Model vodopádu - Waterfall model

Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Cvičení
Nástroje
Standardy a orgány znalostí
Glosáře
Obrysy
Nemodifikovaný „model vodopádu“. Pokrok proudí shora dolů, jako kaskádový vodopád.

Model vodopádu je zhroucení aktivit projektu na lineární postupných fází, kde každá fáze závisí na výstupech z předchozí a odpovídá zaměření úkolů. Tento přístup je typický pro určité oblasti inženýrského designu . Při vývoji softwaru patří k méně iterativním a flexibilním přístupům, protože pokrok plyne převážně jedním směrem („dolů“ jako vodopád ) fázemi koncepce, iniciace, analýzy , návrhu , konstrukce , testování , nasazení a údržby. .

Model rozvoje vodopádu vznikl ve zpracovatelském a stavebním průmyslu; kde vysoce strukturovaná fyzická prostředí znamenala, že změny designu se ve vývojovém procesu neúměrně prodražily. Když byly poprvé přijaty pro vývoj softwaru, neexistovaly žádné uznávané alternativy pro kreativní práci založenou na znalostech.

Dějiny

První známou prezentaci popisující použití takových fází v softwarovém inženýrství uspořádal Herbert D. Benington na sympoziu o pokročilých programovacích metodách pro digitální počítače dne 29. června 1956. Tato prezentace se týkala vývoje softwaru pro SAGE . V roce 1983 byl článek znovu publikován s předmluvou od Beningtona vysvětlující, že fáze byly účelově organizovány podle specializace úkolů, a poukázal na to, že tento proces ve skutečnosti nebyl prováděn striktně shora dolů, ale závisel na prototypu .

Ačkoli termín „vodopád“ není v příspěvku použit, první formální podrobný diagram procesu později známý jako „model vodopádu“ je často citován jako článek Winstona W. Royce z roku 1970 . Cítil však také, že má velké nedostatky vyplývající ze skutečnosti, že testování proběhlo až na konci procesu, který popsal jako „riskantní a zve k selhání“. Zbytek jeho příspěvku představil pět kroků, které považoval za nezbytné k „odstranění většiny rozvojových rizik“ spojených s nezměněným přístupem k vodopádu.

Royceových pět dalších kroků (které zahrnovaly sepsání kompletní dokumentace v různých fázích vývoje) se nikdy neujalo hlavního proudu, ale jeho diagram toho, co považoval za chybný proces, se stal výchozím bodem při popisu přístupu „vodopádu“.

Nejstarší použití termínu „vodopád“ může být v novinách Bell a Thayera z roku 1976.

V roce 1985 ministerstvo obrany Spojených států zachytilo tento přístup v DOD-STD-2167A , jejich standardech pro práci s dodavateli vývoje softwaru, které uváděly, že „dodavatel musí zavést cyklus vývoje softwaru, který zahrnuje následujících šest fází: Analýza požadavků na software „Předběžný návrh, podrobný návrh, kódování a testování jednotek, integrace a testování“.

Modelka

V původním modelu vodopádu Royce jsou následovány následující fáze v pořadí:

  1. Požadavky na systém a software : zachyceny v dokumentu s požadavky na produkt
  2. Analýza : výsledkem jsou modely , schéma a obchodní pravidla
  3. Design : výsledkem je softwarová architektura
  4. Kódování : vývoj , dokazování a integrace softwaru
  5. Testování : systematické objev a ladění z vad
  6. Operace : instalace , migrace , podpora a údržba kompletních systémů

Vodopádový model tedy tvrdí, že by se člověk měl přesunout do fáze pouze tehdy, když je zkontrolována a ověřena její předchozí fáze.

Různé modifikované modely vodopádů (včetně Royceova finálního modelu) však mohou zahrnovat mírné nebo velké variace tohoto procesu. Tyto variace zahrnovaly návrat do předchozího cyklu poté, co byly nalezeny nedostatky po proudu, nebo návrat až do fáze návrhu, pokud se fáze po proudu považovaly za nedostatečné.

Podpůrné argumenty

Čas strávený na začátku výrobního cyklu softwaru může snížit náklady v pozdějších fázích. Například problém nalezený v raných fázích (například specifikace požadavků) je levnější opravit než stejná chyba nalezená později v procesu (faktorem 50 až 200).

V běžné praxi vedou metodologie vodopádu k časovému plánu projektu, přičemž 20–40% času investovaného do prvních dvou fází, 30–40% času věnovaného kódování a zbytek věnovaný testování a implementaci. Vlastní organizace projektu musí být vysoce strukturovaná. Většina středních a velkých projektů bude obsahovat podrobný soubor postupů a kontrol, které regulují každý proces na projektu.

Dalším argumentem pro model vodopádu je, že klade důraz na dokumentaci (například dokumenty požadavků a dokumenty návrhu) a zdrojový kód . V méně důkladně navržených a zdokumentovaných metodikách dochází ke ztrátě znalostí, pokud členové týmu odejdou před dokončením projektu, a pro projekt může být obtížné vzpamatovat se ze ztráty. Pokud je k dispozici plně funkční dokument o návrhu (jak je záměrem Big Design Up Front a modelu vodopádu), noví členové týmu nebo dokonce zcela nové týmy by se měli seznámit se čtením dokumentů.

Model vodopádu poskytuje strukturovaný přístup; samotný model postupuje lineárně skrz diskrétní, snadno srozumitelné a vysvětlitelné fáze, a proto je snadno pochopitelný; poskytuje také snadno identifikovatelné milníky v procesu vývoje. Z tohoto důvodu je model vodopádu v mnoha textech a kurzech softwarového inženýrství používán jako počáteční příklad vývojového modelu.

Kritika

Klienti nemusí přesně vědět, jaké jsou jejich požadavky, než uvidí fungující software, a tak své požadavky změní, což povede k přepracování, přestavbě a opětovnému testování a ke zvýšení nákladů.

Designéři si nemusí být vědomi budoucích potíží při navrhování nového softwarového produktu nebo funkce. V takovém případě je lepší návrh revidovat, než setrvávat v návrhu, který neberou v úvahu žádná nově objevená omezení, požadavky nebo problémy.

Organizace se mohou pokusit vypořádat s nedostatkem konkrétních požadavků od klientů zaměstnáváním systémových analytiků, aby prozkoumali stávající manuální systémy a analyzovali, co dělají a jak by mohli být nahrazeni. V praxi je však obtížné udržet striktní oddělení mezi systémovou analýzou a programováním. Důvodem je, že implementace jakéhokoli netriviálního systému téměř nevyhnutelně odhalí problémy a okrajové případy, o kterých systémový analytik neuvažoval.

V reakci na vnímané problémy s modelem čistého vodopádu byly zavedeny upravené modely vodopádů, jako například „Sashimi (vodopád s překrývajícími se fázemi), vodopád s dílčími projekty a vodopád s omezením rizika“.

Některé organizace, jako například ministerstvo obrany Spojených států, nyní uvádějí, že upřednostňují metodologie typu vodopádu, počínaje MIL-STD-498 , která podporuje evoluční získávání a iterativní a přírůstkový vývoj .

Zatímco zastánci agilního vývoje softwaru tvrdí, že model vodopádu je neúčinný proces pro vývoj softwaru, někteří skeptici naznačují, že model vodopádu je falešným argumentem, který se používá čistě k uvádění na trh alternativních metod vývoje.

Fáze Rational Unified Process (RUP) uznávají programovou potřebu milníků, udržení projektu na cestě, ale podporují iterace (zejména v rámci oborů) ve fázích. Fáze RUP jsou často označovány jako „podobné vodopádům“.

Upravené modely vodopádů

V reakci na vnímané problémy s modelem „čistého“ vodopádu bylo zavedeno mnoho upravených modelů vodopádů . Tyto modely mohou řešit některé nebo všechny kritiky modelu „čistého“ vodopádu.

Patří sem modely Rapid Development, které Steve McConnell nazývá „upravené vodopády“: „sashimi model“ Petera DeGrace (vodopád s překrývajícími se fázemi), vodopád s podprojekty a vodopád se snižováním rizika. Existují také další kombinace modelů vývoje softwaru, jako je „přírůstkový model vodopádu“.

Royceův finální model

Konečný model Royce

Winston W. Royceův konečný model, jeho zamýšlené vylepšení oproti jeho počátečnímu „modelu vodopádu“, ilustroval, že zpětná vazba by mohla (měla by a často by mohla) vést od testování kódu k návrhu (jako testování kódu odhalilo nedostatky v návrhu) a od návrh zpět na specifikaci požadavků (protože problémy s designem mohou vyžadovat odstranění konfliktních nebo jinak neuspokojivých / nedefinovatelných požadavků). Ve stejném dokumentu Royce také obhajoval velké množství dokumentace a dělal práci „pokud možno dvakrát“ (sentiment podobný tomu, jaký měl Fred Brooks , známý tím, že napsal Mýtický mužský měsíc, vlivnou knihu v oblasti řízení softwarových projektů , který prosazoval plánování „zahodit“) a co nejvíce zapojit zákazníka (podobný pocit jako při extrémním programování ).

Poznámky Royce k finálnímu modelu jsou:

  1. Před zahájením analýzy a kódování dokončete návrh programu
  2. Dokumentace musí být aktuální a úplná
  3. Pokud je to možné, proveďte práci dvakrát
  4. Testování musí být plánováno, kontrolováno a monitorováno
  5. Zapojte zákazníka

Viz také

Reference

externí odkazy