Frequently Asked Questions

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

Каскадная модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.
Ответ:

Каскадный метод

Waterfall_model
Каскадный метод применяется примерно с 70-х годов ХХ века и по сей день распространен достаточно широко. Согласно этому методу вам необходимо совершить определенную последовательность действий в течение жизненного цикла проекта. Обычно проект проходит следующие стадии:

— анализ технических требований;
— дизайн;
— реализация;
— тестирование;
— установка;
— обслуживание.

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

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

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

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