modelul Cascade

În inginerie software , modelul cascada (modelul cascadă în limba engleză ) sau ciclul de viață cascada (cascada ciclului de viață) este modelul mai tradițional al ciclului de viață al software - ului . Conform acestui model, procesul de dezvoltare software este structurat într - o secvență lineară de faze sau etape ^[1] , care include:

Acest model preia succesiunea etapelor tipice de fabricare a producției, și a fost primul care urmează să fie aplicat atunci când dezvoltarea de software a început să fie conceput ca o activitate industrială. ^[2] Modelul a fost abandonat progresiv de către industria de software, dar rămâne un important de referință istorică.

Istorie

Ciclul de viață cascadă a fost primul model de ciclu de viață software dezvoltat ca urmare a crizei de software . Teoretizare său reprezintă în primul rând o schimbare importantă a perspectivei în practica de dezvoltare de software, care este pentru prima dată concepută ca un proces industrial , adică, ca o secvență de subactivități (toate cu documentația relativă și control), mai degrabă decât o activitate „artizanală“ (așa-numitul cod și fix abordare, care ar putea fi tradus în limba italiană ca programare prin încercare și eroare). Ciclul de viață cascadă a fost un succes enorm în anii 1970 și este încă cel mai adesea asociat cu procedural și structurat de programare astăzi .

Deoarece cel puțin din anii 1980, modelul a fost supus unor critici profunde și revizuiri, în special datorită evoluției a software - ului în sine și de limbaje de programare . Deși cele mai multe critici ale acestui model sunt acceptate universal astăzi, ciclul de viață în cascadă continuă să rămână un punct important de referință, în esență, un „canonic“ model de raport cu care moderne „variații“ sunt adesea descrise; și este adesea primul model de dezvoltare de software predat studenților. Printre noile metodologii de dezvoltare de software sunt modelul spirală și metodologiile agile.

Definiție

Pietrele de temelie sunt:

procesul de dezvoltare este împărțit în faze secvențiale;
fiecare etapă produce o ieșire care este utilizată ca intrare pentru etapa următoare;
fiecare pas al procesului este documentat.

Modelul tradițional cascadă presupune următoarele etape:

Cerințe de analiză : are ca scop determinarea ce va face sistemul; aceasta include, sau este precedată de un studiu de fezabilitate , în care se stabilește dacă este util (din punct de vedere tehnic și economic de vedere) pentru punerea în aplicare a sistemului pentru care cerințele sunt definite;
proiectare : scopul său este de a determina modul în care sistemul va face ceea ce a fost stabilit în prima fază, și , în special , împărțirea în module și relațiile dintre ele;
de codificare sau de dezvoltare: crearea de module cu un limbaj de programare ;
testarea : executarea de teste pentru a verifica corectitudinea punerii în aplicare a modulelor individuale;
integrare (sau test de integrare): executarea testelor pentru a verifica corectitudinea funcționării globale a sistemului;
de întreținere : urmează livrarea sau livrarea produsului la client, și include toate activitățile care vizează îmbunătățirea, extinderea și corectarea sistemului de-a lungul timpului.

În cadrul unei organizații specifice, modelul cascada poate fi redefinit cu variante specifice. În plus, o organizație poate formaliza în continuare procesul de definire a standardelor și impunerea unor constrângeri în ceea ce privește natura, mărimea, structura și / sau conținutul documentelor produse în diferitele etape (așa-numitele rezultate, livrabile), în mod obișnuit , în scopul permit un control mai riguros asupra progresului proiectului și calitatea lucrării efectuate.

Studiu de fezabilitate

Este prima etapă. Domeniul de aplicare

Decide dacă ar trebui să fie întreprinse noi de dezvoltare.

actorii implicați

Client / Client
Organizație de afaceri

Ieșire

Un document care prezintă diferite scenarii și soluții, împreună cu o discuție despre compromisuri în ceea ce privește costurile și beneficiile așteptate.

Dezvoltare

Interacțiunea dintre actorii
Caută soluții existente

Problemele principale

Analiza face adesea sub presiune și în grabă
Analiza Uneori imperfectă a costurilor cu remake-uri continue
decizii premature care împiedică dezvoltarea ulterioară

Analiza cerințelor

Intrare

Documentul studiu de fezabilitate

Domeniul de aplicare

Identificarea și descrierea cerințelor, adică caracteristicile sistemului

actorii implicați

Client / Client
Dezvoltatori
Organizație de afaceri

Ieșire

Un document care descrie caracteristicile sistemului și care surprinde nevoile utilizatorului, dar este, de asemenea, exhaustivă pentru proiectant. Acest document, pentru ca părțile să cadă de acord, trebuie să fie ușor de înțeles, precise, complete, coerente și lipsite de ambiguitate, de altfel ușor modificabil;
Ghid de utilizare: în unele cazuri, poate fi util să aibă o versiune preliminară care explică modul în care utilizatorul va interacționa cu sistemul;
Planul de testare: nu este esențial, dar puteți decide în această etapă, împreună cu utilizatorul.

Dezvoltare

Interacțiunea dintre actorii
Cu cât este mai inovator sistem, cu atât mai mult este necesar pentru a interacționa
Documentația trebuie să fie descrise în conformitate cu standardele și notațiile specifice

Problemele principale

Lipsa de limbaj comun între actorii
Cerințe adesea neclare
Incapacitatea de a lua în considerare toate cerințele și să producă un loc de muncă complet

Proiecta

Intrare

Document cerințele caietului de sarcini

Domeniul de aplicare

Definirea arhitecturii sistemului

Actori

Chief Software Arhitect / Arhitect Software

Ieșire

Definirea structurii generale (arhitectura de nivel înalt)
Definirea caracteristicilor componentelor individuale (module)

Dezvoltare

Identificarea componentelor necesare și a caracteristicilor acestora

Probleme

Multe decizii trebuie să fie făcute
Nu toate structurile sunt aceleași
Alegerile nu sunt întotdeauna bine definite

Modulul de codificare și testare

Intrare

Documentele proiectului

Domeniul de aplicare

Punerea în aplicare a formularelor

Actori

Dezvoltatori

Ieșire

module implementate

Dezvoltare

Scrierea codului
Forma de test
Standarde de verificare a conformității

Probleme

Scrierea codului

Integrarea și testarea sistemului

Intrare

Modulele codificate

Domeniul de aplicare

Verificați dacă modulele luate una câte una sunt de lucru
Verificați că, odată ce a pus împreună modulele continua să lucreze

Actori

Dezvoltatori

Ieșire

Sistemul de lucru
Tehnici de verificare și de validare (alpha test)

Probleme

Diferite tipuri de probleme legate în principal, pentru a analiza cerințele săraci

întreținere

Tot ceea ce se întâmplă din momentul în care sistemul este livrat la dispoziția sa
Verificarea software-ului de către utilizatori (test beta)
Este o fază foarte lungă

Simplificată, în acest fel, ciclul de viață clasic poate fi reprezentat ca:

Analize
Proiecta
Codificare
Integrare
Test
Eliberare

prin urmare, referirea la cascada găsită în numele.

Exemplu

Ca un exemplu, considerăm că ciclul de viață definit cu MIL-STD-2167 de către Statele Unite Departamentul Apararii (DoD) pentru Ada limba (un alt produs al DoD).

MIL-STD-2167 împarte ciclul de viață al software - ului în următoarele 6 activități macro:

ANALIZA:
- Analiza Cerințe: definește ceea ce este necesar în ceea ce privește funcțiile, fără a preciza modul în care acestea trebuie să fie puse în aplicare
- Design preliminar : Urmează cerințele, să dezvolte o abordare de software , care include , de asemenea , modele matematice, scheme logice funcționale și proceduri de testare. În această fază, structura generală și funcționarea sistemului sunt definite, indicând, de asemenea, relațiile dintre principalele blocuri funcționale (module)
PROIECTARE:
- Proiectul executiv : ierarhică eficientă și defalcare detaliată a acestor module; această descompunere continuă până la descompunerea ulterioară ar duce la codul programului
Implementarea:
- Codificare și verificare: scris și verificarea programelor pornind de la proiectul executiv și prin proceduri de verificare
- Codul Computer Software (CSC): integrarea și verificarea unităților incluse în subsistemele individuale
- Validarea integrării CSC

Beneficii

Modelul a jucat un rol important în dezvoltarea de software pentru a depăși limitările procesului „de cod și fix“ și în cele din urmă stabilite două concepte:

Procesul de dezvoltare de software trebuie să fie supuse disciplinei și planificare;
punerea în aplicare a produsului ar trebui să fie amânată până când obiectivele sunt perfect clare.

Cel mai mare avantaj al acestei metode de lucru este cu siguranță simplificarea controlului progresului proiectului prin subdiviziunea a ciclului de viață în faze succesive bine definite. Diferitele metodologii care adoptă acest ciclu de viață se disting în mod esențial prin subdivizarea și specificarea fazelor în subfaze mai elementare, în definirea standardelor de documentare și în identificarea momentelor de verificare la finalul fiecărei activități (etapa). Pentru a optimiza ciclul de viață, defalcarea fazelor în subfaze urmărește două obiective:

atribuie soluționarea problemelor specifice fiecărei faze
face, în măsura în care este posibil, fazele independente, pentru a fi în măsură să paraleliza activitățile lor

Defecte

Deși adoptarea acestor principii pare extrem de productivă, aplicarea practică a acestora are ca efect secundar, în special pentru proiecte mari, o deconectare periculoasă între diferitele activități, atât din cauza dificultăților de coordonare și de diferențele în metodologiile și formalismele specializate adoptate. De exemplu, identificarea structurilor de date și a sistemului de funcționalități sunt în mod normal abordate cu diferite metodologii și, în special pentru proiecte mari, simultan și separat de către diferite grupuri de lucru. În primul caz , rezultatele sunt formalizate cu diagrama entitate-asociere (ER sau diagrama entitate-relație în dicția anglo-saxon) , în conformitate cu o metodă de descompunere funcțională . Numai atunci când aceste două activități se încheie este o armonizare suplimentară a rezultatelor respective începute.

O altă problemă cu această abordare derivă din necesitatea de a finaliza complet întregul analiza cerințelor și aplicarea de proiectare faza pentru a începe programarea și apoi să verifice concluziile în domeniu.

Modelul, prin urmare, este o simplificare a realității, care nu găsește aplicarea deplină ca trei principii trebuie să fie respectate:

Liniaritatea: de multe ori există bucle de feedback (cazul alfa și beta de testare) pentru corectarea erorilor. Acest feedback trebuie să fie liniară și, prin urmare, nu este posibil să sară înapoi, dar toate fazele trebuie să fie retrasată într-un mod liniar;
Rigiditate: fiecare fază este înghețat atunci când se deplasează la faza următoare, astfel încât interacțiunea între clienții și dezvoltatorii nu este posibil în timpul ciclului de viață după partea inițială;
Monolitic: întregul model este orientat spre data de lansare unice care apare adesea luni sau ani după începerea primei faze așa că, dacă orice erori sunt făcute sau cerințele schimba, acestea vor fi puse în aplicare după o lungă perioadă de timp și, în orice caz către faza de livrare va urma în curând o altă adaptare , deoarece software - ul va fi deja depășite.

Cele mai mari probleme sunt următoarele:

Este dificil de estimat resursele și costurile în mod corect până cel puțin în prima fază de analiză a fost efectuată;
Specificarea cerințelor produce un document scris care leagă produsul care urmează să fie dezvoltate: acest lucru nu satisface întotdeauna nevoile clientului, deoarece este încă specificații bazate pe un document neînsuflețit care nu întotdeauna ajutor în definirea nevoilor (care, în schimb, apar imediat clar după prima versiune de software). Mai mult decât atât, acest document trebuie să fie complet și clar înainte de a începe de dezvoltare, dar acest lucru nu este întotdeauna posibil;
Utilizatorul de multe ori nu cunosc toate cerințele de aplicare pentru că nu le poate cunoaște, motiv pentru care documentul cerințe nu este întotdeauna completă și, prin urmare, există un pasaj la următoarea etapă cu documentația neclară;
Modelul ne obligă la standardele de utilizare în mare măsură bazate pe producerea unei anumite documentații în anumite momente, astfel încât lucrarea riscă să fie birocratizat.

Se înțelege modul în care costurile ridicate ale software-ului sunt de multe ori din cauza modelului cascadă, tocmai din cauza specificațiilor incomplete și numeroasele intervenții ulterioare pentru a introduce funcții care nu sunt prevăzute de la început. Se întâmplă, prin urmare, că defectele modelului cad de pe întreținere, cauzând costuri în creștere, sau că, dimpotrivă, operează cu o întreținere de sinteză prin producerea unui software, cu o punere în aplicare care diferă de specificațiile cerințelor.

Notă

^ Fazele cascada model.Archived 14 octombrie 2015 la Internet Archive .
^ Herbert D. Benington, Producere de programe mari de calculator. IEEE Analele Istoria calculatoarelor (IEEE Educațional Departamentul Activități) 5 (4), 1983

Elemente conexe

Alte proiecte

Wikimedia Commons conține imagini sau alte fișiere pe un model de cascadă

Portal IT : accesați intrările Wikipedia care se ocupă cu IT

[1] Fazele cascada model.Archived 14 octombrie 2015 la Internet Archive .

[2] Herbert D. Benington, Producere de programe mari de calculator. IEEE Analele Istoria calculatoarelor (IEEE Educațional Departamentul Activități) 5 (4), 1983

[1]

[2]