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

Riscuri legate de cerinţe, partea a II-a

Acest articol este continuarea de la partea I.

La ce efecte negative ne putem aştepta?

Prin urmare, oricare dintre variante poate conduce la următoarele efecte negative:
- dezvoltarea unor funcţionalităţi inutile;
- dezvoltarea unor funcţionalităţi utile dar în afara domeniului problemei, care ridică probleme de buget;
- omiterea unor funcţionalităţi necesare sau chiar esenţiale.


Am numit aceste rezultate negative „efecte negative” pentru că lucrul către care trebuie să ne îndreptăm sunt de fapt cauzele de la baza întregului fenomen negativ.

Recapitulând, efectul ultim este nereuşita proiectului în ceea ce priveşte atingerea obiectivelor legate de funcţionalităţi, calitate şi buget (simultan), iar din punct de vederea al analizei cerinţelor aceasta porneşte de la dezvoltarea unor funcţionalităţi inutile, dezvoltarea unor funcţionalităţi necesare dar din afara domeniului problemei şi omiterea unor funcţionalităţi necesare. La rândul lor aceste fenomene pornesc de la un set de cauze, aşa cum sunt descrise în tabelul de mai jos:

CauzeEfect negativ
- înţelegerea slabă a problemei clientului, a raţiunii proiectului;
- insuficienta implicarea a clientului;
- cerinţe ambigue;
- adăugarea necontrolată a unor cerinţe a căror raţiune este neclară;
- dezvoltarea unor funcţionalităţi inutile;
- înţelegerea slabă a problemei clientului, a raţiunii proiectului;
- supraîncărcarea proiectului cu cerinţe, din cauza pierderii controlului asupra schimbărilor;
- dezvoltarea unor funcţionalităţi necesare dar din afara domeniului problemei;
- înţelegerea slabă a problemei clientului, a raţiunii proiectului;
- insuficienta implicarea a clientului;
- cerinţe ambigue, specificaţii incomplete;
- omiterea unor funcţionalităţi necesare;


Între cauzele prezentate mai sus "înţelegerea slabă a problemei clientului", deşi poate să pară puţin surprinzătoare este un fenomen foarte des întâlnit.
Pur şi simplu, întrebaţi membrii unei echipe de dezvoltare "de ce se dezvoltă acest proiect?" sau "de ce clientul dă bani pe acest soft?".

Veţi fi surprinşi să aflaţi că acel proiect se dezvoltă pentru că "aşa avem contract cu clientul" (păi nu...!?) sau "nu ştiu, dar dacă clientul plăteşte... e treaba lui", ori "pentru că aşa trebuie, nu poţi să rămâi în urmă cu tehnologia".
Cel mai dramatic este atunci când asemenea răspunsuri vin de la persoane care sunt analişti sau project manageri, încât te întrebi, firesc, cum se stabilesc acolo priorităţile şi pe ce bază se negociază schimbările?


Mai multe despre rolul clientului

Încă de la primele articole spuneam că "insuficienta implicarea a clientului" este prima cauză pentru problemelor privind calitatea şi livrarea la timp, în proiectele software.

Altfel spus, situaţia normală ar fi aceea în care clientul este actorul principal în definirea cerinţelor – proiectul de dezvoltare fiind proiectul în primul rând al lui, nu al echipei de dezvoltare. Nimic din ceea ce este cerinţă pentru viitorul sistem nu trebuie presupus şi de asemenea, nici-o schimbare a cerinţelor nu se presupune a fi acceptată fără consultarea clientului şi explicarea impactului schimbării.

În permanenţă analistul trebuie să fie primul care îşi doreşte să obţină feed-back de la client, chiar dacă acesta este negativ (doar feed-back-ul negativ îţi garantează corectarea traiectoriei atunci când ai pornit pe un drum greşit). Acesta este modul de lucru principal al analistului, mecanismul de corectare şi de finisare a specificaţiei.

Dacă aţi lucra cu metal, lemn sau piatră aţi avea, cu siguranţă instrumente specifice pentru corectarea erorilor şi pentru şlefuirea materialului, atunci când lucraţi cu informaţie, instrumentul de care aveţi nevoie, se cheamă feed-back.


Cerinţele ambigue sunt acelea care pot fi interpretate în mai multe feluri fără faultarea logicii.
Tuturor ne scapă asemenea lucruri, pentru că noi ştim ce vrem să spunem şi "înţelegem" chiar dintr-o frază pe care o construim prost. Mai mult, chiar în comunicarea între două persoane se pot transmite lucruri ambigue pentru că cel care recepţionează un mesaj crede că a înţeles ceea ce trebuie. Atâta timp cât el crede sincer că a înţeles ce trebuie, e chiar dificil să depistezi ambiguitatea.

Totuşi, posibilităţi de depistare a ambiguităţilor există. Folosiţi use case-uri, organizaţi review-uri formale ale specificaţiilor, trimiteţi responsabililor de la testare specificaţia pentru crearea planului de teste, înainte de a se dezvolta aplicaţia şi insistaţi să se scrie prima versiune a manualului de utilizare pe baza specificaţiei.

Mai ales cerinţele neclare, dificile, acelea de care îţi vine, mai degrabă să scapi cât mai repede decât să insişti pentru clarificarea lor, trebuie avute în vedere aici. Nici-o ambiguitate nu va scăpa până la sfârşit (acceptanţa!) – orice datorie neplătită va fi plătită la un moment dat, dar cu o penalizare mult mai mare.


În privinţa chestiunii "adăugării necontrolate a unor cerinţe a căror raţiune este neclară" putem spune că orice cerinţă a cărei raţiune nu este clară, nu ar trebui, de fapt, să fie considerată cerinţă. La fel ca la raţiunea proiectului, dacă răspunsul la întrebarea "de ce?" este ceva de genul "pentru că aşa vrea clientul ...", acea cerinţă este incomplet înţeleasă.

În acest grup intră cu succes unele funcţionalităţi de tip nice to have propuse de dezvoltatori sau de utilizatori, precum "îmbunătăţiri" ale interfeţei utilizator, sau "îmbunătăţiri" mânate de dorinţa utilizării unei tehnologii noi, proaspăt descoperită de programator. Am participat, aici în România, un proiect la care utilizarea XML-ului a fost motivaţia complicării inutile a proiectului, a adăugării unor funcţionalităţi doar pentru că "XML-ul permite", lucruri care au condus la un eşec aproape total al proiectului. După părerea mea, cel puţin jumătate din funcţionalităţile dezvoltate în acel proiect au fost inutile.


Ultima chestiune pusă în discuţie, "supraîncărcarea proiectului cu cerinţe, din cauza pierderii controlului asupra schimbărilor" nu este deloc cea din urmă.

Dimpotrivă, prin faptul că este o permanenţă în proiectele software (axioma A1: întotdeauna cerinţele se schimbă pe parcursul derulării proiectului...), prin efectele devastatoare (apropo de axioma A6: nici un proiect software nu dispune de un buget nelimitat...) această chestiune este una vitală. Dacă lucraţi într-un proiect mare, ignoraţi-o şi veţi pierde!

Vestea proastă este că factorul care generează această problemă, este schimbarea cerinţelor, lucru care nu poate fi evitat, şi că impunerea controlului asupra schimbării cerinţelor este un lucru greu de realizat şi nu se poate face decât prin respectarea riguroasă a unei proceduri de includere a schimbărilor în proiect. Pentru fiecare schimbare trebuie evaluat impactul asupra întregului (lucru care, în sine, costă) şi trebuie decis dacă cerinţa poate fi inclusă în proiect, dacă este necesară modificarea sau eliminarea altor cerinţe, renegocierea bugetului sau a termenelor.

De asemenea, procedura de control al schimbării cerinţelor trebuie respectată de ambele părţi, atât dezvoltator cât şi client. Nimeni nu poate schimba cerinţele fără respectarea procedurii (decât, poate, în măsura în care schimbă automat şi bugetul şi termenele la niveluri acoperitoare).

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Riscuri legate de cerinţe
Articolul următor:  Cerinţele nefuncţionale



  


  Adauga un comentariuSpune-ti parerea despre acest articol!