Úvod do vodopádového modelu

Pochází ze stavebnictví a zpracovatelského průmyslu, jedná se o vysoce strukturované fyzické prostředí určené pro procesy návrhu a vývoje. Waterfall model je také známý jako model životního cyklu vývoje softwaru. Byl to první model procesu představený jako lineárně-sekvenční model životního cyklu. Waterfall model jednoduše říká, že jev dokončí jednu fázi před zahájením nové fáze vývoje, takže nedochází k překrývání fází. V oblasti vývoje softwaru byl nejprve použit vodopádový model jako přístup SDLC. Abychom mohli pracovat na vodopádovém modelu, musíme pochopit jeho aplikační přístup založený na interních i externích faktorech, které mohou být následující:

  • Žádné nejednoznačné požadavky v aplikaci.
  • Stabilita definice produktu
  • Je to technologie chápaná
  • Není dynamický
  • Pro podporu produktu jsou k dispozici velké zdroje s odpovídající odborností
  • Vey krátký projekt
  • Dobrý dokument, jasné a pevné požadavky.

Na začátku historie vodopádového modelu bych rád řekl, že první vzorek vodopádového modelu byl představen v roce 1970 Winstonem w Roycem v článku. Od té doby model vodopádu uvádí, že člověk by měl přejít do jiné fáze, pouze pokud jsou předchozí fáze úplně testovány, přezkoumány a ověřeny. Zdůrazňuje logický postup fázových kroků. Jeho funkce je podobná toku vody přes okraj útesu. Tento přístup k vývoji softwaru dostal název vodopád, protože se systematicky vyvíjí z jedné fáze do druhé sestupně. Od doby, kdy byl poprvé publikován Winstonem W. Roycem v roce 1970, se model vodopádu široce používá v oblasti vývoje softwaru. V procesním cyklu vývoje softwaru se programovací modely používají k plánování různých fází vývoje aplikace. Jedním takovým modelem je vodopádový model.

Fáze vodopádového modelu

Nyní pojďme hovořit o fázích vodopádového modelu, které lze jasně vysvětlit pomocí tohoto demo infographic.

S výše uvedenými infografiky můžeme pochopit, že model vodopádu má celkem 7 fází softwarového cyklu návrhu a vývoje, které jsou následující:

  1. Požadavky
  2. Analýza
  3. Design
  4. Kódování / implementace
  5. Testování
  6. Provoz / nasazení
  7. Údržba

Můžeme tedy vidět, že model vodopádu funguje hierarchicky shora dolů s jednou fází dokončenou úplnými verzemi a poté přechází do jiné fáze včetně fázových procesů, jako je koncepce, zahájení, analýza, návrh, konstrukce, testování, výroba / implementace a údržba. Abychom získali podrobnější informace o modelu vodopádu, musíme pochopit všechny jeho procesy v hloubce s jeho pracovním modelem. Před zahájením hlubokých fází poznání je třeba pochopit základní fázi nezbytných předpokladů. Jedná se o studii proveditelnosti softwarového produktu. Zabývá se finančními a technickými aspekty projektových požadavků. Tato fáze se zabývá opravou opatření na základě analyzovaných přínosů a nevýhod. Tím je vybráno nejlepší řešení.

  1. Požadavky: Jak je specificky řečeno, potřebujeme vědět a rozumět tomu, co musíme navrhnout, co musíme vyvinout, jeho procesy, co bude jeho funkčnost atd. Poskytuje vstupní materiál pro vyráběný produkt, a tedy pro nadcházející produkt je studován, finalizován a označen. Také nám poskytuje rozšíření pro rozhodnutí o hardwarových nebo softwarových požadavcích na produkt, který bude navržen, vyvinut a zachycen ve všech fázích.
  2. Analýza: Výsledkem je navrhování modelů, schémat a obchodních pravidel. Nejen tento požadavek je rozdělen do dvou částí:
  • Shromažďování požadavků a analýza: Nejprve jsou shromážděny všechny informace a požadavky na vývoj produktu od zákazníka a poté jsou zpracovány pro analýzu. Hlavní úlohou této části je odstranit neúplnost a nesrovnalosti související s vývojem softwarového produktu.
  • Specifikace požadavků: Poté jsou výše analyzované požadavky zdokumentovány v dokumentu SRS (specifikace softwarových požadavků). Slouží jako cesta mezi zákazníkem a vývojovým týmem SRS. Veškeré spory v budoucnu budou řešeny a řešeny pouze prostřednictvím této dokumentace SRS.
  1. Návrh: Po dokončení a ověření první fáze je to další nejdůležitější fáze, která se má studovat, protože se používá pro návrh systému. Pomáhá při určování požadavků na software a hardware pro návrh produktu. Pomáhá také v celkové architektuře pro návrh systému. V této fázi je tedy specifikace požadavků většinou studována a ověřována. Pomáhá také při transformaci dokumentu SRS do funkčního návrhu a vývoje softwarového produktu. Můžeme tedy říci, že ve fázi projektování vytváříme celkovou architekturu projektu vývoje softwaru.
  2. Implementace: S plně ověřeným návrhem systému přichází fáze implementace do řádku. V této fázi jsou převzaty vstupy z návrhu systému a je nejprve vyvinuto v malých programech známých jako jednotky, které jsou testovány a implementovány v nadcházející fázi. Každá jednotka ve fázi implementace prochází vývojem a je testována její úplná funkčnost, která se také nazývá testování jednotek. V této fázi je tedy návrh systému převeden na zdrojový kód s plně funkčními moduly programů. Zahrnuje vývoj, testování a integraci softwaru.
  3. Integrace a testování: Každá konstrukce a vývoj jednotky v dřívějších fázích jsou začleněny z fáze implementace, která je integrována do modulu nebo systému pro různé zkoušky, jako je zátěžový test, test olova atd. Po testování každé jednotky. Testovací prostředí prochází stálou kontrolou softwaru, aby se zjistilo, zda v návrhu nebo kódu nejsou nějaké toky nebo chyby. Testování se provádí za účelem udržení stability a proveditelnosti softwaru tak, aby klient během své výroby nebyl vystaven žádným poruchám ani chybám. Takže v této fázi po implementaci je celý systém důkladně testován na případné poruchy a poruchy. Testování systému se skládá ze tří různých typů činností, které lze vysvětlit níže:
  • Alpha (α) Testování: Jedná se o testování prováděné vývojovým týmem.
  • Beta (β) testování: Jedná se o testování provedené přátelským týmem zákazníků a uživatelů.
  • Akceptační testování: provádí se po testování alfa a beta. V zásadě se toto testování provádí po dodání zákazníky. Po testování provedeném zákazníkem se rozhodne, zda je tento software přijatelný nebo jej odmítne. Takže v této fázi se v podstatě provádí ladění chyb.
  1. Nasazení systému / operací: jakmile je provedeno nefunkční, funkční, alfa a beta testování, je produkt softwaru nasazen do systému uživatele nebo zákazníka nebo je uveden na trh. Fáze nasazení zahrnuje instalaci, migraci a podporu celého systému do prostředí uživatele nebo zákazníka.
  2. Údržba: Je to poslední, ale nejdůležitější fáze modelu vodopádového pracovního postupu. Tento krok přichází těsně po instalaci a zahrnuje provedení vhodné úpravy produktu nebo systému nebo zlepšení, změnu nebo úpravu atributů souvisejících s výkonem souvisejícím se systémem. jeho hlavní úlohou je zlepšit výkon systému s výsledkem maximální přesnosti výstupu softwaru. Tyto změny vyvolané během fáze údržby souvisejí hlavně se změnami zahájenými k provedení zákazníkem nebo uživateli po fázi instalace a testování, která zahrnuje chyby, jako je vada odkrytá během živého používání systému nebo požadavek vznesený zákazníky. Klientovi je tak poskytována včasná a plánovaná údržba a podpora vyvíjeného produktu. Budete opravdu ohromeni, když víte, že úsilí vynaložené ve fázi vývoje a vývoje softwarového produktu je pouze 60% úsilí ve srovnání s úsilím ve fázi údržby. V zásadě existují tři typy údržby, které jsou vysvětleny níže:
  • Opravná údržba: Během fáze návrhu a vývoje nejsou některé chyby objeveny, berou v úvahu pouze při použití zákazníkem. Jedná se pouze o opravnou údržbu, která znamená opravu problémů nebo chyb, které nebyly objeveny ve vývojové fázi.
  • Perfektní údržba: Tento typ údržby se provádí na žádost zákazníka s cílem zvýšit a zlepšit funkčnost systému nebo softwaru.
  • Adaptivní údržba: je to údržba, která je nutná pro přepínání systémového prostředí. Obvykle se vyžaduje pro přenesení existujícího systému do nového prostředí nebo nového počítače nebo systému nebo možná s novým operačním systémem. Tato fáze je příliš důležitá, protože vede k lepšímu výkonu systému.

Ve výše uvedené diskusi jsme tedy hlouběji poznali každou fázi vodopádového modelu s plnými specifikacemi. Můžeme tedy říci, že model vodopádu je v softwarovém poli velmi důležitý také ve srovnání s mechanickým průmyslem, protože každá fáze má svůj vlastní význam, což vede k vytvoření produktivnějšího a stabilnějšího softwaru.

Výhody

Nejen tento vodopádový model má také mnoho dalších výhod v životním cyklu vývoje softwaru, o kterém se dá diskutovat níže:

  • Umožňuje oddělení a kontrolu.
  • Pro každou fázi vývoje lze stanovit časový rozvrh a produkt může procházet fázemi modelu vývojového procesu jeden po druhém.
  • Protože prochází snadno pochopitelnými a vysvětlitelnými fázemi, překonává mnoho problémů, takže je velmi snadné použití.
  • Vzhledem k rigiditě modelu pracovního postupu je řízení velmi snadné, protože každá fáze modelu vodopádu má specifické procesy kontroly a výstupů.
  • Model vodopádu funguje dobře pro menší projekty, kde jsou požadavky dobře známy.
  • Časový rozvrh může být stanoven s termíny pro každou fázi vývoje a produkt může procházet fázemi modelu vývojového procesu jeden po druhém.
  • Jasně definované fáze.
  • Dobře chápané milníky.
  • Snadno uspořádat úkoly.
  • Proces a výsledky jsou dobře zdokumentovány.
  • Posiluje dobré návyky: definujte před designem,
  • Návrh před kódem.
  • Model funguje dobře pro menší projekty a projekty, kde jsou dobře známy požadavky.

Nevýhoda

Jak víme, že každá mince má dvě tváře, takže s velkým přístupem k výhodám modelu vodopádu má model vodopádu také určité nevýhody nebo můžete uvést nevýhody, které jsou popsány níže:

  • Není to dobrý model pro komplexní a objektově orientované projekty.
  • Nevhodné pro projekty, u nichž jsou požadavky mírně až vysoce rizikové.
  • Je obtížné odhadnout čas a náklady pro každou fázi procesu vývoje.
  • Není to dobrý model pro komplexní a objektově orientované projekty.
  • Až do konce životního cyklu se nevyrábí žádný pracovní software.
  • Nelze vyhovět měnícím se požadavkům.
  • Je obtížné měřit pokrok ve fázích.
  • Vysoká míra rizika a nejistoty.
  • Špatný model pro dlouhé a probíhající projekty.
  • Úprava rozsahu během životního cyklu může projekt ukončit.
  • Žádná cesta zpětné vazby
  • Žádné překrývání fází
  • Obtížné vyhovět požadavkům na změnu.
  • riziko a nejistota jsou u tohoto procesního modelu vysoké.

Kde použít vodopádový model

Nyní po obklíčení všech scénářů se dostáváme do bodu, kdy chceme vědět, kde použít vodopádový model.

  • V obranném projektu se používá převážně vodopádový model, protože požadavek je jasný, protože před přechodem do vývojové fáze jej dobře analyzují.
  • To lze také použít v projektech migrace, kde požadavky budou stejné, pouze platforma nebo jazyky se mohou lišit / změnit.

Závěr

Takže jako celek mohu říci, že vodopádový model je nejvhodnější pro malý projekt vývoje softwaru ve srovnání s velkými projekty, protože design, vývoj a implementace je v malém projektu jednodušší při práci na vodopádovém modelu, protože v tomto modelu je třeba všech předchozích fází být dokončen při přechodu na nadcházející fáze. Ve velkém projektu tedy problémy a chyby přicházejí často, protože má velký model, takže pokaždé bude testovací fáze pokračovat, pokud bude implementována pomocí vodopádového modelu, což povede k menší optimalizaci a přesnosti softwaru.

Doporučené články

Toto byl průvodce Waterfall Model. Zde jsme diskutovali o fázích, výhodách a nevýhodách vodopádového modelu. Další informace naleznete také v dalších navrhovaných článcích -

  1. Co je AWS?
  2. Co je Bootstrap?
  3. Co je Úl?
  4. Co je Unix?
  5. Scrum vs Vodopád | Srovnání

Kategorie:

Vývoj softwaru