Redigerer V-modellen

[[Fil:Systems_Engineering_Process_II.svg|miniatyr|420x420pk|V-modellen er en [[Systemteknikk|systemteknisk]] prosess.<ref name="FHWA 05">[http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm ''Clarus Concept of Operations''] {{Webarchive|url=https://web.archive.org/web/20090705102900/http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm|date=2009-07-05}}, Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.</ref>]]
'''V-modellen''' er en grafisk fremstilling av en [[Systemutvikling|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.<ref>[http://www.clarotesting.com/page11.htm#coherence "The Dangerous & Seductive V Model"] {{Wayback|url=http://www.clarotesting.com/page11.htm#coherence |date=20170627042804 }} {{Webarchive|url=https://web.archive.org/web/20190915230955/http://www.clarotesting.com/page11.htm|date=2019-09-15}}, accessed January 9, 2013.</ref>

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.<ref name="VPM">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.</ref><ref name="INCOSE">International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref>{{Kilde www|url=http://www.gmu.edu/departments/seor/insert/robot/robot2.html|tittel=The SE VEE|besøksdato=26. mai 2007|arkiv-url=https://web.archive.org/web/20071018220159/http://www.gmu.edu/departments/seor/insert/robot/robot2.html|arkivdato=18. oktober 2007|forlag=SEOR, George Mason University}}</ref><ref name="Original"/> 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. [[Romfart|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 [[Prosjektstyring|prosjektstyringsmetoden]] til tyske myndigheter. Den tilsvarer omtrent [[PRINCE2]], men mer direkte relevant for [[programvareutvikling]].<ref>[https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html "V-Modell site (in German)"] {{Wayback|url=https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html |date=20220808154653 }}, accessed July 10, 2020.</ref> 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.<ref>German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992</ref><ref>{{Kilde www|url=http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12|tittel=Fundamentals of the V-Modell|besøksdato=14. april 2016|arkiv-dato=2016-03-08|arkiv-url=https://web.archive.org/web/20160308053740/http://v-modell.iabg.de/v-modell-xt-html-english/349ffba5c5cda0.html#toc12|url-status=yes}}</ref><ref>{{Kilde www|url=http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.1-eng/Dokumentation/pdf/V-Modell-XT-eng-Teil1.pdf|tittel=V-Modell XT, Part 1: Fundamentals of the V-Modell|besøksdato=14. april 2016}}</ref>

=== 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.<ref>[http://www.istqb.org/downloads/viewdownload/16/15.html "International Software Testing Qualifications Board – Foundation Level Syllabus"] {{Wayback|url=http://www.istqb.org/downloads/viewdownload/16/15.html |date=20170806121121 }}, accessed January 9, 2013.</ref> Det finnes ingen enkel definisjon av denne modellen, men flere ulike varianter som følger lignende prinsipper (se egen artikkel om [[V-Modell (programvareutvikling)|V-modell (programvareutvikling)]].

=== Offentlig amerikansk standard ===
I USA har myndighetene laget en V-modell som er omtrent like gammel som sin tyske motpart. [[Omfang|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.<ref>{{Kilde www|url=http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf|tittel=Systems Engineering for Intelligent Transportation Systems|besøksdato=9. juni 2007|forlag=US Dept. of Transportation}}</ref><ref>[http://www.fhwa.dot.gov/cadiv/segb/index.htm "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS"], accessed January 9, 2013.</ref><ref name="VPM">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.</ref><ref name="INCOSE">International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref>{{Kilde www|url=http://www.dau.mil/pubscats/PubsCats/AR%20Journal/arj53/Redshaw53.pdf|tittel=BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION|besøksdato=14. april 2016|arkiv-dato=2016-11-23|arkiv-url=https://web.archive.org/web/20161123010345/http://www.dau.mil/pubscats/PubsCats/AR%20Journal/arj53/Redshaw53.pdf|url-status=yes}}</ref><ref>{{Kilde www|url=https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html|tittel=Using V Models for Testing|besøksdato=14. april 2016}}</ref> 

== 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 [[Institute of Electrical and Electronics Engineers|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):<ref name="pmboked4">{{Kilde bok|url=https://ieeexplore.ieee.org/document/5937011|tittel=IEEE Guide--Adoption of the Project Management Institute (PMI) Standard A Guide to the Project Management Body of Knowledge (PMBOK Guide)--Fourth Edition|etternavn=IEEE|forfatter-lenke=IEEE|dato=juni 2011|verk=IEEE P1490/D1, May 2011|besøksdato=25. mai 2021|isbn=978-0-7381-6817-3|side=452|doi=10.1109/IEEESTD.2011.6086685}}</ref>

* "'''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 ==
[[Fil:Systems_Engineering_and_Verification.jpg|miniatyr|320x320pk|Systemutvikling og verifisering.<ref>Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.</ref>]]

=== 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.<ref name="FHWA 05"/> 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 [[Akseptansetest (programvare)|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.<ref name="FHWA 05"/><ref name="VPM">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.</ref><ref name="INCOSE">International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref name="Original"/>

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.<ref name="FHWA 05"/><ref name="VPM">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.</ref>

=== De to strømmene ===
==== Spesifikasjonsstrøm ====
Spesifikasjonsstrømmen består hovedsakelig av:
* Spesifikasjoner av brukerkrav
* [[Funksjonelle krav|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 ==
[[File:VPM3e_Vee_with_detail.gif|miniatyr|320x320pk|Off-Core alternativer (illustrerer oppover og nedover iterasjoner og tid og Modenhet dimensjon). Kilde: K. Forsberg og H. Mooz 2004<ref name="VPM">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.</ref><ref name="Original">Forsberg, K. and Mooz, H., [http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf "The Relationship of Systems Engineering to the Project Cycle"] {{Webarchive|url=https://web.archive.org/web/20090227123750/http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf|date=2009-02-27}}, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991</ref>]]
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 Company|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)<ref name="scribd">{{Kilde www|url=https://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications|tittel=Sequential Thematic Organization of Publications (STOP)|besøksdato=24. desember 2015|arkiv-url=https://web.archive.org/web/20080203133138/http://www.scribd.com/doc/2019286/Sequential-Thematic-Organization-of-Publications|arkivdato=3. februar 2008}}</ref> laget av Hughes i 1963 som ble brukt inntil Hughes ble delt opp og solgt av Howard Hughes Medical Institute i 1985.<ref>{{Kilde bok|tittel=Sustainable Development Possible with Creative System Engineering|etternavn=Sobkiw|fornavn=Walter|dato=2008-01-01|isbn=978-0615216300}}</ref>
* 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.<ref name="GermanOriginal">{{Kilde www|url=http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|tittel=V-Model Lifecycle Process Model|besøksdato=24. desember 2015|arkiv-url=https://web.archive.org/web/20160303204644/http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc|arkivdato=3. mars 2016|forlag=v-modell.iabg.de}}</ref>
* Den amerikanske V-modellen er dokumentert fra referater i 1991 fra National Council of Systems Engineering (NCOSE, senere INCOSE fra 1995),<ref name="Original">Forsberg, K. and Mooz, H., [http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf "The Relationship of Systems Engineering to the Project Cycle"] {{Webarchive|url=https://web.archive.org/web/20090227123750/http://www.csm.com/repository/model/rep/o/pdf/Relationship%20of%20SE%20to%20Proj%20Cycle.pdf|date=2009-02-27}}, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991</ref> og ble utviklet for satellittsystemer som involverer maskinvare, programvare og menneskelig interaksjon.
* Det amerikanske forsvarsdepartementet behandler [[Systemteknikk|systemstekniske]] prosessinteraksjoner etter en V-modell.<ref>{{Kilde www|url=http://www.dau.mil/pubscats/PubsCats/atl/2006_03_04/mar-apr06.pdf|tittel=A New Systems Engineering Model and an Old, Familiar Friend; Figure 2 V-9 Process Interactions|besøksdato=7. april 2016|forlag=Defense AT&L|arkiv-dato=2016-11-22|arkiv-url=https://web.archive.org/web/20161122235900/http://www.dau.mil/pubscats/PubsCats/atl/2006_03_04/mar-apr06.pdf|url-status=yes}}</ref>

V-modellen har fått utbredt anvendelse i kommersielle så vel som forsvarsprogrammer. Den primære bruken er i prosjektledelse<ref name="VPM">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.</ref><ref name="INCOSE">International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref> 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.<ref name="VPM">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.</ref><ref name="INCOSE">International Council On Systems Engineering (INCOSE), ''Systems Engineering Handbook Version 3.1,'' August 2007, pages 3.3 to 3.8</ref><ref name="Original"/> 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.<ref name="VPM" />

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.{{Utdyp}}

== 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.<ref name="VModelChange">{{Kilde www|url=http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|tittel=Further Development of the V-Modell (broken link)|besøksdato=24. desember 2015|arkiv-url=https://web.archive.org/web/20110423005924/http://v-modell.iabg.de/v-modell-xt-html-english/db09fe25265517.html#toc34|arkivdato=23. april 2011|forlag=v-modell.iabg.de}}</ref>
* 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.<ref name="VModelActivities">{{Kilde www|url=http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|tittel=Overview of the Activity Model of the V-Modell (broken link)|besøksdato=24. desember 2015|arkiv-url=https://web.archive.org/web/20110719043340/http://v-modell.iabg.de/v-modell-xt-html-english/dbe1fba6c7da92.html#toc797|arkivdato=19. juli 2011|forlag=v-modell.iabg.de}}</ref>

== Begrensninger ==
Følgende aspekter dekkes ikke av V-modellen, og må enten reguleres utenom, eller krever at V-modellen må tilpasses:<ref name="VModelLimits1">{{Kilde www|url=http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|tittel=Limits of the VModel|besøksdato=24. desember 2015|arkiv-url=https://web.archive.org/web/20110521043950/http://v-modell.iabg.de/v-modell-xt-html-english/446bfd42664fda.html#toc9|arkivdato=21. mai 2011|forlag=v-modell.iabg.de}}</ref><ref name="VModelLimits2">Christian Bucanac, [http://www.bucanac.com/documents/The_V-Model.pdf The V-Model] {{Wayback|url=http://www.bucanac.com/documents/The_V-Model.pdf |date=20120222231728 }}</ref>

* 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 ==
<references/>
{{Autoritetsdata}}

[[Kategori:Systemteknikk]]