V-model
Het V-model is een lineaire softwareontwikkelmethode en is ontworpen in 1986 door Paul E. Rook.[1] Het V-model is oorspronkelijk afgeleid van de watervalmethode.
Opzet methode
Het V-model besteedt in tegenstelling tot het watervalmodel evenwichtig aandacht aan ontwikkeling en verificatie. Het softwareontwerp inclusief de verificatie is opgedeeld in een aantal fasen die elk een aantal vooraf gedefinieerde producten opleveren. Wanneer de producten van een fase zijn opgeleverd, vormen deze de basis voor de volgende fase, er kan dus niet worden begonnen aan een nieuwe fase wanneer de producten van de vorige fase niet zijn opgeleverd (en goedgekeurd). Dit herhaalt zich voor alle fasen, en met elke nieuwe basis die wordt gevormd groeit het vertrouwen in het systeem.
Fasering
![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/a5/V-model.png/260px-V-model.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e8/Systems_Engineering_Process_II.svg/260px-Systems_Engineering_Process_II.svg.png)
De fasen en producten zijn weergegeven in een V-model (figuur 1). Voor elke specificatie- of ontwerpfase aan de linkerzijde van de “V”, is een corresponderende integratiefase aan de rechterzijde van de “V”. In figuur 1 representeren de rechthoekige blokken de fasen en de ovale blokken de producten. Het V-model is een lineaire methode en wordt altijd in de volgorde uitgevoerd als in figuur 1.
Over het algemeen zal het ontwikkelproces er als volgt uitzien, dit is dus de linkerkant van het model:
Business Case
De business case is de eerste stap van ontwikkeling, hierin wordt beschreven door de klant wat er wordt verwacht van het nieuwe systeem. Moet er een heel nieuw systeem worden ontwikkeld? Of is het de bedoeling dat er een uitbreiding komt op een reeds in gebruik genomen systeem? Wat zijn de verwachte voordelen die het systeem bij voltooiing zal bieden in het werkveld van de klant, en wat zijn de geschatte kosten om dit systeem te ontwikkelen en in gebruik te nemen? De business case is de economische onderbouwing voor het project. Wat is de investering en wat zijn de verwachte opbrengsten?
Requirements
Bij requirements wordt door de klant beschreven wat de vereisten zijn van het systeem om te worden geaccepteerd. Dit is een beschrijving van zowel de functionele als niet-functionele eisen.
Informatie-analyse
Vereisten worden vervolgens doorgespeeld naar de ontwikkelaars. Deze maken dan een systeemspecificatie. Hierin verandert de focus van wat het systeem moet kunnen naar de manier waarop men dit wil bereiken, dus welke methode, software, hardware is nodig om aan de vereisten te kunnen voldoen.
Systeemontwerp
Andere ontwikkelaars gaan vervolgens aan de slag met het systeemontwerp, deze wordt opgesteld aan de hand van de reeds gemaakte systeemspecificatie. Hierin worden de verschillende componenten die het systeem zal bevatten om aan de requirements te kunnen voldoen aan elkaar gekoppeld en wordt de relatie tussen de componenten beschreven.
Component Design
Iedere component heeft ook een eigen design, waar in detail wordt beschreven hoe het zijn processen zal verwerken.
Programmering
De componenten worden gebouwd, het systeem is dan klaar voor het testproces.
Testproces
Het testproces dat hoort bij de hierboven beschreven methode ziet er als volgt uit, dit is dus de rechterkant van het model:
Unittest
Bij de Unittest worden de individuele componenten getest: voldoen zij aan de voorwaarden beschreven in component design? In theorie zou een onafhankelijke tester dit moeten doen, maar in de praktijk wordt dit meestal gedaan door de ontwikkelaar zelf. Een probleem bij de unittest is dat de component wellicht door de test "individueel" heen komt, maar uiteindelijk zal moeten werken in een volledig systeem. Daarom wordt er vaak software gebruikt die de component wijs maakt dat dit in een compleet systeem functioneert, terwijl dit dus nog helemaal niet zo is.
Integratietest
Wanneer componenten afzonderlijk zijn getest begint de integratietest, dit is in feite kijken of de componenten wanneer zij aan elkaar gekoppeld zijn ook nog naar wens functioneren. Deze test kan door de ontwikkelaar of door specialisten worden gedaan.
Systeemtest
Wanneer het volledige systeem is gebouwd is het tijd voor de systeemtest. Hierin wordt gekeken of alle vereisten kunnen worden gehaald. Dit is niet het testen van verschillende componenten, maar meer het volledige systeem. Denk hierbij aan het testen van onder andere:
- Performance - Zijn de vooraf opgestelde doelstellingen voor dit punt bereikt?
- Volume - Kan het systeem grote hoeveelheden informatie aan?
- Stress - Kan het systeem grote hoeveelheden informatie op een bepaald tijdstip aan? (piekuren)
- Documentatie - Is de documentatie die er wordt bijgeleverd bruikbaar voor het uiteindelijke systeem?
- Robustness - Blijft het systeem stabiel onder uitzonderlijke omstandigheden?
Acceptatietest
De acceptatietest test feitelijk de business case: levert het systeem wat de klant er van verwacht om voor hem een voordeel op te leveren in zijn werkveld? Met andere woorden zijn alle vereisten bereikt. Deze test moet uiteraard worden gedaan door de klant / gebruiker. Men spreekt dan ook wel van de UAT (User Acceptance Test) oftewel in goed Nederlands, de Gebruikersacceptatietest.
Release Testing
De release test is het testen hoe het systeem uiteindelijk draait in de organisatie. Heeft het bijvoorbeeld invloed op andere systemen? Is het compatibel met de andere systemen? Hoe is de daadwerkelijke performance van het systeem binnen de organisatie?
Technieken
Het V-model suggereert geen bepaalde technieken voor de verschillende fasen. Technieken die voor de rechterkant (de testkant) gebruikt kunnen worden zijn:
- Algoritmetest
- Beslissingstabellentest
- Dataflowtest
- Elementaire vergelijkingtest
- Error Guessing
- Gegevenscyclustest
- Procescyclustest
- Programmainterfacetest
- Real-Lifetest
- Semantische test
- Syntactische test
Voordelen
- Elke fase van integratie wordt getest.
Nadelen
- Het V-model gaat ervan uit dat vereisten niet veranderen.
- Het ontwerp wordt niet geverifieerd.
- Vereisten worden niet geverifieerd.
- In elke fase bestaat de kans op fouten. Fouten kunnen het best zo vroeg mogelijk in het traject gevonden en hersteld worden, dit is altijd goedkoper. In het V-model vindt de eerste verificatiefase plaats na het ontwerp van de modules. Verificatie gebeurt bij andere methoden al tijdens de specificatiefase.
Bronnen
- win.tue.nl
- coleyconsulting.co.uk
![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Commons-logo.svg/25px-Commons-logo.svg.png)