byur Jimmy
PS Знаете, не хочется ввязываться во флейм по типу "На чем круче писать программы, на C++ или Delphi?" Если есть вопросы по существу - готов ответить в привате на мыло. ОК?

Чтобы говорит по существу, собеседникам нужно как минимум владеть терминологией и достаточно четко представлять отличие требований от архитектуры и понимать разницу м/у архитектурой и дизайном. Если вы это понимаете -- давайте поговорим по существу, я же не против.

Если есть вопросы по существу - готов ответить...

мимо пробегал byur
Отлично, но вы перечислили аккурат ТРЕБОВАНИЯ к системе (в частности атрибуты качества, касающиеся времени отклика на загрузку данных и время формирования отчетов и необходимость иметь возможность резервног окопирования) а отнюдь не архитектурные характеристики! А теперь вопрос на засыпку -- ЧТО вы напишите в архитектурной спецификации на data warehouse??? Что есть архитектура системы????
.....
и эта специфика должна быть отражена в ТРЕБОВАНИЯХ в первую очередь (ЧТО и НАСКОЛЬКО быстро/эргономично/безопастно/ ....), и только потом в дизайне -- КАК это будет реализовано.


Время отклика, формирование отчетности, резервное копирование.... где вы этих заказчиков откопали? Они далеко не все буквы осилят в этих словах. Максимум на что способны заказчики - это сказать: хотим что б быстро работало. И у нас есть только один способ подстраховаться от расхождений в понимании слова "быстро": написать в требованиях цифру 1 сек для всякого там времени отклика. Но ожидать что заказчик скажет что-то дельное после прочтения подобных спецификаций - в высшей степени наивно. Кстати, Джимми, это к вашим архитектурным спецификациям тоже относится.

Если же к подобному эскизному проекту относится как защите задницы, не пофиг ли как там все изложено и зачем бедному заказчику мозги засе...ть всеми этими излишествами - без них гладишь и докУмент быстрее заапрувят.

1. Насчет измеримых требований - они безусловно есть, и время отклика в ТЗ зафиксировано именно в сек., а не "быстро"

2. При разработке и внедрении систем, основанных на хранилищах данных, есть такая печальная тенденция - каждые 3 из 4 заказчиков пытаются изменить архитектуру системы, т.е. выдвигают требования по ходу проекта, которые связаны с архитектурными решениями. Что такое архитектура BI системы на базе ХД:
а) концептуальная архитектура хранилища данных (двух (автономные витрины) или трехуровневая, как правило)
б) логическая архитектура - data flow (источники данных, ETL1, ETL2, подистема хранения, репозиторий и т.п.)
в) программно-аппаратная архитектура (физическая) - серверы (основной, тестовый, резервный, аналитический и т.д.), станции управления, рабочие станции.

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

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

PS Теперь, надеюсь, ясна мотивация для использования такого подхода?

мимо пробегал И если говорить о сабже дискуссии, то эскизный проект - это описание каким образом эти бизнес-цели будут достигаться и с какими ограничениями.
По сути этот документ - заготовка того,что же изменить в его, заказчика, жизни, когда он все это заполучит.


1. Согласен - наиболее близкое к реальности определение.
2. Ну если только очень приблизительно :0)

mcureenab
Пальцем в небо.
:::
Т.е. в результате выполнения стадии эскизного проекта мы должны получить утверждённые документы определяющие "ПРЕДВАРИТЕЛЬНЫЕ проектные решения по системе и её частям". Видимо, эти документы и назвывают "эскизным проектом".

Чтобы понять, что входит или не входит в ПРЕДВАРИТЕЛЬНЫЕ проектные решения, нужно сравнить содержание работ 8 и 9.

ТП:
mcureenab ...утверждённые документы определяющие "ПРЕДВАРИТЕЛЬНЫЕ проектные решения по системе и её частям"

мимо пробегал ...это описание каким образом эти бизнес-цели будут достигаться и с какими ограничениями.

Jimmy ... наиболее близкое к реальности определение

mcureenab Пальцем в небо...

?