Ati proceda la fel daca ati construi un site web de prezentare a unei firme si un program software pentru conducere a avioanelor? Bineinteles ca nu. Veti proceda diferit, intrucat si proiectele respective impun un efort de munca si un grad de risc diferit. In acest scop, va va fi de ajutor cunoasterea principalelor metodologii de lucru, astfel incat proiectul dumneavoastra sa se bucure de succes.
O metodologie de lucru pentru un produs software reprezinta modul de structurare, planificare si control al procesului de dezvoltare.
Pentru a intelege mai bine ce inseamna o metodologie de lucru, iata cativa termeni ce sunt utilizati frecvent in acest domeniu:
- Metodologie (sau metoda) – o anumita colectie de principii si/sau practici
- Familie de metodologii – un set de metode alternative care coexista
- Framework – un schelet (pentru metode) care trebuie dezvoltat/personalizat inainte de utillizare
- Model – o descriere (pentru metode) care trebuie implementata de o metoda, familie sau framework.
Pentru cei care sunt mai familiarizati cu limbajul software! O metodologie este asemanatoare unei clase ce poate fi instantiata pentru un anumit proiec. O familie de metodologii este asemanator cu un namespace de clase diferite dar comparabile. Un framework se aseamana cu o clasa abstracta care trebuie mai intai mostenita si extinsa. Un model este asemanator unei interfete ce reprezinta doar o descriere a “ceva” ce trebuie implementat de una sau mai multe clase.
In continuare urmeaza descrierea unora dintre cele mai importante metodologii pentru crearea de software.
Modelul Waterfall sau modelul Cascada:
Modelul Waterfall reprezinta un proces de implementare secvential, utilizat deseori in procesul de dezvoltare software. Are mai multe faze: Cerinte, Proiectare, Implementare, Integare si Mentinere.

In faza de Cerinte sunt stabilite toate cerintele posibile ale sistemului ce se doreste implementat. Cerintele sunt culese de la utilizator prin consultarea acestuia, dupa care este analizata posibilitatea de incorporare a lor in produsul dorit. La final este redactat un document cu aceste cerinte, ce va servi ca 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 in specificarea cerintelor de sistem si hardware, precum si in definirea arhitecturii de ansamblu. Rezultatul acestei etape se concretizeaza in redactarea unui document ce cuprinde specificatiile de proiectare.
In continuare, se trece la etapa de Implementare. Dupa terminarea proiectarii, munca este divizata in module si incepe adevarata implementare a 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 software apar dupa ce el incepe sa fie utilizat, astfel incat problemele vor fi rezolvate dupa lansarea produsului.
Printre avantajele acestui tip de model, se pot mentiona:
- Documentatia si proiectarea structurii 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.
- Este recomandat pentru proiectele mici, in care cerintele sunt foarte bine intelese.
Printre dezavantajele acestui tip de model, se numara:
- 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.
- Problemele din cadrul unei etape nu sunt niciodata rezolvate complet in cadrul aceleiasi etape
- Partitionarea in etape a proiectului nu este flexibila
- Intrucat clientul poate adauga noi cerinte, acestea nu pot fi implementate in aceeasi editie a produsului. Prin urmare, va fi nevoie de costuri suplimentare pentru implementarea cerintelor nou adaugate.
- Este dificil sa se faca o estimare corecta a timpului si costului alocat pentru fiecare etapa.
- Un produs functional finit este obtinut tarziu, comparativ cu momentul de inceput al proiectului.
Modelul Prototip:

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. Acesta este dezvoltat pe baza cerintelor cunoscute in prezent. Dezvoltarea prototipului contine fazele de proiectare, implementare si testare, dar acestea nu sunt foarte riguroase sau formale.
Prin intermediul prototipului, clientul intelege mai bine modul in care lucreaza produsul, intrucat interactioneaza cu acesta pe parcursul intregului ciclu de dezvoltare.
Acest model este preferat in cadrul sistemelor mari si complicate, pentru care este dificila intelegerea cerintelor de la inceput. In astfel de situatii, accesul clientului la prototip furnizeaza un aport substantial in intelegerea si definirea specificatiilor.
Avantajele acestui tip de model sunt:
- 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
Printre dezavantaje, merita mentionate:
- 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.
Modelul incremental:

Acest model a fost dezvoltat pentru a contracare aparitia tarzie a unui executabil din modelul Waterfall. El reprezinta o evolutie a modelului Waterfall. Cu acest model, proiectul este livrat incremental, in functie de prioritatea incrementului. Incrementele ar trebui sa aiba dimensiuni reduse, astfel incat sa existe un timp de la cateva saptamani la maxim doua luni intre lansari.
Avantaje ale modelului incremental:
- Prioritatile cele mai ridicate sunt livrate primele
- Se efectueaza o livrare la o data la cateva saptamani
- Feedback-ul obtinut din incrementele anterioare ofera specificatiile pentru incrementele urmatoare
- Riscul scazut de esec total al proiectului
- Incrementele cu prioritate mai mare tind sa aiba parte de cea mai multa testare
Dezavantaje ale modelului incremental:
- Se poate sa fie necesara crearea de solutii temporare pentru a putea livra la timp un increment.
- O mare parte a codului poate fi inlaturata
- Planificarea devine dificila
Acest model este recomandat pentru proiectele care evolueaza in timp.
Modelul Spirala:

Pasii unei iteratii din modelul Spirala pot fi generalizati astfel:
1. 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.
2. 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 a costului sunt analizate si sunt decise strategiile de abordare.
3. 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.
4. Un al doilea prototip este dezvoltat, asfel:
a. Evaluarea primului prototip in termeni de puncte forte, puncte slabe si riscuri
b. Definirea cerintelor pentru al doilea prototip
c. Planificarea si proiectarea celui de al doilea prototip
d. Construirea si testarea celui de al doilea prototip
Avantaje:
- Presupune o atitudine pro-activa asupra riscurilor, cu o presupunere explicita a riscurilor si a rezolvarii lor
- Foarte flexibil
Dezavantaje:
- Aproape imposibil de estimat de la inceput timpul si costurile necesare.
Metodele Agile:
Grupul de metode Agile este bazat pe dezvoltarea iterativa si incrementala acolo unde specificatiile si solutiile provin din colaborarea intre echipe organizate individual, dar care au acelasi scop comun.
Aceste metode au la baza 12 principii, sintetizate in asa numitul “Agile Manifesto”, emis in februarie 2001:
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.
Printre cele mai importante metode Agile, enumeram SCRUM si XP (Extreme Programming).
SCRUM:

SCRUM este un schelet ce contine un set de practici si diferite roluri. Principalele roluri din SCRUM sunt:
- “Scrum Master” – este cel care mentine procesele
- “Detinatorul produsului” – cel care reprezinta investitorii si afacerea
- “Echipa” – un grup de aproximativ 7 oameni ce fac analiza, proiectarea si implementarea
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. Cerintele sunt “inghetate” in timpul unui sprint. 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.
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
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.
EXTREME PROGRAMMING
Prin Extreme Programming se incearca reducerea costurilor impuse de modificarea cerintelor prin efectuarea de mai multe cicluri de implementare mai scurte in locul unuia lung. In aceasta metodologie, schimbarile sunt un aspect natural si ar trebui planificate in loc de a incerca stabilirea unui set fix si stabil de cerinte.
Extreme Programmig, sau XP, descrie patru activitati de baza, care sunt realizate in timpul procesului de dezvoltare al software-ului:
- Scrierea codului – sustinatorii XP sunt de parere ca singurul produs cu adevarat important al procesului de dezvoltare este codul. Fara cod, nu exista un produs viabil.
- Testarea – abordarea XP este aceea ca, daca putina testare poate elimina putine erori, mai multa testare poate elimina mai multe erori.
- Ascultarea – programatorii trebuie sa asculte ce doresc clientii sa faca sistemul. Trebuie sa inteleaga aceste cerinte suficient de bine pentru a da feedback clientului cu privire la aspectele tehnice ce pot fi rezolvate sau nu.
- Proiectarea – se promoveaza crearea unei structuri logice a proiectului, pentru a evita un numar mare de dependente in proiect si pentru a usura implementarea eventualelor modificari.
Avantaje:
- XP livreaza proiectari si software de calitate in timpul programat realist
- Un nivel ridicat de calitate prin testarea in intregime a tuturor aspectelor
- Incurajarea lucrului in echipa – programatorii lucreaza in perechi in care ambii au un singur monitor si o tastatura
- Nivel sporit de satisfacere a clientului, datorita modului in care sunt captate cerintele acestuia
- Design-ul este simplu – proiectarea nu se face pentru ceva viitor si pentru ceva prezent
- Test-case-uri usor de inteles
- Intregul proces de dezvoltare este vizibil si masurabil
Dezavantaje:
- este greu de realizat Extreme Programming – este dificila strangerea unui numar de programatori care sa accepte aceasta practica si este nevoie de multa disciplina pentru ca toti sa duca la bun sfarsit un proiect cu aceasta abordare
- software-ul din ziua de astazi este foarte mare si complex, lucru ce face grea proiectarea incrementala abordata de XP
- XP pune accent pe refactorizarea in timpul procesului de implementare, fapt ce poate scadea din productivitatea altor aspecte
- Dezvoltare bazata pe cod, in loc sa fie bazata pe proiectare
- Lipsa documentatiei de proiectare
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:
