Процедура анализа влияния изменения

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

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

2.Определите все файлы, модели и документы, которые, возможно, придется изменить, если команда включит все запрошенные изменения.

3.Определите задачи, необходимые для реализации изменения, и оцените усилия, необходимые для выполнения этих задач.

На рис. 19-5 показан контрольный список вопросов, разработанный в помощь аналитику. В списке на рис. 19-6 перечислены наводящие вопросы, которые помогут вам определить все элементы ПО, затронутые изменением. Данные трассируемости, которые связывают изменяемые требования с другими основными документами проекта, крайне полезны при анализе влияния. По мере наработки опыта при использовании этих контрольных вопросов адаптируйте их для ваших проектов.

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

1.Работайте со списком на рис. 19-5.

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

Рис. 19-5. Список возможных последствий предложенного изменения

Рис. 19-6. Список возможных элементов ПО, затрагиваемых изменением

3.Воспользуйтесь рабочей таблицей на рис. 19-7 для расчета затрат, необходимых для выполнения предполагаемых задач. Для выполнения большинства запросов на изменение потребуется только часть задач из рабочей таблицы, однако для выполнения других необходимы дополнительные задачи.

Рис. 19-7. Расчет затрат на изменение требования

4.Выполните расчет всех затрат.

5.Определите последовательность выполнения задач и то, как они могут пересекаться с уже запланированными задачами.

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

7.Оцените влияние предложенного изменения на график и затраты.

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

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

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