Managementul proiectelor software

- Principii generale -

Scopuri:
Stabilirea obiectivelor proiectrii software Identificarea diferenelor ce apar la dezvoltarea proiectele software i la dezvoltarea altor proiecte Definirea etapelor uzuale ale unui proiect software nelegerea nevoii de planificare, monitorizare i control Msurarea succesului unui proiect n ndeplinirea obiectivelor

1) Introducere
Un proiect este o activitate planificat. Obs. Un task repetat de un numr de ori nu este un proiect. Obs. Amploarea proiectului este foarte important. Un proiect ce implic 200 oameni difer (ca management) fa de unul ce implic 2 oameni.

2) Proiecte software vs. Alte proiecte

Un proiect software are anumite caracteristici care-l difereniaz fa de alte tipuri de proiecte: Invizibilitatea: dac la un pod ce se construiete, e vizibil progresul, la produsele software nu e la fel; Complexitatea: produsele software conin mai mult complexitate per dolar sau euro cheltuit Flexibilitate: un produs software se poate schimba n funcie de preferinele utilizatorilor, mai degrab dect s se cear utilizatorilor s-i modifice comportamentul pentru a folosi produsul.

3) Activiti n managementul proiectelor software

Un proiect software nu privete 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 nsui 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 urmtorul:

Detalierea etapelor

Analiza cerinelor: aceast etap trebuie s stabileasc

ceea ce doresc utilizatorii de la software.

Descriere: documentaia 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 operaiile sunt structurate intern

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

 Verificare

i validarea: operaie necesar pentru depistarea i corectarea eventualelor erori (errors, bugs, faults) din sistem.

Implementarea / instalarea: termenul implementare se

refer, dup unii autori, la tot ce urmeaz dup etapa de design, iar dup alii 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 corecia erorilor ce nu au fost depistate n faza de testare, de extinderea i mbuntirea sistemului. Mentenana i suportul pot fi vzute ca procese software minore.

4) Clasificarea proiectelor software

a) Putem ntlni: sisteme de informaie (information systems): exemplu un sistem de control al stocurilor. sisteme n timp real (embedded systems): exemplu un sistem ce controleaz aerul condiionat dintr-o cldire. Obs. Unele sisteme pot avea caracteristici din ambele tipuri de sisteme b) Din punct de vedere al scopului sistemului: sisteme care produc ceva sisteme ce ndeplinesc anumite obiective.

5) Proiectul ca sistem
Un proiect se ocup de crearea unui nou sistem sau/i de transformarea unuia vechi. Sistem (system) = mulime de pri intercorelate Un sistem poate fi parte a unui sistem mai mare i poate avea ca pri componente subsisteme (subsystem). n afara sistemului exist aa numitul mediu al sistemului (systems environment), adic acele elemente care pot afecta sistemulo, dar asupra crora sistemul nu are control. Sistemele deschise (open systems) sunt sistemele ce interacioneaz cu mediul. Aproape toate sistemele sunt deschise.

6) Ce este managementul?
Managementul presupune urmtoarele activiti: Planificare ce trebuie fcut; Organizare making arrangements; ncadrarea personalului selectarea oamenilor potrivii; Conducere, ndrumare se dau instruciuni; Monitorizare verificarea progresului; Control aciuni care s remedieze penele; Inovare propunerea de noi soluii; Prezentare legtura cu utilizatorii.

Pe de alt parte, cele mai frecvente provocri pentru un manager sunt urmtoarele (printre altele): S fac fa deadlines-urilor (85%); S fac fa restriciilor legate de resurse (83%); Comunicarea efectiv de sarcini (80%); Ctigarea angajamentului membrilor echipei (74%); Stabilirea unor pietre de hotar msurabile (70%); S fac fa schimbrilor (60%); S fac fa conflictelor (42%); S gestioneze vnztorii i sub-contractorii (38%). Procentele de mai sus se refer la numrul de manageri care au identificat fiecare item. Un manager poate identifica mai mult dect un item.

7) Probleme cu proiectele software

Dei multe sarcini ale managementului se gestioneaz mai degrab se sisteme de management dect de manageri, e adevrat c pentru succesul unui proiect e totui rspunztoare 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; ignorana managerului n IT; lipsa cunotinelor n aria sa de munc; lipsa standardelor; lipsa documentaiei la zi; activiti anterioare neterminate la timp; lipsa comunicrii ntre utilizatori i tehnicieni; schimbarea software environment; presiunea dat de deadline; lipsa controlului de calitate; lipsa trainingului.

8) Controlul managementului
A) Ciclul de control al proiectului Managementul, n general, poate fi vzut ca un proces de stabilire a obiectivelor i apoi monitorizarea sistemului pentru a vedea care este performana sa adevrat.

B) Obiective Managerul i echipa sa trebuie s stabileasc clar obiectivele, pentru a se putea concentra asupra lucrurilor eseniale 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 evoluiei proiectului.

C) Msurarea eficacitii Obiectivele efective sunt bine definite. Un enun vag, de tipul s mbunteasc relaia cu clientul, nu e un obiectiv. Dar reformularea reducerea plngerilor clienilor cu 25% poate fi un obiectiv. Msura eficacitii poate fi, n anumite cazuri, un rspuns simplu (da/nu) la o ntrebare, de pild ai instalat noul software sptmna trecut? D) Sub-obiective i scopuri (goals) n multe situaii, un obiectiv se poate mpri n sub-obiective. De exemplu, pentru atingerea obiectivului A, trebuie ndeplinite n prealabil obiectivele B i C. Aceste sub-obiective se mai numesc scopuri (goals).

9) Stakeholders
Sunt persoane cheie care au un anumit interes n proiect,. Aceste persoane trebuie identificate ct mai devreme cu putin, n vederea stabilirii unui canal de comunicaii. Nu toate persoanele implicate n proiect au aceleai motivaii. Stakeholders pot fi: interni n echipa proiectului: vor fi sub controlul managerial direct al liderului de proiect; externi echipei proiectului, dar n aceeai organizaie: de exemplu, liderul proiectului ar putea avea nevoie de asisten din partea grupului de management al informaiei n ideea de a aduga tipuri de date noi n baza de date. n acest caz, trebuie negociat angajamentul acelor persoane. externi echipei i organizaiei: n acest caz, stakeholders pot fi clienii, cu care trebuie ncheiat un contract.

10) Descrierea cerinelor

A) Cerine funcionale: ce trebuie s fac sistemul

B) Cerine de calitate: cum trebuie s se comporte sistemul, de exemplu timp de rspuns, uurina folosirii, fiabilitate

C) Cerine referitoare la resurse: nregistrarea a ct de mult dorete o organizaie s cheltuiasc pe sistem

11) Informaii i control n organizaii

Problema comunicaiilor depinde direct proporional 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 ali lideri de grup, raporteaz catre managerul de la nivelul superior. Spre vrf, tot mai puine persoane trebuie s ia hotrri i cantitatea d einformaii crete.

A) Nivele de luarea deciziilor i informaii

Deciziile pot fi grupate astfel: decizii strategice: eseniale 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 aciuni pentru ndeplinirea obiectivelor i s monitorizeze progresul activitii; decizii operaionale: se refer la munca de zi cu zi pentru implementarea proiectului

B) Diferene n tipurile de informaii

Tabel 1. Tipuri de informaii necesare pentru luarea deciziilor Caracteristic motivare orientare focus detaliu rspuns ci de acces la zi acuratee certitudine obiectivitate tipul informaiei Operaional eficien intern specific unei funcii detaliat rapid standard esenial esenial esenial nalt mai ales cantitativ Strategic eficacitate intern i extern specific unei organizaii rezumat nu aa rapid flexibil dezirabil aproximativ adesea predictiv mai subiectiv adesea calitativ

Eficacitatea se refer la a face lucrul potrivit. Eficiena se refer la folosirea optim a resurselor.

C) Msurtori n proiectele mai mari, liderii de proiect trebuie s gestioneze o cantitate mare de informaii. Aceste informaii nu trebuie s fie vagi i, ideal, ar trebui s fie cantitative. Msurtorile software (software measurements) se divid n: msurtori ale performanei: msoar caracteristicile sistemului livrat. Msurtorile includ timpul mediu dintre defeciuni i timpul de nvare a aplicaiei (useability); msurtori predictive: se fac n timpul dezvoltrii i arat care va fi performana aproximat a sistemului.

Concluzii
Proiectele sunt prin definiie activiti non-rutin i de aceea mai nesigure dect alte sarcini; Proiectele software sunt similare cu alte activiti, dar au anumite atribute ce prezint dificulti, 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 rspund de ntregul proiect; Pentru ca obiectivele s aib concretee, trebuie s existe ci practice de a verifica c obiectivele se ndeplinesc. Asta conduce la nevoia de msurtori; Trebuie s existe msurtori obiective de succes, n ideea de a ajuta la comunicarea neambigu a diverselor pri implicate n proiect.

Calitatea software-ului

1. Introducere
Dei 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 caliti cerem unui sistem. Calitatea privete toate etapele planificrii i executrii proiectului, dar se dovedete de un interes particular n urmtoarele etape: Identificarea infrastructurii proiectului; analiza caracteristicilor proiectului; identificarea produselor i activitilor; revizuirea i editarea planului.

2. Importana calitii software-ului

Caracteristicile speciale ale software-ului, n particular inatngibilitatea i complexitatea, cer anumite lucruri speciale: Natura critic n cretere a software-ului. Utilizatorul e anxios gndindu-se la calitatea software-ului, mai ales la fiabilitatea acestuia. E cazul organizaiilor care devin din ce n ce mai dependente de sistemele de calcul i software-ul e utilizat din ce n ce mai mult n arii care sunt critice d.p.d.v. al siguranei, cum ar fi controlul avioanelor. Intangibilitatea software-ului. Acest lucru face dificil cunoaterea faptului c o anumit sarcin n proiect a fost completat satisfctor. Rezultatele acestor sarcini pot fi fcute tangibile cernd dezvoltatorului s produc deliverables care s fie examinate pentru calitate. Acumularea erorilor n timpul dezvoltrii software. Deoarece produsul e fcut dintr-un numr de pai unde ieirea unuia devine intrarea altuia, erorile produse n etapele timpurii ale proiectului conduc la amplificarea lor. Cu ct o eroare e descoperit mai trziu, cu att mai mult cost reparaea ei.

3. Definirea calitii software-ului

Pentru orice sistem software, ar trebui s fie trei specificaii: o specificaie funcional descriind ceea ce trebuie s fac sistemul; o specificaie de calitate, ce privete ct de bine opereaz funciile; o specificaie de resurse, ce privete ct de mult se cheltuiete pe sistem.

James A.McCall (An Introduction to Software Quality Metrics, 1978) ncearc s identifice caliti specifice produselor, potrivite software-ului. El grupeaz calitile software n 3 mulimi: product operation qualities; product revision qualities; product transition qualities.

Factorii product operation quality Corectitudinea. Marja pn la care programul staisface specificaiile i ndeplinete obiectivele utilizatorului; Fiabilitatea. Marja pn la care se ateapt ca programul s lucreze n parametrii specificai cu precizia dorit; Eficiena. Cantitatea de resurse cerut de software; Integritate. Marja pn la care accesul la software sau date a persoanelor neautorizate poate fi controlat; Usability (mod de utilizare). Efortul necesar pentru a nva, opera, pregti intrarea i interpreta ieirea. Factorii product revision quality ntreinere. Efortul necesar pentru localizarea i repararea erorii ntr-un program operaional; Testabilitatea. Efortul necesar pentru a testa un program pentru a asigura c lucreaz n parametrii specificai; Flexibilitate. Efortul necesar pentru a modifica un program operaional.

Factorii product transition quality Portabilitate. Efortul necesar pentru transferul programului de pe o configuraie hardware i un mediu software pe alta/altul; Refolosirea. Marja pn la care un program poate fi utilizat n alte aplicaii; Interoperabilitate. Efortul necesar pentru a cupla un sistem cu altul. Pentru fiecare criteriu, trebuie inventate nite msuri pentru a evalua gradul n care calitatea e prezent. Orice msur relativ bun trebuie s compare numrul unitilor la maximul posibil n acele circumstane. De exemplu, numrul maxim de erori ntr-un program va fi raportat la mrimea programului, astfel nct msura numrul de erori la mia de linii de cod e mai util dect numrul de erori din program. n anumite cazuri putem msura calitatea n mod direct, n timp ce n altele lucrul msurat nu e calitate propriu-zis, dar reprezint un indicator care s indice n ce grad e prezent calitatea.

4. ISO 9126 (standard publicat n 1991)

ISO 9126 identific 6 categorii de calitate a software-ului: funcionalitate, care acoper funciile pe care produsul software le asigur pentru satisfacerea nevoilor utilizatorilor; siguran (reliability), care se refer la capabilitatea software-ului pentru a menine nivelul de performan; usability, care se refer la efortul cerut pentru a utiliza software-ul; eficien, care se refer al resursele fizice folosite cnd software-ul e executat; mentenabilitate, care se refer la efortul cerut pentru a face schimbri 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.

Funcionalitate

Suitability (ct de potrivit este) Acuratee Interoperabilitate (abilitatea de a interaciona) Conformitate (compliance)(fa de standardele legale) Securitate Maturitate (frecvena eecurilor datorate erorilor) Toleran la erori Recuperabilitate nelegere (Understandability) nvare (Learnability) Operabilitate (Operability)

Siguran

Usability

Obs. Understandability e calitatea de a putea ptrunde conceptele logice i aplicabilitatea lor. Learnability este diferit de operability. Un instrument software poate fi uor de nvat, dar consumator de timp la utilizare, deoarece, de exemplu, utilizeaz un numr mare de meniuri n cascad.

Eficien

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

Mentenabilitate

Analisability Flexibilitate (Changeability) Stabilitate Testabilitate

Obs. Analisability (sau diagnosability) este uurina cu care de determin cauza unui eec. 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 neateptate.

Portabilitate

Adaptabilitate Uurina instalrii (Installability) Conformitate (Conformance) Uurina de a fi nlocuit (Replaceability)

Obs. Conformance, spre a se distinge de compliance, se refer la acele standarde care privesc portabilitatea. Exemplu: folosirea unui limbaj de programare standard n multe medii software/hardware e exemplu de conformance. Obs. Replaceability se refer la factori care dau compatibilitatea n sus ntre componentele software vechi i cele noi.

ISO 9126 ofer anumite indicaii privind folosirea caracteristicilor de calitate. Pentru sistemele interactive (interactive end user system), elementul primordial d.p.d.v. al calitii ar fi usability. O dat cerinele software stabilite, se stabilesc urmtorii pai: Selectarea metricilor de calitate. Nu sunt date indicaii n standardul ISO 9126 privind aplicabilitatea diverselor msuri ce trebuie folosite. Definirea nivelelor de rating. Metricile folosite trebuie s se mapeze pe scale care s indice gradul n care au fost satisfcute cerinele. Definirea criteriilor de evaluare. Este felul n care scorurile d.p.d.v. al calitii se combin pentru a da o vedere de ansamblu asupra produsului. Mai jos e dat un exemplu de acordare a scorurilor:

5. Msuri practice ale calitii software

Mai jos sunt date orientativ anumite modaliti de msurare a unor caliti particulare. Fiecare proiect va trebui s aib ns propriile msuri. Reliability Aceasta poate fi msurat n termeni de: disponibilitate(availability), procentul unui interval de timp n care sistemul poate fi folosit; timpul mediu dintre eecuri, timpul total de lucru, mprit la numrul de eecuri; eec la cerere, probabilitatea ca un sistem s nu fie disponibil la un anumit timp sau probabilitatea ca o tranzacie s eueze; activitatea de suport (support activity), numrul de rapoarte de erori.

Mentenability Poate fi vzut ca flexibilitate plus diagnosability, care poate fi definit drept timpul mediu necesar pentru diagnosticarea unei erori. Obs. D.p.d.v. al utilizatorului, mentenability privete 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 flexibilitii. Se definete ca productivitatea necesar pentru a ncorpora anumite caracteristici noi n sistemul existent.

6. Standarde externe
Unele standarde de calitate au fost gndite pentru toate produsele, nu doar pentru produsele software. I) O privire asupra cerinelor 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 cunotina persoanelor din toate nivelele; b) Toate procedurile de control al calitii trebuie documentate; c) Toate contractele pentru a furniza bunuri i servicii trebuie s conin cerine 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 nct s fie ndeplinite cerinele stabilite cu utilizatorul; e) Trebuie s existe proceduri care s aprobe designul i documentaia auxiliar. f) Acolo unde componentele sistemul ce urmeaz s fie livrate sunt obinute de la un partener extern, trebuie s existe proceduri care s asigure, s verifice i s menin calitatea acestor componente;

g) Produsele individuale trebuie s fie identificabile, precum i componentele sale; h) Procesul prin care e creat produsul final trebuie s fie planificate i monitorizare; i) Inspecia i testarea trebuie s aib loc n timpul fazei de dezvoltare i nainte de livrare. De asemenea, testele i inspeciile trebuie s se fac i asupra componentelor obinute de la parteneri extern. j) Echipamentul folosit n procesul de producie trebuie s fie controlat adecvat n privina calitii; k) Statutul testrii pentru toate componentele i sistemele trebuie s fie nregistrat clar n toate etapele; l) Trebuie avut grij ca itemii care sunt cunoscui ca potenial de a se defecta s fie folosii cu mare atenie; m) Cnd se identific un defect, trebuie luate msuri pentru ndeprtarea prii defecte i pentru a ne asigura c defectul nu apare din nou; n) Trebuie s existe proceduri corespunztoare manipularrii, stocrii, mpachetrii i livrrii produsului; o) Trebuie meninute suficiente nregistrri care s demonstreze c sistemul de asigurare a calitii lucreaz cu succes;

p) Sistemul de management al calitii software trebuie s fie supus auditului; q) Activitile de service i suport trebuie s fie subiect pentru sistemul de management al calitii; r) Dezvoltatorul trebuie s stabileasc tehnici statistice potrivite care s verifice c produsul final poate fi recepionat.

II) TickIt. Department of Trade and Industry (DTI) a formulat standardul TickIt, care d interpretarea standardului ISO 9000 (mai ales n ceea ce privete dezvoltarea software). Acesta include cerine, 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 dezvoltrii; c) Trebuie fcute revizuiri ale designului; d) Trebuie revizuit metodologia suitability designului; e) Trebuie revizuit progresul sistematic;

f) Trebuie s fie posibil gsite caracteristicile designului software la specificaii i cerine; g) Designul trebuie documentat corespunztor; h) Trebuie produse planurile de testare potrivite, specificaiile i nregistrrile; i) Trebuie pus n practic un code of practice, care guverneaz felul n care software-ul e dezvoltat. Code of practice trebuie s includ cerine precum: Designul trebuie s fie divizat pe nivele, fiecare cu intrri i ieiri identificabile; Software-ul trebuie organizat pe module; Un modul trebuie s ndeplineasc n mod normal o singur funcie sau o mulime de funcii 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 folosete 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 organizaiile care produc software ntr-unul dintre cele 5 nivele de maturitate pentru a indica ct de sofisticate sunt i ct de calitative sunt practicile de producere a software-ului. Aceste nivele dunt definite dup cum urmeaz: Nivelul 1: Initial Procedurile urmate tind s fie ntmpltoare. Anumite proiecte vor avea succes, dar asta datorit doar priceperii unor profesioniti din echip (inclusiv managerii). Nu exist nivel 0 i de aceea orice organizaie va fi implicit la acest nivel. Nivelul 2: Repeatable Organizaiile de la acest nivel vor avea proceduri de baz pentru managementul proiectelor. Totui felul n care o sarcin individual e dus la bun sfrit va depinde n mare msur de persoana care o face.

Nivelul 3: Defined Organizaiile au definit felul n care fiecare sarcin a ciclului de via al dezvoltrii software va fi fcut. Nivelul 4: Managed Produsele i procesele implicate n dezvoltarea software sunt subiect al msurii i controlului. Nivelul 5: Optimizing mbuntirile aduse procedurilor sunt concepute i implementate folosind datele adunate n proceseul de msurare.

Pentru fiecare dintre aceste nivele, exceptnd nivelul 1, s-au identificat arii de proces cheie (key process areas KPAs) care s fac distincia ntre nivelul curent i nivelele mai joase. Aceste KPAs sunt listate mai jos:

7. Tehnici care ajut la creterea calitii software

Tehnicile care ajuta la creterea calitii 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 puin egoist (egoless programming), care a ncurajat practica simpl a programatorilor care s se uite la codul celorlai. 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 obinerii unor practici pentru calitate a fost verificarea corectitudinii muncii n etapele incipiente, conceptuale. Ideea este s se poat obine modele ale muncii, chiar dac nu perfecte, care s poate fi depanate ulterior.

Dintre tehnicile specifice temelor majore aminitite, enumerm: Inspeciile 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, mprind dezvoltarea software n 3 echipe: una pentru specificaii, una pentru dezvoltare a codului i una de testare) Metode formale (care definesc pre- i post- condiii pentru fiecare procedur) Software quality circles (SWQC) ( tehnic aprut n Japonia): un quality circle e un grup de 4-10 oameni lucrnd n aceeai arie, care se ntlnesc o or pe sptmn (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 cerinele de calitate practice trebuie definite cu mare atenie Trebuie s existe moduri practice de testare a prezenei sau absenei calitii Multe dintre calitile care sunt aparente utilizatorilor de software pot fi testate doar atunci cnd sistemul e complet E nevoie deci de modaliti de verificare a calitii probabile n timpul dezvoltrii Anumite tehnici de cretere a calitii 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 cruia a fost nevoie de 400 zile-munc. Un amendament la sistem a provocat adugarea a 100 SLOC, care au luat 20 zile-munc pentru implementare. Calculai: a) productivitatea sistemului original b) Productivitatea pentru amendament c) Extendibilitatea Problema 2. Sugerai specificaii 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 pn vineri. ntr-o perioad de 4 sptmni, sistemul a fost indisponibil timp de o ntreag zi din cauza unor probleme cu harddiscul i indisponibil alte 2 zile pn la 10 a.m. Din cauza unor uniti. Care este availability i timpul mediu dintre eecuri (failures), presupunnd c au fost 3 eecuri?

Problema 4. Identificai instane specifice n mediul de dezvoltare software unde sunt relevante cerinele: a) privind controlul echipamentului (punctul (j) din standardul BS EN ISO 9001); b) privind nregistrarea statusului testrii al tuturor componenetelor (punctul (k) din standardul BS EN ISO 9001); c) privind mnuirea corect, depozitarea, mpachetarea i livrarea produsului (punctul (m) din standardul BS EN ISO 9001) Ce proceduri s-ar aplica n mediul software n legtur cu aceste necesiti?

Indicaii i rspunsuri

Problema 1. Un sistem cuprinde 5000 SLOC, pentru implementarea cruia a fost nevoie de 400 zile-munc. Un amendament la sistem a provocat adugarea a 100 SLOC, care au luat 20 zile-munc pentru implementare. Calculai: a) Productivitatea sistemului original b) Productivitatea pentru amendament c) Extendibilitatea Soluie. a) Productivitatea sistemului original=5000/400=12,5 b) Productivitatea pentru amendament=100/20=5 c) Extendibilitatea=5/12,5x100=40%

Problema 2. Sugerai specificaii de calitate pentru un editor de texte. Indicaii. Software-ul se poate diviza ntr-un numr de arii de interes, care se evalueaz separat, cum ar fi pregtirea documentului, prezentarea, mbinarea corespondenei etc. De exemplu; Calitate uurina nvrii; Definiie timpul necesar unui novice pentru a nva s opereze a.. s produc un document standard; Scara ore Test oferii-i sistemul, un manual de utilizare i un document pe care sl pregteasc. Cronometrai ct i ia (considerai, de exemplu, c planificat este 2 ore, cel mai bun caz i ia 1 or, cel mai ru 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 pn vineri. ntr-o perioad de 4 sptmni, sistemul a fost indisponibil timp de o ntreag zi din cauza unor probleme cu harddiscul i indisponibil alte 2 zile pn la 10 a.m. Din cauza unor uniti. Care este availability i timpul mediu dintre eecuri (failures), presupunnd c au fost 3 eecuri? Soluie. Sistemul trebuie s fie disponibil n fiecare zi 18-8 = 10 ore. Pe perioada de 4 sptmni 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 aadar 186/200x100 = 93%. Timpul mediu dintre eecuri este 186/3 = 62 ore.

Problema 4. Identificai instane specifice n mediul de dezvoltare software unde sunt relevante cerinele: Indicaie. b) Statusul testrii. Componentele software care sunt actualizate nu sunt eliberate ctre utilizatori nainte ca o testare adecvat s fie fcut.

Evaluarea proiectului

1. Introducere Ideea de a ncepe (continua) munca la un proiect este de fapt compararea unui proiect cu alternativele sale i hotrrea 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 obine un beneficiu care nu s-ar obine dac proiectele ar fi manageriate independent (D.C.Ferne, 1991). De aceea e nevoie de un plan strategic care s defineasc obiectivele organizaiei. n acest fel se definesc scopurile programului. Va exista aadar, mai ales n cazul organizaiilor 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 organizaiei.

Principalele probleme i ntrebrile care se pun

Obiective Cum va contribui sistemul propus la obiectivele stabilite ale organizaiei? De pild, pot crete cifra de afaceri? Cum se ncadreaz sistemul propus n planul IS? Cu ce sistem existent va interfera noul sistem? Ce sistem existent va nlocui? Ce efect va organizaiei? avea noul sistem asupra

Plan IS

Structura organizaiei MIS Personal Imagine

Ce informaii va aduce sistemul i la ce nivel? Ce implicaii aduce asupra politicii globale asupra personalului? n ce fel va afecta imaginea clienilor organizaiei noul sistem?

IS = Information System MIS = Management Information System

3. Evaluarea tehnic Const n evaluarea funcionalitii fa de hardware-ul i software-ul existent. 4. Analiza costurilor - beneficiilor Orice proiect ce necesit investiii trebuie s obin cel puin un beneficiu mai mare dect dac s-ar depozita suma de investiii ntr-o banc, de exemplu. Trebuie aleas cea mai bun opiune de proiect dintre cele disponibile. Analiza costurilor beneficiilor se face n dou etape: identificarea i estimarea tuturor costurilor i beneficiilor pentru ducerea la bun sfrit a proiectului. exprimarea acestor costuri i beneficii n uniti 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 fiierelor, recrutarea i pregtirea personalului. Costuri operaionale: include costurile necesare dup ce sistemul a fost instalat.

Clasificarea beneficiilor:
Beneficii directe: sunt mai uor de estimat, din exploatarea direct a sistemului. Beneficii indirecte estimabile: sunt n general beneficii secundare, cum ar fi acurateea crescut prin introducerea unei interfee 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 arta cnd apar cheltuielile (expenditure) i venitul.

Dificultatea i importana cash-flow forecasting e evideniat de numrul companiilor care dau faliment deoarece, dei dezvolt produse sau servicii profitabile, nu pot susine cheltuieli neplanificate (se observ i din grafic ca la nceput e necesar s se fac investiii, venitul aprnd cnd sistemul poate fi exploatat).

Inflaia poate cauza cheltuieli neprevzute.

De exemplu, tabelul de mai jos indic estimarea cash flow pentru 4 proiecte:

6. Tehnici de evaluare cost - beneficiu

Pentru tabelul de mai jos, ntocmii un clasament privind dezirabilitatea proiectelor prezentate i motivai alegerea fcut:

Profitul net: este diferena dintre venitul total i cheltuieleile totale. n tabelul precedent, proiectul 2 are profitul net cel mai mare, dar necesit i cea mai mare investiie iniial (1 milion). Perioada de restituire (Payback period): este timpul scurs pn la acoperirea investiiei iniiale. Tem: calculai perioada de restituire pentru fiecare proiect din tabelul precedent. Return on investment (ROI) sau Accounting rate of return (ARR) este o metod de a compara profitabilitatea net cu investiia cerut: Tem. Calculai ROI pentru fiecare dintre proiectele prezentate n tabelul precedent. Un dezavantaj al acestui criteriu este acela c nu ine seama de timpul necesar al cash-flow.

Net present value (NPV) i internal rate of return (IRR) sunt cunoscute ca tehnici de discounted cash flow (DCF). Calcularea NPV este o tehnic de evaluare a proiectului i ia n calcul profitabilitatea proiectului i timing-ul cash flows care sunt produse. Se determin prin reducerea (discounting) viitoarelor cash flows cu un procent numit rat de discount.

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

unde r este rata de discount. Valoarea prezent a unui cash flow poate fi calculat prin nmulirea cash flow cu factorul de discount potrivit. NPV pentru un proiect poate fi calculat prin reducerea fiecrui cash flow i nsumarea valorilor reduse.

Exemplu de calcul a NPV pentru proiectul 1:

Tem. Calculai NPV pentru proiectele 2,3 i 4 i indicai care dintre proiecte poate fi ales, pe baza criteriului NPV.

Internal rate of return (IRR). Un dezavantaj al NPV ca msura a profitabilitii e acela c, dei e utilizat ca metod de comparare a proiectelor, s-ar putea s nu fie direct comparabile cu ctigurile cu alte investiii. IRR ncearc s ofere o msur a profitabilitii ca un beneficiu procentual ce e direct comparabil cu ratele dobnzilor (interest rates). De aceea, un proiect ce are IRR de 10% va merita dac, de exemplu, capitalul poate fi mprumutat cu mai puin de 10% sau dac nu poate fi investit n alt parte cu un beneficiu mai mare de 10%. IRR e calculat ca rata de discount procentual ce va produce NPV cu valoare 0. Se poate calcula cu uurin folosind, de exemplu, Microsoft Excel, care are implementate funcii specifice. Obs. Se pot gsi 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 totui rspunsul 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 ctiguri ar putea fi de departe mai mici dect 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 finanm acest proiect, mai putem finana i alte proiecte valoroase?

7. Evaluarea riscurilor
Principalul risc este acel c proiectul s-ar putea s nu ndeplineasc obiectivele pentru care a fost gndit. Nu e un risc dac proiectul se termin mai repede dect 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 clasificm fiecare risc n raport cu importana lui i probabilitatea de apariie. Exemplu de o parte de astfel de matrice, unde H mare (high), M medie, L sczut (low). ntr-un capitol ulterior se dau detalii.

Riscurile i NPV Cnd 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 evalurii riscurilor este s se considere fiecare posibil efect i estimarea probabilitii ca el s apar. n loc de o singur estimare a cash flow, vom avea o mulime de cash flows, fiecare cu o probabilitate de apariie. Valoarea proiectului e obinut prin nsumarea costurilor sau beneficiilor pentru fiecare rezultat, sum ponderat cu probabilitatea corespunztoare. Aceast abordare e potrivit mai ales pentru proiectele mari, unde exist suficieni factori de incertitudine. Pe de alt parte, stabilirea probabilitilor de apariie a riscurilor nu e uor de fcut.

Analiza profilului riscului (risk profile analysis) O abordare este analiza sensibilitii (senzitivity analysis). Aceasta presupune variaia fiecrui parametru ce afecteaz costul sau beneficiul proiectului pentru a stabili ct de sensibil e profitabilitatea proiectului la fiecare factor. Rezult astfel identificarea factorilor decisivi pentru succesul proiectului. Obs. Analiza sensibilitii presupune variaia unui singur factor la un moment dat. Se folosete metoda Monte Carlo pentru astfel de simulri. Exist instrumente software care implementeaz metoda.

Folosirea arborilor de decizie Sunt multe situaii cnd n care putem evalua dac un factor de risc e important i dac e, ce aciuni 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 trziu. nlocuirea imediat nseamn amnarea unor proiecte. Nenlocuirea la timp poate fi o opiune scump, n condiiile n care conduce la pierderea beneficiului din cauza neputinei de a satisface toate cererile. S-a calculat c extinderea sistemului are NPV 57000 Euros, dei dac piaa se extinde smenificativ, poate conduce la o valoare a NPV de -100000 Euros. Dac piaa crete, o nlocuire a sistemului acum duce la NPV de 250000 Euros. Dac vnzrile nu cresc, beneficiile se vor reduce, conducnd la NPV de -50000 Euros.

Exemplu (continuare). Compania apreciaz c probabilitatea s creasc piaa e de 20%, adic probabilitatea s nu creasc fiind de 80%. Acest scenariu poate fi reprezentat n figura de mai jos.

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

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

Analiza unui arbore de decizie const n evaluarea beneficiului ateptat lund-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 uurin (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 depete totalitatea costurilor; O sum de bani ctigai mai trziu este mai puin valoroas dect aceeai sum de care s dispunei n prezent, care pot fi investii; Tehnicile de discounted cash flow pot fi folosite pentru a calcula valoarea prezent a future cash flow, innd cont de rata dobnzilor (interest rates) i de gradul de nesiguran (uncertainty); Tehnicile de analiz cost-beneficiu i arborii de decizie furnizeaz instrumente pentru evaluarea rezultatelor ateptate (expected outcomes) i alegerea ntre diverse strategii.

Managementul riscului

1. Introducere

n aceast prezentare, atenia se concentreaz pe riscul datorat ntrzierii proiectului sau depirii bugetului alocat

Identificm trei tipuri de riscuri: cele cauzate de dificultile inerente ale estimrii; cele datorate presupunerilor fcute n timpul procesului de planificare; cele datorate unor evenimente aprute neateptat.

Estimarea erorilor Anumite sarcini sunt greu de estimat din cauza lipsei experienei 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 acuratee mrit. Estimarea poate fi mbuntit dac se analizeaz datele istorice pentru activiti similare i sisteme similare. Pstrarea nregistrrilor comparnd estimrile originale i rezultatele finale vor pune n eviden tipurile de sarcini pentru care se fac cu greu estimri corecte. Presupunerile fcute la planificarea activitilor La fiecare etap a procsului de planificare, e important s listm explicit toate presupunerile care au fost fcute i s identificm ce efecte pot avea asupra planului dac sunt nepotrivite. Posibiliti Anumite posibiliti nu pot fi prevzute. Totui, majoritatea evenimentelor neateptate pot fi, n realitate, prevzute. Asemenea evenimente se pot ntmpla din timp n timp i, chiar dac probabilitatea de apariie a lor s fie mic, trebuie luate n calcul i planificate.

2. Managementul riscurilor
Exist un numr 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 numete ingineria riscului (risk engineering). Toate elementele din figur se vor discuta n detaliu n slide-urile urmtoare.

3. Identificarea riscurilor (risk identification)

Trebuie fcut distincia dintre cauza ntmpltoare (hazard) i efectul produs de acesta. Anumite cauze ntmpltoare sunt generice adic sunt relevante pentru toate proiectele software. Asemenea riscuri sunt nelegerea greit a cerinelor 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 legai de aplicaie (application factors) natura aplicaiei (fie c e vorba de o aplicaie de porcesare simpl a datelor, de un sistem critic din punct de vedere al securitii sau de sisteme distribuite) poate fi un factor critic. De asemenea, mrimea ateptat a aplicaiei e important (cu ct e mai mare aplicaia, cu att probabilitatea de apariie a erorilor e mai mare).

Factorii legai de personal (staff factors) un programator experimentat face, de regul, mai puine erori dect unul cu mai puin experien. Pe de alt parte, e important aria n care unii au experien (experiena unui programator n Cobol nu prea conteaz dac dezvolt un sistem n C++). Factorii legai de proiect (project factors) e important ca proiectul i obiectivele sale s fie bine definite i s fie clare pentru toi 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 trziu sau cu probleme. Pe de alt parte, folosirea acestor metode pentru prima oar poate duce la ntrzieri.

Factorii hardware/software un proiect care necesit hardware nou poate pune probleme mai mari dect 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 legai de schimbri (changeover factors) o schimbare radical pentru noul sistem faciliteaz apariia riscurilor. Schimbrile graduale minimizeaz riscurile dar nu sunt ntotdeauna practice. Factorii legai de furnizori (supplier factors) un proiect se bazeaz uneori pe organizaii exterioare. Riscurile legate de ntrzierile cu care livreaz anumite produse sau de calitatea acestora nu pot fi controlate. Factorii de mediu (conjuncturali) de exemplu, schimbri legate de regulile de plata a salariilor (modificarea CAS, a sporurilor etc) pot afecta succesul unui proiect ce gestioneaz salarizarea ntr-o organizaie. Factorii de sntate i siguran dei impactul asupra sntii i siguranei celor care interacioneaz cu un proiect software e diminuat fa de alte proiecte (de exemplu, construcii), totui, 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)

Identificnd riscurile, e util o cale de a le evalua importana. Anumite riscuri au probabilitate mai mare de apariie (cum ar fi mbolnvirea unuia dintre membrii echipei, chiar i pentru o perioad scurt de timp), iar altele au probabilitate mic de apariie (un eec hardware s duc, de exemplu, la pierderea ntregului cod scris). Probabilitatea apariiei unei cauze ntmpltoare de risc e cunoscut ca probabilitatea riscului (risk likehood). Efectul rezultat, dac apare, se numete impactul riscului (risk impact) i importana riscului e cunoscut ca valoarea riscului (risk value sau risk exposure). Risk value e calculat: risk value = risk likehood x risk impact Obs. Termenii de mai sus pot fi ntnii i sub alte denumiri, nu sunt denumiri universal acceptate. Ideal, impactul riscului e exprimat n termeni monetari i probabilitatea riscului ca probabilitate (numr subunitar). n acest caz, valoarea riscului va reprezenta costul ateptat (expected cost). Se pot compara aadar valorile riscului pentru a evalua iportana relativ a riscurilor.

Muli manageri folosesc o metod prin care se dau scoruri riscurilor, pentru a oferi o msur cantitativ pentru evaluarea fiecrui risc. Un scor ar putea fi mprirea 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 apariie e unei erori). Msurile de impact, notate pe o scar similar, trebuie s ia n consideraie riscul total al proiectului. Acesta trebuie s includ urmtoarele costuri poteniale: costul ntrzierilor fa de datele planificate pentru deliverables; supracostul datorat de folosirea adiional a unor resurse;

n tabelul urmtor se d un exemplu de calcul a valorii riscului pentru un anumit proiect.

Acordarea de prioriti riscurilor Managerii folosesc dou strategii: reducerea valorii riscului prin reducerea probabilitii riscului sau a impactului riscului; realizarea unor planuri de rezerv (care s ia n calcul ntmplri neprevzute), astfel nct, dac riscurile apar, s fie gestionate. Oricare dintre aceste strategii vor avea un cost asociat. De aceea e important acordarea de proriti riscurilor, pentru ca cele mai importante s primeasc atenia cea mai mare. n practic, sunt n general ali factori care trebuie luai n calcul atunci cnd vrem s aranjm n funcie de prioritate: Riscuri acumulate. Cnd se ntmpl acest lucru, riscurile trebuie tratate ca i cum ar fi un singur risc. Numrul riscurilor. Exist un numr maxim de riscuri ce trebuie considerate efectiv de un manager

 Costul aciunii. Anumite riscuri, o dat identificate, pot fi reduse sau evitate imediat cu un cost redus. Pentru alte riscuri trebuie s comparm costurile cu efectuarea aciunii cu beneficiile reducerii riscului. O metod e s se calculeze risk reduction leverage (RRL):

RRL =

REina int e REdupa cos t reducere risc

unde REinainte e valoarea riscului original, REdupa este valoarea riscului ateptat dup trecerea la aciune, iar cost reducere risc este costul implementrii aciunii de reducere a riscului.

5. Reducerea riscurilor
n linii mari, exist 5 strategii de reducere a riscului: Prevenirea hazardului. Reducerea probabilitii de apariie. 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 artate riscuri i msuri de reducere a acestor riscuri, aa 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 ateptm pentru ca sarcina s se desfoare n circumstane normale. l notm cu m. Optimistic time cel mai scurt timp n care ne ateptm c completm activitatea. l notm cu a. Pessimistic time cel mai prost timp pentru completarea activitii. l notm cu b. Timpul ateptat (te) obine cu relaia:

a + 4m + b te = 6

Exemplu. Se consider tabelul de mai jos, cu estimrile timpului activitilor folosind estimatorii PERT:

Reeaua PERT prezentat pe pagina urmtoare ne arat c se ateapt ca proiectul s dureze 13,5 sptmni.

T te

Convenia de notare n reeaua PERT

s

Reeaua PERT pentru activitile prezentate n tabelul precedent

O msur cantitativ a gradul de incertitudine a unui estimator de timp pentru o activitate se obine calculnd deviaia standard s:

ba s= 6
Tabelul cu estimatorii PERT se completeaz cu deviaia standard i va arta astfel:

Avantajul tehnicii PERT este c ofer o metod pentru estimarea probabilitii de a respecta sau rata datele planificate ale diverselor sarcini. S presupunem c vrem s completm proiectul n 15 sptmni, dar ne ateptm s ne ia 13,5 sptmni. Poate lua mai mult sau mai puin. n plus, s presupunem c activitatea C trebuie completat pn n sptmna a 10-a. n plus, evenimentul 5 reprezint livrarea produsului intermediar ctre client.

Tehnica PERT folosete o metod n 3 pai pentru a calcula probabilitatea de a respecta sau nu data int:
1. 2. 3.

se calculeaz deviaia standard pentru fiecare eveniment al proiectului; se calculeaz valoarea z pentru fiecare eveniment care are o dat int; se convertete valoarea z la probabilitate. Deviaia standard pentru evenimentul 3 depinde doar de activitatea B. De aceea deviaia standard va fi 0,33. Pentru evenimentul 5 exist dou ci posibile, B+E sau F. Deviaia standard total pentru calea B+E este

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

iar pentru F este1,17. Prin urmare, deviaia standard pentru evenimentul 5 este 1,17 (cea mai mare dintre ele).

Calcularea valorii z Valoarea z se calculeaz pentru fiecare nod care are o dat int, cu formula de mai jos, n care T este data int, iar te este data ateptat:

z=

T te s

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

Convertirea valorii z la probabiliti Se poate face folosind tabelele cu valorile lui z, care se gsesc n majoritatea crilor de statistic sau cu un grafic ce reprezint echivalentul tabelelor.

Simularea Monte Carlo Baza acestei tehnici este calcularea timpilor evenimentelor de un numr mare de ori, fiecare timp selectnd timpii activitii aleator dintr-o mulime de estimri pentru fiecare activitate. Rezultatele sunt apoi tabulate, sumarizate sau afiate ca grafic, aa cum se arat n figura de mai jos.

Managementul riscului
- Laborator -

Problema 1. Se consider tabelul de mai jos, care conine o list cu riscurile identificate, mpreun cu probabilitatea, impactul i valoarea fiecrui risc:

Cum se poate reduce probabilitatea sau impactul fiecrui risc?

Problema 2. Se consider tabelul de mai jos, care conine estimatorii de timp a, m i b pentru diversele activiti. Calculai timpul ateptat pentru fiecare activitate, te

s=0.5 s=0.33 s=0.17 s=0.25 s=0.5 s=1.17 s=0.33 s=0.08

Problema 3. Se consider reeaua PERT de mai jos. Calculai pentru deviaia standard pentru fiecare dintre evenimentele A,B,C,D,E,F,G,H.

Indicaie. Semnificaia grafic este urmtoarea:

Problema 4. Se consider reeaua PERT de mai jos. Calculai valorile z pentru fiecare dintre evenimentele cu date int din reea.

Problema 5. Se consider graficul de mai jos, care ajut la convertirea

valorii z la probabiliti, pentru reeaua de activiti de la problemele 3 sau 4. Calculai riscul ca proiectul s nu se termine n sptmna a 15-a. Calculai probabilitatea de a nu se realiza activitile 4 i 5 la sfritul sptmnii a 10-a.

Indicaii i rspunsuri

Problema 1. Se consider tabelul de mai jos, care conine o list cu riscurile

identificate, mpreun cu probabilitatea, impactul i valoarea fiecrui risc:

Indicaie.
R2 revizuii estimrile sau mprii activitatea n componente mai mici i facei estimri pentru acele componente. R4 gndii 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 conine estimatorii de timp

a, m i b pentru diversele activiti. Calculai timpul ateptat pentru fiecare activitate, te

Indicaie.

4 2.83 4.08 2.83 3 2.08

Problema 3. Se consider reeaua PERT de mai jos. Calculai pentru deviaia

standard pentru evenimentele 4 i 6.

Indicaie. Evenimentul 4. Calea A+C are deviaia standard

Calea B+D are deviaia standard

0,50 2 + 0,17 2 = 0,53 0,332 + 0,252 = 0,41

Nodul 4 are aadar deviaia standard 0,53.

Problema 4. Se consider reeaua PERT de mai jos. Calculai valorile z pentru

fiecare dintre evenimentele cu date int din reea.

Indicaie.
Valoarea z pentru evenimentul 5 este:

10 10,5 = 0,43 1,17

z4=1,89 z6=1,23

Problema 5. Se consider graficul de mai jos, care ajut la convertirea valorii z

la probabiliti, pentru reeaua de activiti de la problemele 3 sau 4. Calculai riscul ca proiectul s nu se termine n sptmna a 15-a. Calculai probabilitatea de a nu se realiza activitile 4 i 5 la sfritul sptmnii a 10-a.

Indicaie. 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 pn la sfritul sptmnii a 10-a.

Managementul proiectelor mici

1. Introducere
n proiectele mici (specifice activitii de laborator a studenilor) apar anumite probleme: Folosirea instrumentelor nefamiliare Cerine de design vag formulate Dac de exemplu proiectul de ntinde pe 10 sptmni, ar fi bine de planificat pe o durat mai mic (9 sptmni). Planificarea activitilor ar putea fi urmtoarea: - sptmnile 1-2: analiza; - sptmna 3: designul; - sptmnile 4-7: construirea sistemului; - sptmnile 8-9: testarea i evaluarea; - sptmna 10: sptmn de rezerv

Sisteme incomplete Avnd n vedere timpul scurt, e posibil ca sistemul care trebuie proiectat s nu fie funcional. De aceea se recomand ca lucrurile s fie de aa natur gndite, nct s existe ceva concret de artat chiar din fazele incipiente ale proiectului. n acest schelet al proiectului, ar fi o idee bun s existe anumite funcionaliti vizibile. S pot aduga alte funcionaliti pe msura trecerii timpului. O sugestie ar fi s folsoii modelul incremental (vezi Modele de procese software), astfel nct dac de exemplu avei 3 incremente i al treilea nu este finalizat, exist totui celelalte dou. Sfat: documentarea proiectului e bine s fie fcut pe msur ce se avanseaz cu etapele proiectului, mai bine dect s documentai proiectul la sfrit, din cauza lipsei de timp. Lipsa interesului din partea clienilor Studentul nu va fi (probabil) pltit pentru proiectul fcut. Avantajul acestei situaii este c o organizaie din afar ar putea fi interesat de ansa de a avea o resurs free.

2. Coninutul unui plan de proiect

n proiectele mici e bine s urmai urmtorul 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 conin: identificarea clientului pentru cine se face proiectul (inclusiv dac e pur didactic cui s-ar putea adresa); o scurt descriere a proiectului cel mult cteva paragrafe; identificarea autoritii de proiect persoana sau persoanele din cadrul organizaiei clientului care va avea autoritate peste evoluia proiectului.

B) Background Aceast parte ar trebui s conin: informaii relevante despre mediul software/hardware existent; circumstanele sau problemele care conduc la proiect; munca din aria proiectului dus deja la bun sfrit; stakeholders din proiect (adic toi cei care vor fi afectai de proiect sau care sunt interesai de el). C) Obiectivele proiectului Obiectivele trebuie s defineasc ce ar trebui s se realizeze i metoda de msurare a acestei creaii. La proiectele studeneti, evaluarea e fcut (de cele mai multe ori) din punct de vedere didactic. Dac ns aceast documentare e fcut i n beneficiul clientului, atunci punctul de vedere al clientului trebuie s fie prezent. Dac sunt multe obiective, ar trebui specificat prioritatea lor.

D) Constrngeri De obicei se trec la partea cu obiectivele proiectului. Constrngerile includ: scri de timp impuse din exterior; cerinele legale; standarde specifice; limitri ale persoanelor care pot fi abordate pentru informaii. 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, documentaie, ghiduri utilizator, rapoarte.

G) Activiti Trebuie precizat lista cu principalele activiti pe care le implic proiectul. Fiecare activitate trebuie precizat n termeni concrei: 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; activitile dependente, adic acele activiti ce necesit terminarea acestei activiti curente pentru a ncepe; timpul / efortul estimat, ntr-o anumit marj; detalii despre cum vor fi verificate i validate produsele activitii. Se pot include aici i tabelele Gantt pentru monitorizarea activitilor (sau alte instrumente specifice monitorizrii).

H) Resurse Se pot include aici cerinele software / hardware i cele legate de personal. I) Analiza riscului Se identific principalele lucruri care ar putea merge ru. n mod normal, acestea ar putea include: indisponibilitatea resurselor; indisponibilitatea personalului; probleme tehnice (cum ar fi bugs-urile software). Se aloca fiecrui risc o evaluare a probabilitii (not ntre 1-10) i o not pentru impactul fiecrui risc (tot ntre 1-10). nmulind cele dou note, se obine un scor de ansamblu. Pentru riscurile mari, e bine s se specifice i eventualele msuri pentru reducerea acelor riscuri.

Concluzii

atenie

la instrumentele sau tehnologiile noi;

trebuie ajustate obiectivele proiectului, astfel nct proiectul s nu depeasc timpul alocat; nu trebuie confundate obiectivele proiectului cu

obiectivele personale; evitai activitile pentru care nu exist rezultate tangibile

Monitorizarea i controlul

1. Introducere
Asigurarea progresului proiectului necesit monitorizarea a ceea ce se ntmpl, compararea realizrilor concrete fa de cele planificate i, acolo unde se impune, revizuirea planurilor i replanificarea pentru a aduce proiectului pe linia dorit. n aceast prezentare, artm cum se pot gestiona situaiile n care se schimb cerinele.

2. Crearea cadrului de lucru (framework)

Figura alturat 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: ntrziere fa de datele planificate, calitate ndoielnic, funcionalitate inadecvat i costuri mai mari dect cele planificate.

Responsabilitate Rspunderea global pentru asigurarea progresului unui proiect este adesea rolul unui Project Board. Responsabilitatea zi-de-zi va rmne n grija managerului de proiect i, n majoritatea proiectelor, se pot delega responsabiliti 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. Cteva exemple sunt date n tabelul de mai jos. Categorii de raportare

Tip de raportare
Oral formal regulat Oral formal ad-hoc

Exemple
Sptmnal sau lunar End-of-stage review meetings

Comentarii
Se pot pstra anumite notie formale scrise Se pot primi sau genera rapoarte scrise

Scris formal regulat Rapoarte privind De obicei sptmnale progresul, foi de calcul folosind formulare Oral informal ad-hoc Rapoarte de excepie Oral informal ad-hoc Interaciuni sociale Adesea ofer avertismente timpurii

Evaluarea progresului Se face n mod normal pe baza informaiilor colectate la intervale regulate sau atunci cnd apar evenimente specifice. Unde e posibil, aceste informaii vor fi obiective i tangibile.

Taking snap-shots Frecvena cu care managerul are nevoie s primeasc informaii despre progresul proiectului depinde de mrimea i gradul de risc al proiectului. Liderii de echip trebuie s evalueze progresul zilnic (mai ales cnd lucreaz cu personal neexperimentat), n timp ce managerii de proiect gsesc mai potrivit s primeasc rapoarte sptmnale sau lunare.

3. Adunarea datelor
Ca o regul, managerii vor ncerca s mpart activitile lungi n sarcini mai controlabile ce se ntind pe o sptmn sau dou. Totui va fi necesar s se adune informaii despre activitile parial completate i, n particular, estimri despre ct munc mai e necesar pentru a le completa. Uneori poate fi dificil s se fac astfel de estimri de mare acuratee. Exerciiu. 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 programrii 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, dei nu reprezint produsul final al activitii de codare i testare.

Raportarea pariale

completrii

Multe organizaii folosesc un sistem de msurare standard. Figura alturat nfieaz un exemplu tipic de un formular de raportare, n acest caz cernd informaii despre abaterea probabil fa de datele de completare, ca i estimri ale completrii.

4. Vizualizarea progresului
Colectarea datelor despre progresul proiectului se pot prezenta ntr-o form atractiv. n cele ce urmeaz, s eprezint cteva dintre aceste metode de prezentare.

(Henry Gantt 1861-1919, inginer)

Tabele

Gantt

E o tehnic simpl i veche, care indic ntr-o diagram datele activitilor planificate. Progresul raportat e nregistrat pe diagram.

Slip chart E o alternativ folosit de unii manageri de proiect care cred c ofer o indicaie vizual mai clar a acelor activiti care nu progreseaz n raport cu planificarea. O slip line cu muli zimi indic necesitatea replanificrii. Slip line

Ball charts n figura de mai jos, cercurile indic punctele de start i de completare pentru activiti. Iniial cercurile conin datele planificate originale. Ori de cte ori se produc revizuiri, acestea sunt adugate ca date secunde n cercul corespunztor pn cnd o activitate e nceput n realitate sau completat cnd datele relevante nlocuiesc prognozele revizuite (ngroat nclinat n figur).
Cnd datele de ncepere real sau de terminare pentru o activitate sunt ntrziate fa de data int, cercul e colorat rou (gri nchis n figur), iar cnd data real e la timp sau mai devreme dect cea planificat cercul e colorat n verde (gri deschis n figur).

Timeline chart E o metod de a nregistra i afia felul n care intele s-au schimbat pe ntreaga durat a proiectului. n figura de mai jos se arat un timeline chart pentru un proiect la sfritul celei de-a asea sptmni. Timpul planificat e reprezentat pe axa orizontal i timpul scurs pe axa vertical. Liniile erpuite din diagram reprezint datele de completare a activitii planificate la nceputul proiectului analyse existing system e planificat s fie completat pn marea (Tuesday) din sptmna a 3-a, obtain user requirements pn joia (Thursday) din sptmna a 5-a, issue tender, activitatea final, pn marea din sptmna a 9-a s.a.m.d. La sfritul primei sptmni, managerul revede aceste date int i le las aa cum sunt. La sfritul sptmnii a 2-a, managerul decide c obtain user requirements nu va fi completat pn marea din sptmna a 6-a de aceea managerul extinde linia activitii diagonal ca s reflecte aceasta. Celelalte inte de completare a activitii sunt ntrziate corespunztor. n marea din sptmna a 3-a, e completat analyse existing system i managerul pune un cercule pe diagonal pentru a indica c asta s-a ntmplat. La sfritul sptmnii a 3-a managerul decide s pstreze intele existente. La sfritul sptmnii a 4-a adaug alte trei zile pentru draft tender i issue tender.

De observat c la sfritul sptmnii a 6-a, sunt completate 2 activiti i 3 sunt nc nefinalizate. Proiectul pe ansamblu va avea 7 zile de ntrziere.

5. Monitorizarea costurilor
O diagram ca cea din figura de mai jos ofer o metod simpl de comparare a cheltuielilor planificate cu cele reale. n sine, nu indic dac nu cumva, dei pare s existe economii fa de bugetul planificat, proiectul este mult ntrziat i de aceea graficul arat aa.

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 informaiile adiionale disponibile n momentul n care se include i estimarea revizuit a costurilor.

6. Earned Value
Earned Value Analysis a ctigat popularitate n ultimii ani i poate fi vzut ca o rafinare a monitorizrii costurilor, discutat anterior. Earned Value Analysis se bazeaz pe asignarea unei valori fiecrei 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 nenceput are asignat valoarea 0 i cnd e completat, ea, precum i proiectul, e creditat cu valoarea sarcinii. Valoarea total a proiectului n orice punct e cunsocut sub denumirea de earned value sau BCWP (budgeted cost of work perfromed) i poate fi reprezentat ca o valoare sau ca procent al BCWS. Cnd 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 pn n momentul n care e completat, cnd 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% cnd e complet; tehnica milestone o sarcin are o valoare asignat pe baza realizrii milestones care au asignat valori ca parte a planului alocat original.

Baseline budget E bazat pe planul proiectului i arat creterea prognozat n timp a earned value. Earned value poate fi msurat n valori monetare, dar n cazul proiectelor de dezvoltare de software e mai obinuit s se msoare n ore de munc pe persoan (person-days) sau zile de munc (workdays).

Exemplu. Baseline budget e reprezentat n tabelul alturat i ilustrat n diagrama de pe pagina urmtoare. Se bazeaz pe zile de munc i folosete tehnica 0/100.

Proiectul nu ateapt s aib o earned value pn n ziua 34.

Monitorizarea earned value Monitorizarea earned value e o msur a progresului proiectului. Acest lucru e fcut prin monitorizarea completrii sarcinilor. n figura de mai jos se arat analiza earned value la nceputul sptmnii a 12-a a proiectului.

La fel de bine ca nregistrarea BCWP, costul real al fiecrei sarcini poate fi exprimat ca ACWP (actual cost of work performed), care e artat 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 msoar 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 planificrii; Cost variance: e calculat ca BCWP-ACWP i indic diferena 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 dect era planificat, n timp ce o valoare mai mic dect 1 nseamn c munca a costat mai mult dect a fost planificat i/sau c se merge mai ncet dect a fost planificat.

7. Modificri n control

Pn acum s-a presupus c natura sarcinilor nu s-a schimbat. n realitate sunt situaii cnd cerinele se modific din cauza schimbrii circumstanelor sau pentru c utilizatorii i fac o idee mai clar despre ceea ce doresc de la software. Pe de alt parte, exist situaii interne, cum ar fi inconsistenele n specificaiile programului care devin evidente numai atunci cnd se scrie codul.

Rolul Configuration librarian Controlul schimbrilor i documentaia ar trebui s fie reponsabilitatea cuiva care se numete Configuration Librarian, Configuration Manager sau Project Librarian. Printre sarcinile pe care o asemenea persoan le are: identificarea tuturor itemilor care ar putea fi subiectul unor schimbri; stabilirea i meninerea unui depozit central ale copiilor principale ale ntregii documentaii a proiectului i produselor software; stabilirea i rularea unei mulimi formale de proceduri care s se ocupe de schimbri; meninerea unor nregistrri cu cine are acces la ce itemi ai bibliotecii i statusul fiecrui item al bibliotecii (ex: dac este n dezvoltare, n testare sau livrat).

Schimbarea procedurilor de control

O procedur simpl de control al schimbrilor pentru sistemele operaionale ar putea avea urmtorii pai:

Monitorizare i control
- Laborator -

Problema 1. Se consider planificarea proiectului dat n figura de mai jos. Identificai acele activiti programate s dureze mai mult de 3 sptmni i descriei cum poate monitoriza progresul pentru fiecare dintre ele.

Problema 2. n tabelul Gantt de mai jos, identificai activitile ntrziate. Ce efect au acestea asupra desfurrii proiectului? Cum poate atenua efectul ntrzierii?

Problema 3. La sfritul sptmnii a 8-a, managerul observ c Plan office layout e complet, dar Draft tender (pus n eviden n figur) o s ia cu o sptmn mai mult dect anticipase iniial. Cum va arta chart-ul la sfritul sptmnii a 8a? Dac proiectul va merge conform planificrii refcute, cum va arta chart-ul la sfritul proiectului?

Problema 4. O schimbare n specificaia programului se va reflecta n schimbrile fcute n designul programului i apoi n codul schimbat. Ce alte elemente vor trebui s sufere modificri?

Indicaii i rezolvri

Problema 3. La sfritul sptmnii a 8-a, managerul observ c Plan office layout e complet, dar Draft tender (pus n eviden n figur) o s ia cu o sptmn mai mult dect anticipase iniial. Cum va arta chart-ul la sfritul sptmnii a 8a? Dac proiectul va merge conform planificrii refcute, cum va arta chart-ul la sfritul proiectului?

Problema 3. La sfritul sptmnii a 8-a, managerul observ c Plan office layout e complet, dar Draft tender (pus n eviden n figur) o s ia cu o sptmn mai mult dect anticipase iniial. Cum va arta chart-ul la sfritul sptmnii a 8a? Dac proiectul va merge conform planificrii refcute, cum va arta chart-ul la sfritul proiectului?

Problema 4. O schimbare n specificaia programului se va reflecta n schimbrile fcute n designul programului i apoi n codul schimbat. Ce alte elemente vor trebui s sufere modificri? Indicaie. Printre itemii cel mai probabil s sufere modificri sunt datele de testare, rezultatele ateptate i manualul de utilizare.

Software design
- concepte, exemple -

1. Introducere
Design-ul este the process of applying various techniques and principles for the purpose of defining a device, a process, or a system in sufficient detail to permit its physical realization. (Taylor, An Interim Report of Engineering Design, MIT, 1959) Procesul de design convertete ce din cadrul cerinelor 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 fr o viitoare interaciune cu utilizatorul. Procesul de design convertete de asemenea terminologia din spaiul problemei al cerinelor la spaiul soluie al implementrii. Unii autori vorbesc de obiectele OOA (Object-Oriented Analysis), care sunt n spaiul problem/domeniu i de obiectele OOD (Object-Oriented Design), care sunt n spaiul soluie/implementare.

Se vorbete despre fenomenon n mediul nconjurtor (lumea) i de fenomenon n implementare (main). Un fenomenon poate fi vizibil sau ascuns. Cerinele orientate pe utilizator pot fi exprimate n termeni de fenomenon, vizibil sau ascuns, din mediu (environment). (Gunter, Gunter,
Jackson, and Zave, A Reference Model for Requirements and Specifications, IEEE Software, May/June 2000)

Exemplu. Identificai ce fenomenon este n mediu i ce fenomenon n implementare n sistemul care gestioneaz mprumutul de cri ntr-o bibliotec. (vezi model_biblioteca)
Soluie. Cartea propriu-zis este un fenomenon ascuns al mediului (environment-hidden). Cnd bibliotecarul scaneaz cartea, scaneaz de fapt un cod de bare. Codul de bare nu conine ISBN-ul, dar trebuie s reflecte eventualele copii multiple ale unei singure cri. Acest code de bare este un fenomenon vizibil al mediului. Implementarea folosete probabil un identificator sau pointer pentru datele referitoare la carte. Acest identificator intern este un fenomenon ascuns al implementrii. Specificarea pentru dezvoltare trebuie s fie scris n termeni de cod de bare.

2. Fazele procesului de design

Data design (designul de date) aceast faz produce the structurile de date. Architectural design (designul arhitecturii) aceast faz produce the unitile structurale (clasele). Interface design (designul interfeelor) aceast faz specific interfeele dintre uniti. Procedural design (designul procedural) aceast faz specific algoritmii fiecrei metode. Exemplu. Realizai designul claselor i al structurilor de date pentru sistemul de gestiune a mprumutului de cri dintr-o bibliotec.
Soluie. Atenia este concentrat pe mprumutul crilor i mai puin pe alte informaii, cum ar fi catalogarea, administrarea, retragerea crilor i administrarea clienilor bibliotecii. Identitatea carte se va combina cu identitatea copie n structura de clase/date pentru stocarea informaiilor despre o copie. Poate conine ISBN-ul i un numr de copie ca unic identificator. Informaiile despre cititori se vor pstra ntr-o structur de date secundar, n care probabil fiecare nregistrare va fi identificat printr-un ID unic (poate fi CNP-ul). Informaiile referitoare la mprumut pot fi puse ntr-o structur de date separat sau nu.

Diagrama de clas

2.1 Interfeele
Interfaa 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 situaie. Trebuie s fie complet pentru ca cel care implementeaz s tie exact ce informaii sunt necesare. Exemplu. Realizai designul interfeelor pentru functiile imprumutare din diagrama de clase de mai sus.
Soluie. Clasele cititor i copiecarte au o metod imprumutare. Este de presupus c apelul oricreia dintre aceste metode va instania clasa imprumut. method cititor::imprumutare input parameters isbn return type int 0 dac nu este disponibil cartea 1 dac este disponibil cartea i instana imprumut se creeaz cu succes -1 dac apare o condiie de eroare method copiecarte::imprumutare input parameter NrImprumut return type int 0 dac nu e disponibil copia 1 dac e disponibil copia

3. Concepte ale designului

Refinement (rafinare) dezvolt designul prin rafinri succesive; se mai numete designul top-down. Modularity (modularitate) e o abordare care divide software-ul n componente mai mici, care apoi sunt integrate. Exemplu. Rafinai funcia imprumutare din sistemul de mprumutare cri de la o bibliotec, prezentat n exemplele anterioare.
Soluie. Pe primul nivel de design, ncepem printr-o funcie imprumutare care are doi parametri: titlul crii i numele cititorului. La urmtorul nivel, se adaug noiunea de entitate mprumut, care (probabil) are dou pri: caut cartea cu titlul specificat, caut cititorul cu numele dat i creeaz o instan de mprumut pe baza ID-urilor crii i cititorului. Urmtoarea rafinare expandeaz fiecare parte de mai sus. gasesteCarte returneaz ISBN dac e gsit i e disponibil cartea, returneaz 0 dac nu e gsit i returneaz -1 dac acea carte e dat. gsesteCititor returneaz IDcititor dac cititorul e gsit, 0 dac cititorul nu e gsit i -1 dac cititorul nu poate mprumuta cartea. creeazaImprumut returneaz 1 dac e creat cu succes.

3.1 Atribute ale designului

Abstraction (abstractizare) un obiect e abstract dac detaliile nenecesare sunt ascunse. Cohesion (coeziune) o procedur e coeziv dac toate declaraiile 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 cnd toate elementele sale sunt n legur unele cu altele. Coupling (cuplare) e o msur a ct de interconectate sunt modulele ntre ele. Dou module sunt cuplate dac modificarea unei variabile ntrunul dintre module necesit schimbri n cellalt modul. E de dorit o cuplare slab ntre module. Exemplu. Evaluai abstractizarea n funcionalitatea mprumutului din sistemul de gestionare a mprumuturilor de cri dintr-o bibliotec.
Soluie. Funcia imprumutare apare n 3 module: bibliotec, cititor i copiecarte. Cea mai bun abstractizare se atinge atunci cnd funcia imprumutare din modulul biblioteca cunoate ct mai puine detallii cu putin despre funciile imprumutare din clasele cititor i copiecarte.

Aa cum se arat n figura de mai sus, dac funcia imprumutare din modulul biblioteca doar apeleaz funcia imprumutare, atunci exist o bun abstractizare.

Dac funcia imprumutare din modulul biblioteca tie despre clasa imprumut, poate verifica disponibilitatea crii, poate crea instana imprumut i poate apela funciile imprumutare pentru a seta valorile instanei imprumut.

Aa cum se arat n figura de mai sus, abstractizarea nu e bun. De ce?

4. Msurarea coeziunii
4.1 Feliile unui program (program slices)
Valorile unei variabile ntr-un program depind de valorile altor variabile. Exist dou tipuri de dependene: data dependencies, n care valoarea lui x afecteaz valoarea lui y prin definiie; control dependencies, n care valoarea lui x determin dac se execut codul care conine definiiile lui y. Exemplu. nmulirea prin nsumare repetat: S se calculeze x*y. Valoarea de ieire z are data dependency fa de x, deoarece x se adun la z i are control dependency fa de y, deoarece controleaz de cte ori de adun x la z.
z = 0; while x > 0 do z = z + y; x = x 1; end-while

Program slices pot fi obinute din ambele direcii. Output slices gsesc fiecare instruciune care afecteaz valoarea unei ieiri (output) specificate. Input slices gsesc fiecare instruciune care e afectat de valoarea unui input specificat. Sunt uor de determinat program slices, pornind de la un graf orientat, n care are o mulime de vrfuri n, fiecare vrf reprezentnd un input, un output sau o instruciune de cod. Arcurile e sunt dependenele. James Bieman i Linda Ott au utilizat definiii de variabile i referine ca uniti de baz, n loc de instruciuni de program (program statements). Aceste definiii i referine se numesc tokens. De aceea, orice referin de constant (constant reference), referin de variabil (variable reference) i definiie de variabil reprezint un token separat (James Bieman, Linda Ott,
Measuring Functional Cohesion, IEEE TOSE, 20:8 August 1994)

Exemplu. Desenai un graf orientat pentru codul din exemplul precedent:

z = 0; while x > 0 do z = z + y; x = x 1;end-while Soluie. Vom folosi linie continu pentru data dependencies i linie punctat pentru control dependencies.

Un input slice poate ncepe cu variabila de intrare x. Tokens x, 0, x, x, i 1 din instruciunile while x>0 i x=x-1 se adaug la slice. Apoi se adaug tokens z, z i y din instruciunea z=z+y. Nici un alt token nu mai poate fi adugat. De aceea, input slice e tot mai puin z=0. Un input slice pentru variabila y va conine tokenul iniial y i tokens z i y din instruciunea z=z+y.

4.2 Glue tokens

Bieman i Ott au definit, de asemenea, anumite metrici de coeziune utiliznd output slices. Definiiile sunt bazate pe glue tokens, care sunt tokens (sectiun de cod) care se gsesc 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 conine token. Exist trei functional cohesion measures: Weak functional cohesion (WFC)raportul glue tokens la total tokens Strong functional cohesion (SFC)raportul superglue tokens la total tokens Adhesiveness (A)media adezivitii tuturor tokens

Exemplu. Calculai functional cohesion measures pentru urmtorul 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; }
Soluie. n figura de pe pagina urmtoare din fiecare token ctre toate tokens care sunt afectate imediat de valoarea token-ului.

Graf orientat artnd toate dependenele

Nu sunt superglue tokens, aadar strong functional cohesion (SFC) este zero. Din cei 31 tokens, sunt 12 glue tokens, deci weak functional cohesion este 12/31 sau 0.387. Sunt patru slices. Zero tokens au adezivitate 100%. Patru tokens sunt n trei slices, aa nct au adezivitate 100%. Opt tokens sunt n dou slices, aa nct au adezivitate 50%. Tokens rmai, 19, sunt doar ntr-un slice, aa nct au adezivitate 25%. Adezivitatea este media adezivitii tuturor tokens, deci (4*0,75+8*0,50+19*0,25)/31=11,25/31=0,363

5. Msurarea cuplrii (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 urmtoarea list de situaii pentru numrare: di = Numrul de parametri de date de intrare ci = Numrul de parametri de control de intrare do = Numrul de parametri de date de ieire (output data parameters) co = Numrul de parametri de control de ieire (output control parameters) gd = Numrul de variabile globale folosite ca date gc = Numrul de variabile globale folsoite ca control w = Numrul de module apelate (fan-out) r = Numrul de module apelante a modului fan-in) Indicatorul de cuplare a modulelor (module coupling indicator) a lui Dharma se definete astfel:

6. Requirements traceability (gradul de urmrire a cerinelor)

Requirements traceability ncearc s lege fiecare cerin (requirement) de un element de design care s satisfac cerina. Cerinele trebuie s influeneze designul. Dac o cerin nu are o parte corespondent a designului sau o parte a designului nu are o parte corespondent n cerine, exist o potenial problem. Evident, anumite pri de design pot fi att de generale, nct nici o parte a cerinelor nu se reflect n acea seciune. Unele cerine, pe de alt parte, s-ar putea s nu aib pri specifice n design care s oglindeasc aceste cerine. O abordare pentru determinarea gradului de urmrire a cerinelor (traceability) este s desenm o matrice. Pe o ax sunt listate toi itemii despre cerine, iar pe cealalt va fi lista cu itemii legai de design. Un semn va fi plasat acolo unde un item de design ndeplinete o cerin.

Exemplu. Desenai o matrice pentru urmtoarea problem: Tom i Sue pregtesc o pensiune ntr-un ora. [1] Ei vor avea 3 dormitoare pentru oaspei. [2] Vor un sistem care s gestioneze [2.1] rezervrile i s monitorizeze [2.2] cheltuielile i profitul. Cnd un client potenial 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] preul negociat, [6.6] nr.credit card i [6.7] nr.camerei. Rezervarea trebuie [7] garantat prin plata [7.1] primei zile. Rezervrile vor fi inute fr garanie [7.2] o perioad stabilit. Dac nu se ofer garania pn la acea zi, rezervarea va fi [7.3] anulat.

Aa cum se arat n tabelele anterioare, exist un numr de linii i coloane albe. Cerina 5 se leag de locuri libere. Nu exist o tratare explicit a locurilor libere, dei un loc liber ar trebui s fie absena unei rezervri ntr-o zi anume. Cerina 6.3 se refer la telefonul clientului i lipsete. Cerina 6.5, legat de preul negociat i lipsete din informaiile privind rezervarea. Cerina 7.1 menioneaz 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 cutarea 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 tranzaciei, care sunt neglijate la cerine.

Exemplu. Construii un model pentru o bibliotec. Soluie. Obiectele sunt biblioteca, cri, copii ale crilor i cititori. ntre biblioteca i carte, ca i ntre bibliotec i cititor exist o relaie de agregare. ntre carte i copiecarte nu e nici agregare, nici motenire, deoarece obiectul carte reprezint abstracia unei cri, n timp de copiecarte este itemul concre (fizic) care se mprumut.

inapoi

Software design
- laborator -

Exerciiul 1. Se d urmtorul design. Analizai cuplarea, coeziunea, abstractizarea.

Exerciiul 2. Se consider un sistem de recunoatere facial bazat pe procesare de imagini. Sistemul va avea o camer i intenioneaz s previn persoanele strine s intre n zonele secrete ale companiei, prin controlul uii (blocarea ei). Cnd o persoan ncearc s rsuceasc mnerul uii, sistemul preia imaginea persoanei i o compar cu imaginile din baza de date. Clasificai fiecare dintre urmtoarele evenimente (i.e. dac sunt n mediu environment sau n sistem i dac sunt ascunse sau vizibile: 1. O persoan ncearc s rsuceasc mnerul uii. 2. Ua e deblocat de sistem. 3. Un angajat las un strin pe u. 4. Un anagajat are un geamn identic. 5. O imagine are un numr minim de similariti pentru algoritmul de potrivire (matching algorithm).

Exerciiul 3. Calculai functional cohesion metrics (Bieman, Ott) pentru fragmentul de cod de mai jos. Desenai graful orientat.

Exerciiul 4. Desenai scenariile pentru interaciunea dintre un client care ncearc s cumpere un anumit CD cu muzic i vnztorul din magazin. Folosii state machine model. Pe arce s fie reprezentate evenimentele. Indicaie. Mai jos e prezentat cea mai simpl situaie, cnd vnztorul intr n magazin, nu gsete CD i pleac din magazin. Completai i variantele celelalte.
Completai...

Indicaii i soluii

Soluie exerciiul 1. Cuplare se dorete cuplare slab i acest design are cuplare slab, deoarece clasa college nu are cunotine despre alctuirea altor clase i alte clase nu trebuie s tie despre college. Coeziune e de dorit o coeziune mare i designul are coeziune mare, deoarece fiecare clas lucreaz cu propriile atribute. Abstractizare designul are o bun abstractizare. De exemplu, metoda display din college nu include detalii despre metodele lower-level de afiare.

Soluie exerciiul 2. 1. 2. 3. 4. 5. O persoan ncearc s rsuceasc mnerul uii. - EV Ua e deblocat de sistem. - SV Un angajat las un strin pe u. - EH Un anagajat are un geamn identic. - EH O imagine are un numr minim de similariti pentru algoritmul de potrivire (matching algorithm). SH

Soluie exerciiul 3.

Soluie exerciiul 3 (continuare).

Soluie exerciiul 3 (continuare).

Sunt 33 tokens. Patru

sunt superglue. ase (incluznd 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%

Soluie exerciiul 4.

Testarea software-ului

1. Introducere

Testarea software-ului se face rulnd software-ul cu date de test. Se mai numete 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.

Dei exist diverse tehnici pentru validarea software-ului, executarea datelor cu date de test reprezint un pas necesar.

2. Noiuni fundamentale
Testarea exhaustiv este executarea fiecrui 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 intrri de tip ntreg pe 32 bii conduc la un numr de 264cazuri de testare posibile). Exist dou criterii de baz privind testarea software: 1. ce cazuri de testare s folosim (test case selection) 2. cte cazuri de testare sunt necesare (stopping criterion) Test case selection se poate baza pe: specificaii (functional); structura codului (structural); fluxul datelor (data flow); o selecie aleatoare a cazurilor de testare (random). Obs. Test case selection poate fi vzut ca o ncercare de dimensionare a cazurilor de testare prin intermediul intrrilor.

Stopping criterion se poate baza pe: criteriu de acoperire (coverage criterion), cum ar fi executarea a n cazuri de testare n fiecare subdomeniu; criterii comportamentale (behavior criteria), cum ar fi testarea pn o rat a erorilor e mai mic dect un prag impus. Un program poate fi gndit ca o mapare a spaiului domeniu la un spaiu al rspunsurilor. Dndu-se o intrare (input), care e un punct n spaiul domeniu, programul produce o ieire (output), care e un punct n spaiul rspunsurilor.

Un caz de testare trebuie s includ totdeauna ieirea ateptat (expected output).

3. Test coverage criterion

Test coverage criterion e o regul despre cum s selectm cazuri de testare i cnd s ne oprim. Abordarea standard o constituie folosirea relaiei subsumes.

3.1 Subsumes (includeri)

Un criteriu de testare A subsumeaz criteriul de acoperire a testrii B dac orice test care satisface criteriul A satisface de asemenea criteriul B. Asta nseamn c criteriul de acoperire a testrii A include ntr-un fel criteriul B. Exemplu. Dac un criteriu de acoperire a testrii necesit ca fiecare instruciune s fie executat i alt criteriu de acoperire a testrii necesit ca fiecare instruciune s fie executat plus alte teste adiionale, atunci al doilea criteriu subsumeaz primul criteriu. Obs. O mulime bine aleas de cazuri de testare ce satisfac un criteriu mai slab poate fi mult mai bun dect o mulime aleas mai ru care s satisfac un criteriu mai puternic.

3.2 Testare funcional (functional testing)

Unul din primii pai este generarea unui caz de testare pentru fiecare tip distinct de ieire a programului. De exemplu, fiecare mesaj de eroare trebuie generat. Apoi fiecare caz special ar trebui s aib un caz de test. Situaiile ce ne pot induce n eroare (tricky situations) ar trebuie testate. Greelile comune ar trebui testate. Exemplu. Unul dintre exemplele clasice este urmtorul: pentru trei numere date la intrare, verificai dac aceste numere pot reprezenta laturile unui triunghi i n caz afirmativ precizai natura triunghiului. Soluie. mprim spaiul domeniu n 3 subdomenii, unul pentru fiecare tip de triunghi: oarecare (scalen), isoscel (2 laturi egale) i echilateral (toate laturile egale). Identificm dou situaii de eroare: un subdomeniu cu intrri greite i un subdomeniu n care laturile nu pot forma un triunghi. Fiecare caz de testare trebuie s specifice valoarea output-ului.

Subdomeniu Oarecare:
Mrimi cresctoare Mrimi descresctoare Cea mai mare a doua

Caz de test
(3,4,5 oarecare) (5,4,3 oarecare) (4,5,3 oarecare)

Isoscel:
a=b i c mai mare a=c i b mai mare b=c i a mai mare a=b i c mai mic a=c i b mai mic b=c i a mai mic (5,5,8 isoscel) (5,8,5 isoscel) (8,5,5 isoscel) (8,8,5 isoscel) (8,5,8 isoscel) (5,8,8 isoscel)

Echilateral:
a=b=c (5,5,5 echilateral)

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

Intrri greite:
1 greit 2 greite 3 greite (-1,2,4 date greite) (3,-2,-5 date greite) (0,0,0 date greite)

Obs. Lista subdomeniilor poate fi extins. Un caz de testare n fiecare subdomeniu e soluia minimal, dar acceptabil.

3.3 Matrici de testare

O metod de formalizare a identificrii subdomeniilor este construirea unei matrici folosind condiiile pe care le identificm din specificaie i apoi s identificm toate combinaiile acestor condiii ca fiind adevrate sau false. Se vor folosi toate combinaiile valide de T i F. Dac sunt 3 condiii, vor fi 23=8 subdomenii (coloane). Liniile vor fi folosite pentru valorile lui a, b i c i pentru ieirile prognozate (expected output) pentru fiecare subdomeniu.

Exemplu. Condiiile din problema triunghiului pot fi : (1) a=b sau a=c sau b=c, (2) a=b i b=c, (3) a<b+c i b<a+c i c<a+b, (4) a>0 i b>0 i c>0. Coloanele matricii vor reprezenta un subdomeniu. Pentru fiecare subdomeniu, vom plasa un T n fiecare rnd n care condiia e adevrat i F cnd condiia 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 instruciune a codului ar trebui executat se un caz de testare. Abordarea normal pentru obinerea C0 coverage este selectarea cazurilor de testare pn cnd un instrument de acoperire (coverage tool) indic faptul c toate instruciunile din cod au fost executate. Exemplu. Urmtorul pseudocod implementeaz problema triunghiului. Matricea arat ce linii sunt executate n fiecare caz de test. Primele trei instruciuni (A, B i C) pot fi considerate pri ale aceluiai nod.

3.4.2 Testarea C1-Every-Branch

Pentru modelarea programului cu triunghiul folosind un control flow graph, acest criteriu necesit acoperirea fiecrui 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 ntmpl s fie o cale. n acel exemplu, exist 16 combinaii diferite de T i F. Totui, 8 dintre aceste combinaii sunt ci nerealizabile (infeasible paths), adic nu exist combinaii de T i F pentru deciziile din program. Poate fi extrem de dificil s determinm dac calea e nerealizabil, precum i s gsim un caz de testare care execut acea cale. Multe programe cu bucle vor avea un numr infinit de ci. n general, testarea every-path nu e rezonabil.

3.4.4 Multiple-Condition Coverage

Acest criteriu de testare necesit ca fiecare condiie de relaie primitiv (primitive relation condition) s fie evaluat true i false. n plus, trebuie ncercate toate combinaiile de T/F pentru relaiile primitive ntr-o condiie. E de notat c evaluarea lazy a unei expresii (un compilator e lazy dac, de exemplu, ntr-o expresie cu or prima relaie e true, a doua nu mai e testat) va elimina anumite combinaii. De exemplu, ntr-un and dintre dou relaii primitive, a doua nu va mai fi evaluat dac prima e fals.

Exemplu. n pseudocodul din exemplul de la C0, sunt mai multe condiii multiple. Primitivele care nu se execut din cauza evalurii lazy sunt marcate mai jos cu un X.

3.4.5 Subdomain testing (testarea de subdomeniu)

Se bazeaz pe idee partiionrii domeniul de intrare (input domain) n subdomenii ce sunt mutual excluse i impunerea unui numr de cazuri de testare egal din fiecare subdomeniu. O idee similar se ntlnea n cazul matricii de testare. n acest caz ns nu se restricioneaz modul n care sunt selectate domeniile. Every-statement coverage i every-branch coverage nu sunt subdomain tests. Nu sunt subdomenii mutual excluse n ceea ce privete executarea diferitelor instruciuni sau ramuri. Every-path coverage este un subdomain coverage. Exemplu. Pentru problema triunghiului, putem ncepe cu un subdomeniu pentru fiecare ieire. Acestea se pot subdiviza ulterior n noi subdomenii, n funcie de faptul dac cel mai mare sau elementul greit introdus este n prima poziie, a doua poziie sau a treia poziie.

3.4.6 C1 subsumeaz C0
Exemplu. Pentru problema triunghiului, am selectat cazurile de testtare bune pentru a obine C0 coverage. Cazurile erau: (3,4,5 oarecare), (3,5,3 isoscel), (0,1,0 intrri greite), (4,4,4 echilateral) Aceste teste acopereau 4 din 5 ieiri. Putem obine C1 coverage cu dou cazuri de testare: (3,4,5 oarecare) i (0,0,0 intrri greite). Testul nu este probabil la fel de bun ca primul. Dar obinem astfel att C1 coverage, ct 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 pn n locul unde sunt folosite. O definiie de date (sau def.) este atunci cnd o valoare e asignat unei variabile. Computation use (sau c-use) este atunci cnd o variabil apare n membrul drept al unei instruciuni de atribuire. c-use se spune c apare ntr-o instruciune de atribuire. Predicate use (sau p-use) este atunci variabila este utilizat n condiia unei instruciuni de decizie. p-use e asignat ambelor ramuri ale instruciunii de decizie. Definition free path (sau def-free) e o cale de la definiia unei variabile la folosirea acelei variabile care nu include alt definiie a variabilei.

Exemplu. Pentru problema triunghiului, reprezentm control flow graph.

Sunt multe criterii de testare a fluxului datelor. Criteriile de baz includ dcu, care necesit o def-free de la fiecare definiie pn la c-use; dpu, care necesit o def-free de la fiecare definiie pn la p-use; du, care necesit o def-free de la fiecare definiie la orice folosire posibil. Cele mai extinse criterii sunt all-dupaths, care necesit toate def-free paths de la fiecare definiie la fiecare folosire posibil. Exemplu. Data flow testing pentru problema triunghiului. dcu singura c-use este pentru variabila din nodul k (instruciunea de ieire) de la def type n nodul abc la nodul k de la def type n nodul d la nodul k de la def type n nodul f la nodul k de la def type n nodul h la nodul k de la def type n nodul j la nodul k calea abc,e,g,i,k calea d,e,g,i,k calea f,g,i,k calea h,i,k calea j,k

Exemplu (continuare) dpu singura p-use este pentru variabilele a,b,c i singura def este nodul abc de la nodul abc la arcul abc-d de la nodul abc la arcul abc-e de la nodul abc la arcul e-f de la nodul abc la arcul e-g de la nodul abc la arcul g-h de la nodul abc la arcul g-i de la nodul abc la arcul i-j de la nodul abc la arcul i-k du toate defs la toate folosirile toate cazurile de testare ale dcu i dpu combinate. all-du-paths toate def-free paths de la toate defs la toate folosirile. toate cazurile de testare ale dcu i dpu combinate.

5. Testarea aleatoare (random testing)

Se realizeaz prin selectarea aleatoare a cazurilor de testare. Are avantajul c este rapid. n plus, inferena statistic e mai uoar cnd testele sunt selectate aleator. Exemplu. Pentru problema triunghiului, putem folosi un generator de numere aleatoare i s grupm fiecare mulime de trei numere ca o mulime de testare. Va trebui s determinm n plus expected output. O problem ar putea fi faptul c probabilitatea s generm un caz de testare a echilateralitii e foarte mic.

5.1 Profilul operaional (operational profile)

Testarea n mediul de dezvoltare (development environment) e adesea diferit de executarea n mediul operaional (operational environment). O cale de a le face pe acestea similare ar fi s avem o specificare a tipurilor i probabilitile ca aceste tipuri s se ntlneasc n operaiile normale. Aceast specificare se numete operational profile.

Prin desenarea cazurilor de testare ale profilului operaional, cel care face testul va avea mai mult ncredere c acea comportare a programului n timpul testrii e mai predictiv despre cum se va comporta n timpul funcionrii. Exemplu. Un posibil profil operaional pentru problema triunghiului:

Pentru aplicarea testrii aleatoare, se poate genera un numr pentru selectarea categoriei dup probabiliti i apoi generarea unor numere suficiente pentru a crea cazul de testare. Dac cumva categoria selectat a fost cazul echilateral, se va folosi acelai numr pentru toate cele trei intrri. Un isoscel drept va necesita un numr aleator pentru lungimea a dou laturi i apoi se poate calcula cealalt latur.

5.2 Inferen statistic la testare

Dac testarea aleatoare a fost fcut prin selectarea aleatorie a cazurilor de testare dintr-un profil operaional, atunci comportarea software-ului n timpul testrii ar trebui s fie aceeai cu comportarea sa n mediul operaional. Exemplu. Dac selectm 1000 cazuri de testare aleator, folosind profilul operaional i gsind 3 erori, putem prezice c software-ul va avea o rat a erorilor mai mic de 3 defeciuni (failures) la 1000 de execuii n mediul operaional.

5. Boundary testing (testarea de frontier)

De multe ori erorile apar la frontierele dintre domenii. n cod, instruciunile condiionale determin frontierele domeniilor. Dac avem o condiie x<=1, atunci frontiera x=1 este n domeniul true. n termeni de boundary testing, spunem c on tests sunt n domeniul true i off tests sunt valori ale lui x mai mari dect 1 i sunt n domeniul fals. Dac o condiie e scris x<1 n loc de x<=1, aunci frontiera x=1 este acum n domeniul fals. Boundary testing e fcut cu scopul de a ne asigura c frontiera adevrat, real (actual) dintre domenii e apropiat pe ct se poate de frontiera specificat. De aceea, cazurile de testare sunt selectate pe frontier i n afara frontierei, ct mai apropiat cu putin de frontier. Testul de frontiera standard const n efectuarea a dou on tests ct mai departe posibil pe frontier i un off test aproape de mijlocul frontierei.

Figura de mai jos arat o frontier simpl. Sgeata indic faptul c on tests ale frontierei sunt n subdomeniul de sub frontier. Cele dou on tests sunt la captul frontierei i off test-ul chiar deasupra jumtii.

Exemplu. n exemplul cu triunghiul, condiiile 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 spaiul 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 amndou adevrate. Off testul va fi n domeniul false i va fi aproape de mijloc (de exemplu 7.9,4,4).

Testarea software
- Laborator -

A. ntrebri
1. De ce e nevoie de specificare pentru a face testarea? 2. De ce path testing este de obicei impracticabil? 3. De ce e important testing coverage criterion?

B. Probleme
1. Un program calculeaz aria unui triunghi. Intrrile sunt 3 mulimi de coordonate x,y. Construii testele funcionale. 2. Un program accept doi timpi (n format de 12 ore) i ieirile reprezint numrul de minute scurse ntre cei doi timpi. Construii testele funcionale. 3. Un subprogram de cutare binar caut lista numelor n ordine alfabetic i returneaz true dac numele e n list i fals n caz contrar. Construii testele funcionale.

C. Problem propus
1. Pentru urmtorul cod, identificai toate cile posibile, path tests i data flow tests:

A1. Rspunsuri la ntrebri

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 numr uria de ci posibile. 3. De ce e important testing coverage criterion? R: Pentru c acest criteriu foreaz pe cel care face testele s testeze diversele pri ale software-ului.

B1. Rspunsuri la Probleme

1. Un program calculeaz aria unui triunghi. Intrrile sunt 3 mulimi de coordonate x,y. Construii testele funcionale.
R: Testele funcionale ar trebui s includ triunghiurile corecte, nontriunghiurile, condiii de eroare etc.

2. Un program accept doi timpi (n format de 12 ore) i ieirile reprezint numrul de minute scurse ntre cei doi timpi. Construii testele funcionale.
R: Testele funcionale 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 dai n ordine invers.

3. Un subprogram de cutare binar caut lista numelor n ordine alfabetic i returneaz true dac numele e n list i fals n caz contrar. Construii testele funcionale.
R: Testele funcionale ar trebui s includ urmtoarele teste: - Primul nume e n list - Ultimul nume e n list - Un nume dinaintea primului nume - Un nume dup ultimul nume - Un nume la mijloc - Un nume care nu e n list chiar dup primul nume - Un nume care nu e n list chiar naintea ultimului nume

C1. Indicaie la problema propus

1. Cile posibile sunt reprezentate n tabelul de mai jos.

Analiza problemei (Problem analysis)

Puncte de interes
Analiza problemei este procesul nelegerii problemelor din lumea real i nevoile utilizatorului i propunerea de soluii pentru satisfacerea acestor nevoi. Scopul analizrii problemei este de de a nelege ct mai bine problema, niante de a trece la dezvoltare. Pentru a identifica problemele din spatele problemei, trebuie ntrebai cei direct implicai. Identificarea actorilor sistemului e un pas cheie n analizarea problemei.

Definirea analizei problemei

Analiza problemei este procesul de a nelege lumea real i nevoile utilizatorului i de a propune soluii 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 diferena dintre lucrurile aa cum sunt percepute i lucrurile aa cum sunt dorite. Obs. Uneori, cea mai simpl soluie este un proces revizuit dect un nou sistem. Scopul problemei este de a nelege mai bine problema nainte ca

dezvoltarea s nceap.

Paii pe care trebuie s-i urmm pentru a obine scopul problemei sunt urmtorii:
1. S ne punem de acord privind definirea problemei. 2. S nelegem problema din spatele problemei. 3. S identificm stakeholders i utilizatorii. 4. S definim frontiera sistemului. 5. S identificm constrngerile care se impun soluiei.

Pasul 1. Punerea de acord privind definirea problemei

O cale foarte simpl este de a pune problema pe hrtie i de a vedea dac toat lumea e de acord cu ea. Ca parte a acestui proces, e adesea de mare ajutor nelegerea beneficiilor soluiei 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 toi stakeholders se concentreaz spre aceleai scopuri.
Element Problema e... Afecteaz... i rezultatele n... Descriere Se descrie problema. Se identific stakeholders. Se descrie impactul problemei asupra stakeholders i asupra activitii de business. Se indic soluia propus i se listeaz cteva beneficii

Beneficiile soluiei...

Pasul 2. Problema din spatele problemei

O tehnic folosit este root cause analysis, care ofer o cale sistematic de a descoperi cauza unei probleme identificate. Root cause analysis nu reprezint o metodologie definit; exist multe procese, instrumente i filozofii. Totui, le putem clasifica n 5 coli: Safety-based RCA descinde din accident analysis i occupational safety and health. Production-based RCA are manufacturarea industrial. originea n controlul calitii pentru

Process-based RCA al crei scop s-a extins ca s includ procesele business. Failure-based RCA are rdcinile n practica failure analysis aa cum se folosete n inginerie i mentenan. Systems-based RCA este un amalgam al colilor precedente, mpreun cu idei luate din domenii precum change management, risk management, i systems analysis.

Procesul general pentru executarea i documentarea unei RCA-based Corrective Action 1. Definirea problemei. 2. Adunarea datelor. 3. ntrebare de ce i identificarea realiilor de cauzalitate asociate problemei date. 4. Identificarea cauzelor care, ndeprtate sau schimbate, vor preveni recurena. 5. Identificarea soluiilor efective care previn recurena, sunt sub controlul dezvoltatorului, ndeplinesc scopurile i nu cauzeaz alte probleme. 6. Implementarea recomandrilor. 7. Observarea soluiilor recomandate pentru a asigura eficacitatea. 8. Metodologia Variability Reduction pentru rezolvarea i evitarea problemelor.

Tehnici root cause analysis Barrier analysis Bayesian inference Causal factor tree analysis Change analysis Current Reality Tree Failure mode and effects analysis Fault tree analysis 5 Whys Ishikawa diagram Kepner-Tregoe Pareto analysis RPR Problem Diagnosis Apollo Root Cause Analysis

Pasul 3. Identificarea stakeholders i a utilizatorilor

Stakeholder e oricine poate fi afectat material de implementarea unui nou sistem sau aplicaie. Muli stakeholders sunt utilizatori ai sistemului i nevoile lor sunt uor de identificat, deoarece ei sunt direct implicai n definirea i utilizarea sistemului. Unii stakeholders sunt doar utilizatori indireci, deoarece sunt influenai doar de veniturile sistemului. Obs. Stakeholders neutilizatori trebuie de asemenea identificai. Urmtoarele ntrebri pot fi de folos pentru identificarea stakeholders: Cine sunt utilizatorii sistemului? Cine este clientul (cumprtorul economic) al sistemului? Cine altcineva va fi afectat de ceea ce produce sistemul? Cine va evalua i aproba sistemul cnd este livrat i funcional? Exist ali utilizatori interni i externi ai sistemului? Cine va asigura mentenana noului sistem? Mai e cineva care conteaz?

Pasul 4. Identificarea frontierei sistemului

mprim sistemul n dou: 1. Sistemul 2. Lucruri care interacioneaz cu sistemul, prin intermediul intrrilor i ieirilor

Obs. Lucrurile care interacioneaz cu sistemul pot fi vzute n termeni de actori (aa cum s-au definit n cadrul UML), nct 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 situaii, frontierele sistemului nu mai sunt aa evidente. De exemplu, sunt situaiile n care analistul trebuie s determine dac datele sunt mprite cu alte aplicaii sau dac noua aplicaie va fi distribuit ntre mai muli clienti etc. Dei de multe ori se identific relativ uor, actorii pot fi determinai rspunznd unor ntrebri de genul (vezi i cursul despre Diagramele cazurilor de utilizare): Cine va folosi informaia din sistem? Cine va opera sistemul? Cine va asigura mentenana sistemului? Unde va fi folosit sistemul? De unde i ia sistemul informaiile? Ce alte sisteme (exterioare sistemului considerat) vor interaciona cu sistemul?

Pasul 5. Identificarea constrngerilor

Definim constrngerea ca fiind o restricie asupra gradului de libertate al soluiei. Fiecare constrngere trebuie considerat cu grij, ca parte important a procesului de planificare i unele ar putea s determine reconsiderarea abordrii tehnologice pe care am imaginat-o iniial. Se pot lua n calcul diverse surse ale constrngerilor: planificarea (n timp), return on investment, bugetul pentru munc i echipamente, sisteme de operare, baze de date, software-ul cumprat, procedurile companiei, alegerea instrumentelor i limbajelor, constrngeri legate de personal, de resurse etc. n tabelul urmtor se listeaz sursele poteniale ale constrngerilor sistemului.

Surs
Economic

Consideraii
Ce constrngeri financiare se aplic? Sunt consideraii legate de preul produsului? Sunt consideraii legate de liceniere? Sunt soluiile poteniale afectate de consideraii politice? Sunt probleme interdepartamentale? Soluia pe care o construim e deja n sistemele existente? Trebuie s meninem compatibilitatea cu soluiile existente? Ce S.O. i medii pot fi suportate? Suntem restricionai n alegerea tehnologiilor? Suntem restricionai n lucrul cu platformele i tehnologiile existente? Exist interdicii privind utilizarea altor tehnologii? Ne ateptm s folosim pachete software cumprate?

Politic

Sisteme

Tehnologic

Surs
Mediu (environment)

Consideraii
Sunt constrngeri legate de mediu (environment)? Sunt constrngeri legale? Care sunt constrngerile legate de securitate? Ce alte standarde ne pot restriciona? Este planificarea definit? Suntem restricionai privind resursele existente? Putem folosi munc din afar? Putem mri resursele?

Planificare i resurse

Odat identificate, unele dintre aceste constrngeri vor deveni cerine pentru noul sistem. Trebuie determinat impactul fiecrei constrngeri asupra soluiei poteniale.

Concluzii
Dup efectuarea analizei problemei, ar trebui s avem ncredere c avem: O bun nelegere a problemei i a eventualelor probleme din spatele problemei (root causes); Identificarea potrivit a stakeholders, a cror analiz (judecat) va determina n ultim instan succesul sau eecul sistemului; O nelegere a locului unde se pot gsi frontierele sistemului; O nelegere i identificare a constrngerilor 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 aplicaii software complete. Acesta poate fi: bespoke system (sistem comandat), i.e. un sistem care e creat de la zero, special pentru un client; off-the-shelf (gata pentru cumprare), pe care l cumperi ca atare (as is) uneori se mai numete shrink-wrapped software; customized off-the-shelf (COTS) software acesta este basic core system, care e modificat pentru a ndeplini cerinele 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 licene pentru folosirea software-ului. Aceste disticii au implicaii legale.

O alt clasificare a contractelor este d.p.d.v. al modalitii de plat ctre furnizori: contracte cu pre fixat; contracte de timp i materiale; contracte cu pre fixat per unitatea livrat.

Contracte cu pre fixat

Preul e fixat atunci cnd se semneaz contractul. Clientul tie c dac nu exist schimbri n termenii contractului, preul pe care-l va plti este cel consemnat n contract.

n acest caz trebuie ca analiza cerinelor s fi avut deja loc. Odat nceput dezvoltarea, clientul nu-i poate schimba cerinele fr s negocieze preul contractului.

Avantajele acestei metode sunt: Cheltuielile clientului cunoscute; Motivarea furnizorului; Dezavantajele acestei metode sunt: Preuri mai mari pentru a permite eventualele lucruri neprevzute. Furnizorul adaug o marj la calcularea preului tocmai pentru a reduce riscul apariiei unor situaii neprevzute; Dificulti n modificarea cerinelor; O presiune upward asupra costului schimrilor. n competii cu ali furnizori, furnizorul va ncerca s ofere un pre ct mai sczut. Dac, odat contractul semnat, e nevoie de schimbri ale cerinelor, furnizorul e n poziia forte de a cere un pre mai mare pentru aceste schimbri; Ameninare la calitatea sistemului. Nevoia de a menine un pre fixat poate duce la deteriorarea calitii 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 nelegerea cerinelor utilizatorului, dar aceasta nu e baza pentru plata final. Avantajele acestei metode sunt: Uurina n a schimba cerinele; Lipsa presiunii preului; Dezavantajele acestei metode sunt: Handicapul clientului. Clientul e cel care se va nfrunta cu toate riscurile asociate cu cerine vag definite sau care se schimb; Lipsa motivaiei pentru furnizor. Furnizorul nu are motivaie 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. Mrimea sistemului care urmeaz s fie livrat e calculat sau estimat la nceputul proiectului. Mrimea sistemului trebuie s fie estimat n linii de cod, dar FPs pot fi derivate cu uurin de la documentaia cerinelor. E stabilit preul per unitate. Preul final va fi preul unitar nmulit cu numrul de uniti. Exemplu. Tabelul de mai jos arat o astfel de estimare a preurilor (tabel preluat din Garmus, Herron, Measuring The Software Process, 1996)

Dac sistemul conine 2600 FPs, costul total va fi: 2000x967+500x1019+100x1058

Avantajele acestei metode sunt: nelegerea din partea clientului. Clientul poate vedea cum e calculat preul; Uurina de a face comparaii. Preurile stabilite pot fi comparate; Emerging functionality. Furnizorul nu-i asum riscul funcionalitii n cretere. Eficiena furnizorului. Furnizorul are nc motivaia s livreze sistemul la funcionalitatea cerut. Lyfe cycle range. Cerinele nu trebuie specificate n forma final la nceput. Contractul poate acoperi att etapa de analiza, ct i etapa de design. Dezavantajele acestei metode sunt: Dificulti cu msurarea dimensiunii software-ului. Numrul de linii de cod poate fi mrit folosind un stil de codare bombastic. Folosirea regulilor de numrare a FPs poate favoriza furnizorul sau clientul. Soluia ar fi s fie angajat un independent FP counter (numrtor independent al FPs); Schimbarea cerinelor. Anumite cerine pot afecta drastic tranzaciile, dar nu se adaug la numrrea global a FPs. O schimbare a cerinelor fcut trziu n ciclul de dezvoltare va necesita aproape sigur mai mult efort pentru implementare dect dac s-ar produce mai devreme.

O alt clasificare a contractelor (conform regulilor din Uniunea European) se face n legtur cu abordarea care e folosit pentru selectarea contractorului: deschis (open); restricionat (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 condiiile originale din invitation to tender trebuie s fie considerate i evaluate n acelai mod ca celelalte. La un proiect major, unde exist o mulime 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 invitai de client. Spre deosebire de open tendering process, clientul poate n orice moment s reduc numrul furnizorilor poteniali. Este n mod uzual cea mai bun abordare. Exist totui riscuri: acolo unde contractul rezultant e la un pre fixat, clientul i asum responsabilitatea pentru corectitudinea i completarea cerinelor specificate furnizorilor.

Negociated procedure Sunt situaii cnd procesul de ofertare restricionat 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 cerinelor naninte de abordarea furnizorului, trebuie s fie specificate clar cerinele. Documentarea cerinelor trebuie sp aib, n mod tipic, seciuni de forma celor artate n tabelul de mai jos (un asemenea document se numete uneori operational requirement sau OR):

Cerinele definesc cu grij funciile care necesit s fie duse la bun sfrit de noua aplicaie i toate intrrile(inputs) i ieirile(outputs) necesare pentru aceste funcii. Cerinele 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 cerine operaionale i de calitate (vezi capitolul despre Calitatea produselor software). Cerinele obligatorii (mandatory) trebuie s fie ndeplinite. Dac o propunere nu ndeplinete obligatorie, atunci propunerea va fi respins. Dac cerina 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 cerine, trebuie schiat planul despre cum va fi evaluat propunerea. Pentru o aplicaie off-the-shelf, sistemul nsui va fi evaluat.

Invitaia la ofert (invitation to tender) Dup analiza cerinelor i producerea planului de evaluare, e posibil etapa de a invita posibilii furnizoti s fac o ofert. n esen, aceast invitaie trebuie nsoit de o scrisoare, n care s se ofere diverse informaii: cum va fi tratat legal oferta, care este termenul limit pentru prezentarea ofertei etc. Abordrile privind aceast etap nu sunt unitare n diverse ri, de aceea recomandm consultarea normelor legale pentru fiecare ar.

Evaluarea propunerilor Procesul de evaluare trebuie fcut metodic i planificat i ar putea include: examinarea atent a documentelor propunerii; intervievarea reprezentanilor furnizorilor; demonstraii; examinri ale site-urilor; teste practice. Documentele propunerii oferite de furnizori pot fi examinate pentru a vedea dac conin toate elementele ce satisfac cerinele originale. Se pot cere anumite clarificri asupra unor puncte ale propunerii. Orice declarare factual fcut de furnizor presupune o angajare legal din partea lui dac influeneaz cumprtorul s ofere contractul acelui furnizor. Cumprtorul poate lua iniiativa de a pstra note ale ntlnirilor i de scrie apoi furnizorului pentru a obine confirmarea asupra acurateii lor. Furnizorul poate, n finalul documentului contractului, s ncerce s exclud orice angajare la orice reprezentaii fcute n negocierile precontract.

Cnd produsul livrat se bazeaz pe un produs existent, e posibil s vad o demonstraie. Un pericol cu demonstraiile este acela c sunt controlate de furnizor. De aceea, clientul ar trebui s fac o planificare a lucrurilor pe care dorete s le vad n demonstraie, asigurndu-se astfel c toate elementele importante sunt vzute. Cu un software off-the-shelf, e posibil s avem acces concret la aplicaie. 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 aplicaie existent lucreaz bine pe o anumit platform, nu lucreaz mulumitor pe platforma clientului. n acest caz sunt mai utile examinrile unor site-uri operaionale care folosesc sistemul.

3. Termenii tipici ai unui contract

E nevoie s schim anumite arii majore asupra crora trebuie s ne concentrm: Definiii S-ar putea ca terminologia folosit n documentul contractului s fie definit, de exemplu ce se nelege prin client i furnizor. Forma nelegerii De exemplu, e contract de vnzare, de leasing sau licen? De asemenea, poate subiectul unui contract, cum ar fi licena pentru utilizare unei aplicaii software, poate fi transferat unei tere pri? 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 fiierelor existente; mentenan; msuri de asigurare temporare. Proprietarul software-ului Dou chestiuni apar: mai nti, poate clientul s vnd software-ul la alii i a doua dac furnizorul poate vinde software-ul la alii. Cnd un software e scris special pentru un client, clientul va dori probabil s-i asigure exclusivitatea, de exemplu prin cumprarea copyright-ului sau prin specificarea n constract c folosete exclusiv software-ul.

Mediul (environment) Cnd trebuie instalat echipamentul fizic, trebuie specificat linia de demarcaie dintre responsabilitile furnizorului i clientului cu privire la lucruri cum ar fi furnizarea de energie. Cnd software-ul e furnizat, trebuie confirmat compatibilitatea cu hardware-ul existent i sistemul de operare existent. Angajamentele clientului Clientul trebuie s asigure accomodation pentru furnizori i probabil alte faciliti (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 cnd testarea e completat. Standarde Clientul poate cere furnizorului dovada c diverse standarde sunt respectate.

Managementul proiectului i al calitii 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 prile cheie ale proiectului. Aceast planificare va obliga att clientul, ct i furnizorul. De exemplu, furnizorul poate si n stare s instaleze software-ul la o dat convenit numai dac clientul face platforma hardware disponibil. Preul i metoda de plat n contract trebuie stabilit preul i modalitatea de plat. Cerine legale diferite n contract pot fi specificate ce condiii se aplic la subcontractarea muncii, obligaia pentru daune ctre o ter parte i liquidated damages. Liquidated damages sunt estimatori ai pierderilor financiare pe care clientul le sufer dac furnizorul a euat n obligaiile pe care i le-a asumat.

4. Managementul contractului
La anumite puncte de decizie, clientul are nevoie s examineze munca deja fcut i s ia decizii despre direcia viitoare a proiectului. Proiectul va necesita ca reprezentani ai clientului i furnizorului s interacioneze n multe puncte ale ciclului de dezvoltare. Aceast interaciune, sau ali factori externi, conduc(e) de obicei la necesitatea unor schimbri. Pentru fiecare punct de decizie, trebuie s fie definite deliverables ce urmeaz s fie prezentate de furnizori i toate output-urile.

Odat contractul ncheiat, trebuie avut n vedere calitatea muncii. Standardul ISO 12207 ofer printre altele posibilitatea existenei unor ageni, angajai independent de client sau furnizor, care se vor duce la bun sfrit verificarea, validarea i asigurarea calitii. Pe msur ce sistemul se dezvolt, apare uneori nevoia unor schimbri n cerine, care pot duce la modificarea termenilor contractului. Va fi nevoie deci de o procedur de control al schimbrilor, care s nregistreze cerinele pentru schimbri, 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 situaiile n care furnizorul nu respect una sau mai multe obligaii legale.

5. Acceptarea
Cnd munca e terminat, clientul trebuie s nceap activitatea legal pentru realizarea testrii de acceptare (acceptance testing). Contractul poate stabili o dat limit pentru ct poate dura testarea, astfel nct clientul s poat face testarea nainte de expirarea timpului, n vederea corectrii problemelor ridicate. O parte a plii sau chiar toat plata va depinde de testul de acceptare. Uneori o parte a plii finale va fi reinut pentru perioada rulare operaional i va fi pltit dac nivelul de fiabilitate este conform specificaiilor contractate. Exist de obicei o perioad de garanie, n timpul creia furnizorul poate pune la punct orice eroare aprut. Probabil c furnizorul poate cere o perioad de garanie mai mic (30 zile, de exemplu), n timp ce clientul ar ncerca s duc perioada de garanie pn spre 120 zile, de exemplu (aceste valori sunt orientative, dar pot fi ntlnite adesea n realitate).

Concluzii Cteva dintre punctele cheie din acest capitol pot fi astfel rezumate:
contractarea

cu succes necesit timp important;

e mai uor s se obin concesii din partea furnizorului nainte de semnarea contractului dect dup; un contract va stabili obligaii i pentru client, i pentru furnizor; negocierea contractului va include nelegerea asupra managementului relaiei dintre furnizor i client n timpul executrii proiectului.

Planificarea proiectelor software

1) WBS Work Breakdown Structure

Una dintre primele sarcini este s mprim activitile mari n activiti mai mici. Acest lucru nseamn i gsirea acelor pri mici ale activitii. nseamn i gsirea deliverables i milestones care se pot utiliza pentru msurarea progresului. Work breakdown structure (WBS) trebuie s fie o structur de arbore. n vrful arborelui se va gsi de obicei lyfe cycle model (LCM) folosit n organizaie. Mai jos sunt date reguli pentru construirea unei structuri corespunztoare: 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 neleas i neambigu. 3. Fiecare task trebuie s aib un criteriu de completare (completion criterion). Trebuie s existe o cale de a decide cnd un task e complet. Aceast decizie se numete 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 recunoatere facial pentru folosirea pe un robot. Sistemul se dorete a fi folosit pentru a ntmpina vizitatorii n laboratorul de robotic. Ar trebui s recunoasc fee pe care le-a mai vzut cu o anumit probabilitate. Primul pas n work breakdown ar trebui s recunoasc urmtoarele 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 dependenele 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 (dependenele). Graful poate s nu aib totdeauna doar un subtask de nceput sau doar un subtask de oprire. ntregul task e completat cnd toate subtask-urile sunt completate. Graful poate fi folosit pentru a calcula timpii de completare pentru fiecare subtask, timpul de completare minim pentru ntregul task i critical path pentru subtask-uri.

Tabelul 1. Subtask-urile

Diagrama PERT

A) ALGORITMUL PENTRU TIMPII DE COMPLETARE (completion times). 1. Pentru fiecare nod, execut pasul 1.1 (pn sunt calculai toi timpii de completare) 1.1 Dac predecesorii sunt completai, atunci ia latest completion time al predecesorilor i adaug timpul cerut pentru acest nod. 2. Nodul cu latest completion time determin earliest completion time pentru proiect. Exemplu. Aplicnd algoritmul pentru tabelul 1 (artat ca diagram n figura de mai sus), ncepem cu subtask-ul a; nu are dependene, deci poate ncepe la timpul iniial (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 urmtoare) 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 acelai timp.

Tabelul 2. Subtask-urile

Exemplu (continuare). Pot fi calculai 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. Procesm 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 amndou plecnd la 21 i h completat la 25 i i la 24. Tabelul 2 are toi 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); marcai-l (le) drept critice. 2. Selectai predecesorul (predecesorii) nodului (nodurilor) critic(e) cu latest completion time(s); marcai-l(e) ca fiind critice. Continuai cu pasul 2 pn cnd se atinge nodul (nodurile) de start.

Tabelul 2. Subtask-urile Exemplu. In tabelul 2 (afiat i n acest slide, pentru claritate) se vd timpii de completare pentru toate subtask-urile. Marcm 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. Subtaskul f are c i d ca predecesori. Va fi marcat c ca parte a drumului critic, avnd 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 ct mai devreme cu putin, altfel tot proiectul va fi ntrziat. Totui subtask-urile care nu sunt pe critical path au o anumit flexibilitate privind momentul cnd sunt ncepute. Aceast flexibilitate se numete slack time. Algoritm pentru slack time 1. Alege nodul necritic cu timpul de terminare cel mai mare (latest ending time), nod care nu a fost procesat. Dac subtask-ul nu are succesori, alege latest ending time al tuturor nodurilor. Dac subtask-ul are succesori, alege cel mai mic dintre latest start times al nodurilor succesor. Acesta este latest completion time pentru acest subtask. F latest start timepentru acest subtask ca s reflecte acest timp. 2. Repet pasul 1 pn cnd toate noncritical path subtasks sunt procesate.

Tabel 3. Subtask-uri cu slack time

Exemplu. Subtask-ul necritic cu

cel mai mare timp de completare este i. Cum nu are succesori, se folosete 25 ca timp de completare. Timpul de start poate fi schimbat n 21,22 (deoarece 25 e mai mare cu 1 dect 24). Urmtorul 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. Aa 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. Procesm 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 cte resurse sunt necesare pentru completarea proiectului. De obicei estimarea se face n programmer-months (PM). Sunt dou abordri diferite pentru estimarea costului. Vechea abordare se numete LOC estimation, deoarece se baza pe estimarea iniial a numrului de linii de cod necesare pentru dezvoltarea proiectului. Abordarea mai nou se bazeaz pe numrarea function points n descrierea proiectului. A) ESTIMAREA LINIILOR DE COD (LOC) Estimarea liniilor de cod se poate face pe baza experienei, mrimea proiectelor anterioare sau pe mprirea proiectului n buci mai mici i estimarea fiecrei pri. Abordarea standard presupune, pentru fiecare piesi, 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 adugat pentru fiecare mie de linii de cod. Parametrul este un exponent ce reflect neliniaritatea relaiei. O valoare >1 nseamn c costul per KLOC se mrete pe msur ce mrimea proiectului crete. Parametrul reflect costul fixat pentru realizarea oricrui proiect. Exemplu. Compania A a nregistrat datele din proiectele anterioare. Estimai care ar fi parametrii pentru formula de estimare a costului i ce efort ar lua un proiect de 30 KLOC. Soluie. Din tabel rezult o relaie liniar ntre mrime (size) i efort (PM). Panta este 2,4, care reprezint . Deoarece linia e dreapt, =1. Valoarea lui va fi 0.

C) CONSTRUCTIVE COST MODEL (COCOMO) COCOMO este formula clasic de estimare a costului bazat pe LOC. A fost creat de Barry Boehm. Folosete mii de instruciuni durs livrate (thousands delivered source instructions KDSI) ca unitate a mrimii. KLOC e echivalent. Boehm a divizat datele de proiecte istorice n 3 tipuri de proiecte: a) Application (ex: procesoare de date) b) Utility programs (ex: compilatoare, analizoare) c) System programs Boehm a determinat valorile parametrilor pentru modelul costului pentru determinarea efortului: a) Application programs: PM=2.4*(KDSI)1.05 b) Utility programs: PM=3.0*(KDSI)1.12 c) System programs: PM=3.6*(KDSI)1.20

Exemplu. Calculai efortul programatorului pentru proiectele din tabelul alturat.

Boehm a determinat de asemenea c n datele de proiect, exist un timp de dezvoltare standard bazat pe tipul de proiect i mrimea 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. Calculai standardul TDEV pentru proiectele din tabelul alturat, folosind formulele de mai sus.

D) FUNCTION POINT ANALYSIS Ideea este s identificm i s cuantificm funcionalitatea cerut pentru proiect. Trebuie s cuantificm lucruri n comportarea exterioar care vor necesita procesare. Itemii clasici sunt:

Inquires sunt perechi cerere-rspuns care nu schimb datele interne. De exemplu, cererea pentru o adres a unui anumit angajat. Inputs sunt itemi ai datelor aplicaiei care sunt furnizai programului. Outputs sunt afiri ale datelor aplicaiei. Un output poate fi un raport, un screen display sau un mesaj de eroare. Internal files sunt fiiere logice ce sunt meninute de sistem. Dac un fiier coninnd date personale i date privind departamentul, se va contoriza probabil ca dou fiiere separate n function point analysis. External interfaces sunt date care sunt mprite cu alte programe.

Counting Unadjusted Function Points Itemii sunt identificai i clasificai ca simpli, medii, compleci. Se asigneaz ponderi i totalul se sumarizeaz. Acest total se numete unadjusted function points. Exemple de ponderi sunt date n tabelul de mai jos:

Nu exist standarde pentru numrarea function points. E important de reinut c function points ncearc s msoare cantitatea de efort necesar pentru dezvoltarea software.

E) PRODUCTIVITATEA Se determin prin mprirea 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 urmtor. Calculai 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), obinem productivitatea=50fp/65 zileprogramare=0,77 fp/zile-programare.

F) EVALUAREA ESTIMRILOR Metrica propus de Tom DeMarco este estimate quality factor (EQF). EQF e definit ca aria de sub curba real, mprit cu aria dintre valoarea estimat i real. Valorile peste 8 sunt rezonabile, conform lui DeMarco. Exemplu. Estimrile de mai jos sunt date pentru un proiect care cost 3,5 milioane dolari i a fost completat dup 11,5 luni:

Aria total=11,5*3,5=40,25. Diferena este 2,3 3,5 1,5 + 3,1 3,5 4 + 3,9 3,5 2,5 + 3,4 3,5 3,5 = 4,75 Raportul este 40,25/4.75=8,7

Planificarea proiectelor software

- Laborator -

ntrebri
1. 2. 3. 4. 5. De ce trebuie ca WBS s fie arbore? Care e avantajul folosirii diagramelor PERT? Este critical path important dac la proiect lucreaz doar o persoan? Care e importana slack time? De ce trebuie ca parametrii pentru estimarea costului s fie determinai din datele companiei?

Problema 1
Creai un WBS pentru task-ul vopsirii unei camere. Presupunem activitile: planificarea muncii, cumprarea proviziilor, vopsirea propriu-zis, curarea.

Problema 2
Desenai diagrama PERT pentru sarcinile problemei 1.

Problema 3
Desenai diagrama PERT pentru sarcinile prezentate n tabelul alturat. Completai tabelul artnd critical path i slack times.

Problema 4
Estimai parametrii de cost pentru mulimea de date din tabel:

Problema 5
Calculai efortul COCOMO, TDEV i productivitatea pentru un proiect organic care e estimat la 39800 linii de cod.

Indicaii i soluii

Indicaii la ntrebri
2. Care e avantajul folosirii diagramelor PERT? Rspuns: Dei WBS dezvolt o list de task-uri, e greu de vzut ce task-uri vor fi fcute primele i care task-uri determin final completion time. 3. Este critical path important dac la proiect lucreaz doar o persoan? Indicaie. E important dac toate task-urile sunt pe critical path.

Problema 1
Creai un WBS pentru task-ul vopsirii unei camere. Presupunem activitile: planificarea muncii, cumprarea proviziilor, vopsirea propriu-zis, curarea Soluie. Mai jos e dat un exemplu de soluie: a)Selectarea culorii pentru camer b)Cumprarea vopselei c)Cumprarea periilor d)Pregtirea pereilor e)Deschiderea cutiei de vopsea f)Amestecarea vopselei g)Vopsirea pereilor h)Curarea

Problema 2
Desenai diagrama PERT pentru sarcinile problemei 1: a. Selectarea culorii pentru camer b. Cumprarea vopselei c. Cumprarea periilor d. Pregtirea pereilor e. Deschiderea cutiei de vopsea f. Amestecarea vopselei g. Vopsirea pereilor h. Curarea Soluie.

Problema 3
Desenai diagrama PERT pentru sarcinile prezentate n tabelul de mai jos. Completai tabelul artnd critical path i slack times. Indicaie.

Problema 4 Estimai parametrii de cost pentru mulimea de date din tabel:

Indicaie. Cost = 4.0 * Marime(KLOC) + 5.0

Problema 5 Calculai efortul COCOMO, TDEV i productivitatea pentru un proiect organic care e estimat la 39800 linii de cod.
Indicaii. Formula de aplicaie se folosete n acest caz: Cost = 2.4 * (KDSI)1.05 TDEV = 2.5 * (PM)0.38 Productivitatea = 39800 LOC / (114.8 PM * 20 zile/lun)