Hoksotin-sovellusprojekti

Transkriptio

1 Hoksotin-sovellusprojekti Kari Aliranta Jaakko Leppäkangas Janne Pesonen Atte Rautio Projektiraportti Julkinen Versio Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä

2 Hyväksyjä Päivämäärä Allekirjoitus Nimenselvennys Projektipäällikkö Tilaaja Ohjaaja..2013

3 Tietoa dokumentista Tekijät: Kari Aliranta (KA) Jaakko Leppäkangas (JL) Janne Pesonen (JP) Atte Rautio (AR) Dokumentin nimi: Hoksotin-projekti, Projektiraportti Sivumäärä: 71 Tiedosto: HoksotinProjektiraportti0.6.0.tex Tiivistelmä: Hoksotin-projektissa kehitettiin käyttöliittymäprototyyppi MEG-mittauslaitteella mitatun aivosignaalidatan esikäsittelyyn, analyysiin ja kuvantamiseen. Projektiraportti kuvaa Hoksotin-projektin toteutuneen läpiviennin sekä sen erot ja syyt suunnitelmaan verrattuna. Projektiraportissa kuvataan projektin tavoitteet, resurssit, käytänteet, tehtävät ja niiden työtunnit, aikataulu sekä projektiin liittyviä riskejä ja niiden hallintaa. Lisäksi kuvataan jokaisen projektiryhmän jäsenen omia kokemuksia ja oppimaa. Avainsanat: Aikataulu, kokemuksia, käytänteet, ohjelmistoprojekti, opittua, projektin läpivienti, prosessimalli, prototyyppi, resurssit, riskien hallinta, tavoitteet, tehtävät, toteuma, työmäärät, vastuualueet. i

4 Muutoshistoria Versio Päivämäärä Muutokset Tekijät Projektiraportin pohja on luotu. Pohjana käytetään projektisuunnitelman versiota [1]. Osaa luvuista on muokattu projektiraporttia vastaaviksi Projektiraporttia on kirjoitettu pidemmälle. Kuvaajiin ei kuitenkaan ole vielä koskettu Projektiraporttia on kirjoitettu pidemmälle, ja se on toimitettu projektiorganisaatiolle tarkastettavaksi Luku 8 on alustettavasti kirjoitettu. Työtuntitaulukon pohja on muokattu vastaamaan raporttia Lukuja on kirjoitettu lisää. Raporttia on korjattu saadun palautteen perusteella Raporttiin on lisätty alustavat aikataulukaaviot sekä analysoitu aikatauluja ja työtunteja Raporttiin on lisätty aikatauluja käsitteleviä lukuja Sisältö pääosin kirjoitettu. Jäsenten omat kokemukset on lisätty. Ajankäyttöön liittyvät kaaviot ovat vielä keskeneräisiä Ajankäyttöön liittyvät kaaviot on päivitetty, tehtäväkokonaisuuksien toteutumista suurin osa on lisätty ja toteumiin on lisätty analyysia Raporttia on korjattu vastaavan ohjaajan palautteen perusteella Raportti on kirjoitettu pääosin valmiiksi ja annettu tarkastettavaksi. Riskejä ja oppimaa käsitteleviä lukuja ei ole vielä korjattu Riskejä ja oppimaa käsittelevät luvut on korjattu. Versiohistoriasta on korjattu version virheet. Käytänteissä kuvattua projektikansion hakemistorakennetta on muokattu Raporttiin on tehty vaaditut muokkaukset ja se on lähetetty tarkastettavaksi. AR AR AR AR AR AR AR AR AR AR AR AR ii

5 Tietoa projektista Tekijät: Kari Aliranta (KA) Jaakko Leppäkangas (JL) Janne Pesonen (JP) Atte Rautio (AR) Tilaaja: Tiina Parviainen Tilaajan asiantuntija: Lauri Parkkonen Ohjaajat: Tuomas Puoliväli Jukka-Pekka Santanen tietotekniikan laitoksen edustaja: Tero Tuovinen Yhteystiedot: Sähköpostilista Sähköpostiarkisto Sähköpostilista (opetus) Sähköpostiarkisto (opetus) list-archive/hoksotin/ list-archive/hoksotin_opetus/ iii

6 iv

7 Sisältö 1 Johdanto 1 2 Termejä Aihealueen termejä Kehitysvälineisiin ja -tekniikoihin liittyviä termejä Projektin tavoitteiden toteutuminen Projektin taustaa Sovellukselle asetetut tavoitteet Sovelluksen kehitysvälineet ja toteutus Sovelluksen toteutuminen Tulokset Oppimistavoitteet Projektin resurssit Projektiorganisaatio Projektin tilat ja laitteet Ohjelmointi- ja dokumentointityökalut Luennot ja perehdytykset Käytänteet Palaverit Tiedotus Tiedostojen nimeäminen ja hakemistorakenne Lähdekoodi Testaus Versiohallinta ja -numerointi Katselmoinnit ja tulosten hyväksyminen Tulosten koostaminen ja julkaisu Projektin tehtävät ja niiden jakautuminen Projektipäällikkö ja varapäällikkö Vastuualueet tulosten osalta Tehtävät ja työmäärät Ryhmän työtunnit tehtäväkokonaisuuksittain Kari Alirannan työtunnit tehtäväkokonaisuuksittain v

8 6.6 Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain Janne Pesosen työtunnit tehtäväkokonaisuuksittain Atte Raution työtunnit tehtäväkokonaisuuksittain Prosessi ja aikataulu Prosessi Aikataulu Ryhmän työtunnit viikoittain Kari Alirannan työtunnit viikoittain Jaakko Leppäkankaan työtunnit viikoittain Janne Pesosen työtunnit viikoittain Atte Raution työtunnit viikoittain Riskien hallinta Riskien todennäköisyydet ja haitat Projektiorganisaatioon ja sidosryhmiin kuuluvien toiminnan viiveet Projektin aiheen haastavuus Vaikeudet valmiiden ohjelmakomponenttien käytössä Puutteet projektiryhmän tietotaidoissa Toteutettavien ominaisuuksien tarkentaminen ja rajaus Jäsenten odottamattomat poissaolot Projektin hallinnan puutteet Jäsenten kokemuksia ja opittua Mitä olisi pitänyt tehdä toisin? Kari Alirannan kokemuksia ja oppimaa Jaakko Leppäkankaan kokemuksia ja oppimaa Janne Pesosen kokemuksia ja oppimaa Atte Raution kokemuksia ja oppimaa Yhteenveto Lähteet 70 vi

9 1 Johdanto Jyväskylän monitieteinen aivotutkimuskeskus perustettiin vuonna 2012, ja se sijoitettiin Jyväskylän yliopiston yhteiskuntatieteelliseen tiedekuntaan. Keskus aikoo keskittyä erityisesti pitkittäistutkimukseen sekä aivojen muutoksiin luonnollisten tapahtumien, sairauksien ja hoidon seurauksena [2]. Keskuksen tiloihin on tulevaisuudessa tarkoitus hankkia MEG-mittauslaitteisto, jonka avulla pystytään tutkimaan aivojen toimintaa niiden sähköisen toiminnan aiheuttamia magneettikenttiä mittaamalla. MEG-mittauslaitteistolla kerätyn datan analysointiin on olemassa valmiita ohjelmia. Ne ovat kuitenkin melko hankalia käyttää varsinkin opiskelijoille, koska monet niistä ovat komentorivipohjaisia, ja jotkut tarvitsevat melko monimutkaisiakin Python-skriptejä toimiakseen. Lisäksi tutkijat ja opiskelijat joutuvat datan esikäsittelyn ja analysoinnin aikana käyttämään useita eri ohjelmia sekä lataamaan ja tallentamaan tiedostoja tarpeettoman paljon. Hoksotin-projekti toteutti käyttöliittymäprototyypin MEG-mittausdatan esikäsittelyyn, analysointiin ja kuvantamiseen. Tilaajan tavoitteena on saada kaikki MEGmittausdatan analysointiin liittyvät toiminnot saman käyttöliittymän alle niin, ettei käyttäjän tarvitse itse käyttää erillisiä graafisia tai komentorivipohjaisia ohjelmistoja missään vaiheessa. Kehitetty sovellus suorittaa tarvittavat komentorivikutsut käyttäjän puolesta, kunhan käyttäjä syöttää komentojen tarvitsemien parametrien arvot. Lisäksi sovellus avaa tarvittaessa erillisiä graafisia ohjelmistoja. Projektille varattu aika oli sen verran lyhyt, että tuotantoversiota sovelluksesta ei ehditty toteuttamaan. Prototyyppi sisältää olennaisimmat toiminnot, ja se pyrittiin toteuttamaan helposti laajennettavaksi. Projektiraportti kuvaa yksityiskohtaisesti projektin toteutuneen läpiviennin ja vertaa sitä suunniteltuun. Projektiraportti esittelee myös sovellukselle asetetut tavoitteet ja niiden toteutumisen sekä vaaditut ja toteutetut tulokset yleisellä tasolla. Projektiraportissa esitellään myös projektiorganisaatioon kuuluvat henkilöt ja muut projektiin keskeisesti liittyvät resurssit. Lisäksi käsitellään projektissa noudatettuja käytänteitä, ryhmän jäsenille osoitettuja tehtäviä ja vastuualueita sekä riskien hallintaa ja toteutumista. Lisäksi dokumentissa esitetään ryhmän jäsenten työmäärät ja projektin toteutunut aikataulu. Projektissa laadittiin muitakin projektin ja sovelluksen kannalta olennaisia dokumentteja. Vaatimusmäärittely [13] kuvaa sovelluksen toiminnalliset ja tekniset vaa- 1(71)

10 timukset prioriteetteineen sekä kuvaa jokaisen vaatimuksen toteutuksen tilan. Sovellusraportti [3] kuvaa projektissa toteutetun sovelluksen toiminnan sekä suunnitteluja toteutusperiaatteet yleisellä tasolla. Luokkadokumentaatio [15] kuvaa jokaisesta luokasta ja metodista sen käyttötarkoituksen, käytetyt parametrit, poikkeukset ja palautettavat muuttujat. Luvussa 2 kuvataan projektisuunnitelmassa esiintyviä termejä. Luvussa 3 esitellään projektin taustaa, tavoitteet ja niiden toteutuminen sekä tulokset. Luvussa 3 esitellään myös projektissa valmistunutta prototyyppiä. Luvussa 4 esitellään projektiorganisaatio sekä projektille varatut resurssit. Luvussa 5 kuvataan projektissa noudatettuja käytänteitä. Luvussa 6 esitellään projektin tehtäväkokonaisuudet ja tehtävät, tulosten vastuuhenkilöt sekä jäsenten arvioidut ja toteutuneet työtunnit tehtävittäin. Luvussa 7 esitellään projektin aikana noudatettua prosessia ja projektin aikataulua. Luvussa 8 käsitellään projektiin liittyviä riskejä sekä niiden hallintaa. Luvussa 9 ryhmän jäsenet kuvaavat omia kokemuksiaan ja oppimistaan, sekä arvioidaan lyhyesti, mitä projektissa olisi kannattanut tehdä toisin. 2(71)

11 2 Termejä Luvussa esitellään dokumentissa käytettäviä aihealueen ja kehitysvälineiden termejä. 2.1 Aihealueen termejä Dokumentissa esiintyvät aihealueeseen liittyvät termit ovat seuraavat: Artefakta ECG-kanava EEG EOG-kanava Epookki Esikäsittely MEG MEG-kanava SQUID on aivojen ulkopuolisen toiminnan aiheuttama häiriö MEGsignaalissa. Artefaktoja signaaliin aiheuttavat mm. sydämenlyönnit ja silmien liikkeet. sisältää sydämen toiminnan aiheuttaman signaalin. eli elektroenkefalografia mittaa aivojen sähköistä toimintaa. sisältää silmänliikkeista aiheutuvan signaalin. (engl. epoch) on MEG-mittausdatasta jonkin ulkopuolisen ärsykkeen kohdalta rajattu aikajänne, josta näkee ärsykkeestä aiheutuneen aktivaation. Epookit voidaan rajata alkamaan esimerkiksi 200 ms ennen ärsykettä ja päättymään 700 ms ärsykkeen jälkeen. on mittausdatan ensimmäinen käsittelyvaihe, jossa MEG-mittausdatasta poistetaan ylimääräiset häiriöt. eli magnetoenkefalografia on menetelmä, jolla aivojen toimintaa tutkitaan mittaamalla aivojen sähköisen toiminnan aiheuttamia magneettikenttiä. sisältää yhden SQUIDin mittaaman signaalin. MEG-datassa on 306 MEG-kanavaa. eli Superconducting Quantum Interference Device on suprajohtava sensori, jolla MEG-laitteella tehtävä mittaus tapahtuu. Yhdessä mittauslaitteessa on useita SQUIDeja. 3(71)

12 SSS TFR Trigger-kanava tsss eli Signal Space Separation on menetelmä, jolla MEG-data saadaan jaettua kolmeen osaan: sensoriryhmän sisäpuolelta lähteneisiin aivosignaaleihin, sensoriryhmän ulkopuolelta tulleisiin häiriöihin ja häiriöihin, jotka ovat lähtöisin itse sensoreista tai hyvin läheltä niitä [9]. Menetelmää käytetään MEG-datan esikäsittelyssä em. häiriöiden poistoon. eli time-frequency representation on signaalista ajan ja taajuuden suhteen muodostettu kuvaaja. sisältää tiedon mittauksessa käytetyistä ärsykkeistä ja esitettyjen ärsykkeiden ajankohdat. eli temporal Signal Space Separation on laajennus SSS-menetelmään. tsss:n avulla saadaan MEG-datasta poistettua myös sisäiset häiriöt, jotka voivat johtua esimerkiksi hammasraudoista tai tahdistimista [9]. 2.2 Kehitysvälineisiin ja -tekniikoihin liittyviä termejä Dokumentissa esiintyy seuraavia kehitysvälineisiin ja -tekniikoihin liittyviä termejä: Doxygen Eclipse EPD Ketterä ohjelmakehitys on työkalu luokkadokumentaation generointiin lähdekoodista. Doxygen tukee useita ohjelmointikieliä, mukaanlukien Pythonia. on sovelluskehitysympäristö, joka on tarkoitettu Java-sovellusten kehittämiseen. Myös monet muut ohjelmointikielet, mukaanlukien Python, ovat tuettuna erilaisten liitännäisten kautta. eli Enthought Python Distribution on kirjastokokoelma, joka sisältää työkaluja datan analysointiin ja visualisointiin [5]. sisältää useita ohjelmistokehitysprojektin läpiviennissä käytettäviä menetelmiä, jotka tunnustavat Agile Manifestossa [6] esiteltyjä arvoja. Ketterän ohjel- 4(71)

13 mistokehityksen perusperiaatteisiin kuuluu toimivan ohjelmiston priorisointi, nopea muutoksiin reagointi sekä joustava viestintä kehittäjän ja asiakkaan välillä. MaxFilter MNE Python YouSource on Elekta Oy:n julkaisema ohjelmisto MEG-datan analyysiin [9]. on MEG-datan ja EEG-datan käsittelyyn tarkoitettu avoimen lähdekoodin ohjelmistopaketti [8]. on avoimen lähdekoodin lisenssin alainen olio-ohjelmointikieli [7]. on Verso-projektissa kehitetty lähdekoodien julkistusjärjestelmä, jota käytetään projektissa laaditun lähdekoodin versiohallintaan ja julkistamiseen [10]. 5(71)

14 3 Projektin tavoitteiden toteutuminen Luvussa kuvataan projektin taustaa sekä toteutettavan sovelluksen tavoitteita. Lisäksi verrataan projektissa toteutetun prototyypin toiminnallisuutta asetettuihin tavoitteisiin. Luvussa esitellään myös projektin aikana toteutetut tulokset sekä projektiryhmän jäsenten oppimistavoitteet ja niiden toteutuminen. Projektiryhmällä kului odotettua enemmän aikaa aihealueeseen tutustumiseen, joten sovelluksen toteutuksen aloitus siirtyi odotettua myöhemmäksi. Lisäksi datan esikäsittelyn toteutus osoittautui odotettua työläämmäksi. Täten analyysimenetelmiä ehdittiin sovellukseen toteuttaa suunniteltua vähemmän. Lisäksi sovelluksen käyttämistä helpottavien ja nopeuttavien lokitietojen keräys ja käyttö sovittiin tilaajan kanssa projektin jälkeiseen jatkokehitykseen. Järjestelmätestaus jäi projektiryhmän osalta varsin vähäiseksi osittain siksi, että ryhmä ei saanut käyttöönsä kaikkia sovelluksen hyödyntämiä ohjelmia. Lisäksi sovelluksen toteutukseen päätettiin käyttää enemmän aikaa, joka otettiin pois testauksesta. Sovelluksen prototyyppiin ehdittiin toteuttaa suunniteltua vähemmän toimintoja. Pääosin tämä johtuu siitä, että aihealueen ymmärtämiseen tarvittu aika oli projektisuunnitelmassa [1] aliarvioitu. Esikäsittelyyn liittyvät toiminnot ehdittiin toteuttaa mutta analyysitoiminnoissa päästiin vain alkuun. Sovellukselle ei kirjoitettu erillistä käyttöohjetta, vaan sovelluksen käyttöä kuvataan sovellusraportissa [3]. Sovellusprojekti-kurssin sekä yleiset että ryhmän jäsenten itselleen asettamat oppimistavoitteet toteutuivat pääosin. 3.1 Projektin taustaa Magnetoenkefalografia (MEG) on aivojen toiminnan analysoinnissa käytetty menetelmä, jossa aivojen toimintaa tutkitaan mittaamalla aivojen sähköisen toiminnan aiheuttamien magneettikenttien muutoksia ajan suhteen. MEG:lla voidaan tutkia muun muassa aktivaation etenemistä aivoissa tiettyyn tehtävään liittyen sekä aivoalueiden verkostoa ja kytkeytymistä. MEG-mittaus on täysin noninvasiivinen, joten mittaukset voidaan toistaa useita kertoja ja koehenkilöinä voidaan käyttää myös lapsia [4]. Ennen kuin MEG-mittauslaitteella (katso kuva 3.1) kerättyä dataa voidaan analysoida, on siitä esikäsittelyvaiheessa poistettava ylimääräiset häiriöt. Niitä ovat esimer- 6(71)

15 kiksi aivojen ulkopuolinen kohina, sydän- ja silmäartefaktat sekä pään liikkumisesta aiheutuvat häiriöt. Kuva 3.1: MEG-mittauslaite. Varsinaiseen datan analysointiin on useita erilaisia menetelmiä, joita voidaan suorittaa joko koko datalle tai tietyille osille sitä. Esimerkiksi herätevasteita tutkittaessa on datasta poimittava ne epookit, joissa ärsykkeet ja niiden aiheuttamat aktivaatiot ovat tapahtuneet. Datalle saatetaan joutua tekemään erilaisia matemaattisia muunnoksia riippuen analysointimenetelmästä. Analysoitaessa dataa sensoritasolla tutkitaan yksittäisten sensorien mittaamaa signaalia ja analysoitaessa lähdetasolla tutkitaan aivojen eri kohdista lähtenyttä signaalia. Siirryttäessä sensoritasolta lähdetasolle pitää datalle tehdä omat muunnoksensa. Kuvassa 3.2 on esitetty esikäsittelemätöntä raakadataa. Kuvassa 3.3 raakadata on pilkottu epookkeihin ja yhden epookin herätevasteet on keskiarvoistettu. Molemmissa kuvissa on piirrettynä kaikkien MEG-kanavien mittaama signaali. 7(71)

16 Kuva 3.2: Esikäsittelemätöntä raakadataa. Kuva 3.3: Keskiarvoistettu epookki. Datan esikäsittelylle ja analyysille on olemassa valmiita ohjelmia. Monet niistä ovat vaikeasti käytettäviä johtuen pääosin siitä, että niitä käytetään komentoriviko- 8(71)

17 mennoilla ja skripteillä. Ohjelmia käyttävillä tutkijoilla ja opiskelijoilla ei kuitenkaan välttämättä ole kovin laajaa tietoteknistä taustaa, joten heiltä kuluu turhan paljon aikaa ohjelmien opetteluun ja käyttöön. Projektin tilaajana toimiva Jyväskylän monitieteinen aivotutkimuskeskus toivoo, että Hoksotin-projektissa kehitettävän sovelluksen avulla pystytään MEG-mittausdatan esikäsittely ja eri analyysit tekemään yhden käyttöliittymän avulla niin, että eri vaiheiden suorittaminen, parametrien arvojen syöttö ja tulosten kuvantaminen on mahdollisimman helppoa. 3.2 Sovellukselle asetetut tavoitteet Hoksotin-projekti toteutti Jyväskylän yliopiston Jyväskylän monitieteiselle aivotutkimuskeskukselle käyttöliittymäprototyypin MEG-laitteella mitatun datan esikäsittelyyn, analyysiin ja kuvantamiseen. Kehitettävän sovelluksen tuotantoversio tulee yhdistämään MNE-ohjelmiston ja MaxFilter-ohjelmiston yhden käyttöliittymän alle. Sovelluksen käyttäjät ovat pääosin tutkijoita ja opiskelijoita, joilla ei voi olettaa olevan paljoa tietoteknistä osaamista. Siten sovelluksen helppokäyttöisyys on erittäin tärkeässä asemassa. Sovelluksessa tulee pystyä kutsumaan em. ohjelmistojen eri toimintoja ja syöttämään toimintojen parametreille arvoja ilman, että joudutaan suorittamaan monimutkaisia komentorivikomentoja tai skriptejä. Sovelluksen tulee tallentaa lokia mittausdatalle suoritetuista toimenpiteistä ja niissä käytetyistä parametrien arvoista. Käyttäjän pitää pystyä halutessaan tekemään eri mittausdatoille samat toiminnot samoilla parametrien arvoilla ilman, että ne joudutaan syöttämään joka kerta uudelleen. Lisäksi käyttäjän pitää päästä halutessaan takaisin aiempiin analyysin vaiheisiin, joten datan tila pitää tallentua joka vaiheen jälkeen. Käyttäjän tulee pystyä tarkastelemaan dataa kuvaajasta eri toimintojen välillä. Tällöin hän pystyy tarkistamaan, että käytetty menetelmä ja sille annetut parametrien arvot ovat johtaneet toivottuun tulokseen. Datan analyysissä suoritettaviin toimenpiteisiin pitää pystyä poimimaan arvoja suoraan kuvaajista. Esimerkiksi voidaan valita, mitä kanavia käsittelyyn otetaan ja mitä jätetään pois. 9(71)

18 3.3 Sovelluksen kehitysvälineet ja toteutus Projektissa kehitetty Sovelluksen prototyyppi toimii Linuxissa, ja se ohjelmoitiin Pythonilla. Sovellus hyödyntää paljon MNE-ohjelmistoa, jossa on liittymät MatLabiin, Pythoniin ja C/C++:aan. Lisätoiminnallisuutta MNE:hen on kirjoitettu eniten Pythonilla, ja Python-modulit ovat myös parhaiten ylläpidetyt MNE:n liitännäiset. Tämän vuoksi Python oli luontevin valinta myös Hoksotin-projektissa toteutetun sovelluksen ohjelmointiin. Käyttöliittymä toteutettiin PyQT:lla. Sovelluksen rakenne on kuvattu yleisellä tasolla kuvassa 3.4. Hoksotin-projektin päätavoite oli toimittaa tilaajalle sovelluksen prototyyppi, jossa on huomioitu esitettyjen vaatimusten [13] ohella sovelluksen laajennettavuus. Projektin aikataulu oli rajattu, joten sovellusta joudutaan pakostakin jatkokehittämään projektin päättymisen jälkeen. Jatkokehitys pyrittiin ottamaan huomioon sovelluksen toteutusratkaisuissa ja dokumentoinnissa. Käytännössä vaikka kaikkia vaatimuksia ei ehdittykään toteuttaa, otettiin ne kuitenkin projektin aikana huomioon kirjaamalla toteuttamatta jääneet vaatimukset ylös vaatimusmäärittelyyn, jotta jatkokehityksen aloittaminen olisi mahdollisimman helppoa. Lisäksi Kari Aliranta, Janne pesonen ja Atte Rautio jatkokehittävät sovellusta kesällä 2013, ja Aliranta kirjasi ylös erilaisia jatkokehitysideoita sekä korjattavia puutteita sovellusraporttiin [3]. Projektiryhmän jäsenet joutuivat käyttämään suunniteltua enemmän aikaa esitutkimukseen. Lisäksi datan esikäsittelyvaiheen toteutus osoittautui huomattavasti oletettua monimutkaisemmaksi, ja se vei huomattavasti suunniteltua enemmän aikaa. Siten lokitietojen keräystä ja osaa kuvaajiin liittyvistä toiminnoista ei ehditty toteuttaa, joten ne sovittiin tilaajan kanssa jatkokehitykseen. Sovelluksen prototyyppi toimitettiin tilaajalle kesäkuun alussa. Projektiryhmä piti tilaajan ajantasalla projektin etenemisestä, jotta tilaajan oli helpompi osoittaa ne sovelluksen ominaisuudet, joiden kehittäminen oli ensisijaista. Lisäksi tilaajan aktiivisella osallistumisella saatiin sovelluksen kehitys pidettyä varmemmin toivotussa suunnassa. 3.4 Sovelluksen toteutuminen Sovelluksesta ei ehditty projektissa toteuttaa tuotantoversiota, vaan se jäi prototyyppiasteelle. Vaatimusmäärittelyssä pakollisia vaatimuksia oli 34 kappaletta ja 10(71)

19 Kuva 3.4: Sovelluksen kokonaisrakenne. niistä toteutui projektissa 31 kappaletta, joko ryhmän toteuttamana tai ulkopuolisella komponentilla. Pakollisista vaatimuksista väärien parametrien syöttämisestä aiheutuvat virheilmoitukset toteutettiin osittain, ja toimenpiteen uusimisesta johtuvaa datatiedoston uudelleentallennusta ei ehditty toteuttaa ollenkaan. Ohjelmiston todettiin toimivan Fedorassa, mutta Ubuntussa oli toimivuusongelmia. Tärkeäksi merkittyjä vaatimuksia oli 42, ja niistä ehdittiin toteuttaa 13 ja kolme vaatimusta osittain. Ajan salliessa toteutettavia vaatimuksia oli 5 kappaletta, mutta niistä ei eh- 11(71)

20 ditty toteuttaa yhtään. Kaikki toteuttamatta jääneet vaatimukset sovittiin tilaajan kanssa jatkokehitykseen. Käyttäjä pystyy luomaan koekohtaisia hakemistoja datan käsittelyä varten. Uutta koetta luodessa sovellus tekee kokeelle hakemistorakenteen valmiiksi ja kopioi käytettävän raakadatatiedoston koekansioon. Sovellus huolehtii siitä, että esikäsittelyn ja analyysin aikana muodostuvat tiedostot tallennetaan oikeannimisinä oikeisiin hakemistoihin ja alihakemistoihin. Sovellus ohjaa käyttäjää avaamalla uusia toimenpiteitä sen perusteella, mitä datalle on tehty. Datan esikäsittelyyn liittyvät ominaisuudet saatiin projektissa toteutettua. Datasta pystytään siis poistamaan esimerkiksi silmien ja sydämen toiminnasta aiheutuvat häiriöt. Lisäksi data voidaan jakaa epookkeihin kokeessa käytettyjen ärsykkeiden pohjalta muodostettavan tapahtumalistan avulla. Epookkeja voidaan keskiarvoistaa, ja käyttäjä pystyy halutessaan näkemään keskiarvoistettujen epookkien kuvaajat. Sovelluksella pystytään muodostamaan myös TFR-kuvia. TFR-kuvat pystytään sijoittamaan päätä kuvaavaan topografiaan, josta näkee jokaisen sensorin mittaaman signaalin, sekä sensorin sijainnin koehenkilön pään ympärillä. Sovelluksen käyttö etenee pääosin loogisesti, mutta käyttäjä ei kuitenkaan saa palautetta siitä, että jokin aikaavievä toiminto on kesken. Lisäksi osa virheilmoituksista ei ole tarpeeksi informatiivisia. Sovellusta varten kehitettiin myös joitakin toimintoja liittyen tilastotietojen etsimiseen kuvaajista analyysia varten. Näitä ei kuitenkaan projektissa ehditty liittää sovellukseen. MEG-datan analyysiin liittyviä toimintoja ehdittiin toteuttaa vain vähän, ja analyysia voidaan tehdä sovelluksen prototyypillä ainoastaan sensoritasolla. Lähdetasolle siirtymiseen liittyvät toiminnot sovittiin jatkokehitykseen jo huhtikuun alkupuolella. Sovelluksen toiminnan varmistavaa järjestelmätestausta ei ehditty projektissa toteuttaa, vaan sovelluksen viimeistelyn taso todettiin koekäytöillä. Koekäyttöjen perusteella sovellukseen jäi jonkin verran korjattavaa. Lisäksi koekäytöissä huomattiin mahdollisia virheitä, jotka voivat johtua sovelluksen käyttämien ohjelmakomponenttien puutteellisesta asennuksesta. Osa puutteista sovittiin korjattavaksi jatkokehitykseen sekä ne mainitaan sovellusraportissa [3]. Lisäksi sovittiin, että jatko- 12(71)

21 kehityksessä toteutetaan sovellukseen ohjedialogi, jossa neuvotaan useimpien ulkopuolisiin ohjelmakomponentteihin liittyvien ongelmien ratkaisemisessa. 3.5 Tulokset Sovelluksen ohella projektiryhmä toteutti seuraavat tulokset: - Ajankäyttöraportti sisältää ryhmän jäsenten kirjaamat työtunnit sekä niiden jakautumisen eri tehtäväkokonaisuuksille ja tehtäville. - Asennusohje neuvoo sovelluksen asennuksen ja käyttöönoton. - Esittelymateriaalit sisältävät väli- ja loppuesittelyn esitysgrafiikat ja muistiot. - Itsearvioinnit sisältävät ryhmän jäsenten arvioinnit omasta, ryhmän, tilaajan edustajien, ohjaajien ja atk-tuen toiminnasta ja onnistumisesta sekä luennoista ja perehdytyksistä. - Luokkadokumentaatio kuvaa toteutettujen ohjelmaluokkien käyttötarkoituksen ja toiminnan sekä metodit ja attribuutit. - Lähdekoodi sisältää projektissa toteutetun sovelluksen kommentoidun lähdekoodin. - Oheiskurssien materiaalit sisältävät oheiskurssien suoritukseen kuuluvat kirjoitusharjoitukset ja muun materiaalin. - Palaverien dokumentit sisältävät palaverien esityslistat, pöytäkirjat ja niissä esitetyt tilakatsaukset. - Projektiraportti kuvaa projektin toteutuneen läpiviennin, vertaa toteumaa suunnitelmaan sekä arvioi erojen syitä ja vaikutuksia. - Projektisuunnitelma on projektin läpiviennin suunnitelma. - Sovellusraportti kuvaa projektissa toteutetun sovelluksen käyttöliittymän kokonaisrakenteen, yleiset toteutusratkaisut ja toiminnot sekä tavoitteiden toteutumista, mahdolliset puutteet ja jatkokehitysideat. - Sähköpostiarkistot sisältävät kaikki projektiorganisaation sähköpostilistoille lähetetyt viestit. - Vaatimusmäärittely kuvaa sovelluksen toiminnalliset ja tekniset. Suunnitelluista dokumenteista ainoastaan käyttöohjetta ei kirjoitettu, vaan sovelluksen käyttöä kuvataan sovellusraportissa. Kaikki projektidokumentit sijoitettiin Creative Commons Attribution-ShareAlike 3.0 Unported -lisenssin alaisuuteen. Kaikki projektissa toteutettu lähdekoodi sijoitettiin avoimen lähdekoodin Simplified BSD -lisenssin alaisuuteen. 13(71)

22 3.6 Oppimistavoitteet Sovellusprojekti-opintojakson päätavoitteena on tarjota opiskelijoille käytännön kokemusta projektimuotoisesta työskentelystä. Jokainen projektiryhmän jäsen sai kokemusta useilta ohjelmistokehityksen osa-alueilta, sillä pieni ryhmäkoko pakotti jakamaan useita tehtäviä samoille henkilöille. Ryhmän jäsenet oppivat monipuolisesti taitoja ohjelmiston määrittelyyn, suunnitteluun, toteutukseen ja testaukseen liittyen, tosin kaikki jäsenet eivät saaneet kokemusta kaikista edellä mainituista tehtäväkokonaisuuksista. Tiiviissä ryhmässä kaikki oppivat kuitenkin väistämättä ryhmätyötaitoja. Erityisesti projektipäällikkö oppi projektityöskentelyn suunnittelussa ja hallinnassa vaadittuja johtamistaitoja ja ajankäytön hallintaa. Projektin aikana järjestettävät palaverit olivat olennainen osa sovellusprojektia ja sitä kautta myös oppimisprosessia. Palavereissa ryhmän jäsenet oppivat noudattamaan asianmukaisia kokous- ja palaverikäytänteitä, minkä lisäksi he oppivat laatimaan esityslistoja ja pöytäkirjoja. Kaikki ryhmän jäsenet toimivat vuorollaan myös puheenjohtajan ja sihteerin roolissa, joten jokainen sai kokemusta myös kyseisistä tehtävistä. Sovellusprojektikurssin yhteyteen oli liitetty opiskelijoiden puhe- ja kirjoitusviestintätaitoja kehittävä Projektiviestintä IT-alalla -kurssi, johon kuului erilaisia kirjoitusja esiintymisharjoituksia. Myös kaikista sovellusprojektin aikana laadittavista dokumenteista saatu palaute tuki viestintätaitojen oppimista. Projektiin liittyi myös oheiskurssi Sovellusprojektin hallintaa, viestintää ja työkaluja. Tämän kurssin kautta ryhmän jäsenet oppivat projektityöskentelyn edellyttämiä tietotaitoja, ryhmätyöskentelyä ja suunnitelmallisuutta. Kurssilla käsiteltiin myös käytettävyyttä. Koska projektiryhmän jäsenillä oli korkeintaan hyvin vähän aiempaa kokemusta projektityöskentelystä, tuli vastaan pakostakin odottamattomia tilanteita. Aiempien projektiryhmien projektikansioiden läpikäynti oli korvaamaton työkalu sekä hyvien että vältettävien käytänteiden opettelemiseen. Varsinkin laajempien dokumenttien kirjoituksessa oli projektikansioista erittäin suurta hyötyä. Projektiryhmä oppi sosiaalisia taitoja ja viestintätaitoja neuvotellessaan asiakkaan kanssa sovelluksen toiminnallisuuksista ja pyrkiessään kaikkia osapuolia miellyttäviin ratkaisuihin. Nämä taidot kehittyivät myös ryhmän sisäisessä työskentelyssä ja viestinnässä. Kellään Hoksotin-ryhmän jäsenistä ei juurikaan ollut aiempaa kokemusta Pythonista, joten kaikkien ryhmän jäsenten ohjelmointitaidot kehittyivät projektin aikana 14(71)

23 huomattavasti. Lisäksi ryhmän jäsenet oppivat lukemaan toisten kirjoittamaa koodia ja kirjoittamaan oman koodinsa helppolukuiseksi. Viimeisen lähdekoodikatselmoinnin palautteen perusteella ryhmän ohjelmointitaidoissa oli todellakin tapahtunut selkeää kehitystä projektin kuluessa. Jäsenet oppivat myös hyödyntämään versiohallintaohjelmistoa, joka mahdollistaa koodin yhtäaikaisen kehityksen. Projektityöskentely edellytti kaikilta ryhmän jäseniltä tiivistä yhteistyötä, sillä projektin läpivienti riippui kaikkien jäsenten panoksesta. Ryhmässä työskenteleminen vaati jäsenten väliltä luottamusta ja kykyä ottaa vastuuta. Projektityöskentelyssä korostuivat myös aloitekyky ja omatoimisuus, mutta toisaalta jokaisen tuli samalla pystyä pitämään muut ryhmän jäsenet ajan tasalla siitä, mitä kulloinkin teki. Ryhmän jäsenet kysyivät toisiltaan aktiivisesti tehtävien tilasta ja ongelmista, joten kaikki pysyivät hyvin mukana projektin loppuun asti. Edellä mainittujen oppimistavoitteiden lisäksi projektiryhmän jäsenet olivat asettaneet itselleen seuraavat henkilökohtaiset oppimistavoitteet: - Kari Alirannan ja Jaakko Leppäkankaan tavoitteena oli oppia ohjelmistojen suunnittelu- ja toteutusperiaatteita etenkin Pythonin osalta. He halusivat myös saada realistista tuntumaa asiakkaan kanssa neuvottelemisesta varsinkin, kun asiakas itse ei ole tietotekniikan ammattilainen. - Janne Pesonen halusi saada käytännön työkokemusta ja oppia ryhmätyöskentelyyn liittyviä taitoja. - Atte Raution tavoitteena oli saada käytännön kokemusta ohjelmistokehityksestä ja projektityöskentelystä. Lisäksi hän halusi kokemusta projektipäällikön tehtävistä ja vastuista. Oppimistavoitteet toteutuivat pääosin. Tilaajan edustajalla oli aika paljon tietoteknistä osaamista, vaikka hän ei alan ammattilainen ollutkaan. Tämän vuoksi tietotekniikkaa osaamattomien kanssa neuvottelusta ei pahemmin saatu kokemusta. Ryhmän jäsenet kokivat myös oppineensa paljon muutakin hyödyllistä projektimuotoisesta työskentelystä ja ohjelmistokehityksestä. Oppimista kuvataan tarkemmin jokaisen jäsenen osalta luvussa 9. 15(71)

24 4 Projektin resurssit Luvussa käsitellään projektiorganisaatioon kuuluvien henkilöiden lisäksi muita projektin käytössä olleita resursseja, kuten työtiloja, laitteita, työkaluja ja perehdytyksiä. Resurssit ja niiden käyttö toteutuivat pääosin suunnitellusti. Luokkadokumentit laadittiin PyDocin sijaan Doxygenillä Potku-sovellusprojektiryhmän suosituksen takia. Sovellusraportti kirjoitettiin Libre Officella, koska Alirannan ei kannattanut enää projektin loppuvaiheessa alkaa opettelemaan L A TEXia. 4.1 Projektiorganisaatio Projektiryhmään kuului neljä jäsentä: Kari Aliranta, Jaakko Leppäkangas, Janne Pesonen ja Atte Rautio. Atte Rautio toimii projektipäällikkönä ja Jaakko Leppäkangas varapäällikkönä. Kari Aliranta on opiskellut tietotekniikan maisteriohjelmassa 1,5 vuotta. Aiempaa tietotekniikan työkokemusta hänellä on kesältä 2012, jolloin hän oli harjoittelijana Jyväskylän yliopiston viestintäpalveluissa. Jaakko Leppäkangas on suorittanut tietotekniikasta ammattikorkeakoulututkinnon ja on opiskellut Jyväskylän yliopistossa tietotekniikkaa maisteriohjelmassa 1,5 vuotta. Janne Pesonen on opiskellut tietotekniikkaa Jyväskylän yliopistossa 4,5 vuotta ja on suorittanut kandidaatintutkintoon vaadittavat kurssit. Atte Rautio on opiskellut tietotekniikkaa kolme vuotta ja aikoo suorittaa kandidaatintutkinnon syksyllä Hän aikoo saada pro gradu - tutkielman valmiiksi keväällä Tilaajan edustajana toimi Tiina Parviainen Jyväskylän yliopiston Jyväskylän monitieteisestä aivotutkimuskeskuksesta. Tilaajan asiantuntijana toimi Lauri Parkkonen Aalto-yliopistosta. Projektin vastaavana ohjaajana toimi Jukka-Pekka Santanen, joka neuvoi ryhmän jäseniä projektin läpiviennissä ja projektin yleisissä käytänteissä. Projektin teknisenä ohjaajana toimi Tuomas Puoliväli, joka neuvoi ryhmää ennen kaikkea MNE:hen liittyen. Puoliväliltä kysyttiin neuvoa myös toteutusratkaisuista ja tuettavasta prosessista. Tietotekniikan laitoksen edustajana toimi Tero Tuovinen. Hän seurasi projektin 16(71)

25 etenemistä sekä osallistui useisiin projektipalavereihin. Projektiryhmän yhteyshenkilönä ATK-lähituessa toimi Santeri Lapinmäki. Maritta Stoor-Lehtonen piti oheiskurssin puheviestinnän luennot ja neuvoi puheviestintään liittyvissä asioissa. Kaisa Leino piti kirjoitusviestinnän luennot ja neuvoi kirjoitusviestintään liittyvissä asioissa. Lisäksi hän antoi palautetta projektin aikana kirjoitettujen dokumenttien kirjoitusasusta. Käytettävyyden osalta projektiryhmää neuvoi Meeri Mäntylä. Projektiorganisaatioon ei tullut muutoksia projektin aikana. 4.2 Projektin tilat ja laitteet Projektiryhmän työtilana toimi projektihuone Ag C223.2, joka sijaitsee Agoran C- siiven toisessa kerroksessa sovellusprojektien tiloissa. Huoneen solussa on monitoimilaite, jota projektiryhmän jäsenet käyttivät tulostukseen, kopiointiin ja skannaamiseen. Projektin aikana ryhmä käytti kokoustilana kokoushuonetta Ag C Kokoushuoneessa olevan tietokoneen ja videoprojektorin lisäksi projektiryhmä sai tarvittaessa kokouskäyttöön kannettavan tietokoneen ja digisanelimen. Projektiryhmällä oli käytössä neljä tietokonetta, joista kolmessa oli käyttöjärjestelmänä Linux Fedora 16 ja yhdessä Windows 7 Enterprise. Projektiryhmän käytössä oli kaksi verkkolevyä. Toinen verkkolevy oli tarkoitettu ryhmän sisäiseen tiedostojen jakamiseen ja toinen varattiin projektin WWW-sivuille, joiden kautta ryhmä julkisti dokumentteja projektiorganisaatiolle. Ryhmä sai verkkolevyt käyttöönsä vasta muutama viikko projektin alkamisen jälkeen, mikä vaikeutti hieman erilaisten dokumenttien jakamista projektiorganisaatiolle. Verkkolevyjä hyödynnettiin kuitenkin niiden käyttöönoton jälkeen, ja varsinkin WWW-levy osoittautui erittäin hyödylliseksi työkaluksi. Projektiryhmä sai projektille tarkoitetut tietokoneet käyttöönsä vasta projektin alkamisen jälkeen viikolla 9. Ryhmällä oli sitä ennen käytössään toiset tietokoneet, joilla opeteltiin projektissa käytettävien työkalujen käyttöä ja asennusta. Siten uusien tietokoneiden käyttöönotto oli todella nopeaa. Tilat ja laitteet toteutuivat verkkolevyjen pientä viivästystä lukuunottamatta suunniteltuina. 17(71)

26 4.3 Ohjelmointi- ja dokumentointityökalut Ohjelmointikielenä projektiryhmä käytti Pythonia EPD-kirjastokokoelmalla laajennettuna. Käyttöliittymän toteutuksessa hyödynnettiin PyQT:ta. Sovelluskehitysympäristönä käytettiin Eclipseä. Tulosten versiohallintaan käytettiin Git-versiohallintaohjelmistoa ja YouSource-nimistä lähdekoodien julkistusjärjestelmää. Luokkadokumentaatio suunniteltiin muodostettavan lähdekoodeista PyDocilla, mutta ryhmä käytti kuitenkin Doxygeniä [12], koska sitä oli helpompi käyttää. Projektin keskeisimmät ja laajimmat dokumentit kirjoitettiin L A TEX-ohjelmistolla lukuunottamatta sovellusraporttia, joka kirjoitettiin Libre Officella. Kari Alirannalla oli hyvin vähän kokemusta L A TEXin käytöstä, mutta hän oli käyttänyt Libre Officea paljon enemmän. Projektiryhmä totesi, ettei projektin loppuvaiheessa kannata uutta ohjelmistoa enää opetella, kunhan sovellusraportin saa kirjoitettua helppolukuiseksi PDF-tiedostoksi. Toteutettavan sovelluksen vaatimusten määrittely ja laatiminen tehtiin Freemindilla ja Geditillä. Muiden dokumenttien, kuten pöytäkirjojen ja muistioiden, laatimiseen ryhmän jäsenet käyttivät kulloiseenkin tilanteeseen parhaaksi katsomaansa tekstinkäsittelyohjelmistoa. Sovellusprojektiin käytettävien työtuntien kirjaamisen käytettiin Petri Heinosen kehittämää Excel-pohjaista ajankäytönseurantasovellusta [14]. Sen avulla muodostettuja kuvaajia käytettiin myös projektipalaverien tilakatsauksissa. Ajankäyttöseurantasovelluksen ongelmana oli se, ettei se toiminut Linuxissa. Ryhmällä oli käytettävissään vain yksi Windows-kone, ja se oli pääosin projektipäällikön käytössä. Tämän vuoksi ryhmän muut jäsenet kirjasivat työtuntinsa ylös parhaaksi katsomallaan tavalla ja päivittivät ajankäytönseurantasovellusta omalta osaltaan parin viikon välein yleensä silloin, kun projektipäällikkö aloitti seuraavan palaverin tilakatsauksen laatimisen. 4.4 Luennot ja perehdytykset Sovellusprojektikurssin ohella opiskelijat suorittivat oheiskurssit Sovellusprojektin hallintaa, viestintää ja työkaluja sekä Projektiviestintä IT-alalla. Näillä kursseilla opiskelijat oppivat projektin hallintaan ja projektiviestintään liittyviä tietotaitoja. Luennot ja tapaamiset keskittyivät seuraaviin aiheisiin: 18(71)

27 - kokous- ja neuvottelukäytänteet (Stoor-Lehtonen) - esittely ja esiintyminen (Stoor-Lehtonen) - kirjoitusviestintä (Leino) - projektin johtaminen ja hallinta (Santanen) - käytettävyyskoulutus (Mäntylä) - versiohallinta (Jonne Itkonen ja Ville Isomöttönen) - väliesittelyt (Stoor-Lehtonen ja Santanen). Ryhmän jäsenet opiskelivat itsenäisesti työkalujen ja tekniikoiden käyttöä Internetistä löytyvistä oppaista sekä ohjaajien ja tilaajan toimittamista materiaaleista. Ylimääräiset perehdytykset koskivat Pythonia ja signaalinkäsittelyn perusteita. Molemmat perehdytykset piti projektin tekninen ohjaaja. Python-perehdytys koettiin varsin hyödylliseksi, ja perehdytyksen jälkeen oli helppo päästä alkuun koodaamisessa. Signaalinkäsittelyperehdytys pidettiin ehkä hieman liian aikaisin. Ryhmällä ei ollut projektin tavoitteista kovinkaan suurta ymmärrystä, ja olisikin ehkä vielä siinä vaiheessa ollut parempi keskittyä yleisellä tasolla siihen, mitä sovelluksella halutaan missäkin vaiheessa pystyä tekemään kiinnittämättä kuitenkaan liikaa huomiota yksityiskohtiin. Ylimääräisten perehdytysten pitämisen lisäksi Puoliväli ohjasi ryhmän toimintaa aktiivisesti. Hän vastasi sähköpostitse lähetettyihin avunpyyntöihin ripeästi ja tuli tarvittaessa paikan päälle neuvomaan sovelluksen toteutukseen liittyvissä asioissa. Luennot ja perehdytykset toteutuivat suunnitellusti. 19(71)

28 5 Käytänteet Luvussa kuvataan projektissa noudatettuja käytänteitä. Ne yhtenäistivät ryhmän toimintatapoja, siten tukea projektin hallintaa sekä varmistaa sen aikana toteutettavan sovelluksen ja muiden tulosten laatua. Suunnitelluissa käytänteissä pitäydyttiin pääosin. Viikoittaisia tilakatsauksia ei kuitenkaan ollut suunniteltua määrää, koska ryhmän jäsenet olivat muutenkin aktiivisesti yhteydessä ohjaajiin ja tilaajan edustajaan. Testausta ei toteutettu lähellekään suunniteltua määrää, vaan testaukseen varatut työtunnit päätettiin siirtää suunnitteluun ja toteutukseen. 5.1 Palaverit Palavereja pidettiin kerran viikossa tai kerran kahdessa viikossa tarpeen mukaan. Projektipäällikkö teki tilavaraukset palavereille. Palaveri oli laillinen, kun palaverikutsu ja esityslista oli toimitettu projektiorganisaatiolle vähintään vuorokautta ennen palaveria. Palaveri oli päätösvaltainen, kun palaverissa oli läsnä vastaava ohjaaja, tilaajan edustaja ja vähintään yksi projektiryhmän jäsen. Tarvittaessa Puoliväli pystyi toimimaan tilaajan edustajana, jos Parviainen ei päässyt paikalle. Tällainen tilanne sattui vain yhdessä palaverissa, johon Parviainen tuli kuitenkin paikalle hieman palaverin alkamisen jälkeen. Projektipäällikkö esitteli palavereissa tilakatsauksen kuvaten, mitä projektissa oli tehty edellisen palaverin jälkeen, mitä ongelmia oli kohdattu, ja mitä aiotaan tehdä seuraavaksi. Lisäksi tilakatsauksissa esiteltiin työtunnit tehtäväkokonaisuuksittain ja viikoittain sekä koko ryhmän että yksittäisten jäsenten osalta. Palavereissa käytiin myös läpi edellisessä palaverissa sovitut toimenpiteet sekä sovittiin tulevista toimenpiteistä. Ensimmäisissä palavereissa sovittiin lisäksi projektin läpivientiin liittyvistä käytänteistä, kuten mahdollisista sopimuksista sekä dokumenteista ja niiden kielestä. Palavereissa keskusteltiin toteutettavan sovelluksen ominaisuuksista ja vaatimuksista sekä niiden toteutusratkaisuista. Palavereissa käsiteltävät asiat pyrittiin käymään läpi niin perusteellisesti, että kaikki projektiorganisaatioon kuuluvat henkilöt ymmärsivät asiat samalla tavalla, eikä väärinymmärryksiä päässyt syntymään. Jos projektiryhmällä oli esittää käyttöliittymästä konkreettisia hahmotelmia, ne esi- 20(71)

29 tettiin palavereissa. Varsinaista sovelluksen toimintaa esiteltiin palaverien jälkeen ryhmän työtilan Linux-mikrolla, koska sovellus ei toimi kokoushuoneessa olevan mikron Windows-käyttöliittymässä. Jokainen ryhmän jäsen toimi vuorollaan sihteerinä ja puheenjohtajana. Roolit kiersivät siten, että edellisen palaverin puheenjohtaja toimi seuraavan palaverin sihteerinä. Puheenjohtaja piti huolen siitä, että palaveri eteni esityslistan osoittamalla tavalla. Sihteerin tehtävänä oli laatia palaverista pöytäkirja, jonka puheenjohtaja tarkasti ennen sen toimittamista projektiorganisaatiolle. Puheenjohtaja toimitti jokaisen jäsenen laatiman ensimmäisen pöytäkirjan myös Santaselle ja Leinolle tarkastettavaksi ennen pöytäkirjan toimittamista projektiorganisaatiolle. Pöytäkirjaan voitiin esittää muutoksia joko etukäteen tai seuraavassa palaverissa, jossa pöytäkirja käytiin läpi. Palavereissa pöytäkirja voitiin hyväksyä sellaisenaan, hyväksyä muutoksin tai jättää hyväksymättä. Roolit kiersivät suunnitellusti. Pöytäkirjoista hyväksyttiin jokainen seuraavassa palaverissa sellaisenaan tai pienin muutoksin. Ensimmäisiin pöytäkirjoihin ehdotettiin muutoksia sähköpostilla, mutta myöhemmin muutosehdotuksia tuli vasta seuraavassa palaverissa. Ryhmä sai parissa palaverissa palautetta huonosta valmistautumisesta, mutta palavereissa saatiin käsiteltyä asioita riittävästi. 5.2 Tiedotus Projektiin liittyvien asioiden tiedotuksesta projektiryhmän ja muun organisaation välillä vastasi ensisijaisesti projektipäällikkö. Jokainen ryhmän jäsen oli kuitenkin vastuussa hänelle osoitettuun tehtävään, tulokseen tai muuhun vastuualueeseen liittyvästä tiedotuksesta. Kun projektissa oli päästy perehtymisvaiheesta varsinaiseen sovelluksen kehitykseen, oli projektipäällikön tarkoitus toimittaa projektiorganisaatiolle pari kertaa viikossa lyhyt tilaraportti kuvaten, mitä ollaan tehty, missä on ollut ongelmia ja mitä aiotaan tehdä seuraavaksi. Tällä tavalla ohjaajat ja tilaaja pystyivät puuttumaan mahdollisiin virheisiin mahdollisimman nopeasti ajan säästymiseksi. Käytännössä projektipäällikkö ei kyseisiä viikottaisia tilakatsauksia juurikaan toimittanut pääosin siksi, että projektiryhmä oli muutenkin lähes viikottain yhteydessä tilaajan edustajaan ja ohjaajiin, ja heidät saatiin pidettyä ajan tasalla sen kautta. Ryhmän jäsenten keskinäinen tiedotus hoidettiin pääosin kasvotusten, koska kaikki 21(71)

30 ryhmän jäsenet työskentelivät suurimmaksi osaksi samassa tilassa. Jos suullinen tiedotus ei ollut mahdollista, hoidettiin yhteydenpito sähköpostitse. Periaatteena oli, että vapaa-ajalla ei tarvitse projektia miettiä, joten puhelimen ja pikaviestinten käyttöä pyrittiin välttämään, ellei asiasta erikseen sovittu. Ohjaajille ja tilaajan edustajalle suunnattu tiedotus hoidettiin ensisijaisesti yhteisen sähköpostilistan kautta. Sähköpostilistan osoite on ja sen jakelulistalle kuuluivat kaikki projektiorganisaation edustajat. Kaikki listalle lähetetyt viestit tallentuivat sähköpostiarkistoon, joka on nähtävillä osoitteessa Projektiryhmän jäsenten ja ohjaajien käytössä oli myös toinen sähköpostilista Sen sähköpostiarkisto sijaitsee osoitteessa hoksotin_opetus/. Sähköpostitse tiedotus onnistui suurimmalta osin. Tilaajan edustajalla ja teknisellä asiantuntijalla oli kuitenkin paljon muitakin kiireitä, joten he eivät kaikkia viestejä seuranneet. Vastauksen saaminen joihinkin kysymyksiin viivästyikin hieman, koska ryhmän jäsenet eivät olleet maininneet viestin otsikkokentässä viestin koskevan nimenomaan tilaajan edustajaa tai teknistä asiantuntijaa. 5.3 Tiedostojen nimeäminen ja hakemistorakenne Lähdekooditiedostojen nimeämisessä käytettiin Pythonin yleisiä käytänteitä [11]. Nimeämisessä käytettiin ainoastaan pieniä kirjaimia, ja välilyönnit korvattiin alaviivalla. Dokumenttitiedostot nimettiin kirjaamalla järjestyksessä projektin nimi, dokumentin nimi ja dokumentin kolmitasoinen versionumero, esimerkiksi HoksotinProjektisuunnitelma0.3.0.pdf. Versionumerointia kuvataan tarkemmin luvussa 5.6. Projektin tulokset tallennettiin CD-levylle ja projektin WWW-hakemistoon seuraavan hakemistorakenteen mukaisesti: projektilausunnot application_report ajankaytto 22(71)

31 class_documentation esittelyt palaverit esityslistat poytakirjat tilakatsaukset application projektiraportti projektisuunnitelma requirements_specification sahkopostiarkistot hoksotin hoksotin_opetus sitoumus_ja_lisenssit source_code Tiedostojen nimeäminen toteutui suunnitellusti. Hakemistorakenne muuttui testauksen osalta. Koska varsinaista järjestelmätestausta ei projektissa suunniteltu eikä suoritettu, ei testaukseen liittyviä dokumentteja myöskään kirjoitettu. Lisäksi projektisuunnitelmassa mainittua itsearvioinnit-osiota ei hakemistoon laitettu. Sen sijaan kansion ensimmäiselle välilehdelle laitettiin projektilausunnot-osio, johon sijoitettiin ryhmän jäsenteen arvioinnit sekä ohjaajien ja tilaajan edustajan lausunnot. Asennusohjeet sijoitettiin asennettavan ohjelman yhteyteen. 5.4 Lähdekoodi Lähdekoodi kirjoitettiin vastaamaan yleisiä Pythonin käytänteitä [11] ja Doxygenin mukaisia käytänteitä [12]. Lähdekoodissa käytetyt aliohjelmat, luokat ja muuttujat nimettiin mahdollisimman kuvaavilla englanninkielisillä nimillä. Myös lähdekoodin kommentointi tapahtui englanniksi. Alla on esimerkki edellisiä käytänteitä noudattaen toteutetusta Python-koodista. # coding: latin1 23(71)

32 """ Created on Mar 6, Jaakko Leppäkangas """ import mne import datetime import re class MeasurementInfo(object): """ A class for collecting information from MEG-measurements. """ def init (self, raw): """ Constructor Keyword arguments: raw -- Raw object Raises a TypeError if the raw object is not of type mne.fiff.raw. """ if isinstance(raw, mne.fiff.raw.raw): self._raw = raw self._info = dict(raw.info) else: raise TypeError( Not a Raw object. def high_pass(self): """ Returns the online high pass cutoff frequency in Hz. Raises an exception if the field highpass does not exist. """ if self._info.get( highpass ) is None: raise Exception( Field highpass does not exist. ) 24(71)

33 else: return self._info.get( highpass ) Lähdekoodi kirjoitettiin suunniteltuja käytänteitä noudattaen. Luokkadokumentaatio [15] suunniteltiin luotavaksi PyDocilla, mutta ryhmä päättikin projektin lopussa käyttää Doxygeniä pääosin siksi, että Potku-projekti oli käyttänyt sitä ja Potkun jäsenet kehuivat sitä paremmaksi. 5.5 Testaus Toteutettavan sovelluksen toiminta pyrittiin varmistamaan yksikkö- ja järjestelmätestauksella. Testauksen tarkoituksena oli löytää lähdekoodista virheitä sekä varmistaa, että sovellus toimii suunnitellusti sekä täyttää sille asetetut toiminnalliset ja laadulliset vaatimukset. Lähdekoodin yksikkötestaus oli lähdekoodin kirjoittajan vastuulla. Yksikkötestauksessa ohjelmoijan kuului varmistaa, että hänen kirjoittamansa koodi toimii suunnitellusti. Yksikkötestaus oli tarkoitus suorittaa lähdekoodin kirjoittamisen yhteydessä. Yksikkötestaus toteutettiin pääosin kunkin toiminnallisuuden koekäytöillä ja debuggaamalla. Sovellukseen kirjoitettiin laskennallista koodia hyvin vähän. Laskennalliselle koodille ohjelmoitiin erilliset yksikkötestit. Nämä testit koodiin kirjoitti poikkeuksellisesti Atte Rautio, vaikka itse koodi olikin toisen jäsenen kirjoittamaa. Ryhmän jäsenet testasivat kirjoittamaansa koodia ohjelmoinnin aikana. He kirjoittivat koodin sekaan testirivejä, joilla he saattoivat esimerkiksi varmistaa, että heidän kirjoittamansa koodin tulostus haluttua. Lisäksi he koekäyttivät ohjelmaa aktiivisesti ohjelmoinnin aikana, jotta he varmistuisivat sovelluksen kokonaisrakenteen pysyvän kasassa. Näitä testeja ei kuitenkaan jätetty mihinkään näkyviin, vaan ne poistettiin koodin joukosta heti, kun koodin tiedettiin toimivan. Järjestelmätestauksesta vastuussa olevan henkilön oli tarkoitus laatia testauksen suorittamiseksi testaussuunnitelma, joka olisi sisältänyt kullakin testauskerralla suoritettavat testitapaukset vaihe vaiheelta. Järjestelmätestauskerran suorittanut henkilö olisi laatinut siitä testausraportin, jossa kuvataan testauskerroilla suoritettujen testitapausten tulokset sekä havaitut virheet ja puutteet. Järjestelmätestauksessa käytettävä mittausaineisto saatiin tilaajalta. Järjestelmätestaus oli tarkoitus suorittaa 25(71)

34 kaksi kertaa projektin aikana. Koska varsinainen toteutus saatiin kuitenkin aloitettua vasta maaliskuun lopulla, päätettiin testaukseen varattuja työtunteja siirtää toteutukseen ja suunnitteluun. Täten järjestelmätestausta ei suoritettu suunnitellusti. Sovelluksen käytettävyyteen kiinnitettiin huomiota kaikkien kehitysvaiheiden aikana. Käytettävyydestä saatiin paljon palautetta käytettävyysasiantuntija Meeri Mäntylältä, tilaajan edustajilta ja projektin ohjaajilta sekä suullisesti että sähköpostitse. Varsinaista käytettävyystestausta ei kuitenkaan projektissa suoritettu, mutta mahdolliset esille tulleet kriittiset puutteet ja epäloogisuudet kirjattiin ylös viimeistään esiteltäessä sovellusta tilaajalle ja ohjaajille. 5.6 Versiohallinta ja -numerointi Tulosten versiohallintaan käytettiin Git-versiohallintaohjelmistoa. Sovelluksen lähdekoodi sijoitettiin Git-pohjaiseen YouSource-julkistusjärjestelmään, josta se oli koko ajan myös ohjaajien saatavilla. Julkistetuissa dokumenttien versioissa käytettiin kolmiportaista versionumerointia. Ryhmän sisäiset versiot aloitettiin versionumerosta 0.0.1, ja kunkin uuden version osalta kasvatettiin vähiten merkitsevää numeroa yhdellä. Tällöin toinen versio oli versionumeroltaan Projektiorganisaatiolle julkistettavien versioiden numerointi aloitettiin versionumerosta Seuraavat versiot numeroitiin kasvattamalla toisen tason numeroa yhdellä. Ensimmäisen hyväksytyn version numero on 1.0.0, ja sitä seuraavissa hyväksytyissä versioissa kasvatettiin toisen tason numeroa yhdellä, joten toinen hyväksytty versio on Sovelluksesta ei julkaistu versioita kesken projektin. Koska toteutettu sovellus oli prototyyppi, annettiin sille versionumeroksi Versiohallinnan käyttö sekä dokumenttien nimeäminen ja numerointi toteutui suunnitellusti. 5.7 Katselmoinnit ja tulosten hyväksyminen Projektiryhmän kirjoittama lähdekoodi katselmoitiin kaksi kertaa. Katselmoinnissa tekninen ohjaaja kommentoi lähdekoodia antaen vinkkejä ja parannusehdotuksia. 26(71)

35 Katselmointiin osallistui teknisen ohjaajan lisäksi koko projektiryhmä sekä vastaava ohjaaja. Projektin lopussa tulokset kokonaisuutena hyväksytettiin projektin ohjaajilla sekä tilaajan edustajalla. Yksittäisistä tuloksista tilaajan edustajan hyväksyntä tarvittiin vähintään toteutetulle sovellukselle, sovellusraportille ja projektiraportille. Lisäksi vaatimusmäärittelylle ja projektisuunnitelmalle hankittiin tilaajan hyväksyntä. Tekninen ohjaaja hyväksyi lähdekoodin. Vastaava ohjaaja hyväksyi projektin keskeisimmät raportit, joita ovat projektisuunnitelma, projektiraportti, sovellusraportti ja vaatimusmäärittely. Suunnitelman mukaan lähdekoodin katselmoinneista tuli laatia muistio. Muistioita ei kuitenkaan kirjattu, koska ryhmä sai palautteet tekniseltä ohjaajalta muutenkin kirjallisena. 5.8 Tulosten koostaminen ja julkaisu Projektiryhmä kokosi projektin tulokset sekä erilliseen projektikansioon että CDlevylle. Projektikansioon kerättiin kaikki projektissa laaditut dokumentit ja lähdekoodilistaukset. Lisäksi sähköpostiarkistot ja jäsenten itsearvioinnit liitettiin projektikansioon ja CD-levylle. CD-levylle tallennettiin edellisten ohella myös kehitetty sovellus. CD-levy koostettiin vasta, kun kaikki projektin tulokset oli hyväksytty. Tulokset toimitettiin tilaajalle CD-levyllä. Laitokselle toimitettiin projektikansio kera projekti- CD:n. Toinen CD-levy toimitettiin laitoksen arkistoon. Projektikansio sijoitettiin projektitilan kokoushuoneessa olevaan kirjahyllyyn. Tulosten koostaminen ja julkaisu toteutuivat suunnitellusti. 27(71)

36 6 Projektin tehtävät ja niiden jakautuminen Luvussa esitellään projektin oleellisimpien tulosten vastuuhenkilöt, tehtäväkokonaisuudet ja tehtävät sekä jäsenten arvioidut ja toteutuneet työtunnit tehtävittäin. Vastuualueiden jakautuminen onnistui pääosin suunnitellusti. Ainoastaan testaus jäi suunniteltua suppeammaksi, joten Kari Alirannan vastuu painottui hieman enemmän käyttöliittymän toteutukseen. Projektin tehtävien määrittely tehtiin maaliskuun alussa, jolloin projektiryhmällä oli vielä hyvin hatara kokonaiskuva sovelluksen rakenteesta. Tämän vuoksi toteutuneet tehtävät eivät täysin vastanneet suunniteltuja. Projektille ja sen oheiskurssille oli varattu aikaa 350 tuntia per jäsen eli yhteensä 1400 tuntia. Jokaisen jäsenen kohdalla tuntimäärä ylittyi muutamalla kymmenellä tunnilla eli projektiin käytettiin aikaa yhteensä noin 1650 tuntia. Esitutkimukseen kuluva aika oli selkeästi aliarvioitu projektisuunnitelmassa, koska projektin aihe osoittautui paljon arvioitua vaativammaksi. Esitutkimukselle oli varattu aikaa 114 tuntia, mutta siihen käytettiin 154 tuntia eli aarvio ylitty 40 työtunnilla. Oheiskurssille varattu aika oli hieman yliarvioitu projektisuunnitelmassa. Toisaalta osa oheiskurssiin liittyvistä tehtävistä oli merkitty muihin tehtäväkokonaisuuksiin. Koska ryhmän jäsenille oli vaikea päättää, mitkä tunnit pitäisi kirjata sovelluksen suunnitteluun ja mitkä toteutukseen, on näitä tehtäväkokonaisuuksia tarkasteltava yhtenä kokonaisuutena. Suunnittelulle ja toteutukselle oli yhteensä varattu 454 tuntia koko ryhmälle. Niihin käytettiin yhteensä aikaa 603 tuntia, eli toteuma ylitti suunnitelman 150 tunnilla. Järjestelmätestausta ei projektissa suoritettu, vaan siihen varatut 30 työtuntia käytettiin sovelluksen suunnitteluun ja toteutukseen. 6.1 Projektipäällikkö ja varapäällikkö Projektipäällikkönä toimi Atte Rautio ja varapäällikkönä Jaakko Leppäkangas. Projektipäällikön tehtäviin kuului projektin läpiviennin suunnittelu ja hallinta, ajankäytön ja projektin etenemisen seuranta ja tiedotus sekä ryhmän sisäisten tehtävien jakaminen jäsenille. Projektipäällikkö oli vastuussa myös projektisuunnitelman ja -raportin laatimisesta. 28(71)

37 Varapäällikön tehtävänä oli toimia projektipäällikön sijaisena tämän poissaollessa. Varapäällikkö joutui hoitamaan projektipäällikön tehtäviä ainoastaan kerran projektissa, kun projektipäällikkö oli ennakoimattomasti poissa palaverista. Varapäällikön olisi tuolloin pitänyt esitellä projektin tilakatsaus. Hänellä ei kuitenkaan tilakatsausta ollut, eikä projektipäällikkö ollut huomannut mainita säilyttävänsä tilakatsauksia projektin WWW-levyllä. Merkittävää haittaa projektipäällikön poissaolosta ei kuitenkaan ollut, vaan tilakatsaus lähetettiin myöhemmin samana päivänänä sähköpostitse. 6.2 Vastuualueet tulosten osalta Keskeisimpien tulosten vastuuhenkilöt ja tulosten hyväksymispäivämäärät on esitetty taulukossa 6.1. Taulukossa on esitettynä toteutettavaksi suunnitellut tulokset, niiden vastuuhenkilöt, ja tulosten hyväksymispäivämäärät. Vastuuhenkilö ei yksinään toteuttanut tulosta, mutta vastasi sen valmistumisesta, tarkastettavaksi toimittamisesta ja mahdollisista vaadituista muokkauksista. Myös tiedottaminen kyseisen tuloksen valmistumisesta kuului siitä vastaavan henkilön tehtäviin. Käytännössä tiedotus hoidettiin palavereissa. Tulos Vastuuhenkilö Hyväksytty Projektisuunnitelma Atte Rautio Vaatimusmäärittely Janne Pesonen? Sovelluksen kokonaisrakenne Jaakko Leppäkangas Sovellusraportti Kari Aliranta? Lähdekoodin viimeistely Jaakko Leppäkangas Projektiraportti Atte Rautio? Taulukko 6.1: Vastuualueet keskeisimpien tulosten osalta. Taulukosta puuttuu järjestelmätestaus, jonka suunnittelu ja suorittaminen oli suunniteltu Kari Alirannan vastuulle. Koska järjestelmätestaus päätettiin kuitenkin jättää projektissa suorittamatta, on se poistettu taulukosta. Taulukossa 6.1 lueteltujen tulosten ohella Kari Aliranta vastasi erilaisten sovelluksen käyttöön liittyvien ohjeiden kirjoittamisesta. Hän kokosi myös ryhmän jäsenille tarkoitettuja ohjeita työkaluihin ja niiden asennukseen liittyen. Nämä ohjeet no- 29(71)

38 peuttivat ryhmän työskentelyä varsinkin projektin alkuvaiheessa. Lisäksi Aliranta pääosin vastasi projektin oheiskurssin tehtäviin liittyvien muistioiden kirjoituksesta sekä laati oheiskurssiin kuuluvien esittelyjen kalvoja. Sovelluksen kokonaisrakennetta ei varsinaisesti hyväksytetty. Pikemminkin Jaakko Leppäkankaan tehtävänä oli pitää huoli siitä, että sovelluksen rakenne pysyy loogisena toteutuksen aikana. Leppäkangas vastasi muutenkin toteutuksesta selvästi muuta projektiryhmää enemmän. Vastuualueiden jakautuminen toteutui suunnitellusti lukuunottamatta järjestelmätestausta, jota ei projektissa ehditty projektiryhmän toimesta suorittamaan. Lisäksi ryhmällä ei ollut käytössään MaxFilter-ohjelmistoa, jota sovellus hyödyntää datan esikäsittelyssä, joten perusteellinen testaus oli mahdotonta. Muutenkin testauksesta siirrettiin työtunteja sovelluksen toteutukseen, joten järjestelmätestaukselle ei jäänyt työtunteja. Testausta suoritettiinkin lähinnä yksikkötestien muodossa. Lisäksi ohjaajat ja tilaajan edustaja koekäyttivät ohjelmistoa. 6.3 Tehtävät ja työmäärät Projektiryhmän jäsenten sovellusprojektin ja siihen liittyvien oheiskurssien arvioidut ja toteutuneet työtunnit on esitetty taulukossa 6.2 tehtäväkokonaisuuksittain ja tehtävittäin. Työtuntiarviot perustuvat sovelluksen eri osakokonaisuuksien arvioituihin vaativuuksiin. Vaativuuksia oli kuitenkin hankala arvioida etukäteen ryhmän jäsenten vähäisen projektityöskentelykokemuksen vuoksi, joten joidenkin tehtävien toteutuneet työtunnit ylittivät arviot. Lisäksi joitain tehtäviä, kuten esimerkiksi rajapintojen suunnittelua ja toteutusta ei edes tehty, koska niille ei ollutkaan tarvetta. Esitutkimukseen ja datan esikäsittelyyn liittyvien tehtävien tuntiarvioiden ylittymisen vuoksi jouduttiin suuri osa analyysiin liittyvistä ominaisuuksista sopimaan tilaajan kanssa jatkokehitykseen. 30(71)

39 KA JL JP AR Kaikki Tehtäväkokonaisuus Tehtävä S T S T S T S T S T Projektin hallinta Toiminnan suunnittelu Projektisuunnitelma Seuranta Tiedotus Sopimukset Asennukset Projektiraportti Tulosten viimeistely Tulosten luovutus Yhteensä Palaverit Valmistelu Palaverit Pöytäkirjat Yhteensä Esitutkimus Aihealueeseen tutustuminen Koulutus Työkaluihin tutustuminen Yhteensä Vaatimusmäärittely Suunnittelu Raportointi Yhteensä Suunnittelu Käyttöliittymä Sovelluksen rakenne Asetusten tallennus Raportointi Visualisointi Esikäsittelynäkymä Keskiarvoistusnäkymä Visualisointinäkymä Tiedostohallinta Lokitiedot TFR-näkymä Lähdetasonäkymä Rajapinnat Yhteensä Toteutus Sovelluksen rakenne Käyttöliittymä Asetusten tallennus Visualisointi Esikäsittelynäkymä Raportointi Keskiarvoistusnäkymä Tiedostohallinta Lokitiedot Rajapinnat TFR-näkymä Lähdetasonäkymä Visualisointinäkymä Yhteensä Järjestelmätestaus Suunnittelu Testauskerrat Raportointi Yhteensä Viimeistely Sovellusraportti Lähdekoodin katselmointi Lähdekoodin viimeistely Sovelluksen luovutus Yhteensä Projektin tunnit yhteensä Oheiskurssi Kirjoitusviestintä Puheviestintä Projektiluennot Yhteensä Projektin ja oheiskurssien tunnit yhteensä Taulukko 6.2: Tehtävien suunnitellut ja toteutuneet työtunnit.

40 Työtuntien kirjaamisessa oli hankalaa päättää, minkä tehtävän alle käytetyt tunnit kirjataan varsinkin, jos tehtiin useaa asiaa samanaikaisesti. Esimerkiksi Rautio saattoi kirjata jonkin päivän kaikki tunnit projektisuunnitelman kirjoittamiseen, vaikka oli kirjoittamisen ohella ottanut osaa sovelluksen suunnitteluun tai etsinyt ratkaisuja toteutuksen aikana ilmenneisiin ongelmiin. Lisäksi oli hankala arvioida, milloin työtunnit pitäisi kirjata toteutukseen ja milloin suunnitteluun, koska sovellusta suunniteltiin ja toteutettiin usein samanaikaisesti. Tämän takia suunnittelua ja toteutusta kannattaakin tarkastella taulukossa yhtenä kokonaisuutena. Työtuntien kirjaamista hankaloitti myös se, että ryhmän käyttämä ajankäyttösovellus ei toimi Linuxissa, ja ryhmän työtilassa oli vain yksi Windows-kone, joka oli pääosin Raution käytössä. Työtuntien kirjaaminen hoidettiinkin siten, että muut jäsenet kirjasivat tuntinsa erilliselle papereille, ja Rautio päivitti ne ajankäyttöseurantasovellukseen säännöllisin väliajoin, yleensä silloin, kun hän aloitti tulevan palaverin tilakatsauksen laatimisen. Ryhmän jäsenet eivät aina eritelleet työtuntejaan tehtävittäin, vaan ilmoittivat kunakin päivänä käyttäneensä työtunnit yhtenä kokonaisuutena. Tämän vuoksi joissain tehtävissä saattaa olla merkittynä muutama tunti liikaa, kun taas joissain muutama tunti liian vähän. Tällaisten virheellisesti kirjattujen työtuntien määrä on kuitenkin hyvin pieni eikä olennaisesti vaikuta työtuntien prosentuaaliseen jakaumaan ja siten työtuntien analyysiin. Projektin hallintaan kuluva aika toteutui aika pitkälti suunniteltuna. Leppäkankaalle oli varattu projektin hallintaan yhteensä 23 tuntia siltä varalta, että hän joutuisi hoitamaan projektin varapäällikön tehtäviä, mutta näin ei kuitenkaan projektissa käynyt. Rautiolle oli varattu tiedotukselle 10 tuntia, mutta toteuma oli ainoastaan 2 tuntia. Pääosin tämä johtui siitä, että hän teki tiedotusta muiden tehtävien ohella, ja merkitsi tiedotukseenkin kuluneen ajan näihin tehtäviin. Projektiraporttiin oli varattu aikaa 35 tuntia, mutta toteuma oli suunnitelmaan verrattuna lähes kaksinkertainen, mikä osaltaan vaikutti projektin viivästymiseen. Aliranta muokkasi projektin tietovaraston rakenteen kertaalleen uusiksi, ja siihen kuluneet työtunnit kirjattiin toiminnan suunnittelun alle. Asennukset ja niihin liittyvien ohjeiden kirjoitus keskittyivät lähinnä Pesoselle ja Alirannalle. Palavereihin kulunut aika toteutui hyvin pitkälti suunniteltuna. Ainoa selkeä ero suunnitelmaan on Leppäkankaan kohdalla tehtävässä pöytäkirjat. Leppäkangas sattui olemaan sihteerinä kaikista nopeimmissa palavereissa, joissa ei ollut paljoa kirjattavaa pöytäkirjaan. Siten hänellä kului pöytäkirjoihin paljon muita vähemmän aikaa. Palavereihin kirjattujen tuntien ero selittyy sillä, että muutaman palaverin jälkeen käytiin sovelluksen toimintaa läpi ryhmän työtilassa. Osa jäsenistä merkitsi- 32(71)

41 vät tämänkin ajan palavereihin, kun taas toiset esimerkiksi suunnitteluun tai toteutukseen. Rautio ja Leppäkangas olivat poissa yhdestä palaverista, joten heillä kului palavereihin hieman vähemmän aikaa kuin muilla. Toisaalta Leppäkangas kävi huhtikuun lopussa viikolla 18 tapaamassa tilaajan teknistä asiantuntijaa Espoossa, ja merkitsi tämän tapaamisen myös palavereihin. Rautio laati jokaiseen palaveriin tilakatsauksen alkaen kolmannesta palaverista, joten hänellä kului muita enemmän työtunteja palaverien valmisteluun. Esitutkimukseen käytetyt työtunnit ylittivät suunnitellut selkeästi. Tämä johtuu pääosin aihealueeseen tutustumiseen käytetystä ajasta. Projektisuunnitelmassa oli varattu aihealueeseen tutustumiseen Alirannalle ja Leppäkankaalle eniten aikaa. Ajatuksena oli, että he tutustuvat aiheeseen Pesosen laatiessa vaatimusmäärittelyä ja Raution laatiessa projektisuunitelmaa. Pesonen ja Rautio voisivat sitten tarvittaessa kysyä heiltä neuvoa, jos ilmenee ongelmia. Aihe oli kuitenkin sen verran vaikea, että kaikki joutuivat käyttämään tutustumiseen suurin piirtein saman verran aikaa. Myös ryhmän tekemä yhteensä 14 tunnin matka Espooseen tapaamaan tilaajan teknistä asiantuntijaa merkittiin aihealueeseen tutustumiseen. Täten aihealueeseen tutustumiseen käytetty aika ylitti suunnitelman 42 tunnilla. Aihealueen vaativuuden aiheuttama viivästys oli kuitenkin kalenteriajassa tätä suurempi, koska ilman kunnollista aiheen ymmärtämistä, oli hankalaa suunnitella ja toteuttaa sovellusta. Kuten jo aiemmin todettiin, kannattaa tehtäväkokonaisuuksia suunnittelu ja toteutus tarkastella yhdessä. Lisäksi on huomioitava, että niiden suunnitellut tehtävät perustuivat vain oletukseen siitä, mitä kokonaisuuksia sovelluksessa saattaisi olla. Tehtävät on arvioitu maaliskuun alussa, kun kokonaiskuva sovelluksesta oli hyvin hatara. Suunnittelulle ja toteutukselle oli varattu yhteensä aikaa 454 tuntia. Niihin kuitenkin käytettiin 588 työtuntia eli 134 työtuntia suunniteltua enemmän. Näistä 30 työtuntia siirtyivät järjestelmätestauksesta, joka päätettiin jättää suorittamatta projektissa. Loput 104 ylimääräistä työtuntia tulevat oheiskurssin suunnitellun työtuntimäärän alittamisesta sekä osittain siitä, että kukin jäsen ylitti työtuntitavoitteen noin 40 työtunnilla. Selkeästi suunniteltua enemmän aikaa veivät tehtävät sovelluksen rakenne, käyttöliittymä, tiedostohallinta js esikäsittelynäkymä. Tämä selittyy osaksi sillä, että suunnitteluun ja toteutukseen määritellyt tehtävät eivät täysin vastanneet lopullisen sovelluksen osakokonaisuuksia. Ryhmän jäsenet eivät olleet aina aivan varmoja, minkä tehtävän alle työtunnit pitäisi kirjata, joten suurin osa työtunneista on kirjattu käyt- 33(71)

42 töliittymän ja sovelluksen rakenteen alle. Esikäsittelynäkymä osoittautui paljon oletettua monimutkaisemmaksi, ja siihen käytetyt työtunnit ylittivät suunnitelman 72 työtunnilla. Lisäksi sovelluksella tuettavaa prosessia on hyvin vaikea jakaa selkeisiin peräkkäisiin vaiheisiin, joten käyttöliittymän kokonaisrakenteen hahmottaminen oli vaikeaa. Sovelluksen rakenne oli sovittu Leppäkankaan vastuulle ja käyttöliittymän kokonaisrakenne Alirannan vastuulle. Vastuujako näkyy tehtävien toteumissa. Pesoselle oli suunniteltu työtunteja tasaisesti eri suunnittelun ja toteutuksen tehtäville. Hän kuitenkin käytti pääosan koodausajastaan erilaisten pienempien dialogien tekemiseen sekä tiedostojen tallennukseen. Esikäsittelyn työtuntiarvion ylittymisen vuoksi analyysiin liittyviä toimintoja ja näkymiä ei ehditty projektissa juurikaan toteuttaa. TFR- ja keskiarvoistusnäkymä saatiin kyllä käyttöliittymään toteutettua, mutta niihin liittyen ehdittiin toteuttaa ainoastaan kuvaajien piirtämiset. Sensoritasolta lähdetasolle siirtymiseen liittyviä toimintoja ei ehditty aloittaa. Järjestelmätestaus päätettiin projektissa jättää suunnitelmasta poiketen suorittamatta. Siihen varatut Alirannan ja Pesosen työtunnit siirrettiin sovelluksen suunnitteluun ja toteutukseen. Viimeistely vaati oletettua enemmän työtunteja. Projektisuunnitelmassa viimeistelylle oli varattu 84 työtuntia, mutta siihen käytettiin 139 työtuntia. Eniten ylimääräisiä työtunteja kertyi lähdekoodin viimeistelylle. Lähdekoodiin jouduttiin lisäämään jonkin verran poikkeusten käsittelyä, ja kommentointia jouduttiin lisäämään melkein joka luokkaan. Varsinkin kommentointiin olisi pitänyt kiinnittää paremmin huomiota jo toteutuksen aikana. Kommenttien lisääminen koodeihin jälkikäteen oli hidasta ja vaikeaa. Oheiskurssin työtuntien toteumat alittivat suunnitelman 35 tunnilla. Varsinkin projektiluennoille varattu aika alittui. Tosin ryhmä merkitsi versiohallintaluennon työkaluihin tutustumiseen, vaikka se kuuluu projektiluentoihin. Projektiryhmän jäsenet olivat sitoutuneet työskentelemään projektin ja siihen liittyvän oheiskurssin eteen noin 5 tuntia päivässä. Tavoitteeseen 350 työtuntia kutakin jäsentä kohden oli tavoitteena päästä toukokuun loppuun mennessä. Tähän arvioon oli otettu huomioon kevään arkipyhät pääsiäinen, vappu ja helatorstai. Jaakko Leppäkankaalla suunnitellut tunnit tulivat täyteen jo toukokuun puolivälissä, mutta hän jatkoi projektin parissa työskentelemistä toukokuun loppuun asti. Muilla ryh- 34(71)

43 män jäsenillä työtuntitavoite tuli täyteen toukokuun lopussa viikoilla 21 ja 22. Tulosten viimeistely ja luovutus venyivät kesäkuulle, ja Leppäkankaalla alkoi tuolloin työharjoittelu. Täten Leppäkangas ei voinut osallistua projektiin enää kesäkuussa. Kesäkuun aikana muiden ryhmän työtunnit kasvoivat yli 400 työtuntiin per jäsen. Ryhmän jäsenet ylittivät työtuntitavoitteen vähintään 40 tunnilla. Työtunteja kertyi työtuntia per jäsen. Leppäkangas pääsi 388 tuntiin jo toukokuun puolessavälissä. Osittain tämä johtuu siitä, että projektille varattu kahden viikon pelivara päätettiin käyttää hyväksi. Toisaalta projektin viimeistelyyn liittyvien tehtävien työtunnit oli selkeästi aliarvioitu projektisuunnitelmassa, mikä osaltaan johti työtuntitavoitteen ylittymiseen. Viimeistely venyi kesäkuun kolmannelle viikolle, jolloin muut ryhmän jäsenet ylittivät 400 työtunnin rajan. Projektiin ja sen oheiskurssiin oli suunniteltu käytettävän yhteensä 1400 työtuntia, mutta niihin käytettiin 1612 työtuntia. Osittain tämä johti siihen, että sovellukseen saatiin vielä kehitettyä joitain ominaisuuksia, joita muuten ei olisi ehditty toteuttaa. Toisaalta työtuntitavoitteen selkeä ylittyminen näkyy projektin viivästymisessä. Kari Alirannalla oli aika paljon muita kursseja projektin alkuvaiheessa viikolle 10 asti, joten hän ei tuolloin ehtinyt käyttämään projektiin aikaa kovin paljoa. Hän oli sitoutunut panostamaan projektiin enemmän työtunteja projektin loppuvaiheessa. Tämän takia sovellusraportti siirrettiin hänen vastuulleen, vaikka aluksi se sovittiin Jaakko Leppäkankaan tehtäväksi. 6.4 Ryhmän työtunnit tehtäväkokonaisuuksittain Ryhmän työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.1. Sekä Esitutkimukseen että viimeistelyyn kului suunniteltua enemmän työtunteja. Projektiryhmä joutui käymään Espoossa yhtenä päivänä keskustelemassa tilaajan teknisen asiantuntijan kanssa sovelluksen toteutuksesta, mikä omalta osaltaan kasvatti esitutkimuksen tuntimäärää. Esitutkimukselle oli varattu noin 8% koko projektin työtunneista, mutta sen toteuma oli 10%. Aihealueen hidas sisäistäminen vaikeutti sovelluksen suunnittelua ja toteutusta varsinkin projektin alkupuoliskolla. Viimeistelylle oli varattu 6% työtunneita, mutta sen toteuma oli myös 10%. Lähes kaikkien viimeistelyyn liittyvien tehtävien työmäärät oli aliarvioitu projektisuunnitelmassa. Kuten luvussa 6.3 todettiin, on tehtäväkokonaisuuksia suunnittelu ja toteutus järkevintä tarkastella yhtenä kokonaisuutena. Suunnitteluun ja toteutukseen oli suunni- 35(71)

44 teltu käytettävän kolmasosa koko projektin työtunneista. Näiden toteuma oli kuitenkin 38%. Osa tunneista siirrettiin suoraan järjestelmätestauksesta, joka päätettiin jättää suorittamatta projektissa. Lisäksi ryhmän työtuntitavoite ylittyi noin 200 tunnilla, josta suurin osa oli suunnittelua ja toteutusta. Viimeistely; 154:48; 10 % Esitutkimus; 153:36; 9 % Määrittely; 75:25; 5 % Oheiskurssi; 216:55; 13 % Toteutus; 488:09; 30 % Palaverit; 161:51; 10 % Suunnittelu; 98:02; 6 % Projektin hallinta; 268:14; 17 % Kuva 6.1: Projektiryhmän työtunnit tehtäväkokonaisuuksittain. 6.5 Kari Alirannan työtunnit tehtäväkokonaisuuksittain Kari Alirannan työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.2. Koska vaatimusmäärittely oli Pesosen vastuulla, ei Alirannalla ole siihen yhtään kirjattua työtuntia. Hän toki osallistui vaatimusmäärittelyn suunnitteluun muiden tehtävien ohella, mutta kirjasi vaatimusmäärittelyynkin kuluneen ajan näihin muihin tehtäviin. Oheiskurssin osuus on Alirannalla 17% eli 3 prosenttiyksikköä suurempi kuin koko ryhmällä. Osasta oheiskurssin tehtävistä piti laatia muistiot, mikä annettiin Alirannan tehtäväksi. Viimeistelyn osuus on Alirannalla selkeästi suurempi kuin koko ryhmällä, mikä johtuu siitä, että sovellusraportti oli hänen vastuullaan. Projektin 36(71)

45 hallintaan kuuluvat tehtävät kuuluivat lähinnä projektipäällikölle, joten Alirannan osuus oli sen takia pienempi. Projektisuunnitelman mukaan Aliranta olisi ollut päävastuussa myös sovelluksen järjestelmätestauksesta sekä testaussuunnitelman ja -raportin kirjoittamisesta, mutta koska testausta ei projektissa ehditty kunnolla suorittaa, vapautuivat siihen varatut tunnit sovelluksen toteuttamiselle. Esitutkimus; 36:25; 9 % Viimeistely; 92:45; 23 % Oheiskurssi; 62:30; 15 % Palaverit; 40:20; 10 % Toteutus; 111:45; 27 % Suunnittelu; 30:20; 8 % Projektin hallinta; 34:25; 8 % Kuva 6.2: Kari Alirannan työtunnit tehtäväkokonaisuuksittain. 6.6 Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.3. Koska Leppäkangas toimi projektin varapäällikkönä, oli hänelle varattu projektisuunnitelmassa hieman enemmän aikaa projektin hallinnalle. Projektin hallintaan liittyviä tehtäviä hän ei kuitenkaan juurikaan joutunut hoitamaan, joten siihen varatut tunnit vapautuivat sovelluksen toteutukseen. Esitutkimukseen varatut tunnit ylittyivät kuitenkin hieman, koska hän kävi projektiryhmän yhteisen vierailun lisäksi toisenkin kerran Espoossa tapaamassa tilaajan teknistä asiantuntijaa. 37(71)

46 Leppäkangas ei myöskään kirjannut tunteja vaatimusmäärittelyyn, koska hän osallistui sen suunnitteluun muiden tehtävien ohella. Palaverien osuus on Leppäkankaalla hieman pienempi kuin koko ryhmällä. Hän kirjoitti pöytäkirjat nopeasti, eikä joutunut valmistelemaan tilakatsauksia palavereja varten. Viimeistely; 23:50; 6 % Esitutkimus; 42:45; 11 % Oheiskurssi; 46:30; 12 % Palaverit; 32:05; 8 % Projektin hallinta; 2:00; 1 % Toteutus; 209:15; 54 % Suunnittelu; 32:15; 8 % Kuva 6.3: Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain. Sovelluksen suunnitteluun ja toteutuksen osuus oli Leppäkankaalla huomattavasti suurempi kuin koko ryhmällä. Sovelluksen rakenne olikin pääosin hänen vastuullaan. 6.7 Janne Pesosen työtunnit tehtäväkokonaisuuksittain Janne Pesosen työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.4. Palaverit veivät Pesosen osalta suunniteltua vähemmän työtunteja pääosin siksi, että hän kirjoitti pöytäkirjat paljon ennakoitua nopeammin. Vaatimusmäärittelyn osuus on Pesosella selkeästi suurempi kuin koko ryhmällä. Vaatimusmäärittely oli hänen vastuullaan, joten hän oli Raution ohella ainoa, joka kirja- 38(71)

47 si työtunteja vaatimusmäärittelyyn. (Rautio kirjasi vain muutaman.) Projektin hallintaan liittyviä tehtäviä Pesonen ei juurikaan suorittanut, joten hänen osuus projektin hallinnasta on varsin vähäinen. Suunnittelua ja toteutusta Pesonen ehti tehdä suunniteltua enemmän. Näille oli Pesoselle varattu noin 30% työtunneista, mutta niiden toteuma oli 38%. Eroa oli siis 8 prosenttiyksikköä. Viimeistely; 22:45; 6 % Esitutkimus; 38:00; 9 % Määrittely; 72:00; 18 % Toteutus; 140:50; 34 % Oheiskurssi; 54:55; 13 % Suunnittelu; 3:45; 1 % Projektin hallinta; 42:15; 10 % Palaverit; 36:10; 9 % Kuva 6.4: Janne Pesosen työtunnit tehtäväkokonaisuuksittain. 6.8 Atte Raution työtunnit tehtäväkokonaisuuksittain Atte Raution työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.5. Rautio toimi projektipäällikkönä, joten lähes puolet hänen työtunneistaan kuluivat projektin hallintaan liittyviin tehtäviin. Myös palaverien osuus oli hänen osaltaan hieman suurempi koko ryhmän työtuntijakaumaan verrattuna, koska hänellä kului palaverien valmisteluun enemmän aikaa. Projektipäällikön tehtävistä johtuen Rautiolle ei jäänyt niin paljoa aikaa sovelluk- 39(71)

48 sen suunnitteluun ja toteutukseen kuin muilla ryhmän jäsenille. Kun suunnittelun ja toteutuksen osuus koko ryhmän työtunneista oli 48%, oli se Raution kohdalla vain 15%. Toteutus; 26:19; 6 % Viimeistely; 15:28; 4 % Esitutkimus; 36:26; 9 % Määrittely; 3:25; 1 % Suunnittelu; 31:42; 7 % Oheiskurssi; 53:00; 13 % Palaverit; 52:08; 12 % Projektin hallinta; 198:37; 48 % Kuva 6.5: Atte Raution työtunnit tehtäväkokonaisuuksittain. 40(71)

49 7 Prosessi ja aikataulu Luvussa käsitellään projektissa noudatettua prosessia ja aikataulua sekä verrataan niiden toteumaa suunnitelmaan. Toimintokokonaisuuksien kehityksen aikataulu muuttui hieman suunnitellusta, koska suurin osa sovelluksen toteutuksesta kului esikäsittelyn toteutukseen, joten itse analysointia ja visualisointia ehdittiin toteuttaa vähemmän. Sovelluksen toteutusta jatkettiin vielä toukokuun alkuviikkoina, joten projektille varattu kahden viikon pelivara jouduttiin käyttämään. Tulosten viimeistelyyn tarvittavat työtunnit oli selkeästi aliarvioitu projektisuunnitelmassa, joten projektin päättäminen venyi kesäkuun loppupuolelle. Lisäksi osa ryhmän jäsenista joutuivat keskittymään osan toukokuusta muiden kurssien päättämiseen. Prosessi ei toteutunut aivan suunnitellusti. Prosessi oli jaettu 2-3 viikon vaiheisiin siten, että uusia ominaisuuksia otettaisiin toteutettavaksi vaiheiden vaihtumisen välillä. Vaihejako ei kehityksen aikana pahemmin projektissa näkynyt, vaan uudet ominaisuudet otettiin kehitykseen vasta edellisten valmistuttua. Käytännössä esikäsittelyä kehitettiin suunnitelmasta poiketen kaikkien kehitysvaiheiden ajan. 7.1 Prosessi Projektissa ei varsinaisesti noudatettu mitään tiettyä prosessimallia. Projekti suunniteltiin läpivietäväksi ketterällä räätälöidyllä prosessilla, jossa sovellusta kehitetään ensisijaisesti inkrementaalisesti ja toissijaisesti iteratiivisesti läpi koko projektin elinkaaren. Projekti oli jaettu vaiheisiin siten, että vaiheen vaihtumisen kohdalla pidettiin projektipalaveri. Täten pystyttiin luontevasti esittelemään tilaajan edustajalle, mitä oltiin kussakin vaiheessa saatu aikaan. Kunkin vaiheen suunniteltiin kestävän kahdesta kolmeen viikkoa. Vaiheita suunniteltiin olevan kuusi kappaletta. Ensimmäisenä oli tutustumisvaihe, jonka aikana ryhmän jäsenet tutustuivat aihealueeseen ja käytettäviin työkaluihin. Lisäksi alettiin laatia vaatimusmäärittelyä sitä mukaa, kun sovelluksella tuettava prosessi selkeni. Projektin aihealue oli tosin niin vaativa, että siihen tutustumiseen jouduttiin käyttämään paljon suunniteltua enemmän aikaa. Tutustumisvaiheesta siirryttiin suunnitteluvaiheeseen, jonka aikana alettiin miettimään sovelluksen kokonaisrakennetta ja hahmottelemaan sovelluksen käyttöliit- 41(71)

50 tymää. Suunnitteluvaiheessa projektipäällikkö aloitti projektisuunnitelman laatimisen ja Pesonen jatkoi vaatimusmäärittelyn laatimista. Suunnitteluvaiheesta siirryttiin sovelluksen kehitysvaiheisiin. Näitä oli suunniteltu olevan kolme kappaletta. Vaiheet oli suunniteltu siten, että jokaisessa vaiheessa kehitetään joku ohjelmakokonaisuus. Vaiheen vaihtuessa otetaan uusi kokonaisuus työn alle siten, että se pohjautuu edellisessä vaiheessa toteutetulle ominaisuudelle tai jatkaa sitä. Vaiheiden vaihtuminen ei kehityksen aikana juurikaan näkynyt, vaan ryhmä käytti suurimman osan kehitysajasta datan esikäsittelyn kehitykseen. Viimeisestä kehitysvaiheesta siirryttiin viimeistelyvaiheeseen. Sovellusta ei enää varsinaisesti kehitetty vaan korjattiin lähdekoodista ja sen kommenteista olennaisimmat puutteet ja aloitettiin sovellusraportin ja projektiraportin kirjoittaminen ja viimeisteltiin vaatimusmäärittely. Noudatettavaa prosessimallia olisi pitänyt miettiä projektin alussa hieman tarkemmin. Toisaalta koska projektin aihealue ja tavoitteet olivat projektin läpivientiä suunniteltaessa vielä melko epäselvät, oli prosessin suunnittelu hankalaa. 7.2 Aikataulu Ennen varsinaisen projektin alkua sovellusprojektikurssilla oli projektiviestinnän luentoja sekä projektien aloitusluento. Projektin ensimmäinen tapaaminen tilaajan kanssa oli , jolloin projekti katsotaan alkaneeksi. Viikot 6, 7 ja 8 oli varattu tutustumisvaiheelle, jossa projektiryhmä tutustui kehitettävän sovelluksen taustoihin ja kohdealueeseen yleensä. Kehitystyökalujen asennukset ja niihin alustava tutustuminen tapahtuivat myös näiden viikkojen aikana. Seuraavan kahden viikon aikana eli viikoilla 9 ja 10 suunnitteluvaiheessa tutustuttiin työkaluihin tarkemmin ja alettiin hahmotella sovelluksen kokonaisrakennetta. Varsinainen sovelluksen kehitys suunniteltiin tapahtuvaksi maaliskuun alun ja huhtikuun lopun välisenä aikana kolmessa kehitysvaiheessa alkaen viikolla 11. Kuitenkin kuten aiemmin tässä luvussa todettiin, ei vaihejako kehityksen aikana juurikaan näkynyt. Kehitysvaiheiden aikana ryhmä joutui perehtymään aihealueeseen tarkemmin. Lisäksi monet pienemmät toiminnot vaativat lisäsuunnittelua. Toteutusta, suunnittelua ja tutustumista tehtiin kehitysvaiheiden aikana samanaikaisesti. Projektin tehtäväkokonaisuuksien ja tehtävien suunnitellut ja toteutuneet aikajän- 42(71)

51 teet esitellään kuvissa 7.1 ja 7.2. Suunnitelmaan oli jätetty noin kahden viikon pelivara toukokuun loppuun mahdollisia viivästyksiä varten. Tämä pelivara myös käytettiin ja projektin viimeistelyvaihe aloitettiin vasta viikolla 21, kun se oli suunniteltu aloitettavaksi jo viikolla 18. Rautio aloitti projektiraportin alustavan laatimisen kuitenkin jo viikolla 18. Projektin tulosten viimeistelyyn tarvittavat työtunnit oli selkeästi aliarvioitu projektisuunnitelmassa ja tulosten viimeistely ja luovuttaminen venyivät viikolle 25, vaikka projektin oli suunniteltu päättyvän viikolla 20. Lisäksi toukokuussa työskentelyä hidastivat ryhmän jäsenten muiden opintojen tentit. 43(71)

52 Kuva 7.1: Projektin suunniteltu aikataulu.

53 Kuva 7.2: Projektin toteutunut aikataulu.