Vesiputousmalli

Vesiputousmallin edut

Huolellinen suunnittelu ohjelmiston elinkaaren alussa todennäköisesti johtaa merkittäviin säästöihin projektin myöhemmissä vaiheissa. Tutkimukset osoittavat, että virhe (bugi), joka löydetään varhaisessa vaiheessa (kuten vaatimusten määrittelyssä tai suunnittelussa) on rahallisesti, työmäärällisesti ja ajallisesti halvempi korjata kuin jos sama virhe olisi havaittu myöhemmässä vaiheessa. McConnell (1996, s. 72), arvioi, että vaatimusmäärittelyvirhe, joka havaitaan vasta implementaatio- tai ylläpitovaiheessa, on 50–200 kertaa kalliimpi korjata kuin mitä se olisi ollut, jos se olisi huomattu jo vaatimusmäärittelyvaiheessa.)
Vesiputousmallissa on nimenomaan kyse varhaisen suunnittelun korostetusta merkityksestä (Big Design Up Front, BDUF). Aika, joka käytetään varhaisessa vaiheessa vaatimusten määrittelyyn ja suunnitteluun, säästää aikaa ja vaivaa myöhemmissä vaiheissa. Vesiputousmalli toimii täydellisesti vain silloin, kun jokainen vaihe on suunniteltu 100% oikein ja täydellisen kattavasti ennen seuraavaan vaiheeseen siirtymistä.
Muita vesiputousmallin hyötyjä ovat esimerkiksi sen painotus kattavaan dokumentointiin. Koska jokainen vaihe on täydellisesti suunniteltu ja "kiveen kirjoitettu", on vaikkapa uuden työntekijän helppo liittyä projektiin missä tahansa vaiheessa, sillä hänellä on täydellinen tieto aiemmasta prosessista saatavillaan.
Lisäksi vesiputousmalli tarjoaa selkeän ja helposti ymmärrettävän, hallittavan ja opetettavan lähtökohdan ohjelmistokehitysprojektiin. Jokainen vaihe on selkeä itsenäinen kokonaisuus ja projektin etenemistä on vaivatonta seurata seuraamalla millä "askelmalla" projekti milloinkin on.
Vesiputousmalli ja BDUF yleensäkin voi olla perusteltu suunnittelumalli sellaisille ohjelmille, joiden vaatimukset voidaan määritellä tarkasti jo alussa ja joiden vaatimuksiin, suunnitteluun ja toiminnallisuuteen ei tule mitään muutoksia enää ensimmäisen vaiheen jälkeen. Tämä pätee useimmiten vain pienissä ja rajoittuneissa ohjelmistoissa. Tarkka suunnittelu pakottaa toteuttajat (ohjelmoijat) työskentelemään tarkasti suunnitelman mukaan, joka helpottaa merkittävästi integraatiovaihetta.

Vesiputousmallin kritiikki

Vesiputousmallia pidetään huonona lähinnä siksi, että uskotaan olevan mahdotonta suunnitella täydellisesti etukäteen mitään suurempaa ohjelmistoa siten, ettei aiempiin vaiheisiin tarvitsisi palata. Usein ohjelmistotuotannossa asiakas ei osaa tarkasti määritellä omia vaatimuksiaan ennen kuin on päässyt kokeilemaan jollain tasolla toimivaa prototyyppiä. Asiakas usein muuttaa vaatimuksiaan kesken projektin, ja vesiputousmallissa tämä tarkoittaisi sitä, että iso osa siitä ajasta ja vaivasta, joka on käytetty alussa suunnitteluun, joudutaan hylkäämään ja tekemään uudelleen.
Suunnittelijat eivät aina osaa ennakoida kaikkia toteutusongelmia ennen toteuttamisen aloittamista, ja uuden ratkaisumallin käyttäminen vaatisi uutta suunnittelua. Lisäksi projektin edetessä mahdolliset virheet aiemmissa vaiheissa saattavat kertautua valtaviksi ongelmiksi myöhemmissä vaiheissa.
Steve McConnell kuvaa kirjassaan Code Complete suunnittelun olevan sellainen ongelma, jonka vaatimuksia ei voida tarkalleen tietää etukäteen, ja että tästä syystä on mahdotonta saada yhtä vaihetta täydellisen valmiiksi ennen seuraavaan siirtymistä.

Muokatut vesiputousmallit

Steve McConnell käsittelee kirjansa Rapid Development: Taming Wild Software Schedules kappaleessa lifecycle planning useita eri muokattuja vesiputousmalleja, jotka saattavat korjata osan alkuperäisen mallin saamasta kritiikistä. Kaikki ohjelmistosuunnittelumallit yhtenevät joiltain osin vesiputousmalliin, mutta useimmat suosituista uusista suunnittelumalleista pyrkivät tarjoamaan enemmän joustavuutta suunnitteluprosessiin, jolloin jokaista vaihetta ei tarvitsisi pystyä toteuttamaan täydellisesti ennen seuraavaan siirtymistä ja joissa muutokset johonkin aiempaan vaiheeseen eivät aiheuttaisi yhtä merkittäviä ongelmia kuin vesiputousmallissa.