TSM - Bune practici pentru asigurarea calităţii produselor software: auditarea proceselor de dezvoltare software

Monica Chiș - Freelancer IT Software Consultant și Trainer

Cuvântul calitate este prezent în conversaţiile noastre zilnice. Avem nevoie de produse şi servicii de calitate. Avem nevoie de produse software de calitate, platforme la care să avem acces 24 de ore din 24, fără întreruperi şi disfuncţionalităţi, uşor accesibile, care ne permit să executăm toate acţiunile dorite.

Calitatea software nu înseamnă doar să livrăm un produs care respectă specificaţiile clientului şi funcţionează perfect pentru utilizatorul final, ci înseamnă să respectăm o serie de procese de dezvoltare bazate pe standarde, pe guidelines de anumite proceduri. Lipsa unui plan de calitate, a unor obiective clare de calitate, a unor metrici şi KPIs care să ne ajute în evaluarea produsului software, a înţelegerii factorilor de calitate (definiţi în standard-ul ISO 25010) sunt doar câţiva dintre factorii care afectează calitatea produselor software.

Putem avea un produs software care să aibă o interfaţă prietenoasă, completă din punctul de vedere al cerinţelor funcţionale, dar codul sursă nu respectă regulile de bază ale tehnologiei folosite. În aceste condiţii şi mentenanţa software-ului este dificilă şi costisitoare, adică se plătește costul proastei calităţi.

Tehnologiile folosite astăzi sunt complexe, există foarte multe sisteme care au nevoie de integrare. Integrarea aplicaţiilor presupune interconectarea mai multor sisteme informatice, la nivel de informaţii şi servicii, astfel încât sistemele să fie capabile să facă schimb de informaţii şi să asigure o funcţionare proceselor în timp real.

Ce putem face pentru a îmbunătăţi calitatea produselor software? În acest articol ne vom referi la una dintre soluţiile pentru perfecționarea proceselor de livrare şi anume auditul SDLC (Software Development Life Cycle) - SDLC Audit.

Puţină teorie...

Auditarea proceselor de dezvoltarea software ne poate ajuta să înţelegem problemele care apar în faza de dezvoltare software, să găsim soluţii pentru îmbunătăţiri ale proceselor şi, mai mult decât atât, să lucrăm împreună cu echipele de dezvoltare pentru a rezolva problemele "în timp real", într-un proces de ameliorare continuă. Vom folosi în continuare termenul SDLC şi audit SDLC.

Nu vom insista asupra noţiunilor teoretice, vom menţiona aici doar câteva noţiuni de bază pe care le utilizăm în acest articol: SDLC, audit, calitatea software, audit SDLC.

Asigurarea calităţii software trebuie planificată, deoarece calitatea unui produs software nu se asigură doar în faza de testare. Avem nevoie de procese de dezvoltare software bine definite, perfecționate continuu.

Software Development Life Cycle (SDLC) - Ciclul de viață al dezvoltării software este un proces structurat care permite producerea de software de înaltă calitate, cu costuri reduse, în cel mai scurt timp de producție posibil. Scopul SDLC este de a produce software care să îndeplinească și chiar să depășească toate așteptările și cerințele clienților. SDLC definește și conturează un plan detaliat cu etape sau faze, fiecare cuprinzând unul sau mai multe procese) și livrabile. Aderarea la SDLC mărește viteza de dezvoltare și diminuează riscurile și costurile proiectului.

Există diverse modele SDLC utilizate în proiecte: Waterfall, Agile, Iterative Model, V-Model şi mai nou DevOps.

Procesul de asigurare a calităţii reprezintă un ansamblu de acţiuni prestabilite şi sistematice referitoare la calitate, cu scopul de a oferi încrederea, certitudinea că produsul/serviciul va satisface un anumit nivel calitativ.

Auditul este o parte integrantă a activităţii de asigurare a calităţii software. Un audit independent presupune parcurgerea etapelor de dezvoltare software, analiza lor în conformitate cu procesele descrise în companie şi elaborarea unor sugestii de îmbunătăţire. Auditul parcurge şi anumiţi paşi pentru analiza modului în care modelul de SDLC ales este utilizat.

În activitatea de dezvoltare software exista doi factori de bază: client şi echipa tehnică. Din punctul de vedere al clientului exista trei aspecte importante: cost, timp şi funcţionalitate. Din punctul de vedere al echipei tehnice de dezvoltarea sunt alte aspecte importunate: persoanele, procesele şi tehnologia.

Considerăm că este esențial să ţinem cont de aceste aspecte pe parcursul unui audit SDLC.

Standardul ISO/IEC/IEEE 12207:2017

Nu putem să vorbim de un audit SDLC fără a menţiona un standard care stă la baza unui astfel de audit. Nu vom insista foarte mult asupra standardului pentru că, în general, prezentarea unui standard fără exemple concrete este greu de urmărit.

ISO/IEC/IEEE 12207:2017 - Systems and software engineering - Software life cycle processes stabileşte un set de procese pentru managementul ciclului de viaţă al unui produs software.

Standardul ISO/IEC/IEEE 12207:2017 este versiunea publicată în Noiembrie 2017. ISO/IEC/IEEE 12207:2017 oferă, de asemenea, elemente care pot fi utilizate pentru definirea, controlul și îmbunătățirea proceselor de dezvoltare software pe tot parcursul ciclului de viață al unui produs, în cadrul unei organizații sau în cadrul unui proiect.

Aşa cum este menţionat în prezentarea standardului ISO/IEC/IEEE 12207:2017, acesta nu prescrie un model specific de SDLC, o metodologie de dezvoltare software, o metodă sau o tehnică. Standardul utilizează două noţiuni importante: etapă sau fază (stages) şi proces. Fazele de dezvoltare nu sunt aceleaşi cu procesele.

Procesul este definit ca un set de activități interdependente sau care interacționează care transformă intrările în ieşiri.

ISO/IEC/IEEE 12207:2017 împarte procesele legate de ciclul de viață al software-ului în patru grupuri principale de procese: agreement processes (aici intră achiziţie şi livrare, organizational project-enabling, technical management processes și technical processes. În fiecare dintre aceste patru grupuri de procese se află o varietate de subcategorii, inclusiv activitățile primare de achiziție și furnizare, configurare (management tehnic) și operarea, livrare și întreținerea (procese tehnice).

În acest articol nu vom trata fiecare capitol din standard şi nu vom parcurge standardul punctual. Ne vom referi doar la câteva aspecte generale folosite în audit. Nu este singurul standard utilizat pentru auditarea proceselor de dezvoltare software. El are legătură cu multe standarde specifice anumitor etape.

Auditul SDLC

Dacă am vorbit despre noţiuni şi standard, trebuie să vedem ce presupune un audit tehnic. Precizăm de la început că articolul are un scop introductiv.

Auditul SDLC este un proces continuu care are ca scop maximizarea succesului unui proiect prin detectarea riscurilor și punctelor slabe potențiale ale acestuia. Un astfel de audit examinează tehnicile și instrumentele de inginerie software utilizate pe parcursul etapelor de dezvoltare software, "adaptat" modelului SDLC ales.

Un audit SDLC se poate face oricând pe parcursul ciclului de dezvoltare software. Dacă audităm un proiect în fazele incipiente, vom avea șanse mai mari de a îmbunătăți calitatea produsului dezvoltat.

Pe parcursul auditului vom analiza fiecare fază de dezvoltare software şi toate procesele corespunzătoare, axându-ne pe tehnici, documente, instrumente (tools) şi proceduri utilizate pentru dezvoltarea software.

O procedură de audit generală cuprinde următoarele faze:

În opinia noastră, în urma analizei rezultatului unui audit există posibilitatea de a lucra cu echipe de dezvoltare pentru a dezbate şi implementa soluţiile propuse ca îmbunatăţiri pentru procesele de dezvoltare software.

Pregătirea şi planificare unui audit presupune:

  1. Clarificare scopului global şi stabilirea obiectivelor auditului;

  2. Înţelegerea contextului general de dezvoltare software al organizaţiei;

  3. Înţelegerea proiectului: obiectiv, tehnologii, metodologii, instrumente de lucru;

  4. Definirea scopului auditului pentru proiect;

  5. Stabilirea unui plan: ce audităm, când audităm, cum se organizează şedinţele de audit şi cine participă.

Analiza (sau caracterizarea) proceselor de dezvoltare software presupune în linii mari:

Evaluarea şi pregătirea raportului de audit presupune analiza informaţiilor colectate în timpul şedinţelor de audit, prezentarea problemelor cu explicaţia aferentă (de ce este o problemă de calitate a software-ului) şi a modului în care afectează procesul de dezvoltare software şi apoi formularea unei recomandări. Raportul de audit trebuie discutat cu echipa şi stakeholderi interni pentru a stabili paşii de urmat.

În urma deciziei de implementare a unei recomandări, se oferă suport echipei pentru implementarea unei soluţii. Aceasta este o abordare modernă care poate ajuta procesul de îmbunătăţire continuă şi poate ajuta organizaţia în construirea unei culturi a calităţii în dezvoltare software.

După o perioadă de timp, stabilită de comun acord cu organizaţia şi echipa de proiect, se face un follow-up. Fără această fază este posibil ca anumite soluţii propuse să nu fie implementate deloc sau să nu fie implementate corespunzător. Este posibil să descoperim la follow-up că, pe parcursul implementării unor sugestii de îmbunătăţire s-au corectat şi procesele colatarele. Putem însă, să constatăm şi faptul că sunt şi alte aspecte care au nevoie de analiză, aspecte care au apărut în urma anumitor ameliorări.

Aspecte analizate în timpul auditului SDLC

Nu vom putea da o reţetă generală pentru un audit. Aşa cum am menţionat, trebuie să cunoaştem organizaţia, contextul în care este dezvoltat proiectul şi proiectul efectiv.

Menţionăm în continuare câteva aspecte analizate în timpul auditului:

  1. Modelul SDLC utilizat, abordare, workflow de dezvoltare, organizarea proiectului, responsabilităţi, instrumente utilizate;

  2. Structura documentaţiei;

  3. Reguli de comunicare în echipe, între echipe şi stakeholderi;

  4. Specificaţiile: Un aspect foarte important în procesul de dezvoltare este modul în care customer requirements ajung la echipa de dezvoltare, modul în care sunt clarificate requirementurile şi tipurile de requirement utilizate; se analizează şi modul în care este monitorizată şi menţinută traceability de la requirements-arhitectură-design la cod şi teste;

  5. Existenţa documentelor de arhitectură şi design şi procedurile specifice de realizare a designului;

  6. Software configuration management (repository, version management, works space control)

  7. Codul sursă: se analizează coding standards utilizate, procedurile necesare utilizate pentru clean code, modul în care se face revizuirea codului (automat şi manual), regulile de commit, reguli de logging şi alte aspecte legate de partea de implementare. Atunci când se auditează partea de coding trebuie să analizăm dacă pentru toate tehnologiile folosite sunt accesibile instrucţiuni clare legate de cod, dacă este un tool care face analiza automată a codului, dacă există reguli pentru scrierea codului (naming convention). Pe scurt, analizăm dacă există un proces general prin care ne asigurăm că avem o preocupare pentru calitatea codului. În cazul în care avem integrarea cu mai multe sisteme trebuie să analizăm şi modul în care este realizată şi documentaţia de integrare;

  8. Modul în care echipa înţelege tot ceea ce trebuie făcut pentru a livra funcţionalitatea completă a produsului;

  9. Viziunea pe care o are echipă asupra taskurilor necesare pentru a livra pachetele software complete;

  10. Strategia de testare adoptată (tipurile de testare), mediile de testare utilizate, modul în care se obţin datele de test, documentaţia aferenta testării;

  11. Analiza non-functional requirements (performance, security, maintainability şi altele) ;

  12. Procesul de deployment (continuous integration, continuous deployment, continuous delivery);

  13. Modul în care sunt gestionate defectele;

  14. Planul de asigurare a calităţii: obiective de calitate, metrici utilizate şi KPIs utilizaţi în procesul de dezvoltare;

  15. Modul în care sunt gestionate schimbările în aplicaţie;

  16. Procesul de îmbunătăţire continuă.

Auditul este diferit în funcţie de proiect şi metodologie, dar în ansamblu scopul lui este acelaşi: creșterea calităţii produsului software bazându-ne pe o analiză a proceselor de dezvoltare.

Pentru fiecare etapă de dezvoltare software există standarde specifice la care ne putem raporta.

Concluzii

Auditul SDLC ne înlesnește identificarea de probleme în procesele de dezvoltare software. În opinia noastră, auditul SDLC poate ajuta în construirea unei culturi a calităţii software. Se pot identifica discrepanţe majore între cerinţele clientului şi software-ul livrat, în timp util, mai ales în procesul de dezvoltare iterativ. Auditul SDLC oferă o oportunitate de atenuare a riscurilor potențiale.

Un astfel de audit nu trebuie privit ca un control al proiectului. Şedinţele de audit pot fi abordate într-o manieră colaborativă în care să se şi dezbată anumite probleme pe care echipele le au în procesul de dezvoltare. Într-o astfel de şedinţă pot fi găsite soluţii pentru anumite probleme existente.

Considerăm că este foarte util ca după identificarea problemelor să se lucreze punctual pentru soluţii adaptate organizaţiei, echipei şi proiectului.

Utilizând analizele auditurilor tehnice, organizaţiile IT pot să determine probleme majore în procese de dezvoltare software pe care le pot rezolva progresiv.

Referinţe bibliografice:

  1. "ISO/IEC 25010:2011", Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.

  2. IEEE/ISO/IEC 12207-2017 - ISO/IEC/IEEE International Standard - Systems and software engineering - Software Life Cycle processes

  3. Pressman, R. S., & Maxim, B. R. (2015). Software engineering: A practitioner's approach. New York: McGraw-Hill Higher Education.

  4. Product revision Quality Factors: https://www.gristprojectmanagement.us/software-4/product-revision-quality-factors.html