Meest recente blogartikel

Het V-model als basis voor system development

Eric-Jan Dekker
door Eric-Jan Dekker op 13-04-18

V

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: 

Het watervalmodel deelt een ontwikkeltraject op in fasen en laat de ontwikkeling vloeiend naar het einddoel lopen. De fasen zijn vaak: definitie & analyse, basisontwerp, technisch ontwerp / detailontwerp, testen, integratie en beheer en onderhoud. Het model gaat ervan uit dat er niet wordt gestart met een fase vóórdat een eerdere fase volledig is afgerond.

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:

V-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.

Creating new business for OEM

Eric-Jan Dekker
Geschreven door Eric-Jan Dekker
Eric-Jan is medeoprichter van Post en Dekker en een System Developer in hart en nieren. Hij heeft een passie voor het ontwerpen van slimme, innovatieve productfamilies. Jarenlange ervaring en een flinke dosis lef resulteerden in tal van mooie cases voor OEM-ers in uiteenlopende markten. Benieuwd wat Post en Dekker voor uw organisatie kan betekenen? Eric-Jan legt het u graag uit!
(020-4680839 | Eric-Jan@postendekker.nl)

Gerelateerde artikelen

Post en Dekker werkt met partners aan VentilAid Pro

Het Coronavirus houdt Nederland en de rest van de wereld flink in zijn greep. Niet alleen zijn de effecten van de maatregelen...

Eric-Jan Dekker
Door Eric-Jan Dekker - 21 april 2020
Hoe we de acceptatie bij ontwikkelingen vergroten met VR

De toepassing van VR, oftewel virtual reality, is de afgelopen jaren flink toegenomen. Ook bij Post en Dekker maken wij hier...

Eric-Jan Dekker
Door Eric-Jan Dekker - 23 mei 2019
Onze toolbox: conceptontwikkeling – van niets naar iets

Vanuit de serie 'Onze toolbox' delen we ditmaal onze visie en werkwijze ten aanzien van conceptstudie en -ontwikkeling.

Binnen

Nicoline Marselis
Door Nicoline Marselis - 13 maart 2019