Так_забежал_просто... кроме того, тут есть ещё одна сторона. После построения некого полного и формального ТЗ (в предположении, что такое возможно) программный продукт можно считать готовым. Дальше можно напустить на это ТЗ компилятор, и программа будет работать, т.к. это ТЗ и будет являться готовым программным продуктом.

Кстати - очень правильная концепция: "формальное ТЗ"->"правила преобразования"->"готовое п/о".

Zerger Так_забежал_просто
Нет, к сожалению, нельзя избежать правок ТЗ по живому в середине проекта. Если требования жильцов к планировке и расположению квартиры более-менее постоянны, то потребности потребителей программного продукта, как правило, изменяются. Так или иначе меняется бизнес, минимум раз в полгода что-то происходит, смещаются акценты, приоритеты задач. За время разработки полноценного программного продукта даже не предполагаемые, а реальные требования к нему почти наверняка поменяются.
Некоторые компании до внедрения своего ПО проводят экспертизу существующих процессов работы с клиентами, определение особенностей бизнеса Заказчика, целей, которые планируется достичь посредством реализации CRM проекта, и рамок этого проекта , которая проводится на предприятиях. На основании экспертизы создается концепция CRM стратегии для компании заказчика и лишь после этого происходит внедрение. Так что потребность правок в середине проекта сводится к минимуму.

Для программных систем, призваных автоматизировать функционал такой расклад вероятен, т.к. множество автоматизируемых функций конечно и сравнительно невелико и ограничено рамками хорошо проработанного бизнес-процесса (в Вашем случае - прямая работа с клиентами).
Если же говорить об аналитических системах, то основной функционал (как правило - OLAP+reporting+ad hoc и т.п.) успешно покрывается существующими промышленными разработками.
Но формального бизнес-процесса, отвечающего на главный вопрос "что и каким образом анализировать", нет.
Вот формирование такого бизнес-процесса, и, что не менее важно, его обеспечение нужными данными, является основным источником изменений в проекте.
Т.е. изменяеются не требования к п/о, а концепции->методики анализа->отчеты/кубы->данные.
И строить иллюзий о том, что можно создать стандартный процесс не приходится.

Таким образом, основное различие в разработке операционного п/о (OLTP|WorkFlow) от аналитических систем (MIS|BI|DWH) в том, чтов первом случае работают с требованиями к п/о , а во втором случае - с требованиями к данным , а это, согласитесь - две большие разницы.

guest_20040621> И строить иллюзий о том, что можно создать стандартный процесс не приходится.

Почему, можно поинтересоваться?

> Таким образом, основное различие

Функционал определяется именно структурой данных, так что разница - умозрительна.

1. Потому-что OLAP, DataMining, Ad hoc - это технологии доступа, которые позволяют решать необычайно широкий круг задач проводя исследование данных.
Я считаю, что- процесс исследования неформализуем. А по Вашему? Если не согласны - прошу привести пример успешно формализованного детального процесса исследования, который можно применять независимо от объекта исследования (т.е. конкретной компании с ее культурой, политикой учета, источниками данных и прочими заморочками).

2. Функционал чего определяется структурой данных? OLAP средства?
Допустим.
Тогда отсюда вытекает, что покупая OLAP инструмент мы должны изменять его функциональность под те данные, которые нужно анализировать. Так по Вашему выходит? Интересно было-бы взглянуть на такой проект...

Я же пока видел обратную картину - данные необходимо преобразовать под те требования (достаточно высокоуровневые - к слову), которые обеспечивают поддержку функционала OLAP средства.
Доказательство - тысячи внедрений, в мире, продуктов Cognos, MicroStrategy, Business Objects и т.п. без изменения встроенного функционала , причем для самых различных задач (и данных соответственно).

Ну и эта "умозрительная" разница видна даже для традиционных систем, в случае, когда несколько разных клиентов переходят (т.е. отказываются от существующей ИТ системы в пользу другой) на одну и ту-же платформу - для каждого случая необходим уникальный процесс (проект) по конвертированию и загрузке существующих данных. Или, согласно Вашим предположениям, нужно оставить данные "как есть", а лучше изменить функционал платформы?

guest_20040621Нет, конечно. Как Вы правильно заметили, имеющиеся данные дешевле представить в том виде, который необходим для конкретной тулзы.


И это тоже "сильно верно" :0)