Modelul cascadă MM 40

Metoda își are originea inițial în procesul de construcție și producție. Deoarece se utilizau resurse costisitoare și o eroare ireparabilă putea face un întreg obiect inutilizabil, era important să se planifice cu atenție când și ce procesare ulterioară urma să aibă loc. Această metodă exista deja și a fost descrisă mai detaliat de Herbert D. Bedington în 1956, într-o prelegere despre experiența sa în dezvoltarea de software. Winston W. Royce a descris oficial modelul pentru prima dată în 1970 în lucrarea sa „Managing the Development of Large Software Systems”.

Modelul Waterfall este liniar și nu agil. Aceasta înseamnă că, spre deosebire de Scrum (M39), de exemplu, nu există un model general în spatele muncii echipei de dezvoltare, care este repetitivă, iar abaterile sunt strict evitate. Aici, munca este determinată individual pentru fiecare proiect, dar sunt întotdeauna definite etape care ar trebui urmate ori de câte ori este posibil. Un exemplu simplificat ar fi crearea unui site web:

1. Planificare:

Discutăm cu clientul despre modul în care informațiile și serviciile ar trebui să fie accesibile pe site-ul său web. Aceștia pot avea o idee generală despre prezența lor online și cerințele de design.

2. Prototip:

Acum este elaborată o schiță care îi arată clientului cum ar putea arăta site-ul său web la sfârșitul proiectului. Dacă sunt necesare modificări, aceasta este ultima ocazie de a discuta prototipul. În caz contrar, acest pas este finalizat.

3. Implementare:

Tot ce a fost promis în draft este acum implementat prin scriptarea site-ului web.

4. Verificare:

Funcționalitatea site-ului web este testată în diverse browsere, sisteme și dispozitive. Dacă se constată nereguli, codul trebuie ajustat. Cu toate acestea, designul rămâne neschimbat.

5. Întreținere:

Site-ul web trebuie să fie mereu actualizat cu cele mai recente tehnologii. În plus, este posibil să existe completări regulate ale site-ului web, care trebuie făcute acum în mod continuu.

Aceasta ar fi o posibilă formă de model cascadă. Cheia este că anumite faze trebuie finalizate în intervale de timp strict definite, astfel încât clientul să se poată baza pe un rezultat. De obicei, orice modificare a unei faze finalizate este tratată ca o comandă nouă.

În contextul:

Î: Î01, Î08, Î15,

E:

T: T05, T07, T14