Vodopádový model

Vodopádový model životního cyklu software (The waterfall Life cycle)

Nejstarší model životního cyklu software se nazývá Vodopádový. Jeho pojmenování vychází z přirovnání posloupnosti jednotlivých fází k protékání vody vodopádem, jak je znázorněno na obrázku 1. Winston W. Royce jej poprvé definoval ve svém článku „Managing the Development of Large Software System“ v roce 1970 [1]. Model byl vyvinut s cílem lépe se vyrovnat s rostoucí složitostí produktů leteckému průmyslu. Royce se ve svém článku zmiňuje o sedmi základních fázích:

• Systémové požadavky (System requirements)
• Softwarové požadavky (Software requirements)
• Analýza (Analysis)
• Návrh programu (Program design)
• Implementace (Coding)
• Testování (Testing)
• Provoz (Operations)

Základní myšlenka vodopádového modelu, vychází ze sekvenčního přístupu k jednotlivým fázím. Model je charakteristický tím, že vstoupit do další fáze mohu až tehdy, pokud je předchozí kompletně dokončena a uzavřena.

S úspěchem lze model využít tehdy, pokud je počátečním fázím věnováno dostatek času. Jen tak lze přijít k vyšším úsporám v pozdějších fázích životního cyklu. Odhalení a odstranění chyby, která je objevena v počátcích životního cyklu (např. v analýze), je mnohem levnější než kdybychom tutéž chybu opravovali později (např. při testování) [2]. V průběhu realizace projektu může nastat situace, kdy návrh programu nelze z nějakého důvodu implementovat. Pokud je tato skutečnost zjištěna již ve fázi návrhu, je přepracování návrhu mnohem jednodušší, než kdyby byla chyba v návrhu objevena v dalších fázích. Chceme-li tedy postupovat přesně podle vodopádového modelu, musíme si být na konci každé fáze maximálně jisti její validací a kompletností. Jen tak lze úspěšně zahájit následující fázi cyklu.

Hlavní nevýhodou Vodopádového modelu je fakt, že v praxi, zejména u rozsáhlejších projektů, nelze prakticky dokončit jednu fázi a zahájit další, beztoho aniž bych se k ní v budoucnu opět vrátil. Požadavky klientů se mohou v průběhu realizace programu měnit. Klient může vznášet další požadavky po zhlédnutí prototypu. V takovýchto případech je nutné zapracovat změny do specifikace a veškeré dokumentace.

Mezi další nevýhody patří prakticky nulová možnost reagovat v průběhu vývojového cyklu na pozměňovací požadavky zákazníka. Finální verze aplikace je zákazníkovi předána až v době, kdy se již nelze vrátit do fází oprav a úprav. Toto riziko může vést k neúspěchu celého projektu. Z pohledu testování je pak velmi nešťastné, když fáze testování nastává až po samotné implementaci, tedy ve chvíli kdy je aplikace téměř připravena na předání zákazníkovi. Opravy chyb v této fázi jsou časově mnohem náročnější, než např. ve fázi návrhu. Pokud se takto objeví chyba v analýze, může vyústit až v kompletní přepracování projektu.

Vodopádový model je jednoduchý a snadno pochopitelný. Jeho požívání vyžaduje, aby implementace postupovala přesně podle prověřeného návrhu. Tím je zajištěna snadná integrace systému. Zpravidla bývá využit u menších projektů, kde se nepočítá s pozdějšími změnami funkcionalit či vlastností celého výsledného programu.

Z původního modelu, který představil Royce, v současné době vychází spousta modifikací. Tyto modifikace se snaží vyřešit jeho nedostatky. Na druhou stranu, spousta modelů životního cyklu software, bude mít určitou podobnost s vodopádovým. Většina soudobých modelů totiž obsahuje fáze, jejichž návaznost se může podobat těm ze schématu vodopádového modelu. Jako příklady životních cyklů, vycházejících z Royceova původního modelu, lze uvést např. V – životní cyklus (The V Life Cycle) nebo Sashimi apod.

Vodopádový model, tak jak jej původně představil Royce, se dnes díky výše zmíněným nedostatkům v praxi příliš nepoužívá. Zejména pak plánování procesu testování až téměř na konec celého modelu, neumožňuje v dnešní době vodopádový model využít v praxi. Dnes se tento model využívá především k výukovým účelům. Snadno se na něm velmi jednoduše demonstruje model životního cyklu software. Přes to všechno jej lze s určitými úpravami použít u drobnějších projektů, kde například není dostatečný časový nebo finanční prostor pro plánování (což ovšem samo o sobě není příliš šťastné a může se to negativně projevit na pravděpodobnosti bezporuchovosti provozu softwaru).

[1]   ROYCE, Winston. Managing the Development of Large Software Systems [online]. Proceedings of IEEE WESCON, 1970. Dostupný na WWW: <http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf>

[2]   BOEHM, Barry and Papaccio N. Understanding and Controlling Software Costs. In IEEE Transactions on Software Engineering. TRW Inc., Redondo Beach, CA. roč. 14, č. 10, 1988, str. 1462-1477. ISSN 0098-5589.