Bij Post en Dekker maken wij bij onze engineering processen veelal gebruik van het V-model. Deze projectaanpak biedt ons de gewenste structuur en resulteert in een efficiënte en effectieve werkwijze. En bovendien levert het de beste resultaten, juist doordat de aanpak uitgaat van een evenredige aandachtsverdeling tussen projectdefinitie (en vertaling naar technisch ontwerp) en validatie/verificatie van die gedefinieerde projecteisen en behoeften.

In dit artikel leg ik één en ander uit over het V-model en beschrijf ik waarom dit model zo goed voor ons werkt.
Het V-model gaat uit van een lineair traject. Gedurende het ontwerptraject wordt net zoveel aandacht besteed aan de fasen die behoren tot de projectdefinitie als de fasen die vallen onder de fasen van testen, verificatie en validatie.

V-model, het grote broertje van het watervalmodel

Het V-model is, zeker voor de ontwerpprocessen van Post en Dekker, een verbeterde versie van het zogenaamde watervalmodel.

Een korte uitleg over het watervalmodel: 

Echter kent het model wat nadelen, een paar van deze nadelen opgesomd:

• Externe factoren kunnen roet in het eten gooien. Denk alleen al aan veranderende eisen vanuit de opdrachtgever, iets wat bij een engineeringsproject niet ondenkbaar is. Het project stokt dan even in een fase alvorens weer vooruitgang kan worden geboekt;
• Door de ‘1 fase per keer’-aanpak is het lastig om de doorlooptijd en kosten goed te beramen;
• Het model houdt geen rekening met diversiteit in visie ten aanzien van het traject van de verschillende engineers die aan het project werken.
• Het wachten op het werk van de ander leidt tot inefficiënte indeling van werkprocessen;
• Testen gebeurt pas laat in het traject. 

Als verbetering op de waterval methode werden het Royce-model (het werd mogelijk om terug te gaan naar een vorige fase), het Sashimi-model (fasen kunnen elkaar overlappen) en het Aorta lifecycle-model (na iedere fase wordt terugkoppeling aan de klant gegeven) ontwikkeld. 

Echter, het meest ideaal voor het ontwerpen van modulaire productfamilies is het V-model, juist omdat de definitiezijde per fase is te valideren, mits de specificaties en eisen SMART (specifiek, meetbaar, acceptabel, realistisch, tijdgebonden) geformuleerd zijn.

Het V-model uitgelegd

Bij het V-model wordt de linkerzijde van de V gebruikt voor de fasen die behoren tot de projectdefinitie. Aan de rechterzijde van de V worden de fasen van de projectdefinitie wederom in fasen getest en gevalideerd. Iedere fase aan de linker is met een fase aan de rechterkant te toetsen. Zo wordt stapsgewijs de user specificaties gevalideerd.

In de fasen zit een gelaagdheid en er geldt dat hoe dieper in het ontwikkeltraject hoe specifieker de fasen worden. Als we het V-model voor Post en Dekker schetsen zien we onderstaand model:

Projectdefinitie
1. Eisen in kaart
2. Gebruikersspecificatie
3. Technische specificatie
4. Module specificatie
5. Technisch ontwerp / geometrische opzet

Test & validatie
1. Module test
2. Acceptatietest
3. Gebruik en beheer 

Een valkuil bij de inzet van het V-model is dat er aan de linkerzijde teveel en/of niet voldoende SMART wordt gedefinieerd. Want als dat het geval is wordt valideren lastig of zelfs onmogelijk. En regel is, alles wat aan de linkerzijde wordt gedefinieerd, heeft zin als het rechts te valideren is.

Het valideren van de eisen en het ontwerp kan op diverse manieren geschieden, uiteraard afhankelijk van de fase en hetgeen dat getest moet worden. Dit kan digitaal gebeuren, aan de hand van een sterkteberekening, een duurtest, veiligheidstesten, inzet van een gebruikerspanel, et cetera.

Wilt u meer weten over de werkwijze van Post en Dekker, download dan onderstaande whitepaper.