techIT.ro Do we have a problem? Let's tech it!    












Daca ai impresia ca educatia e scumpa,
atunci încearca sa vezi cum e ignoranta.
Andy McIntyre









Home  |  Dictionar IT  |  Download  |  Forum  |  Despre noi  |  Contact

Dezvoltarea şi Managementul cerinţelor

E bine să folosiţi dezvoltarea iterativă doar în acele proiecte care doriţi să se termine cu bine.
Martin Fowler, UML Distilled


În general, rezolvarea unei probleme noi presupune cel puţin două faze, absolut legitime: informarea la nivel macro (despre ce este vorba?) şi detalierea.
Astfel, abordarea unei probleme face ca în mintea noastră să se creeze un model al problemei reale şi, privind din punctul acesta de vedere, abordarea problemei înseamnă, în prima fază, crearea unui model mental, pornind de la zero, iar în a doua fază, rafinarea şi corectarea acestuia.

Practic, pe baza "simptomelor", a efectelor vizibile ale problemei, în prima fază, printr-un amplu proces de sinteză, în iteraţii succesive, se creează cea mai mare parte a modelului, iar în a doua fază, pe baza cunoştinţelor create anterior, modelul este detaliat şi corectat potrivit realităţii, pe bază de feed-back.

A doua fază este, aşadar, faza în care suntem capabili să luăm decizii, să construim şi să corectăm efectiv. In această fază începe să se nască soluţia. Pornind de la modelul creat în prima fază, cu siguranţă imperfect, se trece la a doua fază, care înseamnă probarea modelului în realitate. Iar realitatea crudă ne va arăta întotdeauna că modelul iniţial nu era tocmai perfect şi că trebuie corectat.


Probabil că unii îşi vor pune întrebarea de ce, dacă tot ştim de la început că în prima fază modelul este imperfect, se trece totuşi la dezvoltarea unei soluţii, înainte de a fi creat un model corect?
În primul rând că această abordare ar prelungi prima fază la nesfârşit, pentru simplul motiv că nu vom putea şti niciodată când am terminat lucrul - când modelul este, în sfârşit, perfect?

De exemplu, pentru a învăţa să înoţi trebuie ca la un moment dat, deşi eşti conştient că nu eşti 100% pregătit, să te expui riscului şi să intri în apă. Oricâtă teorie ai face înainte, oricât te-ai pregăti, numai contactul cu apa este momentul adevărului.
În al doilea rând, nu există nimic inventat până azi care să înlocuiască feed-back-ul. Totul este până la proba realităţii, doar presupunere.

Analiza funcţionează desigur în spiritul celor scrise mai sus (tocmai de aceea le-am scris!). În prima fază se creează un model, toate părţile cad de acord că acela este modelul cel mai potrivit, conform percepţiei lor din acel moment, iar în faza a doua, care începe odată cu semnarea specificaţiilor, modelul este corectat.

Din punct de vedere cantitativ, prima fază aduce cea mai mare parte a informaţiilor, în timp ce a doua parte este înzecit mai redusă. Cineva împărţea foarte inspirat aceste două etape în: (1) pescuitul cerinţelor cu plasa şi (2) pescuitul cerinţelor cu undiţa.

Ca o precauţie, nu porniţi niciodată cu ideea că puteţi face de la început o specificaţie perfectă. Este exclus şi, uneori, chiar periculos să se creeze aşteptări nerealiste. Întotdeauna, cerinţele se vor modifica pe parcursul derulării proiectului.

Prin urmare, în aproape toate abordările, procesul de Analiză este împărţit în două faze mari (fiecare dintre ele are în interior propriul set de iteraţii): A. Dezvoltarea cerinţelor – etapă care are ca scop crearea modelului iniţial;
B. Managementul cerinţelor - etapă care are ca scop introducerea schimbării, în mod controlat, în proiect, astfel încât să fie respectate restricţiile externe (buget, calitate, resurse umane).
Dezvoltarea şi managementul cerinţelor software

A doua fază implică întotdeauna şi activităţi care nu sunt specifice analizei şi necesită participarea substanţială a managementului de proiect (negocierea cerinţelor, renegocierea bugetelor etc.).

Aşa cum se poate vedea în figura de mai sus, etapa de dezvoltare a cerinţelor porneşte de la culegerea brută a cerinţelor şi analiza acestora, până la realizarea modelului viitoarei aplicaţii (documentul / documentele de specificaţii) şi validarea acestui model prin review-uri interne sau la client.

Într-o abordare iterativă a proiectului, grupele de cerinţe pot evolua cu viteze diferite între aceste stadii. De exemplu, în timp ce cerinţele privind gestiunea stocurilor se află în faza incipientă, de culegere a informaţiilor, specificaţia pentru un o altă grupă de cerinţe, să zicem cele privind producţia, poate fi într-un stadiu mult mai avansat, de pildă în faza de concepere a arhitecturii de bază.



Culegerea cerinţelor se bazează, în principal, pe interviurile realizate la client dar poate să însemne, de la caz la caz utilizarea unor surse diferite precum: caiete de sarcini, proceduri de lucru, descrieri de proces, legislaţie, urmărirea derulării unor procese şi aşa mai departe. Deoarece discuţiile faţă în faţă cu clientul sunt şi cea mai importantă sursă cât şi cea mai dificil de exploatat şi mai plină de învăţăminte, o vom trata pe larg în capitolul privind Realizarea interviurilor.


În privinţa analizei cerinţelor, aceasta îşi propune:
- subordonarea cerinţelor la obiectivele de business (vă recomand relectura capitolului privind Descompunerea problemelor), pe baza raţiunii de a fi a fiecărei cerinţe;
- validarea cerinţelor din punctul de vedere al caracteristicilor lor (capitolul Caracteristicile cerinţelor software);
- prioritizarea cerinţelor;
- determinarea dependenţei între cerinţe (modul în care cerinţele depind unele de altele).

Privind problema simplificat, acestea sunt lucrurile pe care trebuie să le faceţi în cadrul acestei activităţi premergătoare, sau alipite, redactării specificaţiei. Rezultatele acestei analize sunt vizibile în mod nemijlocit şi imediat în specificaţie.
Dar, repet, aceasta este o abordare simplificată a analizei cerinţelor, văzută în sensul restrâns de activitate premergătoare redactării specificaţiei. În sens larg, analiza înseamnă tot restul, iar obiectivul ultim al analizei, chiar dacă e vorba de analiza unei singure cerinţe, îl reprezintă succesul proiectului - nimeni nu poate face analiză mărginindu-se la acest capitol.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Caracteristicile cerinţelor software
Articolul următor:  Realizarea interviurilor la client



  


  Adauga un comentariuSpune-ti parerea despre acest articol!