T-76.4115 Ohjelmistokehitysprojekti I Projektisuunnitelma (PP) Versio Päiväys Muokkaaja Kuvaus 2.1.5 1.12.2005 Markus Kattilamäki Riskit päivitetty 2.10 Markus Kattilamäki Katselmoinnissa löydetyt virheet korjattu 2.00 31.10.2005 Markus Kattilamäki Laadunvarmistussuunnitelma lisätty 1.75 31.10.2005 Markus Kattilamäki Kehittäjien tavoitteet lisätty 1.72 29.10.2005 Markus Kattilamäki Jaksotuksen alaotsikot muutettu 1.71 28.10.2005 Markus Kattilamäki 6.1.1 Muuta huomioitavaa lisätty aikatauluun 1.71 28.10.2005 Markus Kattilamäki 7.3.3 Lisätty sairastumista käsittelevä riski 1.70 28.10.2005 Markus Kattilamäki 5.1.4 Viittaus myöhempään poistettu 1.69 28.10.2005 Markus Kattilamäki 5.1.9 Virheiden seuranta päivitetty (Bugzilla) 1.68 28.10.2005 Markus Kattilamäki Rönkön oppimistavoite päivitetty 1.67 28.10.2005 Markus Kattilamäki 5.1.1 Iteraation lopun tarkentaminen 1.66 28.10.2005 Markus Kattilamäki Maininta ohjelmointikielestä (Johdanto) 1.65 28.10.2005 Markus Kattilamäki Asiakkaan laitteiden määräpäivä (kappale 4.2) 1.64 28.10.2005 Markus Kattilamäki Ryhmän tavoitteiden päivitys 1.63 28.10.2005 Markus Kattilamäki Resurssit ja budjetti päivitetty 1.62 28.10.2005 Markus Kattilamäki Organisaatiokaavion ja lyhenteiden siirto 1.61 28.10.2005 Markus Kattilamäki Asiakkaan tavoitteiden muokkaus ja prioriteetti 1.60 28.10.2005 Markus Kattilamäki Muokkaus palautteen pohjalta 1.50 16.10.2005 Markus Kattilamäki Palautettava versio 1.00 02.10.2005 Kirsi Rönkkö Lisätty muutosloki
1 Sisällysluettelo 2.2 Yleiskatsaus projektiin Valpas...3 3 Sidosryhmät ja jäsenet...5 3.1 Organisaatiokaavio...5 3.2 Yhteystiedot...7 4 Tavoitteet ja lopettamiskriteerit...8 4.1 Asiakkaan tavoitteet...8 4.2 Projektiryhmän tavoitteet...8 4.3 Henkilökohtaiset oppimistavoitteet...9 4.4 Projektin keskeytys- ja lopetuskriteerit...9 5 Resurssit ja budjetti...10 5.1 Henkilökunta...10 5.2 Materiaali...11 5.3 Budjetti...11 6 Työkalut ja menetelmät...12 6.1 Menetelmät...12 6.1.1 Iteratiivinen kehittäminen...12 6.1.2 Iteraatiosuunnittelu...12 6.1.3 Dokumentointi...13 6.1.4 Tuntiraportointi...13 6.1.5 Ohjelmiston koon raportointi...13 6.1.6 Kommunikaatio...13 6.1.7 Iteraatiodemo...14 6.1.8 Virheiden seuranta...14 6.1.9 Versionhallinta...14 6.1.10 Ohjelmointikäytännöt...15 6.1.11 SEPA - Heuristinen arviointi...15 6.1.12 SEPA Design patterns...15 6.1.13 SEPA Staattiset metodit...15 6.1.14 SEPA Refaktorointi...15 6.2 Työkalut...16 6.3 Standardit ja protokollat...16 7 Jaksotus...17 7.1 Huomioitavaa...17 7.2 Aikataulu...17 7.3 Projektin suunnittelu (PP)...19 7.4 Implementaatio 2 (I2)...20 8 Riskienhallinta...20 8.1 Prosessi...21 8.2 Riskikategoriat...21 9 Lähteet...25 1
2 Johdanto Tämä dokumentti on ryhmän Neptune projektisuunnitelma Teknillisen Korkeakoulun kurssin T-76.4115 Ohjelmistokehitysprojekti I puitteissa toteutettavaan projektiin. Asiakkaana toimii Indagon Oy. Indagon Oy on mobiilipaikannukseen erikoistunut yritys. Projekti suoritetaan aikavälillä 27.9.2005-2.3.2006. Tämä dokumentti toimii epävirallisena sopimuksena projektiin liittyvien osapuolien välillä. Projektin suorittava ryhmä käsittää kahdeksan kurssin opiskelijaa, jotka toimivat erilaisissa ohjelmistoprojektille tyypillisissä rooleissa. Kurssin toimesta projektille on asetettu toimintavaatimuksia sekä noudatettavia käytäntöjä. Ne on mainittu tässä dokumentissa. Projektin aihe on Indagon Oy:n esittämä ja se kuvataan seuraavassa kappaleessa. Tässä luvussa tullaan käsittelemään lyhyesti projektiin liittyvät oleelliset seikat, selitetään tässä dokumentissa käytetyt termit, tutustutaan toteutettavaan tuotteeseen sekä selitetään projektin viitekehys. 2.1 Käytetyt termit Seuraavassa taulukossa on lueteltu tässä dokumentissa sekä projektissa käytetyt termit ja niiden selitykset. Termien avaaminen on oleellista jotta projektiryhmä sekä asiakas ja muut sidosryhmät puhuvat asioista samoilla käsitteillä. Sillä vältetään ongelmat termien erilaisesta käytöstä kommunikoitaessa järjestelmästä ja siihen liittyvistä asioista. Taulukko 1: Käytetyt termit 2
Termi/Lyhenne EPA Selitys Edusta palvelin, Tetra-verkon reunalla oleva palvelin, joka tarjoaa Tetraverkon palveluita helpommin käytettävällä tavalla sovelluksille. Downlink Ilmoitinkeskus Itseohjaava laite Laitetyyppi Laitemalli Se kanava, jota pitkin viesti kulkee Valppaalta puhelimelle. Rakennuksessa oleva keskus, johon kaikki rakennuksessa olevat hälytin anturit/sensorit on kytketty. Laite, joka omalla toiminnallaan testaa linjan toimivuutta (laite itse on aktiivinen linjavian suhteen). Joukko samaan tarkoitukseen tehtyjä laitteita. Esimerkiksi palohälyytin ja poiju ovat laitetyyppejä. Joukko samaan laitteita, jotka toimivat samalla tavalla ja ovat saman valmistajan tekemiä. Linjavika MTT Ohjattava laite Ryhmäosoite SDS Tetra Vika yhdeydessä Valppaan ja puhelimen välillä. Mobile Telematics Terminal. Indagon Oy:n kehittämä laite, joka osaa kertoa koordinaatit paikasta, jossa laite sijaitsee. Laite, jonka kohdalla linjavikaa testataan lähettämällä laitteelle viesti (laite itse on passiivinen linjavian suhteen). TETRA-verkon "puhelinnumero", jonka vastaanottajina on useampia tahoja samaan aikaan. Tetra-verkon vastine SMS-viestille. SDS-viestejä on useampia tyyppejä, joista kolmella on kiinteä pituus ja neljäs on vaihelevan pituinen. Terrestial Trunked Radio. Omanlaisensa radiopuhelin verkko, jota useimmiten käytetään viranomaistarkoituksiin. TMR880 Nokian puhelin malli TETRA-verkkoon. Uplink Se kanava, jota pitkin viesti kulkee puhelimelta Valppaalle. Valpas Toteuttettava järjestelmä (ValvontaPalvelinSysteemi) Valvottava objekti Yksittäinen laite, jota Valpas valvoo. Virve Suomen viranomaisverkko. Toimii TETRA-järjestelmällä Yksilöosoite Vastaa TETRA-verkossa tavallista puhelinnumeroa. (K)loc SEPA (Kilo) Lines Of Code, koodirivien määrä (tuhansissa) (Software Engineering Practice), Kurssin vaatima selvitys käytettävästä menetelmästä 2.2 Yleiskatsaus projektiin Valpas Nykypäivänä viranomaiset ovat asettaneet vaatimuksia palohälyttimille, joita on pakko olla julkisissa ja riittävän isoissa rakennuksissa. Hälyttimiä tulee voida tarkkailla ja varmistaa 3
luotettavasti niiden toimivuus. Rakennettava järjestelmä, Valpas, vastaa tähän tarpeeseen ja toteuttaa kyseisen toiminnallisuuden Tetra-verkossa. Projektin tarkoitus on ensimmäisessä vaiheessa toteuttaa prototyyppi järjestelmästä, jonka perusteella voidaan tarpeen mukaan jatkokehittää kaupallinen tuote. Kuva 1: Projektissa toteutettava järjestelmä Projektin tarkoituksena on kehittää TETRA-verkon päällä toimiva simulaatio, jolla on tarkoitus testata tulevaisuudessa toimivaa järjestelmää. TETRA-puhelin voidaan yhdistää sarjaportin kautta PC:hen, jolloin puhelinta voidaan käyttää AT Command Interfacen avulla. Tämä PC simuloi ilmoitinkeskusta ja laskee perille tulleita viestejä ja lähetettyjä viestejä. TETRA-verkon toisella laidalla on EPA, joka tarjoaa palveluita rakennettavalle Valppaalle. EPA:n kautta Valpas pystyy lähettämään ja vastaanottamaan SDS-viestejä. Tärkeää projektin kannalta on pystyä tilastoimaan järjestelmän luotettavuutta. Lisäksi Valppaaseen tarvitaan WWW-palvelu, jolla järjestelmän toimintaa voidaan ylläpitää. Toiminnallisuus tullaan toteuttamaan Java-ohjelmointikielellä. 4
3 Sidosryhmät ja jäsenet Projekti on tarkoitus suorittaa kahdeksan opiskelijaa käsittävällä projektiryhmällä. Projektiryhmän jäsenillä on erilaisia rooleja käsittäen yleisimmät ohjelmistoprojektin roolit. Tehtäviä on mahdollista vaihtaa projektin edetessä jos ryhmältä siihen kiinnostusta löytyy. Projektin muita sidosryhmiä ovat asiakas, Indagon Oy, tekninen neuvoja, kurssin henkilökunta (Mentor, luennoitsija) sekä laatupalkinnon jakava edustaja Accenture Oy:stä. 3.1 Organisaatiokaavio Kuvassa 2 on esitetty projektin organisaatiokaavio ja projektin sidosryhmät. Täydelliset yhteystiedot löytyvät projektin kotisivuilta (Wiki) ja ne on jätetty tästä dokumentista pois tarkoituksella. Tästä dokumentista löytyvät kuitenkin projektiin osallistuvien henkilöiden sähköpostiosoitteet. 5
6 T-76.4110 Ohjelmistoprojekti I
Kuva 2: Sidosryhmien väliset riippuvuudet 3.2 Yhteystiedot Projektin Wiki löytyy osoitteesta http://rivendell.tky.hut.fi/projekti/ ja vaatii käyttäjältään käyttäjätunnuksen ja salasanan. Seuraavassa taulukossa on listattu projektiin osallistuvien henkilöiden toimenkuvat sekä sähköpostiosoitteet. Taulukko 2: Yhteystiedot Nimike Nimi Email Luennoitsija Jari Vanhanen jari.vanhanen#hut.fi Laatupalkinto Vesa Luomala vesa.luomala#accenture.com Mentor Kari Suhonen kari.suhonen#hut.fi Asiakas Mikko Weckström mikko.weckstrom#indagon.com Tekninen neuvoja Pete Lyly peteveikko.lyly#everkot.fi Projektipäällikkö Markus Kattilamäki markus.kattilamaki#hut.fi Pääarkkitehti Tuukka Laakso tjlaakso#cc.hut.fi Laatupäällikkö Kirsi Rönkkö catangel#iki.fi Kehittäjä Mikko Halttunen mikko.halttunen#hut.fi Kehittäjä Markku Huttunen mahuttun#cc.hut.fi Kehittäjä Antti Kettunen ajkettun#niksula.hut.fi Kehittäjä Mikko Närjänen mtnarjan#cc.hut.fi Testaaja Antti Poikela aspoikel#cc.hut.fi 7
4 Tavoitteet ja lopettamiskriteerit Projektin tavoitteena on rakentaa prototyyppi, jonka avulla voidaan selvittää tuotteen kaupalliset ja jatkokehitykseen liittyvät näkymät. Projektiryhmälle kurssi toimii opetuksellisena harjoitustyönä, tarkoituksena syventää näkemystä ohjelmistoprojektiin ja erilaisiin ohjelmistoprojektille ominaisiin menetelmiin ja rooleihin. 4.1 Asiakkaan tavoitteet Seuraavaan taulukkoon on kirjattu asiakkaan tavoitteet projektille tärkeysjärjestykseen. Täyttymiskriteeriä verrataan projektin aikaansaannoksiin ja sen perusteella voidaan mitata tavoitteen täyttyminen. Asiakkaan tavoitteita ei voida katsoa täyttyväksi projektiryhmän toimesta. Asiakas määrittelee tavoitteiden täyttymisen projektin päätyttyä. Taulukko 3: Asiakkaan tavoitteet ID Tavoite Täyttymiskriteeri A1 Mahdollinen kaupallinen tuote tuhansille käyttäjille Prototyypin onnistunut toteuttaminen ja sen soveltuminen jatkokehitykseen. A2 Tetra-verkon käytettävyyden lisäselvitys A3 Kaupallistamisen selvittäminen A4 Aihealueesta oppiminen ja tietämyksen laajentaminen asiakkaan taholta A5 Asiakkaan ohjelmistoprosessin kehittäminen A6 Teknisen neuvojan tavoitteena lopputyön tekeminen aiheesta Prototyypin toimivuus ja skaalautuvuus sekä Tetra-verkon soveltuvuus käyttötarkoitukseen. Prototyypin toimivuus ja sopivuus sekä kaupalliset näkymät. Projekti tuo organisaatioon uutta osaamista ja tietoa aihealueesta. Asiakkaan prosessien kehittyminen ja menetelmien oppiminen. Projekti auttaa ja mahdollistaa lisätietoa aiheesta. Projektin hyödyllisyyden arvio lopussa teknisen neuvojan toimesta. 4.2 Projektiryhmän tavoitteet Seuraavassa taulukossa on listattu projektiryhmän tavoitteet projektille ja tavoitteiden täyttymiskriteerit. Tavoitteet ovat projektiryhmän yhteisiä, projektin alussa sille asetettuja tavoitteita. Taulukko 4: Projektiryhmän tavoitteet ID Tavoite Täyttymiskriteeri R1 Opintosuoritus hyvällä arvosanalla Kurssin suoritus vähintään arvosanalla 4 8
R2 Aihealueesta oppiminen R3 Laajemmassa ohjelmistoprojektissa toimiminen R4 Laadukkaan ja asiakkaalle arvoa tuottavan ohjelmiston toimittaminen R5 Projektin loppuun saattaminen Oppimiskokemusten kerääminen projektin jälkeen, oppimisen toteaminen Projektin tyydyttävä suoritus Asiakas päättää projektin perusteella jatkokehittää tuotetta Kurssin laajuuden täyttäminen ja suoritusmerkinnän saaminen 4.3 Henkilökohtaiset oppimistavoitteet Projektin oppimistavoitteiden seuraamisen kannalta jokainen projektiryhmän jäsen on listannut omat oppimistavoitteensa ja odotuksensa projektista. Henkilökohtaiset oppimistavoitteet on listattu seuraavassa taulukossa. Taulukko 5: Henkilökohtaiset oppimistavoitteet Jäsen Oppimistavoite Kattilamäki Saada kokemusta ohjelmistoprojektin vetämisestä ja oppia tehokkaita menetelmiä projektin läpiviemiseksi. Laajentaa näkemystä ohjelmistoprojektista ja sen eri vaiheista. Laakso Rönkkö Huttunen Poikela Närjänen Halttunen Kettunen Oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä Oppia vetämään projektia paremmin, hallitsemaan sitä sekä oppia laadunvarmistukseen liittyviä asioita. Lisäksi tavoitteena on kehittyä testauksen saralla sekä oppia luottamaan enemmän muiden työhön ja keskittyä paremmin omaan. Uusien tekniikoiden oppiminen, kommunikointi laajemmassa projektissa sekä oman ajankäytön ja arvioinnin parempi hallitseminen Aiemman testauskokemuksen puuttuessa pääasiallisena tavoitteenani on oppia rooliin kuuluvat tehtävät ja käytännöt. Projektin koko tuo mukanaan haasteita, joten oppia projektin kulkuun vaikuttavista asioista, esimerkiksi tiimin sisäisestä kommunikoinnista ja asiakkaan kanssa toimimisesta. Ryhmätyötaitojen kehittäminen, laajemman projektin toimintaan tutustuminen, uusien työkalujen (Borland Together, JUnit, jne.) käytön oppiminen, ohjelmointitaitojen kehittäminen. Laajentaa tietoani ohjelmistoprojekteiden kulusta ja päästä kokeilemaan sellaisessa mukana olemista. Yksikkötestauksen oppiminen ja käyttäminen. Oppia soveltamaan käytännössä uusia ohjelmiston tuottamisen käytäntöjä sekä oppia niiden käyttökelpoisuus erilaisissa tilanteissa. 4.4 Projektin keskeytys- ja lopetuskriteerit Projekti ja kurssin suorittaminen voidaan keskeyttää ryhmän yhteisellä päätöksellä jos jokin seuraavista tilanteista toteutuu 9
Prototyyppi ei vastaa jatkokehityksen vaatimuksia Asiakas lopettaa projektin Kaksi tai useampi henkilö jättää ryhmän Kurssia ei ole enää mahdollista läpäistä Projekti päättyy viimeisen iteraation päätyttyä 2.3.2006. Tällöin dokumentit ja lopputuote toimitetaan asiakkaalle kaikissa tapauksissa. Projektin päättymiskriteerit ennen projektin määräpäivää ovat: Käytettävän työmäärän täyttyminen Projektin valmistuminen ennen määräpäivää 5 Resurssit ja budjetti Seuraavassa on esitetty projektin käytössä olevat resurssit ja budjetoitu niiden käyttö. Projektin budjetti on suunniteltu osa-alueittain sekä henkilöiden työtunneittain. Budjetit ja arviot on esitetty seuraavassa. Taulukko 6: Arvio ajankäytöstä PP PP tot. I1 I2 yht. Suunnittelu 50 17 46 22 85 Dokumentointi 64,8 55 52 95 202 Infrastruktuuri 4,4 6 30 10 46 Luento 40,8 55,5 0 0 55,5 Palaveri 40 33 96 95 224 Ohjelmointi 0 0 209 210 419 Hallinnointi 20 27,5 33 45,2 105,7 Opiskelu 20 12,5 25 17,2 54,7 Testaus 0 1 85 56,6 142,6 Kommunikaatio 5 5,5 5 5 15,5 Muu 5 0 5 5 10 Yhteensä 250 213 586 561 1360 Taulukon arvioiden pohjana on ollut kurssin edellisten vuosien tuntimäärien jakautuminen tehtävien kesken, projektin edellisten vaiheiden realisoituminen sekä kirjallisuuden antamat esitykset sopivasta tuntien jakautumisesta projektin kesken. 5.1 Henkilökunta Projektiryhmän jäsenille on budjetoitu seuraavan taulukon mukainen työmäärä kuhunkin iteraatioon. Arviota päivitetään realisoituneiden tuntien mukaisesti. Jokaisen tulee pyrkiä täyttämään iteraatiolle varatut tunnit jotta työ ei kasaudu. Jokainen on laatinut myös viikoittaisen tuntisuunnitelman jonka toteutumista projektipäällikkö seuraa. 10
Taulukko 7: Iteraatioiden arvioidut työmäärät Henkilö I0 I1 I2 Yhteensä Kattilamäki 83 45 42 170 Rönkkö 60 55 55 170 Laakso 31,5 69 69,5 170 Halttunen 3 87 80 170 Huttunen 5,5 85 79,5 170 Kettunen 12,5 80 77,5 170 Närjänen 6 85 79 170 Poikela 11,5 80 78,5 170 213 586 561 1360 5.2 Materiaali Projektin kehitystyö tullaan pääosin suorittamaan projektiryhmän omilla laitteistoilla. Lisäksi ryhmällä on käytettävissään Teknillisen Korkeakoulun opiskelijoilleen tarjoamat laitteistot ja palvelut (ATK-keskus ja Niksula). Paras mahdollinen tilanne olisi että jokaisella projektiin osallistuvalla olisi käytössään samanlainen kehitysympäristö ja alusta. Tämä on käytännössä mahdollista koulun tarjoamia koneita käyttäen. Emme voi kuitenkaan vaatia ainoastaan niiden käyttöä kehitystyössä. Ympäristöissä ja työkaluissa pyritään mahdollisimman samankaltaiseen asetteluun. Indagon Oy mahdollistaa projektille testilaitteistoa ohjelmiston testausta varten. Laitteiston tulisi olla käytettävissä viimeistään 20.11.2005 1 kpl kannettava tietokone (Käytössä iteraatiodemon ajan) 1-3 kpl Tetra-verkon puhelinta 5.3 Budjetti Seuraavassa taulukossa on esitetty projektin teoreettinen budjetti. Se on laskettu arvioita käyttäen eikä asiakasta laskelman mukaisesti veloiteta. Osa kuluista kuten asiakkaan omat tunnit ja asiakkaan tarjoamat materiaalit tuottavat asiakkaalle oikeita kuluja. Kurssi veloittaa asiakkaalta myös osallistumismaksun. Taulukko 8: Teoreettinen kustannuslaskelma Kustannuserä Yksikköhinta Määrä Summa Projektiryhmän työ 50 e/h 1360 h 68 000 e Asiakkaan käyttämät tunnit 50 e/h 200 h 10 000 e Asiakkaan materiaalikulut Yhteensä: 5000 e 83 000 e 11
Vastaavanlainen projekti tulisi arvioiden mukaan maksamaan 83 000 euroa asiakkaalle suurimpana menoeränään henkilöstökulut. Henkilöstökulut ovat laskettu kuitenkin varsin maltillisesti. Riippuen projektia tuottavan yrityksen sisäisistä kuluista ei ko. hinnalla kovin suuri voittomarginaali ole mahdollinen. 6 Työkalut ja menetelmät Kappaleessa käydään läpi projektissa käytettävät työkalut sekä kurssin vaatimat käytännöt projektin toteutuksessa. Lisäksi kurssin T-76.5633 Ohjelmistotuotannon erikoiskurssin vaatimuksen mukaiset SEPA-päiväkirjojen aiheet listataan luvussa. 6.1 Menetelmät Luku käsittelee projektissa käytetyt menetelmät, käytännöt ja työkalut. Osa menetelmistä on pakollisia kurssin puolesta ja niiden käyttö on arvostelun lähtökohtana. 6.1.1 Iteratiivinen kehittäminen Projekti tullaan kehittämään kolmessa iteraatiossa: Projektin suunnittelu (PP) - Projektin alustus ja suunnitelmat Implementaatio 1 (I1) - Tärkein toiminnallisuus Implementaatio 2 (I2) - Toiminnallisuuden integrointi, käyttöliittymä ja luovutus Jokaisen iteraation alussa karkealla tasolla suunnitellut tehtävät jaetaan pienempiin ja hallittavampiin osakokonaisuuksiin asiakkaan vaatimuksia kuunnellen. Perustana iteraation suunnitteluun on vaatimusmäärittely sekä tekniset määrittelyt joiden ajantasaisuus tarkistetaan asiakkaan kanssa ennen iteraation alkua. Iteraation pitää sisällään viikon mittaisia syklejä, joissa kyetään toteuttamaan ja seuraamaan projektia. Tämä tarkoittaa osaltaan sitä, että palavereissa hahmotetaan ja jaetaan seuraavan viikon työ ja seurataan sen edistymistä sekä tehtäväkohtaisesti että tunneittain sekä päätetään mahdolliset korjaavat toimenpiteet. Asiakkaalla on mahdollisuus viikoittaisen seurannan lisäksi (Projektin edistyminen on nähtävillä seuranta osiossa Wikissä keskiviikkoisin) tarkastaa jokaisen iteraation tuotokset iteraation lopulla järjestettävässä iteraatiodemossa. Jokaisen iteraation lopulla ryhmällä on esittää sovitun toiminnallisuuden sisältävä ja testattu ohjelmakokonaisuus. Tehtävä työ pyritään suunnittelemaan ja sopimaan mahdollisimman tarkasti ennen iteraation alkua, jotta iteraation aikana suuremmilta muutoksilta vältytään. Tällä osaltaan taataan kehittäjille työrauha ja edesautetaan asiakasta miettimään tarpeitaan mahdollisimman tarkasti. 6.1.2 Iteraatiosuunnittelu Ennen iteraatiota tai sen alussa pidetään asiakkaan kanssa palaveri jossa sovitaan ennalta mietittyjen kokonaisuuksien toteuttamisesta, vaatimusten priorisoinnista ja niiden toteuttamisesta sekä tulevan iteraation näkymistä. Toinen palaveri pyritään pitämään iteraation aikana, jolloin projektin eteneminen ja sovitut asiat tarkistetaan. Iteraation lopullinen tilannekatsaus pidetään jokaisen iteraation lopulla iteraatiodemossa. Iteraatioon kuuluvien tehtävien tarkempi työmääräarvio tehdään ennen päätöstä toteutettavista komponenteista, jotta asiakkaalla on mahdollisuus vaikuttaa budjetin mukaisesti iteraation 12
tehtäviin. Projektin budjetointi ja tehtävien ajastuksen vastuu on projektipäälliköllä. Pääarkkitehti hyväksyy iteraatiosuunnitelman työkokonaisuudet ja niiden ajastuksen. 6.1.3 Dokumentointi Projektipäällikön vastuulla on projektisuunnitelma, edistymisraportti ja iteraatiosuunnitelma. Laatupäällikkö vastaa vaatimusdokumentista ja testaukseen liittyvistä muista dokumenteista. (katselmointidokumentti, testaussuunnitelma, yms.) Pääarkkitehdin vastuulla on arkkitehtuuridokumentti. Dokumentit tuotetaan ensisijaisesti Wikiin jotta kaikilla on mahdollisuus tutustua niiden sisältöön jo kehitysvaiheessa. Lähempänä määräpäivää ne katselmoidaan ja hyväksyvän päätöksen jälkeen ne vedostetaan pdfformaattiin. Ennen julkaisua asiakas hyväksyy vielä dokumentin sisällön. Projektipäällikkö vastaa dokumenttien lopullisesta hyväksymisestä ja on vastuussa niiden jakelusta ja palauttamisesta. Dokumenteissa ja Wikissä olevat kuvat tuotetaan png-formaattiin. Dokumentin luoja on vastuussa myös siitä, että viimeisin versio ja palautettu versio ovat saatavilla Wikissä. Dokumenttikohtaisesti voidaan niiden tehtäviä jakaa. Jakamisesta ja koostamisesta vastaa kokonaisuudessaan projektiryhmä 6.1.4 Tuntiraportointi Jokaisen henkilökohtaiset tunnit raportoidaan Wikiin välittömästi kyseisen tehtävän suorittamisen jälkeen. Tuntilistaan merkitään tehtävän osa-alue ja Wikin seuranta osiosta löytyvä tehtävä sekä mahdollinen kuvaus. Viikoittainen tuntiseuranta tapahtuu projektipäällikön toimesta tiistaisin, jolloin tärkeimmät mittarit ovat seurattavissa Seurantasivulla. Samalta sivulta voidaan seurata myös yksittäisten tehtävien ajankäyttöä verrattuna suunniteltuun. Projektipäällikkö vastaa myös tehtävien luomisesta ja päivittämisestä. 6.1.5 Ohjelmiston koon raportointi Borland Together kerää automaattista statiikkaan projektin lähdekoodista ja generoi niistä myös valmiita kaavioita. Alustavasti projektin kokoa tullaan seuraamaan koodirivien määrällä (yksikkö Kloc). Projektin edetessä tulee miettiä seurannan muita tarpeita ja työkalun niihin tarjoamia mahdollisuuksia. Pääarkkitehti on vastuussa tarpeellisten statistiikkojen tuottamisesta ja esittelemisestä johtoryhmän viikkopalaverissa. Projektipäällikkö seuraa kehitystä ja päättää mahdollisista toimenpiteistä yhdessä projektin johtoryhmän kanssa. 6.1.6 Kommunikaatio Projektilla on käytössään useita kommunikaatiokanavia. Ensisijainen kanava projektin jäsenten kesken ovat viikoittaiset palaverit (Projektin johtoryhmällä omansa ja pääarkkitehdin järjestämänä kehittäjille omansa). Muita kanavia ovat IRC (#softarojekti) johtoryhmän käyttöön, (#simutiimi) simulaattoritiimin käyttöön, (#valpastiimi) valpastiimin käyttöön sekä #epa EPA:a käsitteleviä asioita varten. Sähköpostin käytössä oleellista on harkita kenelle kaikille tieto on tarpeellinen ja osoittaa posti ainoastaan heille. Sähköpostissa TO-kenttään laitetaan sellaiset henkilöt joilta odotetaan toimenpiteitä. CCkenttään laitettaville sähköposti menee tiedoksi. Projektipäälliköllä on myös käytössä 20 tekstiviestiä päivittäin ryhmän sisäiseen nopeaa reagointia tai kriittistä informaatiota varten. Kommunikaatiokanavat on koottu seuraavaan taulukkoon odotetun vastausajan 13
perusteella. Taulukosta voidaan myös johtaa aikavälit joiden sisällä ryhmän jäsenen tulisi olla tavoitettavissa kussakin mediassa. Taulukko 9: Kommunikaatiokanavat ja vasteajat Kanava Odotettu vasteaika Kohderyhmä Puhelu Välitön - muutama tunti Kahdenkeskinen asia Tekstiviesti Välitön - muutama tunti Yksilö - Koko ryhmä IRC Välitön - vuorokausi Yksilö - Koko ryhmä Sähköposti Vuorokausi Yksilö - Projektin osaryhmä Wiki Yli vuorokausi Koko ryhmä Kyseisiä kanavia voidaan käyttää kommunikointiin myös ryhmän ulkopuolelle. Asiakkaalta ja Mentorilta odotetaan myös vastaavia vasteaikoja. Mentoriin ensisijaisesti on yhteydessä projektipäällikkö ja asiakkaaseen laatu- tai projektipäällikkö. Jokaisesta palaverista sen järjestämisesta vastuussa oleva henkilö kirjoittaa pöytäkirjan tai vapaamuotoisemman palaverimuistion. Muistiot lisätään Wikiin, SovitutPalaverit sivun alle. Projektipäällikkö lähettää asiakkaalle ja mentorille keskiviikkoon mennessä viikkoraportin edistymisestä ja tulevan viikon näkymistä. 6.1.7 Iteraatiodemo Projektipäällikkö vastaa iteraatiodemon järjestämisestä, kutsuu asianosaiset paikalle ja toimii iteraatiodemossa puheenjohtajana. Projektipäällikkö vastaa myös tilaisuudessa tarvittavasta materiaalista. Laatupäällikön vastuulla on järjestää iteraatiodemossa tuotteen esittely, varmistaa esityksen onnistuminen ja hankkia tarvittavat laitteet paikalle. Pääarkkitehti kertaa iteraation tuotannolliset asiat, tekniset yksityiskohdat ja oleelliset muutokset tuotteeseen ja arkkitehtuuriin. 6.1.8 Virheiden seuranta Virheiden seurantaan käytetään kurssin tarjoamaa Bugzilla-ohjelmistoa. Laatupäälliköllä on ensisijainen vastuu virheiden seurannasta ja menetelmän käytöstä. Kattavampi kuvaus virheiden seurannasta löytyy tämän dokumentin kappaleesta laadunvarmistussuunnitelma. 6.1.9 Versionhallinta Versionhallintaan käytetään Niksulan tarjoamaa CVS-työkalua (Concurrent Versions System). Repositorio sijaitsee koulun ympäristössä ja on täten ryhmäläisten tavoitettavissa. Ohje CVS:n käyttämiseksi löytyy Wikistä. Työkalu on valittu sen toiminnallisuuden ja tuttuuden takia. CVS:n käytössä noudatetaan seuraavia käytäntöjä: Vain valmiit ominaisuudet ja kääntyvä koodi päivitetään repositorioon. Muutokset kirjataan dokumentin muutoshistoriaan. Check-in tehdään selkeän kokonaisuuden jälkeen (Usean paikan muuttaminen yhdellä commitilla ei toivottavaaa) 14
6.1.10 Ohjelmointikäytännöt Yleisesti käytetään koodauskäytäntönä SUN:in esittelemää käytäntöä http://java.sun.com/docs/codeconv/html/codeconvtoc.doc.html Lisäksi käytämme seuraavia käytäntöjä: Koodin kommentointi Javadoc-kommentointi o Jokaiselle luokalle o Jokaiselle metodille o Jokaiselle tärkeälle muuttujalle Geneeristä kommentointia o Luokan alkuun luonti- ja lyhyet muuttamistiedot (kuka, mitä, milloin?) o Yli viiden rivin metodiin selventäviä kommentteja mukaan Koodin ulkoasu Sisennys 4 välilyöntiä (ei tabulaattoria) Rivinleveys 80 merkkiä Vältetään yli sivun mittaisia metodeja Metodi- ja muuttujakutsuihin suorittaja eteen (this, super), ellei kyseessä ole staattinen metodi. 6.1.11 SEPA - Heuristinen arviointi Heuristinen arviointi on tuotteen tai käyttöliittymän arviointia ilman käyttäjiä tiettyihin käytettävyyssääntöihin vertaamalla. Heuristinen arvio tulisi tehdä 3-5 asiantuntijan voimin. Heuristisella arvioinnilla haetaan lopputuotteen hyvää käytettävyyttä. Projektissa menetelmää tullaan käyttämään ainakin ensimmäisen iteraation alussa prototyypin arviointiin ja parantamiseen sekä lopussa edesauttamaan käyttöliittymän kehittämistä. 6.1.12 SEPA Design patterns Suunnittelumallit (Design Patterns) ovat ohjelmiston rakenteen suunnittelussa hyväksi havaittuja yleisiä malleja. Suunnittelumallit toimivat arkkitehdin apuna suunnittelutyössä. SEPA tulee käsittelemään ns. Gang-of-Four suunnittelumalleja joita ovat mm. adapter, factory ja facade. 6.1.13 SEPA Staattiset metodit Käytännöllä staattiset metodit tarkoitetaan ohjelmiston (esim. lähdekoodin) analysointia ilman että sitä ajetaan. Staattisten metodien analyysi voi olla esimerkiksi koodikatselmuksien suorittamista. Tarkoituksena on mitata, analysoida ja parantaa ohjelmiston rakennetta sekä löytää siinä ilmeneviä virheitä. Projektin kontekstissa ohjelmiston kriittisiä osia tullaan katselmoimaan muiden tuotosten ohella. 6.1.14 SEPA Refaktorointi Refactoring tarkoittaa ohjelmakoodin rakenteen muuttamista ilman sen toiminnallisuuden muuttamista. Tällä tavoitellaan selkeämpää, luettavampaa ja ylläpidettävämpää koodia 15
lyhyemmässä ja alkuperäistä paremmassa muodossa. Projektin kannalta nämä ominaisuudet ovat varsin tärkeitä asiakkaan jatkokehityksen kannalta. Tarkoituksena on suorittaa refaktorointia jatkuvasti kehityksen aikana. Hyvä käytäntö on tarkistaa refaktorointitarve jokaisen metodin kirjoittamisen jälkeen ja työskentelyjakson päätyttyä. Näin koodin toiminnallisuutta ei tarvitse välttämättä kerrata. Yksinkertaisimmillaan refaktorointi voi olla esim. koodin muotoilu konventioiden mukaiseksi metodin kirjoittamisen jälkeen. 6.2 Työkalut Projektissa tullaan käyttämään seuraavan taulukon mukaisesti listaamia työkaluja. Listaus löytyy myös projektin Wikistä jossa listattu myös mahdollinen käyttöohje ja henkilö joka hallitsee työkalun käytön. Taulukko 10: Käytetyt työkalut Nimi Versio Lähde Tarkoitus Apache Ant http://ant.apache.org/ Kääntäjä CVS http://cvsbook.redbean.com/cvsbook.html Versionhallinta Jetty http://jetty.mortbay.org/jetty/ Www-palvelin Log4j http://logging.apache.org/log4j/ Ohjelman toiminnan raportoija JUnit http://www.junit.org/ Testaustyökalu MagicDraw http://www.magicdraw.com/ UML-työkalu Eclipse http://www.eclipse.org/ Koodin kehitystyökalu javadoc http://java.sun.com/j2se/javadoc/ Kommentointi Wiki http://moinmoin.wikiwikiweb.de/ Tiedon välittäminen ja ylläpitäminen Irc http://www.irc.org/ Kommunikointi Cobertura http://cobertura.sourceforge.net/ Testien kattavuuden mittaaja Borland Together Architect 2006 http://www.borland.com/us/ products/together/index.html Asennusohjeet kurssin kotisivuilla Tools-valikon alla. Hibernate 3.0.5 http://www.hibernate.org/ Tietokannan käsittely Quartz 1.5.1 http://www.opensymphony.com/quartz/ Skeduloija Spring Framework 1.2.5 http://www.springframework.org/ UI Framework 6.3 Standardit ja protokollat Standardeja tullaan päivittämään projektin kuluessa. Tähän mennessä mainittavan arvoiset käytettävät standardit tai protokollat ovat: TETRA (Terrestrial Trunked Radio) 16
LIP (Location Information Protocol) o Paikkatiedon välitys TETRA-verkossa HTML 4.01 (HyperText Markup Language) o Vaihtoehtoisesti XHTML 1.0 Säädökset palovaroittimien valvomiselle 7 Jaksotus Projekti on jaettu kolmeen iteraatioon. Seuraavassa luvussa kuvataan iteraatioiden tavoitteet, tuotokset, tehtävät sekä niiden työarviot ja tärkeät päivämäärät iteraation aikana. 7.1 Huomioitavaa Kurssin mahdollistama joululoma 8.12.2005 16.1.2005. Loman käyttämisestä sovitaan I1 lopussa Aikavälillä 22.12.2005 26.12.2005 projektia ei toteuteta Tuukka Laakso mahdollisesti lomamatkalla 1.1.2006-14.1.2006 Joululomalla useat lyhyemmillä matkoilla tai lomalla 7.2 Aikataulu Seuraavassa on listattu projektin kolmen osan aikataulu. On huomioitava että vuoden 2005 lopussa on kurssin mahdollistama joululoma jonka käytöstä sovitaan etukäteen. näyttää siltä että lomaa lyhennetään kurssin mahdollistamasta osallistujien riittämättömän ajankäytön takia. Taulukko 11: Projektin Suunnittelu (27.9.- 20.10.2005) Päivä Kello Tapahtuma Selitys Osallistujat 27.9.2005 11.30 Viikkopalaveri Johtoryhmä 27.9.2005 16.15 Luento Software process, project planning 3.10.2005 13.00 Palautus Iteraatiosuunnitelma 4.10.2005 16.15 Luento Requirements management 9.10.2005 18.00 Vaatimusmäärittely Ensimmäinen versio valmis 11.10.2005 16.15 Luento Borland's development tools 15.10.2005 18.00 Arkkitehtuuri Iteraation arkkitehtuuri valmis 17.10.2005 13.00 Palautus Projektisuunnitelma, Vaatimusdokumentti, Edistymisraportti 18.10.2005 16.15 Luento Quality assurance 19.10.2005 Iteraatiodemo Mentor, Asiakas Taulukko 12: Implementaatio 1 (21.10.- 8.12.2005) 17
Päivä Kello Tapahtuma Selitys Osallistujat 26.10.2005 19.00 Projektin Kick-off Projektiryhmä 31.10.2005 13.00 Iteraatiosuunnitelman Iteraatio- ja QAsuunnitelma Markus, Kirsi palautus 2. - 3.11.2005 Mentor-tapaaminen Johtoryhmä 27.11.2005 13.00 Iteraation toiminnallisuus valmis 5.12.2005 13.00 Palautus SEPA-päiväkirjat Kaikki 5.12.2005 13.00 Palautus Kts. kurssin sivut 7. - 8.12.2005 Iteraatiodemo Johtoryhmä, asiakas, Menor 9.12.2005 - Joululoma Päätetään Kaikki 15.1.2006 muöhemmin 22.12.2005-26.12.2005 Pakollinen joululoma Kaikki Taulukko 13: Implementaatio 2 (16.1. - 2.3.2006) Päivä Kello Tapahtuma Selitys Osallistujat 18.1.2006 13.00 Palautus Iteraatio- ja QAsuunnitelma Kattilamäki, Rönkkö 1. - 3.2.2006 Iteraatiodemo 10.2.2006 13.00 Järjestelmän toiminnallisuus valmis 17.2.2006 13.00 Vertaistestaukseen luovutus 21.2.2006 13.00 Vertaistestauksen palaute Edistymisen seuraus Lopullinen järjestelmä ja ohjeet Palaute vertaisryhmälle Rönkkö Rönkkö 27.2.2006 13.00 Dokumenttien palautus Johtoryhmä 1. - Iteraatiodemot Mentor, Asiakas, 2.3.2006 Projektiryhmä 3. - 4.3.2006 Project Close-Out Party Taulukko 14: Testauksen aikataulu Projektiryhmä, Asiakas, Mentor Päivä/Viikko Mitä valmiina päivän lopussa/kyseisen viikon perjantaina? Viikko 44 Testeissä tarvittavat stubit Viikko 45 Testitapaukset Viikko 46 Automatisoidut intergointi testit Viikko 47 25.11.2005 Järjestelmän kehitys, noin viikko aikaa korjata löydetyt onglemat. Viikko 48 Systeemitason testaus 18
7.3 Projektin suunnittelu (PP) Projektin suunnitteluvaiheen tavoitteena on Aihealueen ymmärtäminen Asiakaskontaktin luominen Projektin alkuun saattaminen Alustava arkkitehtuuri Vaatimusmäärittely Laadunvarmistuksen suunnittelu Taulukko 15: Projektin suunnitteluvaiheen tehtävät 19
Kuva 3 - Projektin suunnitteluvaiheen aikataulu 7.4 Implementaatio 2 (I2) Projektin toisen iteraation tavoitteena on Laadukkaan lopputuotteen toimittaminen asiakkaalle Projektin oppien kokoaminen Toiminnallisuuksien integrointi Mahdollisen jatkokehityksen edistäminen (dokumentaatio, käyttöohje) Käyttöliittymän toteuttaminen Kurssin tavoitteellinen suorittaminen 8 Riskienhallinta Seuraavassa kappaleessa käsitellään projektiin liittyviä riskejä, niiden huomioimista, seurantaa ja torjuntaa. Riskienhallinnan päävastuu on projektipäälliköllä yhdessä johtoryhmän kanssa. Riskien seuranta tapahtuu viikoittain ja tulokset käsitellään johtoryhmän palaverissa. 20
8.1 Prosessi Oleellisena osana projektin seurantaa on riskien hallinta. Päävastuu riskien hallinnasta ja seurannasta kuuluu projektipäällikölle. Riskejä seurataan viikoittain johtoryhmän viikkopalaverissa ja projektipäällikkö päättää seuraavista toimenpiteistä. Jokaisen projektiin osallistuvan henkilön velvollisuus on ilmoittaa havaitsemastaan uudesta riskistä viipymättä projektipäällikölle. Näin riski saadaan kartoitettua, siihen voidaan valmistautua ja vaikutusta minimoida. Oleellista riskien hallinnassa on tunnistaa riskit, arvioida niiden vaikutus sekä hallita ja tarkkailla niitä. Riskin alttius riippuu sen todennäköisyydestä ja vaikutuksesta. Näiden määreiden korkeat arvot tietyssä riskissä on kirjattu kuhunkin riskiin. Kuva 4 - Riskienhallintaprosessi Projektin aikana on mahdollista käydä toteen myös projektista riippumattomia riskejä joihin ei voida varautua tai se ei ole järkevää. (esim. poikkeustila, luonnonmullistus) Kyseisenlaisia riskejä ei ole listattu riskilokiin. 8.2 Riskikategoriat Riskin poistuttua riski poistetaan listalta, uudet riskit kirjataan. K = Kriittinen, T = Todennäköinen Taulukko 16: Top 5 riskit 21
ID Toimenpiteet poistamiseksi listalta Vastuu S3 Tehostetaan tuntisuunnitelmien tekemistä ja seurantaa Kattilamäki P5 Pyritään tekemään projektin alijäämä pois joululomalla Johtoryhmä K2 Asetetaan realistiset tavoitteet, tiedostetaan tekemisen ja arvostelun yhteys Projektiryhmä T4 Perehdytään pimennossa oleviin osa-alueisiin joululomalla Johtoryhmä K4 Huolehditaan asiakkaan kanssa I2 suunnitelmassa että tekemistä riittää Kattilamäki Taulukko 17: Asiakkaan riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö A2 A3 Asiakas ei ymmärrä projektin prosessia ja siihen liittyviä asioita riittävällä tasolla Asiakkaalla ei riitä aikaa ja kiinnostusta projektille Asiakkaan ja projektiryhmän näkemys projektista ristiriitainen Vaadittava palaute asiakkaalta jää saamatta ja projektin laatu kärsii Lisäämällä kommunikaatiota ja sen laatua yhtenäistetään näkemykset Pyritään sitouttamaan asiakas projektiin ja saamaan riittävästi palautetta Rönkkö Kattilamäki Taulukko 18: Teknologiaan liittyvät riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Verkko ei kestä Tuotteen jatkokehitys ei Asiakas hyödyntää kertyneen kokemuksen T2 K vaadittua kuormitusta mielekästä muuten Rönkkö T3 K Ryhmällä ei demottavaa tuotetta iteraatiodemossa Arvosanan aleneminen Huolehditaan hyvissä ajoin ennen demoa ongelmien poistamisesta Kattilamäki T4 T Ryhmän jäsenillä ei tarvittavan laajuista kokonaisnäkemystä tuotteeseen Kokonaisuuden kannalta vääränlaisten ratkaisujen toteuttaminen, ei pystytä korvaamaan toisen työtä Tutustutaan toisten suorittamiin töihin sekä tutustutaan järjestelmään kokonaisuutena Laakso Taulukko 19: Sidosryhmään liittyvät riskit 22
ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Sidosryhmillä ei ole tarpeeksi tietoa järjestelmän Järjestelmä ei vastaa Taataan kaikkien osapuolein vahva S1 K rakentamiseen odotuksia näkemys projektiin Kattilamäki S2 Projektiryhmästä keskeyttää useampi henkilö Työpanoksen ja tietotaidon menetys Tehtävien jakaminen ja projektin scopen muutos vastaamaan resursseja Kattilamäki S3 T Projektiin osallistujilla ei ole tarpeeksi aikaa projektille Projekti ei pysy aikataulussa eikä määriteltyjä tavoitteita saavuteta Projektin edistymistä ja osallistujien ajankäyttöä on seurattava tarkasti. Kriittisessä tilanteessa resurssien käyttö suunniteltava uudelleen Kattilamäki Taulukko 20: Projektinhallintaan liittyvät riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö P2 K P3 T P4 T P5 Alihankkija ei saa ajoissa toimitettua tarvittavia komponentteja Vaatimukset ovat puutteelliset Projekti ei pysy budjetissa Projekti ei etene suunnitellussa tahdissa Suunnittelu ja toteutus vaikeutuu ja myöhästyy Lopputuote ei vastaa asiakkaan tarpeita Ei pystytä vastaamaan asiakkaan vaatimuksiin Vaadittu tuntimäärä ei täyty ja projekti myöhästyy Toteutetaan mahdollisimman joustavia komponentteja ja rajapintoja Tarpeeksi lyhyt palautesykli, prototyyppien käyttö ja läpinäkyvä prosessi Vaatimusten priorisointi ja karsiminen Budjetin ja ajankäyttösuunnitelmien päivittäminen ja työtuntien kiristäminen Laakso Rönkkö Kattilamäki Kattilamäki Taulukko 21: Järjestelmään liittyvät riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Projektin lopputuote ei skaalaudu Projektin tarkoituksen menettäminen enne Kolmannen iteraation J1 K jatkotuotantoon toista iteraatiota työn varmistaminen Kattilamäki J2 K Virve ei sovellu projektin vaatimaan toimintaan Ei tarkoitusta jatkotuottaa projektia Taulukko 22: Kurssin suorittamiseen liittyvät riskit Varmistetaan Virven toiminnallisuus projektin kontekstissa Kattilamäki 23
ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Projektin laatu ei vastaa Motivaatio projektiin Tarkistetaan ryhmän motivaatiotaso ja tavoitteet ja johdetaan niistä projektin tuotteiden K2 T ryhmän tavoitteita laskee laatutaso Kattilamäki K3 K K4 K Kurssin asettamat vaatimukset eivät täyty Projektin laajuus ei riitä kattamaan kurssin vaatimaa työmäärää Epätyydyttävä kurssin arvosana tai kurssin suorittamisen epäonnistuminen Kurssin laajuus ei täyty Verrataan toimintaa ja tuotoksia kurssin vaatimuksiin ja reagoidaan mentorin antamaan palautteeseen Johtoryhmä Huolehditaan ennen I2 alkua tarpeellisen työmäärän sopimisesta asiakkaan kanssa Kattilamäki Taulukko 23: Lailliset & kaupalliset riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Dokumentit tarkisteaan ennen julkaisua ja rajataan kriittinen Erillisverkoille huono informaatio ulkopuolisilta L1 K maine (NDA) Kattilamäki L2 Projektista vuotaa kriittistä tietoa ulos Erillisverkkojen tuotteet sekoitetaan projektin tuotoksiin Erillisverkkojen myynin lasku Projektin selkeä nimeämiskäytäntö ja huhujen rajoittaminen Projektiryhmä L3 K Projektiryhmä rikkoo NDAta Mahdollinen haitta asiakkaalle ja rikkovan osapuolen vastuu Varmistetaan että kaikille osapuolille sopimuksen alainen aineisto on selvä ja rikkomustapauksissa neuvotellaan. TEKn jäsenillä mahdollisuus asianajajaan. Projektiryhmä Taulukko 24: Poistuneet riskit 24
ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Teknologioiden Soveltuvat teknologiat Teknologiavalinnat eivät muuttaminen syö valitaan projektin alussa T1 sovellu projektiin resursseja tarkasti Laakso P1 K1 A1 K,T Arkkitehtuurin alkuunsaattamisen kannalta tärkeiden vaatimusten etsintä kestää liian pitkään Johtoryhmä ei opiskelullaan pysty paikkaamaan osaamisessaan olevia puutteita 9 Lähteet Arkkitehtuuri myöhästyy Vaikutus näkyy projektin lopputoutteessa ja arvostelussa Asiakkaalta ei saada selkeitä, tai edes Projektia on vaikea selkeähköjä, vaatimuksia saada onnistumaan Toteutetaan arkkitehtuuria sen hetkisten vaatimusten perusteella ja tehdään siitä mahdollisimman helposti muutettava Ylimääräisen ajan käyttäminen opiskeluun ja neuvojen hankkimiseen Parannetaan kommunikaatiota ja vaatimusten määrittelyprosessia Laakso Johtoryhmä Rönkkö 1. "Software Project Management", Hughes, B. Cotterell, M. McGraw-Hill 2002, ISBN 00770 9834X 2. "Projektihallinnan käsikirja", Pelin, R. 1. painos Projektijohtaminen Oy 1996 3. "Software Engineering 7", Sommerville, I. ISBN 0-321-21026-3 4. "Object-Oriented and Classical Software Engineering", Schach, S. McGraw-Hill 2002 5. "An introduction to SEMS Approach", Rautiainen, R. Vähäniitty, J. 25