KOKA2008

Parannusehdotukset – KOKA2008

Testausvaihe Testausvaiheeseen tulisi kiinnittää enemmän huomiota. Tes-taushenkilöt tulisi saada sitoutettua jollain tavalla testaamiseen.

Ohjausryhmän tuki Ohjausryhmän toiminta ei ollut projektiryhmän mielestä tukea antavaa. Ohjausryhmältä toivotaan enemmän liiketoimin-tanäkökulman tuomista hankintaan. Teknisten yksityiskohtien tarkasteleminen olisi hyvä jättää pois ohjausryhmän kokouksis-ta, jollei projektiryhmä tuo asiaa esille.

Dokumentaatio KOKA2008-alustan käyttöohjeistus on käytännössä TEPA-dokumentaatio. TEPA-dokumentaation muokkaaminen esimer-kiksi www-pohjaiseksi voisi helpottaa sen ymmärtämistä. Pro-jektipäälliköitä vaaditaan usein osallistumaan käyttöönottopro-jekteihin.

Taulukko 5: KOKA2008 parannusehdotukset.

KOKA2008 oli iso hankinta, joka muutti Tiehallinnon sovelluksille tarjottavan perus-palvelun luonnetta tarjoamalla yhden yhtenäisen palvelualustan (taulukko 5). Hankin-taa edelsi TEPA-projekti, jossa suunniteltiin testipalvelualusta ja prosessi uuden järjes-telmä tai päivityksen käyttöönotosta. TEPA:n rooli KOKA2008 -projektille oli suuri, koska se toimi käytännössä esiselvityksenä ja vaatimusmäärittelynä sille. KOKA -projekti ei siis joutunut tekemään vaatimusmäärittelyä.

TEPA tehtiin yhteistyössä toimittajan kanssa, jolloin siitä saatiin yhteistyön avulla karsittua mahdollisia ongelmia pois. Tämä osoittaa hyvin kuinka suuri merkitys hyväl-lä esiselvitykselhyväl-lä ja vaatimusmäärittelylhyväl-lä on.

KOKA2008-projektin osalta testaajien osuutta olisi pitänyt selvittää tarkemmin. Pro-jekti jäi kuitenkin ilman ylempien organisaatioelinten tukea siinä vaiheessa, kun tarvit-tiin apua saada järjestelmävastaavat mukaan testaukseen. KOKA2008-projektin alku-vaiheessa projektiryhmä piti useita tiedotustilaisuuksia järjestelmävastaaville, mutta he eivät saaneet järjestelmävastaavia sitoutumaan tarpeeksi testausvaiheeseen.

Toisaalta ne ongelmat, jotka testausvaiheessa tulivat esille, olivat pääsääntöisesti niin teknisiä, ettei Tiehallinnon järjestelmävastaavilla olisi ollut kykyjä ratkaista näitä on-gelmia. Tietojärjestelmien suunnittelijoita ja toteuttajia olisi tarvittu mukaan projektin testausvaiheeseen. Ymmärrettävää on se, että tästä olisi aiheutunut lisäkustannuksia, koska jo toimitetun tietojärjestelmän suunnittelijat eivät todennäköisesti olisi lähteneet mukaan testausvaiheeseen ilman erillistä toimeksiantoa.

Hankinta oli siinä mielessä onnekas, että se voitiin toteuttaa juuri niillä henkilöresurs-seilla, jotka siihen haluttiin. Tämä koskee kuitenkin ainoastaan vain toteutusvaihetta.

Testivaiheessa projektilta puuttui tarvittavat testausresurssit. Sommervillen mukaan projektiryhmän tulisi koostua henkilöistä, joilla on edellytyksiä suorittaa tehtävä hyvin.

Hän korostaa myös ryhmän toimivuutta henkilökemian näkökulmasta. (Sommerville, 2001: 490,497.)

Ryhmän toimivuuden näkökulmasta KOKA2008:n projektiryhmä toimi hyvin. Henki-löt olivat suurimmaksi tuttuja aiemmista projekteista ja toimintatavat olivat suurin piir-tein tiedossa. Tiehallinnon puolelta testaus oli vastuutettu osittain harjoittelijalle. Tes-taamisen kannalta oikea henkilö testaamiseen on tietojärjestelmän asiantuntija, tai op-timaalisessa tilanteessa tietojärjestelmän kehittäjä. (Pressman, 2005: 387.)

Tietojärjestelmien testitapauskuvaukset olivat joko huonolla tasolla, tai niitä ei ollut tehty. Tietojärjestelmädokumentaation tärkeys korostui testausvaiheessa.

Tiehallinnon projektiohjeistus ohjeistaa tietojärjestelmäprojektin luomaan muun muas-sa joukon erilaisia ohjeistuksia. Haastatteluismuas-sa tuli esille, että usein näitä kaikkia do-kumentteja ei tehdä tai niitä ei pidetä ajan tasalla mahdollisten tietojärjestelmämuutos-ten jälkeen. Pressmanin mukaan dokumentaation, erityisesti testausdokumentaation, virheellisyys aiheuttaa turhia ongelmia, koska ei voida olla varmoja tietojärjestelmän toimivuudesta. (Pressman, 2005: 454.) Dokumentit tulisi tehdä kunnolla tietojärjestel-mäprojektin aikana, koska niiden tuottaminen jälkeenpäin tuntuu usein turhauttavalta ja aikaa vievältä.

Dokumenttien ajatellaan olevan turhia koska tietojärjestelmät toimivat ilman niitäkin kunnes tietojärjestelmä ei toimikaan. (Pressman, 2005: 876.) Pfleegerin mukaan tes-taussuunnitelma tulisi tehdä aina riippumatta tietojärjestelmän koosta. Testaussuunni-telman merkitys kasvaa mitä isommasta tietojärjestelmästä on kyse. (Pfleeger, 2001:

417-428.) Testaussuunnitelma, joka jätettiin tekemättä, olisi saattanut kartoittaa pa-remmin mahdolliset ongelmakohdat.

Haastatteluissa, myös muissa kuin KOKA2008:n haastatteluissa, esiintyi epätietoisuut-ta Tiehallinnon toivomisepätietoisuut-ta dokumenteisepätietoisuut-ta. Osa dokumenteisepätietoisuut-ta koettiin hyvin tärkeiksi tietojärjestelmien kannalta. Tärkeydestä huolimatta dokumentteja varjosti epätietoisuus sisällöstä.

Monitoimittajaympäristössä yhden toimittajan, yleensä kilpailutuksen voittajan, on hyvin vaikea, jollei jopa mahdotonta työstää dokumentti yksin. Tietojärjestelmät ovat kytköksissä eri tietolähteisiin ja tietojärjestelmiin, niin myös dokumentit. Tiehallinnos-sa (nykyisin Liikennevirasto), tulisi helpottaa dokumenttien syntymistä tekemällä esi-merkkidokumentaatio esimerkki tietojärjestelmästä. Toimittajat kokivat, että esimerk-kidokumentaatio selventäisi dokumenttien sisältöä. Esimerkesimerk-kidokumentaatioita voi olla useampikin, esimerkiksi jos kohdealueet eroavat toisistaan huomattavasti.

Esimerkkidokumentaatio ei kuitenkaan ole ainoa ratkaisu epäselvyyteen dokumenttien kanssa, mutta kunnollisena esimerkkinä se helpottaisi toimittajia ymmärtämään mitä Liikennevirastossa halutaan dokumentin sisältävän. Tällä hetkellä dokumentaatiosta on tarjolla ainoastaan otsikkorunko, jonka voi toimittajien mukaan ymmärtää hyvin eri tavalla.

KOKA2008-projektin olisi pitänyt saada tietojärjestelmien kehittäjät mukaan testaus-vaiheeseen, mutta tämä ei kuitenkaan onnistunut. Projektiryhmän näkökulmasta on-gelmaa olisi helpottanut suurempi tuki ohjausryhmän suunnalta. Ohjausryhmän tulisi toimia enemmän auttavana ryhmänä projektille.

Monitoimittajaympäristössä toimiessaan järjestelmädokumentaatio tulisi työstää yh-teistyössä eri osapuolien kanssa. Vastuu dokumentin syntymisestä riippuu kilpailutuk-sen voittaneen toimittajan ja kilpailuttajan välisestä sopimuksesta. Vastuulliselle tahol-le tulisi antaa enemmän tukea dokumenttien luomiseen. Yhteistyön merkitys korostuu dokumentoinnissa. Eri osapuolet eivät välttämättä ole helposti tavoitettavissa maantie-teellisten sijaintien takia, joten tapaaminen saman pöydän ääressä ei ole aina mahdol-lista. KOKA2008-projektissa yhteinen työryhmätila olisi voinut helpottaa dokumentti-en muodostumista ja hallintaa. Toimittajan projektipäällikkö epäili ryhmätyötilan toi-mivuutta. Kyse tuntui kuitenkin olevan epäilyksestä saataisiinko ryhmätyötilasta tar-peeksi helppo sen käyttäjille, jotta se toimisi. Tiehallinnon puolella ajatus otettiin pa-remmin vastaan.

KOKA2008-ohjeistus, joka käytännössä on TEPA-dokumentaatio, on hyvin laaja ko-konaisuus, jonka sisäistäminen on koettu ongelmalliseksi. Yhtenä vaihtoehtona tähän ongelmallisuuden ratkaisemiseksi on muuttaa dokumentaation esitystapa. Tällä hetkel-lä dokumentaatio on periaatteessa kasa tekstidokumentteja. Sen sijaan, että ne olisivat perinteisessä dokumenttimuodossa, niiden muuttamista www-pohjaiseen esitystapaan tulisi miettiä. Www-pohjainen dokumentaatio olisi myös oltava helposti jaettavissa talon ulkopuolelle, jolloin toimittajat saisivat materiaalin käsiinsä.

Nykyisin toimittajalle toimitetaan useita dokumentteja, eikä toimittaja aina tiedä mihin kaikkia näitä dokumentteja tulisi käyttää ja ovatko ne edes tarpeellisia. Ryhmätyötila voisi toimia ohjesivustona, jonka pystyisi tarjoamaan myös toimittajalle.