Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
- контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма );
- диаграммы декомпозиции ;
- диаграммы дерева узлов ;
- диаграммы только для экспозиции (FEO) .
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты.
Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания.
Построение диаграммы IDEF0 в process modeler (bpwin)
После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ , но не взаимосвязи между работами . Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены.
Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Деятельность компании», «Прием заказа» и т.д.). Работа «Деятельность компании» может иметь, например, следующее определение: «Это учебная модель, описывающая деятельность компании». При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой , изображающей систему в целом (рис. 7.6).
Рис. 7.6. Пример контекстной диаграммы
Что такое UML за 7 минут: Диаграмма классов, последовательностей, состояний и деятельности
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы . Для описания других свойств работы служит диалог Activity Properties (рис. 7.7).
Рис. 7.7. Редактор задания свойств работы
Диаграммы декомпозиции содержат родственные работы , т. е. дочерние работы , имеющие общую родительскую работу . Для создания диаграммы декомпозиции следует щелкнуть по кнопке
на панели инструментов.
Возникает диалог Activity Box Count (рис. 7.8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 7.9).
Допустимый интервал числа работ — 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.
Рис. 7.8. Диалог Activity Box Count
Рис. 7.9. Пример диаграммы декомпозиции
Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.
Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа , выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы . Такое размещение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ (см. ниже).
Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис.
7.9 все работы еще не были декомпозированы.
Источник: intuit.ru
Контекстная диаграмма
Контекстная диаграмма прежде всего позволяет быстро, кратко и ёмко описать назначение и границы системы, выявить и устранить коллективные расхождения в их понимании, показать и договориться о её масштабе.
Быстрое выявление функциональных системных требований
Второе её назначение — служить источником для быстрой генерации первичного набора системных функциональных требований при необходимости проектирования системы не «сверху-вниз», от бизнес-модели, бизнес-требований, модели деятельности организации, требований заинтересованных лиц, модели использования, как предлагает нам системная инженерия, а «из середины».
Как устроена контекстная диаграмма
- Проектируемый объект (например, система)
- Взаимодействующие с проектируемым объектом элементы окружения (группы пользователей, смежные системы)
- Потоки данных (исходящие и входящие)
Пример контекстной диаграммы для программной системы управления Заказами в ресторане:
Потоки данных могут передаваться между окружением и (программной) системой любым образом — с помощью графического пользовательского интерфейса (GUI), командной строки (CLI), программных вызовов (API), почтовых сообщений и т.д.
Если система имеет физические интерфейсы, то это могут быть разнообразные джойстики, рукоятки управления, специализированные клавиатуры, датчики распознавания движения, изображения, жестов и т.д.
В стандартной форме не принято указывать виды интерфейсов взаимодействия и тем более протоколы, чтобы не усложнять диаграмму и не пытаться принимать вторичные решения, пока не приняты первичные.
Пример контекстной диаграммы для программной системы автоматизации Единого расчётного центра (ЕРЦ) коммунальных услуг:
Подписаться на рассылку
Подпишитесь на рассылку, чтобы получать от нас полезные материалы и оставаться на связи
«Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности»
Как создавать контекстную диаграмму
Контекстная диаграмма может разрабатываться в ходе рабочего семинара, в ходе серии интервью или на основе результатов серии интервью.
Контекстную диаграмму можно рисовать на маркерной доске, в среде проектирования или в онлайн-инструменте (Google Draw, Draw.io, Miro и т.д.). Мы рекомендуем маркерную доску или онлайн-инструмент с совместным редактированием.
Порядок разработки контекстной диаграммы на рабочем семинаре:
- Из числа заинтересованных лиц собирается рабочая группа (обычно от 3 до 5 человек)
Как тестировать контекстную диаграмму
Диаграмму можно тестировать 2-мя способами — через контроль соответствия входных и выходных данных системы или через сквозной устный сценарий использования системы.
Тестирование контекстной диаграммы с помощью парных соответствий
Контроль соответствия входных и выходных данных системы опирается на принцип (aka «Закон сохранения данных»), что если в систему попадают какие-то данные (входной поток), они должны как-то использоваться для как минимум одного выходного потока.
И наоборот, если есть выходной поток, то система либо должна генерировать эти данные согласно каким-то правилам (например, случайно) или формировать их на основе каких-то других входных данных.
Более формально парные соответствия можно проконтролировать через таблицу, например:
Входной поток (Источник. Поток);Выходной поток (Получатель. Поток)
AD. Учётные записи; Администратор. Учётные записи Оператор. Платёжка; Бухгалтер. Ведомость платежей . ;.
Тестирование контекстной диаграммы с помощью сквозного сценария
В зависимости от сложности системы, можно проводить неформальное или формальное тестирование диаграммы через сквозной сценарий её использования.
Как выглядит неформальное тестирование — один из участников семинара, опираясь на конкретные потоки данных и указывая их на диаграмме, рассказывает возможный сквозной сценарий использования системы, начиная с логически более ранних событий и продолжая последующими, например:
- Система загружает реестр пользователей из AD
По ходу рассказа остальные участники помечают на диаграмме задействованные в сценарии потоки, дают свои комментарии, оперативно вносят изменения и дополнения в диаграмму. Очень часто в таком сценарии обнаруживаются пропущенные потоки данных.
При желании такой сквозной сценарий можно разработать и записать, сделав его приложением к контекстной диаграмме, иллюстрирующим текстом работу системы.
Как применять контекстную
диаграмму после её создания
Диаграмма может использоваться в документе концепции системы, документе системных требований или вики-документации для получения обзорного представления о назначении системы у читателя.
Контекстная диаграмма не создаётся один раз и навсегда, она может эволюционировать в ходе проекта. Другое дело, что каждое изменение диаграммы по сути означает изменение рамок системы и должно внимательно отрабатываться проектной командой.
Выявление и контроль полноты (функциональных) системных требований
При создании системных требований возникает риск упустить что-то важное или наоборот, избыточно проработать очевидное.
Чтобы не упустить что-то важное среди системных функций, можно применять:
- Трассировку системных требований на требования заинтересованных лиц
- Модель использования системы (обычно в форме набора сценариев использования, use case’ов)
- Контекстную диаграмму системы
Наибольшие гарантии даёт применение всех 3-х методов, однако контекстная диаграмма — это самый простой и дешёвый их них, поэтому часто стоит начинать проработку системных требований именно с неё.
Чтобы убедиться в том, что при выявлении первичного набора системных функциональных требований вы не упустили ни один из нарисованных потоков данных, бывает полезно развернуть потоки данных в таблицу, на которую потом страссировать порождённые ей требования:
Направление пограничного потока; Элемент контекста; Класс передаваемых данных; Код порождённого системного функционального требования
Входящий; Active Directory; Учётная запись пользователя; SFR-234 Входящий; Администратор; Полномочия пользователя; SUC-14 . ; . ; . ; .
Источник: systems.education
2.2 Контекстная диаграмма
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Контекстная диаграмма состоит из одной работы, которая называется «Система управления менеджментом и маркетингом КБ».
Взаимодействие работы с внешним миром описывается в виде стрелок, которые представляют собой некую информацию и именуются существительными. В данной работе описаны стрелки типа вход (Input), «информация о сотрудниках» и «информация по клиентам», они представляют собой входную информацию. Стрелка типа выход (Output), «документация и договора» содержит в себе выходную информацию.
Стрелка «маркетинговый отдел» является стрелкой типа механизм (Mechanizm) и входит в нижнюю грань работы. Стрелки «информация о конъюнктуре рынка», «цель и стратегия управления» являются стрелками типа управление (Control), входят в верхнюю грань работы и показывает правила, процедуры, которыми руководствуется работа «Система управления менеджментом и маркетингом КБ». Контекстная (корневая) работа имеет номер А-0(рис. 1)
2.3 Диаграммы декомпозиции в методологии idef0
Основной из трех методологий, поддерживаемых BPwin, является IDEF0, оно относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. 
Рис.1 Контекстная диаграмма В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекстную диграмму входит определение субъекта моделирования, цели и точки зрения на модель. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. Диаграммы декомпозиции содержат родственные работы, т.е. работы, имеющие общую родительскую работу. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т.д. до достижения нужного уровня подробности описания системы. Декомпозиция контекстной диаграммы имеет номер А0 (рис.2). Эта декомпозиция состоит из следующих основных работ «Управление маркетинговой деятельностью КБ», «Управление финансовым менеджментом КБ». 
Рис.2 Диаграмма декомпозиции А0 Декомпозиция работы «Управление маркетинговой деятельностью КБ» имеет номер А1 (рис.3) и состоит из следующих работ:
- планирование маркетинга
- организация осуществления маркетинговых стратегий и программ
- учет и контроль маркетинговой деятельности
Рис.3 Диаграмма декомпозиции «Управление маркетинговой деятельностью КБ» А1 Декомпозиция работы «Управление финансовым менеджментом КБ» имеет номер А2 (рис.4) которая состоит из следующих работ: планирование, информация о конъюнктуре рынка, создание продуктового ряда. Декомпозиция работы «Планирование» А2.1. (рис.5) будет состоять из следующих работ:
- Стратегическое планирование
- Моделирование
- Оперативное планирование
Рис.4 Диаграмма декомпозиции «Управление финансовым менеджментом КБ» А2 
Рис 5. Диаграмма декомпозиции «Планирование» А2.1 Диаграмма декомпозиции «Создание продуктового ряда» А2.3 (рис.6) включает в себя следующие работы: выбор вида услуги, оказание услуги, оформление документации и договоров. 
Рис.6 Диаграмма декомпозиции «Создание продуктового ряда» А2.3
Источник: studfile.net