Ранние стадии

Рассмотрение результатов анализа

Это собственно процесс передачи информации от аналитиков проектировщикам. На практике это итерактивный процесс. У проектировщиков неизбежно будут возникать вопросы к аналитикам, и наоборот. Информация о системе будет постоянно уточняться. При разработке схемы базы данных может измениться информационная модель, полученная на этапе анализа, например потому, что имеющееся проектное решение нестабильно либо медленно работает при реализации его посредством выбранной СУБД или в силу иных причин. Проверить, охватывает ли анализ все бизнес-процессы системы (то есть осуществить проверку на полноту), проектировщики не в состоянии, но проверку информационной модели на непротиворечивость и корректность проектировщики провести могут. Это позволяет отследить ошибки в информационной модели и не повторить их в модели данных. Если результаты хранятся в репозитарии CASE-средства, то такая проверка на корректность может быть произведена автоматически.

Семинары

Ранние стадии проектирования сопряжены с нудной и утомительной работой. Проектировщики и аналитики должны достигнуть полного понимания требований заказчика. Семинары являются быстрым и эффективным способом обмена информацией. Хороший способ убедиться в том, правильно ли проектировщики понимают назначение той или иной подсистемы, – взять один или несколько сценариев бизнес-процессов и проиграть их. Это можно сделать в форме простой диаграммы потока данных, причем необходимо указать не только автоматизированные, но и ручные функции.

Критические участки

Критические участки системы изучаются при первом обследовании системы и уточняются на этапе анализа. Термин «критические» может означать жизненно важные как для нормального функционирования информационной системы с точки зрения бизнеса (например, время простоя автоматизированной линии изготовления материала X не должно превышать одной минуты), так и для успешной реализации и приемки проекта. Критические с точки зрения бизнеса участки информационной системы хорошо подходят для макетирования. На основе этих макетов (работы макетирования выполняют проектировщики и группы тестирования) тестеры дают оценку качества как информационной модели, так и модели данных. Также макетирование позволяет показать, какие требования и какими средствами могут быть выполнены, а какие требования – не могут.

Часто на этапе проектирования выявляются критические участки, которые не были очевидными на этапе анализа. Это влечет за собой необходимость уточнения информационной модели. Часто это связано с особенностями реализации тех или иных возможностей в выбранной СУБД. Некоторые функции, которые на этапе анализа выглядят простыми, могут стать очень сложными, когда дело дойдет до физической реализации. Например:

• В выбранной СУБД отсутствует эффективный механизм сканирования деревьев, а при анализе выявлено большое количество справочников и выбраны интерфейсы представления в виде деревьев, кроме того это понравилось заказчику, а СУБД при большом справочнике работает слишком медленно.
• Другая распространенная неприятность – неполно реализованная ссылочная целостность. В СУБД не реализованы каскадные модификации, в информационной модели нормализованные отношения предполагают наличие каскадных удалений и обновлений. Реализация же таких механизмов посредством триггеров оказалась слишком медленной, и уровень каскадирования триггеров ниже, чем уровень каскадных операций, определенных в информационной модели.

Такие моменты могут инициировать не только изменение информационной модели, но и смену СУБД.

Между критическими участками проекта и его рисками существует тесная связь. Критический участок разработки (например, срыв сроков первого этапа сдачи проекта заказчику) может стоить целого проекта. Причинами срыва могут быть как ошибки проектирования, так и нехватка персонала.