Sunteți pe pagina 1din 19

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

MA MANAGEMENTUL PROIECTELOR DE DEZVOLTARE SOFTWARE CONSIDERAII GENERALE Constana BODEA, erban CONSTANTIN1
Rezumat: Managementul proiectelor reprezint aplicarea unui sistem de proceduri, practici, tehnologii i cunotine n scopul planificrii, organizrii, coordonrii, monitorizrii i controlului proceselor de execuie. Universalitatea managementului este un concept care permite aplicarea cunotinelor manageriale n orice domeniu, n particular pentru proiectele de inginerie a programrii. Un studiu recent a demonstrat c peste 70% dintre organizaiile productoare de software i desfoar activitatea prin metode ad-hoc, fr s aplice metode de determinare a costurilor, de planificare sau evaluare a calitii software. Fiecare manager conduce prin folosirea metodelor care i-au folosit n decursul proiectelor anterioare. Tehnicile de ingineria programrii precum analiza cerinelor, verificarea i documentarea sunt reduse sau eliminate atunci cnd costurile proiectului cresc, cnd termenul limit se apropie sau cnd beneficiarul cere mai mult funcionalitate, fr a acorda un buget mai mare. Aceste aspecte relevate nu fac dect s adnceasc criza software. Cuvinte-cheie: Proiecte de dezvoltare software, managementul proiectelor, funcii i activiti de management. 1. Funcii i activiti manageriale Modelul clasic al managementului (figura 1) clasific activitile de conducere n cinci componente sau funcii separate i anume: planificarea, organizarea, coordonarea, alocarea personalului, monitorizarea i controlul. Tabelul 1 cuprinde detalierea acestor funcii.
Management

Planificare Organizare

Antrenare Coordonare

Control/ Evaluare

Fig. 1. Modelul clasic al managementului

Academia de Studii Economice din Bucureti., bodea@ase.ro

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004 Tabel 1 Funcia Planificare Organizare Coordonare Antrenare Control Evaluare / Descriere Predeterminarea unui curs al aciunilor pentru ndeplinirea obiectivelor organizaiei. Definirea relaiilor dintre unitile de lucru i delegarea autoritii pentru ndeplinirea obiectivelor. Armonizarea deciziilor i aciunilor membrilor echipei Crearea unei atmosfere care va asista i motiva personalul pentru atingerea rezultatelor dorite. Stabilirea, msurarea i evaluarea performanelor i activitilor, comparativ cu obiectivele planificate.

2. Planificarea unui proiect de dezvoltare software Planificarea unui proiect de dezvoltare software const n managementul activitilor care conduc la selectarea cursului viitor de aciune pentru proiect i a unui program pentru ndeplinirea acestor aciuni. Planificarea implic specificarea scopurilor i a obiectivelor unui proiect i a strategiilor, politicilor, planurilor i procedurilor ntreprinse pentru atingerea lor. Fiecare proiect trebuie s porneasc cu un plan eficient, deoarece planificarea este absolut necesar n condiiile de risc i incertitudine prezente n viaa real. Planificarea concentreaz atenia asupra scopului proiectului, asupra aciunilor necesare pentru atingerea lor i asupra riscurilor i problemelor poteniale care pot interfera cu buna desfurare a proiectului. Printre problemele care pot fi ntmpinate n timpul planificrii unui proiect informatic se numr: Cerinele software sunt adesea incomplete sau incorecte. Multe specificaii privind cerinele sunt instabile i sunt subiectul unor modificri frecvente i majore. Planificarea este adesea interpretat ca o pierdere de timp, deoarece planurile se modific oricum n cursul proiectului. Costurile i termenele planificate nu sunt revizuite cnd apar schimbri ale cerinelor sau ale mediului i adesea sunt fundamentate pe cerine de marketing i nu pe cerinele sistemului. Este dificil de estimat dimensiunea i complexitatea unui proiect software n vederea evalurii reale a costurilor i termenelor. Factorii de risc nu sunt evaluai corespunztor. Majoritatea organizaiilor care produc software nu folosesc datele nregistrate cu ocazia unor proiecte trecute. Companiile nu stabilesc politici sau procese pentru dezvoltarea de software. n ceea ce privete riscurile, acestea sunt acceptabile atta timp ct efectele lor sunt cunoscute sau previzibile. Din nefericire, de multe ori planurile sunt bazate pe simple presupuneri ale managerilor. n aceste cazuri, cnd un anumit risc se concretizeaz, echipa de programatori i managementul sunt luai prin surprindere, avnd ca rezultat depirea costurilor i a termenelor de livrare. Politicile sunt instrumente ale managementului executiv, iar multe organizaii funcioneaz fr a avea politici adecvate pentru dezvoltarea i ntreinerea software-ului. Aceasta are drept efect lipsa controlului asupra mediului proiectului. n tabelul 2 sunt prezentate activitile care trebuie ndeplinite de ctre managerii de proiect n procesul de planificare.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004 Tabel 2 Activitatea Definirea obiectivelor i scopurilor Dezvoltarea strategiilor Dezvoltarea politicilor Previziunea situaiilor viitoare Evaluarea riscului Determinarea cursurilor posibile de aciune Luarea deciziilor Definirea regulilor i procedurilor Dezvoltarea planurilor proiectului Stabilirea bugetelor Documentarea planurilor proiectului Explicaie Determinarea rezultatelor dorite ale proiectului. Selectarea scopurilor principale ale organizaiei i dezvoltarea unui program general de aciuni pentru atingerea acestor scopuri. Luarea deciziilor pe termen lung cu privire la problemele importante pentru a furniza un cadru pentru celelalte decizii. Anticiparea evenimentelor viitoare sau presupuneri despre viitor; prognoza rezultatelor sau ateptrilor. Anticiparea posibilelor evenimente potrivnice i a problemelor; dezvoltarea planurilor alternative; prognoza rezultatelor cursurilor posibile ale aciunilor. Dezvoltarea, analiza i evaluarea diferitelor ci de conducere a proiectului. Evaluarea i selectarea celei mai bune alternative de derulare a proiectului. Stabilirea metodelor, reperelor i limitelor pentru ndeplinirea activitilor proiectului. Stabilirea politicilor, procedurilor, regulilor, activitilor i resurselor necesare pentru derularea proiectului. Alocarea costurilor estimate pentru funciile i activitile proiectului. nregistrarea deciziilor cu privire la politici, cursuri de aciune, bugete, planuri.

Managerul proiectului trebuie s utilizeze numeroase instrumente de planificarei. Tabelul 3 evideniaz o serie de planuri manageriale care pot fi aplicate oricrui proiect de dezvoltare software.
Tabel 3 Instrument de planificare Planul obiectivelor Plan strategic Politici Proceduri Explicaie Obiectivele (principale i secundare) i non-obiectivele proiectului. Abordare general a unui proiect; furnizeaz puncte de reper n vederea focalizrii ateniei i folosirii resurselor pentru atingerea obiectivelor proiectului. Directive care ghideaz luarea deciziilor i activitile proiectului. Politicile limiteaz libertatea de a lua decizii, dar induc o anumit pruden. Directive care specific metode obinuite de ndeplinire a activitilor, orientate mai mult ctre aciuni, dect ctre luarea deciziilor. Ele detaliaz modalitatea exact n care activitile unui proiect trebuie ndeplinite i permit abaterea uoar. Cerine pentru aciunile specifice, bine definite, permise sau nepermise n anumite situaii ale proiectului. Regulile nu permit abaterea. Un set interconectat de scopuri, obiective, politici, proceduri, reguli, repartizri ale activitilor, resurse i alte elemente necesare pentru a conduce un proiect software. O aseriune asupra restriciilor resurselor, exprimat n termeni cantitativi.

Reguli Planuri Bugete

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

2.1 Definirea obiectivelor proiectului Primul pas n planificarea unui proiect software l constituie determinarea obiectivelor proiectului i a resurselor necesare. Acestea presupun analiza i documentarea cerinelor sistemului software, determinarea necesitilor i constrngerilor manageriale. Constrngerile manageriale sunt adesea exprimate prin limita resurselor i a timpului. Criteriile de definire a succesului trebuie de asemenea definite. Acestea, n mod normal, includ livrarea la timp a unui sistem software care satisface cerinele i care se ncadreaz n costuri. Totui pot fi definite i alte criterii: prelungirea contractului, semnarea unui nou contract, creterea profitului marginal prin premii de ncurajare etc. Criteriile de succes pot fi ierarhizate n ordinea importanei, spre exemplu poate fi mult mai important ca proiectul s se ncadreze n timp dect n buget. 2.2 Dezvoltarea strategiilor proiectului O alt activitate este dezvoltarea i documentarea unui set de strategii manageriale pentru un proiect. Strategiile sunt definite ca obiectivele pe termen lung i metodele folosite pentru atingerea acestor obiective. Acestea sunt n general definite la nivel de organizaie, ns managerii de proiect pot avea planuri strategice n cadrul unui proiect, n particular n cazul unor proiecte de dimensiuni mari. Un exemplu de plan strategic este dezvoltarea unui nou domeniu de expertiz pentru organizaie prin dezvoltarea unui proiect n acel domeniu. 2.3 Dezvoltarea politicilor proiectului Politicile sunt decizii manageriale predeterminate. Managerii pot stabili politici pentru a oferi un cadru pentru luarea deciziilor de rutin pentru supervizorii i membrii echipelor. Spre exemplu, o politic poate fi raportarea sptmnal a situaiei proiectului. Politicile pot reduce nevoia de interaciune pentru fiecare decizie i furnizeaz o direcie pentru fiecare membru al echipei. n multe cazuri, managerii nu definesc politici noi pentru proiect, ci urmeaz politicile stabilite la nivelul organizaiei. 2.4 Previziunea situaiilor viitoare Determinarea cursurilor viitoare de aciune se bazeaz att pe starea prezent a mediului, ct i pe viziunile asupra viitorului ale managerilor de proiect. Acesta este rspunztor pentru prognoza situaiilor care pot avea impact asupra proiectului. Previziunea se face n doi pai: primul implic prezicerea mediului viitor al proiectului, iar cel de-al doilea precizeaz modul n care proiectul va rspunde viitorului prezis. Primul pas implic prevederea unor evenimente cum ar fi disponibilitatea personalului, rata inflaiei, disponibilitatea unor noi platforme hardware i impactul pe care aceste evenimente l vor avea asupra proiectului. Al doilea pas implic prezicerea consecinelor asupra proiectului, cum ar fi specificarea resurselor viitoare ale proiectului i a fondurilor suplimentare. Managerul de proiect este rspunztor pentru estimarea riscului i dezvoltarea planurilor secundare pentru contracararea acestor riscuri. 2.5 Evaluarea riscurilor proiectului Riscul este probabilitatea de apariie a unui eveniment nedorit n anumite perioade sau circumstane. Conceptul de risc cuprinde dou elemente: frecvena de apariie a evenimentului i

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

consecinele acestuia. Factorii de risc trebuie identificai, iar previziunile trebuie pregtite evideniind situaiile care pot influena negativ proiectul software. Planurile secundare specific aciuni de ntreprins n cazul n care un risc se produce. Un risc devine o problem real atunci cnd un indicator al riscului respectiv depete un nivel predefinit, spre exemplu bugetul a fost depit cu 12%, iar limita maxim admis era de 10%, prin urmare planul secundar trebuie pus n aplicare. 2.6 Determinarea cursurilor posibile de aciune n majoritatea proiectelor exist mai multe ci de conducere a unui proiect, ns nu cu costuri, termene sau riscuri egale. Este responsabilitatea managerului de proiect s examineze diferitele abordri care pot conduce la finalizarea cu succes a proiectului. Spre exemplu, o abordare poate fi foarte costisitoare n ceea ce privete personalul i tehnologia, dar poate reduce dramatic termenul de realizare. O alt abordare poate reduce dramatic att costurile, ct i termenul de realizare, dar se poate confrunta cu un risc sporit de livrare a unui sistem nesatisfctor. Managerul trebuie s examineze fiecare curs posibil i s determine avantajele, dezavantajele, beneficiile i riscurile fiecruia. 2.7 Adoptarea soluiei aplicabile Managerul proiectului, mpreun cu managementul executiv, beneficiarii i alte pri interesate, este responsabil pentru selectarea celui mai bun curs de evoluie n vederea atingerii obiectivelor proiectului. Managerul proiectului este responsabil i pentru deciziile de compromis care privesc costurile, termenele limit, proiectarea strategiilor i riscurile proiectului. Tot rspunderea managerului este aprobarea metodelor i instrumentelor, att tehnice, ct i manageriale, cu care proiectul este condus. 2.8 Definirea regulilor i procedurilor proiectului Managerul proiectului stabilete procedurile i regulile proiectului. Spre deosebire de politici, procedurile stabilesc metode comune i furnizeaz repere detaliate pentru activitile proiectului. Procedurile detaliaz modalitatea exact de realizare a unei activiti. Regulile stabilesc aciuni specifice, bine definite, permise sau nepermise ntr-o anumit situaie. O regul nu permite abateri. Spre exemplu, o regul poate fi aceea ca n sala serverelor s fie doi oameni permanent. Standardele de proces pot fi folosite pentru a stabili proceduri. Standardele de proces pot fi adoptate din standardele organizaiei sau definite pentru un proiect particular. 2.9 Dezvoltarea planurilor proiectului Un plan al proiectului specific toate aciunile necesare pentru a livra un produs software reuit. n general, planurile specific urmtoarele: Aciunile de ntreprins pentru a livra produsul software final. Aceasta presupune mprirea activitilor proiectului n fraciuni mai mici, bine precizate. Dimensiunea sistemului software. Costurile i resursele necesare pentru ndeplinirea fiecrei activiti a proiectului. Programul proiectului care specific dependenele manifestate ntre activiti i stabilete reperele proiectului.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

2.10 Stabilirea bugetului proiectului Stabilirea bugetului este procesul de determinare a costurilor activitilor identificate n planul proiectului. Managerul de proiect este responsabil pentru determinarea costurilor i alocarea bugetelor pentru activiti. Costul este numitorul comun al tuturor elementelor proiectului; prin el se pot compara cerinele de personal, tehnice etc. 2.11 Documentarea planurilor proiectului Managerul de proiect este responsabil pentru documentarea planurilor proiectului. Acesta este de asemenea rspunztor pentru pregtirea altor planuri, cum ar fi planul pentru asigurarea calitii software, planul managementului configuraiei software sau planul de testare. Planul proiectului este principalul mijloc de comunicare cu alte entiti care interacioneaz cu proiectul respectiv. 3. Organizarea unui proiect de dezvoltare software Organizarea unui proiect dezvoltare software presupune dezvoltarea unei structuri organizatorice eficiente i efective pentru repartizarea i ndeplinirea activitilor proiectului, precum i stabilirea relaiilor de autoritate i responsabilitate. Organizarea implic detalierea activitilor necesare pentru atingerea scopului unui proiect i aranjarea acestora n uniti logice. Scopul organizrii este de a concentra eforturile multiple asupra unui sigur scop. Problemele majore care apar n organizarea unui proiect de ingineria programrii sunt: Dificultatea de a determina cea mai bun structur organizatoric pentru o organizaie specific sau mediu. O structur organizatoric poate lsa nedefinite sau neclare anumite responsabiliti ale activitilor proiectului. O structur organizatoric matricial nu este acceptat de muli dintre cei care dezvolt programe. Muli dintre liderii echipelor pot executa activiti tehnice, dar pot s coordoneze i echipa. Este dificil de a determina cea mai bun structur organizatoric pentru un proiect i pentru organizaia care susine proiectul. Exist o varietate de tehnici de organizare, de la forme funcionale, la cele matriciale. Tabelul 4 evideniaz activitile care trebuie ndeplinite de ctre un manager n procesul de organizare a proiectului.
Activitate Identificarea i gruparea funciilor i activitilor proiectului Selectarea structurilor organizatorice Crearea poziiilor organizatorice Definirea responsabilitilor i autoritilor Stabilirea calificrilor necesare Documentarea deciziilor organizatorice Tabel 4 Explicaie Definirea, dimensionarea i mprirea n categorii a activitilor proiectului. Selectarea structurilor adecvate att pentru finalizarea proiectului, ct i pentru monitorizare, control, comunicare i coordonare. Stabilirea titlurilor, descrierea posturilor i definirea relaiilor ntre acestea. Definirea responsabilitilor fiecrei poziii organizatorice i acordarea autoritilor pentru ndeplinirea responsabilitilor. Definirea calificrilor care trebuie deinute de persoanele care vor ocupa fiecare poziie. Documentarea titlurilor, poziiilor, a descrierilor posturilor, responsabilitilor, autoritilor, calificrilor i a relaiilor dintre acestea.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

3.1 Identificarea i gruparea funciilor i activitilor proiectului n responsabilitatea managerului cade cunoaterea cerinelor proiectului, definirea activitilor de ndeplinit, ca i dimensionarea i gruparea acestora n entiti logice. Titlurile i entitile organizatorice sunt acordate pentru a ndeplini aceste activiti. Informaiile culese permit managerului de proiect selectarea unei structuri organizatorice pentru a controla aceste grupuri (vezi tabelul 4.5 pentru exemple de activiti identificate). Managerul de proiect trebuie de asemenea s identifice activitile conexe necesare proiectului, att cele interne, ct i cele externe. Exemple de activiti interne sunt: suport de secretariat, suport pentru procesarea de texte, monitorizare financiar, administrarea proiectului. Activiti externe pot fi: activiti legate de necesitile de transport, securitate, suport hardware etc. 3.2 Stabilirea structurii organizatorice a proiectului Dup identificarea i gruparea activitilor proiectului, managerul de proiect trebuie s selecteze o structur de organizare. Un proiect software poate fi organizat folosind una dintre urmtoarele structuri de organizare: Structura convenional de organizare: organizarea liniar. Structura de organizare a unui proiect: organizarea funcional sau matricial. Structura de tip echip: organizarea ierarhic, a programatorului ef, echipa democratic.
Activiti ale proiectului Determinarea cerinelor sistemului software mprirea i alocarea cerinelor software pe componentele sistemului Proiectarea arhitecturii software Identificarea i planificarea activitilor Stabilirea i ntreinerea interfeelor interne i externe Controlul procesului de dezvoltare a sistemului software Verificarea i validarea produselor i proceselor software Analiza componentelor software pentru produsul 1 Proiectarea componentelor produsului 1 Implementarea componentelor software ale produsului 1 Pregtirea documentaiei Verificarea i validarea suportului Aceleai activiti ca cele ale produsului 1 Pregtirea planului de verificare i validare a programelor Desfurarea activitilor de verificare i validare Pregtirea i susinerea testrii software Stabilirea planului de asigurare a calitii software Desfurarea activitilor de asigurare a calitii Documentarea rezultatelor activitilor de asigurare a calitii Tabel 5 Entiti organizatorice

Dezvoltarea sistemului software

Grupul 1 de aplicaii

Grupul 2 de aplicaii Verificare i validare software

Asigurarea calitii software

n selectarea unei structuri de organizare, este foarte important ca cerinele proiectului s se potriveasc cu punctele slabe i punctele forte ale fiecrei structuri de organizare. Tabelul 6 prezint avantajele i dezavantajele a trei tipuri de organizare.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

3.3 Definirea rolurilor n proiect Odat ce activitile sunt identificate, dimensionate i grupate, iar structura organizatoric specificat, managerul de proiect trebuie s creeze i s documenteze rolurile. Personalul va fi recrutat pentru proiect folosind aceste titluri i descrieri ale rolurilor. De exemplu: Manager de proiect responsabil pentru dezvoltarea i implementarea sistemului. Coordoneaz efortul inginerilor programatori, analitilor i celorlali membri ai echipei. Inginer de sistem proiecteaz i dezvolt software pentru sistemul de operare al calculatorului. Dezvolt componente firmware, drivere i software specializat, cum ar fi sisteme grafice, de comunicaie, controllere, sisteme de operare i interfee. Ei colaboreaz cu inginerii ce se ocup de hardware i cu programatorii, i trebuie s neleag toate aspectele produsului. Inginer programator, analist programator execut proiectele detaliate, codificarea, testarea, eliminarea erorilor i elaborarea documentaiei pentru diferite aplicaii computerizate. Inginer pentru verificarea i validarea software-ului dezvolt planuri independente de validare i verificare, precum i proceduri, instrumente, cazuri de test pentru sistemele software. Inginer pentru asigurarea calitii software elaboreaz proceduri i standarde de dezvoltare software. Desfoar controlul sistemelor software i supravegheaz testele. 3.4 Definirea responsabilitilor i a autoritii Responsabilitatea reprezint obligaia de ndeplini angajamentele, iar autoritatea reprezint dreptul de a lua decizii i de a exercita puterea. Adesea se spune c autoritatea poate fi delegat, ns responsabilitatea nu. Responsabilitatea i autoritatea pentru activitile organizatorice trebuie asignate poziiilor n momentul crerii sau modificrii acestora. Managerului de proiect i sunt desemnate, i desemneaz la rndul lui, responsabiliti i autoriti corespunztoare diferitelor poziii ale proiectului. 3.5 Stabilirea calificrilor necesare Calificarea necesar trebuie identificat pentru fiecare poziie a proiectului i este stabilit prin considerarea unor ntrebri de tipul: Ce fel de indivizi sunt necesari pentru proiect? Ct de mult experien este necesar n domeniul aplicaiei? Ce studii sunt necesare? Ce pregtire este necesar, nainte sau dup iniierea proiectului? Ce limbaj de programare este necesar a fi cunoscut? 3.6 Documentarea structurii organizatorice Autoritatea i responsabilitatea fiecrui titlu i fiecrei activiti trebuie documentat n planul proiectului. Justificarea deciziilor trebuie bine documentat i s fie disponibil n vederea ocuprii posturilor proiectului.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004 Tabel 6 Organizare funcional Puncte forte Puncte slabe Organizarea exist deja (nceputul i ncheierea n cadrul proiectului nu exist o poziie central a proiectului este rapid). responsabilitii sau a autoritii. Recrutarea, pregtirea i reinerea specialitilor Problemele legate de interfa sunt dificil de este uoar. rezolvat Politicile, procedurile, standardele, metodele, Proiectele sunt dificil de monitorizat i controlat. instrumentele i tehnicile sunt deja stabilite. Organizare de tip proiect Puncte forte Puncte slabe n cadrul proiectului exist o poziie central a Organizarea trebuie format pentru fiecare proiect nou responsabilitii i autoritii. Toate interfeele sistemului sunt controlate central Recrutarea, pregtirea i reinerea specialitilor poate fi mai dificil dect n cazul funcional Deciziile pot fi luate rapid Politicile, procedurile, standardele, metodele, instrumentele i tehnicile trebuie adoptate pentru fiecare proiect nou. Motivarea personalului este n general nalt Organizare matricial Puncte forte Puncte slabe Poziia central a responsabilitii i autoritii Responsabilitatea i autoritatea membrilor proiectului este partajat ntre doi sau mai muli este mbuntit n comparaie cu formatul manageri. funcional. Interfeele ntre funcii pot fi controlate cu Este mult prea uor transferul personalului de la un proiect la altul. uurin Recrutarea, pregtirea i reinerea specialitilor Este necesar o coordonare mai riguroas a este uoar. organizaiei. nceputul i ncheierea unui proiect este facil. Exist o concuren mai acerb pentru resurse ntre proiecte. Politicile, procedurile, standardele, metodele, instrumentele i tehnicile sunt deja stabilite. Utilizarea mai flexibil a personalului este posibil.

4. ALOCAREA PERSONALULUI UNUI PROIECT DE DEZVOLTARE SOFTWARE Alocarea personalului unui proiect de dezvoltare software const n activitile manageriale necesare pentru ocuparea i meninerea ocupat a rolurilor stabilite prin structura organizatoric a proiectului. Acestea includ selectarea candidailor i pregtirea acestora pentru ndeplinirea eficient a sarcinilor, precum i retragerea personalului atunci cnd este necesar acest lucru. Alocarea personalului nu este acelai lucru cu organizarea: alocarea personalului implic ocuparea funciilor create n structura organizatoric a proiectului prin selectarea personalului i pregtirea lui. Obiectivul alocrii personalului este de a asigura c funciile proiectului sunt ocupate de personalul calificat, att din punct de vedere tehnic, ct i temperamental. Problemele majore ale alocrii personalului ntr-un proiect de dezvoltare software sunt: Managerul de proiect este frecvent selectat mai mult datorit capacitii de a programa sau de a executa diferite activiti, dect datorit capacitii de a conduce (puini programatori sunt i buni manageri).

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

Productivitatea programatorilor, analitilor i proiectanilor variaz de la un individ la altul. Exist un procent mare de nlocuire a personalului unui proiect software, n special n cazul proiectelor organizate matricial.

Universitile nu produc un numr suficient de absolveni specializai, care neleg procesul de inginerie a programrii sau de management al proiectelor. Planurile de pregtire a programatorilor nu sunt dezvoltate sau meninute. Tabelul 7 evideniaz activitile care trebuie ndeplinite de ctre managerii de proiect n procesul de alocare a personalului.
Activitatea Ocuparea poziiilor organizatorice Integrarea personalului recent angajat Instruirea sau pregtirea personalului Asigurarea dezvoltrii generale Evaluarea i aprecierea personalului Recompensarea Tabel 7 Definiie sau explicaie Selectarea, recrutarea sau promovarea persoanelor calificate pentru fiecare poziie a proiectului. Orientarea i familiarizarea noilor angajai cu proiectul i activitile care trebuie ndeplinite n proiect. Compensarea deficienelor de calificare a personalului. mbuntirea cunotinelor, a atitudinii i a abilitilor personalului. nregistrarea i analizarea cantitii i calitii activitilor proiectului ca baz pentru evaluarea personalului; stabilirea obiectivelor de performan i aprecierea periodic a personalului. Stabilirea salariilor, primelor, profiturilor sau a altor remuneraii, n concordan cu performanele i responsabilitile proiectului.

4.1 Ocuparea rolurilor ntr-un proiect software Managerul proiectului poart responsabilitatea ocuprii poziiilor stabilite prin planificarea organizatoric, prin considerarea urmtorilor factori: Studiile Experiena Pregtirea Motivarea Angajamentul Auto-motivarea Afinitatea la grup Inteligena Deficienele nregistrate la oricare dintre aceti factori pot fi compensate prin excesul altora, spre exemplu deficienele studiilor pot fi compensate de experien, un tip particular de pregtire sau chiar de entuziasm. Totui, deficienele majore trebuie s produc aciuni corective. Printre sursele de personal calificat se pot enumera: 9 transferul n cadrul proiectului: este un privilegiu al managerului de proiect; 9 transferul n cadrul organizaiei: are loc n general atunci cnd alte proiecte se ncheie sau sunt anulate; 9 angajarea de la alte companii: se face prin intermediul trgurilor de munc, referinelor etc. 9 recrutarea absolvenilor prin interviuri sau referine; 9 angajarea personalului necalificat i pregtirea acestuia.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

Selectarea unui personal cu productivitate sporit se face n funcie de dou metrici: cantitatea de experien deinut i diversitatea experienei. 4.2 Integrarea personalului recent angajat n atribuiile managerului sunt incluse nu numai activitile de angajare a personalului, ci i familiarizarea acestuia cu procedurile proiectului sau planurile necesare integrrii efective n proiect. Multe dintre companiile mari au programe formale de orientare, care pot dura cteva zile i cuprind caracteristicile i istoria companiei, politici generale, structura organizatoric etc. 4.3 Instruirea sau pregtirea personalului Nu este ntotdeauna posibil recrutarea sau transferul angajailor cu pregtirea necesar pentru un proiect particular. Prin urmare, managerul este responsabil pentru instruirea i pregtirea personalului repartizat pentru a se asigura c el poate ndeplini cerinele proiectului. Instruirea difer de pregtire prin aceea c presupune nvarea bazelor, teoriilor i a conceptelor fundamentale unei discipline, cu rezultate pe termen lung. Pregtirea presupune deprinderea unei aptitudini sau cunotine i are rezultate ateptate pe termen scurt. 4.4 Asigurarea dezvoltrii generale Pe lng instruire i pregtire, managerul proiectului trebuie s se asigure c personalul se dezvolt mpreun cu proiectul i compania. El trebuie s se asigure c se vor dezvolta i cunotinele profesionale ale personalului i c acesta are o atitudine pozitiv fa de proiect, companie i clieni. Unul din obiectivele dezvoltrii generale a angajailor este mbuntirea eficienei organizaiei. 4.5 Evaluarea i aprecierea personalului Alte atribuii ale managerului proiectului sunt evaluarea i aprecierea periodic a personalului.Aprecierea furnizeaz feedback-ul ctre membrii proiectului cu privire la aspectele pozitive i negative ale performanelor acestora, cu scopul consolidrii calitilor pozitive i al mbuntirii celor negative. Aprecierea trebuie efectuat la intervale de timp regulate i trebuie concentrat asupra performanei individuale i nu asupra personalitii, cu excepia cazului n care aspectele legate de personalitate interfereaz cu cele legate de performan. O tehnic binecunoscut de evaluare a personalului este managementul prin obiective. Aceast tehnic este superioar evalurii personale. 4.6 Recompensarea personalului Managerul proiectului cteodat n mod direct, cteodat n mod indirect este responsabil pentru determinarea salariului i beneficiilor personalului. Beneficiile pot fi monetare sau echivalente: deinerea de aciuni, automobilul oferit de companie, prim la sfritul anului etc., sau non-monetare: respect, titlu impresionant etc. 4.7 Retragerea personalului Managerul proiectului nu este responsabil numai cu angajarea personalului; el trebuie de asemenea s ncheie contracte atunci cnd este necesar acest lucru. ncheierea contractului poate include reangajarea personalului la ncheierea cu succes a unui proiect, sau concedierea

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

personalului n cazul anulrii unui proiect. Retragerea personalului este extrem de important. Cei care nu au performane satisfctoare, n mod frecvent scad moralul celorlali, iar managementul pare ineficient. 4.8 Documentarea deciziilor cu privire la alocarea personalului Managerul proiectului trebuie s documenteze planurile cu privire la personal, la evaluarea lui sau a politicilor de instruire. Fiecare individ dintr-o organizaie trebuie s aib un plan personal de pregtire, care s reflecte cursul necesar i progresul proiectului. 5. ANTRENAREA Antrenarea const n acele activiti manageriale care presupun aspectele inter-personale i legate de motivare, care fac ca personalul s neleag i s contribuie la atingerea scopurilor proiectului. Odat ce subordonaii sunt pregtii i orientai, managerul proiectului are responsabilitatea continu de a clarifica sarcinile acestora, ghidndu-i ctre mbuntirea performanelor i motivndu-i s lucreze cu entuziasm i ncredere pentru ndeplinirea obiectivelor proiectului. Antrenarea presupune lucrul cu oamenii; ea implic capacitatea de a conduce, supravegherea zilnic a personalului, delegarea autoritii, coordonarea activitilor, facilitarea comunicrii, medierea conflictelor, managementul schimbrilor i documentarea deciziilor importante (tabelul 8). Problemele majore ntmpinate n cadrul procesului de antrenare sunt: Eecul n comunicarea efectiv att ntre entitile proiectului, ct i cu cele care nu aparin proiectului. Banii nu sunt ntotdeauna un motiv suficient pentru productorii unui sistem software. Companiile i managerii nu au instrumentele adecvate i tehnicile necesare pentru a motiva inginerii programatori. Beneficiarii i managerii nu recunosc impactul pe care l-ar putea avea o modificare aparent trivial.
Activiti Crearea cadrului necesar conducerii Supravegherea personalului Delegarea autoritii Motivarea personalului Construirea echipelor Coordonarea activitilor Facilitarea comunicrii Medierea conflictelor Managementul schimbrilor Documentarea deciziilor conducerii Tabel 8 Explicaie Crearea unui mediu n care membrii proiectului i pot ndeplini sarcinile cu entuziasm si ncredere Furnizarea instruciunilor zilnice, a ndrumrii i a disciplinei necesare membrilor proiectului pentru a-i ndeplini sarcinile repartizate. Autorizarea personalului n luarea deciziilor i utilizrii resurselor n limitele rolului deinut. Furnizarea unui mediu de lucru n care personalul i poate satisface nevoile psihologice. Furnizarea unui mediu de lucru n care angajaii pot lucra mpreun pentru atingerea obiectivelor proiectului; se stabilesc obiective att pentru echipe, ct i pentru indivizi. Combinarea eficient a activitilor proiectului. Asigurarea unui flux corect de informaii ntre membrii proiectului. ncurajarea constructiv a diferenelor de opinie i sprijin n rezolvarea conflictelor. Stimuleaz creativitatea i inovaia n atingerea obiectivelor proiectului. Documentarea deciziilor care implic delegarea de autoritate, comunicarea i coordonarea, medierea conflictelor i managementul modificrilor.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

5.1 Crearea cadrului necesar antrenrii Managerul proiectului trebuie s creeze cadrul necesar conducerii, prin interpretarea planurilor i cerinelor, pentru a se asigura de faptul c fiecare membru al proiectului i aduce contribuia la realizarea scopului final. Aceasta rezult din fora i abilitatea liderului de a ndruma i influena oamenii. Fora managerului de proiect provine din dou surse: funcia deinut, numit i leadership formal, i armul personal sau charisma. Un bun manager de proiect este capabil s mbine scopurile personale ale subordonailor cu scopurile organizaiei. 5.2 Supravegherea personalului

O responsabilitate a managerului proiectului este supravegherea activitii fiecrui membru al echipei. De asemenea, intr n responsabilitatea managerului proiectului ndrumarea i, atunci cnd este cazul, disciplinarea membrilor proiectului pentru a asigura ndeplinirea sarcinilor. n unele cazuri, managerul proiectului poate lua o decizie important cu privire la soluia software adoptat; poate aduce un argument bine ntemeiat conducerii organizaiei, care are ca efect achiziionarea unor echipamente mai performante sau mbuntirea mediului de lucru. Managerul proiectului poate fi uneori i un bun asculttor al problemelor personale ale membrilor proiectului.
5.3 Delegarea autoritii Managerul unui proiect de dezvoltare software este de asemenea responsabil pentru delegarea autoritii ctre ali membrii ai proiectului. Sarcinile sunt repartizate pe subgrupuri, echipe i indivizi, iar autoritatea este delegat acestor echipe astfel nct ele pot fi ndeplinite ntr-o manier eficient. n general, un manager de proiect bun va delega autoritatea ctre un nivel organizatoric ct mai mic. Delegarea corespunztoare a autoritii poate elibera managerul proiectului de deciziile i supravegherea de rutin, permindu-i acestuia s acorde mai mult timp aspectelor importante ale proiectului. Managerul trebuie s se asigure c fiecare individ nelege ce autoritate i este delegat i care este responsabilitatea corespunztoare acesteia. De asemenea, membrii proiectului trebuie s neleag foarte bine domeniul, limitele i scopul delegrii. 5.4 Motivarea personalului Managerul proiectului trebuie s motiveze i s inspire personalul pentru a maximiza performanele. O serie de tehnici generale de motivare sunt aplicabile i proiectelor de inginerie a programrii, cum ar fi managementul prin obiective. n tabelul 9 sunt prezentate o serie de tehnici i modele de motivare.
Model de motivare Frederick Taylor Elton Mayo Kurt Lewin Douglas McGregor Abraham Maslow Frederick Herzberg Tabel 9 Definiie sau explicaie Angajaii vor aprecia stimulentele salariale Valorile de grup surclaseaz valorile individuale. Indivizii vor reaciona la presiunea grupului. Fora grupului poate nvinge interesele individuale. Managerii trebuie s neleag natura oamenilor pentru a fi capabili s-i motiveze. Nevoile umane pot fi ierarhizate. Nevoile satisfcute nu constituie factori de motivare. O descretere a factorilor de mediu este nesatisfctoare; o cretere a factorilor de

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004 Model de motivare Definiie sau explicaie mediu nu este satisfctoare. O descretere a coninutului muncii nu este nesatisfctoare; o cretere a coninutului muncii este satisfctoare. Cu ct este mai mare discrepana ntre nevoile companiei i nevoile individuale, cu att este mai mare neplcerea angajailor. Managementul participativ este esenial pentru motivarea personal. Managerii sunt motivai prin provocarea muncii, statut, necesitatea de a conduce, spiritul de competiie, fric i bani. O combinaie ntre stilul de management american i cel japonez. Oamenii au nevoie de scopuri i obiective, altfel ei pot mpiedica progresul personal i al organizaiei. O strategie pentru mbuntirea continu a performanei la fiecare nivel i arie de responsabilitate.

Chris Argyris Rensis Likert Arch Patton Teoria Z Managementul totale calitii

5.5 Formarea echipei proiectului software Formarea echipei reprezint procesul de mbuntire a relaiilor dintre membrii proiectului n vederea creterii eficienei echipei ca ntreg. Tehnicile de mbuntire a capacitilor echipelor includ exerciii de construire a echipelor, ntlnirile n afara firmei i altele. 5.6 Coordonarea activitilor proiectului Coordonarea reprezint aranjarea entitilor proiectului pentru a colabora n vederea unui scop comun cu minimul de efort. Documentele, politicile, procedurile etc. sunt interpretate diferit de persoane distincte. Sarcina managerului de proiect este de a reconcilia diferenele de opinie i de efort n avantajul proiectului. Managerul trebuie s se asigure c membrii proiectului comunic i se neleg, i c alte persoane n contact cu proiectul sunt informate cu privire la structura organizatoric, la activitile ntreprinse i la ceea ce se ateapt din partea organizaiei. 5.7 Facilitarea comunicrii Pe lng coordonare, managerul proiectului trebuie s faciliteze comunicarea att n cadrul proiectului, ct i cu alte organizaii. Spre exemplu, managerul trebuie s asigure distribuirea planurilor proiectului n organizaie, cnd acest lucru este util. Un bun manager se va asigura ntotdeauna c membrii proiectului sunt bine informai, astfel nct zvonurile s fie rapid risipite. 5.8 Medierea conflictelor Medierea conflictelor intr n atribuiile managerului de proiect, att cele ntre membrii proiectului, ct i cele cu alte entiti externe, privind probleme tehnice sau manageriale. Managerul proiectului nu trebuie s fie un expert n toate aspectele proiectului, dar trebuie s dein abiliti deosebite n ceea ce privete rezolvarea problemelor. Managerul proiectului trebuie s reduc ansele de conflict prin ndeprtarea surselor de disput, spre exemplu, membrii echipei cu poziii echivalente trebuie s aib beneficii egale. 5.9 Managementul schimbrilor cu impact asupra proiectului Un manager de proiect trebuie s ncurajeze inovaiile i ideile membrilor proiectului i s armonizeze schimbrile, cnd acestea sunt eficiente i benefice pentru proiect. Edward Yourdon prezint un plan simplu pentru a introduce o nou tehnologie software ntr-o organizaie: Explic riscurile i beneficiile noii metodele, instrument sau tehnici. Furnizeaz pregtirea membrilor proiectului.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

Experimenteaz tehnica nainte de a fi utilizat. Furnizeaz suport tehnic pe parcursul ntregului proiect. Ascult preocuprile i problemele utilizatorilor. Evit concentrarea ntregului proiect asupra tehnologiei.

5.10 Documentarea deciziilor procesului de antrenare Managerul proiectului trebuie s documenteze toate activitile, delegrile de autoritate, efectele rezolvrii conflictelor, precum i deciziile cu privire la comunicare i coordonare. 6. CONTROLUL-EVALUAREA UNUI PROIECT DE DEZVOLTARE SOFTWARE Controlul presupune acele activiti manageriale utilizate pentru a asigura desfurarea proiectului conform planurilor. Performanele i rezultatele sunt comparate cu planurile, diferenele sunt notate, iar aciuni corective vor fi ntreprinse pentru a asigura respectarea planurilor. Controlul furnizeaz o cale de a elimina diferenele dintre planuri sau standarde i rezultatele concrete. Procesul de control necesit de asemenea o structur organizatoric, comunicare i coordonare. Metodele de control trebuie s fie obiective, ele trebuie s identifice abaterea de la planuri fr a considera o persoan anume sau poziiile implicate. Aceste metode de control trebuie s fie particulare fiecrui mediu sau manager n parte, trebuie s fie flexibile i adaptabile unui mediu schimbtor. Printre problemele majore ntmpinate n controlul unui proiect de ingineria programrii se numr: Multe metode pentru controlul unui proiect software se bazeaz pe cheltuieli bugetare, fr a lua n considerare munca depus. Vizibilitatea progresului n dezvoltarea unui sistem software este dificil de msurat. Calitatea nu este necesar, monitorizat sau controlat. Adesea standardele pentru dezvoltarea software-ului i managementul proiectelor nu sunt documentate sau aplicate. Metricile software nu sunt dezvoltate suficient. Tabelul 10 evideniaz activitile de management care trebuie ndeplinite n procesul de control, iar figura 2 reflect aceste activiti i succesiunea lor n procesul de control al unui proiect software.
Tabel 10 Activitate Dezvoltarea standardelor de performan Stabilirea sistemelor de monitorizare i raportare Msurarea i analiza rezultatelor Iniierea aciunilor corective Recompensarea i disciplinarea Documentarea metodelor de control Explicaie Definirea scopurilor care vor fi atinse atunci cnd activitile sunt corect ndeplinite. Determinarea datelor necesare, cine i cnd le vor recepiona i ce vor face cu ele pentru a controla proiectul. Compararea realizrilor cu standardele, scopurile i planurile. Aducerea pe un curs normal a cerinelor, planurilor i a situaiei curente a proiectului. Aprecierea, remunerarea i disciplinarea personalului, dup caz. Documentarea standardelor de performan, a sistemelor de monitorizare i control i a mecanismelor de recompensare i disciplinare.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

6.1 Dezvoltarea standardelor de performan Specificarea standardelor de performan ale proiectului reprezint o alt responsabilitate a managerului de proiect, care fie dezvolt standarde i proceduri pentru proiect, le adopt i folosete pe cele ale organizaiei, fie folosete standarde dezvoltate de beneficiar sau o organizaie profesionist, cum ar fi standardele IEEE. Standardul reprezint un set documentat criterii, care specific i determin calitatea unei aciuni sau unui obiect. n ingineria programrii, un standard este un set de proceduri care definesc procesul de dezvoltare sau determin calitatea unui produs software.

Compararea produselor sau proceselor cu cerinele sau planul proiectului

Aplicarea unor aciuni corective dac cele curente deviaz de la plan sau standarde

Stabilirea sistemului de monitorizare i raportare a metricilor

Modificarea metricilor sau standardelor

Dezvoltarea cerinelor sau planului

Modificarea sau reducerea cerinelor sau planului

Cerinele software

Renunarea la proiect

Figura 2. Controlul proiectului

Att standardele produselor, ct i cele ale proceselor sunt extrem de importante pentru dezvoltarea unui software de calitate. Un set de standarde va realiza urmtoarele: Va mbunti comunicarea ntre membrii echipei. Va facilita transferul de personal ntre proiecte. Va reduce nevoia de a reine ingineri, proiectani i programatori. Va facilita aplicarea experienei unor proiecte de succes. Va simplifica implementarea i ntreinerea programelor. Va mbunti controlul proiectelor, deoarece standardele proceselor pot fi mbuntite. Va permite asigurarea calitii software. Conform IEEE, asigurarea calitii software reprezint un model sistematic i planificat al tuturor aciunilor necesare pentru ca un produs s corespund cerinelor tehnice stabilite. Aceasta include procesul de dezvoltare a produsului, metodele de management, standarde, managementul

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

configuraiei, standardele de documentare, verificare i validare, specificaiile i procedurile de testare. Asigurarea calitii software reprezint una dintre tehnicile principale de control aflate la dispoziia managerului unui proiect. Managementul configuraiei software este o metod de control a situaiei unui sistem software prin identificarea configuraiei sale n diferite momente. Scopul acestuia este de a controla n mod sistematic modificrile de configuraie, i de a ntreine integritatea sistemului pe ntreg ciclul de via al acestuia. Metricile produselor i ale proceselor msoar gradul n care un produs sau proces posed o caracteristic specific. Alte metrici aplicabile unui proiect software sunt urmtoarele: Metrici software calitative reprezint msuri cantitative ale gradului n care un software prezint o caracteristic specific care i afecteaz calitatea. Metrici software cantitative reprezint msuri cantitative ale unor caracteristici fizice ale unui software, spre exemplu linii de cod, pagini de documentaie, puncte de intrare n funcie. Metrici ale managementului reprezint indicatori care pot fi folosii pentru a msura activitile manageriale, cum ar fi bugetul de cheltuieli, valoarea adugat, depirea costurilor sau a termenelor. 6.2 Stabilirea sistemelor de monitorizare i raportare Pentru a permite determinarea situaiei proiectului software, sistemul de monitorizare i raportare trebuie specificat. Managerul proiectului are nevoie de feedback asupra progresului proiectului i asupra calitii produsului pentru a se asigura c totul se desfoar conform planurilor. Trebuie specificate, deci, tipul, frecvena, originea i receptorii rapoartelor proiectului. Instrumentele de raportare a situaiei nu reprezint numai utilizare de resurse i timp, ci acestea trebuie implementate. Metodele, procedurile, instrumentele i tehnicile software trebuie de asemenea specificate. n tabelul 11 sunt specificate unele sisteme de monitorizare i raportare caracteristice. Unele instrumente care servesc n controlul unui proiect de ingineria programrii sunt PERT, CPM i graficele Gantt.
Metoda Verificri formale Verificri bugetare Control independent Sistemul de urmrire binar Asigurarea calitii software Managementul configuraiei Testarea Verificarea i validarea Inspecii Tabel 11 Explicaie Verificri periodice cu scopul de a evalua progresul proiectului. O comparaie a bugetului estimat cu cheltuielile actuale, cu scopul de a determina ncadrarea sau abaterea de la plan. O examinare independent a proiectului software, cu scopul de a determina ncadrarea n plan, specificaii sau standarde. O metod de evaluare a progresului unei uniti de lucru prin acceptarea doar a unei completitudini de 0 sau 100%. Un model sistematic i planificat al tuturor aciunilor necesare pentru ca un produs s corespund cerinelor tehnice stabilite. O metod de control i raport a situaiei produselor dezvoltate ntr-un proiect software. Execuia controlat a unui program, cu scopul de a dezvlui erorile. Asigur faptul c fiecare faz a ciclului de via implementeaz corect specificaiile de la faza precedent i c fiecare produs software satisface cerinele. Examinri sistematice ale produselor software, cu scopul descoperirii erorilor.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

6.3 Msurarea i analiza rezultatelor Att n timpul dezvoltrii proiectului, ct i la sfritul acestuia, managerul proiectului trebuie s cuantifice i s analizeze rezultatele proiectului, care pot fi rezultate ale activitilor de management i/sau rezultate tehnice. 6.4 Iniierea aciunilor corective Managerul proiectului poate schimba planurile sau standardele, dac cele iniiale nu pot fi ndeplinite. Aceasta ar putea impune alocarea unui buget mai mare, mai muli programatori sau mai mult timp acordat verificrilor. De asemenea, ar putea implica reducerea standardelor, spre exemplu verificarea numai a modulelor software critice. Uneori este posibil rencadrarea n planuri prin alocarea de noi resurse sau pstrarea costurilor iniiale prin mrirea termenelor sau scderea funcionalitii sistemului software. 6.5 Recompensarea i disciplinarea membrilor proiectului Membrii proiectului care respect standardele i planurile trebuie recompensai de ctre managerul proiectului, iar cei care nu se conformeaz, fr a avea un motiv ntemeiat, trebuie disciplinai. Acest lucru nu trebuie confundat cu recompensarea sau disciplinarea membrilor echipei pentru ndeplinirea sarcinilor ncredinate, care este o funcie a managementului personalului. Acest sistem de recompense i pedepse constituie un mecanism pentru controlul capacitii de a ndeplini planurile sau standardele. 6.6 Documentarea metodelor de control Managerul proiectului trebuie s documenteze toate standardele, procedurile care asigur calitatea software, metricile i celelalte metode de msurare a produselor software. n plus, managerul proiectului trebuie s stabileasc metrici pentru a determina cnd este necesar ca aciunile corective s fie iniiate i s determine n avans posibilele aciuni care pot fi ntreprinse. Doar aplicarea procedurilor i tehnicilor de inginerie a programrii nu poate garanta succesul unui proiect. Un bun manager de proiect poate uneori s depeasc deficienele de organizare, personal, bugete, standarde sau alte imperfeciuni, n timp ce un manager slab se blocheaz la fiecare problem, real sau nu, i nici o regul, politic, standard sau tehnic nu-i poate folosi. Totui, metodele i tehnicile prezentate, folosite de un manager de proiect competent, pot mbunti semnificativ ansele de succes ale proiectului. Referine bibliografice [1] Centre for Business Practices Project Management: the State of the Industry Survey, 2003, http://www.cbponline.com. [2] Charvat J. Project Management Nation. Tools, Techniques and Goals for the New and Practicing IT Project Manager, John Wiley&Sons, Inc., 2002. [3] Chin G Agile Project Management. How to Succeed in the Face of Changing Project Requirements, American Management Association, AMACOM Books, 2004 [4] Dwayne P. The Software Project Managers Handbook. Principles that Work at Work, IEEE Computer Society Press, 1998 [5] eXtreme Project Management Concepts, http://www.informit.com/content/ [6] Jalote P. Software Project Management in Practice, Pearson Education, Inc., Addison-Wesley, 2002.

Workshop - Managementul proiectelor informatice Bucureti, 27 octombrie 2004

[7] McConnell S. Software Project Survival Guide, Microsoft Press, 1998. [8] Oracle Corporation Project Management Method Handbook, Release 2.0.1, 1996. [9] Schwalbe K. IT Project Management, Second edition, Thomson Learning, Inc., 2002. [10] Software Engineering Coordonating Committee SWEBOK Guide to the Software Engineering Body of Knowledge, IEEE Press, 2001. [11] Software Engineering Institute Capability Maturity Model for Software: SW-CMM , Carnegie-Mellon, http://www.sei.cmu.edu/cmm/cmm.html. [12] Software Technology Support Center Report on Project Management and Software Cost estimation Technologies, STSC-TR-012-April, 1995 [13] Software Technology Support Center Software Configuration Management Technologies and Applications, 1998. [14] Thayer R.H. Software Engineering Project Management, IEEE-Computer Society, Yourdan Press, 1999. [15] XP: A Project Managers Primer, http://www.informit.com/isapi/