Florin Leon

Florin Leon
Managementul proiectelor
software
Suport de curs
2016
Cuprins
Capitolul 1. Introducere n managementul proiectelor
1.1. Introducere .................................................................................................. 11
1.2. Funciile managementului...................................................................... 13
1.2.1. Planificarea ...................................................................................... 13
1.2.2. Organizarea .................................................................................... .14
1.2.3. Selecia personalului .................................................................... 15
1.2.4. Conducerea ...................................................................................... 17
1.2.5. Controlul ........................................................................................... 17
1.3. Noiuni de baz ........................................................................................... 18
1.3.1. Definiii .............................................................................................. 18
1.3.2. Triunghiul managementului de proiect............................... .19
1.3.3. Ciclul de via al unui proiect ................................................... 22
1.4. Managerul de proiect ............................................................................... 25
1.4.1. Echilibrul atitudinilor .................................................................. 27
1.4.2. Presiunile i neatenia ................................................................ .30
1.4.3. Msurarea performanelor ........................................................ 32
1.4.4. Implicarea corect ....................................................................... .33
1.5. Concluzii ........................................................................................................ 35
Capitolul 2. Metodologii de dezvoltare a programelor
2.1. Introducere .................................................................................................. 37
2.2. Abordarea codeaz i repar ............................................................. 37
2.3. Metodologia secvenial .......................................................................... 37
2.3.1. Metodologia cascad .................................................................... 38
2.4. Metodologia ciclic (iterativ) .............................................................. 40
5
Florin Leon (2016). Managementul proiectelor software - Suport de curs
http://florinleon.byethost24.com
2.4.1. Metodologia spiral ...................................................................... 41

2.4.2. Metodologia Timeboxing........................................................... .42
2.5. Metodologia hibrid ecluz .................................................................... 43
2.6. Modelul V ...................................................................................................... 44
2.7. Metode formale........................................................................................... 45
2.8. Programarea extrem .............................................................................. 47
2.9. Metodologia Open Source ....................................................................... 49
2.10. Metodologia de dezvoltare Offshore (Outsourcing) .................. 50
2.11. Concluzii ..................................................................................................... 51
Capitolul 3. Justificarea financiar a proiectului
3.1. Introducere .................................................................................................. 53
3.2. Diagrama pragului de rentabilitate .................................................... 53
3.3. Rata medie de recuperare a investiiei.............................................. 55
3.4. Valoarea actual net ............................................................................... 56
3.5. Rata intern de recuperare a investiiei ........................................... 58
3.6. Concluzii ........................................................................................................ 59
Capitolul 4. Managementul domeniului
4.1. Introducere .................................................................................................. 63
4.2. Definirea domeniului................................................................................ 63
4.3. Crearea structurii de descompunere a activitilor ..................... 66
4.4. Verificarea domeniului ............................................................................ 68
4.5. Controlul domeniului ............................................................................... 69
4.6. Concluzii ........................................................................................................ 70
Capitolul 5. Managementul timpului
5.1. Introducere .................................................................................................. 71
5.2. Definirea activitilor ............................................................................... 71
5.3. Ordonarea activitilor ............................................................................ 72
6
5.3.1. Metoda diagramei de preceden ........................................... 72

5.4. Estimarea duratei activitilor i proiectului .................................. 76
5.4.1. Metoda drumului critic ............................................................... 76
5.4.2. Metoda PERT................................................................................... 76
5.4.3. Simularea Monte Carlo ................................................................ 79
5.5. Considerente practice ale planificrii ................................................ 80
5.5.1. Scopurile planificrii .................................................................... 80
5.5.2. Calitatea estimrilor ..................................................................... 81
5.5.3. Omisiunile frecvente .................................................................... 82
5.5.4. Recomandri ................................................................................... 83
5.6. Considerente practice ale planificrii ................................................ 84
Capitolul 6. Managementul costului
6.1. Introducere .................................................................................................. 85
6.2. Metode de estimare................................................................................... 86
6.3. Modele algoritmice clasice ..................................................................... 92
6.4. Modele algoritmice moderne ................................................................ 95
6.4.1. Modelul Walston-Felix ................................................................ 97
6.4.2. Modelul COCOMO .......................................................................... 99
6.4.3. Analiza punctelor funcionale ............................................... 101
6.5. Distribuirea forei de munc n timp............................................... 103
6.6. Concluzii ..................................................................................................... 108
Capitolul 7. Managementul calitii
7.1. Introducere ............................................................................................... 109
7.2. Procesele principale ale managementului calitii .................... 110
7.3. Standardele ISO 9000 ............................................................................ 110
7.4. Modelul CMMI .......................................................................................... 115
7.5. Biblioteca ITIL .......................................................................................... 119
7.6. Concluzii ..................................................................................................... 120
7
Capitolul 8. Managementul resurselor umane

8.1. Introducere ............................................................................................... 121
8.2. Factori de management al echipei ................................................... 122
8.3. Motivarea ................................................................................................... 122
8.3.1. Proceduri i motivare ............................................................... 123
8.3.2. Teoria ateptrii ......................................................................... 124
8.3.3. Teoria ierarhiei nevoilor umane a lui Maslow ................ 125
8.3.4. Teoria celor doi factori a lui Herzberg ............................... 128
8.3.5. Tipuri de personalitate ............................................................ 128
8.4. Organizarea echipelor ........................................................................... 129
8.4.1. Organizarea ierarhic ............................................................... 129
8.4.2. Organizarea matrice .................................................................. 130
8.5. Principii generale de organizare a unei echipe ........................... 131
Capitolul 9. Conducerea echipei
9.1. ncrederea.................................................................................................. 133
9.1.1. Delegarea autoritii ................................................................. 134
9.1.2. Modelele comportamentale ................................................... 134
9.2. Politica i puterea ................................................................................... 134
9.2.1. Surse de putere ........................................................................... 135
9.2.2. Tipuri de putere .......................................................................... 136
9.3. Procesul de feedback ............................................................................. 137
9.3.1. Greelile subordonailor .......................................................... 138
9.4. Calitile necesare managerului de proiect .................................. 139
9.4.1. Energia ........................................................................................... 139
9.4.2. Perseverena ................................................................................ 139
9.4.3. Stabilirea i respectarea prioritilor ................................. 140
9.5. Mecanisme de coordonare .................................................................. 140
9.6. Stiluri de management .......................................................................... 141
8
Capitolul 10. Managementul comunicrii

10.1. Introducere ............................................................................................. 145
10.2. Procesele principale ale managementului comunicrii ........ 147
10.3. Transmiterea informaiilor .............................................................. 147
10.4. Bariere de comunicare ....................................................................... 149
10.5. mbuntirea comunicrii ............................................................... 150
10.5.1. mbuntirea procesului de ascultare ........................... 150
10.6. Comunicarea scris ............................................................................. 151
10.6.1. Redactarea email-urilor ........................................................ 151
10.7. Comunicarea verbal .......................................................................... 153
10.7.1. Organizarea edinelor .......................................................... 153
Capitolul 11. Managementul riscului
11.1. Introducere ............................................................................................. 157
11.2. Analiza SWOT ........................................................................................ 159
11.3. Identificarea riscurilor ....................................................................... 162
11.4. Analiza riscurilor .................................................................................. 164
11.5. Planificarea gestionrii riscurilor .................................................. 166
11.6. Monitorizarea riscurilor .................................................................... 167
Capitolul 12. Analiza deciziilor
12.1. Introducere ............................................................................................. 169
12.2. Decizii n condiii de certitudine .................................................... 170
12.2.1. Analiza Pareto ........................................................................... 170
12.2.2. Analiza comparrii perechilor ............................................ 172
12.2.3. Analiza matricei de decizii ................................................... 174
12.2.4. Analiza costuri-beneficii ....................................................... 177
12.3. Decizii n condiii de incertitudine ................................................ 180
12.3.1. Criteriul Laplace ....................................................................... 180
12.3.2. Criteriul maximax .................................................................... 181
9
12.3.3. Criteriul maximin .................................................................... 181

12.3.4. Criteriul Hurwicz ..................................................................... 182
12.3.5. Criteriul Savage (al regretelor) .......................................... 183
12.4. Decizii n condiii de risc ................................................................... 184
12.4.1. Arbori de decizie ...................................................................... 184
Referine .................................................................................................................... 191
10
Capitolul 1
Introducere n managementul proiectelor

1.1. Introducere
Managementul proiectelor devine rapid metoda de management
utilizat de un numr din ce n ce mai mare de industrii. Sunt realizate
proiecte pentru construirea celor mai mari zgrie nori sau pentru realizarea
unor programe informatice foarte simple. Cei mai muli manageri de proiect
consider c tehnicile de management pot fi aplicate proiectelor indiferent
de dimensiune i c metodologia, metodele i paii utilizai pentru
management sunt aproape aceleai. Multe companii mari au n prezent o
politic declarat de administrare folosind metode de management al
proiectelor.
Conform Ghidului PMBOK (Project Management Body of
Knowledge, Corpul de cunotine al Managementului de Proiect), un
proiect este un efort temporar ntreprins pentru a crea un produs sau
serviciu unic.
Cuvntul temporar nseamn c orice proiect are un nceput i un
sfrit. n general un proiect ncepe cnd un anumit tip de document oficial
declar c proiectul ia fiin. Acest document de obicei creeaz unele
mijloace de realizare a cheltuielilor i costurilor proiectului. Sfritul
proiectului are loc de obicei atunci cnd toate obiectivele proiectului au fost
realizate. Unele proiecte se termin atunci cnd din diferite motive se decide
abandonarea proiectului pentru c scopurile sale nu pot fi realizate practic.
Cuvntul unic nseamn c bunurile sau serviciile create de proiect
sunt ntr-o oarecare msur diferite fa de orice a fost produs nainte. Acest
lucru nu nseamn c proiectul este complet unic, ci c unele pri sunt
suficient de diferite pentru a necesita un proces de planificare pentru
organizarea efortului care trebuie fcut.

Managementul proiectelor software
Dac nu ar exista aceste pri diferite am vorbi de o repetiie de

rutin care nu ar avea nevoie de instrumentele i tehnicile de management
de proiect.
Odat ce obiectivele au fost ndeplinite, resursele reunite n acest
scop pot fi atribuite altor proiecte. Aceasta nseamn c echipa unui proiect
poate fi creat special pentru scopul acestuia.
Unul dintre principalele avantaje ale managementului de proiect este
capacitatea de a forma echipe multidisciplinare care conin oameni potrivii
la momentul potrivit. Prin urmare, pot fi aduse n proiect resurse deosebite
atunci cnd sunt necesare.
Persoana (sau organizaia) care are un interes privind rezultatele unui
proiect se numete parte interesat (engl. stakeholder). Proiectele vor
avea ntotdeauna mai mult de o parte interesat, fiecare cu nevoi i ateptri
diferite. Clientul sau sponsorul este principala parte interesat n proiect.
Fr acesta, proiectul probabil c nu s-ar realiza. Sponsorul asigur banii
necesari pentru proiect i are cel mai mare interes n succesul acestuia.
Managementul proiectelor reprezint aplicarea unor cunotine,
aptitudini i tehnici pentru activitile proiectului cu scopul de a satisface
sau depi nevoile i ateptrile prilor interesate. Deci, managementul de
proiect utilizeaz o serie de instrumente i tehnici pentru a gestiona proiecte.
Managerul de proiect este persoana responsabil n final pentru
succesul sau eecul proiectului.
Se poate face o distincie ntre termenii de proiect i program.
Conform Ghidului PMBOK, un program reprezint un grup de proiecte
administrate ntr-un mod coordonat pentru a obine beneficii care nu s-ar
putea obine dac proiectele ar fi administrate separat.
Este important de realizat faptul c terminarea unui proiect nu
nseamn i terminarea bunurilor sau serviciilor pe care le produce proiectul.
De exemplu un proiect pentru construirea unei centrale nucleare se termin
cnd a fost ndeplinit scopul de construire a centralei i de punere n
funciune. Centrala continu s funcioneze i dup ce proiectul a fost
finalizat.
12
1.2. Funciile managementului

Managementul reprezint ndeplinirea unor obiective prin
intermediul oamenilor i al altor tipuri de resurse. Acesta se refer la
procesul de stabilire i atingere a scopurilor prin cinci funcii de baz:
planificare, organizare, selecie de personal, conducere i control, folosind
resurse umane, financiare i materiale.
1.2.1. Planificarea
Privete anticiparea situaiilor viitoare i determinarea celei mai
potrivite modaliti de aciune pentru ndeplinirea obiectivelor
organizaionale. Deseori considerat prima funcie a managementului,
planificarea pune bazele tuturor celorlalte funcii. Planificarea e un proces
continuu care implic stabilirea aciunilor necesare pentru a rspunde la
ntrebri precum: ce trebuie fcut, cnd i cum. De asemenea, n aceast
faz managerul trebuie s ia n calcul i factorii care pot ajuta sau mpiedica
atingerea scopului, precum i posibilele alternative disponibile pentru
atingerea sa.
Prin planificare se instituie o serie de aciuni care angajeaz
indivizii, departamentele i ntreaga organizaie timp de zile, luni sau chiar
ani. De aceea, planificarea trebuie fcut cu atenie, lundu-se n calcul
urmtoarele aspecte:
1. Determinarea resurselor necesare;
2. Identificarea numrului de oameni i a tipurilor de calificare
(personal tehnic, de supervizare sau managerial);
3. Dezvoltarea mediului organizaional n care se va lucra (ierarhia
organizaional);
4. Determinarea standardelor necesare pentru evaluarea evoluiei
proiectului, astfel nct s se poat face corecii atunci cnd acest
lucru se impune.
n funcie de amploare sau sfera de aciune, se pot evidenia trei
categorii de planificare:
13
1. Planificarea strategic: Determin obiectivele majore ale

organizaiei. Este iniiat i ghidat de un management de nivel nalt,
ns toate nivelurile de management trebuie s participe pentru ca
planificarea strategic s dea rezultate. Acest tip de planificare
ndeplinete scopuri precum:
Stabilirea unor direcii i angajamente pe termen lung pentru
ntreaga organizaie;
Implicarea mai multor niveluri de management n procesul
de planificare;
Dezvoltarea unui model organizaional n care planurile
subunitilor s fie armonizate i consistente;
2. Planificarea tactic: Privete mai ales implementarea planurilor
strategice printr-un management de nivel mediu. Tactica este
mijlocul de ndeplinire a strategiei. Planurile se refer la
responsabilitile unitilor i n general se concentreaz pe
activitile curente i pe termen scurt;
3. Planificarea
operaional:
Se
refer
la
ndeplinirea
responsabilitilor la nivel de post sau compartiment. Planurile pot fi
singulare (pentru activiti care nu se repet, de exemplu realizarea
unui buget) sau continue (care includ anumite proceduri sau politici).
1.2.2. Organizarea
Organizarea este funcia managementului care mbin resursele
umane i materiale prin proiectarea unei structuri formale a sarcinilor i
autoritii. Organizarea stabilete deci relaiile dintre activitate i autoritate.
n acest context, managerul trebuie s ndeplineasc patru scopuri
principale:
1. S determine ce activiti de lucru trebuie fcute pentru atingerea
obiectivelor organizaionale;
2. S clasifice tipurile de activiti i grupurile de lucru n uniti uor
gestionabile;
3. S atribuie indivizilor sarcini de lucru i s-i delege autoritatea ntrun mod adecvat;
14
4. S proiecteze o ierarhie a relaiilor pentru luarea deciziilor.

Procesul de organizare poate fi vzut ca format din cinci pai:
1. Studierea planurilor i scopurilor: Planurile dicteaz scopurile i
activitile curente sau viitoare. n unele situaii, ar trebui create noi
uniti, alteori, unor uniti existente li se confer noi atribuii, iar
unele uniti pot fi desfiinate. Pot aprea noi relaii ntre prile
interesate. Organizarea creeaz o nou structur, noi relaii i le
modific pe cele existente;
2. Identificarea activitilor necesare pentru atingerea obiectivelor:
Trebuie creat o list de sarcini ncepnd cu cele continue i
terminnd cu cele singulare;
3. Clasificarea i gruparea activitilor: Managerii trebuie s efectueze
trei proceduri:
S examineze fiecare activitate pentru a-i determina natura
general (marketing, producie etc.);
S grupeze activitile n ariile corespunztoare;
S stabileasc departamentele adecvate n cadrul structurii
organizaiei;
4. Atribuirea sarcinilor i delegarea autoritii: Un pas critic n care se
stabilesc departamentele, natura, scopul i sarcinile fiecrui
departament, mpreun cu performanele ateptate;
5. Proiectarea unei ierarhii de relaii: Se hotrsc relaiile de lucru
verticale i orizontale. Structurarea vertical rezult ntr-o ierarhie de
luare a deciziilor n care se tie cine rspunde pentru fiecare sarcin.
Structurarea orizontal definete relaiile de lucru ntre departamente
i stabilete numrul de subordonai ai fiecrui manager.
1.2.3. Selecia personalului
Aceast funcie
desemnarea persoanei
organizaiei. n general,
resurs de care dispune
privete recrutarea, selecionarea, instruirea i

potrivite pentru poziia potrivit n cadrul
se consider c oamenii sunt cea mai important
organizaia. Prin selecia personalului, se dorete
15

identificarea, atragerea i pstrarea personalului calificat pentru a ocupa

poziiile disponibile.
Selecia personalului poate fi vzut ca un proces n opt pai:
1. Planificarea resurselor umane: Trebuie s asigure faptul c nevoile
de personal ale organizaiei vor fi satisfcute. De obicei, se
analizeaz planurile organizaiei pentru a vedea ce competene
anume vor fi necesare n viitor. Dup realizarea previziunilor, se
stabilete numrul de persoane care trebuie recrutate (din afara
organizaiei) sau instruite (din interior);
2. Recrutarea: Se identific i se atrag candidai care ndeplinesc
cerinele pentru posturile vacante prevzute. Ca rezultat al analizei
posturilor, se ntocmesc descrierile i specificaiile acestora.
Recrutarea efectiv se realizeaz prin site-uri Internet specializate,
ageni de ocupare a forei de munc, legturi cu universitile,
anunuri publice n ziare etc.;
3. Selecionarea: Dup recrutare, candidaii interesai trebuie evaluai
i selecionai cei ale cror competene se potrivesc cu cerinele
posturilor. Etapele urmrite n evaluare pot fi: completarea unor
formulare, examinarea profesional, verificarea recomandrilor i
interviul;
4. Instalarea i orientarea: Odat selecionai, noii angajai trebuie
integrai n organizaie; trebuie s li se prezinte grupul de lucru,
precum i regulamentul intern sau normele organizaiei;
5. Instruirea i dezvoltarea: Se ncearc mbuntirea capacitii
angajailor de a contribui la funcionarea eficient a organizaiei.
Instruirea se concentreaz asupra calificrii angajailor. Dezvoltarea
implic pregtirea lor pentru responsabiliti suplimentare sau
avansare;
6. Evaluarea performanelor: Un sistem proiectat s msoare
performanele efective ale angajailor n comparaie cu standardele
de performan prestabilite;
7. Deciziile de recompensare: Pe baza evalurii performanelor, se pot
lua decizii privind recompensele financiare, transferrile,
promovrile sau retrogradrile;
16
8. ncetarea relaiilor de munc: Managementul trebuie s fie

preocupat i de demisii, pensionri sau concedieri.
1.2.4. Conducerea
Dup crearea planurilor, structurii organizaiei i completarea
personalului, urmtorul pas al procesului managerial este conducerea, adic
dirijarea i motivarea angajailor ctre obiectivele organizaionale. Din acest
motiv, conducerea este important mai ales la primul nivel de supervizare,
deoarece la acest nivel este concentrat majoritatea angajailor organizaiei.
Caracteristicile cele mai importante ale funciei de conducere se
refer la stilul de conducere (autocratic, democratic) i la procesul de luare a
deciziilor. Acestea sunt n strns legtur cu o serie de factori precum
urgena situaiei sau motivarea subordonailor. De asemenea, managerul ca
lider trebuie s cunoasc toate aspectele situaiei curente, s estimeze
impactul pe care l vor avea deciziile sale i s ia totdeauna n calcul
elementul uman. El trebuie s atribuie sarcinile iniiale tuturor angajailor, s
dea ordine clare i concise i s urmreasc modul cum sunt ndeplinite
sarcinile, dnd dac este nevoie ndrumri verbale sau scrise.
1.2.5. Controlul
Ultima funcie a managementului se refer la evaluarea
performanelor organizaiei pentru a determina dac i ndeplinete sau nu
obiectivele. n aceast faz trebuie luate urmtoarele msuri:
1. Stabilirea standardelor de performan utilizate pentru a msura
progresul ctre scop. Standardul reprezint un mecanism de msur
cantitativ sau calitativ, destinat monitorizrii performanelor
oamenilor sau proceselor. n general putem vorbi de:
Standarde manageriale: includ rapoarte, regulamente i
evaluri de performan. De exemplu, un raport lunar din
partea tuturor persoanelor implicate n vnzri, centrat pe
ariile cheie de interes pentru managerul de vnzri;
Standarde tehnice: se refer la metodele i procesele de
17
producie, la materiale, echipamente, componente i

furnizori. Standardele tehnice pot veni din surse interne sau
externe. De exemplu, standarde de calitate dictate de
reglementri
guvernamentale
sau
specificaiile
productorului pentru echipamente;
2. Monitorizarea i evaluarea performanelor: sunt msurate
performanele i se determin dac respect standardele stabilite.
Dac o asemenea comparaie indic faptul c rezultatele sunt
acceptabile, nu este necesar nicio aciune. n caz contrar, se trece la
urmtorul pas:
3. Corectarea deviaiilor de la standarde: msurile de corecie
necesare se vor lua pe baza a trei factori standardul, precizia
msurtorii care a indicat deviaia i diagnosticul persoanelor care au
investigat cauzele deviaiei. Standardele pot fi prea slabe sau prea
stricte. Msurtorile pot fi imprecise deoarece instrumentele de
msur pot fi utilizate defectuos sau prezint ele nsele defecte.
Oamenii pot lua decizii greite la hotrrea aciunilor corective
necesare.
1.3. Noiuni de baz

1.3.1. Definiii
n cele ce urmeaz, vom preciza cteva definiii eseniale pentru
managementul de proiect:
Plan: Graficul datelor de ncepere i terminare ale activitilor

mpreun cu informaii despre resurse i costuri. Un plan de baz
este planul iniial, care se salveaz i se folosete pentru a monitoriza
progresul. Un plan interimar este un set de date salvate n timpul
derulrii proiectului, folosite pentru a le compara cu alte planuri
interimare.
Buget: Costul estimat al proiectului care se stabilete n planul de
baz (engl. baseline).
18
Cost: Costul total planificat pentru o activitate, resurs, sarcin

trasat sau pentru ntregul proiect. Uneori este denumit cost
curent.
Resurse: Oamenii, echipamentele i materialele folosite pentru a
finaliza activitile din proiect.
Tarif de plat: Costul resurselor pe or. Exist dou tipuri de tarife
de plat: standard i pentru ore suplimentare.
Supra-alocare: Rezultatul atribuirii mai multor activiti dect poate
realiza o resurs n timpul de lucru disponibil.
Activitate divizat: O activitate al crei grafic de lucru este ntrerupt.
De exemplu, o activitate de dou zile, care nu necesit execuia prin
lucru continuu, poate fi mprit astfel nct prima zi de lucru s fie
programat luni iar cea de-a doua zi joi.
Nivelare: Rezolvarea conflictelor de resurse sau a supra-alocrilor
prin ntrzierea sau divizarea unor activiti. Cnd o resurs este
nivelat, sarcinile sale sunt distribuite i reprogramate.
Dat de ncheiere: Data la care o activitate este programat pentru a
fi finalizat. Aceast dat depinde de data de ncepere a activitii,
durata acesteia, calendarele dup care se lucreaz, datele unor sarcini
precedente, dependenele fa de alte activiti i alte constrngeri.
ntrziere: Timpul dintre data planificat de ncepere a unei activiti
i momentul n care ncepe efectiv lucrul la aceasta. ntrzierile sunt
deseori folosite pentru a rezolva supra-alocrile de resurse.
Livrabil: Un rezultat concret i msurabil, produsul sau un element
care trebuie produs pentru a finaliza proiectul sau o parte a
proiectului. n mod normal, echipa proiectului i prile interesate
decid de comun acord livrabilele nainte de nceperea proiectului.
1.3.2. Triunghiul managementului de proiect
Managementul proiectelor este adesea rezumat ntr-un triunghi

(figura 1.1). Principalii trei factori sunt timpul, costul i domeniul de
aplicare, numii i tripla constrngere. Acestea formeaz vrfurile
triunghiului avnd calitatea ca tem central:
19
1.
2.
3.
4.
Proiectele trebuie s fie livrate la timp.

Proiectele trebuie s se ncadreze n costuri.
Proiectele trebuie s se ncadreze n domeniul de aplicare.
Proiectele trebuie s ndeplineasc cerinele de calitate ale clienilor.
Figura 1.1. Triunghiul managementului de proiect
Dac timpul sau banii ar fi nelimitai, sau cerinele ar fi nule, nu ar

mai fi nevoie de management de proiect. Din pcate, cele mai multe proiecte
au o anumit limit de timp, de buget i domeniu de aplicare. nelegerea
triunghiului proiectului permite luarea de decizii mai bune atunci cnd
trebuie fcute compromisuri. Dac se ajusteaz o latur a triunghiului,
celelalte dou laturi sunt afectate. De exemplu:
Dac se decide scderea timpului alocat pentru finalizarea

proiectului, poate rezulta o cretere a costurilor, precum i o
restrngere a domeniului de aplicare;
Dac se decide scderea bugetului proiectului, poate rezulta un
grafic de lucru mai lung i o scdere a domeniului de aplicare;
Dac se decide extinderea domeniul de aplicare, proiectul poate s
dureze mai mult timp i s coste mai muli bani, de exemplu sub
form de resurse umane.
Modificrile din planul proiectului pot afecta triunghiul n diverse

moduri, n funcie de circumstanele specifice i de natura proiectului. De
exemplu, de cele mai multe ori, scurtarea timpului de execuie al proiectului
poate crete costurile. n alte cazuri, acestea se pot chiar diminua.
20
Din punct de vedere al triunghiului proiectului, resursele sunt

considerate un element de cost. Deci, n funcie de cum ajustm resursele
pentru mai mult sau mai puin efort de lucru sau pentru a reflecta
disponibilitatea acestora, costurile vor urca sau vor cobor n mod
corespunztor. Aceste costuri sunt bazate pe tarifele de plat ale resurselor.
De asemenea, se poate observa c pe msur ce se ajusteaz resursele, apar
modificri n graficul de lucru. De exemplu, dac avem un numr de resurse
supra-alocate i se niveleaz proiectul, graficul de lucru poate conine acum
sarcini divizate i ntrzieri, care extind data limit a terminrii proiectului.
n cele mai multe proiecte, cel puin o latur a triunghiului este fix.
Pentru unele proiecte, este latura bugetului: sub nicio form nu se vor primi
mai muli bani pentru proiect. La altele, este latura timpului: datele nu se pot
schimba. Sau este domeniul de aplicare: nu va fi permis nicio schimbare n
livrabile. Ideea este de a gsi prile blocate sau fixe ale triunghiului
proiectului. Aceste pri ne spun ce se poate schimba sau ajusta dac exist
o problem. Enunarea problemei ne poate ajuta s clarificm ce parte a
triunghiului are dificulti.
Cunoscnd care parte a triunghiului nu poate fi schimbat ne poate
ajuta s aflm ce trebuie ajustat. Aa c, atunci cnd se ncepe optimizarea,
n primul rnd, se decide care dintre cele trei elemente este fix. Acesta este
de obicei elementul cel mai important pentru succesul proiectului
(terminarea la timp, nedepirea bugetului sau respectarea domeniului de
aplicare convenit). Apoi, se determin pe care latur a triunghiului apare
problema curent pentru a ti la ce elemente trebuie lucrat pentru a relua
bunul mers al proiectului.
Dac latura pe care a aprut problema i latura fix a triunghiului
coincid, rmn celelalte dou laturi ale triunghiului pentru a fi ajustate. De
exemplu, dac proiectul trebuie s fie terminat la timp i problema este c
proiectul necesit prea mult timp, se pot modifica resursele sau domeniul de
aplicare.
Dac latura problemei este diferit de latura fix, proiectul trebuie
optimizat adaptnd latura rmas. De exemplu, dac proiectul trebuie s fie
terminat la timp, dar crete domeniul de aplicare, mai rmne s ajustm
numai latura costului, de exemplu, prin adugarea de resurse.
Cnd se ajusteaz o latur a triunghiului, celelalte dou sunt
susceptibile de a fi afectate, pozitiv sau negativ.
21
Proiectele au ntotdeauna resurse limitate, dar uneori exist proiecte

n care costul i cantitatea resurselor par a fi nelimitate. Ne putem gndi la
proiectul Manhattan din anii 40 sau la proiectul Apollo din anii 60, dar
chiar i aceste proiecte au avut unele constrngeri de resurse. Pentru
managerul de proiect care ncerc s finalizeze un proiect cu resurse puine
sau rare, acesta poate prea un mod minunat de a gestiona un proiect, dar de
obicei aceste tipuri de proiecte vin de obicei cu cerine severe pentru
graficul de lucru i termenele limit.
1.3.3. Ciclul de via al unui proiect
Proiectele de orice dimensiune, mici sau mari, pot fi gestionate
folosind metodologia managementului de proiect. Pentru c toate proiectele
sunt unice ntr-un fel, este util observarea ciclului de via al proiectelor
pentru a vedea c exist multe asemnri ntre proiecte i toate trec prin faze
similare. Ciclul de via al unui proiect definete nceputul i sfritul
acestuia i diferitele etape din cadrul lui. n diferite puncte ale ciclului de
via, aceste etape sunt reevaluate i este luat o decizie dac s se continue
proiectul sau nu. Punctele dintre nceputul i sfritul proiectului variaz
considerabil n funcie de specificul proiectului care urmeaz s fie realizat.
n Ghidul PMBOK sunt discutate procesele de baz ale
managementului de proiect. Managementul de proiect este un proces n care
intr anumite resurse, acestea sunt prelucrate i sunt produse rezultate. n
cadrul proceselor de management de proiect sunt incluse i alte procese
precum: iniierea, planificarea, execuia i ncheierea.
Pe parcursul duratei de via a unui proiect, vor exista rezultate la
fiecare faz. ndeplinirea acestor rezultate duce la crearea unui produs
livrabil, tangibil, verificabil rezultatul muncii depuse n cadrul proiectului.
Produsele pot fi livrate n exteriorul proiectului, sau sunt necesare pentru
realizarea altor activiti din cadrul proiectului, fiind considerate livrri
interne.
Exist mai multe modele ale ciclului de via al proiectelor, n
funcie de specificul domeniului. Modelul tipic cuprinde patru stadii, din
care ultimul poate fi compus din dou etape. n figura 1.2 se prezint ciclul
de via generic al unui proiect.
22
Figura 1.2. Ciclul de via al unui proiect
Acesta conine urmtoarele stadii:

1. Stadiul de definire:
Definirea specificaiilor proiectului;
Definirea obiectivelor proiectului;
Identificarea principalelor responsabiliti;
2. Stadiul de planificare:
Planificarea graficelor de lucru calendaristice;
Planificarea resurselor umane, de timp i a bugetului
proiectului;
Managementul riscurilor;
3. Stadiul de execuie i control:
Implementarea proiectului;
Monitorizarea progresului nregistrat n implementare;
Evaluarea, msurarea i controlul realizrilor intermediare;
Elaborarea de previziuni i prognoze de dezvoltare;
4. Stadiul de livrare i finalizare:
Livrarea produsului proiectului ctre beneficiar, incluznd
activiti de instruire, transfer de documente etc.;
23
Realizarea unei analize post-implementare;

Realocarea resurselor;
Raportul final al proiectului.
Pe durata ciclul su de via, proiectul trebuie s fac fa n

principal la dou tipuri de cerine. Prima dintre acestea se refer la etapa de
definire a problemei, n care eventualele erori pot conduce la dezvoltarea
unei soluii corecte pentru o problem definit greit.
n faza iniial a proiectului, nivelurile de costuri i de personal sunt
mici. Exist doar civa oameni cheie care i petrec timpul lucrnd la
proiect. Au fost achiziionate puine materiale sau deloc, iar angajamentul
companiei cu privire la partea financiar a proiectului nu este deplin. n
aceast etap exist cea mai mare probabilitate ca proiectul s nu fie
niciodat finalizat. Multe proiecte ajung n aceast faz doar pentru a fi
ntrerupte atunci cnd se stabilete c nu se poate respecta costul de realizare
sau costurile depesc beneficiile. n aceast etap a proiectului, multe
aspecte ale sale sunt necunoscute.
Cea de-a doua problem caracterizeaz etapa post-implementare.
Orice proiect trebuie s se finalizeze cu elaborarea unei analize postimplementare, cu scopul de a identifica att aspectele pozitive ale
proiectului ct i aspectele ce trebuie mbuntite.
n practic, aceast etap este deseori trecut cu vederea. Astfel, n
cadrul conferinei Frontiers Conference on Proiect Management, unul
dintre moderatori a ntrebat audiena format din 400 de persoane: Ci
dintre dumneavoastr au primit dispoziia ca, dup executarea proiectului, s
elaboreze un raport de evaluare care s cuprind concluziile finale? La
aceast ntrebare doar 10 persoane au ridicat mna.
A doua ntrebare a aceluiai moderator a fost: Ci dintre
dumneavoastr ai fost solicitai s prezentai managementului companiei ce
vei face ca s evitai repetarea n viitor a greelilor fcute n executarea
proiectului? La aceast ntrebare numai 2 persoane au ridicat mna.
Concluziile finale dup executarea unui proiect sunt deosebit de
importante, deoarece persoanele care nu cunosc istoricul proiectelor
precedente au tendina de a repeta greelile anterioare. Reticena unor
persoane de a face o trecere n revist a rezultatelor finale poate avea mai
24
multe cauze. n primul rnd, pe msur ce se apropie de finalizarea

proiectului, managerii devin nerbdtori s treac la realizarea altor sarcini
sau proiecte. n al doilea rnd, ei nu doresc s recunoasc faptul c la
anumite aspecte trebuie aduse mbuntiri. Uneori, aceast atitudine este
determinat de dorina de a nu crea dificulti persoanelor a cror activitate
trebuie perfecionat.
Totui, orict de bine este realizat o activitate, ntotdeauna este loc
pentru mbuntiri, iar analizele finale trebuie conduse n acest spirit.
Tendina de a pedepsi persoanele a cror activitate prezint deficiene poate
duna managerilor de proiect n elaborarea unor rapoarte de evaluare
corecte.
1.4. Managerul de proiect

Managementul proiectelor poate fi o profesie, o ocupaie, un rol sau
o activitate. Unele companii au manageri de proiecte a cror datorie este de
a superviza proiecte ntregi cu sute de persoane. Alte companii acord acest
titlu unor manageri nceptori, fiecare fiind responsabil de o mic parte
dintr-un proiect mai mare. n funcie de modul n care este structurat o
organizaie, de cultura sa organizaional i de obiectivele proiectului,
managementul de proiect poate avea un rol informal (este realizat de ctre
oricine, ori de cte ori este necesar) sau clar definit (X, Y i Z sunt manageri
de proiect cu norm ntreag).
Uneori absena unui manager de proiect dedicat nu pune probleme.
Programatorii i efii lor realizeaz planurile inginereti cnd este nevoie i
un specialist n marketing face planificarea sau stabilete cerinele. Orice
alt activitate de management de proiect pur i simplu se distribuie n
ntreaga echip. Poate c unii oamenii din echip au fost angajai pentru
interesul lor dincolo de scrierea de cod. Acetia nu vor refuza activiti
precum planificarea, proiectarea interfaei cu utilizatorul sau definirea
strategiei de afaceri. Folosind acest mod de lucru se pot realiza optimizri
semnificative. Atta timp ct toi membrii echipei sunt dispui s accepte
responsabiliti pentru a face lucrurile s mearg n mod coordonat i s
preia activitile unui manager de proiect dedicat, aceasta nseamn un om
25
mai puin, de care echipa se poate lipsi. Eficiena i simplitatea trebuie

apreciate.
Alteori, lipsa unui manager de proiect creeaz disfuncii. Fr o
persoan a crei principal activitate este ghidarea efortului global,
interesele individuale pot afecta direcia echipei. n jurul rolurilor tehnice i
comerciale pot aprea tensiuni care duc la ncetinirea progresului i
frustrarea celor implicai. De exemplu, n spitalele de urgen un singur
medic ia deciziile privind aciunile efectuate pentru un pacient. Acest mod
de lucru accelereaz luarea multor decizii i clarific rolul fiecrui membru
din echip. Fr o astfel de autoritate clar pentru probleme de management
al proiectelor, echipele de dezvoltare pot ntmpina dificulti. Dac nu
exist un responsabil pentru conducerea procesului de prelucrare i sortare a
defectelor, sau nimeni nu este direct responsabil pentru monitorizarea
graficului de lucru i semnalarea problemelor, aceste activiti pot rmne
mult n urma celor bazate pe programarea propriu-zis.
Dei muli programatori de vrf au suficient de multe cunotine
despre managementul de proiect, nct ar putea face chiar ei acest lucru,
acetia recunosc valoarea unic a unei persoane competente, dedicate, care
joac rolul de manager.
Managementul de proiect este n acelai timp:
o tiin deoarece presupune nelegerea proceselor, instrumentelor i

tehnicilor, precum i definirea i coordonarea activitilor care
trebuie efectuate;
o art, datorit aspectelor inter-personale care se refer la
conducerea oamenilor.
Instrumentele i tehnicile de management de proiect sunt ncercate i

testate i pot fi folosite cu succes la orice proiect. Aproape toate dintre
acestea sunt disponibile de muli ani, dar au fost oarecum dificil de utilizat
fr ajutorul calculatoarelor personale.
De asemenea, prin organizarea ntr-o manier care canalizeaz
eforturile depuse de echip n direcia de realizare a proiectului, se creeaz o
stare de nalt motivaie. Aceasta permite echipei s se concentreze asupra
obiectivelor i s nu fie distras de alte activiti din jur. Prile interesate
26
trebuie s aib puncte de contact consecvente cu echipa de proiect, iar

managerul de proiect trebuie s fie o surs sigur de informaii cu privire la
proiect i tot ce se ntmpl n cadrul acestuia.
Managerii de proiect pot fi vzui ca nite manageri de ntreprinderi
mici. Multe din caracteristicile necesare n gestionarea unei mici afaceri sunt
aceleai cu cele necesare pentru un bun management de proiect. n realitate,
datorit faptului c muli manageri de proiect din ziua de astzi au pregtirea
de baz n discipline tehnice, este surprinztor faptul c aptitudinile care le
sunt solicitate erau considerate anterior abiliti neobinuite pentru
managerii tehnici.
Astzi este de ateptat ca managerul de proiect s aib cunotine
considerabile din domeniul financiar, contabilitate, vnzri, marketing,
producie, cercetare i dezvoltare, planificare strategic i operaional,
caracteristicile organizaiilor, resurse umane, administraie, gestionarea
relaiilor de munc, motivare i alte competene inter-umane. Echipa
multidisciplinar a proiectului devine o entitate n sine, axat pe nevoile
proiectului i care ncearc satisfacerea acestor nevoi n cel mai bun mod
posibil.
1.4.1. Echilibrul atitudinilor
Managerii de proiect buni sunt greu de gsit deoarece acetia trebuie
s menin un echilibru al atitudinilor. Un manager de proiect trebuie nu
numai s fie contient de aceste trsturi, dar i s i dezvolte instinctele
adecvate pentru anumite situaii. Aceasta contribuie la ideea c
managementul de proiect este o art: necesit intuiie, hotrre i experien
de a utiliza aceste fore n mod eficient.
1. Orgoliul / lipsa orgoliului. Datorit responsabilitii mari pe care o
au managerii de proiect, acetia gsesc o satisfacie personal n
munca lor. Ei investesc o mare ncrctur emoional n ceea ce fac
i, pentru muli, aceast legatur emoional este ceea ce i determin
s menin intensitatea necesar pentru a fi eficieni. Dar n acelai
timp, managerii de proiect trebuie s evite plasarea intereselor
proprii naintea proiectului. Ei trebuie s fie dispui s delege att
sarcini importante ct i distractive, s mpart premiile i
27
2.
3.
4.
5.
recompensele cu ntreaga echip. Chiar dac mndria poate fi o

rezerv de energie, managerul de proiect trebuie s recunoasc
momentul n care aceasta i st n cale.
Autocraia / delegarea. n unele situaii, cele mai importante lucruri
sunt o linie clar de autoritate i un timp de rspuns rapid. Un
manager de proiect trebuie s fie ncreztor i dispus s preia
controlul i s foreze anumite aciuni ale echipei. Totui, n general
scopul este s se evite asemenea situaii extreme. Un proiect
gestionat bine trebuie s creeze o atmosfer unde sarcinile pot fi
delegate iar colaborarea este eficient.
Tolerarea ambiguitii / urmrirea perfeciunii. Primele faze ale
oricrui proiect conin experiene deschise i de o fluiditate mare,
acolo unde necunoscutul surclaseaz cunoscutul. Ambiguitatea
controlat este esenial pentru scoaterea la suprafa a ideilor bune,
i un manager de proiect ar trebui cel puin s respecte acest lucru
dac nu s l faciliteze i s l controleze. Dar n alte momente, mai
ales n fazele finale ale proiectului, disciplina i precizia sunt vitale.
Este nevoie de inteligen pentru a discerne ntre cazul n care
perfeciunea este rsplatit i cazul n care o soluie mediocr, rapid
i neglijent este suficient.
Comunicarea oral / scris. Indiferent ct este de axat o organizaie
de dezvoltare software pe comunicarea electronic, aptitudinile de
comunicare oral sunt de o importan critic pentru managementul
proiectului. ntotdeauna vor fi ntlniri, negocieri, discuii pe hol i
sesiuni de brainstorming, iar managerul de proiect trebuie s fie
eficient att la nelegerea ct i la comunicarea ideilor fa n fa.
Cu ct organizaia sau proiectul este mai mare, cu att abilitile
scrise devin mai importante. n ciuda preferinelor lui personale, un
manager de proiect trebuie s i dea seama cnd este mai eficient
comunicarea scris i cnd este de preferat comunicarea oral.
Recunoaterea complexitii / promovarea simplitii. Muli oameni
cad victime complexitii. Cnd sunt pui fa n fa cu o provocare
organizaional sau inginereasc complex, ei tind s se concentreze
asupra detaliilor i s piard din vedere imaginea de ansamblu. Alii
refuz complexitatea i iau decizii proaste pentru c nu neleg ntru
28
totul subtilitile problemelor aprute. Echilibrul aici poate fi gsit

vznd care perspectiv asupra proiectului e mai folositoare, prin
schimbarea sau combinarea perspectivelor. Managerii de proiect
trebuie s determine echipa s urmreasc simplitatea i calitatea,
fr a minimiza ns complexitatea necesar scrierii unui cod bun i
de ncredere.
6. Rbdarea / nerbdarea. n cele mai multe cazuri, managerul de
proiect este persoana care mpinge la aciune, forndu-i pe ceilali s
se concentreze asupra sarcinilor de lucru. Dar n unele situaii,
nerbdarea se ntoarce mpotriva proiectului. Unele activiti
politice, birocratice sau inter-organizaionale sunt consumatoare de
timp. De exemplu, dac o persoan important trebuie s vin la un
moment dat la o ntlnire, managerul de proiect trebuie s fie
rbdtor. A ti cnd s forezi o problem i cnd s te retragi i s
lai lucrurile s mearg de la sine este o calitate pe care trebuie s io dezvolte managerii de proiect.
7. Curajul / frica. O idee greit este aceea c oamenilor curajoi nu le
este fric. De fapt, curajoi sunt cei crora le este fric, dar cu toate
acestea aleg s acioneze. Un manager de proiect trebuie s aib o
bun nelegere a tuturor lucrurilor care pot merge ru i s le
considere posibile. Dar, cu toate acestea, el trebuie s aib curajul
necesar pentru a accepta provocri mari.
8. ncrederea / scepticismul. Nu este nimic mai important pentru
moralul echipei dect un lider respectat care crede n ceea ce face.
Un manager de proiect trebuie s aib ncredere n munca realizat i
s vad adevrata valoare a obiectivelor ce vor fi atinse. n acelai
timp, este nevoie de o doz de scepticism (nu cinism) referitoare la
modul n care se fac anumite lucruri. Cineva trebuie s critice i s
pun ntrebri, s conteste presupunerile altora i s aduc
problemele dificile la lumin. Cheia este capacitatea de a pune
ntrebri referitoare la presupunerile cuiva, de a-i contesta ipotezele
fr a zdruncina ncrederea echipei n munca pe care o face.
Persoanele cu astfel de abiliti se gsesc foarte rar, cu att mai mult
cele care au capacitatea de a le echilibra eficient. Multe dintre greelile pe
care le face un manager de proiect sunt cauzate de ineficiena echilibrrii
29
acestor fore conflictuale. Totui, oricine poate deveni mai bun n

recunoaterea, nelegerea i apoi n creterea abilitilor sale de a ine
forele n echilibru. Privind aceast list de fore conflictuale inevitabile,
managerul de proiect poate reconsidera ce face i de ce, pentru a lua decizii
mai bune.
1.4.2. Presiunile i neatenia
Una din temerile managerilor de proiect nceptori este aceea c
succesul necesit schimbare: modificare, construire sau distrugere.
Meninerea strii curente, n afara unui scop explicit pentru aceasta, este o
practic ineficient. Lumea se schimb tot timpul i dac un site web sau
orice alt proiect este la fel de bun astzi cum era anul trecut, asta nseamn
c a rmas n urm deoarece atingerea scopurilor a fost ru direcionat sau
execuia proiectului a euat ntr-un fel.
Este greu de ignorat imensa presiune care cade pe umerii
managerului de proiect, dar aceasta este inevitabil. Exist ntotdeauna un
mod nou de a gndi, altceva de nvat i aplicat, sau un nou proces care
face munca mai uoar i mai eficient. Un manager bun are nevoie de
abiliti de lider, iar un lider bun necesit abiliti de management. Oricine e
implicat n managementul proiectelor este responsabil de cte un pic din
amndou, indiferent ce scrie n fia postului.
Revenind la chestiunea presiunii, sunt muli manageri care fug de
momentele n care trebuie s fie i lideri, de exemplu cnd echipa are nevoie
de cineva care s ia o decizie, i se complac n a urmri eforturile altora n
loc s faciliteze sau chiar s participe la ele. Dac cineva st tot timpul i
ine scorul sau privete de pe margine, acesta este mai potrivit pentru un
post de contabil. Cnd cineva cu un rol de lider rspunde la presiune
ferindu-se de ea, el nu conduce, ci se ascunde. Managerii de proiect lai sau
ineficieni tind s fie mpini nspre periferia proiectului, de unde aduc
puin valoare acestuia.
Unii manageri n aceast situaie se rezum la a cuantifica lucruri
care nu trebuie cuantificate. Nesiguri de ce ar trebui s fac sau prea speriai
s fac ce trebuie fcut, ei i ocup timpul cu lucruri secundare. Cu ct
spaiul dintre manager i proiect crete, cu att mai mult crete i timpul
30
alocat verificrii tabelelor, listelor sau rapoartelor. Este posibil ca managerul

de proiect s ajung s cread n timp c datele i procesele sunt chiar
proiectul. El se bazeaz pe lucruri mai puin importante cu care se lucrez
mai uor precum fie de lucru i rapoarte, n pofida lucrurilor importante
care se rezolv mai greu, cum ar fi efortul de planificare sau programare. Ar
putea ajunge s cread c dac urmeaz perfect o anumit rutin i verific
rapoartele, proiectul este garantat s aib succes i, mai cinic, orice greeal
care apare nu este din vina lui.
Pentru a minimiza posibilitatea confuziilor, managerii de proiect
buni rezist tentaiei de a defini limite stricte asupra muncii pe care sunt
dispui s o fac sau nu. Ei evit s trag o linie ntre sarcinile referitoare la
managementul proiectului i proiectul n sine. Utilizarea listelor de obiective
implic faptul c exist un proces bine definit care garanteaz un anumit
final, ceea ce nu este cazul. n realitate exist ntotdeauna trei lucruri: un
scop, un volum de lucru i o mn de oameni. Rolurile bine definite i pot
ajuta pe aceti oameni s se organizeze privitor la volumul de munc, dar
formarea acestor roluri nu este scopul principal. O list de obiective poate
ajuta oamenii s lucreze ntr-un fel care atinge scopul, dar nu lista este
scopul principal. Confundarea proceselor cu scopurile este una din cele mai
mari greeli de management.
Years ago, working on the Internet Explorer 4.0 project, I was
the PM for several large areas of the user interface. I felt significant
pressure: it was the largest assignment Id ever had. In response, I
developed the belief that if I could write everything down into
checklists, Id never fail. While things do need to be tracked carefully
on a project, Id taken it too far. Id built an elaborate spreadsheet to
show multiple data views, and the large whiteboards in my office were
covered with tables and lists (and extra whiteboards were on the way).
My boss let me run with it because things were going well.
That is, until he saw me spending more time with my checklists and
processes than I did with my team a big red flag (warning sign). He
came into my office one day, and seeing the comically large matrix of
checklists and tables Id written on every flat surface in my office, sat
me down and closed the door. He said, Scott, this stuff is nice, but
your project is your team. Manage the team, not the checklists. If the
checklists help you manage the team, great. But the way youre going,
31
soon youll be using your team to help you manage your checklists.
(Scott Berkun The Art of Project Management)
n loc s se concentreze pe procese sau metode, managerii de proiect

ar trebui s se concentreze asupra echipei. n mod sigur trebuie folosite
sisteme simple de planificare i monitorizare, dar ele trebuie s fie
compatibile cu complexitatea proiectului i cultura echipei. Mai exact,
planificarea i monitorizarea trebuie s ajute echipa n atingerea scopului
proiectului, nu s-i mpiedice. Atta timp ct managerii de proiect sunt
ateni i ctig ncrederea echipei, orice scpare privind sarcinile,
procesele, rapoartele sau listele necesare managementului de proiect va iei
la lumin nainte ca problemele pe care acestea le pot rezolva s devin
serioase.
1.4.3. Msurarea performanelor
Deseori exist presupuneri tacite sau chiar explicite despre modul n
care un individ este recunoscut sau nu pentru performanele sale.
Dezvoltatorii sunt premiai pentru terminarea sarcinilor la timp. Testerii sunt
recompensai pentru efectuarea a numeroase teste i gsirea multor defecte.
Specialitii pentru suport telefonic sunt rspltii pentru preluarea a
numeroase apeluri i rezolvarea lor i aa mai departe. Totui, folosirea unor
metrici liniare pentru msurarea performanelor unui individ poate fi
neproductiv.
Aa cum reiese din figura 1.3, cnd un sistem de msurare este pus
n aplicare, msurile performanelor ncep s creasc. La nceput, valoarea
real a organizaiei poate de asemenea s creasc. Acest fenomen are loc
ntr-o anumit msur pentru c angajaii nu neleg sistemul de msurare
foarte bine la nceput, aa c aleg calea cea mai sigur de a atinge scopurile
organizaionale. mbuntiri reale pot aprea i pentru c primele inte sunt
modeste i nu determin angajaii s nele sistemul. Cu trecerea timpului
ns, cu ct standardele organizaiei cresc prin mrirea cotelor sau inducerea
unei stri de competiie ntre angajai, sunt folosite ci de atingere a
scopurilor incompatibile cu politicile firmei. Cnd un grup de angajai vede
alt grup c profit de scprile sistemului de evaluare, grupul mai lent simte
presiunea de a-i imita. Treptat, msurile i pierd relevana pentru
32
adevratele performane, fiindc angajaii cedeaz presiunii de a nela

sistemul. Performanele msurate cresc, ns adevratele performane scad
dramatic. n acest mod sistemul de msurare devine disfuncional.
Nivel de performan
Indicatorii msurtorii
Performana real
Timp
Figura 1.3. Efectul msurrii unidimensionale a performanei

Imagine measuring programmer productivity based on lines of
code written per day. An individual has a choice of calling a
framework method (perhaps 5 lines with error handling) or of copying
200 lines of open-source example code. Which one gets rewarded?
Which one is easier to maintain, to code-review, to security-review, to
test, and to integrate? Or similarly, the individual has the chance to
refactor three overlapping methods into one, reducing the size of the
code base.
Imagine measuring testers based on the number of bugs found.
Do they look for easy-to-find, overlapping, simple bugs or go after
significant ones that require setting up complex customer data and
configurations? Which approach gets rewarded? Which one yields
more customer value? (Robert D. Austin Measuring and Managing
Performance in Organizations)
1.4.4. Implicarea corect

Managerii nu sunt angajai s contribuie n mod liniar la munca din
organizaie, ca programatorii simpli, ci s amplifice valoarea celor din jurul
lor. Metodele prin care se poate aduga aceast valoare difer de munca
realizat la nivelurile inferioare. Dar pentru c muli manageri sunt foti
33
programatori care au fost promovai, sunt anse ca ei s aib mai mult talent
la scrierea codului dect la conducerea unor persoane.
Prezena unui manager ar trebui s contribuie cu ceva de alt natur
dect simpla adugare a unei contribuii individuale. Uneori aceast
contribuie vine din aplanarea conflictelor i izolarea echipei de partea
politic. Alteori se refer la planificarea de nivel nalt sau gsirea unor ci
de evitare a situaiilor neateptate. Pentru c aceste contribuii sunt mai greu
de msurat, muli manageri de proiect au o problem cu ambiguitatea rolului
lor.
Cea mai bun metod de a gsi punctele de echilibru este utilizarea
diferenei psihologice pe care o confer poziia de pe un nivel superior. Un
manager de proiect, n timpul activitilor sale, va petrece n mod natural
mai mult timp cu oamenii din echip dect alii, obinnd astfel mai multe
surse de informare i o perspectiv mai larg asupra proiectului. Un
manager de proiect va nelege att perspectiva comercial a proiectului ct
i pe cea tehnic i va ajuta echipa s comute ntre cele dou dac este
necesar. Aceast perspectiv mai larg face posibil oferirea unor informaii
critice angajailor la momentul potrivit.
As a habit, Ive always walked the halls and dropped in on
programmers who had their doors open. Id usually just make small
talk, try to get them to laugh about something, and ask them to show
me what they were working on. If they offered, Id watch a demo of
whatever theyd show me. Doing this every few days, even for a few
minutes, often gave me a good idea of the real status of the project.
For example, one morning during the IE 5.0 project, I dropped
by Freds office. He was arguing with Steve, another programmer,
about how they were going to get the new List View control to work
properly an unforeseen compatibility issue had been discovered that
morning. Neither one of them wanted to do the work. And from what I
could hear, it would take a half-day or more to fix. I poked my nose in
and confirmed what they were talking about. They nodded their heads,
as if to say, Yeah, why should you care? I then told them to go talk
to Bill down the hall. They again asked why, thinking this was a very
specific architectural issue that I couldnt easily understand. I smiled
and said, Because I just left his office, and he has the new tree
control working perfectly on his machine. He came across the
34
problem last night and fixed it as part of another work item. (Scott
Berkun The Art of Project Management)
Managerii de proiect buni trebuie s cunoasc tot felul de lucruri

utile referitoare la starea echipei i a proiectului i apoi s le aplice pentru a
ajuta oamenii s-i termine activitile. Transferul la timp al informaiilor
este ceea ce face o echip mediocr bun, iar o echip bun excelent.
Niciun sistem de monitorizare a unui proiect nu poate nlocui complet
nevoia oamenilor de a comunica ntre ei despre ce se ntmpl, pentru c
reelele sociale sunt ntotdeauna mai puternice i uneori mai rapide dect
cele tehnice. Marile provocri precum viziunea asupra proiectului, listele de
caracteristici i graficele de lucru se reduc la o serie de numeroase provocri
mai mici care sunt influenate de ct de bine curg informaiile ntr-o echip.
Managerii de proiect joac un rol critic n meninerea activ a acestui flux
de informaii.
Managerii de proiect petrec mai mult timp cu fiecare persoan din
echip dect oricine altcineva. Ei particip la mai multe ntlniri, intr n
mai multe birouri i vorbesc cu mai muli colaboratori dect oricine
altcineva din organizaie. Dac un manager de proiect e fericit, suprat,
motivat sau deprimat, ceva din aceste stri de spirit se va reflecta i asupra
oamenilor pe care i ntlnete n fiecare zi. Ceea ce un manager aduce
proiectului, bun sau ru, va fi contagios pentru restul echipei.
1.5. Concluzii
Managerii de proiect buni ctig de obicei un anumit respect din
partea proiectanilor, a programatorilor, a testerilor i a celorlalte persoane
cu care vin n contact. Un manager de proiect trebuie s fie n stare s
realizeze strategii, planuri, s aib idei i un mod de gndire i de conducere
cu un impact pozitiv asupra echipei. De obicei, aceasta implic gsirea unor
optimizri inteligente n fluxul zilnic de lucru sau aducerea unui impuls de
entuziasm i ncurajare n direcia potrivit la momentul potrivit. Managerii
de proiect nu trebuie s fie supra-oameni sau s fie deosebit de inteligeni.
35
Trebuie doar s neleag avantajul perspectivei lor asupra situaiei i s

foloseasc acest lucru.
In the end, the core idea I believe in is that as long as no one
gets hurt (except perhaps competitors), and you involved people in the
right way, nothing else matters but the fact that good stuff is made. It
doesnt matter how many ideas came from you or someone else, as
long as the outcome is positive. Project management is about using
any means necessary to increase the probability and speed of positive
outcomes. A useful daily mantra Ive used is Make good stuff
happen. People would see me in the hallway or working with a
programmer at a whiteboard and ask, Hey Scott, whatcha doing?
And Id smile and say, Making good stuff happen. It became a
dominant part of how I approached each and every day, and when I
managed others, this attitude extended out and across the team
through them. (Scott Berkun The Art of Project Management)
36
Capitolul 2
Metodologii de dezvoltare a programelor

2.1. Introducere
O metodologie de dezvoltare a programelor, numit i proces de
dezvoltare software, reprezint o structur impus asupra dezvoltrii unui
produs software. Este planul de aciune privind succesiunea celor patru faze
ale ingineriei programrii: analiza, proiectarea, implementarea i testarea.
Unele companii folosesc propriile metodologii. Altele folosesc
metodologii comerciale. ns fr o metodologie adecvat, dezvoltarea
produsului este haotic.
Alegerea unei metodologii de dezvoltare trebuie s in seama de
natura fiecrui proiect: mrimea echipei, bugetul, tehnologia i
instrumentele utilizate, termenele limit, procesele existente deja.
2.2. Abordarea codeaz i repar

Abordarea codeaz i repar (engl. code and fix) este cea mai
rapid i puin eficient metodologie. Nu exist reguli de organizare i se
ignor etapele cheie de dezvoltare. Aceasta este metoda utilizat de obicei
de companiile de la nceput de drum, cu puini dezvoltatori. Recomandarea
n aceast situaie este introducerea treptat a unor modaliti formale de
dezvoltare i verificare.
2.3. Metodologia secvenial

Este o metodologie generic n care cele patru faze urmeaz una
alteia ntr-o manier serial. Echipele care se ocup de fiecare faz pot fi

diferite, iar la fiecare tranziie de faz poate fi necesar o decizie

managerial. Se recomand pentru probleme bine nelese, pentru
automatizarea unor sisteme manuale existente sau pentru proiecte de scurt
durat.
Figura 2.1. Metodologia secvenial
Avantaje. Metodologia secvenial este potrivit cnd complexitatea

sistemului este mic iar cerinele sunt statice. Este simpl, logic i uor de
urmat. Foreaz meninerea unei discipline de lucru n care analiza i
proiectarea au loc naintea implementrii. Se evit presiunea scrierii codului
nainte de a cunoate precis ce produs va trebui de fapt construit i deci
scade probabilitatea introducerii unor pri de cod inutile sau ineficiente n
produsul final. Un mare numr de sisteme software din trecut au fost
construite cu o metodologie secvenial.
Dezavantaje. Se acord o foarte mare importan fazei de analiz.
Analitii trebuie s defineasc toate detaliile aplicaiei nc de la nceput i
nu exist un proces de corectare a erorilor dup stabilirea cerinelor.
Comunicarea dintre echipele desemnate pentru fazele de dezvoltare se
limiteaz n principal la documentele realizate de o echip i trimise
urmtoarei echipe. ntr-un mediu economic dinamic, metodologia
secvenial poate produce sisteme care, la vremea lansrii, s fie deja
nvechite.
2.3.1. Metodologia cascad
Metodologia cascad (engl. waterfall) a fost propus de Winston
W. Royce (1970). Procesul curge de la etap la etap, ca apa ntr-o
cascad. Dup fiecare etap exist un pas de validare. n descrierea iniial
exist o ntoarcere, un pas napoi interactiv ntre fiecare dou etape
succesive.
38
Cerine sistem i validare
Cerine software i validare
Proiectare preliminar i validare
Proiectare detaliat i validare
Implementare, testare,
depanare i desfurare
Pre-operare, testare de validare
Operare, ntreinere, revalidare

Figura 2.2. Metodologia cascad
Dezavantajul principal al modelului cascad apare deoarece clientul

obine o viziune practic asupra produsului doar n momentul terminrii
procesului de dezvoltare. De asemenea, modelul nu are suficient putere
descriptiv, n sensul c nu integreaz activiti ca managementul riscului
sau managementul configuraiei.
39
2.4. Metodologia ciclic (iterativ)

Se bazeaz pe ideea perfecionrii incrementale a metodologiei
secveniale. Fazele sunt dispuse n cicluri care contribuie succesiv la
realizarea sistemului final. n fiecare faz se consum un timp mai scurt,
dup care urmeaz mai multe iteraii prin toate fazele. Pe msur ce
procesul nainteaz, sunt generate din ce n ce mai multe detalii. n final,
dup cteva cicluri, sistemul este complet i gata de lansare. Procesul poate
continua pentru lansarea mai multor versiuni ale produsului. Se recomand
pentru proiecte unde timpul este esenial, unde apar riscuri asociate cu o
durat mare a proiectului sau unde cerinele nu pot fi cunoscute exact de la
nceput.
Figura 2.3. Metodologia ciclic
Avantaje. Permite feedback-ul de la fiecare echip n ceea ce

privete corectitudinea cerinelor. Exist etape n care pot fi corectate
eventualele greeli. Clientul poate studia rezultatul i poate oferi informaii
importante mai ales n faza dinaintea lansrii produsului. Dezvoltarea se
poate adapta mai bine progresului tehnologic: pe msur ce apar noi soluii,
ele pot fi ncorporate n produs. Pot avea loc livrri regulate sau rapide.
Permite prioritizarea cerinelor.
Dezavantaje. De vreme ce nu exist constrngeri asupra echipei de
analiz s fac lucrurile cum trebuie de prima dat, acest fapt poate duce la
scderea responsabilitii. Echipa de proiectare nu are o viziune global
asupra produsului i deci nu poate realiza o arhitectur complet. Fiecare
iteraie necesit un timp suplimentar de planificare. Ciclurile pot continua
fr o condiie clar de terminare. Echipa de implementare poate fi pus n
situaia nedorit n care cerinele i arhitectura sistemului sunt n permanent
schimbare iar renunarea la pri de cod deja scrise determin creterea
costurilor.
40
2.4.1. Metodologia spiral

Metodologia spiral, propus de Barry Boehm (1988), consider c
fiecare pas din dezvoltare conine o serie de activiti comune:
pregtirea: se identific obiectivele, alternativele, constrngerile;

managementul riscului: analiza i rezolvarea situaiilor de risc;
activiti de dezvoltare specifice pasului curent, de exemplu analiza
cerinelor sau scrierea de cod;
planificarea urmtorului stadiu: termenele limit, resursele necesare,
revizuirea strii curente a proiectului.
Figura 2.4. Metodologia spiral
41
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint

o etap. Pe msur ce se parcurge spirala, produsul se maturizeaz. Cu
fiecare ciclu, sistemul se apropie de soluia final.
2.4.2. Metodologia Timeboxing
ncearc accelerarea procesului de dezvoltare prin aplicarea
paralelismului ntre diferite iteraii. Unitatea de baz este o caset de timp
(engl. time box), cu durat fix. De aceea, un factor cheie n alegerea
cerinelor este ce poate fi realizat ntr-o caset de timp. Acest fapt
contrasteaz cu metodologiile iterative clasice n care mai nti se hotrte
funcionalitatea i abia apoi timpul de livrare. Fiecare caset de timp este
mprit ntr-o succesiune de etape, ca n modelul cascad. Duratele acestor
etape trebuie s fie de asemenea aproximativ egale. Trebuie s existe o
echip dedicat pentru fiecare etap. Cnd o echip termin etapa i din
caseta de timp k, i pred livrabilul echipei dedicate fazei i+1 i apoi ncepe
lucrul la aceeai etap din caseta de timp k+1.
Dac o caset de timp are T zile i n etape, prima livrare are loc dup
T zile, iar urmtoarele la cte T / n zile distan. De exemplu, dac T este 9
sptmni iar n este 3, prima livrare va fi fcut dup 9 sptmni, a doua la
12 sptmni, a treia la 15 .a.m.d. Execuia liniar a iteraiilor ar conduce la
termene de livrare de 9, 18, respectiv 27 de sptmni.
Costul suplimentar pentru scurtarea timpului de livrare st n
utilizarea resurselor. De exemplu, dac pentru un proiect analiza i
proiectarea dureaz 2 sptmni cu 2 persoane, implementarea 2 sptmni
cu 4 persoane iar testarea 2 sptmni cu 3 persoane, pentru execuia serial
a iteraiilor sunt necesare 4 persoane. Pentru metodologia timeboxing, sunt
necesare 2+4+3 = 9 persoane.
42
Figura 2.5. Metodologia Timeboxing
Avantajul principal este scurtarea ciclului de livrare.

Dezavantajele constau n creterea dimensiunii echipei,
complexitatea managementului i costul ridicat.
Metodologia se recomand atunci cnd sunt necesare termene de
livrare scurte i exist flexibilitate n gruparea funcionalitilor, astfel nct
casetele de timp s aib lungimi egale.
2.5. Metodologia hibrid ecluz

Metodologia ecluz (engl. watersluice), propus de Ronald LeRoi
Burback (1998), combin progresul constant al metodologiei secveniale cu
incrementele iterative ale metodologiei ciclice.
43
Figura 2.6. Metodologia hibrid ecluz
n prima etap, schia de principiu, echipele lucreaz iterativ la toate

fazele problemei. Echipa de implementare se concentreaz asupra sarcinilor
critice. Unul din scopurile acestei etape este de a se convinge echipele c
proiectul este fezabil, c o soluie poate fi gsit i pus n practic.
n cea de a doua etap, de prototip, cerinele sunt ngheate. Dup ce
sarcinile critice au fost terminate, echipa de implementare se poate
concentra pe extinderea acestora. Unul din scopurile acestei etape este de a
convinge persoanele din afara echipelor (prile interesate) c o soluie este
posibil.
n versiunile alfa i beta, arhitectura este ngheat, iar accentul cade
pe implementare i asigurarea calitii. Rolul acestei etape este de a
convinge clienii c aplicaia va fi un produs adevrat.
nainte de lansarea produsului, implementarea este ngheat i
accentul cade pe testare. Scopul este realizarea unui produs competitiv.
2.6. Modelul V
Modelul V (germ. V-Modell) evideniaz testarea pe tot parcursul
ciclului de dezvoltare. A fost creat pentru reglementarea dezvoltrii
produselor software n administraia federal german. Modelul poate fi
44
considerat o extensie a metodologiei cascad, ns pune accentul pe relaia

dintre fiecare faz de dezvoltare i faza de testare asociat. Trecerea la faza
urmtoare se face numai dup ce toate livrabilele din faza curent au trecut
testele de verificare i validare.
Figura 2.7. Modelul V
2.7. Metode formale

Acest model de dezvoltare apeleaz la formalismul i rigoarea
matematicii pentru construirea specificaiilor. Metodele formale sunt
potrivite n special pentru sisteme cu cerine critice.
Avantaje:
precizia obinut prin specificarea formal;

45
pstrarea corectitudinii n timpul transformrii specificaiilor n cod

executabil;
ofer posibilitatea generrii automate de cod;
verificarea consistenei i testarea prin metode similare demonstrrii
automate de teoreme.
Dezavantaje:
specificarea formal este de obicei o barier de comunicare ntre

client i analist;
necesit personal foarte calificat, deci mai scump;
folosirea impecabil a tehnicilor specificrii formale nu implic
neaprat obinerea de programe sigure, deoarece anumite aspecte
critice pot fi omise din specificaii.
Figura 2.8. Specificaie n limbajul Z

46
2.8. Programarea extrem

Programare extrem (engl. eXtreme Programming) este o
metodologie agil, potrivit dezvoltrii rapide de aplicaii, propus de
Kent Beck (1996). Dintre caracteristicile XP, amintim urmtoarele:
Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie

la proiect folosind maximul din cunotinele sale;
Scrierea de cod este activitatea cea mai important;
Proiectul este n mintea tuturor programatorilor din echip, nu n
documentaii, modele sau rapoarte;
La orice moment, un reprezentant al clientului este disponibil pentru
clarificarea cerinelor;
Codul se scrie ct mai simplu;
Se scrie mai nti cod de test;
Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se
face fr mil;
Modificrile aduse codului sunt integrate continuu, de cteva ori pe
zi;
Se programeaz n perechi. Echipele se schimb la sfritul unei
iteraii (1-2 sptmni);
Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar.
Manifest pentru dezvoltarea agil de software (2001)
Descoperim continuu metode mai bune pentru dezvoltarea de

software prin aplicarea acestora i prin ajutorul acordat altora pentru a le
aplica. Astfel, am ajuns s preuim:
Oamenii i interaciunile mai mult dect procesele i instrumentele
Software-ul funcional mai mult dect documentaia cuprinztoare
Colaborarea cu clienii mai mult dect negocierea contractelor
Adaptarea la schimbare mai mult dect respectarea unui plan
Mai exact, dei elementele din dreapta sunt valoroase, le preuim mai
mult pe cele din stnga.
47
Principiile Manifestului agil

Respectm urmtoarele principii:
1. Prima noastr prioritate este aceea de a satisface clienii prin livrri
nentrziate i continue de software valoros.
2. Acceptm schimbarea cerinelor, chiar i mai trziu n procesul de
dezvoltare. Procesele agile valorific schimbarea n avantajul
competiional al clientului.
3. Livrm frecvent software funcional, de la cteva sptmni pn la
cteva luni, prefernd intervalele de timp mai scurte.
4. Oamenii de afaceri i dezvoltatorii trebuie s lucreze zilnic mpreun
pe parcursul proiectului.
5. Construim proiecte n jurul persoanelor motivate. Le oferim mediul
i sprijinul de care au nevoie i avem ncredere n ei c vor finaliza
lucrarea.
6. Metoda cea mai eficient i eficace pentru comunicarea informaiilor
ctre i n cadrul echipei de dezvoltare o reprezint conversaia fa
n fa.
7. Software-ul funcional este principala msur a progresului.
8. Procesele agile promoveaz dezvoltarea durabil. Sponsorii,
dezvoltatorii i utilizatorii trebuie s fie capabili s menin un ritm
constant pe timp nedefinit.
9. Atenia continu pentru superioritate tehnic i proiectare bun
sporete agilitatea.
10. Simplitatea arta maximizrii cantitii de munc neefectuat este
esenial.
11. Cele mai bune arhitecturi, cerine i proiectri provin din cadrul
echipelor care se organizeaz singure.
12. La intervale regulate, echipa reflecteaz asupra modului n care
poate deveni mai eficace i apoi i modific n mod corespunztor
comportamentul.
Carta drepturilor dezvoltatorului:
Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare

de prioritate;
Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s
i revizuieti estimrile n funcie de experien;
48
Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie

atribuite;
Ai dreptul s faci treab de calitate n orice moment;
Ai dreptul la linite, distracie i la munc productiv i plcut.
Carta drepturilor clientului:
Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce

pre;
Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se
dovedete c funcioneaz trecnd teste repetabile pe care le specifici
tu;
Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s
schimbi prioritile;
Ai dreptul s fii informat de schimbrile n estimri, suficient de
devreme pentru a putea reduce cerinele astfel ca munca s se
termine la data prestabilit. Poi chiar s te opreti la un moment dat
i s rmi cu un sistem folositor care s reflecte investiia pn la
acea dat.
2.9. Metodologia Open Source

Conceptul de dezvoltare open-source (surs la vedere) este o
abordare recent, aprut ca urmare a dezvoltrii mijloacelor de comunicare
prin internet: email, grupuri de discuie, site-uri dedicate dezvoltrii
colaborative de software. Exemple clasice de produse dezvoltate n aceast
manier sunt sistemul de operare Linux i browser-ul Netscape 5. Codul
surs este transmis utilizatorului final ntr-o manier non-proprietar (fr
patent), pe baza unei licene open-source (de exemplu GNU).
O iteraie tipic:
Iniiatorul realizeaz proiectarea i implementarea, individual sau n

echip;
Ceilali dezvoltatori sau comunitatea de utilizatori realizeaz testarea
i eventual depanarea;
49
Noile funcionaliti dorite i erorile depistate sunt trimise

iniiatorului proiectului;
Se lanseaz o nou versiune cu defectele corectate i se analizeaz
noile cerine;
Se distribuie o list de sarcini ctre comunitatea de utilizatori,
cutndu-se membri voluntari care s execute sarcinile de pe list.
Avantaje:
Pre mult mai mic dect al produselor proprietare;

Ideile vin de la o ntreag comunitate de utilizatori i programatori;
Accesul la surse poate ajuta detectarea i repararea defectelor.
Dezavantaje:
Lipsa garaniilor de calitate;

Risc privind cazurile de nclcare a proprietii intelectuale, dac
programatorii folosesc surse proprietare, greu de verificat;
Unele licene prevd ca produsele derivate s fie tot open-source,
ceea ce oblig companiile care utilizeaz aceste produse s i
publice propriul cod.
2.10. Metodologia de dezvoltare Offshore

(Outsourcing)
Companiile utilizeaz outsourcing-ul pentru funciile care pot fi
dezvoltate mai ieftin n alt ar. Un proiect tipic are urmtoarele etape:
Iniierea proiectului (local);

Analiza cerinelor (local);
Proiectarea de nivel nalt (local);
Proiectarea detaliat (offshore);
Implementarea (offshore);
50
Testarea (offshore sau local);

Livrarea (local).
Motive pentru outsourcing:
Reducerea costurilor;
Creterea eficienei;
Concentrarea asupra obiectivelor critice ale proiectului;
Accesarea flexibil a unor resurse care altfel nu ar fi accesibile, de
exemplu personal nalt calificat;
Dimensiunea mare a proiectului.
Dezavantaje:
Control managerial mai redus;

Probleme de confidenialitate i securitate;
Risc n cazul falimentului companiei offshore;
Probleme de limb, fus orar.
2.11. Concluzii
Simpla adoptare a unei metodologii fr o analiz temeinic a
cerinelor i contextului de lucru nu este recomandat. Metodologia este o
tactic ce trebuie considerat numai dup determinarea strategiei generale a
companiei.
51

Capitolul 3
Justificarea financiar a proiectului

3.1. Introducere
nainte de nceperea proiectului, se realizeaz aa-numita cart a
proiectului (engl. project charter), documentul care autorizeaz n mod
formal nceperea acestuia i nominalizeaz managerul de proiect.
Autorizarea formal presupune de obicei deschiderea unui cont pentru
gestionarea costurilor proiectului. Carta proiectului este redactat de
managerul de proiect, ns se distribuie sub semntura persoanei autorizate
s creeze i s finaneze proiectul. Este important ca managerul de proiect s
scrie carta deoarece este o prim ocazie ca acesta s defineasc modul n
care vede proiectul. Carta conine i justificarea financiar a proiectului.
Una din justificrile cele mai puternice este conceptul de beneficiu
financiar pentru organizaia care depune efortul de realizare a proiectului.
Desigur, exist i alte justificri, precum rspunsul la noi reglementri
guvernamentale, creterea cotei de pia sau oportuniti de a intra pe noi
segmente de pia.
3.2. Diagrama pragului de rentabilitate

(Break Even Chart)
Diagrama pragului de rentabilitate este util la compararea a dou
sau mai multe alternative. Pentru justificarea proiectului, se compar
realizarea acestuia cu alternativa de a nu-l realiza. Pe abscis se reprezint
timpul iar pe ordonat costul total (figura 3.1).

Figura 3.1. Diagrama pragului de rentabilitate
Dac realizarea proiectului necesit o investiie iniial, costul

variabil se reprezint ncepnd cu punctul de pe axa vertical corespunztor
costului total fix iniial al proiectului. Dac alternativa este de a nu realiza
proiectul, costul iniial este nul.
La un anumit moment de timp, dac proiectul are un beneficiu,
liniile variabile se intersecteaz. Acesta este pragul de rentabilitate, cnd
beneficiile proiectului depesc costurile n comparaie cu alternativa de a
nu face proiectul. Punctul corespunztor de pe axa timpului reprezint
perioada de recuperare a investiiei (engl. payback period).
De exemplu, sistemul de automatizare a produciei unei firme poate
asigura producerea de componente cu 2 USD bucata. Un nou sistem ar putea
crete productivitatea la 1,5 USD / component, ns necesit o investiie
iniial de 200.000 USD. Firma produce 25.000 de componente pe lun.
Pragul de rentabilitate este afiat n figura 3.2.
54
Figura 3.2. Exemplu de diagram a pragului de rentabilitate
Aceast metod este potrivit cnd se presupune c ratele de

producie sunt constante, astfel nct costurile totale sunt liniare.
Dezavantajul este c proiectele cu o recuperare rapid a investiiei sunt
favorizate n comparaie cu proiectele care ar putea aduce mai mult profit pe
termen lung.
3.3. Rata medie de recuperare a investiiei

(Average Rate of Return on Investment)
Elimin problema orizontului de timp a metodei pragului de
rentabilitate, comparnd toate alternativele pe aceeai perioad de timp:
durata aproximativ de via a produselor rezultate din proiect.
Continund exemplul anterior, lum acum n calcul i variaiile de
productivitate i cheltuielile de ntreinere ale sistemului, care apar dup
civa ani de funcionare (tabelul 1-1). n acest caz, profitul de 935.000 USD
pentru investiia de 200.000 USD reprezint o rat de recuperare de 467,5%
n 10 ani, adic o rat medie de recuperare a investiiei de 46,75%.
55
3.4. Valoarea actual net (Net Present Value)

Metoda pleac de la principiul c banii primii sau cheltuii n viitor
valoreaz mai puin dect banii din prezent. De exemplu, dac se depun la
banc 100 USD cu o dobnd de 5%, peste un an banii vor valora 105 USD
iar peste 2 ani 110,25 USD, conform formulei:
VV VA 1 d ,
n
unde VV este valoarea viitoare, VA este valoarea actual, d este dobnda iar n
este numrul de ani.
Invers, se poate utiliza aceeai formul pentru a calcula valoarea
actual a unei sume de bani din viitor:
VA
VV
.
1 d n
Considernd acelai nivel al dobnzii, de 5%, putem spune c 100

USD primii peste un an sunt echivaleni cu 95,24 USD primii n prezent
iar 100 USD primii peste 10 ani sunt echivaleni cu 61,39 USD primii n
prezent.
Multe proiecte pornesc cu o investiie iniial, urmnd ca beneficiile
s apar ulterior. Folosind valoarea actual, putem determina mai precis
56
valoarea real a unui proiect. Proiectele care genereaz profit mai repede vor
fi considerate mai bune dect proiectele care au acelai profit mai trziu.
Valoarea actual net este suma intrrilor i ieirilor de capital
ajustat la valoarea actual.
n tabelul 1-2 se prezint spre comparaie 2 proiecte care presupun o
investiie iniial de 100.000 USD, dup care proiectul A aduce mai mult
profit n primii ani, iar proiectul B aduce profit constant pe toat durata
considerat, de 10 ani. Rata dobnzii se consider 7%. Ambele proiecte au
intrri totale de capital de 300.000 USD, ns primul proiect are o valoare
actual net mai mare.
Aceast metod prezint avantajul de a lua n calcul dinamica

proiectului pe parcursul ciclului de via, ns are i unele dezavantaje. De
exemplu, dac n viitor apar pierderi, valorile actualizate ale acestora sunt
mai mici, ceea ce ar putea conduce la un rezultat prea optimist al analizei
proiectului.
Totui, dac valoarea actual net a unui proiect este negativ,
aceasta nu nseamn c proiectul trebuie respins automat. Alternativa de a
nu-l realiza poate fi i mai defavorabil. De asemenea, pot exista alte criterii
de justificare, de exemplu creterea cotei de pia etc. dup cum am
menionat mai sus.
57
3.5. Rata intern de recuperare a investiiei

(Internal Rate of Return on Investment)
n exemplul din tabelul 1-2, proiectul A a fost preferat de fapt
datorit ratei dobnzii. Dac aceasta ar fi fost 0%, ambele proiecte ar fi fost
la fel de atractive.
Metoda ratei interne de recuperare a investiiei se bazeaz pe analiza
modului de investire a banilor i a riscurilor existente. De exemplu, o sum
de bani poate fi investit n bonuri de trezorerie care au risc practic nul dar
i o dobnd mic. Alternativ, banii pot fi investii pentru realizarea unui
proiect, unde riscul este mai mare dar i profiturile pot fi mai mari.
La dobnzi mici, vor fi favorizate investiiile n proiecte cu riscuri
asociate dar i cu intrri mai mari de capital. Pe msur ce dobnda crete,
diferena dintre cele dou tipuri de investiii va scdea pn cnd investiia
lipsit de risc va fi mai potrivit.
Pentru aceast metod de justificare financiar, se calculeaz rata
dobnzii bonurilor de trezorerie care ar face ca investiia n bonuri i
investiia n proiect s fie la fel de atractive. Pentru aceasta, comparm
valoarea actual net a proiectului la sfritul ciclului de via cu valoarea
actual net a unei investiii fr risc (0).
Conform metodei, se determin dobnda limit pentru care valoarea
actual net a ciclului de via estimat al proiectului (N ani) este 0:
Ct
0,
t
t 0 1 d
N
V Anet
unde Ct sunt intrrile (valori pozitive) i ieirile (valori negative) de capital.

Rata intern de recuperare este rata de actualizare (engl. discount
rate) la care totalul intrrilor de capital n valoare actualizat egaleaz
totalul ieirilor de capital la valoare actualizat.
De exemplu, s considerm proiectul A din exemplul anterior i s
analizm fluxul de capital pentru diferite rate de dobnd (tabelul 1-3). Dac
vom calcula valoarea actual n fiecare caz, observm c, la sfritul ciclului
de via estimat, valorile nete sunt pozitive sau negative. Ne intereseaz
valoarea limit la care totalul este 0, care se vede c aparine intervalului
58
(40% 42,5%). Se poate determina iterativ, pe baza mpririlor succesive

ale intervalului, valoarea exact: 41,2%.
Se consider c un proiect este o investiie bun dac rata sa de
recuperare este mai mare dect rata de recuperare a unei investiii
alternative. Cu ct este mai mare rata de recuperare, cu att mai dezirabil
este demararea unui proiect. Astfel, rata de recuperare poate fi folosit
pentru a ierarhiza diferite proiecte poteniale pe care le-ar putea realiza o
firm.
Rata intern de recuperare este un indicator al eficienei sau calitii
unei investiii, spre deosebire de valoarea actual net care reflect mrimea
investiiei.
3.6. Concluzii
Toate proiectele trebuie justificate, de obicei pe baza comparrii
costurilor cu beneficiile. n prezent, metoda cea mai utilizat pentru
justificarea financiar a proiectelor este cea a ratei interne de recuperare a
investiiei.
59
60
61
62
Capitolul 4
Managementul domeniului
4.1. Introducere
Managementul domeniului (engl. scope) unui proiect se refer la
gestionarea anvergurii, amplorii, ntinderii, dimensiunii proiectului. Acest
tip de management include procesele care garanteaz c proiectul include
toate activitile necesare, i numai activitile necesare, pentru a finaliza
proiectul cu succes. Managementul domeniului se ocup deci cu definirea i
controlul a ceea ce este inclus sau nu n proiect.
Managementul domeniului include urmtoarele aspecte:
Definirea domeniului;
Crearea structurii de descompunere a activitilor;
Verificarea domeniului;
Controlul domeniului.
Trebuie reinut faptul c ndeplinirea domeniului proiectului este

msurat n raport cu planul proiectului, iar ndeplinirea domeniului
produsului este msurat n raport cu cerinele produsului.
4.2. Definirea domeniului

Cel mai frecvent motiv pentru eecul proiectelor este definirea
deficitar a domeniului, atunci cnd ateptrile prilor interesate, n special
ale clientului sau sponsorului, sunt diferite de ateptrile echipei proiectului.
Uneori, este dificil de convins clientul c att el ct i echipa au de fapt
acelai scop n cadrul proiectului, acela de a-i oferi clientului un produs util
i cu funcionalitile dorite.

Echipa proiectului trebuie de asemenea s l neleag pe client i s

nu devin frustrat n cazul n care acesta pare s tie mai puin despre
proiect dect nsi echipa. Clientul nu este un expert n realizarea
proiectelor software i de aceea a apelat la ajutorul echipei.
Etapele de definire a domeniului, crearea Structurii de
descompunere a activitilor, SDA (engl. Work Breakdown Structure,
WBS) i verificarea domeniului au loc n mod iterativ n metodologiile
agile. O SDA clasic este de obicei mprit la nivel nalt n fazele de
analiz, proiectare, implementare, testare i apoi aciuni de desfurare
(engl. deployment). Fiecare din aceste faze este descompus mai apoi n
pachete de activiti (engl. work packages). Planificarea tradiional a
unui proiect este top-down i se bazeaz pe elaborarea de activiti detaliate
cu estimri i dependene care ghideaz graficul de lucru al proiectului cu
ajutorul analizei drumului critic. Totui, o descompunere excesiv poate
conduce la un efort de management neproductiv, la o utilizare inadecvat a
resurselor i la scderea eficienei de executare a lucrrilor.
n metodologiile agile aceste practici sunt abordate diferit. Se
definesc caracteristicile (engl. features) de nivel nalt ale produsului i
apoi acestea sunt alocate iteraiilor de lansare (engl. release). O iteraie
sau chiar o caracteristic poate fi considerat echivalentul agil al unui pachet
de activiti. Caracteristicile sunt estimate n linii generale, fr a se detalia
activitile sau resursele asociate. Cnd ncepe o iteraie, caracteristicile
alocate (i numai acestea) sunt descompuse pe activiti care reprezint
planul de dezvoltare. n acest mod se previne acumularea unor cerine
detaliate care s-ar putea s nu trebuiasc implementate niciodat. Durata
scurt a unei iteraii mbuntete capacitile de planificare i control i
reduce numrul de detalii i complexitatea estimrilor. Abordarea agil
pleac de la premisa c vor aprea schimbri dese ale cerinelor i deci c nu
trebuie realizat o descompunere detaliat pe activiti pn n momentul n
care se poate ncepe lucrul efectiv la o caracteristic.
Tabelul 4.1 prezint o comparaie ntre abordarea clasic i cea agil
n privina definirii domeniului, care n proiectele agile se numete
planificare multinivel.
64
Tabelul 4.1. Definirea domeniului

Abordarea clasic
Pregtirea unui document de Specificare
a Domeniului Proiectului, care include
elemente precum: obiectivele i limitele
proiectului, descrierea domeniului
Definirea punctelor de referin (engl.

milestones) i a livrabilelor
proiectului
Specificaiile produsului i criteriile de

acceptare / recepie
Presupuneri i constrngeri
Abordarea agil
Organizarea unei ntlniri pentru
definirea viziunii asupra produsului,
confirmarea i clarificarea obiectivelor,
limitelor i descrierea domeniului prin
exerciii precum enunul din lift (engl.
elevator pitch)
Organizarea unei ntlniri de planificare
a foii de parcurs (engl. roadmap) a
proiectului, precum i ntlniri (de
exemplu trimestriale) de planificare a
punctelor de referin i a livrabilelor la
nivel de iteraie
ntlnire de planificare a iteraiei cu
scopul stabilirii detaliilor fiecrei
caracteristici i a activitilor necesare
pentru terminarea acestora pe baza
criteriilor de finalizare ale echipei i a
criteriilor de acceptare ale clientului
Toate ntlnirile identific sau
revizuiesc presupunerile i
constrngerile
ntr-o prim faz, sunt eliminate din list cerinele asupra crora
toate prile interesate cad de acord c nu sunt necesare. S-ar putea s
trebuiasc eliminate n continuare unele cerine asupra crora nu exist un
consens, pe baza analizei de fezabilitate, a prioritilor i a importanei
prilor interesate. Cerinele rmase reprezint linia de baz (engl.
baseline) a domeniului proiectului. n general, este important
documentarea cerinelor care nu au fost implementate la un moment dat,
mpreun cu justificarea deciziei de neimplementare. Dac excluderea nu
este documentat adecvat, aceste cerine se pot rentoarce ulterior drept
cerine noi pe parcursul derulrii proiectului.
De asemenea, toate elementele din linia de baz a domeniului trebuie
clar definite. Trebuie s existe rezultate concrete, msurabile, care trebuie
ndeplinite. Acestea trebuie documentate mpreun cu criteriile de acceptare,
65
ca parte a definirii domeniului. Dac nu se ntmpl acest lucru, domeniul

nu poate fi verificat, iar clienii pot solicita mereu introducerea unor noi
cerine sau pot refuza produsul datorit unei interpretri diferite a
specificaiilor.
4.3. Crearea structurii de descompunere a

activitilor
Echipele proiectelor agile nu creeaz de obicei SDA formale, ci
folosesc table i flipchart-uri pentru a reprezenta descompunerea lucrului
(figurile 4.1 i 4.2). La sfritul planificrii pentru lansare, echivalentul agil
al unei SDA arat ca n figura 4.3. Rezultatele unei ntlniri de planificare a
iteraiei arat ca n figura 4.4.
Figura 4.1. Plan de lansare n metodologie agil
66
Figura 4.2. Plan de iteraie n metodologie agil
Figura 4.3. Rezultatele unei ntlniri de planificare a lansrii
67
Figura 4.4. Plan de iteraie parial

n privina descompunerii activitilor. n proiectele agile, SDA se regsete
n planul de lansare i n planul de iteraie.
Tabelul 4.2. Crearea SDA
Abordarea clasic
Crearea unei diagrame a SDA
Abordarea agil
ntlniri de planificare n care se confer
echipei responsabilitatea descompunerii
lucrului n pachete de activiti mai mici
4.4. Verificarea domeniului

Verificarea domeniului se realizeaz n cadrul iteraiei, clientul
putnd revizui, testa i accepta caracteristicile implementate. n mod ideal,
aceasta are loc pe parcursul iteraiei, dar poate avea loc i la sfritul
acesteia, la prezentarea (demonstrarea) codului. Caracteristicile
neimplementate, din lipsa timpului sau din cauza problemelor de
68
specificare, sunt reintroduse pe lista de cerine (engl. backlog) sau intr n

urmtoarea iteraie, conform deciziei clientului.
4.5. Controlul domeniului

n metodologiile agile, controlul domeniului const n:
gestionarea listei de cerine (backlog);

protejarea iteraiei.
Clientul gestioneaz lista de cerine iar managerul de proiect

protejeaz echipa i previne schimbrile de cerine din timpul unei iteraii.
Este important stabilirea corect a duratei unei iteraii, deoarece
clientul trebuie s atepte urmtoarea iteraie pentru a face modificri. Dac
cerinele de modificare sunt frecvente, ciclurile de iteraii pot fi scurtate.
Pot exista excepii; n urma discuiilor dintre client i managerul de
proiect, o iteraie poate fi oprit sau renceput, ns aceste situaii trebuie s
fie foarte rare.
n privina controlului domeniului.
Tabelul 4.3. Controlul domeniului
Abordarea clasic
Utilizarea unui sistem de control al
modificrilor
Abordarea agil
Clientul gestioneaz lista de cerine a
produsului. Cnd echipa ncepe lucrul la
o iteraie, domeniul rmne blocat pe
parcursul ei
Echipa revizuiete planurile de lansare
i foaia de parcurs n mod regulat, ori
de cte ori este nevoie pentru a
surprinde progresul echipei i
modificrile solicitate de client
Actualizarea tuturor documentelor

potrivit modificrilor aprobate
69
4.6. Concluzii
Unul din motivele eecului proiectelor este lipsa identificrii clare a
livrabilelor care trebuie realizate. Fr stabilirea unei linii de baz a
domeniului, nici liniile de baz ale costului i graficului de lucru nu pot fi
precizate.
70
Capitolul 5
Managementul timpului
5.1. Introducere
Managementul timpului este utilizat pentru a asigura terminarea la
timp a unui proiect. Exist 5 procese principale necesare pentru a realiza un
management de timp eficient:
1. Definirea activitilor. Definirea activitilor specifice necesare
pentru a finaliza proiectul i pentru a produce toate livrabilele
acestuia;
2. Ordonarea activitilor. Identificarea interdependenelor dintre
activiti i a legturilor cu intrrile externe ale proiectului;
3. Estimarea duratei activitilor. Estimarea timpului necesar pentru
fiecare activitate;
4. Dezvoltarea graficului de lucru. Analizarea tuturor datelor
disponibile pentru a stabili graficul de lucru sau programarea
calendaristic (engl. schedule) potrivit() pentru proiect;
5. Controlul graficului de lucru. Controlul modificrilor care au loc n
proiect i care afecteaz graficul de lucru al acestuia.
5.2. Definirea activitilor

Principalul instrument necesar pentru definirea activitilor, precum
i pentru determinarea duratei i succesiunii acestora este Structura de
Descompunere a Activitilor (engl. Work Breakdown Structure). Metoda
este utilizat pentru a descompune proiectul n sub-proiecte mai uor de
gestionat. SDA definete nivelul de control cel mai de jos pe care trebuie
s-l gestioneze managerul de proiect: nivelul pachetului de activiti (engl.

work package). Din punctul de vedere al managerului unui sub-proiect, un

pachet de activiti poate fi mprit la rndul su pn la nivel de activitate
sau sarcin individual.
5.3. Ordonarea activitilor

n faza de dezvoltare a SDA, se verific dac fiecare activitate are
intrri corespunztoare pentru lucrul aferent. Fiecare ieire a unei activiti
trebuie s fie utilizat de o alt activitate sau s fie parte a unui livrabil al
proiectului.
Dependenele dintre activiti pot fi:
obligatorii: definite de natura proiectului. De exemplu, testarea de

tip cutie alb nu poate fi fcut dect dup implementare;
discreionare: definite de management. Rezult de obicei din bunele
practici n domeniu, de exemplu aplicarea unei metodologii de
dezvoltare software. Trebuie s fie bine documentate deoarece
limiteaz deciziile ulterioare de planificare;
externe: definite din afara proiectului. De exemplu, testarea poate
depinde de livrarea unor componente hardware dintr-o surs extern.
5.3.1. Metoda diagramei de preceden
Diagrama de preceden conine noduri reprezentate ca nite

dreptunghiuri, cu orice informaii necesare despre activiti, precum
numrul curent, descrierea, data de ncepere i terminare, durata etc.
Activitile sunt conectate prin sgei care precizeaz relaiile logice ale
graficului de lucru. Captul sgeii indic activitatea dependent. Sunt
posibile 4 relaii logice: sfrit-nceput (FS), nceput-nceput (SS), sfritsfrit (FF), nceput-sfrit (SF).
72
Figura 5.1. Diagram de preceden
Sfrit-nceput (Finish-to-start, FS)

O relaie sfrit-nceput reprezint cel mai des ntlnit tip de
dependen. n cadrul unei astfel de relaii, activitatea succesoare poate
ncepe doar dup terminarea activitii predecesoare. De exemplu:
Un raport trebuie scris nainte s poat fi publicat;

O persoan trebuie s aib un calculator nainte s-i poat instala
programele de care are nevoie.
nceput-sfrit (Start-to-finish, SF)
n relaia nceput-sfrit, activitatea succesoare se poate termina doar

nainte de nceperea activitii predecesoare. De exemplu:
Angajaii pot ncepe s foloseasc o nou procedur numai dup ce

au terminat pregtirea profesional pentru aceasta. n cazul n care
utilizarea noii proceduri este ntrziat, se dorete de asemenea
ntrzierea pregtirii, astfel nct aceasta s aib loc ct mai trziu
posibil nainte de punerea n aplicare. Acest exemplu de relaie
nceput-sfrit nu se poate considera ca o relaie sfrit-nceput.
Ideea este de a nu permite niciun fel de ntrziere ntre pregtire i
73
aplicare. Dac noua procedur poate ncepe doar dup ce se termin

pregtirea (relaie sfrit-nceput), noua procedur poate ncepe n
orice moment ulterior ncheierii pregtirii, n funcie de modul n
care alte relaii o pot ntrzia. Dac activitatea de pregtire trebuie s
se termine chiar nainte de nceperea celeilalte activiti, ntrzierile
activitii ulterioare (de punere n aplicare) ntrzie de asemenea i
activitatea anterioar;
Schimbul 2 ncepe cnd se termin schimbul 1. Dar nu poate exista o
perioad ntre cele dou schimburi n care nu lucreaz nimeni. Dac
nceputul schimbului 2 ntrzie, trebuie s ntrzie i sfritul
schimbului 1.
Figura 5.2. Comparaie ntre dependenele nceput-sfrit (Start-to-finish)

i Sfrit-nceput (Finish-to-start)
nceput-nceput (Start-to-start, SS)

ntr-o relaie nceput-nceput, activitatea succesoare poate ncepe
doar n momentul n care ncepe activitatea predecesoare. De exemplu:
74
Cnd ncep s se primeasc rezultatele unor alegeri, se poate ncepe

centralizarea lor;
Cnd ncepe lucrul la un proiect, ncep i activitile de management.
Sau activitile de management ncep cu n zile nainte de nceperea
lucrului la proiect. Activitile de management i cele de lucru
efectiv se desfoar apoi n paralel o perioad de timp.
Sfrit-sfrit (Finish-to-finish, FF)
ntr-o dependen sfrit-sfrit, activitatea succesoare se poate

termina doar cnd se termin activitatea predecesoare. De exemplu:
Se termin instalarea calculatoarelor n acelai moment cu

terminarea mutrii angajailor ntr-o cldire nou, astfel nct
angajaii s poat folosi calculatoarele imediat;
Dou divizii trebuie s termine retehnologizarea liniilor lor de
producie n aceeai zi astfel nct directorul s le poat inspecta pe
amndou.
75
5.4. Estimarea duratei activitilor i proiectului

5.4.1. Metoda drumului critic
Este un algoritm pentru planificarea unei mulimi de activiti. Se
calculeaz datele cnd se pot termina unele activiti cel mai trziu fr a
ntrzia proiectul precum i calea cea mai lung a activitilor planificate
pn la sfritul proiectului. Acest proces determin ce activiti sunt critice
(de exemplu, pe calea cea mai lung) i ce activiti au perioade de
inactivitate sau decalaj, adic pot fi amnate fr a face proiectul mai lung.
Drumul critic este succesiunea de activiti cu durata total cea mai mare,
care determin i cel mai scurt timp posibil pentru a finaliza proiectul. Orice
ntrziere a unei activiti de pe drumul critic afecteaz direct data de
terminare a proiectului.
Spre deosebire de costul total al proiectului, n care se sumeaz
costurile tuturor activitilor, durata proiectului este dat de suma duratelor
activitilor aflate numai pe drumul critic.
5.4.2. Metoda PERT
Tehnica de evaluare i examinare a programelor (engl. Program
Evaluation and Review Technique, PERT) a fost dezvoltat pentru analiza
proiectelor n care exist incertitudine asupra duratei activitilor. Multe
fenomene naturale sunt modelate bine de distribuia normal (figura 5.3).
Pentru activitile specifice proiectelor, s-a constat c distribuia beta (figura
5.4) este mai potrivit, dar distribuia normal rmne suficient de bun din
punct de vedere practic.
76
Figura 5.3. Distribuia de probabilitate normal (gaussian)
77
Figura 5.4. Distribuia de probabilitate beta
78
O aproximare a acestor dou distribuii este dat de analiza a trei

estimri formulate de un expert: o valoare optimist, una probabil i una
pesimist. Valoarea ateptat a duratei se calculeaz ca o medie ponderat a
acestora:
VA
VO 4VProb VP
6
Deviaia standard este:
VP VO
6
Conform regulii 3 sigma, sau regulii 68 - 95 - 99,7, dac vom

considera c o probabilitate de 95% este suficient pentru estimarea duratei,
durata ateptat este de 100 de zile i deviaia standard este de 5 zile, putem
spune c proiectul are 95% anse s fie terminat ntre 90 i 110 zile.
5.4.3. Simularea Monte Carlo
Metoda PERT face o presupunere problematic, aceea c drumul
critic va conine ntotdeauna aceeai mulime de activiti. ns, n funcie de
duratele reale, este posibil ca activitile de pe drumul critic s se modifice,
afectnd data de terminare estimat a proiectului.
ntr-o simulare Monte Carlo, durata fiecrei activiti are asociat o
distribuie de probabilitate. Se realizeaz un numr mare de simulri i se
determin o distribuie de probabilitate pentru data de terminare a
proiectului. Acest rezultat este de obicei prezentat ca o histogram sau ca o
probabilitate cumulativ ca proiectul s fie terminat naintea unei date
anume. Datorit modificrii drumului critic, este posibil ca unele date de la
nceputul i sfritul intervalului s fie mai probabile, cu date mai puin
probabile ntre ele.
Prin simulri se poate obine i indexul de criticalitate al
activitilor, care reprezint procentul din simulri n care o activitate este pe
drumul critic. De exemplu, dac sunt realizate 1000 de simulri i n 212
79
dintre acestea o activitate este pe drumul critic, indexul su de criticalitate

este de 21,2%.
5.5. Considerente practice ale planificrii

5.5.1. Scopurile planificrii
Toate planificrile au trei scopuri principale, indiferent dac este
vorba de o petrecere n week-end sau de actualizarea unui site web:
1. Primul i cel mai bine cunoscut este de a crea angajamente asupra
momentului cnd vor fi fcute anumite activiti. Graficul de lucru
ofer o form de contract pentru fiecare persoan din echip,
confirmnd ceea ce trebuie livrat sau realizat n urmtoarele zile,
sptmni sau luni;
2. Al doilea scop al planificrii este ncurajarea tuturor celor care
contribuie la proiect s i vad eforturile ca parte a unui ntreg i s
se strduiasc ca prile proprii s se mbine cu ale altora. Ct
vreme nu exist o prim variant a unui grafic de lucru care s
specifice datele cnd activitile trebuie finalizate, toat lumea va
lucra pe cont propriu, fr s se gndeasc cum rezultatele proprii i
vor afecta pe ceilali. Cnd exist un grafic de lucru, se pot pune
ntrebri asupra realismului unor cerine i se pot face comparaii
ntre ce se dorete s realizeze proiectul i ce pare s fie posibil ntro anumit perioad de timp. O funcie de forare (engl. forcing
function) este orice eveniment care determin o schimbare n
perspectiv, atitudine sau comportament. Planificrile sunt funcii de
forare importante pentru proiect. Chiar dac graficul de lucru nu se
respect, se mrete sau trece prin multe alte modificri,
angajamentele i conexiunile fcute de persoanele din echip se vor
pstra;
3. Al treilea scop al planificrii este de a oferi echipei un instrument
pentru monitorizarea progresului i pentru descompunerea
volumului de lucru n elemente gestionabile. Descompunerea n
80
activiti cu durata de 1 sau 2 zile i ajut pe oameni s neleag mai

bine ce trebuie s fac.
Cu ct este mai mare i mai complex un proiect, cu att este mai
important planificarea. n proiectele mari exist mai multe dependene ntre
oameni, iar deciziile i sincronizrile au anse mai mari s i afecteze pe
ceilali. Dac apare o ntrziere de o zi la o echip mic, aceasta se poate
recupera: o persoan lucreaz peste program ntr-o zi sau ntreaga echip i
redistribuie sarcinile pentru a compensa ntrzierea. ntr-un proiect mai
mare, cu sute de persoane, o ntrziere de o zi poate provoca un efect n
cascad i creeaz probleme dincolo de capacitatea unei singure echipe de a
le recupera.
Planurile perfecte nu rezolv toate problemele pe care le au
proiectele. Un plan nu poate remedia proiectarea sau practicile inginereti
greite i nici nu poate proteja proiectul de o conducere slab, obiective
neclare i comunicare deficitar. Pn la urm, cineva trebuie s foloseasc
planurile ca un instrument de gestionare i conducere a proiectului.
5.5.2. Calitatea estimrilor
Planificrile sunt doar nite predicii. Orict de minuioase sau
convingtoare ar arta, ele reprezint sumarea unui numr mare de estimri
mrunte, fiecare activitate fiind predispus la apariia unor diverse
probleme. Planificrile de calitate sunt realizate numai de managerii care au
cunotine detaliate despre ntreg procesul de dezvoltare software.
O planificare nu trebuie s fie perfect, trebuie s fie doar suficient
de bun pentru ca echipa s cread n ea, s asigure o baz pentru
monitorizare i realizarea ajustrilor i s aib o probabilitate de succes care
satisface clientul sau sponsorul proiectului.
Estimrile bune se realizeaz doar pentru cerine i proiecte credibile
i sunt posibile doar dac exist dou lucruri: informaii bune i ingineri
buni.
Dac managerii admit estimri mai puin exacte i deci un risc mai
mare al planificrii, atunci aceste estimri sunt acceptabile. Pentru proiecte
mici i de scurt durat, astfel de estimri sunt suficiente. Cerinele se pot
schimba des, iar natura organizaiei poate cere o structur mai flexibil. Nu
81
e nimic n neregul cu estimrile de o calitate slab atta timp ct nimeni nu

le confund cu unele de calitate ridicat.
n continuare vom prezenta cteva modaliti suplimentare pentru a
asigura estimri bune:
1. Stabilirea unor intervale de ncredere pentru estimri: o
presupunere 40%, o estimare bun 70%, o analiz detaliat
90%;
2. Programatorii efi trebuie s stabileasc standardul de calitate
pentru estimri, conform nevoilor echipei;
3. Programatorii trebuie crezui. Presiunile trebuie aplicate doar ca o
msur de echilibrare: programatorii tind s dea estimri mai mari
pentru sarcinile care nu le plac i estimri mai mici pentru cele care
le plac. Uneori sunt utile estimri multiple, de la doi dezvoltatori
diferii;
4. Estimrile depind de nelegerea scopurilor proiectului. Estimrile
nu depind numai de interpretarea specificaiilor de ctre
programatori, ci i de scopurile de nivel nalt ale proiectului;
5. Estimrile trebuie s se bazeze pe experiena anterioar.
5.5.3. Omisiunile frecvente
Riscurile cele mai mari ale unei planificri apar din lucrurile
nescrise, de exemplu dac un membru important al echipei se mbolnvete
sau pleac n concediu.
Urmtoarea list de ntrebri poate ajuta la detectarea din timp a
unor probleme de planificare:
1. Au fost incluse ntr-o anumit form n graficul de lucru zilele de
concediu de odihn sau medical?
2. Au acces membrii echipei la graficul de lucru i li se cere s
raporteze progresul n mod regulat?
3. Exist cineva care s monitorizeze graficul general de lucru, zilnic
sau sptmnal? Are acea persoan suficient autoritate pentru a
pune ntrebri sau a face corecii?
82
4. A contribuit echipa la definirea planului de lucru sau acesta a fost

realizat la un nivel superior? Echipa simte c este parte a
planificrii?
5. Au fost ncurajai i sprijinii membrii echipei s refuze noi sarcini
de lucru care nu se ncadreaz n viziunea i obiectivele proiectului?
6. Graficul de lucru presupune mai puine ore de munc efectiv n
perioada srbtorilor? De exemplu Crciunul i Patele sunt perioade
cu productivitate mai sczut.
O scpare de la nceputul procesului care va fi descoperit mai trziu
va avea un impact ramificat asupra proiectului. Dac echipa are o
probabilitate de 90% de a respecta graficul de lucru n fiecare sptmn, n
timp ansele nerespectrii planului cresc continuu.
5.5.4. Recomandri
Deoarece graficul de lucru este o imagine a ntregului proiect,
singura cale de a-l folosi n mod eficient este de a nelege tot ce trebuie s
se ntmple pentru a asigura succesul proiectului. Este o sarcin
interdisciplinar, nu doar o activitate de inginerie sau de management.
1. Lungimea punctelor de referin trebuie s se potriveasc cu
volatilitatea proiectului. Cu ct se ateapt mai multe schimbri, cu
att punctele de referin (engl. milestones) trebuie s fie mai
apropiate;
2. Trebuie planificate ntlniri sau discuii privind adugarea sau
eliminarea de funcionaliti;
3. Trebuie evaluat experiena echipei n domeniul problemei curente;
4. Trebuie evaluat experiena i ncrederea echipei privind lucrul
mpreun. Chiar i o echip de programatori experimentai nu va fi
att de eficient dac membrii echipei nu au lucrat mpreun nainte;
5. Riscurile trebuie gestionate ct mai devreme. Cu ct este mai mare
riscul, cu att mai mult timp va fi necesar pentru gestionarea sa.
Dac riscurile sunt gestionate trziu, vor exista mai puine grade de
libertate pentru a le rspunde adecvat. Acelai lucru se recomand
pentru riscurile politice, organizaionale sau legate de resurse.
83
5.6. Concluzii
Managementul timpului unui proiect presupune planificarea de baz
crearea graficului de lucru. Structura de Descompunere a Activitilor
furnizeaz activitile individuale care trebuie planificate. Duratele
activitilor sunt determinate prin procesul de estimare.
Metoda drumului critic eficientizeaz managementul de proiect prin
concentrarea mai mare a efortului asupra activitilor fr perioade de
inactivitate. Metoda PERT realizeaz o aproximare statistic a datei de
terminare a proiectului prin ponderarea a trei estimri: una optimist, una
probabil i una pesimist. Simularea Monte Carlo este o metod stohastic
utilizat pentru a evita problemele de estimare cnd activitile de pe drumul
critic variaz.
Au fost discutate trei scopuri ale planificrii, au fost introduse o serie
de ntrebri utile pentru a asigura estimri de calitate i pentru a evita
omisiunile frecvente ntlnite n realizarea planificrilor i au fost precizate
cteva recomandri pentru minimizarea riscurilor i pentru maximizarea
beneficiilor planificrii.
84
Capitolul 6
Managementul costului
6.1. Introducere
La construirea unei case, la decorarea unei bi sau a unei grdini,
dorim s cunoatem costul precis al operaiilor ce urmeaz a fi efectuate
nainte de nceperea acestora. Un grdinar este capabil s fac o aproximare
a costurilor bazndu-se, de exemplu, pe tipul pmntului, mrimea dorit a
terasei sau a zonei cu iarb, prezena sau absena unui iaz i pe alte
informaii similare. Apoi aceast estimare poate fi fcut mai precis printrun dialog ulterior nainte de a se ncepe lucrrile.
Estimarea costurilor unei aplicaii software reprezint un domeniu
mai puin formalizat, care se bazeaz mai mult pe aproximri. Exist totui o
serie de metode care permit estimarea costului total pentru un proiect
software pe baza unui numr limitat de generatori relevani de costuri.
n cele mai multe modele de estimare, este presupus o relaie simpl
ntre cost i efort. Efortul poate fi msurat de exemplu n luni-om (adic
numrul estimativ de luni necesar unui singur om s realizeze lucrarea), i
fiecrei luni-om i se asociaz o sum fix de bani, corespunztor salariului
angajailor. Costul total estimat se obine nmulind numrul estimat de luniom cu factorul constant considerat.
Noiunea de cost total reprezint de obicei costul efortului iniial de
dezvoltare software, costul analizei cerinelor, proiectrii, implementrii i
testrii, fr a fi luate n considerare costurile de ntreinere. Noiunea de
cost, care se va folosi n continuare, nu include i posibilele costuri
hardware, ci numai costurile legate de personalul angajat n dezvoltarea
produsului software.

6.2. Metode de estimare

Cercetrile n domeniul estimrii costului sunt departe de a fi
cristalizate. Diferite modele folosesc diferite sisteme de msur i generatori
de costuri, nct este dificil compararea lor. S presupunem c un model
folosete o ecuaie de forma: E 2,7 KLOC1,05 . Aceast ecuaie arat o
relaie ntre efortul necesar i mrimea produsului (KLOC = Kilo-Lines Of
Code, kilo-linii de cod). Unitatea de msur a efortului poate fi numrul de
luni-om necesare.
Apar aici mai multe ntrebri. Ce este o linie de cod? Numrm
codul main sau codul surs ntr-un limbaj de nivel nalt? Numrm de
asemenea i comentariile, liniile libere care mresc vizibilitatea sau nu?
Lum n considerare i zilele libere, vacanele, concediile medicale n
noiunea de luni-om sau se refer numai la o msurare net? Diferite
interpretri ale acestor ntrebri pot conduce la rezultate complet diferite.
Uneori nici nu este cunoscut ce definiii au fost folosite n aplicarea
modelului.
n mod ideal, mrimea ar trebui s se refere doar la codul propriuzis, fr linii albe i comentarii, ns pentru proiecte de dimensiuni mari,
este mai simplu s se numere direct toate liniile.
Pentru a determina ecuaiile unui model algoritmic de estimare a
costului, putem urma diferite abordri. n primul rnd ne putem baza ecuaia
pe rezultatul experimentelor. ntr-un asemenea experiment, n general
variem un parametru, n timp ce ceilali parametri rmn constani. n acest
fel ncercm s determinm influena pe care o are parametrul care variaz.
Un exemplu tipic este cel ce testeaz dac comentariile ajut la nelegerea
unui program. Vom pune un numr de ntrebri despre acelai program unor
programatori mprii n dou grupuri. Primul grup va primi programul fr
comentarii, iar al doilea grup va primi textul aceluiai program, dar
comentat. Folosind rezultatele celor dou grupuri, putem testa ipoteza
realist c o nelegere mai bun i mai rapid a programului are efecte
pozitive asupra ntreinerii programului.
O alt modalitate de a descoperi modele algoritmice de estimare a
costului se bazeaz pe o analiz a datelor unui proiect real, dar i pe un
suport teoretic. O organizaie poate strnge date despre un numr de sisteme
86
software care au fost dezvoltate. Aceste date pot privi timpul petrecut la
diferite faze bine determinate, calificarea personalului implicat, momentele
de timp n care au aprut erori, att n timpul testrii ct i dup instalare,
complexitatea, robusteea i ali factori importani ai proiectului, mrimea
diferitelor entiti implicate i o analiz statistic a acestor date. Un exemplu
pentru o asemenea relaie este cea dat mai sus, ce exprim o legtur ntre
E i KLOC. Aplicabilitatea i corectitudinea acestor ecuaii este, n mod
evident, dependent de corectitudinea datelor pe care se bazeaz.
Rezultatele obinute n acest fel reprezint o medie, o aproximare
bazat pe datele disponibile, de aceea rezultatele obinute trebuie aplicate cu
atenie. De exemplu, programul ce urmeaz a fi dezvoltat n cadrul unui nou
proiect nu se poate compara cu produse anterioare datorit inovaiilor
implicate. Estimarea costurilor pentru un proiect legat de o navet spaial
nu poate fi fcut printr-o simpl extrapolare a proiectelor anterioare.
Trebuie reinut c aplicarea oarb a unor formule din modelele
existente nu va rezolva problema estimrii costului. Fiecare model necesit
o adaptare la mediul n care va fi folosit. Aceasta conduce la necesitatea
colectrii continue a datelor din propriul proiect i aplicarea unor metode
statistice pentru a calibra parametrii modelului.
Neconcordanele dintre diferitele modele mai pot aprea deoarece:
Majoritatea modelelor ofer o relaie ntre numrul lunilor-om

necesare i mrimea produsului n linii de cod. Pot exista ns mai
multe interpretri diferite pentru aceste noiuni;
Efortul nu nseamn ntotdeauna acelai lucru. Uneori se consider
activitile de dezvoltare pornind de la conceperea produsului, dup
ce au fost fixate cerinele. Alteori se includ i eforturile de
ntreinere.
Cu toate acestea, modelele de estimare a costului au multe

caracteristici comune. Acestea reflect importana factorilor care intervin
asupra costului de dezvoltare i efortului. Creterea nelegerii costurilor
produselor software ne permite s identificm strategii de cretere a
productivitii, cele mai importante fiind:
87
Scrierea de mai puin cod: Mrimea sistemului este una din cauzele
principale ale efortului i costului. Prin metode care ncearc s
reduc mrimea, cum ar fi utilizarea de limbaje de nivel nalt,
reutilizarea componentelor sau refactorizarea, se pot obine reduceri
semnificative;
Stimularea oamenilor s lucreze la capacitatea maxim: Capacitatea
de a lucra att individual ct i n echip are un mare impact asupra
productivitii. Angajarea celor mai buni oameni este de obicei o
afacere profitabil. O mai bun stimulare, condiii mai bune de lucru,
cursurile de perfecionare asigur oportuniti de cretere a
productivitii;
Evitarea rescrierii componentelor dezvoltate anterior: Studiile au
artat c pentru a rescrie ceea ce s-a produs deja este necesar un efort
considerabil. Prin aplicarea unor tehnici precum prototipizarea, se
pot reduce semnificativ costurile;
Dezvoltarea i folosirea mediilor de dezvoltare integrate, cu
instrumentele ce pot ajuta la eliminarea sau eficientizarea unor etape.
Numeroase studii au fost efectuate cu scopul de a estima efortul

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

n2 = numrul de operanzi diferii;
N1 = numrul total de apariii ale operatorilor;
N2 = numrul total de apariii ale operanzilor;
Relaiile modelului Halstead sunt urmtoarele:
Vocabularul: n = n1 + n2
Lungimea implementrii: N = N1 + N2
Ecuaia lungimii: N' = n1log2n1 + n2log2n2
Volumul programului: V = N log2n
n N
Dificultatea: D 1 2
2 n2
Efortul: E D V
Astfel se obine o rafinare a msurii numrului de linii simple de

cod, LOC. Att LOC ct i N ofer o bun corelaie cu efortul de
programare. De aceea este important s se gseasc modaliti de estimare a
acestora n primele etape ale implementrii. Valoarea lui N depinde de n1 i
n2. Valoarea lui n1 este, de cele mai multe ori, un factor constant pentru
programele scrise ntr-un anumit limbaj de nivel nalt i depinde de limbajul
de programare ales. De exemplu, pentru un limbaj dat, numrul maxim de
operatori care poate fi utilizat n orice program este fix: toi sunt prezentai
n sintaxa limbajului. Majoritatea programelor vor folosi un mare procent
din acestea, cel puin o dat. O ipotez consider c n2 este determinat n
principal de numrul de variabile (VARS) care apar n program. Bazndu-se
pe aceste presupuneri, a fost enunat urmtoarea relaie empiric:
LOC 102 5,31VARS
Astfel, fiecare program va conine aproximativ 100 de linii de cod,

plus 5 linii suplimentare pentru fiecare variabil ce apare n program.
Primele experimente arat c n acest fel se pot obine aproximri destul de
corecte ale mrimii i efortului necesar. Valoarea estimat a lui VARS poate
89
fi obinut relativ devreme dac este folosit o metod de proiectare topdown n combinaie cu un limbaj de nivel nalt.
Generalizarea acestor rezultate la programe mai mari nu este
indicat. n programele mai complexe, factori precum interfaa dintre
componente i comunicarea necesar ntre persoanele implicate joac un rol
ce nu poate fi neglijat.
Cunoscnd mrimea estimat a unui proiect, suntem interesai n
continuare s evalum timpul de dezvoltare necesar. ntr-o abordare naiv
am putea considera c un proiect ce necesit 60 de luni-om poate fi realizat
ntr-un an cu o echip de 5 persoane sau ntr-o lun cu o echip de 60 de
persoane. Aceast abordare este ns prea simplist. Un proiect de o anumit
dimensiune corespunde unei anumite perioade de timp fizic. Dac ncercm
s micorm prea mult acest timp nominal de dezvoltare, intrm ntr-o zon
imposibil, iar probabilitatea unui eec crete.
Costurile estimate au deseori o culoare politic, iar rezultatele sunt

determinate de argumente care nu au o natur tehnic. Motive tipice care
reflect aceste argumente non-tehnice sunt prezentate n exemplele
urmtoare:
Dac avem 12 luni pentru a finaliza o lucrare, ea va necesita 12 luni.

Acest motiv poate fi privit ca o variant a legii Parkinson: munca
ocup tot timpul disponibil;
90
Dac tim c a fost fcut o ofert de 100.000 de euro de ctre

concuren, noi vom face o ofert de 90.000 de euro (metoda
preului de ctig);
Dorim s ne promovm produsul la un anumit trg de tehnic de
calcul i din acest motiv programul trebuie scris i testat n
urmtoarele 9 luni, dei realizm c timpul este limitat;
Proiectul poate fi dezvoltat ntr-un an, dar eful nu ar accepta acest
termen. tim c termenul de 10 luni este acceptabil i atunci l
programm pentru 10 luni.
Aceste estimri pot avea efecte negative, dup cum s-a demonstrat
frecvent n istoria ingineriei programrii. Estimrile vor depinde mai mult
de argumentele politice ale prilor interesate dect de realitatea tehnic a
proiectului.
Pe de alt parte, simpla comparare a caracteristicilor unui proiect cu
un proiect precedent nu garanteaz o estimare corect a costului su. Dac o
echip lucreaz n mod repetat la proiecte asemntoare, timpul de lucru
necesar scade, datorit experienei acumulate. n 1968, unei echipe de
programatori i s-a cerut s dezvolte un compilator FORTRAN pentru trei
maini diferite. Efortul necesar pentru aceste trei proiecte este descris n
tabelul de mai jos:
Compilatorul Efortul (n luni-om)
1
72
2
36
3
14
Pentru estimarea costului se poate apela la serviciul unui expert, care

apeleaz la propria sa experien. Factori greu de cuantificat, precum
caracteristicile de personalitate sau unele caracteristici neobinuite ale
proiectului, pot fi astfel luai n considerare. n acest caz, calitatea estimrii
nu poate depi calitatea expertului.
Pentru o estimare mai precis se pot solicita mai muli experi.
Totui, dac un grup de persoane trebuie s gseasc mpreun o soluie, se
observ c unii membri ai grupului au un impact mai mare asupra
rezultatului dect ceilali. Unele persoane nu i exprim opinia sau sunt
91
impresionate de celelalte. Acest lucru poate avea un impact negativ asupra

rezultatului final. Pentru a anticipa acest efect negativ, putem folosi metoda
Delphi. n metoda Delphi, fiecare expert i expune opinia n scris. Un
moderator colecteaz estimrile obinute astfel i le redistribuie celorlali
experi. n acest proces nu sunt asociate numele experilor cu estimrile lor.
Fiecare expert pred apoi o nou estimare bazat pe informaiile primite de
la moderator. Procesul continu pn cnd se ajunge la un consens.
O alt metod pentru obinerea unei estimri mai bune se bazeaz pe
un expert care s realizeze mai multe estimri: o estimare optimist a, o
estimare realist m i o estimare pesimist b. Efortul ateptat va fi:
E
a 4m b
6
Aceast estimare este mai bun dect dac se consider numai media
aritmetic a lui a i b.
6.3. Modele algoritmice clasice

Nelson (1966) ofer un model liniar pentru estimarea efortului
necesar pentru un proiect de dezvoltare software. Modelele liniare au
urmtoarea form:
n
E a0 ai xi
i 1
Coeficienii ai sunt constante, iar xi reprezint factorii care au impact

asupra efortului necesar. Un numr mare de factori poate influena
productivitatea i implicit efortul. Analiznd cu atenie datele proiectelor
precedente i diferite combinaii de factori, se poate ncerca obinerea unui
model cu un numr mic de factori. Nelson, de exemplu, sugereaz un model
care ia n considerare 14 factori:
92
E 33,63 9,15x1 10,73x2 0,51x3 0,46 x4 0,40 x5 7,28 x6 21,45x7

13,5x8 12,35x9 58,82 x10 30,61x1129,55x12 0,54 x13 25,20 x14
n aceast ecuaie, E reprezint numrul estimat de luni-om necesare.

Semnificaia factorilor xi i domeniile lor de definiie sunt prezentate n
tabelul urmtor:
Factor
x1
x2
x3
x4
x5
x6
x7
x8
x9
x10
x11
x12
x13
x14
Descriere
Instabilitatea specificaiilor cerinelor
Instabilitatea proiectrii
Procentajul de instruciuni matematice
Procentajul de instruciuni I/O
Numrul subprogramelor
Utilizarea unui limbaj de nivel nalt
Aplicaie comercial
Program de sine stttor
Primul program pe aceast main
Dezvoltare concurent de hardware
Utilizarea dispozitivelor random-access
Maina gazd diferit de maina int
Numr de erori
Dezvoltare pentru o organizaie militar
Valori posibile
0-2
0-3
0-100
0-100
numr
0 (da) / 1 (nu)
0 (da) / 1 (nu)
0 (da) / 1 (nu)
1 (da) / 0 (nu)
1 (da) / 0 (nu)
1 (da) / 0 (nu)
1 (da) / 0 (nu)
numr
0 (da) / 1 (nu)
Putem face mai multe observaii asupra acestui model. De exemplu,

la dezvoltarea programelor pentru aplicaiile de aprare, n care programele
sunt ncorporate n maini diferite de maina gazd, cum ar fi programul de
control al zborului pentru rachete, factori precum x12 i x14 au cu siguran
un impact mare asupra costului. Un alt exemplu este creterea efortului
atunci cnd se folosete limbajul de asamblare n locul unui limbaj de nivel
nalt (x6).
n general modelele liniare nu funcioneaz foarte bine. Dei exist
un numr mare de factori care influeneaz productivitatea, este puin
probabil ca ei s intervin n mod independent i liniar. Trebuie atras
atenia asupra preciziei acestui tip de formul i asupra capcanei exprimat
n sloganul: exist trei tipuri de minciuni: minciuni mici, minciuni mari i
statistici. Formula lui Nelson este rezultatul analizei statistice a datelor unor
93
proiecte reale i trebuie interpretat ca atare, adic n termeni probabilistici.

Dac avem o estimare E, atunci efortul real R va verifica formula:
P((1 ) E R (1 ) E ) ,
S presupunem c = 0,2, = 0,9, iar estimarea este de 100 luniom. Semnificaia formulei este urmtoarea: probabilitatea ca proiectul s
necesite n realitate ntre 80 i 120 de luni-om este mai mare ca 90%.
Costurile estimate prin acest tip de model rezult ntr-un anumit
interval, rmnnd o probabilitate diferit de zero ca acesta s fie n afara
intervalului. Aplicabilitatea acestor estimri este puternic influenat de
mrimea intervalului i de probabilitatea ca valoarea real a costului s
aparin ntr-adevr acelui interval. n special pentru proiectele care necesit
efort mai mare, este bine s se considere valoarea superioar a intervalului
n care se afl costul, n locul valorii estimate.
O alt modalitate prin care un expert poate ajunge la o estimare a
costului este printr-un proces bottom-up. Pentru fiecare modul, se obine un
cost estimativ iar costul final este suma costurilor modulelor, cu o corecie
aplicat datorit integrrii modulelor.
Wolverton descrie un model n care o matrice de costuri este folosit
ca punct de plecare n determinarea costurilor modulelor. n aceast matrice
exist un numr limitat de tipuri diferite de module i un numr de niveluri
de complexitate. Tabelul urmtor ilustreaz o matrice ipotetic de costuri.
Elementele matricei reflect costul pentru fiecare linie de cod.
Complexitate
Tipul modulului
1. Management de date
2. Management de memorie
3. Algoritm
4. Interfa utilizator
5. Control
Mic
1
11
25
6
13
20
2
13
26
8
16
25
3
15
27
14
19
30
4
18
29
27
23
35
94
Mare
5
22
32
51
29
40
Fiind date o matrice de costuri C, un modul de tip i, complexitate j i

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

n seciunile anterioare am remarcat faptul c efortul de programare
este corelat cu mrimea programului. Exist i modele neliniare care
exprim aceast legtur. O form general este:
E (a b KLOCc ) f ( x1 ,..., xn ) ,
unde KLOC reprezint mrimea programului n kilo-linii de cod, iar E

reprezint efortul n luni-om. a, b i c sunt constante iar f ( x1 ,..., xn ) este o
funcie care depinde de valorile factorilor x1 ,..., xn .
n general, formula de baz este:
E a b KLOCc
Aceasta este obinut printr-o analiz de regresie a datelor

proiectelor disponibile. Primul generator de cost este mrimea programului,
msurat n linii de cod. Acest cost nominal estimat este apoi adaptat pentru
un numr de factori care influeneaz productivitatea (generatorii de cost
secundari). De exemplu, dac unul din factorii folosii reprezint
experiena echipei de programatori aceasta poate cauza o corecie a
costului nominal estimat cu 1,50, 1,20, 1,00, 0,80, 0,60 pentru un nivel de
expertiz foarte sczut, sczut, mediu, nalt i respectiv foarte nalt.
95
Tabelul urmtor conine formulele de baz pentru relaia dintre

mrimea programului i efort. Din motivele enunate anterior este dificil s
comparm aceste modele. Este interesant de observat c valoarea lui c
variaz n jurul valorii de 1 n toate modelele.
Autor
Formula
Halstead
E 0,7 KLOC 1,50
Boehm
E 2,4 KLOC 1,05
Walston-Felix
E 5,2 KLOC 0,91
Cnd c < 1, se remarc apariia unui fenomen foarte bine cunoscut

din teoria economic. Pentru producia de mas, se presupune c este mai
ieftin s se produc mari cantiti din acelai produs. Costurile fixe vor fi
mprite astfel unui numr mai mare de uniti, ceea ce conduce la scderea
costului pe unitate. n cazul programelor, liniile de cod sunt produsul, deci
presupunem c producnd multe linii de cod, scade costul pe linie de cod.
Motivul este costul instrumentelor scumpe precum mediile de dezvoltare,
instrumentele de testare sau generatoarele de programe, care poate fi
distribuit unui numr mai mare de linii de cod.
n cazul opus, cnd c > 1, observm c dup un anumit punct,
producerea de uniti suplimentare implic nite costuri suplimentare.
Programele foarte mari sunt mult mai scumpe, deoarece crete necesitatea
de comunicare i de control managerial, iar problemele i interfeele sunt
mai complexe. Deci fiecare linie de cod suplimentar necesit mai mult
efort.
Al doilea tip de relaii (c > 1) pare mai plauzibil. Pentru proiecte
foarte mari, efortul crete mai mult dect liniar cu mrimea. Alegerea unui
anumit model depinde n principal de gradul de complexitate a interfarii
modulelor proiectului.
Este evident c valoarea exponentului c influeneaz foarte mult
valoarea calculat E, n special pentru valori mari ale KLOC. Tabelul
urmtor prezint valorile lui E, calculate prin metodele prezentate anterior i
pentru cteva valori ale KLOC. Se remarc marea diferen dintre modele.
Pentru programe mici, prin metoda Halstead rezult costuri estimate mici.
Pentru proiecte cu aproximativ un milion de linii de cod, acelai model
96
genereaz estimri ale costului cu un ordin de mrime mai mari dect prin
aplicarea metodei Walston-Felix.
KLOC Halstead Boehm Walston-Felix
0,7
2,4
5,2
1
22,1
26,9
42,3
10
247,5
145,9
182,8
50
700
302,1
343,6
100
22135,9 3390,1
2792,6
1000
Aceste observaii nu trebuie s ne conduc la concluzia c aceste

metode sunt inutile. Exist diferene mari ntre caracteristicile mulimilor de
proiecte pe care se bazeaz diferite modele. tim c numerele utilizate n
modele provin n urma analizei datelor proiectelor reale. Dac aceste date
reflect diferite proiecte i/sau medii de dezvoltare, modelele se vor
comporta la fel. Nu putem copia pur i simplu aceste formule. Fiecare mediu
are caracteristicile sale proprii i este deci necesar adaptarea parametrilor la
mediul specific, proces numit calibrare.
Cea mai important problem este obinerea unei estimri iniiale a
mrimii programului. Cum am putea s estimm numrul de pagini ale unui
roman care nu a fost scris nc? Chiar dac tim numrul de personaje, de
locaii i intervalul n care se va desfura povestea, este dificil estimarea
realist a mrimii nc de la nceput. Cu ct naintm n realizarea
proiectului, cu att va fi mai exact estimarea mrimii. Dac proiectarea se
apropie de final, ne putem forma o impresie rezonabil asupra mrimii
programului rezultat. Dar numai cnd sistemul va fi predat vom cunoate
valoarea exact.
6.4.1. Modelul Walston-Felix
Ecuaia ce st la baza modelului Walston-Felix (1977) este:
E 5,2 KLOC0,91 . Modelul a fost creat prin analiza a 60 de proiecte de la
IBM. Aceste proiecte erau complet diferite ca mrime, iar programele au
fost scrise n mai multe limbaje de programare. Totui nu reprezint o
97
surpriz faptul c dac aplicm acest model chiar unei submulimi a celor 60
de proiecte, nu vom avea rezultate satisfctoare.
ncercnd s explice aceste rezultate dintr-o plaj mare de valori,
autorii au identificat 29 de variabile care influeneaz n mod sigur
productivitatea. Pentru fiecare din aceste variabile au fost considerate trei
niveluri: mare, mediu i mic. Pentru un numr de 51 de proiecte, Walston i
Felix au determinat nivelul fiecrei variabile din cele 29, mpreun cu
productivitatea obinut, exprimat ca numr de linii de cod pe lun-om.
Aceste rezultate sunt prezentate n tabelul urmtor pentru cteva din cele
mai importante variabile. De exemplu, productivitatea medie este de 500 de
linii de cod pe lun-om pentru proiecte cu o interfa utilizator de
complexitate sczut. Pentru o interfa de complexitate nalt sau medie,
productivitatea este de 295 i respectiv 124 de linii de cod pe lun. Ultima
coloan reprezint variaia productivitii, PC (engl. productivity change),
diferena dintre valorile maxime i minime.
Variabila
Complexitatea interfeei utilizator
Calificarea i experiena
personalului
Experien anterioar cu aplicaii
similare
Procentajul de programatori
participani n faza de proiectare
Raportul dintre mrimea medie a
echipei i durata proiectului
(persoane/lun)
Productivitatea medie pentru

valoarea variabilei
< normal
normal
> normal
500
295
124
mic
medie
mare
132
257
410
minim
medie
vast
146
221
410
< 25%
25 50%
> 50%
153
242
391
< 0,5
305
0,5 0,9
310
> 0,9
171
PC
376
278
264
238
134
Walston i Felix consider c indexul productivitii I poare fi

determinat pentru noile proiecte dup urmtoarea relaie:
29
I Wi X i ,
i 1
98
unde ponderile Wi sunt definite astfel:
Wi 0,5 log10 ( PCi ) .

n relaia de mai sus, PCi reprezint variaia productivitii
factorului i. Pentru primul factor din tabelul de mai sus, complexitatea
interfeei cu utilizatorul, rezult urmtoarele: PC1 376 , deci W1 1,29 .
Variabilele X i pot lua valorile 1, 0 i 1, unde factorul corespunztor este
de nivel sczut, mediu sau nalt. Indexul productivitii obinut poate fi
tradus ntr-o productivitate ateptat: linii de cod scrise pe lun-om.
Modelul pleac de la ecuaia de baz E 5,2 KLOC0,91
i folosete I pentru a ajusta estimrile.
Numrul factorilor luai n considerare n acest model este destul de
ridicat: 29 de factori din 51 de proiecte. De asemenea, nu este clar cum
aceti factori se influeneaz unul pe cellalt. Un alt dezavantaj ar fi c
numrul de alternative pentru fiecare factor este de numai 3 i nu ofer
destule opiuni pentru situaiile practice.
6.4.2. Modelul COCOMO
COCOMO (engl. COnstructive COst MOdel) este una dintre cele
mai bine documentate metode de estimare a costului (Boehm, 1981). n
forma sa cea mai simpl, numit Basic COCOMO, formula care exprim
legtura dintre efort i mrimea programului este:
E b KLOCc ,
unde b i c sunt constante ce depind de tipul proiectului executat.

Boehm distinge trei clase de proiecte:
Organice: n proiectele de tip organic o echip relativ mic dezvolt

produsul ntr-un mediu cunoscut. Persoanele implicate au n general
experien n proiecte similare realizate n organizaia lor. Astfel, ei
99
pot s lucreze de la nceput, nefiind necesare investiii iniiale.

Proiectele de acest tip sunt de multe ori programe relativ mici;
Integrate: Proiectele de acest tip implic sisteme unde mediul
impune constrngeri severe. Produsul va fi integrat ntr-un mediu
foarte strict. Exemple de asemenea proiecte sunt programele de
control al traficului aerian sau aplicaiile militare;
Semidetaate: Aceasta este o form intermediar. Echipa poate fi
format din persoane experimentate i neexperimentate, proiectul
poate fi destul de mare, dar nu foarte mare.
Pentru clase diferite, parametrii metodei Basic COCOMO iau

urmtoarele valori:
Clasa de proiect
organic
semidetaat
integrat
b
2,4
3,0
3,6
c
1,05
1,12
1,20
Tabelul urmtor prezint estimri ale efortului pentru fiecare din cele
trei moduri, pentru diferite valori ale KLOC (dei un proiect organic de un
milion de linii de cod nu este realist). Se observ influena foarte mare a
constantei c asupra estimrilor obinute. Estimrile efortului sunt exprimate
tot n luni-om.
KLOC organic semidetaat integrat
2,4
3,0
3,6
1
26,9
39,6
57,1
10
145,9
239,4
392,9
50
521,3
904,2
100
6872
14333
1000
100
6.4.3. Analiza punctelor funcionale

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

o fiiere interne logice;
o fiiere externe de interfa;
funcii tranzacionale:
o intrri externe;
o ieiri externe;
o interogri externe.
Fiierele interne logice (engl. Internal Logical Files, ILF): Permit

utilizatorilor s foloseasc datele pe care trebuie s le ntrein. De exemplu,
un pilot poate introduce datele de navigare la un terminal din carling
nainte de plecare. Datele sunt stocate ntr-un fiier i pot fi modificate n
timpul misiunii. Pilotul este deci responsabil pentru ntreinerea acestor date.
Fiierele externe de interfa (engl. External Interface Files, EIF):
n acest caz, utilizatorul nu este responsabil pentru ntreinerea datelor;
acestea sunt localizate n alt sistem care le ntreine. Utilizatorul sistemului
analizat solicit datele doar pentru informare. De exemplu, un pilot se poate
informa asupra poziiei cu ajutorul sateliilor GPS sau al sistemelor de la sol.
El nu are responsabilitatea actualizrii acestor date, ns le poate accesa n
timpul zborului.
101
Intrrile externe (engl. External Input, EI): Permit utilizatorului s

ntrein fiierele interne logice prin operaii de adugare, modificare i
tergere.
Ieirile externe (engl. External Output, EO): Permit utilizatorului
s produc date de ieire. De exemplu, pilotul poate s afieze separat viteza
la sol i viteza real n aer, informaii derivate din datele interne (pe care le
poate ntreine) i cele externe (pe care le poate accesa).
Interogrile externe (engl. External Inquiries, EQ): Pentru ca
utilizatorul s poat selecta i afia datele din fiiere, el trebuie s introduc
informaii de selecie pentru a gsi datele n conformitate cu anumite criterii.
Interogrile pot accesa date att din fiierele interne logice ct i din fiierele
externe de interfa, dar nu produc date noi. Datele din fiiere nu sunt
modificate, ci doar cutate i furnizate. De exemplu, dac pilotul afieaz
date cu privire la relieful solului, date stocate anterior, rezultatul este
regsirea direct a informaiilor.
Prin ncercri repetate, s-au stabilit ponderi pentru fiecare din aceste
entiti. Numrul de puncte funcionale neajustate este:
PFN 10 ILF 7 EIF 4 EI 5 EO 4 EQ
n funcie de complexitatea tipurilor de date, se disting o serie de

valori pentru aceste puncte funcionale, prezentate n tabelul urmtor.
Nivel de complexitate
Simplu Mediu Complex
ILF
7
10
15
EIF
5
7
10
EI
3
4
6
EO
4
5
7
EQ
3
4
6
Tip
Pentru ajustarea suplimentar a estimrilor, se iau n calcul i alte 14

caracteristici care influeneaz dezvoltarea aplicaiilor: comunicaiile de
date, funciile distribuite, performana, folosirea masiv a configuraiilor,
rata tranzaciilor, intrrile de date online, eficiena utilizatorilor finali,
102
actualizrile online, prelucrrile complexe, refolosirea, uurina la instalare,

uurina la folosire, locaiile multiple, facilitarea modificrilor.
Influena fiecrei caracteristici este evaluat pe o scar de la 0 (nu
influeneaz) la 5 (influen puternic). Gradul de influenare (GI) este
suma acestor puncte pentru toate caracteristicile. Se calculeaz apoi factorul
de complexitate tehnic:
FCT 0,65 0,01 GI .
Punctele funcionale ajustate (PF) se obin astfel:
PF PFN FCT .
Avantajul principal al analizei punctelor funcionale este faptul c
msura productivitii este un rezultat natural, deoarece punctele funcionale
sunt independente de tehnologie i deci pot fi utilizate pentru a compara
productivitatea pe platforme diferite i cu instrumente de dezvoltare diferite.
Ele pot fi folosite pentru a stabili o rat de productivitate (PF / h) care
faciliteaz estimrile privind durata proiectului ca ntreg.
6.5. Distribuirea forei de munc n timp

Norden a studiat distribuia forei de munc n timp ntr-un numr de
proiecte de dezvoltare software din anii 60. A descoperit c aceast
distribuie avea deseori o form caracteristic, bine aproximat de distribuia
Rayleigh. Bazndu-se pe aceast descoperire, Putnam a dezvoltat un model
de estimare a costului n care fora de munc necesar la un moment de timp
t este dat de:
2
FM (t ) 2 K a t e at ,
unde a este un factor de accelerare care determin panta iniial a curbei, iar
K reprezint fora de munc total necesar, incluznd faza de ntreinere. K
103
este egal cu aria zonei delimitate de curba Rayleigh, reprezentat n figura

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

2
I (t ) K (1 e at )
Dac vom considera momentul de timp T n care curba Rayleigh
1
ajunge n punctul de maxim, atunci a 2 . Acest moment este apropiat
2T
de momentul de timp n care proiectul este predat clientului. Aria delimitat
de curba Rayleigh ntre punctele 0 i T este o bun aproximare a efortului
iniial de dezvoltare. Pentru acesta obinem:
E I (T ) 0,3945K .
Acest rezultat este foarte apropiat de o regul euristic des utilizat:

40% din efortul total este consumat pentru dezvoltarea efectiv, n timp ce
60% este consumat pentru ntreinere. Specificarea cerinelor nu este inclus
n model i deci estimrile nu se pot aplica dect ncepnd cu proiectarea i
implementarea.
Putnam a folosit observaii empirice legate de nivelurile de
productivitate pentru a deriva ecuaia software-ului din curba Rayleigh:
104
D k E1 / 3 t 4 / 3 ,
unde D este dimensiunea proiectului, E este efortul total n ani-om, t este

timpul scurs pn la lansare (n ani) iar k este un factor tehnologic bazat pe
14 componente, precum:
maturitatea general a proiectului i tehnicile de management;

gradul de utilizare a tehnicilor de ingineria programrii;
nivelul limbajelor de programare folosite;
capacitatea i experiena echipei de dezvoltare;
complexitatea aplicaiei.
Puterea supraunitar a timpului are implicaii puternice asupra

alocrii resurselor n proiecte mari. Prelungiri relativ mici ale datei de
livrare pot determina reducerea substanial a efortului.
Pentru estimarea efortului, Putnam a introdus ecuaia acumulrii
forei de munc (engl. manpower-buildup):
A E / t3 ,
unde A este accelerarea forei de munc iar E i t au semnificaiile de mai

sus.
Accelerarea forei de munc este 12,3 pentru proiecte software noi,
cu multe interfee i interaciuni cu alte sisteme, 15 pentru sisteme de sine
stttoare i 27 pentru reimplementri ale sistemelor existente.
Pe baza celor dou ecuaii, eliminm timpul i determinm efortul:
E ( D / k )9 / 7 A4 / 7 .
Acest rezultat este interesant deoarece arat c efortul este
proporional cu dimensiunea la puterea 9 / 7 1,286 , valoare similar cu
factorul c al lui Boehm de 1,20.
Evident, scurtarea timpului de dezvoltare implic un numr mai
mare de persoane necesare pentru proiect. Referindu-ne la modelul curbei
Rayleigh, scurtarea timpului de dezvoltare conduce la mrirea valorii a,
105
factorul de accelerare care determin panta iniial a curbei. Vrful curbei

Rayleigh se deplaseaz spre stnga-sus. Astfel obinem o cretere a puterii
necesare la nceputul proiectului i o for de munc maxim mai mare.
Exist i dezavantaje ale acestei deplasri. Mai multe studii au artat
c productivitatea individual scade odat cu creterea echipei. Conform lui
Brooks, exist dou cauze ale acestui fenomen:
Dac o echip se mrete, crete timpul acordat comunicrii cu

ceilali membri ai echipei (pentru consultare, sincronizarea sarcinilor
etc.);
Dac este adugat for de munc suplimentar unei echipe n
timpul dezvoltrii unui proiect, mai nti scade productivitatea. Noii
membri ai echipei nu sunt productivi de la nceput, cnd necesit
ajutor, deci timp, de la ceilali membri ai echipei n timpul
procesului de nvare. Luate mpreun, acestea conduc la scderea
productivitii totale.
Combinnd aceste dou informaii, ajungem la fenomenul cunoscut

sub denumirea de legea lui Brooks: adugarea de personal la un proiect
ntrziat l va ntrzia i mai mult.
Analiznd o mare baz de date de proiecte, Conte a descoperit
urmtoarea relaie ntre productivitatea medie L (msurat n linii de cod pe
lun-om) i mrimea medie a unei echipe P:
777
.
P
Formula atest faptul c productivitatea individual scade cu

mrimea echipei. Numrul de legturi de comunicare ntre persoanele
implicate ntr-un proiect este determinat de mrimea i structura echipei.
Dac ntr-o echip de mrime P fiecare membru trebuie s-i coordoneze
activitile sale cu toi ceilali din echip, numrul legturilor de
P( P 1)
comunicaie va fi:
. Dac fiecare membru trebuie s comunice
2
numai cu un singur alt membru, acest numr va fi: P 1 . Mai puin
106
comunicare dect aceasta nu este rezonabil, deoarece ne-am confrunta cu

echipe independente.
Numrul de legturi de comunicaie variaz de la aproximativ P la
aproximativ P 2 / 2 . ntr-o organizare ierarhic, aceasta conduce la P ci de
comunicaie, cu (1, 2) .
Pentru un membru al echipei, numrul de legturi de comunicaie
variaz de la 1 la P 1 . Dac productivitatea individual maxim este L i
fiecare legtur de comunicaie conduce la o pierdere a productivitii l,
atunci productivitatea medie va fi:
L L l ( P 1) ,
unde (0, 1] este o msur a numrului de legturi de comunicaie.
Presupunem c exist cel puin o persoan care s comunice cu mai
mult de o persoan, deci > 0. Pentru o echip de mrime P, aceasta
conduce la o productivitate total:
Ltot P L P L l ( P 1) .
Pentru o mulime dat de valori pentru L, l i , pentru valori
cresctoare ale lui P, aceast funcie crete de la 0 la o valoare maxim i
apoi scade din nou. Deci exist o mrime optim a echipei Popt , care
conduce la o productivitate maxim a echipei. Productivitatea echipei pentru
diferite valori ale lui P este dat n tabelul de mai jos. Aici, presupunem c
productivitatea individual este de 500 LOC / lun-om (L = 500), iar
scderea de productivitate este de 10% pe canal de comunicaie (l = 50). Cu
interaciune complet ntre membrii echipei ( = 1), rezult o echip optim
de 5,5 persoane:
107
Mrimea echipei Productivitatea individual Productivitatea total

1
500
500
2
450
900
3
400
1200
4
350
1400
5
300
1500
5,5
275
1512
6
250
1500
7
200
1400
8
150
1200
6.6. Concluzii
n acest curs au fost prezentate diferite modele de estimare a
efortului necesar pentru dezvoltarea unui proiect software, a forei de munc
i a timpului efectiv de dezvoltare. n final, s-a prezentat o modalitate de
estimare a distribuiei forei de munc n timp pentru gsirea numrului
optim de persoane implicate ntr-un proiect.
108
Capitolul 7
Managementul calitii
7.1. Introducere
Managementul calitii include procesele necesare pentru a asigura
faptul c proiectul va satisface cerinele pentru care este realizat.
Calitatea reprezint totalitatea caracteristicilor unei entiti care i
permit s satisfac cerinele explicite sau implicite. Un aspect critic al
managementului calitii este necesitatea de a transforma cerinele implicite
n cerine explicite cu ajutorul managementului domeniului proiectului.
Tehnicile moderne de management al calitii recunosc importana
urmtoarelor aspecte:
Satisfacia clientului: nelegerea, gestionarea i influenarea

cerinelor astfel nct ateptrile clientului s fie satisfcute sau
depite. Proiectul trebuie s fie conform cu specificaiile (trebuie s
produc ceea ce spune c produce) i potrivit pentru utilizare (trebuie
s satisfac nevoi reale);
Favorizarea prevenirii asupra corectrii: costul evitrii erorilor este
ntotdeauna mult mai mic dect costul corectrii lor;
Responsabilitatea managerial: pentru asigurarea succesului
proiectului este necesar participarea tuturor membrilor echipei, ns
rmne responsabilitatea managementului s asigure resursele
necesare pentru reuit;
Procesele organizate pe faze: iteraii ale ciclului Deming:
planificare-realizare-verificare-aciune (engl. Plan-Do-Check-Act,
PDCA)
Natura temporar a proiectelor nseamn c investiia n

mbuntirea calitii, n special prevenirea i evaluarea defectelor, trebuie

susinut de organizaia executant, deoarece un anumit proiect poate dura

prea puin pentru ca aceste investiii s fie recuperate.
7.2. Procesele principale ale managementului calitii

Exist 3 procese principale de management al calitii:
Planificarea calitii: identificarea standardelor de calitate relevante

pentru proiect i determinarea modului n care vor fi satisfcute;
Asigurarea calitii: evaluarea performanei globale a proiectului n
mod regulat pentru a stabili ncrederea c proiectul va satisface
standardele de calitate relevante;
Controlul calitii: monitorizarea rezultatelor proiectului pentru a
determina dac acestea sunt n conformitate cu standardele i pentru
a identifica modalitile de eliminare a cauzelor performanelor
nesatisfctoare.
Unul din scopurile managementului calitii este controlul variaiei

foarte important la produse de serie (de exemplu DVD-uri). n cazul
produselor software, acesta se refer de exemplu la minimizarea diferenei
dintre resursele planificate i cele reale, la teste de acoperire a unui procent
cunoscut din produs, minimizarea variaiei numrului de defecte de la o
versiune la alta etc.
7.3. Standardele ISO 9000

Standardele ISO 9000 reprezint o familie de documente referitoare
la sisteme de calitate dezvoltat de Organizaia Internaional pentru
Standardizare i administrat de organe de acreditare i certificare.
Ele specific cerinele sistemelor de calitate care pot fi utilizate cnd
un contract dintre 2 pri necesit demonstrarea capacitii furnizorului de a
proiecta i livra un produs. Cele 2 pri pot fi un furnizor i un client extern
110
sau ambele pot fi interne, de exemplu departamentele de marketing i de

programare din cadrul aceleiai companii.
n prezent, n familia ISO 9000 sunt incluse urmtoarele standarde:
ISO 9000 (Sisteme de management al calitii Principii i

vocabular) explic ce sunt sistemele de management al calitii.
Este un document de ndrumare i nu este utilizat n scopuri de
certificare. Este o referin important pentru a nelege termenii i
vocabularul legat de sistemele de management al calitii;
ISO 9001 (Sisteme de management al calitii Cerine) este
destinat utilizrii n orice organizaie care proiecteaz, dezvolt,
fabric, instaleaz sau asigur service pentru orice produs sau
furnizeaz orice form de servicii. Conine un numr de cerine pe
care trebuie s le ndeplineasc o organizaie dac dorete s obin
satisfacia clientului prin produse i servicii consecvente care
ndeplinesc ateptrile. Acest standard este singura implementare
pentru care pot acorda certificri auditori teri. Pstrarea certificrii
necesit audituri o dat la 3 ani, cu mini-audituri o dat la 6 luni.
Ultima versiune a standardului dateaz din anul 2008;
ISO 9004 (Sisteme de management al calitii Principii pentru
mbuntirea performanelor) trateaz perfecionarea continu,
dnd recomandri asupra a ceea ce trebuie fcut pentru a dezvolta un
sistem deja maturizat. Specific explicit faptul c nu este destinat ca
ghid pentru implementare.
Conceptele de calitate subliniate de aceste standarde sunt

urmtoarele:
O organizaie trebuie s obin i s susin calitatea produselor sau

serviciilor pentru a satisface n mod continuu nevoile implicite i
explicite ale clienilor;
O organizaie trebuie s asigure ncrederea propriului management
privind obinerea i susinerea calitii intenionate;
O organizaie trebuie s asigure ncrederea cumprtorului privind
calitatea deja existent sau n curs de obinere a produselor livrate
111
sau a serviciilor prestate. Cnd sunt cerute prin contract, aceast

asigurare a ncrederii poate presupune cerine de demonstrare
acceptate de comun acord.
Dei cu aplicabilitate general, standardul ISO 9001 este adecvat
dezvoltrii i ntreinerii produselor software. ISO 90003 conine Principii
pentru aplicarea standardului ISO 9001 la produse software. Acesta
identific problemele care trebuie rezolvate n mod independent de
tehnologiile utilizate, metodologii, procese de dezvoltare i structuri
organizaionale.
Seciunile standardului ISO 90003 conin:
cerine: ce trebuie ndeplinit pentru a obine certificarea;

recomandri: ce ar fi bine de fcut pentru a ajuta la ndeplinirea
cerinelor.
Exist 20 de prevederi n ISO 9001, interpretate de ISO 90003

pentru dezvoltarea software:
1. Responsabilitatea managerial. Politica de calitate trebuie definit,
documentat, neleas, implementat i ntreinut. Trebuie definite
responsabilitile i autoritatea tuturor membrilor echipei pentru
specificarea, atingerea i monitorizarea calitii. Trebuie definite,
instruite i finanate resursele interne de verificare. Trebuie s existe
un manager desemnat care s asigure implementarea programului de
calitate;
2. Sistemul de calitate. Trebuie stabilit un sistem de calitate
documentat, avnd proceduri i instruciuni, i care este integrat n
ntreg ciclul de dezvoltare;
3. Analiza contractelor. Contractele trebuie analizate pentru a vedea
dac cerinele sunt definite adecvat, concord cu oferta i pot fi
implementate;
4. Controlul proiectrii. Trebuie stabilite proceduri de verificare a
proiectrii pentru a asigura c cerinele sunt ndeplinite i c
metodele de proiectare sunt utilizate corect;
112
5. Controlul documentelor. Distribuirea i modificarea documentelor

trebuie controlate;
6. Achiziiile: Produsele achiziionate trebuie s fie conforme cu
cerinele specificate, incluznd evaluarea subcontractorilor poteniali
i verificarea produselor achiziionate;
7. Produsele furnizate de cumprtor. Toate materialele furnizate de
cumprtor trebuie verificate i ntreinute. Intr aici produsele
software existente sau produsele COTS (commercial-off-theshelf);
8. Identificarea i trasabilitatea produselor. Trasabilitatea (engl.
traceability) este capacitatea de a regsi istoricul, realizarea sau
localizarea obiectului considerat. n cazul unui produs, poate fi vorba
de originea materialelor i a prilor componente, istoricul realizrii,
distribuia i amplasarea produsului dup livrare. Produsul software
trebuie s poat fi identificat i urmrit pe parcursul tuturor fazelor
de dezvoltare, livrare i instalare;
9. Controlul proceselor. Procesele de dezvoltare trebuie definite i
planificate n condiii controlate i n conformitate cu instruciuni
documentate. Procesele speciale care ulterior nu pot fi complet
verificate sunt permanent monitorizate;
Figura 7.1. Nivelul optim al inspeciilor
113
10. Inspeciile i testarea. Se realizeaz inspecii i testri nainte de

lansarea produsului final. Trebuie gsit un echilibru ntre costul
reparrii defectelor i costul inspeciilor pentru depistarea acestora
(figura 7.1). Rapoartele inspeciilor i testelor trebuie pstrate;
11. Echipamentele de inspecie, msurare i testare. Echipamentele
utilizate pentru a demonstra conformitatea trebuie controlate,
calibrate i ntreinute. Cnd se utilizeaz hardware sau software de
testare, acestea trebuie verificate nainte de utilizare i reverificate la
intervale stabilite;
12. Starea inspeciilor i testelor. Rapoartele privind starea tuturor
articolelor de configuraie trebuie pstrate pe parcursul fazelor de
prelucrare;
13. Controlul produselor neconforme. Produsele neconforme trebuie
controlate pentru a preveni utilizarea sau instalarea incorecte. n
producia industrial, uneori este necesar construirea unor produse
utiliznd componente care nu se conformeaz tuturor cerinelor.
Produsele rezultate trebuie atent controlate. n domeniul software, un
sistem poate utiliza uneori instrumente sau poate integra componente
reutilizabile care nu satisfac toate standardele. De exemplu,
reutilizarea unei biblioteci DLL native scrise n C ntr-un program
C# poate fi eficient din punct de vedere al costurilor dac acel cod
C i-a demonstrat valoarea n aplicaii anterioare. Totui, codul C
poate pune riscuri sistemului DotNET i aceste riscuri trebuie
gestionate corespunztor;
14. Aciuni corective. Cauzele produselor neconforme trebuie
identificate. Cauzele poteniale ale neconformitilor trebuie
eliminate iar procedurile trebuie modificate prin aciuni corective.
Aciunile corective se refer la eliminarea cauzelor neconformitilor
reale. Aciunile preventive se refer la eliminarea cauzelor
neconformitilor poteniale;
15. Manipularea, stocarea, mpachetarea i livrarea. Trebuie stabilite
proceduri pentru aceste aspecte. n cazul produselor software, aici
intr operaiunile de multiplicare i instalare;
16. Rapoartele de calitate. Informaiile despre calitate trebuie colectate,
ntreinute i puse la dispoziie cnd este nevoie persoanelor
114
autorizate;
17. Audituri interne de calitate. Auditurile trebuie planificate i
executate. Rezultatele auditurilor sunt comunicate managementului
iar deficienele gsite trebuie corectate;
18. Instruirea. Trebuie identificate nevoile de instruire (engl. training)
atunci cnd activitile necesit o calificare nou. Rapoartele
aciunilor de instruire trebuie pstrate;
19. ntreinerea. Activitile de service trebuie ndeplinite dup cum sunt
specificate. n cazul produselor software, acest punct se refer la
ntreinere (engl. maintenance);
20. Tehnici statistice. Atunci cnd este posibil, trebuie identificate
tehnici statistice adecvate pentru verificarea capacitii proceselor i
a caracteristicilor produselor. n cazul produselor software, acest
punct se refer la metrici sau alte modaliti de msurare.
7.4. Modelul CMMI

Modelul de Maturitate a Capacitii pentru Software (engl. The
Capability Maturity Model for Software, CMM) a fost dezvoltat de
Institutul de Ingineria Programrii (engl. Software Engineering Institute,
SEI) de la Universitatea Carnegie-Mellon. A urmat Capability Maturity
Model Integration, CMMI, a crui versiune 1.3 a fost lansat n 2010.
Modelul descrie principii i bune practici asociate cu maturizarea
proceselor de dezvoltare software i este destinat organizaiilor care doresc
s urmeze calea de la procese ad-hoc la procese standardizate. Modelul este
organizat pe 5 niveluri de maturitate. Un nivel este un platou evolutiv bine
definit ctre atingerea maturitii i mbuntirea continu a proceselor de
dezvoltare.
CMMI include urmtoarele niveluri:
1. Iniial. Procesele software sunt improvizate, uneori chiar haotice.
Puine procese sunt definite iar succesul depinde de eforturile
individuale;
2. Gestionat (engl. managed). Sunt stabilite procese manageriale de
115
baz pentru a monitoriza costurile, graficul de lucru i

funcionalitatea. Exist disciplina necesar pentru a repeta succesele
anterioare pentru proiecte similare;
3. Definit. Procesele software pentru activitile de management i cele
tehnice sunt documentate i integrate ntr-un proces standard al
organizaiei. Toate proiectele folosesc o versiune adaptat i
aprobat a standardului;
4. Gestionat cantitativ (engl. quantitatively managed). Sunt colectate
msurtori detaliate despre procesele software i calitatea
produselor. Att procesele software ct i produsele sunt nelese i
controlate din punct de vedere cantitativ;
5. n optimizare (engl. optimizing). Este facilitat mbuntirea
continu a proceselor prin reacii (feedback) cantitative din cadrul
proceselor i prin includerea unor idei i tehnologii inovatoare.
Figura 7.2. Modelul CMMI
n varianta CMM, nivelul 2 se numete Repetabil iar nivelul 4 se

numete Gestionat.
Cu excepia nivelului 1, fiecare nivel de maturitate este descompus
n cteva arii de procese cheie care indic pe ce aspecte trebuie s se
116
concentreze organizaia pentru a-i mbunti procesele software. Aspectele

cheie identific problemele care trebuie rezolvate pentru a atinge un anumit
nivel de maturitate. Acestea includ grupuri de activiti nrudite care,
realizate colectiv, conduc la ndeplinirea scopurilor considerate importante
pentru creterea capacitii proceselor.
Procesele cheie pentru fiecare nivel sunt prezentate n cele ce
urmeaz.
Prin definiie, pentru nivelul 1 nu exist procese cheie.
Procesele cheie pentru nivelul 2 se concentreaz asupra stabilirii
funciilor manageriale de baz:
Aria de inginerie:
o Managementul cerinelor;
Aria de management de proiect:
o Planificarea proiectelor;
o Monitorizarea i controlul proiectelor;
o Managementul acordurilor cu furnizorii (Gestionarea
achiziiilor de produse de la furnizori externi);
Aria de suport:
o Msurtori i analize;
o Asigurarea calitii proceselor i produselor;
o Managementul configuraiei.
Procesele cheie pentru nivelul 3 se refer att la probleme legate de
proiect ct i la cele organizaionale, ntruct organizaia stabilete
infrastructura de lucru i instituionalizeaz procesele de ingineria
programrii i de management pentru toate proiectele. Scopul principal este
standardizarea proceselor.
Aria de inginerie:
o Dezvoltarea cerinelor (Transformarea nevoilor clientului n
cerine prin consolidarea informaiilor insuficiente,
rezolvarea conflictelor etc.);
o Soluia tehnic (Reprezint efortul tehnic principal de
proiectare i implementare);
117
o Integrarea produsului (Asamblarea produsului din

componentele sale);
o Verificarea;
o Validarea;
o Definirea proceselor organizaionale;
o Activitile organizaionale de instruire;
o Management de proiect integrat (Implicarea tuturor prilor
interesate relevante);
o Managementul riscului;
Aria de suport:
o Analiza deciziilor i rezoluiile (engl. Decision Analysis and
Resolution Analiza alternativelor cu ajutorul unui proces
de evaluare formal pe baza unor criterii bine definite).
Procesele cheie ale nivelului 4 se concentreaz pe nelegerea

cantitativ a proceselor i produselor:

o Performanele proceselor organizaionale (Stabilirea unor
modele de evaluare cantitativ a proceselor organizaiei);
o Managementul de proiect cantitativ (Managementul n
vederea ndeplinirii obiectivelor cantitative stabilite de
calitate i performan).
Procesele cheie ale nivelului 5 acoper problemele referitoare la

mbuntirea continu i msurabil a proceselor legate de software:

o Inovarea
organizaional
i
desfurarea
(engl.
Organizational Innovation and Deployment);
Aria de suport:
o Analiza cauzal i rezoluiile (engl. Causal Analysis and
Resolution Identificarea cauzelor defectelor i luarea de
msuri pentru prevenirea lor).
118
Organizaiile nu pot fi certificate CMMI, n schimb are loc un

proces de evaluare (engl. appraisal), n urma cruia organizaia este cotat
la unul din nivelurile 1-5.
7.5. Biblioteca ITIL

Biblioteca
Infrastructurii
Tehnologiei
Informaiei
(engl.
Information Technology Infrastructure Library, ITIL) reprezint un set de
concepte i bune practici destinate n principal pentru managementul
serviciilor IT, dar i pentru procesele de dezvoltare IT n general. Biblioteca
este proprietatea Guvernului Marii Britanii.
Managementul serviciilor IT se bazeaz pe o filosofie axat pe
perspectiva clientului asupra contribuiei IT-ului la mediul de afaceri i este
n contrast cu abordrile n care tehnologia deine rolul central. n acest caz,
furnizorii de servicii IT nu se mai concentreaz pe tehnologie i pe
organizarea lor intern, ci iau n calcul calitatea serviciilor oferite i se
concentreaz pe relaia cu clienii.
Versiunea 2011 a ITIL cuprinde 5 volume:
1. Strategia serviciilor: conine recomandri asupra clarificrii i
prioritizrii investiiilor furnizorilor de servicii, care pot ajuta
organizaiile IT s i mbunteasc performanele i s se dezvolte
pe termen lung;
2. Proiectarea serviciilor: cuprinde o serie de bune practici asupra
proiectrii serviciilor IT i a modului n care serviciile planificate
trebuie s interacioneze cu mediul comercial i tehnic mai larg;
3. Tranziia serviciilor: se adreseaz livrrii serviciilor n mediul
operaional i managementului schimbrilor provocate n mediul de
afaceri;
4. Funcionarea serviciilor: conine bune practici pentru asigurarea
unui nivel de calitate specificat pentru serviciile oferite att clienilor
ct i utilizatorilor finali, precum i pentru monitorizarea
problemelor i gsirea echilibrului ntre ncrederea serviciilor i
costuri;
119
5. mbuntirea continu a serviciilor: i propune alinierea i

realinierea serviciilor IT la necesitile n permanent schimbare ale
mediului de afaceri i la identificarea i implementarea modalitilor
de mbuntire a serviciilor.
Certificarea ITIL cade n sarcina ITIL Certification Management
Board (ICMB). Schema de certificare ITIL este modular. La primul nivel,
Fundamente (engl. Foundations), candidaii primesc 2 credite. La nivelul
Intermediar trebuie obinute 15 credite, pe direciile Ciclu de via (engl.
Lifecycle), Capacitate (engl. Capability) sau combinaii ale acestora.
Un modul de Ciclu de via ofer 3 credite iar unul de Capacitate ofer 4
credite. La nivelul Expert, candidatul trebuie s obin 22 de credite,
ultimele 5 reprezentnd examenul Managementul pe parcursul ciclului de
via (engl. Managing Across the Lifecycle).
7.6. Concluzii
Exist o strns corelaie ntre modelele ISO 9001 i CMMI, dei
unele aspecte din ISO 9001 nu sunt acoperite de CMMI i viceversa.
Asemnarea cea mai mare rezult din faptul c ambele standarde ndeamn
s spui ce faci i s faci ce spui (engl. say what you do; do what you
say). Premisa fundamental este c toate procesele importante trebuie
documentate i c toate livrabilele trebuie verificate prin activiti de control
al calitii. Diferena cea mai mare este c modelul CMMI pune accentul pe
mbuntirea continu a proceselor. ISO 9001 descrie criteriile minime
pentru un sistem de calitate acceptabil. De asemenea, CMMI se
concentreaz exclusiv pe procesele de dezvoltare software, n timp ce ISO
9001 are un domeniu de aplicare general. O analiz rapid arat c o
organizaie certificat ISO 9001 satisface majoritatea criteriilor CMMI de
nivel 2 i multe criterii de pe nivelul 3. ns datorit diferenelor de
abordare, nu se poate face o corelaie exact privind nivelurile de ndeplinire
a criteriilor de calitate ntre cele dou standarde.
Biblioteca Infrastructurii Tehnologiei Informaiei (ITIL) reprezint
un set de concepte i bune practici n principal pentru managementul
serviciilor IT.
120
Capitolul 8
Managementul resurselor umane

8.1. Introducere
Managementul resurselor umane include procesele necesare pentru a
utiliza n cel mai eficient mod persoanele implicate n proiect. Include toate
prile interesate ale proiectului sponsori, clieni, colaboratori individuali
etc. Exist 3 procese principale de management al resurselor umane:
Planificarea organizaional: identificarea, documentarea i

atribuirea rolurilor, responsabilitilor i structurii ierarhice. Acestea
pot fi atribuite indivizilor sau grupurilor, care pot face parte din
organizaie sau pot fi colaboratori externi. Grupurile interne sunt
deseori asociate cu un departament funcional specific, precum
departamentul tehnic, de marketing sau de contabilitate.
Selecia personalului: alocarea resurselor umane necesare pentru a
lucra la proiect. n majoritatea situaiilor, cele mai bune resurse pot
s nu fie disponibile, iar managerul de proiect trebuie s asigure
faptul c resursele disponibile vor satisface cerinele de competen
ale proiectului.
Dezvoltarea echipei: dezvoltarea competenelor individuale i de
grup pentru a crete performanele lucrului la proiect. Dezvoltarea
personal, att managerial ct i tehnic, reprezint fundaia
necesar pentru dezvoltarea echipei, care la rndul su este un factor
critic pentru a face ca proiectul s-i ating obiectivele.

8.2. Factori de management al echipei

Oamenii sunt bunul cel mai de pre al unei organizaii. Aadar,
sarcinile unui manager sunt n principal orientate ctre oameni. Dac aceste
aspecte nu sunt nelese, managementul este nereuit. n general,
managementul deficitar al resurselor umane este un factor important de eec
al proiectelor. Dintre factorii principali de management al echipei,
menionm:
Consecvena: membrii echipei trebuie tratai n mod comparabil, fr

favoritisme sau discriminare;
Respectul: diferii membri ai echipei au competene diferite iar
aceste diferene trebuie respectate i folosite n favoarea proiectului;
Implicarea: toi membrii echipei trebuie implicai n desfurarea
proiectului iar punctele lor de vedere trebuie luate n considerare;
Sinceritatea: managerul de proiect trebuie s fie ntotdeauna sincer
cu privire la lucrurile care merg bine sau ru n desfurarea
proiectului.
Motivarea: stimularea oamenilor s se angajeze ntr-o (mai) mare
msur n activitile legate de proiect.
8.3. Motivarea
Conceptul de management tiinific al lui F. W. Taylor a fost
implementat de Henry Ford n contextul liniilor de producie n mas, unde
o modalitate de cretere a eficienei a fost scderea complexitii sarcinilor
individuale de lucru, astfel nct la nlocuirea unei persoane, noul angajat si poat nva foarte repede atribuiile i s devin productiv.
Mass production was popularized in the 1910s and 1920s by
Henry Fords Ford Motor Company, which introduced electric motors
to the then-well-known technique of chain or sequential production
and, in the process, began a new era often called the second
industrial revolution. Fords contribution to mass production was
122
synthetic in nature, collating and improving upon existing methods of

sequential production and applying electric power to them, resulting
in extremely-high-throughput, continuous-flow mass production,
making the Model T affordable and, as such, an instant hit.
Ford astonished the world in 1914 by offering a $5 per day
wage, which more than doubled the rate of most of his workers. Using
the consumer price index, this was equivalent to $120 per day in 2015
dollars. The move proved extremely profitable; instead of constant
turnover of employees, the best mechanics in Detroit flocked to Ford,
bringing in their human capital and expertise, raising productivity,
and lowering training costs. Ford called it wage motive.
(Wikipedia Henry Ford)
ncepnd cu revoluia industrial i pn dup al doilea rzboi

mondial, nu s-a pus problema creterii productivitii prin aciuni de
motivare a angajailor. Acetia erau privii aproape la fel ca nite maini
care pot fi schimbate cnd nu mai dau rezultate. Datorit faptului c
numrul oamenilor care doreau s se angajeze n industrie era foarte mare,
nlocuitori se gseau uor.
Prosperitatea de dup cel de-al doilea rzboi mondial a diminuat
constrngerile la care puteau fi supui angajaii. Oamenii puteau s
prseasc voluntar slujbele neatractive fr riscul de a muri de foame sau
de a nu-i mai gsi un alt serviciu. Aceast situaie a dus la apariia
cercetrilor n domeniul motivrii angajailor, pentru ca acetia s lucreze pe
ct posibil din plcere i n consecin s fie i mai eficieni.
8.3.1. Proceduri i motivare
S-a constatat c atunci cnd n organizaie exist proceduri clare iar
oamenii tiu exact ce trebuie s fac, cnd i cum, angajaii sunt mai
satisfcui i devin mai productivi. Studiile realizate asupra companiilor att
din punct de vedere al standardizrii procedurilor ct i al introducerii
msurilor de motivare a angajailor (figura 8.1) au artat c productivitatea
crete n ordine n urmtoarele situaii:
123
motivare slab, proceduri nestandardizate;

motivare slab, proceduri standardizate;
motivare bun, proceduri nestandardizate;
motivare bun, proceduri standardizate.
Figura 8.1. Efectul motivrii i al standardizrii procedurilor

asupra productivitii
8.3.2. Teoria ateptrii

Se bazeaz pe ideea c oamenii fac anumite lucruri pentru a primi o
recompens sau pentru a ajunge la un rezultat ateptat. Dac se creeaz o
anumit ateptare la o persoan, aceasta se poate transforma n realitate.
Dac i se spune n mod repetat cuiva c nu lucreaz bine, chiar dac acest
lucru nu este adevrat, n timp va ajunge s nu mai lucreze bine. Invers,
dac i se spune cuiva c lucreaz bine, n timp va ajunge s i
mbunteasc performanele.
Un experiment tipic realizat n coli primare a presupus
administrarea unui test de inteligen copiilor, dup care a fost selectat
aleatoriu un numr mic de elevi din fiecare clas. nvtorilor i prinilor
li s-a spus c aceti copii au caliti deosebite. Dup un timp, tuturor elevilor
li s-a administrat un test similar. S-a constatat c elevii selectai i-au
124
mbuntit scorurile n mod considerabil, doar datorit atitudinii celor din

jur.
Din punct de vedere practic, n managementul de proiect, teoria
poate fi aplicat prin ncurajarea angajailor, recunoaterea realizrilor,
laude publice i critici private.
8.3.3. Teoria ierarhiei nevoilor umane a lui Maslow
Conceptul ierarhizrii nevoilor umane a fost dezvoltat de Abraham
Maslow. Nevoile fundamentale sunt dispuse ntr-o piramid (figura 8.2), i
se consider c nevoile de nivel mai sczut trebuie ndeplinite nainte de a fi
luate n calcul nevoile de nivel superior.
Figura 8.2. Piramida nevoilor umane
Pe primul nivel se gsesc nevoile de hran, adpost, mbrcminte.

Dup ce sunt satisfcute acestea, motivaia se ndreapt ctre urmtorul
nivel, protejarea acestor factori. De exemplu, dup dobndirea unei locuine,
persoana vrea s i asigure sigurana, att imediat ct i viitoare.
Urmeaz nevoile de contacte sociale. O atmosfer de lucru
motivant apare atunci cnd un angajat se simte acceptat n colectiv.
125
Apoi, pe urmtorul nivel, apare dorina de a fi apreciat i recunoscut.

Pe ultimul nivel al ierarhiei sunt nevoile de auto-mplinire, cnd
persoana are sentimentul c ceea ce face este valoros n sine, indiferent de
recunoaterea colegilor sau a managerului. Interesul nsui este un factor
suficient de motivare.
In the 1970s many companies tried to implement this method of
motivation. It was felt that the basic needs of food, shelter, clothing,
security, and safety were already satisfied and that employee
motivation could be achieved by increasing workers ability to
socialize. Companies attempted to make their employees one big
happy family. Generally, this was attempted by building golf courses
and country clubs and encouraging company sponsored after-hours
activities. In general, these programs failed. Peoples need for
socialization was already satisfied, and giving them more of these
things did not motivate them further. One side effect of this kind of
program was that when these things were later withdrawn there was a
great deal of dissatisfaction, and employees become demotivated.
(Michael W. Newell Preparing for the Project Management
Professional Certication Exam)
n conformitate cu acest model, oamenii sunt n permanen ntr-o

stare de necesitate. Nevoile devin din ce n ce mai abstracte, ns dac din
anumite cauze externe (de exemplu crize, situaii de urgen) nevoile
inferioare nu mai sunt ndeplinite, acestea devin din nou factorii dominani.
Several survival biographies and histories of groups have been
written over the years about people's reactions to hardship and dire
situations. Typically in these stories the group starts out as an
agreeable and mutually cooperative group with some goal in mind. As
the hardships increase, the motivation moves from satisfying selfesteem to satisfying the need for socialization to the more basic needs.
As the lower levels of needs become unsatisfied the individual's
motivation becomes more basic and more self-serving. In World War
II prison camps, these basic needs became so motivating that people
performed acts that they would never have performed under normal
circumstances. (Michael W. Newell Preparing for the Project
Management Professional Certication Exam)
126
The Stanford prison experiment was a study of the

psychological effects of becoming a prisoner or prison guard. The
experiment was conducted in 1971 by a team of researchers led by
Psychology Professor Philip Zimbardo at Stanford University.
Twenty-four undergraduates were selected out of 70 to play the roles
of both guards and prisoners and live in a mock prison in the
basement of the Stanford psychology building. Roles were assigned at
random. They adapted to their roles well beyond that expected,
leading the guards to display authoritarian and even draconian
measures.
Examples:
After a relatively uneventful first day, a riot broke out on the
second day. The guards volunteered to work extra hours and worked
together to break the prisoner revolt, attacking the prisoners with fire
extinguishers without supervision from the research staff.
After only 36 hours, one prisoner began to act crazy, to
scream, to curse, to go into a rage that seemed out of control. It took
quite a while before we became convinced that he was really suffering
and that we had to release him.
Prisoner No. 416, a newly admitted stand-by prisoner,
expressed concern over the treatment of the other prisoners. The
guards responded with more abuse. When he refused to eat his
sausages, saying he was on a hunger strike, guards confined him in a
closet and called it solitary confinement. The guards used this incident
to turn the other prisoners against No. 416, saying the only way he
would be released from solitary confinement was if they gave up their
blankets and slept on their bare mattresses, which all but one refused
to do.
Zimbardo concluded the experiment early when Christina
Maslach, a graduate student he was then dating (and later married),
objected to the appalling conditions of the prison after she was
introduced to the experiment to conduct interviews. Zimbardo noted
that of more than fifty outside persons who had seen the prison,
Maslach was the only one who questioned its morality. After only six
days of a planned two weeks duration, the Stanford Prison
experiment was shut down.
Several guards became increasingly cruel as the experiment
continued. Experimenters said that approximately one-third of the
guards exhibited genuine sadistic tendencies. Most of the guards were
127
upset when the experiment concluded early. (Wikipedia Stanford

Prison Experiment)
8.3.4. Teoria celor doi factori a lui Herzberg

Aceast teorie propus de Frederick Herzberg, cunoscut i sub
numele de teoria motivaie-igien (engl. motivation-hygiene theory),
consider c satisfacia i insatisfacia la serviciu sunt fenomene
independente: unii factori cauzeaz satisfacia n timp ce ali factori
cauzeaz insatisfacia.
Satisfacia este legat de activitile pe care le execut individul i
include ca factori favorizani provocrile profesionale, recunoaterea,
dezvoltarea personal etc.
Insatisfacia este legat de absena unor factori exteriori, precum
sigurana locului de munc, poziia social, salariul, practicile de
supervizare etc.
8.3.5. Tipuri de personalitate
Piramida nevoilor este o simplificare a motivaiilor reale. Motivarea
trebuie s in seama i de tipurile de personalitate ale angajailor. Putem
distinge 3 tipuri de personalitate, clasificate din punct de vedere al factorilor
motivani. Astfel, persoanele pot fi:
Orientate spre ndeplinirea sarcinilor: motivaia pentru munc este

munca nsi;
Orientate spre sine: munca este un mijloc pentru atingerea
scopurilor individuale (bani, cltorii etc.);
Orientate spre interaciuni: motivaia principal este prezena i
aciunile colegilor oamenii merg la serviciu fiindc le place acolo.
Motivaiile reale sunt compuse din elemente ale fiecrei clase.

Proporiile se pot schimba n funcie de circumstanele personale i
evenimentele externe. Oamenii nu sunt motivai doar de factori personali, ci
i de apartenena la un grup i de colegii lor de serviciu cu care lucreaz.
128
8.4. Organizarea echipelor

Echipele mari sunt greu de gestionat i deseori sunt mprite n
subechipe, astfel nct gestionarea activitilor i comunicarea s se limiteze
n cadrul aceleiai subechipe, mrindu-se productivitatea.
8.4.1. Organizarea ierarhic
n mediile dedicate producerii de software, se ntlnesc deseori
structuri ierarhice. n funcie de dimensiunea proiectului i a organizaiei,
pot exista diferite niveluri de management.
Figura 8.3 prezint un exemplu de organizare ierarhic.
Dreptunghiurile denot subechipele n care se lucreaz efectiv. Cercurile
reprezint managerii. Aici avem dou niveluri de management. La nivelul
inferior, subechipele sunt responsabile de dezvoltarea diferitelor pri ale
proiectului. Managerii acestora au rolul de a le coordona activitatea. La
nivelul superior, se coordoneaz activitatea subechipelor pe ansamblu.
Figura 8.3. Organizare ierarhic
Organizarea ierarhic reflect deseori structura global a sistemului

care trebuie dezvoltat. Dac sistemul are trei subsisteme majore, pot exista
trei subechipe. De asemenea, pot exista uniti funcionale asociate cu
responsabiliti specifice proiectului, cum ar fi testarea.
O problem a organizrii ierarhice este distana dintre nivelurile
superioare i inferioare ale piramidei. Munca real se face de obicei pe
nivelurile inferioare, unde sunt utilizate cunotinele concrete despre
129
aplicaie. Pe msur ce ne ridicm n ierarhie, cunoaterea devine din ce n

ce mai puin specific.
Totui, chiar dac deciziile importante se iau la aceste niveluri, n
multe cazuri sunt luate n considerare semnalele venite de pe nivelurile de
jos, care sunt de obicei nsumate sau sintetizate pe niveluri intermediare.
De multe ori, pe msur ce informaiile urc n ierarhie, lucrurile
tind s par din ce n ce mai bune. Urmtorul scenariu nu este imposibil:
nivelul de jos: avem probleme serioase la implementarea modulului X;

nivelul 1: sunt ceva probleme cu modulul X;
nivelul 2: progresul este constant, nu prevd probleme reale;
nivelul de sus: totul merge conform planului.
Aceste distorsiuni sunt deseori dificil de mpiedicat. Ele sunt cauzate

de faptul c linia ierarhic pe care se raporteaz progresul este aceeai cu
cea utilizat pentru evaluarea performanelor. Oamenii doresc evaluri
pozitive i de aceea tind s-i modifice i rapoartele n consecin. Dac
datele privind progresul proiectului sunt colectate i prelucrate de persoane
neimplicate n evaluarea membrilor echipei, cresc mult ansele ca i
informaiile s fie suficient de corecte.
Un alt aspect problematic al acestui tip de organizare este faptul c
individul este judecat, att din punct de vedere social ct i financiar, dup
nivelul pe care l ocup n ierarhie. Este de neles aspiraia de a ajunge pe
niveluri din ce n ce mai nalte, dei nu este foarte clar dac acest lucru este
de dorit. Principiul lui Peter din legile lui Murphy spune: ntr-o organizaie
ierarhic, fiecare angajat urc pn la nivelul su de incompeten. Un
programator bun nu e neaprat i un bun manager. Programarea necesit
competene diferite de cele ale managementului. Ideal este stimularea
oamenilor pentru meninerea lor pe nivelurile la care lucreaz cel mai bine.
8.4.2. Organizarea matrice
Acest tip de organizare este deseori ntlnit n situaia cnd la un
proiect software lucreaz oameni din diferite departamente i care pot avea
simultan mai muli efi. Unitatea de baz este un grup mic, specializat. Pot
130
exista mai multe uniti cu aceeai specializare. Unitile sunt organizate n

conformitate cu specializarea lor, de exemplu: grafic computerizat, baze
de date, interfee cu utilizatorul, testare etc. Proiectele implic uniti cu
diferite specializri. Indivizii sunt organizai pe dou axe: una reprezentnd
grupurile specializate iar cealalt proiectele la care particip (figura 8.4).
programare
grafic baze de date testare
n timp real
X
X
proiectul A
X
X
X
proiectul B
X
X
X
proiectul C
Figura 8.4. Organizare matrice
n aceast situaie, managerul de proiect este responsabil de

terminarea cu succes a proiectului. El controleaz una sau mai multe uniti
i trebuie s menin sau s mreasc, pe termen lung, baza de cunotine i
experiena membrilor echipei. El poate pune accent pe rezolvarea
activitilor necesare pentru ndeplinirea obiectivului, n timp ce managerii
unitilor se pot concentra pe creterea gradului de relaionare cu angajaii.
O astfel de organizare poate fi foarte eficient, cu condiia s existe
suficient ncredere reciproc i dorin de cooperare.
8.5. Principii generale de organizare a unei echipe

Indiferent de modul n care este organizat o echip, cel mai
important este faptul c trebuie s fie unitar, dar nu uniform. Dintre
principiile de organizare a unei echipe, menionm:
Folosirea unui numr mic de oameni capabili: Productivitatea

maxim este obinut de un grup relativ mic de oameni, de exemplu
aproximativ 6 persoane. Grupurile mari necesit mai mult
comunicare, care are efecte negative asupra productivitii i duce la
erori mai multe;
131
Sarcinile trebuie puse n acord cu motivaiile i capacitile

oamenilor disponibili: Cu alte cuvinte, trebuie s ne asigurm ca
principiul lui Peter nu se aplic i n cazul echipei noastre. n cele
mai multe organizaii, programatorilor foarte buni li se ofer funcii
manageriale. Este mult mai bine s li se ofere posibiliti de a avansa
n carier n arii mai tehnice ale dezvoltrii i ntreinerii
software-ului;
Pe termen lung, organizaia are mai mult de ctigat dac i ajut pe
angajai s evolueze: Altfel spus, nu trebuie s aib loc Principiul
lui Peter inversat: angajaii urc n ierarhie pn la nivelul la care
devin indispensabili. De exemplu, un programator poate deveni
singurul expert ntr-un anumit domeniu. El nu va avea ansa s
lucreze n alt domeniu. S-ar putea ca persoana respectiv s
prseasc firma pentru a lucra la altceva mai interesant;
Este bine s fie selectai oameni care s formeze o echip bine
echilibrat i armonioas: Nu este suficient s existe n echip doar
civa experi de vrf. Trebuie s existe i persoane care s
ndeplineasc sarcinile mai simple, de rutin, pe care experii s-ar
putea simi chiar insultai s le rezolve;
Cine nu se potrivete cu echipa trebuie ndeprtat: Dac echipa nu
funcioneaz ca o unitate coerent, de multe ori suntem nclinai s
mai ateptm puin, s vedem cum evolueaz lucrurile i s sperm
ca totul va merge bine. Acest lucru este duntor pe termen lung.
132
Capitolul 9
Conducerea echipei
9.1. ncrederea
ntr-un cadru profesional, ncrederea se ctig de persoanele care i
fac bine treaba, care respect scopurile proiectului, i trateaz corect colegii
i se comport n mod consecvent chiar i n momente dificile. ncrederea
profesional nu este neaprat legat de trsturile de personalitate. Putem
avea ncredere n anumite persoane chiar dac ne plac sau nu din punct de
vedere personal.
O msur a ncrederii este angajamentul respectarea promisiunilor.
Unul din cele mai importante elemente ale proiectelor bine administrate este
ca managerul s i asume responsabiliti i s lucreze pentru a-i respecta
aceste angajamente.
Un angajament eficient presupune urmtoarele aspecte:
Persoana care i ia angajamentul o face de bun voie;

Angajamentul este afirmat deschis, n mod public;
Angajamentul este luat n cunotin de cauz, doar dup o analiz
atent a volumului de lucru, a resurselor i a graficului de lucru;
Exist o nelegere ntre pri asupra a ceea ce trebuie fcut, de ctre
cine i pn cnd;
Persoana responsabil ncearc s i ndeplineasc angajamentul
chiar dac are nevoie de ajutor;
nainte de termenul limit, dac apare ceva care pune n pericol
ndeplinirea angajamentului, prile afectate trebuie s i ntiineze
pe ceilali i s se negocieze o nou nelegere.
ncrederea se ctig prin respectarea angajamentelor i se pierde

prin comportament inconsecvent. Cnd un angajat nu-i ndeplinete

promisiunile, acest fapt creeaz o atmosfer de ngrijorare n cadrul echipei,

care nu i mai concentreaz toat energia asupra ndeplinirii obiectivelor
proiectului, ci consum resurse calculnd dac persoana va face ntr-adevr
ceea ce a spus c va face. Contient sau incontient se fac planuri de rezerv
i crete nivelul stresului i ndoielii.
9.1.1. Delegarea autoritii
Delegarea autoritii este o alt form de ncredere: ncrederea ca
alii s ia decizii. Prin declararea public a faptului c un anumit aspect
organizaional va fi administrat de altcineva, managerul i transfer
autoritatea asupra persoanei respective. Este important ca delegrile s aib
suficient vizibilitate pentru ca toi oamenii implicai s cunoasc acest
lucru.
9.1.2. Modelele comportamentale
Nicio dispoziie a unui conductor nu este respectat mai bine dect
aceea pe care o respect conductorul nsui. Oamenii deseori nva prin
observarea modelelor pe care le admir i apoi prin ncercarea contient
sau subcontient de a le emula comportamentul. De aceea managerii
trebuie s fie primii care respect regulile pe care le impun celorlali.
9.2. Politica i puterea

n orice proiect care presupune organizarea oamenilor, exist
persoane cu atitudini, dorine i abiliti diferite. Orict de inteligent sau de
talentat ar fi un conductor, vor exista tot timpul oameni care nu primesc tot
ceea ce vor. Oamenii ambiioi vor ncerca deci s i ndeplineasc
scopurile prin influenarea celor care au puterea s le ofere ce i doresc.
Orice act de management redistribuie sau consolideaz anumite forme de
putere.
De aceea exist ceea ce numim politic. Motivaia politicii este
puterea. O definiie aproximativ a puterii este capacitatea unei persoane de
134
a-i influena sau controla pe alii. O alt definiie este capacitatea de a-i
determina pe alii s fac ceva ce altfel nu ar face. ns aceasta nu nseamn
neaprat manipulare sau determinarea unor aciuni n defavoarea propriilor
interese ale persoanelor asupra crora se exercit puterea.
ntre putere i ierarhie nu exist ntotdeauna o suprapunere exact.
Un angajat care poate convinge persoanele potrivite la momentul potrivit,
care i pune n valoare cunotinele pentru a rezolva unele situaii n
beneficiul tuturor poate fi mai puternic n organizaie dect superiorii si
ierarhici, uneori chiar fr ca acetia s i dea seama.
Politica se poate defini ca procesul de luare a deciziilor n vederea
administrrii i controlului afacerilor interne i externe ale unei organizaii
(n sensul cel mai larg).
Este important de remarcat faptul c n general raportul dintre putere
i responsabilitate este constant. Cu ct are cineva mai mult putere, cu att
are mai multe constrngeri, mai multe interese de echilibrat i probleme de
rezolvat. De aceea, puterea mai mare nu uureaz lucrurile; stresul,
preteniile, provocrile cresc ca rezultat al puterii sporite.
9.2.1. Surse de putere
Exist mai multe surse de putere ntr-o organizaie:
Recompensele: posibilitatea de a da oamenilor bonusuri, mriri de

salariu, premii etc.;
Constrngerile: controlul formal asupra penalizrilor, sanciunilor,
sau capacitatea informal de a ridiculiza public pe cineva etc.;
Cunoaterea: expertiza ntr-un anumit domeniu sau informaiile
specifice relevante pentru anumite decizii;
Relaiile: persoanele cunoscute care pot sprijini pe alii i i pot
transfera asupra lor o parte din propria putere i reputaie;
Influena: capacitatea de a-i convinge pe alii, indiferent de
cunotinele avute ntr-un anumit domeniu, presupunnd o
combinaie de abiliti de comunicare, siguran de sine, inteligen
emoional, putere de observaie etc.
135
Folosirea greit a puterii are loc atunci cnd o persoan i

urmrete propriul interes n locul obiectivelor proiectului. Aceast situaie
este facilitat de desincronizarea dintre obiectivele proiectului i realitate i
de lipsa unei viziuni comune asupra proiectului.
9.2.2. Tipuri de putere
Puterea funcional este de dou tipuri: acordat i ctigat.
Puterea acordat vine din ierarhie i din titlurile de serviciu (putere ex
officio). De exemplu, eful unei firme mici poate decide cine este angajat i
cine este concediat. ns acest tip de putere nu spune nimic despre respectul
pe care l au ceilali oameni fa de el. Prin contrast, puterea ctigat se
cultiv prin performane i aciuni, i apare atunci cnd oamenii ascult nu
fiindc li se impune acest lucru ci fiindc li se pare util.
O recomandare general este ca managerii s nu se bazeze pe
puterea acordat. A-i convinge pe oameni este mai eficient pe termen lung
dect a le impune. Puterea de convingere a unui manager crete dac este
dublat de ncrederea echipei. Acest lucru devine important mai ales n
momentele de criz cnd managerul este nevoit s le cear oamenilor s
ndeplineasc activiti mai dificile, s fac lucru suplimentar sau unele
aciuni care nu intr explicit n fia postului.
Conducerea pe baza puterii acordate limiteaz relaiile interumane,
exclude posibilitatea schimburilor de idei i se concentreaz pe folosirea
forei i nu a inteligenei. Cnd un conductor scoate sabia, nimeni nu-l mai
ascult pe conductor, ascult sabia. n plus, oamenii i vor pregti propriile
sbii ca rspuns. Cnd managerul va grei, unii subordonai i vor folosi
propria putere acordat pentru a-i contesta puterea acestuia, rezultnd ntr-o
competiie care nu are nimic de-a face cu rezolvarea problemei sau cutarea
celei mai bune soluii.
Folosirea puterii acordate este tentant deoarece este mai uoar:
conductorul nu trebuie s depun eforturi suplimentare pentru a obine ce
vrea. Cu toate acestea, conducerea bazat exclusiv pe puterea acordat
ndeprteaz oamenii inteligeni i independeni i i ncurajeaz pe cei
crora le place s li se spun ce s fac. De asemenea, tiranii creeaz ali
136
tirani pe nivelurile inferioare iar aceste modele de comportament otrvesc

pn la urm ntreaga organizaie.
Totui, un manager trebuie s fie autocrat cnd este necesar. Cnd
lucrurile scap de sub control, puterea acordat poate fi cel mai rapid mod
de a restabili ordinea. Cnd o edin degenereaz sau cnd angajamente
importante sunt nclcate, managerul trebuie s fie clar, direct i s-i
foloseasc autoritatea executiv pentru a asigura progresul proiectului.
Nevoia de a recurge des la puterea acordat este un semnal c n
organizaie sunt probleme fundamentale care trebuie rezolvate. Autocraia
poate ameliora simptomele, dar nu rezolv problemele de baz.
9.3. Procesul de feedback

Conductorii buni au suficient ncredere n colaboratori pentru a
primi reacii asupra propriilor performane. De multe ori reaciile se primesc
n mod privat. Conductorul nu este obligat s acioneze n conformitate cu
feedback-ul primit sau nici mcar s comenteze, ns este greu de imaginat
un proiect de succes n care s nu existe o cale sntoas i sigur prin care
astfel de informaii s ajung la manager.
Conductorii trebuie s i defineasc propriul proces de feedback.
Muli oameni au n general reineri n a-i critica efii. Cu toate acestea,
dac managerii stabilesc o modalitate de comunicare cu angajaii,
informaiile obinute sunt de obicei mai valoroase dect informaiile similare
obinute de la proprii lor manageri.
n contextul interaciunilor dintre angajai, trebuie s se fac
ntotdeauna distincia clar ntre criticarea unei idei i criticarea persoanei
care a avut ideea. Membrii echipei trebuie s se respecte i s aib suficient
ncredere unii n alii pentru a-i spune deschis prerile fr a trebui s-i
cear scuze, dar i fr maliiozitate sau comentarii nejustificate. Cnd
diferenele de opinie degenereaz n atacuri la persoan, managerul i poate
folosi puterea acordat pentru a aduce discuia pe un fga productiv pentru
proiect.
137
9.3.1. Greelile subordonailor

Este uor s ai ncredere n oameni cnd totul merge bine, ns
gestionarea greelilor este mai complicat. Cnd un angajat raporteaz
managerului o greeal, managerul trebuie s ia n considerare urmtoarele:
S-i spun angajatului c apreciaz faptul c a venit la el n loc s

ascund lucrurile sau s ncerce s le rezolve pe cont propriu i s
nruteasc situaia;
S identifice opiunile de rezolvare i s l ndrume pe ct posibil pe
angajat pentru ca acesta s ia el nsui msurile necesare;
S se asigure c dac exist o lecie de nvat, angajatul o va nva.
Pe lng ajutorul dat n rezolvarea unei probleme, managerii trebuie

s conduc procesul preschimbrii greelii ntr-o lecie pe care s-o nvee
echipa.
Membrii echipei nu trebuie s aib sentimentul c lucreaz singuri
sau c sunt sprijinii doar cnd lucrurile merg bine. De fapt, potenialul de a
face greeli este exact acelai potenial necesar pentru a contribui la succesul
proiectului. Mediul de lucru ideal este acela care permite oamenilor s fie
ambiioi, ns i determin s i admit greelile i s i asume
responsabilitatea pentru ele.
n timpul unei crize, nu se recomand pedepsirea unui angajat ct
vreme problema este nc nerezolvat. n acest mod nu se rezolv nimic iar
de cele mai multe ori scade probabilitatea rezolvrii rapide a problemei,
deoarece vinovatul, care tie cel mai mult despre aceasta, va intra n
defensiv. Dup ce lucrurile reintr n normal, cnd presiunea scade, este cel
mai potrivit moment pentru a analiza ce s-a ntmplat i de ce, i care sunt
leciile pentru individ, manager i echip.
138
9.4. Calitile necesare managerului de proiect

9.4.1. Energia
Una din cele mai importante trsturi necesare unui manager este
capacitatea de a trage echipa dup el, de a-i determina pe subordonai s
acioneze. Aceast capacitate este o combinaie ntre a ti cum s fie un
catalizator sau un motor n diverse situaii i a avea curajul s fac ceea ce
i propune.
Energia i determinarea sunt de obicei cerine cheie pentru angajarea
unui manager de proiect. Dac cineva nu este suficient de activ i flexibil
pentru a-i adapta abilitile i cunotinele la situaiile date i pentru a gsi
modaliti de a mpinge lucrurile nainte, atunci acesta probabil nu va fi
capabil s conduc un proiect tipic.
9.4.2. Perseverena
n orice situaie dificil exist ci mai simple: renunarea, acceptarea
unei soluii pariale, amnarea aciunii n sperana c lucrurile se vor rezolva
de la sine sau nvinovirea altora.
Calea dificil este confruntarea direct a problemei i urmrirea ei
pn la gsirea unei soluii acceptabile. Managerii de succes pur i simplu
nu renun uor, asta nsemnnd c iau n calcul mai multe alternative dect
oamenii obinuii i sunt siguri c n 99% din cazuri exist o rezolvare a
problemei (inclusiv prin schimbarea definiiei problemei). Cnd este
necesar, ei trebuie s acioneze n orice mod posibil. Aceasta poate nsemna
reorganizarea unei echipe disfuncionale, convingerea unor persoane dificile
s se pun de acord asupra obiectivelor sau aplanarea conflictelor dintre
angajai.
n caz de nenelegeri sau la negocieri, un manager perseverent poate
determina prile adverse s renune doar ca s fie lsate n pace.
Perseverena, dar nu agresivitatea, poate fi o tehnic eficient n sine.
139
9.4.3. Stabilirea i respectarea prioritilor

Prioritile clare sunt coloana vertebral a progresului. Evoluia
proiectului depinde de o nelegere clar a celor mai importante obiective i
aplicarea acestei perspective n fiecare interaciune care are loc n cadrul
echipei.
Multe dificulti de comunicare i pai greii apar din cauza
nelegerii diferite a prioritilor: de exemplu programatorul 1 pune accent
pe viteza programului iar programatorul 2 pe minimizarea resurselor de
memorie. Acelai lucru se ntmpl i cu echipele de proiectare, testare,
marketing etc. Stabilirea prioritilor ajut la concentrarea eforturilor pentru
avansarea ctre scopul final al proiectului n loc de rezolvarea conflictelor
aprute.
Stabilirea prioritilor, i n special a celor critice, permite refuzul
unor cerine sau funcionaliti. n aceste situaii, trebuie clarificat faptul c
refuzarea unor propuneri nu nseamn c ideile respective sunt rele n sine,
ci doar c nu se potrivesc ci doar c nu se potrivesc n stadiul curent al
proiectului.
9.5. Mecanisme de coordonare

Mintzberg distinge cinci configuraii organizaionale tipice:
Structura simpl: ntr-o structur simpl exist unul sau numai

civa manageri i un nucleu de persoane care lucreaz la proiectul
propriu-zis. Aceast configuraie este ntlnit de obicei n firmele
noi, cu personal redus. Specializarea este limitat, la fel i instruirea
i formalizarea. Mecanismul de coordonare corespunztor este
supervizarea direct;
Birocraia automat: Cnd coninutul sarcinilor este complet
specificat, este posibil executarea acestora pe baz de instruciuni
precise. Exemple tipice ale acestui tip de configuraie sunt producia
de mas i liniile de asamblare. Instruirea este redus, n schimb se
140
pune mare accent pe specializare i formalizare. Coordonarea se

obine prin standardizarea proceselor de lucru;
Forma divizionalizat: n acest tip de configuraie fiecrei divizii
(fiecrui proiect) i se acord o mare autonomie n ceea ce privete
modul de atingere a scopurilor. Detaliile sunt stabilite de divizii.
Coordonarea se obine prin standardizarea produciei. Controlul se
exercit regulat prin msurarea performanelor diviziilor. Acest
mecanism de coordonare este posibil numai atunci cnd este
specificat precis rezultatul final;
Birocraia profesional: Dac nu este posibil specificarea
rezultatului sau coninutul sarcinilor, coordonarea poate fi realizat
prin standardizarea calificrii. Profesionitii talentai se bucur de o
autonomie considerabil privind modul de ndeplinire a atribuiilor;
Adhocraia: n proiecte mari i/sau inovatoare, lucrul este divizat
ntre mai muli specialiti. n acest caz, poate fi greu sau chiar
imposibil de stabilit cu precizie ce trebuie s fac fiecare specialist
sau modul n care trebuie s-i ndeplineasc sarcinile. Succesul
proiectului depinde de capacitatea grupului de a atinge un scop
nespecificat ntr-un mod nespecificat. Coordonarea se obine prin
ajustare reciproc.
Trebuie spus c majoritatea organizaiilor reale nu pot fi ncadrate

ntr-un singur tip de configuraie. Diferite departamente ale firmei pot fi
organizate diferit. De asemenea, tipurile prezentate reprezint idei abstracte.
n realitate, organizaiile pot tinde spre unul din aceste tipuri, pstrnd n
acelai timp i caracteristici ale celorlalte.
9.6. Stiluri de management

Teoria lui Reddin a stilurilor de management distinge dou
dimensiuni ale managementului forei de munc:
gradul de dirijare a relaiilor: se refer la atenia acordat

individului i relaiilor lui cu ali indivizi din organizaie;
141
gradul de dirijare a activitilor: privete atenia acordat

rezultatelor care trebuie obinute i modului n care acestea trebuie
obinute.
Gradele de dirijare pot fi sczute sau ridicate, ceea ce conduce la

patru combinaii de baz, prezentate n tabelul 9.1.
Tabelul 9.1. Stilurile de management ale lui Reddin
gradul de dirijare a activitilor
sczut
ridicat
gradul de dirijare
sczut stil de separare stil de angajament
a relaiilor
stil de integrare
ridicat stil de relaionare
Stilul cel mai potrivit pentru o anumit situaie depinde de tipul

lucrrii:
Stilul de separare: Este cel mai potrivit pentru munca de rutin.

Eficiena este tema central. Managerul de proiect se comport ca un
birocrat care aplic reguli i proceduri. Acest stil corespunde
configuraiei de birocraie automat;
Stilul de relaionare: Este cel mai eficient n situaiile n care
oamenii trebuie motivai, coordonai i instruii. Sarcinile sunt clar
atribuite indivizilor. Munca nu are un caracter de rutin, ci este
inovatoare i specializat. Stilul este asemntor configuraiei de
adhocraie;
Stilul de angajament: Este cel mai eficient cnd se lucreaz sub
tensiune. Managerul de proiect trebuie s tie cum s se ating
scopurile fr s trezeasc resentimente. Stilul e asemntor
configuraiei de birocraie profesional;
Stilul de integrare: Se potrivete situaiilor cnd rezultatul este
nesigur. Munca are o natur exploratorie i sarcinile au un puternic
caracter de interdependen. Rolul managerului de proiect este s
stimuleze i s motiveze. i n acest caz, configuraia de adhocraie
este cea mai apropiat.
142
Fiecare proiect de dezvoltare software poate necesita diferite

mecanisme. De exemplu, pentru o echip experimentat, care trebuie s
dezvolte o aplicaie bine specificat ntr-un domeniu familiar, coordonarea
poate fi realizat prin standardizarea produciei. Pentru o aplicaie complex
i novatoare, acest mecanism ar fi ineficient.
143

Capitolul 10
Managementul comunicrii
10.1. Introducere
Comunicarea este procesul de trimitere a informaiilor de la o surs
la o destinaie prin intermediul unui mediu de transmitere i care presupune
nelegerea informaiilor n acelai mod att de ctre surs ct i de
destinatar.
Managementul comunicrii include procesele necesare pentru a
asigura la timp i n mod adecvat generarea, colectarea, diseminarea,
stocarea i punerea la dispoziie a informaiilor proiectului. Asigur
legturile critice dintre oamenii, ideile i informaiile necesare pentru
succesul proiectului. Toate persoanele implicate trebuie s fie pregtite s
trimit i s primeasc mesaje conform terminologiei adoptate n proiect i
s neleag cum aceste aciuni afecteaz proiectul n ansamblu.
Abilitile de comunicare sunt printre cele mai importante caliti pe
care trebuie s le aib un manager de proiect. Figura 10.1 prezint
rezultatele unui sondaj printre manageri privind importana pe care acetia o
acord calitilor necesare pentru managementul proiectelor.
n medie, 70% din timpul de lucru al unui manager se consum
pentru comunicare, avnd aproximativ structura din figura 10.2.

100%
90%
84%
75%
80%
70%
72%
68%
60%
48%
50%
40%
30%
20%
10%
0%
Abilitati de
comunicare
Abilitati
organizatorice
Abilitati de
"team building"
Abilitati de
conducere
Abilitati tehnice
Figura 10.1. Care din urmtoarele abiliti considerai

c sunt importante pentru un manager de proiect?
Figura 10.2. Tipuri de comunicare
146
10.2. Procesele principale ale managementului

comunicrii
Exist 4 procese principale de management al comunicrii:
Planificarea comunicrii: procesul care stabilete ce informaii sunt

necesare, cine are nevoie de ele i cine trebuie s le genereze, cnd
sunt necesare i cum trebuie furnizate; determin necesarul de
comunicare ntre persoanele implicate n proiect;
Distribuirea informaiilor: asigur faptul c informaiile necesare
sunt disponibile la timp;
Raportarea performanelor: colectarea i diseminarea informaiilor
referitoare la performanele atinse de proiect; rapoartele indic starea
curent, progresele nregistrate i prognozele;
ncheierea pe plan administrativ (engl. administrative closure):
generarea, colectarea i diseminarea informaiilor necesare pentru
formalizarea finalizrii unei faze sau a proiectului (de exemplu
documentarea rezultatelor).
10.3. Transmiterea informaiilor

Oamenii comunic prin simboluri, de la desenele rupestre la
codificarea digital a datelor, n diverse moduri: prin voce, scriere sau
gesturi. Indiferent de natura comunicrii, orice schimb de informaii
presupune 3 etape:
codificarea unui mesaj la surs;

transmiterea acestuia printr-un canal de comunicaie;
decodificarea mesajului la destinaie.
n prima etap, mesajul trebuie convertit ntr-o reprezentare

simbolic, de exemplu cuvinte, note muzicale, ecuaii matematice, bii etc.
Un mesaj La muli ani simbolizeaz o urare. Aceeai urare poate fi
147
transmis prin dispunerea pe un portativ a notelor muzicale ale cntecului

Muli ani triasc, numai c n acest caz se codific sunete.
Pentru ca un cod s fie util, trebuie trimis cuiva. Transmiterea poate
fi fcut de asemenea printr-o mare varietate de mijloace: direct prin voce,
printr-o scrisoare, prin telefon, prin e-mail etc. La destinaie, cineva trebuie
s recepioneze simbolurile i s le decodifice, comparndu-le cu propriul
bagaj informaional pentru a extrage datele utile.
Schema general a unui sistem de comunicaie este reprezentat n
figura 10.3. Mai nti, sursa de informaii produce mesajul care se dorete a
fi comunicat. Transmitorul acioneaz asupra mesajului, aducndu-l ntr-o
form convenabil pentru transmiterea prin canalul de comunicaii, adic
mediul folosit n acest scop. Aici apar de obicei zgomote care afecteaz
calitatea semnalului. Receptorul realizeaz n general operaia invers celei
executate de transmittor, pentru a reconstrui mesajul din semnalul primit.
Destinatarul este persoana sau dispozitivul cruia i este adresat mesajul.
Figura 10.3. Schema general a unui sistem de comunicaie
Comunicarea ntr-un grup este influenat de factori precum:
Dimensiunea grupului: cu ct este mai mare grupul, cu att este mai

dificil pentru oameni s comunice cu ali membri ai acestuia;
148
Structura grupului: comunicarea se realizeaz mai bine n grupuri cu

o structur informal dect n grupuri structurate ierarhic;
Alctuirea grupului: comunicarea se realizeaz mai bine atunci cnd
n grup exist tipuri de personaliti diferite i n grupuri mixte
(brbai i femei).
10.4. Bariere de comunicare

n figura 10.4 se prezint scderea nivelului de nelegere a unui
mesaj pe msura transmiterii lui n ierarhia organizaiei.
100%
100%
90%
80%
66%
70%
55%
60%
50%
40%
40%
30%
30%
20%
20%
10%
0%
Presedinte
Vicepresedinte
Manager
general
Manager de
proiect
Sef de
echipa
Membru al
echipei
Figura 10.4. Diminuarea nivelurilor de nelegere
n multe situaii mesajele pot fi blocate sau distorsionate i n

consecin nelesul lor poate fi modificat considerabil. Dintre cauzele
acestui fapt, menionm:
Percepiile distorsionate: mediul, starea psihic, statutul social sau

organizaional al sursei, chiar i subiectul mesajului sunt factori care
pot influena primirea corect a acestuia. Percepiile destinatarului
sunt afectate i de nevoia de a relaiona noile informaii cu informaii
anterioare primite i integrate;
149
Lipsa de ncredere a sursei: dac sursa comunic o informaie

greit sau care pare greit, coninutul mesajului nu mai conteaz
iar percepia mesajului va fi n concordan cu ateptrile
destinatarului;
Erorile de transmisie: limba este una din cauzele cele mai des
ntlnite pentru transmiterea eronat a unui mesaj. Pe lng cuvintele
propriu-zise i accentele diferite, conteaz experiena anterioar i
contextul cultural ale vorbitorilor;
Presupunerile diferite: asupra aciunilor care trebuie ndeplinite, n
ce moment, i dac trebuie trimis o ntiinare asupra realizrii lor
cu succes sau nu.
10.5. mbuntirea comunicrii

Pentru a mbunti comunicarea, se pot lua urmtoarele msuri:
Mesajul trebuie s fie relevant pentru destinatar: destinatarul trebuie

s fie interesat de coninutul mesajului (s aib ceva de ctigat de pe
urma sa). Faptul c sursa nelege mesajul nu garanteaz nelegerea
acestuia de ctre destinatar: nu conteaz ce spune sursa, conteaz ce
nelege destinatarul;
Mesajul trebuie redus la termenii cei mai simpli: detaliile inutile
necesit resurse suplimentare pentru decodarea esenei coninutului
mesajului;
Repetarea punctelor cheie: pe parcursul actului de comunicare este
util sintetizarea ideilor principale din timp n timp i repetarea
informaiilor importante.
10.5.1. mbuntirea procesului de ascultare
Dintre modalitile de optimizare a proceselor de comunicare i

ascultare, menionm:
150
Lipsa ntreruperilor: ntreruperile care nu sunt legate direct de

subiectul mesajului suspend firul logic al expunerii i reduc
eficiena comunicrii;
Favorizarea siguranei vorbitorului: muli manageri au emoii cnd
trebuie s vorbeasc n public. Pentru optimizarea transmiterii
mesajului, audiena trebuie s par interesat de subiect i s l
susin pe vorbitor prin comentarii i atitudini pozitive, atunci cnd
este cazul;
Eliminarea surselor de distragere a ateniei: ascultarea poate fi mult
mbuntit prin evitarea mediilor zgomotoase, de exemplu
nchiderea uilor, telefoanelor mobile etc.
10.6. Comunicarea scris

Comunicarea scris poate fi mai detaliat dect cea verbal i poate
fi utilizat pentru a explica unele chestiuni complexe care ar fi mai dificil de
neles ntr-un schimb verbal scurt. Comunicarea scris poate fi mai bine
organizat i d posibilitatea receptorului s revad materialele deja citite.
Acest tip de comunicare este important n etapele de definire a
proiectului, de desemnare a echipei i managerului, pentru c atunci este
nevoie de acte i mputerniciri. n etapa stabilirii modalitilor de control,
acestea trebuie precizate n scris. La evaluarea proiectului este de asemenea
nevoie de documente scrise, pentru ca rezultatele finale s poat fi
nregistrate i verificate mai trziu.
10.6.1. Redactarea email-urilor
n prezent, mare parte din comunicarea scris din cadrul
managementului de proiect, i n special din domeniul IT, se realizeaz prin
email. Volumul mare de email-uri primite determin presiunea de a le citi i
a rspunde repede, sacrificndu-se astfel calitatea mesajelor. ns claritatea
email-urilor, mai ales a celor aparinnd managerului de proiect, poate
influena foarte mult comunicarea n cadrul echipei i n final performanele
proiectului n ansamblu.
151
Vom prezenta n continuare o serie de recomandri privind scrierea

de email-uri utile pentru proiect. Acestea trebuie:
S fie concise, simple i directe. Expeditorul trebuie s aib n

vedere profilul persoanelor care vor citi email-ul i s decid care
detalii trebuie incluse i care trebuie omise, conform conceptelor pe
care expeditorul presupune c le cunosc receptorii. Pentru email-uri
importante sau destinate unui numr mare de persoane, este util ca
expeditorul s reciteasc mesajul dup cteva minute dup ce a fost
scris sau s roage un membru al echipei s l citeasc i s i spun
prerea;
S conin o cerere de aciune i un termen limit. Mesajul trebuie
s aib o intenie bine precizat, astfel nct receptorii s neleag de
ce l-au primit i ce trebuie s fac pn la termenul stabilit;
S se conformeze unor prioriti. Expeditorul trebuie s se ntrebe
dac este cu adevrat necesar s trimit un anumit email, sau dac
unele lucruri nu pot fi rezolvate mai uor la telefon sau ntr-o
discuie direct.
Managerul de proiect nu trebuie s plece de la premisa c toi

destinatarii vor citi un anumit email. Mai ales n cazul mesajelor destinate
unor persoane de pe niveluri ierarhice superioare, dac problema este foarte
important, managerul trebuie s fac unele eforturi suplimentare pentru a
se asigura c mesajul a fost ntr-adevr recepionat.
n cazul n care managerul nu nelege pe deplin coninutul unui
mesaj important, n locul unui email de rspuns cu ntrebri se recomand o
discuie telefonic sau direct pentru clarificri. Comunicarea interactiv
este mult mai eficient pentru rezolvarea confuziilor i conflictelor. Dup
clarificarea chestiunii, managerul poate trimite un email cu noile explicaii
tuturor celor interesai deoarece sunt mari ansele ca mesajul iniial s fi pus
probleme i altor persoane.
Dac subiectul sumarizeaz corect coninutul corpului mesajului,
destinatarii i vor modifica n mod corespunztor contextul mental nainte
de citirea mesajului propriu-zis. Dac problema ridicat n email este
urgent, subiectul poate fi prefaat de cuvntul URGENT. Dac prin email
152
nu se solicit un rspuns, subiectul poate fi prefaat de abrevierea FYI (engl.

For Your Information). Chiar dac informaiile indirecte sunt n principiu
benefice pentru schiarea unei imagini de ansamblu asupra lucrului la
proiect, acest tip de mesaje nu trebuie s domine conversaiile unei echipe.
10.7. Comunicarea verbal

Comunicarea verbal este mai rapid dect cea scris i permite
reacii i ntrebri din partea destinatarului. Mesajele verbale sunt ns mai
uor de trecut cu vederea. Comunicarea verbal este important deoarece
simultan se realizeaz i comunicarea non-verbal, care ajut la interpretarea
rezultatelor comunicrii.
10.7.1. Organizarea edinelor
n general, costul edinelor este foarte mare. Dac o edin dureaz
1 or i implic 10 persoane, costul su va fi de 10 ore-om. n loc s
depaneze programul, programatorii stau n sala de conferine ateptnd,
justificat sau nu, s aib loc ceva important.
Totui, dac ntr-o edin se discut decizii critice pentru progresul
proiectului sau se prezint informaii care pot schimba perspectiva tuturor
participanilor, atunci valoarea sa este mult mai ridicat i aceasta devine un
mod de comunicare ale crui rezultate ar fi dificil de obinut prin alte
mijloace.
Unul din motivele pentru care foarte multe edine sunt plictisitoare
pentru participani este nepotrivirea dintre scopurile edinei i structura sau
dimensiunea acesteia. n principal, exist 3 tipuri de edine:
Discuii cu un grad ridicat de interactivitate: Scopul este rezolvarea

unor probleme specifice i cutarea alternativelor, de exemplu
discuii de proiectare detaliat, brainstorming, managementul
crizelor, clasificarea defectelor. Dimensiunea este de 2-8 persoane i
toi participanii iau cuvntul;
153
Raportare sau discuii moderate: O persoan trebuie s expun nite

idei asupra crora dorete reaciile participanilor. Discuiile pot fi
interactive, dar implic numai un subgrup al participanilor.
Dimensiunea este de 5-15 persoane. De exemplu: analiza
specificaiilor, a arhitecturii, prezentri scurte;
Analize generale: Scopul este sintetizarea strii unei echipe sau a
unui ntreg proiect i ofer managementului de nivel nalt ansa s
prezinte noile linii directoare simultan unui ntreg grup.
Dimensiunea este de 10-100 persoane. De exemplu: analiza strii
unui proiect, prezentri lungi.
edinele nu sunt potrivite pentru:
ntiinri curente: dac fluxul informaional este unidirecional, este

mai potrivit un email;
Criticarea angajailor cu performane sczute: de obicei o astfel de
abordare nu crete motivarea angajailor respectivi; este mai potrivit
o discuie fa n fa;
Creterea entuziasmului: motivarea este o provocare zilnic a
managerului de proiect; sunt mai potrivite discuii private cu fiecare
membru al echipei i rezolvarea problemelor fiecruia separat.
n continuare sunt prezentate cteva recomandri pentru a organiza o

edin productiv:
O edin reuit are nevoie de o persoan cu rol de facilitator, care

s i ajute pe ceilali s aib un dialog constructiv. Pe lng rolul de
stabilire a agendei de discuii i de direcionare a ideilor pe un fga
util pentru proiect, facilitatorul poate elimina neclaritile de
exprimare ale unor persoane, refraznd sau rafinnd unele intervenii
pentru a fi mai uor nelese de ceilali participani;
Organizatorii trebuie s se asigure c sunt prezente numai persoanele
necesare. Dac nu pot fi invitate aceste persoane, este mai bine s se
amne edina. Dac n sal sunt prezente i alte persoane care ar
putea afecta bunul mers al discuiilor, acestora li se poate promite c
154
li se vor trimite notele discuiilor (minuta ntlnirii), ns este bine s

fie invitate politicos s se retrag;
Conductorii discuiilor trebuie s pregteasc atent edina. Multe
ntlniri eueaz din cauza lipsei de pregtire. Pregtirea poate
consta ntr-o list de ntrebri sau de probleme deschise, sau poate fi
mai complex, presupunnd o demonstraie sau documente ce
trebuie nmnate participanilor nainte de nceperea discuiilor;
Dac este posibil, trebuie descurajat folosirea laptop-urilor sau a
altor dispozitive care ar putea distrage atenia participanilor de la
discuii;
edina trebuie finalizat cu un plan de aciune ulterioar, o serie de
aciuni bine definite i responsabilii care se vor ocupa de acestea. O
parte din pregtirea edinei se refer la modalitile de a ajunge la
un acord privind acest plan i la identificarea celor mai potrivite
persoane care s realizeze activitile aferente.
155

Capitolul 11
Managementul riscului
11.1. Introducere
Managementul riscului implic anticiparea situaiilor care pot afecta
graficul de lucru al proiectului i calitatea produsului software dezvoltat
precum i luarea unor msuri pentru evitarea sau limitarea efectelor lor. Un
management de risc eficient asigur faptul c problemele aprute nu vor
conduce la depiri inacceptabile ale bugetului i termenelor limit.
Exist 3 categorii de riscuri:
1. Riscuri referitoare la proiect: afecteaz graficul de lucru sau
resursele proiectului, de exemplu pierderea unui arhitect software
experimentat;
2. Riscuri referitoare la produsul software: afecteaz calitatea sau
performanele produsului dezvoltat, de exemplu cnd o component
cumprat sau un instrument de dezvoltare nu funcioneaz potrivit
ateptrilor;
3. Riscuri privind mediul comercial: afecteaz organizaia, de exemplu
apariia unui produs nou al unui competitor.
Desigur, aceste tipuri de risc se pot suprapune. Dac un programator
cu experien prsete proiectul, aceast situaie constituie un risc pentru
proiect deoarece livrarea sistemului poate fi ntrziat. Poate fi un risc i
pentru produs deoarece persoana nlocuitoare poate fi mai puin competent
i poate face mai multe erori. Poate fi i un risc comercial pentru
organizaie, deoarece experiena programatorului nu mai poate fi folosit
pentru demararea unor anumite proiecte n viitor.
Multe riscuri sunt comune pentru un mare numr de proiecte
software, de exemplu cele prezentate n tabelul 11.1.

Tabelul 11.1. Riscuri posibile n proiecte software

Risc
Tip de risc
Pierderile de personal
Proiect
Schimbarea conducerii
Proiect
Indisponibilitatea
hardware-ului
Proiect
Schimbarea cerinelor
Proiect i produs
ntrzierea specificaiilor
Proiect i produs
Subestimarea dimensiunii
Proiect i produs
Performanele slabe ale

instrumentelor CASE
Produs
Schimbarea tehnologiei
Comercial
Concurena produsului
Comercial
Descriere
Personalul cu experien
pleac nainte ca proiectul s
fie terminat
Are loc o schimbare a
managementului organizaiei,
care are alte prioriti
Hardware-ul esenial pentru
proiect nu este livrat la timp
Exist un numr mai mare de
schimbri ale cerinelor dect
a fost anticipat
Specificaiile privind
interfeele principale nu sunt
disponibile la timp
Dimensiunea sistemului a fost
subestimat
Instrumentele CASE pe care
se bazeaz proiectul nu dau
performanele dorite
Tehnologia care st la baza
sistemului este nlocuit de o
nou tehnologie
Un produs concurent este
lansat nainte ca sistemul s
fie terminat
Managementul riscului este important n special pentru proiectele

software din cauza incertitudinilor inerente cu care se confrunt majoritatea
proiectelor. Acestea provin din definirea incomplet a cerinelor, din
dificultile de estimare a timpului i resurselor necesare pentru dezvoltare,
din dependena de abilitile individuale, din schimbrile cerinelor care
reflect schimbarea nevoilor clienilor etc.
Procesul de management al riscului este ilustrat n figura 11.1 i
implic mai multe faze:
158
1. Identificarea riscurilor posibile referitoare la proiect, produs sau

mediul comercial;
2. Analiza riscurilor: evaluarea probabilitilor i consecinelor
riscurilor;
3. Planificarea gestionrii riscurilor: ntocmirea unor planuri pentru
evitarea riscurilor sau minimizarea efectelor acestora asupra
proiectului;
4. Monitorizarea riscurilor: actualizarea evalurilor i revizuirea
planurilor atunci cnd apar informaii suplimentare.
Figura 11.1. Procesul de management al riscului
Procesul de management al riscului este iterativ i continu pe

parcursul ciclului de via al proiectului. Rezultatele analizei riscurilor
trebuie documentate n planul proiectului mpreun cu consecinele apariiei
factorilor de risc i msurile care trebuie luate n aceast eventualitate.
11.2. Analiza SWOT

Analiza SWOT (engl. Strengths Weaknesses Opportunities
Threats, rom. Puncte tari Puncte slabe Oportuniti Ameninri)
poate constitui o etap preliminar n managementul riscului. Ea ajut la
gsirea corespondenelor optime dintre tendinele mediului extern
(oportunitile i ameninrile) i posibilitile interne ale organizaiei.
Folosit ca un instrument de analiz a riscului, poate identifica ariile cele
mai sensibile dar i caracteristicile cele mai puternice ale organizaiei.
Termenii cheie ai analizei SWOT se definesc astfel:
159
Un punct tare este o resurs sau o abilitate pe care organizaia o

poate utiliza eficient pentru a-i atinge obiectivele, ce poate fi fcut
sau ce poate fi folosit;
Un punct slab este o limitare sau un defect care mpiedic
organizaia s-i ndeplineasc obiectivele, ce nu poate fi fcut sau
ce nu poate fi folosit;
O oportunitate este orice situaie favorabil din mediul exterior al
organizaiei care o ajut s-i ating scopurile. De obicei este o
tendin sau o schimbare, o necesitate neglijat care crete cererea
pentru un anumit produs i care permite organizaiei s reduc
riscurile;
O ameninare este o situaie defavorabil din mediul exterior cu
potenialul de a perturba organizaia. Ameninarea poate fi o barier,
o constrngere sau orice situaie extern care poate cauza probleme.
Dup cum se arat n figura 11.2, poriunea intern reflect

capacitatea organizaiei. Poriunea extern identific factorii de succes sau
obstacolele pentru implementare sau performan.
Figura 11.2. Relaiile dintre mediul intern i mediul extern

al unei organizaii n analiza SWOT
Dup terminarea analizei, profilul SWOT poate fi utilizat ca baz

pentru estimarea severitii riscurilor i determinarea celor mai potrivite
modaliti de confruntare i minimizare a acestora.
160
Analiza SWOT se bazeaz pe ntrebri adresate de manageri pentru a

determina n jur de 5 factori principali n fiecare categorie. Mai mult de 5
factori pot fi inclui doar dac sunt suficient de diferii ntre ei i sunt critici
pentru conturarea riscurilor majore. Exemple de astfel de ntrebri sunt
prezentate n tabelul 11.2.
Tabelul 11.2. ntrebri pentru realizarea analizei SWOT
Puncte tari
Puncte slabe
Ce avantaje are organizaia?
Ce s-ar putea mbunti?
Ce face organizaia mai bine dect

oricine altcineva?
Ce ar trebui evitat?
La ce resurse unice sau ieftine are

acces?
Ce puncte sunt considerate drept

slbiciuni de ctre oamenii din acelai
segment de pia?
Ce puncte tari i recunosc oamenii din

acelai segment de pia?
Ce factori afecteaz performanele

organizaiei?
Ce factori i determin succesul?

Oportuniti
Ameninri
Unde sunt oportunitile care pot

influena organizaia?
Ce obstacole ar putea ntmpina

organizaia?
Care sunt tendinele externe cele mai

promitoate pentru organizaie?
Ce aciuni ale concurenei ar trebui s

ngrijoreze?
Schimbri n tehnologie i pia la scar

mic i mare
Se modific specificaiile pentru

produs?
Schimbri n politicile guvernamentale

legate de domeniul de activitate al
organizaiei
Se modific tehnologiile?
Schimbri n modelele sociale, profiluri

de populaie, schimbri n stilul de via
etc.
Poate un anumit punct slab s i

amenine serios organizaiei poziia pe
pia?
Exist probleme de lichiditate sau

datorii?
Evenimente locale
161
Analiza SWOT este util att pentru identificarea cilor de aciune

ct i pentru punerea problemelor ntr-o perspectiv mai larg. Analiza
poate ajuta la descoperirea oportunitilor care pot fi exploatate cu ajutorul
punctelor tari i la nelegerea punctelor slabe care pot fi gestionate pentru a
elimina ameninrile. De asemenea, analiza SWOT poate oferi indicaii
asupra strategiilor prin care organizaia se poate diferenia de competitori
pentru a-i asigura succesul pe pia.
11.3. Identificarea riscurilor

Identificarea riscurilor i propune descoperirea posibilelor situaii de
risc pentru proiect. n principiu, acestea nu ar trebui evaluate sau prioritizate
n aceast faz, ns n practic riscurile cu consecine minore sau cu
probabiliti foarte mici sunt eliminate.
Tolerana la risc este msura n care o organizaie sau o persoan
este dispus s i asume riscuri. Companiile, ca i oamenii, au tolerane
diferite la risc. Unele i asum mai multe riscuri ncercnd s ctige mai
mult iar altele sunt mai conservatoare. n cadrul bugetului unui proiect,
trebuie s existe o anumit rezerv care s poat fi folosit la nevoie pentru
gestionarea riscurilor.
Identificarea riscurilor poate fi realizat printr-un proces de echip,
prin brainstorming sau pe baza experienei personale a managerului. Se
recomand utilizarea unei liste de verificare cu diferite tipuri de risc. Pot
aprea 6 astfel de tipuri:
1. Riscuri tehnologice, care privesc tehnologiile software i hardware
utilizate pentru a dezvolta sistemul;
2. Riscuri de personal, asociate cu membrii echipei de dezvoltare;
3. Riscuri organizaionale, derivate din mediul organizaional unde se
dezvolt produsul software;
4. Riscuri privind instrumentele de dezvoltare, precum instrumentele
CASE (engl. Computer-Aided Software Engineering) sau alte
produse software auxiliare utilizate pentru dezvoltarea sistemului;
162
5. Riscuri privind cerinele, care deriv din gestionarea schimbrilor

cerinelor clientului;
6. Riscuri de estimare, derivate din estimrile managerilor privind
caracteristicile i resursele necesare pentru construirea sistemului.
Tabelul 11.3 prezint cteva exemple de riscuri posibile din fiecare
categorie.
Tabelul 11.3. Riscuri i tipuri de risc
Tipul de risc
Tehnologia
Personalul
Organizaia
Instrumentele
Cerinele
Estimrile
Riscuri posibile
Sistemul de baze de date utilizat nu poate efectua un numr
suficient de tranzacii pe secund, conform cerinelor.
Componentele software care ar trebui reutilizate conin defecte
care le limiteaz funcionalitatea
Este imposibil recrutarea de personal avnd calificarea dorit.
Personalul cheie este bolnav i indisponibil n momentele
critice.
Instruirea personalului este necesar, dar nu se poate efectua.
Organizaia este restructurat astfel nct se schimb
managementul responsabil pentru proiect.
Problemele financiare ale organizaiei impun reducerea
bugetului proiectului.
Codul generat de instrumentele CASE nu este eficient.
Instrumentele CASE nu pot fi integrate.
Sunt propuse schimbri ale cerinelor care necesit modificri
majore ale arhitecturii.
Clienii nu neleg impactul pe care l au schimbrile cerinelor.
Timpul necesar pentru dezvoltarea produsului software este
subapreciat.
Rata de reparare a defectelor este supraestimat.
Dimensiunea produsului software este subestimat.
163
11.4. Analiza riscurilor

Pentru fiecare factor de risc identificat trebuie estimate probabilitatea
i gravitatea efectelor. Aceste estimri nu sunt simple, ci se bazeaz pe
experiena anterioar. De aceea, managerii experimentai sunt n general
cele mai potrivite persoane pentru a face analiza.
Valoarea ateptat (engl. expected value) este o metod prin care
se combin probabilitatea i impactul unui risc. Valoarea ateptat
reprezint produsul dintre probabiliti i efecte, msurate n bani, zile de
lucru sau orice alt unitate de msur convenabil.
Cu ajutorul valorilor ateptate se pot evalua oportunitile i riscurile
proiectului. Valorile ateptate pot oferi i o perspectiv bun asupra
efortului financiar necesar pentru eliminarea riscurilor.
De exemplu, dac exist o probabilitate de 10% a apariiei unui
factor de risc care s aib ca impact pierderi de 5000 euro asupra proiectului
i exist o probabilitate de 5% a unor pierderi de 15000 euro, valoarea
ateptat a acestui risc este de: 0,1 5000 0,05 15000 1250 euro. Dac
exist posibilitatea evitrii complete a riscului prin cheltuirea a 1000 euro,
atunci aceast soluie este considerat o decizie corect.
De multe ori, estimrile de risc nu exprim valori numerice precise,
ci anumite intervale:
Probabilitatea riscului poate fi estimat ca: foarte mic (<10%),

mic (10-25%), moderat (25-50%), mare (50-75%) sau foarte mare
(>75%);
Efectul poate fi estimat ca: nesemnificativ, suportabil, serios sau
catastrofal.
Rezultatele se prezint tabelar, factorii de risc fiind sortai dup

gravitate. Tabelul 11.4 ilustreaz acest proces pentru riscurile identificate n
tabelul 11.3. n acest exemplu, evalurile sunt arbitrare. n practic, este
nevoie de informaii detaliate despre proiect, procesele de lucru, echipa de
dezvoltare i organizaie.
164
Tabelul 11.4. Analiza riscurilor

Risc
Problemele financiare ale organizaiei impun
reducerea bugetului proiectului
Este imposibil recrutarea de personal avnd
calificarea dorit
Personalul cheie este bolnav i indisponibil n
momentele critice
Componentele software care ar trebui reutilizate
conin defecte care le limiteaz funcionalitatea
Sunt propuse schimbri ale cerinelor care
necesit modificri majore ale arhitecturii
Organizaia este restructurat astfel nct se
schimb managementul responsabil pentru
proiect
Sistemul de baze de date utilizat nu poate efectua
un numr suficient de tranzacii pe secund,
conform cerinelor
Timpul necesar pentru dezvoltarea produsului
software este subapreciat
Instrumentele CASE nu pot fi integrate
Clienii nu neleg impactul pe care l au
schimbrile cerinelor
Instruirea personalului este necesar, dar nu se
poate efectua
Rata de reparare a defectelor este supraestimat
Dimensiunea produsului software este
subestimat
Codul generat de instrumentele CASE nu este
eficient
Probabilitate Efect
mic
catastrofal
mare
catastrofal
moderat
serios
moderat
serios
moderat
serios
mare
serios
moderat
serios
mare
serios
mare
suportabil
moderat
suportabil
moderat
suportabil
moderat
suportabil
mare
suportabil
moderat
nesemnificativ
Att probabilitatea ct i estimarea efectelor se pot modifica atunci

cnd devin disponibile informaii suplimentare sau dup ce se
implementeaz planurile de gestionare a riscurilor. n consecin, acest tabel
trebuie actualizat la fiecare iteraie a procesului de management al riscului.
Dup ce riscurile au fost analizate i prioritizate, trebuie determinate
riscurile cele mai importante, pe baza combinaiei probabilitii de apariie
165
cu efectele generate. Se recomand ca riscurile catastrofale s fie luate

ntotdeauna n considerare, la fel i riscurile serioase cu probabilitate de
apariie moderat, mare sau foarte mare. De exemplu, n tabelul 11.4 ar
trebui considerai 8 factori de risc, cei cu consecine catastrofale sau
serioase.
Numrul de factori de risc trebuie s fie gestionabil. Un numr foarte
mare ar presupune colectarea unei cantiti prea mari de informaii. Numrul
optim difer de la proiect la proiect, ns Boehm recomand selectarea
primilor 10 factori de risc, n ordinea importanei.
11.5. Planificarea gestionrii riscurilor

n aceast faz, se iau n calcul factorii de risc cheie descoperii
anterior i se identific strategiile pentru gestionarea lor. Nici acest proces
nu este unul simplu i se bazeaz pe gndirea i experiena managerilor.
Tabelul 11.5 arat cteva strategii posibile pentru factorii de risc din tabelul
11.4. Aceste strategii pot fi incluse n 3 categorii:
1. Strategii de evitare: determin scderea probabilitii de apariie a
riscului, de exemplu strategia de gestionare a componentelor defecte;
2. Strategii de minimizare: determin reducerea impactului factorului de
risc, de exemplu strategia pentru gestionarea problemelor medicale ale
personalului;
3. Strategii de criz (engl. contingency plans): indic msurile care
trebuie luate atunci cnd apariia unei situaii de criz este
inevitabil, de exemplu strategia pentru problemele financiale ale
organizaiei.
166
Tabelul 11.5. Strategii de gestionare a riscurilor

Risc
Probleme financiare
ale organizaiei
Probleme de recrutare
mbolnvirea
personalului
Componente defecte
Schimbri ale
cerinelor
Restructurarea
organizaiei
Performanele
sistemului de baze de
date
Subestimarea timpului
de dezvoltare
Strategie de gestionare
Pregtirea unui raport de informare pentru managementul
superior care s arate contribuia foarte important a
proiectului asupra scopurilor comerciale
Avertizarea clientului c vor exista posibile dificulti i
ntrzieri, investigarea achiziionarii de componente gata
fcute
Reorganizarea echipei astfel nct activitile s se
suprapun mai mult i deci membrii echipei s neleag
mai bine munca celorlali
nlocuirea posibilelor componente defecte cu alte
componente achiziionate care funcioneaz
corespunztor
Stabilirea informaiilor de trasabilitate pentru a evalua
impactul schimbrilor cerinelor, maximizarea
abstractizrii arhitecturii
Pregtirea unui raport de informare pentru managementul
superior care s arate contribuia foarte important a
proiectului asupra scopurilor comerciale
Investigarea posibilitii de a cumpra un sistem de baze
de date mai performant
Investigarea posibilitii de a cumpra componente gata
fcute i de a folosi generatoare de programe
11.6. Monitorizarea riscurilor

Monitorizarea riscurilor presupune evaluarea riscurilor identificate
pentru a decide dac probabilitatea lor scade sau crete i dac efectele lor
posibile se modific. De multe ori, acestea nu se pot observa direct i deci
trebuie luai n calcul ali factori care ar putea influena probabilitatea i
impactul riscurilor, factori care depind de tipurile de risc. Tabelul 11.6
prezint cteva exemple de factori utili n estimarea tipurilor de risc.
Monitorizarea riscurilor trebuie s fie un proces continuu i la fiecare
167
ntlnire pentru discutarea progresului proiectului, trebuie s se discute

separat i factorii de risc cheie.
Tabelul 11.6. Factori de risc
Tipul de risc
Tehnologia
Personalul
Organizaia
Instrumentele
Cerinele
Estimrile
Indicatori poteniali
Livrarea cu ntrziere a hardware-ului sau software-ului de
suport, raportarea a numeroase probleme legate de tehnologie
Moralul prost al personalului, relaiile tensionate ntre membrii
echipei, disponibilitatea altor posturi
Zvonuri, pasivitatea managementului superior
Reticena membrilor echipei de a folosi instrumentele CASE,
plngeri legate de astfel de instrumente, cereri pentru staii de
lucru mai puternice
Numeroase cereri de schimbare a cerinelor, nemulumiri ale
clientului
Eecul respectrii graficului de lucru stabilit, eecul rezolvrii
defectelor raportate
168
Capitolul 12
Analiza deciziilor
12.1. Introducere
Cele mai multe persoane i desfoar activitatea de zi cu zi fr a
lua decizii. Acestea reacioneaz la evenimente, fr a-i acorda timp s
decid asupra lor. Cnd telefonul sun i dac sunt disponibile, ridic
receptorul i rspund. n aceste situaii, ele nu decid, ci doar lucreaz. Cu
toate acestea, uneori au nevoie s ia decizii. Dac trebuie s angajeze pe
cineva i exist mai muli candidai, trebuie s ia o decizie.
Spre deosebire de urmarea unei rutine, cineva ia o decizie atunci
cnd are mai multe direcii pe care le poate urma. A decide nseamn a
ajunge la o soluie care pune capt incertitudinii sau disputei legate de ceea
ce trebuie fcut. O decizie se ia atunci cnd modul n care se poate aciona
este selectat dintr-o serie de alternative. Mai formal, o decizie are
urmtoarele componente:
O mulime de alternative sau opiuni;

Fiecare alternativ conduce la o serie de consecine pe care
decidentul nu le poate controla;
Decidentul este nesigur n legtur cu ceea ce s-ar putea ntmpla;
Decidentul are diferite preferine cu privire la rezultate asociate cu
diversele consecine;
O decizie implic alegerea ntre rezultate incerte cu valori diferite.
Analiza deciziilor este procesul de separare a unei decizii complexe

n prile sale componente i reconstituirea ntregii decizii prin folosirea
unei formule matematice. Este o metod de a ajuta decidenii s fac alegeri
simple i familiare i apoi, prin folosirea unui model matematic, de a deduce
decizia complex pe baza compunerii acestora.

Principalele elemente implicate n procesul de decizie sunt:
un numr de posibile aciuni, Ai, dintre care va fi selectat una;

un numr de evenimente sau stri ale naturii, Sj, din care oricare
poate avea loc;
valoarea, profitul sau consecina, Pij, pentru decident, de realizare a
uneia din aciunile disponibile, avnd n vedere posibilele stri ale
naturii;
criteriul n funcie de care decidentul alege ntre aciunile alternative.
Tabelul 12.1. Matricea profiturilor
Aciunile
A1
A2
A3
S1
P11
P21
P31
Strile naturii
S2
S3
S4
P12
P13
P14
P22
P23
P24
P32
P33
P34
S5
P15
P25
P35
12.2. Decizii n condiii de certitudine

12.2.1. Analiza Pareto
Analiza Pareto este o tehnic foarte simpl care ajut la alegerea
celei mai eficace schimbri. Folosete principiul Pareto, a crui idee de baz
este c prin realizarea a 20% din volumul de lucru se poate genera 80% din
avantajul realizrii ntregii lucrri. Analiza Pareto este o tehnic formal
pentru gsirea schimbrilor care vor aduce cele mai mari beneficii. Este util
atunci cnd concureaz mai multe moduri n care se poate aciona.
170
Modul de folosire
1. Pentru a folosi acest instrument, se noteaz o list de schimbri care
s-ar putea realiza. Dac este o list lung, se grupeaz n schimbri
nrudite;
2. Apoi se acord un scor fiecrui articol sau fiecrui grup. Metoda de
acordare a punctajului depinde de problema care trebuie rezolvat.
De exemplu, dac se dorete mrirea profitului, se vor puncta
opiunile pe baza profitului pe care fiecare grup l-ar putea genera.
Dac se ncearc creterea satisfaciei clientului, se poate stabili
punctajul pe baza numrului de plngeri eliminate de fiecare
schimbare;
3. Prima schimbare care se va produce va fi cea cu punctajul cel mai
mare. Aceasta va oferi cel mai mare beneficiu n cazul rezolvrii;
4. Opiunile cu punctajul cel mai mic probabil nu vor merita s fie
rezolvate; rezolvarea acestora ar putea costa mai mult dect soluia
n sine.
Exemplu
Un manager se ocup de reabilitarea unui centru de asisten. El i
propune s afle de ce clienii sunt de prere c serviciul nu este bun. Astfel,
primete urmtoarele comentarii de la clieni:
1. Telefoanele sunt preluate dup multe tonuri de apel;
2. Personalul pare distras i sub presiune;
3. Inginerii nu par a fi bine organizai. Au nevoie de o a doua vizit
pentru a aduce i alte piese de schimb, deci clienii trebuie s-i ia
mai mult timp liber pentru a fi prezeni cnd are loc cea de-a doua
vizit;
4. Clienii nu tiu cnd va avea loc cea de-a doua vizit, ceea ce i
determin s fie prezeni ntreaga zi n ateptarea inginerului;
5. Membrii personalului nu par a ti ntotdeaua ceea ce fac;
6. Uneori, la sosirea membrilor personalului, clientul constat c
problema s-ar fi putut rezolva la telefon.
171
Managerul grupeaz aceste probleme, apoi le acord un punctaj n

funcie de numrul de plngeri i ordoneaz lista:
Scpri n instruirea personalului: punctele 5 i 6 51 plngeri;

Personal insuficient: punctele 1, 2 i 4 21 plngeri;
Organizare i pregtire deficitare: punctul 3 2 plngeri.
n urma analizei Pareto, managerul poate observa c majoritatea

problemelor (69%) pot fi rezolvate prin mbuntirea abilitilor
personalului. Odat rezolvat acest lucru, ar fi inutil creterea numrului de
membri ai personalului. Alternativ, cu ct membrii personalului sunt mai
capabili s rezolve problemele prin intermediul telefonului, este posibil ca
necesitatea de mrire a personalului s se diminueze. Se observ c ntruct
exist mai puine comentarii n legtur cu deficienele de organizare i
pregtire, acestea ar putea avea cauze dincolo de controlul managerului.
Prin efectuarea unei analize Pareto, managerul se poate concentra
asupra instruirii ca o problem de sine stttoare, n loc s-i iroseasc
eforturile ncercnd att instruirea ct i angajarea de noi membri de
personal i eventual instalarea unui nou sistem informatic.
Analiza Pareto este o tehnic simpl care ajut la identificarea celor
mai importante probleme. Pe lng faptul c scoate n eviden cea mai
important problem de rezolvat, ofer de asemenea un punctaj care arat
ct de sever este aceasta.
12.2.2. Analiza comparrii perechilor
Analiza comparrii perechilor este util pentru determinarea
importanei relative a unor opiuni, mai ales atunci cnd nu exist date
obiective pe care s se poat baza procesul de decizie. Metoda faciliteaz
alegerea celei mai importante probleme care trebuie rezolvat, sau a soluiei
care aduce cel mai mare profit. De asemenea, permite stabilirea prioritilor
atunci cnd apar cerine contradictorii asupra resurselor.
Este de asemenea un instrument ideal pentru a compara merele cu
perele, opiuni complet diferite precum acelea de a investi n marketing,
ntr-un nou sistem IT sau ntr-o nou pies a unui mecanism. Aceste decizii
172
sunt de obicei mult mai greu de luat dect alegerea unui sistem IT din trei
variante posible, de exemplu.
Modul de folosire
1. Se noteaz opiunile care se vor compara. Se atribuie o liter fiecrei
opiuni;
2. Se marcheaz opiunile sub form de cap de tabel pe linii i coloane;
3. Celulele din tabel unde se compar o opiune cu ea nsi sunt
blocate;
4. Celulele din tabel n care apar comparaii duplicate sunt de asemenea
blocate;
5. n cadrul celulelor rmase, se compar opiunea de pe linie cu cea de
pe coloan. Pentru fiecare celul, se decide care dintre cele dou
opiuni este mai important. Se noteaz litera celei mai importante
opiuni n celul i se puncteaz diferena de importan de la 0
(nicio diferen) la 3 (diferen major);
6. n final, se calculeaz totalul tuturor valorilor pentru fiecare opiune.
Aceste rezultate se pot converti n procentaje din scorul total.
Exemplu
Un om de afaceri studiaz cile prin care s-i extind afacerea. Are
resurse limitate, dar i urmtoarele opiuni:
S se extind pe pieele externe;

S se extind pe pieele interne;
S mbunteasc relaiile cu publicul;
S asigure creterea calitii produselor.
La nceput, se realizeaz tabelul pentru analiza comparrii

perechilor. Apoi se compar opiunile, se noteaz litera celei mai importante
opiuni i se calculeaz diferena de importan (tabelul 12.2).
173
Tabelul 12.2. Analiza comparrii perechilor
n final, se adun valorile pentru A, B, C, D i se convertete fiecare

valoare ntr-un procentaj. Se obin urmtoarele totaluri:
A = 3 (37,5%);
B = 1 (12,5%);
C = 4 (50%);
D = 0.
n acest caz, lucrul cel mai important este s se mbunteasc

relaiile cu publicul (C) i apoi s se abordeze pieele de export (A).
Calitatea nu are o prioritate mare, probabil c este deja bun.
Analiza comparrii perechilor este o modalitate util de a cntri
importana relativ a diferitelor aciuni, cnd prioritile nu sunt clare.
Metoda asigur un cadru de lucru pentru compararea fiecrei aciuni cu
toate celelalte i ajut la evidenierea diferenei de importan dintre factori.
12.2.3. Analiza matricei de decizii
Analiza matricei de decizii (cunoscut i ca analiza grid, Pugh
matrix analysis sau multi-attribute utility theory) este puternic mail ales
cnd exist un numr de alternative din care se alege i muli factori de luat
174
n considerare. Acest lucru face tehnica important pentru aproape toate

problemele de decizie n care nu exist o opiune clar sau evident.
Modul de folosire
Tehnica funcioneaz prin listarea ntr-un tabel a opiunilor pe linii i
a factorilor care trebuie luai n considerare pe coloane. Apoi se stabilete un
punctaj pentru fiecare celul i se calculeaz scorul total pentru fiecare
opiune.
1. Mai nti, se listeaz toate opiunile pe linii i toi factorii pe
coloane;
2. Apoi se decide importana relativ a factorilor de decizie ca fiind un
numr de la 0 la 5, unde 0 nseamn c factorul nu conteaz deloc n
decizia final iar 5 nseamn c factorul este foarte important. Se
accept factori cu aceeai importan. Valorile stabilite pot fi
evidente, dar n cazul n care nu sunt evidente, se folosete o metod
precum cea a analizei comparrii perechilor pentru a le estima;
3. Urmtorul pas este ataarea unui punctaj fiecrei opiuni pentru
fiecare factor de decizie. Se stabilete un punctaj de la 0 la 5 pentru
fiecare opiune. Se observ c nu trebuie s existe un punctaj diferit
pentru fiecare opiune; dac niciuna dintre ele nu este potrivit
pentru un anumit factor de decizie, atunci toate opiunile vor avea
punctajul 0;
4. Se multiplic fiecare din punctajele de la pasul 3 cu valoarea
importanei relative calculate la pasul 2. Se obin astfel punctaje
pentru fiecare combinaie opiune-factor;
5. n final, se sumeaz aceste punctaje pentru fiecare dintre opiuni. Se
alege opiunea cu punctajul cel mai mare.
Exemplu
Un surfer entuziast dorete s-i schimbe maina. Are nevoie de una
cu care nu doar s transporte planeta i pnzele, ci s fie bun i pentru
cltorii de afaceri. ntotdeauna i-au plcut mainile sport. ns nicio main
nu respect toate cele trei preferine. Opiunile sale sunt:
175
Un SUV/4x4;
O main de familie confortabil;
O main break (station wagon n tabelele 12.3 i 12.4);
O main sport decapotabil.
Criteriile pe care le ia n considerare sunt:
Costul;
Posibilitatea de a transporta n mod sigur o plac pentru windsurfing;
Posibilitatea de a depozita n siguran pnze i echipamente;
Confortul pe distane lungi;
Distracia;
Aspectul plcut i calitatea.
n primul rnd, se realizeaz tabelul de mai jos i se stabilesc

punctaje pentru fiecare opiune, n funcie de ct de bine satisface aceasta
fiecare factor.
Tabelul 12.3. Analiza matricei de decizii pentru evaluarea neponderat
a modului n care fiecare tip de main satisface fiecare factor
Apoi se decide importana relativ pentru fiecare factor. Se

multiplic cu scorul deja stabilit i apoi se sumeaz.
176
Tabelul 12.4. Analiza matricei de decizii pentru evaluarea ponderat

a modului n care fiecare tip de main satisface fiecare factor
Se obine un rezultat interesant: n ciuda lipsei de distracie, o

main break ar putea fi cea mai bun alegere. Dac surferul se simte nc
nemulumit de decizie, este posibil s fi supraestimat importana unuia
dintre factori. Poate ar fi trebuit s dea factorului distracie valoarea 7.
Analiza matricei de decizii ajut la luarea deciziilor ntre mai multe
opiuni, atunci cnd se iau n considerare mai muli factori diferii i este cea
mai simpl form de analiz a deciziilor multi-criteriale. Alte metode mai
sofisticate implic o modelare complex a diferitelor scenarii poteniale i
tehnici de matematic avansat.
12.2.4. Analiza costuri-beneficii
Analiza costuri-beneficii este o tehnic relativ simpl i foarte
rspndit pentru luarea unei decizii de a realiza o schimbare. Precum
sugereaz i numele, pur i simplu se adun valoarea beneficiilor unei
aciuni i se scad costurile asociate cu aceasta.
Costurile pot fi calculate o singur dat sau se pot acumula n timp.
Beneficiile sunt de cele mai multe ori ncasate dup un timp. Acest efect de
timp se include n cadrul analizei prin calcularea unei perioade de
amortizare timpul necesar ca beneficiile s permit recuperarea costurilor.
Multe companii i propun amortizarea proiectelor dup o perioad de timp
specificat, de exemplu 3 ani.
177
Modul de folosire
ntr-o form simpl, analiza costuri-beneficii se efectueaz folosind
doar costuri i beneficii financiare. De exemplu, raportul costuri-beneficii
pentru construirea unei osele include doar costul construirii efective a
drumului, precum i beneficiul economic rezultat din mbuntirea
infrastructurii de transport. Nu se msoar costul distrugerii mediului
nconjurtor sau beneficiul unui drum spre lucru mai rapid i mai uor.
O abordare mai sofisticat este ncercarea de a atribui valori
financiare costurilor i beneficiilor intangibile. Acest lucru are o dimensiune
foarte subiectiv. De exemplu, este greu de estimat costul renunrii la o
zon verde protejat i de asemenea valoarea unei cltorii lipsite de stres
dimineaa ctre locul de munc.
Exemplu
Un director de vnzri decide dac s implementeze un nou sistem
de management al contactelor i un sistem computerizat de prelucrare a
vnzrilor. Departamentul lui are doar cteva calculatoare iar angajaii si
nu au cunotine de utilizare a calculatoarelor. El este contient c utiliznd
calculatorul, agenii de vnzri ar fi capabili s contacteze mai muli clieni
i c ar spori ncrederea i calitatea relaiilor cu publicul. Acetia ar lucra
mai eficient i cu echipele de prelucrare i de livrare.
Analiza costuri-beneficii arat ca mai jos:
Costuri:
Echipamente noi:
o 10 PC-uri conectabile la internet cu suport software:
2450 $ fiecare;
o 1 server: 3500 $;
o 3 imprimante: 1200 $ fiecare;
o Cablare i instalare: 4600 $;
o Suport software pentru vnzari: 15.000 $;
Costuri de pregtire:
o Introducere n calculatoare 8 persoane: 400 $ fiecare;
178
o Abiliti de utilizare 8 persoane: 400 $ fiecare;

o Sistem suport de vnzri 12 persoane: 700 $ fiecare;
Alte costuri:
o Timp pierdut: 40 zile-om, 200 $ / zi;
o Vnzri pierdute din cauza ntreruperii activitii:
estimativ 20.000 $;
o Vnzri pierdute din cauza ineficienei din primele
luni: estimativ 20.000 $;
Cost total: 114.000 $.
Beneficii:
Triplarea capacitii de contactare a clienilor: estimativ
40.000 $ / an;
Abilitate de susinere a campaniilor de vnzri prin telefon:
estimativ 20.000 $ / an;
Sporirea eficienei i ncrederii: estimativ 50.000 $ / an;
Serviciu de relaii cu publicul mbuntit: estimativ
30.000 $ / an;
Acuratee mai mare de informare a publicului: estimativ
10.000 $ / an;
Abilitate crescut de a se ocupa de efortul de vnzri:
30.000 $ / an;
Beneficiu total: 180.000 $ / an.
Timp de amortizare: 114.000 / 180.000 (ani) = 0,63 ani 8 luni.
Pentru analiza perioadei de recuperare a investiiei se poate utiliza
diagrama pragului de rentabilitate, descris n capitolul 3, Justificarea
financiar a proiectului.
Inevitabil, estimrile beneficiilor aduse de noul sistem sunt
subiective. n ciuda acestui fapt, directorul de vnzri ar trebui probabil s l
introduc, datorit perioadei scurte de amortizare.
Analiza costuri-beneficii este un instrument puternic, relativ simplu
i des folosit pentru a decide dac s se fac sau nu o schimbare. Analiza se
poate realiza utiliznd doar costuri i beneficii financiare. De asemenea, se
179
pot include articole intangibile n cadrul analizei ns, deoarece trebuie

estimat o valoare pentru acestea, va aprea inevitabil un element
suplimentar de subiectivitate n cadrul procesului.
12.3. Decizii n condiii de incertitudine

Cnd decidentul trebuie s aleag o aciune din mai multe posibile,
repercusiunile ctorva aciuni, dac nu a tuturor, vor depinde n general de
evenimente incerte i de aciuni viitoare care se vor prelungi pe termen lung.
Datorit incertitudinilor, acesta trebuie:
S inventarieze toate opiunile viabile disponibile pentru a se

informa, a experimenta i a aciona;
S enumere toate evenimentele care pot s apar;
S organizeze toate informaiile pertinente i alegerile sau
presupunerile fcute;
S ordoneze consecinele rezultate din cursurile diferite ale
aciunilor;
S estimeze probabilitile de apariie ale evenimentelor incerte.
12.3.1. Criteriul Laplace
Criteriul Laplace, al raiunii insuficiente, susine urmtorul lucru:

dac nu exist informaii cu privire la probabilitile diverselor rezultate, se
poate considera c aceste probabiliti sunt egale. n consecin, dac exist
n rezultate posibile, probabilitatea fiecruia este de 1 / n . De asemenea,
aceast abordare sugereaz c decidentul calculeaz profitul ateptat al
fiecrei alternative i alege opiunea cu cea mai mare valoare. Utilizarea
valorilor ateptate distinge aceast abordare de criteriile care folosesc
valorile extreme ale beneficiilor. Aceast caracteristic face ca abordarea s
fie similar cu luarea deciziilor n condiii de risc. n tabelul 12.5, prima
alternativ este mai bun atunci cnd profitul ateptat se calculeaz cu stri
echiprobabile.
180
Tabelul 12.5. Ilustrarea criteriului Laplace

Aciuni / Stri
A1
A2
A3
S1
S2
S3
S4
Profitul
(Pr = 0.25) (Pr = 0.25) (Pr = 0.25) (Pr = 0.25) ateptat
20
60
-60
20
10
0
20
-20
20
5
50
-20
-80
20
-7.5
12.3.2. Criteriul maximax

Criteriul maximax este o abordare optimist. El sugereaz faptul c
decidentul examineaz valorile maxime ale profiturilor date de alternative i
alege opiunea cu cel mai bun rezultat. Acest criteriu este atractiv pentru
persoanele care i asum riscuri, fiind atrase de profiturile mari. De
asemenea, abordarea este atrgtoare i pentru cei crora le plac pariurile,
dar care pot suporta pierderi fr inconvenine majore. n tabelul 12.6, prima
alternativ este cea ctigtoare.
Tabelul 12.6. Ilustrarea criteriului maximax
Aciuni / Stri
S1
S2
S3
S4
A1
A2
A3
20
0
50
60
20
-20
-60
-20
-80
20
20
20
Profitul
maxim
60
20
50
12.3.3. Criteriul maximin

Criteriul maximin reprezint o abordare pesimist, afirmnd c
decidentul analizeaz doar profiturile minime date de alternative i o alege
pe aceea al crei rezultat este cel mai puin slab. Criteriul este potrivit pentru
decidenii precaui, care vor s se asigure c n cazul unui eveniment
defavorabil, exist mcar un profit minim garantat. Abordarea se justific
datorit faptului c beneficiile mici pot s aib probabiliti mai mari de
apariie sau c profitul minim poate conduce la un rezultat extrem de
defavorabil. n tabelul 12.7, a doua alternativ este ctigtoare.
181
Tabelul 12.7. Ilustrarea criteriului maximin

Aciuni / Stri
S1
S2
S3
S4
A1
A2
A3
20
0
50
60
20
-20
-60
-20
-80
20
20
20
Profitul
minim
-60
-20
-80
12.3.4. Criteriul Hurwicz

Aceast abordare ncearc s gseasc un echilibru ntre criteriile
maximax i maximin, sugernd c minimul i maximul din cele dou
strategii trebuie ponderate. Alternativa cu media ponderat cea mai mare
este selectat. Coeficientul , numit i indexul de pesimism, reflect
atitudinea decidentului fa de asumarea riscului. O persoan precaut va
folosi = 1, valoare ce reduce criteriul Hurwicz la criteriul maximin, n
vreme ce o persoan ndrznea va folosi = 0, fapt ce reduce criteriul la
maximax.
n tabelul 12.8 este prezentat aplicarea acestui criteriu cu = 0,4.
Prima alternativ este ctigtoare.
Tabelul 12.8. Ilustrarea criteriului Hurwicz
Aciuni / Stri
S1
S2
S3
S4
A1
A2
A3
20
0
50
60
20
-20
-60
-20
-80
20
20
20
Profitul
( = 0,4)
12
4
-2
De exemplu, pentru a treia alternativ, profitul este:

PHurwicz = Pmaximin + (1 ) Pmaximax = 0,4 (80) + 0,6 50 = 2.
182
12.3.5. Criteriul Savage (al regretelor)

Criteriul regretului minim analizeaz regretul, costul sau pierderile
rezultate atunci cnd profitul alternativei selectate este mai mic dect cel
maxim care ar fi putut fi atins n situaia respectiv. Regretul corespunztor
unui anumit profit Pij este definit ca Rij = Pjmax Pij, unde Pjmax este cel mai
mare beneficiu care poate fi obinut n starea Sj. Aceast definiie a
regretului permite decidentului s transforme matricea profiturilor ntr-o
matrice a regretelor. Decidentul ia n considerare regretul maxim
corespunztor fiecrei strategii i alege varianta cu cea mai mic valoare.
Aceast abordare este atractiv pentru persoanele precaute, care vor s se
asigure c varianta aleas este bun n comparaie cu celelalte alternative,
indiferent de situaia ivit. Abordarea este potrivit mai ales pentru un
decident care tie c o parte din competitorii si se confrunt cu
circumstane identice sau similare i care este contient c performanele
sale vor fi evaluate n comparaie cu cele ale concurenilor si. Criteriul se
aplic aceleiai situaii decizionale, transformnd matricea profiturilor n
matricea regretelor. n tabelul 12.9, prima alternativ este ctigtoare.
Tabelul 12.9. Ilustrarea criteriului Savage
Aciuni / Stri
S1
S2
S3
S4
A1
A2
A3
30
50
0
0
40
80
40
0
60
0
0
0
Regretul
maxim
40
50
80
De exemplu, pentru prima coloan, cu valorile din tabelele 12.6 i

12.7, valoarea maxim este 50, pe linia 3. Prin urmare, regretul pentru linia
1 este 50 20 = 30, iar regretul pentru linia 2 este 50 0 = 50. Pentru linia
3, regretul este 0. Dintre valorile maxime ale regretelor pe linii (40, 50 i
80), se alege cea mai mic valoare, adic 40, iar linia sa corespunde
alternativei ctigtoare.
183
12.4. Decizii n condiii de risc

12.4.1. Arbori de decizie
Arborii de decizie sunt instrumente utile pentru reprezentarea
problemelor decizionale cu mai muli pai. Aciunile posibile din orice
moment sunt prezentate ca ramuri care pornesc dintr-un punct decizional,
reprezentat de un ptrat mic. Diversele rezultate posibile ale unei aciuni
apar ca ramuri ce pornesc dintr-un punct ans, marcat printr-un nod sub
forma unui cerc, la captul ramurii corespunztoare unei aciuni. Fiecrei
ramuri i este asociat o probabilitate de la un punct ans spre un rezultat.
Valorile asociate fiecrui rezultat sunt reprezentate la captul ramurilor
corespunztoare.
Figura 12.1. Structura unui arbore de decizie
Dup construirea arborelui, se poate identifica aciunea recomandat

de criteriul valorii ateptate, prin folosirea metodelor de nfurare napoi i
retezare (elagaj). nfurarea napoi const n calcularea valorii ateptate
pentru fiecare nod. Se ncepe cu nodurile care nu au succesori, cele mai
ndeprtate n viitor. Pentru un nod decizional fr niciun succesor de tip
ans nu exist incertitudine la alegerea aciunii. Valoarea nodului
decizional reprezint profitul aciunii respective. Unui nod ans fr niciun
succesor de tip decizional i se atribuie valoarea ateptat a profiturilor
asociate ramurilor care ies din el.
Pentru un nod decizional ai crui succesori ans au fost evaluai, se
alege aciunea care conduce ctre nodul ans cu cel mai mare profit. Toate
celelalte aciuni posibile asociate respectivului nod decizional nu mai sunt
184
luate n considerare, ramurile fiind retezate. Nodului decizional i se atribuie

valoarea pe care o are nodul ans aflat la captul aciunii selectate. Pentru
un nod ans ai crui succesori decizionali au fost evaluai, se calculeaz
valoarea ateptat a tuturor nodurilor decizionale succesoare.
Acest proces se repet n mod sistematic pn cnd se evalueaz
nodul decizional aflat n rdcina arborelui, ce reprezint decizia care se va
lua. Acele pri ale arborelui de decizie care pot fi atinse pornind din
rdcin i urmnd ramurile care nu au fost retezate ofer o soluie complet
a problemei.
Exemplu
O companie trebuie s decid ntre a construi o uzin mic sau una
mare pentru a fabrica un produs nou cu o durat de via pe pia de 10 ani.
Cererea pentru produsul n cauz poate fi mare n primii 2 ani, dar,
n cazul n care muli din utilizatorii iniiali l vor considera nesatisfctor,
cererea ar putea s scad n continuare spre un nivel mic. Ca alternativ,
cererea iniial mare ar putea indica posibilitatea unui volum de pia ridicat
pe termen lung. Dac cererea este iniial mare i rmne astfel, iar compania
nu are o capacitate suficient n primii 2 ani, cu siguran pe pia vor fi
introduse produse concurente de ctre alte companii.
Dac iniial compania construiete o fabric mare, trebuie s o
susin timp de 10 ani, indiferent de cererea de pe pia. n cazul n care
construiete o fabric mic, exist posibilitatea extinderii ei dup 2 ani,
opiune ce va fi aleas numai dac cererea este mare n perioada de nceput.
Dac se construiete iniial o fabric mic i cererea e sczut la nceput,
compania va menine producia i va obine un profit bun din volumul mic
de produse fabricate.
Informaii de pia: Se estimeaz c va exista urmtoarea evoluie a
cererii:
Iniial ridicat, pe termen lung ridicat: 60%;

Iniial ridicat, pe termen lung sczut: 10%;
Iniial sczut, n continuare sczut: 30%;
Iniial sczut, pe termen lung ridicat: 0%.
185
Venit anual:
O fabric mare cu un volum de pia ridicat va avea un ctig anual

de 1 m (1 milion de lire), timp de 10 ani;
O fabric mare cu un volum de pia sczut va avea un ctig de
numai 0,1 m pe an;
O fabric mic avnd cererea de pia sczut va avea un venit anual
de 0,4 m;
O fabric mic va avea un venit anual de 0,45 m n cazul unei
perioade iniiale cu cerere mare, dar, datorit concurenei, acesta va
scdea pn la 0,25 m pe termen lung, dac cererea va fi n
continuare mare;
Dac o fabric iniial mic ar fi extins dup 2 ani ca urmare a
cererii ridicate, ar avea un ctig anual de 0,7 m pentru urmtorii 8
ani;
Dac o fabric iniial mic ar fi extins dup 2 ani, dar cererea
ridicat nu ar continua, venitul anual estimat pentru urmtorii 8 ani
ar fi de 0,05 m.
Costuri de capital: Construirea unei fabrici mari ar costa 3 m, iar o

fabric mic ar presupune un cost iniial de 1,3 m i unul adiional de
2,2 m n cazul extinderii dup 2 ani.
Figura 12.2. Exemplu de arbore de decizie

186
Deoarece o situaie corespunztoare unui volum de pia iniial

sczut, urmat de unul ridicat pe termen lung are probabilitatea zero, ramurile
asociate ei au fost eliminate din arborele decizional de mai sus.
Profitul net de 7 m pentru cazul unui volum de pia ridicat timp de
10 ani se obine prin scderea costului de capital n valoare de 3 m din
venitul total de 10 m. Valorile profiturilor nete corespunztoare celorlalte
situaii se calculeaz ntr-o manier similar.
Ramura de sus care iese din nodul ans aflat la captul aciunii
iniiale build big corespunde unei situaii n care volumul este mare pe
ntreaga perioad de 10 ani. Probabilitatea acestei ramuri este preluat direct
din informaiile de pia. Probabilitile celorlalte dou ramuri care ies din
acelai nod ans (iniial ridicat, pe termen lung sczut i iniial sczut,
pe termen lung sczut) se obin n mod similar.
Ramurile care pornesc din nodul ans aflat la captul aciunii
iniiale build small corespund volumelor de pia iniial ridicat, respectiv
iniial sczut. Probabilitile pot fi obinute, din nou, din informaiile de
pia.
Probabilitile nodurilor ans care urmeaz aciunilor expand i
dont expand sunt ceva mai complicate. S considerm ramura de sus care
pornete din nodul ans ce urmeaz dup expand. Aceasta corespunde unui
volum de pia mare pe termen lung, n condiiile unui volum ridicat n
primii 2 ani. Probabilitatea acestei situaii este:
n mod similar, ramura de jos care pornete din nodul ans ce

urmeaz dup expand corespunde unui volum de pia sczut pe termen
lung, n condiiile unui volum ridicat n primii 2 ani. Aceasta are urmtoarea
probabilitate:
187
Ramurile care ies din nodul ans ce urmeaz dup dont expand au
probabiliti similare.
Nodul ans aflat dup build big are urmtoarea valoare ateptat:
7,0 0,6 (0,2) 0,1 (2,0) 0,3 4,2 0,02 0,6 3,58 m.
Analog, nodurile ans de dup expand i dont expand au valorile

2,27 m i 1,76 m.
Lund n considerare punctul decizional aflat la sfritul celui de-al
doilea an, n contextul unei fabrici iniial mici i al unui volum de pia
iniial mare, sunt posibile dou aciuni: expand i dont expand. Aceste
aciuni conduc spre noduri ans cu valori ateptate de 2,27 m i respectiv
1,76m. Un profit ateptat de 2,27 m este preferabil unuia de 1,76 m,
astfel nct expand este ales n detrimentul lui dont expand. Acest lucru
nseamn c, n cazul n care compania construiete iniial o fabric mic i
volumul este mare, atunci conform criteriului valorii ateptate, compania ar
trebui s extind fabrica dup 2 ani. Ramura dont expand este retezat, iar
nodului decizional i se atribuie valoarea ateptat de 2,27 m.
Acum, nodul ans de dup build small poate fi evaluat. De aici
pornesc dou ramuri, corespunztoare celor dou situaii: initially high
volume i initially low volume. Ramura superioar, cu o probabilitate de 0,7,
ne conduce spre un nod decizional cruia tocmai i-am atribuit valoarea
2,27 m. Ramura inferioar, cu o probabilitate de 0,3, are un rezultat cu un
profit de 2,7 m. Valoarea ateptat a acestui nod ans este:
2,27 0,7 + 2,7 0,3 = 1,59 + 0,81 = 2,4 m.
La final, analizm nodul aflat n rdcina arborelui. Exist dou
aciuni posibile: build big i build small. Prima conduce spre un nod ans
cu o valoare ateptat de 3,58 m. Cea de-a doua conduce spre nodul ans
discutat n paragraful anterior, cu valoarea ateptat de 2,4 m. Aciunea
build big ne conduce ctre o valoare ateptat mai mare, n consecin,
aceasta este aciunea preferat. Aciunea build small este retezat, iar
nodului decizional i se atribuie valoarea ateptat de 3,58 m.
188
Aadar, recomandarea este ca, din start, compania s construiasc o

fabric mare. Profitul net ateptat n acest caz este de 3,58 m.
189

Referine
[1] Albrecht, A. J. (1981). Function points as a measure of productivity, Proc. GUIDE 53 Meeting, Dallas.
[2] Alemi, F. (2008). Introduction to Decision Analysis, http://gunston.
gmu.edu/730/ IntroductionToDecisionAnalysis.asp.
[3] Austin, R. D. (1996). Measuring and Managing Performance in
Organizations, Dorset House.
[4] Beck, K. (1998). Extreme Programming: A Humanistic Discipline
of Software Development, FASE 1998: 1-6
[5] Berkun, S. (2005). The Art of Project Management, OReilly.
[6] Boehm, B. W. (1988). A Spiral Model of Software Development
and Enhancement, IEEE Computer, vol.21, no. 5, pp 61-72.
[7] Boehm, B. W. (1981). Software Engineering Economics, PrenticeHall.
[8] Duncan, W. R. (1996). A Guide to the Project Management Body
of Knowledge, Project Management Institute, PMI Publishing Division.
[9] Fayol, H. (1949). General and Industrial Administration. London:
Sir Issac Pitman & Sons, Ltd..
[10] Guckenheimer, S., Perez, J. J. (2006). Software Engineering with
Visual Studio Team System, Pearson Education.
[11] Gustafson, D. H., Cats-Baril, W. L., Alemi, F. (1992). Introduction
to Decision Analysis, in Systems to Support Health Policy Analysis: Theory, Model and Uses, Health Administration Press: Ann
Arbor, Michigan.

[12] Halstead, M. H. (1977). Elements of Software Science, NorthHolland Publishing Company.

[13] Heimberg, J. D. (2006). Using a Strengths, Weaknesses, Opportunities, and Threats (SWOT) Analysis as a Risk Assessment and Risk
Management Tool, Federal Network Services White Paper,
http://www.leverageis.com/customer_solutions/
WP_LIS_SWOTforRiskAnaly.pdf.
[14] IT Service Management Forum (2002). IT Service Management:
An Introduction, in Van Bon, J. (ed.), Van Haren Publishing.
[15] Johnson, K. (1998). Software Cost Estimation: Metrics and Models, Department of Computer Science, University of Calgary Alberta, Canada, http://sern.ucalgary.ca/courses/seng/621/W98/ johnsonk/cost.htm.
[16] Kmietowicz, Z. W., Pearman, A.D. (1981). Decision Theory and
Incomplete Knowledge, pp. 7-9, Gower Publishing Company Limited, Aldershot, Hampshire, England.
[17] Koontz, H., ODonnel, C. (1976). Management: A Systems and
Contingency Analysis of Managerial Functions, McGraw Hill,
New York.
[18] Kriwaczek, F. (2009). Decision Analysis, 2009, http://www.doc.ic.
ac.uk/~frk/frank/da/all%20notes.pdf
[19] Leon, F., Zaharia, M. H. (2005). Ingineria programrii, Politehnium, Iai.
[20] LeRoi Burback, R. (1999). Software Engineering Methodology:
The WaterSluice, PhD Thesis, Stanford University, http://wwwdb.stanford.edu/~burback/watersluice.
[21] Management 101 (2001). The Five Functions of Management,
http://digi.physic.ut.ee/tanel/books/project_management/ business%20ebook%20-%20Management%20101%20The%20Five
%20Functions%20of%20Management.pdf.
[22] Mind Tools Ltd. (2009). Decision Making Techniques,
http://www.mindtools.com/pages/ main/newMN_TED.htm
192
Referine
[23] Mintzberg, H. (1983). Structures in Fives: Designing Effective

Organizations, Prentice Hall.
[24] Nelson, E. A. (1966). Management Handbook for the Estimation
of Computer Programming Costs, AD-A648750, Systems Development Corp.
[25] Newell, M. W. (2002). Preparing for the Project Management
Professional Certication Exam, Second Edition, American Management Association.
[26] Norden, P. V. (1970). Useful tools for project management, in M.
K. Starr (ed.), Management of Production, Penguin Books, pp. 71101.
[27] Paulk, M. (1994). A Comparison of ISO 9001 and the Capability
Maturity Model for Software, Technical Report CMU/SEI-94-TR012, http://www.sei.cmu.edu/publications/documents/94.reports/
94.tr.012.html.
[28] Putnam, L. H., ed. (1980). Tutorial: Software Cost Estimating and
Life-cycle Control: Getting the Software Numbers, IEEE Catalog
nr. EZ314.
[29] Reddin, W. J. (1970). Managerial Effectiveness, McGraw-Hill.
[30] Reynolds, B., Schaeffer, B. (2009). Decisions Under Uncertainty,
http://terpconnect.umd.edu/~sandborn/courses/808S_projects/
reynolds.html
[31] Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques, in Technical Papers of
Western Electronic Show and Convention (WesCon). , Los Angeles.
[32] Sliger, M., Broderick, S. (2008). The Software Project Manager's
Bridge to Agility: Scope Management, in The Software Project
Manager's Bridge to Agility, Addison-Wesley Professional,
http://www.informit.com/articles/article.aspx?p=1215640.
[33] Smith, T. (2009). Using Descriptive Rather Than Prescriptive Metrics, http://technology-doc.blogspot.com/2009/11/usingdescriptive-rather-than.html.
193
[34] Sommerville, I. (2000). Software Engineering, Addison-Wesley

Publishing Company.
[35] Spivey, J. M. (1989). The Z Notation: a reference manual, Prentice-Hall.
[36] Van Vliet, H. (1993). Software Engineering, John Wiley & Sons.
[37] Wikipedia, The Free Encyclopedia (2015). Henry Ford,
https://en.wikipedia.org/wiki/Henry_Ford
[38] Wikipedia, The Free Encyclopedia (2015). Information Technology
Infrastructure Library, http://en.wikipedia.org/wiki/Information_
Technology_Infrastructure_Library.
[39] Wikipedia, The Free Encyclopedia (2015). IT service management,
http://en.wikipedia.org/wiki/ITSM.
[40] Wikipedia, The Free Encyclopedia (2015). Stanford prison experiment, https://en.wikipedia.org/wiki/Stanford_prison_experiment
[41] Wysocki, R. K. (2006). Effective Software Project Management,
Wiley.
194

Florin Leon - Managementul Proiectelor Software

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Florin Leon - Managementul Proiectelor Software

Încărcat de

Drepturi de autor:

Formate disponibile

2.4.1. Metodologia spiral ...................................................................... 41

5.3.1. Metoda diagramei de preceden ........................................... 72

Capitolul 8. Managementul resurselor umane

Capitolul 10. Managementul comunicrii

12.3.3. Criteriul maximin .................................................................... 181

Introducere n managementul proiectelor

Florin Leon (2016). Managementul proiectelor software - Suport de curs

Managementul proiectelor software

Dac nu ar exista aceste pri diferite am vorbi de o repetiie de

Capitolul 1. Introducere n managementul proiectelor

1.2. Funciile managementului

Managementul proiectelor software

1. Planificarea strategic: Determin obiectivele majore ale

Capitolul 1. Introducere n managementul proiectelor

4. S proiecteze o ierarhie a relaiilor pentru luarea deciziilor.

privete recrutarea, selecionarea, instruirea i

Florin Leon (2016). Managementul proiectelor software - Suport de curs

Managementul proiectelor software

identificarea, atragerea i pstrarea personalului calificat pentru a ocupa

Capitolul 1. Introducere n managementul proiectelor

8. ncetarea relaiilor de munc: Managementul trebuie s fie

Managementul proiectelor software

producie, la materiale, echipamente, componente i

1.3. Noiuni de baz

Plan: Graficul datelor de ncepere i terminare ale activitilor

Capitolul 1. Introducere n managementul proiectelor

Cost: Costul total planificat pentru o activitate, resurs, sarcin

Managementul proiectelor este adesea rezumat ntr-un triunghi

Managementul proiectelor software

Proiectele trebuie s fie livrate la timp.

Figura 1.1. Triunghiul managementului de proiect

Dac timpul sau banii ar fi nelimitai, sau cerinele ar fi nule, nu ar

Dac se decide scderea timpului alocat pentru finalizarea

Modificrile din planul proiectului pot afecta triunghiul n diverse

Capitolul 1. Introducere n managementul proiectelor

Din punct de vedere al triunghiului proiectului, resursele sunt

Managementul proiectelor software

Proiectele au ntotdeauna resurse limitate, dar uneori exist proiecte

Capitolul 1. Introducere n managementul proiectelor

Figura 1.2. Ciclul de via al unui proiect

Acesta conine urmtoarele stadii:

Managementul proiectelor software

Realizarea unei analize post-implementare;

Pe durata ciclul su de via, proiectul trebuie s fac fa n

Capitolul 1. Introducere n managementul proiectelor

multe cauze. n primul rnd, pe msur ce se apropie de finalizarea

1.4. Managerul de proiect

Managementul proiectelor software

mai puin, de care echipa se poate lipsi. Eficiena i simplitatea trebuie

o tiin deoarece presupune nelegerea proceselor, instrumentelor i

Instrumentele i tehnicile de management de proiect sunt ncercate i

Capitolul 1. Introducere n managementul proiectelor

trebuie s aib puncte de contact consecvente cu echipa de proiect, iar

Managementul proiectelor software

recompensele cu ntreaga echip. Chiar dac mndria poate fi o

Capitolul 1. Introducere n managementul proiectelor

totul subtilitile problemelor aprute. Echilibrul aici poate fi gsit

Managementul proiectelor software

acestor fore conflictuale. Totui, oricine poate deveni mai bun n

Capitolul 1. Introducere n managementul proiectelor

alocat verificrii tabelelor, listelor sau rapoartelor. Este posibil ca managerul

Managementul proiectelor software