V-Model, ook wel het Verificatie- en Validatiemodel genoemd. Hierin moet elke fase van SDLC zijn voltooid voordat de volgende fase begint. Het volgt een sequentieel ontwerpproces dat hetzelfde is als het watervalmodel. Het testen van het apparaat is parallel gepland met een overeenkomstige ontwikkelingsfase.
Verificatie: Het betreft een statische analysemethode (review) die wordt uitgevoerd zonder code uit te voeren. Het is het evaluatieproces van het productontwikkelingsproces om te bepalen of de gespecificeerde vereisten voldoen.
Geldigmaking: Het gaat om een dynamische analysemethode (functioneel, niet-functioneel), het testen gebeurt door het uitvoeren van code. Validatie is het proces om de software na voltooiing van het ontwikkelingsproces te classificeren om te bepalen of de software voldoet aan de verwachtingen en eisen van de klant.
V-Model bevat dus verificatiefasen aan de ene kant en de validatiefasen aan de andere kant. Het verificatie- en validatieproces wordt vergezeld door een codeerfase in V-vorm. Daarom staat het bekend als het V-model.
Er zijn verschillende fasen van de verificatiefase van het V-model:
| Analyse van bedrijfsvereisten: | Dit is de eerste stap waarbij de productvereisten van de kant van de klant worden begrepen. Deze fase omvat gedetailleerde communicatie om de verwachtingen en exacte vereisten van de klant te begrijpen.
| Systeem ontwerp: | In deze fase analyseren en interpreteren systeemingenieurs de activiteiten van het voorgestelde systeem door het document met gebruikersvereisten te bestuderen.
| Architectonisch ontwerp: | De basislijn bij het selecteren van de architectuur is dat deze alles moet begrijpen, wat doorgaans bestaat uit de lijst met modules, de korte functionaliteit van elke module, hun interfacerelaties, afhankelijkheden, databasetabellen, architectuurdiagrammen, technologiedetails, enz. Het integratietestmodel wordt uitgevoerd uit in een bepaalde fase.
| Moduleontwerp: | In de moduleontwerpfase wordt het systeem opgesplitst in kleine modules. Het gedetailleerde ontwerp van de modules wordt gespecificeerd, dit staat bekend als Low-Level Design
| Coderingsfase: | Na het ontwerpen wordt de codeerfase gestart. Op basis van de vereisten wordt een geschikte programmeertaal bepaald. Er zijn enkele richtlijnen en standaarden voor codering. Voordat de repository wordt ingecheckt, wordt de uiteindelijke build geoptimaliseerd voor betere prestaties en ondergaat de code vele codebeoordelingen om de prestaties te controleren.
Er zijn verschillende fasen van de validatiefase van het V-model:
| Testen van een eenheid: | In het V-model worden tijdens de moduleontwerpfase Unit Test Plans (UTP’s) ontwikkeld. Deze UTP's worden uitgevoerd om fouten op codeniveau of eenheidsniveau te elimineren. Een eenheid is de kleinste entiteit die zelfstandig kan bestaan, bijvoorbeeld een programmamodule. Het testen van eenheden verifieert dat de kleinste entiteit correct kan functioneren wanneer deze wordt geïsoleerd van de rest van de codes/eenheden.
| Integratie testen: | Tijdens de architectonische ontwerpfase worden integratietestplannen ontwikkeld. Deze tests verifiëren dat groepen die onafhankelijk van elkaar zijn gemaakt en getest, naast elkaar kunnen bestaan en met elkaar kunnen communiceren.
| Systeem testen: | Systeemtestplannen worden ontwikkeld tijdens de systeemontwerpfase. In tegenstelling tot Unit- en Integratietestplannen worden Systeemtestplannen samengesteld door het zakelijke team van de klant. Systeemtest zorgt ervoor dat aan de verwachtingen van een applicatieontwikkelaar wordt voldaan.
| Acceptatietesten: | Acceptatietesten houden verband met het analysegedeelte van de bedrijfsvereisten. Het omvat het testen van het softwareproduct in de gebruikersatmosfeer. Acceptatietests brengen de compatibiliteitsproblemen met de verschillende systemen aan het licht, die beschikbaar zijn binnen de gebruikersomgeving. Het ontdekt tegelijkertijd de niet-functionele problemen zoals belasting- en prestatiefouten binnen de echte gebruikersatmosfeer.
Wanneer gebruik je het V-model?
- Wanneer de vereiste goed gedefinieerd en niet dubbelzinnig is.
- Het V-vormige model moet worden gebruikt voor kleine tot middelgrote projecten waarbij de eisen duidelijk gedefinieerd en vastgelegd zijn.
- Het V-vormige model moet worden gekozen als er voorbeeld technische hulpmiddelen beschikbaar zijn met essentiële technische expertise.
Voordeel (voordelen) van het V-model:
- Makkelijk te begrijpen.
- Testmethoden zoals planning en testontwerp vinden plaats ruim vóór het coderen.
- Dit bespaart veel tijd. Vandaar een grotere kans op succes ten opzichte van het watervalmodel.
- Voorkomt de neerwaartse stroom van de defecten.
- Werkt goed voor kleine plannen waarbij de vereisten gemakkelijk te begrijpen zijn.
Nadeel (nadelen) van het V-model:
- Zeer stijf en minst flexibel.
- Niet goed voor een complex project.
- Software wordt ontwikkeld tijdens de implementatiefase, er worden dus geen vroege prototypes van de software geproduceerd.
- Als er halverwege wijzigingen plaatsvinden, moeten de testdocumenten samen met de vereiste documenten worden bijgewerkt.
