Опыт разработки ИС в настоящее время показывает, что возможно создание класса, который будет реализовывать 90% прикладного функционала в 90% объектов ИС на его основе. Специфические методы (обработка записей, экранные формы и формы отчётов и т.п.) могут быть добавлены в нескольких стандартных «точках входа» через списки и меню выбора с использованием простых для пользователей конструкторов или с помощью скриптов, подготовленных профессионалами и легко внедряемыми о конкретный объект.
Предлагаю обсудить несколько вопросов.
1. Какая часть работы должна быть выполнена на этапе создания ИС, а какая при эксплуатации в рамках продолжающейся разработки?
2.Кто должен выполнять создание: продвинутый пользователь или программист;
3. Какую часть работ по дальнейшему развитию функционала можно отдать современному пользователю, а какая должна быть выполнена только профессионалами и почему?
4. Как уменьшить долю работ профессионалов?
5. Позволяет ли такой подход создать промышленное решение?
6. Сколько времени должно занимать создание приложения
7. Какие методы обязательны (в рамках 90%) ?
8. Почему существующие в глобальной сети системы RAD заточены не на прикладные свойства системы, а на создание экранных форм и обладают крайне слабыми аналитическими возможностями (в лучшем случае, сортировка и поиск по одному полю + отчёты)?
9. Расположение: локально или глобально. Если глобально, то WEB-интерфейс или десктоп на облачном сервере. Если облако, то Windows, Linux, FreeBSD, ….

iscrafm,
возможно надо выделить несколько областей и рассматривать их отдельно. Тогда отдельный вопрос — какие и что их делает особенными, какой объём этих особенностей, можно ли обобщить ?

skyANA,
ну это те самые 10% - специальный плагин для чтения этих данных и, может быть, записи их (плохо знаю такого типа ИС) , хотя и там либо SQL либо NOSQL.

skyANA,
90% - условное значение, но если в системе есть очевидные операции
- добавить, изменить удалить запись или группу записей;
- показать записи в разных удобных форматах;
- отсортировать по полю, полям, выражению из полей;
- искать и выбирать по полям,..., выражениям на основе полей (с учётом словоформ, синонимов ..., с учётом полей в дочерних таблицах);
- создавать формы отчётов и накладывать их на выбранные и отсортированные данные;
- выполнять другие стандартные действия ( групповую замену одних текстов на другие, подведение итогов по колонке или выражению из нескольких колонок, выгрузка и загрузка в XML и др. широко используемых форматах, построение каких-то итоговых таблиц типа pivot-table и консолидации числовых полей по полям указанным в сортировке и т. д.)
-разрешить пользователю настраивать внешний вид данных (как в Excel) и более ...

-что ещё ... надо подумать ... собственно поэтому и вышел на форум.

skyANA,

а модули, компоненты - это 10% т.е. то, что специфично для конкретной информационной системы.

Лирическое отступление.
Когда-то автомобиле и сервис к ним был такого качества, что на них могли ездить только крутые перцы перемазанные в солидоле.
Моя мать не решалась, хотя права имела. Концерн VW когда производил 2.5 миллиона бюджетных авто. Автопроизводители поработали и создали нечто понятное дамам в высшим образованием, но без среднего (редко кто правильно отвечает во сколько раз надо увеличить дистанцию до впереди идущей авто, если скорость увеличилась в два раза!). Производство машин резко увеличилось - только в Китае сейчас более 50 заводов. Свою роль выполнил сервис , ведь не каждая блондинка дотащит колесо от своего Лэнд Круизера до шиномонтажа. Всего лишь понятность, надежность и доступность.

Не уверен, что сложные системы должны сложно создаваться и управляться (вспомним наших детей, пока они дети).

Информационные системы где-то между ...

Хотелось бы увидеть простые решения для сложных проблем, их упрятывание в "чёрный ящик" ПО.

Нашёл простые решения для простых проблем (РУНА, MyTaskHelper), но это пока ещё хоть и надежный, но двухколесный и без мотора - далеко не уедешь.

На конкретном примере.

Есть сотрудник в крупной фирме или небольшом государстве. Время от времени надо от региональных подразделений разбросанных по всему миру или его окрестностям собирать некоторую информацию (сегодня одну - завтра другую), которую укажет руководитель. Собирать надо быстро, а информация каждый раз разная, но в рамках относительно простых реляционных моделей и полей в таблицах 10-100 (всего) с некоторыми ограничениями (классификаторы, условия, маски, шаблоны). Сотрудник с хорошим (финансовым, биологическим, метео, МЧС-овским ) образованием и умеет думать, и обучаем, но не программист (да и нет времени программисту всё объяснять). Как этому горемыке сделать ИС и опубликовать её, да так, чтобы в регионах каждый заполнил свою часть таблиц (может быть не видя, что делают другие регионеры). Изготовитель ИС должен видеть всё и прямо в ней и тут же провести необходимую обработку (статистическую, отчёты, графика и т.д.) не перегружая в другое приложение. Обработка не очень сложная , но вплоть до OLAP .

Есть что-нибудь для этого (у нас, у них) или надо ваять? А если ваять, то как лучше?