Mudeli ajalugu / kes / millal / arendasvälja

Waterfall-mudel on lineaarne, järjestikune lähenemine tarkvaraarenduse elutsüklile (SDLC), mis on populaarne tarkvaraarenduses ja tootearenduses.

Waterfall-mudelis kasutatakse projekti SDLC etappide loogilist kulgemist, mis sarnaneb vee voolamise suunaga üle kalju serva. See seab igale arendusprotsessi etapile kindlad lõpp-punktid või eesmärgid. Neid lõpp-punkte või eesmärke ei saa pärast nende lõpuleviimist uuesti läbi vaadata.

Dr. Winston W. Royce Lockheedi tarkvaratehnoloogiakeskusest tutvustas seda kontseptsiooni 1970. aastal avaldatud dokumendis, mis käsitleb tema kogemusi satelliitide tarkvara arendamisel. Royce ei kasutanud siiski terminit Waterfall; selle asemel viitas ta dokumentatsiooni järk-järgulisele väärtusele.

Waterfall-mudelit kasutatakse jätkuvalt tööstusdisaini rakendustes. Seda nimetatakse sageli esimeseks tarkvaraarenduse metoodikaks. Mudelit kasutatakse ka üldisemalt kui kõrgetasemelist projektijuhtimise metoodikat keeruliste, mitmetahuliste projektide puhul.

Etapid

Analüüs. See on kõige pikem etapp, kus töövõtja arutab toote üle tellijaga, hangib nõuded, kiidab heaks plaanid, eesmärgid, eelarve, töövõtted ja riskid. Seejärel töötatakse välja esialgsed ülesanded ja juhised, millest järgmistes etappides ei saa kõrvale kalduda.

Projekteerimine. Selles etapis luuakse tarkvara prototüüp, valitakse programmeerimisplatvorm ja kinnitatakse meeskonnaliikmete rollid.

Arendus. Siin kirjutatakse toote kood rangelt kooskõlas tehnilise spetsifikatsiooniga.

Testimine. Selles etapis kontrollitakse, kui hästi kood vastab tehnilisele spetsifikatsioonile.

Kasutamine. Toode antakse kliendile kasutamiseks üle ja seejärel analüüsitakse tulemust. Tagasiside kogumine ja kriitiliste vigade parandamine võib nõuda eelmiste etappide juurde tagasipöördumist ja nende uuesti tegemist.

Toetus. Viimases etapis peab töövõtja hoidma toodet töökorras, parandama vead ja koguma kasutajatelt tagasisidet, et funktsionaalsust veelgi täiustada või asendada.

Skeem

Waterfall’i plussid ja miinused

plussid	miinused
Selge struktuur ja etappide järjestus	Suutmatus reageerida paindlikult nõuete muutustele arendusprotsessi käigus
Lihtne planeerida ja juhtida projekti tänu rangele vahe-eesmärkide järjestusele	Ei sobi projektidele, mille nõuded on ebatäielikult määratletud või muutuvad
Dokumenteeritud igas etapis (sh plaanid, nõuded, testimine)	Kõrge risk, kui hilisemates etappides avastatakse vigu või muudatusi nõuetes
Sobib hästi väikeste, selgete nõuetega projektide jaoks	Sammude vahelise tagasiside puudumine võib viia vigade kuhjumiseni
Hõlpsasti jälgida eelarvet ja ajakava igas etapis	Kui hilisemates etappides esineb vigu, tuleb pöörduda tagasi eelmiste etappide juurde, mis suurendab kulusid
Sobib kindlate nõuete ja tähtaegadega projektide jaoks	Võib olla pikk ja kulukas protsess keerukate või pikaajaliste projektide puhul

Testküsimus