Loading AI tools
Из Википедии, свободной энциклопедии
Метод структурированного системного анализа и проектирования (далее - SSADM) — это системный подход к анализу и проектированию информационных систем. SSADM создавался для Центрального агентства компьютеров и телекоммуникаций, являющегося департаментом правительства Великобритании, занимающегося использованием технологий в правительстве, с 1980 года.
Названия «Метод структурированного системного анализа и проектирования» и «SSADM» являются зарегистрированными торговыми марками Управления государственной торговли (OGC), являющегося подразделением Казначейства Соединенного Королевства. [1]
Основными этапами развития метода структурированного системного анализа и проектирования были: [2]
Три наиболее важных метода, которые используются в SSADM, следующие:
Метод SSADM включает в себя связанные задачи по последовательному анализу, документированию и проектированию.
Чтобы определить, осуществим ли данный проект, необходимо провести некоторые исследования целей и последствий проекта. Для очень небольших проектов это может вообще не потребоваться, поскольку объем проекта легко понять. В более крупных проектах технико-экономическое обоснование может быть выполнено, но в неформальном смысле, либо потому, что нет времени на формальное исследование, либо потому, что проект является «необходимым» и его придется реализовать так или иначе. Диаграмма потока данных описывает то, как работает текущая система, и для визуализации известных проблем.
При составлении технико-экономического обоснования необходимо рассматривать четыре основные области:
Для получения ответов на эти вопросы, технико-экономическое обоснование фактически представляет собой сокращенную версию комплексного системного анализа и проектирования. В некоторой степени анализируются требования и способы использования, прорисовываются некоторые бизнес-варианты и даже некоторые детали технической реализации. Результатом этого этапа является формальный документ с технико-экономическим обоснованием. SSADM определяет разделы исследования, которые должны содержать:
Разработчики SSADM понимали, что почти во всех случаях существует некая форма существующей системы, даже если она полностью состоит из людей и бумаги. Благодаря сочетанию опросов сотрудников, распространению анкет, наблюдений и наличию существующей документации аналитик приходит к полному пониманию системы в том виде, в каком она есть в начале проекта. Это служит многим целям (например каким?).
Изучив текущую систему, аналитик должен решить как в общем проектировать новую систему. Для этого он или она, используя результаты предыдущего этапа, разрабатывает набор вариантов бизнес-системы. Это разные варианты, как может создаваться новая система: от ничего не делать до полного отказа от старой системы и построения совершенно новой. Аналитик может провести мозговой штурм, чтобы сгенерировать как можно больше разнообразных идей.
Затем полученные идеи собираются в варианты, которые представляются пользователю. Возможны следующие варианты:
При необходимости опция будет документирована с помощью логической структуры данных и диаграммы потока данных первого уровня.
Пользователи и аналитик совместно выбирают один бизнес-вариант. Это может быть один из уже определенных вариантов или синтез по различным аспектам существующих вариантов. Результатом этого этапа является один выбранный бизнес-вариант вместе со всеми результатами этапа технико-экономического обоснования.
Вероятно, это самый сложный этап в SSADM. Используя требования, разработанные на этапе 1, и работая в рамках выбранного бизнес-варианта, аналитик должен разработать полную логическую спецификацию того, что должна делать новая система. Спецификация не должна содержать ошибок, двусмысленностей и противоречий. Под логикой мы подразумеваем, что спецификация не говорит, как будет реализована система, а скорее описывает, что она будет делать.
Чтобы создать логическую спецификацию, аналитик строит необходимые логические модели как для диаграмм потоков данных (DFD), так и для логической модели данных (LDM), состоящей из логической структуры данных (называемой в других методах диаграммами отношений сущностей) и полное описание данных и их взаимосвязей. Они используются для создания определения каждой функции, которое пользователи потребуют от системы, жизненных историй объектов (ELH), которые описывают все события на протяжении жизни объекта, и диаграмм соответствия эффектов (ECD), которые описывают, как взаимодействует каждое событие. со всеми соответствующими организациями. Они постоянно сопоставляются с требованиями, и при необходимости требования добавляются и дополняются.
Продуктом этого этапа является полный документ технического задания, который состоит из:
Этот этап является первым на пути к реализации нового системного приложения. Как и в случае с вариантами бизнес-системы, на этом этапе генерируется большое число вариантов реализации новой системы. Это число сужается до двух или трех вариантов, для представления пользователю, из которых впоследствии выбирается или синтезируется окончательный вариант.
Однако соображения совершенно разные:
Все эти аспекты также должны соответствовать любым ограничениям, налагаемым бизнесом, таким как доступные деньги и стандартизация аппаратного и программного обеспечения.
Результатом данного этапа является выбранный вариант технической системы.
Хотя предыдущий уровень определяет детали реализации, результаты этого этапа не зависят от реализации и концентрируются на требованиях к интерфейсу человек-компьютер. Логический дизайн определяет основные методы взаимодействия с точки зрения структур меню и командных структур.
Одной из сфер деятельности определяет пользовательский диалог. Это основные интерфейсы, с помощью которых пользователи будут взаимодействовать с системой. Другие виды деятельности связаны с анализом как влияния событий на обновление системы, так и необходимости запроса данных в системе. Оба они используют события, описания функций и диаграммы соответствия эффектов, созданные на этапе 3, чтобы точно определить, как обновлять и читать данные согласованным и безопасным способом.
Результатом этого этапа является логический проект, который состоит из:
Это заключительный этап, на котором все логические характеристики системы преобразуются в описания системы с точки зрения реального аппаратного и программного обеспечения. Это очень технический этап, и здесь представлен простой обзор .
Логическая структура данных преобразуется в физическую архитектуру с точки зрения структур базы данных. Указана точная структура функций и способы их реализации. Физическая структура данных оптимизируется там, где это необходимо, для удовлетворения требований к размеру и производительности.
Продукт представляет собой полный физический проект, который может рассказать разработчикам программного обеспечения, как построить систему с конкретными деталями аппаратного и программного обеспечения и в соответствии с имеющимися стандартами.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.