V-modell også referert til som verifikasjons- og valideringsmodellen. I dette må hver fase av SDLC fullføres før neste fase starter. Den følger en sekvensiell designprosess på samme måte som fossmodellen. Testing av enheten er planlagt parallelt med et tilsvarende utviklingsstadium.

Bekreftelse: Det involverer en statisk analysemetode (gjennomgang) utført uten å kjøre kode. Det er prosessen med evaluering av produktutviklingsprosessen for å finne ut om spesifiserte krav oppfyller.

Validering: Det involverer dynamisk analysemetode (funksjonell, ikke-funksjonell), testing gjøres ved å kjøre kode. Validering er prosessen for å klassifisere programvaren etter fullføring av utviklingsprosessen for å avgjøre om programvaren oppfyller kundenes forventninger og krav.

Så V-Model inneholder verifikasjonsfaser på den ene siden av valideringsfasene på den andre siden. Verifikasjons- og valideringsprosessen er forbundet med kodingsfase i V-form. Derfor er den kjent som V-Model.

Det er de forskjellige fasene av verifiseringsfasen til V-modellen:

Analyse av forretningsbehov:Dette er det første trinnet hvor produktkrav forstått fra kundens side. Denne fasen inneholder detaljert kommunikasjon for å forstå kundens forventninger og eksakte krav.System design:I dette stadiet analyserer og tolker systemingeniører virksomheten til det foreslåtte systemet ved å studere brukerkravdokumentet.Arkitekturdesign:Grunnlaget for valg av arkitektur er at den skal forstå alt som vanligvis består av listen over moduler, kort funksjonalitet for hver modul, deres grensesnittforhold, avhengigheter, databasetabeller, arkitekturdiagrammer, teknologidetaljer osv. Integrasjonstestmodellen utføres ut i en bestemt fase.Moduldesign:I moduldesignfasen brytes systemet ned i små moduler. Den detaljerte utformingen av modulene er spesifisert, som er kjent som Low-Level DesignKodefase:Etter utforming startes kodingsfasen. Ut fra kravene bestemmes et passende programmeringsspråk. Det er noen retningslinjer og standarder for koding. Før du sjekker inn depotet, er den endelige byggingen optimalisert for bedre ytelse, og koden går gjennom mange kodegjennomganger for å sjekke ytelsen.

Det er de forskjellige fasene av valideringsfasen til V-modellen:

Enhetstesting:I V-modellen utvikles Unit Test Plans (UTPs) i løpet av moduldesignfasen. Disse UTP-ene utføres for å eliminere feil på kodenivå eller enhetsnivå. En enhet er den minste enheten som uavhengig kan eksistere, for eksempel en programmodul. Enhetstesting bekrefter at den minste enheten kan fungere korrekt når den er isolert fra resten av kodene/enhetene.Integrasjonstesting:Integrasjonstestplaner utvikles under den arkitektoniske designfasen. Disse testene bekrefter at grupper opprettet og testet uavhengig kan sameksistere og kommunisere seg imellom.Systemtesting:Systemtester Planer utvikles i systemdesignfasen. I motsetning til enhets- og integrasjonstestplaner, er systemtestplaner satt sammen av kundens forretningsteam. Systemtest sikrer at forventningene fra en applikasjonsutvikler oppfylles.Aksepttesting:Aksepttesting er relatert til delen av forretningsbehovsanalysen. Det inkluderer testing av programvareproduktet i brukeratmosfære. Aksepttester avslører kompatibilitetsproblemene med de forskjellige systemene, som er tilgjengelig i brukeratmosfæren. Den oppdager samtidig de ikke-funksjonelle problemene som last- og ytelsesfeil i den virkelige brukeratmosfæren.

Når skal man bruke V-Model?

• Når kravet er godt definert og ikke tvetydig.
• Den V-formede modellen bør brukes til små til mellomstore prosjekter hvor krav er klart definerte og faste.
• Den V-formede modellen bør velges når eksempler på tekniske ressurser er tilgjengelige med essensiell teknisk ekspertise.

Fordeler (fordeler) med V-modell:

1. Enkelt å forstå.
2. Testmetoder som planlegging, testdesign skjer i god tid før koding.
3. Dette sparer mye tid. Derav en høyere sjanse for suksess i forhold til fossefallsmodellen.
4. Unngår nedadgående flyt av defektene.
5. Fungerer godt for små planer der kravene er lett å forstå.

Ulemper (ulemper) med V-modell:

1. Veldig stiv og minst fleksibel.
2. Ikke bra for et komplekst prosjekt.
3. Programvare utvikles under implementeringsfasen, så det produseres ingen tidlige prototyper av programvaren.
4. Hvis det skjer endringer midtveis, må testdokumentene sammen med de nødvendige dokumentene oppdateres.