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 1.1 2006 11 07 Tuomo Mäkelä, Jani Iteraatiosuunnittelun (I1) tuotosten Eränen 2.0 2007 01 16 Tuomo Mäkelä, Jani Eränen liittäminen projektisuunnitelmaan Iteraatiosuunnittelun (I2) tuotosten liittäminen projektisuunnitelmaan

Sisältö: 1 ESITTELY 4 1.1 Projektin esittely 4 1.2 Terminologia 4 2 SIDOSRYHMÄT JA PROJEKTIORGANISAATIO 5 2.1 Projektin yhteystiedot ja roolit 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 Laadunvarmistussuunnitelma 17 5.2.1 Projektin laatu 17 5.2.2 Toteutusiteraatioiden laatu 20 5.3 Työkalut 22 5.4 Standardit 23 Good Minton 2 (35)

6 VAIHEISTUS 23 6.1 Aikataulu 23 6.2 Projektin suunnittelu 24 6.2.1 Tavoitteet 24 6.2.2 Tuotokset 25 6.2.3 Tehtävät 25 6.3 Toteutus 1 (I1) 26 6.3.1 Tavoitteet 26 6.3.2 Tuotokset 26 6.3.3 Tehtävät 28 6.4 Toteutus 2 (I2) 30 6.4.1 Tavoitteet 30 6.4.2 Tuotokset 30 6.4.3 Tehtävät 32 7 RISKILOKI 34 Good Minton 3 (35)

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 (35)

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 Projektin yhteystiedot ja roolit 2.1.1 Projektin sisäisen organisaation yhteystiedot sekä roolit Good Minton 5 (35)

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. 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. Good Minton 6 (35)

Taulukko 4. Asiakasorganisaation yhteystiedot Status Nimi Sähköposti Puhelin Asiakas Jukka Antila jukka.antila(a)sulkapallo.org 0400 696 370 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 (35)

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 (35)

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 (35)

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. Suunnitelma on päivitetty toisen toteutusiteraation alussa. Taulukko 7. Projektin henkilöstön työmäärien jakautuminen Nimi Rooli PP I1 I2 tot Tuomo Mäkelä Projektipäällikkö 77 61 64 202 Jani Eränen Laatujohtaja 56 55 92 203 Tatu Frisk Arkkitehti 38 102 44 184 Janne Mäkelä Kehittäjä (proj.pääll.) 15 32 117 164 Timo Hassinen Kehittäjä (laatujoht.) 21 64 85 170 Petri Palmila Kehittäjä (laatujoht.) 20 80 67 167 Henri Kostia Kehittäjä (arkkitehti) 16 49 104 169 Olavi Stenroos Kehittäjä (arkkitehti) 29 66 88 183 Yhteensä 272 509 661 1442 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. Good Minton 10 (35)

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 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 (35)

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 (35)

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 (35)

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 (35)

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 (35)

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 (35)

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 Laadunvarmistussuunnitelma 5.2.1 Projektin laatu 5.2.1.1 Projektin tärkeimmät laatutavoitteet Projektissa kehitettävän järjestelmän tärkeimmät laatutavoitteet: Luoda helppokäyttöinen järjestelmä kilpailuihin liittyvien tietojen hallintaan. Järjestelmän on oltava intuitiivinen ja järjestelmän käytön nopeasti opittavissa. Ohjelman tulee toimia yleisesti käytettyjen käyttöliittymäperiaatteiden mukaisesti. Parantaa yhteensopivuutta jäsenseuroissa käytettävien kilpailunhallinta ohjelmien ja Sulkapalloliiton käyttämän järjestelmän osalta. Järjestelmän pitää pystyä vastaanottamaan tietoa jäsenseuroissa yleisesti käytettävistä ohjelmista esim Badminton Tournament Planner. Varmistaa uuden järjestelmän päivitettävyys ja ylläpidettävyys tulevien muutosten varalta. Järjestelmää tullaan jatkokehittämään projektin jälkeen ja järjestelmän ylläpidon ja jatkokehityksen on oltava mahdollista ilman merkittäviä panostuksia järjestelmään tutustumiseen. Ylläpidettävyys varmistetaan kattavalla dokumentaatiolla, yhtenevällä nimeämis ja koodauskäytännöllä sekä template tekniikoilla. Järjestelmän toteutus on laadullisesti onnistunut, kun nämä laatutavoitteet on saavutettu. 5.2.1.2 Toiminta ja käytännöt laadun varmistamiseksi Laadunvarmistukseen käytetyt testaustasot: Yksikkötestaus tehdään jokaiselle toteutettavalle luokalle ja/tai sivulle järjestelmässä. Tällä varmistetaan luokkien ja/tai sivujen määrittelyjen mukainen toiminta. Integraatiotestaus tehdään toteutetuille toiminnoille esim. käyttäjien lisäys tai pelaajan muokkaus. Järjestelmätestaus kattaa kaikki iteration lopussa valmiina olevat järjestelmän toiminnot. Hyväksymistestaus tehdään viimeisen toteutusiteraation lopussa. Hyväksymistestauksella varmistetaan, että toteutettu järjestelmä vastaa projektin vaatimusmäärittelyä. Good Minton 17 (35)

Laadun varmistamiseen käytetyt testityypit: Toiminnalliset testit. Kaikkia määriteltyjä toimintoja varten suunnitellaan testit, joilla voidaan osoittaa toteutetun toiminnon toimivan suunnitellulla tavalla. Turvallisuus testit. Järjestelmän luonteen vuoksi pyritään varmistamaan syötetyn tiedon turvallisuus järjestelmän syötteiden osalta. Näin estetään tärkeän datan korruptoituminen. Yhteensopivuus testit. Järjestelmää testataan erilaisilla käyttöympäristöillä. Järjestelmän toteutustavan vuoksi lähinnä eri selainten testaamista. Käyttäjätestit. Järjestelmää testataan yhdessä Sulkapalloliiton kanssa hankittujen todellisten käyttäjien kanssa. Tällä varmistetaan järjestelmän käyttäjäystävällinen ja looginen toiminta. Testauksen lisäksi projektin laatua hallitaan seuraavilla tavoilla: Käytetään yhdessä sovittuja nimeämis ja koodauskäytäntöjä. Jokainen projektiryhmän jäsen pyrkii noudattamaan yhdessä sovittuja laatutavoitteita. Projektiryhmän jäsenten tulee myös ilmoittaa heti esille tulleista puutteista tai mahdollisista ongelmista, jolloin niihin voidaan puuttua mahdollisimman nopeasti. Kaikki projektissa tuotetut dokumentit tarkastetaan vähintään johtoryhmässä toimesta ennen niiden palauttamista. Asiakkaalle ja mentorille tiedotetaan projektin etenemisestä viikoittain. Näin saadut kommentit ja mahdolliset parannusehdotukset käsitellään johtoryhmässä. Kehittäjien kanssa kommunikoidaan projektin tavoitteet, eteneminen ja esiin tulleet ongelmat. 5.2.1.3 Laadunvarmistuksen aikataulut ja vastuut 5.2.1.3.1 Laadunvarmistuksen aikataulut Kokoajan Käytetään sovittuja nimeämis ja koodauskäytäntöjä Suoritetaan yksikkötestejä valmistuneille sivuille ja luokille Kommunikoidaan ryhmän kanssa projektiin liittyvistä asioista Ilmoitetaan esiin tulleista ongelmista Varmistetaan tarvittaessa asiakkaalta esiin tulleita asioita Toiminnon tai toiminnallisen kokonaisuuden valmistuttua Suoritetaan integraatiotesti valmistuneille toiminnoille Iteraation lopussa Järjestelmätestaus Turvallisuustestaus Käyttäjätestaus (suoritetaan jo iteraation puolivälissä) Good Minton 18 (35)

Projektin lopussa Koko järjestelmän testaus yhdessä asiakkaan kanssa. Varmistetaan järjestelmän vaatimusten mukainen toiminta. 5.2.1.3.2 Laadunvarmistuksen vastuut Johtoryhmä vastaa Dokumenttien tarkastamisesta ennen palautuksia Projektipäällikkö vastaa viimekädessä kaikesta projektiin liittyvästä. Laatujohtaja vastaa Testauksen suunnittelusta ja aikatauluttamisesta Testauksen raportoinnista suunnitellulla tavalla Vaatimusten hallinnasta projektin prosessin mukaisella tavalla Projektin dokumenttaation laadusta Arkkitehti vastaa Kehittäjien ohjauksesta Projektin kehitystehtävien työnjaosta Koodauskäytäntöjen luonnista Virheiden korjauksesta 5.2.1.4 Testitapaukset Testitapaukset luodaan vaatimusmäärittelyn perusteella ja ne yhdistetään testijoukoiksi järjestelmän pääkäsitteiden mukaisesti. Testitapaukset kerätään kurssin tarjoaman testimatriisin mukaisesti. Tarpeen mukaan voidaan myös luoda erillinen dokumentti testitapauksista, mikäli se on testitapausten hallinnan kannalta järkevää. Testitapauksia luotaessa pyritään kukin toiminto kattamaan mahdollisimman pienellä määrällä testitapauksia. Testitapaukset luodaan iteraation alkuvaiheessa toteutettavaksi päätettyjen toimintojen vaatimusmäärittelyn tarkennusten jälkeen. Toimintojen vaatimuksista luodut testitapaukset tarkastetaan vielä ennen testausta toiminnon toteutuksen aikana mahdollisesti tulleiden muutosten varalta. 5.2.1.5 Testeihin liittyvät dokumentit Testaukseen liittyy seuraavat dokumentit: Testauksen periaatteet (tämä dokumentti ja projektisuunnitelman luku 5.2) Good Minton 19 (35)

Testimatriisi ja mahdollinen lisädokumentti testitapauksista Yhteenveto testauksesta QA raportissa iteraation lopussa 5.2.1.6 Testien tulosten käsittely Testauksen tuloksena löytyneistä virheistä tehdään raportti BugZilla virheidenhallintajärjestelmään. Virheestä ilmoitetaan toiminnosta vastanneelle kehittäjälle, jonka tehtävänä on todentaa virhe ja aloittaa tarvittavat toimenpiteet virheen korjaamiseksi. Arkkitehdin vastuulla on seurata virheiden korjausta. Mikäli jokin osio järjestelmästä osoittautuu virhealtiiksi eli siihen kohdistuu toistuvasti virheitä, on johtoryhmän otettava kyseinen järjestelmän osio tarkasteluun ja päätettävä jatkotoimista. 5.2.1.7 Laadun mittaus Järjestelmän laatua mitataan ensisijaisesti virheiden määrää suhteessa tuotettuihin koodiriveihin. Tarkempaa seurantaa varten voidaan tarvittaessa seurata järjestelmän osiosta löytyneiden virheiden määrää suhteessa järjestelmän osion koodiriveihin. Lisäksi pidetään kirjaa keskimääräisestä virheiden korjausnopeudesta. 5.2.2 Toteutusiteraatioiden laatu 5.2.2.1 Toteutusiteraatio 1 5.2.2.1.1 Testattavat toiminnot Ensimmäisen toteutusiteraation aikana testataan kaikki toteutetut toiminnot. Ensimmäisen toteutusiteraation ainaka testataan myös käyttöliittymää ja käytettävyyttä. Näiden palautteiden perusteella tarvittaessa muokataan käyttöliittymää toteutusiteraation 2 aikana. Mikäli mahdollista niin jo toteutusiteraatiossa 1. Järjestelmän tietojen oikeellisuus on tulosten laskennan kannalta tärkeää, joten toteutusiteraatio 1:n aikana järjestelmälle suoritetaan turvallisuustestejä, joilla pyritään estämään järjestelmän väärinkäytökset ja siten varmistamaan tiedon eheys. 5.2.2.1.2 Testausympäristö ja data Testaukseen käytetään virtuaalipalvelinta, joka on asennettu mahdollisimman yhdenmukaiseksi asiakkaan tuotantoympäristön kanssa. Lisäksi käytetään joko MS Internet Explorer tai Mozilla Firefox selaimia, koska ne ovat yleisimmät käytössä olevat selaimet. Mahdollisuuksien mukaan testataan myös Mac Safari selaimella. Asiakas toimittaa testidataa olemassa olevista kilpailutiedoista, joiden perusteella voidaan todentaa järjestelmän toimivuus. 5.2.2.1.3 Resurssit Testauksesta vastaa laatujohtaja mutta testaukset suoritetaan yhdessä QA ryhmään liitettyjen kehittäjien ja käyttöliittymän suunnittelusta vastaavan kehittäjän kanssa. Asiakas osallistuu käytettävyystesteihin, joko itse tai hankkimalla todellisia loppukäyttäjiä järjestelmän testaamista varten. Testausvälineinä käytetään projektiryhmän omia PC laitteita, joille on asennettu virtuaalipalvelin sovellus. 5.2.2.1.4 Aikataulut Good Minton 20 (35)

03.11. Iteraatio suunnitelma ja laadunvarmistussuunnitelman palautus 07.11. Käyttöliittymän sisäinen tarkastus 10.11. BugZilla virheidenhallinta ohjelmiston käyttöönotto ja ohjeiden jako 13.11. Käyttöliittymän toimitus asiakkaalle testausta varten 20.11. Testaussuunnitelma ja testitapaukset valmiit tarkastusta varten 27.11. Ensimmäinen testauskierros ja testiloki toteutetusta järjestelmästä.(ei suoritettu toteutuksen viivästymisen vuoksi) 04.12. Toinen testauskierros ja testiloki toteutetusta järjestelmästä. 11.12. QA Raportti ja iteraation testilokien palautus 5.2.2.1.5 Testikierrokset Yksikkötestausta suoritettaan valmistuville toiminnoille koko toteutuksen ajan. Toteutettuja toimintoja testataan testitapausten mukaisesti sitä mukaa kun ne valmistuvat ja lisäksi iteraation loppu puolella suoritetaan kaksi kaikki toteutetut toiminnot kattavaa järjestelmätestaus kierrosta. Järjestelmätestauskierroksia on kaksi sen vuoksi, ettei järjestelmää ole voitu testata aikaisemmin yhtenä kokonaisuutena, joten ensimmäisellä kierroksella löydettyjen virheiden korjaukset ehditään vielä testaamaan ennen iteraation loppua. Järjestelmätestaukset pyritään automatisoimaan käyttäen, jotain saatavilla olevaa testausohjelmistoa. Ohjelmistoa ei ole vielä päätetty ja se vahvistuu asiaa käsittelevän SEPA aiheen tutkimuksen myötä. 5.2.2.2 Toteutusiteraatio 2 5.2.2.2.1 Testattavat toiminnot Toisen toteutusiteraation aikana testataan kaikki ensimmäisessä toteutusiteraatiossa toteutetut toiminnot sekä toisessa toteutusiteraatiossa toteutetut toiminnot. Toisen toteutusiteraation aikana testataan myös käyttöliittymää ja käytettävyyttä. Näiden palautteiden perusteella viimeistellään käyttöliittymä kurssin resurssien puitteissa. Ensimmäisen toteutusiteraation toteutuksesta siirrettiin syötetyn tiedon oikeellisuustarkistukset toiseen toteutusiteraatioon ja niihin paneudutaan erityisesti, jotta voidaan varmistaa järjestelmän tietojen oikeellisuus. 5.2.2.2.2 Testausympäristö ja data Testaukseen käytetään virtuaalipalvelinta, joka on asennettu mahdollisimman yhdenmukaiseksi asiakkaan tuotantoympäristön kanssa. Lisäksi käytetään joko MS Internet Explorer tai Mozilla Firefox selaimia, koska ne ovat yleisimmät käytössä olevat selaimet. Asiakas toimittaa testidataa olemassa olevista kilpailutiedoista, joiden perusteella voidaan todentaa järjestelmän toimivuus. 5.2.2.2.3 Resurssit Testauksesta vastaa laatujohtaja mutta testaukset suoritetaan yhdessä QA ryhmään liitettyjen kehittäjien ja käyttöliittymän suunnittelusta vastaavan kehittäjän kanssa. Asiakas osallistuu Good Minton 21 (35)

käytettävyystesteihin, joko itse tai hankkimalla todellisia loppukäyttäjiä järjestelmän testaamista varten. Testausvälineinä käytetään projektiryhmän omia PC laitteita, joille on asennettu virtuaalipalvelin sovellus. 5.2.2.2.4 Aikataulut 16.01. Iteraatio suunnitelma ja laadunvarmistussuunnitelman palautus 20.01. Toteutettavien vaatimusten tarkennus valmis 20.01. Testauskierros ja testiloki toteutetusta järjestelmästä 27.01. Testitapausten tarkennus ja uusien toimintojen testitapaukset valmiit 27.01. Testauskierros ja testiloki toteutetusta järjestelmästä 02.02. Testauskierros ja testiloki toteutetusta järjestelmästä 09.02. Testauskierros ja testiloki toteutetusta järjestelmästä 16.02. Vertaistestausjärjestelyt ja aikataulut valmiit 16.02. Testauskierros ja testiloki toteutetusta järjestelmästä 16.02. Ohjekirjan ensimmäinen versio valmis asiakkaan tarkistettavaksi 17.02. Järjestelmän ja testausohjeiden toimitus vertaisryhmälle 21.02. Vertaistestauksen tulosten palautus vertaisryhmälle 23.02. Testauskierros ja testiloki toteutetusta järjestelmästä 26.02. QA Raportti ja iteraation testilokien palautus 5.2.2.2.5 Testikierrokset Yksikkötestausta suoritettaan valmistuville toiminnoille koko toteutuksen ajan. Toteutettuja toimintoja testataan testitapausten mukaisesti viikoittain. Lisäksi suoritetaan automatisoituja järjestelmätestejä viikoittain. Automatisoidulla järjestelmätestauksella pyritään varmistamaan järjetelmän eheys jokaisen päivityksen jälkeen. Jokaisesta testikierroksesta tehdään testiloki ja löytyneet virheet kirjataan virhetietokantaan. Jokaisella testikierroksella testataan kaikki toiminnot. 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ä. Good Minton 22 (35)

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. 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. Good Minton 23 (35)

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 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ää. Good Minton 24 (35)

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 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 Good Minton 25 (35)

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) Projektin ensimmäisen toteutusiteraation aikataulu on esitetty taulukossa 11. Taulukko 11. Ensimmäisen toteutusiteraation aikataulu pvm tehtävä vastuuhenkilö 3.11.2006 Iteraatiosuunnitelman palautus TM 6.11.2006 GUI layoutin palautus JM 7.11.2006 GUI layoutin katselmointi JM 10.11.2006 BugZillan käyttöönotto ja ohjeet PP 13.11.2006 GUI layout asiakkaalle testattavaksi JE ja JM 20.11.2006 Testaussuunnitelma ja testicaset valmiit TH 27.11.2006 Ensimmäinen testauskierros ja testiloki järjestelmästä PP ja TH 4.12.2006 Toinen testauskierros ja testiloki järjestelmästä PP ja TH 11.12.2006 Iteraation palautukset TM Lisäksi asiakkaan kanssa pidetään ainakin yksi järjestelmän välidemonstraatio. Tälle ei ole sovittu vielä tarkkaa aikaa. 6.3.1 Tavoitteet Ensimmäisen toteutusiteraation aikana ryhmällä on tavoitteena: Tehdä ensimmäinen versio toimitettavasta järjestelmästä. Toteuttaa järjestelmään ensimmäisessä toteutusiteraatiossa suunnitellut vaatimukset. Suunnitella ja toteuttaa käyttöliittymästä ensimmäinen versio, joka olisi kaikkien osapuolien hyväksymä siten. Tavoitteena on, että käyttöliittymään ei viimeisessä iteraatiossa tarvitsisi tehdä enää suuria muutoksia. Testata järjestelmä ja korjata testauksessa löytyneet virheet siten, ettei järjestelmässä olisi enää kuin pieniä virheitä. 6.3.2 Tuotokset 6.3.2.1 Palautettavat dokumentit Projektisuunnitelma (päivitetty) Vaatimusdokumentti (päivitetty) Tekninen spesifikaatio Testitapaukset, testiloki, laadunvarmistusraportti Edistymisraportti SEPA päiväkirjat Good Minton 26 (35)

6.3.2.2 Palautettava järjestelmä Toteutetut vaatimukset on esitty taulukossa 12. Taulukko 12. Ensimmäisessä toteutusiteraatiossa toteutettavat vaatimukset ID F1 F2 F3 F4 F5 F7 F8 F11 F12 F15 F20 F26 F27 Nimi Käyttäjän lisäys Käyttäjän muokkaus Käyttäjän poisto Seuran lisäys Seuran muokkaus Pelaajan lisäys Pelaajan muokkaus Kilpailun lisäys Kilpailun muokkaus Ilmoittautumisen lisäys Tulosten lisäys Käyttäjän sisäänkirjautuminen Käyttäjän uloskirjautuminen Lisäksi järjestelmästä toteutetaan Tietokanta ja sen rajapinta Badminton Tournament Planner ohjelman luoman CSV tiedoston syöttäminen tietokantaan Ranking sääntöjen laskentakaavat ilman käyttöliittymää niiden muokkaukseen Ensimmäinen versio käyttöliittymästä Good Minton 27 (35)

6.3.3 Tehtävät Ensimmäisen toteutusiteraation tehtävät on esitetty taulukossa 13. Taulukko 13. Ensimmäisen toteutusiteraation tehtävät Viikko Projektiryhmä jäsen Tehtävä 43 44 45 46 47 48 49 50 TM JE TF JM TH PP HK OS Viestintä, yleinen 39 3 6 6 6 6 6 6 39 10 6 4 7 3 3 3 3 Viestintä, asiakas 16 6 10 16 2 2 2 2 2 2 2 2 Opiskelu, yleinen 20 4 4 4 4 2 2 20 2,5 2,5 2,5 2,5 2,5 2,5 2,5 2,5 Opiskelu, SEPA 72 8 10 14 14 14 8 4 72 9 9 9 9 9 9 9 9 PM Viikkoraportointi 19 2 3 3 5 3 3 19 11 8 PM Tuntikirjauksen päivittäminen 3 3 3 3 PM Iteraatiosuunnittelu 15 5 10 15 7 4 4 PM Projektisuunnitelman päivittäminen 8 1 2 5 8 3 5 PM Edistymisraportin suunnittelu 9 7 2 9 2 3 4 PM Edistymisraportin esittely 6 6 6 1 1 1 1 0,5 0,5 0,5 0,5 Dev Käyttöliittymän suunnittelu, 1. versio 10 10 10 10 Dev Käyttöliittymän katselmointi 13 13 13 2 2 2 3 2 2 Dev Katselmoinnin perusteella tehtyjen muutosten kirjaaminen 6 6 6 2 4 Dev Asiakkaan palautteen perusteella tehtyjen muutosten kirjaaminen 3 3 3 3 Dev Tietokannan ER kaavion piirtäminen 10 5 5 10 10 Dev ER kaavion katselmointi 9 9 9 2 3 2 2 Dev ER kaavion muutokset katselmoinnin perusteella 1 1 1 1 Dev Prototyypin muokkaaminen kehitystyön rungoksi 4 4 4 4 Dev Kannan SQL luontikäskyt 8 8 8 8 Dev Access tietokannan tiedon siirtäminen uuteen kantaan 16 16 16 16 Dev Tietokannan rajapinnan luominen 16 16 16 16 Dev Käyttöliittymän tuottamien PHP luokkien kirjoittaminen 20 20 20 10 5 5 Dev BTF ohjelman luoman CVS tiedoston kantaan syöttävä luokka 8 8 8 8 Good Minton 28 (35)