T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Dokumentissa on kuvattu Keimo-projektin riskienhallintasuunnitelma ja kulloinkin tunnistetut riskit. Dokumenttia päivitetään jokaiseen palautukseen. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi Kirjoittajat Petri Kero pkero@cc.hut.fi Iiro Ojala iaojala@cc.hut.fi Muutokset PVM Tekijä Versio Selitys 18.10.2002 Petri Kero 0.9 Ensimmäinen versio riskienhallinnasta 30.11.2002 Iiro Ojala 0.91 Päivitetty erillinen dokumentti 1.12.2002 Iiro Ojala 0.92 Versio sisäiseen katselmointiin 2.12.2002 Iiro Ojala 0.93 Korjattu kirjoitusvirheitä 2.12.2002 Matti Kannala 1.0 Viimeistely palautukseen 10.2.2003 Iiro Ojala 1.1 Lisätty kappale 4.3 T2-vaiheen palautukseen. 1
Sisällysluettelo 1 Johdanto...3 1.1 Dokumentin tarkoitus... 3 1.2 Yleiset perustelut... 3 2 Käytännön toimenpiteet... 3 2.1 Riskien tunnistaminen... 3 2.2 Riskienhallintapäällikkö... 3 2.3 Viikkopalaverit... 4 2.4 Nopea sähköinen viestintä... 4 2.5 Riskien mittaaminen... 4 2.6 Riskien ennaltaehkäiseminen ja varasuunnitelma... 4 3 Tunnistetut riskit... 5 3.1 Tekniset riskit... 5 3.1.1 Valitun toteutustekniikan sopimattomuus projektiin... 5 3.1.2 Ongelmat CVS-palvelimessa... 5 3.1.3 Ongelmat valittujen työkalujen kanssa... 5 3.1.4 Ongelmat yksittäisten ryhmäläisten koneissa... 6 3.2 Kurssiorganisaatioon liittyvät riskit... 6 3.2.1 Ongelmat kurssin työkalujen kanssa... 6 3.2.2 Viivästykset tarvittavan materiaalin toimituksissa... 6 3.3 Ryhmään liittyvät riskit... 7 3.3.1 Ryhmän jäsen lähtee projektista... 7 3.3.2 Huono henki ja konfliktit ryhmän sisällä... 7 3.3.3 Työmääräarvioiden pettäminen... 7 3.3.4 Töiden epätasainen jakautuminen... 8 3.3.5 Toteuttajien perfektionismi ja väärien asioiden tekeminen... 8 3.4 Asiakkaaseen liittyvät riskit... 9 3.4.1 Asiakas lähtee projektista... 9 3.4.2 Kommunikaatio-ongelmat ja konfliktit asiakkaan kanssa... 9 3.4.3 Asiakkaan vaatimukset muuttuvat... 9 3.5 Yhteenveto riskeistä... 10 4 Riskien seuranta... 10 4.1 PS-vaihe... 10 4.2 T1-vaihe... 10 5 Lähteet...11 2
1 Johdanto 1.1 Dokumentin tarkoitus Tämän dokumentin tarkoitus on pitää kirjaa tunnistetuista riskeistä, esittää toimenpiteet niiden hallitsemiseksi, toteutumisen estämiseksi ja seurausten minimoimiseksi. Dokumentti palvelee jatkuvasti päivitettävänä riskienhallintasuunnitelmana projektin alusta loppuun asti. 1.2 Yleiset perustelut Ohjelmistoprojektit ovat niin monimutkaisia, että ne ovat väistämättä alttiita riskeille. Kustannukset voivat ylittää arviot tai projektit voivat valmistua myöhässä tai keskeytyä kokonaan. Usein uhat voidaan havaita jo paljon ennen niiden kehittymistä todelliseksi vahingoiksi. Siksi onkin tärkeää, että riskit kartoitetaan systemaattisesti ja niiden kehittymistä seurataan järjestelmällisesti koko projektin ajan. Riskien ei saa antaa kehittyä rauhassa, vaan niitä tulee aktiivisesti seurata ja niiden vaikutuksia hallita. 2 Käytännön toimenpiteet 2.1 Riskien tunnistaminen Projektin alettua ryhmä keskusteli vapaasti projektia mahdollisesti uhkaavista riskeistä. Keskustelun ja yleisesti tunnettujen ohjelmistoprojekteja uhkaavien riskien pohjalta laadittiin lista tunnistetuista riskeistä(tämän dokumentin kappale 3). Lista sisältää kuvaukset riskeistä, niiden luokittelun, ehkäisevät toimenpiteet ja korjaavat toimenpiteet riskin mahdollisesti toteutuessa. Listaa päivitetään jatkuvasti. 2.2 Riskienhallintapäällikkö Projektille on nimetty riskienhallintapäällikkö. Tehtävään valittu henkilö vastaa koko projektin riskienhallintaprosessin toiminnasta ja kehittämisestä. Erillisen päällikön nimeäminen ei kuitenkaan vapauta muita ryhmäläisiä velvollisuudesta raportoida havaitsemiaan ongelmia ja toteutumassa olevia riskejä. Riskienhallintaan kuuluu olennaisena osana jatkuva uusien riskien tunnistaminen ja vanhojen uudelleenarviointi. Onkin sanottu, että riskienhallintapäällikön tulee omaksua itselleen pessimistinen suhtautuminen projektiin. Tämä tulee kuitenkin ymmärtää positiivisessa mielessä: Hän kyseenalaistaa rakentavasti tehtyjä päätöksiä ja kiinnittää huomionsa niistä mahdollisesti aiheutuviin riskeihin. Lisäksi riskienhallintapäällikön vastuulla on tämän dokumentin ja tunnistettujen riskien listan ylläpitäminen. 3
2.3 Viikkopalaverit Jokaisessa viikkopalaverissa käydään riskienhallintapäällikön johdolla tunnettujen riskien tilanne lyhyesti läpi. Jatkuva seuranta mahdollistaa riittävän nopean reagoinnin toteutumassa oleviin riskeihin. Jokainen ryhmäläinen on velvollinen raportoimaan havaitsemistaan uhista ja uusista riskeistä riskienhallintapäällikölle. 2.4 Nopea sähköinen viestintä Mikäli jokin ryhmän jäsen havaitsee välittömän uhan riskin toteutumiselle tai erittäin vakavan uuden riskin, tulee hänen raportoida siitä välittömästi muulle ryhmälle esimerkiksi sähköpostitse. Tällaisissa tapauksissa ei missään nimessä tule odottaa seuraavaan viikkopalaveriin asti. 2.5 Riskien mittaaminen Jokaisesta tunnistetusta riskistä arvioidaan erikseen: Riskin toteutumisen todennäköisyys ja Riskin toteutumisen seuraukset projektiin. Näiden kahden tekijän tulona saadaan jokaiselle riskille: Riskin vakavuus. Riskien todennäköisyydettä arvioidaan numeerisesti asteikolla 1-5, jossa 1 tarkoittaa hyvin epätodennäköistä ja 5 erittäin todennäköistä. Riskin toteutumisen seuraukset luokitellaan vastaavasti 1-5, jossa 1 tarkoittaa vähäisiä ongelmia ja 5 koko projektin kannalta kohtalokkaita seurauksia. Riskin vakavuudelle saadaan siis asteikko 1-25. Lieviksi riskeiksi luokitellaan arvot välillä 1-6, vakaviksi 8-15 ja erittäin vakaviksi 16-25. Kun riskit on luokiteltu näin, osataan kohdistaa suurin huomio kaikkein vakavimpiin riskeihin. Silti vähäisen vaikutuksen riskejäkään laiminlyödä. 2.6 Riskien ennaltaehkäiseminen ja varasuunnitelma Jokaista tunnistettua riskiä varten laaditaan lyhyt menetelmä sen toteutumisen ennaltaehkäisemiseksi ja valmis varasuunnitelma sen toteutumisen varalta. Ehkäisymenetelmän ja varasuunnitelman voi kirjoittaa riskin tunnistanut henkilö itse, riskienhallintapäällikkö tai ryhmä yhdessä. Riskienhallintapäällikön on kuitenkin hankittava koko ryhmän hyväksyntä listaan kirjatuille ehkäisymenetelmille ja varasuunnitelmille viikkopalaverin riskienseurantaosion yhteydessä. 4
3 Tunnistetut riskit 3.1 Tekniset riskit 3.1.1 Valitun toteutustekniikan sopimattomuus projektiin Todennäköisyys 1. Sovellusarkkitehtuuri on suunniteltu huolella ja toteutettu tunnettujen standardien, kuten OpenGL:n ja Javan varaan. Ryhmäläisillä on aikaisempaa kokemusta käytetyistä tekniikoista. 4. Arkkitehtuurin muuttaminen jälkikäteen on työlästä ja aikaa vievää. Tarvittaessa se pystytään tekemään, mutta silloin jostain muusta on tingittävä. Vakavuus 4 Ennaltaehkäisy Arkkitehtuurin huolellinen suunnittelu ja hyväksi havaittujen tekniikoiden käyttö. Varasuunnitelma Arkkitehtuurin dramaattinen muuttaminen ja keskeisten osien uudelleen suunnittelu sekä toteuttaminen. Riski 1 Toteutustekniikan sopimattomuus projektiin 3.1.2 Ongelmat CVS-palvelimessa Todennäköisyys Vakavuus 9 Ennaltaehkäisy Varasuunnitelma Riski 2 Ongelmat CVS-palvelimessa 3. Lyhyet ja keskipitkät verkkokatkot ovat yleisiä. Pidemmän keskeytyksen työhön aiheuttavat viat sen sijaan erittäin harvinaisia. 3. Kriittisenä hetkenä pettävä palvelin voi pysäyttää kehityksen. Dokumenttikannan tuhoutuessa kokonaan se jouduttaisiin palauttamaan varmuuskopioista, jolloin osa työstä menetettäisiin pystyvästi. Lähdekoodien ja dokumenttien hajauttaminen palvelimen lisäksi ryhmäläisten lokaaleille levyille. Palvelimesta ylläpidon toimesta otettavat varmuuskopiot. Palvelimen verkkokatkon aikana dokumenttien jakaminen ryhmäläisten kesken muilla keinoilla, esim. sähköpostilla tai levykkeillä. Tarvittaessa kannan palauttaminen varmuuskopioista. 3.1.3 Ongelmat valittujen työkalujen kanssa Todennäköisyys 2. Ryhmäläisillä on kokemusta varsin laajasta työkaluvalikoimasta. Joitakin uusia ja tuntemattomia järjestelmiä joudutaan silti ottamaan käyttöön. 3. Ongelman työkalujen kanssa voivat hidastaa työntekoa huomattavasti. Huonot työkalut myös tunnetusti syövät 5
motivaatiota. Vakavuus 6 Ennaltaehkäisy Käytetään mahdollisimman paljon ryhmälle ennestään tuttuja työkaluja. Varasuunnitelma Tarvittaessa vaihdetaan työkalua. Jos vaihto ei ole mahdollista, yksi ryhmäläinen selvittää ongelman ja opettaa ratkaisun muille. Riski 3 Ongelmat valittujen työkalujen kanssa 3.1.4 Ongelmat yksittäisten ryhmäläisten koneissa Todennäköisyys 2. Laitteistoviat ovat harvinaisia, mutta aina mahdollisia. Tietoliikenneongelmat ovat hyvinkin todennäköisiä 2. Osa töistä saattaa viivästyä tai jäädä kokonaan tekemättä. Vakavuus 4 Ennaltaehkäisy Dokumenttien varmuuskopioiminen ja niiden väliversioidenkin säilyttäminen CVS-järjestelmässä. Varasuunnitelma Koulun tai muun toimittajan laitteiden käyttö korjauksen vievän ajan. Dokumenttien palauttaminen varmuuskopioista. Riski 4 Ongelmat yksittäisten ryhmäläisten koneissa 3.2 Kurssiorganisaatioon liittyvät riskit 3.2.1 Ongelmat kurssin työkalujen kanssa Todennäköisyys 4. Kurssin tarjoamat työkalut ovat www-pohjaisia ja alttiita verkkokatkoille. Työkaluja ei myöskään ole laajassa mitassa ennen käytetty. 2. Pakolliset raportoinnit viivästyvät. Virheidenseuranta vaikeutuu. Ylimääräistä työtä. Vakavuus 8 Ennaltaehkäisy Lähes ryhmästä riippumatonta. Havaittujen ongelmien nopea raportoiminen. Varasuunnitelma Omien työkalujen tilapäinen käyttö tunti- ja virhekirjaukseen. Kirjausten siirto kurssinjärjestelmään sen taas toimiessa. Riski 5 Ongelmat kurssin työkalujen kanssa 3.2.2 Viivästykset tarvittavan materiaalin toimituksissa Todennäköisyys 3. Ei ole mitenkään ennenkuulumatonta, että kurssien materiaalit myöhästyvät tai jäävät toimittamatta opiskelijoille kokonaan. 2. Vaaditut tehtävät viivästyvät tai niiden tekeminen estyy kokonaan. Vakavuus 6 Ennaltaehkäisy Lähes ryhmästä riippumatonta. Havaittujen ongelmien nopea raportoiminen. 6
Varasuunnitelma Korvaavan materiaalin etsiminen tai sellaisen tekeminen itse. Riski 6 Viivästyksen tarvittavan materiaalin toimituksissa 3.3 Ryhmään liittyvät riskit 3.3.1 Ryhmän jäsen lähtee projektista Todennäköisyys 1. Kaikki ryhmäläiset ovat erittäin motivoituneita saattamaan projektin menestyksekkäästi loppuun. 4. Seitsemän hengen ryhmässä jo yhden hengen väheneminen tuo suuren loven resursseihin. Lisäksi tämä todennäköisesti laskisi jäljellejääneiden motivaatiota. Vakavuus 4 Ennaltaehkäisy Kaikkien ryhmän jäsenten motivaation ylläpito antamalla kaikille mielenkiintoisia ja vaihtelevia tehtäviä, jakamalla työt tasaisesti ja ylläpitämällä hyvää henkeä ryhmän sisällä. Varasuunnitelma Uusia jäseniä ryhmään ei voida kesken kurssin hankkia. Ryhmästä lähteneen työt on jaettava tasaisesti ja arvioitava koko projektin puitteissa mistä osa-alueista tarvittaessa tingitään. Riski 7 Ryhmän jäsen lähtee projektista 3.3.2 Huono henki ja konfliktit ryhmän sisällä Todennäköisyys 2. Pieniä konflikteja tulee tämänkokoisessa projektissa syntymään hyvin todennäköisesti. Riitojen paisuminen ongelmaksi asti sen sijaan on melko epätodennäköistä. 3. Myrkyttynyt ilmapiiri syö työmotivaatiota ja vaikeuttaa yhteistoimintaa. Voi johtaa myös muihin ongelmiin, kuten ryhmäläisen lähtemiseen projektista. Vakavuus 6 Ennaltaehkäisy Motivaation ylläpito, rehelliset keskustelut ja orastavien konfliktien ratkominen ennen niiden paisumista. Varasuunnitelma Ongelmien selvittäminen keskustelemalla ja mahdollisten epäkohtien oikaiseminen. Saattaa tarvita konfliktin ulkopuolisen auktoriteetin, kuten projektipäällikön tiukkaa puuttumista asiaan. Riski 8 Konfliktit ryhmän sisällä 3.3.3 Työmääräarvioiden pettäminen Todennäköisyys 3. Vaikka ryhmäläisillä on aikaisempaa kokemusta ohjelmistokehityksestä, ei kukaan ole toiminut täysin vastaavassa tiukasti aikataulutetussa projektissa. Työmäärien arviointi uudessa projektissa on aina vaikeaa. Suoritettavat tehtävät eivät ole aina kovin yksityiskohtaisesti kuvattuja. 4. Työmääräarvioiden pettäminen voi aiheuttaa kohtuutonta 7
Vakavuus 12 Ennaltaehkäisy Varasuunnitelma Riski 9 Työmääräarvioiden pettäminen viivästystä projektin etenemisessä. Koska projektilla on tiukat kalenteriaikaan sidotut deadlinet, ei aina ole mahdollista käyttää lisää työpanoksia keskeneräisiin töihin. Työmäärien huolellinen arviointi. Arvioiden päivittäminen työn kuluessa. Töiden tekeminen ajoissa ennen deadlinea, jolloin suunnittelemattoman työn tekemiseenkin vielä on mahdollisuuksia. Huonosti määriteltyjen tehtävien tarkentaminen projektin edetessä. Arviot reilusti ylittävien tehtävien prioriteetin uudelleen arviointi ja tarvittaessa lykkääminen tai keskeyttäminen. Ajan ja resurssien salliessa lisätyön tekeminen. 3.3.4 Töiden epätasainen jakautuminen Todennäköisyys 3. Joku laiminlyö tehtäviään ja ne kaatuvat muiden niskaan. Kaikkia suhteellisen suuriakaan tehtäviä ei ole mahdollista järkevästi jakaa usealle henkilölle. Myös työmääräarvioiden pettäminen voi johtaa tämän riskin toteutumiseen. 3. Töitä jää tekemättä tai kaikille tekijöille ei riitä suunniteltuja tehtäviä. Ylikuormitettujen motivaatio voi kärsiä. Vakavuus 9 Ennaltaehkäisy Töiden tasainen jakaminen ja työmäärien seuranta. Sovittujen tehtävien tekeminen ja tarvittaessa sen kontrollointi. Varasuunnitelma Tasoittava töiden jako seuraavissa vaiheissa. Arvioiden tarkentaminen. Riski 10 Töiden epätasainen jakautuminen 3.3.5 Toteuttajien perfektionismi ja väärien asioiden tekeminen Todennäköisyys Vakavuus 9 Ennaltaehkäisy Varasuunnitelma Riski 11 Toteuttajien perfektionismi 3. Ohjelmoijat usein toteuttavat suunnittelemattomia ominaisuuksia, jotka ovat ohjelmoijien mielestä hienoja tai muuten vaan kivoja. 3. Rajoitetun ajan haaskaaminen matalan prioriteetin tai jopa täysin turhiin ominaisuuksiin saattaa estää tärkeiden ominaisuuksien valmistumisen ajallaan. Vaatimukset ja suunnitelmat laaditaan tarpeeksi yksityiskohtaisiksi. Tehtyä työtä seurataan ja lopputuloksia verrataan suunnitelmiin. Huomattaessa toteutettavan vääriä ominaisuuksia, lopetetaan näiden tekeminen heti. 8
3.4 Asiakkaaseen liittyvät riskit 3.4.1 Asiakas lähtee projektista Todennäköisyys 1. Asiakkaalla on luonnollinen motivaatio projektin loppuun saattamiseen. 5. Asiakkaan lopettaminen olisi kohtalokasta projektille ja se todennäköisesti päättyisi tähän. Vakavuus 5 Ennaltaehkäisy Asiakkaan tavoitteiden mukainen toiminta. Varasuunnitelma Ainut mahdollisuus on kysyä kurssihenkilökunnalta korvaava asiakasta samalle aiheelle. Riski 12 Asiakas lähtee projektista 3.4.2 Kommunikaatio-ongelmat ja konfliktit asiakkaan kanssa Todennäköisyys 2. Ryhmä ja asiakas ovat sitoutuneet yhteisiin tavoitteisiin. 3. Jos asiakkaalla ja ryhmällä ei ole yhteistä näkemystä projektin suunnasta, ei lopputulos todennäköisesti tyydytä kumpaakaan. Vakavuus 6 Ennaltaehkäisy Ryhmä tiedottaa aktiivisesti tekemisistään asiakkaalle. Myös asiakasta rohkaistaan ottamaan yhteyttä ryhmään, jos jokin asia on jäänyt epäselväksi. Varasuunnitelma Ensisijaisesti ryhmän tulee tarkastella omia toiminta- ja yhteydenpitotapojaan. Jos niissä huomataan ongelmia, tulee uusista menettelytavoista sopia yhdessä asiakkaan kanssa. Riski 13 Konfliktit asiakkaan kanssa 3.4.3 Asiakkaan vaatimukset muuttuvat Todennäköisyys Vakavuus 9 Ennaltaehkäisy Varasuunnitelma Riski 14 Asiakkaan vaatimukset muuttuvat 3. Asiakas on esittänyt alustavat vaatimukset projektille. Pienien muutosten tuleminen on vielä melko todennäköistä, suurien linjojen muuttuminen taas epätodennäköistä. 3. Tärkeiden vaatimusten muuttuminen voi aiheuttaa huomattavaa lisätyötä tai jo tehty työ voi osoittautua turhaksi. Pienemmät muutokset eivät tuo suuria ongelmia. Ryhmä kommunikoi aktiivisesti asiakkaan kanssa. Ryhmällä on selkeästi määritelty vaatimustenhallintaprosessi, jonka mukaisesti kaikki uudet tai muuttuneet vaatimukset käsitellään. Tarvittaessa ohjelmistoa uudistetaan asiakkaan vaatimusten mukaisesti ja samalla sovitaan mitä ominaisuuksia lisääntyneen työn kompensoimiseksi jätetään pois. 9
3.5 Yhteenveto riskeistä Projektilla ei ole yhtään tunnistettua erittäin vakavaa riskiä. Vakavaksi luokiteltuja on useampia, niistä korkeimmat pisteet saaneena työmäärien virheellinen arviointi. Seuraavina tulevat toteuttajien perfektionismi, töiden epätasainen jakautuminen, versionhallinnan pettäminen, asiakkaan vaatimusten muuttuminen ja ongelmat kurssin tarjoamien työkalujen kanssa. 4 Riskien seuranta 4.1 PS-vaihe Suunnitteluvaiheessa riskienhallintaa ei vielä varsinaisesti implementoitu. Riskienhallintaprosessi oli vielä muiden prosessien tavoin vasta kehittymässä käyttökelpoiseen muotoon. Tärkein sovellus oli alustavan riskilistan luominen. 4.2 T1-vaihe Ensimmäisessä toteutusvaiheessa riskienhallinta pyörähti todenteolla käyntiin. Uusia riskejä tunnistettiin reilusti lisää, joitakin vanhoja poistettiin ja yhden riskin todettiin toteutuneen ja ennalta laadittu varasuunnitelma otettiin käyttöön. Kyseessä oli kurssin toimittaman sopimuspohjan viivästyminen ja sittemmin jääminen kokonaan toimittamatta. Varasuunnitelman mukaisesti projektipäällikkö hankki omista lähteistään korvaavan sopimuksen kiitettävän nopeasti. Huomattavaa vahinkoa projektille ei päässyt syntymään. 4.3 T2-vaihe Toisen toteutusvaiheen aikana vietettiin pitkä joululoma. Se katkaisi täydelliseti työnteon lisäksi myös riskienhallinnan ja seurannan. Loman jälkeen tunnistettujen riskien lista käytiin koko ryhmän voimalla läpi ja siihen tehtiin pieniä tarkennuksia. Päälinjoiltaan sen todettiin olevan ajanmukainen. Ryhmäpalaverit ja niissä tapahtuva säännöllinen riskienseuranta ovat projektin tärkeimmät riskienhallintatyökalut. Palavereja pidettiin T2-vaiheessa hieman aikaisempaa vähemmän, mistä johtuen riskienseuranta jäi normaalia enemmän vain riskienhallintapäällikön työksi. Tästä huolimatta riskienhallinta onnistui vaiheessa erinomaisesti: Yksikään riski ei varsinaisesti päässyt toteutumaan, vaan niiden kehittyminen huomattiin ajoissa ja ne voitiin onnistuneesti ennaltaehkäistä. Päälimmäisenä huolenaiheena oli työmääräarvioiden pettäminen (Riski 9). Vaiheen tehtävät olivat niin laajasti määriteltyjä, ettei niiden vaatimaa työtä osattu kunnolla arvioida etukäteen. Arvioiden tarkentamisen lisäksi yksittäisiä tehtävänkuvauksia päivitettiin vaiheen kuluessa ja joitakin asioita päätettiin siirtää seuraavaan vaiheeseen. 10
Tärkein tietoisesti siirretty tehtävä oli The Keimo programmer s guiden -kirjoittaminen. Kaikkea oppaan kirjoittamiseen tarvittavaa teknistä- ja ohjelmakoodin dokumentaatiota ei vielä ollut olemassa, eikä opasta tosiasiassa tarvita ennen mahdollisten ulkopuolisten kehittäjien tulemista projektiin. Näistä syistä katsoimme tärkeämmäksi mm. saattaa käyttäjäohjeen julkaisukelpoiseen kuntoon ja totesimme ettei projekti kärsi ohjelmointioppaan ensimmäisen version viivästymisestä. 5 Lähteet [1] Steve McConnell, Software Project Survival Guide, Microsoft Press, 1998 [2] Sommerville, I., Software Engineering, 6th Edition, Addison-Wesley, 2001 [3] Haikala, I. ja Märijärvi, J., Ohjelmistotuotanto, 5. painos, Suomen ATK- Kustannus Oy, 1998 11