Модель разработки
ВОДОПАД
Описание
Классическая водопадная модель — это базовая модель жизненного цикла разработки программного обеспечения .
По данной модели жизненный цикл делиться на ряд фаз. Предполагается что одна фаза может начаться после завершения предыдущей фазы. Таким образом, процесс разработки можно рассматривать как последовательное течение в водопаде. Здесь фазы не пересекаются друг с другом.



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

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

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

Этап состоит из двух разделов:
  • Сбор и анализ требований: сначала собираются все требования к ПО заказчика, а затем анализируются собранные требования. Цель аналитической части — устранить неполноту и несоответствия в описании и формулировки требований.
  • Спецификация требований: Составление документа, где описаны все требования. Составление договора и сопроводительной документации.
Проектирование
Целью этого этапа является преобразование требований в "модели" которые можно закодировать на языке программирования. Разработка макетов и архитектурной проектной документации.
кодирование
На этапе кодирования проектные схемы программного обеспечения переводится в исходный код с использованием любого подходящего языка программирования.

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

    • Альфа-тестирование— это тестирование системы, выполняемое командой разработчиков.
    • Бета-тестирование — это тестирование системы, проводимое дружественной группой клиентов.
    • Приемочное тестирование - проводится на системе заказчика.
Эксплуатация
Техническое обслуживание является наиболее важной фазой жизненного цикла программного обеспечения. Усилия, затрачиваемые на обслуживание, составляют 60% от общих усилий, затрачиваемых на разработку полного программного обеспечения. В основном существует три вида технического обслуживания:
  • Корректирующее обслуживание: этот тип обслуживания выполняется для исправления ошибок, которые не были обнаружены на этапе разработки продукта.
  • Безупречное техническое обслуживание: Этот тип технического обслуживания проводится для расширения функциональных возможностей системы на основе запроса клиента.
  • Адаптивное обслуживание. Адаптивное обслуживание обычно требуется для переноса программного обеспечения для работы в новой среде, например, для работы на новой компьютерной платформе или с новой операционной системой.
Преимущества классической модели водопада
Классическая водопадная модель — это идеалистическая модель разработки программного обеспечения. Она очень проста, поэтому ее можно считать основой для других моделей жизненного цикла разработки программного обеспечения. Ниже приведены некоторые из основных преимуществ этой модели:
  • Эта модель очень проста и понятна.
  • Фазы в этой модели обрабатываются по одной.
  • Каждый этап в модели четко определен.
  • Эта модель имеет четкие и понятные вехи.
  • Процесс, действия и результаты хорошо документированы.
  • Эта модель хорошо работает для небольших проектов и проектов, где требования хорошо понятны.
Недостатки классической модели водопада
Классическая модель водопада имеет ряд недостатков при ее применении в реальных проектах. Ниже приведены основные недостатки этой модели:

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