Tema de casa-Inginerie Software-

Estimarea cost a software-ului

Studenti:Birsan Ruben-Titi 442AManuca Adrian Ionut 441AMarica Iulia 442ASerban Andrei Gabriel 442AManea Constantin 442A

Cuprins

1.Introducere ……………………………………………………………………………… 3

- Responsabilii in estimarea unui produs software ...…………………………………… 5

- Factorii care contrubuie la estimarea inexacta …………………………………………. 6

- De ce este estimarea atat de dificila? ……………………………………………………. 6

2.Metode de estimare ……………………………………………………………………... 7

- Metode de estimare non-algoritmice …………………………………………………… 11

3.Metode algoritmice clasice …………………………………………………………...… 13

4.Metode algoritmice moderne …………………………………………………………... 14

- Modelul Walston-Felix …………………………………………………………………. 16

- Modelul COCOMO ……………………………………………………………………... 17

- Analiza punctelor functionale ..……………………………………………………….. 18

5. Distribuirea fortei de munca in timp …………………………………………………. 20

6. Organizarea echipei software …………………………………………………………. 23

7. Concluzii ………………………………………………………………………………... 29

8. Bibliografie ……………………………………………………………………………... 30

Birsan Ruben-TIti1.Introducere- Responsabilii in estimarea unui produs software- Factorii care contrubuie la estimarea inexacta- De ce este estimarea atat de dificila?Manuca Adrian Ionut2.Metode de estimare- Metode de estimare non-algoritmiceMarica Iulia3.Metode algoritmice clasice4.Metode algoritmice moderne- Modelul Walston-Felix- Modelul COCOMO- Analiza punctelor functionaleSerban Andrei Gabriel5. Distribuirea fortei de munca in timpManea Constantin6. Organizarea echipei software7. Concluzii

2

Estimarea cost a software-ului

1. Introducere

La fel cum de obicei trebuie determinate greutatea, volumul, și caracteristiciledinamice de zbor ale unui avion de dezvoltare, ca parte a procesului de planificare, estenevoie sa fie determinat cat de mult software trebuie realizat. Unul dintre principalelemotive pentru care programele software nu reusesc este incapacitatea noastră de aestima cu exactitate dimensiunea software-ului. Pentru că, aproape întotdeauna seestimeaza dimensiunea prea mică, software-ul nu este finanțat în mod adecvat sau nu iieste dedicat suficient timp pentru dezvoltare. Estimările sărace ale dimensiunii sunt, deobicei principala cauza a costului ridicat și depășirii timpului alocat.

Estimarea costurilor unei aplicatii software reprezinta un domeniu mai putinformalizat, care se bazeaza mai mult pe aproximari. Exista totusi o serie de metode carepermit estimarea costului total pentru un proiect software pe baza unui numar limitat degeneratori relevanti de costuri. În cele mai multe modele de estimare, este presupusa orelatie simpla între cost si efort. Efortul poate fi masurat de exemplu în luni-om (adicanumarul estimativ de luni necesar unui singur om sa realizeze lucrarea), si fiecarei luni-om i se asociaza o suma fixa de bani, corespunzator salariului angajatilor. Costul totalestimat se obtine înmultind numarul estimat de luni-om cu factorul constantconsiderat.Notiunea de cost total reprezinta de obicei costul efortului initial dedezvoltare software, costul analizei cerintelor, proiectarii, implementarii si testarii, faraa fi luate în considerare costurile de întretinere. Notiunea de cost, care se va folosi încontinuare, nu include si posibilele costuri hardware, ci numai costurile legate depersonalul angajat în dezvoltarea produsului software.

Estimarea costurilor software-ului este procesul de prezicere a efortului necesarpentru a dezvolta un produs software. Au fost propuse de-a lungul ultimilor 30 de animulte modele de estimare.Această lucrare oferă o prezentare generală a metodelor deestimare a costului produselor software,inclusiv recentele progrese în domeniu.Uneledin aceste modele se bazează pe o estimare a dimensiunii software-ului de intrare. Se vaprezenta mai întâi o imagine de ansamblu a metricilor de dimensiune uzuale. Se vorevidenția mai apoi modelele de estimare de cost care au fost propuse și utilizate cusucces. Modelele pot fi clasificate în două mari categorii: algoritmice și non-algoritmice.Fiecare model are propriile sale forte și punctele slabe. Un factor-cheie înselectarea unui model de estimare a costuli este acuratețea estimărilor sale. Din păcate,în ciuda corpului mare deexperiența cu modele de estimare, acuratețea acestor modelenu este satisfăcătoare.

Estimarea resurselor necesare și a timpului sunt foarte importante pentru toateproiectele, dar mai ales în cadrul sistemelor informatice, în cazul în care bugetul șiprogramul sunt de obicei depășite.Toate metodele de estimare trebuie să se ia careferință o dimensiune metrica a software-ului. Estimarea proiectelor software prezintadificultati speciale,în comparație cu alte sectoare. Metodele de estimare existente suntextrem de dependente de informatiile disponibile pentru proiect. Când proiectul esteimpartit in mai multe etape,estimarea este mai precisă, deoarece există mai multeinformații și este mai fiabil. Procesul de estimare ar trebui să fie un proces continuu,

3

incluzand noi informații.Acest lucru stabileste o metodă de estimare de costuri alesoftware-ului bazată pe tehnici de inteligență artificială (AI),identificând factorii careinfluențează cel mai mult și cei variabili in costul software-ului. Munca se face pe bazaunui set de date din proiectele trecute, luând datele furnizate de International SoftwareBenchmarking Standards Group (ISBSG), care a colectat informații de la mai mult de2000 de proiecte. Acest set de date conține valori numerice, precum și date categoriale.

Estimarea costurilor implica ipoteze si dezvoltarea unei aprecieri aproximative acosturilor resurselor necesare pentru completarea tuturor activitatilor proiectului. Inaproximarea costului, cel care estimeaza ia in considerare cauzele variatiei estimarilorfinale cu scopul conducerii mai bune a proiectului. Cand un proiect se desfasoara pebaza de contract, trebuie avut grija sa se faca distinctie intre estimarea costurilor sipreturi. Estimarea costurilor urmareste stabilirea cu aproximatie a bugetului; cu luareain considerare a diferitelor alternative de cost prin care resursele necesare estimate safinalizeze cu succes proiectul.

Estimarea costurilor implica dezvoltarea unei evaluari cantitative a rezultatului.Se pune adesea intrebarea: care este costul suportat de organizatia furnizoare penru aproduce serviciul sau produsul ce urmeaza a fi realizat? Penru atingerea potentialului descadere a costurilor se stabilesc o serie de responsabilitati le nivelul fiecaruidepartament al unitatii economice. De exemplu:

- pentru o reducere a costurilor de pana la 20%, conducatorul de proiect poateapela la o serie de modificari constructive;

- cel care realizeaza fabricatia poate actiona la randul lui prin reducereacosturilor de productie de pana la 15%;

- departamentul de aprovizionare poate realiza o reducere a costurilor in jurulvalorii de 10% pentru achizitiile facute, precum si prin reducerea stocurilor de materiiprime, materiale si echipamente ca urmare a unei aprovizionari ritmice de la parteneri;

Stabilirea pretului de vanzare este o decizie de afaceri. Piata este aceea care areun rol deosebit in formarea costurilor scop ale produsului. In timp ce vanzatorulstabileste pretul de jos in sus (bottom-up) cumparatorul calculeaza pretul de sus in jos(top-down). De aceea piata este aceea care stabileste echilibrul. Cat permite piata saofere pe noul produs? Cat cere organizatia furnizoare pe produsul sau, sau pentruserviciul prestat tinand seama de potantialii concurenti si cat este dispus sa plateascaclientul? Asupra costului tinta (target-costing) pe care vrea sa-l obtina producatorul prinlansarea noului produs pe piata,se recomanda cu consacventa nu numai scadereacosturilor de productie ci si costurile de reprezentanta si vanzare.

Fig.1 Estimarea costurilor in dezvoltarea de produs

4

În ultimii ani, software-ul a devenit cea mai scumpa componenta a unui proiectde sistem informatic. Cea mai mare parte a costurilor de dezvoltare de software sedatorează efortului uman, iar cele mai multe metode de estimare a costurilor seconcentreza asupra acestui aspect și se fac estimări în ceea ce privește relatia persoana-luni. Estimările exacte a costului de software sunt critice si pentru dezvoltatori și pentruclienții. Ele pot fi folosite pentru generarea de cereri si propuneri de proiecte,negocierea de contracte, planificare, monitorizare și control. Subestimarea costurilorpoate duce la gestionarea si aprobarea sistemelor propuse, care depășesc bugetele lor,au funcții subdezvoltate, precum si de calitate slabă, și incapacitatea de a fi terminate latimp. Supraestimarile poate duce la prea multe resurse folosite la proiect, sau prea multtimp acordat contractului, rezultand pierderea contractului, care poate duce la pierdereade locuri de muncă.

Estimarea costurilor de precisa este importanta deoarece:

- poate ajuta să se clasifice și să se prioritizeze proiectele de dezvoltare cuprivire la un plan de afaceri mare.

- poate fi utilizata pentru a determina ce resurse să se angajeze în proiect șimodul în care aceste resurse vor fi utilizate.

- poate fi folosita pentru a evalua impactul modificărilor și a oferi suport incazul unei replanificari.

- proiectele pot fi mai ușor de gestionat și controlat atunci când resursele suntmai bine adaptate la nevoile reale.

- clienții așteaptă costurile reale de dezvoltare pentru a fi în acord cu costurileestimate.

Estimarea costurilor software-ului consta in a determina una sau mai multedintre următoarele estimări:

- efortul (de obicei, în persoana-luni)

- durata proiectului (în timp calendaristic)

- costul (în dolari)

Responsabilii in estimarea costului unui produs software

Grupul de persoane responsabile pentru crearea estimarilor a costurilorsoftware-ului poate varia în funcție de fiecare organizație. Cu toate acestea, următoarelecazuri sunt posibile în majoritatea scenariilor.

- oamenii care sunt direct implicati în punerea în aplicare a proiectului suntimplicati în estimare;

- managerul de proiect este responsabil pentru producerea de estimări alecostului realiste;

- managerii de proiect pot efectua această sarcină pe cont propriu sau se potconsulta cu programatorii responsabili.

- diferite studii arată că, dacă programatorii responsabili pentru dezvoltareeproduselor softwere sunt implicati în estimare, estimarea a fost mai precisă.Programatorii au motivație mai multa pentru a îndeplini obiectivele în cazul în care aufost implicați în procesele de estimare.

5

Următoarele scenarii sunt posibile, de asemenea:

- o echipa independenta de estimare costurilor poate realiza o estimare

- experți independenți dau caietul de sarcini software și creează o estimare acostului proiectului. Echipa de estimare cerceteaza acest lucru și tot grupul aunge la unconsens formand o decizie finală.

Factorii care contribuie la estimarea inexacta- scop imprecis,cerinte imprecise

- noile proiecte de software reprezintă noi provocări, care pot fi foarte diferite deproiectele anterioare

- multe echipe nu reușesc să documenteze valorile și sa isi asimileze lecțiileînvățate din proiectele anterioare

- de multe ori estimările sunt forțate să se potrivească timpului disponibil șiresurselor de către liderii agresivi

- estimările nerealiste pot fi create prin diferite ”politici curente”

Impactul subestimarilor – subestimarile unui proiect por fi foarte daunatoare

- aceasta duce la planificarea necorespunzatoare a proiectelor

- aceasta poate duce, de asemenea, la detinerea de personal putin și poate duce lao supraincarcare a membrilor echipei care lucreaza

- mai presus de toate calitatea produsului software poate fi direct afectată dincauza insuficientelor teste facute pe produsul software

- nerespectarea termenelor limita duce la pierderea de credibilitate

De ce este estimarea atat de dificila?Principala întrebare, atunci când se confruntă problemele menționate mai sus,

este ceea care face estimarea costurilor software-ului atât de dificila. Există multemotive și, fără a intra în detalii, unele pot fi enumerate după cum urmează:

- există o lipsă de date privind proiectele software finalizate anterior . Acest tipde date poate sprijini managerul de proiect în a face estimări.

- estimările sunt de multe ori facute în grabă, fără o apreciere pentru efortulnecesar pentru a face un loc de muncă credibil. În plus, de prea multe ori este cazul încare o estimare este necesară înainte de specificațiile clare ale cerințelor de sistem. Deaceea, o situație tipică este că estimatorii sunt presați să scrie o estimare prea repedepentru un sistem pe care nu il înțeleg pe deplin.

- specificațiile clare, complete și fiabile sunt dificil de formulat, în special laînceputul unui proiect. Modificările completările si adaptările sunt mai mult regulădecât o excepție; de asemena, pe parcurs trebuie să fie adaptate planurile de consecintasi bugetele.

6

- caracteristicile software-ului și dezvoltarea de software fac estimarea dificilă.De exemplu:nivelul de abstractizare, complexitatea, măsurabilitate al produsului șiprocesului, aspectele inovative, etc.

- un număr mare de factori au o influență asupra efortului și timpului necesarpentru a dezvolta software-ul. Acești factori sunt numiti "drivere de cost". Exemple suntdimensiunea și complexitatea software-ului, angajamentul și participarea organizației deutilizare, experienta echipei de dezvoltare.

- schimbările rapide în tehnologia informației (IT) și metodologia de dezvoltarede software sunt o problemă pentru o stabilizare a procesului de estimare.

- un estimator (care in general esta managerul de proiect) nu poate avea multăexperiență în estimările în curs de dezvoltare, în special pentru proiecte mari. Câteproiecte "mari" poate cineva gestiona, de exemplu in 10 de ani?

- un estimator este probabil să ia în considerare cât de mult timp ar lua o anumităparte a software-ului și apoi să extrapoleze această estimare pentru restul sistemului,ignorând aspectele non-lineare de dezvoltare de software, de exemplu, coordonarea șimanagementul.

- estimatorul estimează timpul necesar pentru a îndeplini sarcina personal,ignorând faptul că o mare parte din muncă va fi realizata de către persoane cu maipuțină experiență, și personalul junior, cu o rată mai mică productivitate.

- estimatorul tinde să reducă estimările într-o oarecare măsură, în scopul de aface oferta mai acceptabila.

2. Metode de estimare

Cercetarile în domeniul estimarii costului sunt departe de a fi cristalizate.Diferite modele folosesc diferite sisteme de masura si generatori de costuri, încât estedificila compararea lor. Sa presupunem ca un model foloseate o ecuatie de forma:

E = 2.7 . KLOC1.05

Acesta ecuatie arata o relatie între efortul necesar si marimea produsului (KLOC= KiloLinesOf Code, kilo-linii de cod). Unitatea de masura a efortului poate fi numarulde luni-om necesare. Pentru a determina ecuatiile unui model algoritmic de estimare acostului, putem urma diferite abordari. În primul rând ne putem baza ecuatia perezultatul experimentelor. Într-un asemenea experiment, în general variem unparametru, în timp ce ceilalti parametri ramân constanti. În acest fel încercam sadeterminam influenta pe care o are parametrul care variaza. Un exemplu tipic este cel cetesteaza daca comentariile ajuta la întelegerea unui program. Vom pune un numar deîntrebari despre acelasi program unor programatori împartiti în doua grupuri.

Primul grup va primi programul fara comentarii, iar al doilea grup va primitextul aceluiasi program, dar comentat. Folosind rezultatele celor doua grupuri, putemtesta ipoteza realista ca o întelegere mai buna si mai rapida a programului are efectepozitive asupra întretinerii programului. O alta modalitate de a descoperi modelealgoritmice de estimare a costului se bazeaza pe o analiza a datelor unui proiect real, darsi pe un suport teoretic. O organizatie poate strânge date despre un numar de sistemesoftware care au fost dezvoltate. Aceste date pot privi timpul petrecut la diferite faze

7

bine determinate, calificarea personalului implicat, momentele de timp în care au aparuterori, atât în timpul testarii cât si dupa instalare, complexitatea, robustetea si alti factoriimportanti ai proiectului, marimea diferitelor entitati implicate si o analiza statistica aacestor date. Un exemplu pentru o asemenea relatie este cea data mai sus, ce exprima olegatura între E si KLOC. Aplicabilitatea si corectitudinea acestor ecuatii este, în modevident, dependenta de corectitudinea datelor pe care se bazeaza.

Rezultatele obtinute în acest fel reprezinta o medie, o aproximare bazata pedatele disponibile, de aceea rezultatele obtinute trebuie aplicate cu atentie. De exemplu,programul ce urmeaza a fi dezvoltat în cadrul unui nou proiect nu se poate compara cuproduse anterioare datorita inovatiilor implicate. Estimarea costurilor pentru un proiectlegat de o naveta spatiala nu poate fi facuta printr-o simpla extrapolare a proiecteloranterioare. Trebuie retinut ca aplicarea oarba a unor formule din modelele existente nuva rezolva problema estimarii costului. Fiecare model necesita o adaptare la mediul încare va fi folosita. Aceasta conduce la necesitatea colectarii continue a datelor dinpropriul proiect si aplicarea unor metode statistice pentru a calibra parametriimodelului.

Neconcordantele dintre diferitele modele mai pot aparea deoarece:

Majoritatea modelelor ofera o relatie între numarul lunilor-om necesar simarimea produsului în linii de cod. Pot exista însa mai multe interpretari diferitepentru aceste notiuni;

Efortul nu înseamna întotdeauna acelasi lucru. Uneori se considera activitatilede dezvoltare pornind de la conceperea produsului, dupa ce au fost fixatecerintele. Alteori se includ si eforturile de întretinere.

Cu toate acestea, modelele de estimare a costului au multe caracteristicicomune.Acestea reflecta importanta factorilor care intervin asupra costului dedezvoltare si efortului. Cresterea întelegerii costului programelor ne permite saidentificam strategii de crestere a productivitatii software, cele mai importante fiind: Scrierea de mai putin cod: Marimea sistemului este una din cauzele principale

ale efortului si costului. Prin metode care încearca sa reduca marimea, cum ar fireutilizarea componentelor si utilizarea de limbaje de nivel înalt, se pot obtinereduceri semnificative;

Stimularea oamenilor sa lucreze la capacitatea maxima: Capacitatea de lucruindividual si în echipa au un mare impact asupra productivitatii. Angajarea celormai buni oameni este de obicei o afacere profitabila. O mai buna stimulare,conditii mai bune de lucru, cursurile de perfectionare asigura oportunitati decrestere a productivitatii;

Evitarea refacerii componentelor dezvoltate anterior: Studiile au aratat capentru a rescrie ceea ce s-a produs deja este necesar un efort considerabil.Aplicând modele cum ar fi realizarea prototipurilor si utilizarea metodelor deprogramare orientata obiect (precum abstractizarea datelor), se pot reducesemnificativ costurile;

Dezvoltarea si folosirea mediilor de dezvoltare integrate, cu instrumentele cepot ajuta la eliminarea sau eficientizarea unor etape.

Numeroase studii au fost efectuate cu scopul de a estima efortul necesar pentru osarcina limitata de programare. Primele experimente au fost realizate de Halstead(1977).

8

La baza modelului sau sta faptul ca numararea liniilor de cod poate constitui oproblema, chiar daca avem o definitie exacta a termenului „linie de cod”. Unele liniisunt mult mai complicate decât altele. Conform teoriei lui Halstead, este mai bine sa seporneasca de la un numar de unitati sintactice, dupa cum sunt recunoscute decompilator. Halstead face distinctia între operatori si operanzi. Operatorii denota ooperatie; exemple sunt operatorii standard (+, -, *, etc.), dar si semnul de punctuatiepunct si virgula (;) care arata structura unei instructiuni si constructii ca if-then-else siwhile-do. Operanzii înseamna date: variabile si constante. Calcularea numarului deoperatori si operanzi dintr-un program va oferi o mai buna masura a marimii decâtsimpla calculare a numarului de linii.

În modelul Halstead, cele patru entitati de baza pentru un program sunt:

n1= numarul de operatori diferiti; n2 = numarul de operanzi diferiti; N1= numarul total de aparitii ale operatorilor; N2= numarul total de aparitii ale operanzilor;

Relatiile modelului Halstead sunt urmatoarele:

Vocabularul: n = n2+n2 Lungimea implementarii: N = N1 +N2 Ecuatia lungimii: N’ = n1log2n1+ n2log2n2 Volumul programului: V = N log2n Dificultatea = ∙ Efortul E = D . V

Astfel se obtine o rafinare a masurii numarului de linii simple de cod, LOC. AtâtLOC cât si N ofera o buna corelatie cu efortul de programare. De aceea este importantsa se gaseasca modalitati de estimare a entitatilor precum LOC si N în primele etape.Valoarea lui N depinde de n1 si n2 .Valoarea lui n1este, de cele mai multe ori, un factorconstant pentru multe programe scrise într-un anumit limbaj de programare de nivelînalt. Aceasta constanta depinde de limbajul de programare ales. De exemplu, pentru unlimbaj dat, numarul maxim de operatori care poate fi utilizat în orice program este fix:toti sunt prezentati în sintaxa limbajului. Majoritatea programelor vor folosi un mareprocent din acestea, cel putin o data. O ipoteza considera ca n2este determinat în principal de numarul de variabile (VARS) care apar în program.

Bazându-se pe aceste presupuneri, a fost enuntata urmatoarea relatie empirica:

LOC = 102 + 5.31 . VARS

Astfel, fiecare program va contine aproximativ 100 de linii de cod, plus 5 liniisuplimentare pentru fiecare variabila ce apare în program. Primele experimente arata caîn acest fel se pot obtine aproximari destul de corecte ale marimii si efortului necesar.Valoarea estimata a lui VARS poate fi obtinuta relativ devreme daca este folosita ometoda de proiectare top-down în combinatie cu un limbaj de nivel înalt. Generalizareaacestor rezultate la programe mai mari nu este indicata. În programele mai complexe,factori precum interfata dintre componente si comunicarea necesara între persoaneleimplicate joaca un rol ce nu poate fi neglijat.

9

Cunoscând marimea estimata a unui proiect, vom fi interesati în continuare sa evaluamtimpul de dezvoltare necesar. Într-o abordare naiva am putea considera ca un proiect cenecesita 60 de luni-om poate fi realizat într-un an cu o echipa de 5 persoane sau într-oluna cu o echipa de 60 de persoane. Aceasta abordare este însa prea simplista. Unproiect de o anumita dimensiune corespunde unei anumite perioade de timp fizic. Dacavom încerca sa micsoram acest timp nominal de dezvoltare prea mult, vom intra într-o„zona imposibila”, iar sansele de esec vor creste.

Costurile estimate au deseori o culoare politica, iar rezultatele sunt determinatede argumente care nu au o natura tehnica. Motive tipice care reflecta aceste argumentenon-tehnice sunt prezentate în exemplele urmatoare: Daca avem 12 luni pentru a finaliza o lucrare, ea va necesita 12 luni. Acest

motiv poate fi privit ca o varianta a legii Parkinson: munca ocupa tot timpuldisponibil;

Daca stim ca a fost facuta o oferta de 100000 de euro de catre concurenta, noivom face o oferta de 90000 de euro. Acesta este cunoscut sub denumirea de pretde câstig;

Dorim sa ne promovam produsul la un anumit târg de tehnica de calcul si dinacest motiv programul trebuie scris si testat în urmatoarele 9 luni, desi realizamca timpul este limitat. Aceasta situatie este cunoscuta sub denumirea de metodabugetului de estimare a costului.

Proiectul poate fi dezvoltat într-un an, dar seful nu ar accepta acest termen. ªtimca termenul de 10 luni este acceptabil si atunci îl programam pentru 10 luni.

Aceste estimari pot avea efecte negative, dupa cum s-a demonstrat frecvent înistoria ingineriei programarii. Estimarile vor depinde mai mult de argumentele politiceale parților interesate decât de realitatea tehnica a proiectului. Pe de alta parte, simplacomparare a caracteristicilor unui proiect cu un proiect precedent nu garanteaza oestimare corecta a costului sau. Daca o echipa lucreaza în mod repetat la proiecteasemanatoare, timpul de lucru necesar va scadea, datorita acumularii experientei. În1968, unei echipe de programatori i s-a cerut sa dezvolte un compilator FORTRANpentru trei masini diferite. Efortul necesar pentru aceste trei proiecte este descris întabelul de mai jos:

Pentru estimarea costului se poate apela la serviciul unui expert, care apeleaza lapropria sa experienta. Factori greu de cuantificat, precum caracteristicile depersonalitate sau caracteristici neobisnuite ale proiectului, pot fi astfel luati înconsiderare. În acest caz, calitatea estimarii nu poate depasi calitatea expertului.

Pentru o estimare mai precisa se pot solicita mai multi experti. Totusi, daca ungrup de persoane trebuie sa gaseasca împreuna o solutie, vom observa ca unii membri aigrupului au un impact mai mare asupra rezultatului decât ceilalti. Unii nu îsi vorexprima opinia sau vor fi impresionati de opiniile celorlalti. Aceasta poate avea unimpact negativ asupra rezultatului final. Pentru a anticipa acest efect negativ, putem

10

folosi metoda Delphi. În metoda Delphi, fiecare expert îsi expune opinia în scris. Unmoderator colecteaza estimarile obtinute astfel si le redistribuie celorlalti experti. Înacest proces nu sunt asociate numele expertilor cu estimarile lor. Fiecare expert vapreda o noua estimare bazata pe informatiile primite de la moderator. Acest procescontinua pâna când se ajunge la un consens.

O alta metoda care doreste obtinerea unei estimari mai bune este aceea de a aveaun expert care sa realizeze mai multe estimari: o estimare optimista a, o estimarerealista m si o estimare pesimista b. Folosind o distributie beta, efortul asteptat va fi:

= + 4 +6Aceasta estimare este mai buna decât daca s-ar fi considerat numai media

aritmetica a lui a si b.

Metode de estimare non-algoritmice

Există două tipuri majore de metode de estimare a costurilor: algoritmice și non-algoritmice.

Modele algoritmice variază foarte mult în complexitate matematică. Unele suntbazate pe formule matematice simple, folosind astfel de statistici sumare ca medii șideviațiile standard. Altele se bazează pe modele de regresie și ecuații diferențiale.Pentru a îmbunătăți precizia de modele algoritmice, există o nevoie de a ajusta saucalibra modelul de la circumstanțele locale.

Metodele nealgoritmice sunt :

1. Analogia costului:Această metodă necesită unul sau mai multe proiecte finalizate anterior, care

sunt similare cu noul proiect și estimarea derivă prin analogie, folosind costurileefective ale proiectelor anterioare. Estimarea prin analogie se poate face fie la niveltotal al proiectului sau la nivel de subsistem. Nivelul total al proiectului are avantajul cătoate componentele de cost ale sistemului vor fi luate în considerare în timp ce nivelulsubsistemului are avantajul de a oferi o evaluare mai detaliată a asemănărilor șideosebirilor dintre noul proiect și proiectele finalizate. Punctul forte al acestei metodeeste că estimarea se bazează pe experiența reală a proiectului.

Cu toate acestea, nu este clar în ce măsură proiectul anterior este de faptreprezentant al constrângerilor, mediu și funcțiile care urmează să fie efectuate de cătrenoul sistem.

2. Hotararea expertilor:Această metodă implică consultarea unui sau mai multi experți. Experții oferă

estimări utilizând propriile metode și experiența lor proprie. Mecanismele expert-consens, cum ar fi tehnica Delphi sau PERT vor fi folosite pentru a rezolva incoerențeleîn estimări .

Tehnica Delphi funcționează după cum urmează:

Coordonatorul prezintă fiecarui expert o specificație și o formă de a înregistraestimările.

11

Fiecare expert completeaza formularul individual (fără a discuta cu alții) și i sepermite sa puna întrebări doar coordonatorului.

Coordonatorul pregătește un rezumat al tuturor estimărilor de la experți pe unformular care solicită o reiterare a estimărilor experților și motivația pentruestimări.

Se repeta pașii 2) -3), in cât mai multe runde, după caz.O modificare a tehnicii Delphi propusa de Boehm și Fahquhar pare să fie mai

eficientă: Înainte de estimare, o reuniune a grupului care implică si coordonatorul șiexperți este amenajata pentru a discuta problemele de estimare. În pasul 3), experții nutrebuie să dea nici o justificare pentru estimări. În schimb, după fiecare rundă deestimare, coordonatorul solicită o reuniune pentru a discuta cu experții acele puncte încare estimările lor au variat foarte mult.

3. Parkinson:Utilizarea principiul Parkinson "munca se extinde pentru a umple volumul

disponibil" costul este determinat (nu estimat) de resursele disponibile, mai degrabădecât bazandu-se pe o evaluare obiectivă. În cazul în care software-ul trebuie să fielivrate în 12 luni și 5 persoane sunt disponibile, efortul este estimat a fi 60 persoane-luni. Deși, uneori, această metodă nu este recomandată, deoarece poate furniza estimărifoarte nerealiste. De asemenea, această metodă nu promovează bunele practici îningineria software.

4. Price-to-win:

Costul programului este estimat a fi cel mai bun preț pentru a câștiga proiectul.Estimarea se bazează pe bugetul clientului în loc sa se bazeze pe funcționalitateasoftware. De exemplu, dacă o estimare rezonabilă pentru un proiect costă 100 depersoane-luni, însă clientul isi poate permite numai 60 persoane-luni, estimatorul esterugat să modifice estimarea efortului pentru a se potrivi 60 persoane-luni , în scopul dea câștiga proiectul . Acest lucru nu este din nou o bună practică, deoarece este foarteprobabil sa se cauzeze o întârziere de livrare sau echipa de dezvoltare să lucreze oresuplimentare.

5. Bottom-up:În această abordare, fiecare componentă a sistemului de software este separat

estimată și rezultatele agregate pentru a produce o estimare pentru sistemul global.Cerința pentru această abordare este că un designul inițial trebuie să fie în locul careindică modul în care sistemul este descompus în componente diferite.

6. Top-down:

Aceasta abordare este opusă a metodei de jos în sus. O estimare a costurilorglobale pentru sistemul este derivata din proprietățile globale, folosind metodealgoritmice fie sau non-algoritmice. Costul total poate fi apoi împărțit între diferitelecomponente. Această abordare este mai potrivită pentru estimarea costurilor de la stadiuincipient.

12

3. Modele algoritmice clasice

Nelson (1966) oferã un model liniar pentru estimarea efortului necesar pentru un proiect de

dezvoltare software. Modelele liniare au urmãtoarea formã:

n

i

ii xaaE1

0

Coeficienþii ai sunt constante, iar xi reprezintã factorii care au impact asupra efortului

necesar. Un numãr mare de factori poate influenþa productivitatea ºi implicit efortul necesar.

Analizând cu atenþie datele proiectelor precedente ºi diferite combinaþii de factori, putem încerca sã

obþinem un model cu un numãr mic de factori. Nelson, de exemplu, sugereazã un model care ia în

considerare 14 factori:

141312111098

7654321

20.2554.055.2961.3082.5835.125.13

45.2128.740.046.051.073.1015.963.33

xxxxxxx

xxxxxxxE

În aceastã ecuaþie E reprezintã numãrul estimat de luni-om necesar. Semnificaþia factorilor xi

ºi domeniul lor de definiþie sunt prezentate în tabelul urmãtor:

Factor Descriere Valori posibile x1 Instabilitatea specificaþiilor cerinþelor 0-2

x2 Instabilitatea proiectãrii 0-3

x3 Procentajul de instrucþiuni matematice 0-100

x4 Procentajul de instrucþiuni I/O 0-100

x5 Numãrul subprogramelor numãr

x6 Utilizarea unui limbaj de nivel înalt 0 (da) / 1 (nu)

x7 Aplicaþie comercialã 0 (da) / 1 (nu)

x8 Program de sine stãtãtor 0 (da) / 1 (nu)

x9 Primul program pe aceastã maºinã 1 (da) / 0 (nu)

x10 Dezvoltare concurentã de hardware 1 (da) / 0 (nu)

x11 Utilizarea dispozitivelor random-access 1 (da) / 0 (nu)

x12 Maºina gazdã diferitã de maºina þintã 1 (da) / 0 (nu)

x13 Numãr de erori numãr

x14 Dezvoltare pentru o organizaþie militarã 0 (da) / 1 (nu)

Putem face mai multe observaþii asupra acestui model. În dezvoltarea programelor pentru

aplicaþiile de apãrare, în care programele vor fi încorporate în maºini diferite de maºina gazdã (un

exemplu ar putea fi programul de control al zborului pentru rachete), factori precum x12 ºi x14 vor

avea cu siguranþã un impact mare asupra costului. Aceasta nu se va mai verifica însã într-un caz

complet diferit. Observãm din nou cã datele proiectelor care stau la baza modelului au un impact

semnificativ asupra factorilor care influenþeazã costul. Existã o creºtere a efortului datoritã folosirii

limbajului de asamblare în locul unui limbaj de nivel înalt (x6).

În general modelele liniare nu funcþioneazã foarte bine. Deºi existã un numãr mare de

factori care influenþeazã productivitatea, este puþin probabil ca ei sã intervinã independent ºi liniar.

13

Trebuie atrasã atenþia asupra preciziei acestui tip de formulã ºi sã avem grijã la capcana

exprimatã în sloganul: existã trei tipuri de minciuni � minciuni mici, minciuni mari ºi statistici.

Formula lui Nelson este rezultatul analizei statistice a datelor unui proiect real ºi trebuie interpretatã

ca atare, adicã în termeni probabilistici. Dacã avem o estimare E, atunci efortul real R va verifica

formula:

))1()1(( EREP ,

unde valori acceptabile pentru á ºi â sunt: á = 0,2 ºi â = 0,9.

Sã presupunem cã estimarea este de 100 luni-om. Semnificaþia formulei este urmãtoarea:

probabilitatea ca proiectul sã necesite în realitate între 80 ºi 120 de luni-om este mai mare ca 90%.

Costurile estimate prin acest tip de model rezultã într-un anumit interval, rãmânând o

probabilitate diferitã de zero ca acesta sã fie în afara intervalului. Aplicabilitatea acestor estimãri

este puternic influenþatã de mãrimea intervalului ºi de probabilitatea ca valoarea realã a costului sa

fie într-adevãr în acel interval. În special pentru proiectele ce necesitã efort mai mare, este bine sã

se considere valoarea superioarã a intervalului în care se aflã costul în locul valorii estimate.

O altã modalitate prin care un expert poate ajunge la o estimare a costului este printr-un

proces bottom-up. Pentru fiecare modul, va fi obþinut un cost estimativ iar costul final va fi suma

costurilor modulelor, cu o corecþie aplicatã datoritã integrãrii modulelor.

Wolverton descrie un model în care o matrice a costurilor este folositã ca punct de plecare în

determinarea costurilor modulelor. În aceastã matrice existã un numãr limitat de tipuri diferite de

module ºi un numãr de nivele de complexitate. Tabelul urmãtor ilustreazã o matrice ipoteticã de

costuri. Elementele matricei reflectã costul pentru fiecare linie de cod.

Complexitate

Micã Mare Tipul modulului

1 2 3 4 5

1. Management de date 11 13 15 18 22

2. Management de memorie 25 26 27 29 32

3. Algoritm 6 8 14 27 51

4. Interfaþã utilizator 13 16 19 23 29

5. Control 20 25 30 35 40

Fiind datã o matrice de costuri C, un modul de tip i, complexitate j ºi mãrime Sk, va rezulta

un cost al modulului ijkk CSM .

Acest tip de model are de asemenea probleme. În afarã de dificultatea estimãrii costului de

integrare a modulelor, utilizatorul trebuie sã estimeze subiectiv clasa de complexitate din care face

parte fiecare modul, ceea ce determinã un grad mare de nesiguranþã. Alþi factori care vor avea

impact asupra productivitãþii, cum ar fi experienþa în programare ºi caracteristicile hardware, nu

sunt luaþi în considerare. Extinderea matricei pentru a include ºi aceºti factori ar creºte gradul de

subiectivitate al metodei.

De asemenea, modelul nu include costurile de integrare a modulelor.

4. Modele algoritmice moderne

În paragrafele anterioare am remarcat faptul cã efortul de programare este corelat cu

mãrimea programului. Existã ºi modele neliniare care exprimã aceastã legãturã. O formã generalã

este:

14

),...,()( 1 n

cxxfKLOCbaE ,

unde KLOC reprezintã mãrimea programului în kilo-linii de cod, iar E reprezintã efortul în luni-om.

a, b ºi c sunt constante iar ),...,( 1 nxxf este o funcþie care depinde de valorile factorilor nxx ,...,1 .

În general, formula de bazã este:

c

KLOCbaE

Ea este obþinutã printr-o analizã de regresiune a datelor proiectelor disponibile. Primul

generator de cost este mãrimea programului, mãsuratã în linii de cod. Acest cost nominal estimat

este apoi adaptat prin corectarea sa pentru un numãr de factori care influenþeazã productivitatea

(generatorii de cost secundari). De exemplu, dacã unul din factorii folosiþi reprezintã �experienþa

echipei de programatori� aceasta poate cauza o corecþie a costului nominal estimat cu 1,50, 1,20,

1,00, 0,80, 0,60 pentru un nivel de expertizã foarte scãzut, scãzut, mediu, înalt ºi respectiv foarte

înalt.

Tabelul urmãtor conþine unele formule de bazã foarte cunoscute pentru relaþia dintre

mãrimea programului ºi efort. Din motivele enunþate anterior este dificil sã comparãm aceste

modele. Este interesant de observat cã valoarea lui c variazã în jurul valorii de 1 în toate modelele.

Autor Formula

Halstead 50.17.0 KLOCE

Boehm 05.14.2 KLOCE

Walston-Felix 91.02.5 KLOCE

Când c < 1, se remarcã apariþia unui fenomen foarte bine cunoscut din teoria economicã.

Pentru o producþie de masã, se presupune cã este mai ieftin sã se producã mari cantitãþi din acelaºi

produs. Costurile fixe vor fi împãrþite astfel unui numãr mai mare de unitãþi, ceea ce conduce la

scãderea costului pe unitate. În cazul programelor, liniile de cod sunt produsul. Dacã presupunem cã

producând multe linii de cod va scade costul pe linie de cod. Motivul este costul instrumentelor

scumpe precum generatoare de program, medii de dezvoltare ºi instrumente de testare, care poate fi

distribuit unui numãr mai mare de linii de cod.

În cazul opus, când c > 1, observãm cã dupã un anumit punct, producerea de unitãþi

suplimentare implicã costuri suplimentare. Putem afirma cã programele foarte mari vor fi mult mai

scumpe. Suma necesarã va fi mai mare deoarece creºte necesitatea de comunicare ºi de control

managerial, deoarece problemele ºi interfeþele devin mai complexe. Deci fiecare linie de cod

suplimentarã necesitã mai mult efort.

Nu existã nici un argument convingãtor pentru nici un tip de relaþie, deºi ultima (c > 1) pare

mai plauzibilã. În mod sigur, pentru proiecte foarte mari, efortul creºte mai mult decât liniar cu

mãrimea. Alegerea unui model sau a altuia depinde în principal de gradul de complexitate a

interfaþãrii modulelor proiectului.

Este evident cã valoarea exponentului c influenþeazã foarte mult valoarea calculatã E, în

special pentru valori mari ale KLOC. Tabelul urmãtor prezintã valorile lui E, calculate prin

metodele prezentate anterior ºi pentru câteva valori ale KLOC. Se remarcã marea diferenþã dintre

modele. Pentru programe mici, prin metoda Halstead rezultã costuri estimate mici. Pentru proiecte

cu aproximativ un milion de linii de cod, acelaºi model genereazã estimãri ale costului cu un ordin

de mãrime mai mari decât prin aplicarea metodei Walston-Felix.

15

KLOC Halstead Boehm Walston-Felix

1 0.7 2.4 5.2

10 22.1 26.9 42.3

50 247.5 145.9 182.8

100 700 302.1 343.6

1000 22135.9 3390.1 2792.6

Aceste observaþii nu trebuie sã ne conducã la concluzia cã aceste metode sunt complet

inutile. Existã diferenþe mari între caracteristicile seturilor de proiecte pe care se bazeazã diferite

modele. ªtim cã numerele utilizate în modele provin din urma analizei datelor proiectelor reale.

Dacã aceste date reflectã diferite proiecte ºi/sau medii de dezvoltare, modelele se vor comporta la

fel. Nu putem copia pur ºi simplu aceste formule. Fiecare mediu are caracteristicile sale proprii ºi

este deci necesarã adaptarea parametrilor la mediul specific, proces numit calibrare.

Cea mai importantã problemã a acestui model este obþinerea unei estimãri sigure a mãrimii

programului de la început. Cum am putea sã estimãm numãrul de pagini ale unui roman care nu a

fost scris încã? Chiar dacã ºtim numãrul de personaje, de locaþii ºi intervalul în care se va desfãºura

povestea, este o iluzie aºteptarea de la început unei estimãri realiste a mãrimii. Cu cât înaintãm în

realizarea proiectului, cu atât va fi mai exactã estimarea mãrimii. Dacã proiectarea se apropie de

final, ne putem forma o impresie rezonabilã asupra mãrimii programului rezultat. Dar numai când

sistemul va fi predat vom cunoaºte numãrul exact.

Clientul însã solicitã o estimare a preþului de la început. În acest caz, numãrul liniilor de cod

reprezintã o mãsurã prea inexactã pentru a reprezenta o bazã pentru estimarea costului. De aceea

trebuie cãutatã o alternativã. În paragrafele urmãtoare, vom analiza câteva modele ce se bazeazã pe

mãrimi cunoscute într-o etapã iniþialã.

Ecuaþia ce stã la baza modelului Walston-Felix este: 91.0

2.5 KLOCE . Acest model a fost

creat prin analiza a 60 de proiecte de la IBM. Aceste proiecte erau complet diferite ca mãrime, iar

cã dacã aplicãm acest model chiar unei submulþimi a celor 60 de proiecte, nu vom avea rezultate

satisfãcãtoare.

Încercând sã explice aceste rezultate dintr-o plajã mare de valori, Walston ºi Felix au

identificat 29 de variabile care influenþeazã în mod sigur productivitatea. Pentru fiecare din aceste

variabile au fost considerate trei nivele: mare, mediu ºi mic. Pentru un numãr de 51 de proiecte,

Walston ºi Felix au determinat nivelul fiecãrei variabile din cele 29, împreunã cu productivitatea

obþinutã, exprimatã ca numãrul liniilor de cod pe lunã-om. Aceste rezultate sunt prezentate în

tabelul urmãtor pentru câteva din cele mai importante variabile. De exemplu, productivitatea medie

este de 500 de linii de cod pe lunã-om pentru proiecte cu o interfaþã utilizator de complexitate

scãzutã. Pentru o interfaþã de complexitate înaltã sau medie, productivitatea este de 295 ºi respectiv

124 de linii de cod pe lunã. Ultima coloanã reprezintã variaþia productivitãþii, PC (engl.

�productivity change�), valoarea absolutã a diferenþei dintre valorile minime ºi maxime.

programele au fost scrise în mai multe limbaje de programare. Totuºi nu reprezintã o surprizã faptul

Modelul Walston-Felix

16

Variabila Productivitatea medie pentru

valoarea variabilei PC

Complexitatea interfeþei utilizator < normalã

500

normalã

295

> normalã

124 376

Calificarea ºi experienþa personalului micã

132

medie

257

mare

410 278

Experienþã anterioarã cu aplicaþii similare minimã

146

medie

221

vastã

410 264

Procentajul de programatori participanþi

în faza de proiectare

< 25%

153

25-50%

242

> 50%

391 238

Raportul dintre mãrimea medie a echipei

ºi durata proiectului (persoane/lunã)

< 0.5

305

0.5-0.9

310

> 0.9

171 134

Walston ºi Felix considerã cã indexul productivitãþii I poare fi determinat pentru noile

proiecte dupã urmãtoarea relaþie:

29

1i

ii XWI ,

unde ponderile iW sunt definite astfel:

)(log5.0 10 ii PCW .

În relaþia de mai sus, iPC reprezintã variaþia productivitãþii factorului i. Pentru primul factor

din tabelul de mai sus, complexitatea interfeþei cu utilizatorul, rezultã urmãtoarele: 3761 PC , deci

29.11 W . Variabilele iX pot lua valorile �1, 0 ºi 1, unde factorul corespunzãtor este de nivel

scãzut, mediu sau înalt. Indexul productivitãþii obþinut poate fi tradus într-o productivitate aºteptatã:

linii de cod scrise pe lunã-om.

Trebuie menþionat cã numãrul factorilor luaþi în considerare în acest model este destul de

ridicat (29 de factori din 51 de proiecte). De asemenea, nu este clar cum aceºti factori se

influenþeazã unul pe celãlalt. Un alt dezavantaj ar fi cã numãrul de alternative pentru fiecare factor

este de numai 3, ºi nu oferã destule opþiuni pentru situaþiile practice.

COCOMO (COnstuctive COst MOdel) este unul din cei mai bine documentaþi algoritmi de

estimare a costului (Boehm, 1981). În forma sa cea mai simplã, numitã �Basic COCOMO�, formula

care exprimã legãtura dintre efort ºi mãrimea programului este:

c

KLOCbE ,

unde b ºi c sunt constante ce depind de tipul proiectului ce este executat.

Boehm distinge trei clase de proiecte:

Organice: În proiectele de tip organic o echipã relativ micã dezvoltã programul într-un

mediu cunoscut. Persoanele implicate au în general experienþã în proiecte similare realizate

în organizaþia lor. Astfel, ei pot sã lucreze de la început, nefiind necesare investiþii iniþiale.

Proiectele de acest tip sunt de multe ori programe relativ mici;

Modelul COCOMO

17

Integrate: Proiectele din acest tip implicã sisteme unde mediul impune constrângeri severe.

Produsul va fi integrat într-un mediu care este foarte strict. Exemplu de asemenea proiecte

sunt programe de control al traficului aerian sau aplicaþiile militare;

Semidetaºate: Aceasta este o formã intermediarã. Echipa poate fi formatã din persoane

experimentate ºi neexperimentate, proiectul poate fi destul de mare, dar nu foarte mare.

Pentru clase diferite, parametrii metodei Basic COCOMO iau urmãtoarele valori:

Clasa de proiect b c

organicã 2.4 1.05

semidetaºatã 3.0 1.12

integratã 3.6 1.20

Tabelul urmãtor prezintã estimãri ale efortului pentru fiecare din cele trei moduri, pentru

diferite valori ale KLOC (deºi un proiect organic de un milion de linii de cod nu este realist). Se

observã influenþa foarte mare a constantei c asupra estimãrilor obþinute. Estimãrile efortului sunt

exprimate tot în luni-om.

KLOC organic semidetaºat integrat

1 2.4 3.0 3.6

10 26.9 39.6 57.1

50 145.9 239.4 392.9

100 302.1 521.3 904.2

1000 3390 6872 14333

Analiza punctelor funcþionale este o metodã de estimare a costurilor care încearcã sã evite

problemele determinate de estimarea dimensiunii codului. APF (Albrecht, 1983) se bazeazã pe

numãrarea diferitelor structuri de date utilizate; se presupune cã acest numãr este un bun indicator

pentru dimensiunea proiectului. Metoda este potrivitã mai ales pentru aplicaþiile comerciale, în care

structura datelor are o foarte mare importanþã. APF este mai puþin indicatã pentru proiectele în care

algoritmii joacã rolul dominant, de exemplu compilatoarele sau aplicaþiile de timp real.

Unul din scopurile principale ale APF este evaluarea posibilitãþilor sistemului din punctul de

vedere al utilizatorilor. De aceea, analiza se bazeazã pe modalitãþile în care diverºi utilizatori

interacþioneazã cu aplicaþiile. Astfel, sistemul îndeplineºte cinci funcþii fundamentale:

funcþii referitoare la date

o fiºiere interne logice

o fiºiere externe de interfaþã

funcþii tranzacþionale

o intrãri externe

o ieºiri externe

o cereri externe

Fiºierele interne logice (engl. �Internal Logical Files�, FIL): Permit utilizatorilor sã

foloseascã datele pe care trebuie sã le întreþinã. De exemplu, un pilot poate introduce datele de

navigare la un terminal din carlingã înainte de plecare. Datele sunt stocate într-un fiºier ºi pot fi

modificate în timpul misiunii. Pilotul este deci responsabil pentru întreþinerea acestor date.

Analiza punctelor funcþionale

18

Fiºierele externe de interfaþã (engl. �External Interface Files�, FEI): În acest caz,

utilizatorul nu este responsabil pentru întreþinerea datelor; acestea sunt localizate în alt sistem care

le întreþine. Utilizatorul sistemului analizat solicitã datele doar pentru informare. De exemplu, un

pilot se poate informa asupra poziþiei cu ajutorul sateliþilor GPS sau al sistemelor de la sol. El nu are

responsabilitatea actualizãrii acestor date, însã le poate accesa în timpul zborului.

Intrãrile externe (engl. �External Input�, IE): Permit utilizatorului sã întreþinã fiºierele

interne logice prin operaþii de adãugare, modificare ºi ºtergere.

Ieºirile externe (engl. �External Output�, EE): Permit utilizatorului sã producã date de ieºire.

De exemplu, pilotul poate sã afiºeze separat viteza la sol ºi viteza realã în aer, informaþii derivate

din datele interne (pe care le poate întreþine) ºi cele externe (pe care le poate accesa).

Cererile externe (engl. �External Inquiries�, CE): Pentru ca utilizatorul sã poatã selecta ºi

afiºa datele din fiºiere, el trebuie sã introducã informaþii de selecþie pentru a gãsi datele în

conformitate cu anumite criterii. În aceastã situaþie datele din fiºiere nu sunt modificate, ci doar

cãutate ºi furnizate. De exemplu, dacã pilotul afiºeazã date cu privire la relieful solului, date stocate

anterior, rezultatul este regãsirea directã a informaþiilor.

Prin încercãri repetate, s-au stabilit ponderi pentru fiecare din aceste entitãþi. Numãrul de

puncte funcþionale neajustate este:

CEEEIEFEIFILPFN 454710

În funcþie de complexitatea tipurilor de date, se disting o serie de valori pentru aceste puncte

funcþionale, prezentate în tabelul urmãtor.

Nivel de complexitate Tip

Simplu Mediu Complex

FIL 7 10 15

FEI 5 7 10

IE 3 4 6

EE 4 5 7

CE 3 4 6

Pentru ajustarea suplimentarã a estimãrilor, se iau în calcul ºi alte 14 caracteristici care

influenþeazã dezvoltarea aplicaþiilor: comunicaþiile de date, funcþiile distribuite, performanþa,

folosirea masivã a configuraþiilor, rata tranzacþiilor, intrãrile de date online, eficienþa utilizatorilor

finali, actualizãrile online, prelucrãrile complexe, refolosirea, uºurinþa la instalare, uºurinþa la

folosire, locaþiile multimple, facilitarea modificãrilor.

Influenþa fiecãrei caracteristici este evaluatã pe o scarã de la 0 (nu influenþeazã) la 5

(influenþã puternicã). Gradul de influenþare GI este suma acestor puncte pentru toate caracteristicile.

Se calculeazã apoi factorul de complexitate tehnicã:

GIFCT 01,065,0 .

Punctele funcþionale ajustate PF se obþin astfel:

FCTPFNPF .

Avantajul principal al analizei punctelor funcþionale este faptul cã mãsura productivitãþii

este un rezultat natural, deoarece punctele funcþionale sunt independente de tehnologie ºi deci pot fi

utilizate pentru a compara productivitatea pe platforme diferite ºi cu instrumente de dezvoltare

diferite. Ele pot fi folosite pentru a stabili o ratã de productivitate (PF / h) care faciliteazã estimãrile

privind durata proiectului ca întreg.

19

Norden a studiat distributia fortei de munca în timp într-un numar de proiecte dedezvoltare software în anii ’60. A descoperit ca aceasta distributie avea deseori o formacaracteristica. Aceasta forma caracteristica este bine aproximata de distributia Rayleigh.Bazându-se pe aceasta descoperire, Putnam a dezvoltat un model de estimare a costuluiîn care forta de munca necesara la un moment de timp t este data de:

unde a este un factor de accelerare care determina panta initiala a curbei, iar Kreprezinta forta de munca totala necesara, incluzând faza de întretinere. K este egal cuaria zonei delimitate de curba Rayleigh, reprezentata în figura 2.

Integrarea ecuatiei pentru FM(t) determina efortul cumulat I:

Fig.2 Curba Raylegh

Daca consideram momentul de timp T în care curba Rayleigh ajunge în punctul demaxim, atunci

= 12Acest moment T va fi apropiat de momentul de timp în care proiectul va fi predat

clientului. Aria delimitata de curba Rayleigh între punctele 0 si T va fi o bunaaproximare aefortului initial de dezvoltare. Pentru acesta obtinem:

Acest rezultat este foarte apropiat de o regula euristica foarte des utilizata: 40%din efortul total este cheltuit pentru dezvoltarea efectiva, în timp ce 60% este cheltuit

5. Distribuirea fortei de munca in timp

20

pentru întretinere. Specificarea cerintelor nu este inclusa în model. Estimarile conformacestui model nu se pot aplica decât începând cu proiectarea si implementarea.Mai multi cercetatori au criticat folosirea curbei Rayleigh pentru estimarea costului(Pillai, 1997). Modelul lui Norden nu se bazeaza pe o teorie, ci mai mult pe observatii.Mai mult, datele sale se refera mai mult la proiecte hardware. Nu s-a demonstrat însafaptul ca proiectele software se comporta la fel. Acestea prezinta uneori o acumularerapida a fortei de munca care invalideaza modelul în fazele incipiente ale proiectului.Putnam a folosit observatii empirice legate de nivelele de productivitate pentru a derivaecuatia software-ului din curba Rayleigh:

unde D este dimensiunea proiectului, E este efortul total în ani-om, t este timpul scurspâna la lansare în ani iar k este un factor tehnologic bazat pe 14 componente, precum:

maturitatea generala a proiectului si tehnicile de management; gradul de utilizare a tehnicilor de ingineria programarii; nivelul limbajelor de programare folosite; capacitatea si experienta echipei de

dezvoltare; complexitatea aplicatiei.

Puterea supraunitara a timpului are implicatii puternice asupra alocarii resurselorîn proiecte mari. Prelungiri relativ mici ale datei de livrare pot determina reducereasubstantiala a efortului (Pressman, 1997).Pentru estimarea efortului, Putnam a introdus ecuatia acumularii fortei de munca (engl.„manpower-buildup”):

unde A este numita accelerarea fortei de munca iar E si t au semnificatiile de mai sus.Accelerarea fortei de munca este 12,3 pentru proiecte software noi, cu multe interfete siinteractiuni cu alte sisteme, 15 pentru sisteme de sine statatoare si 27 pentrureimplementari ale sistemelor existente. Pe baza celor doua ecuatii, putem eliminatimpul si determina efortul:

Acest rezultat este interesant deoarece arata ca efortul este proportional cudimensiunea la puterea 9/7 ≈ 1.286, valoare similara cu factorul lui Boehm, între 1,05si 1,20. Evident, scurtarea timpului de dezvoltare implica un numar mai mare depersoane necesare pentru proiect. Referindu-ne la modelul curbei Rayleigh, scurtareatimpului de dezvoltare conduce la marirea valorii a, factorul de accelerare caredetermina panta initiala a curbei. Vârful curbei Rayleigh se deplaseaza spre stânga si înacelasi timp în sus. Astfel obtinem o crestere a puterii necesare la începutul proiectuluisi o forta de munca maxima mai mare.

21

Exista si dezavantaje ale acestei deplasari. Mai multe studii au aratat caproductivitatea individuala scade odata cu cresterea echipei. Conform lui Brooks, existadoua cauze ale acestui fenomen: Daca o echipa se mareste, va creste timpul acordat comunicarii cu ceilalti

membri ai echipei(pentru consultare, sincronizarea sarcinilor etc.); Daca este adaugata forta de munca suplimentara unei echipe în timpul

dezvoltarii unui proiect, mai întâi scade productivitatea. Noii membri ai echipeinu sunt productivi de la început. În acelasi timp ei necesita ajutor, deci timp, dela ceilalti membri ai echipei în timpul procesului de învatare. Luate împreuna,acestea conduc la scaderea productivitatii totale.

Combinând aceste doua informatii, ajungem la fenomenul cunoscut sub denumirea delegea lui Brooks: adaugarea de personal la un proiect întârziat îl va întârzia si mai mult.Analizând o mare baza de date de proiecte, Conte a descoperit urmatoarea relatie întreproductivitatea medie L (masurata în linii de cod pe luna-om) si marimea medie a uneiechipe P:

Formula atesta faptul ca productivitatea individuala scade cu marimea echipei. Numarulde legaturi de comunicare între persoanele implicate într-un proiect este determinat demarimea si structura echipei. Daca într-o echipa de marime P fiecare membru trebuiesa-si coordoneze activitatile sale cu toti ceilalti din echipa, numarul legaturilor decomunicatie va fi : = ( )

Daca fiecare membru trebuie sa comunice numai cu un singur alt membru, acestnumar va fi: P-1 . Mai putina comunicare decât aceasta nu este rezonabila, deoarece ne-am confrunta cu echipe independente.Numarul de legaturi de comunicatie variaza de la aproximativ P la aproximativ P2/2 .Într-o organizare ierarhica, aceasta conduce la cai de comunicatie, cu 1<∝<2 . Pentruun membru al echipei, numarul de legaturi de comunicatie variaza de la 1 la P-1 . Dacaproductivitatea individuala maxima este L si fiecare legatura de comunicatie conduce lao pierdere a productivitatii l, atunci productivitatea medie va fi:

unde ∈(0,1] este o masura a numarului de legaturi de comunicatie. Presupunem caexista cel putin o persoana care sa comunice cu mai mult de o persoana, deci > 0.Pentru o echipa de marime P, aceasta conduce la o productivitate totala:

Pentru o multime data de valori pentru L, l si a, pentru valori crescatoare ale lui P,aceasta functie creste de la 0 la o valoare maxima si apoi scade din nou. Deci exista omarime optima a echipei P , care conduce la o productivitate maxima a echipei.Productivitatea echipei pentru diferite valori ale lui P este data în tabelul de mai jos.Aici, presupunem ca productivitatea individuala este de 500 LOC / luna-om (L = 500),

22

iar scaderea de productivitate este de 10% pe canal de comunicatie (l = 50). Cuinteractiune completa între membrii echipei (a = 1), rezulta o echipa optima de 5,5persoane:

Inainte de a demara un proiect trebuie sa te asiguri ca ai autoritatea de a realizaproiectul. O persoana are autoritatea de a rezolva o cerinta numai daca are uncontroladecvat asupra resurselor necesare pentru a completa acea cerinta. Prin ai da unimanager de proiect autoritatea de demara un proiect se intelege ca acesta are controlasupra resurselor (oameni, spatiu, resurse hard si soft, etc.) necesare finalizariiproiectului respectiv.

Acest lucru nu inseamna ca managerul de proiect trebuie sa aiba cotrol directasupra resurselor, dar totusi el trebuie sa aiba suportul total al managerului fiecareiresurse in parte ce este destinata proiectului. Fara acestea si fara garantia ca va avearesursele financiare necesare autoritatea managerului de proiect este inca incompleta.

Oferirea autoritatii si responsabilitatii fiecarui membru al echipei

Cand cineva este resposabil pentru un proiect software, atunci este responsabilpentru succesul acestuia. Totusi, nu este singura persoana responsabila, aceastareposabilitate trebuie impartita in mod corespunzator intre membrii echipei.

Asigurarea integritatii proiectului

O alta problema la proiectele software si nu numai este de a proteja proiectulatunci cand autoritatea este pusa la incercare. De exemplu resursele alocate proiectuluiau fost retrase.

Transparenta muncii din echipa

Cand fiecare persoana din echipa stie ca ce ea creaza va fi citit si folosit de toticeilalti membrii ai echipei, aceea persoan se va simti mult mai responsabila pentru fieacre actiune a ssa din cadrul proiectului.

Luarea deciziilor trebuie sa se ia pe baza unor criterii binecunosute

Daca lucrurile se fac la fel de fiecare data, oamenii inteleg cu timpulrationamentele din spatele deciziilor. Oameni se simnt mai bine atunci cand deciziileluate de manager sunt mai putin predictibile. O solutie care ajuta pe altii sa inteleaga

6. Organizarea echipei software

23

mai bine perspectiva conducerii echipei, este de a se publica standardele dupa care seiau deciziile.

Organizarea echipei

Cel mai important lucru la un manager de proiect este de a cunoaste dificultatilesi cerintele posturilor subalternilor lui. De aceea de regula unul dintre cei mai buniprogramatori, desingneri, sau tester va fi promovat la statutul de manager. Alegere, carein cele mai multe cazuri s-a dovedit foarte buna pentru ca este foarte important ca acestasa inteleaga munca depusa de echipa.

Intelegerea muncii depuse de echipa este un lucru foarte bun, insa principalasarcina a managerului este sa se asigure ca fiecare persoana este compatibila cu sarcinape care o are. Pe sa se asigure ca acea persoana este cea mai eficienta si cea mai putinproblematica pentru sarcina respectiva. De obicei primul instinct al unui manager, caresa spunem ca a fost mai inainte un bun programator, este acele de a fi cel mai bunprogramator din echipa. Aceasta nu este intotdeauna ceea ce echipa are nevoi, echipaare nevoie de de cineva care sa ia decizii, sa indrume si sa ofere suport.

In contrast unui manageri intelec ca ei trebuie sa delege. Dar in timp cedelegarea este o parte importanta de management, aceasta trebuie facuta cu o bunaintelegere a muncii din spatele postului unde a fost delegat. Managerul nu trebuie sa fieneaparat cel mai bun inginer, dar trebuie sa inteleaga scopurile si limitarile fiecaruitask, si sa fie capabil sa ofere suport si indrumare daca membrii echipei se impotmolesc.

Bunii manageri de obicei se stimt putin vinovati ca sunt intr-un post deconducere. Ei stiu ca oamenii lor sunt buni si vor ca acestia sa reuseasca. Ei inteleg camunca lor nu este cea mai importanta in realizarea proiectului si ca ei doar „ung rotilemecanismului” prin furizarea unui mediu in care problemele se rezolva.

Eficientizare echipei software

Daca in cele prezentate mai sus am descris sumar problemele intampinate de unmanager de proiect, atat in legatura cu proiectul in sine cat si probleme ce pot sa aparain legatura cu echipa software, in cele ce urmeaza vom prezenta doua scheme pentruimbunatatirea eficientei echipei softuare.

Team Software Process (TSP) a fost folosit pe o sacara larga in companiile detop ce se ocupa cu dezvoltarea de software, aducand multe beneficii firmelor respective.Vom prezenta cercetarile si implementarea TSP si trei parti ce includ formarea echipei ,lansarea echipei si lucrul echipei. Vom analiza de asemenea avantajele sidezavantajeleprocesului TSP. In ceea ce priveste dezavantajele vor fi propuse douascheme numite Tailored TSP (TTSP) si Level TSP (LTSP) pentru a imbunatati metosaTSP.

O scurta prezentare a teoriei TSP

Vom descrie TSP din doua puncte de vedere si anume organizarea TSP sifunctioanrea TSP. Prima propune o descriere din punct de vedere managerial, in timp ceadoua se axeaza pe partea tehnica .

24

Organizarea TSP

TSP are trei parti generale: formarea echipei, lansarea echipei si lucrul echipei.

In timpul formarii echipei, se reruteaza potentialii membtii si se asigura atatechipei cat si managerilor cursuri de trainig si orientare necesare. Principala activitatein formarea echipei este impartita in patru parti dupa cum uremeaza alocarea de resurse,aptitudinile necesare, recrutarea membrilor, asigurarea trainingului.

Lansarea echipei TSP are noua intalniri in decursul a patru zile. In timpullansarii echipei se urmaresc urmatoarele rezultate definirea obiectivelor, determinarerolului fiecarui membru, elaborarea planului, calitatea planului, evaluarea riscurilor sistarea rapoartelor.

Lucrul echipei se refera la continutul specific al activitatii echipei care are cinciparti: strangerea datelor, uramrirea planului, rezutatele echipei, balansarea greutatii sireplanificarea.

Strangerea datelor este importanta pentru orice inceput de proiect si se axeaza inspecial pe determinarea cerintelor de timp, dimensiunea produsului si defecte gasite.

Un plan detaliat impreuna cu date adunate ajuta echipa sa vada cu exactiatate ince statiu se afla proiectul si sa inteleaga diviatiile de la plan. Principalele elemente aleurmaririi planului sunt: orele de lucru, valorile castigate, pozitia actuala in cadrulproiectului si calitatea.

Un element esential in mentinerea motivarii echipei este prezentarea rezultatuluimuncii depuse. Acesta este furnizat la intalniri saptamanale ale echipei.

Balansarea incarcaturii este importanta pentru ca scurteaza semnificativ timpulnecesar completarii proiectului.

In cadrul TSP, echipele isi replanifica periodic munca. Cel mai bun momentpentru a relansa este atunci cand membrii echipei sunt de parere ca actualul plan nu maieste folositor pentru a le ghida activitatea.

Replanificarea asigura echipei un planu exact si eficient dupa care acesta sa-iorganizeze eforturile.

Functionarea TSP

Structura si cursul TSP. In figura de mai jos sunt prezentate ciclurile TSPnecesare construirii unui produs final.

Cand se desvolta o strategie bazata pe cicluri, fiecare ciclu trebuie sa produca ovarianta testabila a produsului care este un subset adecvat al produsului final.

25

Procesul TSP. Urmatoarea figura prezinta procesul TSP ca o serie de activitati sifaze. Orice aplicatie TSP poate include nu numai o faza, ci u numar de faze. Inainteainceperii proiectului, echipa ar trebui sa-si planifice activitatile. In timpul planificariisau replanificarii ar trebui ordonate obiectivele si analizate riscurile cheie.

26

Elementele procesului TSP. TSP este definit ca un set de elemente precum urmatoarele

- script-uri care sa ghideze anumite procese

- forme care sa contina informatii specifice prin angajarea unui sau a mai multorscript-uri

- rolul caietului de sarcini pentru a ghida indivizii in executarea unor activitaticritice ale planului dar nescripatate

- alte acivitati precum introducerea strategiei, lista de verificare, liniile generale deorientare si pecificatii care nu sunt prevazute in caietul de sarcini

- cursuri de training si autorizare in activitati TSP si PSP (Personal SoftwareProces)

Analiza TSP

Atat PSP cat si TSP pot imbunatati caliatatea software-ului, reduce timpul deproductie, reduce costurile si pot creste productivitatea.

Desi introducerea TSP-ului furnizeaza indrumarea tehnicapentru dezvoltarea echipeisoftware, a intampinat si unele dificultati la implementare. In primul rand membriiechipei nu inteleg pe deplin procesul TSP. Este greu pentru ei sa comunice si sacoopereze. Mai mult, datele procesului software sunt greu de manipulat, si adeseauneltele puse la dipozitie nu sunt de ajuns. In al doile rand, daca o aorganizatie trebuiesa implementeze TSP, capabilitatea de scadenta ar trebui sa fie peste CMM2 (CapabilityMaturity Model) si dezvoltatorii de proiect au nevoie de trainig PSP. Pentru majoritateacompaniilor mici si mijloci, care doresc sa implementeze TSP in echipele softwarepentru a dezvolta calitatea produselor software, cerintele mentionae mai sus adesea nusunt complet indeplinite. Avand in vedere aceasta situatie au fost propuse doua schemepentru facilitarea implementarii TSP. Aceasta imbunatatire are urmatoarele scopuri:

- redefinirea ideii de baza a TSP, si aplicarea acesteia la diferite fireme cu diferitecapabilitati.

- Divizarea erarhica a TSP-ului, gideaza organizatiile de dezvltare sa perfectionezegradat echipele, si sa obtina cerintele CMM

- Imbunatairea operabilitatii TSP

Pentrun promovarea implementarii TSP, s-a combinat carcteristicile de managementale CMM si PSP pentru a imbunatati TSP, iar performantele specifice sunt Tailored TSPsi Level TSP. Prima solutie este aplicabila in cazul echipelor software in genaral si seaxeaza pe planificare si caliatatea managementului. In timp ce a doua a fost conceputapentru echipe software de nivele diferite. Aceasta aloca diferite obiective si folosestediferite practici cheie in functie de maturiatatea si abilitatea echipei softwares, fiindimplementata combinat cu CMM2/3 si PSP.

Schema TTSP

Este necesar sa se adapteze elementele TSP in scopul de a indeplinii dezvoltareaechipe, de a simplifica procesul si de imbunatatii operabilitatea TSP. Procesul TSP esteadaptat dupa urmatoarele elemente:

27

- se pastreaza elementele cheie ale planificarii si ale calitatii managementului si serenunta la elementele supra-rafinate.

- se minimizeaza formele si documentele ce nu sunt necesare

- se unesc componentele cu continut similar

Bazandu-se pe principiile de mai sus elementele TSP sau adaptat dupa cum urmeaza:

- Adaptarea procesului. Procesul TSP include patru faze cerinte, design,implementare, integrare. Un proiect cu TSP poate sa includa o singura faza, sauun numar de faze consecutive. I faza initiala de implementare, se poate adaptaprocesul software.

- Adaptarea formei. TSP este alcatuit din 21 forme, inclusiv KPA de la CMM2pana la CMM5. in faza initiala de implementare este necesara adaptareaformelor.

- Adaptarea rolului echipei. In ceea ce priveste dezvolatrea echipei sunt opt tipuride gestionare a rolurilor. Cand membrii echipei sunt putini, unele roluri se potimbina. Cand membrii echipei sunt multi, unele roluri por fi separate. In ceea cepriveste adaptarea rolului echipei se iau doua elemente in coniderare puncteletehnice si caliatatea. Partea tehnica contine managementul design-ului,managementul implementarii managementul de testare. In timp ce calitatea serefera la managementul calitatii.

Schema LTSP

Versiunea acutala a modelului CMM contine cinci nivele si ofera un cadruiterativ de imbunatatire a procesului software. Modelul PSP include patru nivele sifurnizeaza inginerului un cadru de evolutie iterativ.

In scopul optimizarii procesului software cu o crestere mica a volumului de munca, artrebui sa se ia in considerare principiile de mai jos:

- sa se ia in considerare caracteristicile ierarhice ale CMM si PSP si sa sefoloseasca la maxim rezultatele TSP existente

- sa se impementeze pas cu pas

- sa se implementeze LTSP corespunzator cu CMM de nivel 2, CMM3 si PSP

Pentru a clasifica eficint TSP sunt urmatorii pasi:

- sa se identifice procesul software pentru fiecare nicvel al echipe software

- sa se identifice KPA pentru fiecare proces

- determinare obiectivelor fiecarui nivel

- determinarea script-urilor si formelor pentru fiecare nivel

28

- determinarea punctelor cheie pentru fiecare nivel al CMM si PSP

- determinarea rezultatelor fiecarui nivel

In conformitate cu principiile si spasii de mai sus, TSP poate fi impartit in patru nivele

TSP1-prototype management level

TSP2-quality management level

TSP3-process management level

TSP4-product management level

Estimarea costului unui proiect software este un concept simplu, insa estecomplex si dificil in realitate.

Complexitatea necesara succesului depaseste capabilitatea multor manageri deproiect, insa este un aspect critic in dezvoltarea software. Multe proiecte au fost opritedin cauza rezultatelor nefavorabile ale estimarilor costului. De aceea, acest aspectnecesita depunerea de eforturi si schimbul de experienta cu cercetatori academici astfelincat companiile dezvoltatoare de software sa obtina modele de dezvoltare cat mai putincostisitoare.

Cea mai buna metoda de estimare a costului unui proiect software este folosireaunei combinatii intre unelte pentru estimarea costului, unelte pentru managementulproiectelor, sub stricta supraveghere a unor manageri de proiect experimentati sispecialist in estimare.

7. Concluzii

29

Handbook for Software Cost Estimation Prepared by: Karen Lum,Michael Bramble,Jairus Hihn,John Hackney,Mori Khorrami,Erik Monson

Software Cost Estimation Hareton Leung,Zhang Fan Department of Computing TheHong Kong Polytechnic University

Software Development Cost Estimation Approaches – A Survey Barry Boehm, ChrisAbtsUniversity of Southern California Los Angeles, CA 90089-0781

http://www.cse.buffalo.edu/~hungngo/SCE-Papers/p96-arifoglu.pdf

http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R18.pdf

http://paper.ijcsns.org/07_book/200811/20081150.pdf

http://www.wseas.us/e-library/conferences/2005malta/papers/499-395.pdf

8. Bibliografie

30