Метод структурированного системного анализа и проектирования

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

Обзор[править | править код]

  • SSADM — это каскадный метод анализа и проектирования информационных систем . Можно считать, что SSADM представляет собой вершину строгого документированного подхода к проектированию системы и контрастирует с более современными гибкими методами, такими как DSDM или Scrum .
  • SSADM является одной из конкретных реализаций и основывается на работах различных школ структурного анализа и методов разработки, таких как гибкая системная методология Питера Чеклэнда, структурированный дизайн Ларри Константина, структурный метод Юрдона Эдварда Юрдона, структурное программирование Джексона Майкла А. Джексона и структурированный анализ Тома ДеМарко.

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

* История[править | править код]

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

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

Методы SSADM[править | править код]

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

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

Этапы[править | править код]

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

Этап 0 – Технико-экономическое обоснование[править | править код]

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

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

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

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

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

Этап 1 – Исследование текущего состояния[править | править код]

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

Этап 2 – Варианты бизнес-системы[править | править код]

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

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

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

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

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

Этап 3 – Техническое задание[править | править код]

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

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

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

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

Этап 4 – Технические варианты системы[править | править код]

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

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

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

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

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

Этап 5 – Логическое проектирование[править | править код]

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

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

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

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

Этап 6 – Физический проект[править | править код]

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

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

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

Рекомендации[править | править код]

  1. ↑ OGC – Annex 1. Office of Government Commerce (OGC). Дата обращения: 17 декабря 2010. Архивировано из оригинала 1 мая 2011 года.
  2. ↑ Mike Goodland; Karel Riha History of SSADM. SSADM – an Introduction (20 января 1999). Дата обращения: 17 декабря 2010. Архивировано из оригинала 19 февраля 2013 года.
  3. ↑ Model Systems and SSADM. Model Systems Ltd (2002). Дата обращения: 2 апреля 2009. Архивировано 2 апреля 2009 года.
  4. ↑ SSADM foundation. — The Stationery Office, 2000. — P. v. — ISBN 0-11-330870-1.

5. Кит Робинсон, Грэм Беррисфорд: Объектно-ориентированный SSADM, Prentice Hall International (Великобритания), Хемел Хемпстед, ISBN 0-13-309444-8

Внешние ссылки[править | править код]

Источник — https://ru.wikipedia.org/w/index.php?title=Метод_структурированного_системного_анализа_и_проектирования&oldid=134183068