Introducere în modelul cascadei
Originară din industria construcțiilor și a producției, este un mediu fizic foarte structurat, destinat proceselor de proiectare și dezvoltare. Modelul cascadei este cunoscut și sub denumirea de model de ciclu de viață al dezvoltării software. A fost primul model de proces introdus ca model liniar-secvențial al ciclului de viață. Modelul cascadei spune pur și simplu fenomenul ca să finalizeze complet faza înainte de a începe noua fază de dezvoltare, astfel încât să nu se suprapună faze. În domeniul dezvoltării software, modelul cascadă a fost folosit pentru prima dată ca abordare SDLC. Pentru a lucra la modelul de cascadă trebuie să înțelegem abordarea aplicării sale bazată atât pe factori interni cât și externi, care pot fi următoarele:
- Nu există cerințe ambigue în cerere.
- Stabilitatea definirii produsului
- Este tehnologie înțeleasă
- Nu este dinamic
- Pentru a sprijini produsul sunt disponibile resurse mari cu experiență adecvată
- Proiect Vey de scurta durata
- Document bun, cerințe clare și fixe.
Pentru a începe cu istoricul modelului cascadei, aș dori să spun că primul eșantion al modelului cascadei a fost introdus în anul 1970 de Winston w Royce într-un articol. De atunci, modelul cascadei afirmă că trebuie să treacă la o altă fază numai atunci când fazele anterioare sunt complet testate, revizuite și verificate. Se pune accent pe progresia logică a etapelor de fază. Funcționalitatea sa este similară cu curgerea apei peste marginea stâncii. Această abordare a dezvoltării de software a primit numele cascadă, deoarece se dezvoltă sistematic de la o fază la alta într-o manieră descendentă. De când a fost publicat pentru prima dată de Winston W. Royce în 1970, modelul cascadă a fost utilizat pe scară largă în domeniul dezvoltării de software. În ciclul procesului de dezvoltare software, modelele de programare sunt utilizate pentru a planifica diferitele etape ale dezvoltării unei aplicații. Un astfel de model este modelul cascadei.
Model de faze ale cascadei
Acum să vorbim despre fazele modelului cascadei, care poate fi explicat clar prin intermediul acestei infografii demo.
Cu infografiile de mai sus, putem înțelege că modelul cascadei are în total 7 faze ale ciclului software de proiectare și dezvoltare, care sunt următoarele:
- cerinţe
- Analiză
- Proiecta
- Codare / implementare
- Testarea
- Operare / desfășurare
- întreținere
Astfel, putem vedea că modelul cascadei funcționează ierarhic de sus în jos cu o fază finalizată cu verificări complete, apoi trecerea la o altă fază, inclusiv procese de fază precum Concepție, Inițiere, Analiză, Proiectare, Construcție, Testare, Producție / Implementare și Întreținere. Pentru a obține o cunoaștere mai succintă despre modelul cascadei, trebuie să înțelegem toate procesele sale în profunzime cu modelul său de lucru. Există o etapă prealabilă de bază care trebuie înțeleasă înainte de a începe fazele profunde ale cunoașterii. Este vorba despre studiul de fezabilitate pentru produsul software. Tratează aspectele financiare și tehnice ale cerințelor proiectului. Această fază tratează corectarea măsurilor pe baza beneficiilor și a dezavantajelor analizate. Astfel, se alege cea mai bună soluție.
- Cerințe: După cum se specifică prin cuvinte, trebuie să știm și să înțelegem ce avem de proiectat, ce avem de dezvoltat, procesele sale, care va fi funcționalitatea lui, etc. Acesta furnizează material de intrare pentru produsul realizat și, astfel, produsul care urmează. este studiat, finalizat și marcat. De asemenea, ne oferă extinderea pentru a decide cerințele hardware sau software ale produsului care va fi proiectat, dezvoltat și capturat în toate fazele.
- Analiză: Rezultă în proiectarea de modele, scheme și reguli de afaceri. Nu numai că această cerință este împărțită în două părți:
- Culegerea și analiza cerințelor: În primul rând, toate informațiile și cerințele pentru dezvoltarea produsului sunt colectate de la client și apoi sunt procesate pentru analiză. Rolul principal al acestei părți este de a eradica incompletitudinea și inconsecvențele legate de dezvoltarea produselor software.
- Specificația cerinței: Apoi, cerințele analizate mai sus sunt documentate într-un document SRS (specificația cerințelor software). Acesta servește ca o cale între client și echipa de dezvoltare SRS. Orice litigii în viitor sunt gestionate și soluționate doar prin această documentație SRS.
- Proiectare: După ce prima fază este finalizată și verificată, este următoarea fază cea mai importantă care trebuie studiată, deoarece este utilizată pentru proiectarea sistemului. Ajută la specificarea cerințelor software și hardware pentru proiectarea produsului. De asemenea, ajută în arhitectura generală pentru proiectarea sistemului. Deci, specificația cerinței este studiată și verificată în cea mai mare parte în această fază. De asemenea, este util în transformarea documentului SRS în proiectarea și dezvoltarea funcțională a produsului software. Deci putem spune că în faza de proiectare, unul realizează arhitectura de ansamblu pentru proiectul de dezvoltare software.
- Implementare: Cu proiectarea sistemului complet verificată, faza de implementare vine pe rând. În această fază, sunt preluate intrările din proiectarea sistemului și sunt dezvoltate pentru prima dată în programe mici cunoscute sub denumirea de unități, care este testat și implementat în faza viitoare. Fiecare unitate în faza de implementare este supusă dezvoltării și funcționalitatea completă a acesteia este testată, care este cunoscută și sub denumirea de testare a unității. Deci, în această fază, proiectarea sistemului este transformată în cod sursă cu module de programe complet funcționale. Acesta include dezvoltarea, dovedirea și integrarea software-ului.
- Integrare și testare: Fiecare unitate de proiectare și dezvoltată în fazele anterioare sunt încorporate din faza de implementare care este integrată într-un modul sau sistem pentru un test diferit, cum ar fi testul de sarcină, testul de plumb etc., după testarea fiecărei unități. Mediul de testare este supus unei verificări software constante pentru a afla dacă există fluxuri sau erori în proiectare sau cod. Testarea se face pentru a menține stabilitatea și fezabilitatea software-ului, astfel încât clientul să nu se confrunte cu tulburări sau bug-uri în timpul producției sale. Deci, în această fază după implementare, întregul sistem este testat minuțios pentru eventualele defecțiuni și defecțiuni. Testarea sistemului constă din trei tipuri diferite de activități, care pot fi explicate mai jos:
- Testare alfa (α): este testarea făcută de echipa de dezvoltare.
- Testare beta (β): este testarea efectuată de echipa prietenoasă a clienților și utilizatorilor.
- Testarea acceptării: se realizează atât după testarea alfa cât și testarea beta. Practic, această testare se face după livrare de către clienți. După testarea efectuată de client, se ia decizia dacă acest software este acceptabil sau de a-l respinge. Deci, în această fază, practic, se face depanarea erorilor.
- Desfășurarea sistemului / Operațiunilor: odată ce testările nefuncționale, funcționale, alpha și beta sunt efectuate, produsul software este implementat utilizatorului sau sistemului clientului sau este lansat pe piață. Faza de implementare include instalarea, migrarea și asistența sistemului complet către mediul utilizator sau client.
- Întreținere: este ultima, dar cea mai importantă fază în modelul fluxului de lucru al cascadei. Acest pas vine imediat după instalare și include modificarea corespunzătoare a produsului sau sistemului sau pentru îmbunătățirea, modificarea sau modificarea atributelor legate de problemele de performanță legate de sistem. rolul său principal este de a îmbunătăți performanța sistemului cu rezultatul maxim al preciziei rezultatului software. Aceste modificări ridicate în faza de întreținere sunt în principal legate de modificările inițiate de către client sau utilizatori după faza de instalare și testare, care include bug-uri, cum ar fi defect descoperit în timpul utilizărilor live ale sistemului sau cerere ridicată de către clienți. Astfel, clientului i se oferă întreținere și asistență în timp util și programat pentru produsul dezvoltat. Vei fi cu adevărat uimit să știi că efortul depus în faza de proiectare și dezvoltare a produsului software este doar efortul de 60% comparativ cu eforturile depuse în faza de întreținere. Există în principiu trei tipuri de întreținere, care este explicată mai jos:
- Întreținere corectivă: în faza de proiectare și dezvoltare, unele erori nu sunt descoperite, ele iau în considerare doar atunci când utilizează clientul. Aceasta este doar o întreținere corectivă, ceea ce înseamnă corectarea problemelor sau a erorilor care nu au fost descoperite în faza de dezvoltare.
- Întreținere perfectă: Acest tip de întreținere se realizează la cererea clienților pentru a crește și îmbunătăți funcționalitățile sistemului sau software-ului.
- Întreținere adaptivă: este întreținerea necesară pentru comutarea mediului de sistem. De obicei, necesar pentru portarea sistemului existent într-un mediu nou sau computer nou sau sistem sau poate cu un nou sistem de operare. Această fază este prea importantă, deoarece acest lucru duce la o performanță mai bună a sistemului.
Așadar, în discuția de mai sus, am cunoscut profund fiecare fază a modelului cascadei, cu specificații complete. Deci, putem spune că modelul cascadei este foarte important în domeniul software, în comparație cu industriile mecanice, deoarece fiecare fază are propria lor importanță, duce la generarea unui software mai productiv și stabil.
avantaje
Nu numai că acest model de cascadă are multe alte avantaje în ciclul de viață al dezvoltării software, care poate fi discutat mai jos:
- Permite departamentul și controlul.
- Un program poate fi stabilit cu termene pentru fiecare etapă de dezvoltare și un produs poate continua prin fazele modelului procesului de dezvoltare unul câte unul.
- Deoarece suferă faze ușor de înțeles și explicabile, depășește multe probleme, deci este foarte ușor de utilizat.
- Datorită rigidității modelului fluxului de lucru, este foarte ușor de gestionat, deoarece fiecare fază a modelului cascadei are procese specifice de revizuire și livrare.
- Modelul de cascadă funcționează bine pentru proiecte mai mici, unde cerințele sunt foarte bine înțelese.
- Programul poate fi stabilit cu termene pentru fiecare etapă de dezvoltare și un produs poate continua prin fazele modelului procesului de dezvoltare unul câte unul.
- Etapele clar definite.
- Repere bine înțelese.
- Activități ușor de aranjat.
- Procesul și rezultatele sunt bine documentate.
- Întărește obiceiurile bune: definiți înainte de proiectare,
- Proiectați-înainte-cod.
- Modelul funcționează bine pentru proiecte și proiecte mai mici, unde cerințele sunt bine înțelese.
Dezavantaj
După cum știm că fiecare monedă are două fețe, deci cu accesul mare la avantajele modelului cascadei, modelul cascadei are și unele dezavantaje sau puteți spune dezavantaje despre care se discută mai jos:
- Nu este un model bun pentru proiecte complexe și orientate pe obiecte.
- Nu este potrivit pentru proiectele în care cerințele prezintă un risc moderat până la mare de schimbare.
- Este dificil să estimați timpul și costurile pentru fiecare fază a procesului de dezvoltare.
- Nu este un model bun pentru proiecte complexe și orientate pe obiecte.
- Niciun software de lucru nu este produs până târziu în timpul ciclului de viață.
- Nu se pot adapta cerințelor schimbătoare.
- Este dificil să măsurați progresul în etape.
- Cantități mari de risc și incertitudine.
- Model slab pentru proiecte lungi și în derulare.
- Ajustarea domeniului de aplicare în timpul ciclului de viață poate încheia un proiect.
- Fără cale de feedback
- Fără suprapunere de faze
- Este dificil să se adapteze solicitărilor de schimbare.
- riscul și incertitudinea sunt mari cu acest model de proces.
Unde se utilizează modelul cascadă
Acum, după încercuirea tuturor scenariilor, am ajuns într-un punct în care vrem să știm unde să folosim modelul cascadei.
- Modelul de cascadă este folosit în mare parte într-un proiect de apărare, cerința fiind clară, deoarece înainte de a trece la faza de dezvoltare, acestea o analizează bine.
- Acest lucru poate fi utilizat și în proiectele de migrație în care cerințele vor fi aceeași numai platforma sau limbile pot varia / modifica.
Concluzie
Deci, în ansamblu, pot spune că modelul cascadei este cel mai potrivit pentru proiectele de dezvoltare software mici, comparativ cu proiectele mari, deoarece proiectarea, dezvoltarea și implementarea este mai ușoară în proiectul mic atunci când lucrezi la modelul de cascadă, deoarece în acest model toate fazele anterioare au nevoie care urmează să fie finalizat atunci când treceți la fazele viitoare. Așadar, în proiectul mare problemele și erorile apar frecvent, deoarece are un model mare, astfel încât de fiecare dată faza de testare va fi continuată dacă este implementată prin intermediul modelului cascadei, ceea ce va duce la o mai mică optimizare și acuratețe a software-ului.
Articole recomandate
Acesta a fost un ghid pentru modelul cascadă. Aici am discutat despre fazele, avantajele și dezavantajele modelului cascadei. Puteți parcurge și alte articole sugerate pentru a afla mai multe -
- Ce este AWS?
- Ce este Bootstrap?
- Ce este un stup?
- Ce este Unix?
- Scrum vs Cascada | Comparaţie