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.3.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. 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äkokonaisuuksen toteutumista suurin osa on lisätty ja toteumiin on lisätty analyysia. 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 Prosessimalli ja aikataulu Prosessi Aikataulu Ryhmän työtunnit viikoittain Kari Alirannan työtunnit viikoittain Jaakko Leppäkankaan työtunnit viikottain Janne Pesosen työtunnit viikottain Atte Raution työtunnit viikottain 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 Jaakko Leppäkankaan kokemuksia Janne Pesosen kokemuksia Atte Raution kokemuksia 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. 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. Tilaajan 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. Kehitetty sovellus suorittaa kaikki 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 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. Projektissa laadittiin muitakin projektin ja sovelluksen kannalta olennaisia dokumentteja. Vaatimusmäärittely kuvaa sovelluksen toiminnalliset ja tekniset vaatimukset prioriteetteineen sekä kuvaa jokaisen vaatimuksen toteutuksen tilan. Sovel- 1(71)

10 lusraportti kuvaa yksityiskohtaisesti projektissa toteutetun sovelluksen toiminnan sekä suunnittelu- ja toteutusperiaatteet. Luokkadokumentaatio sisältää sovelluksen lähdekoodin dokumentaation, jossa on kuvattuna jokaisesta luokasta ja metodista sen tehtävä, käytetyt parametrit, poikkeukset sekä 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ö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ä sekä niiden hallintaa ja toteutumista. Luvussa 9 ryhmän jäsenet kuvaavat omia kokemuksiaan ja oppimistaan. Lisäksi 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 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(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ä: Eclipse EPD Ketterä ohjelmakehitys 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 ohjelmistokehityksen perusperiaatteisiin kuuluu toimivan ohjelmiston priorisointi, nopea muutoksiin reagointi sekä joustava viestintä kehittäjän ja asiakkaan välillä. 4(71)

13 MaxFilter MNE PyDoc 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 työkalu Pythonilla kirjoitettujen ohjelmien luokkadokumentaation generointiin. 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 datan esikäsittelyn toteutukseen, joten 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, koska 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.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 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 6(71)

15 Kuva 3.1: MEG-mittauslaite. 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. 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. 7(71)

16 Kuva 3.2: Esikäsittelemätöntä raakadataa. Kuva 3.3: Keskiarvoistettu epookki.

17 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 tuotantoversion tulee yhdistää MNE-ohjelmisto ja MaxFilter-ohjelmisto 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. 3.3 Sovelluksen kehitysvälineet ja toteutus 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. 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 9(71)

18 Kuva 3.4: Sovelluksen kokonaisrakenne. projektin päättymisen jälkeen. Jatkokehitys pyrittiin ottamaan huomioon sovelluksen 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 kirjaamalla toteuttamatta jääneet vaatimukset ylös vaatimusmäärittelyyn, jotta jatkokehityksen aloittaminen olisi mahdollisimman helppoa. Lisäksi Kari Aliranta jatkokehittää sovellusta kesällä, ja hän kirjasi ylös erilaisia jatkokehitysideoita sekä korjattavia puutteita sovelluksessa. Projektiryhmän jäsenet joutuivat käyttämään suunniteltua enemmän aikaa esitutkimukseen. Lisäksi datan esikäsittelyvaiheen toteutus osoittautui huomattavasti ole- 10(71)

19 tettua 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. Sovelluksen prototyyppi toimitettiin tilaajalle kesäkuun alussa. 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.4 Sovelluksen toteutuminen Sovelluksesta ei saatu projektissa toteutettua tuotantoversiota, vaan se jäi prototyyppiasteelle. Vaatimusmäärittelyssä pakollisia vaatimuksia oli 33 kappaletta ja niistä toteutui projektissa 31 kappaletta, joko ryhmän toteuttamana tai ulkopuolisella komponentilla. Väärien parametrien syöttämisestä aiheutuvat virheilmoitukset toteutettiin osittain, mutta toimenpiteen uusimisesta johtuvaa datatiedoston uudelleentallennusta ei ehditty toteuttaa. Tärkeäksi merkittyjä vaatimuksia oli 38, ja niistä ehdittiin toteuttaa 17 ja yksi vaatimus osittain. Loput sovittiin jatkokehitykseen. Vaatimuksia, jotka oli merkitty toteutettavaksi ajan salliessa oli 6 kappaletta, mutta niistä ei ehditty toteuttaa yhtään. 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 tallennettavat tiedostot tallennetaan oikeannimisinä oikeisiin paikkoihin. Sovellus ohjaa käyttäjää avaamalla uusia toimenpiteitä sen perusteella, mitä datalle ollaan 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 tehdyn 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 (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(71)

20 ympärillä. Sovelluksen käyttö etenee pääosin loogisesti. Käyttäjä ei kuitenkaan saa palautetta siitä, että jokin aikaavievä toiminto on kesken. Lisäksi osa virheilmoituksista eivät ole tarpeeksi informatiivisia. Sovellusta varten kehitettiin myös joitakin toimintoja liittyen tilastotietojen etsimiseen kuvaajista analyysia varten. Näitä ei kuitenkaan ehditty liittää sovellukseen. 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ä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ä. - Luokkadokumentaatio kuvaa toteutettujen ohjelmaluokkien 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 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, toiminnalliset ja tekniset vaatimukset sekä rajoitteet. 12(71)

21 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. 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. 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ö 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 aikana opittiin 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ä. 13(71)

22 Projektiryhmä oppi 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 oppimisessa. Kellään Hoksotin-ryhmän jäsenistä ei juurikaan 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 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ä. 14(71)

23 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 suosittelun takia. Sovellusraportti kirjoitettiin Libre Officella, koska todettiin ettei Alirannan 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. 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 sekä 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 kirjoitettavan lähdekoodeista PyDocilla, mutta ryhmä käytti kuitenkin Doxygeniä, 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. Luennot ja perehdytykset toteutuivat suunnitellusti. 19(71)

28 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. 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. 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(71)

29 tettiin palavereissa. Varsinaista sovelluksen toimintaa esiteltiin palaverien jälkeen ryhmän työtilan 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 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 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 tallennettiin 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ä. 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 22(71)

31 class_documentation esittelyt itsearvioinnit palaverit esityslistat poytakirjat tilakatsaukset ohjeet projektiraportti projektisuunnitelma requirements_specification sahkopostiarkistot hoksotin hoksotin_opetus sitoumus_ja_lisenssit source_code Tiedostojen nimeäminen toteutui suunnitellusti. Hakemusrakenne muuttui testauksen osalta. Koska varsinaista järjestelmätestausta ei projektissa tehty, ei testaukseen liittyviä dokumentteja myöskään kirjoitettu. TARKISTA VIELÄ LAITETAANKO ASENNUSOHJE ERIKSEEN VAI ESIM: LÄHDEKOODIN SEKAAN 5.4 Lähdekoodi Lähdekoodi kirjoitettiin vastaamaan yleisiä Pythonin käytänteitä [11] ja Doxygenin mukaisia käytänteitä [?]. 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, (71)

32 @author: 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. ) else: return self._info.get( highpass ) 24(71)

33 25(71)

34 Lähdekoodi kirjoitettiin suunniteltuja käytänteitä noudattaen. Luokkadokumentaatio 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 testiajoilla, sekä debuggaamalla. Sovellukseen kirjoitettiin laskennallista koodia hyvin vähän. Laskennalliselle koodille kirjoitettiin erilliset unit-testit. Nämä 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 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 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 toteutettu suunnitellusti. Tilaaja ja vastaava ohjaaja koekäyttivät sovellusta, mutta testaussuunnitelmaa ja -raportteja ei laadittu. 26(71)

35 Sovelluksen käytettävyyteen kiinnitettiin huomiota kaikkien kehitysvaiheiden aikana. 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 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 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. 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, käyttöohjeelle ja sovellusraportille. Lisäksi vaatimusmäärittelylle ja projektisuunnitelmalle hankittiin tilaajan hyväksyntä. Tekni- 27(71)

36 nen 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. 28(71)

37 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. Projektiryhmän jäsenten tavoiteltu työtuntimäärä 350 tuntia per jäsen ylittyi jokaisella jäsenellä noin 20 tuntia. Esitutkimukseen kuluva aika oli selkeästi aliarvioitu projektisuunnitelmassa, koska projektin aihe osoittautui paljon arvioitua vaativammaksi. Järjestelmätestausta ei projektissa tehty, vaan siihen varatut työtunnit käytettiin sovelluksen suunnitteluun ja toteutukseen. Projektin oheiskurssiin kuluva aika oli hieman yliarvioitu suunnitelmassa. 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 ennakoimattomasti 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ä. Merkittävää haittaa projektipäällikön poissaolosta ei kuitenkaan ollut, vaan tilakatsaus lähetetettiin myöhemmin samana päivänänä sähköpostitse. 29(71)

38 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ä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. 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 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 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. Muutenkin testauksesta siirrettiin työtunteja sovelluksen toteutukseen, joten järjestelmätestaukselle ei jäänyt aikaa. Testausta tehtiinkin lähinnä yksikkötestien muodossa. Lisäksi ohjaajat ja tilaa- 30(71)

39 jan edustaja koekäyttivät ohjelmistoa. 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 5 tuntia päivässä. Työmäärätavoitteeseen 350 tuntia kutakin jäsentä kohden oli tavoitteena päästä toukokuun loppuun mennessä. Tähän arvioon oli otettu huomioon kevään juhlapyhät pääsiäinen, vappu sekä helatorstai. Jaakko Leppäkankaalla suunnitellut tunnit tulivat täyteen jo toukokuun puolivälissä, mutta hän jatkoi silti projektin parissa työskentelemistä toukokuun 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 se sovittiin Jaakko Leppäkankaan tehtäväksi. 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 joidenkin tehtävien toteutuneet työtunnit ylittivät arvion. 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. Projektin hallintaan kuluva aika toteutui aika pitkälti suunniteltuna. Leppäkan- 31(71)

40 kaalle 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. 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ä merkitsivät tämänkin ajan palavereihin, kun taas toiset esimerkiksi suunnitteluun tai toteutukseen. Rautio oli poissa yhdestä palaverista, joten hänellä on siksi vähemmän tunteja merkittynä kuin muilla. 32(71)

41 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 ? 35? Tulosten viimeistely 4? 4 0 4? 4? 16? Tulosten luovutus 4? 4 0 4? 4? 16? Yhteensä 16? ? 157? 210? Palaverit Valmistelu ? Palaverit ? Pöytäkirjat ? Yhteensä 42? ? Esitutkimus Aihealueeseen tutustuminen ? Koulutus ? Työkaluihin tutustuminen ? Yhteensä ? Vaatimusmäärittely Suunnittelu ? ? Raportointi ? ? Yhteensä 0? ? ? 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 45? ? Lähdekoodin katselmointi ? Lähdekoodin viimeistely 3? ? 3? 19? Sovelluksen luovutus 1? 1 0 1? 1? 4? Yhteensä 53? ? 8? 84? Projektin tunnit yhteensä 285? 288 textbf ? 288? 1149? Oheiskurssi Kirjoitusviestintä ? Puheviestintä ? Projektiluennot ? Yhteensä ? Projektin ja oheiskurssien tunnit yhteensä 350? ? 350? 1400? Taulukko 6.2: Tehtävien suunnitellut ja toteutuneet työtunnit.

42 6.4 Ryhmän työtunnit tehtäväkokonaisuuksittain PIIRAKKAKAAVIOT OVAT VIELÄ KESKENERÄISIÄ Ryhmän työtunnit tehtäväkokonaisuuksittain on esitelty kuvassa 6.5. Esitutkimukseen kului paljon enemmän aikaa kuin oli suunniteltu aihealueen vaativuuden vuoksi. Projektiryhmä joutui käymään Helsingissä yhtenä päivänä keskustelemassa tilaajan teknisen asiantuntijan kanssa sovelluksen toteutuksesta, mikä omalta osaltaan kasvatti tuntimäärää. Suunnitteluun oli varattu aikaa 145 tuntia ja toteutukseen 309 tuntia. Suunnitteluun oli merkitty kuitenkin vain 99 tuntia, kun taas toteutukseen 505 tuntia. Toteutusta ja suunnittelua tehtiin kuitenkin usein samanaikaisesti ja niihin käytetyt tunnit merkittiin toteutuksen puolelle, mikä osaltaan selittää eroa. Suunnitteluun ja toteutukseen varatut tunnit ylittyivät kuitenkin yli 150 tunnilla. Toisaalta projektin oheiskurssiin varatut alittuivat selvästi. Kultakin jäseneltä kului oheiskursseihin noin 20 tuntia suunniteltua vähemmän. Lisäksi testausta ei pystytty suorittamaan kunnolla, joten aikaa toteutukselle jäi enemmän. 34(71)

43 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.

44 6.5 Kari Alirannan työtunnit tehtäväkokonaisuuksittain Kari Alirannan osalta esitutkimukseen kului aikaa aika pitkälti niin paljon kuin oli suunniteltukin. Toisaalta hän harjoitteli työkalujen käyttöä suunnittelemalla ja toteuttamalla sovellusta, joten osa opetteluun käytetyistä tunneista on kirjattu niihin. Suunnitteluun ja toteutukseen varatut työtunnit ylittyivät myös Alirannan osalta selvästi. Projektisuunnitelman mukaan Aliranta olisi ollut päävastuussa myös sovelluksen testaamisesta ja testaussuunnitelman ja -raportin kirjoittamisesta, mutta koska testausta ei projektissa ehditty kunnolla suorittaa, vapautuivat siihen varatut tunnit sovelluksen toteuttamiselle. 36(71)

45 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.

46 6.6 Jaakko Leppäkankaan työtunnit tehtäväkokonaisuuksittain Koska Jaakko 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 varattu aika ylittyi kuitenkin hieman, koska hän kävi projektiryhmän yhteisen vierailun lisäksi toisenkin kerran Helsingissä tapaamassa tilaajan teknistä asiantuntijaa. Sovelluksen suunnitteluun ja toteutukseen Leppäkangas käytti yli 100 tuntia suunniteltua enemmän. Tämän vuoksi hänen työtuntinsa tulivat täyteen jo toukokuun puoleenväliin mennessä, joten viimeistelyyn hän käytti tunteja säästeliäästi. Leppäkangas käytti projektiin noin 390 tuntia ja ylitti siis suunnitellun kokonaistuntimäärän 40 tunnilla. 38(71)

47 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.

48 6.7 Janne Pesosen työtunnit tehtäväkokonaisuuksittain Palaverit veivät Janne Pesosen osalta vähemmän aikaa kuin oli suunniteltu pääosin siksi, että hän kirjoitti pöytäkirjat paljon ennakoitua nopeammin. Esitutkimukseen Pesosella kului suunniteltua enemmän aikaa. Aihealue oli odotettua vaativampi. Lisäksi ryhmän tekemä vierailu Helsinkiin kirjattiin esitutkimukseksi, mikä nosti työtunteja huomattavasti. Suurin osa muista tehtäväkokonaisuuksista säästyneistä työtunneista näkyvät Pesosella siinä, että hän käytti sovelluksen suunnitteluun ja toteutukseen 44 tuntia suunniteltua enemmän. 40(71)

49 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.

50 6.8 Atte Raution työtunnit tehtäväkokonaisuuksittain 42(71)

51 Atte Raution projektin hallintaan ja palavereihin käytetyt työtunnit vastasivat melko tarkasti suunniteltua. Heittoa toteumassa on suunnitelmaan verrattuna vain muutamia tunteja. Rautiolla kului esitutkimukseen melkein kaksi kertaa suunniteltu määrä mutta hänenkin kohdallaan tuntimäärään vaikuttaa ryhmän tekemä Helsinginmatka. Rautiolla kului suuri osa ajasta projektipäällikön tehtäviin, joihin kuluvia työtunteja oli kaikista helpointa arvioida. Täten sovelluksen suunnitteluun ja toteutukseen arvioidut työtunnit täsmäävät hyvin pitkälti suunnitelman kanssa.

52 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. 44(71)

53 7 Prosessimalli ja aikataulu Luvussa käsitellään projektissa noudatettua prosessimallia ja suunniteltua aikataulua sekä verrataan suunnitelmaa toteutumaan. Prosessi muuttui hieman suunnitellusta, koska suurin osa sovelluksen toteutuksesta kului esikäsittelyvaiheen toteutukseen ja itse analysointi ja visualisointi jäivät pienemmälle huomiolle. Sovelluksen toteutusta jatkettiin vielä toukokuun alkuviikkoina, mikä aikataulun venymisessä, joten projektille varattu kahden viikon pelivara jouduttiin käyttämään. Prosessi ei toteutunut aivan suunnitellusti. Sovelluksen ttoteutuksen aloituksessa oli jonkin verran ongelmia ja suurin osa toteutuksesta kului datan esikäsittelyvaiheeseen. Täten prosessin vaiheiden vaihtuminen ei pahemmin näkynyt toteutuksen aikana. 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. Vaiheet auunniteltiin kestävän kahdesta kolmeen viikkoa. Siirryttäessä varsinaiseen sovelluksen kehitykseen, ei prosessin vaiheisiinjako juurikaan näkynyt. Aihealue oli sen verran vaativa, että suurin osa toteutukseen varatusta ajasta meni esikäsittelyn toteuttamiseen, jolloin analyysille ja visualisoinnille 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. Varsinaisen ohjelmistokehityksen tuli tapahtua vaiheissa kolme, neljä ja viisi. Käytännössä prosessin vaiheisiinjako ei kuitenkaan toteutuksen aikana näkynyt. Sovelluksen osakokonaisuuksien toteutukseen käytettiin niin paljon aikaa kuin ne vaativat ja sen jälkeen otettiin uusi osakokonaisuus kehitettäväksi. Viimeinen vaihe varattiin projektin viimeistelylle ja tulosten toimittamiselle. Vaiheiden vaihtuminen ei toteutuksen aikana juurikaan näkynyt, vaan suurin osa 45(71)

54 toteutukselle varatusta ajasta meni esikäsittelyvaiheen toteutukseen. Noudatettavaa prosessimallia olisikin pitänyt miettiä projektin alussa hieman tarkemmin. Toisaalta koska projektin aihealue ja tavoitteet olivat silloin 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. 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 sovelluksen kehitys suunniteltiin tapahtuvaksi maaliskuun alun ja huhtikuun lopun välisenä aikana kolmessa kehitysvaiheessa Kehityksen aloitus viivästyi tästä hieman ja alkoi vasta maaliskuun puolessa välissä. Projektin aihealue oli niin vaativa, että siihen jouduttiin perehtymään paljon suunniteltua enemmän. Aihealueeseen jouduttiin perehtymään lisää kehityksenkin aikana. Kehitys suunniteltiin päätettäväksi huhtikuun lopussa, mutta sitä jatkettiin vielä toukokuun pari ensimmäistä viikkoa. Tämän jälkeen aloitettiin projektin viimeistely ja laadittiin projektiraportti sekä sovellusraportti ja viimeisteltiin vaatimusmäärittely. Lisäksi tulokset koottiin projektikansioon. Tulokset hyväksyttiin kesäkuun alkupuolella, joten projektin päättyminen viivästyi hieman. 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 (71)

55 TÄHÄN ANALYYSIÄ GANTT K AAV IOIST A 47(71)

56 Kuva 7.1: Projektin suunniteltu aikataulu.

57 Kuva 7.2: Projektin toteutunut aikataulu.