Что такое водопадный подход к разработке?

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

Определение каскадной модели разработки

Каскадная модель разработки — это методология, которая предполагает последовательное прохождение каждого этапа жизненного цикла разработки программного обеспечения (SDLC: Software Development Life Cycle). Эта модель была впервые представлена ​​в 1970-х годах Уинстоном Ройсом (Winston W. Royce) и с тех пор используется во многих проектах. Каскадная модель включает следующие этапы:

1. Анализ требований (Requirements Analysis): этап сбора и четкого определения требований к проекту.

2. Проектирование (Design): этап разработки архитектуры и детального проектирования программного обеспечения.

3. Реализация (Implementation): этап фактического написания кода и разработки программного обеспечения.

4. Тестирование (Test): этап тестирования разработанного программного обеспечения для выявления и устранения ошибок.

5. Развертывание (Deployment): этап развертывания программного обеспечения в реальной рабочей среде.

6. Техническое обслуживание (Maintenance): этап поддержки и совершенствования развернутого программного обеспечения.

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

Однако, как вода течет сверху вниз, в случае, если разработка уже начата, внесение внезапных изменений в план или изменение разработки не практикуется.

Особенности каскадной модели разработки

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

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

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

1. Четкая структура: этапы четко разделены, что позволяет легко отслеживать ход выполнения проекта.

2. Документирование: тщательное документирование на каждом этапе облегчает отслеживание хода проекта и принятых решений.

3. Простота управления: планирование и управление графиком работ упрощены, а также можно устанавливать четкие цели для каждого этапа.

Недостатки

1. Сложность внесения изменений: требования фиксируются на начальном этапе, поэтому внесение изменений в последующих этапах затруднено и требует больших затрат.

2. Зависимость этапов: переход к следующему этапу возможен только после завершения предыдущего, что повышает вероятность задержек.

3. Недостаточное участие заказчика: после начального этапа участие заказчика ограничено, что может привести к несоответствию конечного результата его ожиданиям.

Это термин, используемый при обсуждении методов разработки, который означает разработку в соответствии с поэтапной процедурой.

❗Дополнительная информация, которая может быть полезна

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

Если бы мы использовали гибкую методологию для разработки сервиса для стороннего заказчика (SI-аутсорсинг), то заказчик должен был бы оплачивать ежемесячно зарплату и административные расходы (аренда офиса, коммунальные платежи и т.д.). Однако на практике проекты чаще всего разрабатываются с фиксированной стоимостью за 2 месяца, 5 месяцев и т.д., а не в формате постоянной ежемесячной оплаты, что делает подобную практику нетипичной.