8-1

Conducerea procesului de realizare a produselor program

Capitolul 8. Conducerea procesului de realizare a produselor

program
8.1.
generale

Aspecte

Procesul de realizare a unui produs program devine un proces deosebit de complex odat cu
cresterea dimensiunii produselor program (de regul formate din mai multe componente
intercorelate),

creterea exigenelor privind calitatea produselor

program,
antrenarea i consumarea unui volum mare de resurse umane i de tehnic de calcul, ceea ce
conduce la costuri nsemnate.
n aceste condiii, procesul de realizare a produselor software trebuie bine structurat, planificat,
organizat, controlat i evaluat, astfel nct s se obin rezultatele scontate, att sub aspect
cantitativ, ct i calitativ, la termenul i cu costurile estimate iniial. Aceast activitate, denumit
conducerea proiectului, interacioneaz n mod direct cu procesul de realizare a produsului program
n cazul realizrii produselor program, proiectul constituie forma organizat de ndeplinire a unei
sarcini specificate (prin tema de realizare / tema proiectului), cu ajutorul unui colectiv de specialiti
(echipa sau echipele proiectului) condus de un responsabil (eful proiectului).
Conducerea proiectului urmrete n principal stabilirea i respectarea parametrilor proiectului,
respectiv calitate, termene i costuri.
n realizarea unui produs program se urmrete, deci, concomitent reducerea costurilor, a termenului
de realizare i creterea calitii produsului. Aceste lucruri nu pot fi realizate n acelai timp pentru c
diferitele criterii sunt neconcordante. n figura 8.1 se observ c lund n considerare un anumit nivel
al calitii, al costurilor i anumite termene de realizare, se obine un triunghi a crui suprafa rmne
constant la variaia acestor mrimi [CUL 97].
SCADE

COSTURI

CRETE

CALITATE
SCADE

TERMENE

LUNGIRE

CRETE

8-22

SCURTARE

Conducerea procesului de realizare a produselor program

Fig. 8.1 Triunghiul calitate-termene-costuri

De remarcat ns c pe axa costurilor i termenelor variaia este invers dect de obicei i invers celei
de pe axa pe care reprezentm nivelul calitii. De exemplu pentru creterea calitii se fac cheltuieli
(costuri) suplimentare i/sau este necesar un timp mai mare de realizare a produsului software.
Mrimea suprafeei triunghiului depinde de stadiul tehnologic din unitatea elaboratoare de software
precum i de nivelul i experiena grupei de analiz-proiectare-programare.
Pentru desfurarea n bune condiii a procesului de realizare a produsului program, se exercit
funciile cunoscute ale conducerii de: previziune, organizare, coordonare, antrenare i controlevaluare, cu adaptrile specifice procesului condus.
Importana conducerii proiectelor / procesului de realizare a produselor program, crete odat cu
trecer- ea de la elaborarea acestora din regim "artizanal" n regim "industrial", fiind demonstrat faptul
c productivitatea muncii elaboratorilor i costurile proiectului depind direct de calitatea
conducerii acestuia.
Dup B.W. Boehm fiecare din greelile de organizare i conducere enumerate n continuare pot dubla
costurile de realizare a unui produs program i, implicit, pot diminua n aceeai proportie
productivitatea:
afectarea de personal nepotrivit n raport cu natura sarcinilor;
alternarea de perioade de "relaxare" cu perioade de "febrilitate", datorit unei proaste
planificri
i mai ales a lipsei de control al modului de ndeplinire a sarcinilor;
lipsa de recompense sau sanciuni n raport cu rezultatele activitatii;
afectarea unui personal numeros proiectului, nainte de a fi definite obiectivele i pe aceast
baz, responsabilitile fiecaruia;
lipsa de preocupare pentru asigurarea din timp a resurselor necesare realizrii proiectului (orecalculator, mijloace de comunicare, seturi de date de test, software ajutator etc.);
nevalidarea specificaiei cerinelor iniiale; neidentificarea i netratarea cu prioritate a punctelor
critice din specificaie.
Cercetrile actuale n domeniul ingineriei software-ului, att pe plan naional ct i mondial, acord o
prioritate crescnd problematicii conducerii proiectelor i n special cuantificabilitii obiectivelor,
resurselor si rezultatelor proiectului (ex: modele de evaluare a costurilor de elaborare a produselor
program, metode de msurare a productivitii muncii elaboratorilor, normarea muncii programatorilor).
Dintre funciile conducerii proiectelor de realizare a unui produs program, cele mai semnificative, sunt
estimare preliminar, planificare, organizare, coordonare, antrenare, control i evaluare.
Importana acestora, aa cum se va vedea n continuare, a condus la conceperea i utilizarea n practic
a unor metode, tehnici i instrumente specifice pentru un proiect-software. Atributele de coordonare i
antrenare se exercit de asemenea n conducerea unui proiect, fcndu-se n special apel la practici de
conducere ad-hoc i la experiena conductorilor. Trebuie de asemenea menionat c ntregul proces de
conducere al realizarii produsului program este n mod direct influenat de obiectivele generale i
structura organizatoric a organizaiei productoare de software.

8.2. Estimarea
proiectului

efortului

de

realizare

Evaluarea efortului de realizare a proiectului este o problem deosebit de important pentru stabilirea,
asigurarea i planificarea resurselor necesare desfsurrii n condiii normale a procesului de realizare a
produselor program.

In acest scop, exist diferite modele de evaluare att a efortului de realizare (exprimat de obicei n
zile/om) ct i a costurilor proiectului.
Marea majoritate a acestor modele iau n considerare urmtoarele elemente de
baz:
dimensiunea produsului program (exprimat n diferite moduri: mii linii surs, mii instruciuni
executabile, mii comenzi masin etc.);

complexitatea produsului
program;

gradul de noutate al problemei de

soluionat;

gradul de reutilizare de module sau produse program deja

existente.
Odat apreciat efortul global de realizare a produsului program, se aduc o serie de corecii n funcie
de condiiile concrete de desfurare a proiectului.
Pentru evaluarea proiectului software, se realizeaz o analiz cost-beneficiu a acestuia. Exist mai
multe abordri pentru o estimare realist a costurilor i a beneficiilor unui proiect, cea mai comun
fiind Project Justification Chain. Aceast metod subliniaz trecerea de la nivelul propunerii
obiectivului la prognoza costului, utiliznd rezultatele fiecrei activiti din seria de justificri a
proiectului, ca baz pentru activitatea urmtoare:
Obiective Scop Estimri Costuri Beneficii Riscuri
Obiective - se cumuleaz cerinele de ordin general, prin interviuri, ntlniri i sesiuni de lucru,
dup care se mpart aceste cerine pe categori i prioriti, ntr-o manier care s permit luarea
unei decizii de execuie iniiale, care va oferi direcia general de urmat.
Scop - se examineaz sistemele de acelai tip, existente sau sisteme cu caracteristici similare,
pentru a aprecia mrimea efortului de realizare al noului proiect. Se cuantific ct mai mule
rezultate ale cerinelor, pentru a facilita realizarea unei estimri ct mai exacte.
Estimri - se utilizeaz instrumente de estimare de nivel nalt sau planuri de lucru pentru
a determina necesarul aproximativ de om-ore. Acesta se compar cu experiena trecut de
dezvoltare a sistemelor pentru a-i conferi un grad de ncredere ct mai mare.
Costuri -se realizeaz foi de calcul pentru a calcula costurile cele mai mari pe baza dimensiunii
estimate a echipei de lucru, a duratei proiectului, a necesarului de om-ore i a cheltuielilor de
administrare a proiectului. Unele dintre aceste costuri pot include:
costurile cu fora de munc
costurile cu spaiul de lucru
costurile cu materiale consumabile
costuri pentru dotri tehnice (calculatoare, copiatoare etc.)
costuri administrative (telefoane, faxuri, ntreinere etc.)
costuri de transport i diurne pentru deplasri
Se compar aceste rezultate cu nivelul cel mai mare al bugetului propus, i dac este necesar, se
modific scopul iniial. Se itereaz acest proces de cte ori este necesar, pentru a realiza un
echilibru ntre costul previzionat al proiectului i rezultatele finale scontate.

Beneficii - Pentru a determina beneficiile aduse de sistem se va realiza urmtoarea

analiz:
se identific i se documenteaz ct mai multe posibile beneficii cuantificabile
se identific i se documenteaz toate beneficiile necuantificabile care pot exista

 se examineaz fiecare cerin i beneficiile pe care le poate aduce

se mpart beneficiile identificate n beneficii pe termen scurt i pe termen lung

Riscuri - se realizeaz analiza urmtoare cu scopul de a determina riscurile

proiectului:

 se identific riscurile poteniale bazate pe ansa de reuit a produsului proiectat fa de alte

produse concurente
se identific nivelul de toleran fa de erori a proiectului propus
se stabilete o strategie de conducere pentru controlul fiecrui element identificat
Urmrirea bugetului n ansamblu
Dup stabilirea costurilor, echipei de realizare i se cere s lucreze respectnd restriciile privind
mijloacele financiare i tehnice alocate.
Pe parcursul ciclului de realizare a proiectului, dac limita bugetului alocat este pe punctul de a fi
atins sau depit, se vor controla cu strictee anumite costuri reprezentative.

8.3.
Planificare
Planificarea realizrii unui produs program const n stabilirea obiectivelor proiectului i a sarcinilor de
ndeplinit, alocarea resurselor necesare i stabilirea termenelor de realizare. Previziunea, n
cazul produselor program, se realizeaz pe cele trei niveluri cunoscute: strtegic, tactic si operativ.
Planificarea strategic se realizeaz, de regul, la nivelul ntregii organizaii producatoare de software
i are n vedere:
stabilirea tipurilor de produse program pe care le elaboreaz unitatea respectiv, n raport
cu:
obiectivele generale ale unitii ;
resursele disponibile la nivelul unitii;
fondul de programe deja existent;
stabilirea nivelului tehnic i calitativ al produselor program
elaborate,
care depinde de:
competena profesional a membrilor organizaiei;
dotarea cu tehnic de calcul;
posibilitile de specializare, cooperare i procurare de produse software deja existente;
stabilirea termenelor globale de realizare a produselor program;
stabilirea costurilor globale i a preurilor de livrare a produselor
program.
Planificarea strategic are n vedere totodat organizarea intern a unitii realizatoare de produse
program (existena sau inexistena compartimentelor specializate n analiz, proiectare, programare,
ntreinere, certificarea calitaii, livrare etc.) ct i sistemul de relaii cu unitile utilizatoare i cu alte
uniti productoare de software din ar i strinatate.
Planificarea tactic se desfoar la nivelul proiectului i se refer la un produs program concret. n
mod evident, planificarea tactic este derivat din planificarea strategic. Planificarea proiectului
acoper ca orizont de timp ntreg ciclul de viat al produsului program. Ea cuprinde att elementele
legate de alocarea resurselor pe activiti ct i de planificare calendaristic a acestora.
Activitatea de baz a procesului de construire a planului este determinarea pailor individuali ai
planului de lucru. Dezvoltatea pailor planului de lucru rmne nc, oarecum, un proces creativ. Ideile
utilizate pentru formularea fazelor, activitilor i proceselor finale ale planului provin din urmtoarele
surse:

experiena acumulat n timp a autorului

planului

experiena acumulat n timp a

consultanilor

 copii ale planurilor din trecut, aflate la dispoziia autorului, i care au

avut succes
machete de planuri din diverse pachete software pentru managementul
proiectelor
planuri de lucrtu etapizate pe pai ale altor metodologii de dezvoltare a
sistemelor

combinaii ale unora sau ale tuturor surselor

precedente

Utilizarea unei anumite metodologii poate oferi anumite avantaje, precum:

metodologiile furnizeaz paii de urmat i sunt rezultatul unor experiene anterioare.
aceti pai pot fi utilizai ca punct de plecare i modificai ulterior de ctre realizatorul planului.
se reduce riscul de a trece cu vederea anumite aspecte importante
timpul de realizare al planului este mult mai redus n cazul n care se pornete de la planuri
realizate anterior dect dac iniial s-ar porni de la zero.
O schem simplificat a pailor parcursi pentru planificarea proiectului este prezentat in fig.8.2.
STRUCTURA

PLANIFICAREA SARCCINILOR

PROBLEMEI
ORGANIZAREA PROIECTULUI

NIVEL RESURSE DISPONIBILE

ALOCARE DE RESAURSE

PLANIFICARE
CALENDARISTIC A
SARCINILOR

PLANIFICARE
CALENDARISTIC A
RESURSELOR
RESTRICII

Fig. 8.2. Planificarea proiectului

a) Planificarea sarcinilor din cadrul proiectului implic o serie de decizii importante cum
sint:
alegerea modelului ciclului de via a produsului program care se va realiza;
structurarea ciclului de via pe etape, faze, activiti;
stabilirea relaiilor temporale dintre acestea (succesiune, preceden, paralelism etc.);
stabilirea tehnologiilor de realizare a produsului program;
stabilirea metodelor, tehnicilor, instrumentelor ce vor fi utilizate
stabilirea standardelor recomandate a se utiliza n cadrul proiectului;
fixarea punctelor de control i a punctelor de "ngheare" a soluiilor.
Planificarea sarcinilor se desfasoar n mod iterativ, de la nivel global la niveluri din ce n ce mai
detaliate, nti pe faze, etape i apoi pe activiti componente.
Pentru fiecare activitate n parte se stabilesc:
rezultatele de obnut (de exemplu specificaii, seturi de date de test, programe-surs, programe
obiect, documentaii etc.);
sarcinile de executat;
resursele necesare (de exemplu ore-om, ore-calculator);
criteriile de verificare i acceptare a rezultatelor.
Aceast detaliere se realizeaz pn la nivelul sarcinii (sau a pachetelor de sarcini), care poate fi
ndeplinit de o singur persoan, creia i se pot evalua rezultatele i i se pot estima resursele necesare
pentru a fi adus la ndeplinire. O problem deosebit de complex o constituie evaluarea resurselor
necesare pentru realizarea

ntregului proiect i a sarcinilor

individuale.
Sarcinile astfel stabilite sunt organizate, de regul, sub form de graf, utilizndu-se tehnicile
cunoscute
PERT si CPM.
Odat cunoscute sarcinile de executat i cantitatea de resurse necesare, se poate trece la alocarea
efectiv a resurselor.
b)
Alocarea resurselor se desfasoar n paralel cu organizarea echipei (sau a echipelor) proiectului
i const n:

stabilirea persoanelor care vor realiza sarcinile

planificate,

stabilirea fondului de timp afectat fiecrei

activiti

alocarea echipamentelor de tehnic de calcul concrete ce se vor utiliza pentru realizarea

proiectului.
Dup stabilirea lucrrilor, se vor stabili persoanele repartizate la fiecare lucrare. n acest stadiu este de
preferat s se aloce tipurile de specialiti sau tipurile de resurse umane i nu s se nominalizeze exact
persoanele fizice. Aceasta favorizeaz o mai mare flexibilitate n cadrul fazei de construire a echipei
de lucru. Va fi examinat fiecare lucrare n parte i necesarul de personal, pe tipuri de specializri,
cerut de aceasta.
Procesul de alocare a resurselor umane se va baza pe urmtorii factori:
se determin cte persoane, pe fiecare nivel de specializare, sunt necesare pentru fiecare
lucrare;
se aloc tipurile de resurse umane pe fiecare
lucrare;
se aloc timpul total estimat pentru fiecare lucrare, n concordan cu tipurile de resurse
umane aferente;
se realizeaz ajustri care s completeze lucrrile, timpii estimai sau personalul propus
iniial.
O dat ce a fost fcut primul pas i anume specificarea necesarului individual de resurse umane, se
trece la un nou nivel de evaluare a efortului i a ncrcrii cu sarcini. Acest pas va fi iterativ alocnd
tipurile de resurse umane pe fiecare perioad de timp.
n mod evident, alocarea de resurse se face pe baza listei de resurse disponibile din organizaia /
atelierul / colectivul, n care se realizeaz proiectul i compararea lor cu resursele
necesare.
n continuare, urmeaz o parte destul de dificil a procesului de planificare, i anume alocarea timpului
de realizare pentru fiecare etap i sarcin.
Estimarea timpului ncepe s ofere o imagine mai clar a proiectului, n termenii resurselor umane,
financiare i tehnice.
Fr calculul unui beneficiu n funcie de timp, deciziile potrivite sunt greu de adoptat. Trebuie luat n
considerare c timpul efectiv de realizare a proiectului va varia fa de estimri. Aceasta se ntmpl
ntotdeauna i duce la necesitatea realizrii unui plan dinamic, care s poat fi modificat ca rspuns la
schimbrile cerinelor i condiiilor proiectului. Pentru aceasta trebuie avute n vedere urmtoarele:

s se fac referin la planuri anterioare, pentru procese

similare

s se compare estimrile de timp propuse de diverse

metodologii
s se discute procesele propuse i orele alocate pentru fiecare cu conductorii de proiect, care
trebuie s aib o exeprien asemntoare n dezvoltarea de procese

s se traseze liniile directoare pe baza estimrilor

stabilite
c)
Planificarea calendaristic a sarcinilor i a resurselor. Pornind de la sarcinile proiectului i
ordinea de execuie a acestora, se stabilesc termenele de nceput i sfrit pentru fiecare sarcin. Se
ntocmeste astfel planul general al proiectului, document pentru care se folosete tehnica GANTT.

n acelai timp, pentru a se cunoate gradul de ncrcare i ocupare a resurselor (oameni i echipamente), se ntocmesc planuri calendaristice individuale pentru fiecare resurs n parte.
Pentru planificarea calendaristic se parcurg urmtorii pai:
se analizeaz fiecare punct al planului de lucru cu scopul de a determina activitile critice din
punct de vedere al efortului. De obicei, aceste activiti, prezint un nivel nalt de dependen
(una trebuie s fie complet nainte de a ncepe cealalt) ct i o ordine logic de realizare.
Activitile non-critice sunt mult mai flexibile la alocarea perioadelor de timp n cadrul planurilor.
se va utiliza o abordare de tip data cea mai ndeprtat de timp posibil de alocat Pentru fiecare
punct al planului se va stabili o dat clar de nceput i o alta de sfrit. Activitile critice trebuie
planificate primele deoarece nu au rezerv de timp. Se vor stabili datele de finalizare ale etapelor
mari ale planului de realizare, pe baza timpilor stabilii pentru fiecare punct al planului
O dat ce planul este complet se trece la dezvoltarea sistemului. Totui, pe parcursul procesului de
planificare, au fost fcute o serie de presupuneri n legtur cu pregtirea membrilor echipei de lucru,
numrul de programe, planul de echipamente tehnice, precum i efortul echipei proiectului. Toate
aceste estimri importante trebuie documentate clar, mai nainte ca ele s poat fi incorporate n plan.
Planificarea efectuat la nivelul ntregului proiect se detaliaz i, mai ales, se corecteaz n cadrul
planificrii operative.
n cadrul planificrii tactice trebuie s se in seama de urmtoarele
cerine:
s se utilizeze o abordare de tip plan de lucru comun pentru toate proiectele (cu pai care au
nume i nelesuri similare);
s se selecteze un pachet de programe standard pentru managementul planurilor de lucru i s se
cear tuturor conductorilor de proiect s l utilizeze pentru gestiunea volumului de lucru (n omore) lucrate;
s se specifice un set comun de date, care vor fi colectate la sfritul fiecrui proiect i care vor fi
comparate cu volumul de lucru efectiv. Datele se refer la numrul de:
- programe / module
- ferestre / ecrane
- rapoarte
- job-uri
- baze de date / elemente
- fiiere
- entiti / atribute
- procese
- obiecte / clase
s se identifice instrumentele i mediile de programare, generatoarele de cod, instrumentele de
tip
CASE i sistemele de gestiune a bazelor de date utilizate de fiecare proiect;
s se determine necesarul mediu de om-ore pentru a realiza analiza, proiectarea i construcia
componentelor;
s se finiseaze i s se mbuntasc factorii om-ore/componente rezultai pentru cerinele viitoare
de estimri.
Planificarea operativ se desfasoar pe parcursul desfurrii proiectului. Ea
presupune:

detalierea i corectarea planificrii tactice, a planificrii activitilor i resurselor unui

proiect;
stabilirea ordinii de execuie a diferitelor sarcinii i activiti, pe baza planificrii calendaristice a
sarcinilor i resurselor, efectuat la nivelul ntregului proiect.

Planificarea operativ este necesar datorit coreciilor fa de planificarea tactic, care n general sunt

datorate urmtoarelor cauze:

imposibilitatea unei evaluri precise a resurselor i a duratelor necesare pentru executarea
sarcinilor, nainte de desfurarea efectiv a proiectului;

indisponibilitii neprevzute a unor resurse afectate proiectului (oameni i

echipamente);
modificarea sarcinilor impus pe parcursul realizrii lor de nsi tehnologia de realizare a
produsului.

8.4.
proiectului

Organizarea

Problemele privind organizarea sunt legate de modul de organizare al echipelor, cu implicaii directe
att asupra calitii produsului program ct i asupra eficienei realizrii acestuia.
Exist mai multe tehnici de organizare, n funcie de dimensiunile (respectiv complexitatea)
proiectului, resursele avute la dispoziie i de structura organizatoric concret din unitatea
elaboratoare a produsului program.
n continuare, vor fi prezentate cteva tehnici de organizare, mai reprezentative, i
anume:

programarea
deschis;

echipa programatorului
ef;

echipa
"chirurgical";

echipa programatorului ef
revizuit.

8.4.1.
deschis

Programarea

n literatura de specialitate n limba romn se utilizeaz termenul de "programare democratic"

provenit din limba engleza de la "egoless programming".
Acest mod de organizare este forma cea mai simpl, comparativ cu cele prezentate n continuare.
Principiile de baz ale acestei tehnici sunt urmtoarele:

ntraga echip are un scop unic - reuita proiectului - i nu scopuri

individuale;

nlturarea greelilor / erorilor este n interesul ntregii

echipe;

erorile trebuie descoperite i nu

ascunse;
deoarece, uneori este mai uor s "vezi" erorile din programele altuia dect din programele proprii,
echipa este compus din mai muli programatori ntre care exist relaii de colaborare;
definirea global a produsului i a soluiilor de realizare se face n colectiv, n cadrul ntregii
echipe, dup care scrierea programelor se distribuie ntre membrii colectivului;
nainte de compilare, programele fiecrui programator vor fi citite de un alt (ali) membru(ii) al/ai
echipei pentru a descoperi erorile. n timpul testrii, fiecare programator se consult cu colegii din
echip asupra rezultatelor obinute i a modului de nlturare a erorilor.
n consecin, programarea deschis implic un sistem de lucru democratic i de sinceritate, ntr-un
sistem de relaii conform fig.8.3.

Programator 1
Programator 2

Programator 4
Programator 3

Fig. 8.3. Programarea deschis

Avantajele acestui mod de organizare sunt urmtoarele:

acest mod de lucru asigur spiritul de

echip;

cunoaterea reciproc a programelor i respectiv a ntregului

produs;

integrarea mai uoar i mai rapid a

componentelor;
nvarea i transferul de experien ntre membrii echipei. Toi membrii echipei, de la cel mai
experimentat pn la nceptori, schimbnd programele ntre ei, nva noi tehnici de programare
i algoritmi, discut probleme de stil de programare i eficien, ntr-o atmosfer deschis i de
colaborare;
programarea deschis nu presupune responsabiliti distincte ale membrilor echipei; conducerea
revine, prin rotaie, fiecrui programator n funcie de calitile i de experiena necesar n
diferitele momente ale desfurrii proiectului.
Cu toate avantajele menionate, n acest mod de organizare apar i unele
dificulti:
nefiind definite responsabilitile membrilor echipei, apar momente de confuzie n soluionarea
unor divergene;

nu se poate impune un control riguros al avansului proiectului i al consumului de

resurse;
luarea deciziilor, n anumite momente, poate fi amnat timp ndelungat, pn se ajunge la un
consens asupra diferitelor soluii de proiectare, asupra standardelor de respectat sau a altor reguli;

nu se asigur o conducere permanent i continu a

proiectului;
comunicarea cu alte entiti organizatorice, din afara echipei (conducerea organizaiei, utilizatorii
etc.) se face n mod greoi.

8.4.2.
(CPT)

Echipa

programatorului

ef

Spre deosebire de programarea deschis, n acest caz structura echipei i responsabilitile atribuite au
un caracter precis i bine definit.
Principiile pe care se bazeaz acest mod de organizare sunt urmtoarele:
ntreg procesul de realizare a produsului program trebuie structurat pe sarcini precise, care s
poat
fi atribuite membrilor echipei;

crearea premizelor pentru utilizarea de instrumente ajuttoare n realizarea

produsului;
asigurarea vizibilitii produsului pe tot parcursul procesului de elaborare (stabilirea rezultatelor
concrete de obinut n cadrul fiecrei activiti i a criteriilor pe care trebuie s le ndeplineasc);

asigurarea posibilitilor de nvare n cadrul

echipei;
asigurarea condiiilor ca cel putin doi membri din echip s cunoasc ntreg produsul n detaliu
(pn
la nivelul fiecrei linii de program-surs).
n cadrul echipei programatorului ef exist un nucleu al echipei format din doi specialiti cu
experien (programatorul-ef i adjunctul su) precum i secretarul echipei. Programatorii - membri ai
echipei sunt selectai de ctre programatorul ef, numrul lor fiind variabil n funcie de complexitatea
proiectului, sau chiar pentru acelai proiect, n funcie de necesarul de programatori n diferitele etape

de dezvoltare a produsului software (fig.8.4.).

Conducere
ierarhic

Utilizator
final

Programator ef

Adjunct

Secretar bibliotecar

Programatori

Bibliotec intern

Bibliotec extern

Fig.8.4. Echipa programatorului ef

Biblioteca proiectului este organizat ntr-o bibliotec intern la care nu are acces dect secretarul
bibliotecar i o bibliotec extern la care au acces toi membrii echipei.
Procesul de realizare al produsului software trebuie structurat precis pe sarcini, care sunt distribuite
membrilor echipei. Prin aceasta sunt create premizele pentru utilizarea resurselor hardware i software
n contextul sarcinilor i a membrilor echipei; se asigur posibiliti de nvare n cadrul echipei; se
asigur vizibilitatea programelor pe tot parcursul elaborrii; se asigur coordonarea proiectului de ctre
o singur persoan (ef de proiect).
Programatorul ef este conductorul tehnic al echipei. El rspunde fa de nivelurile superioare din
ierarhia conducerii organizaiei de reuita proiectului sub aspect tehnic i pstreaz legtura cu
beneficiarul. Sarcinile sale principale constau n:

elaborarea specificaiilor produsului i a documentaiei de

proiectare,

codificarea i testarea componentelor critice ale

produsului,
orientarea celorlali membri programatori n codificarea i testarea
programelor.
Exist forme restrictive ale acestei metode de organizare, n care programatorul ef proiecteaz,
codific i testeaz fiecare linie de cod a produsului program. Programatorul ef trebuie s aib caliti
deosebite i n special o foarte bun experien n programare (cca.10 ani), dar i s satisfac cerinele
unui bun coordonator.
Adjunctul programatorului ef este conductorul "de rezerv" al echipei, el trebuind s fie
familiarizat cu absolut toate aspectele proiectului, pentru a putea prelua conducerea. El particip la
toate deciziile tehnice importante, dreptul de decizie final avndu-l ns programatorul ef. n plus,
adjunctul programatorului ef elaboreaz planurile de testare i execut activiti de cercetaredocumentare pentru programatorul ef.
Secretarul echipei ndeplinete sarcina de ntreinere la zi a documentaiei proiectului, a bibliotecilor
de programe, a datelor de test i a rezultatelor testrii.
Echipa programatorului ef rezolv n bun parte inconvenientele programrii deschise, prezentnd
urmtoatele avantaje:


introduce rigurozitate n distribuirea responsabilitilor i a
sarcinilor;

Conducerea procesului de realizare a produselor program

8-19
19

ofer posibilitatea de control permanent al avansului proiectului, din punct de vedere

calendaristic
(termenele de elaborare i de predare).
Exist ns o serie de critici aduse acestei tehnici, n special legate de statutul de autoritate total a
programatorului ef, care poate conduce la:
- lipsa de motivare i interes ale membrilor echipei;
- lipsa de control asupra deciziilor programatorului sef;
- lipsa de atractivitate pentru funcia de "adjunct al programatorului ef";
- posibiliti limitate de nvare i de schimb de experien ntre membrii echipei;
- dificulti n selectarea i numirea de programatori efi, care trebuie s ntruneasc foarte
multe caliti att de ordin profesional ct i de conducator.

8.4.3.
chirurgical.

Echipa

Prin aceast tehnic, specializarea membrilor echipei este i mai detaliat dect n cazul metodei
programatorului ef, ncercndu-se o diminuare a dezavantajelor acesteia din urm (nsi denumirea
tehnicii sugereaz acest aspect).
i n acest caz echipa este compus dintr-un ef de echip, ajutat de un administrator, care, dac
problema este mai complex, poate fi asistat de un secretar (care nu trebuie s fie neaprat un
programator). Editarea documentaiilor este fcut de un editor, care poate avea la rndul su un
secretar. Ceilali programatori sunt mprii pe categorii (fig.8.5.).
ef

Adjunct
Administrator
Responsabil cu instrumentele
Secretar
Editor

Secretar

Specialiti n limbaje

Responsabil cu testarea

Fig.8.5 Echipa chirurgical

eful echipei i adjunctul su (n termenii originali "surgeon" i "copilot") ndeplinesc sarcini similare
cu cele din cadrul metodei programatorului ef, cu urmtoarele diferene:
- eful echipei nu se mai ocup de recrutarea personalului i procurarea resurselor, (sarcini ce revin
administratorului), rmnnd strict desemnat pentru coordonarea tehnic a proiectului;
- adjunctul are sarcina de a asigura i interfaa cu alte echipe.
Administratorul rspunde de asigurarea condiiilor de lucru normale pentru echip: gestionarea resurselor (umane i financiare) ale proiectului, procurarea spaiului, asigurarea accesului i a fondului

8-2020
program
de

Conducerea procesului de realizare a produselor

ore-calculator etc. i execut interfaa cu conducerea de pe nivelurile superioare. Administratorul

raporteaz activitatea sa efului echipei i ia decizii administrative cu aprobarea acestuia.
Editorul elaboreaz - pe baza documentelor primite de la eful echipei - ntreaga documentaie a
proiectului (documentaia de realizare i manualele finale ale produsului).
Administratorul i respectiv editorul sunt ajutai de ctre un secretar. n cadrul personalului ajuttor se
menioneaz i arhivarul proiectului care execut sarcini similare cu cele ale secretarului
(bibliotecarului) proiectului din CPT.
Programatorii propriu-zii sunt i ei specializai pe diferite
funcii:
- responsabilul cu instrumentele, care pune la dispozitia echipei instrumentele software necesare
(utilitare specializate, editoare, depanatoare etc.) sau chiar elaboreaz anumite instrumente
software, stabilete procedurile de catalogare i genereaz macrobibliotecile;
- specialitii n limbaje de programare sunt utilizai ca experi specializai pe diferite limbaje, care
selecteaz soluii eficiente de programare n limbajele respective;
- responsabilul cu testarea - pune n aplicare planul de testare elaborat de eful echipei, prin
generarea seturilor de date de test, a programelor de testare i a procedurilor de depanare.
Organizarea de tip "echip chirurgical" atenueaz unele dificulti ale metodei programare deschis
prin distribuirea mai uniform a sarcinilor tehnice i creterea responsabilitii membrilor echipei de
programare.

8.4.4. Echipa programatorului sef revizuit

RCPT
Aceast metod de organizare mbin avantajele metodelor precedente, nucleul fiind format dintr-un
conductor de proiect, un adjunct al acestuia, un responsabil pentru asigurarea legturii cu utilizatorul
i un administrator al proiectului (vezi fig.8.6.).
Administrator

Conductor de proiect
Adjunct
Legtura cu utilizatorul
f in a l

Programator
Redactor tehnic

Programator

Fig. 8.6. Echipa programatorului ef revizuit

Spre deosebire de CPT, n aceast variant de organizare, conductorul de proiect - echivalent

cu programatorul ef - este subordonat administratorului, cruia i raporteaz starea proiectului.
Conductorul de proiect este conductorul tehnic al echipei pe care o coordoneaz pe tot
parcursul proiectului i ndeplinete urmtoarele sarcini:
- hotrte mpreun cu administratorul resursele necesare;
- selecteaz i/sau elaboreaz standardele i procedurile obligatorii de respectat;
- elaboreaz specificaiile de definire a produsului program i documentaia de proiectare, ajutat de

adjunctul su i de persoana nsrcinat s menin legatura cu utilizatorul;

- asigur conducerea tehnic a proiectului;

verific programele scrise de membrii echipei, planurile de testare i rezultatele
testrii;
- ine jurnalul proiectului;
asigur ridicarea nivelului tehnic al membrilor
echipei.
Colaboratorul su - adjunctul efului de proiect - ndeplinete funcii similare cu adjunctul programatorului ef, cu deosebirea c are sarcini de concepie suplimentare, participnd la proiectarea
produsului. Ca i conductorul de proiect, adjunctul trebuie s fie n primul rnd un analist
experimentat i mai puin un "super-programator". El ndeplinete urmtoarele sarcini:
particip la elaborarea specificaiilor i a documentaiilor de proiectare;
elaboreaz planul de testare a produsului;
particip la verificarea programelor i a rezultatelor testrii;
reprezint echipa n edinele tehnice cu grupuri din afar;
ine legatura cu grupul de ntreinere (organizat de regul ca grup distinct fa de echipa de
elaborare).
Administratorul de proiect este conductorul administrativ al proiectului, care asigur legatura cu
conducerea organizaiei respective. De regul, ndeplinete urmtoarele sarcini:
prezint echipei obiectivele proiectului i prioritile definite de conducerea
organizaiei;
asigur resursele necesare bunului mers al proiectului;
gestioneaz fondurile proiectului;
raporteaz conducerii stadiul proiectului.
Un administrator poate subordona simultan mai multe proiecte. Persoana nsrcinat s menin legatura cu utilizatorul trebuie s cunoasc foarte bine domeniul de aplicaie pentru care se realizeaz
produsul; aceasta ndeplinete urmtoarele sarcini:
- asigur satisfacerea cerinelor utilizatorului;
- interpreteaz i explic cerinele utilizatorului;
- asigur relaia permanent cu utilizatorii i ntocmete documentaia
de utilizare;
- particip la testare i mai ales construirea cazurilor de test pentru acceptarea produsului de ctre
utilizator;
asigur legtura ntre echipa de elaborare, grupul de ntreinere i
utilizator.
Programatorii rspund de scrierea i testarea programelor, pe baza specificaiilor primite i a sarcinilor
distribuite de conductorul proiectului. Programatorii pot fi specializai pe diferite activiti, putnduse roti ntre ei n realizarea diferitelor sarcini. Sarcinile programatorilor constau din:
- asigurarea codificrii;
construirea de utilitare specializate, proceduri catalogate,
macrobiblioteci etc.;
- adaptarea pachetelor i modulelor reutilizabile pentru a fi ncorporate
n sistem;
elaborarea planurilor de testare i executarea
testelor.
n mod opional RCPT poate include i un redactor tehnic de documentaie, n special pentru produse
program complexe i care se adreseaz unui cerc foarte larg de utilizatori.
Fa de organizrile prezentate n paragrafele anterioare, RCPT aduce unele inovaii menite s

atenueze dezavantajele tehnicilor respective.

n primul rnd se ncearc o limitare a funciilor ndeplinite de conductorul proiectului, care trebuie s
se concentreze numai pe activitatea de concepie-proiectare a produsului program, fr a mai fi vzut
ca un "supra-programator".
El nu mai scrie nici un program, n schimb verific codul surs realizat de programatori, din punctul
de

vedere al respectrii specificaiilor.

n al doilea rnd, prin funciile atribuite administratorului proiectului, au fost plasate pe alt nivel de
competen - mult mai nalt - sarcinile de asigurare a resurselor, recrutarea i evaluarea personalului,
controlul avansului proiectului i raportarea n faa conducerii organizaiei.
n al treilea rnd, conductorul proiectului este scutit de interaciunea cu utilizatorul i cu alte grupuri
din afara echipei, putndu-se concentra pe aspectele tehnice, pe mai buna distribuire i urmrire a
sarcinilor n interiorul echipei, pe ridicarea nivelului tehnic al programatorilor.
n cadrul RCPT se asigura, mult mai bine decit n alte tehnici de organizare, comunicarea dintre echip
i exterior (legatura cu utilizatorii, cu conducerea, cu echipa de ntreinere i cu alte grupuri).
Un alt avantaj al RCPT este c poate fi implementat pe proiecte de diferite dimensiuni. Astfel, pentru
proiecte mici RCPT se poate reduce la conductorul proiectului i adjunctul su (fig.8.7.)
Administrator

Conductor proiect
Adjunct

Fig. 8.7. Echipa programatorului ef revizuit redus

n acest caz, acetia doi preiau i funciile de programare, legtura cu utilizatorul i scrierea
documentaiei.
Pentru proiecte mai mari se poate alctui o ierarhie de RCPT, n cadrul creia legatura dintre echipe
se realizeaz prin intermediul adjunctului (fig. 8.8.)

Administrator

Adj.
Adj.
Adj.
Adj.

Adj.

Fig. 8.8. Legtura dintre echipe

Dup ce a fost aleas o modalitate de organizare a echipei de lucru se trece la construirea echipei de
lucru.
Selectarea membrilor echipei se poate realiza innd cont de urmtoarele considerente:
Personalul intern
Cnd se selecteaz personalul intern, se vor alege acei care:
- neleg politica firmei
- Sunt familiarizai cu problemele firmei

Cunosc standardele i liniile directoare referitoare la aplicarea soluiilor tehnice, n interiorul

firmei
Au experien n acest tip de lucrri
Au un interes personal n rezultatul proiectului
Vor fi responsabili de proiect n perioada care va veni.

Consultani
Trebuie s se aleag persoane externe firmei,
care:
- Pot furniza cunotine tehnice de calitate
- Pot propune soluii rezultate din experiena cu clienii sau din situai similare
- Pot aduce noi puncte de vedere n analiza cerinelor
- Nu trebuie s acorde o mare atenie politicii interne a firmei
Pot aprecia urgena i importana proiectului, deoarece sunt pltii
direct.

Programatorii
Este important s se selecteze personalul care:
- Pot asigura cerinele de resurse tehnice ale proiectului la fiecare nivel
- Pot furniza cunotiine tehnice specifice
- Pot furniza un cod de calitate ntr-o perioad scurt de timp.

Utilizatorii
Sistemul este construit att n beneficiul firmei ct i al clienilor care l vor utiliza. Dei echipa de
lucru dezvolt un pachet software comercial, pe baza propriei lor experienei lor, totui echipa va
trebui s aloce o perioad considerabil de timp utilizatorilor finali. Se va stabili cine sunt acetia,
ce rol vor juca pe parcursul procesului de dezvoltare i ct timp va fi necesar s se aloce fiecruia.
Toate acestea sunt decizii critice, care trebuie studiate cu atenie.
Cnd se stabilesc participanii la proiect, este important s se aleag
persoanele:
- asupra crora sistemul va avea un impact direct
- care doresc s se implice
- care au critici la adresa sistemului curent
- care sunt considerate n pas cu noul
- care au imaginaie
- care au influien n propia firm

Personalul de
decizie
Factorul de decizie nu este neaprat o singur persoan. El poate fi i un comitet. n ambele cazuri,
factorul de decizie trebuie s fie capabil s rezolve urmtoarele tipuri de probleme:
- ntrebri despre direcia i scopul proiectului
rezoluii n problemele zilnice, economice sau
tehnice
- recomandri n abordrile sau soluiile problemelor
aprobarea final a personalului, resurselor sau
bugetului.
O dat stabilit factorul de decizie, se va hotr cum se va derula procesul. Mai nti trebuie s se
asigure de faptul c decizia cerut nu a fost deja luat. Se consult manualele de politic a firmei
precum i cele de proceduri, standarde i linii directoare, sau memorandumuri existente, care pot deja
conine rspunsuri la problemele de politic economic.

Dac problema este complet diferit de modul curent de derulare al lucrurilor, trebuie consultai
factorii de decizie.
n al doilea rnd, este necesar determinarea momentului optim pentru luarea unei decizii. O decizie
incorect, datorat unei informaii pariale sau insuficiente, poate produce mari daune. nainte s se
apeleze la factorul de decizie, echipa trebuie s atepte pn sunt colectate toate informaiile relevante.

De multe ori este util s se prezinte o list de decizii alternative, o dat cu direcia de aciune
recomandat de echip. Aceasta va pune factorul de decizie n poziia de a face o alegere, mai degrab
dect a risca o decizie.

8.5.
proiectului

Controlul

Prin aceast funciune a conducerii se urmrete realizarea produsului program la termen, cu consumul
de resurse planificat i n condiiile de calitate specificate. n acest scop pot fi utilizate o serie de
tehnici, dintre care mai utilizate sunt:
verificrile tehnice;
raportarea stadiului proiectului;
controlul modificarilor.

8.5.1.
tehnice

Verificrile

Verificrile tehnice se efectueaz n puncte de control, prestabilite odat cu structurarea pe etape a

ciclului de realizare a produsului program. De regul, aceste controale se efectueaz la sfritul
etapelor "cheie" din ciclul de realizare a produsului program respectiv:
elaborarea temei de realizare;
proiectarea preliminar;
proiectarea detaliat;
elaborare programe;
integrare i testare;
experimentare;
omologare.
Verificrile tehnice se desfasoar pe baza urmatoarelor principii:
obiectul verificrilor este calitatea soluiilor i a documentaiilor elaborate i nu performanele
individuale ale realizatorilor.
persoanele implicate n verificrile tehnice pot avea unul din urmtoarele roluri: verificator,
verificat sau secretar (persoana care consemneaz rezultatele verificrii);
materialele supuse controlului trebuie difuzate din timp;
rezultatele verificrilor sunt analizate n cadrul unei edine de lucru planificat i anunat din
timp;
scopul ntlnirilor de control este identificarea problemelor de soluionat i distribuirea acestora
persoanelor care trebuie s le rezolve;
concluziile ntlnirii de lucru sunt consemnate, de secretar, ntr-un raport al verificrii tehnice
efectuate.
edinele de verificri tehnice sunt conduse de persoana care are responsabilitatea fazei respective,
asistat de eful de proiect sau lociitorul acestuia, persoana care realizeaz legtura cu utilizatorul,
responsabilul cu ntreinerea produsului i grupul de control al calitii.
Principalele activiti abordate prin verificrile tehnice efectuate n punctele de control menionate
constau din:
analiza produselor intermediare rezultate la nivelul etapei/fazei i a documentelor elaborate n
respectiva etap/faz;
identificarea problemelor care pot afecta alte etape din cadrul procesului de realizare;
discutarea cererilor de modificare.

8.5.2.
proiectului

Raportarea

stadiului

Raportarea stadiului proiectului este o tehnic de control a realizrii produselor program. Structura
raportrii este formalizat pentru a permite furnizarea de informaii relevante i la timp conducerii, pe
diferite cicluri ale conducerii proiectului.
Scopul urmrit de tehnic este urmtorul:
actualizarea planului de realizare a produsului program;
determinarea calitii produsului program pe parcursul proiectului i dup finalizare;
discutarea i realizarea problemelor identificate cu ocazia verificrilor
efectuate;
respectarea standardelor unitii;
stabilirea i / sau modificarea asigurrilor de responsabiliti / sarcini;
introducerea unor elemente cu caracter de noutate;
efectuare de comentarii pe domeniile supuse
discuiei.
n timpul unei ntilniri de raportare a stadiului proiectului eful poate cunoate mai bine modul de a
gndi i atitudinea membrilor echipei fa de diferitele probleme, dect prin citirea unui raport de
stadiu.
Tehnica furnizeaz o serie de reguli de raportare a stadiului care se aplic pe cele patru niveluri de baz
de conducere a unui proiect - conducerea unitii, administratorul proiectului, eful proiectului, eful
fazei - si anume:
ntlnirile de raportare a stadiului se in regulat cu o periodicitate stabilit funcie de nivelul de
conducere a proiectului - i vor dura aproximativ o or;
respectivele ntlniri sunt conduse de persoana care are responsabilitatea respectivului nivel de
conducere i la ele particip subordonaii direci ai acestuia;
fiecare ntlnire are o agend de probleme fixate, ca de
exemplu:
- actualizarea planului proiectului;
- discutarea sarcinilor care afecteaz diferite sarcini ale proiectului;
- atribuirea de responsabiliti / sarcini;
- discutarea elementelor cu caracter de noutate i efectuarea de comentarii;
- fiecare participant la ntlnire prezint efului documentele de control solicitate de acesta
(documentele de control pot fi grupate n urmtoarele clase: documente de lansare, documente
de verificare tehnic, documente de urmrire a nivelului de realizare a planului iniial al
proiectului, rapoarte de incidente, cereri de modificare, rapoarte de stare, etc);
problemele identificate pe parcurs sunt raportate pe formulare de raportare a
incidentelor;
conductorul ntilnirii ntocmete un raport asupra stadiului proiectului pe care-l nainteaz
conductorului de pe nivelul ierarhic imediat superior;
problemele care nu intereseaz ntregul personal care particip la ntlnire nu sunt
discutate.
Tehnica precizeaz elementele specifice fiecrui nivel de conducere, relative la raportarea stadiului
proiectului.
Raportarea stadiului proiectului, fiind o tehnic de control ce se utilizeaz pe parcursul ntregului ciclu
de via a unui produs program conform principiilor i regulilor pe care se bazeaz.

Tehnica impune o abordare organizat i disciplinat a cunoaterii stadiului n care se afl un produs
program n momente prestabilite de efii de pe diferitele nivele de conducere a proiectului.

8.5.3.
modificrilor

Controlul

Apariia de modificri pe parcursul ciclului de via al unui produs program fiind inevitabil, existena
unei modaliti de control al modificarilor este de mare utilitate.
Tehnica de control a modificrilor vizeaz numai acele modificri care apar la nivel de cerine, de
specificaii i de cod surs care afecteaz faza anterioar "ngheat" sau efectueaz mai mult decit o
faz a procesului de realizare.
Pentru viabilitatea produsului program este esenial ca aceste modificri s fie controlate de
conducerea proiectului.
Celelalte modificri care apar la nivelul unei faze n scopul nbuntirii soluiei propuse sau nlturrii
unor erori depistate nainte de "nghearea" soluiei fazei sunt analizate, controlate i evideniate la
nivelul respectivei faze de eful acesteia.
Modificrile care constituie obiectul tehnicii de control al modificrilor sunt analizate i numai dac
sunt aprobate vor fi introduse n produs.
Fiecare modificare de acest tip este supus unei proceduri de control
i anume:
documentarea modificrii de ctre solicitant pe un formular - cerere de
modificare;
discutarea cererii de modificare n cadrul ntlnirii de raportare a stadiului proiectului condus de
conductorul direct al solicitantului; dac cererea de modificare este formulat de utilizator, acesta
o d persoanei din echip care asigur legtura cu utilizatorul.
validarea sau invalidarea cererii de modificare de ctre conductor; dac cererea de modificare a
fost invalidat solicitantul poate cere ca ea s fie analizat de urmatorul nivel de conducere;
naintarea cererilor de modificare, de ctre conducatorii de pe nivelul inferior de conducere, ctre
eful de proiect, nsotit de recomndari;
examinarea cererilor de modificare nerezolvate, n ntlnirile de raportare a stadiului conduse de
eful de proiect. Modificrile care nu afcteaz scopul, obiectivele, costul, termenele proiectului
pot fi validate la acest nivel;
modificrile care afecteaz scopul, obiectivele, costul, termenele proiectului trebuie examinate de
administratorul proiectului;
prezentarea imediat a cererilor de modificare urgente, eful
solicitantului;
implementarea modificrilor aprobate este urmrit de eful de proiect i eful de faz;
evidenierea unitar a tuturor acestor cereri de modificare mpreun cu starea
lor.
Tehnica de control al modificrilor se poate utiliza pe parcursul ntregului ciclu de via a unui produs
program ori de cte ori se solicit efectuarea unei modificri din categoria celor care fac obiectul
tehnicii.
Din multitudinea de modificri care se efectueaz pe ntreg ciclu de via a unui produs informatic
tehnica ia n consideraie numai pe acelea critice, care de cele mai multe ori au implicaii asupra
soluiei de proiectare i respectiv de programare, asupra efortului necesar pentru implementarea lor,
asupra costului, respectiv duratei de realizare, i eventual obiectivelor urmrite.