Использование нотаций ARIS и BPNM для описания процессов: почему необходимо следовать правилам

Здравствуйте! Меня зовут Сергей Гусев, я ведущий системный аналитик IT_One. В данной статье я бы хотел затронуть важные нюансы деятельности системного аналитика и команд разработки ПО.

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

Эти инструменты позволяют описать то, как будет работать продукт и как пользователи будут с ним взаимодействовать. Чаще всего получается довольно объемный документ или набор документов, где описаны функциональные и нефункциональные требования, варианты взаимодействия (use case diagrams) и чек-листы для тестирования. Что же из этого лучше с точки зрения разработчика? В идеале – это готовый прототип программного продукта, демонстрирующий, как пользователь взаимодействует с ним, что именно требуется разработать, как и в какой последовательности должны появляться окна для заполнения информации. Остается только открыть текстовый документ, чтобы в нем свериться со свойствами атрибутов. Увы, чаще всего из-за нехватки времени и желания сэкономить многие команды пренебрегают созданием такой модели.

Второй, не менее популярный, метод — это описание функционирования продукта с помощью нотаций ARIS eEPC и BPMN 2.0. Чем же они удобны?

Преимущества ARIS eEPC – простыми словами

Нотацию ARIS eEPC разработал основатель IDS Scheer Август Вильгельм Шеер со своими коллегами. Взяв за основу методологию IDEF3, он дополнил ее до модели EPC – расширенной цепочки процесса, управляемого событиями, которую позже стали называть «процессно-событийная модель» (дословно Event-driven Process Chain). Используемая для моделирования бизнес-процессов в инструментарии ARIS, она представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение определенного результата. По сути, если созданная модель описывает функциональность разрабатываемого ПО, то она является инструкцией для разработчика.

Посмотрим на основные компоненты данной нотации:

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

Событие – описывает состояние процесса, которое является существенным в рамках этого процесса и оказывает влияние на этот бизнес-процесс или контролирует его дальнейшее развитие

Операторы «И», «Или», «Исключающее ИЛИ», служат для развилок по какому сценарию далее пойдет выполнение сценария в зависимости от того. что выберет пользователь или какой будет вариант ответа на вопрос.

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

IT system используется для отображения на диаграмме некоторой информационной системы, её модуля или даже отдельной функции ИС, поддерживающей выполнение функции, с которой её связывают в модели.

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

Функции в модели ARIS EPC запускаются событиями: например, «Поступила заявка на рассмотрение». Событиями они и оканчиваются: например, «Запрос удовлетворён» или «Заявка отклонена». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, – событие между этими функциями может не рисоваться. В Интернете можно найти множество статей на данную тему и детально познакомиться с данной нотацией.

Какое преимущество она имеет с точки зрения разработчика? Лично мне нравится работа с данной нотацией потому, что я вижу, какие окна программы могу создать, что расположить на них, где сделать развилки с вариантами выбора, разместить загрузчики файлов и т.п. Мне остается только посмотреть типы полей и ограничений, чтобы создать модель базы данных и разместить соответствующие компоненты в окнах программы. Нет необходимости в чтении обширной документации по продукту. Это очень удобно, особенно когда я попадаю в проект не в самом начале или подменяю коллегу, который заболел или в отпуске. С помощью этой нотации понять смысл продукта, как он должен работать, где искать ошибку в той или иной ситуации – быстрее и проще, чем смотреть пользовательские истории или документацию ПО.

Но есть и сложности. Чаще всего разработкой ARIS eEPC занимается бизнес-аналитик без опыта в программировании или создании баз данных. Поэтому многие моменты, которые он может посчитать очевидными и понятными, являются проблемами для разработчика. Вот наиболее типичные ошибки при составлении нотаций, которые я встречал:

Некорректное изображение самой цепочки работ

Последовательное использование двух функций одной за другой.

После каждой функции должно следовать «событие». Использование событий помогает быстро определить, где необходимо создать формы для ввода данных, а где необходимо использовать компоненты для загрузки файлов.

Пример из жизни: требование «Предоставить сведения о земельном участке». Без обозначения на нотации документа пояснения в виде «Предоставлен документ со сведениями о земельном участке» или «Введены сведения о земельном участке» сложно угадать, что нужно сделать: создать загрузчик для документов или все-таки поля для ввода реквизитов документа.

И самое опасное – когда нотацию строят не только сверху – вниз, но еще и слева – направо.

Чем же данные ошибки опасны? Основным ограничением проекта является время и трудозатраты. Последний вариант является самым рискованным, так как разработчик очень легко может спутать направления ветки сценария и спроектировать программу неправильно. Также могут не быть указаны дополнительные компоненты, такие, как «Документ», или события, поясняющие, что должно произойти после функции. В этих случаях разработчики тратят время на изучения всего пакета документов, чтобы определить, что же они должны сделать. Или им необходимо планировать встречу с аналитиком или владельцем проекта для получения разъяснений. В ситуациях, когда «проект должен быть сделан вчера» или необходимо исправить ошибку в течении нескольких часов, – иногда простые задачи превращаются в сложные. Данных ошибок можно легко избежать, если делать нотацию ARIS eEPC в соответствии с правилами.

Применение BPMN 2.0 в разработке ПО

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

В ответ на этот вызов международная организация BPMI (Business Process Management Initiative) разработала новый подход к управлению бизнес-процессами – BPM (Business Process Management) и предложила нотацию BPMN – систему условных обозначений для моделирования бизнес-процессов. В 2011 году в нее был внесен ряд улучшений и вышла версия BPMN 2.0, которая сегодня активно используется в бизнесе. Чем она лучше прежних нотаций? В ней стали использовать параметр «Время», на моделях бизнес-процессов стало возможно показывать события и множество моментов, которые ранее было сложно описать.

Но самое важное – на базе данной нотации разрабатываются системы Business Process Management System (BPMS). Программное обеспечение для управления бизнес-процессами (BPMS) помогает компаниям определять и развертывать автоматизированные бизнес-процессы, а также управлять ими. Оно заменяет трудоемкие операции, выполняемые вручную, на оптимизированные рабочие процессы в бизнес-приложениях. По сути, мы не только рисуем бизнес-процесс, но и используем его в работе нашего ПО.

BPMS используют различные BPM-движки. В нашем случае используется платформа Camunda, которая поддерживает BPMN, нотацию описания бизнес-процессов. То есть в BPMN можно нарисовать логику любой сложности, а движок её выполнит. Большинство процессных вещей, которые можно сделать в BPMN, делать в чистом коде дороже в десятки раз.

Camunda поддерживает последнюю версию Java и вообще любой JVM-язык — Kotlin, Scala, Groovy и т.п. Более того, в ней гораздо проще менять логику работы или исправлять ошибки и оперативно обновлять программное обеспечение.

В инструменте Camunda Modeler или его аналогах можно создать весь бизнес-процесс работы приложения и вставить программный код, который будет исполняться на каждом его этапе. Это существенно облегчает разработку модели бизнес-процессов, использование BPMS в решении задач. При использовании данного инструмента тоже необходимо придерживаться правил. К сожалению, их часто нарушают аналитики при разработке модели:

• Нотация должна идти слева-направо.
• Если используете цвета, делайте легенду: к какой группе относятся данные процессы.
• Подписывайте потоки, указывайте, какой из них выставляется по умолчанию, если есть несколько вариантов.
• Если несколько процессов выполняют одну функцию – объедините в группу.

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

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

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

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

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