Каскадная модель жц по

В 1970 году каскадная модель (рис. 1) была впервые определена как альтернативный вариант метода разработки ПО по принципу кодирование-устранение ошибок, который был широко распространен в то время. Эта модель была регламентирована множеством нормативных документов, в частности широко известным стандартом США DOD-STD-2167A и российскими стандартами ГОСТ 34.

Рис. 1. Классическая каскадная модель ЖЦ ПО

Рис. 2. Реальный процесс разработки ПО (с обратной связью)

Свойства классической каскадной модели ЖЦ:

Фиксация требований к системе до ее сдачи Заказчику.

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

Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии.

Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта.

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

Преимущества каскадной модели:

На каждой стадии формируется законченный набор проектной документации.

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

Использование каскадной модели:

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

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

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

Недостатки каскадной модели:

Позднее обнаружение проблем.

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

Избыточное количество документации.

Невозможность разбить систему на части (весь продукт разрабатывается за один раз).

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

Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:

Пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки.

За время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

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