Úvod do vodopádového modelu
Pochádza zo stavebníctva a výrobného priemyslu a je vysoko štruktúrovaným fyzickým prostredím určeným pre procesy návrhu a vývoja. Model vodopádu je známy aj ako model životného cyklu vývoja softvéru. Bol to prvý model procesu predstavený ako lineárny-sekvenčný model životného cyklu. Model vodopádu jednoducho hovorí, že jav úplne dokončí jednu fázu pred začatím novej fázy vývoja, aby nedošlo k prekrývaniu fáz. V oblasti vývoja softvéru sa vodopádový model prvýkrát použil ako prístup SDLC. Aby sme mohli pracovať na vodopádovom modeli, musíme pochopiť jeho aplikačný prístup založený na vnútorných aj vonkajších faktoroch, ktoré môžu byť tieto:
- Žiadne nejednoznačné požiadavky v žiadosti.
- Stabilita definície výrobku
- Je to technológia pochopená
- Nie je to dynamické
- Na podporu produktu sú k dispozícii veľké zdroje s primeranými odbornými znalosťami
- Vey krátky projekt
- Dobrý dokument, jasné a pevné požiadavky.
Na začiatok histórie vodopádového modelu by som chcel povedať, že prvú vzorku vodopádového modelu predstavil v roku 1970 Winston w Royce vo svojom článku. Od tej doby model vodopádu uvádza, že človek by mal prejsť na inú fázu, len ak sú predchádzajúce fázy úplne testované, preskúmané a overené. Zdôrazňuje logický postup fázových krokov. Jeho funkčnosť je podobná prietokom vody cez okraj útesu. Tento prístup k vývoju softvéru dostal názov vodopád, pretože sa systematicky vyvíja z jednej fázy do druhej smerom nadol. Od svojho prvého vydania Winstonom W. Roycom v roku 1970 sa vodopádový model v oblasti vývoja softvéru hojne používa. V procesnom cykle vývoja softvéru sa programovacie modely používajú na plánovanie rôznych fáz vývoja aplikácie. Jedným takýmto modelom je vodopádový model.
Fázy vodopádového modelu
Teraz sa porozprávajte o fázach vodopádového modelu, ktorý je možné jasne vysvetliť prostredníctvom tejto demografickej infographic.
S vyššie uvedenými informáciami môžeme pochopiť, že model vodopádu má celkom 7 fáz softvérového cyklu navrhovania a vývoja, ktoré sú nasledujúce:
- požiadavky
- analýza
- dizajn
- Kódovanie / vykonávanie
- testovanie
- Prevádzka / nasadenie
- údržba
Takže vidíme, že vodopádový model funguje hierarchiou zhora nadol, pričom jedna fáza je ukončená úplnými overeniami a potom prechádza do inej fázy vrátane fázových procesov, ako je koncepcia, začatie, analýza, návrh, konštrukcia, testovanie, výroba / implementácia a údržba. Aby sme získali stručnejšie vedomosti o vodopádovom modeli, musíme hlbšie porozumieť všetkým jeho procesom s jeho pracovným modelom. Pred začatím hlbokých fáz poznania je potrebné pochopiť základnú nevyhnutnú fázu. Je to o štúdii uskutočniteľnosti softvérového produktu. Zaoberá sa finančnými a technickými aspektmi požiadaviek projektu. Táto fáza sa zaoberá opravou opatrení na základe analyzovaných výhod a nevýhod. Preto sa vyberie najlepšie riešenie.
- Požiadavky: Ako je konkrétne povedané, potrebujeme poznať a porozumieť tomu, čo musíme navrhnúť, čo musíme vyvíjať, jeho procesy, čo bude jeho funkčnosť atď. Poskytuje vstupný materiál pre vyrábaný produkt, a teda pre nadchádzajúci produkt. je študovaný, finalizovaný a označený. Poskytuje tiež rozšírenie na rozhodovanie o hardvérových alebo softvérových požiadavkách na produkt, ktorý bude navrhnutý, vyvinutý a zachytený vo všetkých fázach.
- Analýza: Výsledkom je navrhovanie modelov, schém a obchodných pravidiel. Nielen táto požiadavka je rozdelená na dve časti:
- Zhromažďovanie požiadaviek a analýza: Najskôr sa zhromaždia všetky informácie a požiadavky na vývoj produktu od zákazníka a potom sa spracujú na analýzu. Hlavnou úlohou tejto časti je odstrániť neúplnosť a nezrovnalosti súvisiace s vývojom softvérových produktov.
- Špecifikácia požiadaviek: Potom sú vyššie analyzované požiadavky zdokumentované v dokumente SRS (špecifikácia softvérových požiadaviek). Slúži ako cesta medzi zákazníkom a vývojovým tímom SRS. Všetky spory v budúcnosti sa budú riadiť a urovnávať iba prostredníctvom tejto dokumentácie SRS.
- Dizajn: Po dokončení a overení prvej fázy je to ďalšia najdôležitejšia fáza, ktorá sa má študovať, pretože sa používa na návrh systému. Pomáha pri určovaní softvérových a hardvérových požiadaviek na návrh produktu. Pomáha tiež v celkovej architektúre pre návrh systému. Špecifikácia požiadaviek sa teda väčšinou skúma a overuje v tejto fáze. Pomáha tiež pri transformácii dokumentu SRS na funkčný návrh a vývoj softvérového produktu. Dá sa teda povedať, že vo fáze projektovania sa vytvára celková architektúra projektu vývoja softvéru.
- Implementácia: Po úplnom overení návrhu systému je fáza implementácie v rade. V tejto fáze sa prijímajú vstupy z návrhu systému a najprv sa vyvíjajú v malých programoch známych ako jednotky, ktoré sa v nadchádzajúcej fáze testujú a implementujú. Každá jednotka vo fáze implementácie prechádza vývojom a testuje sa jej úplná funkčnosť, ktorá je známa aj ako testovanie jednotky. V tejto fáze sa návrh systému prevedie na zdrojový kód s plne funkčnými programovými modulmi. Zahŕňa vývoj, testovanie a integráciu softvéru.
- Integrácia a testovanie: Každá konštrukcia a vývoj jednotky vyvinuté v predchádzajúcich fázach sú začlenené z fázy implementácie, ktorá je integrovaná do modulu alebo systému pre rôzne skúšky, ako je záťažový test, test elektródy atď. Po testovaní každej jednotky. Testovacie prostredie prechádza stálou kontrolou softvéru, aby sa zistilo, či v návrhu alebo kóde nie sú nejaké toky alebo chyby. Testovanie sa vykonáva na udržanie stability a uskutočniteľnosti softvéru tak, aby klient počas svojej výroby nebol vystavený žiadnym poruchám ani chybám. Takže v tejto fáze po implementácii je celý systém dôkladne testovaný na akékoľvek poruchy a poruchy. Testovanie systému pozostáva z troch rôznych typov činností, ktoré je možné vysvetliť nižšie:
- Alfa (α) testovanie: Je to testovanie vykonané vývojovým tímom.
- Beta (β) testovanie: Je to testovanie vykonané priateľským tímom zákazníkov a používateľov.
- Akceptačné testovanie: vykonáva sa po testovaní alfa a beta. Toto testovanie sa v zásade vykonáva po doručení zákazníkom. Po testovaní vykonanom zákazníkom sa rozhodne, či je tento softvér prijateľný alebo ho odmietne. Takže v tejto fáze sa v podstate vykonáva ladenie chýb.
- Nasadenie systému / operácií: po ukončení nefunkčného, funkčného, alfa a beta testovania sa produkt softvéru umiestni do systému používateľa alebo zákazníka alebo sa uvedie na trh. Fáza zavádzania zahŕňa inštaláciu, migráciu a podporu celého systému do prostredia používateľa alebo zákazníka.
- Údržba: Je to posledná, ale najdôležitejšia fáza modelu vodopádového workflow. Tento krok prichádza hneď po inštalácii a zahŕňa vykonanie vhodnej úpravy produktu alebo systému alebo vylepšenie, zmenu alebo úpravu atribútov súvisiacich s problémom s výkonom týkajúcim sa systému. jeho hlavnou úlohou je zlepšovať výkon systému s výsledkom maximálnej presnosti výstupu softvéru. Tieto zmeny vyvolané počas fázy údržby sa vo veľkej miere týkajú zmien, ktoré sa začali vykonávať zákazníkom alebo používateľmi po fáze inštalácie a testovania, ktorá zahŕňa chyby, ako sú chyby odhalené počas živého používania systému alebo požiadavky vznesené zákazníkmi. Klientovi je tak poskytnutá včasná a naplánovaná údržba a podpora pre vyvíjaný produkt. Skutočne vás ohromí, keď viete, že úsilie vynaložené vo fáze návrhu a vývoja softvérového produktu je iba 60% úsilie v porovnaní s úsilím vo fáze údržby. V zásade existujú tri druhy údržby, ktoré sú vysvetlené nižšie:
- Nápravná údržba: Počas fázy návrhu a vývoja sa niektoré chyby nezistia, berú do úvahy iba pri použití zákazníkom. Ide iba o opravnú údržbu, ktorá znamená opravu problémov alebo chýb, ktoré neboli odhalené vo vývojovej fáze.
- Perfektná údržba: Tento typ údržby sa vykonáva na žiadosť zákazníka s cieľom zvýšiť a vylepšiť funkčnosť systému alebo softvéru.
- Adaptívna údržba: je to údržba, ktorá sa vyžaduje na prepínanie systémového prostredia. Zvyčajne sa vyžaduje na prenos existujúceho systému do nového prostredia alebo nového počítača alebo systému alebo prípadne do nového operačného systému. Táto fáza je príliš dôležitá, pretože vedie k lepšiemu výkonu systému.
Takže vo vyššie uvedenej diskusii sme hlboko spoznali každú fázu vodopádového modelu s úplnými špecifikáciami. Môžeme teda povedať, že vodopádový model je v softvérovej oblasti veľmi dôležitý aj v porovnaní s mechanickým priemyslom, pretože každá fáza má svoj vlastný význam, čo vedie k vytvoreniu produktívnejšieho a stabilnejšieho softvéru.
výhody
Nielen tento vodopádový model má aj mnoho ďalších výhod v životnom cykle vývoja softvéru, o ktorom sa dá hovoriť nižšie:
- Umožňuje oddelenie a kontrolu.
- Pre každú fázu vývoja možno stanoviť časový harmonogram a produkt môže postupovať fázami modelu vývojového procesu jednu po druhej.
- Keďže prechádza ľahko zrozumiteľnými a vysvetliteľnými fázami, prekonáva mnoho problémov, takže sa veľmi ľahko používa.
- Vzhľadom na rigiditu modelu pracovného toku je jeho zvládnutie veľmi ľahké, pretože každá fáza modelu vodopádu má špecifické procesy preskúmania a výstupov.
- Model vodopádu funguje dobre pre menšie projekty, kde sú požiadavky dobre pochopené.
- Časový rozvrh je možné stanoviť s konečnými termínmi pre každú fázu vývoja a produkt môže postupovať fázami modelu vývojového procesu jednu po druhej.
- Jasne definované fázy.
- Dobre zrozumiteľné míľniky.
- Ľahko zariadiť úlohy.
- Proces a výsledky sú dobre zdokumentované.
- Posilňuje dobré návyky: definujte pred návrhom,
- Design-before-kódu.
- Model funguje dobre pre menšie projekty a projekty, kde sú požiadavky dobre pochopené.
nevýhoda
Ako vieme, každá minca má dve tváre, takže s veľkým prístupom k výhodám modelu vodopádu má model vodopádu aj určité nevýhody alebo môžete uviesť nevýhody, ktoré sú uvedené nižšie:
- Nie je to dobrý model pre komplexné a objektovo orientované projekty.
- Nie je vhodné pre projekty, kde sú požiadavky mierne alebo vysoké.
- Je ťažké odhadnúť čas a náklady pre každú fázu procesu vývoja.
- Nie je to dobrý model pre komplexné a objektovo orientované projekty.
- Až do konca životného cyklu sa nevyrába žiadny pracovný softvér.
- Nemôže vyhovieť meniacim sa požiadavkám.
- Je ťažké merať pokrok vo fázach.
- Vysoká miera rizika a neistoty.
- Zlý model pre dlhé a prebiehajúce projekty.
- Úprava rozsahu počas životného cyklu môže projekt ukončiť.
- Žiadna cesta spätnej väzby
- Žiadne prekrývanie fáz
- Je ťažké vyhovieť požiadavkám na zmeny.
- Pri tomto modeli procesu sú riziká a neistota vysoké.
Kde použiť vodopádový model
Po obkľúčení všetkých scenárov sme dospeli k bodu, v ktorom chceme vedieť, kde používať vodopádový model.
- V obrannom projekte sa používa prevažne model vodopádu, pretože požiadavka je jasná, pretože pred prechodom do vývojovej fázy ho dobre analyzujú.
- To sa dá použiť aj v migračných projektoch, kde budú požiadavky rovnaké. Iba platforma alebo jazyky sa môžu meniť / meniť.
záver
Takže ako celok môžem povedať, že vodopádový model je najvhodnejší pre malý projekt vývoja softvéru v porovnaní s veľkými projektmi, pretože dizajn, vývoj a implementácia je v malom projekte jednoduchšia pri práci na vodopádovom modeli, pretože v tomto modeli sú potrebné všetky predchádzajúce fázy. sa má dokončiť pri prechode na nadchádzajúce fázy. Vo veľkom projekte sa preto problémy a chyby vyskytujú často, pretože má veľký model, takže zakaždým, keď bude implementovaná prostredníctvom modelu vodopádu, bude pokračovať testovacia fáza, čo povedie k menšej optimalizácii a presnosti softvéru.
Odporúčané články
Toto bol sprievodca po vodopádovom modeli. Tu sme diskutovali o fázach, výhodách a nevýhodách vodopádového modelu. Viac informácií nájdete aj v ďalších navrhovaných článkoch -
- Čo je AWS?
- Čo je to Bootstrap?
- Čo je Úľ?
- Čo je Unix?
- Scrum vs Vodopád Porovnanie