MANAGEMENTUL PROIECTELOR SOFTWARE

REFERAT

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. În acest sens, este lesne de intuit paralelismul dintre acestea. Asa cum obiectivele de investitii necesita un plan de realizare si de urmarire sub aspectul încadrarii în costuri, termene de punere în functiune si niveluri calitative, tot la fel se pune problema si pentru realizarea unui proiect informatic.

1. CE ESTE UN PROIECT ÎN GENERAL?

Asadar sa încercam sa reproducem o definitie, definind notiunea utilizata. Un proiect este:

un ansamblu de activitati, apartinînd unor faze care se interfereaza între ele (cum?);

avînd un sfîrsit comun si fericit (ce?);

permitînd satisfacerea unei nevoi sau cerinte identificate (de ce?);

prin contributia unor participanti (cine?);

coordonati de un responsabil;

pentru care exista un obiectiv triplu: costul, termenul si calitatea produsului rezultat (cît?, cînd?, conformitate?).

Din cîte se observa aceasta definitie ilustreaza complexitatea conceptului iar daca am vrea sa întelegem 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 în cadrul relatiei contractuale client-furnizor);

gestiunea termenelor (este o exigenta mai mult sau mai putin importanta, în functie de prioritatile organizatiei clientului si de criticitatea proiectului);

respectarea cerinţ 20220h78u ;elor exprimate (este exigenta cea mai tare, fara îndoiala).

2. PLANIFICAREA ACTIVITĂŢILOR

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 întîlni multe obstacole pe durata realizarii proiectului. Unele din acestea sunt previzibile si, cu ajutorul experientei acumulate în decursul realizarii unor proiecte anterioare, pot fi depasite, altele nu pot fi prevazute si numai abilitatea managerului de proiect poate determina surmontarea acestor obstacole. În 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 întîlnirea 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 înca de la început.

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 în bugetul de cheltuieli prevazut? Cum se poate estima forta de munca necesara, atît din punct de vedere numeric, cît si ca pregatire?.

Pentru toate aceste probleme solutia este de a se elabora un plan bine fundamentat înca de la inceput.Cu toate ca o serie de probleme pot aparea în diferite stadii de realizare a proiectului, însa, cel mai adesea,ele îsi au originea într-o planificare inadecvata.

Pe toata durata de realizare si de punere în functiune a proiectelor informatice, între managerul de proiect si factorii de decizie din unitatea beneficiara trebuie sa existe o permanenta colaborare si conlucrare. În aceasta colaborare, trebuie sa se determine conditiile si planul de desfasurare a proiectului informatic. Totodata, înainte de intra în detalii cu privire la planificarea în timp a activitatilor echipei, managerul de proiect va trebui sa cunoasca raspunsul la unele întrebari:

Care este bugetul general disponibil pentru proiect?;

În ce timp se doreste sa fie realizat si implementat proiectul?;

Care este data aproximativa a implementarii?;

Care este personalul disponibil?;

Ce hardware si software exista în cadrul unitatii beneficiare si cît de apropriat este acesta de cel pe care se intentioneaza a fi implementat proiectul?;

Cine va asigura mentinerea sistemului dupa punerea lui în functiune?;

Cine va raspunde din partea beneficiarului de implementarea proiectului?;

Care mai sunt persoanele competente ce vor participa din partea beneficiarului la realizarea proiectului?.

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

Tot ca cerinta prestabilita poate fi considerata si stabilirea metodologiei de planificare, urmarire si raportare. În 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 software impune pe lînga 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 în 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 în cadrul fiecarei etape. Dupa inventarierea si întocmirea listei de activitati se deduc subactivitatile si se stabileste succesiunea logica si timpul afectat fiecareia. În cele ce urmeaza sugeram un exemplu de lista de activitati, grupate pe etape de realizare a proiectului informatic În concluzie, realizarea unui proiect începe deci cu exprimarea cerintelor si se finalizeaza prin obtinerea unui program operational. Între aceste jaloane se deruleaza asa numitul ciclu de dezvoltare software, format dintr-o suita de perioade care se numesc faze si care se suprapun în parte. În interiorul fazelor se definesc activitati. Mai precis ciclul de viata înseamna definirea unei suite de faze, a activitatilor efectuate în timpul acestor faze, a rezultatelor (documente, programe) ce se obtin si a dependentelor între faze.

Astfel în 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

întocmirea unui raport de fezabilitate;

prezentarea raportului de fezabilitate conducerii firmei beneficiare.

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

întocmirea unui chestionar pentru utilizatori;

strîngerea unui set complet de documente despre sistemul existent;

planificarea interviurilor cu utilizatorii;

pregatirea membrilor echipei în tehnica interviului;

elaborarea schemelor fluxurilor si circuitelor informationale si analiza acestora;

definirea intrarilor/iesirilor si estimarea volumului de date, atît cel existent cît si cel prevazut;

elaborarea documentatiei pentru cele constatate;

prezentarea situatiei în 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 în 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;

testarea de receptie completa;

semnarea receptiei complete.

Toate metodele, tehnicile si instrumentele folosite în activitatea de planificare si control a proiectelor presupun realizarea în avans a urmatoarelor activitati:

- întocmirea listei activitatilor implicate în proiect;

- stabilirea succesiunii logice de realizare a activitatilor;

- estimarea duratei fiecarei activitati;

- stabilirea activitatilor ce se pot executa în 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 în doua mari categorii(A,B), în functie de ponderea duratei acestora în ponderea totala a proiectului. În acest mod vor rezulta doua clase. Clasa A ce va include 20% din totalul de activitati care însumeaza 80% din durata de realizare a întregului proiect, acestea fiind numite activitati critice. Clasa B va include celelalte activitati, numite si activitati necritice, în sensul ca prezinta o anumita rezerva de timp în realizarea lor.

Gruparea activitatilor în 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 în 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 în 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. În prezent, se utilizeaza o gama mai larga de metode, tehnici si instrumente în activitatea de planificare si control a proiectelor, avînd 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. DIFICULTĂŢI ÎN PLANIFICAREA sI EVALUAREA PROIECTELOR

Dupa afirmatiile de mai sus, planificarea se refera la faze, activitati si sarcini (adica la procesul de dezvoltare software). Însa de multe ori proiectele software deriva, în sensul ca ele iau mai mult timp decît s-a prevazut, si costa mai mult decît 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:

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 încadrare în timp si de utilizare eficienta a resurselor. Aceasta problema este deosebit de dificila si, în consecinta si-a gasit tîrziu în raport cu celelalte ramuri ale ingineriei software o modelare si încercari de solutii.

Estimarea de proiect se face cel putin o data înainte de începerea propriu-zisa a proiectului, dar poate fi refacuta si pe parcursul dezvoltarii proiectului. Precizia estimarii variaza în functie de faza în care este facuta si se amelioreaza în timp.

Solutiile adoptate pentru evaluarea costurilor proiectarii depind de modul în 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 echipelor, de regulile de organizare si nu în ultimul rînd 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 decît pentru etapa urmatoare; pentru celelalte etape din aval efectuîndu-se numai o estimare globala. În concluzie evaluarea va fi cu atît mai buna cu cît ea se face odata cu planificarea proiectului si cu cît este aplicata o metoda de evaluare a proiectelor.

4. INIŢIEREA PROIECTULUI

Proiectele sunt de doua feluri: externe si interne.Proiectele externe sunt, în 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 rîndul sau într-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 într-un ansamblu cît mai detaliat de sarcini elementare grupînd aceste sarcini în faze, etape, loturi. definind astfel o varianta de proces de dezvoltare specifica proiectului în cauza. Tot el verifica cerintele si specificatiile proiectului (cele care apar în caietul de sarcini, în alte documente furnizate de client sau alte documentatii adiacente) si identifica procesele proiectului.

Se estimeaza efortul necesar pentru fiecare sarcina în parte si pentru gestiunea globala de proiect, conform ghidului de estimare proiect. Aceasta estimare trebuie sa cuprinda împartirea estimarilor efortului pe procese si etape.

De regula, elaboratorul ofertei organizeaza lista sarcinilor aferente proiectului într-o diagrama Grantt si o diagrama Pert.

Dupa aprobarea contractului cu clientul, directorul tehnic numeste un sef de proiect care va conduce la dezvoltarea proiectului, comitetul de proiect solicita 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 pîna la acel moment în dosarul de proiect.

seful de proiect realizeaza planul proiectului în conformitate cu un sablon standard.

Acest plan de dezvoltare face o detaliere a aspectelor de gestiune de proiect prezentate în oferta. De regula, toate elementele din oferta se regasesc în planul de dezvoltare. În anumite situatii si din anumite motive între oferta si planul de dezvoltare pot exista diferente. În 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 îl va actualiza periodic.

5. DESFĂsURAREA PROIECTULUI

seful de proiect raspunde ca proiectul sa fie realizat în conditiile definite în 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:

6. CONTROLUL PROIECTULUI

7. ÎNCHEIEREA PROIECTULUI

La sfîrsitul proiectului, seful de proiect tine o reuniune de încheiere a proiectului. Participantii sunt definiti de catre seful de proiect, dar în 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 în raport necesita initierea unor actiuni colective. În acest caz, responsabilul de calitate cere sefului de proiect sa completeze un formular de actiuni colective.

seful de proiect pune în ordine dosarul proiectului pentru arhivare. Se pastreaza toata corespondenta clientului împreuna 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 în continuare si va tine la zi dosarul de proiect.

La sfîrsitul perioadei de garantie dosarul de proiect este arhivat.

8. CONCLUZIE

BIBLIOGRAFIE:

I. ROsCA, N.DAVIDESCU, E. MACOVEI, V. RĂILEANU -PROIECTAREA SISTEMELOR INFORMATICE FINANCIAR CONTABILE- BUCUREsTI 1993

INFORMATICĂ ECONOMICĂ - NR.9-1999

INFORMATICĂ ECONOMICĂ - NR.2 1997

PS REPORT - OCTOMBRIE 1999

W.W.W.MENSOFT.COM