Содержание |
Методология SSADM создана в начале 80-х годов и принятая в 1993 году в качестве национального стандарта Великобритании для разработки информационных систем. Ее несомненным достоинством является наличие взаимосогласованных методик, регламентирующих начальные этапы разработки системы, центральным из которых является этап итеративного определения требований. В то же время SSADM не распространяется на этапы, связанные с реализацией, внедрением и сопровождением системы, отсылая разработчика к другим общедоступным методологиям, рекомендуемым британским государственным агенством по информатике и вычислительной технике.
В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. При моделировании, функций используются классические DFD (включающие только базовые объекты: процесс, поток данных, хранилище данных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы истории жизни сущностей ELN (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора.
Этапы разработки ИТ-системы по SSADM
Согласно стандарту при разработке автоматизированной системы выделяются следующие этапы:
Стадия 0. Оценивание реализуемости (необязательно).
- Определить рамки и составить план разработки.
- Определить первоначальный вариант требований.
- Выбрать вариант оценивания реализуемости.
- Оформить отчёт о возможности создания.
Стадия 1. Предпроектное исследование.
- Определить рамки предпроектного исследования.
- Определить основные требования.
- Изучить процессы обработки информации в существующей системе.
- Изучить данные, обрабатываемые в существующей системе.
- Разработать логическое описание существующей системы.
- Обобщить результаты предпроектного исследования.
Стадия 2. Выбор варианта автоматизации.
Стадия 3. Разработка технического задания.
- Разработать общие требования к автоматизируемым функциям.
- Разработать требуемую логическую модель данных.
- Уточнить требования и функциональные задачи.
- Уточнить логическую модель данных.
- Разработать демонстрационный прототип.
- Разработать требования к обработке данных.
- Уточнить цели разработки.
- Оформить техническое задание на создание АС.
Стадия 4. Выбор варианта технической реализации.
- Разработать варианты технической реализации,
- Выбрать вариант технической реализации.
Стадия 5. Разработка логического проекта.
- Определить порядок диалогового взаимодействия.
- Разработать постановки задач модификации баз данных.
- Разработать постановки информационных задач.
- Завершить разработку логического проекта.
Стадия 6. Физическое проектирование.
- Подготовить план физического проектирования.
- Разработать физическую реализацию баз данных.
- Разработать спецификации требований к программным компонентам.
- Оптимизировать физическую структуру баз данных.
- Уточнить спецификации требований к программным компонентам.
- Согласовать интерфейс между задачами и базами данных.
- Оформить физический проект.
Комментарии
Исходные данные накапливаются в специальном документе – «Каталоге требований».
На стадии 3 составляют другие документы, дополняющие каталог требований. Определение требований – итерационный процесс.
На стадии 0 может появиться каталог требований, в случае, если этап 0 не проводится, его вводят на стадии 1.
На стадии 1 составляется модель в терминах задач, информационных потоков, обрабатываемых данных. Все выявленные недостатки существующей системы оформляются в каталог требований. Если система создаётся на голом месте, то все требования записываются в соответствии с пожеланиями пользователей. Основная цель этапа 1 составить перечень функций системы.Российский рынок видеоконференцсвязи: оценки, драйверы, крупнейшие участники. Обзор TAdviser 
На стадии 2 разрабатывают от трех до шести вариантов автоматизации и выбирают один из них. На стадии 3 требования пересматриваются с учётом выбранного варианта автоматизации. Если какие-то требования не удовлетворяются, то указывают причину.
На этапах 301-303 строят формализованную модель.
В неё входят модель информационных потоков, логическая модель данных, описание функций.
После этапа 3 запрещено добавлять новые требования к системе, однако допускается их уточнение.
На стадии 4 остаются требования, касающиеся технической и программной реализации. Пути их удовлетворения отражаются в «вариантах технической реализации». Другая часть требований – требования к диалоговому взаимодействию, реализуются на этапе 501. Задокументировать требования – основная задача проектировщика. В его задачи также входит сбор первичных требований.
В процессе сбора необходимо получить ответ на многие вопросы, такие как: что требуется от системы, зачем это нужно, кому это необходимо, насколько это важно, чем можно измерить степень соответствия требованиям.
До стадии 3 все требования не окончательны.
К ним могут добавляться требования на вновь разрабатываемые документы. Виды требований делятся на функциональные и нефункциональные (что нужно делать и с каким качеством).
Источники
