V-modellen er en type SDLC model hvor processen udføres sekventielt i en V-form. Det er også kendt som verifikations- og valideringsmodellen. Den er baseret på tilknytningen af ​​en testfase for hvert tilsvarende udviklingstrin. Udviklingen af ​​hvert trin er direkte forbundet med testfasen. Den næste fase starter først efter afslutningen af ​​den foregående fase, dvs. for hver udviklingsaktivitet er der en testaktivitet svarende til den.

Indholdsfortegnelse

• V-model design
• Vigtigheden af ​​V-modellen
• Principper for V-modellen
• Hvornår skal man bruge V-Model?
• Fordele ved V-Model
• Ulemper ved V-Model
• Konklusion

V-modellen er en softwareudviklings livscyklusmodel (SDLC), der giver en systematisk og visuel repræsentation af softwareudviklingsprocessen. Det er baseret på ideen om en V-form, hvor de to ben af ​​V'et repræsenterer progressionen af softwareudviklingsproces fra kravindsamling og analyse til design, implementering, test og vedligeholdelse.

V-model design

1. Kravindsamling og analyse : V-modellens første fase er kravindsamlings- og analysefasen, hvor kundens krav til softwaren samles og analyseres for at bestemme projektets omfang.
2. Design: I designfasen udvikles softwarearkitekturen og design, herunder højniveaudesign og detaildesign.
3. Implementering: I implementeringsfasen bygges softwaren ud fra designet.
4. Test: I testfasen testes softwaren for at sikre, at den lever op til kundens krav og er af høj kvalitet.
5. Implementering: I udrulningsfasen udrulles og tages softwaren i brug.
6. Vedligeholdelse: I vedligeholdelsesfasen vedligeholdes softwaren for at sikre, at den fortsat opfylder kundens behov og forventninger.
7. V-modellen bruges ofte i sikkerhed: kritiske systemer, såsom rumfarts- og forsvarssystemer, på grund af dets vægt på grundig testning og dets evne til klart at definere de trin, der er involveret i softwareudviklingsprocessen.

SDLC V-model

Følgende illustration viser de forskellige faser i en V-model af SDLC.

Verifikation Faser :

Det involverer en statisk analyseteknik (gennemgang) udført uden at udføre kode. Det er processen med evaluering af produktudviklingsfasen for at finde ud af, om specificerede krav er opfyldt.

Der er flere verifikationsfaser i V-modellen:

Analyse af forretningsbehov:

Dette er det første trin i udpegningen af ​​udviklingscyklussen, hvor produktkrav skal afhjælpes fra kundens perspektiv. i disse faser inkluderer korrekt kommunikation med kunden for at forstå kundernes krav. det er de meget vigtige aktiviteter, der skal håndteres ordentligt, da kunderne for det meste ikke ved præcis, hvad de vil have, og de ikke er sikre på det på det tidspunkt, så bruger vi en accept test design planlægning, som udføres på tidspunktet for forretningskravet, vil det blive brugt som en input til accepttest.

Systemdesign:

Design af systemet starter, når det overordnede vi er klar over produktkravene, og derefter skal designe systemet fuldstændigt. Denne forståelse vil være i begyndelsen af ​​komplet under produktudviklingsprocessen. disse vil være gavnlige for den fremtidige udførelse af testcases.

Arkitektonisk design:

I denne fase bliver arkitektoniske specifikationer forstået og designet. Normalt lægges der flere tekniske tilgange frem, og det ultimative valg træffes efter at have overvejet både den tekniske og økonomiske levedygtighed. Systemarkitekturen er yderligere opdelt i moduler, der hver håndterer en særskilt funktion. Et andet navn for dette er High-Level Design (HLD).

På dette tidspunkt er udvekslingen af ​​data og kommunikation mellem de interne moduler og eksterne systemer godt forstået og defineret. I denne fase kan der oprettes og dokumenteres integrationstests ved hjælp af de oplyste oplysninger.

Moduldesign:

Denne fase, kendt som Low-Level Design (LLD), specificerer det omfattende interne design for hvert systemmodul. Kompatibilitet mellem designet og andre eksterne systemer samt andre moduler i systemarkitekturen er afgørende. Enhedstest er en afgørende komponent i enhver udviklingsproces, da de hjælper med at identificere og udrydde størstedelen af ​​fejl og mangler på et tidligt tidspunkt. Baseret på de interne moduldesigns kan disse enhedstests nu oprettes.

Kodningsfase:

java array

Kodningstrinnet involverer at skrive koden til de systemmoduler, der blev oprettet under designfasen. System- og arkitekturkravene bruges til at bestemme hvilket programmeringssprog der er mest passende.

Kodningsstandarderne og -principperne følges ved udførelse af kodningen. Inden den endelige build tjekkes ind i depotet, gennemgår koden mange kodegennemgange og er optimeret til optimal ydeevne.

Validering Faser :

Det involverer dynamiske analyseteknikker (funktionelle og ikke-funktionelle) og test udført ved at udføre kode. Validering er processen med at evaluere softwaren efter afslutningen af ​​udviklingsfasen 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 valideringsfaserne er forbundet af kodningsfasen i en V-form. Således kaldes det V-Model.
Der er flere Validering faser i V-modellen:

Enhedstest:

Enhedstestplaner udvikles under moduldesignfasen. Disse enhedstestplaner udføres for at eliminere fejl på kode- eller enhedsniveau.

Integrationstest:

Efter afslutning af enhedstestning udføres integrationstest. Ved integrationstest integreres modulerne, og systemet testes. Integrationstest udføres i arkitekturdesignfasen. Denne test verificerer kommunikationen af ​​moduler indbyrdes.

Systemtest:

Systemtest tester hele applikationen med dens funktionalitet, indbyrdes afhængighed og kommunikation. Den tester de funktionelle og ikke-funktionelle krav til den udviklede applikation.

Brugeraccepttest (UAT):

UAT udføres i et brugermiljø, der ligner produktionsmiljøet. UAT verificerer, at det leverede system opfylder brugerens krav, og at systemet er klar til brug i den virkelige verden.

Designfase:

• Behovsanalyse: Denne fase indeholder detaljeret kommunikation med kunden for at forstå deres krav og forventninger. Denne fase er kendt som Requirement Gathering.
• Systemdesign: Denne fase indeholder systemdesignet og det komplette hardware- og kommunikationsopsætning til udvikling af produktet.
• Arkitektonisk design: Systemdesign er opdelt yderligere i moduler, der optager forskellige funktionaliteter. Dataoverførslen og kommunikationen mellem de interne moduler og med omverdenen (andre systemer) er tydeligt forstået.
• Moduldesign: I denne fase opdeles systemet i små moduler. Det detaljerede design af moduler er specificeret, også kendt som Low-Level Design (LLD).

Testfaser:

• Enhedstest: Enhedstestplaner udvikles under moduldesignfasen. Disse enhedstestplaner udføres for at eliminere fejl på kode- eller enhedsniveau.
• Integrationstest: Efter afslutning af enhedstestning udføres integrationstest. Ved integrationstest integreres modulerne, og systemet testes. Integrationstest udføres i arkitekturdesignfasen. Denne test verificerer kommunikationen af ​​moduler indbyrdes.
• Systemtest: Systemtest tester hele applikationen med dens funktionalitet, indbyrdes afhængighed og kommunikation. Den tester de funktionelle og ikke-funktionelle krav til den udviklede applikation.
• Brugeraccepttest (UAT): UAT udføres i et brugermiljø, der ligner produktionsmiljøet. UAT verificerer, at det leverede system opfylder brugerens krav, og at systemet er klar til brug i den virkelige verden.

Industriel udfordring:

Efterhånden som industrien har udviklet sig, er teknologierne blevet mere komplekse, stadig hurtigere og i konstant forandring, men der er stadig et sæt grundlæggende principper og koncepter, der er lige så anvendelige i dag, som da IT var i sin vorden.

tcp og ip model

• Definer og forfin brugerkrav nøjagtigt.
• Design og byg en applikation i henhold til de autoriserede brugerkrav.
• Bekræft, at den applikation, de havde bygget, overholdt de godkendte forretningskrav.

Vigtigheden af ​​V-modellen

1. Tidlig defektidentifikation

Ved at inkorporere verifikations- og valideringsopgaver i alle stadier af udviklingsprocessen, opmuntrer V-modellen til tidlig testning. Dette sænker omkostningerne og indsatsen, der er nødvendig for at afhjælpe problemer senere i udviklingens livscyklus ved at hjælpe med tidlig opdagelse og løsning af fejl.

2. fastlæggelse af udviklings- og testfaserne

V-modellen indeholder en testfase, der svarer til hvert trin i udviklingsprocessen. Ved at sikre, at test- og udviklingsprocesser er klart kortlagt, fremmer denne klare kortlægning en metodisk og velordnet tilgang til software engineering.

3. Forhindrer Big Bang-test

Testning udføres ofte i slutningen af ​​udviklingens livscyklus i traditionelle udviklingsmodeller, hvilket resulterer i en Big Bang-tilgang, hvor alle testoperationer er fokuseret på én gang. Ved at integrere testaktiviteter i udviklingsprocessen og tilskynde til en mere progressiv og reguleret testtilgang forhindrer V-modellen dette.

4. Forbedrer samarbejdet

På alle niveauer fremmer V-modellen samarbejdet mellem test- og udviklingsteamene. Gennem dette samarbejde bliver projektkrav, designvalg og testmetoder bedre forstået, hvilket forbedrer effektiviteten og effektiviteten af ​​udviklingsprocessen.

5. Forbedret kvalitetssikring

Den overordnede kvalitetssikring forbedres af V-modellen, som inkorporerer testoperationer på alle niveauer. Inden programmet når det endelige implementeringsstadium, sikrer det sig, at det opfylder kravene og gennemgår en streng validerings- og verifikationsproces.

Principper for V-modellen

• Stor til lille: I V-Model udføres test i et hierarkisk perspektiv, for eksempel krav identificeret af projektteamet, oprettelse af High-Level Design og detaljerede designfaser af projektet. Efterhånden som hver af disse faser er gennemført, bliver kravene, de definerer bliver mere og mere raffinerede og detaljerede.
• Data/procesintegritet: Dette princip siger, at et vellykket design af ethvert projekt kræver inkorporering og sammenhæng mellem både data og processer. Proceselementer skal identificeres ved ethvert behov.
• Skalerbarhed: Dette princip siger, at V-Model-konceptet har fleksibiliteten til at rumme ethvert it-projekt uanset dets størrelse, kompleksitet eller varighed.
• Krydshenvisning: En direkte sammenhæng mellem krav og tilsvarende testaktivitet er kendt som krydsreference.

Håndgribelig dokumentation:

Dette princip siger, at hvert projekt skal oprette et dokument. Denne dokumentation er påkrævet og anvendt af både projektudviklingsteamet og supportteamet. Dokumentation bruges til at vedligeholde applikationen, når den er tilgængelig i et produktionsmiljø.

Hvorfor foretrækkes?

• Den er nem at styre på grund af modellens stivhed. Hver fase af V-Model har specifikke leverancer og en gennemgangsproces.
• Proaktiv fejlsporing – det vil sige, at fejl opdages på et tidligt tidspunkt.

Hvornår skal bruges af V-model ?

• Sporbarhed af krav: V-modellen viser sig at være gavnlig i situationer, hvor det er bydende nødvendigt at skabe præcis sporbarhed mellem kravene og deres relaterede testcases.
• Komplekse projekter: V-modellen tilbyder en metodisk måde at styre testaktiviteter og reducere risici relateret til integration og grænsefladeproblemer for projekter med et højt niveau af kompleksitet og indbyrdes afhængighed mellem systemkomponenter.
• Vandfaldslignende projekter : Da V-modellen tilbyder en tilgængelig struktur til at organisere, udføre og overvåge testaktiviteter på alle udviklingsniveauer, er den passende til projekter, der bruger en sekventiel tilgang til udvikling, ligesom vandfaldsmodellen.
• Sikkerhedskritiske systemer: Disse systemer bruges i fly-, bil- og sundhedsindustrien. De lægger stor vægt på rigide verifikations- og valideringsprocedurer, som er med til at sikre, at væsentlige systemkrav er opfyldt, og at mulige risici findes og elimineres tidligt i udviklingsprocessen.

Fordele af V-model

• Dette er en meget disciplineret model, og faserne afsluttes én ad gangen.
• V-Model bruges til små projekter, hvor projektkravene er klare.
• Enkel og nem at forstå og bruge.
• Denne model fokuserer på verifikations- og valideringsaktiviteter tidligt i livscyklussen og øger derved sandsynligheden for at bygge et fejlfrit produkt af god kvalitet.
• Det gør det muligt for projektledelsen at spore fremskridt præcist.
• Klar og struktureret proces: V-modellen giver en klar og struktureret proces til softwareudvikling , hvilket gør det nemmere at forstå og følge.
• Vægt på test: V-modellen lægger stor vægt på test, hvilket er med til at sikre kvaliteten og pålideligheden af ​​softwaren.
• Forbedret sporbarhed: V-modellen giver en klar forbindelse mellem kravene og det endelige produkt, hvilket gør det nemmere at spore og administrere ændringer i softwaren.
• Bedre kommunikation: V-modellens klare struktur er med til at forbedre kommunikationen mellem kunden og udviklingsteamet.

Ulemper ved V-Model

• Høj risiko og usikkerhed.
• Det er ikke godt til komplekse og objektorienterede projekter.
• Den er ikke egnet til projekter, hvor kravene ikke er klare og indeholder en høj risiko for ændringer.
• Denne model understøtter ikke iteration af faser.
• Den håndterer ikke let samtidige hændelser.
• Ufleksibilitet: V-modellen er en lineær og sekventiel model, som kan gøre det vanskeligt at tilpasse sig skiftende krav eller uventede hændelser.
• Tidskrævende: V-modellen kan være tidskrævende, da den kræver meget dokumentation og test.
• Overdreven afhængighed af dokumentation: V-modellen lægger stor vægt på dokumentation, hvilket kan føre til overdreven afhængighed af dokumentation på bekostning af egentligt udviklingsarbejde.

Konklusion

En videnskabelig og organiseret tilgang til Software Development Life Cycle (SDLC) leveres af Software Engineering V-Model. Teamets ekspertise med den valgte metode, de unikke egenskaber ved projektet og arten af ​​kravene bør alle tages i betragtning, når der vælges SDLC-modeller, inklusive V-modellen.

Opslagsbog:

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