WikiDer > Метод анализа и проектирования структурных систем

Structured systems analysis and design method

Структурный системный анализ и метод проектирования (SSADM), первоначально выпущенный как методология, это системный подход к анализу и проектированию информационных систем. SSADM был разработан для Центральное компьютерное и телекоммуникационное агентство, а Правительство Великобритании офис, занимающийся использованием технологий в правительстве, с 1980 года.

Обзор

SSADM - это водопадный метод для анализа и проектирования информационные системы. Можно считать, что SSADM представляет собой вершину строгого подхода, основанного на документации, к проектированию системы и контрастирует с более современным гибкий такие методы как DSDM или же Scrum.

SSADM - это одна из конкретных реализаций, основанная на работе различных школ структурированный анализ и методы разработки, такие как Питер Чекленд методология мягких систем, Ларри Константина структурированный дизайн, Эдвард Йордон Структурированный метод Yourdon, Майкл А. Джексон Структурированное программирование Джексона, и Тома ДеМарко структурированный анализ.

Названия «Структурный системный анализ и метод проектирования» и «SSADM» являются зарегистрированные торговые марки из Управление государственной торговли (OGC), который является офисом Казначейства Соединенного Королевства.[1]

История

Основными этапами разработки методологии анализа и проектирования структурированных систем были:[2]

  • 1980: Центральное компьютерное и телекоммуникационное агентство (CCTA) оценивает методы анализа и проектирования.
  • 1981: Консультанты, работающие в Learmonth & Burchett Management Systems под руководством Джона Холла, выбрали для разработки SSADM v1.
  • 1982: Джон Холл и Кейт Робинсон ушли, чтобы основать Model Systems Ltd, позже компания LBMS разработала LSDM, свою собственную версию.
  • 1983: SSADM стал обязательным для всех разработок новых информационных систем.
  • 1984: выпущена версия 2 SSADM
  • 1986: Выпущена версия 3 SSADM, принята NCC
  • 1988: Выпуск сертификата SSADM, SSADM продвигается как «открытый» стандарт
  • 1989: Движение к Еврометод, запуск схемы сертификации продукции CASE
  • 1990: запущена версия 4
  • 1993: Стандарт SSADM V4 и схема соответствия инструментов
  • 1995: анонсирован SSADM V4 +, запущена V4.2
  • 2000: CCTA переименовал SSADM в «Разработка бизнес-систем». Метод был перекомпонован в 15 модулей и добавлено еще 6 модулей.[3][4]

SSADM методы

В SSADM используются следующие три наиболее важных метода:

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

Этапы

Метод SSADM включает в себя выполнение последовательности задач анализа, документации и проектирования, связанных со следующим.

Этап 0 - Технико-экономическое обоснование

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

Когда проводится технико-экономическое обоснование, необходимо учитывать четыре основные области:

Технические - возможен ли проект технически?
Финансовые - может ли бизнес позволить себе реализовать проект?
Организационно - будет ли новая система совместима с существующей практикой?
Этично - приемлемо ли влияние новой системы на общество?

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

Этап 1 - Исследование текущей среды

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

Этап 2 - Варианты бизнес-системы

Изучив текущую систему, аналитик должен принять решение об общем дизайне новой системы. Для этого он или она, используя результаты предыдущего этапа, разрабатывает набор опций бизнес-системы. Это разные способы создания новой системы: от бездействия до полного отказа от старой системы и создания совершенно новой. Аналитик может провести сеанс мозгового штурма, чтобы сгенерировать как можно больше разнообразных идей.

Затем идеи собираются в варианты, которые представляются пользователю. Варианты учитывают следующее:

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

При необходимости вариант будет задокументирован с помощью логической структуры данных и диаграммы потока данных уровня 1.

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

Этап 3 - Спецификация требований

Это, наверное, самый сложный этап в SSADM. Используя требования, разработанные на этапе 1, и работая в рамках выбранного бизнес-варианта, аналитик должен разработать полную логическую спецификацию того, что должна делать новая система. В спецификации не должно быть ошибок, двусмысленностей и противоречий. Под логикой мы подразумеваем, что спецификация не говорит, как система будет реализована, а скорее описывает, что система будет делать.

Чтобы произвести логическую спецификацию, аналитик строит необходимые логические модели как для диаграммы потоков данных (DFD) и Логическая модель данных (LDM), состоящий из логической структуры данных (в других методах называемой диаграммы отношений сущностей) и полное описание данных и их взаимосвязей. Они используются для создания определений функций каждой функции, которые потребуются пользователям от системы, историй жизни сущностей (ELH), которые описывают все события в течение жизненного цикла сущности, и диаграмм соответствия эффектов (ECD), которые описывают, как каждое событие взаимодействует. со всеми соответствующими организациями. Они постоянно сопоставляются с требованиями, и при необходимости требования добавляются и дополняются.

Продуктом этого этапа является полный документ технических требований, который состоит из:

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

Этап 4 - Варианты технической системы

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

Однако соображения совершенно разные:

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

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

Результатом этого этапа является выбранный вариант технической системы.

Этап 5 - Логический дизайн

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

Одна из сфер деятельности - это определение пользовательских диалогов. Это основные интерфейсы, с помощью которых пользователи будут взаимодействовать с системой. Другие действия связаны с анализом как последствий событий при обновлении системы, так и необходимости делать запросы о данных в системе. Оба они используют события, описания функций и диаграммы соответствия эффектов, созданные на этапе 3, чтобы точно определить, как обновлять и читать данные согласованным и безопасным способом.

Результатом этого этапа является логический дизайн, состоящий из:

  • Каталог данных
  • Требуемая логическая структура данных
  • Модель логического процесса - включает диалоги и модель для процессов обновления и запроса
  • Напряжение и изгибающий момент.

Этап 6 - Физический дизайн

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

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

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

Рекомендации

  1. ^ «НГК - Приложение 1». Управление государственной торговли (OGC). Получено 2010-12-17.
  2. ^ Майк Гудленд; Карел Риха (20 января 1999 г.). «История СГАДМ». SSADM - Введение. Архивировано из оригинал на 2013-02-19. Получено 2010-12-17.
  3. ^ «Модельные системы и SSADM». Model Systems Ltd. 2002. Архивировано 2 апреля 2009 года.. Получено 2009-04-02.CS1 maint: неподходящий URL (связь)
  4. ^ Фонд SSADM. Разработка бизнес-систем с SSADM. Канцелярский офис. 2000. с. v. ISBN 0-11-330870-1.
   5. Кейт Робинсон, Грэм Беррисфорд: объектно-ориентированный SSADM, Prentice Hall International (Великобритания), Hemel Hempstead, ISBN 0-13-309444-8

внешняя ссылка