logo

SDLC-modeller

Software Development life cycle (SDLC) är en andlig modell som används i projektledning som definierar stadierna som ingår i ett informationssystemutvecklingsprojekt, från en första genomförbarhetsstudie till underhållet av den färdiga applikationen.

Det finns olika livscykelmodeller för mjukvaruutveckling som specificerar och design, som följs under mjukvaruutvecklingsfasen. Dessa modeller kallas också ' Processmodeller för mjukvaruutveckling .' Varje processmodell följer en serie faser som är unika för sin typ för att säkerställa framgång i steget av mjukvaruutveckling.

Här är några viktiga faser av SDLC:s livscykel:

Software Engineering SDLC-modeller

Vattenfall modell

Vattenfallet är en universellt accepterad SDLC-modell. I denna metod är hela processen med mjukvaruutveckling uppdelad i olika faser.

sql datatyper

Vattenfallsmodellen är en kontinuerlig mjukvaruutvecklingsmodell där utvecklingen ses som att den flyter stadigt nedåt (som ett vattenfall) genom stegen kravanalys, design, implementering, testning (validering), integration och underhåll.

Linjär ordning av aktiviteter har några betydande konsekvenser. För det första, för att identifiera slutet av en fas och början av nästa, måste vissa certifieringstekniker användas i slutet av varje steg. Viss verifiering och validering innebär vanligtvis detta som säkerställer att utgången från steget överensstämmer med dess indata (vilket är resultatet från föregående steg), och att utgången från steget överensstämmer med systemets övergripande krav.

RAD-modell

RAD eller Rapid Application Development process är en användning av vattenfallsmodellen; det är inriktat på att utveckla mjukvara inom en kort period. RAD-modellen bygger på konceptet att ett bättre system kan utvecklas på kortare tid genom att använda fokusgrupper för att samla systemkrav.

  • Affärsmodellering
  • Datamodellering
  • Processmodellering
  • Applikationsgenerering
  • Testning och omsättning

Spiralmodell

Spiralmodellen är en riskdriven processmodell . Denna SDLC-modell hjälper gruppen att anta delar av en eller flera processmodeller som ett vattenfall, inkrementellt, vattenfall, etc. Spiraltekniken är en kombination av snabb prototypframställning och samtidighet i design- och utvecklingsaktiviteter.

Varje cykel i spiralen börjar med identifieringen av mål för den cykeln, de olika alternativen som är möjliga för att uppnå målen och de begränsningar som finns. Detta är den första kvadranten av cykeln (övre vänstra kvadranten).

Nästa steg i cykeln är att utvärdera dessa olika alternativ utifrån målen och begränsningarna. Fokus för utvärderingen i detta steg är baserad på riskuppfattningen för projektet.

Nästa steg är att utveckla strategier som löser osäkerheter och risker. Detta steg kan involvera aktiviteter som benchmarking, simulering och prototypframställning.

V-modell

I denna typ av SDLC-modelltestning och utvecklingen planeras steget parallellt. Så det finns verifieringsfaser på sidan och valideringsfasen på andra sidan. V-Model ansluter genom kodningsfas.

Inkrementell modell

Den inkrementella modellen är inte en separat modell. Det är nödvändigtvis en serie vattenfallscykler. Kraven delas in i grupper i början av projektet. För varje grupp följs SDLC-modellen för att utveckla mjukvara. SDLC-processen upprepas, med varje version som lägger till mer funktionalitet tills alla krav är uppfyllda. I den här metoden fungerar varje cykel som underhållsfas för den tidigare programversionen. Ändring av den inkrementella modellen tillåter utvecklingscykler att överlappa varandra. Efter den efterföljande cykeln kan börja innan den föregående cykeln är klar.

Agil modell

Agil metodik är en praxis som främjar fortsatt interaktion mellan utveckling och testning under SDLC-processen i alla projekt. I Agile-metoden är hela projektet uppdelat i små inkrementella byggen. Alla dessa builds tillhandahålls i iterationer, och varje iteration varar från en till tre veckor.

Varje smidig mjukvarufas kännetecknas på ett sätt som adresserar flera viktiga antaganden om huvuddelen av mjukvaruprojekt:

  1. Det är svårt att på förhand tänka sig vilka programvarukrav som kommer att bestå och vilka som kommer att förändras. Det är lika svårt att förutse hur användarnas prioriteringar kommer att förändras allt eftersom projektet fortskrider.
  2. För många typer av mjukvara är design och utveckling sammanflätade. Det vill säga att båda aktiviteterna bör utföras i tandem så att designmodeller bevisas när de skapas. Det är svårt att tänka på hur mycket design som krävs innan konstruktion används för att testa konfigurationen.
  3. Analys, design, utveckling och testning är inte så förutsägbara (ur planeringssynpunkt) som vi skulle vilja.

Iterativ modell

Det är en speciell implementering av en livscykel för mjukvaruutveckling som fokuserar på en initial, förenklad implementering, som sedan successivt får mer komplexitet och en bredare uppsättning funktioner tills det slutliga systemet är färdigt. Kort sagt är iterativ utveckling ett sätt att bryta ner mjukvaruutvecklingen för en stor applikation i mindre bitar.

Big bang modell

Big bang-modellen fokuserar på alla typer av resurser inom mjukvaruutveckling och kodning, med ingen eller väldigt lite planering. Kraven förstås och implementeras när de kommer.

Denna modell fungerar bäst för små projekt med mindre utvecklingsteam som arbetar tillsammans. Det är också användbart för akademiska programvaruutvecklingsprojekt. Det är en idealisk modell där kraven antingen är okända eller där slutgiltigt releasedatum inte anges.

Prototypmodell

Prototypmodellen börjar med kravinsamlingen. Utvecklaren och användaren möter och definierar syftet med programvaran, identifierar behoven osv.

A ' snabb design ' skapas sedan. Denna design fokuserar på de aspekter av programvaran som kommer att vara synliga för användaren. Det leder sedan till utvecklingen av en prototyp. Kunden kontrollerar sedan prototypen och eventuella modifieringar eller ändringar som behövs görs på prototypen.

Looping sker i detta steg och bättre versioner av prototypen skapas. Dessa visas kontinuerligt för användaren så att eventuella nya ändringar kan uppdateras i prototypen. Denna process fortsätter tills kunden är nöjd med systemet. När en användare är nöjd konverteras prototypen till det faktiska systemet med alla hänsyn till kvalitet och säkerhet.