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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 13.2.
Пользовательское требование	Функциональное требование	Элемент дизайна	Модуль кода	Вариант тестирования
UC-28	catalog.query.sort	Каталог класса	catalog.sort()	search.7 search.8
UC-29	catalog.query.import	Каталог класса	catalog.import() catalog.validate()	search.12 search.13 search.14

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

¹⁾ Royce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9 ²⁾ Исключение составляют, например, некоторые классы военных разработок, где до сих пор применяются модификации каскадного подхода, базирующиеся на очень тщательной проработке и верификации спецификаций и гарантирующие точное соответствие продукта спецификациям. ³⁾ Lawrence, Brian. 1996. Unresolved Ambiguity. American Programmer 9(5}:17-22 ⁴⁾ http://www-306.ibm.com/software/rational/ ⁵⁾ Брайен А. Уайт. Управление конфигурацией программных средств. Практическое руководство по Rational ClearCase: Пер. с англ. -М.:ДМК Пресс, 2002. - 272 с.: ил. (Серия "Объектно-ориентированные технологии в программировании"). ⁶⁾ Capers Jones (1994)