Calitatea unui produs este acea caracteristică ce îl diferențiază față de alte produse similar disponibile pe piață - este una dintre cele mai răspândite definiții. Calitatea înseamnă să îndeplinești așteptările clientului, la un cost pe care clientul își permite (sau dorește) să îl plătească, astfel încât noi, furnizorul de produse sau servicii, să ne putem continua activitatea și mâine sau în zilele următoare. Un produs fără defecte nu înseamnă neapărat că acesta este și de bună calitate.
Calitatea unui produs sau serviciu este atât de bună pe cât clientul sau utilizatorul final o simte, în funcție de ce așteptări are de la produsul sau serviciul nostru și de cât de mult aceste așteptări sunt îndeplinite. Bineînțeles, un produs fără buguri are șanse mai mari să fie perceput ca un produs de calitate, dar aceasta e doar o parte a întregului. O parte importantă, într-adevăr, dar doar o parte. Asigurarea calității, sau Quality Assurance - pe scurt QA, reprezintă întregul set de activități ce au ca scop crearea unui produs de calitate. Se compune din activități cu rol preventiv și activități corective ce ne asigură (pe noi și clientul!) că ceea ce livrăm va îndeplini așteptările clientului. Aceste așteptări derivă din felul în care utilizatorul final își imaginează că ne va folosi produsul, trebuie îndeplinite diferite standard legale sau din alte domenii sau chiar și din așteptările clienților lor.
V-Model schema
Provocările în industria dezvoltării embedded software pentru piața auto sunt diferite (cel puțin) de provocările întâlnite în alte domenii ale programării: hardware-ul și software-ul sunt strâns legate. De cele mai multe ori hardware-ul diferă de la un furnizor la altul; resursele hardware sunt de asemenea foarte limitate; sistemele dezvoltate trebuie să reacționeze în timp real; modificările (update-uri, patches) nu se pot face ușor, iar durata de viață poate ajunge la zece sau mai mulți ani în condiții de capacități foarte reduse (aproape inexistente) de mentenanță. Un eventual defect într-un sistem ce gestionează un magazin online poate face să se piardă câteva comenzi, dar o defecțiune a ESP-ului, a Engine Control Unit sau a airbagului într-o mașină ce rulează cu viteză pe șosea poate duce la răniri grave sau chiar mai rău. Comunicarea între departamentele sau organizațiile ce construiesc asemenea sisteme este esențială pentru succesul proiectului, fiind foarte important ca toate părțile implicate să vorbească aceeași limbă. În industria automotive , un proiect nu înseamnă doar dezvoltarea de software: părțile hardware sau mecanice (fie că vorbim despre un vitezometru, ABS sau noul sistem de andocare pentru smartphone) fac parte din același întreg și se vând împreună, ca un singur produs. Echipele ce dezvoltă părțile unui astfel de sistem sunt distribuite pe tot globul, chiar dacă sunt membri ai aceleiași organizații.
A include cât mai devreme calitatea într-un astfel de produs este o mare provocare. Înseamnă alinierea cerințelor clientului cu echipe din toată lumea în timp ce eventualele cerințe legale sau cele specifice industriei auto (obligatorii în multe cazuri) sunt de asemenea luate în considerare. Din fericire, noi dezvoltatorii software, putem beneficia de experiența acumulată în industria auto în cel mai mult de 100 de ani de istorie - aproximativ de 4 ori mai mult decât cei ce au trecut de când dezvoltarea software a devenit populară iar calculatoarele și programele au devenit aproape utilități publice. Producătorii de automobile au creat și folosit primii procese de producție și tot ei au fost printre primii care au fost obligați să aplice reguli/cerințe legale și de siguranță.
După această scurtă introducere despre calitate și de ce calitatea trebuie inclusă în produsele dezvoltate de noi, să vedem și cum poate fi realizată. Vom vedea cum poate beneficia industria software de experiența căpătată de industria auto în ultima sută de ani.
Managementul calității în proiectele automotive e abordat având la bază procesele de producție. Sunt trei modele, standarde industriale ce stau la baza unui astfel de sistem de management al calității:
ISO/TS 16949 -Quality management systems—Particular requirements for the application of ISO 9001:2008 for automotive production and relevant service part organizations;
CMMI -Capability Maturity Model Integration;
De fapt, e vorba de o variantă a SPICE, Automotive-SPICE or ASPICE, ce a fost dezvoltată de un grup al celor mai mari producători pentru a se asigura că există o viziune comună asupra calității. Treptat A-SPICE a devenit standardul de facto în rețeaua de furnizori din industria auto.
Pe baza acestor trei piloni și luând în considerare și alte standarde ale industriei (ISO/IEC 9001 sau V-Model) precum și nenumărate solicitări sau specificații ale clienților, orice organizație ce dorește să intre pe această piață va trebui să își creeze un sistem intern de management al calității. Un sistem de management al calității va fi un punct forte în favoarea organizației ce l-a implementat în fața oricărui competitor sau posibil client. Existența unui astfel de sistem ce este aplicat zilnic în toate ariile și la toate nivelurile organizației va permite să se învețe din experiențele anterioare, va îmbunătăți estimările și va iuți procesul de învățare, ceea ce conduce la scăderea costurilor de producție - un alt avantaj în fața organizațiilor concurente. Fiecare va ști exact ce are de făcut și în ce moment. Va cunoaște exact informațiile de care are nevoie pentru a-și îndeplini cu succes activitățile zilnice și de asemenea care sunt rezultatele așteptate în urma acestor activități. Știind exact ce are fiecare de făcut se pot defini măsurători ce pot fi la rândul lor folosite ca bază pentru îmbunătățiri ulterioare. Metricile colectate în timp se pot folosi în timpul prezentărilor către noi (posibili) clienți, arătându-le astfel că noi, furnizorul produsului sau serviciilor, putem livra conform așteptărilor iar sumele ce se vor cheltui vor fi date pe un produs înalt calitativ, dovedind o mentalitate orientată spre calitate încă din fazele incipiente ale unui proiect, în toate aspectele ce fac tranziția de la idee la realitate.
Automotive SPICE - modelul de referință
Modelele SPICE și CMMI grupează activitățile zilnice dintr-o organizație în arii de proces cum ar fi procese de dezvoltare (engineering) - dezvoltare de produs sau de specificații, managementul schimbărilor; procese de management - management de proiect sau managementul performanței; procese suport (organizaționale) - managementul proceselor, organizarea trainingurilor, managementul furnizorilor. Fiecare arie de proces este descrisă în detaliu, inclusiv ceea ce se așteaptă să fie disponibil la pornirea procesului precum și ceea ce se așteaptă să fie realizat la sfârșitul lui. O caracteristică importantă a proceselor descrise de modelele de mai sus este nivelul de maturitate ce exprimă cât de bine este executat acel proces, prin evaluarea a diferite atribute ale procesului. Sunt 6 nivele de maturitate a proceselor, pornind de la 0 (zero, ce reprezintă un "proces" incomplet, în care nu se cunosc etapele și activitățile ce ar trebui executate și care nu își atinge scopul) până la nivelul 5 (procesul este optimizat și îmbunătățit continuu) trecând prin nivelul 3 în care un proces este bine definit și reprezintă un standard intern al organizației, fiind urmat de toate departamentele.
Nivelul de maturitate atins de implementările modelelor CMMI sau ISO pot fi certificate de organizații independente, cu acordul creatorilor modelului (SEI sau ISO). Procesul de certificare este standardizat și se repetă la intervale bine stabilite. În ce privește modelul A-SPICE nu există un proces de certificare standardizat, cu toate că este acceptat de majoritatea furnizorilor din industria auto. Nu există un certificat care să ateste că sistemul intern de management al calității urmează modelul A-SPICE și nici nivelul de maturitate atins. În practică, fiecare producător poate cere prin contract furnizorilor existența unui sistem de management al calității conform modelului A-SPICE și un anumit nivel de maturitate de la fiecare echipă ce dezvoltă produsul pe care îl cumpără. Organizațiile ce tind să devină furnizori pentru industria auto vor trebui să fie capabile să dovedească clienților (prin audituri ale clientului, ad-hoc sau periodic) că urmează un proces conform cu A-SPICE, la nivelul de maturitate stabilit în contract, în toate ariile de proces.
Nivele de maturitate conform modelului CMMI.
Desigur, un proces de producție nu trebuie să fie rigid sau folosit fără o minimă analiză în proiecte diferite. Procesele de producție sunt vii, trebuie să evolueze constant pe măsură ce se câștigă experiență din execuția lor. Organizațiile trebuie să investească în dezvoltarea proceselor după care să se execute activitățile zilnice și să creeze un mediu care să permită această evoluție astfel încât procesele să devină obiceiuri, a doua natură pentru fiecare membru al său!
Definirea unui set de procese de producție sau suport la nivelul organizațional nu reprezintă decât jumătate dintr-un sistem de management al calității! Acestea nu sunt decât sugestii ce trebuie apoi puse în practică la nivelul proiectelor - acolo unde, zi de zi, se creează produsul. Această abordare -instanțierea unor procese definite la nivel organizațional în echipe de proiect- trebuie făcută cu mare atenție pentru a nu împiedica rutina zilnică prin adăugarea de activități fără valoare pentru scopul final al proiectului, lucru ce poate duce la întârzieri sau acumularea de tensiuni în echipă, între echipă și organizație sau (în cel mai rău caz) între echipă și client. Echipele de proiect trebuie să fie conștiente că investind o cantitate mică de resurse (timp) în activități preventive, cât mai devreme în proiect, va beneficia de o reducere în costurile de reparație (bugfixing) din etapele finale ale proiectului. O zi în care se analizează și se asigură că s-au înțeles așteptările clientului poate înlocui două sau trei zile de reparat defecte sub presiunea livrării. Aceleași considerente se aplică și necesității de a documenta fiecare decizie ce s-a luat poate într-o convorbire telefonică cu clientul sau pentru a ne asigura că dezvoltatorul a înțeles designul arhitectului sau că echipa de testare a înțeles funcționalitatea ce urmează a fi testată - iar lista nu se oprește aici.
Definirea și întreținerea unui sistem de management al calității bazat pe procese presupune un efort susținut. Trebuie colectate impresiile, feedback-ul din proiecte ce folosesc acele procese; aderența trebuie verificată periodic astfel încât definiția procesului să poată fi îmbunătățită. Mai mult, echipele de proiect trebuie susținute în timpul implementării proceselor definite la nivel de organizație; este nevoie de îndrumare pentru stabilirea unor obiective de calitate fezabile și pentru eventuale ajustări necesare astfel încât procesul implementat să nu devieze prea mult de la o metodă ce și-a dovedit utilitatea dar în același timp să nu îngrădească inovațiile ce pot eventual să apară. Și totul trebuie făcut fără compromisuri în ce privește calitatea produsului finit.
Persoana ce se află în centrul atenției în acest caz este Inginerul de Calitate (Software Quality Engineer sau SWQE). Este acea persoană care cunoaște în amănunt definiția proceselor dar și rutina zilnică din interiorul echipei. Este responsabil de instanțierea proceselor definite la nivelul organizației în interiorul ecosistemului reprezentat de proiect (echipă, tehnologii). Cu toate acestea, inginerul de calitate NU este membru al echipei de proiect! Există (ar trebui să existe) o ramură diferită în ierarhia companiei destinată acestui rol. Prin aceasta se asigură independența față de ierarhia din proiect a persoanei ce îndeplinește acest rol. Această independență aduce cu sine și unele dezavantaje - prin limitarea capacității de a stopa eventuale practici sau obiceiuri riscante pentru calitate. Nu înseamnă că este imposibil - dar este destul de dificil. Depinde mult de abilitățile de comunicare ale inginerului de calitate - un team-leader sau manager de proiect poate fi convins sau determinat să acționeze în direcția propusă de SWQE dacă poate aduce suficiente dovezi în favoarea sa, eventual însoțite de exemple practice sau rezultate obținute prin măsurători. Măsurătorile necesare monitorizării sistemului de management al calității sunt de asemenea în responsabilitatea inginerului de calitate, urmate firesc de etapa de raportare către quality-manager. Sau chiar către client dacă specificațiile contractuale o cer. Munca unui SWQE acoperă toate aspectele ciclului de viață al unui proiect -există procese definite fiecărui rol din echipă, de la managerul de proiect până la requirement engineers, programatori, testeri, integratori, indiferent de nivelul de senioritate. Inginerul de calitate nu este un polițist, el (sau ea) este un consilier ce ajută echipa de proiect să nu piardă din vedere calitatea - scopul final al tuturor activităților din fiecare etapă a ciclului de producție. Iar dacă situația o cere, inginerul de calitate este în prima linie atunci când clientul cere dovezi că echipa lucrează în conformitate cu modelul și nivelul de maturitate descris în contract; este primul responsabil și obligat să identifice soluții atunci când, în urma unui audit, se descoperă neconformități.
Managementul calității și accentul pus pe asigurarea calității încă din stadiile incipiente ale dezvoltării unui produs sunt obligatorii în orice organizație. Industria software din Cluj a evoluat de la zorii outsourcingului până la asumarea responsabilităților în toate aspectele ce țin de succesul unui proiect (management, requirements, dezvoltare sau testare la toate nivelurile). Dezvoltarea "embedded software" a urmat aceeași cale. Echipele de ingineri și-au dovedit profesionalismul ca parteneri valoroși pentru mulți jucători mari ai industriei ceea ce le-a oferit ocazia să învețe de la cei mai buni la nivel mondial. Clienții produselor ce folosesc "embedded software" cer furnizorilor produse înalt calitative iar noi va trebui să dovedim că avem capacitatea să le îndeplinim aceste cerințe. Tot mai multe organizații locale își definesc sisteme interne de management al calității ce sunt mai apoi certificate în conformitate cu un model sau altul dintre cele menționate la începutul articolului. Companiile ce dezvoltă software "embedded" nu ar trebui să fie diferite din acest punct de vedere iar sistemele de management al calității nu ar trebui să fie privite ca ceva exotic, ținând cont că auditurile cerute de clienții produselor embedded sunt ceva obișnuit în zilele noastre.
Din punct de vedere al dezvoltării personale, următoarea data când veți citi un anunț despre un post de QA Engineer veți putea avea ocazia să puneți întrebările corecte într-o eventuală discuție cu recrutorul. Există un sistem intern de management al calității? Ce standard sau model s-a folosit pentru definirea lui? Cât de devreme într-un proiect nou se discută despre calitatea produsului ce va fi construit și livrat? Discuția va fi mult mai interesantă, garantat!
Peter Leeson, http://www.qpit.net/blog.html
www.automotivespice.com/fileadmin/software.../Automotive_SPICE_PAM_30.pdf
de Davide Corda
de Adrian Vîntu
