Ingineria Programării

Metrici

Curs 12

Adriana Gheorghieş, adrianaa@infoiasi.ro

Ovidiu Gheorghieş, ogh@infoiasi.ro
IP
12
Aprecierea calităŃii
• Cum măsurăm calitatea unui lucru?
– Calitatea construcŃiei (cât de bine este lucrat, dacă există
defecte în materialul din care este fabricat ...)
– Calitatea designului (eleganŃă, comfort ...)
– O combinaŃie între calităŃile construcŃiei şi ale designului
(rezistenŃa...)
• În general putem spune că un scaun A este mai bun
decât un scaun B sub un anumit aspect al calităŃii,
dar de obicei este greu de precizat cu cât este mai
bun.
IP
12
Calitatea unui program (1)
• Nu se examinează calitatea construcŃiei (=> unicitate
între toate disciplinele inginereşti)
• Toate atributele calităŃii se referă la design.
• Dacă ne referim la valori estetice:
– Programele sunt în mare parte invizibile, iar valorile estetice
contează doar pentru părŃile vizibile
– Înafară de interfaŃă, singurele aspecte observabile la un
program sunt:
• NotaŃiile folosite pentru design şi scrierea codului
• Comportamentul programului atunci când interacŃionează cu
alte entităŃi.
IP
12
Calitatea unui program (2)
• Atunci când vorbim despre calitatea unui
program trebuie:
– Să definim atribute ale calităŃii care ne
interesează;
– Să căutăm modalităŃi de măsurare a lor;
– Să putem da o reprezentare designului;
– Să scriem specificaŃii care să ghideze
programatorii (calităŃile designului să fie
respectate şi de implementare).
IP
12
Codul sursă
• Codul care implementează un design este o
reprezentare a acelui design.
• Asigurarea calităŃii făcută după scrierea
codului este un proces costisitor.
IP
12
Calitatea unui program (3)
• Măsoară cât de bine se potriveşte un program
mediului său.
• Ia în calcul aspecte de tipul:
– Programul funcŃionează;
– Programul face ceea ce trebuie să facă;
– Programul este sigur;
– Programul poate fi adaptat pe măsură ce nevoile se
schimbă.
• Toate măsurile referitoare la calitate sunt relative.
IP
12
Concepte ale calităŃii
• SiguranŃă
• EficienŃa
• ÎntreŃinere
• Uzabilitate
IP
12
SiguranŃa
Este programul complet, consistent şi robust?
– completitudine – tratează toate intrările posibile;
– consistenŃă – se comportă întotdeauna aşa cum
este aşteptat;
– robusteŃe – se comportă bine în situaŃii anormale
(ex. lipsa resurselor).
IP
12
EficienŃa
• Programul utilizează într-un mod eficient
resursele? (procesor, memorie, reŃea...)
• EficienŃa este întotdeauna mai puŃin
importantă decât siguranŃa.
• Este mai uşor să facem un program sigur să
fie eficient decât un program eficient să fie
sigur.
IP
12
ÎntreŃinere
• Cât de uşor poate fi modificat design-ul
ulterior?
• Tipuri de întreŃinere:
– Corectivă: eliminarea erorilor;
– Perfectivă: adăugarea de funcŃionalităŃi care ar fi
trebuit să fie oferite;
– Adaptivă: actualizarea programului când se
schimbă cerinŃele.
IP
12
Uzabilitate
• Cât de uşor este programul de învăŃat şi de
folosit?
IP
12
Atribute măsurabile
• Simplitate
• Modularitate
IP
12
Simplitate
• Este măsura inversă a complexităŃii.
• Aspecte ale complexităŃii:
– Complexitatea fluxului de control: numără căile
posibile de execuŃie ale unui program (vezi testare
structurală).
– Complexitatea fluxului de informaŃii: numără
datele care sunt transmise în program.
– Complexitatea înŃelegerii: numără identificatorii şi
operatorii folosiŃi.
IP
12
Modularitate
• Poate fi măsurată uitându-ne la:
– Coeziune: cât de bine lucrează împreună
componentele unui modul.
– Cuplaj: gradul de interacŃiune între module.
IP
12
MotivaŃii pentru metrici
Efectuăm măsurători pentru
• a înŃelege
• a controla
• a prevedea

Când poŃi să măsori lucrul despre care vorbeşti şi să

exprimi aceasta în numere, atunci ştii ceva despre acel
lucru. Dar când nu poŃi să îl măsori, când nu poŃi să îl
exprimi în numere, cunoştinŃele tale sunt slabe şi
nesatisfăcătoare; ele pot fi începutul cunoaşterii, dar mai
nimic nu este încă făcut pentru a ajunge la stadiul de
ştiinŃă. (Lord Kelvin)
IP
12
Ce se doreşte a fi măsurat
• Dimensiunea unui program
• Complexitatea unui program
• Fiabilitatea unui program

• Timpul necesar dezvoltării unui program

• Alocarea resurselor necesare dezvoltării unui
program

• Productivitatea muncii
• Costurile de dezvoltare
IP
12
Metrici de bază
• KLOC: Kilo Lines Of Code (mii linii de cod)

• Effort, PM: Person – Month (Om – lună).

IP
12
COCOMO
COnstructive COst MOdel (Boehm 1981)

Folosit pentru evaluarea costurilor

Trei nivele de rafinare a predicŃiilor:

COCOMO de bază
COCOMO intermediar
COCOMO detaliat
IP
12
COCOMO de bază
Formula pentru efortul necesar dezvoltării în
funcŃie de numărul de linii de cod

Exprimat în PM

Constante ce depind de tipul proiectului

Organic: b = 2.4 c=1.5

Semidetaşat: b = 3.0 c=1.12
Integrat: b = 3.6 c = 1.20
IP
12
COCOMO 2
• Propus de Boehm în 1995

• Ia în calcul tehnicile moderne de dezvoltare

apărute
– Prototipizare
– Dezvoltarea pe componente
– 4GL

• Oferă posibilitatea de a face estimări încă din

primele faze ale dezvoltării
IP
12
COCOMO 2: Prototipizarea iniŃială

• Surprinde efortul necesar realizării unui

prototip al aplicaŃiei

• Se bazează pe numărul de puncte obiect

(NOP)
IP
12
NOP
• Se inventariază ecranele ce trebuie afişate
– Simple: 1
– Complexe: 2
– Foarte complexe: 3

• Se inventariază rapoartele ce trebuie generate

– Simple: 2
– Complexe: 5
– Foarte complexe: 8

• Fiecare modul în limbaj de nivel mai jos (ex. 3GL): 10

• Suma punctelor obŃinute reprezintă numărul total de

puncte obiect ale programului.
IP
12
COCOMO 2: Prototipizarea iniŃială
(cont.)
• Formula de calcul a efortului

Procentul de reutilizare a codului Productivitatea (NOP/PM)

Foarte Mic Nominal Foarte

Experienta programatorului mica a a Mare mare
Productivitate (NOP/PM) 4 7 13 25 50
 IP
12
COCOMO 2: proiectarea iniŃială
NOP =>Size (2..40 LOC/NOP)
KLOC
• Efort 1.1 .. 1.24
2.5

Capacitatea Reutilizare ExperienŃa

Planificare
personalului cerută personalului
1..6

SiguranŃa şi Dificultatea FacilităŃi

complexitate platformei asistenŃă

Procentul de Productivitatea
Numar linii cod linii de cod pentru acest tip
generate automat generate automat de activitate
IP
12
COCOMO 2: după proiectare

• Se estimează numărul total de linii de cod

(ESLOC)

• Factori luaŃi în calcul

– Volatilitatea cerinŃelor
– Gradul posibilităŃii de reutilizare a codului
IP
12
COCOMO 2:
influenŃa asupra costurilor
• Atributele produsului
– SiguranŃa produsului; Complexitatea modulelor
sistemului; Dimensiunea documentaŃiei cerute;
Dimensiunile bazei de date utilizate; Procentajul
cerut de componente reutilizabile.

• Atributele sistemului de calcul

– Constrângeri privind timpul de execuŃie;
Volabilitatea platformei pe care se face
dezvoltarea; Constrângeri de memorie.
IP
12
COCOMO 2:
influenŃa asupra costurilor (cont.)
• Atributele personalului
– Capacitatea analiştilor; Capacitatea
programatorilor; Continuitatea personalului;
ExperienŃa analistului în domeniul problemei;
ExperienŃa programatorilor în domeniul problemei;
ExperienŃa în limbajele şi instrumentele folosite
• Atributele proiectului
– Utilizarea intrumentelor; Gradul de lucru în echipe
aflate la distanŃă şi calitatea comunicării între
echipe; Comprimarea planului de dezvoltare
IP
12
COCOMO 2:
calcularea timpului de dezvoltare
• Timpul necesar dezvoltării produsului se
calculează după formula:
IP
12
COCOMO 2:
calcularea preŃului de dezvoltare
• PreŃul se calculează după formula:

nă!
lu
e pe
Constrângeri ExperienŃa st
SiguranŃa echipei ule
memorie e Ń
, pr
Constrângeri Folosirea Da
timp instrumentelor
IP
12
DistribuŃia forŃei de muncă în timp

• 20 om-lună
– 20 oameni muncesc 1 luna
– 4 oameni muncesc 5 luni

NU
– 1 om munceşte 20 luni

– Productivitatea individuală scade atunci când echipa

de dezvoltare creşte
• Comunicare suplimentară
• La adăugarea de noi membri, productivitatea iniŃial scade

– Creşterea numerică a forŃei de muncă la un proiect

rămas în urmă are ca efect rămânerea şi mai în urmă
a proiectului. (Legea lui Brooks)
IP
12
DistribuŃia forŃei de muncă în timp
(2)
• Productivitatea medie (L: LOC/PM)

• P: dimensiunea medie a echipei

IP
12
DistribuŃia forŃei de muncă în timp
(2)
• Pentru o echipă cu P persoane putem avea
între P-1 şi P(P-1)/2
canale de comunicaŃie.
Fiecare canal induce o
pierdere l de eficienŃă
• Productivitatea individuală va fi:

• Productivitatea echipei (de dimensiune P) va fi:

IP
12
Cum NU se calculează costurile
şi NU se fac planificări
• Avem 12 luni să terminăm treaba, deci treaba va dura 12
luni. Legea lui Parkinson: munca se întinde pe timpul
avut la dispoziŃie.

• Ştim că competitorul a cerut $1.000.000. Noi cerem

$900.000.

• Ştim că bugetul clientului pentru produs este de

$500.000. Atât ne costă şi pe noi dezvoltarea.

• Vrem să prezentăm produsul la CeBit anul viitor:

terminăm până atunci produsul.

• Programul va dura 1 an, dar voi spune că va dura 10

luni. Ce-o să mai conteze 2 luni peste planificare...
IP
12
Metrici Orientate Obiect
• Adâncimea arborelui de derivare
• Numărul claselor derivate dintr-o clasă
• Metode bazate pe ponderi pentru o clasă
• Cuplaje între clase de obiecte
• ResponsabilităŃile unei clase
• Lipsa coeziunii în metode
IP
12
Adâncimea arborelui de derivare

• Care este cel mai lung brum de la clasa

rădăcină până la o clasă derivată din
aceasta?
• Cu cât o clasă se află mai jos în ierarhie, cu
atât creşte probabilitatea să moştenească
mai multe metode de la ancestori.
IP
12
Numărul claselor derivate dintr-o
clasă
• Câte subclase are o anumită clasă?
• Indică importanŃa unei anumite clase.
• Deşi moştenirea este o formă de refolosire a
codului, un număr mare de clase derivate
conduce la o structură complexă a ierarhiei
de clase.
IP
12
Metode bazate pe ponderi pentru
o clasă
• Câte metode sunt într-o clasă şi cât de
complexe sunt ele?
• Numărul şi complexitatea metodelor indică
timpul necesar dezvoltării şi menŃinerii clasei.
• Un număr mare de metode într-o clasă are un
impact mai puternic asupra claselor derivate
şi reduce generalitatea.
IP
12
Cuplaje între clase de obiecte
• De câte clase este legată o anumită clasă?
• Prea multe cuplaje împiedică modularitatea şi
refolosirea codului.
IP
12
ResponsabilităŃile unei clase
• Câte metode pot fi invocate de o metodă a
unei alte clase?
• Indică complexitatea.
IP
12
Lipsa coeziunii în metode
• Fiecare unitate reprezintă o unitate logică din
punctul de vedere al funcŃionalităŃii?
• Coeziunea promovează încapsularea. Dacă
metodele nu sunt coezive s-ar putea să fie
nevoie de o subclasă.
IP
12
Probleme la folosirea metricilor

• Lipsa de acurateŃe

• RezistenŃa din partea angajaŃilor

• Folosirea lor în alte scopuri decât au fost create

• Disensiuni în cadrul echipei de dezvoltare

IP
12
Vă mulŃumim !

... pentru
– atenŃie
– răbdare