Каскадна модель
| Процес розробки ПЗ |
| Аналіз • Проектування • Програмування • Документування • Тестування |
| Ітеративна • Спіральна • Каскадна • V-Model • Dual Vee Model |
| Agile (XP, Lean, Scrum, FDD та ін.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD • BDD |
| Конфігураційне управління • Управління проектами • Управління вимогами • Забезпечення якості |
Зміст
У 1970 році у своїй статті Ройс описав у вигляді концепції те, що зараз називають «каскадна модель», і обговорював недоліки цієї моделі. Там же він показав, як ця модель може бути доопрацьована до ітеративної моделі.
У вихідній каскадній моделі наступні фази йшли у такому порядку:
- Визначення вимог
- Проектування
- Конструювання (також «реалізація» чи «кодування»)
- Втілення
- Тестування та налагодження (також «верифікація»)
- Інсталяція
- Підтримка
Наслідуючи каскадну модель, розробник переходить від однієї стадії до іншої суворо послідовно. Спочатку повністю завершується етап «визначення вимог», у результаті виходить список вимог до ПЗ. Після того, як вимоги повністю визначені, відбувається перехід до проектування, в ході якого створюються документи, що докладно описують програмістів спосіб і план реалізації зазначених вимог. Після того, як проектування повністю виконане, програмісти виконують реалізацію отриманого проекту. На наступній стадії процесу відбувається інтеграція окремихкомпонентів, що розробляються різними командами програмістів. Після того, як реалізація та інтеграція завершена, проводиться тестування та налагодження продукту; на цій стадії усуваються всі недоліки, що з'явилися на попередніх стадіях розробки. Після цього програмний продукт впроваджується та забезпечується його підтримка – внесення нової функціональності та усунення помилок.
Тим самим, каскадна модель має на увазі, що перехід від однієї фази розробки до іншої відбувається тільки після повного та успішного завершення попередньої фази, і що переходів назад або вперед або перекриття фаз не відбувається.
Тим не менш, існують модифіковані каскадні моделі (включаючи модель самого Ройса), що мають невеликі або навіть значні варіації цього процесу.
Починаючи з PMBOK 4-ї версії вдалося досягти компромісу між методологами, прихильними до формального та поступального управління проектом, з методологами, які роблять ставку на гнучкі ітеративні методи. Таким чином, починаючи з 2009 року, формально Інститутом управління проектами (PMI) пропонується як стандарт гібридний варіант методології управління проектами, що поєднує як плюси від методики «Водопаду», так і досягнення ітеративних методологів.