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ä: 39 Tiedosto: HoksotinProjektiraportti0.1.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. Projektiraportissa kuvataan projektin tavoitteet ja niiden toteutuminen, resurssit, käytänteet, tehtävät ja niiden arvioidut sekä toteutuneet työtunnit, aikataulu sekä projektiin liittyvät riskit, niiden hallinta ja niiden toteutuminen. 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

4 Muutoshistoria Versio Päivämäärä Muutokset Tekijät Projektiraportin pohja on luotu. Pohjana käytetään projektisuunnitelman versiota 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. 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 Yhteystiedot: Sähköpostilista Sähköpostiarkisto Sähköpostilista (opetus) Sähköpostiarkisto (opetus) Projektiryhmän työtila AgC 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 tavoitteet Projektin taustaa Sovellus 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 Prosessimalli ja aikataulu Prosessimalli Aikataulu v

8 8 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 Yhteenveto Lähteet 38 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 [1]. Keskuksen tiloihin on tulevaisuudessa tarkoitus hankkia MEG-mittauslaitteisto. Mittauslaitteiston avulla pystytään tutkimaan aivojen toimintaa aivojen 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 käsittelyyn, analysointiin ja kuvantamiseen. Sovelluksen tavoitteena on saada kaikki MEG-mittausdatan analysointiin liittyvät toiminnot saman käyttöliittymän alle niin, ettei käyttäjän tarvitse käyttää komentorivikomentoja missään vaiheessa. Sovellus suorittaa kaikki tarvittavat komentorivikutsut käyttäjän puolesta, kunhan käyttäjä syöttää tarvittavat parametrien arvot. 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 ja vaaditut sekä 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. 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 vas- 1(39)

10 tuuhenkilö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. 2(39)

11 2 Termejä Luvussa esitellään dokumentissa käytettäviä aihealueen ja kehitysvälineiden termejä. 2.1 Aihealueen termejä Dokumentissa esiintyvät projektin hallintaan ja 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 esimerkiksi 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 noin 306 MEG-kanavaa. eli Superconducting Quantum Interference Device on suprajohtava sensori, jolla MEG-laitteella tehtävä mittaus tapahtuu. Yhdessä mittauslaitteessa on useita SQUIDeja. 3(39)

12 SSS 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. 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 MaxFilter 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ä. on Elekta Oy:n julkaisema ohjelmisto MEG-datan analyysiin [8]. 4(39)

13 MNE PyDoc Python YouSource 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 julkaisujärjestelmä, jota käytetään projektissa laaditun lähdekoodin versiohallintaan ja julkistamiseen. [9] 5(39)

14 3 Projektin tavoitteet Luvussa kuvataan projektin taustaa sekä toteutettavan sovelluksen tavoitteita. Luvussa esitellään myös projektin aikana toteutetut tulokset sekä projektiryhmän jäsenten oppimistavoitteet ja niiden toteutuminen. 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. Kuva 3.1: MEG-mittauslaite. 6(39)

15 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ä. Analyysiä voidaan tehdä joko sensoritasolla, jolloin tutkitaan yksittäisten sensorien mittaamaa signaalia, tai lähdetasolla, jolloin 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. Kuva 3.2: Esikäsittelemätöntä raakadataa. 7(39)

16 Kuva 3.3: Keskiarvoistettu epookki. Datan esikäsittelylle ja analyysille on olemassa valmiita ohjelmia. Monet niistä ovat vaikeasti käytettäviä johtuen pääosin siitä, että niitä käytetään 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 Sovellus Hoksotin-projekti toteutti Jyväskylän yliopiston Jyväskylän monitieteiselle aivotutkimuskeskukselle käyttöliittymän MEG-laitteella mitatun datan esikäsittelyyn, analyysiin ja kuvantamiseen. Kehitettävän sovelluksen tulee yhdistää MNE-ohjelmisto ja MaxFilter-ohjelmisto yhden käyttöliittymän alle. Sovelluksen käyttäjät ovat pää- 8(39)

17 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 ilman, että joudutaan tekemään 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ä, jotta 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. 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 huomattavasti suunniteltua enemmän aikaa. Sitej lokitietojen keräys ja osa kuvaajiin liittyvistä toiminnoista jäi toteuttamatta ja ne siirrettiin jatkokehitykseen. 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 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 [12] ohella sovelluksen laajennettavuus. Projektin aikataulu oli rajallinen, joten sovellusta joudutaan pakostakin jatkokehittämään projektin päättymisen jälkeen. Jatkokehitys pyrittiin ottamaan huomioon sovelluksen toteutusratkaisuissa ja dokumentoinnissa. Käytännössä tämä tarkoittaa sitä, että vaikka kaikkia vaatimuksia ei ehdittäisikään toteuttaa, otetaan ne kuitenkin projektin aikana huomioon ja toteutetaan lähdekoodiin alustavat aliohjelmarungot. 9(39)

18 Käyttöliittymä Näkymiä Toiminnallisuus Hallintaluokat Tiedostohallinta Lisäominaisuudet Kutsuttavat ohjelmistot Kutsuttavat ohjelmistot MNE Maxfilter Kuva 3.4: Sovelluksen kokonaisrakenne. Sovellus toimitettiin tilaajalle toukokuun loppuun mennessä. Projektiryhmä piti tilaajan ajantasalla projektin etenemisestä, jotta tilaajan oli helpompi osoittaa ne sovellukselle asetetut vaatimukset, joiden kehittäminen on ensisijaista. Lisäksi tilaajan aktiivisella osallistumisella saatiin sovelluksen kehitys pidettyä varmemmin toivotussa suunnassa. 3.3 Tulokset Sovelluksen ohella projektiryhmä toteutti seuraavat tulokset: 10(39)

19 - 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ä. - Palaverien dokumentit sisältävät palaverien esityslistat, pöytäkirjat ja niissä esitetyt tilakatsaukset. - Käyttöohje neuvoo sovelluksen käytön. - Lähdekoodi sisältää projektissa toteutetun sovelluksen kommentoidun lähdekoodin. - Oheiskurssien materiaalit sisältävät oheiskurssien suoritukseen kuuluvat kirjoitusharjoitukset ja muun materiaalin. - 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 virheet 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 sijoitetaan Creative Commons Attribution-ShareAlike 3.0 Unported -lisenssin alaisuuteen. Kaikki projektissa toteutettu lähdekoodi sijoitetaan avoimen lähdekoodin Simplified BSD -lisenssin alaisuuteen. 3.4 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 testauk- 11(39)

20 seen 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 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 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ävyyttä ja siihen 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ä pro- 12(39)

21 jektin 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, missä oltiin menossa, 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 on oppia ohjelmistojen suunnittelu- ja toteutusperiaatteita etenkin Pythonin osalta. He haluavat myös saada realistista tuntumaa asiakkaan kanssa neuvottelemisesta varsinkin, jos asiakas itse ei ole tietotekniikan ammattilainen. - Janne Pesonen haluaa saada käytännön työkokemusta ja oppia ryhmätyöskentelyyn liittyviä taitoja. - Atte Raution tavoitteena on saada käytännön kokemusta ohjelmistokehityksestä ja projektityöskentelystä. Lisäksi hän haluaa kokemusta projektipäällikön tehtävistä ja vastuista. Oppimistavoitteiden toteutumista arvioidaan tarkemmin jäsenten itsearvioinneissa. 13(39)

22 4 Projektin resurssit Luvussa käsitellään projektiorganisaatioon kuuluvien henkilöiden lisäksi muita projektin käytössä olleitaa 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ä 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. 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ä. 14(39)

23 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 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. 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. Toteutettavan sovelluksen vaatimusten suunnittelu ja määrittely 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 [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ä- 15(39)

24 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ö alkoi työstämään seuraavan palaverin tilakatsausta. 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. 16(39)

25 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. Projektipäällikkö esitteli palavereissa tilakatsauksen kuvaten, mitä projektissa oli tehty edellisen palaverin jälkeen ja mitä ongelmia oli kohdattu. Lisäksi tilakatsauksissa esiteltiin viikottaiset työtunnit tehtäväkokonaisuuksittain ja viikoittain sekä koko ryhmän että yksittäisten jäsenten osalta. 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 esitettiin palavereissa. Varsinaista sovelluksen toimintaa päätettiin esitellä palaverien jälkeen ryhmän työtilassa, koska sovellus ei toimi Windowsissa. 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ä. 17(39)

26 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 etenee 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ä. 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 lyhyen tilaraportin 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, jolloin saadaan aikaa säästettyä. Käytännössä tällaisia viikottaisia tilakatsauksia ei kuitenkaan paljoa tehty 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, 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 18(39)

27 Projektiryhmän jäsenten ja ohjaajien käytössä oli myös toinen sähköpostilista Sen sähköpostiarkisto sijaitsee osoitteessa hoksotin_opetus/. 5.3 Tiedostojen nimeäminen ja hakemistorakenne Lähdekooditiedostojen nimeämisessä käytetään Pythonin yleisiä käytänteitä. Nimeämisessä käytetään ainoastaan pieniä kirjaimia, ja välilyönnit korvataan 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 itsearvioinnit palaverit esityslistat poytakirjat tilakatsaukset ohjeet projektiraportti projektisuunnitelma requirements_specification sahkopostiarkistot hoksotin hoksotin_opetus sitoumus_ja_lisenssit 19(39)

28 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, 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. 20(39)

29 """ if isinstance(raw, mne.fiff.raw.raw): self._raw = raw self._info = dict(raw.info) else: raise TypeError( Not a Raw object. ) 21(39)

30 @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 ) 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 ja täyttää sille asetetut toiminnalliset sekä laadulliset vaatimukset. Lähdekoodin yksikkötestaus oli lähdekoodin kirjoittajan vastuulla. Yksikkötestauksessa hänen 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. Yksikkötestit tähän koodiin kirjoitti poikkeuksellisesti Atte Rautio, vaikka itse koodi olikin toisen jäsenen kirjoittamaa. 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 ai- 22(39)

31 kana ja käytettävyydestä saatiin myös paljon palautetta. 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. 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 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ä (siis toinen hyväksytty versio on 1.1.0). 5.7 Katselmoinnit ja tulosten hyväksyminen Projektiryhmän kirjoittama lähdekoodi tullaan katselmoimaan vähintään kaksi kertaa. Katselmoinnissa tekninen ohjaaja kommentoi lähdekoodia antaen vinkkejä ja parannusehdotuksia. Tekninen ohjaaja myös hyväksyy lähdekoodin. Katselmointiin osallistuu teknisen ohjaajan lisäksi koko projektiryhmä, ja katselmoinnin havainnot kirjataan muistioksi. Projektin lopussa tulokset kokonaisuutena hyväksytetään projektin ohjaajilla sekä tilaajan edustajalla. Yksittäisistä tuloksista tilaajan edustajan hyväksyntä tarvitaan vähintään toteutetulle sovellukselle, käyttöohjeelle ja sovellusraportille. Tekninen ohjaaja hyväksyy lähdekoodin. Vastaava ohjaaja hyväksyy projektin keskeisimmät raportit, joita ovat projektisuunnitelma, projektiraportti ja sovellusraportti. 23(39)

32 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 lisäksi 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. 24(39)

33 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 ja Kari Alirannan vastuu painottui hieman enemmän käyttöliittymän toteutukseen. Projektin aikataulutus ja 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 aikaa hieman yli kolmasosan koko projektin työmäärästä, mikä vastaa normaalia ohjelmistokehitysprojektia. 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. 6.2 Vastuualueet tulosten osalta Keskeisimpien tulosten vastuuhenkilöt on esitetty taulukossa 6.1. 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ä tämäntyyppinen tiedotus hoidettiin kuitenkin palavereissa. 25(39)

34 Tulos Projektisuunnitelma Vaatimusmäärittely Sovelluksen kokonaisrakenne Sovellusraportti Lähdekoodin viimeistely Järjestelmätestaus Projektiraportti Vastuuhenkilö Atte Rautio Janne Pesonen Jaakko Leppäkangas Kari Aliranta Jaakko Leppäkangas Kari Aliranta 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. 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 kutakin jäsentä kohden on 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. 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. 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, ettei niille ollutkaan tarvetta. Joidenkin tehtävien tuntiarvioiden ylittymisen vuoksi jouduttiin osa tehtävistä siirtämään jatkokehitykseen. 26(39)

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

36 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 muut osat jäivät pienemmälle huomiolle. Tämä näkyy myös aikataulun venymisessä. 7.1 Prosessimalli Projektissa ei varsinaisesti käytetä 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. 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 tustuminen tapahtuivat myös näiden viikkojen aikana. 28(39)

37 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. 29(39)

38 Projektin tehtäväkokonaisuuksien toteutuneet aikajänteet esitellään kuvassa 7.1. TÄHÄN GANTT-KAAVIO TOTEUTUNEESTA AIKATAULUSTA (Latex näköjään hyppyyttää tekstiä miten sattuu, korjataan, kun toteutunut Gantt-kaavio on valmis.)

39 Kuva 7.1: Projektin suunniteltu aikataulu. 31(39)

40 8 Riskien hallinta Luvussa käsitellään projektiin liittyviä riskejä sekä niiden toteutumisen todennäköisyyttä, vaikutusta ja hallintaa. 8.1 Riskien todennäköisyydet ja haitat Riskien arvioidut esiintymistodennäköisyydet, haittavaikutukset ja toteumat on esitetty taulukossa 8.1. Riskien todennäköisyyksiä, vaikutuksia ja toteumaa on arvioitu kolmiportaisella asteikolla pieni, keskinkertainen ja suuri. Riski Arvioitu todennäköisyyvaikutuminen Arvioitu haitta- riskin toteutu- Projektiorganisaatioon ja sidosryhmiin suuri keskinkertainen toteuma kuuluvien toiminnan viiveet Projektin aiheen haastavuus suuri keskinkertainen toteuma Vaikeudet valmiiden komponenttien suuri keskinkertainen toteuma käytössä Puutteet projektiryhmän tietotaidoissa keskinkertainen keskinkertainen toteuma Toteutettavien ominaisuuksien tarkentaminen keskinkertainen keskinkertainen toteuma ja rajaus Jäsenten odottamattomat poissaolot pieni suuri toteuma Projektin hallinnan puutteet pieni keskinkertainen toteuma Taulukko 8.1: Riskien todennäköisyydet, haittavaikutukset ja toteumat. Taulukon riskien vaikutusta projektin läpivientiin ja tuloksiin sekä riskien ehkäisyä ja vaikutusten minimointia on kuvattu luvuissa SEURAAVIA LUKUJA EI OLE VIELÄ MUOKATTU RAPORTTIA VASTAAVIKSI 32(39)

41 8.2 Projektiorganisaatioon ja sidosryhmiin kuuluvien toiminnan viiveet Sidosryhmiin kuuluvien toiminnan viiveillä tarkoitetaan projektiorganisaatioon tai esimerkiksi ATK-lähitukeen kuuluvien henkilöiden toimenpiteiden viivästymistä. Jos projektiryhmä esimerkiksi joutuu odottamaan ATK-tuen reagointia palvelupyyntöihin, on riski toteutunut. Myös jos esimerkiksi aiheen ja tavoitteiden tarkentuminen siirtyy myöhemmäksi asiakkaan edustajien tai vastaavan ohjaajan muiden kiireiden takia, on riski toteutunut. Toteutuessaan riski hidastaa projektin etenemistä ja hankaloittaa aikataulussa pysymistä. Riskin ehkäisemiseksi projektiryhmän jäsenet pitävät aktiivisesti yhteyttä projektiorganisaation ja sidosryhmien kanssa, ja toimenpiteistä sovitaan mahdollisimman varhain. Riskiä pyritään ehkäisemään myös tehokkaalla ja aktiivisella tiedotuksella. Projektin aikatauluun on varattu kahden viikon pelivara toukokuun lopussa. Riskin toteutuessa arvioidaan asiakkaan kanssa riskin aiheuttamat haittavaikutukset ja muutetaan sen perusteella esimerkiksi sovelluksen vaatimuksia ja niiden priorisointeja. Jos toteutunut riski johtuu projektiorganisaatioon kuuluvista henkilöistä, pyritään asiaan löytämään ratkaisu neuvottelemalla aikatauluista projektiorganisaatioon kuuluvien kesken. Vastaava ohjaaja voi tarvittaessa hoputtaa ATK-tukea, jos heidän toiminnassaan on viiveitä. 8.3 Projektin aiheen haastavuus Projektin aihe on hyvin vaativa. Projektiryhmän jäsenillä ei ole minkäänlaista kokemusta aivotutkimuksesta, joten kehitettävällä sovelluksella tuettavan prosessin ymmärtäminen on vaikeaa. Riskin ehkäisemiseksi ryhmän jäsenille varataan paljon aikaa aihealueeseen tutustumiseen. Lisäksi aihetta selvennetään palavereissa ja tilaajalta kysytään tarvittaessa neuvoja sekä taustamateriaalia aiheeseen liittyen. Myös teknisen ohjaajan apu on välttämätöntä riskin ehkäisemiseksi. Riskin toteutuessa sovelluksen toteutuminen viivästyy. Tällöin joudutaan pyytämään tilaajaa kuvaamaan tuettavaa prosessia tarkemmin. Tarvittaessa käydään kysymässä neuvoa tilaajan tekniseltä asiantuntijalta henkilökohtaisesti. 33(39)