Тема 15. Управление изменениями требований

Мадорская Ю.М.

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

Итак, управление изменениями.

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

1) Возможно ли его реализовать в текущих условиях?
2) Сколько это будет стоить?
3) Что/кого именно затронет новшество?

В «горячей» стадии проектирования, когда скелет системы только создается и свободы еще много, изменения идут особенно быстро и тут чаще всего не нужно ограничивать аналитиков/проектировщиков какими-то формальными процедурами работы с изменениями. Более того, на мой взгляд, даже вредно слишком многим давать «подсматривать» за этой работой. Для поддержи этого режима работы удобно пользоваться разбиением пользователей на команды. Тогда только пользователи внутри команды будут видеть все черновики, все остальные — только те элементы, которые прошли утверждение.

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

Когда проект стабилизируется, появляются зафиксированные версии элементов, базовые линии, то тут уже могут понадобится более формальные процедуры отработки изменений. Для этого в Cradle есть так называемые Change Request и Change Tasks и возможность настройки workflow (алгоритма) согласования изменений. Эта функциональность особенно востребована у военных или у тех, кто выполняет для них разработку.

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

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

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

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