Ingineria programarii

1. Graful cauz i efect

a. Aplicare:

Identific cerinele care sunt incomplete i ambigue. Aceast msur exploreaz intrrile i ieirile programului pentru a elimina ambiguitile i a obine un set complet i consistent de specificaii.

Acest graf poate fi aplicat, de asemenea, pentru a genera cazuri de test cu o probabilitate mare de detectare a defectelor existente n programe.

Nu se preocup de structura intern sau comportarea programului.

b. Primitive:

Lista de cauze: toate combinaiile distincte de intrri;Lista de efecte: condiiile distincte la ieire sau transformrile strii sistemului.Aex = nr. de ambiguiti rmase de eliminat ntr-un program;Atot = nr. total de ambiguiti identificate.

c. Implementare:

Un graf cauz-efect este transcrierea formal a specificaiei formulate n limbaj natural. Astfel se identific toate specificaiile i se mpart n entiti distincte. Se analizeaz toate specificaiile pentru a stabili toate cauzele i efectele asociate. Fiecare cauz i fiecare efect sunt identificate printr-un simbol.

Paii parcuri pentru constituirea grafului sunt:(1) fiecare cauz i efect se reprezint prin cte un nod care are un numr

unic;(2) se interconecteaz nodurile cauz i cele efect prin analizarea coninutului

semantic al specificaiei, transformndu-l ntr-un graf boolean. Fiecare cauz i efect pot avea dou stri: true i false. Prin folosirea logicii booleene, se listeaz toate strile posibile ale cauzelor i se determin n ce condiii se va produce fiecare efect;

(3) se vor aduga constrngerile care descriu acele combinaii de cauze i efecte care sunt imposibile semantic sau ambiental;

(4) se identific ambiguitile din: orice cauz care nu are un efect corespunztor; orice efect care nu are la baz o cauz; orice combinaii cauz - efect care contrazic specificaiile sau nu pot fi

realizate. Msura are expresia:

( )

=

tot

ex

AACE 1100% .

Metoda grafului cauz - efect se folosete pentru testarea programului astfel: se construiete un tabel decizional unde coloanele corespund efectelor, iar

liniile cauzelor;

pentru fiecare efect, se identific n graf combinaii de cauze care duc la efectul respectiv i se completeaz acea coloan;

se determin starea celorlalte efecte pentru combinaia de cauze determinat; valorile de pe o coloan formeaz un test pentru sistem.

d. Exemplu:

Se construiete o baz de date cu numerele fiierelor nscrise ntr-un index care identific locaiile tuturor fiierelor. Indexul are 10 seciuni.

Un sistem de afiare va permite utilizatorului s vizualizeze una din cele 10 seciuni ale indexului printr-o comand format dintr-o liter urmat de o cifr.

Primul caracter {D, L}, unde:D = display;L = listare.

Al doilea caracter {0, 1, ., 9} identific seciunea din index. Ele ocup primele dou coloane.Dac primul caracter e greit se tiprete mesajul A de eroare, iar pentru al doilea

mesajul B, unde:A = comanda greit;B = numr index greit.

n constituirea grafului cauz - efect se identific cauzele i efectele astfel:Cauze:

(1) caracterul din coloana 1 este D.(2) caracterul din coloana 1 este L.(3) caracterul din coloana 2 este o cifr.

Efecte:(50) este vizualizat seciunea din index.(51) este tiprit mesajul A.(52) este tiprit mesajul B.

Fig. 1 Graful boolean cauz - efect

1

2

3

51

50

52

20OR

NOT

AND

NOT

Nodul 20 este un nod intermediar ce reprezint rezultatul aplicrii operatorului SAU exclusiv nodurilor 1 i 2.

O ambiguitate a specificaiei este dat de vizualizarea seciunii, pentru c nu se precizeaz dac e vizualizat pe ecran sau tiprit la imprimant atunci cnd se d o comand corect.

Aceast ambiguitate se elimin prin redefinirea efectului 50 astfel:50 A - seciunea din index se vizualizeaz pe ecran.50 B - seciunea din index se tiprete la imprimant.

Graful cauz - efect devine:

Fig. 2 Graful boolean cauz - efect (final)

Acum se poate construi tabelul 1, cu coloanele corespunznd efectelor i liniile cauzelor.

Tabelul 1 Reguli de decizieE f e c t e

20 I D L

50A 50B 51 52

1 1 1 0 12 1 0 1 120 03 1 1 0

Nepermis (*) * 1 1 1 1 1 1

1

2

3

51

50A

50B

20OR

NOT

AND

NOT

52

AND

C a u z e

Fiecare coloan din tabelul 1 se poate converti n mai multe teste echivalente. O posibilitate ar fi:

Tabelul 2 Teste ale sistemuluiNr. test Intrri Rezultate scontate

1 D 3 Se vizualizeaz seciunea 3 (50 A)2 L 5 Se tiprete seciunea 5 (50 B)3 B 6 Comand incorect (51)4 L X Numr index eronat (52)

e. Instruire:

Graful cauz i efect este o tehnic matematic ce necesit cunotine de logic boolean.

f. Beneficii:

Aceast msur permite analiza cerinelor, eliminarea ambiguitilor i constituie o baz pentru dezvoltarea cazurilor de test.

2. Trasabilitatea cerine

a. Aplicare:

Verific conformana dintre specificaiile sistemului i cerinele iniiale ale beneficiarului, aplicndu-se n faza incipient a ciclului de via.

Prevederea unei cerine sau adugarea unei specificaii n plus inutil pot s apar n procesul de detaliere a cerinelor iniiale, cnd se creaz arhitectura sistemului software.

Trasabilitatea e corect dac toate specificaiile asociate arhitecturii sistemului au corespondent n cerinele iniiale ale beneficiarului i reciproc, dac toate cerinele se regsesc n arhitectura sistemului.

b. Primitive:

R1 = nr. de cerine implementate n arhitectura sistemului;R2 = nr. de cerine iniiale (beneficiar).

c. Implementare:

Msura de trasabilitate se calculeaz cu formula:

TM = 100% .

d. Interpretare:

Cnd toate cerinele software beneficiar sunt acoperite de arhitectura software, msura de trasabilitate este 100%.

Dac msura de trasabilitate e mai mic de 100%, atunci unele cerine iniiale nu au fost incluse n arhitectura software.

Arhitectura poate, totui, s conin cerine suplimentare celor iniiale. Unele dintre acestea pot rezulta ca urmare a unor pai de rafinare, altele din noi cerine adugate arhitecturii. Astfel de situaii trebuie analizate cu atenie.

e. Instruire:

Este necesar instruirea n interpretarea adecvat a rezultatelor.

f. Exemplu:Se consider un sistem de suparaveghere a traficului care trebuie s transmit un

avertisment la consola operatorului i s-l tipreasc atunci cnd traficul n sistem este ridicat.

n figura 3, nu se precizeaz tiprirea avertismentului, trasabilitatea nefiind deci complet.

R2 = R1 + 1 i TM = 100% < 100%.

Fig. 3 Arhitectura unui sistem de control al traficului (incomplet)

R1

R2

R1

R2

Trafic intensAvertizare supervizorSesizare

n arhitectura din fig. 4 se remediaz aceast omisiune:

Fig. 4 Sistem de supraveghere trafic (complet)

Aici R1 = R2 + 1 i TM > 100% pentru c o cerin adiional, care n-a fost iniial n arhitectura sistemului, s-a introdus (lund fig. 3 ca reflectnd ceea ce a cerut beneficiarul iniial).

Aceast situaie ar putea fi i o eroare (TM > 100%).

g. Beneficii:

Acest metric, aplicat fazei de design arhitectural software, poate identifica cerinele beneficiar neimplementate.

Trafic intens Avertizare operatorSesizare

Mesaj la imprimant

Metrica Halstead (metric a textului surs)

Orice limbaj de programare este caracterizat prin: Definire de instruciuni neexecutabile(declarative); Instruciuni executabile; Manipularea, n cadrul expresiilor, a operatorilor i operanzilor; Programele sunt formate din instruciuni care sunt scrise n secvene,

fr a lua n considerare ordinea execuiei; Programele sunt privite omogen, fr s se in seama de prelucrrile

fcute.

IPOTEZE DE LUCRU:- Cu toate c tipurile de date nseamn alocri de zone de memorie

diferite, toi operaranzii sunt considerai omogeni, putnd fi contorizai global;

- Dei operatorii nseamn nr. diferit de cicluri main, vor fi considerai omogeni i vor fi, aadar, contorizai global;

- Chiar dac cuvintele cheie folosite n instruciuni executabile corespund unor secvene de compilare de lungimi diferite, vor fi considerate omogene i se vor contoriza global.

Aceste ipoteze simplificatoare sunt specifice metricii HALSTEAD.Se consider: n1 nr. operanzilor distinci; n2 nr. operatorilor distinci;Se vor defini relaiile:

n = n1 + n2, unde n este vocabularul folosit n program; N = N1 + N2, unde:

N1 nr. total de operanzi care apar n program;N2 nr. total de apariii ale operatorilor n program;N lungimea observat a programului.

C = n1 log2( n1 ) + n2 log2( n2 ), unde C este complexitatea estimat a programului;

V = N log2( n ), unde V este volumul programului; K = (V n2 N1) / (2 n1), unde K este claritatea programului; L = ( 2 n1) / ( n2 N1 ), unde L reprezint nivelul de implementare; D = 1 / L, unde D este dificultatea.

Se observ c metrica HALSTEAD privete programul ca un ansamblu de componente, fr a lua n considerare interdependenele dintre instruciuni i modul de execuie a lor.

De exemplu secvenele:

s = 0; s = 0;i= 0; for ( i =1; i< n; i++ )x [ i ] = 1; {for ( i = 1; i < n; i++ ) y[ i ] = 0;

{ z[ i ] = i; x [ i ] = ( i +3 ) * (i+3); x [ i ] = ( i+3 ) * (i+3); s+ = x[ i ]; s+ = x[ i ];

} }

Secvena a) Secvena b)

dei sunt diferite ca semnificaie, din punct de vedere al execuiei i al rezultatelor obinute conduc la valori ale metricii HALSTEAD prezentate n tabelul 1.

Tabelul 1. Metrica HALSTEAD calculat pt. 2 secvene de program

INDICATORUL SECVENA a) SECVENA b)n1 7 7n2 10 10N1 21 22N2 26 27V 192.11 200.28C 52.87 52.87D 15 15.71

Pt. secvena a)n1 = {s, i, x, n, 0, 1, 3}----operanzi distinci;n2 = { = ; [ ] ( ) < ++ * + }----operatori distinci.Obs.: 1) { } i , sunt separatori. 2) Cu toate c instruciunile nu sunt comutative, metrica HALSTEAD

nu reflect necomutativitatea, tocmai de aceea, pt. realizarea unor comparaii reprezentative, ea se aplic unor programe corecte i optimale.

De exemplu secvenele:

s= 0; s= 0; a = 0; for (i = 0; i < n; i++)for (i = 0; i < n; i++) { { a = 0; s+ = x[ i ]; s+ = x[ i ]; } }

Secvena a) Secvena b)

, dei sunt identice din punct de vedere al metricii HALSTEAD, neoptimalitatea secvenei b) nu este reflectat.

NUMRUL CICLOMATIC (Metrica McCabe)

Dac se consider graful G asociat unui program, care are N noduri, M arce i P componente conexe (pentru care se identific perechi de noduri distincte legate printr-un lan), numrul ciclomatic v(G) = M N +P.Numrul ciclomatic reprezint o agregare de elemente neomogene (noduri, arce, perechi de noduri legate prin lanuri).De exemplu, pentru graful din fig. 1

Fig. 1 Graf orientat

Numrul de noduri N = 8, numrul de arce M = 7. Perechile de noduri (x1, x5), (x2, x5), (x3, x5), (x1, x6), (x2, x6), (x3, x6), (x4, x6), sunt legate prin lanuri; n acest caz P = 7.Numrul ciclomatic asociat grafului din fig. 1 este :v(G) = M N +P=7 8 + 7 = 6.Structurilor de program le corespund grafuri care au particulariti impuse de caracterul secvenial al execuiei instruciunilor. Fiecrei structuri de program i se poate ataa un graf orientat n care nodurile corespund instruciunilor, iar arcele ordinii de execuie a instruciunilor. Un astfel de graf are un nod iniial (de start) i un nod terminal (de stop) i nu este un graf conex, deoarece nu exist un drum de la nodul iniial la cel final. Prin adugarea unui arc care pleac din nodul terminal i are cealalt extremitate n nodul iniial se obine un graf conex, ce are o singur component (P = 1).Numrul ciclomatic se calculeaz dup formula:v(G) = M N +2, deoarece a fost adugat grafului iniial un arc suplimentar (fictiv).De exemplu, pentru un program format din 6 instruciuni de afiare care se execut secvenial, avnd asociat graful din fig. 2,

Fig. 2 Graful asociat unei secvene liniare de program

X2 X3

X1

X4 X5

X6

X7

X8

I2 I3 I4 I5 I6 I1

numrul ciclomatic este:v(G) = M N +2 = 5 -6 + 2 = 1.

Intuitiv, structurile liniare sunt identificate cu complexiti minime. n acest caz, numrul ciclomatic se asimileaz cu o msur de complexitate.Pentru programul care numr elementele pozitive, negative i nule ale unui masiv unidimensional, al crui text surs este:

void main(){int np, nn, nz, i, x[10]={-3, 2, 7, 0, 11, 0, 2, 4, -1, 0};I1: np=0;I2: nn=0;I3: nz=0;I4: for(i=0; i 0) I8: np++; else I9: nz++;I11: printf(\n Numarul elementelor negative = %d, nn);I12: printf(\n Numarul elementelor nule = %d, nz);I13: printf(\n Numarul elementelor pozitive = %d, np);}, se asociaz graful din fig. 3:

Vom avea:Numrul de noduri: N = 13Numrul de arce: M = 15Numrul ciclomatic asociat acestui graf:V(G) = M N + 2 = 15 -13+ 2= 4.

Pentru un modul obinuit, 10 este complexitatea ideal maxim. Pentru un sistem foarte complex, numrul ciclomatic poate fi mai mare. Dac numrul complexitii calculate este prea mare, se impune o modularizare a codului. Literatura de specialitate ofer urmtoarele valori:

Cyclomatic Complexity Risk Evaluation 110 A simple program, without much risk1120 More complex, moderate risk2150 Complex, high risk program>50 Untestable program (very high risk)

Numrul ciclomatic i nivelul de context

Prin convenie, nivelul de context asociat structurii liniare este 1. Instruciunea :if cond S1

else S2

Este generatoarea unui nou context, iar secvenele S1 i S2 vor avea nivelul de context majorat cu o unitate n raport cu nivelul precedent.Pentru secvena de program: a = 3;

b = 4;c = 2;if (a > b) min = b;

else min = a; if (min > c) min = c;

printf(\n %d, min); ,graful asociat este dat n fig. 4:

nivele de context 3 2 1 2 3

n1 a=3

n2 b=4

n3 c=2

n4 if(a > b)

n6 min=a

n5 min=b

n7endif

n10endif

n9min=c

n8if(min > c)

n11printf

Fig. 4 Nivele de context pentru o secven de program

da

da

Arcul care efectueaz legtura ntre un nod avnd nivelul de context Ki i un nod avnd nivelul de context Kj va fi ponderat cu max {Ki, Kj}. Se consider un graf G asociat programului P avnd n arce, cu ponderile p1, p2, ..., pn i m noduri. Numrul ciclomatic ponderat este:C = pi m +2, unde i = 1, ,n.Indicele ciclomatic ponderat este definit prin:Ic = C / (n * max{ pi } m + 2.Pentru secvena de program considerat, graful din figura de mai sus are 12 arce i 11 noduri. Ponderile asociate arcelor sunt date n tabelul nr. 1.

Tabelul 1. Niveluri de context i ponderi asociate arcelor

Arcul (ni, nj) Context Ki Context Kj pi(n1, n2) 1 1 1(n2, n3) 1 1 1(n3, n4) 1 1 1(n4, n5) 1 2 2(n4, n6) 1 2 2(n5, n7) 2 1 2(n6, n7) 2 1 2(n7, n8) 1 1 1(n8, n9) 1 2 2(n8, n10) 1 1 1(n9, n10) 2 1 2(n10, n11) 1 1 1

pi 18

C = 18 11 + 2 = 9.Numrul ciclomatic calculat dup formula lui McCabe are valoarea:CMC = M N + 2 = 12 11 + 2 = 3.Ic = 8 / ( 12 * 2 11 + 2 ) = 9 / 15.Se observ, analiznd tabelul 2, c ponderea exprim mai bine diversitatea legturilor dintre noduri.

Tabelul 2. Indicatori ponderai i neponderai

Tip indicatori C sau CMC IcNeponderat 3 1

Ponderat 9 9/15

I1 np = 0

I2 nz = 0

I3 nn = 0

I4 for

I5 if

I6 nn++

daI7 if

I8 np++I9 nz++

Continuare ciclu (nod fictiv)

nu

da I11

I12

I13

Fig. 3 Graful asociat programului

1. Timpul mediu de descoperire a urmtoarelor k defecte

a. Aplicare:Metrica poate fi folosit pentru a proiecta timpul mediu pn la descoperirea

urmtoarelor k defecte, dnd indicaie asupra a ct de mult timp se cere pn ce se obine un nivel dorit de fiabilitate.

b. Primitive:f = numr de defecte gsite de la nceputul testrii pn n prezent;ti = timpul ntre defectarea (i-1) i i pentru un nivel de severitate dat (i=1, ).

c. Implementare:Timpul mediu pn la defectare (metricul 4) ar trebui folosit pentru estimarea

urmtoarelor k defecte n software. El are expresia:Timpul mediu pn la descoperirea urmtoarelor k defecte (TME) =

MTTF ii f

f k

=

+ 1 , unde MTTFi este un timp mediu pn la defectare estimat ntre defectarea i i i+1 i se poate calcula folosind orice model software bazat pe timpii ntre defectri. Prin estimarea MTTF, se poate estima ct timp de testare va fi necesar pentru a descoperi toate defectele sau un subset al defectelor reziduale.

d. Interpretare:Calculele numerice actuale ale estimrii MTTF depind de distribuia aleas de

model pentru MTTF.

e. Consideraii:n timpul ciclului de via al dezvoltrii software, ar trebui s se utilizeze

evalurile prediciilor unui model pentru f i n funcie de aceasta s se fac planificri care se pot realiza.

g. Instruire:Implementarea acestui metric cere cunoaterea aplicrii modelelor software ale

timpilor ntre defectri.

h. Exemplu:Se folosete modelul de de-eutroficare Jelinski-Moranda pentru a estima

MTTFi (timpul mediu de defectare ntre defectrile i i i+1).

MTTFi = , unde:

Q = constant de proporionalitate estimat n model;

NF = numr estimat al defectelor existente n program.Timpul mediu estimat pentru a descoperi urmtoarele defecte este:

^

^

^

^ 1

Q (NF-i)^ ^

^

TMEi f

f k

=

=

+ 1 .Pentru a ilustra calculul, fie:

f = 20, Q = 0.05; NF = 100.Timpul mediu, de exemplu, pentru a descoperi urmtoarele 2 defecte este:

( ) ( ) ( ) ( ) ( ) ( )TME ii= = + ==1

0 05 1001

0 05 801

0 05 79050

20

21

. . ..

Observaie: Timpul se poate referi la timpul de execuie CPU sau calendaristic.

i. Beneficii:Acest metric se poate reprezenta funcie de k (k = 1,2,3, NF) folosind la

aprecierea integritii unui sistem n orice moment dat.

2. Estimarea numrului de defecte rmase (prin seeding)

a. Aplicare:Numrul estimat de defecte rmase ntr-un program ine de fiabilitatea

programului. Sunt mai multe tehnici de estimare a acestui numr. Aici se propune o form a plantrii defectelor cu o distribuie omogen.

Acest metric poate fi aplicat oricrei faze a ciclului de via software.Cutarea defectelor continu pn cnd se descoper un anumit numr de defecte

nsmnate, pe lng cele indigene.

b. Primitive:NS = numr de defecte plantate;nS = numr de defecte plantate gsite;nF = numr de defecte indigene gsite;

c. Implementare: o echip special insereaz NS defecte reprezentative pentru tipul de defecte

indigene ateptate s existe n soft; echipa de test raporteaz defectele gsite n timpul unei perioade de test

prestabilit. Precizia estimrii crete cu numrul de defecte care au fost inserate aleator n software. Fiecare defect raportat trebuie atribuit unei clase (indigen sau inserat) i totodat se stabilete dac a mai aprut;

estimarea numrului de defecte indigene pentru o anumit clas este:

NF = , unde :

NF se va lua ca parte ntreag.

Estimarea numrului rmas de defecte este:

^ ^

1

Q (NF-i)^ ^

^ n F N

S

nS

^

NF rez = NF - nF probabilitatea gsirii lui nF din NF defecte indigene i a lui nS din NS defecte

nsmnate, adic pentru a se gsi nF + nS defecte n program, estePfound = C (NS, nS)(NF, nF) / C(NF + NS, nF + nS) unde;C(x, J) = x! / (x - J)! J! este combinri de x luate cte J.

d. Consideraii: msura depinde de presupunerea c defectele nserate sunt reprezentative pentru defectele existente. n general, nu toate defectele au posibilitate egal n a fi descoperite de o procedur de test; defectele sunt corectate n software-ul original numai dup ce s-a determinat care sunt erorile indigene dintre toate defectele; corecia defectelor indigene poate duce la generarea altor defecte.

e. Instruire: se cere instruire n inserarea defectelor i monitorizarea procesului de testare; se cere i pricepere n clasificarea defectelor.

f. Exemplu:Presupunem c s-au inserat 100 de defecte. n timpul perioadei de testare, au fost

gsite 50 din cele 100 de defecte plantate i 2 dintre cele indigene.Atunci: NS = 100

nS = 50nF = 2

NFn NnF S

S=

=

=

2 10050

4

Numr de defecte reziduale: NF rez = NF - nF = 4 - 2 = 2.Nippon Telephone and Telegraph au obinut rezultate bune aplicnd metoda de

inserare defecte unui sistem de operare cu 15000 linii de cod.

3. Acoperire test (coverage)a. Aplicare:Msoar completitudinea procesului de testare din perspectiva utilizator i

dezvoltator. Are legtur direct cu etapele de dezvoltare, integrare i testare (pentru testele de : unitate, sistem i acceptare).

b. Primitive:(1) program:

funcionale (module, segmente, instruciuni, ramificri, ci); date (clase de date).

(2) cerine:

^

^ ^

^ ^

cazuri de test; capaciti funcionale.

c. Implementare:Acoperire test (TC) are expresia:

TC (%) = 100

d. Interpretare: TC este doar un indicator al desvririi unui test. De obicei exist un numr infinit de cazuri de test. Acesta poate fi redus semnificativ dac se definesc logic relaii echivalente referitor la funcii i date; ncrederea n nivelul testrii crete prin utilizarea de primitive rafinate: de exemplu, acoperirea segment de 100% este mai puternic dect cea a modulului de 100%.

e. Consideraii: programul este un set de instruciuni codificate, iar cerinele sunt un set al capabilitilor dorite de utilizator;

Fig. 1 Acoperire testare

intersecia din fig. 1 reprezint setul de capabiliti cerute de utilizator care sunt implementate;

aria stng reprezint creativitatea programator sau acele zone pentru care s-au luat decizii de implementare necesare funcionrii hardware-ului;

aria dreapt reprezint capabilitile intenionate ale utilizatorului care lipsesc n implementare intenionat sau nu;

corespunztor acestui model, se procedeaz astfel:

(Capabiliti implementate)(Capabiliti cerute)

(Primitive program testate)(Primitive program totale)

CERINE IGNORATE/LIPSCREATIVITATE PROGRAMATOR

PROGRAM

CERINE

CUTIE ALB

CUTIE NNEAGR

CUTIE GRI(ACOPERIRE DORIT)

(1) programului i se asociaz o activitate de testare unitate bazat pe cunoaterea structurii programului (cunoscut ca WHITE BOX) sau pe cea funcional

(CLEAR BOX TESTING);(2) cerinelor li se asociaz o activitate de test sistem care, n majoritatea cazurilor,

presupune o necunoatere a implementrii program.Sunt proiectate scenarii de test care s demonstreze operarea corect din

punctul de vedere al utilizatorului.Primitivele cerine se cunosc i ele dau o msur de acoperire test orientat

utilizator (BLACK BOX TESTING).Combinarea celor dou activiti duce la ceea ce se cheam GRAY BOX

TESTING. Testarea n aceast activitate vizeaz produsul, acoperirea prin test a programului i cerinelor.

f) Instruire:Utilizatorul ar trebui s neleag baza teoriei de testare.

g). Exemplu:Presupunem c toate cerinele sunt implementate.Tabelul 3 d coverage-ul test al unui set de teste n care segmentele sunt

primitivele.

Tabelul 1 Exemplu de msurare a acoperirii testrii(cu segmente ca primitive)

Nr. Nume Numr de

Teste executate

crt.

modul segmente Nr. de invocri Nr. de segmente testate Procent coverage

5051525354555657

ABCDEFGH

1771573545929

122143420512

521142183914

29.3873.3357.1466.6733.3360.00100.0048.28

TOTAL 1192 397 454 38.09 %

4. Timpul mediu pn la defectare

a. Aplicare:Se folosete pentru a testa un MTTF specificat.

b. Primitive: MTTF este parametrul de baz cerut de majoritatea modelelor de fiabilitate

software; calculul e dependent de precizia nregistrrii timpului de defectare ( ti ), unde

ti este timpul dintre defectrile (i-1) i i; pentru un mediu de dezvoltare software, se recomand timpul de execuie

CPU, iar pentru mediul operaional timpul calendaristic (mai puin precis).

c. Implementare: se pstreaz istoria defectrilor; se organizeaz defectele n funcie de complexitate, severitate sau rata de

reinserie; se alege un model reprezentativ al procesului de defectare, care se valideaz

cu datele despre defectri pe care le-am nregistrat.

c. Interpretare:O valoare mare a MTTF implic o fiabilitate i disponibilitate corespunztoare ale

software-ului.

d. Instruire: cunotine de statistic matematic i folosire a modelelor de fiabilitate; calculele pentru majoritatea modelelor de fiabilitate cer implementarea unor

programe pe calculator.

e. Exemplu:Se consider trei nivele ale severitii claselor de defectare: SF1, SF2 i SF3.

Fiecare clas de defectare are proprii si timpi ntre defectri:SF1: 180, 675, 315, 212, 278, 503, 431SF2: 477, 1048, 685, 396SF3: 894, 1422.

Atunci o estimare a MTTF este:

MTTFtik

k

i

=

=

1

, pentru fiecare clas, unde:

tk = timpii ntre defectri;i = nr. de defectri din clasa de severitate respectiv.

MTTF SF12594

7370 57= = . ,

MTTF SF 22606

4651 5= = . ,

MTTF SF 32316

21158= = .

Aceste valori pot fi comparate cu MTTF specificat pentru fiecare clas de severitate.Pentru c rata de defectare e constant, funcia de distribuie a defectrii poate fi presupus exponenial i F(t) = 1 - exp(-t/MTTF), care reprezint probabilitatea defectrii software n timpul t.

5. Rata de defectarea. Aplicare:Poate fi folosit pentru a indica creterea fiabilitii software n funcie de timpul

de testare.

b. Primitive:ti = timpul ntre defectri pentru un anumit nivel de severitate (i = 1, 2,..);fi = numrul de defectri ale unui nivel de severitate n intervalul de timp t.

c. Implementare: rata de defectare (t) poate fi estimat din funcia de fiabilitate, R(t), care

la rndul ei se poate obine din distribuia de probabilitate cumulativ, F(t), a timpului pn la urmtoarea defectare folosind orice model de cretere fiabilitate, cum ar fi modelul Poisson neomogen (NHPP) sau modelul de tip Bayesian.

Rata de defectare este : (t) = R tR t

' ( )( ) , unde R(t) = 1 - F(t).

d. Interpretare: (t) obinut din NHPP depinde numai de timpul t i descrete continuu; (t) care deriv din modelul lui Littlewood depinde de timpul t i valoarea

funciei de cretere fiabilitate (i) la defectarea a i a.Cernd funciei (i) s fie cresctoare, condiia (ti) (ti - 1) poate fi

respectat doar n sens probabilistic, pentru c programatorul poate introduce noi erori n timpul coreciei unei erori.

e. Consideraii:Modelul NHPP face supoziiile:

(1) Fiecare defect are probabilitate egal de expunere;(2) Nr. de defecte detectate n timpul intervalelor destinate de test , t i, sunt

independente;(3) Timpul ntre defectrile i-1 i i depinde de timpul pn la a (i-1) a defectare.

f. Instruire: programe de calcul pe calculator (pt. parametri i indicatori); cunoatere a proceselor stochastice i a tehnicilor de optimizare.

g. Exemple:

Misra , un specialist NASA, a obinut o funcie valoare medie pentru rata de defectare testnd peste 0.5 milioane linii cod surs ale unui software folosit n aviaie.

Dup 38 sptmni de testare ( 2455 h) au fost estimai parametrii modelului NHPP pentru categoria de erori majore:

a = 163.813; b = 0.287 10-3Rata de defectare descresctoare are expresia:

( ) t ab b t tii

n

= +

=exp 1 pentru t tii

n

=

1

.

Littlewood a examinat un set de date de 136 timpi de execuie, publicat de Musa, pentru a prezice timpii de defectare viitori, utiliznd

( ) ( )

t t i ,t t ti i= + +1

i lund pentru (i) o form liniar: (i) = 1 +2i.

Parametrii , 1 i 2 s-au obinut cu metoda verosimilitii maxime bazat pe primele 35 de observaii:

= 1.518; 1 = -0.995; 2 = 7.834.Cu aceasta, rata de defectare dup defectarea i se poate estima cu formula:

( ) tt i

=

+

15180 995 7 834

.. .

,

ti t ti + 1 (i = 1, .136).

h. Beneficii: scderea ratei de defectare poate fi folosit pentru a arta mbuntirea

fiabilitii software ca un rezultat al folosirii operaionale; se poate estima timpul necesar atingerii unei inte de fiabilitate

^

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

Introducere n Ingineria Programrii


Obiective

l De a face o introducere n ingineria software i de a explica importana ei

l De a prezenta rspunsuri la ntrebrile cheie legate de ingineria programrii

l De a prezenta aspecte etice i profesionale ce sunt legate de inginerii software


Cuprins

l ntrebri frecvente despre ingineria software

l Responsabilitate ethic i profesional


Ingineria programrii

l Economiile TUTUROR rilor dezvoltate depind de software.

l Tot mai multe sisteme sunt controlate de programe.

l Ingineria software se ocup cu teorii, metode i instrumente pentru dezvoltarea software profesional.

l Cheltuielile legate de software reprezint un procent semnificativ n toate rile dezvoltate.


Costuri software

l Costurile software de cele mai multe ori depesc costurile hardware.

l Costurile de ntreinere a unui program de obicei sunt mai mari dect costurile de dezvoltare. Pentru sistemele cu o via lung, costurile de mentenan pot depi de cteva ori costurile de dezvoltare.

l Ingineria programrii se ocup cu dezvoltarea eficient a programelor.


ntrebri frecvente despre ingineria software

l Ce este software-ul?l Ce este ingineria software?l Care este diferena dintre ingineria software i

tiina calculatoarelor?l Care este diferena dintre ingineria software i

ingineria sistemelor?l Ce este un proces software?l Ce este un model al procesului software?


ntrebri frecvente despre ingineria software

l Care sunt costurile n ingineria software?l Ce sunt metodele ingineriei software?l Ce este CASE (Computer-Aided Software

Engineering)l Care sunt atributele unui software de calitate?l Care sunt provocrile eseniale ale ingineriei

software?


Ce este software-ul?l Programele de calculator i documentaia legat de ele cum

ar fi cerine, modele de proiectare i manuale de utilizare.l Produsele software pot fi dezvoltate pentru un client

particular sau pentru o pia general.l Produsele software pot fi

Generice dezvoltate pentru a fi vndute unei game largi de utilizatori (cum ar fi Excel sau Word).

Dedicate dezvoltate pentru un singur client n conformitate cu cerinele clientului.

l Software nou poate fi creat prin dezvoltarea de noi programe, configurnd sisteme software generice sau reutiliznd software existent.


Ce este ingineria software?

l Ingineria software este o disciplin de inginerie ce se ocup de toate aspectele produciei software.

l Inginerii software trebuie s adopte o abordare sistematic i organizat i s foloseasc instrumente i tehnici potrivite cu problema de rezolvat, cu constrngerile de dezvoltare i cu resursele disponibile.


Care este diferena dintre ingineria software i tiina calculatoarelor?

l tiina calculatoarelor se ocup cu partea de teorie i fundamente; ingineria software se ocup cu prtile practice de dezvoltare i livrare a programelor utile.

l Teoriile tiinei calculatoarelor nu sunt suficiente pentru ingineria software.


Care este diferena dintre ingineria software i ingineria sistemelor?

l Ingineria sistemelor se ocup cu toate aspectele de dezvoltare ale sistemelor bazate pe calculator incluznd hardware, software i ingineria proceselor. Ingineria software este parte a acestui proces ce se ocup cu dezvoltarea infrastructurii software, control, aplicaii i baze de date n sistem.

l Inginerii de sistem sunt implicai n specificarea sistemelor, proiectarea arhitecturii, integrare i instalare.


Ce este un proces software?l Este o mulime de activiti ale cror scop este

dezvoltarea sau evoluia unui software.l Activitile generice prezente n toate procesele

software sunt: Specificare ce ar trebui s fac sistemul i care sunt

constrngerile de dezvoltare Dezvoltare producia sistemului software Validare verificarea dac sistemul software este ceea

ce dorete clientul Evoluie schimbarea sistemului software ca rspuns

la cerinele clientului


Ce este un model al procesului software?

l Este o reprezentare simplificat a unui proces software, prezentat dintr-o perspectiv specific.

l Exemple de perspective prin care putem privi un process Perspectiv Workflow secven de activiti; Perspectiv Data-flow fluxul informaiei (de date); Perspectiv Rol/aciune cine ce face.

l Modele generic de proces Waterfall (cascad); Dezvoltare iterativ; Dezvoltare bazat pe componente.


Care sunt costurile n ingineria software?

l Aproximativ 60% din costuri sunt costuri de dezvoltare, iar 40% sunt costuri de testare. Dar pentru software dezvoltat pentru un client particular, costurile de evoluie de cele mai multe ori depesc costurile de dezvoltare.

l Costurile variaz n funcie de tipul sistemului dezvoltat i n funcie de cerinele sistemului mai ales cele de performan i fiabilitate.

l Distribuia costurilor depinde mult de modelul de dezvoltare folosit.


Distribuia costurilor pe activitateWa t e rfa ll m o d e l

It e ra tiv e d e v e lo pm e n t

Co m po ne n t-b a se d so ftw a re e ng in e e rin g

De v e lo pm e n t a n d e v o lutio n c o sts fo r lo n g -life tim e sy st e m s

Sy ste m e v o lutio n

1 0 2 0 0 3 0 4 0 00

Sy ste m d e v e lo pm e n t

Spe c ific a tio n De sig n De v e lo pm e n t In te g ra tio n a nd te sting

2 5 5 0 7 5 1 0 00

Spe c ific a tio n De v e lo pm e n t Inte g ra tio n a nd te stin g

2 5 5 0 7 5 1 0 00

Spe c ific a tio n Ite ra tiv e d e v e lo pm e nt Sy ste m te sting

2 5 5 0 7 5 1 0 00


Costurile de dezvoltare a unui produs

Spe c ific a tio n De v e lo pm e n t Sy ste m te stin g

2 5 5 0 7 5 1 0 00


Ce sunt metodele ingineriei software?

l Sunt abordri structurate ale dezvoltrii software care includ modele de sistem, notaii, reguli, sfaturi de proiectare i ghid de proces.

l Diagrame de model Descrieri grafice ale modelului de sistem;

l Reguli Constrngeri aplicate modelelor de sistem;

l Recomandri Sfaturi de bun proiectare;

l Ghid de proces Ce activiti ar trebui efectuate.


Ce este CASE (Computer-Aided Software Engineering)

l Sunt sisteme software care ofer suport pentru activitile proceselor software.

l Sistemele CASE sunt deseori folosite pentru a realiza o metodologie de dezvoltare.

l Upper-CASE Aplicaii care vin n ajutorul activitilor de nceput ale

procesului de dezvoltare cum ar fi specificarea cerinelor, analiz i proiectare;

l Lower-CASE Aplicaii care ajut activiti ulterioare cum ar fi

programare, depanare i testare.


Care sunt atributele unui software de calitate?

l Un software de calitate trebuie s ofere funcionalitatea i performana cerut de client i s fie mentenabil, fiabil i acceptat de client.

l Mentenabilitate Software-ul trebuie s evolueze pentru a fi n pas cu schimbrile;

l Fiabilitate Software-ul trebuie s fie de ncredere;

l Eficien Software-ul nu trebuie s abuzeze de resursele sistemului;

l Acceptan Software-ul trebuie s fie acceptat de utilizatorii pentru care a fost

proiectat. Acest lucru nseamn c trebuie s fie uor de neles, utilizabil i compatibil cu alte sisteme.


Care sunt provocrile eseniale ale ingineriei software?

l Eterogenitate, promptitudine i ncredere.l Eterogenitate

Tehnicile de dezvoltare software trebuie s fac fa platformelor i mediilor de execuie eterogene;

l Promptitudine Tehnicile de dezvoltare trebuie s duc la o mai

rapid dezvoltare a programelor;l ncredere

Tehnicile de dezvoltare trebuie s demonstreze c utilizatorii pot folosi cu ncredere produsul software.


Responsabiliti profesionale i etice

l Ingineria software implic mai multe responsabiliti dect punerea n practic a unor aptitudini tehnice.

l Inginerii software trebuie s aib un comportament onest i etic dac vor s fie respectai ca profesioniti.

l Comportamentul etic nseamn mai mult dect a respecta legea.


Elemente de responsabilitate profesional

l Confidenialitate Trebuie respectat confidenialitatea angajailor i a

clienilor indiferent dac a fost semnat sau nu un contract de confidenialitate.

l Competen Nu trebuie prezentat greit nivelul de competen.

Nu trebuie acceptat o lucrare care depete nivelul de competen.


Elemente de responsabilitate profesional

l Proprietatea intelectual Trebuie avute n vedere legile locale legate de

patente, copyright, etc. Trebuie de asemnea luate msuri pentru protejarea proprietilor intelectuale ale angajailor i clienilor.

l ntrebuinare iresponsabil a calculatorului Aptitudinile de lucru cu calculatorul nu trebuie

folosite iresponsabil asupra calculatoarelor altor persoane. Folosirea iresponsabil variaz de la lucruri relativ triviale (jucarea unor jocuri pe calculatoarele clientului) pn la lucruri extrem de serioase (virusarea calculatoarelor).


Concluziil Ingineria software este o disciplin de inginerine ce se ocup

cu toate aspecte de producie software.l Produsele software constau din programele dezvoltate i

documentaia corespunztoare. Atributele esentiale ale produselor software sunt maintainabilitatea, fiabilitatea, eficiena i utilitatea.

l Procesul software const din activitile implicate n dezvoltarea produselor software. Activitile de baz sunt specificarea software, dezvoltarea, validarea i evoluia.

l Metodele sunt moduri organizate de producie software. Ele includ sugestii pentru procesul ce trebuie urmat, notaii folosite, reguli ce guverneaz descrierile sistemului ce este produs i sfaturi de proiectare.


Concluzii

l Aplicaiile CASE sunt sisteme software proiectate s ajute activitile de rutin din procesul de dezvoltare software, cum ar fi editarea diagramelor, verificarea consistenei lor i evidena testelor rulate.

l Inginerii software au responsabiliti profesionale i sociale care depesc elementele tehnice.


Cerine Software


Obiective

l De a introduce conceptele de cerine utilizator i cerine sistem

l De a descrie cerinele funcionale i ne-funcionale

l De a explica cum pot fi organizate cerinele sotfware ntr-un document de cerine


Cuprins

l Cerine funcionale i ne-funcionalel Cerine utilizatorl Cerine de sisteml Documentul de cerine software


Ingineria cerinelor

l Este procesul de stabilire a serviciilor pe care le dorete clientul de la sistem i constrngerile de operare i dezvoltare.

l Cerinele sunt descrieri ale serviciilor sistemului.


Ce este o cerin?

l Poate varia de la o fraz abstract care descrie un serviciu sau o constrngere de sistem pn la o specificare matematic detaliat.

l Aceast situaie este inevitabil deoarece ele au dou funcii Pot sta la baza unei licitaii deci trebuie s fie uor

de interpretat; Pot sta la baza unui contract deci trebuie definite n

detaliu; Ambele descrieri sunt numite cerine.


Abstractizarea cerinelor (Davis)

Dac o companie dore te s ini ieze dezvoltarea unui proiect software mare , trebuie s defineasc cerin ele ntr -un mod suficient de abstract ca solu ia s nu fie predefinit . Cerin ele trebuie scrise astfel nct diferite firme s poate licita pentru con tract, oferind probabil diferite moduri de a ndeplini cerin ele organiza iei clien t. Odat ce contractul a fost c tigat, contractorul trebuie s scrie o defini ie a sistemului mult mai detaliat astfel nct clientul s n eleag i s valideze comportamentul programului. Ambele do cumente pot fi numite document de cerin e pentru sistem.


Tipuri de cerinel Cerine utilizator

Sunt fraze n limbaj natural plus diagrame ale serviciilor pe care le ofer sistemul i constrngeri de operare. Ele sunt scrise de clieni.

l Cerine de sistem Sunt structurate ntr-un document cu descrieri

detaliate ale funciilor sistemului, servicii i constrngeri de operare. Definete ceea ce va fi implementat, deci poate fi parte dintr-un contract.


Definiii i specificaii

1. Programul trebuie s ofere mijloace de reprezentare i accesare a 1. fiierelor externe create de alte instrumente

1.1 Utilizatorul trebuie s aib mijloace de a defini tipul fiierelor externe2 1.2 Fiecare tip de fiier exterior poate avea un instrument asociat cu care1.2 poate fi deschis acel fiier.1.3 Fiecare tip de fiier exterior poate fi reprezentat cu un icon specific1.2 pe ecran1.4 Trebuie oferite mijloace ca pozele ce reprezint tipurile de fiiere1.2 externe s poat fi definite de utilizator1.5 Cnd utilizatorul selecteaz o poz ce reprezint un fiier, efectul1.2 seleciei este aplicarea instrumentului asociat acelui tip de fiier1.2asupra fiierului selectat

Definiie de cerin utilizator

Specificaie de cerin sistem


Cine citete cerinele?

Manageri ai clientuluiUtilizatori finali de sistem

Ingineri ai clientuluiManageri de dezvoltare

Arhiteci de sistem

Utilizatori finali de sistemIngineri ai clientului

Arhiteci de sistemDezvoltatori software

Ingineri ai clientului (posibil)Arhiteci de sistem

Dezvoltatori software

Cerineutilizator

Cerinesistem

Specificaii deproiectare


Cerine funcionale i ne-funcionale

l Cerine funcionale Descrieri ale serviciilor pe care trebuie s le ofere sistemul,

cum trebuie s reacioneze i s se comporte sistemul n situaii particulare.

l Cerine ne-funcionale Constrngeri asupra serviciilor sau funciilor oferite de

sistem cum ar fi constrngeri de timp, constrngeri ale procesului de dezvoltare, standarde, etc.

l Cerine specifice domeniului problemei Cerine ce provin din mediul de utilizare a sistemului.


Cerine funcionale

l Descriu funcionalitatea sau serviciile sistemului.

l Depind de tipul de software i de tipul de utilizatori ce vor folosi sistemul.

l Cerinele funcionale pot fi fraze abstracte de descriu ceea ce face sistemul, dar ele pot descrie sistemul n detaliu.


Sistemul LIBSYS (exemplu)

l Este un sistem tip bibliotec ce ofer o interfa unic la un numr de baze de date cu articole din diferite biblioteci.

l Utilizatorii pot cuta, aduce i tipri aceste articole pentru studiu personal.


Exemple de cerine funcionalel Utilizatorul trebuie s poat cuta articole n

toate bazele de date sau ntr-un subset selectat.l Sistemul trebuie s ofere instrumente de

vizualizare potrivite pentru citirea articolelor.l Fiecare comand trebuie s aib alocat un

identificator unic (ORDER_ID).


Imprecizii ale cerinelor

l Problemele apar atunci cnd cerinele nu sunt enunate precis.

l Cerinele ambigue pot fi interpretate diferit de utilizatori i dezvoltatori.

l De exemplu termenul instrumente de vizualizare potrivite Intenia utilizatorului instrumente de vizualizare

speciale pentru fiecare tip de document; Interpretarea dezvoltatorului oferirea unui editor de

text care s prezinte coninutul documentului.


Completitudinea i consistena cerinelor

l n principiu, cerinele trebuie s fie complete i consistente.

l Complete Trebuie s includ descrieri ale tuturor

facilitilor.l Consistente

Nu trebuie s existe conflicte sau contradicii n descrierea facilitilor sistemului.

l n practic, este imposibil realizarea unui document de cerine complete i consistente.


Cerine ne-funcionale

l Acestea definesc proprietile i constrngerile sistemului cum ar fi fiabilitate, timp de rspuns i cerine de stocare. Constrngerile sunt proprieti ale componentelor de stocare de date, reprezentri ale sistemului, etc.

l Pot fi specificate cerine de proces care impun un anumit sistem CASE, un limbaj de programare sau o metod de dezvoltare.

l Cerinele ne-funcionale pot fi mai critice dect cele funcionale. Dac primele nu sunt ndeplinite, sistemul este inutilizabil.


Clasificarea cerinelor ne-funcionale

l Cerine de produs Sunt cerine care specific lucruri pe care produsul trebuie s le

ndeplineasc legat de viteza de execuie, fiabilitate, etc.l Cerine de organizare

Cerine care sunt consecine ale politicii i procedurilor organizaiei cum ar fi standarde de proces folosite, cerine de implementare, etc.

l Cerine externe Cerine care provin din factori externi sistemului i procesului

de dezvoltare cum ar fi cerine de interoperabilitate, cerine legislative, etc.


Tipuri de cerine ne-funcionale

Per fo rm an cere q u ir em e n ts

Sp acer e q u ir e m en ts

Usa b ilityr e q u ir em en ts

Effic ie n c yre q u ir em e n ts

Re lia b ilityr e q u ir em e n ts

Po rta b ilityre q u ir e m e n ts

In te r o p e r a b ilityre q u ir em e n ts

Eth ic alr e q u ir e m e n ts

Leg is lativ ere q u ir em e n ts

Im p lem e n ta tio nre q u ir e m e n ts

Stan d ar d sre q u ir em en ts

De li ve ryre q u ir em e n ts

Safe tyre q u ir em e n ts

Pri vac yr e q u ir em e n ts

Pro d uc tr e q u ir em e n ts

Org an is atio n alre q u ir em e n ts

Ex te rn alr e q u ir e m e n ts

No n -fun c tio n alre q u ir em e n ts


Exemple de cerine ne-funcionalel Cerine de produs

8.1 Interfaa cu utilizatorul pentru sistemul LIBSYS trebuie s fie implementat ca pagini HTML simple fr cadre (frames) sau Java applets.

l Cerine de organizare9.3.2 Procesul de dezvoltare i documentele rezultate se

vor conforma celor definite n XYZCo-SP-STAN-95.l Cerine externe

7.6.5 Sistemul nu trebuie s ofere alte informaii personale legate de clieni n afar de numele lor.


Cerine i scopuril Cerinele ne-funcionale pot fi foarte greu de exprimat ntr-

un mod precis, iar cerinele imprecise pot fi greu verificate. l Scop

O intenie general a utilizatorului, cum ar fi uurina n utilizare.l Cerin ne-funcional verificabil

O cerin ce folosete un sistem de msur pentru a putea fi obiectiv testat.

l Scopurile sunt utile dezvoltatorilor n msura n care cuprind inteniile utilizatorilor de sistem.


Exemple

l Un scop al sistemului Sistemul trebuie s fie uor de utilizat de operatori

experimentai i trebuie organizat astfel nct erorile de utilizare s fie minimizate.

l O cerin ne-funcional verificabil Operatorii experimentai trebuie s poat folosi

funcionalitatea sistemului dup un total de dou ore de nvare. Dup aceast perioad numrul mediu al erorilor fcute de operatorii experimentai nu trebuie s depeasc dou pe zi.


Uniti de msur pentru cerine

Proprietate Unitate de msur

Viteza Tranzacii/secund procesate Timp de rspuns Timp de mprosptare pe ecran

Dimensiune M Bytes Numr de cipuri ROM/RAM

Uurin de utilizare Timp de nvare Numrul de ferestre de ajutor

Fiabilitate Timpul mediu pn la eroare Probabilitatea de indisponibilitate Rata de apariie a erorilor Disponibilitate

Robustee Timp de restart dup eroare Procentul de evenimente ce cauzeaz erori Probabilitatea de corupere a datelor la erori

Portabilitate Procentul de instruciuni ce depind de mediul int de implementare Numrul de medii int de implementare


Interaciunea cerinelor

l Conflictele dintre diferite cerine ne-funcionale sunt un lucru obinuit n sistemele complexe.

l Sistem folosit n navete spaiale Pentru a minimiza greutatea, numrul de cipuri

separate din sistem trebuie minimizat. Pentru a minimiza consumul de putere, trebuie

folosite cipuri cu consum redus. Totui, folosirea cipurilor cu consum redus poate

nsemna c vor fi folosite mai multe cipuri. Care cerin este mai important (mai critic)?


Cerine din domeniul aplicaiei

l Descriu caracteristici ale sistemului i faciliti care reflect domeniul specific de lucru al aplicaiei.

l Ele pot fi cerine funcionale, constrngeri asupra altor cerine sau pot defini calcule specifice.

l Dac aceste cerine nu sunt ndeplinite, sistemul poate fi inutilizabil.


Cerine din domeniul aplicaiei LIBSYSl Trebuie s existe o interfa utilizator standard

pentru toate bazele de date, interfa bazat pe standardul Z39.50.

l Datorit restriciilor de copyright, unele documente trebuie terse imediat dup ce au fost aduse. n funcie de cerinele utilizatorului, aceste documente pot fi doar printate local sau pe o imprimant de reea.


Probleme ale cerinelor din domeniul aplicaiei

l nelegerea cerinelor Cerinele sunt exprimate ntr-un limbaj specific

domeniului aplicaiei; Acest limbaj nu este ntotdeauna neles de inginerii

software ce dezvolt sistemul.l Cerine implicite

Specialitii domeniului neleg domeniul att de bine nct nu se gndesc c este nevoie s exprime explicit aceste cerine.


Cerine utilizator

l Trebuie s descrie cerine funcionale sau ne-funcionale ntr-un mod care s fie neles de ctre utilizatorii sistemului care nu au cunotine tehnice de detaliu.

l Cerinele utilizator sunt definite folosind limbajul natural, tabele i diagrame, n msura n care pot fi nelese de ctre toi utilizatorii.


Probleme legate de exprimarea n limbaj natural

l Lipsa de claritate Este greu s obii precizie fr s faci documentul

dificil de citit.l Confuzia cerinelor

Cerinele funcionale i cele ne-funcionale tind s fie amestecate.

l Amalgamarea cerinelor Diferite cerine pot fi exprimate mpreun.


Cerine utilizator LIBSYS

4..5 Sistemul LIBSYS trebuie s ofere un sistem de contabilitate care s in nregistr ri ale tuturor pl ilor f cute de utilizatorii sistemului . Managerii sistemului pot configura acest sistem de contabilitate astfel nct utilizatorii frecven i s poat beneficia de reduceri .


Probleme ale cerinelor

l Cerinele includ att informaie conceptual ct i de detaliu

l Cerinele amestec tipuri diferite de cerine


Sfaturi pentru scrierea cerinelorl Inventeaz un format standard i folosete-l

pentru toate cerinele.l Folosete limbajul ntr-un mod consistent.

Folosete trebuie pentru cerinele obligatorii i ar trebui pentru cerinele de dorit.

l Scoate n eviden prile cheie ale cerinelor.l Evit folosirea jargonului informatic.


Cerine de sistem

l Sunt specificaii mai detaliate ale funcionalitii sistemului, ale serviciilor sau constrngerilor.

l Ele vor fi baza pentru proiectarea sistemului.l Pot fi ncorporate ntr-un contract.l Cerinele de sistem pot fi definite sau ilustrate

folosind diferite modele de sistem.


Cerinele i proiectarea

l n principiu, cerinele trebuie s exprime ceea ce va face sistemul, iar proiectarea trebuie s descrie cum va face sistemul aceste lucruri.

l n practic, cerinele i proiectarea sunt inseparabile O arhitectur de sistem poate fi proiectat pentru a

structura cerinele; Sistemul poate interopera cu alte sisteme care

genereaz cerine de proiectare; Folosirea unei proiectri specifice poate fi o cerin

din domeniul aplicaiei.


Probleme ale specificrii n limbaj natural

l Ambiguitate Cititorii i scriitorii de cerine trebuie s interpreteze

aceleai cuvinte n acelai fel. Limbajul natural este ambiguu, ceea ce face lucrurile dificile.

l Flexibilitate prea mare Acelai lucru poate fi spus n mai multe feluri n

specifiaie.l Lipsa modularizrii

Structurile limbajului natural nu sunt adecvate pentru a structura cerinele de sistem.


Alternative la specificaii n limbaj natural

Nota ie Descriere Limbaj natural structurat

Aceast abordare depinde de definirea unor abloane standard pentru exprimarea cerin elor.

Limbaje de descriere a proiect rii

Aceast abordare folose te limbaje asem n toare cu limbajele de programare , dar cu facilit i mai abstracte pentru a specifica cerin ele prin definirea unui model opera ional al sistemului. Aceast abordare nu este pre mult folosit ast zi , cu toate c poate fi util pentru specifica iile de interfe e.

Nota ii grafice Un limbaj grafic, suplimentat de note de text, folosit pentru a defini cerin ele func ionale ale sistemului. Ast zi se folosesc descrieri de tip use -case (cazuri de utilizare) i diagrame de secven .

Specifica ii matematice

Acestea sunt nota ii bazate pe concepte matematice cum ar fi automate cu st ri finite. Aceste specifica ii neambigue reduc discut iile dintre client i contractor legate de func ionalitatea sistemului. Pe de alt parte majoritatea clien ilor nu n eleg specifica iile formale i au mari rezerve n a le accepta ca i contract.


Specificaii n limbaj structurat

l Libertatea scriitorului de cerine este limitat de un ablon predefinit pentru cerine.

l Toate cerinele sunt scrise ntr-o manier standard.

l Terminologia folosit n descrieri poate fi limitat.l Avantajul este c se menine expresivitatea

limbajului natural, dar este impus un grad de uniformizare a specificaiilor.


abloane de specificaii

l Definirea funciei sau a entitii.l Descrierea intrrilor i a provenienei lor.l Descrierea ieirilor i a destinaiei lor.l Indicarea altor entiti necesare.l Pre i post condiii (dac este necesar).l Efecte secundare (laterale) ale funciei.


abloane de specificaii

Insulin Pump/Control Software/SRS/3.3.2

Funcie Calculeaz doza de insulin: Nivelul sigur de zahr

Descriere Calculeaz doza de insulin ce trebuie administrat cnd nivelul msurat de zah este n

zona de siguran ntre 3 i 7 uniti.

Intrri Citirea nivelul curent de zahr (r2), i precedentele dou citiri (r0 and r1)

Surs Nivelul curent de zahr de la senzor. Alte citiri din memorie.

Ieiri DozaCalculat doza de insulin ce trebuie administrat

Destinaie Bucla principal de control

Aciune: DozaCalculat este zero dac nivelul zahrului este stabil sau n cdere sau dac nivelul este n cretere, dar rata de cretere scade. Dac nivelul crete i rata de cretere crete i ea, atunci DozaCalculat se obine mprind diferena dintre nivelul curent al zahrului i nivelul precedent la 4 i rotunjind rezultatul. Dac rezultatul este rotunjit la zero atunci DozaCalculat este doza minim ce poate fi administrat.

Necesit Dou citiri precedente pentru a putea fi calculat rata modificrii nivelului de zahr.

Pre-condiie Rezervorul de insulin conine cel puin doza maxim de insulin..

Post-condiie r0 este nlocuit de r1, apoi r1 este nlocuit de r2

Efecte-secundare Nici unul


Modele grafice

l Modelele grafice sunt foarte utile cnd trebuie s ari cum se schimb starea sistemului sau cnd trebuie specificate secvene de aciuni.


Diagrame de secven

l Arat secvena evenimentelor care apar n timpul unei interaciuni a utilizatorului cu sistemul.

l Se citesc de sus n jos pentru a nelege ordinea n care apar aciunile.

l Scoaterea banilor dintr-un ATM Validarea cardului; Prelucrarea cerinei; Completarea tranzaciei.


Diagram de secven pentru scoaterea banilor dintr-un ATM

ATM Database

CardCard number

Card OKPIN request

PINOption menu

invalid card

Withdraw request

Amount request

Amount

Balance request

Balance

insufficient cash

Debit (amount)

Debit response

Card

Card removed

Cash

Cash removedReceipt

Validate card

Handle request

Completetransaction


Documentul de cerine

l Documentul de cerine este exprimarea oficial a ceea ce se cere de la dezvoltatorii sistemului.

l Trebuie s includ att definiii ale cerinelor utilizator ct i specificaii ale cerinelor de sistem.

l NU este un document de proiectare. Pe ct este posibil, trebuie s exprime CE trebuie s fac sistemul i nu CUM trebuie s fac


Utilizatorii documentului de cerine

Use the requirements todevelop validation tests for

the system

Use the requirementsdocument to plan a bid forthe system and to plan the

system development process

Use the requirements tounderstand what system is to

be developed

System testengineers

Managers

Systemengineers

Specify the requirements andread them to check that they

meet their needs. Theyspecify changes to the

requirements

Systemcustomers

Use the requirements to helpunderstand the system and

the relationships between itsparts

Systemmaintenance

engineers


Standardul IEEE pentru cerine

l Definete o structur generic pentru documentul de cerine ce trebuie creat pentru un sistem specific. Introducere. Descriere general. Cerine specifice. Apendice. Index.


Structur propus pentru documentul de cerine

l Prefal Introducerel Glosarl Definirea cerinelor utilizatorl Arhitectura sistemuluil Specificarea cerinelor de sisteml Modele de sisteml Evoluia sistemuluil Apendicel Index


Concluzii

l Cerinele exprim ceea ce trebuie s fac sistemul i definete constrngerile asupra operrii sau implementrii.

l Cerinele funcionale exprim serviciile pe care le va oferi sistemul.

l Cerinele ne-funcionale constrng sistemul sau procesul de dezvoltare.

l Cerinele utilizator sunt exprimri de nivel nalt a ceea ce trebuie s fac sistemul. Cerinele utilizator trebuie scrise n limbaj natural, eventual folosind tabele i diagrame.


Concluzii

l Cerinele de sistem trebuie s descrie funciile oferite de sistem.

l Un document de cerine software este o exprimare oficial a cerinelor sistemului.

l Standardul IEEE este un punct de start pentru definirea unor standarde mai detaliate de specificare a cerinelor.

CAPITOLUL 2FIABILITATEA PRODUSELOR SOFTWARE.

2.1 Rolul standardelor n asigurarea calitii i fiabilitii software

Domeniul calitii software-ului a fost pus n discuie pentru prima dat ntr-o conferin internaional organizat de N.A.T.O., n anul 1968, cnd s-au analizat coninutul i semnificaia domeniului cunoscut actualmente sub denumirea de ingineria software-ului (software engineering).

Simpozioanele i conferinele internaionale ce au avut loc dup 1968, avnd ca tematic calitatea software-ului, ca i cercetrile i experimentrile fcute, au relevat complexitatea acestui domeniu, precum i multitudinea de probleme care apar legat de specificarea, realizarea, msurarea i evaluarea calitii software-ului pe ntregul ciclu de via (asigurarea calitii software).ISO (Organizaia Internaional de Standardizare) i IEC (Comisia Electrotehnic Internaional) alctuiesc sistemul specializat n ceea ce privete standardizarea internaional.

Organismele naionale care sunt membre ale ISO sau IEC, iau parte la elaborarea standardelor internaionale prin intermediul comitetelor tehnice desemnate de organizaia respectiv, n scopul abordrii unor domenii specifice ale activitii tehnice.

Alte organizaii internaionale, guvernamentale i neguvernamentale, n colaborare cu ISO i IEC, iau parte, de asemenea, la activitatea aceasta.

n domeniul tehnologiei informaiei ISO i IEC au creat un comitet tehnic comun, ISO/IEC JTC1.

Proiectele Standardelor Internaionale care sunt adoptate de acest comitet tehnic comun sunt trimise organismelor naionale care, n urma studiului efectuat, i exprim votul vizavi de un anumit proiect de standard.

Adoptarea i publicarea ca standard internaional impun adeziunea a unui procent de minim 75% din numrul organismelor naionale care i-au exprimat votul.

Pe msur ce numrul i importana aplicaiilor software au crescut, de asemenea a crescut i cerina de calitate pe care trebuie s o aib n vedere orice organizaie (firm) care dezvolt i comercializeaz produse software, ea reprezentnd adevrata carte de vizit a respectivei instituii, a crei transparen, recunoatere i certificare permit competitivitatea i prosperitatea ei .

Pe plan mondial, cercetrile i realizrile viznd calitatea software sunt naintate, att n mediul universitar ct i cel industrial. Ele au fost dinamizate datorit sporirii concurenei internaionale, schimbrilor profunde n tehnologia de elaborare a software-ului, cerinelor noi i complexe ale clienilor i de aderena la standarde (de ex.: ISO 9126).

Companii mari, care vnd produse din ramura tehnologiei informaiei, cum ar fi: Microsoft, IBM, Hewlett-Packard, Verilog-Frana, Datamat-Italia i-au elaborat strategii pe termen lung pentru conducerea calitii globale, avnd un rol primordial activitile manageriale i de msurare a calitii software-ului pe ntreg ciclul de via.

Totui, rezultatele obinute de acestea nu sunt generalizate i utilizate pe scar larg, fie datorit faptului c unele firme nu-i fac publice strategiile proprii de obinere i monitorizare a calitii produselor software livrate, fie graie costurilor financiare mari care au fcut ca numai organizaiile mari, care au resurse bneti substaniale, s beneficieze de implementarea lor n scopul meninerii competitivitii i a asigurrii unui avantaj pe piaa concurenial de produse i servicii din ramura tehnologiei informaiei.

Pe plan intern, calitatea software (sau caracteristici ale asigurrii ei) a fost studiat de specialiti din centre de cercetare (ICI), mediile universitare (ATM, UPB, ASE), ct i de organizaii industriale.

1

S-a acordat o atenie deosebit terminologiei i aspectelor de ordin conceptual din domeniul calitii software, prelundu-se i adaptndu-se rezultate ale firmelor de prestigiu n domeniu, publicate n reviste i cri de specialitate.

Rezultatele cercetrilor i experimentrilor ntreprinse n mediul universitar i industrial au fost concretizate prin publicarea a peste 40 de lucrri de specialitate, n perioada 1982-1994 .

O atenie aparte a fost acordat fiabilitii software-ului, studii i experimentri fiind ntreprinse n cadrul ICI i instituiilor de nvmnt superior (ASE, UPB, ATM), drept urmare se poate aprecia c s-a format un grup de specialiti care posed cunotine tehnice i care au acumulat experien n domeniu pe baza experimentelor i studiilor de caz ntreprinse.

Nu se pot spune prea multe lucruri pozitive n ceea ce privete societile care se ocup cu realizarea i comercializarea produselor din domeniul tehnologiei informaiei, unde activitile de conducere i asigurare a calitii software-ului sunt foarte slab exprimate.

Cercetrile din domeniul ingineriei software-ului abordeaz implicit i explicit domeniul calitii software-ului.

Tratarea implicit a calitii se refer la metode, tehnici i instrumente de realizare (analiz, proiectare, programare) care s aib ca obiectiv final obinerea de software cu un nivel mare de calitate.

elul specialitilor este de a elabora i implementa tehnologii pentru asigurarea i mbuntirea calitii software.

Abordarea explicit vizeaz cercetarea direct (nemijlocit) a calitii, avnd ca obiective principale:

definirea terminologiei i a noiunilor principale ale calitii software-ului; stabilirea i clasificarea caracteristicilor de calitate; construirea metodelor de specificare, msurare, estimare i evaluare a calitii software-ului; elaborarea listei de indicatori ai calitii software-ului.

Importana standardelor ce descriu calitatea (de ex. seria de standarde ISO 9000) rezult din faptul c standardele ISO au fost preluate de un numr mare de organisme de standardizare naionale i regionale.

Unele organizaii de standardizare folosesc standardele ISO fr a le modifica, altele au introdus sisteme proprii de numerotare, textul fiind acelai cu cel al standardelor ISO.

Sunt multe organizaii care produc standarde n SUA i alte ri.n industria de aprare avem de-a face cu standardele DOD (Departament of Defence) care

se folosesc de muli ani. O serie de standarde ale departamentului de aprare au fost preluate i adoptate n sectorul comercial al produciei de organizaii precum IEEE (Institute for Electrical on Engineers), ASTM (The American Society for Testing and Materials), UL (Underwriters Laboratories) i SAE (Society for Automative Engineers).

n ceea ce privete fiabilitatea, ca una dintre principalele caracteristici de calitate software, ea a fost abordat indirect, prin standardele de asigurare a calitii software n ansamblu (ISO 9000, ISO 9126, i altele) sau direct, prin standarde care vizau problematica definirii terminologiei, msurrii i evalurii fiabilitii software pe ntreg ciclul de via, standarde publicate att de ISO/IEC, ct i de alte organisme i organizaii internaionale.

Mai jos se propune o list cu unele dintre standardele de fiabilitate (plus alte standarde la care se fac referine) cunoscute i existente pe plan mondial, dar i n ara noastr i pe care autorul le-a putut consulta prin intermediul IRS (Institutul Romn de Standarde):

N u m e s t a n d a r dT i t l u

ANSI/IEEE std. 729-1983[XXXX83] IEEE Standard Glossary of Software Engineering Terminology.

2

ANSI/IEEE std. 730-1984[XXXX84] IEEE Standard for Software Quality Assurance Plans.

ANSI/IEEE std. 1012-1986[XXXX86] IEEE Standard for Software Verification and Validation Plans.

ISO 8402-1994[XXXa94] Management and Assurance of quality - vocabulary.

N u m e s t a n d a r d T i t l uIEEE std. 982.1-1988[XXXa88] IEEE Standard Dictionary of Measures

to Produce Reliable Software.IEEE std. 982.2-1989[XXXa89] IEEE Guide for the Use of Standard

Dictionary of Measures to Produce Reliable Software (982.1 - 1988).

DD 198:1991[XXXb91](standard britanic)

Guide to Assessment of Reliability of Systems Containing Software.

BS 5760:Part 0:1985[XXXa85](standard britanic)

Introductory Guide to Reliability.

BS 5760:Part 1:1985[XXXb85](standard britanic)

Guide to Reliability and Maintainability Programme Management.

BS 5760:Part 6:1991[XXXa91](standard britanic, identic cu IEC 1014:1989)

Guides to Programmes for Reliability Growth.

ISO 8930-1987[XXXa87] General Principles on Reliability for Structures. List of Equivalent Terms.

UTE C20-317 U:1990[XXXa90](standard Frana)

Programmes de Croisance le Fiabilit.

XP X60-500:1988[XXXb88](standard Frana)

Terminologie relative la Fiabilit - Maintenabilit-Disponibilit.

Creterea continu a importanei acordate fiabilitii software-ului de ctre specialiti se explic prin elaborarea de noi standarde de fiabilitate (un standard AIAA pentru fiabilitatea software a fost aprobat n 1993[XXXX93] i alte standarde IEEE sunt sub dezvoltare) i prin crearea unei noi discipline-Software Reability Engineering (SRE).

Ingineria fiabilitii software se maturizeaz prin extinderea standardelor i prin promovarea lor.

Creterea comunitii de cercetare n SRE este de aproximativ 35% pe an, fapt ce explic importana acordat acestei discipline aflat n ascensiune.

2.2 Fiabilitatea, o caracteristic a calitii software-ului reflectat de standardele internaionale ISO 9000 i ISO 9126

2.2.1 Caracteristicile de calitate software

Convenional, inginerii software au considerat c responsabilitatea lor sunt rezultatele tehnice ale furnizrii unui produs software care execut nite funcii conform specificaiilor.

Cel mai important lucru este s se obin calitatea prin controlarea metodelor de producere i nu a produsului nsui.

3

Folosirea tehnicilor noi e posibil s creasc fezabilitatea i s reduc riscurile implicate n obinerea sigur a calitii dorite.

De exemplu, metodele formale pot duce la realizarea unor nivele nalte de fiabilitate, iar fixarea de prototipuri poate crete ansa atingerii nivelelor dorite n utilizarea produsului.

La elaborarea produselor software, caracteristicile de calitate sunt privite difereniat. Se poate pune accent la un moment dat pe realizarea la cote superioare a unei anumite caracteristici de calitate.

Celelalte caracteristici vor avea niveluri influenate direct de caracteristica prioritar, care trebuie meninut ntre limite care nu afecteaz nivelul global al performanei produsului.

Programele sunt elaborate astfel nct s rspund cerinelor de prelucrare ale beneficiarilor, dar n acelai timp s reflecte posibilitile materiale i financiare ale realizatorului i ale beneficiarilor. Dac la proiectare primeaz o anumit caracteristic, odat cu trecerea la noi versiuni ale programului, se poate modifica ierarhizarea caracteristicilor n raport cu criteriul importanei.

Caracteristicile i atributele de calitate ale produselor program formeaz un sistem complex, dinamic; creterea nivelului unei anumite caracteristici influeneaz pozitiv nivelul altor caracteristici, dar pot exista i situaii conflictuale.

De aceea trebuie asigurat echilibrul necesar ncadrrii produselor program ntre limitele admise ale performanei, prin utilizarea tehnicilor de analiz - proiectare - programare adecvate, dup ce s-au evaluat efectele lor.

2.2.2 Clasificarea caracteristicilor de calitate

Exist mai multe criterii de clasificare a lor: faza ciclului de via a produsului program n care se pun n eviden caracteristici:

exist caracteristici de calitate evideniate n etapele de elaborare a produsului, iar alte caracteristici apar n etapele de efectuare de modificri n structura produsului pentru a-i asigura meninerea n funciune.

specificitatea produsului program care impune ca o caracteristic s fie prioritar, iar celelalte caracteristici secundare; persoana care elaboreaz, utilizeaz sau menine n utilizare produsul software, care poate evidenia prezena sau absena unei caracteristici de calitate.

Cercetrile specialitilor au condus la elaborarea unei structuri conceptuale a sistemului de caracteristici cunoscut sub numele de modelul calitii software-ului. Modelul a fost creat pentru prima dat de Barry Boehm i colaboratorii si de la TRW Systems Group. Ulterior a fost rafinat i extins de James McCall, P. Richard i G. Walters - modelul a fcut obiectul standardizrii i este recomandat de ISO prin standardul ISO/IEC 9126-1991.

Componentele calitii de nivel nalt, uzual numite factori de calitate, sunt considerate n termeni ai componentelor de calitate de nivel sczut, criterii, consistente cu viziunea dezvolttorilor de sistem al calitii.

Aceast concepie conduce la modelul: factor de calitate (caracteristic), criteriu de calitate (subcaracteristica) i metrici de

calitate, schematizat n fig. 1.

4

metrici metrici

factor (caracteristic)

(subcaracteristic)criteriu 1 criteriu n

Fig. 1. Relaia caracteristici-subcaracteristici-metrici

. . .

Caracteristicile de calitate reprezint punctul de vedere al utilizatorului i al efului de proiect asupra calitii, folosind la definirea cerinelor utilizatorului i la stabilirea obiectivelor de calitate pentru sistemul de programe.

Subcaracteristicile au semnificaie tehnic i sunt relevante pentru personalul de specialitate (analiti, proiectani, programatori).

Ele faciliteaz comunicarea ntre eful de proiect i personalul de specialitate pentru atingerea obiectivelor de calitate.

Subcaracteristicile se definesc pentru componentele sistemului de programe i diferitele forme de reprezentare (cerine, specificaii, cod surs, documentaie de utilizare, .a.) pe parcursul ciclului de via.

La ultimul nivel se definesc metricile, care permit msurarea subcaracteristicilor i, n consecin, a caracteristicilor de pe primul nivel.

2.2.3 Relaiile dintre caracteristici

ntre caracteristici exist relaii de subordonare i de dependen ce sunt reflectate n mod diferit de modelele calitii (ISO 9126, Esprit (recomandat de European organization for Quality), Boehm, McCall) , aa cum se vede n fig. 2.

Relaiile ierarhice de subordonare sunt definite prin structura sistemului de caracteristici i difer de la un model la altul.

Relaiile de influen de tip conflictual semnific faptul c pe msur ce crete nivelul unei caracteristici, este de ateptat ca nivelele celeilalte caracteristici s scad.

Relaiile de influen de tip complementar au urmtoarea semnificaie:- dac nivelul unei caracteristici crete, atunci este de ateptat ca i nivelul celorlalte caracteristici s creasc. Cunoaterea relaiilor i a interdependenelor ntre caracteristici e necesar n toate fazele de specificare, determinare i evaluare a calitii sistemelor de programe, n special n faza de stabilire a obiectivelor de calitate.

n dezvoltarea i utilizarea unui model de calitate pentru un anumit tip de sistem de programe, e foarte important s se includ caracteristici de calitate ct mai independente.

2.2.4 Modelul calitii software din ISO 9126

Prin modelul ISO 9126 se recomand utilizarea urmtorului set de caracteristici:

5

Relaii

Ierarhice De influen

Conflictuale Complementare

Fig. 2 Relaiile ntre caracteristici

- funcionalitate, utilizabilitate, fiabilitate, eficien, mentenabilitate i portabilitate, ca n figura 3:

Mai jos se d o descriere pe scurt a semnificaiei caracteristicilor n modelul ISO/IEC 9126:

Tabelul 1. Caracteristici de calitate n modelul ISO/IEC 9126

Caracteristic Semnificaie

FUNCIONALITATE

- prezena i adecvana setului de funciuni fa de specificaii;- atributele produsului sunt legate de obinerea rezultatelor corecte sau convenite (ex. gradul necesar de precizie al valorilor);- posibilitatea de interaciune a produsului cu altele specificate; - aderarea la standarde, convenii, reglementri i alte prescripii similare, legate de domeniul de aplicaie;- posibilitatea produsului de a preveni accesul neautorizat, accidental sau deliberat, la programe sau date.

FIABILITATE

- gradul de maturitate al produsului, respectiv frecvena cderilor din cauza erorilor produsului software;- capacitatea produsului de a-i menine un anumit nivel specificat de performan n caz de eroare;- posibilitatea restabilirii nivelului de performan i refacerea datelor n cazul unei erori; timpul i efortul necesar pentru aceasta.

UTILIZABILITATE- uurina n nelegere, efortul utilizatorului de a recunoate conceptul logic i aplicabilitatea lui;- uurina n operare;- uurina n nvarea aplicrii produsului.

PERFORMANE- comportamentul n timp, eficiena ca timp de rspuns - pe tipuri diverse de prelucrri, ratele de transfer sub condiii diferite de ncrcare i configuraii diferite;- comportamentul resurselor, respectiv consumul de memorie intern i extern n diferite condiii.

MENTENABILITATE- rapiditatea i exactitatea cu care se poate identifica o eroare n execuie din mesajele produsului i cauzele acesteia;- existena n documentaie a procedurilor i facilitilor de ntreinere a produsului.

PORTABILITATE- posibilitatea de adaptare la alte medii specifice, fr a apela faciliti din afara produsului;- posibilitatea de instalare a produsului ntr-un mediu specificat;- gradul de aderare a produsului la standardele i reglementrile legate de portabilitate.

6

Fig. 3 Modelul ISO/IEC 9126

Mentenabilitate

Maturitate

Toleran la erori

Capacitatea de recuperare

Funcionalitate

Utilizabilitate

Portabilitate

Fiabilitate

Eficien

Caracteristicici

Subcaracteristici

Conform acestui standard, fiabilitatea e definit ca fiind capacitatea software-ului de a menine nivelul su de performan n condiii stabilite pentru o perioad dat de timp.

Uzura sau mbtrnirea nu apare n software. Limitrile fiabilitii sunt generate de erorile n cerine, proiectare i implementare. ntreruperile care apar din cauza acestor erori depind de modul cum e utilizat produsul software (profilul operaional) i de opiunile selectate n program, mai degrab dect de trecerea timpului.

n definiia ISO 8402, fiabilitatea reprezint Aptitudinea unui produs de a ndeplini o funcie cerut....... n acest standard,

funcionalitatea este numai una din caracteristicile calitii software-ului. Ca urmare, definiia fiabilitii a fost extrapolat la meninerea nivelului su de performan n loc de executarea unei funcii cerute.

n ceea ce privete subcaracteristicile, se poate aprecia c nivelul lor este mai detaliat. Vom exemplifica aici doar subcaracteristicile specifice fiabilitii, cele aparinnd celorlalte caracteristici putndu-se afla prin consultarea standardului (se pot deduce i din semnificaia dat caracteristicilor n tabelul 1). Ele sunt:

maturitatea - atribute ale software-ului ce vizeaz frecvena ntreruperilor datorate erorilor software; tolerana la defectri - aptitudinea software de a menine un nivel specificat de funcionare n cazul apariiei erorilor sau al violrii interfeei sale; capacitatea de recuperare - atribute software ce reflect capacitatea de restabilire a nivelului su de funcionare i de recuperare a datelor afectate direct de apariia unor erori, precum i timpul i efortul necesare pentru aceasta.

Definiia dat calitii din ISO 8402 exprim punctul de vedere al utilizatorilor, la fel ca i caracteristicile din acest standard.

Utilizatorii evalueaz software-ul fr a ti aspectele interne de realizare i interaciune software.

ntrebrile utilizatorilor pot fi de forma: funciile cerute sunt disponibile n software? ct de fiabil este software-ul? ct de eficient este software-ul? este software-ul uor de utilizat? care-i dificultatea transferrii software-ului n alt mediu?

Realizatorii sunt responsabili de producerea software-ului care va satisface cerinele de calitate, fiind interesai att n calitatea produsului intermediar, ct i n cea a produsului final.

Pentru a evalua calitatea produsului intermediar n fiecare faz a ciclului de realizare, realizatorii trebuie s foloseasc msuri diferite pentru aceleai caracteristici, nefiind universale pentru toate fazele ciclului de via..

Punctul de vedere al realizatorilor trebuie s exprime i pe cel al celor care ntrein software-ul.

Administratorul (managerul de proiect) este interesat de calitate pe ansamblu, dect de o caracteristic anume i de aceea va trebui s fie acordate ponderi caracteristicilor individuale, care s oglindeasc cerinele comerciale.

Administratorul echilibreaz mbuntirea calitii cu criteriile de administrare, cum ar fi ntrzierea fa de timpul planificat sau depirea costului, dorind optimizarea calitii n cadrul limitelor costului, resurselor umane i a timpului prevzut. Ultimul nivel n modelul calitii, reprezentat de metrici, nu este nc standardizat.

Se las la latitudinea organizaiilor s-i defineasc metrici specifice.Unii specialiti folosesc alt terminologie pentru perechea caracteristici - subcaracteristici:

- caracteristici - atribute n modelul Boehm;- factori - subfactori n modelul McCall.

Modelele difer att prin modul de ierarhizare a caracteristicilor i subcaracteristicilor, ct i prin definiiile utilizate.

2.2.5 Standardele ISO 9000

7

Conceptul de management al calitii totale se axeaz pe lucrrile de pionierat ale lui Armand Feigenbaum, Dr.Edward Deming, Dr. Joseph Juran i alii.

O lucrare de referin n acest domeniu este Total Quality Control, publicat de A. Feigenbaum nc din 1951.

Calitatea total s-a aplicat

Ingineria programarii

Documents

Transcript of Ingineria programarii