qalight
Центр подготовки
IT специалистов

База знаний

Каскадная модель (Waterfall model)

waterfall

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

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

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

Плюсы и минусы каскадной модели:

+ Полное документирование каждого этапа;

+ Четкое планирование сроков и затрат;

+ Прозрачность процессов для заказчика;

— Необходимость утверждения полного объема требований к системе еще на первом этапе;

— В случае необходимости внесения изменений требований позднее – возврат к первой стадии и переделка заново всей проделанной работы;

— Увеличение затрат средств и времени в случае необходимости изменения требований.

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

Когда использовать каскадную модель:

– В проектах с четко определенными требованиями, для которых не предусматривается их изменений в процессе разработки;

– Для проектов, которые мигрируют с одной платформы на другую. То есть, требования остаются те же, меняется только системное окружение и/или язык программирования;

– Когда от компании-разработчика не требуется проводить тестирования – к примеру, его обеспечением займется сам заказчик или сторонняя фирма.