Introduktion till vattenfallsmodell

Ursprungligen från bygg- och tillverkningsindustrin och är mycket strukturerad fysisk miljö avsedd för design- och utvecklingsprocesser. Vattenfallsmodellen är också känd som mjukvaruutvecklingen livscykelmodell. Det var den första processmodellen som introducerades som den linjära sekventiella livscykelmodellen. Vattenfallsmodellen säger helt enkelt fenomenet att fullfölja en fas fullständigt innan den nya utvecklingsfasen påbörjas så att det inte finns någon överlappning av faser. Inom mjukvaruutvecklingsfältet användes vattenfallsmodellen först som SDLC-strategi. För att arbeta med vattenfallsmodellen måste vi förstå dess tillämpningssätt baserat på både inre och yttre faktorer som kan vara följande:

  • Inga tvetydiga krav i ansökan.
  • Produktdefinitionens stabilitet
  • Det är teknik förstås
  • Det är inte dynamiskt
  • Stora resurser med lämplig expertis finns tillgängliga för att stödja produkten
  • Vey kort längd projekt
  • Det bra dokumentet, tydliga och fasta krav.

Till att börja med historien om vattenfallsmodellen skulle jag vilja säga att det första provet av vattenfallsmodellen infördes 1970 av Winston w Royce i en artikel. Sedan dess anger vattenfallsmodellen att man bör byta till en annan fas endast när de tidigare faserna är helt testade, granskade och verifierade. Det betonar den logiska utvecklingen av fassteg. Dess funktionalitet liknar vattnet som flödar över klippkanten. Denna strategi för mjukvaruutveckling har fått namnet vattenfall eftersom den systematiskt utvecklas från en fas till en annan på ett nedåtgående sätt. Sedan den första gången den publicerades av Winston W. Royce 1970 har vattenfallsmodellen använts i stor utsträckning inom mjukvaruutveckling. I mjukvaruutvecklingsprocesscykeln används programmeringsmodeller för att planera de olika stadierna för att utveckla en applikation. En sådan modell är vattenfallsmodellen.

Faser av vattenfallsmodellen

Låt oss nu prata om faserna i vattenfallsmodellen, som kan förklaras tydligt genom denna demo-infographic.

Med ovanstående infografik kan vi förstå att vattenfallsmodellen har totalt 7 faser av design- och utvecklingsprogramvarucykel som är följande:

  1. Krav
  2. Analys
  3. Design
  4. Kodning / implementering
  5. Testning
  6. Drift / distribution
  7. Underhåll

Så vi kan se att vattenfallsmodellen fungerar hierarki från topp till botten med en fas avslutad med fullständiga verifieringar och sedan byta till en annan fas inklusive fasprocesser som Conception, Initiation, Analys, Design, Construction, Testing, Production / Implementation and Maintenance. För att få en mer kortfattad kunskap om vattenfallsmodellen måste vi förstå alla dess processer djupt med dess arbetsmodell. Det finns en grundläggande förutsättningsfas som måste förstås innan de djupa faser av kunskap startas. Det handlar om genomförbarhetsstudien för programvaruprodukten. Den behandlar de ekonomiska och tekniska aspekterna av projektkraven. Denna fas behandlar korrigering av åtgärderna baserat på de analyserade fördelarna och nackdelarna. Därför väljs den bästa lösningen.

  1. Krav: Så specifikt med ord måste vi veta och förstå vad vi måste utforma, vad vi måste utveckla, dess processer, vad som kommer att vara dess funktionalitet, etc. Det tillhandahåller inputmaterial till den produkt som tillverkas och därmed den kommande produkten studeras, slutförs och markeras. Det ger oss också förlängningen att bestämma hårdvara eller programvarukrav för produkten som kommer att utformas, utvecklas och fångas i alla faser.
  2. Analys: Det resulterar i utformning av modeller, scheman och affärsregler. Inte bara detta krav är indelat i två delar:
  • Kravssamling och analys: Först samlas all information och krav för produktutvecklingen från kunden och sedan bearbetas för analys. Huvudrollen för denna del är att utrota ofullständighet och inkonsekvenser relaterade till programvaruutveckling.
  • Kravspecifikation: Sedan dokumenteras ovan analyserade krav i ett SRS-dokument (programvarukravspecifikation). Det fungerar som en väg mellan kunden och SRS utvecklingsteam. Eventuella tvister i framtiden hanteras och avgörs endast genom denna SRS-dokumentation.
  1. Design: När den första fasen är klar och verifierad är det nästa viktigaste fas som ska studeras eftersom den används för systemdesign. Det hjälper till att specificera program- och hårdvarukrav för produktdesignen. Det hjälper också till övergripande arkitektur för systemdesign. Så kravspecifikationen studeras och verifieras mestadels i denna fas. Det är också bra att omvandla SRS-dokumentet till funktionell design och utveckling av programvaruprodukten. Så vi kan säga att man i designfasen gör den övergripande arkitekturen för mjukvaruutvecklingsprojektet.
  2. Implementering: Med systemkonstruktion fullständigt verifierad kommer implementeringsfasen i raden. I denna fas tas ingångarna från systemdesign, och det utvecklas först i små program som kallas enheter, som testas och implementeras i den kommande fasen. Varje enhet i implementeringsfasen genomgår för utveckling och dess fulla funktionalitet testas, vilket också kallas enhetstest. Så i denna fas konverteras systemdesignen till källkod med fullt fungerande programmoduler. Det inkluderar utveckling, bevisning och integration av programvaran.
  3. Integration och testning: Varje enhetsdesign och utvecklad i de tidigare faserna är införlivad från implementeringsfasen som integreras i en modul eller ett system för olika test som lasttest, ledningstest osv efter testning av varje enhet. Testmiljön genomgår en ständig mjukvarukontroll för att ta reda på om det finns några flöden eller fel i designen eller koden. Testning görs för att bibehålla programvarans stabilitet och genomförbarhet så att klienten inte får några störningar eller buggar under dess produktion. Så i denna fas efter implementeringen testas hela systemet noggrant för eventuella fel och fel. Systemtestning består av tre olika typer av aktiviteter som kan förklaras enligt nedan:
  • Alpha (α) Testing: Det är testet som utförs av utvecklingsgruppen.
  • Beta (β) Testing: Det är testet som görs av det vänliga teamet av kunder och användare.
  • Acceptantestning: det görs både efter alfatestning och betatest. I grund och botten utförs denna testning efter leverans av kunderna. Efter test utförda av kunden fattas beslutet om denna programvara är acceptabel eller att avvisa den. Så i denna fas görs i princip felsökning av buggar.
  1. Distribution av systemet / Operations: när den icke-funktionella, funktionella, alfa- och betatestningen har genomförts distribueras programvaruprodukten till användaren eller kundsystemet eller släpps ut på marknaden. Distributionsfasen inkluderar installation, migrering och support av hela systemet till användare eller kundmiljö.
  2. Underhåll: Det är sist men den viktigaste fasen i arbetsflödesmodellen för vattenfall. Det här steget kommer precis efter installationen, och det inkluderar att göra lämplig modifiering av produkten eller systemet, eller för att förbättra, ändra eller ändra attribut relaterade till prestandafrågor relaterade till systemet. dess huvudroll är att förbättra systemets prestanda med maximal resultat av mjukvaruutgången. Dessa förändringar som tas upp under underhållsfasen är huvudsakligen relaterade till förändringar som initierats för att göras av kunden eller användarna efter installation och testfas som inkluderar buggar som fel som upptäckts under levande användning av systemet eller begäran som uppförts av kunderna. Så klienten förses med snabbt och schemalagt underhåll och support för den utvecklade produkten. Du kommer verkligen att bli förvånad över att veta att ansträngningarna som gjorts i design- och utvecklingsfasen för programvaruprodukten endast är 60% -insatsen jämfört med ansträngningarna som gjorts i underhållsfasen. Det finns i princip tre typer av underhåll som förklaras nedan:
  • Korrigerande underhåll: Under konstruktions- och utvecklingsfasen upptäcks inte några fel, de tar bara hänsyn till när kunden använder. Detta är endast korrigerande underhåll vilket innebär korrigering av problem eller fel som inte upptäcktes i utvecklingsfasen.
  • Perfekt underhåll: Den här typen av underhåll utförs på kundens begäran för att öka och förbättra funktionaliteten i systemet eller programvaran.
  • Adaptivt underhåll: det är underhållet som krävs för att byta systemmiljö. Vanligtvis krävs för portning av det befintliga systemet till en ny miljö eller ny dator eller system eller kanske med ett nytt operativsystem. Denna fas är för viktig eftersom det leder till bättre systemprestanda.

Så i ovanstående diskussion lärde vi oss varje fas i vattenfallsmodellen djupt med fullständiga specifikationer. Så vi kan säga att vattenfallsmodellen är mycket viktigt inom programvarufältet också jämfört med mekaniska industrier eftersom varje fas har sin egen betydelse, det leder till att generera en mer produktiv och stabil programvara.

fördelar

Inte bara denna vattenfallsmodell har också många fler fördelar i mjukvaruutvecklingens livscykel som kan diskuteras nedan:

  • Det möjliggör avdelning och kontroll.
  • Ett schema kan fastställas med tidsfrister för varje utvecklingssteg och en produkt kan gå igenom utvecklingsprocessmodellens faser en efter en.
  • Eftersom det genomgår lättförståeliga och förklarbara faser övervinner det många problem, så det är väldigt lätt att använda.
  • På grund av styvheten i arbetsflödesmodellen är det mycket lätt att hantera eftersom varje fas i vattenfallsmodellen har specifika gransknings- och leveransprocesser.
  • Vattenfallsmodellen fungerar bra för mindre projekt där kraven är mycket väl förståda.
  • Schemat kan ställas in med tidsfrister för varje utvecklingssteg och en produkt kan gå igenom utvecklingsprocessmodellens faser en efter en.
  • Tydligt definierade stadier.
  • Väl förstått milstolpar.
  • Lätt att ordna uppgifter.
  • Process och resultat är väl dokumenterade.
  • Förstärker goda vanor: definiera-före-design,
  • Design-före-kod.
  • Modellen fungerar bra för mindre projekt och projekt där krav förstås väl.

Nackdel

Som vi vet att varje mynt har två ansikten, så med den stora tillgången till fördelarna med vattenfallsmodellen har vattenfallsmodellen också några nackdelar eller så kan du säga nackdelar som diskuteras nedan:

  • Inte en bra modell för komplexa och objektorienterade projekt.
  • Inte lämplig för de projekt där kraven har en måttlig till hög risk att förändras.
  • Det är svårt att uppskatta tid och kostnad för varje fas i utvecklingsprocessen.
  • Inte en bra modell för komplexa och objektorienterade projekt.
  • Ingen fungerande mjukvara produceras förrän sent under livscykeln.
  • Kan inte tillgodose ändrade krav.
  • Det är svårt att mäta framsteg inom steg.
  • Höga mängder risk och osäkerhet.
  • Dålig modell för långa och pågående projekt.
  • Att justera omfattningen under livscykeln kan avsluta ett projekt.
  • Ingen feedbackväg
  • Ingen överlappning av faser
  • Svårt att tillgodose ändringsförfrågningar.
  • risk och osäkerhet är hög med denna processmodell.

Var du ska använda vattenfallsmodell

Efter att ha omkretsat alla scenarier kommer vi till en punkt där vi vill veta var vi ska använda vattenfallsmodellen.

  • Huvudsakligen används vattenfallsmodellen i ett försvarsprojekt som där, kravet är klart eftersom de innan de går till utvecklingsfasen analyserar den väl.
  • Detta kan också användas i migrationsprojekt där kraven kommer att vara samma plattform eller språk kan variera / ändras.

Slutsats

Så i sin helhet kan jag säga att vattenfallsmodellen är bäst lämpad för små programvaruutvecklingsprojekt jämfört med stora projekt eftersom design, utveckling och implementering är enklare i det lilla projektet när jag arbetar med vattenfallsmodell eftersom alla tidigare faser i denna modell behöver ska slutföras när man går till kommande faser. Så i det stora projektet kommer problem och fel ofta eftersom det har en stor modell, så varje testfas fortsätter om den implementeras genom vattenfallsmodellen, vilket kommer att leda till mindre optimering och noggrannhet av programvaran.

Rekommenderade artiklar

Detta har varit en guide till Waterfall Model. Här har vi diskuterat faserna, fördelarna och nackdelarna med vattenfallsmodellen. Du kan också gå igenom våra andra föreslagna artiklar för att lära dig mer -

  1. Vad är AWS?
  2. Vad är Bootstrap?
  3. Vad är en bikupa?
  4. Vad är Unix?
  5. Scrum vs vattenfall | Jämförelse

Kategori:

Mjukvaruutveckling