Модели разработки и тестирования ПО: каскадная модель

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


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

• Спецификация требований
• Дизайн
• Разработка (Имплементация или Кодинг)
• Интеграция
• Тестирование (Валидация)
• Инсталляция
• Поддержка

 

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

Преимущества каскадной модели

• Каждая фаза имеет точные контрольные данные
• Каждая фаза выполняется в своем порядке
• Отлично работает при разработке небольших проектов с прозрачными требованиями
• Иллюстрирует афоризмы «Идея предшествует дизайну» и «Дизайн предшествует коду»

Недостатки каскадной модели

• Шаткие границы проекта во время его жизненного цикла подобны смерти
• Работающий прототип отходит на задний план
• Неопределенность с высокой степенью риска
• Плохо подходит для сложных и объектно-ориентированных проектов
• Плохо подходит для проектов, рассчитанных на большой период времени
• Заложенные требования могут меняться с высокой степенью вероятности

Когда каскадная модель подходит

• Модель широко используется при наличии явных требований, которые не будут подвергаться изменениям во время разработки. Например, при разработке оборонительных проектов, где тщательный анализ предшествует написанию ТЗ.
• Также подходит для мигрирующих проектов, где требования останутся неизменны; различаться будут платформы или языки.
• Сгодится для проектов, в которых спонсоры предоставляют тестирование, поскольку проект не будет доступен до окончания написания кода.

 

По материалам Testing Excellence