Лекции - Управление жизненны циклом ИС

Подождите немного. Документ загружается.

Пряма в тексте выделил вопросы.

Не разбивал по вопросам потому что под таблицей много мусора, который на свое усмотрение

можно использовать против себя

Для того что бы не ошибится читаем внимательно табличку, выбираем нужный этап и расписываем)

 ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных

межотраслевых документов.

 Комплекс рассчитан на взаимодействие заказчика и разработчика.

 ГОСТ 34 в основном уделяет внимание содержанию проектных документов.

 Комплекс стандартов на автоматизированные системы:

 ГОСТ 34.201-89 ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ

ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ.

 ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ СТАДИИ СОЗДАНИЯ.

 ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ

СИСТЕМЫ.

 ГОСТ 34.603—92 ВИДЫ ИСПЫТАНИЙ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

7-11. Этапы и стадии процесса проектирования ИС по ГОСТ 34.

Стандарт устанавливает стадии и этапы создания АС.

Стадии Этапы работ

1. Формирование требований к АС

8) ГОСТ 34. Состав и содержание

работ на предпроектной стадии

проектирования ИС.x

возможно и 2 стадия тоже

1.1. Обследование объекта и обоснование

необходимости создания АС.

1.2. Формирование требований пользователя к

АС.

1.3. Оформление отчёта о выполненной работе и

заявки на разработку АС (тактико-технического

задания)

2. Разработка концепции АС.

8) ГОСТ 34. Состав и содержание

работ на предпроектной стадии

проектирования ИС.x

2.1. Изучение объекта.

2.2. Проведение необходимых научно-

исследовательских работ.

2.3. Разработка вариантов концепции АС,

удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3. Техническое задание.

9) ГОСТ 34. Состав и содержание

работ на стадии технического

проектирования ИС.

3.1. Разработка и утверждение технического

задания на создание АС.

4. Эскизный проект.

9) ГОСТ 34. Состав и содержание

работ на стадии технического

проектирования ИС.

4.1. Разработка предварительных проектных

решений по системе и её частям.

4.2. Разработка документации на АС и её части.

5. Технический проект.

10) ГОСТ 34. Состав и содержание

работ на стадии рабочего

проектирования ИС.

5.1. Разработка проектных решений по системе и

её частям.

5.2. Разработка документации на АС и её части.

5.3. Разработка и оформление документации на

поставку изделий для комплектования АС и (или)

технических требований (технических заданий)

на их разработку.

5.4. Разработка заданий на проектирование в

смежных частях проекта объекта автоматизации.

6. Рабочая документация.

10) ГОСТ 34. Состав и содержание

6.1. Разработка рабочей документации на

систему и её части.

работ на стадии рабочего

проектирования ИС.

6.2. Разработка или адаптация программ.

7. Ввод в действие.

11) ГОСТ 34. Состав и содержание

работ на стадии ввода ИС в

эксплуатацию

7.1. Подготовка объекта автоматизации к вводу

АС в действие.

7.2. Подготовка персонала.

7.3. Комплектация АС поставляемыми изделиями

(программными и техническими средствами,

программно-техническими комплексами,

информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приёмочных испытаний.

8. Сопровождение АС 8.1. Выполнение работ в соответствии с

гарантийными обязательствами.

8.2. Послегарантийное обслуживание.

Стадии этапы, выполняемые организациями - участниками работ по созданию АС,

устанавливаются в договорах и техническом задании

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

объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий

проект". Допускается выполнять отдельные этапы работ до завершения предшествующих стадий,

параллельное во времени выполнение этапов работ, включение новых этапов работ

ГОСТ 34.201-89

ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ

АВТОМАТИЗИРОВАННЫХ СИСТЕМ

Перечень наименований разрабатываемых документов на систему и ее части должен быть

определен в техническом задании на создание автоматизированной системы (подсистемы), которое

разрабатывается в соответствии с требованиями ГОСТ 34.602

На стадии «Ввод в действие» разрабатывают следующие организационно-распорядительные

документы:

1) акт завершения работ;

2) акт приемки в опытную эксплуатацию;

3) акт приемки в промышленную эксплуатацию;

4) план-график работ;

5) приказ о составе приемочной комиссии;

6) приказ о проведении работ;

7) программа работ;

8) протокол испытаний;

9) протокол согласования.

ГОСТ 34.603-92

ВИДЫ ИСПЫТАНИЙ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

 Испытания АС проводят на стадии “Ввода в действие” по ГОСТ 34.601 с целью проверки

соответствия создаваемой АС требованиям технического задания (ТЗ).

 Виды испытаний и статус приемочной комиссии устанавливают в договоре и (или) ТЗ.

 Для планирования проведения всех видов испытаний разрабатывают документ “Программа и

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

12. Состав и содержание технического задания на разработку ИС.

ГОСТ 34.602-89

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.

ОБЩИЕ ПОЛОЖЕНИЯ

 ТЗ на АС является основным документом, определяющим требования и порядок создания

автоматизированной системы, в соответствии с которым проводится разработка АС и ее

приемка при вводе в действие.

 Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и

разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой

частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись “Действует с ... ”.

СОСТАВ И СОДЕРЖАНИЕ

ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

 общие сведения;

 назначение и цели создания (развития) системы;

 характеристика объектов автоматизации;

 требования к системе;

 состав и содержание работ по созданию системы; .

 порядок контроля и приемки системы;

 требования к составу и содержанию работ по подготовке объекта автоматизации к вводу

системы в действие;

 требования к документированию;

 источники разработки.

В ТЗ на АС могут включаться приложения, допускается вводить дополнительные, исключать или

объединять подразделы.

В разделе “Общие сведения” указывают:

 полное наименование системы и ее условное обозначение;

 шифр темы или шифр (номер) договора;

 наименование предприятий (объединений) разработчика и заказчика (пользователя) системы

и их реквизиты;

 перечень документов, на основании которых создается система, кем и когда утверждены эти

документы;

 плановые сроки начала и окончания работы по созданию системы;

 сведения об источниках и порядке финансирования работ;

 порядок оформления и предъявления заказчику результатов работ по созданию системы (ее

частей), по изготовлению и наладке отдельных средств (технических, программных,

информационных).

Раздел “Требования к системе” состоит из следующих подразделов:

 требования к системе в целом;

 требования к функциям (задачам), выполняемым системой;

 требования к видам обеспечения.

Раздел “Состав и содержание работ по созданию (развитию) системы” должен содержать

перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601, сроки их

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

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

ответственного (заказчик или разработчик) за проведение этих работ. В данном разделе также

приводят:

 перечень документов, по ГОСТ 34.201, предъявляемых по окончании соответствующих

стадий и этапов работ;

 вид и порядок проведения экспертиза технической документации (стадия, этап, объем

проверяемой 'документации, организация-эксперт);

ПОРЯДОК РАЗРАБОТКИ СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на

основании технических требований. Срок согласования проекта ТЗ на АС в каждой организации не

должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование

экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика

и заказчика системы.

Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием.

Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и

заказчиком (или другими заинтересованными организациями), то составляется протокол

разногласий

Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются

разработчиком ТЗ на АС участникам создания системы.

13. Современные методологии создания ИС

Цель методологии создания информационных систем (ИС) заключается в организации

процесса построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать

выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными

задачами, решение которые должна обеспечивать методология создания корпоративных ИС

(вместе с соответствующим набором инструментальных средств) являются следующие задачи:

обеспечивать создание корпоративных ИС, отвечающих предъявляемым к ним требованиям

по автоматизации деловых процессов и отвечающих целям и задачам организации;

гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета;

поддерживать удобную дисциплину сопровождения, модификации и наращивания системы,

чтобы ИС могла отвечать быстро изменяющимся требованиям работы компании;

обеспечивать создание корпоративных ИС, отвечающих требованиям открытости,

переносимости и масштабируемости;

обеспечивать использование в разрабатываемой ИС задела в области информационных

технологий, существующего в организации (ПО, баз данных, средств вычислительной техники,

телекоммуникаций, технологий).

Методология должна обеспечивать снижение сложности процесса создания ИС за счет

полного и точного описания этого процесса и применения современных методов и технологий

создания ИС на всем жизненном цикле ИС - от замысла до реализации.

В 90-ые годы в мире произошли кардинальные изменения как на рынках товаров и услуг, так и

в информационных технологиях (ИТ). Современные корпоративные ИС становятся основным

фактором успешной работы корпораций на рынке. Для выполнения своего назначения они должны

решать значительно более сложные задачи, чем раньше. В соответствии с высокой динамикой

изменения ситуации на рынке становятся очень жесткими требования как к функциям, выполняемым

ИС, так и к процессу создания ИС. Резко ужесточились требования ко времени разработки

отдельных приложений и системы в целом. Появилась необходимость в изменении требований в

процессе разработки с тем, чтобы система отвечала требованиям организации на момент конца

разработки, а не на момент начала.

Достижения в области ИТ позволили преодолеть принципиальные технические и программно-

инструментальные проблемы создания корпоративных ИС. Появились современные аппаратно-

программные платформы архитектуры клиент-сервер, средства для проведения распределенных

параллельных вычислений и управления вычислительным процессом в гетерогенных сетях, методы

и средства разработки программ и баз данных, обеспечивающие возможности создания открытых,

переносимых, масштабируемых приложений и баз данных, возможности быстрой разработки и т.д.

(Об этом свидетельствуют и многочисленные публикации в журнале СУБД.)

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

корпоративные ИС, недостаточно иметь только современные платформы и средства, а прежние

методологии создания ИС, созданные в 70 - 80-е годы и ориентированные на мэйнфрэймы и

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

данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994г,

неудачными оказались более 30% проектов общей стоимостью более чем 80 миллиардов долларов.

При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход

средств составил 189% от запланированного бюджета. Анализ показал, что большинство неудач

было связано с отсутствием или неправильным применением методологии проектирования ИС.

Мощные импульсы развитию методологий дало появление двух принципиально новых

подходов к созданию корпоративных ИС: информационного инжиниринга и реинжиниринга бизнес-

процессов (BPR). Предлагаемые в них методы позволили описывать, анализировать и

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

этих подходов породил свой класс методологий, обладающих общими характеристиками. В

настоящее время продолжается активный процесс развития и совершенствования методологий

создания корпоративных ИС. В этой области работают многие ведущие специалисты во всем мире.

В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems

Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной основе

разрабатывает проекты стандартов, методы и методологию быстрого создания приложений (ИС). В

консорциуме участвуют и российские компании.

Таким образом, с появлением инструментальных средств нового поколения роль методологии

при создании ИС не только не снизилась, - она возросла. По данным опроса, проведенного в 1994 г,

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

сервер, двумя наиболее важными факторами для успешной разработки своих ИС.

Сегодня в нашей стране недостаточно оценивается роль и значение методологии (в отличии

от средств проектирования прикладного программного обеспечения). В предстоящие годы задача

создания корпоративных ИС на базе современных методологий встанет перед многими

отечественными организациями. (При этом заметим, что на Западе методологии по-прежнему

считают стратегической продукцией. Многие из них представляют собой ноу-хау и по сей день.)

2. Основные составляющие методологии

Целью работы является описание методологии, обеспечивающей решение перечисленных

выше основных задач. Предлагаемая методология создания корпоративных ИС состоит из двух

основных взаимосвязанных частей: методологии анализа ИС, включающей описание деятельности

организации и формирование требований к ИС на основе бизнес-процессов, и методологии

проектирования от данных, предназначенной для проектирования и быстрой разработки

программного и информационного обеспечения ИС. Предлагаемая методология строится на основе

итерационной спиральной модели жизненного цикла ИС. Принципиальной особенностью этой

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

на поддержку начальных этапов создания корпоративных ИС, главной задачей которых является

формирование требований к ИС, точно отвечающих целям и задачам организации. В соответствии с

подходом информационного инжиниринга, который Джеймс Мартин определяет как "применение

взаимосвязанного набора формальных технологий (моделей) для планирования, анализа,

проектирования и создания информационных систем на уровне корпораций или отдельных ее

частей ...", процесс создания ИС строится как процесс построения и развития моделей. Реализация

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

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

соответствии с методологией на протяжении ЖЦ ИС.

Таким образом, фундамент предлагаемой методологии составляют:

итерационная спиральная модель жизненного цикла ИС;

комплекс развивающихся систем согласованных моделей;

методология анализа ИС на основе бизнес-процессов;

методология проектирования от данных;

комплекс согласованных инструментальных средств

3. Итерационная спиральная модель жизненного цикла ИС.

Методология описывает процесс создания и сопровождения информационных систем в виде

жизненного цикла (ЖЦ) ИС, представляя его в виде последовательности стадий, каждая из которых

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

последовательность выполняемых работ, получаемые результаты, методы и средства,

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

описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и

обеспечить управление этим процессом.

Жизненный цикл ИС, определяемый методологией, приведен на рис.1. Он включает стадии

анализа, проектирования, разработки, тестирования и интеграции, внедрения, сопровождения и

развития ИС. На рисунке приведены также перечень основных этапов для каждой стадии ЖЦ и

процессы, выполняемые на протяжении всего ЖЦ - процессы управления и интегральные процессы.

Эти процессы в той или иной степени присутствуют на каждом из этапов.

Процесс создания ИС представляет из себя процесс построения и последовательного

преобразования согласованных моделей на всех этапах ЖЦ. Эти модели сохраняются и

накапливаются в репозитории проекта. С помощью CASE-средств модели создаются,

преобразуются и контролируются. Основными результатами на каждом этапе ЖЦ являются модели

определяемых на данном этапе объектов (организации, требований к ИС, проекта ИС, требований к

приложениям и т.д.).

Характер выполняемых процессов и организация работ в представленной модели ЖЦ

основаны на подходе информационного инжиниринга и отличаются от классической каскадной

модели ЖЦ, несмотря на внешнюю схожесть. При традиционной обработке данных разработка

велась строго последовательно. Требования ТЗ утверждались в начале разработки, а их

выполнение проверялось в конце. Переход от стадии к стадии, от этапа к этапу допускался только

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

ЖЦ ИС, предлагаемый в новой методологии определяется следующими особенностями.

Современные средства CASE, 4GL, СУБД и др. предоставляют возможности быстрого

проектирования, прототипирования, разработки и тестирования приложений и баз данных на основе

построенных моделей.

Методология предполагает активное участие заказчиков на всех этапах создания ИС,

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

Эти особенности определяют возможности оперативного и быстрого пересмотра требований и

разработанных решений на основе современных средств, возможности неравномерной,

параллельной разработки различных частей проекта, возможности возврата на предыдущие этапы

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

предусматривает и версионный характер изменения проекта или его частей при поддержке CASE-

средств. Все это определяет итерационный, спиральный характер предлагаемой модели

жизненного цикла.

5. Методология анализа ИС на основе бизнес-процессов

Целью начальных этапов создания ИС, выполняемых на стадии анализа, является

формирование требований к ИС, корректно и точно отражающих цели и задачи организации. Чтобы

описать процесс создания ИС, отвечающей целям и задачам организации, нужно выяснить в чем

заключаются эти цели и задачи. Нужно выяснить требования заказчиков к ИС и преобразовать их на

языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и

задачам организации.

Современные средства позволяют достаточно быстро создавать ИС по готовым требованиям.

Но как отмечалось выше, очень часто оказывается, что эти системы не удовлетворяют заказчиков.

Их приходится постоянно дорабатывать, что приводит к резкому удорожанию фактической

стоимости ИС. Основной причиной такого положения является неправильное, неточное или

неполное определение требований к ИС. И это не случайность. Как правило, заказчики не могут

правильно и точно сформулировать требования к ИС. Более того, они зачастую не могут точно

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

чтобы извлечь эту информацию из заказчиков. Проблема формирования требований к ИС остается

до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и тяжелых

для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ

создания ИС, когда эти требования должны быть выявлены и формализованы, в получении

конечного результата. Предлагаемая методология определяет, какие виды данных должны

собираться в организации в процессе обследования и какие модели строиться для того, чтобы

сформировать требования к ИС.

Основу деятельности любой организации составляют ее деловые процессы, или бизнес-

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

реализацию всех видов деятельности организации, связанных с производством товаров и/или услуг,

которые корпорация либо производит, либо продает и поставляет, либо делает все это в

совокупности. Каждый бизнес-процесс характеризуется четко определенными во времени началом и

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

внутри организации, либо описывают выход во внешнее окружение, последовательностью

выполняемых работ и правилами их выполнения (бизнес -правилами). Для каждой работы,

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

общей последовательности работ, условия инициации и время выполнения.

В отличии от описания организации на основе иерархической функциональной структуры,

которую невозможно объективно оценить, описание на основе процессов позволяет точно

представить цели, характеристики (в том числе, динамические) и конечный результат каждого вида

деятельности организации.

Исходя из того, что основные бизнес-процессы реализуют по своей природе цели и задачи

организации, методология предлагает строить описание деятельности организации, как процесс

создания и развития систем согласованных моделей, основанных на моделях бизнес-процессов. В

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

всех функциональных свойств, отражающих цели и задачи организации, и согласованности

моделей. Такая согласованность обеспечивается методологией и поддерживающими ее

современными CASE-средствами.

В процессе описания организации и ее деятельности формируются три основных системы

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

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

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

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

создании ИС.

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

Метод SADT (Structured Analysis and Design Technique) разработан в 1973 г . Дугласом

Россом (SoftTech, Inc.). Успешно использовался в военных, промышленных и коммерческих

организациях США. Метод поддерживается Министерством обороны США, которое было

инициатором разработки стандарта IDEF0 (Icam DEFinition) - подмножества SADT, являющегося

основной частью программы ICAM (Integrated Computer Aided Manufacturing - интегрированная

компьютеризация производства). Более того, среди менеджеров и руководителей компьютерных

фирм считается, чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-

либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для

построения функциональной модели объекта (производимые им действия - работы - и связи между

ними).

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

отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых

результатов. Основными объектами диаграмм являются:

• функция - некоторое действие ЭИС, необходимое для решения экономической задачи.

• декомпозиция функции - разбиение функции на множество подфункций.

Система разбивается на функциональные подсистемы , которые делятся на подфункции, те -

на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет

целостное представление.

Метод основан на следующих концепциях :

• графическое представление блочного моделирования;

• строгость и точность;

• отделение организации от функции (исключение влияния административной структуры на

функциональную модель).

Диаграммы - главные компоненты модели, на которых в виде блоков и дуг представлены все

функции (работы) организации и интерфейсы.

Работы - поименованные процессы, функции или задачи, которые происходят в течение

определенного времени и имеют распознаваемые результаты. Изображаются в виде

прямоугольников. Имя работы выражается отглагольным существительным.

Построение SADT-модели начинается с представления всей системы в виде контекстной

диаграммы . Контекстная диаграмма представляет самое общее описание системы и ее

взаимодействия с внешней средой. Имеет вид одного блока и дуг, изображающих набор внешних

интерфейсов системы. Затем проводится разбиение системы на крупные фрагменты

(функциональная декомпозиция). Декомпозиция выявляет полный набор подфункций, каждая из

которых показана как блок с интерфейсными стрелками. Каждая подфункция может быть

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

декомпозиции.

Специалисты, традиционно занимавшиеся созданием крупномасштабных систем, стали

осознавать необходимость большей упорядоченности. Таким образом, разработчики решили

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

 Анализ — определение того, что система будет делать,

 Проектирование — определение подсистем и их взаимодействие,

 Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в

единое целое,

 Тестирование — проверка работы системы,

 Установка — введение системы в действие,

 Эксплуатация — использование системы.

Современный уровень информационных технологий предоставляет богатый выбор методов

для создания автоматизированной поддержки SADT. Наиболее доступным на сегодняшний день

SADT-средством является Design/IDEF (Meta Software Corp.) — изначально построенный в рамках

программы интегрированной компьютеризации производства и широко используемый ныне в

различных областях деятельности. Автоматизированная поддержка SADT происходит в развитии от

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

более общих понятий моделирования.