SDLC - модель водопада

Модель Waterfall - это классическая модель SDLC, которая широко известна, понятна и широко используется. Он был представлен Royce в 1970 году и до сих пор используется в качестве общего подхода к разработке программного обеспечения в различных организациях отрасли.

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

Водопад Жизненный цикл

Модель водопада - Сильные стороны

Сильные стороны модели Waterfall:

  • Легко понять, легко использовать.
  • Обеспечивает структуру для неопытной команды разработчиков.
  • Вехи хорошо поняты.
  • Устанавливает требования стабильности.
  • Идеально подходит для управленческого контроля (планирование, мониторинг, отчетность).
  • Хорошо работает, когда качество важнее, чем стоимость или график.

Модель водопада - Слабые стороны

Слабые стороны или недостатки модели Waterfall:

  • Идеализированный - он не соответствует действительности.

  • Нереально - нельзя ожидать точных требований в начале проекта.

  • Не отражает итеративный характер поискового развития, который является более распространенным.

  • Сложно и дорого вносить изменения.

  • Программное обеспечение поставляется только в конце проекта. Благодаря этому -

    • Задержки обнаружения серьезных дефектов.

    • Возможность доставки устаревших требований.

  • Значительные накладные расходы на управление, которые могут быть дорогостоящими для небольших команд и проектов.

  • Требуются опытные ресурсы на каждом этапе - аналитики, дизайнеры, разработчики, тестировщики.

  • Тестирование начинается только после завершения разработки, и тестеры не участвуют ни в одном из более ранних этапов.

  • Экспертиза межфункциональных команд не разделяется, так как каждая фаза выполняется в бункерах.

Когда использовать модель водопада?

Вы можете использовать модель Водопад, если -

  • Требования очень хорошо известны.

  • Определение продукта является стабильным.

  • Технология хорошо понятна.

  • Новая версия существующего продукта.

  • Портирование существующего продукта на новую платформу.

  • Большая организация со структурированными межфункциональными командами.

  • Каналы связи хорошо налажены как внутри организации, так и с заказчиком.

Модель эволюционного прототипирования

При разработке программного обеспечения с использованием модели Evolutionary Prototyping разработчики создают прототип на этапе требований. Затем конечные пользователи оценивают прототип и дают обратную связь. В качестве обратной связи могут выступать исправления к прототипу или дополнительные функции. Основываясь на отзывах, разработчики доработали прототип.

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

Поставка конечного продукта

Модель эволюционного прототипирования - сильные стороны

Сильные стороны или преимущества модели эволюционного прототипирования:

  • Клиенты / конечные пользователи могут визуализировать системные требования, когда они собираются, глядя на прототип.

  • Разработчики учатся у клиентов и, следовательно, нет двусмысленности в отношении домена или производственной среды.

  • Позволяет гибкое проектирование и разработку.

  • Взаимодействие с прототипом стимулирует осознание дополнительно необходимой функциональности.

  • Неожиданные требования и изменения требований легко приспосабливаются.

  • Устойчивые и видимые признаки прогресса производятся.

  • Доставка точного и ремонтопригодного конечного продукта.

Модель эволюционного прототипирования - Слабые стороны

Слабые стороны или недостатки модели эволюционного прототипирования заключаются в следующем:

  • Тенденция отказаться от структурированной разработки при разработке кода и исправления, хотя это не то, что предписано моделью.

  • Эта модель получила плохую репутацию за быстрые и грязные методы.

  • Общая ремонтопригодность может быть упущена.

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

  • Проект может продолжаться вечно (с непрерывной ползучестью), и руководство может не оценить его.

Когда использовать модель эволюционного прототипирования?

Вы можете использовать модель Evolutionary Prototyping -

  • Когда требования нестабильны или должны быть уточнены
  • Как этап уточнения требований модели водопада
  • Разработать пользовательские интерфейсы
  • Для недолговечных демонстраций
  • Для новой или оригинальной разработки
  • Для внедрения новой технологии