Продукты работы аналитика

Пожалуй, начать следует с напоминания классики. На следующем рисунке показан набор продуктов дисциплины "Требования" RUP[1].

В этой статье я буду называть всех участников разработки требований "аналитиками". Подробно характеризовать каждый продукт работы я тоже не буду: я не ставил перед собой задачу написать очередной учебник по управлению требованиями к ПО. Остановлюсь на продуктах, качество которых, на мой взгляд, больше всего влияет на успешность выполнения проекта (сохраняются названия рабочих продуктов RUP):

• План управления требованиями

На мой взгляд, это единственный документ, который должен быть утвержден на высшем уровне руководством заказчика и исполнителя. Грамотно составленный документ позволяет избежать множества проблем во взаимоотношениях между участниками проекта[2].

• Видение

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

Явно определяются заинтересованные лица и указываются их обязанности по отношению к проекту. Эффективное средство "управления" "неадекватными" заинтересованными лицами[3].

Одна из статей будет специально посвящена моделированию Видения и генерации документа как отчета SoDA.

• Модель прецедентов

Опыт моих общений с аналитиками, особенно с начинающими, свидетельствует, что многие из них считают синонимами понятия "модели прецедентов" и "диаграммы прецедентов". А ведь это далеко не так!

Диаграмма прецедентов – это всего лишь графическое представление списка функций системы в терминах реализуемых системой целей пользователей.

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

Известный гуру в области определения требований к системам Алистер Коберн обиделся на диаграммы прецедентов[4] за их нецелевое использование начинающими аналитиками и "выплеснул вместе с водой ребенка": моделирование на UML вообще.

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

• Дополнительные спецификации

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

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

• Спецификация требований к программному обеспечению

В RUP это документ, который содержит все требования к системе, функциональные и нефункциональные.

Собственно, разработчикам такой документ не нужен. Но некоторые заказчики требуют "ТЗ по ГОСТу". Никакой новой информации, по сравнению с перечисленными выше продуктами работы, этот документ  содержать не может. Если это так, то он, как и другие документы, может быть сгенерирован из моделей.

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

Должен признаться, я никогда не пытался создать шаблон отчета для "ТЗ по ГОСТу". Но проблем здесь я не вижу!

А должен ли аналитик моделировать бизнес[5]?

Должен только в одном случае: если бизнес-модель должна быть включена в комплект поставки (мы говорим о бизнес-моделировании для определения требований к системе).

Давайте сформулируем вопрос по-другому: нужно ли моделировать бизнес в проектах разработки ПО. Я глубоко убежден, что за редкими исключениями это очень полезно, и в первую очередь – самому аналитику.

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

Когда аналитик беседует с заинтересованными лицами, то даже самые "заинтересованные" из них часто забывают такие тонкости, как события в других частях бизнеса или изменения рабочего потока по условию. Это естественно: они об этом просто не задумываются, считают естественным, и думают, что компьютер поступит также. Увы!

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

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

Бизнес-моделирование в RUP

Бизнес-моделирование в RUP определяется через цели:

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

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

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

Терминология: Термины "бизнес-прецедент" и "бизнес-процесс" в RUP считаются синонимами. Я применяю термин "бизнес-процесс", имеющий приблизительно одинаковый смысл и в других методиках моделирования бизнеса.

Упрощенное моделирование существующего бизнеса

Бизнес-моделирование в RUP следует принципам объектно-ориентированного подхода к моделированию бизнеса. И в задачах проектирования нового или реинженеринга существующего бизнеса этот подход имеет неоспоримые преимущества. Но в проектах разработки ПО для существующего бизнеса в разделении модели на "внешнюю" и "внутреннюю" нет необходимости. А почти удвоенные трудозатраты – слишком высокая цена за строгое следование принципам при равноценных результатах.

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

Документ "Указания по бизнес-моделированию", который я рекомендую использовать для проектов ПО небольшого и среднего размера, можно скачать по адресу: Повышение производительности аналитика 02, Приложение

Пример бизнес-моделирования[7]

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

Пример, на мой взгляд, хорош тем, что, с одной стороны его предметная область – управление оказанием услуг, – достаточно общая, и модель, после адаптации, может быть применена на практике. С другой стороны, тема эта "не избита" в многочисленных примерах моделирования[8].

Некоторые соображения:

• Что такое бизнес-процесс?

UML родился больше 15 лет назад, но до сих пор в многочисленных аудиториях многочисленные аналитики спорят, что есть прецедент (use case, вариант использования и т.д.), а что нет. В бизнес-моделировании ситуация та же. Но, т.к. бизнес-моделирование на UML распространено меньше, и споров меньше.

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

• Бизнес-процесс затрагивает весь бизнес или существенную его часть
• При выполнении обязанностей по реализации целей бизнеса, бизнес-процессы обладают низкой связанностью и высоким зацеплением

Множество организаций выполняют один единственный основной бизнес-процесс[9]. В примере моделирования это бизнес-процесс "Оказание услуги".

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

• Степень детализации бизнес-модели

Я высказывал эту мысль выше: "Бизнес-модель нужна, прежде всего, аналитику как систематизированная информация для определения требований к системе".

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

Излишняя детализация смысла не имеет.

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

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

Скачивайте и смотрите веб-публикацию модели с помощью вашего браузера или модель непосредственно в RSA. И помните, что модель UML – это не только картинки.