MANAGEMENTUL PROIECTELOR

INFORMATICE
Realizarea unui sistem informatic reprezinta o activitate complexa si de durata, ce
antreneaza mari resurse materiale, umane si de timp. Prin analogie, realizarea unui sistem
informatic se poate asemana foarte bine cu realizarea unui obiectiv de investitii. In acest
sens, este lesne de intuit paralelismul dintre acestea. Asa cum obiectivele de investitii
necesita un plan de realizare si de urmarire sub aspectul incadrarii in costuri, termene de
punere in functiune si niveluri calitative, tot la fel se pune problema si pentru realizarea
unui proiect informatic.
1. CE ESTE UN PROIECT IN GENERAL?
Asadar sa incercam sa reproducem o definitie. Un proiect este un ansamblu de activitati,
apartinand unor faze care se interfereaza intre ele ,avand un sfarsit comun si fericit,permitand
satisfacerea unei nevoi sau cerinte identificate,prin contributia unor participanti coordonati de un
responsabil pentru care exista un obiectiv triplu:costul,termenul si calitatea produsului rezultat.
Din cite se observa aceasta definitie ilustreaza complexitatea conceptului iar daca am
vrea sa intelegem notiunea proiectului si mai pe scurt, atunci am putea s-o reducem la
obiectivul ei triplu de mai sus, adica la cele trei exigente fundamentale:
gestiunea resurselor, inclusiv a costurilor este esentiala in cadrul relatiei
contractuale client-furnizor!"
gestiunea termenelor este o exigenta mai mult sau mai putin importanta, in functie
de prioritatile organizatiei clientului si de criticitatea proiectului!"
respectarea cerintelor exprimate.
#
2. PLANIFICAREA ACTIVITATILOR
DIN CADRUL PROIECTELOR INFORMATICE
$biectivul planificarii proiectelor este acela de a asigura realizarea acestora la
termenele si c%eltuielile prestabilite. Acest obiectiv nu este usor de realizat si poate intalni
multe obstacole pe durata realizarii proiectului. Unele din acestea sunt previzibile si, cu
a&utorul experientei acumulate in decursul realizarii unor proiecte anterioare, pot fi
depasite, altele nu pot fi prevazute si numai abilitatea managerului de proiect poate
determina surmontarea acestor obstacole. In acest context, managerul de proiect trebuie sa
dispuna de capacitatea de a alege cea mai buna cale pentru evitarea si depasirea
obstacolelor si sa realizeze actiunile de remediere necesare la intilnirea unor nea&unsuri.
Practica dovedeste ca fara o planificare riguroasa, proiectele complexe nu pot fi
realizate deoarece o estimare a costurilor si a termenelor de realizare pentru activitatile
implicate necesita o buna pregatire inca de la inceput.
'ara o planificare prealabila, ne intrebam: cum s-ar putea prevedea termenele finale
si cum s-ar analiza daca proiectul a fost realizat la timp si daca s-a incadrat in bugetul de
c%eltuieli prevazut( )um se poate estima forta de munca necesara, atat din punct de
vedere numeric, cat si ca pregatire(
Pentru toate aceste probleme solutia este de a se elabora un plan bine fundamentat
inca de la inceput.)u toate ca o serie de probleme pot aparea in diferite stadii de realizare
a proiectului, insa, cel mai adesea,ele isi au originea intr-o planificare inadecvata.
Pe toata durata de realizare si de punere in functiune a proiectelor informatice, intre
managerul de proiect si factorii de decizie din unitatea beneficiara trebuie sa existe o
permanenta colaborare si conlucrare. In aceasta colaborare, trebuie sa se determine
conditiile si planul de desfasurare a proiectului informatic. *otodata, inainte de intra in
detalii cu privire la planificarea in timp a activitatilor ec%ipei, managerul de proiect va
trebui sa cunoasca raspunsul la unele intrebari:
1. )are este bugetul general disponibil pentru proiect(
2. In cat timp se doreste sa fie realizat si implementat proiectul(
3. )are este data aproximativa a implementarii(
4. )are este personalul disponibil(
5. )e %ard+are si soft+are exista in cadrul unitatii beneficiare si cit de apropriat este
acesta de cel pe care se intentioneaza a fi implementat proiectul(
6. )ine va asigura mentinerea sistemului dupa punerea lui in functiune(
7. )ine va raspunde din partea beneficiarului de implementarea proiectului(
8. )are sunt persoanele competente ce vor participa din partea beneficiarului la
realizarea proiectului(
,
Raspunsurile la aceste intrebari pot fi considerate cerinte prestabilite in activitatea
de planificare a proiectelor informatice. -ecunoasterea informatiilor sau absenta unor
raspunsuri satisfacatoare vor afecta elaborarea si fundamentarea planului de realizare si
punerea in functiune a proiectului sistemului informatic.
*ot ca cerinta prestabilita poate fi considerata si stabilirea metodologiei de
planificare, urmarire si raportare. In prezent, se practica varianta prin care se detaliaza
numai primele faze ale proiectului, iar pentru proiectare, programare si testare se va limita
doar la o sc%itare a planului. Deci desfasurarea proiectelor informatice impune pe langa
cerintele de mai sus alegerea ec%ipei de proiect si a responsabilului de proiect care se face
prin respectarea cerintelor referitoare la competentele profesionale necesare pentru
proiectul respectiv. Un proiect se organizeaza si exista pe durata ciclului de dezvoltare a
produsului.serviciului de realizat. Dupa receptia acestuia, proiectul se considera terminat
daca se intra in perioada de garantie pentru clientul extern!.$ data cunoscute cerintele
planificarii, managerul de proiect realizeaza planificarea detaliata a proiectului. Acest
lucru presupune: cunoasterea detaliata a activitatilor si respectiv stabilirea succesiunii
logice a acestora in cadrul fiecarei etape. Dupa inventarierea si intocmirea listei de
activitati se deduc subactivitatile si se stabileste lizare a proiectului informatic In
concluzie, realizarea unui proiect incepe deci cu exprimarea cerintelor si se finalizeaza
prin obtinerea unui program operational. Intre aceste &aloane se deruleaza asa numitul
ciclu de dezvoltare soft+are, format dintr-o suita de perioade care se numesc faze si care
se suprapun in parte. In interiorul fazelor se definesc activitati. /ai precis ciclul de viata
inseamna definirea unei suite de faze, a activitatilor efectuate in timpul acestor faze, a
rezultatelor documente, programe! ce se obtin si a dependentelor intre faze.
Astfel in cadrul etapei de fezabilitate avem urmatoarele tipuri de activitati:
- stabilirea bugetelor"
- stabilirea termenelor"
- intervievarea conducerii firmei beneficiare"
- stabilirea si fundamentarea obiectivelor sistemului"
- realizarea analizei cost.beneficiu si obtinerea acordului
compartimentului utilizator"
- sc%itarea ar%itecturiisc%emei de principiu! a sistemului propus
- intocmirea unui raport de fezabilitate"
- prezentarea raportului de fezabilitate conducerii firmei beneficiare.
)ea de-a doua etapa, etapa de analiza cuprinde urmatoarele tipuri de activitati:
- intocmirea unui c%estionar pentru utilizatori"
- stringerea unui set complet de documente despre sistemul existent"
- planificarea interviurilor cu utilizatorii"
- pregatirea membrilor ec%ipei in te%nica interviului"
- elaborarea sc%emelor fluxurilor si circuitelor informationale si analiza
acestora"
0
- definirea intrarilor.iesirilor si estimarea volumului de date, atit cel
existent cit si cel prevazut"
- elaborarea documentatiei pentru cele constatate"
- prezentarea situatiei in fata conducerii firmei beneficiare"
- definirea unor proceduri de control si raportare a sc%imbarilor.
)ea de-a treia etapa, a !"ie#ta!ii cuprinde activitatile:
- definirea metodologiei de proiectare"
- proiectarea intrarilor"
- proiectarea procedurilor"
- proiectarea rapoartelor de iesire"
- proiectarea fisierelor sau a bazei de date"
- proiectarea strategiei de testare si integrare logica"
- elaborarea documentatiei proiectului de ansamblu"
- definirea interfetelor cu alte sisteme"
- proiectarea modulelor si datelor de test.
A patra etapa de !"$!a%a!e include urmatoarele etape:
- elaborarea specificatiilor programelor"
- verificarea specificatiilor programelor"
- descompunerea programelor pe module si atribuirea de sarcini
programatorilor"
- scrierea programelor in limba& ales"
- testarea modulelor si a legaturilor dintre acestea"
- verificarea calitatii programelor"
- elaborarea documentatiei programelor.
A cincea etapa si ultima, cea de te&ta!e &i i%le%enta!e cuprinde activitatile:
asigurarea conditiilor pentru implementare"
difuzarea instructiunilor de executare a procedurilor"
instruirea personalului utilizator"
asigurarea conditiilor organizatorice necesare"
asigurarea conditiilor materiale"
asigurarea fondului de date"
executarea procedurilor de conversie"
testarea integrarii complete"
verificarea performantelor"
definitivarea documentatiei"
1
testarea de receptie completa"
semnarea receptiei complete.
*oate metodele, te%nicile si instrumentele folosite in activitatea de planificare si
control a proiectelor presupun realizarea in avans a urmatoarelor activitati:
- intocmirea listei activitatilor implicate in proiect"
- stabilirea succesiunii logice de realizare a activitatilor"
- estimarea duratei fiecarei activitati"
- stabilirea activitatilor ce se pot executa in paralel.
)a rezultate, metodele de planificare si control pot oferi, de la caz la caz,
urmatoarele informatii:
- imaginea aproximativa a proiectuluigraful retelei de activitati!"
- graficul calendaristic de realizare a activitatilor proiectului"
- -clasificarea activitatilor in doua mari categoriiA,2!, in functie de
ponderea duratei acestora in ponderea totala a proiectului. In acest mod vor
rezulta doua clase. )lasa A ce va include ,34 din totalul de activitati care
insumeaza 534 din durata de realizare a intregului proiect, acestea fiind
numite activitati critice. )lasa 2 va include celelalte activitati, numite si
activitati necritice, in sensul ca prezinta o anumita rezerva de timp in
realizarea lor.
6ruparea activitatilor in cele doua categorii prezinta interes cel putin din urmatoarele
doua considerente:
ofera posibilitatea concentrarii atentiei asupra realizarii si urmaririi principalelor
activitati sau c%iar a reducerii termenului de punere in functiune a sistemului informatic
proiectat"
datorita faptului ca grupa A detine ponderea cea mai mare si sub aspectul
resurselor bugetare implicate, este firesc sa ne concentram atentia asupra acestei grupe in
scopul identificarii posibilitatilor de reducere a costurilor proiectelor informatice. Astfel,
riscam sa ne dispersam atentia asupra unor multiple activitati marunte iar efectele
economice rezultate sa fie nesemnificative. In prezent, se utilizeaza o gama mai larga de
metode, te%nici si instrumente in activitatea de planificare si control a proiectelor, avind
7
un carater general de aplicabilitate, nu numai pentru proiecte informatice:graficele
6rantt" analiza drumului critic )ritical Pad /et%od 8 )P/!" metoda P9R* Program
9valuation and Revie+ *e%ni:ues!" metoda potentialelor /etro Potential /et%od 8
/P/!.
'. DIFICULTATI IN PLANIFICAREA SI EVALUAREA
PROIECTELOR
Dupa afirmatiile de mai sus, planificarea se refera la faze, activitati si sarcini adica
la procesul de dezvoltare soft+are!. Insa de multe ori proiectele soft+are deriva, in sensul
ca ele iau mai mult timp decit s-a prevazut, si costa mai mult decit s-a evaluat. Acest fapt
este deseori pus pe seama clientului care-si sc%imba des cerintele.
)auzele care duc la esecul proiectelor soft+are pot fi diverse, dupa cum urmeaza:
- planificarea insuficienta"
- managementul neexperimentat"
- ineficacitatea procedurilor de control a modificarilor"
- termenele si evaluarile de sarcini nerealiste.
Dintre acestea cea mai importanta cauza este planificarea insuficienta care nu
poate fi facuta bine daca se dispune de o definitie precisa si constanta a fazelor, a
sarcinilor si activitatilor si se aplica o metoda de evaluare a sarcinilor si a termenelor.
-ecesitatea estimarii costurilor rezulta din cerintele de incadrare in timp si de
utilizare eficienta a resurselor. Aceasta problema este deosebit de dificila si, in
consecinta si-a gasit tirziu in raport cu celelalte ramuri ale ingineriei soft+are o
modelare si incercari de solutii.
9stimarea de proiect se face cel putin o data inainte de inceperea propriu-zisa a
proiectului, dar poate fi refacuta si pe parcursul dezvoltarii proiectului. Precizia
estimarii variaza in functie de faza in care este facuta si se amelioreaza in timp.
;olutiile adoptate pentru evaluarea costurilor proiectarii depind de modul in care se
exercita gestiunea proiectelor la nivelul firmei si, ca atare, de metodele si instrumentele
<
utilizate, de practicile, de calitatile si de stilul de lucru al ec%ipelor, de regulile de
organizare si nu in ultimul rind de stilul de conducere si de urmarire a proiectelor.
$ evaluare precisa, bazata pe o metodologie clara, pertinenta si legata de
planificarea activitatilor nu se efectueaza decit pentru etapa urmatoare" pentru celelalte
etape din aval efectuindu-se numai o estimare globala. In concluzie evaluarea va fi cu
atit mai buna cu cit ea se face odata cu planificarea proiectului si cu cit este aplicata o
metoda de evaluare a proiectelor.
(. INITIEREA PROIECTULUI
Proiectele sunt de doua feluri: externe si interne.Proiectele externe sunt, in general,
initiate ca urmare a unei cereri de oferta venite din partea unui client.)ererea de oferta
se materializeaza de la caz la caz printr-un caiet de sarcini sau pur si simplu printr-o
cerere verbala.
Proiectele interne sunt initiate ca urmare a unei decizii interne a furnizorului,
formulate de departamentul de mar=eting si aprobate de conducerea furnizorului.
Aceasta decizie se constituie la rindul sau intr-un caiet de sarcini. Un proiect intern
poate sa priveasca dezvoltarea unui nou program sau realizarea unei noi versiuni a unui
program de&a existent.
Dupa stabilirea caietului de sarcini, directorul te%nic trebuie sa elaboreze o oferta
raspuns la caietul de sarcini! sau sa delege elaborarea acestui caiet de sarcini.
9laboratorul ofertei decide descompunerea proiectului intr-un ansamblu cit mai
detaliat de sarcini elementare grupind aceste sarcini in faze, etape, loturi. definind astfel
o varianta de proces de dezvoltare specifica proiectului in cauza. *ot el verifica
cerintele si specificatiile proiectului cele care apar in caietul de sarcini, in alte
documente furnizate de client sau alte documentatii adiacente! si identifica procesele
proiectului.
;e estimeaza efortul necesar pentru fiecare sarcina in parte si pentru gestiunea
globala de proiect, conform g%idului de estimare proiect. Aceasta estimare trebuie sa
cuprinda impartirea estimarilor efortului pe procese si etape.
De regula, elaboratorul ofertei organizeaza lista sarcinilor aferente proiectului
proiect solicita intr-o diagrama 6rantt si o diagrama Pert.
>
Dupa aprobarea contractului cu clientul, directorul te%nic numeste un sef de proiect
care va conduce la dezvoltarea proiectului, comitetul de managerului calitatii
desemnarea unui responsabil de calitate pentru proiect. ;eful de proiect va primi caietul
de sarcini, oferta, si toate celelalte documente legate de proiect existente pina la acel
moment in dosarul de proiect.
;eful de proiect realizeaza planul proiectului in conformitate cu un sablon
standard.
Acest plan de dezvoltare face o detaliere a aspectelor de gestiune de proiect
prezentate in oferta. De regula, toate elementele din oferta se regasesc in planul de
dezvoltare. In anumite situatii si din anumite motive intre oferta si planul de dezvoltare
pot exista diferente. In acest caz diferentele sunt bine identificate si &ustificate.
)onform planului de dezvoltare, seful de proiect repartizeaza sarcinile din plan
pentru fiecare membru al ec%ipei de realizare si tine gestiunea proiectului folosindu-se
de un dosar al proiectului pe care il va actualiza periodic.
). DESFASURAREA PROIECTULUI
;eful de proiect raspunde ca proiectul sa fie realizat in conditiile definite in planul
de dezvoltare a proiectului: se asigura ca primeste regulat de la membrii ec%ipei
rapoartele privind evolutia proiectului si compara evolutia reala a proiectului dedusa
din aceste rapoarte cu cea planificata.
;eful de proiect verifica si pune la zi planificarea proiectului:
- convoaca reuniuni ale ec%ipei de proiect pentru verificarea modului cum
avanseaza proiectul si identificarea concluziilor. 'recventa reuniunilor,
participantii si metodele de urmarire a actiunilor proiectului utilizate sunt
definite in planul proiectului.
- convoaca reuniuni de verificare a etapelor, pentru evaluarea proiectului
din punct de vedere al criteriilor de intrare si iesire ale etapei. ?a aceste
reuniuni participa comitetul de proiect, inclusiv un reprezentant al
compartimentului de asigurare a calitatii. ?a recomandarea comitetului de
proiect pot participa si alte persoane, experti, alti sefi de proiecte.
)omitetul de proiect se reuneste periodic, asa cum se specifica in planul
proiectului, pentru a verifica evolutia generala raportata de seful de proiect.
5
*. CONTROLUL PROIECTULUI
Dupa cum se observa din cele cele de mai sus, munca in ec%ipa este specifica
activitatii de realizare a sistemelor informatice, conducerea proiectului revenind in sarcina
sefului de proiect. Acesta va trebui sa-si defineasca strategia si tactica care sa-I ofere
nivelul optim de control pentru ca este stiut faptul ca prea multe detalii inseamna consum
de resurse, pe cind prea putine inseamna date insuficiente pentru un control eficient.
)ontrolul este o continua estimare a progreselor realizate in dezvoltarea
proiectului, in raport cu anumite criterii. In general, aceste criterii sunt timpul, calitatea si
bugetul, insa fiecare dintre acestea pot fi la rindul lor subimpartite pe anumite obiective.
In practica controlul se desfasoara de catre seful de proiect care verifica evolutia
acestuia si priveste obiectivele de calitate definite in planul proiectului: se asigura ca
testele planificate si verificarile au fost efectuate si ca rezultatele sunt satisfacatoare si
aprobate de catre responsabilul de calitate.
In functie de gradul de complexitate a proiectelor se determina metoda de control
si raportare. Din acest punct de vedere se disting: proiecte simple, proiecte de dimensiune
medie si proiecte complexe. Proiectele simple, la care participa ec%ipe formate dintr-un
numar mic de persoane, necesita o structura simpla in care, fiecarui membru al ec%ipei I se
da o sarcina, iar acesta raporteaza la intervale mici saptaminal! direct sefului de proiect.
Acesta raporteaza operativ managerului sau direct si managerului firmei beneficiare.

@
'ig.# ;tructura simpla de raportare


intregului.Proiectele de complexitate medie, la care sunt anga&ate mai multe
persoane intre 5 si ,3 de ani! sunt structurate pe domenii si aplicatii. Pentru fiecare
aplicatie pe domeniu poate fi numita o ec%ipa si un conducator al acesteia. *otodata, poate
fi formata o ec%ipa care sa se ocupe de soft+are-ul de sistem pentru dimensionarea,
configurarea, controlul menentenenta %ard-ului si soft-ului. *inind seama de dimensiunea
si configuratia proiect este posibil ca managerul acestuia sa nu poata face fata controlului
proiectului sub aspect calitativ, situatie in care poate recurge la numirea unui responsabil
cu controlul calitativ al proiectului. Intr-un astfel de caz structura de raportare este
sugerata in figura ,.
#3


'I6., ;tructura de complexitate medie
Proiectele complexe cu durata de realizare mare ,-0ani ! si cu un efectiv
important de persoane peste ,3!, necesita niveluri intermediare de conducere si raportare.
In aceste conditii structura tipica de raportare este sugerata in figura 0.
##
'I6.0 ;tructura de raportare pentru proiectele complexe
+. INC,EIEREA PROIECTULUI
#,
?a sfirsitul proiectului, seful de proiect tine o reuniune de inc%eiere a proiectului.
Participantii sunt definiti de catre seful de proiect, dar in mod obisnuit acestia sunt:
responsabilul de calitate, reprezentanti ai ec%ipei proiectului, comitetul de proiect si
utilizatori. ;e realizeaza un raport care se distribuie ec%ipei proiectului, comitetului de
proiect si responsabilului de calitate.
Responsabilul de calitate decide daca recomandarile pentru proiectele viitoare
prevazute in raport necesita initierea unor actiuni colective. In acest caz, responsabilul de
calitate cere sefului de proiect sa completeze un formular de actiuni colective.
;eful de proiect pune in ordine dosarul proiectului pentru ar%ivare. ;e pastreaza
toata corespondenta clientului impreuna cu versiunile finale ale documentatiei complete a
proiectului.
)ontractul, actul de vandare al clientului si alte documente importante sunt trecute
contabilitatii pentru ar%ivare separata.
Documentatia privind asistenta te%nica a proiectului, informatiile privind
configuratia sunt extrase din dosarul proiectului si trecute ca document de control
responsabilului de asistenta te%nica 8 daca este cazul.
Pe parcursul perioadei de garantie, seful de proiect va pastra in continuare si va tine
la zi dosarul de proiect.
?a sfirsitul perioadei de garantie dosarul de proiect este ar%ivat.
-. CONCLU.IE
)are sunt problemele si solutiile pentru ameliorarea succesului proiectelor
soft+are( Problematica este prea vasta si de aceea s-au atins in cele de mai sus citeva
aspecte. Primul raspuns ar putea fi sa imbunatatim calitatea, iar aici multi poate se si
gindesc la cunoscutul model propus de I;$ @33# pentru un sistem al calitatii pentru
#0
domeniul soft+are ( standardul ne este cunoscut, ;oft+in fiind certificata I;$ @33# in
domeniul dezvoltarii soft+are).
Dar soft+are-ul se incadreaza foarte greu in I;$ @33# pentru ca soft+are-ul
e prea special, prea diferit de productia materiala. Acest specific al proiectelor soft+are
este tinta spre care ne indreptam eforturile de ameliorare.
Prioritatea nu este cercetarea rezultatelor, ci a proceselor care conduc la
aceste rezultate. Problema care trebuie rezolvata este o noua organizare, o ameliorare
continua, cu un accent deosebit pe cooperare intre oameni. Iar conducerea intreprinderii
trebuie sa genereze ea insasi si sa promoveze punerea in valoare a climatului favorabil
cooperarii.
)u alte cuvinte, sa nu cautam glontul de argint, adica o solutie panaceu
pentru organizarea si conducerea proiectelor soft+are, ca s-ar putea sa nu existe. In
sc%imb, putem avea o abordare mai modesta, bazata pe ideea de perfectionare continua:
adica sa ne imbunatatim permanent activitatea si atat.
#1