Hyvä yleisö,

Täytyy aloittaa toteamalla, että on kunnia astua professuuriin perinteikkäälle laitokselle, josta avoimen lähdekoodin maailmanvalloitus käynnistyi Linus Torvaldsin saattelemana. Torvalds osoitti, että ohjelmistoalalla yhdelläkin toimijalla voi olla valtavan katalyyttinen vaikutus.

Ohjelmistot ovat yksi 1900-luvun suurimmista innovaatioista. Ohjelmistojen vaikutukset näkyvät päivittäisessä elämässämme monin eri tavoin. Ohjelmoinnin työn tulokset ovat myös arkipäivästyneet huomaamattamme. Tietotekniikaa tuntemattomatkin tietävät googlettamisen perussäännöt. YouTube:n suomalainen viritiys eli ”Juutuuppi” on suurelle osalle nuorisoa ja aikuusväestöä tuttu videoiden lataus- ja levityspaikka. 1980-luvun hurjimmat reseptien säilömisvisiot Commodore Vic 20:lla ovat osoittautuneet alimitoitetuksi, kuten melkeinpä mikä tahansa tietotekniikan kehittymiseen liittyvä pitkäntähtäimen visio. Lähitulevaisuudesta on hyvä tietää, että Kaikki maailman valokuvat ovat latautumassa Internetiin huikealla nopeudella. Niin ovat teidänkin, arvoisa yleisö.
Tiedämme, että ohjelmistot valtaavat alaa elektroniikkateollisuudessa nopealla tahdilla. Kännykän kustannuksista on jo yli 75% ohjelmistojen kehittämisestä johtuvaa. 90% autoteollisuuden uusista innovaatioista syntyy ohjelmistojen ja elektroniikan kehittämisen seurauksena. Tämän vuosisadan alussa ohjelmistot ympäröivät meidät täydellisesti. Nykyään puhutaan ubiikista eli sulautetusta tietotekniikasta, jota tulee löytymään vaatteista, kengistä, laukuista, polkupyöristä ja vaikkapa vaatekuivaustangosta. Halusimme tai ei, olemme kaikki merkittäviä ohjelmistointensiivisten järjestelmien suurkuluttajia jo tällä hetkellä.

Ohjelmistojen ollessa arkipäivää ja niitä käytettäessä ei ohjelmointityön laatu ole sinällään merkityksellinen asia. Laadun tai laaduttomuuden huomaa vasta, kun joku haluttu asia ei toimikaan. Itse asiassa virhetilanteita on niin paljon, ettei niihin enää osaa kiinnittää edes erikoisesti huomiota. Voidaan perustellusti väittää, että olemme tulleet immuuneiksi ohjelmistojärjestelmissä piileville omituisuuksille, siis virheille –osin tietenkin pakon sanelemana. Voidaan luonnehtia, että reagoimme kuin 2000-luvun city-laamat virheeseen sen kohdatessamme. Emme edes hätkähdä, kun käyttämämme ohjelmisto ilmoittaa ”kaatuneensa”. Harmittelemme kenties sitä, että tulikohan se teksti tallennettua milloin viimeksi. Tietojärjestelmien toimittajatkin ovat joutuneet kehittämään uusia käsitteitä suomen kieleen ilmaisemaan toiminnallisuuden laatua. Toimia verbi on saanut kilpailijaksi toimahdella verbin, joka ei eilen aamuisen google-haun perusteella ole vielä kuitenkaan lähiaikoina syrjäyttämässä kantasanaansa. Toimahtelu tarkoittaa ohjelmistojärjestelmän ominaispiirrettä siinä tilassa, kun järjestelmä on kehitysvaheessa. Voidaan sanoa, että järjestelmä toimahtelee jo lupaavasti, mutta ei täysin kuitenkaan. Ongelma piilee kuitenkin siinä, että niin sanotusti valmiita järjestelmiä ei enää sanan varsinaisessa merkityksessä ole olemassakaan, vaan kaikki ovat jonkinasteisia kehitysversioita. Googlehan on institutionaalistanut beta-vaiheen järjestelmät. Ne kuvaavat järjestelmiä, jotka eivät ole vielä julkaisukelpoisia. Uutuus on siinä, että nämä betavaiheet näyttävät kestävät jo useita vuosia. Tiedämme, että beta-vaiheen järjestelmillä on siis toimahtelutakuu, mutta käytämme sitä kuin valmista järjestelmää. Onko maailma menossa suuntaan, jossa prototyypit ja tuotteiden esiasteet ovat yleisempiä, kun varsinaiset palvelut?

Mitä ovat ne virhetilanteet, joihin olen jo useamman kerran viitannut ja joihin olemme jo tulleet immuuneiksi? Annan muutamia käytännön esimerkkejä tästä ohjelmistojen laadun ilmentymästä käyttäjän näkökulmasta. Teillä on myös satoja ja kollektiivisesti tuhansia kokemuksia, kun niitä alkaa miettimään. Olin Saksassa työmatkalla ja yritin ostaa postimerkkiautomaatista postimerkin. Laitoin ohjeiden mukaisesti kolikon sisälle ja järjestelmä kiitti kohteliaasti, että ”Vielen dank”. Postimerkkiä ei kuitenkaan tullut ulos. Laitoin uuden kolikon systeemiin samalla tuloksella. Kolmannella kerralla ryhdikkään kiitoksen tullessa luovutin ja onnittelin Saksan paikallista postia uuden ansaintamekanismin luomisesta. Italiassa rekisteröidyin Internetpalvelujen käyttäjäksi lentokentällä ja naputtelin järjestelmään luottokorttitietojani. Hyväksyessä ostosuorituksen järjestelmä ilmoitti tylysti minun syöttäneen liian lyhyen luottokorttinumeron. Järjestelmä muistutti, että minulla täytyy olla 16 numeroa luottokortissani. Luulin tehneeni virheen ja olin tyytyväinen, että järjestelmä osaa noin tarkasti ohjeistaa. Mutta, monien uudelleenyritysten jälkeen minun oli todettava, että luottokortissani on vain 15 numeroa, eikä sitä voi kasvattaa tietojärjestelmäkehittäjien toiveesta huolimatta. Palvelu jäi ostamatta, aikaa meni parikymmentä minuuttia, eikä kenellekään voinut asiasta kertoa. Lentokentillä ohjelmistovirheet ovat enemmän sääntö kuin poikkeus. Matkustajia auttavat näyttötaulut ovat monesti pimeinä tuttuine Windows-logoineen ja virhetilailmoituksineen. Joskus ohjelmistovirheistä aiheutuu vakavia seuraamuksia. Tämän vuoden kesäkuussa metronohjausautomaatiikka petti Washington DC:ssä, jonka seurauksena 7 ihmistä menetti henkensä ja 100 joutui sairaalahoitoon. Tässä tapauksessa metrojuna törmäsi toiseen pysähdyksissä olleeseen junaan ilman selkeää syytä. Nyt täytyy huomata, että Helsingin metro automatisoidaan 2013 mennessä. 40-vuoden lähihistoriassa on lukuisia samansuuntaisia esimerkkejä kuuraketeista lennonohjausjärjestelmiin. Ohjelmistojen avulla tullaan käymään taistoon ilmastonmuutosta vastaan lähitulevaisuudessa, mutta yhtälailla ohjelmistot muodostavat yhteiskunnalle alati kasvavan riskitekijän, johon pureutuminen ei ole suoraviivaista.

Mikä tekee ohjelmistojen kehittämisestä niin vaikean? Miksi laadukkaita ohjelmistoja ei kyetä rakentamaan edes 60-vuoden kokemuksen perusteella? Tämä on hyvä kysymys, johon tulen vielä monesti palaamaan ohjelmistojen laatuun erikoistuvan professuurini oppituolissa istuessani. Ohjelmiston laatu ei ole yksiselitteinen käsite. Sitä voidaan lähestyä ainakin seuraavista näkökulmista: Käytettävyys, luotettavuus, siirrettävyys, ylläpidettävyys, testattavuus, ymmärrettävyys, tehokkuus, turvallisuus ja konsistenttisuus vain muutamia yleisimpiä laadun attribuutteja listatakseni. Käyttäjälle tärkeimmät ollevat käytettävyyden lisäksi luotettavuus ja turvallisuus. Laadunvarmistus on keino, jonka avulla varmistetaan, että kaikki halutut laatuominaisuudet on toteutettu.

Ohjelmisto kuitenkin eroaa muista fyysisistä artefaktoista monella eri tavoin. Sen tuotantokustannukset voivat olla merkittävät, mutta jakelu ja monistaminen ovat käytännössä ilmaisia. Sitä ei voi ottaa käteen, tunnustella tai pyöritellä. Ohjelmistot eivät näy tai tunnu fyysisessä maailmassa. Ohjelmisto ei periaatteessa kulu käytössä, vaikkakin evidenssiä ns. rapautumisesta onkin havaittavassa käytännön tietojärjestelmissä. Rapautuminen näkyy vaikka kännykässä. Älykännykän joutuu alustamaan ja tyhjentämään aika-ajoin, koska se muuttuu käytössä ns. tukkoiseksi tai käyttäytyy muuten epäluotettavasti. Ennustamattomat virhetilanteet johtavat uusiin ennakoimattomiin tilanteisiin, jota ei kehitys- tai käyttötilanteessa kyetty testaamaan tai virhettä toistamaan. Ohjelmistojen erityispiirteisiin kuuluu myös se, että niitä valmistetaan käsityönä vielä tänäkin päivänä mitä merkittävimmässä määrin. Voidaan perustellusti puhua hyvin pitkälle viedystä ja uudesta käsityöläisen ammatista. Ohjelmointitaitoa voi etäisesti verrata kirjoittamien taitoon. On opittava kielen syntaksti, kielioppisäännöt, hyväksyttävät lauserakenteet ja esitysmuoto. Kirjoittamaan oppiminen ei kuitenkaan tee kenestäkään vielä kirjailijaa. Ohjelmoimaan oppiminen ei niin ikään tee kenestäkään ohjelmistosuunnittelijaa. Tämän me olemme yliopistoissa jo ymmärtäneet 1960-luvun lopulta alkaen. Tuhansia menetelmiä on kehitelty vastaamaan käytännön tarpeisiin. Yliopistoissa pyrimme menetelmäopinnoilla valmentamaan opiskelijoita määrittelemään, suunnittelemaan, toteuttamaan ja testaamaan ohjelmistoja systemaattisesti hyviä käytäntöjä noudatellen.

Missä siis ongelma? Edellä esitettyjen ohjelmistojen laatutekijöiden tulee olla suunnittelussa ja kehittämisessä mukana ensimmäisestä päivästä lukien. Mitään niistä ei saada liitettyä jälkikäteen järjestelmään. Menetelmiä löytyy, mutta mikään menetelmä ei korvaa vuosien kokemusta ja ymmärrystä asiakastoimialasta. Ei ole vieläkään löytynyt ratkaisua sille kuinka tarkasti ohjelmistoammattilaiselle tulee kuvata työn kulku, jotta tulos olisi taatusti laadukasta. Tuhansista kehitetyistä menetelmistä arviolta 90% löytyy menetelmäkehittäjien kirjahyllystä, eivätkä ne koskaan saavuttaneet merkittävämpää suosiota. Menneenä vuosikymmenenä onkin nostettu esille uudelleen ihmisten ja vuorovaikutuksen merkitys ohjelmistojen kehittämisessä. Teknologia ei automatisoinutkaan ohjelmistosuunnittelua. Universaali ja matematiikkapohjainen määrityskieli ei saanutkaan jalansijaa yrityksissä. Työkalutoimittajien lupaukset paremmasta huomisesta kalpenivat nekin ihmislähtöisten arvojen vallatessa alaa.

Ohjelmistoalan mielenkiintoinen piirre liittyy kyvyttömyyteen päätellä osaamisen taso. Korostaakseni tätä näkökulmaa, otetaan käytännön esimerkki muulta alalta valottamaan tilannetta. Kun tulee tarve teettää sähkötöitä talossa, niin soitto läheiseen sähköfirmaan tuottaa paikalle nuoren ja kenties vastavalmistuneen sähköinsinöörin, joka hyvin suurella varmuudella kykenee ratkaisemaan ongelman laadukkaasti ja turvallisesti. Yksityiset henkilöt harvoin ostavat ohjelmistoja, mutta yhteisöt ja yritykset luonnollisesti tekevät merkittäviäkin hankintoja. Julkishallinnollisilla yhteisöillä tai yksityisillä yrityksillä ei kuitenkaan ole mitään toimivaksi todettua mallia, jolla varmistetaan etukäteen ohjelmistotoimittajan kyky tehdä työ menestyksekkäästi valmiiksi. Ohjelmistoalalla ei ole edes insinöörin tutkintoa, joka takaisi, että ohjelmistokehittäjä osaa edes tietyt perusasiat valmistuessaan. Tutkintorakenne on kohtuullisen hajallaan sekä maailmalla, että Suomessa. Lainaan nyt erästä ohjelmistoalan kokenutta menetelmäkonsulttia, joka otti minuun yhteyttä jonkin aikaa sitten meilitse: ”Ollaan muuten juteltu täällä silloin tällöin, miten saisimme yliopisto/ akateemisen yhteisön mukaan Agileen. Perusopetusta vedetään edelleen perinteisellä ja viimeistään 2-3 vuoden päästä valtaosa IT -alan töistä tehdään ei-perinteisellä. Ei ole kenenkään edun mukaista, työmaailmassa joudutaan “uninstalloimaan” yliopisto/korkeakouluopit, ja opettamaan perusasiat uusiksi. ”

Perinteinen maailma, johon menetelmäkonsultti viittaa, olettaa, että tietojärjestelmätarpeet voitaisiin ennalta käsin määritellä, kuten vaikkapa sillan tai talonrakentamiseen liittyvät vaatimukset ja edellytykset. Perinteinen maailma myös olettaa, että muutokset alkuperäisiin vaatimuksiin nähdään järjestelmänsuunnittelun heikkoutena ja puutteena, jota pitäisi välttää. Käytäntö on kuitenkin osoittanut toisin. Ohjelmistot ovat vain osin insinööritieteiden selitettävissä. Voidaan väittää, että merkittävin osuus selittyy paremmin ihmistieteiden kautta. Ohjelmistojen valmistaminen on oppimisprosessi, jossa pienin inkrementein ja alituisin muutoksien avulla saavutetaan parempi ymmärrys ratkaisun alla olevavasta monimutkaisesta ongelmasta. Oppimista tapahtuu kaikkien osapuolien välillä eikä sen merkitystä tulisi väheksyä. Jos tämä hyväksytään, tästä on merkittävä implikaatioita aina lainsäädäntöön saakka.

Nykyään nimittäin EU:n direktiivit ja suomen hankintalaisäädäntö otaksuu, että ohjelmistot ovat rinnastettavissa mihin tahansa hankintaan. Hankinta voi liittyä yhtälailla moottoritien rakentamiseen kuin makkaratehtaan elintarvikkeiden tilaamiseen. Molemmat on kilpailutettava julkishallinnon hankintalain mukaisesti samojen kilpailutusprosessien kautta. Käytännössä tämä tarkoittaa sitä, että julkisoikeudellinen taho hankkii konsultin tekemään hankinnan alla olevasta järjestelmästä määritykset, josta käy ilmi tarkasti millaisesta järjestelmästä on kyse ja millaisia vaatimuksia sille on asetettu. Ohjelmistojen toimittajat tekevät tarjouksensa perustuen määritysdokumenttiin ja valitsevat kokonaisedullisimman toimittajan hankinnalle. Hankintapäätöksen jälkeen määritykset joudutaan kirjoittamaan toimittajan taholta uusiksi siksi, että aletaan tarkemmin ymmärtämään mistä todellisuudessa on kyse. Määritykset muuttuvat vielä lukuisia – lukuisia kertoja ennen kuin järjestelmä on lopullisesti käytössä. Alkuperäinen määritysdokumentti muistuttaa tuskin etäisesti sitä järjestelmää, jota asiakas oikeasti tarvitsi käytännössä. Voisin väittää, että yhtä vakuuttava kilpailutuksen tulos saavutettaisiin, jos ohjelmistotoimittajakandidaatit pistettäisiin juoksemaan 100 metriä kilpaa ja esimerkiksi kolmanneksi nopein valittaisiin toimittajaksi. EU:n komission tietojärjestelmätoimittajia joudutaan vaihtamaan aina tietyn ajan jälkeen tasapuolisuuden nimissä. Tiedämme kuitenkin sen, että toimiva asiakassuhde ohjelmistoalalla vaatii vuosien yhteistyön sekä erittäin vahvan ymmärryksen asiakkaan liiketoimintaympäristöistä ja –tarpeista.

Alan huimimpiin visioihin kuuluu näkemys, jonka mukaan tulevaisuuden ohjelmistojen valmistus on loppukäyttäjien – eli Teidän ja meidän – käsissä. Tätä kutsutaan loppukäyttäjäohjelmoinniksi. Näin vältetään virhetilanteita, joissa palvelut eivät vastaa kuluttajien tarpeita. Joku voisi kutsua tätä utopiaksi, mutta Internetin kotisivujen suunnittelussa ja toteutuksessa tämä toteutui alle kymmenessä vuodessa. Muistamme, että 1990-luvun puolivälissä ns. webbisivujen tekeminen oli teknologisesti monimutkaista ja vaati osaamista, jota loppukäyttäjillä ei ollut. Muutamassa vuodessa monet palvelut ovat helpottaneet kotisivujen tekemisen siten, että sellaisten luominen ei vaadi tekstinkäsittelytaitoja kummempaa osaamista. Teknisten esteiden poistuessa sisällön merkitys kasvaa, mikä voidaan nähdä erittäin positiivisena suuntauksena.

Olen taustoittanut ohjelmistokenttää monesta eri näkökulmasta, mutta missä piilee lupaamaani ohjelmiston laadun uusi aikakausi?

Maailma on muuttunut, ohjelmistot ja niiden kehittäminen elävät jatkuvassa murroksessa. Tulevaisuuden pilviteknologiat mullistavat palvelujen jakelukanavat. On luontevaa ajatella, että tulevaisuudessa ohjelmistojen laadun varmistamisessa ja ohjelmistojen kehittämisessä tapahtuvat harppaukset liittyvät biologiasta omaksuttujen käsitteiden toteutumiseen järjestelmissä. Tulevaisuuden järjestelmät ovat vikasietoisempia kuin ohjelmistot nykypäivänä. Puhutaan järjestelmistä, jotka hoitavat itsenäisesti vikatilanteet järjestelmissä olevien luontaisten vasta-aineiden alkaessa toimimaan. Avoimuus tulee murtamaan perinteiset raja-aidat. Järjestelmien rajapintojen avoimuus on jo nyt tehnyt mahdollistanut tiedon liikkumisen eri järjestelmien välillä, vaikkakin viime viikolla julkaistu EVAn selvitys kuvasi kuntien tietojärjestelmäkenttää räjäytystä vailla olevana kaoottisena toisistaan riippumattomien tietojärjestelmien ja tietokantojen viidakkona. Laatu ei ole siis pelkästään valmistustekninen tai -teknologinen asia, vaan vaatii eri osapuolten tiivistä yhteistyötä ja aitoa halua palvella paremmin asiakkaita ja loppukäyttäjiä. Tämä aito halu palvella ei synny tai toimi suljetuissa järjestelmissä.

Ohjelmistoala on äärimmäisen herkkä uusille trendeille. Voidaan osin puhua jopa muotiteollisuudesta. Jokaiselle vuosikymmenelle löytyy omat muotivirtaukset. Dynamiikan kasvaessa, tutkimus ja opetus tuntuvat kuitenkin junnaavan hieman paikallaan tavalla, johon soisi parannusta tulevan. On kestämätöntä ajatella, että yliopistot tuottavat alalle ammattilaisia, joita pitää uudelleenkouluttaa käytännön reaaliteettien, teknologioiden ja työtapojen suhteen. Vankan teoreettisen pohjan luominen tulee säilyä opetusohjelmissa. Vuoropuhelua käytännön ammattilaisten kanssa tulee kuitenkin tiivistää ja siihen Eurooppalaiset laajat ns. runkoprojektit ovat osoittautuneet olevan oiva keino. Muitakin keinoja löytyy. Yliopistolain muuttuessa ensi vuoden alusta, yliopistot kykenevät yhä paremmin päättämään itsenäisesti oman suuntansa. Tämä avaa myös uusia mahdollisuuksia integroida ja luoda uusia kanavia opiskelijoiden, opettajien, tutkijoiden ja käytännön ammattilaisten välille. Vuoropuhelun kautta opetusohjelma säilyttää luontevan kosketuspinnan reaalielämän haasteiden kanssa.

Ohjelmistot jatkavat voittokulkuaan laitteissa ja kojeissa. Tulevaisuuden teknologiat ja toimijat tulevat kehittymään nopeammin ja huimemmin kuin kykenemme ennalta arvaamaan. Olen edellä esittänyt muutamia mahdollisia skenaarioita laadun uuden aikakauden siemeneksi. Nyt on aika tiivistää ja konkretisoida näkemykseni: Laatuongelman ratkaisemisen keskiössä tulee olemaan avoimen lähdekoodin lanseeraama avoimuuden polku, jota itse asiassa alamme vasta nyt hahmottamaan ja ymmärtämään. Avoimuutta seuraa läpinäkyvyys. Rajapintojen avautuminen on vasta ensimmäinen askel. Tästä seuraa järjestelmien asteittainen avautuminen sekä läpinäkyvien pilvipalvelujen yleistyminen. Läpinäkyvyyden muista ulottuvuuksista meillä ei ole edes vielä tietoa. Ohjelmistotoimittajilla tulee olemaan kiire uusien liiketoimintalogiikoiden luomisessa maailmassa missä ohjelmistojen kehittämisellä ei enää ole suoraa yhteyttä omistamiseen ja lisensointiin, joiden merkitys ansaintalogiikan mielessä vähenee päivä päivältä. Läpinäkyvyyden luoma positiivinen paine tulee vaikuttamaan laatuun monessa eri kerroksessa. Tässä on monella suomalaisella IT-alan palvelutarjoajalla mahdollisuus olla eturintamassa murroksessa.

Linus Torvaldsin käyntiinsaattama avoimen lähdekoodin maailmanvalloitus saa siis 2010-luvulla uusia ulottuvuuksia, joilla on syvällinen vaikutus myös laadun kehityksen kannalta tarkasteltuna.

Kiitos!