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

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

Большинство естественных и искусственных языков, в том числе графических, используют следующее правило чтения: "Слева направо, сверху вниз". Полагаю, что местоположение иконки "План управления требованиями" на рисунке выше явно указывает на то, какое значение придают этому документу авторы RUP.

Управление требованиями в RUP

"Управление требованиями – это систематический подход к обнаружению, документированию, организации и сопровождению изменяющихся требований к системе".

Это формальное определение подразумевает наличие двух видов деятельности в рамках управления требованиями:

• Определение, организация и документирование требований
• Установление и выполнение правил управления изменением требований

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

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

Совместная деятельность требует управления; иначе – хаос. Правила этой деятельности должны быть согласованы (а лучше – утверждены) заказчиком и исполнителем на самом высоком уровне.

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

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

RUP содержит описание рабочего продукта "План управления требованиями", шаги создания этого рабочего продукта, советы и шаблон документа MS Word[1].

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

Пример 1. Заказной проект

Контекст

История проекта:

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

По решению Губернатора СПб упомянутые подразделения были выведены из подчинения райадминистраций и переподчинены вновь созданному Главному управлению. Ознакомившись с ситуацией в сфере ИТ, руководство нового управления приняло решение о создании единой системы управления на базе наиболее удачного "районного" решения. Как, наверное, догадались читатели, за основу была выбрана система, о которой говорилось выше

Ошибка руководства компании-исполнителя состояла в том, что анализ ситуации, согласование технических требований и подготовка договора были поручены специалистам продаж (без участия технических специалистов). Технические специалисты были привлечены для выполнения готового договора и утвержденных технических требований и графика поставок! Я был приглашен в проект в качестве системного аналитика.

Заинтересованные стороны:

• Заказчик

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

• Пользователь

Районный филиал – заказчик и пользователь предыдущей версии системы. Этот филиал был избран заказчиком в качестве полигона для тестирования и приемки новой системы. Заинтересован в пошаговой поставке системы и непрерывности поддержки бизнеса при переходе на новую версию.

• Исполнитель

Заинтересован в своевременной поставке системы, соответствующей требованиям, с минимальными затратами.

Проблемы

1. Технические требования были сформулированы на очень высоком уровне, соответствующем, по мнению исполнителя, задаче доработки существующей системы.
   Фактически, требовалось разработать новую систему, повторяющую функциональность старой, но имеющую совершенно другую архитектуру развертывания
   Утвержденный календарный план не предусматривал разработки требований к системе.
2. Календарный план поставок сформулирован на очень высоком уровне в терминах "водопадной" разработки, не обеспечивающей возможности пошаговой поставки.
3. Не сохранилось никакой технической документации по предыдущей версии системы, ее разработчики уволились. Для разработки проекта была набрана временная команда
4. Договорная документация была утверждена очень высоким руководством и, реально, не могла быть изменена.

Решение

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

Были приняты следующие решения:

1. Использовать итерационный инкрементный цикл разработки
2. Детализировать календарный план, сохранив названия и сроки этапов.
3. Считать документ RUP "Видение" отчетным документом этапа "Эскизное проектирование", соответствующим образом изменив его название.
4. Разработать модель прецедентов и модель анализа системы. Для каждого прецедента выпустить спецификацию, которая будет включать описание прецедента (требования) и описание реализации прецедента (анализ). Каждую спецификацию идентифицировать как приложение к документу "Эскизное проектирование. Общий отчет".
5. Разработать и утвердить на уровне руководства заказчика, пользователя и исполнителя документ "План управления требованиями", правила которого обязательны для всех участников проекта.

Пример 2. Внутренний проект

Контекст

Документ разрабатывался в рамках внутреннего проекта "Стандартный процесс разработки ПО" в департаменте разработки ИТ крупного банка[2].

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

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

Продолжительность проекта – 8 месяцев. В этом проекте я выполнял роль наставника проекта[3].

Проблема и решение

Главная проблема – большое число связанных проектов и большое число участников. Ее следствием является сложность управления связанными требованиями и решениями многоразового использования.

Для разрешения этой проблемы в регламенте:

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

Инструменты управления требованиями

Скорее всего, ни один из примеров плана управления требованиями не подойдет Вам, если Вы не используете инструмент для управления требованиями[4].

На мой взгляд, хороший инструмент управления требованиями должен позволять:

1. Создавать требования вручную или из модельных элементов и сохранять их в хранилище требований
2. Определять типы требований с наборами атрибутов для управления требованиями
3. Устанавливать иерархии требований одинакового типа
4. Устанавливать трассируемости между требованиями одного или различных типов, в том числе между требованиями к различным проектам
5. Идентифицировать требования, которые могут потребовать изменения вследствие изменения связанных (трассированных) требований
6. Синхронизировать требования и описания связанных модельных элементов
7. Сохранять историю изменения требований
8. Генерировать рабочие и презентационные отчеты в требуемой форме

Я использую IBM Rational RequisitePro, который допускает все эти возможности.