Часть I. Процесс быстрого тестирования. проектов, для которых соответствующая проблема стала фактором, повлекшим за собой провал проекта:

проектов, для которых соответствующая проблема стала фактором, повлекшим за собой провал проекта:

• Неполнота требований (13.1%)

• Неучастие пользователя в разработке требований (12.4%)

• Нереалистичные ожидания (9.9%)

• Изменение требований и спецификаций (8.7%)

• Отпала потребность в системе (7.5%).

Одним из результатов этого отчета является вывод о том, что большое число де­ фектов может быть внесено в продукт уже на стадии формулирования требований. Когда дефекты попадают в требования, возникает их волнообразное распростране­ ние на весь процесс разработки, устранение последствий которого требует больших затрат средств и времени. Боем (Boehm) и Папаччио (Papaccio) (которые цитируют­ ся в [42]) утверждают, что если затраты на обнаружение и устранение дефекта на ста­ дии формулирования требований составляют $1, то на стадии проектирования эти затраты увеличиваются до $5, на стадии кодирования — $10, на стадии модульного тестирования — $20, а после поставки программного продукта заказчику стоимость работ по устранению того же дефекта достигает $200. Диаграмма, иллюстрирующая затраты на устранение дефекта на разных стадиях разработки, показана на рис. 2.1. По большей части такая эскалация затрат связана с необходимостью повторного вы­ полнения работ на стадии, предшествующей той, на которой этот дефект был обна­ ружен и устранен.

$200-

Рис. 2.1. Стоимость устранения дефекта на стадии разработки. Приводится из [28]

Опубликованный группой Standish Group анализ данных, который имеет целью определить причины неудачного завершения проектов и стоимость устранения де­ фектов не на ранних, а на поздних стадиях цикла разработки, недвусмысленно свиде­ тельствует в пользу применения статического тестирования на стадии формулирова­ ния требований с тем, чтобы предотвратить проникновение дефектов на более позд­ ние стадии.

Две причины для привлечения тестовой группы для участия на ранней стадии формулирования требований могут быть определены следующим образом:

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

• Тестовая группа должна проводить статическое тестирование спецификаций требований с тем, чтобы предотвратить попадание дефектов на более поздние стадии разработки. Успешное статическое тестирование на стадии формулиро­ вания требований позволяет сэкономить время и затраты.

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

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