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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Позволяет гибкий дизайн и развитие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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