Водопадная модель разработки

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

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

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

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

Альтернатива «водопаду» — итеративная модель разработки (различные «гибкие» методологии, например).

управление проектамиуправление продуктами
Статья опубликована в 2019 году

Тематические статьи

Agile — гибкие методологии разработки

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

Статья опубликована в 2023 году
CustDev

CustDev (Customer Development) — это процесс, который помогает предприятиям разрабатывать продукты и услуги, отвечающие потребностям их клиентов.

Статья опубликована в 2023 году
Итеративная модель разработки

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

Статья обновлена в 2025 году
Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования

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

Статья опубликована в 2014 году
Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению

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

Статья опубликована в 2014 году
​Создание сайта быстро, дешево, индивидуально и качественно

Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку». Невозможно сделать разработку сайта одновременно и быстрой, и дешевой, и индивидуальной, и качественной.

Статья обновлена в 2020 году
Как зависит качество разработки от финансирования, сроков и менеджмента проекта?

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

Статья обновлена в 2022 году
Процессы веб‑разработки, которые не очень заметны, но существенно влияют на качество полученного результата

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

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

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

Статья опубликована в 2014 году