[Bytextest] waterfall software development and testing model

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

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

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

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

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

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

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

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

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

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

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

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

comments powered by HyperComments