Validarea Si Verificarea Sistemelor Critice

Noțiuni generale

Planificarea verificării și validării

Metode de validare

3.1. Validarea sistemelor critice

3.2. Validarea fiabilității

3.3. Profile operaționale

3.4. Predicția fiabilității

4. Metode de verificare

4.1. Recenzii. Tipuri de recenzii

4.1.1. Analiza codului

4.1.2. Inspecții de software

4.1.3. Prezentări (Walkthrough)

4.2. Metode formale

4.2.1. Modelul checking

4.2.2. Inferența logică

4.2.3. Derivarea de program

5. Concluzii

6. Bibliografie

Noțiuni generale

Verificarea și validarea reprezintă procesele prin care se stabilește dacă un produs software îndeplinește cerințele inițiale și îndeplinește scopul pentru care a fost dezvoltat.“ Împreună aceste doua procese se regăsesc sub denumirea controlul calității software. Este important de știut că verificarea și validarea nu sunt același lucru, cu toate că adese ori sunt confundate.

Pe scurt, verificarea asigură că produsul a fost dezvoltat corect , pe când validarea confirmă dacă produsul îndeplinește sau nu scopul pentru care a fost dezvoltat. Un produs este considerat validat dacă satisface nevoile consumatorului. Validarea presupune asigurarea că procesele de dezvoltare și verificare duc la realizarea unui produs ce respectă necesitațile si specificațiile inițiale. În cazul apariției unei probleme în cadrul procesului de dezvoltare sau verificarea, va fi necesară modelarea problemei folosind procedurile de validare (ce presupun si simulări) pentru a evita procesele invalide sau incomplete de dezvoltare/verificare. „Exista si proceduri de validare auxiliare care asigura ca o data ce a fost modelată problema inițială, produsul finit va respecta cerintele inițiale.”

Pe scurt , validarea poate fi definita prin intrebarea “Construiesc produsul potrivit?

Iar verificare: Construiesc corect produsul?”

Validarea este activitatea de acceptare a produsului final de către beneficiar. Acesta e mai puțin interesat de metodele folosite în realizarea programului. El urmărește dacă programul face ceea ce el așteaptă să facă, dacă rezultatele sunt obținute sub forma dorită și dacă sunt complete. Testarea făcută de către beneficiar nu se bazează pe date de test ci pe date reale. Se verifică funcționarea programului în condiții reale. În plus beneficiarul va verifica dacă există documentație pentru programul ce-l recepționează, în primul rând cea de utilizare, dar un beneficiar avizat nu uită să ceară documentația de realizare.

Verificarea este o activitate de durată, care începe din prima fază a realizării programului și se încheie la predarea lui, ea constând din:

– analiza specificațiilor;

– inspectarea proiectării, codificării și documentării;

– execuție simbolică a algoritmilor folosiți;

– testarea produsului;

– citirea documentației..

Verificare și validarea sistemelor critice are, evident, multe în comun cu validarea oricărui alt sistem. Procesele de V&V ar trebui sa demonstreze ca sistemul își îndeplinește specificațiile și că sunt realizate toate cerintele utilizatorului.

Scopul final al V&V este să stabilească încrederea că sistemul software se potrivește scopului său. Nivelul de încredere depinde de scopul sistemului, de așteptările utilizatorilor și de mediul de marketing:

.Funcția software. Nivelul de incredere cerut depinde de cât de critic este software-ul pentru o organizatie. De exemplu, nivelul de încredere cerut pentru un software care este utilizat într-un sistem critic din punct de vedere al funcționalității este mult mai mare decat cel necesar unui software prototip care incearcă să demonstreze idei noi.

Așteptările utilizatorilor. Utilizatorii nu se așteaptă ca software să funcționeze întotdeauna corect. Ei înțeleg aceste neajunsuri atunci când beneficiile sunt mai numeroase decât dezavantajele.

Mediul de marketing. Când un sistem este pus la vânzare, vânzătorii trebuie să ia în considerare programele competițoare, prețul pe care cumparatorii sunt dispuși să îl plăteasca pentru sistem și timpul necesar pentru livrarea produsului. Când utilizatorii nu sunt dispusi să plăteasca un pret mai ridicat, ei pot fi dispuși să tolereze mai multe erori. Toți acești factori trebuie să fie luați în considerare atunci cînd se decide asupra efortului care trebuie pus ăn procesul de V&V.

In procesul de V&V există 2 abordări complementare pentru sistemul de inspecție și analiză:

Inspecții de softare care analizează și verifică reprezentarea sistemului în documentație, diagrame de design și cod sursă. Inspecțiile software și analizele automate sunt tehnici statice de V&V, pentru că nu este nevoie a rula software-ul pe un calculator.

Testarea software implică rularea unei implementări a soft-ului cu date de test. Se examinează ieșirea și comportamentul pentru a verifica performanța necesară. Testarea este o tehnica dinamica de verificare si validare.

Sistemul se poate testa doar atunci când există un prototip sau o versiune executabilă a programului.

Verificarea si validarea sunt realizate pentru a stabili existența de defecte în sistem;

Debugging-ul este un proces care localizează defectele și le corectează;

Localizarea defectelor într-un program nu este întotdeauna un proces simplu, pentru că defectul poate să nu fie aproape de locul unde programul se defectează..

După ce un defect a fost descoperit, el trebuie corectat și sistemul trebuie revalidat. Se testează faptul că acestă corecție nu a introdus erori noi în sistem..

Planificarea verificării și validării

Verificarea și validarea sunt procese costisitoare. Pentru unele sistem, cum ar fi cele in timp real cu constrangeri nefuncționale complexe, mai mult de jumătate din bugetul de dezvoltarea a sistemului este cheltuit pe V&V. O planificare ingrijită este necesară pentru a obtine maximul din testare si inspecție și pentru a controla costurile procesului de verificare și validare.

model de dezvolate sistem software

Planificarea verificării și validării trebuie pornită la începutul procesului de dezvoltare. În figura de mai sus este prezentat un model de dezvolate de produs soft. El figureză că planurile de testare sunt derivate din specificațiile de sistem și design. Acest model împarte sistemul de V&V într-un anumit număr de stagii. Fiecare stagiu este condus de teste care au fost definite să inspecteze conformitatea programului cu designul și specificațiile produsului soft.

Din procesul de planificare V&V fac parte decizia privind raportul de tehnici de abordare statice și dinamice pentru validare și verificare, definirea de standarde și proceduri pentru inspecția software-ului, și definirea planului de testare.

Ca o regulă generală, cu cât un sistem este mai critic, cu atât mai mult efort ar trebui alocat tehnicilor de verificare statică.

Planificarea testării se concentrează cu stabilirea de standarde pentru procesul de testare, nu doar cu descrierea testării de produs. Pe lângă faptul că ajută managerii să aloce resurse și să estimeze programul de testare, planurile acestea sunt destinate și inginerilor implicați în design și realizarea testării.

Structura unui plan de testare software:

Procesul de testare : o descriere a fazelor majore ale procesului de testare; acestea pot fi ca cele descrise anterior

Urmărirea cerintelor: utilizatorii sunt interesțti în mod deosebit ca sistemul să își indeplimească cerințele și testarea ar trebui planificată astfel încât toate cerințele să fie testate individual

Componentele testate: componentele care trebuie testate vor fi specificate

Programul de testare: programul general de testare și alocarea resurselor

Inregistrarea procedurilor de testare: nu este suficient ca testele să fie realizate; rezultatele trebuie să fie inregistrate sistematic; trebuie să fie posibilă inspectarea faptului ca testul a fost realizat corect

Cerintele hardware si software: această secțiune ar trebui să stabilească ustensilele software utilizate și incarcarea hardware estimată

Constrângeri: constrangerile care afecteaza procesul de testare

Activități de verificare pe parcursul ciclului de viață

Documentul de cerințe software este verificat față de documentul de cerințe utilizator, conform sectiunii SR din planul de verificare și validare.

„ADD – SRD”

„DDD –ADD”

„Code –DDD” Unit tests „verifică faptul că modulele software funcționează corect ca entități independente, conform specificației din DDD și secțiunii UT din SVVP.”

„Integration tests” „System tests” „Acceptance tests”

Acestea sunt reprezentate in schema de mai jos.

Sursa foto: http://software-document.blogspot.ro/2011/06/software-verificatio-introduction.html

3. Metode de validare:

1.Validare în perspectivǎ reprezintă activitațile desfǎșurate înainte ca articolele noi sǎ fie lansate pentru a se asigura caracteristicile de interes care întrunesc standarde de funcționare corecte si sigure.

.2.Validare retrospectivǎ reprezintă un proces pentru articolele deja in uz, distribuție sau producție. Se reia evaluarea specificațiilor și așteptǎrilor de la produs, iar daca lipsesc date se întrerupe etapa curentǎ. Acest proces se realizeazǎ dacǎ se constatǎ lipsa realizǎrii unei validǎri de perspectivǎ, la schimbarea unor legislații sau standarde, la repunerea pe piațǎ a unor produse anterior excluse.

.3.Validare curentǎ are loc concomitent cu procesul de proiectare/dezvoltare.

3.1.Validarea sistemelor critice

Verificare și validarea sistemelor critice are, evident, multe în comun cu validarea oricărui alt sistem. Procesele de V&V ar trebui să demonstreze că sistemul își îndeplinește specificațiile și că sunt realizate toate cerintele utilizatorului. Totuși, pentru sisteme critice, unde este nevoie de o mare fiabilitate, teste și analize adiționale sunt necesare pentru a putea concluziona că sistemul este de încredere. Sunt două motive pentru care ar trebui făcut acest lucru:

Costul esecului: costurile și consecințele eșecului unui sistem critic sunt mult mai mari decât ale unui sistem care nu este critic; riscurile trebuie micșorate prin alocarea unei perioade mai mari de timp pentru verificare și validare; în mod uzual este mai ieftin să se găsească și să elimine erorile înainte ca sistemul să fie livrat, decât să se plătească pentru consecințele accidentelor sau perturbațiilor sistemului.

Validarea fiabilității atributelor: pentru garantarea că sistemul își îndeplinește cerințele de fiabilitate trebuie oferite documente oficiale; acest lucru necesită activități V&V specifice; în anumite cazuri anumite instituții trebuie să certifice că sistemul este sigur înainte ca el să poată fi livrat; pentru a putea obține o asemenea certificare trebuie proiectate proceduri speciale de V&V pentru a colecta dovezi despre fiabilitatea sistemului.

Pentru aceste motive, costurile V&V pentru sisteme critice sunt de obicei mult mai mari decât pentru alte clase de sisteme.

Deși procesele de validare a sistemelor critice se concentrează în mare parte pe validarea sistemului, activități relaționale cu acestea ar trebui să verifice că procesele de dezvoltare a sistemului au fost urmate.

3.2. Validarea fiabilitatii

Un numar de metode de masură au fost dezvoltate pentru a specifica cerințele de fiabilitate ale unui sistem. Pentru a valida că un sistem întrunește aceste cerințe, trebuie măsurată fiabilitatea lui din punctul de vedere al utilizatorului. Procesul de măsurarea a fiabilității este prezentat în figura următoare

Acest proces implica 4 etape:

Se începe cu studiul sistemelor existene de același tip pentru a stabili profilul operațional; un profil operațional identifică clasele de intrări ale sistemului și probabilitatea că aceste clase să apară în cazul folosirii uzuale

Se construiețte apoi un set de date test pentru a reflecta profilul operațional; se crează date cu aceleași probabilități ca și datele pentru sistemele studiate

Se testează sistemul folosind aceste date și se numară câte erori apar; timpul de apariție a acestor erori este de asemenea înregistrat

După ce au fost obținute un numar statistic semnificat de erori, se poate calcula fiabilitatea software

Această abordare se numeste testare statistică. Scopul acesteia este să stabilească fiabilitatea sistemului.. Acestă modalitate atractivă de abordare pentru măsurarea fiabilității nu este ușor de pus în practică. Principalele dificultăți întâlnite apar datorită:

Incertitudinii profilelor operaționale: profilele operaționale bazate pe experiența cu alte sisteme pot să nu reflecte precis utilizarea reala a sistemului.

Costurile crescute ale generării de date: se poate ca generarea unui volum mare de date necesare unui profil operațional să fie foarte costisitoare dacă nu poate fi facută în mod automat

Incertitudinea statistică atunci când este nevoie de fiabilitate foarte ridicată

Dezvoltarea unui profil operațional precis este posibil pentru anumite sisteme, cum ar fi sistemele de telecomunicații, care au o utilizare standardizată..

De departe cea mai bună cale de a genera datele necesare pentru măsurarea fiabilității este folosirea unui generator de date care să fie setat să ofere automat intrările potrivite pentru profilul operațional. Nu este posibil întotdeauna producerea automată a tuturor datelor de intrare. Setul de date pentru aceste sisteme trebuie generate manual, cu costuri considerabil mai mari.

Incertitudinea statistică este în general o problemă în măsurarea fiabilității unui sistem.

3.3. Profile Operaționale

Profilul operațional al software-ului reflectă cum va fi acesta folosit în practică. El conține specificațiile claselor de intrari și probabilitatea apariției fiecărei clase. Atunci când un nou software înlocuiește unul existent, este destul de usor să se stabilească modelul de utilizare a noului software. El ar trebui să corespundă cu modelul deja existent, cu mici schimbări datorită noilor funcționalități adăugate.

Profilul operațional este în așa fel încât intrările care au cea mai mare probabilitate să fie generate să intre intr-un număr mic de clase. Există un numar mare de clase unde intrarile sunt mai puțin probabile.

Atunci când un sistem software este nou și inovativ este dificil de anticipat cum va fi folosit și de aici să se genereze profilul operațional. Mulți utilizatori diferiți cu diferite așteptări pot folosi noul sistem. Nu există o bază de date anterioara de utilizare. Utilizatorii pot folosi sistemul în moduri neașteptate, care nu au fost anticipate de dezvoltatori.

O altă problemă care se adaugă este aceea că profilul operațional se poate modifica pe măsura ce sistemul este utilizat. Pe parcurs ce utilizatorii învață despre noul sistem și devin din ce în ce mai încrezători în el, încep să îl folosească în moduri mai sofisticate. Din această cauză unii specialiști consideră că nu se pot dezvolta profile operaționale 100% de încredere.

3.4. Predicția fiabilității

Sunt multe modele de dezvoltare a fiabilității care au fost deduse din experimente de fiabilitate într-un numar mare de domenii de aplicație. Cel mai simplu model care ilustrează modul de dezvoltare a fiabilitatii este funcția treaptă. Fiabilitatea crește cu o constantă de fiecare data când un set de erori sunt descoperite și reparate, o versiune noua de software fiind creată. Acest model presupune că reparațiile software sunt întotdeauna corect implementate și că de fiecare dată numarul de erori scade.

În practică totuși, erorile din software nu sunt întotdeauna reparate în debugging și când se modifică un program se adaugă erori noi. Probabilitatea aparitiei acestori erori poate fi mai mare decat probabilitatea ca eroarea originala sa fie reparata și în acest caz fiabilitatea în loc să crească, scade.

Modelele dezvoltate ulterior iau în considerare aceste considerente prin introducerea elemetului aleator în creșterea fiabilității. Fiecare reparație nu mai rezultă într-o îmbunătățire egală a fiabilității. Aceste modele permit și creșteri negative ale fiabilității (scăderi), atunci când reparațiile introduc noi erori. De asemenea modelează și faptul că pe măsură ce erorile sunt reparate, media de îmbunătățire a fiabilitatii scade.

Simplist, se poate prezice fiabilitatea prin potrivirea fiabilității măsurate cu un model cunoscut. Apoi se poate extrapola modelul la nivelul cerut de fiabilitate și să se observe când nivelul cerut de fiabilitate va fi atins, testarea și debugging-ul trebuind să continue până atunci.

4. Metode de verificare:

4.1. Recenzii;

4.2. Verificări formale.

Recenzii (Reviews) de software sunt reprezentate de întȃlniri pe parcursul cǎrora un produs este examinat de personalul care s-a ocupat de proiect, manageri, utilizatori, clienți sau alte pǎrți interesate.

Tipuri de recenziilor:

1) .Analiza codului (recenzia codului) care examinează sistematic codul sursǎ;

2). Inspecțiile software urmǎresc o procedurǎ strictǎ de depistare a defectelor.;

3) Prezentări (Walkthrough) – autorii organizeazǎ pentru toate parțile interesate o prezentare a proiectului, participanții avȃnd oportunitatea sǎ afle rǎspunsuri, sǎ sesizeze defecte sau neconcordanțe;

4). Recenziile tehnice înseamnă o echipa formatǎ din personal calificat sa care au rolul examineze dacǎ produsul este adecvat pentru uzul destinat și identificǎ discrepanțele cu standarde și specificații.

5). Auditurile informatice sunt realizate de personalul din exteriorul proiectului pentru a evalua conformitatea produsului cu specificațiile, standardele și acordurile contractuale inițiale.

4.1.1 Analiza codului Analiza codului verifică dacă programul codificat implementează corect proiectul verificat și nu violează cerințele de siguranță. În această fază, o bună parte din întrebări vor primi răspuns pentru prima dată. De exemplu, numărul liniilor de cod, resursa de memorie, încărcarea CPU pot fi observate și măsurate. Pot avea loc chiar reproiectări semnificative bazate pe parametrii codului actual. Codul permite o măsurare reală a dimensiunii, complexității și gradului de utilizarea al resurselor.. Analiza codului presupune:

Analiza logică a codului

Analiza logică a codului evaluează secvența de operațiuni reprezentate prin program. Analiza logicăma codului va detecta erorile logice din software. Această analiză este condusă pentru a realiza reconstrucția logică, reconstrucția ecuațiilor și decodarea memoriei.

Analiza codului pentru date

Analiza codului pentru date se concentrează asupra structurii și utilizării datelor în software-ul rezultat (codat). Obiectivul principal al acestei analize este de a verifica faptul că itemuri de date ce sunt definite și organizate sunt corect, complet și coerent definite.Această verificare este realizată prin compararea utilizării cu valorile tuturor itemelor de date din cod cu descrierea furnizată de materialele proiectului.

Analiza codului pentru interfete

Analiza codului pentru interfețe verifică compatibilitatea internă si externă a componentelor software. O componentă software este compusă dintr-un număr de segmente de cod care lucrează împreună pentru realizarea unei sarcini. Aceste segmente de cod trebuie să comunice între ele (fiecare cu fiecare), cu alte componente software sau hardware și cu operatorul uman pentru a realiza sarcina dată. Se verifică, în acest sens, dacă parametrii care se transmit de-a lungul interfețelor sunt proprii acestora.

Măsurarea complexității codului

Unul din scopurile măsurării complexității este tentativa de a o minimiza, pentru reducerea

probabilității de erori în sistem.Una dintre tehnicile cele mai importante pentru reducerea complexității este modularizarea. Complexitatea se va putea măsura, utilizând metricele McCabe sau tehnici similare.

Analiza actualizărilor limitelor proiectului

Criteriile pentru analiza proiectării limitelor utilizate în faza de proiectare în detaliu, sunt aplicate într-o noua iterație și codului final. În această fază, pot fi realizate testări reale care caracterizează comportamentul și performanțele software, în completarea analizei propriu-zise.

Se vor lua în considerare limitările fizice ale platformei hardware pentru implementarea dată.

Listele de control ale inspecțiilor codului (care includ codificarea standardelor)

Codificarea standardelor este bazată pe ghidul de stil și subseturile sigure ale limbajelor de programare. Listele de verificare sunt dezvoltate pe parcursul inspecțiilor formale pentru a facilita inspectarea codului în vederea demonstrării conformității acestuia cu codificarea standardelor.

4.1.2. Inspectii de software

Inspecția de software este un proces static al V&V în care sistemul software este revăzut pentru a găsi erori, omiteri și anomalii.

In general,inspecțiile se concentrează pe codul sursă, dar orice reprezentare citibilă a software-ului, așa cum ar fi cerințele sau design-ul, pot fi inspectate. Atunci când se inspectează un sistem, se folosesc cunoștințele despre acel sistem, despre domeniul de aplicare și despre limbajul de programare.

parametrii inspectiei tehnice

Ideea de inspectie nu este chiar noua. Există mai multe studii și experimente care demonstrează că inspecția este mai eficientă pentru descoperirea de defecte decât testarea.

Fagan a raportat că mai mult de 60% dintre erori dintr-un program pot fi detectate utilizând inspecții informale de program.

Mills a sugerat că o abordare mai formală a inspecției bazată pe corectitudinea argumentelor poate detecta 90% dintre erorile dintr-un program.

4.1.3. Prezentări (Walkthrough)

Acest tip de verificare este utilă în evaluarea timpurie a documentelor, a modelelor si a codului, în fazele de specificare a cerințelor software și proiectare. Obiectivul unei prezentări este de a evalua un element software specific prin identificarea defectelor și căutarea de soluții posiblie.Spre deosebire de celelate forma de revizie,prezentările au și un obiectiv secundar,acela de a educa.Toate erorile,schimbările și îmbunătățirile sugerate din timpul unei prezentări sunt înregistrate împreună cu acțiunile definite în timpul întrunirii.[3],[10]

4.2 Verificarea formală

Metodele formale de dezvoltare de software sunt bazate pe reprezentarea matematică a software-ului, în mod uzual ca o specificare formală. Aceste metode formale sunt în principal concentrate pe analiza matematică a specificațiilor, cu transformarea specificațiilor într-o reprezentare echivalentă, dar mai detaliată sau pe verificarea echivalentelor între formele de reprezentare.

Se poate spune că metodele formale sunt cele mai avansate metode de verificare statică. Ele au nevoie de analize detaliate ale specificațiilor de sistem și ale programului. Utilizarea lor este adesea scumpă și consumatoare de timp. În consecință, ele sunt folosite în dezvoltarea software-ului pentru sigurantă sau pentru situații critice.

Argumetul pentru utilizarea specificațiilor formale este acela că ele obligă o analiză detaliată a specificațiilor.

Verificarea formala demonstrează că programul dezvoltat întrunește toate specificațiile, și erorile de implementare nu compromit fiabilitatea sa.

Argumentul împotriva utilizarii specificațiilor formale este acela că utilizează notații specializate.

In anumite cazuri utilizarea metodelor formale conduc la dezvoltarea unor sisteme mai fiabile și mai sigure. Nu este nicio îndoială că specificațiile de sistem formale au o șansă mai mica de a conține anomalii care trebuie rezolvate, dar acest lucru nu este o garanție că software va fi fiabil 100% în utilizarea practică.

Verificarea formalǎ pentru software include mai multe tipuri de verificări:

1.Modelul checking;

2.Inferența logică;

3.Derivarea de program.

4.2.1. Model checking

Metoda model checking constǎ în explorarea sistematicǎ si exhaustivǎ a modelului matematic. Acest lucru este posibil atȃt pentru modelele finite cȃt și pentru cele infinite unde seturile infinite de stǎri pot fi reprezenate in mod finit prin abstractizare.

Aceastǎ metodǎ rezolvǎ urmatoarea problemǎ: dȃndu-se modelul unui sistem, se verificǎ dacǎ acesta indeplinește o anume specificație datǎ. Pentru a rezolva aceastǎ problemǎ dupa un algoritm, modelul sistemului și specificațiile acestuia vor fi formulate intr-un limbaj matematic precis: se verificǎ dacǎ o structurǎ datǎ satisface o formulǎ logicǎ datǎ.

Model checking-ul este un automat cu stǎri finite. Spre deosebire de verificarea prin demonstrare de teoreme,această metodă fǎcȃndu-se automat pentru toate execuțiile posibile, în caz de eroare generȃndu-se un contraexemplu

Etapele modelului :

□ Se specifică proprietățile produslui soft și se traduc în limbaj C;

□ Deoarece programul poate fi complex, se folosește abstracția în verificare, adicǎ se

dorește concentrarea asupra porțiunii relevante din program. Acest lucru se realizeazǎ prin tehnica program slicing prin care se determinǎ fragmentul de program care afecteazǎ o anumita proprietate a programului;

□ Se genereazǎ programul boolean pornind de la predicatele din specificație.

□ Se analizeazǎ programul boolean adică se calculeazǎ mulțimea stǎrilor atinse.

□ Dacǎ se depisteaza erori se vor genera contraexemple și noi predicate; contraexemplul este realizabil, atunci eroarea este realǎ, altfel, se pleacǎ din nou din starea de eroare în programul abstract și se parcurge calea de eroare înapoi pȃnǎ cȃnd se gǎsește o inconsistențǎ. Dupǎ care se genereazǎ predicatele corespunzǎtoare și programul boolean; se reia verificarea. [7]

4.2.2. Inferența logicǎ

O altǎ abordare este reprezentatǎ de inferența logicǎ care constǎ in folosirea unei versiuni formale a unui raționament matematic. Se folosesc de obicei teoreme precum HOL, ACL2, Isabelle, Coq. Aceste teoreme sunt aplicate parțial automat și sunt conduse de ințelgerea de cǎtre utilizator a sistemului de validat. Instrumentele mai noi precum Perfect Developer și Escher C Verifier incearcǎ sǎ automatizeze complet procesul. Logica liniarǎ și cea temporalǎ poate de asemenea fi folositǎ la inferența logicǎ și nu numai în cazul model checking-ului. [3]

4.2.3. Derivarea de program

O alta metoda este reprezentată de derivarea de program, cȃnd producerea de cod eficient se face plecȃnd de la specificațiile funcționale și se urmeazǎ o serie de pași cu rolul de a conserva corectitudinea. [3]

5. Concluzii

Validarea software este un proces critic, folosit pentru a asigura calitatea produsului software. Prin validare se imbunatateste aplicabilitatea practica si fiabilitatea software-ului, rezultatul fiind rata mica de erori , mai putine actiuni de corecate a codului sursa.resulting. Validarea software poate reduc costurile pe termen lung, facand posibil ca modificarile fiabile software si eventualulele revalidari sa se execute cu costuri scazute. In conditiile in care validarea initiala lipseste costurile de intretinere al produsului software sunt considerabil mai ridicate.

O validare initiala bine planificata si amanuntita ajuta la reducerea costurilor pe termen lung , prin reducerea costurilor necesare revalidarilor pentru versiunile urmatoare ale produsului software.

Metodele de validare și verificare sunt importante în dezvoltarea de produse soft,deoarece acestea fac posibile înțelegerea și punerea în discuție a problemei, descoperirea contradicțiilor de orice natură prin notații clare și precise. Totodată trebuie luat în calcul și satisfacerea nevoilor și îndeplinirea cerințelor clientului pentru a-i ușura munca.

6. Bibliografie

[1].Ian Sommerville,Software Engineering,Ed.Addison-Wesley,2007

[2] http://bigfoot.cs.upt.ro/~dan/curs/fis/Cap7_Testare.pdf

[3].Militon Frențiu, Verificarea și validarea sistemelor soft,Ed.Presa Universitară Clujeană,2010

[4]. http://en.wikipedia.org/wiki/Verification_and_validation_(software)

[5].http://www.ionivan.ro/ANUL-UNIVERSITAR%202010-2011/ZZZZcartea%20structuri%20date/F00036000-inspectie.pdf

[6]. http://en.wikipedia.org/wiki/Verification_and_validation

[7]. http://en.wikipedia.org/wiki/Model_checking

[8]. http://en.wikipedia.org/wiki/Formal_verification

[9]. http://alecu.ase.ro/articles/economistul_2005.pdf

[10]. http://en.wikipedia.org/wiki/Software_walkthrough

[11]. http://en.wikipedia.org/wiki/Software_review

[12]. Ian Sommerville ,Software Engineering ,Eighth Edition [13]. Timo Malm, Matti Vuori, Jari Rauhamäki, Timo Vepsäläinen,Johannes Koskinen, Jari Seppälä, Heikki Virtanen, Marita Hietikko & Mika Katara, Safety-critical software in machinery applications ,