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

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

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

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

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

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

История [ править ]

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

1980: Центральное агентство компьютеров и телекоммуникаций (CCTA) оценивает методы анализа и проектирования.
1981: Консультанты, работающие в компании Learmont & 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» . Управление государственной торговли (OGC) . Проверено 17 декабря 2010 г.
^ Майк Гудленд; Карел Риха (20 января 1999 г.). «История ССАДМ» . SSADM – Введение . Архивировано из оригинала 19 февраля 2013 г. Проверено 17 декабря 2010 г.
^ «Модельные системы и SSADM» . Model Systems Ltd. 2002. Архивировано из оригинала 2 апреля 2009 года . Проверено 2 апреля 2009 г. {{cite web}}: CS1 maint: неподходящий URL ( ссылка )
^ Фонд ССАДМ . Разработка бизнес-систем с помощью SSADM. Канцелярский офис . 2000. с. ISBN против 0-11-330870-1 .

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

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

[1] «ОГК – Приложение 1» . Управление государственной торговли (OGC) . Проверено 17 декабря 2010 г.

[2] Майк Гудленд; Карел Риха (20 января 1999 г.). «История ССАДМ» . SSADM – Введение . Архивировано из оригинала 19 февраля 2013 г. Проверено 17 декабря 2010 г.

[3] «Модельные системы и SSADM» . Model Systems Ltd. 2002. Архивировано из оригинала 2 апреля 2009 года . Проверено 2 апреля 2009 г. {{cite web}}: CS1 maint: неподходящий URL ( ссылка )

[4] Фонд ССАДМ . Разработка бизнес-систем с помощью SSADM. Канцелярский офис . 2000. с. ISBN против 0-11-330870-1 .

[1]

[2]

[3]

[4]