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