Ohjelmistoala, ohjelmistoprosessi ja ohjelmistoprosessimalli

Tässä tutkielmassa ohjelmistoalan määritelmänä käytetään Tilastokeskuksen 62 ohjelmistot, konsultointi ja siihen liittyvä toiminta - luokitusta. Luokkaan kuulu-vat ohjelmien ja ohjelmistojen kirjoittaminen, muuntaminen, testaaminen ja tuki;

sellaisten tietokonejärjestelmien suunnittelu, joissa yhdistyy laitteisto-, ohjel-misto- ja viestintäteknologia; asiakkaan tiloissa tapahtuva tietokonesysteemien ja tietojenkäsittelylaitteiden hallinta ja käyttö; ja muut laitteistoihin ja ohjelmistoi-hin liittyvät asiantuntijapalvelut ja tekniset palvelut. Tutkielmassa keskitytään toimialaluokituksen alaluokan 6201 mukaiseen toimintaan, johon kuuluvat oh-jelmien ja ohjelmistojen kirjoittaminen, muuntaminen, testaaminen ja tuki. Tähän sisältyy ohjelmiston rakenteen ja sisällön suunnittelu ja/tai ohjelmakoodin kir-joittaminen varusohjelmistoja, sovelluksia, tietokantoja, web-sivustoja ja tietoko-nepelejä varten sekä olemassa olevan sovelluksen muuntaminen ja konfigurointi tilaustyönä niin, että se toimii tarkoituksenmukaisesti asiakkaan järjestelmäym-päristössä. (Tilastokeskus, 2018)

Systemaattista lähestymistä ohjelmistokehitykseen kutsutaan ohjelmistopro-sessiksi (software process) (Sommerville, 2016) tai ohjelmistokehitysproohjelmistopro-sessiksi (software development process) (Mohapatra, 2000). Tässä tutkielmassa käytetään edellistä ilmaisua. Sommervillen (2016) mukaan ohjelmistoprosessi on sarja akti-viteetteja, jotka johtavat ohjelmistotuotteen tuottamiseen. Neljä ohjelmistopro-sesseille yhteistä perusaktiviteettia ovat:

1. Ohjelmiston määrittely, jossa asiakkaat ja kehittäjät määrittelevät tuotet-tavan ohjelmiston sekä sen toiminnallisuuden rajoitteet.

2. Ohjelmiston kehittäminen, jossa ohjelmisto suunnitellaan ja ohjelmoidaan.

3. Ohjelmiston validointi, jossa ohjelmisto tarkastetaan ja varmistetaan, että se on sitä, mitä asiakas vaatii.

4. Ohjelmiston jatkokehitys, jossa ohjelmistoa muokataan vastaamaan asiak-kaan ja markkinan muuttuvia vaatimuksia. (Sommerville, 2016)

Ohjelmistoprosessimalli (software process model) on yksinkertaistettu esitys oh-jelmistoprosessista. Jokainen prosessimalli edustaa prosessia tietystä näkökul-masta, ja siten tarjoaa ainoastaan osittaista tietoa prosessista (Sommerville, 2016).

Sommervillen (2016) mukaan täytyy muistaa, että mikään prosessimalli ei sovi

kaikkeen ohjelmistokehitykseen, vaan oikea prosessi riippuu asiakkaasta ja vaa-timuksista, ohjelmiston käyttöympäristöstä ja kehitettävän ohjelmiston tyypistä.

(Sommerville, 2016). Seuraavaksi esitellään muutamia yleisiä ohjelmistoproses-simalleja esimerkinomaisesti.

Vesiputousmalli

Vesiputousmalli oli ensimmäinen julkaistu ohjelmistomalli, ja se esiteltiin ensim-mäistä kertaa Roycen vuonna 1970 julkaistusta artikkelista (Royce, 1970). Vesi-putousmalli kuvaa ohjelmistoprosessia sarjana vaiheita (Mohapatra, 2000; Som-merville, 2016) (kuvio 4). Vesiputousmallin ajatukseen kuuluu, että vaiheesta toi-seen voi edetä vasta, kun edellisen vaiheen tulokset on arvioitu ja verifioitu, ja vaihe on päätetty (Royce, 1970; Mohapatra, 2000; Sommerville, 2016). Peräkkäis-ten vaiheiden kesken iterointi on mahdollista, mutta iterointi useamman kuin kahden vaiheen kesken on harvinaista (Royce, 1970).

KUVIO 4 Vesiputousmalli (Royce, 1970)

Alkuperäinen malli muodostuu seitsemästä vaiheesta (Royce, 1970), mutta sitä on myös sovellettuja versioita (esimerkiksi Sommerville, 2016; Mohapatra, 2000) (taulukko 3). Mallin eri variaatioiden välinen ero vaiheiden määrän suhteen joh-tuu pääasiassa yksityiskohtien määrästä ja kategorisointitavasta (Mohapatra, 2000). Roycen mallin vaiheita ovat järjestelmän vaatimusten määritteleminen, ohjelmiston vaatimusten määritteleminen, analyysi, suunnittelu, ohjelmointi, testaus ja käyttöönotto (Royce, 1970). Sommervillen ja Mohapatran malleissa vai-heiden määrä on tiivistetty seitsemästä viiteen.

TAULUKKO 3 Vesiputousmallin vaihejakoja

Royce (1970) Sommerville (2016) Mohapatra (2000)

Järjestelmän vaatimusten

määritteleminen Vaatimusmäärittely Vaatimusten analysointi ja määrittely

Ohjelmiston vaatimusten määritteleminen

Analyysi Järjestelmän ja ohjelmiston

suunnittelu Suunnittelu ja määrittely Suunnittelu

Ohjelmointi Toteutus ja yksikkötestaus Ohjelmointi ja yksikkötes-taus

Testaus Integraatio- ja

järjestelmä-testaus

Integraatio- ja järjestelmä-testaus

Käyttöönotto Käyttöönotto ja ylläpito Toimitus ja ylläpito

Vesiputousmallia kohtaan on myös kohdistunut kritiikkiä, joka kohdistuu ennen kaikkea perinpohjaiseen suunnitteluun ja laajaan dokumentointiin (Royce, 1970;

Boehm, 1986; Mohapatra, 2000). Boehmin (1986) mukaan pääsyy ongelmiin vesiputousmallin käytössä liittyy mallin yksityiskohtaisiin dokumentteihin, jotka ovat alun vaatimusmäärittely- ja suunnitteluvaiheiden valmistumiskriitireinä. Myös vesiputousmallin jäykkyyttä ja vaiheen jäädyttä-mistä ennen seuraavaan siirtyjäädyttä-mistä on kritisoitu (Mohapatra, 2000).

Spiraalimalli

Spiraalimalli on Barry Boehmin ehdottama inkrementaalinen ja riskilähtöinen prosessimalli (Sommerville, 2016), joka yhdistää piirteitä vesiputousmallista, inkrementaalisesta kehittämisestä ja evolutiivisesta prototyypityksestä (Moha-patra, 2000). Prosessi kuvataan enemmin spiraalina kuin aktiviteettien sarjana.

Spiraalin jokainen kierros edustaa vaihetta ohjelmistoprosessissa. Siten sisin kier-ros sisältää vaatimusmäärittelyn, seuraava kierron järjestelmän suunnittelun ja niin edelleen. (Mohapatra, 2000; Sommerville, 2016). Boehmin (1986) mukaan jo-kaiseen spiraalimallin sykliin sisältyy neljä vaihetta: 1) tavoitteiden ja rajoitteiden määrittely, 2) vaihtoehtojen arviointi sekä riskien tunnistaminen ja ratkaiseminen, 3) kehittäminen ja seuraavan tason tuotteen määrittely, jossa tehtävinä eri iteraa-tioilla on muun muassa vaatimusten määrittely ja validointi, suunnittelu ja suun-nitelman validointi, ja ohjelmointi ja testaus, ja 4) seuraavien vaiheiden suunnit-telu (Boehm, 1986). Mallissa ei ole ennalta määrättyjä vaiheita, vaan projektin johto päättää vaiheistuksesta. Täten spiraalimallin kierrosten määrä voi vaihdella eri organisaatioiden välillä ja jopa saman organisaation eri projektien välillä.

(Mohapatra, 2000)

Rational Unified Process (RUP)

Rational Unified Process (RUP) on iteratiivinen ja inkrementaalinen ohjelmisto-kehityksessä käytetty prosessimalli. RUP tarjoaa kurinalaisen lähestymistavan tehtävien ja vastuiden jakamiseen kehitysorganisaatiossa. Sen tavoitteena on

taata korkealaatuisen ohjelmiston tuottaminen niin, että ohjelmisto täyttää lop-pukäyttäjien vaatimukset aikataulussa ja budjetissa pysyen. (Kruchten, 2000)

RUP:n prosessirakenteessa on kaksi ulottuvuutta: horisontaalinen akseli kuvaa aikaa ja havainnollistaa prosessin elinkaarta. Pystyakseli puolestaan ku-vaa ydinprosessin työnkulkua (Kruchten, 2000). Elinkaaren vaiheita ovat aloitta-minen, tarkentualoitta-minen, rakentaminen ja siirtyminen (Kruchten, 2000; Mohapatra, 2000). Vaiheiden lisäksi RUP:ssa on määritetty myös vaiheisiin sijoittuvat tehtä-vät, jotka mukailevat pitkälti vesiputousmallin vaihejakoa. RUP:ssa esitettyjä tehtäviä ovat liiketoimintamallin määrittely, vaatimusmäärittely, analyysi ja suunnittelu, toteutus, testaus, käyttöönotto, kokoonpano- ja muutosten hallinta, projektinhallinta ja ympäristön hallinta. (Kruchten, 2000)

Ketterät menetelmät

Vastatakseen jatkuvasti muuttuviin käyttäjävaatimuksiin, projektien pitäisi olla ketteriä (Mohapatra, 2000). Ketterät menetelmät ovat kokoelma ohjelmistokehi-tysmenetelmiä, jotka toteuttavat ketterän ohjelmistokehityksen julistuksessa (Agile Manifesto) esitettyjä arvoja ja periaatteita. Julistuksessa painotetaan neljää arvoa (Beck ym., 2001):

Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja au-tamme muita siinä. Kokemuksemme perusteella arvosau-tamme:

 yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja.

 toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota.

 asiakasyhteistyötä enemmän kuin sopimusneuvotteluja.

 vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa.

Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.

Ketterän ohjelmistokehityksen julistuksessa esitetyt kaksitoista periaatetta sisäl-tävät ajatuksia alusta asti toimivasta ohjelmistosta, ohjelmiston versioiden ly-hyistä kehitys- ja toimitussykleistä, vaatimusten muutosalttiudesta, asiakkaan ja kehittäjien tiiviistä yhteistyöstä läpi projektin, kehittäjien taitoihin luottamisesta, kasvokkain käytävän keskustelun tehokkuudesta viestintätapana, toimivasta jelmistosta edistymisen mittarina, kestävien toimintatapojen käyttämisestä, oh-jelmiston laadun ja hyvän rakenteen huomioimisesta, yksinkertaisuudesta, itse-organisoituvista tiimeistä sekä tiimin itsearvioinnista työskentelyn tehosta-miseksi (Beck ym., 2001). Ketterässä ohjelmistokehityksessä on siis kyse arvoista ja periaatteista, joita voidaan toteuttaa usein eri tavoin. Ketteriä ohjelmistokehi-tysmenetelmiä ovat esimerkiksi Scrum ja Extreme Programming eli XP (Moha-patra, 2000).