Software Development life cycle (SDLC) er en åndelig modell som brukes i prosjektledelse som definerer stadiene som inkluderes i et informasjonssystemutviklingsprosjekt, fra en innledende mulighetsstudie til vedlikehold av den fullførte applikasjonen.

Det er forskjellige livssyklusmodeller for programvareutvikling spesifisere og designe, som følges under programvareutviklingsfasen. Disse modellene kalles også ' Prosessmodeller for programvareutvikling .' Hver prosessmodell følger en serie av faser som er unike for sin type for å sikre suksess i trinnet med programvareutvikling.

Her er noen viktige faser av SDLCs livssyklus:

Fossmodell

Fossen er en universelt akseptert SDLC-modell. I denne metoden er hele prosessen med programvareutvikling delt inn i ulike faser.

string java erstatning

Fossmodellen er en kontinuerlig programvareutviklingsmodell der utviklingen blir sett på som flyter jevnt nedover (som en foss) gjennom trinnene kravanalyse, design, implementering, testing (validering), integrasjon og vedlikehold.

Lineær rekkefølge av aktiviteter har noen betydelige konsekvenser. For det første, for å identifisere slutten av en fase og begynnelsen av den neste, må noen sertifiseringsteknikker brukes på slutten av hvert trinn. Noe verifisering og validering betyr vanligvis at resultatet av trinnet er i samsvar med dets input (som er resultatet fra forrige trinn), og at resultatet fra trinnet er i samsvar med de generelle kravene til systemet.

RAD-modell

RAD eller Rapid Application Development prosess er en adopsjon av fossefallmodellen; den tar sikte på å utvikle programvare i løpet av kort tid. RAD-modellen er basert på konseptet om at et bedre system kan utvikles på kortere tid ved å bruke fokusgrupper for å samle systemkrav.

• Forretningsmodellering
• Datamodellering
• Prosessmodellering
• Applikasjonsgenerering
• Testing og omsetning

Spiral modell

Spiralmodellen er en risikodrevet prosessmodell . Denne SDLC-modellen hjelper gruppen med å ta i bruk elementer av en eller flere prosessmodeller som en foss, inkrementell, foss, osv. Spiralteknikken er en kombinasjon av rask prototyping og samtidighet i design- og utviklingsaktiviteter.

Hver syklus i spiralen begynner med identifisering av mål for den syklusen, de forskjellige alternativene som er mulige for å nå målene, og begrensningene som finnes. Dette er den første kvadranten i syklusen (øvre venstre kvadrant).

Det neste trinnet i syklusen er å evaluere disse ulike alternativene basert på målene og begrensningene. Fokuset for evaluering i dette trinnet er basert på risikooppfatningen for prosjektet.

java streng til heltall konvertering

Neste steg er å utvikle strategier som løser usikkerhet og risiko. Dette trinnet kan involvere aktiviteter som benchmarking, simulering og prototyping.

V-modell

I denne typen SDLC-modelltesting og utviklingen planlegges trinnet parallelt. Så det er verifikasjonsfaser på siden og valideringsfasen på den andre siden. V-Model blir med etter kodingsfase.

java-forekomst av

Inkrementell modell

Den inkrementelle modellen er ikke en egen modell. Det er nødvendigvis en serie med fossefallssykluser. Kravene deles inn i grupper ved oppstart av prosjektet. For hver gruppe følges SDLC-modellen for å utvikle programvare. SDLC-prosessen gjentas, med hver utgivelse som legger til mer funksjonalitet til alle krav er oppfylt. I denne metoden fungerer hver syklus som vedlikeholdsfasen for forrige programvareversjon. Endring av den inkrementelle modellen gjør at utviklingssykluser kan overlappe hverandre. Etter den påfølgende syklusen kan begynne før forrige syklus er fullført.

smidig modell

Agile metodikk er en praksis som fremmer kontinuerlig interaksjon mellom utvikling og testing under SDLC-prosessen til ethvert prosjekt. I Agile-metoden er hele prosjektet delt inn i små inkrementelle bygg. Alle disse byggene leveres i iterasjoner, og hver iterasjon varer fra én til tre uker.

Enhver smidig programvarefase er karakterisert på en måte som adresserer flere viktige antakelser om hoveddelen av programvareprosjekter:

1. Det er vanskelig å tenke på forhånd hvilke programvarekrav som vil vedvare og hvilke som vil endre seg. Det er like vanskelig å forutsi hvordan brukerprioriteringer vil endre seg etter hvert som prosjektet skrider frem.
2. For mange typer programvare er design og utvikling sammenflettet. Det vil si at begge aktivitetene bør utføres i tandem slik at designmodeller blir bevist etter hvert som de lages. Det er vanskelig å tenke på hvor mye design som er nødvendig før konstruksjon brukes for å teste konfigurasjonen.
3. Analyse, design, utvikling og testing er ikke så forutsigbare (fra et planleggingssynspunkt) som vi kanskje ønsker.

Iterativ modell

Det er en spesiell implementering av en livssyklus for programvareutvikling som fokuserer på en innledende, forenklet implementering, som deretter gradvis får mer kompleksitet og et bredere funksjonssett til det endelige systemet er ferdig. Kort sagt er iterativ utvikling en måte å bryte ned programvareutviklingen til en stor applikasjon i mindre biter.

Big bang modell

Big bang-modellen fokuserer på alle typer ressurser innen programvareutvikling og koding, med ingen eller svært lite planlegging. Kravene blir forstått og implementert når de kommer.

aws sns

Denne modellen fungerer best for små prosjekter med mindre utviklingsteam som jobber sammen. Det er også nyttig for akademiske programvareutviklingsprosjekter. Det er en ideell modell der kravene enten er ukjente eller endelig utgivelsesdato ikke er gitt.

Prototype modell

Prototyping-modellen starter med kravsamlingen. Utvikleren og brukeren møter og definerer formålet med programvaren, identifiserer behov osv.

A ' rask design ' blir deretter opprettet. Denne designen fokuserer på de aspektene av programvaren som vil være synlige for brukeren. Det fører så til utviklingen av en prototype. Kunden sjekker deretter prototypen, og eventuelle modifikasjoner eller endringer som er nødvendig gjøres på prototypen.

Looping foregår i dette trinnet, og bedre versjoner av prototypen lages. Disse vises fortløpende til brukeren slik at eventuelle nye endringer kan oppdateres i prototypen. Denne prosessen fortsetter til kunden er fornøyd med systemet. Når en bruker er fornøyd, konverteres prototypen til det faktiske systemet med alle hensyn til kvalitet og sikkerhet.