Designverifiering och valideringsprocess

Designverifiering

Designverifiering är en metod för att bekräfta, genom granskning och genom att tillhandahålla bevis, att utdata från en designad programvaruprodukt uppfyller dess indataspecifikationer. Målet med designverifieringsprocessen under programvaruutveckling är att säkerställa att den designade programvaruprodukten är densamma som vad som specificerades.

Designinput är alla fysiska krav och prestandakrav som används som grund för designen. Designoutput är resultatet av varje designfas och av den totala designinsatsen. Inom reglerade branscher som medicintekniska produkter blir den slutliga designoutputen grunden för enhetens huvuddata, vilket är anledningen till att designkontrollvokabulär förekommer så ofta i verifieringsdokumentation.

I praktiken jämför verifiering två uppsättningar dokument: de specifikationer, standarder och begränsningar som angavs mot de ritningar, kod och testinstruktioner som utfärdades. Varje avvikelse mellan dem är ett verifieringsresultat.

Design validering

Verifiering bevisar intern konsistens. Validering ställer den svårare frågan om huruvida specifikationen beskrev rätt produkt från första början.

Design validering är en process för att utvärdera programvaruprodukten mot slutanvändarnas eller intressenternas exakta krav. Syftet med designvalidering är att testa programvaruprodukten efter utveckling för att bekräfta att den uppfyller dessa krav när den används i användarens egen miljö.

Validering handlar om att visa att en design är konsekvent och fullständig med avseende på användarnas behov. Det här är steget där man faktiskt bygger en version av produkten och validerar den mot användarnas krav.

Bannern nedan markerar de två halvorna av aktiviteten så som de vanligtvis presenteras i designdokument.

Diagrammet som följer visar själva designvalideringsprocessen, från användarnas behov till den validerade produkten.

Syftet är att med objektiva bevis bevisa att produkten uppfyller de dokumenterade användarbehoven. Objektiva bevis är helt enkelt fysiska bevis på resultatet – en bild, en textfil, en ljudfil eller en signerad rapport – som visar att proceduren faktiskt utfördes.

Genom dessa objektiva bevis undersöker processen konsekvent om produkten uppfyller de fördefinierade kraven. Det involverar testaktivitet, inspektion, analys och liknande tekniker, vilket är anledningen till att validering vanligtvis bygger på systemtestning och testning av användaracceptans snarare än på kontroller på enhetsnivå.

Skillnad mellan designverifiering och validering

Det finns alltid missuppfattningar mellan verifiering och validering. De är olika aktiviteter, och båda utförs i varje steg av utvecklingsprocessen snarare än vid en enda milstolpe.

En användbar genväg: verifiering är mestadels statiskt arbete mot dokument, medan validering mestadels är dynamisk testning mot en löpande byggnad.

Designverifieringsprocess

Verifieringsprocessen sker i fem steg, och varje steg producerar en artefakt som nästa steg är beroende av.

Identifiering och förberedelse:

• Medan en specifikation utvecklas identifieras verifieringsaktivitet parallellt. Detta gör det möjligt för konstruktören att säkerställa att specifikationen faktiskt är verifierbar, så att en testingenjör kan börja med detaljerade testplaner och procedurer. Alla ändringar i specifikationen måste kommuniceras.
• Identifiera den bästa metoden för att utföra verifiering och definiera mätmetoder, nödvändiga resurser, verktyg och anläggningar.
• Den färdiga verifieringsplanen granskas med designteamet för att upptäcka problem innan planen slutförs.

Planera:

• Planering för verifiering är en samtidig aktivitet med kärn- och utvecklingsteamen. Den sker under hela projektets livscykel och uppdateras närhelst designinputen ändras.
• Under denna fas dokumenteras omfattningen av den programvara eller det system som testas.
• En preliminär testplan skrivs och förfinas sedan. Planen fångar upp de kritiska milstolpar som minskar projektrisken.
• Verktyg, testmiljö och utvecklingsstrategi väljs ut, och de krav som ska bekräftas genom inspektion eller analys identifieras.

Utvecklaping:

• Testfall utvecklingen sammanfaller med SDLC metodik som projektgruppen har implementerat. En mängd olika testmetoder identifieras i detta skede.
• Designunderlagen måste utvecklas så att även de enklaste verifieringsaktiviteterna är entydiga och verifierbara.
• Verifieringstiden minskar när liknande koncept verifieras i följd, eftersom utdata från ett test kan återanvändas som indata för ett efterföljande test.
• TracFunktionslänkar skapas mellan testfall och deras motsvarande designindata, för att säkerställa att alla krav testas och att designutgången uppfyller designindata.

Genomförande

• Testprocedurerna som skapas under utvecklingsfasen utförs i enlighet med testplanen och följs strikt under verifieringsaktiviteten.
• Om ogiltiga resultat uppstår, eller om någon procedur behöver modifieras, måste ändringarna dokumenteras och formellt godkännas.
• Alla problem som upptäcks loggas som defekt enligt den vanliga metoden. process för felhantering.
• A tracförmågasmatris skapas för att verifiera att varje designinput som identifierats i verifieringstestplanen har testats och för att bestämma godkännandegraden.

Rapporter:

• Denna aktivitet utförs i slutet av varje fas av verifieringsutförandet.
• Designverifieringsrapporten ger en detaljerad sammanfattning av verifieringsresultaten, inklusive konfigurationshantering, resultaten för varje typ av testning och de problem som upptäcktes under verifieringsaktiviteten.
• En designverifiering tracEn hållbarhetsrapport skapas mellan krav och motsvarande testresultat för att bekräfta att alla krav har testats och att lämpliga resultat har registrerats.
• Eventuella avvikelser dokumenteras och åtgärdas på lämpligt sätt.
• RevVisningar genomförs när designverifieringen är slutförd och resultaten är formellt godkända.

Designvalideringsprocess

Validering har ingen lika strikt sekvens. Istället använder den sig av en liten uppsättning accepterade metoder, och ett projekt använder normalt mer än en av dem.

• Jämförelse med likvärdiga designer. Vissa konstruktioner kan valideras genom att jämföra dem med liknande utrustning som tjänar ett liknande syfte. Detta är särskilt relevant vid validering av konfigurationsändringar i befintlig infrastruktur, eller standardkonstruktioner som införlivas i ett nytt system eller en ny applikation.
• Demonstration och inspektion. Antingen eller båda kan användas för att validera krav och annan funktionalitet hos produkten.
• Analys. Designen kan analyseras genom matematisk modellering eller en simulering som återskapar den erforderliga funktionaliteten.
• Testning. Tester utförs på den slutliga designen för att validera systemets förmåga att fungera enligt specifikationen, vilket är där funktionstestning och icke-funktionell testning uppfylla användarnas krav.
• Dokumentation. Testplanen, utförandet och resultaten bör dokumenteras och bevaras som en del av designdokumentationen. Validering är i slutändan de insamlade resultaten av alla valideringsaktiviteter.
• Ekvivalensmotivering. När likvärdiga produkter används i den slutliga designvalideringen måste tillverkaren dokumentera likheten och eventuella skillnader från den ursprungliga produktionen.

Exempelvis

Ett kortfattat exempel gör skillnaden konkret.

• Ta en enkel produkt: en vattentät klocka.
• Produktkravdokumentet kan ange att ”klockan måste vara vattentät vid simning”. Det är användarbehovet, och det är det som valideringen mäts mot.
• Designspecifikationen kan ange att ”klockan ska fungera även om användaren simmar under en längre tid”. Det är designindata, och det är det som verifieringen mäts mot.
• Testresultaten bör bekräfta att klockan uppfyller dessa krav. Om de inte gör det fortsätter omdesignen tills den gör det.

Lägg märke till hur en klocka kan klara verifieringen och ändå misslyckas med valideringen. Om specifikationen definierar en längre simtur som femton minuter och riktiga simmare stannar i vattnet i en timme, matchar designutgången dess indata perfekt och misslyckas fortfarande med användaren.

Fördelar med designvalidering och verifiering

Att köra båda aktiviteterna kontinuerligt, snarare än som en grind i slutet, är det som ger fördelarna nedan.

• Design kan övervakas kontinuerligt, vilket gör det möjligt att uppfylla användardefinierade krav i varje steg.
• Att validera designen pekar på skillnaden mellan hur funktionaliteten fungerar och hur den förväntas fungera.
• Att dokumentera valideringsprocedurerna gör funktionaliteten lätt att förstå senare, närhelst en ändring eller förbättring görs.
• Utvecklingstiden minskas konsekvent och produktiviteten förbättras, vilket bidrar till att leverera produkten som förväntat.
• Processen definierar omfattningen och omfattningen av varje valideringsmetod som måste användas.
• Validering kan utföras med hjälp av detaljerade designdata som representerar de slutliga användarkraven.
• Eventuella skillnader mellan resultatet och användarbehovsdokumenten registreras snarare än förloras.
• Ändringar i en validerad design utlöser en omvalideringsaktivitet, så att posten aldrig försvinner från produkten.
• Att dokumentera varje aktivitet som sker under valideringen är det som på ett adekvat sätt bevisar att designen uppfyller användarnas krav.

Designverifiering och validering planeras därför bäst inom ramen för det bredare livscykel för mjukvarutestning och mappad mot den andra typer av mjukvarutestning, snarare än att behandlas som en separat efterlevnadsövning.

Vanliga frågor