![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть 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 анализ данных, который имеет целью определить причины неудачного завершения проектов и стоимость устранения де фектов не на ранних, а на поздних стадиях цикла разработки, недвусмысленно свиде тельствует в пользу применения статического тестирования на стадии формулирова ния требований с тем, чтобы предотвратить проникновение дефектов на более позд ние стадии.
Две причины для привлечения тестовой группы для участия на ранней стадии формулирования требований могут быть определены следующим образом:
• Тестовая группа заинтересована в как можно более раннем получении макси мально точной спецификации, на основе которой можно составлять план тес тирования и проектировать тесты. Это основное условие, без выполнения ко торого тестирование на ранних стадиях не дает положительного эффекта.
• Тестовая группа должна проводить статическое тестирование спецификаций требований с тем, чтобы предотвратить попадание дефектов на более поздние стадии разработки. Успешное статическое тестирование на стадии формулиро вания требований позволяет сэкономить время и затраты.
В данной главе мы обсуждаем процесс формулирования требований с точки зре ния специалиста по тестированию. Обсуждение начинается с опроса пользователя с целью выявления требований и анализа задач, определения конкретных рабочих продуктов и точек этого процесса, в которых можно применить статическое тестиро вание. Мы также рассмотрим типы требований, необходимых для обеспечения полноты,
и предложим возможные способы тестирования требований. Кроме того, обсуждается возможность использования прототипов программного продукта при анализе требова ний, равно как и роль тестирования жизненного цикла, основанного на прототипах.
|