V-model
Van Wikipedia
Inhoud |
[bewerk] Geschiedenis
Het V-model is een lineaire software ontwikkelmethode en is ontworpen in 1986 door Paul E. Brook. Het V-model is oorspronkelijk afgeleid van de watervalmethode.
[bewerk] Opzet methode
Het V-model besteedt in tegenstelling tot het waterval model evenwichtig aandacht aan ontwikkeling en verificatie. Het software ontwerp inclusief de verificatie is opgedeeld in een aantal fasen welke 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. Dit herhaalt zich voor alle fasen, en met elke nieuwe basis die wordt gevormd groeit het vertrouwen in het systeem.
[bewerk] Fasering
Figuur 1 [1]
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.
[bewerk] 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
-Programma interfacetest
-Real-Life test
-Semantische test
-Syntactische test
Over het algemeen zal het ontwikkelproces er als volgt uit zien, dit is dus de linkerkant van het model:
Business Case
Dit is de eerste stap van ontwikkeling, hierin wordt beschreven door de klant wat er wordt verwacht van het nieuwe systeem. Moet er een heel nieuwe 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 voltooing 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
Hierin 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 vereisten.
System Specification
Vereisten worden vervolgens doorgespeeld naar de developers. Deze maken dan een systeem specificatie. 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 requirements te kunnen voldoen.
System Design
Andere developers gaan vervolgens bezig met het system design, deze wordt opgesteld aan de hand van de reeds gemaakte system specification. Hierin worden de verschillende componenten die het systeem zal bevatten om aan de requirements te kunnen voldoen aan elkaar gekoppeld en beschrijft de relatie tussen de componenten.
Component Design
Iedere component heeft ook een eigen design, waar in gedetaileerd wordt beschreven hoe het zijn processen zal verwerken.
Component Construction
De componenten worden gebouwd, het systeem is dan klaar voor het testproces.
Het test proces dat hoort bij de hierboven beschreven methode ziet er als volgt uit, dit is dus de rechterkant van het model:
Component Testing
Hier 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 component testing is dat het wellicht door de test "individueel" heen komt, maar uiteindelijk zal het moeten werken in een volledig systeem, daarom wordt er vaak software gebruikt die het component wijs maakt dat het in een compleet systeem functioneerd terwijl dit dus nog helemaal niet zo is.
Interface Testing
Wanneer componenten afzonderlijk zijn getest begint de interface test, dit is in feite kijken of de componenten wanneer zij aan elkaar gekoppeld zijn ook nog naar wens funtioneren. Deze test kan door de ontwikkelaar of specialisten worden gedaan.
System Testing
Wanneer het volledige systeem is gebouwd is het tijd voor de system test. Hierin wordt gekeken of alle requirements 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 )
- Documentation - Is de documentatie die er wordt bijgeleverd bruikbaar voor het uiteindelijke systeem?
- Robustness - Blijft het systeem stabiel onder uitzonderlijke omstandigheden?
Acceptance Testing
De acceptatie test, leverd het systeem wat de klant er van verwacht om voor hem een voordeel op te leveren in zijn werkveld? Met andere worden zijn alle requirements bereikt. Deze test moet uiteraard worden gedaan door de klant.
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 compatible met de andere systemen? Hoe is de daadwerkelijke performance van het systeem binnen de organisatie?
[bewerk] Voordelen
- Elke fase van integratie wordt getest.
[bewerk] Nadelen
- Het V-model gaat er vanuit dat requirements niet veranderen.
- Het ontwerp wordt niet geverifieerd.
- Requirements 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 verificatie fase plaats na het ontwerp van de modules. Verificatie zou eigenlijk al moeten beginnen tijdens de specificatie fase.
[bewerk] Bronnen
http://www.coleyconsulting.co.uk/testtype.htm
S259276 S264015
