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 esteun 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).

•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.

•Verificare şi validarea: operaţie necesară pentru depistarea şi corectarea eventualelor erori (errors,
bugs, faults) din sistem.

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 producceva
•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.

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.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%).

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 managementuluiA) Ciclul de control al proiectuluiManagementul, î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

Stakeholders pot fi:

•interniîn echipa proiectului: vor fi sub controlul managerial direct al liderului de proiect;
•externiechipei 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.
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.

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ţiiProblema 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ţee senţ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 particularinatngibilitateaşi complexitatea, cer anumite

lucruri speciale:

•Natura critică în creştere a software-ului. Utilizatorule anxiosgâ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-ule utilizat din ce în ce mai mult în arii care sunt critice d.p.d.v. al
siguranţei, cum ar fi controlul avioanelor.

•Intangibilitateasoftware-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ăcutdintr-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ăreparaeaei.

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.

JamesA.McCall(“AnIntroduction toSoftwareQuality Metrics”, 1978) încearcăsă identifice calităţi

specifice produselor, potrivite software-ului. El grupează calităţile software în 3 mulţimi:
•productoperation qualities;
•productrevision qualities;
•producttransition qualities.
Factorii productoperation quality
•Corectitudinea. Marja până la care programulstaisfacespecificaţ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 persoanelorneautorizatepoate fi
controlat;
•Usability (mod de utilizare).Efortul necesar pentru a învăţa, opera, pregăti intrarea şi interpreta
ieşirea.

Factorii productrevision 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 producttransition 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.

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

4. ISO 9126 (standard publicat în 1991)

•funcţionalitate, care acoperă funcţiile pe care produsul software le asigură pentru satisfacerea
nevoilor utilizatorilor;
•siguranţă (reliability), care se referă lacapabilitateasoftware-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-ule 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)

Eficienţă

Comportare în timp
Comportare d.p.d.v. al resurselor

Obs. Understandabilitye 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ă.

Mentenabilitate

Analisability
Flexibilitate (Changeability)
Stabilitate
Testabilitate

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.

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.
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, mentenabilitypriveş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) Oprivire 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 suntobţ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 finaltrebuie 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 practicetrebuie 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: InitialProcedurile 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: RepeatableOrganizaţ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: DefinedOrganizaţiile au definit felul în care fiecare sarcină a ciclului de viaţă al dezvoltării
software va fi făcută.

•Nivelul 4: ManagedProdusele ş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 circlee 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ă obiectiveleorganizaţ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

IS = Information System
MIS = Management Information Cum va contribui sistemul propus la obiectivele stabilite
SystemObiective 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 organizaţiei Ce efect va avea noul sistem asupra 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?

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 forecastinge 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.

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.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.
unde reste 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 NPVcu 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.

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ă).

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.

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.

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.

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 valuesau risk exposure). Risk value e calculat:
risk value= risk likehoodx 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):

unde REinainte e valoarea riscului originală, REdupaeste 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:

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.

Convenţia de notare în reţeaua PERT

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:

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ă:
• se calculează deviaţia standard pentru fiecare eveniment al proiectului;
• se calculează valoarea z pentru fiecare eveniment care are o dată ţintă;
•se converteşte valoarea zla 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

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 Teste
data ţintă, iar teeste data aşteptată:
Valoarea zpentru 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 -

Cum se poate reduce probabilitatea sau impactul fiecărui risc? 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

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 zpentru 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.

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

Calea B+D are deviaţia standard

Nodul 4 are aşadar deviaţia standard 0,53.

Problema 4. Se consideră reţeaua PERT de mai jos. Calculaţi valorile zpentru fiecare dintre
evenimentele cu date ţintă din reţea.
Indicaţie.

Valoarea z pentru evenimentul 5 este:

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ţ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ă dejala 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 ceeace 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 Exemple Comentarii

raportareTip de
raportare
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 genera rapoarte scrise
meetings
Scrisă formală regulată Rapoarte privind De obicei săptămânale folosind formulare
progresul, foi de calcul
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
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ă. 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.

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 linecu mulţi “zimţi” indică
necesitatea replanificării.

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 chartpentru 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 costurilorO diagramă ca cea din figura de mai jos oferă o metodă simplă
decomparare 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 ValueEarned Value Analysisa 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 valuesau 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 budgetE bazat pe planul proiectului şi arată creşterea prognozată în timpa 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 valuela î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 Managersau 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?

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-uleste‘‘the process of applying various techniques and principles for the purposeof defining a
device, a process, or a system in sufficient detail to permit itsphysical 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 vizibilsau 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’’,IEEESoftware, 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.

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.2. Fazele
procesului de designExemplu. 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.

2.1 InterfeţeleInterfaţ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 imprumutaredin 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::imprumutareinput parameters –
isbnreturn type –int0 dacănu este disponibilă cartea1 dacă este disponibilă cartea şi instanţa
imprumut se creează cu succes-1 dacă apare o condiţie de eroaremethod
copiecarte::imprumutareinput parameter –NrImprumutreturn type –int0 dacă nu e disponibilă
copia1 dacăe disponibilă copia

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.3. Concepte ale designuluiExemplu. Rafinaţi funcţia imprumutaredin 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.

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) —eo 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.3.1 Atribute ale designuluiExemplu. Evaluaţi abstractizarea în
funcţionalitatea împrumutului din sistemul de gestionare a împrumuturilor de cărţi dintr-o
bibliotecă.Soluţie. Funcţia imprumutareapare în 3 module: bibliotecă, cititor şi copiecarte. Cea mai
bună abstractizare se atinge atunci când funcţia imprumutaredin modulul bibliotecacunoaş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 imprumutaredin modulul biblioteca doar apelează
funcţia imprumutare, atunci există o bună abstractizare.

Dacă funcţia imprumutaredin 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?

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 yprin definiţie;
•control dependencies, în care valoarea lui x determină dacă se execută codul care conţine definiţiile
lui y.
4. Măsurarea coeziunii4.1“Feliile”unui program (program slices)Exemplu. Înmulţirea prin însumare
repetată: Să se calculeze x*y. Valoarea de ieşire z are data dependencyfaţă de x, deoarece x se
adună la z şi are control dependencyfaţă de y, deoarece controlează de câte ori de adună x la z.z =
0;while x > 0 doz = z + y;x = x –1;end-while

Program slicespot 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-whileSoluţie. Vom folosi linie continuă pentru data dependencies şi linie punctată
pentru control dependencies.
Un input slicepoate începe cu variabila de intrare x. Tokens x, 0, x, x, şi1din instrucţiunile while x>0
şix=x-1 se adaugă la slice. Apoi se adaugă tokens z, z şiy din instrucţiunea z=z+y. Nici un alt token nu
mai poate fi adăugat.De aceea, input slicee tot mai puţin z=0.
Un input slicepentru 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 şiOtt 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ă treifunctional cohesion measures:•Weak
functional cohesion (WFC)—raportulglue tokenslatotal tokens•Strong functional cohesion (SFC)—
raportulsuperglue tokenslatotal tokens•Adhesiveness (A)—mediaadezivităţiituturortokens

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şadarstrong functional cohesion (SFC) este zero. Din cei 31 tokens,
sunt12 glue tokens, deci weak functionalcohesion este12/31 sau 0.387.Sunt patruslices. Zero tokens
auadezivitate 100%. Patrutokenssunt întreislices, aşa încât au adezivitate 100%. Opttokens 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%.Adezivitateaeste 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ăruldeparametri de date de intrareci= Numărul de
parametri de control de intraredo= Numărul de parametri de date de ieşire(output data parameters)co=
Numărulde parametri de control de ieşire (output control parameters)gd= Numărul de variabile globale
folosite ca dategc= Numărul de variabile globale folsoite ca controlw= 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 copiecartenu e nici agregare, nici moştenire, deoarece obiectul carte reprezintă
abstracţia unei cărţi, în timp de copiecarteeste itemul concre (fizic) care se împrumută.
 Software design

-laborator-

Exerciţiul 1. Se dă următorul design. Analizaţi cuplarea, coeziunea, abstractizarea.

Soluţie exerciţiul 1.
Cuplare–se doreşte cuplare slabă şi acest design are cuplare slabă, deoarece clasa collegenu 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 displaydin collegenu include
detalii despre metodele lower-level de afişare.

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).

Soluţie exerciţiul 2. 1.O persoană încearcă să răsucească mânerul uşii. -EV2.Uşa e deblocată de
sistem. -SV3.Un angajat lasă un străin pe uşă. -EH4.Un anagajat are un geamăn identic. -EH5.O
imagine are un număr minim de similarităţi pentru algoritmul de potrivire (matching algorithm). –SH

Exerciţiul 3. Calculaţi functional cohesion metrics(Bieman, Ott) pentru fragmentul de cod de mai jos.
Desenaţi graful orientat.

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%

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.
 Testareasoftware-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 selectionse 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 criterionse poate baza pe:

•criteriu de acoperire (coverage criterion), cum ar fi executarea a ncazuri 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 cazuride 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 Bdacă orice test care satisface
criteriul A satisface de asemeneacriteriul 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”.

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.

3.2 Testare funcţională (functional testing)

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 şib<a+c şic<a+b, (4) a>0 şib>0 şic>0.Coloanele matricii vor reprezenta un subdomeniu. Pentru
fiecaresubdomeniu, 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 orprima 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 coveragenu sunt subdomain tests. Nu sunt subdomenii

mutual excluse în ceea ce priveşte executarea diferitelor instrucţiuni sau ramuri. Every-path
coverageeste 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,carenecesităodef-free de la fiecare definiţie
la orice folosire posibilă. Cele mai extinse criterii sunt all-du-paths, care necesită toate def-free
pathsde la fiecare definiţie la fiecare folosire posibilă.

Exemplu.Data flow testing pentru problema triunghiului.

dcu–singura c-useeste 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 defeste 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 defsla toate folosirile

toate cazurile de testare ale dcu şi dpucombinate.

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

toate cazurile de testare ale dcu şi dpucombinate.

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.2Inferenţă 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 frontierax=1 este în domeniul true. În
termeni de boundary testing, spunem că on testssunt în domeniul true şi off testssunt valori ale lui x
mai mari decât 1 şi sunt în domeniul fals.Dacăo condiţiee 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 testaproape
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?
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

B. Probleme

1.Un program calculează aria unui triunghi. Intrările sunt 3 mulţimi de coordonate x,y. Construiţi testele
funcţionale.

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

C. Problemă propusă
1.Pentru următorul cod, identificaţi toate căile posibile, path testsşi data flow tests:

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

O tehnică folosită este root cause analysis, care oferă o cale sistematică de a descoperi cauza unei
probleme identificate.
Pasul 2. Problema din spatele problemei
Root cause analysisnu reprezintă o metodologie definită; există multe procese, instrumente şi filozofii.
Totuşi, le putem clasifica în 5 “şcoli”:•Safety-based RCAdescinde dinaccident analysisşioccupational
safety and health.•Production-based RCAare originea încontrolul calităţii pentru manufacturarea
industrială. •Process-based RCAal cărei scop s-a extins ca să includăprocesele business. •Failure-
based RCAare rădăcinile în practica failure analysisaşa cum se foloseşte în inginerie şi mentenanţă.
•Systems-based RCAeste un amalgam al şcolilor precedente, împreună cu idei luate din domenii
precum change management, risk management, şisystems analysis.

Procesul general pentru executarea şi documentarea unei RCA-based Corrective Action1.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 implementareaunui 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.Sistemul2.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ţiisau 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?

Mediu (environment)• Sunt constrângeri legate de mediu (environment)?

Planificare şi resurse
•Sunt constrângeri legale?
•Care sunt constrângerile legate de securitate?
•Ce alte standarde ne pot restricţiona?
• Este planificarea definită?
•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:
•bespokesystem (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-wrappedsoftware;
•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 requirementsau OR):

Cerinţele definesc cu grijă funcţiilecare 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 utilizareunei 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 accomodationpentru 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 damagessunt 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.

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.

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.
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 completarepentru fiecare subtask, timpul
de completare minimpentru întregul task şi critical pathpentru subtask-uri.

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 timeal predecesorilor şi adaugă
timpul cerut pentru acest nod.
2.Nodul cu latest completion time determină earliest completion timepentru 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 timpuliniţ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 timesal 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 subtaskssunt 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âteresurse 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.
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.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.

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 costuluipentru 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

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 efortul programatorului pentru proiectele din tabelul alăturat.

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.

Inputssunt itemi ai datelor aplicaţiei care sunt furnizaţi programului.

Outputssunt afişări ale datelor aplicaţiei. Un output poate fi un raport, un screen displaysau un mesaj
de eroare.

Internal filessunt 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 interfacessunt date care sunt împărţite cu alte programe.

Counting Unadjusted Function PointsItemii 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.

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:
Planificareaproiectelor software

-Laborator -

Întrebări

1.De ce trebuie ca WBS să fie arbore?

2.Care e avantajul folosirii diagramelor PERT?

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ă?

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.

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.

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:

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.

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

Cost = 2.4 * (KDSI)1.05
TDEV = 2.5 * (PM)0.38
Productivitatea = 39800 LOC / (114.8 PM * 20 zile/lună)

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.