logo

V-model

V-modellen også kaldet verifikations- og valideringsmodellen. I dette skal hver fase af SDLC afsluttes, før den næste fase starter. Den følger en sekventiel designproces på samme måde som vandfaldsmodellen. Test af enheden er planlagt parallelt med et tilsvarende udviklingstrin.

V-model

Verifikation: Det involverer en statisk analysemetode (gennemgang) udført uden at udføre kode. Det er processen med evaluering af produktudviklingsprocessen for at finde ud af, om specificerede krav opfylder.

Validering: Det involverer dynamisk analysemetode (funktionel, ikke-funktionel), test udføres ved at udføre kode. Validering er processen til at klassificere softwaren efter afslutningen af ​​udviklingsprocessen for at afgøre, om softwaren lever op til kundens forventninger og krav.

Så V-Model indeholder verifikationsfaser på den ene side af valideringsfaserne på den anden side. Verifikations- og valideringsprocessen er forbundet med kodningsfasen i V-form. Derfor er den kendt som V-Model.

Der er de forskellige faser af verifikationsfasen af ​​V-modellen:

    Analyse af forretningsbehov:Dette er det første trin, hvor produktkrav forstås fra kundens side. Denne fase indeholder detaljeret kommunikation for at forstå kundens forventninger og præcise krav.Systemdesign:I denne fase analyserer og fortolker systemingeniører det foreslåede systems forretning ved at studere brugerkravsdokumentet.Arkitektur design:Udgangspunktet for valg af arkitektur er, at det skal forstå alt, hvad der typisk består af listen over moduler, kort funktionalitet af hvert modul, deres grænsefladeforhold, afhængigheder, databasetabeller, arkitekturdiagrammer, teknologidetaljer osv. Integrationstestmodellen udføres ud i en bestemt fase.Moduldesign:I moduldesignfasen opdeles systemet i små moduler. Det detaljerede design af modulerne er specificeret, hvilket er kendt som Low-Level DesignKodningsfase:Efter design påbegyndes kodningsfasen. Ud fra kravene besluttes et passende programmeringssprog. Der er nogle retningslinjer og standarder for kodning. Før du tjekker ind i depotet, er den endelige build optimeret til bedre ydeevne, og koden gennemgår mange kodegennemgange for at kontrollere ydeevnen.

Der er de forskellige faser af valideringsfasen af ​​V-modellen:

    Enhedstest:I V-modellen udvikles Unit Test Plans (UTP'er) under moduldesignfasen. Disse UTP'er udføres for at eliminere fejl på kodeniveau eller enhedsniveau. En enhed er den mindste enhed, der selvstændigt kan eksistere, fx et programmodul. Enhedstest verificerer, at den mindste enhed kan fungere korrekt, når den er isoleret fra resten af ​​koderne/enhederne.Integrationstest:Integrationstestplaner udvikles i den arkitektoniske designfase. Disse tests bekræfter, at grupper, der er oprettet og testet uafhængigt, kan eksistere side om side og kommunikere indbyrdes.Systemtest:Systemtest Planer udvikles i systemdesignfasen. I modsætning til enheds- og integrationstestplaner er systemtestplaner sammensat af kundens forretningsteam. Systemtest sikrer, at forventningerne fra en applikationsudvikler bliver opfyldt.Accepttest:Accepttest er relateret til analysedelen af ​​forretningskrav. Det omfatter test af softwareproduktet i brugeratmosfære. Accepttest afslører kompatibilitetsproblemer med de forskellige systemer, som er tilgængelige i brugeratmosfæren. Den opdager i fællesskab de ikke-funktionelle problemer som belastnings- og ydeevnedefekter i den virkelige brugeratmosfære.

Hvornår skal man bruge V-Model?

  • Når kravet er veldefineret og ikke tvetydigt.
  • Den V-formede model bør anvendes til små til mellemstore projekter, hvor kravene er klart definerede og faste.
  • Den V-formede model bør vælges, når prøve tekniske ressourcer er tilgængelige med væsentlig teknisk ekspertise.

Fordele (fordele) ved V-model:

  1. Let at forstå.
  2. Testmetoder som planlægning, testdesign sker i god tid før kodning.
  3. Dette sparer en masse tid. Derfor en større chance for succes i forhold til vandfaldsmodellen.
  4. Undgår nedadgående strøm af defekterne.
  5. Fungerer godt til små planer, hvor kravene er let at forstå.

Ulempe (ulemper) ved V-model:

  1. Meget stiv og mindst fleksibel.
  2. Ikke godt for et komplekst projekt.
  3. Software udvikles i implementeringsfasen, så der bliver ikke produceret tidlige prototyper af softwaren.
  4. Hvis der sker ændringer midtvejs, skal testdokumenterne sammen med de nødvendige dokumenter opdateres.