Managementul Proiectelor Software

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/302923755
Managementul proiectelor software - Suport de curs
Book · May 2016
CITATIONS READS
0 542
1 author:
Florin Leon
Gheorghe Asachi Technical University of Iasi
135 PUBLICATIONS 475 CITATIONS
SEE PROFILE
All content following this page was uploaded by Florin Leon on 22 September 2016.
The user has requested enhancement of the downloaded file.

Florin Leon
Managementul proiectelor
software
Suport de curs
2016
Cuprins
Capitolul 1. Introducere în managementul proiectelor

1.1. Introducere .................................................................................................. 11
1.2. Funcţiile managementului...................................................................... 13
1.2.1. Planificarea ...................................................................................... 13
1.2.2. Organizarea .................................................................................... .14
1.2.3. Selecţia personalului .................................................................... 15
1.2.4. Conducerea ...................................................................................... 17
1.2.5. Controlul ........................................................................................... 17
1.3. Noţiuni de bază ........................................................................................... 18
1.3.1. Definiţii .............................................................................................. 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 neatenţia ................................................................ .30
1.4.3. Măsurarea performanţelor ........................................................ 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 secvenţială .......................................................................... 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 investiţiei.............................................. 55
3.4. Valoarea actuală netă ............................................................................... 56
3.5. Rata internă de recuperare a investiţiei ........................................... 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 activităţilor ..................... 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 activităţilor ............................................................................... 71
5.3. Ordonarea activităţilor ............................................................................ 72
6
5.3.1. Metoda diagramei de precedenţă ........................................... 72
5.4. Estimarea duratei activităţilor ş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 planificării ................................................ 80
5.5.1. Scopurile planificării .................................................................... 80
5.5.2. Calitatea estimărilor ..................................................................... 81
5.5.3. Omisiunile frecvente .................................................................... 82
5.5.4. Recomandări ................................................................................... 83
5.6. Considerente practice ale planificării ................................................ 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 funcţionale ............................................... 101
6.5. Distribuirea forţei de muncă în timp............................................... 103
6.6. Concluzii ..................................................................................................... 108
Capitolul 7. Managementul calităţii

7.1. Introducere ............................................................................................... 109
7.2. Procesele principale ale managementului calităţii .................... 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 aşteptării ......................................................................... 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 autorităţii ................................................................. 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. Greşelile subordonaţilor .......................................................... 138
9.4. Calităţile necesare managerului de proiect .................................. 139
9.4.1. Energia ........................................................................................... 139
9.4.2. Perseverenţa ................................................................................ 139
9.4.3. Stabilirea şi respectarea priorităţilor ................................. 140
9.5. Mecanisme de coordonare .................................................................. 140
9.6. Stiluri de management .......................................................................... 141
8
Capitolul 10. Managementul comunicării
10.1. Introducere ............................................................................................. 145
10.2. Procesele principale ale managementului comunicării ........ 147
10.3. Transmiterea informaţiilor .............................................................. 147
10.4. Bariere de comunicare ....................................................................... 149
10.5. Îmbunătăţirea comunicării ............................................................... 150
10.5.1. Îmbunătăţirea 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 şedinţelor .......................................................... 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 gestionării riscurilor .................................................. 166
11.6. Monitorizarea riscurilor .................................................................... 167
Capitolul 12. Analiza deciziilor

12.1. Introducere ............................................................................................. 169
12.2. Decizii în condiţii de certitudine .................................................... 170
12.2.1. Analiza Pareto ........................................................................... 170
12.2.2. Analiza comparării perechilor ............................................ 172
12.2.3. Analiza matricei de decizii ................................................... 174
12.2.4. Analiza costuri-beneficii ....................................................... 177
12.3. Decizii în condiţii 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 condiţii de risc ................................................................... 184
12.4.1. Arbori de decizie ...................................................................... 184
Referinţe .................................................................................................................... 191
10
Capitolul 1
Introducere în managementul proiectelor
1.1. Introducere
Managementul proiectelor devine rapid metoda de management

utilizată de un număr din ce în ce mai mare de industrii. Sunt realizate
proiecte pentru construirea celor mai mari zgârie nori sau pentru realizarea
unor programe informatice foarte simple. Cei mai mulţi manageri de proiect
consideră că tehnicile de management pot fi aplicate proiectelor indiferent
de dimensiune şi că metodologia, metodele şi paşii utilizaţi pentru
management sunt aproape aceleaşi. 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 cunoştinţe al Managementului de Proiect), un
proiect este un efort temporar întreprins pentru a crea un produs sau
serviciu unic.
Cuvântul temporar înseamnă că orice proiect are un început şi un
sfârşit. În general un proiect începe când 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. Sfârşitul
proiectului are loc de obicei atunci când toate obiectivele proiectului au fost
realizate. Unele proiecte se termină atunci când din diferite motive se decide
abandonarea proiectului pentru că scopurile sale nu pot fi realizate practic.
Cuvântul unic înseamnă că bunurile sau serviciile create de proiect
sunt într-o oarecare măsură diferite faţă de orice a fost produs înainte. Acest
lucru nu înseamnă că proiectul este complet unic, ci că unele părţi sunt
suficient de diferite pentru a necesita un proces de planificare pentru
organizarea efortului care trebuie făcut.

Managementul proiectelor software
Dacă nu ar exista aceste părţi diferite am vorbi de o repetiţie 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 conţin oameni potriviţi
la momentul potrivit. Prin urmare, pot fi aduse în proiect resurse deosebite
atunci când sunt necesare.
Persoana (sau organizaţia) care are un interes privind rezultatele unui
proiect se numeşte parte interesată (engl. “stakeholder”). Proiectele vor
avea întotdeauna mai mult de o parte interesată, fiecare cu nevoi şi aşteptări
diferite. Clientul sau sponsorul este principala parte interesată în proiect.
Fără 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 cunoştinţe,
aptitudini şi tehnici pentru activităţile proiectului cu scopul de a satisface
sau depăşi nevoile şi aşteptările părţilor 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 eşecul proiectului.
Se poate face o distincţie între termenii de proiect şi program.
Conform Ghidului PMBOK, un program reprezintă un grup de proiecte
administrate într-un mod coordonat pentru a obţine beneficii care nu s-ar
putea obţine 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ă
când a fost îndeplinit scopul de construire a centralei şi de punere în
funcţiune. Centrala continuă să funcţioneze şi după ce proiectul a fost
finalizat.
12
1.2. Funcţiile 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 funcţii de bază:
planificare, organizare, selecţie de personal, conducere şi control, folosind
resurse umane, financiare şi materiale.
1.2.1. Planificarea
Priveşte anticiparea situaţiilor viitoare şi determinarea celei mai

potrivite modalităţi de acţiune pentru îndeplinirea obiectivelor
organizaţionale. Deseori considerată „prima” funcţie a managementului,
planificarea pune bazele tuturor celorlalte funcţii. Planificarea e un proces
continuu care implică stabilirea acţiunilor necesare pentru a răspunde la
întrebări precum: ce trebuie făcut, când ş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 acţiuni care angajează
indivizii, departamentele şi întreaga organizaţie timp de zile, luni sau chiar
ani. De aceea, planificarea trebuie făcută cu atenţie, luându-se în calcul
următoarele aspecte:
1. Determinarea resurselor necesare;

2. Identificarea numărului de oameni şi a tipurilor de calificare
(personal tehnic, de supervizare sau managerial);
3. Dezvoltarea mediului organizaţional în care se va lucra (ierarhia
organizaţională);
4. Determinarea standardelor necesare pentru evaluarea evoluţiei
proiectului, astfel încât să se poată face corecţii atunci când acest
lucru se impune.
În funcţie de amploare sau sfera de acţiune, se pot evidenţia trei

categorii de planificare:
13
1. Planificarea strategică: Determină obiectivele majore ale

organizaţiei. Este iniţiată ş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
îndeplineşte scopuri precum:
 Stabilirea unor direcţii şi angajamente pe termen lung pentru
întreaga organizaţie;
 Implicarea mai multor niveluri de management în procesul
de planificare;
 Dezvoltarea unui model organizaţional în care planurile
subunităţilor să fie armonizate şi consistente;
2. Planificarea tactică: Priveşte mai ales implementarea planurilor
strategice printr-un management de nivel mediu. Tactica este
mijlocul de îndeplinire a strategiei. Planurile se referă la
responsabilităţile unităţilor şi în general se concentrează pe
activităţile curente şi pe termen scurt;
3. Planificarea operaţională: Se referă la îndeplinirea
responsabilităţilor la nivel de post sau compartiment. Planurile pot fi
singulare (pentru activităţi care nu se repetă, de exemplu realizarea
unui buget) sau continue (care includ anumite proceduri sau politici).
1.2.2. Organizarea
Organizarea este funcţia managementului care îmbină resursele

umane şi materiale prin proiectarea unei structuri formale a sarcinilor şi
autorităţii. Organizarea stabileşte deci relaţiile dintre activitate şi autoritate.
În acest context, managerul trebuie să îndeplinească patru scopuri
principale:
1. Să determine ce activităţi de lucru trebuie făcute pentru atingerea

obiectivelor organizaţionale;
2. Să clasifice tipurile de activităţi şi grupurile de lucru în unităţi uşor
gestionabile;
3. Să atribuie indivizilor sarcini de lucru şi să-şi delege autoritatea într-
un mod adecvat;
14
4. Să proiecteze o ierarhie a relaţiilor pentru luarea deciziilor.
Procesul de organizare poate fi văzut ca format din cinci paşi:
1. Studierea planurilor şi scopurilor: Planurile dictează scopurile şi

activităţile curente sau viitoare. În unele situaţii, ar trebui create noi
unităţi, alteori, unor unităţi existente li se conferă noi atribuţii, iar
unele unităţi pot fi desfiinţate. Pot apărea noi relaţii între părţile
interesate. Organizarea creează o nouă structură, noi relaţii şi le
modifică pe cele existente;
2. Identificarea activităţilor necesare pentru atingerea obiectivelor:
Trebuie creată o listă de sarcini începând cu cele continue şi
terminând cu cele singulare;
3. Clasificarea şi gruparea activităţilor: Managerii trebuie să efectueze
trei proceduri:
 Să examineze fiecare activitate pentru a-i determina natura
generală (marketing, producţie etc.);
 Să grupeze activităţile în ariile corespunzătoare;
 Să stabilească departamentele adecvate în cadrul structurii
organizaţiei;
4. Atribuirea sarcinilor şi delegarea autorităţii: Un pas critic în care se
stabilesc departamentele, natura, scopul şi sarcinile fiecărui
departament, împreună cu performanţele aşteptate;
5. Proiectarea unei ierarhii de relaţii: Se hotărăsc relaţiile de lucru
verticale şi orizontale. Structurarea verticală rezultă într-o ierarhie de
luare a deciziilor în care se ştie cine răspunde pentru fiecare sarcină.
Structurarea orizontală defineşte relaţiile de lucru între departamente
şi stabileşte numărul de subordonaţi ai fiecărui manager.
1.2.3. Selecţia personalului
Această funcţie priveşte recrutarea, selecţionarea, instruirea şi

desemnarea persoanei potrivite pentru poziţia potrivită în cadrul
organizaţiei. În general, se consideră că oamenii sunt cea mai importantă
resursă de care dispune organizaţia. Prin selecţia personalului, se doreşte
15
identificarea, atragerea şi păstrarea personalului calificat pentru a ocupa

poziţiile disponibile.
Selecţia personalului poate fi văzută ca un proces în opt paşi:
1. Planificarea resurselor umane: Trebuie să asigure faptul că nevoile

de personal ale organizaţiei vor fi satisfăcute. De obicei, se
analizează planurile organizaţiei pentru a vedea ce competenţe
anume vor fi necesare în viitor. După realizarea previziunilor, se
stabileşte numărul de persoane care trebuie recrutate (din afara
organizaţiei) sau instruite (din interior);
2. Recrutarea: Se identifică şi se atrag candidaţi care îndeplinesc
cerinţele pentru posturile vacante prevăzute. Ca rezultat al analizei
posturilor, se întocmesc descrierile şi specificaţiile acestora.
Recrutarea efectivă se realizează prin site-uri Internet specializate,
agenţíi de ocupare a forţei de muncă, legături cu universităţile,
anunţuri publice în ziare etc.;
3. Selecţionarea: După recrutare, candidaţii interesaţi trebuie evaluaţi
şi selecţionaţi cei ale căror competenţe se potrivesc cu cerinţele
posturilor. Etapele urmărite în evaluare pot fi: completarea unor
formulare, examinarea profesională, verificarea recomandărilor şi
interviul;
4. Instalarea şi orientarea: Odată selecţionaţi, noii angajaţi trebuie
integraţi în organizaţie; trebuie să li se prezinte grupul de lucru,
precum şi regulamentul intern sau normele organizaţiei;
5. Instruirea şi dezvoltarea: Se încearcă îmbunătăţirea capacităţii
angajaţilor de a contribui la funcţionarea eficientă a organizaţiei.
Instruirea se concentrează asupra calificării angajaţilor. Dezvoltarea
implică pregătirea lor pentru responsabilităţi suplimentare sau
avansare;
6. Evaluarea performanţelor: Un sistem proiectat să măsoare
performanţele efective ale angajaţilor în comparaţie cu standardele
de performanţă prestabilite;
7. Deciziile de recompensare: Pe baza evaluării performanţelor, se pot
lua decizii privind recompensele financiare, transferările,
promovările sau retrogradările;
16
8. Încetarea relaţiilor de muncă: Managementul trebuie să fie

preocupat şi de demisii, pensionări sau concedieri.
1.2.4. Conducerea
După crearea planurilor, structurii organizaţiei şi completarea

personalului, următorul pas al procesului managerial este conducerea, adică
dirijarea şi motivarea angajaţilor către obiectivele organizaţionale. Din acest
motiv, conducerea este importantă mai ales la primul nivel de supervizare,
deoarece la acest nivel este concentrată majoritatea angajaţilor organizaţiei.
Caracteristicile cele mai importante ale funcţiei de conducere se
referă la stilul de conducere (autocratic, democratic) şi la procesul de luare a
deciziilor. Acestea sunt în strânsă legătură cu o serie de factori precum
urgenţa situaţiei sau motivarea subordonaţilor. De asemenea, managerul ca
lider trebuie să cunoască toate aspectele situaţiei curente, să estimeze
impactul pe care îl vor avea deciziile sale şi să ia totdeauna în calcul
elementul uman. El trebuie să atribuie sarcinile iniţiale tuturor angajaţilor, să
dea ordine clare şi concise şi să urmărească modul cum sunt îndeplinite
sarcinile, dând dacă este nevoie îndrumări verbale sau scrise.
1.2.5. Controlul
Ultima funcţie a managementului se referă la evaluarea

performanţelor organizaţiei pentru a determina dacă îşi îndeplineşte sau nu
obiectivele. În această fază trebuie luate următoarele măsuri:
1. Stabilirea standardelor de performanţă utilizate pentru a măsura

progresul către scop. Standardul reprezintă un mecanism de măsură
cantitativă sau calitativă, destinat monitorizării performanţelor
oamenilor sau proceselor. În general putem vorbi de:
 Standarde manageriale: includ rapoarte, regulamente şi
evaluări de performanţă. De exemplu, un raport lunar din
partea tuturor persoanelor implicate în vânzări, centrat pe
ariile cheie de interes pentru managerul de vânzări;
 Standarde tehnice: se referă la metodele şi procesele de
17
producţie, la materiale, echipamente, componente şi

furnizori. Standardele tehnice pot veni din surse interne sau
externe. De exemplu, standarde de calitate dictate de
reglementări guvernamentale sau specificaţiile
producătorului pentru echipamente;
2. Monitorizarea şi evaluarea performanţelor: sunt măsurate
performanţele şi se determină dacă respectă standardele stabilite.
Dacă o asemenea comparaţie indică faptul că rezultatele sunt
acceptabile, nu este necesară nicio acţiune. În caz contrar, se trece la
următorul pas:
3. Corectarea deviaţiilor de la standarde: măsurile de corecţie
necesare se vor lua pe baza a trei factori – standardul, precizia
măsurătorii care a indicat deviaţia şi diagnosticul persoanelor care au
investigat cauzele deviaţiei. Standardele pot fi prea slabe sau prea
stricte. Măsurătorile pot fi imprecise deoarece instrumentele de
măsură pot fi utilizate defectuos sau prezintă ele însele defecte.
Oamenii pot lua decizii greşite la hotărârea acţiunilor corective
necesare.
1.3. Noţiuni de bază
1.3.1. Definiţii
În cele ce urmează, vom preciza câteva definiţii esenţiale pentru

managementul de proiect:
 Plan: Graficul datelor de începere şi terminare ale activităţilor

împreună cu informaţii despre resurse şi costuri. Un plan de bază
este planul iniţial, care se salvează şi se foloseşte pentru a monitoriza
progresul. Un plan interimar este un set de date salvate în timpul
derulării proiectului, folosite pentru a le compara cu alte planuri
interimare.
 Buget: Costul estimat al proiectului care se stabileşte î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 activităţile 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 activităţi decât poate
realiza o resursă în timpul de lucru disponibil.
 Activitate divizată: O activitate al cărei grafic de lucru este întrerupt.
De exemplu, o activitate de două zile, care nu necesită execuţia prin
lucru continuu, poate fi împărţită astfel încât prima zi de lucru să fie
programată luni iar cea de-a doua zi – joi.
 Nivelare: Rezolvarea conflictelor de resurse sau a supra-alocărilor
prin întârzierea sau divizarea unor activităţi. Când 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 activităţii,
durata acesteia, calendarele după care se lucrează, datele unor sarcini
precedente, dependenţele faţă de alte activităţi şi alte constrângeri.
 Întârziere: Timpul dintre data planificată de începere a unei activităţi
şi momentul în care începe efectiv lucrul la aceasta. Întârzierile sunt
deseori folosite pentru a rezolva supra-alocările de resurse.
 Livrabil: Un rezultat concret şi măsurabil, produsul sau un element
care trebuie produs pentru a finaliza proiectul sau o parte a
proiectului. În mod normal, echipa proiectului şi părţile 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, numiţi şi tripla constrângere. Acestea formează vârfurile
triunghiului având calitatea ca temă centrală:
19
1. Proiectele trebuie să fie livrate la timp.

2. Proiectele trebuie să se încadreze în costuri.
3. Proiectele trebuie să se încadreze în domeniul de aplicare.
4. Proiectele trebuie să îndeplinească cerinţele de calitate ale clienţilor.
Figura 1.1. Triunghiul managementului de proiect
Dacă timpul sau banii ar fi nelimitaţi, sau cerinţele ar fi nule, nu ar

mai fi nevoie de management de proiect. Din păcate, cele mai multe proiecte
au o anumită limită de timp, de buget şi domeniu de aplicare. Înţelegerea
triunghiului proiectului permite luarea de decizii mai bune atunci când
trebuie făcute compromisuri. Dacă se ajustează o latură a triunghiului,
celelalte două laturi sunt afectate. De exemplu:
 Dacă se decide scăderea timpului alocat pentru finalizarea

proiectului, poate rezulta o creştere a costurilor, precum şi o
restrângere a domeniului de aplicare;
 Dacă se decide scăderea bugetului proiectului, poate rezulta un
grafic de lucru mai lung şi o scădere a domeniului de aplicare;
 Dacă se decide extinderea domeniul de aplicare, proiectul poate să
dureze mai mult timp şi să coste mai mulţi bani, de exemplu sub
formă de resurse umane.
Modificările din planul proiectului pot afecta triunghiul în diverse

moduri, în funcţie de circumstanţele specifice şi de natura proiectului. De
exemplu, de cele mai multe ori, scurtarea timpului de execuţie al proiectului
poate creşte 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 funcţie de cum ajustăm resursele
pentru mai mult sau mai puţin efort de lucru sau pentru a reflecta
disponibilitatea acestora, costurile vor urca sau vor coborî în mod
corespunzător. Aceste costuri sunt bazate pe tarifele de plată ale resurselor.
De asemenea, se poate observa că pe măsură ce se ajustează resursele, apar
modificări în graficul de lucru. De exemplu, dacă avem un număr de resurse
supra-alocate şi se nivelează proiectul, graficul de lucru poate conţine acum
sarcini divizate şi întârzieri, care extind data limită a terminării proiectului.
În cele mai multe proiecte, cel puţin o latură a triunghiului este fixă.
Pentru unele proiecte, este latura bugetului: sub nicio formă nu se vor primi
mai mulţi 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 găsi părţile „blocate” sau fixe ale triunghiului
proiectului. Aceste părţi ne spun ce se poate schimba sau ajusta dacă există
o problemă. Enunţarea problemei ne poate ajuta să clarificăm ce parte a
triunghiului are dificultăţi.
Cunoscând care parte a triunghiului nu poate fi schimbată ne poate
ajuta să aflăm ce trebuie ajustat. Aşa că, atunci când se începe optimizarea,
în primul rând, se decide care dintre cele trei elemente este fix. Acesta este
de obicei elementul cel mai important pentru succesul proiectului
(terminarea la timp, nedepăşirea 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 apărut problema şi latura fixă a triunghiului
coincid, rămân 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 adaptând latura rămasă. De exemplu, dacă proiectul trebuie să fie
terminat la timp, dar creşte domeniul de aplicare, mai rămâne să ajustăm
numai latura costului, de exemplu, prin adăugarea de resurse.
Când 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 gândi la
proiectul Manhattan din anii ’40 sau la proiectul Apollo din anii ’60, dar
chiar şi aceste proiecte au avut unele constrângeri de resurse. Pentru
managerul de proiect care încercă să finalizeze un proiect cu resurse puţine
sau rare, acesta poate părea un mod minunat de a gestiona un proiect, dar de
obicei aceste tipuri de proiecte vin de obicei cu cerinţe 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 asemănări între proiecte şi toate trec prin faze
similare. Ciclul de viaţă al unui proiect defineşte începutul şi sfârşitul
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 sfârşitul proiectului variază
considerabil în funcţie 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: iniţierea, planificarea, execuţia ş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 activităţi din cadrul proiectului, fiind considerate livrări
interne.
Există mai multe modele ale ciclului de viaţă al proiectelor, în
funcţie 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 conţine următoarele stadii:
1. Stadiul de definire:
 Definirea specificaţiilor proiectului;
 Definirea obiectivelor proiectului;
 Identificarea principalelor responsabilităţi;
2. Stadiul de planificare:
 Planificarea graficelor de lucru calendaristice;
 Planificarea resurselor umane, de timp şi a bugetului
proiectului;
 Managementul riscurilor;
3. Stadiul de execuţie şi control:
 Implementarea proiectului;
 Monitorizarea progresului înregistrat în implementare;
 Evaluarea, măsurarea şi controlul realizărilor intermediare;
 Elaborarea de previziuni şi prognoze de dezvoltare;
4. Stadiul de livrare şi finalizare:
 Livrarea produsului proiectului către beneficiar, incluzând
activităţi de instruire, transfer de documente etc.;
23
 Realizarea unei analize post-implementare;

 Realocarea resurselor;
 Raportul final al proiectului.
Pe durata ciclul său de viaţă, proiectul trebuie să facă faţă în

principal la două tipuri de cerinţe. Prima dintre acestea se referă la etapa de
definire a problemei, în care eventualele erori pot conduce la dezvoltarea
unei soluţii corecte pentru o problemă definită greşit.
În faza iniţială a proiectului, nivelurile de costuri şi de personal sunt
mici. Există doar câţiva oameni cheie care îşi petrec timpul lucrând la
proiect. Au fost achiziţionate puţine 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 când se stabileşte că nu se poate respecta costul de realizare
sau costurile depăşesc 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 post-
implementare, cu scopul de a identifica atât aspectele pozitive ale
proiectului cât şi aspectele ce trebuie îmbunătăţite.
În practică, această etapă este deseori trecută cu vederea. Astfel, în
cadrul conferinţei Frontiers Conference on Proiect Management, unul
dintre moderatori a întrebat audienţa formată din 400 de persoane: „Câţi
dintre dumneavoastră au primit dispoziţia ca, după executarea proiectului, să
elaboreze un raport de evaluare care să cuprindă concluziile finale?” La
această întrebare doar 10 persoane au ridicat mâna.
A doua întrebare a aceluiaşi moderator a fost: „Câţi dintre
dumneavoastră aţi fost solicitaţi să prezentaţi managementului companiei ce
veţi face ca să evitaţi repetarea în viitor a greşelilor făcute în executarea
proiectului?” La această întrebare numai 2 persoane au ridicat mâna.
Concluziile finale după executarea unui proiect sunt deosebit de
importante, deoarece persoanele care nu cunosc istoricul proiectelor
precedente au tendinţa de a repeta greşelile anterioare. Reticenţa unor
persoane de a face o trecere în revistă a rezultatelor finale poate avea mai
24
multe cauze. În primul rând, pe măsură ce se apropie de finalizarea

proiectului, managerii devin nerăbdători să treacă la realizarea altor sarcini
sau proiecte. În al doilea rând, ei nu doresc să recunoască faptul că la
anumite aspecte trebuie aduse îmbunătăţiri. Uneori, această atitudine este
determinată de dorinţa de a nu crea dificultăţi persoanelor a căror activitate
trebuie perfecţionată.
Totuşi, oricât de bine este realizată o activitate, întotdeauna este loc
pentru îmbunătăţiri, iar analizele finale trebuie conduse în acest spirit.
Tendinţa de a pedepsi persoanele a căror activitate prezintă deficienţe poate
dăuna managerilor de proiect în elaborarea unor rapoarte de evaluare
corecte.
1.4. Managerul de proiect
Managementul proiectelor poate fi o profesie, o ocupaţie, un rol sau

o activitate. Unele companii au manageri de proiecte a căror datorie este de
a superviza proiecte întregi cu sute de persoane. Alte companii acordă acest
titlu unor manageri începători, fiecare fiind responsabil de o mică parte
dintr-un proiect mai mare. În funcţie de modul în care este structurată o
organizaţie, de cultura sa organizaţională şi de obiectivele proiectului,
managementul de proiect poate avea un rol informal (este realizat de către
oricine, ori de câte ori este necesar) sau clar definit (X, Y şi Z sunt manageri
de proiect cu normă întreagă).
Uneori absenţa unui manager de proiect dedicat nu pune probleme.
Programatorii şi şefii lor realizează planurile inginereşti când este nevoie şi
un specialist în marketing face planificarea sau stabileşte cerinţele. Orice
altă activitate de management de proiect pur şi simplu se distribuie în
întreaga echipă. Poate că unii oamenii din echipă au fost angajaţi pentru
interesul lor dincolo de scrierea de cod. Aceştia nu vor refuza activităţi
precum planificarea, proiectarea interfaţei cu utilizatorul sau definirea
strategiei de afaceri. Folosind acest mod de lucru se pot realiza optimizări
semnificative. Atâta timp cât toţi membrii echipei sunt dispuşi să accepte
responsabilităţi pentru a face lucrurile să meargă în mod coordonat şi să
preia activităţile unui manager de proiect dedicat, aceasta înseamnă un om
25
mai puţin, de care echipa se poate lipsi. Eficienţa şi simplitatea trebuie

apreciate.
Alteori, lipsa unui manager de proiect creează disfuncţii. Fără o
persoană a cărei principală activitate este ghidarea efortului global,
interesele individuale pot afecta direcţia echipei. În jurul rolurilor tehnice şi
comerciale pot apărea tensiuni care duc la încetinirea progresului şi
frustrarea celor implicaţi. De exemplu, în spitalele de urgenţă un singur
medic ia deciziile privind acţiunile efectuate pentru un pacient. Acest mod
de lucru accelerează luarea multor decizii şi clarifică rolul fiecărui membru
din echipă. Fără o astfel de autoritate clară pentru probleme de management
al proiectelor, echipele de dezvoltare pot întâmpina dificultăţi. 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 activităţi pot rămâne
mult în urma celor bazate pe programarea propriu-zisă.
Deşi mulţi programatori de vârf au suficient de multe cunoştinţe
despre managementul de proiect, încât ar putea face chiar ei acest lucru,
aceştia recunosc valoarea unică a unei persoane competente, dedicate, care
joacă rolul de manager.
Managementul de proiect este în acelaşi timp:
 o ştiinţă deoarece presupune înţelegerea proceselor, instrumentelor şi

tehnicilor, precum şi definirea şi coordonarea activităţilor 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 mulţi ani, dar au fost oarecum dificil de utilizat
fără ajutorul calculatoarelor personale.
De asemenea, prin organizarea într-o manieră care canalizează
eforturile depuse de echipă în direcţia de realizare a proiectului, se creează o
stare de înaltă motivaţie. Aceasta permite echipei să se concentreze asupra
obiectivelor şi să nu fie distrasă de alte activităţi din jur. Părţile interesate
26
trebuie să aibă puncte de contact consecvente cu echipa de proiect, iar

managerul de proiect trebuie să fie o sursă sigură de informaţii cu privire la
proiect şi tot ce se întâmplă în cadrul acestuia.
Managerii de proiect pot fi văzuţi ca nişte manageri de întreprinderi
mici. Multe din caracteristicile necesare în gestionarea unei mici afaceri sunt
aceleaşi cu cele necesare pentru un bun management de proiect. În realitate,
datorită faptului că mulţi manageri de proiect din ziua de astăzi au pregătirea
de bază în discipline tehnice, este surprinzător faptul că aptitudinile care le
sunt solicitate erau considerate anterior abilităţi neobişnuite pentru
managerii tehnici.
Astăzi este de aşteptat ca managerul de proiect să aibă cunoştinţe
considerabile din domeniul financiar, contabilitate, vânzări, marketing,
producţie, cercetare şi dezvoltare, planificare strategică şi operaţională,
caracteristicile organizaţiilor, resurse umane, administraţie, gestionarea
relaţiilor de muncă, motivare şi alte competenţe 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 găsit deoarece aceştia trebuie

să menţină un echilibru al atitudinilor. Un manager de proiect trebuie nu
numai să fie conştient de aceste trăsături, dar şi să îşi dezvolte instinctele
adecvate pentru anumite situaţii. Aceasta contribuie la ideea că
managementul de proiect este o artă: necesită intuiţie, hotărâre şi experienţă
de a utiliza aceste forţe în mod eficient.
1. Orgoliul / lipsa orgoliului. Datorită responsabilităţii mari pe care o

au managerii de proiect, aceştia găsesc o satisfacţie personală în
munca lor. Ei investesc o mare încărcătură emoţională în ceea ce fac
şi, pentru mulţi, această legatură emoţională este ceea ce îi determină
să menţină intensitatea necesară pentru a fi eficienţi. Dar în acelaşi
timp, managerii de proiect trebuie să evite plasarea intereselor
proprii înaintea proiectului. Ei trebuie să fie dispuşi să delege atât
sarcini importante cât şi distractive, să împartă premiile şi
27
recompensele cu întreaga echipă. Chiar dacă mândria poate fi o

rezervă de energie, managerul de proiect trebuie să recunoască
momentul în care aceasta îi stă în cale.
2. Autocraţia / delegarea. În unele situaţii, cele mai importante lucruri
sunt o linie clară de autoritate şi un timp de răspuns rapid. Un
manager de proiect trebuie să fie încrezător şi dispus să preia
controlul şi să forţeze anumite acţiuni ale echipei. Totuşi, în general
scopul este să se evite asemenea situaţii extreme. Un proiect
gestionat bine trebuie să creeze o atmosferă unde sarcinile pot fi
delegate iar colaborarea este eficientă.
3. Tolerarea ambiguităţii / urmărirea perfecţiunii. Primele faze ale
oricărui proiect conţin experienţe deschise şi de o fluiditate mare,
acolo unde necunoscutul surclasează cunoscutul. Ambiguitatea
controlată este esenţială pentru scoaterea la suprafaţă a ideilor bune,
şi un manager de proiect ar trebui cel puţin 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
perfecţiunea este răsplatită şi cazul în care o soluţie mediocră, rapidă
şi neglijentă este suficientă.
4. Comunicarea orală / scrisă. Indiferent cât este de axată o organizaţie
de dezvoltare software pe comunicarea electronică, aptitudinile de
comunicare orală sunt de o importanţă critică pentru managementul
proiectului. Întotdeauna vor fi întâlniri, negocieri, discuţii pe hol şi
sesiuni de brainstorming, iar managerul de proiect trebuie să fie
eficient atât la înţelegerea cât şi la comunicarea ideilor faţă în faţă.
Cu cât organizaţia sau proiectul este mai mare, cu atât abilităţile
scrise devin mai importante. În ciuda preferinţelor lui personale, un
manager de proiect trebuie să îşi dea seama când este mai eficientă
comunicarea scrisă şi când este de preferat comunicarea orală.
5. Recunoaşterea complexităţii / promovarea simplităţii. Mulţi oameni
cad victime complexităţii. Când sunt puşi faţă în faţă cu o provocare
organizaţională sau inginerească complexă, ei tind să se concentreze
asupra detaliilor şi să piardă din vedere imaginea de ansamblu. Alţii
refuză complexitatea şi iau decizii proaste pentru că nu înţeleg întru
28
totul subtilităţile problemelor apărute. Echilibrul aici poate fi găsit

văzând care perspectivă asupra proiectului e mai folositoare, prin
schimbarea sau combinarea perspectivelor. Managerii de proiect
trebuie să determine echipa să urmărească simplitatea şi calitatea,
fără a minimiza însă complexitatea necesară scrierii unui cod bun şi
de încredere.
6. Răbdarea / nerăbdarea. În cele mai multe cazuri, managerul de
proiect este persoana care împinge la acţiune, forţându-i pe ceilalţi să
se concentreze asupra sarcinilor de lucru. Dar în unele situaţii,
nerăbdarea se întoarce împotriva proiectului. Unele activităţi
politice, birocratice sau inter-organizaţionale sunt consumatoare de
timp. De exemplu, dacă o persoană importantă trebuie să vină la un
moment dat la o întâlnire, managerul de proiect trebuie să fie
răbdător. A şti când să forţezi o problemă şi când să te retragi şi să
laşi lucrurile să meargă de la sine este o calitate pe care trebuie să şi-
o dezvolte managerii de proiect.
7. Curajul / frica. O idee greşită este aceea că oamenilor curajoşi nu le
este frică. De fapt, curajoşi sunt cei cărora le este frică, dar cu toate
acestea aleg să acţioneze. Un manager de proiect trebuie să aibă o
bună înţelegere a tuturor lucrurilor care pot merge rău şi să le
considere posibile. Dar, cu toate acestea, el trebuie să aibă curajul
necesar pentru a accepta provocări mari.
8. Încrederea / scepticismul. Nu este nimic mai important pentru
moralul echipei decât un lider respectat care crede în ceea ce face.
Un manager de proiect trebuie să aibă încredere în munca realizată şi
să vadă adevărata valoare a obiectivelor ce vor fi atinse. În acelaşi
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ă întrebări, să conteste presupunerile altora şi să aducă
problemele dificile la lumină. Cheia este capacitatea de a pune
întrebări referitoare la presupunerile cuiva, de a-i contesta ipotezele
fără a zdruncina încrederea echipei în munca pe care o face.
Persoanele cu astfel de abilităţi se găsesc foarte rar, cu atât mai mult

cele care au capacitatea de a le echilibra eficient. Multe dintre greşelile pe
care le face un manager de proiect sunt cauzate de ineficienţa echilibrării
29
acestor forţe conflictuale. Totuşi, oricine poate deveni mai bun în

recunoaşterea, înţelegerea şi apoi în creşterea abilităţilor sale de a ţine
forţele în echilibru. Privind această listă de forţe conflictuale inevitabile,
managerul de proiect poate reconsidera ce face şi de ce, pentru a lua decizii
mai bune.
1.4.2. Presiunile şi neatenţia
Una din temerile managerilor de proiect începători este aceea că

succesul necesită schimbare: modificare, construire sau distrugere.
Menţinerea stării 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 astăzi cum era anul trecut, asta înseamnă
că a rămas în urmă deoarece atingerea scopurilor a fost rău direcţionată sau
execuţia proiectului a eşuat î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 gândi, altceva de învăţat şi aplicat, sau un nou proces care
face munca mai uşoară şi mai eficientă. Un manager bun are nevoie de
abilităţi de lider, iar un lider bun necesită abilităţi de management. Oricine e
implicat în managementul proiectelor este responsabil de câte un pic din
amândouă, indiferent ce scrie în fişa postului.
Revenind la chestiunea presiunii, sunt mulţi manageri care fug de
momentele în care trebuie să fie şi lideri, de exemplu când echipa are nevoie
de cineva care să ia o decizie, şi se complac în a urmări eforturile altora în
loc să faciliteze sau chiar să participe la ele. Dacă cineva stă tot timpul şi
ţine scorul sau priveşte de pe margine, acesta este mai potrivit pentru un
post de contabil. Când cineva cu un rol de lider răspunde la presiune
ferindu-se de ea, el nu conduce, ci se ascunde. Managerii de proiect laşi sau
ineficienţi tind să fie împinşi înspre periferia proiectului, de unde aduc
puţină valoare acestuia.
Unii manageri în această situaţie se rezumă la a cuantifica lucruri
care nu trebuie cuantificate. Nesiguri de ce ar trebui să facă sau prea speriaţi
să facă ce trebuie făcut, ei îşi ocupă timpul cu lucruri secundare. Cu cât
spaţiul dintre manager şi proiect creşte, cu atât mai mult creşte şi timpul
30
alocat verificării 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 puţin importante cu care se lucreză
mai uşor precum fişe 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 greşeală
care apare nu este din vina lui.
Pentru a minimiza posibilitatea confuziilor, managerii de proiect
buni rezistă tentaţiei de a defini limite stricte asupra muncii pe care sunt
dispuşi 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 mână de oameni. Rolurile bine definite îi pot
ajuta pe aceşti 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 greşeli 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 I’d ever had. In response, I
developed the belief that if I could write everything down into
checklists, I’d never fail. While things do need to be tracked carefully
on a project, I’d taken it too far. I’d 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 I’d 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 you’re going,
31
soon you’ll 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. Atâta timp cât managerii de proiect sunt
atenţi şi câştigă încrederea echipei, orice scăpare privind sarcinile,
procesele, rapoartele sau listele necesare managementului de proiect va ieşi
la lumină înainte ca problemele pe care acestea le pot rezolva să devină
serioase.
1.4.3. Măsurarea performanţelor
Deseori există presupuneri tacite sau chiar explicite despre modul în

care un individ este recunoscut sau nu pentru performanţele sale.
Dezvoltatorii sunt premiaţi pentru terminarea sarcinilor la timp. Testerii sunt
recompensaţi pentru efectuarea a numeroase teste şi găsirea multor defecte.
Specialiştii pentru suport telefonic sunt răsplătiţi pentru preluarea a
numeroase apeluri şi rezolvarea lor şi aşa mai departe. Totuşi, folosirea unor
metrici liniare pentru măsurarea performanţelor unui individ poate fi
neproductivă.
Aşa cum reiese din figura 1.3, când un sistem de măsurare este pus
în aplicare, măsurile performanţelor încep să crească. La început, valoarea
reală a organizaţiei poate de asemenea să crească. Acest fenomen are loc
într-o anumită măsură pentru că angajaţii nu înţeleg sistemul de măsurare
foarte bine la început, aşa că aleg calea cea mai sigură de a atinge scopurile
organizaţionale. Îmbunătăţiri reale pot apărea şi pentru că primele ţinte sunt
modeste şi nu determină angajaţii să înşele sistemul. Cu trecerea timpului
însă, cu cât standardele organizaţiei cresc prin mărirea cotelor sau inducerea
unei stări de competiţie între angajaţi, sunt folosite căi de atingere a
scopurilor incompatibile cu politicile firmei. Când un grup de angajaţi vede
alt grup că profită de scăpările sistemului de evaluare, grupul mai lent simte
presiunea de a-i imita. Treptat, măsurile îşi pierd relevanţa pentru
32
adevăratele performanţe, fiindcă angajaţii cedează presiunii de a înşela

sistemul. Performanţele măsurate cresc, însă adevăratele performanţe scad
dramatic. În acest mod sistemul de măsurare devine disfuncţional.
Nivel de performanţă
Indicatorii măsurătorii
Performanţa reală
Timp
Figura 1.3. Efectul măsurării unidimensionale a performanţei
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 angajaţi să contribuie în mod liniar la munca din

organizaţie, ca programatorii simpli, ci să amplifice valoarea celor din jurul
lor. Metodele prin care se poate adăuga această valoare diferă de munca
realizată la nivelurile inferioare. Dar pentru că mulţi manageri sunt foşti
33
programatori care au fost promovaţi, sunt şanse ca ei să aibă mai mult talent
la scrierea codului decât la conducerea unor persoane.
Prezenţa unui manager ar trebui să contribuie cu ceva de altă natură
decât simpla adăugare a unei contribuţii individuale. Uneori această
contribuţie vine din aplanarea conflictelor şi izolarea echipei de partea
politică. Alteori se referă la planificarea de nivel înalt sau găsirea unor căi
de evitare a situaţiilor neaşteptate. Pentru că aceste contribuţii sunt mai greu
de măsurat, mulţi manageri de proiect au o problemă cu ambiguitatea rolului
lor.
Cea mai bună metodă de a găsi punctele de echilibru este utilizarea
diferenţei psihologice pe care o conferă poziţia de pe un nivel superior. Un
manager de proiect, în timpul activităţilor sale, va petrece în mod natural
mai mult timp cu oamenii din echipă decât alţii, obţinând astfel mai multe
surse de informare şi o perspectivă mai largă asupra proiectului. Un
manager de proiect va înţelege atât perspectiva comercială a proiectului cât
şi pe cea tehnică şi va ajuta echipa să comute între cele două dacă este
necesar. Această perspectivă mai largă face posibilă oferirea unor informaţii
critice angajaţilor la momentul potrivit.
As a habit, I’ve always walked the halls and dropped in on

programmers who had their doors open. I’d 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, I’d watch a demo of
whatever they’d 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 Fred’s 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 couldn’t 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 activităţile. Transferul la timp al informaţiilor
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 întâmplă, pentru că
reţelele sociale sunt întotdeauna mai puternice şi uneori mai rapide decât
cele tehnice. Marile provocări precum viziunea asupra proiectului, listele de
caracteristici şi graficele de lucru se reduc la o serie de numeroase provocări
mai mici care sunt influenţate de cât de bine curg informaţiile într-o echipă.
Managerii de proiect joacă un rol critic în menţinerea activă a acestui flux
de informaţii.
Managerii de proiect petrec mai mult timp cu fiecare persoană din
echipă decât oricine altcineva. Ei participă la mai multe întâlniri, intră în
mai multe birouri şi vorbesc cu mai mulţi colaboratori decât oricine
altcineva din organizaţie. Dacă un manager de proiect e fericit, supărat,
motivat sau deprimat, ceva din aceste stări de spirit se va reflecta şi asupra
oamenilor pe care îi întâlneşte în fiecare zi. Ceea ce un manager aduce
proiectului, bun sau rău, va fi contagios pentru restul echipei.
1.5. Concluzii
Managerii de proiect buni câştigă de obicei un anumit respect din

partea proiectanţilor, 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 gândire şi de conducere
cu un impact pozitiv asupra echipei. De obicei, aceasta implică găsirea unor
optimizări inteligente în fluxul zilnic de lucru sau aducerea unui impuls de
entuziasm şi încurajare în direcţia potrivită la momentul potrivit. Managerii
de proiect nu trebuie să fie supra-oameni sau să fie deosebit de inteligenţi.
35
Trebuie doar să înţeleagă avantajul perspectivei lor asupra situaţiei ş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
doesn’t 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 I’ve 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, what’cha doing?”
And I’d 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 dezvoltării unui
produs software. Este planul de acţiune privind succesiunea celor patru faze
ale ingineriei programării: analiza, proiectarea, implementarea şi testarea.
Unele companii folosesc propriile metodologii. Altele folosesc
metodologii comerciale. Însă fără o metodologie adecvată, dezvoltarea
produsului este haotică.
Alegerea unei metodologii de dezvoltare trebuie să ţină seama de
natura fiecărui proiect: mărimea 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 puţin 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 puţini dezvoltatori. Recomandarea
în această situaţie este introducerea treptată a unor modalităţi formale de
dezvoltare şi verificare.
2.3. Metodologia secvenţială
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 tranziţie de fază poate fi necesară o decizie

managerială. Se recomandă pentru probleme bine înţelese, pentru
automatizarea unor sisteme manuale existente sau pentru proiecte de scurtă
durată.
Figura 2.1. Metodologia secvenţială
Avantaje. Metodologia secvenţială este potrivită când complexitatea

sistemului este mică iar cerinţele sunt statice. Este simplă, logică şi uşor de
urmat. Forţează menţinerea unei discipline de lucru în care analiza şi
proiectarea au loc înaintea implementării. Se evită presiunea scrierii codului
înainte de a cunoaşte precis ce produs va trebui de fapt construit şi deci
scade probabilitatea introducerii unor părţi de cod inutile sau ineficiente în
produsul final. Un mare număr de sisteme software din trecut au fost
construite cu o metodologie secvenţială.
Dezavantaje. Se acordă o foarte mare importanţă fazei de analiză.
Analiştii trebuie să definească toate detaliile aplicaţiei încă de la început şi
nu există un proces de corectare a erorilor după stabilirea cerinţelor.
Comunicarea dintre echipele desemnate pentru fazele de dezvoltare se
limitează în principal la documentele realizate de o echipă şi trimise
următoarei echipe. Într-un mediu economic dinamic, metodologia
secvenţială poate produce sisteme care, la vremea lansării, 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 iniţială
există o întoarcere, un pas înapoi interactiv între fiecare două etape
succesive.
38
Cerinţe sistem şi validare
Cerinţe software şi validare
Proiectare preliminară şi validare
Proiectare detaliată şi validare
Implementare, testare,
depanare şi desfăşurare
Pre-operare, testare de validare
Operare, întreţinere, revalidare
Figura 2.2. Metodologia cascadă
Dezavantajul principal al modelului cascadă apare deoarece clientul

obţine o viziune practică asupra produsului doar în momentul terminării
procesului de dezvoltare. De asemenea, modelul nu are suficientă putere
descriptivă, în sensul că nu integrează activităţi ca managementul riscului
sau managementul configuraţiei.
39
2.4. Metodologia ciclică (iterativă)
Se bazează pe ideea perfecţionării incrementale a metodologiei

secvenţiale. 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 iteraţii prin toate fazele. Pe măsură ce
procesul înaintează, sunt generate din ce în ce mai multe detalii. În final,
după câteva 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 esenţial, unde apar riscuri asociate cu o
durată mare a proiectului sau unde cerinţele nu pot fi cunoscute exact de la
început.
Figura 2.3. Metodologia ciclică
Avantaje. Permite feedback-ul de la fiecare echipă în ceea ce

priveşte corectitudinea cerinţelor. Există etape în care pot fi corectate
eventualele greşeli. Clientul poate studia rezultatul şi poate oferi informaţii
importante mai ales în faza dinaintea lansării produsului. Dezvoltarea se
poate adapta mai bine progresului tehnologic: pe măsură ce apar noi soluţii,
ele pot fi încorporate în produs. Pot avea loc livrări regulate sau rapide.
Permite prioritizarea cerinţelor.
Dezavantaje. De vreme ce nu există constrângeri asupra echipei de
analiză să facă lucrurile cum trebuie de prima dată, acest fapt poate duce la
scăderea responsabilităţii. Echipa de proiectare nu are o viziune globală
asupra produsului şi deci nu poate realiza o arhitectură completă. Fiecare
iteraţie necesită un timp suplimentar de planificare. Ciclurile pot continua
fără o condiţie clară de terminare. Echipa de implementare poate fi pusă în
situaţia nedorită în care cerinţele şi arhitectura sistemului sunt în permanentă
schimbare iar renunţarea la părţi de cod deja scrise determină creşterea
costurilor.
40
2.4.1. Metodologia spirală
Metodologia spirală, propusă de Barry Boehm (1988), consideră că

fiecare pas din dezvoltare conţine o serie de activităţi comune:
 pregătirea: se identifică obiectivele, alternativele, constrângerile;

 managementul riscului: analiza şi rezolvarea situaţiilor de risc;
 activităţi de dezvoltare specifice pasului curent, de exemplu analiza
cerinţelor sau scrierea de cod;
 planificarea următorului stadiu: termenele limită, resursele necesare,
revizuirea stării curente a proiectului.
Figura 2.4. Metodologia spirală
41
Procesul începe în centrul spiralei. Fiecare ciclu terminat reprezintă

o etapă. Pe măsură ce se parcurge spirala, produsul se maturizează. Cu
fiecare ciclu, sistemul se apropie de soluţia finală.
2.4.2. Metodologia Timeboxing
Încearcă accelerarea procesului de dezvoltare prin aplicarea

paralelismului între diferite iteraţii. Unitatea de bază este o casetă de timp
(engl. “time box”), cu durată fixă. De aceea, un factor cheie în alegerea
cerinţelor este ce poate fi realizat într-o casetă de timp. Acest fapt
contrastează cu metodologiile iterative clasice în care mai întâi se hotărăşte
funcţionalitatea şi abia apoi timpul de livrare. Fiecare casetă de timp este
împărţită î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ă. Când o echipă termină etapa i din
caseta de timp k, îi predă livrabilul echipei dedicate fazei i+1 şi apoi începe
lucrul la aceeaşi 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 următoarele la câte T / n zile distanţă. De exemplu, dacă T este 9
săptămâni iar n este 3, prima livrare va fi făcută după 9 săptămâni, a doua la
12 săptămâni, a treia la 15 ş.a.m.d. Execuţia liniară a iteraţiilor ar conduce la
termene de livrare de 9, 18, respectiv 27 de săptămâni.
Costul suplimentar pentru scurtarea timpului de livrare stă în
utilizarea resurselor. De exemplu, dacă pentru un proiect analiza şi
proiectarea durează 2 săptămâni cu 2 persoane, implementarea 2 săptămâni
cu 4 persoane iar testarea 2 săptămâni cu 3 persoane, pentru execuţia serială
a iteraţiilor 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 creşterea dimensiunii echipei,
complexitatea managementului şi costul ridicat.
Metodologia se recomandă atunci când sunt necesare termene de
livrare scurte şi există flexibilitate în gruparea funcţionalităţilor, astfel încât
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 secvenţiale cu
incrementele iterative ale metodologiei ciclice.
43
Figura 2.6. Metodologia hibridă ecluză
În prima etapă, schiţa 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 soluţie poate fi găsită şi pusă în practică.
În cea de a doua etapă, de prototip, cerinţele sunt îngheţate. 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 (părţile interesate) că o soluţie este
posibilă.
În versiunile alfa şi beta, arhitectura este îngheţată, iar accentul cade
pe implementare şi asigurarea calităţii. Rolul acestei etape este de a
convinge clienţii că aplicaţia va fi un produs adevărat.
Înainte de lansarea produsului, implementarea este îngheţată şi
accentul cade pe testare. Scopul este realizarea unui produs competitiv.
2.6. Modelul V
Modelul V (germ. “V-Modell”) evidenţiază testarea pe tot parcursul

ciclului de dezvoltare. A fost creat pentru reglementarea dezvoltării
produselor software în administraţia federală germană. Modelul poate fi
44
considerat o extensie a metodologiei cascadă, însă pune accentul pe relaţia

dintre fiecare fază de dezvoltare şi faza de testare asociată. Trecerea la faza
următoare 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 specificaţiilor. Metodele formale sunt
potrivite în special pentru sisteme cu cerinţe critice.
Avantaje:
 precizia obţinută prin specificarea formală;
45
 păstrarea corectitudinii în timpul transformării specificaţiilor în cod

executabil;
 oferă posibilitatea generării automate de cod;
 verificarea consistenţei şi testarea prin metode similare demonstrării
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 specificării formale nu implică
neapărat obţinerea de programe sigure, deoarece anumite aspecte
critice pot fi omise din specificaţii.
Figura 2.8. Specificaţie în limbajul Z
46
2.8. Programarea extremă
Programare extremă (engl. “eXtreme Programming”) este o

metodologie „agilă”, potrivită dezvoltării rapide de aplicaţii, propusă de
Kent Beck (1996). Dintre caracteristicile XP, amintim următoarele:
 Echipa de dezvoltare nu are o structură ierarhică. Fiecare contribuie

la proiect folosind maximul din cunoştinţele sale;
 Scrierea de cod este activitatea cea mai importantă;
 Proiectul este în mintea tuturor programatorilor din echipă, nu în
documentaţii, modele sau rapoarte;
 La orice moment, un reprezentant al clientului este disponibil pentru
clarificarea cerinţelor;
 Codul se scrie cât mai simplu;
 Se scrie mai întâi cod de test;
 Dacă apare necesitatea rescrierii sau eliminării codului, aceasta se
face fără milă;
 Modificările aduse codului sunt integrate continuu, de câteva ori pe
zi;
 Se programează în perechi. Echipele se schimbă la sfârşitul unei
iteraţii (1-2 săptămâni);
 Se lucrează 40 de ore pe săptămână, fără 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ă preţuim:
Oamenii şi interacţiunile mai mult decât procesele şi instrumentele

Software-ul funcţional mai mult decât documentaţia cuprinzătoare
Colaborarea cu clienţii mai mult decât negocierea contractelor
Adaptarea la schimbare mai mult decât respectarea unui plan
Mai exact, deşi elementele din dreapta sunt valoroase, le preţuim mai
mult pe cele din stânga.
47
Principiile Manifestului agil
Respectăm următoarele principii:
1. Prima noastră prioritate este aceea de a satisface clienţii prin livrări

neîntârziate şi continue de software valoros.
2. Acceptăm schimbarea cerinţelor, chiar şi mai târziu în procesul de
dezvoltare. Procesele agile valorifică schimbarea în avantajul
competiţional al clientului.
3. Livrăm frecvent software funcţional, de la câteva săptămâni până la
câteva luni, preferând 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 informaţiilor
către şi în cadrul echipei de dezvoltare o reprezintă conversaţia faţă
în faţă.
7. Software-ul funcţional este principala măsură a progresului.
8. Procesele agile promovează dezvoltarea durabilă. Sponsorii,
dezvoltatorii şi utilizatorii trebuie să fie capabili să menţină un ritm
constant pe timp nedefinit.
9. Atenţia continuă pentru superioritate tehnică şi proiectare bună
sporeşte agilitatea.
10. Simplitatea – arta maximizării cantităţii de muncă neefectuată – este
esenţială.
11. Cele mai bune arhitecturi, cerinţe şi proiectări 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 corespunzător
comportamentul.
Carta drepturilor dezvoltatorului:
 Ai dreptul să ştii ceea ce se cere, prin cerinţe clare, cu declaraţii clare

de prioritate;
 Ai dreptul să spui cât îţi va lua să implementezi fiecare cerinţă, şi să
îţi revizuieşti estimările în funcţie de experienţă;
48
 Ai dreptul să îţi accepţi responsabilităţile, în loc ca acestea să-ţi fie

atribuite;
 Ai dreptul să faci treabă de calitate în orice moment;
 Ai dreptul la linişte, distracţie şi la muncă productivă şi plăcută.
Carta drepturilor clientului:
 Ai dreptul la un plan general, să ştii ce poate fi făcut, când, şi la ce

preţ;
 Ai dreptul să vezi progresul într-un sistem care rulează şi care se
dovedeşte că funcţionează trecând teste repetabile pe care le specifici
tu;
 Ai dreptul să te răzgândeşti, să înlocuieşti funcţionalităţi şi să
schimbi priorităţile;
 Ai dreptul să fii informat de schimbările în estimări, suficient de
devreme pentru a putea reduce cerinţele astfel ca munca să se
termine la data prestabilită. Poţi chiar să te opreşti la un moment dat
şi să rămâi cu un sistem folositor care să reflecte investiţia până la
acea dată.
2.9. Metodologia Open Source
Conceptul de dezvoltare open-source (sursă la vedere) este o

abordare recentă, apărută ca urmare a dezvoltării mijloacelor de comunicare
prin internet: email, grupuri de discuţie, site-uri dedicate dezvoltării
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ă (fără
patent), pe baza unei licenţe open-source (de exemplu GNU).
O iteraţie tipică:
 Iniţiatorul realizează proiectarea şi implementarea, individual sau în

echipă;
 Ceilalţi dezvoltatori sau comunitatea de utilizatori realizează testarea
şi eventual depanarea;
49
 Noile funcţionalităţi dorite şi erorile depistate sunt trimise

iniţiatorului proiectului;
 Se lansează o nouă versiune cu defectele corectate şi se analizează
noile cerinţe;
 Se distribuie o listă de sarcini către comunitatea de utilizatori,
căutându-se membri voluntari care să execute sarcinile de pe listă.
Avantaje:
 Preţ mult mai mic decât 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 garanţiilor de calitate;

 Risc privind cazurile de încălcare a proprietăţii intelectuale, dacă
programatorii folosesc surse proprietare, greu de verificat;
 Unele licenţe prevăd 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 funcţiile care pot fi

dezvoltate mai ieftin în altă ţară. Un proiect tipic are următoarele etape:
 Iniţierea proiectului (local);

 Analiza cerinţelor (local);
 Proiectarea de nivel înalt (local);
 Proiectarea detaliată (offshore);
 Implementarea (offshore);
50
 Testarea (offshore sau local);

 Livrarea (local).
Motive pentru outsourcing:
 Reducerea costurilor;
 Creşterea eficienţei;
 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 confidenţialitate şi securitate;
 Risc în cazul falimentului companiei offshore;
 Probleme de limbă, fus orar.
2.11. Concluzii
Simpla adoptare a unei metodologii fără o analiză temeinică a

cerinţelor ş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ă aşa-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 semnătura persoanei autorizate
să creeze şi să finanţeze 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 conţine şi justificarea financiară a proiectului.
Una din justificările cele mai puternice este conceptul de beneficiu
financiar pentru organizaţia care depune efortul de realizare a proiectului.
Desigur, există şi alte justificări, precum răspunsul la noi reglementări
guvernamentale, creşterea cotei de piaţă sau oportunităţi 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 investiţie iniţială, costul

variabil se reprezintă începând cu punctul de pe axa verticală corespunzător
costului total fix iniţial al proiectului. Dacă alternativa este de a nu realiza
proiectul, costul iniţial este nul.
La un anumit moment de timp, dacă proiectul are un beneficiu,
liniile variabile se intersectează. Acesta este „pragul de rentabilitate”, când
beneficiile proiectului depăşesc costurile în comparaţie cu alternativa de a
nu face proiectul. Punctul corespunzător de pe axa timpului reprezintă
perioada de recuperare a investiţiei (engl. “payback period”).
De exemplu, sistemul de automatizare a producţiei unei firme poate
asigura producerea de componente cu 2 USD bucata. Un nou sistem ar putea
creşte productivitatea la 1,5 USD / componentă, însă necesită o investiţie
iniţială de 200.000 USD. Firma produce 25.000 de componente pe lună.
Pragul de rentabilitate este afişat în figura 3.2.
54
Figura 3.2. Exemplu de diagramă a pragului de rentabilitate
Această metodă este potrivită când se presupune că ratele de

producţie sunt constante, astfel încât costurile totale sunt liniare.
Dezavantajul este că proiectele cu o recuperare rapidă a investiţiei sunt
favorizate în comparaţie cu proiectele care ar putea aduce mai mult profit pe
termen lung.
3.3. Rata medie de recuperare a investiţiei

(Average Rate of Return on Investment)
Elimină problema orizontului de timp a metodei pragului de

rentabilitate, comparând toate alternativele pe aceeaşi perioadă de timp:
durata aproximativă de viaţă a produselor rezultate din proiect.
Continuând exemplul anterior, luăm acum în calcul şi variaţiile de
productivitate şi cheltuielile de întreţinere ale sistemului, care apar după
câţiva ani de funcţionare (tabelul 1-1). În acest caz, profitul de 935.000 USD
pentru investiţia de 200.000 USD reprezintă o rată de recuperare de 467,5%
în 10 ani, adică o rată medie de recuperare a investiţiei de 46,75%.
55
3.4. Valoarea actuală netă (Net Present Value)
Metoda pleacă de la principiul că banii primiţi sau cheltuiţi în viitor

valorează mai puţin decât banii din prezent. De exemplu, dacă se depun la
bancă 100 USD cu o dobândă 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 dobânda iar n
este numărul de ani.
Invers, se poate utiliza aceeaşi formulă pentru a calcula valoarea
actuală a unei sume de bani din viitor:
VV
VA  .
1  d n
Considerând acelaşi nivel al dobânzii, de 5%, putem spune că 100

USD primiţi peste un an sunt echivalenţi cu 95,24 USD primiţi în prezent
iar 100 USD primiţi peste 10 ani sunt echivalenţi cu 61,39 USD primiţi în
prezent.
Multe proiecte pornesc cu o investiţie iniţială, urmând 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 decât proiectele care au acelaşi profit mai târziu.
Valoarea actuală netă este suma intrărilor şi ieşirilor de capital
ajustată la valoarea actuală.
În tabelul 1-2 se prezintă spre comparaţie 2 proiecte care presupun o
investiţie iniţială 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 dobânzii se consideră 7%. Ambele proiecte au
intrări 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.
Totuşi, 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 creşterea cotei de piaţă etc. după cum am
menţionat mai sus.
57
3.5. Rata internă de recuperare a investiţiei

(Internal Rate of Return on Investment)
În exemplul din tabelul 1-2, proiectul A a fost preferat de fapt

datorită ratei dobânzii. Dacă aceasta ar fi fost 0%, ambele proiecte ar fi fost
la fel de atractive.
Metoda ratei interne de recuperare a investiţiei 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 dobândă mică. Alternativ, banii pot fi investiţi pentru realizarea unui
proiect, unde riscul este mai mare dar şi profiturile pot fi mai mari.
La dobânzi mici, vor fi favorizate investiţiile în proiecte cu riscuri
asociate dar şi cu intrări mai mari de capital. Pe măsură ce dobânda creşte,
diferenţa dintre cele două tipuri de investiţii va scădea până când investiţia
lipsită de risc va fi mai potrivită.
Pentru această metodă de justificare financiară, se calculează rata
dobânzii bonurilor de trezorerie care ar face ca investiţia în bonuri şi
investiţia în proiect să fie la fel de atractive. Pentru aceasta, comparăm
valoarea actuală netă a proiectului la sfârşitul ciclului de viaţă cu valoarea
actuală netă a unei investiţii fără risc (0).
Conform metodei, se determină dobânda limită pentru care valoarea
actuală netă a ciclului de viaţă estimat al proiectului (N ani) este 0:
N
Ct
V Anet   0,
t 0 1  d 
t
unde Ct sunt intrările (valori pozitive) şi ieşirile (valori negative) de capital.

Rata internă de recuperare este rata de actualizare (engl. „discount
rate”) la care totalul intrărilor de capital în valoare actualizată egalează
totalul ieşirilor de capital la valoare actualizată.
De exemplu, să considerăm proiectul A din exemplul anterior şi să
analizăm fluxul de capital pentru diferite rate de dobândă (tabelul 1-3). Dacă
vom calcula valoarea actuală în fiecare caz, observăm că, la sfârşitul ciclului
de viaţă estimat, valorile nete sunt pozitive sau negative. Ne interesează
valoarea limită la care totalul este 0, care se vede că aparţine intervalului
58
(40% – 42,5%). Se poate determina iterativ, pe baza împărţirilor succesive

ale intervalului, valoarea exactă: 41,2%.
Se consideră că un proiect este o investiţie bună dacă rata sa de
recuperare este mai mare decât rata de recuperare a unei investiţii
alternative. Cu cât este mai mare rata de recuperare, cu atât mai dezirabilă
este demararea unui proiect. Astfel, rata de recuperare poate fi folosită
pentru a ierarhiza diferite proiecte potenţiale pe care le-ar putea realiza o
firmă.
Rata internă de recuperare este un indicator al eficienţei sau calităţii
unei investiţii, spre deosebire de valoarea actuală netă care reflectă mărimea
investiţiei.
3.6. Concluzii
Toate proiectele trebuie justificate, de obicei pe baza comparării

costurilor cu beneficiile. În prezent, metoda cea mai utilizată pentru
justificarea financiară a proiectelor este cea a ratei interne de recuperare a
investiţiei.
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 activităţile necesare, şi numai activităţile 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 următoarele aspecte:
 Definirea domeniului;
 Crearea structurii de descompunere a activităţilor;
 Verificarea domeniului;
 Controlul domeniului.
Trebuie reţinut faptul că îndeplinirea domeniului proiectului este

măsurată în raport cu planul proiectului, iar îndeplinirea domeniului
produsului este măsurată în raport cu cerinţele produsului.
4.2. Definirea domeniului
Cel mai frecvent motiv pentru eşecul proiectelor este definirea

deficitară a domeniului, atunci când aşteptările părţilor interesate, în special
ale clientului sau sponsorului, sunt diferite de aşteptările echipei proiectului.
Uneori, este dificil de convins clientul că atât el cât şi echipa au de fapt
acelaşi scop în cadrul proiectului, acela de a-i oferi clientului un produs util
şi cu funcţionalităţile dorite.

Echipa proiectului trebuie de asemenea să îl înţeleagă pe client şi să

nu devină frustrată în cazul în care acesta pare să ştie mai puţin despre
proiect decât însăşi 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 activităţilor, SDA (engl. “Work Breakdown Structure”,
WBS) şi verificarea domeniului au loc în mod iterativ în metodologiile
agile. O SDA clasică este de obicei împărţită la nivel înalt în fazele de
analiză, proiectare, implementare, testare şi apoi acţiuni de desfăşurare
(engl. “deployment”). Fiecare din aceste faze este descompusă mai apoi în
pachete de activităţi (engl. “work packages”). Planificarea tradiţională a
unui proiect este top-down şi se bazează pe elaborarea de activităţi detaliate
cu estimări şi dependenţe care ghidează graficul de lucru al proiectului cu
ajutorul analizei drumului critic. Totuşi, o descompunere excesivă poate
conduce la un efort de management neproductiv, la o utilizare inadecvată a
resurselor şi la scăderea eficienţei de executare a lucrărilor.
În metodologiile agile aceste practici sunt abordate diferit. Se
definesc caracteristicile (engl. “features”) de nivel înalt ale produsului şi
apoi acestea sunt alocate iteraţiilor de lansare (engl. “release”). O iteraţie
sau chiar o caracteristică poate fi considerată echivalentul agil al unui pachet
de activităţi. Caracteristicile sunt estimate în linii generale, fără a se detalia
activităţile sau resursele asociate. Când începe o iteraţie, caracteristicile
alocate (şi numai acestea) sunt descompuse pe activităţi care reprezintă
planul de dezvoltare. În acest mod se previne acumularea unor cerinţe
detaliate care s-ar putea să nu trebuiască implementate niciodată. Durata
scurtă a unei iteraţii îmbunătăţeşte capacităţile de planificare şi control şi
reduce numărul de detalii şi complexitatea estimărilor. Abordarea agilă
pleacă de la premisa că vor apărea schimbări dese ale cerinţelor şi deci că nu
trebuie realizată o descompunere detaliată pe activităţi până în momentul în
care se poate începe lucrul efectiv la o caracteristică.
Tabelul 4.1 prezintă o comparaţie între abordarea clasică şi cea agilă
în privinţa definirii domeniului, care în proiectele agile se numeşte
planificare multinivel.
64
Tabelul 4.1. Definirea domeniului

Abordarea clasică Abordarea agilă
Pregătirea unui document de Specificare Organizarea unei întâlniri pentru
a Domeniului Proiectului, care include definirea viziunii asupra produsului,
elemente precum: obiectivele şi limitele confirmarea şi clarificarea obiectivelor,
proiectului, descrierea domeniului limitelor şi descrierea domeniului prin
exerciţii precum enunţul din lift (engl.
“elevator pitch”)
Definirea punctelor de referinţă (engl. Organizarea unei întâlniri de planificare
“milestones”) şi a livrabilelor a foii de parcurs (engl. “roadmap”) a
proiectului proiectului, precum şi întâlniri (de
exemplu trimestriale) de planificare a
punctelor de referinţă şi a livrabilelor la
nivel de iteraţie
Specificaţiile produsului şi criteriile de Întâlnire de planificare a iteraţiei cu
acceptare / recepţie scopul stabilirii detaliilor fiecărei
caracteristici şi a activităţilor necesare
pentru terminarea acestora pe baza
criteriilor de finalizare ale echipei şi a
criteriilor de acceptare ale clientului
Presupuneri şi constrângeri Toate întâlnirile identifică sau
revizuiesc presupunerile şi
constrângerile
Într-o primă fază, sunt eliminate din listă cerinţele asupra cărora
toate părţile interesate cad de acord că nu sunt necesare. S-ar putea să
trebuiască eliminate în continuare unele cerinţe asupra cărora nu există un
consens, pe baza analizei de fezabilitate, a priorităţilor şi a importanţei
părţilor interesate. Cerinţele rămase reprezintă linia de bază (engl.
“baseline”) a domeniului proiectului. În general, este importantă
documentarea cerinţelor care nu au fost implementate la un moment dat,
împreună cu justificarea deciziei de neimplementare. Dacă excluderea nu
este documentată adecvat, aceste cerinţe se pot reîntoarce ulterior drept
cerinţe noi pe parcursul derulării proiectului.
De asemenea, toate elementele din linia de bază a domeniului trebuie
clar definite. Trebuie să existe rezultate concrete, măsurabile, care trebuie
îndeplinite. Acestea trebuie documentate împreună cu criteriile de acceptare,
65
ca parte a definirii domeniului. Dacă nu se întâmplă acest lucru, domeniul

nu poate fi verificat, iar clienţii pot solicita mereu introducerea unor noi
cerinţe sau pot refuza produsul datorită unei interpretări diferite a
specificaţiilor.
4.3. Crearea structurii de descompunere a

activităţilor
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 sfârşitul planificării pentru lansare, echivalentul agil
al unei SDA arată ca în figura 4.3. Rezultatele unei întâlniri de planificare a
iteraţiei arată ca în figura 4.4.
Figura 4.1. Plan de lansare în metodologie agilă
66
Figura 4.2. Plan de iteraţie în metodologie agilă
Figura 4.3. Rezultatele unei întâlniri de planificare a lansării
67
Figura 4.4. Plan de iteraţie parţial

în privinţa descompunerii activităţilor. În proiectele agile, SDA se regăseşte
în planul de lansare şi în planul de iteraţie.
Tabelul 4.2. Crearea SDA

Crearea unei diagrame a SDA Întâlniri de planificare în care se conferă
echipei responsabilitatea descompunerii
lucrului în pachete de activităţi mai mici
4.4. Verificarea domeniului
Verificarea domeniului se realizează în cadrul iteraţiei, clientul

putând revizui, testa şi accepta caracteristicile implementate. În mod ideal,
aceasta are loc pe parcursul iteraţiei, dar poate avea loc şi la sfârşitul
acesteia, la prezentarea (demonstrarea) codului. Caracteristicile
neimplementate, din lipsa timpului sau din cauza problemelor de
68
specificare, sunt reintroduse pe lista de cerinţe (engl. “backlog”) sau intră în

următoarea iteraţie, conform deciziei clientului.
4.5. Controlul domeniului
În metodologiile agile, controlul domeniului constă în:
 gestionarea listei de cerinţe (“backlog”);

 protejarea iteraţiei.
Clientul gestionează lista de cerinţe iar managerul de proiect

protejează echipa şi previne schimbările de cerinţe din timpul unei iteraţii.
Este importantă stabilirea corectă a duratei unei iteraţii, deoarece
clientul trebuie să aştepte următoarea iteraţie pentru a face modificări. Dacă
cerinţele de modificare sunt frecvente, ciclurile de iteraţii pot fi scurtate.
Pot exista excepţii; în urma discuţiilor dintre client şi managerul de
proiect, o iteraţie poate fi oprită sau reîncepută, însă aceste situaţii trebuie să
fie foarte rare.
în privinţa controlului domeniului.
Tabelul 4.3. Controlul domeniului

Utilizarea unui sistem de control al Clientul gestionează lista de cerinţe a
modificărilor produsului. Când echipa începe lucrul la
o iteraţie, domeniul rămâne blocat pe
parcursul ei
Actualizarea tuturor documentelor Echipa revizuieşte planurile de lansare
potrivit modificărilor aprobate şi foaia de parcurs în mod regulat, ori
de câte ori este nevoie pentru a
surprinde progresul echipei şi
modificările solicitate de client
69
4.6. Concluzii
Unul din motivele eşecului proiectelor este lipsa identificării clare a

livrabilelor care trebuie realizate. Fără 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 activităţilor. Definirea activităţilor specifice necesare

pentru a finaliza proiectul şi pentru a produce toate livrabilele
acestuia;
2. Ordonarea activităţilor. Identificarea interdependenţelor dintre
activităţi şi a legăturilor cu intrările externe ale proiectului;
3. Estimarea duratei activităţilor. 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 modificărilor care au loc în
proiect şi care afectează graficul de lucru al acestuia.
5.2. Definirea activităţilor
Principalul instrument necesar pentru definirea activităţilor, precum

şi pentru determinarea duratei şi succesiunii acestora este Structura de
Descompunere a Activităţilor (engl. “Work Breakdown Structure”). Metoda
este utilizată pentru a descompune proiectul în sub-proiecte mai uşor de
gestionat. SDA defineşte nivelul de control cel mai de jos pe care trebuie
să-l gestioneze managerul de proiect: nivelul pachetului de activităţi (engl.

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

pachet de activităţi poate fi împărţit la rândul său până la nivel de activitate
sau sarcină individuală.
5.3. Ordonarea activităţilor
În faza de dezvoltare a SDA, se verifică dacă fiecare activitate are

intrări corespunzătoare pentru lucrul aferent. Fiecare ieşire a unei activităţi
trebuie să fie utilizată de o altă activitate sau să fie parte a unui livrabil al
proiectului.
Dependenţele dintre activităţi pot fi:
 obligatorii: definite de natura proiectului. De exemplu, testarea de

tip „cutie albă” nu poate fi făcută decât după implementare;
 discreţionare: 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ţă conţine noduri reprezentate ca nişte

dreptunghiuri, cu orice informaţii necesare despre activităţi, precum
numărul curent, descrierea, data de începere şi terminare, durata etc.
Activităţile sunt conectate prin săgeţi care precizează relaţiile logice ale
graficului de lucru. Capătul săgeţii indică activitatea dependentă. Sunt
posibile 4 relaţii logice: sfârşit-început (FS), început-început (SS), sfârşit-
sfârşit (FF), început-sfârşit (SF).
72
Figura 5.1. Diagramă de precedenţă
Sfârşit-început (Finish-to-start, FS)
O relaţie sfârşit-început reprezintă cel mai des întâlnit tip de

dependenţă. În cadrul unei astfel de relaţii, activitatea succesoare poate
începe doar după terminarea activităţii 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-sfârşit (Start-to-finish, SF)
În relaţia început-sfârşit, activitatea succesoare se poate termina doar

înainte de începerea activităţii predecesoare. De exemplu:
 Angajaţii pot începe să folosească o nouă procedură numai după ce

au terminat pregătirea profesională pentru aceasta. În cazul în care
utilizarea noii proceduri este întârziată, se doreşte de asemenea
întârzierea pregătirii, astfel încât aceasta să aibă loc cât mai târziu
posibil înainte de punerea în aplicare. Acest exemplu de relaţie
început-sfârşit nu se poate considera ca o relaţie sfârşit-început.
Ideea este de a nu permite niciun fel de întârziere între pregătire şi
73
aplicare. Dacă noua procedură poate începe doar după ce se termină

pregătirea (relaţie sfârşit-început), noua procedură poate începe în
orice moment ulterior încheierii pregătirii, în funcţie de modul în
care alte relaţii o pot întârzia. Dacă activitatea de pregătire trebuie să
se termine chiar înainte de începerea celeilalte activităţi, întârzierile
activităţii ulterioare (de punere în aplicare) întârzie de asemenea şi
activitatea anterioară;
 Schimbul 2 începe când se termină schimbul 1. Dar nu poate exista o
perioadă între cele două schimburi în care nu lucrează nimeni. Dacă
începutul schimbului 2 întârzie, trebuie să întârzie şi sfârşitul
schimbului 1.
Figura 5.2. Comparaţie între dependenţele Început-sfârşit (Start-to-finish)

şi Sfârşit-început (Finish-to-start)
Început-început (Start-to-start, SS)
Într-o relaţie început-început, activitatea succesoare poate începe

doar în momentul în care începe activitatea predecesoare. De exemplu:
74
 Când încep să se primească rezultatele unor alegeri, se poate începe

centralizarea lor;
 Când începe lucrul la un proiect, încep şi activităţile de management.
Sau activităţile de management încep cu n zile înainte de începerea
lucrului la proiect. Activităţile de management şi cele de lucru
efectiv se desfăşoară apoi în paralel o perioadă de timp.
Sfârşit-sfârşit (Finish-to-finish, FF)
Într-o dependenţă sfârşit-sfârşit, activitatea succesoare se poate

termina doar când se termină activitatea predecesoare. De exemplu:
 Se termină instalarea calculatoarelor în acelaşi moment cu

terminarea mutării angajaţilor într-o clădire nouă, astfel încât
angajaţii să poată folosi calculatoarele imediat;
 Două divizii trebuie să termine retehnologizarea liniilor lor de
producţie în aceeaşi zi astfel încât directorul să le poată inspecta pe
amândouă.
75
5.4. Estimarea duratei activităţilor şi proiectului
5.4.1. Metoda drumului critic
Este un algoritm pentru planificarea unei mulţimi de activităţi. Se

calculează datele când se pot termina unele activităţi cel mai târziu fără a
întârzia proiectul precum şi calea cea mai lungă a activităţilor planificate
până la sfârşitul proiectului. Acest proces determină ce activităţi sunt critice
(de exemplu, pe calea cea mai lungă) şi ce activităţi au perioade de
inactivitate sau decalaj, adică pot fi amânate fără a face proiectul mai lung.
Drumul critic este succesiunea de activităţi cu durata totală cea mai mare,
care determină şi cel mai scurt timp posibil pentru a finaliza proiectul. Orice
întârziere a unei activităţi de pe drumul critic afectează direct data de
terminare a proiectului.
Spre deosebire de costul total al proiectului, în care se sumează
costurile tuturor activităţilor, durata proiectului este dată de suma duratelor
activităţilor 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 activităţilor. Multe
fenomene naturale sunt modelate bine de distribuţia normală (figura 5.3).
Pentru activităţile specifice proiectelor, s-a constat că distribuţia beta (figura
5.4) este mai potrivită, dar distribuţia normală rămâne suficient de bună din
punct de vedere practic.
76
Figura 5.3. Distribuţia de probabilitate normală (gaussiană)
77
Figura 5.4. Distribuţia de probabilitate beta
78
O aproximare a acestor două distribuţii este dată de analiza a trei

estimări formulate de un expert: o valoare optimistă, una probabilă şi una
pesimistă. Valoarea aşteptată a duratei se calculează ca o medie ponderată a
acestora:
VO  4VProb  VP
VA 
6
Deviaţia 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 aşteptată este de 100 de zile şi deviaţia 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 conţine întotdeauna aceeaşi mulţime de activităţi. Însă, în funcţie de
duratele reale, este posibil ca activităţile de pe drumul critic să se modifice,
afectând data de terminare estimată a proiectului.
Într-o simulare Monte Carlo, durata fiecărei activităţi are asociată o
distribuţie de probabilitate. Se realizează un număr mare de simulări şi se
determină o distribuţie 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ă modificării drumului critic, este posibil ca unele date de la
începutul şi sfârşitul intervalului să fie mai probabile, cu date mai puţin
probabile între ele.
Prin simulări se poate obţine şi indexul de criticalitate al
activităţilor, care reprezintă procentul din simulări în care o activitate este pe
drumul critic. De exemplu, dacă sunt realizate 1000 de simulări şi în 212
79
dintre acestea o activitate este pe drumul critic, indexul său de criticalitate

este de 21,2%.
5.5. Considerente practice ale planificării
5.5.1. Scopurile planificării
Toate planificările 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 când vor fi făcute anumite activităţi. Graficul de lucru
oferă o formă de contract pentru fiecare persoană din echipă,
confirmând ceea ce trebuie livrat sau realizat în următoarele zile,
săptămâni sau luni;
2. Al doilea scop al planificării este încurajarea tuturor celor care
contribuie la proiect să îşi vadă eforturile ca parte a unui întreg şi să
se străduiască ca părţile proprii să se îmbine cu ale altora. Câtă
vreme nu există o primă variantă a unui grafic de lucru care să
specifice datele când activităţile trebuie finalizate, toată lumea va
lucra pe cont propriu, fără să se gândească cum rezultatele proprii îi
vor afecta pe ceilalţi. Când există un grafic de lucru, se pot pune
întrebări asupra realismului unor cerinţe şi se pot face comparaţii
între ce se doreşte să realizeze proiectul şi ce pare să fie posibil într-
o anumită perioadă de timp. O funcţie de forţare (engl. “forcing
function”) este orice eveniment care determină o schimbare în
perspectivă, atitudine sau comportament. Planificările sunt funcţii de
forţare importante pentru proiect. Chiar dacă graficul de lucru nu se
respectă, se măreşte sau trece prin multe alte modificări,
angajamentele şi conexiunile făcute de persoanele din echipă se vor
păstra;
3. Al treilea scop al planificării este de a oferi echipei un instrument
pentru monitorizarea progresului şi pentru descompunerea
volumului de lucru în elemente gestionabile. Descompunerea în
80
activităţi cu durata de 1 sau 2 zile îi ajută pe oameni să înţeleagă mai

bine ce trebuie să facă.
Cu cât este mai mare şi mai complex un proiect, cu atât este mai
importantă planificarea. În proiectele mari există mai multe dependenţe între
oameni, iar deciziile şi sincronizările au şanse mai mari să îi afecteze pe
ceilalţi. Dacă apare o întârziere 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 întârzierea. Într-un proiect mai
mare, cu sute de persoane, o întârziere 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 inginereşti
greşite şi nici nu poate proteja proiectul de o conducere slabă, obiective
neclare şi comunicare deficitară. Până la urmă, cineva trebuie să folosească
planurile ca un instrument de gestionare şi conducere a proiectului.
5.5.2. Calitatea estimărilor
Planificările sunt doar nişte predicţii. Oricât de minuţioase sau

convingătoare ar arăta, ele reprezintă sumarea unui număr mare de estimări
mărunte, fiecare activitate fiind predispusă la apariţia unor diverse
probleme. Planificările de calitate sunt realizate numai de managerii care au
cunoştinţe 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 ajustărilor şi să aibă o probabilitate de succes care
satisface clientul sau sponsorul proiectului.
Estimările bune se realizează doar pentru cerinţe şi proiecte credibile
şi sunt posibile doar dacă există două lucruri: informaţii bune şi ingineri
buni.
Dacă managerii admit estimări mai puţin exacte şi deci un risc mai
mare al planificării, atunci aceste estimări sunt acceptabile. Pentru proiecte
mici şi de scurtă durată, astfel de estimări sunt suficiente. Cerinţele se pot
schimba des, iar natura organizaţiei poate cere o structură mai flexibilă. Nu
81
e nimic în neregulă cu estimările de o calitate slabă atâta timp cât nimeni nu

le confundă cu unele de calitate ridicată.
În continuare vom prezenta câteva modalităţi suplimentare pentru a
asigura estimări bune:
1. Stabilirea unor intervale de încredere pentru estimări: o

presupunere – 40%, o estimare bună – 70%, o analiză detaliată –
90%;
2. Programatorii şefi trebuie să stabilească standardul de calitate
pentru estimări, conform nevoilor echipei;
3. Programatorii trebuie crezuţi. Presiunile trebuie aplicate doar ca o
măsură de echilibrare: programatorii tind să dea estimări mai mari
pentru sarcinile care nu le plac şi estimări mai mici pentru cele care
le plac. Uneori sunt utile estimări multiple, de la doi dezvoltatori
diferiţi;
4. Estimările depind de înţelegerea scopurilor proiectului. Estimările
nu depind numai de interpretarea specificaţiilor de către
programatori, ci şi de scopurile de nivel înalt ale proiectului;
5. Estimările trebuie să se bazeze pe experienţa anterioară.
5.5.3. Omisiunile frecvente
Riscurile cele mai mari ale unei planificări apar din lucrurile
nescrise, de exemplu dacă un membru important al echipei se îmbolnăveşte
sau pleacă în concediu.
Următoarea listă de întrebări 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 săptămânal? Are acea persoană suficientă autoritate pentru a
pune întrebări sau a face corecţii?
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
planificării?
5. Au fost încurajaţi şi sprijiniţi membrii echipei să refuze noi sarcini
de lucru care nu se încadrează în viziunea şi obiectivele proiectului?
6. Graficul de lucru presupune mai puţine ore de muncă efectivă în
perioada sărbătorilor? De exemplu Crăciunul şi Paştele sunt perioade
cu productivitate mai scăzută.
O scăpare de la începutul procesului care va fi descoperită mai târziu

va avea un impact ramificat asupra proiectului. Dacă echipa are o
probabilitate de 90% de a respecta graficul de lucru în fiecare săptămână, în
timp şansele nerespectării planului cresc continuu.
5.5.4. Recomandări
Deoarece graficul de lucru este o imagine a întregului proiect,

singura cale de a-l folosi în mod eficient este de a înţelege tot ce trebuie să
se întâmple 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 cât se aşteaptă mai multe schimbări, cu
atât punctele de referinţă (engl. “milestones”) trebuie să fie mai
apropiate;
2. Trebuie planificate întâlniri sau discuţii privind adăugarea sau
eliminarea de funcţionalităţi;
3. Trebuie evaluată experienţa echipei în domeniul problemei curente;
4. Trebuie evaluată experienţa şi încrederea echipei privind lucrul
împreună. Chiar şi o echipă de programatori experimentaţi nu va fi
atât de eficientă dacă membrii echipei nu au lucrat împreună înainte;
5. Riscurile trebuie gestionate cât mai devreme. Cu cât este mai mare
riscul, cu atât mai mult timp va fi necesar pentru gestionarea sa.
Dacă riscurile sunt gestionate târziu, vor exista mai puţine grade de
libertate pentru a le răspunde adecvat. Acelaşi lucru se recomandă
pentru riscurile politice, organizaţionale sau legate de resurse.
83
5.6. Concluzii
Managementul timpului unui proiect presupune planificarea de bază

– crearea graficului de lucru. Structura de Descompunere a Activităţilor
furnizează activităţile individuale care trebuie planificate. Duratele
activităţilor sunt determinate prin procesul de estimare.
Metoda drumului critic eficientizează managementul de proiect prin
concentrarea mai mare a efortului asupra activităţilor fără perioade de
inactivitate. Metoda PERT realizează o aproximare statistică a datei de
terminare a proiectului prin ponderarea a trei estimări: una optimistă, una
probabilă şi una pesimistă. Simularea Monte Carlo este o metodă stohastică
utilizată pentru a evita problemele de estimare când activităţile de pe drumul
critic variază.
Au fost discutate trei scopuri ale planificării, au fost introduse o serie
de întrebări utile pentru a asigura estimări de calitate şi pentru a evita
omisiunile frecvente întâlnite în realizarea planificărilor şi au fost precizate
câteva recomandări pentru minimizarea riscurilor şi pentru maximizarea
beneficiilor planificării.
84
Capitolul 6
Managementul costului
6.1. Introducere
La construirea unei case, la decorarea unei băi sau a unei grădini,

dorim să cunoaştem costul precis al operaţiilor ce urmează a fi efectuate
înainte de începerea acestora. Un grădinar este capabil să facă o aproximare
a costurilor bazându-se, de exemplu, pe tipul pământului, mărimea dorită a
terasei sau a zonei cu iarbă, prezenţa sau absenţa unui iaz şi pe alte
informaţii similare. Apoi această estimare poate fi făcută mai precisă printr-
un dialog ulterior înainte de a se începe lucrările.
Estimarea costurilor unei aplicaţii software reprezintă un domeniu
mai puţin formalizat, care se bazează mai mult pe aproximări. Există totuşi o
serie de metode care permit estimarea costului total pentru un proiect
software pe baza unui număr limitat de generatori relevanţi de costuri.
În cele mai multe modele de estimare, este presupusă o relaţie simplă
între cost şi efort. Efortul poate fi măsurat de exemplu în luni-om (adică
numărul estimativ de luni necesar unui singur om să realizeze lucrarea), şi
fiecărei luni-om i se asociază o sumă fixă de bani, corespunzător salariului
angajaţilor. Costul total estimat se obţine înmulţind numărul estimat de luni-
om cu factorul constant considerat.
Noţiunea de cost total reprezintă de obicei costul efortului iniţial de
dezvoltare software, costul analizei cerinţelor, proiectării, implementării şi
testării, fără a fi luate în considerare costurile de întreţinere. Noţiunea 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
Cercetările în domeniul estimării costului sunt departe de a fi

cristalizate. Diferite modele folosesc diferite sisteme de măsură şi generatori
de costuri, încât este dificilă compararea lor. Să presupunem că un model
foloseşte o ecuaţie de forma: E  2,7  KLOC1,05 . Această ecuaţie arată o
relaţie între efortul necesar şi mărimea produsului (KLOC = Kilo-Lines Of
Code, kilo-linii de cod). Unitatea de măsură a efortului poate fi numărul de
luni-om necesare.
Apar aici mai multe întrebări. Ce este o linie de cod? Numărăm
codul maşină sau codul sursă într-un limbaj de nivel înalt? Numărăm de
asemenea şi comentariile, liniile libere care măresc vizibilitatea sau nu?
Luăm în considerare şi zilele libere, vacanţele, concediile medicale în
noţiunea de luni-om sau se referă numai la o măsurare netă? Diferite
interpretări ale acestor întrebări pot conduce la rezultate complet diferite.
Uneori nici nu este cunoscut ce definiţii au fost folosite în aplicarea
modelului.
În mod ideal, mărimea ar trebui să se refere doar la codul propriu-
zis, fără linii albe şi comentarii, însă pentru proiecte de dimensiuni mari,
este mai simplu să se numere direct toate liniile.
Pentru a determina ecuaţiile unui model algoritmic de estimare a
costului, putem urma diferite abordări. În primul rând ne putem baza ecuaţia
pe rezultatul experimentelor. Într-un asemenea experiment, în general
variem un parametru, în timp ce ceilalţi parametri rămân constanţi. În acest
fel încercăm să determinăm influenţa pe care o are parametrul care variază.
Un exemplu tipic este cel ce testează dacă comentariile ajută la înţelegerea
unui program. Vom pune un număr de întrebări despre acelaşi program unor
programatori împărţiţi în două grupuri. Primul grup va primi programul fără
comentarii, iar al doilea grup va primi textul aceluiaşi program, dar
comentat. Folosind rezultatele celor două grupuri, putem testa ipoteza
realistă că o înţelegere mai bună şi mai rapidă a programului are efecte
pozitive asupra întreţinerii 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 organizaţie poate strânge date despre un număr 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 apărut erori, atât în timpul testării cât şi după instalare,
complexitatea, robusteţea şi alţi factori importanţi ai proiectului, mărimea
diferitelor entităţi implicate şi o analiză statistică a acestor date. Un exemplu
pentru o asemenea relaţie este cea dată mai sus, ce exprimă o legătură între
E şi KLOC. Aplicabilitatea şi corectitudinea acestor ecuaţii este, în mod
evident, dependentă de corectitudinea datelor pe care se bazează.
Rezultatele obţinute în acest fel reprezintă o medie, o aproximare
bazată pe datele disponibile, de aceea rezultatele obţinute trebuie aplicate cu
atenţie. De exemplu, programul ce urmează a fi dezvoltat în cadrul unui nou
proiect nu se poate compara cu produse anterioare datorită inovaţiilor
implicate. Estimarea costurilor pentru un proiect legat de o navetă spaţială
nu poate fi făcută printr-o simplă extrapolare a proiectelor anterioare.
Trebuie reţinut că aplicarea oarbă a unor formule din modelele
existente nu va rezolva problema estimării costului. Fiecare model necesită
o adaptare la mediul în care va fi folosit. Aceasta conduce la necesitatea
colectării continue a datelor din propriul proiect şi aplicarea unor metode
statistice pentru a calibra parametrii modelului.
Neconcordanţele dintre diferitele modele mai pot apărea deoarece:
 Majoritatea modelelor oferă o relaţie între numărul lunilor-om

necesare şi mărimea produsului în linii de cod. Pot exista însă mai
multe interpretări diferite pentru aceste noţiuni;
 Efortul nu înseamnă întotdeauna acelaşi lucru. Uneori se consideră
activităţile de dezvoltare pornind de la conceperea produsului, după
ce au fost fixate cerinţele. Alteori se includ şi eforturile de
întreţinere.
Cu toate acestea, modelele de estimare a costului au multe

caracteristici comune. Acestea reflectă importanţa factorilor care intervin
asupra costului de dezvoltare şi efortului. Creşterea înţelegerii costurilor
produselor software ne permite să identificăm strategii de creştere a
productivităţii, cele mai importante fiind:
87
 Scrierea de mai puţin cod: Mărimea sistemului este una din cauzele
principale ale efortului şi costului. Prin metode care încearcă să
reducă mărimea, cum ar fi utilizarea de limbaje de nivel înalt,
reutilizarea componentelor sau refactorizarea, se pot obţine reduceri
semnificative;
 Stimularea oamenilor să lucreze la capacitatea maximă: Capacitatea
de a lucra atât individual cât şi în echipă are un mare impact asupra
productivităţii. Angajarea celor mai buni oameni este de obicei o
afacere profitabilă. O mai bună stimulare, condiţii mai bune de lucru,
cursurile de perfecţionare asigură oportunităţi de creştere a
productivităţii;
 Evitarea rescrierii componentelor dezvoltate anterior: Studiile au
arătat 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 activităţile elementare de programare. Primele experimente
au fost realizate de Halstead (1977). La baza modelului său stă faptul că
numărarea liniilor de cod poate constitui o problemă, chiar dacă avem o
definiţie exactă a termenului „linie de cod”. Unele linii sunt mult mai
complicate decât altele. Conform teoriei lui Halstead, este mai bine să se
pornească de la un număr de unităţi sintactice, după cum sunt recunoscute
de compilator. Halstead face distincţia între operatori şi operanzi. Operatorii
denotă o operaţie; exemple sunt operatorii standard (+, –, * etc.), dar şi
semnul de punctuaţie punct şi virgulă (;) care arată structura unei
instrucţiuni şi construcţii cum ar fi if-then-else şi while-do. Operanzii
înseamnă date: variabile şi constante. Calcularea numărului de operatori şi
operanzi dintr-un program va oferi o măsură mai bună a mărimii decât
simpla calculare a numărului de linii.
În modelul Halstead, cele patru entităţi de bază pentru un program
sunt:
88
 n1 = numărul de operatori diferiţi;

 n2 = numărul de operanzi diferiţi;
 N1 = numărul total de apariţii ale operatorilor;
 N2 = numărul total de apariţii ale operanzilor;
Relaţiile modelului Halstead sunt următoarele:
 Vocabularul: n = n1 + n2
 Lungimea implementării: N = N1 + N2
 Ecuaţia lungimii: N' = n1log2n1 + n2log2n2
 Volumul programului: V = N log2n
n N
 Dificultatea: D  1  2
2 n2
 Efortul: E  D V
Astfel se obţine o rafinare a măsurii numărului de linii simple de

cod, LOC. Atât LOC cât şi N oferă o bună corelaţie cu efortul de
programare. De aceea este important să se găsească modalităţi de estimare a
acestora în primele etape ale implementării. 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, numărul maxim de
operatori care poate fi utilizat în orice program este fix: toţi sunt prezentaţi
în sintaxa limbajului. Majoritatea programelor vor folosi un mare procent
din acestea, cel puţin o dată. O ipoteză consideră că n2 este determinat în
principal de numărul de variabile (VARS) care apar în program. Bazându-se
pe aceste presupuneri, a fost enunţată următoarea relaţie empirică:
LOC  102  5,31VARS
Astfel, fiecare program va conţine 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 obţine aproximări destul de
corecte ale mărimii şi efortului necesar. Valoarea estimată a lui VARS poate
89
fi obţinută relativ devreme dacă este folosită o metodă de proiectare top-

down în combinaţie cu un limbaj de nivel înalt.
Generalizarea acestor rezultate la programe mai mari nu este
indicată. În programele mai complexe, factori precum interfaţa dintre
componente şi comunicarea necesară între persoanele implicate joacă un rol
ce nu poate fi neglijat.
Cunoscând mărimea estimată a unui proiect, suntem interesaţi în
continuare să evaluăm 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ă încercăm
să micşorăm prea mult acest timp nominal de dezvoltare, intrăm într-o „zonă
imposibilă”, iar probabilitatea unui eşec creşte.
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
următoare:
 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 făcută o ofertă de 100.000 de euro de către

concurenţă, noi vom face o ofertă de 90.000 de euro (metoda
preţului de câştig);
 Dorim să ne promovăm produsul la un anumit târg de tehnică de
calcul şi din acest motiv programul trebuie scris şi testat în
următoarele 9 luni, deşi realizăm 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
programăm pentru 10 luni.
Aceste estimări pot avea efecte negative, după cum s-a demonstrat
frecvent în istoria ingineriei programării. Estimările vor depinde mai mult
de argumentele politice ale părților interesate decât 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 său. Dacă o
echipă lucrează în mod repetat la proiecte asemănătoare, timpul de lucru
necesar scade, datorită experienţei acumulate. În 1968, unei echipe de
programatori i s-a cerut să dezvolte un compilator FORTRAN pentru trei
maşini 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 neobişnuite ale
proiectului, pot fi astfel luaţi în considerare. În acest caz, calitatea estimării
nu poate depăşi calitatea expertului.
Pentru o estimare mai precisă se pot solicita mai mulţi experţi.
Totuşi, dacă un grup de persoane trebuie să găsească împreună o soluţie, se
observă că unii membri ai grupului au un impact mai mare asupra
rezultatului decât ceilalţi. 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ă estimările obţinute astfel şi le redistribuie celorlalţi
experţi. În acest proces nu sunt asociate numele experţilor cu estimările lor.
Fiecare expert predă apoi o nouă estimare bazată pe informaţiile primite de
la moderator. Procesul continuă până când se ajunge la un consens.
O altă metodă pentru obţinerea unei estimări mai bune se bazează pe
un expert care să realizeze mai multe estimări: o estimare optimistă a, o
estimare realistă m şi o estimare pesimistă b. Efortul aşteptat va fi:
a  4m  b
E
6
Această estimare este mai bună decât 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
următoarea formă:
n
E  a0   ai xi
i 1
Coeficienţii ai sunt constante, iar xi reprezintă factorii care au impact

asupra efortului necesar. Un număr mare de factori poate influenţa
productivitatea şi implicit efortul. Analizând cu atenţie datele proiectelor
precedente şi diferite combinaţii de factori, se poate încerca obţinerea unui
model cu un număr 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,61x1129,55x12  0,54 x13  25,20 x14
În această ecuaţie, E reprezintă numărul estimat de luni-om necesare.

Semnificaţia factorilor xi şi domeniile lor de definiţie sunt prezentate în
tabelul următor:
Factor Descriere Valori posibile

x1 Instabilitatea specificaţiilor cerinţelor 0-2
x2 Instabilitatea proiectării 0-3
x3 Procentajul de instrucţiuni matematice 0-100
x4 Procentajul de instrucţiuni I/O 0-100
x5 Numărul subprogramelor număr
x6 Utilizarea unui limbaj de nivel înalt 0 (da) / 1 (nu)
x7 Aplicaţie comercială 0 (da) / 1 (nu)
x8 Program de sine stătător 0 (da) / 1 (nu)
x9 Primul program pe această maşină 1 (da) / 0 (nu)
x10 Dezvoltare concurentă de hardware 1 (da) / 0 (nu)
x11 Utilizarea dispozitivelor random-access 1 (da) / 0 (nu)
x12 Maşina gazdă diferită de maşina ţintă 1 (da) / 0 (nu)
x13 Număr de erori număr
x14 Dezvoltare pentru o organizaţie militară 0 (da) / 1 (nu)
Putem face mai multe observaţii asupra acestui model. De exemplu,

la dezvoltarea programelor pentru aplicaţiile de apărare, în care programele
sunt încorporate în maşini diferite de maşina 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 creşterea efortului
atunci când se foloseşte limbajul de asamblare în locul unui limbaj de nivel
înalt (x6).
În general modelele liniare nu funcţionează foarte bine. Deşi există
un număr mare de factori care influenţează productivitatea, este puţin
probabil ca ei să intervină în mod independent şi liniar. Trebuie atrasă
atenţia 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 luni-

om. Semnificaţia formulei este următoarea: 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, rămânând o probabilitate diferită de zero ca acesta să fie în afara
intervalului. Aplicabilitatea acestor estimări este puternic influenţată de
mărimea intervalului şi de probabilitatea ca valoarea reală a costului să
aparţină într-adevăr 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 obţine un
cost estimativ iar costul final este suma costurilor modulelor, cu o corecţie
aplicată datorită integrării 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 număr limitat de tipuri diferite de module şi un număr de niveluri
de complexitate. Tabelul următor ilustrează o matrice ipotetică de costuri.
Elementele matricei reflectă costul pentru fiecare linie de cod.
Complexitate
Tipul modulului Mică  Mare
1 2 3 4 5
1. Management de date 11 13 15 18 22
2. Management de memorie 25 26 27 29 32
3. Algoritm 6 8 14 27 51
4. Interfaţă utilizator 13 16 19 23 29
5. Control 20 25 30 35 40
94
Fiind date o matrice de costuri C, un modul de tip i, complexitate j şi

mărime Sk, rezultă un cost al modulului M k  Sk  Cij .
Acest tip de model are la rândul său unele probleme. Utilizatorul
trebuie să estimeze subiectiv clasa de complexitate din care face parte
fiecare modul, ceea ce determină un grad mare de nesiguranţă. Alţi factori
care au un impact asupra productivităţii, cum ar fi experienţa în programare
şi caracteristicile hardware, nu sunt luaţi în considerare. Extinderea matricei
pentru a include şi aceşti factori ar creşte gradul de subiectivitate al metodei.
6.4. Modele algoritmice moderne
În secţiunile anterioare am remarcat faptul că efortul de programare

este corelat cu mărimea programului. Există şi modele neliniare care
exprimă această legătură. O formă generală este:
E  (a  b  KLOCc )  f ( x1 ,..., xn ) ,
unde KLOC reprezintă mărimea 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
funcţie care depinde de valorile factorilor x1 ,..., xn .
În general, formula de bază este:
E  a  b  KLOCc
Aceasta este obţinută printr-o analiză de regresie a datelor

proiectelor disponibile. Primul generator de cost este mărimea programului,
măsurată în linii de cod. Acest cost nominal estimat este apoi adaptat pentru
un număr de factori care influenţează productivitatea (generatorii de cost
secundari). De exemplu, dacă unul din factorii folosiţi reprezintă
„experienţa echipei de programatori” aceasta poate cauza o corecţie a
costului nominal estimat cu 1,50, 1,20, 1,00, 0,80, 0,60 pentru un nivel de
expertiză foarte scăzut, scăzut, mediu, înalt şi respectiv foarte înalt.
95
Tabelul următor conţine formulele de bază pentru relaţia dintre

mărimea programului şi efort. Din motivele enunţate anterior este dificil să
comparăm 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
Când c < 1, se remarcă apariţia unui fenomen foarte bine cunoscut

din teoria economică. Pentru producţia de masă, se presupune că este mai
ieftin să se producă mari cantităţi din acelaşi produs. Costurile fixe vor fi
împărţite astfel unui număr mai mare de unităţi, ceea ce conduce la scăderea
costului pe unitate. În cazul programelor, liniile de cod sunt produsul, deci
presupunem că producând 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 număr mai mare de linii de cod.
În cazul opus, când c > 1, observăm că după un anumit punct,
producerea de unităţi suplimentare implică nişte costuri suplimentare.
Programele foarte mari sunt mult mai scumpe, deoarece creşte necesitatea
de comunicare şi de control managerial, iar problemele şi interfeţele sunt
mai complexe. Deci fiecare linie de cod suplimentară necesită mai mult
efort.
Al doilea tip de relaţii (c > 1) pare mai plauzibil. Pentru proiecte
foarte mari, efortul creşte mai mult decât liniar cu mărimea. Alegerea unui
anumit model depinde în principal de gradul de complexitate a interfaţării
modulelor proiectului.
Este evident că valoarea exponentului c influenţează foarte mult
valoarea calculată E, în special pentru valori mari ale KLOC. Tabelul
următor prezintă valorile lui E, calculate prin metodele prezentate anterior şi
pentru câteva 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, acelaşi model
96
generează estimări ale costului cu un ordin de mărime mai mari decât prin
aplicarea metodei Walston-Felix.
KLOC Halstead Boehm Walston-Felix

1 0,7 2,4 5,2
10 22,1 26,9 42,3
50 247,5 145,9 182,8
100 700 302,1 343,6
1000 22135,9 3390,1 2792,6
Aceste observaţii nu trebuie să ne conducă la concluzia că aceste

metode sunt inutile. Există diferenţe mari între caracteristicile mulţimilor 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 obţinerea unei estimări iniţiale a
mărimii programului. Cum am putea să estimăm numărul de pagini ale unui
roman care nu a fost scris încă? Chiar dacă ştim numărul de personaje, de
locaţii şi intervalul în care se va desfăşura povestea, este dificilă estimarea
realistă a mărimii încă de la început. Cu cât înaintăm în realizarea
proiectului, cu atât va fi mai exactă estimarea mărimii. Dacă proiectarea se
apropie de final, ne putem forma o impresie rezonabilă asupra mărimii
programului rezultat. Dar numai când sistemul va fi predat vom cunoaşte
valoarea exactă.
6.4.1. Modelul Walston-Felix
Ecuaţia 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 mărime, iar programele au
fost scrise în mai multe limbaje de programare. Totuşi nu reprezintă o
97
surpriză faptul că dacă aplicăm acest model chiar unei submulţimi a celor 60
de proiecte, nu vom avea rezultate satisfăcătoare.
Încercând să explice aceste rezultate dintr-o plajă mare de valori,
autorii au identificat 29 de variabile care influenţează în mod sigur
productivitatea. Pentru fiecare din aceste variabile au fost considerate trei
niveluri: mare, mediu şi mic. Pentru un număr de 51 de proiecte, Walston şi
Felix au determinat nivelul fiecărei variabile din cele 29, împreună cu
productivitatea obţinută, exprimată ca număr de linii de cod pe lună-om.
Aceste rezultate sunt prezentate în tabelul următor pentru câteva 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 scăzută. Pentru o interfaţă de complexitate înaltă sau medie,
productivitatea este de 295 şi respectiv 124 de linii de cod pe lună. Ultima
coloană reprezintă variaţia productivităţii, PC (engl. “productivity change”),
diferenţa dintre valorile maxime şi minime.
Productivitatea medie pentru

Variabila PC
valoarea variabilei
< normală normală > normală
Complexitatea interfeţei utilizator 376
500 295 124
Calificarea şi experienţa mică medie mare
278
personalului 132 257 410
Experienţă anterioară cu aplicaţii minimă medie vastă
264
similare 146 221 410
Procentajul de programatori < 25% 25 – 50% > 50%
238
participanţi în faza de proiectare 153 242 391
Raportul dintre mărimea medie a
< 0,5 0,5 – 0,9 > 0,9
echipei şi durata proiectului 134
305 310 171
(persoane/lună)
Walston şi Felix consideră că indexul productivităţii I poare fi

determinat pentru noile proiecte după următoarea relaţie:
29
I  Wi X i ,
i 1
98
unde ponderile Wi sunt definite astfel:
Wi  0,5  log10 ( PCi ) .
În relaţia de mai sus, PCi reprezintă variaţia productivităţii

factorului i. Pentru primul factor din tabelul de mai sus, complexitatea
interfeţei cu utilizatorul, rezultă următoarele: PC1  376 , deci W1  1,29 .
Variabilele X i pot lua valorile –1, 0 şi 1, unde factorul corespunzător este
de nivel scăzut, mediu sau înalt. Indexul productivităţii obţinut poate fi
tradus într-o productivitate aşteptată: linii de cod scrise pe lună-om.
Modelul pleacă de la ecuaţia de bază E  5,2  KLOC0,91
şi foloseşte I pentru a ajusta estimările.
Numărul factorilor luaţi în considerare în acest model este destul de
ridicat: 29 de factori din 51 de proiecte. De asemenea, nu este clar cum
aceşti factori se influenţează unul pe celălalt. Un alt dezavantaj ar fi că
numărul de alternative pentru fiecare factor este de numai 3 şi nu oferă
destule opţiuni pentru situaţiile 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ă
legătura dintre efort şi mărimea 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 organizaţia lor. Astfel, ei
99
pot să lucreze de la început, nefiind necesare investiţii iniţiale.

Proiectele de acest tip sunt de multe ori programe relativ mici;
 Integrate: Proiectele de acest tip implică sisteme unde mediul
impune constrângeri severe. Produsul va fi integrat într-un mediu
foarte strict. Exemple de asemenea proiecte sunt programele de
control al traficului aerian sau aplicaţiile militare;
 Semidetaşate: 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

următoarele valori:
Clasa de proiect b c
organică 2,4 1,05
semidetaşată 3,0 1,12
integrată 3,6 1,20
Tabelul următor prezintă estimări ale efortului pentru fiecare din cele
trei moduri, pentru diferite valori ale KLOC (deşi un proiect organic de un
milion de linii de cod nu este realist). Se observă influenţa foarte mare a
constantei c asupra estimărilor obţinute. Estimările efortului sunt exprimate
tot în luni-om.
KLOC organic semidetaşat integrat

1 2,4 3,0 3,6
10 26,9 39,6 57,1
50 145,9 239,4 392,9
100 521,3 904,2
1000 6872 14333
100
6.4.3. Analiza punctelor funcţionale
Analiza punctelor funcţionale (Albrecht, 1983) este o metodă de

estimare a costurilor care încearcă să evite problemele determinate de
estimarea dimensiunii codului. APF se bazează pe numărarea diferitelor
structuri de date utilizate. Se presupune că acest număr este un bun indicator
pentru dimensiunea proiectului. Metoda este potrivită mai ales pentru
aplicaţiile comerciale în care structura datelor are o foarte mare importanţă.
APF este mai puţin indicată pentru proiectele în care algoritmii joacă rolul
dominant, de exemplu compilatoarele sau aplicaţiile de timp real.
Unul din scopurile principale ale APF este evaluarea sistemului din
punctul de vedere al utilizatorilor. De aceea, analiza se bazează pe
modalităţile în care diverşi utilizatori interacţionează cu aplicaţiile. Astfel,
sistemul îndeplineşte cinci funcţii fundamentale:
 funcţii referitoare la date:

o fişiere interne logice;
o fişiere externe de interfaţă;
 funcţii tranzacţionale:
o intrări externe;
o ieşiri externe;
o interogări externe.
Fişierele interne logice (engl. “Internal Logical Files”, ILF): Permit

utilizatorilor să folosească datele pe care trebuie să le întreţină. De exemplu,
un pilot poate introduce datele de navigare la un terminal din carlingă
înainte de plecare. Datele sunt stocate într-un fişier şi pot fi modificate în
timpul misiunii. Pilotul este deci responsabil pentru întreţinerea acestor date.
Fişierele externe de interfaţă (engl. “External Interface Files”, EIF):
În acest caz, utilizatorul nu este responsabil pentru întreţinerea datelor;
acestea sunt localizate în alt sistem care le întreţine. Utilizatorul sistemului
analizat solicită datele doar pentru informare. De exemplu, un pilot se poate
informa asupra poziţiei cu ajutorul sateliţilor GPS sau al sistemelor de la sol.
El nu are responsabilitatea actualizării acestor date, însă le poate accesa în
timpul zborului.
101
Intrările externe (engl. “External Input”, EI): Permit utilizatorului să

întreţină fişierele interne logice prin operaţii de adăugare, modificare şi
ştergere.
Ieşirile externe (engl. “External Output”, EO): Permit utilizatorului
să producă date de ieşire. De exemplu, pilotul poate să afişeze separat viteza
la sol şi viteza reală în aer, informaţii derivate din datele interne (pe care le
poate întreţine) şi cele externe (pe care le poate accesa).
Interogările externe (engl. “External Inquiries”, EQ): Pentru ca
utilizatorul să poată selecta şi afişa datele din fişiere, el trebuie să introducă
informaţii de selecţie pentru a găsi datele în conformitate cu anumite criterii.
Interogările pot accesa date atât din fişierele interne logice cât şi din fişierele
externe de interfaţă, dar nu produc date noi. Datele din fişiere nu sunt
modificate, ci doar căutate şi furnizate. De exemplu, dacă pilotul afişează
date cu privire la relieful solului, date stocate anterior, rezultatul este
regăsirea directă a informaţiilor.
Prin încercări repetate, s-au stabilit ponderi pentru fiecare din aceste
entităţi. Numărul de puncte funcţionale neajustate este:
PFN  10  ILF  7  EIF  4  EI  5  EO  4  EQ
În funcţie de complexitatea tipurilor de date, se disting o serie de

valori pentru aceste puncte funcţionale, prezentate în tabelul următor.
Nivel de complexitate
Tip
Simplu Mediu Complex
ILF 7 10 15
EIF 5 7 10
EI 3 4 6
EO 4 5 7
EQ 3 4 6
Pentru ajustarea suplimentară a estimărilor, se iau în calcul şi alte 14

caracteristici care influenţează dezvoltarea aplicaţiilor: comunicaţiile de
date, funcţiile distribuite, performanţa, folosirea masivă a configuraţiilor,
rata tranzacţiilor, intrările de date online, eficienţa utilizatorilor finali,
102
actualizările online, prelucrările complexe, refolosirea, uşurinţa la instalare,

uşurinţa la folosire, locaţiile multiple, facilitarea modificărilor.
Influenţa fiecărei caracteristici este evaluată pe o scară de la 0 (nu
influenţează) la 5 (influenţă puternică). Gradul de influenţare (GI) este
suma acestor puncte pentru toate caracteristicile. Se calculează apoi factorul
de complexitate tehnică:
FCT  0,65  0,01 GI .
Punctele funcţionale ajustate (PF) se obţin astfel:
PF  PFN  FCT .
Avantajul principal al analizei punctelor funcţionale este faptul că

măsura productivităţii este un rezultat natural, deoarece punctele funcţionale
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ă estimările privind durata proiectului ca întreg.
6.5. Distribuirea forţei de muncă în timp
Norden a studiat distribuţia forţei de muncă în timp într-un număr de

proiecte de dezvoltare software din anii ’60. A descoperit că această
distribuţie avea deseori o formă caracteristică, bine aproximată de distribuţia
Rayleigh. Bazându-se pe această descoperire, Putnam a dezvoltat un model
de estimare a costului în care forţa 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 iniţială a curbei, iar
K reprezintă forţa de muncă totală necesară, incluzând faza de întreţinere. K
103
este egal cu aria zonei delimitate de curba Rayleigh, reprezentată în figura

următoare.
Integrarea ecuaţiei 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
iniţial de dezvoltare. Pentru acesta obţinem:
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 întreţinere. Specificarea cerinţelor nu este inclusă
în model şi deci estimările nu se pot aplica decât începând cu proiectarea şi
implementarea.
Putnam a folosit observaţii empirice legate de nivelurile de
productivitate pentru a deriva ecuaţia 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 până 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 programării;
 nivelul limbajelor de programare folosite;
 capacitatea şi experienţa echipei de dezvoltare;
 complexitatea aplicaţiei.
Puterea supraunitară a timpului are implicaţii puternice asupra

alocării resurselor în proiecte mari. Prelungiri relativ mici ale datei de
livrare pot determina reducerea substanţială a efortului.
Pentru estimarea efortului, Putnam a introdus ecuaţia acumulării
forţei de muncă (engl. “manpower-buildup”):
A  E / t3 ,
unde A este accelerarea forţei de muncă iar E şi t au semnificaţiile de mai

sus.
Accelerarea forţei de muncă este 12,3 pentru proiecte software noi,
cu multe interfeţe şi interacţiuni cu alte sisteme, 15 pentru sisteme de sine
stătătoare şi 27 pentru reimplementări ale sistemelor existente.
Pe baza celor două ecuaţii, eliminăm timpul şi determinăm efortul:
E  ( D / k )9 / 7  A4 / 7 .
Acest rezultat este interesant deoarece arată că efortul este

proporţional 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 număr mai
mare de persoane necesare pentru proiect. Referindu-ne la modelul curbei
Rayleigh, scurtarea timpului de dezvoltare conduce la mărirea valorii a,
105
factorul de accelerare care determină panta iniţială a curbei. Vârful curbei

Rayleigh se deplasează spre stânga-sus. Astfel obţinem o creştere a puterii
necesare la începutul proiectului şi o forţă de muncă maximă mai mare.
Există şi dezavantaje ale acestei deplasări. Mai multe studii au arătat
că productivitatea individuală scade odată cu creşterea echipei. Conform lui
Brooks, există două cauze ale acestui fenomen:
 Dacă o echipă se măreşte, creşte timpul acordat comunicării cu

ceilalţi membri ai echipei (pentru consultare, sincronizarea sarcinilor
etc.);
 Dacă este adăugată forţă de muncă suplimentară unei echipe în
timpul dezvoltării unui proiect, mai întâi scade productivitatea. Noii
membri ai echipei nu sunt productivi de la început, când necesită
ajutor, deci timp, de la ceilalţi membri ai echipei în timpul
procesului de învăţare. Luate împreună, acestea conduc la scăderea
productivităţii totale.
Combinând aceste două informaţii, ajungem la fenomenul cunoscut

sub denumirea de legea lui Brooks: adăugarea de personal la un proiect
întârziat îl va întârzia şi mai mult.
Analizând o mare bază de date de proiecte, Conte a descoperit
următoarea relaţie între productivitatea medie L (măsurată în linii de cod pe
lună-om) şi mărimea medie a unei echipe P:
777
L .
P
Formula atestă faptul că productivitatea individuală scade cu

mărimea echipei. Numărul de legături de comunicare între persoanele
implicate într-un proiect este determinat de mărimea şi structura echipei.
Dacă într-o echipă de mărime P fiecare membru trebuie să-şi coordoneze
activităţile sale cu toţi ceilalţi din echipă, numărul legăturilor de
P( P  1)
comunicaţie va fi: . Dacă fiecare membru trebuie să comunice
2
numai cu un singur alt membru, acest număr va fi: P  1 . Mai puţină
106
comunicare decât aceasta nu este rezonabilă, deoarece ne-am confrunta cu

echipe independente.
Numărul de legături de comunicaţie variază de la aproximativ P la
aproximativ P 2 / 2 . Într-o organizare ierarhică, aceasta conduce la P căi de
comunicaţie, cu   (1, 2) .
Pentru un membru al echipei, numărul de legături de comunicaţie
variază de la 1 la P  1 . Dacă productivitatea individuală maximă este L şi
fiecare legătură de comunicaţie conduce la o pierdere a productivităţii l,
atunci productivitatea medie va fi:
L  L  l ( P  1) ,
unde   (0, 1] este o măsură a numărului de legături de comunicaţie.

Presupunem că există cel puţin o persoană care să comunice cu mai
mult de o persoană, deci γ > 0. Pentru o echipă de mărime P, aceasta
conduce la o productivitate totală:
 
Ltot  P  L  P  L  l  ( P  1) .
Pentru o mulţime dată de valori pentru L, l şi γ, pentru valori

crescătoare ale lui P, această funcţie creşte de la 0 la o valoare maximă şi
apoi scade din nou. Deci există o mărime 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
scăderea de productivitate este de 10% pe canal de comunicaţie (l = 50). Cu
interacţiune completă între membrii echipei (γ = 1), rezultă o echipă optimă
de 5,5 persoane:
107
Mărimea 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 forţei de muncă
şi a timpului efectiv de dezvoltare. În final, s-a prezentat o modalitate de
estimare a distribuţiei forţei de muncă în timp pentru găsirea numărului
optim de persoane implicate într-un proiect.
108
Capitolul 7
Managementul calităţii
7.1. Introducere
Managementul calităţii include procesele necesare pentru a asigura

faptul că proiectul va satisface cerinţele pentru care este realizat.
Calitatea reprezintă „totalitatea caracteristicilor unei entităţi care îi
permit să satisfacă cerinţele explicite sau implicite”. Un aspect critic al
managementului calităţii este necesitatea de a transforma cerinţele implicite
în cerinţe explicite cu ajutorul managementului domeniului proiectului.
Tehnicile moderne de management al calităţii recunosc importanţa
următoarelor aspecte:
 Satisfacţia clientului: înţelegerea, gestionarea şi influenţarea

cerinţelor astfel încât aşteptările clientului să fie satisfăcute sau
depăşite. Proiectul trebuie să fie conform cu specificaţiile (trebuie să
producă ceea ce spune că produce) şi potrivit pentru utilizare (trebuie
să satisfacă nevoi reale);
 Favorizarea prevenirii asupra corectării: costul evitării erorilor este
întotdeauna mult mai mic decât costul corectării lor;
 Responsabilitatea managerială: pentru asigurarea succesului
proiectului este necesară participarea tuturor membrilor echipei, însă
rămâne responsabilitatea managementului să asigure resursele
necesare pentru reuşită;
 Procesele organizate pe faze: iteraţii ale ciclului Deming:
planificare-realizare-verificare-acţiune (engl. “Plan-Do-Check-Act”,
PDCA)
Natura temporară a proiectelor înseamnă că investiţia în

îmbunătăţirea calităţii, în special prevenirea şi evaluarea defectelor, trebuie

susţinută de organizaţia executantă, deoarece un anumit proiect poate dura

prea puţin pentru ca aceste investiţii să fie recuperate.
7.2. Procesele principale ale managementului calităţii
Există 3 procese principale de management al calităţii:
 Planificarea calităţii: identificarea standardelor de calitate relevante

pentru proiect şi determinarea modului în care vor fi satisfăcute;
 Asigurarea calităţii: evaluarea performanţei globale a proiectului în
mod regulat pentru a stabili încrederea că proiectul va satisface
standardele de calitate relevante;
 Controlul calităţii: monitorizarea rezultatelor proiectului pentru a
determina dacă acestea sunt în conformitate cu standardele şi pentru
a identifica modalităţile de eliminare a cauzelor performanţelor
nesatisfăcătoare.
Unul din scopurile managementului calităţii este controlul variaţiei –

foarte important la produse de serie (de exemplu DVD-uri). În cazul
produselor software, acesta se referă de exemplu la minimizarea diferenţei
dintre resursele planificate şi cele reale, la teste de acoperire a unui procent
cunoscut din produs, minimizarea variaţiei numărului 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 Organizaţia Internaţională pentru
Standardizare şi administrată de organe de acreditare şi certificare.
Ele specifică cerinţele sistemelor de calitate care pot fi utilizate când
un contract dintre 2 părţi necesită demonstrarea capacităţii furnizorului de a
proiecta şi livra un produs. Cele 2 părţi pot fi un furnizor şi un client extern
110
sau ambele pot fi interne, de exemplu departamentele de marketing şi de

programare din cadrul aceleiaşi companii.
În prezent, în familia ISO 9000 sunt incluse următoarele standarde:
 ISO 9000 („Sisteme de management al calităţii – Principii şi

vocabular”) – explică ce sunt sistemele de management al calităţii.
Este un document de îndrumare şi nu este utilizat în scopuri de
certificare. Este o referinţă importantă pentru a înţelege termenii şi
vocabularul legat de sistemele de management al calităţii;
 ISO 9001 („Sisteme de management al calităţii – Cerinţe”) este
destinat utilizării în orice organizaţie care proiectează, dezvoltă,
fabrică, instalează sau asigură service pentru orice produs sau
furnizează orice formă de servicii. Conţine un număr de cerinţe pe
care trebuie să le îndeplinească o organizaţie dacă doreşte să obţină
satisfacţia clientului prin produse şi servicii consecvente care
îndeplinesc aşteptările. Acest standard este singura implementare
pentru care pot acorda certificări auditori terţi. Păstrarea certificării
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 calităţii – Principii pentru
îmbunătăţirea performanţelor”) tratează perfecţionarea continuă,
dând recomandări asupra a ceea ce trebuie făcut 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

următoarele:
 O organizaţie trebuie să obţină şi să susţină calitatea produselor sau

serviciilor pentru a satisface în mod continuu nevoile implicite şi
explicite ale clienţilor;
 O organizaţie trebuie să asigure încrederea propriului management
privind obţinerea şi susţinerea calităţii intenţionate;
 O organizaţie trebuie să asigure încrederea cumpărătorului privind
calitatea deja existentă sau în curs de obţinere a produselor livrate
111
sau a serviciilor prestate. Când sunt cerute prin contract, această

asigurare a încrederii poate presupune cerinţe de demonstrare
acceptate de comun acord.
Deşi cu aplicabilitate generală, standardul ISO 9001 este adecvat

dezvoltării şi întreţinerii produselor software. ISO 90003 conţine „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
organizaţionale.
Secţiunile standardului ISO 90003 conţin:
 cerinţe: ce trebuie îndeplinit pentru a obţine certificarea;

 recomandări: ce ar fi bine de făcut pentru a ajuta la îndeplinirea
cerinţelor.
Există 20 de prevederi în ISO 9001, interpretate de ISO 90003

pentru dezvoltarea software:
1. Responsabilitatea managerială. Politica de calitate trebuie definită,

documentată, înţeleasă, implementată şi întreţinută. Trebuie definite
responsabilităţile şi autoritatea tuturor membrilor echipei pentru
specificarea, atingerea şi monitorizarea calităţii. Trebuie definite,
instruite şi finanţate 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, având proceduri şi instrucţiuni, şi care este integrat în
întreg ciclul de dezvoltare;
3. Analiza contractelor. Contractele trebuie analizate pentru a vedea
dacă cerinţele sunt definite adecvat, concordă cu oferta şi pot fi
implementate;
4. Controlul proiectării. Trebuie stabilite proceduri de verificare a
proiectării pentru a asigura că cerinţele sunt îndeplinite şi că
metodele de proiectare sunt utilizate corect;
112
5. Controlul documentelor. Distribuirea şi modificarea documentelor

trebuie controlate;
6. Achiziţiile: Produsele achiziţionate trebuie să fie conforme cu
cerinţele specificate, incluzând evaluarea subcontractorilor potenţiali
şi verificarea produselor achiziţionate;
7. Produsele furnizate de cumpărător. Toate materialele furnizate de
cumpărător trebuie verificate şi întreţinute. Intră aici produsele
software existente sau produsele COTS (“commercial-off-the-
shelf”);
8. Identificarea şi trasabilitatea produselor. Trasabilitatea (engl.
“traceability”) este capacitatea de a regăsi istoricul, realizarea sau
localizarea obiectului considerat. În cazul unui produs, poate fi vorba
de originea materialelor şi a părţilor componente, istoricul realizării,
distribuţia şi amplasarea produsului după livrare. Produsul software
trebuie să poată fi identificat şi urmărit pe parcursul tuturor fazelor
de dezvoltare, livrare şi instalare;
9. Controlul proceselor. Procesele de dezvoltare trebuie definite şi
planificate în condiţii controlate şi în conformitate cu instrucţiuni
documentate. Procesele speciale care ulterior nu pot fi complet
verificate sunt permanent monitorizate;
Figura 7.1. Nivelul optim al inspecţiilor
113
10. Inspecţiile şi testarea. Se realizează inspecţii şi testări înainte de

lansarea produsului final. Trebuie găsit un echilibru între costul
reparării defectelor şi costul inspecţiilor pentru depistarea acestora
(figura 7.1). Rapoartele inspecţiilor şi testelor trebuie păstrate;
11. Echipamentele de inspecţie, măsurare şi testare. Echipamentele
utilizate pentru a demonstra conformitatea trebuie controlate,
calibrate şi întreţinute. Când se utilizează hardware sau software de
testare, acestea trebuie verificate înainte de utilizare şi reverificate la
intervale stabilite;
12. Starea inspecţiilor şi testelor. Rapoartele privind starea tuturor
articolelor de configuraţie trebuie păstrate pe parcursul fazelor de
prelucrare;
13. Controlul produselor neconforme. Produsele neconforme trebuie
controlate pentru a preveni utilizarea sau instalarea incorecte. În
producţia industrială, uneori este necesară construirea unor produse
utilizând componente care nu se conformează tuturor cerinţelor.
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 aplicaţii anterioare. Totuşi, codul C
poate pune riscuri sistemului DotNET şi aceste riscuri trebuie
gestionate corespunzător;
14. Acţiuni corective. Cauzele produselor neconforme trebuie
identificate. Cauzele potenţiale ale neconformităţilor trebuie
eliminate iar procedurile trebuie modificate prin acţiuni corective.
Acţiunile corective se referă la eliminarea cauzelor neconformităţilor
reale. Acţiunile preventive se referă la eliminarea cauzelor
neconformităţilor potenţiale;
15. Manipularea, stocarea, împachetarea şi livrarea. Trebuie stabilite
proceduri pentru aceste aspecte. În cazul produselor software, aici
intră operaţiunile de multiplicare şi instalare;
16. Rapoartele de calitate. Informaţiile despre calitate trebuie colectate,
întreţinute şi puse la dispoziţie când este nevoie persoanelor
114
autorizate;
17. Audituri interne de calitate. Auditurile trebuie planificate şi
executate. Rezultatele auditurilor sunt comunicate managementului
iar deficienţele găsite trebuie corectate;
18. Instruirea. Trebuie identificate nevoile de instruire (engl. “training”)
atunci când activităţile necesită o calificare nouă. Rapoartele
acţiunilor de instruire trebuie păstrate;
19. Întreţinerea. Activităţile de service trebuie îndeplinite după cum sunt
specificate. În cazul produselor software, acest punct se referă la
întreţinere (engl. “maintenance”);
20. Tehnici statistice. Atunci când este posibil, trebuie identificate
tehnici statistice adecvate pentru verificarea capacităţii proceselor şi
a caracteristicilor produselor. În cazul produselor software, acest
punct se referă la metrici sau alte modalităţi de măsurare.
7.4. Modelul CMMI
Modelul de Maturitate a Capacităţii pentru Software (engl. “The

Capability Maturity Model for Software”, CMM) a fost dezvoltat de
Institutul de Ingineria Programării (engl. “Software Engineering Institute”,
SEI) de la Universitatea Carnegie-Mellon. A urmat Capability Maturity
Model Integration, CMMI, a cărui versiune 1.3 a fost lansată în 2010.
Modelul descrie principii şi bune practici asociate cu maturizarea
proceselor de dezvoltare software şi este destinat organizaţiilor 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 către atingerea maturităţii şi îmbunătăţirea continuă a proceselor de
dezvoltare.
CMMI include următoarele niveluri:
1. Iniţial. Procesele software sunt improvizate, uneori chiar haotice.

Puţine 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

funcţionalitatea. Există disciplina necesară pentru a repeta succesele
anterioare pentru proiecte similare;
3. Definit. Procesele software pentru activităţile de management şi cele
tehnice sunt documentate şi integrate într-un proces standard al
organizaţiei. Toate proiectele folosesc o versiune adaptată şi
aprobată a standardului;
4. Gestionat cantitativ (engl. “quantitatively managed”). Sunt colectate
măsurători detaliate despre procesele software şi calitatea
produselor. Atât procesele software cât şi produsele sunt înţelese şi
controlate din punct de vedere cantitativ;
5. În optimizare (engl. “optimizing”). Este facilitată îmbunătăţirea
continuă a proceselor prin reacţii (“feedback”) cantitative din cadrul
proceselor şi prin includerea unor idei şi tehnologii inovatoare.
Figura 7.2. Modelul CMMI
În varianta CMM, nivelul 2 se numeşte Repetabil iar nivelul 4 se

numeşte Gestionat.
Cu excepţia nivelului 1, fiecare nivel de maturitate este descompus
în câteva arii de procese cheie care indică pe ce aspecte trebuie să se
116
concentreze organizaţia pentru a-şi îmbunătăţi procesele software. Aspectele

cheie identifică problemele care trebuie rezolvate pentru a atinge un anumit
nivel de maturitate. Acestea includ grupuri de activităţi înrudite care,
realizate colectiv, conduc la îndeplinirea scopurilor considerate importante
pentru creşterea capacităţii proceselor.
Procesele cheie pentru fiecare nivel sunt prezentate în cele ce
urmează.
Prin definiţie, pentru nivelul 1 nu există procese cheie.
Procesele cheie pentru nivelul 2 se concentrează asupra stabilirii
funcţiilor manageriale de bază:
 Aria de inginerie:
o Managementul cerinţelor;
 Aria de management de proiect:
o Planificarea proiectelor;
o Monitorizarea şi controlul proiectelor;
o Managementul acordurilor cu furnizorii (Gestionarea
achiziţiilor de produse de la furnizori externi);
 Aria de suport:
o Măsurători şi analize;
o Asigurarea calităţii proceselor şi produselor;
o Managementul configuraţiei.
Procesele cheie pentru nivelul 3 se referă atât la probleme legate de
proiect cât şi la cele organizaţionale, întrucât organizaţia stabileşte
infrastructura de lucru şi instituţionalizează procesele de ingineria
programării şi de management pentru toate proiectele. Scopul principal este
standardizarea proceselor.
 Aria de inginerie:
o Dezvoltarea cerinţelor (Transformarea nevoilor clientului în
cerinţe prin consolidarea informaţiilor insuficiente,
rezolvarea conflictelor etc.);
o Soluţia 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 organizaţionale;
o Activităţile organizaţionale de instruire;
o Management de proiect integrat (Implicarea tuturor părţilor
interesate relevante);
o Managementul riscului;
 Aria de suport:
o Analiza deciziilor şi rezoluţiile (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 înţelegerea

cantitativă a proceselor şi produselor:

o Performanţele proceselor organizaţionale (Stabilirea unor
modele de evaluare cantitativă a proceselor organizaţiei);
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

îmbunătăţirea continuă şi măsurabilă a proceselor legate de software:

o Inovarea organizaţională şi desfăşurarea (engl.
“Organizational Innovation and Deployment”);
 Aria de suport:
o Analiza cauzală şi rezoluţiile (engl. “Causal Analysis and
Resolution” – Identificarea cauzelor defectelor şi luarea de
măsuri pentru prevenirea lor).
118
Organizaţiile nu pot fi „certificate” CMMI, în schimb are loc un

proces de evaluare (engl. “appraisal”), în urma căruia organizaţia este cotată
la unul din nivelurile 1-5.
7.5. Biblioteca ITIL
Biblioteca Infrastructurii Tehnologiei Informaţiei (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 contribuţiei IT-ului la mediul de afaceri şi este
în contrast cu abordările în care tehnologia deţine 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 relaţia cu clienţii.
Versiunea 2011 a ITIL cuprinde 5 volume:
1. Strategia serviciilor: conţine recomandări asupra clarificării şi

prioritizării investiţiilor furnizorilor de servicii, care pot ajuta
organizaţiile IT să îşi îmbunătăţească performanţele şi să se dezvolte
pe termen lung;
2. Proiectarea serviciilor: cuprinde o serie de bune practici asupra
proiectării serviciilor IT şi a modului în care serviciile planificate
trebuie să interacţioneze cu mediul comercial şi tehnic mai larg;
3. Tranziţia serviciilor: se adresează livrării serviciilor în mediul
operaţional şi managementului schimbărilor provocate în mediul de
afaceri;
4. Funcţionarea serviciilor: conţine bune practici pentru asigurarea
unui nivel de calitate specificat pentru serviciile oferite atât clienţilor
cât şi utilizatorilor finali, precum şi pentru monitorizarea
problemelor şi găsirea echilibrului între încrederea serviciilor şi
costuri;
119
5. Îmbunătăţirea continuă a serviciilor: îşi propune alinierea şi

realinierea serviciilor IT la necesităţile în permanentă schimbare ale
mediului de afaceri şi la identificarea şi implementarea modalităţilor
de îmbunătăţire a serviciilor.
Certificarea ITIL cade în sarcina ITIL Certification Management

Board (ICMB). Schema de certificare ITIL este modulară. La primul nivel,
Fundamente (engl. “Foundations”), candidaţii primesc 2 credite. La nivelul
Intermediar trebuie obţinute 15 credite, pe direcţiile Ciclu de viaţă (engl.
“Lifecycle”), Capacitate (engl. “Capability”) sau combinaţii ale acestora.
Un modul de Ciclu de viaţă oferă 3 credite iar unul de Capacitate oferă 4
credite. La nivelul Expert, candidatul trebuie să obţină 22 de credite,
ultimele 5 reprezentând examenul Managementul pe parcursul ciclului de
viaţă (engl. “Managing Across the Lifecycle”).
7.6. Concluzii
Există o strânsă corelaţie între modelele ISO 9001 şi CMMI, deşi

unele aspecte din ISO 9001 nu sunt acoperite de CMMI şi viceversa.
Asemănarea 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 activităţi de control
al calităţii. Diferenţa cea mai mare este că modelul CMMI pune accentul pe
îmbunătăţirea 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
organizaţie certificată ISO 9001 satisface majoritatea criteriilor CMMI de
nivel 2 şi multe criterii de pe nivelul 3. Însă datorită diferenţelor de
abordare, nu se poate face o corelaţie exactă privind nivelurile de îndeplinire
a criteriilor de calitate între cele două standarde.
Biblioteca Infrastructurii Tehnologiei Informaţiei (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
părţile interesate ale proiectului – sponsori, clienţi, colaboratori individuali
etc. Există 3 procese principale de management al resurselor umane:
 Planificarea organizaţională: identificarea, documentarea şi

atribuirea rolurilor, responsabilităţilor şi structurii ierarhice. Acestea
pot fi atribuite indivizilor sau grupurilor, care pot face parte din
organizaţie sau pot fi colaboratori externi. Grupurile interne sunt
deseori asociate cu un departament funcţional specific, precum
departamentul tehnic, de marketing sau de contabilitate.
 Selecţia personalului: alocarea resurselor umane necesare pentru a
lucra la proiect. În majoritatea situaţiilor, cele mai bune resurse pot
să nu fie disponibile, iar managerul de proiect trebuie să asigure
faptul că resursele disponibile vor satisface cerinţele de competenţă
ale proiectului.
 Dezvoltarea echipei: dezvoltarea competenţelor individuale şi de
grup pentru a creşte performanţele lucrului la proiect. Dezvoltarea
personală, atât managerială cât şi tehnică, reprezintă fundaţia
necesară pentru dezvoltarea echipei, care la rândul său 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 organizaţii. Aşadar,

sarcinile unui manager sunt în principal orientate către oameni. Dacă aceste
aspecte nu sunt înţelese, managementul este nereuşit. În general,
managementul deficitar al resurselor umane este un factor important de eşec
al proiectelor. Dintre factorii principali de management al echipei,
menţionăm:
 Consecvenţa: membrii echipei trebuie trataţi în mod comparabil, fără

favoritisme sau discriminare;
 Respectul: diferiţi membri ai echipei au competenţe diferite iar
aceste diferenţe trebuie respectate şi folosite în favoarea proiectului;
 Implicarea: toţi membrii echipei trebuie implicaţi în desfăşurarea
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 rău în desfăşurarea
proiectului.
 Motivarea: stimularea oamenilor să se angajeze într-o (mai) mare
măsură în activităţile legate de proiect.
8.3. Motivarea
Conceptul de management ştiinţific al lui F. W. Taylor a fost

implementat de Henry Ford în contextul liniilor de producţie în masă, unde
o modalitate de creştere a eficienţei a fost scăderea complexităţii sarcinilor
individuale de lucru, astfel încât la înlocuirea unei persoane, noul angajat să-
şi poată învăţa foarte repede atribuţiile şi să devină productiv.
Mass production was popularized in the 1910s and 1920s by

Henry Ford’s 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.” Ford’s 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)
Începând cu revoluţia industrială şi până după al doilea război

mondial, nu s-a pus problema creşterii productivităţii prin acţiuni de
motivare a angajaţilor. Aceştia erau priviţi aproape la fel ca nişte maşini
care pot fi schimbate când nu mai dau rezultate. Datorită faptului că
numărul oamenilor care doreau să se angajeze în industrie era foarte mare,
înlocuitori se găseau uşor.
Prosperitatea de după cel de-al doilea război mondial a diminuat
constrângerile la care puteau fi supuşi angajaţii. Oamenii puteau să
părăsească voluntar slujbele neatractive fără riscul de a muri de foame sau
de a nu-şi mai găsi un alt serviciu. Această situaţie a dus la apariţia
cercetărilor în domeniul motivării angajaţilor, pentru ca aceştia să lucreze pe
cât posibil din plăcere şi în consecinţă să fie şi mai eficienţi.
8.3.1. Proceduri şi motivare
S-a constatat că atunci când în organizaţie există proceduri clare iar

oamenii ştiu exact ce trebuie să facă, când şi cum, angajaţii sunt mai
satisfăcuţi şi devin mai productivi. Studiile realizate asupra companiilor atât
din punct de vedere al standardizării procedurilor cât şi al introducerii
măsurilor de motivare a angajaţilor (figura 8.1) au arătat că productivitatea
creşte în ordine în următoarele situaţii:
123
 motivare slabă, proceduri nestandardizate;

 motivare slabă, proceduri standardizate;
 motivare bună, proceduri nestandardizate;
 motivare bună, proceduri standardizate.
Figura 8.1. Efectul motivării şi al standardizării procedurilor

asupra productivităţii
8.3.2. Teoria aşteptării
Se bazează pe ideea că oamenii fac anumite lucruri pentru a primi o

recompensă sau pentru a ajunge la un rezultat aşteptat. Dacă se creează o
anumită aşteptare 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 adevărat, în timp va ajunge să nu mai lucreze bine. Invers,
dacă i se spune cuiva că lucrează bine, în timp va ajunge să îşi
îmbunătăţească performanţele.
Un experiment tipic realizat în şcoli primare a presupus
administrarea unui test de inteligenţă copiilor, după care a fost selectat
aleatoriu un număr mic de elevi din fiecare clasă. Învăţătorilor şi părinţilor
li s-a spus că aceşti copii au calităţi deosebite. După un timp, tuturor elevilor
li s-a administrat un test similar. S-a constatat că elevii selectaţi şi-au
124
îmbunătăţit 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 angajaţilor, recunoaşterea realizărilor,
laude publice şi critici private.
8.3.3. Teoria ierarhiei nevoilor umane a lui Maslow
Conceptul ierarhizării 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 scăzut trebuie îndeplinite înainte de a fi
luate în calcul nevoile de nivel superior.
Figura 8.2. Piramida nevoilor umane
Pe primul nivel se găsesc nevoile de hrană, adăpost, îmbrăcăminte.

După ce sunt satisfăcute acestea, motivaţia se îndreaptă către următorul
nivel, protejarea acestor factori. De exemplu, după dobândirea unei locuinţe,
persoana vrea să îi asigure siguranţa, atât imediată cât şi viitoare.
Urmează nevoile de contacte sociale. O atmosferă de lucru
motivantă apare atunci când un angajat se simte acceptat în colectiv.
125
Apoi, pe următorul nivel, apare dorinţa de a fi apreciat şi recunoscut.

Pe ultimul nivel al ierarhiei sunt nevoile de auto-împlinire, când
persoana are sentimentul că ceea ce face este valoros în sine, indiferent de
recunoaşterea colegilor sau a managerului. Interesul însuşi 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. People’s 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 Certification 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, situaţii de urgenţă) nevoile
inferioare nu mai sunt îndeplinite, acestea devin din nou factorii dominanţi.
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 self-
esteem 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 Certification 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 motivaţie-igienă (engl. “motivation-hygiene theory”),
consideră că satisfacţia şi insatisfacţia la serviciu sunt fenomene
independente: unii factori cauzează satisfacţia în timp ce alţi factori
cauzează insatisfacţia.
Satisfacţia este legată de activităţile pe care le execută individul şi
include ca factori favorizanţi provocările profesionale, recunoaşterea,
dezvoltarea personală etc.
Insatisfacţia este legată de absenţa unor factori exteriori, precum
siguranţa locului de muncă, poziţia socială, salariul, practicile de
supervizare etc.
8.3.5. Tipuri de personalitate
Piramida nevoilor este o simplificare a motivaţiilor reale. Motivarea

trebuie să ţină seama şi de tipurile de personalitate ale angajaţilor. Putem
distinge 3 tipuri de personalitate, clasificate din punct de vedere al factorilor
motivanţi. Astfel, persoanele pot fi:
 Orientate spre îndeplinirea sarcinilor: motivaţia pentru muncă este

munca însăşi;
 Orientate spre sine: munca este un mijloc pentru atingerea
scopurilor individuale (bani, călătorii etc.);
 Orientate spre interacţiuni: motivaţia principală este prezenţa şi
acţiunile colegilor – oamenii merg la serviciu fiindcă le place acolo.
Motivaţiile reale sunt compuse din elemente ale fiecărei clase.

Proporţiile se pot schimba în funcţie de circumstanţele personale şi
evenimentele externe. Oamenii nu sunt motivaţi doar de factori personali, ci
şi de apartenenţa 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 împărţite în

subechipe, astfel încât gestionarea activităţilor şi comunicarea să se limiteze
în cadrul aceleiaşi subechipe, mărindu-se productivitatea.
8.4.1. Organizarea ierarhică
În mediile dedicate producerii de software, se întâlnesc deseori

structuri ierarhice. În funcţie de dimensiunea proiectului şi a organizaţiei,
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 părţi 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 unităţi funcţionale asociate cu
responsabilităţi specifice proiectului, cum ar fi testarea.
O problemă a organizării ierarhice este distanţa dintre nivelurile
superioare şi inferioare ale piramidei. Munca „reală” se face de obicei pe
nivelurile inferioare, unde sunt utilizate cunoştinţele concrete despre
129
aplicaţie. Pe măsură ce ne ridicăm în ierarhie, cunoaşterea devine din ce în

ce mai puţin specifică.
Totuşi, 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 măsură ce informaţiile urcă în ierarhie, lucrurile
tind să pară din ce în ce mai bune. Următorul 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 prevăd 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 aceeaşi cu
cea utilizată pentru evaluarea performanţelor. Oamenii doresc evaluări
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
informaţiile să fie suficient de corecte.
Un alt aspect problematic al acestui tip de organizare este faptul că
individul este judecat, atât din punct de vedere social cât şi financiar, după
nivelul pe care îl ocupă în ierarhie. Este de înţeles aspiraţia de a ajunge pe
niveluri din ce în ce mai înalte, deşi nu este foarte clar dacă acest lucru este
de dorit. Principiul lui Peter din legile lui Murphy spune: într-o organizaţie
ierarhică, fiecare angajat urcă până la nivelul său de incompetenţă. Un
programator bun nu e neapărat şi un bun manager. Programarea necesită
competenţe diferite de cele ale managementului. Ideală este stimularea
oamenilor pentru menţinerea lor pe nivelurile la care lucrează cel mai bine.
8.4.2. Organizarea matrice
Acest tip de organizare este deseori întâlnit în situaţia când la un

proiect software lucrează oameni din diferite departamente şi care pot avea
simultan mai mulţi şefi. Unitatea de bază este un grup mic, specializat. Pot
130
exista mai multe unităţi cu aceeaşi specializare. Unităţile sunt organizate în

conformitate cu specializarea lor, de exemplu: grafică computerizată, baze
de date, interfeţe cu utilizatorul, testare etc. Proiectele implică unităţi cu
diferite specializări. Indivizii sunt organizaţi pe două axe: una reprezentând
grupurile specializate iar cealaltă – proiectele la care participă (figura 8.4).
programare
grafică baze de date testare
în timp real
proiectul A X X
proiectul B X X X
proiectul C X X X
Figura 8.4. Organizare matrice
În această situaţie, managerul de proiect este responsabil de

terminarea cu succes a proiectului. El controlează una sau mai multe unităţi
şi trebuie să menţină sau să mărească, pe termen lung, baza de cunoştinţe şi
experienţa membrilor echipei. El poate pune accent pe rezolvarea
activităţilor necesare pentru îndeplinirea obiectivului, în timp ce managerii
unităţilor se pot concentra pe creşterea gradului de relaţionare cu angajaţii.
O astfel de organizare poate fi foarte eficientă, cu condiţia 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, menţionăm:
 Folosirea unui număr mic de oameni capabili: Productivitatea

maximă este obţinută de un grup relativ mic de oameni, de exemplu
aproximativ 6 persoane. Grupurile mari necesită mai multă
comunicare, care are efecte negative asupra productivităţii şi duce la
erori mai multe;
131
 Sarcinile trebuie puse în acord cu motivaţiile şi capacităţile

oamenilor disponibili: Cu alte cuvinte, trebuie să ne asigurăm ca
principiul lui Peter nu se aplică şi în cazul echipei noastre. În cele
mai multe organizaţii, programatorilor foarte buni li se oferă funcţii
manageriale. Este mult mai bine să li se ofere posibilităţi de a avansa
în carieră în arii mai tehnice ale dezvoltării şi întreţinerii
software-ului;
 Pe termen lung, organizaţia are mai mult de câştigat dacă îi ajută pe
angajaţi să evolueze: Altfel spus, nu trebuie să aibă loc Principiul
lui Peter inversat: angajaţii urcă în ierarhie până 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ă
părăsească firma pentru a lucra la altceva mai interesant;
 Este bine să fie selectaţi oameni care să formeze o echipă bine
echilibrată şi armonioasă: Nu este suficient să existe în echipă doar
câţiva experţi de vârf. Trebuie să existe şi persoane care să
îndeplinească sarcinile mai simple, de rutină, pe care experţii s-ar
putea simţi chiar insultaţi să le rezolve;
 Cine nu se potriveşte cu echipa trebuie îndepărtat: Dacă echipa nu
funcţionează ca o unitate coerentă, de multe ori suntem înclinaţi să
mai aşteptăm puţin, să vedem cum evoluează lucrurile şi să sperăm
ca totul va merge bine. Acest lucru este dăunător pe termen lung.
132
Capitolul 9
Conducerea echipei
9.1. Încrederea
Într-un cadru profesional, încrederea se câştigă 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 neapărat legată de trăsăturile de personalitate. Putem
avea încredere în anumite persoane chiar dacă ne plac sau nu din punct de
vedere personal.
O măsură a încrederii este angajamentul – respectarea promisiunilor.
Unul din cele mai importante elemente ale proiectelor bine administrate este
ca managerul să îşi asume responsabilităţi şi să lucreze pentru a-şi respecta
aceste angajamente.
Un angajament eficient presupune următoarele aspecte:
 Persoana care îşi ia angajamentul o face de bună voie;

 Angajamentul este afirmat deschis, în mod public;
 Angajamentul este luat în cunoştinţă de cauză, doar după o analiză
atentă a volumului de lucru, a resurselor şi a graficului de lucru;
 Există o înţelegere între părţi asupra a ceea ce trebuie făcut, de către
cine şi până când;
 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, părţile afectate trebuie să îi înştiinţeze
pe ceilalţi şi să se negocieze o nouă înţelegere.
Încrederea se câştigă prin respectarea angajamentelor şi se pierde

prin comportament inconsecvent. Când un angajat nu-şi îndeplineşte

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 calculând dacă persoana va face într-adevăr
ceea ce a spus că va face. Conştient sau inconştient se fac planuri de rezervă
şi creşte nivelul stresului şi îndoielii.
9.1.1. Delegarea autorităţii
Delegarea autorităţii este o altă formă de încredere: încrederea ca

alţii să ia decizii. Prin declararea publică a faptului că un anumit aspect
organizaţional va fi administrat de altcineva, managerul îşi transferă
autoritatea asupra persoanei respective. Este important ca delegările să aibă
suficientă vizibilitate pentru ca toţi oamenii implicaţi să cunoască acest
lucru.
9.1.2. Modelele comportamentale
Nicio dispoziţie a unui conducător nu este respectată mai bine decât

aceea pe care o respectă conducătorul însuşi. Oamenii deseori învaţă prin
observarea modelelor pe care le admiră şi apoi prin încercarea conştientă
sau subconştientă de a le emula comportamentul. De aceea managerii
trebuie să fie primii care respectă regulile pe care le impun celorlalţi.
9.2. Politica şi puterea
În orice proiect care presupune organizarea oamenilor, există

persoane cu atitudini, dorinţe şi abilităţi diferite. Oricât de inteligent sau de
talentat ar fi un conducător, vor exista tot timpul oameni care nu primesc tot
ceea ce vor. Oamenii ambiţioşi vor încerca deci să îşi îndeplinească
scopurile prin influenţarea 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ă. Motivaţia politicii este
puterea. O definiţie aproximativă a puterii este capacitatea unei persoane de
134
a-i influenţa sau controla pe alţii. O altă definiţie este capacitatea de a-i
determina pe alţii să facă ceva ce altfel nu ar face. Însă aceasta nu înseamnă
neapărat manipulare sau determinarea unor acţiuni în defavoarea propriilor
interese ale persoanelor asupra cărora 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 cunoştinţele pentru a rezolva unele situaţii în
beneficiul tuturor poate fi mai puternic în organizaţie decât superiorii săi
ierarhici, uneori chiar fără ca aceştia să îşi dea seama.
Politica se poate defini ca procesul de luare a deciziilor în vederea
administrării şi controlului afacerilor interne şi externe ale unei organizaţii
(în sensul cel mai larg).
Este important de remarcat faptul că în general raportul dintre putere
şi responsabilitate este constant. Cu cât are cineva mai multă putere, cu atât
are mai multe constrângeri, mai multe interese de echilibrat şi probleme de
rezolvat. De aceea, puterea mai mare nu uşurează lucrurile; stresul,
pretenţiile, provocările cresc ca rezultat al puterii sporite.
9.2.1. Surse de putere
Există mai multe surse de putere într-o organizaţie:
 Recompensele: posibilitatea de a da oamenilor bonusuri, măriri de

salariu, premii etc.;
 Constrângerile: controlul formal asupra penalizărilor, sancţiunilor,
sau capacitatea informală de a ridiculiza public pe cineva etc.;
 Cunoaşterea: expertiza într-un anumit domeniu sau informaţiile
specifice relevante pentru anumite decizii;
 Relaţiile: persoanele cunoscute care pot sprijini pe alţii şi îşi pot
transfera asupra lor o parte din propria putere şi reputaţie;
 Influenţa: capacitatea de a-i convinge pe alţii, indiferent de
cunoştinţele avute într-un anumit domeniu, presupunând o
combinaţie de abilităţi de comunicare, siguranţă de sine, inteligenţă
emoţională, putere de observaţie etc.
135
Folosirea greşită a puterii are loc atunci când o persoană îşi

urmăreşte propriul interes în locul obiectivelor proiectului. Această situaţie
este facilitată de desincronizarea dintre obiectivele proiectului şi realitate şi
de lipsa unei viziuni comune asupra proiectului.
9.2.2. Tipuri de putere
Puterea funcţională este de două tipuri: acordată şi câştigată.

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 ceilalţi oameni faţă de el. Prin contrast, puterea câştigată se
cultivă prin performanţe şi acţiuni, şi apare atunci când 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
decât a le impune. Puterea de convingere a unui manager creşte dacă este
dublată de încrederea echipei. Acest lucru devine important mai ales în
momentele de criză când managerul este nevoit să le ceară oamenilor să
îndeplinească activităţi mai dificile, să facă lucru suplimentar sau unele
acţiuni care nu intră explicit în fişa postului.
Conducerea pe baza puterii acordate limitează relaţiile interumane,
exclude posibilitatea schimburilor de idei şi se concentrează pe folosirea
forţei şi nu a inteligenţei. Când un conducător scoate sabia, nimeni nu-l mai
ascultă pe conducător, ascultă sabia. În plus, oamenii îşi vor pregăti propriile
săbii ca răspuns. Când managerul va greşi, unii subordonaţi îşi vor folosi
propria putere acordată pentru a-i contesta puterea acestuia, rezultând într-o
competiţie care nu are nimic de-a face cu rezolvarea problemei sau căutarea
celei mai bune soluţii.
Folosirea puterii acordate este tentantă deoarece este mai uşoară:
conducătorul nu trebuie să depună eforturi suplimentare pentru a obţine ce
vrea. Cu toate acestea, conducerea bazată exclusiv pe puterea acordată
îndepărtează oamenii inteligenţi şi independenţi şi îi încurajează pe cei
cărora le place să li se spună ce să facă. De asemenea, tiranii creează alţi
136
tirani pe nivelurile inferioare iar aceste modele de comportament otrăvesc

până la urmă întreaga organizaţie.
Totuşi, un manager trebuie să fie autocrat când este necesar. Când
lucrurile scapă de sub control, puterea acordată poate fi cel mai rapid mod
de a restabili ordinea. Când o şedinţă degenerează sau când angajamente
importante sunt încălcate, 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
organizaţie sunt probleme fundamentale care trebuie rezolvate. Autocraţia
poate ameliora simptomele, dar nu rezolvă problemele de bază.
9.3. Procesul de feedback
Conducătorii buni au suficientă încredere în colaboratori pentru a

primi reacţii asupra propriilor performanţe. De multe ori reacţiile se primesc
în mod privat. Conducătorul nu este obligat să acţioneze în conformitate cu
feedback-ul primit sau nici măcar să comenteze, însă este greu de imaginat
un proiect de succes în care să nu existe o cale sănătoasă şi sigură prin care
astfel de informaţii să ajungă la manager.
Conducătorii trebuie să îşi definească propriul proces de feedback.
Mulţi oameni au în general reţineri în a-şi critica şefii. Cu toate acestea,
dacă managerii stabilesc o modalitate de comunicare cu angajaţii,
informaţiile obţinute sunt de obicei mai valoroase decât informaţiile similare
obţinute de la proprii lor manageri.
În contextul interacţiunilor dintre angajaţi, trebuie să se facă
întotdeauna distincţia 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 alţii pentru a-şi spune deschis părerile fără a trebui să-şi
ceară scuze, dar şi fără maliţiozitate sau comentarii nejustificate. Când
diferenţele de opinie degenerează în atacuri la persoană, managerul îşi poate
folosi puterea acordată pentru a aduce discuţia pe un făgaş productiv pentru
proiect.
137
9.3.1. Greşelile subordonaţilor
Este uşor să ai încredere în oameni când totul merge bine, însă

gestionarea greşelilor este mai complicată. Când un angajat raportează
managerului o greşeală, managerul trebuie să ia în considerare următoarele:
 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ă
înrăutăţească situaţia;
 Să identifice opţiunile de rezolvare şi să îl îndrume pe cât posibil pe
angajat pentru ca acesta să ia el însuşi măsurile necesare;
 Să se asigure că dacă există o lecţie de învăţat, angajatul o va învăţa.
Pe lângă ajutorul dat în rezolvarea unei probleme, managerii trebuie

să conducă procesul preschimbării greşelii într-o lecţie pe care s-o înveţe
echipa.
Membrii echipei nu trebuie să aibă sentimentul că lucrează singuri
sau că sunt sprijiniţi doar când lucrurile merg bine. De fapt, potenţialul de a
face greşeli este exact acelaşi potenţial necesar pentru a contribui la succesul
proiectului. Mediul de lucru ideal este acela care permite oamenilor să fie
ambiţioşi, însă îi determină să îşi admită greşelile şi să îşi asume
responsabilitatea pentru ele.
În timpul unei crize, nu se recomandă pedepsirea unui angajat câtă
vreme problema este încă nerezolvată. În acest mod nu se rezolvă nimic iar
de cele mai multe ori scade probabilitatea rezolvării rapide a problemei,
deoarece vinovatul, care ştie cel mai mult despre aceasta, va intra în
defensivă. După ce lucrurile reintră în normal, când presiunea scade, este cel
mai potrivit moment pentru a analiza ce s-a întâmplat şi de ce, şi care sunt
lecţiile pentru individ, manager şi echipă.
138
9.4. Calităţile necesare managerului de proiect
9.4.1. Energia
Una din cele mai importante trăsături necesare unui manager este
capacitatea de a trage echipa după el, de a-i determina pe subordonaţi să
acţioneze. Această capacitate este o combinaţie între a şti cum să fie un
catalizator sau un motor în diverse situaţii şi a avea curajul să facă ceea ce
îşi propune.
Energia şi determinarea sunt de obicei cerinţe cheie pentru angajarea
unui manager de proiect. Dacă cineva nu este suficient de activ şi flexibil
pentru a-şi adapta abilităţile şi cunoştinţele la situaţiile date şi pentru a găsi
modalităţi de a împinge lucrurile înainte, atunci acesta probabil nu va fi
capabil să conducă un proiect tipic.
9.4.2. Perseverenţa
În orice situaţie dificilă există căi mai simple: renunţarea, acceptarea

unei soluţii parţiale, amânarea acţiunii în speranţa că lucrurile se vor rezolva
de la sine sau învinovăţirea altora.
Calea dificilă este confruntarea directă a problemei şi urmărirea ei
până la găsirea unei soluţii acceptabile. Managerii de succes pur şi simplu
nu renunţă uşor, asta însemnând că iau în calcul mai multe alternative decât
oamenii obişnuiţi şi sunt siguri că în 99% din cazuri există o rezolvare a
problemei (inclusiv prin schimbarea definiţiei problemei). Când este
necesar, ei trebuie să acţioneze în orice mod posibil. Aceasta poate însemna
reorganizarea unei echipe disfuncţionale, convingerea unor persoane dificile
să se pună de acord asupra obiectivelor sau aplanarea conflictelor dintre
angajaţi.
În caz de neînţelegeri sau la negocieri, un manager perseverent poate
determina părţile adverse să renunţe doar ca să fie lăsate în pace.
Perseverenţa, dar nu agresivitatea, poate fi o tehnică eficientă în sine.
139
9.4.3. Stabilirea şi respectarea priorităţilor
Priorităţile clare sunt coloana vertebrală a progresului. Evoluţia

proiectului depinde de o înţelegere clară a celor mai importante obiective şi
aplicarea acestei perspective în fiecare interacţiune care are loc în cadrul
echipei.
Multe dificultăţi de comunicare şi paşi greşiţi apar din cauza
înţelegerii diferite a priorităţilor: de exemplu programatorul 1 pune accent
pe viteza programului iar programatorul 2 pe minimizarea resurselor de
memorie. Acelaşi lucru se întâmplă şi cu echipele de proiectare, testare,
marketing etc. Stabilirea priorităţilor ajută la concentrarea eforturilor pentru
avansarea către scopul final al proiectului în loc de rezolvarea conflictelor
apărute.
Stabilirea priorităţilor, şi în special a celor critice, permite refuzul
unor cerinţe sau funcţionalităţi. În aceste situaţii, 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 configuraţii organizaţionale tipice:
 Structura simplă: Într-o structură simplă există unul sau numai

câţiva manageri şi un nucleu de persoane care lucrează la proiectul
propriu-zis. Această configuraţie este întâlnită de obicei în firmele
noi, cu personal redus. Specializarea este limitată, la fel şi instruirea
şi formalizarea. Mecanismul de coordonare corespunzător este
supervizarea directă;
 Birocraţia automată: Când conţinutul sarcinilor este complet
specificat, este posibilă executarea acestora pe bază de instrucţiuni
precise. Exemple tipice ale acestui tip de configuraţie sunt producţia
de masă şi liniile de asamblare. Instruirea este redusă, în schimb se
140
pune mare accent pe specializare şi formalizare. Coordonarea se

obţine prin standardizarea proceselor de lucru;
 Forma divizionalizată: În acest tip de configuraţie fiecărei divizii
(fiecărui proiect) i se acordă o mare autonomie în ceea ce priveşte
modul de atingere a scopurilor. Detaliile sunt stabilite de divizii.
Coordonarea se obţine prin standardizarea producţiei. Controlul se
exercită regulat prin măsurarea performanţelor diviziilor. Acest
mecanism de coordonare este posibil numai atunci când este
specificat precis rezultatul final;
 Birocraţia profesională: Dacă nu este posibilă specificarea
rezultatului sau conţinutul sarcinilor, coordonarea poate fi realizată
prin standardizarea calificării. Profesioniştii talentaţi se bucură de o
autonomie considerabilă privind modul de îndeplinire a atribuţiilor;
 Adhocraţia: În proiecte mari şi/sau inovatoare, lucrul este divizat
între mai mulţi specialişti. Î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 obţine prin
ajustare reciprocă.
Trebuie spus că majoritatea organizaţiilor reale nu pot fi încadrate

într-un singur tip de configuraţie. Diferite departamente ale firmei pot fi
organizate diferit. De asemenea, tipurile prezentate reprezintă idei abstracte.
În realitate, organizaţiile pot tinde spre unul din aceste tipuri, păstrând în
acelaşi timp şi caracteristici ale celorlalte.
9.6. Stiluri de management
Teoria lui Reddin a stilurilor de management distinge două

dimensiuni ale managementului forţei de muncă:
 gradul de dirijare a relaţiilor: se referă la atenţia acordată

individului şi relaţiilor lui cu alţi indivizi din organizaţie;
141
 gradul de dirijare a activităţilor: priveşte atenţia acordată

rezultatelor care trebuie obţinute şi modului în care acestea trebuie
obţinute.
Gradele de dirijare pot fi scăzute sau ridicate, ceea ce conduce la

patru combinaţii de bază, prezentate în tabelul 9.1.
Tabelul 9.1. Stilurile de management ale lui Reddin

gradul de dirijare a activităţilor
scăzut ridicat
gradul de dirijare
scăzut stil de separare stil de angajament
a relaţiilor
ridicat stil de relaţionare stil de integrare
Stilul cel mai potrivit pentru o anumită situaţie depinde de tipul

lucrării:
 Stilul de separare: Este cel mai potrivit pentru munca de rutină.

Eficienţa este tema centrală. Managerul de proiect se comportă ca un
birocrat care aplică reguli şi proceduri. Acest stil corespunde
configuraţiei de birocraţie automată;
 Stilul de relaţionare: Este cel mai eficient în situaţiile în care
oamenii trebuie motivaţi, coordonaţi şi instruiţi. Sarcinile sunt clar
atribuite indivizilor. Munca nu are un caracter de rutină, ci este
inovatoare şi specializată. Stilul este asemănător configuraţiei de
adhocraţie;
 Stilul de angajament: Este cel mai eficient când se lucrează sub
tensiune. Managerul de proiect trebuie să ştie cum să se atingă
scopurile fără să trezească resentimente. Stilul e asemănător
configuraţiei de birocraţie profesională;
 Stilul de integrare: Se potriveşte situaţiilor când 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, configuraţia de adhocraţie
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 aplicaţie bine specificată într-un domeniu familiar, coordonarea
poate fi realizată prin standardizarea producţiei. Pentru o aplicaţie complexă
şi novatoare, acest mecanism ar fi ineficient.
143
Capitolul 10
Managementul comunicării
10.1. Introducere
Comunicarea este procesul de trimitere a informaţiilor de la o sursă

la o destinaţie prin intermediul unui mediu de transmitere şi care presupune
înţelegerea informaţiilor în acelaşi mod atât de către sursă cât şi de
destinatar.
Managementul comunicării include procesele necesare pentru a
asigura la timp şi în mod adecvat generarea, colectarea, diseminarea,
stocarea şi punerea la dispoziţie a informaţiilor proiectului. Asigură
legăturile critice dintre oamenii, ideile şi informaţiile necesare pentru
succesul proiectului. Toate persoanele implicate trebuie să fie pregătite să
trimită şi să primească mesaje conform terminologiei adoptate în proiect şi
să înţeleagă cum aceste acţiuni afectează proiectul în ansamblu.
Abilităţile de comunicare sunt printre cele mai importante calităţi pe
care trebuie să le aibă un manager de proiect. Figura 10.1 prezintă
rezultatele unui sondaj printre manageri privind importanţa pe care aceştia o
acordă calităţilor necesare pentru managementul proiectelor.
În medie, 70% din timpul de lucru al unui manager se consumă
pentru comunicare, având aproximativ structura din figura 10.2.

100%
90% 84%
80% 75% 72%
68%
70%
60%
48%
50%
40%
30%
20%
10%
0%
Abilitati de Abilitati Abilitati de Abilitati de Abilitati tehnice
comunicare organizatorice "team building" conducere
Figura 10.1. Care din următoarele abilităţi consideraţi

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

comunicării
Există 4 procese principale de management al comunicării:
 Planificarea comunicării: procesul care stabileşte ce informaţii sunt

necesare, cine are nevoie de ele şi cine trebuie să le genereze, când
sunt necesare şi cum trebuie furnizate; determină necesarul de
comunicare între persoanele implicate în proiect;
 Distribuirea informaţiilor: asigură faptul că informaţiile necesare
sunt disponibile la timp;
 Raportarea performanţelor: colectarea şi diseminarea informaţiilor
referitoare la performanţele atinse de proiect; rapoartele indică starea
curentă, progresele înregistrate şi prognozele;
 Încheierea pe plan administrativ (engl. “administrative closure”):
generarea, colectarea şi diseminarea informaţiilor necesare pentru
formalizarea finalizării unei faze sau a proiectului (de exemplu
documentarea rezultatelor).
10.3. Transmiterea informaţiilor
Oamenii comunică prin simboluri, de la desenele rupestre la

codificarea digitală a datelor, în diverse moduri: prin voce, scriere sau
gesturi. Indiferent de natura comunicării, orice schimb de informaţii
presupune 3 etape:
 codificarea unui mesaj la sursă;

 transmiterea acestuia printr-un canal de comunicaţie;
 decodificarea mesajului la destinaţie.
În prima etapă, mesajul trebuie convertit într-o reprezentare

simbolică, de exemplu cuvinte, note muzicale, ecuaţii matematice, biţi etc.
Un mesaj „La mulţi ani” simbolizează o urare. Aceeaşi urare poate fi
147
transmisă prin dispunerea pe un portativ a notelor muzicale ale cântecului

„Mulţi ani trăiască”, numai că în acest caz se codifică sunete.
Pentru ca un cod să fie util, trebuie trimis cuiva. Transmiterea poate
fi făcută de asemenea printr-o mare varietate de mijloace: direct prin voce,
printr-o scrisoare, prin telefon, prin e-mail etc. La destinaţie, cineva trebuie
să recepţioneze simbolurile şi să le decodifice, comparându-le cu propriul
bagaj informaţional pentru a extrage datele utile.
Schema generală a unui sistem de comunicaţie este reprezentată în
figura 10.3. Mai întâi, sursa de informaţii produce mesajul care se doreşte a
fi comunicat. Transmiţătorul acţionează asupra mesajului, aducându-l într-o
formă convenabilă pentru transmiterea prin canalul de comunicaţii, adică
mediul folosit în acest scop. Aici apar de obicei zgomote care afectează
calitatea semnalului. Receptorul realizează în general operaţia inversă celei
executate de transmitător, pentru a reconstrui mesajul din semnalul primit.
Destinatarul este persoana sau dispozitivul căruia îi este adresat mesajul.
Figura 10.3. Schema generală a unui sistem de comunicaţie
Comunicarea într-un grup este influenţată de factori precum:
 Dimensiunea grupului: cu cât este mai mare grupul, cu atât este mai
dificil pentru oameni să comunice cu alţi membri ai acestuia;
148
 Structura grupului: comunicarea se realizează mai bine în grupuri cu

o structură informală decât în grupuri structurate ierarhic;
 Alcătuirea grupului: comunicarea se realizează mai bine atunci când
în grup există tipuri de personalităţi diferite şi în grupuri mixte
(bărbaţi şi femei).
10.4. Bariere de comunicare
În figura 10.4 se prezintă scăderea nivelului de înţelegere a unui

mesaj pe măsura transmiterii lui în ierarhia organizaţiei.
100%
100%
90%
80%
70% 66%
60% 55%
50% 40%
40% 30%
30% 20%
20%
10%
0%
Presedinte Vice- Manager Manager de Sef de Membru al
presedinte general proiect echipa echipei
Figura 10.4. Diminuarea nivelurilor de înţelegere
În multe situaţii mesajele pot fi blocate sau distorsionate şi în

consecinţă înţelesul lor poate fi modificat considerabil. Dintre cauzele
acestui fapt, menţionăm:
 Percepţiile distorsionate: mediul, starea psihică, statutul social sau

organizaţional al sursei, chiar şi subiectul mesajului sunt factori care
pot influenţa primirea corectă a acestuia. Percepţiile destinatarului
sunt afectate şi de nevoia de a relaţiona noile informaţii cu informaţii
anterioare primite şi integrate;
149
 Lipsa de încredere a sursei: dacă sursa comunică o informaţie

greşită sau care pare greşită, conţinutul mesajului nu mai contează
iar percepţia mesajului va fi în concordanţă cu aşteptările
destinatarului;
 Erorile de transmisie: limba este una din cauzele cele mai des
întâlnite pentru transmiterea eronată a unui mesaj. Pe lângă cuvintele
propriu-zise şi accentele diferite, contează experienţa anterioară şi
contextul cultural ale vorbitorilor;
 Presupunerile diferite: asupra acţiunilor care trebuie îndeplinite, în
ce moment, şi dacă trebuie trimisă o înştiinţare asupra realizării lor
cu succes sau nu.
10.5. Îmbunătăţirea comunicării
Pentru a îmbunătăţi comunicarea, se pot lua următoarele măsuri:
 Mesajul trebuie să fie relevant pentru destinatar: destinatarul trebuie

să fie interesat de conţinutul mesajului (să aibă ceva de câştigat de pe
urma sa). Faptul că sursa înţelege mesajul nu garantează înţelegerea
acestuia de către destinatar: nu contează ce spune sursa, contează ce
înţelege destinatarul;
 Mesajul trebuie redus la termenii cei mai simpli: detaliile inutile
necesită resurse suplimentare pentru decodarea esenţei conţinutului
mesajului;
 Repetarea punctelor cheie: pe parcursul actului de comunicare este
utilă sintetizarea ideilor principale din timp în timp şi repetarea
informaţiilor importante.
10.5.1. Îmbunătăţirea procesului de ascultare
Dintre modalităţile de optimizare a proceselor de comunicare şi

ascultare, menţionăm:
150
 Lipsa întreruperilor: întreruperile care nu sunt legate direct de

subiectul mesajului suspendă firul logic al expunerii şi reduc
eficienţa comunicării;
 Favorizarea siguranţei vorbitorului: mulţi manageri au emoţii când
trebuie să vorbească în public. Pentru optimizarea transmiterii
mesajului, audienţa trebuie să pară interesată de subiect şi să îl
susţină pe vorbitor prin comentarii şi atitudini pozitive, atunci când
este cazul;
 Eliminarea surselor de distragere a atenţiei: ascultarea poate fi mult
îmbunătăţită prin evitarea mediilor zgomotoase, de exemplu
închiderea uşilor, telefoanelor mobile etc.
10.6. Comunicarea scrisă
Comunicarea scrisă poate fi mai detaliată decât cea verbală şi poate

fi utilizată pentru a explica unele chestiuni complexe care ar fi mai dificil de
înţeles î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 modalităţilor 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 târziu.
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 răspunde repede, sacrificându-se astfel calitatea mesajelor. Însă claritatea
email-urilor, mai ales a celor aparţinând managerului de proiect, poate
influenţa foarte mult comunicarea în cadrul echipei şi în final performanţele
proiectului în ansamblu.
151
Vom prezenta în continuare o serie de recomandări 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 număr mare de persoane, este util ca
expeditorul să recitească mesajul după câteva minute după ce a fost
scris sau să roage un membru al echipei să îl citească şi să îşi spună
părerea;
 Să conţină o cerere de acţiune şi un termen limită. Mesajul trebuie
să aibă o intenţie bine precizată, astfel încât receptorii să înţeleagă de
ce l-au primit şi ce trebuie să facă până la termenul stabilit;
 Să se conformeze unor priorităţi. Expeditorul trebuie să se întrebe
dacă este cu adevărat necesar să trimită un anumit email, sau dacă
unele lucruri nu pot fi rezolvate mai uşor la telefon sau într-o
discuţie directă.
Managerul de proiect nu trebuie să plece de la premisa că toţi

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-adevăr recepţionat.
În cazul în care managerul nu înţelege pe deplin conţinutul unui
mesaj important, în locul unui email de răspuns cu întrebări se recomandă o
discuţie telefonică sau directă pentru clarificări. Comunicarea interactivă
este mult mai eficientă pentru rezolvarea confuziilor şi conflictelor. După
clarificarea chestiunii, managerul poate trimite un email cu noile explicaţii
tuturor celor interesaţi deoarece sunt mari şansele ca mesajul iniţial să fi pus
probleme şi altor persoane.
Dacă subiectul sumarizează corect conţinutul corpului mesajului,
destinatarii îşi vor modifica în mod corespunzător contextul mental înainte
de citirea mesajului propriu-zis. Dacă problema ridicată în email este
urgentă, subiectul poate fi prefaţat de cuvântul URGENT. Dacă prin email
152
nu se solicită un răspuns, subiectul poate fi prefaţat de abrevierea FYI (engl.

“For Your Information”). Chiar dacă informaţiile indirecte sunt în principiu
benefice pentru schiţarea unei imagini de ansamblu asupra lucrului la
proiect, acest tip de mesaje nu trebuie să domine conversaţiile unei echipe.
10.7. Comunicarea verbală
Comunicarea verbală este mai rapidă decât cea scrisă şi permite

reacţii şi întrebări din partea destinatarului. Mesajele verbale sunt însă mai
uşor de trecut cu vederea. Comunicarea verbală este importantă deoarece
simultan se realizează şi comunicarea non-verbală, care ajută la interpretarea
rezultatelor comunicării.
10.7.1. Organizarea şedinţelor
În general, costul şedinţelor este foarte mare. Dacă o şedinţă durează

1 oră şi implică 10 persoane, costul său va fi de 10 ore-om. În loc să
depaneze programul, programatorii stau în sala de conferinţe aşteptând,
justificat sau nu, să aibă loc ceva important.
Totuşi, dacă într-o şedinţă se discută decizii critice pentru progresul
proiectului sau se prezintă informaţii care pot schimba perspectiva tuturor
participanţilor, atunci valoarea sa este mult mai ridicată şi aceasta devine un
mod de comunicare ale cărui rezultate ar fi dificil de obţinut prin alte
mijloace.
Unul din motivele pentru care foarte multe şedinţe sunt plictisitoare
pentru participanţi este nepotrivirea dintre scopurile şedinţei şi structura sau
dimensiunea acesteia. În principal, există 3 tipuri de şedinţe:
 Discuţii cu un grad ridicat de interactivitate: Scopul este rezolvarea

unor probleme specifice şi căutarea alternativelor, de exemplu
discuţii de proiectare detaliată, brainstorming, managementul
crizelor, clasificarea defectelor. Dimensiunea este de 2-8 persoane şi
toţi participanţii iau cuvântul;
153
 Raportare sau discuţii moderate: O persoană trebuie să expună nişte

idei asupra cărora doreşte reacţiile participanţilor. Discuţiile pot fi
interactive, dar implică numai un subgrup al participanţilor.
Dimensiunea este de 5-15 persoane. De exemplu: analiza
specificaţiilor, a arhitecturii, prezentări scurte;
 Analize generale: Scopul este sintetizarea stării 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 stării
unui proiect, prezentări lungi.
Şedinţele nu sunt potrivite pentru:
 Înştiinţări curente: dacă fluxul informaţional este unidirecţional, este

mai potrivit un email;
 Criticarea angajaţilor cu performanţe scăzute: de obicei o astfel de
abordare nu creşte motivarea angajaţilor respectivi; este mai potrivită
o discuţie faţă în faţă;
 Creşterea entuziasmului: motivarea este o provocare zilnică a
managerului de proiect; sunt mai potrivite discuţii private cu fiecare
membru al echipei şi rezolvarea problemelor fiecăruia separat.
În continuare sunt prezentate câteva recomandări pentru a organiza o

şedinţă productivă:
 O şedinţă reuşită are nevoie de o persoană cu rol de facilitator, care

să îi ajute pe ceilalţi să aibă un dialog constructiv. Pe lângă rolul de
stabilire a agendei de discuţii şi de direcţionare a ideilor pe un făgaş
util pentru proiect, facilitatorul poate elimina neclarităţile de
exprimare ale unor persoane, refrazând sau rafinând unele intervenţii
pentru a fi mai uşor înţelese de ceilalţi participanţi;
 Organizatorii trebuie să se asigure că sunt prezente numai persoanele
necesare. Dacă nu pot fi invitate aceste persoane, este mai bine să se
amâne şedinţa. Dacă în sală sunt prezente şi alte persoane care ar
putea afecta bunul mers al discuţiilor, acestora li se poate promite că
154
li se vor trimite notele discuţiilor (minuta întâlnirii), însă este bine să

fie invitate politicos să se retragă;
 Conducătorii discuţiilor trebuie să pregătească atent şedinţa. Multe
întâlniri eşuează din cauza lipsei de pregătire. Pregătirea poate
consta într-o listă de întrebări sau de probleme deschise, sau poate fi
mai complexă, presupunând o demonstraţie sau documente ce
trebuie înmânate participanţilor înainte de începerea discuţiilor;
 Dacă este posibil, trebuie descurajată folosirea laptop-urilor sau a
altor dispozitive care ar putea distrage atenţia participanţilor de la
discuţii;
 Şedinţa trebuie finalizată cu un plan de acţiune ulterioară, o serie de
acţiuni bine definite şi responsabilii care se vor ocupa de acestea. O
parte din pregătirea şedinţei se referă la modalităţile de a ajunge la
un acord privind acest plan şi la identificarea celor mai potrivite
persoane care să realizeze activităţile aferente.
155
Capitolul 11
Managementul riscului
11.1. Introducere
Managementul riscului implică anticiparea situaţiilor care pot afecta

graficul de lucru al proiectului şi calitatea produsului software dezvoltat
precum şi luarea unor măsuri pentru evitarea sau limitarea efectelor lor. Un
management de risc eficient asigură faptul că problemele apărute nu vor
conduce la depăşiri 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
performanţele produsului dezvoltat, de exemplu când o componentă
cumpărată sau un instrument de dezvoltare nu funcţionează potrivit
aşteptărilor;
3. Riscuri privind mediul comercial: afectează organizaţia, de exemplu
apariţia unui produs nou al unui competitor.
Desigur, aceste tipuri de risc se pot suprapune. Dacă un programator

cu experienţă părăseşte proiectul, această situaţie constituie un risc pentru
proiect deoarece livrarea sistemului poate fi întârziată. Poate fi un risc şi
pentru produs deoarece persoana înlocuitoare poate fi mai puţin competentă
şi poate face mai multe erori. Poate fi şi un risc comercial pentru
organizaţie, deoarece experienţa programatorului nu mai poate fi folosită
pentru demararea unor anumite proiecte în viitor.
Multe riscuri sunt comune pentru un mare număr de proiecte
software, de exemplu cele prezentate în tabelul 11.1.

Tabelul 11.1. Riscuri posibile în proiecte software

Risc Tip de risc Descriere
Personalul cu experienţă
Pierderile de personal Proiect pleacă înainte ca proiectul să
fie terminat
Are loc o schimbare a
Schimbarea conducerii Proiect managementului organizaţiei,
care are alte priorităţi
Indisponibilitatea Hardware-ul esenţial pentru
Proiect
hardware-ului proiect nu este livrat la timp
Există un număr mai mare de
Schimbarea cerinţelor Proiect şi produs schimbări ale cerinţelor decât
a fost anticipat
Specificaţiile privind
Întârzierea specificaţiilor Proiect şi produs interfeţele principale nu sunt
disponibile la timp
Dimensiunea sistemului a fost
Subestimarea dimensiunii Proiect şi produs
subestimată
Instrumentele CASE pe care
Performanţele slabe ale
Produs se bazează proiectul nu dau
instrumentelor CASE
performanţele dorite
Tehnologia care stă la baza
Schimbarea tehnologiei Comercial sistemului este înlocuită de o
nouă tehnologie
Un produs concurent este
Concurenţa produsului Comercial 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 cerinţelor, din
dificultăţile de estimare a timpului şi resurselor necesare pentru dezvoltare,
din dependenţa de abilităţile individuale, din schimbările cerinţelor care
reflectă schimbarea nevoilor clienţilor 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 probabilităţilor şi consecinţelor
riscurilor;
3. Planificarea gestionării riscurilor: întocmirea unor planuri pentru
evitarea riscurilor sau minimizarea efectelor acestora asupra
proiectului;
4. Monitorizarea riscurilor: actualizarea evaluărilor şi revizuirea
planurilor atunci când apar informaţii 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 consecinţele apariţiei
factorilor de risc şi măsurile care trebuie luate în această eventualitate.
11.2. Analiza SWOT
Analiza SWOT (engl. “Strengths – Weaknesses – Opportunities –

Threats”, rom. „Puncte tari – Puncte slabe – Oportunităţi – Ameninţări”)
poate constitui o etapă preliminară în managementul riscului. Ea ajută la
găsirea corespondenţelor optime dintre tendinţele mediului extern
(oportunităţile şi ameninţările) şi posibilităţile interne ale organizaţiei.
Folosită ca un instrument de analiză a riscului, poate identifica ariile cele
mai sensibile dar şi caracteristicile cele mai puternice ale organizaţiei.
Termenii cheie ai analizei SWOT se definesc astfel:
159
 Un punct tare este o resursă sau o abilitate pe care organizaţia o

poate utiliza eficient pentru a-şi atinge obiectivele, ce poate fi făcut
sau ce poate fi folosit;
 Un punct slab este o limitare sau un defect care împiedică
organizaţia să-şi îndeplinească obiectivele, ce nu poate fi făcut sau
ce nu poate fi folosit;
 O oportunitate este orice situaţie favorabilă din mediul exterior al
organizaţiei care o ajută să-şi atingă scopurile. De obicei este o
tendinţă sau o schimbare, o necesitate neglijată care creşte cererea
pentru un anumit produs şi care permite organizaţiei să reducă
riscurile;
 O ameninţare este o situaţie defavorabilă din mediul exterior cu
potenţialul de a perturba organizaţia. Ameninţarea poate fi o barieră,
o constrângere sau orice situaţie externă care poate cauza probleme.
După cum se arată în figura 11.2, porţiunea internă reflectă

capacitatea organizaţiei. Porţiunea externă identifică factorii de succes sau
obstacolele pentru implementare sau performanţă.
Figura 11.2. Relaţiile dintre mediul intern şi mediul extern

al unei organizaţii în analiza SWOT
După terminarea analizei, profilul SWOT poate fi utilizat ca bază

pentru estimarea severităţii riscurilor şi determinarea celor mai potrivite
modalităţi de confruntare şi minimizare a acestora.
160
Analiza SWOT se bazează pe întrebări adresate de manageri pentru a

determina în jur de 5 factori principali în fiecare categorie. Mai mult de 5
factori pot fi incluşi doar dacă sunt suficient de diferiţi între ei şi sunt critici
pentru conturarea riscurilor majore. Exemple de astfel de întrebări sunt
prezentate în tabelul 11.2.
Tabelul 11.2. Întrebări pentru realizarea analizei SWOT

Puncte tari Puncte slabe
Ce avantaje are organizaţia? Ce s-ar putea îmbunătăţi?

Ce face organizaţia mai bine decât Ce ar trebui evitat?
oricine altcineva? Ce puncte sunt considerate drept
La ce resurse unice sau ieftine are slăbiciuni de către oamenii din acelaşi
acces? segment de piaţă?
Ce puncte tari îi recunosc oamenii din Ce factori afectează performanţele
acelaşi segment de piaţă? organizaţiei?
Ce factori îi determină succesul?
Oportunităţi Ameninţări
Unde sunt oportunităţile care pot Ce obstacole ar putea întâmpina

influenţa organizaţia? organizaţia?
Care sunt tendinţele externe cele mai Ce acţiuni ale concurenţei ar trebui să
promiţătoate pentru organizaţie? îngrijoreze?
Schimbări în tehnologie şi piaţă la scară Se modifică specificaţiile pentru
mică şi mare produs?
Schimbări în politicile guvernamentale Se modifică tehnologiile?
legate de domeniul de activitate al Există probleme de lichiditate sau
organizaţiei datorii?
Schimbări în modelele sociale, profiluri Poate un anumit punct slab să îi
de populaţie, schimbări în stilul de viaţă ameninţe serios organizaţiei poziţia pe
etc. piaţă?
Evenimente locale
161
Analiza SWOT este utilă atât pentru identificarea căilor de acţiune

cât şi pentru punerea problemelor într-o perspectivă mai largă. Analiza
poate ajuta la descoperirea oportunităţilor care pot fi exploatate cu ajutorul
punctelor tari şi la înţelegerea punctelor slabe care pot fi gestionate pentru a
elimina ameninţările. De asemenea, analiza SWOT poate oferi indicaţii
asupra strategiilor prin care organizaţia se poate diferenţia de competitori
pentru a-şi asigura succesul pe piaţă.
11.3. Identificarea riscurilor
Identificarea riscurilor îşi propune descoperirea posibilelor situaţii de

risc pentru proiect. În principiu, acestea nu ar trebui evaluate sau prioritizate
în această fază, însă în practică riscurile cu consecinţe minore sau cu
probabilităţi foarte mici sunt eliminate.
Toleranţa la risc este măsura în care o organizaţie sau o persoană
este dispusă să îşi asume riscuri. Companiile, ca şi oamenii, au toleranţe
diferite la risc. Unele îşi asumă mai multe riscuri încercând să câştige 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 experienţei personale a managerului. Se
recomandă utilizarea unei liste de verificare cu diferite tipuri de risc. Pot
apărea 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 organizaţionale, derivate din mediul organizaţional 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 cerinţele, care derivă din gestionarea schimbărilor

cerinţelor clientului;
6. Riscuri de estimare, derivate din estimările managerilor privind
caracteristicile şi resursele necesare pentru construirea sistemului.
Tabelul 11.3 prezintă câteva exemple de riscuri posibile din fiecare

categorie.
Tabelul 11.3. Riscuri şi tipuri de risc

Tipul de risc Riscuri posibile
Sistemul de baze de date utilizat nu poate efectua un număr
suficient de tranzacţii pe secundă, conform cerinţelor.
Tehnologia
Componentele software care ar trebui reutilizate conţin defecte
care le limitează funcţionalitatea
Este imposibilă recrutarea de personal având calificarea dorită.
Personalul cheie este bolnav şi indisponibil în momentele
Personalul
critice.
Instruirea personalului este necesară, dar nu se poate efectua.
Organizaţia este restructurată astfel încât se schimbă
managementul responsabil pentru proiect.
Organizaţia
Problemele financiare ale organizaţiei impun reducerea
bugetului proiectului.
Codul generat de instrumentele CASE nu este eficient.
Instrumentele
Instrumentele CASE nu pot fi integrate.
Sunt propuse schimbări ale cerinţelor care necesită modificări
Cerinţele majore ale arhitecturii.
Clienţii nu înţeleg impactul pe care îl au schimbările cerinţelor.
Timpul necesar pentru dezvoltarea produsului software este
subapreciat.
Estimările
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 estimări nu sunt simple, ci se bazează pe
experienţa anterioară. De aceea, managerii experimentaţi sunt în general
cele mai potrivite persoane pentru a face analiza.
Valoarea aşteptată (engl. “expected value”) este o metodă prin care
se combină probabilitatea şi impactul unui risc. Valoarea aşteptată
reprezintă produsul dintre probabilităţi şi efecte, măsurate în bani, zile de
lucru sau orice altă unitate de măsură convenabilă.
Cu ajutorul valorilor aşteptate se pot evalua oportunităţile şi riscurile
proiectului. Valorile aşteptate pot oferi şi o perspectivă bună asupra
efortului financiar necesar pentru eliminarea riscurilor.
De exemplu, dacă există o probabilitate de 10% a apariţiei 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
aşteptată a acestui risc este de: 0,1 5000  0,05 15000  1250 euro. Dacă
există posibilitatea evitării complete a riscului prin cheltuirea a 1000 euro,
atunci această soluţie este considerată o decizie corectă.
De multe ori, estimările 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 sortaţi după

gravitate. Tabelul 11.4 ilustrează acest proces pentru riscurile identificate în
tabelul 11.3. În acest exemplu, evaluările sunt arbitrare. În practică, este
nevoie de informaţii detaliate despre proiect, procesele de lucru, echipa de
dezvoltare şi organizaţie.
164
Tabelul 11.4. Analiza riscurilor

Risc Probabilitate Efect
Problemele financiare ale organizaţiei impun
mică catastrofal
reducerea bugetului proiectului
Este imposibilă recrutarea de personal având
mare catastrofal
calificarea dorită
Personalul cheie este bolnav şi indisponibil în
moderată serios
momentele critice
Componentele software care ar trebui reutilizate
moderată serios
conţin defecte care le limitează funcţionalitatea
Sunt propuse schimbări ale cerinţelor care
moderată serios
necesită modificări majore ale arhitecturii
Organizaţia este restructurată astfel încât se
schimbă managementul responsabil pentru mare serios
proiect
Sistemul de baze de date utilizat nu poate efectua
un număr suficient de tranzacţii pe secundă, moderată serios
conform cerinţelor
Timpul necesar pentru dezvoltarea produsului
mare serios
software este subapreciat
Instrumentele CASE nu pot fi integrate mare suportabil
Clienţii nu înţeleg impactul pe care îl au
moderată suportabil
schimbările cerinţelor
Instruirea personalului este necesară, dar nu se
moderată suportabil
poate efectua
Rata de reparare a defectelor este supraestimată moderată suportabil
Dimensiunea produsului software este
mare suportabil
subestimată
Codul generat de instrumentele CASE nu este
moderată nesemnificativ
eficient
Atât probabilitatea cât şi estimarea efectelor se pot modifica atunci

când devin disponibile informaţii suplimentare sau după ce se
implementează planurile de gestionare a riscurilor. În consecinţă, acest tabel
trebuie actualizat la fiecare iteraţie a procesului de management al riscului.
După ce riscurile au fost analizate şi prioritizate, trebuie determinate
riscurile cele mai importante, pe baza combinaţiei probabilităţii de apariţie
165
cu efectele generate. Se recomandă ca riscurile catastrofale să fie luate

întotdeauna în considerare, la fel şi riscurile serioase cu probabilitate de
apariţie moderată, mare sau foarte mare. De exemplu, în tabelul 11.4 ar
trebui consideraţi 8 factori de risc, cei cu consecinţe catastrofale sau
serioase.
Numărul de factori de risc trebuie să fie gestionabil. Un număr foarte
mare ar presupune colectarea unei cantităţi prea mari de informaţii. Numărul
optim diferă de la proiect la proiect, însă Boehm recomandă selectarea
primilor 10 factori de risc, în ordinea importanţei.
11.5. Planificarea gestionării riscurilor
În această fază, se iau în calcul factorii de risc cheie descoperiţi

anterior şi se identifică strategiile pentru gestionarea lor. Nici acest proces
nu este unul simplu şi se bazează pe gândirea şi experienţa managerilor.
Tabelul 11.5 arată câteva strategii posibile pentru factorii de risc din tabelul
11.4. Aceste strategii pot fi incluse în 3 categorii:
1. Strategii de evitare: determină scăderea probabilităţii de apariţie 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ă măsurile care
trebuie luate atunci când apariţia unei situaţii de criză este
inevitabilă, de exemplu strategia pentru problemele financiale ale
organizaţiei.
166
Tabelul 11.5. Strategii de gestionare a riscurilor

Risc Strategie de gestionare
Pregătirea unui raport de informare pentru managementul
Probleme financiare
superior care să arate contribuţia foarte importantă a
ale organizaţiei
proiectului asupra scopurilor comerciale
Avertizarea clientului că vor exista posibile dificultăţi şi
Probleme de recrutare întârzieri, investigarea achiziţionarii de componente gata
făcute
Reorganizarea echipei astfel încât activităţile să se
Îmbolnăvirea
suprapună mai mult şi deci membrii echipei să înţeleagă
personalului
mai bine munca celorlalţi
Înlocuirea posibilelor componente defecte cu alte
Componente defecte componente achiziţionate care funcţionează
corespunzător
Stabilirea informaţiilor de trasabilitate pentru a evalua
Schimbări ale
impactul schimbărilor cerinţelor, maximizarea
cerinţelor
abstractizării arhitecturii
Pregătirea unui raport de informare pentru managementul
Restructurarea
superior care să arate contribuţia foarte importantă a
organizaţiei
proiectului asupra scopurilor comerciale
Performanţele
Investigarea posibilităţii de a cumpăra un sistem de baze
sistemului de baze de
de date mai performant
date
Subestimarea timpului Investigarea posibilităţii de a cumpăra componente gata
de dezvoltare făcute ş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 creşte şi dacă efectele lor
posibile se modifică. De multe ori, acestea nu se pot observa direct şi deci
trebuie luaţi în calcul alţi factori care ar putea influenţa probabilitatea şi
impactul riscurilor, factori care depind de tipurile de risc. Tabelul 11.6
prezintă câteva exemple de factori utili în estimarea tipurilor de risc.
Monitorizarea riscurilor trebuie să fie un proces continuu şi la fiecare
167
întâlnire pentru discutarea progresului proiectului, trebuie să se discute

separat şi factorii de risc cheie.
Tabelul 11.6. Factori de risc

Tipul de risc Indicatori potenţiali
Livrarea cu întârziere a hardware-ului sau software-ului de
Tehnologia
suport, raportarea a numeroase probleme legate de tehnologie
Moralul prost al personalului, relaţiile tensionate între membrii
Personalul
echipei, disponibilitatea altor posturi
Organizaţia Zvonuri, pasivitatea managementului superior
Reticenţa membrilor echipei de a folosi instrumentele CASE,
Instrumentele plângeri legate de astfel de instrumente, cereri pentru staţii de
lucru mai puternice
Numeroase cereri de schimbare a cerinţelor, nemulţumiri ale
Cerinţele
clientului
Eşecul respectării graficului de lucru stabilit, eşecul rezolvării
Estimările
defectelor raportate
168
Capitolul 12
Analiza deciziilor
12.1. Introducere
Cele mai multe persoane îşi desfăşoară activitatea de zi cu zi fără a

lua decizii. Acestea reacţionează la evenimente, fără a-şi acorda timp să
decidă asupra lor. Când telefonul sună şi dacă sunt disponibile, ridică
receptorul şi răspund. În aceste situaţii, ele nu decid, ci doar lucrează. Cu
toate acestea, uneori au nevoie să ia decizii. Dacă trebuie să angajeze pe
cineva şi există mai mulţi candidaţi, trebuie să ia o decizie.
Spre deosebire de urmarea unei rutine, cineva ia o decizie atunci
când are mai multe direcţii pe care le poate urma. A decide înseamnă a
ajunge la o soluţie care pune capăt incertitudinii sau disputei legate de ceea
ce trebuie făcut. O decizie se ia atunci când modul în care se poate acţiona
este selectat dintr-o serie de alternative. Mai formal, o decizie are
următoarele componente:
 O mulţime de alternative sau opţiuni;

 Fiecare alternativă conduce la o serie de consecinţe pe care
decidentul nu le poate controla;
 Decidentul este nesigur în legătură cu ceea ce s-ar putea întâmpla;
 Decidentul are diferite preferinţe cu privire la rezultate asociate cu
diversele consecinţe;
 O decizie implică alegerea între rezultate incerte cu valori diferite.
Analiza deciziilor este procesul de separare a unei decizii complexe

în părţile sale componente şi reconstituirea întregii decizii prin folosirea
unei formule matematice. Este o metodă de a ajuta decidenţii 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 număr de posibile acţiuni, Ai, dintre care va fi selectată una;

 un număr de evenimente sau „stări ale naturii”, Sj, din care oricare
poate avea loc;
 valoarea, profitul sau consecinţa, Pij, pentru decident, de realizare a
uneia din acţiunile disponibile, având în vedere posibilele stări ale
naturii;
 criteriul în funcţie de care decidentul alege între acţiunile alternative.
Tabelul 12.1. Matricea profiturilor

Stările naturii
S1 S2 S3 S4 S5
A1 P11 P12 P13 P14 P15
Acţiunile A2 P21 P22 P23 P24 P25
A3 P31 P32 P33 P34 P35
12.2. Decizii în condiţii de certitudine
12.2.1. Analiza Pareto
Analiza Pareto este o tehnică foarte simplă care ajută la alegerea

celei mai eficace schimbări. Foloseşte principiul Pareto, a cărui idee de bază
este că prin realizarea a 20% din volumul de lucru se poate genera 80% din
avantajul realizării întregii lucrări. Analiza Pareto este o tehnică formală
pentru găsirea schimbărilor care vor aduce cele mai mari beneficii. Este utilă
atunci când concurează mai multe moduri în care se poate acţiona.
170
Modul de folosire
1. Pentru a folosi acest instrument, se notează o listă de schimbări care

s-ar putea realiza. Dacă este o listă lungă, se grupează în schimbări
înrudite;
2. Apoi se acordă un scor fiecărui articol sau fiecărui grup. Metoda de
acordare a punctajului depinde de problema care trebuie rezolvată.
De exemplu, dacă se doreşte mărirea profitului, se vor puncta
opţiunile pe baza profitului pe care fiecare grup l-ar putea genera.
Dacă se încearcă creşterea satisfacţiei clientului, se poate stabili
punctajul pe baza numărului de plângeri 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 rezolvării;
4. Opţiunile cu punctajul cel mai mic probabil nu vor merita să fie
rezolvate; rezolvarea acestora ar putea costa mai mult decât soluţia
în sine.
Exemplu
Un manager se ocupă de reabilitarea unui centru de asistenţă. El îşi

propune să afle de ce clienţii sunt de părere că serviciul nu este bun. Astfel,
primeşte următoarele comentarii de la clienţi:
1. Telefoanele sunt preluate după multe tonuri de apel;

2. Personalul pare distras şi sub presiune;
3. Inginerii nu par a fi bine organizaţi. Au nevoie de o a doua vizită
pentru a aduce şi alte piese de schimb, deci clienţii trebuie să-şi ia
mai mult timp liber pentru a fi prezenţi când are loc cea de-a doua
vizită;
4. Clienţii nu ştiu când va avea loc cea de-a doua vizită, ceea ce îi
determină să fie prezenţi întreaga zi în aşteptarea 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

funcţie de numărul de plângeri şi ordonează lista:
 Scăpări în instruirea personalului: punctele 5 şi 6 – 51 plângeri;

 Personal insuficient: punctele 1, 2 şi 4 – 21 plângeri;
 Organizare şi pregătire deficitare: punctul 3 – 2 plângeri.
În urma analizei Pareto, managerul poate observa că majoritatea

problemelor (69%) pot fi rezolvate prin îmbunătăţirea abilităţilor
personalului. Odată rezolvat acest lucru, ar fi inutilă creşterea numărului de
membri ai personalului. Alternativ, cu cât membrii personalului sunt mai
capabili să rezolve problemele prin intermediul telefonului, este posibil ca
necesitatea de mărire a personalului să se diminueze. Se observă că întrucât
există mai puţine comentarii în legătură cu deficienţele de organizare şi
pregătire, 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 stătătoare, în loc să-şi irosească
eforturile încercând atât instruirea cât ş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 lângă faptul că scoate în evidenţă cea mai
importantă problemă de rezolvat, oferă de asemenea un punctaj care arată
cât de severă este aceasta.
12.2.2. Analiza comparării perechilor
Analiza comparării perechilor este utilă pentru determinarea

importanţei relative a unor opţiuni, mai ales atunci când 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 soluţiei
care aduce cel mai mare profit. De asemenea, permite stabilirea priorităţilor
atunci când apar cerinţe contradictorii asupra resurselor.
Este de asemenea un instrument ideal pentru „a compara merele cu
perele”, opţiuni 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 decât alegerea unui sistem IT din trei
variante posible, de exemplu.
Modul de folosire
1. Se notează opţiunile care se vor compara. Se atribuie o literă fiecărei

opţiuni;
2. Se marchează opţiunile sub formă de cap de tabel pe linii şi coloane;
3. Celulele din tabel unde se compară o opţiune cu ea însăşi sunt
blocate;
4. Celulele din tabel în care apar comparaţii duplicate sunt de asemenea
blocate;
5. În cadrul celulelor rămase, se compară opţiunea de pe linie cu cea de
pe coloană. Pentru fiecare celulă, se decide care dintre cele două
opţiuni este mai importantă. Se notează litera celei mai importante
opţiuni în celulă şi se punctează diferenţa de importanţă de la 0
(nicio diferenţă) la 3 (diferenţă majoră);
6. În final, se calculează totalul tuturor valorilor pentru fiecare opţiune.
Aceste rezultate se pot converti în procentaje din scorul total.
Exemplu
Un om de afaceri studiază căile prin care să-şi extindă afacerea. Are

resurse limitate, dar şi următoarele opţiuni:
 Să se extindă pe pieţele externe;

 Să se extindă pe pieţele interne;
 Să îmbunătăţească relaţiile cu publicul;
 Să asigure creşterea calităţii produselor.
La început, se realizează tabelul pentru analiza comparării

perechilor. Apoi se compară opţiunile, se notează litera celei mai importante
opţiuni şi se calculează diferenţa de importanţă (tabelul 12.2).
173
Tabelul 12.2. Analiza comparării perechilor
În final, se adună valorile pentru A, B, C, D şi se converteşte fiecare

valoare într-un procentaj. Se obţin următoarele totaluri:
 A = 3 (37,5%);
 B = 1 (12,5%);
 C = 4 (50%);
 D = 0.
În acest caz, lucrul cel mai important este să se îmbunătăţească

relaţiile cu publicul (C) şi apoi să se abordeze pieţele de export (A).
Calitatea nu are o prioritate mare, probabil că este deja bună.
Analiza comparării perechilor este o modalitate utilă de a cântări
importanţa relativă a diferitelor acţiuni, când priorităţile nu sunt clare.
Metoda asigură un cadru de lucru pentru compararea fiecărei acţiuni cu
toate celelalte şi ajută la evidenţierea diferenţei 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
când există un număr de alternative din care se alege şi mulţi factori de luat
174
în considerare. Acest lucru face tehnica importantă pentru aproape toate

problemele de decizie în care nu există o opţiune clară sau evidentă.
Modul de folosire
Tehnica funcţionează prin listarea într-un tabel a opţiunilor pe linii şi

a factorilor care trebuie luaţi în considerare pe coloane. Apoi se stabileşte un
punctaj pentru fiecare celulă şi se calculează scorul total pentru fiecare
opţiune.
1. Mai întâi, se listează toate opţiunile pe linii şi toți factorii pe

coloane;
2. Apoi se decide importanţa relativă a factorilor de decizie ca fiind un
număr 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 aceeaşi importanţă. Valorile stabilite pot fi
evidente, dar în cazul în care nu sunt evidente, se foloseşte o metodă
precum cea a analizei comparării perechilor pentru a le estima;
3. Următorul pas este ataşarea unui punctaj fiecărei opţiuni pentru
fiecare factor de decizie. Se stabileşte un punctaj de la 0 la 5 pentru
fiecare opţiune. Se observă că nu trebuie să existe un punctaj diferit
pentru fiecare opţiune; dacă niciuna dintre ele nu este potrivită
pentru un anumit factor de decizie, atunci toate opţiunile vor avea
punctajul 0;
4. Se multiplică fiecare din punctajele de la pasul 3 cu valoarea
importanţei relative calculate la pasul 2. Se obţin astfel punctaje
pentru fiecare combinaţie opţiune-factor;
5. În final, se sumează aceste punctaje pentru fiecare dintre opţiuni. Se
alege opţiunea cu punctajul cel mai mare.
Exemplu
Un surfer entuziast doreşte să-şi schimbe maşina. Are nevoie de una

cu care nu doar să transporte planşeta şi pânzele, ci să fie bună şi pentru
călătorii de afaceri. Întotdeauna i-au plăcut maşinile sport. Însă nicio maşină
nu respectă toate cele trei preferinţe. Opţiunile sale sunt:
175
 Un SUV/4x4;
 O maşină de familie confortabilă;
 O maşină break (“station wagon” în tabelele 12.3 şi 12.4);
 O maşină 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ţă pânze şi echipamente;
 Confortul pe distanţe lungi;
 Distracţia;
 Aspectul plăcut şi calitatea.
În primul rând, se realizează tabelul de mai jos şi se stabilesc

punctaje pentru fiecare opţiune, în funcţie de cât de bine satisface aceasta
fiecare factor.
Tabelul 12.3. Analiza matricei de decizii pentru evaluarea neponderată

a modului în care fiecare tip de maşină satisface fiecare factor
Apoi se decide importanţa 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 maşină satisface fiecare factor
Se obţine un rezultat interesant: în ciuda lipsei de distracţie, o

maşină break ar putea fi cea mai bună alegere. Dacă surferul se simte încă
nemulţumit de decizie, este posibil să fi supraestimat importanţa unuia
dintre factori. Poate ar fi trebuit să dea factorului „distracţie” valoarea 7.
Analiza matricei de decizii ajută la luarea deciziilor între mai multe
opţiuni, atunci când se iau în considerare mai mulţi factori diferiţi şi este cea
mai simplă formă de analiză a deciziilor multi-criteriale. Alte metode mai
sofisticate implică o modelare complexă a diferitelor scenarii potenţiale şi
tehnici de matematică avansată.
12.2.4. Analiza costuri-beneficii
Analiza costuri-beneficii este o tehnică relativ simplă şi foarte

răspândită pentru luarea unei decizii de a realiza o schimbare. Precum
sugerează şi numele, pur şi simplu se adună valoarea beneficiilor unei
acţiuni ş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 îmbunătăţirea
infrastructurii de transport. Nu se măsoară costul distrugerii mediului
înconjurător sau beneficiul unui drum spre lucru mai rapid şi mai uşor.
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 renunţării la o
zonă verde protejată şi de asemenea valoarea unei călătorii lipsite de stres
dimineaţa către locul de muncă.
Exemplu
Un director de vânzări decide dacă să implementeze un nou sistem

de management al contactelor şi un sistem computerizat de prelucrare a
vânzărilor. Departamentul lui are doar câteva calculatoare iar angajaţii săi
nu au cunoştinţe de utilizare a calculatoarelor. El este conştient că utilizând
calculatorul, agenţii de vânzări ar fi capabili să contacteze mai mulţi clienţi
şi că ar spori încrederea şi calitatea relaţiilor cu publicul. Aceştia 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 vânzari: 15.000 $;
 Costuri de pregătire:
o Introducere în calculatoare – 8 persoane: 400 $ fiecare;
178
o Abilităţi de utilizare – 8 persoane: 400 $ fiecare;

o Sistem suport de vânzări – 12 persoane: 700 $ fiecare;
 Alte costuri:
o Timp pierdut: 40 zile-om, 200 $ / zi;
o Vânzări pierdute din cauza întreruperii activităţii:
estimativ 20.000 $;
o Vânzări pierdute din cauza ineficienţei din primele
luni: estimativ 20.000 $;
 Cost total: 114.000 $.
Beneficii:
 Triplarea capacităţii de contactare a clienţilor: estimativ
40.000 $ / an;
 Abilitate de susţinere a campaniilor de vânzări prin telefon:
estimativ 20.000 $ / an;
 Sporirea eficienţei şi încrederii: estimativ 50.000 $ / an;
 Serviciu de relaţii cu publicul îmbunătăţit: estimativ
30.000 $ / an;
 Acurateţe mai mare de informare a publicului: estimativ
10.000 $ / an;
 Abilitate crescută de a se ocupa de efortul de vânzări:
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 investiţiei se poate utiliza

diagrama pragului de rentabilitate, descrisă în capitolul 3, Justificarea
financiară a proiectului.
Inevitabil, estimările beneficiilor aduse de noul sistem sunt
subiective. În ciuda acestui fapt, directorul de vânzări 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 utilizând 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 apărea inevitabil un element
suplimentar de subiectivitate în cadrul procesului.
12.3. Decizii în condiţii de incertitudine
Când decidentul trebuie să aleagă o acţiune din mai multe posibile,

repercusiunile câtorva acţiuni, dacă nu a tuturor, vor depinde în general de
evenimente incerte şi de acţiuni viitoare care se vor prelungi pe termen lung.
Datorită incertitudinilor, acesta trebuie:
 Să inventarieze toate opţiunile viabile disponibile pentru a se

informa, a experimenta şi a acţiona;
 Să enumere toate evenimentele care pot să apară;
 Să organizeze toate informaţiile pertinente şi alegerile sau
presupunerile făcute;
 Să ordoneze consecinţele rezultate din cursurile diferite ale
acţiunilor;
 Să estimeze probabilităţile de apariţie ale evenimentelor incerte.
12.3.1. Criteriul Laplace
Criteriul Laplace, al raţiunii insuficiente, susţine următorul lucru:

dacă nu există informaţii cu privire la probabilităţile diverselor rezultate, se
poate considera că aceste probabilităţi sunt egale. În consecinţă, dacă există
n rezultate posibile, probabilitatea fiecăruia este de 1 / n . De asemenea,
această abordare sugerează că decidentul calculează profitul aşteptat al
fiecărei alternative şi alege opţiunea cu cea mai mare valoare. Utilizarea
valorilor aşteptate distinge această abordare de criteriile care folosesc
valorile extreme ale beneficiilor. Această caracteristică face ca abordarea să
fie similară cu luarea deciziilor în condiţii de risc. În tabelul 12.5, prima
alternativă este mai bună atunci când profitul aşteptat se calculează cu stări
echiprobabile.
180
Tabelul 12.5. Ilustrarea criteriului Laplace

S1 S2 S3 S4 Profitul
Acţiuni / Stări
(Pr = 0.25) (Pr = 0.25) (Pr = 0.25) (Pr = 0.25) aşteptat
A1 20 60 -60 20 10
A2 0 20 -20 20 5
A3 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 opţiunea cu cel mai bun rezultat. Acest criteriu este atractiv pentru
persoanele care îşi asumă riscuri, fiind atrase de profiturile mari. De
asemenea, abordarea este atrăgătoare şi pentru cei cărora le plac pariurile,
dar care pot suporta pierderi fără inconveninţe majore. În tabelul 12.6, prima
alternativă este cea câştigătoare.
Tabelul 12.6. Ilustrarea criteriului maximax

Profitul
Acţiuni / Stări S1 S2 S3 S4
maxim
A1 20 60 -60 20 60
A2 0 20 -20 20 20
A3 50 -20 -80 20 50
12.3.3. Criteriul maximin
Criteriul maximin reprezintă o abordare pesimistă, afirmând că

decidentul analizează doar profiturile minime date de alternative şi o alege
pe aceea al cărei rezultat este cel mai puţin slab. Criteriul este potrivit pentru
decidenţii precauţi, care vor să se asigure că în cazul unui eveniment
defavorabil, există măcar un profit minim garantat. Abordarea se justifică
datorită faptului că beneficiile mici pot să aibă probabilităţi mai mari de
apariţie sau că profitul minim poate conduce la un rezultat extrem de
defavorabil. În tabelul 12.7, a doua alternativă este câştigătoare.
181
Tabelul 12.7. Ilustrarea criteriului maximin

Profitul
minim
A1 20 60 -60 20 -60
A2 0 20 -20 20 -20
A3 50 -20 -80 20 -80
12.3.4. Criteriul Hurwicz
Această abordare încearcă să găsească un echilibru între criteriile

maximax şi maximin, sugerând 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ă îndrăzneaţă va folosi α = 0, fapt ce reduce criteriul la
maximax.
În tabelul 12.8 este prezentată aplicarea acestui criteriu cu α = 0,4.
Prima alternativă este câștigătoare.
Tabelul 12.8. Ilustrarea criteriului Hurwicz

Profitul
(α = 0,4)
A1 20 60 -60 20 12
A2 0 20 -20 20 4
A3 50 -20 -80 20 -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 când profitul alternativei selectate este mai mic decât cel
maxim care ar fi putut fi atins în situaţia respectivă. Regretul corespunzător
unui anumit profit Pij este definit ca Rij = Pjmax – Pij, unde Pjmax este cel mai
mare beneficiu care poate fi obţinut în starea Sj. Această definiţie a
regretului permite decidentului să transforme matricea profiturilor într-o
matrice a regretelor. Decidentul ia în considerare regretul maxim
corespunzător fiecărei 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 comparaţie cu celelalte alternative,
indiferent de situaţia ivită. Abordarea este potrivită mai ales pentru un
decident care ştie că o parte din competitorii săi se confruntă cu
circumstanţe identice sau similare şi care este conştient că performanţele
sale vor fi evaluate în comparaţie cu cele ale concurenţilor săi. Criteriul se
aplică aceleiaşi situaţii decizionale, transformând matricea profiturilor în
matricea regretelor. În tabelul 12.9, prima alternativă este câştigătoare.
Tabelul 12.9. Ilustrarea criteriului Savage

Regretul
maxim
A1 30 0 40 0 40
A2 50 40 0 0 50
A3 0 80 60 0 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 câştigătoare.
183
12.4. Decizii în condiţii de risc
12.4.1. Arbori de decizie
Arborii de decizie sunt instrumente utile pentru reprezentarea

problemelor decizionale cu mai mulţi paşi. Acţiunile posibile din orice
moment sunt prezentate ca ramuri care pornesc dintr-un punct decizional,
reprezentat de un pătrat mic. Diversele rezultate posibile ale unei acţiuni
apar ca ramuri ce pornesc dintr-un punct şansă, marcat printr-un nod sub
forma unui cerc, la capătul ramurii corespunzătoare unei acţiuni. Fiecărei
ramuri îi este asociată o probabilitate de la un punct şansă spre un rezultat.
Valorile asociate fiecărui rezultat sunt reprezentate la capătul ramurilor
corespunzătoare.
Figura 12.1. Structura unui arbore de decizie
După construirea arborelui, se poate identifica acţiunea recomandată

de criteriul valorii aşteptate, prin folosirea metodelor de înfăşurare înapoi şi
retezare (elagaj). Înfăşurarea înapoi constă în calcularea valorii aşteptate
pentru fiecare nod. Se începe cu nodurile care nu au succesori, cele mai
îndepărtate în viitor. Pentru un nod decizional fără niciun succesor de tip
şansă nu există incertitudine la alegerea acţiunii. Valoarea nodului
decizional reprezintă profitul acţiunii respective. Unui nod şansă fără niciun
succesor de tip decizional i se atribuie valoarea aşteptată a profiturilor
asociate ramurilor care ies din el.
Pentru un nod decizional ai cărui succesori şansă au fost evaluaţi, se
alege acţiunea care conduce către nodul şansă cu cel mai mare profit. Toate
celelalte acţiuni 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 capătul acţiunii selectate. Pentru
un nod şansă ai cărui succesori decizionali au fost evaluaţi, se calculează
valoarea aşteptată a tuturor nodurilor decizionale succesoare.
Acest proces se repetă în mod sistematic până când se evaluează
nodul decizional aflat în rădăcina arborelui, ce reprezintă decizia care se va
lua. Acele părţi ale arborelui de decizie care pot fi atinse pornind din
rădăcină şi urmând ramurile care nu au fost retezate oferă o soluţie 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 mulţi din utilizatorii iniţiali îl vor considera nesatisfăcător,
cererea ar putea să scadă în continuare spre un nivel mic. Ca alternativă,
cererea iniţială mare ar putea indica posibilitatea unui volum de piaţă ridicat
pe termen lung. Dacă cererea este iniţial mare şi rămâne astfel, iar compania
nu are o capacitate suficientă în primii 2 ani, cu siguranţă pe piaţă vor fi
introduse produse concurente de către alte companii.
Dacă iniţial compania construieşte o fabrică mare, trebuie să o
susţină timp de 10 ani, indiferent de cererea de pe piaţă. În cazul în care
construieşte o fabrică mică, există posibilitatea extinderii ei după 2 ani,
opţiune ce va fi aleasă numai dacă cererea este mare în perioada de început.
Dacă se construieşte iniţial o fabrică mică şi cererea e scăzută la început,
compania va menţine producţia şi va obţine un profit bun din volumul mic
de produse fabricate.
Informaţii de piaţă: Se estimează că va exista următoarea evoluţie a

cererii:
 Iniţial ridicată, pe termen lung ridicată: 60%;

 Iniţial ridicată, pe termen lung scăzută: 10%;
 Iniţial scăzută, în continuare scăzută: 30%;
 Iniţial scăzută, pe termen lung ridicată: 0%.
185
Venit anual:
 O fabrică mare cu un volum de piaţă ridicat va avea un câştig anual

de 1 m£ (1 milion de lire), timp de 10 ani;
 O fabrică mare cu un volum de piaţă scăzut va avea un câştig de
numai 0,1 m£ pe an;
 O fabrică mică având cererea de piaţă scăzută 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 iniţiale cu cerere mare, dar, datorită concurenţei, acesta va
scădea până la 0,25 m£ pe termen lung, dacă cererea va fi în
continuare mare;
 Dacă o fabrică iniţial mică ar fi extinsă după 2 ani ca urmare a
cererii ridicate, ar avea un câştig anual de 0,7 m£ pentru următorii 8
ani;
 Dacă o fabrică iniţial mică ar fi extinsă după 2 ani, dar cererea
ridicată nu ar continua, venitul anual estimat pentru următorii 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 iniţial de 1,3 m£ şi unul adiţional de
2,2 m£ în cazul extinderii după 2 ani.
Figura 12.2. Exemplu de arbore de decizie
186
Deoarece o situaţie corespunzătoare unui volum de piaţă iniţial

scăzut, 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 obţine prin scăderea costului de capital în valoare de 3 m£ din
venitul total de 10 m£. Valorile profiturilor nete corespunzătoare celorlalte
situaţii se calculează într-o manieră similară.
Ramura de sus care iese din nodul şansă aflat la capătul acţiunii
iniţiale build big corespunde unei situaţii în care volumul este mare pe
întreaga perioadă de 10 ani. Probabilitatea acestei ramuri este preluată direct
din informaţiile de piaţă. Probabilităţile celorlalte două ramuri care ies din
acelaşi nod şansă („iniţial ridicat, pe termen lung scăzut” şi „iniţial scăzut,
pe termen lung scăzut”) se obţin în mod similar.
Ramurile care pornesc din nodul şansă aflat la capătul acţiunii
iniţiale build small corespund volumelor de piaţă iniţial ridicat, respectiv
iniţial scăzut. Probabilităţile pot fi obţinute, din nou, din informaţiile de
piaţă.
Probabilităţile nodurilor şansă care urmează acţiunilor expand şi
don’t expand sunt ceva mai complicate. Să considerăm ramura de sus care
porneşte din nodul şansă ce urmează după expand. Aceasta corespunde unui
volum de piaţă mare pe termen lung, în condiţiile unui volum ridicat în
primii 2 ani. Probabilitatea acestei situaţii este:
În mod similar, ramura de jos care porneşte din nodul şansă ce

urmează după expand corespunde unui volum de piaţă scăzut pe termen
lung, în condiţiile unui volum ridicat în primii 2 ani. Aceasta are următoarea
probabilitate:
187
Ramurile care ies din nodul şansă ce urmează după don’t expand au
probabilităţi similare.
Nodul şansă aflat după build big are următoarea valoare aşteptată:
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 don’t expand au valorile

2,27 m£ şi 1,76 m£.
Luând în considerare punctul decizional aflat la sfârşitul celui de-al
doilea an, în contextul unei fabrici iniţial mici şi al unui volum de piaţă
iniţial mare, sunt posibile două acţiuni: expand şi don’t expand. Aceste
acţiuni conduc spre noduri şansă cu valori aşteptate de 2,27 m£ şi respectiv
1,76m£. Un profit aşteptat de 2,27 m£ este preferabil unuia de 1,76 m£,
astfel încât expand este ales în detrimentul lui don’t expand. Acest lucru
înseamnă că, în cazul în care compania construieşte iniţial o fabrică mică şi
volumul este mare, atunci conform criteriului valorii aşteptate, compania ar
trebui să extindă fabrica după 2 ani. Ramura don’t expand este retezată, iar
nodului decizional i se atribuie valoarea aşteptată de 2,27 m£.
Acum, nodul şansă de după build small poate fi evaluat. De aici
pornesc două ramuri, corespunzătoare celor două situaţii: initially high
volume şi initially low volume. Ramura superioară, cu o probabilitate de 0,7,
ne conduce spre un nod decizional căruia 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 aşteptată a acestui nod şansă este:
2,27 ∙ 0,7 + 2,7 ∙ 0,3 = 1,59 + 0,81 = 2,4 m£.
La final, analizăm nodul aflat în rădăcina arborelui. Există două

acţiuni posibile: build big şi build small. Prima conduce spre un nod şansă
cu o valoare aşteptată de 3,58 m£. Cea de-a doua conduce spre nodul şansă
discutat în paragraful anterior, cu valoarea aşteptată de 2,4 m£. Acţiunea
build big ne conduce către o valoare aşteptată mai mare, în consecinţă,
aceasta este acţiunea preferată. Acţiunea build small este retezată, iar
nodului decizional i se atribuie valoarea aşteptată de 3,58 m£.
188
Aşadar, recomandarea este ca, din start, compania să construiască o

fabrică mare. Profitul net aşteptat în acest caz este de 3,58 m£.
189
Referinţe
[1] Albrecht, A. J. (1981). Function points as a measure of productivi-

ty, 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, O’Reilly.
[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, Prentice-
Hall.
[8] Duncan, W. R. (1996). A Guide to the Project Management Body
of Knowledge, Project Management Institute, PMI Publishing Divi-
sion.
[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 Analy-
sis: Theory, Model and Uses, Health Administration Press: Ann
Arbor, Michigan.

[12] Halstead, M. H. (1977). Elements of Software Science, North-

Holland Publishing Company.
[13] Heimberg, J. D. (2006). Using a Strengths, Weaknesses, Opportu-
nities, 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 Mod-
els, Department of Computer Science, University of Calgary Alber-
ta, Canada, http://sern.ucalgary.ca/courses/seng/621/W98/ john-
sonk/cost.htm.
[16] Kmietowicz, Z. W., Pearman, A.D. (1981). Decision Theory and
Incomplete Knowledge, pp. 7-9, Gower Publishing Company Lim-
ited, Aldershot, Hampshire, England.
[17] Koontz, H., O’Donnel, 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 programării, Politehni-
um, Iaşi.
[20] LeRoi Burback, R. (1999). Software Engineering Methodology:
The WaterSluice, PhD Thesis, Stanford University, http://www-
db.stanford.edu/~burback/watersluice.
[21] Management 101 (2001). The Five Functions of Management,
http://digi.physic.ut.ee/tanel/books/project_management/ busi-
ness%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
Referinţe
[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 Devel-
opment Corp.
[25] Newell, M. W. (2002). Preparing for the Project Management
Professional Certification Exam, Second Edition, American Man-
agement Association.
[26] Norden, P. V. (1970). Useful tools for project management, in M.
K. Starr (ed.), Management of Production, Penguin Books, pp. 71-
101.
[27] Paulk, M. (1994). A Comparison of ISO 9001 and the Capability
Maturity Model for Software, Technical Report CMU/SEI-94-TR-
012, 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 Soft-
ware Systems: Concepts and Techniques, in Technical Papers of
Western Electronic Show and Convention (WesCon). , Los Ange-
les.
[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 Met-
rics, http://technology-doc.blogspot.com/2009/11/using-
descriptive-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, Pren-
tice-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 experi-
ment, https://en.wikipedia.org/wiki/Stanford_prison_experiment
[41] Wysocki, R. K. (2006). Effective Software Project Management,
Wiley.
194
View publication stats

Managementul Proiectelor Software

Încărcat de

Informații document

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

Managementul Proiectelor Software

Încărcat de

Drepturi de autor:

Formate disponibile

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.

Managementul proiectelor software - Suport de curs

Book · May 2016

The user has requested enhancement of the downloaded ﬁle.

Capitolul 1. Introducere în managementul proiectelor

Capitolul 2. Metodologii de dezvoltare a programelor

Capitolul 3. Justificarea financiară a proiectului

Capitolul 4. Managementul domeniului

Capitolul 5. Managementul timpului

Capitolul 6. Managementul costului

Capitolul 7. Managementul calităţii

Capitolul 9. Conducerea echipei

Capitolul 11. Managementul riscului

Capitolul 12. Analiza deciziilor

Referinţe .................................................................................................................... 191

Introducere în managementul proiectelor

Managementul proiectelor devine rapid metoda de management

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

Dacă nu ar exista aceste părţi diferite am vorbi de o repetiţie de

1.2. Funcţiile managementului

Managementul reprezintă îndeplinirea unor obiective prin

Priveşte anticiparea situaţiilor viitoare şi determinarea celei mai

1. Determinarea resurselor necesare;

În funcţie de amploare sau sfera de acţiune, se pot evidenţia trei

1. Planificarea strategică: Determină obiectivele majore ale

Organizarea este funcţia managementului care îmbină resursele

1. Să determine ce activităţi de lucru trebuie făcute pentru atingerea

4. Să proiecteze o ierarhie a relaţiilor pentru luarea deciziilor.

Procesul de organizare poate fi văzut ca format din cinci paşi:

1. Studierea planurilor şi scopurilor: Planurile dictează scopurile şi

1.2.3. Selecţia personalului

Această funcţie priveşte recrutarea, selecţionarea, instruirea şi

identificarea, atragerea şi păstrarea personalului calificat pentru a ocupa

1. Planificarea resurselor umane: Trebuie să asigure faptul că nevoile

8. Încetarea relaţiilor de muncă: Managementul trebuie să fie

După crearea planurilor, structurii organizaţiei şi completarea

Ultima funcţie a managementului se referă la evaluarea

1. Stabilirea standardelor de performanţă utilizate pentru a măsura

producţie, la materiale, echipamente, componente şi

1.3. Noţiuni de bază

În cele ce urmează, vom preciza câteva definiţii esenţiale pentru

 Plan: Graficul datelor de începere şi terminare ale activităţilor

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

1.3.2. Triunghiul managementului de proiect

Managementul proiectelor este adesea rezumat într-un triunghi

1. Proiectele trebuie să fie livrate la timp.

Figura 1.1. Triunghiul managementului de proiect

Dacă timpul sau banii ar fi nelimitaţi, sau cerinţele ar fi nule, nu ar

 Dacă se decide scăderea timpului alocat pentru finalizarea

Modificările din planul proiectului pot afecta triunghiul în diverse

Din punct de vedere al triunghiului proiectului, resursele sunt

Proiectele au întotdeauna resurse limitate, dar uneori există proiecte

1.3.3. Ciclul de viaţă al unui proiect

Proiectele de orice dimensiune, mici sau mari, pot fi gestionate

Figura 1.2. Ciclul de viaţă al unui proiect

Acesta conţine următoarele stadii:

 Realizarea unei analize post-implementare;

Pe durata ciclul său de viaţă, proiectul trebuie să facă faţă în

multe cauze. În primul rând, pe măsură ce se apropie de finalizarea

1.4. Managerul de proiect

Managementul proiectelor poate fi o profesie, o ocupaţie, un rol sau

mai puţin, de care echipa se poate lipsi. Eficienţa şi simplitatea trebuie

 o ştiinţă deoarece presupune înţelegerea proceselor, instrumentelor şi

Instrumentele şi tehnicile de management de proiect sunt încercate şi