Hopp til innhold

V-modellen

Fra Wikipedia, den frie encyklopedi
V-modellen er en systemteknisk prosess.[1]

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.[2]

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.[3][4][5][6] 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

[rediger | rediger kilde]

Det finnes tre hovedtyper V-modeller.

V-Modell

[rediger | rediger kilde]

"V-Modell" er den offisielle prosjektstyringsmetoden til tyske myndigheter. Den tilsvarer omtrent PRINCE2, men mer direkte relevant for programvareutvikling.[7] 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.[8][9][10]

Generell testmodell

[rediger | rediger kilde]

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.[11] 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

[rediger | rediger kilde]

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.[12][13][3][4][14][15]

Validering kontra verifisering

[rediger | rediger kilde]

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):[16]

  • "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

[rediger | rediger kilde]

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

[rediger | rediger kilde]
Systemutvikling og verifisering.[17]

Systemutvikling og verifisering

[rediger | rediger kilde]

Systemutviklingsprosessen gir en måte å forbedre kostnadseffektiviteten til komplekse systemer som systemeieren vil oppleve gjennom hele systemets levetid, fra unnfangelse til dekommisjonering.[1] 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.[1][3][4][6]

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.[1][3]

De to strømmene

[rediger | rediger kilde]

Spesifikasjonsstrøm

[rediger | rediger kilde]

Spesifikasjonsstrømmen består hovedsakelig av:

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

[rediger | rediger kilde]
Fil:VPM3e Vee with detail.gif
Off-Core alternativer (illustrerer oppover og nedover iterasjoner og tid og Modenhet dimensjon). Kilde: K. Forsberg og H. Mooz 2004[3][6]

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)[18] laget av Hughes i 1963 som ble brukt inntil Hughes ble delt opp og solgt av Howard Hughes Medical Institute i 1985.[19]
  • 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.[20]
  • Den amerikanske V-modellen er dokumentert fra referater i 1991 fra National Council of Systems Engineering (NCOSE, senere INCOSE fra 1995),[6] og ble utviklet for satellittsystemer som involverer maskinvare, programvare og menneskelig interaksjon.
  • Det amerikanske forsvarsdepartementet behandler systemstekniske prosessinteraksjoner etter en V-modell.[21]

V-modellen har fått utbredt anvendelse i kommersielle så vel som forsvarsprogrammer. Den primære bruken er i prosjektledelse[3][4] 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.[3][4][6] 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.[3]

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.[bør utdypes]

Fordeler

[rediger | rediger kilde]

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.[22]
  • 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.[23]

Begrensninger

[rediger | rediger kilde]

Følgende aspekter dekkes ikke av V-modellen, og må enten reguleres utenom, eller krever at V-modellen må tilpasses:[24][25]

  • 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å

[rediger | rediger kilde]

Referanser

[rediger | rediger kilde]
  1. ^ a b c d Clarus Concept of Operations Arkivert 2009-07-05 hos Wayback Machine, Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.
  2. ^ "The Dangerous & Seductive V Model" Arkivert 27. juni 2017 hos Wayback Machine. Arkivert 2019-09-15 hos Wayback Machine, accessed January 9, 2013.
  3. ^ a b c d e f g h 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.
  4. ^ a b c d e International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8
  5. ^ «The SE VEE». SEOR, George Mason University. Arkivert fra originalen 18. oktober 2007. Besøkt 26. mai 2007. 
  6. ^ a b c d e Forsberg, K. and Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" Arkivert 2009-02-27 hos Wayback Machine, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991
  7. ^ "V-Modell site (in German)" Arkivert 8. august 2022 hos Wayback Machine., accessed July 10, 2020.
  8. ^ German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992
  9. ^ «Fundamentals of the V-Modell». Arkivert fra originalen 8. mars 2016. Besøkt 14. april 2016. 
  10. ^ «V-Modell XT, Part 1: Fundamentals of the V-Modell» (PDF). Besøkt 14. april 2016. 
  11. ^ "International Software Testing Qualifications Board – Foundation Level Syllabus" Arkivert 6. august 2017 hos Wayback Machine., accessed January 9, 2013.
  12. ^ «Systems Engineering for Intelligent Transportation Systems» (PDF). US Dept. of Transportation. Besøkt 9. juni 2007. 
  13. ^ "US Dept of Transportation, Federal Highway Administration. Systems Engineering Guidebook for ITS", accessed January 9, 2013.
  14. ^ «BUILDING ON A LEGACY: RENEWED FOCUS ON SYSTEMS ENGINEERING IN DEFENSE ACQUISITION» (PDF). Arkivert fra originalen (PDF) 23. november 2016. Besøkt 14. april 2016. 
  15. ^ «Using V Models for Testing». Besøkt 14. april 2016. 
  16. ^ IEEE (juni 2011). IEEE Guide--Adoption of the Project Management Institute (PMI) Standard A Guide to the Project Management Body of Knowledge (PMBOK Guide)--Fourth Edition. IEEE P1490/D1, May 2011. s. 452. ISBN 978-0-7381-6817-3. doi:10.1109/IEEESTD.2011.6086685. Besøkt 25. mai 2021. 
  17. ^ Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.
  18. ^ «Sequential Thematic Organization of Publications (STOP)». Arkivert fra originalen 3. februar 2008. Besøkt 24. desember 2015. 
  19. ^ Sobkiw, Walter (1. januar 2008). Sustainable Development Possible with Creative System Engineering. ISBN 978-0615216300. 
  20. ^ «V-Model Lifecycle Process Model». v-modell.iabg.de. Arkivert fra originalen 3. mars 2016. Besøkt 24. desember 2015. 
  21. ^ «A New Systems Engineering Model and an Old, Familiar Friend; Figure 2 V-9 Process Interactions» (PDF). Defense AT&L. Arkivert fra originalen (PDF) 22. november 2016. Besøkt 7. april 2016. 
  22. ^ «Further Development of the V-Modell (broken link)». v-modell.iabg.de. Arkivert fra originalen 23. april 2011. Besøkt 24. desember 2015. 
  23. ^ «Overview of the Activity Model of the V-Modell (broken link)». v-modell.iabg.de. Arkivert fra originalen 19. juli 2011. Besøkt 24. desember 2015. 
  24. ^ «Limits of the VModel». v-modell.iabg.de. Arkivert fra originalen 21. mai 2011. Besøkt 24. desember 2015. 
  25. ^ Christian Bucanac, The V-Model Arkivert 22. februar 2012 hos Wayback Machine.
Autoritetsdata
Hentet fra «https://no.wikipedia.org/w/index.php?title=V-modellen&oldid=24375861»