Poikkeuksellinen virhe

20.12.2008

Jokainen tekee virheitä, paitsi minä. Minä teen poikkeuksia. Suorastaan heittelen niitä. Ohjelmoinnissa virheen voi nimittäin miltei aina kuitata olevan ohjelman ominaisuus (Ohjelmointivirhe s.a.). Kauppa hyväksyy negatiiviset määrät, koska kukaan ei ole määritellyt ettei sen pitäisi hyväksyä. Miksi siis rajoittaa hienon kaupan mahdollisuuksia, vaikka ostoskori näyttäisikin, että ostajan kuuluisi saada palautuksena rahaa miinus appelsiinistaan?

Sara Nikander
Director, Design & Technology

sara.nikander@valve.fi
045 6735 577

Poikkeus taas on hallittu keino reagoida ei-toivottuihin tapahtumiin. Jotta poikkeuksia olisi mahdollista ennakoida, tulisi tehdä kattava ohjelman määrittely ja poikkeuksien kartoitus. Virheitä ei siten kannata pelätä vaan odottaa. Pelko on tunnetila johon liittyy ohjelmistokehityksen kannalta liuta haitallisia defenssimekanismeja kuten: kieltäminen, vähättely, epäusko ja valehtelu. Eihän kukaan voi syöttää niitä negatiivisia tuotteita, koska se ei ole loogista. Miinusesimerkki on ehkä heikko pelottavuuden kannalta, mutta osoittanee kuitenkin sen, että toiveet toteutuksesta tulisi lausua ääneen, jotta saisi varmuuden niiden toteutumisesta.

Ohjelmistokehitys on kuitenkin ihmisen tekemää työtä ja tällöin myös ihan oikeasti virheitä voi sattua, vaikka kuinka niihin varauduttaisiin. Tehdäänkin siis tämän kerran poikkeus ja myönnetään: kyllä minäkin teen toisinaan virheitä. Mitä niistä sitten seuraa eli paljon palaa hynää?

Mitä maksaa?

Toisinaan virheet ovat sillä tasolla, että ne voidaan korjata ilman negatiivista julkisuutta tai käyttäjien menetyksiä. Ainoiksi kustannuksiksi tällöin jäänee mielipaha ja korjauskulut. Joskus käy taas niin, että virhe on sitä kaliiberia, että siitä lukevat lööpeistä ihmiset, jotka eivät kenties koskaan järjestelmää edes käyttäisikään ja hekin nauravat myötähäpeästä.

Kaikille lienee tuttuja Suomen eduskuntavaaleissa 2008 käytetystä sähköisestä äänestysjärjestelmästä aiheutuneet erinäiset kulut (Rantanen 2008). Mukaan on laskettava myös järjestelmän perustamiskulut, mikäli järjestelmä hylätään tulevaisuudessa (Sähköinen äänestys s.a.). Muita esimerkkejä isomman luokan kämmeistä löytyy lähihistoriasta esimerkiksi Sampo pankin uuden verkkopankin käyttöönotosta (Sauvala & Toivanen 2008). Joku voisi sanoa, että nämä oppirahat olivat pieniä verrattuina tietoihin mitä käyttöönotoista saatiin. Se joku ei varmaankaan tee kustannusarvioita päätoimenaan.

Isompienkin projektien horjuessa noin pahasti, miten pienemmätkään voivat tarkasti määrittää riskiensä hintaa? Sammakkoennustajat tai voodoomammat tuskin osuvat oikeaan, mutta ehkä tehdyistä tutkimuksista vedetyt keskiarvot ohjaavat hieman oikeampaan suuntaan. Alempana taulukko virheiden korjauskustannuksista:

Esiintymisen ajankohta Vaatimus-määrittely Arkkitehtuuri Valmistus Testaus Julkaisun jälkeen
Vaatimusmäärittely 1 3 5-10 10 10-100
Arkkitehtuuri - 1 10 15 25-100
Valmistus - - 1 10 10-25

Keskimääräiset virheiden korjauksista aiheutuneet kustannukset (McConnell 2004, 29)

Tulkitaanpa hieman taulukkoa. Jos esimerkiksi ohjelman arkkitehtuurista löytyy suunnitteluvaiheessa virhe, ja se korjataan silloin esimerkiksi 100? kustannuksilla, saman virheen korjaus maksaisi testausvaiheessa 1500? (ibid.). Arkkitehtuurinen virhe johtaa nimittäin yleensä ainakin osan ohjelman uudelleen suunnitteluun, kirjoittamiseen, testaamiseen ja julkaisuun. Kierre on valmis ja toisin kuin kanelipullan, tämä kierre ei ole herkullinen. Silti jonkun on se syötävä, mutta kenen?

Kuka maksaa?

Osakeyhtiölaissa osakeyhtiön oikeudellinen tarkoitus on olettamasäännön mukaan voiton tuottaminen osakkeenomistajille. Tekijä tekee tuotteen tilaajalle maksusta, jolloin kustannukset tuotteesta siirretään tilaajalle. Virheet toteutuksessa analysoidaan ja tehdään päätös johtuivatko ne puutteellisista vaatimuksista ja ovat täten tilaajan maksettavia, vai ovatko ne vaatimuksien laiminlyöntejä eli tekijän korvattavia. Kumpikaan osapuoli ei voi loputtomiin ottaa nieltäväkseen kustannuksia, koska tällöin ne eivät toteuttaisi oikeudellista tarkoitustaan vaan tekisivät tappiota. Väistämättäänkin käsissä on ristiriita, joka purkautuessaan vihamielisenä tekee särön yhteistyökumppanien välille.

Jos ei tahdo maksaa?

Luova työ on intohimon kohdistamista luomiseen. Nihkeissä väleissä väkisin pikistetty luomus näyttää siltä itseltään ja asiakas kyllä huomaa. Seuraa välirikko, jonka seurauksena saatetaan menettää vuosia kestäneen yhteistyön hedelmät puhumattakaan mahdollisista tulevaisuuden aarteista. Mitä vaihtoehtoja on tälle vahingolliselle syyllisen etsiskelylle?

Määrittelyt kuntoon. Vaatimusmäärittelyt itsessään ovat niin laaja alue, että niitä ei ole mahdollista tarkastella nyt tarkemmin. Todettakoon vain, että hyöty panostuksesta projektin alkupäässä on havaittavissa esimerkiksi yllä olevasta taulukosta.


Mietitään mitä halutaan, supistetaan toimialuetta. Aina kun järjestelmään lisätään toiminnallisuutta, on sille kirjoitettava määritykset, suunnitelmat, toteutukset ja testit. Lisäksi on selvitettävä miten se vaikuttaa aikaisempaan arkkitehtuuriin. Mitä monimutkaisemmaksi järjestelmä käy, sitä enemmän se on altis virheille.


Hyväksytään tietty virheaste. Aina on virheitä ja poikkeuksia. Kokenut ymmärtää ettei mitään voi suunnitella vedenpitäväksi. On vain asennoiduttava siihen, että jotain epämääräistä voi tapahtua, ja tehdä pätevä suunnitelma virheiden varalle. Nopea reagointi osoittaa sen, että ohjelmasta välitetään.

Tahtoa maksaa

Inhimillisiä virheitä eli Human Erroreita(lyhennettynä HE) varten tarvittaisiin jonkin sortin Human Error mies eli HE-man. Sellaisen puuttuessa on kai vain tyydyttävä ottamaan ne huomioon kustannusarvioissa. Muut semanttisella tasolla liikkuvat virheet ovat estettävissä, jos tahto on tarpeeksi kova. On vain arvioitava mille tasolle tahto loppuu, sillä tahto kuten moni muukin asia, kulkee käsi kädessä rahan kanssa.

Lähdeluettelo

Anon: Ohjelmointivirhe. Wikipedia. Viitattu 20.12.2008.
Anon: Sähköinen äänestys. Wikipedia. Viitattu 20.12.2008.
McConnell, Steve 2004: Code Complete, Second Edition. Microsoft Press, Washington.
Rantanen, Miska: Kunnat peräävät sähköisen äänestyksen kuluja ministeriöltä. HS.fi. 12.12.2008. Viitattu 20.12.2008.
Sauvala Milka; Toivanen Jarmo: Sampo Pankki hyvittää asiakkaille neljän kuukauden palvelumaksut. HS.fi 23.4.2008. Viitattu 20.12.2008.