В 2002 году под заголовком «Современные методы описания функциональных требований к системам» на русском языке была выпущена книга Алистера Коберна «Writing Effective Use Cases» (скачать русскую версию в djvu можно по этой ссылке)
Книжка эта, конечно, в первую очередь о требованиях, но и не только о требованиях. В действительности, автор излагает подход к моделированию процессов, позволяющий не использовать графическую нотацию. Я предвижу праведный гнев бизнес-аналитиков. Однако считаю совершенно необходимым поделиться с экспертами, занимающимися бизнес-процессами, данным подходом к их моделированию.
Сначала слово Коберну:
Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использование описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях. Основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Различные модели поведения, или сценарии, развертываются в зависимости от определенных запросов и условий, при которых делались эти запросы. Вариант использования собирает вместе эти сценарии.
В концептуальном плане подход Алистера Коберна очень силен. Система, как контракт, защищающий интересы участников, непрерывно разворачивающая история преследования действующими лицами своих целей и т.п. – отличные идеи. Однако в этом сообщения я буду говорить о конструктивном наполнении вариантов использования, т.е. об описании конкретных сценариев в виде последовательностей шагов.
Ни в одной из графических нотаций, я не встречал серьезных рекомендаций по взаимному расположению действий, заданий и соединяющих их потоков и ассоциаций (пулы и «дорожки» — не считаются). Т.е. вы можете располагать квадратики и объединять их стрелками, как вам заблагорассудиться. Идущие следом друг за другом активности можно расположить в разных частях страницы и соединить стрелкой потока управления, предварительно сделав десяток оборотов вокруг одной из задач. Подозреваю, что процессные модельеры тратят массу времени именно на подобные манипуляции.
Для начала, Алистер Коберн избавляется от ветвлений процесса. Не от самих ветвлений, а от их графического отображения, превращающего бизнес-модель в захватывающую карту «острова сокровищ».
Правило 1. В любом процессе необходимо выделить основной сценарий, определить типичный ход событий, линейную последовательность шагов, наиболее быстро приводящую главное действующее лицо к цели. По сути, мы должны определить на нашей карте кратчайший путь от начала процесса, до его успешного завершения. Шаги этого пути надо выписать в обыкновенный список. Не надо никаких стрелок от первого шага ко второму и от второго к третьему. Шаги следуют друг за другом. Не надо никаких квадратиков со скругленными краями, внутрь которых засовывается описание действия с аббревиатурами и сокращениями. Простой набор нумерованных текстовых строк, следующих друг за другом в линейном порядке.
Правило 2. Любой сход с трека основного сценария оформляется как Исключение. Исключение – это не обязательно плохо. Это просто уход процесса с основного пути, т.е. некоторое отклонение от типичного хода событий. Там где раньше, после задания с именем А вы хотели нарисовать оператор исключающего ИЛИ и две стрелки, первая ведущая к заданию B, а вторая к заданию С вам следует поступить иначе. Например, задания A и B включить в основной сценарий, а переход к заданию С считать исключением. Безусловно, развитие процесса через задание B должно приводить вас к завершению сценария быстрее, чем развитие сценария через задание C. Для обработки исключений мы создаем отдельные сценарии, описывающие развитие процесса в случае возникновения данного исключения. Сценарий обработки исключения может завершиться возвратом к одному из шагов основного сценария или же просто завершиться.
Правило 3. Дальнейшее построение процесса осуществляется рекурсивно. Т.е. в сценарии обработки исключений, так же могут возникнуть исключения и для их обработки мы должны разработать необходимые сценарии.
Еще несколько правил:
- Для описания шагов сценария используйте простые предложения.
- Ясно укажите кто «владеет мячом». Т.е. после описания каждого шага сценария не должно оставаться сомнений в том, кто будет производить следующий шаг.
- Покажите продвижение процесса.
и т.д. Интересующихся отсылаю к книжке Алистера Коберна, а я подведу итог.
Следуя методу описания вариантов использования, мы получаем описание процесса в виде простых списков. Каждый список, кроме самого верхнего, прикреплен к конкретному шагу какого-то другого списка и служит для обработки исключения, которое может возникнуть на данном шаге. Этот подход обладает рядом преимуществ, как для описания процесса, так и для его представления, а именно:
- Разработка бизнес-процесса приобретает итерационный характер. Вам не зачем описывать его сразу целиком. Начните с разработки основного сценария, типичного хода событий, оставив на потом обработку исключений. Проектируйте не вглубь, а вширь. Это позволит запустить процесс существенно раньше того момента, когда аналитик выяснит все многочисленные детали и нюансы. Не спешите «программировать» обработчики редко встречающихся исключений. Скорее всего, придуманный вами сценарий для обработки таких событий будет неправильным. Включите на такие шаги процесса людей, экспертов в предметной области. Пусть они разберутся с несколькими конкретными случаями. Потом вы обобщите их опыт в модели бизнес-процесса.
- Откажитесь от «карты сокровищ». Простой список из 5-7, в крайних случаях 12-15 активностей – вот модель бизнес-процесса, которую сумеют воспринять ваши пользователи. Да, возможно на каких-то шагах возникнут исключения, но описания процессов их обработки столь же просты, как и описание основного сценария. Наша команда уже много лет использует такие описания и практически все вопросы к сценариям это вопросы не по форме изложения, а по существу процесса.
- Автоматизировать разработку вариантов использования существенно проще, чем создать графический редактор, реализующий BPMN. Просто удивительно, что поставщики ПО предпочитают разрабатывать сложные и дорогостоящие графические редакторы вместо простого веб-приложения, обеспечивающего совместную работу с простыми и понятными описаниями бизнес-процессов. Задача построения картинки по структурированным данным является довольно простой, как впрочем, и задача создания работающего приложения. Задача унификации картинок, их централизованного хранения и обработки и уж тем более генерации по ним выполняемого кода на порядок сложнее.
- Варианты использования – это отличный способ описания процессов для adaptive case management. Т.к. для создания элементов процесса, описанного в виде вариантов использования не надо обладать знанием BPMN, с таким описанием может справиться любой пользователь. А именно пользователь является у нас ключевой фигурой в адаптивном кейс-менеджменте.
Честно говоря, я жду повышения интереса к методологи проектирования процессов, предложенной Алистером Коберном более десяти лет назад. Интереса, в первую очередь от поставщиков программных систем управления бизнес-процессами. До сегодняшнего день, мне не доводилось видеть программного решения, реализующего такой подход. Но я не перестаю надеяться, что в обозримом будущем мои мечты о таком инструменте сбудутся.