Использование нотаций ARIS и BPNM для описания процессов: почему необходимо следовать правилам
Здравствуйте! Меня зовут Сергей Гусев, я ведущий системный аналитик IT_One. В данной статье я бы хотел затронуть важные нюансы деятельности системного аналитика и команд разработки ПО.
Начиная новый проект или работая над модернизацией текущего проекта, в ходе обсуждения бизнес-аналитик или другое ответственное лицо собирает множество требований, которые возникают у заинтересованных сторон. Первоначально это текстовое описание, таблицы, затем к ним добавляются UML-диаграммы.
Эти инструменты позволяют описать то, как будет работать продукт и как пользователи будут с ним взаимодействовать. Чаще всего получается довольно объемный документ или набор документов, где описаны функциональные и нефункциональные требования, варианты взаимодействия (use case diagrams) и чек-листы для тестирования. Что же из этого лучше с точки зрения разработчика? В идеале – это готовый прототип программного продукта, демонстрирующий, как пользователь взаимодействует с ним, что именно требуется разработать, как и в какой последовательности должны появляться окна для заполнения информации. Остается только открыть текстовый документ, чтобы в нем свериться со свойствами атрибутов. Увы, чаще всего из-за нехватки времени и желания сэкономить многие команды пренебрегают созданием такой модели.
Второй, не менее популярный, метод — это описание функционирования продукта с помощью нотаций ARIS eEPC и BPMN 2.0. Чем же они удобны?
Преимущества ARIS eEPC – простыми словами
Нотацию ARIS eEPC разработал основатель IDS Scheer Август Вильгельм Шеер со своими коллегами. Взяв за основу методологию IDEF3, он дополнил ее до модели EPC – расширенной цепочки процесса, управляемого событиями, которую позже стали называть «процессно-событийная модель» (дословно Event-driven Process Chain). Используемая для моделирования бизнес-процессов в инструментарии ARIS, она представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение определенного результата. По сути, если созданная модель описывает функциональность разрабатываемого ПО, то она является инструкцией для разработчика.
Подробнее по ссылке.