6.

Managementul calității

6.1. Specificul managementului calității la nivel de proiect

Managementul calităţii include procesele necesare pentru a asigura faptul că proiectul

va satisface cerinţele pentru care este realizat. Calitatea reprezintă conform SR EN ISO
9000:2015„măsura în care un ansamblu de caracteristici intrinseci ale unui obiect îndeplineşte
cerinţele”.
Managementul calităţii este centrat pe aspectele:
Satisfacţia clientului: înţelegerea cerinţelor astfel încât aşteptările clientului să fie
satisfăcute sau depăşite. Proiectul trebuie să fie conform cu specificaţiile şi potrivit pentru
utilizare (trebuie să satisfacă nevoi reale);
Evaluarea și gestionarea riscurilor: costul evitării erorilor este întotdeauna mult mai
mic decât costul corectării acestora;
Responsabilitatea managerială: pentru asigurarea succesului proiectului este
necesară participarea tuturor membrilor echipei, însă rămâne responsabilitatea
managementului să asigure resursele necesare pentru reuşită;
Procesele organizate pe faze, iteraţii ale ciclului Deming: planificare-realizare-
verificare-acţiune (engl. “Plan-Do-Check-Act”, PDCA)
Procesele principale ale managementului calităţii aplicabile în orice tip de proiect sunt:
Planificarea calităţii: identificarea standardelor de calitate relevante pentru proiect şi
determinarea modului în care vor fi satisfăcute;
Asigurarea calităţii: evaluarea performanţei globale a proiectului în mod regulat
pentru a stabili încrederea că proiectul va satisfice standardele de calitate relevante;
Controlul calităţii: monitorizarea rezultatelor proiectului pentru a determina dacă
acestea sunt în conformitate cu standardele şi pentru a identifica modalităţile de eliminare a
cauzelor performanţelor nesatisfăcătoare.
Unul din scopurile managementului calităţii este controlul variaţiei –foarte important
la produse de serie. În cazul produselor software, acesta se referă de exemplu la minimizarea
diferenţei dintre resursele planificate şi cele reale.
Specificul Managementului calității la nivel de proiect rezidă în înțelegerea contextului
proiectului. Principiile de management sunt comune cu cele descrise în ISO 9001:2015 și ISO
10006:2017, standard care este total compatibil cu PMBOOK, ediția VI, capitolul 8. Ținând
cont de specificul produselor dezvoltate prin proiecte (sisteme informaționale, sisteme și
aplicații software), se poate asigura repetabilitatea acțiunilor, monitoriza activitățile, asigura
managementul cu informațiile necesare în mod sistematic și planificat. În acest context,
utilizarea șabloanelor, standardizarea operațiilor și a proceselor, elaborarea rapoartelor –
constituie elemente care reduc considerabil timpul necesar pentru încheierea cu succes a unor
etape de proiect și garantează un minim de erori.
Metodologiile moderne de dezvoltare software, oferă șabloane, cerințe unice
standardizate pentru activități și evenimente desfășurate în proiect, inclusiv urmărirea și
raportarea; utilizarea de instrumente colaborative simple pentru a asigura comunicarea facilă
și transparența proiectului.
Posibilitatea de a utiliza sistematic metrici și metode de analiză predefinite țin sub
control procesele și garantează evoluția pozitivă și dezvoltarea previzionată, oferind un mare
beneficiu privind identificarea și prevenirea riscurilor, o viziune clară despre procesele și
activitățile din fiecare etapă ale unui proiect.
Ideea de bază care trebuie desprinsă este că un sistem adecvat de calitate permite
identificarea punctelor slabe și a căilor de îmbunătățire continuă a proceselor, operațiilor și
procedurilor tehnologice și că rolul metodologiei și a instrumentelor aplicate în derularea
unor proiecte este crucial pentru asigurarea calității.

Fig. 1. Necesitatea asigurării calității produselor software

6.2. Standardele în vigoare

Prezența unui mare număr de norme/standarde de calitate, creșterea cerințelor și
exigențelor clienților, creșterea complexității produselor și progresul tehnologic sunt aspecte
de care trebuie să se țină cont în implementarea unui sistem robust și eficient de calitate. În
acest sens se impune o analiză profundă și o cunoaștere interelaționată a celor mai bune practici
sau abordări ale calității, rezultatul necesar și așteptat fiind concretizat într-un ghid adecvat al
utilizării standardelor, relativ simplu și transparent, pentru a ajuta utilizatorul să facă alegerea
în concordanță cu propria strategie și politică de calitate a organizației.
Într-adevăr, la nivel mondial există diverse moduri de abordare a calității, de exemplu:
implementarea SMC conform standardului internațional ISO 9001:2015 sau a filosofiei
managementului calității totale (TQM), a managementului calității proiectelor (seria ISO
10000), a managementului calității software (conform seriei ISO 25000, Systems and software
quality requirements and evaluation, abreviat SQuaRE) etc. Există zeci de asemenea standarde,
dar ținând cont de specificul domeniilor de activitate (telecomunicații, transport, sănătate etc.),
de specificul platformelor, a activităților și a domeniilor de aplicare a sistemelor elaborate,
numărul standardelor este de câteva sute.
Deşi cu aplicabilitate generală, standardul ISO 9001 este adecvat dezvoltării şi
întreţinerii produselor software. ISO 9000-3 conţine „Principii pentru aplicarea standardului
ISO 9001 la produse software”. Acesta identifică problemele care trebuie rezolvate în mod
independent de tehnologiile utilizate, metodologii, procese de dezvoltare şi structuri
organizaţionale.
Secţiunile standardului ISO 9000-3 conţin:
cerinţe: ce trebuie îndeplinit pentru a obţine certificarea;
recomandări: ce ar fi bine de făcut pentru a ajuta la îndeplinirea cerinţelor.
Există 20 de prevederi în ISO 9001, interpretate de ISO 9000-3 pentru dezvoltarea software:
1. Responsabilitatea managerială. Politica de calitate trebuie definită, documentată,
înţeleasă, implementată şi întreţinută. Trebuie definite responsabilităţile şi autoritatea tuturor
membrilor echipei pentru specificarea, atingerea şi monitorizarea calităţii. Trebuie definite,
instruite şi finanţate resursele interne de verificare.
2. Sistemul de calitate. Trebuie stabilit un sistem de calitate documentat, având
informații documentate şi care este integrat în întreg ciclul de dezvoltare;
3. Analiza contractelor. Contractele trebuie analizate pentru a vedea dacă cerinţele sunt
definite adecvat, concordă cu oferta şi pot fi implementate;
4. Controlul proiectării. Trebuie stabilite proceduri de verificare a proiectării pentru a
asigura că cerinţele sunt îndeplinite şi că metodele de proiectare sunt utilizate corect;
5. Controlul documentelor. Distribuirea şi modificarea documentelor trebuie
controlate;
6. Achiziţiile: Produsele achiziţionate trebuie să fie conforme cu cerinţele specificate,
incluzând evaluarea subcontractorilor potenţiali şi verificarea produselor achiziţionate;
7. Produsele furnizate de cumpărător. Toate materialele furnizate de cumpărător
trebuie verificate şi întreţinute. Intră aici produsele software existente sau produsele COTS
(“commercial-off-the shelf”);
8. Identificarea şi trasabilitatea produselor. Trasabilitatea (engl.“traceability”) este
capacitatea de a regăsi istoricul, realizarea sau localizarea obiectului considerat. În cazul unui
produs, poate fi vorba de originea materialelor şi a părţilor componente, istoricul realizării,
distribuţia şi amplasarea produsului după livrare. Produsul software trebuie să poată fi
identificat şi urmărit pe parcursul tuturor fazelor de dezvoltare, livrare şi instalare;
9. Controlul proceselor. Procesele de dezvoltare trebuie definite şi planificate în
condiţii controlate şi în conformitate cu instrucţiuni documentate. Procesele speciale care
ulterior nu pot fi complet verificate sunt permanent monitorizate;
 10. Inspecţiile şi testarea. Se realizează inspecţii şi testări înainte de lansarea
produsului final. Trebuie găsit un echilibru între costul reparării defectelor şi costul inspecţiilor
pentru depistarea acestora. Rapoartele inspecţiilor şi testelor trebuie păstrate;
11. Echipamentele de inspecţie, măsurare şi testare. Echipamentele utilizate pentru
a demonstra conformitatea trebuie controlate, calibrate şi întreţinute. Când se utilizează
hardware sau software de testare, acestea trebuie verificate înainte de utilizare şi reverificate la
intervale stabilite;
12. Starea inspecţiilor şi testelor. Rapoartele privind starea tuturor articolelor de
configuraţie trebuie păstrate pe parcursul fazelor de prelucrare;
13. Controlul produselor neconforme. Produsele neconforme trebuie identificate
pentru a preveni propagarea utilizării lor în lanțul de furnizare
14. Acţiuni corective. Cauzele apariției produselor neconforme trebuie identificate, iar
neconformităţile eliminate.
15. Manipularea, stocarea, împachetarea şi livrarea. Trebuie stabilite proceduri
pentru aceste aspecte. În cazul produselor software, aici intră operaţiunile de multiplicare şi
instalare;
16. Rapoartele de calitate. Informaţiile despre calitate trebuie colectate, întreţinute şi
puse la dispoziţie când este nevoie persoanelor
17. Audituri interne de calitate. Auditurile trebuie planificate şi executate. Rezultatele
auditurilor sunt comunicate managementului iar deficienţele găsite trebuie corectate;
18. Instruirea. Trebuie identificate nevoile de instruire (engl. “training”) atunci când
activităţile necesită o calificare nouă. Rapoartele acţiunilor de instruire trebuie păstrate;
19. Întreţinerea. Activităţile de service trebuie îndeplinite după cum sunt specificate.
În cazul produselor software, acest punct se referă la întreţinere (engl. “maintenance”);
20. Tehnici statistice. Atunci când este posibil, trebuie identificate tehnici statistice
adecvate pentru verificarea capacităţii proceselor şi a caracteristicilor produselor. În cazul
produselor software, acest punct se referă la metrici sau alte modalităţi de măsurare.
Plecând de la aceeaşi idee, de a îndruma aplicarea cerinţelor specificate de ISO 9001,
au existat şi alte iniţiative de interpretare şi suport alături de ISO 9000-3 precum TickIT,
respectiv TickITplus https://www.tickitplus.org/en
Apare întrebarea firească, ce familii de standarde sunt actuale și necesare pentru a
asigura managementul calității proiectelor sistemelor și aplicațiilor software? Pentru multe
firme de dezvoltare software poate să nu fie clar pe ce standard să se bazeze la început: pe seria
ISO 9000; pe seria ISO 9126 sau pe seria ISO 25000; pe CMM (Capability Maturity Model),
CMMI (CMM Integrated) sau pe modele ierarhice de calitate software?
Alte organizaţii precum IEEE (Institute of Electrical and Electronics Engineers) au
publicat o serie de standarde care se referă la dezvoltarea de software şi la calitatea acestora.
Acestea pot fi observate în tabelul următor:
 IEEE 730 a fost intitulat „IEEE Standard for Software Quality Assurance Plans –
Standardul IEEE pentru planurile de asigurare a calităţii software” (SQAP). Aşa cum o spune
şi titlul, acest standard se concentrează asupra conţinutului planului de asigurare a calităţii, dar
şi asupra unor cerinţe de management, pentru dezvoltarea de software, precum necesarul minim
de documentaţie a reviziilor şi auditurilor de aplicaţii software. IEEE 730 tratează aproximativ
capitolul 4.4 „Design control” al normei ISO 9001.
Un sistem SQAP, descrie pentru un proiect sau produs, activităţile ce trebuie parcurse
în cadrul managementului calităţii şi nu conţinutul acestora. În general, standardele IEEE sunt
interpretate ca blocuri menite să reunească elemente şi activităţi în cadrul unui sistem de
management al calităţii. Acestea includ obiective pentru componentele individuale ale unui
sistem QMS (Quality Management System, software-specific), dar nu pentru întregul sistem al
calităţii.
AQAP-110 (Allied Quality Assurance Publication), publicată în februarie 1995 sub
numele „NATO Quality Assurance Requirements for Design, Development and Production”,
nu este altceva decât ISO 9001 cu unele adăugări. Are aceeaşi structură şi de multe ori
observaţia regăsită în această normă este ”se aplică cerinţele ISO”. Datorită faptului că această
normă nu include cerinţe software, asemenea cu ISO 9001, NATO publică norma AQAP-150
în martie 1993 şi o actualizează mai târziu în Septembrie 1997, sub numele” NATO Quality
Assurance Requirements for Software Development”. Diferenţa de bază a acestei norme faţă
de ISO 9000-3 priveşte formularea. In ISO 9000-3 regăsim formularea „ar trebui” pe când în
AQAP-150 formularea „trebuie”. AQAP-150 este un standard pe când ISO 9000-3 este un ghid
orientativ. AQAP-150 se deosebeşte de ISO 9000-3 prin faptul că este orientată mult pe
probleme specifice proiectului, în esenţă conţinând cerinţe de conţinut al SQAP („Software
Quality Assurance Plan”) şi al activităţilor controlate de acest plan. De asemenea, AQAP-150
nu conţine reguli de calitate, analize manageriale, analize contractuale, audituri interne şi
instruiri sau mentenanţă.

ISO/IEC 12207 conţine descrieri de procese, activităţi şi sarcini implicate în procesul

de achiziţie, de furnizare, de operare şi de întreţinere a sistemelor şi a aplicaţiilor software.
Unul dintre dezavantajele acestei norme este dificultatea introducerii într-o organizaţie care
deja are un alt sistem datorită complexităţii şi dificultăţii de înţelegere şi interpretare a acestei
norme, atunci când este folosită pentru prima dată. Cerinţele în ISO / IEC 12207 sunt destinate
a fi adaptate de către client înainte de a le impune unui furnizor. Acest lucru este important mai
ales pentru proiecte mici, caz în care standardul poate deveni uşor apăsător. O modalitate bună
de a folosi ISO / IEC 12207 este aceea de a fi folosit de către client. El include indicii pentru
cerinţele specifice din standard, pe care furnizorul trebuie să le îndeplinească. Acest standard
internaţional oferă de asemenea un proces care poate fi utilizat în definirea, controlul, şi
îmbunătăţirea ciclului de viaţă al proceselor software. Procesele, activităţile şi sarcinile acestui
standard internaţional, fie singur, fie în colaborare cu ISO / IEC 15288 (Systems and software
engineering —System life cycle Processes) ar putea fi, de asemenea, aplicate în timpul
achiziţionării unui sistem care conţine software (ISO/IEC 12207:2008).

6.3. Calitatea și managementul calității proiectelor software

Managementul calităţii aplicaţiilor software câştigă tot mai mult în importanţă în toate
domeniile economiei, datorită următorilor factori (Kneuper, R., Sollmann,F., 1995):
pe de o parte, calitatea aplicaţiilor software reprezintă un factor exponenţial în
domeniul concurenţei, determinat de conştientizarea tot mai mare pe ramură
calitativă a beneficiarilor;
pe de altă parte, corecţia de erori software s-a dovedit a fi foarte costisitoare;
aceste costuri pot fi însă evitate prin introducerea şi folosirea din timp a unui sistem
de management al calităţii.
În mod tradiţional managementul calităţii (atât pentru software, cât şi pentru produse
de orice natură) se bazează pe faptul că un produs finit trebuie verificat/testat sau examinat,
astfel încât să îndeplinească toate necesităţile/cerinţele, iar în cazul defectelor identificate să le
înlăture (ISO 9000). Această abordare s-a dovedit însă a fi insuficientă datorită costurilor
ridicate pentru testarea unui produs şi pentru procedeul de eliminare a neconformităţilor
apărute la produsul finit. Din aceste motive, se preconizează o calitate a aplicaţiilor software
în mod indirect, prin îmbunătăţirea calităţii proceselor de obţinere a aplicaţiilor software.
Ipoteza care stă la baza acestei abordări, este că printr-un proces cu un înalt nivel de calitate,
se pot obţine în mod predictibil produse foarte calitative.
Ca urmare a acestei abordări, se pot diferenţia două categorii de norme:
norme de proces şi norme de sistem ale managementului calităţii;
norme de produs.
6.4.Modelul CMMI
Modelul de Maturitate a Capacităţii pentru Software (engl. “The Capability Maturity
Model for Software”, CMM) a fost dezvoltat de Institutul de Ingineria Programării (engl.
“Software Engineering Institute”, SEI) de la Universitatea Carnegie-Mellon. A urmat
Capability Maturity Model Integration, CMMI, a cărui versiune 1.3 a fost lansată în 2010.
Modelul descrie principii şi bune practici asociate cu maturizarea proceselor de dezvoltare
software şi este destinat organizaţiilor care doresc să urmeze calea de la procese ad-hoc la
procese standardizate. Modelul este organizat pe 5 niveluri de maturitate. Un nivel este un
platou evolutiv bine definit către atingerea maturităţii şi îmbunătăţirea continuă a proceselor
de dezvoltare. Astfel putem identifica 4 diferenţe principale între ISO 9001 şi CMMI
ISO 9001 se adresează mai mult industriei prelucrătoare, pe când CMMI este specific
pentru industria software;
CMMI este mai detaliat şi mult mai specific;
ISO 9001 presupune acceptarea unui singur nivel de management al furnizorilor şi
proceselor, pe când CMM este un sistem de evaluare a performanţei şi capacităţii software-ului
furnizorului pe o scală de nivele de la 1 la 5;
ISO 9001 se concentrează pe relaţia client – furnizor, iar CMMI se concentrează
asupra procesului de realizare a aplicaţiilor software.
CMMI include următoarele niveluri:
1. Iniţial. Procesele software sunt improvizate, uneori chiar haotice. Puţine procese sunt
definite, iar succesul depinde de eforturile individuale;
2. Gestionat (engl. “managed”). Sunt stabilite procese manageriale de bază pentru a monitoriza
costurile, graficul de lucru şi funcţionalitatea. Există disciplina necesară pentru a repeta
succesele anterioare pentru proiecte similare;
3. Definit. Procesele software pentru activităţile de management şi cele tehnice sunt
documentate şi integrate într-un proces standard al organizaţiei. Toate proiectele folosesc o
versiune adaptată şi aprobată a standardului;
4. Gestionat cantitativ (engl. “quantitatively managed”). Sunt colectate măsurători detaliate
despre procesele software şi calitatea produselor. Atât procesele software, cât şi produsele sunt
înţelese şi controlate din punct de vedere cantitativ;
5. În optimizare (engl. “optimizing”). Este facilitată îmbunătăţirea continuă a proceselor prin
reacţii (“feedback”) cantitative din cadrul proceselor şi prin includerea unor idei şi tehnologii
inovatoare.

Fig. 2 Modelul CMMI

 În varianta CMM, nivelul 2 se numeşte Repetabil, iar nivelul 4 se numeşte Gestionat.
Cu excepţia nivelului 1, fiecare nivel de maturitate este descompus în câteva arii de procese
cheie care indică pe ce aspecte trebuie să concentreze organizaţia pentru a-şi îmbunătăţi
procesele software. Aspectele cheie identifică problemele care trebuie rezolvate pentru a atinge
un anumit nivel de maturitate. Acestea includ grupuri de activităţi înrudite care, realizate
colectiv, conduc la îndeplinirea scopurilor considerate importante pentru creşterea capacităţii
proceselor.
Procesele cheie pentru fiecare nivel sunt prezentate în cele ce urmează.
Prin definiţie, pentru nivelul 1 nu există procese cheie.
Procesele cheie pentru nivelul 2 se concentrează asupra stabilirii funcţiilor manageriale de
bază:
Aria de inginerie:
o Managementul cerinţelor;
Aria de management de proiect:
o Planificarea proiectelor;
o Monitorizarea şi controlul proiectelor;
o Managementul acordurilor cu furnizorii (Gestionarea achiziţiilor de produse de la
furnizori externi);
Aria de suport:
o Măsurători şi analize;
o Asigurarea calităţii proceselor şi produselor;
o Managementul configuraţiei.
Procesele cheie pentru nivelul 3 se referă atât la probleme legate de proiect, cât şi la
cele organizaţionale, întrucât organizaţia stabileşte infrastructura de lucru şi instituţionalizează
procesele de ingineria programării şi de management pentru toate proiectele. Scopul principal
este standardizarea proceselor.
Aria de inginerie:
o Dezvoltarea cerinţelor (Transformarea nevoilor clientului în cerinţe prin consolidarea
informaţiilor insuficiente, rezolvarea conflictelor etc.);
o Soluţia tehnică (Reprezintă efortul tehnic principal de proiectare şi implementare);
o Integrarea produsului (Asamblarea produsului din componentele sale);
o Verificarea;
o Validarea;
Aria de management de proiect:
o Definirea proceselor organizaţionale;
o Activităţile organizaţionale de instruire;
o Management de proiect integrat (Implicarea tuturor părţilor interesate relevante);
o Managementul riscului;
Aria de suport:
 o Analiza deciziilor şi rezoluţiile (engl. “Decision Analysis and Resolution” – Analiza
alternativelor cu ajutorul unui process de evaluare formal pe baza unor criterii bine definite).
Procesele cheie ale nivelului 4 se concentrează pe înţelegerea cantitativă a proceselor şi
produselor:
Aria de management de proiect:
o Performanţele proceselor organizaţionale (Stabilirea unor modele de evaluare
cantitativă a proceselor organizaţiei);
o Managementul de proiect cantitativ (Managementul în vederea îndeplinirii
obiectivelor cantitative stabilite de calitate şi performanţă).
Procesele cheie ale nivelului 5 acoperă problemele referitoare la îmbunătăţirea continuă şi
măsurabilă a proceselor legate de software:
Aria de management de proiect:
o Inovarea organizaţională şi desfăşurarea (engl.“Organizational Innovation and
Deployment”);
Aria de suport:
o Analiza cauzală şi rezoluţiile (engl. “Causal Analysis and Resolution” – Identificarea
cauzelor defectelor şi luarea de măsuri pentru prevenirea lor).
Organizaţiile nu pot fi „certificate” CMMI, în schimb are loc un proces de evaluare
(engl. “appraisal”), în urma căruia organizaţia este cotată la unul din nivelurile 1-5.
Există o strânsă corelaţie între modelele ISO 9001 şi CMMI, deși unele aspecte din ISO
9001 nu sunt acoperite de CMMI şi viceversa. Asemănarea cea mai mare rezultă din faptul că
ambele standarde îndeamnă „să spui ce faci şi să faci ce spui” (engl. “say what you do; do
what you say”). Premisa fundamentală este că toate procesele importante trebuie documentate
şi că toate livrabilele trebuie verificate prin activităţi de control al calităţii. ISO 9001 descrie
criteriile minime pentru un sistem de calitate acceptabil. De asemenea, CMMI se concentrează
exclusiv pe procesele de dezvoltare software, în timp ce ISO 9001 are un domeniu de aplicare
general. O analiză rapidă arată că o organizaţie certificată ISO 9001 satisface majoritatea
criteriilor CMMI de nivel 2 şi multe criterii de pe nivelul 3. Însă datorită diferenţelor de
abordare, nu se poate face o corelaţie exactă privind nivelurile de îndeplinire a criteriilor de
calitate între cele două standarde.
Cerințele crescânde ale clienților și beneficiarilor în software din punct de vedere al
calității, pot fi satisfăcute implementând un SMC conform ISO 9001. Sunt scoase în evidență
specificul SMC și particularitățile proceselor de management al calității pentru companiile care
realizează produse cu licență (cu drepturi de proprietate intelectuală IP- Intelectual Property)
și oferă servicii de dezvoltare software. Suplimentar, la implementarea SMC pentru astfel de
firme, trebuie să se țină cont de recomandările standardelor de calitate din seriile ISO 10000,
25000 și celor ce țin de ingineria software. O mare importanță are sintetizarea propriilor modele
de calitate, ce reflectă specificul sistemelor elaborate. Ținând cont de volumul operațiilor de
rutină, evaluarea și managementul calității software poate fi eficientă doar în condiții de
automatizare. Metoda propusă de abordare a calității constă în utilizarea directă a ieșirilor
proceselor de management și a operațiunilor tehnologice de dezvoltare software ca intrări în
aplicația de management al calității. Digitalizarea în managementul calității ar conduce la
rezultate promițătoare, contribuind la reducerea costurilor, a multor operații de rutină prin
importarea directă a datelor de intrare, excluderea neconcordanței datelor etc. Pentru
construirea unui cadru de măsurare, evaluare și îmbunătățire a calității este nevoie atât de
sprijin metodologic, cât și de un suport tehnologic cu instrumente potrivite. Deasemenea se
impune a dezvolta/realiza/utiliza instrumente ca aplicații software destinate pentru suportul
managementului calității.

6.5. Instrumente ale calității

Metodele, tehnicile şi instrumentele de managementul calităţii urmãresc rezolvarea

problemelor ce le ridică calitatea în toate fazele ciclului de viață al proiectelor.
Prezentarea instrumentelor de control al calităţii
Primele 7 instrumente nu sunt suficiente pentru a rezolva 90% din probleme, cum
spunea K. Ishikawa, drept pentru care acestea au fost completate de: brainstorming, votul
ponderat, consensul, analiza multicriterială, matricea soluţiilor, metoda întrebărilor.
Histogramele
Histograma este o reprezentare grafică a frecvenţei de apariţie, absolute sau relative,
a valorilor individuale măsurate ce descriu un fenomen sau o entitate analizată.
Histogramele se folosesc des în activitãţile de menţinere sub control a proiectelor.

Fig. 3 Utilizarea histogramelor (ASTA Power Project)

 Diagramele Pareto
Diagrama Pareto este un instrument utilizat în analizele pentru stabilirea priorităţilor în
rezolvarea diferitelor probleme care apar în cadrul proiectelor.

Fig.4. Diagramele Pareto

Diagrama de dispersie
Diagrama de dispersie reprezintă unul dintre cele mai simple mijloace de prezentare a
mãsurãtorilor. Utilitatea lor principală este de a arăta dacă există o corelaţie între două seturi
de date. Dacă există o legătură între aceste date, prin tehnici matematice se poate calcula
coeficientul de corelare a datelor. Într-o diagramă de dispersie, datele sunt prezentate într-un
sistem de coordonate reprezentate de cele două variabile. Efectul general poate fi comparat cu
imaginea unui ”nor”. Dacă relaţia între diferite perechi de date ale variabilelor este puternică,
”norul” va fi mai strâns cu o împrăştiere redusă şi poate fi aproximat cu o linie dreaptă şi vice-
versa. Dacă din reprezentarea datelor rezultă o linie dreaptă, rezultă că există o relaţie puternică
între variabilele respective.
 Fig.5 Diagrama de dispersie

Fişele de control
Fişele de control reprezintă formulare întocmite pentru înregistrarea datelor referitoare
la apariţia unor evenimente: non-conformităţi, defectări ale maşinilor şi echipamentelor,
activităţi care nu adaugă valoare etc. Acestea pot fi prezentate sub formă de tabel, diagramă şi
sunt utile în colectarea datelor. Datele cuprinse în fişele de control constituie o bază reală pentru
analizele şi acţiunile corective ulterioare.
Fişele de control statistic
Fişele de control statistic utilizeazã limite bazate pe abaterea stadard (respectiv
repartiţia în cadrul populaţiei statistice). Produsele se fabricã în conformitate cu toleranţele
precizate în specificaţiile tehnice. Un proces pentru care au fost îndepãrtate toate cauzele
semnificative poate produce produse neconforme dacã, procesul în sine nu este capabil.
Similar, un proces care prezintã cauze determinate poate realiza produse conforme.
Fişele de control pentru variabile reprezintã instrumente puternice care pot fi folosite
când sunt disponibile mãsurãtorile unui proces. Exemple pot fi: diametrul unui rulment, efortul
de închidere al unei uşi sau timpul necesar pentru a analiza o facturã. Fişele de control statistic
pentru variabile cele mai des folosite sunt: Fişele de control pentru media aritmeticã a
populaţiei şi pentru amplitudinea eşantionului. În Anexa 1 se prezintă un formular de Fişă de
control statistic pe ”flux de fabricaţie”

Media Limita superioarã de control

x Înregistrarea valorilor medii

Limita inferioarã de control

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Numãrul probei
Fig. 6 Fişe de control statistic
 Fişe de înregistrare a datelor
Fişa de frecvenţă reprezintă o tehnică comodă de colectare simplă şi rapidă a datelor
exacte asupra unei probleme.
După funcţiunile pe care le îndeplinesc, fişele de înregistrare sunt de două tipuri:
- fişa pentru înregistrare propriu-zisă;
- fişa de inspecţie
Ambele tipuri de fişe se pot întocmi, în funcţie de scopul urmărit, în mai multe variante.

Proces Activ LUNA

7 8 9
A 1 OO●□ OOO
2 ●

B 3 OO□ OO O
4 OOO●

Legendă: - defect de asamblare

- schimbări survenite în timp

- eroare de control

- altele

Fig.7 Fişa pentru înregistrarea frecvenţei cauzelor defectelor

Diagrame cauză-efect

Diagrama cauză-efect, “în os de peşte” sau Ishikawa a fost dezvoltată cu scopul de a

determina şi defalca principalele cauze ale unei probleme date. Se recomandă utilizarea
acesteia doar atunci când există o singură problemă, iar cauzele posibile pot fi ierarhizate.
Există trei tipuri de diagrame cauză-efect:
 Diagrama cauză-efect 5M
 Diagrama cauză-efect de proces;
 Diagrama cauză-efect pentru analiza dispersională.
 Fig. 8 Diagrama cauză-efect

Graficele
Graficele sunt instrumente utilizate pentru:
 Facilitarea înţelegerii şi analizei datelor colectate;
 Investigarea relaţiilor dintre diferiţi factori;
 Indicarea unor tendinţe;
 Atragerea atenţiei asupra anumitor probleme;
 Organizarea datelor în vederea memorării acestora
Din punct de vedere al formei de prezentare, graficele pot fi:
- ilustrative – prezintă datele sub formă grafică;
- matematice – prezintă datele sub formă grafică, cu posibiltatea de interpolare
sau extrapolare
Formele grafice de reprezentare sunt dintre cele mai diverse: grafice liniare, grafice cu
bare, grafice tip pie, grafice Gantt, grafice radar.

Prezentarea instrumentelor moderne ale managementului calităţii

După cum s-a putut observa, primele 7 instrumente permit să se trateze, plecând de la
date cuantificate, problemele existente în proiecte şi au ca obiectiv evitarea reapariţiei lor
viitoare. În anii ’60, o constatare a doctorului Yoji Akao, avea să ducă la o nouă abordare a
calităţii: o gestionare optimă a calităţii nu poate ascunde o proiectare deficitară a produsului
sau procesului. În 1972, datorită doctorilor Mizună şi Furukawa, se asistă la prima aplicare
industrială a instrumentelor care se vor integra mai târziu în Quality Function Deployment
(QFD). Aceste instrumente se vor numi cele 7 instrumente noi.
 Diagrama afinităţilor (Diagrama KJ)

Diagrama afinităţilor se constitue într-un instrument util de organizare şi structurare a

datelor, aspectelor, preocupărilor şi ideilor în vederea luării deciziilor şi identificării unor
soluţii. Diagrama se bazează pe afinităţi naturale dintre opinii şi date parţiale, referitoare la
anumite situaţii, în vederea înţelegerii şi structurării unei anumite probleme, implicând mai
mult un proces creativ decât logic.
Pentru aplicarea diagramei afinităţilor se parcurg următoarele etape:
 Descrierea şi formalizarea problemei;
 Exprimarea opiniilor privind problema pusă în discuţie, de către fiecare membru al
grupului şi înregistrarea în fişe;
 Aşezarea fişelor la întâmplare pe un panou;
 Gruparea fişelor pe familii (F1, F2,..) prin punerea de acord a participanţilor;
 Identificarea afinităţilor între familiile constituite;
 Stabilirea ordinii cronologice a familiilor;
 Construirea diagramei de afinităţi.

Fig. 9 Diagrama afinitatilor

Diagrama de relaţii
Diagrama de relaţii permite identificarea, înţelegerea şi clarificarea unor relaţii complexe tip
cauză-efect, în vederea identificării cauzelor şi soluţiilor la o problemă, precum şi a factorilor
cheie ce acţionează în situaţia analizată.
Etapele aplicării diagramelor de relaţii:
 Descrierea şi formalizarea problemei;
 Identificarea cauzelor care fac ca problema respectivă să existe, fiecare dintre acestea poate
fi efectul altei cauze, se stabilesc astfel legăturile cauză-efect principale;
 Evidenţierea legăturilor de acelaşi tip în cadrul fiecărui cuplu cauză-efect identificat,
continuându-se la următorul nivel de detaliere;
 Identificarea circuitelor cauză-efecte care determină cu cea mai mare probabilitate apariţia
problemei analizate.

Fig. 10. Diagrama de relatii

Diagrama matriceală
Diagrama matriceală permite vizualizarea şi analiza relaţiilor dintre evenimente şi a
criteriilor luate în considerare pentru caracterizarea lor. Prin utilizarea acestui instrument se
urmăreşte definirea priorităţilor în selectarea elementelor care vor fi analizate.
În funcţie de numărul elementelor luate în considerare se utilizează următoarele tipuri
de matrice:
- matrice în L, pentru analiza relaţiilor dintre două categorii de elemente;
- matrice în T, pentru analiza relaţiilor dintre o categorie de elemente şi alte două
categorii;
- matrice în Y, pentru analiza relaţiilor dintre trei categorii de lemente, luate două
câte două;
- matrice în X , pentru analiza relaţiilor dintre patru categorii de elemente, fiecare
categorie fiind asociată cu alte două categorii.

Etapele de aplicare a diagramei matriceale sunt:

 Definirea tipului de matrice care va fi utilizat, se stabilesc criteriile şi modul lor de
ponderare;
 Definirea în grup a elementelor selecţionate;
 Definirea relaţiilor dintre elementele de pe coloane şi linii cu ajutorul simbolurilor grafice;
 Determinarea punctajului pe linie ţinând cont de ponderile şi valorile stabilite;
 Formularea concluziilor în funcţie de rezultatele obţinute.
 Fig. 11. Diagrama matriceală

Diagrama arbore (sistematică)

Diagrama arbore permite evidenţierea relaţiilor dintre obiectivele de realizat şi acţiunile

(mijloacele) necesare pentru atingerea lor. Se poate aplica individual sau în grup.
Elaborarea unei diagrame arbore presupune parcurgerea următoarelor etape:
 Definirea problemei ce va fi analizată reprezentând nivelul 1 al arborelui;
 Identificarea principalelor metode pentru realizarea obiectivului, identificându-se nivelul
2 al arborelui;
 Fiecare metodă primară este tratată ca un obiectiv individual şi se repetă metodologia
utilizată în etapa anterioară, generând nivelul 3 al arborelui;
 Procesul se repetă până la epuizarea tuturor ideilor, numărul maxim al nivelelor este 4.
 Fig. 12 Diagrama arbore

Diagrama săgeată

Diagrama săgeată este utilizată pentru optimizarea planificării calităţii, asigurând

continuitatea, prin detectarea rapidă a riscurilor de întârziere.
Aplicarea acestei tehnici presupune parcurgerea următoarele etape:
 Definirea temei de către participanţi, a activităţilor necesare pentru a atinge un obiectiv;
 Clarificarea şi regruparea acţiunilor, stabilindu-se cele care vor fi întreprinse;
 Evidenţierea legăturilor dintre acţiunile de întreprins;
 Determinarea în funcţie de termenele stabilite, a momentelor în care trebuie începute
acţiunile, cel mai devreme şi cel mai târziu;
 Marcarea pe diagramă a drumului critic.

A B D
1 0 2 2 4 4
0 2 4
1 2 1 2 1 3

C
3 3
2
1 1

A - denumirea activităţii

D – durata activităţii
A
N T1 T1 – începe cel mai târziu

T2 T2 – începe cel mai devreme

1 D
N – numărul de ordine al acţiunii

- drum critic Fig. 13 Diagrama săgeată

 Brainstorming Identificarea Lista problemelor

problemelor
Fise de observatii,
inregistrãri si control Obtinerea informatiilor Informatii despre
Foi tabelare, despre probleme probleme
Grafice

Intelegerea problemelor

Votul simplu Selectarea problemelor Votul ponderat

Diagrama arbore Alegerea problemei

Diagrame de Diagrame Pareto

corelatii

Intelegerea Fise de observatii,

problemei inregistrãri si
Matricea ponderatã control,
Foi tabelare

Definirea problemei

Cãutarea cauzelor
potentiale

Documentarea asupra
cauzelor potentiale
Diagrame C/E
Grafice radar

Analiza cauzelor
Diagrame arbore
Diagrame de relatii

Diagrame Pareto Ierarhizarea cauzelor

1
 1

Formularea problemei si
a cauzelor ei reale

Lista solutiilor
Brainstorming Cãutarea solutiilor potentiale

Alegerea Diagrame
Diagramele solutiilor matriceale
deciziilor
Matricea

FMECA/AMEDC
Transmiterea
solutiilor

Diagrame Pareto

Urmãrirea
rezultatelor

Actiune

Sursã de fundamentare a unor decizii

Decizie

Fig.14 Abordarea sistemică a tehnicilor şi instrumentelor calităţii