A vesiputousmalli , kuusivaiheinen malli on vesiputousmalli. Toisin sanoen vaiheet tapahtuvat peräkkäin. Aivan kuten uiminen vesiputousta vastaan on mahdotonta, puhdas vesiputoustekniikka estää paluuta vaiheeseen sen päätyttyä.
Ei ole ihanteellista päättää suunnittelun muuttamisesta toteutusvaiheen aikana, jolloin toteutus pysähtyy. Vesiputoustapa ei usein sovellu ohjelmistokehitysprojekteihin useista syistä.
- Ohjelmistokehitys on taiteellinen yritys; käytännössä on vaikea ennakoida kaikkia tarpeita (toimintoja).
- Ominaisuuden kehittämiseen tarvittavan ajan arvioiminen on erittäin haastavaa.
- Käyttäjien pitäisi pystyä testaamaan kaikki välitulokset koko hankkeen elinkaaren ajan.
Ohjelmistokehitys on taiteellinen yritys #
Aloittamattomille ohjelmistokehitys näyttää olevan enemmän suunnittelua kuin keksintöä. Se liittyy kuitenkin monin tavoin keksimiseen. Luomisprosessissa ei koskaan tiedä tarkalleen, mitä tapahtuu.
Suunnittelijoiden ja ohjelmoijien, jotka ovat vastuussa uusien ohjelmistojen kehittämisestä, on löydettävä vastaukset esittämiinsä kysymyksiin. Riippumatta monista tekniikoista ja työmääräyksistä, tietokonekoodin luominen on edelleen enimmäkseen tuntematonta ja siksi arvaamatonta. Ohjelmoijat voivat valita miljoonista ratkaisuista, jotka on kirjoitettu kymmenillä ohjelmointikielillä ja jotka toimivat tuhansilla eri laitteistoyhdistelmillä ja ohjelmistoalustoilla. Vaikka tästä joustavuudesta on paljon hyötyä, se tekee projektista myös haastavampaa kuin tavanomaista projektinhallinta (kuten rakennus- tai rakennushankkeet).
Toteutusasetukset #
Vesiputous lähestymistapa edellyttää, että vaatimukset määritellään seurauksena hankkeen määrittelyvaihe . Ihannetapauksessa näiden kriteerien pitäisi poiketa mahdollisimman vähän koko projektin loppuajan. Ohjelmistokehityksen vesiputoustapa edellyttää aluksi sitoutumista huomattaviin ponnistuksiin vaadittujen toimintojen (vaatimusten) analysoinnissa. Tämä johtaa toiminnalliseen suunnitteluun (lisätietoja toiminnallisista malleista on kohdassa I). Ohjelmistoarkkitehti luo teknisen suunnittelun koko suunnitteluprosessin ajan käyttäen toiminnallista suunnittelua viitteenä. Lisäksi tekninen suunnittelu sisältää ohjeet vaaditun toiminnon suorittamisesta.
Vaikka tämä saattaa tuntua yksinkertaiselta ongelmalta, harkitse seuraavaa skenaariota. Osana hanketta kehitetään uutta ajoneuvoa. Aktiivisena autonkuljettajana sinun tehtäväsi on kehittää autoteollisuuden tarpeita. Neuvottelet muiden autoilijoiden kanssa ja koot kattavan luettelon:
- Autossa on oltava neljä henkilöä;
- Autossa on oltava ohjauspyörä edessä kuljettajan vasemmalla puolella; • Autossa on oltava jarrupoljin, kaasupoljin ja käsijarru.
- Auton ajovalojen on oltava valkoisia ja takavalojen on oltava punaisia. (tietysti todellinen lista olisi valtava)
Suunnittelu ja mallinnus #
Suunnittelijat luovat uuden mallin käyttämällä luetteloasi oppaana, joka rakennetaan monta kuukautta myöhemmin. Kun menet kadulle, näet ajoneuvon pysähtyneen. Ymmärrät, että jätit jarruvalot pois luettelostasi! Otat nopeasti yhteyttä autonvalmistajan insinööriin, joka melkein räjähtää vastauksena puheluusi. Väität, että kyseessä on pieni muutos. Se on kuitenkin katastrofi autonvalmistajille. Jo valmistetut autot on purettava kokonaan, johdot jarrupolkimista taakse on pidennettävä, ajoneuvon takaosa on suunniteltava kokonaan uudelleen jarruvalojen mukaiseksi, ja jo valmistetut tavaratilan luukut on romutettava, ja luetteloa jatketaan.
Vaikka yllä oleva skenaario näyttää naurettavalta, se edustaa lähes päivittäistä tapahtumaa ohjelmistokehityksessä. Ohjelmoijat tekevät virheellisen oletuksen, että luodun tuotteen asiakkaat, asiakkaat tai käyttäjät ymmärtävät tarkalleen, mitä he haluavat. Asiakkaat uskovat virheellisesti, että ohjelmistokehittäjät voivat luoda (ja muokata) mitä tahansa mahdollisimman lyhyessä ajassa. Tämä on pääasiallinen syy kiistelyyn kuluttajien ja ohjelmistokehittäjien välillä.
