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

Daca vrei sa afli o cale spre mai bine, e nevoie sa privesti îndelung tot ce este mai rau.
Thomas Hardy


Într-un articol anterior am descris un mic exemplu, ipotetic (exemplul cu proiectul ALPHA) al unui proiect ratat. Spuneam acolo ca, printre altele, echipa de proiect nu a stiut sa abordeze chestiunile de Project Mangement sau Analiza. Cu siguranta ca asa este, dar mai mult decât atât, echipa proiectului ALPHA nu a pornit la drum cu o viziune realista asupra a ceea ce este în lumea reala, a afacerilor, un proiect software si a constrângerilor impuse unui proiect software.

Probabil ca într-o lume ideala, în care programatorii ar fi avut la dispozitie un buget nelimitat, termene nelimitate, o echipa stabila si un set stabil de functionalitati, proiectul s-ar fi sfârsit cu bine. Asta însemnând ca functionalitatile cerute ar fi fost cândva gata, la parametrii de calitate ceruti.


În viata reala însa, lucrurile nu sunt la fel de usoare (vedeti si capitolul Axiome ale dezvoltarii de software!). Proiectul real porneste întotdeauna cu un buget limitat si evolueaza întotdeauna în directia adaugarii de cerinte cât pentru trei bugete (axioma întâia), dar se termina de cele mai multe ori la un nivel de calitate mult sub cel dorit.

Aici este, de fapt, întreaga maiestrie: sa controlezi un proiect real, afectat de multimea de constrângeri, sa controlezi schimbarile permanente, sa negociezi în permanenta succesul.

Acesta este si motivul pentru care adevaratii Project manageri, analisti, arhitecti software sau programatori sunt atât de bine platiti, ceea ce fac ei nu poate fi facut oricum si de catre oricine.


Succesul unui proiect software, pândit din toate partile de o sumedenie de constrângeri, probleme si riscuri se masoara pe trei coordonate: functionalitati, calitate si buget. Încadrarea sau neîncadrarea în limitele stabilite de la început ne dau masura succesului proiectului, iar pastrarea acestei încadrari nu se poate face, în contextul schimbarilor permanente, decât pastrând controlul asupra a ceea ce este important si prin negociere. Ori, doua dintre aceste coordonate (functionalitati si calitate) precum si informatiile pentru a controla si decide asupra schimbarilor provin din analiza. De aici deriva si importanta riscurilor aferente analizei, care atunci când se transforma în probleme concrete au efecte devastatoare asupra întregului proiect.


Pentru a analiza riscurile potentiale ale activitatii de analiza vom porni de la ceea ce ar trebui sa fie într-un proiect. Lucrurile de la care pornim sunt problema clientului si resursele posibil de alocat pentru rezolvarea acesteia:
Riscuri legate de cerinte. Buget subdimensionat, estimare gresita a costurilor

Problema reala a clientului este, de obicei, foarte vasta, mai ales în raport cu bugetul alocat. De aceea, ceea ce trebuie sa fie domeniul problemei pe care îsi propune, în mod realist, sa o rezolve un proiect trebuie negociat astfel încât dezvoltatorul sa nu fie obligat sa lucreze în pierdere (lucru care de obicei degenereaza într-o pierdere de ambele parti) iar clientul sa rezolve cu adevarat problema de baza.

Într-o prima varianta clientul întelege ca solutionarea problemei lui solicita o investitie mai mare si accepta modificarea bugetului pâna la acoperirea întregului necesar:

Clientul accepta modificarea bugetului

În cealalta varianta clientul, constrâns de probleme bugetare, nu poate mari suma alocata si împreuna cu consultantul sau decide sa reduca domeniul problemei la ceea ce îsi permite sa cheltiue (în urma unei analize de impact, fie gaseste acele 20% dintre cerinte care rezolva 80% din problema, fie decide ce este mai important si mai profitabil sa implementeze în acest proiect si ce se poate amâna pentru un alt proiect viitor).

Reducerea domeniului problemei pentru a respecta constrângerea bugetara

În orice caz, la sfârsitul acestei etape presupunem ca avem declarata, chiar în termeni vagi, o anumita problema si avem alocat bugetul adecvat. Desi în realitate este putin probabil sa se ajunga aici, pentru noi aceasta simplificare a modelului este utila pentru întelegerea situatiilor care pot sa apara.

Prin urmare noi vom presupune ca la primul pas am definit (chiar daca destul de vag) domeniul problemei.

Urmatorul pas, culegerea cerintelor este o detaliere a problemei, si rezultatul ei final ar trebui sa fie tot o suprapunere perfecta peste acel domeniu, numit de noi problema reala sau domeniul problemei. În realitate însa nu ne putem astepta la o suprapunere perfecta dar ne propunem, în mod realist, pastrarea unei diferente minimale, controlata, care sa nu afecteze obiectivele de baza ale proiectului.


Situatiile nefavorabile care pot sa apara sunt urmatoarele:

Situatii posibile


A. În prima situatie, cerintele captate nu acopera problema în întregime (anumite lucruri nu se vor rezolva) însa produce costuri considerabile prin includerea unor cerinte inutile sau a unor cerinte care ies din domeniul initial al problemei (probleme reale dar care nu contribuie la rezolvarea problemei).

B. În a doua situatie, cerintele captate si acceptate a fi incluse în proiect depasesc posibilitatile bugetare ale proiectului si va conduce la pierderi financiare, litigii în justitie sau la abateri grave de la calitate.

C. A treia situatie neplacuta, este rezolvarea incompleta a problemei prin omiterea unor cerinte sau întelegerea vaga si incompleta altora sau chiar a problemei.

Continuarea în partea a II-a.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Unde se termină cerinţele clientului şi unde începe designul?
Articolul următor:  Riscuri legate de cerinţe, partea a II-a



  


  Adauga un comentariuSpune-ti parerea despre acest articol!