V-modellen er en type SDLC-modell hvor prosessen utføres sekvensielt i en V-form. Det er også kjent som verifikasjons- og valideringsmodellen. Den er basert på assosiasjonen av en testfase for hvert tilsvarende utviklingstrinn. Utviklingen av hvert trinn er direkte knyttet til testfasen. Neste fase starter først etter fullføring av forrige fase, dvs. for hver utviklingsaktivitet er det en testaktivitet som tilsvarer den.

Innholdsfortegnelse

• V-modelldesign
• Viktigheten av V-modellen
• Prinsipper for V-modell
• Når skal man bruke V-modellen?
• Fordeler med V-modell
• Ulemper med V-modell
• Konklusjon

V-modellen er en programvareutviklings livssyklus (SDLC) modell som gir en systematisk og visuell representasjon av programvareutviklingsprosessen. Den er basert på ideen om en V-form, med de to bena til V-en som representerer progresjonen til programvareutviklingsprosess fra kravsamling og analyse til design, implementering, testing og vedlikehold.

V-modelldesign

1. Kravsamling og analyse : Den første fasen av V-modellen er kravinnsamlings- og analysefasen, hvor kundens krav til programvaren samles og analyseres for å bestemme omfanget av prosjektet.
2. Design: I designfasen utvikles programvarearkitekturen og designen, inkludert høynivådesign og detaljdesign.
3. Gjennomføring: I implementeringsfasen bygges programvaren basert på designet.
4. Testing: I testfasen testes programvaren for å sikre at den oppfyller kundens krav og er av høy kvalitet.
5. Utplassering: I utrullingsfasen distribueres programvaren og tas i bruk.
6. Vedlikehold: I vedlikeholdsfasen vedlikeholdes programvaren for å sikre at den fortsetter å møte kundens behov og forventninger.
7. V-modellen brukes ofte i sikkerhet: kritiske systemer, som romfart og forsvarssystemer, på grunn av dens vekt på grundig testing og dens evne til å tydelig definere trinnene som er involvert i programvareutviklingsprosessen.

SDLC V-modell

Følgende illustrasjon viser de forskjellige fasene i en V-modell av SDLC.

Bekreftelse Faser :

Det innebærer en statisk analyseteknikk (gjennomgang) utført uten å kjøre kode. Det er prosessen med evaluering av produktutviklingsfasen for å finne ut om spesifiserte krav er oppfylt.

Det er flere verifikasjonsfaser i V-modellen:

Analyse av forretningsbehov:

Dette er det første trinnet i utpekingen av utviklingssyklusen der produktkrav må kureres fra kundens perspektiv. i disse fasene inkluderer riktig kommunikasjon med kunden for å forstå kravene til kundene. Dette er de svært viktige aktivitetene som må håndteres på riktig måte, da kunder som oftest ikke vet nøyaktig hva de vil ha, og de er ikke sikre på det på det tidspunktet, da bruker vi en aksept test design planlegging som gjøres på tidspunktet for forretningskravet vil bli brukt som en input for akseptansetesting.

System design:

Design av systemet vil starte når det generelle vi er klare med produktkravene, og deretter trenger å designe systemet fullstendig. Denne forståelsen vil være i begynnelsen av komplett under produktutviklingsprosessen. disse vil være fordelaktige for fremtidig gjennomføring av testcases.

Arkitektonisk design:

I dette stadiet blir arkitektoniske spesifikasjoner forstått og utformet. Vanligvis legges det ut flere tekniske tilnærminger, og det ultimate valget tas etter å ha vurdert både teknisk og økonomisk levedyktighet. Systemarkitekturen er videre delt inn i moduler som hver håndterer en distinkt funksjon. Et annet navn for dette er High-Level Design (HLD).

På dette tidspunktet er utveksling av data og kommunikasjon mellom interne moduler og eksterne systemer godt forstått og definert. I denne fasen kan integrasjonstester opprettes og dokumenteres ved hjelp av informasjonen som er gitt.

Moduldesign:

Denne fasen, kjent som Low-Level Design (LLD), spesifiserer den omfattende interne designen for hver systemmodul. Kompatibilitet mellom designet og andre eksterne systemer samt andre moduler i systemarkitekturen er avgjørende. Enhetstester er en avgjørende komponent i enhver utviklingsprosess siden de hjelper til med å identifisere og utrydde de fleste feil og mangler på et tidlig stadium. Basert på de interne moduldesignene kan disse enhetstestene nå opprettes.

Kodefase:

java intervju spørsmål

Kodingsteget innebærer å skrive koden for systemmodulene som ble opprettet under designfasen. System- og arkitekturkravene brukes til å bestemme hvilket programmeringsspråk som er mest hensiktsmessig.

Kodestandardene og -prinsippene følges ved utføring av kodingen. Før den endelige byggingen sjekkes inn i depotet, gjennomgår koden mange kodegjennomganger og er optimert for optimal ytelse.

Validering Faser :

Det involverer dynamiske analyseteknikker (funksjonelle og ikke-funksjonelle), og testing utført ved å kjøre kode. Validering er prosessen med å evaluere programvaren etter fullføring av utviklingsfasen for å avgjøre om programvaren oppfyller kundens forventninger og krav.

Så, V-Model inneholder verifikasjonsfaser på den ene siden av valideringsfasene på den andre siden. Verifikasjons- og valideringsfasene er forbundet med kodingsfasen i en V-form. Dermed kalles den V-Model.
Det er flere Validering faser i V-modellen:

Enhetstesting:

Enhetstestplaner utvikles i moduldesignfasen. Disse enhetstestplanene utføres for å eliminere feil på kode- eller enhetsnivå.

Integrasjonstesting:

Etter fullført enhetstesting utføres integrasjonstesting. Ved integrasjonstesting integreres modulene og systemet testes. Integrasjonstesting utføres i arkitekturdesignfasen. Denne testen verifiserer kommunikasjonen av moduler seg imellom.

Systemtesting:

Systemtesting tester hele applikasjonen med funksjonalitet, gjensidig avhengighet og kommunikasjon. Den tester de funksjonelle og ikke-funksjonelle kravene til den utviklede applikasjonen.

User Acceptance Testing (UAT):

UAT utføres i et brukermiljø som ligner produksjonsmiljøet. UAT verifiserer at det leverte systemet oppfyller brukerens krav og at systemet er klart til bruk i den virkelige verden.

Designfase:

• Kravanalyse: Denne fasen inneholder detaljert kommunikasjon med kunden for å forstå deres krav og forventninger. Dette stadiet er kjent som Requirement Gathering.
• System design: Denne fasen inneholder systemdesignet og det komplette maskinvare- og kommunikasjonsoppsettet for utvikling av produktet.
• Arkitektonisk design: Systemdesign deles ytterligere ned i moduler som tar opp ulike funksjoner. Dataoverføringen og kommunikasjonen mellom de interne modulene og med omverdenen (andre systemer) er tydelig forstått.
• Moduldesign: I denne fasen brytes systemet ned i små moduler. Den detaljerte utformingen av moduler er spesifisert, også kjent som Low-Level Design (LLD).

Testfaser:

• Enhetstesting: Enhetstestplaner utvikles i moduldesignfasen. Disse enhetstestplanene utføres for å eliminere feil på kode- eller enhetsnivå.
• Integrasjonstesting: Etter fullført enhetstesting utføres integrasjonstesting. Ved integrasjonstesting integreres modulene, og systemet testes. Integrasjonstesting utføres i arkitekturdesignfasen. Denne testen verifiserer kommunikasjonen av moduler seg imellom.
• Systemtesting: Systemtesting tester hele applikasjonen med funksjonalitet, gjensidig avhengighet og kommunikasjon. Den tester de funksjonelle og ikke-funksjonelle kravene til den utviklede applikasjonen.
• User Acceptance Testing (UAT): UAT utføres i et brukermiljø som ligner produksjonsmiljøet. UAT verifiserer at det leverte systemet oppfyller brukerens krav og at systemet er klart til bruk i den virkelige verden.

Industriell utfordring:

Etter hvert som industrien har utviklet seg, har teknologiene blitt mer komplekse, stadig raskere og i stadig endring, men det gjenstår et sett med grunnleggende prinsipper og konsepter som er like anvendelige i dag som da IT var i sin spede begynnelse.

når starter q2

• Definer og avgrens brukerkrav nøyaktig.
• Design og bygg en applikasjon i henhold til autoriserte brukerkrav.
• Bekreft at applikasjonen de hadde bygget overholdt de autoriserte forretningskravene.

Viktigheten av V-modellen

1. Tidlig defektidentifikasjon

Ved å inkorporere verifikasjons- og valideringsoppgaver i alle trinn i utviklingsprosessen, oppmuntrer V-modellen til tidlig testing. Dette reduserer kostnadene og innsatsen som trengs for å avhjelpe problemer senere i utviklingens livssyklus ved å hjelpe til med tidlig oppdagelse og løsning av feil.

2. bestemme fasene for utvikling og testing

V-modellen inneholder en testfase som tilsvarer hvert trinn i utviklingsprosessen. Ved å sikre at test- og utviklingsprosesser er tydelig kartlagt, fremmer denne klare kartleggingen en metodisk og ryddig tilnærming til programvareutvikling.

3. Forhindrer Big Bang-testing

Testing utføres ofte helt på slutten av utviklingslivssyklusen i tradisjonelle utviklingsmodeller, noe som resulterer i en Big Bang-tilnærming der alle testoperasjoner er fokusert på en gang. Ved å integrere testaktiviteter i utviklingsprosessen og oppmuntre til en mer progressiv og regulert testmetode, forhindrer V-modellen dette.

4. Forbedrer samarbeidet

På alle nivåer fremmer V-modellen samarbeid mellom test- og utviklingsteamene. Gjennom dette samarbeidet blir prosjektkrav, designvalg og testmetodikk bedre forstått, noe som forbedrer effektiviteten og effektiviteten til utviklingsprosessen.

5. Forbedret kvalitetssikring

Den generelle kvalitetssikringen er forbedret av V-modellen, som inkluderer testoperasjoner på alle nivåer. Før programmet når det endelige distribusjonsstadiet, sørger det for at det tilfredsstiller kravene og går gjennom en streng validerings- og verifiseringsprosess.

Prinsipper for V-modell

• Stor til liten: I V-Model utføres testing i et hierarkisk perspektiv, for eksempel krav identifisert av prosjektteamet, skaper High-Level Design og detaljerte designfaser av prosjektet. Som hver av disse fasene er fullført kravene, de definerer blir mer og mer raffinert og detaljert.
• Data/prosessintegritet: Dette prinsippet sier at vellykket design av ethvert prosjekt krever inkorporering og sammenheng mellom både data og prosesser. Prosesselementer må identifiseres ved hvert krav.
• Skalerbarhet: Dette prinsippet sier at V-Model-konseptet har fleksibiliteten til å imøtekomme ethvert IT-prosjekt uavhengig av størrelse, kompleksitet eller varighet.
• Kryssreferanser: En direkte korrelasjon mellom krav og tilsvarende testaktivitet er kjent som kryssreferanser.

Materiell dokumentasjon:

Dette prinsippet sier at hvert prosjekt må lage et dokument. Denne dokumentasjonen kreves og brukes av både prosjektutviklingsteamet og støtteteamet. Dokumentasjon brukes til å vedlikeholde applikasjonen når den er tilgjengelig i et produksjonsmiljø.

Hvorfor foretrukket?

• Det er enkelt å administrere på grunn av modellens stivhet. Hver fase av V-Model har spesifikke leveranser og en gjennomgangsprosess.
• Proaktiv defektsporing – det vil si at feil oppdages på et tidlig stadium.

Når du skal bruke av V-modell ?

• Sporbarhet av krav: V-modellen viser seg å være nyttig i situasjoner der det er viktig å skape presis sporbarhet mellom kravene og deres relaterte testtilfeller.
• Komplekse prosjekter: V-modellen tilbyr en metodisk måte å administrere testaktiviteter og redusere risiko knyttet til integrasjons- og grensesnittproblemer for prosjekter med høy grad av kompleksitet og gjensidig avhengighet mellom systemkomponenter.
• Fosslignende prosjekter : Siden V-modellen tilbyr en tilgjengelig struktur for organisering, gjennomføring og overvåking av testaktiviteter på alle utviklingsnivåer, er den passende for prosjekter som bruker en sekvensiell tilnærming til utvikling, omtrent som fossefallsmodellen.
• Sikkerhetskritiske systemer: Disse systemene brukes i fly-, bil- og helseindustrien. De legger stor vekt på rigide verifikasjons- og valideringsprosedyrer, som bidrar til å garantere at essensielle systemkrav oppfylles og at mulige risikoer blir funnet og eliminert tidlig i utviklingsprosessen.

Fordeler av V-modellen

• Dette er en svært disiplinert modell og faser fullføres én om gangen.
• V-Model brukes til små prosjekter hvor prosjektkravene er klare.
• Enkel og lett å forstå og bruke.
• Denne modellen fokuserer på verifikasjons- og valideringsaktiviteter tidlig i livssyklusen og øker dermed sannsynligheten for å bygge et feilfritt produkt av god kvalitet.
• Den gjør det mulig for prosjektledelsen å spore fremdriften nøyaktig.
• Klar og strukturert prosess: V-modellen gir en tydelig og strukturert prosess for programvare utvikling , noe som gjør det lettere å forstå og følge.
• Vekt på testing: V-modellen legger stor vekt på testing, noe som bidrar til å sikre kvaliteten og påliteligheten til programvaren.
• Forbedret sporbarhet: V-modellen gir en klar kobling mellom kravene og sluttproduktet, noe som gjør det lettere å spore og administrere endringer i programvaren.
• Bedre kommunikasjon: Den klare strukturen til V-modellen bidrar til å forbedre kommunikasjonen mellom kunden og utviklingsteamet.

Ulemper med V-modell

• Høy risiko og usikkerhet.
• Det er ikke bra for komplekse og objektorienterte prosjekter.
• Den egner seg ikke for prosjekter hvor kravene ikke er klare og inneholder høy risiko for endring.
• Denne modellen støtter ikke iterasjon av faser.
• Den håndterer ikke lett samtidige hendelser.
• Ufleksibilitet: V-modellen er en lineær og sekvensiell modell, som kan gjøre det vanskelig å tilpasse seg endrede krav eller uventede hendelser.
• Tidkrevende: V-modellen kan være tidkrevende, da den krever mye dokumentasjon og testing.
• Overavhengighet av dokumentasjon: V-modellen legger stor vekt på dokumentasjon, noe som kan føre til overdreven avhengighet av dokumentasjon på bekostning av faktisk utviklingsarbeid.

Konklusjon

En vitenskapelig og organisert tilnærming til Software Development Life Cycle (SDLC) leveres av Software Engineering V-Model. Teamets ekspertise med den valgte metodikken, de unike egenskapene til prosjektet og arten av kravene bør alle tas i betraktning når du velger SDLC-modeller, inkludert V-modellen.

Oppslagsverk:

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