Описание Диаграмм бизнес процесса «Учет компьютерной техники предприятия»
Описание 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.
6.2. Назначение и состав методологии SADT (IDEF0)Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.
Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).
Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:
Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);
Создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии можно постепенно выстраивать и анализировать систему даже тогда, когда трудно еще представить ее воплощение.
Таким образом, IDEF0 может применяться на ранних этапах создания широкого круга систем. В то же время она может быть использована для анализа функций существующих систем и выработки решений по их улучшению.
Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:
Контекстную диаграмму;
Диаграммы декомпозиции;
Диаграммы дерева узлов;
Диаграммы только для экспозиции (for exposition only, FEO).
Контекстная диаграмма (диаграмма верхнего уровня), являясь вершиной древовидной структуры диаграмм, показывает назначение системы (основную функцию) и ее взаимодействие с внешней средой. В каждой модели может быть только одна контекстная диаграмма. После описания основной функции выполняется функциональная декомпозиция, т. е. определяются функции, из которых состоит основная.
Далее функции делятся на подфункции и так до достижения требуемого уровня детализации исследуемой системы. Диаграммы, которые описывают каждый такой фрагмент системы, называются диаграммами декомпозиции . После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных процессов созданным диаграммам. Найденные несоответствия устраняются, после чего приступают к дальнейшей детализации процессов.
Диаграмма дерева узлов показывает иерархическую зависимость функций (работ), но не связи между ними. Их может быть несколько, поскольку дерево можно построить на произвольную глубину и с произвольного узла.
Диаграммы для экспозиции строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства организации).
6.3. Элементы графической нотации IDEF0
Методология IDEF0 нашла широкое признание и применение, в первую очередь, благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.
На следующем рисунке показаны основные элементы графической нотации IDEF0 .
Рис. 6.1. Элементы графической нотации IDEF0
Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).
Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :
- вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;
- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);
- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;
- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;
- вызов (англ. call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.
6.4. Типы связей между работами
После определения состава функций и взаимосвязей между ними, возникает вопрос о правильной их композиции (объединении) в модули (подсистемы). При этом подразумевается, что каждая отдельная функция должна решать одну, строго определенную задачу. В противном случае необходима дальнейшая декомпозиция или разделение функций.
При объединении функций в подсистемы необходимо стремиться, чтобы внутренняя связность (между функциями внутри модуля) была как можно сильнее, а внешняя (между функциями, входящими в разные модули), как можно слабее. Опираясь на семантику связей методологии , введем классификацию связей между функциями (работами). Данная классификация является расширением . Типы связей приводятся в порядке уменьшения их значимости (силы связывания). В приводимых примерах утолщенными линиями выделяются функции, между которыми имеется рассматриваемый тип связи.
1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.
Рис. 6.2. Иерархическая связь
2. Регламентирующая (управляющая, подчиненная) связь отражает зависимость одной функции от другой, когда выход одной работы направляется на управление другой. Функцию, из которой выходит управление, следует считать регламентирующей или управляющей, а в которую входит – подчиненной. Различают прямую связь по управлению , когда управление передается с вышестоящей работы на нижестоящую (рис. 6.3), и обратную связь по управлению , когда управление передается от нижестоящей к вышестоящей (рис. 6.4).
3. Функциональная (технологическая) связь имеет место, когда выход одной функции служит входными данными для следующей функции. С точки зрения потока материальных объектов данная связь показывает технологию (последовательность работ) обработки этих объектов. Различают прямую связь по входу , когда выход передается с вышестоящей работы на нижестоящую (рис. 6.5), и обратную связь по входу , когда выход передается с нижестоящей к вышестоящей (рис.6.6).
 |
 |
| Рис. 6.5. Прямая связь по входу | Рис. 6.6. Обратная связь по входу |
4. Потребительская связь имеет место, когда выход одной функции служит механизмом для следующей функции. Таким образом, одна функция потребляет ресурсы, вырабатываемые другой.
Рис. 6.7. Потребительская связь
5. Логическая связь наблюдается между логически однородными функциями. Такие функции, как правило, выполняют одну и ту же работу, но разными (альтернативными) способами или, используя разные исходные данные (материалы).
Рис. 6.8. Логическая связь
6. Коллегиальная (методическая) связь имеет место между функциями, алгоритм работы которых определяется одним и тем же управлением. Аналогом такой связи является совместная работа сотрудников одного отдела (коллег), подчиняющихся начальнику, который отдает указания и приказы (управляющие сигналы). Такая связь также возникает, когда алгоритмы работы этих функций определяются одним и тем же методическим обеспечением (СНИП, ГОСТ, официальными нормативными материалами и т. д.), служащим в качестве управления.
Рис. 6.9. Методическая связь
7. Ресурсная связь возникает между функциями, использующими для своей работы одни и те же ресурсы. Ресурсно-зависимые функции, как правило, не могут выполняться одновременно.
Рис. 6.10. Ресурсная связь
8. Информационная связь имеет место между функциями, использующими в качестве входных данных одну и ту же информацию.
Рис. 6.11. Информационная связь
9. Временная связь возникает между функциями, которые должны выполняться одновременно до или одновременно после другой функции.
Кроме указанных на рисунке случаев, эта связь имеет место также между другими сочетаниями управления, входа и механизма, поступающими в одну функцию.
Рис. 6.12. Временная связь
10. Случайная связь возникает, когда конкретная связь между функциями мала или полностью отсутствует.
Рис. 6.13. Случайная связь
Из приведенных выше типов связей наиболее сильной является иерархическая связь, которая, по сути, и определяет объединение функций в модули (подсистемы). Несколько слабее являются регламентирующие, функциональные и потребительские связи. Функции с этими связями обычно реализуются в одной подсистеме. Логические, коллегиальные, ресурсные и информационные связи одни из самых слабых. Функции, обладающие ими, как правило, реализуют в разных подсистемах, за исключением логически однородных функций (функций, связанных логической связью). Временная связь свидетельствует о слабой зависимости функций друг от друга и требует их реализации в отдельных модулях.
Таким образом, при объединении функций в модули наиболее желательными являются первые пять видов связей. Функции, связанные последними пятью связями, лучше реализовывать в отдельных модулях.
В IDEF0 существуют соглашения (правила и рекомендации) по созданию диаграмм, которые призваны облегчить чтение и экспертизу модели [ , ]. Некоторые из этих правил CASE-средства поддерживают автоматически, выполнение других следует обеспечить вручную.
1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.
2. На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.
4. Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз. Такое расположение позволяет более четко отразить логику и последовательность выполнения работ. Кроме этого маршруты стрелок будут менее запутанными и иметь минимальное количество пересечений.
5. Отсутствие у функции одновременно стрелок управления и входа не допускается. Это означает, что запуск данной функции не контролируется и может произойти в любой произвольный момент времени либо вообще никогда.
Рис. 6.14. Функция без управления и входа
Блок с наличием только управления можно рассматривать как вызов в программе функции (процедуры) без параметров. Если у блока имеется вход, то он эквивалентен вызову в программе функции с параметрами. Таким образом, блок без управления и входа эквивалентен функции, которая в программе ни разу не вызывается на исполнение.
На рис. 6.7–6.12, отображающих фрагменты диаграмм IDEF0, встречаются блоки без входа и управления. Это не стоит рассматривать как ошибку, так как подразумевается, что одна из этих стрелок должна быть.
6. У каждого блока должен быть как минимум один выход.
Рис. 6.15. Функция без выхода
Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.
7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.
8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).
9. Каждый блок и каждая стрелка на диаграммах должны обязательно иметь имя. Допускается использовать ветвление (декомпозицию) или слияние (композицию) стрелок. Это связано с тем, что одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. И наоборот, одинаковые или однородные данные и объекты, порожденные разными работами, могут использоваться в одном месте.
Рис. 6.16. Ветвление стрелок
При этом допускается задание различным ветвям стрелки уточняющих имен после разветвления (до слияния). Если какая-либо ветвь после ветвления не именована, то считается, что ее имя соответствует имени стрелки, записанному до ветвления.
Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.
На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.
Рис. 6.17. Неправильное именование стрелок
10. При построении диаграмм для лучшей их читаемости может использоваться механизм туннелирования стрелок. Например, чтобы не загромождать лишними деталями диаграммы верхних уровней (родительские), на диаграммах декомпозиции начало дуги помещают в тоннель.
Рис. 6.18. Туннелирование стрелок
В данном примере при построении модели проведения новогоднего утренника механизм «два топора» не будет отображаться на диаграммах верхних уровней, при чтении которых может возникнуть справедливый вопрос: «А зачем нужны два топора на новогоднем утреннике?».
Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.
11. Все стрелки, входящие и выходящие из блока, при построении для него диаграммы декомпозиции должны быть отображены на ней. Исключение составляют затуннелированные стрелки. Имена стрелок, перенесенных на диаграмму декомпозиции, должны совпадать с именами, указанными на диаграмме верхнего уровня.
12. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и называть единым термином.
Рис. 6.19. Объединение связей
13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.
Рис. 6.20. Иерархия диаграмм
В современных CASE-средствах механизмы нумерации работ поддерживается автоматически. CASE-средства обеспечивают также автоматическое построение диаграмм дерева узлов, которые содержат только иерархические связи. Вершиной такой диаграммы может быть любой узел (блок), и она может быть построена на любую глубину.
6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей
Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».
Как было отмечено, построение модели IDEF0 начинается с представления всей системы в виде простейшей компоненты (контекстной диаграммы). Данная диаграмма отображает назначение (основную функцию) системы и необходимые входные и выходные данные, управляющую и регламентирующую информацию, а также механизмы.
Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.
Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)
В качестве исходной информации , на основе которой выполняется определение допускаемых скоростей, используются:
Данные проекта новой линии или проекта реконструкции (содержат всю необходимую информацию для реализации проекта, а именно километраж, оси раздельных пунктов, план линии и др.);
Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);
Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));
Данные о результатах съемки плана пути вагоном-путеизмерителем;
Ведомость возвышений наружного рельса в кривых (содержит информацию о плане пути).
Часть исходной информации может быть взята из разных источников. В частности сведения о плане (параметрах кривых) могут быть взяты из проекта новой линии или проекта реконструкции, подробного продольного профиля, паспорта дистанции пути и т.д.
Управляющими данными являются:
Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;
Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;
Сведения о текущем или планируемом поездопотоке (данные о марках обращающихся локомотивов и типах используемых вагонов);
Сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.
Результатом работы системы должны быть:
Ведомости допускаемых скоростей, содержащие все типы рассчитанных скоростей и позволяющие установить причину их ограничения;
Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;
Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.
Скорости, содержащиеся в Приказе «Н» и типовых формах, могут отличаться от рассчитанных и показываемых в ведомостях допускаемых скоростей. Это связано с тем, что в них отражают ограничения скорости не только по конструкции подвижного состава, параметров ВСП и кривых, но и по состоянию устройств и сооружений (деформация земляного полотна, перекос опор контактной сети и т. д.). Кроме того, они корректируются с учетом планируемых ремонтов пути, реконструкции и переустройства сооружений и устройств и т.д.
После построения контекстная диаграмма детализируется с помощью диаграммы декомпозиции первого уровня. На этой диаграмме отображаются функции системы, которые должны быть реализованы в рамках основной функции. Диаграмма, для которой выполнена декомпозиция, по отношению к детализирующим ее диаграммам называется родительской . Диаграмма декомпозиции по отношению к родительской называется дочерней .
Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.
Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)
Очередность выполнения функций для решения рассматриваемой задачи следующая:
Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);
Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;
Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;
Формирование ведомостей допускаемых скоростей (блок 5). На базе результатов расчета создаются несколько видов выходных документов, которые, с одной стороны, позволяют выявить причину ограничений скорости, с другой стороны, выступают в качестве основы для подготовки регламентированных документов;
Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).
После построения диаграммы декомпозиции первого уровня для указанных на ней функций строятся отдельные диаграммы (диаграммы декомпозиции второго уровня). Затем процесс декомпозиции (построения диаграмм) продолжается до тех пор, пока дальнейшая детализация функций не теряет смысла. Для каждой атомарной функции, описывающей элементарную операцию (т. е. функции, не имеющей диаграмму декомпозиции), составляется подробная спецификация, определяющая ее особенности и алгоритм реализации. В качестве дополнения к спецификации могут использоваться блок-схемы алгоритмов. Таким образом, процесс функционального моделирования заключается в постепенном выстраивании иерархии функций.
6.7. ICOM-коды
Стрелки, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и стрелки, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы (см. рис. и ). Как следствие этого, границы функции верхнего уровня – это то же самое, что и границы диаграммы декомпозиции.
ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).
Практикум по применению 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:
IDEF0 диаграммы строятся с помощью программы BPWin. Предназначены они для графического моделирования происходящих бизнес-процессов
О методологии IDEF0
Методология IDEF0 широко используется благодаря простой и понятной для понимания графической нотации, применение которой для построения модели очень удобное. Главное место в методологии отводится диаграммам. На диаграммах отображают функции системы посредством геометрических прямоугольников, а также имеющиеся связи между функциями и внешней средой. Связи отображаются с помощью стрелок. В этом можно убедиться, увидев, что предлагает IDEF0 диаграмма, примеры которой можно найти в данной статье.
Тот факт, что в моделировании используется всего два графических примитива, позволяет довольно быстро объяснить действующие правила взаимодействий IDEF0 тем людям, которые не имеют никакого представления об этом Посредством диаграмм IDEF0 подключение заказчика к происходящим процессам осуществляется более быстро благодаря использованию наглядного языка графики. Можно увидеть, что предлагает IDEF0 диаграмма, примеры которой представлены ниже.
Элементы, используемые для IDEF0
Как уже упоминалось, используется 2 типа геометрических примитивов: прямоугольники и стрелки. Прямоугольники обозначают определённые процессы, функции, работы или задачи, что имеют цели и ведут к обозначенному результату. Взаимодействие процессов между собой и внешней средой обозначается с помощью стрелок. В IDEF0 различают 5 различных типов стрелок.
Возможности использования IDEF0
Методологию IDEF0 можно применять для описи функционального аспекта любой информационной системы.
Типы связей между процессами IDEF0
В интересах модели создавать такие связи построений, чтобы внутренние связи были как можно сильней, а внешние - как можно слабей. Это сильная сторона моделирования с помощью IDEF0. Примеры диаграмм вы можете увидеть сами и убедиться в правдивости этих слов. Для облегчения установления связей подобные соединяются в модули. Между модулями устанавливаются внешние связи, а внутри модулей - внутренние. Различают несколько типов связей.
1. Иерархическая («часть» - «целое») связь.
2. Управляющая (регламентирующая, подчинённая):
2) обратная связь управления.
3. Функциональная или технологическая:
2) обратная входная.
3) потребительская;
4) логическая;
5) методическая или коллегиальная;
6) ресурсная;
7) информационная;
8) временная;
9) случайная.
Построение блоков и связей в диаграммах
Методология IDEF0 предоставляет целый ряд правил и рекомендаций по своему использованию и улучшению качества использования. Так, в диаграмме отображается один блок, на котором можно задать название системы, её назначение. К блоку или от блока ведёт 2-5 стрелок. Можно больше или меньше, но как минимум две стрелки необходимы для входа/выхода, а остальные для дополнительных работ и их указания на диаграмме. Если стрелок больше 5, следует задуматься об оптимальности построения модели, и нельзя ли сделать её ещё более детализированной.
Построение блоков в диаграммах декомпозиции
Количество блоков, которое будет на одной диаграмме, рекомендовано в численности 3-6. Если их меньше, то такие диаграммы вряд ли будут нести смысловую нагрузку. Если количество блоков будет огромным, то прочитать такую диаграмму будет весьма сложно, учитывая наличие ещё и дополнительных стрелок. Для улучшения восприятия информации размещать блоки рекомендуется сверху вниз и слева направо. Такое расположение позволит отразить логику исполнения последовательности процессов. А также стрелки будут создавать меньшую путаницу, обладая минимальным количеством пересечений друг с другом.
Если запуск определённой функции никак не контролируется, и процесс может быть запущен в произвольный момент, то такую ситуацию обозначают отсутствием стрелок, означающих управление и вход. Но наличие такой ситуации может говорить потенциальным партнерам об определенной нестабильности и необходимости внимательнее присмотреться к потенциальному партнеру.
Блок, у которого есть только стрелка входа, говорит о том, что процесс получает входные параметры, но управление и корректировка во время исполнения не происходят. Блок, у которого есть только стрелка управления, используется для обозначения работ, которые вызываются только по особому распоряжению управляющей системы. Они управляются и корректируются на всех своих этапах.
Но пример построения IDEF0 диаграммы может убедить, что наиболее полноценным и охватывающим типом является диаграмма со стрелками входа и управления.
Именование
Для улучшения визуального восприятия каждый блок и каждая стрелка должны иметь своё собственное имя, которое позволит идентифицировать их среди множества других блоков и стрелок. Так выглядят в IDEF0 примеры диаграмм. Информационная система, построенная с помощью них, позволит разобраться во всех недостатках и сложностях моделей.
Часто используется слияние стрелок, и встают вопросы об их именовании. Но слияние возможно только в случае передачи однородных данных, поэтому отдельные имена не нужны, хотя в программе BPWin их можно задать. Также, если происходит расхождение стрелок, то их можно отдельно наименовать, чтобы понимать, что за что отвечает.
Если после ветвления нет наименования, то считается, что имя точно такое, как было до ветвления. Так может быть, если два блока требуют одинаковую информацию. Контекстная диаграмма IDEF0, пример которой можно найти в данной статье, подтвердит эти слова.
Информация о стрелках
Стрелки, входящие и выходящие из одного блока при построении диаграммы композиции, должны отображаться на ней. Имена геометрических фигур, перенесённых на диаграмму, должны в точности повторять информацию высшего уровня. Если две стрелы параллельны относительно дуг друга (т.е. начинаются на грани одного процесса и заканчиваются обе на одной грани другого процесса), то возможно, для оптимизации модели их следует объединить и подобрать подходящее имя, что прекрасно отображается в IDEF0 (примеры диаграмм в Visio можно посмотреть).
Пример реализации методологии IDEF0 на конкретной модели
Вы уже узнали, что такое IDEF0 диаграмма, примеры и правила построения таких диаграмм частично увидели. Теперь следует обратиться и к практике. Для лучшего понимания объяснение будет идти не на какой-то «общей» модели, а на конкретном примере, который позволит лучше и полнее понять особенности работы с IDEF0 в программе BPWin.
В качестве примера выступит скорость движения поезда из точки А в точку Б. Необходимо принять во внимание, что поезд не может развивать скорость больше взятой за допустимую. Эта грань устанавливается на основе опыта эксплуатации и влияния составов на железнодорожном пути. Следует понимать, что целью состава является доставка пассажиров, которые, в свою очередь, заплатили, чтобы в безопасности и с комфортом добраться до пункта назначения. Полезна IDEF0 диаграмма, примеры которой можно найти в этой статье.
Исходной информацией выступают:
- данные про линию путей;
- паспорт всей дистанции;
- план пути.
Управляющие данные:
- Указание начальника, заведующего службой путей.
- Сведения о существующем потоке передвижения составов.
- Сведения о запланированных ремонтах, реконструкциях и изменении путей.
Результатом модели является:
- Ограничение допустимых скоростей с указанием причины ограничения.
- Допустимые скорости при движении на раздельных пунктах и во время перегона составов.
Когда построена контекстная диаграмма, она должна быть детализирована, и затем создана композитная диаграмма, которая будет диаграммой первого уровня. На ней будут изображены все основные функции системы. Методология и диаграмма IDEF0, для которой делается декомпозиция, именуется родительской. IDEF0 декомпозиции называют дочерней.
Заключение
После декомпозиции на первом уровне проводится декомпозиция второго уровня - и так до тех пор, пока дальнейшая декомпозиция не потеряет своего смысла. Всё это делается для получения максимально детализированной графической схемы происходящих и планируемых процессов. Это готовый пример IDEF0 диаграммы, по которому вы можете ориентироваться уже сейчас.
Одна картинка стоит тысячи слов
Народная мудрость
Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, неважно, идет речь об организации работы склада или об IT системе (от лида до заявки). Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.
Несколько слов о преимуществах графики
Как известно, функциональные модели IDEF0 - это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.
И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя - много-много слов. И понять в итоге, что же происходит, было очень сложно.
А потому идея Сытина была поистине революционной - он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.
Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену - это и правда очень сложно.
Этому клиенту я предложил альтернативный вариант - описать все, что можно, графически в виде нотаций. Показал ему примеры моделирования. В итоге они сейчас переосмысливают свои пожелания и оформление технического задания.
Знаю я также много других примеров, когда графическое моделирование бизнес-процессов помогало в работе как моим коллегам, бизнес-консультантам и разработчикам, так и самим бизнесменам
Почему это важно для моей работы
Моя работа всегда связана с внесением изменений в существующую систему. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.
После изучения существующего положения вещей я, как и любой другой сторонний специалист, создаю коммерческое предложение, в котором максимально подробно раскрываю мое видение текущей ситуации, а также действия, которые необходимо выполнить для решения поставленной задачи, и, конечно, ожидаемый результат.
Такие отчеты об обследовании работы получаются объемные, занимают не одну страницу, что с одной стороны, необходимо, а с другой – усложняет восприятие. Вначале я, как и многие, думал, что объемные отчеты - это хорошо, ведь человек платит за работу и нужно ему предоставить максимум подробной информации.
На самом деле, важно не предоставить объем, а максимально быстро и полно донести суть. Большие объемы текста требуют времени, которого у бизнесменов чаще всего очень мало. А графика позволяет сократить объем моего предложения и наглядно, в понятной форме показать решение. В результате мои предложения значительно сократились, в них появилась графика, а решения о начале сотрудничества стали приниматься быстрее.
Именно по этой причине я использую наглядные модели. Как известно, одна картинка стоит тысячи слов. И в случае описания бизнес-процессов и вариантов модернизации работы бизнеса – это действительно так. И здесь очень хорошо подходят нотации IDEF0.
Но для начала, давайте разберемся с основными понятиями, что такое нотации, зачем они нужны, что такое IDEF0, в чем особенности и преимущества этого метода
Что такое нотация описания бизнес-процессов
Нотацией называется формат описания бизнес-процесса, представляющий собой совокупность графических объектов, используемых при моделировании, а также правил моделирования.
По сути, нотации – это особый графический язык, который позволяет описывать работу компании, наглядно демонстрировать взаимодействие между различными подразделениями, т.е. описывать бизнес-процессы. Нотации могут применяться для процессного или функционального моделирования.
В общем, нотации можно назвать языком программирования при бизнес-анализе
Что такое IDEF0?
IDEF0 - методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временнаL9;я последовательность (поток работ). Википедия
Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.
Функциональная модель компании
Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные.
Стрелки могут быть:
- Входящие – вводные, которые ставят определенную задачу.
- Исходящие – выводящие результат деятельности.
- Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
- Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.
Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается еще и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения.
Стрелки подписываются при помощи имен существительных (опыт, план, правила), а блоки – при помощи глаголов, т.е. в них описываются действия, которые производятся (создать товар, заключить договор, произвести отгрузку).
IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.
Кроме того, использование для создания бизнес-моделей IDEF0 - это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.
Как известно, забивать гвозди лучше всего молотком. Конечно, вы можете для этого применять и другие инструменты, но молоток - наиболее функционален и с его помощью проще всего забить гвоздь аккуратно и точно. Так и с применением IDEF0 - этот инструмент был создан для функционального моделирования, и с его помощью вы намного быстрее и точнее сможете получить нужный результат.
Пример создания функциональной модели IDEF0
Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи.
Основной блок – «Написать статью».
Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.
Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».
А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.
Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.
На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы.
В нашем случае работа делится на 4 основных этапа:
- Подготовить аудио.
- Подготовить текст
- Подготовить текст к публикации.
- Разместить статью в издании.
На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы.
Так, автор при создании аудио использует свои знания и опыт, при этом руководствуется планом публикации и требованиями издателя. Копирайтер получает на входе аудиозапись, из которой, руководствуясь правилами русского языка, создает текст. Корректор получает текст и проверяет его, также руководствуясь правилами русского языка. Для размещения статьи в издании необходимо специальное программное обеспечение.
При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».
Так, если бы тот же процесс был описан с точки зрения копирайтера, то входящими были бы опыт и аудиофайл от автора. При этом в таком случае под Опытом подразумевался бы опыт копирайтера, но не руководителя или автора. А потому первое, что нужно определить при создании модели бизнес-процесса – это выбрать точку зрения и четко сформулировать цель.
Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста - копирайтер и корректор. Если я поставлю задачу оптимизировать финансирование проекта, то я благодаря схеме сразу увижу, где это и как можно сделать. Так, к копирайтер и корректор пользуются примерно одинаковыми правилами, но копирайтер получает аудио, а выдает результат в виде текста, корректор же и принимает, и отдает текст. А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю - у меня стоит задача: оптимизация затрат.
Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.
Как создавать нотации IDEF0
Существует множество различных программных продуктов, которые можно применять при создании нотаций. Какие-то созданы специально для функционального моделирования, другие предназначены для любой работы с графическими элементами. Где и как вы будете строить эти модели – решать вам.
Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок.
Для того чтобы создать нотацию существующих бизнес-процессов, т.е. описать, как сейчас работает компания, необходимо принципы работы изучить. Сторонний специалист (консультант, разработчик) для этого проводит интервью. На первом этапе на вопросы отвечает руководитель компании, далее в процессе детализации нотации проводятся интервью сотрудников, отвечающих за различные этапы работы.
При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях.
Вторая нотация – «как должно быть». Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи.
Требования стандарта IDEF0
Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.
- В левом верхнем углу всегда – главный элемент.
- Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
- Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
- Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
- Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.
Типичные ошибки
Функциональное моделирование выполняют при помощи самых разных инструментов, в том числе, не предназначенных для моделирования. В последнем случае нет проверки на ошибки и ограничения стандарта. Желание повысить наглядность и отсутствие опыта при этом часто оканчиваются ошибками.
Использование различных цветов
Все элементы на диаграмме одинаково важны. При функциональном моделировании нет более или менее важных элементов. Исчезновение любого приведет к нарушению процесса и производственному браку.
Часто при моделировании на бумаге или в различных программах пользователи пытаются повысить наглядность за счет использования разных цветов. Это одна из самых распространенных ошибок. На самом деле, применение разноцветных стрелок и блоков только вносит дополнительную путаницу, а также искажает восприятие схемы.
Ваша модель должна читаться в черно-белом виде, без каких-то дополнительных цветовых решений. Такой подход одновременно помогает избежать недоразумений и дисциплинирует создателя модели, в результате читабельность и грамотность модели повышаются.
Слишком большое количество блоков
При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок. Читабельность при этом теряется.
Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.
Нарушение структуры при внесении корректировок
Внимательно следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов. Например, если в приведенном выше примере, я посчитаю нужным сместить точку зрения на копирайтера, я удалю из схемы автора. И тогда управляющие элементы «опыт автора и сторонние источники», а также план публикации становятся ненужными. Ведь ими пользуется автор. Копирайтер работает с аудиофайлом. И если они останутся в общей схеме, то при детализации будут вести непонятно куда и вносить путаницу.
Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.
Правила названия управляющих элементов и блоков
Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок.
Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.
Выгоды использования IDEF0
- Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
- Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
- Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема - это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
- Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.
В чем трудность применения IDEF0
Важно понимать, что только в самых простых случаях два бизнес-аналитика создадут для описания работы компании абсолютно одинаковые функциональные модели. Любая модель – это отражение опыта аналитика, глубины понимания работы бизнеса, который он стремится описать, а также, в некотором роде, его личная точка зрения на этот бизнес. Т.е. человек разрабатывает бизнес-модель с точки зрения руководителя, как будто этим руководителем является именно он.
При этом я считаю, что бизнес-аналитик - это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0.
А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками. Только если ваша функциональная модель «как есть» будет действительно отражать реальное положение вещей, можно вносить какие-то изменения и предложения. А для достижения качественных результатов в такой работе требуется, прежде всего, практический опыт и знание особенностей того или иного вида бизнеса.