Вы находитесь на странице: 1из 41

3.

Моделирование бизнес
процессов
3.1. Определение бизнес
процесса
• Бизнес процессом называется
последовательность работ, которая:
– связана с деятельностью организации;
– является устойчивой, т. е. повторяется;
– ориентирована на создание новой
стоимости.
• Бизнес процесс представляется как
иерархия взаимосвязанных действий,
реализующих одну или несколько целей
системы.
• Примеры целей бизнес процесса:
– выпуск продукции;
– ресурсное обеспечение выпуска
продукции.
• Под продукцией понимают товары,
услуги или документы.
• В UML бизнес процесс определяется
как набор действий (активностей),
целью которых является производство
некоторого продукта для заказчика или
рынка.
• Для моделирования бизнес-процессов
широко используются следующие стандарты:
– IDEF0 (Integration Definition for Function Modeling);
– BPMN (Business Process Modeling Notation).
• Эти стандарты представляют собой
графическую нотацию для описания и
моделирования бизнес-процессов.
• Стандарт IDEF0 реализован в таких пакетах
как IDEF0.EM Tool, IDEF0\Doctor, BPWin,
Office Visio 2007.
3.2. Стандарт IDEF0
• Стандарт IDEF0 предназначен для
моделирования:
– функций (действий, процессов,
операций), исполняемых системой или
предприятием;
– функциональных отношений и данных
(информации или объектов), которые
поддерживают интеграцию этих функций.
• Применимость стандарта IDEF0:
– моделирование информационных систем
для их анализа, разработки,
реинжиниринга, интеграции и сборки;
– моделирование бизнес-процессов
предприятий для их анализа;
– моделирование процессов (методологий)
разработки программного обеспечения.
• Результатом применения стандарта
IDEF0 является модель.
• Модель состоит из диаграмм, текста
и словаря терминов, имеющих
перекрестные ссылки друг на друга.
• Диаграммы - основной компонент
модели.
• Все функции и взаимодействия
отображаются на диаграммах в виде
прямоугольников (функции) и стрелок
(взаимодействия).
• Основные элементы стандарта IDEF0:
– функциональный блок;
– интерфейсная дуга.
• Функциональный блок (Activity Box):
– изображается в виде прямоугольника;
– представляет некоторую функцию,
рассматриваемую в рамках системы;
– название функционального блока должно
иметь глагольное наклонение.
• Интерфейсная дуга (Arrow):
– изображается в виде стрелки;
– обозначает элемент (объект или
документ), который обрабатывается
функциональным блоком или влияет на
функциональный блок;
– название дуги должно быть оборотом
существительного.
• Каждый функциональный блок должен
иметь уникальный номер и, по
крайней мере, одну управляющую и
одну исходящую дуги.
• Каждая интерфейсная дуга должна
иметь уникальное название.
• Каждая сторона функционального блока
имеет свое назначение:
– левая – вход, представляет ресурсы (данные
или предметы) над которыми производится
действие в ходе операции);
– правая – выход, представляет продукты,
которые являются результатом исполнения
функционального блока;
– верхняя – управление, представляет
управляющие воздействия на функциональный
блок;
– нижняя – механизм, представляет средства
исполнения функционального блока.
• Вызов - это разновидность механизма,
которая позволяет использовать одну и
ту же часть диаграммы в нескольких
моделях или в нескольких частях одной
модели.
• Третьим основным понятием стандарта
IDEF0 является декомпозиция
(Decomposition).
• Принцип декомпозиции применяется при
разбиении сложного процесса на
составляющие его функции. При этом
уровень детализации процесса определяется
непосредственно разработчиком модели.
• Декомпозиция позволяет постепенно и
структурировано представлять модель
системы в виде иерархической структуры
отдельных диаграмм, что делает ее менее
перегруженной и легко усваиваемой.
• Модель IDEF0 всегда начинается с
представления системы как единого
целого – одного функционального
блока с интерфейсными дугами,
простирающимися за пределы
рассматриваемой области.
• Такая диаграмма с одним
функциональным блоком называется
контекстной диаграммой, и
обозначается идентификатором “А-0”.
Пример контекстной диаграммы
Декомпозиция контекстной диаграммы
• Ограничения сложности на диаграммы
(необязательные):
1. Ограничение количества функциональных
блоков на диаграмме тремя-шестью.
2. Ограничение количества подходящих к
одному функциональному блоку (выходящих
из одного функционального блока)
интерфейсных дуг четырьмя.
• В пояснительном тексте к контекстной
диаграмме должна быть указана цель
(Purpose) построения диаграммы в виде
краткого описания и зафиксирована точка
зрения (Viewpoint).
3.3. Стандарт BPMN
• BPMN определяет графические
элементы для моделирования бизнес
процессов. Моделью бизнес процесса
является графическая диаграмма,
которая состоит из активностей
(activities, works) и потоков
управления (flow controls), которые
определяют порядок исполнения
активностей.
• BPMN предназначена для
моделирования только бизнес
процессов и не поддерживает
моделирование структуры организации
и функциональных требований.
• BPMN ориентирована на
моделирование двух базовых типов
бизнес-процессов:
– сотрудничество (collaborations) или
публичный (public) бизнес процесс;
– внутренний (internal) или частный
(private) бизнес процесс.
• Сотрудничество это бизнес процесс,
которые представляет собой
взаимодействие нескольких участников
этого бизнес процесса.
• Частный вид сотрудничества бизнес
процесс B2B (business to business).
• Внутренний бизнес процесс это
бизнес процесс, которые происходит
внутри организации и невидим вне этой
организации.
• Графические элементы BPMN:
– элементы потока (flow elements);
– соединительные элементы (connecting
elements);
– разделители (swimlanes);
– артефакты (artifacts).
Элементы потока
• Активность или действие (activity) –
это работа, которая исполняется внутри
бизнес процесса.
• Обозначения для активности:
• Событие (event) – это что-то
происшедшее во время исполнения
бизнес процесса и повлиявшее на
последовательность или
продолжительность активностей.
• Различаются три типа событий:
– начальное (start);
– промежуточное (intermediate);
– конечное (end).
• Обозначения событий:
• Слияния-разъединения (gateway) –
используются для слияния и
разъединения потока активностей.
Различаются следующие типы слияний-
разъединений:
– слияние-разъединение (gateway)
– ветвление-соединение (fork / join);
– inclusive decision / merge
• Обозначение слияний-разъединений:
• Соединительные элементы включают
три типа соединений:
– последовательности потока
(sequence flow) – показывает
последовательность исполнения
активностей бизнес процесса;
– потока сообщений (message flow) –
показывает поток сообщений между
участниками бизнес процесса;
– ассоциации (association) – используется
для соединения информации и артефактов
с объектами бизнес процесса.
• Обозначение соединительных
элементов:
• Разделители включают элементы
двух типов:
– пулы (pools) – это соглашения между
предпринимателями для устранения
конкуренции, здесь отдельная часть бизнес
процесса;
– подразделения (lanes) – это части пула
для организации активностей внутри пула.
• Обозначаются подразделения
следующим образом:
• Артефакты включают три типа
объектов:
– объекты данных (data objects) – это
объекты, которые содержат информацию о
бизнес-процессе, но на исполнение бизнес
процесса не влияют;
– группы (groups) – используются для
группирования объектов в бизнес-
процессе;
– аннотации (annotations) – объекты для
представления дополнительной
информации о бизнес-процессе.
• Обозначение артефактов:
Пример бизнес процесса с нормальным
потоком
Пример бизнес процесса с пулами
3.4. Моделирование бизнес
процессов в UML
• Профилем в UML называется пакет
элементов для моделирования в
определенной прикладной области.
• Элементы профиля имеют специальные
стереотипы, свойства и ограничения.
• В UML бизнес-процесс определяется как
последовательность действий (активностей),
целью которых является создание
определенного продукта для заказчика или
рынка.
Профиль Эрикссона-Пенкера для
моделирования бизнес процессов в UML
• Для моделирования бизнес процессов в
системе SPARX EA используется
профиль Эриксонна-Пенкера (Ericsson-
Penker), в котором определены
следующие стереотипы:
– для активности определен стереотип
<<Business process>> - бизнес процесс;
– для объектов, которые инициируют
исполнение бизнес процесса, определен
стереотип <<Event>> - событие.
• - для связи бизнес-процесса с объектами, от которых
зависит его исполнение, определены следующие
стереотипы для отношения зависимости:
– <<goal>> цель – связывает бизнес процесс с причиной, из-
за которой организация выполняет бизнес процесс;
– <<supply>> обеспечить – связывает бизнес процесс с
объектами, которые содержат информацию для
обеспечения исполнения бизнес процесса;
– <<input>> ввод – связывает бизнес процесс с объектами,
которые используются (обрабатываются) в процессе
исполнения бизнес процесса.
– <<output>> вывод – отмечает объекты, которые являются
результатом исполнения этого бизнес процесса;
– <<control>> управление – связывает бизнес процесс с
объектами, которые управляют бизнес процессом.
Пример бизнес-процесса разработки
программной системы
analysis Analysis v iew

Удовлетворение
требований
заказчика

«goal»

Разработка программной
Спецификация системы Программная
программной система
системы «input» «output»

«supply» «supply»

Разработчики Средства
разработки