Водопадная модель разработки
Водопадная или каскадная модель разработки программного обеспечения (waterfall, водопад) — это процесс разработки, в котором последовательно проходят фазы сбора и анализа требований, проектирования и прототипирования, реализации, тестирования, интеграции и поддержки.
Следуя водопадной модели, разработчики строго последовательно переходят от одного процесса к другому. Сначала полностью завершается этап сбора требований — составлется список выявленных требований к ПО. Только после того как требования собраны и зафиксированы, происходит переход к процессу проектирования, в ходе которого формируется техническое задание на разработку, содержащее описание задач, стоящих перед разработчиками, а также способов их реализации и имеющихся ограничений. После того как проектирование полностью завершено, разработчиками выполняется реализация проекта согласно техническому заданию — если на примере разработки сайта, то рисуется дизайн, осуществляется верстка и программирование. После того как фаза разработки завершена, производится тестирование и отладка разработанного продукта: на этой стадии выявляются и устраняются все недочёты согласно техническому заданию. После этого осуществляется запуск проекта и обеспечивается его поддержка — обеспечение работоспособности и устранение ошибок.
Водопадная модель подразумевает, что переход от одной фазы создания продукта к другой происходит только после полного завершения предыдущей фазы и что переходов назад и перекрытия фаз не происходит.
Разработка ПО в рамках этой модели позволяет строго зафиксировать бюджет и сроки. Однако, работа по этой модели может быть эффективна только в том случае, если Заказчик весьма детально понимает цели и задачи разрабатываемого продукта, а также способен их сформулировать. Это обусловлено тем, что объём работы тоже фиксируется — если что-то не попало в ТЗ, то это скорее всего не будет реализовано в рамках согласованного бюджета и сроков. Внесение изменений в водопадные проекты тоже достаточно проблематично. Таким образом для реально больших проектов и для разработки чего-либо инновационного такая модель не подходит.
Альтернатива «водопаду» — итеративная модель разработки (различные «гибкие» методологии, например).
Разработка ПО на основе водопадной модели эффективна при полном и детальном понимании целей и задач проекта. Благодаря работе по строгой спецификации, эта модель позволяет строго зафиксировать бюджет и сроки проекта.
По ходу реализации проектов очень часто что-то меняется: либо проясняется исходное видение и неявные требования вдруг становятся явными, либо же изменения связаны с переосмыслением изначальных требований. Итеративная модель в таких проектах оказывается более эффективной, но попробуем разобраться, что делать с изменениями в водопадном проекте.
В рамках новых задач возникает необходимость возвращаться к уже выполненным ранее этапам, а также пересматривать грядущие этапы на предмет их соответствия новым задачам. Если же не работать с изменениями, то проект скорее всего скатится в неуправляемое состояние и изменения либо не будут вносится, либо их внесение будет хаотичным и будут возникать конфликты в функционале. Поэтому изменения в уже запущенном проекте требуют проработки и построения некого бизнес-процесса.
Итеративная (итерационная, инкрементная или эволюционная) модель разработки программного обеспечения — это процесс, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы.
Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций. Каждая из этих итерации, по сути, является водопадным проектом в миниатюре, то есть включает в себя все ключевые процессы разработки ПО и результатом работы по каждой итерации обычно является пригодная для использования версия продукта.
Итеративная разработка — это оптимальный выбор:
- для больших проектов
- для проектов с размытыми требованиями
- для инновационных продуктов и стартапов
- для проверки бизнес-гипотез
- для запуска в сжатые сроки
Cтатьи по теме:
Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования
Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению
Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска
Как написать функциональное техническое задание?
Итеративная модель разработки
Создание дизайна сайта или веб-приложения
Использование экономических критериев в веб-разработке для оценки целесообразности реализации
Тематические технологии:
