V-model: verificatie en validatie
Lucid Content
Leestijd: ongeveer 7 min
Onderwerpen:
In de afgelopen decennia zijn er veel verschillende methodologieën voor softwareontwikkeling gebruikt. Over het algemeen vallen deze in een van deze twee categorieën: zwaargewicht of lichtgewicht.
Zwaargewicht (voorspellende) methodologieën zoals het Waterval model, Spiraal model en V-model zijn gebaseerd op een lineaire, sequentiële, stapsgewijze benadering van softwareontwikkeling. Ze worden meestal gebruikt voor langere ontwikkelingscycli, die meerdere maanden of zelfs een jaar kunnen duren.
Lichtgewicht (agile) methodologieën, zoals Scrum, Lean en XP zijn flexibel en worden gebruikt in korte ontwikkelingscycli (iteraties) die twee tot vier weken duren. Zo kunnen je teams snel reageren op de snel veranderende eisen van je klanten.
Zwaargewicht modellen zijn nauwelijks meer in de mode en zijn vervangen door lichte methodologieën, maar dat wil niet zeggen dat niemand de zwaargewicht methodes meer gebruikt. Als je nieuwe software ontwikkelt, is het ontwikkelingsmodel dat je kiest de sleutel tot je succes. En er is niet een specifieke methode die altijd en voor iedereen werkt.
In dit artikel bespreken we een zwaargewicht model dat bekend staat als het V-model. We leggen uit wat het V-model is en hoe het je van dienst zou kunnen zijn in dit tijdperk van lichtgewicht ontwikkeling.
Wat is het V-model?
Deze softwareontwikkelmethode is een variant op het klassieke Watervalmodel. Het verschil is dat bij Waterval iedere ontwikkelingsfase overgaat in de volgende in een eenvoudig lineair proces. Bij het V-model loopt er een testfase parallel aan iedere ontwikkelingsfase. Iedere parallelle ontwikkelings- en testfase moet worden voltooid voordat de volgende fase begint.
Dit model is genoemd naar zijn primaire focus op verificatie en validatie. En wanneer je deze parallelle ontwikkelings- en testfases grafisch weergeeft, lijkt het resulterende diagram op de vorm van de letter V.
Wat is het verschil tussen verificatie en validatie?
Sommige mensen raken verward en denken dat verificatie en validatie synoniemen zijn. Dus laten we naar de verschillen kijken.
Verificatie is het proces waarmee wordt verzekerd dat er aan de projecteisen wordt voldaan. Dit behelst de verificatie van documentatie, ontwerp en code op een bepaald moment tijdens de ontwikkeling van het project. Je zorgt dat het project op de juiste manier wordt ontwikkeld.
Als je bijvoorbeeld een speadsheet app ontwikkelt, moet je tijdens het proces verifiëren dat de fundamentele wiskundige berekeningen kloppen voordat je verdergaat met complexere code en formules. Dit soort testen vindt parallel aan de ontwikkeling van het product plaats.
Validatie is het proces waarmee wordt verzekerd dat je het juiste product ontwikkelt. Dit type test vindt plaats wanneer de ontwikkelingsfase is voltooid. Je test om je ervan te verzekeren dat het product voldoet aan de behoeften van de klant.
Hoe werkt het V-model?
Het V-model bestaat uit een serie lineaire fases die een voor een worden uitgevoerd totdat het project is voltooid. Aan de linkerkant van het V-model staan de verificatie fases van de ontwikkeling. De rechterkant toont de parallelle validatiefases. De verificatie- en validatiefases komen samen in de punt van de V-vorm.
In het hieronder beschreven V-model voor techniek staan verschillende verificatie- en validatie fases.
Vereisten
Tijdens de fase van de vereisten analyseren stakeholders en het team de behoeften van klanten en bepalen ze wat er in het functiepakket zal worden opgenomen. Neem ruim de tijd voor een grondige analyse, zodat je niets mist dat belangrijk is voor je klanten. Maak ook gedetailleerde documentatie, zodat alle betrokkenen de vereisten begrijpen. Tegelijkertijd worden de acceptatietesten gepland en ontworpen.
Systeemontwerp
Bepaal aan de hand van de documenten met vereisten en feedback van klanten en stakeholders welke methoden of technieken je zou kunnen gebruiken om de vereisten te implementeren. Stel een specificatiedocument op met de algemene systeemorganisatie, menustructuren, bedrijfslogica, gegevenslagen enzovoort.
In deze fase worden de systeemtesten gepland en ontworpen op basis van de systeem ontwerp documenten.
Architectonisch ontwerp
In deze fase documenteer je specificaties waarin in detail wordt aangegeven hoe alle verschillende componenten in de software via interne of externe integraties met elkaar gekoppeld zullen zijn en op elkaar zullen reageren. Deze fase wordt ook wel high-level design (HLD) genoemd.
Op basis van de informatie die tijdens deze fase wordt gedocumenteerd, worden tegelijkertijd de integratietesten ontwikkeld.
Module ontwerp
Deze fase wordt ook wel low-level design voor je systeem genoemd. In deze fase bepaal je de details voor het interne ontwerp van het systeem. Je moet de details documenteren over hoe modellen, componenten, interfaces enzovoort worden geïmplementeerd en hoe ze samenwerken met andere modules in het systeem.
Tijdens deze fase moeten de unittesten worden gepland en gemaakt. Deze unittesten dienen ter verzekering dat de individuele componenten van de module correct functioneren.
Coderen
Hier komen we bij de punt van de V-vorm, waar de verificatie kant van het model is verbonden met de validatie kant. In deze fase werken je ontwikkelaars aan de codering aan de hand van de richtlijnen en normen die in de ontwerpdocumenten staan beschreven. Met behulp van de ontwerp- en specificatiedocumenten schrijft je team code en creëert een functionerend systeem. Voor de definitieve versie wordt eerst de code gecontroleerd en geoptimaliseerd. De testfases beginnen nadat de definitieve versie is ingediend.
Unittesten
De validatiefases van het V-model beginnen met unittesten. De unittesten moeten zijn gepland en ontworpen tijdens de module ontwerp fase. Met deze testen wordt de code in individuele onderdelen van de module gecontroleerd. Unit testen helpt je om bugs en andere mogelijke problemen op te sporen en op te lossen.
Omdat unit testen een extreem precies proces is, neemt deze fase waarschijnlijk meer tijd in beslag dan de andere validatie fases. Maar deze fase is heel belangrijk omdat die je helpt het overgrote deel van potentiële bugs en problemen te elimineren, zodat de volgende testfases soepeler en sneller zullen verlopen.
Integratie testen
De testplannen voor deze fase moeten zijn gemaakt tijdens de fase voor architectonisch ontwerp. De testen worden gebruikt om te zien hoe goed je software werkt en communiceert met zowel interne als externe componenten in het systeem.
Systeem testen
De systeem testen worden gemaakt tijdens de systeemontwerp fase. Deze testen concentreren zich vooral op de algemene prestaties, om te zorgen dat de nieuwe software goed werkt en communiceert binnen het systeem. Systeemtesten kunnen je helpen compatibiliteitsproblemen tussen software en hardware te vinden.
Acceptatietesten
De acceptatietest vormt de laatste testfase. Acceptatietesten vinden plaats in een gebruikersomgeving. Het doel is om te controleren of de nieuwe software compatibel is met andere systemen in de gebruikersomgeving of goed zal functioneren in een live omgeving.
Waarom gebruik je een V-model?
Nu de meeste bedrijven in een agile omgeving werken, kun je je afvragen waarom je een V-model zou gebruiken dat is afgeleid van de Watervalmethode. Als de wereldwijde pandemie ons een ding heeft geleerd, is het dat bedrijven flexibel moeten zijn om te kunnen slagen. Flexibiliteit betekent niet alleen dat je je medewerkers thuis, op kantoor of in een hybride model laat werken. Het betekent ook dat veel organisaties een verschuiving hebben doorgemaakt in hoe ze hun projecten plannen en uitvoeren.
Het Project Management Institute (PMI) noemt deze bedrijven gymnastische bedrijven. Een gymnastisch bedrijf richt zich meer op uitkomsten en resultaten. Dat betekent dat deze bedrijven meer openstaan voor verschillende processen die hen kunnen helpen de gewenste uitkomst te bereiken. Dus op basis van het soort project, de complexiteit en de medewerkers distributie kan een gymnastisch bedrijf soms beslissen dat het zinvol is een project te ontwikkelen aan de hand van een zwaargewicht methode zoals het V-model.
En je kunt een V-model overwegen vanwege de volgende voordelen:
- Het is relatief eenvoudig te begrijpen en te implementeren. Doordat iedere fase voltooid wordt voordat de volgende begint, is het makkelijk om op koers te blijven en doelen te behalen.
- Het is eenvoudig te managen. De lineaire aard van het model laat je weten waar je was, waar je bent en waar je naartoe moet.
- Het V-model is lineair, rigide en beperkend. Dat klinkt misschien niet als een voordeel. Maar een lineaire, rigide aanpak werkt goed voor projecten met een strakke reikwijdte en tijdslijn.
- Het V-model is goed voor tijdmanagement. Dit model werkt heel goed bij projecten die een strakke deadline moeten handhaven en onderweg bepaalde mijlpalen moeten halen.
Klaar om het V-model toe te passen op je project management?
Over Lucidchart
Lucidchart, een slimme diagramapplicatie in de cloud, is een kernonderdeel van Lucid Software's pakket voor visuele samenwerking. Met deze intuïtieve cloudgebaseerde oplossing kunnen teams in realtime samenwerken om flowcharts, mockups, UML-diagrammen, kaarten van customer journeys en meer te maken. Lucidchart stuwt teams vooruit om sneller aan de toekomst te bouwen. Lucid is trots op zijn diensten aan belangrijke bedrijven over de hele wereld, waaronder klanten als Google, GE en NBC Universal, en 99% van de Fortune 500. Lucid werkt samen met brancheleiders, waaronder Google, Atlassian en Microsoft. Sinds de oprichting heeft Lucid talrijke onderscheidingen ontvangen voor zijn producten, bedrijfsvoering en werkcultuur. Ga voor meer informatie naar lucidchart.com.
Gerelateerde artikelen
Watervalmethode: voor- en nadelen
Waterfall project management bestaat uit zes afzonderlijke fasen die achtereenvolgens moeten worden doorlopen; de volgende fase begint pas als de huidige fase is voltooid. Ontdek de stappen en voordelen van deze methode en ga aan de slag met gratis Lucidchart sjablonen voor Waterfall projectmanagement.