Designverifiserings- og valideringsprosess

Designverifisering

Designverifisering er en metode for å bekrefte, gjennom undersøkelse og ved å fremlegge bevis, at resultatet av et designet programvareprodukt oppfyller dets spesifikasjoner for inndata. Målet med designverifiseringsprosessen under programvareutvikling er å sikre at det designede programvareproduktet er det samme som det som ble spesifisert.

Designinndata er ethvert fysisk krav og ytelseskrav som brukes som grunnlag for designet. Designutdata er resultatet av hver designfase og av den totale designinnsatsen. I regulerte bransjer som medisinsk utstyr, blir det endelige designutdataet grunnlaget for enhetens hovedregister, og det er derfor designkontrollvokabular forekommer så ofte i verifiseringsdokumentasjon.

I praksis sammenligner verifisering to sett med dokumenter: spesifikasjonene, standardene og begrensningene som ble innlevert, mot tegningene, koden og testinstruksjonene som ble utarbeidet. Enhver uoverensstemmelse mellom dem er et verifiseringsfunn.

Designvalidering

Verifisering beviser intern konsistens. Validering stiller det vanskeligere spørsmålet om spesifikasjonen beskrev riktig produkt i utgangspunktet.

Designvalidering er en prosess for å evaluere programvareproduktet mot de eksakte kravene til sluttbrukere eller interessenter. Formålet med designvalidering er å teste programvareproduktet etter utvikling for å bekrefte at det oppfyller disse kravene når det brukes i brukerens eget miljø.

Validering handler om å demonstrere konsistensen og fullstendigheten til et design med hensyn til brukerbehov. Dette er stadiet der du faktisk bygger en versjon av produktet og validerer det mot brukerkravene.

Banneret nedenfor merker de to halvdelene av aktiviteten slik de vanligvis presenteres i designdokumenter.

Diagrammet som følger viser selve designvalideringsprosessen, fra brukerbehov til det validerte produktet.

Hensikten er å bevise med objektive bevis at produktet tilfredsstiller de dokumenterte brukerbehovene. Objektive bevis er rett og slett fysisk bevis på resultatet – et bilde, en tekstfil, en lydfil eller en signert rapport – som viser at prosedyren faktisk ble utført.

Gjennom disse objektive bevisene undersøker prosessen konsekvent om produktet oppfyller de forhåndsdefinerte kravene. Det involverer testaktivitet, inspeksjon, analyse og lignende teknikker, og det er derfor validering vanligvis bygger på systemtesting og brukeraksepttesting snarere enn på kontroller på enhetsnivå.

Forskjellen mellom designverifisering og validering

Det finnes alltid misoppfatninger mellom verifisering og validering. De er forskjellige aktiviteter, og begge utføres på hvert trinn i utviklingsprosessen i stedet for ved en enkelt milepæl.

En nyttig snarvei: verifisering er stort sett statisk arbeid mot dokumenter, mens validering stort sett er dynamisk testing mot en løpende bygg.

Designverifiseringsprosess

Verifiseringsprosessen går i fem trinn, og hvert trinn produserer en artefakt som det neste trinnet er avhengig av.

Identifikasjon og forberedelse:

• Mens en spesifikasjon utvikles, identifiseres verifiseringsaktivitet parallelt. Dette lar designeren forsikre seg om at spesifikasjonen faktisk er verifiserbar, slik at en testingeniør kan starte med detaljerte testplaner og prosedyrer. Enhver endring i spesifikasjonen må kommuniseres.
• Identifiser den beste tilnærmingen for å gjennomføre verifisering og definer målemetoder, nødvendige ressurser, verktøy og fasiliteter.
• Den fullførte verifikasjonsplanen gjennomgås med designteamet for å avdekke problemer før planen ferdigstilles.

Planlegger:

• Planlegging for verifisering er en samtidig aktivitet med kjerne- og utviklingsteamene. Den skjer gjennom hele prosjektets livssyklus og oppdateres når designinnspillene endres.
• I denne fasen dokumenteres omfanget av programvaren eller systemet som testes.
• En foreløpig testplan skrives og deretter forbedres. Planen fanger opp de kritiske milepælene som reduserer prosjektrisikoen.
• Verktøy, testmiljø og utviklingsstrategi velges, og kravene som skal bekreftes gjennom inspeksjon eller analyse identifiseres.

Utviklingping:

• Test tilfelle utviklingen sammenfaller med SDLC-metodikk prosjektgruppen har implementert. En rekke testmetoder identifiseres på dette stadiet.
• Designinnspillene må utvikles slik at selv de enkleste verifiseringsaktivitetene er entydige og verifiserbare.
• Verifiseringstiden reduseres når lignende konsepter verifiseres i rekkefølge, fordi resultatet av én test kan brukes om igjen som input for en påfølgende test.
• TracDet opprettes funksjonslenker mellom testtilfeller og tilhørende designinndata for å sikre at alle krav testes og at designutdataene oppfyller designinndataene.

Henrettelse:

• Testprosedyrene som ble opprettet i utviklingsfasen utføres i samsvar med testplanen og følges strengt under verifiseringsaktiviteten.
• Hvis det oppstår ugyldige resultater, eller hvis en prosedyre må endres, må endringene dokumenteres og formelt godkjennes.
• Ethvert problem som oppdages, registreres som feil gjennom den vanlige prosess for feilhåndtering.
• A tracevnematrise er laget for å bekrefte at alle designinnspill som er identifisert i verifiseringstestplanen har blitt testet, og for å bestemme beståttforholdet.

Rapporter:

• Denne aktiviteten utføres på slutten av hver fase av verifiseringsutførelsen.
• Designverifiseringsrapporten gir et detaljert sammendrag av verifiseringsresultatene, inkludert konfigurasjonsstyring, resultatene for hver type testing og problemene som ble funnet under verifiseringsaktiviteten.
• En designverifisering tracEn testrapport opprettes mellom krav og tilhørende testresultater for å bekrefte at alle krav ble testet og at passende resultater ble registrert.
• Eventuelle avvik dokumenteres og håndteres på riktig måte.
• RevVisninger gjennomføres når designverifiseringsaktiviteten er fullført, og resultatene er formelt godkjent.

Designvalideringsprosess

Validering har ingen like rigid sekvens. I stedet benytter den seg av et lite sett med aksepterte metoder, og et prosjekt bruker vanligvis mer enn én av dem.

• Sammenligning med tilsvarende design. Noen design kan valideres ved å sammenligne dem med lignende utstyr som tjener et lignende formål. Dette er spesielt relevant når man validerer konfigurasjonsendringer i eksisterende infrastruktur, eller standarddesign som innlemmes i et nytt system eller en ny applikasjon.
• Demonstrasjon og inspeksjon. Enten eller begge kan brukes til å validere krav og annen funksjonalitet i produktet.
• Analyse. Designet kan analyseres gjennom matematisk modellering eller en simulering som gjenskaper den nødvendige funksjonaliteten.
• Testing. Tester utføres på den endelige designen for å validere systemets evne til å fungere som spesifisert, og det er her funksjonstesting og ikke-funksjonell testing oppfylle brukerens krav.
• Dokumentasjon. Testplanen, utførelsen og resultatene bør dokumenteres og vedlikeholdes som en del av designregistreringen. Validering er til syvende og sist de innsamlede resultatene av alle valideringsaktiviteter.
• Ekvivalensbegrunnelse. Når likeverdige produkter brukes i den endelige designvalideringen, må produsenten dokumentere likheten og eventuelle forskjeller fra den opprinnelige produksjonen.

Eksempel

Et kortfattet eksempel gjør skillet konkret.

• Ta et enkelt produkt: en vanntett klokke.
• Produktkravdokumentet kan si at «klokken må være vanntett under svømming». Det er brukerens behov, og det er det validering måles mot.
• Designspesifikasjonen kan si at «klokken skal fungere selv om brukeren svømmer over lengre tid». Det er designinndataene, og det er det verifiseringen måles mot.
• Testresultatene bør bekrefte at klokken oppfyller disse kravene. Hvis de ikke gjør det, fortsetter redesign-iterasjonene inntil den gjør det.

Legg merke til hvordan en klokke kan bestå verifiseringen og fortsatt ikke validere. Hvis spesifikasjonen definerer en langvarig svømmetur som femten minutter, og ekte svømmere holder seg i vannet i en time, samsvarer designutdataene perfekt med inputen, og brukeren blir fortsatt skuffet.

Fordeler med designvalidering og verifisering

Å kjøre begge aktivitetene kontinuerlig, i stedet for som en port på slutten, er det som gir fordelene nedenfor.

• Design kan overvåkes kontinuerlig, noe som gjør det mulig å oppfylle brukerdefinerte krav i alle trinn.
• Validering av designet peker på forskjellen mellom hvordan funksjonaliteten fungerer og hvordan den forventes å fungere.
• Dokumentasjon av valideringsprosedyrene gjør funksjonaliteten enkel å forstå senere, når en endring eller forbedring gjøres.
• Utviklingstiden reduseres jevnt og trutt, og produktiviteten forbedres, noe som bidrar til å levere produktet som forventet.
• Prosessen definerer omfanget og omfanget av hver valideringsmetode som må benyttes.
• Validering kan utføres ved hjelp av detaljerte designdata som representerer de endelige brukerkravene.
• Enhver forskjell mellom resultatet og brukerens behov for dokumenter registreres i stedet for å gå tapt.
• Endringer i et validert design utløser en revalideringsaktivitet, slik at posten aldri forsvinner fra produktet.
• Å dokumentere all aktivitet som skjer under valideringen er det som på en tilstrekkelig måte beviser at designet oppfyller brukerens krav.

Designverifisering og validering planlegges derfor best innenfor det bredere livssyklus for programvaretesting og kartlagt mot den andre typer programvaretesting, snarere enn å bli behandlet som en separat samsvarsøvelse.

Spørsmål og svar