V model

V-modellen (eller VEE-modellen) er en udviklingsmodel for informationssystemer (IS), der sigter mod at forenkle forståelsen af ​​kompleksiteten forbundet med systemudvikling. Det bruges til at definere en samlet procedure for udvikling af softwareprodukter , hardware og menneske-maskine-grænseflader .

Oversigt

Historie

Konceptet med V-modellen blev udviklet af Tyskland og USA i slutningen af ​​1980'erne uafhængigt af hinanden:

• Den tyske V-model blev udviklet af luftfartsselskabet IABG i Ottobrunn nær München i samarbejde med Federal Armaments Procurement Department i Koblenz , for det tyske forsvarsministerium. Modellen blev vedtaget af den tyske føderale administration til civil brug i sommeren 1992 [1] .
• Den amerikanske V-Model (VEE) blev udviklet af National Council for Systems Engineering (internationalt - siden 1995) til satellitsystemer, herunder hardware, software og brugerinteraktion [2] .

Den nuværende version af V-Model er V-Model XT, som blev godkendt i februar 2005 . V-modellen bruges til at styre softwareudviklingsprocessen for den tyske føderale administration. Det er nu standarden for tyske regerings- og forsvarsprojekter såvel som for softwareproducenter i Tyskland. V-modellen er mere et sæt projektstandarder for udvikling af nye produkter. Denne model ligner på mange måder PRINCE2 og beskriver metoder til både projektledelse og systemudvikling.

Grundlæggende principper

Grundprincippet i den V-formede model er, at detaljerne i projektet øges, når du bevæger dig fra venstre mod højre, samtidig med tiden, og ingen af ​​dem kan vende tilbage. Gentagelser i projektet er lavet vandret, mellem venstre og højre side af bogstavet.

I informationssystemudvikling er V-modellen en variant af vandfaldsmodellen , hvor udviklingsopgaver går fra top til bund i venstre side af bogstavet V, og testopgaver går op i højre side af bogstavet V. Vandrette linjer er tegnet inde i V, der viser, hvordan resultaterne af hver af faseudviklingerne påvirker udviklingen af ​​testsystemet i hver af testfaserne. Modellen er baseret på, at accepttest primært er baseret på krav, systemtest er baseret på krav og arkitektur, kompleks test er baseret på krav, arkitektur og grænseflader, og komponenttest er baseret på krav, arkitektur, grænseflader og algoritmer [ 4].] .

Mål

V-modellen yder støtte i projektplanlægning og implementering. Følgende opgaver stilles i løbet af projektet:

• Risikominimering: Den V-formede model gør projektet mere gennemsigtigt og forbedrer kvaliteten af ​​projektstyringen ved at standardisere delmål og beskrive de tilsvarende resultater og ansvarlige personer. Dette giver dig mulighed for at identificere afvigelser i projektet og risici på et tidligt tidspunkt og forbedrer kvaliteten af ​​projektledelsen, hvilket reducerer risici.
• Kvalitetsforbedring og -sikring: V-modellen er en standardiseret udviklingsmodel, der leverer de ønskede kvalitetsresultater fra et projekt. Mellemresultater kan kontrolleres på et tidligt tidspunkt. Universel dokumentation letter læsbarhed, forståelighed og verificerbarhed.
• Reduktion af de samlede omkostninger ved projektet: Ressourcer til udvikling, produktion, ledelse og support kan forudberegnes og kontrolleres. De opnåede resultater er også universelle og lette at forudsige. Dette reducerer omkostningerne til efterfølgende etaper og projekter.
• Forbedring af kvaliteten af ​​kommunikationen mellem projektdeltagere: En universel beskrivelse af alle elementer og betingelser letter gensidig forståelse for alle projektdeltagere. Dermed reduceres unøjagtigheder i forståelsen mellem brugeren, køberen, leverandøren og udvikleren [5] .

Fordele

• V-Model brugere deltager i udvikling og vedligeholdelse af V-Model. Forandringskontroludvalget vedligeholder projektet og mødes en gang om året for at behandle alle indkomne anmodninger om at foretage ændringer i V-modellen [6] .
• Ved starten af ​​ethvert projekt kan den V-formede model tilpasses dette projekt, da denne model ikke afhænger af typen af ​​organisationer og projekter [7] .
• V-model giver dig mulighed for at opdele aktiviteten i separate trin, som hver vil omfatte de nødvendige handlinger for den, instruktioner til dem, anbefalinger og en detaljeret forklaring af aktiviteten [8] .

Begrænsninger

Følgende punkter er ikke taget i betragtning i V-modellen, men kan overvejes separat, eller det er muligt at tilpasse modellen til dem:

• Placering af servicekontrakter er ikke reguleret.
• Tilrettelæggelse og udførelse af styring, vedligeholdelse, reparation og bortskaffelse af systemet er ikke taget i betragtning i V-modellen. Planlægning og forberedelse af disse operationer er dog overvejet af modellen.
• Den V-formede model handler mere om softwareudvikling i et projekt end hele tilrettelæggelsen af ​​processen [9] .

Kritik

Fordele

• Modellen lægger vægt på planlægning rettet mod at verificere og validere det produkt, der udvikles på de tidlige stadier af dets udvikling. Enhedstestfasen validerer det detaljerede design. Integrations- og testfaserne implementerer det arkitektoniske design eller design på topniveau. Systemtestfasen bekræfter, at kravfasen for produktet og dets specifikation er blevet korrekt gennemført [10] .
• Modellen sørger for certificering og verifikation af alle eksterne og interne data, der modtages, og ikke kun selve softwareproduktet [10] [11] [12] .
• I den V-formede model er krav defineret før systemdesign udvikles, og softwaredesign udføres før komponenter udvikles [10] .
• Modellen definerer de produkter, der skal produceres som et resultat af udviklingsprocessen, og hver resulterende data skal testes [10] [12] .
• Takket være modellen kan projektledere spore udviklingsprocessens fremskridt, da det i dette tilfælde er ganske muligt at bruge en tidslinje, og afslutningen af ​​hver fase er en milepæl [10] [12] .

Ulemper

• Modellen giver ikke mulighed for arbejde med parallelle hændelser [10] .
• Modellen giver ikke mulighed for at indføre kravet om dynamiske ændringer på forskellige stadier af livscyklussen [10] [11] [13] .
• Test af krav i livscyklussen sker for sent, hvilket gør det umuligt at foretage ændringer uden at påvirke projektplanen [10] [11] .
• Modellen omfatter ikke handlinger rettet mod risikoanalyse [10] .
• Nogle resultater kan først ses, når bunden af ​​bogstavet V er nået [14] .

Se også

• vandfaldsmodel
• Dual Vee model
• kaos model

Noter

1. ↑ V-Model - Livscyklusprocesmodel Arkiveret 3. marts 2016.  (Engelsk)
2. ↑ Forsberg, K. og Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" , First Annual National Council on Systems Engineering Symposium, oktober 1991  
3. ↑ Clarus Concept of Operations. Arkiveret 12. september 2014 på Wayback Machine Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA),   2005
4. ↑ Economicus: en række ordbøger inden for økonomi, finans og ledelse  (utilgængeligt link)
5. ↑ Mål for V-modellen arkiveret 20. april 2011.  (Engelsk)
6. ↑ Yderligere udvikling af V-modellen arkiveret 23. april 2011.  (Engelsk)
7. ↑ Management Mechanisms of the V-Model - Tailoring Arkiveret 19. juli 2011.  (Engelsk)
8. ↑ Oversigt over aktivitetsmodellen for V-modellen arkiveret 19. juli 2011.  (Engelsk)
9. ↑ Grænser for V-modellen Arkiveret 21. maj 2011.  (Engelsk)
10. ↑ 1 2 3 4 5 6 7 8 9 En oversigt over livscyklusmodeller for softwareudvikling . Hentet 5. juni 2011. Arkiveret fra originalen 15. juni 2016. (ubestemt)
11. ↑ 1 2 3 Testing Excellence - V-Model Arkiveret 25. juni 2011 på Wayback Machine 
12. ↑ 1 2 3 Sameeradilhan - Fordele og ulemper ved Waterfall Model og V-Model Arkiveret 29. august 2012 på Wayback Machine 
13. ↑ TestManagement - Fordele og ulemper ved V-Model Arkiveret 20. juni 2015 på Wayback Machine 
14. ↑ V-Model Arkiveret 20. juni 2015 på Wayback Machine : Expert Program  Management

Links

• Detaljeret information om V-modellen (92/97/XT)  (tysk)
• Officiel dokumentation for V-modellen  (eng.)