IDEF0 (Integration Definition for Function Modeling) — стандартизированная методология функционального моделирования: система как множество взаимосвязанных функций с ролями дуг ICOM (Inputs, Controls, Outputs, Mechanisms). Нотация отвечает на вопрос что делает система, что в неё поступает, что получается на выходе, при каких ограничениях и с помощью каких ресурсов — без привязки ко времени.

В ветке «Описание бизнес-процессов» IDEF0 закрывает функции и ICOM; последовательность действий — в 03.04.01 BPMN 2.0 - введение и основы, движение данных — в 03.04.02 Диаграмма потоков данных (DFD). Модель данных в эту же статью не входит: для сущностей и атрибутов используйте 03.03.01 ER-диаграммы (сущность-связь) или DFD; в семействе IDEF за данные отвечает IDEF1X — отдельный стандарт, в базе не разбирается. Динамика процессов — 03.04.01 BPMN 2.0 - введение и основы или 03.04.04 Цепочка создания ценности (VAD) и EPC; IDEF3 (Process Flow Description) вне scope базы.

Методология выросла из SADT и была принята как федеральный стандарт США (FIPS 183, ныне withdrawn; актуальная спецификация — ISO/IEC/IEEE 31320-1:2012, см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)). В российских проектах IDEF0 часто применяют на стадии предпроектного обследования и разработки концепции ИС — особенно в госсекторе и промышленности, в связке с 05.01 Waterfall и V-model и 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

1. Суть темы

IDEF0 описывает функциональную архитектуру — не исполняемый процесс и не поток данных. Модель строится сверху вниз: от контекстной диаграммы A-0 (дефис только у контекста) через декомпозицию A0 к дочерним уровням (A1, A11, A12…). Главная сила нотации — строгая иерархия с правилом балансировки дуг между уровнями и однозначной классификацией каждой дуги по ICOM.

Системный аналитик применяет IDEF0, чтобы зафиксировать функции «как есть» (as-is) и спроектировать целевое состояние «как должно быть» (to-be), обеспечив прослеживаемость к 02.03.03 Спецификация требований (SRS, Use Case, User Story) и 02.03.04 Трассировка требований (концепция): блок A12 → функциональное требование, прецедент use case или модуль/сервис (см. §3). В Agile IDEF0 встречается редко в ежедневных спринтах — чаще на этапе обследования, концепции или согласования scope; см. 05.02 Scrum и Kanban (аналитик в Agile).

Один объект системы может иметь несколько моделей при разных целях и точках зрения (viewpoint): для заказчика — «Управлять заказами», для ИТ — «Интегрировать с ERP». Цель и viewpoint фиксируют на A-0 текстом рядом с диаграммой — это не «единственная истина», а выбранное представление; связь с 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).

IDEF0 vs Context Diagram — когда что выбирать

03.01.02 Моделирование контекста системы (Context Diagram) и A-0 IDEF0 оба показывают систему как «чёрный ящик» на границе. Различие — в глубине и следующем шаге:

КритерийContext DiagramIDEF0 A-0 и далее
Цель артефактаЗафиксировать кто обменивается с системой и какими потокамиЗафиксировать функцию системы и роли каждого потока (ICOM), затем декомпозировать
Нужна иерархия функцийНетДа — A0, A1… с балансировкой
АудиторияАрхитекторы, интеграции, быстрый контекстТЗ, обследование, регламенты; заказчик и аналитик на воркшопах
Тип проектаПродуктовая разработка, API, интеграционный контурГОСТ 34, промышленность, legacy с пакетом функциональных моделей

Практическое правило: если достаточно показать внешние акторы и потоки без классификации ICOM и без декомпозиции — Context Diagram в 03.01.02 Моделирование контекста системы (Context Diagram). Если дальше нужны уровни функций, управляющие связи и трассировка к требованиям/модулям — стартуйте с A-0 IDEF0. Модели можно согласовать: потоки Context Diagram часто становятся входами или выходами A-0 после уточнения роли.

2. Ключевые понятия

Функциональный блок и ICOM

Блок — прямоугольник с глагольным описанием функции («Обработать заказ»). Нумерация иерархическая: A-0 — контекст (единственный уровень с дефисом), A0 — первая декомпозиция, A1, A2… — детализация выбранного блока, A11, A12… — следующий уровень. Блоки располагают по доминантности (dominance): функции, инициирующие или управляющие другими, — выше и левее; это не хронология и не метрика «важности».

Тип дугиПозиция у блокаСмыслПримеры
Вход (Input)Левая граньДанные или объекты, преобразуемые функциейЗаказ клиента, сырьё, заявление
Управление (Control)Верхняя граньПравила, ограничения, политики, регламентирующие выполнениеЗаконодательство, регламент, стандарты качества
Выход (Output)Правая граньРезультат выполнения функцииГотовый продукт, обработанный заказ, отчёт
Механизм (Mechanism)Нижняя граньРесурсы вне преобразования: исполнители и инструментыПерсонал, оборудование, ПО

Один объект может играть разные роли для разных блоков: «Чертёж» — выход проектирования и управление для производства. Дуги подписывают существительным, без глаголов.

Граница системы и механизмы

На A-0 все дуги I, C, O — это граница модели: то, что входит в систему, управляет ею или выходит из неё. Механизмы снизу — за границей: персонал, оборудование и прикладное ПО — внешние ресурсы, которые система использует, но не «перерабатывает». Это согласуется с 02.01.04 Определение границ решения (Scope Modelling): функция «Обработать заказ» внутри границы; «Персонал и система» на схеме — не часть блока, а ресурс снаружи. Если механизм — целевая ИС проекта, на A-0 часто один агрегированный механизм «Целевая система и персонал»; детализацию модулей переносят на декомпозицию или в 03.01.03 Декомпозиция системы на подсистемы и модули.

Control vs Input — пограничные случаи

СитуацияКлассификацияПочему
Нормативный документ, по которому сверяют результат, но не «перерабатывают»ControlЗадаёт правила, не является материалом преобразования
Пакет данных, который блок изменяет и передаёт дальшеInputПреобразуется функцией
Справочник, из которого выбирают значение без изменения справочникаControl (или Input — по соглашению команды)Если справочник только ограничивает выбор — Control; если блок формирует новую версию справочника — Input
База знаний с шаблонами решений и правилами эскалацииControlНорматив содержимого и критерии; блок руководствуется БЗ, не «перерабатывает» её как заявку
SLA как порог качестваControlОграничивает допустимый результат
Заявка клиентаInputОсновной объект обработки

При сомнении задайте вопрос: «Функция преобразует этот объект или руководствуется им?» Преобразует — Input; руководствуется — Control.

Иерархия и балансировка

УровеньСодержание
A-0 (контекст)Один блок — вся система; все внешние дуги I/C/O определяют границу («чёрный ящик»)
A0Первая декомпозиция на 3–6 функций; периметр совпадает с ICOM родителя — новых внешних дуг без обоснования на родителе быть не должно
A1, A2…Детализация выбранного блока (A1 → A11, A12, A13)

Правило балансировки: каждая дуга родительского блока должна быть отражена на дочерней диаграмме — как граничная (interface) дуга на периметре или как сумма внутренних потоков между подблоками. Внутренние потоки (output A1 → input A2) не расширяют периметр: они детализируют, как родительский I/C/O проходит через подфункции.

Пример на двух уровнях. На A-0 блок «Обработать заказ»: вход «Заказ клиента», управление «Регламент обработки», выход «Выполненный заказ», механизм «Персонал и система». На A0 те же четыре граничные дуги на периметре: «Заказ клиента» слева → A1; «Регламент» сверху → fork на A1 и A2; «Выполненный заказ» справа ← join из A3; «Персонал и система» снизу → A1, A2, A3. Между A1, A2, A3 — только внутренние связи («Результат проверки», «Скомплектованный заказ»); они не появляются на A-0. Если на A1 детализируете «Проверить наличие» → A11, A12, A13, вход «Заказ клиента» снова — граничная дуга слева A1 без «нового» внешнего входа.

Граничные дуги (interface arrows) на дочерней диаграмме — те же имена, что у родителя; читайте модель «снаружи внутрь»: периметр дочерней диаграммы = ICOM родительского блока.

Связи между блоками на одном уровне

Передача output → input между соседними блоками на одном уровне декомпозиции допустима и описывает функциональную зависимость («результат A1 — вход A2»). Это не временная последовательность BPMN: IDEF0 не фиксирует «сначала — потом», порядок блоков определяется доминантностью, а не календарём. Для динамики и событий — 03.04.01 BPMN 2.0 - введение и основы или 03.04.04 Цепочка создания ценности (VAD) и EPC.

Fork и join на дугах

  • Fork: одна входная или управляющая дуга родителя разветвляется на несколько блоков (один «Регламент» → A1 и A2).
  • Join: несколько потоков сливаются в одну граничную дугу родителя — для выходов (A11 и A12 → «Выполненный заказ» на периметре), для входов (несколько источников → одна граничная входная дуга) и для управлений (несколько регламентов → одна граничная Control после согласования с родителем).

Имена при fork/join сохраняют трассировку: либо та же метка, что у родителя, либо явное пояснение в глоссарии модели.

Особые виды дуг

  • Дуги вызова (call arrows) — связывают блок с дочерней диаграммой детализации (навигация: «этот блок раскрывается на A1»), а не поток данных между равноправными блоками на одном листе.
  • Туннельные дуги — скрывают промежуточную детализацию на родительском уровне, когда внутренний путь очевиден; помечаются скобками у границы. Применяйте, если полная прорисовка засоряет родительский лист, но балансировка на дочернем уровне сохранена.

Правила построения

  • На одной диаграмме 3–6 блоков (оптимально 3–4).
  • Уникальные имена блоков и дуг в рамках диаграммы.
  • Дуги — строго горизонтально или вертикально, углы 90°.
  • Нельзя объединять входные и управляющие дуги в одну стрелку.

3. Как применяется в работе аналитика

IDEF0 уместна, когда нужно:

  • понять функциональную структуру предприятия или ИС перед автоматизацией;
  • определить границы проекта на A-0 (02.01.04 Определение границ решения (Scope Modelling));
  • выявить управляющие и информационные связи для последующей детализации в DFD или BPMN;
  • подготовить регламентирующие документы и обучить персонал архитектуре функций.

Модель строят на 02.02.02 Воркшопы, фасилитация и совместные сессии; для legacy и госсектора — дополняют 02.02.03 Наблюдение и анализ документов (регламенты, старые ТЗ). Перед сдачей проверяют ICOM и балансировку по чеклисту, аналогично 08.04 Рецензирование и инспекции (техники Фейгана).

Модели as-is и to-be

Типичный deliverable в 05.01 Waterfall и V-model и проектах по ГОСТ — две согласованные иерархии:

  1. As-is — текущие функции и ICOM; фиксирует baseline для обследования.
  2. To-be — целевая архитектура после автоматизации или реорганизации.

Ведите модели в одном инструменте с версионированием (07.05 Системы контроля версий (Git) для документации) или явными метками листов «AS-IS / TO-BE». Согласование delta: для каждого изменившегося блока — что добавлено, удалено или перенесено; изменения на A-0 (новый вход/выход) тянут пересмотр scope и 02.03.04 Трассировка требований (концепция). Не смешивайте as-is и to-be на одной диаграмме без легенды — это типичный источник споров на приёмке.

Трассировка к артефактам SA

Элемент IDEF0Куда трассируется
Блок A1…An (глагольная функция)Функциональное требование; прецедент на 03.02.01 Диаграмма прецедентов (Use Case Diagram) (функция ≈ use case, внешние акторы — источники I/O на A-0)
Граничный вход/выход A-0Интерфейс системы; контракт интеграции (03.01.04 Интерфейсы и интеграционные взаимодействия)
Подблок нижнего уровня (A12)Модуль, сервис, компонент (03.01.03 Декомпозиция системы на подсистемы и модули)
ControlНФТ, регламент, критерии приёмки (02.04.02 Критерии приёмки (Acceptance Criteria))

Сравнение с DFD и BPMN

ХарактеристикаIDEF0DFD (Gane/Sarson)BPMN
ФокусФункции и ICOMПреобразование данных и хранилищаПоследовательность действий, события, роли
Отображение времениНетНетДа
ДекомпозицияСтрогая иерархия нумерованных блоковИерархия процессов по уровнямПодпроцессы, сворачиваемые элементы
Исполнители / внешний мирМеханизм (вне границы); граница — дуги I/C/OВнешние сущности — источники/приёмники данныхПулы и дорожки
Модель данныхНет (→ DFD, ER, IDEF1X)ДаАртефакты данных
СтандартизацияFIPS 183 (архив), ISO/IEC/IEEE 31320-1:2012Нотации Yourdon, Gane/SarsonISO/IEC 19510:2013
Типичное применениеФункциональный аудит, ТЗ, концепцияАрхитектура данных и интеграцийИсполняемые бизнес-процессы

В проектах нотации дополняют друг друга (см. вводный абзац): после IDEF0 детализируйте потоки в DFD и роли/порядок в BPMN.

Пример диаграммы (аппроксимация в Mermaid)

Mermaid не поддерживает IDEF0 нативно; схемы ниже иллюстрируют логику ICOM и направление дуг, но не проверяют позиции стрелок автоматически. В рабочих артефактах используйте Visio, draw.io, Ramus или CASE с шаблоном IDEF0.

Контекстная диаграмма A-0:

flowchart LR
    I1["Заказ клиента"] --> A0["Обработать заказ"]
    C1["Регламент обработки"] --> A0
    A0 --> O1["Выполненный заказ"]
    M1["Персонал и система"] --> A0

«Заказ клиента» — Input (слева), «Регламент обработки» — Control (сверху), «Выполненный заказ» — Output (справа, исходит из блока), «Персонал и система» — Mechanism (снизу, вне границы функции).

Декомпозиция A0 (периметр = ICOM A-0; связи между A1–A3 — внутренние):

flowchart TD
    I1["Заказ клиента"] --> A1["1. Проверить наличие"]
    C1["Регламент обработки"] --> A1
    C1 --> A2["2. Оформить заказ"]
    A1 -- "Результат проверки" --> A2
    A2 -- "Скомплектованный заказ" --> A3["3. Организовать доставку"]
    A3 --> O1["Выполненный заказ"]
    M1["Персонал и система"] --> A1
    M1 --> A2
    M1 --> A3

«Регламент обработки» на A0 покрывает и оформление, и доставку — отдельные «правила доставки» здесь не выносятся на периметр, они входят в ту же Control родителя или во внутреннюю детализацию A3. Связи A1 → A2 → A3 — функциональные (output → input), не BPMN-последовательность.

Практический кейс

Проект «Автоматизация заявок в технической поддержке». A-0: блок «Обработать заявку»; вход «Заявка пользователя», управление «SLA и регламент», механизм «Сотрудники и Service Desk», выход «Решение и отчёт». A0: «1. Зарегистрировать», «2. Классифицировать и назначить», «3. Решить», «4. Закрыть»; «Зарегистрированная заявка» — output A1 и input A2. Блок «3. Решить» управляется дугой Control «База знаний (шаблоны и правила решений)» — норматив, по которому выбирают и оформляют решение; сама БЗ как IT-система — Mechanism «Service Desk и БЗ» на периметре A0 снизу. Модель входит в ТЗ, ложится в основу DFD и 02.03.03 Спецификация требований (SRS, Use Case, User Story); блок «3. Решить» → прецедент «Разрешить инцидент» на 03.02.01 Диаграмма прецедентов (Use Case Diagram).

Инструменты

ИнструментЗаметки
RamusOpen-source, популярен в РФ/СНГ; IDEF0 и DFD
AllFusion Process Modeler (BPwin)Исторический стандарт; снят с поддержки
MS VisioШаблоны IDEF0 без семантической проверки
draw.io / diagrams.netБиблиотеки или ручная настройка форм
Sparx Enterprise ArchitectIDEF0 как расширение функционального моделирования

Общий выбор CASE — в 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io).

4. Типовые ошибки и ограничения

  • Смешение ICOM: данные заказа на верхней грани вместо левой — проверяйте роль по таблице Control vs Input.
  • Механизм внутри границы: персонал и ПО — снизу, вне функции; не рисуйте их как вход или часть блока.
  • Неверное направление Output: стрелка входит в блок справа — должна исходить из блока.
  • Путаница output→input с BPMN: горизонтальные связи на одном уровне — функциональная зависимость; для «кто когда» — BPMN.
  • Новые внешние дуги на A0: «Информация о товаре» или «Правила доставки» на периметре без отражения на A-0 — нарушение балансировки; выносите на A-0 или оставляйте внутренним потоком.
  • Слишком много блоков: более 6 на листе — декомпозируйте в дочнюю диаграмму.
  • Нет управляющих дуг: у каждого блока — хотя бы одно Control.
  • Нарушение join входов/управлений: несколько граничных входов родителя на дочернем уровне должны сходиться в одну дугу родителя, как и выходы.
  • Call arrows между равными блоками: call — переход к детализации, не поток между A1 и A2.
  • База знаний как Input: если блок не изменяет БЗ, а следует правилам — это Control, не вход.
  • Ожидание динамики от IDEF0: ветвления, таймеры, параллель — 03.04.01 BPMN 2.0 - введение и основы.
  • Поиск модели данных в IDEF0: сущности и атрибуты — 03.03.01 ER-диаграммы (сущность-связь) или DFD.
  • Единственная модель без viewpoint: одна A-0 не покрывает всех заинтересованных сторон — фиксируйте цель модели.
  • Смешение as-is и to-be на одном листе без версии и легенды.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • Federal Information Processing Standards Publication 183 (1993). Integration Definition for Function Modeling (IDEF0). NIST. Архивный PDF: https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub183.pdf — стандарт withdrawn с 2 сентября 2008 г. (Federal Register, 73 FR 51276); для актуальной нормативной базы опирайтесь на ISO.
  • ISO/IEC/IEEE 31320-1:2012. Information technology — Modeling Languages — Part 1: Syntax and Semantics for IDEF0. Карточка стандарта: https://www.iso.org/standard/60614.html
  • Mark, D. A., McGowan, C. (1988). SADT: Structured Analysis and Design Technique. McGraw-Hill. — Историческая база IDEF0.
  • Черемных, С. В., Семенов, И. О., Ручкин, В. С. (2005). Моделирование и анализ систем. IDEF-технологии: практикум. М.: Финансы и статистика.
  • Маклаков, С. В. (2008). BPwin и Erwin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ.

Инструменты и спецификации