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

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

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

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

Data Sailors - COTOOL dokumentaatio Riskiloki

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Projektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti

T Edistymisraportti. ExtraTerrestriaLs PP iteraatio

PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

COTOOL dokumentaatio Riskiloki


Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Harjoitus 3 Case Face Wash. Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja

T Testitapaukset TC-1

Project group Tete Work-time Attendance Software

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset. Riskienhallinta DTV projektissa

Siimasta toteutettu keinolihas

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

PS-vaiheen edistymisraportti Kuopio

T Projektikatselmus

Projektisuunnitelma Viulu

EDISTYMISRAPORTTI - PS Virtuaaliyhteisöjen muodostaminen Versio 1.0

Projektisuunnitelma Nero-ryhmä

SEPA: Projektin edistymisen seuranta ja hallinta

Kuopio Testausraportti Asiakkaat-osakokonaisuus

T Tietojenkäsittelyopin ohjelmatyö

T Tietojenkäsittelyopin ohjelmatyö Hirviöryhmä loppukatselmointi. Hirviö. Projektikatselmointi

TYÖOHJEET VR-HYVINKÄÄ

Lego Mindstorms anturit

T Testiraportti - järjestelmätestaus

Ryhmä (11) Numeropankki

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen

Reilun Pelin työkalupakki: Kiireen vähentäminen

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU käyttöjärjestelmässä -projekti

SYSTEMAATTINEN RISKIANALYYSI YRITYKSEN TOIMINTAVARMUUDEN KEHITTÄMISEKSI

Raitiotieallianssin riskienhallintamenettelyt

Projektisuunnitelma. Laitteiston ja kalusteiden hankinta, versio WEB MAGIA OY Laatija Oula Kangas

Jyväskylän yliopisto, Sovellusprojektien kokoustila AgC Itkonen Jonne (saapui 9.25) Santanen Jukka Pekka (saapui 9.35)

VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D

T Loppukatselmus

Tehokkaiden strategioiden identifiointi vakuutusyhtiön taseesta

Projektisuunnitelma. Palvelujen siirto Palvelutietovarantoon (PTV) Harri Nevala 1

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Projektisuunnitelma. Projektin tavoitteet

Convergence of messaging

T Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu. Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki

ENG-A1002 ARTS-ENG-Projekti. B-kori

Menetelmäraportti - Konfiguraationhallinta

Electric power steering

IIZT4020 Projektitoiminta

Case Tampere3: PMO:n rooli organisaatioiden yhdistyessä

T Projektisuunnitelma

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjausryhmä. Petri Veijalainen

Jyrki Kullaa ohjaava opettaja. Mika Miettinen puheenjohtaja

Projektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus

AS Automaatio ja systeemitekniikan projektityöt Projektisuunnitelma Syksy 2009 A09 05 OSGi IRC Bot For Coffee Maker

CS-C2130 / CS-C2140 / CS-E4910 Software Project 1 / 2 / 3 ja Accenture Luento

GroupDesk Toiminnallinen määrittely

Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Projektisuunnitelma. Boa Open Access. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

Valtioneuvoston kanslia VAIN VIRKAKÄYTTÖÖN Hallinto- ja palveluosasto/hallintoyksikkö Terja Ketola PTJ2008-työsuunnitelma 1 (5)

Orientaatio ICT-alaan. Projekti

Määrittelyvaihe. Projektinhallinta

Liikenteen turvallisuusviraston Trafin toimialariippumattomien ict-tehtävien toimintosiirtoprojektin loppuraportti 1.0

Ohjausryhmä. EAKR-hankkeiden starttikoulutus ja

T Projektisuunnitelma

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä

Project group Tete Work-time Attendance Software

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Projektityö

Tietojärjestelmän osat

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Junaliikenteen häiriötilannetietojen tuottaminen ja tiedotus

Raahen kaupunki Projektiohjeet luonnos

Mylab Projektitoiminnan kehittäminen. PM Club Tampere

xxx avoimen rajapinnan hallintasuunnitelma (VALMIS 1.4)

PROJEKTIN EDISTYMISRAPORTTI Seurantajakso <jaksonumero, alkupäivä - päättymispäivä>

Gumenius Sebastian, Miettinen Mika Moottoripyörän käynnistysalusta

Projektin suunnittelu

Aloite Onko asioiden esittämistapa riittävän selkeä ja kieleltään ymmärrettävä?

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön

Projektin palikat hallintaan! Tehokkaan projektinhallinnan opas. Idea Suunnittelu Käynnistäminen Toteutus Tulos

HELSINGIN KAUPUNKI TOIMINTAOHJE 1/7 LIIKENNELIIKELAITOS Yhteiset Palvelut / Turvallisuuspalvelut K. Kalmari / Y. Judström 18.9.

Kooste kotitehtävien vastauksista. Kotitehtävä 6 - Ylläpito- ja kehittämismalli

Projektinhallinta SFS-ISO mukaan

Hajautettu Ohjelmistokehitys

Automaattinen yksikkötestaus

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

Miten tehdä onnistunut projektisuunnitelma 10 vinkkiä

Transkriptio:

T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (12) T-76.115 Riskienhallintadokumentti ExtraTerrestriaLs Versio Pvm Tekijä Kuvaus 0.1 Mika Suvanto Alustava versio 0.2 19.10.2004 Mika Suvanto Riskilokia täytetty 0.3 21.10.2004 Mika Suvanto Kosmeettisia muutoksia 1.0 21.10.2004 Mika Suvanto Kirjoitusvirheitä ym. korjattu Riston kommenttien perusteella 1.1 27.10.2004 Timo Sallinen Lisätty hallintakeinoja, korjauksia 1.8.10.2004 Mikko Ruokojoki Muokattu ulkonäköä ja lisätty vastuut riskeihin 2.0 29.10.2004 Mikko Ruokojoki Versio 2 2.1 Mika Suvanto Riskiloki päivitetty ja lokin muutokset -taulukko lisätty 2.4.1.2005 Mika Suvanto Riskiloki ja lokin muutokset -taulukko päivitetty 2.3 13.3.2005 Mika Suvanto Riskiloki ja lokin muutokset -taulukko päivitetty, loppuarviointi Sisältö 1. Dokumentin tarkoitus... 1 2. Riskienhallinnan osapuolet ja vastuut... 2 3. Riskienhallintaprosessi... 2 3.1. Prosessin kuvaus... 2 4. Riskiloki... 3 5. Seuranta... 4 5.1 Seurantaprosessi... 4 5.2 Toimenpiteistä päättäminen... 5 6. Loppuarviointi... 5 7. Lähteet... 6 1. Dokumentin tarkoitus Tämä dokumentti määrittelee ExtraTerrestrials ryhmän riskienhallintaprosessin Teknillisen korkeakoulun kurssin T-76.115 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 mu-

T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 2 (12) kaan 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. Riskienhallinnan osapuolet ja vastuut n sisäisen työnjaon mukaisesti riskienhallinnasta on päävastuussa Mika Suvanto. Projektipäällikkö 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 3.1.1 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

T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 3 (12) 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ä hallitaan ja seurataan säännöllisesti. Kuva 3.1.1. 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.)

T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 4 (12) suunnitteluriskit (ohjelmistosuunnittelu) laaturiskit (tuotteiden laatu) force majeure (katastrofit, sodat ym. Näihin ei varauduta ollenkaan.) vaatimusmäärittelyriskit (vaatimusmäärittelyn taso) 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 kapea-alaisia; 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 Todennäköisyys Matala (1) Kohtalainen (2) Kriittinen (3) Suuri (3) 3 6 9 Kohtalainen (2) 2 4 6 Pieni (1) 1 2 3 Taulukko 4.3. Todennäköisyys / Vakavuus 5. Seuranta 5.1 Seurantaprosessi Riskienhallinnan vastuuhenkilöt vastaavat riskien seurannasta. Seuranta käsittää:

T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 5 (12) toteutuneiden riskien havainnoinnin valittujen toimenpiteiden vaikutusten seurannan tapahtumasta opittujen asioiden analysoinnin ja kirjaamisen dokumentoinnin päivittämisen Jokaisen ryhmän jäsenen vastuulla on uusien riskien tunnistaminen ja oman vastuualueensa riskien ennakointi ja toimenpiteiden seuranta. Riskien seurannan tuloksena riskilokiin tulleet muutokset kirjataan taulukkoon 4.5. Tässä taulukossa esitetään muuttuneet kohdat sekä toteutuneet riskit ja reagointi niihin. 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. Loppuarviointi Riskienhallinnan loppuarviointi 7.3.2005. Projektiryhmän työn ollessa loppusuoralla myös riskienhallinnan työ päättyy ja riskit projektin kannalta menettävät merkitystään. Tässä kappaleessa on arvioitu riskienhallinnan mielekkyyttä, toteuttamistapaa ja onnistumista projektissamme. Pääosin riskienhallintatyötä tehtiin iteraatioiden aikana pidetyissä riskienhallintatapaamisissa sekä ryhmä- ja asiakastapaamisissa. Riskienhallintatapaamisten tarkoituksena oli pysähtyä miettimään projektin tilannetta riskien näkökulmasta, tunnistaa uusia riskejä ja arvioida toimenpiteitä ja riskien vakavuutta. Nämä tapaamiset olivat varsin onnistuneita ja tehokkaita. Riskienhallinnan tärkeimpänä antina voi pitää toisenlaista näkökulmaa projektin tilaan. Miettimällä asioita riskien kannalta löysimme asioita joihin pitää kiinnittää enemmän huomiota. Esimerkkinä dokumentoinnin laaturiski, joka todettiin I2 -vaiheessa. Tästä seurasi huomattava panostus ja parannus dokumentointiin I2 ja FD -vaiheissa. Myös asioiden tärkeysjärjestykseen riskienhallinnan menetelmillä oli vaikutusta. Toimenpiteistä päättäminen tehtiin pitkälti normaalin projektinhallinnan keinoin keskustelemalla ryhmäkokouksissa ja uutisryhmässä. Yhteenvetona riskienhallintamenetelmä vaikuttaa kohtuullisen onnistuneelta. Projekti on kuitenkin kohtuullisen suppea, joten raskaampaa ja byrokraattisempaa menetelmää ei kannattane käyttää. Riskienhallinta vaati suoranaisesti yhteensä n. 30 h (~2 % projektin tunneista) työ-

T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 6 (12) tä ryhmältä. Tähän lukuun ei sisälly ryhmä/asiakaskokoukset tai projektipäällikön/riskistä vastaavan toimenpiteet. 7. Lähteet [1] ExtraTerrestrials ryhmän projektisuunnitelma [2] J. Kontio: The Riskit Method for Software Risk Management, version 1.00, http://www.soberit.hut.fi/~jkontio/riskittr.pdf, viitattu 14.10.2004 [3] Jyrki Kontio, Risk management intro, T-76.663 lecture slides, http://www.soberit.hut.fi/t-76.115/03-04/ohjeet/lectures/t-76.633_rmintro.pdf, viitattu 14.10.2004

ID Kategoria Vakavuus (1-3) R1 R2 R3 R4 R5 R6 R7 R8 Vaatimus Suunnittelu Todennäköisyys (1-3) 2 => 1 1 3 => 2 1 3 2 3 =>2 1 Tiedustellaan asiakkaalta ulkopuolisia tietolähteitä. Tehdään määrittelyistä riittävän tarkat ryhmän mahdollisimman itsenäisen työskentelyn mahdollistamiseksi. 2 1 1 1 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 Projektipäällikkö ja vaatimusmäärittelyn vastuuhlö Arkkitehtuurin vastuuhlö ja projektipäällikkö Suunnitteluvirhe Asiakkaan henkilöresurssit puutteelliset Versionhallintapalvelin vikaantuu News/kalenterikone vikaantuu n keskeinen kommunikointi ei toimi 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ä Erimielisyyksiä, väärinymmärryksiä 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 Motivaatio kärsii, työmäärä lisääntyy 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. Siirretään versionhallinta koulun palvelimelle riskin toteutuessa Varaudutaan varmuuskopioinnilla, hoidetaan kommunikointi sähköpostitse tai siirrytään TikiWikiin riskin toteutuessa Mietitään kommunikointikäytännöt uusiksi, lisätään jäsenten välisiä tapaamisia. Projektipäällikkö Projektipäällikkö Projektipäällikkö Projektipäällikkö ja ko. asiasta vastaava News-vastaava 21.10.2004 Projektipäällikkö

ID Kategoria Vakavuus (1-3) R9 R10 R11 R12 R13 R14 R15 R16 R17 Sopimus Sopimus Todennäköisyys (1-3) 2 1 1 1 3 1 1 2 1 1 1 1 1 1 2 3 Altistavat tekijät n tavoitteet epäselviä Lisenssien kanssa ongelmia Oikeuksista sopiminen ei onnistu SoberIT:llä laiteongelmia ATK-keskuksella laiteongelmia ATK-keskuksella / muilla ISP:llä ongelmia sähköpostin kanssa n jäsenellä laiteongelmia ko. ryhmän jäsen Motivaatio-ongelmia Liian paljon töitä Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi Erimielisyyksiä, väärinymmärryksiä Jotain lisämoduulia ei voida käyttää ohjelmistossa SoberIT sivut alhaalla Projektin kotisivut alhaalla Sähköpostiongelmat kohtainen tietokone hajoaa Projekti ei kiinnosta Projektille ei pystytä järjestämään riittävästi aikaa 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 Työt viivästyvät, viivästyttää myös muiden työtä, arvosanat putoavat / Mentor 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ökohtaisista tavoitteista, mahdollinen tehtävien uudelleenjärjestely. Tehtäviä jaetaan uudelleen, riittävä osaamisen jakaminen varmistettava. Projektipäällikkö Työkaluista vastaava Projektipäällikkö SoberIT atk HUT atk HUT atk Projektipäällikkö n jäsenet ja projektipäällikkö

ID Kategoria Vakavuus (1-3) R18 R19 R20 R21 R22 R23 Todennäköisyys (1-3) 2=>1 2=>1 1 1=>2 Laatu Vaatimus R24 / Vaatimus R25 R26 R27 Laatu Kaikki 3 1=>2 2 1=>2 1 1 1 2 3=>2 1 1=>2 1=>2 1 2 2 1 Altistavat tekijät 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 Puutteellinen tietotaito ryhmällä Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi 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 Tekniset haasteet osoittautuvat liian suuriksi 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 Tavoiteltua toiminnallisuutta ei pystytä toteuttamaan 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. Määrittelyt käydään riittävän selvästi läpi asiakkaan kanssa, jotta epäselvyyksiä ei tule. Kokeillaan vaihtoehtoisia kommunikointitapoja, muutetaan yhteysti- Laaditaan muistiot jokaisesta tapaamisesta, dokumentoidaan sovitut asiat Haetaan asiakkaalta opastusta, tarvittaessa muutoksia projektin laajuuteen. Projektipäällikkö Projektipäällikkö n jäsen, joka on työmäärät arvioinut Otetaan käyttöön systemaattiset testausprosessit. Viikoittaiset raportit edistymisestä, edistymättömyydestä. Testausvastaava ja projektipäällikkö Testausvastaava ja projektipäällikkö Projektipäällikkö ja vaatimusmäärittelyn vastuuhlö Projektipäällikkö heyttä. Pidetään katselmuksia tärkeimmistä dokumenteista Katselmointivastaava Kokouksen sihteeri Projektipäällikkö

ID Kategoria Vakavuus (1-3) R28 R29 R30 R31 R32 R33 R34 R35 Altistavat tekijät Suunnittelu Suunnittelu Laatu Laatu Todennäköisyys (1-3) 2 1 3=>1 1 2 1=>2 2 1=>2 Tekniset ongelmat muiden (lähde-) järjestelmien suhteen kemia ryhmän kesken ei toimi Rajapinnat huonosti määritelty tai kommunikointi ohjelmoijien välillä puutteellista Siirtyminen suunnittelusta toteutukseen hidasta Arkkitehdilla tuntimäärä varsin suuri Muutamalla ryhmän jäsenellä varsin vähän tunteja Koodin laatu heikkoa Keskeneräistä koodia jää ohjelmaan Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi Löytyy bugeja tms. ominaisuuksia joihin ei voida vaikuttaa 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 Toteutus viivästyy Toteutus viivästyy Arkkitehti ei osallistu aktiivisesti I2 ja FD -vaiheisiin Vaikeuksia löytää tarpeeksi aikaa myöhemmissä vaiheissa Ohjelman toimintaa ei ymmärretä Koodia luullaan valmiiksi Jatkokehitys vaikeaa, muiden ryhmän jäsenten vaikea saada selvää / Jatkokehitys vaikeaa / 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. Pyritään jakamaan toteutusvastuuta ryhmälle, pidetään aivoriihi aiheesta Vastuutetaan tehtäviä uudelleen (johtuu osittain projektin luonteesta, mm. testausta ei olla pystytty juurikaan tekemään) Jaetaan itsenäisiä tehtäviä mm. joululoman ajaksi Pidetään koodikatselmointeja, käytetään suunnittelumalleja Dokumentointiin panostettava Arkkitehtuurista vastaava ja projektipäällikkö n jäsen yhdessä projektipäällikön kanssa Arkkitehtuurista vastaava Projektipäällikkö organisoi työt Toteutus vaikeutuu, muut joutuvat ottamaan vastuuta enemmän Tuntimäärät voivat ko. henkilöiden osalta jäädä vajaiksi, seurauksena heikompi lopputulos Projektipäällikkö, arkkitehtuurista vastaava Projektipäällikkö, ko. henkilöt Katselmointivastaava, arkkitehtuurista vastaava Projektipäällikkö, dokumentoinnin vastaava 24.01.2005

Taulukko 4.4. Riskiloki Muuttunut kohta Muutos Tilanne Toteutetut / päätetyt toimenpiteet Päivämäärä R1 Laskettu todennäköisyys 2 -> 1 Ei merkkejä toteutumisesta - R3 - Osittain toteutunut pieniä puutteita löydetty R6 - Osittain toteutunut versiohallinnan kanssa pieniä ongelmia Päätetty tehostaa muutostenhallintaa 24.11 toimii ok. Pidetään yllä valmiutta siirtää CVS progress:iin R7 - - Varmuuskopiointi on järjestetty. R8 - Osittain toteutunut informaatiotulva ongelmana, kaikki eivät ole päässeet kokouksiin kenties riittävästi R11 - Lisenssistä / salassapidosta ei ole saatu sopimusta aikaan R12 - Osittain toteutunut aiheuttanut ylimääräistä odottelua palautuksen aikoihin R15 Nostettu todennäköisyys 1 -> 2 Toteutunut nettiyhteys poikki, bussilakko vaikeuttanut koulun koneiden käyttöä R16 Nostettu todennäköisyys 1 -> 2 Todennäköisesti pienissä määrin esiintyy jokaisella projektin aikana R17 Nostettu todennäköisyys 2 -> 3 Muut kiireet ovat rajoittaneet osallistumista projektiin - Projektipäällikkö on yhteydessä asiakkaaseen välittömästi Projektipäällikkö määrittelee lokaalin kopion teon kurssisivuista jollekin tehtäväksi - - -

Muuttunut kohta Muutos Tilanne Toteutetut / päätetyt toimenpiteet Päivämäärä R26 Nostettu todennäköisyys 1 -> 2 Muutama tehtävä unohtunut / viivästynyt, epävirallisimmissa työpalavereissa luvattuja asioita ei aina muista, kokouksen sihteeri ei huomaa kirjata kaikkia päätöksiä R30 - Osittain toteutunut kaikki eivät ole täysin selvillä miten edetä toteutuksessa Jokaisen pyrittävä kiinnittämään tähän enemmän huomiota Pidetään 25.11. aivoriihi toteutuksesta R31 Uusi riski - - R32 Uusi riski - - R33 Uusi riski - - R34 Uusi riski - PP viestittää vielä ohjeita vastuujaosta ja tehtävistä R3 Osittain toteutunut Epäselviä asioita kerättävä palaveriin perjantaiksi 24.1.2005 R11 Ei enää ajankohtainen Osittain toteutunut 24.1.2005 R13 Ei enää ajankohtainen 24.1.2005 R20 Osittain totetunut 24.1.2005 R31 Ei enää ajankohtainen 24.1.2005 Kaikki Ei enää ajankohtainen Projekti päättyy 10.3.2005 Taulukko 4.5. Riskilokin muutokset