Managementul proiectelor

software
- Principii generale -
 Scopuri:
• Stabilirea obiectivelor proiectării software
• Identificarea diferenţelor ce apar la
dezvoltarea proiectele software şi la
dezvoltarea altor proiecte
• Definirea etapelor uzuale ale unui proiect
software
• Înţelegerea nevoii de planificare,
monitorizare şi control
• Măsurarea succesului unui proiect în
îndeplinirea obiectivelor
 1) Introducere

Un proiect este o activitate planificată.

Obs. Un task repetat de un număr de ori nu este

un proiect.

Obs. Amploarea proiectului este foarte importantă.

Un proiect ce implică 200 oameni diferă (ca
management) faţă de unul ce implică 2 oameni.
 2) Proiecte software vs. Alte proiecte
Un proiect software are anumite caracteristici care-l
diferenţiază faţă de alte tipuri de proiecte:
• Invizibilitatea: dacă la un pod ce se construieşte, e
vizibil progresul, la produsele software nu e la fel;
• Complexitatea: produsele software conţin mai
multă complexitate per dolar sau euro cheltuit
• Flexibilitate: un produs software se poate schimba
în funcţie de preferinţele utilizatorilor, mai degrabă
decât să se ceară utilizatorilor să-şi modifice
comportamentul pentru a folosi produsul.
 3) Activităţi în managementul proiectelor
software
Un proiect software nu priveşte doar scrierea software-ului.
De aceea, există 3 procese succesive care sunt necesare:
a) Studiu de fezabilitate: investigare dacă un proiect de
viitor merită să fie început. Trebuie estimate costurile şi
beneficiile. La un proiect mare, studiul de fezabilitate
poate fi el însuşi un proiect.
b) Planificarea: dacă studiul de fezabilitate spune că
proiectul poate începe, trebuie începută planificarea.
Obs. Pentru un proiect mare, nu trebuie ca toate detaliile
să fie planificate de la început, ci doar etapele
importante, detaliindu-le apoi (în diverse etape ale
proiectului).
c) Executarea proiectului: Un ciclu de viaţă tipic al unui
proiect (typical project life-cycle) este următorul:
Detalierea etapelor

• Analiza cerinţelor: această etapă trebuie să stabilească

ceea ce doresc utilizatorii de la software.
• Descriere: documentaţia detaliată a ceea ce îşi propune
sistemul să facă.

• Design: are două etape:

¾ design-ul extern (sau al utilizatorului): ce face
sistemul în termni de meniuri, ecrane etc
¾ design-ul fizic: felul în care datele şi operaţiile sunt
structurate intern

• Cod: scrierea efectivă a codului (într-un anumit limbaj).

• Verificare şi validarea: operaţie necesară pentru
depistarea şi corectarea eventualelor erori (errors, bugs,
faults) din sistem.
• Implementarea / instalarea: termenul “implementare” se
referă, după unii autori, la tot ce urmează după etapa de
design, iar după alţii la instalarea sistemului după ce
software-ul a fost dezvoltat (în acest caz, trebuie încorporate
aici şi stabilirea parametrilor sistemului, scrierea manualelor
de utilizare, asigurarea training-ului utilizatorilor).
• Mentenanţă şi suport: după ce sistemul a fost instalat, e
nevoie de corecţia erorilor ce nu au fost depistate în faza de
testare, de extinderea şi îmbunătăţirea sistemului.
Mentenanţa şi suportul pot fi văzute ca procese software
minore.
 4) Clasificarea proiectelor software
a) Putem întâlni:
• sisteme de informaţie (information systems): exemplu – un
sistem de control al stocurilor.
• sisteme în timp real (embedded systems): exemplu – un
sistem ce controlează aerul condiţionat dintr-o clădire.
Obs. Unele sisteme pot avea caracteristici din ambele tipuri
de sisteme

b) Din punct de vedere al scopului sistemului:

• sisteme care produc ceva
• sisteme ce îndeplinesc anumite obiective.
 5) Proiectul ca sistem
Un proiect se ocupă de crearea unui nou sistem sau/şi de
transformarea unuia vechi.
Sistem (system) = mulţime de părţi intercorelate

Un sistem poate fi parte a unui sistem mai mare şi poate

avea ca părţi componente subsisteme (subsystem).

În afara sistemului există aşa numitul mediu al sistemului

(system´s environment), adică acele elemente care pot
afecta sistemulo, dar asupra cărora sistemul nu are control.
Sistemele deschise (open systems) sunt sistemele ce
interacţionează cu mediul. Aproape toate sistemele sunt
deschise.
 6) Ce este managementul?

Managementul presupune următoarele activităţi:

• Planificare – ce trebuie făcut;

• Organizare – “making arrangements”;
• Încadrarea personalului – selectarea oamenilor potriviţi;
• Conducere, îndrumare – se dau instrucţiuni;
• Monitorizare – verificarea progresului;
• Control – acţiuni care să remedieze penele;
• Inovare – propunerea de noi soluţii;
• Prezentare – legătura cu utilizatorii.
Pe de altă parte, cele mai frecvente provocări pentru un
manager sunt următoarele (printre altele):

• Să facă faţă deadlines-urilor (85%);

• Să facă faţă restricţiilor legate de resurse (83%);
• Comunicarea efectivă de sarcini (80%);
• Câştigarea angajamentului membrilor echipei (74%);
• Stabilirea unor “pietre de hotar” măsurabile (70%);
• Să facă faţă schimbărilor (60%);
• Să facă faţă conflictelor (42%);
• Să gestioneze vânzătorii şi sub-contractorii (38%).

Procentele de mai sus se referă la numărul de manageri

care au identificat fiecare item. Un manager poate identifica
mai mult decât un item.
 7) Probleme cu proiectele software
Deşi multe sarcini ale managementului se gestionează mai
degrabă se sisteme de management decât de manageri, e
adevărat că pentru succesul unui proiect e totuşi
răspunzătoare o persoană.
Problemele ce apar (d.p.d.v. al managerului) sunt:
• estimare şi planificare deficitară;
• lipsa standardelor de calitate;
• lipsa criteriilor în luarea deciziilor;
• lipsa tehnologiei pentru ca prgresul să devină vizibil;
• repartizarea defectuoasă a rolurilor – cine ce face?
• criterii de succes incorecte.
Problemele ce apar (d.p.d.v. al membrilor echipei) sunt:
• descrierea inadecvată a muncii sale;
• ignoranţa managerului în IT;
• lipsa cunoştinţelor în aria sa de muncă;
• lipsa standardelor;
• lipsa documentaţiei la zi;
• activităţi anterioare neterminate la timp;
• lipsa comunicării între utilizatori şi tehnicieni;
• schimbarea software environment;
• presiunea dată de deadline;
• lipsa controlului de calitate;
• lipsa trainingului.
 8) Controlul managementului

A) Ciclul de control al
proiectului

Managementul, în
general, poate fi văzut
ca un proces de stabilire
a obiectivelor şi apoi
monitorizarea sistemului
pentru a vedea care
este performanţa sa
adevărată.
B) Obiective

Managerul şi echipa sa trebuie să stabilească clar

obiectivele, pentru a se putea concentra asupra lucrurilor
esenţiale şi a defini astfel criteriile de succes ale proiectului.

Dacă există mai multe grupuri de utilizatori, atunci trebuie să

existe o autoritate a proiectului, care să aibă autoritatea
globală asupra proiectului. În acest caz, există şi un comitet
de organizare, care are responsabilitatea globală pentru
stabilirea, monitorizarea şi schimbarea obiectivelor.
Managerul este responsabil pentru derularea proiectului zi de
zi, dar el trebuie să raporteze periodic comitetului de
organizare stadiul evoluţiei proiectului.
C) Măsurarea eficacităţii
Obiectivele efective sunt bine definite.
Un enunţ vag, de tipul “să îmbunătăţească relaţia cu clientul”,
nu e un obiectiv. Dar reformularea “reducerea plângerilor
clienţilor cu 25%” poate fi un obiectiv.
Măsura eficacităţii poate fi, în anumite cazuri, un răspuns
simplu (da/nu) la o întrebare, de pildă “ai instalat noul software
săptămâna trecută?”

D) Sub-obiective şi scopuri (goals)

În multe situaţii, un obiectiv se poate împărţi în sub-obiective.

De exemplu, pentru atingerea obiectivului A, trebuie
îndeplinite în prealabil obiectivele B şi C. Aceste sub-obiective
se mai numesc scopuri (goals).
 9) Stakeholders
Sunt persoane cheie care au un anumit interes în proiect,.
Aceste persoane trebuie identificate cât mai devreme cu
putinţă, în vederea stabilirii unui canal de comunicaţii. Nu
toate persoanele implicate în proiect au aceleaşi motivaţii.

Stakeholders pot fi:

• interni în echipa proiectului: vor fi sub controlul managerial
direct al liderului de proiect;
• externi echipei proiectului, dar în aceeaşi organizaţie: de
exemplu, liderul proiectului ar putea avea nevoie de asistenţă
din partea grupului de management al informaţiei în ideea de
a adăuga tipuri de date noi în baza de date. În acest caz,
trebuie negociată angajamentul acelor persoane.
• externi echipei şi organizaţiei: în acest caz, stakeholders pot
fi clienţii, cu care trebuie încheiat un contract.
 10) Descrierea cerinţelor

A) Cerinţe funcţionale: ce trebuie să facă sistemul

B) Cerinţe de calitate: cum trebuie să se comporte sistemul,

de exemplu timp de răspuns, uşurinţa folosirii, fiabilitate

C) Cerinţe referitoare la resurse: înregistrarea a cât de mult

doreşte o organizaţie să cheltuiască pe sistem
 11) Informaţii şi control în organizaţii
Problema comunicaţiilor depinde direct proporţional de
dimensiunea proiectului. Proiectele mari au, de regulă, o
structură de management ierarhică, ca în figura de mai jos:

Membrii echipelor proiectului au un lider de grup, care,

împreună cu alţi lideri de grup, raportează catre managerul de
la nivelul superior. Spre vârf, tot mai puţine persoane trebuie
să ia hotărâri şi cantitatea d einformaţii creşte.
 A) Nivele de luarea deciziilor şi informaţii

Deciziile pot fi grupate astfel:

• decizii strategice: esenţiale pentru obiectivele ferme;
• decizii tactice: necesare pentru a se asigura că obiectivele
vor fi îndeplinite. Liderul de proiect trebuie să întocmească un
plan concret de acţiuni pentru îndeplinirea obiectivelor şi să
monitorizeze progresul activităţii;
• decizii operaţionale: se referă la munca de zi cu zi pentru
implementarea proiectului
B) Diferenţe în tipurile de informaţii
Tabel 1. Tipuri de informaţii necesare pentru luarea deciziilor
Caracteristică Operaţională Strategică
motivare eficienţă eficacitate
orientare internă internă şi externă
focus specifică unei funcţii specifică unei organizaţii
detaliu detaliată rezumată
răspuns rapidă nu aşa rapidă
căi de acces standard flexibilă
la zi esenţială dezirabilă
acurateţe esenţială aproximativă
certitudine esenţială adesea predictivă
obiectivitate înaltă mai subiectivă
tipul informaţiei mai ales cantitativă adesea calitativă

Eficacitatea se referă la a face lucrul potrivit. Eficienţa se referă la

folosirea optimă a resurselor.
C) Măsurători
În proiectele mai mari, liderii de proiect trebuie să gestioneze
o cantitate mare de informaţii. Aceste informaţii nu trebuie să
fie vagi şi, ideal, ar trebui să fie cantitative.

Măsurătorile software (software measurements) se divid în:

• măsurători ale performanţei: măsoară caracteristicile
sistemului livrat. Măsurătorile includ timpul mediu dintre
defecţiuni şi timpul de învăţare a aplicaţiei (useability);
• măsurători predictive: se fac în timpul dezvoltării şi arată
care va fi performanţa aproximată a sistemului.
 Concluzii
• Proiectele sunt prin definiţie activităţi “non-rutină” şi de
aceea mai nesigure decât alte sarcini;
• Proiectele software sunt similare cu alte activităţi, dar au
anumite atribute ce prezintă dificultăţi, cum ar fi de exemplu
invizibilitatea relativă a multor produse;
• Un factor cheie în succesul unui proiect este stabilirea unor
obiective clare. Diferite persoane cheie din proiect
(stakeholders) pot avea interese diferite. De aceea e necesară
o autoritate recunoscută care să răspundă de întregul proiect;
• Pentru ca obiectivele să aibă concreteţe, trebuie să existe
căi practice de a verifica că obiectivele se îndeplinesc. Asta
conduce la nevoia de măsurători;
• Trebuie să existe măsurători obiective de succes, în ideea
de a ajuta la comunicarea neambiguă a diverselor părţi
implicate în proiect.
Calitatea software-ului
 1. Introducere

Deşi calitatea este “un lucru bun”, calitatea unui sistem, în practică, poate
fi un atribut vag şi insuficient definit. De aceea trebuie să se definească
exact ce calităţi cerem unui sistem.

Calitatea priveşte toate etapele planificării şi executării proiectului, dar se

dovedeşte de un interes particular în următoarele etape:
• Identificarea infrastructurii proiectului;
• analiza caracteristicilor proiectului;
• identificarea produselor şi activităţilor;
• revizuirea şi editarea planului.
 2. Importanţa calităţii software-ului

Caracteristicile speciale ale software-ului, în particular inatngibilitatea şi

complexitatea, cer anumite lucruri speciale:
• Natura critică în creştere a software-ului. Utilizatorul e anxios
gândindu-se la calitatea software-ului, mai ales la fiabilitatea acestuia. E
cazul organizaţiilor care devin din ce în ce mai dependente de sistemele
de calcul şi software-ul e utilizat din ce în ce mai mult în arii care sunt
critice d.p.d.v. al siguranţei, cum ar fi controlul avioanelor.
• Intangibilitatea software-ului. Acest lucru face dificilă cunoaşterea
faptului că o anumită sarcină în proiect a fost completată satisfăcător.
Rezultatele acestor sarcini pot fi făcute tangibile cerând dezvoltatorului să
producă “deliverables” care să fie examinate pentru calitate.
• Acumularea erorilor în timpul dezvoltării software. Deoarece
produsul e făcut dintr-un număr de paşi unde ieşirea unuia devine intrarea
altuia, erorile produse în etapele timpurii ale proiectului conduc la
amplificarea lor. Cu cât o eroare e descoperită mai târziu, cu atât mai mult
costă reparaea ei.
 3. Definirea calităţii software-ului
Pentru orice sistem software, ar trebui să fie trei specificaţii:
• o specificaţie funcţională descriind ceea ce trebuie să facă sistemul;
• o specificaţie de calitate, ce priveşte cât de bine operează funcţiile;
• o specificaţie de resurse, ce priveşte cât de mult se cheltuieşte pe
sistem.

James A.McCall (“An Introduction to Software Quality Metrics”, 1978)

încearcă să identifice calităţi specifice produselor, potrivite software-ului.
El grupează calităţile software în 3 mulţimi:
• product operation qualities;
• product revision qualities;
• product transition qualities.
Factorii product operation quality
• Corectitudinea. Marja până la care programul staisface specificaţiile şi
îndeplineşte obiectivele utilizatorului;
• Fiabilitatea. Marja până la care se aşteaptă ca programul să lucreze în
parametrii specificaţi cu precizia dorită;
• Eficienţa. Cantitatea de resurse cerută de software;
• Integritate. Marja până la care accesul la software sau date a
persoanelor neautorizate poate fi controlat;
• Usability (mod de utilizare). Efortul necesar pentru a învăţa, opera,
pregăti intrarea şi interpreta ieşirea.

Factorii product revision quality

• Întreţinere. Efortul necesar pentru localizarea şi repararea erorii într-un
program operaţional;
• Testabilitatea. Efortul necesar pentru a testa un program pentru a
asigura că lucrează în parametrii specificaţi;
• Flexibilitate. Efortul necesar pentru a modifica un program operaţional.
Factorii product transition quality
• Portabilitate. Efortul necesar pentru transferul programului de pe o
configuraţie hardware şi un mediu software pe alta/altul;
• Refolosirea. Marja până la care un program poate fi utilizat în alte
aplicaţii;
• Interoperabilitate. Efortul necesar pentru a cupla un sistem cu altul.

Pentru fiecare criteriu, trebuie inventate nişte măsuri pentru a evalua

gradul în care calitatea e prezentă.
Orice măsură relativă bună trebuie să compare numărul unităţilor la
maximul posibil în acele circumstanţe. De exemplu, numărul maxim de
erori într-un program va fi raportat la mărimea programului, astfel încât
măsura “numărul de erori la mia de linii de cod” e mai utilă decât “numărul
de erori din program”.

În anumite cazuri putem măsura calitatea în mod direct, în timp ce în

altele lucrul măsurat nu e calitate propriu-zisă, dar reprezintă un indicator
care să indice în ce grad e prezentă calitatea.
 4. ISO 9126 (standard publicat în 1991)

ISO 9126 identifică 6 categorii de calitate a software-ului:

• funcţionalitate, care acoperă funcţiile pe care produsul software le
asigură pentru satisfacerea nevoilor utilizatorilor;
• siguranţă (reliability), care se referă la capabilitatea software-ului
pentru a menţine nivelul de performanţă;
• usability, care se referă la efortul cerut pentru a utiliza software-ul;
• eficienţă, care se referă al resursele fizice folosite când software-ul e
executat;
• mentenabilitate, care se referă la efortul cerut pentru a face schimbări
software-ului;
• portabilitate, care se referă la abilitatea software-ului de a fi transferat
în diferite medii.

ISO 9126 oferă subcaracteristici pentru fiecare categorie primară, utile

pentru clarificarea categoriei principale.
Funcţionalitate Suitability (cât de potrivit este)
Acurateţe
Interoperabilitate (abilitatea de a interacţiona)
Conformitate (compliance)(faţă de standardele legale)
Securitate

Siguranţă Maturitate (frecvenţa eşecurilor datorate erorilor)

Toleranţă la erori
Recuperabilitate

Usability Înţelegere (Understandability)

Învăţare (Learnability)
Operabilitate (Operability)
Obs. Understandability e calitatea de a putea pătrunde conceptele logice şi aplicabilitatea
lor. Learnability este diferită de operability. Un instrument software poate fi uşor de învăţat,
dar consumator de timp la utilizare, deoarece, de exemplu, utilizează un număr mare de
meniuri în cascadă.
Eficienţă Comportare în timp
Comportare d.p.d.v. al resurselor
Mentenabilitate Analisability
Flexibilitate (Changeability)
Stabilitate
Testabilitate
Obs. Analisability (sau diagnosability) este uşurinţa cu care de determină cauza unui eşec.
Changeability (sau flexibility) implică faptul că furnizorii de software îl schimbă totdeauna.
Stabilitatea înseamnă că există un risc mic ca o modificare a software-ului să aibă efecte
neaşteptate.

Portabilitate Adaptabilitate
Uşurinţa instalării (Installability)
Conformitate (Conformance)
Uşurinţa de a fi înlocuit (Replaceability)
Obs. Conformance, spre a se distinge de compliance, se referă la acele standarde care
privesc portabilitatea. Exemplu: folosirea unui limbaj de programare standard în multe medii
software/hardware e exemplu de conformance.

Obs. Replaceability se referă la factori care dau compatibilitatea ”în sus” între componentele
software vechi şi cele noi.
ISO 9126 oferă anumite indicaţii privind folosirea caracteristicilor de
calitate. Pentru sistemele interactive (interactive end user system),
elementul primordial d.p.d.v. al calităţii ar fi usability.

O dată cerinţele software stabilite, se stabilesc următorii paşi:

Selectarea metricilor de calitate. Nu sunt date indicaţii în standardul ISO
9126 privind aplicabilitatea diverselor măsuri ce trebuie folosite.
Definirea nivelelor de rating. Metricile folosite trebuie să se mapeze pe
scale care să indice gradul în care au fost satisfăcute cerinţele.
Definirea criteriilor de evaluare. Este felul în care scorurile d.p.d.v. al
calităţii se combină pentru a da o vedere de ansamblu asupra produsului.
Mai jos e dat un exemplu de acordare a scorurilor:
 5. Măsuri practice ale calităţii software

Mai jos sunt date orientativ anumite modalităţi de măsurare a unor calităţi
particulare. Fiecare proiect va trebui să aibă însă propriile măsuri.

Reliability
Aceasta poate fi măsurată în termeni de:
• disponibilitate(availability), procentul unui interval de timp în care
sistemul poate fi folosit;
• timpul mediu dintre eşecuri, timpul total de lucru, împărţit la numărul
de eşecuri;
• eşec la cerere, probabilitatea ca un sistem să nu fie disponibil la un
anumit timp sau probabilitatea ca o tranzacţie să eşueze;
• activitatea de suport (support activity), numărul de rapoarte de erori.
Mentenability
Poate fi văzută ca flexibilitate plus diagnosability, care poate fi definită
drept timpul mediu necesar pentru diagnosticarea unei erori.
Obs. D.p.d.v. al utilizatorului, mentenability priveşte timpul scurs între
detectarea unei erori şi corectarea ei, iar d.p.d.v. al managementului de
programare ca efortul necesar.

Extendibility (capacitatea de a fi extins)

E o componentă a flexibilităţii. Se defineşte ca productivitatea necesară
pentru a încorpora anumite caracteristici noi în sistemul existent.
 6. Standarde externe
Unele standarde de calitate au fost gândite pentru toate produsele, nu
doar pentru produsele software.
I) O privire asupra cerinţelor standardului BS EN ISO 9001:
a) Conducerea trebuie să definească şi să documenteze politică privind
calitatea şi trebuie să asigure că această politică e adusă la cunoştinţa
persoanelor din toate nivelele;
b) Toate procedurile de control al calităţii trebuie documentate;
c) Toate contractele pentru a furniza bunuri şi servicii trebuie să conţină
cerinţe agreate mutual pe care dezvoltatorul este capabil să le livreze;
d) Trebuie să existe proceduri pentru controlul şi verificrea designului
sistemului ce urmează să fie livrat, astfel încât să fie îndeplinite
cerinţele stabilite cu utilizatorul;
e) Trebuie să existe proceduri care să aprobe designul şi documentaţia
auxiliară.
f) Acolo unde componentele sistemul ce urmează să fie livrate sunt
obţinute de la un partener extern, trebuie să existe proceduri care să
asigure, să verifice şi să menţină calitatea acestor componente;
g) Produsele individuale trebuie să fie identificabile, precum şi
componentele sale;
h) Procesul prin care e creat produsul final trebuie să fie planificate şi
monitorizare;
i) Inspecţia şi testarea trebuie să aibă loc în timpul fazei de dezvoltare şi
înainte de livrare. De asemenea, testele şi inspecţiile trebuie să se facă
şi asupra componentelor obţinute de la parteneri extern.
j) Echipamentul folosit în procesul de producţie trebuie să fie controlat
adecvat în privinţa calităţii;
k) Statutul testării pentru toate componentele şi sistemele trebuie să fie
înregistrat clar în toate etapele;
l) Trebuie avut grijă ca itemii care sunt cunoscuţi ca potenţial de a se
defecta să fie folosiţi cu mare atenţie;
m) Când se identifică un defect, trebuie luate măsuri pentru îndepărtarea
părţii defecte şi pentru a ne asigura că defectul nu apare din nou;
n) Trebuie să existe proceduri corespunzătoare manipularării, stocării,
împachetării şi livrării produsului;
o) Trebuie menţinute suficiente înregistrări care să demonstreze că
sistemul de asigurare a calităţii lucrează cu succes;
p) Sistemul de management al calităţii software trebuie să fie supus
auditului;
q) Activităţile de service şi suport trebuie să fie subiect pentru sistemul de
management al calităţii;
r) Dezvoltatorul trebuie să stabilească tehnici statistice potrivite care să
verifice că produsul final poate fi recepţionat.

II) TickIt. Department of Trade and Industry (DTI) a formulat standardul

TickIt, care dă interpretarea standardului ISO 9000 (mai ales în ceea ce
priveşte dezvoltarea software). Acesta include cerinţe, cum ar fi:

a) Trebuie să existe un plan de dezvoltare detaliat de a începe

dezvoltarea;
b) Vor fi folosite proceduri de control în toate etapele dezvoltării;
c) Trebuie făcute revizuiri ale designului;
d) Trebuie revizuită metodologia suitability designului;
e) Trebuie revizuit progresul sistematic;
f) Trebuie să fie posibilă găsite caracteristicile designului software la
specificaţii şi cerinţe;
g) Designul trebuie documentat corespunzător;
h) Trebuie produse planurile de testare potrivite, specificaţiile şi
înregistrările;
i) Trebuie pus în practică un code of practice, care guvernează felul în
care software-ul e dezvoltat.

Code of practice trebuie să includă cerinţe precum:

• Designul trebuie să fie divizat pe nivele, fiecare cu intrări şi ieşiri
identificabile;
• Software-ul trebuie organizat pe module;
• Un modul trebuie să îndeplinească în mod normal o singură funcţie sau
o mulţime de funcţii înrudite;
• o descriere trebuie să existe pentru fiecare modul.
III) Capability process models
În loc să verifice că un sistem e în stare să detecteze erori, un client poate
cere că vadă dacă furnizorul foloseşte metode şi instrumente de
dezvoltare software care să fie potrivite pentru a produce un software de
bună calitate.
În SUA s-a dezvoltat un capability maturity model (CMM) la Software
Engineering Institute (SEI). Acesta încearcă să plaseze organizaţiile care
produc software într-unul dintre cele 5 nivele de maturitate pentru a indica
cât de sofisticate sunt şi cât de calitative sunt practicile de producere a
software-ului. Aceste nivele dunt definite după cum urmează:

• Nivelul 1: Initial Procedurile urmate tind să fie întâmplătoare. Anumite

proiecte vor avea succes, dar asta datorită doar priceperii unor
profesionişti din echipă (inclusiv managerii). Nu există nivel 0 şi de
aceea orice organizaţie va fi implicit la acest nivel.

• Nivelul 2: Repeatable Organizaţiile de la acest nivel vor avea

proceduri de bază pentru managementul proiectelor. Totuşi felul în
care o sarcină individuală e dusă la bun sfârşit va depinde în mare
măsură de persoana care o face.
• Nivelul 3: Defined Organizaţiile au definit felul în care fiecare sarcină
a ciclului de viaţă al dezvoltării software va fi făcută.
• Nivelul 4: Managed Produsele şi procesele implicate în dezvoltarea
software sunt subiect al măsurii şi controlului.
• Nivelul 5: Optimizing Îmbunătăţirile aduse procedurilor sunt
concepute şi implementate folosind datele adunate în proceseul de
măsurare.
Pentru fiecare dintre aceste nivele, exceptând nivelul 1, s-au identificat arii
de proces cheie (key process areas – KPAs) care să facă distincţia între
nivelul curent şi nivelele mai joase. Aceste KPAs sunt listate mai jos:
 7. Tehnici care ajută la creşterea calităţii software

Tehnicile care ajuta la creşterea calităţii software por fi încadrate în trei

mari teme:

• Increasing visibility Un pas important pentru a face procesele de

dezvoltare software mai vizibile a fost pledoaria lui Gerald Weinberg
pentru o programare mai puţin egoistă (“egoless programming”), care a
încurajat practica simplă a programatorilor care să se uite la codul
celorlaţi.
• Procedural structure S-au dezvoltat, de-a lungul anilor, metodologii în
care fiecare proces în ciclul de dezvoltare software să fie cu grujă
planificat pe etape.

• Checking intermediate stages Un element important în vederea

obţinerii unor practici pentru calitate a fost verificarea corectitudinii
muncii în etapele incipiente, conceptuale. Ideea este să se poată
obţine modele ale muncii, chiar dacă nu perfecte, care să poate fi
depanate ulterior.
Dintre tehnicile specifice temelor majore aminitite, enumerăm:
• Inspecţiile
• Metoda Fagan (vezi M.E.Fagan: “Design and code inspections to reduce
errors in program development”, IBM System Journal, 15(3)).
• Programarea structurată (Dijkstra a introdus conceptul, iar Harlan Mills a
dezvoltat conceptul, împărţind dezvoltarea software în 3 echipe: una
pentru specificaţii, una pentru dezvoltare a codului şi una de testare)
• Metode formale (care definesc pre- şi post- condiţii pentru fiecare
procedură)
• Software quality circles (SWQC) ( tehnică apărută în Japonia): un quality
circle e un grup de 4-10 oameni lucrând în aceeaşi arie, care se întâlnesc
o oră pe săptămână (de exemplu) pentru a identifca, analiza şi rezolva
problemelor legate de munca lor comună.
• Abordarea GQM (Goal/Question/Metrics)
 Concluzii

• Calitatea în sine e un concept vag şi cerinţele de calitate practice trebuie

definite cu mare atenţie
• Trebuie să existe moduri practice de testare a prezenţei sau absenţei
calităţii
• Multe dintre calităţile care sunt aparente utilizatorilor de software pot fi
testate doar atunci când sistemul e complet
• E nevoie deci de modalităţi de verificare a calităţii probabile în timpul
dezvoltării
• Anumite tehnici de creştere a calităţii se concentrează pe testarea
produselor procesului de dezvoltare, în timp ce altele încearcă să
evalueze calitatea proceselor de dezvoltare folosite.
Calitatea software-ului

- Laborator -
Problema 1. Un sistem cuprinde 5000 SLOC, pentru implementarea
căruia a fost nevoie de 400 zile-muncă. Un amendament la sistem a
provocat adăugarea a 100 SLOC, care au luat 20 zile-muncă pentru
implementare. Calculaţi:
a) productivitatea sistemului original
b) Productivitatea pentru amendament
c) Extendibilitatea

Problema 2. Sugeraţi specificaţii de calitate pentru un editor de texte.

Problema 3. Un sistem a fost instalat şi e disponibil în mod normal de la

8 a.m. la 6 p.m., de luni până vineri. Într-o perioadă de 4 săptămâni,
sistemul a fost indisponibil timp de o întreagă zi din cauza unor
probleme cu harddiscul şi indisponibil alte 2 zile până la 10 a.m. Din
cauza unor unităţi. Care este availability şi timpul mediu dintre eşecuri
(failures), presupunând că au fost 3 eşecuri?
Problema 4. Identificaţi instanţe specifice în mediul de dezvoltare
software unde sunt relevante cerinţele:
a) privind controlul echipamentului (punctul (j) din standardul BS EN ISO
9001);
b) privind înregistrarea statusului testării al tuturor componenetelor
(punctul (k) din standardul BS EN ISO 9001);
c) privind mânuirea corectă, depozitarea, împachetarea şi livrarea
produsului (punctul (m) din standardul BS EN ISO 9001)
Ce proceduri s-ar aplica în mediul software în legătură cu aceste
necesităţi?
Indicaţii şi răspunsuri
Problema 1. Un sistem cuprinde 5000 SLOC, pentru implementarea
căruia a fost nevoie de 400 zile-muncă. Un amendament la sistem a
provocat adăugarea a 100 SLOC, care au luat 20 zile-muncă pentru
implementare. Calculaţi:
a) Productivitatea sistemului original
b) Productivitatea pentru amendament
c) Extendibilitatea

Soluţie.
a) Productivitatea sistemului original=5000/400=12,5
b) Productivitatea pentru amendament=100/20=5
c) Extendibilitatea=5/12,5x100=40%
Problema 2. Sugeraţi specificaţii de calitate pentru un editor de texte.

Indicaţii. Software-ul se poate diviza într-un număr de arii de interes,

care se evaluează separat, cum ar fi pregătirea documentului,
prezentarea, îmbinarea corespondenţei etc.
De exemplu;
• Calitate – uşurinţa învăţării;
• Definiţie – timpul necesar unui novice pentru a învăţa să opereze a.î.
să producă un document standard;
• Scara – ore
• Test – oferiţi-i sistemul, un manual de utilizare şi un document pe
care săâl pregătească. Cronometraţi cât îi ia (consideraţi, de
exemplu, că planificat este 2 ore, cel mai bun caz îi ia 1 oră, cel mai
rău 4 ore)
Problema 3. Un sistem a fost instalat şi e disponibil în mod normal de la
8 a.m. la 6 p.m., de luni până vineri. Într-o perioadă de 4 săptămâni,
sistemul a fost indisponibil timp de o întreagă zi din cauza unor
probleme cu harddiscul şi indisponibil alte 2 zile până la 10 a.m. Din
cauza unor unităţi. Care este availability şi timpul mediu dintre eşecuri
(failures), presupunând că au fost 3 eşecuri?

Soluţie. Sistemul trebuie să fie disponibil în fiecare zi 18-8 = 10 ore.

Pe perioada de 4 săptămâni va trebui să fie disponibil 10x5x4 = 200 ore.
Nu a fost disponibil o zi, adică 10 ore.
Nu a fost diponibil încă 2 zile, adică 2x(10-8) = 4 ore.
A fost disponibil deci 200 – 10 – 4 = 186 ore.
Availability este aşadar 186/200x100 = 93%.
Timpul mediu dintre eşecuri este 186/3 = 62 ore.
Problema 4. Identificaţi instanţe specifice în mediul de dezvoltare
software unde sunt relevante cerinţele:
Indicaţie.
b) Statusul testării. Componentele software care sunt actualizate nu
sunt eliberate către utilizatori înainte ca o testare adecvată să fie
făcută.
Evaluarea proiectului
 1. Introducere

Ideea de a începe (continua) munca la un proiect este de fapt

compararea unui proiect cu alternativele sale şi hotărârea de
a merge mai departe sau nu.

Evaluarea se va baza pe criterii strategice, tehnice şi

economice.

Evaluarea proiectului se face în pasul 0 al Step Wise.

 2. Evaluarea strategică

Programul (programme) este definit ca un “grup de proiecte

ce ce sunt manageriate într-un mod coordonat pentru a obţine
un beneficiu care nu s-ar obţine dacă proiectele ar fi
manageriate independent” (D.C.Ferne, 1991).
De aceea e nevoie de un plan strategic care să definească
obiectivele organizaţiei. În acest fel se definesc scopurile
programului. Va exista aşadar, mai ales în cazul organizaţiilor
mari, o structură organizatorică pentru managementul
programului. Responsabil va fi un director de program.

Chiar dacă nu există un program explicit definit, orice proiect

propus va fi evaluat în cadrul general al obiectivelor de
business ale organizaţiei.
 Principalele probleme şi întrebările care se pun

Obiective Cum va contribui sistemul propus la obiectivele

stabilite ale organizaţiei? De pildă, pot creşte
cifra de afaceri?
Plan IS Cum se încadrează sistemul propus în planul IS?
Cu ce sistem existent va interfera noul sistem?
Ce sistem existent va înlocui?
Structura Ce efect va avea noul sistem asupra
organizaţiei organizaţiei?
MIS Ce informaţii va aduce sistemul şi la ce nivel?

Personal Ce implicaţii aduce asupra politicii globale

asupra personalului?
Imagine În ce fel va afecta imaginea clienţilor organizaţiei
noul sistem?
IS = Information System
MIS = Management Information System
 3. Evaluarea tehnică
Constă în evaluarea funcţionalităţii faţă de hardware-ul şi
software-ul existent.
4. Analiza costurilor - beneficiilor
“Orice proiect ce necesită investiţii trebuie să obţină cel puţin
un beneficiu mai mare decât dacă s-ar depozita suma de
investiţii într-o bancă, de exemplu.”
Trebuie aleasă cea mai bună opţiune de proiect dintre cele
disponibile.
Analiza costurilor – beneficiilor se face în două etape:
• identificarea şi estimarea tuturor costurilor şi beneficiilor
pentru ducerea la bun sfârşit a proiectului.
• exprimarea acestor costuri şi beneficii în unităţi comune.
Trebuie evaluat beneficiul net, ca diferenţă dintre beneficiul total şi
costurile totale. De accea, trebuie exprimate beneficiile şi costurile
în bani efectivi.
Clasificarea costurilor:
• Costuri de dezvoltare: include salariile şi alte costuri pentru echipa
de dezvoltatori ai proiectului, precum şi costurile asociate.
• Costuri de organizare (setup): costurile pentru punerea sistemului
în practică şi include costurile pentru orice hardware nou şi
echipamente auxiliare, dar şi pentru conversia fişierelor, recrutarea
şi pregătirea personalului.
• Costuri operaţionale: include costurile necesare după ce sistemul
a fost instalat.

Clasificarea beneficiilor:
• Beneficii directe: sunt mai uşor de estimat, din exploatarea directă
a sistemului.
• Beneficii indirecte estimabile: sunt în general beneficii secundare,
cum ar fi acurateţea crescută prin introducerea unei interfeţe mai
prietenoase, la care putem aprecia reducerea erorilor.
• Beneficii indirecte intangibile: sunt beneficii foarte greu de
cuantificat.
 5. Estimarea fluxului banilor
(Cash-flow forecasting)
Estimarea fluxului banilor se poate arăta când apar cheltuielile
(expenditure) şi venitul.

Dificultatea şi importanţa cash-flow forecasting e evidenţiat de

numărul companiilor care dau faliment deoarece, deşi dezvoltă
produse sau servicii profitabile, nu pot susţine cheltuieli
neplanificate (se observă şi din grafic ca la început e necesar să se
facă investiţii, venitul apărând când sistemul poate fi exploatat).
Inflaţia poate cauza cheltuieli neprevăzute.
De exemplu, tabelul de mai jos indică estimarea cash flow pentru 4
proiecte:
 6. Tehnici de evaluare cost - beneficiu

Pentru tabelul de mai jos, întocmiţi un clasament privind

dezirabilitatea proiectelor prezentate şi motivaţi alegerea făcută:
Profitul net: este diferenţa dintre venitul total şi cheltuieleile totale. În
tabelul precedent, proiectul 2 are profitul net cel mai mare, dar
necesită şi cea mai mare investiţie iniţială (1 milion).
Perioada de restituire (Payback period): este timpul scurs până la
acoperirea investiţiei iniţiale.
Temă: calculaţi perioada de restituire pentru fiecare proiect din
tabelul precedent.
Return on investment (ROI) sau Accounting rate of return (ARR)
este o metodă de a compara profitabilitatea netă cu investiţia
cerută:

Temă. Calculaţi ROI pentru fiecare dintre proiectele prezentate în

tabelul precedent.
Un dezavantaj al acestui criteriu este acela că nu ţine seama de
timpul necesar al cash-flow.
Net present value (NPV) şi internal rate of return (IRR) sunt
cunoscute ca tehnici de discounted cash flow (DCF). Calcularea
NPV este o tehnică de evaluare a proiectului şi ia în calcul
profitabilitatea proiectului şi timing-ul cash flows care sunt produse.
Se determină prin reducerea (discounting) viitoarelor cash flows cu
un procent numit rată de discount.

valoare in anul t
valoare prezenta =
(1 + r ) t

unde r este rata de discount.

Valoarea prezentă a unui cash flow poate fi calculată prin înmulţirea
cash flow cu factorul de discount potrivit.
NPV pentru un proiect poate fi calculat prin reducerea fiecărui cash
flow şi însumarea valorilor reduse.
Exemplu de calcul a NPV pentru proiectul 1:

Temă. Calculaţi NPV pentru proiectele 2,3 şi 4 şi indicaţi care dintre

proiecte poate fi ales, pe baza criteriului NPV.
Internal rate of return (IRR).
Un dezavantaj al NPV ca măsura a profitabilităţii e acela că, deşi e
utilizat ca metodă de comparare a proiectelor, s-ar putea să nu fie
direct comparabile cu câştigurile cu alte investiţii.
IRR încearcă să ofere o măsură a profitabilităţii ca un beneficiu
procentual ce e direct comparabil cu ratele dobânzilor (interest
rates). De aceea, un proiect ce are IRR de 10% va merita dacă, de
exemplu, capitalul poate fi împrumutat cu mai puţin de 10% sau
dacă nu poate fi investit în altă parte cu un beneficiu mai mare de
10%.

IRR e calculat ca rata de discount procentuală ce va produce NPV

cu valoare 0. Se poate calcula cu uşurinţă folosind, de exemplu,
Microsoft Excel, care are implementate funcţii specifice.
Obs. Se pot găsi mai multe valori care să produce o valoare 0 a
NPV. În acest caz, se poate lua valoarea cea mai mică şi ignora
celelalte valori.
Obs. NPV şi IRR nu oferă totuşi răspunsul complet la o evaluare
economică a unui proiect.

• O evaluare totală trebuie să ia în considerare problemele de

“funding of cash flows”.

• În timp ce IRR ar putea indica un proiect profitabil, viitoarele

câştiguri ar putea fi de departe mai mici decât dacă s-ar fi depozitat
banii într-o bancă. De accea trebuie luat în calcul ca un proiect să
aducă un beneficiu cu mai mult de 15%, să zicem, faţă de interest
rates.

• Trebuie avută în vedere o întrebare de genul: dacă finanţăm acest

proiect, mai putem finanţa şi alte proiecte valoroase?
 7. Evaluarea riscurilor
Principalul risc este acelă că proiectul s-ar putea să nu
îndeplinească obiectivele pentru care a fost gândit. Nu e un risc
dacă proiectul se termină mai repede decât a fost planificat şi
folosind un buget mai mic!
Identificarea şi clasificarea riscurilor
O abordare pentru analiza riscurilor ar fi să se creeze o matrice a
riscurilor posibile folosind o listă cu riscurile posibile şi să clasificăm
fiecare risc în raport cu importanţa lui şi probabilitatea de apariţie.
Exemplu de o parte de astfel de matrice, unde H – mare (high), M –
medie, L – scăzută (low). Într-un capitol ulterior se dau detalii.
Riscurile şi NPV
Când un proiect e relativ riscant, e bine să se folosească o rată de
discount mai mare pentru calculul NPV.

Analiza cost-beneficiu
O abordare mai sofisticată a evaluării riscurilor este să se considere
fiecare posibil efect şi estimarea probabilităţii ca el să apară. În loc
de o singură estimare a cash flow, vom avea o mulţime de cash
flows, fiecare cu o probabilitate de apariţie. Valoarea proiectului e
obţinută prin însumarea costurilor sau beneficiilor pentru fiecare
rezultat, sumă ponderată cu probabilitatea corespunzătoare.

Această abordare e potrivită mai ales pentru proiectele mari, unde

există suficienţi factori de incertitudine. Pe de altă parte, stabilirea
probabilităţilor de apariţie a riscurilor nu e uşor de făcut.
Analiza profilului riscului (risk profile analysis)

O abordare este analiza sensibilităţii (senzitivity analysis).

Aceasta presupune variaţia fiecărui parametru ce afectează costul

sau beneficiul proiectului pentru a stabili cât de sensibilă e
profitabilitatea proiectului la fiecare factor. Rezultă astfel
identificarea factorilor decisivi pentru succesul proiectului.

Obs. Analiza sensibilităţii presupune variaţia unui singur factor la un

moment dat. Se foloseşte metoda Monte Carlo pentru astfel de
simulări. Există instrumente software care implementează metoda.
Folosirea arborilor de decizie
Sunt multe situaţii când în care putem evalua dacă un factor de risc
e important şi dacă e, ce acţiuni trebuie urmate. Multe asemenea
decizii vor limita sau vor afecta viitoarele decizii şi, în fiecare punct,
e important să privim în viitor pentru a vedea cum poate o decizie
să afecteze profitabilitatea proiectului.

Exemplu. Pentru extinderea sistemului de facturare, o firmă poate

lua în calcul extinderea sistemului existent sau înlocuirea completă
a lui, imediat sau mai târziu. Înlocuirea imediată înseamnă
amânarea unor proiecte. Neînlocuirea la timp poate fi o opţiune
scumpă, în condiţiile în care conduce la pierderea beneficiului din
cauza neputinţei de a satisface toate cererile.
S-a calculat că extinderea sistemului are NPV 57000 Euros, deşi
dacă piaţa se extinde smenificativ, poate conduce la o valoare a
NPV de -100000 Euros. Dacă piaţa creşte, o înlocuire a sistemului
acum duce la NPV de 250000 Euros. Dacă vânzările nu cresc,
beneficiile se vor reduce, conducând la NPV de -50000 Euros.
Exemplu (continuare). Compania apreciază că probabilitatea să
crească piaţa e de 20%, adică probabilitatea să nu crească fiind de
80%. Acest scenariu poate fi reprezentat în figura de mai jos.

75000*0.8+(-100000)*0.2
=40000 Euros

250000*0.2+(-50000)*0.8
=10000 Euros

Analiza unui arbore de decizie constă în evaluarea beneficiului

aşteptat luând-o pe fiecare ramură a unui punct de decizie (notat cu
D în figură).
Un avantaj al folosirii arborilor de decizie este că se pot extinde cu
uşurinţă (vezi figura de mai jos):
 8. Concluzii

• Proiectele trebuie evaluate strategic, tehnic şi economic;

• Evaluarea economică implică identificarea tuturor costurilor şi
beneficiilor pe toată durata de viaţă a sistemului şi verificarea dacă
totalitatea beneficiilor depăşeşte totalitatea costurilor;
• O sumă de bani câştigaţi mai târziu este mai puţin valoroasă decât
aceeaşi sumă de care să dispuneţi în prezent, care pot fi investiţi;
• Tehnicile de discounted cash flow pot fi folosite pentru a calcula
valoarea prezentă a future cash flow, ţinând cont de rata dobânzilor
(interest rates) şi de gradul de nesiguranţă (uncertainty);
• Tehnicile de analiză cost-beneficiu şi arborii de decizie furnizează
instrumente pentru evaluarea rezultatelor aşteptate (expected
outcomes) şi alegerea între diverse strategii.
Managementul riscului
 1. Introducere

În această prezentare, atenţia se concentrează pe riscul datorat

întârzierii proiectului sau depăşirii bugetului alocat

Identificăm trei tipuri de riscuri:

• cele cauzate de dificultăţile inerente ale estimării;
• cele datorate presupunerilor făcute în timpul procesului de
planificare;
• cele datorate unor evenimente apărute neaşteptat.
Estimarea erorilor
Anumite sarcini sunt greu de estimat din cauza lipsei experienţei cu
sarcini similare, de aceea e indicat să existe manuale de utilizare. Pe de
altă parte, timpul petrecut cu testarea şi depanarea poate fi greu de
prognozat cu un grad de acurateţe mărit.
Estimarea poate fi îmbunătăţită dacă se analizează datele istorice pentru
activităţi similare şi sisteme similare. Păstrarea înregistrărilor comparând
estimările originale şi rezultatele finale vor pune în evidenţă tipurile de
sarcini pentru care se fac cu greu estimări corecte.

Presupunerile făcute la planificarea activităţilor

La fiecare etapă a procsului de planificare, e important să listăm explicit
toate presupunerile care au fost făcute şi să identificăm ce efecte pot
avea asupra planului dacă sunt nepotrivite.

Posibilităţi
Anumite posibilităţi nu pot fi prevăzute. Totuşi, majoritatea evenimentelor
neaşteptate pot fi, în realitate, prevăzute. Asemenea evenimente se pot
întâmpla din timp în timp şi, chiar dacă probabilitatea de apariţie a lor să
fie mică, trebuie luate în calcul şi planificate.
 2. Managementul riscurilor

Există un număr de modele pentru managementul riscului, dar majoritatea

sunt similare, pentru că identifică două componente majore – identificarea
riscului (risk identification) şi managementul riscului (risk management). În
figura de mai jos e dată o structură divizată în sarcini, pe care Barry
Boehm o numeşte ingineria riscului (risk engineering). Toate elementele
din figură se vor discuta în detaliu în slide-urile următoare.
 3. Identificarea riscurilor (risk identification)

Trebuie făcută distincţia dintre cauza întâmplătoare (hazard) şi efectul

produs de acesta.
Anumite cauze întâmplătoare sunt generice – adică sunt relevante pentru
toate proiectele software. Asemenea riscuri sunt înţelegerea greşită a
cerinţelor şi starea de boală a persoanelor cheie implicate în proiect.
Alte riscuri sunt specifice – care vor fi identificate mai greu şi numai cu
suportul întregii echipe a proiectului.

Categoriile care trebuie luate în considerare sunt:

Factorii legaţi de aplicaţie (application factors) – natura aplicaţiei (fie că
e vorba de o aplicaţie de porcesare simplă a datelor, de un sistem critic din
punct de vedere al securităţii sau de sisteme distribuite) poate fi un factor
critic. De asemenea, mărimea aşteptată a aplicaţiei e importantă (cu cât e
mai mare aplicaţia, cu atât probabilitatea de apariţie a erorilor e mai mare).
Factorii legaţi de personal (staff factors) – un programator experimentat
face, de regulă, mai puţine erori decât unul cu mai puţină experienţă. Pe
de altă parte, e importantă aria în care unii au experienţă (experienţa unui
programator în Cobol nu prea contează dacă dezvoltă un sistem în C++).

Factorii legaţi de proiect (project factors) – e important ca proiectul şi

obiectivele sale să fie bine definite şi să fie clare pentru toţi membrii
proiectului şi pentru stakeholders.

Metode legate de proiect – folosind anumite metode pentru

managementul proiectelor şi dezvoltarea de sistem se scade probabilitatea
ca sistemul să fie livrat târziu sau cu probleme. Pe de altă parte, folosirea
acestor metode pentru prima oară poate duce la întârzieri.

Factorii hardware/software – un proiect care necesită hardware nou

poate pune probleme mai mari decât dacă se dezvoltă sistemul pe un
hardware existent. Realizarea proiectului pe un tip de hardware şi o
platformă software şi utilizarea sistemului pe un alt hardware şi/sau
software poate ridica anumite probleme la instalare şi nu numai.
Factorii legaţi de schimbări (changeover factors) – o schimbare
radicală pentru noul sistem facilitează apariţia riscurilor. Schimbările
graduale minimizează riscurile dar nu sunt întotdeauna practice.

Factorii legaţi de furnizori (supplier factors) – un proiect se bazează

uneori pe organizaţii exterioare. Riscurile legate de întârzierile cu care
livrează anumite produse sau de calitatea acestora nu pot fi controlate.

Factorii de mediu (conjuncturali) – de exemplu, schimbări legate de

regulile de plata a salariilor (modificarea CAS, a sporurilor etc) pot afecta
succesul unui proiect ce gestionează salarizarea într-o organizaţie.

Factorii de sănătate şi siguranţă – deşi impactul asupra sănătăţii şi

siguranţei celor care interacţionează cu un proiect software e diminuat faţă
de alte proiecte (de exemplu, construcţii), totuşi, conform BS 6079, “orice
proiect trebuie să includă un audit al acestor posibile riscuri înainte de a
începe”, iar acest audit trebuie să facă parte din planul de ansamblu al
proiectului.
 4. Analiza riscurilor (risk analysis)

Identificând riscurile, e utilă o cale de a le evalua importanţa. Anumite

riscuri au probabilitate mai mare de apariţie (cum ar fi îmbolnăvirea unuia
dintre membrii echipei, chiar şi pentru o perioadă scurtă de timp), iar altele
au probabilitate mică de apariţie (un eşec hardware să ducă, de exemplu,
la pierderea întregului cod scris).

Probabilitatea apariţiei unei cauze întâmplătoare de risc e cunoscută ca

probabilitatea riscului (risk likehood). Efectul rezultat, dacă apare, se
numeşte impactul riscului (risk impact) şi importanţa riscului e cunoscută
ca valoarea riscului (risk value sau risk exposure). Risk value e calculat:
risk value = risk likehood x risk impact
Obs. Termenii de mai sus pot fi întâniţi şi sub alte denumiri, nu sunt
denumiri universal acceptate.

Ideal, impactul riscului e exprimat în termeni monetari şi probabilitatea

riscului ca probabilitate (număr subunitar). În acest caz, valoarea riscului
va reprezenta costul aşteptat (expected cost). Se pot compara aşadar
valorile riscului pentru a evalua iportanţa relativă a riscurilor.
Mulţi manageri folosesc o metodă prin care se dau scoruri riscurilor,
pentru a oferi o măsură cantitativă pentru evaluarea fiecărui risc. Un scor
ar putea fi împărţirea în trei categorii (High, Medium, Low), dar se
recomandă (şi e mai populară) metoda în care se dau note de la 1 la 10
(unde 10 este pentru probablitatea cea mai mare de apariţie e unei erori).

Măsurile de impact, notate pe o scară similară, trebuie să ia în

consideraţie riscul total al proiectului. Acesta trebuie să includă
următoarele costuri potenţiale:
• costul întârzierilor faţă de datele planificate pentru deliverables;
• supracostul datorat de folosirea adiţională a unor resurse;

În tabelul următor se dă un exemplu de calcul a valorii riscului pentru un

anumit proiect.
Acordarea de priorităţi riscurilor
Managerii folosesc două strategii:
• reducerea valorii riscului prin reducerea probabilităţii riscului sau a
impactului riscului;
• realizarea unor planuri de rezervă (care să ia în calcul întâmplări
neprevăzute), astfel încât, dacă riscurile apar, să fie gestionate.

Oricare dintre aceste strategii vor avea un cost asociat. De aceea e

importantă acordarea de prorităţi riscurilor, pentru ca cele mai importante
să primească atenţia cea mai mare.

În practică, sunt în general alţi factori care trebuie luaţi în calcul atunci
când vrem să aranjăm în funcţie de prioritate:
• Riscuri acumulate. Când se întâmplă acest lucru, riscurile trebuie
tratate ca şi cum ar fi un singur risc.
• Numărul riscurilor. Există un număr maxim de riscuri ce trebuie
considerate efectiv de un manager
• Costul acţiunii. Anumite riscuri, o dată identificate, pot fi reduse sau
evitate imediat cu un cost redus. Pentru alte riscuri trebuie să comparăm
costurile cu efectuarea acţiunii cu beneficiile reducerii riscului. O metodă
e să se calculeze risk reduction leverage (RRL):

REina int e − REdupa

RRL =
cos t reducere risc

unde REinainte e valoarea riscului originală, REdupa este valoarea riscului

aşteptată după trecerea la acţiune, iar cost reducere risc este costul
implementării acţiunii de reducere a riscului.
 5. Reducerea riscurilor

În linii mari, există 5 strategii de reducere a riscului:

• Prevenirea hazardului.

• Reducerea probabilităţii de apariţie.

• Evitarea riscului.

• Transferul riscului. Anumite riscuri pot fi transferate, de exemplu

printr-o asigurare.

• Planificarea de rezervă (contingency planning)

În tabelul de mai jos sunt arătate riscuri şi măsuri de reducere a acestor

riscuri, aşa cum sunt prezentate în Tutorial on Software Risk
Management, IEEE Computer Society, 1989 de Barry Boehm.
 6. Metode de reducere a riscurilor

Utilizarea PERT pentru evaluarea efectelor incertitudinii

PERT (Program Evaluation and Review Techniques) utilizează 3
estimatori:
• Most likely time – timpul pe care-l aşteptăm pentru ca sarcina să se
desfăşoare în circumstanţe normale. Îl notăm cu m.
• Optimistic time – cel mai scurt timp în care ne aşteptăm că completăm
activitatea. Îl notăm cu a.
• Pessimistic time – cel mai prost timp pentru completarea activităţii. Îl
notăm cu b.

Timpul aşteptat (te) obţine cu relaţia:

a + 4m + b
te =
6
Exemplu. Se consideră tabelul de mai jos, cu estimările timpului
activităţilor folosind estimatorii PERT:

Reţeaua PERT prezentată pe pagina următoare ne arată că se aşteaptă

ca proiectul să dureze 13,5 săptămâni.
 T
Convenţia de notare în reţeaua PERT
te
s

Reţeaua PERT pentru activităţile prezentate în tabelul

precedent
O măsură cantitativă a gradul de incertitudine a unui estimator de timp
pentru o activitate se obţine calculând deviaţia standard s:
b−a
s=
6
Tabelul cu estimatorii PERT se completează cu deviaţia standard şi va
arăta astfel:
Avantajul tehnicii PERT este că oferă o metodă pentru estimarea
probabilităţii de a respecta sau rata datele planificate ale diverselor
sarcini.
Să presupunem că vrem să completăm proiectul în 15 săptămâni, dar ne
aşteptăm să ne ia 13,5 săptămâni. Poate lua mai mult sau mai puţin. În
plus, să presupunem că activitatea C trebuie completată până în
săptămâna a 10-a. În plus, evenimentul 5 reprezintă livrarea produsului
intermediar către client.
 Tehnica PERT foloseşte o metodă în 3 paşi pentru a calcula
probabilitatea de a respecta sau nu data ţintă:
1. • se calculează deviaţia standard pentru fiecare eveniment al proiectului;
2. • se calculează valoarea z pentru fiecare eveniment care are o dată ţintă;
3. • se converteşte valoarea z la probabilitate.

Deviaţia standard pentru evenimentul 3 depinde doar de activitatea B. De

aceea deviaţia standard va fi 0,33.
Pentru evenimentul 5 există două căi posibile, B+E sau F. Deviaţia
standard totală pentru calea B+E este

0,332 + 0,50 2 = 0,6

iar pentru F este1,17. Prin urmare, deviaţia standard pentru evenimentul
5 este 1,17 (cea mai mare dintre ele).
Calcularea valorii z
Valoarea z se calculează pentru fiecare nod care are o dată ţintă, cu
formula de mai jos, în care T este data ţintă, iar te este data aşteptată:

T − te
z=
s
Valoarea z pentru evenimentul 4 este (10-9)/0,53=1,8867.

Convertirea valorii z la probabilităţi

Se poate face folosind tabelele cu valorile lui z, care se găsesc în

majoritatea cărţilor de statistică sau cu un grafic ce reprezintă
echivalentul tabelelor.
Simularea Monte Carlo
Baza acestei tehnici este calcularea timpilor evenimentelor de un număr
mare de ori, fiecare timp selectând timpii activităţii aleator dintr-o mulţime
de estimări pentru fiecare activitate. Rezultatele sunt apoi tabulate,
sumarizate sau afişate ca grafic, aşa cum se arată în figura de mai jos.
Managementul riscului
- Laborator -
Problema 1. Se consideră tabelul de mai jos, care conţine o listă cu
riscurile identificate, împreună cu probabilitatea, impactul şi valoarea
fiecărui risc:

Cum se poate reduce probabilitatea sau impactul fiecărui risc?

Problema 2. Se consideră tabelul de mai jos, care conţine estimatorii de
timp a, m şi b pentru diversele activităţi. Calculaţi timpul aşteptat pentru
fiecare activitate, te

s=0.5
s=0.33
s=0.17

s=0.25
s=0.5

s=1.17

s=0.33
s=0.08
Problema 3. Se consideră reţeaua PERT de mai jos. Calculaţi pentru
deviaţia standard pentru fiecare dintre evenimentele A,B,C,D,E,F,G,H.

Indicaţie. Semnificaţia grafică este următoarea:

Problema 4. Se consideră reţeaua PERT de mai jos. Calculaţi valorile z
pentru fiecare dintre evenimentele cu date ţintă din reţea.
Problema 5. Se consideră graficul de mai jos, care ajută la convertirea
valorii z la probabilităţi, pentru reţeaua de activităţi de la problemele 3 sau
4. Calculaţi riscul ca proiectul să nu se termine în săptămâna a 15-a.
Calculaţi probabilitatea de a nu se realiza activităţile 4 şi 5 la sfârşitul
săptămânii a 10-a.
Indicaţii şi răspunsuri
Problema 1. Se consideră tabelul de mai jos, care conţine o listă cu riscurile
identificate, împreună cu probabilitatea, impactul şi valoarea fiecărui risc:

Indicaţie.
R2 – revizuiţi estimările sau împărţiţi activitatea în componente mai mici şi faceţi
estimări pentru acele componente.
R4 – gândiţi o strategie de rezervă pentru recrutarea persoanelor implicate în
alte proiecte, dar care pot fi în postură de stanb-by la diverse momente.
Problema 2. Se consideră tabelul de mai jos, care conţine estimatorii de timp
a, m şi b pentru diversele activităţi. Calculaţi timpul aşteptat pentru fiecare
activitate, te

Indicaţie.

4
2.83
4.08
2.83

3
2.08
Problema 3. Se consideră reţeaua PERT de mai jos. Calculaţi pentru deviaţia
standard pentru evenimentele 4 şi 6.

Indicaţie.
Evenimentul 4. Calea A+C are deviaţia standard 0,50 2 + 0,17 2 = 0,53
Calea B+D are deviaţia standard 0,332 + 0,252 = 0,41
Nodul 4 are aşadar deviaţia standard 0,53.
Problema 4. Se consideră reţeaua PERT de mai jos. Calculaţi valorile z pentru
fiecare dintre evenimentele cu date ţintă din reţea.

Indicaţie. z4=1,89
10 − 10,5 z6=1,23
Valoarea z pentru evenimentul 5 este: = −0,43
1,17
Problema 5. Se consideră graficul de mai jos, care ajută la convertirea valorii z
la probabilităţi, pentru reţeaua de activităţi de la problemele 3 sau 4. Calculaţi
riscul ca proiectul să nu se termine în săptămâna a 15-a. Calculaţi probabilitatea
de a nu se realiza activităţile 4 şi 5 la sfârşitul săptămânii a 10-a.

z5

z4=1,89
z5=-0,43
z6=1,23

z6
z4

Indicaţie. Valoarea z pentru evenimentul 4 este 1,89, care conduce la o

probabilitate de 3%. De aceea există 3% şanse ca să nu îndeplinim evenimentul
până la sfârşitul săptămânii a 10-a.
Managementul proiectelor
mici
 1. Introducere

În proiectele mici (specifice activităţii de laborator a studenţilor) apar

anumite probleme:

Folosirea instrumentelor nefamiliare

Cerinţe de design vag formulate

Dacă de exemplu proiectul de întinde pe 10 săptămâni, ar fi bine de
planificat pe o durată mai mică (9 săptămâni). Planificarea activităţilor
ar putea fi următoarea:
- săptămânile 1-2: analiza;
- săptămâna 3: designul;
- săptămânile 4-7: construirea sistemului;
- săptămânile 8-9: testarea şi evaluarea;
- săptămâna 10: săptămână de rezervă
Sisteme incomplete
Având în vedere timpul scurt, e posibil ca sistemul care trebuie
proiectat să nu fie funcţional. De aceea se recomandă ca lucrurile să
fie de aşa natură gândite, încât să existe ceva concret de arătat chiar
din fazele incipiente ale proiectului. În acest schelet al proiectului, ar fi
o idee bună să existe anumite funcţionalităţi vizibile. S pot adăuga alte
funcţionalităţi pe măsura trecerii timpului. O sugestie ar fi să folsoiţi
modelul incremental (vezi Modele de procese software), astfel încât
dacă de exemplu aveţi 3 incremente şi al treilea nu este finalizat,
există totuşi celelalte două.
Sfat: documentarea proiectului e bine să fie făcută pe măsură ce se
avansează cu etapele proiectului, mai bine decât să documentaţi
proiectul la sfârşit, din cauza lipsei de timp.

Lipsa interesului din partea clienţilor

Studentul nu va fi (probabil) plătit pentru proiectul făcut. Avantajul
acestei situaţii este că o organizaţie din afară ar putea fi interesată de
şansa de a avea o resursă free.
 2. Conţinutul unui plan de proiect

În proiectele mici e bine să urmaţi următorul plan:

A) Introducere
În introducere, e o idee bună să se explice pe scurt ce face sistemul
proiectat şi de ce. De asemenea, introducerea ar fi bine să conţină:
• identificarea clientului – pentru cine se face proiectul (inclusiv dacă e
pur didactic – cui s-ar putea adresa);
• o scurtă descriere a proiectului – cel mult câteva paragrafe;
• identificarea autorităţii de proiect – persoana sau persoanele din
cadrul organizaţiei clientului care va avea autoritate peste evoluţia
proiectului.
B) Background
Această parte ar trebui să conţină:
• informaţii relevante despre mediul software/hardware existent;
• circumstanţele sau problemele care conduc la proiect;
• munca din aria proiectului dusă deja la bun sfârşit;
• stakeholders din proiect (adică toţi cei care vor fi afectaţi de proiect
sau care sunt interesaţi de el).

C) Obiectivele proiectului
Obiectivele trebuie să definească ce ar trebui să se realizeze şi
metoda de măsurare a acestei creaţii. La proiectele studenţeşti,
evaluarea e făcută (de cele mai multe ori) din punct de vedere didactic.
Dacă însă această documentare e făcută şi în beneficiul clientului,
atunci punctul de vedere al clientului trebuie să fie prezent.
Dacă sunt multe obiective, ar trebui specificată prioritatea lor.
D) Constrângeri
De obicei se trec la partea cu obiectivele proiectului. Constrângerile
includ:
• scări de timp impuse din exterior;
• cerinţele legale;
• standarde specifice;
• limitări ale persoanelor care pot fi abordate pentru informaţii.

E) Metodele / tehnologiile folosite

Trebuie specificate instrumentele software folosite (acolo unde e
cazul).

F) Rezultatele proiectului
Trebuie listate toate rezultatele (produsele) sau elementelor cum ar fi
module software, documentaţie, ghiduri utilizator, rapoarte.
G) Activităţi
Trebuie precizată lista cu principalele activităţi pe care le implică
proiectul. Fiecare activitate trebuie precizată în termeni concreţi: de
exemplu, în loc de “familiarizarea cu procedurile departamentului-2 ar
trebui “documentarea procedurilor departamentului”. S-ar putea
descoperi rezultate intermediare ale proiectului.
Pentru fiecare activitate, se definesc:
• elementele necesare înainte de a începe activitatea;
• activităţile dependente, adică acele activităţi ce necesită terminarea
acestei activităţi curente pentru a începe;
• timpul / efortul estimat, într-o anumită marjă;
• detalii despre cum vor fi verificate şi validate produsele activităţii.
Se pot include aici şi tabelele Gantt pentru monitorizarea activităţilor
(sau alte instrumente specifice monitorizării).
H) Resurse
Se pot include aici cerinţele software / hardware şi cele legate de
personal.

I) Analiza riscului
Se identifică principalele lucruri care ar putea merge rău. În mod
normal, acestea ar putea include:
• indisponibilitatea resurselor;
• indisponibilitatea personalului;
• probleme tehnice (cum ar fi bugs-urile software).
Se aloca fiecărui risc o evaluare a probabilităţii (notă între 1-10) şi o
notă pentru impactul fiecărui risc (tot între 1-10). Înmulţind cele două
note, se obţine un scor de ansamblu.
Pentru riscurile mari, e bine să se specifice şi eventualele măsuri
pentru reducerea acelor riscuri.
 Concluzii

• atenţie la instrumentele sau tehnologiile noi;

• trebuie ajustate obiectivele proiectului, astfel încât

proiectul să nu depăşească timpul alocat;

• nu trebuie confundate obiectivele proiectului cu

obiectivele personale;

• evitaţi activităţile pentru care nu există rezultate tangibile

Monitorizarea şi controlul
 1. Introducere

Asigurarea progresului proiectului necesită monitorizarea a ceea ce se

întâmplă, compararea realizărilor concrete faţă de cele planificate şi,
acolo unde se impune, revizuirea planurilor şi replanificarea pentru a
aduce proiectului pe linia dorită.

În această prezentare, arătăm cum se pot gestiona situaţiile în care se

schimbă cerinţele.
 2. Crearea cadrului de
lucru (framework)

Figura alăturată ilustrează un model

al ciclului de control al proiectului şi
arată cum controlul proiectului e un
proces continuu de monitorizare a
planului şi eventual revizuirea
planului pentru a ţine cont de
abateri.

În practică problemele sunt:

întârziere faţă de datele planificate,
calitate îndoielnică, funcţionalitate
inadecvată şi costuri mai mari decât
cele planificate.
Responsabilitate
Răspunderea globală pentru asigurarea progresului unui proiect este
adesea rolul unui Project Board. Responsabilitatea zi-de-zi va rămâne în
grija managerului de proiect şi, în majoritatea proiectelor, se pot delega
responsabilităţi liderilor de echipă (team leaders). In figura de mai jos e
dată structura tipică de raportare.
Responsabilitate (continuare)
Raportarea poate fi orală sau scrisă, formală sau informală, regulată sau
ad-hoc. Câteva exemple sunt date în tabelul de mai jos.

Categorii de raportare

Tip de raportare Exemple Comentarii

Orală formală regulată Săptămânal sau lunar Se pot păstra anumite

notiţe formale scrise
Orală formală ad-hoc End-of-stage review Se pot primi sau
meetings genera rapoarte scrise
Scrisă formală regulată Rapoarte privind De obicei săptămânale
progresul, foi de calcul folosind formulare
Orală informală ad-hoc Rapoarte de excepţie

Orală informală ad-hoc Interacţiuni sociale Adesea oferă

avertismente timpurii
Evaluarea progresului
Se face în mod normal pe baza informaţiilor colectate la intervale
regulate sau atunci când apar evenimente specifice. Unde e posibil,
aceste informaţii vor fi obiective şi tangibile.

Taking snap-shots
Frecvenţa cu care managerul are nevoie să primească informaţii despre
progresul proiectului depinde de mărimea şi gradul de risc al proiectului.
Liderii de echipă trebuie să evalueze progresul zilnic (mai ales când
lucrează cu personal neexperimentat), în timp ce managerii de proiect
găsesc mai potrivit să primească rapoarte săptămânale sau lunare.
 3. Adunarea datelor
Ca o regulă, managerii vor încerca să împartă activităţile lungi în sarcini
mai controlabile ce se întind pe o săptămână sau două. Totuşi va fi
necesar să se adune informaţii despre activităţile parţial completate şi, în
particular, estimări despre câtă muncă mai e necesară pentru a le
completa. Uneori poate fi dificil să se facă astfel de estimări de mare
acurateţe.

Exerciţiu. Un dezvoltator de soft a scris 250 linii de cod şi estimarea este

de 500 linii. De ce nu e corect să presupunem că sarcina programării
este 50% completată. Care ar fi o estimare corectă?

Obs. În anumite cazuri, produsele intermediare pot fi folosite ca

milestones. De exemplu, prima compilare cu succes a unui program
poate fi considerată ca o milestone, deşi nu reprezintă produsul final al
activităţii de codare şi testare.
Raportarea completării
parţiale
Multe organizaţii folosesc
un sistem de măsurare
standard. Figura alăturată
înfăţişează un exemplu
tipic de un formular de
raportare, în acest caz
cerând informaţii despre
abaterea probabilă faţă
de datele de completare,
ca şi estimări ale
completării.
 4. Vizualizarea progresului
Colectarea datelor despre progresul proiectului se pot prezenta într-o
formă atractivă. În cele ce urmează, s eprezintă câteva dintre aceste
metode de prezentare.

Tabele Gantt (Henry

Gantt 1861-1919, inginer)
E o tehnică simplă şi
veche, care indică într-o
diagramă datele
activităţilor planificate.
Progresul raportat e
înregistrat pe diagramă.
Slip chart
E o alternativă folosită de unii manageri de proiect care cred că oferă o
indicaţie vizuală mai clară a acelor activităţi care nu progresează în raport
cu planificarea. O slip line cu mulţi “zimţi” indică necesitatea replanificării.

Slip line
Ball charts
În figura de mai jos, cercurile indică punctele de start şi de completare
pentru activităţi. Iniţial cercurile conţin datele planificate originale. Ori de
câte ori se produc revizuiri, acestea sunt adăugate ca date secunde în
cercul corespunzător până când o activitate e începută în realitate sau
completată când datele relevante înlocuiesc prognozele revizuite
(îngroşat înclinat în figură).

Când datele de
începere reală sau de
terminare pentru o
activitate sunt întârziate
faţă de data ţintă, cercul
e colorat roşu (gri închis
în figură), iar când data
reală e la timp sau mai
devreme decât cea
planificată cercul e
colorat în verde (gri
deschis în figură).
Timeline chart
E o metodă de a înregistra şi afişa felul în care ţintele s-au schimbat pe
întreaga durată a proiectului. În figura de mai jos se arată un timeline
chart pentru un proiect la sfârşitul celei de-a şasea săptămâni. Timpul
planificat e reprezentat pe axa orizontală şi timpul scurs pe axa verticală.
Liniile şerpuite din diagramă reprezintă datele de completare a activităţii
planificate – la începutul proiectului analyse existing system e planificat
să fie completat până marţea (Tuesday) din săptămâna a 3-a, obtain user
requirements până joia (Thursday) din săptămâna a 5-a, issue tender,
activitatea finală, până marţea din săptămâna a 9-a s.a.m.d.
La sfârşitul primei săptămâni, managerul revede aceste date ţintă şi le
lasă aşa cum sunt. La sfârşitul săptămânii a 2-a, managerul decide că
obtain user requirements nu va fi completată până marţea din săptămâna
a 6-a – de aceea managerul extinde linia activităţii diagonal ca să reflecte
aceasta. Celelalte ţinte de completare a activităţii sunt întârziate
corespunzător. În marţea din săptămâna a 3-a, e completată analyse
existing system şi managerul pune un cerculeţ pe diagonală pentru a
indica că asta s-a întâmplat. La sfârşitul săptămânii a 3-a managerul
decide să păstreze ţintele existente. La sfârşitul săptămânii a 4-a adaugă
alte trei zile pentru draft tender şi issue tender.
De observat că la sfârşitul
săptămânii a 6-a, sunt
completate 2 activităţi şi 3
sunt încă nefinalizate.
Proiectul pe ansamblu va
avea 7 zile de întârziere.
 5. Monitorizarea costurilor
O diagramă ca cea din figura de mai jos oferă o metodă simplă de
comparare a cheltuielilor planificate cu cele reale. În sine, nu indică dacă
nu cumva, deşi pare să existe economii faţă de bugetul planificat,
proiectul este mult întârziat şi de aceea graficul arată aşa.

Diagrama poate deveni mai utilă dacă se adaugă costuri viitoare

planificate, calculate prin adunarea costurilor estimate ale muncii
necompletate la costurile deja existente.
Figura de mai jos ilustrează informaţiile adiţionale disponibile în momentul
în care se include şi estimarea revizuită a costurilor.
 6. Earned Value
Earned Value Analysis a câştigat popularitate în ultimii ani şi poate fi văzută
ca o rafinare a monitorizării costurilor, discutată anterior.
Earned Value Analysis se bazează pe asignarea unei “valori” fiecărei sarcini
sau pachet de muncă (work package), bazată pe prognozele originale ale
cheltuielilor. Valoarea asignată este costul alocate original (original
budgeted cost) pentru item şi e cunoscut ca BCWS (budgeted cost of work
scheduled). O sarcină neîncepută are asignată valoarea 0 şi când e
completată, ea, precum şi proiectul, e creditat cu valoarea sarcinii. Valoarea
totală a proiectului în orice punct e cunsocută sub denumirea de earned
value sau BCWP (budgeted cost of work perfromed) şi poate fi reprezentată
ca o valoare sau ca procent al BCWS.
Când sarcinile au început dar nu sunt complete, trebuie aplicată o metodă
de asignare a earned value. Dintre aceste metode, amintim:
• tehnica 0/100 – o sarcină are asignată valoarea 0 până în momentul în
care e completată, când i se atribuie o valoare de 100% din budgeted value;
• tehnica 50/50 - o sarcină are asignată o valoare de 50% din valoarea sa
imediat ce începe şi apoi o valoare de 100% când e completă;
• tehnica milestone – o sarcină are o valoare asignată pe baza realizării
milestones care au asignat valori ca parte a planului alocat original.
Baseline budget
E bazat pe planul proiectului şi arată creşterea prognozată în timp a
earned value. Earned value poate fi măsurată în valori monetare, dar în
cazul proiectelor de dezvoltare de software e mai obişnuit să se măsoare
în ore de muncă pe persoană (person-days) sau zile de muncă
(workdays).

Exemplu. Baseline budget

e reprezentat în tabelul
alăturat şi ilustrat în
diagrama de pe pagina
următoare. Se bazează pe
zile de muncă şi foloseşte
tehnica 0/100.
Proiectul nu aşteaptă să aibă o earned value până în ziua 34.
Monitorizarea earned value
Monitorizarea earned value e o măsură a progresului proiectului. Acest
lucru e făcut prin monitorizarea completării sarcinilor. În figura de mai jos
se arată analiza earned value la începutul săptămânii a 12-a a
proiectului.
La fel de bine ca înregistrarea BCWP, costul real al fiecărei sarcini poate fi
exprimat ca ACWP (actual cost of work performed), care e arătat în figura
de mai jos.
Elementele ce apar în figura precedentă se definesc astfel:
• Budget variance: se calculează ca ACWP-BCWS şi indică gradul în
care costurile reale diferă de cele planificate;
• Schedule variance: se măsoară în termeni de cost ca BCWP-BCWS şi
indică gradul în care valoarea muncii complete diferă de cea planificată. În
figură mai e indicat şi schedule variance (time), care indică gradul în care
proiectul e în urma planificării;
• Cost variance: e calculată ca BCWP-ACWP şi indică diferenţa dintre
costul alocat şi costul real al muncii complete;
• Performance ratios: cost performance index (CPI=BCWP/ACWP) şi
schedule performance index (SPI=BCWP/BCWS). O valoare mai mare ca
1 indică faptul că munca a fost completată mai bine decât era planificată,
în timp ce o valoare mai mică decât 1 înseamnă că munca a costat mai
mult decât a fost planificat şi/sau că se merge mai încet decât a fost
planificat.
 7. Modificări în control

Până acum s-a presupus că natura sarcinilor nu s-a schimbat. În realitate

sunt situaţii când cerinţele se modifică din cauza schimbării
circumstanţelor sau pentru că utilizatorii îşi fac o idee mai clară despre
ceea ce doresc de la software.

Pe de altă parte, există situaţii interne, cum ar fi inconsistenţele în

specificaţiile programului care devin evidente numai atunci când se scrie
codul.
Rolul “Configuration librarian”
Controlul schimbărilor şi documentaţia ar trebui să fie reponsabilitatea
cuiva care se numeşte Configuration Librarian, Configuration Manager sau
Project Librarian. Printre sarcinile pe care o asemenea persoană le are:
• identificarea tuturor itemilor care ar putea fi subiectul unor schimbări;
• stabilirea şi menţinerea unui depozit central ale copiilor principale ale
întregii documentaţii a proiectului şi produselor software;
• stabilirea şi rularea unei mulţimi formale de proceduri care să se ocupe
de schimbări;
• menţinerea unor înregistrări cu cine are acces la ce itemi ai bibliotecii şi
statusul fiecărui item al bibliotecii (ex: dacă este în dezvoltare, în testare
sau livrat).
Schimbarea procedurilor de control

O procedură simplă de
control al schimbărilor
pentru sistemele
operaţionale ar putea
avea următorii paşi:
Monitorizare şi control

- Laborator -
Problema 1. Se consideră planificarea proiectului dată în figura de mai jos.
Identificaţi acele activităţi programate să dureze mai mult de 3 săptămâni şi
descrieţi cum poate monitoriza progresul pentru fiecare dintre ele.
Problema 2. În tabelul Gantt de mai jos, identificaţi activităţile întârziate. Ce
efect au acestea asupra desfăşurării proiectului? Cum poate atenua efectul
întârzierii?
Problema 3. La sfârşitul
săptămânii a 8-a,
managerul observă că
Plan office layout e
completă, dar Draft
tender (pusă în evidenţă
în figură) o să ia cu o
săptămână mai mult
decât anticipase iniţial.
Cum va arăta chart-ul la
sfârşitul săptămânii a 8-
a? Dacă proiectul va
merge conform planificării
refăcute, cum va arăta
chart-ul la sfârşitul
proiectului?
Problema 4. O schimbare în specificaţia programului se va reflecta în
schimbările făcute în designul programului şi apoi în codul schimbat.
Ce alte elemente vor trebui să sufere modificări?
Indicaţii şi rezolvări
Problema 3. La sfârşitul
săptămânii a 8-a,
managerul observă că
Plan office layout e
completă, dar Draft
tender (pusă în evidenţă
în figură) o să ia cu o
săptămână mai mult
decât anticipase iniţial.
Cum va arăta chart-ul la
sfârşitul săptămânii a 8-
a? Dacă proiectul va
merge conform planificării
refăcute, cum va arăta
chart-ul la sfârşitul
proiectului?
Problema 3. La sfârşitul
săptămânii a 8-a,
managerul observă că
Plan office layout e
completă, dar Draft
tender (pusă în evidenţă
în figură) o să ia cu o
săptămână mai mult
decât anticipase iniţial.
Cum va arăta chart-ul la
sfârşitul săptămânii a 8-
a? Dacă proiectul va
merge conform planificării
refăcute, cum va arăta
chart-ul la sfârşitul
proiectului?
Problema 4. O schimbare în specificaţia programului se va reflecta în
schimbările făcute în designul programului şi apoi în codul schimbat.
Ce alte elemente vor trebui să sufere modificări?

Indicaţie. Printre itemii cel mai probabil să sufere modificări sunt datele
de testare, rezultatele aşteptate şi manualul de utilizare.
Software design

- concepte, exemple -
 1. Introducere

Design-ul este ‘‘the process of applying various techniques and principles

for the purpose of defining a device, a process, or a system in sufficient
detail to permit its physical realization.’’ (Taylor, An Interim Report of
Engineering Design, MIT, 1959)

Procesul de design converteşte “ce” din cadrul cerinţelor în “cum” al

design-ului. Rezultatele fazei de design ar trebui să se concretizeze într-un
document ce oferă suficiente detalii care să permită sistemului să fie
implementat fără o viitoare interacţiune cu utilizatorul.

Procesul de design converteşte de asemenea terminologia din spaţiul

problemei al cerinţelor la spaţiul soluţie al implementării. Unii autori
vorbesc de obiectele OOA (Object-Oriented Analysis), care sunt în spaţiul
problemă/domeniu şi de obiectele OOD (Object-Oriented Design), care
sunt în spaţiul soluţie/implementare.
Se vorbeşte despre fenomenon în mediul înconjurător (lumea) şi de
fenomenon în implementare (maşină). Un fenomenon poate fi vizibil sau
ascuns. Cerinţele orientate pe utilizator pot fi exprimate în termeni de
fenomenon, vizibil sau ascuns, din mediu (environment). (Gunter, Gunter,
Jackson, and Zave, ‘‘A Reference Model for Requirements and Specifications’’,
IEEE Software, May/June 2000)

Exemplu. Identificaţi ce fenomenon este în mediu şi ce fenomenon în

implementare în sistemul care gestionează împrumutul de cărţi într-o
bibliotecă. (vezi model_biblioteca)
Soluţie. Cartea propriu-zisă este un fenomenon ascuns al mediului
(environment-hidden). Când bibliotecarul scanează cartea, scanează de fapt un
cod de bare. Codul de bare nu conţine ISBN-ul, dar trebuie să reflecte
eventualele copii multiple ale unei singure cărţi. Acest code de bare este un
fenomenon vizibil al mediului. Implementarea foloseşte probabil un identificator
sau pointer pentru datele referitoare la carte. Acest identificator intern este un
fenomenon ascuns al implementării. Specificarea pentru dezvoltare trebuie să fie
scrisă în termeni de cod de bare.
 2. Fazele procesului de design

Data design (designul de date) — această fază produce the structurile de

date.
Architectural design (designul arhitecturii) — această fază produce the
unităţile structurale (clasele).
Interface design (designul interfeţelor) — această fază specifică interfeţele
dintre unităţi.
Procedural design (designul procedural) — această fază specifică algoritmii
fiecărei metode.
Exemplu. Realizaţi designul claselor şi al structurilor de date pentru
sistemul de gestiune a împrumutului de cărţi dintr-o bibliotecă.
Soluţie. Atenţia este concentrată pe împrumutul cărţilor şi mai puţin pe alte
informaţii, cum ar fi catalogarea, administrarea, retragerea cărţilor şi administrarea
clienţilor bibliotecii. Identitatea “carte” se va combina cu identitatea “copie” în
structura de clase/date pentru stocarea informaţiilor despre o copie. Poate conţine
ISBN-ul şi un număr de copie ca unic identificator. Informaţiile despre cititori se vor
păstra într-o structură de date secundară, în care probabil fiecare înregistrare va fi
identificată printr-un ID unic (poate fi CNP-ul). Informaţiile referitoare la împrumut
pot fi puse într-o structură de date separată sau nu.
Diagrama de clasă
 2.1 Interfeţele
Interfaţa arată comportarea exterioară a unui modul. Trebuie să fie suficient
de completă pentru ca modulul apelant să ştie ce va face modulul apelat în
orice situaţie. Trebuie să fie completă pentru ca cel care implementează să
ştie exact ce informaţii sunt necesare.
Exemplu. Realizaţi designul interfeţelor pentru functiile imprumutare din
diagrama de clase de mai sus.
Soluţie. Clasele cititor şi copiecarte au o metodă imprumutare. Este de presupus
că apelul oricăreia dintre aceste metode va instanţia clasa imprumut.
method cititor::imprumutare
input parameters – isbn
return type – int
0 dacă nu este disponibilă cartea
1 dacă este disponibilă cartea şi instanţa imprumut se creează cu succes
-1 dacă apare o condiţie de eroare

method copiecarte::imprumutare
input parameter – NrImprumut
return type – int
0 dacă nu e disponibilă copia
1 dacă e disponibilă copia
 3. Concepte ale designului

Refinement (rafinare) — dezvoltă designul prin rafinări succesive; se mai

numeşte designul “top-down”.
Modularity (modularitate) — e o abordare care divide software-ul în
componente mai mici, care apoi sunt integrate.

Exemplu. Rafinaţi funcţia imprumutare din sistemul de împrumutare cărţi

de la o bibliotecă, prezentat în exemplele anterioare.

Soluţie. Pe primul nivel de design, începem printr-o funcţie imprumutare care are
doi parametri: titlul cărţii şi numele cititorului.

La următorul nivel, se adaugă noţiunea de entitate împrumut, care (probabil) are

două părţi: caută cartea cu titlul specificat, caută cititorul cu numele dat şi creează
o instanţă de împrumut pe baza ID-urilor cărţii şi cititorului.

Următoarea rafinare expandează fiecare parte de mai sus. gasesteCarte

returnează ISBN dacă e găsită şi e disponibilă cartea, returnează 0 dacă nu e
găsită şi returnează -1 dacă acea carte e dată. găsesteCititor returnează IDcititor
dacă cititorul e găsit, 0 dacă cititorul nu e găsit şi -1 dacă cititorul nu poate
împrumuta cartea. creeazaImprumut returnează 1 dacă e creată cu succes.
 3.1 Atribute ale designului

Abstraction (abstractizare) — un obiect e abstract dacă detaliile

nenecesare sunt ascunse.
Cohesion (coeziune) — o procedură e coezivă dacă toate declaraţiile sale
sunt legate de fiecare dintre output-urile sale. O clasă e coezivă dacă toate
atributele din clasă sunt utilizate de fiecare metodă. Cu alte cuvinte,
coeziunea într-un modul se atinge atunci când toate elementele sale sunt
în legură unele cu altele.
Coupling (cuplare) — e o măsură a cât de interconectate sunt modulele
între ele. Două module sunt cuplate dacă modificarea unei variabile într-
unul dintre module necesită schimbări în celălalt modul. E de dorit o
cuplare slabă între module.

Exemplu. Evaluaţi abstractizarea în funcţionalitatea împrumutului din

sistemul de gestionare a împrumuturilor de cărţi dintr-o bibliotecă.
Soluţie. Funcţia imprumutare apare în 3 module: bibliotecă, cititor şi copiecarte.
Cea mai bună abstractizare se atinge atunci când funcţia imprumutare din modulul
biblioteca cunoaşte cât mai puţine detallii cu putinţă despre funcţiile imprumutare
din clasele cititor şi copiecarte.
Aşa cum se arată în figura de mai sus, dacă funcţia imprumutare din modulul
biblioteca doar apelează funcţia imprumutare, atunci există o bună abstractizare.

Dacă funcţia imprumutare din modulul biblioteca ştie despre clasa imprumut, poate
verifica disponibilitatea cărţii, poate crea instanţa imprumut şi poate apela funcţiile
imprumutare pentru a seta valorile instanţei imprumut.
Aşa cum se arată în figura de mai sus, abstractizarea nu e bună. De ce?
 4. Măsurarea coeziunii
4.1 “Feliile” unui program (program slices)
Valorile unei variabile într-un program depind de valorile altor variabile.

Există două tipuri de dependenţe:

• data dependencies, în care valoarea lui x afectează valoarea lui y prin
definiţie;
• control dependencies, în care valoarea lui x determină dacă se execută
codul care conţine definiţiile lui y.

Exemplu. Înmulţirea prin însumare repetată: Să se calculeze x*y.

Valoarea de ieşire z are data dependency faţă de x, deoarece x se adună
la z şi are control dependency faţă de y, deoarece controlează de câte ori
de adună x la z.

z = 0;
while x > 0 do
z = z + y;
x = x –1;
end-while
Program slices pot fi obţinute din ambele direcţii. Output slices găsesc
fiecare instrucţiune care afectează valoarea unei ieşiri (output) specificate.
Input slices găsesc fiecare instrucţiune care e afectată de valoarea unui
input specificat.

Sunt uşor de determinat program slices, pornind de la un graf orientat, în

care are o mulţime de vârfuri n, fiecare vârf reprezentând un input, un
output sau o instrucţiune de cod. Arcurile e sunt dependenţele.

James Bieman şi Linda Ott au utilizat definiţii de variabile şi referinţe ca

unităţi de bază, în loc de instrucţiuni de program (program statements).
Aceste definiţii şi referinţe se numesc tokens. De aceea, orice referinţă de
constantă (constant reference), referinţă de variabilă (variable reference) şi
definiţie de variabilă reprezintă un token separat (James Bieman, Linda Ott,
‘‘Measuring Functional Cohesion,’’ IEEE TOSE, 20:8 August 1994)
Exemplu. Desenaţi un graf orientat pentru codul din exemplul precedent:
z = 0; while x > 0 do z = z + y; x = x –1;end-while

Soluţie. Vom folosi linie continuă pentru data dependencies şi linie punctată pentru
control dependencies.

Un input slice poate începe cu variabila de intrare x. Tokens x, 0, x, x, şi 1 din

instrucţiunile while x>0 şi x=x-1 se adaugă la slice. Apoi se adaugă tokens z, z şi y
din instrucţiunea z=z+y. Nici un alt token nu mai poate fi adăugat. De aceea, input
slice e tot mai puţin z=0.

Un input slice pentru variabila y va conţine tokenul iniţial y şi tokens z şi y din

instrucţiunea z=z+y.
4.2 Glue tokens

Bieman şi Ott au definit, de asemenea, anumite metrici de coeziune

utilizând output slices. Definiţiile sunt bazate pe glue tokens, care sunt
tokens (sectiună de cod) care se găsesc în mai mult de un slice şi
superglue tokens, care sunt în toate slices. Adezivitatea (adhesiveness)
unui token e procentul de output slices într-o procedură ce conţine token.

Există trei functional cohesion measures:

• Weak functional cohesion (WFC)—raportul glue tokens la total tokens
• Strong functional cohesion (SFC)—raportul superglue tokens la total
tokens
• Adhesiveness (A)—media adezivităţii tuturor tokens
Exemplu. Calculaţi functional cohesion measures pentru următorul fragment
de cod.

cin >> a >> b;

int x,y,z;
x=0; y=1; z=1;
if (a > b){
x = a*b;
while (10 > a){
y=y+z;
a=a+5;
}
else {
x=x+b;
}

Soluţie. În figura de pe pagina următoare din fiecare token către toate tokens care
sunt afectate imediat de valoarea token-ului.
Graf orientat arătând toate dependenţele
Nu sunt superglue tokens, aşadar strong functional cohesion (SFC) este
zero. Din cei 31 tokens, sunt 12 glue tokens, deci weak functional
cohesion este 12/31 sau 0.387.

Sunt patru slices. Zero tokens au adezivitate 100%. Patru tokens sunt în
trei slices, aşa încât au adezivitate 100%. Opt tokens sunt în două slices,
aşa încât au adezivitate 50%. Tokens rămaşi, 19, sunt doar într-un slice,
aşa încât au adezivitate 25%.

Adezivitatea este media adezivităţii tuturor tokens, deci

(4*0,75+8*0,50+19*0,25)/31=11,25/31=0,363
 5. Măsurarea cuplării (coupling)
Dharma (H. Dharma, ‘‘Quantitative Models of Cohesion and Coupling in
Software,’’ Journal of Systems and Software, 29:4, April 1995.) a propus o
metrică cu următoarea listă de situaţii pentru numărare:
di = Numărul de parametri de date de intrare
ci = Numărul de parametri de control de intrare
do = Numărul de parametri de date de ieşire (output data parameters)
co = Numărul de parametri de control de ieşire (output control
parameters)
gd = Numărul de variabile globale folosite ca date
gc = Numărul de variabile globale folsoite ca control
w = Numărul de module apelate (fan-out)
r = Numărul de module apelante a modului fan-in)

Indicatorul de cuplare a modulelor (module coupling indicator) a lui

Dharma se defineşte astfel:
 6. Requirements traceability (gradul de urmărire a
cerinţelor)
Requirements traceability încearcă să lege fiecare cerinţă (requirement) de
un element de design care să satisfacă cerinţa. Cerinţele trebuie să
influenţeze designul. Dacă o cerinţă nu are o parte corespondentă a
designului sau o parte a designului nu are o parte corespondentă în cerinţe,
există o potenţială problemă. Evident, anumite părţi de design pot fi atât de
generale, încât nici o parte a cerinţelor nu se reflectă în acea secţiune.
Unele cerinţe, pe de altă parte, s-ar putea să nu aibă părţi specifice în
design care să oglindească aceste cerinţe.

O abordare pentru determinarea gradului de urmărire a cerinţelor

(traceability) este să desenăm o matrice. Pe o axă sunt listate toţi itemii
despre cerinţe, iar pe cealaltă va fi lista cu itemii legaţi de design. Un semn
va fi plasat acolo unde un item de design îndeplineşte o cerinţă.
Exemplu. Desenaţi o matrice pentru următoarea problemă: Tom şi Sue
pregătesc o pensiune într-un oraş. [1] Ei vor avea 3 dormitoare pentru
oaspeţi. [2] Vor un sistem care să gestioneze [2.1] rezervările şi să
monitorizeze [2.2] cheltuielile şi profitul. Când un client potenţial sună pentru
rezervare [3], ei verifică [4] calendarul şi dacă sunt locuri libere [5], vor
introduce [6.1] numele clientului, [6.2] adresa, [6.3] telefonul, [6.4] datele,
[6.4] preţul negociat, [6.6] nr.credit card şi [6.7] nr.camerei. Rezervarea
trebuie [7] garantată prin plata [7.1] primei zile. Rezervările vor fi ţinute fără
garanţie [7.2] o perioadă stabilită. Dacă nu se oferă garanţia până la acea
zi, rezervarea va fi [7.3] anulată.
Aşa cum se arată în tabelele anterioare, există un număr de linii şi coloane
albe. Cerinţa 5 se leagă de locuri libere. Nu există o tratare explicită a
locurilor libere, deşi un loc liber ar trebui să fie absenţa unei rezervări într-o
zi anume. Cerinţa 6.3 se referă la telefonul clientului şi lipseşte. Cerinţa 6.5,
legată de preţul negociat şi lipseşte din informaţiile privind rezervarea.
Cerinţa 7.1 menţionează prima zi de plată, care de asemenea nu este
printre atribute.

Coloana A.1 e o listă a datelor, care e inclusă pentru a a juta căutarea

locurilor libere. B şi B.1 sunt necesare, dar nu sunt specifice pentru vreo
cerinţă. C.8 e un constructor. D.1-D.4 sunt detalii ale tranzacţiei, care sunt
neglijate la cerinţe.
Exemplu. Construiţi un model pentru o bibliotecă.
Soluţie. Obiectele sunt biblioteca, cărţi, copii ale cărţilor şi cititori. Între
biblioteca şi carte, ca şi între bibliotecă şi cititor există o relaţie de agregare.
Între carte şi copiecarte nu e nici agregare, nici moştenire, deoarece obiectul
carte reprezintă abstracţia unei cărţi, în timp de copiecarte este itemul concre
(fizic) care se împrumută.

inapoi
Software design

- laborator -
Exerciţiul 1. Se dă următorul design. Analizaţi cuplarea, coeziunea,
abstractizarea.
Exerciţiul 2. Se consideră un sistem de recunoaştere facială bazată pe
procesare de imagini. Sistemul va avea o cameră şi intenţionează să
prevină persoanele străine să intre în zonele secrete ale companiei,
prin controlul uşii (blocarea ei). Când o persoană încearcă să
răsucească mânerul uşii, sistemul preia imaginea persoanei şi o
compară cu imaginile din baza de date.
Clasificaţi fiecare dintre următoarele evenimente (i.e. dacă sunt în mediu –
environment sau în sistem şi dacă sunt ascunse sau vizibile:
1. O persoană încearcă să răsucească mânerul uşii.
2. Uşa e deblocată de sistem.
3. Un angajat lasă un străin pe uşă.
4. Un anagajat are un geamăn identic.
5. O imagine are un număr minim de similarităţi pentru algoritmul de
potrivire (matching algorithm).
Exerciţiul 3. Calculaţi functional cohesion metrics (Bieman, Ott) pentru
fragmentul de cod de mai jos. Desenaţi graful orientat.
Exerciţiul 4. Desenaţi scenariile pentru interacţiunea dintre un client care
încearcă să cumpere un anumit CD cu muzică şi vânzătorul din magazin.
Folosiţi state machine model. Pe arce să fie reprezentate evenimentele.

Indicaţie. Mai jos e prezentată cea mai simplă situaţie, când vânzătorul
intră în magazin, nu găseşte CD şi pleacă din magazin. Completaţi şi
variantele celelalte.

Completaţi...
Indicaţii şi soluţii
Soluţie exerciţiul 1.
Cuplare – se doreşte cuplare slabă şi acest design are cuplare slabă,
deoarece clasa college nu are cunoştinţe despre alcătuirea altor clase şi
alte clase nu trebuie să ştie despre college.
Coeziune – e de dorit o coeziune mare şi designul are coeziune mare,
deoarece fiecare clasă lucrează cu propriile atribute.
Abstractizare – designul are o bună abstractizare. De exemplu, metoda
display din college nu include detalii despre metodele lower-level de
afişare.
Soluţie exerciţiul 2.

1. O persoană încearcă să răsucească mânerul uşii. - EV

2. Uşa e deblocată de sistem. - SV
3. Un angajat lasă un străin pe uşă. - EH
4. Un anagajat are un geamăn identic. - EH
5. O imagine are un număr minim de similarităţi pentru algoritmul de
potrivire (matching algorithm). – SH
Soluţie exerciţiul 3.
Soluţie exerciţiul 3 (continuare).
Soluţie exerciţiul 3 (continuare).
Sunt 33 tokens. Patru sunt superglue. Şase (incluzând tokens
superglue) sunt glue tokens.
WKC=6/33=18.2%
SFC=4/33=12.1%
Adezivitate este (4*1+2*0.75+27*0.25)/33=12.25/33=37.1%
Soluţie exerciţiul 4.
Testarea software-ului
 1. Introducere

Testarea software-ului se face rulând software-ul cu date de test. Se

mai numeşte testare dinamică a software-ului (dynamic software
testing), pentru a se deosebi de analiza statică (static analysis), numită
uneori şi testare statică, care presupune analizarea codului sursă
pentru identificarea problemelor.

Deşi există diverse tehnici pentru validarea software-ului, executarea

datelor cu date de test reprezintă un pas necesar.
 2. Noţiuni fundamentale
Testarea exhaustivă este executarea fiecărui caz de test posibil, dar se
face rar, pentru că şi la sistemele simple există foarte multe cazuri de
testare posibile (Exemplu: un program cu 2 intrări de tip întreg pe 32
biţi conduc la un număr de 264cazuri de testare posibile).

Există două criterii de bază privind testarea software:

1. ce cazuri de testare să folosim (test case selection)
2. câte cazuri de testare sunt necesare (stopping criterion)

Test case selection se poate baza pe:

• specificaţii (functional);
• structura codului (structural);
• fluxul datelor (data flow);
• o selecţie aleatoare a cazurilor de testare (random).

Obs. Test case selection poate fi văzută ca o încercare de dimensionare

a cazurilor de testare prin intermediul intrărilor.
Stopping criterion se poate baza pe:
• criteriu de acoperire (coverage criterion), cum ar fi executarea a n
cazuri de testare în fiecare subdomeniu;
• criterii comportamentale (behavior criteria), cum ar fi testarea până o
rată a erorilor e mai mică decât un prag impus.

Un program poate fi gândit ca o mapare a spaţiului domeniu la un

spaţiu al răspunsurilor. Dându-se o intrare (input), care e un punct în
spaţiul domeniu, programul produce o ieşire (output), care e un punct
în spaţiul răspunsurilor.

Un caz de testare trebuie să includă totdeauna ieşirea aşteptată

(expected output).
 3. Test coverage criterion
Test coverage criterion e o regulă despre cum să selectăm cazuri de
testare şi când să ne oprim. Abordarea standard o constituie folosirea
relaţiei subsumes.

3.1 Subsumes (includeri)

Un criteriu de testare A subsumează criteriul de acoperire a testării B
dacă orice test care satisface criteriul A satisface de asemenea criteriul
B. Asta înseamnă că criteriul de acoperire a testării A include într-un fel
criteriul B.
Exemplu. Dacă un criteriu de acoperire a testării necesită ca fiecare
instrucţiune să fie executată şi alt criteriu de acoperire a testării
necesită ca fiecare instrucţiune să fie executată plus alte teste
adiţionale, atunci al doilea criteriu subsumează primul criteriu.
Obs. O mulţime bine aleasă de cazuri de testare ce satisfac un criteriu
“mai slab” poate fi mult mai bun decât o mulţime aleasă mai rău care să
satisfacă un criteriu “mai puternic”.
3.2 Testare funcţională (functional testing)

Unul din primii paşi este generarea unui caz de testare pentru fiecare
tip distinct de ieşire a programului. De exemplu, fiecare mesaj de
eroare trebuie generat. Apoi fiecare caz special ar trebui să aibă un caz
de test. Situaţiile ce ne pot induce în eroare (tricky situations) ar trebuie
testate. Greşelile comune ar trebui testate.

Exemplu. Unul dintre exemplele clasice este următorul: pentru trei

numere date la intrare, verificaţi dacă aceste numere pot reprezenta
laturile unui triunghi şi în caz afirmativ precizaţi natura triunghiului.

Soluţie. Împărţim spaţiul domeniu în 3 subdomenii, unul pentru fiecare

tip de triunghi: oarecare (scalen), isoscel (2 laturi egale) şi echilateral
(toate laturile egale). Identificăm două situaţii de eroare: un
subdomeniu cu intrări greşite şi un subdomeniu în care laturile nu pot
forma un triunghi. Fiecare caz de testare trebuie să specifice valoarea
output-ului.
Subdomeniu Caz de test

Oarecare:
Mărimi crescătoare (3,4,5 – oarecare)

Mărimi descrescătoare (5,4,3 – oarecare)

Cea mai mare a doua (4,5,3 – oarecare)

Isoscel:
a=b şi c mai mare (5,5,8 – isoscel)
a=c şi b mai mare (5,8,5 – isoscel)
b=c şi a mai mare (8,5,5 – isoscel)
a=b şi c mai mică (8,8,5 – isoscel)
a=c şi b mai mică (8,5,8 – isoscel)
b=c şi a mai mică (5,8,8 – isoscel)
Echilateral:
a=b=c (5,5,5 – echilateral)

Nu e triunghi:
a cea mai mare (6,4,2 – nu e triunghi)
b cea mai mare (4,6,2 – nu e triunghi)
c cea mai mare (1,2,3 – nu e triunghi)

Intrări greşite:
1 greşită (-1,2,4 – date greşite)
2 greşite (3,-2,-5 – date greşite)
3 greşite (0,0,0 – date greşite)

Obs. Lista subdomeniilor poate fi extinsă. Un caz de testare în fiecare

subdomeniu e soluţia minimală, dar acceptabilă.
3.3 Matrici de testare
O metodă de formalizare a identificării subdomeniilor este construirea
unei matrici folosind condiţiile pe care le identificăm din specificaţie şi
apoi să identificăm toate combinaţiile acestor condiţii ca fiind adevărate
sau false. Se vor folosi toate combinaţiile valide de T şi F. Dacă sunt 3
condiţii, vor fi 23=8 subdomenii (coloane). Liniile vor fi folosite pentru
valorile lui a, b şi c şi pentru ieşirile prognozate (expected output)
pentru fiecare subdomeniu.

Exemplu. Condiţiile din problema triunghiului pot fi : (1) a=b sau a=c
sau b=c, (2) a=b şi b=c, (3) a<b+c şi b<a+c şi c<a+b, (4) a>0 şi b>0 şi
c>0. Coloanele matricii vor reprezenta un subdomeniu. Pentru fiecare
subdomeniu, vom plasa un T în fiecare rând în care condiţia e
adevărată şi F când condiţia e falsă.
3.4 Testare structurală
Testarea structurală se bazează pe structura codului. Cel mai simplu
criteriu este every statement coverage, cunoscut drept C0 coverage.

3.4.1 C0 coverage
Acest criteriu presuppune că fiecare instrucţiune a codului ar trebui
executată se un caz de testare. Abordarea normală pentru obţinerea
C0 coverage este selectarea cazurilor de testare până când un
instrument de acoperire (coverage tool) indică faptul că toate
instrucţiunile din cod au fost executate.

Exemplu. Următorul pseudocod implementează problema triunghiului.

Matricea arată ce linii sunt executate în fiecare caz de test. Primele trei
instrucţiuni (A, B şi C) pot fi considerate părţi ale aceluiaşi nod.
3.4.2 Testarea C1-Every-Branch
Pentru modelarea programului cu triunghiul folosind un control flow
graph, acest criteriu necesită acoperirea fiecărui arc din digramă.
3.4.3 Testarea Every-Path

O cale (path) e o secvenţă unică a nodurilor programului care sunt

executate de un caz de testare. În matricea de testare (exemplul de
mai sus), erau 8 subdomenii. Fiecare dintre ele se întâmplă să fie o
cale. În acel exemplu, există 16 combinaţii diferite de T şi F. Totuşi, 8
dintre aceste combinaţii sunt căi nerealizabile (infeasible paths), adică
nu există combinaţii de T şi F pentru deciziile din program. Poate fi
extrem de dificil să determinăm dacă calea e nerealizabilă, precum şi
să găsim un caz de testare care execută acea cale.
Multe programe cu bucle vor avea un număr infinit de căi. În general,
testarea every-path nu e rezonabilă.
3.4.4 Multiple-Condition Coverage

Acest criteriu de testare necesită ca fiecare condiţie de relaţie primitivă

(primitive relation condition) să fie evaluată true şi false. În plus, trebuie
încercate toate combinaţiile de T/F pentru relaţiile primitive într-o
condiţie. E de notat că evaluarea lazy a unei expresii (un compilator e
lazy dacă, de exemplu, într-o expresie cu or prima relaţie e true, a doua
nu mai e testată) va elimina anumite combinaţii. De exemplu, într-un
and dintre două relaţii primitive, a doua nu va mai fi evaluată dacă
prima e falsă.

Exemplu. În pseudocodul din exemplul de la C0, sunt mai multe

condiţii multiple. Primitivele care nu se execută din cauza evaluării lazy
sunt marcate mai jos cu un “X”.
3.4.5 Subdomain testing (testarea de subdomeniu)
Se bazează pe idee partiţionării domeniul de intrare (input domain) în
subdomenii ce sunt mutual excluse şi impunerea unui număr de cazuri
de testare egal din fiecare subdomeniu. O idee similară se întâlnea în
cazul matricii de testare. În acest caz însă nu se restricţionează modul
în care sunt selectate domeniile.

Every-statement coverage şi every-branch coverage nu sunt

subdomain tests. Nu sunt subdomenii mutual excluse în ceea ce
priveşte executarea diferitelor instrucţiuni sau ramuri. Every-path
coverage este un subdomain coverage.

Exemplu. Pentru problema triunghiului, putem începe cu un

subdomeniu pentru fiecare ieşire. Acestea se pot subdiviza ulterior în
noi subdomenii, în funcţie de faptul dacă cel mai mare sau elementul
greşit introdus este în prima poziţie, a doua poziţie sau a treia poziţie.
3.4.6 C1 subsumează C0
Exemplu. Pentru problema triunghiului, am selectat cazurile de testtare
bune pentru a obţine C0 coverage. Cazurile erau:
(3,4,5 – oarecare),
(3,5,3 – isoscel),
(0,1,0 – intrări greşite),
(4,4,4 – echilateral)
Aceste teste acopereau 4 din 5 ieşiri.

Putem obţine C1 coverage cu două cazuri de testare:

(3,4,5 – oarecare) şi
(0,0,0 – intrări greşite).

Testul nu este probabil la fel de bun ca primul. Dar obţinem astfel atât
C1 coverage, cât şi C0 coverage.
 4. Data flow testing
Este testarea bazată pe fluxul datelor (data flow) într-un program.
Datele curg din locul unde sunt definite până în locul unde sunt folosite.

O definiţie de date (sau def.) este atunci când o valoare e asignată

unei variabile.

Computation use (sau c-use) este atunci când o variabilă apare în

membrul drept al unei instrucţiuni de atribuire. c-use se spune că apare
într-o instrucţiune de atribuire.

Predicate use (sau p-use) este atunci variabila este utilizată în

condiţia unei instrucţiuni de decizie. p-use e asignată ambelor ramuri
ale instrucţiunii de decizie.

Definition free path (sau def-free) e o cale de la definiţia unei

variabile la folosirea acelei variabile care nu include altă definiţie a
variabilei.
Exemplu. Pentru problema triunghiului, reprezentăm control flow
graph.
Sunt multe criterii de testare a fluxului datelor.
Criteriile de bază includ dcu, care necesită o def-free de la fiecare
definiţie până la c-use; dpu, care necesită o def-free de la fiecare
definiţie până la p-use; du, care necesită o def-free de la fiecare
definiţie la orice folosire posibilă. Cele mai extinse criterii sunt all-du-
paths, care necesită toate def-free paths de la fiecare definiţie la
fiecare folosire posibilă.
Exemplu. Data flow testing pentru problema triunghiului.
dcu – singura c-use este pentru variabila din nodul k (instrucţiunea de
ieşire)
de la def type în nodul abc la nodul k calea abc,e,g,i,k
de la def type în nodul d la nodul k calea d,e,g,i,k
de la def type în nodul f la nodul k calea f,g,i,k
de la def type în nodul h la nodul k calea h,i,k
de la def type în nodul j la nodul k calea j,k
Exemplu (continuare)
dpu – singura p-use este pentru variabilele a,b,c şi singura def este
nodul abc
de la nodul abc la arcul abc-d
de la nodul abc la arcul abc-e
de la nodul abc la arcul e-f
de la nodul abc la arcul e-g
de la nodul abc la arcul g-h
de la nodul abc la arcul g-i
de la nodul abc la arcul i-j
de la nodul abc la arcul i-k

du – toate defs la toate folosirile

toate cazurile de testare ale dcu şi dpu combinate.

all-du-paths – toate def-free paths de la toate defs la toate folosirile.

toate cazurile de testare ale dcu şi dpu combinate.
 5. Testarea aleatoare (random testing)
Se realizează prin selectarea aleatoare a cazurilor de testare. Are
avantajul că este rapidă. În plus, inferenţa statistică e mai uşoară când
testele sunt selectate aleator.

Exemplu. Pentru problema triunghiului, putem folosi un generator de

numere aleatoare şi să grupăm fiecare mulţime de trei numere ca o
mulţime de testare. Va trebui să determinăm în plus expected output. O
problemă ar putea fi faptul că probabilitatea să generăm un caz de
testare a echilateralităţii e foarte mică.

5.1 Profilul operaţional (operational profile)

Testarea în mediul de dezvoltare (development environment) e adesea
diferită de executarea în mediul operaţional (operational environment).
O cale de a le face pe acestea similare ar fi să avem o specificare a
tipurilor şi probabilităţile ca aceste tipuri să se întâlnească în operaţiile
normale. Această specificare se numeşte operational profile.
Prin desenarea cazurilor de testare ale profilului operaţional, cel care
face testul va avea mai multă încredere că acea comportare a
programului în timpul testării e mai predictivă despre cum se va
comporta în timpul funcţionării.

Exemplu. Un posibil profil operaţional pentru problema triunghiului:

Pentru aplicarea testării aleatoare, se poate genera un număr pentru
selectarea categoriei după probabilităţi şi apoi generarea unor numere
suficiente pentru a crea cazul de testare. Dacă cumva categoria
selectată a fost cazul echilateral, se va folosi acelaşi număr pentru
toate cele trei intrări. Un isoscel drept va necesita un număr aleator
pentru lungimea a două laturi şi apoi se poate calcula cealaltă latură.

5.2 Inferenţă statistică la testare

Dacă testarea aleatoare a fost făcută prin selectarea aleatorie a
cazurilor de testare dintr-un profil operaţional, atunci comportarea
software-ului în timpul testării ar trebui să fie aceeaşi cu comportarea
sa în mediul operaţional.

Exemplu. Dacă selectăm 1000 cazuri de testare aleator, folosind

profilul operaţional şi găsind 3 erori, putem prezice că software-ul va
avea o rată a erorilor mai mică de 3 defecţiuni (failures) la 1000 de
execuţii în mediul operaţional.
 5. Boundary testing (testarea de frontieră)

De multe ori erorile apar la frontierele dintre domenii. În cod,

instrucţiunile condiţionale determină frontierele domeniilor. Dacă avem
o condiţie x<=1, atunci frontiera x=1 este în domeniul true. În termeni
de boundary testing, spunem că on tests sunt în domeniul true şi off
tests sunt valori ale lui x mai mari decât 1 şi sunt în domeniul fals. Dacă
o condiţie e scrisă x<1 în loc de x<=1, aunci frontiera x=1 este acum în
domeniul fals.

Boundary testing e făcută cu scopul de a ne asigura că frontiera

adevărată, reală (actual) dintre domenii e apropiată pe cât se poate de
frontiera specificată. De aceea, cazurile de testare sunt selectate pe
frontieră şi în afara frontierei, cât mai apropiat cu putinţă de frontieră.
Testul de frontiera standard constă în efectuarea a două on tests cât
mai departe posibil pe frontieră şi un off test aproape de mijlocul
frontierei.
Figura de mai jos arată o frontieră simplă. Săgeata indică faptul că on
tests ale frontierei sunt în subdomeniul de sub frontieră. Cele două on
tests sunt la capătul frontierei şi off test-ul chiar deasupra jumătăţii.
Exemplu. În exemplul cu triunghiul, condiţiile primitive, a>=b+c or
b>=a+c or c>=a+b, determină o frontieră. Deoarece depinde de trei
variabile, frontiera e un plan în spaţiul 3D. On testele ar trebui să fie 2
(sau mai multe) teste separate care au egalitate (de exemplu 8,1,7 şi
8,7,1). Acestea sunt amândouă adevărate. Off testul va fi în domeniul
false şi va fi aproape de mijloc (de exemplu 7.9,4,4).
Testarea software

- Laborator -
 A. Întrebări

1. De ce e nevoie de specificare pentru a face testarea?

2. De ce path testing este de obicei impracticabilă?
3. De ce e important testing coverage criterion?
 B. Probleme
1. Un program calculează aria unui triunghi. Intrările sunt 3
mulţimi de coordonate x,y. Construiţi testele funcţionale.
2. Un program acceptă doi timpi (în format de 12 ore) şi
ieşirile reprezintă numărul de minute scurse între cei doi
timpi. Construiţi testele funcţionale.
3. Un subprogram de căutare binară caută lista numelor în
ordine alfabetică şi returnează true dacă numele e în listă
şi fals în caz contrar. Construiţi testele funcţionale.
 C. Problemă propusă
1. Pentru următorul cod, identificaţi toate căile posibile, path tests şi
data flow tests:
 A1. Răspunsuri la Întrebări
1. De ce e nevoie de specificare pentru a face testarea?
R: O specificare e necesară pentru a şti dacă
comportarea concretă (actual behavior) e corectă sau nu.
2. De ce path testing este de obicei impracticabilă?
R: Pentru că într-un program pot exista un număr uriaş
de căi posibile.
3. De ce e important testing coverage criterion?
R: Pentru că acest criteriu forţează pe cel care face
testele să testeze diversele părţi ale software-ului.
 B1. Răspunsuri la Probleme
1. Un program calculează aria unui triunghi. Intrările sunt 3
mulţimi de coordonate x,y. Construiţi testele funcţionale.
R: Testele funcţionale ar trebui să includă triunghiurile corecte, non-
triunghiurile, condiţii de eroare etc.
2. Un program acceptă doi timpi (în format de 12 ore) şi
ieşirile reprezintă numărul de minute scurse între cei doi
timpi. Construiţi testele funcţionale.
R: Testele funcţionale ar trebui să includă teste mai mici de 1 oră,
mai mare de 1 oră, unul mai mare de 12 ore, unul care necesită
transport de ore şi unul cu timpii daţi în ordine inversă.
3. Un subprogram de căutare binară caută lista numelor în
ordine alfabetică şi returnează true dacă numele e în listă
şi fals în caz contrar. Construiţi testele funcţionale.
R: Testele funcţionale ar trebui să includă următoarele teste:
- Primul nume e în listă
- Ultimul nume e în listă
- Un nume dinaintea primului nume
- Un nume după ultimul nume
- Un nume la mijloc
- Un nume care nu e în listă chiar după primul nume
- Un nume care nu e în listă chiar înaintea ultimului nume
 C1. Indicaţie la problema propusă
1. Căile posibile sunt reprezentate în tabelul de mai jos.
Analiza problemei
(Problem analysis)
 Puncte de interes

• Analiza problemei este procesul înţelegerii problemelor din lumea

reală şi nevoile utilizatorului şi propunerea de soluţii pentru
satisfacerea acestor nevoi.

• Scopul analizării problemei este de de a înţelege cât mai bine

problema, îniante de a trece la dezvoltare.

• Pentru a identifica problemele din spatele problemei, trebuie

întrebaţi cei direct implicaţi.

• Identificarea actorilor sistemului e un pas cheie în analizarea

problemei.
 Definirea analizei problemei
Analiza problemei este procesul de a înţelege lumea reală şi nevoile
utilizatorului şi de a propune soluţii care să satisfacă aceste nevoi.

Pentru a putea face analiza problemei, definim ce este problema [Gause,

Weinberg, Exploring requirements..., 1989]:
Problema poate fi definită ca diferenţa dintre lucrurile aşa cum sunt
percepute şi lucrurile aşa cum sunt dorite.

Obs. Uneori, cea mai simplă soluţie este un proces revizuit decât un nou
sistem.

Scopul problemei este de a înţelege mai bine problema înainte ca

dezvoltarea să înceapă.
Paşii pe care trebuie să-i urmăm pentru a obţine scopul
problemei sunt următorii:
1. Să ne punem de acord privind definirea problemei.

2. Să înţelegem problema din spatele problemei.

3. Să identificăm stakeholders şi utilizatorii.

4. Să definim frontiera sistemului.

5. Să identificăm constrângerile care se impun soluţiei.

 Pasul 1. Punerea de acord privind definirea
problemei
O cale foarte simplă este de a pune problema pe hârtie şi de a vedea
dacă toată lumea e de acord cu ea. Ca parte a acestui proces, e adesea
de mare ajutor înţelegerea beneficiilor soluţiei propuse (cu mare grijă ca
beneficiile să fie descrise d.p.d.v al utilizatorilor).
Scrierea problemei se va face într-un format standardizat (vezi tabelul de
mai jos). Completerea tabelului e o tehnică simplă care ne asigură că toţi
stakeholders se concentrează spre aceleaşi scopuri.
Element Descriere
Problema e... Se descrie problema.
Afectează... Se identifică stakeholders.
Şi rezultatele în... Se descrie impactul problemei asupra
stakeholders şi asupra activităţii de
business.
Beneficiile soluţiei... Se indică soluţia propusă şi se listează
câteva beneficii
 Pasul 2. Problema din spatele problemei
O tehnică folosită este root cause analysis, care oferă o cale sistematică
de a descoperi cauza unei probleme identificate.
Root cause analysis nu reprezintă o metodologie definită; există multe
procese, instrumente şi filozofii. Totuşi, le putem clasifica în 5 “şcoli”:
• Safety-based RCA descinde din accident analysis şi occupational safety
and health.
• Production-based RCA are originea în controlul calităţii pentru
manufacturarea industrială.
• Process-based RCA al cărei scop s-a extins ca să includă procesele
business.
• Failure-based RCA are rădăcinile în practica failure analysis aşa cum se
foloseşte în inginerie şi mentenanţă.
• Systems-based RCA este un amalgam al şcolilor precedente, împreună
cu idei luate din domenii precum change management, risk management,
şi systems analysis.
Procesul general pentru executarea şi documentarea unei RCA-based
Corrective Action
1. Definirea problemei.
2. Adunarea datelor.
3. Întrebare de ce şi identificarea realţiilor de cauzalitate asociate
problemei date.
4. Identificarea cauzelor care, îndepărtate sau schimbate, vor preveni
recurenţa.
5. Identificarea soluţiilor efective care previn recurenţa, sunt sub controlul
dezvoltatorului, îndeplinesc scopurile şi nu cauzează alte probleme.
6. Implementarea recomandărilor.
7. Observarea soluţiilor recomandate pentru a asigura eficacitatea.
8. Metodologia Variability Reduction pentru rezolvarea şi evitarea
problemelor.
Tehnici root cause analysis
• Barrier analysis
• Bayesian inference
• Causal factor tree analysis
• Change analysis
• Current Reality Tree
• Failure mode and effects analysis
• Fault tree analysis
• 5 Whys
• Ishikawa diagram
• Kepner-Tregoe
• Pareto analysis
• RPR Problem Diagnosis
• Apollo Root Cause Analysis
 Pasul 3. Identificarea stakeholders şi a
utilizatorilor
Stakeholder e oricine poate fi afectat material de implementarea unui nou
sistem sau aplicaţie.
Mulţi stakeholders sunt utilizatori ai sistemului şi nevoile lor sunt uşor de
identificat, deoarece ei sunt direct implicaţi în definirea şi utilizarea
sistemului. Unii stakeholders sunt doar utilizatori indirecţi, deoarece sunt
influenţaţi doar de veniturile sistemului.
Obs. Stakeholders neutilizatori trebuie de asemenea identificaţi.
Următoarele întrebări pot fi de folos pentru identificarea stakeholders:
• Cine sunt utilizatorii sistemului?
• Cine este clientul (cumpărătorul economic) al sistemului?
• Cine altcineva va fi afectat de ceea ce produce sistemul?
• Cine va evalua şi aproba sistemul când este livrat şi funcţional?
• Există alţi utilizatori interni şi externi ai sistemului?
• Cine va asigura mentenanţa noului sistem?
• Mai e cineva care contează?
 Pasul 4. Identificarea frontierei sistemului
Împărţim sistemul în două:
1. Sistemul
2. Lucruri care interacţionează cu sistemul, prin intermediul intrărilor şi
ieşirilor

Obs. Lucrurile care interacţionează cu sistemul pot fi văzute în termeni de

actori (aşa cum s-au definit în cadrul UML), încât sistemul se poate
reprezenta ca în figura de mai jos:
În multe cazuri, frontierele sistemului sunt evidente (de exemplu, la
sistemele cu un utilizator şi o platformă).

În alte situaţii, frontierele sistemului nu mai sunt aşa evidente. De exemplu,

sunt situaţiile în care analistul trebuie să determine dacă datele sunt
împărţite cu alte aplicaţii sau dacă noua aplicaţie va fi distribuită între mai
mulţi clienti etc.

Deşi de multe ori se identifică relativ uşor, actorii pot fi determinaţi

răspunzând unor întrebări de genul (vezi şi cursul despre Diagramele
cazurilor de utilizare):
• Cine va folosi informaţia din sistem?
• Cine va opera sistemul?
• Cine va asigura mentenanţa sistemului?
• Unde va fi folosit sistemul?
• De unde îşi ia sistemul informaţiile?
• Ce alte sisteme (exterioare sistemului considerat) vor interacţiona cu
sistemul?
 Pasul 5. Identificarea constrângerilor
Definim constrângerea ca fiind o restricţie asupra gradului de libertate al
soluţiei.

Fiecare constrângere trebuie considerată cu grijă, ca parte importantă a

procesului de planificare şi unele ar putea să determine reconsiderarea
abordării tehnologice pe care am imaginat-o iniţial.

Se pot lua în calcul diverse surse ale constrângerilor: planificarea (în timp),
return on investment, bugetul pentru muncă şi echipamente, sisteme de
operare, baze de date, software-ul cumpărat, procedurile companiei,
alegerea instrumentelor şi limbajelor, constrângeri legate de personal, de
resurse etc.

În tabelul următor se listează sursele potenţiale ale constrângerilor

sistemului.
Sursă Consideraţii
Economică • Ce constrângeri financiare se aplică?
• Sunt consideraţii legate de preţul produsului?
• Sunt consideraţii legate de licenţiere?
Politică • Sunt soluţiile potenţiale afectate de consideraţii
politice?
• Sunt probleme interdepartamentale?
Sisteme • Soluţia pe care o construim e deja în sistemele
existente?
• Trebuie să menţinem compatibilitatea cu soluţiile
existente?
• Ce S.O. şi medii pot fi suportate?
Tehnologică • Suntem restricţionaţi în alegerea tehnologiilor?
• Suntem restricţionaţi în lucrul cu platformele şi
tehnologiile existente?
• Există interdicţii privind utilizarea altor tehnologii?
• Ne aşteptăm să folosim pachete software cumpărate?
Sursă Consideraţii
Mediu • Sunt constrângeri legate de mediu (environment)?
(environment) • Sunt constrângeri legale?
• Care sunt constrângerile legate de securitate?
• Ce alte standarde ne pot restricţiona?
Planificare şi • Este planificarea definită?
resurse • Suntem restricţionaţi privind resursele existente?
• Putem folosi muncă din afară?
• Putem mări resursele?

Odată identificate, unele dintre aceste constrângeri vor deveni cerinţe

pentru noul sistem. Trebuie determinat impactul fiecărei constrângeri
asupra soluţiei potenţiale.
 Concluzii

După efectuarea analizei problemei, ar trebui să avem încredere că avem:

• O bună înţelegere a problemei şi a eventualelor probleme din spatele

problemei (root causes);

• Identificarea potrivită a stakeholders, a căror analiză (judecată) va

determina în ultimă instanţă succesul sau eşecul sistemului;

• O înţelegere a locului unde se pot găsi frontierele sistemului;

• O înţelegere şi identificare a constrângerilor care pot afecta sistemul

Managementul contractelor
 1. Tipuri de contract
Resursele externe cerute pot fi sub formă de servicii. Un exemplu simplu ar fi
folosirea unei echipe temporare la contracte de durată mică, în vederea
îndeplinirii anumitor sarcini.
Pe de altă parte, contractul poate fi încheiat pentru livrarea unei aplicaţii
software complete.
Acesta poate fi:
• bespoke system (sistem comandat), i.e. un sistem care e creat de la zero,
special pentru un client;
• off-the-shelf (gata pentru cumpărare), pe care îl cumperi ca atare (“as is”) –
uneori se mai numeşte shrink-wrapped software;
• customized off-the-shelf (COTS) software – acesta este basic core system,
care e modificat pentru a îndeplini cerinţele unui anumit client.

Obs. Livrarea unui echipament, conform legii din Anglia, poate fi privită ca
un contract pentru livrarea de bunuri. Livrarea de software poate fi privită ca
oferirea unui serviciu (pentru scrierea software-ului) sau ca acordarea unei
licenţe pentru folosirea software-ului. Aceste disticţii au implicaţii legale.
O altă clasificare a contractelor este d.p.d.v. al modalităţii de plată către
furnizori:

• contracte cu preţ fixat;

• contracte de timp şi materiale;

• contracte cu preţ fixat per unitatea livrată.

Contracte cu preţ fixat

Preţul e fixat atunci când se semnează contractul. Clientul ştie că dacă nu

există schimbări în termenii contractului, preţul pe care-l va plăti este cel
consemnat în contract.

În acest caz trebuie ca analiza cerinţelor să fi avut deja loc. Odată începutî
dezvoltarea, clientul nu-şi poate schimba cerinţele fără să negocieze preţul
contractului.
Avantajele acestei metode sunt:
• Cheltuielile clientului cunoscute;
• Motivarea furnizorului;

Dezavantajele acestei metode sunt:

• Preţuri mai mari pentru a permite eventualele lucruri neprevăzute.
Furnizorul adaugă o marjă la calcularea preţului tocmai pentru a reduce
riscul apariţiei unor situaţii neprevăzute;
• Dificultăţi în modificarea cerinţelor;
• O presiune upward asupra costului schimărilor. În competiţi cu alţi
furnizori, furnizorul va încerca să ofere un preţ cât mai scăzut. Dacă, odată
contractul semnat, e nevoie de schimbări ale cerinţelor, furnizorul e în
poziţia forte de a cere un preţ mai mare pentru aceste schimbări;
• Ameninţare la calitatea sistemului. Nevoia de a menţine un preţ fixat
poate duce la deteriorarea calităţii sistemului.
Contracte de timp şi materiale
Clientul e taxat la o valoare fixă pentru unitatea de efort (de exemplu, oră
echipă). La începutul contractului, furnizorul oferă o estimare a costului,
bazată pe înţelegerea cerinţelor utilizatorului, dar aceasta nu e baza pentru
plata finală.

Avantajele acestei metode sunt:

• Uşurinţa în a schimba cerinţele;
• Lipsa presiunii preţului;

Dezavantajele acestei metode sunt:

• Handicapul clientului. Clientul e cel care se va înfrunta cu toate riscurile
asociate cu cerinţe vag definite sau care se schimbă;
• Lipsa motivaţiei pentru furnizor. Furnizorul nu are motivaţie să lucreze
într-o manieră care să încurajeze economia costurilor.
Contracte cu preţ fixat per unitatea livrată (preţ unitar fixat)
Acesta e asociat cu function point (FP) counting. Mărimea sistemului care
urmează să fie livrat e calculată sau estimată la începutul proiectului.
Mărimea sistemului trebuie să fie estimată în linii de cod, dar FPs pot fi
derivate cu uşurinţă de la documentaţia cerinţelor. E stabilit preţul per
unitate. Preţul final va fi preţul unitar înmulţit cu numărul de unităţi.

Exemplu. Tabelul de mai jos arată o astfel de estimare a preţurilor (tabel

preluat din Garmus, Herron, Measuring The Software Process, 1996)

Dacă sistemul conţine 2600 FPs, costul total va fi:

2000x967+500x1019+100x1058
Avantajele acestei metode sunt:
• Înţelegerea din partea clientului. Clientul poate vedea cum e calculat
preţul;
• Uşurinţa de a face comparaţii. Preţurile stabilite pot fi comparate;
• Emerging functionality. Furnizorul nu-şi asumă riscul funcţionalităţii în
creştere.
• Eficienţa furnizorului. Furnizorul are încă motivaţia să livreze sistemul la
funcţionalitatea cerută.
• Lyfe cycle range. Cerinţele nu trebuie specificate în forma finală la
început. Contractul poate acoperi atât etapa de analiza, cât şi etapa de
design.
Dezavantajele acestei metode sunt:
• Dificultăţi cu măsurarea dimensiunii software-ului. Numărul de linii de
cod poate fi mărit folosind un stil de codare “bombastic”. Folosirea regulilor
de numărare a FPs poate favoriza furnizorul sau clientul. Soluţia ar fi să fie
angajat un independent FP counter (numărător independent al FPs);
• Schimbarea cerinţelor. Anumite cerinţe pot afecta drastic tranzacţiile, dar
nu se adaugă la numărrea globală a FPs. O schimbare a cerinţelor făcută
târziu în ciclul de dezvoltare va necesita aproape sigur mai mult efort pentru
implementare decât dacă s-ar produce mai devreme.
O altă clasificare a contractelor (conform regulilor din Uniunea Europeană)
se face în legătură cu abordarea care e folosită pentru selectarea
contractorului:
• deschisă (open);
• restricţionată (restricted);
• negociată (negociated).

Open tendering process

În acest caz, orice furnizor poate face o ofertă pentru furnizarea de bunuri şi
servicii. Mai mult, toate ofertele care sunt în conformitate cu condiţiile
originale din invitation to tender trebuie să fie considerate şi evaluate în
acelaşi mod ca celelalte. La un proiect major, unde există o mulţime de
oferte şi procesul de evaluare e consumator de timp, acest mod poate fi
scump.
Restricted tendering process
În acest caz, sunt oferte doar de la furnizorii care au fost invitaţi de client.
Spre deosebire de open tendering process, clientul poate în orice moment
să reducă numărul furnizorilor potenţiali. Este în mod uzual cea mai bună
abordare. Există totuşi riscuri: acolo unde contractul rezultant e la un preţ
fixat, clientul îşi asumă responsabilitatea pentru corectitudinea şi
completarea cerinţelor specificate furnizorilor.

Negociated procedure
Sunt situaţii când procesul de ofertare restricţionată nu e cel mai potrivit.
În aceste cazuri, se poate justifica abordarea unui singur furnizor, caz în
care clientul poate fi acuzat de favoritisme.
 2. Etape în definitivarea contractelor
Analiza cerinţelor
Înaninte de abordarea furnizorului, trebuie să fie specificate clar cerinţele.
Documentarea cerinţelor trebuie sp aibă, în mod tipic, secţiuni de forma
celor arătate în tabelul de mai jos (un asemenea document se numeşte
uneori operational requirement sau OR):
Cerinţele definesc cu grijă funcţiile care necesită să fie duse la bun sfârşit
de noua aplicaţie şi toate intrările(inputs) şi ieşirile(outputs) necesare pentru
aceste funcţii.
Cerinţele trebuie de asemenea să declare orice standard cu care trebuie să
fie conforme şi sistemele cu care noul sistem să fie compatibil.
Sunt necesare de asemenea cerinţe operaţionale şi de calitate (vezi
capitolul despre Calitatea produselor software).

Cerinţele obligatorii (mandatory) trebuie să fie îndeplinite. Dacă o propunere

nu îndeplineşte obligatorie, atunci propunerea va fi respinsă.
Dacă cerinţa e dezirabilă (desirable), dar nu obligatorie, atunci propunerea
poate fi acceptată din acest punct de vedere, dar trebuie ca alte aspecte ale
propunerii să compenseze acest neajuns.
Planul de evaluare (evaluation plan)
Odată specificată lista de cerinţe, trebuie schiţat planul despre cum va fi
evaluată propunerea. Pentru o aplicaţie off-the-shelf, sistemul însuşi va fi
evaluat.

Invitaţia la ofertă (invitation to tender)

După analiza cerinţelor şi producerea planului de evaluare, e posibilă etapa
de a invita posibilii furnizoti să facă o ofertă. În esenţă, această invitaţie
trebuie însoţită de o scrisoare, în care să se ofere diverse informaţii: cum va
fi tratată legal oferta, care este termenul limită pentru prezentarea ofertei
etc.
Abordările privind această etapă nu sunt unitare în diverse ţări, de aceea
recomandăm consultarea normelor legale pentru fiecare ţară.
Evaluarea propunerilor
Procesul de evaluare trebuie făcut metodic şi planificat şi ar putea include:
• examinarea atentă a documentelor propunerii;
• intervievarea reprezentanţilor furnizorilor;
• demonstraţii;
• examinări ale site-urilor;
• teste practice.
Documentele propunerii oferite de furnizori pot fi examinate pentru a vedea
dacă conţin toate elementele ce satisfac cerinţele originale. Se pot cere
anumite clarificări asupra unor puncte ale propunerii.
Orice declarare factuală făcută de furnizor presupune o angajare legală din
partea lui dacă influenţează cumpărătorul să ofere contractul acelui furnizor.
Cumpărătorul poate lua iniţiativa de a păstra note ale întâlnirilor şi de scrie
apoi furnizorului pentru a obţine confirmarea asupra acurateţii lor.
Furnizorul poate, în finalul documentului contractului, să încerce să excludă
orice angajare la orice reprezentaţii făcute în negocierile precontract.
Când produsul livrat se bazează pe un produs existent, e posibil să vadă o
demonstraţie. Un pericol cu demonstraţiile este acela că sunt controlate de
furnizor. De aceea, clientul ar trebui să facă o planificare a lucrurilor pe care
doreşte să le vadă în demonstraţie, asigurându-se astfel că toate
elementele importante sunt văzute.

Cu un software off-the-shelf, e posibil să avem acces concret la aplicaţie.

De exemplu, o versiune demonstrativă poate fi valabilă (de genul celor care
după 39 zile nu mai sunt valabile). E nevoie de un plan de test, care să ne
asigure ca sunt evaluate caracteristicile importante.

O problemă frecventă este aceea că în timp ce o aplicaţie existentă

lucrează bine pe o anumită platformă, nu lucrează mulţumitor pe platforma
clientului. În acest caz sunt mai utile examinările unor site-uri operaţionale
care folosesc sistemul.
 3. Termenii tipici ai unui contract
E nevoie să schiţăm anumite arii majore asupra cărora trebuie să ne
concentrăm:
Definiţii
S-ar putea ca terminologia folosită în documentul contractului să fie definită,
de exemplu ce se înţelege prin “client” şi “furnizor”.

Forma înţelegerii
De exemplu, e contract de vânzare, de leasing sau licenţă? De asemenea,
poate subiectul unui contract, cum ar fi licenţa pentru utilizare unei aplicaţii
software, poate fi transferată unei terţe părţi?

Bunuri şi servicii furnizate

Echipament şi software. Include o listă concretă a pieselor individuale de
echipament care vor fi livrate.
Servicii. Acestea acoperă lucruri ca:
• instruire;
• documentare;
• instalare;
• conversia fişierelor existente;
• mentenanţă;
• măsuri de asigurare temporare.

Proprietarul software-ului
Două chestiuni apar: mai întâi, poate clientul să vândă software-ul la alţii şi
a doua dacă furnizorul poate vinde software-ul la alţii.
Când un software e scris special pentru un client, clientul va dori probabil
să-şi asigure exclusivitatea, de exemplu prin cumpărarea copyright-ului sau
prin specificarea în constract că foloseşte exclusiv software-ul.
Mediul (environment)
Când trebuie instalat echipamentul fizic, trebuie specificată linia de
demarcaţie dintre responsabilităţile furnizorului şi clientului cu privire la
lucruri cum ar fi furnizarea de energie.
Când software-ul e furnizat, trebuie confirmată compatibilitatea cu
hardware-ul existent şi sistemul de operare existent.
Angajamentele clientului
Clientul trebuie să asigure accomodation pentru furnizori şi probabil alte
facilităţi (internet, linie telefonică etc).

Proceduri de acceptare
Un sistem va fi acceptat numai după a trecut de testele de acceptare. O
parte a contractului va specifica detalii ca timpul pe care-l are clientul să
facă testele, deliverables de care depind testele de acceptare şi procedura
pentru semnare atunci când testarea e completată.

Standarde
Clientul poate cere furnizorului dovada că diverse standarde sunt
respectate.
Managementul proiectului şi al calităţii
Contractul trebuie să ceară ca standardele din seria ISO-9000 să fie
îndeplinite, ca şi ISO 12207 (de exemplu).

Planificarea
Oferă o planificare a timpului în care trebuie completate părţile cheie ale
proiectului. Această planificare va obliga atât clientul, cât şi furnizorul. De
exemplu, furnizorul poate si în stare să instaleze software-ul la o dată
convenită numai dacă clientul face platforma hardware disponibilă.

Preţul şi metoda de plată

În contract trebuie stabilit preţul şi modalitatea de plată.

Cerinţe legale diferite

În contract pot fi specificate ce condiţii se aplică la subcontractarea muncii,
obligaţia pentru daune către o terţă parte şi liquidated damages.
Liquidated damages sunt estimatori ai pierderilor financiare pe care clientul
le suferă dacă furnizorul a eşuat în obligaţiile pe care şi le-a asumat.
 4. Managementul contractului

La anumite puncte de decizie, clientul are nevoie să examineze munca deja

făcută şi să ia decizii despre direcţia viitoare a proiectului.

Proiectul va necesita ca reprezentanţi ai clientului şi furnizorului să

interacţioneze în multe puncte ale ciclului de dezvoltare.

Această interacţiune, sau alţi factori externi, conduc(e) de obicei la

necesitatea unor schimbări.

Pentru fiecare punct de decizie, trebuie să fie definite deliverables ce

urmează să fie prezentate de furnizori şi toate output-urile.
Odată contractul încheiat, trebuie avută în vedere calitatea muncii.
Standardul ISO 12207 oferă printre altele posibilitatea existenţei unor
agenţi, angajaţi independent de client sau furnizor, care se vor duce la bun
sfârşit verificarea, validarea şi asigurarea calităţii.

Pe măsură ce sistemul se dezvoltă, apare uneori nevoia unor schimbări în

cerinţe, care pot duce la modificarea termenilor contractului. Va fi nevoie
deci de o procedură de control al schimbărilor, care să înregistreze cerinţele
pentru schimbări, împreună cu acordul furnizorului şi eventualele costuri
suplimentare necesare pentru munca în plus.

Clientul, pe de altă parte, trebuie să se asigure că în contract se specifică şi

felul cum sunt tratate situaţiile în care furnizorul nu respectă una sau mai
multe obligaţii legale.
 5. Acceptarea

Când munca e terminată, clientul trebuie să înceapă activitatea legală

pentru realizarea testării de acceptare (acceptance testing). Contractul
poate stabili o dată limită pentru cât poate dura testarea, astfel încât clientul
să poată face testarea înainte de expirarea timpului, în vederea corectării
problemelor ridicate.
O parte a plăţii sau chiar toată plata va depinde de testul de acceptare.
Uneori o parte a plăţii finale va fi reţinută pentru perioada rulare operaţională
şi va fi plătită dacă nivelul de fiabilitate este conform specificaţiilor
contractate. Există de obicei o perioadă de garanţie, în timpul căreia
furnizorul poate pune la punct orice eroare apărută. Probabil că furnizorul
poate cere o perioadă de garanţie mai mică (30 zile, de exemplu), în timp ce
clientul ar încerca să ducă perioada de garanţie până spre 120 zile, de
exemplu (aceste valori sunt orientative, dar pot fi întâlnite adesea în
realitate).
 Concluzii

Câteva dintre punctele cheie din acest capitol pot fi astfel

rezumate:
• contractarea cu succes necesită timp important;
• e mai uşor să se obţină concesii din partea furnizorului înainte
de semnarea contractului decât după;
• un contract va stabili obligaţii şi pentru client, şi pentru
furnizor;
• negocierea contractului va include înţelegerea asupra
managementului relaţiei dintre furnizor şi client în timpul
executării proiectului.
Planificarea proiectelor software
 1) WBS – Work Breakdown Structure

Una dintre primele sarcini este să împărţim activităţile mari în activităţi mai
mici. Acest lucru înseamnă şi găsirea acelor părţi mici ale activităţii.
Înseamnă şi găsirea deliverables şi milestones care se pot utiliza pentru
măsurarea progresului.

Work breakdown structure (WBS) trebuie să fie o structură de arbore. În

vârful arborelui se va găsi de obicei lyfe cycle model (LCM) folosit în
organizaţie. Mai jos sunt date reguli pentru construirea unei structuri
corespunzătoare:
1. WBS trebuie să fie o structură de arbore. Nu trebuie să existe bucle
sau cicluri.
2. Fiecare sarcină şi descriere de deliverable trebuie să fie înţeleasă
şi neambiguă.
3. Fiecare task trebuie să aibă un criteriu de completare (completion
criterion). Trebuie să existe o cale de a decide când un task e complet.
Această decizie se numeşte completion criterion. Poate fi deliverable, un
design complet pentru proiect.
4. Toate deliverables trebuie să fie identificate. Un deliverable trebuie
să fie produs de un task sau nu va fi produs.

5. Completarea task-urilor trebuie să implice completarea întregului

task. Dacă lipsesc task-uri importante sau deliverables, întregul task nu
va fi realizat.
Exemplu. Echipa A vrea să dezvolte un sistem de recunoaştere facială
pentru folosirea pe un robot. Sistemul se doreşte a fi folosit pentru a
întâmpina vizitatorii în laboratorul de robotică. Ar trebui să recunoască
feţe pe care le-a mai văzut cu o anumită probabilitate. Primul pas în work
breakdown ar trebui să recunoască următoarele subtask-uri:
 2) PERT – Program Evaluation and Review Technique

Obs. PERT este discutat şi în capitolul despre monitorizarea riscului.

Tehnica creează un graf care arată dependenţele dintre task-uri. Fiecare

sarcină are un estimator de timp necesar pentru completarea sarcinii şi o
listă a altor task-uri care trebuie completate înainte de a începe task-ul
respectiv (dependenţele). Graful poate să nu aibă totdeauna doar un
subtask de început sau doar un subtask de oprire. Întregul task e
completat când toate subtask-urile sunt completate. Graful poate fi folosit
pentru a calcula timpii de completare pentru fiecare subtask, timpul de
completare minim pentru întregul task şi critical path pentru subtask-uri.
Tabelul 1. Subtask-urile

Diagrama PERT
A) ALGORITMUL PENTRU TIMPII DE COMPLETARE (completion
times).
1. Pentru fiecare nod, execută pasul 1.1 (până sunt calculaţi toţi timpii de
completare)
1.1 Dacă predecesorii sunt completaţi, atunci ia latest completion time
al predecesorilor şi adaugă timpul cerut pentru acest nod.
2. Nodul cu latest completion time determină earliest completion time
pentru proiect.

Exemplu. Aplicând algoritmul pentru tabelul 1 (arătat ca diagramă în

figura de mai sus), începem cu subtask-ul a; nu are dependenţe, deci
poate începe la timpul iniţial (să zicem 0). Poate fi completat la 0+8=8.
Similar, subtask-ul b poate fi completat la 0+10=10. În tabelul 2 (de pe
pagina următoare) sunt ilustrate subtask-urile şi critical paths. Doarece
aceste subtask-uri nu sunt dependente în vreun fel, pot începe la
momentul 0. Se presupune însă că există persoane disponibile ca să facă
ambele sarcini în acelaşi timp.
Tabelul 2. Subtask-urile
Exemplu (continuare). Pot fi
calculaţi acum timpii pentru
nodurile c şi d. Deoarece
predecesorii lui c se termină la 8
şi 10, subtask-ul c poate începe
la 10 şi completat la 10+8=18.
Timpul de start pentru d va fi 8 şi
timpul de completare poate fi
8+9=17 şi pentru e vor fi 10 şi
10+5=15.
Procesăm f şi g. Timpii de start
pot fi 18 şi respectiv 17. Timpii
de completare pentru f va fi
18+3=21 şi 17+2=19 pentru g.
Subtask-urile h şi i se pot calcula
cu amândouă plecând la 21 şi h
completat la 25 şi i la 24. Tabelul
2 are toţi timpii de start şi
completare.
B) CRITICAL PATH

Critical path este un set de task-uri care determină cel mai mic timp de
completare (shortest possible completion time).

Algoritm pentru marcarea critical path

1. Start cu nodul (nodurile) cu latest completion time(s); marcaţi-l (le) drept
critice.

2. Selectaţi predecesorul (predecesorii) nodului (nodurilor) critic(e) cu

latest completion time(s); marcaţi-l(e) ca fiind critice. Continuaţi cu pasul 2
până când se atinge nodul (nodurile) de start.
Tabelul 2. Subtask-urile
Exemplu. In tabelul 2 (afişat şi
în acest slide, pentru claritate)
se văd timpii de completare
pentru toate subtask-urile.
Marcăm h ca parte a drumului
critic (critical path). Predecesorii
lui h sunt f şi g. Subtask-ul f are
timpul cel mai mare de
completare (latest) al celor două
subtask-uri, deci f e marcat ca
parte a drumului critic. Subtask-
ul f are c şi d ca predecesori. Va
fi marcat c ca parte a drumului
critic, având timpul cel mai mare
de completare. Similar, b va fi
marcat ca parte a drumului critic,
ca predecesor al lui c cu timpul
de completare cel mai mare.
Drumul critic e complet.
C) SLACK TIME (satgnare)
Subtask-urile care sunt pe critical path trebuie să fie începute cât mai
devreme cu putinţă, altfel tot proiectul va fi întârziat. Totuşi subtask-urile
care nu sunt pe critical path au o anumită flexibilitate privind momentul
când sunt începute. Această flexibilitate se numeşte slack time.
Algoritm pentru slack time
1. Alege nodul necritic cu timpul de terminare cel mai mare (latest ending
time), nod care nu a fost procesat. Dacă subtask-ul nu are succesori,
alege latest ending time al tuturor nodurilor. Dacă subtask-ul are
succesori, alege cel mai mic dintre latest start times al nodurilor succesor.
Acesta este latest completion time pentru acest subtask. Fă latest start
timepentru acest subtask ca să reflecte acest timp.
2. Repetă pasul 1 până când toate noncritical path subtasks sunt
procesate.
Tabel 3. Subtask-uri cu slack time
Exemplu. Subtask-ul necritic cu
cel mai mare timp de completare
este i. Cum nu are succesori, se
foloseşte 25 ca timp de
completare. Timpul de start poate
fi schimbat în 21,22 (deoarece 25
e mai mare cu 1 decât 24).
Următorul subtask necritic
neprocesat este g, care are ca
unic succesor pe h. h trebuie să
înceapă la 21, g trebuie să se
termine la 21. Aşa că timpul de
completare al lui g devine 19,21 şi
timpul de start 17,19. Urmează d,
cu f şi g succesori. Timpul de
completare al lui d devine 17,18 şi
cel de start 8,9. Procesăm e, care
va avea startul 10,14 şi 15,19 de
completare. Pentru a,
completarea va fi 8,9 şi startul
0,1. Tabelul 3 arată aceste valori.
 3) Software cost estimation

Estimarea costului proiectului are scopul de a determina câte resurse sunt

necesare pentru completarea proiectului. De obicei estimarea se face în
programmer-months (PM).
Sunt două abordări diferite pentru estimarea costului. Vechea abordare se
numeşte LOC estimation, deoarece se baza pe estimarea iniţială a
numărului de linii de cod necesare pentru dezvoltarea proiectului.
Abordarea mai nouă se bazează pe numărarea function points în
descrierea proiectului.

A) ESTIMAREA LINIILOR DE COD (LOC)

Estimarea liniilor de cod se poate face pe baza experienţei, mărimea
proiectelor anterioare sau pe împărţirea proiectului în bucăţi mai mici şi
estimarea fiecărei părţi. Abordarea standard presupune, pentru fiecare
piesăi, estimarea timpului maxim (pesimist), minim (optimist) şi cel mai
probabil. Vezi capitolul despre Managementul riscului, unde s-au definit
timpii a, b, m şi s-a calculat te=(a+4m+b)/6.
B) LOC-BASED COST ESTIMATION
Formula de bază are 3 parametri:
Cost=α*KLOCβ+γ
Parametrul α este costul marginal per KLOC (mii de linii de cod). Acesta
este costul adăugat pentru fiecare mie de linii de cod.
Parametrul β este un exponent ce reflectă neliniaritatea relaţiei. O valoare
β>1 înseamnă că costul per KLOC se măreşte pe măsură ce mărimea
proiectului creşte.
Parametrul γ reflectă costul fixat pentru realizarea oricărui proiect.

Exemplu. Compania A a înregistrat datele din

proiectele anterioare. Estimaţi care ar fi parametrii
pentru formula de estimare a costului şi ce efort ar
lua un proiect de 30 KLOC.

Soluţie. Din tabel rezultă o relaţie liniară între mărime (size) şi efort (PM).
Panta este 2,4, care reprezintă α. Deoarece linia e dreaptă, β=1. Valoarea
lui γ va fi 0.
C) CONSTRUCTIVE COST MODEL (COCOMO)
COCOMO este formula clasică de estimare a costului bazat pe LOC. A
fost creată de Barry Boehm. Foloseşte mii de instrucţiuni dursă livrate
(thousands delivered source instructions – KDSI) ca unitate a mărimii.
KLOC e echivalent.
Boehm a divizat datele de proiecte istorice în 3 tipuri de proiecte:
a) Application (ex: procesoare de date)
b) Utility programs (ex: compilatoare, analizoare)
c) System programs

Boehm a determinat valorile parametrilor pentru modelul costului pentru

determinarea efortului:
a) Application programs: PM=2.4*(KDSI)1.05
b) Utility programs: PM=3.0*(KDSI)1.12
c) System programs: PM=3.6*(KDSI)1.20
Exemplu. Calculaţi efortul programatorului
pentru proiectele din tabelul alăturat.

Boehm a determinat de asemenea că în datele de proiect, există un timp

de dezvoltare standard bazat pe tipul de proiect şi mărimea proiectului.
Mai jos sunt date formule pentru timpul de dezvoltare (development
time – TDEV):
a) Application programs: TDEV=2.5*(PM)0.38
b) Utility programs: TDEV=2.5*(PM)0.35
c) System programs: TDEV=2.5*(PM)0.32

Exemplu. Calculaţi standardul TDEV pentru

proiectele din tabelul alăturat, folosind formulele
de mai sus.
D) FUNCTION POINT ANALYSIS
Ideea este să identificăm şi să cuantificăm funcţionalitatea cerută pentru
proiect. Trebuie să cuantificăm lucruri în comportarea exterioară care vor
necesita procesare. Itemii clasici sunt:

Inquires sunt perechi cerere-răspuns care nu schimbă datele interne. De

exemplu, cererea pentru o adresă a unui anumit angajat.
Inputs sunt itemi ai datelor aplicaţiei care sunt furnizaţi programului.
Outputs sunt afişări ale datelor aplicaţiei. Un output poate fi un raport, un
screen display sau un mesaj de eroare.
Internal files sunt fişiere logice ce sunt menţinute de sistem. Dacă un
fişier conţinând date personale şi date privind departamentul, se va
contoriza probabil ca două fişiere separate în function point analysis.
External interfaces sunt date care sunt împărţite cu alte programe.
Counting Unadjusted Function Points
Itemii sunt identificaţi şi clasificaţi ca simpli, medii, complecşi. Se
asignează ponderi şi totalul se sumarizează. Acest total se numeşte
unadjusted function points. Exemple de ponderi sunt date în tabelul de
mai jos:

Nu există standarde pentru numărarea function points. E important de

reţinut că function points încearcă să măsoare cantitatea de efort
necesară pentru dezvoltarea software.
E) PRODUCTIVITATEA
Se determină prin împărţirea LOC la efortul programatorilor, exprimat în
zi-programare. (vezi şi exemplele date la Calitatea software – laborator).
Exemplu. Compania A are efortul pentru fiecare fază a ciclului de viaţă dată
în tabelul următor. Calculaţi efortul în termeni de LOC/zi-programare şi în
termeni de function points/zi programare. Function point estimate a fost de
50 unadjusted function points. Produsul final include 950 linii de cod.

65
Efortul total este de 65 zile-programare. Productivitatea este 950/65=14,6
linii de cod/zile-programare.
Folosind fp (function points), obţinem productivitatea=50fp/65 zile-
programare=0,77 fp/zile-programare.
F) EVALUAREA ESTIMĂRILOR
Metrica propusă de Tom DeMarco este estimate quality factor (EQF).
EQF e definită ca aria de sub curba reală, împărţită cu aria dintre valoarea
estimată şi reală. Valorile peste 8 sunt rezonabile, conform lui DeMarco.

Exemplu. Estimările de mai jos sunt date pentru un proiect care costă 3,5
milioane dolari şi a fost completat după 11,5 luni:

11,5

Aria totală=11,5*3,5=40,25.
Diferenţa este 2,3 − 3,5 ∗1,5 + 3,1 − 3,5 ∗ 4 + 3,9 − 3,5 ∗ 2,5 + 3,4 − 3,5 ∗ 3,5 = 4,75
Raportul este 40,25/4.75=8,7
1,5=1,5-initial
4 =5,5-1,5
2,5=8-5,5
3,5=11,5-8
Planificarea proiectelor software

- Laborator -
 Întrebări
1. De ce trebuie ca WBS să fie arbore?
2. Care e avantajul folosirii diagramelor PERT?
3. Este critical path importantă dacă la proiect lucrează
doar o persoană?
4. Care e importanţa slack time?
5. De ce trebuie ca parametrii pentru estimarea costului
să fie determinaţi din datele companiei?
 Problema 1
Creaţi un WBS pentru task-ul vopsirii unei camere.
Presupunem activităţile: planificarea muncii,
cumpărarea proviziilor, vopsirea propriu-zisă,
curăţarea.
 Problema 2
Desenaţi diagrama PERT pentru sarcinile problemei 1.
 Problema 3
Desenaţi diagrama PERT
pentru sarcinile prezentate
în tabelul alăturat.
Completaţi tabelul arătând
critical path şi slack times.
 Problema 4
Estimaţi parametrii de cost pentru mulţimea de date din tabel:
 Problema 5
Calculaţi efortul COCOMO, TDEV şi productivitatea pentru
un proiect organic care e estimat la 39800 linii de cod.
Indicaţii şi soluţii
 Indicaţii la întrebări
2. Care e avantajul folosirii diagramelor PERT?
Răspuns: Deşi WBS dezvoltă o listă de task-uri, e greu de văzut ce
task-uri vor fi făcute primele şi care task-uri determină final
completion time.

3. Este critical path importantă dacă la proiect lucrează doar o

persoană?
Indicaţie. E importantă dacă toate task-urile sunt pe critical path.
 Problema 1
Creaţi un WBS pentru task-ul vopsirii unei camere. Presupunem activităţile:
planificarea muncii, cumpărarea proviziilor, vopsirea propriu-zisă, curăţarea

Soluţie. Mai jos e dată un exemplu de soluţie:

a)Selectarea culorii pentru cameră
b)Cumpărarea vopselei
c)Cumpărarea periilor
d)Pregătirea pereţilor
e)Deschiderea cutiei de vopsea
f)Amestecarea vopselei
g)Vopsirea pereţilor
h)Curăţarea
 Problema 2

Desenaţi diagrama PERT pentru sarcinile problemei 1:

a. Selectarea culorii pentru cameră
b. Cumpărarea vopselei
c. Cumpărarea periilor
d. Pregătirea pereţilor
e. Deschiderea cutiei de vopsea
f. Amestecarea vopselei
g. Vopsirea pereţilor
h. Curăţarea
Soluţie.
 Problema 3
Desenaţi diagrama PERT pentru sarcinile prezentate în tabelul de mai jos.
Completaţi tabelul arătând critical path şi slack times.

Indicaţie.
* = critical path slack times ??
0 10

10 15 *

10 12 10,16 12,18

10 13 10,12 13,15

15 22 se ia cel mai mare 15,18 22,25

12 19
15 25 se ia cel mai mare *
13 22
12 17
13 18 se ia cel mai mare 13,20 18,25
22 28
25 31 se ia cel mai mare *
18 24
 Problema 4
Estimaţi parametrii de cost pentru mulţimea
de date din tabel:

Indicaţie.

Cost = 4.0 * Marime(KLOC) + 5.0

 Problema 5

Calculaţi efortul COCOMO, TDEV şi productivitatea pentru un proiect

organic care e estimat la 39800 linii de cod.

Indicaţii.

Formula de aplicaţie se foloseşte în acest caz:

PM
Cost = 2.4 * (KDSI)1.05 =2.4*(39.8)^1.05=114.8

TDEV = 2.5 * (PM)0.38 =2.5*114.8^0.38=15.16

Productivitatea = 39800 LOC / (114.8 PM * 20 zile/lună)

Managementul persoanelor şi
al echipei de lucru
- Concepte generale -
 OB (Organizational Behaviour)

-E un domeniu al ştiinţelor sociale

-Teoriile încearcă să explice comportamentul uman
-Frederick Winslow Taylor (1856-1915) e privit ca părintele
“managementului ştiinţific” a cărui parte e OB.

Taylor are 3 obiective mari:

• să selecteze cea mai bună (potrivită) persoană pentru acel
post (job);
• să instruiască acele persoane folosind metodele cele mai
bune;
• să ofere stimulente sub forma unor salarii mai mari celor
mai buni muncitori.
 Selectarea persoanei potrivite pentru job
Procesul de recrutare
Meredith Belbin (în Team Roles At Work, 1993) face distincţia dintre
candidat eligibil şi potrivit.
Candidatul eligibil e cel al cărui CV oferă un număr “corect” de ani într-un
post similar, în care are calificative “bune”.
Candidatul potrivit e cel care poate face concret treaba bine.
O greşeală uşor de făcut este să se selecteze un candidat eligibil care nu
e de fapt potrivit. Pe de altă parte, candidaţii potriviţi care nu sunt tehnic
vorbind eligibili, pot fi candidaţi ideali deoarece, odată angajaţi, sunt mai
loiali organizaţiei.
M.Belbin e de părere că cei care au îndemânare mai mare, în dauna
experienţei bogate, şi de asemenea o dorinţă mai mare de a se instrui, pot
fi mai degrabă aleşi pentru job.
O procedură standard pentru recrutare poate fi:
• Crearea unei specificaţii a job-ului;
• Crearea unui profil a celui care va căpăta job-ul, specificând calităţile,
calificarea, educaţia, experienţa dorite;
• Obţinerea aplicanţilor: în acest sens, se va face un anunţ într-o
publicaţie în care să aibă impactul dorit. E recomandabil să se ofere
suficiente informaţii despre job: salariul oferit, locaţia, scopul muncii,
durata, calificările necesare.
• Examinarea CV-urilor. E un pas important pentru eliminarea celor care
nu sunt calificaţi pentru job, pentru că în CV-uri se caută acele elemente
specificate în profilul job-ului
• Interviuri, teste de aptitudini, teste de personalitate, precum şi
examinarea unor mostre ale muncii trecute. Interviul e cea mai uzuală
metodă.
• Alte proceduri. În anumite cazuri se pot cere referinţe, în altele
adeverinţe medicale etc.
 Instruirea folosind cele mai bune metode
Când un nou membru al echipei e recrutat, managerul echipei trebuie să
planifice cu mare atenţie integrarea persoanei în echipă. Dacă proiectul e
deja în dezvoltare, s-ar putea ca integrarea să nu fie uşoară. Adaptarea
noului venit în echipă trebuie luată în considerare.

Liderul echipei trebuie să fie conştient de nevoia de a asigura în mod

continuu instruirea membrilor echipei. Încă de când e construit profilul
celui care va ocupa un post, va fi gândit un profil cu nevoile de instruire.

Un anumit training poate fi asigurat de companiile comerciale de training.

Chiar atunci când bugetul e redus, nu trebuie renunţat la training, chiar
dacă se poate recurge la soluţia în care unui membru al echipei i se
asigură trainingul şi acesta devine, de nevoie, noul trainer pentru colegii
săi.
Metodele învăţate trebuie aplicate în realitate. Inspecţiile ne pot ajuta să
asigurăm acest lucru.
 Motivaţia
1) Modelul Taylorist
Acest punct de vedere se reflectă în folosirea piece-rates (caz în care
muncitorii sunt plătiţi cu o sumă fixă pentru fiecare item produs). Problema
care apare în această situaţie este cea în care se introduce o nouă
tehnologie ce îmbunătăţeşte productivitatea. De obicei, schimbări radicale
în practicile de lucru trebuie să fie precedate de trecerea de la piece-rates
la day-rates (care se referă la plata muncii după timpul lucrat).

Recompensele trebuie să fie legate de munca produsă. Când se

realizează un computer, e greu să fie izolată şi cuantificată munca făcută,
mai ales când dezvoltarea sistemului e în mare măsură efort de echipă.
Într-un astfel de mediu, a face distincţie în mod excesiv între membrii
echipei poate dpuna moralului şi productivităţii. Echipa primează în faţa
indivizilor.
2) Ierarhia de nevoi a lui Maslow
Oamenii sunt motivaţi în diverse moduri. În mod evident, banii sunt un
stimulent important. Totuşi, când această parte e satisfăcută, apare
nevoia unor alte stimulente.

Maslow, un psiholog american, a sugerat că există o ierarhie a nevoilor.

Dacă un nivel inferior al nevoilor e asigurat, apar nevoile de pe nivelul
superior. Nevoile de bază sunt pentru lucruri precum mâncarea şi
adăpostul. Cel mai înalt nivel, e nevoia de “self-actualization”, adică
sentimentul că-ţi foloseşti complet potenţialul.

În practică, liderul de proiect realizează că oamenii pot fi motivaţi diferit.

Mărirea de salariu, oricând binevenită, are probabil un impact mai mic
pentru un lucrător cu vechime, care e foarte bine plătit, decât pentru un
nou venit în echipă. Cel cu vechime ar prefera să i se acorde o anumită
autonomie la muncă, care arată respect pentru judecata lui şi simţul de
răspundere.
3) Teoria celor doi factori a lui Herzberg

Anumite lucruri pot face munca nesatisfăcătoare. Îndepărtând cauzele, e

posibil să nu fie nevoie ca munca să fie făcută mai provocatoare. La baza
cercetării pe care Heryberg a făcut-o referitor la satisfacţia pe care o oferă
un job, a identificat doi factori importanţi:

• igiena sau factorii de mentenanţă, care pot aduce insatisfacţie dacă nu

sunt respectaţi, de exemplu nivelul d eplată sau condiţiile de muncă;

• motivatorii, care te fac să simţi că munca e valoroasă

4) Teoria anticipativă a motivaţiei
Un model al motivaţiei dezvoltat de Vroom identifică trei influenţe asupra
motivaţiei:
• perspectiva (aşteptarea), credinţa că munca mai susţinută va duce la o
performanţă mai bună;
• instrumentalitatea, credinţa că o performanţă mai bună va fi răsplătită;
• valoarea percepută a recompensei rezultate.

Absenţa oricarui element poate duce la lipsa motivaţei.

Exemplu:
a) Lucrând la un package, făcut de o terţă companie, în care îndepărarea
unui bug nu e posibilă, aşteptarea devine 0 şi motivaţia se pierde.
b) Dacă lucraţi la un package pentru un utilizator şi aflaţi că utilizatorul
dezvoltă şi un package alternativ, se dezvoltă ideea că vă irosiţi munca
degeaba (instrumentalitatea devine 0).
5) Modelul Oldham-Hackman al caracteristicilor job-ului

Oldham-Hackman sugerează că satisfacţia muncii e bazată pe 5 factori:

a) Varietatea abilităţilor, numărul abilităţilor pe care posesorul job-ului
are oprtunitatea să le exerseze;
b) Identitatea activităţii, gradul în care munca ta şi rezultatele ei sunt
identificabile ca aparţinând persoanei tale;
c) Semnificaţia activităţii, gradul în care munca ta are influenţa asupra
altor activităţi;
d) Autonomia, discreţia pe care o ai în felul în care îţi faci munca;
e) Feedback-ul, informaţiile pe care le obţii despre rezultatele muncii
 Metode de îmbunătăţire a motivaţiei

• Stabilirea unor scopuri precise. Implicarea oamenilor din echipă în

stabilirea scopurilor ajută la aceptarea lor;
• Asigurarea feedback-ului;
• Design-ul job-ului.

Două măsuri sunt folosite adesea pentru a spori design-ul job-ului:

• Job enlargement
• Job enrichment
 Lucrul în echipă
Grupurile formale pot fi împărţite în grupuri de comandă, care sunt grupuri
departamentale şi reflectă structura manegeraială formală, şi grupuri de
activitate, care gestionează anumite sarcini.

Cum se formează o echipă

Echipele trec prin 5 etape de dezvoltare:
• forming – membrii echipei se cunosc între ei şi stabiliesc reguli;
• storming – conflictele apar când diverşi oameni încearcă să se erijeze în
lideri şi se stabilesc metodele de operare ale grupului;
• norming – apare sentimentul de identitate a grupului;
• performing – o atenţie specială se acordă acum sarcinilor;
• adjourning – grupul se separa (dizolvă)
Belbin a ajuns la concluzia că echipele au nevoie de un echilibru între
diverse tipuri de oameni:
• The chair, nu neapărat un lider strălucit, dar eficient la conducerea
întâlnirilor, calm, puternic şi tolerant;
• The plant, cineva care are idei şi soluţii potenţiale pentru probleme;
• The monitor-evaluator, bun la evaluarea ideilor şi la selectarea celei
mai bune;
• The sharper, omul care direcţionează atenţia echipei către lucrurile
importante;
• The team worker, foarte bun la crearea unui mediu de lucru bun;
• The resource investigator, cel care găseşte resurse fizice şi de
informaţii;
• The completer-finisher, bun la completarea activităţilor;
• The company worker, un bun membru al echipei care e dispus să preia
sarcinile mai puţin atractive, dacă acest lucru conduce la succesul
echipei.
 Performanţa grupului
O clasificare a activităţilor grupului este:
• additive tasks;
• compensatory tasks;
• disjunctive tasks;
• conjunctive tasks.
 Luarea deciziilor
Deciziile pot fi clasificate astfel:
- structurate, relativ simple, decizii de rutină în care se pot aplica regulile;
- nestructurate, mai complexe şi care necesită adesea creativitate.

O altă clasificare priveşte gradul de risk şi de incertitudine.

Obstacole în luarea deciziilor

• Faulty heuristics;
• Escalation of commitment, se referă la dificultatea de a schimba o
decizie deja luată, chiar în faţa greşelii evidente;
• Information overload, când informaţiile abundă şi “nu se mai vede
pădurea din cauza copacilor”.
Măsuri pentru a reduce dezavantajele luării deciziilor

Folosirea tehnicii Delphi încearcă să adune opiniile unui număr de experţi,

fără a-i aduce faţă în faţă. Dându-se o problemă, e urmată procedura:
• se face o listă cu experţi;
• problema e prezentată experţilor;
• experţii dau recomandările lor;
• recomandările sunt adunate;
• răspunsurile sunt recirculate;
• experţii comentează ideile altora şi modifică recomandările;
• dacă liderul detectează un anumit consens de opinii, procesul se
opreşte, altfel comentariile sunt recirculate la experţi.

Problema este că uneori experţii pot fi în locaţii depărate.

 Leadership
Leadership-ul e bazat pe ideea unei autorităţi. Această putere provine fie
din poziţia persoanei (putere dată de poziţie) sau din calităţile individuale
ale persoanei.
Puterea dată de poziţie poate fi analizată mai departe în:
- putere coercitivă, de a forţa pe cineva să facă ceva sau de a ameninţa
cu pedeapsa pe cineva;
- putere de conectare, care e bazată pe accesul al cei care au putere;
- putere legitimată, bazată pe titlul persoanei, care-i conferă un status
special;
- putere de recompensare.

Puterea personală poate fi descompusă în:

- putere a expertului, care vine din specializarea în anumite activităţi;
- putere a informaţiei, în care posesorul are acces la informaţii la care
alţii nu au;
- putere personală propriu-zisă, care e bazată pe carisma personală.
Stiluri de conducere
• directive autocrat, ia decizii singur, cu atenta supraveghere a
implementării lor;
• permissive autocrat, ia decizii singur, dar lasă subordonaţilor sarcina
implementării lor;
• directive democrat, ia decizi iparticipativ, dar supraveghează
implementarea lor;
• permissive democrat, ia decizii participativ şi lasă subordonaţilor
sarcina implementării lor.