Modelul cascadă ( modelul cascadă în engleză , tradus uneori ca modelul „cascada” ) este un model de proces de dezvoltare software în care procesul de dezvoltare arată ca un flux care trece secvenţial prin fazele de analiză a cerinţelor, proiectare, implementare, testare, integrare şi suport. . Un articol publicat de W. W. Royce în 1970 este adesea citat ca sursă a numelui ; în ciuda faptului că Royce însuși a folosit un model de dezvoltare iterativ .
Într-o lucrare din 1970, Royce a descris în concept ceea ce se numește acum „modelul în cascadă” și a discutat despre deficiențele acestui model. În același loc, el a arătat cum acest model poate fi rafinat la un model iterativ.
În modelul original de cascadă, următoarele faze au mers în această ordine:
Urmând modelul cascadei, dezvoltatorul trece de la o etapă la alta strict secvenţial. În primul rând, etapa de „definire a cerințelor” este complet finalizată, rezultând o listă de cerințe software. După ce cerințele sunt complet definite, are loc o tranziție la proiectare, în timpul căreia sunt create documente care descriu în detaliu pentru programatori metoda și planul de implementare a acestor cerințe. După ce proiectarea este complet finalizată, programatorii implementează proiectul rezultat. Următoarea etapă a procesului este integrarea componentelor individuale dezvoltate de diferite echipe de programatori. După finalizarea implementării și integrării, produsul este testat și depanat; în această etapă sunt eliminate toate neajunsurile apărute la etapele anterioare de dezvoltare. După aceea, produsul software este implementat și este oferit suportul acestuia - introducerea de noi funcționalități și eliminarea erorilor.
Astfel, modelul în cascadă presupune că trecerea de la o fază de dezvoltare la alta are loc numai după finalizarea completă și cu succes a fazei anterioare și că nu există tranziții înapoi sau înainte sau suprapunere de fază.
Cu toate acestea, există modele în cascadă modificate (inclusiv al lui Royce) care au variații mici sau chiar semnificative ale procesului descris.
Metodologia Waterfall Model este adesea criticată pentru lipsa de flexibilitate și pentru declararea managementului formal de proiect ca un scop în sine în detrimentul timpului, costurilor și calității. Cu toate acestea, atunci când gestionați proiecte mari, formalizarea a fost adesea de mare valoare, deoarece ar putea reduce dramatic multe dintre riscurile proiectului și să-l facă mai transparent . Prin urmare, chiar și în versiunea a treia a PMBOK , doar metodologia „modelului în cascadă” a fost fixată în mod formal și nu au fost propuse opțiuni alternative cunoscute sub numele de management iterativ de proiect .
Începând cu cea de-a 4-a versiune a PMBOK , s-a ajuns la un compromis între metodologii dedicați managementului formal și progresiv al proiectelor, metodologii bazându-se pe metode iterative flexibile . Astfel, începând din 2009, în mod formal, Institutul de Management de Proiect (PMI) oferă ca standard o versiune hibridă a metodologiei de management de proiect, combinând atât avantajele metodologiei Waterfall, cât și realizările metodologilor iterativi.
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|