Estimarea costului unui proiect software

Managementul proiectelor software Cursul 5

Estimarea costului unui proiect software

1. Introducere 2. Metode de estimare 3. Modele algoritmice clasice 4. Modele algoritmice moderne

4.1. Modelul Walston-Felix 4.2. Modelul COCOMO 4.3. Analiza punctelor funcionale

5. Distribuirea forei de munc n timp 6. Concluzii

1. Introducere

La construirea unei case, la decorarea unei bi sau a unei grdini, dorim s cunoatem costul precis al operaiilor ce urmeaz a fi efectuate nainte de nceperea acestora. Un grdinar este capabil s fac o aproximare a costurilor bazndu-se, de exemplu, pe tipul pmntului, mrimea dorit a terasei sau a zonei cu iarb, prezena sau absena unui iaz i pe alte informaii similare. Apoi aceast estimare poate fi fcut mai precis printr-un dialog ulterior nainte de a se ncepe lucrrile. Estimarea costurilor unei aplicaii software reprezint un domeniu mai puin formalizat, care se bazeaz mai mult pe aproximri. Exist totui o serie de metode care permit estimarea costului total pentru un proiect software pe baza unui numr limitat de generatori relevani de costuri. n cele mai multe modele de estimare, este presupus o relaie simpl ntre cost i efort. Efortul poate fi msurat de exemplu n luni-om (adic numrul estimativ de luni necesar unui singur om s realizeze lucrarea), i fiecrei luni-om i se asociaz o sum fix de bani, corespunztor salariului angajailor. Costul total estimat se obine nmulind numrul estimat de luni-om cu factorul constant considerat.

Noiunea de cost total reprezint de obicei costul efortului iniial de dezvoltare software, costul analizei cerinelor, proiectrii, implementrii i testrii, fr a fi luate n considerare costurile de ntreinere. Noiunea de cost, care se va folosi n continuare, nu include i posibilele costuri hardware, ci numai costurile legate de personalul angajat n dezvoltarea produsului software.

2. Metode de estimare

Cercetrile n domeniul estimrii costului sunt departe de a fi cristalizate. Diferite modele folosesc diferite sisteme de msur i generatori de costuri, nct este dificil compararea lor. S presupunem c un model folosete o ecuaie de forma:

05,17,2 KLOCE

Aceast ecuaie arat o relaie ntre efortul necesar i mrimea produsului (KLOC = Kilo-Lines Of Code, kilo-linii de cod). Unitatea de msur a efortului poate fi numrul de luni-om necesare.

Pentru a determina ecuaiile unui model algoritmic de estimare a costului, putem urma diferite abordri. n primul rnd ne putem baza ecuaia pe rezultatul experimentelor. ntr-un asemenea experiment, n general variem un parametru, n timp ce ceilali parametri rmn constani. n acest fel ncercm s determinm influena pe care o are parametrul care variaz. Un exemplu

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

2

tipic este cel ce testeaz dac comentariile ajut la nelegerea unui program. Vom pune un numr de ntrebri despre acelai program unor programatori mprii n dou grupuri. Primul grup va primi programul fr comentarii, iar al doilea grup va primi textul aceluiai program, dar comentat. Folosind rezultatele celor dou grupuri, putem testa ipoteza realist c o nelegere mai bun i mai rapid a programului are efecte pozitive asupra ntreinerii programului. O alt modalitate de a descoperi modele algoritmice de estimare a costului se bazeaz pe o analiz a datelor unui proiect real, dar i pe un suport teoretic. O organizaie poate strnge date despre un numr de sisteme software care au fost dezvoltate. Aceste date pot privi timpul petrecut la diferite faze bine determinate, calificarea personalului implicat, momentele de timp n care au

aprut erori, att n timpul testrii ct i dup instalare, complexitatea, robusteea i ali factori importani ai proiectului, mrimea diferitelor entiti implicate i o analiz statistic a acestor date. Un exemplu pentru o asemenea relaie este cea dat mai sus, ce exprim o legtur ntre E i KLOC. Aplicabilitatea i corectitudinea acestor ecuaii este, n mod evident, dependent de corectitudinea datelor pe care se bazeaz. Rezultatele obinute n acest fel reprezint o medie, o aproximare bazat pe datele disponibile, de aceea rezultatele obinute trebuie aplicate cu atenie. De exemplu, programul ce urmeaz a fi dezvoltat n cadrul unui nou proiect nu se poate compara cu produse anterioare datorit inovaiilor implicate. Estimarea costurilor pentru un proiect legat de o navet spaial nu poate fi fcut printr-o simpl extrapolare a proiectelor anterioare. Trebuie reinut c aplicarea oarb a unor formule din modelele existente nu va rezolva problema estimrii costului. Fiecare model necesit o adaptare la mediul n care va fi folosit. Aceasta conduce la necesitatea colectrii continue a datelor din propriul proiect i aplicarea unor metode statistice pentru a calibra parametrii modelului.

Neconcordanele dintre diferitele modele mai pot aprea deoarece:

Majoritatea modelelor ofer o relaie ntre numrul lunilor-om necesare i mrimea produsului n linii de cod. Pot exista ns mai multe interpretri diferite pentru aceste noiuni;

Efortul nu nseamn ntotdeauna acelai lucru. Uneori se consider activitile de dezvoltare pornind de la conceperea produsului, dup ce au fost fixate cerinele. Alteori se includ i eforturile de ntreinere.

Cu toate acestea, modelele de estimare a costului au multe caracteristici comune. Acestea

reflect importana factorilor care intervin asupra costului de dezvoltare i efortului. Creterea nelegerii costurilor produselor software ne permite s identificm strategii de cretere a productivitii, cele mai importante fiind:

Scrierea de mai puin cod: Mrimea sistemului este una din cauzele principale ale efortului i costului. Prin metode care ncearc s reduc mrimea, cum ar fi utilizarea de limbaje de nivel nalt, reutilizarea componentelor sau refactorizarea, se pot obine reduceri semnificative;

Stimularea oamenilor s lucreze la capacitatea maxim: Capacitatea de a lucra att individual ct i n echip are un mare impact asupra productivitii. Angajarea celor mai buni oameni este de obicei o afacere profitabil. O mai bun stimulare, condiii mai bune de lucru, cursurile de perfecionare asigur oportuniti de cretere a productivitii;

Evitarea refacerii componentelor dezvoltate anterior: Studiile au artat c pentru a rescrie ceea ce s-a produs deja este necesar un efort considerabil. Prin aplicarea unor tehnici precum

prototipizarea i prin utilizarea metodelor de programare orientat pe obiecte se pot reduce semnificativ costurile;

Dezvoltarea i folosirea mediilor de dezvoltare integrate, cu instrumentele ce pot ajuta la eliminarea sau eficientizarea unor etape.


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

3

Numeroase studii au fost efectuate cu scopul de a estima efortul necesar pentru activitile elementare de programare. Primele experimente au fost realizate de Halstead (1977). La baza

modelului su st faptul c numrarea liniilor de cod poate constitui o problem, chiar dac avem o definiie exact a termenului linie de cod. Unele linii sunt mult mai complicate dect altele. Conform teoriei lui Halstead, este mai bine s se porneasc de la un numr de uniti sintactice, dup cum sunt recunoscute de compilator. Halstead face distincia ntre operatori i operanzi. Operatorii denot o operaie; exemple sunt operatorii standard (+, -, *, etc.), dar i semnul de punctuaie punct i virgul (;) care arat structura unei instruciuni i construcii cum ar fi if-then-else i while-do. Operanzii nseamn date: variabile i constante. Calcularea numrului de operatori i operanzi dintr-un program va oferi o msur mai bun a mrimii dect simpla calculare a numrului de linii.

n modelul Halstead, cele patru entiti de baz pentru un program sunt:

n1 = numrul de operatori diferii;

n2 = numrul de operanzi diferii;

N1 = numrul total de apariii ale operatorilor;

N2 = numrul total de apariii ale operanzilor;

Relaiile modelului Halstead sunt urmtoarele:

Vocabularul: n = n1 + n2

Lungimea implementrii: N = N1 + N2

Ecuaia lungimii: N' = n1log2n1 + n2log2n2

Volumul programului: V = N log2n

Dificultatea: 2

21

2 n

NnD

Efortul: VDE

Astfel se obine o rafinare a msurii numrului de linii simple de cod, LOC. Att LOC ct i N ofer o bun corelaie cu efortul de programare. De aceea este important s se gseasc modaliti de estimare a acestora n primele etape ale implementrii. Valoarea lui N depinde de n1 i n2. Valoarea lui n1 este, de cele mai multe ori, un factor constant pentru programele scrise ntr-un

anumit limbaj de nivel nalt i depinde de limbajul de programare ales. De exemplu, pentru un limbaj dat, numrul maxim de operatori care poate fi utilizat n orice program este fix: toi sunt prezentai n sintaxa limbajului. Majoritatea programelor vor folosi un mare procent din acestea, cel puin o dat. O ipotez consider c n2 este determinat n principal de numrul de variabile (VARS) care apar n program. Bazndu-se pe aceste presupuneri, a fost enunat urmtoarea relaie empiric:

VARSLOC 31,5102

Astfel, fiecare program va conine aproximativ 100 de linii de cod, plus 5 linii suplimentare pentru fiecare variabil ce apare n program. Primele experimente arat c n acest fel se pot obine aproximri destul de corecte ale mrimii i efortului necesar. Valoarea estimat a lui VARS poate fi obinut relativ devreme dac este folosit o metod de proiectare top-down n combinaie cu un limbaj de nivel nalt.

Generalizarea acestor rezultate la programe mai mari nu este indicat. n programele mai complexe, factori precum interfaa dintre componente i comunicarea necesar ntre persoanele implicate joac un rol ce nu poate fi neglijat.


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

4

Cunoscnd mrimea estimat a unui proiect, suntem interesai n continuare s evalum timpul de dezvoltare necesar. ntr-o abordare naiv am putea considera c un proiect ce necesit 60 de luni-om poate fi realizat ntr-un an cu o echip de 5 persoane sau ntr-o lun cu o echip de 60 de persoane. Aceast abordare este ns prea simplist. Un proiect de o anumit dimensiune corespunde unei anumite perioade de timp fizic. Dac ncercm s micorm prea mult acest timp nominal de dezvoltare, intrm ntr-o zon imposibil, iar probabilitatea unui eec crete.

Costurile estimate au deseori o culoare politic, iar rezultatele sunt determinate de argumente care nu au o natur tehnic. Motive tipice care reflect aceste argumente non-tehnice sunt prezentate n exemplele urmtoare:

Dac avem 12 luni pentru a finaliza o lucrare, ea va necesita 12 luni. Acest motiv poate fi privit ca o variant a legii Parkinson: munca ocup tot timpul disponibil;

Dac tim c a fost fcut o ofert de 100.000 de euro de ctre concuren, noi vom face o ofert de 90.000 de euro (metoda preului de ctig);

Dorim s ne promovm produsul la un anumit trg de tehnic de calcul i din acest motiv programul trebuie scris i testat n urmtoarele 9 luni, dei realizm c timpul este limitat;

Proiectul poate fi dezvoltat ntr-un an, dar eful nu ar accepta acest termen. tim c termenul de 10 luni este acceptabil i atunci l programm pentru 10 luni.

Aceste estimri pot avea efecte negative, dup cum s-a demonstrat frecvent n istoria ingineriei programrii. Estimrile vor depinde mai mult de argumentele politice ale prilor interesate dect de realitatea tehnic a proiectului. Pe de alt parte, simpla comparare a caracteristicilor unui proiect cu un proiect precedent nu garanteaz o estimare corect a costului su. Dac o echip lucreaz n mod repetat la proiecte asemntoare, timpul de lucru necesar scade, datorit experienei acumulate. n 1968, unei echipe de programatori i s-a cerut s dezvolte un compilator FORTRAN pentru trei maini diferite. Efortul necesar pentru aceste trei proiecte este descris n tabelul de mai jos:

Compilatorul Efortul (n luni-om)

1 72

2 36

3 14

Pentru estimarea costului se poate apela la serviciul unui expert, care apeleaz la propria sa experien. Factori greu de cuantificat, precum caracteristicile de personalitate sau unele caracteristici neobinuite ale proiectului, pot fi astfel luai n considerare. n acest caz, calitatea estimrii nu poate depi calitatea expertului.


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

5

Pentru o estimare mai precis se pot solicita mai muli experi. Totui, dac un grup de persoane trebuie s gseasc mpreun o soluie, se observ c unii membri ai grupului au un impact mai mare asupra rezultatului dect ceilali. Unele persoane nu i exprim opinia sau sunt impresionate de celelalte. Acest lucru poate avea un impact negativ asupra rezultatului final. Pentru

a anticipa acest efect negativ, putem folosi metoda Delphi. n metoda Delphi, fiecare expert i expune opinia n scris. Un moderator colecteaz estimrile obinute astfel i le redistribuie celorlali experi. n acest proces nu sunt asociate numele experilor cu estimrile lor. Fiecare expert pred apoi o nou estimare bazat pe informaiile primite de la moderator. Procesul continu pn cnd se ajunge la un consens.

O alt metod pentru obinerea unei estimri mai bune se bazeaz pe un expert care s realizeze mai multe estimri: o estimare optimist a, o estimare realist m i o estimare pesimist b. Efortul ateptat va fi:

6

4 bmaE

Aceast estimare este mai bun dect dac se consider numai media aritmetic a lui a i b.

3. Modele algoritmice clasice

Nelson (1966) ofer un model liniar pentru estimarea efortului necesar pentru un proiect de dezvoltare software. Modelele liniare au urmtoarea form:

n

i

ii xaaE1

0

Coeficienii ai sunt constante, iar xi reprezint factorii care au impact asupra efortului necesar. Un numr mare de factori poate influena productivitatea i implicit efortul. Analiznd cu atenie datele proiectelor precedente i diferite combinaii de factori, se poate ncerca obinerea unui model cu un numr 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 ecuaie, E reprezint numrul estimat de luni-om necesare. Semnificaia factorilor xi i domeniile lor de definiie sunt prezentate n tabelul urmtor:

Factor Descriere Valori posibile x1 Instabilitatea specificaiilor cerinelor 0-2

x2 Instabilitatea proiectrii 0-3

x3 Procentajul de instruciuni matematice 0-100

x4 Procentajul de instruciuni I/O 0-100

x5 Numrul subprogramelor numr

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

x7 Aplicaie comercial 0 (da) / 1 (nu)

x8 Program de sine stttor 0 (da) / 1 (nu)

x9 Primul program pe aceast main 1 (da) / 0 (nu)

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

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

x12 Maina gazd diferit de maina int 1 (da) / 0 (nu)

x13 Numr de erori numr

x14 Dezvoltare pentru o organizaie militar 0 (da) / 1 (nu)


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

6

Putem face mai multe observaii asupra acestui model. De exemplu, la dezvoltarea programelor pentru aplicaiile de aprare, n care programele sunt ncorporate n maini diferite de maina gazd, cum ar fi programul de control al zborului pentru rachete, factori precum x12 i x14 au cu siguran un impact mare asupra costului. Un alt exemplu este creterea efortului atunci cnd se folosete limbajul de asamblare n locul unui limbaj de nivel nalt (x6).

n general modelele liniare nu funcioneaz foarte bine. Dei exist un numr mare de factori care influeneaz productivitatea, este puin probabil ca ei s intervin n mod independent i liniar. Trebuie atras atenia asupra preciziei acestui tip de formul i asupra capcanei exprimat n sloganul: exist trei tipuri de minciuni: minciuni mici, minciuni mari i statistici. Formula lui Nelson este rezultatul analizei statistice a datelor unor proiecte reale 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. Semnificaia formulei este urmtoarea: 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, rmnnd o probabilitate diferit de zero ca acesta s fie n afara intervalului. Aplicabilitatea acestor estimri este puternic influenat de mrimea intervalului i de probabilitatea ca valoarea real a costului s aparin ntr-adevr acelui interval. n special pentru proiectele care 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, se obine un cost estimativ iar costul final este suma costurilor modulelor, cu o corecie aplicat datorit integrrii modulelor. Wolverton descrie un model n care o matrice de costuri este folosit ca punct de plecare n determinarea costurilor modulelor. n aceast matrice exist un numr limitat de tipuri diferite de module i un numr de niveluri de complexitate. Tabelul urmtor ilustreaz o matrice ipotetic de costuri. Elementele matricei reflect costul pentru fiecare linie de cod.

Tipul modulului

Complexitate

Mic Mare

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 mrime Sk, rezult un

cost al modulului ijkk CSM .

Acest tip de model are la rndul su unele probleme. Utilizatorul trebuie s estimeze subiectiv clasa de complexitate din care face parte fiecare modul, ceea ce determin un grad mare de nesiguran. Ali factori care au un impact asupra productivitii, cum ar fi experiena n programare i caracteristicile hardware, nu sunt luai n considerare. Extinderea matricei pentru a include i aceti factori ar crete gradul de subiectivitate al metodei.


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

7

4. Modele algoritmice moderne

n seciunile anterioare am remarcat faptul c efortul de programare este corelat cu mrimea programului. Exist i modele neliniare care exprim aceast legtur. O form general este:

),...,()( 1 nc xxfKLOCbaE ,

unde KLOC reprezint mrimea programului n kilo-linii de cod, iar E reprezint efortul n luni-om.

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

n general, formula de baz este:

cKLOCbaE

Aceasta este obinut printr-o analiz de regresie a datelor proiectelor disponibile. Primul generator de cost este mrimea programului, msurat n linii de cod. Acest cost nominal estimat este apoi adaptat pentru un numr de factori care influeneaz productivitatea (generatorii de cost secundari). De exemplu, dac unul din factorii folosii reprezint experiena echipei de programatori aceasta poate cauza o corecie a costului nominal estimat cu 1,50, 1,20, 1,00, 0,80, 0,60 pentru un nivel de expertiz foarte sczut, sczut, mediu, nalt i respectiv foarte nalt. Tabelul urmtor conine formulele de baz pentru relaia dintre mrimea programului i efort. Din motivele enunate anterior este dificil s comparm 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

Cnd c < 1, se remarc apariia unui fenomen foarte bine cunoscut din teoria economic. Pentru producia de mas, se presupune c este mai ieftin s se produc mari cantiti din acelai produs. Costurile fixe vor fi mprite astfel unui numr mai mare de uniti, ceea ce conduce la scderea costului pe unitate. n cazul programelor, liniile de cod sunt produsul, deci presupunem c producnd multe linii de cod, scade costul pe linie de cod. Motivul este costul instrumentelor

scumpe precum mediile de dezvoltare, instrumentele de testare sau generatoarele de programe, care

poate fi distribuit unui numr mai mare de linii de cod. n cazul opus, cnd c > 1, observm c dup un anumit punct, producerea de uniti

suplimentare implic nite costuri suplimentare. Programele foarte mari sunt mult mai scumpe, deoarece crete necesitatea de comunicare i de control managerial, iar problemele i interfeele sunt mai complexe. Deci fiecare linie de cod suplimentar necesit mai mult efort.

Primul tip de relaii (c > 1) pare mai plauzibil. Pentru proiecte foarte mari, efortul crete mai mult dect liniar cu mrimea. Alegerea unui anumit model depinde n principal de gradul de complexitate a interfarii modulelor proiectului.

Este evident c valoarea exponentului c influeneaz foarte mult valoarea calculat E, n special pentru valori mari ale KLOC. Tabelul urmtor prezint valorile lui E, calculate prin metodele prezentate anterior i pentru cteva 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, acelai model genereaz estimri ale costului cu un ordin de mrime mai mari dect prin aplicarea metodei Walston-Felix.


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

8

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 observaii nu trebuie s ne conduc la concluzia c aceste metode sunt inutile. Exist diferene mari ntre caracteristicile mulimilor de proiecte pe care se bazeaz diferite modele. tim c numerele utilizate n modele provin n 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 este obinerea unei estimri a mrimii programului de la nceput. Cum am putea s estimm numrul de pagini ale unui roman care nu a fost scris nc? Chiar dac tim numrul de personaje, de locaii i intervalul n care se va desfura povestea, este dificil estimarea realist a mrimii nc de la nceput. Cu ct naintm n realizarea proiectului, cu att va fi mai exact estimarea mrimii. Dac proiectarea se apropie de final, ne putem forma o impresie rezonabil asupra mrimii programului rezultat. Dar numai cnd sistemul va fi predat vom cunoate numrul exact.

4.1. Modelul Walston-Felix

Ecuaia ce st la baza modelului Walston-Felix (1977) este: 91,02,5 KLOCE . Modelul a

fost creat prin analiza a 60 de proiecte de la IBM. Aceste proiecte erau complet diferite ca mrime, iar programele au fost scrise n mai multe limbaje de programare. Totui nu reprezint o surpriz faptul c dac aplicm acest model chiar unei submulimi a celor 60 de proiecte, nu vom avea rezultate satisfctoare.

ncercnd s explice aceste rezultate dintr-o plaj mare de valori, autorii au identificat 29 de variabile care influeneaz n mod sigur productivitatea. Pentru fiecare din aceste variabile au fost considerate trei niveluri: mare, mediu i mic. Pentru un numr de 51 de proiecte, Walston i Felix au determinat nivelul fiecrei variabile din cele 29, mpreun cu productivitatea obinut, exprimat ca numr de linii de cod pe lun-om. Aceste rezultate sunt prezentate n tabelul urmtor pentru cteva 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 sczut. Pentru o interfa de complexitate nalt sau medie, productivitatea este de 295 i respectiv 124 de linii de cod pe lun. Ultima coloan reprezint variaia productivitii, PC (engl. productivity change), diferena dintre valorile maxime i minime.

Variabila Productivitatea medie pentru

valoarea variabilei PC

Complexitatea interfeei utilizator < normal

500

normal 295

> normal 124

376

Calificarea i experiena personalului mic 132

medie

257

mare

410 278

Experien anterioar cu aplicaii similare minim

146

medie

221

vast 410

264

Procentajul de programatori participani n faza de proiectare

< 25%

153

25 50% 242

> 50%

391 238

Raportul dintre mrimea medie a echipei i durata proiectului (persoane/lun)

< 0,5

305

0,5 0,9 310

> 0,9

171 134


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

9

Walston i Felix consider c indexul productivitii I poare fi determinat pentru noile proiecte dup urmtoarea relaie:

29

1i

ii XWI ,

unde ponderile iW sunt definite astfel:

)(log5,0 10 ii PCW .

n relaia de mai sus, iPC reprezint variaia productivitii factorului i. Pentru primul factor

din tabelul de mai sus, complexitatea interfeei cu utilizatorul, rezult urmtoarele: 3761 PC , deci

29,11 W . Variabilele iX pot lua valorile 1, 0 i 1, unde factorul corespunztor este de nivel

sczut, mediu sau nalt. Indexul productivitii obinut poate fi tradus ntr-o productivitate ateptat: linii de cod scrise pe lun-om.

Numrul factorilor luai n considerare n acest model este destul de ridicat: 29 de factori din 51 de proiecte. De asemenea, nu este clar cum aceti factori se influeneaz unul pe cellalt. Un alt dezavantaj ar fi c numrul de alternative pentru fiecare factor este de numai 3 i nu ofer destule opiuni pentru situaiile practice.

4.2. Modelul COCOMO

COCOMO (COnstructive COst MOdel) este una dintre cele mai bine documentate metode

de estimare a costului (Boehm, 1981). n forma sa cea mai simpl, numit Basic COCOMO, formula care exprim legtura dintre efort i mrimea programului este:

cKLOCbE ,

unde b i c sunt constante ce depind de tipul proiectului 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 organizaia lor. Astfel, ei pot s lucreze de la nceput, nefiind necesare investiii iniiale. Proiectele de acest tip sunt de multe ori programe relativ mici;

Integrate: Proiectele de acest tip implic sisteme unde mediul impune constrngeri severe. Produsul va fi integrat ntr-un mediu foarte strict. Exemple de asemenea proiecte sunt

programele de control al traficului aerian sau aplicaiile militare;

Semidetaate: 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 urmtoarele valori:

Clasa de proiect b c

organic 2,4 1,05

semidetaat 3,0 1,12

integrat 3,6 1,20


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

10

Tabelul urmtor prezint estimri ale efortului pentru fiecare din cele trei moduri, pentru diferite valori ale KLOC (dei un proiect organic de un milion de linii de cod nu este realist). Se observ influena foarte mare a constantei c asupra estimrilor obinute. Estimrile efortului sunt exprimate tot n luni-om.

KLOC organic semidetaat 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

4.3. Analiza punctelor funcionale

Analiza punctelor funcionale (Albrecht, 1983) este o metod de estimare a costurilor care ncearc s evite problemele determinate de estimarea dimensiunii codului. APF se bazeaz pe numrarea diferitelor structuri de date utilizate. Se presupune c acest numr este un bun indicator pentru dimensiunea proiectului. Metoda este potrivit mai ales pentru aplicaiile comerciale, n care structura datelor are o foarte mare importan. APF este mai puin indicat pentru proiectele n care algoritmii joac rolul dominant, de exemplu compilatoarele sau aplicaiile de timp real. Unul din scopurile principale ale APF este evaluarea sistemului din punctul de vedere al

utilizatorilor. De aceea, analiza se bazeaz pe modalitile n care diveri utilizatori interacioneaz cu aplicaiile. Astfel, sistemul ndeplinete cinci funcii fundamentale:

funcii referitoare la date: o fiiere interne logice; o fiiere externe de interfa;

funcii tranzacionale: o intrri externe; o ieiri externe; o interogri externe.

Fiierele interne logice (engl. Internal Logical Files, ILF): Permit utilizatorilor s foloseasc datele pe care trebuie s le ntrein. De exemplu, un pilot poate introduce datele de navigare la un terminal din carling nainte de plecare. Datele sunt stocate ntr-un fiier i pot fi modificate n timpul misiunii. Pilotul este deci responsabil pentru ntreinerea acestor date.

Fiierele externe de interfa (engl. External Interface Files, EIF): n acest caz, utilizatorul nu este responsabil pentru ntreinerea datelor; acestea sunt localizate n alt sistem care le ntreine. Utilizatorul sistemului analizat solicit datele doar pentru informare. De exemplu, un pilot se poate informa asupra poziiei cu ajutorul sateliilor GPS sau al sistemelor de la sol. El nu are responsabilitatea actualizrii acestor date, ns le poate accesa n timpul zborului.

Intrrile externe (engl. External Input, EI): Permit utilizatorului s ntrein fiierele interne logice prin operaii de adugare, modificare i tergere. Ieirile externe (engl. External Output, EO): Permit utilizatorului s produc date de ieire. De exemplu, pilotul poate s afieze separat viteza la sol i viteza real n aer, informaii derivate din datele interne (pe care le poate ntreine) i cele externe (pe care le poate accesa). Interogrile externe (engl. External Inquiries, EQ): Pentru ca utilizatorul s poat selecta i afia datele din fiiere, el trebuie s introduc informaii de selecie pentru a gsi datele n conformitate cu anumite criterii. n aceast situaie datele din fiiere nu sunt modificate, ci doar


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

11

cutate i furnizate. De exemplu, dac pilotul afieaz date cu privire la relieful solului, date stocate anterior, rezultatul este regsirea direct a informaiilor. Prin ncercri repetate, s-au stabilit ponderi pentru fiecare din aceste entiti. Numrul de puncte funcionale neajustate este:

EQEOEIEIFILFPFN 454710

n funcie de complexitatea tipurilor de date, se disting o serie de valori pentru aceste puncte funcionale, prezentate n tabelul urmtor.

Tip Nivel de complexitate

Simplu Mediu Complex

ILF 7 10 15

EIF 5 7 10

EI 3 4 6

EO 4 5 7

EQ 3 4 6

Pentru ajustarea suplimentar a estimrilor, se iau n calcul i alte 14 caracteristici care influeneaz dezvoltarea aplicaiilor: comunicaiile de date, funciile distribuite, performana, folosirea masiv a configuraiilor, rata tranzaciilor, intrrile de date online, eficiena utilizatorilor finali, actualizrile online, prelucrrile complexe, refolosirea, uurina la instalare, uurina la folosire, locaiile multiple, facilitarea modificrilor. Influena fiecrei caracteristici este evaluat pe o scar de la 0 (nu influeneaz) la 5 (influen puternic). Gradul de influenare (GI) este suma acestor puncte pentru toate caracteristicile. Se calculeaz apoi factorul de complexitate tehnic:

GIFCT 01,065,0 .

Punctele funcionale ajustate (PF) se obin astfel:

FCTPFNPF .

Avantajul principal al analizei punctelor funcionale este faptul c msura productivitii este un rezultat natural, deoarece punctele funcionale 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 estimrile privind durata proiectului ca ntreg.

5. Distribuirea forei de munc n timp

Norden a studiat distribuia forei de munc n timp ntr-un numr de proiecte de dezvoltare software din anii 60. A descoperit c aceast distribuie avea deseori o form caracteristic, bine aproximat de distribuia Rayleigh. Bazndu-se pe aceast descoperire, Putnam a dezvoltat un model de estimare a costului n care fora de munc necesar la un moment de timp t este dat de:

2

e2)( attaKtFM ,


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

12

unde a este un factor de accelerare care determin panta iniial a curbei, iar K reprezint fora de munc total necesar, incluznd faza de ntreinere. K este egal cu aria zonei delimitate de curba Rayleigh, reprezentat n figura urmtoare.

Integrarea ecuaiei pentru FM(t) determin efortul cumulat I:

)e1()(2atKtI

Dac vom considera momentul de timp T n care curba Rayleigh ajunge n punctul de

maxim, atunci 22

1

Ta . Acest moment este apropiat de momentul de timp n care proiectul este

predat clientului. Aria delimitat de curba Rayleigh ntre punctele 0 i T este o bun aproximare a efortului iniial de dezvoltare. Pentru acesta obinem:

KTIE 3945,0)( .

Acest rezultat este foarte apropiat de o regul euristic des utilizat: 40% din efortul total este consumat pentru dezvoltarea efectiv, n timp ce 60% este consumat pentru ntreinere. Specificarea cerinelor nu este inclus n model i deci estimrile nu se pot aplica dect ncepnd cu proiectarea i implementarea.

Putnam a folosit observaii empirice legate de nivelurile de productivitate pentru a deriva ecuaia software-ului din curba Rayleigh:

3/43/1 tEkD ,

unde D este dimensiunea proiectului, E este efortul total n ani-om, t este timpul scurs pn la lansare (n ani) iar k este un factor tehnologic bazat pe 14 componente, precum:

maturitatea general a proiectului i tehnicile de management;

gradul de utilizare a tehnicilor de ingineria programrii;

nivelul limbajelor de programare folosite;

capacitatea i experiena echipei de dezvoltare;

complexitatea aplicaiei.

Puterea supraunitar a timpului are implicaii puternice asupra alocrii resurselor n proiecte mari. Prelungiri relativ mici ale datei de livrare pot determina reducerea substanial a efortului.

Pentru estimarea efortului, Putnam a introdus ecuaia acumulrii forei de munc (engl. manpower-buildup):


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

13

3/ tEA ,

unde A este accelerarea forei de munc iar E i t au semnificaiile de mai sus. Accelerarea forei de munc este 12,3 pentru proiecte software noi, cu multe interfee i interaciuni cu alte sisteme, 15 pentru sisteme de sine stttoare i 27 pentru reimplementri ale sistemelor existente.

Pe baza celor dou ecuaii, eliminm timpul i determinm efortul:

7/47/9)/( AkDE .

Acest rezultat este interesant deoarece arat c efortul este proporional cu dimensiunea la

puterea 286,17/9 , valoare similar cu factorul c al lui Boehm de 1,20.

Evident, scurtarea timpului de dezvoltare implic un numr mai mare de persoane necesare pentru proiect. Referindu-ne la modelul curbei Rayleigh, scurtarea timpului de dezvoltare conduce

la mrirea valorii a, factorul de accelerare care determin panta iniial a curbei. Vrful curbei Rayleigh se deplaseaz spre stnga-sus. Astfel obinem o cretere a puterii necesare la nceputul proiectului i o for de munc maxim mai mare.

Exist i dezavantaje ale acestei deplasri. Mai multe studii au artat c productivitatea individual scade odat cu creterea echipei. Conform lui Brooks, exist dou cauze ale acestui fenomen:

Dac o echip se mrete, crete timpul acordat comunicrii cu ceilali membri ai echipei (pentru consultare, sincronizarea sarcinilor etc.);

Dac este adugat for de munc suplimentar unei echipe n timpul dezvoltrii unui proiect, mai nti scade productivitatea. Noii membri ai echipei nu sunt productivi de la

nceput, cnd necesit ajutor, deci timp, de la ceilali membri ai echipei n timpul procesului de nvare. Luate mpreun, acestea conduc la scderea productivitii totale.

Combinnd aceste dou informaii, ajungem la fenomenul cunoscut sub denumirea de legea lui Brooks: adugarea de personal la un proiect ntrziat l va ntrzia i mai mult.

Analiznd o mare baz de date de proiecte, Conte a descoperit urmtoarea relaie ntre productivitatea medie L (msurat n linii de cod pe lun-om) i mrimea medie a unei echipe P:

.777

PL

Formula atest faptul c productivitatea individual scade cu mrimea echipei. Numrul de legturi de comunicare ntre persoanele implicate ntr-un proiect este determinat de mrimea i structura echipei. Dac ntr-o echip de mrime P fiecare membru trebuie s-i coordoneze

activitile sale cu toi ceilali din echip, numrul legturilor de comunicaie va fi: 2

)1( PP. Dac

fiecare membru trebuie s comunice numai cu un singur alt membru, acest numr va fi: 1P . Mai puin comunicare dect aceasta nu este rezonabil, deoarece ne-am confrunta cu echipe independente.

Numrul de legturi de comunicaie variaz de la aproximativ P la aproximativ 2/2P .

ntr-o organizare ierarhic, aceasta conduce la P ci de comunicaie, cu )2,1( .

Pentru un membru al echipei, numrul de legturi de comunicaie variaz de la 1 la 1P . Dac productivitatea individual maxim este L i fiecare legtur de comunicaie conduce la o pierdere a productivitii l, atunci productivitatea medie va fi:


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

14

)1( PlLL ,

unde ]1,0( este o msur a numrului de legturi de comunicaie. Presupunem c exist cel

puin o persoan care s comunice cu mai mult de o persoan, deci > 0. Pentru o echip de mrime P, aceasta conduce la o productivitate total:

)1( PlLPLPLtot .

Pentru o mulime dat de valori pentru L, l i , pentru valori cresctoare ale lui P, aceast funcie crete de la 0 la o valoare maxim i apoi scade din nou. Deci exist o mrime optim a

echipei optP , care conduce la o productivitate maxim a echipei. Productivitatea echipei pentru

diferite valori ale lui P este dat n tabelul de mai jos. Aici, presupunem c productivitatea individual este de 500 LOC / lun-om (L = 500), iar scderea de productivitate este de 10% pe canal de comunicaie (l = 50). Cu interaciune complet ntre membrii echipei ( = 1), rezult o echip optim de 5,5 persoane:

Mrimea echipei Productivitatea individual Productivitatea total

1 500 500

2 450 900

3 400 1200

4 350 1400

5 300 1500

5,5 275 1512

6 250 1500

7 200 1400

8 150 1200

6. Concluzii

n acest curs au fost prezentate diferite modele de estimare a efortului necesar pentru

dezvoltarea unui proiect software, a forei de munc i a timpului efectiv de dezvoltare. n final, s-a prezentat o modalitate de estimare a distribuiei forei de munc n timp pentru gsirea numrului optim de persoane implicate ntr-un proiect.


Flor

in L

eon,

Man

agem

entu

l pro

iect

elor

sof

twar

e, h

ttp://

florin

leon

.bye

thos

t24.

com

/cur

s_m

ps.h

tm

Documents

Estimarea costului unui proiect software