Sunteți pe pagina 1din 14

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.

1
2. PLANIFICAREA ACTIVITATILOR

DIN CADRUL PROIECTELOR INFORMATICE

Obiectivul planificarii proiectelor este acela de a asigura realizarea acestora la


termenele si cheltuielile prestabilite. Acest obiectiv nu este usor de realizat si poate intalni
multe obstacole pe durata realizarii proiectului. Unele din acestea sunt previzibile si, cu
ajutorul 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 neajunsuri.

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.

Fara 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
cheltuieli prevazut? Cum 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.Cu 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. Totodata, inainte de intra in
detalii cu privire la planificarea in timp a activitatilor echipei, managerul de proiect va
trebui sa cunoasca raspunsul la unele intrebari:

1. Care este bugetul general disponibil pentru proiect?


2. In cat timp se doreste sa fie realizat si implementat proiectul?
3. Care este data aproximativa a implementarii?
4. Care este personalul disponibil?
5. Ce hardware si software exista in cadrul unitatii beneficiare si cit de apropriat este
acesta de cel pe care se intentioneaza a fi implementat proiectul?
6. Cine va asigura mentinerea sistemului dupa punerea lui in functiune?
7. Cine va raspunde din partea beneficiarului de implementarea proiectului?
8. Care sunt persoanele competente ce vor participa din partea beneficiarului la
realizarea proiectului?

2
Raspunsurile la aceste intrebari pot fi considerate cerinte prestabilite in activitatea
de planificare a proiectelor informatice. Necunoasterea informatiilor sau absenta unor
raspunsuri satisfacatoare vor afecta elaborarea si fundamentarea planului de realizare si
punerea in functiune a proiectului sistemului informatic.

Tot 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 schitare a planului. Deci desfasurarea proiectelor informatice impune pe langa
cerintele de mai sus alegerea echipei 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).O 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 jaloane se deruleaza asa numitul
ciclu de dezvoltare software, format dintr-o suita de perioade care se numesc faze si care
se suprapun in parte. In interiorul fazelor se definesc activitati. Mai 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;
- schitarea arhitecturii(schemei de principiu) a sistemului propus
- intocmirea unui raport de fezabilitate;
- prezentarea raportului de fezabilitate conducerii firmei beneficiare.

Cea de-a doua etapa, etapa de analiza cuprinde urmatoarele tipuri de activitati:

- intocmirea unui chestionar pentru utilizatori;


- stringerea unui set complet de documente despre sistemul existent;
- planificarea interviurilor cu utilizatorii;
- pregatirea membrilor echipei in tehnica interviului;
- elaborarea schemelor fluxurilor si circuitelor informationale si analiza
acestora;

3
- 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 schimbarilor.

Cea de-a treia etapa, a proiectarii 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 programare include urmatoarele etape:

- elaborarea specificatiilor programelor;


- verificarea specificatiilor programelor;
- descompunerea programelor pe module si atribuirea de sarcini
programatorilor;
- scrierea programelor in limbaj ales;
- testarea modulelor si a legaturilor dintre acestea;
- verificarea calitatii programelor;
- elaborarea documentatiei programelor.

A cincea etapa si ultima, cea de testare si implementare 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;

4
•testarea de receptie completa;

•semnarea receptiei complete.

Toate metodele, tehnicile 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.

Ca rezultate, metodele de planificare si control pot oferi, de la caz la caz,


urmatoarele informatii:

- imaginea aproximativa a proiectului(graful retelei de activitati);


- graficul calendaristic de realizare a activitatilor proiectului;
- -clasificarea activitatilor in doua mari categorii(A,B), in functie de
ponderea duratei acestora in ponderea totala a proiectului. In acest mod vor
rezulta doua clase. Clasa A ce va include 20% din totalul de activitati care
insumeaza 80% din durata de realizare a intregului proiect, acestea fiind
numite activitati critice. Clasa B va include celelalte activitati, numite si
activitati necritice, in sensul ca prezinta o anumita rezerva de timp in
realizarea lor.

Gruparea activitatilor in cele doua categorii prezinta interes cel putin din urmatoarele
doua considerente:

− ofera posibilitatea concentrarii atentiei asupra realizarii si urmaririi principalelor


activitati sau chiar 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, tehnici si instrumente in activitatea de planificare si control a proiectelor, avind

5
un carater general de aplicabilitate, nu numai pentru proiecte (informatice:graficele
Grantt; analiza drumului critic (Critical Pad Method – CPM); metoda PERT Program
Evaluation and Review Tehniques); metoda potentialelor (Metro Potential Method –
MPM).

3. DIFICULTATI IN PLANIFICAREA SI EVALUAREA


PROIECTELOR

Dupa afirmatiile de mai sus, planificarea se refera la faze, activitati si sarcini (adica
la procesul de dezvoltare software). Insa de multe ori proiectele software 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 schimba des cerintele.

Cauzele care duc la esecul proiectelor software 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.
Necesitatea 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 software o
modelare si incercari de solutii.
Estimarea 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.
Solutiile adoptate pentru evaluarea costurilor proiectarii depind de modul in care se
exercita gestiunea proiectelor la nivelul firmei si, ca atare, de metodele si instrumentele

6
utilizate, de practicile, de calitatile si de stilul de lucru al echipelor, de regulile de
organizare si nu in ultimul rind de stilul de conducere si de urmarire a proiectelor.
O 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.

4. 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.Cererea 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 marketing 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 deja existent.
Dupa stabilirea caietului de sarcini, directorul tehnic trebuie sa elaboreze o oferta
(raspuns la caietul de sarcini) sau sa delege elaborarea acestui caiet de sarcini.
Elaboratorul 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. Tot 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.
Se estimeaza efortul necesar pentru fiecare sarcina in parte si pentru gestiunea
globala de proiect, conform ghidului 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 Grantt si o diagrama Pert.

7
Dupa aprobarea contractului cu clientul, directorul tehnic numeste un sef de proiect
care va conduce la dezvoltarea proiectului, comitetul de managerului calitatii
desemnarea unui responsabil de calitate pentru proiect. Seful de proiect va primi caietul
de sarcini, oferta, si toate celelalte documente legate de proiect existente pina la acel
moment in dosarul de proiect.
Seful 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 justificate.
Conform planului de dezvoltare, seful de proiect repartizeaza sarcinile din plan
pentru fiecare membru al echipei de realizare si tine gestiunea proiectului folosindu-se
de un dosar al proiectului pe care il va actualiza periodic.

5. DESFASURAREA PROIECTULUI
Seful 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 echipei
rapoartele privind evolutia proiectului si compara evolutia reala a proiectului dedusa
din aceste rapoarte cu cea planificata.
Seful de proiect verifica si pune la zi planificarea proiectului:
- convoaca reuniuni ale echipei de proiect pentru verificarea modului cum
avanseaza proiectul si identificarea concluziilor. Frecventa 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. La aceste
reuniuni participa comitetul de proiect, inclusiv un reprezentant al
compartimentului de asigurare a calitatii. La recomandarea comitetului de
proiect pot participa si alte persoane, experti, alti sefi de proiecte.
Comitetul de proiect se reuneste periodic, asa cum se specifica in planul
proiectului, pentru a verifica evolutia generala raportata de seful de proiect.

8
6. CONTROLUL PROIECTULUI

Dupa cum se observa din cele cele de mai sus, munca in echipa 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.

Controlul 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 echipe formate dintr-un
numar mic de persoane, necesita o structura simpla in care, fiecarui membru al echipei 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.

9
Fig.1 Structura simpla de raportare

intregului.Proiectele de complexitate medie, la care sunt angajate mai multe


persoane (intre 8 si 20 de ani) sunt structurate pe domenii si aplicatii. Pentru fiecare
aplicatie pe domeniu poate fi numita o echipa si un conducator al acesteia. Totodata, poate
fi formata o echipa care sa se ocupe de software-ul de sistem pentru dimensionarea,
configurarea, controlul menentenenta hard-ului si soft-ului. Tinind 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 2.

10
FIG.2 Structura de complexitate medie

Proiectele complexe cu durata de realizare mare ( 2-3ani ) si cu un efectiv


important de persoane (peste 20), necesita niveluri intermediare de conducere si raportare.
In aceste conditii structura tipica de raportare este sugerata in figura 3.

11
FIG.3 Structura de raportare pentru proiectele complexe

7. INCHEIEREA PROIECTULUI

12
La sfirsitul proiectului, seful de proiect tine o reuniune de incheiere a proiectului.
Participantii sunt definiti de catre seful de proiect, dar in mod obisnuit acestia sunt:
responsabilul de calitate, reprezentanti ai echipei proiectului, comitetul de proiect si
utilizatori. Se realizeaza un raport care se distribuie echipei 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.

Seful de proiect pune in ordine dosarul proiectului pentru arhivare. Se pastreaza


toata corespondenta clientului impreuna cu versiunile finale ale documentatiei complete a
proiectului.

Contractul, actul de vandare al clientului si alte documente importante sunt trecute


contabilitatii pentru arhivare separata.

Documentatia privind asistenta tehnica a proiectului, informatiile privind


configuratia sunt extrase din dosarul proiectului si trecute ca document de control
responsabilului de asistenta tehnica – daca este cazul.

Pe parcursul perioadei de garantie, seful de proiect va pastra in continuare si va tine


la zi dosarul de proiect.

La sfirsitul perioadei de garantie dosarul de proiect este arhivat.

8. CONCLUZIE

Care sunt problemele si solutiile pentru ameliorarea succesului proiectelor


software? 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 ISO 9001 pentru un sistem al calitatii pentru

13
domeniul software ( standardul ne este cunoscut, Softwin fiind certificata ISO 9001 in
domeniul dezvoltarii software).

Dar software-ul se incadreaza foarte greu in ISO 9001 pentru ca software-ul


e prea special, prea diferit de productia materiala. Acest specific al proiectelor software
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.

Cu alte cuvinte, sa nu cautam ″ glontul de argint″ , adica o solutie panaceu


pentru organizarea si conducerea proiectelor software, ca s-ar putea sa nu existe. In
schimb, putem avea o abordare mai modesta, bazata pe ideea de perfectionare continua:
adica sa ne imbunatatim permanent activitatea si atat.

14