Designverifikations- og valideringsproces

Design Verifikation

Design Verifikation er en metode til at bekræfte, ved undersøgelse og ved at fremlægge beviser, at outputtet fra et designet softwareprodukt opfylder dets inputspecifikationer. Målet med designverifikationsprocessen under softwareudvikling er at sikre, at det designede softwareprodukt er det samme som det, der blev specificeret.

Designinput er ethvert fysisk krav og ydeevnekrav, der bruges som grundlag for designet. Designoutput er resultatet af hver designfase og af den samlede designindsats. I regulerede brancher såsom medicinsk udstyr bliver det endelige designoutput grundlaget for enhedens master record, hvilket er grunden til, at designkontrolvokabular optræder så ofte i verifikationsdokumentation.

I praksis sammenligner verifikation to sæt dokumenter: de specifikationer, standarder og begrænsninger, der blev indsendt, med de tegninger, koder og testinstruktioner, der blev udarbejdet. Enhver uoverensstemmelse mellem dem er et verifikationsresultat.

Design validering

Verifikation beviser intern konsistens. Validering stiller det vanskeligere spørgsmål om, hvorvidt specifikationen beskrev det rigtige produkt i første omgang.

Design validering er en proces, hvor softwareproduktet evalueres i forhold til slutbrugernes eller interessenternes præcise krav. Formålet med designvalidering er at teste softwareproduktet efter udvikling for at bekræfte, at det opfylder disse krav, når det bruges i brugerens eget miljø.

Validering handler om at demonstrere et designs konsistens og fuldstændighed i forhold til brugernes behov. Dette er den fase, hvor du rent faktisk bygger en version af produktet og validerer det i forhold til brugerens krav.

Banneret nedenfor markerer de to halvdele af aktiviteten, som de normalt præsenteres i designregistreringer.

Diagrammet nedenfor viser selve designvalideringsprocessen, fra brugerens behov til det validerede produkt.

Formålet er at bevise med objektive beviser, at produktet opfylder de dokumenterede brugerbehov. Objektive beviser er blot fysisk bevis på outputtet – et billede, en tekstfil, en lydfil eller en underskrevet rapport – der viser, at proceduren faktisk blev udført.

Gennem denne objektive evidens undersøger processen konsekvent, om produktet opfylder de foruddefinerede krav. Det involverer testaktivitet, inspektion, analyse og lignende teknikker, hvilket er grunden til, at validering normalt trækker på system test og test af brugeraccept snarere end på kontroller på enhedsniveau.

Forskellen mellem designverifikation og validering

Der er altid misforståelser mellem verifikation og validering. De er forskellige aktiviteter, og begge udføres på alle stadier af udviklingsprocessen snarere end ved en enkelt milepæl.

En nyttig genvej: verifikation er for det meste statisk arbejde mod dokumenter, mens validering for det meste er dynamisk test mod en løbende build.

Design verifikationsproces

Verifikationsprocessen foregår i fem faser, og hver fase producerer en artefakt, som den næste fase afhænger af.

Identifikation og forberedelse:

• Mens en specifikation udvikles, identificeres verifikationsaktivitet parallelt. Dette giver designeren mulighed for at sikre, at specifikationen faktisk er verificerbar, så en testingeniør kan begynde på detaljerede testplaner og -procedurer. Enhver ændring af specifikationen skal kommunikeres.
• Identificer den bedste metode til at udføre verifikation, og definer målemetoder, nødvendige ressourcer, værktøjer og faciliteter.
• Den færdige verifikationsplan gennemgås med designteamet for at afdække problemer, inden planen færdiggøres.

Planlægning:

• Planlægning af verifikation er en sideløbende aktivitet med kerne- og udviklingsteamene. Den foregår gennem hele projektets livscyklus og opdateres, når designinput ændres.
• I denne fase dokumenteres omfanget af den software eller det system, der testes.
• En foreløbig testplan udarbejdes og forfines derefter. Planen indfanger de kritiske milepæle, der reducerer projektrisikoen.
• Værktøjer, testmiljø og udviklingsstrategi udvælges, og de krav, der skal bekræftes gennem inspektion eller analyse, identificeres.

Udviklingping:

• Test tilfælde udviklingen falder sammen med SDLC metode som projektgruppen har implementeret. En række forskellige testmetoder identificeres på dette stadie.
• Designinputtene skal udvikles, så selv de enkleste verifikationsaktiviteter er entydige og verificerbare.
• Verifikationstiden reduceres, når lignende koncepter verificeres i rækkefølge, fordi outputtet fra én test kan genbruges som input til en efterfølgende test.
• TracDer oprettes funktionslinks mellem testcases og deres tilsvarende designinput for at sikre, at alle krav testes, og at designoutputtet opfylder designinputtene.

Udførelse:

• Testprocedurerne, der er udarbejdet i udviklingsfasen, udføres i overensstemmelse med testplanen og følges nøje under verifikationsaktiviteten.
• Hvis der opstår ugyldige resultater, eller hvis en procedure skal ændres, skal ændringerne dokumenteres og formelt godkendes.
• Ethvert fundne problem registreres som en fejl via den sædvanlige procedure. proces til håndtering af fejl.
• A tracevnematrix er oprettet for at verificere, at alle designinput, der er identificeret i verifikationstestplanen, er blevet testet, og for at bestemme beståelsesforholdet.

Rapporter:

• Denne aktivitet udføres i slutningen af ​​hver fase af verifikationsudførelsen.
• Designverifikationsrapporten giver et detaljeret resumé af verifikationsresultaterne, herunder konfigurationsstyring, resultaterne for hver type test og de problemer, der blev fundet under verifikationsaktiviteten.
• En designverifikation tracEn funktionsdygtighedsrapport oprettes mellem krav og de tilsvarende testresultater for at bekræfte, at alle krav blev testet, og at passende resultater blev registreret.
• Enhver afvigelse dokumenteres og håndteres behørigt.
• RevDer udføres evalueringer, når designverifikationsaktiviteten er afsluttet, og resultaterne er formelt godkendt.

Design valideringsproces

Validering har ingen lige så stiv rækkefølge. I stedet trækker den på et lille sæt accepterede metoder, og et projekt bruger normalt mere end én af dem.

• Sammenligning med tilsvarende designs. Nogle designs kan valideres ved at sammenligne dem med lignende udstyr, der tjener et lignende formål. Dette er især relevant ved validering af konfigurationsændringer i eksisterende infrastruktur eller standarddesigns, der integreres i et nyt system eller en ny applikation.
• Demonstration og inspektion. Enten eller begge kan bruges til at validere krav og anden funktionalitet i produktet.
• Analyse. Designet kan analyseres gennem matematisk modellering eller en simulering, der genskaber den nødvendige funktionalitet.
• Testing. Der udføres test på det endelige design for at validere systemets evne til at fungere som specificeret, hvilket er hvor funktionstest og ikke-funktionel testning opfylde brugerens krav.
• Dokumentation. Testplanen, udførelsen og resultaterne bør dokumenteres og vedligeholdes som en del af designregistreringerne. Validering er i sidste ende de indsamlede resultater af alle valideringsaktiviteter.
• Ækvivalensbegrundelse. Når der anvendes ækvivalente produkter i den endelige designvalidering, skal producenten dokumentere ligheden og enhver forskel i forhold til den oprindelige produktion.

Eksempel

Et kortfattet eksempel gør sondringen konkret.

• Tag et simpelt produkt: et vandtæt ur.
• Produktkravdokumentet kan angive, at "uret skal være vandtæt under svømning". Det er brugerens behov, og det er det, validering måles i forhold til.
• Designspecifikationen kan angive, at "uret skal fungere, selvom brugeren svømmer i længere tid". Det er designets input, og det er det, verifikationen måles i forhold til.
• Testresultaterne bør bekræfte, at uret opfylder disse krav. Hvis de ikke gør det, fortsættes redesign-iterationerne, indtil det gør det.

Bemærk hvordan et ur kan bestå verifikation og stadig ikke validere. Hvis specifikationen definerer en forlænget svømmetur som femten minutter, og rigtige svømmere bliver i vandet i en time, matcher designets output perfekt inputtet og skuffer stadig brugeren.

Fordele ved designvalidering og -verifikation

At begge aktiviteter kører kontinuerligt, i stedet for som en port til sidst, er det, der giver nedenstående fordele.

• Design kan overvåges kontinuerligt, hvilket gør det muligt at opfylde de brugerdefinerede krav i alle faser.
• Validering af designet påpeger forskellen mellem, hvordan funktionaliteten fungerer, og hvordan den forventes at fungere.
• Dokumentation af valideringsprocedurerne gør funktionaliteten let at forstå senere, når der foretages en ændring eller forbedring.
• Udviklingstiden reduceres konsekvent, og produktiviteten forbedres, hvilket bidrager til at levere produktet som forventet.
• Processen definerer omfanget og omfanget af hver valideringsmetode, der skal anvendes.
• Validering kan udføres ved hjælp af detaljerede designdata, der repræsenterer de endelige brugerkrav.
• Enhver forskel mellem resultatet og brugerens behov for dokumenter registreres i stedet for at gå tabt.
• Ændringer i et valideret design udløser en genvalideringsaktivitet, så posten aldrig forsvinder fra produktet.
• Dokumentation af alle aktiviteter, der finder sted under valideringen, er det, der tilstrækkeligt beviser, at designet opfylder brugerens krav.

Designverifikation og validering planlægges derfor bedst inden for det bredere livscyklus for softwaretest og kortlagt mod den anden typer af softwaretestning, snarere end at blive behandlet som en separat compliance-øvelse.

Ofte Stillede Spørgsmål