Vodopádový model

Vodopádový model je sekvenční vývojový proces, ve kterém je vývoj nahlížen jako neustále se svažující tok (jako když teče vodopád) fázemi analýzy požadavků, návrhu, implementace, testování (validace), integrace a údržby.

Jako první formální popis vodopádového modelu je často citován článek publikovaný v roce 1970 Winstonem W. Roycem (1929–1995),^[1] ačkoli Royce pojem „vodopádový“ ve svém článku nepoužil. Royce paradoxně představil tento model jako příklad chybného, nefungujícího modelu.^[2] Takto byl také ve skutečnosti tento pojem v článcích o vývoji softwaru používán – jako forma kritiky běžně praktikovaných softwarových postupů.^[3] V opozici vůči vodopádovému modelu stojí agilní metodiky.

Roycův původní vodopádový model obsahuje sedm fází v následujícím pořadí:

1. Specifikace požadavků
2. Návrh
3. Implementace
4. Integrace
5. Testování a ladění (validace)
6. Instalace
7. Údržba

Postupovat podle vodopádového modelu znamená přecházet od jedné fáze k následující přísně sekvenčním způsobem. Nejprve se například připraví specifikace požadavků, které jsou pevně dané. Teprve když jsou požadavky úplně kompletní, přejde se k návrhu. Požadovaný software je navržen a návrh předán implementátorům – návrh by měl být jakýmsi plánem implementace daných požadavků. Když je tedy návrh hotový, programátoři se ujmou jeho implementace. V pozdějších etapách této implementační fáze jsou vytvořené softwarové komponenty kombinovány, zavádí se nová funkcionalita a odstraňují chyby.

Vodopádový model tedy vyžaduje, aby se k následující fázi přikročilo pouze tehdy, pokud je ta předcházející kompletní a perfektně připravená. Na druhou stranu existují různé modifikované vodopádové modely (včetně Roycova konečného modelu), které se od uvedeného procesu mohou ve větší či menší míře lišit.

Vodopádový model je široce využíván takovými vývojářskými giganty, jako jsou firmy pracující pro Ministerstvo obrany Spojených států a NASA, a také pro různé vládní projekty (viz "standardní vodopádový model" na Internet Archive). Ti, kdo se těmito metodami řídí, často formálně nerozlišují mezi původním vodopádovým modelem a jeho různými modifikacemi, a tak může být složité specifikovat, přesně které modely se používají a v jaké míře.

Ministerstvo obrany Spojených států upustilo od vodopádového modelu v roce 1994 standardem MIL-STD-498 a v roce 1998 standardem IEEE 12207.

Pokud se věnuje dostatek času počátečním fázím tvorby softwaru, může to vést k vyšším úsporám v pozdějších etapách jeho životního cyklu. Mnohokrát se totiž ukázalo, že odstranění chyby, na kterou se přijde již v raných fázích životního cyklu tvorby softwaru (jako např. specifikace požadavků či návrh), je levnější (z hlediska peněz, úsilí i času), než když se na tu samou chybu přijde až v pozdějších fázích celého procesu. (Autor řady knih o softwarovém inženýrství Steve McConnell odhaduje, že „odstranění chyby v požadavcích, kterou se nepodaří odhalit až do fáze implementace nebo údržby, stojí 50krát až 200krát více, než kdyby se taková chyba odhalila a napravila již v etapě specifikace požadavků.“^[4] Pokud se v extrémním případě např. ukáže, že návrh programu je nemožné implementovat, je jednodušší jej upravit již v příslušné fázi návrhu, než zjistit o několik měsíců později, když se už jednotlivé komponenty integrují, že veškerá dosud odvedená práce přišla vniveč kvůli tomu, že návrh byl od začátku špatný.

Hlavní myšlenkou Big Design Up Front (BDUF) a vodopádového modelu je tedy to, že čas strávený na začátku zajišťováním toho, že požadavky i návrh jsou naprosto správné a kompletní, ušetří zase mnoho úsilí a času později. To znamená, že postupujeme-li podle vodopádového modelu, musíme si být v každé fázi jistí, že je stoprocentně kompletní a správná, než přejdeme k další etapě vývoje programu. Požadavky na program by měly být dány pevně a jasně, ještě než se začne s návrhem (v opačném případě kvůli chybným požadavkům přijde práce na návrhu nazmar); návrh programu by měl být zase doveden k dokonalosti předtím, než se začne s jeho implementací (v opačném případě se implementuje špatný návrh a práce je vniveč), atd.

Dalším argumentem ve prospěch vodopádového modelu je, že klade stejný důraz na dokumentaci (jako např. dokumentace požadavků nebo dokumentace návrhu) jako na zdrojový kód. V metodikách s jednodušším návrhem a dokumentací dochází v případě odchodu členů týmu ke ztrátě znalostí a ty pak může být obtížné získat zpět. Pokud je k dispozici plně funkční dokumentace (jak navrhuje Big Design Up Front a vodopádový model), noví členové týmu nebo dokonce celé nové týmy by měli být schopni se relativně snadno začlenit díky tomu, že si dokumentaci přečtou.

Ti, kteří preferují vodopádový model, na něm oceňují jednoduchost jeho přístupu. Připadá jim také disciplinovanější. Vodopádový model by měl poskytovat strukturovaný přístup; model postupuje lineárně, diskrétními, jednoduše pochopitelnými a vysvětlitelnými fázemi, a tak není složité mu porozumět. Poskytuje také snadno určitelné milníky ve vývojovém procesu. Možná to je tím důvodem, proč je vodopádový model uváděn mezi prvními ukázkovými příklady vývojového modelu v mnohých učebnicích a kurzech o softwarovém inženýrství. Má se za to, že vodopádový model a Big Design Up Front obecně je vhodný pro softwarové projekty, které jsou stabilní (zvlášť pro projekty, kde se příliš nemění požadavky) a kde je možné a pravděpodobné, že návrháři budou schopni dobře odhadnout problémové oblasti systému a vytvořit bezchybný návrh předtím, než začne implementace. Vodopádový model také vyžaduje, aby implementátoři postupovali podle pečlivě vytvořeného a kompletního návrhu přesně, čímž se zajistí hladký průběh integrace systému.

Vodopádový model je mnohými považován za nevhodný pro praxi. Kritici jsou především přesvědčeni, že u jakéhokoli netriviálního projektu je nemožné dovést jednu fázi životního cyklu softwarového produktu k dokonalosti předtím, než se přejde k fázi následující. Klientům nemusí být například úplně jasné, jaké jsou jejich požadavky, dokud neuvidí fungující prototyp, ke kterému se pak mohou vyjádřit; své požadavky mohou neustále měnit a návrháři a implementátoři pak nad tím ztrácejí kontrolu. Jestliže klient změní své požadavky poté, co je návrh hotov, musí být návrh modifikován a novým požadavkům přizpůsoben. Tím přijde vniveč relativně hodně práce, pokud se do Big Design Up Front investovalo příliš mnoho času. Návrháři také nemusí mít představu o budoucích implementačních problémech, pokud vytváří návrh pro ještě neimplementovaný softwarový produkt. Jinými slovy, teprve v implementační fázi se může ukázat, že určitou oblast funkcionality programu je velice těžké naimplementovat. Pokud se něco takového stane, je lepší zrevidovat návrh, než trvat na použití návrhu původního, který byl založen na chybných předpokladech a který se nedá použít pro nově objevené problémové oblasti.

Dr. Winston W. Royce popisuje v Managing the Development of Large Software Systems^[5] (prvním článku popisujícím vodopádový model) nejjednodušší verzi modelu jako „riskantní a odsouzenou k neúspěchu“.

Steve McConnell v knize Code Complete (česky: Dokonalý kód, kniha kritizující rozšířenost používání vodopádového modelu) označuje návrh softwaru za „záludný problém“ – problém, jehož požadavky a omezení nemohou být před dokončením plně známy. V důsledku toho je nemožné dovést jakoukoli fázi vývoje softwaru k dokonalosti, a tak je zároveň nemožné použít vodopádový model k přechodu do fáze následující.

David Parnas v článku A Rational Design Process: How and Why to Fake It píše:^[6]

„Mnoho detailů postupně vyjde najevo v průběhu implementace. Některé věci, které zjistíme, zneplatní náš návrh a my se musíme vrátit zpátky.“

Myšlenkou vodopádového modelu může být „dvakrát měř, jednou řež“. Odpůrci vodopádového modelu namítají, že tato myšlenka selhává, když problém, kterým se zabýváme, se neustále mění kvůli měnícím se požadavkům a následným novým zjištěním o problému samotném.

Jako reakce na zmíněné problémy originálního vodopádového modelu bylo představeno mnoho jeho modifikací. Tyto modifikované modely řeší částečně či úplně kritizované problémy modelu původního. Rozličné modely se dají nalézt v knize Steve McConnella Rapid Development: Taming Wild Software Schedules, v kapitole o plánování životního cyklu.

Každý model vývoje softwaru bude mít určité podobnosti s vodopádovým modelem, neboť každý takový model bude zahrnovat nějaké fáze, které se budou podobat těm z vodopádového modelu. Tato sekce se zabývá modely, které jsou vodopádovému modelu nejbližší. Informace o modelech, které se od vodopádového modelu liší výrazněji, nebo informace o diametrálně odlišných modelech budete moci nalézt v obecném textu o návrhu počítačového programu.

Sašimi model (nazýván podle japonské speciality z mořských plodů sašimi, protože jeho překrývající se fáze připomínají překrývající se kousky servírovaného masa) byl vytvořen Peterem DeGracem. Někdy se mu říká „vodopádový model s překrývajícími se fázemi“ nebo „vodopádový model se zpětnou vazbou“. Protože se fáze v sašimi modelu překrývají, je možné adresovat problémová místa během fází, které by u tradičního vodopádového modelu předcházely fázím jiným. Například fáze návrhu a implementace se v sašimi modelu překrývají, takže implementační problémy mohou být objeveny během fáze návrhu i implementace vývojového procesu. To pomáhá zmírnit mnoho problémů spojených s filozofií Big Design Up Front a vodopádového modelu.

• Návrh počítačového programu

V tomto článku byl použit překlad textu z článku Waterfall model na anglické Wikipedii.

• MCCONNELL, Steve. Software Estimation: Demystifying the Black Art. [s.l.]: Microsoft Press, 2006. Dostupné online. ISBN 0-7356-0535-1.  (anglicky)
• MCCONNELL, Steve. Dokonalý kód : umění programování a techniky tvorby software. Brno: Computer Press, 2005. ISBN 80-251-0849-X. 
• MCCONNELL, Steve. Rapid Development: Taming Wild Software Schedules. [s.l.]: Microsoft Press, 1996. Dostupné online. ISBN 1-55615-900-5.  (anglicky)
• SPOLSKY, Joel. The Project Aardvark Spec [online]. [cit. 2008-12-31]. Dostupné online.  (anglicky)
• SPOLSKY, Joel. Daily Builds Are Your Friend [online]. [cit. 2008-12-31]. Dostupné online.  (anglicky)
• TOIKKANEN, Tarmo. Don’t draw diagrams of wrong practices - or: Why people still believe in the Waterfall model [online]. [cit. 2008-12-31]. Dostupné online.  (anglicky)

• Obrázky, zvuky či videa k tématu Vodopádový model na Wikimedia Commons
• The pros and cons of the Waterfall Model of software development (anglicky)
• "Waterfall model considered harmful" (anglicky)
• "The demise of the waterfall model is imminent" and other urban myths (anglicky)
• Project lifecycle models: how they differ and when to use them (anglicky)
• Going Over the Waterfall with the RUP (anglicky)
• Software Processes (also the Waterfall Model) (anglicky)