The page has been modified since the last reload. Refresh now?
Matias Berg
Bek Eljurkaev
Minna Lehtomäki
Juhani Sihvonen
Hannu Viinikainen
Versio 1.0.0
28.9.2015
Julkinen
Jyväskylän yliopisto
Tietotekniikan laitos
Jyväskylä
Hyväksyjä | Päivämäärä | Nimenselvennys | Allekirjoitus |
---|---|---|---|
Projektipäällikkö | __.9.2015 | Juhani Sihvonen | |
Tilaaja | __.9.2015 | Vesa Lappalainen | |
Ohjaaja | __.9.2015 | Jukka-Pekka Santanen |
Tekijät:
matias.j.k.berg@student.jyu.fi
kaeljurk@student.jyu.fi
minna.j.lehtomaki@student.jyu.fi
juhani.j.p.sihvonen@student.jyu.fi
hannu.j.viinikainen@student.jyu.fi
Dokumentin nimi: Timppa-sovellusprojekti, projektiraportti
Tiedosto: https://tim.jyu.fi/view/kurssit/tie/proj/2015/timppa/dokumentit/projektiraportti
Tiivistelmä: Timppa-projekti kehitti Jyväskylän yliopiston tietotekniikan laitoksella kehitettyyn TIM-oppimisympäristöön WWW-sovelluksen tukemaan välitöntä vuorovaikutusta massaluennoilla. Kehitetyllä sovelluksella luennoitsijat voivat luoda luentoja, laatia kysymyksiä, kysyä luennolle liittyneiltä opiskelijoilta kysymyksiä luennon aikana, sekä esittää kysymysten vastausjakaumia. Oppilaat voivat liittyä luennoille, sekä vastata luentokysymyksiin, kysyä kysymyksiä ja kommentoida luentoa luentoseinän avulla. Projektiraportissa kuvataan projektin suunniteltua ja toteutunutta läpivientiä käsitellen muun muassa tavoitteita, resursseja ja käytänteitä sekä jäsenten oppimaa ja kokemuksia. Lisäksi projektiraportissa verrataan toteumaa suunniteltuun muun muassa työnjaon ja työmäärien, aikataulun sekä arvioitujen riskien hallinnan osalta ottaen kantaa erojen syihin ja vaikutuksiin.
Avainsanat: Aikataulu, kokemuksia, käytänteet, ohjelmistokehitysprojekti, opittua, projektiorganisaatio, projektiraportti, prosessi, resurssit, riskien hallinta, tavoitteet, taustaa, tehtävät, tulokset, työmäärät, työnjako, vastuualueet.
Muutoshistoria
Versio | Päivämäärä | Muutokset | Tekijät |
---|---|---|---|
0.0.1 | 4.5.2015 | Projektiraportin laatiminen aloitettiin. | JS |
0.0.2 | 13.4.2015 | Lisättiin otsikot ja kirjoitettiin kokemuksista. | JS |
0.1.0 | 7.5.2015 | Lähetettiin versio kommentoitavaksi. | JS |
0.2.0 | 22.5.2015 | Korjauksia tehtiin jokaiseen lukuun ohjaajan palautteen perusteella. | JS |
0.3.0 | 27.5.2015 | Päivitettiin kuvia. Korjattiin virheitä ohjaajan palautteen perusteella. | JS |
0.3.5 | 6.9.2015 | Korjauksia tehtiin ohjaajan palautteen perusteella. Viimeisteltiin luku 6. | JS |
0.4.0 | 13.9.2015 | Dokumenttia viimeisteltiin. | JS |
0.4.1 | 17.9.2015 | Muokattiin lukuja 1-3 ja lähdeluetteloa palautteen perusteella. | MB |
0.4.2 | 18.9.2015 | Muokattiin lukuja 4, 5 ja 10, sekä osaa luvusta 5 ja 9 palautteen perusteella. | MB |
0.4.3 | 19.9.2015 | Muokattiin lukuja 6 ja 7 ohjaajan palautteen perusteella. | JS |
0.5.0 | 20.9.2015 | Muokattiin lukua 8 ja 9 ohjaajan palautteen perusteella. | JS |
0.5.1 | 24.9.2015 | Muokattiin koko dokumenttia lukuja 6-8 lukuunottamatta. | MB |
0.6.0 | 24.9.2015 | Muokattiin lukuja 6-8 ohjaajan palautteen perusteella | JS |
1.0.0 | 28.9.2015 | Viimeisteltiin dokumenttia | JS |
Timppa-projekti kehitti Jyväskylän yliopiston tietotekniikan laitoksella kehitettyyn TIM-oppimisympäristöön sovelluksen tukemaan välitöntä vuorovaikutusta massaluennoilla.
Projektin jäsenet:
matias.j.k.berg@student.jyu.fi
kaeljurk@student.jyu.fi
minna.j.lehtomaki@student.jyu.fi
juhani.j.p.sihvonen@student.jyu.fi
hannu.j.viinikainen@student.jyu.fi
Tilaaja:
vesa.t.lappalainen@jyu.fi
antti-jussi.lakanen@jyu.fi
Ohjaajat:
mika.k.lehtinen@student.jyu.fi
santanen@mit.jyu.fi
Yhteystiedot:
timppa@korppi.jyu.fi
, timppa_opetus@korppi.jyu.fi
https://korppi.jyu.fi/kotka/servlet/list-archive/timppa
ja https://korppi.jyu.fi/kotka/servlet/list-archive/timppa_opetus
Timppa-projekti kehitti Sovellusprojekti-kurssilla keväällä 2015 Jyväskylän yliopiston tietotekniikan laitoksella kehitettyyn TIM-oppimisympäristöön sovelluksen tukemaan välitöntä vuorovaikutusta massaluennoilla. Timppa-projektiryhmä lisäsi TIM-järjestelmään kyselyominaisuuden, jolla pystyy luomaan monipuolisempia kysymyksiä kuin vanhassa inSitu-järjestelmässä. Projektiryhmä lisäsi TIM-järjestelmään myös luentoseinän, johon oli olemassa erillinen sivusto ennestään. Kolmen erillisen ohjelmiston käyttö, ylläpito ja kehittäminen on todettu hankalaksi ja työlääksi.
Projektiraportissa kuvataan Timppa-projektin toteutunutta läpivientiä. Lähteinä projektiraportin laatimisessa on hyödynnetty Timppa-projektin projektisuunnitelmaa [8], Hälyri-projektin projektiraporttia [1] ja sovellusprojektien ohjetta [2]. Timppa-projektin laatimiin dokumentteihin kuuluvat myös sovellusraportti [9], vaatimusmäärittely [10], järjestelmätestaussuunnitelma [7] sekä järjestelmätestausraportit [5] ja [6].
Luvussa 2 esitellään dokumentissa käytettävät termit. Luvussa 3 käsitellään projektin taustaa ja tavoitteita. Luvussa 4 esitellään projektin organisaatio ja resurssit. Luvussa 5 kuvataan projektin käytänteitä. Luvussa 6 kuvataan projektin tehtävien työmäärien ja työnjaon toteumaa. Luvussa 7 kuvataan projektin prosessia ja aikataulua. Luvussa 8 käydään läpi projektin ennakoitujen riskien hallintaa sekä käsitellään niiden syitä ja vaikutuksia projektin läpivientiin ja tuloksiin. Luvussa 9 kuvataan ryhmän jäsenten kokemuksia ja oppimaa projektista.
Projektiraportissa käytettäviä aihealueen termejä ja ohjelmistoja ovat seuraavat:
Luvussa kuvataan projektin taustoja sekä projektissa kehitetyn sovelluksen tavoitteiden ja projektin tulosten toteumaa. Luvussa käsitellään myös ryhmän jäsenten oppimistavoitteita ja niiden toteutumista.
Sovellukselle asetettujen tavoitteiden osalta toteuma vastasi pääpiirteittäin suunnitelmaa. Projektissa lisättiin TIM-järjestelmään opettajille mahdollisuus luoda luentoja, laatia ja kysyä kysymyksiä, sekä tarkastella vastausten jakaumia. Oppilas voi muutoksien ansiosta vastata kysymyksiin sekä kysyä ja keskustella luennon sisällöstä luentoseinällä. Tavoitteiden toteumaa kuvataan tarkemmin luvussa 3.2, sovellusraportissa [9] ja vaatimuskohtaisesti vaatimusmäärittelyssä [10].
Projektiryhmä laati melkein kaikki suunnitellut dokumentit lukuunottamatta luokkadokumentaatiota. Ryhmän jäsenet kokivat saavuttaneensa henkilökohtaiset oppimistavoitteensa.
Jyväskylän yliopiston tietotekniikan laitoksella on kehitetty interaktiivisuutta massaluennoilla. Laitoksella kehitettiin 1990-luvulla langallinen järjestelmä, jonka avulla luennoitsija pystyi kysymään opiskelijoilta monivalintakysymyksiä. Järjestelmän ongelmana olivat erilliset laitteet, joiden kantaminen massaluennoille oli vaivalloista.
Tämän jälkeen tietotekniikan laitoksella kehitettiin Java-ohjelmointikielellä InSitu-niminen sovellus, joka toimii radioverkon yli. Kyseistä sovellusta opiskelijat pystyvät käyttämään tietokoneilla ja mobiililaitteilla. Järjestelmän heikkous opettajan näkökulmasta on se, että se ei toimi mobiililaitteissa ja lisäksi luennon valmistelu vaatii myös todella paljon aikaa. Projektin tilaajat ovatkin nähneet tarpeen sovellukselle, jolla pystyisi lisäämään vuorovaikutusta massaluennoilla.
Em. tarpeeseen Timppa-projekti kehitti kysymysominaisuuden olemassa olevaan TIM-oppimisympäristöön. TIMin ideana on tarjota oppimateriaaliin kirjamainen järjestys. TIMin avulla on myös tarkoitus lisätä opettajien ja oppilaiden välistä vuorovaikutusta luennoilla. TIMiin yhdistettyjen plug-inien avulla opettaja voi lisätä luentomateriaaliin esimerkiksi monivalintatehtäviä.
Projektin tavoitteena oli kehittää TIMiin seuraavat ominaisuudet:
Projektiryhmä toteutti kaikki yllä mainitut ominaisuudet TIMiin. Ainoastaan osa kysymyksen luontiin liittyvistä pakolliseksi luokitelluista vaatimuksista sovittiin tilaajan kanssa jatkokehitykseen. Tarkemmat tiedot vaatimusten toteutuminen vaatimuskohtaisesti löytyy vaatimusmäärittelystä [10].
Sovelluksen ohella projektiryhmä toteutti seuraavat dokumentit:
Projektiryhmä laati melkein kaikki suunnitellut dokumentit. Luokkadokumentaatiota ei luotu, ja sovelluksen viimeistä versiota ei järjestelmätestattu. Käyttötapausdokumentista ryhmä laati alustavan version, mutta se koettiin liian työlääksi hyötyynsä nähden.
Sovellus toteutettiin Sovellusprojekti-kurssilla, jossa opiskelijoiden tavoitteena on oppia projektimuotoista työskentelyä. Projektin edetessä ryhmän jäsenet saivat käytännön kokemusta siitä, kuinka projektimuotoinen ryhmätyöskentely toimii ohjelmointialalla. Projektin edetessä ryhmän jäsenet tutustuivat myös erilaisiin ohjelmointityökaluihin kuten PyCharmiin.
Ryhmän jäsenet olivat asettaneet omiksi oppimistavoitteekseen seuraavat:
Hannu halusi kehittää ohjelmointiosaamistaan verkkoympäristössä.
Bek oli asettanut päätavoitteekseen kehittää ryhmätyö- ja viestintätaitojaan. Bek oli myös kiinnostunut kehittymään verkkosovellusten kehittäjänä. Erityisen kiinnostuksen kohteena hänellä oli back-end-kehittäminen.
Juhani halusi kehittää projektinjohtamisen osa-alueita ja viestintätaitoja.
Minna halusi perehtyä selainpohjaisen käyttöliittymän toteuttamiseen.
Matias halusi kehittää projektitaitojaan ja WWW-ohjelmointitaitojaan.
Kaikki ryhmän jäsenet kokevat saavuttaneensa asetettamansa oppimistavoitteet. Kukin ryhmän jäsen on analysoinut oppimaansa tarkemmin luvussa 9.
Luvussa esitellään projektiorganisaatio, käytössä olleet resurssit sekä projektiin liittyvät oheiskurssit ja perehdytykset. Projektin toteutunut organisaatio ja resurssit vastasivat suunnitelmaa.
Projektiryhmän muodostivat Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen. Matias Bergilla oli jonkin verran ohjelmointikokemusta eri ohjelmistokielillä opiskelun ja harrastusten kautta. Bek Eljurkaevilla oli jonkin verran Java-ohjelmointikokemusta opiskelun kautta. Minna Lehtomäellä ei ollut paljoa ohjelmointikokemusta, mutta hänellä oli näkymystä käyttöliittymien suunnittelussa ja kehityksessä. Juhani Sihvosella oli C#-ohjelmointikokemusta työn kautta, ja hänellä oli myös kokemusta useista ohjelmointikielistä opiskelujen kautta kuten Javasta. Hannu Viinikaisella oli Pythonista kokemusta vaihto-opiskeluajaltaan Belgiasta, sekä hänellä oli myös hieman Ruby-on-Railsista kokemusta työn kautta.
Tilaajan edustajina toimivat Antti-Jussi Lakanen ja Vesa Lappalainen tietotekniikan laitokselta. Jukka-Pekka Santanen oli projektin vastaava ohjaaja. Teknisenä ohjaajana toimi Mika Lehtinen, joka on aktiivisesti mukana TIM-järjestelmän kehityksessä.
Jyväskylän yliopiston ATK-lähituki vastasi ryhmän käytössä olevista laitteista ja ohjelmistoista. Projektiviestintäkurssin kirjoitusviestinnän opettajana toimi Juha Jalkanen ja puheviestinnän opettajana Hanna Kivimäki.
Projektiryhmä sai käyttöönsä tietotekniikan laitokselta Agorasta huoneen C225.3, jossa oli asennettuina viisi Windows 7 -työasemaa. Projektin palaverit pidettiin Agoran kokoushuoneessa C226.1. Testausta varten projektiryhmä sai käyttöönsä Vesa Lappalaiselta Windows Phone 8 -älypuhelimen.
Sovellusprojektin avotilassa oli ryhmän käytössä monitoimitulostin ilman kuluja jäsenille. Ryhmällä oli mahdollisuus varata käyttöönsä videoprojektori, kannettava tietokone ja digitaalisanelin. Projektiryhmällä oli käytettävissä virkistystila, jossa on vedenkeitin ja kahvinkeitin.
Projektin julkistetut dokumentit sijoitettiin TIM-järjestelmään URL-osoitteeseen https://tim.jyu.fi/view/kurssit/tie/proj/2015/timppa
. Projektilla oli käytössään yhteinen verkkolevy hakemistossa \\sovpa7.cc.jyu.fi\timppa
ja WWW-sivusto osoitteessa http://sovellusprojektit.it.jyu.fi/timppa
. Projektissa kehitetyn sovelluksen testausympäristö perustettiin osoitteeseen https://tim-beta.it.jyu.fi/?folder=timppa
. Projektissa toteutettava lähdekoodi sijoitettiin nähtäville Git-pohjaiseen YouSource-julkistusjärjestelmään osoitteeseen https://yousource.it.jyu.fi/+timppa
. Projektilla käytössä olleet sähköpostilistat ja niiden arkistot esitellään luvussa 5.1.
Projektiryhmällä ei ollut projektin aikana tarvetta videoprojektorille, kannettavalle tietokoneelle eikä digisanelimelle. Vesa Lappalaiselta lainattiin Windows Phone 8 testaukseen. Ryhmä käytti verkkolevyjä kuvien tallennuspaikkana ja näitä pystyi liittämään TIM-järjestelmässä tehtyihin dokumentteihin viittamalla niiden URL-osoitteisiin. Osa dokumenteista tallennettiin myös ensin Google Drive -pilvipalveluun ennen kuin ne siirrettiin TIMiin.
Projektisuunnitelma, projektiraportti ja kokouspöytäkirjat laadittiin käyttäen TIMiä. Esityslistat ja moni muu dokumentti laadittiin ensin Google Drivessa ennen kuin ne julkistettiin TIMissä. Vaatimukset kirjattiin projektin Trello-tilille, josta vaatimusmäärittely muodostettiin. Tehtävien työtunnit kirjattiin Excel-taulukkolaskentaohjelmaan, jolla myös laadittiin tilakatsauksissa käytettävät grafiikat. Tilakatsaukset laadittiin Google Driven slides-ohjelmalla. Sekvenssikaaviot laadittiin ArgoUML-ohjelmalla. Freemind-ohjelmaa hyödynnettiin tavoitteiden kartoittamisessa, ja Gantt-kaaviot laadittiin GanttProject-ohjelmalla.
Sovelluksen kehittäminen tapahtui lähinnä Python-kielellä. HTML5:ta, CSS:ää ja JavaScriptiä käytettiin käyttöliittymän toteuttamiseen. Lisäksi kysymyksien vastausten jakaumien esittämiseen käytettiin valmista Charts.js-kirjastoa [4]. JavaScriptin kanssa käytettiin AngularJS- ja jQuery-apukirjastoja. Sovelluskehitysympäristönä käytettiin PyCharm-ohjelmaa.
Projektin kanssa samaan aikaan järjestettiin kaksi oheiskurssia: "Sovellusprojektin hallintaa, viestintää ja työkaluja" (TIES412, 1op) sekä "Projektiviestintä IT-alalla" (XYHI004, 3op). Oheiskurssien työtunnit kirjattiin omalle tehtäväkokonaisuudelle työajanseurantataulukkoon.
Kurssiin "Sovellusprojektin hallintaa, viestintää ja työkaluja" sisältyivät seuraavat luennot:
Kurssiin "Projektiviestintä IT-alalla" kuuluivat puhe- ja kirjoitusviestinnän luennot sekä ryhmätyöt. Lisäksi kurssiin kuuluivat projektissa laadittujen dokumenttien kirjoitusasun ja rakenteen muokkauksen työtunnit. Projektin aikana järjestetyt kaksi väliesittelyä kuuluivat myös viestintäkurssiin.
Ryhmän jäsenistä vain Matias Berg ja Hannu Viinikainen suorittivat kurssin "Projektiviestintä IT-alalla".
Luvussa esitellään projektin läpiviennissä noudatettuja käytänteitä. Käytänteiden tarkoituksena oli edistää projektin läpivientiä, asetettujen tavoitteiden saavuttamista ja tulosten toteutumista. Käytänteillä pyrittiin varmistamaan, että projekti etenee aikataulussa sekä toteutetut tulokset ovat yhteneviä suunniteltuihin tuloksiin.
Projektin kaikkia suunniteltuja käytänteitä ei noudatettu. Projektipäällikkö ei tiedottanut projektiorganisaatiota projektipalaverien välissä projektin etenemisestä. Palaverejen tilakatsaukset olivat puuttellisia. Dokumenttien versioiden numerointi ei vastannut aina käytänteitä. Yksikkötestausta ei suoritettu kattavasti ennen jokaista julkaisua. Järjestelmätestausta ei ehditty suorittaa tilaajille luovutettuun sovellukseen. Tiedostojen ja hakemistojen nimeäminen poikkesi käytänteistä.
Projektiorganisaatiolle tiedotettiin projektin etenemisestä, projektissa kohdatuista haasteista ja vaihtoehdoista sekä tehdyistä valinnoista, ratkaisuista ja päätöksistä lähinnä projektipalavereissa. Projektipäällikkö vastasi projektin etenemisen tiedottamisesta projektiorganisaatiolle antamalla tilakatsauksen jokaisessa projektipalaverissa.
Sähköpostilistalle timppa@korppi.jyu.fi
kuuluivat kaikki projektiorganisaation jäsenet, joten sitä käytettiin koko projektiorganisaatiota koskevaan viestintään sisältäen lähinnä tuloksista sekä palavereista ja niiden pöytäkirjoista tiedottamisen. Sähköpostilistalle lähetettyjä viestejä pystyy selaamaan Korpin sähköpostiarkiston kautta osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/timppa/
.
Sähköpostilista timppa_opetus@korppi.jyu.fi
oli varattu projektin ohjaajien ja ryhmän jäsenten väliseen viestintään. Sen sähköpostiarkisto sijaitsee osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/timppa_opetus/
. Sähköpostilistalla käsiteltiin asioita, jotka eivät olleet oleellisia tilaajan edustajien kannalta.
Projektiryhmän sisäinen viestintä tapahtui WhatsAppin, Trellon ja sähköpostin välityksellä sekä kasvokkaisilla keskusteluilla ja pienillä kokouksilla projektiryhmän työhuoneessa ja kokoushuoneessa. Projektiryhmän muuhun kuin kasvokkaiseen viestintään pyrittiin käyttämään pääasiallisesti sähköpostia. Sähköpostilla myös tiedotettiin virallisemmista asioista projektiryhmän sisällä. WhatsApp oli tarkoitettu lähinnä pikaisiin ja lyhyisiin viesteihin. Trellossa puolestaan käytiin yksittäisiin vaatimuksiin ja tehtäviin liittyvää keskustelua.
Suunnitellusta poiketen projektipäällikkö ei tiedottanut ohjaajille ja tilaajan edustajille projektin etenemisestä projektipalaverien välillä. Ryhmän sisäinen sähköinen viestintä tapahtui pääasiassa WhatsAppin välityksellä sähköpostin sijaan.
Projektiorganisaatio piti aluksi palavereja viikoittain sujuvan alun varmistamiseksi. Tämän jälkeen palavereita pyrittiin pitämään noin kahden viikon välein. Seuraavan palaverin ajankohta päätettiin aina edellisessä palaverissa.
Palavereissa käsiteltiin edellisen palaverin jälkeistä projektin etenemistä ja etenemiseen vaikuttaneita asioita. Lisäksi projektipäällikkö esitti tilakatsauksessa projektiryhmän viikoittaisen ja tehtäväkokonaisuuksittaisen ajankäytön. Jokaisessa palaverissa käytiin läpi edellisen palaverin pöytäkirja vähintään tehtyjen päätösten sekä osallistujille sovittujen toimenpiteiden tilan osalta. Lisäksi edellisen palaverin pöytäkirja olisi tarvittaessa käyty läpi myös muilta osin, mutta tähän ei koettu tarvetta juuri lainkaan. Pöytäkirjan läpikäymistä johti puheenjohtaja.
Palavereissa käsiteltiin toteutettavan sovelluksen ominaisuuksia ja vaatimuksia sekä niiden toteutusratkaisuja. Asiat käytiin läpi niin tarkasti, että asiakkaan edustajat ja projektiryhmän jäsenet pääsevät yhteisymmärrykseen sovellukseen liittyvistä asioista, eikä väärinymmärryksiä pääse syntymään. Projektiryhmä esitteli palaverissa sovelluksesta käyttöliittymän suunnitelmia tai prototyyppejä, mikäli sellaisia oli valmiina. Palavereissa sovittiin myös projektiin liittyvistä käytänteistä.
Jokainen ryhmän jäsen toimi vuorollaan palavereissa sihteerinä tai puheenjohtajana. Kyseiset tehtävät kiersivät ryhmän keskenään sopimassa järjestyksessä. Puheenjohtaja huolehti esityslistan lähettämisestä sähköpostilla projektiorganisaation jäsenille vähintään vuorokautta ennen seuraavaa palaveria. Palaverissa puheenjohtaja vei keskustelua eteenpäin esityslistan mukaisesti. Sihteeri laati palaverista pöytäkirjan, jonka hän toimitti mahdollisimman nopeasti palaverin puheenjohtajalle tarkastettavaksi. Kun pöytäkirja oli puheenjohtajan osalta hyväksytty, sihteeri toimitti sen koko projektiorganisaatiolle. Tämän lisäksi jokaisen ryhmän jäsenen laatima ensimmäinen pöytäkirja toimitettiin myös vastaavan ohjaajan esitarkastettavaksi.
Pöytäkirja hyväksytettiin seuraavassa palaverissa, jolloin siihen oli mahdollista esittää muutoksia. Mikäli edellisen palaverin pöytäkirja hyväksyttiin korjauksin, kyseisen palaverin puheenjohtajan tai sihteerin olisi tullut sähköpostitse ilmoittaa korjatusta pöytäkirjasta projektiorganisaatiolle listaten tiivistetysti tehdyt korjaukset.
Projektiorganisaation yhteisten palavereiden lisäksi projektiryhmä järjesti viikoittain oman palaverin, jossa sovittiin yhdessä seuraavan viikon tehtävät ja merkittiin ne tarvittaessa Trelloon. Tämä palaveri pyrittiin järjestämään mahdollisimman pian projektiorganisaation yhteisen palaverin jälkeen.
Palaverien suunnitelman ja toteuman välillä on muutama poikkeama. Projektiryhmän jäsenet eivät listanneet pöytäkirjoihin tehtyjä korjauksia sähköpostissa. Lisäksi projektipäällikön esittämässä tilakatsauksessa ei aina käyty läpi työtunteja tehtäväkokonaisuuksittain.
Lähdekoodi kirjoitettiin vastaamaan Pythonin yleisiä käytänteitä noudattaen PEP8-dokumentaatiota [3]. Lähdekoodissa käytetyt aliohjelmat, luokat ja muuttujat nimettiin englanniksi mahdollisimman kuvaavilla nimillä. Myös lähdekoodin kommentit kirjoitettiin englanniksi. Lähdekoodissa käytettyjen tekstitiedostojen tallennusmerkistönä käytettiin UTF-8 -koodausta.
Alla on esimerkki edellä esitettyjä käytänteitä noudattavasta JavaScript-koodista.
/**
* Created by hajoviin on 6.5.2015.
* Controller to show statistics to questions.
* @module showStatisticsToQuestionController
* @author Matias Berg
* @author Bek Eljurkaev
* @author Minna Lehtomäki
* @author Juhani Sihvonen
* @author Hannu Viinikainen
* @licence MIT
* @copyright 2015 Timppa project authors
*/
var angular;
var timApp = angular.module('timApp');
timApp.controller('ShowStatisticsToQuestionController', ['$scope', '$http', function ($scope) {
"use strict";
$scope.dynamicAnswerShowControl = {};
$scope.canvas = "";
$scope.questionTitle = "";
$scope.lecturerAnswered = false;
$scope.$on("closeAnswerSheetForGood", function() {
$scope.$emit('closeAnswerShow');
$scope.dynamicAnswerShowControl.close();
});
/**
* Closes statistic window
* @memberof module:showStatisticsToQuestionController
*/
$scope.close = function () {
$scope.$emit('closeAnswerShow');
if($scope.lecturerAnswered) {
$scope.dynamicAnswerShowControl.close();
}
};
$scope.$on("lecturerAnswered", function () {
$scope.lecturerAnswered = true;
});
/**
* Adds answer to statistic directive
* @memberof module:showStatisticsToQuestionController
*/
$scope.$on("putAnswers", function (event, answer) {
$scope.dynamicAnswerShowControl.addAnswer(answer.answers);
});
/**
* Creates chart based on question json.
* @memberof module:showStatisticsToQuestionController
*/
$scope.$on("createChart", function (event, question) {
$scope.lecturerAnswered = false;
$scope.dynamicAnswerShowControl.createChart(question);
$scope.questionTitle = question.QUESTION;
});
}]);
Lähdekoodin osalta toteuma vastasi laajalti suunnitelmaa, mutta muutamia poikkeamia oli. Lähdekoodia ei ehditty dokumentoimaan niin kattavasti kuin olisi pitänyt, sekä luokkien ja metodien nimeämiset poikkesivat osittain käytänteistä.
Tulosten versiohallintaan käytettiin Git-versiohallintaohjelmistoa ja sovelluksen lähdekoodi sijoitettiin Git-pohjaiseen YouSource-julkistusjärjestelmään. YouSource-julkistusjärjestelmässä lähdekoodi oli koko ajan ohjaajien ja tilaajan edustajien saatavilla.
Julkistetuissa dokumenttien versioissa käytettiin kolmiportaista versionumerointia. Ryhmän sisäiset versiot aloitettiin versionumerosta 0.0.1. Kunkin uuden version osalta kasvatettiin vähiten merkitsevää numeroa yhdellä, jolloin toinen versio oli versionumeroltaan 0.0.2. Projektiryhmän ulkopuolelle julkistettavien versioiden numerointi aloitettiin versionumerosta 0.1.0, ja seuraavat julkistetut versiot numeroitiin kasvattamalla toisen tason numeroa yhdellä. Ensimmäisen hyväksytyn version numero oli 1.0.0. Sitä seuraavissa hyväksytyissä versioissa kasvatettiin toisen tason numeroa yhdellä, jolloin toinen hyväksytty versio oli 1.1.0
Versioiden numerointi dokumenttien osalta ei vastannut suunnitelmaa muuten kuin ensimmäisen hyväksytyn version numeroinnin osalta. Sovelluksesta pyrittiin julkaisemaan uusi versio aina seuraavaan palaveriin mennessä. Toisinaan versioita julkaistiin useammin ja toisinaan hieman harvemmin.
Sovelluksen toiminta oli tarkoitus varmistaa yksikkö- ja järjestelmätestauksella. Testauksella pyrittiin varmistamaan, että sovellus vastasi sille asetettuja toiminnallisia ja laadullisia vaatimuksia.
Lähdekoodin yksikkötestaus oli lähdekoodin kirjoittajan vastuulla. Yksikkötestauksessa hän varmisti, että hänen kirjoittamansa koodi toimii suunnitellusti. Yksikkötestaus pyrittiin suorittamaan ennen lähdekoodin julkistamista tilaajan käyttöön, mutta usein puutteellinen tai virheellinen versio julkaistiin. Vähimmäisvaatimuksena ennen sovelluksen versioitten lähdekoodin julkistamista tilaajalle oli, että vähintään kaksi projektiryhmän jäsentä tarkistaa lähdekoodin toiminnan, mutta tämä toteutui harvoin.
Järjestelmätestauksesta vastuussa oleva henkilö laati testauksen suorittamiseksi testaussuunnitelman [7] ja vastasi testauskertojen suorittamisesta. Testaussuunnitelma sisälsi kullakin testauskerralla suoritettavat testitapaukset askeleittain. Järjestelmätestauskerran suorittanut henkilö laati siitä testausraportin, jossa kuvattiin testauskerroilla suoritettujen testitapausten tulokset sekä havaitut virheet ja puutteet. Järjestelmätestaus suoritettiin kaksi kertaa toukokuussa. Testauskerrat suoritettiin Windows 7 -työasemalla Internet Explorer- ja Google Chrome-selaimilla.
Sovelluksen käytettävyyteen kiinnitettiin huomiota kaikkien kehitysvaiheiden aikana, mutta varsinaista käytettävyystestausta ei projektissa suoritettu.
Järjestelmätestauksen osalta toteuma ei vastannut suunnitelmaa. Ryhmä ehti suorittaa vain kaksi kattavaa testaukertaa, eikä lopullista tilaajalle luovutettua versiota järjestelmätestattu. Varsinaisia yksikkötestejä ei laadittu projektin aikana, mutta sovellusta käytettiin projektin aikana laajasti ryhmän, tilaajien ja ohjaajien toimesta. Sovellusta käytettiin Android-, iPhone- ja Windows Phone -puhelimilla, Android- ja iPad-tableteilla, sekä useilla eri selaimilla. Testauksen ansiosta lähdekoodista löydettiin virheitä.
Projektiryhmän kirjoittama lähdekoodi katselmoitiin kaksi kertaa projektin aikana. Katselmoinnissa tekninen ohjaaja ja tilaajan edustaja kommentoivat lähdekoodia sekä antoivat vinkkejä ja parannusehdotuksia. Ensimmäiseen katselmointiin osallistui koko projektiryhmä. Toisesta katselmoinnista oli poissa Eljurkaev. Projektiryhmä kirjasi katselmoinnissa esille tuodut havainnot ja huomiot muistioksi [11] ensimmäisestä katselmoinnista. Toisen katselmoinnin huomioita ei kirjattu muistioksi, sillä teknisen ohjaajan tekemät kirjalliset huomiot [12] olivat varsin kattavat.
Projektin lopussa sovellus, lähdekoodit, raportit ja vaatimusmäärittely hyväksytettiin projektin ohjaajilla ja toisella tilaajan edustajista. Yksittäisistä tuloksista tilaajan edustajan hyväksyntä pyydettiin toteutuneille sovellukselle, sovellusraportelle ja vaatimusmäärittelylle. Tekninen ohjaaja hyväksyi lähdekoodin. Projektisuunnitelma ja projektiraportti, sovellusraportti sekä vaatimusmäärittely hyväksyttiin projektipäällikön, tilaajan edustajan ja projektin vastaavan ohjaajan allekirjoituksilla.
Tulosten katselmointien ja hyväksymisen osalta toteuma vastaa suunnitelmaa.
Projektiryhmä kokosi projektin tulokset projektikansioon ja CD-levyille. Projektikansioon tulostettiin kaikki projektissa laaditut dokumentit ja lähdekoodi. TIMissä laaditut dokumentit tallennettiin html- ja pdf-formaatissa CD:ille. Lisäksi sähköpostiarkistot, tiivistetty projektin kuvaus ja jäsenten itsearvioinnit liitettiin projektikansioon ja CD-levyille.
CD-levy koostettiin vasta, kun kaikki projektin tulokset oli hyväksytty. Tulokset toimitettiin tilaajalle CD-levyllä. Laitokselle toimitettu projektikansio sijoitettiin projektitilan kokoushuoneessa olevaan hyllyyn. Projektikansion yhteyteen liitettiin myös projekti-CD, ja toinen CD-levy toimitettiin laitoksen arkistoon.
Projektissa käytetty testauspalvelin siirrettiin projektin päätyttyä tilaajan haltuun. Ohjelmiston viimeisimmät versiot ovat saatavilla YouSourcesta osoitteesta https://yousource.it.jyu.fi/+timppa
.
Tulosten koostamisen ja toimittamisen osalta toteuma vastasi suunnitelmaa sillä poikkeamalla, että tilaajalle toimitettiin CD muistitikun sijaan.
Lähdekooditiedostot olisi pitänyt nimetä PEP8-suositusten [3] mukaisesti. Tiedostojen ja hakemistojen nimet kirjoitettiin englanniksi. Lisäksi tiedostojen ja hakemistojen nimet olisi pitänyt kirjoittaa aina pienillä kirjaimilla ja välilyönnit olisi pitänyt korvata alaviivoilla.
Dokumenttitiedostot nimettiin niitä kuvaavilla nimillä. CD:lle nimiin lisättiin versionumero luvussa 5.4 esitettyjen käytänteiden mukaisesti. Esimerkiksi projektisuunnitelman pdf-tiedosto nimettiin timppa_projektisuunnitelma_[numero].[numero].[numero].pdf
.
Tiedostojen ja dokumenttien nimeäminen ei toteutunut suunnitelmien mukaan, vaan välillä välilyönnit korvattiin alaviivan sijaan aloittamalla seuraava sana isolla kirjaimella. Kaikki nimet kuitenkin kirjoitettiin englanniksi. Dokumenttien nimeäminen toteutui suunnitelman mukaan.
Projektin tulokset tallennettiin CD-levylle ja TIMiin seuraavan hakemistorakenteen mukaisesti pois lukien TIMIstä uupuva software
-hakemisto.
dokumentit
ajankaytto
esittelyt
itsearvioinnit
kayttoliittymasuunnitelma
kayttotapaukset
projektiraportti
projektisuunnitelma
sitoumus_ja_lisenssit
sovellusraportti
vaatimusmaarittely
palaverit
esityslistat
katselmoinnit
kaytettavyyspalaute
poytakirjat
tilakatsaukset
sahkopostiarkistot
timppa
timppa_opetus
software
timppa-tim
lahdekoodi
testaus
testausraportit
testaussuunnitelmat
Suunniteltua luokkadokumentaatiota ei luotu. Suunnitelmasta poikettiin myös siinä, että software-kansioon lisättiin timppa-tim-kansio, joka sisältää koko TIM-järjestelmän ml. jo ennen projektia TIMissä olleet tiedostot. Kansioiden nimet ovat myös hieman muuttuneet. Käyttötapauksia ei myöskään ollut suunnitelmassa.
Luvussa esitellään projektiryhmän jäsenten tehtävät ja olennaisimpien tuloksien vastuuhenkilöt, sekä jäsenten arvioidut ja toteutuneet työtunnit. Lehtomäen sijasta projektiraportin vastuuhenkilönä toimi Berg. Muiden tuloksien osalta toteuma vastasi suunnitelmaa. Suurimpia eroja suunnitelluissa ja toteutuneissa työmäärissä syntyi projektipalavereista, toteutuksesta ja oheiskursseista. Projektipalavereja arvioitiin pidettävän kerran viikossa, kun toteuma oli kahden viikon välein. Toteutuksessa ryhmä ei osannut ottaa huomioon jäsenten osaamista kehitystekniikoista. Oheiskurssien toteutunut työmäärä oli suunniteltua pienempi, koska ryhmän jäsenistä vain Berg ja Viinikainen osallistuivat kirjoitus- ja puheviestinnän kurssille.
Projektipäällikkönä toimi Juhani Sihvonen ja varapäällikkönä Matias Berg. Projektipäällikön vastuulle kuuluivat projektin suunnittelu ja hallinta sekä ajankäytön seuranta. Varapäällikkö toimi projektipäällikkönä projektin aikana kaksi kertaa projektipäällikön ollessa sairaana.
Tuloksille nimetyt ja toteutuneet vastuuhenkilöt esitellään taulukossa 6.1. Vastuuhenkilö vastasi tuloksen etenemisestä ja laadusta.
Tulos | Vastuuhenkilö | Toteutunut |
---|---|---|
Projektisuunnitelma | Juhani Sihvonen | Juhani Sihvonen |
Projektiraportti | Juhani Sihvonen | Juhani Sihvonen |
Sovellusraportti | Minna Lehtomäki | Matias Berg |
Testausdokumentit | Matias Berg | Matias Berg |
Vaatimusmäärittely | Bek Eljurkaev | Bek Eljurkaev |
Palvelin | Hannu Viinikainen | Hannu Viinikainen |
Käyttöliittymä | Minna Lehtomäki | Minna Lehtomäki |
Taulukko 6.1: Tulosten vastuuhenkilöt.
Matias Berg toimi sovellusraportin vastuuhenkilönä Minna Lehtomäen sijasta, koska sovellusraportin katsottiin soveltuvan paremmin varaprojektipäällikön vastuulle. Muiden vastuualueiden osalta toteuma vastasi suunnitelmaa.
Kukin projektiryhmän jäsen käytti sovellusprojektiin yli 300 tuntia. Yhteensä työtunteja projektiryhmälle kertyi 1570. Kunkin jäsenen työmäärä vastasi 11 opintopistettä ja noin 10 viikkotuntia. Tämän lisäksi projektin jäsenet käyttivät oheiskursseihin yhteensä 88 tuntia.
Projektiryhmä jakoi tehtäviä tasapuolisesti siten, että kullekin jäsenelle tuli tehtäviä eri osa-alueilta. Projektin työmäärä jakautui tehtävittäin jäsenten kesken kuvan 6.1 mukaisesti. Työnjaossa ja työmäärien suunnittelussa huomioitiin projektin jäsenten taidot ja aikataulut sekä projektin aikataulu. Arvioidut työmäärät perustuivat projektipäällikön kokemuksiin muista projekteista. Työmäärien järkevyyttä pohdittiin vertailemalla niitä Hälyri-projektin projektiraportin[1] suunniteltuihin ja toteutuneisiin työtunteihin.
Projektin hallinnan yhteenlasketut tunnit vastasivat lähes suunnitelmaa. Lehtomäen oli tarkoitus projektin alussa käyttää enemmän aikaa projektisuunnitelmaan, mutta lopulta ryhmä katsoi järkeväksi, että Sihvonen hoitaa myös Lehtomäelle suunnitellun osuuden. Projektiraportin suunniteltua suuremmat toteutuneet tunnit johtuvat osittain siitä, että Sihvonen kirjasi viimeistelyn ja kokoamisen tunteja usein myös projektiraportin tekemiseen.
Palaverien suurimmat poikkeamat tulevat projektipalavereista, joita tunteja suunnitellessa arvioitiin pidettävän kerran viikossa, kun toteuma oli kahden viikon välein. Ryhmän omien palaverien suunniteltua pienempi tuntimäärä johtuu siitä, että ryhmän omat palaverit olivat usein suunniteltua nopeampia ja tunteja merkattiin usein myös toteutuksen puolelle, kun palavereissa keskusteltiin toteutusratkaisuista. Pöytäkirjojen kirjoittaminen tapahtui usein muiden tehtävien ohella, jolloin tunnit kirjattiin osaksi muita tehtäviä.
Perehtymisen osalta ryhmän tunnit jäivät hieman alle suunnitelman. Myös perehtymisen tunteja merkittiin osaksi muita tehtäviä. Bergin perehtymiseen käytetyt tunnit on merkitty toteutuksen alle.
Määrittelyn työtunteja on suunniteltua vähemmän. Suurin ero on alustavan vaatimusmäärittelyn ja vaatimusmäärittelyn päivittämisen välillä. Bergin määrittelyn tunnit on merkitty osaksi toteutusta. Koska määrittelyyn ei käytetty helmikuussa tarpeeksi aikaa, jouduttiin määrittelyä tarkentamaan vielä huhtikuun aikana. Määrittelyyn olisi pitänyt myös varata enemmän aikaa.
Suunnittelun toteutunut tuntimäärä jäi suunniteltua pienemmäksi. Suurimmat erot toteutuneiden ja suunniteltujen tuntien osalta olivat Sihvosella ja Viinikaisella. Sihvonen oli sairaana viikolla, kun suunnittelua tehtiin eniten. Viinikainen käytti maaliskuussa enemmän aikaa koodaamiseen, jolloin suunnittelulle ei jäänyt tarpeeksi aikaa.
Toteutuksen työtunneissa on kaikista suurimmat eroavaisuudet suunniteltujen ja toteutuneiden tuntien välillä. Projektiryhmä ei huomioinut tunteja suunnitellessaan, että tilaaja ei käytä sovelluksessaan mitään valmista CSS-kirjastoa. Tyylitiedostojen puute ja projektiryhmän kokemattomuus sovelluksessa käytettävästä AngularJS-kirjastosta aiheutti suunniteltujen tuntien ylityksen. Myös kysymykseen vastaamisen osalta ryhmä käytti yhteensä 100 tuntia suunniteltua enemmän. Suunnitteluvaiheessa ryhmä ei huomioinut kirjata tehtäväksi luennolle liittymistä, joten jälkikäteen osa luennolle liittymisen tunneista kirjattiin kysymykseen vastaamiseen ja luentoseinä tehtäviin.
Testauksen kokonaistyötunneissa toteuma vastaa suunnitelmaa, vaikka osatehtävissä onkin suuria eroja. Testausvastaava laati testaussuunnitelmasta kattavan, jonka vuoksi testauksen suunnitteluun käytetyt tunnit ylittyivät. Ryhmä ei laatinut projektin aikana yksikkötestejä.
Viimeistelyn osalta toteutuneet tunnit vastaavat lähes suunnitelmaa. Berg vastasi Lehtomäen sijasta sovellusraportista ja käytti myös suunniteltua enemmän aikaa sovelluksen viimeistelyyn, koska muilla projektiryhmän jäsenillä ei ollut siihen aikaa kesäkuussa. Viinikainen auttoi Bergiä Sihvosen sijasta sovellusraportissa ja sovelluksen viimeistelyssä. Projektin viimeisillä viikoilla projektiraporttiin käytettiin arviolta 10 tuntia ja viimeistelyyn ja kokoamiseen 5 tuntia.
Oheiskurssien toteutuneet tunnit ovat huomattavasti suunniteltua pienemmät. Projektiryhmän jäsenistä vain Berg ja Viinikainen suorittivat puhe- ja kirjoitusviestinnän kurssin.
Suurimmat erot tunneissa ryhmän jäsenillä on Bergin ja Eljurkaevin välillä. Eljurkaev aloitti varusmiespalveluksen heinäkuussa, eikä voinut enää käyttää tunteja projektille. Kokonaisuudessaan projektiryhmä jäi suunnitelluista tunneista 30 tuntia, joka vastaa parin päivän työmäärää koko ryhmältä.
Kuvassa 6.3 on esitelty ryhmän jäsenten yhteenlaskettujen työtuntien jakautuminen tehtäväkokonaisuuksittain. Luvun kuvien piirakkagraafit on muodostettu kuvan 6.1 taulukosta.
Berg toimi projektissa varaprojektipäällikkönä ja vastasi testauksesta. Perehdytyksen työtunnit Berg merkitsi osana toteutusta. Tunnit projektin aikana painottuivat toteutukseen, mutta Berg osallistui myös muihin tehtäviin.
Muut ryhmän jäsenet eivät ehtineet osallistua testauksen suunnitteluun- ja suoritukseen, mikä näkyy kuvassa 6.4 muita suurempana osuutena testauksessa ja viimeistelyssä.
Eljurkaevin vastuulla oli vaatimusten määrittely ja sovelluksen kehitys. Vastuu määrittelystä näkyy muita suurempana osuutena määrittelyssä. Kehitykseen käytetyt tunnit jakautuivat melko tasaisesti käyttöliittymän ja palvelimen kehitykseen.
#Lehtomäen vastuulla oli käyttöliittymä, jonka suunnitteluun ja toteuttamiseen kului suuri osa hänen työtunneistaan. Tämä johtui siitä, että Lehtomäki halusi tässä projektissa perehtyä erityisesti käyttöliittymän suunnitteluun ja toteutukseen. Oheiskursseista Lehtomäki osallistui vain projektin hallinnan kurssille.
Sihvonen toimi projektipäällikkönä koko projektin aikana, mikä näkyy kuvassa 6.7 suurena osuutena projektin suunnittelussa ja hallinnassa.
Viinikaisen vastuualue oli palvelimen kehittäminen. Viinikainen käytti muutenkin huomattavasti aikaa sovelluksen kehittämiseen, mistä johtuen hänen työtuntinsa ovatkin hyvin vahvasti toteutuspainotteiset. Nämä ovat selkeästi havaittavissa kuvassa 6.8.
Luvussa kuvataan projektissa käytettyä prosessia ja toteutunutta aikataulua. Prosessin osalta ryhmä noudatti Scrumia luvussa 7.1 kuvatuin muutoksin. Projektin suunniteltu päättymispäivä oli toukokuussa, kun projektin saatiin päätökseen syyskuussa.
Projekti koostui suunnittelu- ja viimeistelyvaiheen lisäksi viidestä kehitysvaiheesta. Eri vaiheiden aloitus ja lopetus limittyivät, mutta vaiheet suoritettiin yksi kerrallaan.
Projektin ensimmäisessä vaiheessa suunniteltiin projektin läpivientiä, ja laadittiin alustava vaatimusmäärittely. Ensimmäisen vaiheen jälkeen viidessä kehitysvaiheessa kehitettiin suunniteltuja ominaisuuksia olemassa olevaan sovellukseen. Projektin viimeinen vaihe koostui sovelluksen viimeistelystä, tulosten raportoinnista ja projektin päättämiseen liittyvistä tehtävistä.
Prosessimallina kehitysvaiheissa hyödynnettiin Scrumia tietyin muokkauksin. Projektissa yhden kehitysvaiheen eli Sprintin kesto oli peräkkäisten projektipalaverien välinen aika, eli keskimäärin kaksi viikkoa. Projektipalaverit vastasivat osittain Sprintin katselmointia, jossa projektiryhmä esitti kehittämiään ominaisuuksia projektiorganisaatiolle. Projektipalaverien jälkeen projektiryhmä piti Sprintin suunnittelu- ja retrospektiivitapaamiset viimeistään vuorokauden kuluessa projektipalaverista. Päivittäispalaverit ryhmä piti kaksi kertaa viikossa. Päivittäispalaverissa jokainen kehitystiimin jäsen kertoi vuorollaan, mitä on tehnyt edellisen palaverin jälkeen, mitä tulee tekemään seuraavaan palaveriin mennessä, ja mahdolliset työtä haittaavat esteet.
Tuotteen kehitysjono sijaitsi projektiryhmän Trello-tilillä, jonne myös tilaajan edustajilla ja ohjaajilla oli pääsy. Kehitysjonon päivittämisestä oli vastuussa vaatimusmäärittelyn vastuuhenkilö, joka toimi myös sovelluksen omistajana.
Koska projektipäälliköllä on eniten käytännön kokemusta Scrumista, toimi hän projektissa Scrum masterina. Scrum masterin tehtäviin kuului päivittäispalavereihin kutsuminen, Scrumin sääntöjen noudattaminen, työtä haittaavien esteiden poisto ja tilaajan kanssa kommunikointi.
Projektiryhmä noudatti projektin aikana edelläkuvattua Scrumia. Sprintin tuloksia ei hyväksytty erikseen kenenkään toimesta, mutta ryhmä julkisti sovelluksesta uuden version tilaajan ja ohjaajien koekäyttöön. Tulosten hyväksyntää ajatellen tuotteen omistajan rooli olisi kuulunut antaa tilaajan edustajalle.
Projekti alkoi 5.2.2015 ja päättyi syyskuun 2015 lopussa neljä myöhässä suunnitellusta päättymispäivästä. Toteutuneen aikataulun rakenne kuvassa 7.2 ei vastaa kuvan 7.1 suunniteltua aikataulua. Kehitysvaiheista toinen arvioitiin aivan liian lyhyeksi, mutta vastapainoksi kolmas ja neljäs vaihe osoittautuivat hyvin lyhyiksi aikajänteeltään. Viidennettä kehitysvaihetta jatkettiin projektin viimeistelyvaiheeseen. Ryhmän kaikilla jäsenillä oli kesäkuun jälkeen muita sitoumuksia, jonka vuoksi projekti viivästyi syyskuulle.
Projekti ei päättynyt suunnitelman mukaisesti toukokuun loppuun mennessä. Kolmannessa kehitysvaiheessa aloitettu kysymykseen vastaaminen osoittautui suunniteltua haastavammaksi, joten sitä jatkettiin neljännessä ja viidennessä kehitysvaiheessa. Viidennen vaiheen viiveen vuoksi saatiin sovellukselle hyväksyntä vasta kesäkuussa. Ryhmän jäsenten muiden sitoumuksien vuoksi viimeistelyvaihe viivästyi syyskuulle.
Kuvassa 7.2 on esitelty ryhmän käyttämien työtuntien jakauma viikoittain. Suunniteltu sovellusprojektin viikoittainen työmäärä oli 20 tuntia kutakin jäsentä ja sata tuntia koko ryhmää kohden. Toteutunut viikottainen työmäärä oli keskimäärin 10 tuntia jäsentä kohden. Projektin kuuden ensimmäisen viikon aikana ryhmä jäi huomattavasti suunnitellun tavoitteen alle. Käyttämällä enemmän aikaa projektille heti ensimmäisistä viikoista lähtien olisi projekti pysynyt aikataulussa.
Kuvassa 7.2 on esiteltynä Bergin työtunnit. Kuvasta voidaan huomata, että projektin alkuvaiheessa hänelle ei kertynyt paljoakaan tunteja, sillä Bergillä ei ollut tarvittavaa tieto-taitoa alkaa heti kehittämään sovellusta. Toisaalta oman aikansa vei myös projektirytmiin tottuminen ja sille ajan varaaminen. Viikot 14 ja 15 Berg oli ulkomaanmatkalla, josta johtuen kyseisillä viikoilla on huomattavasti vähemmän tunteja kuin muilla viikoilla.
Kuvassa 7.3 näkyvät Bek Eljurkaevin työtunnit. Ensimmäisinä kolmena viikkona hänelle kertyi tunteja huomattavasti suunniteltua vähemmän, koska projektin käynnistyessä oli vaikea tarttua tehtäviin työvälineiden ja alkuperäisen järjestelmän vierauden vuoksi. Projektin alun jälkeen työtunnit pysyivät melko tasaisena. Heinäkuusta syyskuulle Eljurkaev ei osallistunut kehitykseen muiden sitoumuksien vuoksi.
#Kuvassa 7.4 näkyvät Minna Lehtomäen työtunnit. Ensimmäisinä kolmena viikkona hän käytti työtunteja huomattavasti suunniteltua vähemmän, koska projektin käynnistyessä oli vaikea tarttua tehtäviin työvälineiden ja alkuperäisen järjestelmän vierauden vuoksi. Viikolla 9 Lehtomäelle ei kertynyt tunteja, koska hän oli kotona hoitamassa lastaan. Viikosta 10 eteenpäin tuntien kertyminen oli hänellä tasaista toukokuun loppuun. Kesäkuun jälkeen Lehtomäki ei muiden sitoumusten vuoksi voinut käyttää aikaa projektille.
Kuvassa 7.6 on esiteltynä Juhani Sihvosen viikoittaiset työtunnit. Helmikuussa hänen olisi pitänyt käyttää huomattavasti enemmän aikaa projektisuunnitelman kirjoittamiseen, jotta se olisi saatu hyväksyttyä nopeammin. Maaliskuun jälkeen viikkotyötunnit pysyivät melko tasaisina vastaten keskimäärin suuunniteltuja viikkotunteja. mukaiset. Viikolla 15 Sihvosella oli aikaa koodaukselle vähäisten työkiireiden takia. Huhti- ja toukokuussa sekä syyskuussa Sihvonen vastasi projektiraportin lisäksi projektin päättämiseen liittyvistä tehtävistä. Kesällä Sihvonen ei käyttänyt tunteja projektille.
Kuvassa 7.6. on esitelty Viinikaisen työtunnit. Viikolla 14 Viinikainen oli ulkomaanmatkalla, joten sen takia hänelle ei kertynyt tunteja kyseiseltä viikolta. Viinikainen oli kesäkuusta alkaen kokopäiväisessä työssä, joten hän ei ollut projektin käytettävissä.
Luvussa kuvataan projektissa tiedostetut riskit ja niiden arvioituja vaikutuksia projektin tuloksiin tai läpivientiin. Lisäksi kuvataan toimia niiden ennakoimiseksi ja ehkäisemiseksi sekä niistä toipumiseen. Projektin aikana jäsenten poissaolot ja kokemattomuus projektinhallinnassa aiheuttivat arvioitua suuremmat haittavaikutukset. Kokemattomuus projektinhallinnassa johti suunniteltua suurempiin työmääriin toteutusta suunniteltaessa. Kesäkuun jälkeen ryhmän jäsenillä oli muita sitoumuksia, joiden vuoksi projekti viivästyi neljällä kuukaudella.
Riskien arvioidut todennäköisyydet sekä niiden arvioidut ja toteutuneet haittavaikutukset on esitelty taulukossa 8.1. Todennäköisyyttä ja haittavaikutusta on arvioitu asteikolla pieni, keskinkertainen ja suuri.
Riski | Arvioitu todennäköisyys | Arvioitu haittavaikutus | Toteutunut haittavaikutus |
---|---|---|---|
Suunnitellun toteutusratkaisun puutteet | keskinkertainen | keskinkertainen | pieni |
Kehittäjien tietotaitojen puutteet | keskinkertainen | keskinkertainen | keskinkertainen |
Jäsenten poissaolot | keskinkertainen | pieni | keskinkertainen |
Kokemattomuus projektinhallinnassa | keskinkertainen | pieni | keskinkertainen |
Taulukko 8.1: Riskien todennäköisyydet ja haitat.
Suurimmat toteutuneet haittavaikutukset olivat kehittäjien tietotaitojen puutteissa ja kokemattomuudessa projektinhallinnassa. Projektin aikana ryhmä huomasi myös, että laadunvarmistuksen puute sekä tilaajan muuttuvat ja tarkentuneet vaatimukset olisi pitänyt kirjata riskiksi.
Projektiryhmä joutui päättämään tekniikat, joilla saadaan toivottuja toiminnallisuuksia toteutettua TIM-järjestelmään. Toteutusratkaisun toimivuutta oli vaikeata arvioida ennen kokeilua, joten ratkaisu olisi saatettu todeta huonoksi vasta toteutuksen jälkeen. Tästä johtuen ryhmä olisi voinut joutua toteuttamaan joitakin järjestelmän ominaisuuksia uudelleen vaatien lisää aikaa tai rajaamaan kyseisiä ominaisuuksia projektin ulkopuolelle.
Riskiä ehkäistiin tutustumalla etukäteen vaihtoehtoisiin toteutustekniikoihin mahdollisimman hyvin. Riskin toteutuessa oli mahdollista muuttaa tai vaihtaa käytettävää toteutustekniikkaa tai rajata joitakin toteutettavia ominaisuuksia projektin ulkopuolelle.
Projektiryhmä joutui päättämään long-poll-kirjaston, jota toteutuksessa käytetään. Projektin aikana ryhmä huomasi, että ryhmän tarpeisiin soveltuvaa kirjastoa ei ole. Ryhmä onnistui kuitenkin kehittämään oman version long-poll-tekniikasta vähäisellä työmäärällä.
Riskin toteutumisesta johtuen ryhmä joutui kehittämään oman long-poll-komponentin TIM-palvelinsovellukseen. Tästä ei kuitenkaan seurannut viivästystä muille tehtäville.
Ohjelmiston toteutuksessa käytettiin monia eri työkaluja ja tekniikoita, joista projektiryhmän jäsenillä ei ollut aikaisempaa kokemusta. Näin ollen ryhmä ei aina osannut ennakoida mahdollisia ongelmakohtia. Riskin ehkäisemiseksi ryhmän jäsenet tutustuivat työkaluihin ja tekniikoihin sekä osallistuivat teknisen ohjaajan pitämään perehdytykseen.
Projektisuunnitelmassa oli ennakoitu työtunneissa tutustuminen tekniikoihin, mutta erityisesti AngularJS-kirjaston oppiminen oli hidasta ja koodaus kyseisellä tekniikalla oli arvioitua hitaampaa. Riskin toteutumisesta seurasi suunniteltua suuremmat tunnit kehitysvaiheessa. Suuremmat työtunnit eivät kasvattaneet kokonaistyötunteja, koska projektipalavereihin oli suunniteltu tarvittavaa enemmän tunteja.
Projektin aikana ryhmän jäsenillä oli sekä suunniteltuja että ennakoimattomia poissaoloja. Riskiä hallitakseen ryhmän jäsenet tiedottivat omista poissaoloistaan muille ryhmän jäsenille ja pitivät huolen siitä, että muut tiesivät heidän sen hetkiset työtehtävät. Täten poissaolojen sattuessa muut ryhmän jäsenet pystyivät jatkamaan poissaolijan tehtäviä.
Riskin toteutumisesta seurasi projektin viivästyminen kolmella ja puolella kuukaudella. Toukokuun jälkeen ryhmän jäsenillä oli muita sitoumuksia, eikä projektia saatu päätettyä suunnitellussa aikataulussa.
Kaikilla projektiryhmän jäsenillä ei ollut kokemusta projektin läpiviemisestä, joten työmäärien ja aikataulun arvioiminen oli vaikeaa. Kokemattomuudesta huolimatta ryhmä sai jaettua työtehtävät tasaisesti ryhmän jäsenille.
Ryhmän jäsenet eivät osanneet arvioida vaadittavia työmääriä riittävällä tarkkuudella, jonka vuoksi toteutukseen kului tunteja huomattavasti suunniteltua enemmän. Kuitenkin kokonaisuutena toteutuneet työtunnit vastaavat suunniteltua. Tältä osin siis projektipäällikkö onnistui hyvin työtuntien arvioinnissa, mutta tuntien viikoittaisessa varaamisessa ja hallinnassa oli kaikilla jäsenillä haasteita.
Projektipäällikkö ei katsonut tarpeelliseksi raportoida projektin etenemisestä projektipalaverien välillä. Vähäisen raportoinnin vuoksi tilaajalla ei välttämättä ollut tarpeeksi hyvää kuvaa kehitettyjen ominaisuuksien tiloista, jonka vuoksi vaatimuksia jouduttiin tarkentamaan vielä toukokuussa.
Kaikkien ryhmän jäsenten mielestä sovellusprojekti oli positiivinen kokemus, joka opetti jäseniä projektimuotoisesta työskentelystä. Projektiryhmässä vallitsi projektin aikana hyvä ilmapiiri.
Olen osallistunut aiemmin yhteen ohjelmistokehitysprojektiin kandidaatinopinnoissani Aberdeenin yliopistossa, mutta kyseinen kurssi oli mielestäni kevyempi kuin tämä. Timppa-projekti vaati paljon aikaa, mutta uskon sen myös antaneen hyvää kokemusta projektityöskentelystä.
Projektin alkuvaiheessa tilaajilla tuntui olevan selkeä käsitys, mitä he halusivat uudelta järjestelmältä. Mutta kun aikaa kului ja projekti eteni, niin myös tilaajien vaatimukset hieman muuttuivat, mikä hieman vaikeutti projektin läpivientiä.
Projektissa sain hyvin kokemusta WWW-ohjelmoinnista ja keskityinkin enemmän JavaScript- ja HTML5-ohjelmointiin. Olin myös vastuussa testauksesta, joka vei huomattavasti odotettua enemmän aikaa.
Projektin alussa en tuntenut ketään jäsenistä entuudestaan, mutta mielestäni projektiryhmälle löytyi hyvä yhteinen henki jo projektin alusta alkaen. Ryhmähenki oli korkealla koko projektin ajan, ja kaikki tekivät kovasti töitä yhteisen päämäärän saavuttamiseksi. Projektin läpiviennissä auttoi ryhmän projektihuone ja se, että huoneessa usein oli joku muukin projektiryhmän jäsen. Suurin osa jäsenistä vietti paljon aikaa huoneessa, joten oli helppo kysyä ja tiedustella asioita kasvotusten.
Sovellusprojekti ja sen oheiskurssit opettivat minulle paljon projektityöskentelystä. Ne antoivat myös oppia ja kokemusta kokouskäytänteistä, sekä itsensä ilmaisemisesta kirjallisesti ja verbaalisesti.
Vaikka olen aikaisemminkin osallistunut projektimuotoiseen työskentelyyn yliopistossa (opetuspelin kehitys), on tämä projekti silti ollut ainutlaatuinen kokemus työn ja etenkin vastuun määrästä johtuen. Erilaisen projektista teki myös se, että sen päätuloksena ei ollut osallistujien opitut uudet taidot (kuten opetusprojekteissa on tapana), vaan tilaajan toimintaan liittyvän ongelman ratkaiseva ohjelmisto. Tämä asetti projektin osallistujien eteen tiettyjä haasteita, joista selviytymiseksi projektiryhmän jäsenet joutuivat sitoutumaan projektiin tavallista enemmän. Tästä päätellen projekti on antanut osallistujilleen tuntuman oikean elämän ohjelmistokehitystyöstä sekä toivon mukaan myös valmiudet suoriutua työelämän haasteista ohjelmistokehityksen monipuolisella alalla.
Projektin alussa pidetyssä roolien jaossa sain vaatimusmäärittelystä vastaavan roolin. Tehtävä miellytti kaikin puolin, vaikka en mielestäni suoriutunut siitä kovinkaan mallikkaasti. Vaatimusmäärittelyn kannalta tärkein ajankohta sattui samaan aikaan uuden lukukauden alun kanssa, jolloin oli reilusti muitakin sitoumuksia. Vaatimusten tarkan ja kunnollisen kirjaamisen motivaation puutteen aiheutti myös se, että kaikki muutkin kehitysryhmän jäsenet osallistuivat samoihin palavereihin tilaajan kanssa. Kaikki kehittäjät tiesivät muutenkin, mitä tilaaja toivoo kehitettävältä ohjelmistolta.
Ohjelmiston varsinainen kehitys oli kaikista miellyttävin osa projektista. Olen erityisen iloinen siitä, että pääsin kehittämään vastuullani olleita ohjelmiston ominaisuuksia kaikilla järjestelmän arkkitehtuurin kerroksilla käyttöliittymästä aina tietokantaan asti. Tämä arkkitehtuuriviipalepohjainen työnjako luonnollisesti antoi paremman mahdollisuuden kehittyä kehittäjänä ja nähdä tekemänsä työn monesta eri näkökulmasta.
Suuri haaste (tai etu, näkökulmasta riippuen) oli myös se, että projektiryhmä ei aloittanut uuden järjestelmän kehitystä alusta asti, vaan sai jatkokehitettäväksi olemassa olevan järjestelmän. Tälläisestä tehtävästä minulla itselläni ei ollut aikaisempaa kokemusta. Suuri osa projektin alkua menikin olemassa olevaan koodin tutustumisen ja ymmärtämisen merkeissä, joka ei aina ollut helppoa. Kehityksessä myös jouduttiin pitämään mielessä ja noudattamaan aikaisempien järjestelmän kehittäjien omaksumia käytäntöjä. Tällöin järjestelmän koodi pysyisi loogisena ja yhtenäisenä, jotta tulevien järjestelmän jatkokehittäjien olisi helpompaa jatkaa kehitystä. Tämä toi puolestaan omia haasteita, joista projektiryhmä selviytyi mainiosti, mistä todisteena on siisti ja ymmärrettävä lähdekoodi.
Kaiken kaikkiaan projekti aiheutti paljon positiivisia emootioita ja kokemuksia, sekä antoi mahdollisuuden kehittää monipuolisia työskentely- ja viestintätaitoja.
Olen aikaisemmin osallistunut projektimuotoiseen työskentelyyn sekä yliopistossa monitieteisen työelämäprojektin merkeissä että työharjoitteluni aikana. Tämä projekti erosi melko paljon näistä aikaisemmista projekteista, koska kaikki projektin jäsenet olivat samalta alalta, kun puolestaan aikaisempi kokemukseni on vain monitieteisestä työskentelystä. Ryhmän jäsenten samankaltainen opiskelutausta näkyi erityisesti siinä, että ajattelu oli samanlaista. Joissain tilanteissa tämä oli etu, sillä se helpotti keskinäistä keskustelua ja toisten ideoiden ymmärtämistä sekä neuvoa oli tarvittaessa helppo kysyä muilta. Toisaalta se vähensi erilaisten näkökulmien määrää, jonka vuoksi ideoita toteutukseen oli varmasti vähemmän kuin esimerkiksi monitieteisessä projektissa.
Projektin alussa minua vähän jännitti, koska olin ainut nainen ryhmässä. Se ei mielestäni näkynyt muiden ryhmän jäsenten käyttäytymisessä, vaan minua kohdeltiin samalla lailla kuin muitakin. Ryhmähenki alkoi muodostua siinä vaiheessa, kun ryhmän jäsenet alkoivat työskennellä enemmän projektihuoneessa, eli ei aivan heti. Loppuajasta kuitenkin meillä oli paljon hyviä keskusteluja projektihuoneessa, ja hommat alkoivat sujuakin paljon paremmin.
Projektista teki omalla kohdallani hankalan se, että oman työmme pohjana oli itselleni vierailla tekniikoilla toteutettu ja suurikokoinen sovellus. Sovelluksen rakennetta ja toteutusta oli hankala ymmärtää, sekä kehitysvälineet olivat aivan vieraita. Minulla ei ollut kokemusta Pythonista, JavaScriptistä, AngularJS:stä, HTML5-ohjelmoinnista tai muutenkaan verkkosovellusten kehittämisestä. Halusin kuitenkin oppia erityisesti käyttöliittymäkehitystä, joten otinkin vastuulleni hyvin pitkälle käyttöliittymän suunnittelemisen ja osia sen toteutuksesta. Suurimman osan ajasta työskentelin JavaScriptin ja HTML:n parissa. Erityisesti lopussa otin tehtäväkseni ulkoasun viimeistelyn, jolloin CSS tuli myös tutuksi. Olenkin tyytyväinen työnjakoon omalla kohdallani, koska opin käyttöliittymän tekemisestä paljon uusia taitoja ja tekniikoita.
Minulla ei ollut ennen projektia kokemusta projektipäällikön tehtävistä. Muiden ryhmän jäsenten nopeasti kieltäydyttyä päällikön tehtävistä otin tehtävän mielelläni vastaan. Tavoitteena projektissa minulla oli kehittää projektinjohtamisen osa-alueita ja viestintätaitoja.
Projektissa laadittavien dokumenttien kirjoittaminen oli projektissa haastavaa ja välillä myös turhauttavaa.
Projektipäällikkönä pyrin pitämään itseni tietoisena kunkin ryhmän jäsenen nykyisistä ja tulevista tehtävistä. Pyrin pitämään tehtävien jakautumisen hyvin itseohjautuvana, jolloin kukin ryhmän jäsen pääsi tekemään mieleisiään tehtäviä. Välillä joihinkin tehtäviin käytettiin mielestäni liikaa aikaa, jolloin jouduin muistuttamaan projektin tavoitteista ja prioriteeteista.
Olin projektin aikana puolipäiväisenä töissä, mikä osaltaan haittasi yhteistoimintaa muun ryhmän kanssa. Usein työaikani projektille oli vasta klo 16 jälkeen, kun muut jo lopettivat päivittäisen työn projektille. Projektiryhmä oli kuitenkin erinomainen. Kaikki ymmärsivät vastuunsa ja tekivät töitä sovittujen tuntien mukaisesti.
Kokonaisuutena sovellusprojekti oli positiivinen kokemus. Projektin aihe oli mielenkiintoinen. Projektin aikana pääsin tutustumaan minulle ennestään vieraisiin ohjelmointikieliin.
En ollut aikaisemmin ollut mukana näin suuren työmäärän ryhmäprojektissa. Myös valmiin sovelluksen kehittäminen oli minulle uusi asia
Varsinkin alussa oli hieman hankala päästä käsiksi projektiin, sillä valmista koodia oli huomattavan paljon, ja siihen tutustuminen vei oman aikansa. Myöskään sovelluksessa käytettävät tekniikat eivät olleet minulle ennestään tuttuja. Pythonia olin käyttänyt vain vähän, ja JavaScriptiinkin vain tutustunut. AngularJS-kirjasto oli minulle täysin uusi.
Projektin aikana opin huomattavan paljon verkkosovellusten kehittämisestä ja erilaisista tekniikoista. Varsinkin kommunikointi palvelimen ja päätelaitteiden kanssa kävi itselleni melko tutuksi. Koin projektista olevan todella paljon hyötyä oppiessani aikaisempaa paremmaksi verkkosovellusten kehittäjäksi.
Projektiryhmässä vallitsi hyvä ilmapiiri, ja huoneeseen oli mukava tulla koodailemaan. Projektin loppuvaiheessa itselleni kertyi todella paljon tunteja, sillä sovelluksen valmistuminen jäi hieman viime tinkaan. Lopussa tunteja oli myös helppo kerryttää, kun tekniikat olivat jo tulleet tutuksi ja oli selkeää, mitä tulee kehittää.
Timppa-projekti toteutti Sovellusprojekti-kurssilla keväällä ja kesällä 2015 Jyväskylän yliopiston tietotekniikan laitokselle muutoksia TIM-järjestelmään. Projektissa lisättiin TIM-järjestelmään opettajille mahdollisuus luoda luentoja, laatia ja kysyä kysymyksiä, sekä tarkastella vastausten jakaumia. Oppilas voi muutoksien ansiosta vastata kysymyksiin sekä kysyä ja keskustella luennon sisällöstä luentoseinällä. Projektin tulokset luovutettiin tilaajalle syyskuun lopussa.
Projektin suurimpana riskinä toteutui kehittäjien tietotaidon puutteet. Ryhmän jäsenillä ei ollut kokemusta projektissa käytetyistä työkaluista ja tekniikoista, jonka vuoksi ryhmä ei osannut ennakoida kaikkia aikaa vieviä tehtäviä. Riskin toteutumisesta seurasi suunniteltua suuremmat tunnit kehitysvaiheessa. Suuremmat työtunnit eivät kuitenkaan kasvattaneet kokonaistyötunteja, koska projektipalavereihin oli suunniteltu tarvittavaa enemmän tunteja.
Jäsenten työtuntien toteuma kokonaisuutena vastaa suunnitelmaa. Projektin kokonaistuntimäärä jäi noin 30 tuntia tavoitteesta, joka vastaa vajaan viikon työtä projektiryhmän osalta. Suurimmat poikkeamat toteutuneissa tunneissa suunniteltuihin verrattuna ovat toteutuksessa, oheiskursseissa, perehtymisessä ja palavereissa.
Projektin suunniteltua päättymispäivä oli toukokuun lopussa. Tilaajalta ei kuitenkaan saatu vielä toukokuussa hyväksyntää sovelluksella, koska tilaajan edustajien mielestä sovellus ei sisältänyt heidän haluamiin ominaisuuksia. Sovelluksen hyväksyntä viivästyi heinäkuulle, jonka vuoksi myös sovellusraportti ja projektirapotti viivästyivät. Projekti viivästyi siten neljä kuukautta. Suurimmat syyt viivästymiselle ovat arvioitua pienemmän viikottaiset työtunnit.
Sovelluksen ominaisuuksien kehittämisen lisäksi sovellusprojekti antoi projektiryhmän jäsenille käytännön kokemusta projektimuotoisesta työskentelystä sekä sen vaatimuksista ja työtavoista.
[1] | Niko Mononen, Veli-Mikko Puupponen, Ilkka Rautiainen ja Atte Söderlund, ”Hälyri-projektiraportti”, saatavilla PDF-muodossa URL:https://trac.cc.jyu.fi/projects/sovproj/raw-attachment/wiki/Halyri/Projektiraportti/Halyri_projektiraportti_0.2.0.pdf , Jyväskylän yliopisto, tietotekniikan laitos, 2014. |
[2] | Jukka-Pekka Santanen, ”Tietotekniikan Sovellusprojektien ohje”, saatavilla HTML-muodossa URL: http://www.mit.jyu.fi/opetus/sovellusprojektit/projohje.html , Jyväskylän yliopisto, tietotekniikan laitos, 29.1.2013. |
[3] | Guido van Rossum, Barry Warsaw and Nick Coghlan, "PEP 8 - Style Guide for Python Code", saatavilla HTML-muodossa URL: https://www.python.org/dev/peps/pep-0008/ , 1.8.2013. |
[4] | Nick Downie, Charts.js, saatavilla HTML-muodossa URL: http://www.chartjs.org/ , viitattu 22.5.2015. |
[5] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, Järjestelmätestausraportti #1", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[6] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, Järjestelmätestausraportti #2", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[7] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, Järjestelmätestaussuunnitelma", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[8] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, projektisuunnitelma", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[9] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, sovellusraportti", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[10] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, vaatimusmäärittely", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[11] | Matias Berg, Bek Eljurkaev, Minna Lehtomäki, Juhani Sihvonen ja Hannu Viinikainen, "Timppa-sovellusprojekti, 1. lähdekoodi katselmointi", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |
[12] | Mika Lehtinen, "Sovellusprojekti Timppa, 2. lähdekoodin katselmointi", Jyväskylän yliopisto, tietotekniikan laitos, 2015. |