Waterfall

Waterfall (англ. «водопад») — модель разработки программного обеспечения, предполагающая последовательное выполнение этапов проекта, при котором каждый следующий этап начинается только после полного завершения предыдущего. Относится к классу каскадных моделей жизненного цикла программного обеспечения. Впервые формализована в 1970 году в статье Уинстона Ройса «Managing the Development of Large Software Systems», хотя сам термин «Waterfall» закрепился позднее. Характеризуется строгой фиксацией требований на начальном этапе и линейным движением проекта от анализа к сопровождению.

История

Истоки каскадного подхода лежат в промышленном производстве и строительстве, где последовательность операций является стандартом. В программной инженерии до 1960-х годов доминировал «код-и-фикс» (code-and-fix) — хаотичная разработка без чёткого планирования. Рост сложности проектов потребовал формализации.

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

Широкое распространение Waterfall получил в 1970–1980-х годах благодаря стандартам Министерства обороны США (DoD-STD-2167, 1985 год) и NASA. В СССР аналогичные принципы применялись в рамках ГОСТ 19.xxx (Единая система программной документации, ЕСПД) и ГОСТ 34.xxx (автоматизированные системы). В России каскадная модель до сих пор используется в проектах с жёсткими регламентами, например, в оборонной и космической отраслях.

Этапы модели

Классическая Waterfall-модель включает пять-семь последовательных фаз. Названия и количество этапов могут варьироваться, но суть остаётся неизменной.

1. Анализ требований

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

2. Проектирование

Разрабатывается архитектура системы, определяются модули, интерфейсы, структуры данных. Создаётся проектная документация (например, в России — эскизный и технический проекты по ГОСТ 34.602-89). Этап делится на высокоуровневое (архитектурное) и детальное (логическое) проектирование.

3. Реализация (кодирование)

Программисты пишут код в соответствии с проектной документацией. Обычно этап разбивается на подэтапы по модулям. Интеграция модулей производится после завершения кодирования всех компонентов.

4. Тестирование

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

5. Внедрение (развёртывание)

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

6. Эксплуатация и сопровождение

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

Характеристики

Преимущества

• Предсказуемость. Чёткие сроки и бюджет, если требования стабильны.
• Документированность. Полная техническая документация на каждом этапе облегчает передачу проекта другим командам.
• Простота управления. Линейная структура удобна для менеджеров, привыкших к традиционным методам управления проектами.
• Контроль качества. Каждый этап завершается вехой (milestone) и формальной проверкой.

Недостатки

• Жёсткость. Изменение требований после начала разработки практически невозможно без серьёзных затрат.
• Позднее обнаружение ошибок. Критические дефекты могут быть выявлены только на этапе тестирования, когда исправление требует переработки всей архитектуры.
• Низкая вовлечённость заказчика. Заказчик видит результат только в конце проекта, что часто приводит к несоответствию ожиданиям.
• Риски «большого взрыва». Интеграция всех модулей в конце проекта может выявить несовместимость, требующую полной переделки.

Применение

Waterfall-модель применяется в проектах, где требования могут быть полностью и однозначно определены до начала разработки и не изменятся в процессе. Типичные области:

• Оборонная и космическая промышленность. Проекты с жёсткими государственными стандартами (например, разработка бортового ПО для ракет).
• Медицинские системы. ПО для медицинского оборудования, где требуется сертификация и строгая документация.
• Банковские системы. Крупные проекты с фиксированными регламентами (например, расчётные системы).
• Строительство и инженерия. Программное обеспечение для управления строительными объектами, где этапы проекта совпадают с этапами строительства.

В России Waterfall-модель активно используется в проектах, выполняемых по государственным контрактам, особенно в рамках ГОСТ 34.601-90 (автоматизированные системы). Пример — разработка автоматизированных систем управления технологическими процессами (АСУ ТП) на предприятиях «Росатома» или «Роскосмоса».

Критика

С середины 1990-х годов Waterfall-модель подвергается критике со стороны сторонников гибких методологий (Agile, Scrum, XP). Основные претензии:

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

В ответ на критику были разработаны гибридные модели, например, Water-Scrum-Fall, где этапы анализа и проектирования выполняются каскадно, а реализация — итеративно. Однако в чистом виде Waterfall-модель продолжает применяться в проектах с низкой неопределённостью и высокими требованиями к безопасности.

Интересные факты

• В статье Ройса 1970 года содержалась диаграмма, изображающая этапы с обратными связями (стрелками назад). Позднейшие интерпретации опустили эти стрелки, что привело к жёсткой трактовке модели.
• Термин «Waterfall» впервые употребил Томас Харлан в 1976 году в статье «The Waterfall Model» в журнале «IEEE Computer».
• В СССР и России каскадная модель была закреплена в ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания», который до сих пор действует.
• Согласно опросу Project Management Institute (PMI) за 2020 год, около 20% IT-проектов в мире всё ещё используют Waterfall-модель в чистом виде.

Источники

• Royce, W. W. (1970). «Managing the Development of Large Software Systems». Proceedings of IEEE WESCON.
• Boehm, B. W. (1988). «A Spiral Model of Software Development and Enhancement». IEEE Computer.
• ГОСТ 34.601-90. «Автоматизированные системы. Стадии создания». Госстандарт СССР, 1990.
• PMI. (2020). «Pulse of the Profession 2020: The Future of Project Management».
• McConnell, S. (1996). «Rapid Development: Taming Wild Software Schedules». Microsoft Press.