Проектирование информационных систем методология idef0. Методология функционального моделирования idef0

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

Определение

IDEF 0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

IDEF 0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей.

Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

Применение IDEF0

IDEF0 используется для создания функциональной модели , то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0.

Функциональная модель – это структурное представление функций, деятельности или процессов в пределах моделируемой системы или предметной области.

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

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

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

Цели стандарта IDEF0

Основные цели (objectives) стандарта:

задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;

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

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

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

общий (generic) – для анализа систем и предметных областей;

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

краткий (concise) – для облегчения понимания, коммуникации, согласия между заинтересованными лицами и проверки. (to facilitate understanding, communication, consensus and validation);

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

гибкий – для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision)

Правила IDEFØ требуют достаточной строгости и точности для удовлетвроения нужд без чрезмерных ограничений аналитика (to satisfy needs without overly constraining the analyst). IDEFØ правила включают следующее:

управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпозиции;

связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей;

связанность интерфейса диаграмм (Diagram Interface Connectivity) – номера узлов, функциональных блоков, C-numbers и Detail Reference Expression);

связанность структуры данных. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий;

синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;

ограничения на разветвления стрелок данных (Data Arrow Branch Constraint) – метки для ограничений потоков данных на разветвлениях;

разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);

маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);

наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;

цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

Основные понятия IDEF0

В основе методологии лежат четыре основных понятия:

функциональный блок;

интерфейсная дуга;

декомпозиция;

глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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

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

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

левая сторона имеет значение «Вход» (Input);

правая сторона имеет значение «Выход» (Output);

нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. Функциональный блок

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

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

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

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

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

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

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

Последним из понятий IDEF0 является глоссарий (Glossary).

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

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

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

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

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

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

Определение

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

Применение IDEF0

Цели стандарта IDEF0

Основные цели (objectives) стандарта:

задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;

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

общий (generic) – для анализа систем и предметных областей;

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

гибкий – для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision)

связанность структуры данных. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий;

синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;

разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);

маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);

наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;

цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

Основные понятия IDEF0

В основе методологии лежат четыре основных понятия:

функциональный блок;

интерфейсная дуга;

декомпозиция;

глоссарий.

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

левая сторона имеет значение «Вход» (Input);

правая сторона имеет значение «Выход» (Output);

нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. Функциональный блок

Последним из понятий IDEF0 является глоссарий (Glossary).

Одна картинка стоит тысячи слов

Народная мудрость

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

Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об IT системе от лида до заявки. Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.

Несколько слов о преимуществах графики

Как известно, функциональные модели IDEF0 - это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

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

А потому идея Сытина была поистине революционной - он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.

Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERP-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену - это и правда очень сложно.

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

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

Почему это важно для моей работы

Моя работа всегда связана с внесением изменений в существующую систему. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.

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

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

Типичные ошибки

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

Использование различных цветов

Все элементы на диаграмме одинаково важны. При функциональном моделировании нет более или менее важных элементов. Исчезновение любого приведет к нарушению процесса и производственному браку.

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

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

Слишком большое количество блоков

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

Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

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

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема - это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

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

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

Еще статьи по данной теме.

Методология функционального моделирования IDEF0 - это технология описания системы в целом как множества взаимозависимых действий, или функций. Важно отметить функциональную направленность IDEF0 - функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. "Функциональная" точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее физической реализации. На рисунке 3 приведен пример типовой диаграммы IDEF0.

Наиболее часто IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта, до IDEF3 моделирования для сбора данных и моделирования процесса "как есть". Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.

Синтаксис и семантика моделей IDEF0

Модели IDEF0

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

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

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

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

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

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

Действия

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

Пример функционального блока приведен на рисунке 2.1.

Рисунок 2.1 – Функциональный блок IDEF0

Выше мы определяли IDEF0 модели как иерархическое множество вложенных блоков. Любой блок может быть декомпозирован на составляющие его блоки. Декомпозицию часто ассоциируют с моделированием "сверху вниз", однако это не совсем верно. Функциональную декомпозицию корректнее определять как моделирование "снаружи вовнутрь", в котором мы рассматриваем систему наподобие луковицы, с которой последовательно снимаются слои.

Границы и связи

Чтобы быть полезным, описание любого блока должно, как минимум, включать в себя описание объектов, которые блок создает в результате своей работы ("выхода"), и объектов, которые блок потребляет или преобразует ("вход").

В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения - объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе.

I (Input) - вход - нечто, что потребляется в ходе выполнения процесса;

С (Control) - управление - ограничения и инструкции, влияющие на ход выполнения процесса;

О (Output) - выход - нечто, являющееся результатом выполнения процесса;

М (Mechanism) - исполняющий механизм - нечто, что используется для выполнения процесса, но не потребляется само по себе. Рисунок 2.2 показывает 4 возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока.

Рисунок 2.2 - Каждый тип стрелки соединяется со своей

стороной функционального блока

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

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

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

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

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

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

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

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

Комбинированные стрелки . В IDEF0 существует пять основных видов комбинированных стрелок: выход - вход, выход - управление, выход - механизм исполнения, выход - обратная связь на управление и выход - обратная связь на вход.

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

Рисунок 2.3 - Комбинация стрелок выход - вход

Стрелка выход - управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. На рисунке 2.4 принципы формирования инвестиционного портфеля управляют поведением брокеров на бирже.

Рисунок 2.4 - Комбинированная стрелка выход - управление

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

Рисунок 2.5 - Комбинированная стрелка выход - механизм исполнения

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

Рисунок 2.6 - Комбинированная стрелка выход - обратная связь на управление

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

Рисунок 2.7 - Комбинированная стрелка выход - обратная связь на вход

Разбиение и соединение стрелок . Выход функционального блока может использоваться в нескольких других блоках. Фактически чуть ли не главная ценность IDEF0 заключается в том, что эта методология помогает выявить взаимозависимости между блоками системы. Соответственно IDEF0 предусматривает как разбиение, так и соединение стрелок на диаграмме. Разбитые на несколько частей стрелки могут, иметь наименования, отличающиеся от наименования исходной стрелки. Исходная и разбитые (или объединенные) стрелки в совокупности называются связанными. Такая техника обычно применяется для того, чтобы отразить использование в процессе только части сырья или информации, обозначаемых исходной стрелкой (рисунок 2.8). Аналогичный подход применяется и к объединяемым стрелкам.

Рисунок 2.8 - Разбитая на две части и переименованная стрелка

Туннели

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

Рисунок 2.9 - Пример применения туннеля

Построение моделей IDEF0

В этом подразделе мы рассмотрим методику построения моделей IDEF0 более подробно.

Диаграммы

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

Рисунок 2.10 - IDEF0-диаграмма со служебной информацией на полях

Все элементы заголовка диаграммы перечислены в таблице 2.1.

Таблица 2.1 - Элементы заголовка диаграммы IDEF0

Поле	Назначение
USED AT	Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную)
Author, date, project	Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась
Notes 1…10	При ручном редактировании программ пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное изменение
Status	Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации я шагами пересмотра и утверждения
Working	Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы
Draft	Диаграмма достигла некоторого приемлемого для читателей уровня и готова для предоставления на утверждение
Recommended	Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся
Publication	Диаграмма готова для окончательной печати и публикации
Reader	ФИО читателя
Date	Дата знакомства читателя с диаграммой
Context	Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данный диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР

Все элементы "подвала" диаграммы перечислены в таблице 2.2.

Таблица 2.2 - Элементы "подвала" диаграммы IDEF0

Поле	Назначение
Node	Номер диаграммы, совпадающий с номером родительского функционального блока
Title	Имя родительского функционального блока
Number (еще называют C-Number)	Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например, SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDJ005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели.

Построение моделей

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

· Почему моделируется данный процесс?

· Что выявит данная модель?

· Как ознакомившиеся с этой моделью смогут ее применить?

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

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

· Каковы задачи менеджера?

· Каковы задачи клерка?

· Кто контролирует работу?

· Какая технология нужна для выполнения каждого шага? и т.п.

Точка зрения

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

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

Границы моделирования

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

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

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

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

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

Постоянное усложнение производственно-технических и организационно-экономических систем – фирм, предприятий, производств и других субъектов производственно-хозяйственной деятельности – и необходимость их анализа с целью совершенствования функционирования и повышения эффективности обусловливают необходимость применения специальных средств описания и анализа таких систем. Эта проблема приобретает особую актуальность в связи с появлением интегрированных компьютеризированных производств и автоматизированных предприятий.
В США в конце 70-х годов была предложена и реализована Программа интегрированной компьютеризации производства ICAM – Integrated Computer Aided Manufacturing, направленная на увеличение эффективности предприятий посредством широкого внедрения компьютерных (информационных) технологий.
Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология моделирования IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

Методология IDEF

Общая методология IDEF состоит из трех частных методологий моделирования, основанных на графическом представлении систем:
IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями;
IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы;
IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы.
К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X).
Методология IDEF0, особенности и приемы применения которой описываются в настоящих рекомендациях, основана на подходе, получившем название
SADT – Structured Analysis & Design Technique – метод структурного анализа и проектирования. Основу этого подхода и методологии IDEF0 составляет графический язык описания (моделирования) систем.

Общие понятия

Модель IDEF0: Графическое описание системы, разработанное с определенной целью и с выбранной точки зрения. Комплект документов IDEF0, которые изображают функции системы с помощью графики (диаграмм), текста и глоссария.
Цель: краткая формулировка причины создания модели.
Точка зрения: указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель. Для каждой модели точка зрения единственная.
Глоссарий: Список определений для ключевых слов, фраз и аббревиатур, связанных с узлами, блоками, стрелками или с моделью IDEF0 в целом.
Текст: Любой текстовый (не графический) комментарий к графической диаграмме IDEF0.
Примечание к модели: текстовый комментарий, являющийся частью диаграммы IDEF0 и используемый для записи факта, не нашедшего графического изображения.
Функция: деятельность, процесс или преобразование (моделируемые блоком IDEF0), идентифицируемое глаголом или глагольной формой, которая описывает, что должно быть выполнено.
Декомпозиция: разделение моделируемой функции на функции-компоненты.

Пример контекстной диаграммы

Диаграмма

Диаграмма: часть модели, описывающая декомпозицию блока.
Контекст: Окружающая среда, в которой действует функция (или комплект функций на диаграмме).
Контекстная диаграмма: диаграмма, имеющая узловой номер А–n (А минус n), которая представляет контекст модели. Диаграмма А–0, состоящая из одного блока, является необходимой (обязательной) контекстной диаграммой; диаграммы с узловыми номерами А–1, А–2, ..., – дополнительные контекстные диаграммы (n > 0). Диаграмма А–0 (А минус ноль): Специальный вид (контекстной) диаграммы IDEF0, состоящей из одного блока, описывающего функцию верхнего уровня, ее входы, выходы, управление, и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель.
Дочерняя диаграмма: диаграмма, детализирующая родительский (порождающий) блок.
Родительская диаграмма: диаграмма, которая содержит родительский блок.
Узловая ссылка: код, присвоенный диаграмме для ее идентификации и определения положения в иерархии модели; формируется из сокращенного имени модели и узлового номера диаграммы с дополнительными расширениями.
Узловой номер диаграммы: часть узловой ссылки диаграммы, которая соответствует номеру родительского блока.

Декомпозиция

На контекстной диаграмме А–0 объект моделирования представлен единственным блоком с граничными стрелками, отображающими связь объекта моделирования
с окружающей средой.

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

Блок

Блок: прямоугольник, содержащий имя и номер и используемый для описания функции.

Номер блока: число (0–6), помещаемое в правом нижнем углу блока и однозначно идентифицирующее блок на диаграмме.

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

Дочерний блок: блок на дочерней (порожденной) диаграмме.

Родительский блок: блок, который подробно описывается дочерней диаграммой.

Для блоков установлены следующие синтаксические правила:

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

Блоки должны быть прямоугольными, с прямыми углами;

Блоки должны быть нарисованы сплошными линиями.

Узел

Узел: блок, порождающий дочерние блоки; родительский блок.

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

Дерево узлов: Представление отношений между родительскими и дочерними узлами модели IDEF0 в форме древовидного графа. Имеет то же значение и содержание, что и перечень узлов.

Перечень узлов: список, часто ступенчатый, показывающий узлы модели IDEF0 в упорядоченном виде. Имеет то же значение и содержание, что и дерево узлов.

Стрелка

Стрелка: Направленная линия, состоящая из одного или нескольких сегментов, которая моделирует открытый канал или канал, передающий данные или материальные объекты от источника (начальная точка стрелки), к потребителю (конечная точка с «наконечником»). Входная стрелка: класс стрелок, отображающих вход IDEF0-блока, то есть данные или материальные объекты, которые преобразуются функцией в выход. Входные стрелки связываются с левой стороной блока IDEF0. Выходная стрелка: класс стрелок, отображающих выход IDEF0 -блока, то есть данные или материальные объекты, произведенные функцией. Выходные стрелки связываются с правой стороной блока IDEF0. Стрелка механизма: Класс стрелок, которые отображают механизмы IDEF0, то есть средства, используемые для выполнения функции; включает специальный случай стрелки вызова. Стрелки механизмов связываются с нижней стороной блока IDEF0. Управляющая стрелка: Класс стрелок, которые в IDEF0 отображают управления, то есть условия, при выполнении которых выход блока будет правильным. Данные или объекты, моделируемые как управления, могут преобразовываться функцией, создающей соответствующий выход. Управляющие стрелки связываются с верхней стороной блока IDEF0.

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

Внутренняя стрелка: входная, управляющая или выходная стрелка, концы которой связывают источник и потребителя, являющиеся блоками одной диаграммы. Отличается от граничной стрелки. Граничная стрелка: стрелка, один из концов которой связан с источником или потребителем, а другой не присоединен ни к какому блоку на диаграмме. Отображает связь диаграммы с другими блоками системы и отличается от внутренней стрелки. Сегмент стрелки: сегмент линии, который начинается или заканчивается на стороне блока, в точке ветвления или слияния, или на границе (несвязанный конец стрелки). Ветвление: разделение стрелки на два или большее число сегментов. Слияние: объединение двух или большего числа сегментов стрелок в один сегмент. Связывание/развязывание: Объединение значений стрелок в составное значение (связывание в «пучок»), или разделение значений стрелок (развязывание «пучка»), выраженные синтаксисом слияния или ветвления стрелок. Тильда: небольшая ломаная (волнистая) линия, используемая для соединения метки с конкретным сегментом стрелки или примечания модели с компонентом диаграммы. Код ICOM: код, обеспечивающий соответствие граничных стрелок дочерней диаграммы со стрелками родительского блока; используется для ссылок (аббревиатура ICOM расшифровывается как Input – вход, Control – управление, Output – выход, Mechanism – механизм).

Семантика блоков и стрелок

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

Для стрелок установлены следующие синтаксические правила: - Ломаные стрелки изменяют направление только под утлом 90°; - Стрелки должны быть нарисованы сплошными линиями.
Можно использовать линии различной толщины; - Стрелки могут состоять только из вертикальных или горизонтальных отрезков.
Отрезки, направленные по диагонали, не допускаются; - Концы стрелок должны касаться внешней границы функционального блока,
но не должны пересекать ее;

Стрелки должны присоединяться к блоку на его сторонах.
Присоединение в углах не допускается.