5. Managementul calitii 5. 1.

Generaliti
Calitate
= totalitatea caracteristicilor unei entiti ce asigur abilitile acesteia de a satisface nevoile impuse i implicite [PMBOK]
= totalitatea caracteristicilor ce asigur respectarea cerinelor funcionale i de performan, a cerinelor implicite, ateptate + respectarea standardelor de dezvoltare/construcie corect [Software]

Categorie (grade)
= rang asociat unor entiti cu acelai rol funcional, dar caracteristici tehnice diferite

ex: hrtie pentru fotografii, copiator, scris

= nivelul de excelen pentru ceva [Webster Dictionary]

Dificulti: o PM trebuie s asigure calitatea activitii de management i obinerea unor livrabile de calitate o pentru evaluarea nivelului de calitate nu exist mereu metrici unanim acceptate Calitatea managementului de proiect rezult din Calitatea rezultatelor, obinerea rezultatelor care erau ateptate Gradul de mulumire al echipei Experiena organizaional acumulat prin proiect >> Cheia: comunicare, implicare stakeholders Calitatea unui produs software Nu exist baze teoretice clare, complete exist o doz de subiectivism: exist acord n privina unor factori importani, dar nu exist definiii precise, complete pentru factorii de calitate

Varianta propus de Mc Call:

Factori de calitate (high level)
1. operare produs corectitudine (face corect ce veau?) fiabilitate (face mereu bine?) eficien (pe hardware-ul existent lucreaz ct de bine se poate?) utilizabilitate (e uor de folosit, rspunde nevoilor utilizatorului?) integritate (e sigur?) revizuire produs mentenan (pot s repar?) testabilitate (pot s-l testez uor?) flexibilitate (pot s-l schimb uor?) tranziie produs portabilitate (pot s-l folosesc pe alte calculatoare?) reutilizare (pot reutiliza?) interoperabilitate (se poate interfaa cu alte sisteme?)

2.

3.

Criterii (low level): acces audit, acces control, acuratee, comunicativitate,

consisten, conciziune, expandabilitate, completitudine, toleran la erori, eficien n execuie, independen de hardware, modularitate, simplitate, trasabilitate, documentare complet, etc

Calitatea&categoria unui produs sunt legate de Valoare produs + costuri pentru realizarea produsului Valoarea de utilizare Fiabilitate Longevitate (n IT: longevitate redus!!!) Calitatea&categoria unui serviciu sunt legate de Cost de implementare Valoarea obinut prin acel serviciu (tarif unitar * nr. uniti accesate) Gradul de satisfacie al utilizatorului Fiabilitate Longevitate o trebuie realizat un compromis ntre cerine divergente
fiabilitate costuri

Sugestii generale pentru managementul eficient al calitii: o clientul trebuie s fie mulumit de produs/serviciu >> proiectul trebuie s realizeze ceea ce s-a cerut >> atenie la utilizabilitate !!! calitatea sczut e periculoas, categoria sczut nu trebuie obligatoriu evitat !!! atenie la cerinele implicite o aciunile preventive sunt preferate celor de inspecie + corecie o folosete cicli de dezvoltare care permit folosirea de modele conceptuale i verificarea ncepnd cu primele faze o cadrul organizatoric este foarte important: cultura + experien + infrastructur

o responsabilitatea revine n special PM, echipa are doar rolul de participant!! PM este responsabil de asigurarea nivelului de calitate + categorie dorite pentru livrabile i pentru managementul de proiect >> uneori aceste obiective sunt divergente: ex: respectarea termenelor de predare prin reducerea perioadei de testare; respectarea cerinelor clientului prin creterea volumului de munc al echipei >> fii un bun exemplu!!! o calitatea ridicat asigur succesul pe termen lung

Standard de calitate o dac productorul respect un standard de calitate, cumprtorul are garania c produsul a fost realizat la un nivel acceptabil de calitate o respectarea unui standard de calitate poate fi greoaie i costisitoare Ex: ISO 9000 (ISO 9000-3 pentru software) pune accent pe documentare, pe formularea i folosirea consecvent a unor proceduri de lucru >> nu asigur direct calitatea dorit << revalidare la 3 ani, raportri/audit la 6 luni

5. 2. Procesele managementului calitii

= procesele care asigur c proiectul realizeaz un produs/serviciu la nivelul de calitate dorit planificarea calitate asigurare calitate identific standardele de calitate potrivite i stabilete cum pot fi satisfcute evalueaz performanele proiectului n mod regulat i indic dac proiectul satisface standardele de calitate impuse monitorizeaz anumite rezultate ale proiectului i determin dac acestea respect standardele de calitate + identific schimbrile necesare pentru a reveni la standardele de calitate impuse

control calitate

5. 2. 1. Planificarea calitii
= identificarea standardelor de calitate relevante i a procedurilor necesare pentru ca standardele de calitate s fie ndeplinite CUM OBII CALITATE?
Scope statement, descriere produs Alte informaii din proiect
(ex: calitatea posibil pentru produsele ce trebuie achiziionate)

Plan management calitate cum se va implementa politica de calitate?

(responsabiliti, proceduri, procese, resurse)

Definiii operaionale - metrici
<< ce se msoar pentru a urmri respectarea nivelului de calitate !! fiecare livrabil s fie msurabil, verificabil !! metrici pentru activitatea de management de proiect Ex. performanele apl. soft: nr utilizatori, memorie ocupat, vitez de execuie control schedule: start, sfrit activiti

Politica de calitate n organizaie

!!! atentie la standardele de calitate folosite pentru toate domeniile implicate n proiect

Standarde + norme Alte informaii + Alte proiecte + Expertiz

Lista de activiti necesare: complet, consistent

<< cum se msoar pentru a urmri respectarea nivelului de calitate

Intrri spre alte procese

Recomandri: o Este necesar o analiza a costurilor i o analiz cost/beneficiu costurile necesare pentru a asigura calitatea cerut = = costurile activitilor care asigur c sunt respectate cerinele/calitatea (prevenie + verificare) + costurile activitilor de corecie, necesare n cazurile n care se depisteaz c nu a fost respectat nivelul de calitate/categorie dorit veniturile rezult din gradul de satisfacie al beneficiarilor, productivitate, etc !!!! s obii venituri > costuri

o construiete diagrame care s ilustreze principalele cauze ce pot conduce la nesatisfacerea nivelului de calitate dorit Ex: diagrame de flux (flowchart); diagrame de tip cauz-efect Ishikawa (fishbone) = diagrame care ilustreaz cum anumite cauze pot genera anumite efecte:

Timp

Echipament

Metoda

Materiale Defect major

Mediu

Oameni

Msurare Cauze potentiale Efecte

o stabilete dac exist standuri de testare (benchmark) - pentru a evidenia mai bine calitatea produsului creat o stabilete setul de experimente necesare pentru verificarea calitii produsului (pot fi i seturi de date stochastic generate) metoda poate fi folosit i pentru verificarea planului realizat n diverse situaii ipotetice (riscuri care intervin, diverse combinaii de strategii de management, etc)

5. 2. 2. Asigurare calitate
= activitile sistematice, planificate (s se desfoare cu regularitate), care asigur c proiectul va respecta nivelul de calitate dorit PROIECTUL RESPECT NIVELUL DE CALITATE DORIT?
Cereri de schimbare Plan management calitate + Definiii operaionale pentru mbuntirea nivelului de calitate

mbuntire calitate Rezultatele obinute n evaluarea calitii

Aciuni de corecie pentru mbuntirea nivelului de calitate

Recomandri + observaii: o organizaia poate opta pentru auditri suplimentare realizate de ctre un auditor extern sau intern, la momente de timp prestabilite sau neplanificate auditul ilustreaz cum se desfoar managementul calitii pe proiect, ce lecii nvate pot fi utile pentru organizaie o n unele organizaii exist un departament pentru asigurarea calitii care indic o parte din aciunile necesare o aciunile preventive sunt preferate celor de corecie

5. 2. 3. Control calitate
= monitorizeaz anumite rezultate ale proiectului pentru a determina dac respect standardele de calitate impuse + identific variantele de corecie + gestioneaz schimbrile necesare CEEA CE AI OBINUT RESPECT NIVELUL DORIT DE CALITATE? CE GREELI FACI? CUM REPARI?

Completarea listei de activiti necesare pentru asigurarea calitii Cereri de schimbare pentru mbuntirea calitii >> inclusiv aciuni preventive noi

Plan management calitate + Definiii operaionale, List activiti

Aciuni de corecie a planului Rezultate obinute n proiect Decizia de refacere a componentelor livrabile necorespunztore SAU Decizia c livrabilele satisfac standardul de calitate dorit Documentare lecii nvate Cauze + criterii de alegere a aciunilor de corecie, a schimbrilor

Recomandri: o Sunt necesare evaluri atente ale rezultatelor: Inspecie = msurare + examinare + testare pentru a vedea dac sunt ndeplinite cerinele Inspectie
(eroarea nu este vzut de client)

Prevenie
(eroarea este evitat n proiect)

Variante de inspecie: Peer review (= membrii echipei se verific ntre ei), posibil dac exist ncredere i expertiz; avantaje: membrii echipei comunic, nva unii de la alii, exist o rezerv dac un membru al echipei prsete proiectul Extern - dac nu exist expertiz intern avantaje: obiectivitate, acuratee Walk around (= realizat de PM) Statistic

Dac e posibil, determin gradul de conformitate (variable sampling) nu stabili doar un verdict acceptat/respins (atribute sampling) La aciunile repetitive construiete un grafic cu gradele de conformitate obinute pentru produsele similiare realizate
performan

Limit superioar

Limit inferioar

Produs 1

Produs 2

Produs 3

Produs 4

Regula 7S: dac 7 produse consecutive au calitate peste nivelul minim impus, dar apropiat de limita inferioar, atunci exist o cauz asignabil (sunt necesare msuri de corecie)

o Orice modificare/corecie trebuie s se bazeze pe o analiz atent: Reanalizeaz diagramele de flux + diagramele cauz/efect Realizeaz o diagrama care s ilustreze pentru fiecare tip de cauz posibil numrul erorilor/defectelor generate n proiect
Numr erori

oameni

metode

.....

Legea Pareto: 80% din probleme sunt generate de 20% din elemente (lege 80/20)

 Analizeaz tendinele manifestate pe proiect i predicteaz ce se va ntmpla n perioada urmtoare - analiza performanelor tehnice: cunoscnd erorile produse pn atunci predicteaz numrul total al erorilor - analiza performanelor managementului de proiectului (timp, cost, etc): cunoscnd depirile nregistrate pn atunci predicteaz depirile totale o Raportrile s fie realizate corect i complet: schimbri/corecii, ce este bine realizat + raportari cumulative: de la nceputul proiectului pn la momentul curent + raportri rezumative
pentru manageri

+ raportri de variaie: ce variaii au intervenit fa de planul iniial

o Folosete doar procedurile convenite pentru a accepta schimbrile o Notific toate schimbrile ctre cei implicai >> + integrarea schimbrilor

5. 3. Testarea produselor software

Validare
= primirea acceptului de la beneficiar

Verificare
= stabilete dac livrabilul este corect /incorect

Debug
realizat de dezvoltatori

Testare
nu e realizat de dezvoltatori

!!! dezvoltatorii i testerii au viziune diferit !!!

Observaii: o Rat costuri pentru corectare defecte, dac eroarea a fost depistat la faze diferite ale proiectului dezvoltare: testare: ntreinere = 1: 10:100 o Testarea solicit de regul aproximativ 30% din costul total al proiectului o Cauzele principale ale erorilor: cerine 60%, design 30%, cod 10%

Stil de testare:
- top - down (poate detecta repede erori majore, dar necesit stubs) - bottom - up (se genereaz mai uor cazurile de test) - white-box rar folosit la testare, folosit mai ales la debug - black box partiionarea spaiului de intrare n clustere, testarea la limitele intervalelor variabilelor de intrare, etc.

Ce se testeaz?
Testare - de unitate testare funcional (black box)

de integrare testeaz interfaarea componentelor (black box)

- de sistem - testare de performan run-time, stress i ncrcare, securitate, mod de lucru n cazul unor erori (recovery) testare beta pentru validare (pe baza criteriilor de acceptare ale beneficiarului)

!!!! Testarea automat este preferat: dup orice corecie a codului, setul de teste trebuie reluat (testare regresiv)

Model V & V (verificare i validare)

Cerine proiect + planificare Cerine nonfuncionale Cerine produs, specificaii, analiz Testare incrcare + stress Testare sistem Producie, mentenan

Design nivel nalt

Testare de integrare Testare de unitate

Design detaliat

Implementare cod

Este software-ul suficient testat?

o Testarea nu poate garanta c nu exist defecte, nu este exhaustiv!!! n funcie de eficien, testarea este Toy test = nesistematic, pe puine date Testare profesional = cu selecia sistematic a cazurilor, set larg de date >> grad bun de acoperire + automatizare (scripturi + tools)

Indicatori pentru evaluarea eficienei testrii Grad de acoperire (test coverage) = % program care a fost testat (ramuri parcurse, instruciuni executate mcar o dat n cadrul testelor) [<100%] - calculat automat de utilitarul folosit pentru testare Eficiena unei secvene de teste (fault seed) Pas 1: se introduc NS greeli n program Pas 2: se ruleaz secvena de testare i se detecteaz NF erori, din care NFS introduse la pasul 1 Pas 3:
NF-NFS ........ ? NFS ......... NS >>>

q=

NF NFS NS - s fie ct mai mic NFS

Indicaii pentru elaborarea planului

Activitile specifice testrii Stabilirea obiectivelor pentru faza de testare (n faza de cerine) Design cazuri de testare Elaborare scripturi de testare Testare scripturi Execuie scripturi + nregistrare erori Evaluare rezultate Corectarea erorilor de ctre dezvoltatori Reluarea testelor pe codul corectat