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

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

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

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

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

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

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

Управление изменениями в «водопадных» проектах

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

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

Узнать больше →

Итеративная модель разработки

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

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

Узнать больше →

Итеративная разработка — это оптимальный выбор:

для больших проектов
для проектов с размытыми требованиями
для инновационных продуктов и стартапов
для проверки бизнес-гипотез
для запуска в сжатые сроки

Cтатьи по теме:

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

06.03.2014 | Статьи — управление продуктами / управление проектами

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

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

07.03.2014 | Статьи — управление продуктами / управление проектами

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