Моделирование в стандарте IDEF0

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диа­грамм. Каждая диаграмма является единицей описания системы и распо­лагается на отдельном листе [9].

Модель может содержать четыре типа диаграмм:

- контекстную диаграмму (в каждой модели может быть только одна кон­текстная диаграмма);

- диаграммы декомпозиции;

- диаграммы дерева узлов;

- диаграммы только для экспозиции (FEO).

 

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

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

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

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

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

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

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

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

Точка зрения. Система моделируется с точки зрения руководителя конструкторского отдела.

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

 

 

Рисунок 5.14 – Контекстная диаграмма системы

 

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

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

Например, при " Обработке анкеты" анкета может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назна­чение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - " Проверенная анкета "). Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 5.14 стрелки " Стандарты, нормативные документы, справочники", " Данные о сотрудниках", " Данные о разработках" являются управ­лением для работы " Хранение и учет конструкторской документации". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

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

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

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

Например, если работа заключается во вводе в ЭВМ данных с бумажного бланка анкет (даже без изменения их смыслового содержания), тогда:

- входом будут смысловые данные (информация), записанные в бумажном бланке анкеты;

- выходом будут данные в электронной форме;

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

Выход (Output) - материал или информация, которые производятся ра­ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка вы­хода рисуется как исходящая из правой грани работы. На рис. 5.14 стрелка " Архивная КД " является выходом для работы " Хранение и учет конструкторской документации".

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рису­ется как входящая в нижнюю грань работы. На рис. 5.14 стрелка " Персонал предприятия" является механизмом для работы " Хранение и учет конструкторской документации". По усмотрению аналитика стрелки механизма могут не изображаться в модели (или туннелироваться).

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

В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

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

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

 

 

Рис. 5.15 - Пример несвязанных стрелок

 

На рис. 5.15 приведен фрагмент диаграммы декомпозиции с несвязан­ными стрелками, генерирующийся BPwin при декомпозиции работы " Хранение и учет конструкторской документации" (см. рис. 5.14). Стрелки входа, выхода, управления и механизма необходимо связать с соответствующими им блоками.

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

 

В IDEF0 различают пять типов связей работ.

1) Связь по входу (output-input), когда стрелка выхода вышестоящей рабо­ты (далее - просто выход) направляется на вход нижестоящей (например, на рис. 5.17 стрелка " Файлы документов" связывает работы " разработка ТЗ" и " Разработка КД и файлов ТЗ").

2) Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показыва­ет доминирование вышестоящей работы. Данные или объекты выхода вы­шестоящей работы не меняются в нижестоящей. На рис. 5.17 стрелка " Утвержденная КД" связывает работы " Утвержденная КД" и " Создание архива"), при этом чертеж не претерпевает изменений в процессе изготов­ления деталей.

3) Обратная связь по входу (output-input feedback), когда выход нижестоя­щей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 5.17 стрелка " Неутвержденная КД " связывает работы " Утверждение КД" и " Разработка КД и файлов ТЗ", при этом выявлен­ные при утверждении несоответствия КД направляются для устранения замечаний.

4) Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка " Рекомендации", рис. 5.17). Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса. На рис. 5.17 стрелка " Архивные файлы других отделов" связывает работы " Документооборот" и " Разработка КД и файлов ТЗ", при этом возможно повторное использование архивных файлов или их фрагментов при разработке КД. На рис. 5.17 качество документации может быть повышено путем непосредственного регулирования процессами разработки в зависимости от результатов (выхода) работы " Документооборот" (наличия аналогичной документации в архиве).

5) Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже ос­тальных и показывает, что одна работа подготавливает ресурсы, необходи­мые для проведения другой работы (рис. 5.16).

Несвязанные граничные стрелки (unconnected border arrow). При деком­позиции работы входящие в нее и исходящие из нее стрелки (кроме стрел­ки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки назы­ваются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

 

 

Рисунок 5.16 – Связь выход-механизм

 

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

 

Рисунок 5.17 – Диаграмма декомпозиции первого уровня

 

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

Смысл разветвляющихся и сливающихся стрелок передается именова­нием каждой ветви стрелок. Существуют определенные правила именова­ния таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. 5.18).

Рисунок 5.18 – Именование разветвляющихся стрелок

 

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

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

 

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

 

Рисунок 5.19 –Второй подуровень «Разработка ТЗ»

 

Первый блок «Разработка ТЗ и прикрепление файлов» декомпозирован на третий подуровень (рисунок 5.20).

 

Рисунок 5.20 –Третий подуровень «Разработка ТЗ и прикрепление файлов»

 

Блок «Разработка ТЗ и прикрепление файлов» подразумевает создание документа технического задания (блок «Создание файла документа ТЗ»), создание новой записи о задании в БД – номер ТЗ, название, тема (блок «Создание нового ТЗ в БД») и прикрепление к заданию файлов, необходимых для его выполнения (блок «Прикрепление к ТЗ файлов необходимых для разработки»).

Блок «Визирование и простановка сроков» (рисунок 5.19) имеет смысл в том, что новое задание должно быть завизировано начальником подразделения разработчика ТЗ (задание может составлять как сотрудник, так и начальник). Начальник должен назначить подразделение-исполнитель и назначить сроки разработки по ТЗ.

Блок «Отправка в отдел-исполнитель» подразумевает, что после визирования ТЗ, у начальника отдела исполнителя появляется запись о новых невыполненных заданиях. После этого он должен назначить конкретного исполнителя, что и показано на четвертом блоке «Назначение исполнителя».

Второй блок «Разработка КД и файлов по ТЗ» (рисунок 5.17) отображает процесс полной разработки документации, файлов для производства и сопутствующих файлов, печати конструкторской документации, обмена информацией с другими подразделениями, что подразумевается в блоке «Документооборот».

Третий блок «Утверждение КД» (рисунок 5.17) отображает, что разработанная документация должна быть проверена начальником, нормоконтролером и утверждена во всех инстанциях. Если КД не утверждена, ее нужно доработать и исправить ошибки. После утверждения КД разработчик имеет право делать электронный архив файлов.

Четвертый блок «Создание архива» отображает порядок создания архива и детализирован на втором подуровне на три составляющих функции (рисунок 5.21).

 

Рисунок 5.21 –Второй подуровень «Создание архива»

 

Блок «Создание папки архива» (рисунок 5.21) подразумевает создание названия архива и выбор номера ТЗ, после чего происходит создание папки хранения архива на сервере БД. Второй блок «Прикрепление файлов» показывает запись файлов в папку архива. Третий блок «Сохранение и ввод информации об архиве» выполняет сохранение данных об авторе архива, присвоение версии архива и простановку даты создания архива.

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

Шестой блок «Документооборот» второго подуровня модели процессов (рисунок 5.17) отображает работы по хранению и извлечению файлов документации из архивов.

 

Тоннелирование стрелок. Вновь внесенные граничные стрелки на диа­грамме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. 5.22)

 

Рис. 5.22 - Неразрешенная (unresolved) стрелка

 

Тоннелирование может быть применено для изображения малозначи­мых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо на­править на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутст­вует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое Тоннелирование называется " не-в-родительской-диаграмме". Например, стрелки «Брак», «Отходы» можно тоннелировать на соответствующем уровне.

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

 

 

Рис. 5.23 - Типы тоннелирования стрелок