Aihe: ‘Ohjelmistotestaus’

Miksi julkiset IT-hankkeet niin usein menevät pieleen?

maanantai, 5 maaliskuuta, 2012 | Kirjoittaja: Jaakko Sakaranaho

Tietoviikko pohdiskelee aihetta, että voiko julkisella sektorilla huonosta IT-hankkeesta kieltäytyä. Siellä puhutaan hienoja sanoja ja kerrotaan, että hieno strategia ict-hankintoihin pitäisi olla. Minä uskon, että IT-strategiatyöryhmistä ei löydy ratkaisua tähän ongelmaan.

Toimikoon tämä kirjoitus enemmän hahmotelmana ja keskustelunavauksena, kuin ilmiselvänä faktana. Kirjoituksen tarkoituksena pohdiskella, minkä vuoksi julkiset it-hankkeet epäonnistuvat niin usein. Aluksi käyn lyhyesti läpi lähteiden it-hankkeiden onnistumisten ja epäonnistumisten syytä. Sitten kuvataan lyhyesti julkisten it-hankkeiden kilpailutusmenettelyt. Voi olla, että nuo kaksi asiaa liittyvät toisiinsa.

Googlettamalla “Why software projects fail” löytyy sivustokaupalla syitä, miksi it-projektit ylipäätään voivat mennä pieleen. Listoilla on hieman eri painotuksia, mutta jokaisessa nousee esille loppukäyttäjän näkökulman puute. Siis se, että hankkeen speksaa, kilpailuttaa, tilaa ja hyväksyy jokin aivan muu taho, kuin loppukäyttäjät. Lisäksi johdon tuki oli usein puutteelista tai jopa olematonta. Oleellista on huomata, että teknologiset haasteet tai henkilöiden “epäkurantti” osaaminen eivät olleet lähellekään yhtä merkityksellisiä tekijöitä.

Onnistuneille projekteille ominaista on, kuten edellisen kappaleen perusteella arvata saattaa, että loppukäyttäjät ovat alusta asti osallisena projektiin. Tämä auttaa paitsi tekemään toimivamman softan, helpottaa se myös käyttöönottovaihetta, kun ohjelmisto on tuttu. Loppukäyttäjien mukanaolo puolestaan johtaa väistämättä siihen, että ohjelmiston vaatimuksia lisätään, muutetaan ja poistetaan kehitystyön edetessä. Tämä vaatii joustavia kehittäjiä ja projektipäälliköitä, jotka oikeasi haluvat saada asiakkaan tyytyväiseksi ja tuotteen erinomaiseksi.

Julkiset IT-palveluiden kilpailutukset etenevät kutakuinkin seuraavasti:

  1. Julkinen yksikkö päättää, että tarvitaan Järjestelmä.
  2. Julkinen yksikkö saattaa tehdä tietopyynnön, missä potentiaalisilta toimittajilta pyydetään kommentteja.
  3. Hankittavan Järjestelmän vaatimusmäärittely tehdään parhaan kyvyn ja osaamisen mukaan. Mukana arvailemassa saattaa olla myös tulevia käyttäjiä
  4. Toimittajat kilpailutetaan ja valitaan kokonaistaloudellisesti edullisin

Valitulla Toimittajalla on speksi, jonka perusteella ohjelmisto pitää toteuttaa kiinteään hintaan. Muutosten tekeminen on hankalaa, koska se muuttaa Toimittajan aikataulutusta ja sitä kautta kasvattaa kuluja tai vaihtoehtoisesti Julkisen yksikön tulisi kasvattaa budjettia. Se on aika hankalaa julkisella sektorilla, joten mennään alkuperäisen suunnitelman mukaan.

Näin ollen, julkisissa hankinnoissa on rasitteena kilpailutuksesta ja kilpailulainsäädännöstä johtuva rakenteellinen ongelma. Loppukäyttäjien tiedon ja asiantuntemuksen hyödyntäminen projektin kuluessa on tehty kutakuinkin mahdottomaksi. Ja kuten aikaisemmin todettiin, on se suurin yksittäinen syy, miksi IT-hankkeet epäonnistuva.

En tunne kilpailulainsäädäntöä kovin hyvin. Jos kilpailutuksen voisi hoitaa siten, loppukäyttäjät saadaan järkevästi mukaan hankkeeseen, niin lakimuutoksia ei silloin tarvittaisi. Ainoastaan osaamista ostoihin. IT-järjestelmän kilpailutusta ei voida tehdä samoilla menetelmillä, kuin lumen aurausta tai lämpöpumppujen asennusta.

Avaan keskustelun!

 

 

Share

Testauksen automatisointiko mullistaisi it-alan?

maanantai, 27 helmikuuta, 2012 | Kirjoittaja: Jussi Niittyviita

Tietoviikon tammikuussa julkaisemassa artikkelissa puhutaan testauksen automatisoinnista ja it-alan muuttuvasta ilmapiiristä. Avasin artikkelin kiinnostuneena, mutta aivoni jäivät lyömään tyhjää heti ensimmäisen lauseen kohdalla:

Ohjelmistotestaajan työ ja koko testaaminen ovat muuttumassa.

Testauksen perimmäisenä tarkoituksena on nostaa esille ne virhekohdat tuotteesta, jotka haittaavat loppukäyttäjän käyttökokemusta. Vaikka testaaminen saattaisi lisääntyä tuotteiden monimutkaistuessa, testauksen tarkoitus ei muutu mihinkään. Onko siis tarkoituksenmukaista ajaa ohjelmistotestaajan työtä ja koko testaamista muutoksen tielle?

Tietoviikon artikkelin lisäksi useasta lähteestä kuulee nykyään samaa raitaa missä lauletaan, että pitäisi panostaa enemmän testauksen automatisointiin. Joillekin automatisointi tuntuu olevan uuden testamentin veroinen ohjenuora työelämän pitkospuille. Sen nimeen vannotaan ja siihen panostetaan aina vain enemmän ja enemmän. Liekköhän tässä ollaan muutoksen tiellä ohituskaistalla vai ajamassa rampilta alas hitaaseen ja tukkoiseen taajamaan…

Vaikka testauksen automatisointi kannattaakin tietyissä tilanteissa, mielestäni testauksen automatisoinnin yhteydessä ei voi puhua testauksesta.  Kun testaustyö automatisoidaan, kyseessä on enää vain koneellinen tarkistus. Testauksen ja koneellisen tarkistuksen välillä on hurja ero. Niin pitkään kuin tuotteiden loppukäyttäjinä ovat ihmiset, ei varsinaista testausta kannata korvata koneellisesti. Koneet löytävät pieniä ja teknisiä nippelivirheitä, kun taas ihmiset löytävät fiilispohjaisia virheitä. Väitän, että olennainen osa virheistä löytyy jälkimmäisellä tavalla. Se on osa, joka vaikuttaa merkittävästi tuotteen myyntipotentiaaliin.

Jos testaamisen lisääntyessä testaajien määrä pienenee, ollaan ohjelmistokehityksessä hyvin vaarallisella tiellä. Tuolla tiellä merkittäviä virheitä jää löytymättä sitä mukaa kun rahaa palaa automatisoinnin suitsuttamiseen ja toteuttamiseen. Silloin kannattaa pysähtyä kysymään: Onko kyseinen yhtälö todellakin taloudellisesti kannattava?

Share

Lissabonista Floridaan

tiistai, 14 helmikuuta, 2012 | Kirjoittaja: Antti Niittyviita

Uusi manner löydettiin ja dokumentoitiin Eurooppalaisten toimesta ensikertaa vuonna 1492. Tuolloin tutkimusmatkailija Kristoffer Kolumbus löysi Amerikan etsiessään meritietä Intiaan. Löydöksen jälkeen alkoi tiivis merimatkailu Atlantin yli.

Merimatkojen tekemiseen sovelletut navigointimenetelmät olivat karkeita ja perustuivat suurelta osalta tähtien ja auringon aseman seuraamiseen. Määränpää saavutettiin onnistuneesti vain silloin kun kurssia korjattiin riittävän usein navigoinnin tulosten perusteella.

  1. Navigointi
  2. Kurssin korjaus

Se on totuus, jonka tiesivät jopa Viikingit 1000 vuotta sitten. Tästä huolimatta useat nykyaikaiset tietojärjestelmähankkeet lähtevät aina oletuksesta missä kurssi asetetaan yhden ainoan kerran suunnitteluvaiheessa. Sitten laitetaan silmät kiinni, peukut pystyyn ja toivotaan vain niin pirusti.

Kerta toisensa jälkeen mediasta saa lukea esimerkkejä hankkeista, jotka ovat kestäneet 5 vuotta ja sitten menneet pahasti pieleen. Maaliin osutaan vuosia myöhässä ja miljoonia euroja köyhempänä.

Navigointi ja kurssin korjaaminen

Navigointi ja kurssin korjaaminen

Ehdottaisinkin, että ne tietojärjestelmähankkeiden omistajat, jotka eivät uskalla luottaa sokeasti ajan ja rahan riittämiseen, tutustuisivat tähän kuvaan ja pysähtyisivät hetkeksi miettimään merimatkailun saloja.

Menestykseen ja maaliin voit siis päästä kahdella tavalla: Voit joko navigoida ja korjata kurssia riittävän usein, tai luottaa hyvään tuuriisi.

Share

Akku irti!

maanantai, 23 tammikuuta, 2012 | Kirjoittaja: Jussi Niittyviita

Akku irti todellakin. Paras ohje, mitä kannattaa ensimmäisenä noudattaa ohjelmistovian sattuessa. Kuinka monta kertaa olet nykypuhelimien aikana joutunut käyttämään akkua pois paikaltaan? Kuinka monta kertaa olet käynnistänyt tietokoneesi kun yksittäinen ohjelma jarruttaa koko konetta? Oletko joskus joutunut sammuttamaan autosi bugisen ajotietokoneen temppuilun takia? Mikä parasta, joissakin automalleissa on nykyään pikakiinnikkeet akun johdoille ainoastaan siitä syystä, että ohjelmistovian sattuessa voidaan käyttää “akku irti”.

Mistä johtuu, että nykyaikana ollaan hyväksytty tiettyjä alkujaan negatiivisia asioita lähes arkirutiineiksi? Kun itse ostan kännykän kaupasta haluan kuvitella, että se toimii ilman mitään maagisia akunirrotuksia tai 8 sekunnin virtanappirituaaleja. Enkä todellakaan halua liata käsiäni moottoritien varrella auton akkupiuhoja irroittaessani taikka hakata läppärini reset-nappia, kun MS Office alkaa hyppimään silmille. (Tähän Applemies sanoisi, että osta Mac. – En osta.)

Aikani mietiskeltyäni päättelin, että tämä kaikki johtuu siitä koska niin on aina ollut. Ilmiö on sama kuin normaalin tupakan käytössä. Jos tupakka tulisikin vasta nyt uutena tuotteena markkinoille, se luultavasti kiellettäisiin vakavana terveyshaittana. Mutta koska tupakka on ollut markkinoilla jotakuinkin niin pitkään kuin ihminen on tulta käyttänyt, se hyväksytään arkipäiväsenä vaikkakin yleisesti negatiiviseksi miellettynä asiana. Kun akkua ollaan irroiteltu jo ties kuinka pitkään, se hyväksytään yhtälailla negatiivisin tuntein.

Sama hyväksyminen on syöpynyt jopa niin pitkälle, että suuri osa puhelinvalmistajien testaajista eivät koskaan pidä testattavassa laitteessa “takakantta” paikallaan. Tämä ainoastaan sen takia, että akku olisi helpompi irrottaa ongelmatilanteen sattuessa ja lisäksi sen takia, että puhelimen tekninen tarkastelu tietyin apulaittein on vaivattomampaa, kun akun saa poistettua käden käänteessä. Tämä tuskin on tarkoituksenmukaista loppukäyttäjätestausta. Kukahan oli se suuri testaajanero, joka ensimmäisen kerran huomasi, että vian saa korjattua akun irroittamisella.

Nykyaikainen yhteiskunta perustuu virrankulutukseen. Minkä ihmeen takia pitäisi yksittäisestä laitteesta katkaista virta saadakseen sen taas toimimaan?

Akku irti! Kuten sanonta kaikuu vieläkin mielen pimeimmissä syövereissä vuosia sitten äijäporukalla toteutetun lasketteluviikonlopun jälkeen saavuttaen yhden ainoan kerran ihmiskunnan historiassa hetken häivähdyksen positiivisesta merkityksestä…

 

Share

Mitä yhden virheen hinnalla olisi saanut aikaan?

keskiviikko, 11 tammikuuta, 2012 | Kirjoittaja: Antti Niittyviita

Cadillac SRX on jämäkän näköinen auto. Sitä valmistaa maailman suurin autovalmistaja General Motors. Vuoden 2011 mallin tullessa markkinoille ajoneuvon matkustajaturvallisuus oli ratkaistu ohjelmistolla, jossa kaikkien istuinpaikkojen ilmatyynyistä vastasi yksi järjestelmä.

Markkinoille tulon jälkeen GM:n insinöörit huomasivat kauhukseen hyvin perustavanlaatuisen virheen ilmatyynyjen hallintajärjestelmässä. Mikäli pelkääjän paikalla ei ajon aikana istu ketään, järjestelmä kytkee pois päältä myös takamatkustajien kattokiskossa olevan ilmatyynyn, joka suojaa päätä kuollettavalta iskulta.

Vian löytymisen jälkeen GM joutui kutsumaan Yhdysvalloissa 47,401 ja muualla Pohjois- Amerikassa 3,099 autoa huoltoon ja järjestelmäpäivitykseen. Siis yhteensä 50,500 autoa. Huoltokutsun toimenpiteet eivät takuulla olleet kovin yksinkertaiset.

Jos yhden auton softapäivitysprosessin läpivienti kutsun lähettämisestä huoltoon veisi yhden tunnin valmistajan ja huoltoyritysten työaikaa se kustantaa maltillisella 50 € tuntihinnalla 2,525,000 €. Puhumattakaan imagohaitasta tai asiakkaalle aiheutuneesta mielipahasta.

Lupasin taannoin myydä vain testauksen konkreettisimpia tuloksia – löytämiäni bugeja – hintaan 79 € / kappale. Tuohon hintaan minä olisin sitoutunut metsästämään GM:lle 31,962 bugia.

Share