VVT 2012

Vericarea si testarea sistemelor de calcul -note de cursIonescu Augustin-Iulian
Cuprins
Prefat a xi
Calitatea sistemelor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3 3 9 11 14 14 18 29 29 30 32 33 35 36 38 41 41 47 47 49 51 52
1 Introducere n ingineria sistemelor 1.1 Sisteme . . . . . . . . . . . . . . . . . . . . . 1.2 Sisteme de calcul . . . . . . . . . . . . . . . . 1.3 Sisteme informat ionale . . . . . . . . . . . . . 1.4 Cicluri de viat a . . . . . . . . . . . . . . . . . 1.4.1 Ciclul de viat a al produselor . . . . . 1.4.2 Ciclul de viat a a datelor . . . . . . . . 1.5 Modele ale ciclului de dezvoltare a unui produs . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Ce este un model? . . . . . . . . . . . 1.5.2 Modelul cascad a (waterfall model) . . 1.5.3 Modelul incremental . . . . . . . . . . 1.5.4 Modelul evolutiv (evolutionary model) 1.5.5 Modelul spiral a . . . . . . . . . . . . . 1.5.6 Modelul V . . . . . . . . . . . . . . . . 1.5.7 Modelul W . . . . . . . . . . . . . . . 2 Calitatea si managementul calit a tii 2.1 Abord ari ale denirii calit a tii . . . 2.2 Necesit a ti, cerint e, a stept ari . . . . 2.2.1 Necesit a ti . . . . . . . . . . 2.2.2 Cerint e . . . . . . . . . . . 2.2.3 A stept ari . . . . . . . . . . 2.3 Categorii de p art i interesate . . . . i
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
ii 2.4 Principiile managementului calit a tii
CUPRINS . . . . . . . . . . . . . . 54 71 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 71 75 75 78 78 79 80 80 81 84
3 Procese de baz a ale managementului calit a tii 3.1 Activit a tile prin care se asigur a calitatea produselor/serviciilor . . . . . . . . . 3.2 Planicarea calit a tii . . . . . . . . . . . . . . . 3.3 Controlul calit a tii . . . . . . . . . . . . . . . . . 3.3.1 Prezentare general a . . . . . . . . . . . 3.3.2 Moduri de realizare a controlului . . . . 3.3.3 Etape generale de realizare a controlului 3.3.4 Standarde . . . . . . . . . . . . . . . . . 3.4 Imbun at a tirea calit a tii . . . . . . . . . . . . . . 3.4.1 Prezentare general a . . . . . . . . . . . 3.4.2 Caracteristici ale m asur arii . . . . . . . 3.5 Asigurarea calit a tii . . . . . . . . . . . . . . . .
4 Modele ale calit a tii software 87 4.1 Metrici ale calit a tii software . . . . . . . . . . . . . . . . . . . 87 4.1.1 Not iuni de inginerie software . . . . . . . . . . . . . . 87 5 Vericare, validare, testare 5.1 Not iuni introductive . . . . . . . . . . . . . . . . . . . 5.2 Principii ale VVT . . . . . . . . . . . . . . . . . . . . . 5.3 Testarea ca disciplin a inginereasc a . . . . . . . . . . . 5.4 Termeni specici . . . . . . . . . . . . . . . . . . . . . 5.5 Clasicarea defectelor . . . . . . . . . . . . . . . . . . 5.6 Nivele de realizare a VVT . . . . . . . . . . . . . . . . 5.6.1 Prezentare general a . . . . . . . . . . . . . . . 5.6.2 Vericarea, validarea si testarea componentelor testing) . . . . . . . . . . . . . . . . . . . . . . 5.6.3 VVT la nivel de integrare (integration testing) 89 89 92 93 94 99 106 106
. . . . . . . . . . . . . . . . . . . . . . . . . . . . (unit . . . . 106 . . . . 109
6 Metode VVT funct ionale 6.1 Prezentare general a. . . . . . . . . . . . . . . . . . . . . . . 6.2 Metode VVT funct ionale de baz a . . . . . . . . . . . . . . . 6.2.1 Metoda partit ion arii n clase de echivalent a . . . . . 6.2.2 Metoda analizei valorilor limit a . . . . . . . . . . . . 6.2.3 Metoda grafurilor cauz a-efect . . . . . . . . . . . . . 6.2.4 Testarea tranzit iei st arilor unei ma sini de stare nite 6.2.5 Completitudinea test arii . . . . . . . . . . . . . . . .
. . . . . . .
115 115 116 116 123 125 133 142
CUPRINS 7 Metode VVT white-box 7.1 Prezentare general a. . . . . . . 7.2 Metoda fumului . . . . . . . . . 7.3 Acoperirea instruct iunilor . . . 7.4 Acoperirea ramurilor . . . . . . 7.5 Testarea condit iilor complexe . 7.6 Acoperirea c ailor independente 7.7 Testarea ciclurilor . . . . . . .
iii 143 . 143 . 145 . 145 . 146 . 146 . 148 . 152
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
8 Testarea bazelor de date 159 8.1 Calitatea informat iei si calitatea datelor . . . . . . . . . . . . 159 8.2 Ce trebuie vericat/testat la o baz a de date relat ionale . . . . 163 8.3 Corectitudinea modelului conceptual . . . . . . . . . . . . . . 164 9 Vericarea si testarea proiectelor VHDL
167
iv
CUPRINS
List a de guri
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 Reprezentarea simbolic a simplicat a a unui sistem. . . . . . . Reprezentarea simbolic a simplicat a a unui sistem deschis. . . Un sistem real cu evident ierea interfet elor cu mediul si operatorul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprezentarea simbolic a simplicat a a dou a sisteme deschise puternic conectate. . . . . . . . . . . . . . . . . . . . . . . . . Reprezentarea simbolic a simplicat a a dou a sisteme deschise slab conectate. . . . . . . . . . . . . . . . . . . . . . . . . . . Schema celor 5 unit a ti. . . . . . . . . . . . . . . . . . . . . . . Arhitectura Harvard a unui calculator. . . . . . . . . . . . . . Structura ierarhic a a unui sistem de calcul. . . . . . . . . . . Mediul de lucru al sistemelor informatice. . . . . . . . . . . . Ciclul de viat a al unui produs. . . . . . . . . . . . . . . . . . Ciclul de viat a a datelor. . . . . . . . . . . . . . . . . . . . . . Modelul cascad a al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003). . . . . . . . . . . Modelul incremental al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003). . . . . . . . . . . Modelul evolutiv al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003). . . . . . . . . . . Modelul spiral a al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003). . . . . . . . . . . Modelul V al dezvolt arii unui produs (conform CA267 - Software Testing - Testing and the Software Lifecycle - David Sinclair). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelul W al dezvolt arii unui produs (conform Software Development Models ). . . . . . . . . . . . . . . . . . . . . . . . Perspective din care poate denit a calitatea. . . . . . . . . v 4 6 7 7 8 10 11 12 13 14 19 31 32 34 36
37 39 43
1.17
2.1
vi 2.2 2.3 2.4 2.5 2.6
DE FIGURI LISTA Ierarhia necesit a tilor umane generale (piramida lui Maslow). . 48 Clasicarea cerint elor. . . . . . . . . . . . . . . . . . . . . . . 50 Clasicarea cerint elor non-funct ionale. . . . . . . . . . . . . . 51 O clasicare a purt atorilor de interese. . . . . . . . . . . . . . 52 Beneciari interni. Nu exist a negocieri ntre beneciarii interni, ecare ncearc a s a acapareze resursele pentru a se evident ia. Apar disfunct ionalit a ti la nivel global. . . . . . . . . . . . . . 54 2.7 Beneciari interni. Exist a negocieri ntre beneciarii interni dar ecare lucreaz a cum a nt eles el cerint ele beneciarului extern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.8 Beneciari interni. Activitatea beneciarilor interni este sincronizat a la nivel global prin comparare cu cerint ele beneciarului extern . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.9 Cele 8 principii ale managementului calit a tii denite de standardul ISO 9000. . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.10 Procesul denit de standardul ISO 9000:2000. . . . . . . . . . 62 2.11 Lant ul de valoricare a datelor. . . . . . . . . . . . . . . . . . 69 3.1 3.2 3.3 3.4 3.5 3.6 Modelul generic al controlului . . . . . . . . . . . . . . . . . . Modelul procesului de product ie f ar a planicare si f ar a control Modelul procesului de product ie f ar a planicare . . . . . . . . Modelul complex al controlului calit a tii . . . . . . . . . . . . Acuratet e si precizie . . . . . . . . . . . . . . . . . . . . . . . Evolut ia nivelului calit a tii datorat a unor cauze speciale sau normale si cre sterea calit a tii prin inovat ie si investit ii . . . . . 75 76 76 77 82 83
5.1 5.2
5.3 5.4
5.5
Etapele dezvolt arii unui program cu evident ierea proceselor de vericare si testare. . . . . . . . . . . . . . . . . . . . . . . 90 Structura simplicat a a unei platforme de testare. PC punctul de comand a de unde se introduc datele si comenzile. PO - punctul de observat ie unde se vizualizeaz a evolut ia entit a tii testate, se colecteaz a rezultatele si se fac comparat iile cu scopul formul arii concluziilor . . . . . . . . . . . . . . . . . 98 Clase de defecte, n funct ie de etapa din ciclul de viat a al produsului n care sunt generate. . . . . . . . . . . . . . . . . 100 Reprezentarea simbolic a a celor trei nivele de realizare a VVT studiate n aceast a lucrare. Se observ a cre sterea complexit a tii entit a tii supuse proceselor VVT. . . . . . . . . . . . . . . . . 107 Desf a surarea procesului de integrare incremental a pentru 4 componente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
DE FIGURI LISTA 5.6 5.7 5.8 5.9 Desf a surarea procesului de integrare top-down n ad ancime pentru 8 componente. . . . . . . . . . . . . . . . . . . . . . . Desf a surarea procesului de integrare top-down pe nivele pentru acelea si 8 componente ca n gura precedent a. . . . . . . Desf a surarea procesului de integrare bottom-up. . . . . . . . Desf a surarea procesului de integrare combinat a pentru 11 componente. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
111 112 113 113
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13
6.14 6.15 6.16
Analiza valorilor limit a pentru o clas a de echivalent a valid a de tip interval. . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Exemple de grafuri cauz a - efect. . . . . . . . . . . . . . . . . 127 Cauze si act iuni care pot determinate pentru Exemplul 3. . 128 Graful boolean cauz a - efect pentru Exemplul 3, bazat pe informat iile din Figura 6.3. . . . . . . . . . . . . . . . . . . . 129 Tabelul de decizie pentru Exemplul 3, bazat pe diagrama cauz a efect din Figura 6.4. . . . . . . . . . . . . . . . . . . 130 Regulile deduse pentru Exemplul 3. . . . . . . . . . . . . . . . 131 Cazurile de test deduse pentru Exemplul 3. . . . . . . . . . . 132 Schema bloc pentru circuitul GBPPS din Exemplul 5. . . . . 136 Diagrama de evolui e a st arilor pentru GBPPS din Exemplul 4.136 Cazuri de test propuse pentru GBPPS din Exemplul 4. . . . . 137 Diagrama de evolui e a st arilor pentru Exemplul 5. . . . . . . 138 Diagrama de evolut ie a st arilor mbun at a tit a pentru Exemplul 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 O secvent a de intrare necesar a test arii prin parcurgerea tuturor st arilor si a majorit a tii tranzit iilor, pentru Exemplul 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Secvent ele de intrare necesar a test arii ie sirii din program, pentru Exemplul 5. . . . . . . . . . . . . . . . . . . . . . . . . 139 Arborele de tranzit ie pentru FSM din Exemplul 5. . . . . . . 140 Parcurgerea diagramei de evolut ie a st arilor din Exemplul 5 pe baza secvent ei de test din BRBRRABRARACBRACRACESC. Se observ a c a sunt vericate toate tranzit iile ntre st arile. . . 141 Programul pseudocod pentru rezolvarea problemei din Exemplul 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Programul pseudocod corectat pentru rezolvarea problemei din Exemplul 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Schema logic a aferent a programului din Figura 7.2. . . . . . . 151 Schema logic a simplicat a aferent a programului din Figura 7.2.152
7.1 7.2 7.3 7.4
viii 7.5 7.6 7.7 7.8 7.9
DE FIGURI LISTA Programul pseudocod pentru rezolvarea problemei din Exemplul 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schema logic a simplicat a pentru programul aferent problemei din Exemplul 2. . . . . . . . . . . . . . . . . . . . . . . . Diagrama de control al uxului pentru rezolvarea problemei din Exem-plul 2. . . . . . . . . . . . . . . . . . . . . . . . . . Programul Java pentru rezolvarea problemei din Exemplul 3. Diagrama de control a programului din Figura 7.8. Complexitatea McCabe a acestui program va M=E-N+2=13-9+2=6
153 153 155 156 157
List a de tabele
6.1 Tabelul claselor de echivalent a pentru testarea programului aferent exemplului 1. vEC desemneaz a o clas a de echivalent a pentru valori valide iar iEC reprezint a o clas a de echivalent a pentru valori invalide. . . . . . . . . . . . . . . . . . . . . . . Tabelul cazurilor de test pentru testarea programului aferent exemplului 1, obt inute prin metoda partit ion arii n clase de echivalent a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabelul claselor de echivalent a pentru testarea programului aferent exemplului 2. vEC desemneaz a o clas a de echivalent a pentru valori valide iar iEC reprezint a o clas a de echivalent a pentru valori invalide. . . . . . . . . . . . . . . . . . . . . . . Tabelul cazurilor de test pentru testarea programului aferent exemplului 2, obt inute prin metoda partit ion arii n clase de echivalent a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabelul cazurilor de test pentru testarea programului aferent exemplului 1, obt inute prin metoda partit ion arii n clase de echivalent a si completate cu cazurile de test rezultate n urma analizei valorilor limit a. . . . . . . . . . . . . . . . . . . . . . Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei. . . . . . . . Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei din Exemplul 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabelul cazurilor de test black-box bazate pe analiza valorilor limit a pentru problema din Exemplul 1. . . . . . . . . . . . . Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei din Exemplul 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
120
6.2
120
6.3
122
6.4
122
6.5
125
7.1 7.2
148
150 151
7.3 7.4
154
x 7.5
DE TABELE LISTA Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei din Exemplul 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Modelul PSP/IQ [33]. . . . . . . . . . . . . . . . . . . . . . . 160 Leg atura modelului PSP/IQ cu metricile informat iei [33]. . . 161
8.1 8.2
Prefat a
Lucrarea are ca scop familiarizarea student ilor cu principalele not iuni privind vericarea, validarea si testarea calit a tii sistemelor de calcul. Prima parte descrie not iuni fundamentale ca sistem ingineresc, sistem de calcul, ingineria software, ingineria hardware, calitate, metrici ale calit a tii. Partea a doua se refer a la conceptele de vericare, validare si testare cu accent pe metodele si tehnicile de testare specice ingineriei sistemelor de calcul. Se ncearc a prezentarea metodelor si tehnicilor de testare ntr-o form a unitar a pentru sistemele inginere sti, particularit a tile pentru software si hardware ind puse n evident a mai ales prin exemple.
xi
xii
PREFAT A
Partea I
Calitatea sistemelor
Capitolul 1
Introducere n ingineria sistemelor

1.1 Sisteme
Prin entitate vom nt elege orice obiect, fenomen sau concept care poate deosebit de alte obiecte, fenomene, concepte asem an atoare prin valorile unor parametri numit i atribute. Entit a tile se caracterizeaz a prin structur a si funct ionalitate. Ele nu sunt izolate ci interact ioneaz a ntr-o mare varietate de forme printr-un schimb de materie, energie si informat ie. Un sistem reprezint a un ansamblu de entit a ti aate n interact iune. La ora actual a termenul sistem a devenit un cuv ant de baz a n orice limb a modern a si desemneaz a: orice entitate complex a ce cont ine mai multe p art i (subsisteme) ntre care pot stabilite anumite relat ii (vezi Figura 1.1). Sistemele au o proprieate esent ial a care le deosebe ste de o reuniune de elemente, numit a proprietatea integratoare a sistemelor : orice sistem are propriet a ti ce nu pot atribuite niciuneia dintre componentele sale, ele rezult and numai n urma interact iunii componentelor. Exemplu: calculatorul este funct ional numai prin interact iunea sis3
CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR
Figura 1.1: Reprezentarea simbolic a simplicat a a unui sistem.
temului zic format din mult imea unor echipamente specializate (hardware) si sistemul software corespunz ator. Componentele unui sistem, care pot eliminate din acesta f ar a a-i afecta funct ionalitatea, sunt numite componente redundante ale sistemului. Exist a ideea c a orice component a redundant a trebuie eliminat a deoarece nu numai c a ridic a pret ul de cost, ci poate provoca si probleme n funct ionare. In realitate componentele redundante sunt utilizate frecvent pentru depistarea si eventual eliminarea unor erori de comunicare a datelor sau pentru cre sterea tolerant ei la defecte a sistemelor prin duplicarea unor blocuri funct ionale sau c ai de comunicare. Din punctul de vedere al inginerului: sistemul este o colect ie de componente - dispozitive, software si oameni - care coopereaz a ntr-un mod organizat pentru a obt ine rezultatul care satisface cerint ele diverselor categorii de persoane interesate (purt atori de interese)[2]. Exist a dou a categorii de sisteme inginere sti: sisteme articiale - create de om n scopul satisfacerii unor necesit a ti materiale sau spirituale; sisteme hibride care cont in at at elemente naturale c at si elemente
1.1. SISTEME articiale, care interact ioneaz a ntr-un scop bine determinat. Exemple: Sistemele de calcul actuale sunt sisteme articiale. Sistemele hidrotehnice sunt sisteme hibride. Sistemele inginere sti au c ateva propriet a ti remarcabile [1]:
Predictabilitate. Asigur a c a un produs va realiza funct iile pentru care a fost creat. Este important si n ce m asur a sistemul nu realizeaz a pe l ang a funct iile dorite si alte funct ii, inutile, nedorite sau chiar periculoase. Astfel, un telefon mobil poate folosit pentru convorbiri (funct ie de baz a), dar si pentru fotograi, nregistr ari video/audio, conectare la Internet (funct ii auxiliare) sau pentru interceptarea unor convorbiri ori comanda unor bombe (funct ii nedorite). De fapt, aproape orice sistem poate utilizat si n scopuri criminale. Este important ca proiectantul s a reduc a pe c at posibil efectul funct iilor nedorite. Fiabilitate. Implic a p astrarea funct iilor impuse sistemului, n condit ii precizate, cel put in ntr-un anumit interval de timp prestabilit. Transparent a. Poate avea dou a interpret ari, din punctul de vedere al proiectantului/produc atorului respectiv din punctul de vedere al utilizatorului: structura sistemului si procesele pe care acesta le suport a pot descrise clar si precis; sistemul poate utilizat f ar a cuno stint e privind structura, tehnologia de realizare, principiile de funct ionare (nu este nevoie s a stii cum funct ioneaz a televiziunea n culori pentru a putea utiliza un televizor). Controlabilitate. Presupune c a starea sistemului poate modicat a prin comenzi externe. Cu alte cuvinte sistemul poate condus pe baza unor instruct iuni clare, n condit ii bine precizate. Sunt luate n considerare at at condit iile normale de funct ionare c at si condit ii speciale care pot produce c aderi ale sistemului c at si pagube sau victime. In realitate nu pot luate n considerare toate situat iile posibile, deci exist a diverse nivele de controlabilitate ale unui sistem articial.
In funct ie de schimburile care au loc ntre sistem si mediu, pot distinse: sisteme nchise - care nu realizeaz a nici un fel de schimburi cu mediul nconjur ator; cu alte cuvinte, schimb arile din mediul nconjur ator nu afecteaz a starea sistemului. sisteme deschise - care realizeaz a permanent schimburi de materie, energie, informat ie cu mediul nconjur ator si din aceast a cauz a modic arile ap arute n mediu pot afecta starea sistemului (Figura 1.2). Sistemele nchise sunt de fapt idealiz ari care permit modelarea mai u soar aa evolut iei unor sisteme reale. In realitate toate sistemele sunt mai mult sau mai put in deschise. Sistemele articiale sunt, prin natura lor, sisteme deschise deoarece ele trebuie s a primeasc a din exterior comenzi, energie, materiale, informat ii, si ofer a la ie sire rezultatul prelucr arilor efectuate.
Figura 1.2: Reprezentarea simbolic a simplicat a a unui sistem deschis.
Sistemele comunic a cu mediul sau cu alte sisteme prin interfet e. Interfat a poate avea un rol funct ional sau de protect ie fat a de agresiunea mediului asupra sistemului sau a sistemului asupra mediului. Interfet ele permit adaptarea semnalelor care trec prin ele ca m arime, durat a si natur a. De exemplu, un semnal electric poate transformat ntr-un semnal optic cu o lungime de und a, durat a si intensitate prestabilite. Chiar si un sistem relativ simplu poate s a aib a diverse interfet e prin care comunic a cu mediul sau alte sisteme. Astfel un mouse ca cel din Figura 1.3 are interfet e proprii prin care omul introduce comenzi, interfat a pentru comunicarea cu calculatorul, interfat a pentru contactul cu suportul si interfat a
1.1. SISTEME de protect ie (carcasa).
Figura 1.3: Un sistem real cu evident ierea interfet elor cu mediul si operatorul.
Se spune c a dou a sisteme sunt puternic conectate dac a au cel put in un subsistem n comun (Figura 1.4). Exemplu: Unitatea central a si sistemul de programe au n comun memoria principal a care este suportul zic pentru orice program executabil.
Figura 1.4: Reprezentarea simbolic a simplicat a a dou a sisteme deschise puternic conectate.
Se spune c a dou a sisteme sunt slab conectate dac a interact ioneaz a dar nu au p art i comune (Figura 1.5).
Figura 1.5: Reprezentarea simbolic a simplicat a a dou a sisteme deschise slab conectate.
Exemplu: Calculatoarele conectate printr-o ret ea local a sunt slab interconectate.
Observat ie! Pe baza celor discutate rezult a imediat c a un sistem se caracterizeaz a prin: cont inut (natura componentelor); structur a (num arul componentelor, pozit ia relativ a, modul n care interact ioneaz a, ordinea componentelor); funct ionalitate (ce rezult a n urma interact iunilor). Denirea unui sistem presupune precizarea tuturor acestor caracteristici ceea ce nu este ntotdeauna simplu. Denirea unui sistem este o problem a subiectiv a si depinde n bun a m asur a de interesul pe care-l are cel care dene ste sistemul, de nivelul s au de cunoa stere si de experient a sa ntr-un anumit domeniu. Dicultatea de a deni un sistem apare datorit a faptului c a n realitate sistemele nu exist a independent unul de altul, ci ecare sistem exist a ntr-un mediu n care interact ioneaz a cu alte sisteme, put and o component a (subsistem) a unui sistem mai mare. Mai mult, a sa cum s-a v azut, unele sisteme pot s a aib a componente comune. Denirea sistemului se poate realiza prin dou a metode diferite: Metoda top-down - se porne ste de la un sistem mare si se denesc subsistemele acestuia si interact iunile dintre acestea.
1.2. SISTEME DE CALCUL
Metoda buttom-up - se porne ste de la un set de componente si un obiectiv pe baza c aruia se dene ste noul sistem. In cadrul acestei lucr ari ne vom referi la o singur a categorie de sisteme articiale puternic deschise si anume sistemele de calcul. Multe din concluziile formulate pot ns a u sor adaptate si pentru alte categorii de sisteme articiale. Sistemele de calcul sunt, ntr-o proport ie cov ar sitoare, rezultatul unei activit a ti industriale de serie mare. Spre deosebire de product ia artizanal a, product ia industrial a are un caracter sistematic, repetitiv, m asurabil si controlabil, ceea ce impune coordonarea acestui proces de c atre ingineri. Pentru a scoate n evident a faptul c a aceste sisteme sunt rezultatul unei activit a ti inginere sti si au o valoare de piat a, ind destinate satisfacerii cerint elor formulate de diversele categorii de oameni, n continuare le vom numi produs.
1.2
Sisteme de calcul
Sistemele de calcul reprezint a cel mai important sistem digital. Av and n vedere num arul foarte mare de entit a ti numite la ora actual a calculator si propriet a tile foarte diferite ale acestora, este practic imposibil s a se formuleze o denit ie unic a a acestei not iuni. O denit ie cu o acceptare sucient de sugestiv a este urm atoarea: Se nume ste calculator (sistem de calcul) orice sistem capabil s a realizeze urm atoarele obiective: s a accepte intr ari care reprezint a o form a codicat a de informat ie (date de intrare sau operanzi); s a prelucreze datele conform unui algoritm; s a furnizeze la ie sire informat ie (date de ie sire sau rezultate) ntr-o form a accesibil a omului sau altui calculator. Cu alte cuvinte se poate spune c a: Un calculator este un sistem care permite prelucrarea datelor n scopul obt inerii de informat ii.
10
Observa tie! Av and n vedere c a la ora actual a n toate domeniile de activitate se utilizeaz a numai calculatoare numerice, prin cuv antul calculator vom nt elege de fapt calculator numeric. In Figura 1.6 este prezentat un model foarte general al calculatoarelor privite ca sistem, cunoscut ca schema celor 5 unit a ti sau arhitectura von Neumann. Fiecare dintre cele 5 unit a ti (subsisteme) este la r andul ei un sistem foarte complex, cu o mult ime de componente. Acest model se refer a doar la echipamentele zice.
Figura 1.6: Schema celor 5 unit a ti.
In Figura 1.7 este prezentat a o variant a a schemei celor 5 unit a ti numit a arhitectura Harvard. Intre cele dou a modele exist a o diferent a fundamental a si anume existent a unui singur bloc de memorie pentru date si instruct iuni la architectura von Neumann respectiv o memorie de date si o memorie de instruct iuni, cu caracteristici n general diferite, pentru arhitectura Harvard. Aceast a diferent a, aparent minor a la nivel de schem a bloc, are consecint e majore asupra organiz arii, structurii si funct ion arii calculatoarelor. Un alt mod de a reprezenta un sistem de calcul este cel din Figura 1.8, al c arui obiectiv este de a pune n evident a interact iunea ntre software si
1.3. SISTEME INFORMAT IONALE
11
Figura 1.7: Arhitectura Harvard a unui calculator.
hardware la un nivel foarte ridicat de abstractizare, f ar a a lua n considerare nivelul ret ea. Se observ a c a nucleul este format din echipamentele corespunz atoare celor 5 unit a ti funct ionale puse n evident a anterior. Acest nucleu permite executarea unui set de instruct iuni cod ma sin a. Urm atorul nivel este format din programele care gestioneaz a ntreaga activitate a calculatorului. Acestea formeaz a sistemul de operare. Pe acet nivel se sprijin a un alt set de programe foarte importante numite programe utilitare, cum ar editoare, compilatoare/interpretoare, medii de dezvoltare, motoare de c autare, SGBD etc. Sistemul de operare si utilitarele mai sunt cunoscute sub numele de software de baz a. Bazele de date si de cuno stint e sunt elemente esent iale n multe dintre programele aplicative (aplicat iile) care formeaz a ultimul nivel.
1.3
Sisteme informat ionale
Sistemul informat ional (SI) reprezint a totalitatea mijloacelor umane, nanciare si tehnice care contribuie la realizarea ciclului de viat a al datelor necesare desf a sur arii activit a tii unei organizat ii.
12
Figura 1.8: Structura ierarhic a a unui sistem de calcul.
Sistemul informatic reprezint a totalitatea resurselor necesare prelucr arii automate a datelor unei organizat ii cu ajutorul tehnicii de calcul. In Figura 1.9 este prezentat modelul unui sistem informat ional mpreun a cu mediul de lucru specic. Nucleul sistemului este format dintr-un set de aplicat ii de diverse tipuri, care prelucreaz a datele specice organizat iei oferind acesteia diverse informat ii ntr-un format corespunz ator. Realizarea obiectivelor SI se bazeaz a direct pe un set de programe, baze de date, programatori, administratori, echipa-
1.3. SISTEME INFORMAT IONALE
13
Figura 1.9: Mediul de lucru al sistemelor informatice.
mente, conexiuni de comunicat ie cu alte SI. Funct ionarea sistemului impune existent a unei infrastructuri format a din resursele materiale/nanciare/umane, norme interne, reguli de securitate, obiective, informat ii etc. Sistemul are o structur a organizatoric a riguros denit a. Mediul de lucru al SI, extern acestuia, este format din beneciari, furnizori, concurent a, b anci, organizat ii guvernamentale si neguvernamentale etc.
14
1.4
1.4.1
Cicluri de viat a
Ciclul de viat a al produselor
Ca orice entitate din univers, un produs are o existent a nit a, datorit a uzurii zice sau morale. In cazul produselor, indiferent de natura acestora, putem pune n evident a mai multe etape de viat a care mpreun a formeaz a ciclul de viat a al produsului. O variant a posibil a a ciclului de viat a a unui produs este reprezentat a cu ajutorul diagramei din Figura 1.10.
Figura 1.10: Ciclul de viat a al unui produs.
Etapa de proiectare este esent ial a deoarece n aceast a etap a sunt captate din realitate toate informat iile necesare n elegerii funct ionalit a tii produsului care urmeaz a s a e proiectat si permit crearea primului model al produsului. In continuare proiectarea poate privit a ca o succesiune de transform ari de
1.4. CICLURI DE VIAT A
15
modele astfel nc at s a nu apar a pierderi de informat ie, adic a s a nu dispar a anumite informat ii esent iale dar nici s a nu e introduse informat ii noi care nu corespund cerint elor beneciarilor proiectului sau sunt gre site. n nal proiectul trebuie s a permit a implementarea si utilizarea produsului la nivelul cerint elor beneciarului. Produsele actuale au o complexitate sucient de mare ca s a nu permit ao abordare global a a proiect arii. Pe baza cerint elor formulate de diverse categorii de utilizatori n faza de denire a produsului, acesta este divizat n diverse subansamble funct ionale care exist a deja sau a c aror proiectare este mult mai simpl a sau necesit a abord ari specice. De exemplu carcasa unui aparat electronic necesit a implicarea unor speciali sti n domeniul rezistent ei materialelor, maselor plastice, design artistic adic a rezolvarea unor probleme pe care electronistul de obicei nu le st ap ane ste. Aceast a divizare implic a denirea interfet elor ntre diversele subansamble. Interfet ele pot conduce la cre sterea pret ului de cost al implement arii si la sc aderea abilit a tii produselor. Pentru ecare subansamblu se vor pune n evident a mijloace si metode specice de vericare, validare si testare. Proiectarea este un proces sistematic, iterativ de mare complexitate (vezi sectiunea 1.6). Orice gre seal a la acest nivel poate inuent a negativ toate celelalte etape. Implementarea unui produs presupune crearea produsului conform proiectului realizat n prima etap a. Problemele care pot s a apar a pe durata implement arii produsului pot uneori s a necesite modicarea proiectului. In anumite situat ii, nainte de a trece la product ia propriuzis a se realizeaz a un produs pilot (prototip) care permite vericarea funct ional a a proiectului si ajustarea anumitor caracteristici. Produsul pilot poate identic cu produsul proiectat sau o variant a simplicat a, ieftin a, u sor de testat si modicat. In cazul n care produsul cont ine diverse subansamble, este necesar a punerea la punct a unei strategii de integrare a acestora p n a la nivelul produsului nal. Pentru ecare etap a de integrare este necesar s a e realizate teste speciale (teste de integrare) puse n evident a nc a din etapa de proiectare. Pentru produsele software, testarea corectitudinii funct ionale si satisfacerea performant elor impuse este mult mai u sor de realizat deoarece un program poate multiplicat cu cheltuieli foarte mici n oric ate exemplare sunt necesare, iar corectarea anomaliilor depistate nu necesit a de obicei un efort sau cheltuieli prea mari. Deoarece crearea, testarea si modicarea unui produs hardware implic a n general cheltuieli mari, la ora actual a se utilizeaz a pe scar a larg a mijloace de proiectare asistat a de calculator care permit modelarea si simularea funct ional a a produsului. Suplimentar, rmele pro-
16
duc atoare de circuite VLSI pun la dispozit ie kituri de testare cu ajutorul c arora pot testate produsele proiectate n condit ii identice cu cele impuse de funct ionarea real a si la un pret de cost foarte mic. In nal este necesar a integrarea produsului n mediul n care va utilizat, ceea ce impune noi teste (teste de acceptant a). Product ia permite multiplicarea rezultatului etapelor precedente n scopul v anz arii si utiliz arii. Produsele obt inute sunt testate pentru a preveni c aderea lor la instalare sau pe durata utiliz arii lor normale. In funct ie de num arul produselor rezultate putem pune n evident a: produse unicat pentru scopuri speciale, cum ar dispozitive de testare, apar atur a pentru cercetare, calculatoare pentru domenii strategice etc. Pret ul este foarte mare deoarece toate cheltuielile de proiectare/ implementare/product ie se acoper a din v anzarea acestui produs. Implic a o vericare/validare/testare foarte atent a la ecare faz a. produse serie mic a - product ie pentru scopuri legate de un domeniu cu un num ar mic de utilizatori cum este cazul unor produse de lux, tehnici militare, tehnologii avansate etc. Testarea se poate face la nivel de produs sau la nivel de lot. produse serie mare (product ie de mas a) implic a mii sau chiar milioane de exemplare (componente electronice, microcalculatoare, software de baz a, echipamente periferice uzuale etc. Pret ul de cost este mic deoarece cheltuielile de proiectare/ implementare se distribuie pe ecare produs. Testarea se face de obicei la nivel de e santioane din ecare lot de product ie. Utilizarea presupune un produs funct ional n limitele cerint elor furnizate de diverse categorii de beneciari. Produsele din domeniul tehnicii de calcul sunt produse care trebuie s a funct ioneze un timp ndelungat f ar a defecte (except ie fac a sanumitele consumabile necesare funct ion arii imprimantelor, copiatoarelor etc.). Unele sisteme de calcul trebuie s a funct ioneze n regim 7x24, adic a nu se accept a nici un fel de ntrerupere a funct ion arii. Totu si apar numeroase situat ii care implic a intervent ia speciali stilor pentru a elimina anumite erori sau pentru a modica structura sau valorile anumitor parametri ai produsului. Principalele cauze care conduc la necesitatea unor intervent ii asupra produsului pe durata funct ion arii sunt: aparit ia unor c aderi ca urmare a unor gre seli de proiectare nedepistate n ainte de darea n folosint a, deterior arii unor componente datorit a
17
uzurii naturale, n urma unor incidente, datorit a unor manevre gre site ale operatorilor, catastrofe naturale etc.; necunoa sterea de c atre utilizator a modului de utilizare; modicarea standardelor, a normelor de protect ie a mediului sau de securitate, legislat iei ( n special n cazul softwareului); degradarea n timp a unor performant e; aparit ia unor solicit ari de modicare sau dezvoltare din partea utilizatorului. Mentenant a este un proces care permite eliminarea tuturor anomaliilor ce se semnaleaz a n timpul exploat arii bazei de date si adaptarea acesteia noilor cerint e. Mentenant a se desf a soar a pe toat a durata utiliz arii si poate lua diferite forme: mentenant a corectiv a care permite eliminarea anomaliilor depistate pe parcursul utiliz arii, datorite unor erori de proiectare sau defect arii unor componente ale produsului; mentenant a adaptiv a care permite adaptarea produsului la noile cerint e impuse de modicarea legislat iei, introducerea sau modicarea unor noi norme privind protect ia si securitatea etc; mentenant a perfectiv a pentru dezvoltarea produsului prin mbun at a tirea unor caracteristici sau introducerea unor noi funct ii; Orice modicare a produsului n procesul de utilizare poate implica necesitatea modic arii proiectului si a proceselor de implementare. Atunci c and se consider a c a pret ul mentenant ei a dep a sit o limit a acceptabil a, se trece la nlocuirea produsului cu unul similar din punct de vedere funct ional dar care nu prezint a anomaliile produsului original sau se trece la reproiectare n scopul realiz arii unei noi versiuni superioare. Tocmai aceast lucru implic a un caracter ciclic etapelor de viat a ale unui produs. Dezafectarea este de fapt ultima etap a n viat a oric arui produs si permite eliminarea acestuia din sistemul n care a fost ncorporat. Mult i consider a c a tehnologiile specice calculatoarelor sunt curate, c a dezafectarea softwareului nu ridic a nici un fel de probleme. In realitate, calculatoarele cont in
18
numeroase componente cu numeroase elemente scumpe a c aror recuperare este foarte important a. De asemenea calculatoarele cont in si componente toxice, n special bateriile. Pentru recuperarea substant elor pret ioase sau toxice sunt necesare tehnologii speciale, sosticate si scumpe. La ora actual a au fost create rme specializate n colectarea calculatoarelor dezafectate si recuperarea unor blocuri sau componente pentru refolosire sau distrugere nepoluant a. Dezafectarea softwareului nu este ntotdeauna simpl a si implic a luarea de m asuri speciale nc a din faza de proiectare, ind uneori necesare programe speciale pentru dezinstalare. Aceste programe au rolul de a elimina toate efectele programului dezafectat si recupereaz a toate resursele folosite, n special memoria, f ar a a afecta alte programe.
1.4.2
Ciclul de viat a a datelor
Etapele operat ionale prin care trec datele din momentul gener arii lor si p an a la obt inerea rezultatelor nale, independente de domeniul de activitate sau natura datelor, formeaz a ciclul de prelucrare a datelor sau ciclul de viat a a datelor. O variant a a ciclului datelor este prezentat a n Figura 1.11. Etapele puse n evident a sunt profund legate ntre ele si calitatea rezolv arii unei etape inuent eaz a direct calitatea rezolv arii celorlalte etape. De fapt punerea n evident a a acestor etape are mai mult un caracter metodologic. In practic a este relatv dicil s a se separe unele etape de altele. De exemplu vericarea si validarea datelor este n multe situat ii legat a de culegerea datelor si introducerea lor pe calculator iar p astrarea datelor este specic a tuturor etapelor ciclului de prelucrare, av nd forme specice pentru ecare etap a. In continuare vor analizate aceste etape pun andu-se n evident a obiectivele si caracteristicile ec arei etape precum si modul cum inuent eaz a celelalte etape ale ciclului de prelucrare. Denirea si proiectarea structurii datelor este o etap a preg atitoare pentru ciclul de viat a propriuzis al datelor. Indiferent dac a datele sunt prelucrate manual sau cu calculatorul, ele au o anumit a structur a. Denirea structurii datelor presupune captarea unor cerint e pe baza c arora proiectantul va stabili ce date trbuie culese, ce caracteristici au datele, cum vor acestea culese, codicate si codicate, ce prelucr ari vor suferi, cine poate avea acces la date si la rezultatele obt inute n urma prelucr arii lor etc. Pe baza acestor informat ii se creaz a modelul conceptual al datelor precum
19
Figura 1.11: Ciclul de viat a a datelor.
si diverse modele logice (externe) aferente diferitelor aplicat ii. Aceste modele nu sunt implementabile av and un grad nalt de abstractizare (modelul ER, ORM, UML etc.). Pe baza acestor modele se proiecteaz a documentele primare dac a nu exist a, si se genereaz a modelele implementabile (relat ional, obiectual, obiect-relat ional, XML etc.). In paralel se proiecteaz a si aplicat iile asupra datelor (cel put in aplicat iile cele mai importante).
20
Implementarea structurii Structura datelor poate implementat a sub forma unei colect ii de siere (at les) gestionate la nivelul sistemului de operare si a aplicat iilor sau sub forma unei baze de date gestionate de SGBD. Nu trebuie confundat a implementarea structurii datelor cu implementarea colect iei de date, deoarece structura creat a nu cont ine nicio dat a. Datele sunt introduse n siere/BD de obicei pe durata utiliz arii. Implementarea aplicat iilor este o etap a laborioas a, cu multe faze si implic a un num ar mare de persoane si mijloace de vericare/validare/testare specice. In aceast a etap a sunt achizit ionate dispozitivele necesare product iei, materiile prime, softwareul de baz a, aplicat ii deja existente si poate s a nceap a preg atirea beneciarilor pentru utilizarea aplicat iilor.
Culegerea datelor Datele primare sunt culese direct de la sursele primare care le genereaz a. Culegerea poate realizat a manual sau automat. Culegerea manual a presupune nregistrarea datelor pe diverse suporturi zice numite documente primare . Calitatea documentelor primare inuent eaz a direct si puternic randamentul prelucr arii si utiliz arii informat iei cont inute. Pe de o parte cont inutul lor trebuie s a reecte n mod c at mai natural realitatea pe care o reprezint a iar pe de alt a parte trebuie s a poat a c at mai repede preluate si prelucrate de c atre sistemul de calcul. In cadrul informat iilor cu un grad nalt de organizare, documentele primare sunt n general formulare tipizate ( se, tabele, chitant e, diagrame etc. ). In cazul informat iei slab structurate, problemele de culegere a datelor sunt mult mai dicile av nd n vedere diversitatea suportului zic si modul de realizare (documente olografe, c art i, reviste, fotograi, h art i, lme, nregistr ari audio sau video, etc.), dicult a tile de compatibilizare, volumul foarte mare de informat ie, dicult a tile de codicare etc. Culegerea automat a presupune existent a unor traductoare care pe baza stimulilor externi genereaz a date astfel codicate nc at s a poat a recept ionate si prelucrate direct de c atre sistemele numerice. Culegerea automat a a datelor este specic a activit a tilor de conducere cu calculatorul a unor procese tehnologice. n acest caz, pentru a permite culegerea datelor n timp real, se utilizeaz a sisteme speciale de achizit ie a datelor. Dezvoltarea ret elelor de calculatoare permite achizit ia automat a de date de c atre un anumit sistem de calcul de la alte sisteme aate n nodurile ret elei. O situat ie cu totul aparte a ap arut n ultimul timp datorit a cre sterii num arului documentelor primare redactate cu calculatorul deoarece n foarte multe situat ii datele cont inute de aceste documente nu pot transferate direct ntre sistemele de calcul si necesit a reintroducerea lor manual a. De asemenea exist a numeroase probleme la transferul au-
21
tomat de date ntre diverse sisteme de calcul, mai ales c nd datele au fost generate cu alte pachete de programe dec at cele folosite la preluarea lor. Pentru rezolvarea acestor probleme au fost puse la punct programe speciale de compatibilizare a formatelor de date , care permit transferul de date ntre programe ce utilizeaz a protocoale diferite de reprezentare a datelor. Transcrierea datelor ntr-o form a accesibil a sistemului informatic (SI) se poate realiza direct sau pe suport intermediar. In cazul nregistr arii directe, datele culese sunt introduse direct n memoria calculatorului cu ajutorul unor traductoare, de la tastatura unei console sau prin sistemul de comunicat ie a datelor de la un sistem de calcul la altul. Este necesar s a se asigure codicarea si formatul corespunz atoare pachetului de programe ce va realiza prelucrarea propriuzis a. Introducerea datelor prin tastatura consolei impune dezvoltarea unor mecanisme puternice de protect ie si validare a datelor si crearea unor posibilit a ti de corectare imediat a a erorilor de operare. La ora actual a operatorii au la dispozit ie pe display machete speciale pentru introducerea datelor. Editarea machetelor de introducere a datelor de la consol a este relativ mare consumatoare de timp si din aceast a cauz a au fost create mijloace software foarte puternice pentru generarea lor chiar si de c atre cei f ar a cuno stint e avansate n domeniul program arii. O machet a de calitate trebuie s a tin a cont nu numai de cont inutul informat ional ci si de aspectul artistic si de aspecte de ergonomie n sensul asigur arii unei solicit ari minime din punct de vedere zic si psihic a operatorului uman. Operatorul trebuie s a e permanent ghidat prin semnale video si audio si prin mesaje asupra tuturor operat iilor pe care trebuie s a le efectueze si a rezultatelor act iunilor sale.
Aspecte ale codic arii datelor Informat ia nu poate conceput a n afara unui proces de schimb ntre doi parteneri- unul care o genereaz a (sursa) si altul care o recept ioneaz a (receptor). Schimbul de informat ii ridic a probleme specice ce decurg din forma de exprimare adic a din expresia zic a si formal a a cont inutului. Receptorul nu poate ret ine si interpreta informat ia primit a dec at atunci c and are acces la suportul zic si cunoa ste codul folosit de emit ator. Exemplu: De si tr aim ntr-o mare de unde electromagnetice, informat ia pe care acestea o transport a nu poate obt inut a dec at de cei de dispun de un receptor radio sau TV si pot decodica semnalele recept ionate. Suplimentar, n cazul mesajelor verbale este necesar a cunoa sterea limbii n care a fost fomulat mesajul.
22
Informat ia si codicarea sunt entit a ti inseparabile. Informat ia nu poate exista f ar a un suport formal de exprimare, tot a sa cum o codicare ce nu serve ste nregistr arii si transmiterii informat iei este un lucru lipsit de sens. Parcurgerea ciclului de prelucrare automat a a datelor implic a existent a unor tipuri diferite de codicare a datelor. 1. Codicarea extern a a informat iei. Apare at at n procesul de culegere a datelor atunci c and ec arei entit a ti informat ionale i se pune n corespondent a un simbol format din litere, cifre si semne speciale, c at si la extragerea rezultatelor. Problema codic arii datelor de intrare este deosebit de important a pe de o parte pentru cre sterea randamentului prelucr arilor ulterioare iar pe de alt a parte pentru o mai simpl a manipulare a acestora de c atre om. Dac a din punctul de vedere al omului se prefer a asocierea unor simboluri c at mai apropiate de limbajul natural, din punctul de vedere al calculatorului se prefer a o codicare optim a adic a cu un num ar minim de simboluri, alese n a sa fel nc at s a permit a prelucrarea cu un num ar minim de operat ii. Uneori astfel de codic ari exist a deja n sectorul de activitate din care provin datele, ind necesare n activitatea curent a. Exemplu: ntr-o colect ie de date privind student ii unei facult a ti se poate folosi n codicarea informat iei nu numele si prenumele student ilor ci codul numeric personal, av and n vedere c a ec arui student i corespunde un cod numeric personal unic. O astfel de codicare are avantajul c a elimin a orice ambiguitate n identicarea student ilor dar implic a revenirea la forma natural a de reprezentare uman a pentru a putea folosit a de c atre utilizator. La ora actual a, av and n vedere posibilit a tile oferite de sistemele de calcul moderne, se prefer a introducerea datelor cu ajutorul unor machete special concepute sau prin utilizarea unor limbaje c at mai apropiate de cele naturale. De asemenea, la extragere se prefer a formate de reprezentare c at mai sugestive, incluz and elemente multimedia u sor de interpretat, ind eliminate pe c at posibil codic arile care f aceau posibil a citirea documentelor doar de c atre speciali stii cu experient a n domeniu. 2. Codicarea intern a a informat iei. Este specic a procesului de prelucrare a datelor deoarece calculatorul lucreaz a numai n reprezentare binar a. Codicarea se poate face conform unor standarde de larg a circulat ie (ASCII, binar, binar-zecimal etc) sau pe baza unor convent ii locale care s a asigure performant e c at mai bune pentru un caz concret. De calitatea codic arii interne depind timpul de prelucrare, portabil-
23
itatea programelor, posibilitatea utiliz arii datelor de c atre mai multe categorii de utilizatori. 3. Codicarea redundant a. Este caracteristic a proceselor de transmisie si p astrare a informat iei pe diverse suporturi interne sau externe. In principiu codicarea redundant a presupune ca pe l ang a simbolurile utile (numite si simboluri informat ionale) prin care se codic a informat ia propriuzis a, s a e introduse si un num ar de simboluri suplimentare (numite si simboluri de control), aate n anumite relat ii prestabilite cu simbolurile informat ionale. Detectarea la recept ie a nc alc arii uneia dintre aceste relat ii permite detectarea si uneori chiar corectarea erorilor ap arute. Cel mai cunoscut exemplu este bitul de control la paritate, astfel ales nc at s a asigure la emisie acela si tip de paritate pentru toate grupele de bit i ce compun un mesaj. Un caz particular al codic arii interne a datelor l reprezint a compresia datelor utilizat a pe scar a larg a n special n operat iile de arhivare si la reprezentarea imaginilor si sunetelor datorit a cantit a tii mari de informat ie implicat a de acestea. Principalul obiectiv al compresiei datelor l reprezint a reducerea volumului de memorie ocupat a de date. Utilizarea compresiei datelor are pe l ang a avantajele certe legate de volumul mult mai mic de memorie ocupat a si unele dezavantaje cum ar cre sterea timpului global de lucru, sc aderea portabilit a tii programelor aplicative, sc aderea abilit a tii, cre sterea complexit a tii prelucr arilor etc. n ciuda acestor dezavantaje, colect iile de date multimedia nu pot concepute f ar a utilizarea compresiei datelor. Un aspect special al codic arii l constituie criptarea informat iei, adic a reprezentarea acesteia sub o form a special a astfel nc at s a nu poat a recunoscut a dec at de c atre cei ce cunosc regula de criptare. Criptarea poate f acut a at at la nivelul codic arii externe (de exemplu c and operatorul nu trebuie s a cunoasc a semnicat ia datelor pe care le manipuleaz a, cum este cazul unor informat ii medicale sau militare) c at si la nivelul codic arii interne pentru a preveni furturile de informat ie. Criptarea trebuie folosit a cu grij a si numai acolo unde este cu adev arat necesar a, deoarece complic a prelucr arile, cre ste timpul de lucru si poate conduce la pierderi irecuperabile de date n cazul unor accidente. Vericarea si validarea datelor Vericarea si validarea datelor reprezint a operat ii deosebit de importante deoarece introducerea unor date eronate poate compromite complet rezultatele utiliz arii datelor, cu consicent e economice sau sociale uneori inacceptabile. Vericarea si validarea datelor tre-
24
buie realizate conform unor protocoale bine puse la punct, care s a specice n clar cine r aspunde pentru corectitudinea ec arei categorii de date introduse. Vericarea si validarea pot realizate n mai multe momente de timp bine denite, cum ar : vericarea la preluarea datelor din documentele primare c and se va testa claritatea nregistr arilor, dac a documentele pot citite, dac a datele introduse sunt plauzibile si respect a standardele si normele n vigoare, dac a au fost completate toate datele solicitate etc; vericare n timpul introducerii manuale a datelor pentru a semnala dep a sirea anumitor valori limit a, nerespectarea unor formate de reprezentare, utilizarea unor simboluri neadmise etc; vericarea dup a introducerea manual a a datelor n calculator pentru eliminarea erorilor umane ce nu au putut detectate cu calculatorul n faza de introducere; este probabil cea mai important a vericare, deoarece erorile nesemnalate n aceast a faz a pot cu greu depistate n fazele urm atoare, mai ales dac a nu provoac a erori n execut ia unor programe aplicative sau dac a nu conduc la rezultate evident aberante; vericarea n timpul prelucr arilor pentru a depista dep a sirea unor valori limit a, existent a unor necorel ari ntre date; este important a mai ales n faza de testare a programelor aplicative c and se recomand a utilizarea unor date special selectate care s a permit a stabilirea corectitudinii rezultatelor obt inute n situat ii c at mai diverse (alegerea datelor de test este o problem a dicil a deoarece implic a at at o cunoa stere profund a a situat iilor reale ce pot s a apar a c at si a programelor testate si a sistemelor pe care se desf a soar a testarea); vericarea nal a a documentelor redactate n scopul valid arii corectitudinii formatelor a sate, a calit a tii imprim arii, a aspectului si completitudinii cont inutului n ainte de autenticarea prin semn atur a de c atre persoanele autorizate. Evitarea unor etape de vericare si validare pe motiv c a acestea scad viteza global a de rezolvare a aplicat iilor poate avea consecint e nale deosebit de grave care compromit ncrederea n utilizarea tehnicii de calcul si implic a uneori chiar r aspunderea administrativ a sau penal a. P astrarea datelor La ora actual a pentru p astrarea datelor se utilizeaz a n special discuri magnetice care asigur a un raport foarte bun ntre capacitatea de memorare si timpul de acces la date. n acela si timp se constat ao
25
continu a sc adere a pret ului pe unitatea de informat ie memorat a. Datorit a acestor calit a ti au putut dezvoltate colect ii de date de ordinul terraoctet ilor si se prevede pentru un viitor relativ apropiat asigurarea unor capacit a ti de ordinul petaoctet ilor. Cre sterea continu a a cantit a tii de informat ie memorat a a ridicat anumite probleme cum ar : cre sterea timpului de c autare a informat iilor utile; cre sterea complexit a tii sistemelor de gestiune a sierelor; cre sterea pericolului de pierdere a informat iei; cre sterea consecint elor negative ale unor pierderi accidentale sau distrugeri premeditate a informat iei; necesitatea introducerii unor metode sosticate de protect ie si securitate a datelor. Aceste probleme au impus dezvoltarea unor tehnici speciale pentru gestiunea memoriei secundare. n cazul unor colect ii de date din domeniul audio si video, datorit a cantit a tii foarte mari de informat ie a fost necesar a dezvoltarea unor tehnici specice de compresie si decompresie a datelor care s a asigure pe de o parte ocuparea unui volum c at mai mic de memorie iar pe de alt a parte s a permit a obt inerea n timp util a informat iilor dorite. Necesitatea asigur arii unei viteze de lucru c at mai mari a impus introducerea unor noi metode de organizare a informat iei si a unor tehnici de c autare rapid a a informat iei. Utilizarea de c atre un num ar tot mai mare de utilizatori a aceleea si colect ii de date a impus intoducerea unei discipline riguroase pentru sincronizarea accesului la date, actualizarea datelor si interzicerea acceselor frauduloase. O problem a foarte important a o reprezint a crearea cpiilor de sigurant a si a arhivelor de date, dicil de realizat si ntret inut n cazul unor colect ii de date foarte mari. Arhivarea datelor poate realizat a pe discuri exibile pentru baze de date personale, pe benzi magnetice sau pe discuri magnetice n cazul unor baze de date foarte mari. n cazul n care datele p astrate sunt de tipul cite ste numai si nu se impun restrict ii severe privind viteza de lucru, datele pot memorate si pe alte suporturi cum ar discurile CDROM cu o capacitate mare de stocare a informat iei si abilitate sporit a. Prelucrarea datelor Prelucrarea datelor nseamn a transformarea datelor pe baza unui anumit algoritm n scopul extragerii de informat ie sau cuno stint e. Elementul fundamental l reprezint a algoritmul, care poate un algoritm
26
foarte simplu (c autarea dup a un criteriu oarecare) sau sosticat (analiza datelor primare si extragerea de cuno stint e prin depistarea unor sabloane). Metodele de prelucrare difer a foarte mult n funct ie de natura datelor (c autarea dup a un cuv ant cheie este mult mai simpl a dec at c autarea dup a culoare a unei regiuni ntr-o imagine). Software-ul modern pune la dispozit ie o gam a larg a de funct ii si proceduri pentru prelucrarea datelor totu si, n continuare, realizarea programelor aplicative ram ane o sarcin a dicil a deoarece se constat a o cre stere continu a a complexit a tii aplicat iilor solicitate de beneciari. Prelucrarea datelor dintr-o colect ie de date poate realizat a prin lansarea de c atre beneciar a unei cereri simple prin care s a solicite c autarea informat iilor pe baza unor criterii prestabilite sau adhoc ori prin lansarea unor programe de prelucrare sosticate. O problem a important a o reprezint a protect ia informat iilor fat a de accesul neautorizat realizat accidental sau n scopuri frauduloase. Este necesar s a e respinse cererile formulate de persoane care nu trebuie s a aib a acces la informat ie sau pot provoca prin cererile formulate distrugerea total a sau part ial a a datelor. O situat ie special a apare n ret elele de calculatoare c and prin lansarea cu rea credint a a unor cereri repetate de prelucrare a datelor dintr-o colect ie de date se poate bloca accesul altor utilizatori la datele respective. Evitarea unor astfel de situat ii este foarte dicil a si n general proiectant ii de sisteme pentru gestiunea datelor si propun nu eliminarea propriuzis a a fraudelor ci descurajarea lor prin cre sterea pret ului de cost si timpului necesar punerii lor n aplicare precum si limitarea efectelor negative. Distribuirea rezultatelor Modul n care rezultatul prelucr arii datelor ajunge la beneciar este deosebit de important deoarece de aceasta depinde n mare m asur a nivelul de nt elegere al informat iilor furnizate. Metodele de distribuire a rezultatelor au evoluat puternic de-a lungul timpului n funct ie de evolut ia tehnologiei informatice. Principalele forme de distribuire a informat iilor obt inute prin prelucrarea colect iilor de date sunt: Documente a sate pe display - reprezint a probabil cel mai utilizat mijloc de prezentare a informat iilor n special datorit a dezvolt arii ret elor de calculatoare. Paginile de a sare a rezultatelor pot oferi facilit a ti deosebite cum ar : o gam a foarte larg a de fonturi si culori pentru a sarea textelor; imagini; grace, tabele,diagrame;
1.4. CICLURI DE VIAT A animat ie; video; avertiz ari sonore; posibilit a ti de navigare rapid a prin cont inutul documentelor; posibilit a ti de conectare rapid a la alte documente.
27
Rapoarte tip arite asem an atoare documentelor utilizate de om. La ora actual a aceste documente au ajuns la un grad nalt de sosticare put and s a cont in a texte si elemente grace, alb-negru sau color. Un accent deosebit se pune pe elementele de grac a (tabele, diagrame, grace) care pot reprezenta ntr-o form a sintetic a foarte sugestiv a informat ii importante. Fi siere pentru transferul ntre diver si beneciari, pentru arhivare sau tip arire ulterioar a. Extinderea utiliz arii ret elelor de calculatoare si n special a Internetului si a telecomunicat iilor wairless a inuent at foarte mult modul de transfer si prezentare a informat iei, mai ales prin cre sterea vitezei de transmisie a informat iilor ntre beneciari ceea ce a permis dezvoltarea unor aplicat ii de mare complexitate, cum ar comert ul electronic, tranzact iile bancare etc. Prezentarea rezultatelor prelucr arilor trebuie s a tin a cont de urm atoarele cerint e: Cerint e informat ionale informat iile oferite trebuie s a e corecte, actuale, complete, ntr-o succesiune logic a. Pe c at posibil, informat iile trebuie s a corespund a necesit a tilor beneciarului, ind evitate informat ii colaterale specice unor cereri mult mai generale. Exemplu: Dac a beneciarul dore ste lista student ilor unei anumite format ii de lucru, care au obt inut note de promovare la toate materiile dintr-o anumit a sesiune, este sup ar ator s a primeasc a o list a cu notele tuturor student ilor, la toate materiile, chiar dac a lista respectiv a cont ine si informat iile solicitate de el. Cerint e ergonomice legate n special de a sarea pe display. Este necesar ca formatul documentelor a sate s a pun a n evident a c at mai bine diversele informat ii, acestea s a poat a u sor citite si interpretate
28
CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR si s a solicite c at mai put in, zic si psihic, operatorul uman. Pentru aceasta este necesar s a e respectate c ateva reguli elementare: Se vor evita fondurile cu culori stridente (ro su, galben, magenta) mai ales dac a documentul va a sat un timp mai ndelungat. Se prefer a culori calme (albastru, verde, bej, gri). Textul va scris cu culori ce se a a n contrast c at mai puternic cu fondul pentru o citire u soar a. Pentru a pune n evident a anumite informat ii se pot folosi fonturi diferite sau culori diferite. Pentru a scoate n evident a anumite informat ii se folosesc caractere italice, sublinierea sau caractere ngro sate. Se vor utiliza pe c at posibil fonturile cu care beneciarul este obi snuit din activitatea sa curent a si formate ale documentelor c at mai apropiate de formularele tipizate utilizate n domeniul respectiv. Se evit a abuzul n folosirea caracterelor italice sau a unor fonturi sosticate deoarece acestea apar uneori deformate pe ecran si sunt greu de citit mai ales dac a se utilizez a dimensiuni mici ale caracterelor. Folosirea corect a a ident arilor simplic a c autarea informat iilor dorite n special n cazul unor informat ii puternic ierarhizate. Dimensiunea fondurilor si spat ierea ntre r anduri vor astfel alese nc at s a asigure pe de o parte o citire c at mai u soar a iar pe de alt a parte s a permit a introducerea unei cantit a ti c at mai mari de informat ie pe pagin a. Se va asigura posibilitatea revenirii rapide la paginile deja parcurse f ar a a nevoie de reformularea cererii. Cerint e estetice uneori neglijate pe motiv c a nu sunt necesare din punct de vedere informat ional si cresc nejusticat timpul de implementare si pret ul de cost al aplicat iilor. n realitate un document pl acut la vedere, echilibrat din punct de vedere al dimensiunilor si culorilor, cu un fundal adecuat subiectului, este mult mai put in obositor si are un impact favorabil asupra vitezei de citire si nt elegere. Folosirea unor imagini de calitate specice subiectului, reprezentarea grac a a unor date are ca efect asimilarea rapid a a informat iilor. Evident, abuzul de elemente artistice poate avea un efect negativ prin cre sterea volumului de memorie si a timpului de transmisie si citire, mai ales pe sistemele de calcul de calitate mai slab a.
1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 29 Dezafectarea datelor se impune ori de c ate ori, din diverse motive, datele nu mai sunt utilizate n aplicat iile curente si nu se prevede utilizarea lor ntrun viitor apropiat, adic a datele curente devin date istorice. Dezafectarea se poate realiza prin: 1. stergere care poate logic a (prin marcare pentru stergere) sau zic a c and datele sunt efectiv eliminate de pe suportul zic iar spat iul ocupat de acestea este recuperat pentru alte scopuri. S tergerea este o operat ie periculoas a deoarece din gre seal a pot sterse date utile, greu de recuperat, cu consecint e economice si juridice deosebite. 2. transferul datelor rar utilizate pe suporturi ieftine, cu performant e reduse. 3. arhivarea datelor prin copierea pe suporturi speciale pentru a utilizate ulterior n funct ie de necesit a ti. De exemplu datele despre student ii facult a tii pot arhivate la 3-5 ani dup a absolvire deoarece utilizarea lor n continuare este episodic a. Datele arhivate sunt eliminate de pe suportul curent. 4. transferul ntr-o magazie de date (data warehouse) este o variant a modern a de utilizare a datelor istorice. Periodic din baza de date curent a se transfer a instantanee care pot include si date derivate, deci magazia de date este o baz a de date nenormalizat a. Se observ a c a ultimile trei variante de dezafectare nseamn a de fapt ncheierea viet ii datelor ntr-un anumit context si nceputul unui nou ciclu de viat a al acestora ntr-un alt context.
1.5
1.5.1
Modele ale ciclului de dezvoltare a unui produs

Ce este un model?
In sensul cel mai larg, prin model int elegem o reprezentare abstract a, simplicat a, a unui fragment de realitate. Modelul conceptual este alc atuit din conceptele, structurile simbolice si mecanismele de manipulare ale acestor structuri care corespund posibilit a tilor de reectare a lumii reale privit a ca obiect al cunoa sterii. Int elegerea modelului ca imagine a capacit a tii omului de a reecta lumea nconjur atoare are c ateva consecint e deosebit de importante:
30
CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR Modelul ata sat unui obiect sau fenomen nu este unic. Modele diferite pot reprezenta acela si obiect sau fenomen cu diferite grade de abstractizare, detaliere, precizie. Aceasta impune elaborarea unor criterii obiective pentru compararea Intre ele a diverselor modele In scopul utiliz arii modelului optim pentru un anumit scop. Modelele au un caracter dinamic. Modelele pot s a evolueze In funct ie de necesit a tile de precizie impuse, de posibilit a tile de prelucrare a informat iei sau de cuno stint ele nou ap arute ce permit cre sterea com plexit a tii modelelor. In general, modelele se obt in printr-un proces de ranare care permite pe de o parte cre sterea preciziei de reprezentare prin punerea n evident a a unor noi detalii iar pe de alt a parte nglobarea de noi aspecte, neluate n considerare de modelele anterioare. Aparit ia noilor modele nu nseamn a neap arat renunt area la vechile modele deoarece ecare model are propria lui arie de aplicabilitate optim a. Modelul trebuie validat prin comparare cu realitatea. Un model se dovede ste util numai atunci c and permite reprezentarea corect a a unor fenomene deja cunoscute, precum si predict ia altor fenomene care urmeaz a s a e descoperite. De multe ori, noile descoperiri impun dezvoltarea vechiului model sau chiar nlocuirea lui cu un model nou.
Modelele procesului de dezvoltare a produselor pun n evident a strategia aleas a de proiectant pentru desf a surarea procesului care conduce de la formularea cerint elor impuse produsului p an a la implementarea acestuia. Fiecare model descrie fazele parcurse de proiect, obiectivele ec arei faze, mijloacele de realizare, riscuri, constr angeri, metodele de evaluare a rezultatelor, documentat ia aferent a. Exist a multe modele, ecare cu avantajele si dezavantajele lui pentru un proces concret.
1.5.2
Modelul cascad a (waterfall model)
Modelul cascad a al desf a sur arii unui proiect este probabil cel mai popular si utilizat model de dezvoltare a produselor de si i s-au adus numeroase critici. Etapele specice acestui model sunt reprezentate n Figura 1.12. Metoda de dezvoltare descris a de acest model este liniar a si secvent ial a. Pentru ecare faz a exist a obiective precise, rezultatele unei faze devenind intr ari pentru faza urm atoare. Intoarcerea napoi pentru refacerea unei faze este foarte dicil a. Fiecare faz a se desf a soar a n intervale de timp bine stabilite, nu exist a suprapuneri ntre faze sau iterat ii. Principalul avantaj al metodei l
1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 31
Figura 1.12: Modelul cascad a al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003).
reprezint a simplicarea managementului si a distribuirii sarcinilor pe departamente funct ionale. Fiecare faz a poate executat a de o echip a specializat a si pentru ecare faz a pot stabilite termene precise de ncheiere. Eliminarea erorilor ap arute pe percursul naliz arii unei faze poate realizat a numai n momentul trecerii la faza urm atoare prin realizarea unor revizii detaliate. Un produs funct ional este disponibil doar spre sf ar situl ciclului de dezvoltare ceea ce face ca progresele sau decient ele existente s a e vizibile cu mare nt arziere. Din aceast a cauz a erorile de documentare din fazele init iale vor putea eliminate doar n faza de mentenant a corectiv a. Moidelul cascad a se recomand a n cazurile n care cerint ele impuse produsului sunt cunoscute de la nceput si nu exist a riscul s a e modicate pe parcurs.
32
1.5.3
Modelul incremental
Modelul incremental este un model iterativ, ind n esent a o succesiune de cicluri cascad a (vezi Figura 1.13). Utilizarea este recomandat a acolo unde se cunosc de la nceput cerint ele impuse proiectului si acestea pot mp art ite n mai multe grupe distincte astfel nc at pentru ecare grup s a poat a aplicat un ciclu cascad a. Rezultatul unui ciclu devine intrare pentru urm atorul ciclu.
Figura 1.13: Modelul incremental al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003).
Principalele avantaje ale modelului sunt [14]: Dac a proiectul este bine gestionat, poate exista o anumit a suprapunere ntre ciclurile cascad a adic a un ciclu poate s a nceap a n aintea naliz arii ciclului precedent. Ciclurile mai noi beneciaz a de experient a acumulat a n ciclurile mai vechi. Cerint ele sunt relativ stabile si pot mbun at a tite la ecare iterat ie ceea ce-l face mult mai exibil dec at modelul cascad a. Un produs funct ional (chiar dac a incomplet) este disponibil nc a de la sf ar situl primei iterat ii ceea ce u sureaz a testarea n iterat iile urm atoare. Rezolvarea implic a folosirea unor echipe mai mici. Progresele si erorile sunt vizibile mult mai repede si pot inuent a evolut ia dezvolt arii produsului. Testarea este mult mai u sor de realizat pe unit a ti mai mici de produs. Printre dezavantajele puse n evident a n literatura de specialitate g asim:
1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 33 Majoritatea cerint elor trebuie s a e cunoscute nc a de la nceputul proiectului. Deoarece dezvoltarea este distribuit a pe durata mai multor iterat ii, trebuie foarte bine denite nc a de la nceput interfet ele ntre module. Operarea este afectat a ori de c ate ori o nou a versiune este distribuit a. Utilizatorii sunt obligat i s a nvet e cum s a lucreze cu ecare versiune. Modelul incremental este recomandat atunci c and cerint ele pot formulate nc a de la nceput dar rezolvarea unora dintre ele poate s a benecieze de pe urma experient ei din versiunile anterioare. De asemenea, modelul este foarte util pentru proiectele a c aror nant are este asigurat a n etape f ar aa putea garanta continuitatea nant arii. Dezvoltarea pe durata a mai multor iterat ii permite si o administrare mai simpl a a riscurilor, deoarece ecare iterat ie trebuie s a rezolve un num ar mai mic de riscuri.
1.5.4
Modelul evolutiv (evolutionary model)
Ca si modelul incremental, modelul evolutiv permite dezvoltarea unui produs printr-un proces iterativ, dar spre deosebire de modelul incremental care doar adaug a mai mult a funct ionalitate la ecare ciclu, modelul evolutiv produce la ecare iterat ie un prototip mai ranat. In Figura 1.14 se observ a c a operat iile de dezvoltare a proiectului pot grupate n 4 categorii: planicare; analiza riscurilor; inginerie; evaluarea de c atre utilizator. Spirala este parcurs a dinspre centru c atre exterior. Procesul de dezvoltare a produsului ncepe cu captarea cerint elor si planicarea activit a tilor. Prima analiz a a riscurilor se bazeaz a pe cerint ele init iale dup a care se poate trece la realizarea prototipului init ial. Utilizatorul poate evalua prototipul init ial si pe baza concluziilor va reformula cerint ele inii ale si va introduce dac a este necesar noi cerint e. Din acest moment ncepe un nou ciclu de dezvoltare. Generarea specicat iilor, dezvoltarea proiectului si testarea se realizeaz a n
34
Figura 1.14: Modelul evolutiv al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003).
ecare iterat ie pe durata fazei de inginjerie. Deoarece cerint ele sunt modicate permanent, este foarte dicil s a se realizeze o documentat ie complet a la ecare iterat ie de si informat ii esent iale sunt necesare pentru nt elegerea evolut iei produsului si ca suport pentru documentat ia nal a. La ecare iterat ie se accept a anumite compromisuri pentru ca prototipul s a e funct ional n timp util, ceea ce va impune eliminarea lor n iterat iile urm atoare. Ca si n cazul modelului iterativ, prototipul este funct ional foarte repede dar la ecare iterat ie modul de operare se poate modica dramatic. Utilizarea modelului evolutiv se recomand a n cazul unor proiecte care au urm atoarele caracteristici [14]: sisteme software-intensive;
1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 35 este necesar a modicarea frecvent na a tehnologiilor software; componenta uman a este integrat a n sistem; exist a un num ar mare de diver si utilizatori; sistemul este complet nou, nu exist a un sistem cu acelea si capabilit a ti; un sistem cu put ine capabilit a ti este acceptabil dac a este disponibil repede.
1.5.5
Modelul spiral a
Modelul spiral a a fost dezvoltat cu scopul de a reduce riscul n ciclul de viat a al softwareului [15]. El combin a elemente ale celor trei modele prezentate anterior si, n funct ie de implementarea concret a a modelului, propriet a tile unuia dintre cele trei modele poate predominant. Una dintre multele variante ale modelului este reprezentat a n diagrama din Figura 1.15. Spirala este parcurs a dinspre centru c atre exterior, trec and ciclic prin patru faze de dezvoltare: Determinarea obiectivelor, alternativelor si restrict iilor. Evaluarea alternativelor, identicarea si rezolvarea riscurilor. Dezvoltarea produsului de la nivelul urm ator. Planicarea urm atorului ciclu. Managementul riscurilor este elementul cheie al modelului spiral a si de aceea n ecare ramur a a spiralei sunt identicate problemele cu cel mai mare risc si solut iile sunt orientate spre rezolvarea acestora. Softwareul nu este dezvoltat p an a n ultima etap a. Principalele avantaje ale modelului sunt [14]: asigur a cel mai bun management al riscului; cerint ele sunt mult mai bine denite; sistemul nal va r aspunde mult mai bine necesit a tilor beneciarului. Principalele dezavantaje puse n evident a sunt [14]: este un model complex, greu de administrat pe toat a durata dezvolt arii;
36
Figura 1.15: Modelul spiral a al dezvolt arii unui produs (conform Condensed GSAM Handbook - Februarie 2003).
cre ste pret ul dezvolt arii. Dezvoltarea n spiral a este un proces iterativ folosit pentru a dezvolta un set de capabilit a ti ntr-un singur increment. Un increment poate format din una sau mai multe spire.
1.5.6
Modelul V
Modelul V este de obicei utilizat pentru a identica relat ia ntre faza de dezvoltare si faza de testare si c toate m asurile corespunz atoare pentru asigurarea calit a tii si testele sunt prezente la momentul potrivit pe parcursul ciclului de dezvoltare. Un exemplu de model V este cel din Figura 1.16. Utilizarea modelului prezint a c ateva avantaje [17]:
Figura 1.16: Modelul V al dezvolt arii unui produs (conform CA267 - Software Testing - Testing and the Software Lifecycle - David Sinclair).
1. Spre deosebire de modelele prezentate anterior (numite si modele clasice) care plaseaz a activitatea de testare spre sf ar situl procesului/iterat iei de dezvoltare, modelul V permite distribuirea activit a tii de testare pe ntreaga durat a a dezvolt arii, ceea ce reduce timpul total de dezvoltare (testele pot preg atite nainte de a ncepe testarea propriuzis a) Pentru ecare etap a atest arii exist a o documentat ie bine pus a la punct. 2. Abordarea test arii nc a din prima etap a de dezvoltare este formulat a explicit. Evident, testarea si depanarea pot realizate n orice etap a dar eliminarea defectelor n etapele nale este mult mai dicil a si mai costisitoare, cresc and timpul de dare n folosint a. In lucrarea citat a se apreciaz a c a dac a costul elimin arii unei erori pe durata proiect arii cost a reprezint a o unitate, eliminarea ei chiar naintea trecerii la testare cost a 6.5 unit a ti iar eliminarea pe durata test arii cost a
38
CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR 15 unit a ti. Eliminarea acelea si erori dup a lansarea n execut ie a versiunii poate s a ajung a p an a la 60 sau chiar 100 unit a ti! Eliminarea c at mai timpurie a erorilor implic a asigurarea unui nivel ridicat al calit a tii documentelor specice capt arii cerint elor si formul arii specicat iilor funct ionale. Aceasta se realizeaz a prin vericarea riguroas a a acestor documente nainte de a trece la proiectare/implementare. 3. Este introdus a clar ideea de specicare a cazurilor de test (diverse seturi de valori ale intr arilor si rezultatele considerate corecte pentru ecare set). 4. Modelul V dene ste riguros ce teste trebuie efectuate pentru ecare etap a. Se observ a din diagrama modelului c a n timp ce ramura descresc atoare dene ste sucesiunea etapelor de dezvoltare exact ca n modelul cascad a, ramura cresc atoare dene ste o succesiune riguroas a de etape de testare. Se mai observ a c a ecare de testare este planicat a pe durata etapei paralele din ramura de dezvoltare. 5. Modelul V ofer a o baz a pentru a putea preciza cine r aspunde de realizarea test arii pentru ecare etap a a dezvolt arii. Existen a mai multor categorii de testori permite o mai bun a specializare si cre sterea performant ei lor.
1.5.7
Modelul W
Modelul W a fost creat pentru a elimina rolul oarecum secundar acordat test arii de c atre celelalte modele de dezvoltare analizate anterior. Principalele decient e care se pot constata n leg atur a cu testarea sunt: activitatea de testare ncepe relativ t arziu, uneori dup a implementare; leg atura ntre diversele etape ale test arii si funamentul test arii nu este foarte clar; nu este claricat a leg atura ntre activit a tile de testare, depanare si actualizare, de si acestea sunt conectate n mod natural. Modelul W (Figura 1.17) se bazeaz a pe modelul V general prezentat n paragraful precedent. Pentru a pune pe picior de egalitate dezvoltarea cu testarea, a fost ad augat nc a un model V dedicat activit a tilor de testare. Cele dou a V-uri formeaz a mpreun a modelul W [18]. Avantajele modelului W:
Figura 1.17: Modelul W al dezvolt arii unui produs (conform Software Development Models ).
Modelul W pune clar n evident a activit a tile specice test arii si ordinea n care acestea sunt realizate. Spre deosebire de modelul V care face o distinct ie net a ntre operat iile de dezvoltare (ramura descresc atoare) si operat iile de testare (ramura cresc atoare), modelul W pune n evident a conexiunea str ans a ntre dezvoltare si testare. De aceea dezvoltatorii si testorii sunt tratat i ca membri cu drepturi egale, cu sarcini distincte, precis denite. Testorul trebuie s a descopere anomaliile iar dezvoltatorul trebuie s a le elimine si s a fac a corect iile. Se ncearc a eliminarea conictelor care apar ntre dezvoltatori si testori atunci c and ace stea sunt privit i ca dou a tabere cu interese diferite. Testorul nu mai este doar o persoan a care v aneaz a gre seli, el nu se limiteaz a s a construiasc a, s a execute si s a evalueze cazuri de test, ci contribuie direct, al aturi de dezvoltator, la asigurarea calit a tii produsului/serviciului. Dezavantajele modelului W: Principalul dezavantaj al modelului, subliniat de mult i autori, const a n simplicarea relat iilor existente ntre diversele componente ale procesului de dezvoltare. Totu si aceast a simplicare poate privit a si ca un factor po-
40
zitiv, deoarece permite nt elegerea si utilizarea modelului de c atre un mare num ar de participant i la procesul de dezvoltare/testare. De fapt tocmai simplitatea face ca In practic a s a e preferat de multe ori modelul V. Modelul W nu claric a problema naturii si cantit a tii resurselor alocate testorului, creind impresia c a acestea sunt la acela si nivel cu cele ale dezvoltatorului, ceea ce nu este adev arat. De exemplu, pentru aplicat ii critice (medicin a, energie nuclear a, minerit, industrie chimic a etc.) pentru testare pot alocate resurse cel put in la nivelul dezvolt narii.
Capitolul 2
Calitatea si managementul calit a tii

2.1 Abord ari ale denirii calit a tii
La ora actual a probabil c a nu exist a domeniu de activitate n care s a nu se utilizeze, al aturi de conceptele informat ie, date, cunostint e, sistem, soft, hard, Internet, si conceptul calitate. O tr as atur a comun a a acestor termeni este aceea c a toat a lumea i folose ste dar foarte put ini sunt cei capabili s ai deneasc a n vreun fel (de exemplu pentru foarte multi oameni termenii informat ie, dat a, cuno stint a sunt sinonimi). In cazul conceptului calitate, care ne intereseaz a n acest capitol, a sa cum se specic a si in lucrarea [29], probabil ecare are o idee despre ce nseamn a calitate. Termenul calitate deriv a din cuv antul latin qualitas cu semnicat ia atribut, proprietate. In ncercarea de a deni calitatea pot puse n evident a dou a moduri de abordare [32]: abordarea popular a; abordarea profesional a. In general, abordarea popular a a calit a tii presupune c a aceasta poate discutat a si chiar apreciat a, dar nu poate masurat a si cuanticat a, conform principiului o recunosc c and o v ad (I know it when I see it ). In lucrarea [64] vol.2 sunt precizate urm atoarele denit ii ale termenului calitate:
41
42
II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT 1. totalitate a nsu sirilor care fac ca un lucru s a e ceea ce este, deosebinduse de alte lucruri ; 2. nsu sire (bun a sau rea);fel de a (bun sau r au) ;
Din aceast a cauz a aprecierea calit a tii se face prin termeni vagi, cum ar bun a, proast a, acceptabil a. O astfel de abordare este periculoas a n sensul c a poate conduce la ideea c a este foarte greu sau chiar imposibil s a control am sau administr am calitatea. O alt a abordare popular a se refer a la clasa produselor de calitate n care sunt incluse produsele de lux, scumpe. Astfel, tot n lucrarea [64] pentru calitate mai sunt specicate urm atoarele semnicat ii: 1. de valoare, din material pret ios sau bine realizat ; 2. caracteristic a pozitiv a; noblet e, valoare ; 3. pozit ie,situat ie; titlu care confer a un drept. S i aceast a abordare are un efect negativ, induc and ideea c a termenul calitate este sinonim cu excelent a, de except ie. Evident, n cadrul cursului ne intereseaz a numai abordarea profesional a a calit a tii. Diverse denit ii ale calit a tii au fost formulate din diverse perspective profesionale (vezi Figura 1.1): - din punct de vedere losoc; - din punct de vedere al produsului; - din punctul de vedere al diver silor actori participant i la procesul de product ie). In lozoe calitatea desemneaz a proprietate care se aplic a lucrurilor luate individual, n contrast cu relat ia, care se aplic a lucrurilor luate c ate dou a, c ate trei etc. [65] vol 3. Ca si abordarea popular a, lozoa tinde s a vad a calit a tile legate e de simt uri subiective e de fapte obiective [66]. Subiectiv, ceva poate bun deoarece este util, deoarece este frumos sau pur si simplu indc a exist a. Dar aceasta implic a s a putem deni clar ce nseamn a util, ce nseamn a frumos sau ce nseamn a a exista.
II 2.1. ABORDARI ALE DEFINIRII CALITAT
43
Figura 2.1: Perspective din care poate denit a calitatea.
Abordarea lozoc a a calit a tii apare nc a din antichitate, cea mai cunoscut a ind cea a lui Aristotel n lucrarea Categorii [19][50]. Distinct ia f acut a de Galilei si de John Locke (secolul XVII) ntre calit a tile primare si cele secundare este motivat a de faptul c a stiint a a dovedit c a percept iile senzoriale brute furnizeaz a informat ii incomplete, vagi sau chiar false despre calit a tile intrinsece ale obiectelor zice. Calit a tile primare (forma, cantitatea, viteza, dimensiunile etc.) sunt propriet a ti reale ale lucrurilor, ce pot descrise prin mijloacele obiective puse la dispozit ie de matematic a. Calit a tile secundare se datoreaz a simt urilor (miros, gust, culoare etc.) deci sunt subiective si nu exist a dec at la nivelul con stiint ei [41] [65] vol 3. In cadrul cursului se vor utiliza n special denit iile bazate pe perspectivele produc atorului si utilizatorului.
Abordarea profesional a bazat a pe principii inginere sti, presupune calitatea ca ind un concept riguros denit, m asurat, monitorizat, administrat si mbun at a tit. Pentru a permite o abordare inginereasc a a calit a tii, o problem a important a care a trebuit rezolvat a a fost stabilirea unor metode si
44
II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT
tehnici de m asurare a calit a tii. Walter Andrew Shewhart(1891-1967) cunoscut ca p arintele controlului statistic al calit a tii sau ca bunicul controlului total al calit a tii, scria n lucrarea Economic control of quality of manufactured product (1931): Exist a dou a aspecte de baz a ale calit a tii: Unul dintre ele are de a face cu considerarea calit a tii unui lucru ca o realitate obiectiv a, independent a de existent a omului. Cel alalt aspect are de a face cu ceea ce g andim, simt im sau apreciem ca rezultat al realit a tii obiective. Cu alte cuvinte, exist a o latur a subiectiv aa calit a tii. Unii anali sti ai lucr arilor lui Shewart consider a c a prin denit ia anterioar a au fost trasate cu mult timp n urm a cele dou a direct ii majore de abordare a calit a tii: conformitatea cu specicat iile (latura obiectiv a); conformitatea cu necesit a tile (latura subiectiv a). Abordarea modern a a teoriei calit a tii n product ie apare chiar la nceputul anilor 70. Walter Edwards Deming (19001993), a fost un statistician, profesor, autor de lucr ari stiint ice, si consultant american, mult mai cunoscut n Japonia unde, nc a din anii 1950 a fost preocupat de mbun at a tirea proiect arii si a serviciilor, cre sterea calit a tii, testare, prin diferite metode, printre care si utilizarea metodelor statistice. Deming este puternic legat de ridicarea Japoniei la rang de mare putere economic a. In lucrarea Out of the crisis: quality , Deming arma: Problema inerent a n ncercarea de a deni calitatea unui produs, aproape oric arui produs, a fost formulat a de maestrul Walter A. Shewhart. Dicultatea n denirea calit a ii const a n a transforma viitoarele necesit a ti ale utilizatorului n caracteristici m asurabile astfel nc at produsul s a poat a proiectat si produs ca s a dea satisfact ie la un pret pe care utilizatorul s al pl ateasc a. Aceasta nu este u sor, si imediat ce cineva se simte inving ator n aceast a ncercare, el va constata c a dorint ele utilizatorului s-au schimbat, au intervenit concurent ii etc. Pentru a si implementa ideile asupra calit a tii, Deming a formulat 14 reguli pentru managementul trecerii la o activitate orientat a pe calitate:
II 2.1. ABORDARI ALE DEFINIRII CALITAT
45
1. crearea unui mediu stabil pentru mbun at a tirea produselor si serviciilor; 2. adoptarea unei noi lozoi ( n care gre selile si negativismul nu au loc); 3. eliminarea necesit a tii veric arilor de mas a (prin realizarea unor produse de calitate garantat a); 4. renunt area la evaluarea produselor doar pe baza pret ului (preferabil orientarea c atre un pret de cost global minim si un furnizor unic); 5. mbun at a tirea continu a si permanent a a sistemului de product ie/servicii; 6. institut ionalizarea preg atirii profesionale; 7. institut ionalizarea conducerii; 8. eliminarea fricii; 9. eliminarea barierelor ntre departamente; 10. eliminarea lozincilor, ndemnurilor si tintelor numerice; 11. eliminarea normelor strict cantitative (realizate de multe ori cu costuri mari si calitate sc azut a); 12. eliminarea barierelor n calea dezvolt arii m andriei pentru munca depus a; 13. instituirea unui program serios de educare; 14. luarea unor m asuri pentru realizarea transform arii (trecerea la o activitate orientat a pe calitate). Observat ie! Aceste reguli au fost nglobate n principiile managementului calit a tii cuprinse n standardul ISO 9001:2000. De si n ultimii 40 ani au fost redactate standarde de calitate pentru foarte multe domenii, inclusiv software si hardware, nu exist a totu si o denit ie unanim acceptat a pentru conceptul calitate. Modul de denire a acestui concept a variat mult de-a lungul timpului. In 1970, unul dintre cei mai mari speciali sti n domeniul calit a tii, Joseph Moses Juran (nascut n 1904 la Br aila [71]) arma [20][74] c a putem spune c a un produs este de calitate dac a este bun pentru utilizare. Aceast a denit ie trebuie completat a cu criterii clare prin care s a putem aprecia obiectiv c a un
46
produs este bun pentru utilizare. Accentul este pus de obicei pe ndeplinirea tuturor funct iilor dorite de utilizator si pe sigurant a n funct ionare. O alt a denit ie foarte cunoscut a a calit a tii, formulat a de J.M. Juran este [73][74] potrivirea cu scopul (tness for purpose) [73]. De si pare mai u sor de nt eles si utilizat, si aceastu a denit ie necesit a l amuriri suplimentare legate de cine trebuie s a formuleze scopul. Armand Vallin Feigenbaum (n. 1922) om de afaceri si expert n domeniul calit a tii este considerat init iatorul conceptului Total Quality Control, transformat mai t arziu tn Total Quality Management. Acesta sust inea: Calitatea produselor si serviciilor poate denit a ca: totalitatea caracteristicilor de marketing, proiectare, product ie si mentenant a ale unui produs/serviciu , prin care acest produs/serviciu va satisface a stept arile clientului. Aceast a denit ie este evident orientat a pe conformitate cu necesit a tile clientului. Feigenbaum a scos in evident a c a important a este satisfacerea necsit a tilor prezente si viitoare ale clientului si, deoarece cerint ele se modic a permanent, calitatea are un caracter dinamic. In 1979, Philip B. Crosby (1926-2001), o alt a personalitate marcant a n domeniul calit a tii [72], va lansa ideea calitatea este gratuit a (quality is free) [22][73][74]. El dene ste calitatea ca ind conformitate cu cerint ele (conformance to requirements) iar costul calit a tii poate m asurat prin cheltuielile datorate nerespect arii cerint elor (expense of nonconformance). De asemenea, introduce ideea c a zero defecte reprezint ao tint a realist a. Aceste idei precum si altele introduse ulterior vor inuent a hot ar ator abordarea calit a tii n diverse domenii de activitate, gener and publicarea unui num ar mare de lucr ari care au analizat critic diversele concepte, nuant andule sau introduc and noi concepte ce si-au dovedit utilitatea n timp. Poate cea mai socant a dintre ideile lui Crosby pare armat ia calitatea este gratuit a. Aceast a armat ie, prezentat a de multe ori rupt a din context, este explicat a foarte clar chiar de Crosby n [22]: Calitatea este gratuit a. Ea nu este un dar, dar este gratuit a. Ceea ce cost a bani sunt lucrurile f ar a calitate toate act iunile implicate de faptul c a lucrurile nu sunt realizate cum trebuie din primul moment. (Quality is free. Its not a gift, but it is free. What costs money are the unquality things all the actions that involve not doing jobs right the rst time.).
I, CERINT 2.2. NECESITAT E, AS TEPTARI
47
Evident, pentru a obt ine un produs care s a satisfac a la cel mai nalt nivel cerint ele beneciarilor, costurile de product ie vor substant ial mai mari dec at n cazul unui produs similar dar care ignor a o parte din cerint e. De exemplu, realizarea unui produs cu o durat a de funct ionare garantat a c at mai mare poate s a coste mult mai mult dec at realizarea aceluia si produs cu materiale sau tehnologie care asigur a o durat a de funct ionare mai mic a (cine nu crede, poate s a mearg a la magazin s a compare pret ul unui bec cu lament- care se arde dup a cel mult c ateva luni cu pret ul unui bec economic, garantat pentru 3 ani). Problema n acest caz este cine suport a cheltuielile generate de lipsa de calitate. Dac a aceste cheltuieli sunt suportate de c atre produc ator acesta va avea tot interesul ca n timp c at mai scurt s a treac a la utilizarea unor materiale si tehnologii care s a-i asigure un nivel corespunz ator de competitivitate pe piat a. Exist a ns a situat ii ca n cazul produselor de larg consum, c and, cel put in ntr-o prim a faz a, cheltuielile legate de lipsa calit a tii le suport a beneciarul. Aceast a situat ie face ca produc atorul s a e relativ put in interesat, sau chiar deloc, de cre sterea calit a tii produsului. De obicei, dup a un timp, beneciarul nt elege c a folosirea produselor cu care a fost obi snuit nu este rentabil a si va ncerca s a fac a efortul pentru a trece la produse de calitate superioar a. Eliminarea de pe piat a a produselor inferioare se face ns a destul de greu (mai ales n societ a tile cu un nivel de trai si de cultur a sc azut), ind uneori necesare chiar m asuri la cele mai nalte nivele de decizie economice, administrative sau politice. Standardul ISO 9000 pentru managementul calit a tii preia denit ia calit a tii propus a de Crosby si o dezvolt a sub forma: m asura n care un ansamblu de caracteristici intrinseci ndeplinesc cerint ele.
2.2
2.2.1
Necesit a ti, cerint e, a stept ari

Necesit a ti
In sect iunea precedent a am utilizat frecvent termenii necesitate, cerint a, a steptare f ar a a accentua diferent a semantic a ntre ele, ceea ce poate provoca anumite confuzii. In aceast a sect iune cei trei termeni vor analizat i n detaliu pentru a elimina eventualele anomalii n utilizarea lor. Prin necesit a ti vom desemna totalitatea funct iilor si caracteristicilor unui produs/serviciu care asigur a nivelul optim de satisfact ie al unei anumite p art i interesate.
48
Evident termenul se refer a la oameni. Mult i sociologi, psihologi, lozo au fost interesat i de-a lungul timpului s a pun a n evident a necesit a tile reale ale oamenilor si s a arate care este raportul ntre necesit a ti si dorint e/a stept ari. n Figura 2.2 este reprezentat a o propunere de ierarhizare a necesit a tilor umane generale, realizat a de c atre psihologul umanist american Abraham Maslow. La ora actual a exist a mai multe variante ale acestei piramide a necesit a tilor, unele cu mai multe nivele. Primul nivel este dedicat necesit a tilor ziologice, primare, f ar a de care nici
Figura 2.2: Ierarhia necesit a tilor umane generale (piramida lui Maslow).
o int a vie nu poate supraviet ui. Urm atorul nivel, al securit a tii, se refer a de asemenea la necesit a ti fundamentale, ns a specic umane (necesitatea unui loc de munc a, unui venit sigur, familie, moralitate, proprietate). Anumite necesit a ti din aceast a categorie sunt totu si prezente si la alte categorii de animale superioare (ad apost, s an atate, relat ii sociale/familiale). Se observ a c a aceste dou a nivele implic a din partea omului cele mai mari cheltuieli materiale si efort ns a satisfacerea lor nu ofer a pentru majoritatea oamenilor dec at un nivel relativ redus de satisfact ie.
49
Urm atoarele trei nivele reprezint a necesit a ti caracteristice oamenilor. Satisfacerea lor implic a din ce n ce mai put ine eforturi si cheltuieli materiale dar provoac a mult mai mult a satisfact ie. In realitate, aceste necesit a ti intereseaz a un num ar relativ mic de oameni comparativ cu necesit a tile fundamentale. Ultimul nivel, autoperfect ionarea, ar trebui s a e nivelul c atre care s a tind a tot i oamenii. El se refer a la moralitate, creativitate, spontaneitate, lipsa prejudec a tilor, accptarea realit a tii.
2.2.2
Cerint e
Prin cerint e vom desemna o reprezentare formal a a unor necesit a ti, rezultat a de obicei n urma unor negocieri ntre diversele p art i interesate. Cerint a este o declarat ie care identic a un atribut, o caracteristic a a unui sistem pentru ca acesta s a aib a valoare si utilitate pentru un beneciar. Pentru ca un enunt s a poat a considerat o cerint a acceptabil a, este necesar ca el s a posede cel put in urm atoarele caracteristici: Unicitate - orice cerere se refer a la o singur a entitate. Completitudine - ecare cerint a este formulat a cu toate detaliile ntr-un singur loc. Consistent a - o cerint a nu trebuie s a contrazic a o alt a cerint a sau cuno stint e acumulate anterior. Atomicitate - nici o cerere nu cont ine mai multe propozit ii legate prin conjunct ii. Dac a n enunt ul init ial apar n conjunct ii, acesta va descompus n n+1 enunt uri distincte. Necesitate - cerint ele trebuie s a corespund a cel put in unei p art i a necesit a tilor p art ilor interesate. Actualitate - o cerint a trebuie s a corespund a necesit a tilor actuale si viitoare si s a nu devin a nvechit a/dep a sit a un interval de timp rezonabil. Modicarea frecvent a a cerint elor poate conduce la un management al calit a tii instabil, haotic. Fezabilitate - cerit a poate implementat a n condit iile restrict iilor impuse proiectului. Claritate - cerint a trebuie formulat a concis, f ar a jargon tehnic, abuz de acronime (chiar dac a acestea sunt explicate ntr-un document separat) si direct, f ar a aluzii greu de nt eles sau perifraze. Ea trebuie
50
II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT s a exprime fapte obiective si nu opinii personale. O cerint a nu trebuie s a permit a mai multe interpret ari diferite. Sunt interzise formul arile negative sau fraze lungi. Se vor evita calicative vagi, de tipul frumos, bun, elegant etc. Obligativitate - cerint a reprezint a o caracteristic a denit a de parteneri, a c arei absent a se presupune c a va conduce la anomalii ce nu pot ameliorate. Din aceast a cauz a, o cerint a opt ional a este o contradict ie n termeni. Vericabilitate - implementarea cerit ei poate pus a n evident a prin: inspect ie, demonstrat ie, testare sau analiz a.
O clasicare a cerint elor este cea prezentat a n Figura 2.3.
Figura 2.3: Clasicarea cerint elor.
Conceptele cerint a funct ional a respectiv cerint a non-funct ional a au fost prezentate prima oar a de c atre R.T. Yeh la conferint a Computer Software and Application. Detalierea cerint elor funct ionale o realizeaz a G.C. Roman n 1985. Cerint ele funct ionale (functional requirements) descriu ce ne a stept am s a realizeze un sistem. Descrierea unei funct ii presupune precizarea unor m arimi de intrare, a proceselor aplicate acestor m arimi si a rezultatelor a steptate. Planul pentru implementarea cerint elor funct ionale este detaliat
51
n proiectul sistemului. Cerint e non-funct ionale (non-functional requirements) sunt acele cerint e care specic a criterii ce pot utilizate pentru a evalua operarea unui sistem, nu funct iiile realizate de acesta. Cerint ele non-funct ionale denesc cum se presupune c a trebuie s a e un sistem. Planul pentru implementarea cerint elor non-funct ionale este detaliat n arhitectura sistemului. Exist a autori care nu sunt de acord cu not iunea de cerint a non-funct ional a, deoarece aceasta ar putea duce la ideea c a acestea sunt cerint e de categoria a doua, neimportante, neglijabile. Ca termen nlocuitor se propune calit a ti ale sistemului. Alt i termeni utilizat i sunt restrict ie, atribute ale calit a tii, obiectivele calit a tii. O detaliere a cerint elor non-funct ionale este prezentat a n Figura 2.4. Unele dintre aceste cerint e se refer a la structura sistemului (mentenabilitate, testabilitate, scalabilitate, extensibilitate) n timp ce altele pot puse n evident a doar pe durata funct ion arii (utilizabilitate, securitate).
Figura 2.4: Clasicarea cerint elor non-funct ionale.
2.2.3
A stept ari
Prin a stept ari vom nt elege dorint e obiective si/sau subiective ale membrilor unei p art i interesate, care nu au neap arat corespondent n necesit a tile reale sau n cerint ele formulate explicit. Observat ii! Din diverse motive, nu toate necesit a tile sunt transformate
52
n cerint e. Este posibil ca unele cerint e s a e formulate incomplet, ambiguu sau chiar gre sit. De obicei cerint ele nu capteaz a toate necesit a tile. Din motive obiective sau subiective unele a stept ari nu se reg asesc printre cerint ele formulate si acceptate. Uneori a stept arile sunt nerealiste, imposibil de realizat cu tehnologiile disponibile sau la un pret de cost acceptabil.
2.3
Categorii de p art i interesate
Parte interesat a (interested party, stakeholder) este o persoan a sau un grup de persoane care are interese legate de performant ele sau succesul unei organizat ii.(ISO 9000:2000). Exist a mai multe categorii de persoane interesate, principalele categorii ind puse n evident a n iagrama din Figura 2.5. Intre aceste categorii pot exista relat ii de colaborare, de c Principalele categorii de p art i interesate puse n evident a sunt:
Figura 2.5: O clasicare a purt atorilor de interese.
Partener (partner) - orice persoan a sau organizat ie care poate furniza ceva unei organizat ii sau poate obt ine ceva de la o organizat ie. Beneciar (customer) - organizat ie care prime ste un produs sau un serviciu. Beneciar intern (internal customer) - subunitate (departament, sect ie, serviciu ) in cadrul unei organizat ii, care prime ste resurse de
I INTERESATE 2.3. CATEGORII DE PART
53
la una sau mai multe subunit a ti si livreaz a rezultatul activit a tii sale altor subunit a ti. Observat ie! Beneciarul intern are dublu rol. Pe de o parte el este beneciar si poate s a emit a propriile lui cerint e, iar pe de alt a parte este furnizor si trebuie s a tin a cont de cererile pe care i le formuleaz a cei pentru care livreaz a produse/servicii. O astfel de situat ie poate da na stere la anomalii n funct ionarea organizat iei, la tensiuni ntre angajat i, la aparit ia unor puncte inguste etc. Pentru a evita o astfel de situat ie se impune optimizarea global a a uxului de product ie, toate cererile beneciarilor interni ind calibrate n raport cu cerint ele client ilor (vezi Figura 2.6, 2.7, 2.8). Angajat i (employee) - reprezint a o resurs a important a a oric arei organizat ii. Ei ofer a organizat iei competent a lor si au interesul ca n schimb s a obt in a condit ii de lucru si un salariu c at mai bune. Este obligat ia patronilor si managerilor organizat iei s a selecteze angajat ii si s a gaseasc a metodele cele mai potrivite de motivare a acestora, deoarece angajatul va cu adevarat un partener doar at at timp c at constat a c a bunul mers al organizat iei se reect a direct n satisfacerea propriilor necesit a ti. Manager (manager) - reprezint a o categorie special a de angajat i, direct responsabil a de implementarea calit a tii n organizat ie. Pe de o parte ei sunt factori de decizie la nivel tactic sau strategic, pe de alt a parte, ca angajat i, sunt obligat i s a se supun a ordinelor patronatului. Acest dublu statut poate crea presiuni deosebite care s a conduc a la degradarea climatului n organizat ie si chiar la dereglarea activit a tii acesteia. Furnizori (providers) - intr a tn categoria partenerilor att timp ct fac eforturi s a ment in a un nivel calitativ corespunz ator al produselor/serviciilor furnizate organizat iei. O organizat ie care vrea s a implementeze calitatea n activitatea sa va trebui s a stie s a selecteze furnizorii si s a ment in a o atmosfer a de parteneriat din care ambii parteneri au de c a stigat. Schimbarea frecvent a a furnizorilor, selectarea acestora doar pe criterii de pret sau n funct ie de interesele personale ale factorilor de decizie, nu pot avea dec at consecint e negative asupra calit a tii produselor/serviciilor. Investitori (investors) - tot i cei care particip a din punct de vedere nanciar la bunul mers al organizat iei (patronat, act ionari, bancheri). Ei obt in o mare parte a protului.
54
Figura 2.6: Beneciari interni. Nu exist a negocieri ntre beneciarii interni, ecare ncearc a s a acapareze resursele pentru a se evident ia. Apar disfunct ionalit a ti la nivel global.
Figura 2.7: Beneciari interni. Exist a negocieri ntre beneciarii interni dar ecare lucreaz a cum a nt eles el cerint ele beneciarului extern.
Figura 2.8: Beneciari interni. Activitatea beneciarilor interni este sincronizat a la nivel global prin comparare cu cerint ele beneciarului extern
2.4
Principiile managementului calit a tii
Indiferent de modul n care este denit a sau perceput a, calitatea produselor/ serviciilor oferite de o organizat ie nu este un dat natural, nt ampl ator, ci
II 2.4. PRINCIPIILE MANAGEMENTULUI CALITAT
55
este rezultatul unei activit a ti con stiente a oamenilor din acea organizat ie. Aceasta nseamn a c a, asemenea oric arei alte activit a ti, calitatea trebuie gestionat a pentru a putea deveni o tr as a tur a predictibil a, continu a si perfectibil a a organizat iei. Standardul ISO 9000 dene ste managementul calit a tii ca ind activit a tile dirijate spre conducerea si controlul organizat iei n domeniul calit a tii [75]. Au fost puse n evident a patru activi a ti fundamentale ale managementului calit a tii si anume: planicarea calit a tii (quality planning); controlul calit a tii (quality control); mbun at a tirea calit a tii (quality improvement); asigurarea calit a tii (quality assurance). Primele trei activit a ti sunt cunoscute n literatura de specialitate ca trilogia lui Juran (Juran Trilogy). Asigurarea calit a tii, de si nu a fost specicat a n clar de Juran, a fost abordat a ntr-una dintre lucr arile sale. Prezentarea detaliat a a cestor activit a ti apare n Capitolul 2 al prezentei lucr ari. In orice domeniu exist a reguli/norme (rules) si principii (principles). Regulile sunt indicat ii precise sau restrict ii privind desf a surarea unor activit a ti sau realizarea unui produs. Ele sunt n general foarte detaliate, fiind orientate pe un domeniu ngust, specice unui anumit produs sau serviciu. De exemplu normele privind desf a surarea antrenamentului pentru o echip a de handbal s-ar putea s a aib a foarte put ine lucruri n comun cu normele pentru antrenarea unei echipe de tenis de mas a. Normele se modic a relativ des datorit a unor modic ari n tehnologie, n legislat ie ori schimbarea formei de proprietate si/sau a obiectivelor organizat iei. Principiile reprezint a totalitatea legilor si not iunilor de baz a, date si nu deduse, ale unei stiint e [64]. Principiile au un caracter mult mai general dec at regulile iar respectarea lor este recomandat a, nu obligatorie. Ele se bazeaz a pe o experient a de lung a durat a ntr-un anumit domeniu, f ar a s a intre n detalii. Principiile pot s a dureze foarte mult (unele principii morale, etice au chiar mii de ani), ind uneori incluse in standarde. Utilizarea principiilor n locul normelor n studiul
56
unui nou domeniu este recomandat a pentru a nt elege fundamentele domeniului care ne interizeaz a. Redactarea normelor ntr-un domeniu trebuie s a se bazeze pe un set coerent de principii. Principiile pot comune unui num ar mare de norme. Relu and exemplul normelor privind desf a surarea antrenamentului pentru o echip a de handbal si a normelor pentru antrenarea unei echipe de tenis de mas a, sigur vom reg asi n ambele principiul doz arii efortului pe durata antrenamentului ( nc alzire, antrenament propriuzis, relaxare). Acesta este un principiu general, care poate reg asit n diverse variante n toate regulamentele privind desf a surarea unor activit a ti de nv a tare. Standardul ISO 9000 pune n evident a 8 principii ale managementului calit a tii (Figura 2.9).
Figura 2.9: Cele 8 principii ale managementului calit a tii denite de standardul ISO 9000.
Principiul 1: Organizat iile depind de client ii lor si, prin urmare, ar trebui s a nt eleag a nevoile actuale si viitoare ale client ilor, s a ndeplineasc a cerint ele clientului si chiar s a se str aduiasc a s a dep a seasc a a stept arile acestuia. Acest principiu corespunde lozincii ap arut a n Rom ania anilor 60, clientul nostru, st ap anul nostru. Principiul nu a fost ales nt ampl ator s a e prezentat primul. Acest lucru are ca obiectiv s a scoat a n evident a important a deosebit a a client ilor pentru orice intreprindere, indiferent ce ofer a aceasta.
57
Problema este s a e denit clientul n toate situat iile posibile. Este evident c a orice cump ar ator este un client. Pentru organizat iile non-prot ns a este necesar a o alt a viziune asupra clientului. Cel mai general putem deni clientul ca ind orice persoan a sau organizat ie care beneciaz a de produse sau servicii de la organizat ia avut a n vedere [46]. Pe baza acestei denit ii au client i IBM, Intel ori Microsoft dar si frizeriile, azilurile, Maa sau Al Qaeda. A considera c a singurul lucru care trebuie s a intereseze o organizat ie este cre sterea protului poate avea consecint e extrem de nefaste asupra organizat iilor, deoarece neglijarea client ilor poate duce n nal la piederea acestora, deci diminuarea protului. O situat ie special a o reprezint a organizat iile de nv a t am ant si s an atate a c aror rentabilizare are n vedere doar aspectele nanciare si se bazeaz a de cele mai multe ori pe neglijarea necesit a tilor si dorint elor celui mai important client, colectivitatea n care acestea si desf a soar a activitatea. Desigur, orice organizat ie are nevoie de resurse nanciare pentru a putea funct iona dar protul poate s a nsemne nu numai venituri b ane sti directe ci si indirecte cum ar cre sterea prestigiului organizat iei, care conduce la obt inerea de noi sponsoriz ari, contracte de cercetare etc. Pentru ca principiul s a nu r am n a o simpl a lozinc a, este necesar ca organizat ia care realizeaz a produsul sau serviciul s a asigure: Punerea n evident a a diverselor categorii de client i. Int elegerea nevoilor si a stept arilor acestor categorii de client i. Garant ia c a obiectivele organizat iei sunt legate de nevoile si a stept arile clientului . Comunicarea nevoilor si a stept arilor client ilor n ntreaga organizat ie. M asurarea satisfact iei client ilor si adaptarea act iunilor n funct ie de rezultatele obt inute. Analiza cauzelor care afecteaz a nivelul de satisfact ie si folosirea rezultatului analizei pentru nbun at a tirea activit a tii organizat iei. Gestionarea sistematic a a relat iilor cu client ii. Garant ia unei abord ari echilibrate ntre satisfacerea client ilor si a altor p art i interesate (cum ar proprietari, angajat i, furnizori, nant atori, comunit a ti locale si societatea n ansamblu). Principalele avantaje ale utiliz arii acestui principiu sunt:
58
II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT Cre sterea veniturilor si a cotei de piat a obt inute prin r aspunsuri exibile si rapide la oportunit a tile piet ei. Cre sterea ecient ei utiliz arii resurselor organizat iei pentru a spori satisfact ia clientului, nu doar ambit iile patronilor. Int arirea loialit a tii client ilor, care vor prefera s a fac a n continuare afaceri cu o rm a care le-a satisf acut anterior ncrederea. Cre sterea prestigiului organizat iei, care poate s a atrag a noi client i sau sprijinitori.
Exacerbarea aplic arii acestui principiu poate conduce la anumite dezechilibre, de exemplu nemult umirea angajat ilor obligat i la eforturi pe care le consider a prea mari, renunt area la anumit i client i pentru a se concentra pe satisfacerea dorint elor/necesit a tilor unui client considerat prioritar etc. Principiul 2: Liderii stabilesc unitatea de scop si conducerea organizat iei. Ei ar trebui s a creeze si s a ment in a mediul intern n care oamenii pot deveni pe deplin implicat i n realizarea obiectivelor organizat iei Termenul lider este folosit pentru a desemna o persoan a cu dreptul de a lua decezii la diverse nivele ntr-o organizat ie. Liderii trebuie s a e modele pentru echipa pe care o conduc, at at n ceea ce prive ste rezolvarea problemelor curente ale sectorului de care r aspund c at si n atitudinea lor fat a de problemele organizat iei, n modul cum colaboreaz a cu celelalte sectoare, n atitudinea fat a de client i si furnizori. Un lider trebuie s a nt eleag a c a de atitudinea lui depinde nu numai buna funct ionare a sectorului condus ci a ntregii organizat ii. In afara ndatoririlor profesionale specice, el trebuie s a creeze atmosfera de lucru necesar a mobiliz arii ntregii echipe pentru realizarea obiectivelor organizat iei. Pentru aceasta, este necesar ca liderul s a cunosc a nu numai potent ialul profesional dar si prolul psihologic si chiar problemele personale ale ale ec arui om din subordine. El va evita implicarea n probleme nesemnicative doar pentru a ar ata c at de mult munce ste, aloc and timp pentru rezolvarea sarcinilor specice de comand a si control. Cu alte cuvinte, liderul trebuie s a e un conduc ator ale c arui ordine si init iative sunt privite cu ncredere de ntregul colectiv si nu doar un sef care execut a orbe ste ordinele venite de la nivelele ierarhice superioare. Printre sarcinile de baz a ale oric arui lider se reg asesc:
59
G asirea celor mai potrivite forme de motivare a oamenilor pentru atingerea obiectivelor organizat iei. Evaluarea activit a tii oamenilor pe baza unor criterii obiective si unitare. Orientarea oamenilor pentru cre sterea continu a a nivelului lor profesional. Gestiunea responsabil a a tuturor resurselor sectorului condus. Depistarea de noi oportunit a ti pentru cre sterea potent ialului sectorului condus. Minimizarea problemelor de comunicare ntre nivelele de structur a ale organizat iei. P astrarea unui climat de cooperare n relat iile cu client ii si furnizorii. Aplicarea acestui principiu de conducere duce de obicei la: Luarea n considerare a nevoile tuturor p art ilor interesate (clienti, proprietari, angajati, furnizori, nant atori, comunit a ti locale si societatea n ansamblu). Instaurarea unui mod de g andire pozitiv n rezolvarea problemelor organizat iei prin eliminarea abord arilor de tipul asta nu se poate/asta e prea greu/dar eu cu ce m a aleg din asta/de ce s a fac eu si nu colegul. Stabilirea unei viziuni clare asupra viitorului organizat iei. Stabilirea unor obiective provocatoare dar rat ionale. Implementarea strategiilor pentru atingerea obiectivelor stabilite. Crearea si sust inerea unor valori comune tuturor nivelurilor organizat iei. Stabilirea ncrederii si eliminarea fricii. Atragerea de oameni cu resursele necesare, av and si libertatea de a act iona cu responsabilitate. Incurajarea si recunoa sterea contribut iilor oamenilor.
60
Principiul 3: Oamenii, la toate nivelurile, sunt esent a unei organizat ii si implicarea lor total a permite folosirea abilit a tilor lor n beneciul organizat iei. Acest principiu precizeaz a c a oamenii sunt principala bog a tie a unei organi-zat ii. R am ane ca liderii organizat iei s a valorice acest a bog a tie. Pentru aceasta este necesar s a se nt eleag a faptul c a un om nu poate redus doar la cuno stint ele lui profesionale. Fiecare om din organizat ie are propria lui experient a de viat a, intuit ie, voint a, caracteristici psihice si zice, capacitate managerial a, cuno stint e n afara competent elor pentru care a fost angajat. Valoricarea tuturor acestor propriet a ti poate s a adauge valoare activit a tii organizat iei. Atingerea obiectivelor organizat iei se poate realiza numai prin implicarea tuturor membrilor organizat iei, de la portar la director general. Orice verig a slab a va duce inevitabil la dereglarea activit a tii intregului sistem. Evident, implicarea oamenilor in realizarea obiectivelor trebuie s a e benevol a si con stient a. O implicare obt inut a doar prin manipulare si amenint ari poate s a rezolve pe moment anumite probleme dar pe termen lung va avea n mod sigur efecte devastatoare (vor pleca mult i angajat i de valoare, vor g asit i din ce n ce mai put ini amatori s a se angajeze, scade interesul angajat ilor pentru bunul mers al organizat iei, se poate instala un sistem de corupt ie an a la nivelele de baz a, dispare interesul pentru introducerea unor elemente noi, etc.) Desigur, ata samentul fat a de organizat ie nu este un dat natural, nu se c a stig a doar prin stimulente materiale, distinct ii sau promov ari acordate f ar a nici un fel de criteriu sau pe baza unor criterii subiective si mereu modicate. Este rolul liderilor s a-l fac a pe ecare angajat din subordine s a nt eleag a important a implic arii sale n atingerea obiectivelor organizat iei si s a g aseasc a mijloacele de motivare cele mai eciente pentru aceast a mplicare. Una dintre gre selile tipice ale liderilor const a in luarea deciziilor f ar a implicarea subordonat ilor. Aceasta conduce uneori la xarea unor obiective si strategii de atingere a acestora nerealiste sau contradictorii, care nu tin cont de potent ialul uman disponibil. Mai mult, subordonat ii vor avea senzat ia c a eforturile care li se cer sunt absurde, f ar a nicio perspectiv a si pe fat a sau mascat vor se vor opune ordinelor primite, ceea ce conduce la crearea unei atmosfere conictuale, mi sc ari revendicative, del asare n realizarea obiectivelor si n nal la compromiterea organizat iei. O organizat ie poate s a sust in a c a aplic a cest principiu numai dac a Toate persoanele din cadrul organizat iei sunt motivate si implicate direct n stabilirea si implementarea obiectivelor si strategiilor/tacticilor
II 2.4. PRINCIPIILE MANAGEMENTULUI CALITAT de realizare a acestora.
61
Toate persoanele din cadrul organizat iei dau dovad a de inovare si creativitate conform competent elor lor, n promovarea obiectivelor organizat iei. Oamenii stiu c a au o r aspundere pentru performant a lor. Oamenii sunt dornici s a participe si s a contribuie la mbun at a tirea continu a a activit a tii, con stient i c a prin aceasta sunt rezolvate si necesit a tile/dorint ele personale. Aplicarea principiului implic arii oamenilor trebuie s a conduc a la: Int elegerea de c atre tot i oamenii organizat iei a important ei contribut iei si rolului ec aruia n organizat ie. Identicarea de c atre oameni a constr ngerilor impuse la nivelul performant ele lor. Oamenii discut a deschis problemele organizat iei. Oamenii si asum a problemele organizat iei si responsabilitatea pentru rezolvarea acestora. Oamenii accept a faptul c a este necesar s a fac a evaluarea performant ei lor at at n raport cu scopurile si obiectivele lor personale c at si cu cele ale organizat iei. Oamenii caut a n mod activ oportunit a ti de a spori nivelul lor de competent a, cuno stint e si experient a pentru c a n felul acesta ponderea lor n luarea deciziilor si rezolvarea problemelor organizat iei va cre ste si n folosul lor. Oamenii accept a liber schimbul de cuno stint e si experient a. Va cre ste m andria de a face parte dintr-un anumit colectiv si loialitatea fat a de acesta. Trebuie nt eles c a atitudinea pozitiv a a oamenilor fat a de organizat ia n care desf a soar a o mare parte a activit a tii lor nu este o caracteristic a n ascut a ci se formeaz a ca o tr as atur a de caracter ntr-un timp relativ ndelungat si ntr-un mediu corespunz ator. Intotdeauna vor exista oameni care nu se pot adapta normelor de activitate si conduit a impuse n cadrul organizat iei, oameni pentru care interesul personal este mai presus de orice sau pentru care
62
cuvintele de ordine sunt las a c a merge si a sa sau nu o s a se nt ample tocmai acum si tocmai mie. Este obligat ia leaderilor (principiul 2) s a depisteze aceste cazuri si s a le reduc a/elimine inuent a n organizat ie. Principiul 4: Atingerea rezultatului dorit este realizat a mai ecient atunci c and activit a tile si resursele necesare sunt gestionate ca un proces. Sect iunea 3.4.1 din ISO 9000:2000 [76] dene ste procesul (process)ca ind un set de activit a ti interdependente sau care interact ioneaz a pentru a transforma intr arile n ie siri. Schematic procesul poate reprezentat ca n diagrama din Figura 2.10. Intr arile reprezint a resursele (materiale, nanciare, energetice, informat ionale
Figura 2.10: Procesul denit de standardul ISO 9000:2000. si umane) necesare desf a sur arii procesului. Ie sirile reprezint a rezultatele obt inute n urma naliz arii procesului (produse, servicii, documente).
63
Procedura (procedure) reprezint a specicarea modului de desf a surare a unei activit a ti sau proces (ISO 9000:2000 sect iunea 3.4.5) [77]. M asurile (measures) reprezint a caracteristicile pe baza c arora se m asoar a performant a/randamentul unui proces. Aceste caracteristici trebuie controlate pentru a stabili dac a un obiectiv a fost realizat. Monitorizarea presupune o vericare sistematic a, realizat a periodic. Standardul subliniaz a important a identic arii, implement arii, gestion arii si cre sterii continue a ecient ei proceselor precum si a gestiunii interact iunii dintre procese n scopul atingerii obiectivelor organizat iei. Introducerea acestui principiu are ca scop: Realizarea obiectivelor cu costuri mai mici si mai repede prin folosirea ecient a a resurselor. Garantarea unor rezultate mai bune, consistente si previzibile. Orientarea activit a tii pe posibilit a tile reale ale organizat iei de mbun at a tirea proceselor prioritare. Pentru a putea sust ine c a o organizat ie aplic a efectiv acest principiu este necesar s a demonstreze c a: Are clar denite obiectivele pe care trebuie s a le ating a. Sunt denite sistematic activit a tile necesare pentru a obt ine un rezultat dorit. Au fost puse n evident a activit a tile critice n atingerea obiectivelor. Sunt riguros denite responsabilit a tile si r aspunderile pentru administrarea activit a tilor cheie. Sunt denite m asurile pentru determinarea succesului, adic a acele m asuri a c aror realizare dene ste obt inerea rezultatului dorit. Sunt identicate m asurile pentru intr arile n ecare proces si pentru rezultate. Se acord a o atent ie deosebit a resurselor, materialelor si metodelor care pot conduce la mbun at a tirea activit a tilor prioritare a le organizat iei.
64
II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT A fost realizat a evaluarea riscurilor, consecint elor si impactului activit a tilor asupra client ilor, furnizorilor si altor p art i interesate (stakeholders).
Nu trebuie ns a s a credem c a simpla abordare pe baza proceselor a managementului organizat iei rezolv a automat toate problemele. Rezultatul unui proces poate un e sec dac a procesul nu este corect denit si gestionat, dac a se accept a intr ari cu valori necorespunz atoare ale parametrilor sau nu exist a criterii si metode corespunz atoare de evaluare a rezultatelor. Principiul 5: Identicarea, nt elegerea si gestionarea proceselor interconectate ca sistem contribuie la cre sterea ecacit a tii (eectiveness) organizat iei si a randamentului n realizarea obiectivelor sale. Sistemul (system) este o reuniune ordonat a de idei, principii, teorii sau operat ii care produc un rezultat bine precizat [46]. Ecacitatea sistemului (system eectiveness) este dat a de capacitatea sistemului de a realiza scopul declarat si obiectivele stabilite [46]. Pentru ca dou a procese s a interact ioneze ele trebuie s a contribue la realizarea aceluia si produs/serviciu sau s a utilizeze acelea si resurse. In cazul n care procesele contribuie la realizarea unui anumit rezultat, ele se pot desf a sura paralel sau serie (unul dup a altul). Accesul la o resurs a comun a poate conduce la pierdere de timp datorit a bloc arilor, ceea ce impune tehnici speciale de gestiune a concurent ei. De exemplu, faptul c a n acela si laborator trebuie s a se desf a soare activit a tile mai multor format ii de lucru de la sectii diferite, va conduce inevitabil la complicarea realiz arii orarelor. Dac a orarul ec arei sect ii va realizat f ar aa tine cont de celelalte sect ii, probabilitatea unui conict de interese va foarte mare. Dac a ns a activitatea de realizare a orarului va abordat a sistemic, va exista o coordonare ntre diversele sect ii si aparit ia conictelor va putea rezolvat a mult mai simplu si mai repede. Trebuie s a tinem cont c a sistemul are o structur a si funct ionare dinamice. Aceasta nseamn a c a o strategie adoptat a la un anumit moment si care se dovede ste foarte util a, poate deveni contraproductiv a sau chiar neaplicabil a peste un anumit timp. Astfel, orarul realizat pentru o sect ie ntr-un an academic va aproape imposibil de realizat chiar anul urm ator datorit a modic arii num arului format iilor de lucru, a normelor titularilor, a titularilor unor discipline. O singur a modicare poate atrage necesitatea realiz arii unui lant de modic ari care n nal vor schimba complet congurat ia orarului.
II 2.4. PRINCIPIILE MANAGEMENTULUI CALITAT Abordarea sistemic a a proceselor asigur a:
65
Integrarea si alinierea proceselor care vor obt ine cele mai bune rezultate dorite. Posibilitatea de a concentra eforturile asupra proceselor cheie. Cre sterea ncrederii p art ilor interesate n ceea ce prive ste coerent a, ecacitatea si randamentului organizat iei. Aplicarea principiului abord arii sistemice duce n nal la: Int elegerea interdependent elor ntre procesele de sistem. Structurarea unui sistem pentru atingerea obiectivelor organizat iei n modul cel mai ecient si ecace. structurat a abord ari care armonizarea si integrarea proceselor. Asigurarea unei mai bune nt elegeri a rolurilor si responsabilit a tilor necesare pentru atingerea obiectivelor comune si reduc nd astfel barierele eco-funct ionale. Int elegerea capacit a tilor organizatorice si de rezolvare a constr ngerilor legate de resurse nainte de act iune. Imbun at a tirea continu a a sistemului prin m asurare si evaluare. Pentru a obt ine avantaje certe, principiiile 4 si 5 trebuie aplicate mpreun a. Astfel, analiz and activitatea dintr-o cur a t atorie din punct de vedere funct ional pot puse n evident a procesul de cur a tire, procesul de dezinfectare si procesul de vopsire. Analiz and cele trei procese ca pe un singur sistem, se poate observa c a procesele de cur a tire si dezinfectare pot reunite ntrun singur proces de cur a tire dezinfectare deoarece cele dou a procese cont in multe elemente si resurse comune. Principiul 6: Imbun at a tirea periodic a (continual) a performant ei globale a organizat iei trebuie s a e un obiectiv permanent al organizat iei. In formularea original a a principiului n cadrul standardului, apare cuv antul englez continual care se traduce prin repetat, periodic, necontenit. In literatura legat a de acest subiect apare ns a din ce n ce mai des termenul continuous cu semnicat ia continuu, permanent. Este evident c a alegerea termenului continual nu a fost nt ampl atoare, deoarece
66
o mbun at a tire continu a ar nerealist a, conduc and la blocarea unor importante resurse nanciare si n special umane. Nici un patron nu va accepta achizit ia unor echipamente noi at at timp c at nu a obt inut protul scontat de pe urma vechiului echipament chiar dac a nu este cea mai performant a tehnologie. Un exemplu foarte cunoscut este p astrarea programelor Oce 2000 n multe organizat ii de si ntre timp au ap arut multe alte variante. Ideea de actualizare, de eliminare a surselor de eroare, de cre stere a nivelului de preg atire a oamenilor, trebuie s a aib a un caracter continuu. Implementarea ideii se va face ns a n momente de timp bine determinate, pe baza unor studii de impact. Modic arile pot orientate pe produs, proces, tehnologie, angajat i. Unele modic ari sunt realizate pe baza unor planuri de modernizare, altele sunt impuse de necesitatea alinierii la noi standarde, de modicarea legislat iei sau modicarea contextului n care si desf a soar a activitatea organizat ia. Chiar dac a mbun at a tirile se realizeaz a la intervale mari de timp, preg atirea lor poate presupune un efort sust inut pe o durat a destul de mare. Astfel, introducerea unui nou software poate implica scolarizarea/antrenarea utilizatorilor chiar cu un an nainte. Trebuie avut n vedere c a orice element nou introdus poate provoca perturb ari serioase dac a asimilarea sa nu a fost preg atit a din timp si cu grij a mai ales la nivel uman. De exemplu, chiar trecerea de la Oce 2000 la Oce 2007 a provocat probleme de adaptare a utilizatorilor si de compatibilitate (nu tot i beneciarii sau furnizorii au trecut la noile variante, astfel nc at si la ora actual a se lucreaz a practic cu formatele .doc, .ppt, .xls). Acest exemplu ar putea s a scoat a n evident a si faptul c a facilit a tile oferite de noile variante nu intereseaz a mare parte dintre beneciari iar necesitatea de adaptare la noile interfet e a t aiat complet pofta migr arii de la o variant a la alta. Principalele benecii ale implement arii acestui principiu sunt: Imbun at a tirea capacit a tii organizatorice a organizat iei. Alinierea activit a tilor de mbun at a tire de la toate nivelurile pentru atingerea obiectivelor strategice ale organizat iei. Cre sterea capacit a tii de react ie rapid a la oportunit a tile care apar n mediul economic, social si politic. Aplicarea principiului de mbun at a tire continu a implic a: Abordarea consistent a, la nivelul ntregii organizat ii, a mbun at a tirii performant elor organizat iei. Aceasta nseamn a echilibrarea eforturilor
67
si consumului de resurse astfel nc at mbun at a tirea unor caracteristici s a nu conduc a la blocarea sau chiar nr aut a tirea valorii altor caracteristici atate cel put in la acela si nivel de prioritate. Inarmarea oamenilor cu metodele si instrumentele specice mbun at a tirii periodice a performant elor. Transformarea mbun at a tirii periodice a produselor, proceselor si sistemelor ntr-un obiectiv pentru ecare membru al organizat iei. Stabilirea obiectivelor pentru a ghida si a m asurilor pentru a urm ari mbun at a tirea periodic a. Recunoa sterea si recompensarea contribut iei ec aruia la mbun at a tirea performant elor. Imbun at a tirea periodic a a activit a tii doar la nivelul unui sector, proces, produs poate s a aib a efecte negative n timp prin dezechilibrul resurselor, crearea uno sentimente de frustrare n alte sectoare, ngustarea ofertei pentru beneciari etc. Din aceast a cauz a stndardul ISO 9000 subliniaz a c a mbun at a tirea se refer a la performant a global a. Desigur, aceasta poate n anumite situat ii s a implice renunt area la anumite produse, reorganizarea sectoarelor, concedieri. In astfel de situat ii este necesar a obt inerea sust inerii tuturor oamenilor din organizat ie (principiul 3). Imbun at a tirea performant elor nu are nici un sens dac a pe termen mediu si lung ea nu se va reecta n mbun at a tirea statutului membrilor organizat iei, a condit iilor lor de lucru, in cre sterea nivelului de trai si a oportunit a tilor de ridicare a nivelului profesional. In cazul n care beneciile se vor reecta doar n cazul unor privilegiat i, activit a tile legate de mbun at a tire apar pentru ceilalct i doar ca o corvoad a sau chiar o amenint are la securitatea locului de munc a. Aceast apercept ie poate avea consecint e dezastroase la nivelul organizat iei pe termen mediu si lung. Principiul 7: Deciziile sunt eciente numai dac a se bazeaz a pe analiza datelor si informat iilor reale Una dintre cele mai cunoscute denit ii ale informat iei precizeaz a c a aceasta reprezint a incertitudinea nl aturat a privind realizarea unui eveniment dintr-un set de evenimente potent ial realizabile. Prin dat a nt elegem fapte, evenimente, tranzact ii nregistrate pe un suport zic oarecare. Datele reprezint a informat ii rupte din context. Aceasta nseamn a c a aceea si
68
dat a poate furniza informat ii diferite n funct ie de cine face interpretarea, de obiectivele interpret arii, de nivelul cuno stint elor n domeniu. Datele care intereseaz a organizat ia sunt culese direct din realitatea nconjur atoare (mediul informat ional brut). Informat iile sunt generate n urma prelucr arii informat iilor. Prin aceast a transformare, datelor li se adaug a valoare. Lant ul complet de valoricare a datelor este prezentat n Figura 2.11. Se observ a c a ultimul nivel, cu valoarea cea mai mare, l reprezint a luarea deciziilor, materializate n nal prin act iuni. Aplicarea acestui principiu are urm atoarele obiective: Luarea unor decizii bazate pe cunoa sterea si nt elegerea realit a tii. Cre sterea capacit a tii de a demonstra ecient a deciziilor anterioare, prin trimitere la evident a faptelor. Luarea unor noi decizii numai dup a analiza rezultatelor bazate pe deciziile anterioare. Cre sterea capacit a tii de a revizui, contesta si schimba opiniile si deciziile. Implementarea principiului de abordare bazat a pe fapte a procesului decizional este posibil a dac a: Exist a sigurant a c a datele si informat iile sunt sucient de precise si abile. Datele sunt furnizate n timp util celor care au nevoie de ele. Analiza datelor si informat iilor se realizeaz a folosind numai metode valide. Luarea deciziilor si implementarea act iunilor aferente, bazate pe analiza unor fapte curente, este echilibrat a de experient a si intuit ia celor care iau deciziile. Principiul 8: O organizat ie si furnizorii s ai interact ioneaz a permanent, si o relat ie reciproc avantajoas a spore ste capacitatea de a crea valoare pentru ambele p art i. Avantajele implement arii acestui principiu ntr-o organizat ie sunt:
69
Figura 2.11: Lant ul de valoricare a datelor.
Cre sterea capacit a tii de a crea valoare pentru ambele p art i. Flexibilizarea si cre sterea vitezei de r aspuns la schimb arile piet ei sau/ si
70
II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT a stept arile client ilor. Optimizarea costurilor si a disponibilit a tii resurselor. Posibilitatea identic arii si select arii furnizorilor cheie.
Se poate spune c a principiul relat iei reciproc avantajoase cu furnizorul se bazeaz a pe: Stabilirea relat iilor care asigur a c a stiguri echilibrate ntre avantajele pe termen scurt si interesele pe termen lung. Punerea n comun a expertizei si a resurselor cu partenerii. O comunicare clar a si deschis a. Schimbul de informat ii si planuri de viitor. Stabilirea si dezvoltarea comun a a activit a tilor de mbun at a tire. Inspirarea, ncurajarea si recunoa sterea mbun at a tirilor realizate de c atre furnizori. Observat ie! Se observ a c a niciununul dintre cele 8 principii ale managementului calit a tii nu cont ine n enunt cuv antul calitate. De si la prima vedere aceasta pare ciudat, de fapt este normal, pentru c a a gestiona calitatea ntr-o organizat ie nseamn a doar s a-i nvet i pe oameni c a orice lucru trebuie f acut corect din primul moment si p an a la ncheierea activit a tii, c a orice abatere de la norme sau disciplin a poate duce la compromiterea unui produs/serviciu si n nal la compromiterea imaginii/obiectivelor organizat iei deci si a propriilor interese.
Capitolul 3
Procese de baz a ale managementului calit a tii

3.1 Activit a tile prin care se asigur a calitatea produselor/serviciilor
Dup a cum s-a ar atat si n capitolul precedent, realizarea managementului calit a tii este posibil a cu ajutorul a patru tipuri de activit a ti si anume: planicarea calit a tii (quality planning); controlul calit a tii (quality control); mbun at a tirea calit a tii (quality improvement); asigurarea calit a tii (quality assurance). De si ecare dintre aceste activit a ti are propriile obiective si metode de rezolvare a acestora, ntre ele exist a o str ans a interdependent a care uneori n practic a duce la suprapunerea unor activit a ti, la redundant a documentelor si crearea impresiei unei activit a ti preponderent birocratice, lipsite de important a. In cadrul acestui capitol vor puse n evident a principalele caracteristici ale celor patru componenete precum si leg aturile dintre acestea.
3.2
Planicarea calit a tii
Standardul ISO 9000 dene ste planicarea calit a tii ca ind acea component a a managementului calit a tii care stabile ste obiectivele calit a tii si precizeaz a 71
ALE MANAGEMENTULUI CALITAT II 72CAPITOLUL 3. PROCESE DE BAZA resursele si procesele necesare pentru realizarea acestor obiective. Exist a dou a nivele de planicare: planicarea strategic a; planicarea operat ional a. Pentru a nt elege diferent a dintre cele dou a nivele vom considera cazul nint arii unei noi facult a ti. Planicarea strategic a se realizeaz a la nivel de Rectorat/Senat universitar. Aici se decid: prolul noii facult a ti; numele facult a tii; formele de scolarizare; cifra de scolarizare; buget disponibil; sediul; colectivul care va gestiona nint area facult a tii. Planicarea operat ional a va realizat a de un colectiv de speciali sti si se va referi la: specializ ari; planuri de nv a ta m ant; necesarul de cadre didactice; organizarea concursurilor pentru angajare; necesarul de spat ii pentru desf a surarea activit a tilor didactice (cursuri, seminarii, lucr ari practice); necesarul de spat ii pentru desf a surarea activit a tilor de cercetare (laboratoare, ateliere); structura organizatoric a a facult a tii; colaborarea cu alte facult a ti;
II 3.2. PLANIFICAREA CALITAT
73
necesarul de c art i si publicat ii de specialitate din dotarea bibliotecii centrale (existente si care trebuie achizit ionate) minimul necesar de dotare a laboratoarelor si atelierelor pentru demararea a activit a tii. necesarul de spat ii pentru birouri, secretariate, depozite etc. Analiz and acest exemplu se observ a c a nic aeri nu apare conceptul de cal itate. Acesta nu apaere n clar pentru cde fapt Planul strategic/operat ional si Planul strategic/operat ional al calit a tii sunt practic acela si lucru prezentat cu diverse denumiri. Practic este imposibil s a realizezi un management global corect f ar a criterii de calitate bine precizate la ecare act iune. Fiecare punct din Planul strategic/operat ional din exemplul analizat se bazeaz a pe criterii de calitate formulate n clar n cadrul diverselor legi, hot ar ari de guvern si normative sau bazate pe cutumele/experient a centrului universitar. Toate hot ar arile luate trebuie s a aib a n vedere satisfacerea diverselor categorii de purt atori de interese. De exemplu, stabilirea prolului noii facult a ti trebuie s a tin a cont cel put in de: potent ialul economic al zonei; necesarul de noi speciali sti (pe baza unor solicit ari ferme cu o perspectiv a de cel put in 5 ani); posibilitatea de atragere a student ilor din zona de acoperire (presupunem c a anterior a fost realizat a o analiz a a cererii pe piat a muncii si a opt iunilor viitorilor absolvent i de liceu); existent a altor facult a ti de prol accesibile n tar a sau str ain atate; posibilit a tile de a asigura un corp profesoral de nivel corespunz ator cu cheltuieli de instalare c at mai mici; criterii de atragere a unor speciali sti de valoare nc a de la nint are; etapele de dezvoltare ale facult a tii, cu obiective concrete realiste; acoperirea cuno stint elor specice prin specializ ari ale altor facult a ti din cadrul centrului; existent a unor organizat ii n care student ii vor putea s a si des av ar seasc a abilit a tile practice; nivelul de atractivitate al noii facult a ti;
ALE MANAGEMENTULUI CALITAT II 74CAPITOLUL 3. PROCESE DE BAZA cum va afecta noua facultate activitatea facult a tilor deja existente; necesitatea desint arii unor specializ ari; oportunitatea modic arii prolului altei facult a ti astfel nc at aceasta s adevin a nucleul noii facult a ti; necesitatea mut arii unor specializ ari la noua facultate; eventuala migrare a unor cadre didactice cu consecint e negative asupra calit a tii procesului de instruire; cheltuielile legate de nint are. Toate aceste elemente trebuie s a e compatibile cu legile si normele n vigoare. In lucrarea [46] este prezentat a o secvent a universal a a activit a tilor de planicare: stabilirea obiectivelor; stabilirea celor asupra c arora aceste obiective au impact; determinarea necesit a tilor reale n raport cu aceste obiective si priorit a tile; dezvoltarea de produse/servicii cu caracteristici ce corespund cerint elor puse n evident a ; dezvoltarea proceselor capabile s a produc a, promoveze si distribuie produsele/serviciile cu cracteristicile cerute; stabilirea proceselor de control si transferul planului c atre nivelele operative. Exist a mai multe rezultate ale activit a tii de planicare, cum ar : Planurile de afaceri (Business Plans); Planuri pentru dezvoltarea produselor noi; Planurile de dezvoltare a proceselor; Descrieri detaliate ale caracteristicilor ce trebuie asigurate produselor/serviciilor; Descrierea detaliat a a tuturor activit a tilor aferente unui proces, a resurselor implicate si a metodelor de control necesare implement arii standardului de calitate acceptat.
II 3.3. CONTROLUL CALITAT
75
3.3
3.3.1
Controlul calit a tii

Prezentare general a
Conform standardului ISO 9000, emphcontrolul calit a tii este o parte a managementului calit a tii concentrat a asupra realiz arii cerint elor. Aceast a denit ie nu scoate n evident a faptul ca activit a tile de control au rolul de regulator a performant elor. In practic a de cele mai multe ori controlul este de multe ori privit ca ceva care impune constr angeri, ngr ade ste libertatea. Dar, n acela si timp controlul este singura modalitate prin care se asigur a un anumit nivel minim de performant a pentru produse/servicii si contribue decisiv la realizarea unor echipamente complexe prin impunerea unor criterii clare de compatibilitate a componentelor. Ne putem u sor imagina ce s-ar nt ampla dac a am cump ara suruburi si piulite realizate cu precizii diferite n funct ie de con stiinciozitatea produc atorilor, de gradul de uzur a al sculelor sau de diverse incidente survenite in procesul de product ie. Astfel de situat ii putem g asi n orice domeniu de activitate. Cea mai simpl a si general a form a a controlului calit a tii este prezentat a n Figura 2.1.
Figura 3.1: Modelul generic al controlului
Se observ a c a cerin ele formulate de diverse categorii de beneciari sunt utilizate n dou a scopuri: generarea diverselor planuri de calitate;
ALE MANAGEMENTULUI CALITAT II 76CAPITOLUL 3. PROCESE DE BAZA vericarea si validarea produselor prin compararea valorii atributelor reale cu valorile solicitate; In cazul n care apar diferent e, se va ncerca n primul r and remedierea defectelor. Dac a se constat a c remedierea este imposibil a sau pret ul de cost este prea mare ind afectat a o parte semnicativ a rexultatelor obt inute, se trece la refacerea planurilor prin modicarea cerint elor impuse resurselor, proceselor sau preg atirii celor care lucreaz a n domeniu. Aceast a structur a general a poate adaptat a de la cazul extrem n care nu exist a nici un control (Figura 2.2) sau exist a doar control al produselor nale (Figura 2.3), p an a la cele mai sosticate metode de planicare, control si corect ie utilizate la ora actual a (Figura 2.4).
Figura 3.2: Modelul procesului de product ie f ar a planicare si f ar a control (produse a c aror calitate este obt inut a oarecum la nt amplare) - specic product iei artizanale de serie mic a.
Figura 3.3: Modelul procesului de product ie f ar a planicare dar cu control al produselor/serviciilor nale (produse cu o calitate stabil a dar percept ia asupra calit a tii nu este foarte clar a) - specic product iei n unele intreprinderi mici si mijlocii sau n servicii
77
Figura 3.4: Modelul procesului de product ie cu punerea n evident a a gener arii specicat iilor, dezvolt arii planurilor si controlul calit a tii produselor(produse cu o calitate stabil a, conform a exigent elor tuturor categoriilor de beneciari) - specic product iei n intreprinderi care au trecut la un nivel superior al managementului calit a tii
ALE MANAGEMENTULUI CALITAT II 78CAPITOLUL 3. PROCESE DE BAZA
3.3.2
Moduri de realizare a controlului
In raport cu procesul de product ie/serviciu, controlul poate realizat n trei momente de timp diferite: n aintea procesului; pe durata procesului; dup a terminarea procesului. Controlul realizat n aintea procesului are ca obiectiv prevenirea aparit iei unor defecte printr-o planicare si proiectare riguroas e. Un exemplu clasic este predict ia abilit a tii n aintea proiect arii. Un alt control tipic este vericarea competent ei celor implicat i n implementarea proiectelor. Important a este si vericarea tot n aceast a faz a a furnizorilor si a materiilor prime oferite de ace stia. Controlul realizat pe durata desf a sur arii procesului are ca scop descoperirea si remedierea unor defecte. Este specic proceselor industriale automate care permit reglarea valorilor unor parametri pe baza unor algoritmi specici de control automat. Controlul nal are ca obiectiv vericarea rezultatului produsului obt inut dupterminarea unui proces pentru a preveni propagarea defectelor c atre etapele superioare ale proces arii.Produsele defecte pot recondit ionate sau sunt eliminate.
3.3.3
Etape generale de realizare a controlului
Conform lui Juran [46] controlul calit a tii presupune realizarea urm atorilor pa si: Determinarea subiectului controlului. Denirea unei unit a ti de m asur a. Stabilirea unui nivel de performant a (standard) pe care dorim s a-l atingem si p astr am. Standardul poate modicat n sensul cre sterii performan elor. Selectarea unui mijloc de m asurare (sensor) a abaterilor fat a de standard. Instalarea sensorului.
79
Colectarea si transmiterea datelor de la sensor la centrul de analiz a. Se veric a rezultatele obt inute si se pun n evident a cazurile n care abaterile ies din limitele permise acceptabile. Se analizeaz a cauzele care au condus la aparit ia dep a sirilor depistate la pasul anterior. Se propun remedii si se iau decizii privind act iunile de eliminare a cauzelor care provoac a anomaliile. Se realizeaz a act iunile acceptate si se veric a dac a efectul corespunde a stept arilor.
3.3.4
Standarde
Conform [82] prin standard se nt elege un mijloc universal sau larg acceptat, convenit sau stabilit pentru a determina ce/cum trebuie s a e ceva. Acest termen se refer a n principal la: Materiale sau substant e ale c aror propriet a ti sunt cunoscute cu o precizie care este sucient a s a permit a utilizarea lor ca o referint a zic a n calibrarea sau m asurarea acelora si propriet a ti ale altui material/substant a. Concept, norm a sau principiu stabilite prin acord, autoritate sau tradit ie si utilizat a in general ca un exemplu sau model pentru a compara/m asura calitatea sau performant a unei activit a ti sau proceduri. O denit ie, limit a sau regul a scris a, aprobat a sau monitorizat a pentru realizare de c atre o agent ie ocial a sau o asociat ie profesional a recunoscut a, ca un criteriu de calitate minim acceptabil (aceasta este semnicat ia general a a termenului folosit n activit a tile practice). In domeniul calculatoarelor exist a standarde pentru limbaje de programare, formate de date, sisteme de operare, protocoale de comunicat ii, interfet e electrice etc. Din punctul de vedere al utilizatorului standardele sunt deosebit de importante n industria tehnicii de calcul deoarece permit reunirea unor componente hardware si software realizate de diver si produc atori pentru a obt ine un sistem de calcul cu performant ele dorite. Dac a nu ar exista standarde, numai componentele produse de aceea si rm a ar putea combinate ceea
ALE MANAGEMENTULUI CALITAT II 80CAPITOLUL 3. PROCESE DE BAZA ce ar crea mari dicult a ti n realizarea unor sisteme dedicate sau personal izate. In plus, standardizarea interfet elor utilizator asigur a o nv a tare mult mai simpl a si rapid a a noilor aplicat ii. Cele mai cunoscute standarde ociale n domeniul tehnicii de calcul sunt elaborate de urm atoarele organizat ii: ANSI (American National Standards Institute) ITU (International Telecommunication Union) IEEE (Institute of Electrical and Electronic Engineers) ISO (International Standards Organization) VESA (Video Electronics Standards Association) Pe l ang a standardele ociale mai exist a foarte multe standarde de facto ap arute n mod natural prin acceptarea lor de c atre principalele rme produc atoare (de exemplu standardul PostScript).
3.4
3.4.1
Imbun at a tirea calit a tii

Standardul ISO 9000 dene ste emph mbun at a tirea calit a tii ca ind acea component a a managementului calit a tii orientat a pe cre sterea capacit a tii de a satisface cerint ele de calitate. De exemplu, un editor de texte poate mbun at a tit prin m arirea num arului de seturi de caractere, prim cre sterea num arului formatelor de editare/salvare, prin ad augarea unor noi facilit a ti de formatare a paginilor si paragrafelor etc. Toate modic arile vor considerate cu adev arat mbun at a tiri n m asura n care satisfac cerint e ale utilizatorilor. Orice sistem/proces este supus unor permanente schimb ari. De exemplu, un program lucreaz a ntr-un context care se modic a permanent: sunt active simultan mereu alte programe; spat iul de memorie variaz a; spat iul adreselor n care este nc arcat codul se modic a;
AT IREA CALITAT II 3.4. IMBUNAT
81
n cazul bazelor de date poate varia foarte mult n timp cantitatea de date prelucrate; cererile utilizatorilor se modic a mereu si apar ntr-o ordine aleatoare. Toate modic arile care apar n procesul de product ie sau pe durata utiliz arii, afecteaz a calitatea produsului/serviciului analizat. Modic arile pot dorite, acceptabile sau inacceptabile. O modicare se consider a mbun at a tire dac a aduce benecii sau este dorit a de utilizator. O mbun at a tire este ntotdeauna relativ a, adic a se m asoar a fat a de nivelul calit a tii la un moment dat. Modicarea este acceptabil a dac a este inevitabil a, nu aduce nici un beneciu dar nici nu provoac a daune sau alter ari periculoase/nedorite. In cazul n care performant ele sistemului/procesului scad sub o limit a considerat a acceptabil a sau se produc daune, modic arile devin inacceptabile. De exemplu, cre sterea num arului de nregistr ari ntr-o baz a de date este inevitabil si conduce n timp la sc aderea vitezei de r aspuns la cererile utilizatorului. Aceast a sc adere a vitezei de r aspuns poate mult timp neglijat a de c atre utilizatori. Totu si, dac a nu se iau m asuri de tinere sub contol a performant elor sistemului, la un moment dat cre sterea timpului de r aspuns poate considerat a ca inadmisibil a afect and performant ele globale ale diverselor aplicat ii.
3.4.2
Caracteristici ale m asur arii
Variat iile valorilor diver silor parametri se pot datora unor cauze normale sau unor cauze speciale si pot puse n evident a prin realizarea unor m asur atori repetate. In timp ce standardele ne indic a ce trebuie s realiz am, m asurarea ne arat a ce am realizat efectiv. M asurarea este un proces prin care reu sim s a asociem valori numerice unor atribute zice sau fenomene. M asurarea unor caracteristici cu semnicat ie zic a clar a si simpl a (lungime, mas a, durat a, vitez a, debit etc.) se poate realiza de obicei direct cu ajutorul unor etaloane sau aparate de m asur a. In cazul n care trebuie evaluate caracteristici abstracte cum ar abilitatea, accesabilitatea, testabilitatea etc. va necesar a transformarea acestora n m arimi m asurabile. De exemplu pentru aprecierea abilit a tii putem num ara c ate defecte au ap arut ntr-un interval de timp bine precizat. Pentru a m asura o anumit a caracteristic a este necesar s a dispunem de: Un mijloc de m asurare care poate un aparat foarte sosticat sau doar
ALE MANAGEMENTULUI CALITAT II 82CAPITOLUL 3. PROCESE DE BAZA un om care observ a si apreciaz a anumite caracteristici (de exemplu un degust ator). Un traductor care transform a parametrii m asurat i ntr-o form a accesibil a omului sau unui sistem de calcul. Un sistem de transmitere a datelor la distant a de la locul unde se realizeaz a m asurarea la locul unde se realizeaz a analiza rezultatelor. Orice m asurare se caracterizeaz a prin acuratet e si precizie (Figura 2.5). Acuratet ea reprezint a diferent a dintre valoarea medie a unei serii de m asur ari si valoarea real a. Precizia reprezint a m arimea variat iei m asurilor n raport cu media.
Figura 3.5: Acuratet e si precizie
Se spune c a variat ia se datoreaz a unei cauze speciale dac a ea poate atribuit a unui eveniment care nu poate pus n leg atur a cu alte variat ii ale seriei de m asur ari considerate. Aparit ia unui astfel de eveniment nu este predictibil a. Cauzele speciale conduc la modicarea nepredictibil a a valorii medii deci sistemul risc a s a devin a instabil. De exemplu, c aderea unui modul de memorie poate compromite execut ia unei aplicat ii critice, cu consecint e foarte grave. Una dintre metodele de evitare a unor astfel de situat ii const a n proiectarea unor sisteme tolerante la defecte, care suport a c aderea unor componente f ar a pagube majore, eventual cu sc aderea unor performant e (trecerea n regim de avarie). Evident, pret ul de cost al sistemelor tolerante la defecte poate este mai mare dec at al sistemelor normale si de aceea ele sunt utilizate doar acolo unde costurile materiale sau sociale datorate defectului sunt considerate prea mari sau chiar inacceptabile. Eliminarea cauzelor speciale este obligatorie dar ea nu duce la cre sterea calit a tii ci la ment inerea acesteia la un nivel prestabilit. Se spune c a variat iile observate n valorile unor parametri se datoreaz a unor
AT IREA CALITAT II 3.4. IMBUNAT
83
cauze normale (commun cause) dac a ele sunt observate dup a eliminarea tuturor cauzelor speciale, sunt aleatoare si se cadreaz a ntre anumite limite prestabilite, considerate acceptabile (Figura 2.6). Cre sterea calit a tii prin eliminarea unor cauze normale necesit a o activitate specic a de inovare si investit ii at at pentru achizit ionarea unor materii prime mai bune sau pentru dotare tehnic a superioar a c at si pentru cre sterea nivelului de preg atire a angajat ilor si a motiv arii acestora. Trecerea la un nivel calitativ superior implic a garant ia c acest nivel va ment inut n continuare, deci nu este doar un experiment sau o nt amplare.
Figura 3.6: Evolut ia nivelului calit a tii datorat a unor cauze speciale sau normale si cre sterea calit a tii prin inovat ie si investit ii
In unele domenii exist a standarde de calitate cre pot de dou a feluri: Standarde care precizeaz a valorile parametrilor ce denesc calitatea produsului/serviciului.
ALE MANAGEMENTULUI CALITAT II 84CAPITOLUL 3. PROCESE DE BAZA Standarde care denesc modul n care pot obt inut i parametrii respectivi. Activitatea de mbun at a tire a calit a tii nu trebuie privit a cu cu o activitate de eliminare a unor erori ci ca o activitate de cre stere a ecient ei si ecacit a tii sistemului/serviciului.
3.5
Asigurarea calit a tii
ISO 9000 dene ste asigurarea calit a tii este acea component a a managementului calit a tii care furnizeaz a sigurant a c a cerint ele privind calitatea vor ndeplinite. Aceast a denit ie contravine percept iei comune conform c areia asigurarea calit a tii are rolul de a preveni problemele legate de implementarea calit a tii. Activit a tile specice asigur arii calit a tii nu controleaz a calitatea ci stabilesc nivelul la care calitatea va , este sau a fost controlat a. Toate aceste activit a ti sunt o-line si se realizeaz a post eveniment [46]. Pentru a nt elege ultimele armat ii care par s a contrazic a intuit ia, putem s a ne imagin am un scenariu foarte simplu. Vom presupune c a la un moment dat dorim s izol am termic o cas a. Pentru aceasta vom apela la speciali sti recomandat i de prieteni sau descoperit i prin sistemele de publicitate. Deoarece operat ia este destul de costisitoare, este evident c a vom ncerca s a m siguri c lucrarea va terminat a la termenul convenit si n condit iile de calitate pe care le dorim. Pentru aceasta ne vom interesa despre: component a echipei ce va folosit a la realizarea lucr arii (num ar, calicare, probleme de comportament); lucr ari de acela si tip executate de c atre rm a anterior; planul de execut ie al lucr arii; materiale utilizate si furnizori; tehnologia utilizat a; probleme anterioare cu alt i client i; pret urile materialelor si manoperei pe piat a; dotarea cu echipament si scule;
II 3.5. ASIGURAREA CALITAT etc.
85
Aparent toate aceste inform ari sunt realizate n ainte de nceperea lucr arii, deci au un caracter preventiv, ceea ce corespunde percept iei generale despre asigurarea calit a tii. In realitate toate informat iile implicate pot obt inute numai post -factum adic a nu pot obt inute dec at pornind de la activit a tile desf a surate anterior n domeniu de c atre rma angajat a sau furnizori.
ALE MANAGEMENTULUI CALITAT II 86CAPITOLUL 3. PROCESE DE BAZA
Capitolul 4
Modele ale calit a tii software

4.1
4.1.1
Metrici ale calit a tii software

Not iuni de inginerie software
Prin program nt elegem un set de instruct iuni pe care calculatorul poate s a le interpreteze pentru a rezolva o problem a, ca s a realizeze calcule sau diferite alte sarcini. Softwareul poate considerat ca o entitate conceptual a care include: un set de programe; date; proceduri de utilizare a programelor; documentat ie. Softwareul permite prelucrarea datelor cu ajutorul unor echipamente speciale numite generic calculatoare (vezi sect iunea . Din denit ia de mai sus rezult a imediat c a, pentru a putea aborda problema calit a tii softwareului, este necesar s a consider am toate cele 4 componente puse n evident a. Nu putem considera c a un software este de calitate corespunz atoare dac a exist a cel put in o component a ai c arei indici de calitate nu corespund cerint elor impuse.
87
88
II SOFTWARE CAPITOLUL 4. MODELE ALE CALITAT
Capitolul 5
Vericare, validare, testare

5.1 Not iuni introductive
Dup a cum se stie (capitolul 1), modelul este o reprezentare abstract a, simplicat a, generalizat a, codicat a a unei clase de obiecte, fenomene, concepte, procese. Procesele de proiectare/implementare ale unui produs implic a o serie de transform ari de modele. Evident, este de dorit ca aceste transform ari s a e realizate f ar a pierdere de informat ie. Deoarece transformarea unui model n altul implic a o interpretare a modelului surs a, pot s apar a ne nt elegeri, simplic ari neinspirate, neglijarea unor aspecte particulare dar importante n practic a, analogii fort ate, etc. Astfel de alter ari ale mesajului modelului init ial apar at at n cazul proiect arii realizate de om c at si n proiectarea asistat a de calculator. Rolul veric arii/test arii este de a pune de acord cerint ele implicate de modelul surs a cu caracteristicile modelului rezultat, a sa cum se vede n diagrama din Figura 5.1 care descrie etapele dezvolt arii unui program. In vorbirea curent a vericare, validare si testare se utilizeaz a frecvent unul n locul celuilalt f ar a a provoca confuzii. In abordarea inginereasc a ns a, cei trei termeni desemneaz a concepte distincte, pentru care se ncearc a o denire riguroas a, ca cea din lucrarea [1]:
Vericarea reprezint a procesul de evaluare a unui sistem cu scopul de a determina n ce m asur a rezultatul unei faze a ciclului de viat a satisface condit iile impuse la nceputul acelei faze. 89
90
CAPITOLUL 5. VERIFICARE, VALIDARE, TESTARE
Figura 5.1: Etapele dezvolt arii unui program cu evident ierea proceselor de vericare si testare.
Validarea reprezint a procesul de evaluare a unui sistem cu scopul de a determina n ce m asur a el satisface dorint ele/necesit a tile/interesele diferitelor categorii de purt atori de interese. Validarea poate realizat a si la sf ar situl unor faze ale ciclului de viat a al produsului dar este obligatorie la ncheierea ciclului de proiectare/implementare pe un produs funct ional, n condit ii reale de funct ionare. Testarea reprezint a o activitate prin care un sistem funct ional este activat n condit ii bine precizate cu scopul de a obt ine un anumit rezultat. Rezultatul obt inut este comparat cu cel estimat pentru a pune n evident a aparit ia unor anomalii. In realitate este greu s a accept am existent a unei singure denit ii a celor trei concepte. Practic, ecare persoan a implicat a n activitatea de dezvoltare a unui sistem poate s a adopte o denit ie a celor trei concepte n funct ie de obiectivele urm arite, de experient a si cultura n domeniu. Astfel, putem deni testarea ca un caz particular de vericare, realizat a pe un produs funct ional. Vericare poate considerat a orice activitate prin care se dovede ste c a un produs a fost realizat cum trebuie, n timp ce validarea ne arat a c a a fost realizat produsul care trebuie. Deoarece cele trei concepte sunt profund conectate ntre ele pe durata ciclului de viat a al unui produs, ele vor desemnate n multe cazuri prin acronimul VVT. Este mult mai u sor s a punem n evident a c ateva tr as aturi specice ale VVT: VVT nu permite s a tragem concluzii denitive privind eliminarea tuturor erorilor din sistemul analizat.
5.1. NOT IUNI INTRODUCTIVE
91
VVT nu trebuie confundat a cu depanarea de si evident cele dou a activit a ti sunt str ans conectate. Depanarea procesul prin care: se localizeaz a sursa unui defect; se elimin a sursa defectului; se repune n funct iune produsul. VVT trebuie s a evident ieze situat iile n care sistemul nu funct ioneaz a corect, nu s a demonstreze c a sistemul este funct ional. VVT trebuie s a aib a ca obiectiv cre sterea calit a tii sistemului testat prin eliminarea erorilor nc a din fazele timpurii ale ciclului de dezvoltare, reducerea timpului de dare n folosint a, reducerea cheltuielilor legate de mentenant a si eliminarea insatisfact iei diferitor categorii de purt atori de interese. Conform Boris Beiser (Software Testing Techniques ) exist a 5 faze n nt elegerea procesului de testare:
Faza 0 - Nu exist a nici o diferent a ntre VVT si depanare. Este specic programatorilor ncep atori. Faza 1 - Scopul VVT este de a demonstra c a sistemul funct ioneaz a. Este specic distribuitorilor de produse. Faza 2 - scopul VVT este de a demonstra c a sistemul nu este funct ional. Este specic testorilor ncep atori care au tendint a de a deveni v an atori de gre seli. Faza 3 - VVT nu trebuie s a demonstreze nimic, ea trebuie doar s a reduc a la un nivel acceptabil riscurile implicate de un sistem nu integral funct ional. Acesta ar nivelul la care trebuie s a ajung a produc atorii si speciali stii n testare. Faza 4 - VVT este o disciplin a mental a ce conduce, cu un efort minim, la reducerea riscurilor livr arii unui produs cu defecte. Acest nivel ar trebuie s a caracterizeze activitatea de management.
92
5.2
Principii ale VVT
1. Toate VVT trebuie s a e legate de cerint ele (explicite sau implicite) impuse produsului. Acest principiu ne arat a c a n primul r and este necesar s a e puse n evident a si eliminate acele defecte/anomalii care mpiedic a produsul s a satisfac a cerint ele utilizatorilor. Dac a n urma activit a tilor VVT sunt puse n evident a si alte defecte/anomalii, se va analiza dac a ele trebuie neaparat eliminate sau pot, cel put in ntr-o prim a etap a, acceptate. 2. Testele trebuie s a e planicate cu mult nainte de efectuarea lor. Aceast a abordare corespunde modelelor V si W de dezvoltare a proiectelor si este necesar a deoarece preg atirea testelor este n general laborioas a, implic and scrierea unui cod special pentru testare, crearea unor platforme hardware adecvate, obt inerea unor dispozitive de diverse naturi (motoare electrice, elemente de act ionare), obt inerea de aprob ari pentru realizarea unor teste speciale etc. Planicarea testelor pentru o component a a produsului poate s a nceap a imediat dup a ncheierea formul arii specicat iilor pentru acea component a. 3. Principiul lui Pareto. Formularea adaptat a a acestui principiu n VVT este: 80% dintre defectele descoperite sunt concentrate n 20% din componentele testate. Un corolar al acestui principiu ar putea formulat a n felul urm ator: probabilitatea descoperirii de noi defecte este mai mare n modulele n care au fost deja descoperite defecte. 4. VVT ncepe de la simplu si evolueaz a c atre complex. Acest principiu ne arat a c a primele teste planicate si executate se refer a la componente de complexitate c at mai mic a (uneori doar c ateva linii de cod care realizeaz a o funct ie bine precizat a) pentru a permite localizarea c at mai rapid a a defectelor. Numai dup a ce defectele de la acest nivel au fost eliminate, se trece la testarea unor grupe de module si n nal la testarea ntregului produs. 5. Atunci c and denim o activitate VTT, este esent ial s a preciz am la ce rezultate trebuie s a ne a stept am. 6. VTT exhaustiv a nu este posibil a adic a niciodat a nu putem garanta c a dintr-un produs au fost eliminate toate defectele. Acest lucru se datoreaz a faptului c a activitatea de testare este o activitate economic a cu resurse limitate si care trebuie s a se desf a soare ntr-un interval de timp acceptabil pentru tot i partenerii la proiect iar num arul total de
INGINEREASCA 5.3. TESTAREA CA DISCIPLINA
93
activit a ti necesare pentru a acoperi toate situat iile posibile poate enorm chiar n cazul unor componente relativ simple. 7. Vor interpretate cu grij a rezultatele tuturor testelor. 8. Trebuie s a test am cu acea si atent ie at at situat iile normale de funct ionare c at si pe cele anormale sau chiar inacceptabile. 9. Nu este sucient s a punem n evident a c a un produs nu realizeaz a ceea ce se presupune c a trebuie s a realizeze. Este necesar s a veric am si dac a nu cumva realizeaz a ceea ce nu trebuie s a realizeze. 10. Nu vom distruge datele si/sau echipamentele de testare utilizate, p an a c and nu renunt am la produsul testat. 11. Nu evalu am efortul de testare baz andu-ne pe ipoteza c a nu vor apare noi e securi. 12. Pentru a cu adev arat eciente, VVT trebuie realizate de o alt a echip a dec at cea care a dezvoltat produsele testate deoarece n timp ce dezvoltatorul este interesat de reducerea timpului de dare n folosint a, testorul este orientat pe asigurarea calit a tii produsului. 13. VTT este o activitate creativ a de un nalt nivel intelectual.
5.3
Testarea ca disciplin a inginereasc a
Inc a se mai poart a discut ii dac a activit a tile VVT reprezint a o art sau o stiint a cu specic ingineresc. Este adev arat c a n activitatea de testor intuit ia, inventivitatea joac a un rol foarte important, ns a acest lucru nu exclude necesitatea unei activit a ti sistematice sust inute bazat a pe metode si tehnici tipic inginere sti. Abordarea inginereasc a a VVT implic a: O nt elegere profund a a procesului de dezvoltare a produsului. Existent a unui set de principii fundamentale. Denirea unui model de viat a a produsului.
94
CAPITOLUL 5. VERIFICARE, VALIDARE, TESTARE Existent a unor norme sau chiar standarde pentru evaluarea calit a tii produselor. Evaluarea calit a tii prin aprecieri cantitative. Existent a unor metode generale ce pot particularizate pentru diverse domenii de activitate. Existent a unor cuno stint e specice, un set de termeni specici si a unui set de practici recomandate. Activit a tile VVT sunt desf a surate de ingineri din diverse domenii, cu antrenament si certicare specice. Existent a unui cod de etic a a profesiei.
Pot puse n evident a trei mari categorii de teste: testare static a realizat a prin inspect ia/revizia documentat iei, schemelor, pseudocodului, codului etc. Nu necesit a existent a unui produs funct ional deci poate realizat a nc a din primele etape ale ciclului de viat a al dezvolt arii produsului. Dac a este f acut a cu responsabilitate, va elimina multe dintre defectele care altfel vor afecta etapele nale ale dezvolt arii. testare dinamic a realizat a pe componente sau sisteme funct ionale. Permite determinarea unor erori care au sc apat test arii statice sau nici nu ar putea puse n evident a de aceasta (de exemplu aspecte ale interact iunii cu alte sisteme sau cu omul). testare de regresie, un caz particular de testare dinamic a realizat a dup a ecare depanare a unui produs prin reluarea tuturor/unei p art i a testelor anterioare cu scopul de a pune n evident a faptul c a depanarea a fost realizat a corect.
5.4
Termeni specici
In afara celor trei concepte fundamentale denite anterior (vericare, validare, testare) exist a si alt i termeni frecvent utilizat i. E secul (failure) reprezint a ne ndeplinirea unei cerint e adic a aparit ia unei diferent e ntre rezultatul/funct ionarea real a si rezultatul/funct io-narea estimat a (a steptat a). Apare atunci c and o cerint a justicat a a utilizatorului
5.4. TERMENI SPECIFICI
95
nu este realizat a corespunz ator cum ar cazul unor sisteme funct ionale dar prea lente sau foarte greu de utilizat. Uneori, pentru a desemna un e sec se utilizeaz a si termenii incident sau problem a. Pentru e securi grave, care fac imposibil a utilizarea sistemului, se utilizeaz a termenul c adere. C aderea poate s a apar a datorit a unor cauze proprii sistemului (defecte) sau unor cauze externe (c adere de tensiune, incendii, cutremure, manipulare gre sit a etc.). Exist a o diferint a important a ntre sistemele zice si programe n ceea ce prive ste cauza e securilor. In timp ce n sistemele zice multe e securi apar datorit a mb atr anirii materialelor sau uzurii, n software e securile se datoreaz a exclusiv erorilor umane n procesele de dezvoltare/mentenant a.De asemenea, n timp ce defectele ntr-un sistem zic pot s a apar a pe parcursul funct ion arii, uneori dup a un timp ndelungat si pot conduce la aparit ia unui lant de e securi (de exemplu frecarea prea mare a unui lag ar poate duce la deformarea acestuia prin abraziune si supra nc alzire iar n cazul cel mai grav chiar la provocarea unui incendiu care va distruge sistemul), erorile software exist a nc a din momentul edit arii programului si nu se amplic a n timp, ns a se pot propaga n sensul c a provoac a aparit ia unor e securi si n alte programe. Defectul (fault) existent n software se manifest a numai n timpul execut iei sub forma unui e sec n timp ce un defect ntr-un sistem zic se poate manifesta si pe durata distribuirii sau depozit arii (de exemplu un borcan cu mur aturi care nu este nchis ermetic poate s a dezvolte mucegai n timpul depozit arii). Uneori pentru a desemna un defect se utilizeaz a si termenul eroare de si, n mod normal, eroarea este cauza defectului. Eroarea (error) apart ine omului, put and s a aib a diverse cauze: lacune n preg atirea dezvoltatorilor/produc atorilor; lipsa de comunicare ntre dezvoltatori; neglijent a; management defectos; utilizarea unor materiale de calitate necorespunz atoare; utilizarea unor unelte si aparate de m asur a neadecvate.
96
CAPITOLUL 5. VERIFICARE, VALIDARE, TESTARE Pentru software putem pune n evident a si cauze specice cum ar : gre seli de editare a numelor unor variabile; nu se tine cont de precedent a operatorilor; incompatibilitate ntre tipul unei variabile si tipul valorii atribuite; incompatibilitate ntre tipul variabilelor si operatorii utilizat i; lipsa unor instruct iuni; necunoa sterea efectelor colaterale n interact iunea unor unit a ti de program dezvoltate n limbaje de programare diferite sau chiar n dialecte ale aceluia si limbaj; necunoa sterea arhitecturii aplicat iei; existent a unor defecte n structura bazelor de date; neluarea n considerare a unor aspecte ergonomice ale interfet elor om/calculator.
Aspectele legate de defectele n proiectarea bazelor de date vor tratate n Capitolul 8. Fiecare eroare are impact at at asupra produsului, prin aparit ia unor defecte si implicit a unor e securi/c aderi, dar si asupra utilizatorului care va nesatisf acut de un produs cu calitate sub a stept ari. Prin modelul unui defect vom nt elege leg atura ce poate stabilit a ntre comiterea unei erori si aparit ia unui defect n produsul creat. Modelele defectelor sunt frecvent utilizate pentru a genera un dict ionar de defecte. Ecient a unui test poate evaluat a n contextul unui model al defectului si se calculeaz a ca raportul dintre num arul de defecte puse n evident a de test si num arul de defecte calculat pe baza modelului defectelor. Cazul de test (test case) reprezint a o entitate care cont ine minim urm atoarele informat ii: un set de date de test (a set of test input) - date primite de codul testat de la o surs a extern a (uman a, software, hardware); condit ii de execut ie (execution conditions) condit iile impuse pentru executarea unui test (o stare particular a a bazei de date, set arile sistemului de operare sau ale altor programe auxiliare, congurarea unui dispozitiv hardware etc);
5.4. TERMENI SPECIFICI
97
ie sirile estimate (expected outputs) rezultatele a steptate ca urmare a execut iei codului cu datele de test si n condit iile specicate. Fiecare organizat ie poate decide introducerea n cazul de test a unor informat ii adit ionale pentru a-i cre ste valoarea ca obiect reutilizabil sau pentru a oferi informat ii detaliate testorilor si dezvoltatorilor. Un caz de test este proiectat pe baza specicat iilor cazului de test. Cont inutul si formatul documentelor pentru testare vor cuprinse n standardele organizat iei pentru documentat ie. Conceptul test poate redenit ca un grup de cazuri de test corelate sau grup de cazuri de test corelate si proceduri. Procedura (procedure) specic a pa sii necesari pentru realizarea unui test. Oracol al testului (test oracle) un document sau o secvent a de program care permite testorului s a determine dac a un test este trecut sau nu. Platforma de testare (test bed) mediul care cont ine tot softwareul si hardwareul necesare test arii unei componente software sau unui sistem software. In cazul VVT dinamice condit ia fundamental a pentru a putea realiza vericarea/testarea este s a avem un produs funct ional. Dac a produsul este un program, aceasta nseamn a c a nu exist a erori de compilare si programul poate lansat n execut ie. Dac a produsul este hardware, este necesar ca acesta s a poat a alimentat si init ializat. Pentru marea majoritate a programelor testate, este necesar ca acestea s a primeasc a diverse informat ii din mediul extern (date si comenzi). Intr arile pot furnizate aleator (testare empiric a) sau generate sistematic sub forma unor cazuri de test bine documentate. Pentru a putea introduce anumite date uneori este sucient s a dispunem de tastatur a si mouse sau de un sier de date preg atit anterior. Exist a ns a si situat ii c and trebuie scrise programe speciale care s a suplineasc a anumite p art i ale sistemului dezvoltat (de exemplu, pentru a testa o funct ie sau o procedur a este necesar s a scriem un program care s a apeleze funct ia si s a transfere parametrii necesari. Rezultatele obt inute trebuie colectate, comparate cu rezultatele estimate si formulate concluzii. S i n acest caz, n anumite situat ii vizualizarea datelor nu este posibil a direct deoarece a sarea implic a existent a unui modul special de a sare. Exist a cazuri n care pe durata execut iei programul testat apeleaz a funct ii sau proceduri c arora le furnizeaz a date/informat ii de stare
98
si de la care a steapt a anumite date sau informat ii de stare ca r aspuns la datele transmise. Dac a aceste programe lipsesc, este necesar ca testorul s a le nlocuiasc a cu programe scrise special. Suplimentar, sunt necesare programe elaborate pentru generarea rezultatelor estimate si compararea acestora cu rezultatele reale obt inute. Programele care nlocuiesc module reale, asigur and o funct ionalitate minim a necesar a proceselor VVT, se numesc si programe surogat (stubs). Gestiunea lans arii n execut ie a cazurilor de test, culegerii rezultatelor si compar arii cu rezultatele estimate, este asigurat a de programe driver. Cazurile de test, programele surogat, programele driver, mediul de execut ie, monitoarele, analizoarele, simulatoarele formeaz a mpreun a mediul de vericare/testare sau platforma de testare (Figura 5.4). Dezvoltarea unei platforme de testare pentru hardware sau pentru sis-
Figura 5.2: Structura simplicat a a unei platforme de testare. PC - punctul de comand a de unde se introduc datele si comenzile. PO - punctul de observat ie unde se vizualizeaz a evolut ia entit a tii testate, se colecteaz a rezultatele si se fac comparat iile cu scopul formul arii concluziilor teme hibride este si mai dicil a deoarece implic a n multe situat ii rezolvarea interfat arii software-hardware si utilizarea unor surogate pentru componente zice.
5.5. CLASIFICAREA DEFECTELOR
99
O problem a delicat a o reprezint a necesitatea test arii softwareului si hardwareului pentru realizarea platformei de testare, deoarece orice defect la aceste componente poate duce la concluzii gre site privind existent a unor defecte n componenta testat a si pe cale de consecint a la pierdere de timp si bani cu o depanare inutil a. Platforma de testare va preg atit a n ainte de a ncepe dezvoltarea produsului si, pe c at posibil, va p astrat a chiar si dup a darea n folosint a a produsului. Grupul de asigurare a calit a tii softwareului (software quality assurence group SQAG) o echip a de oameni cu preg atirea si ndem anarea cu care s a asigure toate act iunile necesare pe durata procesului de dezvoltare, astfel inc at softwareul rezultat s a e conform tuturor cerint elor tehnice stabilite. Revizia (review) o int alnire a unui grup format din manageri, dezvoltatori, testori si alte persoane, cu scopul de a evalua un artefact sau un set de artefacte. Reviziile sunt un tip de tehnic a de testare software ce poate utilizat a pentru evaluarea calit a tii unui artefact software (specicat ia cerint elor, documente de proiectare, planuri de test, cod surs a). Auditul (audit) un caz particular de revizie , condus de obicei de SQAG, cu scopul de a asigura compatibilitatea cu specicat ii/standarde/ nt elegeri contractuale.
5.5
Clasicarea defectelor
Pentru a benecia de toate avantajele experient ei acumulate si pentru a putea reutiliza cazurile de test n c at mai multe proiecte, organizat ia trebuie s a decid a asupra unei anumite scheme de clasicare a defectelor si s a o aplice n toate proiectele. Tipul defectelor si frecvent a aparit iei lor ghideaz a planicarea testelor si proiectarea acestora, permit and selectarea acelor strategii de testare care au cele mai mari sanse s a detecteze anumite tipuri de defecte. Testele pentru softwareul nou vor proiectate pentru a detecta n primul r and cele mai frecvent nt alnite defecte. Majoritatea defectelor se detecteaz a prin teste bazate pe execut ie dar si reviziile pot s a se dovedeasc a deosbit de utile. In funct ie de etapa din ciclul de viat al produsului unde apar, defectele pot clasicate conform diagramei din Figura 7.2:
100
Figura 5.3: Clase de defecte, n funct ie de etapa din ciclul de viat a al produsului n care sunt generate.
Clasa defectelor n cerint e/specicat ii Primele etape ale ciclului de viat a al unui produs sunt critice pentru asigurarea unei calit a ti superioare a acestuia. Defectele introduse n aceast a faz a pot persista pe durata ntregului ciclu si sunt greu de eliminat. Consemnarea cerint elor se face n limbaj natural, ceea ce conduce frecvent la ambiguit a ti, contradict ii, redundant a si imprecizie. In multe organizat ii specicat iile sunt formulate tot ntr-un limbaj nat-
101
ural, deci apar acelea si probleme. Suplimentar, specicat iile se obt in n urma interpret arii de c atre proiectant a cerint elor beneciarului, deci cre ste probabilitatea aparit iei unor defecte prin necunoa sterea exact a a termenilor utilizat i de cei care formuleaz a cerint ele, a priorit a tilor, a necesit a tilor reale. In ultimii ani au fost introduse limbaje formale pentru redactarea specicat iilor si unelte software pentru manipularea acestora, dar problemele sunt departe de a rezolvate. Principalele categorii de defecte din aceast a clas a sunt: Defecte ale descrierii funct ionale descrierea general a a ceea ce face produsul si comportamentul s au ori relat ia intrare/ie sire este incorect a, ambigu a si/sau incomplet a. Defecte ale unor caracteristici. O caracteristic a (feature) poate descris a ca o proprietate distinct a a unui sistem sau a unei componente a acestuia si se refer a la aspectele funct ionale ale softwareului, care se suprapun peste cerint ele funct ionale descrise de utilizatori/client i. Caracteristicile se refer a si la cerint e de calitate cum ar performant a sau sigurant a n funct ionare. Defectele caracteristicilor pot : lipsa unei caracteristici; ambiguitatea; incorectitudinea; redundant a. Defecte ale interact iunii ntre caracteristici datorate unei descrieri incorecte/incomplete a modului n care diverse caracteristici interactioneaz a. Exemplu: clasicarea unui pacient dup a tipul de asigurare impune un anumit pachet de servicii gratuite acordate pacientului. Defecte ale interact iunii ntre caracteristici datorate unei descrieri incorecte/incomplete a modului n care diverse caracteristici interact ioneaz a. Exemplu: clasicarea unui pacient dup a tipul de asigurare impune un anumit pachet de servicii gratuite acordate pacientului. Defecte ale descrierii interfet elor se refer a la defecte ce apar n descrierea modului n care interact ioneaz a sistemul analizat cu alte sisteme software, hardware sau cu utilizatorii. Exemplu: un editor de scheme logice poate s a interact ioneze cu un editor de stimuli si un program de simulare sau de generare a cablajelor.
102
Pentru depistarea defectelor de tipul celor descrise anterior se utilizeaz a pe scar a larg a tehnici black box n care se exploateaz a descrierea funct ional a a produsului testat f ar a referiri la detalii de implementare. Multe dintre aceste defecte pot puse n evident a n fazele timpurii ale ciclului de viat a cu ocazia unei recenzii corect planicate. Testele de tip black box pot planicate la nivel de component a, integrare, sistem sau acceptant a (vezi si sect iunea urm atoare). Defectele de interact iune sunt puse n evident a prin tehnicile black box n etapa de integrare sau testare a sistemului. Clasa defectelor de proiectare Apar atunci c and componente ale sistemului, interact iunea ntre componentele sistemului, interact iunea cu softwareul extern, cu hardwareul sau cu utilizatorii nu sunt corect proiectate adic a pot reliefate gre seli n proiectarea algoritmilor, structurilor de date, logicii de control, interfet elor ntre module sau cu alte programe/hardware. In cazul n care nu se utilizeaz a pseudocodul n descrierea detaliat a a tuturor elementelor produsului program, defectele de proiectare se vor propaga n codul dezvoltat. Principalele defecte din aceast a categorie sunt: 1) Defecte n algoritmi si procese, adic a: expresii gre site; ordinea gre sit a a operat iilor ntr-un proces; pa si lips a sau duplicat i; omiterea unor veric ari cum ar divizarea cu 0; neluarea n considerare a unor cazuri particulare; algoritmul ales nu este cel potrivit. 2) Defecte logice si n controlul uxului prelucr arilor atunci c and expresiile logice si/sau uxul prelucr arilor nu sunt prezentate corect n pseudocod: utilizarea unei condit ii gre site ntr-o instruct iune de ramicare; plasarea gre sit a a ramic arii; utilizarea gre sit a a ciclurilor ; neacoperirea unor c ai;
103
ne nt elegerea formul arii unor condit ii cu expresii booleene care folosesc si valoarea nul a; etc. 3) Defecte ale datelor asociate cu proiectarea gre sit a a structurilor de date: lipse ste un c amp ntr-o nregistrare; se asigneaz a gre sit tipul de dat a al unei variabile sau al unui c amp al unei nregistr ari; un vector/tablou nu are un num ar corespunz ator de elemente; spat iul de stocare nu este asignat corespunz ator. Pentru relevarea unor astfel de defecte se recomand a revizii corect planicate si utilizarea unui dict ionar al datelor. 4) Defecte ale descrierii funct ionale includ elemente incorecte, lips a sau ambigue ale descrierii funct ionale a unui modul. Se depisteaz a cel mai bine cu ocazia unei revizii a proiect arii. 5) Defecte ale descrierii interfet ei ntre module utilizarea unui tip al parametrilor incorec/inconsistent, un num ar gre sit de parametri, ordine gre sit a a parametrilor. 6) Defecte ale descrierii interfet elor externe deriv a din proiectarea gre sit a a interfet elor cu sisteme software externe, cu bazele de date sau diverse componente hardware, descrierea necorespunz atoare a interfet ei cu utilizatorul, lipsa unor comenzi, lipsa unor mesaje adecvate pentru utilizator. Sunt puse n evident a cu ocazia unor revizii ale proiectului. Observat ie! Dac a nu se utilizeaz a pseudocodul n faza de proiectare, multe dintre defectele enumerate apar direct n faza de elaborare a codului.
Clasa defectelor n cod Sunt evident legate de produsele software. Pentru produsele hardware pot puse u sor n evident a alte tipuri de defecte specice diverselor abord ari n implementare. Dac a pentru sintez a se utilizeaz a un HDL, defectele prezentate n continuare pot s a apar a.
104
1) Defecte n algoritmi si procese lipsa unor teste de dep a sire si subdep a sire; compar ari ntre date de tipuri incompatibile sau cu operatori inadecvat i; ordinea gre sit a n executarea unor operat ii; lipsa parantezelor; utilizarea gre sit a a semnului; utilizarea unui tip de variabil a nepotrivit (exemplu: simpl a precizie n loc de dubl a precizie). 2) Defecte n logica de control a ordinei operat iilor expresii incorecte ntr-o instruct iune if ori switch; gre seli n utilizarea ciclurilor; neacoperirea cu cod a unor ramuri ale programului. 3) Defecte de editare scrierea gre sit a a numelui unei variabile; scrierea gre sit a a valorii unei constante; lipsa unei paranteze; operator gre sit. 4) Defecte de init ializare lipse ste init ializarea; init ializare cu valoare incorect a. 5) Defecte n uxul de prelucrare a datelor init ializ ari multiple; eliminarea unei variabile in ainte de a utilizat a. 6) Defecte ale datelor
5.5. CLASIFICAREA DEFECTELOR omisiunea unui c amp ntr-o nregistrare; utilizarea unui tip de dat a gre sit; un tabel cu un num ar gre sit de elemente; denirea incorect a a unor constante. 7) Defecte ale interfet elor ntre module num ar incorect de parametri; tipul parametrilor este inconsistent; ordinea gre sit a a parametrilor; apel la module inexistente. 8) Defecte ale documentat iei codului nu reecta cee ce face programul; este incomplet a, ambigu a, incorect a, neactualizat a.
105
Afecteaz a eforturile de testare put and duce la proiectarea unor teste inadecvate. Astfel de defecte sunt descoperite pe durata reviziei codului. 9) Defecte ale interfet elor cu softwareul extern si hardwareul conexiuni la baze de date; operat ii de intrare/ie sire; utilizarea memoriei; comunicat ii cu dispozitive externe pe baza unor protocoale; accesul la siere de date; etc. Se detecteaz a cel mai bine utiliz and tehnici glass-box care implic a cunoa sterea structurii. Anumite tehnici black-box sunt foarte utile pentru a depista defecte cum ar cele din expresii booleene.
106
Defecte n teste Testele sunt proiectate ca orice alt produs deci pot supuse unor erori ale proiectantului sau ale celui care le utilizeaz a. Putem distinge dou a mari categorii de defecte n testele software: Defecte n softwareul auxiliar (test hardness, scafolding cod) apar datorit a ne nt elegerii codului testat sau neglijent ei n proiectarea si implementarea testelor. Toate tipurile de defecte discutate anterior pot s a apar a si n codul auxiliar. Se impune o proiectare foarte atent a si testarea/validarea separat aa acestui cod. Defecte n cazurile si procedurile de test se materializeaza prin cazuri si proceduri de test incorecte, incomplete, inadecvate sau lips a. Se depisteaz a at at pe durata reviziilor c at si n procesul de testare, printr-o analiz a atent a a condi iilor de test si a rezultatelor ob inute. Eliminarea acestor defecte este obligatorie.
5.6
5.6.1
Nivele de realizare a VVT

Modelele V si W ale ciclului de viat a al unui produs (sect iunile 1.5.6, 1.5.7) pun n evident a mai multe nivele de realizare a VVT n funct ie de complexitatea structurii analizate. In continuare vor detaliate doar primele trei nivele (vezi si Figura 5.3): nivelul component a - entit a ti a c aror descompunere nu mai este posibil a sau nu se justic a; nivelul integrare - entit a ti formate prin reunirea a cel put in dou a componente capabile s a interact ioneaze pentru a realiza o anumit a/anumite specicat ii de proiect; nivelul sistem - entitatea format a prin integrarea tuturor componentelor pentru realizarea integral a a specicat iilor de proiect;
5.6.2
Vericarea, validarea si testarea componentelor (unit testing)
VVT la nivel de component a are ca obiectiv depistarea existent ei unor defecte la nivel de unitate funct ional a (component a).
5.6. NIVELE DE REALIZARE A VVT
107
Figura 5.4: Reprezentarea simbolic a a celor trei nivele de realizare a VVT studiate n aceast a lucrare. Se observ a cre sterea complexit a tii entit a tii supuse proceselor VVT.
Principalele avantaje ale acestei abord ari sunt: Dimensiunea componentelor este sucient de mic a pentru a permite ulterior localizarea si eliminarea ntr-un timp acceptabil a defectelor care au provocat e secul. Dimensiunea mic a a componentelor permite generarea sistematic a a unor cazuri de test care s a acopere principalele defecte care ar putea s a apar a. Acest lucru permite automatizarea proceselor VVT. Se elimin a confuziile legate de aparit ia si propagarea unor defecte n diverse componente. Poate realizat a n mare parte chiar de c atre dezvoltator. Defecte tipice puse tn evident a pentru produsele software sunt: Nu se tine cont de precedent a operatorilor; Utilizarea gre sit a a parantezelor; Nume gre site ale obiectelor programului; Compararea unor date de tipuri necompatibile; Lipsa init ializ arii sau init ializare gre sit a;
108
CAPITOLUL 5. VERIFICARE, VALIDARE, TESTARE Utilizarea unei precizii insuciente; Utilizarea gre sit a a unor operatori; Ignorarea particularit a tilor diverselor variante/versiuni de compilator/interpretor;
In cazul produselor hardware, natura defectelor urm arite depinde de modul de proiectare si realizare. Dac a se are n vedere proiectarea clasic a cu circuite integrate pe scar a mic a sau medie, se va realiza o vericare a schemei obt inute pentru ecare bloc n parte, cu scopul de a pune n evident a diferent e ntre specicat ii si sau aparit ia unor anomalii (de exemplu st ari/cicluri capcan a, lipsa init ializ arii, init ializare gre sit a etc.). Testarea/validarea se realizeaz a la nivel zic, adic a pe o schem a implementat a. Se pot pune n evident a diverse anomalii n funct ionarea real a (glitchuri, nt arzieri inadmisibile, deformare de semnale, consum prea mare de putere, interferent e de semnale etc.). Dac a proiectarea se face cu circuite VLSI, multe dintre defectele care apar n faza de vericare sunt defecte software la nivel de limbaj HDL. Totu si este posibil ca s a nu existe defecte de programare dar schema rezultat a s a e inutilizabil a (de exemplu aparit ia unor latchuri nedorite datorit a necunoa sterii anumitor particularit a ti ale limbajelor HDL sau neglijarea unor aspecte ale program arii concurente). O vericare ecient a se realizeaz a n cazul schemelor electronice cu ajutorul simulatoarelor. In cazul schemelor digitale cu un num ar relativ mic de intr ari se poate realiza chiar si o vericare exhaustiv a, adic a pentru toate combinat iile de intrare posibile. Testarea/validarea poate s a pun a n evident a anomalii legate de viteza de lucru a semnalului de tact, probleme ale propag arii semnalelor prin circuitul integrat, gre seli n editarea constr ngerilor, necesitatea optimiz arii structurii la nivel zic etc.). De obicei testarea acestor circuite se face la nivel de integrare sau chiar la nivel de sistem. O vericare ecient a se realizeaz a n cazul schemelor electronice cu ajutorul simulatoarelor. Procesele VVT pentru circuite integrate nu fac obiectul acestei lucr arii, neput and n general realizate cu mijloacele de care dispun utilizatorii acestor circuite. Totu si, cel put in pentru circuitele integrate pe scar a mic a si medie, pot realizate anumite teste funct ionale care nu implic a aparatur a de mare complexitate. Metode generale pentru VVT la nivel de component a vor prezentate n capitolele 6 si 7, accentul ind pus pe componentele software.
109
5.6.3
VVT la nivel de integrare (integration testing)
Obiectiv: Testeaz a interfat a ntre componente pentru a pune n evident a defecte n transferul de informat ie ntre componente. Exist a mai multe abord ari ale test arii de integrare: Integrarea incremental a; Integrarea top-down; Integrare bottom-up; Smoke testing; Integrarea sandwich. Testarea de regresie; Observat ii! Indiferent de abordare, integrarea trebuie planicat a cu grij a pentru a minimiza efortul de scriere a driverelor si surogatelor. Nici o component a nu poate integrat a p an a c and nu trece toate testele la nivel de component a. Integrarea incremental a. Integrarea se face pas cu pas, integr and la primul pas dou a componente, apoi, dup a ce toate testele au fost realizate si defectele eliminate, se adaug a alt a component a, se refac toate testele anterioare, se adaug a noi teste si a sa mai departe p an a c and cu testele considerate nu mai poate pus n evident a nici un defect. Modul de desf a surare a procesului de integrare este reprezentat simbolic prin diagramele din Figura 5.5. Se
Figura 5.5: Desf a surarea procesului de integrare incremental a pentru 4 componente.
110
observ a c a procesul de integrare dureaz a foarte mult deoarece a n-a component a nu poate ad augat a p an a c and nu au fost integrate si testate prmele n componente. De asemenea efortul de dezvoltare a programelor surogat poate mai mare dec at pentru alte abord ari.
Integrarea top-down. Este o variant a a integr arii incrementale n care se porne ste de la programul principal si se adaug a mereu componente de pe nivelele imediat inferioare p an a c and tot programul este testat. Exist a dou a strategii posibile: Integrarea n ad ancime (depth-rst) nu se trece la integrarea pe o ramur a a grafului p an a c and nu a fost ncheiat a integrarea pe o ramur a, ca n Figura 5.6; Integrarea pe nivele (breadth-rst) - nu se trece la integrarea pe o ramur a a grafului p an a c and nu a fost ncheiat a integrarea (vezi Figura 5.7). Indiferent de strategia aleas a, pa sii procesului de integrare sunt: Programul principal joaca rolul de test driver si se introduc surogate pentru ecare dintre componentele direct subordonate acestuia. In funct ie de strategia aleas a, la ecare etap a un surogat este nlocuit cu o component a real a si surogatele aferente acesteia. Pentru ecare componenta nou integrata se realizeaza testele planicate. Numai dup a efectuarea tuturor testelor propuse, se trece la nlocuirea urm atorului surogat cu o component a real a. Se efectueaz a teste de regresie pentru a pune n eviden a eventuale defecte datorate ultimei componente integrate. S i n acest caz, la un moment dat poate integrat a o singur a component a dar nu mai este necesar s a e dezvoltate programe driver. Integrarea bottom-up. Este o variant a a integr arii incrementale n care se porne ste de la componentele situate pe cele mai de jos nivele n structura programului. Pa sii procesului de integrare:
111
Figura 5.6: Desf a surarea procesului de integrare top-down n ad ancime pentru 8 componente.
Componentele de la nivelul inferior se reunesc n clustere care realizeaz a subfunct ii bine precizate. Pentru ecare cluster sunt scrise programe driver care gestioneaz a introducerea datelor de test si extragerea rezultatelor. Se testeaz a ecare cluster. Se elimin a driverele si se integreaz a n cluster componente de la nivelul superior, efectu and si testele de regresie corespunz atoare. Procesul se reia p an a c and toate componentele au fost integrate. Principalul avantaj al metodei l reprezint a posibilitatea test arii n paralel a mai multor clastere.
112
Figura 5.7: Desf a surarea procesului de integrare top-down pe nivele pentru acelea si 8 componente ca n gura precedent a.
Integrarea combinat a (sandwich) Este o variant a a integr arii incrementale n care se combin a cele dou a metode de integrare prezentate anterior pentru a m ari ecient a test arii prin cre sterea paralelismului n operat iile de testare (Figura 5.9). Pa sii procesului de integrare prin aceast a metod a sunt: Componentele de la nivelul inferior se reunesc n clustere care realizeaz a subfunct ii bine precizate. Pentru ecare cluster sunt scrise programe driver care gestioneaz a introducerea datelor de test si extragerea rezultatelor. Se testeaz a ecare cluster.
113
Figura 5.8: Desf a surarea procesului de integrare bottom-up.
Figura 5.9: Desf a surarea procesului de integrare combinat a pentru 11 componente.
Pentru componentele de la nivelul superior testarea se face prin metoda top-down.
114
CAPITOLUL 5. VERIFICARE, VALIDARE, TESTARE Se elimin a driverele si surogatele si se integreaz a toate componentele testate anterior.
Observat ie! Avantajele metodei sunt legate de abilitatea planic arii operat iilor de testare n a sa fel inc at s a se minimizeze necesarul de surogate si drivere si s a creasc a paralelismul operat iilor de integrare/testare. Testarea de regresie Este un proces prin care se veric a dac a o modicare introdus a ntr-o component a, indiferent de cauz a, nu afecteaz a funct ionalitatea acesteia sau a ntregului program. Setul de teste de regresie cont ine trei clase de teste: Teste adit ionale orientate pe anumite funct ii realizate de program. Teste care s a verice toate funct iile realizate de program. Teste concentrate pe componentele modicate.
Capitolul 6
Metode VVT funct ionale

6.1 Prezentare general a
Planicarea activit a tilor VVT funct ional a (black-box, functional, behavioral) se bazeaz a numai pe specicat iile de proiect, f ar a nici un fel de cuno stint e privind structura obiectului analizat. In software aceasta presupune c a nu se cunosc detalii privind modul de realizare a programelor testate, iar uneori nici limbajul n care aceste programe au fost dezvoltate. In hardware vericarea/testarea funct ional a presupune ignorarea tehnologiei de realizare (nivelul de integrare, tehnologia de realizare a CI). VTT black-box introduc n sistem un set de valori ale m arimilor de intrare selectate pe baza anumitor criterii si compar a rezultatul obt inut cu rezultatul estimat nscris n oracol. Obiectivul VVT funct ionaleconst a n determinarea unor cazuri de test care s a permit a evident ierea unor defecte cu un efort de procesare minim. Nu are nici o important a cum este generat un rezultat, ci numai dac a acesta corespunde specicat iilor. Inginerul VVT poate deci s a se concentreze numai asupra r aspunsului sistemului la stimului selectat i n condit ii bine precizate ignor and structura si funct ionarea sistemului. Dac a se dore ste testarea unor subsisteme, acestea vor denite pe criterii funct ionale, nu structurale. Un mare avantaj al VVT black-box const a n faptul c a cestea pot utilizate la orice nivel al dezvolt arii produsului (componente, integrare, sistem, acceptant a) si n orice faz a ciclului de viat a acestuia (dezvoltare, product ie, mentenant a dezafectare). Metodele de baz a ale VVT black-box sunt: partit ionarea n clase de echivalent a; 115
116
CAPITOLUL 6. METODE VVT FUNCT IONALE analiza valorilor limit a; metoda grafurilor cauz a - efect; testarea tranzit iei st arilor.
In afara acestor metode exist a multe alte metode mai put in cunoscute sau utilizate n cazuri speciale.
6.2
6.2.1
Metode VVT funct ionale de baz a

Metoda partit ion arii n clase de echivalent a
Orice sistem prime ste la intrare anumite semnale, date care reprezint a variabilele de intrare ale sistemului. Fiecare variabil a se caracterizeaz a prin natura ei, structur a si domeniu de valori. Metoda analizat a n aceast a subsect iune implic a dividerea domeniului ec arei variabile de intrare n clase de echivalent a. Prin clas a de echivalent a (equivalence class) vom nt elege un grup de valori despre care se presupune c a sunt procesate n acela si fel de c atre produsul vericat/validat/testat. Testarea pentru o singur a valoare reprezentativ a din clasa de echivalent a se consider a sucient a, deoarece pentru orice alt a valoare din aceea si clas a se poate presupune c a nu se va observa un comportament diferit. Evident, acest lucru nu este totdeauna adev arat, deci metoda nu poate garanta eliminarea tuturor erorilor. Observat ie! Tesarea corect a impune at at testarea claselor de echivalent a pentru valori admise la intrare (date valide) c at si a claselor de echivalent a pentru valori incorecte. Pentru determinarea partit iilor de echivalent a se parcurg urm atoarele etape: Se determin a mult imea datelor valide. Se determin a mult imea datelor incorecte (invalide). Folosind informat iile primite direct de la utilizator, specicat iile de proiect sau cuno stint e generale legate de domeniul de activitate (aspecte matematice, teorii zice, legislat ie, cutume etc.), se raneaz a
6.2. METODE VVT FUNCT IONALE DE BAZA
117
partit ionarea pun and n evident a noi clase de echivalent a at at pentru datele valide c at si pentru datele invalide. Se alege pentru ecare clas a de echivalent a o valoare reprezentativ a. Alegerea se poate face aleator sau pe baza experient ei acumulate de testor. Se vor evita cazurile particulare (valori la limita ntre dou a clase, valoarea 0 , matricea nul a sau unitate etc.), acestea urm and s a e analizate separat. Fiec arui set de valori reprezentative alese i va corespunde un caz de test. In continuare vor analizate mai multe exemple cu scopul de a evident ia diverse aspecte ale utiliz arii metodei. Observat ii si concluzii setul de date alese trebuie s a acopere toate clasele de echivalent a; este necesar sa e luate n considerare at at clasele de echivalent a valide c at si cele invalide, corespunz atoare unor date eronate sau inacceptabile; clasele de echivalent a pot deduse si din condit iile de ie sire; procesul de determinare a claselor de echivalent a este un proces heuristic; nu exist a ret ete de determinare a claselor de echivalent a ci doar idei care ghideaz a determinarea claselor de echivalent a si din aceast a cauz a, pornind de la acelea si specicat ii de proiect, diver si testori pot s a genereze seturi de clase de echivalent a diferite; exist a situat ii n care limita ntre clasele de echivalent a este ambigu a sau chiar lipse ste; n anumite situat ii apare un num ar foarte mare de clase de echivalent e; multe dintre anomaliile semnalate apar datorit a unor specicat ii ambigue, contradictorii, incomplete sau inconsistente, care trebuie l amurite prin dialog direct cu beneciarul/utilizatorul. exist a cazuri care, prin natura lor, sunt foarte dicil de analizat (cele legate de sc). De si nu exist a ret ete privind partit ionarea n clase de echivalent e, pot formulate anumite indicat ii pentru partit ionare:
118
CAPITOLUL 6. METODE VVT FUNCT IONALE Dac a o condit ie este specicat a ca un interval de valori, se alege o clas a de echivalent a valid a care acoper a acest interval si dou a clase de echivalent a invalide, una la st anga si alta la dreapta intervalului valid. Dac a o condit ie de intrare este specicat a ca un num ar de valori, se alege o clas a de echivalent a valid a care include acel num ar de valori si dou a clase de echivalent a invalide una cu mai put ine si alta cu mai multe valori. Dac a o condit ie este specicat a sub forma unei liste de valori admise, se alege o clas a de echivalent a valid a care cont ine toate aceste valori si o clas a de echivalent a invalid a care cont ine toate celelalte valori posibile. Dac a o condit ie de intrare este specicat a sub forma trebuie sa e , se alege o clas a de echivalent a valid a care respect a condit ia si o clas a de echivalent a invalid a care nu respect a condit ia. Pot luate n considerare mai multe etape de ranare a partit iei.
Dup a determinarea partit iilor de echivalent a se trece la specicarea cazurilor de test. Dac a se analizeaz a un singur parametru, se va tine cont de urm atoarele indicat ii: Fiec arei clase de echivalent a i se ata seaz a un identicator unic (de obicei un num ar ntreg). Se genereaz a cazuri de test p an a c and ecare clas a de echivalent a valid a este acoperit a de cel put in un caz de test; Dac a o clas a de echivalent a valid a este denit a printr-o condit ie de forma c1 AND c2 AND AND cn, este necesar un singur caz de test; Dac a o clas a de echivalent a valid a este denit a printr-o condit ie de forma c1 OR c2 OR OR cn, este necesar c ate un caz de test pentru ecare dintre condit ii ; Se dezvolt a cazuri de test pentru toate clasele de echivalent a invalide, p an a c and toate aceste clase sunt acoperite de un caz de test. Orice valoare considerat a interesant a pe baza experient ei anterioare, va aleas a pentru un nou caz de test (de exemplu valorile 0 si 1 sau r ad acinile numitorului n testarea algoritmilor numerici).
119
Precizarea cazurilor de test pentru un set de parametri se face tin and cont de urm atoarele reguli: Fiec arui caz de test i se ata seaz a un identicator unic (de obicei un num ar ntreg). Cea mai simpl a metod a const a n generarea cazurilor de test pentru clasele de echivalent a valide, combin and toate valorile reprezentative ale parametrilor implicat i. Se genereaz a c ate un caz de test pentru ecare combinat ie. De obicei multe dintre teste nu sunt relevante si vor eliminate n urma unei analize detaliate, n timp ce teste utile pot s a nu apar a. Aceste anomalii pot eliminate dac a generarea claselor de echivalent a pentru diver si parametri se face corelat si nu independent. Se dezvolt a cazuri de test pentru toate clasele de echivalent a invalide p an a c and toate aceste clase sunt acoperite de c ate un caz de test. O valoare incorect a a unui parametru va combinat a obligatoriu cu valori corecte ale celorlalt i parmetri testat i. Exemple Exemplul 1: Se consider a un program care calculeaz a penaliz arile la o sum a restant a, dup a regula: 1%/zi pentru nt arzieri ntre 1 si 30 zile; 2%/zi pentru nt arzieri ntre 31 si 90 zile; 4%/zi pentru nt arzieri peste 90 zile; Datoria nu poate mai mic a de 1000RON dar nici mai mare de 20000RON. Dac a una dintre datele introduse este invalid a, se va a sa mesajul Atentie!! data invalida. Dac a nt arzierea este mai mare de 90 zile, penalizarea va a sat a cu culoare ro sie. Presupunem c a programul testat este o funct ie care prime ste la intrare parametrii numar zile (valoare ntreag a strict pozitiv a) si datorie (numar ntreg pozitiv). Determinarea claselor de echivalent a se poate face conform urm atorului
120
CAPITOLUL 6. METODE VVT FUNCT IONALE
Tabela 6.1: Tabelul claselor de echivalent a pentru testarea programului aferent exemplului 1. vEC desemneaz a o clas a de echivalent a pentru valori valide iar iEC reprezint a o clas a de echivalent a pentru valori invalide. Variabila Clase de echivalent a vEC11: 1 numar zile 30 vEC12: 31 numar zile 90 vEC13: 91 numar zile iEC11: numar zile 0 vEC21: 1000 datorie 20000 iEC21: datorie < 1000 iEC22: 20000 < datorie Valori reprezentative 15 60 100 -5 10000 500 200000 Observat ii
numar zile
a sare cu ro su
datorie
Tabela 6.2: Tabelul cazurilor de test pentru testarea programului aferent exemplului 1, obt inute prin metoda partit ion arii n clase de echivalent a. Caz test numar zile datorie Rezultat TC1 15 10000 150 TC2 60 10000 6000 TC3 100 10000 10000 TC4 -5 10000 Atentie! data invalida TC5 15 500 Atentie! data invalida TC6 15 200000 Atentie! data invalida TC7 60 500 Atentie! data invalida TC8 60 200000 Atentie! data invalida TC9 100 200000 Atentie! data invalida TC10 100 500 Atentie! data invalida
tabel: Pe baza informat iei din tabelul Tabel 6.1 putem deduce un set de cazuri de test, prezentate n tabelul Tabel 6.2.
Observat ie! Pentru a putea executa testele, este necesar s a se scrie un test driver care s a genereze datele de test si s a execute testele nl ant uit.
121
Problema care se pune este n ce m asur a testele propuse sunt suciente. Intuit ia ne spune c a exist a o zon a sensibil a, unde se pot frecvent face gre seli de programare si anume la limita dintre dou a clase de echivalent a. Aceast a problem a va abordat a n subsect iunea urm atoare. Exemplul 2: Se consider a un program care analizeaz a dac a 3 segmente de dreapt a cu lungimile a, b si c pot forma un triunghi. In acest caz specicat ia de proiect este destul de s arac a n informat ii explicite care s a permit a identicarea claselor de echivalent a. Din aceast a cauz a vom apela la cunu stint ele de geometrie plan a. In primul r and este obligatoriu ca a>0, b>0 si c>0. In al doilea r and trebuie s a e ndeplinite simultan cele trei condit ii de existent a a unui triunghi: a+b>c a+c>b b+c>a Mult imea valorilor reale strict pozitive care ndepline ste si ultimile 3 condit ii formeaz a clasa de echivalent a a valorilor valide. Se observ a c a n acest caz nu putem pune n evident a intervale de valori valide pentru ecare variabil a, ci triplete de valori care ndeplinesc mpreun a anumite condit ii. Orice triplet de valori reale care ncalc a cel put in una dintre cele 6 condit ii apart ine clasei de echivalent a a valorilor invalide. Aceast a clas a de valori invalide poate ranat a pentru a putea pune n evident a mai multe cazuri de test utile. Clasele de echivalent a luate n considerare sunt prezentate n tabelul 6.3 iar cazurile de test derivate din acestea sunt cele din Figura 6.4.
S i n acest caz se observ a c a pot s a apar a probleme la limita ntre clasa valorilor valide si clasele valorilor invalide, neluate n considerare de aceast a metod a, care vor abordate n subsect iunea urm atoare. Avantajele metodei elimin a necesitatea unor teste exhaustive, de cele mai multe ori imposibil de realizat;
122
Tabela 6.3: Tabelul claselor de echivalent a pentru testarea programului aferent exemplului 2. vEC desemneaz a o clas a de echivalent a pentru valori valide iar iEC reprezint a o clas a de echivalent a pentru valori invalide. Clase de Descriere Valori echivalent a reprezentative vEC11 a > 0, b > 0, c > 0 a=3, b=4, c=5 a + b > c, b + c > a, c + a > b iEC21 a0 a=-3, b=4, c=5 iEC22 b0 a=3, b=-4, c=5 iEC23 c0 a=3, b=4, c=-5 iEC31 a+bc a=5, b=10, c=20 iEC32 b+ca a=5, b=20, c=10 iEC33 c+ab a=20, b=5, c=10
Tabela 6.4: Tabelul cazurilor de test pentru testarea programului aferent exemplului 2, obt inute prin metoda partit ion arii n clase de echivalent a. Caz test a b c Rezultat TC1 3 4 5 segmentele pot forma un triunghi TC2 -3 4 5 segment de lungime negativa! TC3 3 -4 5 segment de lungime negativa! TC4 3 4 -5 segment de lungime negativa! TC5 5 10 20 segmentele nu pot forma un triunghi TC6 5 20 10 segmentele nu pot forma un triunghi TC7 20 5 10 segmentele nu pot forma un triunghi
ndrum a testorul s a selecteze un subset de intr ari de test cu o mare probabilitate de a detecta defecte; permite testorului s a acopere un domeniu foarte larg de intr ari/ie siri cu un set relativ mic de date, selectat din clasele de echivalent a; poate utilizat a nc a din primele faze ale ciclului de viat a al proiectului; nu necesit a cuno stin e de programare; este u sor de nt eles si utilizat;
6.2. METODE VVT FUNCT IONALE DE BAZA poate aplicat a pentru testarea oric arui tip de produs.
123
Problemele apar la identicarea corect a a claselor de echivalent a. O abordare posibil a const a n utilizarea unui set de a sa numite condit ii interesante, identicate din specicat iile pentru sistemul testat.
6.2.2
Metoda analizei valorilor limit a
Poate considerat a ca un supliment la metoda partit ion arii n clase de echivalent a, av and ca scop s a pun a n evident a ce se nt ampl a la limita ntre clase. Evident, metoda se va aplica numai dup a punerea n evident a a claselor de echivalent a dar generarea cazurilor de test se va face pentru ecare dintre metode separat. Recomand ari Dac a o condit ie este specicat a ca un interval de valori, se vor dezvolta cazuri de test valide pentru ecare dintre valorile de la capetele intervalului si cazuri de test invalide pentru valori foarte apropiate de acestea (vezi diagrama din Figura 6.1). Dac a o condit ie de intrare este specicat a ca un num ar de valori admise, se vor alege obligatoriu dou a cazuri de test valide pentru nmin si nmax si dou a cazuri de test invalide pentru nmin-1 respectiv nmax+1. Dac a o condit ie este specicat a sub forma unui set ordonat/matrice de valori admise, se vor alege obligatoriu cazuri de test pentru primul si ultimul element.
Figura 6.1: Analiza valorilor limit a pentru o clas a de echivalent a valid a de tip interval.
124
Exemplu Se va considera Exemplul 1 de la metoda partit ion arii n clase de echivalent a. Folosind informat iile din Tabelul 6.1, vom completa tabelul 6.2 cu cazurile de test corespunz atoare valorilor limit a pentru variabilele numar zile si datorie (vezi Tabelul 6.5). Domeniul valorilor valide pentru variabila numar zile este un interval cu o singur a limit a nit a, deci vom analiza doar valoarea 0. Am considerat c a valoarea invalid a numar zile=-5 este destul de apropiat a de limita inferioar a, deci am renunt at la cazul de test pentru numar zile=-1. Pentru variabila datorie, au fost introduse dou a cazuri de test pentru valorile limit a (1000, 20000) si dou a cazuri de test pentru valorile invalide cele mai apropiate de valorile limit a (999, 20001). Observat ie Setul de teste poate completat si cu alte cazuri, de exemplu testarea react iei programului la introducerea unei valori nenumerice pentru cele dou a variabile.
125
Tabela 6.5: Tabelul cazurilor de test pentru testarea programului aferent exemplului 1, obt inute prin metoda partit ion arii n clase de echivalent a si completate cu cazurile de test rezultate n urma analizei valorilor limit a. Caz test numar zile datorie Rezultat TC1 15 10000 150 TC2 60 10000 6000 TC3 100 10000 10000 TC4 -5 10000 Atentie! data invalida TC5 15 500 Atentie! data invalida TC6 15 200000 Atentie! data invalida TC7 60 500 Atentie! data invalida TC8 60 200000 Atentie! data invalida TC9 100 200000 Atentie! data invalida TC10 100 500 Atentie! data invalida TC11 0 10000 0 TC12 15 1000 15 TC13 15 999 Atentie! data invalida TC14 15 20000 300 TC15 15 20001 Atentie! data invalida
Analiza valorilor limit a pentru cel de-al doilea exemplu din subsect iunea 6.2.2 este l asat a ca tem a pentru cititor.
6.2.3
Metoda grafurilor cauz a-efect
Grafurile cauz a-efect reprezint a o tehnic a ce permite combinarea condit iilor si derivarea unui set ecient de cazuri de test care pot descoperi inconsistent e n specicat iile programelor. Dezavantajul metodei este acela c a, spre deosebire de metodele precedente, nu poate utilizat de oricine, deoarece necesit a anumite cuno stinte de algebr a boolean a si funct ii de comutat ie. Suplimentar, dezvoltarea unui graf complet n cazul unor module complexe, cu multe combinat ii ale intr arilor, este dicil a si mare consumatoare de timp. Pentru a putea genera cazurile de test, graful poate transformat ntr-un tabel de decizie. Pentru dezvoltarea cazurilor de test folosind graful cauza-efect, trebuie parcurse urm atoarele etape:
126
1. Specicat iile unei componente complexe sunt descompuse n unit a ti de nivel mai sc azut. 2. Pentru ecare unitate se vor identica cauze si efecte precum si relat iile logice dintre acestea. O cauz a este o condit ie de intrare distinct a sau o clas a de echivalent a a condit iilor. Un efect este o condit ie de ie sire sau o transformare a sistemului. 3. Din informat iile de la punctul precedent se creaz a un graf boolean cauz a-efect. Nodurile grafului sunt formate din cauze (st anga) si efecte (dreapta). Un arc simbolizeaz a o relat ie cauz a-efect Leg atura logic a dintre relat ii se marcheaz a printr-un operator logic (Figura 6.2). 4. Graful este convertit intr-un tabel de decizie. Liniile din zona superioar a corespund condit iilor iar cele din zona inferioar a efectelor (act iunilor). Fiecare coloan a genereaz a o regul a. Fiecare celul a din zona superioar a poate cont ine 1 (condit ia particip a la generarea efectului), 0 (condit ia negat a particip arii la generarea efectului) sau (nesemnicativ, nu particip a la generarea efectului). Fiecare celul a din zona inferioar a cont ine 1 n linia corespunz atoare efectului analizat si 0 n rest. 5. pentru ecare act iune se genereaz a o regul a sub forma unui termen P sau a unei sume de termeni P. Un termen P este generat pentru coloana n care n linia act iunii apare 1. Un termen P este un produs logic de condit ii n form a direct a dac a pe coloana corespunz atoare termenului apare 1 n dreptul condi tiei si n form a complementat a dac a apare 0. 6. Fiecare regul a este convertit a ntr-un caz de test prin alegerea unui set de valori reprezentative.
127
Figura 6.2: Exemple de grafuri cauz a - efect.
Exemplul 3: S a e testat programul care primind la intrare 3 valori strict pozitive a,b,c determin a dac a acestea sunt laturile unui triunghi scalen, isoscel sau echilateral. Analiz and din punct de vedere matematic exemplul propus, rezult a imediat c a putem pune n evident a cauzele si act iunile din Figura 6.3. Pe baza acestor informat ii poate construit graful boolean cauz a-efect din Figura 6.4. iar n nal tabelul de decizie din Figura 6.5. Folosind acest tabel pentru ecare act iune poate generat a o regul a sub forma unor expresii booleene. Pentru exemplul considerat, vor rezulta 6 reguli ce cont in 14 termeni P (Figura 6.6). Este foarte important cum interpret am o regul a. Astfel regula R1 se va citi: dac aa=b si a = c si b=c, se va a sa triunghi oarecare iar regula R2 va citit a ca: dac a a=b si a=c si b=c sau a=b si a=c si b=c sau a=b si a=c si b=c, se va a sa triunghi isoscel. Pentru ecare termen P din regulile generate la pasul anterior se vor genera unul sau mai multe cazuri de test (vezi Tabel 6.7). Pentru ecare dintre condit iile C7, C8, C9, C10, C11, C12 pot generate c ate dou a cazuri de test (unul pentru < si cel alalt pentru =), din aceast a
128
Figura 6.3: Cauze si act iuni care pot determinate pentru Exemplul 3.
cauz a au fost generate n total 20 cazuri de test.
129
Figura 6.4: Graful boolean cauz a - efect pentru Exemplul 3, bazat pe informat iile din Figura 6.3.
130
Figura 6.5: Tabelul de decizie pentru Exemplul 3, bazat pe diagrama cauz a efect din Figura 6.4.
131
Figura 6.6: Regulile deduse pentru Exemplul 3.
132
Figura 6.7: Cazurile de test deduse pentru Exemplul 3.
133
6.2.4
Testarea tranzit iei st arilor unei ma sini de stare nite
In multe situat ii dinamica unui sistem depinde at at de valorile curente ale intr arilor c at si de ntreaga evolut ie anterioar a, materializat a la un moment dat prin starea sistemului. Starea desemneaz a o congurare intern a a unui sistem sau a componentei unui sistem la un moment dat. Starea este denit a de valorile variabilelor de stare adic a a variabilelor care prin valorile lor descriu sintetic o anumit a stare. Observat ie! Starea este un concept specic activit a tii proiectant ilor de sisteme. Utilizatorul obi snuit nu are de obicei acces la variabilele de stare si nici nu l intereseaz a. Sistemele de calcul dar si multe alte sisteme conduse cu ajutorul sistemelor de calcul pot modelate relativ simplu folosind teoria automatelor nite (Finit State Machine- FSM). Implementarea FSM poate realizat a at at hardware c at si software, la ora actual a ind frecvent folosite variante mixte software/hardware. In general, atunci c and se a a ntr-o anumit a stare, sistemul va realiza anumite act iuni specice si va produce anumite ie siri. Tranzit ia reprezint a o relat ie ntre dou a st ari. Aceastu a relat ie ne arat a c a atunci c and apare un anumit eveniment si sunt ndeplidite anumite condit ii, prima stare trece n a doua stare. Evolut ia sistemului este prezentat a idealizat (f ar a luarea n considerare a nt arzierilor) prin diverse tipuri de diagrame de stare. Acestea descriu evolut ia intern a a sistemului, de obicei invizibil a pentru utilizator. In cazul sistemelor articiale, pot puse n evident a trei tipuri de superst ari [1]: starea init ial a pe durata c areia se realizeaz a alimentarea si init ializarea sistemului; starea operat ional a pe durata c areia c areia sistemul realizeaz a act iunile caracteristice; starea nal a c and sistemul realizeaz a toate act iunile pentru ncheierea activit a tii si trece ntr-o stare de repaos sau se deconecteaz a de la sursa de energie.
134
Observat ie! Pe durata unei superst ari pot avea loc evolut ii complexe ale sistemului prin tranzit ia n mai multe st ari. De exemplu, pe durata deconect arii unui sistem de calcul pot salvate cont inuturile unor siere, apoi nchiderea sierelor, salvarea unor informat ii de tip log, dialoguri cu operatorul, deconectarea de la periferice etc. Diagrama de stare a FSM descrie st arile prin care poate trece sistemul descris pe durata existent ei sale, comportamentul pe durata st arii, si evenimentele care determin a modicarea st arii. St arile reprezint a comportamentul specic al unei clase sau al unui sistem iar tranzit iile reprezint a procesele prin care o clas a sau un sistem si modic a funct ionarea. Mai precis, tranzit iile trebuie s a specice circumstant ele n care comportamentul clasei/sistemului trebuie s a se modice, calea ntre dou a st ari, condit iile logice (calicatorii) care trebuie satisf acute pentru a putea realiza o anumit a tranzit ie precum si orice condit ie care blocheaz a tranzit ia (garda). Observat ie! Diagrama de evolut ie a st arilor trebuie s a fac a parte din documentat ia pentru specicarea unit a tii analizate. Evenimentele sunt denite ca o clas a care declan seaz a modicarea st arii sau realizarea unor operat ii ale sistemului. Evenimentele pot s a apar a ca r aspuns la anumite evenimente externe sau ca urmare a unei act iuni a sistemului sau pot generate periodic, cu ajutorul unui ceas (timer). Aparit ia unui eveniment poate luat a n considerare la intrarea ntr-o stare sau la ie sirea dintr-o stare. Un eveniment poate activa o stare, poate genera un alt eveniment, sau poate determina anumite act iuni. Un eveniment poate s a reecte modicarea unei condit ii sau marcheaz a scurgerea unui anumit interval de timp. FSM sunt frecvent utilizate pentru a modela funct ionarea unor sisteme complexe, de tipul sisteme nglobate cu funct ionare n timp real (real-time embedded systems). Testarea nu se poate reduce doar la parcurgerea tuturor st arilor deoarece aceasta ar nsemna c a o mare parte a tranzit iilor nu pot vericate. Idealul ar testarea tuturor tranzit iilor, dar n anumite situat ii acest lucru este practic imposibil datorit a efortului de calcul prea mare. De asemenea, pentru ecare stare/tranzit ie trebuie testat a cel put in odat a ecare act iune ata sat a. Dicultatea test arii este m arit a de faptul c a, dac a sistemul nu a fost implementat cu facilit a ti de testare, corectitudinea evolut iei poate
6.2. METODE VVT FUNCT IONALE DE BAZA evaluat a numai prin vizualizarea ie sirii. Teste tipice pentru FSM sunt[1]: teste pentru vericarea corectitudinii init ializ arii;
135
teste pentru act iuni gre site - o act iune ata sat a unei tranzit ii lipse ste sau nu este corect a; teste pentru erori ale calicatorilor - condit iile de calicare pentru o act iune nu sunt specicate corect sau nu sunt generate corect; teste pentru depistarea nespecic arii unor tranzit ii sau evenimente este posibil ca pentru o anumit a stare s a nu e specicate toate evenimentele care provoac a tranzit ii sau tranzit ia s a nu e descris a corect; teste pentru depistarea unor evenimente nea steptate care provoac a c aderea sistemului; teste pentru depistarea unor st ari lips a sau unor st ari suplimentare gre sit introduse; teste pentru depistarea erorilor n denirea st arii urm atoare. teste pentru tranzit ii false - un eveniment valid provoac a tranzit ia unei st ari de si nu ar trebui s a aib a nici un efect. Testarea tranzit iei st arilor poate realizat a la nivel de specicat ie, component a, integrare sau sistem. Exemplul 4: Se va testa funct ionarea unui Generator de bit de paritate par a serial (GBPPS) care prime ste un sir de bit i divizat n grupe de 4 bit i. Fiecare grup are structura uuux unde uuu reprezint a bit ii utili care vor trece nemodicat i iar x este un bit redundant, care va nlocuit cu bitul de control la paritate par a calculat pe baza bit ilor din secvent a util a. Schema bloc a GBPPS este cea din Figura 6.8 iar evolut ia schemei se desf a soar a conform diagramei de stare din Figura 6.9. Analiz and diagrama de evolut ie a st arilor se observ a c a num a rul de teste ce trebuie efectuate est nit si sucient de mic deoarece coincide cu num arul combinat iilor de lungime n (n lungimea unui grup de bit i). Pentru cazul analizat sunt suciente 16 cazuri de test, ca cele din tabelul din Figura 6.10. Cele 16 teste pot realizate ca un singur test aplic and succesiv toate cele 16 secvent e de intrare.
136
Figura 6.8: Schema bloc pentru circuitul GBPPS din Exemplul 5.
Figura 6.9: Diagrama de evolui e a st arilor pentru GBPPS din Exemplul 4.
137
Figura 6.10: Cazuri de test propuse pentru GBPPS din Exemplul 4.
Exemplul 5: Trebuie testat a funct ional corectitudinea evolut iei unui recunosc ator de secvent a dinamic care a seaz a pe display cuv antul Uraaaa! ori de c ate ori n sirul de caractere de la intrare se identic a secvent a util a RAC. Ma sina secvent ial a pe baza c areia se realizeaz a programul Java, este de tip Moore. Diagrama de evolut ie a st arilor este prezentat a n Figura 6.11. Testarea static a (simpla vizualizare a diagramei de evolut ie a st arilor) pune n evident a faptul c a nu a fost precizat a starea init ial a si nu exist ao condit ie pentru intreruperea execut iei programului. Ca urmare diagrama va modicat a si va transmis a dezvoltatorului pentru a realiza modic arile necesare. Noua diagram a va avea aspectul din Figura 6.12. Se observ a imediat c a pentru o testare complet a este necesar s a e vericate toate tranzit iile posibile. Testarea este simpl a dac a avem acces la variabilele
138
Figura 6.11: Diagrama de evolui e a st arilor pentru Exemplul 5.
programului si putem urm ari evolut ia st arilor. Dac a ns a nu putem s a stim n care stare se a a ma sina secvent ial a dec at prin efectul de la ie sire, testarea este mult mai dicil a. Vom considera n continuare tocmai aceast a ultim a situat ie. Pentru ma sini de stare nit a simple, ca cea din exemplul dat, secvent a de intrare necesar a test arii poate dedus a direct din graful de stare (Figura 6.14). Pentru testarea ie sirii din program, acesta va mai executat de trei ori, folosind secvent ele de intrare din Figura 6.13. Pentru a simplica punerea n evident a a tuturor c ailor posibile pentru parcurgerea arcelor grafului, acesta poate transformat ntr-un arbore de tranzit ie pe baza urm atoarelor reguli: R ad acina arborelui este starea START. Pentru ecare tranzit ie din graf, rezult a o ramur a distinct a n arbore. Procesul de la pasul anterior se repet a pentru ecare frunz a, p ana c and nu se mai pot genera alte frunze, adic a noua frunz a este o stare deja introdus a n graf sau este stare nal a a programului testat (ie sire). Pentru FSM din Exemplul 4, arborele de tranzit ie care rezult a din diagrama de evolut ie a st arilor din Figura 6.9, arborele de tranzit ie are forma din Figura 6.15. In aceast a diagram a caracterul B este reprezentantul clasei de echivalent a A\{A, C, R, ESC }. Folosind arborele de tranzit ie, putem relativ u sor determina una sau mai multe secvent e de intrare care s a permit a testarea tuturor tranzit iilor din
139
Figura 6.12: Diagrama de evolut ie a st arilor mbun at a tit a pentru Exemplul 5.
Figura 6.13: O secvent a de intrare necesar a test arii prin parcurgerea tuturor st arilor si a majorit a tii tranzit iilor, pentru Exemplul 5.
Figura 6.14: Secvent ele de intrare necesar a test arii ie sirii din program, pentru Exemplul 5.
diagrama de stare. In cazul analizat, rezult a c a folosind secvent a BRBRRABRARACBRACRACESC si secvent ele din Figura 6.12, pot testate toate tranzit iile din diagrama
140
de evolut ie a st arilor atunci c nd nu avem acces dec at la mesajul a sat n starea nal a S3.
Figura 6.15: Arborele de tranzit ie pentru FSM din Exemplul 5.
Folosind secvent ele de test propuse, st arile diagramei vor parcurse n ordinea din Figura 6.16.
141
Figura 6.16: Parcurgerea diagramei de evolut ie a st arilor din Exemplul 5 pe baza secvent ei de test din BRBRRABRARACBRACRACESC. Se observ a c a sunt vericate toate tranzit iile ntre st arile.
Aparent, dac a niciunul dintre testele realizate nu depisteaz a o eroare, am demonstrat c a FSMul analizat funct ioneaz a corect. In realitate am demonstrat doar c a sistemul realizeaz a ceea ce trebuie s a realizeze. Mai r am ane de analizat dac a nu cumva sistemul realizeaz a si lucruri pe care nu ar trebui s a le realizeze. Aceast a sarcin a este mult mai dicil a, av and n vedere at at num arul mare de intr ari posibile c at si num arul mare de tranzit ii care poate specicat pentru ecare stare. Relu and analiza cerint elor formulate init ial se observ a nc a o ambiguitate si anume nu se specic a n clar dac a secvent a util a trebuie s a cont in a numai litere mari sau se accept a si litere mici. Este posibil ca dezvoltatorul s a interpreteze c a secvent a util a poate format a din litere mari sau mici, ceea ce nu corespunde interpret arii testorului. Din aceast a cauz a, se va relua testarea folosind secvent a de intrare brbrrabraracbracracESC. Ulterior va necesar a o discut ie cu beneciarul pentru a l amuri ce a dorit de fapt acesta. O alt a situat ie posibil a, practic imposibil de depistat prin testare funct ional a, const a n introducerea deliberat a de c atre dezvoltator a unei act iuni periculoase activat a de aparit ia n sirul de la intrare a unei anumite secvent e diferite de cea util a.
142
6.2.5
Completitudinea test arii
M asoar a ce procent din num arul total de teste posibile conform unui criteriu ales, au fost executate. Pentru cele 4 metode prezentate anterior, completitudinea poate evaluat a n felul urm ator: Pentru metoda claselor de echivalent a: CEacoperire = (numarCE
testate /numartotal CE )
100
Pentru analiza valorilor limit a: V Lacoperire = (numarV L

testate /numartotal V L )
100
Pentru graful cauz a-efect: Condit ia minim a: ecare coloan a a tabelului de decizie s a e acoperit a de cel put in un caz de test, pentru a putea verica toate condit iile si efectele lor. Pentru metoda test arii tranzit iei st arilor: S a e atinse toate st arile. S a e parcurse toate tranzit iile posibile. S a e testate toate tranzit iile care violeaz a specicat iile.
Capitolul 7
Metode VVT white-box

7.1 Prezentare general a
Testarea white-box (white-box testing) este acea metod a de testare care ia n considerare structura si funct ionarea intern a ale unui sistem sau component a (IEEE, 1990). Testarea white-box mai este cunoscut a ca testare structural a (structural testing), testare limpede (clear box testing ) si testare glass-box (glass box testing). Ultimile dou ariante scot n evident a totala vizibilitate a structurii interne si funct ion arii sistemului testat. In acest capitol se va discuta doar vericarea white-box pentru software dar aceast a analiz a acoper a si vericarea proiectelor hardware realizate prin descrierea circuitului cu ajutorul unui HDL. Spre deosebire de tehnicile black-box aplicate unor unit a ti funct ionale de c atre alte persoane dec at dezvoltatorii, tehnicile white-box sunt utilizate cu prec adere de dezvoltatori. Utiliz and tehnicile white-box, un dezvoltator de software poate proiecta cazuri de test care permit: 1. parcurgerea unor trasee independente prin program; 2. vericarea unor decizii logice at at pe ramura TRUE c at si pe ramura FALSE; 3. execut ia unor cicluri; 4. vericarea unor structuri de date interne pentru validarea lor. Testarea white-box este utilizat a pentru trei tipuri de testare: 143
144
CAPITOLUL 7. METODE VVT WHITE-BOX Testarea unit a tilor (unit testing). Prin unitate vom nt elege o component a software sau hardware care nu mai poate descompus a n alte componente. Testarea unit a tilor permite testarea unei componente sau a unui grup de componente care interact ioneaz a. Testul are ca scop s a pun a n evident a dac a funct ionarea componentei este conform a cu specicat iile. n cazul softwareului corectitudinea codului nu este garantat a doar de lipsa erorilor de compilare. Este obligatorie si realizarea altor teste care s a verice corectitudinea execut iei codului n diverse condit ii. Acest tip de testare este obligatoriu n ainte de a trece la faza de integrare a componentelor, deoarece dup a integrare localizarea erorilor este mult mai dicil a. Unii autori apreciaz a c a peste 60% din erori pot detectate prin testarea unit a tilor, dac a aceasta este realizat a corect, cu responsabilitate. Teste de integrare(integration testing). Au ca scop s a pun a n evident a cum se comport a diverse unit a ti atunci c nd sunt obligate s a lucreze mpreun a si interact ioneaz a n condit ii impuse. Testele de integrare pot de tip black-box sau white-box. n primul caz, cel care genereaz a cazurile de test stie ce componente interact ioneaz a dar nu cunoa ste detalii privind interfet ele dintre acestea. In al doilea caz, cazurile de test au ca scop vericarea explicit a a interfet elor ntre componente. Teste de regresie(regression testing). Presupune reluarea selectiv a a testelor asupra unui sistem pentru a verica c a modicarea unei componente nu a afectat n mod nedorit funct ionalitatea componentei. Este bine cunoscut c a eliminarea unei erori poate s a pun a n evident a alte erori mascate anterior de eroarea eliminat a. De asemenea este posibil ca modic arile necesare elimin arii erorii s a e f acute doar part ial sau, si mai grav, s a e realizate acolo unde nu trebuie din neatent ie ori pentru c a programatorul nu a nt eles semnicat ia erorii. Testele de regresie pot de tip black-box sau white-box sau o combinat ie a lor. Pentru a simplica activitatea de testare, se recomand a salvarea cazurilor de test aplicate unit a tilor si cazurile de test pentru integrare, urm and ca acestea s a e refolosite ori de c ate ori este necesar ca teste de regresie.
Principalele tehnici white box sunt: metoda fumului acoperirea instruct iunilor;
7.2. METODA FUMULUI acoperirea ramurilor; testarea condit iilor: testarea condit iilor de ramicare; testarea combinat iilor condit iilor de ramicare; acoperirea c ailor.
145
Pentru a u sura depistarea cazurilor de test, se utilizeaz a de obicei scheme logice (owchart) sau diagrama de control al uxului prelucr arilor.
7.2
Metoda fumului
Este o metod a foarte simpl a, aplicat a n aintea oric arui alt test. Obiectivul testului este de a vedea dac a sistemul este funct ional si funct ionarea sa nu are efecte colaterale periculoase. Denumirea vine de la o tehnic a foarte veche utilizat a pentru vericarea etan seit a tii tevilor folosite la aprovizionarea cu ap a a ora selor. Aceast a metod a se utilizeaz a si azi, de exemplu pentru vericarea ret elelor pentru distribuirea gazului metan c and n loc de fum se introduce pe conducte aer sub presiune si se m asoar a presiunea la cel alalt cap at. In cazul test arii software se veric a dac a programul poate lansat n execut ie, dac a utilizatorul se poate conecta, dac a poate primi date si nu blocheaz a alte programe cu care interact ioneaz a. In cazul test arii hardware se testeaz a dac a dispozitivul testat este alimentat si nu apar efecte nedorite (scurtcircuite, supra nc alzirea unor componente, defecte intermitente datorate unor conexiuni proaste, generarea unor semnale periculoase pentru alte componente ale sistemului etc.).
7.3
Acoperirea instruct iunilor
Se mai nume ste si acoperire C0. Urm are ste executarea tuturor instruct iunilor din unitatea testat a, n scopul depist arii unor zone de cod mort, care nu pot accesate. Un astfel de test este util n special n cazul unor programe scrise n limbaj de asamblare c and instruct iunile care urmeaz a dup a un salt necondit ionat pot s a r am an a neapelate ( nu exist a un salt la instruct iunea imediat urm atoare instruct iunii de salt necondit ionat).
146
CAPITOLUL 7. METODE VVT WHITE-BOX
7.4
Acoperirea ramurilor
Parcurgerea tuturor instruct iunilor nu este sucient a n toate cazurile. Este posibil ca n anumite situat ii unele ramuri s a nu cont in a nici o instruct iune si cel care face testele s a e tentat s a neglijeze vericarea ramurilor f ar a instruct iuni. Aceasta nseamn a ns a c a nu sunt testate complet condit iile de ramicare, ceea ce poate conduce la imposibilitatea descoperirii unor erori. Atent ia trebuie concentrat a pe parcurgerea tuturor deciziilor at at pentru valoarea TRUE c at si pentru valoarea FALSE. In cazul unei instruc tiuni IF trebuie testate at at ramura THEN c at si ramura ELSE. In cazul instruc tiunilor case, switch se testeaz a toate variantele de decizie posibile In cazul ciclurilor, se testeaz a obligatoriu trecerea prin corpul ciclului dar si ntoarcerea la prima instruc tiune din corpul ciclului. Se va tine cont de tipul de instruct iune folosit a pentru implementarea ciclului (while, until sau for). Ciclurile until sunt executate cel put in odat a n timp ce pentru ciclurile while si for exist a cazuri n care ciclul nu este parcurs niciodat a. Apare o anumit a redundant a datorit a necesit a tii de a parcurge anumite ramuri in cadrul mai multor teste, dar acest lucru nu poate in general evitat. Nivelul de acoperire al unui test sau al unui grup de teste este calculat cu relat ia: Acoperirea ramurilor = (Num arul ramurilor testate/Num arul total al ramurilor)*100% Este un criteriu mai bun dec at acoperirea instruct iunilor, deoarece garanteaz a si acoperirea acestora, dar pret ul de cost este mai mare. Permite testarea tuturor condit iilor simple dar nu implic a neap arat testarea condit iilor complexe.
7.5
Testarea condit iilor complexe
Prin condit ie complex a nt elegem un predicat format din mai multe expresii relat ionale (condit ii atomice) reunite prin operatori logici. Exemple:
7.5. TESTAREA CONDIT IILOR COMPLEXE
147
5 <= nota labAN D5 <= nota examen 1 <= notaAN Dnota <= 10 Fiecare predicat trebuie testat separat. Dac a predicatele sunt unite prin operatorul logic AND, pentru a testa predicatul Pi toate celelalte predicate trebuie s a aib a valoarea TRUE. Dac a predicatele sunt unite prin operatorul logic OR, pentru a testa predicatul Pi toate celelalte predicate trebuie s a aib a valoarea FALSE. Dac a predicatele sunt unite prin operatorul logic XOR (excluziune mutual a), testarea unuia dintre predicate se va face odat a pentru valoarea FALSE a celui de-al doilea predicat si odat a pentru valoarea TRUE a celui de al doilea predicat ( n total 4 cazuri de test pentru ecare predicat). In cazul unor predicate care cont in paranteze, se analizeaz a predicatul din ecare parantez a si apoi se consider a leg aturile ntre paranteze. O alt a variant a const a n transformarea predicatului init ial ntrun predicat n form a normal disjunctiv a (sum a logic a de produse de predicate). Fiecare produs se testeaz a fort and celelalte produse la valoarea FALSE. Pentru ecare predicat simplu din produs sunt necesare dou a cazuri de test si ment inerea celorlalte predicate simple n starea TRUE. Este posibil ca unele dintre cazurile de test s a coincid a, deci num arul nal de cazuri de test selectate va mai mic dec at cel estimat pe baza acestei analize. Exemplu: Pentru a nt elege diferent a ntre acoperirea ramurilor si testarea condit iilor complexe, vom considera instruct iunea: if (x <= 5 or x > 20) and y < 15 then . . . else . . . end if ; Dac a se dore ste doar acoperirea ramurilor, sunt necesare doar dou a cazuri de test, unul pentru condit ie TRUE iar cel alalt pentru condit ie FALSE. De exemplu putem considera x=3,y=10 respectiv x=10, y=10. Testarea condit iilor complexe necesit a o analiz a mult mai detaliat a. Not and P1 = x <= 5, P2 = x > 20 si P3 = y < 15, condit ia de test poate scris a ca:
148
P=(P1 or P2 ) and P3 . Cazurile de test necesare test arii complete a acestui predicat pot deduse pe baza informat iilor din Tabela 7.1. Se observ a Tabela 7.1: Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei. Caz test P1 P2 P3 P TC1 TRUE FALSE TRUE TRUE TC2 FALSE FALSE TRUE FALSE TC3 FALSE TRUE TRUE TRUE TC4 FALSE FALSE TRUE FALSE TC5 FALSE FALSE TRUE FALSE TC6 FALSE FALSE FALSE FALSE
imediat c a TC2, TC4 si TC5 sunt identice, deci n nal sunt necesare doa 4 cazuri de test (TC1, TC2, TC3 si TC6). La cele 4 cazuri de test mai pot ad augate cazurile de test rezultate din analiza valorilor limit a. Pentru exemplul considerat este important s a test am separat cazurile x=5, x=20 respectiv y=15.
7.6
Acoperirea c ailor independente
Num arul c ailor independente dintr-un program se pot determina u sor din schema logic a simplicat a a programului. Aceasta este un graf orientat care cont ine laturi (blocuri de instruct iuni executate secvent ial) si noduri care corespund elementelor de decizie. Dac a toate elementele de decizie sunt binare (au o ie sire pentru TRUE si o ie sire pentru (FALSE)), pentru un graf cu n noduri vor exista n+1 c ai independente. Num arul c ailor independente reprezint a num arul minim de cazuri de test necesar parcurgerii tuturor nodurilor si ramurilor (deci acoperirea tuturor instruct iunilor precum si testarea tuturor condit iilor simple, dar pentru condit iile complexe este necesar a o analiz a de tipul celei prezentate n sect iunea precedent a. Pentru a nt elege mai bine aceast a metod a vom considera urm atorul exemplu: Exemplul 1 Se consider a un program care returneaz a valoarea funct iei f(x,y)= x+y dac a x2 + y 2 < R 2 , xy dac a x2 + y 2 = R 2 ,
7.6. ACOPERIREA CAILOR INDEPENDENTE x+y dac a x2 + y 2 > R2 . Programul pseudocod pentru evaluarea funct iei este cel din Figura 7.1. Analiz and static acest program, putem formula urm atoarele observat ii:
149
Nu apare vericarea faptului c a raza unui cerc este un num ar real pozitiv. Nu apar comentarii ceea ce va ngreuna nt elegerea programului de c atre programator. Pe baza acestor observat ii programul pseudocod poate modicat n forma din Figura 7.2. Schema logic a aferent a programului este cea din Figura 7.3.
Figura 7.1: Programul pseudocod pentru rezolvarea problemei din Exemplul 1. In Figura 7.4 apare schema logic a simplicat a (f ar a specicarea instruct iunilor executate). Vom utiliza aceast a diagram a pentru determinarea testelor white-box. Num arul c ailor independente prin program se poate determina cu relat ia ai independente=n+1 unde n este num arul nodurilor din dianum ar c gram a adic a num arul elementelor de decizie. Pentru exemplul considerat se observ a c a num ar c ai independente=3+1=4. Cele 4 c ai independente sunt: a - b - d - h; a - b - e - f - h;
150
Figura 7.2: Programul pseudocod corectat pentru rezolvarea problemei din Exemplul 1.
a - b - e - g - h; a - c. In continuare vor determinate cazurile de test white-box care permit parcurgerea celor 4 c ai puse n eviden t a anterior. Pentru aceasta se vor determina 4 seturi de valori reprezentative ale variabilelor x, y, R precum si rezultatul a at n ecare caz, ca n Tabela 7.2. Analiz and cazurile de test obt inute se observ a c a ele permit realizarea tuTabela 7.2: Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei din Exemplul 1. Caz test a b R f TC1 1 2 5 3 TC2 3 4 5 12 TC3 -4 6 5 -10 TC4 2 3 -5 Raza negativ a sau 0!!!
turor tipurilor de teste white-box prezentate anterior. Totu si, pentru a cre ste certitudinea funct ion arii corecte a programului este necesar a si efectuarea unor teste black-box deduse din analiza limitei ntre clasele de echivalent a.
7.6. ACOPERIREA CAILOR INDEPENDENTE
151
Figura 7.3: Schema logic a aferent a programului din Figura 7.2.
Se observ a din denirea problemei c a exist a trei clase de echivalent a (interiorul cercului, circumferint a cercului si exteriorul cercului).Limita ntre cele trei clase de echivalent a o reprezint a circumferint a cercului. Deoarece testarea unui punct pe circumferint a este realizat a de testul TC2, mai este necesar s a e introduse dou a cazuri de test pentru dou a puncte n vecin atatea circumferint ei, unul n interior si cel alalt n exterior. Cele dou a cazuri de test sunt prezentate n Tabela 7.3. Tabela 7.3: Tabelul cazurilor de test black-box bazate pe analiza valorilor limit a pentru problema din Exemplul 1. Caz test a b R f TC5 2.999 4 5 6.999 TC6 3.001 4 5 -0.999
152
Figura 7.4: Schema logic a simplicat a aferent a programului din Figura 7.2.
7.7
Testarea ciclurilor
Pentru testarea corect a a unui ciclu este necesar ca: s a e parcurs cel put in odat a corpul ciclului; s a se verice c a are loc ciclarea, adic a execut ia permite revenirea la prima instruct iune a ciclului. Exemplul 2 Se consider a un program care returneaz a tabelul cu valorile funct iei f(x) pentru 1000 de valori ale variabilei x ntr-un domeniu precizat prin limitele a respectiv b. Pasul de tabelare se va calcula cu relat ia pas = |a b|/1000. Funct ia tabelat a este f (x) = (x2 1)/(x 2). Presupunem programul scris n pseudocod sub forma din Figura 7.5. Se observ a imediat c a sunt trei c ai independente si anume: a-b-d-f-c; a-b-e-f-c; a-c.
7.7. TESTAREA CICLURILOR
153
Figura 7.5: Programul pseudocod pentru rezolvarea problemei din Exemplul 2.
Figura 7.6: Schema logic a simplicat a pentru programul aferent problemei din Exemplul 2.
154
Pe baza acestui program putem genera schema logic a simplicat a ca n Figura 7.6. Pentru a parcurge cele 3 c ai independente sunt necesare cazuri de test, ca cele propuse n Tabela 7.4. Se observ a c a valorile de test pentru a si b au Tabela 7.4: Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei din Exemplul 2. Caz test a b f TC1 3 3 8 TC2 2 2 pentru x=2 divizare la 0! TC3 5 3 nu se a seaz a nimic
fost astfel alese nc at corpul ciclului s a e parcurs o singur a dat a, ceea ce simplic a testarea. Cele trei teste permit: Parcurgerea tuturor nodurilor. Testarea tuturor instruct iunilor. Testarea tuturor condit iilor. Testarea ciclului. O alt a variant a pentru determinarea c ailor independente ale grafului const a n utilizarea grafului de control al uxului prelucr arilor din Figura 7.7. Fiecare nod corespunde nceputului respectiv sf ar sitului unei instruct iuni de decizie iar ecare arc uneia dintre ramurile deciziei. Suplimentar exist a un nod de start si cel put in un nod de ie sire ( vezi Figura 7.7). In acest caz num arul c ailor independente se calculeaz a folosind formula pentru calculul complexit a tii McCabe, adic a: M=E-N+2P unde: M - valoarea complexit a tii McCabe; E - num arul arcelor (edges); N - numarul nodurilor (nodes); P - num arul nodurilor de ie sire (exit nodes).
155
Figura 7.7: Diagrama de control al uxului pentru rezolvarea problemei din Exem-plul 2.
Pentru exemplul considerat M=7-6+2=3 c ai independente (acela si rezultat ca si cel obt inut folosind schema logic a simplicat a a programului). In continuare analiza pentru determinarea cazurilor de test se realizeaz a ca si n varianta precedent a. Condit ia a b este de fapt o condit ie complex a put and scris a ca a < b or a = b. Inseamn a c a este necesar s a se introduc a si un caz de test pentru a < b. De exemplu se poate alege a=3, b=5. In acest caz ciclul este parcurs de 1000 de ori ceea ce complic a testarea. Dac a testarea este realizat a de dezvoltator, pentru a simplica testarea se poate modica formula de calcul a pasului astfel nc at s a poat a a sate doar 3 valori (dou a
156
la capetele intervalului si una n centrul intervalului). Pentru a=3 si b=5 pasul va calculat cu formula pas = |a b|/2. Exemplul 3 Se consider a un program Java (Figura 7.8) pentru determinarea anotimpului lunii introduse de la consol a. Execut ia programului se opret e c and n locul numelui unei luni apare cuv antul stop. Numele lunii se scrie numai cu caractere mici dar cuv antul stop poate scris oricum. Testarea nodurilor si testarea ramurilor sunt acoperite de testarea c ailor si a ciclurilor, deci va trebui s a determin am num arul c ailor independente. Pentru a determina num arul c ailor independente prin acest program, se poate construi graful din Figura 7.9 si apoi aplic am formula pentru calculul complexit a tii McCabe. Analiz and acest graf, se observ a c a putem pune n
Figura 7.8: Programul Java pentru rezolvarea problemei din Exemplul 3.
157
Figura 7.9: Diagrama de control a programului din Figura 7.8. Complexitatea McCabe a acestui program va M=E-N+2=13-9+2=6
evident a 6 c ai independente si anume: 1. a-b-c-d-e; 2. a-b-f-g-d-e; 3. a-b-f-h-d-e; 4. a-b-f-h-j-k-d-e; 5. a-b-f-h-j-l-d-e; 6. a-b-f-h-j-l-d-m.
158
Pe baza informat iilor puse deja n evident a, putem determina foarte u sor cazurile de test pentru parcurgerea celor 6 c ai independente. Cazurile de test propuse apar n Tabela 7.5. Tabela 7.5: Tabelul cazurilor de test pentru parcurgerea c ailor independente din programul pentru rezolvarea problemei din Exemplul 2. Caz test luna rezultat estimat TC1 ianuarie ianuarie este luna de iarna TC2 martie martie este luna de primavara TC3 iunie iunie este luna de vara TC4 octombrie octombrie este luna de toamna TC5 blablabla nu se a seaz a nimic dar se reia ciclul TC6 sToP nu se a seaz a nimic si se opreste executia
Dac a cele 6 cazuri de test sunt executate succesiv pe durata aceluia si apel al programului, rezultatul obt inut va : ianuarie este luna de iarna martie este luna de primavara iunie este luna de vara octombrie este luna de toamna blablabla este luna de toamna sToP este luna de toamna Se observ a imediat c a ultimile dou a teste sunt pozitive adic a rezultatul obt inut este absurd. Aceasta nseamn a c a programul trebuie depanat iar apoi vor reluate toate testele (testare de regresie). Suplimentar vor efectuate si alte teste n funct ie de modul n care au fost rezolvate defectele semnalate anterior. Testele determinate pentru testarea c ailor independente nu asigur a vericarea condit iilor complexe care apar n instruct iunile if. Se observ a imediat c a pentru ecare condit ie trebuie vericate 3 cazuri (unul pentru ecare lun a) deci n total 4*3=12 cazuri de test. Ad aug and la acestea si ultimile dou a cazuri considerate pentru programul original, rezult a necesitatea execut arii a 14 teste.
Capitolul 8
Testarea bazelor de date

8.1 Calitatea informat iei si calitatea datelor
A sa cum s-a aratatat anterior n sect iunea 2.4, exist a deosebiri fundamentale ntre informat ie si date. Aceasta duce n mod natural la ideea unei abord ari diferite a calit a tii informat iei respectiv datelor. Exist a posibilitatea ca date aparent corecte s a conduc a la informat ii gre site, deoarece informat iile sunt rezultatul interpret arii datelor ntr-un anumit context si orice interpretare poate afectat a de erori. Calitatea sc azut a a datelor/informat iilor are un impact negativ semnicativ asupra ntregii activit a ti ntr-o organizat ie. Deoarece datele stau la baza lant ului de valoricare a datelor prezentat n Figura 2.11, rezult a imediat c a orice eroare care afecteaz a ciclul de viat a al datelor va inuent a negativ informat iile derivate din acestea si n nal deciziile bazate pe acestea. Din aceast a cauz a, organizat iile sunt interesate n asigurarea unor m asuri care s a garanteze o calitate corespunz atoare a datelor. Aceste m asuri se refer a n special la bazele de date ale organizat iei care altfel ar acumula continuu date murdare (dirty data), nu numai lipsite de valoare dar chiar periculoase pentru calitatea deciziilor la nivel executiv. Problema dicil a o reprezint a denirea unor indicatori de calitate a datelor obiectivi, u sor de evaluat si interpretat. Conform celor discutate n capitolele 1 si 2, exist a patru moduri de abordare a conceptului calitate : excelent a; valoare; satisfacerea cerint ele impuse; 159
160
CAPITOLUL 8. TESTAREA BAZELOR DE DATE satisfacerea si chiar dep a sirea a stept arilor beneciarilor/utilizatorilor.
Primul mod de abordare este subiectiv, f ar a nici o valoare n procesul de mbun at a tire a calit a tii deoarece ignor a problema costurilor n cre sterea nivelului calit a tii. Denirea calit a tii ca valoare pentru utilizator capteaz a leg atura ntre calitate si pret de cost dar poate s a ignore alte aspecte importante pentru utilizator. Satisfacerea cerint elor este u sor de evaluat dar si n acest caz apare problema n ce m asur a cerint ele exprim a a stept arile beneciarilor/utilizatorilor. Pentru a elimina toate aceste neajunsuri, n lucr arile [30],[31],[33] se dezvolt a modelul PSP/IQ (Product and Service Quality for Information Quality). Modelul este prezentat n Tabela 8.1 si poate u sor pus n corespondent a cu un set de metrici u sor de nt eles si evaluat, bazate at at pe satisfacerea specicat iilor c at si pe ideea satisfacerii si dep a sirii a stept arilor.
Tabela 8.1: Modelul PSP/IQ [33]. satisfacerea specicat iilor Corectitudinea informat iei caracteristicile informat iei livrate corespund standardelor de calitate a informat iei Credibilitatea informat iei procesul de transformare a datelor n informat ie corespunde standardelor satisfacerea si dep a sirea a stept arilor consumatorilor Utilitatea informat iei informat ia livrat a corespunde necesit a tilor consumatorului Utilizabilitatea informat iei procesul de transformare a datelor n informat ie dep a se ste necesit a tile consumatorului
calitatea produselor
calitatea serviciilor
Metricile de calitate a informat iei propuse de autorii modelului PSP/IQ au urm atoarele semnicat ii: accesibilitate - m asura n care informat ia este disponibil a sau poate u sor si repede reg asit a; actualitatea - m asura n care informat ia reect a realitatea la un moment sucient de apropiat fat a de momentul utiliz arii; cantitate corespunz atoare de informat ie - m asura n care volumul de informat ie disponibil corespunde sarcinilor specice;
8.1. CALITATEA INFORMAT IEI S I CALITATEA DATELOR
161
Tabela 8.2: Leg atura modelului PSP/IQ cu metricile informat iei [33]. satisfacerea specicat iilor Corectitudinea informat iei - lipsa erorilor - reprezentare concis a - completitudine - consistent a reprezent arii satisfacerea si dep a sirea a stept arilor consumatorilor Utilitatea informat iei - cantitate corespunz atoare - relevant a - inteligibilitate - interpretabilitatea - obiectivitatea Utilizabilitatea informat iei - credibilitate - accesibilitate - u surint a manipul arii - reputat ie valoare ad augat a
calitatea produselor
calitatea serviciilor
Credibilitatea informat iei - actualitate - securitate
credibilitate - m asura n care informat ia poate considerat a adev arat a sau credibil a; completitudine - m asura n care informat ia este sucient a pentru rezolvarea sarcinilor curente; concizia reprezent arii - m asura n care informat ia consistent a reprezent arii - m asura n care informat ia este reprezentat a ntr-o form a compact a; corectitudinea - m asura n care informat ia este corect a si sigur a n utilizare; inteligibilitatea - m asura n care informat ia din diverse surse este reprezentat a n acela si format; interoperabilitatea - m asura n care informat ia este reprezentat a n limbajul corespunz ator, cu simbolurile si unit a tile de m asur a adecvate iar denit iile sunt clare; manipulabilitatea - m asura n care informat ia este u sor de utilizat n diverse aplicat ii;
162
CAPITOLUL 8. TESTAREA BAZELOR DE DATE obiectivitatea - m asura n care informat ia este generat a n urma unor procese impart iale, repetabile, m asurarea ind f acut a cu mijloace speciale, autorizate; relevant a - m asura n care informat ia este util a pentru rezolvarea unei sarcini precizate; reputat ia - m asura n care informat ia provine dintr-o surs a autorizat a si respectat a; securitatea - m asura n care accesul la informat ie este restrict ionat astfel nc at s a nu poat a distrus a voit sau utilizat a n scopuri necinstite; valoarea ad augat a - m asura n care informat ia produce benecii prin utilizarea sau distribuirea ei;
A sa cum se arat a n [58], n studiul calit a tii bazelor de date apar c ateva probleme specice. In primul r and corectitudinea datelor este foarte greu de demonstrat, mai ales c and este vorba de date aferente unor persoane. Exemplul 1: Un pacient poate declara cu bun a credint a c a n familia lui singura boal a ereditar a cunoscut a este hipertensiunea, dar n realitate el este nat si n familia natural a sunt frecvente bolile psihice. Exemplul 2: Cei care culeg si introduc date nu au practic nici un mijloc de a verica dac a un act este real sau falsicat. Aceast gen de veric ari nu poate realizat dec at de c atre persoane autorizate, cu cheltuieli mari. In al doilea r and calitatea datelor are un caracter dinamic, o dat a corect a n momentul achizit iei poate deveni incorect a n timp relativ scurt. Exemplul 3: O adres a sau un num ar de telefon pot modicate n orice moment. De obicei oamenii nu anunt a astfel de modic ari. Exemplul 4: Numele persoanei se modic a frecvent prin c as atorie/divort . Aceast a situat ie afecteaz a n special medicii de familie care trebuie s a urm areasc a evolut ia pacientului din copil arie p an a n momentul curent. O alt a problem a este legat a de faptul c a transformarea datelor n informat ie ind o problem a de interpretare, este posibil ca date corecte s a nu nsemne ntotdeauna si informat ii corecte.
DE DATE RELAT 8.2. CE TREBUIE VERIFICAT/TESTAT LA O BAZA IONALE163 Exemplul 5: Acelea si simptome pot descrie diverse boli, ceea ce poate conduce la diagnostice gre site.
8.2
Ce trebuie vericat/testat la o baz a de date relat ionale
Corectitudinea cerint elor (testare static a, revizie). Corectitudinea capt arii regulilor de integritate specice a datelor (testare static a). Corectitudinea modelului conceptual (testare static a). Corectitudinea modelelor logice (testare static a). Corectitudinea transform arii modelului conceptual n model relat ional (testare static a). Implic a eliminarea duplicatelor, sinonimelor si omonimelor precum si normalizarea datelor (testare static a). Corectitudinea scripturilor pentru crearea bazei de date si a tabelelor (testare static a si dinamic a). Corectitudinea implement arii regulilor de integritate declarative (testare dinamic a). Posibilitatea folosirii alfabetelor nat ionale (testare dinamic a). Corectitudinea leg aturilor ntre tabele (testare static a si dinamic a). Corectitudinea denirii vederilor (testare static a si dinamic a). Corectitudinea implement arii procedurilor stocate (testare static a si dinamic a). Corectitudinea implement arii funct iilor de utilizator (testare static a si dinamic a). Corectitudinea implement arii triggerelor (testare dinamic a). Corectitudinea implement arii interog arilor (testare static a si dinamic a). Corectitudinea implement arii securit a tii accesului la date (testare dinamic a).
164
CAPITOLUL 8. TESTAREA BAZELOR DE DATE Performant ele funct ie de nc arcare pentru punerea n evident a a calitt ii indec silor (testare dinamic a). Observat ie! Termenul nc arcare se refer a la dou a aspecte: volum de date; numar de utilizatori activi simultan. Teste de stres realizate pentru un volum foarte mare de date si/sau num ar foarte mare de utilizatori n acces concurent. Respectarea cerint elor de securitate a accesului la date. Alocarea drepturilor pentru utilizatori.
8.3
Corectitudinea modelului conceptual
Exist a nc a persoanecare consider a c a a genera modelul conceptual n aintea implement arii bazei de date este o pierdere de vreme, deoarece la ora actual a toat a lumea utilizeaz a modelul relat ional. Acest mod de a g andi denot a ne nt elegerea rolului modelelor conceptuale, acela de a capta semantica datelor independent de modul de utilizare. Ideea c a singurul mod de implementare este cel relat ional se justic a doar pentru bazele de date clasice, dar la ora actual a existe baze de date obiect-relat ionale si baze de date obiectuale cu o sfer a de aplicabilitate bine precizat a. Desigur, un proiect mic cu 10-15 tabele poate realizat direct , f ar a model relat ional dar orice extensie a bazei de date sau integrare ntr-o baz a de date mai mare va ridica probleme serioase. Chiar si tactica gre sit a de a crea modelul conceptual dup a crearea modelului implementabil este mai bun a dec at lipsa oric arui model conceptual. Crearea modelului conceptual este un proces iterativ, laborios, care se bazeaz a pe cerint ele formulate de utilizator put and completat permanent pe baza discut iilor ntre proiectant si utilizator. Este bine ca modelul conceptual s a ofere o perspectiv a c at mai ampl a asupra cont inutului bazei de date, s a nu se m argineasc a la cerint ele actuale ale beneciarului ci s a prevad a si dezvoltarea ulterioar a a bazei de date conform celor discutate n paragraful 8.1. Dac a init ial modelele conceptuale au inclus doar obiectele specice ale bazei de date (clase de entit a ti, atribute, leg aturi, la ora actual a acestea includ si vederile asupra bazei de date din punctul de vedere al diver silor utilizatori. Modelele conceptuale ale bazelor de date sunt n esent a reprezent ari grace ale obiectelor specice bazei de date (cele mai cunoscute ind modelele EER
8.3. CORECTITUDINEA MODELULUI CONCEPTUAL
165
si UML). Pe l ang a reprezent arile grace care capteaz a doar un num ar relativ mic de propriet a ti ale obiectelor bazei de date, modelul conceptual poate include si un glosar n care sunt specicate tipurile de date, lungimea datelor, limba nat ional a utilizat a pentru p astrarea datelor, num arul de entit a ti estimate pentru o clas a de entit a ti, rata actualiz arilor (insert ii, modic ari, elimin ari), num arul estimat de utilizatori cocurent i, aspecte ale securit a tii accesului la date etc. Aceste informat ii pot foarte utile pentru implementarea si administrarea optim a a bazei de date.
166
CAPITOLUL 8. TESTAREA BAZELOR DE DATE
Capitolul 9
Vericarea si testarea proiectelor VHDL
167
168CAPITOLUL 9. VERIFICAREA S I TESTAREAPROIECTELOR VHDL
Bibliograe
[1] Avner Angel: Verication, Validation, and Testing of Engineered Systems, John Wiley & Sons, Inc. (2010); [2] Elizabeth Hull, Ken Jackson, Jeremy Dick: Requirements Engineering Third Edition, Springer-Verlag London Limited (2011); [3] Ionescu Augustin-Iulian: Introducere n analiza si sinteza sistemelor digitale Vol. I, Editura Universitaria, Craiova (2007); [4] Ionescu Augustin-Iulian, Dumitra scu Eugen, Lemeni Ioan: Introducere n analiza si sinteza sistemelor digitale Vol. II, Editura Universitaria, Craiova (2010); [5] John L. Hennessy, David A. Patterson: Computer Architecture A Quantitative Approach Fourth Edition, Elsevier, Inc. (2007); [6] David A. Peterson, John L. Hennessy: Computer Organization and Design 4th Edition, Elsevier, Inc. (2009); [7] Je Tian: Software Quality Engineering, John Wiley & Sons,Inc. (2005); [8] David Hoile: Quality Management Essentials, Elsevier Limited (2007); [9] Agarwal B.B., Tayal, S.P., Gupta M.: Software Engineering $ Testing, Jones and Barlett Publishers, LLC (2010); [10] Andreas Spillner, Tilo Linz, Hans Schaefer: Software Testing Foundations Second Edition, Rocky Nook Inc. (2007); [11] Janick Bergeron: Writing Testbenches: Functional Verication of HDL Models Second Edition, KluwerAcademic Publishers (2003); 169
170
BIBLIOGRAFIE
[12] Fadi P. Deek, James A.M. McHugh, Osama M. Eljabiri: Strategic Software Engineering - An Interdesciplinary Approach, Auerbach Publications, Taylor & Francis Group, LLC (2005); [13] Roger S. Pressman: Software engineering: a practitioners approach Fifth Edition, McGraw-Hill Companies, Inc. (2001); [14] ***: Condensed GSAM Handbook - Februarie www.stsc.hill.af.mil/resources/tech docs/gsam4/chap2.pdf 2003,
[15] Barry W. Boehm: A Spiral Model of Software Development and Enhancement, IEEE Transaction on Computer, May 1988, http://weblog.erenkrantz.com/ jerenk/phase-ii/Boe88.pdf [16] David Sinclair: CA267 - Software Testing - Testing and the Software Lifecycle, http://www.computing.dcu.ie/ davids/courses/CA267/CA267 Lifecycle 2p.pdf [17] ***: The V model student accountant January 2006, http://www.compensationanalytics.com/ resources/vtestingmodel.pdf [18] ***: Software Development Models, http://sqa.fyicenter.com/FAQ/Software-Development-Models/ [19] Aristotel, Categories, tradus n limba englez a de E. M. Edghill, http://classics.mit.edu/Aristotle/categories.mb.txt [20] Joseph M. Juran, Quality Planning and Analysis, McGrowHill, 1970 [21] Thomas J. McCabe, A Complexity Measure, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-2, NO.4, DECEMBER 1976 http://www.literateprogramming.com/mccabe.pdf [22] Philip B. Crosby, Quality is Free, McGraw-Hill, 1979; o prezentare interesant a a acestei lucr ari se gase ste la adresa www.freequality.org/documents/Training/Quality [23] Peter J. Denning, What is Software Quality?,A Commentary from Communications of ACM, January 1992, http://cs.gmu.edu/cne/pjd/PUBS/softqual92.pdf [24] Kitchenham, S. L., Peeger, Software Quality: The Elusive Target, IEEE Software,13(1), 12-21, 1996
BIBLIOGRAFIE
171
[25] Arthur H. Watson, Thomas J. McCabe, Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric, NIST Special Publication 500-235, 1996 http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/title.htm [26] Jer Hogan, An Analysis of OO Software Metrcs, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.6904, 1997 [27] A. J. Sojev, Basis Path Testing,1997 http://users.csc.calpoly.edu/ jdalbey/206/Lectures/BasisPathTutorial/index.html [28] Linda H. Rosenberg, Theodore F. Hammer, Lenore L. Human, Requirements, Testing, and Metrics, In 15th Annual Pacic Northwest Software Quality Conference, 1998, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.7103 [29] Roland Petrasch, The Denition of Software Quality: A Practical Approach, ISSRE, 1999 http://www.chillarege.com/fastabstracts/issre99/99124.pdf [30] Beverly K. Kahn, Diane M. Strong, Product and Service Performance Model for Information Quality: An Update, Information Quality Conference, 1998 http://mitiq.mit.edu/ICIQ/Documents/IQProductServicePerformanceModelforIQ.pdf [31] Omar E. M. Khalil, Diane M. Strong, Beverly K. Kahn, Leo L. Pipino Teaching Information Quality in Information Systems Undergraduate Education, Informing Science, Volume 2 No 3 1999, http://inform.nu/Articles/Vol2/v2n3p53-59.pdf [32] StephenH.Kan, Metrics and Models in Software Quality Engineering, Second Edition, Addison Wesley, 2002 http://www.acs.ase.ro/mcs/Metrics [33] Beverly K. Kahn, Diane M. Strong, and Richard Y. Wang, Information Quality Benchmarks: Product and Service Performance April 2002/Vol. 45, No. 4ve COMMUNICATIONS OF THE ACM, http://web.mit.edu/tdqm/www/tdqmpub/KahnStrongWangCACMApr02.pdf , http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.4752 [34] Yang W. Leea, Diane M. Strongb, Beverly K. Kahnc, Richard Y. Wangd AIMQ: a methodology for information quality assessment, Information & Management 40 (2002) 133146, Elsevier, 2002
172
BIBLIOGRAFIE
[35] John ODonoghue, Tom OKane, Joe Gallagher, Garry Courtney, Abdur Aftab, Aveline Casey, Javier Torres and Philip Angove, Modied Early Warning Scorecard: The Role of Data/Information Quality within the Decision Making Process, http://www.ics.lu.se/media/ics/sta/gertrud.dahlman/data-andinformation-quality.pdf?id=en&cache=cache [36] Zbigniew J Gackowski, Is DQ/IQ the Quality of Information? Two Views, Information Quality Conference, 2009, http://mitiq.mit.edu/ICIQ/Documents/IQ [37] Daniel Diemers On the Social Dimension of Information Quality and Knowledge, University of St. Gallen, 2001 http://www.diemers.net/sub/doc/knowledgeiq.htm [38] Mary Levis, Markus Helfert and Malcolm Brady, Website Design Quality and Form Input Validation: An Empirical Study on Irish Corporate Websites, J. Serv. Sci. & Management. 2008, 1: 91-100, Published Online June 2008 in SciRes, 2008, http://search.conduit.com/Results.aspx?q=psp%2Fiq%20models&start= 40&hl=en&SearchSource=13&SelfSearch=1&SearchType=SearchWeb&ctid= CT2269050&octid=CT2269050&FollowOn=True [39] Marnie L. Hutcheson, Software Testing Fundamentals: Methods and Metrics, John Wiley & Sons, 2003 [40] Cem Kaner, P. Bond, Software Engineering Metrics: What Do They Measure and How Do We Know?, 10T H INTERNATIONAL SOFTWARE METRICS SYMPOSIUM, METRICS , 2004 http://www.kaner.com/pdfs/metrics2004.pdf [41] John Locke, An Essay Concerning Humane Understanding, Volume II, Project Gutemberg, 2004 http://www.gutenberg.org/ebooks/10616 [42] Cara Stein, Glenn Cox, Letha Etzkorn, Sampson Gholston, Sharnsnaz Virani, Phil Farrington,Dawn Utley, Julie Fortune, Exploring the Relationship between Cohesion and Complexity, Journal of Computer Science 1(2): 134-144, 2005 http://www.scipub.org/fulltext/jcs/jcs12137-144.pdf [43] Je Tian, Software Quality Engineering Testing, Quality Assurance, and Quantiable Improvement, John Wiley & Sons, Inc., 2005
BIBLIOGRAFIE
173
[44] Ioan Mihnea Iacob, Radu Constantinescu, Testing: First Step towrds Software Quality, Journal of Applied Quantitative Methods, 2006 http://jaqm.ro/issues/volume-3,issue-3/pdfs/iacob constantinescu.pdf [45] Marc-Alexis Ct, Witold Suryn PhD, Elli Georgiadou, Software Quality Model Requirements for Software Quality Engineering, 2006 http://profs.logti.etsmtl.ca/wsuryn/research/SQE-Publ/Quality http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.677 [46] David Hoyle, Quality Management Essentials,First edition, Elsevier Limited, 2007 [47] Latif Al-Hakim, Information Quality Management: Theory and Applications, IdeA Group publIshInG, 2007 http://de.megadownload.net/download/mu/8ltvewr5/312information-quality-manageme..pdf [48] F. Deissenboeck , S. Wagner , M. Pizka , S. Teuchert, An activitybased quality model for maintainability, In Proc. 23rd International Conference on Software Maintenance (ICSM 07), 2007 IEEE Computer, 2007 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.149.5847 [49] Stefan Wagner, Florian Deissenboeck, An Integrated Approach to Quality Modelling, In Proc. 5th Workshop on Software Quality (5WoSQ). IEEE Computer, 2007 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.1993 [50] Studtmann,P.,Aristotles Categories, 2007, http://plato.stanford.edu/entries/aristotlecategories/#Quality [51] *** Information Quality Guidelines, U.S. Occupational Safety and Health Review Commission Oce of Administration Policy Statement and Procedures, 2007 http://www.oshrc.gov/infoquality/infoquality121707.pdf [52] Herbert Schildt, JavaT M : The Complete Reference McGrow Hill Companies, 2007 [53] Augustin-Iulian Ionescu, Eugen Dumitracu,Continuous Data Quality Assurance,Anale Universitatea din Craiova, 2008
174
BIBLIOGRAFIE
[54] Ismael Caballero, Anglica Caro, Coral Calero, Mario Piattini, IQM3: Information Quality Management Maturity Model, Journal of Universal Computer Science, vol. 14, no. 22 (2008), 3658-3685 http://www.jucs.org/jucs 14 22/iqm3 information quality management /jucs 14 22 3658 3685 caballero.pdf [55] Florian Deissenboeck, Elmar Juergens, Klaus Lochmann, Stefan Wagner, Software Quality Models: Purposes, Usage Scenarios and Requirements, 2008 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.149.4330 [56] Enescu Nicolae-Iulian, Modele pentru evaluarea corectitudinii aplicaiilor informatice distribuite, Teza de doctorat, ASE Bucureti, 2008 [57] Helfert Markus, Foley Owen, Ge Mouzhi, Cappiello Cinzia, Analysing the Eect of Security on Information Quality Dimensions, 17th European Conference on Information Systems, ECIS 2009, Verona, 2009 [58] Augustin-Iulian Ionescu, Eugen Dumitra scu, Nicolae-Iulian Enescu Method of Testing the Quality of a Database During Exploitation MTC Greece, 2009 [59] Riaz Ahamed, An Integrated and Comprehensive Approach to Software Quality,International Journal of Engineering Science and Technology Vol.2 (2), 2010, 59-66 http://www.ijest.info/docs/IJEST10-02-02-02.pdf [60] Gregory Hill, A Framework for Valuing the Quality of Customer Information Thesis, October 2009, http://ghill.customer.netspace.net.au/docs/ [61] Jaikrit Kandari, Information Quality on the World Wide Web: A User Perspective, University of Nebraska - Lincoln, 12-1-2010, http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1017&context=imsediss [62] Gustavo Alonso, A Context-Based Transformation of High-Level Conceptual Query Trees, Diploma Thesis, Institute for Pervasive Computing, Zurich, Switzerland, January 11, 2004, http://e-collection.library.ethz.ch/eserv/eth:26928/eth-26928-01.pdf
BIBLIOGRAFIE
175
[63] Shirlee-ann Knight, The combined conceptual life-cycle model of information quality: part 1, an investigative framework Int. J. Information Quality, Vol. 2, No. 3, 2011 http://www.informationqualityonline.com/Pubs/IJIQ.vol02.03.p205.pdf [64] *** Dict ionar universal ilustrat al limbii rom ane, Ed. Litera, 2010 [65] *** Enciclopedia universal a BRTANICA, Ed. Litera, 2010 [66] *** Quality (philosophy), http://en.wikipedia.org/wiki/Quality (philosophy) [67] *** Software Quality, http://en.wikipedia.org/wiki/Software quality#Software Quality Factors [68] *** Software Metrics Glossary, http://www.mccabe.com/iq research metrics.htm [69] *** Software Quality, https://www.thedacs.com/databases/url/key/3494 [70] ***, Business Dictionary, http://www.businessdictionary.com [71] *** Joseph M. Juran, http://en.wikipedia.org/wiki/Joseph M. Juran [72] *** Philip B. Crosby, http://en.wikipedia.org/wiki/Philip B. Crosby [73] Mohamed Fawzy Afy, Pages from Chapter 13 Quality management http://www.downloadit.org/free les/Pages [74] *** Quality Management Philosophies, www.castle.eiu.edu/lhogan/EV403.PPT [75] *** Quality management principles, http://www.iso.org/iso/iso catalogue/management and leadership standards/ quality management/qmp.htm [76] *** ISO 9001:2000 - Quality Managment System, PCL - Petts Consulting Ltd http://www.petts-consulting.co.uk/Information
176
BIBLIOGRAFIE
[77] *** The Quality Assurence Manual for Flight Procedure Designe, volume I, 2007 http://www2.icao.int/en/pbn/ICAO%20Documentation/ICAO %20Documentation/Advance%20Copy%20-%20Quality%20Assurance %20Manual.Vol%20I%20Doc%209906.pdf [78] *** The History of Quality - Overview, http://asq.org/learn-about-quality/history-ofquality/overview/overview.html [79] *** Software quality - Software Quality Factors, http://www.experiencefestival.com/software quality [80] Jim Harris, Is Your Data Complete and Accurate, But Useless to Your Business?, 2011 http://www.ocdqblog.com/home/is-your-data-complete-and-accuratebut-useless-to-your-busin.html [81] *** Glossary, http://thiyagarajan.wordpress.com/glossary/ [82] *** Standard denition, http://www.businessdictionary.com/denition/standard.html

VVT 2012

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

VVT 2012

Încărcat de

Drepturi de autor:

Formate disponibile

Vericarea si testarea sistemelor de calcul -note de cursIonescu Augustin-Iulian

ii 2.4 Principiile managementului calit a tii

. . . . . . . . . . . . . . . . . . . . . . . . . . . . (unit . . . . 106 . . . . 109

115 115 116 116 123 125 133 142

iii 143 . 143 . 145 . 145 . 146 . 146 . 148 . 152

vi 2.2 2.3 2.4 2.5 2.6

111 112 113 113

6.14 6.15 6.16

7.1 7.2 7.3 7.4

viii 7.5 7.6 7.7 7.8 7.9

153 153 155 156 157

Introducere n ingineria sistemelor

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Figura 1.1: Reprezentarea simbolic a simplicat a a unui sistem.

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Figura 1.2: Reprezentarea simbolic a simplicat a a unui sistem deschis.

1.1. SISTEME de protect ie (carcasa).

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Exemplu: Calculatoarele conectate printr-o ret ea local a sunt slab interconectate.

1.2. SISTEME DE CALCUL

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Figura 1.6: Schema celor 5 unit a ti.

1.3. SISTEME INFORMAT IONALE

Figura 1.7: Arhitectura Harvard a unui calculator.

Sisteme informat ionale

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Figura 1.8: Structura ierarhic a a unui sistem de calcul.

1.3. SISTEME INFORMAT IONALE

Figura 1.9: Mediul de lucru al sistemelor informatice.

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Figura 1.10: Ciclul de viat a al unui produs.

1.4. CICLURI DE VIAT A

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

1.4. CICLURI DE VIAT A

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Ciclul de viat a a datelor

1.4. CICLURI DE VIAT A

Figura 1.11: Ciclul de viat a a datelor.

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

1.4. CICLURI DE VIAT A

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

1.4. CICLURI DE VIAT A

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

1.4. CICLURI DE VIAT A

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Modele ale ciclului de dezvoltare a unui produs

Modelul cascad a (waterfall model)

1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 31

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Modelul evolutiv (evolutionary model)

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 37

1.5. MODELE ALE CICLULUI DE DEZVOLTARE A UNUIPRODUS 39

CAPITOLUL 1. INTRODUCERE IN INGINERIA SISTEMELOR

Calitatea si managementul calit a tii

II 2.1. ABORDARI ALE DEFINIRII CALITAT

Figura 2.1: Perspective din care poate denit a calitatea.

II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT

II 2.1. ABORDARI ALE DEFINIRII CALITAT

II CAPITOLUL 2. CALITATEA S I MANAGEMENTUL CALITAT

I, CERINT 2.2. NECESITAT E, AS TEPTARI

Necesit a ti, cerint e, a stept ari