1.2.2.1. Водопадная (каскадная) модель

Водопадная (каскадная) модель (или классическая модель) является первой описанной моделью жизненного цикла программной системы, которая проистекала из обычных процессов производства, имевших место в строительстве и механике и пр. Модель описал Уинстон В. Ройс (Winston W. Royce) в 1970 году. Водопадная модель – наиболее старая и наиболее подвергнувшаяся критике модель процессов.

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

1. Определение требований. Этот этап можно разделить на две категории – системный анализ (все то, что окружает конкретное программное обеспечение), и анализ требований. Документируют поведение системы, производительность, интерфейс и т.д.

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

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

4. Интеграция и тестирование системы. Объединяют программы и модули, тестируют всю систему, после тестирования продукт передается заказчику. Во время тестирования сосредотачиваются как на логических деталях, так и на том, отвечает ли система требованиям в отношении функциональности (проверка достоверности).

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

Результатом каждой фазы является один или несколько документов, которые утверждаются. Следующая фаза не должна начинаться до того, пока предыдущая не завершена. У фаз имеются определенные совпадения, и информация передается от одной фазы к другой. См. также рисунок 1-1.

Рисунок 1-1. Водопадная модель

Комментарий к рисунку 1-1 – логика водопадной (каскадной) модели часто изображается таким образом, что стрелки направлены только сверху вниз (от предыдущей фазы к следующей). К предыдущим шагам не возвратиться, так же, как и в жилищном строительстве жилого дома нельзя вернуться к фундаменту после установки крыши. В этом случае по модели было бы невозможно вообще ничего позже изменить в системе. Ройс тоже признал этот вариант в своей статье невозможным. Фактически Ройс добавил уже вначале для каждого этапа изображающую обратную связь стрелку. Тем не менее, возвращение из каждого этапа на предыдущий – невозможно. Если во время тестирования была обнаружена ошибка, чьи корни лежат в архитектуре, то согласно модели можно вернуться к изменениям в архитектуре только тогда, когда программное обеспечение уже используется (см. направления стрелок на рисунке).

Заключение:

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