Meny

SDLC (programvareutvikling livssyklus) faser, metoder, prosesser og modeller

  • Hoved
  • Annen
  • SDLC (programvareutvikling livssyklus) faser, metoder, prosesser og modeller

sdlc phases

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er programvareutviklings livssyklus (SDLC)? Lær SDLC-faser, metoder, prosesser og modeller

Software Development Life Cycle (SDLC) er et rammeverk som definerer trinnene som er involvert i utviklingen av programvare i hver fase. Den dekker detaljplanen for å bygge, distribuere og vedlikeholde programvaren.

SDLC definerer hele utviklingssyklusen, dvs. alle oppgavene som er involvert i planlegging, oppretting, testing og distribusjon av et programvareprodukt.

Programvareutvikling livssyklus SDLC

Hva du vil lære:

Programvareutvikling livssyklusprosess

SDLC er en prosess som definerer de ulike trinnene som er involvert i utviklingen av programvare for å levere et produkt av høy kvalitet. SDLC-trinn dekker den komplette livssyklusen til en programvare, dvs. fra begynnelse til pensjonering av produktet.

Overholdelse av SDLC-prosessen fører til utvikling av programvaren på en systematisk og disiplinert måte.

Hensikt:

Formålet med SDLC er å levere et produkt av høy kvalitet som er i samsvar med kundens krav.

SDLC har definert sine faser som kravinnsamling, design, koding, testing og vedlikehold. Det er viktig å følge fasene for å levere produktet på en systematisk måte.

For eksempel, Det må utvikles en programvare og et team er delt i å jobbe med en funksjon av produktet og får jobbe som de vil. En av utviklerne bestemmer seg for å designe først, mens den andre bestemmer seg for å kode først og den andre på dokumentasjonsdelen.

Dette vil føre til prosjektfeil på grunn av hvilket det er nødvendig å ha god kunnskap og forståelse blant teammedlemmene for å levere et forventet produkt.

SDLC-syklus

SDLC Cycle representerer prosessen med å utvikle programvare.

Nedenfor er den diagrammatiske representasjonen av SDLC-syklusen:

SDLC-syklus

SDLC-faser

Nedenfor er de forskjellige fasene:

  • Kravsamling og analyse
  • Design
  • Implementering eller koding
  • Testing
  • Utplassering
  • Vedlikehold

# 1) Kravsamling og analyse

I løpet av denne fasen samles all relevant informasjon fra kunden for å utvikle et produkt i henhold til deres forventning. Uklarheter må bare løses i denne fasen.

Forretningsanalytiker og prosjektleder satte opp et møte med kunden for å samle all informasjon som hva kunden ønsker å bygge, hvem som skal være sluttbruker, hva er formålet med produktet. Før du bygger et produkt, er en kjerneforståelse eller kunnskap om produktet veldig viktig.

For eksempel, En kunde ønsker å ha en applikasjon som involverer pengetransaksjoner. I dette tilfellet må kravet være klart som hva slags transaksjoner som vil bli gjort, hvordan det vil bli gjort, i hvilken valuta det vil bli gjort, etc.

Når kravinnhentingen er gjort, blir en analyse gjort for å kontrollere muligheten for utvikling av et produkt. I tilfelle tvetydighet, blir en samtale satt opp for videre diskusjon.

Når kravet er klart forstått, opprettes SRS-dokumentet (Software Requirement Specification). Dette dokumentet skal være grundig forstått av utviklerne og bør også gjennomgås av kunden for fremtidig referanse.

# 2) Design

I denne fasen blir kravet samlet i SRS-dokumentet brukt som en input- og programvarearkitektur som brukes for å implementere systemutvikling.

# 3) Implementering eller koding

Implementering / koding starter når utvikleren får Design-dokumentet. Programvaredesignet oversettes til kildekode. Alle komponentene i programvaren er implementert i denne fasen.

hvordan du legger til et heltall i en matrise i java

# 4) Testing

Testingen starter når kodingen er fullført og modulene er utgitt for testing. I denne fasen testes den utviklede programvaren grundig, og eventuelle mangler som er funnet, tildeles utviklere for å få dem løst.

Test på nytt, regresjonstesting utføres til det tidspunktet hvor programvaren er i samsvar med kundens forventning. Testere henviser til SRS-dokument for å sikre at programvaren er i samsvar med kundens standard.

# 5) Implementering

Når produktet er testet, distribueres det i produksjonsmiljøet eller først UAT (brukertilsynstesting) gjøres avhengig av kundens forventning.

I tilfelle UAT opprettes en kopi av produksjonsmiljøet, og kunden sammen med utviklerne gjør testingen. Hvis kunden finner applikasjonen som forventet, leveres kunden for å logge av.

# 6) Vedlikehold

Etter distribusjon av et produkt i produksjonsmiljøet, blir vedlikehold av produktet, dvs. hvis et problem dukker opp og må løses eller forbedringer skal gjøres, ivaretatt av utviklerne.

Programvareutvikling livssyklusmodeller

En livssyklusmodell for programvare er en beskrivende fremstilling av programvareutviklingssyklusen. SDLC-modeller kan ha en annen tilnærming, men de grunnleggende fasene og aktiviteten forblir den samme for alle modellene.

# 1) Fossmodell

Fossmodell er den aller første modellen som brukes i SDLC. Det er også kjent som den lineære sekvensielle modellen.

I denne modellen er utfallet av en fase inngangen til neste fase. Utviklingen av neste fase starter bare når den forrige fasen er fullført.

  • For det første gjøres kravinnsamling og analyse. Når kravet er fryset, er det bare Systemdesign som kan starte. Her er SRS-dokumentet som er laget, utdata for kravfasen, og det fungerer som en inngang for systemdesignet.
  • I systemdesign programvarearkitektur og design opprettes dokumenter som fungerer som input for neste fase, dvs. implementering og koding.
  • I implementeringsfasen gjøres koding og programvaren som er utviklet er inngangen til neste fase, dvs. testing.
  • I testfasen testes den utviklede koden grundig for å oppdage manglene i programvaren. Mangler blir logget inn i verktøyet for feilsporing og testes på nytt når de er løst. Feillogging, omprøving, regresjonstesting fortsetter til den tiden programvaren er i live-tilstand.
  • I distribusjonsfasen flyttes den utviklede koden i produksjon etter at kunden har avmeldt.
  • Eventuelle problemer i produksjonsmiljøet løses av utviklerne som kommer under vedlikehold.

Fossmodell

Fordeler med fossemodellen:

  • Fossemodell er den enkle modellen som lett kan forstås og er den der alle fasene gjøres trinn for trinn.
  • Leveranser av hver fase er veldefinerte, og dette fører til ingen kompleksitet og gjør prosjektet enkelt håndterbart.

Ulemper ved fossemodellen:

  • Fossemodellen er tidkrevende og kan ikke brukes i prosjekter med kort varighet. I denne modellen kan en ny fase ikke startes før den pågående fasen er fullført.
  • Fossemodell kan ikke brukes til prosjekter som har usikre krav eller hvor kravet fortsetter å endres, siden denne modellen forventer at kravet vil være klart i selve kravinnsamlings- og analysefasen, og enhver endring i de senere stadiene vil føre til høyere kostnader som endringer vil være påkrevd i alle faser.

# 2) V-formet modell

V- modell er også kjent som Verification and Validation Model. I denne modellen går bekreftelse og validering hånd i hånd, dvs. utvikling og testing går parallelt. V-modellen og fossemodellen er de samme bortsett fra at testplanlegging og testing starter på et tidlig stadium i V-Model.

V-formet modell

a) Bekreftelsesfase:

(i) Kravsanalyse:

I denne fasen blir all nødvendig informasjon samlet og analysert. Verifikasjonsaktiviteter inkluderer gjennomgang av kravene.

(ii) Systemdesign:

Når kravet er klart, er et system designet, dvs. arkitektur, komponenter i produktet blir opprettet og dokumentert i et designdokument.

(iii) Design på høyt nivå:

Design på høyt nivå definerer arkitekturen / utformingen av moduler. Den definerer funksjonaliteten mellom de to modulene.

(iv) Lavt nivå design:

Lavt nivå Design definerer arkitekturen / utformingen av individuelle komponenter.

(v) Koding:

Kodeutvikling gjøres i denne fasen.

b) Valideringsfase:

(i) Enhetstesting:

Enhetstesting utføres ved hjelp av enhetstesttilfellene som er utformet og gjøres i lavnivå designfasen. Enhetstesting utføres av utvikleren selv. Det utføres på individuelle komponenter som fører til tidlig deteksjon av feil.

(ii) Integrasjonstesting:

Integrasjonstesting utføres ved hjelp av integrasjonstesttilfeller i designfasen på høyt nivå. Integrasjonstesting er testingen som gjøres på integrerte moduler. Det utføres av testere.

(iii) Systemtesting:

Systemtesting utføres i systemdesignfasen. I denne fasen blir hele systemet testet, dvs. hele systemfunksjonaliteten blir testet.

(iv) Akseptprøving:

Akseptprøving er knyttet til kravanalysefasen og gjøres i kundens miljø.

Fordeler med V - Modell:

  • Det er en enkel og lett forståelig modell.
  • V – modelltilnærming er bra for mindre prosjekter der kravet er definert og det fryser tidlig.
  • Det er en systematisk og disiplinert modell som resulterer i et produkt av høy kvalitet.

Ulemper med V-Model:

  • V-formet modell er ikke bra for pågående prosjekter.
  • Kravendring på et senere tidspunkt vil koste for høyt.

# 3) Prototypemodell

Prototypemodellen er en modell der prototypen er utviklet før selve programvaren.

Prototypemodeller har begrensede funksjonelle evner og ineffektiv ytelse sammenlignet med den faktiske programvaren. Dummy-funksjoner brukes til å lage prototyper. Dette er en verdifull mekanisme for å forstå kundenes behov.

Programvare prototyper er bygget før den faktiske programvaren for å få verdifull tilbakemelding fra kunden. Tilbakemeldinger er implementert og prototypen blir gjennomgått av kunden for eventuelle endringer. Denne prosessen fortsetter til modellen godtas av kunden.

Prototypemodell

Når kravinnhentingen er gjort, opprettes den raske designen og prototypen som presenteres for kunden for evaluering blir bygget.

Kundefeedback og det raffinerte kravet brukes til å modifisere prototypen og blir igjen presentert for kunden for evaluering. Når kunden godkjenner prototypen, brukes den som et krav for å bygge den faktiske programvaren. Den faktiske programvaren er laget ved hjelp av tilnærmingen til Waterfall-modellen.

Fordeler med prototypemodell:

  • Prototypemodell reduserer kostnadene og tiden for utvikling ettersom manglene er funnet mye tidligere.
  • Manglende funksjon eller funksjonalitet eller en endring i kravet kan identifiseres i evalueringsfasen og kan implementeres i den raffinerte prototypen.
  • Involvering av en kunde fra første fase reduserer enhver forvirring i kravet eller forståelsen av funksjonalitet.

Ulemper med prototypemodell:

  • Siden kunden er involvert i hver fase, kan kunden endre kravet til sluttproduktet, noe som øker kompleksiteten i omfanget og kan øke leveringstiden til produktet.

# 4) Spiralmodell

Spiralmodellen inkluderer iterativ og prototype tilnærming.

Spiralmodelfasene følges i iterasjonene. Sløyfene i modellen representerer fasen i SDLC-prosessen, dvs. den innerste sløyfen er kravsamling og analyse som følger planlegging, risikoanalyse, utvikling og evaluering. Neste løkke er Designing etterfulgt av Implementering og deretter testing.

Spiral Model har fire faser:

  • Planlegger
  • Risikoanalyse
  • Ingeniørfag
  • Evaluering

Spiral Model

(i) Planlegging:

Planleggingsfasen inkluderer kravinnsamling der all nødvendig informasjon er samlet fra kunden og er dokumentert. Spesifikasjonsdokument for programvarekrav opprettes for neste fase.

(ii) Risikoanalyse:

I denne fasen velges den beste løsningen for de involverte risikoene, og analyse gjøres ved å bygge prototypen.

For eksempel , risikoen ved tilgang til dataene fra en ekstern database kan være at datatilgangshastigheten kan være for treg. Risikoen kan løses ved å bygge en prototype av delsystemet for tilgang til data.

(iii) Ingeniørfag:

Når risikoanalysen er gjort, blir koding og testing utført.

(iv) Evaluering:

Kunden evaluerer det utviklede systemet og planlegger for neste iterasjon.

Fordeler med spiralmodell:

  • Risikoanalyse gjøres mye ved hjelp av prototypemodellene.
  • Enhver forbedring eller endring i funksjonaliteten kan gjøres i neste iterasjon.

Ulemper med spiralmodell:

  • Spiralmodellen er best egnet for store prosjekter.
  • Kostnaden kan være høy da det kan ta et stort antall iterasjoner som kan føre til lang tid å nå det endelige produktet.

# 5) Iterativ inkrementell modell

Den iterative inkrementelle modellen deler produktet i små biter.

For eksempel , Funksjon som skal utvikles i iterasjonen blir bestemt og implementert. Hver iterasjon går gjennom fasene, nemlig Kravsanalyse, design, koding og testing. Detaljplanlegging er ikke nødvendig i iterasjoner.

Når iterasjonen er fullført, verifiseres et produkt og leveres til kunden for evaluering og tilbakemelding. Kundens tilbakemeldinger implementeres i neste iterasjon sammen med den nye funksjonen.

Derfor øker produktene når det gjelder funksjoner, og når iterasjonene er fullført, inneholder den endelige versjonen alle produktets funksjoner.

Faser av Iterativ og inkrementell utviklingsmodell:

  • Oppstartsfase
  • Utdypningsfase
  • Byggefase
  • Overgangsfase

(i) Startfase:

Oppstartsfasen inkluderer kravet og omfanget av prosjektet.

(ii) Utdypningsfase:

I utførelsesfasen leveres arbeidsarkitekturen til et produkt som dekker risikoen identifisert i oppstartsfasen og også oppfyller de ikke-funksjonelle kravene.

(iii) Byggefase:

I byggefasen fylles arkitekturen ut med koden som er klar til å distribueres og opprettes gjennom analyse, design, implementering og testing av funksjonskravet.

(iv) Overgangsfase:

I overgangsfasen distribueres produktet i produksjonsmiljøet.

Fordeler med Iterativ og inkrementell modell:

  • Enhver endring i kravet kan enkelt gjøres og vil ikke koste, da det er et omfang å innlemme det nye kravet i neste iterasjon.
  • Risiko analyseres og identifiseres i iterasjonene.
  • Mangler oppdages på et tidlig stadium.
  • Ettersom produktet er delt inn i mindre biter, er det enkelt å administrere produktet.

Ulemper av Iterativ og inkrementell modell:

  • Fullstendig krav og forståelse av et produkt kreves for å bryte ned og bygge trinnvis.

# 6) Big Bang Model

Big Bang Model har ingen definert prosess. Penger og innsats blir satt sammen ettersom input og output kommer som et utviklet produkt som kanskje er eller ikke er det samme som det kunden trenger.

Big Bang Model krever ikke mye planlegging og planlegging. Utvikleren gjør kravanalysen og kodingen og utvikler produktet i henhold til hans forståelse. Denne modellen brukes kun til små prosjekter. Det er ikke noe testteam og ingen formell testing er gjort, og dette kan være en årsak til at prosjektet mislyktes.

Fordeler av Big Bang Model:

  • Det er en veldig enkel modell.
  • Mindre planlegging og planlegging er nødvendig.
  • Utvikleren har fleksibiliteten til å bygge programvaren av seg selv.

Ulemper ved Big Bang-modellen:

  • Big Bang-modeller kan ikke brukes til store, pågående og komplekse prosjekter.
  • Høy risiko og usikkerhet.

# 7) Agil modell

Agile Model er en kombinasjon av den iterative og inkrementelle modellen. Denne modellen fokuserer mer på fleksibilitet mens du utvikler et produkt i stedet for på kravet.

I Agile blir et produkt delt inn i små trinnvise bygg. Det er ikke utviklet som et komplett produkt på en gang. Hver byggetrinn når det gjelder funksjoner. Neste bygg er bygget på tidligere funksjonalitet.

I smidige betegnelser blir betegnet som spurter. Hver sprint varer i 2-4 uker. På slutten av hver sprint bekrefter produkteieren produktet, og etter godkjenning blir det levert til kunden.

Kundenes tilbakemeldinger blir tatt for forbedring, og hans forslag og forbedringer blir jobbet med i neste sprint. Testing utføres i hver sprint for å minimere risikoen for feil.

Agil modell

Fordeler med smidig modell:

  • Det gir mer fleksibilitet til å tilpasse seg endringene.
  • Den nye funksjonen kan enkelt legges til.
  • Kundetilfredshet da tilbakemeldingene og forslagene tas på hvert trinn.

Ulemper:

  • Mangel på dokumentasjon.
  • Agile trenger erfarne og dyktige ressurser.
  • Hvis en kunde ikke er klar over hvor nøyaktig de vil at produktet skal være, vil prosjektet mislykkes.

Konklusjon

Overholdelse av en passende livssyklus er veldig viktig for en vellykket gjennomføring av prosjektet. Dette gjør ledelsen lettere.

Ulike programvareutvikling livssyklusmodeller har sine egne fordeler og ulemper. Den beste modellen for ethvert prosjekt kan bestemmes av faktorene som krav (enten det er klart eller uklart), systemkompleksitet, prosjektstørrelse, kostnad, ferdighetsbegrensning, etc.

Eksempel, i tilfelle et uklart krav, er det best å bruke Spiral og Agile-modeller, da den nødvendige endringen lett kan tilpasses når som helst.

Fossmodell er en grunnleggende modell, og alle de andre SDLC-modellene er bare basert på det.

Håper du ville ha fått enorm kunnskap om SDLC.

Anbefalt lesing

^