Introduksjon til fossefallmodell

Det er opprinnelig fra bygg- og produksjonsindustrier, og er svært strukturerte fysiske omgivelser ment for design- og utviklingsprosesser. Fossemodell er også kjent som livssyklusmodellen for programvareutvikling. Det var den første prosessmodellen som ble introdusert som den lineære sekvensielle livssyklusmodellen. Fossemodell forteller ganske enkelt fenomenet om å fullføre den ene fasen fullstendig før du starter den nye utviklingsfasen, så det ikke er noen overlapping av faser. I programvareutviklingsfeltet ble fossefallsmodellen først brukt som SDLC-tilnærming. For å jobbe med fossefallmodellen må vi forstå dens anvendelsesmetode basert på både interne og eksterne faktorer som kan være som følger:

  • Ingen tvetydige krav i søknaden.
  • Stabilitet av produktdefinisjon
  • Det er teknologi forstått
  • Det er ikke dynamisk
  • Store ressurser med passende kompetanse er tilgjengelige for å støtte produktet
  • Vey kort lengde prosjekt
  • Det gode dokumentet, klare og faste krav.

For å starte med historien til fossefallmodellen, vil jeg si at den første prøven av fossefallmodellen ble introdusert i 1970 av Winston w Royce i en artikkel. Siden oppgir fossefallsmodellen at man bare bør bytte til en annen fase når de forrige fasene er fullstendig testet, gjennomgått og verifisert. Den legger vekt på den logiske progresjonen av fasetrinn. Funksjonaliteten er lik vannstrømmen over kanten av stupet. Denne tilnærmingen til programvareutvikling har fått navnet foss fordi den utvikler seg systematisk fra en fase til en annen på en nedadgående måte. Siden den gang den ble publisert av Winston W. Royce i 1970, har fossemodellen blitt brukt mye innen programvareutvikling. I programvareutviklingsprosessssyklusen brukes programmeringsmodeller for å planlegge de forskjellige stadiene for å utvikle en applikasjon. En slik modell er fossemodellen.

Faser av fossefallmodell

La oss nå snakke om fasene i fossefallmodellen, som kan forklares tydelig gjennom denne demo-infografien.

Med ovennevnte infografikk kan vi forstå at fossefallmodellen har totalt 7 faser av design- og utviklingsprogramvaresyklus som er som følger:

  1. Krav
  2. Analyse
  3. Design
  4. Koding / implementering
  5. testing
  6. Drift / distribusjon
  7. Vedlikehold

Så vi kan se at fossefallmodellen fungerer hierarki fra topp til bunn med en fase fullført med full bekreftelse og deretter bytte til en annen fase, inkludert faseprosesser som unnfangelse, initiering, analyse, design, konstruksjon, testing, produksjon / implementering og vedlikehold. For å få en kortere kunnskap om fossefallmodellen, må vi forstå alle prosessene i dybden med arbeidsmodellen. Det er en grunnleggende forutsetningsfase som må forstås før vi starter de dype faser av kunnskap. Det handler om mulighetsstudien for programvareproduktet. Den tar for seg de økonomiske og tekniske aspektene ved prosjektkravene. Denne fasen omhandler korreksjon av tiltakene basert på analyserte fordeler og ulemper. Dermed er den beste løsningen valgt.

  1. Krav: Som spesifikke med ord, må vi vite og forstå hva vi må utforme, hva vi må utvikle, dets prosesser, hva som vil være dets funksjonalitet, etc. Det gir inputmateriale til produktet som blir laget og dermed det kommende produktet blir studert, avsluttet og merket. Det gir oss også utvidelsen til å bestemme maskinvare- eller programvarekravene til produktet som skal designes, utvikles og fanges opp i alle faser.
  2. Analyse: Det resulterer i utforming av modeller, skjemaer og forretningsregler. Ikke bare dette kravet er delt inn i to deler:
  • Kravssamling og analyse: Først samles all informasjon og krav til produktutviklingen fra kunden og deretter behandles den for analyse. Hovedrollen til denne delen er å utrydde ufullstendighet og uoverensstemmelser relatert til programvareutvikling.
  • Kravspesifikasjon: Deretter blir de ovennevnte analyserte kravene dokumentert i et SRS-dokument (programvarekravspesifikasjon). Det fungerer som en bane mellom kunden og SRS utviklingsteam. Eventuelle tvister i fremtiden håndteres og avgjøres bare gjennom denne SRS-dokumentasjonen.
  1. Design: Etter at den første fasen er fullført og verifisert, er det den neste viktigste fasen som skal studeres når den brukes til systemdesign. Det hjelper med å spesifisere programvare- og maskinvarekrav for produktdesign. Det hjelper også i generell arkitektur for systemdesign. Så kravspesifikasjonen studeres og verifiseres for det meste i denne fasen. Det er også nyttig å transformere SRS-dokumentet til funksjonell design og utvikling av programvareproduktet. Så vi kan si at i utformingsfasen lager man den overordnede arkitekturen for programvareutviklingsprosjektet.
  2. Implementering: Med systemdesign fullstendig verifisert, kommer implementeringsfasen i rekken. I denne fasen tas inngangene fra systemdesign, og den blir først utviklet i små programmer kjent som enheter, som testes og implementeres i den kommende fasen. Hver enhet i implementeringsfasen gjennomgår for utvikling og full funksjonalitet testes, også kjent som enhetstesting. Så i denne fasen blir systemdesignet konvertert til kildekode med fullt funksjonelle programmoduler. Det inkluderer utvikling, bevising og integrering av programvaren.
  3. Integrering og testing: Hver enhetsdesign og utviklet i de tidligere fasene er integrert fra implementeringsfasen som er integrert i en modul eller et system for en annen test som lasttest, blytest osv. Etter testing av hver enhet. Testmiljøet gjennomgår en konstant programvaresjekk for å finne ut om det er noen flyter eller feil i designen eller koden. Testing gjøres for å opprettholde programvarens stabilitet og gjennomførbarhet, slik at klienten ikke blir utsatt for forstyrrelser eller feil under produksjonen. Så i denne fasen etter implementering testes hele systemet grundig for eventuelle feil og feil. Systemtesting består av tre forskjellige typer aktiviteter som kan forklares som nedenfor:
  • Alpha (α) Testing: Det er testingen som er utført av utviklingsteamet.
  • Beta (β) Testing: Det er testen som er utført av det vennlige teamet av kunder og brukere.
  • Akseptstesting: det gjøres etter både alfa-testing og betatesting. I utgangspunktet utføres denne testingen etter levering av kundene. Etter testing utført av kunden blir beslutningen tatt om denne programvaren er akseptabel eller å avvise den. Så i denne fasen er det i grunnen gjort feilsøking av feil.
  1. Distribusjon av systemet / Operasjoner: Når den ikke-funksjonelle, funksjonelle, alfa- og beta-testen er utført, distribueres programvareproduktet til bruker- eller kundesystemet, eller det frigjøres til markedet. Distribusjonsfasen inkluderer installasjon, migrering og støtte av hele systemet til bruker- eller kundemiljøet.
  2. Vedlikehold: Det er sist men den viktigste fasen i arbeidsflytmodellen for fossefall. Dette trinnet kommer rett etter installasjonen, og det inkluderer å gjøre riktig modifisering av produktet eller systemet, eller for å forbedre, endre eller endre attributter relatert til ytelsesproblemer relatert til systemet. dens viktigste rolle er å forbedre ytelsen til systemet med maksimal nøyaktighetsresultat av programvareproduksjonen. Disse endringene som ble reist i løpet av vedlikeholdsfasen er hovedsakelig relatert til endringer som er initiert for å bli utført av kunden eller brukerne etter installasjons- og testfasen, som inkluderer feil som feil som er avdekket under live bruk av systemet eller forespørsel reist av kundene. Så klienten er utstyrt med rettidig og planlagt vedlikehold og støtte for det utviklede produktet. Du vil virkelig bli overrasket over å vite at innsatsen som er gjort i design- og utviklingsfasen av programvareproduktet bare er 60% innsats sammenlignet med innsatsen som gjøres i vedlikeholdsfasen. Det er i utgangspunktet tre typer vedlikehold som blir forklart nedenfor:
  • Korrigerende vedlikehold: I prosjekterings- og utviklingsfasen oppdages ikke noen feil, de tar bare hensyn til når kunden bruker. Dette er bare korrigerende vedlikehold som betyr korrigering av problemer eller feil som ikke ble oppdaget i utviklingsfasen.
  • Perfekt vedlikehold: Denne typen vedlikehold utføres på kundens forespørsel for å øke og forbedre funksjonaliteten til systemet eller programvaren.
  • Adaptivt vedlikehold: det er vedlikeholdet som kreves for å bytte systemmiljø. Vanligvis nødvendig for porting av det eksisterende systemet til et nytt miljø eller ny datamaskin eller system eller kanskje med et nytt operativsystem. Denne fasen er for viktig da dette fører til bedre systemytelse.

Så i diskusjonen ovenfor ble vi dypt kjent med hver fase av fossemodellen med fulle spesifikasjoner. Så vi kan si at fossefallmodellen er veldig viktig i programvarefeltet, også sammenlignet med mekaniske næringer, ettersom hver fase har sin egen betydning, fører den til å generere en mer produktiv og stabil programvare.

Fordeler

Ikke bare denne fossen modellen har også mange flere fordeler i programvaren utvikling livssyklus som kan diskuteres nedenfor:

  • Det gir mulighet for avdeling og kontroll.
  • Det kan settes en tidsplan med frister for hvert utviklingsstadium, og et produkt kan fortsette gjennom utviklingsprosessmodellfasene én etter én.
  • Siden den gjennomgår lett forståelige og forklarbare faser, overvinner den mange problemer, så den er veldig enkel å bruke.
  • På grunn av stivheten i arbeidsflytmodellen er det veldig lett å administrere, da hver fase i fossefallmodellen har spesifikke gjennomgangs- og leveringsprosesser.
  • Fossemodell fungerer bra for mindre prosjekter der kravene er veldig godt forstått.
  • Tidsplanen kan settes med frister for hvert utviklingsstadium, og et produkt kan fortsette gjennom utviklingsprosessmodellfasene en etter en.
  • Tydelig definerte stadier.
  • Godt forstått milepæler.
  • Lett å ordne oppgaver.
  • Prosess og resultater er godt dokumentert.
  • Forsterker gode vaner: definere-før-design,
  • Design-før-kode.
  • Modellen fungerer bra for mindre prosjekter og prosjekter der krav er godt forstått.

Ulempe

Som vi vet at hver mynt har to ansikter, så med den store tilgangen til fordelene med fossefallmodellen har også fossefall noen ulemper, eller du kan si ulemper som blir diskutert nedenfor:

  • Ikke en god modell for komplekse og objektorienterte prosjekter.
  • Ikke egnet for prosjektene hvor kravene er moderat til høy risiko for endring.
  • Det er vanskelig å estimere tid og kostnader for hver fase av utviklingsprosessen.
  • Ikke en god modell for komplekse og objektorienterte prosjekter.
  • Ingen fungerende programvare blir produsert før sent i løpet av livssyklusen.
  • Kan ikke imøtekomme endrede krav.
  • Det er vanskelig å måle fremgang i faser.
  • Høye mengder risiko og usikkerhet.
  • Dårlig modell for lange og pågående prosjekter.
  • Å justere omfanget i løpet av livssyklusen kan avslutte et prosjekt.
  • Ingen tilbakemeldingsvei
  • Ingen overlapping av faser
  • Vanskelig å imøtekomme endringsforespørsler.
  • risiko og usikkerhet er høy med denne prosessmodellen.

Hvor du skal bruke fossefallmodell

Nå etter å ha omkranset alle scenariene, kommer vi til et punkt hvor vi vil vite hvor vi skal bruke fossefallmodellen.

  • Stort sett brukes fossefallmodell i et forsvarsprosjekt som der, kravet er klart fordi de, før de går over til utviklingsfase, analyserer det godt.
  • Dette kan også brukes i migrasjonsprosjekter der kravene vil være den samme, bare plattformen eller språk kan variere / endres.

Konklusjon

Så som en helhet kan jeg si at fossefallmodell er best egnet for lite programvareutviklingsprosjekt sammenlignet med store prosjekter fordi design, utvikling og implementering er lettere i det lille prosjektet når jeg jobber med fossefallmodell fordi i denne modellen trenger alle de tidligere fasene skal fullføres når du går til kommende faser. Så i det store prosjektet kommer problemene og feilene ofte som det har en stor modell, så hver gang testfasen vil bli videreført hvis den implementeres gjennom fossefallmodellen, noe som vil føre til mindre optimalisering og nøyaktighet av programvaren.

Anbefalte artikler

Dette har vært en guide til Waterfall Model. Her har vi diskutert faser, fordeler og ulemper ved fossefallmodell. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -

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

Kategori:

Programvare utvikling