Методология водопада

Модель водопада определяется как последовательная модель процесса, с помощью которой развитие может быть отображено на основе последовательных фаз.

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

Разработка классической водопадной модели приписывается компьютерному ученому Уинстону В. Ройсу. Но Ройс не является изобретателем. Вместо этого в его эссе «Управление разработкой больших программных систем», опубликованном в 1970 году, содержится критический анализ линейных моделей процессов. В качестве альтернативы Ройс предлагает итеративно-инкрементальную модель, в которой каждая фаза возвращается к предыдущей и проверяет ее результаты.

Ройс предлагает модель с семью фазами, которая выполняется в несколько итераций:

1. Системные требования
2. Требования к программному обеспечению
3. Анализ
4. Проектирование
5. Реализация
6. Тестирование
7. Эксплуатация

Процедурная модель, известная как модель водопада, основана на фазах, определенных Ройсом — но сам термин появился с тех пор. В эссе, написанном Ройсом, термин «водопад» даже не встречается.

На практике используются различные версии водопадной модели. Распространены модели, которые делят процесс разработки на пять фаз. Фазы 1, 2 и 3, определенные Ройсом, иногда объединяются в фазу проекта как анализ требований.

1. 1-й анализ: планирование, анализ требований и спецификация
2. Проектирование: проектирование системы и спецификация
3. Реализация: программирование и модульные тесты
4. Интеграция системы: системные и интеграционные тесты
5. Эксплуатация: поставка, обслуживание, улучшение

На следующем рисунке показано, почему линейную модель процесса называют «моделью водопада».

Расширения простой водопадной модели дополняют базовую модель итеративными функциями — например, ребутами, позволяющими сравнивать результаты каждой фазы с предположениями, сделанными на предыдущей фазе, и таким образом проверять их.

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

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

Затем следует детальное определение требований, которое включает анализ текущей ситуации и целевую концепцию. В то время как анализ «как есть» определяет проблемную область, целевая концепция определяет, какие функции и свойства должен предлагать программный продукт, чтобы соответствовать требованиям. Результаты определения требований включают, например, спецификацию требований, подробное описание того, как должны быть выполнены требования проекта, и план приемочного тестирования.

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

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

Архитектура программного обеспечения, разработанная на этапе проектирования, реализуется на этапе внедрения, который включает программирование программного обеспечения, устранение неполадок и тестирование модулей. На этапе реализации проект программного обеспечения реализуется на требуемом языке программирования. Отдельные компоненты разрабатываются отдельно, проверяются в рамках модульного тестирования и шаг за шагом интегрируются в общий продукт. Результатом фазы реализации является программный продукт, который впервые тестируется как полноценный продукт на последующей фазе (альфа-тестирование).

Фаза тестирования включает в себя интеграцию программного обеспечения в желаемую целевую среду. Как правило, программные продукты первоначально поставляются в виде бета-версий избранным конечным пользователям (бета-тесты). Приемочные испытания, разработанные на этапе анализа, могут быть использованы для определения того, соответствует ли программное обеспечение ранее установленным требованиям. Программный продукт, успешно прошедший бета-тестирование, готов к выпуску.

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

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

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

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

Водопадные модели используются прежде всего для проектов, где требования и процессы могут быть точно описаны уже на этапе планирования и где можно предположить, что допущения будут незначительно меняться в ходе проекта. Поэтому строго линейные модели процессов подходят в первую очередь для небольших, простых и четко структурированных проектов программного обеспечения. Ройс пришел к такому выводу в 1970-х годах. Он предложил альтернативу линейной модели процесса, которая позже стала известна как водопадная модель, и включил в нее три основных усовершенствования:

Согласно Ройсу, результаты каждой фазы проекта должны немедленно сравниваться и проверяться с ранее подготовленными документами — например, после разработки модуля следует убедиться, что он соответствует ранее определенным требованиям, а не только в конце процесса разработки.

По словам Ройса, водопадная модель должна быть запущена как минимум дважды: сначала для разработки прототипа, а затем для разработки реального программного продукта.

В качестве третьего расширения водопадной модели Ройс в своем эссе призвал к мере, которая сегодня является стандартной практикой в разработке продуктов: вовлечение конечного пользователя в производственный процесс. Ройс предлагает вовлекать пользователя в процесс разработки программного обеспечения на трех этапах: Во время планирования программного обеспечения на этапе анализа, между проектированием и реализацией программного обеспечения и на этапе тестирования перед выпуском программного обеспечения.

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

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