Det finns många anledningar att tycka om V-modellen, men det finns även en hel del kritik mot modellen. Argument som att den bygger på vattenfallsutveckling, att den inte är flexibel och inte möter den föränderliga naturen inom systemutvecklingsprojekten.
För mig är V-modellen en av de konceptuella visualiseringar som burit mest frukt för att tydliggöra hur man validerar och säkerställer kundacceptansen, vilket i sig är kvittot på ett lyckat projekt.
Det första steget i populära projektmodeller är ju att få ett direktiv kring vad som avses åstadkommas. Överst i V-modellen så är fokus på just hur vi projektledare kan säkerställa acceptans av projektleveransen. Genom att visualisera en linje över V symboliken så visar man på hur det kommer att valideras (”Uppfyller leveransen behovet”, “Är det rätt system?”) och på så sätt får man en överenskommelse kring vad som är förutsättningen för att lyckas. En riktigt bra start skulle jag säga.
V-modellen är inte detsamma som Vattenfallsmetoden, men har sitt ursprung i samma trakter med en sekventiell exekvering av processer där föregångaren skall vara färdig före nästa steg kan påbörjas. Det finns en mängd olika varianter på V-modellen som bygger på olika nivåer, det finns även adaptioner som är ämnade för iterativa agila utvecklingsprojekt. Modellen får dock hård kritik där det blåser agila vindar, kanske mycket på grund av de nära relationerna med Vattenfallsmetoden.
Oavsett vilken metodik man utvecklar i så är det alltid bra att ha en överenskommelse kring hur det skall valideras och testas före det man påbörjar. Detsamma gäller även inom testdriven utveckling där man vänder lite på modellen och skriver testen inan man skriver koden, vilket fokuserar utvecklingsarbetet på kvalitet och testbarhet.
Hur säkerställer man då förvaltningsbarheten… vi har inte några magiska kristallkulor att titta in i och se vad som kan behöva göras i framtiden… men genom att säkerställa testbarheten på flera nivåer enligt V-modellen så får man i någon form ett kvitto (”Rätt byggd, “Är systemet rätt gjort?”) på att det går att vidareutveckla. Bygger man vidare på koden och inte bryter tidigare tester så kan man göra regressionstester vilket ger framtida utvecklare en bra ingång att bygga vidare och kortar ofta ner tiden för vidareutvecklingsarbete.
Det finns ingen ”rätt” modell för systemutveckling, så oavsett vilken metodik, modell eller process man har för utvecklingsarbete så är det bra att vara i konsensus, det är just där jag ser styrkan i V-modellen, som en modell för konsensus. Ett råd är att ta godbitarna i V-modellen och anpassa den efter den verklighet där den skall verka.