Методические рекомендации по выполнению лабораторных работ по курсу «Управление процессами» для студентов специальности 220501. 65 «Управление качеством» (стр. 4 из 10)

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

Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:

- Обобщает ли диаграмма моделируемый бизнес-процесс?

- Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?

- Подходит ли выбранный уровень детализации стрелок для контекстного блока? (Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.)

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

Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок А0 декомпозируется в блоки A1, А2, A3 и т.д. А1 декомпозируется в A11, A12, А13 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.

1.3.3 Два подхода к началу моделирования

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

1.4 Другие диаграммы IDEF0

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

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

Презентационные диаграммы (For Exposition Only diagrams - FEO diagrams) часто включают в модели, чтобы проиллюстрировать другие точки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Естественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она будет выглядеть как обыкновенная диаграмма IDEF0, удовлетворяя всем ограничениям IDEF0.

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

2 Методология описания бизнес-процессов IDEF3

2.1 Назначение методологии IDEF3

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

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

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

2.2 Синтаксис и семантика графического языка IDEF3

2.2.1 Модели IDEF3

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

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

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

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

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

2.2.2 Действие

Аналогично другим технологиям моделирования действие, или в терминах IDEF3 «единица работы» (Unit of Work – UOW), в диаграммах IDEF3 отображается в виде прямоугольника. Каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рисунок 12).

Рисунок 12 – Изображение и нумерация действия в диаграмме IDEF3

2.2.3 Связи

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

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

Таблица 2 – Типы связей в модели IDEF3

Изображение	Название	Назначение
	Временное предшествование (Temporal precedence)	Исходное действие должно завершиться прежде, чем конечное действие сможет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия. Исходное действие должно завершиться прежде, чем конечное действие сможет начаться
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения

Рисунок 13 – Связь типа «Временное предшествование» между
действиями 1.1 и 1.2

Связь типа «Объектный поток». Одна из наиболее часто встречающихся причин использования связи типа «Объектный поток» состоит в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Такая связь отличается от связи временного предшествования двойным концом обозначающей ее стрелки. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования. Это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие начнет выполняться, как показано на рисунке 14. В приведенном примере счет на оплату услуг является результатом выполнения действия 1.1. Счет необходим для проведения оплаты услуг.