Softwarebekræftelse og validering - Software verification and validation

IEEE softwares livscyklus

I softwareprojektstyring , softwaretest og softwareteknik er verifikation og validering ( V&V ) processen med at kontrollere, om et softwaresystem opfylder specifikationer og krav, så det opfylder dets tilsigtede formål. Det kan også kaldes software kvalitetskontrol . Det er normalt softwaretesters ansvar som en del af softwareudviklingens livscyklus . Simpelthen er softwareverifikation: "Forudsat at vi skal bygge X, når vores software sine mål uden fejl eller huller?" På den anden side er softwarevalidering: "Var X det, vi skulle have bygget? Opfylder X kravene på højt niveau?"

Definitioner

Verifikation og validering er ikke det samme, selvom de ofte er forvirrede. Boehm udtrykte kortfattet forskellen som

  • Verifikation: Bygger vi produktet rigtigt?
  • Validering: Bygger vi det rigtige produkt?

"Opbygning af produktet korrekt" kontrollerer, at specifikationerne er korrekt implementeret af systemet, mens "opbygning af det rigtige produkt" refererer tilbage til brugerens behov . I nogle sammenhænge er det påkrævet at have skriftlige krav til både formelle procedurer eller protokoller til bestemmelse af overholdelse. Ideelt set giver formelle metoder en matematisk garanti for, at software opfylder dets specifikationer.

At bygge produktretten indebærer brug af kravspecifikationen som input til den næste fase af udviklingsprocessen, designprocessen, hvis output er designspecifikationen. Derefter indebærer det også brug af designspecifikationen til at fodre byggeprocessen. Hver gang output fra en proces korrekt implementerer sin inputspecifikation, er softwareproduktet et skridt tættere på den endelige verifikation. Hvis output fra en proces er forkert, bygger udviklerne ikke det produkt, interessenterne ønsker korrekt. Denne form for verifikation kaldes "artefakt eller specifikationsbekræftelse".

At bygge det rigtige produkt indebærer oprettelse af en kravspecifikation, der indeholder behovene og målene for interessenterne i softwareproduktet. Hvis en sådan artefakt er ufuldstændig eller forkert, vil udviklerne ikke være i stand til at bygge det produkt, interessenterne ønsker. Dette er en form for "artefakt eller specifikationsvalidering".

Bemærk: Verifikationen begynder før validering, og derefter kører de parallelt, indtil softwareproduktet frigives.

Software verifikation

Det ville indebære at kontrollere, om specifikationerne er opfyldt ved at køre softwaren, men dette er ikke muligt (f.eks. Hvordan kan nogen vide, om arkitekturen/designet/osv. Er korrekt implementeret ved at køre softwaren?). Kun ved at gennemgå de tilhørende artefakter kan nogen konkludere, om specifikationerne er opfyldt eller ej.

Verifikation af artefakt eller specifikation

Output fra hvert softwareudviklingsprocesstadium kan også underkastes verifikation, når det kontrolleres i forhold til dets inputspecifikation (se definitionen af ​​CMMI nedenfor).

Eksempler på artefaktverifikation:

  • Af designspecifikationen mod kravspecifikationen: Implementerer arkitektonisk design, detaljeret design og database logiske modelspecifikationer de funktionelle og ikke-funktionelle kravspecifikationer korrekt?
  • Af konstruktionens artefakter mod designspecifikationen: Implementerer kildekoden, brugergrænsefladerne og databasens fysiske model designspecifikationen korrekt?

Software validering

Softwarevalidering kontrollerer, at softwareproduktet tilfredsstiller eller passer til den påtænkte anvendelse (kontrol på højt niveau), dvs. at softwaren opfylder brugerens krav, ikke som specifikationsartefakter eller som behov hos dem, der kun betjener softwaren; men som behovene hos alle interessenter (f.eks. brugere, operatører, administratorer, ledere, investorer osv.). Der er to måder at udføre softwarevalidering på: intern og ekstern. Under intern softwarevalidering antages det, at interessenternes mål blev korrekt forstået, og at de blev udtrykt præcist og omfattende i kravartefakterne. Hvis softwaren opfylder kravspecifikationen, er den blevet internt valideret. Ekstern validering sker, når den udføres ved at spørge interessenterne, om softwaren opfylder deres behov. Forskellige softwareudviklingsmetoder kræver forskellige niveauer af bruger- og interessentinddragelse og feedback; så ekstern validering kan være en diskret eller en kontinuerlig begivenhed. En vellykket endelig ekstern validering sker, når alle interessenter accepterer softwareproduktet og udtrykker, at det opfylder deres behov. En sådan endelig ekstern validering kræver brug af en accepttest, som er en dynamisk test .

Det er imidlertid også muligt at udføre interne statiske tests for at finde ud af, om softwaren opfylder kravene, men det falder ind under statisk verifikation, fordi softwaren ikke kører.

Artefakt eller specifikationsvalidering

Krav bør valideres, før softwareproduktet som helhed er klar (vandfaldsudviklingsprocessen kræver, at de er fuldstændigt defineret, inden designet starter; men iterative udviklingsprocesser kræver ikke, at dette er sådan og tillader deres løbende forbedring).

Eksempler på artefaktvalidering:

  • Validering af brugerkravspecifikation: Brugerkrav som angivet i et dokument kaldet brugerkravspecifikation valideres ved at kontrollere, om de virkelig repræsenterer interessenternes vilje og mål. Dette kan gøres ved at interviewe interessenterne og spørge dem direkte (statisk testning) eller endda ved at frigive prototyper og have brugerne og interessenterne til at vurdere dem (dynamisk test).
  • Validering af brugerinput: Brugerinput (indsamlet af en hvilken som helst perifer enhed som tastatur, biometrisk sensor osv.) Valideres ved at kontrollere, om input fra softwareoperatørerne eller brugerne opfylder domænereglerne og begrænsningerne (f.eks. Datatype, område og format).

Validering kontra verifikation

I henhold til Capability Maturity Model (CMMI-SW v1.1),

  • Softwarevalidering: Processen med at evaluere software under eller ved afslutningen af ​​udviklingsprocessen for at afgøre, om den opfylder specificerede krav. [IEEE-STD-610]
  • Softwareverifikation: Processen med at evaluere software for at afgøre, om produkterne fra en given udviklingsfase opfylder de betingelser, der blev pålagt ved starten af ​​denne fase. [IEEE-STD-610]

Validering under softwareudviklingsprocessen kan ses som en form for validering af brugerkrav. og, at ved afslutningen af ​​udviklingsprocessen svarer til intern og/eller ekstern softwarevalidering. Verifikation fra CMMI's synspunkt er tydeligvis af artefaktarten.

Med andre ord sikrer softwareverifikation, at output fra hver fase af softwareudviklingsprocessen effektivt udfører, hvad dets tilsvarende inputartefakt specificerer (krav -> design -> softwareprodukt), mens softwarevalidering sikrer, at softwareproduktet opfylder behovene hos alle interessenter (derfor blev kravspecifikationen i første omgang udtrykt korrekt og præcist). Softwareverifikation sikrer, at "du har bygget det rigtigt" og bekræfter, at produktet, som det er leveret, opfylder udviklernes planer. Softwarevalidering sikrer, at "du byggede det rigtige" og bekræfter, at produktet, som det er leveret, opfylder interessenternes påtænkte anvendelse og mål.

Denne artikel har brugt den strenge eller snævre definition af verifikation.

Fra et testperspektiv:

  • Fejl - forkert eller manglende funktion i koden.
  • Fejl - manifestation af en fejl under udførelsen. Softwaren var ikke effektiv. Det gør ikke "hvad" det skal gøre.
  • Fejl - i henhold til dens specifikation opfylder systemet ikke den angivne funktionalitet. Softwaren var ikke effektiv (den tog for mange ressourcer såsom CPU -cyklusser, den brugte for meget hukommelse, udførte for mange I/O -operationer osv.), Den var ikke brugbar, den var ikke pålidelig osv. Den gør ikke noget "hvordan" det skal gøre det.

Relaterede koncepter

Både verifikation og validering er relateret til begreberne kvalitet og software kvalitetssikring . I sig selv garanterer verifikation og validering ikke softwarekvalitet; planlægning, sporbarhed , konfigurationsstyring og andre aspekter af softwareteknik er påkrævet.

Inden for modellerings- og simulering (M&S) -samfundet er definitionerne af verifikation, validering og akkreditering ens:

  • M&S Verification er processen med at bestemme, at en computermodel , simulering eller sammenslutning af modeller og simuleringerimplementeringer og deres tilhørende data nøjagtigt repræsenterer udviklerens konceptuelle beskrivelse og specifikationer.
  • M&S Validation er processen med at bestemme, i hvilken grad en model, simulering eller sammenslutning af modeller og simuleringer og deres tilhørende data er nøjagtige repræsentationer af den virkelige verden set fra den eller de påtænkte anvendelser.
  • Akkreditering er den formelle certificering af, at en model eller simulering er acceptabel til at blive brugt til et specifikt formål.

Definitionen af ​​M & S-validering fokuserer på den nøjagtighed, hvormed M&S repræsenterer den eller de påtænkte anvendelser. Det er påkrævet at bestemme graden af ​​M & S -nøjagtighed, fordi alle M&S er tilnærmelser til virkeligheden, og det er normalt kritisk at afgøre, om graden af ​​tilnærmelse er acceptabel til den eller de påtænkte anvendelser. Dette står i kontrast til softwarevalidering.

V&V metoder

Formel

I missionskritiske softwaresystemer kan der bruges formelle metoder til at sikre, at et system fungerer korrekt. Disse formelle metoder kan imidlertid vise sig at være dyre og repræsentere så meget som 80 procent af de samlede omkostninger til software design.

Uafhængig

Independent Software Verification and Validation (ISVV) er målrettet mod sikkerhedskritiske softwaresystemer og har til formål at øge kvaliteten af ​​softwareprodukter og derved reducere risici og omkostninger gennem softwarens driftstid. Målet med ISVV er at give sikkerhed for, at software udfører det angivne niveau af tillid og inden for dets designede parametre og definerede krav.

ISVV -aktiviteter udføres af uafhængige ingeniørteam, der ikke er involveret i softwareudviklingsprocessen, for at vurdere processerne og de resulterende produkter. ISVV -teamets uafhængighed udføres på tre forskellige niveauer: økonomisk, ledelsesmæssigt og teknisk.

ISVV går ud over "traditionelle" verifikations- og valideringsteknikker, der anvendes af udviklingsteams. Selvom sidstnævnte har til formål at sikre, at softwaren fungerer godt i forhold til de nominelle krav, er ISVV fokuseret på ikke-funktionelle krav som robusthed og pålidelighed og på forhold, der kan få softwaren til at mislykkes.

ISVV -resultater og fund tilbageføres til udviklingsteamene til korrektion og forbedring.

Historie

ISVV stammer fra anvendelsen af ​​IV&V (Independent Verification and Validation) til softwaren. Tidlig ISVV-applikation (som kendt i dag) går tilbage til begyndelsen af ​​1970'erne, da den amerikanske hær sponsorerede det første betydelige program relateret til IV&V for Safeguard Anti-Ballistic Missile System. Et andet eksempel er NASAs IV & V -program, der blev etableret i 1993.

I slutningen af ​​1970'erne blev IV&V hurtigt ved at blive populær. Softwarens konstante stigning i kompleksitet, størrelse og betydning førte til en stigende efterspørgsel på IV&V anvendt på software.

I mellemtiden konsolideres IV&V (og ISVV til softwaresystemer) og bruges nu i vid udstrækning af organisationer som DoD , FAA , NASA og ESA . IV&V er nævnt i DO-178B , ISO/IEC 12207 og formaliseret i IEEE 1012 .

Hos ESA

Oprindeligt i 2004-2005 oprettede et europæisk konsortium ledet af European Space Agency og sammensat af DNV , Critical Software SA , Terma og CODA SciSys plc den første version af en guide dedikeret til ISVV, kaldet "ESA Guide for Independent Verification and Validation "med støtte fra andre organisationer. Denne vejledning dækker de metoder, der gælder for alle softwaretekniske faser i det, der vedrører ISVV.

I 2008 udgav European Space Agency en anden version efter at have modtaget input fra mange forskellige europæiske rumfart ISVV -interessenter.

Metodik

ISVV består normalt af fem hovedfaser, disse faser kan udføres sekventielt eller som et resultat af en skræddersyingsproces.

Planlægning

  • Planlægning af ISVV -aktiviteter
  • Systemkritikalitetsanalyse: Identifikation af kritiske komponenter gennem et sæt RAMS -aktiviteter (Value for Money)
  • Valg af passende metoder og værktøjer

Krav verifikation

  • Verifikation for: fuldstændighed, rigtighed, testbarhed

Designbekræftelse

  • Design tilstrækkelighed og overensstemmelse med softwarekrav og grænseflader
  • Intern og ekstern konsistens
  • Verifikation af gennemførlighed og vedligeholdelse

Kodebekræftelse

Validering

  • Identifikation af ustabile komponenter/funktioner
  • Validering fokuseret på fejlhåndtering: komplementær (ikke samtidig) validering vedrørende den udført af udviklingsteamet
  • Overholdelse af software og systemkrav
  • Black box test og White box test teknikker
  • Erfaringsbaserede teknikker

Lovgivningsmiljø

Software skal ofte opfylde overholdelseskravene i lovligt regulerede industrier, som ofte styres af offentlige myndigheder eller industrielle administrative myndigheder. F.eks. Kræver FDA, at softwareversioner og patches valideres.

Se også

Yderligere læsning

  • 1012-2012 IEEE Standard for system- og softwareverifikation og validering . 2012. doi : 10.1109/IEEESTD.2012.6204026 . ISBN 978-0-7381-7268-2.
  • Tran, E. (1999). "Verifikation/validering/certificering" . I Koopman, P. (red.). Emner i pålidelige indlejrede systemer . Carnegie Mellon University . Hentet 2007-05-18 .
  • Menzies, T .; Y. Hu (2003). "Data mining for meget travle mennesker". Computer . 36 (1): 22–29. doi : 10.1109/MC.2003.1244531 .

eksterne links

Referencer

  1. ^ Pham, H. (1999). Software pålidelighed . John Wiley & Sons, Inc. s. 567. ISBN 9813083840. Software validering. Processen med at sikre, at softwaren udfører den rigtige proces. Software Verifikation. Processen med at sikre, at softwaren udfører processen rigtigt. "Ligeledes og også der:" Kort sagt, Boehm (3) udtrykte forskellen mellem softwareverifikation og softwarevalidering som følger: Verifikation: '' Bygger vi produktretten ? '' Validering: '' Bygger vi det rigtige produkt? ''.
  2. ^ "CMMI for Software Engineering, version 1.1, trinvis repræsentation (CMMI-SW, V1.1, iscenesat)" . resources.sei.cmu.edu . Hentet 2021-03-20 .
  3. ^ a b c "Department of Defense Documentation of Verification, Validation & Accreditation (VV&A) for Models and Simulations". Missilforsvarsagentur. 2008. Citer journal kræver |journal=( hjælp )
  4. ^ Rogers, R. (1981-10-26). "Planlægning af uafhængig softwareverifikation og validering" . 3. computere i luftfartskonference . San Diego, CA, USA: American Institute of Aeronautics and Astronautics. doi : 10.2514/6.1981-2100 .
  5. ^ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (2008-05-12). "En uafhængig softwareverifikations- og valideringsproces for rumapplikationer" . SpaceOps 2008 -konference . Heidelberg, Tyskland: American Institute of Aeronautics and Astronautics. doi : 10.2514/6.2008-3517 . ISBN 978-1-62410-167-0.
  6. ^ Lewis, Robert O. (1992). Uafhængig verifikation og validering: en livscyklusteknisk proces til kvalitetssoftware . New York: Wiley. ISBN 0-471-57011-7. OCLC  74908695 .
  7. ^ a b Asbury, Michael (2015-03-09). "Om NASAs IV & V -program" . NASA . Hentet 2021-03-20 .
  8. ^ Balci, O. (2010). "Gyldne regler for verifikation, validering, testning og certificering af modellerings- og simuleringsapplikationer" . udefineret . Hentet 2021-03-20 .
  9. ^ "Flight Software Systems Section (TEC-SWF)" . www.esa.int . Hentet 2021-03-20 .
  10. ^ a b lavva.pt. "Ny ISVV -guide til plads i værkerne" . www.criticalsoftware.com . Hentet 2021-03-20 .
  11. ^ "Generelle principper for softwarevalidering; endelig vejledning for industri og FDA -personale" (PDF) . Food and Drug Administration . 11. januar 2002 . Hentet 12. juli 2009 .
  12. ^ "Vejledning til industrien: Del 11, elektroniske optegnelser; Elektroniske signaturer - omfang og anvendelse" (PDF) . Food and Drug Administration . August 2003 . Hentet 12. juli 2009 .
  13. ^ "Vejledning til industrien: Cybersikkerhed for netværksbaserede medicinske enheder, der indeholder software uden for hylden (OTS)" (PDF) . Food and Drug Administration . 14. januar 2005 . Hentet 12. juli 2009 .