Основы методологии Waterfall и её структура в разработке

Методология Waterfall получила название из-за последовательной структуры: каждый этап начинается только после завершения предыдущего, как вода в каскаде. Это объясняет и второе название — каскадная модель разработки программного обеспечения. Winston Royce впервые описал и предложил эту классическую модель в 1970 году как методологию управления крупными проектами и определил объем работ в них. Жизненный цикл разработки в рамках методологии Waterfall удобно описывать через шесть основных этапов: анализ требований, проектирование архитектуры системы, разработку, тестирование, развёртывание и поддержку.

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

Для Junior QA это дает четкое понимание того, когда именно начинается этап тестирования проекта и какие требования нужно проверять в полном объеме. Для Senior QA это признание того, что методология Waterfall остается основательно востребованной и актуальной в значительной части индустрии, несмотря на растущую популярность гибких методологий разработки, таких как Agile и Scrum.

Процесс тестирования на каждом этапе Waterfall проекта

Тестировщики в Waterfall присутствуют на каждом этапе проекта с самого начала, не дожидаясь финального этапа тестирования. На этапе сбора требований и анализа требований QA помогает выявить требования к тестированию, определить критерии приемки и выявить возможные проблемы заранее посредством детального изучения списка требований. На этапе проектирования готовится детальная стратегия тестирования, определяется структура и план test cases, подбираются необходимые инструменты и новые технологии для реализации проекта. На этапе разработки пишут детальные тест-кейсы на основе технического задания, подготавливают тестовые данные и окружение для работы.

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

  • Требования могут изменяться в ходе выполнения работ по разработке, требуя переписывания всех test cases и сдвига сроков на следующий этап, что нарушает установленный порядок и напрягает малую команду разработчиков и специалистов
  • На этапе интеграционного тестирования модули и компоненты готовятся поэтапно, создавая сложность в планировании и невозможность полного тестирования взаимодействия между отдельными частями системы
  • На этапе UAT в конце проекта за несколько недель требуется протестировать весь накопленный функционал, поэтому нужно значительно больше специалистов и значительные ресурсы, что приводит к выгоранию и потере качества

Преимущества, недостатки Waterfall и когда его выбирать вместо Agile

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

Основные недостатки каскадного подхода: когда требования быстро меняются в ходе работы, нужно переделывать документацию и писать код заново; риск обнаружить ошибки системы на поздних этапах интеграции, когда переделка обойдется дорого; выгорание команды разработки в конце проекта при интенсивном тестировании. Выбирайте водопадную модель управления для долгих проектов (12+ месяцев) с четко определенными требованиями и водопадной методологией основных этапов разработки проекта. Избегайте применять Waterfall в стартапах, MVP проектах и маленьких командах, где итеративная разработка и гибкие методологии Scrum работают эффективнее через постоянную обратную связь и постоянное взаимодействие с заинтересованными сторонами. Waterfall — не плохая методология разработки, это эффективный инструмент для специфических условий и типов проектов, где предсказуемость важнее гибкости.