• ciclu de asigurare a calității produsului software
• se desfășoară de-a lungul întregului ciclu de dezvoltare a produsului software, pe care îl îndrumă, monitorizează, auditează, evaluează și coordonează
• complementează procesul de dezvoltare a proiectului
• (în mediile enterprise) este realizat de către un grup de resurse umane dedicate asigurării calității.

• metodologia QA a fost introdusă inițial în cadrul fabricilor, unde și-a demonstrat aportul la succesul producției de calitate
• ulterior, s-a dorit adoptarea QA la mediul dezvoltator de aplicații software
• Problema: produsul software nu este palpabil, deci măsurarea funcțiilor, a beneficiilor și a costurilor sunt mai dificil de determinat
• Soluția: s-au adăugat concepte precum quality attributes (metrici software, cerinte functionale si non-functionale) pentru a putea măsura calitatea produsului software.

Cel mai cunoscut model de atribute ale produselor software de calitate este FURPS+ model, care cuprinde următoarele atribute:

1. funcționalitate (functionality)
   • cuprinde toate cerințele funcționale ale sistemului așa cum au fost stabilite în SRS
2. utilizabilitate (usability)
   • cuprinde cerințe legate de ușurința de folosire a interfeței sistemului de către utilizator (interfața trebuie să fie estetică, intuitivă, ergonomică, consistentă, accesibilă și celor cu disabilități)
3. încredere (reliability)
   • cuprinde cerințe legate de precizia răspunsurilor, de disponibilitatea și toleranța la defecte a sistemului
4. performanță (performance)
   • cuprinde cerințe legate de timpii de lucru, precum timp de răspuns (response time), timp de revenire (recovery time), timp de lansare (startup time)
5. avantaje suplimentare (supportability)
   • cuprinde cerințe legate de ușurința testării (testability), a mentenanței (maintainability), a configurării (configurability), de gradul de scalare (scalability) și compatibilitate (compatibility) și de oferire de multiple traduceri ale conținutului interfeței cu utilizatorul.

• “+” se referă la faptul că la acest model se pot adăuga și alte cerințe de calitate personalizate.
  
  

Au apărut standarde dedicate produselor software, de tipurile:

• standarde de managementul calității (Quality management)
  • ISO 9000 – 3 Quality Management and Quality Assurance Standards – Part 3: Guidelines for the application of 9001 to the development, supply, installation and maintenance of computer software
• standarde de documentare (Documentation Standards) specifică formatul și conținutul documentelor de planificare și control și a documentației produsului
  • standarde de planificare (Producing plans): IEEE Std1059-1993 Guide for Software Verification and Validation Plans
• standarde de Project Management
  • General project management: IEE Std 1058.1-1987 Standard for Software Project Management Plans
• standarde de Software Engineering
  • Software Project Lifecycle: ISO/IEC WD 15288 System Life Cycle Processes
  • Software Project Requirements: IEEE Std 1233-1996 Guide for Developing System Requirements Specifications
  • standarde de proiectare (Design Standards) specifică reguli și metode de proiectare a soluției pornind de la specificații și formatul și conținutul documentelor de proiectare
  • standarde de codare (Code Standards) specifică limbajele de programare alese, convențiile de stil, reguli de construire a interfețelor și modul de comentare a surselor.
    
    

Ulterior, s-au definit proceduri:

• sunt succesiuni de pași ce trebuie urmați pentru a împlini un proces (ex: testare, configuration management).

Activitățile principale SQA sunt:

• asigură că standardele și procedurile de calitate alese pentru a fi urmate în proiect sunt adecvate la specificul proiectului (stabilirea lor este critică pentru că standardele oferă criteriile de evaluare a produsului și procedurile criteriile de comparare pentru procesele de dezvoltare și control)
• asigură că standardele și procedurile alese sunt bine documentate pentru că activitățile de monitorizare, audit și evaluare se bazează pe ele
• monitorizarea proceselor de dezvoltare și control în raport cu procedurile de calitate (pașii urmați coincid cu cei ai procedurilor?)
• evaluarea proiectului în raport cu standardele de calitate.

Activitățile de evaluare și monitorizare au loc în cadrul auditurilor. Auditul este tehnica SQA de bază folosită pentru verificarea calității produsului

• întocmește rapoarte de audit care sunt predate management-ului, ce afirmă gradul de implementare a calității și oferă recomandări pentru implementarea / sporirea calității în faza următoare a proiectului.
  
  

Există activități SQA specifice fazelor ciclului de viață al proiectului

1. faza de inițiere
   • SQA intervine în redactarea și revizuirea planului de management
   • asigură că standardele și procedurile alese sunt potrivite, clare și pot servi ca bază de auditare
2. faza cerințelor software
   • SQA intervine în revizuirea specificațiilor
   • asigură că specificațiile sunt clar exprimate, sunt categorisite corect în cerințe funcționale și non-funcționale (de interfață, de performanță, etc.), acoperă toate cerințele utilizatorului, pot fi măsurate
3. faza de proiectare
   • SQA intervine în revizuirea documentelor de proiectare
   • asigură că toate cerințele software au fost traduse corect în componente software în raport cu standardele și procedurile de proiectare
4. faza de dezvoltare
   • SQA asigură că soluția este dezvoltată în concordanță cu documentul de proiectare și cu standardele și procedurile de codare
5. faza de testare
   • SQA asigură respectarea standardelor și a procedurilor de testare
   • anunță sfârșitul procedurii de testare a cerințelor funcționale
6. faza de livrare
   • SQA verifică și declară respectarea cerințelor non-funcționale
   • anunță că produsul final este gata de livrare
7. faza de mentenanță
   • SQA intervine pentru a asigura că subciclurile de dezvoltare respectă normele de calitate

În general, scopul unei organizații este crearea unui SQAP care să asigure nivelul dorit de calitate a produsului.

Din standardul IEEE 730-1998, structura unui SQAP conține următoarele secțiuni:

1. Scopul documentului (Purpose)
2. Documente referite
3. Management
4. Documentație
5. Standarde, practici, convenții, metrici
6. Revizii și audituri
7. Managementul riscului
8. Raportarea problemelor și acțiuni de corecție
9. Utilitare, tehnici și metodologii
10. Controlul furnizorului
11. Training
12. Colectarea înregistrărilor, mentenanța

Un exemplu de document SQAP puteți găsi aici.

Un proiect se poate finaliza în următoarele contexte:

• s-a terminat (cazul cel mai fericit – proiect de succes)
• a fost oprit din motive (proiect eșec):
  • de afaceri (apar oportunități noi de business care ar genera un profit semnificativ mai mare decât proiectul actual)
  • de cost (bugetul alocat proiectului a fost epuizat și nu mai există surse de finanțare)
  • de calitate (calitatea proiectului este foarte redusă, deci investiția nu mai merită)
  • tehnice (între timp, au fost lansate soluții mai viabile decât cea a proiectului actual, tehnologiile utilizate de proiect au devenit demodate)
  • de timp (timpul alocat proiectului s-a încheiat)

Feluri de terminare a unui proiect:

• Extinctie (proiectul se termină prin succes sau eșec și, pe viitor, nu se va mai lucra la proiect)
• Terminare prin adiție (proiectul se termină cu succes și, pe viitor, echipa care a dezvoltat proiectul se va ocupa de mentenanța produsului)
• Terminare prin integrare (proiectul se termină cu succes și resursele sunt reintegrate în alte proiecte ale companiei – modul cel mai frecvent)

• cuprinde activitățile rămase din cadrul proiectului
• cuprinde activitățile colaterale ce trebuie realizate pentru a încheia proiectul în conformitate cu procedurile actuale:
  • completarea și distribuirea rapoartelor de performanță
  • completarea și distribuirea documentației sistemului
  • completarea auditurilor de calitate
  • completarea auditurilor de vânzare
  • revizia sistemului împreună cu help desk
  • întâlnirea cu staff-ul operațional care urmează să preia software-ul (în vederea mentenanței)
  • împlinirea cerințelor de training ale staff-ului operațional
  • primirea sign-off-ului de la staff-ul operațional
  • oferirea detaliilor despre performanța membrilor proiectului (evaluarea echipei și evaluările individuale ale membrilor și a PM-ului)
  • primirea sign-off-ului de acceptare de la client și acceptarea formală a tuturor livrabilelor proiectului.

În cazul în care se folosește un sistem de bug/issue tracking, trebuie ca toate issue-urile să fie rezolvate înainte de finalizarea proiectului chiar dacă ele nu au fost incluse în specificații.

În cazul în care nu se poate acest lucru, cei care predau proiectul trebuie să se asigure că problemele rămase deschise sunt de prioritate scăzută și nu au un impact major asupra funcționalității.

• se decide terminarea proiectului
• se obțin aprobările necesare (de la clienți, sponsori)
• se comunică decizia părților interesate
• se realizează activitățile rămase din proiect și cele colaterale
• se face post-performance analysis
• se publică raportul final
• se sărbătorește terminarea proiectului
• se reasignează resursele (persoane și echipamente)
• se efectuează închiderea financiară și administrativă

Încheierea unui proiect nu presupune numai livrarea produsului, ci și oportunitatea de a învăța din această experiență pentru îmbunătățirea contribuțiilor la proiectele viitoare.

Recomandări:

• analiza finală a proiectului să se bazeze pe metrici (așa se pot cuantifica acurat rezultatele);
• exemplu de metrici:
  1. calitatea produsului:
     1. Defects per KLOC (Kilo Line Of Code): numărul de buguri per KLOC, unde KLOC este unitatea de măsură pentru codul produsului
     2. MTTC (Mean Time To Change): cât timp este necesar pentru a localiza eroarea, a proiecta repararea, a o implementa si testa
     3. threat probability: probabilitatea atacurilor ce exploatează vulnerabilitățile produsului pe o perioadă de timp
     4. security probability: probabilitatea eliminării vulnerabilităților pe o perioadă de timp
  2. calitatea activităților QA:
     1. Test Coverage: numărul de unități testate (KLOC/FP) / dimensiunea sistemului, unde FP (function point) este unitate de măsură pentru codul produsului din perspectiva funcționalității de business oferite
     2. Number of tests per unit size: numărul de teste per KLOC/FP
     3. Cost to locate defect: costul de testare / numărul de defecte detectate
  3. Quality of Testing: E / ( E + D ), unde E este numărul de erori identificate înainte de livrarea produsului, D numărul de erori identificate după livrare
     1. System complaints: numărul de plângeri din partea clienților / numărul de plângeri rezolvate
     2. Test Planning Productivity: numărul de teste proiectate / efortul pentru proiectarea și documentarea testelor
     3. Test Execution Productivity: numărul de cicluri de testare executate / efortul de testare
     4. Test efficiency: numărul de teste solicitate / numărul erorilor sistemului

• să se determine cauzele ce au condus la valorile finale ale metricilor
• să se rețină și să se înțeleagă aceste cauze, să se determine ce posibilități ar fi existat/ar exista pentru a evita producerea acestor cauze, ce posibilități sunt de stimulare a producerii a acestor cauze
• să se colecteze valorile reutilizabile care au fost produse în cadrul proiectului (proceduri, checklisturi, guidelines) și să se facă publice

PPA:

• este analiza situației finale a proiectului în vederea concluzionării asupra factorilor de succes și a modalităților de stimulare a lor, precum și asupra factorilor de insucces și a modalităților de prevenire, rezolvare a efectelor lor
• este analiza ce stimulează procesul de învățare din experiența proiectului
• este recomandat să se realizeze periodic (imediat după milestone-uri) pentru a putea folosi concluziile analizei chiar in faza următoare

Procesul PPA are următorii pași:

1. invitarea echipei la analiză (propunând ca fiecare membru să reflecteze asupra factorilor de succes/insucces și să vină cu propuneri de îmbunătățire – se trimite un chestionar de analiză)
2. colectarea individuală a feedback-ului fiecărei persoane implicate în proiect (individual pentru a înțelege întreaga panoramă a proiectului)
3. realizarea unei întâlniri a echipei în vederea concluzionării asupra: ce și cum s-a întâmplat, în ce moduri ar fi putut fi prevenite/soluționate problemele?
4. publicarea și arhivarea sumarului PPA.

În general, se folosește un chestionar pentru colectarea informațiilor. De obicei, acesta are conținut diferit între team leaderi și team memberi.

Câteva întrebări de chestionar sunt cele de mai jos:

1. Identificați lucrurile care au mers bine în cadrul acestui proiect.
2. Identificați lucrurile care au mers prost în cadrul acestui proiect.
3. Ce evenimente neprevăzute au afectat pozitiv sau negativ desfășurarea proiectului?
4. În cadrul acestui proiect, ce lucruri ați face diferit dacă ar fi repornit?
5. Descrie un lucru pe care tu l-ai fi putut realiza personal pentru a îmbunătăți calitatea produsului obținut din cadrul acestui proiect.
6. Ai fost informat despre ceea ce se așteaptă de la tine în cadrul acestui proiect?
7. Au fost rolurile membrilor echipei definite clar?
8. Echipa a făcut tot ce se putea face pentru a duce la bun sfârșit acest proiect?
9. Cum s-a comportat echipa în ansamblul său?
10. Care a fost componenta cea mai satisfăcătoare din cadrul proiectului?

Un exemplu complet de chestionar găsiți aici

1. Descrieți sumar conțintul unui SQAP pentru proiectul vostru.
   • Parcurgeți secțiunea Software Quality Assurance Plan
2. Pregătiți un checklist pentru terminarea proiectului vostru. Argumentați!
   • Parcurgeți secțiunea Terminarea unui proiect
3. Răspundeți la întrebările de la procesul PPA pentru proiectul vostru.
   • Parcurgeți secțiunea Post-Performance Analysis