Ohjelmistokehitys

Ohjelmistolla saadaan tietokone tekemään jotain haluttua ja jotta saadaan haluttu ohjelmisto, se pitää kehittää. Ohjelmistokehitys (myös sovelluskehitys tai ohjelmistotuotanto) on tietokoneohjelmistojen valmistusta asiakasorganisaatiolle. Kuka niitä tekee, kuinka, miksi ja milloin? Ja miksi pyörä pitää keksiä aina uudelleen, eikö maailmassa ole jo tarpeeksi ohjelmistoja?

Ohjelmistoja tarvitaan koko ajan ja joka paikassa. Tietokoneohjelmiston avulla liikennevalot vaihtuvat vihreäksi ja kännykän taustakuvan voi vaihtaa. Ohjelmistoja on kelloissa, kassakoneissa, koulussa, mikroaaltouunissa ja TV:n kaukosäätimessä. Modernissa autossa niitä vasta onkin.

Ohjelmistokehityksen kenttää voi jaotella monella eri tavalla, listaamalla eri teknologioita tai toimialoja, työvaiheita tai toimintatapoja. Mielestäni liiketoiminnan digitalisaation näkökulmasta tärkeää on näkökulma, milloin ohjelmiston saa valmiina hyllystä ja milloin sellainen kannattaa teettää.

Valmisohjelmistot ja räätälöidyt ohjelmistot

Perusperiaate on se, että usein toistuville tarpeille on olemassa joku valmis ratkaisu, joka todennäköisesti käy myös sinulle. Sähköpostiohjelmisto on hyvä esimerkki. Voit valita useita eri vaihtoehdoista eikä suomalaisen järjestön tai yrityksen yleensä tarvitse teettää omaa sähköpostiohjelmistoa. Potilastietojärjestelmiäkin tarvitaan eri puolella maailmaa, mutta silti sellainen kannattaa – tai on pakko – teettää uudestaan, miksi? Syynä ei ole harvinainen kielialue vaan se, että järjestelmän tarve ja toimintaympäristö on uniikki. Vain Suomessa on suomalainen terveydenhuoltojärjestelmä, joten myös tietokoneohjelmisto on räätälöitävä toimintaympäristöön sopivaksi. Jos sinulla on pitkät jalat, mutta vain yksi lyhyt käsivarsi, niin mittatilauspuku on ainoa vaihtoehto, vaikka kaupasta pukuja saakin.

Sama pätee liiketoimintaan. Jos olet kirpputorikauppias, niin kassajärjestelmän saat varmasti valmiina joltain alan toimijalta. Jos taas laajennat toimintaasi verkkoon ja löydät liiketoimintahyötyä vaikkapa yhdistämällä fiksusti eri sosiaalisen median kanavia ja läheisen huoltoaseman liikkeentunnistinta, joudut tilaamaan tähän sopivan sovelluksen ohjelmisto- eli sovelluskehittäjältä. Valmista ohjelmistoa ei yksinkertaisesti ole olemassa, koska tarpeesi on ainutkertainen.

Digitalisaatiossa oli pitkään kysymys siitä, että kone hoitaa jonkun asian paremmin tai halvemmin kuin ihminen; tekstinkäsittely ja virheiden korjaus Wordillä säästi aikaa ja rahaa kirjoituskoneeseen verrattuna. Internetin maailmassa digitalisaatio tarkottaa puolestaan yhä useammin asioita, joita ei edes voi olla olemassa netin ulkopuolella.

Valmiita ohjelmistoja voi hankkia kahdella tavalla: palveluna tai asennettuna omaan toimintaympäristöön. Gmail ostetaan palveluna Googlen pilvestä, mutta toiminnanohjausjärjestelmään tehdään aina jotain muutoksia ja räätälöintejä, jolloin puhutaan käyttöönotosta. Käyttöönotto kestää päivästä vuosiin, aivan tilanteesta riippuen. Jos valmista ei löydy, jonkun pitää se tehdä. Usein ollaan jossain välimaastossa, jolloin esitutkimusvaiheessa selvitetään, kannattaako räätälöidä ja muokata valmista vai teettää uutta.

Legopalikat ja palikkatehtaat

Koska ohjelmistokehitys on melko näkymätöntä tekemistä, siitä puhuessa ja kirjoittaessa on pakko turvautua vertauskuviin. Vertaukset talonrakennukseen ovat yleisiä, koska siitä on helppo ymmärtää, että samaan lopputulokseen voi päästä miljoonilla eri tavoilla. Suosittu vertaus on myös legoista rakentaminen. Legot ovat komponentteja, joita eri tavoin järjestelemällä voi rakentaa lähes mitä vain. Suurin osa ohjelmistokehityksestä on Legolandiassa legopalikoilla rakentamista. Legolandialla tarkoitetaan tässä ohjelmistokielien kerroksisuutta; uutta tehdään aina vanhan päälle. Lähellä varsinaista fyysistä prosessoria olevia kieliä kutsutaan matalan tason ohjelmointikieliksi ja lähempänä loppukäyttäjää olevia kieliä puolestaan korkean tason ohjelmointikieliksi.

C-ohjelmointikielen päälle on rakennettu esim. php-ohjelmointikieli, jolla ohjelmistosuunnittelija tekee sopivia komponentteja. Nämä komponentit yhdessä muiden ohjelmistojen kanssa pystyvät pyörittämään ja näyttämään meille webbisivuja ja -sovelluksia kuten vaikkapa verkkokauppoja. Liikennevalojen ja autonavaimien ohjelmisto on todennäköisesti jotain matalamman tason ohjelmistokieltä, mutta siinäkin hyödynnetään aikaisemmin tehtyä työtä ja koodia.

Webbikehityksessä legopalikkavertaus kantaa hyvin pitkälle, samoilla palikoilla voidaan reagoida muuttuvaan toimintaympäristöön kuten uusiin selaimiin ja päätelaitteisiin. Välillä joudutaan purkamaan legolandian lattiaa ja perustuksia ja välillä taas rakentamaan nopeasti korkeuksiin. Joskus perustukset sortuvat tai jopa häviävät olemasta, jolloin täytyy korjata nopeasti.

Joidenkin toimijoiden kannattaa kuitenkin rakentaa oma legotehdas ja tehdä palikoita omalla muovisekotuksellaan. Tällaisia ovat vaikkapa Facebook tai Applen oma käyttöjärjestelmä, jotka ovat eriytyneet omiksi legolandioikseen. Perusperiaatteet pysyvät kuitenkin samana: alla on käyttöjärjestelmiä, joiden päälle rakennetaan lisäkerroksia, kunnes tietokone tai -koneet saadaan tekemään haluttu asia. Vaikka teknologiat muuttuvat jatkuvasti, osaava ja ammattiylpeä ohjelmistokehittäjä pystyy pienen perehtymisen jälkeen ottamaan uudet rakennuspalikat käyttöönsä.

Ohjelmistokehityksen vaiheet

Ohjelmistokehityksen vaiheet ovat periaatteessa samat kuin talonrakennuksessa, ensin suunnitellaan, sitten tehdään ja testataan ja lopuksi otetaan käyttöön. Perinteiset ohjelmistokehityksen vaiheet ovat esitutkimus, määrittely, käyttöliittymäsuunnittelu, toteutus, testaus, julkaisu tai käyttöönotto ja ylläpito. Jokainen vaihe voidaan jakaa pienempiin paloihin kuten esim. testaus jakautuu testausmenetelmien suunnitteluun, järjestelmätestaukseen, yksikkötestaukseen, integraatiotestaukseen, rasitustestaukseen ja testauksen dokumentointiin.

Noin 2000-luvulle saakka ohjelmistokehityksessä vallitsevaa toimintatapaa kutsutaan vesiputousmalliksi. Tässä perinteisessä prosessissa vaiheet soljuvat eteenpäin kuin vesiputous tasolta toiselle, ja siksi tätä prosessia kutsutaankin vesiputousmalliksi. Vesi ei koskaan putoa ylöspäin eli kerran tehtyyn määrittelyyn ei palata matkan varrella. Ajatuksena on, että kukin vaiheista tuottaa dokumentin tai joukon dokumentteja, jotka toimivat syötteenä seuraavalle vaiheelle. Vesiputousmallin ongelmia on se, että maailma ja liiketoiminta muuttuu niin nopeasti, että huolellisinkin määrittely alkaa vanheta heti valmistuttuaan.

Autoteollisuudesta liikkeelle lähtenyt lean-malli, jossa pyritään äärimmäiseen tehokkuuteen ja kaiken turhan välttämiseen, on jalkautunut ohjelmistokehitykseen ns. ketterän kehityksen menetelminä. Perusero vesiputoukseen on pienempien iteraatioiden ja prototyyppien käyttö, joiden avulla voidaan helpommin mukautua omiin ja toimintaympäristön muutoksiin. Ketterä, iteratiivinen ohjelmistokehitys on tuottanut hyviä tuloksia, ei tosin sekään pysty täysin poistamaan ohjelmistokehityksen riskejä. Haittapuoli tilaajan näkökulmasta on se, että kokonaishintalappu ei ole tarkasti tiedossa lähtiessä. Lopullisen ohjelmiston hinta riippuu siitä, mitä tilaaja ja toimittaja yhdessä projektin aikana päättävät tehdä ja mitkä asiat priorisoidaan tärkeimmäksi.

Ohjelmistokehityksen ostaminen ja sen riskit

Ohjelmisto- eli sovelluskehittäjät työskentelevät joko ohjelmistoa tarvitsevassa organisaatiossa, ohjelmistoalan yrityksessä tai itsenäisinä yrittäjinä. Isoissa organisaatioissa saattaa olla järkevää pitää omia kuukausipalkkaisia kehittäjiä kun taas pienen ja keskikokoisen yrityksen kannattaa ostaa ulkoa. Kuitenkin harvassa sairaalassa on omia ohjelmistokehittäjiä, vaikka organisaatio olisi isokin. Omassa kehittäjässä on yritykselle suuri henkilöriski, jos se ainoa osaaja jostain syystä lähtee, niin usein kukaan ei tiedä mistään mitään. Koska koodin kirjoittaminen on helpompaa kuin koodin lukeminen, on toisen tekijän usein hyvin työlästä päästä sisään vieraaseen järjestelmään. Tästä syystä dokumentaatio ja koodin kommentoiminen on tärkeää, mutta usein joudutaan priorisoimaan itse tekemistä dokumentoinnin sijaan, joten täydellinen dokumentaatio on harvinaisuus.

Toinen riski on toimittajariski tai niin sanottu toimittajaloukku, jota voi kyllä välttää. Toimittajaloukulla tarkoitetaan tilannetta, jossa valittu teknologia on niin harvinainen että sitä saa vain yhdeltä toimittajalta, jolloin ollaan pakkoavioliitossa. Avoin lähdekoodi auttaa yleensä tämän riskin välttämisessä. Avoin lähdekoodi tarkoittaa sitä, että käytetyt komponentit ja palikat ovat julkisia, ilmaisia ja avoimia, mutta ei se, mitä niillä tehdään. Isojen teknologiatalojen kuten Microsoftin tai SAP:in ohjelmistotuotteet ja koodi eivät kuulu avoimeen lähdekoodiin, mutta toimittajia ja vaihtoehtoja on silti useita.

Kirjoittaja: Anu Halme, asiakkuusjohtaja, W3 Group Finland Oy – IT rakennusmestariyritys, www.w3.fi

Palvelutarjoajat

1.Ohjelmistokehitys tarjoajayritykset