Uvod u model vodopada

Potječe iz građevine i proizvodne industrije, visoko je strukturirano fizičko okruženje namijenjeno procesima dizajna i razvoja. Model vodopada poznat je i kao model životnog ciklusa razvoja softvera. Bio je to prvi procesni model uveden kao linearno-sekvencijalni model životnog ciklusa. Model vodopada jednostavno govori fenomenu da se jedna faza u potpunosti završi prije započinjanja nove faze razvoja, tako da ne postoji preklapanje faza. U području razvoja softvera, model vodopada prvi je put korišten kao SDLC pristup. Da bismo radili na modelu vodopada, moramo razumjeti njegov aplikativni pristup koji se temelji na unutarnjim i vanjskim čimbenicima koji mogu biti sljedeći:

  • U prijavi nema dvosmislenih zahtjeva.
  • Stabilnost definicije proizvoda
  • To je tehnologija shvaćena
  • Nije dinamičan
  • Na raspolaganju su veliki resursi s odgovarajućom stručnošću kako bi podržali proizvod
  • Vey projekt kratke duljine
  • Dobar dokument, jasni i fiksni zahtjevi.

Za početak s poviješću modela vodopada, želio bih reći da je prvi uzorak modela vodopada u članku 1970. godine predstavio Winston w Royce. Od tada model slapa kaže da bi se trebalo prebaciti na drugu fazu tek kada su prethodne faze u potpunosti testirane, pregledane i provjerene. Naglašava na logičnom napredovanju faznih koraka. Njegova funkcionalnost slična je protoku vode preko ruba litice. Ovakav pristup razvoju softvera dobio je ime vodopad, jer se sustavno razvija iz jedne faze u drugu na silazni način. Od vremena kad ga je 1970. prvi put objavio Winston W. Royce, model vodopada široko se koristio u području razvoja softvera. U ciklusu procesa razvoja softvera, programski modeli se koriste za planiranje različitih faza razvoja aplikacije. Jedan takav model je model vodopada.

Faze modela vodopada

Sada razgovarajmo o fazama modela vodopada, što se jasno može objasniti kroz ovu demo infografiku.

S gornjom infografikom možemo razumjeti da model vodopada ima ukupno 7 faza ciklusa dizajna i razvoja softvera koji su sljedeći:

  1. zahtjevi
  2. Analiza
  3. Oblikovati
  4. Kodiranje / implementacija
  5. Testiranje
  6. Rad / raspoređivanje
  7. Održavanje

Tako možemo vidjeti da model vodopada funkcionira hijerarhijom od vrha do dna s jednom fazom koja je završena s potpunim provjerama, a zatim prelazi na drugu fazu, uključujući fazne procese poput koncepcije, inicijacije, analize, dizajna, konstrukcije, ispitivanja, proizvodnje / implementacije i održavanja. Da bismo stekli kraće znanje o modelu vodopada, trebamo duboko razumjeti sve njegove procese s njegovim radnim modelom. Postoji osnovna pretpostavka faza koju treba shvatiti prije nego što započnemo duboke faze znanja. Riječ je o studiji izvodljivosti za softverski proizvod. Bavi se financijskim i tehničkim aspektima zahtjeva projekta. Ova faza bavi se ispravljanjem mjera na temelju analiziranih koristi i nedostataka. Tako je izabrano najbolje rješenje.

  1. Zahtjevi: Specifični po riječima, moramo znati i razumjeti što moramo dizajnirati, što moramo razviti, njegove procese, koja će biti njegova funkcionalnost itd. Pruža ulazni materijal proizvodu koji se izrađuje, a time i nadolazećem proizvodu proučava se, finalizira i obilježava. Također nam omogućava proširenje za odlučivanje o hardverskim ili softverskim zahtjevima proizvoda koji će biti dizajnirani, razvijeni i snimljeni u svim fazama.
  2. Analiza: Rezultat je dizajniranja modela, shema i poslovnih pravila. Ne samo da je ovaj zahtjev podijeljen u dva dijela:
  • Prikupljanje i analiza zahtjeva: Najprije se svi podaci i zahtjevi za razvoj proizvoda prikupe od kupca, a zatim se obrade na analizu. Glavna uloga ovog dijela je uklanjanje nepotpunosti i nedosljednosti u vezi s razvojem softverskih proizvoda.
  • Specifikacija zahtjeva: Tada su prethodno analizirani zahtjevi dokumentirani u SRS (specifikacija softverskog zahtjeva) dokumenta. Služi kao put između kupca i razvojnog tima SRS-a. Bilo kakvi sporovi u budućnosti rješavaju se i rješavaju samo kroz ovu dokumentaciju SRS-a.
  1. Dizajn: Nakon završetka i provjere prve faze to je sljedeća najvažnija faza koja se proučava jer se koristi za dizajn sustava. To vam pomaže u određivanju softverskog i hardverskog zahtjeva za dizajn proizvoda. Također pomaže u cjelokupnoj arhitekturi za dizajn sustava. Dakle, specifikacija zahtjeva uglavnom se proučava i provjerava u ovoj fazi. Također je korisno u pretvaranju SRS dokumenta u funkcionalni dizajn i razvoj softverskog proizvoda. Tako da možemo reći da se u fazi dizajniranja izrađuje cjelokupna arhitektura projekta razvoja softvera.
  2. Implementacija: S potpuno provjerenim dizajnom sustava, dolazi na red faza implementacije. U ovoj se fazi uzimaju inputi iz dizajna sustava i prvo se razvijaju u malim programima poznatim kao jedinice, koji se testira i provodi u narednoj fazi. Svaka jedinica u fazi implementacije prolazi kroz razvoj i testira se njena puna funkcionalnost koja je poznata i kao testiranje jedinice. U ovoj se fazi dizajn sustava pretvara u izvorni kod s potpuno funkcionalnim programskim modulima. To uključuje razvoj, dokazivanje i integraciju softvera.
  3. Integracija i testiranje: Svaka izvedba jedinice i razvijena u ranijim fazama uključena je iz faze primjene koja je integrirana u modul ili sustav za različita ispitivanja poput ispitivanja opterećenja, olovnog ispitivanja itd. Nakon testiranja svake jedinice. Okolina za testiranje podvrgava se stalnoj provjeri softvera kako bi se utvrdilo ima li protoka ili pogreške u dizajnu ili kodu. Testiranje se radi kako bi se održala stabilnost i izvedivost softvera tako da se klijent ne suoči s bilo kakvim smetnjama ili greškama tijekom proizvodnje. U ovoj fazi nakon implementacije cijeli se sustav temeljito ispituje na bilo kakve pogreške i nedostatke. Testiranje sustava sastoji se od tri različite vrste aktivnosti koje se mogu objasniti kao dolje:
  • Alpha (α) Ispitivanje: To je testiranje koje je obavio razvojni tim.
  • Beta (β) testiranje: to je testiranje prijavenog tima kupaca i korisnika.
  • Provjera prihvatljivosti: provodi se nakon alfa testiranja i beta testiranja. U osnovi, ovo testiranje se vrši nakon isporuke kupcima. Nakon testiranja koje izvršava kupac, donosi se odluka je li ovaj softver prihvatljiv ili ga odbiti. U ovoj fazi se u osnovi vrši uklanjanje pogrešaka.
  1. Upotreba sustava / Operacije: jednom kad se nefunkcionalno, funkcionalno, alfa i beta testiranje završi, proizvod softvera raspoređuje se na korisnikov ili korisnički sustav ili se pušta na tržište. Faza implementacije uključuje instalaciju, migraciju i podršku kompletnog sustava korisničkom ili korisničkom okruženju.
  2. Održavanje: To je posljednja, ali najvažnija faza u modelu toka slapa. Ovaj korak dolazi odmah nakon instalacije, a uključuje uvođenje odgovarajućih izmjena na proizvod ili sustav ili za poboljšanje, promjenu ili izmjenu atributa povezanih s problemom performansi u vezi sa sustavom. njegova glavna uloga je poboljšanje performansi sustava s maksimalnom preciznošću rezultata softvera. Ove promjene podignute tijekom faze održavanja uglavnom su povezane s promjenama koje je inicirao kupac ili korisnici nakon faze instalacije i testiranja, a koje uključuju greške poput oštećenja otkrivenih tijekom aktivnog korištenja sustava ili zahtjeva koji su postavili kupci. Dakle, klijentu se pruža pravovremeno i redovito održavanje i podrška za razvijeni proizvod. Zaista ćete biti zaprepašteni kada znate da je trud uložen u fazu dizajna i razvoja softverskog proizvoda samo 60% napora u odnosu na napore uložene u fazi održavanja. U osnovi postoje tri vrste održavanja što je objašnjeno u nastavku:
  • Korektivno održavanje: Neke greške se tijekom faze dizajniranja i razvoja ne otkriju, one uzimaju u obzir samo kada korisnik koristi. Ovo je samo korektivno održavanje što znači ispravljanje problema ili pogreške koje nisu otkrivene u fazi razvoja.
  • Savršeno održavanje: Ova vrsta održavanja provodi se na zahtjev kupca radi povećanja i poboljšanja funkcionalnosti sustava ili softvera.
  • Prilagodljivo održavanje: održavanje je potrebno za prebacivanje okruženja sustava. Obično je potreban za prijenos postojećeg sustava u novo okruženje ili novo računalo ili sustav ili možda s novim operativnim sustavom. Ova je faza previše važna, jer vodi boljim performansama sustava.

Tako smo u gornjoj raspravi duboko upoznali svaku fazu modela vodopada s potpunim specifikacijama. Dakle, možemo reći da je vodopadni model vrlo važan iu softverskom polju, u usporedbi s mehaničkom industrijom, jer svaka faza ima svoju važnost, dovodi do stvaranja produktivnijeg i stabilnijeg softvera.

prednosti

Ne samo da ovaj model vodopada ima i mnogo više prednosti u životnom ciklusu razvoja softvera, o kojima može biti govora u nastavku:

  • Omogućuje departmentalizaciju i kontrolu.
  • Raspored se može postaviti s rokovima za svaku fazu razvoja i proizvod može postupno prolaziti kroz faze razvojnog procesa.
  • Budući da prolazi kroz lako razumljive i razumljive faze, prevladava mnoga pitanja, pa je vrlo jednostavan za korištenje.
  • Zbog krutosti modela tijeka rada, vrlo je jednostavno upravljati jer svaka faza u modelu vodopada ima specifične procese pregleda i rezultata.
  • Model slapova dobro uspijeva za manje projekte gdje se zahtjevi vrlo dobro razumiju.
  • Raspored se može postaviti s rokovima za svaku fazu razvoja, a proizvod može postupno prolaziti kroz faze razvojnog procesa.
  • Jasno definirane faze.
  • Dobro razumjene prekretnice.
  • Lako dogovoriti zadatke.
  • Proces i rezultati dobro su dokumentirani.
  • Pojačava dobre navike: definirati prije dizajna,
  • Dizajn-prije-koda.
  • Model dobro funkcionira za manje projekte i projekte gdje se zahtjevi dobro razumiju.

Hendikep

Kao što znamo da svaki novčić ima dva lica, tako da uz veliki pristup prednostima modela vodopada, model vodopada ima i neke nedostatke ili možete reći nedostatke koji su spomenuti u nastavku:

  • Nije dobar model za složene i objektno orijentirane projekte.
  • Nije pogodno za projekte u kojima su zahtjevi umjereni do visoki rizik promjene.
  • Teško je procijeniti vrijeme i troškove za svaku fazu razvojnog procesa.
  • Nije dobar model za složene i objektno orijentirane projekte.
  • Nijedan radni softver ne proizvodi se do kasno tijekom životnog ciklusa.
  • Ne mogu se prilagoditi promjenjivim zahtjevima.
  • Teško je mjeriti napredak u fazama.
  • Visoke količine rizika i nesigurnosti.
  • Loš model za duge i tekuće projekte.
  • Podešavanje opsega tijekom životnog ciklusa može završiti projekt.
  • Nema povratnih informacija
  • Nema preklapanja faza
  • Teško udovoljiti zahtjevima za promjenom.
  • rizik i neizvjesnost su visoki kod ovog modela procesa.

Gdje koristiti model vodopada

Nakon opkoljavanja svih scenarija, došli smo do točke u kojoj želimo znati gdje se koristi model vodopada.

  • Model vodopada uglavnom se koristi u obrambenom projektu, a zahtjev je jasan, prije nego što prijeđu u razvojnu fazu, oni ga dobro analiziraju.
  • To se također može koristiti u migracijskim projektima u kojima će zahtjevi biti isti, a samo se platforma ili jezici mogu mijenjati / mijenjati.

Zaključak

Dakle, u cjelini mogu reći da je vodopadni model najprikladniji za male projekte razvoja softvera u usporedbi s velikim projektima jer su dizajn, razvoj i implementacija u malom projektu lakši kada se radi na modelu vodopada, jer su u ovom modelu potrebne sve prethodne faze biti dovršen pri prelasku na nadolazeće faze. Dakle, u velikom projektu problemi i pogreške često se javljaju jer ima velik model, tako da će se svaki put faza testiranja nastaviti ako se provodi kroz model vodopada, što će dovesti do manje optimizacije i točnosti softvera.

Preporučeni članci

Ovo je vodič za model vodopada. Ovdje smo razgovarali o fazama, prednostima i nedostacima modela vodopada. Možete i proći naše druge predložene članke da biste saznali više -

  1. Što je AWS?
  2. Što je Bootstrap?
  3. Što je košnica?
  4. Što je Unix?
  5. Scrum vs Vodopad | usporedba

Kategorija:

Razvoj softvera