Vesiputousmalli

**Vesiputousmalli** on vaiheellinen ohjelmistotuotantoprosessi, jossa suunnittelu- ja toteutusprosessi etenee vaihe vaiheelta alaspäin kuin vesiputouksessa. Menetelmä muistuttaa usein muussa suunnittelutyössä käytettyä mallia.

## Historia
Vaiheittaista ohjelmistokehityksen menetelmää on käsitelty jo vuonna 1956 SAGE-järjestelmän kehitykseen liittyen. Aiemmin saatiin menestystä kun insinöörit kehittivät pieniä ohjelmia, jotka yksi ihminen pystyi ymmärtämään täysin. Tämä johti virhepäätelmiin, kun ohjelmat olivat suurempia kuin yksi ihminen pystyi täysin ymmärtämään ja tarvittiin suuria määriä ohjelmoijia.

Vesiputousmallin katsotaan usein saaneen alkunsa Winston W. Roycen (1929&ndash;1995) kirjoittamasta 1970-luvulla julkaistusta artikkelista. Royce ei itse käyttänyt termiä "Vesiputous" tekstissään. Royce esitti kyseisen mallin esimerkkinä virheellisestä ja toimimattomasta ohjelmistokehitysmallista. Alkujaan termiä käytettiinkin kritisoitaessa yleisesti käytettyjä ohjelmistotuotantokäytäntöjä.

Vesiputousmallin juuret ovat valmistusprosesseissa; hyvin strukturoituja ja vaiheistettuja prosesseja, joissa muutokset aiempiin vaiheisiin olivat joko hyvin kalliita tai jopa mahdottomia. Koska formaaleja ohjelmistotuotantomalleja ei tuohon aikaan vielä ollut, laitteiston suunnittelumalli omaksuttiin pienin muutoksin myös ohjelmistotuotantoon.

## Malli
Roycen alkuperäisessä vesiputousmallissa käytettiin seuraavia vaiheita (tässä järjestyksessä):
# Järjestelmävaatimukset (System Requirements)
# Ohjelmistovaatimukset (Software Requirements)
# Analyysi (Analysis)
# Suunnittelu (Program Design)
# Ohjelmointi (Coding)
# Testaus (Testing)
# Käyttöönotto (Operations)

Vesiputousmallia seurattaessa edetään järjestyksessä yhdestä vaiheesta toiseen. Eli kun vaatimusten määrittely on valmistunut, siirrytään suunnitteluvaiheeseen, eikä vaatimuksia enää muokata. Suunnitteluvaiheessa valmistetaan selkeä kartoitus, jota toteuttajat (ohjelmoijat) sitten noudattavat. Vesiputousmalli vaatii, että yksi vaihe toteutetaan valmiiksi asti ennen seuraavan vaiheen aloittamista, vaikkakin muokattuja malleja (kuten Roycen lopullinen malli), joissa tätä ohjetta voidaan rikkoa, on olemassa.

## 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.
## Lähteet
* McConnell, Steve: Rapid Development: Taming Wild Software Schedules Microsoft Press, 1996, 
### Viitteet

## Aiheesta muualla