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

Управление изменениями

Управление незапланированным ростом объема

Незапланированный рост объема ставит под удар ^{6Capers Jones (1994)} :

• 80% проектов по разработке систем управления информацией;
• 70% проектов по разработке военных систем ПО;
• 45% проектов по созданию ПО, выполняемых по контракту.

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

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

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

Другая стратегия - это умение сказать: "Нет" . Психология большинства людей устроена так, что им тяжело отказывать, что в данном случае может привести к состоянию постоянного прессинга. К.Вигерс предлагает "смягчить" этот подход, заменив "Нет", на "Не сейчас" (требование обязательно будет выполнено, но не в текущей версии). Автор лекционного курса, соответственно, хотел бы добавить в эту копилку фразу "Зачем?". Опыт показывает, что данная фраза значительно упрощает общение и позволяет сподвигнуть представителя Заказчика на размышления: а действительно ли его идея хороша, а какую конкретную пользу она принесет бизнесу его предприятия?

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

Процесс контроля изменений

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

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

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

После регистрации запроса на изменение необходимо принять решение о его дальнейшей судьбе. Совет по управлению изменениями (change control board, CCB) (иногда его называют советом по управлению конфигурацией) был признан лучшим практическим решением при разработке ПО . На практике функции Совета могут быть делегированы и одному человеку (в зависимости от размеров проекта).

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

• а) из степени важности запроса для Заказчика и
• б) из его стоимости для Разработчика. Стоимость определяется на основании анализа влияния изменения.

Анализ влияния изменения

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

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

Анализ результатов изменений затрагивает три аспекта [13.1].

1. Определите возможные последствия изменения. Часто они вызывают значительный волновой эффект. Включение множества функций в продукт может снизить его производительность до неприемлемого уровня, например, когда системе, запускаемой ежедневно, потребуется 24 часа для завершения одного запуска.
2. Определите все файлы, модели и документы, которые, возможно, придется изменить, если команда включит все запрошенные изменения.
3. Определите задачи, необходимые для реализации изменения, и оцените усилия, необходимые для выполнения этих задач.

Трассируемость требований

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

Для осуществления анализа трассируемости каждое требование должно быть уникально идентифицировано.

Рис. 13.2. Основные типы трассируемости требований

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

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

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

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

Наиболее типичный способ представления связей между требованиями и другими элементами системы - матрица трассируемости требований, которую также называют матрицей отслеживания требований или таблицей трассируемости (requirements traceability matrix). В таб. 13.2 показана иллюстрация части такой матрицы из [13.1].

Другая форма представления связей трассируемости - дерево трассировок [13.2].