V-modellen

**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.

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. 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. 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.

### 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. 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. 

## 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

### 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.

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.

### 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), 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 prosjektledelse 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. 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.

Ettersom V-modellen er offentlig tilgjengelig brukes den av mange selskaper. I prosjektledelse er det en metode som kan sammenlignes med PRINCE2, og beskriver metoder for prosjektledelse samt metoder for systemutvikling. Selv om V-modellen har en rigid prosess kan den være veldig fleksibel i bruk, særli når det gjelder omfanget utenfor området for de normale parameterene for systemutviklingens livssyklus.

## Fordeler
Fordeler med V-modellen foran andre systemutviklingsmodeller inkluderer:

* Brukerne av V-modellen deltar i utviklingen og vedlikeholdet av V-modellen. En endringskomité vedlikeholder V-modellen og sikrer at den synliggjøres. Endringekomitéen møtes hvor som helst fra hver dag til ukentlig og behandler alle mottatte endringsforespørsler under systemutvikling og testing.
* V-modellen gir konkrete forslag til hvordan man implementerer en aktivitet og dens arbeidstrinn, og definerer eksplisitt hendelsene som trengs for å fullføre et arbeidstrinn: Hvert aktivitetsdel inneholder instruksjoner, anbefalinger og detaljerte forklaringer på aktiviteten.

## Begrensninger
Følgende aspekter dekkes ikke av V-modellen, og må enten reguleres utenom, eller krever at V-modellen må tilpasses:

* Plassering av kontrakter for tjenester er ikke regulert.
* Organisering og gjennomføring av drift, vedlikehold, reparasjon og avhending av systemet dekkes ikke av V-modellen. Planlegging og utarbeidelse av et konsept for disse oppgavene er imidlertid regulert i V-modellen.
* V-modellen tar for seg programvareutvikling i et prosjekt i stedet for i hele organisasjonen.

## Se også
* Informasjonsforvaltning, herunder teknisk informasjonsforvaltning
* Rational Unified Process, et rammeverk for å støtte programvareutvikling
* Fossefallmodellen
* Systemarkitektur
* Systemering (systemdesign)
* Systemteknikk, fagfelt rundt design og administrasjon av komplekse systemer
* Theory U, en metode for endringsledelse

## Referanser