Sunteți pe pagina 1din 14

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 , 1
7 , 2 KLOC E =

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
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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.
Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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:

- n
1
= numrul de operatori diferii;
- n
2
= numrul de operanzi diferii;
- N
1
= numrul total de apariii ale operatorilor;
- N
2
= numrul total de apariii ale operanzilor;

Relaiile modelului Halstead sunt urmtoarele:

- Vocabularul: n = n
1
+ n
2

- Lungimea implementrii: N = N
1
+ N
2

- Ecuaia lungimii: N' = n
1
log
2
n
1
+ n
2
log
2
n
2

- Volumul programului: V = N log
2
n
- Dificultatea:
2
2 1
2 n
N n
D =
- Efortul: V D E =

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 n
1
i n
2
.
Valoarea lui n
1
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 n
2
este determinat n principal de numrul de variabile (VARS)
care apar n program. Bazndu-se pe aceste presupuneri, a fost enunat urmtoarea relaie
empiric:

VARS LOC + = 31 , 5 102

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.
Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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.
Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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 b m a
E
+ +
=

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
i i
x a a E
1
0


Coeficienii a
i
sunt constante, iar x
i
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:

14 13 12 11 10 9 8
7 6 5 4 3 2 1
20 , 25 54 , 0 55 , 29 61 , 30 82 , 58 35 , 12 5 , 13
45 , 21 28 , 7 40 , 0 46 , 0 51 , 0 73 , 10 15 , 9 63 , 33
x x x x x x x
x x x x x x x E
+ + + + + +
+ + + + + + =


n aceast ecuaie, E reprezint numrul estimat de luni-om necesare. Semnificaia factorilor
x
i
i domeniile lor de definiie sunt prezentate n tabelul urmtor:

Factor Descriere Valori posibile
x
1
Instabilitatea specificaiilor cerinelor 0-2
x
2
Instabilitatea proiectrii 0-3
x
3
Procentajul de instruciuni matematice 0-100
x
4
Procentajul de instruciuni I/O 0-100
x
5
Numrul subprogramelor numr
x
6
Utilizarea unui limbaj de nivel nalt 0 (da) / 1 (nu)
x
7
Aplicaie comercial 0 (da) / 1 (nu)
x
8
Program de sine stttor 0 (da) / 1 (nu)
x
9
Primul program pe aceast main 1 (da) / 0 (nu)
x
10
Dezvoltare concurent de hardware 1 (da) / 0 (nu)
x
11
Utilizarea dispozitivelor random-access 1 (da) / 0 (nu)
x
12
Maina gazd diferit de maina int 1 (da) / 0 (nu)
x
13
Numr de erori numr
x
14
Dezvoltare pentru o organizaie militar 0 (da) / 1 (nu)

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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 x
12
i x
14
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 (x
6
).
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:

| o o > + s s ) ) 1 ( ) 1 (( E R E P ,

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 S
k
, rezult un
cost al modulului
ij k k
C S M = .
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.



Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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 n
c
x x f KLOC b a E + = ,

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 n
x x f este o funcie care depinde de valorile factorilor
n
x x ,...,
1
.
n general, formula de baz este:

c
KLOC b a E + =

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 , 1
7 , 0 KLOC E =
Boehm
05 , 1
4 , 2 KLOC E =
Walston-Felix
91 , 0
2 , 5 KLOC E =

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.

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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 , 0
2 , 5 KLOC E = . 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
Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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

=
=
29
1 i
i i
X W I ,

unde ponderile
i
W sunt definite astfel:

) ( log 5 , 0
10 i i
PC W = .

n relaia de mai sus,
i
PC reprezint variaia productivitii factorului i. Pentru primul factor
din tabelul de mai sus, complexitatea interfeei cu utilizatorul, rezult urmtoarele: 376
1
= PC , deci
29 , 1
1
= W . Variabilele
i
X 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:

c
KLOC b E = ,

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

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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
Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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:

EQ EO EI EIF ILF PFN + + + + = 4 5 4 7 10

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:

GI FCT + = 01 , 0 65 , 0 .

Punctele funcionale ajustate (PF) se obin astfel:

FCT PFN PF = .

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
e 2 ) (
at
t a K t FM

= ,

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


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:

) e 1 ( ) (
2
at
K t I

=

Dac vom considera momentul de timp T n care curba Rayleigh ajunge n punctul de
maxim, atunci
2
2
1
T
a = . 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:

K T I E 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 / 4 3 / 1
t E k D = ,

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):
Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


13
3
/ t E A = ,

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 / 4 7 / 9
) / ( A k D E = .

Acest rezultat este interesant deoarece arat c efortul este proporional cu dimensiunea la
puterea 286 , 1 7 / 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
P
L =

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 ( P P
. Dac
fiecare membru trebuie s comunice numai cu un singur alt membru, acest numr va fi: 1 P . 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 /
2
P .
ntr-o organizare ierarhic, aceasta conduce la
o
P ci de comunicaie, cu ) 2 , 1 ( e o .
Pentru un membru al echipei, numrul de legturi de comunicaie variaz de la 1 la 1 P .
Dac productivitatea individual maxim este L i fiecare legtur de comunicaie conduce la o
pierdere a productivitii l, atunci productivitatea medie va fi:

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m


14

) 1 ( = P l L L ,

unde ] 1 , 0 ( e 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 ( = = P l L P L P L
tot
.

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
opt
P , 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.

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm
F
l
o
r
i
n

L
e
o
n
,

M
a
n
a
g
e
m
e
n
t
u
l

p
r
o
i
e
c
t
e
l
o
r

s
o
f
t
w
a
r
e
,

h
t
t
p
:
/
/
f
l
o
r
i
n
l
e
o
n
.
b
y
e
t
h
o
s
t
2
4
.
c
o
m
/
c
u
r
s
_
m
p
s
.
h
t
m