IDEF0 нотация: моделирование функциональных процессов информационных систем – методология, описание стандартов, проектирование диаграмм, примеры

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

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

Определение – что такое IDEF0-нотация и ее место в моделировании процессов

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

IDEF0 расшифровывается как «Icam DEFinition for Function Modeling», где ICAM – это еще одна аббревиатура, расшифровка: Integrated Computer Aided Manufacturing (русск. «Интегрированное автоматизированное производство» – специальная программа ВВС США).

Правильное произношение как «idef zero».

 В 1998 году институт IEEE переформулировал аббревиатуру IDEF в Integration Definition (русск. «Определение интеграции»).

Краткое описание нотации IDEF0 (стандарт IDEF)

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

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

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

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

Зачем нужна модель IDEF0 и для каких случаев она используется

Основные сферы применения и решаемые задачи:

• Анализ бизнеса и внутренних процессов. С помощью IDEF0 можно описывать любые процессы вне зависимости от тематики и ниши: банковская сфера (например, процесс выдачи кредита, рассмотрения страховых случаев), производство (моделирование циклов и конвейеров, логистических цепочек), IT-компании (типовые процессы разработки ПО, внедрения, техподдержки), госучреждения (регламенты предоставления услуг населению) и пр.
• Разработка и внедрение информационных систем. IDEF0 будет полезным как для создания техзаданий, так и при приёме результата заказчиком.
• Реинжиниринг бизнес-процессов. В этом случае нужно создать сразу две модели: сначала «Как есть» (AS-IS), чтобы выявить узкие места и проблемы, а потом «Как должно быть» (TO-BE). Отдельно про AS IS — TO BE.
• Управление качеством. Модель не противоречит использованию тематических (профильных) стандартов и помогает лучше сформулировать требования.
• Моделирование любых других систем и процессов на разных этапах жизненного цикла компании (проектирование, производство, эксплуатация, утилизация).

Немного истории и связанные стандарты

IDEF0 был создан на основе языка графического моделирования SADT (Structured Analysis and Design Technique, разработчик Дуглас Т. Росс, SofTech, Inc). ВВС США поручили создателям SADT разработать метод удобного описания функциональных моделей для быстрого анализа их работы при приёмке и передаче. IDEF0 должен был помочь «понятно общаться» аналитикам и заказчикам.

IDEF0 был представлен в 1981 году, вместе с другими моделями серии IDEF (IDEF1, применялась для описания информационных систем, позже была расширена до IDEF1X, и IDEF2, применялась для описания динамических систем). На основе IDEF0 в 1991 году был разработан стандарт FIPS PUB 183 (США). Но позже, в 2008 году, он был отозван в пользу спецификаций и стандартов OPEN.

Существуют также методы IDEF3, IDEF4, IDEF5, вплоть до IDEF14. Но особого распространения они не получили, а некоторые остались лишь на уровне концепций.

Что примечательно, институт IEEE создал свой стандарт на основе IDEF0, а ISO принял и опубликовал его как IEEE/ISO/IEC 31320-1.

В России нет идентичных ГОСТов, но есть Руководящий документ Госстандарта РД IDEF0-2000 и Методология функционального моделирования Р 50.1.028-2001.

Примеры нотации IDEF0

Простой пример построения диаграммы для одного процесса

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

Основные элементы IDEF0 и структура функциональной модели

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

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

Блоки (функции) и процесс как центральное понятие нотации

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

Название блока отражает его функционал. Согласно стандарту, для наименования рекомендуется использовать глагол, но лучше выбрать расширенную фразу на основе глагола. Например, «Управлять проектами», «Реализовать процесс производства»,  «Строить дом» и т.п.

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

Четыре типа стрелок: вход, управление, механизм, выход

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

Стрелки нельзя рисовать «под углом», по диагонали, изогнутыми. Все изгибы должны быть только под 90 градусов. Допускается отрисовка линий разной толщины.

Типы стрелок мы уже упоминали выше. Ещё нагляднее поможет объяснить картинка:

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

Стрелки можно и нужно подписывать.

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

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

Стрелки могут разветвляться или сливаться (объединяться в одну).

Правила построения диаграмм (модель A-0, A0, A1–A3, дальнейшие уровни) и точки зрения

Комплексные IDEF0-модели, созданные по всем канонам, должны включать в себя не только диаграммы (а это ключевой компонент модели), но также глоссарий и описательную часть. Всё это самостоятельные документы.

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

Иерархия IDEF0-нотаций – это сердце всего стандарта и одновременно оригинальная фишка. Разбивка на уровни происходит так:

• А-0 («A минус ноль») – это схема высшего уровня, она описывает цель моделирования, а также точку зрения и область охвата (границы будущего проекта/системы). На такой диаграмме всегда изображается только один блок, и он обязательно имеет стартовый номер – 0 (ноль).
• A0 («А ноль») – это первая дочерняя диаграмма, которая всегда детализует блок схемы высшего уровня (напомним, он имеет номер «0»). В этой схеме нумерация блоков производится уже от единицы (так как ноль занят). Все последующие диаграммы будут иметь уникальные номера.
• A1 («А один») – это диаграмма, которая «разбирает» (детализует) первый блок из диаграммы A0. Соответственно, по аналогии – ур. A2, A3 или A4 будут детализировать номерные блоки из нулевого уровня.
• Последующие уровни – детализируют отдельные функции вышестоящих блок-схем, при этом нумерация производится по следующему паттерну: <номер блока из ур. A 0> <номер дочернего блока из следующей детализации по нисходящей> <номер дочернего блока из следующей детализации по нисходящей> и т.д.

Пара примеров для лучшего понимания:

• А32 – будет «разбирать» (детализировать) второй блок в диаграмме А3.
• A611 – отображает связи между внутренними функциями для первого блока диаграммы A61. А 61 свою очередь будет детализировать первый блок внутри A6. И т.д.
• Получается своего рода матрешка.

Требования стандарта к согласованности и полноте модели

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

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

Как строится IDEF0-диаграмма (модель): пошаговое описание

Детализируем процесс по шагам.

1. Определение границ системы и её главного процесса

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

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

2. Создание дочерних диаграмм (уровень A 0 и ниже) – для декомпозиции

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

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

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

3. Проверка модели: корректность стрелок, логика процессов, согласование входов/выходов

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

Главные преимущества методологии IDEF0

• Удобная детализация с разбивкой на разные технические уровни. По аналогии со структурными, функциональными и принципиальными схемами.
• Строгий формат нотации, который обеспечивает простое чтение и понимание схем.
• Универсальность. Методология и модели IDEF0 подходят для разных сфер применения, не только для разработки ПО и IT-проектирования. С помощью таких структур можно описать любые бизнес-процессы.
• Эффективность для анализа и проектирования. С помощью диаграмм можно не только детально планировать новые проекты, но и улучшать/переделывать имеющиеся, искать узкие места, анализировать текущие состояния и т.д.

Ограничения нотации IDEF0

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

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

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

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

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

Когда лучше применить другие нотации: BPMN, UML, DFD

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

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

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

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

Выводы: где IDEF0 действительно работает лучше всего

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

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

Вместе с тем IDEF0-модель имеет ряд ограничений и не сможет помочь с проектированием динамических систем/процессов – там, где важна строгая привязка к шкале времени.

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