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ä: 34 Tiedosto: HoksotinProjektisuunnitelma0.3.0.tex Tiivistelmä: Hoksotin-projektissa toteutetaan käyttöliittymä MEG-mittauslaitteella mitatun aivosignaalidatan esikäsittelyyn, analyysiin ja kuvantamiseen. Projektisuunnitelma kuvaa Hoksotin-projektin suunnitellun läpiviennin. Projektisuunnitelmassa kuvataan projektin tavoitteet, resurssit,käytänteet, aikataulu, tehtävät ja niiden jakautuminen ryhmän jäsenten kesken 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, Johdanto kirjoitettu ja luku 3 aloitettu Luvut 3 sekä 4 on pääosin kirjoitettu, termejä sekä AR lähteitä lisätty ja lukua 5 kirjoitettu pidem- mälle Työtuntisuunnitelman pohja luotu. AR Johdantoa, termejä ja lukua 3 on muokattu. AR Lukuja 3 ja 4 on korjattu sekä aikataulun ganttkaavio AR lisätty Kaikki luvut on kirjoitettu ja suunnitelma toimitettu projektiorganisaatiolle tarkistettavaksi. 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 Projektin WWW-levyn 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 Sidosryhmien toiminnan viiveet Puutteet projektiryhmän tietotaidoissa Jäsenten odottamattomat poissaolot Projektin hallinnan puutteet Vaikeudet valmiiden ohjelmakomponenttien käytössä Puutteet toteutettavien ominaisuuksien rajauksessa Projektin aiheen haastavuus Yhteenveto Lähteet 33 vi

9 1 Johdanto Jyväskylän monitietoinen aivotutkimuskeskus perustettiin vuonna 2012 ja se sijoitettiin Jyväskylän yliopiston yhteiskuntatieteelliseen tiedekuntaan. Erityisesti keskus aikoo keskittyä 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 käsittelyn ja analysoinnin aikana käyttämään useita eri ohjelmia sekä lataamaan ja tallentamaan tiedostoja tarpeettoman paljon. Hoksotin-projekti toteuttaa käyttöliittymän MEG-mittausdatan käsittelyyn ja analysointiin. 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, jolloin käyttäjän tarvitsee vain päättää, mitä arvoja millekin parametrille annetaan. Projektille varattu aika on sen verran lyhyt, että tuotantoversiota sovelluksesta tuskin ehditään toteuttamaan. Sovellus tulee olemaan olennaisimmat toiminnot sisältävä prototyyppi ja se toteutetaan niin, että se on helposti laajennettavissa. Projektisuunnitelma kuvaa yksityiskohtaisesti projektin suunniteltua läpivientiä ja määrittelee sille asetetut tavoitteet. 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 henkilökohtaisista työmääristä ja projektin kokonaisaikataulusta. Projektisuunnitelma on laadittu hyödyntäen Kuvatusprojektin projektisuunnitelmaa [4], koska Kuvatus-projektin aihe oli samantapainen Hoksottimen aiheen kanssa. Projektiryhmä laatii projektisuunnitelman lisäksi muita projektia ja kehitettävää sovellusta kuvaavia dokumentteja. Sovelluksen tekniset ja käyttöön liittyvät vaati- 1(34)

10 mukset kuvataan vaatimusmäärittelyssä. Sovelluksen teknistä toteutusta kuvaavassa sovellusraportissa kuvataan yleisellä tasolla sovelluksen ohjelmakoodin toteutusratkaisut sekä mahdolliset havaitut ongelmat 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, projektin tavoitteet sekä 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 jq tehtävät, tulosten vastuuhenkilöt, sekä arvioidaan jäsenten työmääriä tehtävittäin. Luvussa 7 esitellään projektin aikana noudatettavaa prosessimallia, sekä projektin suunniteltua aikataulua. Luvussa 8 käsitellään projektiin liittyvät riskit ja niiden hallintaa. 2(34)

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 (epoch) Esikäsittely MEG MEG-kanava SQUID on aivojen ulkopuolisen toiminnan aiheuttama häiriö MEGsignaalissa. Artefaktoja ovat 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. on MEG-mittausdatasta jonkin ulkopuolisen ärsykkeen kohdalta irrotettu ajanhetki, josta näkee ärsykkeestä aiheutuneen aktivaation. Yleensä epookit rajataan alkamaan 2 ms ennen ärsykettä ja päättymään 100 ms ärsykkeen jälkeen. on ylimääräisten häiriöiden poistamista MEG-mittausdatasta. eli magnetoenkefalografia on menetelmä, jolla aivojen toimintaa tutkitaan mittaamalla aivojen sähköisen toiminnan aiheuttamaa magneettikenttää. 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. 3(34)

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 MEGdatan esikäsittelyssä. 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 eri plug-inien kautta. eli Enthought Python Distribution on kirjastokokoelma, josta löytyy työkaluja datan analysointiin ja visualisointiin [3]. sisältää useita ohjelmistotuotantoprojektin 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(34)

13 MNE PyDoc Python YouSource on MEG-datan ja EEG-datan käsittelyyn tarkoitettu ohjelmistopaketti [7]. on työkalu Pythonilla kirjoitettujen ohjelmien luokkadokumentaation generointiin. on avoimen lähdekoodin lisenssin alainen olioohjelmointikieli [6]. on Verso-projektissa kehitetty lähdekoodien julkaisujärjestelmä, jota käytetään projektissa laaditun lähdekoodin versiohallintaan ja tarkkailuun. [9] 5(34)

14 3 Projektin tavoitteet Luvussa Esitellään 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 MEG on aivojen toiminnan analysoinnissa käytetty menetelmä, jossa aivojen toimintaa tutkitaan mittaamalla aivojen sähköisen toiminnan aiheuttamien magneettikenttien muutoksia ajassa. MEG:lla voidaan tutkia muun muassa miten aktivaatio etenee 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]. Kuva 3.1: MEG-mittauslaite Ennen kuin MEG-mittauslaitteella 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. 6(34)

15 Varsinaisen 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 muutoksia riippuen analysointimenetelmästä. Analyysiä voidaan tehdä joko sensoritasolla, jolloin tutkitaan yksittäisten sensorien mittaamaa signaalia, tai lähdetasolla, jolloin mitataan aivojen eri kohdista lähtenyttä signaalia. Siirryttäessä sensoritasolta lähdetasolle, pitää datalle tehdä omat muunnoksensa. 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 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 tehdä yhden käyttöliittymän avulla niin, että eri vaiheiden suorittaminen ja parametrien syöttö 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 ja analyysiin. Kehitettävän sovelluksen tulee yhdistää MNE-ohjelmisto ja MaxFilterohjelmisto yhden käyttöliittymän alle. Sovelluksen tulee toimia Linuxissa. Koska sovelluksen käyttäjät ovat pääosin tutkijoita ja opiskelijoita, joilla ei voi olettaa olevan paljoa tietoteknistä osaamista, on sovelluksen helppokäyttöisyys erittäin tärkeässä asemassa. Sovelluksessa tulee pystyä kutsumaan valmiiden ohjelmistojen eri toimintoja ja syöttämään toiminnoille parametreja ilman, että joudutaan tekemään monimutkaisia komentorivikomentoja tai skriptejä. Sovelluksen tulee tallentaa loki mittausdatalle tehdyistä toimenpiteistä, ja niissä käytetyistä parametrien arvoista. Käyttäjän pitää pystyä halutessaan tekemään eri mittausdatoille samat toiminnot samoilla parametreilla ilman, että parametrit joudutaan syöttämään joka kerta uudelleen. Lisäksi pitää päästä halutessaan takaisin aiempiin vaiheisiin, eli datan tila pitää tallentua joka vaiheen jälkeen. 7(34)

16 Käyttäjän tulee pystyä näkemään kuvaaja datasta eri vaiheiden välillä, jotta hän pystyy tarkistamaan, että käytetty menetelmä ja sille annetut parametrien arvot ovat johtaneet toivottuun tulokseen. Datan analyysiin pitää pystyä poimimaan arvoja suoraan kuvaajista. Esimerkiksi voidaan valita, mitä kanavia käsittelyyn otetaan ja mitä jätetään pois. Sovellus 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 ratkaisu myös Hoksotin-projektissa toteutettavan sovelluksen ohjelmoinnissa. Käyttöliittymän suunnittelu tehdään PyQT:lla. 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. 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 huhti-toukokuun vaihteessa. 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. 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ä. 8(34)

17 - 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. - Oheiskurssin 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 puutteet ja jatkokehitysideat. - Sähköpostiarkisto sisältää kaikki projektiorganisaation sähköpostilistalle lähetetyt viestit. - Vaatimusmäärittely kuvaa sovelluksen tavoitteet, tekniset ja toiminnalliset vaatimukset sekä rajoitteet. Kaikki projektidokumentit sijoitetaan... -lisenssin alaisuuteen. Kaikki projektin aikana 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 9(34)

18 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ä taitoja, 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 tai 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 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 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. 10(34)

19 - 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 vastuusta. 11(34)

20 4 Projektin resurssit Luvussa käsitellään projektiorganisaatioon kuuluvien henkilöiden lisäksi muita projektin käytössä olevia resursseja, kuten työtiloja, laitteita ja työkaluja. 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 työkokemusta hänellä on kesältä 2012, jolloin hän oli harjoittelijana Jyväskylän yliopiston viestintäpalveluissa. Jaakko Leppäkankaalla 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 3 vuotta ja aikoo suorittaa kandidaatintutkinnon syksyllä 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-tuessa 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ä. 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 monitoi- 12(34)

21 milaite, 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ä sovellusprojektissa käytetään 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. Muiden dokumenttien kuten pöytäkirjojen ja muistioiden laatimiseen ryhmän jäsenet käyttävät kulloiseenkin tilanteeseen parhaaksi katsomaansa tekstinkäsittelyohjelmistoa. Toteutettavan sovelluksen vaatimusten suunnittelu ja määrittely tehdään Freemindilla ja Geditillä. 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. 13(34)

22 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ä taitoja. 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- ja loppuesittelyt (Leino ja Santanen). Näiden lisäksi ja näihin liittyen järjestetään tarvittaessa ylimääräisiä perehdytyksiä. Ryhmän jäsenet opiskelevat myös työkalujen ja tekniikoiden käyttöä itsenäisesti Internetistä löytyvistä oppaista sekä ohjaajien ja tilaajan toimittamista materiaaleista. 14(34)

23 5 Käytänteet Luvussa kuvataan projektissa noudatettavia käytänteitä. Ne yhtenäistävät ryhmän toimintatapoja sekä siten tukevat projektin hallintaa ja 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. Ryhmä toimittaa kunkin palaverin esityslistan projektiorganisaatiolle vähintään vuorokautta ennen palaveria. Projektipäällikkö esittelee palavereissa tilakatsauksen kuvaten, mitä projektissa on tehty edellisen palaverin jälkeen ja mitä ongelmia on kohdattu. Lisäksi tilakatsauksissa esitellään projektiryhmän käyttämät viikottaiset työtunnit sekä koko ryhmän että yksittäisten jäsenten osalta. Ryhmän työtunnit jaotellaan tehtäväkokonaisuuksiin, jotta nähdään mihin aika on käytetty. 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 ja dokumenteista, sekä niiden kielestä. Palavereissa sovitaan myös tulevista toimenpiteistä sekä käydään läpi edellisessä palaverissa sovitut toimenpiteet. 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. 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 15(34)

24 tavalla. Sihteerin tehtävänä on laatia palaverista pöytäkirja, jonka puheenjohtaja tarkistaa ennen sen toimittamista projektiorganisaatiolle. Puheenjohtaja toimittaa jokaisen sihteerin laatiman ensimmäisen pöytäkirjan myös Santaselle ja Leinolle tarkistettavaksi ennen pöytäkirjan toimittamista projektiorganisaatiolle. Pöytäkirjaan voidaan esittää muutoksia joko etukäteen tai seuraavassa palaverissa, jossa pöytäkirja käydään läpi. Palavereissa pöytäkirja voidaan joko 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 liittyvistä tiedotuksesta. Kun projektissa on päästy perehtymisvaiheesta varsinaiseen toteutukseen, 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 sisäinen sähköpostilista Sen sähköpostiarkisto sijaitsee osoitteessa hoksotin_opetus/. 16(34)

25 5.3 Tiedostojen nimeäminen ja Projektin WWW-levyn 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 laittamalla ensin projektin nimi, sen jälkeen dokumentin nimi ja lopuksi dokumentin versionumero esimerkiksi HoksotinProjektisuunnitelma0.3.0.pdf. Versionumerointi esitellään tarkemmin luvussa 5.6. Projektin tulokset tallennetaan CD-levylle ja projektin WWW-hakemistoon seuraavanlaisen 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 17(34)

26 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. def find_minimum(self, sfreq, arr, tmin=0.0, tmax=sys.float_info.max): """ Returns the last minimum and its time for a 1d numpy array. Keyword arguments: sfreq -- Sampling frequency in Hz arr -- 1d numpy array tmin -- Start of the time window in milliseconds tmax -- End of the time window in milliseconds """ if sfreq <= 0: raise Exception( Sampling frequency cannot be zero. ) if arr == []: raise Exception( No data found. ) start = int(round((tmin/1000)/sfreq)) stop = int(round(tmax/sfreq))+1 twindow = arr[start:stop] time = (np.argmin(twindow)+ start) * 1000 / sfreq return np.min(twindow), time 5.5 Testaus Toteutettavan sovelluksen toiminta varmistetaan yksikkö- ja järjestelmätestauksella. Tetauksen tarkoituksena on löytää lähdekoodista virheitä ja varmistaa, että 18(34)

27 sovellus toimii suunnitellusti ja täyttää sille asetetut toiminnalliset ja laadulliset vaatimukset. Lähdekoodin yksikkötestaus on lähdekoodin kirjoittajan vastuulla. Yksikkötestauksessa hän varmistaa, että hänen kirjoittamansa koodi toimii niin kuin pitääkin. Yksikkötestaus tehdään 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 testauskerralla suoritettujen testitapausten tulokset sekä havaitut virheet ja puutteet. Järjestelmätestauksessa käytettävä mittausaineisto saadaan tilaajalta. Järjestelmätestauksia pyritään järjestämään kaksi kertaa projektin aikana. Sovelluksen käytettävyyteen kiinnitetään huomiota kaikkien kehitysvaiheiden aikana. Varsinaista käytettävyystestausta ei kuitenkaan projektin aikana järjestetä, mutta mahdolliset kriittiset puutteet ja epäloogisuudet kirjataan ylös viimeistään esiteltäessä sovellusta tilaajalle ja ohjaajille. 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 asiakkaan 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 julkistettava 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). 19(34)

28 5.7 Katselmoinnit ja tulosten hyväksyminen Projektin aikana kirjoitettava lähdekoodi tullaan katselmoimaan vähintään kaksi kertaa projektin aikana. 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 tiivistelmä projektista jäsenten itsearvioineen liitetään projektikansioon 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ä ja projektikansiossa. Laitokselle toimitetaan projektikansio kera projekti-cd:n. Toinen CD-levy toimitetaan laitoksen arkistoon. Projektikansio sijoitetaan projektitilan kokoushuoneessa olevaan kirjahyllyyn. 20(34)

29 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 vastuutehtäviin kuuluu projektin läpiviennin suunnittelu, hallinta, ajankäytön ja projektin etenemisen seuranta, tiedotus sekä ryhmän sisäisten tehtävien jakaminen. 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 poissa ollessa. 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 Vastuuhenkilö Projektisuunnitelma Atte Rautio Vaatimusmäärittely Janne Pesonen Lähdekoodin viimeistely Jaako Leppäkangas Sovellusraportti Kari Aliranta Sovelluksen kokonaisrakenngas Jaakko Leppäkan- Järjestelmätestaus Kari Aliranta Projektiraportti Atte Rautio Taulukko 6.1: Vastuualueet keskeisimpien tulosten osalta. 21(34)

30 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äsenelle 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. Henkilökohtaiseen työmäärätavoitteeseen, joka on 350 tuntia per jäsen, 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ötuntiarvio perustuu 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 rajaamaan pois. 22(34)

31 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 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 Sovelluksen rakenne Tiedostohallinta Rajapinnat Lokitiedot Asetusten tallennus raportointi visualisointi käyttöliittymä Esikäsittelynäkymä Keskiarvoistusnäkymä TFR-näkymä Lädetasonäkymä Visualisointinäkymä Yhteensä Toteutus Sovelluksen rakenne Tiedostohallinta Rajapinnat Lokitiedot Asetusten tallennus Raportointi Visualisointi käyttöliittymä Esikäsittelynäkymä Keskiarvoistusnäkymä 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 (34) Yhteensä Projektin tunnit yhteensä Oheiskurssi Kirjoitusviestintä Puheviestintä Projektiluennot Yhteensä Kaikki tunnit yhteensä

32 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 räätälöidyllä mallilla, jossa sovellusta kehitetään ensisijaisesti inkrementaalisesti ja toissijaisesti iteratiivisesti läpi koko projektin elinkaaren. Projektin ensimmäiseen vaiheeseen varataan aikaa helmikuun loppuun. Toiselle vaiheelle varataan aikaa helmikuun lopusta maaliskuun alkuun. Kolmas vaihe kestää maaliskuun loppuun, neljäs huhtikuun puoleen väliin ja viides toukokuun alkuun. Viimeiselle vaiheelle varataan aikaa toukokuun loppupuolelle asti. Projektin kahdessa ensimmäisessä vaiheessa keskitytään aihealueeseen ja työkaluihin tutustumiseen sekä projektin läpiviennin ja sovelluksen kokonaisrakenteen suunnitteluun. Varsinainen toteutus tapahtuu vaiheissa kolme, neljä ja viisi. Viimeinen vaihe varataan projektin viimeistelylle ja tulolsten 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 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 tutustuttiin työkaluihin tarkemmin ja alettiin hahmotella sovelluksen kokonaisrakennetta. Varsinainen toteutus tapahtuu maaliskuun alun ja huhtikuun lopun välisenä aikana. Maaliskuussa laaditaan Projektisuunnitelma sekä alustava Vaatimusmäärittely. Toukokuu on varattu tulosten viimeistelylle. Sovellus- ja projektiraportti aloitetaan jo huhtikuussa ja pyritään saamaan valmiiksi toukokuun puoleen väliin mennessä. 24(34)

33 Projektin tehtäväkokonaisuuksien ja tehtävien suunnitellut kestot esitellään kuvassa 7.1. Suunnitelmaan on jätetty noin kahden viikon tyhjä pelivara toukokuun loppuun mahdollisten viivästyksien takia. Projektin tulokset luovutetaan tilaajalle toukokuun loppuun mennessä. 25(34)

34 HoksotinAikataulu Gantt Kaavio Viikko 6 Viikko 7 Viikko 8 Viikko 9 Viikko 10 Viikko 11 Viikko 12 Viikko 13 Viikko 14 Viikko 15 Viikko 16 Viikko 17 Viikko 18 Viikko 19 Viikko 20 Viikko 21 Viikko 22 Nimi Projektin vaiheet Tutustumisvaihe Suunnittelu 1. toteutusvaihe 2. toteutusvaihe 3. toteutusvaihe Viimeistelyvaihe Projektin hallinta Projektisuunnitelma Projektiraportti Tulosten viimeistely Esitutkimus Aihealueeseen tutustuminen Työkaluihin tutustuminen Määrittely Suunnittelu Raportointi Suunnittelu Sovelluksen rakenne Tiedostonhallinta Rajapinnat Asetusten tallennus Lokitietojen keräys Raportointi visualisointi Käyttöliittymä Esikäsittelynäkymä Keskiarvoistusnäkymä TFR-näkymä Lähdetasonäkymä Visualisointinäkymä Toteutus Sovelluksen rakenne Tiedostohallinta Rajapinnat Asetusten tallennus Lokitietojen keräys Raportointi Visualisointi Käyttöliittymä Esikäsittelynäkymä Keskiarvoistusnäkymä TFR-näkymä Lähdetasonäkymä Visualisointinäkymä Järjestelmätestaus Suunnittelu 1. testaus 2. testaus Viimeistely Sovelluksen viimeistely Sovellusraportti Kuva 7.1: Projektin suunniteltu aikataulu. 26(34)

35 8 Riskien hallinta Luvussa käsitellään projektiin liittyviä riskejä sekä niiden toteutumisen todennäköisyyttä ja vaikutusta. 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 Sidosryhmien toiminnan viiveet Puutteet projektiryhmän tietotaidoissa Jäsenten odottamattomat poissaolot Projektin hallinnan puutteet Vaikeudet valmiiden komponenttien käytössä Puutteet toteutettavien ominaisuuksien rajauksessa Projektin aiheen haastavuus Arvioitu todennäköisyys suuri keskinkertainen pieni pieni suuri keskinkertainen suuri Arvioitu haittavaikutus keskinkertainen keskinkertainen suuri keskinkertainen keskinkertainen keskinkertainen keskinkertainen Taulukko 8.1: Riskien todennäköisyydet ja haittavaikutukset. Taulukon riskien hallintaa on kuvattu luvuissa (34)

36 8.2 Sidosryhmien toiminnan viiveet Sidosryhmien toiminnan viiveillä tarkoitetaan projektiorganisaatioon tai muuhun sidosryhmään kuuluvien henkilöiden toimenpiteiden viivästymistä. Jos esimerkiksi joudutaan odottamaan ATK-tuen reagointia palvelupyyntöihin, liikutaan tämän riskin alueella. Myös jos esimerkiksi loppuesittelyä joudutaan siirtämään 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ä sidosryhmien kanssa, ja toimenpiteistä sovitaan mahdollisimman varhain. Riskiä pyritään ehkäisemään tehokkaalla ja aktiivisella tiedotuksella. Riskin toteutuessa arvioidaan ensin, koskeeko se projektiorganisaation ulkopuolisia sidosryhmiä. jos näin on, 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 projektiorganisaation jäsenten kesken. 8.3 Puutteet projektiryhmän tietotaidoissa Koska projektiryhmän jäsenillä on korkeintaan hyvin vähän kokemusta käytettävistä työkaluista sekä ohjelmistoprojekteista, tulee projektin aikana todennäköisesti vastaan tilanteita, joita ryhmän jäsenet eivät osaa itse ratkaista. Tällainen tilanne voi koskea esimerkiksi 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 ta- 28(34)

37 kaa, 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. 8.4 Jäsenten odottamattomat poissaolot Projektiryhmän jäsenet ovat sitoutuneet tiiviiseen projektityöskentelyyn, ja projektin suorittaminen edellyttää jokaisen työpanosta. Jos joku ryhmän jäsenistä joutuu odottamattomasti olemaan poissa, saattaa se viivästyttää projektin etenemistä huomattavasti. Riskin haittavaikutusta ehkäistään sillä, että kukaan ei ole yksin vastuussa mistään olennaisesta tuloksesta. Tarvittaessa kenen tahansa tulee pystyä jatkamaan toisen aloittamaa työtä. Toteutuessaan riski edellyttää uudelleenorganisointia ryhmän sisällä varsinkin, jos ryhmän jäsenen poissaolo on huomattavan pitkä. Yhden ihmisen pienentynyt työmäärä vaikuttaa näin pienessä ryhmässä projektin läpivientiin huomattavasti. Tällöin joudutaan neuvottelemaan asiakkaan kanssa jatkotoimenpiteistä. 8.5 Projektin hallinnan puutteet Projektiryhmän jäsenillä ei ole aiempaa kokemusta sovellusprojektin suunnittelusta ja läpiviennistä. Puutteellinen projektinhallinta saattaa johtaa epäselvyyksiin työnjaossa tai ryhmähengen heikkenemiseen. Ehkäisevinä toimenpiteinä on jäsenten keskinäinen yhteydenpito ja tehtävämäärien kirjallinen arviointi. Lisäksi ryhmän vastaava ohjaaja valvoo ryhmän toimintaa ja tarvittaessa puuttuu siihen. Ryhmän jäseniä on myös kehoitettu ottamaan ohjaajaan yhteyttä vaikka ongelma tuntuisikin yksinkertaiselta. Ryhmähenkeä on jo pyritty parantamaan projektin alussa järjestetyllä keilausreissulla. Muutenkin ryhmän jäsenet pyrkivät suhtautumaan toisiinsa tasavertaisesti ja pitämään ryhmän työtilan ilmapiirin rentona. 29(34)

38 Jos havaitaan, että ryhmän työjako on epäselvä tai työilmapiiri on huono, voidaan katsoa riski toteutuneeksi. Tällöin ongelmatilanteeseen puututaan ja otetaan tarvittaessa yhteyttä vastaavaan ohjaajaan. Ryhmän jäsenten käyttämät työtunnit ja projektisuunnitelma tarkastetaan ongelmakohtien paikallistamiseksi. Jos kyse on äärimmäisen huonosta työilmapiiristä, joudutaan pohtimaan muita ratkaisuja. Tämä on kuitenkin erittäin epätodennäköistä. 8.6 Vaikeudet valmiiden ohjelmakomponenttien käytössä Sovelluksessa hyödynnetään paljon valmiita aivotutkimusdatan esikäsittelyyn ja analyysiin suunniteltuja ohjelmia. Ne ovat kuitenkin suunniteltu aivotutkimusalan 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ä. 8.7 Puutteet toteutettavien ominaisuuksien rajauksessa Koska projektin jäsenillä on hyvin vähän kokemusta sovellusprojekteista, voi toteutettavien ominaisuuksien rajauksessa tulla ongelmia, varsinkin vaatimusten priorisoinnin suhteen. Riskin vaikutus on suurempi, jos projektin aikataulu viivästyy ja joudutaan siirtämään joitain ominaisuuksia jatkokehitykseen. Riskin ehkäisemiseksi Vaatimusmäärittely pyritään kirjoittamaan alustavasti valmiiksi mahdollisimman aikaisin, ja se toimitetaan verkkoon, jotta muut projektiorganisaatioon kuuluvat voivat sitä kommentoida. Tilaajalta kysytään tarvittaessa kantaa vaatimusten prioriteeteista, ja Vaatimusmäärittelyä tarkennetaan projektin aikana. 30(34)