CALITATEAARII SOFTWARE

CALITATEA PROIECTARII SOFTWARE

Calitatea proiectarii unui produs software este o asertiune despre un proiect daca este sau nu bun (conformarea la specificatiile cerintelor ce au stat la baza proiectului).

Aceasta asertiune trebuie fundamentala evaluata. Trebuie sa avem niste criterii => metrici de calitate a proiectarii software.

Testare: - se examineaza cerintele sI se vede daca sunt respectate    (confirmare ca produsul respecta definitia cerintelor).

Cum realizam procedeele de testare ?

gasirea unor metode de testare a componentelor soft.

gasirea unor matrici de estimare a calitatii

Validarea     este o certificare de calitate a produsului. Operatia de validare se face prin revizii de proiect ale produsului software, reviziile fiind mecanisme de asigurare a calitatii produsului soft.

Scopul este gasirea anomaliilor in proiectare.

Forme ale reviziei

Inspectie deteliata

Inspectie structurata

Revizie formala

1. Inspectia detaliata

Este o inspectie care verifica conformitatea cu prevederile detaliate din specificatorul cerintelor.

Avem la dispozitie o tabela cu date care trebuie respectate (se bifeaza ce este bine).

2. Inspectia structurata

Se ocupa cu evolutia corecta a Proiectului intre faze conform structurii proiectului.

La fiecare sedinta se examineaza o componenta dintr-o structura. Pot fi discutate sI costuri de proiect.

3. Revizia formala

Examinarea in care detaliile nu sunt importante.

In programarea ESOLESS exista posibilitatea ca colegii sa aiba toate datele. Nu se mai fac astfel de sedinte.

Sedintele pot fi - in care fiecare explica produsul propriu

- in care se face scolarizarea utilizatorului

Matrice de calitate

- numarul de linii de program

- numarul ciclotronic -> se ia organigrama sI se face sub forma de diagrama de flux de date.

->numarul de cicluri dintr-un graf.

ELSE

DO

CASE

Numarul ciclotronic= E-N-1 (E - edges <<arce>>, N - noduri).

C = a*E+b*N (C - complexitatea)

Cuplarea

Pt. masurarea cuplarii exista metode care se bazeaza pe numarul de in sI out.

Fen IN - dat de numarul de linii care intraintr-o componenta

- numarul de apeluri din program la acea componenta

Fen OUT - numarul de linii care ies din structura

- numarul de apeluri ce se fac la alte componente

Fen IN mare -> grad mare de cuplare

Fen OUT mare -> avem o componenta complexa care este un manager de aplicatii

Interfata spre utilizator

Foarte importanta pt. ca este imaginea produsului.

Pt. studiul interfetei    se apeleaza la psihologi sI alti care studiaza utilizatorul.

Reguli de respectat:

Set de chestionare trimise la utilizatori.

Livrare prototip specializat numai pe interfata.

Produsul in sine sa includa diverse cereri de informatie cu privire la modificarile de interfata dorite.

Implementare

Posibilitatea sI refolosirea produsuluu soft - sunt probleme de rezolvat.

Compatibilitatea - de masina

- de limbaj

Scopul este programul portabil (sa mearga pe c#t mai multe masini). Programul portabil este un program independentcarenu are nevoie de agenti externi. Independenta nu pota fi violata. Solutie -> lucram la o mica parte a programului

Validarea programelor

Verificare sI validare

Testare

Tipuri de verificari

Verificari statice - se fac fara ca programul sa ruleze.

- se verifica schitele.

- se face in faza de specificatii cerinte, proiectare, programare detaliata.

Testare dinamica

de sus in jos

de jos in sus

Testari de jos in sus:

Testarea de sus in jos

Se porneste de la programele mari. Se incepe cu modulul cel mai mare sI toate sub modulele sunt inlocuite cu programe de simulare (stubss). Se iau pe parcurs fiecare sI se desfasoara p#na se ajunge la bara.

Depanare de program

Faze:

Se cerceteaza situatia.

Se emit ipoteze.

Se verifica ipotezele.

Se identifica o cauza a erorii.

Se proiecteaza solutii.

Se implementeaza solutii.

Daca eroarea este mica se face modificarea local. Daca este mare este posibil ca tot proiectul sa fie intors cu una sua mai multe cicluri in urma.