Мухи отдельно, котлеты отдельно. Или когда использовать IDEF3?

08.08.21

Архитектура

С нотацией IDEF0 разобрались, теперь поговорим о следующем представителе семейства IDEF – нотации IDEF3.

- Официант, почему у меня в супе дохлая муха?!

- Ну какая же она дохлая, вы только посмотрите, как она бодро шевелит лапками!

 

Вступление

В первой статье цикла, посвященной нотациям и методологиям описания бизнес-процессов, была детально рассмотрена нотация IDEF0 (//infostart.ru/1c/articles/1408200/).

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

Основы методологии WFD

Начнем с того, что рассмотрим вначале методологию моделирования WFD, к которой относится нотация IDEF3.

Итак, WFD (Work Flow Modeling) – это методология моделирования потоков работ (иногда можно встретить и другое название – диаграмма алгоритмов). Она представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня, в момент, когда возникает необходимость показывать временную последовательность выполнения работ в зависимости от получающихся результатов и событий, возникающих в ходе выполнения процесса.

Главным объектом описания становятся действия (работы), а не потоки данных (как, например, в методологии DFD – Data Flow Diagram).

Графические объекты методологии: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки.

Нотация, разработанная в данной методологии IDEF3 (тип диаграммы: PFDD – Process Flow Description Diagrams), т.е. диаграмма описания последовательности этапов процесса, с помощью которой моделируется последовательность действий, реализуемых в рамках бизнес-процесса.

Основы нотации IDEF3

Нотация IDEF3 (Integrated DEFinition for Process Description Capture Method) – важнейшая нотация после IDEF0 и предназначена для описания потоков работ бизнес-процесса (WFD). Как правило используется совместно с нотацией IDEF0, но может и отдельно.

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

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

В течении длительного времени IDEF3 широко использовалась для создания моделей бизнес-процессов организации на нижнем уровне – при описании работ, выполняемых в подразделениях и на рабочих местах. Эта нотация была взята за основу при создании методики описания процессов ARIS eEPC – «расширенной цепочки процесса, управляемого событиями». Таким образом, нотация IDEF3 – классический вариант Work Flow, тогда как ARIS eEPC – можно назвать современной схемой моделирования бизнес-процессов.

Основные характеристики нотации IDEF3:

  1. Основная цель нотации: дать возможность бизнес-аналитикам описать ситуацию, когда процессы (действия) выполняются в определенной последовательности и взаимной зависимости, а также описать объекты, участвующие совместно в одном процессе.
  2. Нотация IDEF3 чаще применяется для моделирования и анализа процессов нижнего уровня и как правило используется при декомпозиции блоков процесса модели IDEF0.
     

    Пример:

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

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

    - Можно дополнять модель DFD диаграммами в нотации IDEF3.

    В каждом конкретном случае при моделирования системы принимается решение о необходимости построения каждого вида модели.

  3. Нотация IDEF3 так же поддерживает возможность декомпозиции (каждый отдельный блок в модели IDEF3, в свою очередь, может быть представлен в виде отдельного подпроцесса).
  4. В отличие от IDEF0 нотация IDEF3 не ограничивает чрезмерно жесткими рамками синтаксиса и семантики, что удобно для описания неполных или не целостных систем, особенно если аналитик плохо знает предметную область. Однако, это подразумевает, что модель может получиться неполной или противоречивой.
  5. Основной организационной единицей описания в IDEF3 является диаграмма. Очень важно придерживаться взаимной организации диаграмм внутри модели, так как они предназначены для чтения другими людьми (а не только автором модели).
  6. В целом методика построения модели и рекомендации по построению диаграмм аналогичны тем, которые применяются при моделировании в нотации IDEF0.
  7. Технологию работы с этой нотацией можно представить следующим образом:

    - определяется цель моделирования — набор вопросов, на которые будет отвечать модель, точка зрения, границы моделирования, с учетом глубины и широты — какие объекты войдут, а какие не будут отображены в модели,
    - опрашиваются эксперты предметной области,
    - составляются списки кандидатов на действия (работы), составляющих процесс, и кандидатов на объекты, участвующих в процессе, обозначающих результат выполнения работ.
     
  8. В нотации IDEF3 нет ограничения на количество блоков на одной диаграмме (в рамках разумной наглядности) и нет принципа «доминирования» блоков.

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

Методы и диаграммы IDEF3

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

  1. Process Flow Description (PFD) — описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса.
  2. Object State Transition Description (OSTD) — описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Основу методологии IDEF3 составляет графический язык описания процессов, поэтому модель в нотации IDEF3 может содержать два типа диаграмм:

  1. Диаграмма описания последовательности этапов процесса (Process Flow Description Diagrams, PFDD),
  2. Диаграмма сети трансформаций состояния объекта (Object State Transition Network, OSTN).

Компоненты диаграммы описания процесса и их назначение

Диаграмма IDEF3 (PFDD) может состоять из 5 основных описательных блоков:

Обозначение

Наименование

Описание

1

Блоки работы или действия (Boxes, Activities) или Unit of Behavior (UOB)

Объект служит для описания функций (процедур, работ), выполняемых подразделениями / сотрудниками предприятия.

2

Стрелки или связи (Arrows, Links)

Показывают взаимоотношения работ. Бывают трех видов: стрелки предшествования, отношения, потоков объектов.

3

Перекрестки (Junctions) или логические операторы «И» (AND), «ИЛИ» (OR), исключающее «ИЛИ» (XOR) и их комбинации.

Операторы, позволяющие описать ветвление или слияние процесса/ов.

4

Объекты ссылок (Referent)

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

 

Блоки работы или действия (boxes, activities)

Основные характеристики элемента:

  1. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения.
  2. Является центральным компонентом модели.
  3. Изображаются прямоугольниками с прямыми углами.
  4. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер.
  5. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.
  6. Действия желательно именовать по тем же правилам, что и в модели IDEF0: глаголом (одиночным или в составе фразы с существительным), обычно отображающим основной результат работы.
  7. Допускается использовать стиль именования через имя, выраженное отглагольным существительным.
  8. Действия имеют входы и выходы, но не поддерживают управления и механизмы, как функции в нотации IDEF0.

Например, «Приготовить ужин» (это действие) – глагол с существительным. Или, другой пример, «Приготовление ужина» (это работа) – имя, выраженное отглагольным существительным.

Стрелки (линии) или связи (arrows, links)

Основные характеристики элемента:

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

- Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.

- Отношения (Relational Link)- пунктирная линия, использующаяся для изображения связей между UOB.

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

Связь «Старшая стрелка»

Основные характеристики элемента:

  1. Связь типа «Временное предшествование» (Precedence).
  2. Обозначение - сплошная стрелка, связывающая единицы работ.
  3. Показывает, что работа-источник должна быть закончена прежде, чем начнется работа-цель.
  4. Во многих случаях завершение одного действия инициирует начало выполнения другого. Связь именуют так, чтобы была понятна причина ее появления.

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

Стрелка отношений

Основные характеристики элемента:

  • Связь типа нечеткое отношение (Relational).
  • Изображается в виде пунктирной линии.
  • Используется для изображения связи между единицами работ, а также между единицами работ и объектами ссылок.
  • Используется, когда невозможно описать связи с использованием предшествующих или объектных связей. Значение такой связи должно быть четко определено с помощью названия и описания стрелки, так как связи такого типа сами по себе не предполагают никаких ограничений.
  • Применение нечетких отношений: отображение задержки между действиями; отображение взаимоотношений между параллельно выполняющимися действиями.
  • Нечеткое отношение является альтернативой временному предшествованию и объектному потоку в смысле задания последовательности выполнения работ — работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.

Поток объектов

Основные характеристики элемента:

  1. Стрелка, изображающая поток объектов (Object Flow).
  2. Стрелка с двумя наконечниками.
  3. Применяется для описания того факта, что объект используется в двух и более единицах работ, например, когда объект порождается в одной работе и используется в другой.
  4. Применяется для описания того, что результатом выполнения исходного действия является некоторый объект, который необходим для выполнения конечного действия. Временная семантика объектных связей аналогична связям предшествования. Связь именуют так, чтобы четко определить передающийся объект.

Например, семейный ужин является результатом выполнения действия 1.1 - приготовления этого ужина.

Перекрестки (Junctions)

Основные характеристики элемента:

  1. Объект, обозначенный J1 - называется перекрестком (Junction).
  2. Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".
  3. Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.
  4. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок.
  5. Перекресток не может использоваться одновременно для слияния и для разветвления стрелок.
  6. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.
  7. Все соединения на диаграммах должны быть парными, т.е. любое разворачивающее соединение должно иметь парное себе сворачивающее соединение, типы соединений не обязательно должны совпадать.
  8. Соединения могут комбинироваться для создания более сложных ветвлений.
  9. В отличие от других методологий (IDEF0, DFD) стрелки могут сливаться или разветвляться только через перекрестки.

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

 

Обозначение

Наименование

Смысл в случае
слияния стрелок
(Fan-in Junction)

Смысл в случае разветвления стрелок (Fan-out Junction)

1

Asynchronous AND

Асинхронное И

Все предшествующие процессы должны быть завершены

Все предшествующие процессы должны быть запущены

2

Synchronous AND

Синхронное И

Все предшествующие процессы завершены одновременно

Все следующие процессы запускаются одновременно

3

Asynchronous OR

Асинхронное ИЛИ

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

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

4

Synchronous OR

Синхронное ИЛИ

Один или несколько предшествующих процессов завершаются одновременно

Один или несколько следующих процессов запускаются одновременно

5

XOR (Exclusive OR)

Исключающее ИЛИ

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

Только один следующий процесс запускается

Объекты ссылок

Основные характеристики элемента:

  1. Выражает идею, концепцию данных, которые нельзя связать со стрелкой, перекрестком, работой.
  2. Используется при построении диаграммы для привлечения внимания пользователя к каким-либо важным аспектам модели.
  3. Объекты ссылки должны быть связаны с единицами работ или перекрестками линиями.
  4. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы.
  5. В качестве имени можно использовать имя какой-либо стрелки, процесса, действия с других диаграмм или имя сущности из модели данных.
  6. Кроме имени следует указывать тип объекта ссылки – см. таблицу.
  7. Официальная спецификация IDEF3 различает 3 стиля объектов ссылок:

- безусловные (unconditional),

- синхронные (synchronous),

- асинхронные (asynchronous).

Тип объекта ссылок

Назначение / Цель описания

Объект /

Object

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

Ссылка /

GOTO

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

Единица действия /
UOB (Unit Of Behavior)

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

Заметка /
Note

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

Уточнение /
Elaboration (ELAB)

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

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

Основные характеристики элемента:

  1. Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью.
  2. Декомпозиция — это представление каждого UOB с помощью отдельной IDEF3 диаграммы.
  3. При этом эта диаграмма будет называться дочерней, по отношению к первичной, а та, соответственно родительской.
  4. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Нумерация работ

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

IDEF3 (PFDD): ПРИМЕР

В качестве примера возьмем часть процесса приготовления котлет по-одесски для семейного ужина. Начало примера мы рассматривали в статье о нотации IDEF0.

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

См. также

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

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

14.10.2024    4189    0    comol    28    

28

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3584    0    Novattor    1    

16

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

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

27.12.2023    2238    0    slavik27    7    

15

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    2977    0    Serg_Tangatarov    2    

16

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5727    0    ivanov660    10    

35

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    3029    0    user1754524    15    

17

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    3565    0    ke_almaty    0    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 2684 08.08.21 14:23 Сейчас в теме
Полезно, как и первая часть.
2. SergeyN 1093 09.08.21 22:11 Сейчас в теме
По моему мнению, про IDEF (что 0, что 3) нужно знать только одно - никогда не используйте этого мамонта)
makushka; ashtey; +2 Ответить
3. ashtey 296 09.08.21 22:14 Сейчас в теме
(2) 😀 но это тоже нужно знать - что не нужно использовать.
До UML скоро доберусь)))
4. SergeyN 1093 09.08.21 22:17 Сейчас в теме
(3) Кстати, мы сейчас UML в тех.проекте используем. Очень просто и понятно получилось. В моей новой проектной технологии я сделал связку BPMN + UML. Пока считаю, что такое сочетание наиболее понятно и универсально для проектов по созданию АС.
5. ashtey 296 09.08.21 22:38 Сейчас в теме
(4) а это уже интересный опыт применения!)
6. SergeyN 1093 09.08.21 22:55 Сейчас в теме
(5) Небольшой пример во вложении. Как нибудь сделаю доклад на эту тему)
Прикрепленные файлы:
Nobel; ashtey; +2 Ответить
Оставьте свое сообщение