Ohjelmistojen muutosten hallinnasta

Kukaan ei nauti siitä, että ohjelmistojen vaatimukset muuttuvat toteutuksen aikana. Kukaan ei nauti siitä, että työt joudutaan keskeyttämään tutkinnan ajaksi ja kertaalleen toteutettuun koodiin joudutaan palaamaan. Suurin osa ihmisistä ajattelee työtä palasina. Ensin teen tuon, sitten tuon jne. Kun vanhoja juttuja joudutaan kaivamaan auki, tuntuu ikävältä.

Perinteiset vesiputousmalliset kehitystyylit kärsivät juuri tästä. Vaikka työtä tehdään iteratiivisesti (suunnitellaan, toteutetaan, suunnitellaan, toteutetaan…), joudutaan silti palaamaan askelia taaksepäin, kun vaatimukset yhtäkkiä muuttuvat. Vaatimukset muuttuvat aina, se ei ole asiakkaan tai ohjelmistotalon vika. Ohjelmistoilla vaan on sellainen luontainen taipumus, että ne muuttuvat koko toteusprojektin ajan.

Uusissa ketterissä menetelmissä (Agile Software Development) lähestytään muutosta eri tavalla. Perinteisen lineaarisen etenemisen vaikeudet on havaittu ja niitä yritetään nyt parantaa. Perinteisesti koko toteutettava tuote suunnitellaan etukäteen. Valmiiden suunnitelmien mukaan lähdetään toteuttamaan.

Näin ei ole pakko olla. Ketteristä menetelmistä esimerkiksi Scrum tarjoaa erilaista lähestymistapaa. Yhtenä suurena erona on se, että asiakas on koko ajan mukana kehittämässä tuotetta. Tätä kautta asiakkaalla on koko ajan käsitys siitä, missä mennään. Toinen merkittävä ero on kehittäminen inkrementaaleissa.

Scrumin tapauksessa inkrementaalinen kehittäminen tarkoittaa kahta listaa. Listaa tuotteen ominaisuuksista ja listaa inkrementaalin ominaisuuksista. Kun tuotetta aletaan suunnittelemaan, asiakas alkaa listaamaan ominaisuuksia, joita ohjelma tarvitsee. Kun ominaisuuslista alkaa näyttämään melko valmiilta, aletaan suunnittelemaan toteutusta. Asiakas ja kehittäjät valitsevat ominaisuuksista sopivan määrän, jotka siirretään inkrementaalilistalle. Kun inkrementaalilista on lyöty lukkoon, niin sitä ei enää muuteta. Listalle laitetaan ominaisuuksia siten, että niiden toteuttamiseen menee noin 30 päivää.

Samaan aikaan kun ohjelmoijat alkavat suunnittelemaan ja toteuttamaan listaa voi asiakkaalle tulla uusia haluja. Uusia ominaisuuksia ja muutoksia lisätään tuotteen ominaisuuslistaan. Tämä lista elää koko toteutuksen ajan.

30 päivän päästä asiakkaalle esitellään tulos, mitä on saatu aikaan. Asiakas ehdottaa muutoksia ja lisäominaisuuksia, nämäkin kirjataan tuotteen ominaisuuslistaan.

Sitten keräännytään taas asiakkaan kanssa yhteen. Päätetään mitä asioita ominaisuuslistalta (johon on lisätty kaikenlaista) jäädytetään nyt inkrementaalilistaan. Ja taas mennään.

Inkrementaalit pyörivät niin kauan, kunnes tuotteen ominaisuuslista jäätyy. Se siis johtuu pääosin asiakkaasta. Sen jälkeen ohjelmisto viimeistellään (poistetaan esim debugit jne) ja luovutetaan.

Scrumin kaltaiset menetelmät vaativat myös asiakkaalta melko paljon. Mutta toisaalta ne tuovat myös asiakkaan suuntaan sellaista joustavuutta, ketteryyttä, jota peräänkuulutetaan.

Pohdiskelu peräytyy kandidaatintyöhöni, jossa tutkin nykyaikaisia ohjelmistotuotannon menetelmiä.


Posted

in

by

Tags:

Comments

2 vastausta artikkeliin “Ohjelmistojen muutosten hallinnasta”

  1. Iiris avatar
    Iiris

    Missäs vaiheessa on kandi? Ite sain tänään esitettyä oman semmatyön. Jeee!

  2. Jasmo avatar

    Onhan se vähän vaiheessa. Maanantaina olis loppuraportin esittäminen :D …

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

This site uses Akismet to reduce spam. Learn how your comment data is processed.