Managementul proiectelor

software
- Principii generale -
 Scopuri:
• Stabilirea obiectivelor proiectării software
• Identificarea diferenţelor ce apar la
dezvoltarea proiectele software şi la
dezvoltarea altor proiecte
• Definirea etapelor uzuale ale unui proiect
software
• Înţelegerea nevoii de planificare,
monitorizare şi control
• Măsurarea succesului unui proiect în
îndeplinirea obiectivelor
 1) Introducere

Un proiect este o activitate planificată.

Obs. Un task repetat de un număr de ori nu este

un proiect.

Obs. Amploarea proiectului este foarte importantă.

Un proiect ce implică 200 oameni diferă (ca
management) faţă de unul ce implică 2 oameni.
 2) Proiecte software vs. Alte proiecte
Un proiect software are anumite caracteristici care-l
diferenţiază faţă de alte tipuri de proiecte:
• Invizibilitatea: dacă la un pod ce se construieşte, e
vizibil progresul, la produsele software nu e la fel;
• Complexitatea: produsele software conţin mai
multă complexitate per dolar sau euro cheltuit
• Flexibilitate: un produs software se poate schimba
în funcţie de preferinţele utilizatorilor, mai degrabă
decât să se ceară utilizatorilor să-şi modifice
comportamentul pentru a folosi produsul.
 3) Activităţi în managementul proiectelor
software
Un proiect software nu priveşte doar scrierea software-ului.
De aceea, există 3 procese succesive care sunt necesare:
a) Studiu de fezabilitate: investigare dacă un proiect de
viitor merită să fie început. Trebuie estimate costurile şi
beneficiile. La un proiect mare, studiul de fezabilitate
poate fi el însuşi un proiect.
b) Planificarea: dacă studiul de fezabilitate spune că
proiectul poate începe, trebuie începută planificarea.
Obs. Pentru un proiect mare, nu trebuie ca toate detaliile
să fie planificate de la început, ci doar etapele
importante, detaliindu-le apoi (în diverse etape ale
proiectului).
c) Executarea proiectului: Un ciclu de viaţă tipic al unui
proiect (typical project life-cycle) este următorul:
Detalierea etapelor

• Analiza cerinţelor: această etapă trebuie să stabilească

ceea ce doresc utilizatorii de la software.
• Descriere: documentaţia detaliată a ceea ce îşi propune
sistemul să facă.

• Design: are două etape:

¾ design-ul extern (sau al utilizatorului): ce face
sistemul în termni de meniuri, ecrane etc
¾ design-ul fizic: felul în care datele şi operaţiile sunt
structurate intern

• Cod: scrierea efectivă a codului (într-un anumit limbaj).

• Verificare şi validarea: operaţie necesară pentru
depistarea şi corectarea eventualelor erori (errors, bugs,
faults) din sistem.
• Implementarea / instalarea: termenul “implementare” se
referă, după unii autori, la tot ce urmează după etapa de
design, iar după alţii la instalarea sistemului după ce
software-ul a fost dezvoltat (în acest caz, trebuie încorporate
aici şi stabilirea parametrilor sistemului, scrierea manualelor
de utilizare, asigurarea training-ului utilizatorilor).
• Mentenanţă şi suport: după ce sistemul a fost instalat, e
nevoie de corecţia erorilor ce nu au fost depistate în faza de
testare, de extinderea şi îmbunătăţirea sistemului.
Mentenanţa şi suportul pot fi văzute ca procese software
minore.
 4) Clasificarea proiectelor software
a) Putem întâlni:
• sisteme de informaţie (information systems): exemplu – un
sistem de control al stocurilor.
• sisteme în timp real (embedded systems): exemplu – un
sistem ce controlează aerul condiţionat dintr-o clădire.
Obs. Unele sisteme pot avea caracteristici din ambele tipuri
de sisteme

b) Din punct de vedere al scopului sistemului:

• sisteme care produc ceva
• sisteme ce îndeplinesc anumite obiective.
 5) Proiectul ca sistem
Un proiect se ocupă de crearea unui nou sistem sau/şi de
transformarea unuia vechi.
Sistem (system) = mulţime de părţi intercorelate

Un sistem poate fi parte a unui sistem mai mare şi poate

avea ca părţi componente subsisteme (subsystem).

În afara sistemului există aşa numitul mediu al sistemului

(system´s environment), adică acele elemente care pot
afecta sistemulo, dar asupra cărora sistemul nu are control.
Sistemele deschise (open systems) sunt sistemele ce
interacţionează cu mediul. Aproape toate sistemele sunt
deschise.
 6) Ce este managementul?

Managementul presupune următoarele activităţi:

• Planificare – ce trebuie făcut;

• Organizare – “making arrangements”;
• Încadrarea personalului – selectarea oamenilor potriviţi;
• Conducere, îndrumare – se dau instrucţiuni;
• Monitorizare – verificarea progresului;
• Control – acţiuni care să remedieze penele;
• Inovare – propunerea de noi soluţii;
• Prezentare – legătura cu utilizatorii.
Pe de altă parte, cele mai frecvente provocări pentru un
manager sunt următoarele (printre altele):

• Să facă faţă deadlines-urilor (85%);

• Să facă faţă restricţiilor legate de resurse (83%);
• Comunicarea efectivă de sarcini (80%);
• Câştigarea angajamentului membrilor echipei (74%);
• Stabilirea unor “pietre de hotar” măsurabile (70%);
• Să facă faţă schimbărilor (60%);
• Să facă faţă conflictelor (42%);
• Să gestioneze vânzătorii şi sub-contractorii (38%).

Procentele de mai sus se referă la numărul de manageri

care au identificat fiecare item. Un manager poate identifica
mai mult decât un item.
 7) Probleme cu proiectele software
Deşi multe sarcini ale managementului se gestionează mai
degrabă se sisteme de management decât de manageri, e
adevărat că pentru succesul unui proiect e totuşi
răspunzătoare o persoană.
Problemele ce apar (d.p.d.v. al managerului) sunt:
• estimare şi planificare deficitară;
• lipsa standardelor de calitate;
• lipsa criteriilor în luarea deciziilor;
• lipsa tehnologiei pentru ca prgresul să devină vizibil;
• repartizarea defectuoasă a rolurilor – cine ce face?
• criterii de succes incorecte.
Problemele ce apar (d.p.d.v. al membrilor echipei) sunt:
• descrierea inadecvată a muncii sale;
• ignoranţa managerului în IT;
• lipsa cunoştinţelor în aria sa de muncă;
• lipsa standardelor;
• lipsa documentaţiei la zi;
• activităţi anterioare neterminate la timp;
• lipsa comunicării între utilizatori şi tehnicieni;
• schimbarea software environment;
• presiunea dată de deadline;
• lipsa controlului de calitate;
• lipsa trainingului.
 8) Controlul managementului

A) Ciclul de control al
proiectului

Managementul, în
general, poate fi văzut
ca un proces de stabilire
a obiectivelor şi apoi
monitorizarea sistemului
pentru a vedea care
este performanţa sa
adevărată.
B) Obiective

Managerul şi echipa sa trebuie să stabilească clar

obiectivele, pentru a se putea concentra asupra lucrurilor
esenţiale şi a defini astfel criteriile de succes ale proiectului.

Dacă există mai multe grupuri de utilizatori, atunci trebuie să

existe o autoritate a proiectului, care să aibă autoritatea
globală asupra proiectului. În acest caz, există şi un comitet
de organizare, care are responsabilitatea globală pentru
stabilirea, monitorizarea şi schimbarea obiectivelor.
Managerul este responsabil pentru derularea proiectului zi de
zi, dar el trebuie să raporteze periodic comitetului de
organizare stadiul evoluţiei proiectului.
C) Măsurarea eficacităţii
Obiectivele efective sunt bine definite.
Un enunţ vag, de tipul “să îmbunătăţească relaţia cu clientul”,
nu e un obiectiv. Dar reformularea “reducerea plângerilor
clienţilor cu 25%” poate fi un obiectiv.
Măsura eficacităţii poate fi, în anumite cazuri, un răspuns
simplu (da/nu) la o întrebare, de pildă “ai instalat noul software
săptămâna trecută?”

D) Sub-obiective şi scopuri (goals)

În multe situaţii, un obiectiv se poate împărţi în sub-obiective.

De exemplu, pentru atingerea obiectivului A, trebuie
îndeplinite în prealabil obiectivele B şi C. Aceste sub-obiective
se mai numesc scopuri (goals).
 9) Stakeholders
Sunt persoane cheie care au un anumit interes în proiect,.
Aceste persoane trebuie identificate cât mai devreme cu
putinţă, în vederea stabilirii unui canal de comunicaţii. Nu
toate persoanele implicate în proiect au aceleaşi motivaţii.

Stakeholders pot fi:

• interni în echipa proiectului: vor fi sub controlul managerial
direct al liderului de proiect;
• externi echipei proiectului, dar în aceeaşi organizaţie: de
exemplu, liderul proiectului ar putea avea nevoie de asistenţă
din partea grupului de management al informaţiei în ideea de
a adăuga tipuri de date noi în baza de date. În acest caz,
trebuie negociată angajamentul acelor persoane.
• externi echipei şi organizaţiei: în acest caz, stakeholders pot
fi clienţii, cu care trebuie încheiat un contract.
 10) Descrierea cerinţelor

A) Cerinţe funcţionale: ce trebuie să facă sistemul

B) Cerinţe de calitate: cum trebuie să se comporte sistemul,

de exemplu timp de răspuns, uşurinţa folosirii, fiabilitate

C) Cerinţe referitoare la resurse: înregistrarea a cât de mult

doreşte o organizaţie să cheltuiască pe sistem
 11) Informaţii şi control în organizaţii
Problema comunicaţiilor depinde direct proporţional de
dimensiunea proiectului. Proiectele mari au, de regulă, o
structură de management ierarhică, ca în figura de mai jos:

Membrii echipelor proiectului au un lider de grup, care,

împreună cu alţi lideri de grup, raportează catre managerul de
la nivelul superior. Spre vârf, tot mai puţine persoane trebuie
să ia hotărâri şi cantitatea d einformaţii creşte.
 A) Nivele de luarea deciziilor şi informaţii

Deciziile pot fi grupate astfel:

• decizii strategice: esenţiale pentru obiectivele ferme;
• decizii tactice: necesare pentru a se asigura că obiectivele
vor fi îndeplinite. Liderul de proiect trebuie să întocmească un
plan concret de acţiuni pentru îndeplinirea obiectivelor şi să
monitorizeze progresul activităţii;
• decizii operaţionale: se referă la munca de zi cu zi pentru
implementarea proiectului
B) Diferenţe în tipurile de informaţii
Tabel 1. Tipuri de informaţii necesare pentru luarea deciziilor
Caracteristică Operaţională Strategică
motivare eficienţă eficacitate
orientare internă internă şi externă
focus specifică unei funcţii specifică unei organizaţii
detaliu detaliată rezumată
răspuns rapidă nu aşa rapidă
căi de acces standard flexibilă
la zi esenţială dezirabilă
acurateţe esenţială aproximativă
certitudine esenţială adesea predictivă
obiectivitate înaltă mai subiectivă
tipul informaţiei mai ales cantitativă adesea calitativă

Eficacitatea se referă la a face lucrul potrivit. Eficienţa se referă la

folosirea optimă a resurselor.
C) Măsurători
În proiectele mai mari, liderii de proiect trebuie să gestioneze
o cantitate mare de informaţii. Aceste informaţii nu trebuie să
fie vagi şi, ideal, ar trebui să fie cantitative.

Măsurătorile software (software measurements) se divid în:

• măsurători ale performanţei: măsoară caracteristicile
sistemului livrat. Măsurătorile includ timpul mediu dintre
defecţiuni şi timpul de învăţare a aplicaţiei (useability);
• măsurători predictive: se fac în timpul dezvoltării şi arată
care va fi performanţa aproximată a sistemului.
 Concluzii
• Proiectele sunt prin definiţie activităţi “non-rutină” şi de
aceea mai nesigure decât alte sarcini;
• Proiectele software sunt similare cu alte activităţi, dar au
anumite atribute ce prezintă dificultăţi, cum ar fi de exemplu
invizibilitatea relativă a multor produse;
• Un factor cheie în succesul unui proiect este stabilirea unor
obiective clare. Diferite persoane cheie din proiect
(stakeholders) pot avea interese diferite. De aceea e necesară
o autoritate recunoscută care să răspundă de întregul proiect;
• Pentru ca obiectivele să aibă concreteţe, trebuie să existe
căi practice de a verifica că obiectivele se îndeplinesc. Asta
conduce la nevoia de măsurători;
• Trebuie să existe măsurători obiective de succes, în ideea
de a ajuta la comunicarea neambiguă a diverselor părţi
implicate în proiect.