«WATERFALL MODEL» (каскадная модель или «водопад»)

Водопадная модель разработки

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

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

[googleapps domain=»docs» dir=»forms/d/e/1FAIpQLSc8M7PUeesa3Z4c5sHUuiccIEY3VazM3v9DLDziDBk8KQU93w/viewform» query=»embedded=true» width=»640″ height=»494″ /]

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

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

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

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

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

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

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

Плюсы модели:

  •  Устойчива к обновлению кадров. Благодаря очень подробному документированию каждого этапа, участники могут приходить и уходить, но на сроки работы это никак не повлияет.
  •  Дисциплинирует, благодаря плану и чёткой последовательности этапов и строгому менеджменту.
  •  Гибкая на ранних этапах. До этапа разработки можно вполне легко вносить изменения в предыдущие этапы.
  •  Прозрачна. Заранее понятно, на каком этапе что будет происходить, поэтому становится проще прогнозировать бюджеты и набирать команду.
  • Заказчик знает, что будет выполняться на каждом этапе

Минусы модели:

  • Невозможно внести изменение в проект на каком-либо этапе системы
  • Непригодность промежуточного продукта для использования
  • Позднее обнаружение проблем, связанных со сборкой, в связи с одновременной интеграцией всех результатов в конце разработки
  • Увелечение затрат и времени, если необходимо изменить начальные требования проекта
  • Тестирование системы должна проводить сторонняя фирма

Сравнение 2-ух моделей: