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

• Название: Программные требования для информационной предметной области системы. Проектирование. Разрабатывается и формулируется логически последовательная техническая характеристика программной системы. Детализация системы
• Дата: 28.03.2022
• Размер: 165.3 Kb.
• Имя файла: Kaskadnaya_model.pptx
• Тип: Программные требования; #422368

Методология Waterfall

Выполнила:

Елпединская Карина

Методология waterfall

Каскадная модель (англ. waterfall model, иногда переводят, как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержка

Автор методологии

Впервые она была изложена американским ученым в области информатики Уинстоном Уокером Ройсом в 1970 году

История возникновения

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

  Самое раннее использование термина «водопад», возможно, было в статье 1976 г. Белл и Тайер.

Этапы разработки ПО:

Анализ требований проекта. Определяются программные требования для информационной предметной области системы.

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

Реализация ПО. Воплощение полноценного проекта.

Тестирование продукта. Тестовая эксплуатация продукта

Интеграция системы. Включает установку и официальную приёмку продукта.

Поддержка. Предоставление технической помощи по продукту после запуска а коммерческую эксплуатацию.

Преимущества методологии

Высокая прозрачность разработки и фаз проекта

Чёткая последовательность

Стабильность требований

Строгий контроль менеджмента проекта

Облегчает работу по составлению плана проекта и сбора команды проекта

Хорошо определяет процедуру по контроля качества

Недостатки методологии

Watrefall проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация

Очень не гибкая методологии

Может создать ошибочное впечатление о работе над проектом (например фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта)

У Заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы

У Пользователя нет возможности привыкать к продукту постепенно

Все требования должны быть известны в начале жизненного цикла проекта

Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выйдет из графиков

Применение

Для средних и больших проектов, где задействованы десятки программистов и несколько разных команд проекта.

Проекты, в которых требования и границы прозрачны и точно известны в начале жизненного цикла проекта.

Заключение

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

СПАСИБО ЗА ВНИМАНИЕ!