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

1. Сбор требований. Собираются требования к продукту, который надо разработать (определяем требования заказчика).

2. Анализ требований. Требования анализируются, детализируются, уточняются, обсуждаются, документируются (формируем требования к ПО).

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

4. Разработка. Реализация.

5. Тестирование. Проверка.

6. Внедрение, поддержка. Вывод в промышленную эксплуатацию и перевод на поддержку.

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

• для средних и больших проектов, в которых задействованы десятки программистов и несколько разных команд проекта;

• для проектов, в которых требования и границы прозрачны и точно известны в начале жизненного цикла проекта. То есть когда проект понятен и прост.

«Водопад» подходит для разработки проектов в медицинской и космической отраслях, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.

Любая стройка – это пример использования «Водопада» (кейс – проект – стройка – приемка). Также в качестве примера подходит автомобильный конвейер.

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

Поэтому появились расширения модели: каскадная с обратной связью и каскадная с промежуточным контролем.

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

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

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

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

Модель обладает следующими характеристиками взаимодействия этапов:

• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);

• каждый этап имеет обратную связь с предыдущими;

• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;

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

• результат появляется только в конце разработки, как и в модели «Водопад».

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