V-model

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

Het V-model is een lineaire softwareontwikkelmethode en is ontworpen in 1986 door Paul E. Brook. Het V-model is oorspronkelijk afgeleid van de watervalmethode.

Opzet methode[bewerken]

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[bewerken]

Voorbeeld van een V model. (Nederlandstalig)
Voorbeeld van een gangbaarder (Engelstalig) V model.

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 uit zien, dit is dus de linkerkant van het model:

Business Case[bewerken]

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?

Requirements[bewerken]

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[bewerken]

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[bewerken]

Andere ontwikkelaars gaan vervolgens bezig 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[bewerken]

Iedere component heeft ook een eigen design, waar in detail wordt beschreven hoe het zijn processen zal verwerken.

Programmering[bewerken]

De componenten worden gebouwd, het systeem is dan klaar voor het testproces.

Testproces[bewerken]

Het testproces dat hoort bij de hierboven beschreven methode ziet er als volgt uit, dit is dus de rechterkant van het model:

Unittest[bewerken]

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 het component wellicht door de test "individueel" heen komt, maar uiteindelijk zal moeten werken in een volledig systeem. Daarom wordt er vaak software gebruikt die het component wijs maakt dat dit in een compleet systeem functioneert, terwijl dit dus nog helemaal niet zo is.

Interfacetest[bewerken]

Wanneer componenten afzonderlijk zijn getest begint de interfacetest, 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[bewerken]

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[bewerken]

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[bewerken]

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[bewerken]

Het V-model suggereert geen bepaalde technieken voor de verschillende fasen. Technieken die voor de rechterkant (de testkant) gebruikt kunnen worden zijn:

Voordelen[bewerken]

  • Elke fase van integratie wordt getest.

Nadelen[bewerken]

  • 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 specificatie fase.

Bronnen[bewerken]