Introduktion til vandfaldsmodel

Det stammer fra bygge- og produktionsindustrier og er meget strukturerede fysiske omgivelser beregnet til design- og udviklingsprocesser. Vandfaldsmodel er også kendt som softwareudviklingen livscyklus model. Det var den første procesmodel, der blev introduceret som den lineære sekventielle livscyklusmodel. Vandfaldsmodellen fortæller ganske enkelt fænomenet, at den skal afslutte den ene fase fuldstændigt, før den nye fase af udviklingen startes, så der ikke er nogen overlapning af faser. Inden for softwareudviklingsfeltet blev vandfaldsmodellen først brugt som SDLC-tilgang. For at arbejde på vandfaldsmodellen er vi nødt til at forstå dens anvendelsesmetode baseret på både interne og eksterne faktorer, som kan være som følger:

  • Ingen tvetydige krav i ansøgningen.
  • Stabilitet i produktdefinition
  • Det forstås teknologi
  • Det er ikke dynamisk
  • Der er store ressourcer med passende ekspertise til rådighed for at understøtte produktet
  • Vey projekt med kort længde
  • Det gode dokument, klare og faste krav.

For at starte med vandfaldsmodellens historie vil jeg gerne sige, at den første prøve af vandfaldsmodellen blev introduceret i 1970 af Winston w Royce i en artikel. Siden da angiver vandfaldsmodellen, at man kun skal skifte til en anden fase, når de foregående faser er fuldt testet, gennemgået og verificeret. Det understreger den logiske udvikling af fasetrin. Dets funktionalitet ligner vandet, der strømmer ud over kanten af ​​klippen. Denne tilgang til softwareudvikling har fået navnet vandfald, fordi den udvikler sig systematisk fra en fase til en anden på en nedadgående måde. Siden det tidspunkt, hvor det første gang blev offentliggjort af Winston W. Royce i 1970, er vandfaldsmodellen blevet brugt meget inden for softwareudvikling. I softwareudviklingsprocesscyklen bruges programmeringsmodeller til at planlægge de forskellige stadier i udviklingen af ​​en applikation. En sådan model er vandfaldsmodellen.

Faser af vandfaldsmodel

Lad os nu tale om faser af vandfaldsmodellen, som kan forklares tydeligt gennem denne demo-infographic.

Med ovenstående infografik kan vi forstå, at vandfaldsmodellen har i alt 7 faser af design- og udviklingssoftwarecyklus, som er som følger:

  1. Krav
  2. Analyse
  3. Design
  4. Kodning / implementering
  5. Test
  6. Drift / implementering
  7. Vedligeholdelse

Så vi kan se, at vandfaldsmodellen fungerer hierarki fra top til bund med en fase afsluttet med fuld verifikation og derefter skifte til en anden fase inklusive faseprocesser som Conception, Initiation, Analyse, Design, Construction, Testing, Production / Implementation og Maintenance. For at få en mere kortfattet viden om vandfaldsmodellen er vi nødt til at forstå alle dens processer dybt med dens arbejdsmodel. Der er en grundlæggende forudsætningsfase, som skal forstås, inden de dybe faser af viden startes. Det handler om mulighedsundersøgelsen for softwareproduktet. Den beskæftiger sig med de økonomiske og tekniske aspekter af projektkravene. Denne fase omhandler korrektion af foranstaltningerne baseret på de analyserede fordele og ulemper. Således vælges den bedste løsning.

  1. Krav: Som specifikt med ord, er vi nødt til at vide og forstå, hvad vi skal designe, hvad vi skal udvikle, dets processer, hvad der vil være dets funktionalitet osv. Det leverer inputmateriale til det produkt, der fremstilles, og dermed det kommende produkt studeres, afsluttes og markeres. Det giver os også udvidelsen til at beslutte hardware- eller softwarekravene til produktet, som skal designes, udvikles og indfanges i alle faser.
  2. Analyse: Det resulterer i design af modeller, skemaer og forretningsregler. Ikke kun dette krav er opdelt i to dele:
  • Kravssamling og analyse: Først samles alle oplysninger og krav til produktudviklingen fra kunden og derefter behandles de til analyse. Hovedrollen for denne del er at udrydde ufuldstændighed og uoverensstemmelser i forbindelse med software produktudvikling.
  • Kravspecifikation: Derefter dokumenteres ovennævnte analyserede krav i et SRS-dokument (softwarekravspecifikation). Det fungerer som en sti mellem kunden og SRS-udviklingsteamet. Eventuelle tvister i fremtiden håndteres og afvikles kun gennem denne SRS-dokumentation.
  1. Design: Når den første fase er afsluttet og verificeret, er det den næste vigtigste fase, der skal studeres, da den bruges til systemdesign. Det hjælper med at specificere software- og hardwarekrav til produktdesignet. Det hjælper også med den overordnede arkitektur til systemdesign. Så kravspecifikationen studeres og verificeres for det meste i denne fase. Det er også nyttigt at omdanne SRS-dokumentet til funktionel design og udvikling af softwareproduktet. Så vi kan sige, at man i designfasen fremstiller den overordnede arkitektur for softwareudviklingsprojektet.
  2. Implementering: Når systemdesign er fuldt verificeret, kommer implementeringsfasen i rækken. I denne fase tages input fra systemdesign, og det udvikles først i små programmer kendt som enheder, som testes og implementeres i den kommende fase. Hver enhed i implementeringsfasen gennemgår for udvikling, og dens fulde funktionalitet testes, hvilket også kaldes enhedstesting. Så i denne fase konverteres systemdesignet til kildekode med fuldt funktionelle programmoduler. Det inkluderer udvikling, bevis og integration af softwaren.
  3. Integration og test: Hver enhedsdesign og udviklet i de tidligere faser er inkorporeret fra implementeringsfasen, som er integreret i et modul eller et system til en forskellige test som belastningstest, lead test osv. Efter test af hver enhed. Testmiljøet gennemgår en konstant softwarekontrol for at finde ud af, om der er nogen strømme eller fejl i designet eller koden. Testning udføres for at opretholde stabiliteten og gennemførligheden af ​​softwaren, så klienten ikke står over for forstyrrelser eller fejl under dens produktion. Så i denne fase efter implementering testes hele systemet grundigt for eventuelle fejl og fejl. Systemtestning består af tre forskellige typer aktiviteter, som kan forklares som nedenfor:
  • Alpha (α) Testing: Det er testen, der udføres af udviklingsholdet.
  • Beta (β) Test: Det er testen, der udføres af det venlige team af kunder og brugere.
  • Acceptacitetstest: det udføres både efter alpha-test og beta-test. Grundlæggende udføres denne testning efter levering af kunderne. Efter test udført af kunden tages beslutningen om denne software er acceptabel eller at afvise den. Så i denne fase er grundlæggende fejlsøgning af bugs udført.
  1. Implementering af systemet / operationer: Når først den ikke-funktionelle, funktionelle, alfa- og beta-test er udført, distribueres softwareproduktet til brugeren eller kundesystemet, eller det frigives til markedet. Implementeringsfasen inkluderer installation, migrering og support af det komplette system til bruger- eller kundemiljø.
  2. Vedligeholdelse: Det er sidst, men den vigtigste fase i vandfaldets arbejdsgangsmodel. Dette trin kommer lige efter installationen, og det inkluderer at foretage den passende ændring af produktet eller systemet eller for at forbedre, ændre eller ændre attributter, der er relateret til ydelsesproblemer relateret til systemet. dets vigtigste rolle er at forbedre systemets ydelse med det maksimale nøjagtighedsresultat af softwareproduktionen. Disse ændringer, der er rejst under vedligeholdelsesfasen, er hovedsageligt relateret til ændringer, der er initieret for at blive udført af kunden eller brugerne efter installation og testfase, som inkluderer bugs som defekt, der er afsløret under live brug af systemet eller anmodning rejst af kunderne. Så kunden får rettidig og planlagt vedligeholdelse og support til det udviklede produkt. Du vil virkelig blive overrasket over at vide, at den indsats, der er gjort i design- og udviklingsfasen af ​​softwareproduktet, kun er 60% -indsatsen sammenlignet med den indsats, der er gjort i vedligeholdelsesfasen. Der er dybest set tre typer vedligeholdelse, som er forklaret nedenfor:
  • Korrekt vedligeholdelse: I design- og udviklingsfasen opdages der ikke nogle fejl, de tager kun hensyn til, når kunden bruger. Dette er kun korrigerende vedligeholdelse, hvilket betyder korrektion af problemer eller fejl, som ikke blev opdaget i udviklingsfasen.
  • Perfektiv vedligeholdelse: Denne type vedligeholdelse udføres på kundeanmodning for at øge og forbedre funktionaliteten af ​​systemet eller softwaren.
  • Adaptiv vedligeholdelse: det er den vedligeholdelse, der kræves for at skifte systemmiljø. Normalt krævet til portering af det eksisterende system til et nyt miljø eller ny computer eller system eller måske med et nyt operativsystem. Denne fase er for vigtig, da dette fører til bedre systemydelse.

Så i ovenstående diskussion lærte vi hver fase af vandfaldsmodellen at kende dybt med fulde specifikationer. Så vi kan sige, at vandfaldsmodellen er meget vigtig inden for softwarefeltet også sammenlignet med mekaniske industrier, da hver fase har deres egen betydning, fører det til at generere en mere produktiv og stabil software.

Fordele

Ikke kun denne vandfaldsmodel har også mange flere fordele i softwareudviklingslivscyklussen, som kan diskuteres nedenfor:

  • Det giver mulighed for afdelingisering og kontrol.
  • Der kan indstilles en tidsplan med frister for hvert udviklingsstadium, og et produkt kan fortsætte gennem udviklingsprocessmodellen faser én efter én.
  • Da det gennemgår let forståelige og forklarbare faser, overvinder det mange problemer, så det er meget let at bruge.
  • På grund af stivheden i arbejdsgangsmodellen er det meget let at administrere, da hver fase i vandfaldsmodellen har specifikke gennemgangs- og leveringsprocesser.
  • Vandfaldsmodel fungerer godt til mindre projekter, hvor kravene er meget godt forstået.
  • Tidsplanen kan indstilles med frister for hvert udviklingsstadium, og et produkt kan fortsætte gennem udviklingsprocessens modelfaser én efter én.
  • Tydeligt definerede faser.
  • Godt forståede milepæle.
  • Let at arrangere opgaver.
  • Process og resultater er veldokumenterede.
  • Forstærker gode vaner: definere-før-design,
  • Design-før-kode.
  • Modellen fungerer godt til mindre projekter og projekter, hvor kravene er godt forstået.

Ulempe

Som vi ved, at hver mønt har to ansigter, så med den store adgang til fordelene ved vandfaldsmodellen har vandfaldsmodellen også nogle ulemper, eller du kan sige ulemper, der diskuteres nedenfor:

  • Ikke en god model for komplekse og objektorienterede projekter.
  • Ikke egnet til de projekter, hvor kravene er moderat til høj risiko for ændring.
  • Det er vanskeligt at estimere tid og omkostninger for hver fase af udviklingsprocessen.
  • Ikke en god model for komplekse og objektorienterede projekter.
  • Der produceres ingen fungerende software før sent i livscyklussen.
  • Kan ikke imødekomme ændrede krav.
  • Det er vanskeligt at måle fremskridt inden for etaper.
  • Høje mængder risiko og usikkerhed.
  • Dårlig model til lange og igangværende projekter.
  • Justering af rækkevidde under livscyklussen kan afslutte et projekt.
  • Ingen feedbacksti
  • Ingen overlapning af faser
  • Svært at imødekomme ændringsanmodninger.
  • risiko og usikkerhed er stor med denne procesmodel.

Hvor skal man bruge vandfaldsmodel

Efter at have omgivet alle scenarierne kommer vi nu til et punkt, hvor vi vil vide, hvor vi skal bruge vandfaldsmodellen.

  • Der anvendes hovedsageligt vandfaldsmodeller i et forsvarsprojekt, da kravet er klart, fordi de, før de går over til udviklingsfasen, analyserer det godt.
  • Dette kan også bruges i migrationsprojekter, hvor kravene kun er den samme platform, eller sprog kan variere / ændres.

Konklusion

Så som helhed kan jeg sige, at vandfaldsmodel er bedst egnet til lille softwareudviklingsprojekt sammenlignet med store projekter, fordi design, udvikling og implementering er lettere i det lille projekt, når man arbejder med vandfaldsmodel, fordi der i denne model er alle de tidligere faser behov for skal afsluttes, når man går til kommende faser. Så i det store projekt kommer problemer og fejl ofte, da det har en stor model, så hver gang testfasen fortsættes, hvis den implementeres gennem vandfaldsmodellen, hvilket vil føre til mindre optimering og nøjagtighed af softwaren.

Anbefalede artikler

Dette har været en guide til vandfaldsmodel. Her har vi drøftet faser, fordele og ulemper ved vandfaldsmodellen. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -

  1. Hvad er AWS?
  2. Hvad er Bootstrap?
  3. Hvad er en bikube?
  4. Hvad er Unix?
  5. Scrum vs vandfald | Sammenligning

Kategori:

Softwareudvikling