Изменение не бесплатно - анализ влияния

И еще одна интересная цитата из книги Карла Вигерса. Все статьи по книге:
[1] [2] [3] [4] [5]

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

Списки могут помочь не только аналитику, но и тестировщику. Для ответа на вопрос "а все ли я учел, а все ли я проверил?"

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

1. Конфликтуют ли какие-то из требований в базовой версии с предложенным изменением?
2. Конфликтуют ли какие-то из отложенных требований в базовой версии с предложенным изменением?
3. Какие могут быть технические или бизнес-последствия, если изменение не будет внесено?
4. Какие могут быть побочные негативные эффекты или другие риски, если изменение не будет внесено?
5. Повлияет ли негативно предложенное изменение на требования к производительности и другие атрибуты качества?
6. Выполнимо ли предложенное изменение в рамках известных технических ограничений и квалификации специалистов?
7. Не потребуется ли для реализации предложенного изменения неприемлимое количество компьютерных ресурсов, необходимых для разработки, тестирования или операционной среды?
8. Нужно ли приобрести какие-либо средства для реализации и тестирования этого изменения?
9. Как предложенное изменение повлияет на последовательность, зависимости, усилия или продолжительность задач, включенных в настоящее время в план проекта?
10. Потребуется ли создание прототипов или другая информация пользователей для проверки предложенного изменения?
11. Сколько затрат, уже вложенных в проект, будут потеряны, если принять эти изменения?
12. Не увеличится ли затрата на единицу продукта при принятии изменения, например, за счет увеличения оплаты лицензирования продукта приглашенными специалистами?
13. Повлияет ли изменение на планы по маркетингу, производству, обучению или поддержки покупателей?

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

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

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

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