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.

2
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 ……………

3
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,
o Ele au fost produse in conformitate cu standardele prevazute,

4
 o 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 Utilizatori
o Conducatori de proiect
o Ingineri software
o Membri ai achipei de asigurare a calitatii,
o 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 Inchisa: a fost rezolvata

o De actualizat: documentul va fi actualizat (modificat)

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

Fiecare intrunire se termina prin:

o O decizie, daca este necesara o noua intrunire

o Posibil, o autorizare de a se trece la faza urmatoare
o 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
defectelor
 Verificarea faptului ca defectele au fost corectate si nu au fost introduse
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.