miniatyr|420x420pk|V-modellen er en systemteknisk prosess.Clarus Concept of Operations , Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005. V-modellen er en grafisk fremstilling av en livssyklus for systemutvikling. Den brukes til å produsere stringente livsløpsmodeller for utvikling og prosjektledelse. V-modellen finnes i tre varianter, som er enten den tyske V-Modell, en generell testmodell eller en amerikanske offentlig standard."The Dangerous & Seductive V Model" , accessed January 9, 2013.
V-modellen oppsummerer hovedstegene som skal tas i forbindelse med tilsvarende leveranser innen rammeverk for datastyrt systemvalidering eller et prosjektet sin livssyklusutvikling. Den beskriver aktivitetene som skal utføres og resultatene som må produseres under produktutviklingen.
Venstre side av V-en representerer nedbrytning av krav og opprettelse av systemspesifikasjoner. Høyre side av V-en representerer integrering av delene og validering av dem.Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8 Kravene må imidlertid først valideres mot kravene på høyere nivå eller brukerbehov. Validering av systemmodeller gjøres også på høyre siden, men kan delvis også gjøres på venstre side, slik at å hevde at validering bare skjer på høyre side kanskje ikke er riktig. Den enkleste oppsummeringen er å si at verifisering alltid skjer mot kravene (tekniske begrep) og validering alltid mot den virkelige verden eller brukerens behov. Romfarts-standarden DO-178B fra Radio Technical Commission for Aeronautics (RTCA) sier at kravene er validert, altså bekreftet å være sanne, og at sluttproduktet er verifisert for å sikre at det tilfredsstiller disse kravene.
Validering kan uttrykkes med spørringen "bygger du den rette tingen?" mens for verifikasjon kan man spørre "bygger du det riktig?"
Typer Det finnes tre hovedtyper V-modeller.
V-Modell "V-Modell" er den offisielle prosjektstyringsmetoden til tyske myndigheter. Den tilsvarer omtrent PRINCE2, men mer direkte relevant for programvareutvikling."V-Modell site (in German)" , accessed July 10, 2020. Hovedformålet med å bruke en V-representasjon er å kreve bevis på at produktene fra venstre side av V-en er akseptable for den aktuelle test- og integrasjonsorganisasjonen som implementerer høyre side av V-en.German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992
Generell testmodell Innenfor testfagfeltet internasjonalt har V-modellen blitt sett på som en vagere illustrativ skildring av programvareutviklingsprosessen slik den er beskrevet i International Software Testing Qualifications Board sitt grunnleggende pensum for programvaretestere."International Software Testing Qualifications Board – Foundation Level Syllabus" , accessed January 9, 2013. Det finnes ingen enkel definisjon av denne modellen, men flere ulike varianter som følger lignende prinsipper (se egen artikkel om V-modell (programvareutvikling).
Offentlig amerikansk standard I USA har myndighetene laget en V-modell som er omtrent like gammel som sin tyske motpart. Omfanget er en smalere livssyklusmodell for systemutvikling, men er samtidig langt mer detaljert og stringent enn de fleste britiske utøvere og testere ville forstått den generelle V-modellen."US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS", accessed January 9, 2013.Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8
Validering kontra verifisering Noen ganger sies det at validering kan uttrykkes ved spørsmålet "bygger du det rette?" og verifisering med spørsmålet "bygger du det riktig?" I praksis varierer bruken av disse begrepene.
PMBOK-guiden, som også har blitt tatt i bruk av IEEE som en standard (vedlikeholdt i samarbeid mellom INCOSE, Systems Engineering Research Center og IEEE Computer Society) definerer dem som følger i den 4. utgaven (direkte oversatt til norsk):
"Validering: Å sikre at et produkt, en tjeneste eller et system oppfyller behovene til kunden og andre identifiserte interessenter. Det innebærer ofte akseptanse av og egnethet hos eksterne kunder. Står i kontrast med verifisering." "Verifisering: Evaluering av hvorvidt et produkt, en tjeneste eller et system er i samsvar med en regulering, krav, spesifikasjon eller pålagt betingelse. Det er ofte en intern prosess. Står i kontrast med validering."
Formål V-modellen gir en veiledning for planlegging og realisering av prosjekter. Følgende mål er ment å oppnås ved en prosjektgjennomføring:
Minimering av prosjektrisiko: V-modellen forbedrer prosjekttransparens og prosjektkontroll ved å spesifisere standardiserte tilnærminger og beskrive de tilsvarende resultatene og ansvarlige roller. Den gjør det mulig å tidlig fange opp avvik fra planer og risikoer og forbedrer prosessledelse, og reduserer dermed prosjektrisikoen. Kvalitetssikring og garanti for kvalitet: Som en standardisert prosessmodell sikrer V-modellen at resultatene som skal leveres er komplette og har ønsket kvalitet. Definerte mellomresultater kan sjekkes på et tidlig tidspunkt. Ensartet produktinnhold vil forbedre lesbarhet, forståelighet og verifiserbarhet. Reduksjon av total kostnad gjennom hele prosjektets og systemets livssyklus: Innsatsen i utvikling, produksjon, drift og vedlikehold av et system kan beregnes, estimeres og kontrolleres på en gjennomsiktig måte ved å bruke en standardisert prosessmodell. Resultatene som oppnås er ensartede og kan enkelt trekkes tilbake. Dette reduserer erververens avhengighet av leverandøren og innsats i påfølgende aktiviteter og prosjekter. Forbedret kommunikasjonen mellom alle interessenter: Den standardiserte og enhetlige beskrivelsen av alle relevante elementer og vilkår er grunnlaget for gjensidig forståelse mellom alle interessenter. Dermed reduseres tap grunnet friksjon mellom bruker, erverver, leverandør og utvikler.
Emner i V-modellen miniatyr|320x320pk|Systemutvikling og verifisering.Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.
Systemutvikling og verifisering Systemutviklingsprosessen gir en måte å forbedre kostnadseffektiviteten til komplekse systemer som systemeieren vil oppleve gjennom hele systemets levetid, fra unnfangelse til dekommisjonering. Prosessen innebærer tidlig og omfattende identifisering av mål, et operasjonskonsept som beskriver brukerbehov og driftsmiljø, grundige og testbare systemkrav, detaljert design, implementering, streng akseptansetesting av det implementerte systemet for å sikre at det oppfyller de angitte kravene (systemverifisering), måling effektiviteten i å svare på målene (systemvalidering), pågående drift og vedlikehold, systemoppgraderinger over tid og eventuell dekommisjonering.Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8
Prosessen legger vekt på kravdrevet design og testing. Alle designelementer og akseptansetester må kunne spores til ett eller flere systemkrav, og hvert krav må svare på minst ett designelement og en akseptansetest. Slik strenghet sikrer at ingenting blir gjort unødvendig og at alt som er nødvendig blir oppnådd.Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.
De to strømmene Spesifikasjonsstrøm Spesifikasjonsstrømmen består hovedsakelig av: Spesifikasjoner av brukerkrav Funksjonelle kravspesifikasjoner Designspesifikasjoner
Teststrømmen består vanligvis av: Installasjonskvalifisering Operasjonell kvalifisering Ytelseskvalifisering
Utviklingsstrømmen kan (avhengig av systemtype og utviklingsomfang) bestå av tilpasning, konfigurasjon eller koding.
Bruksområder
V-modellen har blitt brukt til å regulere programvareutviklingsprosesser i tysk føderal administrasjon, samt forsvarsprosjekter og programvareutvikling innen regioner.
Konseptet med V-modeller ble utviklet samtidig, men uavhengig fra hverandre, i Tyskland og USA på slutten av 1980-årene:
V-modellen dukket først opp rundt 1982 hos Hughes Aircraft som en del av et konkurransen om programmet FAA Advanced Automation System (AAS), og munnet til slutt ut i teststrategien for Hughes sitt bidrag i Design Competition Phase (DCP). Den ble laget for å vise test- og integrasjonsmetoder som ble drevet av nye utfordringer for å overflate latente feil i programvaren. Behovet for dette nye nivået på deteksjon av latente defekter ble drevet av målet om å begynne å automatisere tenknings- og planleggingsprosessene til flygelederen som var en av formålene med å utvikle en automatisert underveis-flygekontrolltjeneste (automated enroute air traffic control, AERA). Årsaken til at V-en er så kraftig lagt vekt på kom av at Hughes-kulturen hadde sterkt fokus på å koble all tekst og analyse til flerdimensjonale bilder. Det la grunnlaget for Sequential Thematic Organization of Publications (STOP) laget av Hughes i 1963 som ble brukt inntil Hughes ble delt opp og solgt av Howard Hughes Medical Institute i 1985. Den tyske V-modellen ble opprinnelig utviklet av IABG i Ottobrunn nær Munchen i samarbeid med det tyske føderale kontoret for forsvarsteknologi og anskaffelser i Koblenz på oppdrag for det tyske forsvarsdepartementet. Utviklingen ble overtatt av innenriksdepartementet for bruk av sivile offentlige myndigheter sommeren 1992. Den amerikanske V-modellen er dokumentert fra referater i 1991 fra National Council of Systems Engineering (NCOSE, senere INCOSE fra 1995),Forsberg, K. and Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" , First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991 og ble utviklet for satellittsystemer som involverer maskinvare, programvare og menneskelig interaksjon. Det amerikanske forsvarsdepartementet behandler systemstekniske prosessinteraksjoner etter en V-modell.
V-modellen har fått utbredt anvendelse i kommersielle så vel som forsvarsprogrammer. Den primære bruken er i prosjektledelseForsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8 gjennom hele prosjektets livssyklus.
Et grunnleggende kjennetegn ved den amerikanske V-modellen er at tid og modenhet beveger seg fra venstre til høyre, og man kan ikke bevege seg tilbake i tid. All iterasjon er langs en vertikal linje til høyere eller lavere nivåer i systemhierarkiet, som vist på figuren.Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8 Dette har vist seg å være en viktig del av modellen. Utvidelsen av modellen til et konsept med dobbel-V er omtalt i en kilde.