История создания классической каскадной модели
- Анализ требований к программному обеспечению
- Эскизный проект
- Рабочий проект
- Кодирование и модульное тестирование
- Интеграция
- тестирование.
Классическая модель водопада — это базовая модель жизненного цикла разработки программного обеспечения. Это модель проста и идеалистична, подобная модель на сегодняшний день практически не используется, но она стала основой для всех других моделей.
Классическая модель водопада делит жизненный цикл на набор фаз или этапов. Модель предполагает, что каждый этап следует один за другим. То есть завершения первого этапа, означает начало второго этапа. Этапы не пересекаются друг с другом.

Расскажем о каждом этапе Classical Waterfall Model —
- Технико-экономическое обоснование: на этом этапе выясняется возможно ли финансово и технически .осуществить разработку программного обеспечения. Осуществляется изучение и понимание проблемы, а затем определение различных возможных стратегий решения проблемы. Выбирается лучшее решение, и все остальные этапы выполняются в соответствии с этой стратегией решения.
- Анализ и спецификация требований : необходимо на этом этапе понять точные требования заказчика и должным образом их задокументировать. Этот этап состоит из двух разных мероприятий.
- Сбор и анализ требований: сначала все требования к программному обеспечению собираются от клиента, а затем собранные требования анализируются. Целью является, во-первых устранение неполноты (неполное требование — это требование, в котором некоторые части фактических требований были опущены) и второе, устранение несоответствий (несогласованное требование — это требование, в котором некоторая часть требования противоречит другой части).
- Спецификация требований: проанализированные требования задокументированы в документе спецификации требований к программному обеспечению (SRS). Документ SRS служит контрактом между командой разработчиков и клиентами.
- Дизайн /архитектура/: цель этапа проектирования — преобразовать требования, указанные в документе SRS, в структуру, подходящую для реализации на каком-либо языке программирования.
- Кодирование и модульное тестирование : на этапе кодирования дизайн программного обеспечения воплощается в исходный код с использованием любого подходящего языка программирования. Кодируется каждый разработанный модуль. Цель этапа модульного тестирования — проверить, правильно ли работает каждый модуль.
- Интеграция и тестирование системы : интеграция различных модулей осуществляется после того, как они были закодированы и прошли модульное тестирование. Интеграция различных модулей выполняется постепенно, в несколько этапов. На каждом этапе интеграции к частично интегрированной системе добавляются ранее запланированные модули, и полученная система тестируется. После того, как все модули были успешно интегрированы и протестированы, получается полная рабочая система, и на ней проводится системное тестирование. Системное тестирование состоит из трех различных видов тестирования:
- Альфа-тестирование: — это тестирование системы, выполняемое командой разработчиков.
- Бета-тестирование: — это тестирование системы, проводимое дружелюбной группой клиентов.
- Приемочное тестирование: после того, как программное обеспечение было поставлено, заказчик провел приемочное тестирование, чтобы определить, принять поставленное программное обеспечение или отклонить его.
- Сопровождение: один из самых важных этапов жизненного цикла программного обеспечения. Усилия, затрачиваемые на сопровождение, составляют 60% от общих усилий, затрачиваемых на разработку полного программного обеспечения. Существует три основных типа обслуживания:
- Корректирующее обслуживание: этот тип обслуживания выполняется для исправления ошибок, которые не были обнаружены на этапе разработки продукта.
- Безупречное обслуживание: этот тип обслуживания выполняется для расширения функциональных возможностей системы по запросу клиента.
- Адаптивное обслуживание: Адаптивное обслуживание обычно требуется для переноса программного обеспечения для работы в новой среде, например, для работы на новой компьютерной платформе или с новой операционной системой.
Преимущества классической каскадной модели
Классическая модель водопада — это идеалистическая модель для разработки программного обеспечения.
- Модель очень проста и понятна.
- Фазы в этой модели обрабатываются по очереди.
- Каждый этап модели четко определен.
- У этой модели очень четкие и хорошо понятные этапы.
- Процесс, действия и результаты очень хорошо документированы.
- Определение до архитектуры, архитектура до кода.
- Модель хорошо подходит для небольших проектов и проектов, где требования хорошо
понятны.
Недостатки классической модели водопада
Классическая модель водопада страдает различными недостатками, в основном мы не можем использовать ее в реальных проектах.
- Нет обратной связи: в классической модели водопада эволюция программного обеспечения от одной фазы к другой фазе похожа на водопад. Предполагается, что разработчики не совершают ошибок ни на одном этапе. Таким образом, он не содержит механизма исправления ошибок и модификации проекта в процессе работы, что в современном мире разработки программного обеспечения крайне не верно, об этом говорит книга Тома ДеМарко, Тимоти Листера “Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения”. Авторы книги говорят о том, что изначальный проект на момент начало разработки и проект который должен быть получен при завершении разработки, может значительно отличаться в связи с динамичностью внешней среды. И поэтому, на всех этапах должна присутствовать обратная связь между разработчиком и заказчикам, чтобы избежать риска выпустить проект утративший необходимость.
- Трудно удовлетворить запросы на изменение: эта модель предполагает, что все требования клиентов могут быть полностью и правильно определены в начале проекта, но на самом деле требования клиентов со временем меняются. После завершения этапа спецификации требований трудно удовлетворить любые запросы на изменение. Что также крайне рискованно с точки зрения разработки, возможность оперативный доработки программного обеспечения, залог успеха проекта, о чем говорится в книги Тома ДеМарко, Тимоти Листера “Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения”
- Отсутствие перекрытия фаз: эта модель рекомендует, чтобы новая фаза могла начаться только после завершения предыдущей. Но в реальных проектах этого поддерживать нельзя. Для повышения эффективности и снижения стоимости фазы могут перекрываться.
На основе классической модели водопада, сложилась более применимая в разработке Итеративная модель \Iterative Waterfall Model\, описанаЯ в статье У. У. Ройса в 1970 году.
Традиционный водопадный подход не всегда работает для проектов с изменяющимися бизнес-требованиями или проектов, в которых задачи не могут быть ограничены одной неизменной фазой.
Поскольку традиционный водопад основан на раннем планировании, он хорошо работает, когда большая часть информации о проекте известна заранее и вряд ли существенно изменится во время выполнения.
В написании статьи использовался материал различных сайтов, однако основной источник — Geeksforgeeks.org