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

Тема этой статьи может не соответствовать общему правилу значимости Википедии . Пожалуйста, помогите продемонстрировать значимость темы, ссылаясь на надежные вторичные источники , которые независимы от темы и обеспечивают ее значительное освещение, выходящее за рамки простого тривиального упоминания. Если значимость не может быть показана, статья, скорее всего, будет объединена , перенаправлена ​​или удалена . Найти источники:  "Structured systems analysis and design method" – новости  · газеты  · книги  · ученый  · JSTOR ( октябрь 2017 г. ) ( Узнайте, как и когда удалить это сообщение )

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

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

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

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

Названия «Метод структурированного системного анализа и проектирования» и «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: Переход на Euromethod , запуск схемы сертификации продукции CASE
• 1990: Выпущена версия 4.
• 1993: Стандарт SSADM V4 и схема соответствия инструментов
• 1995: анонсирован SSADM V4+, запущена версия V4.2
• 2000: CCTA переименовала SSADM в «Разработку бизнес-систем». Метод был переупакован в 15 модулей и добавлено еще 6 модулей. ^{[3] [4]}

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

Логическое моделирование данных

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

Моделирование потока данных

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

Моделирование событий сущностей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результатом этого этапа является полный документ со спецификацией требований, который состоит из:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Материалы без ссылок могут быть оспорены и удалены. Найти источники:  "Метод структурированного системного анализа и проектирования" – новости  · газеты  · книги  · ученый  · JSTOR ( ноябрь 2008 г. ) ( Узнайте, как и когда удалять это сообщение )

• Что такое SSADM? на webopedia.com
• Введение в методологии и SSADM
• Пример использования прагматичного SSADM
• Структурированный анализ Wiki