Hoksotin-sovellusprojekti Kari Aliranta Jaakko Leppäkangas Janne Pesonen Atte Rautio Projektiraportti Julkinen Versio 0.2.0 17.5.2013 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä
Hyväksyjä Päivämäärä Allekirjoitus Nimenselvennys Projektipäällikkö..2013 Tilaaja..2013 Ohjaaja..2013
Tietoa dokumentista Tekijät: Kari Aliranta (KA) Jaakko Leppäkangas (JL) Janne Pesonen (JP) Atte Rautio (AR) kari.p.aliranta@student.jyu.fi jaeilepp@student.jyu.fi janne.o.pesonen@student.jyu.fi atte.m.rautio@student.jyu.fi Dokumentin nimi: Hoksotin-projekti, Projektiraportti Sivumäärä: 54 Tiedosto: HoksotinProjektiraportti0.2.0.tex Tiivistelmä: Hoksotin-projektissa kehitettiinn käyttöliittymäprototyyppi MEG-mittauslaitteella mitatun aivosignaalidatan esikäsittelyyn, analyysiin ja kuvantamiseen. Projektiraportti kuvaa Hoksotin-projektin toteutuneen läpiviennin sekä läpiviennin erot ja niiden 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. Avainsanat: Aikataulu, käytänteet, ohjelmistoprojekti, projektin läpivienti, prosessimalli, prototyyppi, resurssit, riskien hallinta, tavoitteet, tehtävät, toteuma, työmäärät, vastuualueet. i
Muutoshistoria Versio Päivämäärä Muutokset Tekijät 0.0.1 7.5.2013 Projektiraportin pohja on luotu. Pohjana käytetään projektisuunnitelman versiota 1.0.0. Osaa luvuista on muokattu projektiraporttia vastaaviksi. 0.0.2 13.5.2013 Projektiraporttia on kirjoitettu pidemmälle. Kuvaajiin ei kuitenkaan ole vielä koskettu. 0.1.0 13.5.2013 Projektiraporttia on kirjoitettu pidemmälle, ja se on toimitettu projektiorganisaatiolle tarkastettavaksi. 0.1.1 14.5.2013 Luku 8 on alustettavasti kirjoitettu. Työtuntitaulukon pohja on muokattu vastaamaan raporttia. 0.1.2 16.5.2013 Lukuja on kirjoitettu lisää. Raporttia on korjattu saadun palautteen perusteella. 0.2.0 17.5.2013 Raporttiin on lisätty alustavat aikataulukaaviot ja aikatauluja ja työtunteja on analysoitu. AR AR AR AR AR AR ii
Tietoa projektista Tekijät: Kari Aliranta (KA) Jaakko Leppäkangas (JL) Janne Pesonen (JP) Atte Rautio (AR) kari.p.aliranta@student.jyu.fi jaeilepp@student.jyu.fi janne.o.pesonen@student.jyu.fi atte.m.rautio@student.jyu.fi Tilaaja: Tiina Parviainen Tilaajan asiantuntija: Lauri Parkkonen tiina.m.parviainen@jyu.fi lauri.parkkonen@aalto.fi Ohjaajat: Tuomas Puoliväli Jukka-Pekka Santanen tuomas.a.b.puolivali@student.jyu.fi santanen@mit.jyu.fi Yhteystiedot: Sähköpostilista Sähköpostiarkisto Sähköpostilista (opetus) Sähköpostiarkisto (opetus) hoksotin@korppi.jyu.fi https://korppi.jyu.fi/kotka/servlet/ list-archive/hoksotin/ hoksotin_opetus@korppi.jyu.fi https://korppi.jyu.fi/kotka/servlet/ list-archive/hoksotin_opetus/ iii
iv
Sisältö 1 Johdanto 1 2 Termejä 3 2.1 Aihealueen termejä............................. 3 2.2 Kehitysvälineisiin ja -tekniikoihin liittyviä termejä........... 4 3 Projektin tavoitteiden toteutuminen 6 3.1 Projektin taustaa............................... 6 3.2 Sovellukselle asetetut tavoitteet...................... 8 3.3 Sovelluksen toteutetut ominaisuudet................... 11 3.4 Tulokset................................... 12 3.5 Oppimistavoitteet.............................. 13 4 Projektin resurssit 16 4.1 Projektiorganisaatio............................. 16 4.2 Projektin tilat ja laitteet........................... 17 4.3 Ohjelmointi- ja dokumentointityökalut.................. 17 4.4 Luennot ja perehdytykset......................... 18 5 Käytänteet 20 5.1 Palaverit................................... 20 5.2 Tiedotus................................... 21 5.3 Tiedostojen nimeäminen ja hakemistorakenne............. 22 5.4 Lähdekoodi................................. 23 5.5 Testaus.................................... 25 5.6 Versiohallinta ja -numerointi........................ 26 5.7 Katselmoinnit ja tulosten hyväksyminen................. 26 5.8 Tulosten koostaminen ja julkaisu..................... 27 6 Projektin tehtävät ja niiden jakautuminen 28 6.1 Projektipäällikkö ja varapäällikkö..................... 28 6.2 Vastuualueet tulosten osalta........................ 29 6.3 Tehtävät ja työmäärät............................ 29 6.4 Ryhmän työtunnit tehtäväkokonaisuuksittain.............. 32 6.4.1 Kari Alirannan työtunnit tehtäväkokonaisuuksittain..... 32 6.4.2 Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain. 32 v
6.4.3 Janne Pesosen työtunnit tehtäväkokonaisuuksittain...... 32 6.4.4 Atte Raution työtunnit tehtäväkokonaisuuksittain....... 32 7 Prosessimalli ja aikataulu 34 7.1 Prosessimalli................................. 34 7.2 Aikataulu................................... 35 7.3 Ryhmän työtunnit viikottain........................ 38 7.3.1 Kari Alirannan työtunnit viikottain............... 39 7.3.2 Jaakko Leppäkankaan työtunnit viikottain........... 40 7.3.3 Janne Pesosen työtunnit viikottain................ 41 7.3.4 Atte Raution työtunnit viikottain................. 42 8 Riskien hallinta 44 8.1 Riskien todennäköisyydet ja haitat.................... 44 8.2 Projektiorganisaatioon ja sidosryhmiin kuuluvien toiminnan viiveet 44 8.3 Projektin aiheen haastavuus........................ 46 8.4 Vaikeudet valmiiden ohjelmakomponenttien käytössä......... 46 8.5 Puutteet projektiryhmän tietotaidoissa.................. 47 8.6 Toteutettavien ominaisuuksien tarkentaminen ja rajaus........ 48 8.7 Jäsenten odottamattomat poissaolot................... 49 8.8 Projektin hallinnan puutteet........................ 49 9 Jäsenten kokemuksia 51 9.1 Mitä olisi pitänyt tehdä toisin?...................... 51 9.2 Kari Alirannan kokemuksia........................ 51 9.3 Jaakko Leppäkankaan kokemuksia.................... 51 9.4 Janne Pesosen kokemuksia......................... 51 9.5 Atte Raution kokemuksia......................... 51 10 Yhteenveto 52 11 Lähteet 53 vi
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 [1]. Keskuksen tiloihin on tulevaisuudessa tarkoitus hankkia MEG-mittauslaitteisto. Mittauslaitteiston 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. Sovelluksen tavoitteena on saada kaikki MEGmittausdatan analysointiin liittyvät toiminnot saman käyttöliittymän alle niin, ettei käyttäjän tarvitse käyttää komentorivikomentoja missään vaiheessa. Kehitettävä sovellus suorittaa kaikki tarvittavat komentorivikutsut käyttäjän puolesta, kunhan käyttäjä syöttää tarvittavat 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 määrittelee myös sovellukselle asetetut tavoitteet sekä vaaditut ja toteutetut tulokset yleisellä tasolla. Projektiraportissa esitellään kaikki projektiorganisaatioon kuuluvat henkilöt ja muut projektiin keskeisesti liittyvät resurssit. Lisäksi käsitellään projektissa sovellettuja 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. Luvussa 2 kuvataan projektisuunnitelmassa esiintyviä termejä. Luvussa 3 esitellään projektin taustaa, tavoitteet ja tulokset. Samalla esitellään projektissa valmistunutta prototyyppiä. Luvussa 4 esitellään projektiorganisaatio sekä projektille varatut 1(54)
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ömäärät tehtävittäin. Luvussa 7 esitellään projektin aikana noudatettua prosessimallia ja projektin aikataulua. Luvussa 8 käsitellään projektiin liittyviä riskejä, niiden hallintaa ja niiden toteutumista. Luvussa 9 ryhmän jäsenet kuvaavat omista kokemuksiaan ja oppimistaan sekä arvioidaan lyhyesti, mitä projektissa olisi kannattanut tehdä toisin. 2(54)
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. (epoch) on MEG-mittausdatasta jonkin ulkopuolisen ärsykkeen kohdalta rajattu ajanhetki, 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(54)
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ä [8]. 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 [8]. 2.2 Kehitysvälineisiin ja -tekniikoihin liittyviä termejä Dokumentissa esiintyy seuraavia kehitysvälineisiin ja -tekniikoihin liittyviä termejä: Eclipse EPD Ketterä ohjelmakehitys on sovelluskehitysympäristö, joka on tarkoitettu Javasovellusten 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 [3]. sisältää useita ohjelmistokehitysprojektin läpiviennissä käytettäviä menetelmiä, jotka tunnustavat Agile Manifestossa [5] esiteltyjä arvoja. Ketterän ohjelmistokehityksen perusperiaatteisiin kuuluu toimivan ohjelmiston priorisointi, nopea muutoksiin reagointi sekä joustava viestintä kehittäjän ja asiakkaan välillä. 4(54)
MaxFilter MNE PyDoc Python YouSource on Elekta Oy:n julkaisema ohjelmisto MEG-datan analyysiin [8]. on MEG-datan ja EEG-datan käsittelyyn tarkoitettu avoimen lähdekoodin ohjelmistopaketti [7]. on työkalu Pythonilla kirjoitettujen ohjelmien luokkadokumentaation generointiin. on avoimen lähdekoodin lisenssin alainen olio-ohjelmointikieli [6]. on Verso-projektissa kehitetty lähdekoodien julkistusjärjestelmä, jota käytetään projektissa laaditun lähdekoodin versiohallintaan ja julkistamiseen. [9] 5(54)
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 datan esikäsittelyvaiheen toteutukseen, joten analyysivaiheita ehdittiin toteuttaa suunniteltua vähemmän. Lisäksi sovelluksen käyttämistä helpottavien ja nopeuttavien lokitietojen keräys ja käyttö jäivät projektin ulkopuolelle. Järjestelmätestaus jäi projektiryhmän osalta varsin vähäiseksi, koska ryhmä ei saanut käyttöönsä kaikkia sovelluksen hyödyntämiä ohjelmia. 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 [2]. 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 esimerkiksi aivojen ulkopuolinen kohina, sydän- ja silmäartefaktat sekä pään liikkumisesta aiheutuvat häiriöt. 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äsittele- 6(54)
Kuva 3.1: MEG-mittauslaite. mä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(54)
Kuva 3.2: Esikäsittelemätöntä raakadataa. 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 komentorivikomennoilla 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 tulee yhdistää MNEohjelmisto ja MaxFilter-ohjelmisto yhden käyttöliittymän alle. Sovelluksen käyttäjät 8(54)
Kuva 3.3: Keskiarvoistettu epookki. 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 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(54)
Sovelluksen tulee toimia 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 se on myös parhaiten ylläpidetty MNE:n liitännäinen. 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. Käyttöliittymä Näkymiä Toiminnallisuus Hallintaluokat Tiedostohallinta Lisäominaisuudet Kutsuttavat ohjelmistot Kutsuttavat ohjelmistot MNE Maxfilter Kuva 3.4: Sovelluksen kokonaisrakenne. Hoksotin-projektin päätavoite oli toimittaa tilaajalle sovelluksen prototyyppi, jossa on huomioitu esitettyjen vaatimusten [12] ohella sovelluksen laajennettavuus. Projektin aikataulu oli rajallinen, joten sovellusta joudutaan pakostakin jatkokehittämään projektin päättymisen jälkeen. Jatkokehitys pyrittiin ottamaan huomioon so- 10(54)
velluksen toteutusratkaisuissa ja dokumentoinnissa. Käytännössä tämä tarkoitti sitä, että vaikka kaikkia vaatimuksia ei ehdittäisikään toteuttaa, päätettiin ne ottaa kuitenkin projektin aikana huomioon ja toteutetaan lähdekoodiin alustavat aliohjelmarungot. Lisäksi toteuttamatta jääneet vaatimukset kirjattiin ylös vaatimusmäärittelystä, jotta jatkokehityksen aloittaminen olisi mahdollisimman helppoa. 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äys ja osa kuvaajiin liittyvistä toiminnoista jäi toteuttamatta ja ne sovittiin tilaajan kanssa jatkokehitykseen. Sovellus toimitettiin tilaajalle toukokuun loppuun mennessä. Projektiryhmä piti tilaajan ajantasalla projektin etenemisestä, jotta tilaajan oli helpompi osoittaa ne sovellukselle asetetut vaatimukset, joiden kehittäminen oli ensisijaista. Lisäksi tilaajan aktiivisella osallistumisella saatiin sovelluksen kehitys pidettyä varmemmin toivotussa suunnassa. 3.3 Sovelluksen toteutetut ominaisuudet Käyttäjä pystyy luomaan koekohtaisia hakemistoja datan käsittelyä varten. Sovellus huolehtii siitä, että prosessin aikana tallennettavat tiedostot tallennetaan oikeannimisinä oikeisiin paikkoihin. Uutta koetta luodessa sovellus tekee kokeelle hakemistorakenteen valmiiksi ja kopioi käytettävän raakadatatiedoston koekansioon. Sovellus ohjaa käyttäjää avaamalla uusia valintoja sen perusteella, mitä datalle ollaan tehty. Datan esikäsittelyyn liittyvät ominaisuudet saatiin toteutettua. Tämä tarkoittaa sitä, että datasta pystytään poistamaan ylimääräiset esimerkiksi silmien ja sydämen toiminnasta aiheutuvat häiriöt. Lisäksi data voidaan jakaa epookkeihin kokeessa käytettyjen ärsykkeiden pohjalta tehdyn tapahtumalistan avulla. Epookkeja voidaan keskiarvoistaa ja käyttäjä pystyy halutessaan näkemään keskiarvoistettuen epookkien kuvaajat. Epookeille pystytään myös tekemään TFR-analyysiä (time-frequency representation). TFR-kuvat pystytään sijoittamaan päätä kuvaavaan topografiaan, josta näkee jokaisen sensorin mittaaman signaalin, sekä sensorin sijainnin koehenkilön pään 11(54)
ympärillä. Esimerkki topografiasta on kuvassa 3.5. Topografiassa koehenkilön kasvot ovat kuvan yläreunassa ja takaraivo kuvan alareunassa. Kuva 3.5: Pään topografia Sovellusta varten kehitettiin myös joitakin toimintoja liittyen tilastotietojen etsimiseen kuvaajista. Näitä ei kuitenkaan ehditty liittää sovellukseen. 3.4 Tulokset Sovelluksen ohella projektiryhmä toteutti seuraavat tulokset: - Ajankäyttöraportti sisältää ryhmän jäsenten kirjaamat työtunnit sekä niiden jakautumisen eri tehtäville ja tehtäväkokonaisuuksille. - 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ä. 12(54)
- Käyttöohje neuvoo sovelluksen käytön. - Luokkadokumentaatio sisältää kuvaa toteutettujen ohjelmaluokkien tarkoituksen ja toiminnan - 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 ja vertaa toteumaa suunnitelmaan sekä arvioi erojen syitä ja vaikutuksia. - Projektisuunnitelma on projektin läpiviennin suunnitelma. - Sovellusraportti kuvaa projektissa toteutetun sovelluksen kokonaisrakenteen yleiset toteutusratkaisut ja toiminnot sekä mahdolliset puutteet ja jatkokehitysideat. - Sähköpostiarkistot sisältävät kaikki projektiorganisaation sähköpostilistoille lähetetyt viestit. - Vaatimusmäärittely kuvaa sovelluksen tavoitteet, tekniset ja toiminnalliset vaatimukset sekä rajoitteet. 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. 3.5 Oppimistavoitteet Sovellusprojekti-opintojakson päätavoitteena on tarjota opiskelijoille käytännön kokemusta projektimuotoisesta työskentelystä. Jokainen projektiryhmän jäsen saa kokemusta useilta ohjelmistokehityksen osa-alueilta, sillä pieni ryhmäkoko pakottaa jakamaan useita tehtäviä samoille henkilöille. Kaikki ryhmän jäsenet oppivat monipuolisesti taitoja ohjelmiston määrittelyyn, suunnitteluun, toteutukseen ja testaukseen liittyen, minkä lisäksi tiiviissä ryhmässä kaikki oppivat väistämättä ryhmätyötaitoja. Erityisesti projektipäällikkö oppii projektityöskentelyn suunnittelussa ja hallinnassa vaadittuja johtamistaitoja ja ajankäytön hallintaa. Projektin aikana järjestettävät palaverit ovat olennainen osa sovellusprojektia ja sitä kautta myös oppimisprosessia. Palavereissa ryhmän jäsenet oppivat noudatta- 13(54)
maan 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 saa kokemusta myös kyseisistä tehtävistä. Sovellusprojektikurssin yhteyteen on liitetty opiskelijoiden puhe- ja kirjoitusviestintätaitoja kehittävä Projektiviestintä IT-alalla -kurssi, johon kuuluu erilaisia kirjoitusja esiintymisharjoituksia. Myös kaikista sovellusprojektin aikana laadittavista dokumenteista saatava palaute tukee viestintätaitojen oppimista. Projektiin liittyy myös oheiskurssi Sovellusprojektin hallintaa, viestintää ja työkaluja. Tämän kurssin aikana opitaan projektityöskentelyn edellyttämiä tietotaitoja, ryhmätyöskentelyä ja suunnitelmallisuutta. Kurssin aikana opitaan myös käytettävyyteen liittyviä asioita. Koska projektiryhmän jäsenillä on korkeintaan hyvin vähän aiempaa kokemusta projektityöskentelystä, tulee vastaan pakostakin odottamattomia tilanteita. Aiempien projektiryhmien projektikansioiden läpikäynti on korvaamaton työkalu hyvien ja vältettävien käytänteiden opettelemiseen. Varsinkin laajempien dokumenttien kirjoituksessa oli projektikansioista erittäin suurta hyötyä. Projektiryhmä oppii sosiaalisia taitoja neuvotellessaan asiakkaan kanssa sovelluksen toiminnallisuuksista ja pyrkiessään kaikkia osapuolia miellyttäviin ratkaisuihin. Myöskään ryhmän sisäisessä työskentelyssä vaadittujen viestintätaitojen vaikutusta ei voida jättää huomiotta. Kellään Hoksotin-ryhmän jäsenistä ei juuri ollut aiempaa kokemusta Pythonista, joten kaikkien ryhmän jäsenten ohjelmointitaidot kehittyivät projektin aikana 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 edellyttää kaikilta ryhmän jäseniltä tiivistä yhteistyötä, sillä projektin läpivienti riippuu kaikkien jäsenten panoksesta. Ryhmässä työskenteleminen vaatii jäsenten väliltä luottamusta ja kykyä ottaa vastuuta. Projektityöskentelyssä korostuvat myös aloitekyky ja omatoimisuus, mutta toisaalta jokaisen tulee samalla pystyä pitämään muut ryhmän jäsenet ajan tasalla siitä, mitä kulloinkin tekee. Ryhmän jäsenet kysyivät toisiltaan aktiivisesti tehtävien tilasta ja ongelmista, joten kaikki pysyivät hyvin mukana projektin loppuun asti. 14(54)
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, jos 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. Oppimistavoitteiden toteutumista arvioidaan tarkemmin jokaisen jäsenen osalta luvussa 9. 15(54)
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ä. 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ä 2013. Hän aikoo saada pro gradu - tutkielman valmiiksi keväällä 2015. 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äoiviennistä ja projektien yleisistä käytänteistä. 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. 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ä. 16(54)
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 C226.2. 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 on 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ä käytettiin kuitenkin niiden käyttöönoton jälkeen ja varsinkin WWW-levy osoittautui erittäin hyödylliseksi työkaluksi. 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 muodostettiin lähdekoodeista PyDocilla. 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 in käytöstä mutta hän oli käyttänyt Libre Officea paljon enemmän ja todettiin, ettei projektin loppuvaiheessa kannata uutta ohjelmistoa enää opetella, kunhan sovellusraportin saa kirjoitettua helppolukuiseksi PDFtiedostoksi. Toteutettavan sovelluksen vaatimusten suunnittelu ja määrittely teh- 17(54)
tiin 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 [13]. 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: - 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äli-esittelyt (Stoor-Lehtonen ja Santanen). Näiden lisäksi järjestettiin tarvittaessa ylimääräisiä perehdytyksiä. 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ä 18(54)
siinä vaiheessa ollut parempi keskittyä siihen, mitä sovelluksella halutaan missäkin vaiheessa pystyä tekemään kiinnittämättä kuitenkaan liikaa huomiota itse toteutukseen. 19(54)
5 Käytänteet Luvussa kuvataan projektissa noudatettuja käytänteitä. Niiden tarkoitus oli yhtenäistää 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. Raportointia ei kuitenkaan ollut niin paljoa, kun oli suunniteltu, koska ryhmän jäsenet olivat muutenkin aktiivisesti yhteydessä ohjaajiin ja tilaajan edustajaan. Testausta ei toteutettu lähellekään siinä mittakaavassa, kun oli suunniteltu, 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 voi toimia 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. Ensimmäisissä palavereissa sovittiin lisäksi projektin läpivientiin liittyvistä käytänteistä, kuten mahdollisista sopimuksista sekä dokumenteista ja niiden kielestä. Palavereissa käytiin myös läpi edellisessä palaverissa sovitut toimenpiteet sekä sovittiin tulevista toimenpiteistä. 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(54)
tettiin palavereissa. Varsinaista sovelluksen toimintaa esiteltiin palaverien jälkeen ryhmän työtilassa, koska sovellus ei toimi Windowsissa. 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, tosin niihin esitettiin ensin joitain muokkauksia. Ryhmä sai parissa palaverissa palautetta huonosta valmistautumisesta mutta muuten 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 voivat puuttua mahdollisiin virheisiin mahdollisimman nopeasti ajan säästymiseksi. Käytännössä projektipäällikkö ei kyseisiä viikottaisia tilakatsauksia ei kuitenkaan 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 ryhmän jäsenet työskentelivät suurimmaksi osaksi samassa tilassa. Jos suullinen tiedotus ei ollut mahdollista, hoidettiin yhteydenpito sähköpostitse. Periaatteena oli, 21(54)
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 hoksotin@korppi.jyu.fi, ja sen jakelulistalle kuuluivat kaikki projektiorganisaation edustajat. Kaikki listalle lähetetyt viestit tallennettiin sähköpostiarkistoon, joka on nähtävillä osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/hoksotin/. Projektiryhmän jäsenten ja ohjaajien käytössä oli myös toinen sähköpostilista hoksotin_opetus@korppi.jyu.fi. Sen sähköpostiarkisto sijaitsee osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/ 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ä. Nimeämisessä käytettiin ainoastaan pieniä kirjaimia, ja välilyönnit korvattiin alaviivalla. Dokumenttitiedostot nimettiin kirjaamalla järjestyksessä projektin nimi, dokumentin nimi ja dokumentin versionumero, esimerkiksi HoksotinProjektisuunnitelma0.3.0.pdf. Versionumerointia kuvataan tarkemmin luvussa 5.6. Projektin tulokset tallennettiin CD-levylle ja projektin WWW-hakemistoon seuraavan hakemistorakenteen mukaisesti: ajankaytto application_report class_documentation esittelyt 22(54)
itsearvioinnit palaverit esityslistat poytakirjat tilakatsaukset ohjeet projektiraportti projektisuunnitelma requirements_specification sahkopostiarkistot hoksotin hoksotin_opetus sitoumus_ja_lisenssit source_code testaus testausraportit testaussuunnitelma 5.4 Lähdekoodi Lähdekoodi kirjoitettiin vastaamaan yleisiä Pythonin käytänteitä [10] ja PyDocin mukaisia käytänteitä [11]. 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 """ Created on Mar 6, 2013 @author: Jaakko Leppäkangas """ import mne import datetime import re class MeasurementInfo(object): 23(54)
""" 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. ) @property 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. ) else: return self._info.get( highpass ) Lähdekoodi kirjoitettiin suunniteltuja käytänteitä noudattaen. 24(54)
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ä. Käytännössä sellaista koodia, jossa yksikkötestausta tarvittiin kirjoitettiin kuitenkin todella vähän. Kyseiset yksikkötestit koodiin kirjoitti poikkeuksellisesti Atte Rautio, vaikka itse koodi olikin toisen jäsenen kirjoittamaa. Ryhmän jäsenet toki testasivat kirjoittamaansa koodia kirjoituksen aikana. He kirjoittivat koodin sekaan testirivejä, joilla he saattoivat esimerkiksi varmistaa, että heidän kirjoittamansa koodin tulostus oli sitä, mitä haluttiin. Lisäksi ohjelma ajettiin alusta loppuun kirjoituksen aikana, jotta varmistuttaisiin, että sovelluksen kokonaistakenne pysyi kasassa. Näitä testeja ei kuitenkaan jätetty mihinkään näkyviin vaan ne poistettiin koodin joukosta heti, kun tiedettiin koodin toimivan. Järjestelmätestauksesta vastuussa olevan henkilön oli tarkoitus laatia testauksen suorittamiseksi testaussuunnitelman. Testaussuunnitelma 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 kaksi kertaa projektin aikana. Koska varsinainen toteutus saatiin kuitenkin aloitettua vasta maaliskuun lopulla, päätettiin testaukseen varattuja työtunteja siirtää toteutukseen ja suunnitteluun. Tämän vuoksi varsinkin järjestelmätestaus jäi paljon suunniteltua suppeammaksi. Sovelluksen käytettävyyteen kiinnitettiin huomiota kaikkien kehitysvaiheiden aikana ja käytettävyydestä saatiin myös paljon palautetta sekä käytettävyysasiantuntija Meeri Mäntylältä, että tilaajan edustajilta ja projektin ohjaajilta. Varsinaista käytettävyystestausta ei kuitenkaan projektissa suoritettu, mutta mahdolliset kriittiset puutteet ja epäloogisuudet päätettiin kirjata ylös viimeistään esiteltäessä sovellusta tilaajalle ja ohjaajille. 25(54)
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 ja sovelluksen lähdekoodien 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 0.0.2. Projektiorganisaatiolle julkistettavien versioiden numerointi aloitettiin versionumerosta 0.1.0. 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 1.1.0. Versiohallinnan käyttö sekä dokumenttien nimeäminen ja numerointi toteutui suunnitellusti. 5.7 Katselmoinnit ja tulosten hyväksyminen Projektiryhmän kirjoittama lähdekoodi päätettiin katselmoida vähintään kaksi kertaa. Katselmoinnissa tekninen ohjaaja kommentoi lähdekoodia antaen vinkkejä ja parannusehdotuksia. Tekninen ohjaaja myös hyväksyi lähdekoodin. Katselmointiin osallistui teknisen ohjaajan lisäksi koko projektiryhmä sekä vastaava ohjaaja, ja katselmoinnin havainnot kirjattiin muistioksi. Projektin lopussa tulokset kokonaisuutena hyväksytettiin projektin ohjaajilla sekä tilaajan edustajalla. Yksittäisistä tuloksista tilaajan edustajan hyväksyntä tarvittiin vähintään toteutetulle sovellukselle, käyttöohjeelle ja sovellusraportille. 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 ja sovellusraportti. Lähdekoodin katselmointi ja tulosten hyväksyminen toteutuivat suunnitellusti. 26(54)
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 toimitetaan laitoksen arkistoon. Projektikansio sijoitetaan projektitilan kokoushuoneessa olevaan kirjahyllyyn. 27(54)
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ömäärät 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 varsinkin tehtävien määrittelyt eivät täysin vastanneet lopullista tulosta. Kuitenkin kun katsotaan tehtäväkokonaisuuksia sovelluksen suunnittelu ja toteutus, huomataan niiden vieneen työtunteja hieman yli kolmasosan koko projektin työmäärästä, mikä vastaa normaalia ohjelmistokehitysprojektin työmäärän jakautumista. LISÄÄ KUVAUSTA HETI KUN TYÖTUNTEJA ON ARVIOITU TARKEMMIN 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, tiedotus sekä ryhmän sisäisten tehtävien jakaminen jäsenille. Projektipäällikkö oli vastuussa myös projektisuunnitelman ja - raportin laatimisesta. 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 poissa palaverista. Varapäällikön olisi 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ä, joten se olisi ollut verkossa nähtävillä. Tämä ei kuitenkaan haitannut projektin läpivientiä, vaan tilakatsaus lähetetettiin myöhemmin samana päivänänä sähköpostitse. 28(54)
6.2 Vastuualueet tulosten osalta Keskeisimpien tulosten vastuuhenkilöt on esitetty taulukossa 6.1. Taulukossa on esitettynä toteutettavaksi suunnitellut tulokse, niiden vastuuhenkilöt, ja tulosten hyväksymispäivämäärä. 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 25.4.2013 Vaatimusmäärittely Janne Pesonen? Sovelluksen kokonaisrakenne Jaakko Leppäkangas? Sovellusraportti Kari Aliranta? Lähdekoodin viimeistely Jaakko Leppäkangas? Järjestelmätestaus Kari Aliranta? Projektiraportti Atte Rautio? Taulukko 6.1: Vastuualueet keskeisimpien tulosten osalta. 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 nopeuttivat ryhmän työskentelyä varsinkin projektin alkuvaiheessa. Lisäksi Aliranta vastasi pääosin erilaisten muistioiden kirjoittamisesta. Vastuualueiden jakautuminen toteutui suunnitellusti lukuunottamatta järjestelmätestausta, jota ei projektissa pystytty projektiryhmän toimesta tekemään. Ryhmällä ei ollut käytössään MaxFilter-ohjelmistoa, jota sovellus hyödyntää datan esikäsittelyssä, joten perusteellinen testaus oli mahdotonta. Lähdekoodin viimeistelyyn osallistui koko projektiryhmä eikä se ollut kenenkään yksittäisellä vastuulla. 6.3 Tehtävät ja työmäärät Projektiryhmän jäsenet olivat sitoutuneet työskentelemään projektin ja siihen liittyvän oheiskurssin eteen noin 25 tuntia viikossa. Työmäärätavoitteeseen 350 tuntia 29(54)
kutakin jäsentä kohden oli tavoitteena päästä toukokuun loppuun mennessä. Jaakko Leppäkankaalla suunnitellut tunnit tulivat täyteen jo toukokuun puolivälissä, mutta hän teki siitä huolimatta itsepintaisesti töitä projektin loppuun asti. Kari Alirannalla oli aika paljon muita kursseja projektin alkuvaiheessa, mutta hän oli sitoutunut panostamaan projektiin enemmän työtunteja projektin loppuvaiheessa. Tämän takia sovellusraportti siirrettiin hänen vastuulleen vaikka aluksi sovittiin, että sen kirjoittaa Jaakko Leppäkangas. Projektiryhmän jäsenten sovellusprojektiin ja siihen liittyviin oheiskursseihin käyttämät työtunnit on arvioitu taulukossa 6.2 tehtäväkokonaisuuksittain ja tehtävittäin. Sarakkeessa S on tehtävän suunnitellut ja sarakkeessa T tehtävän toteutuneet työtunnit. 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 joillekin tehtäville arvioidut työmäärät ylittyivät. Lisäksi joitain tehtäviä, kuten esimerkiksi rajapintojen suunnittelua ja toteutusta ei edes tehty, koska osoittautui että niille ei ollutkaan tarvetta. Joidenkin tehtävien tuntiarvioiden ylittymisen vuoksi jouduttiin osa tehtävistä sopimaan tilaajan kanssa jatkokehitykseen. Työtuntien kirjaamisessa oli myös hankalaa se, että välillä 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. 30(54)
KA JL JP AR Kaikki Tehtäväkokonaisuus Tehtävä S t S t S t S t S t Projektin hallinta Toiminnan suunnittelu 0? 2? 0? 30? 32? Projektisuunnitelma 2? 2? 2? 48? 54? Seuranta 0? 5? 0? 12? 17? Tiedotus 2? 4? 2? 10? 18? Sopimukset 0? 0? 0? 8? 8? Asennukset 4? 2? 2? 6? 14? Projektiraportti 0? 0? 0? 35? 35? Tulosten viimeistely 4? 4? 4? 4? 16? Tulosten luovutus 4? 4? 4? 4? 16? Yhteensä 16? 23? 14? 157? 210? Palaverit Valmistelu 5? 5? 5? 14? 29? Palaverit 20? 20? 20? 20? 80? Pöytäkirjat 17? 17? 17? 17? 68? Yhteensä 42? 42? 42? 51? 177? Esitutkimus Aihealueeseen tutustuminen 25? 15? 10? 7? 57? Koulutus 4? 4? 4? 4? 16? Työkaluihin tutustuminen 10? 13? 10? 8? 41? Yhteensä 39? 32? 24? 19? 114? Vaatimusmäärittely Suunnittelu 0? 0? 25? 0? 25? Raportointi 0? 0? 55? 0? 55? Yhteensä 0? 0? 80? 0? 80? Suunnittelu Käyttöliittymä 3? 2? 0? 1? 6? Sovelluksen rakenne 2? 15? 2? 4? 23? Asetusten tallennus 3? 3? 3? 3? 12? Raportointi 3? 3? 3? 3? 12? Visualisointi 2? 2? 2? 2? 8? Esikäsittelynäkymä 5? 2? 2? 2? 11? Keskiarvoistusnäkymä 3? 2? 2? 2? 9? Visualisointinäkymä 4? 2? 2? 2? 10? Tiedostohallinta 5? 5? 5? 5? 20? Lokitiedot 3? 1? 1? 1? 6? TFR-näkymä 3? 2? 2? 2? 9? Lähdetasonäkymä 3? 1? 1? 1? 6? Rajapinnat 2? 2? 7? 2? 13? Yhteensä 41? 42? 32? 30? 145? Toteutus Sovelluksen rakenne 1? 18? 5? 4? 28? Käyttöliittymä 10? 14? 9? 3? 36? Asetusten tallennus 4? 25? 4? 2? 35? Visualisointi 3? 2? 10? 1? 16? Esikäsittelynäkymä 5? 15? 5? 1? 26? Raportointi 6? 6? 11? 2? 25? Keskiarvoistusnäkymä 10? 14? 7? 1? 32? Tiedostohallinta 4? 15? 4? 1? 24? Lokitiedot 5? 20? 10? 1? 36? Rajapinnat 1? 1? 7? 2? 11? TFR-näkymä 10? 1? 1? 3? 15? Lähdetasonäkymä 10? 2? 2? 1? 15? Visualisointinäkymä 7? 1? 1? 1? 10? Yhteensä 76? 134? 76? 23? 309? Järjestelmätestaus Suunnittelu 6? 0? 0? 0? 6? Testauskerrat 8? 0? 8? 0? 16? Raportointi 4? 0? 4? 0? 8? Yhteensä 18? 0? 12? 0? 30? Viimeistely Sovellusraportti 45? 0? 0? 0? 45? Lähdekoodin katselmointi 4? 4? 4? 4? 16? Lähdekoodin viimeistely 3? 10? 3? 3? 19? Sovelluksen luovutus 1? 1? 1? 1? 4? Yhteensä 53? 15? 8? 8? 84? Projektin tunnit yhteensä 285? 288? 288? 288? 1149? Oheiskurssi Kirjoitusviestintä 20? 20? 20? 20? 80? Puheviestintä 25? 22? 22? 22? 91? Projektiluennot 20? 20? 20? 20? 80? Yhteensä 65? 62? 62? 62? 251? Projektin ja oheiskurssien tunnit yhteensä 350? 350? 350? 350? 1400? Taulukko 6.2: Tehtävien suunnitellut ja toteutuneet työtunnit.
6.4 Ryhmän työtunnit tehtäväkokonaisuuksittain Ryhmän työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.1. 6.4.1 Kari Alirannan työtunnit tehtäväkokonaisuuksittain 6.4.2 Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain 6.4.3 Janne Pesosen työtunnit tehtäväkokonaisuuksittain 6.4.4 Atte Raution työtunnit tehtäväkokonaisuuksittain 32(54)
Viimeistely; 46:28; 3% Ajankäyttö vaiheittain Visualisointi; 1:45; 0% Esitutkimus; 153:36; 12% Määrittely; 57:00; 4% Toteutus; 505:09; 38% Oheiskurssi; 177:10; 13% Palaverit; 134:48; 10% Testaus; 6:30; 0% Suunnittelu; 99:17; 7% Projektin hallinta; 149:20; 11% Kuva 6.1: Projektiryhmän työtunnit tehtäväkokonaisuuksittain. 33(54)
Ajankäyttö vaiheittain Viimeistely; 25:15; 8% Esitutkimus; 36:25; 12% Oheiskurssi; 49:15; 16% Toteutus; 122:45; 39% Palaverit; 36:20; 12% Suunnittelu; 30:20; 10% Projektin hallinta; 7:25; 2% Testaus; 6:30; 2% Kuva 6.2: Kari Alirannan työtunnit tehtäväkokonaisuuksittain. 34(54)
Ajankäyttö vaiheittain Viimeistely; 12:35; 3% Esitutkimus; 42:45; 12% Oheiskurssi; 40:00; 11% Toteutus; 209:15; 57% Palaverit; 30:05; 8% Suunnittelu; 32:15; 9% Projektin hallinta; 2:00; 1% Kuva 6.3: Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain. 35(54)
Ajankäyttö vaiheittain Viimeistely; 2:00; 1% Esitutkimus; 38:00; 12% Toteutus; 146:50; 45% Määrittely; 57:00; 17% Oheiskurssi; 43:40; 13% Suunnittelu; 6:45; 2% Palaverit; 26:10; 8% Projektin hallinta; 8:45; 3% Kuva 6.4: Janne Pesosen työtunnit tehtäväkokonaisuuksittain. 36(54)
Ajankäyttö vaiheittain Viimeistely; 6:38; 2% Visualisointi; 1:45; 1% Toteutus; 26:19; 8% Esitutkimus; 36:26; 11% Suunnittelu; 29:57; 9% Oheiskurssi; 44:15; 14% Projektin hallinta; 131:10; 41% Palaverit; 42:13; 13% Kuva 6.5: Atte Raution työtunnit tehtäväkokonaisuuksittain. 37(54)
7 Prosessimalli ja aikataulu Luvussa käsitellään projektissa noudatettua prosessimallia ja suunniteltua aikataulua sekä verrataan suunnitelmaa toteutumaan. Prosessimalli muuttui hieman suunnitellusta, koska suurin osa sovelluksen toteutuksesta kului esikäsittelyvaiheen toteutukseen ja itse analysointi ja visualisointivaiheet jäivät pienemmälle huomiolle. Tämä näkyy myös aikataulun venymisessä. Projektille varattu kahden viikon pelivara jouduttiin käyttämään hyväksi. Prosessimalli ei toteutunut aivan siinä määrin, kun oli suunniteltu. Tiedotus oli vähäisempää varsinkin viikottaisten tilakatsausten osalta, koska projektiryhmä tapasi tilaajaa tai teknistä ohjaajaa lähes viikottain. Koska toteutuksen aloituksessa oli jonkin verran ongelmia ja suurin osa toteutuksesta kului datan esikäsittelyvaiheeseen, ei vaiheiden vaihtuminen pahemmin näkynyt toteutuksen aikana. 7.1 Prosessimalli Projektissa ei varsinaisesti noudatettu mitään tiettyä prosessimallia. Projekti suunniteltiin läpivietäväksi ketterällä räätälöidyllä prosessimallilla, 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. Vaiheet kestivät kahdesta kolmeen viikkoa. Aihealueen vaativuuden vuoksi esikäsittelyä jouduttiin toteuttamaan monessa kehitysvaiheessa, jolloin muille vaiheille jäi vähemmän aikaa. Projektin kahdessa ensimmäisessä vaiheessa keskityttiin aihealueeseen ja työkaluihin tutustumiseen sekä projektin läpiviennin ja sovelluksen kokonaisrakenteen suunnitteluun. Varsinainen ohjelmistokehitys tapahtui vaiheissa kolme, neljä ja viisi. Viimeinen vaihe varattiin projektin viimeistelylle ja tulosten toimittamiselle. Vaiheiden vaihtuminen ei toteutuksen aikana juurikaan näkynyt, vaan suurin osa toteutukselle varatusta ajasta meni esikäsittelyvaiheen toteutukseen. Käytettävää prosessimallia olisikin pitänyt miettiä projektin alussa hieman tarkemmin. Toisaalta koska projektin aihealue ja tavoitteet olivat silloin vielä melko epäselvät, oli prosessinmallin suunnittelu hankalaa. 38(54)
7.2 Aikataulu Ennen varsinaisen projektin alkua sovellusprojektikurssilla oli projektiviestinnän luentoja sekä projektien aloitusluento. Projektin ensimmäinen tapaaminen tilaajan kanssa oli 5.2.2013, jolloin projekti katsotaan alkaneeksi. Ensimmäisen kolmen viikon aikana tutustumisvaiheessa 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 parin viikon aikana suunnitteluvaiheessa tutustuttiin työkaluihin tarkemmin ja alettiin hahmotella sovelluksen kokonaisrakennetta. Varsinainen ohjelmistokehitys suunniteltiin tapahtuvaksi maaliskuun alun ja huhtikuun lopun välisenä aikana kolmessa kehitysvaiheessa. Toukokuun loppuun varattu pelivara päätettiin käyttää hyväksi ja kehitystä jatkettiin vielä toukokuun pari ensimmäistä viikkoa. Maaliskuussa laadittiin Projektisuunnitelma sekä alustava Vaatimusmäärittely. Toukokuu varattiin tulosten viimeistelylle. Sovellus- ja projektiraportti oli tarkoitus saada valmiiksi toukokuun puoleen väliin mennessä. Toukokuun alku meni kuitenkin vielä toteutuksessa, joten nämä raportit saatiin aloitettua vasta hieman ennen toukokuun puolta väliä. Projektin tehtäväkokonaisuuksien ja tehtävien suunnitellut aikajänteet esitellään kuvassa 7.1. Suunnitelmaan on jätetty noin kahden viikon pelivara toukokuun loppuun mahdollisia viivästyksiä varten. Tämä pelivara myös käytettiin. Projektin tehtäväkokonaisuuksien toteutuneet aikajänteet esitellään kuvassa 7.2. 39(54)
Kuva 7.1: Projektin suunniteltu aikataulu.
Kuva 7.2: Projektin toteutunut aikataulu.