T Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (9)

Transkriptio

1 T Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (9) T Riskienhallintadokumentti ExtraTerrestriaLs Versio Pvm Tekijä Kuvaus 0.1 Mika Suvanto Alustava versio Mika Suvanto Riskilokia täytetty Mika Suvanto Kosmeettisia muutoksia Mika Suvanto Kirjoitusvirheitä ym. korjattu Riston kommenttien perusteella Timo Sallinen Lisätty hallintakeinoja, korjauksia Mikko Ruokojoki Muokattu ulkonäköä ja lisätty vastuut riskeihin Mikko Ruokojoki Versio 2 Sisältö 1. Dokumentin tarkoitus Riskienhallinnan osapuolet ja vastuut Riskienhallintaprosessi Prosessin kuvaus Riskiloki Seuranta Seurantaprosessi Toimenpiteistä päättäminen Lähteet Dokumentin tarkoitus Tämä dokumentti määrittelee ExtraTerrestrials ryhmän riskienhallintaprosessin Teknillisen korkeakoulun kurssin T ohjelmistoprojektissa. Tarkempi kuvaus ohjelmistoprojektista löytyy projektisuunnitelmasta [1]. Dokumentin keskeistä sisältöä ovat erityisesti riskienhallintaprosessin kuvaus, jossa kerrotaan kuinka ryhmä hallitsee projektiin luontaisesti kuuluvaa epävarmuutta, sekä riskiloki, jossa yksittäiset riskit on eritelty, analysoitu ja vastuutettu. Tätä dokumenttia päivitetään tarpeen mukaan projektin edetessä. Tämä sisältää tarpeellisiksi koetut muutokset prosessiin sekä toistuvat päivitykset riskilokiin aina uusia riskejä tunnistettaessa tai kun jo tunnistetuista riskeistä saadaan lisää tietoa.

2 T Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 2 (9) 2. Riskienhallinnan osapuolet ja vastuut n sisäisen työnjaon mukaisesti riskienhallinnasta on päävastuussa Mika Suvanto. Mikko Ruokojoki toimii tässä varahenkilönä. Heidän tehtäviään riskienhallinnassa ovat: prosessin määrittäminen riskienhallinnan dokumentointi riskien analysointi riskien seuranta Koko projektiryhmä osallistuu myös riskienhallintaan: riskien tunnistaminen toimenpiteistä päättäminen Muut riskienhallinnan osapuolet: asiakas mentor ja mentor muodostavat projektin ohjausryhmän. 3. Riskienhallintaprosessi 3.1. Prosessin kuvaus Käyttämämme riskienhallinnan prosessi pohjautuu Jyrki Kontion RiskIt menetelmään [2, 3]. Emme kuitenkaan sovella menetelmää koko laajuudessaan, vaan pyrimme toteuttamaan menetelmää tarpeisiimme soveltuvin osin. Tähän päädyttiin projektin suhteellisen pienuuden ja vähäisten resurssien takia. Kuvassa on esitetty iteratiivinen riskienhallintaprosessi, jota sovellamme projektissa. Keskeistä on riskienhallinnan iterointi projektivaiheissa. Jokaisen vaiheen alussa pidetään palaveri, jossa tunnistamme ja analysoimme mahdollisia uusia riskejä ja muutostarpeita riskienhallintaprosessiin. Mikäli projektissa tapahtuu suuria muutoksia esimerkiksi tavoitteiden osalta, palaveri voi olla syytä pitää myös tällöin. Tapaamisten tuloksena syntyneet muutokset päivitetään tähän dokumenttiin. Riskejä tunnistetaan kolmen neljän hengen työryhmässä. n kokoonpanoon kuuluvat riskienhallinnan vastuuhenkilöt sekä mahdollisesti vaihtuva kolmas (ja neljäs) jäsen. Työryhmän tarkoitus on tunnistaa projektiin liittyvät riskit, analysoida ne, määrätä vastuuhenkilöt riskien seurantaan, suunnitella toimenpiteet riskin toteutuessa ja kirjata tulokset riskilokiin. Palaverin jälkeen riskienhallinnan vastuuhenkilöt käyttävät tarkistuslistamenetelmää varmistuakseen tulosten kattavuudesta. Koko projektin ajan koko ryhmä voi tunnistaa uusia riskejä ja esittää muutoksia nämä pyritään käsittelemään välittömästi. Projektin ensimmäisen vaiheen riskintunnistuksessa käytetään myös hyväksi edellisten vuosien projektiraportteja näissä voi olla konkreettista tietoa projekteja kohdanneista riskeistä. Riskienhallinnassa keskitytään ennen kaikkea suurimpiin riskeihin, ja nämä pyritään tunnistamaan ja analysoimaan varhaisessa vaiheessa. Kaikkia pienempiä riskejä tuskin pystymme edes tunnistamaan ja niihin keskittyminen ei ole tehokasta; projektiin liittyy kuitenkin normaalia epävarmuutta. Prosessissa onkin keskeistä, että projektin kannalta tärkeimpiä riskitekijöitä

3 T Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 3 (9) hallitaan ja seurataan säännöllisesti. Kuva Riskienhallintaprosessi 4. Riskiloki Riskien luokittelussa olennaista on kaksi tekijää riskin vakavuus ja riskin toteutumisen todennäköisyys. Nämä käsitteet on määritelty taulukoissa 4.1 ja 4.2. Varsinainen riskiloki on taulukossa 4.4. Riskit on jaettu eri kategorioihin niiden tyypin mukaan. Näitä kategorioita ovat: henkilöriskit (projektiryhmä, asiakas, kurssihenkilökunta) infrastruktuuririskit (laitteistot, työkalut ym.) sopimusriskit (oikeuksista sopiminen ym.) suunnitteluriskit (ohjelmistosuunnittelu) laaturiskit (tuotteiden laatu) force majeure (katastrofit, sodat ym. Näihin ei varauduta ollenkaan.) vaatimusmäärittelyriskit (vaatimusmäärittelyn taso)

4 T Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 4 (9) Taulukko 4.3 kuvaa todennäköisyyden ja vakavuuden suhdetta. Tärkeimmät riskit kuuluvat oikeaan ylänurkkaan (merkitty punaisella) ja vähäisimmät riskit vasempaan alanurkkaan (merkitty vaaleansinisellä). Taulukko kertoo myös todennäköisyyden ja vakavuuden pisteytyksen, joita käytetään riskilokissa vastaavissa sarakkeissa. Vakavuus Kriittinen Kohtalainen Matala Kuvaus Tapahtuma aiheuttaa toteutuessaan suuria ongelmia projektin suorittamiselle tavoitteiden mukaisesti, jopa vaarantaen koko projektin. Tapahtuma aiheuttaa toteutuessaan paljon työtä ja vaatii huomiota useilta ryhmän jäseniltä. Matalan prioriteetin vaatimukset vaarantuvat. Tapahtuma aiheuttaa lähinnä ylimääräistä työtä ja vaatii huomiota, mutta ei vaaranna projektiin kohdistuvia vaatimuksia. Vaikutukset kapeaalaisia; vähän työtä tai vaikuttaa vain yhteen kahteen henkilöön. Taulukko 4.1. Vakavuuden määritelmä Todennäköisyys Suuri Kohtalainen Pieni Kuvaus Tapahtuma toteutumista voidaan pitää hyvin todennäköisenä projektin aikana, muttei kuitenkaan varmana. Tapahtuman toteutuminen on varsin mahdollista. Tapahtuma on varsin epätodennäköinen, mutta kuitenkin mahdollinen projektin aikana. Taulukko 4.2. Todennäköisyyden määritelmä Vakavuus Matala (1) Kohtalainen (2) Kriittinen (3) Todennäköisyys Suuri (3) Kohtalainen (2) Pieni (1) Taulukko 4.3. Todennäköisyys / Vakavuus 5. Seuranta 5.1 Seurantaprosessi Riskienhallinnan vastuuhenkilöt vastaavat riskien seurannasta. Seuranta käsittää: toteutuneiden riskien havainnoinnin valittujen toimenpiteiden vaikutusten seurannan tapahtumasta opittujen asioiden analysoinnin ja kirjaamisen dokumentoinnin päivittämisen

5 T Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 5 (9) Jokaisen ryhmän jäsenen vastuulla on uusien riskien tunnistaminen ja oman vastuualueensa riskien ennakointi ja toimenpiteiden seuranta. 5.2 Toimenpiteistä päättäminen Riskitapahtuman toteutuessa seuraukset riippuvat riskin vakavuusasteesta: matala Työryhmä / projektipäällikkö päättää toimenpiteet kohtalainen Päätetään koko ryhmän tapaamisessa kriittinen Päätetään yhdessä ohjausryhmän kanssa, välitön raportointi kaikille projektin osapuolille Toimenpiteistä päätettäessä pohjaudutaan riskilokissa määriteltyihin toimintatapoihin. Kuitenkin on todennäköistä, että näitä on tarpeellista soveltaa vielä yksityiskohtaisemmin. Toteutuneista riskeistä on kaikissa tapauksissa raportoitava riskienhallinnan vastuuhenkilöille seurantaa varten. 6. Lähteet [1] ExtraTerrestrials ryhmän projektisuunnitelma [2] J. Kontio: The Riskit Method for Software Risk Management, version 1.00, viitattu [3] Jyrki Kontio, Risk management intro, T lecture slides, viitattu

6 ID Kategoria Vakavuus (1-3) R1 R2 R3 R4 R5 R6 R7 Vaatimus Suunnittelu Todennä köisyys (1-3) 3 2 Altistavat tekijät Yksi ryhmän jäsen jättää kurssin kesken Useampi ryhmän jäsen jättää kurssin kesken Vaatimusten määrittely ei onnistu ja vaatimusmäärittelyn vastuuhlö Arkkitehtuurin vastuuhlö ja projektipäällikkö Suunnitteluvirhe Asiakkaan henkilöresurssit puutteelliset Versionhallinta palvelin vikaantuu News/kalenteri kone vikaantuu Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi n henkilöresurssit vähenevät n henkilöresurssit vähenevät olennaisesti Vaatimusmäärittel yyn jää olennaisia puutteita Valitaan väärä toteutustekniikka Kommunikointi asiakkaan kanssa jää liian vähälle Versionhallinta ei ole käytettävissä Newssit / kalenteri ei ole käytettävissä Projektin laajuus supistuu tai työmäärä lisääntyy Projektin laajuus ja läpivienti joudutaan miettimään uudestaan Lopputulos ei vastaa asiakkaan tarpeita Joudutaan tekemään asioita uudelleen / työmäärä lisääntyy Lopputulos ei vastaa asiakkaan tarpeita, ryhmän motivaatio kärsii Ohjelmointi / dokumentointi viivästyy n kommunikointi vaikeutuu Tehtävien uudelleenjako, tarvittaessa muutoksia projektin laajuuteen. Neuvotellaan asiakkaan kanssa projektin laajuuden supistamisesta, mahdollisesti asiakkaan tiiviimpi osallistuminen. Tiivis yhteistyö asiakkaan kanssa vaatimusmäärittelyä tehdessä. Riittävä yhteistyö asiakkaan teknisen asiantuntijan kanssa merkittävistä teknisistä ratkaisuista. Tiedustellaan asiakkaalta ulkopuolisia tietolähteitä. Tehdään määrittelyistä riittävän tarkat ryhmän mahdollisimman itsenäisen työskentelyn mahdollistamiseksi. Siirretään versionhallinta koulun palvelimelle riskin toteutuessa Varaudutaan varmuuskopioinnilla, hoidetaan kommunikointi sähköpostitse tai siirrytään TikiWikiin riskin toteutuessa ja ko. asiasta vastaava News-vastaava

7 R8 R9 R10 R11 R12 R13 R14 R15 R16 Sopimus Sopimus 1 2 n keskeinen kommunikointi ei toimi n tavoitteet epäselviä Lisenssien kanssa ongelmia Oikeuksista sopiminen ei onnistu SoberIT:llä laiteongelmia SoberIT sivut alhaalla ATK-keskuksella laiteongelmia ATK-keskuksella / muilla ISP:llä ongelmia sähköpostin kanssa n jäsenellä laiteongelmia Motivaatio-ongelmia Erimielisyyksiä, väärinymmärryksiä Erimielisyyksiä, väärinymmärryksiä Jotain lisämoduulia ei voida käyttää ohjelmistossa Projektin kotisivut alhaalla Sähköpostiongelmat kohtainen tietokone hajoaa Projekti ei kiinnosta Motivaatio kärsii, työmäärä lisääntyy Motivaatio kärsii, työmäärä lisääntyy Toimintoja joudutaan karsimaan ja/tai tekemään itse Projekti ei käytännössä pääse käyntiin Dokumenttien teko viivästyy tai vaikeutuu Kotisivut tilapäisesti poissa käytöstä Sähköposti ei kulje tai kulkee hyvin hitaasti Työnteko vaikeutuu, osa tehdystä työstä menetetään, aikaa kuluu Työt viivästyvät, laatu heikkenee, arvosanat putoavat / Mentor Mietitään kommunikointikäytännö t uusiksi, lisätään jäsenten välisiä tapaamisia. Selkeä ja säännöllinen viestintä tehtävistä töistä, ja näiden jaosta. Selvitetään etukäteen asiakkaan kanssa minkälaiset lisenssit ovat mahdollisia ulkopuolisissa moduuleissa. Otetaan lokaalit kopioit kurssisivujen materiaalista. Tarvittaessa sivut voidaan helposti siirtää muualle, pidetään sisältö CVS:ssä Käytetään muita palveluntarjoajia (mm. työpaikat) ja puhelinta riskin toteutuessa Pidetään kaikki koodi ja dokumentit CVS:ssä, tarvittaessa käytetään koulun tarjoamia koneita Neuvotellaan ryhmän kesken henkilökohtaisita tavoitteista, mahdollinen tehtävien uudelleenjärjestely. Työkaluista vastaava SoberIT atk HUT atk HUT atk ko. ryhmän jäsen

8 R17 R18 R19 R20 R21 R22 R23 Laatu Vaatimus R24 / Vaatimus R25 R26 Laatu Kaikki 1 2 Liian paljon töitä Sairastumiset SoberIT:llä laiteongelmia Liian korkeat tavoitteet resursseihin nähden Testaus ei riittävän laadukasta Asioiden piilottelu ja peittely, tahallinen / tahaton Asiakkaan vaatimukset muuttuvat toistuvasti Kommunikointi asiakkaan suhteen ei toimi Dokumentoinnin laatu heikkoa Asioista sovitaan vain suullisesti Projektille ei pystytä järjestämään riittävästi aikaa Projektille ei pystytä järjestämään riittävästi aikaa Trapoli alhaalla Työmäärä arvioidaan liian pieneksi Virheet ja puutteet jäävät löytämättä Tieto ongelmista ei kulje Toistuvat muutokset vaatimuksiin t eivät tule toimeen keskenään Dokumentoinnin hyöty vähäistä Päätökset unohtuvat Työt viivästyvät, viivästyttää myös muiden työtä, arvosanat putoavat Työt viivästyvät, tärkeä henkilö poissa Tuntiraportteja ei saada ajoissa Hommat jäävät puolitiehen Laatu alhainen Ongelmat tulevat esille liian myöhään Suunnittelu ja töiden jakaminen vaikeutuu, työnteko hidastuu, tehdään vääriä asioita Suunnittelu ja töiden jakaminen vaikeutuu, työnteko hidastuu, tehdään vääriä asioita tyytymätön, ohjelman jatkokäyttö vaarassa Pidetään turhia palavereja, tehdään turhaa työtä, sovittuja asioita jää hoitamatta Tehtäviä jaetaan uudelleen, riittävä osaamisen jakaminen varmistettava. Riittävä redundanssi jokaisen projektin osaalueen osaamisessa. Tehtävien uudelleenjako. Otetaan raportit riittävän ajoissa (2 päivää ennen) Neuvotellaan asiakkaan kanssa ajoissa tavoitteiden muuttamisesta. Otetaan käyttöön systemaattiset testausprosessit. Viikoittaiset raportit edistymisestä, edistymättömyydestä. Määrittelyt käydään riittävän selvästi läpi asiakkaan kanssa, jotta epäselvyyksiä ei tule. Kokeillaan vaihtoehtoisia kommunikointitapoja, muutetaan yhteystiheyttä. Pidetään katselmuksia tärkeimmistä dokumenteista Laaditaan muistiot jokaisesta tapaamisesta, dokumentoidaan sovitut asiat n jäsenet ja projektipäällikkö n jäsen, joka on työmäärät arvioinut Testausvastaav a ja projektipäällikkö Testausvastaav a ja projektipäällikkö ja vaatimusmääritt elyn vastuuhlö Katselmointiva staava Kokouksen sihteeri

9 R27 R28 R29 R30 Suunnittelu Puutteellinen tietotaito ryhmällä Tekniset ongelmat muiden (lähde-) järjestelmien suhteen kemia ryhmän kesken ei toimi Rajapinnat huonosti määritelty tai kommunikointi ohjelmoijien välillä puutteellista Tekniset haasteet osoittautuvat liian suuriksi Löytyy bugeja tms. ominaisuuksia joihin ei voida vaikuttaa Tavoiteltua toiminnallisuutta ei pystytä toteuttamaan Tavoiteltua toiminnallisuutta ei pystytä toteuttamaan, työmäärä lisääntyy, suunnitelmia täytyy tarkistaa Yhteistyö ei suju Motivaatio kärsii Järjestelmäintegrointi eri moduulien välillä vaikeaa Arkkitehtuuri kärsii, suunnittelua ja ohjelmointia joudutaan miettimään uudelleen Haetaan asiakkaalta opastusta, tarvittaessa muutoksia projektin laajuuteen. Ratkaisuja ei sidota tiettyyn järjestelmään. kohtainen panostus, riittävä ajanvaraus projektille. UML-kaaviot ja/tai kirjalliset määrittelyt kaikista rajapinnoista ryhmän saataville. Arkkitehtuurista vastaava ja projektipäällikkö n jäsen yhdessä projektipäällikön kanssa Arkkitehtuurista vastaava Taulukko 4.4. Riskiloki