Estimarea costurilor unui sistem software

Estimarea costurilor necesită o atenŃie specială în cadrul procesului de dezvoltare a unui

proiect software. łinând cont de faptul că un produs software este unic, experienŃa unor proiecte
anterioare trebuie utilizată cu precauŃie. CircumstanŃele în care se realizează noul produs pot fi
diferite, plecând de la specificaŃii noi, alte platforme hardware şi software şi continuând cu noi
aplicaŃii de dezvoltare şi metodologii de proiectare.
Odată cu creşterea complexităŃii sistemelor software, orice estimare poate duce la o alocare
inadecvată a resurselor. Resursele limitate determină întârzierea proiectului, iar alocarea
supradimensionată duce la o scădere substanŃială a profitului.
În practică se iau în considerare trei valori pentru costuri: valoarea cea mai probabilă, limita
maximă şi limita minimă. Aceste valori reflectă factorul de incertitudine în ceea ce priveşte
estimarea costului unui proiect software. În general, nivelul de incertitudine scade pe parcursul
dezvoltării produsului.
Necesitatea introducerii de modele pentru estimarea costului este justificată de un număr de
cerinŃe comune ale proiectelor software:
• Identificarea, stabilirea priorităŃilor şi justificarea resurselor necesare.
• Negocierea bugetului adecvat şi stabilirea echipei proiectului.
• Optimizarea costului, productivităŃii, calităŃii şi funcŃionalităŃii.
• Nevoia de cuantificare a impactului riscului.
• Stabilirea impactului schimbărilor.
• Modificarea bugetelor în funcŃie de apariŃia unor evenimente neprevăzute.
Există doi predictori principali ai costului unui proces software: efortul aşteptat şi timpul
consumat pentru realizarea acestuia. Metodele de estimare a costului întâlnite în practică sunt
următoarele:
1. Opiniile experŃilor – se bazează pe experienŃa experŃilor acumulată în dezvoltarea altor
proiecte software;
2. Analogia. Cheia acestei metode este de a realiza judecăŃi bazate pe proiecte anterioare, de
a utiliza estimările obŃinute în proiecte anterioare şi de ale aplica în proiectul curent. Estimarea
iniŃială este ajustată pe baza diferenŃei dintre proiectele anterioare şi cel curent. Rezultatul estimării
depinde de posibilitatea cuantificării nivelului de similaritate dintre proiectele anterioare şi cel
curent. Judecarea greşită a similarităŃilor şi diferenŃelor poate fi o sursă a estimărilor eronate.
3. Descompunerea. Această metodă presupune împărŃirea proiectului în sub-taskuri,
estimarea costului componentelor şi sumarea acestora într-o estimare generală. Sumarea se face
printr-o ponderare ce Ńine cont de complexitatea componentelor.
4. Modele PERT (Program Evaluation and Review Technique- Tehnica evaluării repetate a
programului). Efortul necesar se estimează plecând de la cea mai bună valoare posibilă, cea mai rea
valoare posibilă şi cea mai probabilă valoare conform următoarei formule:
A + 4⋅M + B
efort = , (1)
6
unde efort = nr ore muncă/activitate calculat în ipoteza că un singur om este alocat;
A = estimare pesimistă;
B = estimare optimistă;
M = estimarea cea mai frecventă.
Metoda permite compensarea riscului prin realizarea unei estimări avantajoase. Estimările A,
B şi M se realizează fie prin metode analogice, fie prin metoda Delphi, metode ce vor fi discutate
ulterior.
5. Modele matematice. Cele mai cunoscute modele din această categorie sunt COCOMO
(COnstructive COst Model – Modelul constructiv al costurilor), modele bazate pe curba Rayleigh şi

1
modele bazate pe analiza punctelor funcŃionale. Parametrii acestor modele se determină prin metode
statistice.

1. Modele bazate pe analiza punctelor funcŃionale

Această clasă de modele, ce are la bază punctele funcŃionale ale lui Albrecht, este în strânsă
legătură cu documentul de specificare a cerinŃelor, în care este determinată funcŃionalitatea
sistemului software. În esenŃă, această metodă de estimare a costurilor pleacă de la acele
caracteristici ale sistemului care pot conduce la obŃinerea unui rezultat bun. IntenŃia este de a
construi o măsură a dimensiunii proiectului ce poate fi disponibilă încă de la începutul procesului de
dezvoltare. Metoda este independentă de tehnologie. Pentru a putea construi un astfel de model se
identifică numărul de puncte cheie ce apar în sistem, care sunt în mod obişnuit derivate din
documentul de specificare a cerinŃelor şi anume:
• Intrările externe (IE) sunt intrările de la utilizator care furnizează date distincte orientate
pe aplicaŃie. Exemple de astfel de intrări sunt numele de fişiere şi selecŃiile din meniuri.
• Ieşirile externe (OE) sunt orientate spre utilizator; acestea sunt sub formă de rapoarte şi
mesaje.
• Cererile externe (CE) sunt intrări interactive ce necesită un răspuns.
• Fişierele externe (FE) asigură interfaŃa cu alte sisteme; utilizatorul nu este responsabil de
întreŃinerea datelor.
• Fişierele interne (FI) sunt fişierele principale ale sistemului; permit utilizatorilor să
folosească datele pe care trebuie să le întreŃină
Cu toate că aceste caracteristici ale sistemului software sunt definite mai degrabă informal,
identificarea lor nu este dificilă când se lucrează cu sisteme specifice. Pentru a ajusta nivelele de
complexitate pentru fiecare sub-funcŃie, se face o evaluare a complexităŃii. Această evaluare conŃine
trei nivele de complexitate: simplu, mediu şi complex.
În funcŃie de complexitatea tipurilor de date, se disting o serie de valori pentru aceste puncte
funcŃionale, prezentate mai jos:
Nivel de complexitate (pondere)
Tip
Simplu Mediu Complex
IE 3 4 6
OE 4 5 7
CE 3 4 6
FE 7 10 15
FI 5 7 10
Se observă faptul că fişierele externe au cea mai mare pondere. Fişiere interne au, de
asemenea, o contribuŃie semnificativă la complexitatea programului. Ieşirile externe, intrările
externe şi cererile externe au un nivel scăzut în această schemă. Acest nivel de evaluare a fişierelor
externe şi interne este o consecinŃă a ponderii mari pe care o au integrarea modulelor unui sistem şi
interfaŃarea cu alte sisteme în cadrul dezvoltării proiectului software.
Într-o primă fază se determină numărul de puncte funcŃionale neajustate (PFN) folosind
următoarea relaŃie:
PFN = ∑ tipi ⋅ ponderei . (2)
În faza a doua, numărul de puncte funcŃionale se rafinează folosind aşa numitul factor de
complexitate tehnică (FCT) care multiplică valoarea iniŃială a PFN producând numărul de puncte
funcŃionale ajustate (PFA):
PFA = PFN ⋅ FCT . (3)
Factorul de complexitate tehnică se calculează cu următoarea formulă obŃinută pe cale
experimentală:

2
 14
FCT = 0.65 + 0.1∑ ci , (4)
i =1

unde ci reprezintă următoarele caracteristici detaliate: funcŃii distribuite, comunicaŃii de date,

performanŃă, intrări de date on-line, actualizări on-line, prelucrări complexe, uşurinŃă la instalare,
facilităŃi de schimbare, refolosire, amplasări multiple, interfaŃă complexă, configuraŃii utilizate
masiv, utilizare operaŃională, capacitate de recuperare. InfluenŃa fiecărei caracteristici este evaluată
pe o scară de la 0 (nerelevantă) la 5 (influenŃă mare). Gradul de influenŃare este suma acestor puncte
pentru toate caracteristicile.
ObservaŃie. Factorul de complexitate tehnică poate varia între 0.65 şi 1.35, deci o variaŃie de ±35%
faŃă de valoarea nominală.
Exemplu. Se consideră un regulator care acceptă două intrări discrete ce provin de la un traductor
de temperatură şi de la unul de debit. În cazul în care semnalele eşantionate provenite de la traductoare sunt
între nişte limite admisibile, regulatorul furnizează comenzi adecvate pentru reglarea celor două mărimi. În
cazul în care măsura depăşeşte limitele impuse, trebuie activat un scenariu de alarmă; valorile parametrilor
regulatorului în caz de alarmă se preiau dintr-un fişier separat (fişier alarmă). Acest fişier mai conŃine şi alte
versiuni ale valorilor parametrilor regulatorului astfel încât să se poată aplica o comandă adecvată. Valorile
citite de la traductoare şi comenzile aplicate sunt arhivate într-un fişier. Operatorul uman este informat în
permanenŃă despre starea sistemului (valorile intrărilor, comenzile aplicate, informaŃii auxiliare cum ar fi
dispersia semnalelor etc.). Se furnizează de asemenea un raport separat despre cazurile de alarmă.
Analiza specificaŃiilor de mai sus duce la o schiŃă a funcŃionalităŃii sistemului ce poate fi observată
în figura 1. Se identifică următoarele puncte funcŃionale:
A – numărul de intrări externe = 2 (temperatură, debit);
B – numărul de ieşiri externe = 4 (raport alarmă, stare sistem, comandă, citiri traductoare);
C- număr de cereri externe = 0;
D – număr de fişiere externe = 1 (arhivă);
E – număr de fişiere interne =1 (fişier alarmă).

Figura 1. FuncŃionalitatea sistemului de reglare

Vom considera pentru început că fiecare tip are complexitate medie. În acest caz se obŃine:
PFN = 4A + 5B + 4C + 10D + 7E = 8 + 20 + 0 + 10 + 7 = 45 . (5)
În cazul în care se consideră cele două limite de complexitate se obŃin următoarele valori pentru
punctele funcŃionale neajustate:
PFN = 3A + 4B + 3C + 7D + 5E = 6 + 16 + 0 + 7 + 5 = 34 , (6)
respectiv PFN = 6A + 7B + 6C + 15D + 10E = 12 + 28 + 0 + 15 + 10 = 65 . (7)
Dacă se presupune că un punct funcŃional necesită un efort de 2 persoane / zi , atunci cele două
limite se convertesc într-un domeniu de timp de la 68 la 130 zile. În cazul unei complexităŃi medii, va fi
nevoie de 90 de zile pentru implementare.
ObservaŃii:
• Modelul punctelor funcŃionale are avantajul că poate fi folosit încă din faza de pornire a
proiectului, deoarece se bazează pe documentul specificaŃiilor software.

3
 • Rezultatele furnizate de acest model pot subestima realitatea deoarece în documentul
specificaŃiilor software nu este elaborat la nivel de detalii de implementare.
• Abordarea bazată pe puncte funcŃionale nu se poate aplica în cazul în care se utilizează
mediile de dezvoltare integrate de tipul CASE, în cazul programării orientate obiect sau reutilizării
librăriilor.

2. Modelul COCOMO
Modelul COCOMO (COnstructive COst Model – Modelul constructiv al costurilor) este cel
mai bun şi documentat model utilizat în estimarea efortului. COCOMO a fost dezvoltat de Boehm
pe baza analizei a 63 de proiecte software. Modelul furnizează o formulă detaliată de determinare a
orarului dezvoltării proiectului, a efortului de dezvoltare general, de descompunere pe faze şi
activităŃi precum şi a efortului de întreŃinere. COCOMO estimează efortul în luni-om. Estimarea se
bazează pe numărul de linii de cod (SLOC – source lines of code) exprimat în mii de instrucŃiuni de
cod livrat (KDSI – thousands of delivered source instructions). Aceste instrucŃiuni includ toate
instrucŃiunile programului, instrucŃiunile de formatare, declaraŃiile de date. Nu sunt numărate
comentariile. Modelul COCOMO presupune că modelul de dezvoltare ales pentru proiectul
software este cel în cascadă şi că proiectul are asigurat un management performant.
Modelul COCOMO este dezvoltat în trei versiuni, în funcŃie de nivelul de rafinare a
estimării: de bază, intermediar şi detaliat. În cele ce urmează vom discuta despre primele două.
Boehm ia în considerare trei clase de siteme:
1. Încorporate. Aceste sisteme sunt caracterizate de constrângeri severe. Produsul este
integrat într-un mediu strict şi are constrângeri de timp, fiind relativ nou pentru companie. Un
exemplu tipic este cel al sistemelor de timp real (în aeronautică, medicină etc.).
2. Organice. Această clasă cuprinde sistemele ce sunt dezvoltate de echipe mici, într-un
mediu cunoscut, cu o interfaŃă relaxată. În această categorie intră proiectele relativ mici.
3. Semidetaşate. Sistemele software din această clasă sunt intermediare celor două
prezentate anterior. Exemple de astfel de sisteme sunt sistemele de operare şi sistemele de
management al bazelor de date.

2.1 Modelul COCOMO de bază

În forma de bază a modelului COCOMO se pleacă exclusiv de la dimensiunea programului
exprimată în KDSI, pe care o vom nota cu KDLOC (kilo delivered lines of code). Legătura între
efort şi dimensiunea programului este dată de:
Efort = a ⋅ KDLOCb , (8)
unde a şi b sunt parametrii modelului, ale căror valori depind de clasa din care sistemul software
face parte, după cum se poate observa în tabelul 1:
Tabel 1. Valorile parametrilor pentru COCOMO de bază
Clasa de sisteme a b
Încorporate 3.6 1.2
Organice 2.4 1.05
Semidetaşate 3.0 1.12
ObservaŃii:
• Forma funcŃiei din (8) precum şi valorile parametrilor sunt obŃinute experimental, pe baza
unor proiecte software anterioare. Din acest motiv, în cazul în care proiectul în lucru diferă foarte
mult de proiectele pe baza cărora s-a realizat modelul COCOMO, s-ar putea folosirea acestui model
să nu fie relevantă.
• În reprezentarea grafică din figura 2 se poate observa că pentru valori mari ale KDLOC
apar diferenŃe semnificative între cele trei clase de sisteme prezentate.

4
 Modelul COCOMO determină de asemenea orarul de dezvoltare al proiectului, M (exprimat
în luni) folosind efortul calculat anterior:
M = c ⋅ Efort d , (9)
unde parametrii c şi d au valorile precizate în tabelul 2.
ObservaŃiile anterioare rămân valabile şi în cazul determinării orarului de dezvoltare a
proiectului. În figura 3 este prezentată dependenŃa orarului de numărul de linii de cod sursă livrate.
Tabel 2. Valorile parametrilor orarului de dezvoltare
Clasa de sisteme c d
Încorporate 2.5 0.32
Organice 2.5 0.35
Semidetaşate 2.5 0.32
COCOMO se foloseşte şi pentru estimarea costurilor de întreŃinere. Formula se bazează pe
eforturile anterioare estimate:
Efort int retinere = TMA ⋅ Efort , (10)
unde TMA este traficul de modificare anual, adică acea fracŃiune din KDLOC care se schimbă pe
parcursul unui an.

Figura 2. DependenŃa efort(KDLOC)

Figura 3. DependenŃa orar(KDLOC)

5
 2.2 Modelul COCOMO intermediar
Acest model, cel mai des utilizat, se obŃine prin rafinarea modelului de bază. ÎmbunătăŃirea
constă în luarea în considerare a 15 atribute ale produsului. Pentru fiecare astfel de atribut,
utilizatorul modelului trebuie să precizeze o pondere din gama: foarte mică (engl. very low, VL),
mică (engl. low, LO), nominală (NM), mare (engl. high, HI), foarte mare (engl. very high, VH) şi
extrem de mare (engl. extra high, XH).
Lista atributelor este compusă din caracteristici ale produsului, sistemului de calcul,
personalului şi proiectului.
Atributele produsului:
• Fiabilitate cerută (RELY). Este utilizată pentru a exprima efectul defectelor software,
într-o gamă de la inconvenient minor (VL) la defect major (VH).
• OcteŃi de date pe instrucŃiune sursă livrată(DATA).
• Complexitate (CPLX). Atributul exprimă complexitatea codului, de la un cod simplu
(VL) la un cod de timp real (XH).
Atributele sistemului de calcul:
• Timp de execuŃie (TIME) şi constrângeri de memorie (STOR). Acest atribut identifică
procentul de resurse ale calculatorului (timp şi memorie) utilizate de sistem. În starea nominală
procentul este mai mic de 50% iar ponderea extrem de mare este dată de un procent de 95%.
• Volatilitatea platformei de dezvoltare (VIRT) este utilizată pentru a indica frecvenŃa
schimbărilor hardware-ului, sistemului de operare şi mediului de programare. Schimbările frecvente
şi semnificative au o pondere mai mare.
• Timp de răspuns (TURN) reprezintă timpul scurs de la începerea aplicaŃiei până la
obŃinerea rezultatelor. LO indică un mediu cu interactivitate mare iar VH cuantifică situaŃia în care
timpul este mai mare de 12 ore.
Atributele personalului
• Capacitatea analiştilor (ACAP) şi a programatorilor (PCAP) descriu aptitudinile echipei
de dezvoltare.
• ExperienŃa în domeniul aplicaŃiei (AEXP), în limbajul de programare (LEXP) şi în
mediul de dezvoltare (VEXP). Sunt utilizate pentru a cuantifica experienŃa echipei de dezvoltare în
domeniile precizate anterior.
Atributele proiectului
• Practicile de dezvoltare moderne (MODP) sunt legate de utilizarea practicilor software
moderne cum ar fi programarea structurată şi abordarea orientată obiect.
• Utilizarea aplicaŃiilor software automate (TOOL). Acestea sunt folosite pentru măsurarea
ponderii pe care respectivele aplicaŃii le au în dezvoltarea proiectului şi la integrare. O pondere mare
presupune nivele înalte în ambele aspecte precizate.
• Modificări ale orarului planului de dezvoltare (SCED) ce constau în comprimări (HI sau
VH) sau extindere (LO sau VL) în raport cu orarul nominal (NM).
În tabelul 3 sunt prezentate ponderile caracteristicilor descrise anterior. În funcŃie de proiect,
aceste rezultate parŃiale se înmulŃesc, obŃinându-se multiplicatorul final (P). Efortul se exprimă cu
formula:
Efort = Efort no min al ⋅ P , (11)
unde efortul nominal are diferite expresii, funcŃie de tipul de sistem:
• în cazul sistemelor încorporate: Efort no min al = 2.8KDLOC1.20 ;
• în cazul sistemelor semidetaşate : Efort no min al = 2.8KDLOC1.12 ;
• în cazul sistemelor organice: Efort no min al = 2.8KDLOC1.05 .

6
ObservaŃii:
• relaŃiile anterioare sunt asemănătoare celor din modelul de bază, diferenŃa apărând la
parametrul a, parametrul b rămânând nemodificat;
• dacă atributul are valoare nominală, nu influenŃează multiplicatorul P;
• unele atribute se pot compensa: creşterea valorii unor atribute este anihilată de scăderea
valorii altor atribute;
• estimarea timpului de dezvoltare a produsului este aceeaşi ca în modelul COCOMO de
bază;
• efortul de întreŃinere se calculează cu formula:
Efort int retinere = TMA ⋅ Efort no min al ⋅ P . (12)

Tabelul 3. Atributele modelului COCOMO intermediar

VL LO NM HI VH XH
RELY 0.75 0.88 1.00 1.15 1.40
DATA 0.9 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT 0.87 1.00 1.15 1.30
TURN 0.87 1.00 1.07 1.15
ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
PCAP 1.42 1.17 1.00 0.86 0.70
LEXP 1.14 1.07 1.00 0.95
VEXP 1.21 1.10 1.00 0.90
MOD 1.24 1.10 1.00 0.91 0.82
P
TOOL 1.24 1.10 1.00 0.91 0.83
SCED 1.23 1.08 1.00 1.04 1.10

Exemplu. Să considerăm un proiect software cu o dimensiune estimată la 300 KDLOC. Proiectul

este parte a unui sistem de control a unui autovehicul, sistem ce preia informaŃii de la diferiŃi senzori, le
procesează şi iniŃiază acŃiuni de control. Evident proiectul face parte din clasa de sisteme încorporate.
Folosind modelul COCOMO de bază, obŃinem Efort = 3.6 ⋅ 3001.20 = 3379 luni-om. Timpul de dezvoltare
este M = 2.5 ⋅ 33790.32 = 33.66 luni. În cazul modelului COCOMO intermediar, avem următoarele valori
ale caracteristicilor:
RELY HI 1.15 VIRT NM 1.00 LEXP NM 1.00
DATA HI 1.08 TURN LO 0.87 VEXP NM 1.00
CPLX NM 1.00 ACAP HI 0.86 MODP NM 1.00
TIME VH 1.30 AEXP HI 0.91 TOOL LO 1.10
STOR VH 1.21 PCAP NM 1.00 SCED VH 1.10

Multiplicând valorile de mai sus se obŃine P = 1.6095 . Eforul nominal este 2.8 ⋅ 3001.20 = 2628
luni-om. Aplicând factorul de corecŃie P se obŃine un efort de 4229 luni-om, semnificativ mai mare decât
cel estimat folosind modelul de bază.

3. Metoda Delphi de estimare a costului

În metodele de analiză anterioare era necesară determinarea unor parametri pe baza
estimărilor unor experŃi. AcurateŃea acestor determinări este esenŃială în estimarea costului. Este de
aşteptat ca rezultatele furnizate de un grup de experŃi să fie bune decât cele ale unei singure

7
persoane. Metoda Delphi ajută la coordonarea procesului de obŃinere de informaŃii de la un grup de
experŃi şi are următorii paşi esenŃiali:
• Coordonatorul prezintă fiecărui expert specificaŃiile proiectului şi alte informaŃii
relevante.
• Coordonatorul convoacă o întâlnire unde experŃii discută estimările.
• ExperŃii completează un formular cu estimările personale ale efortului de dezvoltare a
proiectului; experŃii furnizează cea mai probabilă valoare precum şi limitele inferioară şi superioară.
• Coordonatorul pregăteşte şi pune în circulaŃie un raport ce indică estimările individuale şi
de grup.
• Coordonatorul convoacă o nouă întâlnire în care experŃii discută estimările curente.
Aceste etape se repetă până când se ajunge la un consens. Estimarea de grup se obŃine ca o
medie ponderată a estimărilor individuale cu următoarea formulă:
LI + 4VP + LS
estimare = (13)
6
unde LI – limita inferioară a estimării; VP – valoarea probabilă a estimării; LS – limita superioară a
estimării.
VarianŃa unei estimări individuale este definită ca:
LS − LI
var ianta = . (14)
6
VarianŃa estimării de grup este media varianŃelor individuale.

Exemplu. Se consideră un sistem software de management al traficului. Sistemul trebuie să livreze

informaŃii despre condiŃiile curente de trafic, să facă predicŃii şi să identifice punctele unor congestionări
potenŃiale ale traficului. Există cinci experŃi implicaŃi în estimarea costului (exprimat în luni). Coordonatorul
furnizează experŃilor informaŃiile necesare. Într-o primă fază, experŃii furnizează estimările din tabelul 4.
Coordonatorul calculează media estimărilor şi prezintă experŃilor rezultatele, conform tabelului 5. La
următoarea întâlnire, experŃii discută estimările curente şi trec la rafinarea acestora (tabelul 6). Se calculează
din nou estimarea medie şi varianŃa conform tabelului 7.
VarianŃa grupului este un indicator al convergenŃei procesului de estimare a costului. VarianŃa ar
trebui să scadă de la iteraŃie la iteraŃie.
Tabelul 4. Prima iteraŃie a estimării Tabelul 5. Calculul estimării de grup
timpului de dezvoltare şi a varianŃei – prima iteraŃie
LI VP LS Expert Estimare VarianŃă
Expert 1 20 50 60 1 46.7 6.7
Expert 2 25 40 70 2 42.5 7.5
Expert 3 10 55 75 3 50.8 10.8
Expert 4 30 60 70 4 56.7 6.7
Expert 5 15 35 85 5 40.0 11.7
Medie 47.3 8.6

Tabelul 6. A doua iteraŃie a estimării Tabelul 7. Calculul estimării de grup

timpului de dezvoltare şi a varianŃei – a doua iteraŃie
LI VP LS Expert Estimare VarianŃă
Expert 1 30 50 60 1 48.3 5.0
Expert 2 30 45 65 2 45.8 5.8
Expert 3 20 50 70 3 48.3 8.3
Expert 4 30 55 70 4 53.3 6.7
Expert 5 25 40 75 5 50.0 8.7
Medie 49.1 6.8