modelul cascadei în SDLC

pentru a înțelege modelul cascadei în SDLC, este necesar să vă scufundați în definiția modelului, fazele principale, ce documente sunt asociate ca urmare a fiecărei etape, avantaje și dezavantaje.

SDLC standuri pentru un ciclu de viață de dezvoltare de software. Este un cadru (o structură de susținere esențială) a unui proces de dezvoltare, care poate diferi de la companie la companie. Unul dintre cele mai populare tipuri de SDLC este modelul Waterfall. Cascada este, după cum se poate vedea de sus, un model de proces., În cuvinte simple, o descriere generalizată a procesului de dezvoltare software. Modelul cascada este cel mai cunoscut, așa cum a fost prima cronologic să apară și să fie descris, de Dr.Winston W. Royce în 1970 în „managementul dezvoltarea de sisteme software Mari.”

există o serie de tipuri de modele de ciclu de viață de dezvoltare, despre care este scris în continuare în detaliu, iar acestea sunt mai târziu veniți:

• scrum model
• rapid application development
• prototyping
• spiral model
• kanban development model
• și altele.,cu siguranță, s-au întâmplat să servească mai bine acolo unde modelul cascadei era mai puțin puternic. Pentru a înțelege „locurile subțiri”, este necesar să se scufunde în definiția modelului cascadă, fazele principale, ce documente sunt asociate ca urmare a fiecărei etape, avantaje și dezavantaje.

  Cascada Model definiție

  Cascada model este un liniar (secvențial) dezvoltarea ciclului de viață model care descrie dezvoltarea ca un lanț de etape succesive. Nici o fază nu poate fi inițiată înainte sau simultan cu cea anterioară sau actuală., Să luăm în considerare fazele principale ale modelului cascadei pe măsură ce merg.

  Modelul Cascada Principalele Faze

  

  la Cerințele de Sistem Fază

  în prima fază, cerințele de sistem sunt stabilite. Procesul începe cu solicitarea cerințelor de afaceri, analizarea și prioritizarea acestora, care se încheie cu crearea viziunii& Scope document (sau 2 documente separate în funcție de fiecare caz particular). Viziunea și domeniul de aplicare a documentelor sunt create înainte de semnarea contractului., Viziunea este definită ca un „concept strategic pe termen lung al scopului final și al formei unui nou sistem.”(Wiegers, 2012, p. 1) Domeniul de aplicare este ceea ce ” trage granița dintre ceea ce este în și ceea ce este în afara pentru proiect.”(Wiegers, 2012, p. 1)

  scopul Denotării este o parte esențială a proiectului pentru ambele părți. Face un client transparent ce se va face. O strategie bună pentru gestionarea așteptărilor este identificarea a ceea ce nu va fi inclus într-un produs, astfel încât așteptările clienților sunt clare, adică pentru documentul de aplicare a proiectului.,

  domeniul de aplicare al proiectului

  domeniul de aplicare al proiectului este de așteptat să conțină foaia de parcurs a proiectului, bugetele și descrierea, cu funcții principale definite în ceea ce privește documentul de viziune a problemei. Citiți un articol despre managementul domeniului de aplicare al proiectului de către un expert Vitaly Hornik.

  faza inițială este de neconceput fără specificația cerințelor Software (SRS) care este nucleul fazei.un SRS tipic include un scop, o descriere generală, cerințe specifice (atribute funcționale, nefuncționale, de calitate).,uneori, poate include prototipuri care pot fi de diferite tipuri: vertical / orizontal, static/dinamic, low-fidelity/high-fidelity. Machetele (sau prototipurile) sunt trimise designerilor UI/UX care le transformă în machete. Simțiți-vă liber să estimați șablonul de specificație a cerințelor Software (SRS) creat de XB Software.

  faza de proiectare

  următoarea fază din diagramele modelului cât de precis vor fi implementate tehnic cerințele sistemului. Această fază acoperă în mare măsură componente precum un limbaj de programare, straturi de date, servicii etc.,

  faza de implementare (dezvoltare)

  codul sursă real este în sfârșit scris în a treia fază, implementând toate modelele, logica de afaceri și integrările de servicii care au fost specificate în etapele anterioare. Procesul de creare a întregului cod poate fi împărțit în unități mici și fiecare unitate este dezvoltată și testată pentru funcționalitatea sa (testarea unității). După aceea, un întreg sistem este construit din unități gata făcute, iar a patra fază începe.,

  faza de testare

  după faza de dezvoltare, produsul ar trebui să experimenteze o asigurare completă a calității și testarea software pentru a descoperi defectele unui sistem. Testerii sunt implicați în găsirea și raportarea problemelor care trebuie rezolvate. Pentru a stoca problemele înregistrate, un sistem de urmărire a erorilor poate fi utilizat cu scopul ca problemele să poată fi tratate în faza ciclului de viață de întreținere.

  software-ul poate fi transmis atunci când problemele de cod sunt fixate. Clientul este angajat cu testarea de acceptare pentru a-l evalua pentru utilizare.,

  faza de întreținere

  de îndată ce produsul este destinat plasării într-un mediu viu, acesta intră în faza de întreținere gata a ciclului de viață de dezvoltare. Faza de întreținere implică nu doar implementarea aplicației, ci și asistența și întreținerea care pot fi necesare pentru a o menține funcțională și actualizată.

  citiți și criteriile pentru externalizarea nedureroasă pe care le-am enumerat după prioritate în articolul 7 Sfaturi pentru a alege o companie de dezvoltare web de externalizare.,

  avantajele și dezavantajele modelului cascadei

  modelul cascadei este ușor de urmărit și de înțeles, este comun instituțiilor mari cu multe niveluri de luare a deciziilor și coordonare. Totuși, ca orice alt model SDLC, are laturile sale puternice și slabe. Modelul cascada nu se poate potrivi orice fel de conceput de un proiect., de flexibilitate

• Lipsa de vizibilitate a progresului actual
• Creșterea termen de livrare
• Modificări în cerințele de afaceri sau adăugiri în funcționalitate necesită modificări la toate etapele anterioare
• Timp-shift într-o singură fază va afecta puternic întregul parcurs ca procese simultane nu sunt disponibile într-o cascadă model
• La sfârșitul produsul este disponibil numai la sfârșitul unui ciclu

Concluzie

modelul Cascada este cel mai potrivit:

• Pentru întreprinderile mici și proiecte pe termen scurt.,
• când cerințele sunt neschimbate.
• pentru clienții cu o structură corporativă complexă, cu multe niveluri de coordonare.

în plus, este recomandabil să estimați un șablon de specificații pentru cerințele de software liber (SRS) creat de XB Software.