Erik Gerega õpimapp

1. История модели (mudeli ajalugu)

Водопадная модель была предложена Уинстоном Ройсом в 1970 году. Это одна из первых формальных моделей жизненного цикла ПО, основанная на последовательном прохождении этапов разработки.

Спиральная модель была разработана Барри Боэмом в 1986 году. Она ориентирована на управление рисками и итеративный подход к разработке программного обеспечения.

2. Этапы (etapid)

Водопадная модель:

1. Сбор и анализ требований
2. Проектирование системы
3. Реализация (кодирование)
4. Тестирование
5. Внедрение
6. Сопровождение

Спиральная модель:

1. Определение целей итерации
2. Анализ и сокращение рисков
3. Разработка и проверка достоверности (создание прототипа)
4. Планирование следующей итерации

Схема (skeem)

Водопадная модель:

Спиральная модель:

4. Плюсы

Водопадная модель:

1. Простота и понятная структура этапов
2. Хорошая документация
3. Подходит для проектов с чёткими и неизменными требованиями
4. Эффективна при краткосрочной разработке
5. Удобна для управления и контроля

Спиральная модель:

1. Позволяет управлять рисками
2. Гибкость при изменении требований
3. Подходит для больших и сложных проектов
4. Активное участие заказчика
5. Позволяет выявить ошибки на ранних этапах

5. Минусы

Водопадная модель:

1. Отсутствие обратной связи на ранних этапах
2. Трудности при изменении требований
3. Позднее обнаружение ошибок
4. Не подходит для длительных или гибких проектов
5. Низкий уровень взаимодействия с пользователем

Спиральная модель:

1. Сложность в управлении процессом
2. Требует значительных ресурсов и времени
3. Необходимы специалисты по управлению рисками
4. Неэффективна для маленьких проектов
5. Стоимость разработки может быть высокой

	Водопадная модель	Спиральная модель
Год появления	1970	1986
Количество основных этапов	6 этапов	4 фазы на каждом витке (итерации)
Суть модели	Последовательное прохождение всех этапов без возврата назад	Итеративная разработка с акцентом на анализ и снижение рисков
Сложность в использовании	Низкая – легко понять и реализовать	Высокая – требует опыта и грамотного управления
Затраты	Относительно низкие при стабильных требованиях	Высокие из-за итераций и анализа рисков
Контроль рисков	Практически отсутствует	Основной элемент модели – контроль и управление рисками
Учёт изменений	Плохо поддерживается	Хорошо реализован на каждом витке
Применение	Малые и средние проекты с чёткими требованиями	Крупные и сложные проекты с высоким уровнем неопределённости
Плюсы	Простота, чёткость, предсказуемость, хорошая документация, контроль	Управление рисками, гибкость, участие заказчика, раннее тестирование, адаптивность
Минусы	Плохая гибкость, позднее выявление ошибок, нет обратной связи, не подходит для гибких проектов, слабое взаимодействие с пользователем	Высокие затраты, сложность реализации, требуется опыт, неэффективна для малых проектов, длительное планирование