Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma

Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys 0.1 2006 10 04 Tuomo Mäkelä Pohja luotu 0.2 2006 10 06 Tuomo Mäkelä Kirjoitettu tekstiä kappaleisiin 2, 3 ja 5 0.3 2006 10 08 Janne Mäkelä Laajennettu kappaleita 1 ja 4 0.4 2006 10 16 Tuomo Mäkelä, Tatu Suurin osa kappaleista valmiina Frisk 0.5 2006 10 20 Tuomo Mäkelä Tavoitteet, tekstin korjailua 0.6 2006 10 22 Tuomo Mäkelä Kaikki kohdat paitsi vikojen seuranta ja vaatimusten hallinta 1.0 2006 10 23 Tuomo Mäkelä, Jani Eränen Projektin suunnitteluvaiheen lopullinen versio

Sisältö: 1 ESITTELY 4 1.1 Projektin esittely 4 1.2 Terminologia 4 2 SIDOSRYHMÄT JA PROJEKTIORGANISAATIO 5 2.1.1 Projektin sisäisen organisaation yhteystiedot sekä roolit 5 2.1.2 Asiakasorganisaation yhteystiedot 6 2.1.3 SoberIT:n valvonta ja tukiorganisaation yhteystiedot 7 2.1.4 Muut projektin sidosryhmät 7 3 TAVOITTEET 8 3.1 Projektin tavoitteet 8 3.2 Henkilökohtaiset oppimistavoitteet 9 4 RESURSSIT JA BUDJETTI 10 4.1 Henkilöstö 10 4.2 Materiaalit 10 4.3 Budjetti 10 5 KÄYTÄNNÖT JA TYÖKALUT 12 5.1 Käytännöt 12 5.1.1 Iteratiivinen kehitys 12 5.1.2 Iteraatiosuunnittelu 12 5.1.3 Dokumentointi 13 5.1.4 Riskien hallinta 13 5.1.5 Aikaraportointi 14 5.1.6 Kommunikaatio 14 5.1.7 Iteraatiodemo 15 5.1.8 Vikojen seuranta 15 5.1.9 Versionhallinta 16 5.1.10 Koodauskäytäntö 16 5.1.11 Prosessin kehittyminen 16 5.1.12 Vaatimusten hallinta 16 5.1.13 Suunnittelu 17 5.2 Laadunvarmistus suunnitelma 17 5.3 Työkalut 17 5.4 Standardit 18 6 VAIHEISTUS 18 6.1 Aikataulu 18 Good Minton 2 (23)

6.2 Projektin suunnittelu 19 6.2.1 Tavoitteet 19 6.2.2 Tuotokset 19 6.2.3 Tehtävät 19 6.3 Toteutus 1 (I1) 20 6.3.1 Tavoitteet 20 6.3.2 Tuotokset 20 6.3.3 Tehtävät 21 6.4 Toteutus 2 (I2) 21 6.4.1 Tavoitteet 21 6.4.2 Tuotokset 21 6.4.3 Tehtävät 21 7 RISKILOKI 22 Good Minton 3 (23)

1 Esittely 1.1 Projektin esittely Projektissa toteutetaan Suomen Sulkapalloliitolle uusi kilpailutoiminnan rekisteriohjelma. Kilpailujärjestelmän keskeisimmät toiminnot ovat ranking, pelaaja ja historiatietojen tuottaminen. Projekti tehdään kahdeksan hengen ryhmässä Teknillisen korkeakoulun kurssille T 76.4115/5115 Ohjelmistokehitysprojekti Toisin sanoen uudella kilpailujärjestelmällä mahdollistuu nopeampi ja luotettavampi pelaajatietojen siirtyminen seurasta järjestelmään ja takaisin. Kilpailuja järjestävät seurat löytävät järjestelmästä tuoreimmat tiedot kilpailuihin osallistuvista pelaajista ja toisaalta ne pystyvät päivittämään kilpailujen tulokset suoraan järjestelmään, mikä taasen takaa tuoreemmat tiedot seuraavaan kilpailuun. Käyttäjälle kilpailujärjestelmä näkyy web pohjaisena käyttöliittymänä, joka toteutetaan PHP:lla. Taustalla toimivan tietokannan ratkaisuna käytetään MySQL:ää. Vanha järjestelmä on kuluttanut erityisesti Suomen Sulkapalloliiton resursseja, kun liitossa on pidetty pelaajatietojen rekisteriä yllä osittain ns. manuaalisesti. Uudella järjestelmällä tämä työvaihe jää väliin, ja vapautuneet resurssit voidaan ohjata muun toiminnan kehittämiseen. 1.2 Terminologia Projektissa käytetään taulukossa 1 esitettyä terminologiaa. Projektissa käytetyt lyhenteet on esitetty taulukossa 2. Taulukko 1. Projektissa käytettävät termit Projektissa käytettävät termit Apache HTTP palvelinohjelma Asiakas Suomen Sulkapalloliitto Bugzilla Tietokoneohjelman virheiden raportointityökalu CVN Versionhallintaohjelmisto Doxygen Ohjelma, joka luo lähdekoodista automaattisen tiivistelmän Javadoc Lähdekoodin kommentointikonventio Mentor Kurssin asettama projektin neuvonantaja, valvoja ja arvostelija MySQL SQL tietokannan hallintajärjestelmä PHP Web palvelin ympäristöissä käytetty ohjelmointikieli Projektiryhmä Projektin sisäinen kahdeksan hengen ryhmä, joka tekee tuotteen Skype Ilmaisiin verkkopuheluihin tarkoitettu ilmainen tietokoneohjelma Smarty Mallinejärjestelmä, joka erottaa PHP:n ja HTML:n toisistaan TikiWiki Projektin kotisivuna käytettävä ryhmätyöskentelytyökalu UML Graafinen mallinnuskieli Taulukko 2. Projektissa käytettävät lyhenteet Projektissa käytettävät lyhenteet HK Nimikirjaimet, Henri Kostia JE Nimikirjaimet, Jani Eränen JM Nimikirjaimet, Janne Mäkelä OS Nimikirjaimet, Olavi Stenroos Good Minton 4 (23)

PP SE SEPA TF TH TM Nimikirjaimet, Petri Palmila Software engineering, ohjelmistotuotanto Software engineering personal assingment, kurssiin liittyvä ylimääräinen tehtävä, jossa tutkitaan jotain ohjelmistoprojektiin liittyvää menetelmää tarkemmin ja käytetään sitä projektissa. Nimikirjaimet, Tatu Frisk Nimikirjaimet, Timo Hassinen Nimikirjaimet, Tuomo Mäkelä 2 Sidosryhmät ja projektiorganisaatio Kuvassa 1 on esitetty projektin organisaatiokaavio. Kuva 1. Organisaatiokaavio 2.1.1 Projektin sisäisen organisaation yhteystiedot sekä roolit Projektiryhmä kostuu kolmen hengen johtoryhmästä, jossa ovat projektipäällikkö, laatujohtaja sekä arkkitehti. Tämän lisäksi ryhmässä on viisi kehittäjää. Jokainen kehittäjä on asetettu yhden johtoryhmän jäsenen avustajaksi erilliseen osaryhmään. Good Minton 5 (23)

Projektipäällikkönä on Tuomo Mäkelä ja hänen avustajanaan Janne Mäkelä. Projektiryhmän laatujohtajana toimii Jani Eränen ja hänen avustajinaan Timo Hassinen sekä Petri Palmila. Arkkitehtinä on Tatu Frisk, jonka avustajina ovat Henri Kostia sekä Olavi Stenroos. Osaryhmien kokoonpanoa voidaan myöhemmin muuttaa, jos työmäärien tasaaminen sitä vaatii, tai mikäli toisessa osaryhmässä on osaamista, jota toinen osaryhmä tarvitsee. Taulukko 3. Projektin sisäisen organisaation roolit ja yhteystiedot Nimi Rooli Tuomo Mäkelä Projektipäällikkö Jani Eränen Laatujohtaja Tatu Frisk Arkkitehti Janne Mäkelä Kehittäjä Timo Hassinen Kehittäjä Petri Palmila Kehittäjä Henri Kostia Kehittäjä Olavi Stenroos Kehittäjä Roolin tarkennus Erikoisosaaminen Vastaa puhtaasti projektin hallinnasta. Tuotantotalouden opiskelija. Ohjelmoinut työkseen PHP ja MySQLympäristöissä. Ohjelmoinut työkseen PHP ja MySQLympäristöissä. Projektipäällikön assistentti. Tuotantotalouden opiskelija. Laatujohtajan ryhmän jäsen. Vastaa testauksesta. Laatujohtajan ryhmän jäsen. Kehittäjä arkkitehdin ryhmässä. Ohjelmoinut työkseen PHP ja MySQLympäristöissä. Kehittäjä arkkitehdin ryhmässä. Yhteystiedot: sähköposti, puhelin, skype tuomo.makela(a)tkk.fi 050 5741 666 tuomomakela jani(a)eranen.com 0400 789 295 ebunny tfrisk(a)cc.hut.fi 040 8462 132 tatufrisk janne.makela(a)tkk.fi 050 3589 355 jannetmakela thassine(a)cc.hut.fi 045 678 2412 hazaah ppalmila(a)cc.hut.fi 050 5814 184 petripalmila hkostia(a)cc.hut.fi 050 3313 495 hkostia ostenroos(a)cc.hut.fi 040 7738 593 ostenroos 2.1.2 Asiakasorganisaation yhteystiedot Teemme projektin Suomen Sulkapalloliitolle. Sulkapalloliiton nimeämä asiakas, jonka kanssa projektista kommunikoimme, on Jukka Antila. Jukka Antila on toteuttanut aiemman järjestelmän ja hänellä on kokemusta ohjelmistoprojektin toteuttamisesta. Muut asiakasorganisaation jäsenet ovat asiantuntijoita sulkapallossa ja sulkapallon järjestelmien vaatimuksissa. Taulukko 4. Asiakasorganisaation yhteystiedot Status Nimi Sähköposti Puhelin Asiakas Jukka Antila jukka.antila(a)sulkapallo.org 0400 696 370 Good Minton 6 (23)

Asiantuntija Mika Heinonen mika.heinonen(a)sulkapallo.fi 040 526 9949 Asiantuntija Pasi Vilkki pasi.vilkki(a)sulkapallo.fi 040 5722 498 2.1.3 SoberIT:n valvonta ja tukiorganisaation yhteystiedot SoberIT:n tehtävänä on valvoa projektin etenemistä ja tähän tehtävään on nimetty Kauko Huuskonen. Kurssin luennoitsija Jari Vanhanen ei ole suoranaisesti projektin kanssa tekemisissä, mutta antaa taustatukea ja määrittelee reunaehtoja kaikkien kurssin projektien toteuttamiselle. Lisäksi SoberIT:n organisaatiossa on lukuisia henkilöitä, jotka ovat välillisesti luomassa puitteita projektin toteuttamiselle. Taulukko 5. SoberIT:n valvontaorganisaation yhteystiedot Status Nimi Sähköposti Puhelin Mentor Kauko Huuskonen kauko.huuskonen(a)tkk.fi 050 3745 479 Kurssin luennoitsija Jari Vanhanen jari.vanhanen(a)tkk.fi 040 758 0055 2.1.4 Muut projektin sidosryhmät Tärkein ulkopuolinen sidosryhmä, joka ei ole suoraan tekemisissä projektin kanssa, ovat tulevan lopputuotteen käyttäjät. Tähän ryhmään kuuluvat kaikki lopputuotteen käyttäjät ylläpitäjästä, liiton ja seurojen päivittäjiin sekä www käyttäjiin. Käytännössä käyttäjäsidosryhmään kuuluvat sulkapallon harrastajat, taustavaikuttajat ja muuten lajista kiinnostuneet. Lopputuotetta testataan loppukäyttäjillä, mikäli projektin toisessa toteutusiteraatiossa on resursseja jäljellä käyttäjätestien läpiviemisiin. Muuten käyttäjät eivät ole suoranaisesti sidoksissa projektiin. Good Minton 7 (23)

3 Tavoitteet 3.1 Projektin tavoitteet Taulukossa 6 on listattu asiakkaan keskeisimmät liiketoimintatavoitteet prioriteettijärjestyksessä. Lisäksi taulukkoon on listattu toteutumiskriteerit, joiden pohjalta tavoitteiden toteutumista arvioidaan. Taulukko 6. Asiakkaan liiketoimintatavoitteet Asiakkaan liiketoimintatavoitteet Toteutumiskriteeri 1. Tavoitteena on korvata vanha järjestelmä. Toteutuu, jos uusi järjestelmä otetaan käyttöön Suomen Sulkapalloliitossa. 2. Tavoitteena on parantaa yhteensopivuutta Asiakas arvioi projektin lopussa, onko seuroissa käytettävien ohjelmien ja liiton yhteensopivuus seuroissa käytettävien kilpailutoiminnan rekisteriohjelman kanssa. ohjelmien ja liiton kilpailutoiminnan 3. Tavoitteena on vähentää Sulkapalloliiton työmäärää tarjoamalla seuroille mahdollisuutta tallentaa kilpailutietoja. 4. Tavoitteena on helpottaa pelaajaluetteloiden ja ranking tietojen tuottamisesta. rekisteriohjelman kanssa riittävä. Asiakas ja projektiryhmä arvioivat, onko kilpailutietojen tallentaminen mahdollistettu vaatimuksiin kirjatulla tavalla. Asiakas arvioi projektin lopussa, onko tavoite toteutunut. 5. Tavoitteena on parantaa helppokäyttöisyyttä. Asiakas arvioi projektin lopussa, onko tuote 6. Tavoitteena on uuden järjestelmän päivitettävyys ja ylläpidettävyys tulevien sääntömuutosten varalta. 7. Tavoitteena on historiatietojen helppo hallinta, saatavuus ja varmistus. 8. Tavoitteena on toteuttaa seuroille tarjottava kilpailuunilmoittautumisjärjestelmä. helppokäyttöinen. Asiakas ja projektiryhmä arvioivat, onko sääntöjen päivitettävyys ja ylläpidettävyys toteutettu vaatimuksiin kirjatulla tavalla. Asiakas arvioi projektin lopussa, onko tavoite toteutunut. Toteutuu, jos ilmoittautumisjärjestelmä on sisällytetty uuteen järjestelmään. Good Minton 8 (23)

3.2 Henkilökohtaiset oppimistavoitteet Seuraavassa on listattu projektiryhmän jäsenten henkilökohtaiset tavoitteet: Jani Eränen Tavoitteenani on saada kehitettyä kommunikaatiotaitojani hajautetun projektiryhmän sisällä sekä asiakkaan kanssa. Toivon voivani omaksua ja soveltaa tuotekehitysprosessia pienessä ja hajautetussa tuotekehitysryhmässä. Toivon löytäväni uusia toimintatapoja ja oppivani paremmin kontrolloimaan omaa ajankäyttöäni. Lisäksi toivon onnistuvani luomaan uusia kontakteja työelämää ajatellen. Tatu Frisk Toivon saavani hyödyllistä kokemusta SE menetelmien soveltamisesta ja tällaisen projektin kulusta yleensä. Pyrin osaltani vaikuttamaan siihen, että projektin tuloksena syntyy asiakkaalle hyödyllinen tuote työmäärän pysyessä kurssin raamien puitteissa. Timo Hassinen Toivon oppivani kurssin aikana soveltamaan Ohjelmistotuotannon perusteet kurssilla oppimiani asioita. Erityisesti haluan oppia, miten laadunvarmistus käytännössä toimii. Henri Kostia Tavoitteenani on kehittyä ohjelmistokehittäjänä jokaisella osa alueella. Toivon, että projekti antaa hyvän esimerkin projektiryhmän toiminnasta, jota voi mahdollisesti hyödyntää työelämässä. Janne Mäkelä Toivon oppivani ohjelmistoprojektin käytännön toteuttamisen vaiheista. Tuomo Mäkelä Tavoitteenani on projektin kuluessa oppia ymmärtämään ohjelmistoprojektin elinkaarta. Toivon saavani kokemusta ohjelmistoprojektin hallinnasta ja projektin johtamisesta. Lisäksi toivon projektin kuluessa kehittyväni ihmisten johtamisessa. Tavoitteenani on osaltaan vaikuttaa siihen, että projekti etenee onnistuneesti läpi ja projektin lopputuotteena saatavasta ohjelmistosta olisi aidosti hyötyä asiakkaalle. Petri Palmila Odotan kurssin antavan selkeän kokonaiskuvan ohjelmistokehitysprojektista. Omalta osaltani tulen keskittymään kehittäjän tehtäviin ja tavoitteena on suoriutua kurssista hyvin. Selviytyminen kurssista tulee vaatimaan hyvää ajankäytönhallintaa. Olavi Stenroos Tavoitteenani on oppia toimimaan oikeassa ohjelmistoprojektiympäristössä ja oppia paremmin käytännössä käytettäviä teknologioita sekä vähän vuorovaikutusta asiakkaan kanssa. Good Minton 9 (23)

4 Resurssit ja budjetti Projektin suunnittelussa on kiinnitetty erityistä huomiota henkilöstön resursoimiseen, Toisaalta materiaalit ja budjetti ovat hyvin vahvasti sidoksissa toimeksiantajan, Suomen Sulkapalloliiton ja myös kurssin, antamiin raameihin. Niiden suunnittelussa on huomattavasti vähäisemmin liikkumavaraa. 4.1 Henkilöstö Taulukossa 7 on esitetty projektiryhmän jäsenille budjetoidut työmäärät iteraatioittain. Taulukko 7. Projektin henkilöstön työmäärien jakautuminen Nimi Rooli PP I1 I2 tot Tuomo Mäkelä Projektipäällikkö 70 60 60 190 Jani Eränen Laatujohtaja 65 60 65 190 Tatu Frisk Arkkitehti 50 80 60 190 Janne Mäkelä Kehittäjä (proj.pääll.) 30 75 85 190 Timo Hassinen Kehittäjä (laatujoht.) 34 71 85 190 Petri Palmila Kehittäjä (laatujoht.) 25 75 90 190 Henri Kostia Kehittäjä (arkkitehti) 33 82 75 190 Olavi Stenroos Kehittäjä (arkkitehti) 33 82 75 190 Yhteensä 340 585 595 1520 4.2 Materiaalit Projektin laitteistoa ja ohjelmistoa saadaan kolmelta eri taholta: Asiakkaalta, Teknilliseltä korkeakoululta sekä projektiryhmän jäseniltä itseltään. Asiakas tarjoaa virtuaalipalvelimen, jolle on asennettu Apache, PHP 4.4, MySQL sekä Smarty. Teknillinen korkeakoulu tarjoaa CVN palvelimen, TikiWiki ja Bugzilla palvelimet, sekä työskentelytiloja, tietokoneita, tulostimia ja koulun koneille asennettuja ohjelmistoja projektityön tekemiseen. Lisäksi projektin teossa käytetään projektin jäsenten omia laitteistoja ja ohjelmistoja. 4.3 Budjetti Taulukossa 8 on laskettu budjetti projektille, mikäli se tehtäisiin oikeana työnä asiakkaalle. Budjetti on laskettu siten, että asiakas maksaa projektiryhmän sisäiset kustannukset lisättynä arvonlisäverolla ja projektiryhmän sisäisellä tuotto odotuksella. Lisäksi asiakkaan kustannukseksi tulee sisäisen työn kustannus, sekä kustannus virtuaalipalvelimesta, joka tuotteen asentamiseen tarvitaan. Seuraavassa oletetaan, että asiakkaalla on olemassa palvelin valmiiksi ja eikä sen kustannuksia osoiteta tämän projektin kustannuksiin. Projektiryhmän sisäiset kustannukset muodostuvat ensinnäkin ihmistyöstä eli sisäisestä työstä, konsultoinnista, johon tässä huomioidaan vain mentorin konsultointi, ei koko kurssihenkilökunnan Good Minton 10 (23)

projektin eteen tekemää työtä. Toiseksi kustannuksiin on laskettu ohjelmisto ja laitteistokustannuksia. Oletuksena on, että molempia kustannuksia pystytään jakamaan myös muiden projektien kesken, jolloin yksittäiseen projektiin aiheutuvat kustannus on vain osa siitä kokonaiskustannuksesta, mitä esimerkiksi tietokoneiden ja ohjelmistolisenssien hankinnasta aiheutuisi. Projektissa käytetään paljon ilmaisohjelmistoja, jotka todellisessa projektissa voitaisiin korvata paremmin toimivilla kaupallisilla versioilla. Toisaalta käytössä on myös ohjelmistoja, joista korkeakoululla on olemassa lisenssit ja joiden käyttäminen kaupallisessa projektissa ei liene lisenssien puitteissa laillista. Lisäksi budjetissa oletetaan, ettei projektiryhmällä ole olemassa mitään vuokrattua työtilaa, vaan jokainen tekee töitä kotonaan. Kaiken kaikkiaan kustannusten arviointi on erittäin vaikeaa, mutta annetut luvut antavat jonkinlaisen käsityksen siitä, mitä suuruusluokkaa tämän kaltaisen projektin kustannukset olisivat, jos se tehtäisiin oikeana työnä. Toki budjettia tarkasteltaessa on hyvä muistaa, että mikäli projektia ei tehtäisi koulun kurssina, voitaisiin toimintaa joiltain osin suoraviivaistaa ja projektiin käytettäviä tunteja vähentää. Taulukko 8. Projektin kuvitteellinen budjetti Projektiryhmän kustannukset määrä kustannustekijä kustannus Sisäinen työ Projektipäällikkö 190 h 80 /h 15 200 Laatujohtaja 190 h 60 /h 11 400 Arkkitehti 190 h 60 /h 11 400 Kehittäjät 5 * 190 h 50 /h 47 500 Konsultointi Mentor 40 h 100 /h 4 000 Laitteisto 5 000 Ohjelmisto 12 000 Yhteensä 106 500 Asiakkaan kustannukset määrä kustannustekijä kustannus Tuotteen hinta (22 % ALV, 15 % tuotto) 149 420 Sisäinen työ 100 h 60 /h 6 000 Yhteensä 155 420 Good Minton 11 (23)

5 Käytännöt ja työkalut 5.1 Käytännöt Seuraavassa esitellään projektissa sovellettavat käytännöt. 5.1.1 Iteratiivinen kehitys Projektin toteutus on jaettu kolmeen eri iteraatioon: Projektin suunnitteluiteraatioon ja kahteen toteutusiteraatioon. Vaatimusten kirjaaminen keskittyy ensimmäiseen iteraatioon, mutta vaatimuksia kommunikoidaan ja täsmennetään asiakkaan kanssa myös toteutusiteraatioiden kuluessa. Iteraatiosuunnittelu toteutetaan kyseisen iteraation alussa tai edellisen lopussa. Projektin suunnittelu keskittyy suunnitteluiteraatioon, mutta projektin suunnittelua tehdään ja projektin prosesseja kehitetään jatkuvasti. Eniten projektisuunnitelmaa tarkistetaan iteraatiosuunnittelun yhteydessä. Arkkitehtuurinen suunnittelu toteutetaan karkealla tasolla suunnitteluiteraatiossa. Arkkitehtuurista suunnittelua jatketaan ensimmäisessä toteutusiteraatiossa niiltä osin kuin vaatimusten täsmentyminen arkkitehtuuriin vaikuttaa. Alemman tason suunnittelusta suurin osa tehdään ensimmäisessä toteutusiteraatiossa. Ohjelmointi suoritetaan toteutusiteraatioiden kuluessa. Testausta toteutetaan jatkuvasti toteutusiteraatioiden kuluessa. Painotus siirtyy iteraatioiden edetessä yksikkötestauksesta laatujohtajan (JE) koordinoimiin koko järjestelmän käyttötesteihin. Asiakkaan kanssa pidetään iteraatioiden aikana palavereita, joissa esitetään aikaansaannoksia. Näitä pidetään iteraatiosta riippuen 1 2 iteraation lopussa pidettävän edistymisraportoinnin lisäksi. Näissä palavereissa asiakas pystyy tarkistamaan, ollaanko kehitystyössä menossa oikeaan suuntaan. 5.1.2 Iteraatiosuunnittelu Vastuu iteraatiosuunnittelusta on projektipäälliköllä (TM). Projektipäällikkö (TM) keskustelee iteraatiosuunnittelusta yhdessä laatujohtajan (JE) ja arkkitehdin (TF) kanssa. Keskusteluissa jaetaan kokonaistyömäärä tehtäviin ja arvioidaan niiden kestot. Keskustelut käydään joko edellisen iteraation lopussa tai heti seuraavan alussa. Työmääräarvion jälkeen pidetään asiakkaan kanssa iteraatiopalaveri, jossa asiakas asettaa prioriteetit toteutettaville toiminnallisuuksille ja tarvittaessa valitsee, mitkä toiminnallisuuksista jätetään toteuttamatta resurssipulan vuoksi. Vastuu iteraatiosuunnitelman kirjoittamisesta on projektipäälliköllä (TM). Projektipäällikkö antaa iteraatiosuunnitelman luettavaksi laatujohtajalle (JE) ja arkkitehdille (TF) viimeistään kaksi päivää ennen iteraatiosuunnitelman palautusta. Laatujohtaja (JE) ja arkkitehti (TF) voivat tehdä suunnitelmaan muutosehdotuksia. Projektipäällikkö (TM) keskustelee suunnitelmasta laatujohtajan (JE) ja arkkitehdin (TF) kanssa. Keskustelujen ja muutosehdotusten pohjalta projektipäällikkö viimeistelee lopullisen version iteraatiosuunnitelmasta ja on vastuussa sen palauttamisesta. Good Minton 12 (23)

5.1.3 Dokumentointi Projektin dokumentointi toteutetaan käyttäen hyväksi kurssin tarjoamia dokumenttipohjia. Dokumentit kirjoitetaan ensisijaisesti Microsoft Wordilla ja palautettaessa ne muutetaan pdfformaattiin, jotta dokumentit olisivat varmemmin kaikkien luettavissa. Valmiit dokumentit säilötään projektin Wiki sivuille, mistä ne ovat kaikkien luettavissa. Projektin kaikille dokumenteille on määritetty vastuuhenkilö, joka voi tarvittaessa delegoida dokumentointia eteenpäin. Dokumentista tehdään ensin katselmoitava versio, joka lähetetään kaikille projektin jäsenille vähintään kaksi päivää ennen palautusta. Projektin jäsenet voivat kommentoida dokumenttia ja tehdä muutoksia siihen, minkä pohjalta dokumentista vastaava henkilö muokkaa dokumentin palautettavaksi versioksi. Ennen dokumentin palautusta projektipäällikkö (TM) hyväksyy vielä dokumentin sisällön, ellei aiemmin ole muuta sovittu. Projektin aikana tehtävät dokumentit on esitelty taulukossa 9. Taulukko 9. Palautettavat dokumentit Dokumentti Iteraatiosuunnitelmat Projektisuunnitelma Edistymisraportit Vaatimusmäärittely Laadunvarmistusraportti Testitapaukset Testiloki Tekninen määrittely Loppuraportti Käyttöohje SEPA päiväkirjat Vastuuhenkilö Tuomo Mäkelä Tuomo Mäkelä Tuomo Mäkelä Jani Eränen Jani Eränen Jani Eränen Jani Eränen Tatu Frisk Tuomo Mäkelä Tuomo Mäkelä jokainen itse 5.1.4 Riskien hallinta Projektin riskit tunnistetaan Delphi metodilla, jossa kaikki projektiryhmän jäsenet, sekä asiakas tunnistavat mielestään projektin suurimmat riskit. Jokaisesta uudesta riskistä määritellään riskin kuvaus, riskin hallintakeinot, vastatoimet riskin tapahduttua, riskin todennäköisyys ja vakavuus asteikolla 1 5 (5 suurin/vakavin). Riskin kokonaisvaikutus projektille saadaan kertomalla nämä kaksi arvioitua lukua keskenään, jolloin saadaan eri riskit vertailukelpoisiksi keskenään (asteikolla 1 25, 25 on suurin arvo). Riskien todennäköisyyden ja vakavuuden arviointi tapahtuu jälleen Delphi metodilla jokaisen osallistujan toimesta, joten laskettu kokonaisvaikutus on keskiarvo kaikista annetuista arvoista. Kokonaisvaikutuksen perusteella muodostetaan kymmenen uhkaavimman riskin lista, joita sitten monitoroidaan ja joiden vaikutusta pyritään minimoimaan koko projektin ajan. Projektin riskiarviointi kaikkien osallistujien kesken tehdään ensimmäiseksi projektin suunnitteluvaiheen aikana. Tämän jälkeen aikaväli riskien arvioinnille riippuu siitä, kuinka vakavia riskejä riskiarvioinnissa löydettiin. Mikäli riskikartoituksessa ei paljastunut merkittäviä riskejä, tehdään riskikartoitus vain kerran iteraatiossa. Good Minton 13 (23)

Tarkemmat tiedot riskien hallinnasta löytyvät erillisestä riskienhallintadokumentista. 5.1.5 Aikaraportointi Aikaraportointi toteutetaan käyttäen Journyx aikaraportointityökalua. Journyx on Web pohjainen sovellus ja siihen kaikki pystyvät itse kirjaamaan siihen tekemänsä tunnit tehtävittäin. Tuntien kirjauksessa ainoa vaatimus on, että edellisen viikon tunnit ovat kirjattuna maanantaina. Journyxista pystyy luomaan erittäin laajan valikoiman erilaisia raportteja. Journyxin heikkous on siinä, ettei siihen pysty kovinkaan helposti asettamaan tehtäville estimaatteja työtehtävien koosta. Näin Journyxin avulla ei suoraan ole mahdollista seurata, miten projekti etenee suhteessa aikatauluun. Tästä syystä projektipäällikkö (TM) siirtää käsin Excel taulukkoon luvut tehdystä työstä ja verratakseen näitä estimaatteihin. Vertailun helpottamiseksi jokainen merkitsee tuntikirjaukseen, missä vaiheessa tekemänsä työtehtävä on. Tämä tehdään luokituksella aloitettu (25 %), käynnissä (50 %), melkein valmis (75 %), valmis (100 %). Sulkuihin merkitty prosenttiluku tarkoittaa, kuinka valmiiksi tehtävä tällöin oletetaan työmäärän suhteen. Tämän kaltaiset kommentit työtehtävän valmiudesta ovat vain karkeita arvioita, mutta yhdistelemällä useita arvioita yhteen saadaan kohtuullinen käsitys siitä, miten projekti etenee suhteessa arvioihin. Merkittävien poikkeaminen paljastuessa, voidaan ryhtyä korjaustoimenpiteisiin. Aikaraportoinnin tehtäväjaottelusta on tehty oma dokumentti, joka on liitteenä. Tehtäväjaottelua päivitetään jokaisen iteraatiosuunnittelun yhteydessä. 5.1.6 Kommunikaatio Kommunikointikieli projektissa on suomi, koska asiakasorganisaatio käyttää kielenään suomea ja kaikki projektin jäsenet puhuvat äidinkielenään suomea. Ainoa poikkeus tähän on lähdekoodi, joka kirjoitetaan ja kommentoidaan englanniksi. Pääkommunikointikanava projektiryhmän sisällä on Skype, jonka kautta projektiryhmän jäsenet voivat ratkoa keskenään ongelmia. Kaikkia koskevien tiedotusten lähettämiseen käytetään sähköpostia. Projektiryhmän sisäisiä palavereja pidetään tarvittaessa, mutta projektissa ei käytetä jokaviikkoista statuspalaveria. Kommunikaatio asiakkaan kanssa hoidetaan sähköpostilla, tarvittaessa puhelimella. Päävastuu kommunikaatiosta on Laatujohtajalla (JE), apunaan projektipäällikkö (TM). Kommunikaatio mentorin kanssa hoidetaan myös sähköpostilla. Vastuu kommunikaatiosta on Projektipäälliköllä (TM). Projektin kotisivu toteutetaan TikiWikin avulla. Projektin kotisivu toimii kommunikaatiokanavana kaikille muille sidosryhmille. TikiWikiä käytetään myös projektin sisäisenä dokumenttipankkina. Good Minton 14 (23)

5.1.7 Iteraatiodemo Vastuu iteraatiodemon pitämisestä on Projektipäälliköllä (TM). Projektipäällikkö (TM) on vastuussa projektin edistymisen ja projektin statuksen esittelystä. Projektin aikaansaannosten esittelystä päävastuu on Laatupäälliköllä (JE) ja arkkitehdillä (TF). Projektipäällikkö (TM) keskustelee iteraatiodemon sisällöstä laatupäällikön (JE) ja arkkitehdin (TF) kanssa viimeistään iteraation materiaalien palautusaikarajaan mennessä. Projektipäällikkö jakaa osuudet laatupäällikön ja arkkitehdin ryhmille. Iteraatiodemon teknisestä toteutuksesta vastaa Jani Eränen. Kaikki iteraatiodemon materiaali pitää olla toimitettuna Jani Eräselle ja projektipäällikölle (TM) vähintään neljä tuntia ennen iteraatiodemon pitämistä, ellei muuta sovita. 5.1.8 Vikojen seuranta Projektin aikana toteutettavan järjestelmän vikojen seurantaan käytetään Bugzilla ohjelmistoa. Ohjelmistolla pidetään kirjaa löydetyistä vioista ja niiden tilasta projektin edetessä. Jos vika löydetään ohjelmoitaessa, sitä ei tarvitse kirjata järjestelmään, jos ohjelmoija pystyy korjaamaan virheen välittömästi ja varmistuu virheen korjaantumisesta. Jos virhettä ei voida korjata heti, se kirjataan Bugzillaan. Samoin kaikki järjestelmä ja hyväksymistestauksessa löydetyt virheet kirjataan Bugzillaan. Järjestelmän virheestä kirjataan ainakin seuraavat asiat: 1. Nimi 2. Lyhyt kuvaus virheestä 3. Virheen tila (unconfirmed, new, assigned, reopened, resolved, Verified) 4. Ratkaisun tila(resolution) (fixed, invalid, wontfix, duplicate, worksforme, moved) 5. Ohjattu henkilölle 6. Prioriteetti 7. Vakavuus (blocker, critical, major, minor, trivial, enhancement) 8. Laitealusta, jolla testattu 9. Kuvaus toiminnoista, jolla virhe voidaan toistaa Vikojen seurannasta vastaa laatujohtaja (JE). Laatujohtaja lukee läpi kaikki Bugzillaan kirjatut bugit, muuttaa tarvittaessa niiden prioriteettia ja ohjaa ne jollekin henkilölle, mikäli vian löytänyt henkilö ei ota vastuuta asiasta itselleen. Good Minton 15 (23)

5.1.9 Versionhallinta Versionhallintaan käytetään SVN versionhallintaohjelmistoa. SVN repository on asennettu ATKkeskukselle, josta sen pitäisi olla ryhmäläisten käytettävissä. Ryhmäläiset voivat käyttää versionhallintaan vapaavalintaista apuohjelmaa, esim. Windowsille TortoiseSVN. Versionhallintaan lisättävän koodin tulee olla toimivaa ja kommentoitua. Toimivuuden kriteeriksi riittää tässä se, että koodi tulkkautuu ilman virheilmoituksia ja mahdollinen tuloste selaimen kautta katsottuna on odotetunlainen. Prototyyppivaiheessa koodin kommentointi ei ole yhtä oleellista. Ennen koodin lisäämistä versiohallintaan olisi syytä tarkistaa, että oma versio päivitettävästä ohjelmasta on viimeisin (update). 5.1.10 Koodauskäytäntö Jotta projektin tuottaman koodin tyyli pysyisi yhtenäisenä, löytyy projektin Wikistä koodauskäytännön ulkoasullisessa mielessä vapaamuotoisesti määrittelevä mallitiedosto. Koodi kommentoidaan Javadoc konventiota noudattaen, jotta siitä voidaan tuottaa automaattinen tiivistelmä Doxygen työkalulla. Lisäksi koodin pitäisi olla kommentoitua sikäli, että se pysyy helposti luettavana. Arkkitehti (TF) tarkistaa toteutusvaiheen alussa kaikkien ohjelmoijien käyttämät tyylit ja sen pohjalta tarvittaessa neuvoo kehittäjiä muuttamaan tyyliä yhtenäiseksi. 5.1.11 Prosessin kehittyminen Kahden ensimmäisen iteraation lopussa pidetään koko projektiryhmän yhteinen palaveri, jossa keskustelemme ryhmän toimintatavoista ja jokaisella on mahdollisuus esittää ajatuksiaan siitä, miten voisimme toimia paremmin ryhmänä. Lisäksi projektipäällikkö (TM) valvoessaan projektin etenemistä miettii viikoittain, miten asioita voitaisiin tehdä paremmin ryhmänä. Ryhmän toimintatavoista on myös mahdollista antaa jatkuvasti palautetta projektipäällikölle (TM). 5.1.12 Vaatimusten hallinta Projektin vaatimukset määritellään yhdessä asiakkaan kanssa, asiakkaan määrittelemistä liiketoimintatavoitteista sekä olemassa olevan järjestelmän toiminnasta. Vaatimusmäärittely esitellään asiakkaalle, joka hyväksyy määrittelyn tai ehdottaa korjauksia. Hyväksyttyjen vaatimusten muuttaminen tai uusien vaatimusten lisääminen vaatimusmäärittelyyn tulee hyväksyä sekä asiakkaan että projektiryhmän toimesta. Ennen muutoksen hyväksymistä tulee selvittää muutoksen vaikutus projektiin. Projektin vaatimusten kirjaamisesta ja hallinnasta vastaa laatujohtaja (JE). Good Minton 16 (23)

5.1.13 Suunnittelu Projektin lopputuotteen täytyy toimia Sulkapalloliiton virtuaalipalvelimella nykyisten web sivujen rinnalla. Tämä määrittelee korkeimman tason arkkitehtuurin, joten sen suunnitteluun ei tarvita lisämenetelmiä. Kehitettävästä ohjelmasta tuotetaan suunnitteluvaiheen aikana käyttöliittymäprototyyppi. Prototyyppiin on toteutettu yksinkertainen arkkitehtuurirunko, joka voidaan validoida arvioimalla prototyypin onnistumista ja kehityksessä mahdollisesti ilmenneitä ongelmia. Tietokantamallin muuttaminen kun sitä käyttävää ohjelmakoodia on jo valmiina voi olla työlästä, joten tietokantamalli suunnitellaan ennen tietokantarajapinnan toteuttamista ER kaavion avulla. Jos toteutuksessa syntyy (perusarkkitehtuurin ulkopuolisia) useamman luokan sisältäviä rakenteita, voidaan ne suunnitella ja dokumentoida UML luokkakaavioiden avulla. Luokkarakenteita suunnitellessa on syytä huomioida, että käytettävä ohjelmointikieli, PHP4, ei tue abstrakteja metodeja eikä rajapintamäärittelyjä. 5.2 Laadunvarmistus suunnitelma Tämä osio lisätään projektisuunnitelmaan ensimmäisen toteutusiteraation suunnitelman yhteydessä 3.11.2006. 5.3 Työkalut Kehitystyössä voidaan käyttää ympäristönä tietokonetta, johon on asennettu Apache Web palvelin PHP tuella, sekä MySQL. Kehitettävä tuote ei ole riippuvainen edellisten versioista, pois lukien hyvin vanhat versiot. Sulkapalloliiton tuotantopalvelimesta on otettu WMware toisinto, jonka avulla sovellusta on mahdollista kehittää ja testata sen lopullisessa suoritusympäristössä. Kaikki työkalut ovat ilmaisia ja saataville verkosta sekä Linux että Windows järjestelmille. Versionumerot ovat suuntaa antavia. PHP 4.1 Käytettävä ohjelmointikieli. Uudempaakin tulkkia voi käyttää, mutta ohjelmakoodin on toimittava tällä versiolla. Smarty 2.6.14 Skriptikieli, jolla luodaan PHP:n ja HTML:n ylläpidettävällä tavalla yhdistäviä aihioita. Apache 1.3.37 Web palvelin. MySQL 5.0.24 Tietokantaohjelmisto. Good Minton 17 (23)

SVN 1.3.0 Versionhallintaohjelmisto. Repositorio on sijoitettu ATK keskuksen palvelimelle. VMware 1.0.1 Virtuaalipalvelinsovellus, jonka avulla tuotetta on mahdollista testata vaivattomasti sen tuotantoympäristössä. DBBuilder 4 Työkalu relaatiotietokantojen suunnitteluun ja koodin generoitiin erityisesti MySQL+PHP ympäristössä. Doxygen 1.5.0 Työkalu ohjelmakoodin automatisoituun dokumentointiin. Skype 2.5.0 Pikaviestiohjelmisto. Projektin pääasiallinen kommunikointimenetelmä sähköpostin ja tapaamisten ohella. 5.4 Standardit Sovelluksen tuottaman HTML koodin tulisi olla W3C HTML 4.01 standardin mukaista. 6 Vaiheistus 6.1 Aikataulu Taulukossa 10 on esitetty projektin aikataulu. Taulukko 10. Projektin aikataulu 2.10.2006 Iteraatiosuunnitelman palautus 9.10.2006 Vaatimusmäärittelyn ensimmäinen versio 16.10.2006 Vaatimusmäärittelyn pohjalta toteutettu prototyyppi 20.10.2006 Vaatimusmäärittelyn korjattu/muokattu ja katselmoitu versio 23.10.2006 Projektin suunnittelun tulosten palautus 25.10.2006 Iteraatiodemo 3.11.2006 Iteraatiosuunnitelman (I1) palautus 11.12.2006 Ensimmäisen toteutusiteraation tulosten palautus Good Minton 18 (23)

12. 13.12.2006 Iteraatiodemo (I1) 16.1.2007 Iteraatiosuunnitelman (I2) palautus helmikuun alku Tuotteen demoaminen asiakkaalle ja mentorille 17.2.2007 Lopputuote vertaistestausryhmälle 21.2.2007 Vertaisryhmän testaustulosten raportointi 26.2.2007 Projektin lopputulosten palautus 28.2. 1.3.2007 Iteraatiodemo (I2) 6.2 Projektin suunnittelu 6.2.1 Tavoitteet Projektisuunnittelun aikana ryhmällä on tavoitteena: Tehdä projektisuunnitelma ja kommunikoida se projektisuunnittelun kuluessa ryhmälle siten, että ryhmä ymmärtää omat toimintatapansa kykenee toimimaan niiden mukaisesti. Jakaa projektin roolit siten, että jokainen ryhmän jäsen saa omaa kiinnostustaan vastaavia ja taitotasolleen sopivia tehtäviä, eikä kenenkään yksittäisen jäsenen työtaakka muodostu kohtuuttoman suureksi. Kirjata ja kommunikoida asiakkaan vaatimukset siten, että ryhmä ymmärtää, mitä asiakas haluaa toteutettavan. Vaatimukset kirjataan siten, että mikäli asiakkaan mieli ei muutu, niitä ei tarvitse enää muokata, ainoastaan tarvittaessa täsmentää. Suunnitella tulevan projektin arkkitehtuuri siten, että heti ensimmäisen toteutusiteraation alussa on mahdollista aloittaa ohjelmointityö. 6.2.2 Tuotokset Projektisuunnitelma (pl. kappale 5.2 QA suunnitelma) Vaatimusdokumentti (pl. yksityiskohtaiset selvitykset kappaleissa 6 8) Edistymisraportti Lisäksi luodaan järjestelmästä prototyyppi, joka ensisijaisesti toimii apuna sisäisessä kehityksessä. 6.2.3 Tehtävät (tähän voisi miettiä taulukkoa tms. josta saisi helpommin selvää ensivilkaisulla) Kommunikaatio, 75 tuntia Kick off palaveri asiakkaan kanssa, 10 tuntia Good Minton 19 (23)

Sisäinen viestintä, yhteiset palaverit: Projektipäällikkö, laatupäällikkö ja arkkitehti, 10 tuntia/henkilö Kehittäjät, 7 tuntia/henkilö Luennot ja projektin viitekehykseen tutustuminen, 50 tuntia Luennot, 25 tuntia Projektin viitekehykseen tutustuminen, 25 tuntia Tarvittaviin työkaluihin tutustuminen ja niiden käyttöönotto, 45 tuntia. Työkalujen käyttöönotto 20 tuntia Työkaluihin tutustuminen, 3 tuntia/henkilö Projektin suunnittelu ja projektisuunnitelman kirjoittaminen, 60 tuntia Projektin ja toimintatapojen suunnittelu, 40 tuntia Projektisuunnitelman kirjoittaminen, 20 tuntia Arkkitehtuurin suunnittelu, 50 tuntia Projektin arkkitehtuurin suunnitteleminen, 25 tuntia Prototyypin tekeminen, 25 tuntia Vaatimusten kirjaaminen, 40 tuntia Vaatimusten kommunikointi yhdessä asiakkaan kanssa, 15 tuntia Vaatimusten kirjoittaminen, 25 tuntia Projektisuunnitelman esitys, 10 tuntia Esityksen luominen ja harjoittelu, 5 tuntia Esityksen pitäminen, 5 tuntia Projektin suunnitteluvaiheeseen on budjetoitu käytettäväksi yhteensä 285 tuntia. Kaikkiaan projektissa on tuntiresursseja käytössä 1200 tuntia, SEPA (Special Assignment in SE) mukaan lukien 1480 tuntia. 6.3 Toteutus 1 (I1) Päivitetään 3.11.2006 Ensimmäisen toteutusiteraation palautuksen yhteydessä. 6.3.1 Tavoitteet Ensimmäisessä toteutusiteraatiossa on tarkoituksena saada tehtyä ohjelmistosta toimiva versio, jossa ovat toteutettuna päätoiminnallisuudet. Käyttöliittymästä tehdään ensimmäinen versio. 6.3.2 Tuotokset Palautettavat dokumentit: Päivitetty projektisuunnitelma Good Minton 20 (23)

Päivitetty vaatimusmäärittely Tekninen spesifikaatio Testitapaukset, testiloki ja laadunvarmistusraportti Edistymisraportti SEPA päiväkirjat 6.3.3 Tehtävät 6.4 Toteutus 2 (I2) 6.4.1 Tavoitteet Toisessa toteutusiteraatiossa on tavoitteena tehdä ohjelmisto valmiiksi. Tämä tarkoittaa kaikkien toiminnallisuuksien toteuttamista ohjelmistoon, käyttöliittymän viimeistelyä, ohjelmiston testaamista lopulliseen muotoonsa. 6.4.2 Tuotokset Palautettavat dokumentit: Projektisuunnitelma Vaatimusmäärittely Tekninen spesifikaatio Loppuraportti Käyttöohje Testitapaukset, testiloki ja laadunvarmistusraportti Vertaistestiloki ja vertaistestiraportti Edistymisraportti SEPA päiväkirjat 6.4.3 Tehtävät Good Minton 21 (23)

7 Riskiloki # Riski Varautuminen ja vastatoimet T V KV 1 Työmäärän kasautuminen määräaikojen lähelle Jaetaan iteraation työt pienempiin osiin, joille määritellään omat valmistumispäivämäärät. 4,00 3,50 14,00 5 Projektin tuotettu materiaali tuhoutuu Jokainen projektiryhmän jäsen huolehtii varmuuskopioinnista yhteisesti sovituin säännöin. Lisäksi koko projektin varmuuskopiot tallennetaan useaan eri paikkaan. 4 Projektiryhmä arvioi väärin vaadittavan työmäärän 8 Ryhmän jäsen ei pysty osallistumaan täysipainoisesti Työmääräarviot tehdään johtoryhmän kesken, jolloin jaetulla näkemyksellä parannetaan arviointitarkkuutta. Jokaisella projektiryhmän jäsenellä on varajäsen, joka pystyy ottamaan toisen jäsenen tehtäviä hoitaakseen. Lisäksi suunnittelussa ja aikataulutuksessa pyritään ottamaan huomioon ennakkoon tiedossa olevat poissa olot ja muut kiireet. 2 Vaatimusten priorisointi epäonnistuu Vaatimusten prioriteetit sovitaan yhdessä asiakkaan kanssa. Priorisointi tarkistetaan jokaisen iteraatiosuunnitteluvaiheen aikana. 3 Vaatimukset muuttuvat kesken projektin Järjestelmästä tehdään aikaisessa vaiheessa prototyyppi, jolla pyritään varmistamaan vaatimusten oikeellisuus. Lisäksi järjestelmän toteutuksessa pyritään hyvään ylläpidettävyyteen, jolla mahdollistetaan myös vaatimusten muutokset. 2,25 5,00 11,25 2,40 4,00 9,60 3,20 3,00 9,60 3,00 2,75 8,25 2,50 2,67 6,67 10 Kommunikaation puute ryhmän sisällä Johtoryhmä huolehtii alaistensa tiedottamisen. Tärkeät asiat lähetetään aina sähköpostilla ja nopeat kysymykset tms. hoidetaan esim. Skypellä. 12 Testaus epäonnistuu Testaus aloitetaan heti kun järjestelmässä on jotain testattavaa. Testausta jatketaan koko projektin ajan. Testaussuunnitelmaa myös ylläpidetään ja muokataan tarpeen mukaan koko projektin ajan. 9 Asiakas ei ole tyytyväinen lopputulokseen 6 Kommunikaation puute asiakkaan kanssa 7 Ranking laskenta algoritmit osoittautuvat vaikeiksi toteuttaa Järjestelmän tila käydään läpi jokaisessa asiakas tapaamisessa. Tällöin puutteet ja muutostarpeet tulevat esille mahdollisimman aikaisessa vaiheessa. Yhteyshenkilön on pidettävä yhteyttä asiakkaaseen säännöllisin väliajoin ja tiedottaa asiakkaalle projektin etenemisen. Samalla voidaan esittää mahdolliset projektiin liittyvät kysymykset. Tutkitaan olemassa olevan toteutuksen tapaa laskea ranking tulokset. Tulosten laskennan toteutus aloitettava heti ensimmäisen toteutus iteraation alussa. 2,50 2,67 6,67 2,00 3,00 6,00 1,33 4,00 5,33 1,50 3,50 5,25 1,50 3,50 5,25 Good Minton 22 (23)

14 Ryhmän jäsen keskeyttää Jokaisella projektiryhmän jäsenellä on varajäsen, joka pystyy ottamaan toisen jäsenen tehtävän hoitaakseen. 13 Projektiryhmä ymmärtää väärin asiakkaan vaatimukset 11 Asiakkaan sitoutuminen projektiin on puutteellista 15 Valitulla tekniikalla ei voida toteuttaa järjestelmää Vaatimukset pyritään kommunikoimaan mahdollisimman hyvin jo projektin alkuvaiheessa. Asiakas pidetään ajan tasalla projektin etenemisestä, jolla edistetään asiakkaan mielenkiinnon säilymistä. Järjestelmästä tehdään aikaisessa vaiheessa prototyyppi, jolla pyritään varmistamaan tekniikan soveltuvuus järjestelmän toteuttamiseen. 16 Riskien arviointi epäonnistuu Riskien arviointi tehdään jokaisessa iteraatiossa ja tarpeen mukaan useamminkin, jos projektiryhmän jäsenet huomaavat selvän nousun riskien todennäköisyyksissä. 17 Yhteensopivuusongelma kehitysalustan ja asiakkaan laitteiston välillä Järjestelmän kehitysalusta valitaan asiakkaan laitteiston perusteella. Järjestelmää testataan asiakkaan laitteistolla mahdollisimman pian käytettyjen tekniikoiden toimivuuden varmistamiseksi. 1,57 3,00 4,71 1,50 3,00 4,50 1,33 3,33 4,44 1,00 4,25 4,25 1,00 4,00 4,00 1,50 2,25 3,38 Good Minton 23 (23)