Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLpt_PTvizh_CNzh_TW

Связь бизнес-процессов с требованиями к программному обеспечению: Кейс-исследование Visual Paradigm по переходу от BPMN к диаграммам вариантов использования

Введение

В современной быстро меняющейся цифровой среде организации сталкиваются с постоянной проблемой: обеспечить, чтобы усилия по разработке программного обеспечения оставались тесно связанными с реальными бизнес-операциями. Часто сбор требований происходит изолированно от моделирования бизнес-процессов, что приводит к созданию систем, не отвечающих реальным рабочим процессам или не приносящих ожидаемой ценности конечным пользователям. В этом кейс-исследовании рассматривается проверенная методология по преодолению этого разрыва, заключающаяся в переходе от диаграмм моделирования бизнес-процессов и нотации (BPMN) к моделям вариантов использования UML с использованием интегрированной среды моделирования Visual Paradigm.

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

Bridging Business Processes to Software Requirements: BPMN-to-Use Case Transition

Понимание основ: диаграммы BPMN и вариантов использования

Что такое BPMN и BPD?

BPMN предоставляет бизнес-аналитикам набор графических нотаций для моделирования бизнес-процессов. Он был первоначально разработан организацией Инициативой по управлению бизнес-процессами (BPMI) и сейчас поддерживается организацией Группой управления объектами (OMG). Одной из причин разработки BPMN стало создание общей графической языка для людей разных ролей, из разных стран и/или с разными родными языками, чтобы они могли понимать один и тот же бизнес-процесс без барьеров.

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

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

BPD sample

Нотация Описание
BPMN pool Пул — представляет участника в процессе. В BPMN для представления участников используются как пулы, так и ленты. Лента содержится внутри пула для моделирования подраздела родительского пула.
BPMN start event Начальное событие — начало процесса. Можно задать триггеры, чтобы сообщить читателям, в каких ситуациях процесс будет запущен. Например, при получении электронного письма, в понедельник утром или при возникновении ошибки.
BPMN task Задача — атомарная деятельность, которую могут выполнить назначенные участники (моделируемые с помощью пула/ленты). Задачи и другие объекты потока соединяются для формирования полного бизнес-процесса.
BPMN end event Конечное событие — конец процесса. Можно определить результат, чтобы сообщить читателям, что произойдет при завершении процесса. Например, отправить сигнал или сгенерировать ошибку.

Что такое диаграмма вариантов использования?

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

06-use-case-diagram-sample

В диаграмме вариантов использования три основных элемента.

Нотация Описание
UML use case Вариант использования — каждый вариант использования представляет цель пользователя, то есть цель, которую пользователь системы хочет достичь. Обратите внимание, что варианты использования можно использовать только для отображения того, что хочет сделать пользователь, а не того, что разработчику нужно реализовать, хотя в некоторых случаях это может совпадать. Если вы хотите документировать или моделировать функции, участвующие в варианте использования, вы можете использовать инструмент потока событий или детализировать вариант использования с помощью диаграмма последовательности/диаграмма деятельности. Помните, что моделирование случаев использования направлено на моделирование того, что пользователь хочет достичь.
UML actor Актор – пользователь системы. Слово «пользователь» здесь не ограничивается людьми. Это может быть система, взаимодействующая с нашей системой для достижения определенной бизнес-цели.
UML communication link Связь коммуникации/Ассоциация – соединяет актора и случай использования, чтобы показать доступ актора к системе. Каждая связь коммуникации подразумевает последовательность транзакций между актором и системой.

Переход от бизнес-процесса к системным требованиям

Стратегическая связь

Хотя BPD и диаграммы случаев использования не должны обязательно зависеть друг от друга, они могут быть связаны друг с другом дополнительным образом. Обычно мы разрабатываем программное обеспечение для автоматизации или оптимизации определенных рабочих процессов бизнес-процессов. С помощью BPD вы можете понять, как участники взаимодействуют между собой и кто отвечает за что, что помогает нам определить, какие функции им нужна система для поддержки. Те функции системы (рабочий процесс или бизнес-процесс), которые пользователь хочет, могут быть смоделированы с помощью случаев использования и затем разработаны командой. В результате мы можем сказать, что BPD помогает вам выявить случаи использования для разрабатываемой системы.

Visual Paradigm — это инструмент визуального моделирования, который поддерживает переход от моделирования бизнес-процессов к моделированию случаев использования (от бизнес-требований к требованиям приложения), устанавливая связь отслеживаемости между двумя моделями с помощью функции моделирования транзиторов. Нам нужна эта отслеживаемость по следующим причинам:

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

  • Чтобы ответить на вопросы, такие как «Зачем нам нужна эта (системная) функция?», отслеживая часть процесса, из которой перешел случай использования.

  • Чтобы ответить на вопросы, такие как «Была ли уже реализована конкретная операция?», отслеживая от BPD до диаграммы случаев использования.

Ключевые различия: BPD против диаграммы случаев использования

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

Кейс-стади: компания по производству дистиллированной воды «True Aqua»

Бизнес-контекст и описание процесса

Компания по производству дистиллированной воды «True Aqua» — молодой поставщик дистиллированной воды в городе. Они продают дистиллированную воду для коммерческого и домашнего использования. Ниже приведено текстовое описание их процесса доставки воды.

Чтобы заказать дистиллированную воду, клиенты либо звонят на горячую линию заказов, либо отправляют нам электронное письмо. В настоящее время 90% заказов поступают по телефону, а 10% — по электронной почте. Ассистент службы поддержки клиентов, получающий заказ, проверяет, является ли клиент существующим или новым. Если клиент никогда ранее не заказывал, ассистент службы поддержки создаст для него учетную запись клиента, прежде чем перейти к доставке воды.
Доставка дистиллированной воды осуществляется раз в неделю по средам. Поэтому каждое утро в среду ассистент службы поддержки клиентов передает заказы в отдел логистики для доставки. Как только менеджер в отделе логистики получает заказы, он организует доставку, распределяя работников по различным заказам, печатая и публикуя график. Работники получают звонки и доставляют воду клиентам соответственно.

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

Пошаговый процесс перехода

  1. СкачатьDistilled Water Delivery.vpp. Вы также можете найти этот файл в конце этого руководства.

  2. Откройте скачанный файл .vpp в Visual Paradigm. Чтобы открыть проект, выберитеПроект > Открытьв строке меню приложения.

  3. Откройте BPDПроцесс заказа дистиллированной воды. Тщательно изучите поток процесса.

    BPD sample

  4. Процесс начинается, когда клиент делает заказ. Здесь мы можем подумать о случае использования — «Сделать заказ». Этот случай использования поможет автоматизировать процесс, предоставив интерфейс для заказа клиентом без помощи ассистента службы поддержки клиентов, помочь проверить личность клиента и создать учетную запись, если клиент не существует. Щелкните правой кнопкой мыши поСоздать заказ и выберите Связанные элементы > Перейти к новому варианту использования… из всплывающего меню.

    Create use case from task

  5. Это вызывает окно Переход элемента модели окно, в котором можно выбрать модель для размещения варианта использования и актора, а также переименовать их. В данном случае нас устраивают имена варианта использования и актора. Оставим их без изменений. Нажмите ОК.

    Transit model element
    Так формируется новый диаграмма вариантов использования в UeXceler.
    Use case diagram formed

  6. Вернитесь к BPD.

  7. Рассмотрим задачу Создать счет клиента. В бизнес-процессе сотрудник службы поддержки клиентов должен создавать счет для каждого нового клиента. В новой системе это может быть частью варианта использования Создать заказ варианта использования, или быть отдельным вариантом использования, запускаемым вручную сотрудником службы поддержки клиентов. В реальных условиях вы должны уточнить подобные сомнения у заинтересованной стороны, поскольку неверная модель вариантов использования приведет к разработке функций, не соответствующих ожиданиям пользователя. В этом примере предположим, что пользователь хочет, чтобы задача Создать счет клиента была выполнена сотрудником службы поддержки клиентов. Создадим вариант использования на основе этой задачи. Щелкните правой кнопкой мыши по Создать счет клиента и выберите Связанные элементы > Перейти к новому варианту использования… из всплывающего меню.

    Create use case from task

  8. Опять же, нас устраивают имя варианта использования и актора. Оставьте все в окне Переход элемента модели без изменений. Нажмите ОК. Диаграмма вариантов использования обновлена новым вариантом использования и актором. Посмотрим.

    New use cases created

  9. Вернитесь к BPD. Перейдем к подпроцессу Организовать доставку. Менеджер отдела логистики может использовать систему для планирования и уведомления рабочих о доставке воды. Следовательно, это также вариант использования системы. Щелкните правой кнопкой мыши по подпроцессу Организовать доставку и выберите Связанные элементы > Перейти к новому варианту использования… из всплывающего меню.

  10. Проверьте актора «Менеджер» в Элемент перехода модели окне. Если мы сохраним имя актора как Менеджер, это неоднозначно в модели вариантов использования, потому что в компании может быть много отделов с разными менеджерами. Поэтому переименуйте актора в Менеджер логистического отдела.

    24-rename-actor

  11. Нажмите ОК. Диаграмма вариантов использования обновлена.

    Use case diagram updated

  12. Вернитесь к BPD. Последняя задача Доставить воду — это задача, которую может выполнять только человек, и она не имеет отношения к взаимодействию с системой. Поэтому нам не нужно создавать вариант использования для нее.

  13. Предположим, региональный менеджер хочет, чтобы система поддерживала новую функцию, которая может генерировать отчет для отображения статистики по заказам. Эта функция может помочь ему проанализировать и уточнить маркетинговую стратегию. Хотя эта функция не была смоделирована в модели бизнес-процесса, мы можем нарисовать ее непосредственно на диаграмме вариантов использования. Откройте диаграмму вариантов использования. Нарисуйте актора Региональный менеджер. Создайте вариант использования Создать отчет по статистике связанный с ним ассоциацией.

    Use case diagram updated

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

    Use case diagram updated

  15. Упорядочьте диаграмму.

    Complete use case diagram

  16. Связь перехода позволяет отслеживать модель бизнес-процесса из модели вариантов использования (и наоборот). Попробуем. Поместите курсор мыши на вариант использования Сделать заказ вариант использования.

    Mouse over use case

  17. Нажмите на Ресурс Model Transitor ресурс в нижнем правом углу фигуры. Выберите Переход от > Процесс заказа дистиллированной воды<. Разместить заказ из всплывающего меню.

    Open task from use case
    Это открывает BPD с задачей Разместить заказ выбрано.
    Task selected

Заключение

Этот кейс-стади демонстрирует, что переход от моделей бизнес-процессов BPMN к диаграммам вариантов использования UML — это не просто техническое упражнение, а стратегический подход к обеспечению того, чтобы программные решения приносили реальную бизнес-ценность. Используя функцию Model Transitor в Visual Paradigm, команды могут установить четкую отслеживаемость между бизнес-деятельностью и системными требованиями, создавая общее понимание между бизнес-заинтересованными сторонами и командами разработки.

Пример компании True Aqua Distilled Water иллюстрирует несколько важных принципов: не каждая бизнес-задача требует соответствующего варианта использования; при сопоставлении процессов с функциями системы необходима ясность со стороны заинтересованных сторон; новые требования могут быть добавлены непосредственно в модели вариантов использования, даже если они отсутствовали в исходном бизнес-процессе. Самое важное — двусторонняя отслеживаемость, обеспечиваемая инструментом, позволяет командам отвечать на фундаментальные вопросы о обоснованности требований и статусе их реализации на протяжении всего жизненного цикла проекта.

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


Ссылки

  1. Как ИИ-технологии на основе обработки естественного языка революционизируют генерацию BPMN из текста для моделирования корпоративных процессов: Исследует, как обработка естественного языка преобразует текстовые описания бизнеса в соответствующие модели BPMN для документирования корпоративных рабочих процессов.
  2. Освоение моделирования бизнес-процессов BPMN 2.0 с помощью инструментов Visual Paradigm, основанных на ИИ: Подробный обзор возможностей моделирования BPMN, усиленных ИИ, для создания исполняемых спецификаций бизнес-процессов.
  3. Функция преобразования варианта использования в диаграмму деятельности: Описывает автоматизированный рабочий процесс расширения высокого уровня вариантов использования до детализированных диаграмм деятельности для планирования реализации.
  4. Обновление генератора бизнес-диаграмм BPMN с ИИ: Заметки о выпуске, охватывающие расширенные возможности ИИ по преобразованию описательных описаний процессов в структурированные диаграммы BPMN.
  5. Функция диаграмм BPMN и инструментов: Официальная документация по инструментам моделирования BPMN 2.0, поддержке нотации и функциям совместной работы в Visual Paradigm.
  6. Демонстрация рефакторинга процессов с помощью диалога: Видеодемонстрация использования команд ИИ-чатбота для динамической модификации диаграмм BPMN с помощью инструкций на естественном языке.
  7. Выпуск инструмента улучшения бизнес-процессов на основе ИИ: Объявление о функциях анализа интеллектуальных рабочих процессов, которые предлагают возможности оптимизации на основе метрик процессов.
  8. Функция диаграмм BPMN и инструментов: Справочник по продвинутым возможностям BPMN, включая декомпозицию подпроцессов и генерацию исполняемых моделей.
  9. Инструмент улучшения диаграмм вариантов использования на основе ИИ: Веб-инструмент на основе ИИ для автоматического улучшения базовых моделей вариантов использования с правильными отношениями включения/расширения и обработкой исключений.
  10. Полное руководство по моделированию вариантов использования с экосистемой ИИ Visual Paradigm: Анализ сторонней компании по методам, поддерживаемым ИИ, для выявления требований и спецификации вариантов использования.
  11. От бизнес-процессов к вариантам использования: учебник (PDF): Скачиваемое пошаговое руководство по переходу от моделей BPMN к диаграммам вариантов использования UML с обеспечением отслеживаемости.
  12. Демонстрация автоматического создания границ: Видеоурок, демонстрирующий создание границ системы, участников и основных вариантов использования с помощью ИИ на основе описания области проекта.
  13. Демонстрация улучшения интеллектуальных связей: Демонстрация анализа ИИ, который выявляет и предлагает соответствующие отношения включения/расширения между вариантами использования.
  14. Функция инструмента улучшения диаграмм вариантов использования с ИИ: Страница продукта, описывающая возможности автоматического анализа и улучшения связей между вариантами использования.
  15. Демонстрация генерации последующих рабочих процессов: Видео, демонстрирующее автоматическую генерацию диаграмм активностей и последовательностей из проверенных спецификаций вариантов использования.
  16. Visual Paradigm в TheirStack: Профиль технологии и информация об использовании инструментов моделирования Visual Paradigm в корпоративных средах.
  17. Функция генератора отчетов по диаграммам вариантов использования с ИИ: Инструмент для преобразования скриптов PlantUML и моделей вариантов использования в профессиональную документацию для заинтересованных сторон.
  18. Документация точки расширения потока событий: Техническая справка по документированию подробных сценариев вариантов использования с предусловиями, постусловиями и альтернативными потоками.
  19. Релиз студии моделирования вариантов использования с ИИ: Анонс релиза с интегрированными возможностями ИИ в моделировании вариантов использования, включая анализ требований на естественном языке.