Modele ale Procesului de Dezvoltare Software

Modele ale Procesului de dezvoltare software

Ca orice produs fabricat complex, un program este realizat urmând un anume proces.

Un proces de dezvoltare a programelor se bazează pe o formalizare a activităților specifice, la care ne-am referit. Scopul formalizării este obținerea unui ansamblu de mecanisme care, în cazul în care sunt aplicate sistematic permit obținerea într-un mod repetitiv și fiabil de produse software de calitate constantă. Descrierea procesului rămâne generală, pentru că nu este posibil să se definească un standard unic adaptat la toate tipurile de aplicații și la toate persoanele.

Dezvoltarea unui program poate fi văzută ca stabilirea unui șir de descrieri din ce în ce mai precise și din ce în ce mai apropiate de un program executabil și de documentația sa. Trecerile de la o descriere la alta sunt deseori numite rafinări succesive. Aceasta este o vedere simplificată, pentru ca nu ia în considerare natura iterativă a procesului de dezvoltare.

O dată dezvoltat un program, este pus în exploatare. Se pun atunci probleme de întreținere, de corectare a defectelor, de ameliorare a anumitor caracteristici sau de urmărire a evoluției cerințelor. Intreținerea poate impune modificarea funcțiilor sistemului și deci, un proces de redezvoltare. Din aceasta cauză se vorbește despre ciclul de viață al unui program, când considerăm exploatarea și întreținerea în plus față de dezvoltare.

Ce este ciclul de viata al unui program (Software life cycle)?

O secventa de etape in existenta produsului software. Sunt incluse toate activitatile necesare pentru dezvoltarea produsului si relatiile temporale dintre ele.

Fiecare etapa din ciclul de viata este caracterizata prin activitati specifice si produsele rezultate din activitatile respective.

Modele ale ciclului de viata software (Software development life cycle models or process models):

Waterfall model (Modelul cascada)

V model (modelul in V)

ESA ( European Space Agency) model

Incremental model (Modelul iterativ si incremental)

Dezvoltarea “agila”

Prototyping (Dezv pe baza de prototip)

Spiral model (Modelul in spirala)

Modelul cascada

Numit si modelul clasic al ciclului de viata sau modelul liniar

Descris de Royce în 1970, a fost larg utilizat de atunci, pentru descrierea generală a procesului de dezvoltarea programelor.

Ciclul de viață în cascadă prezintă dezvoltarea unui program ca o succesiune de faze ce se înlănțuie într-o derulare liniară, de la analiza cerințelor și până la livrarea produsului către client.

Fiecare fază corespunde unei activități și trebuie să se termine la o anumită dată prin producerea anumitor documente sau programe.

Rezultatele fazei sunt supuse unei revizii aprofundate și nu se trece la faza următoare decât atunci când sunt considerate satisfăcătoare.

In prima sa versiune, modelul avea numai săgeți descendente, care materializează înlănțuirea etapelor; el nu prevedea iterații. Săgețile ascendente au fost adăugate mai târziu pentru a ilustra principiul că o etapă repune în discuție numai etapa precedentă.

Limitele modelului în cascadă

Modelul în cascadă se bazează pe o secvență de faze bine delimitate. Documentele produse de fiecare fază sunt evaluate în cadrul reviziilor care validează trecerea de la o fază la alta. Din păcate, proba efectivă a bunei sau a proastei functionări a sistemului este realizată numai în cadrul fazei de integrare, când este posibilă evaluarea concretă a programului. Inaintea acestei faze au fost produse numai documente.

Abordarea în cascadă dă rezultate satisfăcătoare numai în cazul în care este efectiv posibilă înlănțuirea fazelor fără prea multe probleme. Aceasta presupune ca ansamblul cerințelor să fie perfect cunoscut și problema complet înteleasă de analiști. Trebuie de asemenea ca soluția să fie ușor de determinat de proiectanți și codificarea simplă – redusă ideal la generarea automată a codului plecând de la documentele de proiectare.

In realitate se constată că partea de necunoscut poate fi însemnată în anumite dezvoltări, în special datorită:

– neînțelegerii cerințelor de către client sau analist;

– instabilității cerințelor;

-alegerilor tehnologice;

-schimbărilor de personal.

Din toate aceste motive sunt necesare reveniri în etape anterioare ale procesului de dezvoltare. Aceste reveniri sunt de fapt o reflectare a realității. Dacă aceste reveniri sunt ocazionale și limitate la faze adiacente, modelul în cascadă este pertinent. In caz contrar, modelul în cascadă nu corespunde realității.

Avantaje:

Sistemul este bine documentat

Permite un bun management al proiectului:

planificarea resurselor umane pe etape

estimari de cost mai exacte

Dezavantaje:

Un produs executabil, care sa demonstreze functionarea sistemului este disponibil destul de tarziu, dupa integrare. Pana atunci s-au produs numai documente.

Deoarece modelul este secvential, exista numai uhn feedback local, la tranzitiile intre faze.

Multe erori sunt descoperite tarziu cost crescut

Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se modifica pe parcursul procesului de dezvoltare.

Experienta ultimelor decenii a demonstrat ca modelul este valoros.

Este utilizat si in prezent de multe organizatii mari.

Modelul in V

Este o varianta a modelului cascada, care pune in evidenta corelarea dintre activitatile de specificare si cele de testare, inlantuirea in timp a activitatilor fiind aceeasi.

Partea din stanga reprezinta lantul de specificare a sistemului iar cea din dreapta lantul de testare. Partea de jos a v-ului reprezinta implementarea

In acest model există două tipuri de dependențe între etape:

-cele reprezentate prin liniile care formeaza V-ul, care corespund înlanțuirii și eventualei iterații din modelul cascadă; etapele se derulează deci secvențial, urmând V-ul de la stânga la dreapta;

-cele reprezentate prin linii orizontale, care indică faptul că o parte din rezultatele etapei din care pleacă săgeata sunt utilizate direct în etapa țintă. De exemplu, la terminarea etapei de proiectare arhitecturală, cazurile de teste de integrare trebuie să fie complet descrise.

Prototiparea

Pentru sisteme noi, în mod special dacă ele sunt mari și complexe este puțin probabil să se construiască o specificație completă, logică și validă înainte ca sistemul sa fie construit și utilizat. Acest fapt a condus la ideea prototipării. Ideea este de a permite viitorilor utilizatori să exerseze cu o primă versiune a sistemului, care poate fi obținută rapid prin tehnici de simulare și/sau de interpretare a specificațiilor. In acest ultim caz, limbajele logico-funcționale sunt în mod sigur chemate să joace un rol important.

Prototipul este o schiță a viitorului sistem: el nu are performanțele și nu răspunde exigențelor de calitate ale unui produs finit. Prototipul oferă clientului functionalități (nu în totalitate) ale viitorului sistem și interfața sa utilizator. El este dezvoltat într-o manieră iterativă. Cerințele sunt extrase și validate iterativ prin utilizarea prototipului. In fiecare iterație specificația sistemului este modificată și detaliată până când prototipul satisface necesitățile utilizatorilor.

Un prototip care este utilizat pentru a desprinde cerințele viitorilor utilizatori, este o "machetă exploratoare".

Activitatea de prototipare poate interveni de asemenea în etapa de proiectare, pentru a experimenta și compara diferite variante. Astfel de prototipuri se numesc "machete experimentale".

Figura următoare redă procesul de prototipare dedicat extragerii cerințelor:

Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte înalt: Smalltalk, PROLOG, LISP, SETL și altele. In prezent există limbaje și medii de dezvoltare specializate pentru construirea prototipurilor. Astfel de limbaje sunt limbajele de generația a 4-a (4GL).

Cu toate că se poate folosi același limbaj de programare, atât pentru realizarea prototipului cât și pentru dezvoltarea aplicației, se recomandă ca prototipul să fie considerat un sistem "închis", adică să nu fie folosit ca bază pentru dezvoltarea aplicației. Aceasta deoarece:

– prototipul a fost dezvoltat prin modificări succesive, de aceea arhitectura sa inițială a fost alterată, ceea ce îngreunează întreținerea;

– prototipul trebuie să corespundă cerințelor utilizatorilor numai din punct de vedere funcțional. De aceea, în dezvoltarea sa sunt neglijate aspecte ca: eficiența, adaptabilitatea, compatibilitatea și chiar fiabilitatea.

Modelul Incremental

Modelul ciclului de viață "Incremental" este opus modelului « in cascada ».

El se bazează pe o idee foarte simplă: dacă un sistem este prea complex pentru a fi înțeles, conceput sau realizat intr-o singura fază este mai bine sa fie realizat în mai multe faze, prin evoluție.

Cum se aplica

Intr-o faza initiala:

Se studiaza scopul proiectului si fezabilitatea sa. In cazul deciziei de continuare a proiectului:

Se detaliaza cerintele utilizatorilor si se efectueaza o analiza de nivel inalt, pentru a se determina cerintele software la un nivel general.

Se determina o arhitectura generala a sistemului.

Se impart cerintele in subseturi care pot fi implemenate in incremente separate. Se stabileste planificarea in timp a incrementelor.

Fiecare increment implementeaza un subset de cazuri de utilizare de nivel inalt, care exprima cerintele utilizatorilor. El este construit urmand abordarea “cascada”: analiza detaliata a cerintelor din subset, proiectarea, implementarea si testarea. Rezultatul este un produs care satisface un subset al cerintelor si este livrat utilizatorilor.

Un produs tipic consta din 10-50 incremente.

Se incepe cu o implementare simpla a unui subset al cerintelor software. Rezulta o prima livrare.

Scopul primei implementari este de a crea un produs la care utilizatorul poate reactiona. El trebuie sa puna in evidenta aspectele cheie ale problemei si sa furnizeze o solutie sufient de simpla pentru a fi inteleasa si usor de implementat.

Fiecare noua iteratie include analiza ultimei versiuni si adaugarea de noi functionalitati, ceea ce presupune reproiectarea, codificarea si testarea. Se urmareste ca proiectarea sa fie directa, modulara, sa suporte reproiectarea.

Analiza unei iteratii se bazeaza pe feedback-ul utilizatorului si pe instrumentele de analiza disponibile. Ea se refera la: modularitea produsului, cuplarea modulelor, utilizabilitatea, fiabilitatea, eficienta si realizarea scopurilor.

Fiecare iteratie este o varianta imbunatatita a celei anterioare, de aceea metoda se mai numeste “imbunatatirea iterativa” (iterative enhancement).

Se utilizeaza masuri pentru evaluarea evolutiei sistemului. Masurile prin care se evalueaza un software sunt dificil de inteles ca valori absolute, dar schimbarile valorilor lor in evolutia unui sistem sunt o baza de comparatie. Astfel de masuri sunt: numarul de defecte, efortul de actualizare, dimensiune, complexitatea, cuplarea modulelor. Schimbarile diferitelor aspecte se pot monitoriza si se pot stabili limite pentru anumite masuri, pentru a semnala probleme sau anomalii.

Utilizarea analizei si a masuratorilor ca ghid in procesul iterativ este o diferenta majora intre aceasta metoda si metodele de “dezvoltare agila” (agile software development). Ele sunt suportul pentru determinarea eficientei procesului si a calitatii produsului.

Fiecare iterație a ciclului de viață iterativ si incremental reproduce ciclul de viață în cascadă la o scară mai mică. Obiectivele unei iterații sunt stabilite pe baza evaluării iterațiilor precedente. Documentația este construită treptat, în timpul fiecărei iterații. La sfârșitul dezvoltării, documentele obținute au aceeași formă cu cele obținute în maniera convențională.

Avantaje:

In fiecare etapa este livrat un produs executabil, care satisface o parte din cerintele utilizator. Opus modelului cascada in care se elaboreaza documente.

Prototipurile sunt livrate clientului/utilizatorilor.

Feedback-ul utilizatorilor este distribuit pe intreg parcursul dezvoltarii.

In cazul aparitiei unor schimbari in cerinte acestea pot fi incoporate in urmatorul prototip.

Ciclul de viață iterativ se bazează pe evoluția prototipurilor executabile, măsurabile și deci pe evoluția elementelor concrete. El este opus din acest punct de vedere ciclului de viata în cascadă care se bazează pe elaborarea de documente. Livrările forțează echipa să dea rezultate concrete în mod regulat.

Integrarea diferitelor componente ale programului este realizată într-o manieră progresivă în timpul construcției.

Progresele se măsoară prin programe demonstrabile mai degrabă decât prin documente sau estimări, ca în ciclul de viață în cascadă;

In cursul dezvoltării, clientul poate utiliza prototipurile. Demonstrarea prototipurilor prezintă numeroase avantaje:

– utilizatorul este pus în fața situațiilor de utilizare concrete care-i permit să-și definească mai bine dorințele și să le comunice echipei de dezvoltare;

– utilizatorul devine partener al proiectului; el îsi ia partea de responsabilitate în noul sistem și de fapt îl acceptă mai ușor;

Dezavantaje

Ciclul de viață Incremental se bazează pe evoluția prototipurilor executabile. Din nefericire, programele nu se pretează în mod natural evoluției, din contră, ele sunt deseori foarte "fragile" la modificări. Efectul unei modificări locale se poate propaga în ansamblul aplicației. Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a programului, facându-l greu de verificat și de întreținut.

Erorile de proiectare sunt mai greu de eliminat.

Abordarea obiect bazată pe modularitate și încapsulare conduce la programe mai robuste și mai rezistente față de schimbări. Din acest punct de vedere, abordarea obiect furnizeaza un cadru confortabil pentru dezvoltarea prin evoluție, într-o manieră iterativă.

Clientul poate vedea ce se poate face si poate cere mai mult!

Abordarea incrementala se poate transforma usor intr-una « codifica si repara « (« build and fix »).

Planificarea

Principalul risc in utilizarea unui model incremental este de a lucra intr-o manierea “ad-hoc”. Determinarea unui plan de actiuni este de prima importanta pt succesul abordarii incrementale. In faza de analiza preliminara se determina scopul proiectului si se incearca determinarea riscurilor majore ale proiectului, se determina o lista o cerintelor si constrangerilor mai importante, pt a construi un plan de dezvoltare. Se stabileste natura fiecarui icrement si ordinea de construire a incrementelor.

O varianta a modelului este “Numai implementarea incrementala”:

Urmeaza modelul cascada pana in faza de implementare

In timpul analizei cerintelor si proiectarii de sistem:

Se definesc subseturi / subsisteme care pot fi livrate

Se definesc interfete care permit adaugari iterative simple, cu un minim de modificari a arhitecturii existente

Diferitele parti sunt implementate, testate si livrate in functie de diferite prioritati si la diferite momente de timp

Construirea in paralel a incrementelor: risc

Diferite incremente pot fi construite in paralel de diferite echipe.Dupa inceperea fazei de proiectare a primului increment, echipa de specificare incepe specificarea celui de-al 2-le increment. Riscul este ca cele 2 incremente sa nu “se potriveasca”. In mod norma, al 2-lea trebuie sa-l includa pe primul. Fiecare increment are parti comune cu altele. Este necesara o buna comunicare si coordonare intre echipele care construiesc in paralel incrementele care au parti comune (privind implementarea partilor comune). Aceste probleme cresc exponential cu numarul de incremente.

Rational Unified Process (RUP: www.rational.com)

Este un proces de dezvoltare iterativ. Cei care l-au definit, Ivar Jacobson, Grady Booch, and James Rumbaugh, il caracterizeaza astfel:

Dirijat de cazurile de utilizare

Modelul cazurilor de utilizare descrie complet functionalitatea sistemului. Cazurile de utilizare dirijeaza procesul de dezvoltare: dezvoltatorii creaza modele de proiectare si implementare pentru a realiza cazurile de utilizare iar testorii testeaza sistemul pentru a verifica daca sistemul implementeaza corect cazurile de utilizare.

Centrat pe arhitectura

Arhitectura sistemului este aspectul cel mai important al sistemului. Arhitectul selecteaza cazurile de utilizare care reprezinta functile cheie ale sistemului (5%-10% din cazurile de utilizare), le specifica in detaliu si le realizeaza in termeni de subsisteme, clase, componente.

Inerativ si incremental

Proiectul de dezvoltare software este divizat in mini-proiecte, fiecare fiind o iteratie din care rezulta un increment. Fiecare iteratie are de-a face cu cele mai importante riscuri si realizeaza un grup de cazuri de utilizare care impreuna extind utilizabilitatea produsului. In fazele initiale, un proiect initial poate fi extins cu unul mai detaliat. In fazele urmatoare, incrementele sunt in mod tipic aditive.

Agile software development

Este un cadru conceptual pentru proiectele software. Exista mai multe metode de “dezvoltare agila”, cum sunt cele expuse de “Agile Alliance”, o organizatie non-profit.

Pentru orice proiect software exista o serie de factori de risc care pot periclita finalizarea cu succes a proiectului, cum ar fi: factori de experienta ( conducatorului de proiect, a echipei), factori de planificare, factori tehnologici, factori externi (modificarea cerintelor, modificarea interfetelor externe).

Cele mai multe metode de dezvoltare agila incearca sa minimizeze riscul dezvoltand software-ul in intervale scurte de timp, numite “timeboxes”, constand din 1-4 saptamani. Data de sfarsit a unui “timebox” nu poate fi modificata. Daca echipa depaseste data, iteratia este anulata si replanificata.

Fiecare iteratie este un proiect software in miniatura si include toate activitatile necesare livrarii mini-incrementului unei noi functionalitati: planificare, analiza cerintelor, proiectare, codificare, testare, documentare.

Fiecare noua iteratie trebuie sa livreze un nou produs. La sfarsitul fiecarei iteratii echipa re-evalueaza prioritatile proiectului.

Timebox-urile sunt utilizate in ,metodele de dezvoltare agila ca o forma de management al riscului in dezvoltarea unui software.

Metodele “agile” pun in evidenta comunicarea directa intre participantii la elaborarea unei iteratii, in locul documentelor scrise. Acestia lucreaza in aceeasi locatie, intre ei fiind cel putin programatorii si “clientii” lor (cei care definesc produsul). Echipa poate include testori, proiectanti de interactiune, echipe de documentare tehnica si manageri.

Principala masura a progresului este considerata software-ul functional. Se produce foarte putina documentatie, motiv pentru care metodele sunt criticate.

Pentru mai multe informatii despre metodele de dezvoltare agila: http://www.agilealliance.org/.

Comparatie cu alte metode

Considerand ca metodele de dezvoltare pot fi plasate pe o scara continua de la cele adaptive la cele predictice, metodele agile se situeaza la extremitatea celor adaptive.

<–Agile–> <–Iterative/Incrementale–> <–Cascada–>

<––––-|––––––––––––|–––––-|->

Adaptive Predictive

Metodele adaptive sunt focalizate pe adaptarea rapida la schimbari. Nu se au in vedere cu exactitate ce se va intampla in viitor. O echipa adaptiva poate raporta exact ce sarcini vor fi realizate saptamana urmatoare si ce este planificat pentru luna urmatoare.

Metodele predictive sunt focalizate pe planificarea in detaliu a activitatilor, in timp. O echipa predictiva poate raporta exact ce este planificat pentru intreagul proces de dezvoltare. Echipa predictiva are dificultati in schimbarea directiei. Planul este optimizat pentru desinatia originala iar schimbarea directiei poate necesita renuntarea la rezultatele curente si replanificarea activitatilor. Numai schimbarile considerate importante sunt luate in considerare.

In comparatie cu metodele incrementale:

asemanare- creaza produse livrabil in perioade de timp scurte

deosebiri:

perioadele de timp sunt masurate in saptamani si nu luni

perioadele de timp sunt stricte (time-box-uri)

in metodele incrementale procesul este ghidat de analiza si masurare a caracteristicilor produsului. Ele sunt suportul pentru determinarea eficientei procesului si a calitatii produsului

In comparatie cu modelul cascada

Dezvoltarea agila are foarte putine in comun cu dezvoltarea cascada. Modelul cascada are si in prezent o utilizare larga.. Modelul cascada este cel mai predictiv, activitatile sunt pre-planificate intr-o secventa. Progresul este masurat prin produse intermediare (specificatii, doc de proiectare, planuri de testare, revizii ale codului, etc). Efortul de integrare si testare poate fi foarte mare (cateva luni – cativa anui!), fiind una dintre cauzele de esec ale unei dezvoltari cascada. Prin dezv agila se produc produse executabile intervale de cateva saptamani sau luni. Se pune accentul pe obtinerea de executabile cat mai repede apoi imbunatatirea lor continua!

Extreme Programming, este o metoda de dezvoltare agila care a crescut popularitatea metodelor agile.

Extreme Programming (XP) este un model incremental bazat pe iteratii scurte, testare intensiva si simplitate. Este adecvata pentru echipe mici si proiecte caracterizate prin schimbari rapide ale cerintelor.

Informatii suplimantare despre XP pot fi gasite la: www.extremeprogramming.org, www.xprogramming.com.

Modelul spirala

Barry Boehm a definit acest model plecand de la slabiciunile modelului cascada, in special lipsa sa de flexibilitate la schimbari ale cerintelor.

Este focalizat pe analiza riscurilor in mod incremental, repetand modelul cascada intr-o serie de cicluri, ca in figura urmatoare.

Fiecare ciclu consta din 4 faze.

Determinarea obiectivelor: definirea produsului, determinarea scopurilor si a constrangerilor, generarea alternativelor.

Evaluarea alternativelor: analiza riscurilor, prototiparea

Dezvoltarea produsului: proiectarea de detaliu, testarea unitara, integrarea, ….

Planificarea urmatorului ciclu: evaluarea de catre client, planificarea dezvoltarii si a livrarii catre client.

Este o imbunatatire a modelului cascada deoarece prevede mai multe livrari si mai multe posibilitati de implicare a clientului.

Raza spiralei reprezinta costul acumulat.

Informatii suplimentare: http://www.stsc.hill.af.mil/crossTalk/2001/05/boehm.html.

Ulterior Boem a sugerat o versune modificata a modelului – modelul spirala WinWin, care adauga la inceputul fiecarui ciclu activitati de identificare a partilor interesate in proiect (“stakeholders”) si conditiile lor de castig (“win conditions”).