Mikä on vesiputousmenetelmä ohjelmistokehityksessä?
Vesiputousmenetelmä on yksi ohjelmistokehitysmenetelmistä, jota monet kehittäjät käyttävät projektinhallinnassa. Se noudattaa lineaarista lähestymistapaa projektin alusta loppuun, mikä tarkoittaa, että jokainen kehitysprosessin vaihe on saatava päätökseen ennen seuraavaan siirtymistä. Monet organisaatiot ovat saavuttaneet toivottuja tuloksia käyttämällä tätä jäsenneltyä ja perusteellista lähestymistapaa, jota on käytetty jo useita vuosia.
Vesiputousmenetelmä alkaa keräämällä asiakkaiden ja sidosryhmien pyyntöjä ohjelmistoprojektin alussa, jotta voidaan laatia peräkkäinen projektisuunnitelma. Kaikki projektin osa-alueet, kuten käyttäjätarinat, käyttöliittymät, ominaisuudet jne., dokumentoidaan etukäteen, jolloin voit laatia tarkat aika-arviot ja laatia ennakoitavissa olevan julkaisupäivän. Tässä artikkelissa saat lisätietoja vesiputousmenetelmästä, sen vaiheista, hyödyistä ja haitoista.
Vesiputousmenetelmän viisi vakiovaihetta
Kuten aiemmin mainittiin, menetelmä toimii kronologisesti ja perustuu kiinteisiin vaatimuksiin, päivämääriin ja tuloksiin. Siksi se ei vaadi tiimeiltä yhteistyötä, ellei erityisiä integraatioita tarvita jatkuvasti. He työskentelevät yleensä itsenäisesti, toisin kuin ketterissä menetelmissä, joissa tiimin jäsenten on annettava usein tilanneraportteja ja tehtävä yhteistyötä.
Tässä jaksossa käsitellään vesiputousmenetelmän viisi päävaihetta tai -vaihetta sellaisena kuin sen luoja Winston W. Royce alun perin ehdotti. Lisäksi jokainen ohjelmistokehityksen vaihe alkaa vasta, kun edellinen on saatu päätökseen. Kun ohjelmistokehitysprojektia harkitaan, prosessiin kuuluvat yleensä seuraavat vaiheet:
- Vaatimukset
- Design
- Toteutus
- Tarkastus tai testaus
- Käyttöönotto tai ylläpito
1. Vaatimukset
Ensimmäisessä vaiheessa on kyse asiakkaan ja sidosryhmien projektivaatimusten keräämisestä ja täydellisestä ymmärtämisestä. Projektipäällikkö tekee tämän tehtävän, jolloin tiimi voi suunnitella seuraavat vaiheet sen mukaisesti. Tyypillisesti kaikki vaatimukset kirjataan kirjallisesti yhdeksi asiakirjaksi tarkkuuden varmistamiseksi.
Siinä hahmotellaan kustannukset, oletukset, riskit, riippuvuudet, onnistumisen mittarit ja valmistumispäivämäärät hankkeen jokaisessa vaiheessa. Teoriassa yhteydenpito asiakkaisiin jatkuu vasta sitten, kun tuote on valmistunut ensimmäisen vaiheen jälkeen.
2. Suunnittelu
Suunnitteluvaiheessa ohjelmistokehittäjät ratkaisevat tuotteen vaatimusten asettamia teknisiä ongelmia. Ratkaisu voi olla ulkoasuja, skenaarioita, tietomalleja jne. Ensimmäiseksi he laativat suunnitelman, jossa hahmotellaan projektin tavoite ja parametrit sekä kunkin komponentin liikenteen ja integraatiopisteiden yleiset reitit. Sitä kutsutaan loogisen suunnittelun osavaiheeksi.
Tämän jälkeen suunnitteluluonnos muutetaan fyysiseksi suunnitteluksi käyttämällä erityisiä laitteisto- ja ohjelmistotekniikoita fyysisen suunnittelun osavaiheessa. Tässä vaiheessa kaikki loogisen suunnittelun alavaiheessa käsitellyt ideat muunnetaan varsinaisiksi eritelmiksi ryhmän valitsemien laitteisto- ja ohjelmistotekniikoiden avulla.
3. Täytäntöönpano
Nyt tulee toteutusvaihe, vaihe, jossa kaikki pannaan täytäntöön. Se on yleensä lyhin vesiputousvaihe, koska kaikki tutkimus ja suunnittelu on saatava valmiiksi tässä vaiheessa. Tässä vaiheessa ohjelmoijat käyttävät suunnitteluvaiheen määrittelyjä ja vaatimuksia koodin kehittämiseen. Tiimi voi kuitenkin joutua palaamaan suunnitteluvaiheeseen, jos toteutusvaiheessa tarvitaan merkittäviä muutoksia.
4. Tarkastus tai testaus
Tuotteen tarkistaminen tai testaaminen ennen sen julkaisemista asiakkaille on merkittävä vesiputousvaihe, jota ei voi välttää, vaikka mitä tapahtuisi. On välttämätöntä taata, että tuote on virheetön ja että kaikki vaatimukset on täytetty, jotta ohjelmiston käyttäjäkokemus olisi myönteinen. Tässä vaiheessa kehitystiimi luovuttaa projektin QA-testaustiimille.
- Ennen projektin käyttöönottoa he etsivät kaikki korjattavat viat ja virheet ja kirjaavat perusteellisesti kaikki laadunvarmistuksen aikana havaitsemansa ongelmat.
- Jos toinen kehittäjä kohtaa samanlaisen vian, hän voi käyttää aiempaa dokumentaatiota apuna ongelman ratkaisemisessa.
- Virhetestauksen jälkeen valmis tuote asetetaan asiakkaan käyttöön varmennusvaiheessa.
- Asiakas tarkastaa valmiin tuotteen varmistaakseen, että se täyttää projektin alussa määritellyt vaatimukset.
5. Käyttöönotto ja ylläpito
Tarkastuksen ja testauksen jälkeen tuote toimitetaan asiakkaalle oikeaan määräaikaan mennessä. On kuitenkin tapauksia, joissa havaitaan uusi vika tai tarvitaan ohjelmistopäivitys, kun tuote on otettu käyttöön. Ylläpitovaiheessa tiimi voi siis tehdä tarvittavat korjaukset ja julkaista päivitetyt ohjelmistoversiot varmistaakseen asiakkaan täydellisen tyytyväisyyden. Ohjelmistokehityksessä on tavallista, että tätä vaihetta työstetään jatkuvasti.
Miten se hyödyttää sinua?
Edellisistä kappaleista luetun perusteella vesiputousmenetelmä on selkeä ja suoraviivainen lähestymistapa projektinhallintaan, jonka lukuisat organisaatiot ovat vuosien varrella omaksuneet. Koska olet alusta alkaen tietoinen projektin vaatimuksista, tiimi tietää, mitä ja milloin se on tehtävä, ja pystyy suunnittelemaan projektin hyvin, jotta se saadaan valmiiksi annettuun määräaikaan mennessä. Seuraavassa on muutamia menetelmän etuja:
- Tunnistamalla suunnitteluvirheet varhaisessa vaiheessa vaatimus- ja suunnitteluprosessia kehittäjät voivat estää huonon koodin kirjoittamisen myöhemmin toteutusvaiheessa.
- Kun vaatimukset on määritetty, on mahdollista arvioida hankkeen kokonaiskustannukset ja aikataulu tarkasti.
- Edistymisen mittaaminen hyvin määriteltyjen välitavoitteiden mukaisesti on helpompaa, kun lähestymistapa on organisoitu.
- Kun uudet kehittäjät liittyvät käynnissä olevaan projektiin, heillä ei ole vaikeuksia päästä vauhtiin, koska vaatimusasiakirjan pitäisi sisältää kaikki heidän tarvitsemansa tiedot.
- Asiakkaat, jotka tuovat hankkeeseen uusia vaatimuksia, eivät viivästytä tuotantoa.
Mitkä ovat haitat?
Edut yhdellä alalla voivat johtaa haittoihin toisella, aivan kuten missä tahansa kehitysprosessissa. Koska vesiputousmenetelmässä korostetaan projektin etukäteissuunnittelua ja sitoutumista tiettyyn, määriteltyyn edistymiseen, sitä on vähemmän helppo mukauttaa prosessin myöhemmässä vaiheessa. Muutosten tekeminen prosessin myöhemmässä vaiheessa voi olla tuskallista, aikaa vievää ja kallista. On muitakin syitä, joiden vuoksi menetelmä ei välttämättä ole tehokas.
- Verrattuna iteratiiviseen lähestymistapaan, kuten ketterään menetelmään, projektin loppuunsaattaminen voi kestää kauemmin, kun käytetään tätä kronologista menetelmää.
- Koska asiakkaat eivät pysty ilmaisemaan tarpeitaan selkeästi etukäteen, he saattavat pyytää muutoksia ja uusia ominaisuuksia myöhemmin prosessin aikana, jolloin niiden täyttäminen on haastavampaa.
- Suunnittelu- ja toteutusvaiheet eivät ole avoimia asiakkaan osallistumiselle.
- Määräajan karkaamisena tunnettu prosessi tapahtuu, kun yhtä vaihetta lykätään, ja samalla lykätään kaikkia muita vaiheita.
- Lähestymistavan suurin haittapuoli on se, että kun vaihe on päättynyt, siihen voi olla haastavaa palata.
Olet siis oppinut paljon vesiputousmenetelmästä tässä artikkelissa. Tämä lähestymistapa ei välttämättä sovellu kaikkiin ohjelmistokehitysprojekteihin. Menetelmää suosivat tyypillisesti projektipäälliköt, jotka hallinnoivat hankkeita, joilla on tarkat vaatimukset, jotka antavat selkeän kuvan siitä, miten asiat etenevät alusta alkaen, ja joiden laajuus tuskin muuttuu projektin alettua. Joissakin hankkeissa lähestymistapa saattaa tuntua kohtuuttoman rajoittavalta, mutta se voi olla erinomainen väline, jolla estetään selkeästi määritellyn ja ennakoitavan hankkeen budjetin ja aikataulun ylittyminen. Tee siis tietoon perustuva päätös artikkelin tietojen perusteella.
Mielenkiintoisia linkkejä:
Katso lisätietoja vesiputousmallista ohjelmistokehityksessä.
Mitkä ovat vesiputousmenetelmän edut ja haitat?
Kuvat: Canva
Kirjoittaja: Sascha Thattil työskentelee Software-Developer-India.com -sivustolla, joka on osa YUHIRO-ryhmää. YUHIRO on intialainen saksalainen yritys, joka tarjoaa ohjelmoijia IT-yrityksille, virastoille ja IT-osastoille.