Seminaari Projektin hallinta Arviointi Lasse Nordlund Helsinki 10.10.2000 Helsingin yliopisto Tietojenkäsittelytieteen laitos Hyväksymispäivä: Arvostelija: Arvosana:
Sisällys 1 Johdanto... 1 2 Kustannusarviointi ja riskinhallinta... 1 2.1 Riski ja kustannus... 1 2.2 Riskien luokittelu kustannustekijöiden luokkiin... 2 2.2.1 Aikatauluriskit... 3 2.2.2 Tuoteriski... 3 2.2.3 Alustariskit... 3 2.2.4 Henkilökuntariskit... 3 2.2.5 Prosessiriskit... 4 2.2.6 Uudelleenkäyttöriskit... 4 2.2.7 Kustannusarviointiriskit... 4 3 Kustannusmallit... 5 3.1 Tausta... 5 3.2 COCOMO... 6 3.3 COCOMO -malliin perustuvia sovelluksia... 6 3.3.1 USC-COCOMOII... 7 3.3.2 Construx Estimate... 9 4 Yhteenveto... 11 Lähteet... 12 I
1 Johdanto Laadukas ohjelmistotuotannon riskinhallinta tarvitsee ihmisen harkintaa. Riskinhallintaa on vaikea toteuttaa, koska sen taitavia ammattilaisia on vähän ja projektit ovat aina yksilöllisiä. Esimerkiksi kokemattomalla projektipäälliköllä voi olla aavistus, että projekti on riskialtis, mutta hän ei tiedä, mitkä riskit ovat ja miten tunnistaa ne. Kustannusarvion tekeminen eroaa riskianalyysin teosta. Kustannusarvion teossa löytyneiden kustannustekijöiden avulla voidaan tunnistaa ja havaita helpommin projektin riskejä. Automaattinen riskinhallintatyökalu auttaa tunnistamaan, järjestämään ja kokoamaan riskit. Seminaariesityksen kirjallisessa osassa pitäydytään enemmän aiheen teoriapuolella ja esimerkkiohjelmat esitellään vain yleisesti. Suullisessa esityksessä käydään tarkemmin läpi ohjelmien ominaisuuksia ja toiminnallisuuksia. 2 Kustannusarviointi ja riskinhallinta Kustannusmalleja käytetään usein projektisuunnittelussa ja -arvioinnissa ennustamaan niin henkilötyötunteja kuin ajankäyttöä projekteissa. COCOMO (Constructive Cost Model) [BOE81] on yksi tällainen laajasti käytetty kustannuslaskentamalli. 2.1 Riski ja kustannus Riski tarkoittaa epätoivotun tuloksen tai jonkin menetyksen mahdollisuutta. Riskinhallinnan tarkoitus on tunnistaa, osoittaa ja poistaa ohjelmistotuotantoriski ennen kuin se uhkaa menestyvää ohjelmistoprojektia tai johtaa uudelleen suunnitteluun. Riskinhallintaan kuuluu siis riskinarviointi ja -hallinta. Sitä on myös tarkoitus tehdä koko projektin elinkaaren ajan. Riskinhallinnalla koitetaan tasapainottaa kustannus-aikataulu-tehokkuus (kuva 1) -kolmikkoa. [BOE89, CHA89] Jokainen näistä muodostaa oman riskikategoriansa, joista aikataulu on tärkein tekijä. 1
Aikataulu Kustannukset Tehokkuus Kuva 1 Kustannus-aikataulu-tehokkuuss -kolmikko Kustannusarviointi ja riskinhallinta liittyvät vahvasti toisiinsa: - Kustannusarviota käytetään riskinarvioimiseen ja riskivaihtoehtojen valitsemiseen. - Riskisimulaatioita voidaan soveltaa kustannusmalleihin. - Kustannusarvioiden toteuttaminen riippuu riskinhallinnasta. Riskitilanne voidaan kuvata yhdistelmänä, missä erityisen korkea kustannustekijä osoittaa kasvavaa työmäärää ja samalla lisää mahdollisia ongelmatekijöitä. Esimerkiksi projekti, jossa on tiukka aikataulu ja työtekijöiden ohjelmistotuntemus on heikko. Yllä olevan voi muokata muotoon: [MAD97] IF ((tarvittava kehitysaikataulu < sopiva) AND (ohjelmistotuntemus < sopiva) THEN Projektiriski 2.2 Riskien luokittelu kustannustekijöiden luokkiin Riskit on luokiteltu COCOMO:n mukaisiin kustannustekijöiden luokkiin. Ne jakautuivat riskityypin mukaan eri kategorioihin. [MAD97] 2
2.2.1 Aikatauluriskit Kaikista kustannustekijöistä aikataululla on eniten riskitekijöitä. Ongelmien todennäköisyys kasvaa nopeasti, kun ollaan valmistamassa tuotetta liian tiukassa aikataulussa. Kaikki tekijät, esimerkiksi vaikea tuote tai työntekijäpula, vaikuttavat suoraan aikatauluun ja näin ollen ne lasketaan osatekijöiksi aikatauluriskeihin. 2.2.2 Tuoteriski Korkealaatuisen tai monimutkaisen tuotteen tekeminen on aina hankalaa. Tällainen vaatii aina korkeatasoista henkilökuntaa, jota on vaikea saada. Kun osaamista ei ole, se johtaa todennäköisesti kustannusten ja aikataulun ylitykseen. Aikataulun joustavuudella voidaan vaikuttaa tavoitteiden saavuttamiseen. 2.2.3 Alustariskit Epävakaa kehitysalusta on aina riski. Alustan päivittämisestä voi aiheutua virheitä jo valmistuneisiin osiin kesken projektin. Pahimmassa tapauksessa joudutaan puuttumaan tuotteen suunnitteluun uudelleen. COCOMO81 -kehittämisen jälkeen tekniikan kehitys on poistanut suurimman osan alustaongelmista. Muisti on tullut halvemmaksi ja tietokoneet huomattavasti nopeammiksi, joten ohjelmankoko ja aikavaatimukset eivät ole enää niin suuri ongelma kuin aikaisemmin. 2.2.4 Henkilökuntariskit Henkilökunnalla on suurin vaikutus tehokkuuteen, joten se on yksi kolmesta pääriskitekijästä. Perussääntönä voidaan pitää, että valitaan oikea ihminen oikeaan paikkaan, kuitenkin niin, että ihmistenväliset sosiaaliset suhteet otetaan huomioon. Luonnollisesti liian tiukka aikataulu vaikuttaa myös henkilökunnan tehokkuuteen ja ilmapiiriin. 3
2.2.5 Prosessiriskit Työkalujen käytöllä ja työskentelytyylillä on aina vaikutus projektin tavoitteiden toteutumisessa. Riski kasvaa, jos työkalut ovat riittämättömät. Samoin jos kehitystä tehdään useissa paikoissa, jolloin kommunikointi vaikeutuu. Jos prosessia ei ole määritelty kunnolla, johtaa tämä lähes poikkeuksetta aikataulun ja kustannusten ylityksiin. 2.2.6 Uudelleenkäyttöriskit Uudelleenkäytettävän osan on oltava hyvin suunniteltu, jotta se sopisi käytettäväksi sellaisenaan. Samoin siihen liittyvän dokumentaation on oltava yksityiskohtainen, jotta uudelleenkäytettävän osan implementointi käy vaivatta. 2.2.7 Kustannusarviointiriskit Epäjohdonmukaiset arviointikohdat täytyy tarkistaa. Huolimattomasti tehty arvio projektin alussa voi aiheuttaa turhia riskejä projektissa, pahimmassa tapauksessa se voi johtaa jopa kannattavan projektin hylkäämiseen. 4
3 Kustannusmallit Yksi suurimmista vaikeuksista ohjelmistokehitysprojektien kustannusarvioinnin ja aikataulun hallinnassa on ollut hyvän ja tarkan kustannusmallin kehittäminen. 3.1 Tausta Vuonna 1995 pelkästään yhdysvalloissa käytettiin erilaisiin ohjelmistoihin yrityksissä ja virastoissa noin 225 miljardia dollari, kun sama luku vuonna 1985 oli noin 70 miljardia dollaria. [QIP98, BOE87] Kasvavat ohjelmistokulut asettavat haasteen ohjelmistotuotantoalalle. Sen pitäisi jatkuvasti kehittää tekniikkaa, mutta samalla tehdä ohjelmistoista tehokkaampia. Projektinhallinnan avulla voidaan vastata näihin haasteisiin. Tähän mennessä etenemistä on tapahtunut hieman sekalaisin tuloksin. Toisaalta integroidut CASE työkalut, neljännen tason ohjelmointikielet ja olioohjelmointi ovat pysyvästi muuttaneet ohjelmistojärjestelmien kehitystapaa, mutta ohjelmistokehitysprojektien hallinta ylemmältä tasolta riittävällä tarkkuudella on vielä kaukana siitä, mihin pitäisi päästä. Yhä jotkin jo 60-luvulla havaitut merkittävät ohjelmistotuotantoprojektin hallintaongelmat (aikataulu, kustannukset, ym.) ovat ratkaisematta ja nykyään ne ovat entistä hankalampia, johtuen projektien kasvaneista koista ja monimutkaisuuksista. Näistä pahimmat ongelmat ovat kustannusten ylitykset ja aikataulun venymiset. Vuonna 1984 tehty amerikkalainen tutkimus osoitti, että keskiarvolta 67% prosenttia ohjelmistotuotanto projekteista ylittää kustannuksensa ja 22% ei valmistu aikataulussa. [JNW84] Tämä on luultavasti vain jäävuorenhuippu, koska ammattilaisten arvio [QIP98] nykyään on, että isot ohjelmistotuotantoprojektit ylittävät kustannuksensa yleisesti jopa 200-300 prosenttisesti ja aikataulu venyy usein kaksinkertaiseksi. Suurimpana syynä näihin ongelmiin pidetään heikkoa kustannusarviointia ja epätarkkaa aikataulun suunnittelua. Nämä johtavat epärealistisiin odotuksiin projektista ja heijastuu näin projektisuunnitteluun. Tämän tuloksena ohjelmistoprojektinhallinnan tutkimus on keskittynyt kustannusmallien luomiseen. 5
Vaikka mallit paranivat huomattavasti ja arvioiden tarkkuus parani, pysyivät ne silti vielä epätarkkoina. Viime aikainen tutkimus [JOR95] osoitti, että suhteellinen virheiden määrä vaihteli 60:stä 280:een prosenttiin kaikilla yleisillä malleilla (COCOMO, SLIM, ESTIMATICS ja Function Points) 3.2 COCOMO Vuonna 1981 kehitetty COCOMO (Constructive Cost Model) [BOE81] on yleisesti hyväksytty ja perusteellisesti dokumentoitu ohjelmistotuotantokustannusmalli, jonka Barry Boehm kehitti. COCOMO81 on monitasoinen malli, joka tarjoaa kaavoja työmäärän ja aikataulun arviointiin käyttäen hyväkseen eri kustannustekijöiden arvoja. Useat niin teollisuudessa kuin tutkimuksessa käytettävät arviointityökalut perustuvat tähän malliin. COCOMOII -tutkimusprojekti on ollut jo pitkään olemassa, jonka tarkoituksena on parantaa ja lisätä malliin uusia ominaisuuksia ja tarkkuutta. Joitakin sovelluksia on jo tehty sen pohjalta ja kappaleissa 3.3.1 ja 3.3.2 on esitetty lyhyesti kaksi tällaista. COCOMO oli yksi ensimmäisistä ohjelmistotuotantokustannusmalleista, joka on nykyään hyväksytyin ohjelmistonkustannusten ja aikataulun arviointitapa. Se on jo pitkään toiminut vertailukohtana muille kustannusarviointi malleille ja tavoille. COCOMO koostuu kolmesta eri mallista: perustason-, keskitason- ja korkeantasonmalli. B. Boehmin tutkimukset näistä kolmesta mallista on osoittanut, että keskitason COCOMO on huomattavasti parempi kuin perustason COCOMO, mutta korkeantason COCOMO ei juuri tarjoa keskitasonmallia parempaa arviota. 3.3 COCOMO -malliin perustuvia sovelluksia Koska kyseessä ovat hyvin erikoistuneet ohjelmat, on erittäin tärkeää, että ihminen, joka ohjelmaa käyttää on asiantuntija. Muuten tällaista erikoisohjelmaa on vaikeata käyttää tehokkaasti. Ohjelmat perustuvat aina niihin syötettyihin subjektiivisiin tietoihin, jotka ohjelma vain käsittelee mallin pohjalta, ja siksi asiantuntemus ja käytännönkokemus alalta on käyttäjälle välttämättömyys. 6
Ohjelman tarkkuus riippuu siis siitä, miten kokenut käyttäjä on. Avuksi asiassa on kuitenkin laajat historialliset tiedot, jos niitä on ohjelmaan kerätty. Ohjelmaan voi syöttää vanhojen projektien tietoja siitä, miten ne ovat menneet ja kuinka paljon ne ovat maksaneet. Mitä enemmän ohjelmaan on syötetty historiallisia tietoja sen parempi, koska silloin ohjelma pystyy niiden avulla arvioimaan paremmin uusia syötettyjä tietoja. Mitä vähemmän historiatietoja ohjelmalla on, sitä enemmän tarvitaan taitoa ihmiseltä, joka yrittää muodostaa arviota. 3.3.1 USC-COCOMOII USC-COCOMO (University of Southern California - Constructive Cost Model) on vuorovaikutteinen ohjelmistokehitysprojekteja varten kehitetty ohjelmisto (kuva 2), joka auttaa projektin kustannusten ja aikataulun suunnittelussa. COCOMOn joustavuuden ansiosta, projektipäällikkö voi kehittää Kuva 2 USC-COCOMOII malleja projektista, joiden avulla hän voi tunnistaa potentiaaliset resursointi-, henkilöstö-, kustannus- ja aikatauluongelmat. Tämä voi tapahtua ennen projektia tai projektin kulun ja ohjelmiston kehitystyön aikana. USC-COCOMO perustuu uudistettuun COCOMO versio II:seen, ohjelmistojen kustannus- ja aikataulunarviointi malliin. Päätavoitteet ohjelmalle ovat: kehittää 1990 ja 2000 -luvuille sopiva ohjelmistojen kustannus- ja aikataulunarviointi ohjelmisto. kehittää kustannustietokanta ja työkalu, joilla voi jatkuvasti parantaa olemassa olevia projektimalleja. tarjota määrällisesti erittelevä kehys ja työkalut tekniikan kehityksen vaikutusten arvioimiseen projektin kustannuksissa ja aikataulussa. 7
Kuvassa 3 on esitetty ohjelman projektinäkymä, joka toimii samalla myös ohjelman päänäkymänä. Ohjelman toiminnallisuuksia ja käyttöä käydään läpi tarkemmin seminaariesityksen suullisessa osassa. Kuva 3 Projektinäkymä 8
3.3.2 Construx Estimate Construx Estimaten (kuva 4) avulla voi kehittää projektin alkuvaiheissa karkeita arvioita siitä, miten projekti tulee etenemään ja myöhemmin tarkentaa niitä. Projektin aluksi on siis mahdollista kehittää nopeita suuntanäyttäviä malleja ja myöhemmin, kun projektin koko ja muut yksityiskohdat alkavat tarkentua, voidaan arvioida uudelleen projektia ja tarkentaa yksityiskohtia, jolloin arvionkin tarkkuus paranee. Kuva 4 Constux Estimate Constux Estimate käyttää kolmea eri arviointitapaa: Projektityypin mukainen arviointi, joka käyttää toimialatyypin tunnettuja tietoja. Kustannustekijöiden mukainen arviointi, joka käyttää toimialatyypin tunnettuja tietoja yhdessä tuottavuustekijöiden kanssa. Historian mukainen arviointi, joka käyttää yrityksen aiemmin arvioituja projektitietoja hyväkseen. Historiallisten tietojen avulla tehdyt arviot ovat tarkempia kuin pelkästään asiantuntijan tekemät arviot. Estimate ohjelman historian mukainen arviointi auttaa 9
kehittämään suhteellisen tarkkoja arvioita, koska ne perustuvat oikeisiin tietoihin, joita on kerätty yrityksen aiemmin toteutetuista projekteista. Ohjelma käyttää tavoitehakuisia (goal-seeking) algoritmeja, joiden avulle se etsii optimaalisen henkilöstömäärän tai aikataulun, perustuen niihin painotuksiin, joita käyttäjä määrittelee työmäärän, aikataulun, kustannusten tai henkilöstön kohdalla. Construx Estimate tuottaa tilaston käyttäjälle, joka ennustaa todennäköisen projektin tuloksen (kuva 5), niiden tietojen perusteella, mitkä käyttäjä on järjestelmään syöttänyt. Ohjelma tuottaa todennäköisen lopputulosarvion, kaikilla mahdollisilla kustannus, aikataulu tai työmäärä syötteillä. Esimerkiksi Estimate voi suositella tietyn kokoiselle projektille 12 kuukauden aikataulua, mutta projektin olisi määrä olla valmis jo yhdeksässä kuukaudessa. Nyt käyttäjä voi antaa ehdoksi 9 kuukauden aikarajan ja nähdä kuinka suuri todennäköisyys projektin onnistumisella on tällä aikataululla. Kuva 5 Projektinäkymä 10
4 Yhteenveto Riskinhallinta ja kustannusarviointi on välttämätöntä projekteille, joiden halutaan valmistuvan aikataulussa ja ilman kustannusten ylityksiä. Tosin näiden perusteellinen tekeminen ei kuitenkaan takaa, että mitään ongelmia aikataulun tai kustannusten kanssa ei syntyisi. Hyvin toteutettuna riskinhallinta ja kustannustenarviointi vähentää todennäköisyyttä projektien epäonnistumisiin. Avuksi tällaiseen työhön on kehitetty useita erilaisia malleja, joista yleisesti hyväksytyin on COCOMO. [BOE81] Tästä mallista on sittemmin kehitetty monia variaatioita erilaisiin tilanteisiin, joihin se ei suoraan sovellu. Myös erilaisia ohjelmistoja on kehitetty auttamaan ihmisiä tekemään parempia arvioita kustannuksista ja havaitsemaan helpommin riskejä. Näiden ohjelmien on osoitettu parantavan todennäköisyyttä onnistuneisiin projekteihin, mutta yhä suurin vaikutus projektin onnistumiseen on ammattitaitoisilla ihmisillä. 11
Lähteet 1. [MAD97] R. J. Madachy, Heuristic Risk Assessment Using Cost Factors, IEEE Software 1997 2. [QIP98] Qing Hu, R. T. Plant, et al; Journal of Management Information Systems, Summer 98 Vol. 15 Issue 1 3. [BOE87] B. Boehm Improving Software Productivity, Computer, 20, 9 1987, 43-57 4. [BOE89] B. Boehm, Software Risk Management, IEEE computer Soc. Press, Los Alamitos, Calif., 1989 5. [CHA89] R. Charette, Software Engineering Risk Analysis and Management, intertext Publications/Multiscience Press and McGraw-Hill, New York, 1989 6. [JNW84] A. M. Jenkins, J.D. Naumann, J.C Wetherbe; Empirical Investigations of Systems Development Practices and Results. Information and Management, 7, 2 1984, 72-84 7. [JOR95] Jorgenssen M. Experience with the Accuracy of Software Maintenance Task Effort Prediction Model. IEEE Transactions on Software Engineering, 21, 8 (1995), 674-681 8. [BOE81] B. Boehm, Software Engineering Economics, Prentice Hall, Englewood Cliffs, N.J., 1981 12