Mikä on järjestelmäkehityksen kehitysmallien oikeudelliset edut ja haitat?

Järjestelmäkehitysprojektien edistämiseen on olemassa tiettyjä menetelmiä. Yleensä, kun opiskellaan järjestelmäkehitykseen liittyviä oikeudellisia kysymyksiä kirjoista ja muista lähteistä, usein oletuksena on vanhin ja klassisin menetelmä, jota kutsutaan vesiputousmalliksi. Kuitenkin, järjestelmäkehityksen edistämiseen käytettävät menetelmät tai mallit eivät rajoitu pelkästään vesiputousmalliin. Esimerkiksi viime aikoina on yhä useammin valittu menetelmäksi ketterä kehitysmalli (agile development model).

Tässä artikkelissa tarkastelemme vesiputousmallia ja ketterää kehitysmallia vertaillen niitä oikeudellisten riskien ja riitojen ehkäisyn näkökulmasta.

Mikä on kehitysmalli?

Mikä on vesiputousmalli?

Järjestelmän kehityksen etenemistapa, joka on yleisin ja klassisin, on seuraavanlainen:

• Vaatimusten määrittely: Tulevan järjestelmän tarvitsemat toiminnot ja vaatimukset
• Perussuunnittelu: Käyttöliittymän suunnittelu ja siirtymät, pääasiassa käyttäjän näkökulmasta katsottuna
• Yksityiskohtainen suunnittelu: Ohjelmistotiedostojen väliset yhteydet jne., pääasiassa kehittäjän näkökulmasta katsottuna
• Ohjelmoinnin toteutus: Ohjelmointi suunnitelman mukaisesti
• Testaus: Tarkistetaan, onko ohjelma tehty vaatimusten mukaisesti, ja pyydetään käyttäjältä vahvistus

Tätä kehitystapaa, jossa pyritään etenemään ylävirrasta alavirtaan mahdollisimman vähän paluuta tai virheitä, kutsutaan “vesiputousmalliksi”. Tämä prosessi ei ole välttämätön toimivan järjestelmän luomiseksi. Kuitenkin, järjestelmän kehityksessä, joka usein vaatii suuren määrän työvoimaa ja pitkän aikavälin sitoutumista, suunnittelu on tärkeää. Siksi myös tehtävien jakaminen, roolien järjestäminen ja vastuualueiden selkeyttäminen ovat tärkeitä.

Mikä on ketterä kehitysmalli?

Toisaalta, kehitystyön etenemistapa ei aina ole “ylävirta-alavirta” -tyyppinen. On totta, että suunnittelun ja ennustamisen taidot ovat tärkeitä työn luonteen vuoksi. Kuitenkin, koska kyse on uuden tuotteen tai teoksen luomisesta, täydellinen suunnittelu on usein mahdotonta alusta alkaen. Jos otetaan huomioon nämä seikat, ei riitä, että työtä jatketaan suunnitelman mukaisesti, vaan on tärkeää myös olla joustava korjauksissa ja vaatimusten muutoksissa, sekä lisätä kokeilun ja virheen toistokertoja. Tämä ajattelutapa heijastuu “ketterään kehitysmalliin”. Ketterässä kehitysmallissa ei yleensä käytetä paljon aikaa yksityiskohtaisten suunnitelmien tai suunnitteludokumenttien laatimiseen, vaan ohjelmoidaan ja testataan pieniä ohjelmia toistuvasti, ja vähitellen muokataan niitä suuremmiksi ohjelmiksi tai järjestelmiksi.

Waterfall-malli helpottaa oikeudellisten kysymysten opiskelua

Ennen kuin vertaamme molempia kehitysmalleja, haluan mainita, että kummankin kehitysmallin mukana tulevien oikeudellisten kysymysten tiedonkeruun ja oikeustieteen opiskelun helppous.

Useimmat viitekirjat on kirjoitettu Waterfall-mallin perusteella

Järjestelmäkehitykseen liittyvien oikeudellisten kysymysten tai oikeustieteen opiskelun yhteydessä, tiedonkeruun helppoudessa Waterfall-malli voittaa. Useimmissa tapauksissa järjestelmäkehityksestä keskustelevat oikeudelliset kirjat on kirjoitettu oikeudellisesti olettaen Waterfall-mallin. Koska klassinen ja yleinen järjestelmäkehitys toteutetaan Waterfall-mallin mukaisesti, Agile-kehitys on siinä lisäosa ja usein vain lyhyesti esitelty. Siksi, jos haluat saada tietoa järjestelmäkehitykseen liittyvistä oikeudellisista kysymyksistä kirjoista, Waterfall-malli helpottaa opiskelua.

Waterfall-mallilla on paljon oikeustapauksia

Lisäksi, koska Waterfall-malli on klassinen ja yleinen järjestelmäkehitysmenetelmä, myös menneisyydessä todellisesti tapahtuneiden kiistatapausten määrä on runsas. Oikeudellisessa keskustelussa, lainsäädännön lisäksi, myös aikaisempien oikeustapausten tuntemus on tärkeää. Joissakin tapauksissa, vaikka lakitekstin sanamuotoa tulkittaisiin vain “valkoiseksi” tai “mustaksi”, voidaan saada tietoa aikaisemmista oikeustapauksista ja täydentää lakitekstin sisältöä.

Vaikka laki ei olisi kirjoitettu, oikeuden antamat päätökset voivat vakiintua arviointiperusteina, aivan kuten lakipykälät. Tätä kutsutaan “oikeuskäytännöksi”. Jopa järjestelmäkehityksen kaltaisissa keskusteluissa, jos alueella on jo oikeuskäytännön kertymä, jopa tuntemattoman kiistan lopullisen kohtalon ennustaminen voi olla suhteellisen helppoa. Tässä suhteessa Waterfall-malliin perustuvalla järjestelmäkehityksellä on monia etuja.

Kunkin kehitysmenetelmän edut

Ottaen huomioon edellä mainitut seikat, vertailemme ja järjestämme seuraavaksi kunkin menetelmän etuja ja haittoja. Ensimmäinen osa keskittyy vesiputousmallin etuihin, ja mitä alemmas mennään, sitä selkeämmin tulevat esille ketterän kehityksen edut.

Vertailu suunnitelmallisuuden ja ennakoitavuuden näkökulmasta

Suunnitelmallisuuden ja ennakoitavuuden osalta voidaan sanoa, että vesiputousmalli on ylivoimainen. Riippumatta siitä, kuinka laaja järjestelmä on kyseessä, se jaetaan aina yksityiskohtaisesti eri vaiheisiin, jotka etenevät “ylhäältä alas”. Asettamalla määräajat jokaiselle vaiheelle, sen etenemistä on suhteellisen helppo hallita suunnitelmallisesti.

Toisaalta ketterä kehitys on menetelmä, joka ei vaadi paljon kustannuksia tai vaivaa etukäteissuunnitteluun tai kokonaiskonseptiin, joten se voi helposti muuttua ad hoc -lähestymistavaksi.

Vertailu yksittäisten roolien ja vastuualueiden selkeyttämisen helppoudessa

Waterfall-mallissa prosessit jaetaan yksityiskohtaisesti, mikä tarjoaa etuna yksittäisten projektijäsenten roolien selkeyttämisen.

Toisaalta Agile-kehityksessä prosessien erottelu voi olla epäselvä, mikä voi johtaa epäselvyyksiin siitä, kuka ottaa vastuun odottamattomista ongelmista ja vastaavista asioista.

Vertailu suurten kehitysprojektien toteuttamisen helppoudessa

Hyvin suunniteltu ja roolitettu vesiputousmalli on erityisen hyödyllinen suurissa kehitysprojekteissa. Vaikka projektissa olisi mukana suuri määrä henkilöstöä, työvaiheiden hienojakoisuus ja työnjako edistävät tehokkuutta ja vähentävät ihmisten välisen koordinoinnin kustannuksia.

Toisaalta ketterän kehitysmallin ei katsota soveltuvan erityisen hyvin suuriin projekteihin. Koska tässä lähestymistavassa painotetaan enemmän nopeaa aloittamista kuin suunnittelua ja roolien määrittelyä, se ei ole paras valinta tilanteissa, joissa lopullisen toimituspäivän siirtyminen saattaa olla huolenaihe.

Vertailu nopeuden ja tehokkuuden näkökulmasta

Agile-kehitys aloitetaan nopeammin

Kun käyttäjäpuolella on jokin toiminnon tarve, ja kun se todella toteutetaan, Agile-kehitysmalli on nopeampi. Tämä johtuu siitä, että vesiputousmallissa ylä- ja alavirtaprosessien vastuut ovat yleensä selkeästi erillään, mikä lisää sisäisen viestinnän vaivaa. Tämä viestinnän vaiva on yhteydessä siihen, että jälkikäteen tehdyt muutokset ovat usein hankalia.

Toisaalta, Agile-kehitysmallissa voidaan odottaa, että työhön ryhdytään ja sitä toteutetaan nopeasti ilman välikäsiä. Tämä liittyy läheisesti Agile-kehitysmallin suurimpaan etuun, eli siihen, että jälkikäteen tehdyt muutokset ovat helpompia. Kuitenkin, vaikka kyseessä olisi Agile-kehitysmalli, jos jatkuvasti suostutaan tekemään muutoksia ja lisäkehitystä, se voi johtaa projektin “palamiseen”. Tässä mielessä, Agile-kehitysmallin mukainen järjestelmän kehitys on avain menestykseen siinä, miten “muutosten hallinta” toteutetaan. Muutosten hallinnasta on yksityiskohtainen selostus seuraavassa artikkelissa.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Vesiputousmalli on vähemmän todennäköinen keskeytymään kesken

Toisaalta, kun vertaillaan nopeuden ja tehokkuuden näkökulmasta, on tärkeää tarkastella asiaa pitkällä aikavälillä. Jos otetaan huomioon riski, että projekti “palaa” kesken ja edistyminen loppuu, vesiputousmalli on parempi. Suurin riski, joka johtaa projektin keskeytymiseen, on käyttäjän ja toimittajan välinen viestinnän puute. Vesiputousmalli, joka helpottaa molempien osapuolten roolien selkeyttämistä, on tässä suhteessa etu.

Agile-kehitys on sujuvampaa hyväksymisvaiheessa

Kuitenkin, jos tarkastellaan, kuinka helppoa on edetä hyväksymisvaiheessa, Agile-kehitysmalli on hieman parempi. Tämä johtuu siitä, että käyttäjän ja toimittajan välillä on oletettu jakavan tietoa yksityiskohtaisesti järjestelmän kehityksen aikana. Tämä vähentää riskiä, että molempien osapuolten näkemyserot tulevat esiin vasta, kun lopullinen tuote on valmis. Lisätietoja järjestelmän kehityksen hyväksymisvaiheesta ja siihen liittyvistä oikeudellisista kysymyksistä löytyy seuraavasta artikkelista.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Yhteenveto

Kun näitä kahta verrataan, voidaan yleisesti todeta, että hallinnon perusteellisuus on vahvuus vesiputousmallissa, kun taas nopeus aloittamisessa ja toteuttamisessa on Agile-kehitysmallin etu. Lisäksi Agile-kehitysmallin mukaiseen järjestelmän kehittämiseen liittyvistä oikeudellisista kysymyksistä käsitellään yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/legal-and-contract-issues-of-agile-development[ja]

Kumpi kehitysmalli on sopivampi, riippuu paitsi oikeudellisista näkökohdista, myös projektin koosta, budjetista ja tavoitteista. Nämä kaikki tulisi ottaa huomioon kokonaisvaltaisessa arvioinnissa.