Acasă » Control » Verificarea este procesul de verificare a unui produs software. Locul verificării între procesele de dezvoltare software În metodele de verificare software

Verificarea este procesul de verificare a unui produs software. Locul verificării între procesele de dezvoltare software În metodele de verificare software

Verificarea și atestarea se referă la procesele de verificare și revizuire în care se verifică conformitatea. software specificațiile sale și cerințele clienților. Verificarea și calificarea acoperă întreaga ciclu de viață Software - ele încep în etapa de analiză a cerințelor și se termină cu verificarea codului programului în etapa de testare a finalului sistem software.

Verificarea și atestarea nu sunt același lucru, deși este ușor să le confundăm. Pe scurt, diferența dintre ele poate fi definită după cum urmează:

Verificarea răspunde la întrebarea dacă sistemul este proiectat corespunzător;

Certificarea răspunde la întrebarea dacă sistemul funcționează corect.

Conform acestor definiții, verificarea verifică dacă software-ul este conform cu specificațiile sistemului, în special cu cerințele funcționale și nefuncționale. Certificare – mai mult proces general. În timpul validării, trebuie să vă asigurați că produsul software corespunde așteptărilor clientului. Validarea se efectuează după verificare pentru a determina modul în care sistemul îndeplinește nu numai specificația, ci și așteptările clientului.

După cum sa menționat mai devreme, validarea cerințelor de sistem este foarte importantă în etapele incipiente ale dezvoltării software. Există adesea erori și omisiuni în cerințe; în astfel de cazuri produs final, probabil nu va satisface așteptările clientului. Dar, desigur, validarea cerințelor nu poate dezvălui toate problemele din specificația cerințelor. Uneori, lacune și erori în cerințe sunt descoperite numai după finalizarea implementării sistemului.

Procesele de verificare și validare folosesc două tehnici principale pentru verificarea și analizarea sistemelor.

1. Inspecție software. Analiza și validarea diferitelor vederi ale sistemului, cum ar fi documentația cu specificațiile cerințelor, diagramele arhitecturale sau cod sursa programe. Inspecția este efectuată în toate etapele procesului de dezvoltare a sistemului software. În paralel cu inspecția, se poate efectua analiza automată a codului sursă al programelor și documentelor aferente. Inspecția și analiza automatizată sunt metode statice de verificare și validare deoarece nu necesită un sistem executabil.

2. Testare software. Rularea codului executabil cu date de testare și examinarea rezultatelor și a performanței produs software pentru a verifica funcționarea corectă a sistemului. Testarea este o metodă dinamică de verificare și validare deoarece este aplicată sistemului care rulează.

Pe fig. Figura 20.1 arată locul inspecției și testării în procesul de dezvoltare a software-ului. Săgețile indică etapele procesului de dezvoltare în care aceste metode pot fi aplicate. Conform acestei scheme, inspecția poate fi efectuată în toate etapele procesului de dezvoltare a sistemului și testarea - atunci când este creat un prototip sau un program executabil.

Metodele de inspecție includ: inspecția programului, analiza automată a codului sursă și verificarea formală. Dar metodele statice pot verifica doar dacă programele sunt conforme cu specificația; ele nu pot fi folosite pentru a verifica funcționarea corectă a sistemului. În plus, caracteristicile nefuncționale precum performanța și fiabilitatea nu pot fi testate cu metode statice. Prin urmare, pentru a evalua caracteristicile nefuncționale, se efectuează testarea sistemului.

Orez. 20.1. Verificare și atestare statică și dinamică

În ciuda utilizării pe scară largă a inspecției software, testarea este încă metoda predominantă de verificare și certificare. Testarea este o verificare a funcționării programelor cu date similare cu cele reale, care vor fi procesate în timpul funcționării sistemului. Prezența în program a defecte și inconsecvențe cu cerințele este detectată prin examinarea datelor de ieșire și identificarea celor anormale dintre acestea. Testarea este efectuată în timpul fazei de implementare a sistemului (pentru a verifica dacă sistemul corespunde așteptărilor dezvoltatorilor) și după finalizarea implementării acestuia.

În diferite etape ale procesului de dezvoltare software, tipuri diferite testarea.

1. Testarea defectelor efectuate pentru a detecta neconcordanțe între program și specificațiile acestuia, care se datorează erorilor sau defectelor din programe. Astfel de teste sunt concepute pentru a detecta erori în sistem și nu pentru a simula funcționarea acestuia.

2. Testare statistică evaluează performanța și fiabilitatea programelor, precum și funcționarea sistemului în diferite moduri de operare. Testele sunt concepute pentru a imita funcționarea reală a sistemului cu date reale de intrare. Fiabilitatea sistemului este evaluată prin numărul de defecțiuni observate în activitatea programelor. Performanța este evaluată prin măsurarea timpului total de funcționare și a timpului de răspuns al sistemului la procesarea datelor de testare.

obiectivul principal Verificare și calificare - pentru a se asigura că sistemul este „potrivit scopului”. Adecvarea unui sistem software pentru scopul propus nu implică că ar trebui să fie absolut lipsit de erori. Mai degrabă, sistemul ar trebui să fie rezonabil de bine adaptat scopurilor pentru care a fost destinat. Necesar validitatea conformității depinde de scopul sistemului, de așteptările utilizatorilor și de condițiile pieței pentru produsele software.

1. Scopul software-ului. Nivelul de fiabilitate a conformității depinde de cât de critic este software-ul dezvoltat în funcție de anumite criterii. De exemplu, nivelul de încredere pentru sistemele critice pentru siguranță ar trebui să fie semnificativ mai mare decât cel pentru sistemele software prototip dezvoltate pentru a demonstra o idee nouă.

2. Așteptările utilizatorilor. Trebuie remarcat cu tristețe că în prezent, majoritatea utilizatorilor au cerințe scăzute pentru software. Utilizatorii sunt atât de obișnuiți cu eșecurile care apar în timpul rulării programelor încât nu sunt surprinși de acest lucru. Sunt dispuși să tolereze defecțiunile sistemului dacă beneficiile utilizării acestuia depășesc dezavantajele. Cu toate acestea, de la începutul anilor 1990, toleranța utilizatorilor pentru defecțiunile sistemelor software a scăzut treptat. Recent, crearea de sisteme nefiabile a devenit aproape inacceptabilă, astfel încât companiile de dezvoltare de software trebuie să acorde din ce în ce mai multă atenție verificării și validării software-ului.

3. Condițiile pieței software. Atunci când evaluează un sistem software, vânzătorul trebuie să cunoască sistemele concurente, prețul pe care cumpărătorul este dispus să-l plătească pentru sistem și timpul așteptat de lansare pe piață pentru acel sistem. Dacă compania de dezvoltare are mai mulți concurenți, este necesar să se determine data intrării sistemului pe piață înainte de încheierea testării complete și a depanării, altfel concurenții pot fi primii care intra pe piață. Dacă clienții nu doresc să cumpere software-ul la preț mare poate că sunt dispuși să tolereze mai multe defecțiuni ale sistemului. La determinarea costurilor procesului de verificare și calificare trebuie să se țină seama de toți acești factori.

De regulă, erorile sunt găsite în sistem în timpul verificării și atestării. Se fac modificări în sistem pentru a corecta erorile. Acest procesul de depanare de obicei integrate cu alte procese de verificare și atestare. Cu toate acestea, testarea (sau mai general, verificarea și validarea) și depanarea sunt procese diferite care au scopuri diferite.

1. Verificarea și validarea este procesul de detectare a defectelor într-un sistem software.

2. Depanare - procesul de localizare a defectelor (erori) și remediere a acestora (Fig. 20.2).

Orez. 20.2. Procesul de depanare

Nu există metode simple de depanare a programelor. Depanatorii experimentați găsesc erori prin compararea tiparelor de ieșire de testare cu rezultatele sistemelor testate. Pentru a localiza o eroare este nevoie de cunoștințe despre tipurile de erori, modelele de ieșire, limbajul de programare și procesul de programare. Cunoașterea procesului de dezvoltare software este foarte importantă. Depanatorii sunt conștienți de cele mai frecvente erori de programare (cum ar fi creșterea unui contor). De asemenea, ia în considerare erorile care sunt tipice pentru anumite limbaje de programare, de exemplu, cele asociate cu utilizarea pointerilor în limbajul C.

Localizarea erorilor în codul programului nu este întotdeauna un proces simplu, deoarece eroarea nu este neapărat localizată în apropierea locului din codul programului în care a avut loc accidentul. Pentru a izola erorile, depanatorul dezvoltă teste software suplimentare care ajută la identificarea sursei erorii în program. Poate fi necesar să urmăriți manual execuția programului.

Instrumentele interactive de depanare fac parte dintr-un set de instrumente de suport pentru limbaj care sunt integrate cu sistemul de compilare a codului. Acestea oferă un mediu special de execuție a programului prin care puteți accesa tabelul de identificatori, iar de acolo la valorile variabilelor. Utilizatorii controlează adesea execuția unui program într-o manieră pas cu pas, trecând de la instrucțiune la instrucțiune în secvență. După executarea fiecărei instrucțiuni, se verifică valorile variabilelor și se identifică eventualele erori.

Eroarea găsită în program este corectată, după care este necesar să verificați din nou programul. Pentru a face acest lucru, puteți reinspecta programul sau repeta testul anterior. Retestarea este folosită pentru a ne asigura că modificările aduse programului nu introduc noi erori în sistem, deoarece în practică un procent mare de „remedieri de erori” fie nu se completează complet, fie introduc noi erori în program.

În principiu, este necesar să rulați din nou toate testele în timpul retesării după fiecare remediere, dar în practică, această abordare este prea costisitoare. Prin urmare, la planificarea procesului de testare, dependențele dintre părțile sistemului sunt determinate și teste sunt atribuite pentru fiecare parte. Apoi este posibilă urmărirea elementelor programului utilizând cazuri de testare speciale (date de control) selectate pentru aceste elemente. Dacă rezultatele urmăririi sunt documentate, atunci numai un subset din setul total de date de testare poate fi utilizat pentru a testa elementul de program modificat și componentele sale dependente.

Planificare pentru verificare și atestare

Verificarea și validarea este un proces costisitor. Pentru sistemele mari, cum ar fi sistemele în timp real cu constrângeri complexe nefuncționale, jumătate din bugetul de dezvoltare a sistemului este cheltuit pentru procesul de verificare și validare. Prin urmare, necesitatea unei planificări atentă a acestui proces este evidentă.

Planificarea verificării și validării, ca parte a dezvoltării sistemelor software, ar trebui să înceapă cât mai curând posibil. Pe fig. Figura 20.3 prezintă un model de dezvoltare software care ia în considerare procesul de planificare a testelor. Aici începe planificarea încă din fazele de specificare și proiectare a sistemului. Acest model este uneori denumit model V (pentru a vedea V, rotiți Figura 20.3 cu 90°). Această diagramă arată și împărțirea procesului de verificare și atestare în mai multe etape, cu testele corespunzătoare efectuate la fiecare etapă.

Orez. 20.3. Planificarea testelor în timpul dezvoltării și testării

În procesul de verificare și certificare a planificării, este necesar să se determine relația dintre metodele statice și dinamice de verificare a sistemului, să se determine standarde și proceduri pentru inspecția și testarea software-ului, să se aprobe harta tehnologica revizuiri software (vezi Secțiunea 19.2) și dezvoltați un plan de testare software. Dacă inspecția sau testarea este mai importantă depinde de tipul de sistem dezvoltat și de experiența organizației. Cu cât sistemul este mai critic, cu atât mai multă atenție trebuie acordată metodelor de verificare statică.

Planul de verificare și validare se concentrează mai degrabă pe standardele procesului de testare decât pe descrierea unor teste specifice. Acest plan nu este doar orientativ, ci este destinat în principal profesioniștilor în dezvoltarea și testarea sistemelor. Planul permite personalul tehnic obțineți o imagine completă a testelor sistemului și planificați-vă munca în acest context. În plus, planul oferă informații managerilor care sunt responsabili pentru a se asigura că echipa de testare are tot hardware-ul și software-ul necesar.

Planul de testare nu este un document fix. Ar trebui revizuit în mod regulat, deoarece testarea depinde de procesul de implementare a sistemului. De exemplu, dacă implementarea unei părți a sistemului nu este finalizată, atunci este imposibil să testați ansamblul sistemului. Prin urmare, planul trebuie revizuit periodic, astfel încât personalul de testare să poată fi folosit în alte locuri de muncă.

Saint Petersburg

Universitatea Electrotehnică de Stat

Departamentul MOEM

prin disciplina

„Procesul de dezvoltare software”

„Verificare software”

Saint Petersburg

Scopul verificării………………………………………………………………… pagina 3

Observații introductive……………………………………………………………………….. pagina 3

Ținte speciale și generale………………………………………….. pagina 4

Practică așteptată pe ținte……………………………………… pagina 4

SG1 Pregătirea pentru verificare……………………………………………………………. pagina 4

SG2 Efectuarea examinărilor (evaluarea de la egal la egal)………………………… pagina 7

SG3 Implementarea verificării…………………………………………………………. pagina 9

Anexa 1. Prezentare generală a instrumentelor de automatizare pentru procesul de verificare……….. pagina 11

Anexa 2. Principala abordări moderne la verificare…………….. pagina 12

Lista literaturii utilizate……………………………………………………….. pagina 14

Un model integrat de excelență și maturitate

Verificare (Nivelul de maturitate 3)

Ţintă

Scopul verificării este oferind asigurarea că middleware-ul sau produsul final selectat îndeplinește cerințele specificate.

note de apă

Verificarea produselor software este verificarea produsului finit sau a versiunilor sale intermediare pentru a îndeplini cerințele inițiale. Aceasta presupune nu numai testarea programului în sine, ci și auditarea proiectului, a documentației utilizator și tehnică etc.

Scopul verificării sistemului software este de a identifica și raporta erorile care pot fi făcute în timpul etapelor ciclului de viață. Principalele sarcini de verificare:

determinarea conformității cerințelor de nivel înalt cu cerințele de sistem;

luarea în considerare a cerințelor de nivel înalt în arhitectura sistemului;

conformitatea cu arhitectura și cerințele pentru aceasta în codul sursă;

determinarea conformității codului executabil cu cerințele pentru sistem;

determinarea mijloacelor folosite pentru rezolvarea sarcinilor de mai sus, care sunt corecte din punct de vedere tehnic și suficient de complete.

Verificarea include verificarea produselor finite și verificarea produselor intermediare în raport cu toate cerințele selectate, inclusiv cerințele clienților, cerințele pentru produsele finite și cerințele pentru componentele sale individuale.

Verificarea este în mod inerent un proces incremental (incremental) din momentul începerii sale, pe parcursul dezvoltării produselor și a întregii lucrări asupra produselor. Verificarea începe cu verificarea cerințelor, apoi urmează verificarea tuturor produselor intermediare în diferite etape ale dezvoltării și fabricării acestora și se termină cu verificarea produsului final.

Verificarea produselor intermediare în fiecare etapă a dezvoltării și fabricării lor crește semnificativ probabilitatea ca produsul final să îndeplinească cerințele clientului, cerințele pentru produsul finit și cerințele pentru componentele sale individuale.

Verificarea și Validarea proceselor sunt procese în mod esențial conexe, având ca scop, totuși, obținerea de rezultate diferite. Scopul validării este de a demonstra că produsul finit își îndeplinește de fapt scopul inițial. Verificarea are ca scop să se asigure că produsul îndeplinește exact anumite cerințe. Cu alte cuvinte, Verificarea asigură că „ o faci corect”, iar validarea este că „ faci ceea ce trebuie”.

Verificarea ar trebui implementată cât mai devreme posibil în procesele relevante (cum ar fi livrarea, dezvoltarea, operarea sau întreținerea) pentru a evalua rentabilitatea și performanța. Acest proces poate include analiză, verificare și testare (testare).

Acest proces poate fi realizat cu diferite grade de independență a interpreților. Gradul de independență al artiștilor interpreți poate fi distribuit atât între diferite entități din organizația propriu-zisă, cât și entități din altă organizație, cu grade diferite de repartizare a responsabilităților. Acest proces se numește proces verificare independentă dacă organizația de implementare este independentă de vânzător, dezvoltator, operator sau întreținător.

Evaluări ale experților (expertiză) reprezintă o parte importantă a verificării ca instrument bine stabilit pentru eliminarea eficientă a defectelor. O concluzie importantă din aceasta este necesitatea de a dezvolta o înțelegere și o înțelegere mai profundă a versiunilor de lucru ale produsului, precum și a fluxurilor de lucru utilizate pentru a identifica posibilele defecte și pentru a crea o oportunitate pentru îmbunătățiri, dacă este necesar.

Examinările includ un studiu metodic al muncii efectuate de experți pentru a identifica defectele și alte modificări necesare.

Principalele metode de evaluare a experților sunt:

inspecţie

control structural de la capăt la capăt

După cum știți, computerele universale pot fi programate pentru a rezolva cele mai diverse probleme - aceasta este una dintre caracteristicile lor principale, care are o mare valoare practică. Unul și același computer, în funcție de programul care se află în memorie, este capabil să efectueze calcule aritmetice, să demonstreze teoreme și să editeze texte, să gestioneze cursul unui experiment și să creeze un proiect pentru o mașină a viitorului, să joace șah și să predea limbă străină. Cu toate acestea, rezolvarea cu succes a tuturor acestor probleme și a multor alte probleme este posibilă numai cu condiția ca programe de calculator nu conțin erori care pot duce la rezultate incorecte.

Se poate spune că cerința pentru absența erorilor în software este destul de naturală și nu trebuie să fie fundamentată. Dar cum poți fi sigur că nu există erori? Întrebarea nu este atât de simplă pe cât ar părea la prima vedere.

Metodele informale pentru a demonstra corectitudinea programelor includ depanare și testare, care sunt o componentă necesară în toate etapele procesului de programare, deși nu rezolvă complet problema corectitudinii. Erorile semnificative sunt ușor de găsit dacă utilizați tehnicile de depanare adecvate (printări de control, urme).

Testare Procesul de executare a unui program cu intenția de a găsi o eroare mai degrabă decât de a confirma că programul este corect. Esența sa este următoarea. Programul de testat este rulat în mod repetat cu acele intrări pentru care rezultatul este cunoscut dinainte. Apoi rezultatul obținut de mașină este comparat cu cel așteptat. Dacă în toate cazurile de testare există o coincidență a acestor rezultate, există o oarecare încredere că calculele ulterioare nu vor duce la un rezultat eronat, de exemplu. că programul original funcționează corect.

Am discutat deja despre conceptul de corectitudine a unui program în ceea ce privește absența erorilor în acesta. Din punct de vedere intuitiv, programul va fi corect dacă, în urma execuției sale, se obține rezultatul, cu scopul de a obține care a fost scris programul. În sine, faptul că programul s-a terminat fără un accident nu spune nimic: este foarte posibil ca programul să facă de fapt ceva complet diferit de ceea ce a fost intenționat. Erorile de acest fel pot apărea din diverse motive.

În cele ce urmează, vom presupune că programele în discuție nu conțin erori sintactice, prin urmare, la fundamentarea corectitudinii lor, se va acorda atenție doar laturii de conținut a problemei, legată de întrebarea dacă acest obiectiv specific este atins cu ajutorul acestui program. Scopul poate fi considerat căutarea unei soluții la problemă, iar programul poate fi considerat o modalitate de a o rezolva. Programul va corect, Daca ea rezolvă problema dată.

Metoda de stabilire a corectitudinii programelor prin mijloace riguroase este cunoscută ca verificarea programului.

Spre deosebire de testarea programelor, unde sunt analizate proprietățile proceselor individuale de execuție a programelor, verificarea se ocupă cu proprietăți programe.

Metoda de verificare se bazează pe presupunerea că există o documentație a programului, a cărei conformitate trebuie dovedită. Documentația trebuie să conțină:

specificație input-output (descrierea datelor care nu depinde de procesul de prelucrare);

proprietățile relațiilor dintre elementele vectorilor de stare în punctele selectate ale programului;

specificațiile și proprietățile subcomponentelor structurale ale programului;

specificarea structurilor de date în funcție de procesul de prelucrare.

Această metodă de a demonstra corectitudinea programelor este metoda afirmaţiilor inductive, formulat independent de K. Floyd și P. Naur.

Esența acestei metode este următoarea:

1) instrucțiunile de intrare și de ieșire sunt formulate: instrucțiunea de intrare descrie toate condițiile de intrare necesare pentru program (sau fragment de program), instrucțiunea de ieșire descrie rezultatul așteptat;

2) presupunând că declarația de intrare este adevărată, se construiește o declarație intermediară, care este derivată pe baza semanticii operatorilor aflați între intrare și ieșire (instrucțiuni de intrare și ieșire); o astfel de afirmație se numește declarație derivată;

3) se formulează o teoremă (condiții de verificare):

instrucțiunea de ieșire decurge din declarația dedusă;

4) se demonstrează teorema; dovada atestă corectitudinea programului (fragment de program).

Demonstrarea este efectuată folosind metode matematice bine dezvoltate, folosind calculul predicatelor de ordinul întâi.

Condițiile de verificare pot fi construite și în direcția opusă, adică, presupunând că declarația de ieșire este adevărată, obțineți declarația de intrare și demonstrați teorema:

instrucțiunea de ieșire decurge din instrucțiunea de intrare.

Această metodă de construire a condițiilor de verificare simulează execuția programului în sens invers. Cu alte cuvinte, condițiile de verificare ar trebui să răspundă la următoarea întrebare: dacă o afirmație este adevărată după execuția instrucțiunii de program, atunci care afirmație trebuie să fie adevărată înainte de declarație?

Construcția enunțurilor inductive ajută la formalizarea intuițiilor despre logica programului. Este cel mai dificil în procesul de demonstrare a corectitudinii programului. Acest lucru se explică, în primul rând, prin faptul că este necesară descrierea tuturor condițiilor de fond și, în al doilea rând, prin faptul că este necesară o descriere axiomatică a semanticii limbajului de programare.

Un pas important în procesul de demonstrare este dovada încheierii programului, pentru care este suficientă un anumit raționament informal.

Astfel, algoritmul de demonstrare a corectitudinii programului prin metoda afirmațiilor inductive este prezentat sub următoarea formă:

1) Construiți structura programului.

2) Scrieți instrucțiunile de intrare și de ieșire.

3) Formulați enunțuri inductive pentru toate ciclurile.

4) Faceți o listă cu căile selectate.

5) Construiți condiții de verificare.

6) Demonstrați starea de verificare.

7) Demonstrați că execuția programului se va încheia.

Această metodă este comparabilă cu procesul obișnuit de citire a textului programului (metoda de control end-to-end). Diferența constă în gradul de formalizare.

Avantajul verificării este că procesul de probă este atât de formalizat încât poate fi efectuat pe un computer. În această direcție s-au făcut cercetări în anii optzeci, s-au creat chiar și sisteme automate de dialog, dar nu și-au găsit aplicație practică.

Pentru un sistem de dialog automat, programatorul trebuie să specifice declarații inductive în limbajul calculului predicat. Sintaxa și semantica unui limbaj de programare trebuie să fie stocate în sistem sub formă de axiome în limbajul de calcul predicat. Sistemul ar trebui să determine căile din program și să construiască condiții de verificare.

Componenta principală a sistemului de dovedire este generatorul de condiții de verificare, care conține operații pentru manipularea predicatelor, algoritmi pentru interpretarea instrucțiunilor de program. A doua componentă a sistemului este subsistemul de demonstrare a teoremei.

Remarcăm dificultățile asociate cu metoda aserțiilor inductive. Este dificil să construiești „un set de axiome de bază, suficient de limitate pentru a evita contradicțiile, dar suficient de bogate pentru a servi drept punct de plecare pentru demonstrarea afirmațiilor despre programe” (E. Dijkstra). A doua dificultate este semantică, constând în formarea enunţurilor în sine de demonstrat. Dacă problema pentru care este scris programul nu are o descriere matematică strictă, atunci este mai dificil să se formuleze condiții de verificare pentru aceasta.

Metodele enumerate au un lucru în comun: consideră programul ca pe un obiect deja existent și apoi dovedesc corectitudinea acestuia.

Metoda formulată de K. Hoare și E. Dijkstra se bazează pe derivarea formală a programelor din formularea matematică a problemei.

Verificare si validare ( verificare si validare-V& v) sunt concepute pentru a analiza, verifica executarea corectă și conformitatea software-ului cu specificațiile și cerințele clientului. Aceste metode de verificare a corectitudinii programelor și respectiv sistemelor înseamnă:

verificarea este verificarea corectitudinii creării sistemului în conformitate cu specificațiile acestuia;
Validarea este o verificare a corectitudinii îndeplinirii cerințelor specificate pentru sistem.

Verificarea ajută la tragerea unei concluzii despre corectitudinea sistemului creat după finalizarea proiectării și dezvoltării acestuia. Validarea vă permite să stabiliți fezabilitatea cerințelor specificate și include o serie de acțiuni pentru obținerea programelor și sistemelor corecte, și anume:

proceduri de planificare pentru verificarea și controlul deciziilor și cerințelor de proiectare;
asigurarea nivelului de automatizare a proiectării programelor prin intermediul CASE;
verificarea functionarii corecte a programelor prin testarea metodelor pe seturi de teste tinta;
adaptarea produsului la mediul de operare etc.

Validarea realizează aceste activități prin revizuirea și inspectarea specificațiilor și a rezultatelor proiectării în etapele ciclului de viață pentru a confirma că există o implementare corectă a cerințelor inițiale și că sunt îndeplinite condițiile și constrângerile specificate. Sarcinile de verificare și validare includ verificarea completității, consecvenței și lipsei de ambiguitate a specificației cerințelor și a corectitudinii performanței funcțiilor sistemului.

Verificarea și validarea sunt supuse:

principalele componente ale sistemului;
interfețe de componente (software, tehnice și informaționale) și interacțiuni ale obiectelor (protocoale și mesaje) care asigură implementarea sistemului în medii distribuite;
mijloace de acces la baza de date și fișiere (tranzacții și mesaje) și verificarea mijloacelor de protecție împotriva accesului neautorizat la datele diferiților utilizatori;
documentație pentru software și pentru sistem în ansamblu;
teste, proceduri de testare și date de intrare.

Cu alte cuvinte, principalele metode sistematice de corectitudine a programelor sunt:

verificare validarea specificațiilor componentelor și cerințelor PS;
inspectie PS să stabilească conformitatea programului cu specificațiile date;
testarea codul de ieșire al PS pe datele de testare într-un mediu de operare specific pentru a identifica erorile și defecte cauzate de diverse defecte, anomalii, defecțiuni ale echipamentelor sau blocări ale sistemului (vezi Capitolul 9).

ISO/IEC 3918-99 și 12207 includ procese de verificare și validare. Pentru ei, obiectivele, sarcinile și acțiunile sunt definite pentru a verifica corectitudinea produsului creat (inclusiv produse de lucru, intermediare) în etapele ciclului de viață și conformitatea cu cerințele acestuia.

Sarcina principală a proceselor de verificare și validare este de a verifica si confirma că software-ul final este adecvat scopului și satisface cerințele clientului. Aceste procese vă permit să identificați erorile în produsele de lucru ale etapelor ciclului de viață, fără a afla motivele apariției acestora, precum și să stabiliți corectitudinea software-ului în raport cu specificația acestuia.

Aceste procese sunt interconectate și sunt definite printr-un singur termen - „verificare și validare” (V&V 7).

Verificarea se efectuează:

verificarea corectitudinii traducerii componentelor individuale în codul de ieșire, precum și descrierilor interfeței prin urmărirea relațiilor dintre componente în conformitate cu cerințele specificate ale clientului;
analiza corectitudinii accesului la fișiere sau la o bază de date, ținând cont de procedurile adoptate în instrumentele de sistem utilizate pentru manipularea datelor și transmiterea rezultatelor;
verificarea mijloacelor de protecție a componentelor pentru conformitatea cu cerințele clienților și urmărirea acestora.

După verificarea componentelor individuale ale sistemului, se realizează integrarea acestora, precum și verificarea și validarea sistemului integrat. Sistemul este testat pe o multitudine de suite de testare pentru a determina dacă suitele de testare sunt adecvate și suficiente pentru a finaliza testul și a stabili corectitudinea sistemului.

Ideea creării unui proiect internațional de verificare formală a fost propusă de T. Hoare, a fost discutată la un simpozion despre software verificat în februarie 2005 în California. Apoi, în octombrie același an, la conferința IFIP de la Zurich, a fost adoptat un proiect internațional pentru o perioadă de 15 ani pentru a dezvolta un „set holistic automatizat de instrumente pentru verificarea corectitudinii PS”.

Acesta a formulat următoarele sarcini principale:

dezvoltarea unei teorii unificate a construcției și analizei programelor;
construirea unui set cuprinzător integrat de instrumente de verificare pentru toți etapele de producție, inclusiv elaborarea specificațiilor și verificarea acestora, generarea de cazuri de testare, rafinarea, analiza și verificarea programelor;
crearea unui depozit de specificații formale și obiecte software verificate tipuri diferiteși tipuri.

ÎN acest proiect Se presupune că verificarea va acoperi toate aspectele creării și verificării corectitudinii software-ului și va deveni un panaceu pentru toate problemele asociate cu apariția constantă a erorilor în programele create.

Multe metode formale de demonstrare și verificare a programelor specificate au fost testate în practică. A fost depusă multă muncă de către comitetul internațional ISO/IEC din cadrul Standardul ISO/ IEC 12207:2002 privind standardizarea proceselor de verificare și validare a software-ului. Verificarea corectitudinii prin metode formale a diferitelor obiecte de programare este promițătoare.

Depozitul este un depozit de programe, specificații și instrumente utilizate în dezvoltarea și testarea, evaluarea componentelor finite, unelte și semifabricate de metodă. Are următoarele sarcini generale:

acumularea de specificații verificate, metode de probă, obiecte de program și implementări de cod pentru aplicații complexe;
acumularea diferitelor metode de verificare, proiectarea lor într-o formă adecvată pentru căutarea și selectarea unei idei teoretice realizate pentru aplicare ulterioară;
dezvoltarea de formulare standard pentru stabilirea și schimbul de specificații formale ale diferitelor obiecte de programare, precum și instrumente și sisteme gata făcute;
dezvoltarea de mecanisme de interoperabilitate și interacțiune pentru transferul produselor finite verificate din depozit în noi medii distribuite și de rețea pentru a crea noi PS-uri.

Acest proiect ar trebui să fie dezvoltat în 50 de ani. Proiectele anterioare și-au propus obiective similare: îmbunătățirea calității software-ului, formalizarea modelelor de servicii, reducerea complexității prin utilizarea PIC-urilor, crearea de instrumente de depanare pentru diagnosticarea vizuală a erorilor și eliminarea acestora etc. Cu toate acestea, o schimbare fundamentală în programare nu a avut loc nici în sensul de depanare vizuală sau în realizarea de software de înaltă calitate. Procesul de dezvoltare continuă.

Un nou proiect internațional de verificare a software-ului necesită de la participanții săi nu numai cunoștințe aspecte teoretice specificațiile programului, dar și programatori cu înaltă calificare pentru implementarea acestuia în următorii ani.

2.1. Proprietățile de integrare ale sistemelor

2.2. Sistemul și mediul său

2.3. Modelarea sistemelor

2.4. Procesul de creare a sistemelor

2.5. Sisteme de achiziție

3. Procesul de creare a software-ului

3.1. Modele ale procesului de dezvoltare software

3.2. Modele iterative de dezvoltare software

3.3. Specificație software

3.4. Proiectare si implementare software

3.5. Evoluția sistemelor software

3.6. Instrumente automate de dezvoltare software

4. Tehnologii de producție software

Partea a II-a. Cerințe software

5. Cerințe software

5.1. Cerințe funcționale și nefuncționale

5.2. Cerințe personalizate

5.3. Cerințe de sistem

5.4. Documentarea cerințelor de sistem

6. Dezvoltarea cerințelor

6.1. Studiu de fezabilitate

6.2. Formarea și analiza cerințelor

6.3. Validarea cerințelor

6.4. Managementul Cerintelor

7. Matricea cerințelor. Dezvoltarea matricei de cerințe

Partea a III-a. Simulare software

8. Proiectare arhitecturală

8.1. Structurarea sistemului

8.2. Modele de management

8.3. Descompunere modulară

8.4. Arhitecturi dependente de probleme

9. Arhitectura sistemelor distribuite

9.1. Arhitectura multiprocesor

9.2. Arhitectura client/server

9.3. Arhitectura obiectelor distribuite

9.4. Corba

10. Proiectare orientată pe obiecte

10.1. Obiecte și clase de obiecte

10.2. Procesul de proiectare orientată pe obiecte

10.2.1. Mediul de sistem și modelele de utilizare a acestuia

10.2.2. design arhitectural

10.2.3. Definiţia obiectelor

10.2.4. modele de arhitectură

10.2.5. Specificarea interfețelor obiect

10.3. Modificarea arhitecturii sistemului

11. Proiectarea sistemului în timp real

11.1. Proiectare sistem în timp real

11.2. Programe de control

11.3. Sisteme de monitorizare si control

11.4. Sisteme de achizitie de date

12. Proiectare cu reutilizarea componentelor

12.1. Dezvoltarea componentelor

12.2. Familii de aplicații

12.3. Modele de design

13. Design interfață utilizator

13.1. Principii de proiectare a interfeței cu utilizatorul

13.2. Interacțiunea utilizatorului

13.3. Prezentarea informațiilor

13.4. Instrumente de asistență pentru utilizatori

13.5. Evaluarea interfeței

Partea a IV-a. Tehnologii de dezvoltare software

14. Ciclul de viață al software-ului: modele și caracteristicile acestora

14.1. Modelul ciclului de viață al cascadei

14.2. Modelul ciclului de viață evolutiv

14.2.1. Dezvoltarea sistemelor formale

14.2.2. Dezvoltare software bazată pe componente create anterior

14.3. Modele iterative ale ciclului de viață

14.3.1 Model de dezvoltare incrementală

14.3.2 Modelul de dezvoltare în spirală

15. Bazele metodologice ale tehnologiilor de dezvoltare software

16. Metode de analiză structurală și proiectare software

17. Metode de analiză orientată pe obiecte și proiectare software. limbaj de modelare uml

Partea a V-a. Comunicare scrisă. Documentația proiectului software

18. Documentarea etapelor dezvoltării software-ului

19. Planificarea proiectului

19.1 Clarificarea conținutului și domeniului de activitate

19.2 Planificarea managementului conținutului

19.3 Planificare organizațională

19.4 Planificarea managementului configurației

19.5 Planificarea managementului calității

19.6 Programul de bază al proiectului

20. Verificare și validare software

20.1. Planificare pentru verificare și atestare

20.2. Inspecția sistemelor software

20.3. Analiza automată a programelor statice

20.4. Metoda camerei curate

21. Testare software

21.1. Testarea defectelor

21.1.1. Testarea cutiei negre

21.1.2. Domenii de echivalență

21.1.3. Testarea structurală

21.1.4. Testarea ramurilor

21.2. Testarea construcției

21.2.1. Testare în jos și în sus

21.2.2. Testarea interfeței

21.2.3. Testare de sarcină

21.3. Testarea sistemelor orientate pe obiecte

21.3.1. Testarea clasei de obiecte

21.3.2. Integrarea obiectelor

21.4. Instrumente de testare

Partea a VI-a. Managementul proiectelor software

22. Managementul proiectelor

22.1. Procese de management

22.2. Planificarea proiectului

22.3. Program de funcționare

22.4. Managementul riscurilor

23. Managementul personalului

23.1. Limitele gândirii

23.1.1. Organizarea memoriei umane

23.1.2. Rezolvarea problemelor

23.1.3. Motivația

23.2. lucru de grup

23.2.1. Crearea unei echipe

23.2.2. Coeziunea echipei

23.2.3. Comunicarea de grup

23.2.4. Organizarea grupului

23.3. Recrutarea si retinerea personalului

23.3.1. Mediu de lucru

23.4. Model de evaluare a nivelului de dezvoltare a personalului

24. Estimarea costului unui produs software

24.1. Performanţă

24.2. Metode de evaluare

24.3. Modelarea algoritmică a costurilor

24.3.1. model sosomo

24.3.2. Modele algoritmice de cost în planificarea proiectelor

24.4. Durata proiectului și recrutarea

25. Managementul calității

25.1. Asigurarea calității și standardele

25.1.1. Standarde de documentație tehnică

25.1.2. Calitatea procesului de dezvoltare software și calitatea produsului software

25.2. Planificarea calitatii

25.3. Control de calitate

25.3.1. Verificări de calitate

25.4. Măsurarea performanței software-ului

25.4.1. Procesul de măsurare

25.4.2. Valorile produsului software

26. Fiabilitatea software-ului

26.1. Asigurarea fiabilității software-ului

26.1.1 Sisteme critice

26.1.2. Operabilitate și fiabilitate

26.1.3. Siguranță

26.1.4. Securitate

26.2. Atestare de fiabilitate

26.3. Garanții de securitate

26.4. Evaluarea securității software

27. Îmbunătățirea producției de software

27.1. Calitatea produsului și a producției

27.2. Analiza si simularea productiei

27.2.1. Excepții în timpul creării de către

27.3. Măsurarea procesului de producție

27.4. Model de evaluare a nivelului de dezvoltare

27.4.1. Evaluarea nivelului de dezvoltare

27.5. Clasificarea proceselor de îmbunătățire

20. Verificare și validare software

Verificarea și validarea se referă la procesele de verificare și analiză care verifică dacă software-ul respectă specificațiile și cerințele clientului. Verificarea și validarea acoperă întregul ciclu de viață al software-ului - ele încep în etapa de analiză a cerințelor și se termină cu verificarea codului programului în etapa de testare a sistemului software finit.

Verificarea și atestarea nu sunt același lucru, deși este ușor să le confundăm. Pe scurt, diferența dintre ele poate fi definită după cum urmează:

Verificarea răspunde la întrebarea dacă sistemul este proiectat corespunzător;

Certificarea răspunde la întrebarea dacă sistemul funcționează corect.

Conform acestor definiții, verificarea verifică dacă software-ul este conform cu specificațiile sistemului, în special cu cerințele funcționale și nefuncționale. Certificarea este un proces mai general. În timpul validării, trebuie să vă asigurați că produsul software corespunde așteptărilor clientului. Validarea se efectuează după verificare pentru a determina modul în care sistemul îndeplinește nu numai specificația, ci și așteptările clientului.

După cum sa menționat mai devreme, validarea cerințelor de sistem este foarte importantă în etapele incipiente ale dezvoltării software. Există adesea erori și omisiuni în cerințe; în astfel de cazuri, produsul final probabil nu va satisface așteptările clientului. Dar, desigur, validarea cerințelor nu poate dezvălui toate problemele din specificația cerințelor. Uneori, lacune și erori în cerințe sunt descoperite numai după finalizarea implementării sistemului.

Procesele de verificare și validare folosesc două tehnici principale pentru verificarea și analizarea sistemelor.

1. Inspecție software. Analiza și verificarea diferitelor reprezentări ale sistemului, cum ar fi documentația cu specificațiile cerințelor, diagramele arhitecturale sau codul sursă al programului. Inspecția este efectuată în toate etapele procesului de dezvoltare a sistemului software. În paralel cu inspecția, se poate efectua analiza automată a codului sursă al programelor și documentelor aferente. Inspecția și analiza automatizată sunt metode statice de verificare și validare deoarece nu necesită un sistem executabil.

2. Testare software. Rularea codului executabil cu datele de testare și examinarea rezultatelor și performanței produsului software pentru a verifica dacă sistemul funcționează corect. Testarea este o metodă dinamică de verificare și validare deoarece este aplicată sistemului care rulează.

Orez. 20.1. Verificare și atestare statică și dinamică

Diferite tipuri de testare sunt utilizate în diferite etape ale procesului de dezvoltare software.

Scopul principal al verificării și calificării este de a se asigura că sistemul este „potrivit scopului”. Adecvarea unui sistem software pentru scopul propus nu implică că ar trebui să fie absolut lipsit de erori. Mai degrabă, sistemul ar trebui să fie rezonabil de bine adaptat scopurilor pentru care a fost destinat. Necesar validitatea conformității depinde de scopul sistemului, de așteptările utilizatorilor și de condițiile pieței pentru produsele software.

3. Condițiile pieței software. Atunci când evaluează un sistem software, vânzătorul trebuie să cunoască sistemele concurente, prețul pe care cumpărătorul este dispus să-l plătească pentru sistem și timpul așteptat de lansare pe piață pentru acel sistem. Dacă compania de dezvoltare are mai mulți concurenți, este necesar să se determine data intrării sistemului pe piață înainte de încheierea testării complete și a depanării, altfel concurenții pot fi primii care intra pe piață. Dacă clienții nu sunt dispuși să achiziționeze software la un preț ridicat, ei pot fi dispuși să tolereze mai multe defecțiuni ale sistemului. La determinarea costurilor procesului de verificare și calificare trebuie să se țină seama de toți acești factori.

1. Verificarea și validarea este procesul de detectare a defectelor într-un sistem software.

2. Depanare - procesul de localizare a defectelor (erori) și remediere a acestora (Fig. 20.2).

Orez. 20.2. Procesul de depanare

Verificarea este procesul de verificare a unui produs software. Locul verificării între procesele de dezvoltare software În metodele de verificare software

Verificare (Nivelul de maturitate 3)

note de apă

20. Verificare și validare software

Popular