TIMCAN-projektin projektiraportti

Versio 1.1.0
Julkinen
18.6.2019

TIMCAN-projekti kehitti TIM-järjestelmään kevään 2019 aikana ominaisuuksia, jotka korvaavat soveltavan kielentutkimuksen keskuksen käyttämän erillisen ICAnDoiT-ohjelman. ICAnDoiT-ohjelmaa on käytetty kielen oppimisen tutkimukseen erityisesti adaptiivisen palautteen vaikutuksen arvioinnissa [1]. Kehitetyt ominaisuudet mahdollistavat adaptiivisen palautteen rakentamisen, sen antamisen oppilaalle tai koehenkilölle tehtäviä tehdessä ja oppimista kuvaavien raporttien muodostamisen tutkimustarkoituksiin. Projektiraportti kuvaa projektin toteutuneen läpiviennin ja vertaa sitä projektisuunnitelmassa [2] suunniteltuun läpivientiin.

1. Johdanto

TIMCAN-projekti kehitti Jyväskylän yliopiston informaatioteknologian tiedekunnassa kehitettyä TIM-järjestelmää paremmin soveltuvaksi soveltavan kielentutkimuksen keskuksen tutkimukseen. Heidän käytössään olleen ICAnDoiT-ohjelman jatkokehitys ja ylläpito on lopetettu. Projektissa kehitettiin TIM-järjestelmään vastaavat toiminnallisuudet kuin ICAnDoiT-ohjelmassa.

Kehitetyn sovelluksen tärkein uusi ominaisuus on adaptiivinen palaute, jossa koehenkilön tehtävän vastauksestaan saama palaute riippuu koehenkilön aiemmista vastauksista ja täten osaamistasosta. Tehtäviä varten kehitettiin uudenlaisia kysymystyyppejä TIM-järjestelmään. Tutkimusta varten on myös tärkeää saada raportti koehenkilön vastauksien kulusta ml. annetuista vastauksista ja saadusta palautteesta sekä vastaamiseen ja palautteen lukemiseen käytetystä ajasta. Lisäksi projektissa huomioitiin kehitettävien ominaisuuksien soveltuvuus myös muiden TIM-järjestelmän käyttäjien tarpeisiin.

Projektiraportti kuvaa projektin toteutuneen läpiviennin, tavoitteiden toteutumisen sekä toteuman ja suunnitelman eroja, syitä ja vaikutuksia. Projektiraportin luku 2 kuvaa dokumentissa käytetyt käsitteet. Luvussa 3 esitellään sovellusprojektin taustaa, tavoitteita ja tuloksia. Luku 4 kuvaa projektiorganisaation käytössä olleet resurssit, kuten henkilöt, tilat, työkalut ja koulutukset. Luku 5 kuvaa käytänteet, joita projektin läpiviennissä noudatettiin.

Luvussa 6 kuvataan projektin tehtäväjakoa, tehtävien työmääriä ja projektiryhmän jäsenten vastuualueet. Luku 7 kuvaa projektissa käytettyä kehitysprosessia sekä projektin suunnitellun ja toteutuneen aikataulun. Luvussa 8 kuvataan projektiin liittyviä riskejä ja niiden hallintaa. Luvussa 9 projektiryhmän jäsenet kuvaavat kokemuksiaan projektin kulusta ja kokemuksistaan.

Projektia ja sovellusta on kuvattu myös muissa dokumenteissa. Projektisuunnitelma [2] kuvaa projektin taustoja, tavoitteita, käytössä olevat resurssit, projektissa noudatettavat käytänteet, tehtäväjaon, työmäärän, aikataulun, sekä riskien hallinnan. Vaatimusmäärittelyssä [4] kuvataan vaatimukset, jotka kehitettävän sovelluksen tuli täyttää. Sovellussuunnitelmissa [18] kuvataan sovelluksen osien rakennetta ja logiikkaa. Testausdokumenteissa [10]–[16] kuvataan sovelluksen testauksen tavoitteet, testitapaukset ja testausten tulokset. Sovellusraportissa [5] kuvataan toteutetun sovelluksen käyttöliittymää ja rakennetta, tavoitteiden ja vaatimusten toteutumista sekä toteutusratkaisuja ja jatkokehitysideoita. Käyttöohjeissa [17] neuvotaan sovelluksen peruskäyttö uusille käyttäjille.

2. Käsitteet

Luvussa määritellään dokumentissa käytetyt olennaiset käsitteet.

2.1 Tausta ja kohdealue

Dokumentissa käytetään seuraavia kohdealueen käsitteitä:

• Adaptiivinen palaute on palautetta, joka riippuu koehenkilön tai oppilaan vastauksista ja aiemmasta suoritustasosta sekä muuttuu testin aikana riippuen suoriutumisesta.
• Alasvetovalikko (engl. dropdown) on kysymystyyppi, jossa avattavasta listasta voi valita vastausvaihtoehdon.
• Harjoitustehtävä (engl. practice item) on tehtäväsarjan alussa esiintyvä tehtävä, joka esittelee kunkin tehtävätyypin mekaanisen vastaamistavan.
• ICAnDoiT on tilaajalle aiemmin kehitetty ohjelma, joka mahdollistaa adaptiivisen palautteen tutkimuksen kielenoppimisessa.
• Kysymystyyppi on TIM:iin toteutettu kysymystyyppi, jota voi käyttää tehtävissä.
• Lopetusehto (engl. stopping condition) on tehtäväsarjalle määritelty ehto, jonka toteutuessa tehtäväsarjan suoritus lopetetaan ja siirrytään testin seuraavaan tehtäväsarjaan.
• Mallitehtävä (engl. sample item) on ICAnDoiT-ohjelmassa tehtäväsarjan tehtävien malli, jolle määritellään muille tehtäville yhtenäinen palaute.
• Palaute-plugin (engl. feedback plugin) on TIM:iin toteutettu liitännäinen, jossa määritellään tehtäväsarjan tehtäville palaute.
• Raahaa ja pudota (engl. drag & drop) on kysymystyyppi, jossa yhdestä kentästä siirretään hiiren avulla sanoja toiseen kenttään. Vastaus muodostuu sanojen järjestyksestä.
• Tehtävä (engl. question item) on yksittäinen tehtävä sarjassa ja perustuu mallitehtävään.
• Tehtäväsarja (engl. task) on kokoelma samanlaisia tehtäviä, jotka kaikki testaavat samaa taitoa tai sisältöä ja joilla on yhtenäinen toisistaan riippuva palaute.
• Testi (engl. test) on kokoelma tehtäväsarjoja, jonka koehenkilö tai oppilas suorittaa kerralla.
• TIM (The Interactive Material) on Jyväskylän yliopistossa kehitetty vuorovaikutteinen oppimisympäristö.
• TIM-dokumentti on yksi sivu TIM-järjestelmässä, ja sillä on oma WWW-osoite.
• TIM-lohko (engl. TIM-block) on TIM-dokumentin osio. Se on yleisesti yksi tai useampi tekstikappale tai muu yhtenäinen kokonaisuus (kuten plugin, huom. ei inline-plugin), jolla on muista erillinen muokattava merkintä.

2.2 Ohjelmointi- ja merkintäkielet

Dokumentissa käytetään seuraavia projektille olennaisia ohjelmointi- ja merkintäkieliin liittyviä käsitteitä:

• AngularJS on JavaScript-pohjainen kehys yksisivuisten sovellusten kehittämiseen.
• CSS on tyylitiedostokieli, jolla määritellään HTML:llä tehtyjen WWW-sivujen ulkoasu.
• HTML on WWW-sivujen laadintaan käytetty merkintäkieli.
• JavaScript on ohjelmointikieli, jota käytetään ensisijaisesti selainpuolen toiminnallisuuden lisäämiseen WWW-sivuille.
• jQuery on JavaScript-kirjasto, joka yksinkertaistaa selainpuolen ohjelmointia ja erityisesti dynaamisten verkkosivujen tekemistä.
• JSDoc on merkintäkieli, jolla dokumentoidaan JavaScript-lähdekoodia.
• JSON (JavaScript Object Notation) on tiedon siirtämiseen ja tallentamiseen tarkoitettu avoimen standardin merkintäkieli.
• Markdown on merkintäkieli, jota TIM-dokumentit käyttävät.
• Python on yleiskäyttöinen ohjelmointikieli, jolla TIMin palvelinpuolen toiminnallisuus on pääosin kirjoitettu.
• SCSS on CSS:ksi kääntyvä tyylitiedostokieli, jonka tarkoitus on laajentaa CSS:n ominaisuuksia.
• TypeScript on JavaScriptin laajennos, jonka ensisijainen tarkoitus on lisätä kieleen tuki tyypitykselle.
• YAML on tiedon tallentamiseen ja siirtämiseen tarkoitettu merkintäkieli, jota käytetään TIM:issä liitännäisten määrittelyyn.

2.3 Ohjelmistokehityksen käsitteet ja työkalut

Dokumentissa käytetään seuraavia työkaluihin ja ohjelmistokehitykseen liittyviä käsitteitä:

• camelCase viittaa tapaan nimetä esimerkiksi luokkia ja aliohjelmia lähdekoodissa siten, että nimen jokainen sana aloitetaan isolla kirjaimella.
• Docker on sovellus, jonka avulla ajetaan sovelluksia virtuaalisoidussa säilössä.
• Plugin tai liitännäinen on TIM-järjestelmän osa, joka lisää toiminnallisuutta dokumentteihin. Erillinen inline-plugin mahdollistaa pluginien liittämisen normaalin tekstin sekaan.
• PEP8 [3] määrittelee Python-ohjelmia kirjoittaessa suositeltuja ohjeita ja sääntöjä.
• PyCharm on erityisesti Python-ohjelmien kirjoittamiseen käytetty ohjelmointiympäristö. Sitä käytetään myös TIMin kehittämiseen.

3. Tausta ja tavoitteet

Luvussa kuvataan TIMCAN-projektin taustaa ja tavoitteita. Luvussa esitellään projektin kohdealuetta, TIM-järjestelmään toteutettuja ominaisuuksia ja projektin oppimistavoitteiden toteutumista. Lisäksi kuvataan projektissa laadittavat dokumentit.

Projektin tavoitteet toteutuivat sovelluksen ja pääpiirteittäin oppimistavoitteiden osalta. Olennaisimmat poikkemat oppimistavoitteiden suhteen liittyvät palvelinohjelmoinnin puuttumiseen. Projektin suunnitellut tulokset saatiin valmiiksi projektin aikana.

3.1 Projektin tausta ja tavoitteet

TIMCAN-projekti jatkokehitti informaatioteknologian tiedekunnan TIM-järjestelmää. Kehityksen päämääränä oli tehdä TIM-järjestelmästä sopiva soveltavan kielentutkimuksen keskuksen tarpeisiin. Keskuksen käytössä on ollut ICAnDoiT-ohjelmisto, jota ei enää jatkokehitetä eikä ylläpidetä. Projektissa ICAnDoiT-ohjelmiston olennaisimmat ominaisuudet toteutettiin TIM-järjestelmään.

Tärkein kehitetty ominaisuus on adaptiivisen palautteen antaminen. Adaptiivinen palaute ja sen vaikutus on ajankohtainen kohdealue kielen oppimisen tutkimuksessa. Adaptiivisessa palautteessa oppilaan tai koehenkilön tehtävästä saama palaute riippuu vastauksen ohella siitä, mitä hän on vastannut aiempiin tehtäviin. Tutkimustarkoituksiin tarvitaan raportti oppilaan vastauksista ja saadusta palautteesta sekä tehtävien ja palautteen lukemiseen käytetystä ajasta.

Kehitetyssä sovelluksessa jokainen testi laaditaan omaan TIM-kansioonsa. Jokainen tehtäväsarja testissä on yksi TIM-dokumentti ja kukin tehtävä on yksi TIM-lohko. Tehtävät ja koehenkilölle annettava palaute laaditaan TIM-järjestelmään projektissa kehitettyjä ominaisuuksia hyödyntäen. Testin laatiminen ja muokkaaminen on mahdollisimman suoraviivaista, käyttäen TIM:n olemassaolevia kansioiden, dokumenttien ja lohkojen luonti- ja muokkausominaisuuksia. Testin toteuttamiseksi kehitettiin uusia tehtävätyyppejä, joita ei aiemmin ollut TIM-järjestelmässä.

Projektin päämääränä oli myös TIM-järjestelmän kehittäminen. Projektissa TIM:iin kehitetyistä ominaisuuksista tehtiin mahdollisimman yleiskäyttöisiä siten, että kehitystyö hyödyttäisi myös TIM:in käyttäjiä laajemminkin, eikä ainoastaan soveltavan kielentutkimuksen keskuksen tutkimusprojekteja. Tutkijoiden ohella kehitystyössä huomioitiin myös TIM:iä käyttävät opettajat ja opiskelijat. Kehitettyjä ominaisuuksia kuvataan tarkemmin luvussa 3.2.

3.2 Tavoitteet sovelluksen osalta

TIMCAN-projektissa kehitettiin TIM-sovellusta siten, että sen avulla voitaisiin laatia testejä, joissa oppilaat tai koehenkilöt saavat vastauksiinsa adaptiivista palautetta. Kehitettävistä toiminnoista pyrittiin tekemään mahdollisimman helppo- ja yleiskäyttöisiä siten, että niistä on hyötyä myös muille TIM:in käyttäjille.

Projektin tavoitteena oli toteuttaa TIM-järjestelmään seuraavat ominaisuudet:

• Kysymystyypit alasvetovalikko (engl. dropdown) sekä raahaa ja pudota (engl. drag&drop) voi sijoittaa TIM-dokumentissä normaalin tekstin sekaan (ns. inline-plugin).

• Testiä rakennettaessa TIM-dokumenttiin voidaan

  • koostaa testi useasta tehtäväsarjasta, joille määritellään oma adaptiivinen palaute,

  • koostaa yksi tehtäväsarja useasta samanlaisesta kysymyksestä, ja

  • määritellä tehtäväsarjoille lopetusehtoja, joiden toteutuessa siirrytään seuraavaan tehtäväsarjaan tai testin loppuun.

• Testinäkymässä oppilas suorittaa testin tehtävä kerrallaan ilman testiin liittymättömiä TIM:in käyttöliittymäelementtejä. Tehtävään vastaamisen jälkeen tulee aina näkyviin palaute ennen seuraavaan tehtävään siirtymistä.

• CSV-muotoinen raportti sisältää oppilaan vastaukset ja palautteet, sekä kuinka kauan oppilas luki kutakin näkymää.

Nämä kaikki ominaisuudet toteutettiin projektin aikana. Lisäksi projektissa toteutettiin alasvetovalikon muotoiluvaihtoehtona radiovalintakysymystyyppi.

Tavoitteita ja niiden toteutumista kuvataan tarkemmin vaatimusmäärittelyssä [4] ja sovellusraportissa [5]. Vaatimusten osalta kaikki toiminnalliset vaatimukset, jotka oli priorisoitu välttämättömiksi (49 kpl), tärkeiksi (93 kpl) ja mahdollisiksi (12 kpl) toteutettiin. Yhteensä 21 vaatimusta luokiteltiin jatkokehitysideoiksi, ja niitä ei toteutettu. Kolme vaatimusta hylättiin tarpeettomina. Jatkokehitykseen sovituista vaatimuksista suurin osa liittyy testin luomiseen ja testin kulkuun.

Toimintojen helppokäyttöisyys ei täysin vastaa vaatimuksia, vaikkakin virallista mittaustapaa käytettävyydelle ei asetettu. Tämän vuoksi sovelluksen käyttöohjeisiin käytettiin suunniteltua enemmän aikaa. Eroavuus liittyy TIM:in yleisiin ominaisuuksiin, joista ei voinut poiketa yleiskäytettävyysvaatimuksen vuoksi.

3.3 Tavoitteet oppimisen osalta

Jokainen projektiryhmän jäsen oli määritellyt projektisuunnitelmassa [2] omat oppimistavoitteensa seuraavasti:

• Hanna Alatalo halusi syventää Python-osaamistaan palvelinohjelmoinnissa. Hänen tavoitteena oli myös oppia WWW-sovelluskehityksen perusteita ja harjoitella ohjelmistosuunnittelua vaatimusmäärittelyn perusteella.

• Jarkko Kuivanen halusi oppia erityisesti palvelinpuolen ohjelmointia ja Python-kielellä ohjelmointia. Myös tietokantaosaamisen kasvattaminen ja projektityöskentelyn terävöittäminen olivat tavoitteena.

• Elisa Nauha halusi oppia IT-alalle tyypillisiä projektimuotoisen työtavan käytänteitä. Hänen tavoitteena oli myös saada kokemusta käytössä olevan ohjelmiston kehittämisestä.

• Jere Ojala halusi saada kokemusta työskentelystä asiakasprojekteissa ja projektiryhmissä sekä suunnitteluvaiheista ja ohjelmointikäytänteistä. Uusiin kieliin ja tekniikoihin perehtyminen oli myös hänen tavoitteena.

• Kimmo Urtamo halusi kerätä kokemusta projektityöskentelystä oikeaan käyttöön tulevan sovelluksen kehityskaaren aikana sekä opetella käyttämään projektissa hyödynnettäviä ohjelmointikieliä ja -tekniikoita.

Oppimistavoitteet toteutuivat seuraavasti:

• Hanna Alatalo kehittyi projektityöskentelyssä, dokumentoinnissa ja käyttöliittymäohjelmoinnissa. Hän oppi TypeScriptiä ja CSS:ää sekä sai ensimmäisen kokemuksen WWW-käyttöliittymäohjelmoinnista. Tavoitteet palvelinohjelmoinnista ja Python-taitojen kehittämisestä jäivät saavuttamatta.

• Jarkko Kuivanen kehittyi projektityöskentelyssä, dokumentoinnissa ja yleisessä suunnittelussa. Projektin alussa esitetty toive Pythonin ja palvelinpuolen ohjelmoinnin kehittymisestä jäivät saavuttamatta.

• Elisa Nauha oppi projektipäällikön roolissa projektin hallintaan liittyviä taitoja. Sovelluksen kokonaiskuvan hallinta opetti myös paljon ohjelmistojen kehitystyöstä, vaikka itse ohjelmointityö jäikin haluttua pienemmäksi.

• Jere Ojala oppi kurssin aikana Python- ja TypeScript-ohjelmointikieliä. Viestinnän puolelta hän oppi, kuinka toimia puheenjohtajana ja sihteerinä kokouksissa sekä kokouksen käytänteistä yleensäkin.

• Kimmo Urtamo sai kokemusta projektityöskentelystä ja sen eri osa-alueista dokumenttien kirjoitus mukaanlukien. Hän kehitti enemmän selainpuolen toimintoja, joten hän oppi siinä käytettyjä ohjelmointikieliä ja -tekniikoita, mutta palvelinpuolen kehityksen oppiminen jäi vähemmälle työnjaosta johtuen.

Koska projektiryhmällä ei ollut aikaisempaa kokemusta sovelluksen kehityksestä projektissa, projektitoiminta ei ollut aivan kaikkien taiteen sääntöjen mukaista. Monet ryhmän jäsenet olisivat halunneet enemmän kokemusta palvelinpuolen ohjelmoinnista tai ohjelmoinnista yleisesti. Poikkeama tavoitteista johtuu projektin työnjaosta ja projektin kehitystyön luonteesta yleisesti, sillä suurin osa kehitystyöstä kohdistui selainpuolen toimintoihin.

3.4 Projektin tulokset

Projektin läpivientiä koskevat dokumentit kirjoitettiin suomen kielellä. Kehitettävää sovellusta ja sen käyttöä koskevat dokumentit kirjoitettiin englannin kielellä, jotta soveltavan kielentutkimuksen keskuksen kanssa yhteistyötä tekevät kansainväliset tutkijat voivat käyttää ohjelmaa.

Projektin läpivientiä koskevat tulokset (kirjoitetttin suomen kielellä) ovat seuraavat:

• Ajankäyttöraportti sisältää projektin jäsenten ajankäytön tehtävittäin.
• Lisenssisitoumuksella projektiryhmä sitoutui sijoittamaan projektissa kirjoittamansa lähdekoodin The MIT License -lisenssin [6] alaisuuteen, sekä projektin dokumentit ja muun materiaalin Creative Commons Attribution 4.0 International -lisenssin [7] alaisuuteen.
• Palaverien dokumentit sisältävät esityslistat ja pöytäkirjat, joissa kerrotaan palavereissa käsitellyt ja päätetyt asiat.
• Projektisuunnitelma kuvaa projektin taustoja, tavoitteita, käytössä olevat resurssit, projektin läpiviennin käytänteet, tehtäväjaon, työmääriä, aikataulua ja riskien hallintaa.
• Projektiraportti kuvaa projektin toteutuneen läpiviennin, jäsenten kokemuksia ja oppimaa, eri osa-alueiden tavoitteiden toteutumisen sekä toteutuman ja suunnitelman eroja ja syitä.
• Sähköpostiarkistot sisältävät projektin aikana projektin molemmille sähköpostilistoille lähetetyt viestit.
• Tilakatsauksissa kuvataan projektin tilaa tiettynä ajanhetkenä.
• Vaitiolosopimuksella jokainen ryhmän jäsen sitoutui pitämään kehityksen aikana nähdyt tietojärjestelmien yksittäisiin henkilöihin liitettävissä olevat tiedot ja materiaalit sekä Titus-projektin luottamukselliset materiaalit salassa.

Kehitettyä ohjelmistoa koskevat tulokset (kirjoitettiin englannin kielellä) ovat seuraavat:

• Käyttöohjeessa neuvotaan, miten kehitettyä sovellusta käytetään.
• Lähdekoodi sisältää sovellusta varten kirjoitetun ohjelmakoodin.
• Sovellusraportti kuvaa sovelluksen käyttöliittymää ja rakennetta, tavoitteiden ja vaatimusten toteutumista sekä toteutusratkaisuja ja jatkokehitysideoita.
• Sovellussuunnitelmat kuvaavat sovelluksen osien käyttöliittymää, rakennetta ja logiikkaa.
• Testaussuunnitelmat kuvaavat, miten sovelluksen ominaisuuksia aiotaan testata ja miten testauskerrat suoritetaan.
  
• Testausraportit käsittelevät testauskertojen tuloksia sekä mahdollisia testauksessa havaittuja virheitä ja huomioita.
  
• Vaatimusmäärittely kuvaa ja priorisoi tiedot ja toiminnot, jotka kehitettävä sovellus tarjoaa käyttäjille.

Lisäksi kirjoitettiin suomenkielinen raportti kehitetyistä ominaisuuksista jokaisen kehitysvaiheen lopussa. Muuten projektin tulokset eivät poikkea olennaisesti suunnitelluista.

4. Resurssit

Luvussa kuvataan projektiin osallistuvia henkilöitä, projektiryhmän käytettävissä olleita tiloja, laitteita ja työkaluja. Lisäksi kuvataan projektiryhmälle järjestetyt perehdytykset ja niiden hyödyllisyys arvioidaan.

Projektiorganisaation osalta suunnitelmasta poiketen Mika Lehtinen toimi käytännössä myös teknisenä ohjaajana auttaen projektin edistymistä. Projektin tilat ja laitteet vastasivat suunniteltuja, vaikka pieniä viivästyksiä aiheuttivat yhden tietokoneen vaihtaminen projektin alussa, tulostuskiintiön muutos sekä kahvin ja kahvimaidon ajoittainen loppuminen kahvihuoneesta.

Suunniteltujen kehitys- ja dokumentointityökalujen lisäksi sovellus- ja projektisuunnitelmia varten käytettiin luvussa 4.3 mainittuja ohjelmistoja kaaviokuvien piirtämiseen sekä raahaa ja pudota -toiminnallisuutta varten tarvittiin valmiita kirjastoja. Oheiskurssin perehdytykset vastasivat suunnitelmaa ja ne koettiin hyödyllisiksi. Lisäksi jäsenet osallistuivat perehdytyksiin liittyen TIM-kehitykseen.

4.1 Projektiorganisaatio

Projektiorganisaation osalta toteuma vastasi suunnitelmaa. Projektiorganisaatio koostui projektiryhmästä, tilaajan edustajista, vastaavasta ohjaajasta, teknisestä ohjaajasta ja TIM-asiantuntijoista.

Projektiryhmään kuuluivat Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo. Sovelluksen tilaajana oli Jyväskylän yliopiston soveltavan kielentutkimuksen keskus, jonka edustajina toimivat Dmitri Leontjev ja Ari Huhta. Projektin vastaavana ohjaajana toimi Jukka-Pekka Santanen. TIM-asiantuntijoina toimivat Vesa Lappalainen ja Mika Lehtinen, joka toimi käytännössä myös teknisenä ohjaajana. Teknisenä ohjaajana toimi myös Visa Naukkarinen.

Projektin sidosryhmänä toimii Tipi-ryhmä, joka kehitti osittain samanlaisia ominaisuuksia TIM-järjestelmään. Sidosryhmänä toimivat myös projektiviestintäkurssin opettajat Hanna Kivimäki ja Kati Rantala-Lehtola. Hilkka Grahn kommentoi sovelluksen käytettävyyttä. Jyväskylän yliopiston ATK-lähituki vastasi projektiryhmän tietokoneiden ja yleisten sovellusten asentamisesta ja toimintakunnossa pitämisestä.

4.2 Tilat ja laitteet

Tilojen ja laitteiden osalta toteuma vastasi suunniteltua. Projektiryhmällä oli käytössä huone Ag C225.4. Huoneessa oli viisi tietokonetta, joissa kaikissa oli asennettuna Windows 10-käyttöjärjestelmä. Yksi tietokoneista jouduttiin heti alussa vaihtamaan uuteen, sillä sillä ei voinut ajaa virtuaalikoneita. Muita käytettävissä olevia tiloja olivat taukohuone, jonne yliopisto kustansi kahvit ja teet projektin ajaksi. Kokoushuone Ag C418.1 oli varattavissa palavereita varten.

Projektiryhmällä oli projektin ajan käytettävissään rajaton tulostuskiintiö yliopiston Print it -palveluun projektin tulosten tulostamista varten. Tulostuskiintiön uusiutuminen loppui jossain vaiheessa projektia, mutta korjattiin jäsenten huomautuksen jälkeen.

Projektille oli käytössään TIM-etäkone, johon projektiryhmä laittoi tuloksiaan muiden katseltaviksi ja kokeiltaviksi. Etäkoneen URL-osoite oli https://timdevs2.it.jyu.fi.

4.3 Kehitys- ja dokumentointityökalut

Projektissa hyödynnettiin seuraavia kehitys- ja dokumentointityökaluja:

• Projektin dokumentit laadittiin TIM-ympäristöön.
• Jäsenten työtunneista pidettiin kirjaa Excel-pohjaisella työajankirjaussovelluksella.
• Versiohallintaan käytettiin Gitiä GitLab-palvelua hyödyntäen.
• Projektiryhmän jäsenet hakivat opiskelijalisenssin PyCharm-kehitysympäristöön, jolla TIMin kehitys ja testaus tapahtuivat.

Suunniteltujen työkalujen lisäksi hyödynnettiin seuraavia työkaluja:

• Kaaviokuvia sovellussuunnitelmiin ja muihin raportteihin piirettiin draw.io-sovelluksella, joka on käytettävissä osoitteessa https://www.draw.io.
• Projektin aikataulu suunniteltiin GanttProject-ohjelmistolla, joka on saatavilla osoitteesta http://ganttproject.biz/about.
• Raahausliitännäistä kehitettiin eri kirjastoja käyttäen päätyen lopulta kahden kirjaston, Angular Drag and Drop Lists ja Mobile Drag Drop, käyttöön, joita kuvataan sovellusraportissa [5].

4.4 Perehdytykset

Projektiryhmälle järjestetyt luennot ja perehdytykset vastasivat suunnitelmaa. Sovellusprojektin rinnalla järjestettävään oheiskurssiin Sovellusprojektin hallintaa, viestintää ja työkaluja (TIES412, 1 op) sisältyivät seuraavat perehdyttävät luennot:

• Aloitusluennolla (3t) esiteltiin projektin kulkua yleisesti ja jaettiin ryhmät. Luennolla jaettu materiaali koettiin liialliseksi aivan alussa, vaikka luennolla itsessään tuli esille tarpeellista tietoa.
• Versiohallintaluento (2t) toteutui tietokoneohjauksena, ja se oli hyvä johdanto Gitin toimintaan. Itse projektissa tosin käytettiin Gitiä SmartGit-ohjelman kautta, jolloin komentorivikäyttö oli osaltaan tarpeetonta.
• Vaatimusmäärittelyluento (2t) oli hyödyllinen muuten paitsi, että ryhmän jäsenet olivat juuri käyneet vaatimusmäärittelykurssin, jossa asioita käsiteltiin syvemmin. Hyödylliseksi olisi koettu vaikka demonstraatio erilaisten työkalujen kuten Trellon käytöstä.
• Projektin suunnittelu- ja hallintaluento (4t) oli hyödyllinen varsinkin projektipäällikön näkökulmasta auttaen prosessien ja aikataulujen suunnittelussa.
• Käytettävyyspäivä (6t) koettiin hyödylliseksi varsinkin kehitettävään sovellukseen saatujen kommenttien vuoksi. Se sattui juuri oikeaan aikaan kehitysnäkökulmasta, kun sovelluksen toiminnot oli saatu suurelta osin valmiiksi, mutta käytettävyyttä ei oltu vielä ehditty miettiä.
• Tekijänoikeuksien ja sopimusten luento (3t) oli yleisesti kiinnostava.

Lisäksi projektin tekninen ohjaaja Mika Lehtinen piti projektiryhmälle kaksi kahden tunnin perehdytystä TIM-järjestelmän kehittämiseen tiistaina 12.2.2019 ja torstaina 14.2.2019. Perehdytykset koettiin tarpeellisiksi ja auttoivat pääsemään vauhtiin kehityksessä. Projektiryhmälle järjestettiin myös perehdytys TIM:in testauskäytänteistä, joka oli samoin hyödyllinen.

Kaikki projektiryhmän jäsenet osallistuivat myös XYHI004 Projektiviestintä IT-alalla -oheiskurssille, jolla perehdyttiin projektissa tarvittaviin viestintä- ja vuorovaikutustaitoihin. Kurssi tuki hyvin ryhmän sisäistä keskustelua ja mukavan ilmapiirin muodostumista.

5. Käytänteet

Luvussa kerrotaan projektissa noudatetut käytänteet liittyen tiedotukseen, palavereihin, päätöksentekoon, versiointiin, lähdekoodin ja dokumenttien kehitykseen, sekä tiedostojen ja hakemistojen nimeämiseen. Käytänteiden toteutumista verrataan myös suunniteltuihin.

Projektin käytänteet toteutuivat suurimmilta osin suunnitelman mukaan. Olennaisimmat erot tulivat testauksessa, jossa automaattitestejä laadittiin vain muutama. Lopullinen hakemistorakenne poikkeaa suunnitellusta, sillä dokumenttien nimet vaihtuivat ja suunnitelmasta poiketen kirjoitettiin ylimääräisiä raportteja.

5.1 Tiedotus

Projektiorganisaatiota varten luotiin sähköpostilista timcan@korppi.jyu.fi. Sen kautta tiedotettiin sellaisista projektin läpivientiin liittyvistä asioista, jotka olivat merkittäviä projektiryhmän lisäksi muulle organisaatiolle mukaan lukien tilaajille. Listaa käytettiin lähinnä palaverien esityslistojen ja pöytäkirjojen sekä tilakatsausten ja muiden raporttien jakamiseen. Lisäksi sähköpostilistaa käytettiin muutaman kerran tilaajan edustajien tavoittamiseen tilaajan toiveita koskevan lisätiedon kysymiseksi. Listalle lähetetyt viestit ovat nähtävissä arkistossa osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/timcan/. Jakelulistalla olevat sähköpostiosoitteet löytyvät osoitteesta https://korppi.jyu.fi/kotka/servlet/list-archive/ timcan/dist.html.

Sähköpostilista timcan_opetus@korppi.jyu.fi perustettiin projektiryhmän, ohjaajien ja TIM-asiantuntijoiden käyttöön. Listaa käytettiin sellaiseen projektiryhmän ja ohjaajien väliseen viestintään, joka ei ollut tilaajan kannalta olennaista. Esimerkiksi dokumenttien ja raporttien tarkastuksista ja ensimmäisten versioiden palautuksesta sekä lähdekoodin huomioista tiedotettiin listalla. Listalle lähetetyt viestit ovat nähtävissä arkistossa osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/timcan_opetus/. Jakelulistalla olevat sähköpostiosoitteet löytyvät osoitteesta https://korppi.jyu.fi/kotka/servlet/ list-archive/timcan_opetus/dist.html.

Projektipäällikkö laati viikoittain projektin tilakatsauksen, jossa kerrottiin lyhyesti projektin tehtävien ja sovelluksen tilasta ja etenemisestä, työtunneista sekä muutoksista edelliseen tilakatsaukseen verrattuna. Lisäksi tilakatsauksessa tuotiin esille asioita, jotka haittaavat projektiryhmän työskentelyä. Kunkin tilakatsauksen valmistumisesta tiedotettiin projektiorganisaatiota sähköpostilistalle timcan@korppi.jyu.fi. Tilakatsaukset sijoitettiin projektin TIM-kansiossa sijaitsevaan Dokumentit/Tilakatsaukset -alikansioon [8].

Projektiryhmä tiedotti projektiorganisaatiota projektin läpivientiin liittyvistä muutoksista tai toimenpiteistä, joilla oli merkitystä projektiryhmän tulosten valmistumiseen. Tiedotus tehtiin viikoittaisella tilakatsauksella ja palavereissa. Projektiryhmä tiedotti myös sellaisista kohtaamistaan ongelmista ja haasteista, joiden koettiin hidastavan projektia ja joihin muulla projektiorganisaatiolla voisi olla ratkaisu. Tarvittaessa projektiryhmä kävi kysymässä apua tai tarkennusta asioihin myös kasvotusten tilaajien edustajilta tai ohjaajilta.

Tarvittaessa TIM-kansioon luotiin myös muita dokumentteja, joissa kuvattin tarkemmin projektin tiettyjen tulosten kehitystä tai kehittämisessä kohdattuja ongelmia. Tämän tyyppinen dokumentti laadittiin esimerkiksi Lappalaisen sovellusta testatessa esiintyville huomioille. Näistä muista dokumenteista tiedotettiin joko sähköpostilistalla tai palavereissa, jolloin pöytäkirjaan kirjattiin linkki.

Ryhmän sisäinen viestintä tapahtui pääasiassa kasvotusten projektihuoneessa sekä Slack-ryhmässä. Osa ryhmän sisäisestä kommunikaatiosta hoidettiin sähköpostitse erityisesti, jos jonkin tiedon haluttiin säilyvän.

Kommunikoidessaan tilaajan edustajien ja ohjaajien kanssa projektiryhmän jäsenet lähettivät ensisijaisesti viestinsä sähköpostilistoille, jotta viestit tulivat koko projektiryhmän ja tarvittaessa myös koko projektiorganisaation tietoisuuteen. Tilaajan edustajien ja ohjaajien pyyntöihin ja kysymyksiin pyrittiin vastaamaan kahden arkipäivän sisällä. Tilaajan edustajat, ohjaajat ja TIM-asiantuntijat pyrkivät vastaavasti vastaamaan projektiryhmän pyyntöihin ja kysymyksiin kahden arkipäivän sisällä.

Tiedotus toteutui suunnitelman mukaisesti. Iso osa ryhmän sisäisestä tiedotuksesta tapahtui projektihuoneessa, sillä kaikki olivat usein läsnä. Näin Slack-ryhmäkin jäi lähinnä muistutuksia ja muuta pikaista tiedonjakoa varten. Projektiorganisaation kanssa tiedotus keskittyi myös paljolti itse palavereihin ja viikottaisiin tilakatsauksiin.

5.2 Palaverit

Projektin palaverit järjestettiin lähtökohtaisesti kaikille sopivana ajankohtana, joka päätettiin edellisen kokouksen lopussa. Helmikuussa palavereita pidettiin viikon välein, jotta tilaajan tarpeet ja haasteet saatiin selville. Myöhemmin palavereita pidettiin kahden viikon välein, sillä projektiryhmän aika meni enemmän itse toteutukseen kuin tilaajien tarpeiden selvittämiseen.

Kaikki palaverit olivat päätösvaltaisia, sillä paikalla oli vähintään yksi edustaja projektiryhmästä, yksi tilaajien edustaja ja vastaava ohjaaja. Palaverit olivat myös laillisia, silä esityslista toimitettiin projektiorganisaatiolle vähintään 24 tuntia ennen palaverin alkua.

Palavereissa valittiin projektiryhmän jäsenistä puheenjohtaja ja sihteeri. Jokaisen projektiryhmän jäsen toimi projektin aikana vähintään kerran molemmissa tehtävissä. Suunnitelmasta poiketen sihteerin sijaan puheenjohtaja laati palaverin esityslistan ja toimitti sen projektiorganisaatiolle. Puheenjohtaja ohjasi palaverin keskustelua esityslistan mukaan.

Sihteeri kirjasi muistiin palaverissa keskustellut asiat ja sovitut päätökset sekä kirjasi ne pöytäkirjaan. Pöytäkirja toimitettiin puheenjohtajalle tarkastettavaksi. Jos sihteeri oli laatinut vasta ensimmäisen pöytäkirjansa, puheenjohtaja toimitti pöytäkirjan huomioidensa kera edelleen vastaavalle ohjaajalle tarkastettavaksi. Puheenjohtajan ja mahdollisten vastaavan ohjaajan palautteiden jälkeen sihteeri teki pöytäkirjaan vaaditut korjaukset ja toimitti pöytäkirjan koko projektiorganisaatiolle. Pöytäkirjat toimitettiin lähtökohtaisesti kolmen arkipäivän sisällä, tai viimeistään seuraavan kokouksen esityslistan yhteydessä eli 24 tuntia ennen palaveriä.

Palaverit toteutuivat suunnitelman mukaan, ja niitä pidettiin yhteensä yhdeksän. Palaverit kestivät suunnitellusti vajaat kaksi tuntia. Pöytäkirjat ja esityslistat toimitettiin aikataulun mukaisesti. Projektin alussa pöytäkirjojen kirjoittamiseen meni enemmän aikaa, sillä päätöksiä tehtiin enemmän ja korjaukset menivät myös vastaavan ohjaajan kautta.

5.3 Lähdekoodi ja dokumentaatio

Lähdekoodissa noudatettiin TIM-järjestelmän kehittäjille laaditun TIMin koodikäytänteet-dokumentin [9] käytänteitä.

Python-koodissa noudatettiin PEP8-tyyliohjetta [3]. PyCharm-kehitysympäristö osasi osin muotoilla koodin PEP8:n mukaiseksi, mutta muissa tapauksissa jäsenet ottivat mallia tyyliohjeesta tai valmiista TIMin lähdekoodista. Aliohjelmiin määriteltiin parametrien ja paluuarvon tyypit.

TypeScriptin ja AngularJS:n osalta noudatettiin camelCase-nimeämistyyliä. Lähdekoodissa suosittiin AngularJS:n ominaisuuksia tavallisen JavaScriptin tai jQueryn ominaisuuksien sijaan. Esimerkiksi AJAX-pyynnöissä käytettiin AngularJS:n $http-palvelua ja funktiota getElementById vältettiin. Koodi kommentoitiin JSDocin mukaisesti. Kaikki uudet luokat, aliohjelmat ja metodit kommentoitiin. Sekä koodi että kommentit kirjoitettiin englanniksi PyCharm-kehitysympäristössä. Valmiiseen koodiin ei jätetty PyCharmin havaitsemia virheilmoituksia eikä varoituksia.

Lähdekoodi ja dokumentaatio kirjoitettiin suunnitelman mukaisesti. Virheet dokumentoinnissa ja koodissa kävivät ilmi myös teknisen ohjaajan koodikatselmoinneissa.

5.4 Lähdekoodin versiohallinta

Lähdekoodin versiohallintaan käytettiin Gitiä GitLab-alustalla. Gitin käytössä noudatettiin TIMin koodikäytänteet -dokumentissa [9] määriteltyjä käytänteitä.

Kehitys tapahtui timcan-haarassa, joka oli haara (engl. fork) angular-refactor-haarasta. Raahaus-liitännäiselle luotiin oma kehityshaara timcan-haaran pohjalta, jonka koodi liitettiin timcan-haaraan ominaisuuden ollessa valmiina yhdistettäväksi muihin. Lähdekoodi löytyy osoitteesta https://gitlab.com/Rampastring/tim.

Lähdekoodit päivitettiin testausympäristöön aina, kun projektin tavoitteissa määriteltyjä ominaisuuksia oli toteutettu tai valmiiksi toteutettuihin ominaisuuksiin oli tehty merkittäviä muutoksia, joita oli syytä testata tai demonstroida.

Lähdekoodin versiohallinnassa ei poikettu suunnitelmasta.

5.5 Dokumenttien versiointi

Dokumenttien versioinnissa käytettiin kolmiportaista numerointia. Viimeistä numeroa käytettiin ryhmän sisäiseen numerointiin, toista numeroa ryhmän ulkopuolelle (ohjaajille tai tilaajan edustajille) julkistettaviin versioihin ja ensimmäistä numeroa hyväksyttyihin versioihin.

Ryhmän sisäinen numerointi alkoi versiosta 0.0.1, ja viimeistä numeroa kasvatettiin aina yhdellä uudessa sisäisessä versiossa. Ensimmäinen vastaavalle ohjaajalle tai tilaajan edustajille julkistettu versio numeroitiin 0.1.0. Keskimmäistä numeroa kasvatettiin yhdellä aina, kun ryhmän ulkopuolelle julkistettiin uusi versio dokumentista. Ensimmäinen hyväksytty versio numeroitiin 1.0.0, ja uusien hyväksyttyjen versioiden yhteydessä kasvatettiin toista numeroa. Esimerkiksi toisen hyväksytyn version numero on 1.1.0 ja kolmannen 1.2.0.

Dokumenttien versioinnissa ei tarkoituksellisesti poikettu suunnitellusta, vaikkakin vastaava ohjaaja joutui monesti korjaamaan versionumerointia.

5.6 Testaus

Projektin aikana sovellukseen kehitettyjä toimintoja ja ominaisuuksia testattiin toiminnallisella testauksella ja käytettävyystestauksella. Automaattitestejä laadittiin vain muutama.

Sovellukseen kehitettyjä uusia toimintoja testattiin toiminnallisella testauksella. Toimintojen testaamista varten laadittiin toiminnallisuustestaussuunnitelmaan testitapaukset, joiden suorittamisella varmistettiin, että toiminnot suoriutuvat niille tarkoitetuista tehtävistä ja täyttävät vaatimukset.

Käytettävyystestauksella testattiin, onko toimintoja varten laadittu käyttöliittymä tarpeeksi helppokäyttöinen. Käytettävyystestaukseen laadittiin tehtäviä, joita suorittivat koekäyttäjinä tilaajan edustajat ja yksi ulkopuolinen henkilö, jolla ei ollut kokemusta TIM:istä eikä ICAnDoiT-ohjelmiston käytöstä.

Sekä toiminnallista testausta [10] että käytettävyystestausta [11] varten laadittiin erilliset testaussuunnitelmat, joissa kuvattiin testauskerran läpivienti, testitapaukset ja tehtävät. Testauskerran jälkeen laadittiin testausraportit, joissa kuvattiin testauskerralla suoritettujen testitapausten ja tehtävien johtopäätökset ja huomiot. Raporttiin kirjattiin myös mahdolliset suorittamatta jääneet testitapaukset ja tehtävät sekä syyt sille, miksei joitain testitapausta tai tehtävää suoritettu. Lisäksi mahdolliset virheiden korjausehdotukset kirjattiin raporttiin.

Toiminnallinen testaus suoritettiin kaksi kertaa sovelluksen kehityksen loppuvaiheessa. Käytettävyystestaus suoritettiin viimeistelyvaiheen alussa, kun uusia toimintoja varten oli luotu vaatimukset täyttävä käyttöliittymä ja käyttöohjeet.

Ensimmäisessä toiminnallisuustestaksessa [12] havaittiin virheitä, joiden takia testauskerta suoritettiin uudelleen virheidenkorjauksen jälkeen. Toisella kerralla itse sovelluksessa ei havaittu virheitä [13]. Virheitä havaittiin ainoastaan itse toiminnallisuustestauksen suunnitelmasta.

Käytettävyystestausta suoritettiin kolme testauskertaa, joiden tulokset on esitetty käytettävyystestausraporteissa [14–16]. Käytettävyystestauksen myötä havaittiin kolme selvästi virheellistä toiminnallisuutta, jotka korjattiin välittömästi testauksen jälkeen. Käytettävyystestauksen avulla sovellukselle muodostettiin parannusehdotuksia, joiden sisältö koski pääasiassa tehtäväsarjan luomiseen tarkoitettujen valmiiden templaattien ja käyttöohjeiden kehittämistä.

Testauksessa laadittiin suunniteltua vähemmän yksikkö-, automaatti-, ja selaintestejä. Osaltaan tämä johtuu ominaisuuksista itsestään, joita on vaikea testata. Esimerkiksi raahaa ja pudota -liitännäisen testaaminen selaintesteillä vaatisi paljon aikaa. Toiminnallisuustestaukseen käytettiin tästä johtuen enemmän aikaa, ja virheitä löytyikin jo itse testaussuunnitelmaa kirjoittaessa.

5.7 Päätöksenteko

Projektia koskevat päätökset tehtiin palavereissa. Palavereiden ulkopuolella ei ilmennyt tarvetta tehdä projektiin vaikuttavia päätöksiä.

Projektiryhmä päätti sisäisesti sellaiset projektin läpivientiin liittyvät asiat, jotka eivät suoraan vaikuttanneet projektin tuloksiin ja läpivientiin. Tällaisia asioita olivat esimerkiksi työnjako, vastuualueet ja ryhmän sisäiset käytänteet. Ryhmän sisäisiä asioita koskevissa ristiriitatilanteissa projektipäälliköllä oli tarvittaessa oikeus tehdä lopullinen päätös kuultuaan muita projektiryhmän jäseniä. Tälle oikeudelle ei tullut käyttöä.

Päätöksenteko vastasi suunniteltua. Projektia koskevat päätökset saatiin tehtyä palavereissa esityslistojen ja kokousten hyvällä suunnittelulla. Ryhmän sisäiset päätökset tehtiin suunnitellusti projektiryhmän sisäisissä palavereissa.

5.8 Tulosten katselmoinnit, hyväksyminen sekä luovutus

Tekninen ohjaaja katselmoi projektiryhmän kirjoittaman lähdekoodin kahdesti projektin aikana, maanantaina 8.4.2019 ja tiistaina 14.5.2019. Suurin osa huomioista liittyi dokumentoinnin tarkkuuteen, mutta myös koodin ja algoritmien parantamiseen tuli ehdotuksia. Ohjaajalle annettiin oikeudet ryhmän Git-säilöön, joten hän pystyi tarkastelemaan lähdekoodia milloin tahansa projektin aikana. Hän antoikin hyviä ehdotuksia alusta lähtien.

Lähdekoodi hyväksytettiin teknisellä ohjaajalla toisen katselmoinnin virheiden korjausten jälkeen. Toteutusratkaisut ja mahdolliset käyttöliittymäkomponentit hyväksytettiin tilaajalla ja TIM-asiantuntijoilla. Hyväksymisen jälkeen tekninen ohjaaja yhdessä projektiryhmän kanssa liitti ryhmän kirjoittaman koodin osaksi TIM-järjestelmän tuotantoversiota.

Tilaajan edustaja ja vastaava ohjaaja hyväksyivät allekirjoituksillaan projektin olennaisimmat dokumentit, kuten projektisuunnitelman, käyttöohjeet, projektiraportin, sovellusraportin, testaussuunnitelmat, testausraportit ja vaatimusmäärittelyn. Palaverien pöytäkirjat ja muut tulosdokumentit hyväksyttiin seuraavassa palaverissa tai sähköpostitse.

Projektin lopussa eri tulokset tulostettiin ja koottiin projektikansioon. Kansioon sijoitettiin tulokset sisältävä CD-levy, josta toimitettiin kopio myös informaatioteknologian tiedekunnan arkistoon. Tulokset toimitettiin myös tilaajalle CD-levyllä.

Tulosten katselmoinnit, hyväksyminen ja luovutus tehtiin suunnitelman mukaan. Tulosten hyväksymiseen meni oletettua enemmän aikaa, sillä ajankohta oli kaikilla kiireinen.

5.9 Tiedostojen ja hakemistojen nimeämiskäytänteet

Lähdekooditiedostot nimettiin englanniksi noudattaen TIMin kehityksen [9] ja käytettävän ohjelmointikielen yleisiä käytänteitä [3]. Projektin läpivientiä koskevat dokumentit laadittiin suomeksi ja kehitettävää ohjelmistoa koskevat dokumentit englanniksi. Dokumentit nimettiin tarkoituksen mukaan, esimerkiksi projektisuunnitelma. Samankaltaisissa dokumenteissa liitettiin nimeen myös alaviivan jälkeen päivämäärä siten, että ensin tuli vuosi, sitten kuukausi ja viimeisenä päivä, esimerkiksi tilakatsaus_20190218. Tiedostonimissä ei käytetty ääkkösiä ja välilyöntien sijasta käytettiin alaviivoja.

TIMin dokumenttien otsikot aloitettiin isolla kirjaimella. Vaikka esimerkiksi projektisuunnitelman tiedostonimi alkaa pienellä, niin dokumentin otsikkona on kuitenkin "Projektisuunnitelma". Mahdolliset tiedostonimissä olevat päivämäärät sisällytettiin otsikkoon etunollien kera tiedostonnimien järjestäytymisen vuoksi poiketen suunnitellusta suomalaisesta kalenterimuodosta ilman etunollia. Muuten tiedostojen ja hakemistojen nimeämiskäytänteiden osalta toteuma vastasi suunnitelmaa.

5.10 Hakemistorakenne

Projektin TIM-kansiossa sekä projektin lopussa kirjoitettavalla CD-levyllä noudatettiin seuraavaa hakemistorakennetta.

dokumentit/
    kehitysvaiheraportit/
    sovellussuunnitelmat/
    testaus/
        kaytettavyystestaus/
        toiminnallisuustestaus/
    tilakatsaukset/
    ajankaytto
    application-report-of-project-timcan
    projektiraportti-timcan
    projektisuunnitelma-timcan        
    requirement-specification-document
esittelyt/
liitteet/
oheiskurssi/
ohjeet/
    jatkokehitysohjeet/
    kayttoohjeet/
palaverit/
    esityslistat/
    poytakirjat/
        liitteet/
prototyypit/
sopimukset/    

Lisäksi CD:lle sijoitetaan seuraavat hakemistot:

lahdekoodit/
kirjeenvaihto/
sahkopostiarkistot/
    timcan/
    timcan_opetus/    
www/

Hakemistorakenteessa kauttaviiva nimen perässä merkitsee, että kyseessä on tiedoston sijaan hakemisto.

Hakemistorakenne poikkeaa hieman suunnitellusta, sillä dokumenttien nimiä muutettiin englanniksi ja esimerkiksi kirjoitettiin myös toteumaraportit kehitysvaiheiden lopussa.

6. Tehtäväkokonaisuudet, tehtävät ja tehtävänjako

Luku kuvaa projektin tehtäväkokonaisuuksia, niihin liittyviä tehtäviä ja työn määrää sekä projektiryhmän jäsenten toteutuneita vastuualueita, tehtäväjakoa ja työtunteja.

Tehtäväkokonaisuudet, tehtävät ja tehtävien jako pysyivät pääpiirteittäin suunnitelman mukaisina. Suurin muutos oli kysymystyyppien jako kahteen siten, että Alatalo oli vastuussa raahausliitännäisestä ja Urtamo alasvetovalikosta. Testinäkymän tehtäväkokonaisuus siirtyi samalla myös Urtamon vastuulle. Kirjallisten dokumenttien vastuualueet pysyivät suunniteltuina.

Tehtävien työmäärät ylittivät suunnitellut. Sovelluksen kehitykseen meni suunniteltua enemmän työtunteja kuten myös dokumentteihin. Varsinkin englanniksi kirjoitettavien dokumenttien laadinta vaati suunniteltua enemmän työtunteja. Kehitykseen ja dekumentteihin käytetyt ylimääräiset tunnit verottivat oheiskursseihin käytettyjä tunteja, jolloin niiden toteuma on suunniteltua pienempi.

6.1 Tulokset ja vastuualueet

Projektipäällikkönä toimi Elisa Nauha ja varaprojektipäällikkönä Kimmo Urtamo. Urtamo hoiti projektipäällikön tehtäviä projektin lopussa Nauhan muiden sitoumusten vuoksi. Varaprojektipäällikkö toimi myös projektipäällikön tukena koko projektin ajan. Taulukko 6.1 luettelee projektin olennaiset dokumentit sekä sovellukseen toteuttavat toiminnallisuudet ja niistä vastuussa olleet jäsenet.

Projektin vastuualueet muuttuivat hieman projektin aikana. Alatalolle suunniteltu testinäkymä oppilaalle ei ollut selvä kokonaisuus kehityksen alussa, jolloin sen kehitys aloitettiin vasta toisessa kehitysvaiheessa. Osaltaan tämän vuoksi kysymystyypit jaettiin kahtia siten, että Alatalo vastasi raahausliitännäisen kehityksestä ja Urtamo kehitti alasvetovalikkoa. Raahausliitännäisen ollessa vaativa toteuttaa, siirtyi testinäkymän teko lopulta Urtamolle. Urtamo otti myös palauteliitännäisen kehityksen itselleen, kun Kuivasen huomio siirtyi enemmän käyttöohjeisiin ja käytettävyystestaukseen.

Dokumenttien suhteen vastuualueet säilyivät suunnitelmien mukaisina, vaikka niiden laadinnassa ryhmän jäsenet auttoivat toisiaan ajan antaessa myöten. Esimerkiksi Nauha auttoi Ojalaa toiminnallisuustestauksen ja Kuivasta käytettävyystestauksen dokumenttien laadinnassa ja testauksen toteutuksessa.

6.2 Tehtävät, työmäärä ja tarkempi tehtävänjako

Luku ja kuva 6.1 kuvaavat projektin tehtäväkokonaisuudet, kokonaisuuksiin liittyvät yksittäiset tehtävät ja kunkin jäsenen ennakoidut tehtäviin käytettävät työtunnit sekä toteutuneet tunnit tehtäväkokonaisuuksittain. Osa toteutuneista tunneista on merkattu tietyille tehtäville ja osa tehtäväkokonaisuudelle yhteensä. Tämä johtuu siitä, että tuntien erottelu tehtäviin on osaltaan vaikeaa ja seurannassa ei käytetty alusta asti tarkkoja suunnitelman mukaisia tehtäviä.

Kullekin projektiryhmän jäsenelle oli suunniteltu 270 tuntia projektityötä eli yhteensä koko ryhmälle 1350 tuntia. Tämä vastaa 10 opintopistettä, jonka laajuiseen suoritukseen ryhmä tähtäsi. Suunniteltu kokonaistuntimäärä ylittyi kaikilla yksittäisillä jäsenillä jo viimeistelyvaiheen alussa viikolla 18. Viikon 17 lopussa ryhmän jäsenillä oli keskimäärin 288 tuntia kasassa. Pelivaran toisella viikolla tunteja ryhmällä oli yhteensä 1977 eli 627 tuntia arvioitua työmäärää enemmän.

Arvioitujen työtuntien ylitys vastaa noin kuutta viikkoa, sillä kukin jäsenistä oli varannut noin 20 tuntia viikossa. Sovelluksen kehitykseen lasketaan määrittely, suunnittelu, toteutus ja testaus. Näiden osalta työtunnit ylittyivät noin 300 tunnin verran, joka vastaa ryhmän kolmea projektityöviikkoa. Kokonaisuudessaan ylitys vastaa noin neljän ja puolen opintopisteen verran työtä jokaista ryhmän jäsentä kohden.

Ryhmän jäsenten yhteenlasketuissa työtunneissa on paljon vaihtelua. Eniten tunteja teki Urtamo, joka teki jopa 100 tuntia enemmän kuin pienimmän tuntimäärän tehneet Alatalo ja Nauha. Suurin osa Urtamon tunneista meni toteutukseen. Syy on osaltaan se, että koodatessa helposti menettää ajantajun, kun ratkaisee vaikeita ongelmia. Kertyvistä tunneista keskusteltiin ryhmän kesken, mutta tasaavan ratkaisun löytyminen oli haastavaa. Kaikki lähtökohtaisesti kuitenkin tekivät viikottain vähintään suunnitellun määrän tunteja. Urtamon urakointi tosin motivoi toisiakin tekemään enemmän tunteja. Alatalo ja Nauha tekivät tunteja 13 opintopisteen verran sekä eniten tunteja tehnyt Urtamo teki tunteja 17 opintopisteen verran.

Suunnitellut työtunnit ylittyivät eniten projektin hallinnan, esitutkimuksen, testauksen ja viimeistelyn tehtäväkokonaisuuksissa. Sovelluksen logiikka oli oletettua vaikeampi ja yksityiskohtia oli paljon, jolloin myös toteutuksen työmäärä oli suunniteltua suurempi. Esimerkiksi raahausliitännäisen kehitys osoittautui vaikeaksi varsinkin mobiilikäytön osalta. Palauteliitännäisessä on suurin osa sovelluksen logiikasta, joten se vaati myös yli tuplasti suunniteltua enemmän tunteja.

Viimeistelyn osalta käyttöohjeet veivät jopa kaksi kertaa suunniteltua enemmän tunteja. Tämä johtuu osittain dokumenttien kielivaatimuksesta, joka aiheutti lisätöitä.

Testauksessa kului osaltaan enemmän aikaa, koska jo suunnitelmia kirjoitettaessa havaittiin virheitä ja puutteita sovelluksen toiminnassa. Sovellusta myös kehitettiin samaan aikaan, jolloin toiminnallisuudet saattoivat vaihtua ennen testauskerran suoritusta.

Projektin hallinta vei suunniteltua enemmän tunteja todennäköisesti sisäisten palaverien vuoksi. Päivittäisistä noin 15 min palavereista kertyy jo yli tunti viikossa, joka tekee noin 20 tuntia projektin aikana kullekin jäsenelle. Lisäksi pidettiin kehitysvaiheiden alussa ja lopussa palavereita. Suurin ylitys seurannan ja hallinnan tehtäväkokonaisuudessa on projektipäällikkö Nauhalla, joka johtuu projektisuunnitelmaan ja projektiraporttiin käytetyistä tunneista. Esitutkimukseen käytetyt ylimääräiset tunnit kertovat sovelluksen aihealueen ja TIM-kehityksen uutuudesta jäsenille.

Projektin ohella tunteja kului oheiskursseihin Projektiviestintä IT-alalla ja Sovellusprojektin hallinta kultakin noin 30-45 tuntia.

6.3 Projektiryhmän työtunnit tehtäväkokonaisuuksittain

Kuva 6.2 esittää koko projektiryhmän työtunnit tehtäväkokonaisuuksittain. Eniten aikaa (19%) meni itse toteutukseen Jos toteutukseen lisää suunnittelun (12%), määrittelyn (4%) ja testauksen (10%), niin 45% ajasta kului sovelluksen kehittämiseen. Viimeistelyssä ja kokoamisessa on myös tunteja lähdekoodin viimeistelyyn, jolloin sovelluksen kehityksen osuus on käytännössä suurempi. Testaukseen kului paljon työtunteja, sillä ryhmä laati käytettävyys- ja toiminnallisuustestauksille suunnitelmat ja raportit. Nämä dokumentit olivat lisäksi englanniksi, joka vaati enemmän aikaa.

Esitutkimukseen kului paljon tunteja, sillä adaptiivisen palautteen logiikka oli yllättävän monimutkainen kokonaisuus toteuttaa TIM:iin. Osan esitutkimuksen tunneista olisi voinut kirjata sovelluksen suunnitteluun. Projektin hallinta vei noin 14% ajasta, sillä päivittäisten palaverien ohella kaikille tuli viikossa ainakin tunti tai kaksi sisäisiä palaverejä.

6.4 Hanna Alatalon työtunnit tehtäväkokonaisuuksittain

Hanna Alatalon suurin vastuualue oli raaha ja pudota -kysymystyypin toteutus. Tehtävä oli vaativa, joten tunneista yhteensä noin 49% meni ominaisuuden suunnitteluun ja toteutukseen. Seuraavaksi suurin tuntimäärä kului viimeistelyyn ja kokoamiseen, sillä Alatalo oli päävastuussa sovellusraportista. Huomattava määrä tunteja meni myös esitutkimukseen, johon sisältyy sekä aihealueeseen että TIM:iin tutustuminen. Alatalolla testaukseen meni keskimääräistä pienempi työtuntimäärä, sillä hän ei osallistunut testausdokumenttien kirjoittamiseen ja suoritti vain yhden toiminnallisuustestauskerran. Kuva 6.3 esittää Alatalon työtunnit tehtäväkokonaisuuksittain.

6.5 Jarkko Kuivasen työtunnit tehtäväkokonaisuuksittain

Jarkko Kuivasen päävastuualue oli alussa palauteliitännäisen toteutus, jonka suunnittelu oli vaativaa. Tämän tehtävän tunteja on kirjattu sekä esitutkimuksen että suunnittelun alle. Määrittelyyn ei ole erikseen merkattu tunteja, vaan ne ovat esitutkimuksen alla. Itse toteutukseen meni Jarkolta tunteja 11%, sillä Urtamo oli lopulta pääkehittäjänä palauteliitännäiselle. Kuivaselle kirjatut testauksen (21%), sekä viimeistelyn ja kokoamisen (27%) tunnit kuvastavat käytettävyystestaukseen ja käyttöohjeisiin käytettyjä tunteja. Kuva 6.4 esittää Kuivasen työtunnit tehtäväkokonaisuuksittain.

6.6 Elisa Nauhan työtunnit tehtäväkokonaisuuksittain

Elisa Nauha toimi projektin projektipäällikkönä ja tästä johtuen huomattava osa (44%) tunneista kului projektin hallintaan. Toteutuksen osalta Nauha oli mukana lähinnä testin raportin kehityksessä. Suunnitteluun ja esitutkimukseen meni paljon tunteja, sillä ryhmä pohti usein yhdessä ominaisuuksia ja niiden toteutusta. Nauhan osallistuminen sekä toiminnalliseen että käytettävyystestaukseen näkyy testauksen tunneissa. Kun sovelluksen kehitykseen luetaan määrittely, suunnittelu, toteutus, ja testaus, Nauha käytti 22% tunneistaan sovelluksen kehitykseen. Nauha käytti keskimääräistä enemmän aikaa oheiskurssiin. Tämä johtuu viestintäkurssin kirjallista tehtävistä, joiden pohtimiseen kului iltaisin tunteja. Kuva 6.5 esittää Nauhan työtunnit tehtäväkokonaisuuksittain.

6.7 Jere Ojalan työtunnit tehtäväkokonaisuuksittain

Jere Ojalan päävastuualue toteutuksessa oli testin raportti. Sen suunnitteluun ja toteutukseen meni noin 28% hänen työtunneista. Testin raportin toteutus valmistui hyvissä ajoin verrattuna muihin ominaisuuskokonaisuuksiin. Lisäksi Ojala oli vastuussa toiminnallisuustestauksesta, johon meni hänen työtunneista 20%. Suhteellisen suuri projektin hallintaan mennyt työtuntimäärä (16%) johtunee Jeren työpanoksen hyödyntämisestä erilaisissa tehtävissä, kuten kehitysvaihe- ja käytettävyysraporttien kirjoittamisessa. Ojala myös käytti keskimääräistä enemmän aikaa oheiskurssiin. Tämä johtuu viestintäkurssin kirjallisista tehtävistä, joiden kirjoittaminen oli haastavaa. Kuva 6.6 esittää Ojalan työtunnit tehtäväkokonaisuuksittain.

6.8 Kimmo Urtamon työtunnit tehtäväkokonaisuuksittain

Kimmo Urtamo oli päävastuussa alasvetovalikon ja lopulta myös palauteliitännäisen toteutuksesta. Hän hoiti myös paljolti sovelluksen kaikkien ominaisuuksien yhdistämisen toimivaksi kokonaisuudeksi. Tämä näkyy selvästi toteutukseen käytetyissä tunneissa, sillä 33% Urtamon ajasta meni toteutukseen ja 12% suunnitteluun. Määrittelyn tunnit (13%) johtuvat vaatimusmäärittelyn laatimisesta ja muokkauksesta. Kokonaisuudessa Urtamon tunneista 59% kului sovelluksen kehitykseen. Hänen testauksen osuus on huomattavasti muita pienempi, sillä Urtamo teki lähinnä automaattitestejä, jotka merkattiin toteutuksen alle. Kuva 6.7 esittää Urtamon työtunnit tehtäväkokonaisuuksittain.

7. Prosessi ja aikataulu

Luku kuvaa projektin läpiviennissä käytetyn prosessin ja projektivaiheiden aikataulun. Projekti vietiin läpi käyttäen suunniteltua prosessia. Aikataulu pysyi myös pääpiirteittäin samana, vaikkakin kehitystyöhön kului suunniteltua enemmän aikaa, jolloin projektiin loppuun jätetty pelivara otettiin käyttöön.

7.1 Prosessi

Kehitettävään sovellukseen toteuttavat toiminnallisuudet jaettiin eri tehtäviin kehitystä varten (ks. luvut 6.1 ja 6.2). Nämä tehtävät kuitenkin riippuivat paljon toisistaan, joten kehittäjien yhteistyö ja kommunikointi oli tärkeää.

Projektissa noudatettiin suunniteltua prosessimallia nuodattaen pitkälti ketterän kehityksen periaatteita. Kehitysvaiheissa toteutettiin toimivia prototyyppejä, joita inkrementaalisesti ja iteratiivisesti jatkokehittiin seuraavassa vaiheessa.

Projekti jakautui alun määrittely- ja suunnitteluvaiheeseen sekä kolmeen 3 viikon ohjelmistokehitysvaiheeseen. Näiden jälkeen viimeistelyvaiheessa viimeisteltiin tulokset ja laaditaan raportit.

Kehitysvaiheisiin valittiin ohjelmiston osioiden ominaisuuksia, joiden tuli olla valmiina vaiheen lopussa. Vaiheen sisällä työnkulku eteni seuraavasti:

1. Vaiheen alkaessa pidettiin ryhmän sisäinen palaveri (noin 1.5 h), jossa selvennettiin vaiheen kulku ja valittiin toteutettavat ominaisuudet sekä jaettiin tehtävät jäsenille.

2. Vaiheen aikana pidettiin päivittäin ryhmän sisäisiä lyhyitä palaverejä (10-15 min), joissa tarkistettiin tehtävien edistyminen ja esteet. Jos esteitä ilmeni, ne ratkaistiin uudella työjaolla tai pidemmällä keskustelulla aiheesta.

3. Vaiheen lopussa pidettiin ryhmän sisäinen palaveri, jossa kerättiin yhteen toteutetut ominaisuudet ja kirjoitettiin lyhyt raportti tuloksista. Seuraavana arkipäivänä aloitettiin taas askeleesta 1.

Viimeisen kehitysvaiheen päättyessä pidettiin vielä vaiheen aloituspalaveri, jossa selvitettiin kehitettävien ominaisuuksien viimeistelytarve. Palaverissa viimeistelyvaiheen tehtävät jaettiin ryhmän kesken.

Prosessin noudattaminen onnistui hyvin. Lyhyet ryhmän sisäiset palaverit auttoivat kaikkia tietämään tehtäväkokonaisuuksien edistymisestä ja auttoivat luomaan yhtenäisen sovelluksen. Alussa vei aikaa tottua lyhyiden palaverien pitämiseen, mutta projektin edetessä palavereja pidettiin tehokkaasti. Viimeistelyvaiheessa lyhyitä palaverejä ei enää pidetty päivittäin, mutta kehittyneen kommunikoinnin kulttuurin vuoksi etenemisestä kuitenkin keskusteltiin päivittäin.

7.2 Aikataulu

Projektin aloitusluento oli 29.1.2019. Kehitettävä sovellus oli tavoitteena saada valmiiksi huhtikuun loppuun mennessä. Suunnitelmasta poiketen testinäkymä oppilaalle -tehtävä aloitettiin vasta toisessa kehitysvaiheessa.

Toukokuussa suunniteltiin laadittavan käyttöohjeet sekä sovellus- ja projektiraportit. Lisäksi toukokuussa sovellukseen suunniteltiin tehtävän vielä pieniä korjauksia. Kehityksen osalta projektin aikataulu kävin hyvin toteen, vaikka viimeistelyvaiheen alussa kehitettiin vielä muutama uusi ominaisuus itse sovellukseen. Myös käyttöohjeiden kirjoittaminen aloitettiin suunniteltua aiemmin kolmannessa kehitysvaiheessa, kun se todettiin tarpeelliseksi testauksen suunnittelun yhteydessä.

Vaihejako onnistui hyvin ja rytmitti kehitystä. Viimeisen kehitysvaiheen tehtävät testauksen suunnittelun ja suorituksen osalta pitkittyivät viimeistelyvaiheen puolelle. Uusia tehtäviä ei suunniteltujen lisäksi tarvittu.

Viimeistelyvaiheessa dokumenttien valmistuminen viivästyi varatun pelivaran loppuun, sillä osan kirjoittaminen englanniksi vei suunniteltua enemmän aikaa. Projektille varattu reilun kahden viikon pelivara tuli käyttöön lähinnä dokumenttien osalta. Myös lähdekoodi saatiin hyväksyttäväksi vasta pelivaran aikana, sillä viimeistelyssä huomattiin vielä tarpeellisia korjauksia sovelluksen toimintaan.

Kuva 7.1 esittää projektin suunnitellun ja kuva 7.2 toteutuneen aikataulun. Projekti joutui käyttämään kokonaan varatun pelivaran. Jotkin tehtävät veivät suunniteltua enemmän kalenteriaikaa, jolloin viimeistelyvaihe jatkui varattuun pelivaraan. Projektin työmäärä oli suunniteltua suurempi varsinkin kehityksen osalta. Ryhmän jäsenet pitäytyvät keskimäärin 20 tunnin viikkotyöajassa, jolloin projekti eteni hyvää vauhtia. Oheiskurssit eivät sisältyneet työtuntilaskelmaan, vaan niille varattiin erilliset 50 tuntia kutakin jäsentä kohden (katso kuva 6.1).

7.3 Ryhmän työtunnit viikottain

Taulukko 7.1 sekä kuvat 7.3 ja 7.4 kertovat projektiryhmän jäsenten viikoittaiset työtunnit. Taulukossa 7.1 ja kuvassa 7.3 ei ole mukana oheiskurssiin käytettyjä tunteja. Kuva 7.4 kertoo ryhmän kokonaistuntimäärän, kun oheiskurssien tunnit lasketaan mukaan.

Projektiryhmä kokonaisuudessaan ylitti suunnitellun 100 yhteistunnin rajan viikoilla 7, 10-15, 17 ja 19-21. Projektin keskivaiheilla viikot 11-14 ylittivät rajan reilusti, sekä viikolla 12 jopa melkein 60 tunnilla. Keskimäärinkin ryhmä teki noin 110 tunnin viikkoja ylittäen suunnitellun työajan.

Projektin loppupuolella viikot 16 ja 18 vaikuttavat esitetyin tunnein muita huomattavasti pienemmiltä. Näillä viikoilla kuitenkin oheiskurssiin kului ryhmältä yhteensä yli 30 tuntia per viikko. Jos nämä tunnit otetaan mukaan, niin tunnit tasoittuvat viereisten viikkojen tasolle (katso kuva 7.4). Näillä viikoilla aikaa veivät väliesittelyt ja niihin valmistautuminen, sekä viimeiset oheiskurssin luennot ja kirjalliset tehtävät. Myös viikolla 5 ryhmä käytti oheiskurssiin kerkimäärin 5 tuntia jäsentä kohden, tehden ensimmäisestä viikosta kuvaajan esittämää työläämmän. Viikon 22 tunnit ovat pienemmät kuin muiden, sillä kuvaajassa on tunnit vain kolmelta päivältä.

7.4 Hanna Alatalon työtunnit viikottain

Hanna Alatalon viikottaiset työtunnit on esitetty kuvassa 7.5. Alatalon suunnitellut työtunnit toteutuivat viikoilla 6, 10-14, 17 ja 21. Viikolla 9 hänelle tuli hyvin vähän tunteja sairauden vuoksi. Viikoilla 12, 13, 17 ja 21 Alatalo teki huomattavasti suunniteltua 20 tuntia enemmän tunteja. Alatalon keskiarvollinen työtuntimäärä viikoilla 5-22 oli 19,7 tuntia.

7.5 Jarkko Kuivasen työtunnit viikottain

Jarkko Kuivasen viikottaiset työtunnit on esitetty kuvassa 7.6. Kuivasen suunnitellut työtunnit toteutuivat viikoilla 7, 11-15 ja 17-21. Myös muiden viikkojen tunnit olivat hyvin lähellä suunniteltua. Kuivasen keskimääräinen viikkotuntimäärä oli melkein 23 tuntia eli reilusti yli suunnitellun 20 tunnin.

7.6 Elisa Nauhan työtunnit viikottain

Elisa Nauhan viikottaiset työtunnit on esitetty kuvassa 7.7. Nauhan suunnitellut työtunnit toteutuivat viikoilla 7, 9, 12-15, 17, 19 ja 20. Viikolla 8 Nauha oli sairauden vuoksi poissa osan aikaa ja viikolla 21 muiden sitoumusten vuoksi. Nauhan keskiarvolliseksi työajaksi viikossa viikoilla 5-22 muodostui 19,8 tuntia.

7.7 Jere Ojalan työtunnit viikottain

Jere Ojalan viikottaiset työtunnit on esitetty kuvassa 7.8. Ojalan suunnitellut työtunnit toteutuivat viikoilla 10-15, 17 ja 19-21. Alussa Ojalan teki muita lyhyempää viikkoa, mutta viikoilla 11-13 hän teki keskimäärin 35 tuntia per viikko ja sai muut kiinni. Tämän jälkeen viikottainen työaika tasoittui, huomioiden viikot 16 ja 18, jolloin oheiskursseihin meni kaikilla paljon tunteja. Ojalan keskiarvollinen työtuntimäärä viikoilla 5-22 oli melkein 22 tuntia.

7.8 Kimmo Urtamon työtunnit viikottain

Kimmo Urtamon viikottaiset työtunnit on esitetty kuvassa 7.9. Urtamon suunnitellut työtunnit toteutuivat viikoilla 6-15, 17 ja 19-21. Urtamon keskimääräinen viikkotuntimäärä on melkein 26 tuntia eli huomattavasti yli suunnitellun 20 tunnin.

8. Riskit

Luku käsittelee projektiin liittyviä ennakoituja riskejä, niiden toteutumista, haittavaikutuksia ja hallintaa. Riskit toteutuivat arvioitua pienemmällä haittavaikutuksella johtuen riskien ennakoimisesta. Esimerkiksi poissaoloihin varauduttiin tekemällä enemmän tunteja viikoilla, joilla tämä oli kullekin mahdollista. Tilaajan ja TIM-asiantuntijoiden erilaiset tarpeet ja toiveet koettiin suurimmaksi riskiksi, ja se toteutuikin keskisuurin vaikutuksin. Kyseisen riskin toteutuminen ei viivästyttänyt projektia merkittävästi, mutta sovelluksen käytettävyys jäi haluttua huonommaksi.

8.1 Riskien todennäköisyydet ja haitat

Projektin arvioidut riskit, niiden arvioidut todennäköisyydet sekä arvioidut ja toteutuneet haittavaikutukset on esitelty taulukossa 8.1. Riskien todennäköisyyksien ja haittavaikutusten arvioinnissa käytetty asteikko on pieni, keskisuuri ja suuri.

Projektin riskit toteutuivat arvioitua lievempinä. Riskien toteutumisesta olisi voinut aiheutua enemmän haittaa, mutta niiden ennakointi ja hallinta onnistuivat hyvin. Tarkemmin kunkin riskin hallintaa käsitellään luvuissa 8.2-8.7. Projektissa ei tullut vastaan ennakoimattomia riskejä.

Taulukko 8.1. Riskien todennäköisyydet ja haittavaikutukset.

8.2 Jäsenten ennakoimattomat poissaolot

Projektiryhmän jäsenillä ei ollut tiedossa pidempiä poissaoloja projektin aikana. Poissaoloja tuli muutamien päivien pituisista noin viikon pituisiin jaksoihin pääosin muutaman jäsenen sairastumisten vuoksi.

Poissaoloista selvittiin pienin haittavaikuttuksin, sillä päivittäisten lyhyiden palaverien johdosta jäsenet olivat hyvin tietoisia toistensa tehtävien etenemisestä. Poissaolon sattuessa voitiin tehtäviä melko hyvin jakaa uudestaan tarvittaessa. Poissaolevat jäsenet myös ahkeroivat poissaolojensa jälkeen yli suunniteltujen tuntien verran, jolloin he saivat hyvin muut kiinni. Projekti ei täten viivästynyt poissaolojen takia.

8.3 Jäsenten muut sitoumukset

Projektiryhmän jäsenillä oli projektin lisäksi muita kursseja, jotka vaativat aikaa viikottain ja varsinkin jaksojen vaihtumisen yhteydessä tenttiin lukemisen osalta. Riski toteutui, mutta ennakoitua pienemmällä haittavaikutuksella. Ryhmän jäsenet priorisoivat projektin etenemisen muiden kurssien ylitse. Urtamon pro gradu -tutkielma jäi myös odottamaan projektin jälkeistä aikaa.

Jäsenten kesätyön hakeminen vei arvioitua enemmän aikaa haastattelujen takia, vaikka itse kesätyöt alkavatkin vasta kesäkuun alussa. Harrastussitoumukset vaativat myös osalta jäsenistä aikataulun järjestelyä käytettävissä olevien toimistotuntien ja pitkien viikonloppujen tapauksessa.

Varsinkin jakson vaihtuminen tentteineen muutamalla viikolla vähensi työtunteja, mutta ryhmän jäsenet saivat nämä tunnit tehtyä ennakoivasti tai kiireiden jälkeen. Täten projektin aikana tunteja kertyi melko tasaisesti, ja projekti ei viivästynyt jäsenten muiden sitoumusten takia.

8.4 Vaatimusten lisääntyminen ja muuttuminen

Projektin aikana tilaajan edustajien esittämät vaatimukset eivät juurikaan lisääntyneet, vaan enemmänkin tarkentuivat sovelluksen edistyessä. Aivan uusiakin ominaisuuksia tuli esille muutama, jotka priorisoitiin muiden mukaan ja toteutettiin ajan salliessa.

Vaatimusten lisääntyminen, muuttuminen ja tarkentuminen aiheutti jonkin verran lisää työtä, mutta ei merkittävästi. Ketterän kehityksen ansiosta muutokset pystyttiin ottamaan huomioon nopeasti.

8.5 Tilaajan ja TIM-asiantuntijoiden erilaiset tarpeet ja toiveet

Tilaajan intressinä oli ICAnDoiT-järjestelmän korvaaminen TIM-järjestelmän avulla. Tärkeänä tavoitteena oli hyvä käytettävyys, jotta tietoteknisesti kokemattomat tutkijat voivat lisätä tehtäviä ja rakentaa niille palautteen. TIM-asiantuntijat halusivat lisäksi kehittää itse TIM-järjestelmää. Palavereissa ilmeni tilaajan edustajilla ja TIM-asiantuntijoilla olevan erilaisia näkemyksiä käytettävyyden huomioimisesta ja ominaisuuksista yleisesti.

Riskin todennäköisyys ja mahdollinen haittavaikutus arvioitiin suureksi, mutta toteutunut haittavaikutus oli vain keskisuuri. Projektin alussa riskin toteutuminen aiheutti hämmennystä ryhmän jäsenissä ja hankaloitti vaatimusten priorisointia. Kehityksen edetessä riskin vaikutus pieneni, kun TIM:in asettamat rajat ja mahdollisuudet sekä kehitysyksityiskohdat selvenivät.

Ryhmän jäsenet ottivat palavereissa esille yksityiskohtiin liittyvät kysymykset, jolloin epäselvyydet saatiin ratkaistua. Projektiryhmä tiedosti aktiivisesti riskin ja keskusteli paljon käytettävyyden kehittymisestä. Monimutkaisuutta lisäävät ominaisuudet yritettiin kehittää ilman käyttäjälle ilmenevää monimutkaistumista.

Projektin osalta riski ei aiheuttanut merkittävää viivästymistä, mutta sovelluksen käyttö testin laatimiseen ei lopulta ole niin helppoa kuin tilaajien tarve vaatisi. Tämä tuli ilmi myös käytettävyystestauksessa, jossa käyttöohjeet koettiin tärkeiksi. Viimeisissä palavereissa tuli myös ilmi mahdollinen jatkokehitys palautteen kirjaamisen helpottamiseksi erillisellä käyttöliittymällä tekstin sijaan.

8.6 Kokemattomuus projektin hallinnasta

Projektipäälliköllä ja muilla ryhmän jäsenillä oli projektin alussa verrattain vähän kokemusta projektimuotoisesta työskentelystä ja ohjelmistoprojekteista. Työtuntien ja aikataulujen arviointi oli haastavaa, mutta aiempien projektien toteutumisen tutkiminen toi asiaan selvyyttä. Kokemuksen puute projektityöskentelystä arvioitiin myös vaikeuttavan ryhmän sisäistä kommunikointia ja yhteistyötä tilaajan edustajien kanssa.

Arvioitu haittavaikutus on lopulta pieni, sillä projektin hallinta onnistui hyvin. Apuna kommunikoinnissa oli projektiviestinnän kurssi, joka loi avoimen keskusteluilmapiirin ryhmän sisälle. Ryhmän sisäiset päivittäiset lyhyet palaverit auttoivat myös kaikkia ryhmän jäseniä muodostamaan kuvan projektin etenemisestä. Viikottaiset tilakatsaukset informoivat projektiorganisaatiota projektin tilasta, mutta myös pakottivat ryhmän kiinnittämään huomiota edistymiseen. Projektin hallintaan meni suunniteltua enemmän työtunteja, mutta tämä ei viivästyttänyt itse projektin etenemistä.

8.7 Kokemattomuus TIM-järjestelmästä ja työkaluista

Projektin jäsenillä oli projektin alussa rajallisesti kokemusta joistain TIM-järjestelmässä käytetyistä ohjelmointikielistä, kuten Pythonista ja AngularJS:stä. Lisäksi projektiryhmällä ei ollut lainkaan aiempaa kokemusta TIM-järjestelmän kehittämisestä tai tietoa sen sisäisestä toiminnasta.

Riski toteutui, mutta haittavaikutus oli pieni. Alussa projektiryhmällä meni paljon aikaa tutustuessa TIM-järjestelmän rakenteeseen, lähdekoodiin ja kehitystyökaluihin, mutta perehdytykset sekä teknisen ohjaajan ja TIM-kehittäjien apu oli aina hyvin saatavilla. Alussa kehitystyö oli hitaampaa, mutta kehitysympäristön tultua tutuksi viimeisessä kehitysvaiheessa pystyttiin muutoksia tekemään hyvinkin tehokkaasti.

9. Jäsenten kokemuksia

Luvussa kukin jäsen kertoo kokemuksistaan ja oppimastaan. Jäsenet käsittelevät tehtävien selkiytymistä työstettäviksi ja vaikeita asioita sekä mitä tekisivät toisin, jos projektiryhmä aloittaisi projektin alusta. Opittuja asioita jäsenet käsittelivät luvussa 3.3.

9.1 Hanna Alatalo

Alkuvaiheessa oli hieman sekavaa, kun kenelläkään meistä ei ollut kokemusta TIM:in dokumenttien laatimisesta. Laajan järjestelmän jatkokehittäminen tuntui haastavalta. Näimme paljon vaivaa aihealueen ymmärtämiseksi ja sen selkeyttämiseksi palavereissa kaavioiden ja prototyyppien avulla.

Sairastumisen vuoksi päädyin lopulta projektissa osa-alueeseen, joka ei ole vahvuuteni. Aikaisempi käyttöliittymäohjelmointikokemukseni on vähäistä, enkä ole koskaan oppinut ymmärtämään tapahtumapohjaista ohjelmointiparadigmaa. Opin ainakin, ettei käyttöliittymäohjelmointi ole oma juttuni, mutta kykenen siihen tarpeen vaatiessa. Sopivien drag&drop-kirjastojen löytäminen ja opetteleminen oli haastavaa sekä lopulta melko palkitsematonta. Selain- ja laiteyhteensopivuuksien huomioonottaminen vei myös paljon työtunteja ja päänvaivaa.

Jos projekti alkaisi nyt alusta, siirtyisin ehkä itse suunnittelupuolelle ja pois käyttöliittymäohjelmoinnista. Olen kuitenkin tyytyväinen siihen, mitä saavutimme projektissa. En usko, että olisimme voineet suoriutua paremmin.

Projektin läpivienti oli mielestäni onnistunut, sillä pysyimme hyvin aikataulussa päivittäisten pikapalaverien sekä tarkasti suunniteltujen kehitysvaiheiden avulla. Kaikki projektin jäsenet olivat paikalla projektihuoneessa lähes päivittäin, mikä nopeutti tiedon kulkua ja ongelmien ratkomista. Vuorovaikutus oli pääasiassa suullista, sillä olimme enimmäkseen tekemisissä toistemme kanssa kasvotusten.

9.2 Jarkko Kuivanen

Adaptiivisen palautteen ja vanhan sovelluksen toiminnan ymmärtäminen veivät itseltäni projektin alussa turhan paljon aikaa. Vaikeaa oli myös TIM-järjestelmän ymmärtäminen.

Alussa itselläni oli hiukan näyttämisen halua, jonka vuoksi yritin tuoda kaiken kattavaa vastausta sovelluksen logiikkaan ja esittää sen kerralla. Ongelmana oli huono esitystaitoni, jonka vuoksi en ehkä saanut ilmaistua ajatuksiani tarpeeksi selvästi. Alun rämpimisen jälkeen oli vain parempi todeta, että porukalla pohtimalla olisi helpompi tapa viedä asioita eteenpäin.

Jos aloittaisin projektin alusta, jättäisin varmaan em. itsekseen haudotun kokonaisen esityksen vaiheen kokonaan välistä ja keskittyisin viemään ajatuksiani läpi pienemmissä perustelluissa palasissa. Sinänsä kokonaisuuden miettimisestä ei ollut missään vaiheessa haittaa, vaan pikemminkin päinvastoin. Aloittaisin myös TIM:n ohjelmointiin perehtymisen aikaisemmassa vaiheessa, jos projekti alkaisi nyt.

Koin pariohjelmoinnin erityisen tehokkaaksi tilanteessa, jossa samaa kooditiedostoa muokataan. Tällöin aika ei kulu arvuuttelussa, vaan samaa ongelmaa miettivät kahdet aivot. Myös tämän ottaisin tavaksi heti projektin alussa.

Yleisesti ottaen projekti lähti hyvin käyntiin ja eteni mallikkaasti. Suurin syy hyvään tahtiin lienee se, että ryhmän jäsenet tekivät projektiin liittyvän työn pääosin ryhmähuoneesta käsin ja jäsenet olivat alusta asti sitoutuneita tekemään projektin eteen sovitun työmäärän. Päivittäisestä kanssakäymisestä johtuen toimimme mielestäni hyvin ryhmänä.

9.3 Elisa Nauha

Projektin alussa meni paljon aikaa aiheeseen ja projektin läpivientiin tutustumisessa. Ryhmä kuitenkin tarttui heti toimeen ja jo ensimmäisestä viikosta lähtien olimme kaikki toimistolla. Projektin aihealue oli uusi. Olikin vähän epäselvää alussa, olisiko hyvä lukea iso pino artikkeleita ja väitöskirjoja vai riittääkö vähempi. Jo yhden artikkelin lukeminen auttoi valtavasti aiheen taustojen selvittämisessä.

Toteutuksen suunnitteluun meni huomattavan paljon aikaa, mutta lopulta kattava suunnittelu säästi aikaa toteutuksessa. Suunnittelun tarpeesta huolimatta lähdimme kuitenkin heti tutkailemaan koodia, ja koen näin alun menneen lopulta mallikkaasti.

Pitkän mietinnän jälkeen ehdotin itseäni projektipäälliköksi. Koen sen olleen hyvä päätös, vaikka se vähensi huomattavasti mahdollisuuksia ohjelmointiin. Käytännössä osallistuin itse ohjelmointiin vain ensimmäisen kehitysvaiheen alussa. Toki sain hyvän kokonaiskuvan koko kehityksestä seuratessani tilannetta ja yhteisissä pohdinnoissa. Kokonaiskuvan hallinta oli haastavaa, mutta auttoi projektin etenemistä. Erityisesti päivittäiset lyhyet palaverit olivat hyödyllisiä projektin hallinnassa. Ne myös kannustivat keskustelemaan ongelmista ajoissa.

Alussa projektisuunnitelman laatiminen varsinkin aikataulun ja prosessin osalta vaati aika paljon tutkailua ja alan kokeneempien tekijöiden haastattelua. Valittu prosessi oli kuitenkin projektin osalta toimiva, ja sitä ei tarvinnut muuttaa projektin aikana. Tuntui aluksi vaikealta saada muut jäsenet määritellyn prosessin taakse, mutta se johtui ehkä vain rohkeuden puutteesta omalta osaltani. Ryhmän jäsenet kuitenkin noudattivat prosessia mallikkaasti.

Työnjako onnistui mielestäni hyvin. Ideana oli jakaa tehtävien tai dokumenttien sijaan vastuualueita, jottei kukaan ajautuisi tilanteeseen, että tuntee olevansa yksin liian ison urakan kanssa. Kaikilla oli oikeus jakaa esimerkiksi dokumenttien osa-alueita muille kirjoitettavaksi, jos toisilla oli aikaa ja tietotaitoa asian tiimoilta.

Jos projekti alkaisi uudestaan alusta, niin koen, ettei suuria muutoksia tulisi tehtyä. Toki päätökset tulisi tehtyä nopeammin, kun ymmärtäisi paremmin projektin kulun ja aihealueeseen liittyvät ongelmat.

9.4 Jere Ojala

Projektin alussa oli hieman vaikeuksia ymmärtää kunnolla, miten tilaajan tilaaman sovelluksen tulisi toimia. Projektin edetessä se hiljalleen selvisi, kun projektiryhmän jäsenet alkoivat ymmärtää logiikkaa. Samalla hankalaksi tuli ajatella, miten kyseisen sovelluksen saisi toimimaan TIM-ympäristössä. Kuitenkin pääsimme suunnitellen hyvää tahtia eteenpäin, ja saimme hyvän kuvan siitä, mitä olemme tekemässä ja miten. Projektissa piti myös alkaa kirjoittamaan koodia kielillä, joita en ollut aiemmin käyttänyt. Onneksi tekemällä oppii sekä myös hyvässä ohjelmointiympäristöstä ja asiantuntijan avusta oli hyötyä.

Hankaluuksia oman osa-alueeni kohdalla ei tullut, sillä koin oman osuuteni olleen muiden osuuksia pienempi ja helpompi. Yksi suuria hankaluuksia projektin aikana oli oheiskurssien kirjoitustehtävät, joihin kului minulta henkilökohtaisesti liikaa aikaa, joka maksoi todellisen projektin työtunteja. Toinen hankaluus projektissa oli oma äärimmäisen huono keskittymiskyky, jonka takia kokouksissa ja ryhmän sisäisissä esittelyissä saatoin kadottaa punaisen langan ja pudota kärryiltä.

Yleisesti ottaen projektin läpivienti sujui suhteellisen tasaisesti. Kaikki vetivät omaa osuuttaan eteenpäin ilman sisäisiä tai ulkoisia esteitä. Koin vuorovaikutuksen ryhmän sisällä olleen moitteetonta, eikä paljoa ristiriitoja tai riitatilanteita koitunut. Työnjako projektiryhmässä oli mielestäni tarpeeksi tasainen, vaikkakin hiukan parantamisen varaa olisi voinut olla. Välistä omalla kohdallani tuntui olevan muita vähemmän töitä, kun taas osalla tuntui olevan välillä liikaa. Kaikkiaan tehtäviä delegoitiin hyvin muillekin ryhmän jäsenille, kun niitä pystyi.

Jos aloittaisin projektin uudestaan alusta, panostaisin enemmän alkupään työhön, sillä sain huonosti työtunteja kurssin alkupuolella. Yrittäisin myös alusta asti enemmän perehtyä, minkälaista koodia muut ovat saaneet aikaan. Lisäksi yrittäisin aloittaa testauksen suunnitelmat aiemmin, sekä laatia parempia testitapauksia ja automaattitestejä.

9.5 Kimmo Urtamo

Mielestäni yleisellä tasolla projektin tehtävät olivat suhteellisen selkeitä heti alussa, koska tilaajan haluamat ominaisuudet olivat selkeitä. Ominaisuudet olivat myös jaetut tehtäviin, joilla oli selvät rajat. Ongelmia aiheutti TIM:iin sisään pääseminen, ja adaptiivisen palautteen ymmärtäminen. Lisäksi vaikka saimme aikaisemman sovelluksen lähdekoodin nähtäväksi, sitä ei pystynyt hyödyntämään projektissa. Palaverien ja ryhmän sisäisen keskustelun avulla tehtävät jäsentyivät ajan edetessä selkeämmiksi ja aloimme ymmärtää, miten haluamme asiat tehdä ja kuka keskittyy mihinkin osa-alueeseen.

Vaikein asia projektissa oli TIM. Se on todella laaja kokonaisuus ymmärrettäväksi, enkä vieläkään varmaan tiedä suurinta osaa sen toiminnasta. Lisäksi selaimessa ja palvelimella käytettyjen eri ohjelmointikielten yhteentoimimisessa ja aikaisemmissa toteutusratkaisuissa oli ihmeteltävää. Onneksi pystyimme aina pyytämään nopeasti apua vieressä olevasta teknisten ohjaajien huoneesta.

Jos asiat tehtäisiin uudelleen, sovelluksen rakennetta voisi mielestäni muuttaa. Tehtäväsarjan sisällä toiminta on ihan hyvää, mutta palauteliitännäinen tekee suurimman osan testin asioista. Testi voi kuitenkin sisältää dokumentteja, joissa ei ole palauteliitännäistä. Projektiryhmän mahdollisuudet olivat pienet vaikuttaa siihen, että testi luodaan tehtäväsarjojen ulkopuolella niin kuin oli visioitu. Lisäksi käyttöoikeuksien kanssa toimimista olisi pitänyt tarkastella aikaisemmin. Toisaalta, koska TIM on Internet-palvelu, käyttäjän toiminnan estämisessä ei pysty ottamaan kaikkea huomioon.

Projekti eteni hyvin, ja kaikille jäsenille kertyi viikkotunteja mukavasti. Siirtymät esitutkimuksen, kehittämisvaiheen ja lopun dokumenttien kirjoittamisen välillä tapahtuivat sujuvasti. Itse kehittämään päästiin suhteellisen nopeasti, kunhan tietokoneongelmat selvisivät. Vaadittavien dokumenttien laatiminen aloitettiin hyvissä ajoin jo ennen kehittämisen lopettamista. Tästä tietysti aiheutui hieman ongelmia mm. ohjeiden pysymisessä sovelluskehityksen mukana, mutta toisaalta dokumenttien korjauksen kanssa ei aiheutunut niin suurta kiirettä.

Projektin läpivienti onnistui mielestäni hyvin. Projekti oli jaettu selkeisiin vaiheisiin ja kaikki vaiheiden osaset valmistuivat ajallaan. Tämän ansiosta projekti pysyi hyvin aikataulussa. Ryhmätyö oli mielestäni toimivaa, joka johtui varmaankin siitä, että jokainen ryhmän jäsen oli paikalla projektihuoneessa joka päivä muutamaa poikkeusta lukuunottamatta. Vuorovaikutus toimi kasvotusten hyvin, mutta kirjallista viestintää olisi voinut hieman parantaa. Motivaatio ja huumori pysyivät korkealla, sekä olimme samalla sivulla asioista.

10. Yhteenveto

TIMCAN-projekti kehitti Jyväskylän yliopiston informaatioteknologian tiedekunnassa kehitettyyn TIM-järjestelmään toimintoja, jotka mahdollistavat ICAnDoiT-ohjelmiston korvaamisen. Toiminnoista kehitettiin mahdollisimman yleiskäyttöisiä siten, että ne hyödyttävät myös muita TIM-järjestelmän käyttäjiä.

Projekti vietiin läpi kevään 2019 aikana pääosin suunnitellussa aikataulussa käyttäen kuitenkin varatun kahden viikon pelivaran. Projektin kokonaistyömäärä oli suunniteltua suurempia ja vastasi noin kuutta projektityöviikkoa, josta puolet oli sovelluksen toteutuksen työtunteja. Ryhmän jäsenet tekivät keskimäärin suunniteltua 20 viikkotyötuntia enemmän tunteja ja projekti eteni hyvin.

Suurin riski projektille oli tilaajan ja TIM-kehittäjien erilaiset tarpeet ja toiveet projektin vaatimusten suhteen. Riski toteutui, mutta ei aiheuttanut projektin merkittävää viivästymistä eikä merkittävästi heikentänyt tulosten laatua muuten kuin käytettävyyden suhteen. Riskeihin varauduttiin aktiivisella kommunikoinnilla tilaajan edustajien ja TIM-asiantuntijoiden kanssa, painottamalla tilaajan toiveita ja seuraamalla projektin tilaa aktiivisesti. Päivittäinen projektin tilan seuraaminen muodostui tärkeäksi osaksi riskien hallintaa.

Sovellusprojektissa projektiryhmän jäsenet oppivat projektimuotoista ryhmätyöskentelyä ja saivat kokemusta sovelluskehityksen läpiviennistä. Lisäksi ryhmän jäsenet saivat kokemusta projektissa käytetyistä ohjelmointikielistä ja työkaluista, kuten Pythonista ja AngularJS:stä.

[3] Guido van Rossum, Barry Warsaw and Nick Coghlan, PEP8 -- Style Guide for Python, saatavilla osoitteesta https://www.python.org/dev/peps/pep-0008/, Python Software Foundation. Viitattu 28.2.2019.

[4] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Requirement Specification Document for the TIMCAN Project, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/2019/timcan/dokumentit/requirement- specification-document, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[5] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Application Report of the TIMCAN Project, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/ proj/2019/timcan/dokumentit/application-report-of-project-timcan, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[6] Opensource.org, The MIT License | Open Source Initiative, saatavilla osoitteesta https://opensource.org/licenses/MIT, Opensource.org. Viitattu 28.2.2019.

[7] Creative Commons, Creative Commons - Attribution 4.0 International - CC BY 4.0, saatavilla osoitteesta https://creativecommons.org/licenses/by/4.0/, Creative Commons. Viitattu 28.2.2019.

[8] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, TIMCAN-projektin tilakatsaukset, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/ 2019/timcan/dokumentit/tilakatsaukset, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[9] TIMin kehittäjät, TIMin koodikäytänteet, saatavilla osoitteesta https://tim.jyu.fi/view/ tim/TIMin-kehitys/Koodikaytanteet, Jyväskylän yliopisto, informaatioteknologian tiedekunta. Viitattu 28.2.2019.

[10] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, TIMCAN Project, Functional Testing Plan, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/ tie/proj/2019/timcan/dokumentit/testaus/functional-testing-plan, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[11] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Test plan for usability testing in TIMCAN project, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/ tie/proj/2019/timcan/dokumentit/testaus/Test-plan-for-usability-testing-in-TIMCAN -project, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[12] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Preliminary Functional Testing Report of the TIMCAN Project, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/2019/timcan/dokumentit/testaus/ preliminary-testing, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[13] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Functional Testing Report of the TIMCAN Project, saatavilla osoitteesta https://tim.jyu.fi/view/ kurssit/tie/proj/2019/timcan/dokumentit/testaus/functional-testing-report, Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[14] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Usability Testing Report 20190506, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/ 2019/timcan/dokumentit/testaus/usability-testing-report-20190506 Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[15] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Usability Testing Report 20190507 1/2, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/ 2019/timcan/dokumentit/testaus/usability-testing-report-20190507-1-2 Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[16] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, Usability Testing Report 20190507 2/2, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/ 2019/timcan/dokumentit/testaus/usability-testing-report-20190507-2-2 Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[17] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo, User Manual for Creating Adaptive Feedback Test in the TIM, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/2019/timcan/kayttoohjeet/instructions Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.

[18] Hanna Alatalo, Jarkko Kuivanen, Elisa Nauha, Jere Ojala ja Kimmo Urtamo,
Sovellusuunnitelmat, saatavilla osoitteesta https://tim.jyu.fi/view/kurssit/tie/proj/ 2019/timcan/dokumentit/sovellussuunnitelmat Jyväskylän yliopisto, informaatioteknologian tiedekunta, 2019.