Содержание курса

• ВВЕДЕНИЕ

• Введение в процесс формирования требований

• Инфраструктура (ландшафт) для организации проектной деятельности

• Управление целями заинтересованных лиц

• Формализация потребностей заказчика

• Выявление функции системы. 1.Теория систем

• Выявление функции системы. 2. Моделирование сервисов

• Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity

• Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.

• Разработка логической структуры данных целевой Информационной системы(ИС)

• Моделирование поведения целевой системы. Моделирование процессов управления

• Формирование спецификаций требований на создание целевой ИС

• Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта

• Организация процессов проектирования в производстве ИТ-продукта

3.2.  Диаграмма BPMN

Рассмотрим еще один из популярных инструментов BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный Object Management Group (OMG). Он широко используется для визуализации, анализа и оптимизации процессов внутри организаций.

Но в отличие от прочих нотаций, BPMN может использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. То есть бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код, который интерпретируется движком, При этом продвигая процессы в соответствии с описанной в диаграммах бизнес-логикой, BPMN-движок следит за выполнением шагов, направляет задачи сотрудникам, вызывает API сервисы, генерирует события, фиксирует в Базе Данных (далее – БД) результат и тому подобное. Помимо того, такой инструмент выполняет мониторинг и логирование каждого запущенного экземпляра процесса, фиксирует его прогресс и актуальные состояния в БД. То есть предоставляется возможность отлаживать процессы уже в ходе их исполнения, наблюдая на конкретных запущенных экземплярах последовательность их шагов изнутри, фиксировать значения параметров, переменных, условий и прочее.

Пробежимся вкратце по основным понятиям языка.

Язык описания бизнес-процессов BPMN опирается на следующие базовые элементы:

• Event – Событие;

• Activity – Действия;

• Gateway – Шлюзы или Развилки;

• Flow – Поток.

• Date – Данные;

• Artefact – Артефакты;

• Swimline – «дорожки»;

• Pool (Пул) — набор.

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

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

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

• Событие BPMN с типом «Таймер» показывает ожидание процессом регулярного события, определенного момента времени или временного периода. На время ожидания текущий поток управления бизнес-процесса приостанавливается. Графически событие BPMN «Таймер» отображается в виде круга с триггером в виде часов внутри.

• Событие BPMN «Сигнал» обозначает ожидание или отправку сигнала между процессами. Это событие похоже на событие с типом «Сообщение» по следующим признакам:

  • по типу расположения в процессе (может быть стартовым, промежуточным или конечным);

  • о типу влияния на процесс (может быть событием обработчиком или событием инициатором);

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

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

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

• Событие BPMN «Компенсация» показывает начало выполнения компенсирующих действий (событие-обработчик) или инициирование компенсации в процессе (событие-инициатор). Сам термин «Компенсация» обозначает отмену одного или более действий процесса, предшествующих событию-компенсации. Необходимость использования события BPMN с типом «Компенсация» связана с тем, что иногда нужно отменить выполнение некоторых задач в процессе. Типичные примеры таких задач:   Бронирование билетов; Аренда автомобиля; Пополнение кредитной карты; Заключение договора с поставщиком услуг и так далее

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

Обычно действия делят на:

• Процесс – крупное действие, которое требует дальнейшей детализации при моделировании.

• Задача – элементарное действие, которое уже не может быть дальше детализировано.

При этом действие может иметь разный характер. Прослеживается аналогия со "стереотипом" в нотации Activity. Вариативность может быть такой:

• User Task ? Выполняется человеком через интерфейс (например, проверка заявки)

• Service Task ⚙️ Выполняется автоматически через сервис/API (например, вызов REST-сервиса)

• Script Task ? Выполняется встроенный скрипт (например, расчёт комиссии)

• Manual Task ✋ Выполняется вручную без системы (например, физическая доставка)

• Receive Task ? Ожидание получения сообщения или события

• Send Task ? Отправка сообщения или уведомления

• Business Rule Task ? Выполняется бизнес-правило (например, через DMN-движок)

• Call Activity  ? Вызов внешнего процесса или подпроцесса

• Embedded Sub-Process ? Встроен внутрь диаграммы, разворачивается при моделировании

• Reusable Sub-Process (Call Activity) ? Внешний процесс, можно использовать повторно

• Event Sub-Process ? Выполняется при наступлении события (например, таймера, ошибки)

• Transaction Sub-Process ? Поддерживает свойства транзакции (откат, подтверждение)

• Ad-Hoc Sub-Process ? Неструктурированная группа действий, порядок выполнения не определён

Gateway – это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба. По большому счету аналог Разветвления управления в нотации Activity, но с более широкими возможностями.

• Эксклюзивный шлюз BPMN (Логический оператор исключающего ИЛИ, управляемый данными) используется для разделения потоков управления на альтернативные маршруты. В зависимости от заданного условия может быть выбран только один маршрут.

• Неэксклюзивный (включающий) шлюз BPMN (Логический оператор ИЛИ) используется для разделения потока управления на несколько альтернативных параллельных маршрутов. В зависимости от выбранного условия активируется один или несколько маршрутов.

• Комплексный шлюз BPMN (Сложный логический оператор) позволяет моделировать сложные условия ветвления и слияния, которые невозможно смоделировать другими видами шлюзов. Данный шлюз не рекомендуется использовать на диаграммах, поскольку он имеет нечеткую семантику.

• Параллельный шлюз BPMN (Логический оператор И) разделяет поток управления.

• Эксклюзивный событийный шлюз BPMN (Логический оператор исключающего ИЛИ, управляемый событиями) используется для выбора альтернативного маршрута процесса. Исходящие потоки управления данного шлюза должны быть связаны только с событиями или задачами – обработчиками сообщений. Поток управления направляется по той ветви, событие по которой наступит раньше других. Остальные события будут проигнорированы.

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

Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.

Message Flows – это пунктирные стрелки в бизнес-модели, которые показывают сообщения, которыми обмениваются участники бизнес-процесса.

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

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

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

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

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

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

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

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

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

5.    Итоги этапа моделирование бизнес-процессов

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

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

2)    Выявление пользователей процессов. Позволяет сгруппировать основные направления деятельности по ролям исполнителей.

3)    Определение связей между процессами и хранилищами. Это поможет плавно перейти от моделей процессов к моделям данных. А также установить все «точки» обращения к хранилищам для выборки и записи данных, для выявления узких мест системы

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

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

6)    Определение объектов системы: форм, функций, кнопок и т.п. Указание стереотипов операции, поможет определить вероятные трудозатраты и подготавливать план-график проекта для расчёта предварительных затрат на производство Продукта.

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

В следующей части мы рассмотрим моделирование Бизнес-объектов и проектирование хранилищ данных.