Verificarea si validarea Software

Prin aceste activitati se verifica daca software-ul satisface specificatiile sale, in timpul fiecarei faze a ciclului sau de dezvoltare. Se realizeaza: Verificand ca fiecare articol software indeplineste cerintele specificate; Verificand fiecare articol software inainte de a fi utilizat ca intrare pentru o alta activitate; Asigurand ca fiecare articol software este verificat, pe cat posibil, de o persoana diferita de aceea care l-a produs; Asigurand ca efortul de verificare si validare este adecvat pentru ca fiecare articol software sa fie operational.

Obiectivul activitatilor de verificare si validare este de a reduce erorile software la un nivel acceptabil. Efortul necesar poate reaprezenta 30-90% din totalul resurselor proiectului, in functie de complexitatea si gradul de risc al functionarii necorespunzatoare a software-ului. Organizarea activitatilor de verificare si validare este inclusa in activitatile de management ale proiectului software. Verificarea: sunt produsele in conformitate cu cerintele lor specificate? Validarea : sunt produsele in conformitate cu cerintele clientului (utilizatorilor)? Verificarea inseamna: Actul de a stabili si documenta faptul ca articolele, procesele, serviciile sau documentele sunt in conformitate cu cerintele specificate. 1

Validarea este, conform definitiei din ANSI/IEEE: Procesul de a evalua un sistem sau o componenta in timpul sau la sfarsitul procesului de dezvoltare pentru a determina daca satisface cerintele specificate.

Activitatile de verificare includ:

Revizii (Reviews). O revizie este o intrunire in care este prezentat un document pentru comentare sau aprobare. Tipurile de revizii sunt:

Revizii tehnice Prezentari (Walkthroughs) Inspectii Audit-uri

Urmarire (tracing): se definesc relatii intre produse ale procesului de dezvoltare, de exemplu dintre o cerinta software si cerinte utilizator. Demonstratii formale: pot fi aplicate pentru anumite aspecte ale sistemului daca se folosesc metode formale pentru analiza si proiectare. Testare: nu poate demonstra absenta erorilor ci doar prezenta lor.

Toate activitatile de verificare si validare sunt documentate in Planul de Verificare si Validare.

Activitatile de verificare pe parcursul Ciclului de Viata

Documentul de cerinte sotware este verificat fata de documentul de cerinte utilizator, conform sectiunii SR din planul de verificare si validare. ADD SRD DDD --ADD Code --DDD Unit tests verifica faptul ca modulele software functioneaza corect ca entitati independente, conform specificatiei din DDD si sectiunii UT din SVVP. Integration tests. System tests . Acceptance tests

1. Revizii
O revizie este o intrunire in timpul careia un produs sau set de produse este prezentat personalului care participa la proiect, managerilor, utilizatorilor, clientilor sau altor persoane interesate, pentru comentarii sau aprobare. Reviziile pot fi formale sau neformale. o Reviziile formale au obiective specifice si reguli de procedura explicite. Prin ele se cauta identificarea defectelor si a discrepantelor software fata de specificatii, planuri si standarde. o Reviziile neformale nu au proceduri predefinite. Sunt uzuale trei tipuri de revizii formale:

Revizii tehnice Prezentari (walkthroughs) Audituri.

Inspectiile software reprezinta o alternativa mai riguroasa a Prezentarilor si sunt foarte recomandate pentru software cu cerinte stringente de fiabilitate, securitate si siguranta.

1.1. Revizii tehnice

O revizie tehnica evalueaza documente pentru a verifica progresul conform planului.

Obiectivul unei revizii este de a asigura ca:

o

Articolele revizuite sunt conforme cu specificatiile facute in fazele anterioare, Ele au fost produse in conformitate cu standardele prevazute, 4

Fiecare modificare a fost implementata corect si afecteaza numai acele parti identificate prin specificatia modificarii.

Componenta echipei de revizie difera in functie de faza din ciclul de viata in acre are loc revizia. Astfel, din echipa pot face parte:
o o o o o

Utilizatori Conducatori de proiect Ingineri software Membri ai achipei de asigurare a calitatii, Experti independenti

Procesul de revizie incepe atunci cand documentele revizuite sunt stabile si complete.

Inainte de intrunire: o Fiecare membru al echipei studiaza documentele revizuite si inregistreaza fiecare problema intalnita. Inregistrarea este transmisa autorului documentului revizuit. o Autorul studiaza problemele care i-au fost transmise si intocmeste un raspuns care este transmis conducatorului echipei de revizie. o Acesta le clasifica in: majore, minore, de editare. In timpul intrunirii:

Se discuta fiecare problema transmisa si se stabileste starea sa:

o o

Inchisa: a fost rezolvata De actualizat: documentul va fi actualizat (modificat)

Actiune: cu specificarea persoanei responsabile si data pana la care documentul trebuie completat Rejectare: problema este inchisa fara actualizare sau actiune

Fiecare intrunire se termina prin:

o o o

O decizie, daca este necesara o noua intrunire Posibil, o autorizare de a se trece la faza urmatoare Intocmirea unui raport in care sunt inscrise rezultatele intrunirii

1.2. Prezentari (Walkthroughs)

Acest tip de verificari sunt utile in evaluarea timpurie a documentelor, a modelelor si a codului, in fazele de Specificare a Cerintelor Software si Proiectare. O prezentare este o varianta de revizie tehnica in care autorul documentului revizuit participa la intrunire. Inainte de intrunire o Membrii echipei studiaza documentul revizuit In timpul intrunirii o Autorul prezinta documentul revizuit: aceasta este principala diferenta fata de o revizie tehnica, unde in timpul intrunirii se discuta doar problemele semnalate o Toate erorile, schimbarile si imbunatatirile sugerate sunt inregistrate, impreuna cu actiunile definite in timpul intrunirii. Obiectivul unei prezentari este de a evalua un element software specific (adica un document sau modul sursa). o Se cauta identificarea defectelor si se considera solutiile posibile. o Spre deosebire de celelalte forme de revizie, prezentarile au si un obiectiv secundar, de a educa si a rezolva probleme de stil. 6

1.3. Audituri
Un audit este o revizie independenta efectuata de un grup extern (persoane care nu fac parte din echipa de dezvoltare). Obiectivul unui audit este de a verifica faptul ca produsele si procesele software sunt in conformitate cu standardele, specificatiile si procedurile stabilite. Exemple:

Un audit fizic verifica prezenta tuturor articolelor din configuratie. Un audit functional verifica daca au fost efectuate toate testele. Un audit al codului verifica daca sunt respectate standardele de codare prevazute

Verificarile audit pot fi de rutina sau nu. o Exemple de audituri de rutina sunt cele fizice si functionale efectuate inainte de livrarea unui software o Audituri ne-uzuale pot fi initiate de clientul care primeste software-ul sau de echipa de management sau de asigurare a calitatii din organizatia care produce software-ul.

1.4. Inspectari
Inspectiile software pot fi utilizate pentru detectarea defectelor in proiectul de detaliu inainte de codare si in cod inainte de testare Pot fi de asemenea folosite pentru a verifica proiectarea cazurilor de test si a procedurilor de testare Sunt eficiente. Pot fi detectate peste 50% din numarul total de defecte introduse in timpul dezvoltarii Sunt economice deoarece reduc numarul de defecte si costul eliminarii lor. Se deosebesc de Parcurgeri prin: 7

Repetarea procesului pana la atingerea unui nivel de defecte acceptabil Analiza rezultatelor procesului si transmiterea lor inapoi pentru

imbunatatirea produsului Evitarea discutarii solutiilor in timpul intrunirii si concentrarea pe gasirea Verificarea faptului ca defectele au fost corectate si nu au fost introduse defectelor alte defecte

2.Urmarie
Urmarirea consta in stabilirea unei relatii intre doua sau mai multe produse ale procesului de dezvoltare. De exemplu, o relatie intre o cerinta data si elementul din proiect care implementeaza cerinta. Urmarirea se face in doua sensuri: Inainte Inapoi

Urmarirea Inainte cere ca fiecare intrare a unei faze sa fie in relatie cu o iesire a fazei. Se realizeaza cu ajutorul unei matrici in care se reprezinta corespondenta dintre intrari si iesiri. Pot rezulta intrari lipsa sau posibile duplicate-intrari care corespund la mai multe iesiri. Urmarirea Inapoi cere ca fiecare iesire a unei faze sa fie in relatie cu o intrare a fazei respective. Iesirile care nu au o relatie cu intrarile sunt un semn de eroare, exceptand cazurile in care intrarile sunt incomplete. Pe parcursul ciclului de viata software este necesar sa se urmareasca: 8

Cerintele utilizator fata de Cerintele software si invers; Cerintele software fata de descrierea componentelor de proiectare si invers; Testele unitare fata de modulele proiectului de detaliu si invers; Testele de integrare fata de unitatile arhitecturale si invers; Testele sistem fata de Cerintele software si invers; Testele de acceptare fata de Cerintele utilizator si invers.

Pentru ca urmarirea sa fie posibila toate cerintele si componentele trebuie sa fie identificabile conform unei conventii.

3. Demonstratii formale
Incearca sa demonstreze prin mijloace matematice faptul ca un software este corect. Testele demonstreaza empiric faptul ca intrari specifice conduc la rezultate specifice. Demonstratiile formale demonstreaza logic faptul ca toate intrarile care indeplinesc preconditii definite produc iesiri care satisfac postconditii definite Tehnicile de demonstrare formala sunt adesea dificil de justificat datorita efortului suplimentar, adaugat activitatilor de verificare mentionate mai inainte. In mod ideal, celelalte activitati de verificare nu ar mai fi necesare in cazul demonstratiilor formale, daca instrumentele de verificare utilizate in demonstratii sunt sigure!! Dificultatea exprimarii intr-o forma matematica a cerintelor software si a proiectului au impiedicat aplicarea pe scara larga a acestor tehnici. Metodele formale s-au bucurat de un interes mai larg si au avut succes in specificarea si verificarea protocoalelor de comunicatie si a sistemelor de securitate.