Практикум по применению IDEF0 для функционального описания программного обеспечения САПР

Практикум по применению IDEF0 для функционального описания программного обеспечения
Часть 1.

Если анализировать объявления о найме сотрудников фирм, занимающихся разработкой программного обеспечения, то в последнее время ощущается острая нехватка руководителей проектов, способных грамотно осуществлять постановку задач. Проблема заключается не в том, что они не могут сформулировать задачу, а в том, что они не могут корректно оформить документацию с учетом современных стандартов проектирования. Заказчику уже мало дать несколько листиков, набранных в Word. Он хочет документацию, оформленную в BPWin, ErWin, S-Designer, Power Designer, Rational Rose и т.д. За каждым из этих CASE-средством стоит стандарт. Данная статья посвящена одному из них - IDEF0.

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

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

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

Идеальный вариант, когда постановку задачи ставит заказчик. В этом случае можно жить по принципу "заказчик хочет", и пока он удовлетворен, вы получаете от заказчика деньги. Но все больше проектов создается в недрах какой-либо организации, а затем уже предлагается заказчику. И в этом случае качество документации, то, что вы сделали и что предполагаете сделать, выходит на передний план. Документация в этом случае решает все...

Стандарт IDEF0 (Integrated Definition Function Modeling) предназначен для функционального моделирования и принят в качестве федерального стандарта США. Стандарт IDEF0 является одним из группы стандартов, широко применяемых для описания любых бизнес-процессов. Его применение для описания программных проектов является весьма молодым направлением, но применение IDEF0 гарантирует серьезное отношение к вам ваших партнеров...

Применение стандартов группы IDEF (IDEF0, IDEF1 и т.д.) является фактическим условием для получения статуса организацией, удовлетворяющей ISO9000, ISO9001. Эти стандарты для организации - возможность увеличить сбыт продукции, возможность доказать, что она "на гребне волны".

Многие программисты широко используют CASE ErWin, при этом не зная, что он основан на стандарте IDEF1. Это не просто то, что вам нравится или нравится вашим клиентам. Это стандарт - и этим все сказано.

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

В основе стандарта IDEF0 лежит три базовых принципа:

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

2. принцип ограничения сложности - количество блоков на диаграмме должно быть 2...6 (условие удобочитаемости);

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

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

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

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

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

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

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

Взаимодействие между блоками отображается в виде дуг (стрелок). Иногда стороны блока называют направлениями, а стрелки - потоками. Стрелки можно подписывать. Подписи связываются с соответствующей стрелкой при помощи зигзага (молнии).

Общий вид реализации блока IDEF0-диаграммы изображен на рис.1.

Рис.1. Реализация блока, применяемого в IDEF0-диаграммах.

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

В своей сущности диаграммы образуют дерево. Любая диаграмма выступает как ДК по отношению к низлежащим.

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

Рис.2. Пример основной диаграммы.

Рис.3. Пример декомпозиции основной функции.

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

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

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

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

Рис.4. Типы связей между блоками на диаграмме. Соответственно а)связь по данным, б)связь по управлению, в)связь по механизму, г)обратная связь.

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

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

Нумерация блоков (индекс блока на диаграмме) на диаграмме определяется на основе приоритета. Нумерация начинается с единицы. Код диаграммы состоит из буквы "А" и номера. ДК имеет код A-0. Буква "А" подразумевает активное действие (от англ. active). Диаграмма, являющаяся декомпозированным вариантом ДК, будет иметь код А0. Каждый элемент на диаграмме А0 будет иметь код от А1 до А6 в соответствии с приоритетом. В свою очередь, при декомпозиции одного из блоков А1...А6, коды блоков вновь декомпозированной диаграммы будут состоять из кода декомпозированной диаграммы плюс индекс выбранного блока. Коды блоков диаграммы не повторяются в пределах всей диаграммы.

По количеству цифр в коде диаграммы можно определить уровень диаграммы - уровень декомпозиции ДК. Принято считать ДК главным уровнем, а все остальные с первого уровня декомпозиции и выше.

Типы последовательности выполнения действий. Данные могут обрабатываться последовательно или параллельно.

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

Пример параллельной обработки - вы можете одновременно смотреть телевизор и есть яблоко. При этом одновременно совершаются два действия. Эти действия между собой не связаны. Такие блоки на диаграмме располагаются вертикально друг над другом.

Часто на диаграмме существует группа действий (блоков), из которой выполняется только одно, в зависимости от какого-либо условия. Такие действия называются альтернативными. К таким блокам условие должно подводиться как управляющее воздействие (выбор действия). Рекомендуется введение специального блока на диаграмму, осуществляющего обработку условия выбора альтернативного действия (блока). Этот блок формирует отдельные команды по выбору для каждого блока.

Роль человек в IDEF0-диаграммах. Кем он является: управлением или механизмом? Вы сами решаете, какие функции выполняет человек в описываемой задаче. Если действием, заключенным в блоке, управляет человек, то управление. Если действие выполняется посредством человека, то механизм. Все зависит от степени абстракции представления вашей задачи.

Существуют случаи, когда человек (в том числе один и тот же) для одного блока будет выступать механизмом и управлением. ТАКОЕ СЛУЧАЕТСЯ. Пример, человек пишет письмо. Оно пишется посредством этого человека, и этот же человек управляет содержимым этого письма.

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

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

Сергей Соколов (Минск, БГУИР)
E-Mail:

Знаете ли Вы, что такое мысленный эксперимент, gedanken experiment?
Это несуществующая практика, потусторонний опыт, воображение того, чего нет на самом деле. Мысленные эксперименты подобны снам наяву. Они рождают чудовищ. В отличие от физического эксперимента, который является опытной проверкой гипотез, "мысленный эксперимент" фокуснически подменяет экспериментальную проверку желаемыми, не проверенными на практике выводами, манипулируя логикообразными построениями, реально нарушающими саму логику путем использования недоказанных посылок в качестве доказанных, то есть путем подмены. Таким образом, основной задачей заявителей "мысленных экспериментов" является обман слушателя или читателя путем замены настоящего физического эксперимента его "куклой" - фиктивными рассуждениями под честное слово без самой физической проверки.
Заполнение физики воображаемыми, "мысленными экспериментами" привело к возникновению абсурдной сюрреалистической, спутанно-запутанной картины мира. Настоящий исследователь должен отличать такие "фантики" от настоящих ценностей.

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

Это мы видим на примере СТО и ОТО, превратившихся в своеобразный вид религии, управляющей наукой и общественным мнением. Никакое количество фактов, противоречащих им, не может преодолеть формулу Эйнштейна: "Если факт не соответствует теории - измените факт" (В другом варианте " - Факт не соответствует теории? - Тем хуже для факта").

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

Эксперимент на то и эксперимент, что он есть не изощрение мысли, а проверка мысли. Непротиворечивая внутри себя мысль не может сама себя проверить. Это доказано Куртом Гёделем.

Описание Диаграмм бизнес процесса «Учет компьютерной техники предприятия»

Описание IDEF0 диаграммы

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

1. Контекстная

2. Функциональная декомпозиция

Рисунок 1 - Контекстная диаграмма «Учет компьютерной техники предприятия»

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

На контекстной диаграмме обозначены стрелки.

Виды стрелок:

· вход (входные материалы: компьютеры и комплектующие)

· выход (выходом является отчет)

· стрелками управления являются документы и руководители

· стрелками механизмов являются сотрудники и оборудование

Входная информация для обработки:

Компьютеры - ПК (персональные компьютеры) находящиеся на предприятии

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

Выходные потоки:

Отчет - готовый отчет по учету компьютерной техники предприятия

Входные управления:

Правила - условия, которые необходимо соблюсти, что бы достичь поставленной цели.

Приказы - поставленная задача предприятию (провести учет компьютерной техники на предприятии с помощью тех или иных информационных систем)

Руководители - директора и главные управляющие предприятием.

Входные ресурсы:

ПК - компьютеры, с помощью которых ведется учёт.

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

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

Рисунок 2 - Функциональная декомпозиция «Учет компьютерной техники предприятия»

Были выделены следующие виды работ:

1) Оформление поставок - процесс, в котором происходит присвоение id товару, отправка на хранение, на склад и занесение информации о товаре в программу.

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

Стрелка связь по входу между работами Оформление поставок и Обслуживание компьютера (компьютер);

Стрелки входа, выхода, управления повторяются в последующих работах.

2) Обслуживание компьютера - процесс, в котором происходит сборка, ремонт и модернизация компьютеров.

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

Стрелка управление - правила, приказы, руководитель;

Стрелка связь по входу между работами Обслуживание компьютера и Расстановка (занесение данных в базу), между работами Обслуживание компьютера и Составление отчета (занесение данных в базу);

3) Расстановка - процесс, в котором происходит расстановка компьютеров по офисам (кабинетам).

Стрелки управление - правила, приказы, руководитель;

Стрелка механизма - сотрудники;

Стрелка связь по входу между Расстановка и Составление отчета (присвоение id);

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

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

На рисунке 3 представлена диаграмма, показывающая работу Оформления поставок более подробно.

В результате детализации были выделены основные функции. В раздел «Оформление поставок» входит семь главных стрелок (вход, выход, управление, механизм).

Стрелка входа - компьютеры и комплектующие;

Стрелками управления являются правила, приказы и руководитель. Стрелки разветвляющие;

Стрелки механизма, разветвляющие - ПК, сотрудники;

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

1) Присвоение номера - присвоение индивидуального номера компьютерам и комплектующим.

Стрелки входа - компьютеры и комплектующие. Стрелка компьютеры повторяется в последующих работах, кроме составления отчета;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - ПК и Сотрудники;

Стрелка связь по входу между работами Присвоение номера и Отправка товара на склад (перемещение), между «Присвоение номера» и «Постановка на баланс» (внесение в базу);

2) Отправка товара на склад - оправка товара с присвоенным номером на склад.

Стрелка выхода - компьютер;

Стрелки управления - правила, приказы и руководитель.

Стрелка связь по входу между работами «Отправка товара на склад» и «Постановка на баланс» (количество);

3) Постановка на баланс - занесение информации в компьютер.

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - ПК и Сотрудники;

На рисунке 4 представлена диаграмма, детализирующая обслуживание компьютера более подробно.

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

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

1) Сборка компьютеров - конфигурация компьютеров по индивидуальному заказу руководителей.

Стрелка входа - компьютеры;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники;

Стрелка связь по входу между работами: «Сборка компьютеров» и «Ремонт компьютеров» (компьютер);

2) Ремонт компьютеров - сборка утвержденных к улучшению компьютеров.

Стрелка входа - компьютеры;

Стрелка выхода - занесение в базу;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники;

Стрелки входа, выхода, управления, механизма являются разветвляющимися;

Стрелка связь по входу между работами: «Ремонт компьютеров» и «Upgrade» (комплектующие);

3) Upgrade - усовершенствование, улучшение, обновление компьютера.

Стрелка выхода - занесение в базу;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники;

Стрелки управления, механизма являются разветвляющимися;

На рисунке 5 представлена диаграмма «Составление отчета» более подробно. В декомпозицию работы Составление отчета входит 4 граничных стрелки (вход, выход, управление, механизмы). Внутренние стрелки (обратная связь по входу, связь по входу).

В результате работы были выведены следующие функции:

1) Сбор данных - сбор информации для анализа и принятия решений.

Стрелка входа - присвоение id;

Стрелки управления - правила, приказы и руководитель;

Стрелки входа, управления, механизма являются разветвляющимися;

Стрелка связь по входу между работами: Сбор данных и Проверка данных (записи);

2) Проверка данных - проверка информации и отправка ее на составление отчета.

Стрелка входа - присвоение id, занесение данных в базу;

Стрелка выхода - Отчет;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники, ПК;

Стрелки входа (присвоение id), управления, механизма являются разветвляющимися;

Стрелкой обратной связи по входу с «Проверки данных» на «Сбор данных» (повторная проверка).

Описание DFD диаграммы

В декомпозиции работы «Обслуживание компьютера» Рисунок 1 определено четыре внутренние работы, две внешние сущности и два хранилища данных.

Рисунок 1 - Обслуживание компьютера

1) Сборка компьютера - процесс сборки компьютера из существующих комплектующих.

2) Составление отчета - процесс, который состоит из обобщающих итоговых показателей, полученных с помощью выполнения работ текущего учета.

3) Диагностика - проверка на работоспособность

4) Upgrade - усовершенствование, улучшение, обновление компьютера.

Внешние сущности: компьютеры и комплектующие

Хранилища данных:

1) Склад - место, где хранятся собранные и модернизированные компьютеры.

2) БД - база данных, в которой хранятся все отчеты и вся информация о проделанных работах.

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

Так же у нас есть еще одна внешняя сущность, это компьютер. Мы его отправляем на модернизацию, после чего на диагностику для проверки работоспособности, затем составляем отчет и заносим информацию о проделанной работе в Базу Данных. Либо после модернизации отправляем товар на склад, и после чего проводим диагностику, составляем отчет и заносим информацию в Базу данных.

В декомпозиции работы «Составление отчета» Рисунок 2 определено три внутренние работы, три внешние сущности и два хранилища данных.

1) Сбор данных - сбор сведений о компьютерах и комплектующих.

2) Проверка - проверка данных на точность.

3) Отчет - написание отчета о проделанной работе.

Внешние сущности: комплектующие, компьютеры, руководитель.

Хранилище данных - Данные о компьютерах и комплектующих, данные отчета.

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

Руководитель проверяет, делает пометки, исправления и отправляет на повторную проверку. После чего отчет отправляется на хранение до повторной проверки руководителя.

Описание IDEF3 диаграммы

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

1) Ремонт - сборка компьютера сборными комплектующими

2) Сборка - приведение компьютера в нормальный вид

3) Upgrade - модернизация компьютера

4) Компьютеры - товар после сборки и модернизации

5) Отправить на склад - отправить на хранение после улучшения (сборки)

6) Диагностика - проверка на работоспособность.

7) Отчет - информация о проделанной работе.

Перекрестки - соединители:

1) J2 - все действия начинаются одновременно.

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

3) J7 - показано, что эти условия одновременно выполняться не могут.

4) J9 - эти действия заканчиваются одновременно после чего составляется отчет по проделанной работе.

На диаграмме IDEF3 показано, что перекрёсток J2 имеет две разветвляющие стрелки на работы (сборка и upgrade), которые начинают выполняться одновременно. Только после выполнения этих работ выходит готовый продукт (компьютер), соединяет перекресток J6. После чего идет соединение перекрестком J7, который показывает что две работы (отправка товара на склад и диагностика) одновременно выполняться не могут. После выполнения предыдущих работ идет процесс составление отчета по проведенной работе, который соединен перекрестком J9.

Известная сегодня уже не только в узких кругах аббревиатура IDEF0 является первой методологией, стандартизирующей работу над бизнес-процессами. Она была разработана в середине прошлого века в рамках аэрокосмического проекта в США и, показав свою эффективность, стала федеральным стандартом. В нашей стране в 2000 году подготовлен документ «Методология функционального моделирования IDEF0. Руководящий документМетодология функционального моделирования IDEF0 Руководящий документ. Издание официальное. Госстандарт России РД IDEF0 – 2000. Разработан Научно-исследовательским Центром CALS – технологий «Прикладная Логистика». Принят и введен в действие Постановлением Госстандарта России 2000 г. Москва », но как стандарт он так и не был утвержден. Хотя это не помешало данной методологии стать в нашей стране одним из наиболее популярных инструментов графического моделирования бизнес-процессов. В данной статье я предлагаю вам рассмотреть модель IDEF0 и оценить актуальность этого подхода в настоящее время.

Основные понятия и сокращения

Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

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

Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.

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

Центральным элементом модели IDEF0 является функция , которая на схеме отображается в виде функционального блока – прямоугольника, внутри которого указано действие в форме отглагольного существительного. Действие может быть очень разным по масштабу – от деятельности компании вообще и до конкретной манипуляции в частности. Примеры: «Производство и продажа керамической посуды» и «Нанесение рисунка на изделие».

Обязательные элементы функционального блока в IDEF0

Независимо от масштаба действий все функции отображаются единообразно и обязательно содержат 4 ключевых потока, которые жестко закреплены за сторонами функционального блока:

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

Такой подход позволяет немного сэкономить на пояснениях в схемах и добиться однозначности в отображении потоков, что придает стройности всей модели.

Для построения функциональной модели методология IDEF0 требует соблюдать следующие правила.

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

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

Контекстная диаграмма

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

1. Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
2. Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
3. Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Основные потоки

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

1. Материальный: материалы и комплектующие на входе и готовая продукция на выходе.
2. Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.
3. Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.
4. Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

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

(нажмите для увеличения)

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

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

• законы и нормы;
• приказы, распоряжения;
• инструкции и регламенты;
• планы;
• конструкторская документация и пр.

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

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

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

(нажмите для увеличения)

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

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

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

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

(нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

Выводы об актуальности нотации

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

1. Модель обладает хорошим визуализирующим потенциалом, но, на мой взгляд, большее ее значение – в дисциплинирующем эффекте. Заложенные в методологию правила и ограничения заставляют выработать системное и строгое отношение к моделям, что очень хорошо сказывается на качестве конечного результата.
2. Модель позволяет выстроить потоки связи между внешне не сильно связанными вещами: связать подсистемы фронт и бэк-офисов с управлением, что гораздо хуже удается другим нотациям.
3. Подход прост и понятен для большинства участников проекта. Построение и чтение диаграмм в данной нотации ограничивается только желанием вникать в хитросплетение потоков бизнеса.

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

• конкретизации событий запуска и остановки процесса;
• условий перехода от одних действий к другим;
• возможности наглядно отобразить все ресурсы и исполнителей без перегрузки схемы стрелками.

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

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

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

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

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

Преимущество графики

Что представляет собой модели IDEF0? Графические схемы со своими особенностями и правила их построения. Почему именно графика? Потому что она эффективна. В этом можно убедиться на нескольких примерах.

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

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

Преимущества IDEF0 для IT -специалистов

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

Так как же доступно донести суть, не прибегая к объемным текстам? Графика! Именно она позволяет сократить написанное, наглядно демонстрируя нужную информацию. Ведь одно изображение способно заменить сотни слов. И применительно к использованию графики при описании бизнес-процессов – это на 100% верно.

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

Нотация описания бизнес-процессов: что это такое

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

IDEF0 – это…

IDEF0 – метод функционального моделирования, а также графическая нотация, которая используется для описания и формализации бизнес-процессов. Особенность IDEF0 заключается в том, что эта методология ориентирована на соподчиненность объектов. IDEF0 была разработана для автоматизации предприятий еще в 1981 году в США.

Функциональная модель компании

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

Типы стрелок

Входящими ставятся задачи.

Исходящими выводят результат деятельности.

Управляющие (стрелки сверху вниз) – это механизмы управления.

Механизмы (стрелки снизу вверх) используются для проведения необходимых работ.

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

IDEF0 позволяет обмениваться информацией, при этом благодаря универсальности и наглядности участники обмена легко поймут друг друга. IDEF0 тщательно разрабатывался и совершенствовался, работать с IDEF0 можно с помощью различных инструментов, к примеру, ERWIN, VISIO, Bussines studio.

У IDEF0 есть еще оно неоспоримое преимущество. Эта методика была разработана сравнительно давно, и за три десятилетия она прошла тщательную шлифовку и корректировку. Поэтому создать функциональную модель компании можно быстро и минимальной вероятностью ошибки.

Естественно, есть и другие методологии, так почему мы рекомендуем именно IDEF0? Отпилить кусок металлической трубы можно и ножовкой, но, согласитесь, сделать это гораздо проще с помощью болгарки. Так и с IDEF0: нет более функционального инструмента для моделирования, с ним получить вы легко и быстро получите нужный вам результат.

Как создается функциональная модель

Разберем создание функциональной модели на примере написания статьи.

Основной блок будет так и называться «Написание статьи».

То, что необходимо для написания статьи, отражается на входящих стрелках – «Опыт», «Дополнительная литература».

Управляющие стрелки для написания статьи – «План статьи», «Требования к оформлению», «Правила русского языка».

Механизмы – это непосредственно сам автор, копирайтер, редактор, программное обеспечение. Как организуется работа этих механизмов? Автор создает текст, записывая его аудиоверсию. Копирайтер переносит текст в текстовый формат, ориентируясь на план публикации, соблюдая требования издателя и правила русского языка. Затем к работе подключается редактор, который проверяет статью, исправляя речевые, орфографические и пунктуационные ошибки. Программное обеспечение – это те программы и инструменты, которыми пользовались участники процесса при создании статьи.

Все вышеописанное – только общая схема работы, поэтому ее нужно детализировать.

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

Так, весь процесс написания статьи можно разделить на 4 этапа:

1. Подготовить аудиоверсию.
2. Подготовить текст в печатном виде.
3. Редактирование и подготовка текста к печати.
4. Публикация статьи.

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

При подготовке функциональной модели исполнитель ориентируется на цель ее создания и свою точку зрения.

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

Процесс создания нотации IDEF0

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

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

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

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

Стандарт IDEF0 и его требования

О базовых требованиях IDEF0 мы говорили чуть выше.

1. Главный элемент – в верхнем левом углу.
2. Каждый элемент должен иметь входящие и исходящие стрелки. Причем входящие стрелки находятся слева, справа – исходящие.
3. Сверху располагаются управляющие элементы, снизу – механизмы.
4. При расположении нескольких блоков на одном листе или экране последующие размещаются справа внизу от предыдущего.
5. Схемы следует создавать так, чтобы стрелки пересекались минимальное количество раз.

Естественно, в стандарте IDEF0 есть общепринятые нормы, требования и обозначения. Подробно на них останавливаться не будем, при желании эту информацию несложно найти.

Ошибки при работе с IDEF0

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

Использование нескольких цветов

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

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

Большое количество блоков

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

Чтобы избежать этой ошибки, воспользуйтесь детализацией, которой будет остаточно для понимания вопроса. Подробная детализация готовится лишь в том случае, если она действительно нужна для решения важного вопроса.

Изменение структуры при исправлении ошибок

При создании схемы важно, чтобы не один процесс не остался без входящих, исходящих или иных важных элементов. К примеру, если нужно удалить из схемы автора, то нужно удалять все элементы и стрелки, непосредственно к нему относящиеся. Если же они останутся в схеме, то возникнет недоразумение и путаница, так как при детализации будут вести неизвестно куда.

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

Название блоков и управляющих элементов

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

Преимущества использования IDEF0

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

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

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

Минимальная вероятность ошибки. Работа по стандарту IDEF0 требует строгого следования его правилам. Это дисциплинирует исполнителя и исключает возможность возникновения ошибки. К тому же любое несоответствие стандарту сразу же становится заметным.

И напоследок

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

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