V-modell
V-modellen (eller VEE-modellen) är en utvecklingsmodell för informationssystem (IS) som syftar till att förenkla förståelsen av komplexiteten i samband med systemutveckling. Den används för att definiera en enhetlig procedur för utveckling av mjukvaruprodukter , hårdvara och människa-maskin-gränssnitt .
Översikt
Historik
Konceptet med V-modellen utvecklades av Tyskland och USA i slutet av 1980-talet oberoende av varandra:
- Den tyska V-modellen utvecklades av flygföretaget IABG i Ottobrunn nära München i samarbete med Federal Armaments Procurement Department i Koblenz , för det tyska försvarsministeriet. Modellen antogs av den tyska federala administrationen för civilt bruk sommaren 1992 [1] .
- Den amerikanska V-modellen (VEE) utvecklades av National Council for Systems Engineering (internationellt - sedan 1995) för satellitsystem, inklusive hårdvara, mjukvara och användarinteraktion [2] .
Den nuvarande versionen av V-Model är V-Model XT, som godkändes i februari 2005 . V-modellen används för att hantera mjukvaruutvecklingsprocessen för den tyska federala administrationen. Det är nu standarden för tyska regerings- och försvarsprojekt, såväl som för programvarutillverkare i Tyskland. V-modellen är mer en uppsättning projektstandarder för att utveckla nya produkter. Denna modell liknar på många sätt PRINCE2 och beskriver metoder för både projektledning och systemutveckling.
Grundläggande principer
Grundprincipen för den V-formade modellen är att detaljen i projektet ökar när du rör dig från vänster till höger, samtidigt med tiden, och ingen av dem kan vända tillbaka. Iterationer i projektet görs horisontellt, mellan vänster och höger sida av bokstaven.
Vid utveckling av informationssystem är V-modellen en variant av vattenfallsmodellen , där utvecklingsuppgifter går uppifrån och ner på vänster sida om bokstaven V, och testuppgifter går upp till höger om bokstaven V. Horisontella linjer är ritade inuti V som visar hur resultaten av varje fasutveckling påverkar utvecklingen av testsystemet i var och en av testfaserna. Modellen bygger på att acceptanstestning i första hand baseras på krav, systemtestning baseras på krav och arkitektur, komplex testning baseras på krav, arkitektur och gränssnitt och komponenttestning baseras på krav, arkitektur, gränssnitt och algoritmer [ 4].] .
Mål
V-modellen ger stöd vid projektplanering och genomförande. Följande uppgifter ställs in under projektet:
- Riskminimering: Den V-formade modellen gör projektet mer transparent och förbättrar kvaliteten på projektkontrollen genom att standardisera delmål och beskriva motsvarande resultat och ansvariga personer. Detta gör att du kan identifiera avvikelser i projektet och risker i ett tidigt skede och förbättrar kvaliteten på projektledningen, vilket minskar riskerna.
- Kvalitetsförbättring och -säkring: V-modellen är en standardiserad utvecklingsmodell som ger önskade kvalitetsresultat från ett projekt. Mellanresultat kan kontrolleras i ett tidigt skede. Universell dokumentation underlättar läsbarhet, förståelighet och verifierbarhet.
- Minska den totala kostnaden för projektet: Resurser för utveckling, produktion, förvaltning och support kan förkalkyleras och kontrolleras. De erhållna resultaten är också universella och lätta att förutsäga. Detta minskar kostnaderna för efterföljande etapper och projekt.
- Förbättra kvaliteten på kommunikationen mellan projektdeltagare: En universell beskrivning av alla element och villkor underlättar ömsesidig förståelse för alla projektdeltagare. Därmed minskar felaktigheter i förståelsen mellan användaren, köparen, leverantören och utvecklaren [5] .
Fördelar
- V-Model användare deltar i utvecklingen och underhållet av V-Model. Förändringskontrollkommittén underhåller projektet och träffas en gång om året för att behandla alla inkomna förfrågningar om att göra ändringar i V-modellen [6] .
- I början av ett projekt kan den V-formade modellen anpassas till detta projekt, eftersom denna modell inte är beroende av typen av organisationer och projekt [7] .
- V-modellen låter dig dela upp aktiviteten i separata steg, som var och en kommer att innehålla nödvändiga åtgärder för den, instruktioner för dem, rekommendationer och en detaljerad förklaring av aktiviteten [8] .
Begränsningar
Följande punkter beaktas inte i V-modellen, utan kan övervägas separat, eller så är det möjligt att anpassa modellen för dem:
- Placeringen av tjänstekontrakt är inte reglerad.
- Organisation och utförande av förvaltning, underhåll, reparation och kassering av systemet beaktas inte i V-modellen. Planering och förberedelser för dessa operationer beaktas dock av modellen.
- Den V-formade modellen handlar mer om mjukvaruutveckling i ett projekt än om hela organisationen av processen [9] .
Kritik
Fördelar
- Modellen betonar planering som syftar till att verifiera och validera produkten som utvecklas i ett tidigt skede av dess utveckling. Enhetstestfasen validerar den detaljerade designen. Integrations- och testfaserna implementerar den arkitektoniska designen eller designen på toppnivå. Systemtestfasen bekräftar att kravfasen för produkten och dess specifikation har genomförts korrekt [10] .
- Modellen tillhandahåller certifiering och verifiering av alla externa och interna data som tas emot, och inte bara själva mjukvaruprodukten [10] [11] [12] .
- I den V-formade modellen definieras krav innan systemdesign utvecklas, och mjukvarudesign utförs innan komponenter utvecklas [10] .
- Modellen definierar de produkter som ska produceras som ett resultat av utvecklingsprocessen, och varje resulterande data måste testas [10] [12] .
- Tack vare modellen kan projektledare spåra utvecklingsprocessens framsteg, eftersom det i det här fallet är fullt möjligt att använda en tidslinje, och slutförandet av varje fas är en milstolpe [10] [12] .
Nackdelar
- Modellen ger inte utrymme för arbete med parallella händelser [10] .
- Modellen ger inte utrymme för införandet av kravet på dynamiska förändringar i olika skeden av livscykeln [10] [11] [13] .
- Testning av krav i livscykeln sker för sent, vilket gör det omöjligt att göra ändringar utan att påverka projektplanen [10] [11] .
- Modellen omfattar inte åtgärder som syftar till riskanalys [10] .
- Vissa resultat kan bara ses när botten av bokstaven V nås [14] .
Se även
Anteckningar
- ↑ V-Model - Livscykelprocessmodell Arkiverad 3 mars 2016. (Engelsk)
- ↑ Forsberg, K. och Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" , Första årliga symposium för National Council on Systems Engineering, oktober 1991
- ↑ Clarus Concept of Operations. Arkiverad 12 september 2014 på Wayback Machine Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
- ↑ Economicus: en serie ordböcker inom ekonomi, finans och förvaltning (otillgänglig länk)
- ↑ Mål för V-modellen arkiverad 20 april 2011. (Engelsk)
- ↑ Ytterligare utveckling av V-modellen arkiverad 23 april 2011. (Engelsk)
- ↑ Management Mechanisms of the V-Model - Tailoring Arkiverad 19 juli 2011. (Engelsk)
- ↑ Översikt över V-modellens aktivitetsmodell arkiverad 19 juli 2011. (Engelsk)
- ↑ Gränser för V-modellen Arkiverad 21 maj 2011. (Engelsk)
- ↑ 1 2 3 4 5 6 7 8 9 En översikt över livscykelmodeller för mjukvaruutveckling . Hämtad 5 juni 2011. Arkiverad från originalet 15 juni 2016. (obestämd)
- ↑ 1 2 3 Testing Excellence - V-Model Arkiverad 25 juni 2011 på Wayback Machine
- ↑ 1 2 3 Sameeradilhan - Fördelar och nackdelar med Waterfall Model och V-Model Arkiverad 29 augusti 2012 på Wayback Machine
- ↑ TestManagement - Fördelar och nackdelar med V-Model Arkiverad 20 juni 2015 på Wayback Machine
- ↑ V-Model Arkiverad 20 juni 2015 på Wayback Machine : Expert Program Management
Länkar