1

CUPRINS

DEZVOLTAREA SI MANAGEMENTUL INGINERIEI SOFTWARE


CAPITOLUL 8:
CALITATEA SISTEMULUI SOFTWARE
8.1. Definirea si asigurarea calitatii software
8.1.1. Calitatea si factorii ei
8.1.2. Analiza factorilor de calitate
8.1.3. Asigurarea calitatii software
8.2. Masurarea calitatii software
8.2.1. Problemele masurarii calitatii
8.2.2. Masurarea calitatii in sistemele SQA
8.2.3. Standarde de calitate software
8.3. Complexitatea software
8.3.1. Definirea complexitatii
8.3.2. Masurarea complexitatii codului
8.3.3. Masurarea complexitatii algoritmului

CAPITOLUL 9:
MANAGEMENTUL INGINERIEI SOFTWARE
9.1. Probleme generale privind managementul ingineriei programarii.
9.1.1. Definitia si structura manageratului
9.1.2. Planificarea resurselor umane
9.1.3. Recrutarea si selectia resurselor umane
9.1.4. Pregatirea si dezvoltarea
9.1.5. Aprecierea performantei
9.2.Managementul personalului programator.
9.2.1. Legea lui Parkinson
9.2.2. Reguli de baza privind managementul personalului
9.3.Managementul performantelor programarii.
9.3.1. Categoriile de computeristi si factorii de personalitate
9.3.2. Sarcinile programarii si mediul de lucru
9.4.Managementul comunicarii interpersonal.
9.4.1. Modelul comunicarii
9.4.2. Problemele comunicarii
9.4.3. Comunicarea in procesul elaborarii software
9.4.4. Comunicarea in faza de proiectare
9.5.Managementul eticii profesionale.
9.5.1. Formarea eticii
9.5.2. Coduri de conduita etica
9.5.3. Studii de caz
9.6.Estimarea efortului si costului producerii software.
9.6.1. Metode de estimare a costului
9.6.2. Estimarea costului prin metoda algoritmica
9.6.3. Estimarea costului prin metoda COCOMO



2

8.1. Definirea si asigurarea calitatii software

8.1.1. Calitatea si factorii ei
In literatura de specialitate exista multe definitii al calitatii software. De exemplu:
Conformitatea cu cerintele functionale si de performante formulate explicit, cu
standardele de dezvoltare documentate explicit si cu caracteristicile implicite care sunt
asteptate de la toate software-urile realizate in mod profesional.
Calitatea software din punctul de vedere al clientului inseamna satisfacerea specificatiilor,
iar din punctul de vedere al proiectantului inseamna usor de intretinut si testat. Dar, calitatea
software nu inseamna doar satisfacerea specificatiilor si repararea defectelor.
Definitia de mai sus subliniaza trei aspecte importante ale calitatii software:
Cerintele software sunt baza de la care este masurata calitatea. Lipsa conformarii
cu cerintele inseamna lipsa de calitate.
Standardele specificate definesc un set de criterii de dezvoltare care ghideaza
maniera in ca software-ul este realizat. Daca nu sunt urmate criteriile, se va ajunge
aproape sigur la lipsa de calitatea.
Exista un set de cerinte implicite care adesea nu sunt mentionate (de exemplu,
dorinta de mentenabilitate buna). Daca software-ul se conformeaza cerintelor
explicite dar nu si celor implicite, calitatea software-ului este suspecta.
Specificarea cerintelor este la fel de dificila pe cat este de importanta in cadrul dezvoltarii
software. Cercetarile din domeniu arata ca specificarea cerintelor de calitate a software-ului
influenteaza si calitatea muncii de implementare. In cadrul unui experiment, cinci echipe de
programare au primit fiecare cate un obiectiv diferit:
memorie interna minima;
claritatea iesirilor;
claritatea programului;
minimum de instructiuni in codul sursa;
timp minim.
Cand s-a evaluat productivitatea, fiecare echipa s-a situat pe primul loc in obiectivul sau
principal. Aceasta arata ca programatorii raspund unui obiectiv. Fiecare echipa a produs exact
ceea ce i s-a cerut.
O alta definitie din dictionarul IEEE de termeni din ingineria software este:
Calitatea este gradul in care un sistem, o componenta sau un proces indeplineste
necesitatile sau asteptarile clientului sau utilizatorului.

Factorii de calitate sunt:
Corectitudine: Gradul in care un program isi satisface specificatiile si
indeplineste obiectivele misiunii utilizatorului.
Fiabilitate: Gradul in care un program va realiza functiile prevazute cu precizia
ceruta.
Eficienta: Cantitatea de cod si resurse de calcul necesara ca un program sa
realizeze o functie.
Integritate: Gradul in care poate fi controlat accesul persoanelor neautorizate la
software sau la date.
Uzabilitate: Efortul necesar pentru invatarea, operarea, pregatirea intrarilor si
interpretarea iesirilor unui program.
Mentenanta: Efortul necesar pentru testarea unui program in vederea verificarii
daca isi realizeaza functia prescrisa.
Flexibilitate: Efortul necesar pentru modificarea unui program functional.
3

Portabilitate: Efortul necesar pentru transferarea unui program dintr-un mediu
hardware si/sau software pe altul.
Reutilizare: Gradul in care un program (sau o parte a lui) poate fi reutilizat in alte
aplicatii.
Interoperabilitate: Efortul necesar pentru a cupla un sistem cu altul.
Calitatea software-ului este exprimata in masuri. O masura software este o proprietate
masurabila care este un indicator al unuia sau mai multor criterii de calitate care se incearca sa
se masoare.
Factorii de calitate arata ca un software de calitate trebuie sa faca ceea ce utilizatori isi
doresc; sa utilizeze resursele calculatorului in mod corect si eficient; sa fie usor de invatat si
utilizat (ingineria umana) si sa fie bine proiectat, bine codat si usor de testat si intretinut.
Aceasta lista este utila ca o verificare pentru programatori si nu ca un ghid de construire a
programelor.

8.1.2. Analiza factorilor de calitate
Obiectivul ingineriei software este, desigur, proiectarea si dezvoltarea de software mai
bun. Se pune problema ce inseamna software mai bun. Pentru a putea raspunde la aceasta
intrebare, trebuie explicati factorii de calitate software. Sase dintre cei mai importanti factori
de calitate sunt: mentenabilitatea, corectitudinea, reutilizarea, fiabilitatea, portabilitatea si
eficienta.

Mentenabilitatea este usurinta cu care pot fi facute modificari pentru
a satisface noile cerinte sau pentru a corecta deficientele. Software-ul bine
proiectat ar trebui sa fie destul de flexibil pentru modificarile de adaptare
ulterioare care vor fi necesare pe masura ce apar noi cerinte. Deoarece
mentenanta acopera aproape 70% din costul ciclului de viata software, importanta acestui
factor de calitate nu poate fi supraaccentuata. Destul de des programatorul responsabil cu
scrierea unei sectiuni de cod nu este si cel care trebuie sa-l intretina. De aceea, calitatea
documentarii software-ului afecteaza foarte mult mentenabilitatea produsului software.

Corectitudinea este gradul in care software-ul satisface cerintele
specificate. La inceputul ciclului de viata software, cerintele de software sunt
determinate si formalizate in documentul de specificare a cerintelor. Software-
ul bine proiectat trebuie sa satisfaca toate cerintele formulate. Ar putea parea
evident ca software-ul trebuie sa fie corect, dar in realitate acest factor este
unul dintre cei mai greu de evaluat. Datorita foarte marii complexitati a produselor software,
este imposibil sa se realizeze testari exhaustive de executie pentru a fi siguri ca nu va aparea
nici o eroare la rularea software-ului. De asemenea, este important de retinut ca unele produse
ale ciclului de viata software, asa cum este specificarea proiectarii, nu pot fi executate
pentru testare. In schimb, aceste produse trebuie testate cu diferite alte tehnici, cum ar fi
demonstratii formale, inspectii si treceri in revista.

Reutilizarea este usurinta cu care software-ul poate fi reutilizat la
dezvoltarea de alt software. Prin reutilizarea software-ului existent,
proiectantii pot crea software mai complex intr-o perioada de timp mai
scurta. Reutilizarea este deja o tehnica uzuala folosita in alte discipline
ingineresti. De exemplu, cand se construieste o casa, grinzile care sustin
acoperisul sunt de obicei preasamblate. Daca nu este necesar un design special, arhitectul nu
va incerca sa proiecteze un nou tip de grinda pentru casa. In schimb, va utiliza pur si simplu
un model existent de grinda, care s-a dovedit fiabila. In aproape acelasi fel, software-ul poate
4

fi proiectat in asa fel incat sa permita reutilizarea in multe situatii. Un exemplu simplu de
reutilizare software ar putea fi dezvoltarea unei rutine eficiente de sortare care poate fi
incorporata in multe aplicatii viitoare.

Fiabilitatea este frecventa si importanta erorilor software, unde
prin eroare aici se intelege un efect sau comportament inacceptabil in
conditii permise de functionare. Frecventa erorilor este masurata
prin timpul mediu dintre aparitia a doua erori succesive. Importanta
erorilor software este masurata prin timpul mediu necesar remedierii.
In mod ideal, inginerii software vor ca produsele lor sa aiba erori cat mai rare (adica sa
prezinta corectitudine mare) si atunci cand apar, erorile sa fie cat mai usor de reparat (adica sa
demonstreze mentenabilitate ridicata). Pentru unele sisteme in timp-real, cum sunt controlul
traficului aerian sau monitoarele cardiace, fiabilitatea devine cel mai important factor de
calitate software. Oricum, ar fi dificil de imaginat un sistem foarte fiabil, care sa nu fie si
foarte corect si bine intretinut.

Portabilitatea este usorinta cu care software-ul poate fi folosit pe
configuratii (de computer) diferite de cea curenta. Portarea software-ului pe
alte configuratii de computer este importanta din cateva motive. Primul,
produsele software bune pot avea o viata de cel putin 15 ani, pe cand
hardware-ul este schimbat frecvent (cel putin la 4 sau 5 ani, daca nu mai
des). Astfel, software-ul poate fi implementat, pe durata vietii sale, pe trei sau patru
configuratii hardware diferite.. Al doilea, portarea software-ului pe o noua configuratie de
computer poate fi mai putin costisitoare decat dezvoltarea de la zero a unui software analog.
Al treilea, vanzarile de software shrink-wrapped poate fi marite deoarece este disponibila o
piata mai mare pentru software.

Eficienta este gradul in care software-ul isi satisface scopul fara risipa de
resurse. Eficienta este de fapt un factor de calitate cu multe fatete si trebuie
evaluat in concordanta cu o resursa particulara, cum ar fi timpul de executie sau
spatiul de stocare. O masura a eficientei este viteza de executie a programului.
Adesea, aceste doua masuri sunt invers proportionale, adica, marirea eficientei
de executie conduce la scaderea eficientei spatiului. Aceasta relatie este cunoscuta drept
compromisul spatiu-timp. Cand nu este posibil de proiectat un produs software cu eficienta
sub toate aspectele, cele mai importante resurse software stabilesc prioritatea.

Mentenabilitatea software este costul principal in majoritatea produselor, si este afectata
de stucturile de date, structura logica, documentatie, unelte de diagnosticare si de atributele
personalului, cum ar fi specializarea, experienta, pregatirea, inteligenta, motivatia
Factorii tehnici care afecteaza mentenanta programului sunt:
Independenta modulelor: Ar trebui sa se poata modifica o unitate program a
unui sistem fara a afecta nici o alta unitate.
Limbajul de programare: Programele scrise intr-un limbaj de nivel inalt sunt de
obicei mai usor de inteles (si deci si de intretinut) decat programele scrise intr-un
limbaj de nivel jos.
Stilul de programare: Modul in care este scris un program contribuie la
intelegerea si astfel si la usurinta cu care poate fi modificat.
Validarea si testarea programului: In general cu cat se cheltuieste mai mult
timp si efort in validarea proiectului si testarea programului, cu atat exista mai
putine erori in program si, in consecinta, costurile de intretinere rezultate din
5

corectia erorilor sunt mai scazute. Costurile de intretinere datorate corectiei
erorilor depind de tipul erorilor de reparat. Erorile de codare sunt de obicei destul
de ieftine de corectat. Erorile de proiectare sunt mai scumpe deoarece pot
presupune rescrierea uneia sau mai multor unitati program. Erorile in cerintele
software sunt cele mai scumpe deoarece inseamna de obicei reproiectare aproape
in intregime.
Calitatea si cantitatea documentarii programului: Daca un program este
secondat de documentatie clara, completa dar si concisa, sarcina intelegerii
programului poate fi imbunatatita. In consecinta, costurile de mentenanta a
programului tind sa fie mai mici pentru sistemele bine documentate decat pentru
sistemele livrate cu documentatie putina sau incompleta.

Pentru un proiect factorul de calitate cheie este mentenabilitatea. In cazul componentelor
proiectului mentenabilitatea inseamna:
coeziune cat de strans legata este functionalitatea de acea componenta;
cuplare cat de independenta este componenta;
lizibilitate cat de usor este de inteles functionarea componentei;
adaptabilitatea cat de usor este sa se modifice componenta.
Majoritatea acestor caracteristici nu pot fi masurate direct, dar se poate considera ca
exista o relatie de legatura intre aceste atribute si complexitatea componentei.

Fiabilitatea software-ului este unul dintre cei mai importanti factori de calitate, deoarece
sistemele nefiabile sunt abandonate sau nu sunt utilizate niciodata.
Fiabilitate inseamna:
elemente care depind de proiectul produsului care vor functiona corect pentru o
perioada substantiala de timp;
o masura care este probabilitatea software-ului de a functiona cu succes.
Modelele probabilistice exprima probabilitatea evenimentelor atunci cand nu se poate sti
exact cand vor aparea.
Mai intai, trebuie definite toate evenimentele posibile. Intr-un model probabilistic al erorii
programului sunt incluse toate caile posibile dintr-un program. Apoi, sunt specificate regulile
de selectie a caii si din acestea, se poate determina probabilitatea de selectie a unei cai. Un
esec software apare cand se proceseaza o secventa continand o eroare.
Teoria fiabilitatii este aplicarea teoriei probabilitatilor pentru modelarea esecurilor si in
consecinta, predictia probabilitatii de succes.

O definitie acceptabila este:
Fiabilitatea software-ului este probabilitatea ca programul sa functioneze cu succes, in
concordanta cu specificatiile, pentru o perioada de timp data.
Specificatiile includ precizari exacte pentru:
masina gazda;
sistemul de operare si software-ul suport;
mediul de functionare;
definitia succesului;
detalii privind interfata hardware cu masina;
detalii privind domeniile si vitezele datele de intrare/iesire;
procedurile functionale.
Timpul poate fi impartit in:
timp operational;
6

timp calendaristic in timpul functionarii;
timp calendaristic in timpul dezvoltarii;
ore-om de codare;
dezvoltare, testare;
depanare;
timpi de testare pe computer.
Masurile fiabilitatii sunt:
Probabilitatea de esuare la cerere. Aceasta este o masura a probabilitatii ca
sistemul sa se comporte intr-un mod neasteptat atunci cand i se cere ceva. Este
relevat mai ales pentru sistemele care trebuie sa fie foarte sigure si pentru
sistemele non-stop a caror functionare continua este critica. In aceste sisteme, o
masura a aparitiei esecurilor este mai putin importanta decat probabilitatea ca
sistemul sa nu se comporte asa cum ar fi trebuit.
Viteza de aparitie a esecurilor (ROCOF). Aceasta este o masura a frecventei de
aparitie a unui comportament neasteptat. De exemplu, daca ROCOF este 2/100
aceasta indica faptul ca pot aparea 2 erori la fiecare 100 unitati de timp
operational. Unitatile de timp sunt cele prezentate mai sus.
Timpul mediu al esecului (MTTF). Acesta este o masura a timpul scurs intre
doua esecuri consecutive.
Disponibilitate. Aceasta este o masura a probabilitatii ca sistemul sa fie disponibil
pentru utilizare. De exemplu, o disponibilitate de 998/1000 inseamna ca, la fiecare
1000 de unitati de timp, sistemul va fi probabil disponibil doar 998 dintre aceste
unitati de timp.

Disponibilitatea este definita ca :
raportul dintre sistemele care functioneaza la un anumit moment si dimensiunea
populatiei studiata (pentru sisteme multiple).
raportul dintre timpul functional observat si suma dintre timpul functional si
nefunctional:

nefunct funct
funct
T T
T
A
+
= (pentru un singur sistem).
Aceste masurari sunt utilizate pentru:
cuantificarea fiabilitatii si compararea sa cu alte sisteme sau obiective;
urmarirea fiabilitatii in timp pentru a vedea daca aceasta creste pe masura ce se
gasesc erorile;
planifica personal pentru reparatii, facilitati (de exemplu, timp de test) si servicii
alternative.
Daca sistemul se afla inca in faza de proiectare si dezvoltare atunci se utilizeaza o a treia
definitie, si anume:
Raportul dintre timpul mediu pana la aparitia erorii (MTTF) si suma dintre acest timp si
timpul mediu necesar repararii (MTTR):
MTTR MTTF
MTTF
A
+
=
Pentru a utiliza masurile fiabilitatii in procesul de asigurare a calitatii, cerintele software
trebuie sa formuleze fiabilitatea necesara in termenii comportamentului dinamic al sistemului.
De exemplu, cerinta pentru un sistem informational managerial ar putea cere ca probabilitatea
ca sistemul sa fie disponibil la cerere sa fie 99,99%. Aceasta inseamna ca ar trebui satisfacute,
in medie, 9999 cereri de servire din 10000.

7

8.1.3. Asigurarea calitatii software (SQA)
Toate persoanele implicate in dezvoltarea de software sunt responsabile si cu asigurarea
calitatii sale. Se urmareste tot mai mult ca asigurarea calitatii sa devina o caracteristica
implicita in ingineria software.

Definitie
Asigurarea calitatii consta din acele proceduri, tehnici si unelte aplicate de catre
profesionisti pentru a fi siguri ca un produs satisface sau chiar depaseste standardele
prestabilite in timpul ciclului sau de dezvoltare.

Din definitia de mai sus se desprind o serie de concluzii privind asigurarea calitatii, dupa
cum urmeaza:
este o activitate esentiala pentru orice activitate producatoare de produse utilizate
de altii;
trebuie plaificata si sistematizata;
trebuie sa fie inclusa in cadrul procesului de inginerie software.
obiectivul general este continua imbunatatire.
In fig.8.1. se prezinta toate tehnicile utilizate pentru imbunatatirea calitatii software-ului.

Fig.8.1. Tehnici de imbunatatire a calitatii

Tehnicile de imbunatatire a calitatii software din fig.8.1. sunt:
Metode si unelte pentru determinarea cerintelor sistemului, analiza sistemului,
proiectarea sistemului si testare. Ajuta la asigurarea ca se va realiza un sistem de
inalta calitate.
Standarde si proceduri pentru conformitate. Pot sa nu existe, dar daca exista
trebuie urmate sau modificate, unde este cazul. De asemenea, pot fi impuse prin
lege sau prin contract (de exemplu, cele militare). Ajuta la asigurarea
repetabilitatii procesului de dezvoltare.
Masuri si masurari ca procedee. Stabilesc si monitorizeaza masurile software si
realizeaza o inregistrare a istoriei sistemului. Ajuta la imbunatatirea procesului de
dezvoltare a software-ului.
Revizuiri tehnice formale la fiecare pas. Ajuta la descoperirea problemelor de
calitate si abandonare (sign-off) la fiecare pas.
Managementul configurarii software si controlul modificarilor. Ajuta la
asigurarea ca modificarile sunt controlate.
Testarea multi-tiered. Ajuta la asigurarea detectarii efective a erorilor.

8

In fig.8.2. se prezinta costurile pentru repararea unei erori. Se observa ca aceste costuri
cresc exponential cu momentul de timp al descoperirii lor in cadrul ciclului de viata al
sistemului. Principiul ce sta la baza acestor costuri este: Platesti putin acum sau platesti mult
mai mult mai tarziu.

Fig.8.2. Costul activitatilor SQA

Principiile asigurarii calitatii software (SQA) sunt:
Exista un set de standarde si factori de calitate pe care trebuie sa le satisfaca un
produs software. Adica, exista un obiectiv de atins.
Se poate masura calitatea unui produs software. Adica, exista o modalitate de
determinare a gradului in care un produs se conformeaza standardelor si factorilor
de calitate.
Se pot urmarii valorile factorilor de calitate. Adica, este posibil sa se evalueze
performantele actuale.
Se utilizeaza informatii despre calitatea software-ului pentru a imbunatatii
calitatea viitoarelor produse software. Adica, exista feedback in procesul de
dezvoltare software.

Standardele software sunt necesare deoarece:
Incapsuleaza practicile cele mai bune (sau cele mai potrivite), achizitionate dupa
multe incercari si erori, ajutand astfel la evitarea greselilor anterioare.
Asigura un cadru de baza in jurul caruia sa se implementeze procesul SQA. Astfel
asigura ca se urmeaza corect cele mai bune practici.
Asista la asigurarea continuitatii lucrului la proiect si reduce efortul de instruire la
inceperea unui noi proiect.

Standardele se impart in:
Standardele produsului: definesc caracteristicile pe care trebuie sa le aiba toate
artifacts produsului pentru a exista calitate.
Standardele procesului: definesc modul de construire a procesului software
pentru a asigura calitatea.

Fiecare proiect trebuie sa decida in ce standard se va incadra, si anume poate sa ignore
standardele, sa le utilizeze asa cum sunt, sa le modifice sau sa-si creeze noi standarde.
9

Obiectivul SQA
SQA este o activitate de management care se ocupa cu asigurarea ca produsele software
satisfac cateva standarde acceptabile. Este o activitate de tip umbrela care ar trebui aplicata
pe parcursul procesului de dezvoltare. Fiecare organizatie ar trebui sa aiba un grup
independent de specialisti dedicat SQA-ului.
Formulate in linii mari, obiectivele grupului SQA sunt:
Imbunatatirea calitatii software prin monitorizarea corespunzatoare atat a
software-ului cat si a procesului de dezvoltare care-l produce.
Asigurarea compatibilitatii depline cu standardele si procedurile stabilite pentru
software si pentru procesul software.
Asigurarea ca orice inadvertenta in produs, proces sau in strandarde este adusa in
atentia managementului, astfel ca aceste inadvertente sa poata fi reparate.
In cadrul organizatiilor, SQA este numita uneori ochii clientului. Aceasta face ca
organizatia sa faca lucrurile corecte la momentul potrivit in mod corect.

Originile SQA
Este bine cunoscut si acceptat ca o calitate inalta a produsului se traduce in scaderi ale
costurilor si imbunatatiri ale liniei de baza (bottom line). Miscarea calitatii a inceput in anii
1940 de catre W.Edwards Deming, denumita mai tarziu managementul calitatii totale (TQM).
TQM a fost utilizat pentru a revolutiona industria automobilelor in J aponia prin eliminarea
sistematica a radacinilor cauzatoare de erori. In perioada de inceput a computerelor (anii 1950
si 1960), calitatea a fost responsabilitatea principala a programatorului. Standardele de
asigurare a calitatii au fost introduse in contractul de software militar in anii 1970 si s-au
raspandit rapid in domeniul comercial. Principiile TQM au evoluat in modele de imbunatatire
a procesului software, cum sunt CMM, ISO9000 si SPICE.

Activitatile SQA
Asigurarea calitatii software cuprinde o varietate de sarcini asociate cu doua optiuni
diferite: inginerii software care realizeaza munca tehnica si grupul SQA care are
responsabilitatea planifica asigurarii calitatii, pastrarea inregistrarilor, analiza si raportarea.
Inginerii software realizeaza calitate prin:
aplicarea metodelor tehnice solide;
conducerea de revizuiri tehnice formale;
realizarea de teste software bine planificate.
Grupul SQA asista echipele de ingineri software in realizarea de produse finite de inalta
calitate; responsabilitatile lor includ urmatoarele:
Pregatirea unui plan SQA pentru un proiect;
Participarea la dezvoltarea descrierii procesului unui proiectului.
Verificarea activitatilor ingineriei software pentru verificarea concordantei cu
procesul definit.
Revizuirea anumitor produse software pentru a verifica daca sunt in concordanta
cu cele definite ca parte a procesului.
Asigurarea ca deviatiile sunt documentate si raportate managementului superior.
Coordonarea managementului modificarilor.
Ajutarea la determinarea si analiza masurilor software.
SQA este cea mai eficienta atunci cand isi percepe rolul nu ca inhibare, ci ca suport
pentru personalul de dezvoltare si intretinere in vederea imbunatatirii calitatii produsului.

10

Organizarea SQA-ului
Grupul SQA ar trebui sa raporteze prin-un lant independent de management. Adica,
dezvoltare trebuie sa aiba un manager, iar SQA un altul, si nici unul dintre acesti manageri nu
trebuie sa-i fie superior celuilalt. Adesea, cand se impune un termen limita, o organizatie
trebuie sa aleaga intre doua optiuni nesatisfacatoare, si anume: sa nu livreze produsul la timp
sau sa livreze un produs cu niste greseli serioase. Ambii manageri ar trebui sa raporteze unui
manager superior care poate cantari consecintele pentru organizatie si client.

Sedintele pentru verificarea tehnica formala
Verificarile tehnice formale (FTR) pot fi realizate in timpul fazelor de specificatii,
proiectare si codare. Documentul (de specificatii, proiectare si codare) este verificat cu grija
de catre o echipa de profesionisti software cu o gama larga de priceperi. Factorul de motivare
din spatele verificarilor este ca altii au sanse mai mari sa gaseasca erorile decat autorul
original. Avantajul unei verificari facute de catre o echipa de experti este ca diferitele
priceperi ale participantilor maresc mult sansele de gasire a unei erori. FTR poate lua forma
unei revizuiri sau a unei inspectii.

Revizuirile
O echipa de revizuire ar trebui sa fie formata din patru pana la sase membrii. O echipa de
revizuire ar trebui sa includa cel putin un proiectant (un membru al echipei care a produs
documentatia), un implementator (un membru al echipei din faza urmatoare de dezvoltare,
echipa care va primi documentatia), managerul responsabil cu documentatia si un
reprezentant al clientului. Moderarea revizuiri trebuie sa fie realizata de catre un reprezentant
al grupului SQA, deoarece grupul SQA are cel mai mult de pierdut daca revizuirea nu se
realizeaza bine si se strecoara erori.
O revizuire poate fi orientata fie spre participanti fie spre document. Intr-o revizuire
orientata spre participanti, acestia isi prezinta listele de erori sau elemente neclare. Intr-o
revizuire orientata spre document, o persoana responsabila cu documentatia le prezinta
participantilor pe scurt intregul document, participantii putand intrerupe fie cu comentarii
pregatite fie cu comentarii declansate de prezentare. Aceasta a doua abordare este posibil sa
fie mai detaliata si in general conduce la detectarea a mai multor erori. De fapt, majoritatea
erorilor sunt adesea detectate in mod spontan de catre prezentator.
Echipa nu trebuie sa corecteze erori, cu doar sa le inregistreze pentru corectie ulterioara.
Membrii echipei ar putea sa nici nu fie calificati pentru a face corectii; corectarea erorilor i-ar
putea distrage de la obiectivul lor si erorile semnalizate ar putea sa nu fie in realitate
incorecte. Nici o revizuire nu trebuie sa dureze mai mult de doua ore.

Inspectii
O inspectie merge mult mai departe decat o revizuire, si consta din cinci pasi:
O prezentare generala a documentului de inspectat este facuta de unul dintre cei
responsabili cu realizarea sa.
Pregatirea. Participantii se pregatesc pentru inspectie, studiind pentru a intelege
documentul in detaliu.
Inspectia. Este realizata o revizuire orientata spre document. Intr-o singura zi,
liderul echipei de inspectie (moderatorul) va realiza un raport scris pentru a
asigura o trecere in revista riguroasa.
Persoana responsabila cu documentul il va reface, rezolvand toate erorile si
problemele trecute in raportul scris.
11

Urmarea. Moderatorul trebuie sa asigure ca fiecare aspect pus in discutie a fost
rezolvat in mod satisfacator. Daca a fost refacut peste 5% din materialul inspectat,
atunci echipa este reconvocata pentru o noua inspectie 100%.

Echipa de inspectie trebuie sa contina patru membrii: moderatorul, proiectantul,
implementatorul si testorul. O componenta esentiala a unei inspectii este pregatirea echipei. O
strategie cheie este utilizarea unei liste de verificare a erorilor potentiale, bazata pe cele tipice
ale proiectelor precedente. Astfel, este important ca echipa sa inregistreze statistica erorilor.
Erorile trebuie inregistrate si categorisite in functie de severitate (majore sau minore) si de
tipul erorii (de interfata, logice, etc).
Desi se pare ca SQA ar putea creste costul dezvoltarii software-ului, nu este este asa.
Costul suplimentar este relativ mic in comparatie cu beneficiile castigate. Multe studii au
demonstrat ca revizuirile si inspectiile conduc la descoperirea unei mai mari parti din erori
devreme in ciclul de dezvoltare software, acolo unde costul lor este mult mai mic. FTR-urile
aplicate in faza de proiectare s-a vazut ca descopera pana la 75% din toate defectele. Intr-un
studiu din 1981, IBM a determinat ca daca pentru o eroare descoperita in faza de proiectare
corectarea costa 1.0 unitati monetare, aceasi eroare descoperita chiar inainte de faza de testare
costa 6.5 unitati monetare, in timpul testarii 15 unitati si dupa livrare intre 60 si 100 de unitati.
Nu numai corectarea erorilor este mai scumpa in fazele tarzii ale ciclului de viata
software, ci erorile din primele faze ale procesului se propaga in stadiile finale si sunt
amplificate intr-un numar mai mare de erori globale.
Aceasta este cunoscuta ca propagarea defectului. In tabelul urmator se prezinta calculul
economiilor realizate de un model al amplificarii defectului:
Erori gasite Numar Unitati de cost Total
Revizuiri realizate
In timpul proiectarii 22 1.5 33
Inaintea testarii 36 6.5 234
In timpul testarii 15 15 315
Dupa livrare 3 67 201
783
Nici o revizuire realizata
Inaintea testarii 22 6.5 143
In timpul testarii 82 15 1230
Dupa livrare 3 67 804
2177

Ghid pentru revizuire:
Se revizuieste produsul, nu producatorul.
Se realizeaza si se respecta o agenda.
Se limiteaza dezbaterile si rebuttal.
Se enunta domeniul problemei, dar nu se va incerca rezolvarea fiecarei probleme
observate.
Se iau notite scrise.
Se limiteaza numarul de participanti si se insista asupra pregatirii dinainte.
Se realizeaza o lista de verificare pentru fiecare produs care este probabil sa fie
revizuit.
Se aloca resurse si se planifica in timp FTR-urile.
Se realizeaza instruirea tuturor recenzorilor.
Se recapituleaza revizuirile precedente.
12

8.2. Masurarea calitatii software

8.2.1. Problemele masurarii calitatii
O masura a calitatii este un numar care reprezinta o fateta sau un aspect al calitatii
software-ului. Tot masura este orice tip de masuratoare care se refera la un sistem software,
un proces sau artifact inrudit.
Masuri de control sunt utilizate pentru a controla procesul de dezvoltare (de exemplu
efortul asteptat, timpul scurs, utilizarea discului, etc).
Masuri de predictie sunt utilizate pentru a prezice calitatea unui produs asociat (de
exemplu complexitatea ciclomatica poate prezice usurita in intretinere).
Factorii externi sunt cei care pot fi descoperiti doar dupa ce software-ul a fost dat in
utilizare (de exemplu mentenanta usoara). Factorii interni sunt cei care pot fi masurati direct
din cadrul software-ului (de exemplu complexitatea ciclomatica).
De aceea se pune problema utilizarii factorilor interni pentru a prevedea valorile celor
externi, dar este greu de formulat si validat relatii intre factorii interni si cei externi. Masurile
software trebuie sa fie determinate, calibrate si interpretate. In fig.8.3. se prezinta cateva
relatii intre factorii interni si cei externi.

Fig.8.3. Relatii intre factorii interni si externi

Frecvent, un factor de calitate software este masurat (sau estimat) prin determinarea
valorilor a catorva masuri inrudite si apoi realizarea sumei ponderate:
n n 2 2 1 1
m w ... m w m w Qi + + + =
unde:
Qi reprezinta un factor de calitate software care ne intereseaza dar care este greu
de masurat direct;
m
1
, m
2
, ..., m
n
w
sunt masuri ale caror valori pot fi determinate relativ usor si care
sunt legate de factorul de calitate software;
1
, w
2
, ..., w
n
Valorilor coeficientilor de pondere sunt in general setate (sau poate estimate) prin
examinarea datelor de la proiectele vechi si estimand importanta relativa a fiecarei masuri
pentru factorul de calitate care se determina. Cu cat sunt disponibile mai multe astfel de date,
cu atat vor fi mai exacti coeficientii de pondere.
sunt ponderi (coeficienti de regresie), adica numere reale care sunt
fixate pentru fiecare sistem sau proiect in parte si determina modul si gradul in
care valoarea fiecarei masuri afecteaza factorul de calitate software.
Exista doua tipuri de masuri ale calitatii:
o masura a produsului este un numar derivat (sau extras) direct dintr-un document
sau din codul programului.
o masura a procesului este un numar extras din performanta unei sarcini software.
Asa cum s-a definit mai sus, disponibilitatea este o masura a procesului care
depinde de fiabilitatea software-ului.

13

8.2.2. Masurarea calitatii in sistemele SQA
In sistemul SQA masurarea calitatii este un proces complicat si consta in verificarea
tuturor activitatilor ce concura la elaborarea produsului. Aceste activitati se prezinta in
continuare:
Asigurarea calitatii este o activitate de tip umbrela si consta in respectarea unor
standarde software si determinarea unor masuri software;
Calitatea produsului pe baza masurilor calitatii proiectului si programului se
realizeaza diverse abordari formale;
Calitatea proiectului apreciata prin verificari si managementul configuratiei
software;
Calitatea procesului pe baza standardului ISO 9001/9000-3 si a modelului SEI de
maturitate a posibilitatilor;
Calitatea personalului pe baza modelului de maturitate a personalului.
Utilizarea masurilor calitatii sunt folositoare:
ca un prag de asigurare a calitatii. Valorile minime (sau maxime) acceptabile
pentru masuri pot fi date in specificatiile cerintelor, pentru a fixa cerinte
cupirnzatoare si testabile legate de factorii de calitate (pe langa cerintele
functionale si de performanta).
ca un mecanism de filtrare. De exemplu, frecvent este adevarat ca nu sunt
disponibile resurse suficiente pentru o inspectie riguroasa a intregului cod asociat
unui proiect. Se stie ca, in general, codul mai complex va fi mai dificil de
intretinut si testat decat codul mai putin complex. O masura a complexitatii poate
fi utilizata pentru a identifica codul cel mai complex care face parte din proiectul
software curent si apoi se poate inspecta si testa cu mare atentie acest cod si mai
riguros decat ar fi fost posibil daca intregul cod ar fi necesitat aceeasi atentie.
pentru evaluarea metodelor de dezvoltare. Este (asadar) recomandabil sa se
intretina o baza de date statistica despre proiectele trecute.
pentru a ajuta la controlul complexitatii, mai ales in timpul intretinerii.
Complexitatea codului tinde sa creasca pe masura ce este intretinut si modificat.
Ar putea fi mai ieftin (pe termen lung) sa se reproiecteze si recodeze un modul
complex decat sa se continue incercarea de peticire a lui.
pentru asigurarea de feedback pentru personal privind calitatea muncii sale.

8.2.3. Standarde de calitate software
In vederea asigurarii calitatii au fost introduse standarde de calitate care sa poate fi
verificate sau chiar masurate.
Doua standarde de calitate sunt mai folosite si anume: standardul de calitate pe produs si
standardul de calitate pe procesul de productie.
Primul standard apartine IEEE.
Standardul IEEE 982.1-1988 se refera la proprietatile subsistemului (numarul de
subsisteme si gradul de cuplare) si proprietatile bazei de date (numar de atribute si clase).
Se calculeaza un index de calitate a structurii proiectului (DSQI) care ia valori intre 0 si 1.
Acest index este utilizat pentru comparare cu proiecte precedente: daca DSQI este prea mic,
ar putea fi necesara proiectarea si verificare suplimentara.
De asemenea, putem lua in considerare modificarile facute pe perioada ciclului de viata a
software-ului si calcula cat este de stabil produsul (adica, cate modificari sunt in subsistemele
din versiunea curenta). Se defineste un index de maturitate software (SMI). Pe masura ce SMI
se apropie de 1, produsul incepe sa se stabilizeze.
Se noteaza:
S
1
=numarul total de subsisteme definite in arhitectura programului;
14

S
2
S
=numarul de subsisteme a caror functionare corecta depinde de sursa datelor de
intrare sau care produc date ce vor fi utilizate in alta parte;
3
S
=numarul de subsisteme a caror functionare corecta depinde de procesele anterioare;
4
S
=numarul de articole din baza de date (include obiectele si toate atributele care
definesc obiecte);
5
S
=numarul total de articole distincte din baza de date;
6
S
=numarul de segmente din baza de date (inregistrari diferite sau obiecte individuale);
7

=numarul de subsisteme cu o singura intrare sau iesire.
Structura programului:

=
altfel , 0
distincta metoda o utilizand dezvoltata fost a a arhitectur daca , 1
D
1


Independenta subsistemului:
1
2
2
S
S
1 D =
Subsisteme care nu depind de procesarile anterioare:
1
3
3
S
S
1 D =
Dimensiunea bazei de date:
4
5
4
S
S
1 D =
Compartimentarea bazei de date:
4
6
5
S
S
1 D =
Caracteristicile de intrare/iesire ale subsistemului:
1
7
6
S
S
1 D =
Din acestea se determina DSQI si SMI cu formulele:

=
i i
D w DSQI , unde w
i
=ponderea relativa a fiecarui D
i
( )
T
d c a T
M
F F F M
SMI
+ +
=
.

unde:
M
T
F
=numarul de subsisteme din versiunea curenta;
c
F
=numarul de subsisteme din versiunea curenta care au fost modificate;
a
F
=numarul de subsisteme din versiunea curenta care au fost adaugate;
d

=numarul de subsisteme din versiunea precedenta care au fost sterse din versiunea
curenta;
Pentru o componenta atributele cheie ale calitatii sunt corectitudinea si dificultatea in
implementare. Pentru evaluarea calitatii unei componente se au in vedere operatorii si
operanzii din aceasta si se calculeaza valorile pentru volumul componentei (V), dificultatea
componentei (D) si efortul necesar pentru implementarea componentei (E).
Notam:
n
1
n
=numarul de operatori unici dintr-o componenta;
2
N
=numarul de operanzi unici dintr-o componenta;
1
N
=numarul total de operatori;
2
L=N
=numarul total de operanzi;
1
+N
2
Se calculeaza:
=lungimea componentei.
Lungimea componentei in biti: ( )
2 1 2
n n log L V + = ;
15

Dificultatea de implementare a componentei:
2
2 1
n
N
2
n
D = ;
Efortul necesar pentru implementarea componentei: D V E = .

Al doilea standard apartine ISO.
In fig.8.4. se prezinta modelul de calitate ISO 9000.

Fig.8.4. Standardul ISO 9000

Standardul de calitate ISO 9001/9000-3 se refera la urmatoarele aspecte:
A. Cadrul sistemului de calitate
1) Responsabilitatea managementului
definirea, documentarea, intelegerea, implementarea si
intretinerea politei de asigurare a calitatii;
definirea responsabilitatilor si autoritatilor pentru tot personalul;
definirea, instruirea si finantarea resurselor de verificare interne;
un manager este insarcinat cu asigurarea ca programul de calitate
este implementat si intretinut;
2) Sistemul de calitate
necesita stabilirea unui sistem de calitate documentat;
trebuie sa fie un proces integrat pe intregul ciclu de viata;
3) Control intern al sistemului de calitate
necesita planificarea si realizarea de verificari;
rezultatele sunt comunicate managementului;
deficientele sunt corectate;
4) Actiuni de corectare
necesita identificarea cauzelor de neconformare a produsului;
eliminarea cauzelor posibile de neconformare;
modificarea procedurilor ca rezultat;
B. Activitatile de calitate din cadrul ciclului de viata
1) Verificarea contractului
contractele sunt verificate pentru determinarea daca cerintele sunt
definite adecvat, sunt in acord cu oferta si pot fi implementate;
2) Specificarea cerintelor clientului
proceduri pentru identificarea si colectarea cerintelor clientului;
3) Planificarea dezvoltarii
16

sunt definite si planificate procesele de productie;
4) Inregistrarea calitatii
este planificat procesul de asigurare a calitatii;
5) Proiectare si implementare
proceduri de control si verificare a proiectului;
include planificare activitatilor de proiectare, identificarea
intrarilor si iesirilor, verificarea proiectului si controlul
modificarilor din proiect;
6) Testare si validare
necesita testarea si validarea inainte de utilizare a
subsistemelor/produselor;
sunt pastrate inregistrari ale testelor;
7) Acceptare
trebuie stabilite proceduri pentru acceptare;
8) Multiplicare, livrare si instalare
trebuie stabilite si intretinute proceduri pentru acestea;
9) Intretinere
necesita realizarea de activitati de intretinere dupa specificatii;
C. Activitati de intretinere a sistemului de calitate
1) Managementul configuratiei
trebuie documentat si controlat procesul de dezvoltare si
intretinere;
2) Controlul documentarii
trebuie controlata distribuirea si modificarea documentelor;
3) Inregistrari ale calitatii
acestea trebuie colectate, intretinute si aranjate;
4) Masurare
tehnici statistice corespunzatoare trebuie identificate si utilizate
pentru verificarea acceptabilitatii caracteristicilor procesului si
produsului;
5) Reguli, practici si conventii
sunt stabilite si urmate;
6) Unelte si tehnici
sunt aplicate in mod adecvat pentru a sustine procesul de
dezvoltare;
7) Cumpararea
cumpararea produselor in conformitate cu cerintele specificate;
8) Produse software incluse
trebuie verificate si intretinute;
9) Instruirea
trebuie identificate necesitatile de instruire si asigurate deoarece
sarcinile specifice pot necesita personal calificat;
trebuie intretinute inregistrarile privind instruirea.

Modelul de maturitate a capacitatilor SEI (CMM) este realizat pentru a ajuta o organizatie
software sa-si imbunatateasca procesele de dezvoltare a software-ului. Exista mai multe
nivele pentru organizatii, dupa cum urmeaza:
Organizatii de nivel 1: proces initial (ad-hoc): fara proceduri formale, fara
estimare a costurilor, fara planuri ale proiectului, fara mecanism de management
pentru asigurarea ca sunt urmate procedurile;
17

Organizatii de nivel 2: proces repetabil (intuitiv): control de baza a proiectului;
utilizeaza metode intuitive;
Organizatii de nivel 3: proces definit (calitativ): definirea si institutionalizarea
procesului de dezvoltare
Organizatii de nivel 4: proces manajat (cantitativ): proces masurat, stabilirea
bazei de date a procesului;
Organizatii de nivel 5: proces optimizat: feedback pentru imbunatatire; analiza
si prevenirea riguroasa a cauzelor de defecte.
Avand in vedere aceasta clasificare, s-au stabilit cateva concluzii. Astfel, este posibil ca o
organizatie de nivel 1 sa primeasca certificatul de calitate ISO 9000. O organizatie de nivel 3
ar putea avea dificultati in obtinerea acestui certificat de calitate. O organizatie de nivel 2 ar
avea multe avantaje semnificative din obtinerea certificatului ISO 9000. Producatorii de
software foarte valoros (de exemplu pentru navete spatiale) ajung doar la nivelul 3 sau 4.

8.3. Complexitatea software

8.3.1. Definirea complexitatii
Este o apreciere globala a masurarii calitatii produsului software.

Definitie
Complexitatea este o masura a resurselor care trebuie cheltuite pentru dezvoltarea,
intretinerea sau utilizarea unui produs software.

Masurile complexitatii sunt necesare. De exemplu: daca se considera cateva proiecte
atunci in general este bine sa se aleaga acela care este cel mai putin complex, in cazul in care
nu este descalificat din alte motive. Astfel, masurile pot fi utile pentru compararea solutiilor
propuse pentru probleme si alegerea dintre ele.

Resursele considerate sunt:
timpul si spatiul de memorie;
ore-om pentru supraveghere, intelegere, proiectare, codare, testare, intretinere si
modificare a software-ului;
scopul software-ului suport, de exemplu: asambloare, interpretoare, compilatoare,
sisteme de operare, editoare de programere de mentenanta, depanatoare si alte
utilitare;
cantitatea de module de cod reutilizat;
cheltuieli de transport;
suport pentru publicatii tehnice si activitati de secretariat;
cheltuieli neprevazute pentru personal si sisteme hardware.
In faza de concepere pot fi considerate sau nu stocarea, complexitatea si timpul de
procesare.
Masurarea complexitatii este utila pentru:
Clasificarea proiectelor adverse si stabilirea unei distante intre pozitii.
Clasificarea dificultatii diferitelor module pentru a asigna personal.
Determinarea daca este necesara subdivizarea unui modul.
Masurarea progresului si calitatii in timpul dezvoltarii.
O parte mare dintre resurse sunt utilizate pentru gasirea erorilor, depanare si retestare;
astfel, o masura asociata a complexitatii este numarul de erori software.

18

Complexitatea programului poate fi logica, psihologica sau structurala.
Complexitatea logica poate fi dificil, lung sau imposibil de dovedit corectitudinea, de
exemplu cresterea numarului de cai de program distincte.
Complexitatea structurala are de-a face cu numarul de module ale unui program.
Complexitatea psihologica face dificila intelegerea software-ului. Aceasta este
cunoscuta in mod uzual drept comprehensibility.

Complexitatea logica a fost masurata printr-o masura din teoria grafurilor, si anume
numarul ciclomatic.
McCabe calculeaza caile dintr-un program. Fiecare nod corespunde unui bloc de cod,
fiecare arc unei ramuri. Apoi calculeaza numarul ciclomatic (numarul maxim de circuite liniar
independente), si controleaza complexitatea prin limitarea acestui numar.
In fig.8.5. se prezinta o schema logica si schema graf corespunzatoare.

Fig.8.5. Realizarea schemei graf

Pe scurt, aceasta este o unealta utila in pregatirea datelor de test si asigura informatii utile
despre complexitatea programului. Oricum, nu tine seama de stucturile de date, algoritmi,
numele variabilelor, comentarii si aspecte cum ar fi portabilitatea, flexibilitatea, eficienta.

Complexitatea structurala poate fi absoluta sau relativa. Complexitatea structurala
absoluta masoara numarul de module, cea relativa este raportul dintre legaturile modulului si
module. Obiectivul este minimizarea conexiunilor dintre module prin care se pot propaga
erori.
Adeziunea (legatura) se refera la relatiile intre componentele unui modul. Adeziunea
mare este caracterizata de catre un modul care realizeaza o sarcina procedurala distincta;
aceasta adopta complexitate structurala relativa scazuta. Principalele tipuri de adeziune sunt:
coincidenta: task-urile depind slab unele de altele, sau chiar deloc.
logica: task-urile sunt legate logic (de exemplu modulul citeste intrarea, indiferent
de tipul acesteia);
temporala: task-urile trebuie executate in acelasi interval de timp;
procedurala: elementele unui modul trebuie executate intr-o ordine specifica;
19

comunicationala: elementele de procesare impart o structura de date comuna;
secventiala: iesirea unei componente este intrare pentru o alta;
functionala: fiecare element de procesare este esential pentru realizarea unui
singure functii.
In fig.8.6. se prezinta aceste tipuri de adeziune.

Fig.8.6. Spectrul adeziunii

Complexitatea psihologica include aspecte cum ar fi:
comentarii de nivel inalt si jos;
nume de variabile mnemonice;
complexitatea fluxului de comanda;
tipul programului general.
Sheppard a facut o serie de experimente cu programatori profesionisti, tipuri de programe
(ingineresti, statistice, nenumerice), nivele de structurare si nivele de nume de variabile
mnemonice. A ajuns la concluzia ca programele cu cat sunt mai putin structurate cu atat
sunt mai dificil de reconstruit (dupa studierea timp de 25 de minute) si cele partial
structurate sunt cel mai usor de reconstruit. Nu s-au evidentiat diferente pentru numele de
variabile, nici pentru ordinea de prezentare a programelor.
Shneiderman sugereaza o regula 90-10, adica un programator competent ar trebui sa
fie in stare sa reconstruiasca functional 90% dintr-un program dupa un studiu de 10
minute (sau un modul in cazul programelor mari). O abordare mai uzuala ar fi regula 80-20,
iar o abordare mai riguroasa regula 95-5. Aceasta se bazeaza pe experimente de memorare-
reconstructie.

8.3.2. Masurarea complexitatii codului
Teoria complexitatii nu ne permite inca sa masuram aspecte separate, cum sunt de
exemplu problema, algoritmul, proiectul, limbajul, functiile, modulele si sa le combinam
pentru a masura si compara complexitatea globala.
Majoritatea masurilor complexitatii se concentreaza asupra programului. Numarul
instructiunilor este utilizat pentru a prevedea orele-om si costurile dezvoltarii. Un limbaj de
nivel inalt poate avea intre 4:1 si 10:1 raportarea la limbajul de asamblare.
O abordare statistica, utilizata de Halstead, ia in considerare numarul total de operatori si
operanzi, si ii raporteaza la efortul de dezvoltare. Masurile sale cuprind un set de masuratori
primare care se pot deriva din codul sursa, cum este numarul total de aparitii ale tuturor
operatorilor utilizati si numarul total de aparitii ale tuturor operanzilor utilizati.
Aceste masuratori sunt utilizate pentru dezvotarea de expresii de estimare a volumului de
cod:
( ) Vocabular log Lungime Volum
2
=
unde Lungime =numarul total de aparitii ale tuturor operatorilor utilizati +numarul total
de aparitii ale tuturor operanzilor utilizati; si Vocabular =numarul de operatori unici utilizati
+numarul de operanzi unici utilizati.
Aici, volumul programului este definit ca fiind numarul de biti necesari pentru realizarea
unui program. Din aceste masurari, s-au specificat estimatori ai efortului de dezvoltare, ai
timpului de dezvoltare si numarul de greseli.

20

Exemplu:
function unique (newword:shortstring; wordlist: list): boolean;
{modul pentru determinarea daca un anumit cuvant s-a mai intalnit inainte}
var index: integer;
begin
unique := TRUE;
for index := 1 to wordlist.count do
if newword = wordlist.word[index] then
unique := FALSE;
end;

O data ce se elimina comentariile si semnele de punctuatie din cod, Lungimea inseamna
doar numararea operatorilor (:=, =) si cuvinte (siruri de caractere alfanumerice consecutive
separate prin spatii si controale de linie), si Vocabularul este numarul de cuvinte unice. Pentru
acest exemplu, numarul total de cuvinte este 33. Dintre acestea 24 sunt unice. Volumul
modulului este asadar 151 de biti (=33 x log
2
Intre prezicerea analitica utilizand modelul lui Halstead si rezultatele experimentale s-a
gasit o buna concordanta. Oricum, acesta nu ia in considerare numele variabilelor,
comentariile, alegerea algoritmului sau structurilor de date. Ignora si aspectele generale de
portabilitate, flexibilitate si eficienta.
(24)).
Din pacate, aceasta abordare presupune ca deja a fost scris codul si asadar nu poate ajuta
la prevederea timpului necesar dezvoltarii sale.

8.3.3. Masurarea complexitatii algoritmului
Considerarea lungimii si dificultatii instructiunilor dintr-un program individual nu ia in
calcul si relatiile dintre instructiuni, adica complexitatea structurala. Majoritatea muncii la
complexitatea structurala se refera la masuratorile topologice ale grafului. Teoria grafurilor nu
poate reprezenta stocarea sau operanzii. Se concentreaza asupra transferului controlului.
Daca exista o ordine in conexiune, sau arc, atunci acesta este un graf orientat sau digraf.
Daca nu exista nici o ordine atunci linia de conectare este o muchie.
Un graf orientat este un graf regulat.
Un digraf este strans conectat daca exista o cale care uneste fiecare pereche de noduri ale
digrafului, astfel incat orice nod poate si atins din oricare alt nod. In fig.8.7. se prezinta un
exemplu de graf conectat.

Fig.8.7. Digraf strans conectat

Numarul ciclomatic vG al grafului G este egal cu numarul maxim de cicluri liniar
independente. Numarul ciclomatic vG al unui digraf strans conectat este egal cu numarul
maxim de circuite liniar independente.
vG = m-n+1, pentru un graf cu m arce, n noduri.
De exemplu, daca m=9 si n=5 atunci vG=5
Exista diferite alte metode de calcul a numarului ciclomatic al unui graf.

21

Masurile complexitatii
Graful unui program este obtinut din concentrarea fiecarui proces si simbol decizional
dintr-o diagrama de flux intr-un punct (nod) si linii care le unesc (arce). Directia este
importanta, astfel fiind obtinut un graf orientat (digraf). In fig.8.8. se prezinta digraful unei
diagrame de flux.

Fig.8.8. Digraf corespunzator unei diagrame de flux

Pentru exemplul din fig.8.8, avem:
nodurile a si k corespund blocurilor de start si de stop
nodul c corespunde lui GET A
nodul i corespunde lui L=L+1
ciclul (bucla) este compusa din arcele 4, 5, 6, 7, 8
IF THEN ELSE apare ca 5, 6 si 9, 10

Numarul ciclomatic al digrafului da o masura a complexitatii. Comparatiile arata ca o
complexitate ciclomatica mare este asociata cu programe inclinate spre erori.
Un graf este construit cu un singur nod de start si un singur nod de stop. Daca exista un
nod de neatins, acesta reprezinta cod imposibil de atins sau eroare de codare care trebuie
corectata.
In general graful nu este strans conectat, deci se poate forma o bucla in jurul intregului
program (arc fantoma), asa cum se prezinta in fig.8.9.

Fig.8.9. Adaugarea unui arc fantoma
22

In exemplul de mai sus numarul de arce m=13 si numarul de noduri n=11, deci:
vG =13-11+1 =3.
McCabe spune ca vG este o masura buna a complexitatii si toate modulele ar trebui sa
aiba vG<10. Aceasta inlocuieste regula generala aproximativa, care spune ca un modul ar
trebui sa aiba o pagina de cod (intre 50 si 60 de linii). El a aratat ca programele cu un vG mare
sunt inclinate spre erori.

2

9.1. Probleme generale privind managementul ingineriei programarii

9.1.1. Definitia si structura manageratului
Managementul reprezinta o componenta importanta a activitatilor productive. O definitie
generala a managementului arata ca acesta se refera la actiunile indreptate spre eficientizarea
utilizarii resurselor in scopul urmaririi unor obiective.
Activitatile manageriale sunt: planificarea, organizarea, conducerea si reglarea utilizarii
resurselor in procesul de productie.
Pe de alta parte resursele pot fi: umane, fizice, financiare, informationale. Schema bloc
din fig.9.1. reprezinta structura managementului conform definitiei.

Fig.9.1. Structura managementului

Ingineria programarii, care cuprinde echipamente, metode si tehnici de producere,
intretinere si dezvoltare software, este considerata a fi atat o tehnica, cat si o arta. Mai mult
decat in alte activitati aici factorul uman si creativitatea sa reprezinta elementele dominante.
Din aceste motive managementul in ingineria programarii reprezinta in cea mai mare parte
coodonarea eficienta a resurselor umane in scopul realizarii software-ului conform cerintelor
si specificatiilor de calitate.
Deci cea mai importanta componenta o reprezinta resusele umane, de aceea in continuare
ne vom referi la managementul acestor resurse, denumit staffing.
Staffing este procesul de procurare si management (conducere) a resurselor umane de
care are nevoie o organizatie pentru a-si realiza obiectivele.

Procesul de staffing
In fig.9.2. se prezinta in detaliu procesul de staffing de baza.


Fig.9.2. Procesul de staffing
3

Mai intai, asa cum se vede in partea stanga a figurii, procesul de staffing trebuie sa tina
seama de o serie de constangeri legale care restrictioneaza activitatea unei firme. In acest
mediu legal, primul pas este planificarea resurselor umane, care presupune intelegerea
completa a diferitelor sarcini ale organizatiei, prevederea numarului de oameni necesari si
diponibili pentru realizarea acestor sarcini si incercarea de a realiza o potrivire cat mai buna
intre oferta si cerere.
Daca sunt necesari mai multi angajati, organizatia trebuie sa recruteze solicitanti calificati
si apoi sa-i aleaga pe cei mai potriviti pentru posturile neocupate. Noii angajati trebuie
pregatiti si instruiti si trebuie evaluata performanta lor in timpul muncii. Desigur, ei trebuie
recompensati pentru timpul lucrat si trebuie sa li se ofere oportunitatea de a participa la
programe profitabile. Recompensarea lor poate fi modificata ca urmare a evaluarii
performatelor, si, dupa cum se vede in figura, si sindicatele pot afecta sau pot fi afectate de
aceste activitati.
Aceste functii sunt realizate de catre directorul de personal in cadrul firmelor mici. Pe
masura ce firma creste se creaza un departament de personal sau resurse umane.

Constrangeri legale
Unul din factorii care au contribuit la crestea importantei managementului resurselor
umane este numarul si complexitatea constrangerilor legale cu care se confrunta orice
organizatie. Datorita tuturor legilor de acest gen, procesul de staffing este poate cel mai
afectat de mediul legal dintre toate procesele de management. De aceea, directorii de resurse
umane au devenit membrii de baza ai organizatiilor.

9.1.2. Planificarea resurselor umane
Prima faza a procesului de staffing este planificarea resurselor umane, care consta din trei
pasi: analiza slujbei (job), prevederea cererii si ofertei de resurse umane si potrivirea intre
cerere si oferta (combinarea ofertei cu cererea). In fig.9.3. sunt ilustrati acesti pasi.

Fig.9.3. Planificarea resurselor umane

Analiza slujbei
Analiza slujbei este colectarea si inregistrarea sistematica a informatiilor despre slujbele
dintr-o organizatie. Aceasta consta din doua activitati: descrierea slujbei, care cuprinde
sarcinile ce ii revin, si specificatia slujbei, care cuprinde priceperile, capacitatile si alte calitati
necesare realizarii slujbei.

Prevederea cererii si ofertei de resurse umane
Prevederea cererii presupune determinarea numarului si tipului de angajati de care
organizatia va avea nevoie la un moment dat in viitor.
4

Prevederea ofertei inseamna determinarea resurselor umane care vor fi disponibile, atat in
interiorul cat si in exteriorul organizatiei.

Potrivirea intre cerere si oferta
Dupa realizarea ambelor prevederi, trebuie comparate rezultatele si planificate anumite
actiuni. Dupa cum se vede in fig.9.3. vor exista trei alternative. Daca se prevede ca oferta va
depasi cererea, managementul trebuie sa planifice somajul, concedierile, pensionarile timpurii
si uzura normala. Daca cererea depaseste oferta, managementul trebuie sa planifice recrutarea,
selectarea si pregatirea de noi angajati. In sfarsit, daca cererea si oferta sunt aproape aceleasi,
nu este necesara nici o actiune de moment, desi situatia trebuie monitorizata pentru cazurile in
care fie cererea, fie oferta se modifica.

9.1.3. Recrutarea si selectia resurselor umane
Daca o organizatie are nevoie sa angajeze mai multe persoane, fie datorita extinderii fie
doar ca sa inlocuiasca angajatii care pleaca, trebuie sa inceapa faza de selectie a resurselor
umane. Aceasta faza consta din trei pasi: recrutare, selectia efectiva si orientarea.
Recrutarea este procesul de atragere a unui grup de solicitanti calificati care sunt interesati
sa lucreze pentru companie.
O modalitate de recrutare este recrutarea interna incercarea de a identifica angajatii care
ar vrea sa fie transferati si/sau promovati. Aceasta metoda imbunatateste moralul angajatilor.
Recrutarea externa este solicitarea publica de solicitanti din afara companiei.
Odata recrutati solicitantii, organizatia trebuie sa-i selecteze pe cei mai potriviti pentru
slujba. Primul pas in selectie este ca posibilii viitori angajati sa completeze un formular de
angajare, care cere o serie de informatii despre slujbele anterioare, educatie, experienta, si
altele. Pentru selectie se utilizeaza adesea teste. Cele mai utilizate tipuri de teste folosite in
procesul de selectie sunt testele de abilitate (capacitate), pricepere, aptitudini si cunostinte.
Cea mai utilizata tehnica de selectie este totusi interviul discutia cu solicitantul. Pe langa
evaluarea solicitantului, intervievatorul poate sa-i prezinte si compania. Din pacate, in ciuda
utilizarii foarte intense, interviurile nu prezic prea bine succesul angajatului. Aceasta deoarece
judecata intervievatorului are corelatie redusa cu performante viitoare a angajatului.
Dupa ce este accepta oferta companiei, noul angajat trebuie sa treaca printr-o procedura
de orientare. Aceste proceduri difera mult de la o companie la alta. Orientarea pentru
operatori consta in simpla lor informare privind cand sa vina la serviciu, cand sunt platiti si
cui sa se adreseze daca au vreo problema. Orientarea personalului managerial si profesional
este mai elaborat. Poate dura cateva saptamani sau chiar luni de munca cu ceilalti angajati
pentru ca noul angajat sa cunoasca toate fazele organizatiei.

9.1.4. Pregatirea si dezvoltarea
Pregatirea in general inseamna invatarea deprinderilor de munca, in timp ce dezvoltarea
presupune capacitati mai generale si de obicei este directionata spre personalul managerial.

Tehnici de pregatire si dezvoltare
In tabelul urmator se prezinta cateva tehnici uzuale de pregatire si dezvoltare. Elementul
cheie este alegerea tehnicii potrivite obiectivelor eforului de pregatire si dezvoltare. De
exemplu, daca obiectivul este ca angajatii sa invete despre procedurile noi ale companiei, o
solutie buna este asignarea de materiale de citit. Daca obiectivul este sa invete oamenii cum sa
comunice mai bine intre ei sau cum sa ia decizii mai bune, cel mai bine s-ar potrivi
interpretarea de roluri sau grupuri pentru discutii de caz. Daca trebuie ca angajatul sa invete sa
opereze un nou tip de masina, optiunile cele mai potrivite sunt pregatirea separata sau la locul
de munca.
5

Metoda Comentarii
Asignarea de
materiale de citit
Materialele pot fi sau nu scrise special pentru pregatire.
Pregatirea prin
modele
comportamentale
Utilizeaza un model video care prezinta comportamentul corect, apoi
se interpreteaza rolurile si se discuta comportamentul corect. Utilizat
mai ales pentru pregatirea supervizorilor in relatiile interumane.
Simularea de
afaceri
Priceperile manageriale se predau fie prin simulari pe hartie, fie prin
jocuri pe calculator.
Discutii de caz Cazuri reale sau fictive sunt discutate in grupuri mici.
Conferinte Discutia intr-un grup restrans pe baza unor subiecte selectate.
Cursuri Prezentare orala, de catre lector, cu participare limitata.
La locul de
munca
Poate fi fara instruire, sau pregatire de catre alti angajati mai
experimentati, sau cu explicare, demonstrare si supervizare practica,
realizata de catre personalul de pregatire.
Instruire
programata
Metoda care utilizeaza text urmat de intrebari si raspunsuri. Costa
mult dezvoltarea.
Interpretarea de
roluri
Personalul de pregatire interpreteaza diferite roluri, cum ar fi seful
facand apreciere de performanta sau angajatul reactionand la
apreciere, pentru a castiga experienta in relatiile interumane.
Pregatirea
senzitiva
Este numita si pregatirea in laborator, aceasta este o experienta
intersiva cu un grup mic. Indivizii incearca noi comportamente si
furnizeaza reactii. Promeveaza increderea, comunicarea deschisa si
intelegerea dinamicii de grup.
Pregatirea
separata
Practica supervizata pe sarcini manuale intr-o zona de lucru separata
cu accent pe siguranta, invatare si reactie.

9.1.5. Aprecierea performantei
Aprecierea performantei este importanta pentru verificarea validitatii metodelor de
selectie, furnizand corect recompense si ajutand angajatii sa se perfectioneze.

Masuri obiective
Masurile obiective ale aprecierii performantei sunt indicatori cuantificabili ai modului de
lucru al angajatului. De exemplu, se poate numara cate unitati dintr-un produs asambleaza un
angajat, modificat numarul in functie de calitate si se ajunge la un indice de performanta.
Din nefericire, masurile obiective adesea nu sunt disponibile sau sunt inexacte. De
exemplu, muncitorii de pe liniile de asamblare nu au control asupra numarului de unitati pe
care le produc. De aceea, managerii trebuie sa modifice indicatorii obiectivi de performanta
pentru a asigura o reprezentare valida a performantelor reale.

Metode decizionale
O alta apreciere a performantei este prin metodele decizionale o persoana, de obicei
superiorul imediat al angajatului, evalueaza in mod subiectiv performanta acestuia, prin
clasificare sau prin evaluare.
Sistemul prin clasificare masoara performantele angajatilor prin comparare intre ei si
aranjare de la performante slabe la performante inalte.
Sistemul prin evaluare compara performanta angajatului cu un standard de performanta.
In fig.9.4. se prezinta doua scale de evaluare. Scalele evalueaza nivelul de constiinciozitate si
gradul de initiativa.
6


Fig.9.4. Scale de evaluare

Managementul prin obiective
Managementul prin obiective serveste ca o metoda utila pentru evaluarea performantei
managerilor care lanseaza obiectivele initiale. De exemplu, sa presupunem ca directorul de
vanzari de la Colgate-Palmolive lanseaza obiectivul de a creste cu 15% vanzarile in teritoriul
sau in anul urmator. La sfarsitul anului, acest obiectiv furnizeaza un cadru efectiv de apreciere
a performantei. Daca vanzarile au crscut intr-adevar cu 15% sau mai mult, se poate face o
aprociere pozitiva a performantei. Dar daca vanzarile au crescut cu doar 4% si daca directorul
este direct raspunzator de aceasta poate fi realizata o apreciere negativa.

9.1.6. Compensatii si beneficii
Managementul compensatiei si beneficiilor este o alta parte importanta a procesului
resurselor umane. Angajatii trebuie sa fie platiti prin salarii si de obicei se asteapta sa
primeasca si diferite feluri de beneficii. Organizatia utilizeaza adesea stimulente financiare
pentru a imbunatatii motivarea si pentru a recompensa performanta trecuta.
Nivelul salariului se refera la salariile unei companii in comparatie cu salariile locale sau
industriale predominante. Structura salariala este comparatia de salarii pentru diferite slujbe
din cadrul unei companii.
O alta parte importanta a compensatiilor o constituie pachetul de beneficii asigurat.
Beneficiile sunt plati altele decat salarii si se adauga la compensatia totala primita de angajat,
reprezentand un supliment pentru salarii. Beneficii uzuale sunt: asigurari de sanatate,
stomatologice, de accidente, de viata pentru angajat (cateodata si pentru familia sa), acestea
putand fi suportate in totalitate sau partial de organizatie.

Uniuni sindicale
Ultimul aspect al managementului resurselor umane sunt relatiile sindicale, un termen
care in general se refera la relatiile cu angajatii organizati in uniuni sindicale.

Negociere colectiva
Procesul de negociere colectiva se concentreaza pe acordul asupra unui contract scris care
va acoperi toate aspectele relevante ale relatiilor dintre organizatie si membrii uniunii.

9.2. Managementul personalului programator

9.2.1. Legea lui Parkinson
Personalul programator reprezinta resursele umane de baza in producerea software-ului.
Adesea aceste resurse sunt denumite peopleware.
In cele ce urmeaza se prezinta principalele probleme legate de managementul
personalului programator.
Se pare ca la baza esuarii proiectelor software se afla personalul si nu problemele tehnice.
7

Legea lui Parkinson spune ca: Munca se extinde pana umple timpul alocat ei.. Pentru
acesta managementul a gasit ca raspuns stabilirea unor date de livrare foarte optimiste, dar
imposibil de realizat. Din experienta se poate spune ca estimarile sunt de fapt
contraproductive.
Solutia posibila este construirea unei echipe strans legate, cu responsabilitatile impartite,
astfel incat programatorii fac extimarile, se realizeaza un cult al calitatii, se asigura multe
posibilitati satisfacatoare de repartizare a muncii, se construieste un sens de elita, se permite si
se incurajeaza individualismul si se impun directii strategice si nu tactice. Astfel de echipe de
succes trebuie pastrate si protejate.

9.2.2. Reguli de baza privind managementul personalului
In vederea realizarii managementului personalului programator este bine sa se tina seama
de particularitatile acestei activitati si de principalele reguli stabilite pe baza experientei.

Regula nr.1: Doar cei mai buni programatori aduc contributii semnificative.
Dupa cum spune si Brooks, un programator bun este de 10 ori mai productiv decat un
programator mediu. Programatorii de nivel mediu vor petrece aproape intreaga lor zi de
munca citind si intelegand codul nou generat de programatorii buni.
Asadar, pentru a asigura succesul, managerul personalului programator trebuie sa creeze
un mediu de lucru in care programatorii buni vor avea destule satisfactii pentru a ramane in
echipa. De asemenea trebuie sa creze un sistem in care programatorii de nivel mediu sa
devina programatori buni.

Regula nr.2: Acordul comun (consensul) este esential dar aproape imposibil de
realizat.
Personalul programator de la toate nivelele se crede la fel de inteligent, deci necesita
consens in luarea unor decizii. Un muncitor oarecare este mai expert ca orice manager, fiind
astfel dificila orice controversa tehnica cu acesta. Persoanele cu idei slabe si productivitate
scazuta se cred adesea cu capacitati superioare. Iar programatorii care au intr-adevar capacitati
superioare, nu are rost sa se astepte cineva sa se inteleaga cu ei.
Asadar, pentru a asigura succesul, managerul personalului programator trebuie sa isi
asigure credibilitatea personalului participand el insusi la munca (codare, proiectarea
modelelor de date, scrierea documentatiilor sau articolelor in reviste). De asemenea, poate
delega capacitatea de decizie unui grup restrans care include o persoana competenta si de
incredere. Pot fi implicati in luarea deciziilor si a reprezentantilor cheie ai clientului astfel
incat programatorii sa-si da seama cum sunt apreciati. In anumite siatuatii, un bun manager al
personalului programator trebuie sa stie sa apeleze la duritate atunci cand democratia nu mai
functioneaza.

Regula nr.3: Masurarea productivitatii software se stie bine ca este dificila.
Lumea e plina de produse care au esuat datorita proiectarii fara gust si mult prea
complexa. Sistemele pe care expertii le-au evaluat si au considerat ca lasa de dorit, ca de
exemplu Unix in 1970, s-au dovedit a avea o mare utilitate. Calitatea si productivitatea nu au
nici o legatura una cu alta (cateodata trebuie stricat totul pentru a face ceva sa functioneze mai
bine).
Asadar, pentru a asigura succesul, managerul personalului programator trebuie sa
masoare productivitatea in termenii testelor trecute, greseli reparate, cunostiinte achizitionate
si comunicate echipei. De asemenea trebuie sa ia in considerare realizarile membrilor si sa
comunice cu acestia zilnic si in privat.

8

Regula nr.4: (Legea lui Parkinson). Munca se extinde pana umple timpul alocat ei.
Un termen limita nu face decat sa furnizeze o scuza pentru amanare si pentru a nu face
nimic pana in apropierea acestuia. In domeniul software timpul este un factor delicat,
deoarece, pe de o parte, software-ul este o stiinta experimentala si intotdeauna se pot face noi
si noi experimente si pe de alta parte, software-ul nu are limita in privinta perfectionarii.
Asadar, in loc sa se stabileasca termene limita, trebuie mentinut ritmul de lucru.

Regula nr.5: Oamenii fac lucrurile pentru care sunt recompensati, nu ceea ce crede
managerul ca vor face.
In cartea Bringing out the Best in People (Evidentierea a ceea ce este mai bun la
oameni), Aubrey Daniels spune ca Daca am fi facut intotdeauna ceea ce ni s-a spus, am fi
mancat doar mancare nutritiva, nu am fi baut niciodata prea mult alcool si am fi exersat
periodic..
Cea mai buna solutie de motivare a angajatilor nu este clasicul bonus anual, deoarece este
mult prea indepartat in timp fata de deciziile cotidiene.
Asadar, trebuie atribuite recompense mici, dar frecvente pentru realizarile personalului.

Regula nr.6: Cei cu performante mici atrag cel mai mult atentia; aceasta
incurajeaza subperformantele.
Este foarte usor sa se neglijeze personalul cel mai bun deoarece acesta nu are nevoie de
indicatii. Dar, prin aceasta, cei cu performante scazute ar putea percepe atentia ca pe o
recompensa a comportamentului lor neproductiv.
Asadar, trebuie asigurata atentie zilnica intregului personal in special celui de elita.

Regula nr.7: Construirea si mentinerea unei echipe software bune se face prin
atragerea de ingineri software si de programatori buni.
Inginerii software se testeaza in timp, de aceea solutia este angajarea catorva si verificarea
lor ulterioara. Deoarece cei mai buni programatori cauta problemele cele mai provocatoare,
solutia de a-i gasi este utilizarea la inceput a problemelor banale si stabilirea de timp
neinsenmant pentru acestea.

Regula nr.8: Sursa primara de gratificare a ego-ului programatorilor este ca ceilalti
programatori sa le admire munca.
Astfel proiectele software open-sourse au un mare avantaj pentru recrutare. De asemenea
trebuie ca fiecare membru al echipei sa lucreze cu codul celorlalti. Nu este bine ca proiectul sa
fie impartit in module care sunt realizate fiecare de cate un programator, ci este mai bine ca
programatorii sa lucreze in grupuri mici si sa imparta codul cu alte grupuri.
Deoarece programatorii buni vor sa creeze, deci cel mai important pas il constituie
indepartarea oricaror bariere in calea creatiei. Programatorii urasc procesele elaborate, sedinte
fara sfarsit si esantioane de evaluare a pietei inaintea livrarii unui produs. Se recomanda
adoptarea unui proces lejer si a unei structuri de management a proiectului netezita.

Regula nr.9: Este necesar un mediu de lucru bun pentru programatori.
Succesul firmei de software depinde de timpul pe care programatorii il petrec la locul de
munca. De aceea biroul lor trebuie sa arate mai bine decat casa unui programator, pentru ca
acesta sa petreaca timp cat mai mult la serviciu.

Regula nr.10: Cei mai buni programatori au multe satisfactii chiar din munca lor.
Acesti programatori scriu cod pe care il pot vedea imediat functionand. Aceasta ii tine la
lucru ore intregi. Deci este bine sa se incurajeze construiri frecvente pentru a mentine sistemul
9

integrat si sa se ceara ca tot codul sa fie testat imediat ce este scris. Facand aceasta
programatori isi vor vedea codul lucrand asa cum trebuie. Neglijand acest lucru programtorii
vor pierde ore intregi gandindu-se de ce nu functioneaza codul lor.

Regula nr.11: Transformarea unui programator mediu intr-un programator bun.
Pentru a avea in timp doar programatori buni in echipa trebuie avute in vedere cateva
aspecte la angajarea de personal programator, si anume: sa aiba o educatie foarte buna in
domeniul stiintei calculatoarelor; un coeficient de inteligenta (IQ) ridicat; abilitati bune de
comunicare atat scris cat si vorbit; sa fie motivat sa programeze ca hobby in timpul liber, sa
doreasca sa invete lucruri noi; si cel mai important sa aiba experienta semnificativa.

Regula nr.12: Principii de dezvoltare a priceperii in programare.
Dezvotarea priceperii in programare tine de: cresterea experientei prin repetitie;
posibilitatea de realizare rapida a unei sarcini, deoarece cercetarile in domeniul pregatirii
programatorilor arata ca daca un programator reuseste sa fie rapid, mai tarziu va deveni si de
calitate; dezvoltarea tehnologica ii forteaza pe programatori sa invete continuu.
Asadar, indiferent de sarcina instruirii, ritmul trebuie sa fie foarte alert; incepatorului
trebuie sa i se impuna sa construiasca in acelasi ritm cu programatorul experimentat; diferenta
intre acestia este ca incepatorul cu siguranta va face multe greseli.

Regula nr.13: La aprecierea productivitatii trebuie avute in vedere toate activitatile
pe care trebuie sa le faca un programator bun.
Aceste activitati sunt: sa navigheze pe Internet; sa contribuie cu informatii pentru altii; sa
citeasca documentatii; sa discute cu colegii; sa scrie specificatii si proiecte; sa scrie
documentatii; sa scrie cod; sa testeze; sa corecteze erorile; sa realizeze fisiere de raport pentru
erorile din codul altor programatori; sa participe la sedinte; sa ajute personalul de vanzari si
marketing; sa joace jocuri pentru a-si mentine in forma creierul.

Regula nr.14: Transformarea unui programator bun intr-un bun manager.
In general, inginerii software raspund cel mai bine managementului realizat de un coleg
programator o persoana pe care o respecta. Dar echipele de software nu-si prea pot permite
sa sacrifice programatori buni pentru posturi de conducere.
Asadar, trebuie minimizat numarul de manageri prin lucrul cu echipe mici, procese
usoare si auto-management; postul de manager trebuie sa fie un post part-time conduce un
proiect, la altul realizeaza codarea, sau conduce si codeaza in cadrul aceluiasi proiect daca se
poate.
Cel mai mare risc atunci cand un manager lucreaza ca programator este ca acesta va
neglija sa revizuiasca munca celorlalti. Pentru a preveni acest lucru, responsabilitatea
evaluarii echipei trebuie atribuita altcuiva, de exemplu unui asistent administrativ.

In concluzie, realizarea si conducerea unei organizatii de ingineri software de inalta
performanta este o mare provocare dar este o afacere extrem de profitabila. De exemplu
produsul Ariba a fost scris de doi programatori, producand pe piata un capital de 30 miliarde
de dolari.

9.3. Managementul performantelor programarii

Managementul performantelor se bazeaza pe studiul si cunoasterea mai multor factori
astfel: categoriile de computeristi si factorii de personalitate, sarcinile programarii si mediul
de lucru.
10

9.3.1. Categoriile de computeristi si factorii de personalitate
Categoriile de computeristi se pot departaja dupa valoare si experienta in:
Programatori profesionisti: programatori de sistem sau programatori de aplicatii.
Programatorii de sistem lucreaza la sisteme de operare, compilatoare, utilitare
folosite de programatorii de aplicatii care sunt cei ce rezolva probleme. Acestea
includ sisteme financiare, de plati, de rezervari, de managementul personalului, de
lucru cu conturi bancare, de colectare a datelor, de analiza statistica, de raport
managerial etc.
Programatori ocazionali depasesc numarul programatorilor profesionisti.
Raportul este de 10:1. Ei scriu pentru cercetare stiintifica, dezvoltare inginereasca,
cercetari de marketing, aplicatii de afaceri etc.
Programatori hobbysti lucreaza pe computere personale sau in firme mici.
Programatori de baze de date utilizeaza limbaje de genul EASYTRIEVE, SQL,
Query-by-example.
Alti programatori, cum ar fi: personalul pentru achizitie de date,
comanda/control, preluarea informatiilor din biblioteci, activitati de banca
computerizate, procesare de texte, case de marcat din supermarket etc.

Factorii de personalitate joaca un rol important in determinarea interactiunilor dintre
programatori si in stilul de munca a programatorilor individuali. Cativa factori sunt:
activ/pasiv adesea un individ activ care nu se teme sa puna intrebari, are
initiativa in realizarea unor lucruri este privit mai bine;
introvertit/extrovertit se prefera programatori buni care sa stie sa coopereze
pentru lucrul in echipa;
autocontrol/control extern persoanele cu autocontrol puternic pot domina
multe situatii, se simt in stare sa-i influenteze pe altii si sa controleze
evenimentele; persoanele cu control extern se simt victime ale evenimentelor si au
tendinta de a se lasa dominati;
nerabdare mare/mica un nivel moderat imbunatateste performanta, un nivel
ridicat conduce la cresterea numarului de erori care conduce la cresterea
nerabdarii, adica un cerc vicios;
motivatie ridicata/scazuta persoanele foarte motivate pot realizat mult mai
multe lucruri, de aceea, managerii incearca sa imbunatateasca moralul si motivatia
angajatilor;
toleranta mare/mica a ambiguitatilor stadiile initiale ale proiectarii
programului necesita toleranta la ambiguitati, trebuie luate decizii pe baza unor
date limitate, trebuie asumate riscuri;
precizie stadiile finale ale compunerii programului necesita o foarte mare atentie
la detalii;
orgoliu un programator de succes nu trebuie sa fie prea orgolios, o abordare mai
umila ii permite sa fie deschis spre sugestii;
rezistenta la stres proiectele pot sa depaseasca termenele si presiunea sa
creasca, insa un bun programator trebuie sa fie in stare sa lucreze bine si in
situatiile de stres.
Doktor (1976) defineste stilul cognitiv ca un mod de procesare a informatiilor in mod
analitic sau euristic:
analitic inseamna procesarea secventiala, liniara, simbolica verbala, orientata spre
partea stanga a creierului;
11

euristic inseamna procesarea intuitiva, globala, pictoriala, orientata spre partea
dreapta a creierului.
Multe studii facute au vizat personalitatea programatorului si multi considera ca aceasta
este mult mai importanta decat ceilalti factori.
Indicatorul de tip Myers-Briggs este un test psihologic care este utilizat cateodata
pentru realizarea echipelor de programatori. Acesta analizeaza patru dimensiuni:
extrovers/introvers, ratiune/intuitie, a gandi/a simti, judecata/perceptie.
Preferinta unui indivit pentru o anumita dimensiune nu este la fel de importanta ca
interactiunea intre preferinte. In continuare se prezinta testele pentru aceste patru dimeniuni.

Unde se afla lumea ta? (Expresiv sau rezervat?)
Introvertiti Extrovertiti
Le place linistea pentru a se concentra. Le place schimbarea si actiunea.
Tind sa fie foarte atenti la detalii, neagreand
lucrurile facute in graba.
Tind sa fie foarte rapizi, neagreand
procedurile complicate.
Nu reusesc sa-si aminteasca nume si figuri de
persoane.
Sunt foarte potriviti pentru intampinarea
persoanelor.
Nu ii deranjeaza sa lucreze la un proiect pe o
perioada lunga de timp fara intrerupere.
Sunt foarte nerabdatori cu lucrurile lungi si
lente.
Sunt interesati de idea din spatele slujbei lor. Sunt interesati de rezultatul slujbei lor, de
terminarea lucrului si de modul in care
lucreaza celelalte persoane.
Nu le plac intreruperile si nici sa fie deranjati
de telefon.
Nu ii deranjeaza intreruperile si nici sa
raspunda la telefon.
Le place sa se gandeasca mult inainte de a
face ceva, de multe ori ajungand sa nu mai
actioneze in nici un fel.
Le place sa actioneze in liniste, uneori chira
fara se gandeasca inainte.
Lucreaza singuri cu placere. Le place sa aiba oameni in jurul lor.
Au probleme privind comunicarea. Comunica bine, in general.

Gasirea raspunsului (Padure sau copaci?)
Intuitivi Rationali
Le place sa rezolve probleme noi. Nu le plac problemele noi decat daca exista
metode standard de rezolvare a lor.
Nu le place sa faca de mai multe ori acelasi
lucru.
Le place rutina bine stabilita.
Le place mai mult sa invete o deprindere
noua decat sa o utilizeze.
Le place mai mult sa utilizeze o deprindere
deja invatata decat sa invete altele noi.
Lucreaza in explozii de energie alimentate de
entuziasm, cu perioade de epuizare intre.
Lucreaza mai echilibrat, cu aprecierea realista
a duratei muncii.
Sar frecvent direct la conluzii. Parcurg toate etapele pana la a ajunge la o
concluzie.
Sunt rabdatori in situatii complicate. Sunt nerabdatori atunci cand detaliile se
complica.
Sunt nerabdatori in detaliile de rutina. Sunt rabdatori in detaliile de rutina.
Isi urmeaza inspiratia, fie ca e buna, fie ca nu. Rar au increde in inspiratie, si de obicei nici
nu au inspiratie.
Au tendinta de a face erori intamplatoare. Rar fac erori intamplatoare.
Nu le place sa piarda timpul pentru precizie. Sunt priceputi la lucrurile de precizie.
12

Realizarea analizei (Cap sau inima?)
Tip sentimental Tip rational
Tind sa fie foarte constienti de ceilalti si de
sentimentele lor.
Sunt relativ lipsiti de sentimente si
neinteresati de ale altora.
Le fac pe plac oamenilor, chiar si cand e
vorba de lucruri neinsemnate.
Pot jigni fara sa-si dea seama.
Le place armonia. Eficienta poate fi afectata
foarte mult de dusmaniile din birou.
Le place sa analizeze si sa puna lucrurile in
ordine logica. Pot trai fara armonie.
Adesea se lasa inluentati in decizii de
preferintele sau dorintele personale sau ale
altor persoane.
Au tendinata de a decide impersonal, uneori
ignorand dorintele altor persoane.
Au nevoie din cand in cand de laude. Au nevoie sa fie tratati corect.
Nu le place sa le spuna oamenilor lucruri
neplacute.
Sunt in stare sa-i certe pe altii si chiar sa-i
concedieze daca este necesar.
Se inteleg bine cu majoritatea persoanelor. Se inteleg bine doar cu alte persoane de tip
rational.
Are tendinta de a fi intelegator. Are tendinta de a avea inima de piatra.

Luarea deciziilor (Rigid sau flexibil?)
Perceptivi Cu judecata
Se adapteaza bine la situatiile schimbatoare. Cel bine este cand pot sa-si planifice munaca
si sa-si urmeze planul.
Nu ii deranjeaza sa lase lucrurile deschise sa
se altereze.
Le place sa lase lucrurile in ordine si
impachetate.
Nu prea reusesc sa ia decizii. Ar putea lua decizii prea in graba.
Pot incepe prea multe proiecte fara sa le
finalizeze.
Nu le place sa intrerupe proiectul la care
lucreaza pentru unul mai urgent.
Amana lucrurile neplacute. Nu observa lucrurile noi care trebuie facute.
Vor sa stie totul despre o slujba noua. Vor sa stie doar lucrurile esentiale despre o
slujba noua.
Au tendinta de a fi curiosi si intampina bine
un nou punct de vedere a unui lucru, situatie
sau persoana.
Au tendinta de a fi satisfacuti dupa ce si-au
facut o parere despre un lucru, situatie sau
persoana.

Combinatii comparate de perceptii si ratiuni
Persoanele care
prefera
intelegere &
gandire
intelegere &
sentimente
intuitie &
sentimente
intuitie &
gandire
se concentreaza
asupra
faptelor faptelor posibilitatilor posibilitatilor
si realizeaza
acesta prin
analiza
impersonala
caldura
personala
caldura
personala
analiza
impersonala
au tendinta de
a fi
practici &
dintr-o bucata
sociabili &
prietenosi
entuziasti &
patrunzatori
ingeniosi
intelectual
si sunt
priceputi la
productie
contructii
contabilitate
afaceri
economie
vanzari
servicii
relatii cu
clientii
munca de
cercetare
predare
pledare
consiliere
scris
cercetare
stiinta
inventii
siguranta
analiza
13

drept
chirurgie
binefacere
surori
medicale
psihologie
psihiatrie
management
cardiologie

9.3.2. Sarcinile programarii si mediul de lucru
Se refera la pregatirea scrierii programelor si la etapele parcurse de catre computeristi in
fazele programarii.
1. Invatarea limbajului. Aceasta este o sarcina pe termen lung deoarece noile
caracteristici (stil de programare, limbaje noi, utilitare, editoare etc) necesita o
invatare continua. Un mod de apreciere a experientei in programare ar fi:
a. Naiv nu este programator si nu are studii
b. Novice mai putin de un an experienta
c. Intermediar de la unu la trei ani experienta
d. Expert peste trei ani experienta.
2. Proiectarea programului necesita o cunoastere detaliata a problemei, experienta
in doemniul de aplicare si intelegere creativa. Este o sarcina greu de evaluat
deoarece depinde de aprecieri subiective ale valorii. Proiectul trebuie sa:
a. aprecieze necesitatile utilizatorului;
b. evalueze costurile;
c. realizeze un orar realist;
d. inteleaga ce pot realiza programatorii.
3. Compozitia presupune preluarea unei probleme sau unui proiect si codarea lui
pentru a putea si executat. Poate fi un proces individual, de echipa sau de mai
multe echipe. Este esential managementul si coordonarea proiectului. O clasificare
grosolana a dimensiunii programului este:
a. mic sub 100 de linii de instructiune;
b. mediu intre 100 si 1000 de linii de instructiune;
c. mare intre 1000 si 10000 de linii de instructiune;
d. foarte mare peste 10000 de linii de instructiune.
4. Intelegerea unui program este vitala. Se citesc programe vechi pentru a promova
comunicarea intre programatori, pentru a pregati o modificare sau pentru a
localiza o eroare. Exista cateva nivele de intelegere:
a. intelegerea fiecarei linii de instructiune;
b. intelegerea functiilor;
c. intelegerea structurii de comanda, modului de proiectare a modulului,
structurii de date.
Acest proces este diferit daca avem de-a face cu:
a. programe proprii sau ale altora;
b. programe scurte sau lungi;
c. novici sau profesionisti;
d. limbaje de nivel jos sau inalt;
e. programe documentate sau nu.
5. Testarea este verificarea ca programul sa satisfaca specificatiile de proiectare.
Poate include construirea de date de test sau doar verificarea specificatiilor. Ar
trebui facuta de fiecare programator, apoi de cineva care nu este implicat in
scrierea programului.
6. Depanarea sau indepartarea erorilor. Erorile pot fi:
a. sintactice utilizarea incorecta a sintaxei
b. semantice erori in proiectare.
14

Cea mai mare parte a erorilor sintactice sunt detectate de compilator. Erorile
semantice pot fi:
a. erori evidente la iesire
b. influenta neregulata, ascunsa asupra iesirii
c. erori de proiectare
d. erori de codare.
7. Documentarea este foarte importanta mai ales la programele care trebuie
modificate. Multe limbaje au posibilitatea realizarii auto-documentarii. Uneori se
folosesc persoane specializate in documentarea programelor. Acestia utilizeaza un
format standardizat, un nivel uniform de detaliere. Este o deprindere dificila care
necesita mult exercitiu. Documentatiile pot fi:
a. documentatii interne
b. documentatii externe
c. scheme logice de principiu
d. scheme logice detaliate
e. pseudocod
f. documentatii audio
8. Modificarea poate constitui pana la 75% din sarcina de programare. Necesita
intelegere si compozitie foarte buna. Trebuie intelese programe foarte mari in timp
scurt si facute modificari care sa nu afecteze restul programului.

Mediul de lucru al programatorului este un element cheie in privinta comportamentului
acestuia. Mediul inseamna:
dimensiunea camerei;
temperatura;
aranjamentul birourilor;
iluminarea;
zgomotul;
gradul de intimitate;
intreruperile etc.
Mediul include si factori de interactiune sociala, cum ar fi:
munca de unul singur sau in echipa;
prietenia etc;
structura manageriala;
recompense si bonus-uri;
posibilitatea de participare la cursuri/conferinte etc.

9.4. Managementul comunicarii interpersonal

9.4.1. Modelul comunicarii
Definitie
Comunicarea este procesul de transmitere a informatiilor de la o persoana la alta.
Atunci cand doua persoane discuta la telefon, cand un vorbitor se adreseaza unui grup
mare de ascultatori sau cand cineva citeste o scrisoare, are loc comunicarea.

Modelul comunicarii
Dupa cum rezulta si din definitia comunicarii, acesta implica cel putin doua persoane. In
fig.9.5., care reprezinta modelul comunicarii, sunt prezentate aceste doua persoane, ca
transmitator persoana care transmite mesajul si receptor persoana care primeste mesajul.
15


Fig.9.5. Modelul comunicarii

Punctul de pornire in realizarea comunicarii este o idee. Aceasta idee poate fi o
intamplare, o parere, o observatie sau orice altceva doreste transmitatorul sa trimita. Ideea este
apoi transformata intr-un mesaj. Acest proces de transformare inseamna ca transmitatorul
trebuie sa aleaga formularea care reflecta cel mai bine continutul ideei sale.
Apoi mesajul este transmis prin unul sau mai multe canale intalnire personala, o
scrisoare, un telefon, o expresie faciala sau orice combinatie intre acestea. Mesajul este
receptionat si retransformat intr-o idee.
Aici se manifesta diferenta dintre comunicarea simpla si comunicarea efectiva. Daca idea
formata de receptor este similara celei originale formulare de transmitator avem comunicare
efectiva. Daca ideile nu prea seamana, atunci comunicarea nu a fost efectiva.
Dupa cum se observa in figura, procesul poate continua prin comunicare bidirectionala.
Adica, receptorul poate raspunde la mesaj printr-un mesaj propriu. Astfel receptorul devine
transmitator, trimitand un nou mesaj transmitatorului original, care acum joaca rolul
receptorului.
Partea finala a procesului este zgomotul. Acesta poate fi orice zgomot care bruiaza
procesul de comunicare.

Ingineria software este o activitatea de colaborare. Ea inseamna comunicare intre
participanti din medii diferite, cum sunt expertii din domeniul aplicatiei, analisti, proiectanti,
programatori, manageri, persoane care scriu specificatiile tehnice, proiectanti de grafica etc.
Pentru a avea succes software-ul un element critic este comunicarea intre acestia.

9.4.2. Problemele comunicarii
Exista doua moduri de comunicare: comunicare programata sau in functie de evenimente.
Se spune ca avem comunicare programata daca aceasta este un eveniment planificat (de
exemplu, referintele clientului) si spunem ca avem comunicare in functie de evenimente daca
nu apare la momente exacte (de exemplu, raportarea erorilor).

Problemele comunicarii
Majoritatea proiectelor au de suferit de pe urma problemelor de comunicare. Problema
principala a programatorilor pare a fi ca nu le place sa comunice cu clientul sau cu grupul de
sponsori, de frica sa nu fie judecati gresit pe baza a ceea ce spun inainte de a livra produsul.
Problemele comunicarii planificate sunt:
neglijenta;
nu se stie cand trebuie realizate documentatiile;
prea multe informatii;
16

documentatiile consuma mult timp pentru a fi scrise, desi pe ele se pune cel mai
mult accentul in orice comunicare;
nepriceperea la scris sau vorbit;
cunostiinte slabe ale clientului privind modul de lucru cu documentatii tehnice;
lipsa controlului versiunii.
Problemele comunicarii neplanificate sunt:
raspunsuri pripite, inainte de a lua bine in considerare toate aspectele;
identificarea gresita a auditoriului, prea putine sau prea multe persoane;
nerespectarea protocolului sedintei.

9.4.3. Comunicarea in procesul elaborarii software
Definirea problemei
Scopul definirii problemei este ca mangerul proiectului si clientul sa cada de acord in
privinta obiectivului sistemului. Conduce la un document de definire a problemei care
sublineaza domeniul si functionalitatea sistemului. Acest document nu este o specificatie
completa a cerintelor ci doar o activitate preliminara de cerinte.

Recenziile clientului
Scopul este aprecierea de catre client a progresului realizat in dezvoltarea software-ului si
confirmarea sau modificarea cerintelor sistemului. Recenziile clientului sunt foarte utile
pentru gospodarirea asteptarilor de ambele parti si in cresterea gradului de intelegere intre
participanti. Aceste recenzii se concentreaza asupra a ceea ce sistemul face relevant pentru
client, in comparatie cu proiectul si implementarea sistemului. Se realizeaza sub forma de
prezentari formale in timpul carora programatorii prezinta clientului functionalitatile
specifice. Clientul asigura feedback-ul, sub forma clarificarilor, aprobarilor sau cerintelor de
modificare a functionarii sau a orarului.

Recenziile proiectului
Scopul este aprecierea de catre managerul proiectului a stadiului actual si revizuirea
interfetelor subsistemelor de catre membrii echipei. De exemplu, pentru proiectarea
sistemului, se revizuieste descompunerea in subsisteme si interfetele subsistemelor de nivel
inalt. Pentru integrare si testare, se revizuiesc testele si rezultatele lor. Se realizeaza sub forma
de prezentari formale in timpul carora fiecare echipa isi prezinta subsistemele managerului
sau celorlalte echipe care depind de aceste subsisteme. Programatorii au posibilitatea de a
negocia modificarile din interfete si a orarului.

Inspectii si prezentari (walkthroughs)
Inspectiile si prezentarile de cod au ca obiectiv principal cresterea calitatii unui subsistem.
In timpul prezentarilor, un programator isi prezinta codul (linie cu linie) celorlalti membrii ai
echipei sale. Este atacat orice cod dubios in incercarea de a descoperi cat mai multe erori
posibil. In timpul inspectiilor, membrii echipei se concentreaza pe conformarea codului cu o
lista predefinita de criterii (de exemplu, verificarea daca codul implementeaza un algoritm
specificat). Elementul central al acestor activitati ar trebui sa fie codul si nu programatorul sau
proiectantul. Inspectiile difera de recenziile proiectului prin formalitate, auditoriu limitat si
durata extinsa.

Recenziile starii actuale
Se concentreaza asupra sarcinilor, spre deosebire de recenziile clientului si ale proiectului,
care se concentreaza asupra sistemului. Recenziile stadiului sarcinilor sunt realizate de obicei
saptamanal (in cadrul echipei) sau lunar (la nivelul proiectului) si obiectivul lor este sa
17

detecteze deviatiile de la planul de sarcini si sa le corecteze. Acestea incurajeaza proiectantii
nu numai sa termine sarcinile incepute dar si sa discute alte aspecte si probleme neprevazute.

Brainstorming
Idea de baza a brainstorming-ului este ca solutiile propuse de un participant, chiar daca
sunt gresite, pot aduce dupa sine idei suplimentare de la ceilalti participanti. Sesiunile de
brainstorming sunt realizate de obicei prin sedinte fata-in-fata pentru a genera si evalua solutii
pentru o problema.

Lansari (livrari)
Scopul lansarilor este ca un document sau un subsistem sa fie disponibil celorlalti
participanti la proiect. Lansarile pot fi simple ca un e-mail de doua randuri sau pot fi
informatii mai lungi, cum este o noua versiune a unui program, o lista de modificari facute de
la ultima lansare a unui program, o lista de probleme sau rezultate care inca trebuie obtinute.
Recenziile clientului asupra proiectului sunt de obicei precedate de o lansare.

Recenzii postmortem
O data ce software-ul a fost terminat si livrat se extrag invataminte din dezvoltarea
sistemului prin recenzii postmortem. Asemenea recenzii pot fi realizate ca sesiuni de
brainstorming, chestionare structurate sau rapoarte individuale scrise de echipe. Este
momentul potrivit pentru a evalua cu ce tehnici, metode si unelte s-a lucrat si care au fost
critice pentru succesul (sau esecul) software-ului.

Cerere de clarificare
Asemenea cereri reprezinta cea mai mare cantitate de comunicatii intre proiectanti, clienti
si utilizatori. Acestea sunt comunicatii dependente de evenimente si pot apare in timpul
sedintele, prin apeluri telefonice, email sau orice alta forma de comunicare disponibila
proiectului. Desi sunt foarte utile, semnaleaza o infrastructura de comunicatii defectoasa, in
care apar intelegeri gresite, informatii lipsa sau plasate gresit.

Cerere de modificare
Un alt exemplu de comunicatie dependenta de evenimente, cererea de modificare apare
cand membrii echipei propun solutii ca urmare a unei probleme. Cererile de modificare contin
o clasificare (de exemplu defect sever, comentariu), o descriere a problemei, o descriere a
contextului in care apare si orice cantitate de material de documentare.

Deciderea rezultatelor
O data ce au fost raportate problemele si propuse solutiile, trebuie selectate, omunicate si
implementate solutii. Procesul acesta depinde de organizatie: o organizatie intinsa va seecta o
solutie printr-o sesiune de brainstorming, in timp ce o organizatie ierarhizata va folosi o
singura persoana care impune solutia. In orice caz, decizia trebuie sa fie documentata si
comunicata participantilor semnificativi. Comunicarea efectiva a deciziilor face ca
participantii sa ramana sincronizati pe dezvoltarea si rezultatele proiectului.

Mecanismele comunicarii pot fi sincrone sau asincrone. Mecanismele sincrone de
comunicare si modul aferent sunt prezentate in tabelul urmator:

Mecanism Modurile suportate
Conversatie pe coridor cereri de clarificare
cereri de modificare
18

Chestionare si interviuri
structurate
recenzii postmortem pentru achizitia de cunostiinte in
domeniul aplicatiei
Sedinte (fata-in-fata,
teleconferinte)
recenziile clientului
recenziile proiectului
inspectii
recenzia stadiului actual
recenzii postmortem
sesiuni de brainstorming
deciderea rezultatelor
Lucru in grup (groupware) in
acelasi timp, dar in locuri
diferite
recenziile clientului
recenziile proiectului
inspectii
sesiuni de brainstorming
deciderea rezultatelor

Mecanismele asincrone de comunicare si metodele aferente sunt prezentate in tabelul
urmator:
Mecanism Modurile suportate
email lansari
cereri de modificare
brainstorming
grupuri de stiri lansari
cereri de modificare
brainstorming
observatii lansari
cereri de modificare
brainstorming
pagini Web lansari
cereri de modificare
brainstorming
inspectii de cod asincron

9.4.4. Comunicarea in faza de proiectare
Comunicarea in faza de proiectare consta in:
Explicarea celor responsabili cu fazele proiectului a responsabilitatilor ce le survin.
Ramanerea in legatura cu cei responsabili.
Comunicari planificate.
Nu trebuie lasat nimic sa mearga de la sine.
Nu trebuie lasat altora sa duca la implinire un rezultat descoperit de o alta persoana.
Nu se fac presupuneri orice decizie care afecteaza si altceva in afara de propriul cod
se confirma si se comunica.
Se urmeaza protocolul cerintelor rezultatele se dezvolta in ordinea din nota de
comanda.
Se va profita de sansele ivite (de exemplu, conversatiile din pauza).
Se comunica mai intai verbal se documenteaza daca este necesar.


19

9.5. Managementul eticii profesionale

9.5.1. Formarea eticii
Definitie
Etica este multimea de standarde sau principii morale pe care o persoana si le formeaza in
privinta a ceea ce este bine sau rau, corect sau gresit.
Este foarte important sa se observe distinctia intre un lucru etic si un lucru legal. Legea
defineste diferite tipuri de actiuni ca acceptabile sau inacceptabile. Etica adesea merge dincolo
de lege si se bazeaza mai mult pe impunerea de norme sociale. Astfel o actiune poate fi si
etica si legala, poate fi legala dar nu etica, sau si ilegala si neetica.

Formarea eticii
In fig.9.6. se prezinta cei mai importanti factori care determina etica individuala.

Fig.9.6. Formarea eticii individuale

Influentele din familie
Influentele din familie joaca un rol cheie in determinarea convingerii individuale privind
ceea ce este si ceea ce nu este corect. De exemplu, o persoana care creste intr-un mediu in
care ambii parinti sunt extrem de etici, cu siguranta isi va dezvolta standarde etice mai inalte
decat o persoana care nu a fost invatata privind importanta unui asemenea comportament.

Influentele altor persoane
Aceste influente sunt si ele destul de importante. Colegii de clasa si celelalte persoane cu
mediul social al unei persoane ii pot modela etica. Presiunea altor persoane poate ajuta la
determinarea daca o persoana poate fi implicata in activitati dubioase, cum ar fi: furtul din
magazine, incercarea drogurilor, etc.

Experiente trecute
Pe masura ce o persoana evolueaza, experientele sale trecute pot juca si ele un rol in
determinarea evolutiei standardelor sale. Daca se comporta neetic intr-o anumita situatie si
sufera consecinte negative (sentimente de vina), comportamentul sau va fi probabil mai etic
data viitoare. Daca insa comportamentul sau neetic nu conduce la sentimente de vina, atunci
se va comporta la fel si data viitoare cand se confrunta cu o asemenea situatie.

Valori si principii morale
La un nivel mai general, valorile de baza si principiile morale influenteaza etica. O
persoana care este foarte religioasa va avea cu siguranta sentimente puternice privind ce este
bine si ce este rau. Asemenea credinte vor ajuta probabil si la modelarea eticii individuale.

20

Factori de situatie
Acestia sunt lucruri care apar intr-un mod aproape aleator si care pot duce la
comportament care poate fi sau nu conform cu etica persoanei respective. De exemplu, sa
consideram un angajat este onest si muncitor. Sotia lui isi pierde slujba si familia incepe sa
aiba probleme. Intr-o zi, cand lucrurile par mai rele, i se ofera posibilitatea de a castiga bani
suplimentari vanzand secrete ale companiei in care lucreaza uneia rivale. Situatia sa financiara
si disperarea vazandu-si familia suferind l-ar putea face sa accepte oferta neetica. Acesta este
un factor de situatie, deoarece daca sotia sa nu si-ar fi pierdut slujba sau daca lui nu i s-ar fi
oferit aceasta oportunitate de a vinde secrete ale companiei, ar fi putut ramane un angajat
dedicat, onest si loial.

9.5.2. Coduri de conduita etica
Definitie
Se numesc coduri de conduita afirmatiile simbolice pline de inteles privind importanta
aderarii la standarde etice inalte in domeniul afacerilor.
Un pas important in managementul eticii profesionale este stabilirea codurilor de
conduita, care de obicei arata importanta urmarii unor practici etice in afaceri in domeniul
tuturor activitatilor organizatiei. Aceste coduri sunt afirmatii simbolice dar pline de inteles in
legatura cu compania.
Tot mai adesea, companiile isi dezvolta propriile coduri de conduita etica. Un studiu
recent a descoperit ca 75% din cele mai mari 1200 de companii Americane au propriile lor
coduri etice.

Asociatiile profesionale au vazut in codurile etice un mecanism de stabilire a pozitiei lor
ca o profesie sau ca un mijloc de a regla calitatea de membru a lor si astfel sa convinga
populatia ca merita sa se autoadapteze. Autoadaptarea depinde de modurile de determinare a
comportamentului neetic al membrilor.
Asociatiile care au incercat sa implementeze un cod de etica au ajuns la concluzia ca
autoadaptarea depinde cel mai mult de consensul si angajamentul membrilor sai intr-un
comportament etic.
Functia sociala esentiala este de a clarifica si formula acele necesitati etice care sunt
importante pentru grup ca asociatie profesionala.
Un cod etic face profesia apreciabila de populatie. Aceasta aduce avantaje majore in
privinta increderii populatiei. Codul etic ajuta la convingerea publicului ca profesionistii
merita increderea si respectul sau.
Cea mai importanta functie a unui cod etic este rolul sau de ajutor in luarea deciziilor de
catre un individ.
Codul etic se refera la respectarea urmatoarelor valori:
1. proprietate intelectuala;
2. intimitate;
3. confidentialitate;
4. calitate profesionala;
5. corectitudine sau discriminare;
6. garantie;
7. riscurile software-ului;
8. conflicte de interese;
9. acces neautorizat la sistemele de computere.

Un conflict de interese exista atunci cand un angajat este pus intr-o situatie in care
deciziile sale pot fi compromise datorita unor loialitati concurente.
21

9.5.3. Studii de caz
In continuare se vor face studii de caz pentru fiecare situatie in parte.

Cazul 1: Proprietatea intelectuala
J ean, o programatoare de baze de date statistice, trebuie sa scrie un program statistic mare
de care compania are nevoie. Dupa ce a lucrat incontinuu cateva luni, a ajuns intr-un impas
privind cateva parti ale programului. Managerul, necunoscand complexitatea problemei, o
preseaza sa termine programul in cateva zile.
Negasind o solutie pentru problema sa, J ean isi aminteste ca un coleg de serviciu i-a dat
niste listing-uri dintr-un cod scris de acesta pentru un proiect si dintr-un pachet software
comercial realizat la o alta companie.
Studiind aceste programe, ea gaseste doua bucati de cod care ar putea fi incorporate direct
in programul ei.
Ea foloseste segmente de cod atat din software-ul colegului sau cat si din software-ul
comercial, fara sa spuna nimanui si fara sa mentioneze aceaste software-uri in documentatie.
Astfel isi termina proiectul si-l preda cu o zi inainte de termen.

Analiza cazului
Prin actiunile sale J ean a incalcat doua aspecte ale eticii profesionale, si anume:
neacordare de credit pentru munca altuia si utilizarea de cod dintr-un pachet comercial avand
copyright.
Chiar daca doar ar fi citit codul unui coleg pentru a gasi idei si apoi ar fi scris singura
programul sau, tot ar fi trebuit sa mentioneze in documentatie codul studiat.
In privinta codului dintr-un pachet comercial, ar fi trebuit sa verifice inainte daca
compania sa este sau nu autorizata sa utilizeze un asemenea cod.

Cazul 2: Intimitatea
Diane proiecteaza un sistem de management a bazelor de date pentru serviciul personal al
unei companii de dimensiuni medii. Diane a informat continuu clientul privind dezvoltarea
programului. S-a ajuns la momentul deciderii privind tipul si gradul de securitate a sistemului.
Diane a prezentat cateva optiuni clientului.
Deoarece sistemul costa mai mult decat s-a prevazut, clientul a decis utilizarea unui
sistem de securitate mai putin sigur. Diane, insa, crede ca informatiile stocate in sistem sunt
informatii private, de tipul evaluarilor performantelor, inregistrarilor medicale, salarii si altele.
Avand sistem de securitate slab, angajatii care lucreaza pe calculatoare sau chiar hacker-ii
ar putea sa gaseasca un mod de a accesa aceste date.

Analiza cazului
Conducerea companiei au obligatia de a proteja informatiile private ale angajatilor, deci
nu ar trebui sa accepte securitate slaba.
Pe de alta parte, Diane are ca obligatie avertizarea conducerii companiei privind nivelul
de securitate al sistemului si in functie de reactia acestora sa ia o decizie pe baza obligatiilor
contractuale si a obligatiilor de etica in privinta intimitatii si confidentialitatii.

Cazul 3: Confidentialitate
Max lucreaza la un mare departament de tratare a alcoolismului si dependentei de droguri.
Agentia administreaza programe pentru persoanele cu probleme de dependanta de alcool
si droguri si mentine o uriasa baza de date cu informatii despre clientii care au apelat la
serviciile lor. Unele dintre fisiere contin numele si adresele actuale ale clientilor.
22

Lui Max i s-a dat sarcina de a realiza un raport privind numarul de clienti din fiecare
program in fiecare luna din ultimii cinci ani, lungimea fiecarui tratament, numarul de clienti
care s-au intors dupa completarea unui program, cazierul clientilor etc.
Pentru a realiza acest raport lui Max i s-a dat acces la toate fisierele din computerul
agentiei. Dupa reasamblarea datelor intr-un nou fisier care include si numele clientilor, el l-a
descarcat pe calculatorul din biroul sau.
Pentru a putea termina raportul la timp, Max decide sa lucreze acasa in weekend, deci isi
copiaza informatia pe cateva dischete pe care le duce acasa. Dupa finalizarea raportului el lasa
dischetele acasa si uita de ele.

Analiza cazului
Acest scenariu seamana cu precedentul care avea de-a face cu informatii private. Oricum,
acest caz ridica o serie de probleme in plus.
Principala vinovata este agentia care trebuie sa protejeze identitatea clientilor sai. Rudele
sau prietenii lui Max ar putea sa descopere din greseala informatiile de pe dischete si sa le
foloseasca pentru a strica reputatia clientilor. Fisierele cu care a lucrat Max pentru raportul
sau nu ar fi trebuit sa contina numele clientilor sau alte informatii care i-ar fi putut identifica.
Agentia ar fi trebuit sa stearga informatiile personale din fisierele cu care a lucrat Max.

Cazul 4: Calitate profesionala
O companie de computere scrie software-ul pentru un sistem contabil mai eficient care va
fi utilizat de guvern. Acest sistem duce la micsorarea taxelor.
Acest software este realizat de o echipa, astfel: o persoana realizeaza dezvoltarea
rapoartelor, alta procesarea interna si o a treia interfata cu utilizatorul.
Managerul considera ca sistemul final realizeaza cerintele si acesta este instalat. Dar,
personalul considera interfata foarte dificila de utilizat si plangerile lor sunt auzite de
managementul superior. Din aceasta cauza, managementul superior nu mai investeste in acest
nou sistem contabil si se revine la sistemul original, dar mai scump.

Analiza cazului
In acest caz esecul se datoreaza lipsei de calitate a produsului. Cu siguranta ca cea mai
mare parte din problemele interfetei ar fi fost descoperite intr-un proces de revizuire, realizat
fie de catre persoane oarecare fie de catre utilizatori.
Esecul in implementarea unui proces de calitate constituie o violare a comportamentului
etic atunci cand acesta conduce la rezultate daunatoare, in acest caz pentru platitorii de taxe.

Cazul 5: Corectitudine sau discriminare
In cadrul cerintelor privind un sistem informatic ce va fi folosit de o agentie pentru
gestionarea locurilor de munca, clientul explica faptul ca doreste ca atunci cand se afiseaza
solicitantii a caror calificare se potriveste celei cerute de o anumita slujba numele barbatilor sa
apara inaintea femeilor.

Analiza cazului
In acest caz proiectantului sistemului i se cere sa construiasca un sistem care se pare ca va
folosit pentru a favoriza barbatii si va discrimina femeile.
Proiectantul sistemului trebuie sa puna in discutie natura problemei care i se cere sa o
realizeze si sa intrebe clientul care este motivul pentru care exista asemenea cerinte.
Daca clientul intr-adevar intentioneaza sa utilizeze sistemul pentru a favoriza barbatii,
atunci un programator profesionist ar trebui sa refuze sa realizeze acest sistem.

23

Cazul 6: Garantie
O companie de dezvoltare de software a produs un nou pachet software care contine noile
legi privind impozitele si realizeaza calculul acestora pentru persoane fizice si pentru firmele
mici. Presedintele companiei stie ca programul contine cateva erori. De asemenea stie ca
prima companie care va pune in circulatie un asemenea software va captura cea mai mare
parte din piata.
Compania face publicitate software-ului. La livrarea discului cu programul este inclusa si
o declaratie de neasumare a responsabilitatilor pentru erorile rezultate din utilizarea
programului.
Compania se asteapta sa primeasca plangeri si sugestii pentru modificari. Acestea vor fi
utilizate pentru a face modificarile necesare.
Datorita acestor erori un numar de utilizatori au completat incorect formularele de
declaratie de venit si au fost penalizati de FISC.

Analiza cazului
Presedintele companiei fiind constient de erorile existente in program si neinformandu-si
clientii privind aceste erori a violat codul etic.
In acest caz riscul utilizatorilor este mare, deoarece trebuie sa plateasca datorita erorilor
din program. Companiile pot sa faca declaratii de neasumare a responsabilitatilor doar daca
nu cunosc existenta vreunei erori si produsul este de calitate.
O alta greseala a managerului este ca isi incurajeaza personalul sa nu-si asume
responsabilitatile sociale.

Cazul 7: Riscurile software-ului
O companie software mica lucreaza la un sistem integrat de control a inventarului pentru
o intreprindere foarte mare de pantofi. Sistemul culege zilnic informatii privind vanzarile de
la magazinele din toata tara. Aceste informatii vor fi utilizate de departamentele de
contabilitate, transport si comanda pentru a controla functionarea corporatiei.
Functia de inventariere este crita pentru buna functionare a sistemului. J ane, inginera
respunsabila cu asigurarea calitatii a companiei de software, crede ca functiile de inventariere
ale sistemului nu au fost suficient testate, desi au trecut toate testele prevazute in contract.
Legal ea trebuie sa realizeze doar testele prevazute in contract, dar experienta sa in
testarea software-ului o face sa se ingrijoreze privind riscurile sistemului.
Pe de alta parte managerii o preseaza sa livreze produsul la timp.
J ane stie ca daca esueaza subsistemul de inventariere, va afecta semnificativ clinetul si
angajatii sai. Daca posibila esuare a software-ului ar ameninta vieti omenesti, J ane ar sti
precis ca trebuie sa refuze livrarea. Dar deoarece gradul de afectare este mai mic, J ane are de-
a face cu o decizie morala dificila.

Analiza cazului
Codul etic spune ca J ane nu trebuie sa livreze sistemul atata timp cat crede ca este de
calitate inferioara, si nu trebuie nici sa induca in eroare clientul in privinta calitatii produsului.
Ea ar trebui sa continue testele, dar i s-a spus sa livreze produsul, pentru ca altfel
compania sa ar putea da faliment. Cel putin ar trebui informat clientul despre rezerva lui J ane.

Cazul 8: Conflict de interese
Un consultant software negociaza un contract cu o cumunitate locala pentru proiectarea
sistemului de control a traficului. Acesta recomanda selectarea sistemului TCS. Consultantul
nu mentioneaza ca el este un actionar de baza la compania care produce software-ul TCS.

24

Analiza cazului
Conform codului eticii consultantul ar fi trebuit sa mentioneze daca exista circumstante
care ar putea conduce la conflicte de interese. Este responsabilitatea consultantului sa se
asigura ca toti clientii sunt bine informati in privinta optiunilor si ca recomandarile
profesionale nu sunt motivate de castiguri personale.

Cazul 9: Acces neautorizat la sistemele de computere
Un student lucreaza la proiectul de la cursul de Inginerie software. Asistentul a alocat
un timp limitat de lucru pe calculator pentru fiecare student la acest proiect. El a depasit
timpul si inca nu a reusit sa-si termine proiectul.
Anul trecut el a lucrat ca student programator la centrul de calculatoare din campus si este
familiarizat cu procedurile de marire a timpului alocat in conturi.
Utilizand cunostiintele de anul trecut, el ar putea sa-si acceseze contul si sa-si acorde timp
suplimentar ca sa termine proiectul.

Analiza cazului
Acest caz contravine codul eticii, care spune ca programatorii, chiar si studentii, pot
accesa doar resursele pentru care sunt autorizati. In plus, daca ar face asemenea modificari,
J oe nu ar respecta nici legile existente.

9.6. Estimarea efortului si costului producerii software

9.6.1. Metode de estimare a costului
Managerii proiectelor software sunt responsabili cu controlul bugetului proiectului, deci,
ei trebuie sa fie in stare sa faca estimari privind cat va costa dezvoltarea unui software.
Componentele principale ale costului proiectului sunt:
costuri hardware;
costuri de transport si instruire;
costuri de efort (costuri pentru plata inginerilor software).
Dintre acestea costurile dominante sunt cele de efort. Acestea sunt cel mai greu de estimat
si controlat si are cel mai mare efect asupra depasirilor de costuri.
Costul software-ului trebuie estimat in mod obiectiv pentru a oferi clientului o predictie
exacta privind dezvoltarea software-ului.
Estimarea costului software-ului este o activitatea continua care incepe de la stadiul de
propunere si continua pe intreg ciclul de viata al unui proiect. Proiectele au in mod normal un
buget, si este necesara o estimare continua a costului pentru a asigura ca toate cheltuielile sunt
realizate conform bugetului.
Efortul se poate masura in ore-personal sau luni-personal (cunoscute si ca ore-om sau
luni-om).
Boehm propune sapte tehnici de estimare a costului software, si anume:
Modelarea algoritmica a costului. Se realizeaza un model pe baza informatiilor
de cost de la proiecte precedente, informatii care realizeaza o legatura intre unele
masuri ale software-ului (de obicei dimensiunea sa) si costul sau. Se realizeaza o
estimare a masurii respective si modelul prezice efortul necesar. COCOMO este
un exemplu de model algoritmic.
Aprecierea expertului. Se utilizeaza unul sau mai multi esperti in tehnicile de
dezvoltare software, care sunt consultati privind domeniul aplicatiei. Fiecare
dintre acestia estimeaza costul proiectului si apoi se realizeaza acord intre ei
privind castul final.
25

Estimare prin analogie. Aceasta tehnica este aplicabila atunci cand s-au mai
realizat si alte proiecte din acelasi domeniu de aplicare. Costul unui nou proiect
este estimat prin analogie cu aceste proiecte finalizate.
Legea lui Parkinson. Legea lui Parkinson spune ca volumul de munca va creste
pana ce umple tot timpul disponibil. In termenii costului software-ului, aceasta
inseamna ca la determinarea costului se au in vedere resursele disponibile si nu
aprecierea obiectiva. Daca software-ul trebuie livrat in 12 luni si sunt disponibili 5
oameni, efortul necesar este estimat la 60 de persoane-luna.
Pretul de castigat. Costul software-ului este estimat la cat are clientul disponibil
sa cheltuiasca pentru proiect. Efortul estimat depinde de bugetul clientului si nu de
functionalitatea software-ului.
Estimare de sus in jos. O estimare a costului se realizata luand in considerare
functionalitatea globala a produsului si cum este realizata aceasta de catre
subfunctiile componente. Estimarile de cost sunt facute pe baza functiei logice si
nu pe baza componentelor care implementeaza acea functie.
Estimare de jos in sus. Se estimeaza costul fiecarei componente. Toate aceste
costuri sunt adunate pentru a produce o estimare a costului final.

Fiecare dintre aceste tehnici are avantaje si dezavantaje, prezentate in tabelul urmator.

Metoda Avantaje Dezavantaje
Modelarea
algoritmica
formula obiectiva, repetabila,
analizabila
eficienta, potrivita pentru analiza
fina
calibrata obiectiv pe experienta
intrari subiective
aprecierea circumstantelor
exceptionale
calibrarea cu trecutul, nu cu
viitorul
Aprecierea
expertului
apreciere reprezentarii,
interactiunilor, exceptiilor
depinde de participanti
partinitoare, incompleta
Estimare
prin
analogie
bazata pe experienta
reprezentativa
reprezentarea experientei
Legea lui
Parkinson
se coreleaza cu ceva experienta intareste experienta scazuta
Pretul de
castigat
adesea obtine contractul in general produce depasiri mari
Estimare
de sus in
jos
concentrata pe sistem
eficienta
baza mai putin detaliata
mai putin stabil
Estimare
de jos in
sus
baza mai detaliata
mai stabila
creste implicarea individuala
poate trece cu vederea costurile la
nivel de sistem
necesita mai mult efort

Pentru proiectele mari, trebuie utilizate in paralel mai multe tehnici de estimare a costului
si comparate rezultatele. Daca aceste tehnici estimeaza costuri foarte diferite, trebuie luate in
vedere mai multe informatii si repetat procesul de estimare a costului. Procesul ar trebui sa
continue pana cand estimarile sunt similare.
Modelele costului se bazeaza pe faptul ca a fost specificat un set de cerinte ale unei firme
si estimarea costului se face pe baza acestor cerinte. Oricum, cateodata se por modifica
cerintele astfel incat sa nu se depaseasca un cost fixat.
26

9.6.2. Estimarea costului prin metoda algoritmica
In acest caz costurile sunt analizate utilizand formule matematice care fac legatura intre
costuri si masurile software-ului.
Masura cea mai utilizata pentru estimarea costului este numarul de linii din codul sursa
(LOC=Lines Of source Code) al sistemului finalizat (care bineanteles ca nu se cunoaste).
Estimarea marimii poate implica estimare prin:
analogie cu alte proiecte;
estimare prin aranjarea dimensiunilor componentelor sistemului si utilizarea unei
componente de referinta cunoscute pentru estimarea dimensiunii componentei;
poate fi pur si simplu o chestiune a aprecierii ingineresti.
Estimarile dimensiunii codului sunt nesigure deoarece depind de optiunile hardware si
software, utilizeaza un sistem managerial de tip baza de data comerciala etc.
O alternativa la utilizarea dimensiunii codului ca atributul estimat al produsului este
utilizarea de puncte-functie, care se refera la functionalitatea si nu la dimensiunea software-
ului.
Punctele-functie se calculeaza prin numararea urmatoarelor caracteristici software:
intrarile si iesirile externe;
interactiunile cu utilizatorul;
interfetele externe;
fisierele utilizate de catre sistem.
Fiecare dintre acestea sunt apreciate individual privind complexitatea si li se atribuie o
valoare de apreciere care poate varia intre 3 (pentru intrari externe simple) si 15 (pentru fisiere
interne complexe).
Numararea punctelor-functie se face multiplicand fiecare numar de pe linie cu valoarea de
apreciere si insumand valorile obtinute, apoi se inmulteste cu factorii de complexitate a
proiectului, cum ar fi gradul de procesare deistribuita, cantitatea de reutilizare, performanta si
altele.
Numararea punctelor-functie poate fi folosita impreuna cu tehnicile de estimare a liniilor
de cod pentru a aprecia dimensiunea codului final.
Pe baza analizei datelor precedente, poate fi estimat numarul mediu de linii de cod
necesare intr-un limbaj particular pentru implementarea unui punct-functie, notat cu AVC.
Dimensiunea estimata a codului pentru o noua aplicatie este calculat dupa cum urmeaza:
Dimensiune cod = AVC x Numar de puncte-functie
Avantajul acestei metode este ca numarul de puncte-functie poate fi estimat adesea din
specificatiile cerintelor, astfel putandu-se face o estimare a dimensiunii codului inca dintr-o
faza incipienta.

9.6.3. Estimarea costului prin metoda COCOMO
Aceasta este metoda cea mai utilizata de estimare a efortului si costului.
COCOMO ia in considerare o mare varietate de factori.
Efortul dezvoltarii:
b
ensiune dim a E = ,
unde a si b sunt constante care se modifica in functie de estimarea necesara.
Proiectele se pot clasifica in trei categorii: organice, semidetasate si embedded, in functie
de dimensiunea lor. In tabelul urmator se prezinta caracteristicile fiecaruia.

Tip proiect Caracteristici
Dimensiune Inovatie Termen limita /
Constrangeri
Mediu de
dezvoltare
Organic Mic Mica Nu fix Stabil
27

Embedded Mare Mai mare Fix Hardware
complex/
interfete multe
Semidetasat Mediu Medie Medii Mediu

In modelul de baza care foloseste doar dimensiunea sursei constantele a si b iau
urmatoarele valori:

Organic Semidetasat Embedded
a 2.4 3.0 3.6
b 1.05 1.12 1.20

Formulele efortului in functie pentru cele trei tipuri de proiecte sunt:
Organic: ) ensiune (dim 4 . 2 E
05 . 1
=
Semidetasat: ) ensiune (dim 0 . 3 E
12 . 1
=
Embedded: ) ensiune (dim 6 . 3 E
20 . 1
=

De exemplu, daca un cod sursa are dimensiunea de 200 KLOC, atunci efortul este:
Organic: om luni 626 ) 200 ( 4 . 2 E
05 . 1
= =
Semidetasat: om luni 1133 ) 200 ( 0 . 3 E
12 . 1
= =
Embedded: om luni 2077 ) 200 ( 6 . 3 E
20 . 1
= =

Exista si un model intermediar care, pe langa dimensiune, utilizeaza alti 15 factori de
cost. Factorii de cost pentru modelul COCOMO sunt:
Fiabilitatea software
Dimensiunea bazei de date a aplicatiei
Complexitatea
Competenta analistului
Competenta ingineriei software
Experienta in aplicatii
Experienta in masini virtuale
Expertiza limbajului de programare
Cerintele de performanta
Constragerile de memorie
Volatilitatea masinii virtuale
Mediul de lucru
Timpul-mort
Utilizarea de unelte software
Aplicarea metodelor ingineriei software
Planificarea impusa a dezvoltarii
Valorile sunt asignate de catre manager.

Efortul dezvoltarii: C ensiune dim a E
b
= ,
unde C este produsul dintre ceilalti factori ai dezvoltarii.

Pentru modelul COCOMO constantele a si b au valorile:

28

Organic Semidetasat Embedded
a 3.2 3.0 2.8
b 1.05 1.12 1.20

Formulele efortului in functie pentru cele trei tipuri de proiecte sunt:
Organic: ) ensiune (dim 2 . 3 E
05 . 1
=
Semidetasat: ) ensiune (dim 0 . 3 E
12 . 1
=
Embedded: ) ensiune (dim 8 . 2 E
20 . 1
=

De exemplu, daca un cod sursa are dimensiunea de 200 KLOC si avem urmatorii factori:
0.88 Fiabilitate scazuta
1.15 Complexitate mare a produsului
1.13 Experienta mica in domeniul aplicatiei
0.95 Mare experienta in limbajul de programare

086 . 1 95 . 0 13 . 1 15 . 1 88 . 0 C = =

Atunci efortul este:
Organic: om luni 906 086 . 1 ) 200 ( 2 . 3 E
05 . 1
= =
Semidetasat: om luni 1231 086 . 1 ) 200 ( 0 . 3 E
12 . 1
= =
Embedded: om luni 1755 086 . 1 ) 200 ( 8 . 2 E
20 . 1
= =

Modelul intermediar este mai exact decat modelul de baza.