Методология оценки качества моделей бизнес-процессов BPMN с использованием метрик программной инженерии: от теории к практике

В условиях постоянно меняющейся рыночной конъюнктуры и растущей конкуренции, способность организаций быстро адаптироваться и оптимизировать свои внутренние процессы становится критически важным фактором успеха. Моделирование бизнес-процессов, в частности с использованием международной нотации BPMN (Business Process Model and Notation), выступает мощным инструментом для достижения этих целей, обеспечивая прозрачность, понимание и возможность анализа операционной деятельности. Однако, как показывает практика, само по себе наличие моделей не гарантирует их качества или эффективности. Ошибки, избыточность или чрезмерная сложность в моделях могут привести к некорректной интерпретации, затруднениям в автоматизации и, как следствие, к снижению производительности и увеличению затрат.

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

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

Для достижения этой цели были поставлены следующие задачи:

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

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

Теоретические основы моделирования: Модели программных процессов и бизнес-процессов

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

В основе эффективного управления любой организацией лежит четкое понимание и оптимизация её внутренних процессов. Бизнес-процесс определяется как логически завершенная цепочка взаимосвязанных и повторяющихся видов деятельности, в результате которых используются ресурсы предприятия для переработки объекта с целью достижения измеримых результатов или создания продукции, удовлетворяющей потребности клиентов. Согласно стандарту ISO 9000-2001, процесс — это «совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы».

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

Ключевым инструментом для моделирования бизнес-процессов является нотация BPMN (Business Process Model and Notation). Разработанная Business Process Management Initiative (BPMI) и поддерживаемая Object Management Group (OMG), BPMN представляет собой стандартизированную систему условных обозначений и их описания в XML. Её основная цель — создание общего языка, понятного всем бизнес-пользователям, включая бизнес-аналитиков, технических разработчиков и менеджеров, тем самым преодолевая разрыв между бизнес-пользователями и ИТ-специалистами. BPMN 2.0, выпущенная в 2010 году, не только расширила набор элементов, но и сделала спецификацию исполняемой и переносимой, что позволяет выполнять процессы, смоделированные в одном редакторе, на движках бизнес-процессов других производителей.

Основные элементы нотации BPMN и их семантика:

Категория элементов	Основные элементы	Описание и роль
Объекты потока	События (Events): начальные, промежуточные, конечные	Определяют, что происходит в процессе: начало, промежуточные стадии, завершение. Могут быть на основе сообщений, таймеров, условий и т.д.
	Действия (Activities): задачи (Tasks), подпроцессы (Sub-processes)	Представляют работу, выполняемую в процессе. Задачи — атомарные действия, подпроцессы — детализированные действия, содержащие внутреннюю модель.
	Шлюзы (Gateways): исключающие (Exclusive), параллельные (Parallel), включающие (Inclusive), событийные (Event-Based)	Контролируют последовательность и ветвление потоков. Исключающие — выбор одного пути, параллельные — одновременное выполнение, включающие — комбинация, событийные — выбор на основе события.
Соединяющие объекты	Потоки последовательностей (Sequence Flows)	Определяют порядок выполнения действий в рамках одного пула.
	Потоки сообщений (Message Flows)	Представляют обмен информацией между участниками разных пулов.
	Ассоциации (Associations)	Связывают артефакты с объектами потока, объясняют контекст.
Дорожки	Пулы (Pools)	Представляют участников процесса (организация, отдел, роль) и являются контейнерами для дорожек.
	Дорожки (Lanes)	Разделяют пул на функциональные единицы, определяя зоны ответственности внутри участника.
Артефакты	Объекты данных (Data Objects)	Представляют информацию, используемую или производимую в процессе.
	Группы (Groups)	Логически объединяют элементы диаграммы для лучшего понимания.
	Текстовые аннотации (Text Annotations)	Дополнительные текстовые пояснения для читаемости.

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

Модели жизненного цикла программного обеспечения

Параллельно с развитием методов моделирования бизнес-процессов, программная инженерия разработала собственные подходы к управлению и оценке качества создания информационных систем. Модели реализации жизненного цикла программного обеспечения (ЖЦПО), или модели процессов разработки программного обеспечения (SDLC — Software Development Life Cycle), представляют собой структурированный подход, определяющий задачи, выполняемые на каждом этапе создания и развития ПО. Это пошаговая структура, описывающая путь ПО от идеи до вывода в релиз.

Семь основных этапов жизненного цикла разработки программного обеспечения (SDLC):

1. Планирование (Planning): Определение целей, требований, ресурсов, сроков и рисков проекта.
2. Анализ (Analysis): Сбор и детализация требований к системе, создание функциональных и нефункциональных спецификаций.
3. Проектирование (Design): Разработка архитектуры системы, пользовательского интерфейса, баз данных и алгоритмов.
4. Разработка (Development): Написание программного кода в соответствии с проектной документацией.
5. Тестирование (Testing): Проверка функциональности, производительности, безопасности и надежности ПО.
6. Развертывание (Deployment): Внедрение программного обеспечения в эксплуатацию, установка на серверы и рабочие станции.
7. Обслуживание (Maintenance): Поддержка, исправление ошибок, обновление и доработка ПО после развертывания.

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

Стандарты качества программного обеспечения:

• ISO/IEC 12207 является международным стандартом для процессов жизненного цикла программного обеспечения, определяющим все задачи, необходимые для разработки, поддержки и использования ПО.
• ISO 9126 (и его расширенная версия ISO 25010:2011) — это серия стандартов, определяющих характеристики качества программного обеспечения. Согласно ISO 9126, качество программного обеспечения определяется как степень, в которой оно обладает требуемой комбинацией свойств, и является относительным понятием, зависящим от условий и области применения.

Шесть основных характеристик качества ПО по ISO 9126:

1. Функциональность: Способность ПО удовлетворять заявленные или подразумеваемые потребности (пригодность, точность, интероперабельность, безопасность, соответствие стандартам).
2. Надежность: Способность сохранять уровень производительности в заданных условиях (зрелость, отказоустойчивость, восстанавливаемость).
3. Практичность (Удобство использования): Удобство использования (понятность, обучаемость, работоспособность, привлекательность).
4. Эффективность: Соотношение уровня производительности и используемых ресурсов (поведение во времени, утилизация ресурсов).
5. Сопровождаемость: Легкость модификации (анализируемость, изменяемость, стабильность, тестируемость).
6. Переносимость: Способность быть перенесенным из одной среды в другую (адаптивность, устанавливаемость, сосуществование, заменяемость).

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

Сравнительный анализ моделей процессов: общие черты и различия

Несмотря на внешние различия в предметных областях, модели программных процессов (SDLC) и модели бизнес-процессов (BPMN) обладают значительными концептуальными сходствами, что делает возможным и целесообразным перенос аналитических методов из одной области в другую.

Сходства:

• Графовое представление: Оба типа моделей по своей сути являются ориентированными графами. Элементы BPMN (задачи, события, шлюзы) и стадии SDLC можно рассматривать как узлы, а потоки последовательностей и переходы между этапами — как ребра. Это фундаментальное сходство позволяет применять математический аппарат теории графов для анализа обеих областей.
• Итеративность и цикличность: Многие SDLC-модели (например, спиральная, итеративная) предусматривают циклическое повторение этапов. Аналогично, бизнес-процессы часто содержат циклы (например, повторная проверка, согласование), которые моделируются в BPMN с помощью шлюзов и потоков.
• Структурирование и декомпозиция: И SDLC, и BPMN позволяют декомпозировать сложные процессы на более мелкие, управляемые части (подпроцессы, подзадачи). Это обеспечивает модульность и улучшает понимание системы в целом.
• Целевая ориентация: Как программные, так и бизнес-процессы нацелены на достижение конкретного, измеримого результата – создание качественного ПО или продукта/услуги для клиента.
• Управление рисками: В обеих областях уделяется внимание выявлению и снижению рисков. SDLC включает механизмы для идентификации, оценки и минимизации рисков на каждом этапе разработки. Моделирование в BPMN позволяет выявлять узкие места и потенциальные сбои в бизнес-процессах.
• Стандартизация: Обе области стремятся к стандартизации. Для ПО это стандарты ISO 12207, ISO 9126; для бизнес-процессов — нотация BPMN. Стандартизация обеспечивает унификацию подходов и облегчает взаимодействие.

Различия:

Характеристика	Модели программных процессов (SDLC)	Модели бизнес-процессов (BPMN)
Основная цель	Создание и поддержка программного обеспечения, снижение стоимости разработки при улучшении качества и сокращении времени.	Повышение эффективности и прозрачности работы организации, формализация логики, упрощение взаимодействия.
Предмет моделирования	Последовательность действий, связанных с созданием ПО (кодирование, тестирование, развертывание).	Последовательность действий, связанных с достижением бизнес-целей (производство, продажи, обслуживание клиентов).
Фокус	Техническая реализация, системная архитектура, функциональность ПО.	Бизнес-логика, взаимодействие участников, потоки работ, организационная структура.
Основная аудитория	Разработчики, тестировщики, менеджеры проектов, системные архитекторы.	Бизнес-аналитики, менеджеры, руководители отделов, сотрудники, ИТ-специалисты.
Детализация данных	Высокая детализация работы с данными, структурами, алгоритмами (часто дополняется UML).	Ограниченная детализация потоков данных; акцент на потоке управления. Для данных часто требуются дополнительные нотации (например, UML).
Исполняемость	Может быть напрямую связана с кодом и компилироваться (CI/CD процессы).	BPMN 2.0 исполняема, но требует специализированных движков BPMN для автоматизации и оркестровки процессов.

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

Метрики качества в программной инженерии: Детальный обзор

Общие принципы оценки качества программного обеспечения

Оценка качества программного обеспечения — это многогранный процесс, направленный на определение степени соответствия продукта установленным требованиям и ожиданиям пользователей. В программной инженерии для этого используются различные метрики качества, которые позволяют количественно измерить определенные свойства ПО. Эти атрибуты качества определяются в серии международных стандартов, таких как ГОСТ Р ИСО/МЭЭК 9126 «Информационная технология – Оценка программной продукции» и его расширенной версии ISO 25010.

Стандарт ISO 9126 выделяет шесть основных характеристик качества ПО: функциональность, надежность, удобство использования, эффективность, сопровождаемость и переносимость. Эти характеристики, в свою очередь, декомпозируются на более детальные атрибуты.

Метрики качества могут быть разделены на две основные категории:

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

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

Метрика цикломатической сложности МакКейба

Одной из фундаментальных и широко используемых метрик в программной инженерии является цикломатическая сложность (Cyclomatic Complexity, CC), предложенная Томасом Дж. МакКейбом в 1976 году. Она представляет собой количественную меру сложности программы, оценивающую количество линейно независимых путей через исходный код. Эта метрика помогает оценить сложность тестирования, читаемости и сопровождаемости программного модуля.

Теоретические основы:
Цикломатическая сложность основана на теории графов. Любая программа может быть представлена в виде графа потока управления (Control Flow Graph, CFG), где:

• Узлы (Nodes, N) представляют операторы или блоки кода без ветвлений.
• Ребра (Edges, E) представляют переходы между операторами.
• Связанные компоненты (Connected Components, P) — это части графа, которые связаны между собой. Для одной программы или функции обычно принимается P = 1.

Формула расчета цикломатической сложности:

V(G) = E - N + 2P

Где:

• V(G) — цикломатическая сложность графа G.
• E — число ребер в графе потока управления.
• N — число узлов в графе потока управления.
• P — число связанных компонентов графа (обычно 1 для одной функции или модуля).

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

• CC ≤ 10: Обычно считается управляемой и хорошо тестируемой.
• 10 < CC ≤ 20: Умеренная сложность, возможны проблемы с пониманием и тестированием. Рекомендуется рассмотреть рефакторинг.
• CC > 20: Высокая сложность, что указывает на необходимость обязательного рефакторинга для улучшения читаемости, сопровождаемости и тестируемости.

Например, для кода, содержащего два последовательных if оператора, цикломатическая сложность будет 3, так как существует три независимых пути выполнения (оба if выполняются, первый if выполняется, второй нет, ни один if не выполняется). Высокая цикломатическая сложность часто указывает на «спагетти-код», где трудно проследить логику выполнения и где высока вероятность ошибок.

Метрика когнитивной сложности

В то время как цикломатическая сложность фокусируется на количестве линейно независимых путей, метрика когнитивной сложности (Cognitive Complexity), сформулированная в 2018 году, была разработана для измерения читаемости и удобства сопровождения кода с точки зрения человеческого восприятия. Она учитывает, насколько легко человеку понять поток управления кодом, а не только количество ветвлений.

Отличие от цикломатической сложности:
Ключевое отличие заключается в том, что когнитивная сложность игнорирует конструкции языка, которые сокращают код и делают его более читаемым, но при этом увеличивает сложность за каждый оператор, нарушающий обычный линейный поток управления. Например, цепочки вызовов методов или операторы объединения с нулевым значением (например, ?? в C#) могут увеличивать цикломатическую сложность, но не добавляют когнитивной, поскольку они интуитивно понятны и не требуют «прыжков» в мыслительном процессе.

Принципы расчета:
Когнитивная сложность начинается с нуля и увеличивается:

• За каждое прерывание линейного потока кода:
  • if, else if, else
  • for, while, do-while
  • switch, case
  • try, catch, finally
  • goto, break, continue
  • Рекурсивные вызовы (прямые и косвенные).
• За каждый уровень вложенности: Каждое вложенное прерывание линейного потока добавляет дополнительный балл (например, if внутри for добавляет 1 за for + 1 за if + 1 за вложенность).
• За логические операторы: &&, || в условных выражениях.

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

Интерпретация:
Высокая когнитивная сложность указывает на трудность понимания кода, что может привести к ошибкам при его изменении и повышению стоимости сопровождения. Рекомендации по улучшению кода с высокой когнитивной сложностью включают:

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

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

Метрики глубины вложенности

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

Определение и влияние на сложность:

• Глубина вложенности управляющих структур (Depth of Nesting): Измеряет максимальное количество вложенных конструкций, таких как if-else операторы, for или while циклы. Чем больше глубина вложенности, тем сложнее код для понимания и сопровождения. Это связано с тем, что при чтении кода необходимо удерживать в уме все вышестоящие контексты, что увеличивает когнитивную нагрузку. Высокая глубина вложенности часто является индикатором «спагетти-кода» или плохо структурированного алгоритма.
• Глубина дерева наследования (Depth of Inheritance Tree, DIT): В объектно-ориентированном программировании DIT измеряет максимальную длину от узла (класса) до корня дерева наследования. Более глубокое дерево наследования может указывать на высокую степень повторного использования, но также может усложнять понимание системы из-за множества уровней абстракции и потенциальных побочных эффектов.

Примеры использования:
Рассмотрим простой пример:


if (условие_1) {
for (i = 0; i < N; i++) {
if (условие_2) {
// Действие
}
}
}


В данном фрагменте кода глубина вложенности достигает 3 (if → for → if). Такой код требует от разработчика понимания трех уровней контекста одновременно.

Влияние на качество ПО:
Высокая глубина вложенности негативно влияет на:

• Читаемость: Сложнее отслеживать поток выполнения и условия.
• Сопровождаемость: Изменение в одном уровне может потребовать пересмотра всех вложенных уровней.
• Тестируемость: Увеличивается количество путей выполнения, что затрудняет создание исчерпывающих тестовых сценариев.

Снижение глубины вложенности часто достигается путем рефакторинга кода, такого как извлечение методов (extract method), использование паттернов Guard Clauses для ранних выходов, или упрощение сложных условных выражений.

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

Специализированные метрики: FMESP и CFC

В контексте анализа графовых моделей, особенно тех, что описывают потоки управления и параллелизм, программная инженерия разработала ряд специализированных метрик. Две из них, которые недостаточно широко освещены в русскоязычных источниках, но крайне важны для глубокой оценки, это FMESP (Flow Metric for Explicit Split and Parallelism) и CFC (Cyclomatic Flow Complexity).

Примечание: Поскольку прямые описания и формулы расчета метрик FMESP (Flow Metric for Explicit Split and Parallelism) и CFC (Cyclomatic Flow Complexity) из области программной инженерии в контексте их первичного определения не были найдены в русскоязычных научных источниках, соответствующих заданным критериям, их детальное представление будет основываться на общих принципах анализа графов потока управления и аналогичных метрик, которые могут быть адаптированы для BPMN-моделей.

1. FMESP (Flow Metric for Explicit Split and Parallelism)

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

Принцип расчета (адаптированный для BPMN):
FMESP может быть рассчитана как сумма баллов, присвоенных каждому элементу, явно указывающему на параллелизм или его синхронизацию:

FMESP = ∑ (Веспараллельного шлюза-разделителя) + ∑ (Веспараллельного шлюза-объединителя) + ∑ (Весмногоэкземплярной задачи)

• Параллельный шлюз-разделитель (Parallel Gateway ‘AND’ Split): Присваивается балл, например, 1. Он указывает на начало параллельных ветвей.
• Параллельный шлюз-объединитель (Parallel Gateway ‘AND’ Join): Присваивается балл, например, 1. Он указывает на синхронизацию параллельных ветвей.
• Многоэкземплярная задача (Multi-Instance Task): Присваивается балл, например, 1 за каждый экземпляр или фиксированный балл за саму задачу, так как она подразумевает параллельное выполнение.

Интерпретация:
Высокое значение FMESP указывает на значительный уровень параллелизма и, следовательно, на потенциальную сложность в управлении процессом, его тестировании и отладке. Это может быть как преимуществом (повышение производительности), так и недостатком (увеличение вероятности ошибок синхронизации, «тупиков»). Модели с высоким FMESP требуют особого внимания к корректности логики параллельного выполнения.

2. CFC (Cyclomatic Flow Complexity)

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

Принцип расчета (адаптированный для BPMN):
CFC для BPMN-модели может быть расширена относительно базовой цикломатической сложности, учитывая не только шлюзы, но и сложность потоков сообщений и информационных объектов:

CFC = V(G) + ∑ (Веспотоков сообщений) + ∑ (Весобъектов данных) + ∑ (Вессложных событий)

Где:

• V(G) — базовая цикломатическая сложность модели BPMN.
• ∑ (Веспотоков сообщений): Каждый поток сообщения между пулами может добавлять балл (например, 0.5 или 1), так как он представляет собой внешнее взаимодействие.
• ∑ (Весобъектов данных): Количество уникальных объектов данных, связанных с задачами, может влиять на сложность.
• ∑ (Вессложных событий): События, требующие сложной обработки (например, условные, сигнальные события), могут добавлять дополнительные баллы.

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

• Высокую связанность: Чрезмерное количество взаимодействий между участниками.
• Информационную перегрузку: Большое количество данных, с которыми оперирует процесс.
• Трудности в интеграции: Сложность обеспечения корректного обмена данными и синхронизации событий.

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

Методология адаптации и применения метрик программной инженерии к моделям бизнес-процессов BPMN

Разработка эффективной методологии адаптации метрик из программной инженерии к моделям бизнес-процессов в нотации BPMN является ключевой задачей для объективной оценки качества последних. Это позволяет перейти от интуитивного анализа к формализованному, математически обоснованному подходу.

Формальное представление BPMN-моделей как ориентированных графов

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

Принципы преобразования элементов BPMN в узлы и ребра графа:

1. Узлы (Vertices):
   • Задачи (Tasks) и Подпроцессы (Sub-processes): Каждый экземпляр задачи или подпроцесса преобразуется в отдельный узел графа. Эти узлы представляют собой элементарные или составные действия.
   • События (Events): Начальные, промежуточные и конечные события также представляются узлами. Они обозначают точки начала, изменения состояния или завершения процесса.
   • Шлюзы (Gateways): Каждый шлюз (исключающий, параллельный, включающий, событийный) преобразуется в узел. Шлюзы являются критически важными элементами для управления потоком и ветвлениями.
2. Ребра (Edges):
   • Потоки последовательностей (Sequence Flows): Каждое соединение между двумя объектами потока (узлами) в рамках одного пула преобразуется в ориентированное ребро графа, указывающее направление выполнения.
   • Потоки сообщений (Message Flows): Могут быть представлены как особый тип ребер, соединяющих узлы в разных пулах. Для некоторых метрик их можно учитывать как обычные ребра, для других — как факторы увеличения сложности взаимодействия.
   • Ассоциации (Associations): Обычно не рассматриваются как ребра потока управления, но могут быть использованы для дополнительного анализа связей с артефактами.

Пример графового представления:
Простой BPMN-процесс «Выполнение задачи» с двумя альтернативными путями:
Start Event → Task A → Exclusive Gateway → Task B (если условие 1) / Task C (если условие 2) → End Event.

Графовое представление:

• Узлы: S (Start), A (Task A), G (Exclusive Gateway), B (Task B), C (Task C), E (End).
• Ребра: (S, A), (A, G), (G, B), (G, C), (B, E), (C, E).

Таким образом, любая BPMN-диаграмма может быть однозначно преобразована в ориентированный граф, что открывает путь для применения метрик, изначально разработанных для анализа программного кода.

Адаптация цикломатической сложности для BPMN-моделей

Классическая цикломатическая сложность МакКейба (V(G) = E - N + 2P) может быть напрямую применена к графовому представлению BPMN-моделей. Однако, для более точного отражения специфики бизнес-процессов, целесообразно использовать модифицированную формулу или учитывать особенности различных элементов BPMN.

Модификация формулы МакКейба для BPMN:

В контексте BPMN, основным источником «ветвлений» и, следовательно, сложности, являются шлюзы. Формулу можно адаптировать, рассматривая каждый шлюз как точку принятия решения или разветвления.

Модифицированная цикломатическая сложность (VBPMN) может быть вычислена следующим образом:

VBPMN = PШлюзов + PЦиклов + 1

Где:

• PШлюзов — количество шлюзов в модели.
• PЦиклов — количество циклов, явно или неявно представленных в модели (например, с помощью шлюзов, направляющих поток обратно к предыдущей задаче). Если шлюз управляет циклом, он уже учтён в PШлюзов. Дополнительно можно учитывать явные циклы, которые не всегда прямо ассоциируются со шлюзами.

Примеры расчета для различных типов шлюзов:

1. Исключающий шлюз «ИЛИ» (Exclusive Gateway):
   • Входящих потоков: 1
   • Исходящих потоков: N (N > 1)
   • Каждый исходящий поток после исключающего шлюза увеличивает количество независимых путей. В рамках формулы VBPMN = PШлюзов + PЦиклов + 1, каждый такой шлюз добавляет 1 к PШлюзов.
2. Параллельный шлюз «И» (Parallel Gateway ‘AND’ Split/Join):
   • Разделитель: Один входящий, несколько исходящих потоков. Создает параллельные ветви.
   • Объединитель: Несколько входящих, один исходящий поток. Синхронизирует параллельные ветви.
   • С точки зрения цикломатической сложности, параллельные шлюзы не добавляют линейно независимых путей, так как все ветви выполняются. Однако, они увеличивают сложность координации. Тем не менее, в базовой формуле МакКейба они учитываются как узлы, а их связи как ребра. В модифицированной формуле PШлюзов каждый такой шлюз добавляет 1, что отражает их структурную роль.
3. Включающий шлюз «ИЛИ» (Inclusive Gateway):
   • Может активировать одну или несколько ветвей.
   • Является более сложным, чем исключающий, поскольку комбинации путей могут быть множественными.
   • В рамках модифицированной формулы, каждый такой шлюз также добавляет 1 к PШлюзов, но для более глубокого анализа можно присвоить ему больший «вес» из-за его комбинаторной сложности.

Таблица влияния элементов BPMN на цикломатическую сложность:

Элемент BPMN	Влияние на E (ребра)	Влияние на N (узлы)	Влияние на P (связанные компоненты)	Примечания
Задача (Task)	Входящий/исходящий поток	1	0	Узел
Событие (Event)	Входящий/исходящий поток	1	0	Узел
Искл��чающий шлюз (XOR)	N входящих + N исходящих	1	0	Узел, создает N-1 независимых путей в графе, увеличивает CC
Параллельный шлюз (AND)	N входящих + N исходящих	1	0	Узел, не увеличивает количество независимых путей, но добавляет сложность синхронизации
Включающий шлюз (OR)	N входящих + N исходящих	1	0	Узел, может создать до 2N-1 независимых путей, существенно увеличивает CC
Поток последовательностей	1	0	0	Ребро

Пример расчета:
Пусть у нас есть модель: Начальное событие → Задача 1 → Исключающий шлюз (2 ветви) → Задача 2.1 / Задача 2.2 → Параллельный шлюз (объединяющий) → Задача 3 → Конечное событие.

• Узлы (N): 6 (начальное событие, Задача 1, Исключающий шлюз, Задача 2.1, Задача 2.2, Параллельный шлюз, Задача 3, конечное событие)
• Ребра (E): 7 (2 потока до Исключающего шлюза, 2 из него, 2 до Параллельного шлюза, 1 из него)
• Связанные компоненты (P): 1

V(G) = 7 - 6 + 2 * 1 = 3 (для графа)
Если использовать модифицированную формулу: PШлюзов = 2 (Исключающий и Параллельный), PЦиклов = 0.
VBPMN = 2 + 0 + 1 = 3.

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

Адаптация когнитивной сложности для BPMN-моделей

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

Принципы адаптации:

1. Базовый балл: Каждый элемент процесса, нарушающий линейный поток выполнения, добавляет базовый балл.
2. Вложенность: Каждый уровень вложенности (например, подпроцессы внутри задач, шлюзы внутри подпроцессов) увеличивает когнитивную сложность.
3. Игнорирование «упрощающих» конструкций: Элементы, которые делают модель более читаемой или сокращают визуальный шум, не должны увеличивать сложность.

Разработанные правила присвоения когнитивных баллов элементам BPMN:

• Начальный балл: Когнитивная сложность модели начинается с 0.
• Задачи (Tasks): 0 баллов, если это простая задача. Если задача является многоэкземплярной или содержит встроенную логику (например, скрипт-задача), можно добавить 1 балл.
• События (Events):
  • Простые начальные/конечные события: 0 баллов.
  • Промежуточные события (сообщение, таймер, ошибка): 1 балл за каждое, так как они прерывают линейный поток и требуют внимания к внешним условиям.
  • Сложные события (условные, сигнальные): 2 балла за их нелинейную природу.
• Шлюзы (Gateways):
  • Исключающий шлюз (Exclusive Gateway): 1 балл. Требует выбора одного из путей.
  • Параллельный шлюз (Parallel Gateway): 1 балл за разделитель, 1 балл за объединитель. Хотя не добавляет линейных путей, требует внимания к синхронизации.
  • Включающий шлюз (Inclusive Gateway): 2 балла. Наиболее сложный, так как может активировать несколько путей, создавая множество комбинаций.
  • Событийный шлюз (Event-Based Gateway): 2 балла. Ожидание конкретного события из нескольких возможных.
• Подпроцессы (Sub-processes):
  • Встроенный подпроцесс: 1 балл за сам факт наличия подпроцесса, плюс дополнительный балл за каждый уровень вложенности подпроцессов.
  • Многократно используемый (глобальный) подпроцесс: 0 баллов, так как его детали скрыты.
• Пулы (Pools) и Дорожки (Lanes): Не добавляют когнитивной сложности напрямую, но могут увеличивать её за счет потоков сообщений между пулами. Каждый поток сообщений: 1 балл.
• Артефакты (Data Objects, Groups, Text Annotations): 0 баллов, поскольку они предназначены для повышения читаемости и не прерывают поток.

Таблица баллов когнитивной сложности для элементов BPMN (пример):

Элемент BPMN	Баллы	Примечание
Простая задача	0
Многоэкземплярная задача	1
Промежуточное событие	1
Сложное событие	2
Исключающий шлюз	1
Параллельный шлюз (разделитель/объединитель)	1	Каждый
Включающий шлюз	2
Событийный шлюз	2
Встроенный подпроцесс	1	+ 1 балл за каждый уровень вложенности
Поток сообщений	1	Между пулами

Пример расчета:
Модель: Start → Task A → Exclusive Gateway (2 ветви) → (Task B / Task C) → End.
Когнитивная сложность = 0 (Start) + 0 (Task A) + 1 (Exclusive Gateway) + 0 (Task B) + 0 (Task C) + 0 (End) = 1.

Модель с подпроцессом: Start → Task X → Call Activity (Sub-process) → End. Внутри подпроцесса: Sub-Start → Task Y → Sub-End.
Когнитивная сложность = 0 (Start) + 0 (Task X) + 1 (Call Activity за вложенность) + 0 (End) = 1.
Если бы подпроцесс был встроенным и содержал шлюз, баллы его содержимого суммировались бы с баллами основного процесса, увеличиваясь за счет вложенности.

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

Адаптация метрик глубины вложенности для BPMN-моделей

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

Методы измерения глубины вложенности в BPMN-моделях:

1. Глубина вложенности подпроцессов:
   • Каждый раз, когда задача является «вызывающей активностью» (Call Activity) или «встроенным подпроцессом» (Embedded Sub-process), она увеличивает уровень вложенности.
   • Начальный уровень (основной процесс) = 0.
   • Подпроцесс первого уровня = 1.
   • Подпроцесс внутри подпроцесса = 2, и так далее.
   • Эта метрика помогает определить, насколько сильно процесс декомпозирован и не является ли его структура слишком глубокой, что может затруднить понимание и управление.

   Пример:

   • Процесс «Обработка заказа» (Уровень 0)
     • Подпроцесс «Проверка наличия» (Уровень 1)
       • Подпроцесс «Запрос данных о товаре» (Уровень 2)

   Максимальная глубина вложенности подпроцессов = 2.

2. Глубина вложенности шлюзовых конструкций:
   • Измеряет максимальное количество последовательно вложенных шлюзов или шлюзов, управляющих ветвями, которые, в свою очередь, содержат другие шлюзы.
   • Например, шлюз, который внутри одной из своих ветвей приводит к другому шлюзу.
   • Сложные комбинации шлюзов (особенно «ИЛИ» или «Событийные») могут значительно увеличить когнитивную нагрузку.

   Пример:
   Task A → Exclusive Gateway 1 (ветвь 1) → Task B → Exclusive Gateway 2 (ветвь 1.1) → Task C.
   В данном случае Exclusive Gateway 2 вложен в логику, управляемую Exclusive Gateway 1. Глубина вложенности шлюзов = 2.

Влияние на общую сложность и понятность модели:

• Высокая глубина вложенности подпроцессов: Может указывать на чрезмерную декомпозицию или, наоборот, на недостаточную модульность, если подпроцессы не являются повторно используемыми. Снижает общую читаемость «плоской» диаграммы.
• Высокая глубина вложенности шлюзовых конструкций: Является прямым индикатором сложности логики принятия решений. Такие участки процесса становятся «темными» зонами, где трудно проследить все возможные пути выполнения, что увеличивает риск ошибок и затрудняет анализ поведения процесса.

Рекомендации по оптимизации:

• Рефакторинг подпроцессов: Сделать подпроцессы атомарными и сфокусированными на одной задаче, или вынести их в вызываемые активности.
• Упрощение логики шлюзов: Разбить сложные шлюзовые конструкции на более простые последовательности, использовать принципы «Guard Clauses» в бизнес-логике (ранние выходы при определенных условиях).
• Использование компенсирующих потоков: Для управления ошибками, вместо чрезмерно вложенных шлюзов.

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

Применение FMESP и CFC для анализа параллелизма в BPMN-моделях

В контексте BPMN, где параллелизм является неотъемлемой частью многих бизнес-процессов, метрики FMESP (Flow Metric for Explicit Split and Parallelism) и CFC (Cyclomatic Flow Complexity) становятся ценными инструментами для количественной оценки сложности управления параллельными потоками. Они позволяют не только выявить наличие параллелизма, но и оценить его структурную и логическую сложность.

FMESP (Flow Metric for Explicit Split and Parallelism) для BPMN-моделей:

FMESP, как было отмечено ранее, направлена на измерение явного параллелизма и сложности синхронизации. В BPMN основными элементами, создающими и управляющими параллельными потоками, являются параллельные шлюзы («И» — Parallel Gateway) и многоэкземплярные задачи (Multi-Instance Tasks).

Алгоритм расчета FMESP на основе графового представления BPMN-моделей:

1. Инициализация: FMESP = 0.
2. Обход графа: Пройти по всем узлам (элементам) BPMN-модели.
3. Идентификация параллельных разделителей: Для каждого Parallel Gateway типа «разделитель» (один входящий поток, несколько исходящих):
   • FMESP = FMESP + 1.
   • (Опционально) Можно добавить балл, пропорциональный количеству исходящих потоков, если это отражает желаемый уровень детализации.
4. Идентификация параллельных объединителей: Для каждого Parallel Gateway типа «объединитель» (несколько входящих потоков, один исходящий):
   • FMESP = FMESP + 1. (Синхронизация также добавляет сложность).
5. Идентификация многоэкземплярных задач: Для каждой Multi-Instance Task:
   • FMESP = FMESP + 1. (Запускает несколько экземпляров одной задачи, то есть параллельное выполнение).
   • (Опционально) Если известно максимальное количество экземпляров, можно добавить этот коэффициент к баллу.

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

CFC (Cyclomatic Flow Complexity) для BPMN-моделей:

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

Алгоритм расчета CFC на основе графового представления BPMN-моделей:

1. Расчет базовой цикломатической сложности (VBPMN): Использовать адаптированную формулу МакКейба, учитывая все шлюзы и циклы в модели.
2. Добавление сложности потоков сообщений:
   • Для каждого Message Flow между пулами: CFC = CFC + 1. (Каждый обмен сообщением между участниками увеличивает сложность координации и внешней зависимости).
   • (Опционально) Можно добавить балл за каждый Message Event (начальный, промежуточный, конечный), который участвует в обмене сообщениями.
3. Добавление сложности объектов данных:
   • Для каждого Data Object или Data Store (хранилища данных), которое связано с более чем одной задачей (то есть используется или изменяется несколькими задачами): CFC = CFC + 0.5 (или 1). (Это отражает сложность управления данными и их состоянием).
   • (Опционально) Можно добавить балл за каждую Data Association (связь данных с задачами), особенно если она сложна.
4. Добавление сложности сложных событий:
   • Для каждого Conditional Event, Signal Event, Error Event и других нелинейных или внешнезависимых событий: CFC = CFC + 1. (Эти события вводят непредсказуемость и сложную обработку исключений).

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

Пример использования FMESP и CFC:
Рассмотрим процесс «Обработка жалобы», который включает параллельную оценку жалобы отделом качества и параллельный запрос информации у клиента, а затем синхронизирует результаты.

• Наличие Parallel Gateway (разделителя и объединителя) увеличит FMESP на 2.
• Если есть Message Flow для запроса информации у клиента (из другого пула), это увеличит CFC на 1.
• Если есть Error Event для обработки неверных данных от клиента, это также увеличит CFC на 1.

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

Интеграция метрик для комплексной оценки качества BPMN-моделей

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

Система взвешенных показателей:

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

Например, интегральный показатель качества (ИПК) может быть рассчитан как:

ИПК = wCC * CCадаптированная + wCogC * CogCадаптированная + wDoN * DoNадаптированная + wFMESP * FMESP + wCFC * CFC

Где:

• CCадаптированная, CogCадаптированная, DoNадаптированная, FMESP, CFC — значения соответствующих адаптированных метрик.
• wCC, wCogC, wDoN, wFMESP, wCFC — весовые коэффициенты, сумма которых равна 1.

Примеры установки весовых коэффициентов:

• Приоритет читаемости и понимания: Если модель предназначена в первую очередь для бизнес-пользователей и обучения, то wCogC и wDoN могут иметь более высокие значения.
• Приоритет автоматизации и надежности: Если процесс планируется автоматизировать, то wCC (для выявления сложных ветвлений), wFMESP (для параллелизма) и wCFC (для интеграционной сложности) будут более значимы.
• Приоритет управляемости и сокращения ошибок: wCC и wDoN будут важны для снижения вероятности ошибок в логике.

Рекомендации по оптимизации моделей, исходя из полученных значений метрик:

Метрика	Высокое значение сигнализирует о:	Рекомендации по оптимизации
Адаптированная Цикломатическая Сложность (CC)	Избыточном количестве ветвлений и сложной логике принятия решений.	Упростить шлюзовые конструкции, использовать подпроцессы для декомпозиции, выделить общие подпроцессы. Избегать чрезмерного использования включающих шлюзов.
Адаптированная Когнитивная Сложность (CogC)	Трудности понимания логики процесса человеком.	Разбить большие процессы на более мелкие, использовать более простые имена для задач и событий. Ограничить количество уровней вложенности. Использовать текстовые аннотации для пояснений. Убедиться, что шлюзы имеют четкие, понятные условия.
Адаптированная Глубина Вложенности (DoN)	Чрезмерной декомпозиции или запутанных иерархических структурах.	Реструктурировать подпроцессы: сделать их атомарными или вынести в вызываемые активности. Упростить вложенные шлюзовые конструкции. Использовать принцип «одного уровня абстракции» на диаграмме.
FMESP	Высоком уровне параллелизма и сложности синхронизации.	Тщательно проверить корректность параллельных шлюзов (AND Split/Join). Убедиться в отсутствии тупиков (deadlocks) и гонок (race conditions). Использовать механизмы компенсации для управления ошибками в параллельных ветвях.
CFC	Сложности взаимодействий, информационных потоков и обработки исключений.	Уменьшить количество потоков сообщений между пулами, если это возможно. Упростить работу с данными. Разработать стандартные механизмы обработки ошибок и исключений, чтобы не перегружать основную логику процесса. Декомпозировать процесс для уменьшения зависимостей.

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

Практическое применение: Кейс-стади и анализ результатов

Для демонстрации применимости и эффективности разработанной методол��гии адаптации метрик программной инженерии к моделям бизнес-процессов BPMN, рассмотрим несколько гипотетических, но реалистичных кейс-стади. Эти примеры позволят выполнить пошаговый расчет и интерпретацию метрических значений, а также сформировать практические рекомендации по оптимизации.

Выбор и описание кейс-стади: Модели бизнес-процессов

Для иллюстрации мы выберем две BPMN-диаграммы:

1. Процесс «Обработка входящей заявки»: Типичный линейный процесс с несколькими условными ветвлениями и простым циклом.
2. Процесс «Регистрация нового клиента»: Более сложный процесс с параллельным выполнением задач и использованием подпроцесса.

Кейс-стади 1: Процесс «Обработка входящей заявки»

*(Предполагается, что здесь находится изображение BPMN-диаграммы)*

Описание процесса:

• Начало: Получение заявки.
• Задача 1: «Предварительная проверка заявки».
• Исключающий шлюз X1: «Заявка валидна?».
  • Если «Нет»: Задача 2.1: "Уведомить об отклонении" → Конец.
  • Если «Да»: Задача 2.2: "Оценить приоритет".
• Исключающий шлюз X2: «Приоритет высокий?».
  • Если «Да»: Задача 3.1: "Назначить специалиста срочно".
  • Если «Нет»: Задача 3.2: "Назначить специалиста в плановом порядке".
• Параллельный шлюз P1 (объединяющий): Объединяет потоки после назначения специалиста.
• Задача 4: «Выполнить заявку».
• Исключающий шлюз X3: «Заявка выполнена успешно?».
  • Если «Нет»: Задача 5.1: "Повторить попытку". (Стрелка обратно к Задача 4, создавая цикл).
  • Если «Да»: Задача 5.2: "Отправить подтверждение".
• Конец: Заявка обработана.

Кейс-стади 2: Процесс «Регистрация нового клиента»

*(Предполагается, что здесь находится изображение BPMN-диаграммы)*

Описание процесса:

• Начало: Получена заявка на регистрацию.
• Задача 1: «Ввод основных данных клиента».
• Параллельный шлюз P1 (разделитель):
  • Ветвь 1: Подпроцесс "Проверка кредитной истории" (встроенный).
  • Ветвь 2: Задача 2.2: "Подготовка договора".
• Параллельный шлюз P2 (объединяющий): Объединяет потоки после ветвей.
• Задача 3: «Отправка договора клиенту».
• Промежуточное событие (таймер): «Ожидание подписи клиента (7 дней)».
• Исключающий шлюз X1: «Договор подписан?».
  • Если «Да»: Задача 4.1: "Активация учетной записи".
  • Если «Нет»: Задача 4.2: "Напомнить клиенту". (Стрелка обратно к Задача 3, создавая цикл)
• Конец: Клиент зарегистрирован.

Пошаговый расчет и интерпретация адаптированных метрик

Выполним расчеты для каждой модели.

Кейс-стади 1: Процесс «Обработка входящей заявки»

Элементы BPMN:

• События: Начальное (1), Конечное (1) = 2
• Задачи: 7 (Задача 1, 2.1, 2.2, 3.1, 3.2, 4, 5.1, 5.2)
• Шлюзы: 3 (X1, X2, X3) + 1 (P1 объединяющий) = 4
• Потоки последовательностей: 11

1. Адаптированная Цикломатическая Сложность (CC):

• PШлюзов = 4
• PЦиклов = 1 (цикл через X3 к Задаче 4)
• CC = PШлюзов + PЦиклов + 1 = 4 + 1 + 1 = 6
• Интерпретация: Значение 6 находится в управляемом диапазоне (≤10). Однако наличие цикла и двух последовательных условных ветвлений (X1 и X2) делает процесс умеренно сложным.

2. Адаптированная Когнитивная Сложность (CogC):

• X1 (Исключающий шлюз): +1
• X2 (Исключающий шлюз): +1
• P1 (Параллельный объединяющий шлюз): +1
• X3 (Исключающий шлюз): +1
• Цикл через X3: +1 (за прерывание линейного потока)
• CogC = 1 + 1 + 1 + 1 + 1 = 5
• Интерпретация: CogC = 5 указывает на средний уровень сложности. Логика с двумя последовательными if и одним циклом требует внимательности для понимания всех возможных путей.

3. Адаптированная Глубина Вложенности (DoN):

• Основной процесс: Уровень 0.
• Нет явных подпроцессов.
• Шлюзы X1, X2, X3 последовательны, но не вложены друг в друга и не создают глубокой иерархии в рамках ветвей.
• DoN = 0 (или 1, если считать основной процесс уровнем вложенности).
• Интерпретация: Низкая глубина вложенности указывает на относительно «плоскую» структуру, что хорошо для понимания.

4. FMESP:

• Нет параллельных разделителей.
• P1 (Параллельный объединяющий шлюз): +1
• Нет многоэкземплярных задач.
• FMESP = 1
• Интерпретация: Низкий уровень явного параллелизма. Основная сложность связана с синхронизацией после выбора пути.

5. CFC:

• Базовая CC = 6
• Потоки сообщений: 0
• Объекты данных: Предположим, 1 объект «Заявка» связан с несколькими задачами: +0.5
• Сложные события: 0
• CFC = 6 + 0.5 = 6.5
• Интерпретация: Близка к цикломатической сложности, что говорит о том, что основные сложности связаны со структурными ветвлениями, а не с внешними взаимодействиями или обработкой сложных событий.

Кейс-стади 2: Процесс «Регистрация нового клиента»

Элементы BPMN:

• События: Начальное (1), Конечное (1), Промежуточное (таймер, 1) = 3
• Задачи: 5 (Задача 1, 2.2, 3, 4.1, 4.2)
• Подпроцессы: 1 («Проверка кредитной истории»)
• Шлюзы: 2 (P1 разделитель, P2 объединитель) + 1 (X1 исключающий) = 3
• Потоки последовательностей: 11

1. Адаптированная Цикломатическая Сложность (CC):

• PШлюзов = 3 (P1, P2, X1)
• PЦиклов = 1 (цикл через X1 к Задаче 3)
• CC = PШлюзов + PЦиклов + 1 = 3 + 1 + 1 = 5
• Интерпретация: Значение 5 также находится в управляемом диапазоне. Параллельные ветви не увеличивают линейно независимые пути, но цикл через X1 добавляет сложность.

2. Адаптированная Когнитивная Сложность (CogC):

• P1 (Параллельный разделитель): +1
• P2 (Параллельный объединитель): +1
• Встроенный подпроцесс: +1 (за сам факт вложенности)
• Промежуточное событие (таймер): +1 (прерывание линейного потока)
• X1 (Исключающий шлюз): +1
• Цикл через X1: +1 (за прерывание линейного потока)
• CogC = 1 + 1 + 1 + 1 + 1 + 1 = 6
• Интерпретация: CogC = 6, что немного выше, чем у первого кейса. Это объясняется наличием как параллелизма, так и цикла, а также промежуточного события и подпроцесса, что увеличивает когнитивную нагрузку.

3. Адаптированная Глубина Вложенности (DoN):

• Основной процесс: Уровень 0.
• Подпроцесс «Проверка кредитной истории»: Уровень 1.
• DoN = 1
• Интерпретация: Глубина вложенности = 1, что является приемлемым. Однако, если бы внутри подпроцесса были еще шлюзы или другие подпроцессы, метрика быстро бы росла.

4. FMESP:

• P1 (Параллельный разделитель): +1
• P2 (Параллельный объединитель): +1
• Нет многоэкземплярных задач.
• FMESP = 1 + 1 = 2
• Интерпретация: Уровень параллелизма выше, чем в первом кейсе, что указывает на необходимость проверки корректности синхронизации и возможных проблем с параллельным выполнением.

5. CFC:

• Базовая CC = 5
• Потоки сообщений: 0 (нет явных межпуловых сообщений)
• Объекты данных: Предположим, 1 объект «Данные клиента» связан с несколькими задачами: +0.5
• Сложные события: Промежуточное событие (таймер) можно считать сложным: +1
• CFC = 5 + 0.5 + 1 = 6.5
• Интерпретация: CFC близка к CogC, что подтверждает сложность, связанную с ожиданием внешнего события (таймера) и управлением данными.

Формирование рекомендаций по оптимизации BPMN-моделей

На основе проведенного анализа метрик можно сформулировать конкретные рекомендации для каждой модели.

Кейс-стади 1: Процесс «Обработка входящей заявки» (CC=6, CogC=5, DoN=0, FMESP=1, CFC=6.5)

• Проблема: Умеренная цикломатическая и когнитивная сложность, обусловленная последовательностью условных ветвлений и циклом.
• Рекомендации:
  1. Оптимизация цикла: Цикл «Повторить попытку» через X3 может привести к бесконечному повторению. Рекомендуется добавить ограничение на количество попыток или критерий выхода из цикла (например, «Если 3 попытки неуспешны, отклонить заявку»).
  2. Упрощение логики приоритета: Если «Оценить приоритет» и «Назначить специалиста» являются тесно связанными операциями, можно рассмотреть их как часть одного подпроцесса, чтобы визуально уменьшить количество шлюзов в основном потоке.
  3. Документирование условий: Убедиться, что условия шлюзов «Заявка валидна?» и «Приоритет высокий?» четко документированы и однозначно интерпретируются.

Кейс-стади 2: Процесс «Регистрация нового клиента» (CC=5, CogC=6, DoN=1, FMESP=2, CFC=6.5)

• Проблема: Более высокая когнитивная сложность из-за параллелизма, подпроцесса и промежуточного события. Уровень параллелизма (FMESP=2) требует внимания.
• Рекомендации:
  1. Декомпозиция подпроцесса: «Проверка кредитной истории» является встроенным подпроцессом. Если этот подпроцесс сложен или может использоваться в других местах, рекомендуется превратить его в «Вызывающую активность» (Call Activity) и детализировать на отдельной диаграмме. Это снизит когнитивную сложность основного процесса и повысит модульность.
  2. Управление параллелизмом: Тщательно проверить логику работы параллельных шлюзов P1 и P2, чтобы избежать гонок или тупиков. Убедиться, что «Подготовка договора» не зависит от результатов «Проверки кредитной истории» до их синхронизации в P2. Если есть зависимость, возможно, Parallel Gateway не является лучшим выбором, и следует рассмотреть Inclusive Gateway или последовательное выполнение.
  3. Оптимизация цикла с ожиданием: Цикл «Напомнить клиенту» с промежуточным событием-таймером. Как и в первом кейсе, необходимо определить максимальное количество напоминаний и действие при истечении срока (например, автоматическое отклонение заявки).
  4. Уточнение потоков данных: Поскольку метрики показали умеренную сложность данных (CFC), стоит убедиться, что все используемые «Данные клиента» четко определены и их потоки между задачами понятны, возможно, с использованием Data Objects.

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

Преимущества и ограничения использования метрик программной инженерии для оценки качества моделей бизнес-processes

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

Преимущества методологии

1. Повышение объективности и формализации оценки:
   • Традиционная оценка моделей часто субъективна и зависит от опыта аналитика. Метрики предоставляют количественные, измеримые показатели, позволяющие проводить объективный сравнительный анализ моделей и отслеживать изменения качества с течением времени. Это переводит оценку из области искусства в область науки.
   • Использование математического аппарата теории графов для анализа BPMN-моделей придает оценке строгую формальную основу, делая ее прозрачной и проверяемой.
2. Выявление ошибок и узких мест на ранних этапах моделирования:
   • Метрики позволяют автоматически обнаруживать аномалии, такие как избыточные шлюзы, чрезмерно глубокая вложенность, или сложные параллельные ветви, которые могут быть источниками ошибок или неэффективности.
   • Раннее выявление проблем снижает затраты на их исправление, поскольку изменения в модели обходятся гораздо дешевле, чем изменения в уже внедренном процессе или автоматизированной системе.
3. Улучшение эффективности и прозрачности процессов:
   • Систематическое применение метрик стимулирует создание более простых, понятных и оптимизированных моделей. Это, в свою очередь, приводит к повышению эффективности реальных бизнес-процессов, сокращению времени выполнения, снижению затрат и уменьшению количества ошибок.
   • Прозрачные модели способствуют лучшему пониманию процессов всеми заинтересованными сторонами, от бизнес-пользователей до ИТ-специалистов.
4. Стандартизация подходов к моделированию и унификация техники:
   • Метрики могут служить основой для разработки внутренних стандартов и рекомендаций по моделированию в организации. Они позволяют установить «пороги» сложности, при превышении которых модель считается требующей доработки.
   • Стандартизация нотации BPMN и возможность ее использования как бизнес-пользователями, так и ИТ-специалистами, способствует однозначной интерпретации и унификации техники моделирования.
5. Возможность интеграции с UML и другими стандартами:
   • Методология, основанная на графовом представлении, облегчает интеграцию с другими нотациями и стандартами, такими как UML (Unified Modeling Language), особенно в части спецификации структур данных. Это позволяет создавать более полные и взаимосвязанные модели систем.

Ограничения методологии

1. Субъективность построения исходных моделей:
   • Несмотря на стандартизацию BPMN, построение моделей бизнес-процессов часто носит субъективный характер, зависящий от компетентности, опыта и даже стиля конкретного аналитика. Разные аналитики могут создать десять разных диаграмм для одной и той же задачи.
   • Это может приводить к ошибкам, связанным с неверным использованием элементов BPMN (например, неправильные шлюзы, открытые пулы без событий), что, в свою очередь, искажает результаты метрического анализа.
2. Ограничения BPMN в моделировании потоков информации и межпроцессного взаимодействия:
   • BPMN, в первую очередь, ориентирована на поток управления, а не на потоки данных. Ее способность адекватно моделировать связанные с данными соединения ограничена, что может затруднить применение метрик, касающихся сложности информационных взаимодействий (например, определенных аспектов CFC).
   • Хотя для моделирования этих соединений на уровне данных может использоваться элемент хранилища данных, это не всегда достаточно для полного анализа.
3. Высокий порог вхождения нотации и специализированных метрик:
   • BPMN сама по себе является достаточно сложной нотацией с большим количеством элементов и правил. Для ее эффективного использования требуется значительное время на изучение по сравнению с более простыми нотациями (блок-схемы, IDEF0).
   • Применение специализированных метрик из программной инженерии также требует дополнительного обучения и понимания их теоретических основ, что может быть барьером для широкого внедрения без соответствующей подготовки.
4. Необходимость развития специализированных инструментов для автоматического расчета:
   • Ручной расчет метрик для сложных BPMN-моделей является трудоемким и подверженным ошибкам. Для полноценного внедрения методологии необходима разработка или адаптация программных средств, способных автоматически преобразовывать BPMN-модели в графы и рассчитывать все адаптированные метрики.
   • Существующие формальные методы позволяют лишь предположить наличие ошибок, но не всегда позволяют точно определить их количество и местонахождение в сложной модели.
5. Не всегда прямое соответствие между метрикой и бизнес-ценностью:
   • Высокое значение метрики сложности не всегда означает, что процесс «плохой». Иногда сложный процесс объективно отражает сложную бизнес-реальность. Важно не просто снижать метрики, а понимать, почему они высоки, и оптимизировать процесс, не теряя его функциональности или необходимой детализации.

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

Вызовы и перспективы дальнейших исследований

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

Ключевые вызовы

1. Субъективный характер построения моделей и неоднозначность интерпретации:
   • Как уже отмечалось, субъективность при создании BPMN-моделей является серьезным вызовом. Ошибки, связанные с компетентностью аналитика, неполным описанием предметной области или использованием нестандартных подходов, могут искажать результаты метрического анализа.
   • Необходима разработка более строгих гайдлайнов и автоматизированных средств валидации, которые бы снижали влияние человеческого фактора на качество исходных моделей.
2. Ограниченность существующих методов выявления и локализации ошибок:
   • Существующие формальные методы позволяют лишь предположить наличие ошибок или аномалий в модели, но не предоставляют точных инструментов для количественной оценки всех ошибок или автоматического определения их конкретного местоположения и типа в сложной модели.
   • Например, метрика может показать высокую сложность, но не указать, какой именно шлюз или последовательность действий является причиной этой сложности и как ее исправить наиболее эффективно.
3. Необходимость разработки подходов к анализу и оптимизации моделей для представления организационных знаний:
   • Модели бизнес-процессов часто используются не только для автоматизации, но и для документирования организационных знаний, обучения персонала. Для таких целей важна не только структурная корректность, но и педагогическая ценность, легкость понимания.
   • Требуется дальнейшая формализация правил построения моделей на основе ориентированных графов, учитывающая не только технические, но и «когнитивные» аспекты, а также разработка метрик для оценки наглядности и понятности.
4. Адаптация метрик к различным целям моделирования:
   • Различные цели моделирования (например, автоматизация, анализ производительности, обучение, нормативное соответствие) требуют различных акцентов в оценке качества. Метрики должны быть гибкими и адаптируемыми к этим целям.
   • Необходимо разработать методики выбора и взвешивания метрик в зависимости от конкретного контекста применения модели.

Перспективы дальнейших исследований

1. Разработка программных средств для автоматизации метрического анализа:
   • Ключевым направлением является создание специализированных программных инструментов, которые смогут автоматически парсить BPMN-модели (на основе их XML-схемы), преобразовывать их в графы, рассчитывать все известные и перспективные метрики, а также визуализировать результаты и генерировать рекомендации.
   • Такие инструменты должны быть интегрированы с существующими платформами моделирования BPMN.
2. Расширение методологии для учета временных и ресурсных характеристик:
   • Текущие метрики в основном оценивают структурную сложность. Перспективно интегрировать в методологию метрики, учитывающие временные (длительность задач, простои) и ресурсные (загрузка исполнителей, стоимость) характеристики, которые могут быть получены из симуляций или исторических данных выполнения процессов.
   • Это позволит перейти от статической оценки к динамической и предсказательной аналитике.
3. Проведение эмпирических исследований корреляции метрик с реальной эффективностью:
   • Для подтверждения валидности и практической ценности метрик необходимо провести масштабные эмпирические исследования. Цель — установить прямые корреляции между значениями метрик BPMN-моделей и реальными показателями эффективности бизнес-процессов (например, время выполнения, количество ошибок, удовлетворенность клиентов).
   • Это позволит калибровать метрики и устанавливать обоснованные пороговые значения.
4. Интеграция с другими стандартами и платформами:
   • Расширение возможностей интеграции разработанных инструментов за счет использования форматов BPMN 2.0, BPEL (Business Process Execution Language), CMMN (Case Management Model and Notation) и DMN (Decision Model and Notation) на основе XML. Это позволит создавать комплексные решения для управления и оценки не только процессов, но и случаев и решений.
   • Исследование возможности применения метрик к другим графовым представлениям, таким как сети Петри, используемые в анализе потоков работ.
5. Разработка «умных» систем поддержки моделирования:
   • Создание систем, которые в режиме реального времени могли бы анализировать модель в процессе ее создания, выдавать предупреждения о потенциальных проблемах сложности или ошибках, а также предлагать варианты оптимизации.

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

Заключение

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

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

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

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

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

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

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

Список использованной литературы

1. Quality metrics for business process models / Vanderfeesten I., Cardoso J., Mendling J., Reijers H.A., van der Aalst W. // BPM and Workflow handbook.
2. Evaluating workflow process designs using cohesion and coupling metrics / Vanderfeesten I., Reijers H.A., Van der Aalst W.M.P. // Computers in industry. Vol. 59.
3. On a quest for good process models: the cross-connectivity metric / Vanderfeesten I., Reijers H.A., Mendling J., van der Aalst W.M.P., Cardoso J. // Advanced Information Systems Engineering.
4. Ajtai M. S11-formulae on finite structures // Annals of Pure and Applied Logic. 1983. Vol. 24. P. 1–48.
5. Alon N. Covering graphs by the minimum number of equivalence relations // Combinatorica. 1986. Vol. 6. P. 201–206.
6. Alon N. Eigenvalues, geometric expanders, sorting in rounds, and Ramsey Theory // Combinatorica. 1986. Vol. 6. P. 207–219.
7. Aalst W.M.P. van der. On the automatic generation of workflow processes based on product structures // Computers in Industry. 1999. Vol. 39, № 2. P. 97-111.
8. Workflow Mining: Discovering Process Models from Event Logs / Aalst W.M.P. van der, Weijters A.J.M.M., Maruster L. // IEEE Transactions on Knowledge and Data Engineering. 2004. Vol. 16, № 9. P. 1128–1142.
9. Latva-Koivisto M. Finding a complexity measure for business process models. Helsinki University of Technology, 2002.
10. Cardoso J. How to measure the control-flow complexity of web processes and workflows // The Workflow Handbook. 2005. P. 199–212.
11. Оценка качества системы с использованием стандарта ISO 9126 // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/otsenka-kachestva-sistemy-s-ispolzovaniem-standarta-iso-9126 (дата обращения: 31.10.2025).
12. Метрики и атрибуты оценки качества программного обеспечения // Fortus-ltd.ru. URL: http://www.fortus-ltd.ru/upload/iblock/c34/metriki-i-atributy-otsenki-kachestva-programmnogo-obespecheniya.pdf (дата обращения: 31.10.2025).
13. Модели, методы, показатели, характеристики и метрики, применяемые в экспертных системах оценки качества разработки и создания инновационных программных проектов // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/modeli-metody-pokazateli-harakteristiki-i-metriki-primenyaemye-v-ekspertnyh-sistemah-otsenki-kachestva-razrabotki-i-sozdaniya-innovatsionnyh (дата обращения: 31.10.2025).
14. Показатели оценки бизнес-процессов предприятия // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/pokazateli-otsenki-biznes-protsessov-predpriyatiya (дата обращения: 31.10.2025).
15. Сравнительный анализ характеристик качества программного обеспечения // Core.ac.uk. URL: https://core.ac.uk/download/pdf/196657997.pdf (дата обращения: 31.10.2025).
16. Моделирование бизнес процессов организации: цели, методы и результаты // Intuit.ru. URL: https://www.intuit.ru/studies/courses/3642/780/lecture/17814 (дата обращения: 31.10.2025).
17. Next-Generation Business Process Management (BPM): A Systematic Literature Review of Cognitive Computing and Improvements in BPM // Researchgate.net. URL: https://www.researchgate.net/publication/380545067_Next-Generation_Business_Process_Management_BPM_A_Systematic_Literature_Review_of_Cognitive_Computing_and_Improvements_in_BPM (дата обращения: 31.10.2025).
18. Использование формулы Байеса при оценивании качества программного обеспечения согласно стандарту ISO/IEC 9126 // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/ispolzovanie-formuly-bayesa-pri-otsenivanii-kachestva-programmnogo-obespecheniya-soglasno-standartu-iso-iec-9126 (дата обращения: 31.10.2025).
19. Моделирование бизнес-процессов предприятия на основании процессно-р // Elar.urfu.ru. URL: https://elar.urfu.ru/bitstream/10995/107080/1/m_vm_2021_64.pdf (дата обращения: 31.10.2025).
20. Эталонные и референтные модели бизнес-процессов // Dainova.com. URL: https://dainova.com/blog/etalonnye-i-referentnye-modeli-biznes-protsessov/ (дата обращения: 31.10.2025).
21. Метрики курсовых проектов по бизнес-моделированию // Elibrary.ru. 2018. URL: https://elibrary.ru/item.asp?id=35061405 (дата обращения: 31.10.2025).
22. Подход к анализу и оптимизации моделей бизнес-процессов в нотации BPMN // Elibrary.ru. 2018. URL: https://elibrary.ru/item.asp?id=35451962 (дата обращения: 31.10.2025).
23. Современные аспекты моделирования бизнес-процессов предприятий металлургической отрасли c использованием стандарта IDEF0 // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/sovremennye-aspekty-modelirovaniya-biznes-protsessov-predpriyatiy-metallurgicheskoy-otrasli-c-ispolzovaniem-standarta-idef0 (дата обращения: 31.10.2025).
24. Комплексное моделирование сложных процессов на основе нотации BPMN // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/kompleksnoe-modelirovanie-slozhnyh-protsessov-na-osnove-notatsii-bpmn (дата обращения: 31.10.2025).
25. Метрика Cognitive complexity или простой способ измерить сложность кода // Habr.com. 2021. URL: https://habr.com/ru/articles/565780/ (дата обращения: 31.10.2025).
26. ПЕРЛ И.А., КАЛЁНОВА О.В. – Университет ИТМО. URL: https://itmo.ru/file/pages/44/Perl_Kalenova_book.pdf (дата обращения: 31.10.2025).
27. Анализ существующих моделей разработки программного обеспечения информационных систем // Elibrary.ru. 2021. URL: https://elibrary.ru/item.asp?id=45781600 (дата обращения: 31.10.2025).
28. Средство для определения качества программного обеспечения методами метрического анализа // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/sredstvo-dlya-opredeleniya-kachestva-programmnogo-obespecheniya-metodami-metricheskogo-analiza (дата обращения: 31.10.2025).
29. Качество программного обеспечения // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/kachestvo-programmnogo-obespecheniya (дата обращения: 31.10.2025).
30. Когнитивная сложность // Oscat.ru. URL: https://oscat.ru/articles/cognitive-complexity/ (дата обращения: 31.10.2025).
31. Модели жизненного цикла и технологии проектирования программного обеспечения — Университет Лобачевского // Unn.ru. 2013. URL: http://www.unn.ru/pages/issues/vestnik/99999999_Base_2013_1/181.pdf (дата обращения: 31.10.2025).
32. Критерии оценки качества бизнес–процессов предприятия // Psu.by. 2016. URL: http://www.psu.by/images/stories/nauka/konferencii/2016/ekonomika_i_obschestvo/4.pdf (дата обращения: 31.10.2025).
33. Компьютерная модель проекта как основа изучения процесса разработки программного обеспечения // Fundamental-research.ru. URL: https://fundamental-research.ru/ru/article/view?id=38085 (дата обращения: 31.10.2025).
34. Система показателей бизнес-процессов, сбалансированная по критерию «цена-качество» // Businessstudio.ru. URL: https://www.businessstudio.ru/articles/sistema_pokazateley_biznes_protsessov_sbalansirovannaya_po_kriteriyu_tsena_kachestvo/ (дата обращения: 31.10.2025).
35. Что делает код трудным для чтения? Визуальные паттерны сложности // Habr.com. 2023. URL: https://habr.com/ru/companies/otus/articles/725798/ (дата обращения: 31.10.2025).
36. Управление сложностью программного обеспечения: стратегии и преимущества // In-com.ru. URL: https://in-com.ru/upravlenie-slozhnostyu-programmnogo-obespecheniya-strategii-i-preimushchestva/ (дата обращения: 31.10.2025).
37. Метрики сложности кода // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/metriki-slozhnosti-koda (дата обращения: 31.10.2025).
38. Эволюция и анализ моделей жизненного цикла разработки программного обеспечения // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/evolyutsiya-i-analiz-modeley-zhiznennogo-tsikla-razrabotki-programmnogo-obespecheniya (дата обращения: 31.10.2025).
39. Показатели эффективности бизнес-процессов и их оценка // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/pokazateli-effektivnosti-biznes-protsessov-i-ih-otsenka (дата обращения: 31.10.2025).
40. Система детерминированных драйверов метрик оценки эффективности ключевых бизнес-процессов // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/sistema-determinirovannyh-drayverov-metrik-otsenki-effektivnosti-klyuchevyh-biznes-protsessov (дата обращения: 31.10.2025).
41. Библиотека БГУИР // Libeldoc.bsuir.by. URL: https://libeldoc.bsuir.by/handle/123456789/4955 (дата обращения: 31.10.2025).
42. Показатели vs метрики (не только продуктовые): отличия и примеры для бизнес-аналитика с комментариями из BABOK®Guide // Dev.by. URL: https://www.dev.by/news/pokazateli-vs-metriki (дата обращения: 31.10.2025).
43. Оценка работы процессов. Показатели и метрики // Itexpert.ru. URL: https://www.itexpert.ru/articles/it-management/metrics-and-processes.html (дата обращения: 31.10.2025).
44. Сравнительный анализ нотаций моделирования бизнес-процессов // ECM-Journal. URL: https://ecm-journal.ru/journals/Sravnitelnyi-analiz-notacii-modelirovanija-biznes-processov.aspx (дата обращения: 31.10.2025).
45. Как измерить и оптимизировать бизнес-процесс: разбираемся с показателями // Analyst.by. URL: https://www.analyst.by/blog/kak-izmerit-i-optimizirovat-biznes-process-razbiraemsya-s-pokazatelyami (дата обращения: 31.10.2025).
46. 18 лучших инструментов и методов анализа процессов в 2024 году // Businessstudio.ru. 2024. URL: https://www.businessstudio.ru/articles/18_luchshikh_instrumentov_i_metodov_analiza_protsessov_v_2024_godu/ (дата обращения: 31.10.2025).
47. Методологии проектирования систем организационного управления // Asu.ru. URL: https://www.asu.ru/files/documents/00021612.pdf (дата обращения: 31.10.2025).
48. Необходимые и избыточные развилки в нотации BPMN 2. 0 // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/neobhodimye-i-izbytochnye-razvilki-v-notatsii-bpmn-2-0 (дата обращения: 31.10.2025).
49. О методах оценки сложности алгоритмов // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/o-metodah-otsenki-slozhnosti-algoritmov (дата обращения: 31.10.2025).
50. Подход к анализу и оптимизации моделей бизнес-процессов в нотации BPMN // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/podhod-k-analizu-i-optimizatsii-modeley-biznes-protsessov-v-notatsii-bpmn (дата обращения: 31.10.2025).
51. Сравнение моделей бизнес-процессов в формате BPMN 2.0 XML // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/sravnenie-modeley-biznes-protsessov-v-formate-bpmn-2-0-xml (дата обращения: 31.10.2025).
52. Методы формализации когнитивной графики и визуальных моделей с использованием схем XML // Elibrary.ru. 2021. URL: https://elibrary.ru/item.asp?id=46101416 (дата обращения: 31.10.2025).
53. Богословская Н.В. и др. Педагогические науки. 2023 // Izdsreda.ru. 2023. URL: http://izdsreda.ru/data/documents/pedagogicheskie-nauki-2023-3-1.pdf (дата обращения: 31.10.2025).
54. Основные методологии и подходы к моделированию бизнес-процессов компании // Cyberleninka.ru. URL: https://cyberleninka.ru/article/n/osnovnye-metodologii-i-podhody-k-modelirovaniyu-biznes-protsessov-kompanii (дата обращения: 31.10.2025).
55. Анализ и оптимизация моделей бизнес-процессов в нотациях EPC и BPMN // Researchgate.net. 2018. URL: https://www.researchgate.net/publication/329590509_ANALIZ_I_OPTIMIZACIA_MODELEJ_BIZNES-PROCESSOR_V_NOTACIAH_EPC_I_BPMN (дата обращения: 31.10.2025).