Hoksotin-sovellusprojekti

Transkriptio

1 Hoksotin-sovellusprojekti Kari Aliranta Jaakko Leppäkangas Janne Pesonen Atte Rautio Projektisuunnitelma 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, Projektisuunnitelma Sivumäärä: 37 Tiedosto: HoksotinProjektisuunnitelma0.5.0.tex Tiivistelmä: Hoksotin-projektissa kehitetään käyttöliittymäprototyyppi MEG-mittauslaitteella mitatun aivosignaalidatan esikäsittelyyn, analyysiin ja kuvantamiseen. Projektisuunnitelma kuvaa Hoksotin-projektin suunnitellun läpiviennin. Projektisuunnitelmassa kuvataan projektin tavoitteet, resurssit, käytänteet, tehtävät ja niiden arvioidut työtunnit, aikataulu sekä projektiin liittyvät riskit ja niiden hallinta. 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 Projektisuunnitelman pohja on laadittu sekä luvut AR 4 ja 6 on aloitettu Projektisuunnitelman pohjaa on korjattu, versionumerointia AR muokattu ja johdantoa on aloitettu Projektiin liittyviä termejä ja dokumentin lähdeviittauksia AR on lisätty, johdantoa on kirjoitettu ja luku 3 on aloitettu Luvut 3 ja 4 on pääosin kirjoitettu, termejä ja lähteitä AR on lisätty ja lukua 5 on täydennetty Työtuntisuunnitelman pohja on luotu. AR Johdantoa, termejä ja lukua 3 on muokattu. AR Lukuja 3 ja 4 on korjattu sekä aikataulun Ganttkaavio AR on lisätty Kaikki luvut on kirjoitettu ja suunnitelma toimitettu AR projektiorganisaatiolle tarkastettavaksi Termejä on korjattu AR Suunnitelmasta on korjattu virheitä ja puutteita AR Suunnitelmasta on korjattu lisää virheitä ja puutteita AR Suunnitelman ulkoasua on korjattu, Ganttkaaviota AR muokattu ja rakennekuva lisätty lu- kuun Suunnitelmaan on tehty viimeiset korjaukset 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 36 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 toteuttaa käyttöliittymäprototyypin MEG-mittausdatan käsittelyyn, analysointiin ja kuvantamiseen. Toteutettavan 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. Toteutettava sovellus suorittaa kaikki tarvittavat komentorivikutsut käyttäjän puolesta, kunhan käyttäjä syöttää tarvittavat parametrien arvot. Projektille varattu aika on sen verran lyhyt, että tuotantoversiota sovelluksesta tuskin ehditään toteuttamaan. Prototyyppi tulee sisältämään olennaisimmat toiminnot, ja se toteutetaan helposti laajennettavaksi. Projektisuunnitelma kuvaa yksityiskohtaisesti projektin suunniteltua läpivientiä ja määrittelee sille asetetut tavoitteet ja vaaditut tulokset yleisellä tasolla. Projektisuunnitelmassa esitellään kaikki projektiorganisaatioon kuuluvat henkilöt ja muut projektiin keskeisesti liittyvät resurssit. Lisäksi käsitellään projektissa sovellettavia käytänteitä, ryhmän jäsenille osoitettuja tehtäviä ja vastuualueita sekä mahdollisten riskien hallintaa. Lisäksi dokumentissa esitetään suunnitelma ryhmän jäsenten työmääristä ja projektin kokonaisaikataulusta. Projektisuunnitelma on laadittu hyödyntäen Kuvatus-projektin projektisuunnitelmaa [4], koska Kuvatus-projektin aihe oli samantapainen kuin Hoksotin-projektin aihe. Projektiryhmä laatii projektisuunnitelman ohella muita projektia ja kehitettävää sovellusta kuvaavia dokumentteja. Sovelluksen tekniset ja toiminnalliset vaatimukset 1(37)

10 kuvataan vaatimusmäärittelyssä. Sovelluksen teknistä toteutusta kuvaavassa sovellusraportissa kuvataan yleisellä tasolla sovelluksen ohjelmakoodin toteutusratkaisut sekä mahdolliset havaitut puutteet ja jatkokehitysehdotukset. Projektiraportissa kuvataan projektin läpiviennin toteuma ja analysoidaan projektin läpiviennin onnistumista. Projektiraportissa myös verrataan projektin toteumaa suunnitelmaan sekä pohditaan mahdollisten erojen syitä ja vaikutuksia. 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 noudatettavia käytänteitä. Luvussa 6 esitellään projektin tehtäväkokonaisuudet ja tehtävät, tulosten vastuuhenkilöt, sekä arvioidaan jäsenten työmääriä tehtävittäin. Luvussa 7 esitellään projektin aikana noudatettavaa prosessimallia ja projektin suunniteltua aikataulua. Luvussa 8 käsitellään projektiin liittyviä riskejä ja niiden hallintaa. 2(37)

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(37)

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(37)

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(37)

14 3 Projektin tavoitteet Luvussa kuvataan projektin taustaa sekä toteutettavan sovelluksen tavoitteita. Luvussa esitellään myös projektin aikana toteutettavat tulokset sekä projektiryhmän jäsenten oppimistavoitteet. 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(37)

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(37)

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 toteuttaa 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 8(37)

17 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 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. Sovelluksen tulee toimia Linuxissa, ja se ohjelmoidaan Pythonilla. Sovellus tulee hyödyntämään 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 on luontevin valinta myös Hoksotin-projektissa toteutettavan sovelluksen ohjelmointiin. Käyttöliittymä toteutetaan PyQT:lla. Sovelluksen rakenne on kuvattu yleisellä tasolla kuvassa 3.4. Hoksotin-projektin päätavoite on toimittaa tilaajalle sovelluksen prototyyppi, jossa on huomioitu esitettyjen vaatimusten [12] ohella sovelluksen laajennettavuus. Projektin aikataulu on rajallinen, joten sovellusta joudutaan pakostakin jatkokehittämään projektin päättymisen jälkeen. Jatkokehitys otetaan 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. Sovellus toimitetaan tilaajalle toukokuun loppuun mennessä. Projektiryhmä pitää tilaajan ajantasalla projektin etenemisestä, jotta tilaajan on helpompi osoittaa ne sovellukselle asetetut vaatimukset, joiden kehittäminen on ensisijaista. Lisäksi tilaajan aktiivisella osallistumisella saadaan sovelluksen kehitys pidettyä varmemmin toivotussa suunnassa. 9(37)

18 Käyttöliittymä Näkymiä Toiminnallisuus Hallintaluokat Tiedostohallinta Lisäominaisuudet Kutsuttavat ohjelmistot Kutsuttavat ohjelmistot MNE Maxfilter Kuva 3.4: Sovelluksen kokonaisrakenne. 3.3 Tulokset Sovelluksen ohella projektiryhmä toteuttaa 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ä. 10(37)

19 - 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 testaukseen liittyen, minkä lisäksi tiiviissä ryhmässä kaikki oppivat väistämättä ryhmätyötaitoja. Erityisesti projektipäällikkö oppii projektityöskentelyn suunnittelussa ja hallinnassa vaadittuja johtamistaitoja ja ajankäytön hallintaa. Projektin aikana järjestettävät palaverit ovat olennainen osa sovellusprojektia ja sitä kautta myös oppimisprosessia. Palavereissa ryhmän jäsenet oppivat 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 11(37)

20 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. 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 ole aiempaa kokemusta Pythonista, joten kaikkien ryhmän jäsenten ohjelmointitaidot kehittyvät projektin aikana huomattavasti. Lisäksi ryhmän jäsenet oppivat lukemaan toisten kirjoittamaa koodia ja kirjoittamaan oman koodinsa helppolukuiseksi. Jäsenet oppivat myös hyödyntämään versiohallintaohjelmistoa, joka mahdollistaa koodin yhtäaikaisen kehityksen. Projektityöskentely edellyttää kaikilta ryhmän jäseniltä tiivistä yhteistyötä, sillä projektin läpivienti riippuu kaikkien jäsenten panoksesta. Ryhmässä työskenteleminen vaatii jäsenten väliltä luottamusta ja kykyä ottaa vastuuta. Projektityöskentelyssä korostuvat myös aloitekyky ja omatoimisuus, mutta toisaalta jokaisen tulee samalla pystyä pitämään muut ryhmän jäsenet ajan tasalla siitä, mitä kulloinkin tekee. Edellä mainittujen oppimistavoitteiden lisäksi projektiryhmän jäsenet ovat 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. 12(37)

21 - 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. 13(37)

22 4 Projektin resurssit Luvussa käsitellään projektiorganisaatioon kuuluvien henkilöiden lisäksi muita projektin käytössä olevia resursseja, kuten työtiloja, laitteita, työkaluja ja perehdytyksiä. 4.1 Projektiorganisaatio Projektiryhmään kuuluu 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 toimii Tiina Parviainen Jyväskylän yliopiston Jyväskylän monitieteisestä aivotutkimuskeskuksesta. Tilaajan asiantuntijana toimii Lauri Parkkonen Aalto-yliopistosta. Projektiryhmän yhteyshenkilönä ATK-lähituessa toimii Santeri Lapinmäki. Maritta Stoor-Lehtonen pitää oheiskurssin puheviestinnän luennot ja neuvoo puheviestintään liittyvissä asioissa. Kaisa Leino pitää kirjoitusviestinnän luennot ja neuvoo kirjoitusviestintään liittyvissä asioissa. Lisäksi hän antaa palautetta projektin aikana kirjoitettavien dokumenttien kirjoitusasusta. Käytettävyyden osalta projektiryhmää neuvoo Meeri Mäntylä. 14(37)

23 4.2 Projektin tilat ja laitteet Projektiryhmän työtilana toimii projektihuone Ag C223.2, joka sijaitsee Agoran C- siiven toisessa kerroksessa sovellusprojektien tiloissa. Huoneen solussa on monitoimilaite, jota projektiryhmän jäsenet käyttävät tulostukseen, kopiointiin ja skannaamiseen. Projektin aikana ryhmä käyttää kokoustilana kokoushuonetta Ag C Kokoushuoneessa olevan tietokoneen ja videoprojektorin lisäksi projektiryhmä saa tarvittaessa kokouskäyttöön kannettavan tietokoneen ja digisanelimen. Projektiryhmällä on 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ä on kaksi verkkolevyä. Toinen verkkolevy on tarkoitettu ryhmän sisäiseen tiedostojen jakamiseen ja toinen varataan projektin WWW-sivuille, joiden kautta ryhmä julkistaa dokumentteja projektiorganisaatiolle. 4.3 Ohjelmointi- ja dokumentointityökalut Ohjelmointikielenä Projektiryhmä käyttää Pythonia EPD-kirjastokokoelmalla laajennettuna. Käyttöliittymän toteutuksessa hyödynnetään PyQT:ta. Sovelluskehitysympäristönä käytetään Eclipseä. Tulosten versiohallintaan käytetään Git-versiohallintaohjelmistoa ja YouSource-nimistä lähdekoodien julkistusjärjestelmää. Luokkadokumentaatio muodostetaan lähdekoodeista PyDocilla. Projektin keskeisimmät ja laajimmat dokumentit kirjoitetaan L A TEX-ohjelmistolla. Toteutettavan sovelluksen vaatimusten suunnittelu ja määrittely tehdään Freemindilla ja Geditillä. Muiden dokumenttien kuten pöytäkirjojen ja muistioiden laatimiseen ryhmän jäsenet käyttävät kulloiseenkin tilanteeseen parhaaksi katsomaansa tekstinkäsittelyohjelmistoa. Sovellusprojektiin käytettävien työtuntien kirjaamisen käytetään Petri Heinosen kehittämää Excel-pohjaista ajankäytönseurantasovellusta [13]. Sen avulla muodostettuja kuvaajia käytetään myös projektipalaverien tilakatsauksissa. 15(37)

24 4.4 Luennot ja perehdytykset Sovellusprojektikurssin ohella opiskelijat suorittavat 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 keskittyvä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ärjestetään tarvittaessa ylimääräisiä perehdytyksiä. Ryhmän jäsenet opiskelevat itsenäisesti työkalujen ja tekniikoiden käyttöä Internetistä löytyvistä oppaista sekä ohjaajien ja tilaajan toimittamista materiaaleista. 16(37)

25 5 Käytänteet Luvussa kuvataan projektissa noudatettavia käytänteitä. Ne yhtenäistävät ryhmän toimintatapoja, siten tukevat projektin hallintaa sekä varmistavat sen aikana toteutettavan sovelluksen ja muiden tulosten laatua. 5.1 Palaverit Palavereja pidetään kerran viikossa tai kerran kahdessa viikossa tarpeen mukaan. Projektipäällikkö tekee tilavaraukset palavereille. Palaveri on laillinen, kun palaverikutsu ja esityslista on toimitettu projektiorganisaatiolle vähintään vuorokautta ennen palaveria. Palaveri on päätösvaltainen, kun palaverissa on 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ääse paikalle. Projektipäällikkö esittelee palavereissa tilakatsauksen kuvaten, mitä projektissa on tehty edellisen palaverin jälkeen ja mitä ongelmia on kohdattu. Lisäksi tilakatsauksissa esitellään viikottaiset työtunnit tehtäväkokonaisuuksittain ja viikoittain sekä koko ryhmän että yksittäisten jäsenten osalta. Palavereissa keskustellaan toteutettavan sovelluksen ominaisuuksista ja vaatimuksista sekä niiden toteutusratkaisuista. Palavereissa käsiteltävät asiat pyritään käymään läpi niin perusteellisesti, että kaikki projektiorganisaatioon kuuluvat henkilöt ymmärtävät asiat samalla tavalla, eikä väärinymmärryksiä pääse syntymään. Jos projektiryhmällä on esittää käyttöliittymästä konkreettisia hahmotelmia, ne esitetään palavereissa. Ensimmäisissä palavereissa sovitaan lisäksi projektin läpivientiin liittyvistä käytänteistä, kuten mahdollisista sopimuksista sekä dokumenteista ja niiden kielestä. Palavereissa käydään myös läpi edellisessä palaverissa sovitut toimenpiteet sekä sovitaan tulevista toimenpiteistä. Jokainen ryhmän jäsen toimii vuorollaan sihteerinä ja puheenjohtajana. Roolit kiertävät siten, että edellisen palaverin puheenjohtaja toimii seuraavan palaverin sihteerinä. Puheenjohtaja pitää huolen siitä, että palaveri etenee esityslistan osoittamalla tavalla. Sihteerin tehtävänä on laatia palaverista pöytäkirja, jonka puheenjohtaja tarkastaa ennen sen toimittamista projektiorganisaatiolle. Puheenjohtaja toimittaa jokaisen jäsenen laatiman ensimmäisen pöytäkirjan myös Santaselle ja Leinolle tarkastettavaksi ennen pöytäkirjan toimittamista projektiorganisaatiolle. Pöytäkirjaan 17(37)

26 voidaan esittää muutoksia joko etukäteen tai seuraavassa palaverissa, jossa pöytäkirja käydään läpi. Palavereissa pöytäkirja voidaan 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ä vastaa ensisijaisesti projektipäällikkö. Jokainen ryhmän jäsen on kuitenkin vastuussa hänelle osoitettuun tehtävään, tulokseen tai muuhun vastuualueeseen liittyvästä tiedotuksesta. Kun projektissa on päästy perehtymisvaiheesta varsinaiseen sovelluksen kehitykseen, toimittaa projektipäällikkö 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ä. Ryhmän jäsenten keskinäinen tiedotus hoidetaan pääosin kasvotusten, koska kaikki ryhmän jäsenet työskentelevät suurimmaksi osaksi samassa tilassa. Jos suullinen tiedotus ei ole mahdollista, hoidetaan yhteydenpito sähköpostitse. Periaatteena on, että vapaa-ajalla ei tarvitse projektia miettiä, joten puhelimen ja pikaviestinten käyttöä pyritään välttämään, ellei asiasta erikseen sovita. Ohjaajille ja tilaajan edustajalle suunnattu tiedotus hoidetaan ensisijaisesti yhteisen sähköpostilistan kautta. Sähköpostilistan osoite on ja sen jakelulistalle kuuluvat kaikki projektiorganisaation edustajat. Kaikki listalle lähetetyt viestit tallennetaan sähköpostiarkistoon, joka on nähtävillä osoitteessa Projektiryhmän jäsenten ja ohjaajien käytössä on myös toinen sähköpostilista Sen sähköpostiarkisto sijaitsee osoitteessa hoksotin_opetus/. 18(37)

27 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 nimetään kirjaamalla järjestyksessä projektin nimi, dokumentin nimi ja dokumentin versionumero, esimerkiksi HoksotinProjektisuunnitelma0.3.0.pdf. Versionumerointia kuvataan tarkemmin luvussa 5.6. Projektin tulokset tallennetaan 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 source_code testaus testausraportit testaussuunnitelma 19(37)

28 5.4 Lähdekoodi Lähdekoodi kirjoitetaan vastaamaan yleisiä Pythonin käytänteitä [10] ja PyDocin mukaisia käytänteitä [11]. Lähdekoodissa käytetyt aliohjelmat, luokat ja muuttujat nimetään mahdollisimman kuvaavilla englanninkielisillä nimillä. Myös lähdekoodin kommentointi tapahtuu 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. """ if isinstance(raw, mne.fiff.raw.raw): self._raw = raw self._info = dict(raw.info) else: raise TypeError( Not a Raw object. ) 20(37)

29 @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 varmistetaan yksikkö- ja järjestelmätestauksella. Testauksen tarkoituksena on löytää lähdekoodista virheitä sekä varmistaa, että sovellus toimii suunnitellusti ja täyttää sille asetetut toiminnalliset sekä laadulliset vaatimukset. Lähdekoodin yksikkötestaus on lähdekoodin kirjoittajan vastuulla. Yksikkötestauksessa hän varmistaa, että hänen kirjoittamansa koodi toimii suunnitellusti. Yksikkötestaus suoritetaan lähdekoodin kirjoittamisen yhteydessä. Järjestelmätestauksesta vastuussa oleva henkilö laatii testauksen suorittamiseksi testaussuunnitelman. Testaussuunnitelma sisältää kullakin testauskerralla suoritettavat testitapaukset vaihe vaiheelta. Järjestelmätestauskerran suorittanut henkilö laatii siitä testausraportin, jossa kuvataan testauskerroilla suoritettujen testitapausten tulokset sekä havaitut virheet ja puutteet. Järjestelmätestauksessa käytettävä mittausaineisto saadaan tilaajalta. Järjestelmätestaus pyritään suorittamaan kaksi kertaa projektin aikana. Sovelluksen käytettävyyteen kiinnitetään huomiota kaikkien kehitysvaiheiden aikana. Varsinaista käytettävyystestausta ei kuitenkaan projektissa suoriteta, mutta mahdolliset kriittiset puutteet ja epäloogisuudet kirjataan ylös viimeistään esiteltäessä sovellusta tilaajalle ja ohjaajille. 21(37)

30 5.6 Versiohallinta ja -numerointi Tulosten versiohallintaan käytetään Git-versiohallintaohjelmistoa. Sovelluksen lähdekoodi sijoitetaan Git-pohjaiseen YouSource-julkistusjärjestelmään, josta se on koko ajan myös ohjaajien saatavilla. Julkistetuissa dokumenttien ja sovelluksen lähdekoodien versioissa tullaan käyttämään kolmiportaista versionumerointia. Ryhmän sisäiset versiot aloitetaan versionumerosta 0.0.1, ja kunkin uuden version osalta kasvatetaan vähiten merkitsevää numeroa yhdellä. Tällöin toinen versio on versionumeroltaan Projektiorganisaatiolle julkistettavien versioiden numerointi aloitetaan versionumerosta Seuraavat versiot numeroidaan kasvattamalla toisen tason numeroa yhdellä. Ensimmäisen hyväksytyn version numero on 1.0.0, ja sitä seuraavissa hyväksytyissä versioissa kasvatetaan 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. 5.8 Tulosten koostaminen ja julkaisu Projektiryhmä kokoaa projektin tulokset sekä erilliseen projektikansioon että CDlevylle. Projektikansioon kerätään kaikki projektissa laaditut dokumentit ja lähdekoodilistaukset. Lisäksi sähköpostiarkistot ja jäsenten itsearvioinnit liitetään projek- 22(37)

31 tikansioon ja CD-levylle. CD-levylle tallennetaan edellisten lisäksi myös kehitetty sovellus. CD-levy koostetaan vasta, kun kaikki projektin tulokset on hyväksytty. Tulokset toimitetaan tilaajalle CD-levyllä. Laitokselle toimitetaan projektikansio kera projekti- CD:n. Toinen CD-levy toimitetaan laitoksen arkistoon. Projektikansio sijoitetaan projektitilan kokoushuoneessa olevaan kirjahyllyyn. 23(37)

32 6 Projektin tehtävät ja niiden jakautuminen Luvussa esitellään projektin oleellisimpien tulosten vastuuhenkilöt, tehtäväkokonaisuudet ja tehtävät sekä arvioidaan jäsenten työmäärä tehtävittäin. 6.1 Projektipäällikkö ja varapäällikkö Projektipäällikkönä toimii Atte Rautio ja varapäällikkönä Jaakko Leppäkangas. Projektipäällikön tehtäviin kuuluu 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ö on vastuussa myös projektisuunnitelman ja - raportin laatimisesta. Varapäällikön tehtävänä on 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 toteuta tulosta, mutta vastaa sen valmistumisesta, tarkastettavaksi toimittamisesta ja mahdollisista vaadituista muokkauksista. Myös tiedottaminen kyseisen tuloksen valmistumisesta kuuluu siitä vastaavan henkilön tehtäviin. 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. 24(37)

33 Taulukossa 6.1 lueteltujen tulosten ohella Kari Aliranta vastaa erilaisten sovelluksen käyttöön liittyvien ohjeiden kirjoittamisesta. Hän kokoaa myös ryhmän jäsenille tarkoitettuja ohjeita työkaluihin ja niiden asennukseen liittyen. 6.3 Tehtävät ja työmäärät Projektiryhmän jäsenet ovat 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ä. 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 on kuitenkin hankala arvioida etukäteen ryhmän jäsenten vähäisen projektityöskentelykokemuksen vuoksi, joten joillekin tehtäville arvioidut työmäärät tulevat todennäköisesti ylittymään. Jos tuntiarviot ylittyvät huomattavasti, tulee arvioida, joudutaanko joitain suunniteltuja ominaisuuksia sopimaan projektin jälkeiseen jatkokehitykseen. 25(37)

34 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 työtunnit.

35 7 Prosessimalli ja aikataulu Luvussa käsitellään projektissa noudatettavaa prosessimallia ja suunniteltua aikataulua. 7.1 Prosessimalli Projektissa ei varsinaisesti käytetä mitään tiettyä prosessimallia. Projekti läpiviedään ketterällä räätälöidyllä prosessimallilla, jossa sovellusta kehitetään ensisijaisesti inkrementaalisesti ja toissijaisesti iteratiivisesti läpi koko projektin elinkaaren. Projekti on jaettu vaiheisiin siten, että vaiheen vaihtumisen kohdalla pidetään projektipalaveri. Täten pystytään luontevasti esittelemään tilaajan edustajalle, mitä ollaan kussakin vaiheessa saatu aikaan. Vaiheet kestävät kahdesta kolmeen viikkoa. Projektin kahdessa ensimmäisessä vaiheessa keskitytään aihealueeseen ja työkaluihin tutustumiseen sekä projektin läpiviennin ja sovelluksen kokonaisrakenteen suunnitteluun. Varsinainen ohjelmistokehitys tapahtuu vaiheissa kolme, neljä ja viisi. Viimeinen vaihe varataan 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. Seuraavan parin viikon aikana suunnitteluvaiheessa tutustuttiin työkaluihin tarkemmin ja alettiin hahmotella sovelluksen kokonaisrakennetta. Varsinainen ohjelmistokehitys tapahtuu maaliskuun alun ja huhtikuun lopun välisenä aikana kolmessa kehitysvaiheessa. Maaliskuussa laaditaan Projektisuunnitelma sekä alustava Vaatimusmäärittely. Toukokuu on varattu tulosten viimeistelylle. Sovellus- ja 27(37)

36 projektiraportti aloitetaan jo huhtikuussa ja pyritään saamaan valmiiksi toukokuun puoleen väliin mennessä. 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. Projektin tulokset luovutetaan tilaajalle toukokuun loppuun mennessä. 28(37)

37 Kuva 7.1: Projektin suunniteltu aikataulu.

38 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 ja haittavaikutukset on esitetty taulukossa 8.1. Riskien todennäköisyyksiä ja vaikutuksia on arvioitu kolmiportaisella asteikolla pieni, keskinkertainen ja suuri. Riski Arvioitu todennäköisyys Arvioitu haittavaikutus Projektiorganisaatioon ja sidosryhmiin suuri keskinkertainen kuuluvien toiminnan viiveet Projektin aiheen haastavuus suuri keskinkertainen Vaikeudet valmiiden komponenttien suuri keskinkertainen käytössä Puutteet projektiryhmän tietotaidoissa keskinkertainen keskinkertainen Toteutettavien ominaisuuksien tarkentaminen keskinkertainen keskinkertainen ja rajaus Jäsenten odottamattomat poissaolot pieni suuri Projektin hallinnan puutteet pieni keskinkertainen Taulukko 8.1: Riskien todennäköisyydet ja haittavaikutukset. Taulukon riskien vaikutusta projektin läpivientiin ja tuloksiin sekä riskien ehkäisyä ja vaikutusten minimointia on kuvattu luvuissa Projektiorganisaatioon ja sidosryhmiin kuuluvien toiminnan viiveet Sidosryhmiin kuuluvien toiminnan viiveillä tarkoitetaan projektiorganisaatioon tai esimerkiksi ATK-lähitukeen kuuluvien henkilöiden toimenpiteiden viivästymistä. 30(37)

39 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. 8.4 Vaikeudet valmiiden ohjelmakomponenttien käytössä Sovelluksessa hyödynnetään paljon valmiita aivotutkimusdatan esikäsittelyyn, analyysiin ja kuvantamiseen kehitettyjä ohjelmia. Ne ovat kuitenkin suunniteltu aivo- 31(37)

40 tutkimusalan ammattilaisten käytettäviksi, joten maallikon voi olla vaikea ymmärtää, miten niitä käytetään ja mitkä toiminnot ovat olennaisimpia. Tämä voi johtaa siihen, ettei sovellukseen osata sijoittaa oikeita toimintoja oikeisiin paikkoihin. Riskin ehkäisemiseksi ryhmälle on nimetty tekninen ohjaaja, jonka apuun voi turvautua ongelmatilanteissa. Jos tekninen ohjaaja ei osaa auttaa jonkin ongelman kanssa, voidaan ottaa yhteyttä tilaajan tekniseen asiantuntijaan. Riskin toteutuminen voi johtaa projektin aikataulun viivästymiseen. Ryhmän tekninen ohjaaja on kuitenkin lupautunut tulemaan tarvittaessa paikalle seuraamaan ryhmän työskentelua ja antamaan henkilökohtaista opastusta, jotta ongelmakohdat saadaan selvitettyä. Tarvittaessa voidaan turvautua myös tilaajan teknisen asiantuntijan apuun. 8.5 Puutteet projektiryhmän tietotaidoissa Koska projektiryhmän jäsenillä on korkeintaan hyvin vähän kokemusta käytettävistä työkaluista sekä ohjelmistoprojekteista yleensä, tulee projektin aikana todennäköisesti vastaan tilanteita, joita ryhmän jäsenet eivät osaa itse ratkaista. Tällainen tilanne voi koskea esimerkiksi sovelluksen toteutusratkaisuja tai työkalujen käyttöä. Riskin toteutuessa projektiryhmä joutuu käyttämään työaikaansa ongelmien selvittämiseen, jolloin projektin eteneminen hidastuu ja sovelluksen toteutuksesta joudutaan karsimaan työtunteja pois. Tällöin saatetaan joutua luopumaan joistain suunnitelluista toiminnallisuuksista. Riskin ehkäisemiseksi on pyritty varaamaan riittävästi aikaa työkaluihin tutustumiseen. Ryhmälle on osoitettu tekninen ja vastaava ohjaaja, jotka voivat auttaa ongelmien ratkaisemisessa. Lisäksi tilaajan edustajalta ja tekniseltä asiantuntijalta voi pyytää neuvoa tarvittaessa. Riskin ennakoinnissa auttavat säännöllisesti pidettävät palaverit ja tiivis yhteydenpito projektiorganisaation sisällä. Hyvä yhteydenpito takaa, että ongelmiin osataan puuttua mahdollisimman ajoissa. Riskin toteutuessa projektiryhmän tulee ottaa yhteyttä ohjaajiin ja tilaajan edustajiin projektiorganisaation sähköpostilistan kautta. Jos asia ei ratkea, tulee tehtävästä keskustella asiakkaan kanssa perusteellisemmin ja arvioida, voidaanko tehtävä rajata projektin ulkopuolelle tai siirtää projektin myöhempään vaiheeseen. Kevään 32(37)