Väitös: Ohjelmistotuotannon tarkastuksia syytä petrata
Sami Kollanus
Ohjelmistotuotantoa harjoittavien organisaatioiden tarkastuskäytänteissä on tuoreen väitöskirjatutkimuksen mukaan vielä paljon parantamisen varaa.
8.5.2009 13:55
5
Ohjelmistotyössä tarkastuksilla tarkoitetaan laadunvarmistusta, joka toteutetaan manuaalisesti lukemalla tarkastettavaa tuotosta.
Aiemmin on havaittu, että tarkastusten systemaattinen käyttö on ohjelmistotuotteiden laadun parantumisen lisäksi tuottanut merkittäviä kustannussäästöjä sekä parannusta koko ohjelmistotuotannon tehokkuuteen. Hyödyistä huolimatta tarkastusten käyttö teollisuudessa on melko puutteellista.
Sami Kollanus tarkastelee väitöskirjassaan tarkastuskäytänteiden puutteita ja ongelmia sekä tarkastuskäytänteiden kehittämistä ohjelmistoja tuottavissa organisaatioissa.
Oleellisin puute
koulutuksessa
Tutkimuksen suomalaisissa kohdeorganisaatioissa tarkastuskäytänteitä sovellettiin jonkin verran paremmin kuin aiemmissa kansainvälisissä tutkimuksissa. Käytänteissä on kuitenkin vielä runsaasti parannettavaa.
Jopa hyvin systemaattisesti toimivissa käytänteissä saattaa ilmetä sellaisia käytännöllisiä ongelmia, jotka vaikuttavat merkittävästi tarkastuksista saatavaan hyötyyn.
Väitöskirjassa kuvataan tavallisimmat tarkastuskäytänteissä ilmenevät puutteet ja ongelmat.
– Oleellisin kaikkia kohdeorganisaatioita yhdistävä puute käytänteissä oli se, että työntekijöille ei tarjota lainkaan tarkastuksiin liittyvää koulutusta. Merkittävin käytännön ongelma tarkastusten toteutuksessa oli heikko tarkastuksiin valmistautuminen. Tarkastusten onnistumisessa keskeisintä vaikuttaa olevan osaavien työntekijöiden riittävä motivaatio tuotosten tarkastamiseen, Kollanus havaitsi.
Ohjelmistoja tuottavien organisaatioiden on tarpeellista parantaa tarkastuskäytänteitään. Kollanuksen väitöskirja vastaa tähän käytännölliseen tarpeeseen kehittämällä lähestymistapoja tarkastuskäytänteiden parantamiseen. Kehitetyistä lähestymistavoista on saatu tutkimuksessa lupaavia kokemuksia.
KTL Sami Kollanuksen tietojärjestelmätieteen väitöskirjan Tarkastuskäytänteiden kehittäminen ohjelmistoja tuottavissa organisaatioissa tarkastustilaisuus pidetään Jyväskylän yliopiston Mattilanniemen Agorassa lauantaina 16.5.2009 klo 12. Vastaväittäjä on professori Ilkka Tervonen Oulun yliopistosta ja kustoksena KTT Jussi Koskinen.
Kommentit (5)
Helpoin tapa muuttaa tilanne olisi laittaa ohjelmistotalot vastuuseen tuotteistaan samaan malliin kuin perinteisen teollisuuden edustajat. Eli ohjelmiston virheet olisi korjattava kohtuullisessa ajassa, ja vastuu jatkuisi samoin kuin myyjän virhevastuu (esim.) kodinkonekaupassa. Voisi jopa olla aiheellista että ohjelmistojen valmistajille tulisi jonkinlainen vastuu välillisistä menetyksistä jotka heidän tuotteidensa ostajille tulee.
Näinhän on esim. autojen valmistajien kohdalla jotka joutuvat aina tasapainottelemaan sen välillä että paljonko heille tulee vahingonkorvausvaateita virheistä, ja korjaamaan ongelmat niissä tapauksissa kun korjauksen kustannus on pienempi kuin korvaukset. Ohjelmistoalalla korvaukset ovat lähes tuntematon käsite, ja uskoisin että lähes kaikkien ohjelmien sopimusehdot ovat laittomia ainakin suomessa.
Entäs business-sovellukset jotka räätälöidään asiakkaalle? Asiakas ei välttämättä halua ko. koodia "kaikkien tietoon" koska siitä voi olla haittaa omalle kilpailukyvylle. Esimerkkinä vaikkapa aseteollisuus, siellä on kysyntää tehokkaammille menetelmille koodin validoimiseksi mutta hyvin vähän halua julkaista koodia.
Myös raskaammissa Business-analyysisovelluksissa on yleensä juuri se rahanarvoinen ajatus siellä koodissa toteutettuna eikä sitä luonnollisesti haluta OpenSource-pohjalle. Ja monelta osin näille sovelluksille ei ole käyttöä kuin massiivisissa kaupallisissa ympäristöissä eli OpenSource-kehitykselle ei ole mielenkiintoa (eikä osaamista koska tässä pitäisi ymmärtää myös laajasti talouslaskentaa).
Monessa isommassa firmassa tehdään vielä nykyäänkin paljon softaa in-house ja hommassa pyritään säästämään kaikessa missä se on mahdollista, ei siinä paljoa korvausvaateet paina kun tekijät on omassa rivissä ja ongelmat johtuu liian kireästä aikabudjetista sekä kouluksen puutteesta, tekijätkin ovat usein varsin kirajaa sakkia. Tehokkaalla koodin validoinnilla voidaan todeta miltä osin porukkaa pitää vähän koulua ja parantaa firman asiakkailleen tarjoamien palveluiden laatua (esim. Sampolla olisi ollut käyttöä mm. paremmalle koodin validoinnille).
no shit, sherlock!
Ongelma on siinä, että testaus ei juurikaan pääse pureutumaan noihin sisäisiin ongelmiin.