Sunteți pe pagina 1din 17

Metodologii in dezvoltarea software

1. Introducere
Succesul unui proiect/produs software depinde foarte mult de metodologia de lucru utilizata pentru conceptia, dezvoltarea si implementarea acestuia. Identificarea corecta a metodologiei de lucru adecvata fiecarui tip de proiect in parte are la baza urmatoarele 2 premise / considerente: y Cunoasterea metodologiilor de dezvoltare software, cu avantajele si dezavantajele aferente y Specificul si complexitatea produsului software ce urmeaza a fi dezvoltat De exemplu, nu se poate aplica aceeasi metodologie de lucru pentru proiecte precum dezvoltarea unui site web de prezentare a unei firme, dezvoltarea unei solutii de gestiune a proceselor de business ale unei companii sau dezvoltarea unui program software pentru conducerea avioanelor, intru-cat proiectele respective impun o abordare, un efort de munca si un grad de risc diferit. Iata cateva dintre dintre cele mai importante metodologii de dezvoltare a unui program software:

2. Modelul secvential liniar (Cascada)


2.1 Descriere
Modelul Waterfall, numit si modelul clasic al ciclului de viata sau modelul liniar, reprezinta un proces de implementare secvential, utilizat deseori in procesul de dezvoltare software. Ciclul de viata in cascada prezinta dezvoltarea unui program ca o succesiune de faze ce se inlantuie intr-o derulare liniara, de la analiza cerintelor si pana la livrarea produsului catre client. Fiecare faza corespunde unei activitati si trebuie sa se termine la o anumita data prin livrarea anumitor documente sau programe. Rezultatele fazei sunt supuse unei revizii aprofundate si nu se trece la faza urmatoare decat atunci cnd sunt considerate satisfacatoare. Modelul cascada defineste urmatoarele faze in dezvoltarea unui program: Cerinte, Proiectare, Implementare, Integare si Mentinere.

In faza de Cerinte sunt stabilite toate cerintele posibile ale sistemului ce se doreste a fi implementat. Cerintele sunt culese de la utilizatori prin consultarea acestora, dupa care este analizata posibilitatea de incorporare a lor in produsul dorit. La final este redactat un document de cerinte, care va fi utilizat ca si ghid pentru fazele urmatoare ale proiectului. In etapa de Proiectare sunt studiate cerintele de la prima etapa si este elaborat design-ul proiectului. Aceasta faza ajuta la specificarea cerintelor de sistem si hardware, precum si la definirea arhitecturii de ansamblu. Rezultatul acestei etape se concretizeaza in redactarea unui document ce cuprinde specificatiile de proiectare. In etapa de Implementare munca este divizata in module si incepe implementarea codului. Sistemul este dezvoltat mai intai in mici programe, numite unitati, care vor fi apoi integrate in faza urmatoare. Fiecare unitate este dezvoltata si testata, pentru a ne asigura ca respecta specificatiile. In faza de Integrare, toate unitatile dezvolate in faza anterioara sunt integrate si testate pentru a verifica daca se coordoneaza, iar sistemul, privit ca un intreg, se comporta conform cu specificatiile. Dupa testarea cu succes, produsul este livrat la beneficiar. Ultima faza a modelului Waterfall este teoretic o faza ce nu are un termen de finalizare. In general, problemele unui program software apar dupa ce el incepe sa fie utilizat, astfel incat problemele vor fi rezolvate dupa lansarea produsului.

2.2
y

Avantaje

Sistemul este bine documentat, ceea ce reprezinta un avantaj atunci cand apar noi membrii in echipa Este un model usor de utilizat si simplu Fiecare faza are un rezultat asteptat, datorat rigiditatii modelului Etapele sunt implementate individual, pe rand. Permite un bun management al proiectului: o o planificarea resurselor umane pe etape estimari de cost mai exacte

y y y y

2.3
y

Dezavantaje

Culegerea specificatiilor in etapa de Cerinte este foarte importanta pentru a proiecta si implementa produsul corespunzator. Cu toate acestea, cerintele pot fi adaugate si dupa finalul acestei etape, fapt ce influenteaza in mod negativ dezvoltarea si implica eventuale costuri suplimentare Problemele din cadrul unei etape nu sunt niciodata rezolvate complet in cadrul aceleiasi etape Partitionarea in etape a proiectului nu este flexibila Un produs functional finit este obtinut tarziu, comparativ cu momentul de inceput al proiectului. Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

y y

2.4

Concluzie

Abordarea in cascada da rezultate satisfacatoare numai in cazul n care este efectiv posibila inlantuirea fazelor fara prea multe probleme. Aceasta presupune ca ansamblul cerintelor sa fie perfect cunoscut si problema complet inteleasa de analisti. Trebuie de asemenea ca solutia sa fie usor de determinat de proiectanti si codificarea simpla.

3. Modelul Prototip
3.1 Descriere
Scopul modelului Prototip este de a contracara primele doua limitari ale modelului Waterfall, discutat mai sus. In loc de a stabili definitiv cerintele inainte de a putea incepe cu proiectarea si implementarea este lansat un prototip pentru a intelege cerintele. Prototipul este o schita a viitorului sistem: el nu are performantele si nu raspunde exigentelor de calitate ale unui produs finit. Prototipul ofera clientului functionalitati (nu n totalitate) ale viitorului sistem si interfata sa utilizator. Cerintele sunt extrase si validate iterativ prin utilizarea prototipului. In fiecare iteratie specificatia sistemului este modificata si detaliata pana cand prototipul satisface necesitatile utilizatorilor. Un prototip care este utilizat pentru a desprinde cerintele viitorilor utilizatori este o "macheta exploratoare". Activitatea de prototipare poate interveni de asemenea in etapa de proiectare, pentru a experimenta si compara diferite variante. Astfel de prototipuri se numesc "machete experimentale". Dezvoltarea prototipului contine fazele de proiectare, implementare si testare, dar acestea nu sunt foarte riguroase sau formale.

Figura urmatoare reda procesul de prototipare dedicat extragerii cerintelor:

Se recomanda ca prototipul sa fie considerat un sistem "inchis", adica sa nu fie folosit ca baza pentru dezvoltarea aplicatiei deoarece: y prototipul este dezvoltat prin modificari succesive, de aceea arhitectura sa initiala este alterata, ceea ce ngreuneaza intretinerea; y prototipul trebuie sa corespunda cerintelor utilizatorilor numai din punct de vedere functional, motiv pentru care in dezvoltarea sa sunt neglijate aspecte ca: eficienta, adaptabilitatea, compatibilitatea si chiar fiabilitatea.

3.2
y y

Avantaje

Utilizatorii sunt implicati direct in dezvoltare Intampina tendinta utilizatorilor de a-si modifica cerintele, pe parcursul ciclului de implementare Intrucat este lansat un model functional al sistemului, utilizatorii pot intelege mai bine modul de functionare Erorile pot fi detectate mult mai devreme Feedback-ul utilizatorului este mult mai rapid, fapt ce duce la obtinerea de solutii mai bune Timpul si costurile reduse

y y

3.3
y

Dezavantaje

Acest model poate creste complexitatea sistemului, sau acesta se poate extinde dincolo de limitele stabilite initial Analiza insuficienta a proiectului ca un intreg Programatorii pot deveni atasati de un prototip in a carui dezvoltare au investit mult timp si vor tinde sa transforme prototipul intr-un produs final chiar si atunci cand arhitectura de baza nu este cea potrivita Consumul excesiv de timp utilizat pentru implementarea unui prototip.

y y

3.4

Concluzie

Acest model este preferat in cadrul sistemelor mari si complexe, pentru care este dificila elaborarea unei specificatii complete, logice si valide inainte ca sistemul sa fie construit si utilizat. Prin intermediul prototipului, clientul intelege mai bine modul in care lucreaza produsul, intrucat interactioneaza cu acesta pe parcursul intregului ciclu de dezvoltare, furnizand astfel un aport substantial in intelegerea si definirea specificatiilor.

4. Modelul Incremental
4.1
Waterfall.

Descriere
Cu acest model, proiectul este livrat incremental, in functie de prioritatea

Acest model a fost dezvoltat pentru a contracara aparitia tarzie a unui executabil din modelul incrementului. Incrementele ar trebui sa aiba dimensiuni reduse, astfel incat sa existe un timp de la cateva saptamani la maxim doua luni intre lansari. Modelul incremental se bazeaza pe o idee foarte simpla: daca un sistem este prea complex pentru a fi nteles, conceput sau realizat intr-o singura faza este mai bine sa fie realizat in mai multe faze, prin evolutie.

Intr-o faza initiala: y Se studiaza scopul proiectului si fezabilitatea sa. In cazul deciziei de continuare a proiectului: y Se detaliaza cerintele utilizatorilor si se efectueaza o analiza de nivel inalt pentru a se determina cerintele software la un nivel general y y Se determina o arhitectura generala a sistemului Se impart cerintele in subseturi care pot fi implemenate in incremente separate si 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, din care 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 diverse masuri pentru evaluarea evolutiei sistemului: numarul de defecte, efortul de actualizare, dimensiune, complexitatea, cuplarea modulelor. 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. 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 iteratie a ciclului de viata iterativ si incremental reproduce ciclul de viata in cascada la o scara mai mica. Obiectivele unei iteratii sunt stabilite pe baza evaluarii iteratiilor precedente. Documentatia este construita treptat, n timpul fiecarei iteratii. La sfrsitul dezvoltarii, documentele obtinute au aceeasi forma cu cele obtinute n maniera conventionala.

4.2
y y y

Avantaje

Prioritatile cele mai ridicate sunt livrate primele Se efectueaza o livrare la o data la cateva saptamani In fiecare etapa este livrat un produs executabil, care satisface o parte din cerintele utilizator. Feedback-ul obtinut din incrementele anterioare ofera specificatiile pentru incrementele urmatoare Riscul scazut de esec total al proiectului

4.3
y

Dezavantaje

Ciclul de viata Incremental se bazeaza pe evolutia prototipurilor executabile. Din nefericire, programele nu se preteaza n mod natural evolutiei, din contra, ele sunt deseori foarte "fragile" la modificari. Efectul unei modificari locale se poate propaga n ansamblul aplicatiei. Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a programului, facndu-l greu de verificat si de ntretinut. Erorile de proiectare sunt mai greu de eliminat. Clientul poate vedea ce se poate face si poate cere mai mult Se poate sa fie necesara crearea de solutii temporare pentru a putea livra la timp un increment. Abordarea incrementala se poate transforma usor intr-una codifica si repara ( build and fix ) Planificarea devine dificila

y y y

4.4

Concluzie

Modelul incremental este iterativ (ca si modelul prototipului) dar se concentreaza pe livrarea unui produs operational la fiecare increment. Versiunile initiale nu se regasesc in produsul final, dar furnizeaza capabilitati necesare utilizatorului. 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 pentru 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, pentru a construi un plan de dezvoltare. Se stabileste natura fiecarui icrement si ordinea de construire a incrementelor. Acest model este preferat in cadrul sistemelor care evolueaza in timp.

5. Modelul Spirala
5.1 Descriere
Modelul Spirala este o combinatie intre modelul cascada si modelul iterativ. Acest model este focalizat pe analiza riscurilor in mod incremental, repetand modelul cascada intr-o serie de cicluri, ca in figura urmatoare.

Este o imbunatatire a modelului cascada deoarece prevede mai multe livrari si mai multe posibilitati de implicare a clientului. Fiecare ciclu consta din 4 faze. o Planificarea: definirea produsului, determinarea scopurilor si a constrangerilor, generarea alternativelor. o Analiza riscurilor: este cea mai importanta etapa a modelului spirala. In aceasta faza sunt analizate toate alternativele care pot imbunatati costul sau performanta. Daca analiza sugereaza ca cerintele nu au fost clar formulate atunci se poate folosi modelul interativ prin definirea unor prototpuri o Implementarea: proiectarea de detaliu, testarea unitara, integrarea o Evaluarea: evaluarea de catre client, planificarea dezvoltarii si livrarii catre client a urmatorului ciclu. Pasii unei iteratii din modelul Spirala pot fi generalizati astfel: y Cerintele sistemului sunt definite cat de detaliat se poate. Acest lucru presupune de obicei intervievarea unui numar de utilizatori reprezentand utilizatorii interni si externi ai sistemului precum si alte aspecte. y Este creat un design preliminar pentru noul sistem. Aceasta faza este cea mai importanta a modelului. In aceasta etapa, toate alternativele posibile (si disponibile), care pot ajuta

in dezvoltarea unui proiect eficient din punct de vedere al costului, sunt analizate si sunt decise strategiile de abordare. y Este construit un prim prototip al noului sistem din design-ul preliminar. Acesta este de obicei un sistem la scara redusa si reprezinta o aproximare a caracteristicilor produsului final. y Un al doilea prototip este dezvoltat, asfel: o Evaluarea primului prototip in termeni de puncte forte, puncte slabe si riscuri o Definirea cerintelor pentru al doilea prototip o Planificarea si proiectarea celui de al doilea prototip o Construirea si testarea celui de al doilea prototip

5.2
y

Avantaje

Presupune o atitudine pro-activa asupra riscurilor, cu o presupunere explicita a riscurilor si a rezolvarii lor Foarte flexibil Estimarea bugetului devine din ce in ce mai reala pe masura ce se inainteaza in iteratii Modificarile cerute ulterior (invitabil) se pot realiza mult mai usor Programatorii care de obicei stau degeaba in etapele initiale se pot implica inca de la inceput in proiect

y y y y

5.3
y

Dezavantaje

Aproape imposibil de estimat de la inceput timpul si costurile necesare

5.4

Concluzie

Modelul spirala e o abordare potrivita pentru sistemele de mari dimensiuni. Acest model foloseste prototipul ca un mecanism de reducere a riscurilor dar, mai important, permite dezvoltatorului sa aplice abordarea prototipului la orice etapa din evolutia proiectului. Modelul spiral men ine abordarea sugerat de ciclul de viata clasic, dar o incorporeaza intr-un cadru iterativ care reflecta mai realist lumea.

6. Modelul SCRUM
6.1 Descriere
Modelul SCRUM face parte din grupul de metode Agile, care este bazat pe dezvoltarea iterativa si incrementala acolo unde specificatiile si solutiile provin din colaborarea intre echipe autoorganizate si inter-functionale. Aceste metode au la baza 12 principii, sintetizate in asa numitul Agile Manifesto: 1. Satisfacerea clientilor, prin livrarea rapida de software utilizabil 2. Intampinarea modificarii specificatiilor, chiar si tarziu in implementare 3. Software-ul utilizabil este livrat frecvent (la nivel de saptamani) 4. Software-ul utilizabil reprezinta principala masura a progresului 5. Dezvoltare sustinuta, capabila sa pastreze un pas constant 6. Cooperare apropiata intre dezvoltatori si clienti 7. Conversatia fata-in-fata este cel mai bun mod de comunicare 8. Proiectele sunt construite de indivizi motivati, credibili 9. Simplitate 10. Echipe organizate individual 11. Adaptare la circumstante schimbatoare. 12. Atentia constanta pentru excelenta tehnica si design bun.

Valorile SCRUM sunt derivate din cele ale metodologiei AGILE de software development:
y

Indivizii si interactiunea primeaza proceselor si instrumentelor de dezvoltare - desi acestea din urma sunt de folos, nu vor aduce niciun plus in progresul dezvoltarii daca echipa nu invata sa comunice si sa colaboreze intr-o maniera constructiva. Software-ul functional livrat primeaza unei documentatii stufoase - documentarea progresului este importanta, dar este mult mai importat ca rezultatul final sa functioneze conform nevoilor clientului. Colaborarea cu clientul primeaza negocierii de contracte - ideea de baza este ca nu trebuie sa se urmareasca contractarea unui proiect pentru a primi bani, ci pentru a rezolva problema ridicata de client. Raspunde schimbarilor conform planului - daca cerintele se schimba, si planul de proiect si design-ul trebuie actualizate.

Artefacte SCRUM:

Product Backlog o reprezinta totalitatea cerintelor produsului software, prioritizate de client o este dezvoltat de proprietarul produsului o este in continua dezvoltare Sprint Backlog o reprezinta totalitatea cerintelor care se vor implementa intr-o iteratie (sprint) - cerintele transformate in sarcini in cadrul unui sprint Sprint o reprezinta o iteratie cu o perioada fixa de timp (2-4 saptamani) n care trebuie implementat un set fixat de cerinte

o etape sprint o planificare sprint o selectie sarcini de prioritate maxima din product backlog o livrare produs sprint o revizuire rezultate Diagrama Burndown o reprezinta artefactul principal al metodologiei SCRUM o reprezinta progresul zilnic al sprintului raportat la lungimea lui (volumul de munca ramas in functie de timp) o este o coliziune a realitatii cu planificarea

Roluri SCRUM SCRUM Mater o este cel care mentine procesele o este responsabil cu gestionarea procesului si implementarea tehnicilor SCRUM o definste practicile, intalnirile si terminologia o face raportarea sprinturilor o de obicei este managerul de proiect Product Owner o este cel care reprezinta investitorii si afacerea o de obicei este analistul de business o se contreaza pe ROI o gestioneaza product backlog Echipa o un grup de aproximativ 6-8 oameni ce fac analiza, proiectarea si implementarea o se auto-gestioneaza si este interfunctionala o selecteaza cerintele ce vor fi implementate si le duce la bun sfarsit

Procesul de lucru SCRUM In timpul fiecarui sprint (de obicei cu o durata de 2-4 sapatamani), echipa creaza un increment ce poate fi livrat. Setul de caracteristici ce intra intr-un sprint provin din backlog-ul

proiectului, care reprezinta un set prioritizat de cerinte de nivel inalt ce trebuiesc realizate. In timpul unei sedinte de planificare a sprint-ului, se stabilesc cerintele ce vor intra in sprint. Din momentul stabilirii, functionalitatile respective se ingheata. Sprint-ul trebuie sa se incheie la timp. Daca cerintele nu sunt implementate complet, ele se intorc in backlog-ul proiectului. Dupa terminarea unui sprint, echipa trebuie sa demonstreze functionarea software-ului.

6.2
y y y y y y y y

Avantaje

Economisirea de timp si bani Rapiditatea implementarii si usurinta de a corecta eventualele erori Vizibilitate a implementarii proiectului Feedback continuu de la client Usurinta de a face fata schimbarilor Intalnirile zilnice duc la o apreciere mai buna a productivitatii individuale Problemele sunt identificate in fazele de inceput, deci pot fi rezolvate mai rapid Este mai usor sa se livreze un produs de calitate in timpul planificat

6.3
y

Dezavantaje

Daca nu exista o data fixa de finalizare, actionarii proiectului vor tinde sa ceara din ce in ce mai multe functionalitati

Daca membrii echipei nu sunt constiinciosi, proiectul fie va esua, fie nu se va finaliza niciodata

Daca o cerinta nu este bine definita, costurile proiectului si timpul alocat nu pot fi apreciate corect

Este recomandat pentru proiecte mici si rapide, intrucat se pliaza mai bine pe echipe mici de oameni

Daca unul din membrii echipei pleaca in timpul implementarii, acest lucru poate avea efect invers asupra dezvoltarii proiectului.

6.4

Concluzie

Valorile SCRUM: y Indivizii si interactiunea primeaza proceselor si instrumentelor de dezvoltare. Desi acestea din urma sunt de folos, nu vor aduce nici un plus in progresul dezvoltarii daca echipa nu invata sa comunice si sa colaboreze intr-o maniera constructiva y Software-ul functional livrat primeaza unei documentatii stufoase - documentarea progresului este importanta, dar este mult mai importat ca rezultatul final sa functioneze conform nevoilor clientului y Colaborarea cu clientul primeaza negocierii de contracte - ideea de baza este ca nu trebuie sa se urmareasca contractarea unui proiect pentru a primi bani, ci pentru a rezolva problema ridicata de client y Raspunde schimbarilor conform planului - daca cerintele se schimba si planul de proiect si design-ul trebuie actualizate

7. Concluzie
Ciclurile de dezvoltare software sunt soluii ce trebuie abordate in funcie de proiect, echipa, context de business i context al afacerii. Nici un ciclu de dezvoltare software nu exclude fazele eseniale necesare dezvoltarii software orice excludere duce la o scadere a calitaii. n cazul n care proiectul are cerin ele foarte detaliate i clare, termene flexibile, folose te tehnologii bine cunoscute, prezint un grad de complexitate sc zut i schimb rile n specifica ii sunt pu in probabile, se recomanda utilizarea unei metodologii traditionale (ex. Waterfall). n cazul n care proiectul are cerin ele flexibile, termene strnse sau fixe, implic un grad sporit de inova ie, tehnologii noi sau complexe, ori prezint risc ridicat de schimbare a specifica iilor, atunci se recomanda utilizarea unei metodologii Agile (ex: Scrum). Pentru a intelege mai bine impactul pe care il poate avea alegerea unei metodologii gresite de lucru pentru un proiect, precum si impactul deficientelor de comunicare, imaginea de mai jos surprinde toate aceste aspecte: