Classical Waterfall Model модель и архитектура разработки программного обеспечения

Classical Waterfall Model модель и архитектура разработки программного обеспечения

Классическая модель разработки программного обеспечения ставшей основой для всех других моделей является — классическая каскадная модель разработки программного обеспечения /Классическая модель водопада Classical Waterfall Model/.
Почему модель водопада Waterfall Model? — это модель разработки является линейной, которая состоит из жестких фаз /этапов, циклов/: когда заканчивается одна фаза, начинается следующая. Шаги выполняются последовательно, модель не позволяет разработчикам вернуться к предыдущим шагам (отсюда и «водопад»: когда вода падает, она не может вернуться вверх).

История создания классической каскадной модели

Первая известная презентация классической каскадной модели, описывающая использование таких этапов в разработке программного обеспечения, была проведена Гербертом Д. Бенингтоном на симпозиуме по передовым методам программирования для цифровых компьютеров 29 июня 1956 г.  Эта презентация была посвящена разработке программного обеспечения для SAGE.
В последствии, более адаптированную модель разработки программного обеспечению была описана в статье У. У. Ройса в 1970 году, которую он назвал — итеративную модель \Iterative Waterfall Model\.
Самым ранним использованием термина «водопад», предполагается, статья Белла и Тайера 1976 года [ Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem?].
В 1985 году Министерство обороны США зафиксировало этот подход в DOD-STD-2167A, в своих стандартах работы с подрядчиками по разработке программного обеспечения, в которых говорилось, что «подрядчик должен реализовать цикл разработки программного обеспечения, который включает следующие шесть этапов:
  1. Анализ требований к программному обеспечению
  2. Эскизный проект
  3. Рабочий проект
  4. Кодирование и модульное тестирование
  5. Интеграция
  6. тестирование.
В 1983 году Бенингтона, переиздает свою статью, в котором пояснялось, что этапы были специально организованы в соответствии со специализацией задач, и указывается, что процесс на самом деле не выполнялся строго сверху вниз, а зависел от прототипа.

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

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

Classical Waterfall Model модель и архитектура разработки программного обеспечения
Classical Waterfall Model модель и архитектура разработки программного обеспечения

Расскажем о каждом этапе Classical Waterfall Model —

  1. Технико-экономическое обоснование:  на этом этапе выясняется возможно ли финансово и технически .осуществить разработку программного обеспечения. Осуществляется изучение и понимание проблемы, а затем определение различных возможных стратегий решения проблемы. Выбирается лучшее решение, и все остальные этапы выполняются в соответствии с этой стратегией решения.
  2. Анализ и спецификация требований : необходимо на этом этапе понять точные требования заказчика и должным образом их задокументировать. Этот этап состоит из двух разных мероприятий.
    • Сбор и анализ требований: сначала все требования к программному обеспечению собираются от клиента, а затем собранные требования анализируются. Целью является, во-первых устранение неполноты (неполное требование — это требование, в котором некоторые части фактических требований были опущены) и второе, устранение несоответствий (несогласованное требование — это требование, в котором некоторая часть требования противоречит другой части).
    • Спецификация требований: проанализированные требования задокументированы в документе спецификации требований к программному обеспечению (SRS). Документ SRS служит контрактом между командой разработчиков и клиентами.
  3. Дизайн /архитектура/: цель этапа проектирования — преобразовать требования, указанные в документе SRS, в структуру, подходящую для реализации на каком-либо языке программирования.
  4. Кодирование и модульное тестирование : на этапе кодирования дизайн программного обеспечения воплощается в исходный код с использованием любого подходящего языка программирования. Кодируется каждый разработанный модуль. Цель этапа модульного тестирования — проверить, правильно ли работает каждый модуль.
  5. Интеграция и тестирование системы : интеграция различных модулей осуществляется после того, как они были закодированы и прошли модульное тестирование. Интеграция различных модулей выполняется постепенно, в несколько этапов. На каждом этапе интеграции к частично интегрированной системе добавляются ранее запланированные модули, и полученная система тестируется. После того, как все модули были успешно интегрированы и протестированы, получается полная рабочая система, и на ней проводится системное тестирование. Системное тестирование состоит из трех различных видов тестирования:
    • Альфа-тестирование: — это тестирование системы, выполняемое командой разработчиков.
    • Бета-тестирование: — это тестирование системы, проводимое дружелюбной группой клиентов.
    • Приемочное тестирование: после того, как программное обеспечение было поставлено, заказчик провел приемочное тестирование, чтобы определить, принять поставленное программное обеспечение или отклонить его.
  6. Сопровождение: один из самых важных этапов  жизненного цикла программного обеспечения. Усилия, затрачиваемые на сопровождение, составляют 60% от общих усилий, затрачиваемых на разработку полного программного обеспечения. Существует три основных типа обслуживания:
    • Корректирующее обслуживание: этот тип обслуживания выполняется для исправления ошибок, которые не были обнаружены на этапе разработки продукта.
    • Безупречное обслуживание: этот тип обслуживания выполняется для расширения функциональных возможностей системы по запросу клиента.
    • Адаптивное обслуживание: Адаптивное обслуживание обычно требуется для переноса программного обеспечения для работы в новой среде, например, для работы на новой компьютерной платформе или с новой операционной системой.

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

Классическая модель водопада — это идеалистическая модель для разработки программного обеспечения.

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

Недостатки классической модели водопада

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

  • Нет обратной связи: в классической модели водопада эволюция программного обеспечения от одной фазы к другой фазе похожа на водопад. Предполагается, что разработчики не совершают ошибок ни на одном этапе. Таким образом, он не содержит механизма исправления ошибок и модификации проекта в процессе работы, что в современном мире разработки программного обеспечения крайне не верно, об этом говорит книга Тома ДеМарко, Тимоти ЛистераВальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения”. Авторы книги говорят о том, что изначальный проект на момент начало разработки и проект который должен быть получен при завершении разработки, может значительно отличаться в связи с динамичностью внешней среды. И поэтому, на всех этапах должна присутствовать обратная связь между разработчиком и заказчикам, чтобы избежать риска выпустить проект утративший необходимость.
  • Трудно удовлетворить запросы на изменение: эта модель предполагает, что все требования клиентов могут быть полностью и правильно определены в начале проекта, но на самом деле требования клиентов со временем меняются. После завершения этапа спецификации требований трудно удовлетворить любые запросы на изменение. Что также крайне рискованно с точки зрения разработки, возможность оперативный доработки программного обеспечения, залог успеха проекта, о чем говорится в  книги  Тома ДеМарко, Тимоти ЛистераВальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения
  • Отсутствие перекрытия фаз: эта модель рекомендует, чтобы новая фаза могла начаться только после завершения предыдущей. Но в реальных проектах этого поддерживать нельзя. Для повышения эффективности и снижения стоимости фазы могут перекрываться.

На основе классической модели водопада, сложилась более применимая в разработке Итеративная модель \Iterative Waterfall Model\, описанаЯ в статье У. У. Ройса в 1970 году.

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

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

В написании статьи использовался материал различных сайтов, однако основной источник — Geeksforgeeks.org