🤖 Как сделать BPMN-диаграмму за минуты с помощью AI: StormBPMN 🤖

В этом эпизоде обсуждаем, как AI меняет подход к моделированию бизнес-процессов и работе с BPMN.

Вместе с топовым экспертом по BPMN в России Денисом Котовым говорим про StormBPMN — инструмент для создания BPMN-диаграмм с поддержкой AI, разбираем, как создавать BPMN через код и в чём нейросети действительно могут помочь.

Если вам только предстоит изучать BPMN или вы уже давно работаете с нотацией, этот выпуск поможет по-новому взглянуть на моделирование процессов и понять, как использовать AI в работе без лишней магии и разочарований.

🔗 Сайт эпизода


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка -
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Сообщество GetAnalyst — ваш путь к получению самого актуального опыта в системном анализе и проектировании архитектуры 🤩

✨ ПРО ВАРИАНТ ИСПОЛЬЗОВАНИЯ (USE CASE) ✨

Вариант использования (англ. use case) — это техника представления требований, которая описывает взаимодействие между несколькими участниками (действующим лицом и системой) для получения определённого значимого результата.

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

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


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

Актор (англ. actor) — человек, устройство или система, играющие некоторую определённую роль во взаимодействии с решением (BABOK Guide).

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

Выделить акторов, которые участвуют в описании вариантов использования, помогут такие вопросы:
❔ Кто (или что) уведомляется, если что-то происходит внутри системы?
❔ Кто (или что) предоставляет системе информацию и сервисы?
❔ Кто (или что) помогает системе среагировать и выполнить задачу?


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

✨ ПЕРЕХОДИМ К ОПИСАНИЮ USE CASE ✨

Варианты использования могут быть представлены:
- в графической форме (например, с помощью Use Case Diagram UML),
- в виде таблицы.

Оформление с помощью нотации UML мы рассмотрим позднее, когда детально углубимся в нотации моделирования 😉

А пока разберём более простой и универсальный способ оформления use case – с помощью таблицы.
В документации к ПО именно этот вариант оформления считается основным, а графический - вспомогательным.

#hardGetAnalyst

Существует два варианта табличного оформления use case: полная табличная форма и свободная табличная форма (упрощённая).

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

🟢 Если проект небольшой и варианты использования — не единственное описание будущих требований к системе (а есть ещё, например, user story, модели процессов, протипы и другие артефакты), можно не использовать полный шаблон записи вариантов использования и обойтись свободным форматом.

Именно его мы и рассмотрим.

⬇️⬇️⬇️

Табличная форма представления фокусируется на детальном рассмотрении последовательности действий, которая описывает взаимодействие актора и системы в рамках одного варианта использования. В ней мы описываем основные и альтернативные сценарии. Но обо всём по порядку

Предлагаем сохранить этот и предыдущий пост в избранное, чтобы шаблон use case был у вас всегда под рукой!


1️⃣ Вариант использования

В этом поле указывается название одного варианта использования, которое вы хотите описать, в формате «глагол + существительное».
Например: «зарегистрироваться на сайте», «создать заявку», «оплатить покупку» и так далее.

Для определения возможных вариантов использования можно руководствоваться следующими способами:
📌Определить действующие лица и бизнес-процессы, в которых они участвуют
В каждом процессе выделить доступную для выполнения функцию — это и будет вариант использования.
📌 Применить CRUD-модель для определения возможных сценариев взаимодействия с данными системы: создания (англ. create), чтения (англ. read), изменения (англ. update) или удаления (англ. delete).


2️⃣ Область действия

Границы системы, в рамках которых выполняется сценарий.
Например, приложение или сайт.


3️⃣ Участники процесса

Участники процесса включают основное действующее лицо и иных участников.
- Основное действующее лицо запускает вариант использования, то есть это и есть актор. Можно записать имя пользователя, должность или роль. Например, пользователь ЛК или администратор.
- В иных участниках указывается перечень дополнительных действующих лиц и их целей в рамках варианта использования. Записывается в формате: [Актор] — [его цель].

Например, сайт, цель которого — сформировать ЛК клиенту. Система-партнёр, которая возвращает информацию об оплате услуги в основную систему.


4️⃣ Предусловие

Здесь указывают описание того, что должно произойти, чтобы актор мог воспроизвести данный вариант использования.
Например, пользователь зашёл на сайт или сформировал корзину для оформления покупки.


5️⃣ Описание

В этом блоке таблицы описывают основной сценарий в виде пошагового описания действий актора и системы.

Например:
1. Система открывает пользователю форму регистрации
2. Пользователь указывает свои персональные данные в форме
3. Система запускает проверку указанных данных на формат
4. Система создаёт пользователю личный кабинет (ЛК)
5. Система авторизует пользователя в ЛК под его персональными данными.

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


6️⃣ Расширения

В расширениях представлено описание альтернативных сценариев, которые выполняются при ответвлении от основного.

Причин такого ветвления может быть несколько:
- Альтернативные пути к успеху;
- Актор действует некорректно;
- Бездействие актора;
- Некорректные данные;
- Внутренние ошибки системы;
- Критические недостатки в производительности системы.

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


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