Слайд 13. Моделирование бизнес процессов
Слайд 23.1. Определение бизнес процесса
Бизнес процессом называется последовательность работ, которая:
связана с
деятельностью организации;
является устойчивой, т. е. повторяется;
ориентирована на создание новой стоимости.
Слайд 3Бизнес процесс представляется как иерархия взаимосвязанных действий, реализующих одну или несколько
целей системы.
Примеры целей бизнес процесса:
выпуск продукции;
ресурсное обеспечение выпуска продукции.
Под продукцией понимают товары, услуги или документы.
Слайд 4В UML бизнес процесс определяется как набор действий (активностей), целью которых
является производство некоторого продукта для заказчика или рынка.
Слайд 5Для моделирования бизнес-процессов широко используются следующие стандарты:
IDEF0 (Integration Definition for
Function Modeling);
BPMN (Business Process Modeling Notation).
Эти стандарты представляют собой графическую нотацию для описания и моделирования бизнес-процессов.
Стандарт IDEF0 реализован в таких пакетах как IDEF0.EM Tool, IDEF0\Doctor, BPWin, Office Visio 2007.
Слайд 63.2. Стандарт IDEF0
Стандарт IDEF0 предназначен для моделирования:
функций (действий, процессов, операций),
исполняемых системой или предприятием;
функциональных отношений и данных (информации или объектов), которые поддерживают интеграцию этих функций.
Слайд 7Применимость стандарта IDEF0:
моделирование информационных систем для их анализа, разработки, реинжиниринга,
интеграции и сборки;
моделирование бизнес-процессов предприятий для их анализа;
моделирование процессов (методологий) разработки программного обеспечения.
Слайд 8Результатом применения стандарта IDEF0 является модель.
Модель состоит из диаграмм, текста
и словаря терминов, имеющих перекрестные ссылки друг на друга.
Диаграммы - основной компонент модели.
Все функции и взаимодействия отображаются на диаграммах в виде прямоугольников (функции) и стрелок (взаимодействия).
Слайд 9Основные элементы стандарта IDEF0:
функциональный блок;
интерфейсная дуга.
Слайд 10Функциональный блок (Activity Box):
изображается в виде прямоугольника;
представляет некоторую функцию,
рассматриваемую в рамках системы;
название функционального блока должно иметь глагольное наклонение.
Слайд 11Интерфейсная дуга (Arrow):
изображается в виде стрелки;
обозначает элемент (объект или
документ), который обрабатывается функциональным блоком или влияет на функциональный блок;
название дуги должно быть оборотом существительного.
Слайд 12Каждый функциональный блок должен иметь уникальный номер и, по крайней мере,
одну управляющую и одну исходящую дуги.
Каждая интерфейсная дуга должна иметь уникальное название.
Слайд 13Каждая сторона функционального блока имеет свое назначение:
левая – вход, представляет
ресурсы (данные или предметы) над которыми производится действие в ходе операции);
правая – выход, представляет продукты, которые являются результатом исполнения функционального блока;
верхняя – управление, представляет управляющие воздействия на функциональный блок;
нижняя – механизм, представляет средства исполнения функционального блока.
Слайд 14Вызов - это разновидность механизма, которая позволяет использовать одну и ту
же часть диаграммы в нескольких моделях или в нескольких частях одной модели.
Слайд 15Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition).
Принцип декомпозиции применяется при
разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Слайд 16Модель IDEF0 всегда начинается с представления системы как единого целого –
одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области.
Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.
Слайд 18Декомпозиция контекстной диаграммы
Слайд 19Ограничения сложности на диаграммы (необязательные):
Ограничение количества функциональных блоков на диаграмме тремя-шестью.
Ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Слайд 203.3. Стандарт BPMN
BPMN определяет графические элементы для моделирования бизнес процессов. Моделью
бизнес процесса является графическая диаграмма, которая состоит из активностей (activities, works) и потоков управления (flow controls), которые определяют порядок исполнения активностей.
Слайд 21BPMN предназначена для моделирования только бизнес процессов и не поддерживает моделирование
структуры организации и функциональных требований.
BPMN ориентирована на моделирование двух базовых типов бизнес-процессов:
сотрудничество (collaborations) или публичный (public) бизнес процесс;
внутренний (internal) или частный (private) бизнес процесс.
Слайд 22Сотрудничество это бизнес процесс, которые представляет собой взаимодействие нескольких участников этого
бизнес процесса.
Частный вид сотрудничества бизнес процесс B2B (business to business).
Внутренний бизнес процесс это бизнес процесс, которые происходит внутри организации и невидим вне этой организации.
Слайд 23Графические элементы BPMN:
элементы потока (flow elements);
соединительные элементы (connecting elements);
разделители (swimlanes);
артефакты (artifacts).
Слайд 24Элементы потока
Активность или действие (activity) – это работа, которая исполняется внутри
бизнес процесса.
Обозначения для активности:
Слайд 25Событие (event) – это что-то происшедшее во время исполнения бизнес процесса
и повлиявшее на последовательность или продолжительность активностей.
Различаются три типа событий:
начальное (start);
промежуточное (intermediate);
конечное (end).
Слайд 27Слияния-разъединения (gateway) – используются для слияния и разъединения потока активностей. Различаются
следующие типы слияний-разъединений:
слияние-разъединение (gateway)
ветвление-соединение (fork / join);
inclusive decision / merge
Слайд 28Обозначение слияний-разъединений:
Слайд 29Соединительные элементы включают три типа соединений:
последовательности потока (sequence flow) –
показывает последовательность исполнения активностей бизнес процесса;
потока сообщений (message flow) – показывает поток сообщений между участниками бизнес процесса;
ассоциации (association) – используется для соединения информации и артефактов с объектами бизнес процесса.
Слайд 30Обозначение соединительных элементов:
Слайд 31Разделители включают элементы двух типов:
пулы (pools) – это соглашения между
предпринимателями для устранения конкуренции, здесь отдельная часть бизнес процесса;
подразделения (lanes) – это части пула для организации активностей внутри пула.
Слайд 32Обозначаются подразделения следующим образом:
Слайд 33Артефакты включают три типа объектов:
объекты данных (data objects) – это
объекты, которые содержат информацию о бизнес-процессе, но на исполнение бизнес процесса не влияют;
группы (groups) – используются для группирования объектов в бизнес-процессе;
аннотации (annotations) – объекты для представления дополнительной информации о бизнес-процессе.
Слайд 35Пример бизнес процесса с нормальным потоком
Слайд 373.4. Моделирование бизнес процессов в UML
Профилем в UML называется пакет элементов
для моделирования в определенной прикладной области.
Элементы профиля имеют специальные стереотипы, свойства и ограничения.
В UML бизнес-процесс определяется как последовательность действий (активностей), целью которых является создание определенного продукта для заказчика или рынка.
Слайд 38Профиль Эрикссона-Пенкера для моделирования бизнес процессов в UML
Слайд 39Для моделирования бизнес процессов в системе SPARX EA используется профиль Эриксонна-Пенкера
(Ericsson-Penker), в котором определены следующие стереотипы:
для активности определен стереотип <> - бизнес процесс;
для объектов, которые инициируют исполнение бизнес процесса, определен стереотип <> - событие.
Слайд 41Пример бизнес-процесса разработки программной системы