IDEF0 - стандарт и методология функционального моделирования

IDEF0 - стандарт и методология  функционального моделирования

 

Моделирование сложных систем (какими являются современные промышленные системы) было начато в программе  интегрированной автоматизации  производства (ICAM - (Integrated Computer Aided Manufacturing) Министерства обороны США в которой была признана полезность методологии SADT (Structured Analysis and Design Technique - Технология структурного анализа и проектирования) введенной в 1973 году Россом, что привело к стандартизации и публикации ее части, называемой IDEF0 (IDEF=ICAM DEFinition или Integration Definition for Function Modeling). C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 году – IDEF0 был принят в качестве стандарта в Российской Федерации.

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

1. Функциональный блок (Activity Box). Функциональный блок графически изображается в виде прямоугольника и представляет собой некоторую конкретную функцию в моделируемой системы. Название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

 

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

 

Верхняя сторона имеет  значение “Управление” (Control);

Левая сторона имеет значение “Вход” (Input);

Правая сторона имеет  значение “Выход” (Output);

Нижняя сторона имеет  значение “Ресурсы” (Mechanism).

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

 

 

2. Интерфейсная стрелка  - интерфейсная дуга, поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

 

Интерфейсная стрелка  «вход» (Input).

 

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

 

Интерфейсная стрелка  «управление» (Control).

 

Интерфейсная стрелка  «управление» управляет преобразованием  входа в выход. Каждый функциональный блок должен иметь по крайней мере одну управляющую интерфейсную стрелку. Интерфейсная стрелка «управление» изображается вверху прямоугольника действия и направлена на него. «Управление» осуществляется в форме регламентов, стандартов, процедур или технической документации. 

 

Интерфейсная стрелка  «ресурс» (Mechanism)

 

Интерфейсная стрелка  «Ресурсы» – обозначает те ресурсы, которые требуются для преобразования входа в выход. Ресурсами могут  являться, например, люди, машины и оборудование. Интерфейсная стрелка «ресурс» не является обязательной.

 

Интерфейсная стрелка  «выход» (Output)

 

Выход – это материалы  или информация, производимая функциональным блоком из входа. Каждое действие должно иметь, по крайней мере одну интерфейсную стрелку «выход». 

 

Интерфейсные стрелки  ссылки (Call Arrow).

 

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

 

Обязательное наличие  управляющих интерфейсных стрелок  является одним из главных отличий  стандарта IDEF0 от других методологий  классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

 

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

 

Модель IDEF0 всегда начинается с представления системы как  единого целого – одного функционального  блока с интерфейсными стрелками, простирающимися за пределы рассматриваемой  области. Такая диаграмма с одним  функциональным блоком называется контекстной  диаграммой, и обозначается идентификатором  “А-0”.

 

Цель

 

Ни одна модель не может  быть создана без конкретного  объекта или цели. Формулировка цели должна ответить на следующие вопросы:

 

почему был смоделирован представленный процесс;

что эта модель собирается показать;

что с ней могут сделать  читающие ее.

Формулировка цели позволяет  команде экспертов придерживаться ее на протяжении всего процесса моделирования. Без формулировки цели моделирование  может зайти в тупик.

 

Модели создаются для  получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой  для создания цели модели. Примерные  вопросы могут звучать следующим  образом:

 

каковы основные задачи сотрудника;

кто отвечает за произведенную  продукцию;

кто управляет начальной  стадией производства;

какой требуется инструмент для каждого этапа.

Точка зрения (Viewpoint). 

 

Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке  зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (англ. FEO, For Exposition Only. Русс. --- только для комментариев).

 

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

 

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

 

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

 

В пояснительном тексте к  контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

 

Определение и формализация цели разработки и точки зрения IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие  области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет  разгрузить модель, отказавшись от детализации и исследования отдельных  элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему.

 

Диаграммы IDEF0 второго уровня называются дочерней (Child diagram) по отношению к первому (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram).

 

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

 

Туннели (Tunnels).

 

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

 

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

 

 

 

 

 

 

 

ЖИЗНЕННЫЙ ЦИКЛ ИС

В основе деятельности по созданию и использованию ИТ лежит понятие ЖЦ, которое является одним из базовых понятий методологии проектирования САПР и многих других ИС. В настоящее время существует ряд общих методологий разработки ИС. Главное в них - единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС.

 

В общем случае под термином жизненный цикл системы ( System Life Cycle ) понимается определенная эволюция, период времени и совокупность работ, меняющих состояние системы от появления замысла и начала ее разработки до окончания эксплуатации. Обычно разбивается на отдельные стадии — анализ требований, проектирование, реализация (конструирование), верификация и эксплуатация. Стадии ЖЦ системы могут повторяться итерационным образом в связи с постепенным уточнением требований к системе и/или с необходимостью ее адаптации к тем изменениям, которые возникают в предметной области системы.

 

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

 

ЖЦ ИС - это период времени  и совокупность работ, от момента  возникновения и обоснования  необходимости создания до момента  нецелесообразности дальнейшей ее эксплуатации, т.е. это совокупность взаимосвязанных  процессов создания и последовательного  изменения состояния ИС, меняющих состояние системы, от формирования исходных требований к ней до окончания  эксплуатации и утилизации комплекса  средств автоматизации ИС. Обычно разбивается на отдельные стадии - анализ требований, проектирование, реализация (конструирование), верификация и эксплуатация. Стадии жизненного цикла системы могут повторяться итерационным образом в связи с постепенным уточнением требований к системе и/или с необходимостью ее адаптации к тем изменениям, которые возникают в предметной области системы. Такой цикл проходят все технические, технологические и иные информационные системы и в каждом случае они должны быть экономически обоснованы и привязаны к конкретным условиям производства.

 

По стандарту ISO/IEC 12207 ЖЦ ИС базируется на трех группах процессов:

 

основные процессы ЖЦ ИС: приобретение, поставка, разработка, эксплуатация, сопровождение. Разработка ИС состоит  из трех этапов: анализ, проектирование и реализацию (программирование)

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

организационные процессы: управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение  самого ЖЦ, обучение.

Модель ЖЦ ИС, как и  модель ЖЦ изделия, разрабатывается  на основе анализа создаваемого ПО для процесса проектирования нового изделия, и включает в себя набор этапов и связей между ними. Жизненный цикл ИС образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т.п., что приводит к изменениям в проектных решениях, выработанных на более ранних этапах.

 

Опыт создания и использования  стандартных моделей ИС позволяет  условно выделить следующие основные этапы жизненного цикла:

 

стратегическое планирование;

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

разработка методики проектирования (предварительного и детального) ИС в целом и ее компонент. Определение  того, как система будет делать то, что она должна делать. Проектирование это спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;

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

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

внедрение - установка и  ввод системы в действие;

эксплуатация (использование) - - работы по подготовке к внедрению  компонентов ИС в эксплуатацию К  основным направлениям деятельности следует  отнести :

конфигурирование базы данных;

конфигурирование рабочих  мест пользователей;

обеспечение эксплуатационной документацией;

проведение обучения персонала;

локализация проблем и  устранение причин их возникновения;

модификация ИС в рамках установленного регламента;

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

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

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

 

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

 

 

 

 

 

 

 

 

 

 

 

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

Содержание   [убрать]  1 Стандарты жизненного цикла ПО 2 Стандарт ГОСТ 34.601-90 3 Стандарт ISO/IEC 12207/ и его применение 4 Процессы жизненного цикла ПО 5 Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями 6 Модели жизненного цикла ПО 6.1 Водопадная (каскадная, последовательная) модель 6.2 Итерационная модель 6.3 Спиральная модель 7 Методологии разработки ПО 8 Литература 9 Примечания

[править]Стандарты жизненного цикла ПО

• ГОСТ 34.601-90
• ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99)

[править]Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. Формирование требований к АС
1. Обследование объекта и обоснование необходимости создания АС
2. Формирование требований пользователя к АС
3. Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
1. Изучение объекта
2. Проведение необходимых научно-исследовательских работ
3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
4. Оформление отчета о проделанной работе
3. Техническое задание
1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект
1. Разработка предварительных проектных решений по системе и ее частям
2. Разработка документации на АС и ее части
5. Технический проект
1. Разработка проектных решений по системе и ее частям
2. Разработка документации на АС и ее части
3. Разработка и оформление документации на поставку комплектующих изделий
4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
1. Разработка рабочей документации на АС и ее части
2. Разработка и адаптация программ
7. Ввод в действие
1. Подготовка объекта автоматизации
2. Подготовка персонала
3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
4. Строительно-монтажные работы
5. Пусконаладочные работы
6. Проведение предварительных испытаний
7. Проведение опытной эксплуатации
8. Проведение приемочных испытаний
8. Сопровождение АС.
1. Выполнение работ в соответствии с гарантийными обязательствами
2. Послегарантийное обслуживание

Эскизный, технический проекты  и рабочая документация — это  последовательное построение все более  точных проектных решений. Допускается  исключать стадию «Эскизный проект»  и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация»  в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

[править]Стандарт ISO/IEC 12207/ и его применение

Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

[править]Процессы жизненного цикла ПО

• Основные:
• Приобретение (действия и задачи заказчика, приобретающего ПО)
• Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
• Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
• Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)
• Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
• Вспомогательные
• Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
• Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
• Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
• Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
• Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
• Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
• Аудит (определение соответствия требованиям, планам и условиям договора)
• Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
• Организационные
• Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
• Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
• Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
• Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

1. Инициирование приобретения
2. Подготовка заявочных предложений
3. Подготовка и корректировка договора
4. Надзор за деятельностью поставщика
5. Приемка и завершение работ

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

1. Формирование требований к системе
2. Формирование списка программных продуктов
3. Установление условий и соглашений
4. Описание технических ограничений (среда функционирования системы и т. д.)

[править]Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;
2. Результаты выполнения работ на каждой стадии;
3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут  выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

[править]Модели жизненного цикла ПО

[править]Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.

Преимущества:

• Полная и согласованная документация на каждом этапе;
• Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход  от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[3].