Vesiputousmalli
 |
Tähän artikkeliin tai osioon ei ole merkitty lähteitä, joten tiedot kannattaa tarkistaa muista tietolähteistä. Voit auttaa Wikipediaa lisäämällä artikkeliin tarkistettavissa olevia lähteitä ja merkitsemällä ne ohjeen mukaan. |
Vesiputousmalli on vaiheellinen ohjelmistotuotantoprosessi, jossa suunnittelu- ja toteutusprosessi etenee vaihe vaiheelta alaspäin kuin vesiputouksessa. Menetelmä muistuttaa usein muussa suunnittelutyössä käytettyä mallia.[1]
Historia
[muokkaa | muokkaa wikitekstiä]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.[2][3]
Vesiputousmallin katsotaan usein saaneen alkunsa Winston W. Roycen (1929–1995) kirjoittamasta 1970-luvulla julkaistusta artikkelista.[4][1] 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
[muokkaa | muokkaa wikitekstiä]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
[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)[5], 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
[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ä]- ↑ a b Petersen, Kai & Wohlin, Claes: The waterfall model in large-scale development urn.kb.se. 2009. ISBN 978-3-642-02151-0 Viitattu 30.10.2024. (englanniksi)
- ↑ H. D. Benington: ”Production of large computer programs”, Symposium on advanced programming methods for digital computers, s. 15-27. Office of Naval Research, 28.-29. kesäkuuta 1956. Teoksen verkkoversio. (englanniksi)
- ↑ Herbert D. Benington: Production of Large Computer Programs (PDF) mosaicprojects.com.au. lokakuu 1983. Viitattu 30.10.2024. (englanniksi)
- ↑ Winston W. Royce: Managing the development of large software systems (PDF) Arkistoitu Viitattu 30.10.2024. (englanniksi)
- ↑ McConnell 1996, s. 72
Aiheesta muualla
[muokkaa | muokkaa wikitekstiä]
Kuvia tai muita tiedostoja aiheesta Vesiputousmalli Wikimedia Commonsissa
