Het V-model is een type van SDLC-model waarbij het proces opeenvolgend in een V-vorm wordt uitgevoerd. Het wordt ook wel het Verificatie- en Validatiemodel genoemd. Het is gebaseerd op de associatie van een testfase voor elke overeenkomstige ontwikkelingsfase. De ontwikkeling van elke stap houdt rechtstreeks verband met de testfase. De volgende fase begint pas na voltooiing van de vorige fase, d.w.z. voor elke ontwikkelingsactiviteit is er een bijbehorende testactiviteit.

Inhoudsopgave

• V-modelontwerp
• Belang van het V-model
• Principes van het V-model
• Wanneer gebruik je het V-model?
• Voordelen van het V-model
• Nadelen van het V-model
• Conclusie

Het V-model is een softwareontwikkelingslevenscyclusmodel (SDLC) dat een systematische en visuele weergave biedt van het softwareontwikkelingsproces. Het is gebaseerd op het idee van een V-vorm, waarbij de twee poten van de V de voortgang van de V vertegenwoordigen softwareontwikkelingsproces van eisen verzamelen en analyse tot ontwerp, implementatie, testen en onderhoud.

V-modelontwerp

1. Vereisten verzamelen en analyseren : De eerste fase van het V-model is de fase van het verzamelen en analyseren van eisen, waarbij de eisen van de klant aan de software worden verzameld en geanalyseerd om de reikwijdte van het project te bepalen.
2. Ontwerp: In de ontwerpfase worden de softwarearchitectuur en het ontwerp ontwikkeld, inclusief het high-level ontwerp en het detailontwerp.
3. Implementatie: In de implementatiefase wordt de software gebouwd op basis van het ontwerp.
4. Testen: In de testfase wordt de software getest om er zeker van te zijn dat deze voldoet aan de eisen van de klant en van hoge kwaliteit is.
5. Inzet: In de deploymentfase wordt de software ingezet en in gebruik genomen.
6. Onderhoud: In de onderhoudsfase wordt de software onderhouden om ervoor te zorgen dat deze blijft voldoen aan de wensen en verwachtingen van de klant.
7. Het V-model wordt vaak gebruikt in de veiligheid: kritische systemen, zoals lucht- en ruimtevaart- en defensiesystemen, vanwege de nadruk op grondig testen en het vermogen om de stappen die betrokken zijn bij het softwareontwikkelingsproces duidelijk te definiëren.

SDLC V-model

De volgende illustratie toont de verschillende fasen in een V-model van de SDLC.

755 chmod

Verificatie Fasen :

Het betreft een statische analysetechniek (review) die wordt uitgevoerd zonder code uit te voeren. Het is het evaluatieproces van de productontwikkelingsfase om vast te stellen of aan de gespecificeerde eisen wordt voldaan.

Er zijn verschillende verificatiefasen in het V-model:

Analyse van bedrijfsvereisten:

Dit is de eerste stap in het aanwijzen van de ontwikkelingscyclus waarin de productbehoefte moet worden opgelost vanuit het perspectief van de klant. in deze fasen omvat een goede communicatie met de klant om de behoeften van de klanten te begrijpen. dit zijn de zeer belangrijke activiteiten die op de juiste manier moeten worden afgehandeld, omdat klanten meestal niet precies weten wat ze willen, en ze er op dat moment niet zeker van zijn, gebruiken we een acceptatietestontwerp planning die wordt uitgevoerd op het moment dat de bedrijfsbehoefte nodig is, zal worden gebruikt als een invoer voor acceptatietesten.

Systeem ontwerp:

Het ontwerp van het systeem begint wanneer we over het algemeen duidelijk zijn over de productvereisten en vervolgens het systeem volledig moeten ontwerpen. Dit inzicht zal aan het begin van het volledige productontwikkelingsproces staan. deze zullen gunstig zijn voor de toekomstige uitvoering van testgevallen.

Architectueel ontwerp:

In deze fase worden de architectonische specificaties begrepen en ontworpen. Meestal worden verschillende technische benaderingen voorgesteld, en de uiteindelijke keuze wordt gemaakt nadat zowel de technische als de financiële haalbaarheid is overwogen. De systeemarchitectuur is verder onderverdeeld in modules die elk een afzonderlijke functie vervullen. Een andere naam hiervoor is High Level Design (HLD).

Op dit punt zijn de gegevensuitwisseling en communicatie tussen de interne modules en externe systemen goed begrepen en gedefinieerd. Tijdens deze fase kunnen integratietests worden gemaakt en gedocumenteerd met behulp van de verstrekte informatie.

Moduleontwerp:

Deze fase, bekend als Low-Level Design (LLD), specificeert het uitgebreide interne ontwerp voor elke systeemmodule. Compatibiliteit tussen het ontwerp en andere externe systemen en andere modules in de systeemarchitectuur is cruciaal. Unittests zijn een cruciaal onderdeel van elk ontwikkelingsproces, omdat ze helpen bij het identificeren en uitroeien van de meeste fouten en gebreken in een vroeg stadium. Op basis van de interne moduleontwerpen kunnen deze unit-tests nu worden gemaakt.

Coderingsfase:

bijenkorf architectuur

De codeerstap omvat het schrijven van de code voor de systeemmodules die tijdens de ontwerpfase zijn gemaakt. Aan de hand van de systeem- en architectuurvereisten wordt bepaald welke programmeertaal het meest geschikt is.

Bij het coderen worden de coderingsnormen en -principes gevolgd. Voordat de definitieve build in de repository wordt ingecheckt, ondergaat de code vele codebeoordelingen en wordt deze geoptimaliseerd voor optimale prestaties.

Geldigmaking Fasen :

Het omvat dynamische analysetechnieken (functioneel en niet-functioneel) en testen door het uitvoeren van code. Validatie is het proces waarbij de software wordt geëvalueerd na voltooiing van de ontwikkelingsfase 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. De verificatie- en validatiefasen worden samengevoegd door de coderingsfase in een V-vorm. Daarom wordt het V-model genoemd.
Er zijn meerdere Geldigmaking fasen in het V-model:

chmod 755

Testen van een eenheid:

Unit Test Plannen worden ontwikkeld tijdens de moduleontwerpfase. Deze unittestplannen worden uitgevoerd om bugs op code- of unitniveau te elimineren.

Integratie testen:

Na voltooiing van de unit-testen worden integratietesten uitgevoerd. Bij integratietesten worden de modules geïntegreerd en wordt het systeem getest. Integratietesten worden uitgevoerd in de Architectuurontwerpfase. Deze test verifieert de communicatie van modules onderling.

Systeem testen:

Systeemtesten testen de volledige applicatie met zijn functionaliteit, onderlinge afhankelijkheid en communicatie. Het test de functionele en niet-functionele eisen van de ontwikkelde applicatie.

Gebruikersacceptatietesten (UAT):

UAT wordt uitgevoerd in een gebruikersomgeving die lijkt op de productieomgeving. UAT verifieert dat het geleverde systeem voldoet aan de eisen van de gebruiker en dat het systeem klaar is voor gebruik in de echte wereld.

Ontwerpfase:

• Vereistenanalyse: Deze fase omvat gedetailleerde communicatie met de klant om hun vereisten en verwachtingen te begrijpen. Deze fase staat bekend als het verzamelen van vereisten.
• Systeem ontwerp: Deze fase omvat het systeemontwerp en de volledige hardware- en communicatie-opstelling voor de ontwikkeling van het product.
• Architectueel ontwerp: Het systeemontwerp wordt verder opgesplitst in modules die verschillende functionaliteiten in beslag nemen. De dataoverdracht en communicatie tussen de interne modules en met de buitenwereld (andere systemen) wordt duidelijk begrepen.
• Moduleontwerp: In deze fase valt het systeem uiteen in kleine modules. Het gedetailleerde ontwerp van modules wordt gespecificeerd, ook wel Low-Level Design (LLD) genoemd.

Testfasen:

• Testen van een eenheid: Unit Test Plannen worden ontwikkeld tijdens de moduleontwerpfase. Deze Unit Test Plans worden uitgevoerd om bugs op code- of unitniveau te elimineren.
• Integratie testen: Na voltooiing van de unit-testen worden integratietesten uitgevoerd. Bij integratietesten worden de modules geïntegreerd en wordt het systeem getest. Integratietesten worden uitgevoerd in de Architectuurontwerpfase. Deze test verifieert de communicatie van modules onderling.
• Systeem testen: Systeemtesten testen de volledige applicatie met zijn functionaliteit, onderlinge afhankelijkheid en communicatie. Het test de functionele en niet-functionele eisen van de ontwikkelde applicatie.
• Gebruikersacceptatietesten (UAT): UAT wordt uitgevoerd in een gebruikersomgeving die lijkt op de productieomgeving. UAT verifieert dat het geleverde systeem voldoet aan de eisen van de gebruiker en dat het systeem klaar is voor gebruik in de echte wereld.

Industriële uitdaging:

Naarmate de industrie zich heeft ontwikkeld, zijn de technologieën complexer, steeds sneller en voortdurend aan het veranderen. Er blijft echter een reeks basisprincipes en concepten bestaan ​​die vandaag de dag nog net zo toepasbaar zijn als toen IT nog in de kinderschoenen stond.

• Definieer en verfijn gebruikersvereisten nauwkeurig.
• Ontwerp en bouw een applicatie volgens de geautoriseerde gebruikersvereisten.
• Valideren dat de applicatie die ze hadden gebouwd voldeed aan de geautoriseerde zakelijke vereisten.

Belang van het V-model

1. Vroegtijdige identificatie van defecten

Door verificatie- en validatietaken in elke fase van het ontwikkelingsproces op te nemen, moedigt het V-model vroeg testen aan. Dit verlaagt de kosten en inspanningen die nodig zijn om problemen later in de ontwikkelingslevenscyclus te verhelpen door te helpen bij het vroegtijdig opsporen en oplossen van fouten.

js-vervanging

2. het bepalen van de fasen van ontwikkeling en testen

Het V-Model bevat een testfase die overeenkomt met elke fase van het ontwikkelingsproces. Door ervoor te zorgen dat test- en ontwikkelingsprocessen duidelijk in kaart worden gebracht, bevordert deze duidelijke mapping een methodische en ordelijke benadering van software-engineering.

3. Voorkomt big bang-testen

Testen wordt in traditionele ontwikkelingsmodellen vaak helemaal aan het einde van de ontwikkelingslevenscyclus uitgevoerd, wat resulteert in een Big Bang-benadering waarbij alle testactiviteiten tegelijkertijd worden geconcentreerd. Door testactiviteiten in het ontwikkelingsproces te integreren en een meer progressieve en gereguleerde testaanpak aan te moedigen, voorkomt het V-model dit.

4. Verbetert de samenwerking

Op elk niveau bevordert het V-Model de samenwerking tussen de test- en ontwikkelingsteams. Door deze samenwerking worden projectvereisten, ontwerpkeuzes en testmethodieken beter begrepen, wat de effectiviteit en efficiëntie van het ontwikkelingsproces verbetert.

5. Verbeterde kwaliteitsborging

De algehele kwaliteitsborging wordt verbeterd door het V-model, dat testactiviteiten op elk niveau omvat. Voordat het programma de laatste implementatiefase bereikt, zorgt het ervoor dat het aan de vereisten voldoet en doorloopt het een strikt validatie- en verificatieproces.

Principes van het V-model

• Groot naar klein: In V-Model wordt het testen uitgevoerd in een hiërarchisch perspectief, bijvoorbeeld de vereisten die zijn geïdentificeerd door het projectteam, het creëren van High-Level Design en gedetailleerde ontwerpfasen van het project. Naarmate elk van deze fasen is voltooid, worden de eisen die ze definiëren steeds verfijnder en gedetailleerder.
• Gegevens-/procesintegriteit: Dit principe stelt dat het succesvolle ontwerp van elk project de integratie en samenhang van zowel gegevens als processen vereist. Proceselementen moeten bij elke eis worden geïdentificeerd.
• Schaalbaarheid: Dit principe stelt dat het V-Model-concept de flexibiliteit heeft om elk IT-project te huisvesten, ongeacht de omvang, complexiteit of duur ervan.
• Kruisverwijzingen: Een directe correlatie tussen vereisten en bijbehorende testactiviteiten staat bekend als kruisverwijzingen.

Tastbare documentatie:

Dit principe stelt dat elk project een document moet maken. Deze documentatie is vereist en wordt toegepast door zowel het projectontwikkelingsteam als het ondersteuningsteam. Er wordt gebruik gemaakt van documentatie om de applicatie te onderhouden zodra deze beschikbaar is in een productieomgeving.

Waarom de voorkeur?

• Het is gemakkelijk te beheren vanwege de stijfheid van het model. Elke fase van V-Model heeft specifieke resultaten en een beoordelingsproces.
• Proactieve detectie van defecten – dat wil zeggen dat defecten in een vroeg stadium worden ontdekt.

Wanneer te gebruiken van V-model ?

• Traceerbaarheid van vereisten: Het V-model blijkt nuttig in situaties waarin het absoluut noodzakelijk is om nauwkeurige traceerbaarheid te creëren tussen de vereisten en de bijbehorende testgevallen.
• Complexe projecten: Het V-model biedt een methodische manier om testactiviteiten te beheren en de risico's gerelateerd aan integratie- en interfaceproblemen te verminderen voor projecten met een hoge mate van complexiteit en onderlinge afhankelijkheden tussen systeemcomponenten.
• Watervalachtige projecten : Omdat het V-model een toegankelijke structuur biedt voor het organiseren, uitvoeren en monitoren van testactiviteiten op elk ontwikkelingsniveau, is het geschikt voor projecten die een sequentiële ontwikkelingsbenadering gebruiken, net zoals het watervalmodel.
• Veiligheidskritische systemen: Deze systemen worden gebruikt in de lucht- en ruimtevaart-, automobiel- en gezondheidszorgsector. Ze leggen sterk de nadruk op rigide verificatie- en validatieprocedures, die helpen garanderen dat aan essentiële systeemvereisten wordt voldaan en dat mogelijke risico's vroeg in het ontwikkelingsproces worden opgespoord en geëlimineerd.

Voordelen van het V-model

• Dit is een zeer gedisciplineerd model en de fasen worden één voor één voltooid.
• V-Model wordt gebruikt voor kleine projecten waarbij de projectvereisten duidelijk zijn.
• Eenvoudig en gemakkelijk te begrijpen en te gebruiken.
• Dit model richt zich op verificatie- en validatieactiviteiten vroeg in de levenscyclus, waardoor de kans op het bouwen van een foutloos product van goede kwaliteit wordt vergroot.
• Het stelt projectmanagement in staat de voortgang nauwkeurig te volgen.
• Duidelijk en gestructureerd proces: Het V-model zorgt voor een helder en gestructureerd proces software ontwikkeling , waardoor het gemakkelijker te begrijpen en te volgen is.
• Nadruk op testen: Het V-model legt een sterke nadruk op testen, wat de kwaliteit en betrouwbaarheid van de software helpt garanderen.
• Verbeterde traceerbaarheid: Het V-model zorgt voor een duidelijke link tussen de eisen en het eindproduct, waardoor het eenvoudiger wordt om wijzigingen in de software te traceren en te beheren.
• Betere communicatie: De duidelijke structuur van het V-model helpt de communicatie tussen de klant en het ontwikkelingsteam te verbeteren.

Nadelen van het V-model

• Hoog risico en onzekerheid.
• Het is niet goed voor complexe en objectgeoriënteerde projecten.
• Het is niet geschikt voor projecten waarbij de vereisten niet duidelijk zijn en een hoog risico op verandering met zich meebrengen.
• Dit model ondersteunt geen iteratie van fasen.
• Het kan niet gemakkelijk omgaan met gelijktijdige gebeurtenissen.
• Inflexibiliteit: Het V-model is een lineair en sequentieel model, wat het moeilijk kan maken om zich aan te passen aan veranderende eisen of onverwachte gebeurtenissen.
• Tijdrovend: Het V-model kan tijdrovend zijn, omdat het veel documentatie en testen vereist.
• Overmatig vertrouwen in documentatie: Het V-model legt een sterke nadruk op documentatie, wat kan leiden tot een overmatig vertrouwen in documentatie, ten koste van feitelijk ontwikkelingswerk.

Conclusie

Een wetenschappelijke en georganiseerde benadering van de Software Development Life Cycle (SDLC) wordt geboden door het Software Engineering V-Model. De expertise van het team met de geselecteerde methodologie, de unieke kenmerken van het project en de aard van de vereisten moeten allemaal in overweging worden genomen bij het selecteren van SDLC-modellen, inclusief het V-model.

Referentieboek:

Software Engineering: A Practitioner’s Approach door Roger S. Pressman, uitgegeven door McGraw-Hill Education, 2017.