Loppuraportti Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma

Loppuraportti Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys 0.1 2007 02 10 Tuomo Mäkelä Pohja luotu 0.2 2007 02 15 Tuomo Mäkelä Kuvailtu käytäntöjä 1.0 2007 02 26 Tuomo Mäkelä, Jani Eränen Valmis

Sisältö: 1 JOHDANTO 3 1.1 Projektin eteneminen 3 2 TULOSTEN ARVIOINTI 4 2.1 Tavoitteiden toteutuminen 4 2.1.1 Arvio järjestelmän tilasta 5 2.1.2 Puutteet resurssien käytössä 5 2.2 Järjestelmän tila ja kehitettävyys 6 2.2.1 Tunnetut bugit ja toteuttamatta jääneet toiminnot 6 2.2.2 Jatkokehitysideat 6 2.3 Haasteet projektissa 6 2.3.1 Laajuuden rajaaminen 6 2.3.2 Ohjelmointikielten osaaminen 7 3 MITTARIT 8 3.1 Resurssien käyttö 8 3.2 Laatumetriikat 11 3.3 Ohjelmiston koko 13 4 KÄYTÄNNÖT JA TYÖKALUT 14 4.1 Käytännöt 14 4.1.1 Iteraatiosuunnittelu 14 4.1.2 Dokumentointi 14 4.1.3 Riskien hallinta 14 4.1.4 Tuntikirjaus 14 4.1.5 Viestintä 15 4.1.6 Vikojen seuranta 15 4.1.7 Vertaistestaus 16 4.1.8 Versionhallinta 16 4.1.9 Koodauskäytäntö 16 4.1.10 Heuristinen arviointi 16 4.1.11 Refactoring 16 4.1.12 Pariohjelmointi 17 4.1.13 Automatisoitu järjestelmätestaus 17 5 OPETUKSELLINEN ARVO 18 5.1 Henkilökohtainen oppiminen 18 6 KURSSIPALAUTE 21 2

1 Johdanto Tämä on loppuraportti projektista, jossa Suomen Sulkapalloliitolle tehtiin kilpailutoiminnan rekisteriohjelma. Projekti toteutettiin TKK:n kurssilla T 76.4115/5115 Ohjelmistokehitysprojekti kahdeksan hengen projektiryhmässä. Projektissa luotiin Suomen Sulkapalloliitolle uusi kilpailutoiminnan rekisteriohjelma, jonka tavoitteena on korvata vanha käytössä oleva järjestelmä. Järjestelmän tehtävänä on ylläpitää tietoja sulkapallon kilpailutoiminnasta. Tämä edellyttää pelaajien, seurojen, kilpailujen ja tulosten hallintaa. Tulosten pohjalta järjestelmä pystyy ylläpitämään myös sulkapallon ranking listoja. 1.1 Projektin eteneminen Projekti kesti viisi kuukautta lokakuun alusta 2006 helmikuun loppuun 2007. Projekti vietiin läpi kolmessa iteraatiossa: Projektin suunnitteluiteraatiossa ja kahdessa toteutusiteraatiossa. Projektin suunnitteluiteraatiossa luotiin käytäntöjä tulevalle toiminnalle. Asiakkaan kanssa käytiin keskusteluita tulevan järjestelmän vaatimuksista. Vaatimusten pohjalta järjestelmästä luotiin prototyyppi, jonka avulla testattiin ohjelmointiympäristöä, otettiin kehittäjät sisään järjestelmän kehittämiseen ja testattiin tulevan järjestelmän rakennetta. Ensimmäisen toteutusiteraation alussa oli ongelmia käyttöliittymän suunnittelun kanssa, mikä hieman hidasti kehitystyötä. Iteraation aikataulu oli varsin tiivis. Kun tietokanta ja käyttöliittymä oli saatu vahvistettua, päästiin varsinaiseen kehitystyöhön. Kehitystyö vei enemmän aikaa kuin suunniteltiin ja iteraation laajuutta jouduttiin rajaamaan. Silti järjestelmää ei ehditty testaamaan yhtä hyvin kuin suunnitelmana oli. Toisessa toteutusiteraatiossa toteutettiin ensin ensimmäisessä toteutusiteraatiossa toteuttamatta jääneet toiminnallisuudet ja keskeisimmät toiminnallisuudet, jotka oli jätetty toiseen toteutusiteraatioon. Tämän jälkeen keskityttiin enemmän järjestelmän virheiden korjaukseen. Kaikki toiminnallisuudet saatiin hyvään kuntoon lukuun ottamatta nelinpelitulosten syöttämistä puukaavioon ja ranking kaavojen luomista muille kuin yleisille luokille. 3

2 Tulosten arviointi 2.1 Tavoitteiden toteutuminen Projektin tavoitteet asetettiin projektin alussa yhdessä asiakkaan kanssa. Niiden toteutumiskriteerit on määritelty pääosin siten, että asiakas arvioi tavoitteiden toteutumisen. Järjestelmä palautetaan asiakkaalle samaan aikaan kuin muut dokumentit, joten asiakkaan arvioita liiketoimintatavoitteiden toteutumisesta emme ole saaneet. Seuraavassa on kuitenkin arvioitu sanallisesti, miten itse koemme tavoitteiden toteutuneen. Taulukko 1. Liiketoimintatavoitteet ja niiden toteutuminen Asiakkaan liiketoimintatavoitteet Toteutumiskriteeri 1. Tavoitteena on korvata vanha järjestelmä. Toteutuu, jos uusi järjestelmä otetaan käyttöön Suomen Sulkapalloliitossa. Koska nelinpelitulosten tallentaminen jäi järjestelmästä toteuttamatta, järjestelmään jäi puute, joka vaatii jatkokehitystä ennen kuin järjestelmä voidaan ottaa käyttöön Suomen Sulkapalloliitossa. 2. Tavoitteena on parantaa yhteensopivuutta seuroissa käytettävien ohjelmien ja liiton kilpailutoiminnan rekisteriohjelman kanssa. Asiakas arvioi projektin lopussa, onko yhteensopivuus seuroissa käytettävien ohjelmien ja liiton kilpailutoiminnan rekisteriohjelman kanssa riittävä. Järjestelmään on mahdollisuus syöttää BTP kilpailunhallintaohjelman tulostiedostoja. 3. Tavoitteena on vähentää Sulkapalloliiton Asiakas ja projektiryhmä arvioivat, onko työmäärää tarjoamalla seuroille kilpailutietojen tallentaminen mahdollisuutta tallentaa kilpailutietoja. mahdollistettu vaatimuksiin kirjatulla tavalla. Seurojen on mahdollista hallita tietoja järjestelmän kautta. Järjestelmään ei kuitenkaan pysty syöttämään nelinpelin tuloksia, mikä tekee kilpailujen tulosten hallinnan puutteelliseksi. 4. Tavoitteena on helpottaa pelaajaluetteloiden ja ranking tietojen tuottamisesta. Asiakas arvioi projektin lopussa, onko tavoite toteutunut. Järjestelmä osaa tuottaa erilaisia pelaajaluetteloita. Ranking tietojen tuottaminen on mahdollista yleisten luokkien osalta, mutta juniori ja eliittisarjojen osalta rankingtietojen tuottamista ei ole toteutettu. 5. Tavoitteena on parantaa helppokäyttöisyyttä. Asiakas arvioi projektin lopussa, onko tuote helppokäyttöinen. Järjestelmään pyrittiin luomaan intuitiivisesti toimiva käyttöliittymä. Käytettävyyttä varmistettiin heuristisin analyysein. Varsinaisia käyttäjätestejä ei kuitenkaan toteutettu asiakkaan tekemää pikaista testausta lukuun ottamatta. Järjestelmä on siinä määrin monimutkainen, että käytettävyyttä on varmasti mahdollista parantaa, kunhan todelliset käyttäjät pääsevät tositoimiin järjestelmän pariin 6. Tavoitteena on uuden järjestelmän päivitettävyys ja ylläpidettävyys tulevien sääntömuutosten varalta. Asiakas ja projektiryhmä arvioivat, onko sääntöjen päivitettävyys ja ylläpidettävyys toteutettu vaatimuksiin kirjatulla tavalla. Järjestelmän kautta voidaan muokata rankingin laskentakaavoja tulevien sääntömuutosten varalta. 7. Tavoitteena on historiatietojen helppo Asiakas arvioi projektin lopussa, onko hallinta, saatavuus ja varmistus. tavoite toteutunut. Järjestelmässä on mahdollista muokata historiatietoja ja järjestelmän ollessa webpohjainen, ne ovat helposti saatavilla 4

8. Tavoitteena on toteuttaa seuroille tarjottava kilpailuunilmoittautumisjärjestelmä. Toteutuu, jos ilmoittautumisjärjestelmä on sisällytetty uuteen järjestelmään. Järjestelmään on toteutettu seuroille mahdollisuus ilmoittautua pelaajia kilpailuihin. 2.1.1 Arvio järjestelmän tilasta Järjestelmän puutteet ovat, että nelinpelitulosten syöttö puukaavioon jäi toteuttamatta ja rankingpisteitä ei ole mahdollista laskea kuin yleisten luokkien osalta. Kaksinpelitulosten syöttäminen on kuitenkin toteutettu ja nelinpelitulosten syöttäminen on sama asia mukailtuna. Pohja jatkokehitykselle on siis olemassa. Nelinpelitulosten syöttämisen poisjääminen johtui ensisijaisesti suunnitteluvirheestä, koska tehtävän jakaminen unohtui iteraatiosuunnittelussa. Kun puute huomattiin iteraation edetessä, tehtävä jaettiin eteenpäin, mutta aikaa tehtävän tekemiseen ei kuitenkaan löytynyt. Projektin lopussa luovuimme tehtävästä, koska riittävää aikaa järjestelmän testaamiseen ei ollut sen varalta, ettei toiminto olisi toiminut kunnolla tai se olisi aiheuttanut ongelmia järjestelmän muihin osiin. Ranking sääntöjen osalta laskukaavat yleisille luokille on tehty. Eliitti ja junioriluokkien osalta ranking säännöt noudattelevat kuitenkin yleisten luokkien periaatteita, joten suurin työ tämän kohdan osalta on jo tehty. Ranking sääntöjen jääminen kesken johtui ensinnäkin siitä, että rankingsääntöjen vaatimukset kirjattiin projektin alussa puutteellisesti, eikä niiden vaatima työmäärä ollut täsmälleen tiedossa. Yllätyksenä tuli, että ranking sääntöjä tulisi tehdä useampia erilaisia. Toiseksi ranking sääntöjen tekeminen jäi kesken muiden aikatauluongelmien takia. Tehtävä oli kuitenkin niin monimutkainen luonteeltaan, ettei sen tekemistä ollut järkevää siirrellä. Kaikki muut toiminnot saatiin toteutettua ja järjestelmä on niiltä osin valmis. Muussa järjestelmässä ei myöskään ole tunnettuja bugeja. Järjestelmää on testattu runsaasti. Ryhmän arvion järjestelmän laadusta on hyvä. Koska emme ole palauttaneet järjestelmää asiakkaalle, emme ole saaneet heidän arviotaan järjestelmän laadusta. Vertaistestauksesta saatu palaute tukee sitä, että järjestelmä on toiminnallisuuksien osalta hyvässä kunnossa. Vertaistestauksessa löydetyt virheet olivat jo aiemmin tunnettuja, jotka myöhemmin korjattiin, tai käytettävyyteen liittyviä parannusehdotuksia. Lisäksi osa palautteesta oli sellaista, että parannusehdotuksia annettiin kohtiin, jotka oli asiakkaan kanssa sovittu toteutettavaksi toteutetulla tavalla. 2.1.2 Puutteet resurssien käytössä Käytimme projektissa tunteja 1401 suunnitellun 1520 sijaan. Eniten tuntien kertymistä olisi helpottanut, jos kehittäjille olisi saanut enemmän tunteja projektin suunnitteluiteraatiossa. Suunnitteluiteraation töitä oli kuitenkin vaikea jakaa siten, että kaikille olisi kertynyt töitä. Toiseksi projektin tuntien hallinnassa ongelmia aiheutti se, että osa projektiryhmästä teki projektin ohella täyttä työviikkoa. Tämä aiheutti suuria haasteita projektin tuntien hallinnan lisäksi myös useamman projektiryhmän jäsenen henkilökohtaiselle ajanhallinnalle. Lisäksi projektin kannalta ongelmaksi muodostui, etteivät johtoryhmän jäsenet pystyneet allokoimaan tunteja projektiin juuri silloin, kun se olisi ollut projektin kannalta järkevää. Tunteja kyllä kokonaisuutena pystyttiin laittamaan projektiin riittävästi, mutta välillä saattoi tulla ajanjaksoja, jolloin tuntien irrottaminen oli vaikeampaa. Tämä aiheutti toisinaan sitä, ettei kehittäjille pystytty jakamaan uusia tehtäviä, koska 5

se olisi vaatinut alkuun työtä johtoryhmältä. Tämä ongelma olisi ollut ehkäistävissä sillä, että ajankäytön ja tehtävien suunnittelu niin projektin kuin henkilökohtaisen elämän tasollakin olisi ollut parempaa. Tavoitteenamme projektissa oli aloittaa työt heti uudenvuoden jälkeen, koska jo ensimmäisen toteutusiteraation jälkeen huomasimme, että tuntien saaminen täyteen tulisi olemaan haastavaa. Projektissa oli kuitenkin useampia avoinna olevia kysymyksiä, joiden ratkaisemiseksi olisimme tarvinneet palaveria asiakkaan kanssa. Asiakas kuitenkin sattui olemaan juuri joulukuun lopussa ja tammikuun alussa kiireinen ja toivomamme palaveri ennen joulun pyhiä siirtyi lopulta kolme viikkoa edemmäs tammikuun toiselle viikolle. Tämä hidasti projektin etenemistä merkittävästi. Ryhmässämme oli kaksi tuotantotalouden opiskelijaa, projektipäällikkö Tuomo Mäkelä ja Janne Mäkelä. Kumpikaan heistä ei osallistunut varsinaiseen ohjelmointityöhön, koska ohjelmointitaidot eivät olleet lähtökohtaisesti sillä tasolla, että tämä olisi ollut tehokasta. Tämä kuitenkin aiheutti etenkin Jannen kohdalla ongelman löytää sopivia tehtäviä. Sikäli kun projektin tunneista vain kolmasosa oli ohjelmointia, olisi tämä ongelma ollut väistettävissä roolien jakamisella projektin alkuvaiheessa. 2.2 Järjestelmän tila ja kehitettävyys 2.2.1 Tunnetut bugit ja toteuttamatta jääneet toiminnot Järjestelmässä on yksi bugi, nelinpelitulosten syöttäminen. Käytännössä tämä on kuitenkin toteutumatta jäänyt toiminto. Ranking sääntöjen toteuttaminen eliitti ja junioriluokkien osalta jäi tekemättä. Ranking säännöt ehdittiin toteuttaa vain yleisten luokkien osalta. 2.2.2 Jatkokehitysideat BTP tiedoston syöttäminen on varsin keskeinen osa järjestelmää. Tämä kohta toimii, mutta sen helppokäyttöisyyttä on mahdollista parantaa entisestään. Nykyisellään BTP tiedoston syöttäminen järjestelmään vaatii käyttäjältä tarkkaavaisuutta. Järjestelmän käytettävyyttä on varmasti mahdollista parantaa monessa suhteessa. Eräs selvimmistä kehityskohteista on tulosten syöttäminen puukaavioon. Jos sarjassa on paljon pelaajia, puukaavio kasvaa varsin suureksi, mikä vaikeuttaa puukaavion hahmottamista ja näin ollen tulosten syöttämistä. 2.3 Haasteet projektissa 2.3.1 Laajuuden rajaaminen Projekti oli sikäli ongelmallinen, että siten laajuutta oli vaikea rajata. Asiakkaan antamista vaatimuksista oli suurin osa toteutettava, jotta järjestelmä oli toimiva. Järjestelmän palaset, pelaajat, seurat, kilpailut ja tulokset, linkittyivät toisiinsa siten, että yhden kokonaisuuden puuttuminen olisi vaikeuttanut muidenkin järjestelmän osien toimintaa. Kokonaisuudessaan projektin laajuus oli sopiva, mutta ensimmäisessä toteutusiteraatiossa tämä aiheutti ongelmia, kun toimivan järjestelmän toteuttaminen vaati erittäin runsaan toiminnallisuuden toteuttamista. 6

2.3.2 Ohjelmointikielten osaaminen Ohjelmointi tapahtui PHP:lla, Smartylla ja MySQL:lla. Kaikki ohjelmointiin osallistuneet kehittäjät osasivat entuudestaan PHP:ta, mutta osa ohjelmoijista joutui vahvistamaan taitojaan, jotta saivat ohjelmointitaitona riittäväksi projektin vaatimuksiin. Ongelmia aiheutti myös melko monimutkainen arkkitehtuurinen rakenne, jollaisen parissa työskenteleminen oli osalle kehittäjistä entuudestaan vierasta. Smarty puolestaan oli suurimmalle osalle kehittäjistä entuudestaan vieras ja tätä jouduttiin opiskelemaan. Kokonaisuutena verrattaessa vastaavien komponenttien kehitystyöhön kulunutta aikaa ensimmäisen ja toisen toteutusiteraation aikana, havaitaan, että kehitykseen käytetty aika oli toisessa toteutusiteraatiossa alhaisempi. Tämä antaa viitteitä siitä, että kehittäjät kehittyivät ensimmäisen toteutusiteraation aikana ohjelmoijina suhteessa järjestelmäämme. Täsmällisiä indikaattoreita tästä on vaikea antaa, koska ohjelmointitehtävät eivät ole identtisiä ja toisaalta ohjelmiston rivien määrän avullakaan ei luotettavaa vertailua pysty tekemään, koska toisessa toteutusiteraatiossa virheiden korjaukseen käytetty aika oli huomattavasti suurempi. 7

3 Mittarit 3.1 Resurssien käyttö Seuraavassa esitetyt tuntien käytön luvut ovat arvioita, koska numerot tuntikirjauksesta oli käytännön syistä pakko ottaa ennen kuin kaikkea projektin työtä oli vielä tehty. Kuitenkin käytännössä arviot ovat varsin tarkkoja ja käsittävät lähinnä vain viimeisen viikonlopun ja palautusviikon työtunteja. Projektiin oli jokaiselle projektiryhmän jäsenelle laskettu työpanokseksi 190 tuntia, kun jokainen projektiryhmän jäsen teki myös SEPA:n. Kokonaisuudessaan projektiryhmällä oli tunteja käytettävissä 1520 ja niitä lopulta käytettiin 1401. Vajausta budjetoiduista tunneista jäi 119 tuntia eli 7,8 %. Projektiryhmän jäsenille kertyneet tunnit on esitetty taulukossa 2 ja kaaviossa 1. Taulukko 2. Käytetyt tunnit kehittäjittäin PP I1 I2 yht Jani Eränen 56 55 83 194 Tatu Frisk 38 102 58 198 Timo Hassinen 21 64 91 176 Henri Kostia 16 49 86 150 Janne Mäkelä 15 32 80 126 Tuomo Mäkelä 77 61 54 192 Petri Palmila 20 80 87 187 Olavi Stenroos 29 66 85 179 yhteensä 271 508 622 1401 Tuntien jakautuminen kehittäjittäin tuntia 200 180 160 140 120 100 80 60 40 20 0 I2 I1 PP Jani Eränen Tatu Frisk Timo Hassinen Henri Kostia Janne Mäkelä Tuomo Mäkelä Petri Palmila Olavi Stenroos Kaavio 1. Tuntien jakautuminen kehittäjille eri iteraatioissa 8

Tuntien kertyminen viikoittain on esitetty kaaviossa 2. Tunteja kertyi melko tasaisesti, paitsi vuodenvaihteessa tuli projektiin selvä tauko ja toisaalta projektin lopussa saatiin tehtyä viikoilla enemmän tunteja. Kuitenkin joka viikko olisi pitänyt pystyä lähelle 80 tuntia. Tuntien kertymä viikoittain tuntia 160 140 120 100 80 60 40 20 1600 1400 1200 1000 800 600 400 200 0 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 2 3 4 5 6 7 8 9 viikko 0 Tunnit viikoittain Tuntien kertymä Kaavio 2. Tuntien kertyminen viikoittain Projektin tuntien kertymä työtavoittain on esitetty kaaviossa 3 ja 4. Lukemat lienevät varsin tyypillisiä kurssilla käydylle ohjelmistoprojektille. Toisaalta tehtävien jaotteleminen eri kategorioihin ei ole aina kovin täsmällistä, kun löytyy tehtäviä, jotka pystyy perustellusti laittamaan useampaan kategoriaan. 9

300 Tuntien jakautuminen tehtävittäin iteraatioissa 250 200 tuntia 150 100 50 0 Opiskelu Viestintä Projektin hallinta Laadunvarmistus Ohjelmointi Suunnittelu Infra SEPA PP I1 I2 Kaavio 3. Tuntien kertyminen tehtävittäin eri iteraatioissa Tuntien jakautuminen tehtävittäin 4 % 3 % 9 % 5 % 18 % Opiskelu Viestintä Projektin hallinta Laadunvarmistus 10 % Ohjelmointi Suunnittelu 34 % Infra 17 % SEPA Kaavio 4. Tuntien jakautuminen tehtävittäin 10

3.2 Laatumetriikat Laadun mittarina on sovittu käytettävän virhettä per 1000 koodiriviä eli virheitä / KLOC, ja I2 lopussa tehdyn testitapaus testauksen mukaan tilanne on 1 virhe / 18690 LOC ~ 0 virhettä / KLOC. Koko elinkaaren aikana löydettyjen virheiden määrä on 45 / 18690 LOC ~ 2,41 virhettä / KLOC. Kaaviossa 5 on esitetty virheiden kokonaismäärä suhteessa tuhanteen riviin koodia. Total Defects per KLOC 3,00 2,50 2,00 1,50 Total Defects per KLOC 1,00 0,50 0,00 06 12 01 06 12 15 07 01 01 07 01 15 07 02 01 07 02 15 07 02 26 Kaavio 5. Löydettyjen virheiden määrä suhteessa tuhanteen riviin ohjelmakoodia Taulukossa 3 on esitetty tämän hetkinen virhetilanne. Kurssin aikataulujen puitteissa pyrittiin korjaamaan kaikki Blocker, Critical ja Major luokan virheet mutta yksi vakava Major luokan virhe vielä jäi toteutukseen. Kyseinen virhe liittyy nelinpelitulosten syöttöön. Toiminto ei ole valmis, joten se on kirjattu virheenä virhetietokantaan. Taulukko 3. Löydetyt virheet tyypeittäin Blocker Critical Major Minor Trivial Yhteensä Löydetty Iteraatiossa 1 Löydetty Iteraatiossa 2 0 2 10 8 3 23 2 0 6 9 5 22 Löydetty yhteensä 2 2 16 17 8 45 Avoinna 0 0 1 0 0 1 11

Taulukossa 4 on esitetty käsitykset eri järjestelmän osien laadusta. Taulukko 4. Järjestelmän eri toiminnallisuuksien laadun tila (1=huono, 2=tyydyttävä, 3=hyvä) Järjestelmän osa Laatu Kommentit laadusta Luottamus Kommentit Luottamuksesta Kilpailukalenteri 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Kilpailut 3 Toiminnon toteutus on valmis,nelinpelin tulosten syöttöä lukuunottamatta, ja löydetyt virheet on korjattu. Pelaajat 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Seurat 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Käyttäjät 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Ranking säännöt 2 Toiminnon toteutus on valmis. Toimintoa ei ole testattu tarpeeksi. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 2 Ranking säännöt ovat erittäin monimutkaiset ja tämä osa alue tarvitsee vielä lisää testausta. 12

3.3 Ohjelmiston koko Ohjelmiston kokoa mitataan lähdekoodin rivien määrällä. Lähdekoodin rivien määrä oli projektin lopussa 18690 riviä. Ohjelmiston koon kehitys on esitetty kaaviossa 6. SLOC 20000 18000 16000 14000 12000 SLOC 10000 SLOC 8000 6000 4000 2000 0 06 11 01 06 11 08 06 11 15 06 11 22 06 11 29 06 12 06 06 12 13 06 12 20 06 12 27 07 01 03 07 01 10 07 01 17 07 01 24 07 01 31 07 02 07 07 02 14 07 02 21 Date Kaavio 6. Järjestelmän lähdekoodin koko 13

4 Käytännöt ja työkalut 4.1 Käytännöt Seuraavassa esitellään projektissa sovellettavat käytännöt. 4.1.1 Iteraatiosuunnittelu Iteraatiosuunnittelusta vastasi johtoryhmä projektipäällikön johdolla. Johtoryhmä hahmotteli iteraation tehtäviä ja asiakkaan kanssa käydyn palaverin jälkeen löi lukkoon iteraatioon tulevat tehtävät ja iteraation aikataulun. Tehtäville annettiin täsmälliset aika arviot, toteutusajat ja tehtävät määrättiin kehittäjille. 4.1.2 Dokumentointi Dokumentoinnissa käytettiin hyväksi kurssin antamia rakennepohjia. Ne dokumentit, joille valmista pohjaa ei ollut annettu, toteutettiin samojen periaatteiden mukaan, jotta dokumentit olivat yhdenmukaisia yleiseltä rakenteeltaan. 4.1.3 Riskien hallinta Riskien hallinnassa käytettiin Deplhi metodia. Riskien kartoitus tehtiin kaksi kertaa projektin kuluessa, molemmissa iteraatioiden vaihteissa. Riskien kartoitus toimi siten, että jokainen projektiryhmän jäsen ja asiakas arvioivat asteikolla yhdestä viiteen riskien toteutumisen todennäköisyyttä ja niiden vaikuttavuutta. Luvut kerrottiin yhteen ja kaikkien antamista luvuista laskettiin keskiarvo, joka kuvasti projektin riskiä. Riskikartoituksen tekeminen auttoi oivaltamaan projektin mahdollisia riskejä ja projektin edetessä ne oli helppo pitää mielessä ja miettiä, mitä ongelmia saattaisi ilmetä. Erityisen mielenkiintoinen riskikartoitus oli toisella kerralla, jolloin oli nähtävissä, miten eri riskit olivat kehittyneet. 4.1.4 Tuntikirjaus Tuntikirjauksessa käytettiin Journyx ohjelmaa. Tuntien kirjaamisen kannalta Journyx toimi siten, että siinä valittiin pudotusvalikoista projekti, sitten tehtävä yksitasoisesta listasta. Tämän jälkeen voitiin viikon sisällä syöttää seuraaviin sarakkeisiin tuntimääriä eri viikon päivien kohdalle. Tehtäviä pystyi myös kommentoimaan. Hallinnan puolelta tuntikirjaukseen piti ensin luoda tehtävät. Raportteja pystyi järjestelmästä ottamaan monenlaisia, mutta aika arvioita tehtäville ei pystynyt asettamaan. Käytännössä tuntikirjauksen raportointi toteutettiin siten, että tuntikirjauksesta tunnit siirrettiin käsin Exceltaulukkoon, jossa tehtävien suunnittelu oli toteutettuna. Tuntikirjauksen selkeyttämiseksi emme siirtäneet kaikkia tehtäviä Journyxiin, vaan joitain tehtäviä yhdisteltiin, jotta tehtävien määrä pysyi inhimillisenä. Käytännössä tämä toimi hyvin aina, kun oli tiedossa, mikä henkilön tehtävä oli ollut edellisellä viikolla tai henkilö oli kirjoittanut kommenttisarakkeeseen, mihin käytännössä oli tunteja käyttänyt. Käytännössä kommenttisaraketta olisi voinut käyttää useammin täsmentämään tehtyjä tehtäviä, mutta kokonaisuutena tuntikirjaus toimi hyvin. 14

4.1.5 Viestintä Projektimme viestintä projektiryhmän sisällä toteutettiin pääosin sähköpostin ja Skypen avulla. Varsinkin Skype viestintävälineenä toimi hyvin. Ainoa ongelma Skypen käytössä oli, että kaikki projektiryhmän jäsenet eivät olleet erityisen aktiivisesti Skypessä ja kaikkien jäsenten tavoittaminen varsinkin silloin kun se olisi ollut asiaa, oli Skypellä huonoa. Skype soveltuu projektin viestintävälineeksi erityisen hyvin silloin, kun projektiryhmän jäsenten tavoitettavuus sen kautta on hyvä. Käytännössä paljon projektiryhmän sisäistä viestintää toteutettiin sähköpostin avulla. Varsinkin tiedotusluontoiset asiat, jotka eivät vaatineet keskustelua, hoidettiin usein sähköpostin kautta. Sähköpostin etuna on, että asiat voi viestiä kaikille silloin kun itsellä on parhaiten aikaa ja vastapuoli taas voi lukea sähköpostin silloin kun hän itse ehtii koneelle. Kuitenkin toisinaan asioissa, jotka vaativat keskustelua tai sopimista ja sähköposti osoitti heikkoutensa, kun vastauksen saamiseen tulee aina viivettä. Ehkä jonkinlainen käytäntö siitä, että sähköpostiviestit kuitattaisiin luetuiksi, vaikka niihin ei heti ehdittäisi vastatakaan, olisi ollut paikallaan. Ryhmän sisäisiä palavereita pidettiin erittäin vähän. Viestinnässä olisi varmasti ollut parannettavaa. Toisinaan ehkä ongelma saattoi tuntua olevan tiedonkulussa, vaikka todellisuudessa se saattoi ollakin siinä, että projektin johtoryhmällä ollut aikaa miettiä asioita, eikä mitään tiedotettavaa. Viestintä usein kulkee käsi kädessä projektin yleisen hallinnan kanssa. Silloin kun projekti sujuu hyvin, niin asioista tiedottaminenkin on helppoa, kun voidaan edetä suunnitelman mukaisesti. Ehkä joissain tilanteissa olisi pitänyt herkemmin tarttua puhelimeen, jotta asiat olisi saanut selvitettyä heti. Projektiryhmän sisäiset palaverit olisivat varmasti helpottaneet viestintää ja luoneet parempaa rytmiä palaveriin. Käytännössä kuitenkin, kun useampi projektiryhmän jäsen oli töissä, olisi palavereiden pitäminen mihinkään järkevään aikaan ollut hankalaa. Toisaalta palaverit olisivat syöneet ehkä tarpeettomasti tunteja. Varsinkin jos huomioi sen, että projektiryhmän jäsenet olisivat saattaneet joutua tulemaan ainoastaan palaverin takia pitkän matkan takaa Otaniemeen. Asiakkaan suuntaan viestintää toteutettiin pääosin sähköpostin välityksellä. Aika ajoin ongelmaksi muodostui, että asiakas vastasi sähköposteihin varsin pitkällä viiveellä, mikä jossain kohdin hidasti tai muokkasi projektin etenemistä. Ehkä etenkin asiakkaan suuntaan olisi ollut hyvä sopia käytännöstä, joissa sähköpostit kuitattaisiin luetuiksi, vaikka niihin ei heti ehdittäisikään vastata. Monet asiakkaalta kysytyt kysymykset olivat luonteeltaan sellaisia, että vastauksen antaminen niihin vaati pientä mietintää, joten puhelimen käyttö ei olisi tehostanut viestintää. Asiakkaan kanssa pidettiin myös palavereita. Palaverit kuitenkin rajoittuivat pääosin kurssin puolelta olleisiin sääntömääräisiin tapaamisiin. Kurssille ja Mentorille viestittiin pääosin viikkoraportoinnin kautta. Kokonaisuutena ei täysin selvinnyt, ketkä kaikki ja kuinka aktiivisesti viikkoraportointia lukivat, olihan se kaikille avoimena netissä ja lukukerrat olivat yleensä suurempia kuin kaksi tai kolme. Viikkoraportointi käsitti sanallisen selvityksen projektin etenemisestä, yksityiskohtaisen taulukon tuntikirjauksesta ja käyrät, jotka kuvasivat tuntien käyttöä. Mentorilta tuntikirjauksesta saatu palaute oli positiivista, joten ilmeisesti tämä viestintä täytti sille asetetut vaatimukset. 4.1.6 Vikojen seuranta 15

Vikojen seurantaa tehtiin Bugzillan avulla. Kaikki virheet, jotka löydettiin testauksessa, kirjattiin Bugzillaan, ellei virhettä kyetty korjaamaan saman tien. Virheiden korjausta ohjattiin kehittäjille myös Bugzillan kautta. 4.1.7 Vertaistestaus Vertaistestaus toteutettiin ristiin Vitamin B ryhmän kanssa. Vertaisryhmän aiheena oli ASSEMBLY Party Management System. Testaus järjestettiin Maarin talolla siten, että neljän tunnin aikana simuloitiin assemblypartyt pienoiskoossa. Lisäksi kaksi Vitamin B projektiryhmän jäsentä teki SEPA:n käytettävyystutkimuksesta, joka toteutettiin vertaisryhmän avulla fake partyn aikana. Testaussessio vedettään läpi sunnuntai iltapäivän aikana Maarin talolla ja siihen osallistuu sekä Vitamin B projektiryhmä että heidän asiakkaansa edustajia. Good Minton järjestelmän testaus toteutettiin skenaariopohjaisten ohjeistusten avulla virtuaalipalvelinta vasten. Järjestimme testausryhmälle julkisessa verkossa olevan palvelimen, jossa oli sen hetkinen vakaa versio Good Minton järjestelmästä. Testaajille toimitettiin Test Session chartterit sekä hieman taustatietoja järjestelmästä. Testaajia pyydettiin käymään läpi neljä erilaista skenaariota. Skenaarioissa keskityttiin järjestelmän peruskäyttöön ja sen yleisimpiin toimintoihin. Testaajat testasivat järjestelmän ja palauttivat testilokit suorittamistaan testeistä. Järjestelmästä löytyi yksi uusi virhe ja muutamia testaajien virheiksi luokittelemia toimintoja, jotka olivat kaikki asiakkaan kanssa sovittuja toimintatapoja. Vertaistestauksesta tuli esille muutamia käytettävyyteen liittyviä asioita. Yleisesti ottaen vertaistestausryhmän mielestä järjestelmä tuntui olevan hyvässä kunnossa ja löydökset olivat enemmänkin käytettävyyteen liittyviä kohtia, jotka parantaisivat ohjelman laatua. 4.1.8 Versionhallinta Projektin versionhallinta asennettiin ATK keskukselle, josta se oli kaikkien projektiryhmän jäsenten tavoitettavissa. Versionhallintaan lisättävä koodin oli määrä olla kommentoitua ja toimivaa. Versionhallinnan käytössä ei sinänsä ollut ongelmia, mutta muutaman kerran, kun versionhallintaan lisättiin koodia tai sitä korjailtiin, vioittui muun järjestelmän toiminta. Nämä ongelmat kuitenkin saatiin korjattua aina suhteellisen nopeasti. 4.1.9 Koodauskäytäntö Ohjeet koodauskäytännöstä ja projektissa tuotetun koodin tyylistä toteutettiin mallitiedostona, johon oli kirjattuna ohjeet ohjelmakoodin ulkoasusta ja kommentointikäytännöstä. 4.1.10 Heuristinen arviointi Teimme SEPAn heuristisesta analyysistä. Analyysi tehtiin projektin aikana kaksi kertaa kummankin iteraation aikana. Heuristinen menetelmä osoittautui hyväksi tavaksi selvittää käyttöliittymässä olevia parannettavia asioita. Heuristinen analyysi kannattaa ehdottomasti jatkossakin säilyttää yhtenä mahdollisena SEPA aiheena. Varsikin projektit, joissa on painoarvoa käyttöliittymässä voivat kokea heuristisen analyysin erittäin hyödylliseksi. 4.1.11 Refactoring 16

Koodin uudelleen järjestely eli refactoring toteutettiin projektissa SEPA aiheena. Koodin uudelleenjärjestely tarkoittaa kirjoitetun koodin muokkaamista paremmin ja helpommin luettavaksi. Tämän toteuttamiseksi muokataan komponentin sisäistä rakennetta. Komponentin ulkoista toiminnallisuutta ei muuteta. Projektissa käytiin läpi käyttöliittymän koodi. Siihen tehtiin kirjan Refactoring: Improving the Design of Existing Code (Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts) opastamana muutoksia, samalla testaten joka vaiheessa että uusia bugeja ei ilmaantunut. Koodin muutoksia tehtiin ensin kahden hengen SEPA ryhmässä, mutta tämän perusteella huomattiin, että on nopeampaa ja tehokkaampaa jakaa työt puoliksi ja tehdä muutokset yksitellen. Koodin uudelleenjärjestäminen sopi kohtalaisesti PHP kielellä tuotetun koodin parantamiseen; useimmat uudelleenjärjestämiset liittyvät luokkiin, joita ei vielä PHP 4:ssa ole toteutettu parhaalla mahdollisella tavalla. Uudelleenjärjestäminen sopii parhaiten oliopohjaiseen koodiin. Oliopohjainen koodi on toki itsessään jo luettavampaa kuin funktionaalinen. 4.1.12 Pariohjelmointi SEPA aiheemme oli pariohjelmointi, jolla tarkoitetaan sitä, että kaksi kehittäjää työskentelee yhden tehtävän kimpussa yhdellä tietokoneella. Pariohjelmointia käytettiin projektissa toteutusvaiheiden 1 ja 2 aikana silloin, kun SEPA:n tehneille laadunvarmistusryhmän jäsenille jaettiin myös ohjelmointitehtäviä. Pariohjelmointi oli projektissa erittäin käyttökelpoinen tekniikka ja sen käyttöä tulisi harkita aina ohjelmistoprojekteissa. Pariohjelmointi vähensi virheiden määrää koodissa sekä nopeutti tehtävistä suoriutumista. Toisaalta intensiivinen työtapa aiheutti erimielisyyksiä joidenkin pariohjelmointisessioiden aikana, mutta ongelmista selvittiin. Ongelmista selviäminen nosti meidän kohdalla myös yhteishenkeä. Pariohjelmoinnista oli hyötyä myös ajankäytönhallinnassa, koska pariohjelmointitilaisuus oli etukäteen sovittu, joten tuntien käyttöä pystyy paremmin arvioimaan etukäteen. 4.1.13 Automatisoitu järjestelmätestaus Projektin toisessa iteraatiossa otettiin käyttöön automaattiseen järjestelmätestaukseen soveltuva TestGen4Web tallennus /toisto ohjelma. Ohjelman avulla varmistettiin, että järjestelmään tehdyt virheenkorjaukset ja muutokset eivät rikkoneet ohjelman muita osia. Ongelmallisinta järjestelmätestauksessa oli sopivan ohjelman löytäminen, mutta projektissa käytetty ohjelma toimi varsin hyvin. Järjestelmätestauksesta oli runsaasti hyötyä etenkin, kun projekti oli suhteellisen suuri ja ryhmämme toimi hajallaan. Järjestelmätestaus helpotti ja nopeutti muutosten aiheuttamien virheiden löytymistä. Automatisoitu järjestelmätestaus oli ohjelmistokehitysprojektissa erittäin hyödyllistä. 17

5 Opetuksellinen arvo 5.1 Henkilökohtainen oppiminen Henkilökohtainen oppiminen kurssilla on esitetty taulukossa 5. Taulukossa on esitetty myös kurssin alussa asetetut henkilökohtaiset tavoitteet, joihin vertaamalla voi arvioida kurssilla oppimista. Taulukko 5. Henkilökohtainen oppiminen kurssilla 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 SEmenetelmien 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. Mitä on opittu Tärkein oppimani asia kurssilla on delegointi. Johtoasemassa olevan henkilön on jaettava tehtäviä sillä itse ei pysty tekemään kaikkea. Toinen asia on delegoitujen tehtävien suuri seurannan tarve varsinkin tämän tyyppisessä hajautetussa projektissa. Ryhmä oli suhteellisen suuri, 8 henkeä, ja aikataulujen vuoksi kehitystyö toteutettiin kullekin sopivana ajankohtana. Tämän vuoksi esimerkiski testaustaskien ja virhekorjausten seuranta oli työlästä. Lisäksi oma päivätyö haittasi selvästi kurssin suorittamista. Uusia toiminta tapoja löytyi ainakin nettikäyttöisten ryhmätyöohjelmien muodossa. Keskitetty tuntikirjaus oli erittäin kätevä ja hyvä väline. Vaatimusten ja testien hallintaan olisin vielä kaivannut jotain helpompaa työkalua kuin Word ja Excel. Sain paljon hyödyllistä kokemusta SEmenetelmien soveltamisesta ja käsitystä tämän kokoluokan projektin kulusta. Ongelmia aiheutti ajankäyttö toisessa toteutusiteraatiossa, kun koulun kurssien ohessa tein täyttä työviikkoa. Kurssin alussa asetin itselleni tavoitteeksi, että kurssin aikana opin soveltamaan Ohjelmistotuotannon perusteet kurssilla oppimiani asioita ja opin, miten laadunvarmistus käytännössä toimii. Nämä tavoitteet olen mielestäni saavuttanut, sillä olen soveltanut esimerkiksi Ohjelmistotuotannon perusteet kurssilla opittua pariohjelmointia projektin aikana SEPA:ssa sekä laatinut järjestelmän vaatimuksia testaavia testitapauksia. Lisäksi olen oppinut, että suuri projektiryhmä kannattaa jakaa pienryhmiin, joiden sisällä tehtäviä on helpompi jakaa. Henri Kostia 18

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ä. Kurssin päätavoite oli projektin tekeminen ryhmissä, tässä onnistuttiin mielestäni melko hyvin. Työkuorman jakautuminen epäilytti heti kurssin alussa: tasaisesti hiukan reilut 10 tuntia viikossa ei kuulostanut mahdolliselta. Joillakin viikoilla kurssin työmäärä oli lähes olematon ja seuraavana viikkona saattoikin olla jo todella kiireistä. Omiin tavoitteisiin nähden kurssi sujui hyvin. Kurssin määräajat ja tavoitteet oli ilmoitettu selkeästi ja ajoissa, jonka ansiosta kurssin suorittaminen sujui vaivattomasti. Tuntikirjausjärjestelmän, versionhallinnan ja bugzillan käytön oppiminen projektin aikana kuuluu kurssin parhaimpaan antiin. 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. Opin millainen on onnistuneesti läpi viety ohjelmistoprojekti. Opin myös eri ohjelmistoprojekteissa käytettävistä työvälineistä ja kommunikaatiotavoista. Jälkikäteen ajateltuna olisin voinut ottaa aktiivisemman otteen projektin johtamisesta, mutta toisaalta omat heikkouteni projektialueen asiantuntemuksessa pakottivat delegoimaan myös johtamistoimintaa. Jälkikäteen ajateltuna olisi monessa tilanteessa toimia toisin, kenties tehokkaammin, mutta kun ajattelen tietämystäni päätöksen hetkillä, ymmärrän tekemäni valintani hyvin. Ehkä tämänkaltainen ajattelu todistaa, että kurssi on opettanut paljon niin projektin johtamisesta kuin ohjelmistoprojektin läpiviemisestä. Tulevien projektijohtajien toimintaa helpottaa varmasti suuresti, että heillä on jo kokemusta kurssilta kehittäjän roolista. Petri Palmila 19

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. Ohjelmistoprojektikurssi oli erityisen opettavainen. Kurssin jälkeen voi sanoa, ettei näitä kokemuksia ja oppeja kovin helposti unohda, siten kuin normaaleilla kirjoihin pohjautuvissa kursseissa on yleensä tapana. Ohjelmistotuotantokurssin aiheet on nyt paljon helpompi sisäistää, kun on itse ollut mukana ohjelmistotuotantoprojektissa. Kurssin yhtenä tavoitteenani oli ajankäytönhallinta projektin aikana. Suoriuduin siitä muutamaa viikkoa lukuunottamatta hyvin. Kurssi vaati hyvin paljon aikaa. Yllätys oli se, miten aikaa kului pelkästään työkalujen ja ohjelmointiympäristön konfigurointiin. Mikäli kurssi olisi tapahtunut työelämässä, niin työkalut ja ympäristö olisivat vaatineet mielestäni huomattavasti vähemmän aikaa. Usein juuri kahden eri tietokoneen käyttö aiheutti päänvaivaa. Ainoa oikea ratkaisu olisi ollut valita vain yksi kone, mutta päivätyötä tekevänä se ei ollut mahdollista. 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. Kurssilla oppi jotain siitä, miten työt tämän kokoluokan projektissa jakautuvat. Tästä oli hyötyä varsinkin siinä mielessä, että kokemusta vastaavista projekteista ei vielä työelämän puolelta ole. Tältä osin kurssi vastasi siis ihan hyvin odotuksia. Asiakkaan kanssa toimimisesta ei tullut paljon kokemuksia. Tekniseltä kantilta kurssin aikana PHPohjelmoinnin rutiini parantui, vaikka varsinaisia uusia asioita ei tullutkaan vastaan. 20

6 Kurssipalaute Kahdeksan hengen ryhmä on ohjelmistoprojektiin melko suuri. Alun perinhän ryhmämme koko oli seitsemän henkeä, mutta ryhmien jo muodostuttua ryhmäämme kyseli mukaan vielä yksi henkilö, jonka otimme ryhmään. Kahdeksan hengen ryhmällä tehtävien järkevä jakaminen oli varmasti vaikeampaa kuin seitsemän hengen ryhmänä toimittaessa. Kurssiuudistus sellaiseksi, että johtoryhmän jäsenet ovat jo kerran käyneet kurssin, helpottaa varmasti paljon johtoryhmän jäsenten päänvaivaa, kun parempi käsitys kurssista kokonaisuutena on jo olemassa. Toisaalta, vaikka kurssi onkin erittäin hyödyllinen, on se myös erittäin työläs. Kurssin käyminen kahteen kertaan on toisaalta varmasti myös erittäin kuluttavaa muun opiskelun kannalta. Toinen toteutusiteraatio oli kohtuullisen lyhyt kestollisesti, jolloin viikoittainen työmäärä kasvoi melko suureksi. 21