Vesiputousmalli

Wikipedia
Loikkaa: valikkoon, hakuun

Vesiputousmalli

Vesiputousmalli on vaiheellinen ohjelmistotuotantoprosessi, jossa suunnittelu- ja toteutusprosessi etenee vaihe vaiheelta alaspäin kuin vesiputouksessa.

Vesiputousmallin katsotaan usein saaneen alkunsa Winston W. Roycen (1929-1995) kirjoittamasta 1970-luvulla julkaistusta artikkelista, vaikkakaan 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, rautapuolen suunnittelumalli omaksuttiin pienin muutoksin ohjelmistotuotantoon.

Malli[muokkaa | muokkaa wikitekstiä]

Roycen alkuperäisessä vesiputousmallissa käytettiin seuraavia vaiheita (tässä järjestyksessä):

  1. Järjestelmävaatimukset (System Requirements)
  2. Ohjelmistovaatimukset (Software Requirements)
  3. Analyysi (Analysis)
  4. Suunnittelu (Program Design)
  5. Ohjelmointi (Coding)
  6. Testaus (Testing)
  7. 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[muokkaa | muokkaa wikitekstiä]

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)[1], 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 vaatimuksen 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[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

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[muokkaa | muokkaa wikitekstiä]

  • McConnell, Steve: Rapid Development: Taming Wild Software Schedules Microsoft Press, 1996, ISBN 1-55615-900-5

Viitteet[muokkaa | muokkaa wikitekstiä]

  1. McConnell 1996, s. 72