Методология SSADM

Примером еще одной методологии, ориентированной на диаграммы потоков данных, является методология SSADM (Structured Systems Analysis and Design Method), созданная в начале 80-х годов и принятая в 1993 году в качестве национального стандарта Великобритании для разработки информационных систем. Ее несомненным достоинством является наличие взаимосогласованных методик, регламентирующих начальные этапы разработки системы, центральным из которых является этап итеративного определения требований. В то же время SSADM не распространяется на этапы, связанные с реализацией, внедрением и сопровождением системы, отсылая разработчика к другим общедоступным методологиям, рекомендуемым британским государственным агенством по информатике и вычислительной технике.

В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. При моделировании функций используются классические DFD (включающие только базовые объекты: процесс, поток данных, хранилище данных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы истории жизни сущностей ELN (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора.

Согласно SSADM определение системных требований включает следующие шесть основных этапов:

1. Оценка реализуемости. Данный этап предваряет инициациацию работ по созданию системы, его основными процессами являются следующие:

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

§ предварительная экономическая оценка проекта

§ построение план-графика выполнения основных работ

§ подготовка документов по оценке возможности создания системы.

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

§ определение границ будущей системы

§ выявление основных требований

§ выявление процессов обработки информации

§ выявление обрабатываемых данных

§ построение информационно-логической модели требований

§ обобщение результатов и подготовка отчетов

3. Выбор варианта автоматизации. На основании результатов (оценок) предшествующего этапа предлагаются несколько (от 3 до 6) вариантов автоматизации, из которых на основании выявленных ограничений совместно с заказчиком выбирается окончательный вариант.

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

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

6. Физическое проектирование.

§ разработка физической информационной модели

§ разработка спецификаций к программным компонентам

§ оптимизация информационной модели

§ уточнение спецификаций к программным компонентам

§ оформление документации.

Отличительной чертой SSADM является четкое выделение и поддержка соответствующими методиками так называемых “нефункциональных требований”. Нефункциональные требования специфицируют, с каким уровнем качества система должна выполнять свои функции. Примерами таких требований являются:

§ среднее время наработки на отказ

§ время отклика

§ ограничения доступа

§ требования безопасности и т.п.