Водопадная модель
Полученные результаты
#1. Водопадная модель получила своё название из-за
1. История модели, кто и когда разработал:
Водопадная модель была предложена в 1970 году американским инженером и ученым Винтоном Беннетом (Winston W. Royce). Это была одна из первых попыток систематизировать процесс разработки программного обеспечения. Модель получила свое название из-за своего линейного и поэтапного характера, когда каждый этап разработки следует за предыдущим, как потоки воды, стекающиеся вниз по водопаду.
2. Этапы водопадной модели:
Водопадная модель состоит из последовательных фаз, каждая из которых должна быть завершена до того, как будет начат следующий этап:
- Планирование — создается общее видение продукта, обсуждаются цели и приоритеты.
- Дизайн и разработка — разрабатотка и планирование функциональности, которая затем тестируется.
- Тестирование — на каждом этапе разрабатываемая функциональность тестируется, и ошибки исправляются.
- Релиз — после завершения каждого этапа > готовый продукт или его часть выпускаются.
- Ревизия и улучшение — на основе отзывов и результатов тестирования продукт постоянно улучшает и адаптируется.
3. Схема водопадной модели:

- English:
Requirements → Design → Implementation → Testing → Deployment → Maintenance - Russian:
Сбор требований → Проектирование → Реализация → Тестирование → Внедрение → Поддержка
4. Плюсы водопадной модели:
- Простота и понятность: Водопадная модель простая для понимания и использования, особенно для небольших проектов.
- Ясное планирование: Каждый этап строго определен, что помогает точно планировать работу и сроки.
- Четкая документация: Требования и результаты каждого этапа документируются, что облегчает контроль и верификацию.
- Предсказуемость: Поскольку каждый этап завершен перед переходом к следующему, легче контролировать проект и избегать изменений.
- Легко управлять: Каждый этап имеет четкие цели и результаты, что упрощает управление проектом и его исполнением.
5. Минусы водопадной модели:
- Отсутствие гибкости: После завершения каждого этапа сложно вернуться и изменить что-то в предыдущем. Это делает модель неподходящей для проектов, где могут быть изменения в требованиях.
- Риск ошибок на ранних стадиях: Ошибки, сделанные на начальных этапах (например, в сборе требований), могут сильно повлиять на весь проект, и их будет трудно исправить.
- Долгое время ожидания: Пользователи и заказчики могут долго ожидать первый рабочий продукт, так как внедрение происходит только в конце всех этапов.
- Невозможность учесть изменения требований: Водопадная модель плохо адаптируется к изменяющимся требованиям или новым условиям.
- Высокие затраты на исправление ошибок: Если на поздних этапах будут найдены ошибки, их исправление может потребовать много времени и ресурсов, что приводит к дополнительным затратам.
Заключение:
Водопадная модель подходит для небольших и стабильных проектов, где требования заранее понятны и не меняются. Для более динамичных проектов, в которых требования могут изменяться, модель может оказаться менее эффективной.
Ссылки на источники информации
https://www.toucantoco.com/en/glossary/waterfall.html



