Участники.

Группа физического проектирования составляется из специалистов но отображению логического проекта системы на физическую среду ее функционирования, по внедрению, отображаемых функциональных компонент, и по настройке баз данных.

Предусловия.

Организационные полномочия:

• соглашение по стратегии физического проектирования;

• планирование на стадии физического проектирования;

• управление на стадии физического проектирования.

Входы:

• стандарты по вводу в действие разработки;

• спецификация логической системы.

Ссылки:

• спецификация физической среды функционирования.

Продукты:

• физический проект;

• стандарты разработки прикладных программных средств.

Действия:

• физический проект

1.4. Ключевые понятия и философия

В этом разделе описываются ключевые понятия SSADM и философия, положена в ее основу, а именно:

• три вида моделей, необходимых для анализа взглядов пользователей на процесс функционирования системы, события и информацию в бизнесе;

• ориентация на требования пользователей, определяющая цели, которые должны быть проанализированы и использованы при оценке достижимости;

• моделирование пользователя, функций и данных, определяющее цели пользователя при решении различных функциональных задач и исследующее типы взаимодействий пользователя с системой;

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

1.4.1. Три вида модели.

SSADМ является универсальной методологией, но из этого не следует, что философия, которая положена все основу слишком обобщена и неясна. Эта методология помогает аналитику сконструировать систему для выполнения четко определенных требовании бизнеса. Она постоянно уточняется по мере увеличения объема знаний о деталях требовании. Инструментом, помогающим сделать это, является анализ по трем ключевым направлениям:

• функции:

• события;

• данные.

Функции как реакции на события отражают точку зрения пользователя на функционирование системы.

События могут быть реальными событиями бизнеса (такими как "Получение заявки") или событиями, генерируемыми самой системой (такими как указатель конца месяца для составления информационного отчета).

Данные перерабатываются и поддерживаются в объеме, достаточном для функционального наполнения системы. Они представляют собой ту информационную среду, которая окружает информационную систему.

Требования должны формироваться, исходя из всех трех направлений, так как отсутствие любого из них приведет к неполноте описания.

Интеллектуальная основа SSADM показана на рис. 1.3 и состоит из:

• логической модели информационных связей (логическая модель данных);

• модели взаимосвязи по данным между процессами, хранилищами данных и внешними объектами (модель потоков данных);

• моделей распространения влияния бизнес - событий, определяемых как спусковые механизмы для потоков данных, текущих между объектами.

Рис. 1.3. Структура моделей SSADM

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

Наоборот, слишком детализированная, функционально переполненная конструкция системы малополезна, особенно если выделенная структура данных неадекватна или громоздка. Процесс без сырья для работы (в нашем случае данных) похож на пустую машину. Он должен иметь вход и выход. И, наконец, даже если и конструкция данных и функциональное наполнение хорошо спроектированы, маловероятно, что они удовлетворят пользователя, если они создавались без ясного понимания тех событий, которые происходят в реальном мире и которыми система должна управлять. Система, построенная без учета событий, происходящих во внешней по отношению к ней среде, является закрытой и обслуживает только свои собственные нужды, а не потребности конкретного бизнеса. SSADM предусматривает проверку правильности порядка, в котором происходят события, чтобы еще раз убедиться в том, что все существующие в действительности последовательности событий правильно учтены.

Ключевыми моментами такого подхода являются:

• анализ требований пользователя с углубленной детализацией;

• три взаимно проникающих и дополняющих друг друга взгляда на систему;

• спецификации, полнота которых обеспечивают базу для использования и

поддержки широкого диапазона функций пользователя.

Такой подход выражается в виде комбинации следующих элементов:

• ориентации на требования пользователя;

• моделирования пользователя, функций и данных;

• разделения логического и физического проектов.