UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI Fondul Social European Instrumente Structurale OIPOSDRU UNIVERSITATEA

MINISTERUL MUNCII, PSD DRU 2007 - 2013 2007 - 2013 TEHNICĂ DE

FAMILIEI ŞI CONSTRUCŢII DIN
PROTECTIEI SOCIALE BUCUREŞTI
AMPOSDRU

Investeşte în oameni !
Proiect cofinanţat din FONDUL SOCIAL EUROPEAN
prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane 2007 – 2013
Axa prioritară 1: „EDUCAŢIA ŞI FORMAREA PROFESIONALĂ ÎN SPRIJINUL CREŞTERII ECONOMICE ŞI DEZVOLTĂRII SOCIETĂŢII
BAZATE PE CUNOAŞTERE”
Domeniul major de intervenţie 1.2 „Calitate în învăţământul superior”
Cerere de propuneri de proiecte: nr. 86 „Universitate pentru viitor”
Titlul proiectului: Reţea naţională de centre pentru dezvoltarea programelor de studii cu rute flexibile şi a unor instrumente didactice la specializarea de
licenţă şi masterat, din domeniul Ingineria Sistemelor
Numărul de identificare al contractului: POSDRU/86/1.2/S/63806

Gabriela Varvara
Ingineria programarii I

Curs 11
Verificarea si validarea sistemelor software

Partener P4

MINISTERUL EDUCAŢIEI, UNIVERSITATEA UNIVERSITATEA TEHNICĂ UNIVERSITATEA TEHNICĂ UNIVERSITATEA SC ASTI AUTOMATION SRL
CERCETĂRII, TINERETULUI ”POLITEHNICA” DIN ”GHEORGHE ASACHI” ”POLITEHNICA”
ŞI SPORTULUI DIN CLUJ-NAPOCA DIN DIN
BUCUREŞTI IAŞI TIMIŞOARA
 <Ingineria programarii I>
Objectivele prelegerii Gabriela Varvara>

Definirea notiunilor de verificare si validare software cu sublinierea diferentelor

dintre acestea
Definirea procesului de inspectie software si a rolului acestuia in contextul
verificarii si validarii
Definirea analizei statice ca tehnica de verificare
Descrierea procesului de dezvoltare software Cleanroom ce permite evitarea
defectelor si nu inlaturarea lor

Subiecte tratate:
Planificarea procesului de verificare si validare
Inspectiile software
Automatizarea analizei statice
Procesul de dezvoltare Cleanroom

2
 <Ingineria programarii I>
Verificarea si validarea (V&V) Gabriela Varvara>

Definitie:
Verificarea – are drept scop analiza produsului software din punct de vedere
al conformarii acestuia cu propriile specificatii (atesta constructia corecta a
produsului)
Validarea – are drept scop analiza produsului software din punct de vedere
al conformarii comportamentului acestuia cu cel dorit de utilizator ( atesta
constructia produsului corect)

Procesul de verificare si validare (V&V):

Se deruleaza pe toata perioada de viata a produsului software, in fiecare
etapa de dezvoltare
Are 2 obiective principale:
Descoperirea defectelor sistemului
Evaluarea utilitatii si a gradului de uzabilitate a produsului dezvoltat

3
 <Ingineria programarii I>
Scopul V&V Gabriela Varvara>

Asigurarea unui grad de incredere ridicat referitor la adecvanta produsului

dezvoltat la scopul pentru care acesta a fost creat. Acest lucru nu implica
eliminarea totala a defectelor.
Garantarea faptului ca produsul este suficient de bun refera doar contextul
particular de folosire pentru care acesta a fost dezvoltat.

Increderea ce va trebui asigurata refera:

Functionarea produsului – cu cat produsul este mai critic pentru organizatia
beneficiarului cu atat increderea in modul corect de functionare a acestuia
trebuie sa fie mai mare.
Asteptarile utilizatorului – exista produse de la care utilizatorul nu se
asteapta la foarte multe rezultate. Pentru acestea nu trebuie asigurat un
nivel de incredere ridicat.
Contextul de piata – livrarea rapida a unui produs pe piata este uneori mai
importanta decat gasirea tuturor defectelor acestuia.

4
 <Ingineria programarii I>
Verificarea statica si dinamica Gabriela Varvara>

Inspectia software – are drept obiectiv analiza reprezentarii statice a sistemului

in vederea descoperirii defectelor (inspectia statica). Poate fi completata cu
documentare automatizata, iar pentru analiza codului pot fi folosite utilitare
specifice de analiza statica.
Testarea software – are drept scop executia sistemului software cu aplicarea
unor seturi de date de intrare (numite date de test) si observarea modului de
comportare a acestuia. Este o forma de verificare dinamica.
Inspectii
software

Specificare Proiectare Specificatii Proiectare

Program
cerinte nivel inalt formale detaliata

Prototip Testare
program

5
 <Ingineria programarii I>
Testarea software Gabriela Varvara>

Pune in evidenta prezenta erorilor si nu absenta acestora

Pentru cerintele nefunctionale, testarea este singura forma de verificare si
validare
Testarea trebuie asociata cu verificarea statica pentru a asigura convergenta
V&V

Tipuri de testare:
Testarea defectelor – proiectarea testelor va urmari descoperirea defectelor.
Un test reusit va pune in evidenta prezenta defectului.

Testarea de validare:
Verifica modul in care produsul satisface cerintele beneficiarului
Un test trece cu succes daca demonstreaza ca o anumita cerinta a fost
implementata adecvat

6
 <Ingineria programarii I>
Testare versus depanare Gabriela Varvara>

Procesele de testare, respectiv depanare sunt diferite:

V&V are ca obiectiv detectarea defectelor produsului dezvoltat
Depanarea are ca obiectiv localizarea si repararea erorilor detectate de V&V.
Ea presupune formularea unei ipoteze privind comportarea sistemului si apoi
verificarea acesteia cu scopul identificarii erorii.

Rezultate Specificare Cazuri

testare testare

Localizare Proiectare Reparare

eroare reparare eroare Retestare
eroare

7
 <Ingineria programarii I>
Planificarea V&V Gabriela Varvara>

Determina gradul de eficienta a proceselor de inspectie si testare,

pentru a caror derulare se consuma resurse materiale si umane
importante

Planificarea va trebui sa inceapa in fazele incipiente ale procesului de

dezvoltare

In plan se vor include, echilibrat, activitati de verificare statica si testare

Planificarea testarii va urmari, primordial, definirea standardelor de

derulare a procesului de testare si nu descrierea produselor de testare

8
 Planificarea testarii pentru ciclul de dezvoltare in V
<Ingineria programarii I>
(documentatie tehnica) Gabriela Varvara>

9
 <Ingineria programarii I>
Structura documentului de planificare a testarii software Gabriela Varvara>

Descrierea fazelor majore ale procesului de testare

Cerinte de trasabilitate – modalitati de acces in vederea testarii fiecarei cerinte
individuale a utilizatorului
Elemente testate – presupune specificarea produselor (module, componente,
etc.) supuse testarii
Calendarul activitatilor de testare si resursele alocate pe fiecare etapa
temporala
Proceduri de inregistrare a rezultatelor testarii – necesare in auditarea
procesului de testare
Cerinte hardware si software – estimarea echipamentului si a utilitarelor
necesare in procesul de testare
Constrangeri ce pot afecta procesul de testare – resursa umana, echipament,
soft folosit, restrictii de timp, etc.

10
 <Ingineria programarii I>
Inspectia software Gabriela Varvara>

Tehnica eficienta in identificarea erorilor sistemului

Implica examinarea reprezentarilor (modelelor din fazele de inginerie a
crintelor si design, date de configurare, de test, etc.) in cadrul unor sesiuni
de review, in vederea depistarii anomaliilor si defectelor.
Inspectia nu implica executia codului, putand fi aplicata inainte de
implementare
La o singura inspectie pot fi identificate un numar mare de erori de tip
diferit. In cazul testarii un defect poate masca alt defect, , astfel incat
identificarea completa implica mai multe executii.
Permite reutilizarea cunostintelor din domeniu si de programare, astfel incat
reviewerii recunosc rapid erorile tipice.

11
 <Ingineria programarii I>
Inspectii versus testare Gabriela Varvara>

Inspectia si testarea reprezinta tehnici de verificare complementare si nu opuse

Ambele tehnici trebuie folosite in procesul V&V

Inspectiile verifica conformarea cu specificatiile si nu cu cerintele reale ale

beneficiarului

Inspectiile nu pot verifica conformarea cu specificatiile nefunctionale precum

uzabilitatea, performanta, etc.

Inspectia pe codul sursa are drept scop identificarea si nu remedierea erorilor

(erori logice, conditii eronate, etc.)

12
 <Ingineria programarii I>
Preconditii pentru realizarea inspectiilor Gabriela Varvara>

Trebuie avuta la dispozitie o specificatie precisa

Membrii echipei trebuie sa fie familiari cu standardele de lucru ale organizatiei

dezvoltatoare a produsului

Trebuie avut acces la o reprezentare a sistemului (model, artifact) sau la cod

sursa corect sintactic

Trebuie pregatita o lista de verificare (checklist) a erorilor vizate

Managerii trebuie sa accepte ca inspectia va creste costurile inca din fazele

timpurii ale ciclului de dezvoltare

Managerii nu trebuie sa foloseasca inspectiile pentru evaluarea (depistarea

angajatilor ce fac erori) personalului propriu

13
 <Ingineria programarii I>
Procesul de inspectie Gabriela Varvara>

Planificare

Overview Continuare

Pregatire Efectuare
inviduala corectii
Intalnire
inspectie

14
 <Ingineria programarii I>
Procedura de inspectie Gabriela Varvara>

Modelul/codul si documentele asociate sunt distribuite echipei inainte de

demararea inspectiei

Se prezinta, pe scurt, produsul analizat echipei de inspectie

Are loc inspectia si se noteaza erorile identificate

Se realizeaza modificarile ce au drept scop remedierea erorilor descoperite

In unele cazuri se impune reluarea procesului de inspectie (reinspectie)

15
 <Ingineria programarii I>
Roluri in procesul de inspectie Gabriela Varvara>

Autor/proprietar – programatorul/proiectantul responsabil cu producerea

artifactului (program/document) supus analizei
Inspector – identifica erori/omisiuni/inconsistente in program/documente.
Poate identifica si probleme mai generale ce exced scopul echipei de inspectie.
Prezentator – prezinta programul/documentul in cadrul unei intalniri pentru
inspectie (review)
Inregistrator – inregistreaza rezultatele procesului derulat in cadrul intalnirii de
inspectie
Moderator – conduce si faciliteaza procesul de inspectie. Raporteaza
rezultatele catre moderatorul sef.
Moderatorul sef – raspunde de imbunatatirea procesului de inspectie,
actualizeaza lista de verificare a erorilor, dezvolta noi standarde, etc.

16
 <Ingineria programarii I>
Liste de verificare in procesul de inspectie Gabriela Varvara>

Lista cu erorile uzuale – va trebui folosita pe toata durata inspectiei

Lista de verificare depinde pentru inspectia pe cod de limbajul de

implementare folosit si reflecta cele mai frecvente erori ce apar pentru acesta

Lista este cu atat mai mare cu cat tipologia erorilor este mai putin restransa

Exemple: initializare, denumire constante, terminare bucle control, limite

masiv, etc

17
 <Ingineria programarii I>
Exemplu de lista de verificare (1) Gabriela Varvara>

Erori in date:
Sunt initializate toate variabilele inainte de folosirea valorilor lor?
Au fost declarate toate constantele?
Limita superioara a masivelor este egala cu dimensiunea sau dimensiunea
-1?
Daca se folosesc siruri de caractere s-a atribuit un delimitator explicit?
Exista posibiltatea depasirii bufferelor?
Erori de control:
Pentru fiecare instructiune conditionala, conditia este corecta?
Fiecare bucla se termina cu certitudine?
Instructiunile de calcul sunt imbricate corect?
Instructiunile switch au prevazute toate cazurile? Pentru acestea s-au
inserat corect instructiunile break?
Erori intrare/iesire:
Sunt folosite toate variabilele de intrare?
Au toate variabilele de iesire asignate valori inainte de iesirea propriu-zisa?
Pot sa produca fenomene de coruptie valori neasteptate ale intrarilor?

18
 <Ingineria programarii I>
Exemplu de lista de verificare (2) Gabriela Varvara>

Erori pe interfata:
Au toate apelurile de functii/metode numar corect de parametrii?
Exista potrivire intre tipurile de parametri formali si cei actuali?
Sunt parametrii mentionati in ordinea corecta?
Componentele ce acceseaza zone partajate de memorie, au acelasi model
de structurare a memoriei partajate?
Erori pe managementul memorarii:
Daca o structura cu legaturi se modifica, s-au reatribuit corect toate
legaturile?
Daca se foloseste alocarea dinamica, s-a alocat corect memoria?
S-a realizat dezalocarea explicita pentru spatiul ce nu mai este necesar?
Erori de management a exceptiilor:
Au fost luate in considerare toate conditiile posibile de eroare?

19
 <Ingineria programarii I>
Frecvente uzuale pentru procesul de inspectie Gabriela Varvara>

500 instructiuni/ora pe durata procesului de overview.

125 instructiuni cod sursa/ora pe durata pregatirii individuale
90-125 instructiuni/ora pe durata inspectiei propriu-zise.

Inspectiile reprezinta un proces costisitor.

Inspectarea a 500 linii de cod costa aproximativ 40 ore munca/om.

20
 <Ingineria programarii I>
Automatizarea analizei statice Gabriela Varvara>

Analizoarele statice sunt utilitare software ce proceseaza un text sursa

Ele parseaza textul programului in incercarea de a descoperi potentiale conditii
eronate si le semnaleaza echipei ce realizeaza V&V
Sunt extrem de efective ca instrumente auxiliare in procesul de inspectie, dar
nu il pot inlocui pe acesta
Exemplu:
Erori in date:
Variabile utilizate inaintea initializarii
Variabile declarate si neutilizate niciodata
Variabile asignate de 2 ori si nefolosite intre asignari
Posibile violari pentru limitele masivelor
Variabile nedeclarate,

Etc.

21
 <Ingineria programarii I>
Fazele analizei statice Gabriela Varvara>
Analiza controlului executiei – verificarea buclelor spre a nu avea puncte de intrare/iesire multiple,
identificare cod neexecutat
Analiza datelor utilizate – detectia variabilelor neinitializate, variabilelor scrise de 2 ori fara
reasignare, variabile declarate si neutilizate, etc.
Analiza interfetei – verificarea consistentei intre declaratiile rutinelor/procedurilor si modul de apel
al acestora.
Analiza fluxului informational – identificarea dependentelor variabilelor de iesire. Nu detecteaza
anomalii, dar pune in vizor informatia necesara inspectiei pe cod / review.
Analiza cailor – identifica in program caile de executie precum si instructiunile ce vor fi executate
pe fiecare cale. Poate fi utila in procesele de review.

Parcurgerea acestor stadii genereaza un volum mare de informatii. Drept consecinta, se

recomanda folosirea acestora cu discernamant.

Analiza statica se recomanda pentru limbaje cum ar fi C, unde definitiile de tip sunt slab verificate,
determinand un numar mare de erori dedetectabil de catre compilator. Ea devine mai putin
eficienta pentru limbaje precum Java, ce au mecanisme puternice de verificare a tipului ce vor
permite detectarea unui numar mare de erori chiar din faza de compilare.

22
 <Ingineria programarii I>
Exemplu de analiza statica Gabriela Varvara>
138% more lint_ex.c
#include <stdio.h>
printarray (Anarray)
int Anarray;
{ printf(“%d”,Anarray); }

main ()
{
int Anarray[5]; int i; char c;
printarray (Anarray, i, c);
printarray (Anarray) ;
}

139% cc lint_ex.c
140% lint lint_ex.c

lint_ex.c(10): warning: c may be used before set

lint_ex.c(10): warning: i may be used before set
printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10)
printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10)
printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11)
printf returns value which is always ignored

23
 <Ingineria programarii I>
Utilizarea metodelor formale in procesul de verificare Gabriela Varvara>

Metodele formale pot fi utilizate ori de cate ori s-a produs o specificatie
matematica pentru sistemul ce urmeaza a fi dezvoltat.
Reprezinta o tehnica de verificare statica ultimativa.
Implica o analiza matematica detaliata a respectivei specificatii si poate produce
argumente formale ce valideaza conformarea programului la specificatia sa
matematica.
Argumente in favoarea folosirii extinse/restranse a metodelor formale:
Deoarece produc specificatii matematice, ele implica o analiza detaliata a
cerintelor si descopera erorile cu o probabilitate crescuta
Implica folosirea unor notatii speciale cu care specialistii din domeniu nu
sunt intotdeauna familiarizati.
Pot detecta erori de implementare inaintea testarii
Dezvoltarea unei specificatii este costisitoare; verificarea raportarii
programului la specificatie este si mai costisitoare.
Este posibil sa se atinga acelasi nivel de incredere in sistem prin folosirea
unor tehnici simple, mai putin costisitoare de V&V.

24
 <Ingineria programarii I>
Ciclul de dezvoltare Cleanroom Gabriela Varvara>

Numele acestui proces de dezvoltare provine din procesul cleanroom din

fabricatia semiconductorilor.
Filozofia acestui proces – evitarea defectelor si nu inlaturarea acestora.
Acest proces de dezvoltare are la baza:
Dezvoltarea incrementala;
Specificarea formala;
Verificarea statica folosind argumente de validare a corectitudinii;
Testare cu metode statistice pentru a verifica fiabilitatea produsului.

25
 <Ingineria programarii I>
Diagrama procesului Cleanroom (documentatie tehnica) Gabriela Varvara>

26
 <Ingineria programarii I>
Caracteristicile procesului Cleanroom Gabriela Varvara>

Specificatii formale prin utilizarea unui model de tranzitie a starilor;

Dezvoltare incrementala cu prioritizarea incrementelor de catre client;
Programare structurata – in program se vor folosi constructii abstracte si un
control limitat;
Verificare statica prin intermediul unor inspectii riguroase;
Testarea statistica a sistemului.

27
Legatura intre specificatia formala si inspectii pentru
<Ingineria programarii I>
procesul Cleanroom Gabriela Varvara>

Modelul bazat pe tranzitia starilor reprezinta o specificatie de sistem si procesul

de inspectie va verifica comportarea programului in raport cu acest model
Metoda de programare este definita astfel incat corespondenta intre model si
sistem este clara.
Argumente de ordin matematic (dar nu demonstratii) sunt folosite pentru a
creste increderea in procesul de inspectie.

28
 <Ingineria programarii I>
Echipele din procesul Cleanroom Gabriela Varvara>

Echipa de specificare – dezvolta si intretine specificatia sistemului

Echipa de dezvoltare – dezvolta si verifica produsul software. Pe durata

dezvoltarii produsul nu este executat, nici macar compilat.

Echipa de certificare – dezvolta o serie de teste statistice la care va fi supus

sistemul dupa dezvoltare. Pentru evaluarea gradului de fiabilitate si a
determinarii pragului de acceptabilitate se vor folosi modele de crestere a
fiabilitatii.

29
 <Ingineria programarii I>
Evaluarea procesului Cleanroom Gabriela Varvara>

Rezultatele unui proces Cleanroom sunt remarcabile. Produsele livrate nu au

mai avut decat extrem de putine erori descoperite la beneficiar.

Evaluari independente au ajuns la concluzia ca procesul este cu mult mai

costisitor ca alte cicluri de dezvoltare.

procesul nu este folosit pe scara larga deoarece suscita experienta si motivare

din partea inginerilor de sistem implicati.

30