Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma

Transkriptio

1 Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys Tuomo Mäkelä Pohja luotu Tuomo Mäkelä Kirjoitettu tekstiä kappaleisiin 2, 3 ja Janne Mäkelä Laajennettu kappaleita 1 ja Tuomo Mäkelä, Tatu Suurin osa kappaleista valmiina Frisk Tuomo Mäkelä Tavoitteet, tekstin korjailua Tuomo Mäkelä Kaikki kohdat paitsi vikojen seuranta ja vaatimusten hallinta Tuomo Mäkelä, Jani Projektin suunnitteluvaiheen lopullinen Eränen Tuomo Mäkelä, Jani Eränen versio Iteraatiosuunnittelun tuotosten liittäminen projektisuunnitelmaan

2 Sisältö: 1 ESITTELY Projektin esittely Terminologia 4 2 SIDOSRYHMÄT JA PROJEKTIORGANISAATIO Projektin yhteystiedot ja roolit Projektin sisäisen organisaation yhteystiedot sekä roolit Asiakasorganisaation yhteystiedot SoberIT:n valvonta ja tukiorganisaation yhteystiedot Muut projektin sidosryhmät 7 3 TAVOITTEET Projektin tavoitteet Henkilökohtaiset oppimistavoitteet 9 4 RESURSSIT JA BUDJETTI Henkilöstö Materiaalit Budjetti 10 5 KÄYTÄNNÖT JA TYÖKALUT Käytännöt Iteratiivinen kehitys Iteraatiosuunnittelu Dokumentointi Riskien hallinta Aikaraportointi Kommunikaatio Iteraatiodemo Vikojen seuranta Versionhallinta Koodauskäytäntö Prosessin kehittyminen Vaatimusten hallinta Suunnittelu Laadunvarmistussuunnitelma Projektin laatu Toteutusiteraatioiden laatu Työkalut Standardit 22 Good Minton 2 (31)

3 6 VAIHEISTUS Aikataulu Projektin suunnittelu Tavoitteet Tuotokset Tehtävät Toteutus 1 (I1) Tavoitteet Tuotokset Tehtävät Toteutus 2 (I2) Tavoitteet Tuotokset Tehtävät 29 7 RISKILOKI 30 Good Minton 3 (31)

4 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 /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 (31)

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

6 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 tuomomakela jani(a)eranen.com ebunny tfrisk(a)cc.hut.fi tatufrisk janne.makela(a)tkk.fi jannetmakela thassine(a)cc.hut.fi hazaah ppalmila(a)cc.hut.fi petripalmila hkostia(a)cc.hut.fi hkostia ostenroos(a)cc.hut.fi ostenroos 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 (31)

7 Taulukko 4. Asiakasorganisaation yhteystiedot Status Nimi Sähköposti Puhelin Asiakas Jukka Antila jukka.antila(a)sulkapallo.org Asiantuntija Mika Heinonen mika.heinonen(a)sulkapallo.fi Asiantuntija Pasi Vilkki pasi.vilkki(a)sulkapallo.fi 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 Kurssin luennoitsija Jari Vanhanen jari.vanhanen(a)tkk.fi 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 (31)

8 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 (31)

9 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 (31)

10 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ö Jani Eränen Laatujohtaja Tatu Frisk Arkkitehti Janne Mäkelä Kehittäjä (proj.pääll.) Timo Hassinen Kehittäjä (laatujoht.) Petri Palmila Kehittäjä (laatujoht.) Henri Kostia Kehittäjä (arkkitehti) Olavi Stenroos Kehittäjä (arkkitehti) Yhteensä 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 (31)

11 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 Laatujohtaja 190 h 60 /h Arkkitehti 190 h 60 /h Kehittäjät 5 * 190 h 50 /h Konsultointi Mentor 40 h 100 /h Laitteisto Ohjelmisto Yhteensä Asiakkaan kustannukset määrä kustannustekijä kustannus Tuotteen hinta (22 % ALV, 15 % tuotto) Sisäinen työ 100 h 60 /h Yhteensä Good Minton 11 (31)

12 5 Käytännöt ja työkalut 5.1 Käytännöt Seuraavassa esitellään projektissa sovellettavat käytännöt 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 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 (31)

13 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 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 (31)

14 Tarkemmat tiedot riskien hallinnasta löytyvät erillisestä riskienhallintadokumentista 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ä 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 (31)

15 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 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 (31)

16 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) 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 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) 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 (31)

17 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 Projektin laatu 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 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 iteraation lopussa valmiina olevat järjestelmän toiminnot. Good Minton 17 (31)

18 Hyväksymistestaus tehdään viimeisen toteutusiteraation lopussa. Hyväksymistestauksella varmistetaan, että toteutettu järjestelmä vastaa projektin vaatimusmäärittelyä. 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 Laadunvarmistuksen aikataulut ja vastuut 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 Good Minton 18 (31)

19 Käyttäjätestaus (suoritetaan jo iteraation puolivälissä) Projektin lopussa Koko järjestelmän testaus yhdessä asiakkaan kanssa. Varmistetaan järjestelmän vaatimusten mukainen toiminta 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 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. Good Minton 19 (31)

20 Testeihin liittyvät dokumentit Testaukseen liittyy seuraavat dokumentit: Testauksen periaatteet (tämä dokumentti ja projektisuunnitelman luku 5.2) Testimatriisi ja mahdollinen lisädokumentti testitapauksista Yhteenveto testauksesta QA raportissa iteraation lopussa 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 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 Toteutusiteraatioiden laatu Toteutusiteraatio 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 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 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. Good Minton 20 (31)

21 Testausvälineinä käytetään projektiryhmän omia PC laitteita, joille on asennettu virtuaalipalvelin sovellus Aikataulut Iteraatio suunnitelma ja laadunvarmistussuunnitelman palautus Käyttöliittymän sisäinen tarkastus BugZilla virheidenhallinta ohjelmiston käyttöönotto ja ohjeiden jako Käyttöliittymän toimitus asiakkaalle testausta varten Testaussuunnitelma ja testitapaukset valmiit tarkastusta varten Ensimmäinen testauskierros ja testilogi toteutetusta järjestelmästä Toinen testauskierros ja testilogi toteutetusta järjestelmästä QA Raportti ja iteraation testi logien palautus 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.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. Good Minton 21 (31)

22 Smarty Skriptikieli, jolla luodaan PHP:n ja HTML:n ylläpidettävällä tavalla yhdistäviä aihioita. Apache Web palvelin. MySQL Tietokantaohjelmisto. SVN Versionhallintaohjelmisto. Repositorio on sijoitettu ATK keskuksen palvelimelle. VMware 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 Työkalu ohjelmakoodin automatisoituun dokumentointiin. Skype 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 Iteraatiosuunnitelman palautus Vaatimusmäärittelyn ensimmäinen versio Good Minton 22 (31)

23 Vaatimusmäärittelyn pohjalta toteutettu prototyyppi Vaatimusmäärittelyn korjattu/muokattu ja katselmoitu versio Projektin suunnittelun tulosten palautus Iteraatiodemo Iteraatiosuunnitelman (I1) palautus Ensimmäisen toteutusiteraation tulosten palautus Iteraatiodemo (I1) Iteraatiosuunnitelman (I2) palautus helmikuun alku Tuotteen demoaminen asiakkaalle ja mentorille Lopputuote vertaistestausryhmälle Vertaisryhmän testaustulosten raportointi Projektin lopputulosten palautus Iteraatiodemo (I2) 6.2 Projektin suunnittelu 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ö Tuotokset Projektisuunnitelma (pl. kappale 5.2 QA suunnitelma) Good Minton 23 (31)

24 Vaatimusdokumentti (pl. yksityiskohtaiset selvitykset kappaleissa 6 8) Edistymisraportti Lisäksi luodaan järjestelmästä prototyyppi, joka ensisijaisesti toimii apuna sisäisessä kehityksessä 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 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. Good Minton 24 (31)

25 Taulukko 11. Ensimmäisen toteutusiteraation aikataulu pvm tehtävä vastuuhenkilö Iteraatiosuunnitelman palautus TM GUI layoutin palautus JM GUI layoutin katselmointi JM BugZillan käyttöönotto ja ohjeet PP GUI layout asiakkaalle testattavaksi JE ja JM Testaussuunnitelma ja testicaset valmiit TH Ensimmäinen testauskierros ja testiloki järjestelmästä PP ja TH Toinen testauskierros ja testiloki järjestelmästä PP ja TH Iteraation palautukset TM Lisäksi asiakkaan kanssa pidetään ainakin yksi järjestelmän välidemonstraatio. Tälle ei ole sovittu vielä tarkkaa aikaa 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ä Tuotokset Palautettavat dokumentit Projektisuunnitelma (päivitetty) Vaatimusdokumentti (päivitetty) Tekninen spesifikaatio Testitapaukset, testiloki, laadunvarmistusraportti Edistymisraportti SEPA päiväkirjat Palautettava järjestelmä Toteutetut vaatimukset on esitty taulukossa 12. Taulukko 12. Ensimmäisessä toteutusiteraatiossa toteutettavat vaatimukset ID F1 F2 Nimi Käyttäjän lisäys Käyttäjän muokkaus Good Minton 25 (31)

26 F3 F4 F5 F7 F8 F11 F12 F15 F20 F26 F27 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 26 (31)

27 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ä TM JE TF JM TH PP HK OS Viestintä, yleinen Viestintä, asiakas Opiskelu, yleinen ,5 2,5 2,5 2,5 2,5 2,5 2,5 2,5 Opiskelu, SEPA PM Viikkoraportointi PM Tuntikirjauksen päivittäminen PM Iteraatiosuunnittelu PM Projektisuunnitelman päivittäminen PM Edistymisraportin suunnittelu PM Edistymisraportin esittely ,5 0,5 0,5 0,5 Dev Käyttöliittymän suunnittelu, 1. versio Dev Käyttöliittymän katselmointi Dev Katselmoinnin perusteella tehtyjen muutosten kirjaaminen Dev Asiakkaan palautteen perusteella tehtyjen muutosten kirjaaminen Dev Tietokannan ER kaavion piirtäminen Dev ER kaavion katselmointi Dev ER kaavion muutokset katselmoinnin perusteella Dev Prototyypin muokkaaminen kehitystyön rungoksi Dev Kannan SQL luontikäskyt Dev Access tietokannan tiedon siirtäminen uuteen kantaan Dev Tietokannan rajapinnan luominen Dev Käyttöliittymän tuottamien PHP luokkien kirjoittaminen Dev BTF ohjelman luoman CVS tiedoston kantaan syöttävä luokka Good Minton 27 (31)

28 Dev Ranking sääntöjen hallinta ja laskeminen Dev Käyttöliittymän Smarty aihioiden totetutus Dev Käyttöliittymän Smarty aihioiden viimeistely Dev Ottelupuun piirtäminen ja käyttöliittymä tulosten lisäämiseen puuhun Dev Käyttöliittymän syötteiden validointi (palvelin, PHP) Dev Käyttöliittymän syötteiden validointi (selain, javascript) Dev Virheiden korjaus, ensimmäinen testauskierros Dev Virheiden korjaus, toinen testauskierros QA Laadunvarmistussuunnittelu QA Bugzillan konfigurointi QA Test Case suunnittelu QA Test case testaus QA Järjestelmätestaus suunnittelu QA Järjestelmätestaus QA Käyttäjätestaus QA Turvallisuustestaus QA Turvallisuustestaus suunnittelu QA Dokumenttien tarkastukset QA Raportin luonti QA Dokumentointi QA Vaatimusmäärittelyjen tarkennus Yhteensä Good Minton 28 (31)

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

30 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 30 (31)