Tekijät:

• Ismo Huhtiniemi (IH)
• Paavo Itkonen (PI)
• Joonas Lattu (JL)
• Petteri Palojärvi (PP)
• Seppo Tarvainen (ST)

Dokumentin nimi: Timber-sovellusprojekti, projektiraportti

Tiivistelmä: Timber-projekti kehitti Jyväskylän yliopiston tietotekniikan laitoksella kehitettyyn TIM-oppimisympäristöön WWW-sovelluksen, jolla voidaan kirjata merkintöjä ja huomioita TIM-dokumentteihin. Sovelluksen avulla TIM-ympäristössä oleviin tehtävien vastauksiin voidaan kirjata merkintöjä, jotka sisältävät vakioidun palautteen ("velppi") ja pistemäärän sekä mahdolliset tarkastajan ja vastaajan kommentit. 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:

Timber-projekti kehitti Jyväskylän yliopiston tietotekniikan laitoksella kehitettyyn TIM-oppimisympäristöön WWW-sovelluksen, jolla voidaan luoda merkintöjä ja huomioita TIM-dokumentteihin.

Ryhmä:

• Ismo Huhtiniemi
• Paavo Itkonen
• Joonas Lattu
• Petteri Palojärvi
• Seppo Tarvainen

Tilaajat:

• Vesa Lappalainen
• Antti-Jussi Lakanen

Ohjaajat:

• Jukka-Pekka Santanen
• Mika Lehtinen

Yhteystiedot:

• Sähköpostilistat: timber@korppi.jyu.fi ja timber_opetus@korppi.jyu.fi
• Sähköpostiarkistot: https://korppi.jyu.fi/kotka/servlet/list-archive/timber ja https://korppi.jyu.fi/kotka/servlet/list-archive/timber_opetus

1. Johdanto

Timber-projekti kehitti kevään 2016 Sovellusprojekti-kurssilla TIM-oppimisympäristöön WWW-sovelluksen yhdenmukaistamaan ja helpottamaan tehtävien vastausten arviointia. Kehitetyllä sovelluksella tehtävän tarkastaja voi kirjata merkintöjä tehtävän vastauksiin antaen palautetta puutteista, virheistä ja ansioista. Merkintöihin voivat tarkastaja ja vastaaja sisällyttää myös kommentteja, joilla voidaan muodostaa viestiketjuja.

Projektiraportin laatimisessa on hyödynnetty Kepler-projektin projektiraporttia [1] ja sovellusprojektien ohjetta [2] sekä Timber-projektin projektisuunnitelmaa [3], vaatimusmäärittelyä [4] ja käsitteiden määrittelyä [7]. Projektissa laadittiin myös sovellusraportti [5], sovelluksen käyttöohje [6], järjestelmätestaussuunnitelman versiot [12] ja [13], järjestelmätestausraportit [14] ja [15] sekä luokkadokumentit asiakas- [10] ja palvelinsovellukselle [11].

Luvussa 2 esitellään dokumentissa käytettävät termit. Luvussa 3 käsitellään projektin taustaa ja tavoitteiden toteutumista. 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 toteutumista ja vaikutuksia projektin läpivientiin ja tuloksiin. Luvussa 9 kuvataan ryhmän jäsenten kokemuksia ja oppimaa projektista.

2. Termit

Luvussa kuvataan projektin aihealueeseen, tietojärjestelmään ja toteutustekniikoihin liittyviä termejä. Tarkemmat määritelmät kohdealueen termeistä on kuvattu käsitteiden määrittely -dokumentista [7].

2.1 Kohdealueen termejä

Kohdealueeseen liittyviä termejä ovat seuraavat:

• Avainsanan (engl. label) avulla velppejä voidaan ryhmitellä eri kategorioihin. Velppiin voi olla liitetty useampikin kuin yksi avainsana, mutta avainsanan liittäminen velppiin ei ole pakollista.
• Itsearvioinnissa opiskelija tarkastaa oman tehtävän vastauksen itse.
• Merkintä (engl. annotation) sisältää velpin, pistemäärän ja mahdollisen vapaan kommentin. Merkintäikkunassa tarkastaja voi myös määritellä, ketkä merkinnän voivat nähdä.
• Opettaja vastaa tehtävien luomisesta TIM-dokumenttiin ja usein myös tehtävien tarkastamisesta.
• Opiskelija vastaa TIM-dokumentissa olevaan tehtävään ja tallentaa vastauksen tarkastamista varten.
• Reunamerkintä (engl. margin annotation) on kappaleen reunaan sijoittuva merkintä, jos merkintää ei voida tai haluta laittaa suoraan huomionarvoisen asian kohdalle.
• Tarkastusalue (engl. assesment area) on TIMin dokumentti, kappale tai tehtävä. Siihen voidaan kirjata merkintöjä sekä liittää velppikokoelmia.
• TIM (The Interactive Material) on Jyväskylän yliopistossa kehitetty WWW-oppimisympäristö.
• Velppi (engl. velp) on vakioitu huomio, jolla tarkastaja voi osoittaa puutteen, virheen, ansion tai muun huomionarvoisen asian opiskelijan tallentamassa vastauksessa.
• Velppikokoelma (engl. velp group) on joko oletuskokoelma tai käyttäjän luoma kokoelma. Jokainen velppi kuuluu johonkin kokoelmaan. Jos käyttäjä ei toisin valitse, hänen luomansa velppi sijoitetaan hänen henkilökohtaiseen tai dokumentin oletuskokoelmaan.
• Vertaisarvioija on opiskelija, joka tarkastaa toisen opiskelijan tekemän tehtävän.

2.2 Ohjelmistoja ja teknisiä termejä

Ohjelmistoja ja teknisiä termejä ovat seuraavat:

• AngularJS on TIMissä ja kehitetyssä sovelluksessa käytetty avoimen lähdekoodin JavaScript-ohjelmistokehys.
• Docker on sovellusympäristö, jossa kehitettyä sovellusta ajetaan.
• Git on hajautettu versiohallintajärjestelmä.
• PyCharm on kehitysympäristö, jolla sovellusta kehitettiin.
• Python on TIMin ja sovelluksen kehittämisessä käytetty ohjelmointikieli.
• SQL (Structured Query Language) on tietokantojen luomiseen ja hallintaan kehitetty ohjelmointikieli.
• Trello on projektissa käytetty tehtävien- ja vaatimustenhallintaohjelma.
• YouSource on Jyväskylän yliopistossa Git-versiohallintaohjelmistoa tukeva lähdekoodien julkistusjärjestelmä.

3. Tavoitteiden toteutuminen ja tulokset

Timber-projekti kehitti tietotekniikan laitoksella toteutettuun TIM-oppimisympäristöön tehtävien palautteenantosovelluksen. Projektiryhmä sai toteutettua sovelluksesta prototyypin tietotekniikan laitoksen koekäyttöön. Luvussa käsitellään Timber-projektissa toteutetulle sovellukselle ja muille tuloksille sekä projektiryhmän jäsenille asetettuja tavoitteita ja näiden toteutumista sekä kohdealueen taustatietoja.

Projektiryhmä laati sovellukseen liittyvinä dokumentteina mm. käyttöohjeen, sovellusraportin sekä vaatimusmäärittelydokumentin. Lisäksi projektiryhmä muodosti asiakas- ja palvelinsovellukselle luokkadokumentaatiot.

Sovellusprojektikurssin oppimistavoitteena oli oppia projektimuotoista työskentelytapaa käytännön kautta. Lisäksi ryhmän jäsenet asettivat kurssin alussa henkilökohtaisia oppimistavoitteita, jotka ryhmän jäsenet kokevat saavuttaneensa.

3.1 Taustaa

Projektin tilaaja oli Jyväskylän yliopiston tietotekniikan laitos. Tietotekniikan laitos käyttää kursseilla TIM-oppimisympäristöä.

TIM-oppimisympäristö sisältää vuorovaikutteisia tehtäviä, joita hyödynnetään mm. tenteissä. TIMissä tehtävien vastauksia arvostellaan joko automaattisesti tai käsin muita ohjelmia apuna käyttäen. Käsin tarkastaminen ja pisteiden kirjaaminen on vaivalloista. Opiskelijat eivät siten saa juurikaan sanallista palautetta, vaan ainoastaan tehtävän kokonaispistemäärän. Opettajat ovatkin kaivanneet sovellusta, jolla pisteidenlasku tarkistettaviin tehtäviin nopeutuisi merkittävästi sekä vakioiduilla apulauseilla voisi antaa palautetta puutteista, virheistä ja onnistumisesta. Lisäksi useamman tarkastajan antamat palautteet ja pisteet tulisi saada yhtenevimmiksi.

3.2 Kehitetty sovellus

Timber-projektissa kehitettiin sovellus osaksi TIM-oppimisympäristöä. Sovelluksella voi kirjata merkintöjä TIM-dokumenteissa oleviin kappaleisiin, tekstiin ja tehtävien vastauksiin. Merkinnät sisältävät aina jonkin velpin, joka puolestaan kuuluu ainakin yhteen velppikokoelmaan.

Velppikokoelmat voivat olla käyttäjän henkilökohtaisia tai ne voidaan liittää TIMin dokumenttiin tai kansioon. Velppikokoelmien avulla käyttäjä saa helposti kaikki tarvitsemansa velpit tietyn tyyppistä tehtävää varten. Niiden avulla voidaan myös hallita velppien käyttöoikeuksia, sillä käyttäjä voi käyttää ainoastaan niitä velppejä, joiden velppikokoelmiin hänellä on oikeudet.

Projektissa kehitetylle sovellukselle asetetut välttämättömät tavoitteet toteutuivat suurelta osin, mutta joitain olennaisia tavoitteita sovittiin tilaajan kanssa jatkokehitykseen. Sovellukseen kehitettiin toiminnallisuudet velppien ja avainsanojen hallintaan sekä merkintöjen kirjaamiseen, muokkaamiseen, poistamiseen ja näkyvyyden hallintaan. Lisäksi sovellukseen kehitettiin tarvittavat toiminnallisuudet velppikokoelmien luontiin. Sovelluksen toimintoja varten toteutettiin selainpohjainen käyttöliittymä. Käyttöoikeuksien hallinta sovelluksessa toteutuu TIMin dokumentin hallintanäkymän kautta. Projektiryhmän kehittämä prototyyppi voidaan ottaa tietotekniikan laitoksella koekäyttöön.

Sovelluksen toiminnot ovat kaikille TIMin käyttäjille sallittuja, joten kuka tahansa voi tehdä merkintöjä kaikkiin näkemiinsä dokumentteihin. Käyttäjä voi poistaa oman merkintänsä, muokata sen näkyvyyttä ja pistemäärää. Käyttäjä voi kommentoida kaikkia näkyviä merkintöjä merkintäikkunassa. Myöhemmin sovelluksen on tarkoitus korvata TIMissä oleva kommentointi. Useita olennaisiakin toimintoja sovittiin tilaajan kanssa jatkokehitykseen työtuntien ja aikajänteen rajallisuudesta johtuen.

Sovelluksen toiminnallisuuksista sovittiin tilaajan kanssa jatkokehitykseen mm. tarkempi ja laajempi käyttöoikeuksien hallinta, merkintöjen muokkausominaisuuksia, merkintäikkunan viimeistely, käytettävämpi sovelluksen ikkunointi, tarkempi ja monipuolisempi pisteiden laskulogiikka sekä ilmoitukset merkinnöistä. Lisäksi sovelluksen liittäminen TIMin master-haaraan sovittiin tilaajan kanssa jatkokehitykseen.

Sovelluksen kokonaisrakennetta on kuvattu Sovellusraportin [5] luvussa Sovelluksen kokonaisrakenne. Sovelluksen käyttöliittymän rakennetta ja toimintaa on kuvattu Käyttöohjeessa [6].

3.3 Sovelluksen toteutuneet tavoitteet ja toiminnallisuudet

Select velp -välilehti sisältää seuraavat toiminnallisuudet:

• Velpin lisäyksessä voidaan määrittää nimi, pistemäärä, avainsanat ja velppikokoelmat.
• Velpin muokkauksessa voidaan määrittää nimi, pistemäärä, avainsanat ja velppikokoelmat.
• Velppejä voidaan suodattaa avainsanojen ja velppien nimien mukaan.

Manage velps -välilehti sisältää seuraavat toiminnallisuudet:

• Velppikokoelmien oletusnäkyvyys ja näkyvyys voidaan määrittää tarkastusalueessa.
• Velppikokoelman lisäyksessä voidaan määrittää velppikokoelman nimi jasijainti. Velppikokoelma voidaan liittää dokumenttiin, kansioon tai asettaa henkilökohtaiseksi velppikokoelmaksi.
• Velppikokoelmien oikeuksia voidaan muokata velppikokoelman linkin kautta.

Summary-välilehti sisältää seuraavat toiminnallisuudet:

• Dokumentin merkintöjen listauksessa näkyvät merkinnöissä käytetyt velpit ja pistemäärät.
• Välilehdellä näytetään dokumentin merkintöjen yhteispistemäärä.
• Merkintälistauksen kautta voidaan siirtyä dokumentissa olevaan merkintään.

Dokumentin tekstissä tai tehtävän vastauksessa (pluginissa) oleva merkintäikkuna sisältää seuraavat toiminnallisuudet:

• Merkinnän kirjannut käyttäjä voi muokata merkinnän pistemäärää tai näkyvyyttä.
• Merkintään voi lisätä kommentin.
• Merkinnän kirjannut käyttäjä voi poistaa merkinnän, jos merkinnässä on vähemmän kuin kaksi kommenttia.

Vaikka suuri osa välttämättömistä toiminnallisuuksista saatiin projektissa toteutettua, joitain toiminnallisuuksia sovittiin tilaajan kanssa jatkokehitykseen. Merkittävimmät toteutumattomat toiminnalliset kokonaisuudet olivat vertaisarviointimahdollisuus, sähköposti-ilmoitukset merkintöihin liittyen ja korostusten hallinta. Sovellusraportin [5] luvusta Jatkokehitysideat löytyvät jatkokehitykseen sovitut toiminnallisuudet.

3.4 Projektin tulokset

Sovelluksen ohella projektiryhmä toteutti seuraavat tulokset:

• Ajankäyttöraportti sisältää ryhmän jäsenten kirjaamat työtunnit sekä niiden jakautumisen eri tehtäväkokonaisuuksille ja tehtäville.
• Esittelymateriaalit sisältävät väliesittelyiden ja loppuesittelyn materiaalit ja muistiot.
• Lisenssisitoumus määrittää avoimen lähdekoodin ja avointen dokumenttien lisenssit, joiden puitteissa ryhmän jäsenet antavat muille oikeuksia projektissa toteuttamiensa tulosten hyödyntämiseen.
• Käsitteiden määrittely [7] sisältää sovelluksessa käytetettyjen käsitteiden kuvaukset.
• Käyttöohje [6] sisältää ohjeet sovelluksen käyttämiseen.
• Luokkadokumentaatiot [10] ja [11] sisältävät sovelluksen asiakas- ja palvelinsovellusten luokkien ja metodien kuvaukset.
• Lähdekoodi sisältää sovelluksen ohjelmointikielisen lähdekoodin kommentteineen.
• Palaverien dokumentit sisältävät projektiorganisaation palaverien esityslistat, pöytäkirjat ja tilakatsaukset.
• Projektiraportti kuvaa projektin suunniteltua ja toteutunutta läpivientiä käsitellen muun muassa tavoitteita, käytänteitä, resursseja, aikataulua ja riskien hallintaa sekä jäsenten oppimaa ja kokemuksia.
• Projektisuunnitelma [3] kuvaa projektin suunniteltua läpivientiä mm. tavoitteiden, resurssien, käytänteiden, tehtävienjaon ja niiden arvioitujen työmäärien, prosessin ja aikataulun sekä riskien hallinnan osalta.
• Sovellussuunnitelmat sisältävät laaditut käyttöliittymän hahmotelmat, tietokannan taulut ja oikeuksien hallinnan hahmotelmat.
• Sovellusraportti [5] kuvaa toteutetun sovelluksen rakenteen ja toteutusratkaisut, puutteelliset ja heikot toteutusratkaisut sekä jatkokehitysideat.
• Sähköpostiarkistot sisältävät kaikki projektille perustetuille sähköpostilistoille lähetetyt viestit.
• Testaussuunnitelmat [12] ja [13] kuvaavat järjestelmätestauksen testitapaukset.
• Testausraportit [14] [15] kuvaavat järjestelmätestauskertojen testitapausten tulokset.
• Vaatimusmäärittely [4] kuvaa kehitettävän sovelluksen toiminnalliset ja tekniset vaatimukset, tavoitteet ja rajoitteet.
• Vaitiolosopimus määrittää tilaajan toimittaman luottamuksellisen datan, jonka vaitioloon kukin jäsen sitoutuu allekirjoituksellansa.

Keskeneräinen projektisuunnitelma jäädytettiin 21.4.2016 järjestetyssä palaverissa. Sen täydentämistä ja korjaamista ei enää katsottu hyödylliseksi projektinhallinnalle, koska projekti oli jo niin pitkällä. Tilaaja vaati erillisen käyttöohjeen, kun alunperin käyttöliittymän kuvaus oli tarkoitus kirjata osaksi sovellusraporttia.

3.5 Jäsenten oppimistavoitteet

Tietotekniikan laitoksen Sovellusprojekti-opintojakson oppimistavoitteena on projektimuotoisen työskentelyn oppiminen ja harjoitteleminen käytännössä. Opintojakson aikana projektiryhmän jäsenet saavat kattavan käsityksen projektimuotoisesta ryhmätyöstä ohjelmiston toteutuksessa sekä sen vaatimuksista ja työtavoista. Olennaisia tehtäväkokonaisuuksia ovat ohjelmiston kehitykseen liittyen määrittely, suunnittelu, toteutus ja testaus. Erityisesti projektipäällikkö oppii ajankäytön suunnittelua ja hallintaa, projektin hallintaa sekä ryhmän johtamista.

Keskeistä sovellusprojektissa on oppiminen käytännön tekemisen kautta sekä aikaisemmilla opintojaksoilla opitun teoriatiedon soveltaminen käytäntöön. Jäsenet arvioivat omaa ja muiden työskentelyä projektin lopussa.

Ryhmätyö- ja viestintätaitojen oppiminen olivat erittäin tärkeässä osassa projektissa. Jäsenet oppivat ja harjoittelivat viestimään sekä ryhmän sisällä että muille projektiorganisaatioon kuuluville ja sidosryhmille. Projektin aikana jäsenet oppivat kirjoittamaan sisällöltään ja kirjoitusasultaan täsmällisiä dokumentteja. Projektin esittelyissä jäsenet saivat harjoittaa puheviestinnän taitojaan ja esiintymiskokemusta. Ryhmätyössä vaadittiin taitoja ongelmatilanteiden ratkaisemiseen ja ristiriitojen käsittelyyn. Ongelmatilanteissa jäsenet pyysivät ohjausta projektiryhmän muilta jäseniltä ja vastaavalta tai tekniseltä ohjaajalta, jotta viivästyksiltä ja virheiltä vältyttäisiin.

Edellisten tavoitteiden lisäksi jäsenet olivat asettaneet seuraavia henkilökohtaisia tavoitteita:

• Ismo halusi oppia projektin läpivientiä ja hallintaa sekä ryhmän johtamista ja ihmistuntemusta.
• Paavo halusi täydentää osaamistaan ohjelmoinnista sekä oppia ohjelmistokehitysprojektin läpivientiä käytännössä.
• Joonas halusi oppia isomman ohjelmistokokonaisuuden rakenteiden toteuttamista ja jatkokehitystä käytännössä. Lisäksi hän halusi oppia uusien kielten ja työkalujen käyttöä.
• Petteri halusi kokemusta ison sovelluksen kehitystyöstä ja ryhmätyöstä ohjelmistokehityksessä. Lisäksi hän halusi oppia ohjelmoimaan Pythonilla.
• Seppo halusi lisää kokemusta erityisesti käyttöliittymän suunnittelusta ja toteutuksesta sovelluskehityksessä.

Sekä ryhmän yhteiset että henkilökohtaiset oppimistavoitteet toteutuivat hyvin jokaisen ryhmän jäsenen osalta. Yksittäisten jäsenten asettamia tavoitteita ja oppimaa kuvataan myös luvuissa 9.1–9.5.

4. Organisaatio ja resurssit

Luvussa esitellään projektiorganisaatio, sen käytettävissä olleet resurssit ja projektiin liittyvät sidosryhmät, oheiskurssit ja perehdytykset. Projektin organisaatio pysyi koko projektin ajan samana, mutta resurssien käyttö poikkesi hieman suunnitelmasta mm. dokumentointityökalujen ja versionhallinnan osalta.

4.1 Projektiorganisaatio

Timber-projektiryhmään kuului neljä tietotekniikan laitoksen pääaineopiskelijaa: Ismo Huhtiniemi, Paavo Itkonen, Joonas Lattu ja Seppo Tarvainen. Petteri Palojärven pääaine on matematiikka. Projektipäällikkönä toimi Ismo Huhtiniemi ja varapäällikkönä Seppo Tarvainen.

Ismo Huhtiniemi on valmistunut JAMK:sta mediatekniikan insinööriksi, jonka jälkeen hän on ollut työelämässä. Hän on osallistunut projektikurssille Jyväskylän ammattikorkeakoulussa. Hän on töissään toteuttanut asiakkailleen XML-dokumentteja sekä asentanut CRM-ohjelmistoja ja tulostuslaitteita. Huhtiniemi on myös työskennellyt tietokantojen parissa. Maisteriopinnot hän aloitti syksyllä 2014. Hän harrastaa aikidoa ja tähän liittyvää seuratoimintaa.

Paavo Itkonen on tietotekniikan maisterivaiheen opiskelija suuntautumisvaihtoehtonaan ohjelmistotekniikka. Hänellä on aiempaa työkokemusta HTML-koodin käytöstä. Yliopistossa hän on täydentänyt osaamistaan mm. WWW-sovelluskurssilla ja käytettävyyskurssilla. Ohjelmointikokemusta hänelle on karttunut opintoihin sisältyviltä ohjelmointikursseilta, joilla hän oli käyttänyt mm. C#-, Java-, ja Python-ohjelmointikieliä. Timber-projektissa hänen roolinsa painottui sovelluksen front end -kehittämiseen.

Joonas Lattu on tietotekniikan maisterivaiheen opiskelija, joka suoritti luonnontieteiden kandidaatin tutkinnon kevään aikana. Suuntautumisvaihtoehtonaan hänellä on pelit ja pelillisyys. Aiempi ohjelmointitausta hänellä keskittyy pitkälti yliopiston eri kursseilla käytettyihin kieliin ja työkaluihin, kuten C#, Java ja SQL. Kurssin aikana etenkin Python ja SQLite tulivatkin hänelle tutuiksi, sillä hänen roolinsa projektissa painottui sovelluksen back end -puoleen.

Petteri Palojärvi on tietotekniikan maisterivaiheen opiskelija suuntautumisvaihtoehtonaan soveltava matematiikka. Sovelluskehityksestä hänellä on kokemusta lukuisilla kielillä (mm. C#, C++, Java, SQL, JavaScript, Matlab ja PHP), mutta ei kuitenkaan WWW-sovelluksista. Harrastuksen lisäksi hän on syventänyt ohjelmointiosaamistaan yliopiston kursseilla, joilla on hän tehnyt monia ohjelmointia vaativia harjoitustöitä. Timber-projektissa Petterin rooli painottui palvelimen ja tietokannan toteutukseen sekä sovelluksen suunnitteluun.

Seppo Tarvainen on valmistunut Lapin yliopistosta taiteen maisteriksi graafisen suunnittelun koulutusohjelmasta. Valmistumisen jälkeen hän aloitti tietotekniikan maisteriopinnot Jyväskylän yliopistossa ohjelmistotekniikan maisteriohjelmassa. Ohjelmointikielistä kokemusta hänellä mm. C#:sta, Javasta, Pythonista ja JavaScriptistä. Tämän lisäksi hän on toteuttanut WWW-sivustoja HTML:n ja CSS:n avulla. Hän on ollut mukana suunnittelemassa TIMin ulkoasua ja toteuttanut TIMin logon. Timber-projektissa hänen rooli keskittyi sovelluksen front end -kehittämiseen sekä sovelluksen suunnitteluun.

Tilaajan edustajina toimivat Jyväskylän yliopiston tietotekniikan laitokselta lehtori Vesa Lappalainen ja tohtoriksi keväällä valmistunut Antti-Jussi Lakanen. Jyväskylän yliopiston tietotekniikan laitokselta projektin vastaavana ohjaajana toimi Jukka-Pekka Santanen ja teknisenä ohjaajana Mika Lehtinen. Jyväskylän yliopiston IT-palvelut (Agoran ATK-lähituki) vastasi ryhmän käytössä olleista tietokonelaitteista ja ohjelmistoista. Lisäksi Pauli Kujala avusti ryhmää sovelluksen tietokannan suunnittelussa ja Johanna Silvennoinen käyttöliittymän suunnittelussa käytettävyyspäivän yhteydessä.

Sovellusprojektiin kuuluvalla viestintäkurssilla kirjoitusviestinnän opettajana toimi Juha Jalkanen ja puheviestinnän opettajana Hanna Kivimäki. Projektin väliesittelyt pidettiin puheviestinnän osuuden yhteydessä.

Projektiorganisaatioon tuli pieniä lisäyksiä suunnitelmaan nähden. Pauli Kujalan osallistumista sovellusprojektiin ei oltu suunnitelmaan kirjattu, mutta hänen panoksensa vaikutti tietokannan taulurakenteeseen. Lisäksi Johanna Silvennoinen antoi projektiryhmän jäsenille hyödyllistä palautetta käyttöliittymästä, jonka mukaan ryhmä saattoi kehittää sovelluksen käyttöliittymää toimivammaksi.

4.2 Projektin tilat, laitteet ja verkkolevyt

Tietotekniikan laitos tarjosi ryhmälle projektin ajaksi käyttöön lukittavan projektihuoneen AgC226.3. Projektin jäsenille annettiin projektihuoneeseen avaimet ja lisäksi RFID-avain, jolla pääsi Agoran sähkölukolla varustetuista ovista opiskelijoille tarkoitettuihin julkisiin tiloihin päivittäin klo 5:30–23:00 välisinä aikoina. Projektiryhmän jäsenillä oli käytössään neljä Windows 7 ja yksi Windows 10 -käyttöjärjestelmällä varustettua tietokonetta. Heillä oli käytössä myös toimistotarvikkeita, kuten nitoja, rei’itin, valkotaulu, valkotaulutusseja, valkotaulujen puhdistusnestettä, taulun pyyhintään sieni, lyijykyniä ja paperia.

Projektihuoneessa olevien laitteiden lisäksi ryhmä käytti omia tietokoneitaan ja IT-palveluiden tarjoamaa virtuaalista testauspalvelinta sovelluksen kehityksessä ja testauksessa sekä testattavien dokumenttien laatimisessa. Projektiryhmä käytti kokoustilaa AgC226.1 projektiorganisaation palavereissa. Tilassa oli käytettävissä Windows 7 -tietokone ja videoprojektori esityksiä varten.

Projektilla oli käytössään ryhmän jäsenille yhteinen verkkolevy \\fileservices.ad.jyu.fi\commonshare\mit-projektit-timber. Lisäksi projektin tiedostojen säilytystä varten oli WWW-sivuston verkkolevy hakemistossa \\sovpa7.cc.jyu.fi\timber ja osoitteessa http://sovellusprojektit.it.jyu.fi/timber. Ryhmä sijoitti TIM-oppimisympäristöön https://tim.jyu.fi/view/kurssit/tie/proj/2016/timber kaikki laatimansa dokumentit projektiorganisaation saataville. Sovelluksen kehitysvaiheissa testauspalvelimelle http://timber.it.jyu.fi päivitettiin noin kahden viikon välein uusi kehitysversio kaikkien projektiorganisaatioon kuuluvien jäsenten testattavaksi.

Sovellusprojektien avotilassa ryhmän käytettävissä oli yliopiston ylläpitämä monitoimitulostin. Ryhmän jäsenet pystyivät tulostamaan projektiin liittyvät dokumentit ilman heille henkilökohtaisesti aiheutuvia lisämaksuja. Ryhmällä oli mahdollisuus varata käyttöönsä videoprojektori, kannettava Windows PC, Olympuksen digitaalisanelin, MiniDisc-tallennin ja toimivuudeltaan epävarma MP3-tallennin.

Projektiryhmällä oli käytettävissä projektihuoneen vieressä taukotila, jossa on kahvinkeitin, vedenkeitin ja mikroaaltouuni. Tietotekniikan laitos tarjosi ryhmälle projektin ajaksi kahvit, kahvimaidot, teet ja mehut.

Projektin tilat, laitteet, testipalvelin ja ohjelmistot toteutuivat suunnitelman mukaisesti. Kahvinkeitin ja vedenkeitin uusittiin.

4.3 Dokumentointityökalut

Projektisuunnitelma, projektiraportti, esityslistat, projektipalaverien pöytäkirjat, muistiot, sovellusraportti, vaatimusmäärittely, käyttöohje, tilakatsaukset ja projektin läpivientiin liittyvät muut dokumentit laadittiin TIM-oppimisympäristössä suomen kielellä. Tarvittavat kaaviot TIM:n dokumenteissa sekä loppu- ja väliesittelyissä käytetyt lisäesitysgrafiikat laadittiin Google Drawings -sovelluksella. Tehtävien työtunnit kirjattiin Excel-taulukkolaskentaohjelmaan, jolla myös laadittiin tilakatsauksissa käytettävät grafiikat. Gantt-kaaviot laadittiin GanttProject-ohjelmalla. Sovelluskehitysvaiheessa projektiorganisaatio käytti Trelloa vaatimusmäärittelyn ylläpitoon ja sovelluskehityksen seurantaan.

Kaikkia projektisuunnitelmaan kirjattuja dokumentointityökaluja hyödynnettiin projektin aikana, mutta luokkadokumentaation generointityökaluja ei oltu suunniteltu. Asiakassovelluksen luokkadokumentaatio generoitiin JSDoc-ohjelmalla ja palvelinsovelluksen vastaava dokumentaatio Sphinx-ohjelmalla. TIMiin sijoitettavia dokumentteja ei myöskään siirretty suunnitellusti Google Drivestä TIMiin, vaan ne kirjoitettiin suoraan TIMiin.

4.4 Ohjelmointityökalut

Sovelluksen kehittäminen tapahtui lähinnä Python-kielellä. HTML5:ta, CSS3:ää ja JavaScriptiä käytettiin käyttöliittymän toteuttamiseen. CSS-tiedostot käännettiin suoraan SASS-tiedostoiksi. JavaScriptin kanssa käytettiin AngularJS- ja jQuery-apukirjastoja. Sovelluskehitysympäristönä käytettiin PyCharm-ohjelmaa.

Ohjelmointityökalut toteutuivat suunnitellusti, vaikka TIM alkoi käyttämään SASS-prosessointityökalua Timber-projektin aikana. Tämä ei vaikuttanut projektissa käytettyihin ohjelmointityökaluihin, sillä CSS-koodi on SASS-yhteensopivaa.

4.5 Versiohallinta

Projektiryhmä käytti lähdekoodin versioiden hallintaan Git-versiohallintaohjelmistoa ja YouSource-julkistusjärjestelmää. YouSource-järjestelmään perustettiin projektiryhmän jäsenille oma ryhmä (timber), projekti ja tarvittavat tietovarastot.

Versiohallintaa ei kirjattu projektisuunnitelmassa resursseihin, mutta versiohallinnan resursseja voidaan verrata versiohallinan käytänteisiin. Versiohallinnan resurssit toteutuivat suunniteltujen käytänteiden mukaisesti.

4.6 Luennot ja perehdytykset

Projektin ohella ryhmän jäsenet suorittivat kaksi oheiskurssia. Oheiskurssien työtunnit kirjattiin omalle tehtäväkokonaisuudelle työajanseurantasovelluksessa.

Viestintäkurssiin Projektiviestintä IT-alalla kuuluivat kirjoitus- ja puheviestinnän luennot ja ryhmätyöt sekä viestintäkurssilla käsiteltävien dokumenttien kirjoitusasun ja rakenteen muokkauksen työtunnit. Projektin aikana järjestettiin kaksi väliesittelyä, jotka olivat osa viestintäkurssia.

Kurssiin Sovellusprojektin hallintaa, viestintää ja työkaluja sisältyivät seuraavat opetustapahtumat:

• aloitusluento (3h),
• vaatimusmäärittely (2h),
• versiohallinta (2h),
• projektin johtaminen ja hallinta (4h),
• käytettävyyspäivä (6h) sekä
• tekijänoikeus ja sopimukset (2h).

Luennot ja perehdytykset toteutuivat suunnitelman mukaisesti. Järjestetyistä opetustapahtumista oli hyötyä ryhmän jäsenille projektimuotoisen työskentelyn sisäistämisessä. Varsinkin käytettävyyspäivänä saatu tieto ja palaute oli hyödyllistä käyttöliittymän kehittämiselle.

5. Käytänteet

Luvussa käydään läpi projektissa noudatettuja käytänteitä. Käytänteiden noudattaminen mahdollisti projektille asetettujen tavoitteiden saavuttamisen ja laadukkaiden tulosten toteutumisen.

Projektisuunnitelmaa jäädytettäessä kaikkia käytänteitä ei oltu mietitty loppuun asti. Suunnitelman viivästyminen vaikutti myös siihen, ettei projektin kaikkia suunniteltuja käytänteitä noudatettu. Palaverien tilakatsaukset olivat alussa puutteellisia, ja dokumenttien versioiden numerointi ei aina vastannut käytänteitä.

Koska kaikkia käytänteitä ei projektisuunnitelmassa ollut, ryhmän jäsenet saattoivat määrittää joitakin käytänteitä hetkellisenä valintana, joka jäi sittemmin elämään käytänteenä muissa vastaavissa tilanteissa.

5.1 Palaverit

Projektiorganisaatio piti alkuvaiheessa yhteisen palaverin vähintään kerran viikossa. Projektin edetessä sovelluskehityksen vaiheisiin palavereja pidettiin kerran kahdessa viikossa, jolloin ryhmä pystyi keskittymään enemmän sovelluksen kehitystyöhön. Palavereista kirjoitettiin pöytäkirjat, jotka hyväksytettiin projektiorganisaatiolla. Projektiorganisaatio piti myös kaksi ideointipalaveria, joista palaverin sihteeri toimitti projektiorganisaatiolle muistiot.

Tulevasta palaverista projektiryhmä toimitti esityslistan projektiorganisaatiolle vähintään vuorokausi etukäteen, jotta osallistujien oli mahdollista valmistautua palaveriin kunnolla. Tämä toteutui muiden paitsi viimeisen palaverin osalta, jolloin esityslista myöhästyi. Palaveri katsottiin päätösvaltaiseksi silloin, kun paikalla oli vähintään yksi projektiryhmän jäsen, tilaajan edustaja ja projektin vastaava ohjaaja Jukka-Pekka Santanen.

Palavereissa käsiteltiin edellisen palaverin jälkeen tapahtuneita asioita, jotka olivat vaikuttaneet projektin tuloksiin tai etenemiseen. Lisäksi palavereissa käsiteltiin tulevia toimenpiteitä ja tehtiin etenemiseen tarvittavat päätökset. Projektin läpivientiin liittyvät käytänteet sovittiin palavereissa. Jokaisessa palaverissa käytiin läpi edellisen palaverin pöytäkirjaan merkityt päätökset sekä osallistujille sovitut toimenpiteet ja näiden tilat.

Projektipäällikkö esitti palavereissa lyhyen tilakatsauksen, jossa kuvattiin projektin tehtävien etenemistä edellisen palaverin jälkeen, mahdollisia kohdattuja ongelmia ja tulevia toimenpiteitä. Tilakatsauksessa esiteltiin lisäksi projektiryhmän jäsenten käyttämät työtunnit tehtäväkokonaisuuksittain ja viikoittain.

Palavereissa keskusteltiin toteutettavan sovelluksen ominaisuuksista, tavoitteista ja vaatimuksista sekä niiden toteutusratkaisuista ja kehitystyökaluista. Palavereissa projektiryhmä esitteli sovelluksen käyttöliittymän hahmotelmia, prototyyppejä ja toimintaa.

Palaverin puheenjohtajana ja sihteerinä toimivat vuorollaan jokainen projektiryhmän jäsen. Tehtäviä kierrätettiin jäsenten kesken sovitussa järjestyksessä. Kunkin palaverin puheenjohtaja ja sihteeri sovittiin ryhmässä etukäteen, mutta valinnasta päätettiin virallisesti jokaisen palaverin alussa.

Puheenjohtaja johti palaverin keskustelua ja huolehti siitä, että palaveri eteni esityslistan mukaisesti. Sihteeri laati palaverin pöytäkirjan, jonka puheenjohtaja tarkasti antaen siitä mahdolliset korjausehdotukset sihteerille. Korjausten jälkeen sihteeri julkisti pöytäkirjan projektiorganisaatiolle ja muille mahdollisille palaveriin osallistuneille. Jokaisen ryhmän jäsenen laatima ensimmäinen pöytäkirja toimitettiin lisäksi vastaavalle ohjaajalle ennen projektiorganisaatiolle julkistamista.

Edellisten palaverien pöytäkirjat oli määrä hyväksyttää seuraavassa palaverissa, jolloin siihen voitiin tarvittaessa esittää muutoksia. Palavereiden 6-8 pöytäkirjat jäivät kuitenkin myöhempiin palavereihin hyväksyttäväksi. Lisäksi kahden viimeisen palaverin pöytäkirjat hyväksyttiin sähköpostilla.

Palavereiden määrän suhteen projektiryhmällä ei ollut suunniteltua käytäntöä, vaan palavereita pidettiin tilaajan kanssa tarpeen mukaan. Seuraavan palaverin ajankohta päätettiin aina kunkin palaverin lopuksi. Tätä käytäntöä ei kirjattu projektisuunnitelmaan, mutta käytäntö omaksuttiin ensimmäisestä palaverista lähtien. Ainoastaan viimeisen projektipalaverin ajankohta sovittiin sähköpostitse, jotta tilaajan kanssa saatiin sovittua viimeiset sovellukseen toteutettavat toiminnallisuudet. Joustava käytäntö palavereiden pitämiseen tuntui toimivalta ratkaisulta, sekä ryhmä koki palavereiden määrän ja seuraavan palaverin ajankohdan sopimistavan toimivaksi.

Pöytäkirjojen kirjoitusprosessi toteutui pääosin suunnitelman mukaan, mutta palavereiden 6-8 pöytäkirjat myöhästyivät aikataulusta. Pöytäkirjat 7 ja 8 hyväksyttiin kokouksessa 10 sekä pöytäkirja 6 palaverin 11 jälkeen. Käytännöstä poikkeaminen vaikutti projektin läpivientiin ja sovelluskehitykseen siten, että kaikkia palavereissa sovittuja asioita ei saatu sovittua ajoissa. Lisäksi pöytäkirjojen myöhästyminen saattoi aiheuttaa epäluottamusta projektiorganisaatioon kuuluvien välillä.

Palavereiden 12 ja 13 pöytäkirjat hyväksyttiin projektiorganisaation toimesta sähköpostitse, sillä viimeisen palaverin pöytäkirja oli määrä hyväksyä sähköpostitse. 13. palaveri pidettiin ylimääräisenä, joten myös tämän palaverin pöytäkirja hyväksyttiin myös sähköpostitse. Pöytäkirjojen hyväksyminen sähköpostitse koettiin hitaammaksi kuin projektiryhmän normaali käytäntö, mutta tämä ei vaikuttanut projektin tuloksiin tai läpivientiin.

5.2 Tiedotus

Projektin tiedotuksesta projektiorganisaatiolle vastasi pääasiassa projektipäällikkö. Ryhmän jäsenet kommunikoivat ensisijaisesti projektipäällikön kanssa, mutta välittivät vapaasti omilta vastuualueiltaan oleelliset tiedotettavat asiat koko projektiorganisaatiolle.

Projektiorganisaation tiedotusta varten luotiin kaksi erillistä sähköpostilistaa. Sähköpostilistojen sähköpostiarkistot eivät ole julkisia, vaan niihin vaaditaan kirjautuminen JYU-tunnuksilla.

Pääasiallista sähköpostilistaa timber@korppi.jyu.fi käytettiin projektiryhmän jäsenten, ohjaajien ja tilaajan edustajien tiedotukseen. Sen jakelulistalle kuuluivat kaikki projektiorganisaation edustajat. Sen sähköpostiarkisto on osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/timber.

Projektiryhmän jäsenten ja ohjaajien käyttöön perustettiin sähköpostilista timber_opetus@korppi.jyu.fi. Sen sähköpostiarkisto on osoitteessa https://korppi.jyu.fi/kotka/servlet/list-archive/timber_opetus/. Sähköpostilistalla käsiteltiin asioita, jotka eivät olleet merkityksellisiä tilaajalle. Tällaisia asioita olivat esimerkiksi projektiryhmän erilaiset koulutukseen liittyvät asiat.

Ryhmän sisäinen tiedotus tapahtui pääosin suullisesti, sillä jäsenet työskentelivät säännöllisesti samassa tilassa ja olivat siten yhteydessä toisiinsa lähes päivittäin. Tarvittaessa tiedotusta ryhmän sisällä hoidettiin WhatsAppin välityksellä tai sähköpostitse.

Projektiorganisaation tiedotus sujui suurelta osin suunnitelman mukaisesti, mutta ryhmän sisäinen viestintä toteutui pääosin WhatsApp-sovelluksella sekä suullisesti projektihuoneessa. Tämä käytäntö osoittautui luontevammaksi tavaksi kommunikoida ryhmän sisäisiä asioita kuin sähköposti.

Projektin tiedotuksesta projektiorganisaatiolle ei ollut suunnitelmaa käytännöissä, mutta tiedotusvastuu ajautui pääosin projektipäällikölle. Tämän lisäksi ryhmän jäsenet tiedottivat omilta vastuualueiltaan projektiorganisaatiolle, mikä koettiin luontevaksi käytänteeksi. Kaikilla projektiorganisaation jäsenillä oli myös pääsy projektiryhmän Trelloon, jossa oli nähtävillä sovelluskehityksen tila ja kehityksessä olevat toiminnallisuudet sekä ajantasainen vaatimusmäärittely.

Projektiorganisaation tiedotus sujui ilman suuria ongelmia. Tiedotuksen lisääminen olisi tuonut ryhmän toiminnasta ja etenemisestä läpinäkyvämpää varsinkin sovelluksen kehitysvaiheissa, mutta se ei olisi merkittävästi edistänyt tavoitteiden toteutumista tai projektin läpivientiä.

5.3 Tehtävien jako

Tapa jakaa tehtäviä projektin jäsenten kesken poikkesi jonkin verran suunnitelmasta. Ryhmän jäsenet käyttivät Trelloa sovelluskehityksen tukena ja lisäsivät kortteihin toteuttavia toiminnallisuuksia, mutta suunnitelmasta poiketen kaikkia kortteja ei useinkaan merkitty kenenkään vastuulle. Tehtävät jaettiin projektiryhmän jäsenten ollessa projektihuoneessa, joten korttien merkitsemiselle ei nähty tarvetta. Ryhmä luotti siihen, että kukin ryhmän jäsen hoitaa hänelle annetut tehtävät. Käytäntö koettiin luontevaksi, eikä suunnitelmasta poikkeaminen vaikuttanut haitallisesti projektin tuloksiin tai läpivientiin.

5.4 Tiedostojen nimeäminen

Python-lähdekooditiedostot nimettiin PEP8-suositusten [8] mukaisesti, jonka mukaan tiedostojen nimet kirjoitetaan aina pienillä kirjaimilla ja välilyönnit korvataan alaviivoilla. JavaScriptin osalta noudatettiin TIMissä käytettyä nimeämistapaa, missä tiedostot kirjoitetaan camelCase-merkintätavalla. Tässä merkintätavassa tiedostojen nimet aloitetaan pienellä, mutta välilyönnit poistetaan ja seuraava sana aloitetaan isolla kirjaimella. Kaikkien tiedostojen ja hakemistojen nimet kirjoitettiin englanniksi.

Lähdekooditiedostojen nimeämiseen liittyviä käytäntöjä ei oltu projektisuunnitelmaan kirjattu, vaan ne määriteltiin TIMin kehityksessä olevien käytänteiden mukaisesti. Käytäntö koettiin järkeväksi sovelluksen jatkokehitystä ajatellen.

Projektiryhmän jäsenet kirjoittivat dokumentit TIMiin aluksi ilman erikseen sovittua tapaa tiedostonimistä. Käytänteeksi sovittiin lopulta kirjoittaa dokumenttien URLit siten, etteivät ne sisällä erikoismerkkejä. Tiedostojen nimeämiseen liittyvien käytäntöjen muodostuminen projektin edetessä ei vaikuttanut haitallisesti projektin läpivientiin tai tuloksiin.

5.5 Hakemistorakenne

Projektin tulokset tallennettiin CD-levylle ja projektin TIM-hakemistoon seuraavan hakemistorakenteen mukaisesti, pois lukien TIMistä uupuvat Ajankaytto, Software- ja Sahkopostiarkistot-hakemistot.

• Ajankaytto
• Dokumentit
• Esittelyt
• Muistiot
• Palaverit
  • Esityslistat
  • Poytakirjat
• Sahkopostiarkistot
  • timber
  • timber_opetus
• Software
  • Source
  • Class_documentation
• Sopimukset_ja_lisenssit
• Suunnitelmia
  • Kayttoliittyma
    
  • Tietokannan_rakenne
  • Vaatimusmaarittely
• Testaus

Hakemistorakenteen osalta projektisuunnitelma oli puutteellinen ja käytäntö tämän osalta muodostuikin projektin edetessä. Ryhmän jäsenet kokivat, ettei puutteellinen käytäntö hakemistorakenteeseen liittyen vaikuttanut projektin tuloksiin tai läpivientiin.

5.6 Lähdekoodi

Palvelinsovelluksen lähdekoodi kirjoitettiin vastaamaan Pythonin yleisiä käytänteitä noudattaen PEP8-dokumentaatiota [8]. Lähdekoodissa käytetyt aliohjelmat, luokat ja muuttujat nimettiin englanniksi TIMin yleisten koodauskäytäntöjen [9] mukaisesti. Myös lähdekoodin kommentit kirjoitettiin englanniksi.

Asiakassovelluksen lähdekoodi kirjoitettiin mukaillen JavaScriptin yleisiä käytänteitä sekä Angularjs:n ohjelmointikäytänteitä. JavaScriptin dokumentaatiossa käytettiin JSDoc-notaatiota. Asiakassovellus hyödyntää HTML-merkintäkieltä ja SASS-tyylitiedostoja. Timber-sovelluksen käyttämät HTML-tiedostot ovat validia HTML5:sta.

Lähdekoodin tuottamiseen liittyvät käytännöt poikkesivat jonkin verran projektisuunnitelmaan kirjatuista käytänteistä. Projektisuunnitelmasta poiketen ryhmän jäsenet kirjoittivat Python-koodia PEP8-dokumentaatiota noudattaen ja asiakassovelluksen lähdekoodi kirjoitettiin TIMin ohjelmointikäytänteiden [9] mukaisesti. Vaikka suunnitelmassa ei ollut kirjattu lähdekoodin kirjoittamiseen liittyviä käytänteitä kovin tarkasti, oli ryhmän jäsenille selvää miten lähdekoodia tulee TIM-sovellukseen kirjoittaa. Puutteellisesti suunnitellut käytänteet eivät vaikuttaneet projektin tuloksiin tai läpivientiin lähdekoodin tuottamisen osalta.

5.7 Suoritetut testaukset ja tulokset

Sovelluksen käyttöliittymää testattiin sovelluskehityksen aikana kaikkien jäsenten toimesta pääasiassa Chrome selaimen versiolla 52.0.2743.116 m ja Mozilla Firefox -selaimen versiolla 45.3.0. Tämän lisäksi sovellusta testattiin myös Internet Explorer 11 selaimen versiolla 11.494.10586.0, Microsoft Edge -selaimen versiolla 25.10586.0.0 sekä muutamia kertoja myös Androidin Internet mobiiliselaimen versiolla 1.5.28 ja Applen Safari-mobiiliselaimen versiolla 9.0. Testausta suoritettiin, jotta voitaisiin varmistua sovelluksen lopullisen toiminnan laadusta.

Vastaava ohjaaja ja tilaajan edustajat koekäyttivät sovellusta useita kertoja kehitysvaiheiden aikana. Heiltä saatu palaute auttoi sovelluksen kehittämisessä. Erityisesti vastaavan ohjaajan palaute oli kattavaa ja hyödyllistä. Tilaajan edustajat antoivat sovelluksen käyttöliittymästä palautetta aktiivisesti projektin ajan sähköpostilla ja palavereissa.

Joonas Lattu toteutti palvelinohjelmalle teknisen ohjaajan pyytämät yksikkötestaukset. Paavo Itkonen ja Ismo Huhtiniemi laativat järjestelmätestaussuunnitelmasta versiot 0.1.1 [12] ja 0.2.0 [13] varsinaisille testauskerroille, johon kirjattiin testitapaukset ennen testauskertoja. Järjestelmätestauksessa testattiin projektiryhmän toteuttamia TIM-sovelluksen toimintoja. Testausraporteissa [14] ja [15] kuvataan testauskertojen tulokset, sekä tehdyt puutteista ja mahdollisista virhetilanteista.

Käytänteet toteutuivat järjestelmätestauksen osalta suunnitelman mukaisesti. Järjestelmätestauksen ensimmäisellä suorituskerralla testaussuunnitelman testitapaukset eivät vastanneeet sovelluksen toimintoja. Toisella järjestelmätestauskerralla löytyi virhe, joka esti useamman testatapauksen läpimenon. Havaitut virheet korjattiin, mutta regressiotestausta ei suoritettu.

5.8 Versiohallinta ja -numerointi

Projektiryhmä käytti sovelluksen lähdekoodin versiohallintaan Git-versiohallintaohjelmistoa ja YouSource-julkistusjärjestelmää. Tietokantasuunnitelmien versiohallintaan käytettiin myös YouSource-järjestelmää. YouSource-järjestelmään perustettiin projektiryhmän jäsenille oma ryhmä (team), projekti ja tarvittavat tietovarastot. Tilaajan edustajille ja tekniselle ohjaajille annettiin lukuoikeus lähdekoodiin. Muut projektiin ja sovellukseen liittyvät dokumentit säilytettiin projektin TIM-hakemistossa.

Dokumenttien julkistetuissa versioissa käytettiin kolmiportaista versionumerointia. Ryhmän sisäisiä luonnoksia numeroitiin pienimmällä merkitsevällä numerolla (i.j.1), ja kunkin uuden julkistetun version kohdalla kasvatettiin numeroa yhdellä. Projektiorganisaatiolle julkistettuja versioita numeroitiin toisella merkitsevällä numerolla (i.1.j) ja projektiorganisaation hyväksymiä versioita ensimmäisellä merkitsevällä numerolla (1.i.j). Joitakin väliversioita oli yli kymmenen, kuten esimerkiksi projektisuunnitelman neljännessätoista ryhmän sisäisessä versiossa 0.0.14. Ensimmäinen koko projektiorganisaation hyväksymä versio oli 1.0.0, ja tätä seuraavien julkistettujen versioiden numerointia kasvatettiin toisen merkitsevän numeron osalta.

Versiointia käytettiin suunnitellusti kaikissa oleellisimmissa dokumenteissa, mutta käyttöohjeessa käytettiin päivämäärää versionumeroinnin sijaan. Toisinaan versiointi oli julkaisuvaiheessa joissain dokumenteissa virheellinen, mutta nämä virheet korjattiin vastaavan ohjaajan palautteen myötä.

5.9 Katselmoinnit ja tulosten hyväksyminen

Projektissa toteutettavan sovelluksen lähdekoodi katselmoitiin kaksi kertaa projektin aikana. Katselmoinneissa projektin tekninen ohjaaja kommentoi lähdekoodia sekä antoi vinkkejä ja ehdotuksia sen parantamiseen. Katselmointeihin osallistuivat vastaavan ohjaajan ja teknisen ohjaajan lisäksi koko projektiryhmä. Katselmoinneissa tehdyt havainnot tekninen ohjaaja kirjasi muistioiksi [16] ja [17]. Katselmoinnit toteutuivat suunnitellusti.

Tekninen ohjaaja hyväksyi lähdekoodit ehdollisina sähköpostitse 12.8.2016. Vastaava ohjaaja ja tilaajan edustajat hyväksyivät tulokset kokonaisuutena projektin lopussa. Keskeisimmät laaditut dokumentit, kuten projektiraportti, sovellusraportti ja vaatimusmäärittely, hyväksyttiin projektipäällikön, tilaajan edustajan ja vastaavan ohjaajan allekirjoituksilla. Tulosten hyväksyminen toteutui projektisuunnitelman mukaisesti.

5.10 Tulosten koostaminen ja toimittaminen

Projektiryhmän jäsenet kokosivat luvussa 3.5 kuvatut projektin tulokset sekä tulostettuina projektikansioon että tallennettuina CD-levylle luvussa 5.5 kuvatun hakemistorakenteen mukaisesti. CD-levy koostettiin vasta sitten, kun kaikki projektissa laaditut tulokset oli hyväksytty. Lisäksi tulokset toimitettiin tilaajalle TIMissä olevina dokumentteina ja ohjelmiston lähdekoodi jaettiin YouSource-palvelun kautta. Tietotekniikan laitokselle toimitettiin projektikansio ja koostettu CD-levy, jotka sijoitettiin projektitilan kokoushuoneessa sijaitsevaan hyllyyn. Laitoksen arkistoon toimitettiin lisäksi yksi CD-levy. Tulosten koostaminen ja toimittaminen toteutuivat suunnitellusti.

6. Tehtävät, työmäärät ja tehtäväjako

Luvussa kuvataan projektipäällikön ja varapäällikön tehtävät sekä projektiryhmän toteutettamien tulosten vastuuhenkilöt. Lisäksi esitellään tehtäväkokonaisuuksien jakautuminen tehtäviin sekä eri tehtävien suunnitellut ja toteutuneet työmäärät ja tehtäväjako.

Jäsenten välinen tehtäväjako vastasi suunnitelmaa pääosin. Tehtäväjaossa onnistuttiin huomioimaan hyvin jäsenten poissaolot sekä muiden opintojaksojen vaatima työmäärä. Kaikki ryhmän jäsenet osallistuivat sovelluskehitykseen, ja jokaisella oli omat hyvin määritellyt vastuualueensa sovelluksen toiminnoista. Projektisuunnitelma ja projektiraportti kuuluivat suurelta osin projektipäällikön tehtäviin. Suuri osa hänen työtunneistaan kului niiden laatimiseen, minkä vuoksi hän osallistui vähiten sovelluksen toteuttamiseen.

Jäädytetyn projektisuunnitelman työtuntiarviot jäivät joidenkin tehtäväkokonaisuuksien osalta suunnittelematta. Kaikkiin tehtäviin tarvittavia työtunteja ei osattu arvioida riittävän tarkasti. Etenkin suunnittelun ja toteutuksen tehtäväkokonaisuuksien eri kehitysvaiheiden toteutuneet työtunnit ovat noin kaksinkertaiset suunniteltuihin verrattuna. Ryhmä ei halunnut jättää sovelluksen tarpeellisia toimintoja ja näkymiä keskeneräisiksi, joten työtunteja käytettiin puuttuneiden toiminnallisuuksien kehittämiseen ja lähdekoodin viimeistelyyn. Määrittelyn ja testauksen arvioitua pienemmät työtunnit johtunevat osittain puutteellisista kirjauskäytänteistä.

Puutteellisista kirjauskäytänteistä johtuen ryhmän jäsenillä ei ollut aina tietoa siitä, mihin tehtäväkokonaisuuten mikäkin työtehtävä tulisi kirjata. Tehtäväkokonaisuuksien työtuntien perusteella on siten hankala tehdä luotettavia johtopäätöksiä. Etenkään yksittäisten tehtävien tasolla ei voida luotettavasti arvioida toteutuneiden ja suunniteltujen työtuntien eroja. Tehtävänimikkeitä yhdistämälläkään ei voida luotettavasti arvioida toteuman ja suunnitelman välistä eroa, sillä myös tämän osalta ryhmän jäsenillä oli toisistaan poikkeavia käytänteitä.

6.1 Vastuualueet tulosten osalta

Projektipäällikkönä toimi Ismo Huhtiniemi ja varapäällikkönä Seppo Tarvainen. Projektipäällikön tehtäviin kuuluivat luonnollisesti projektin läpiviennin suunnitteleminen ja hallinta, projektin tilan seuraaminen ja raportointi, jäsenten ajankäytön seuranta sekä tehtävienjako ja tiedotus. Projektipäällikkö vastasi projektisuunnitelman ja -raportin laatimisesta. Varapäällikölle tuli tarvetta projektissa kolme kertaa, kun projektipäällikkö oli estyneenä sairauden tai muun menon vuoksi.

Projektiryhmässä toteutetut keskeisimmät tulokset ja niiden vastuuhenkilöt on esitetty taulukossa 6.1. Vastuuhenkilö ei toteuttanut koko tulosta yksinään, mutta vastasi suurelta osin sen laadusta ja valmistumisesta sekä siitä tiedottamisesta.

Vastuualueet toteutuivat suurelta osin suunnitellusti, mutta suunnitelmasta puuttuivat käyttöoikeuksien, käyttöohjeen ja luokkadokumentaation vastuuhenkilöt. Testausdokumenttien vastuuhenkilöiksi toteutui suunnitelmasta poiketen Ismo Huhtiniemi. Lisäksi projektisuunnitelma jäädytettiin, kun sen täydentämistä ja korjaamista ei enää katsottu hyödylliseksi projektinhallinnalle.

6.2 Tehtävien työmäärät ja tehtäväjako

Kukin projektiryhmän jäsen käytti sovellusprojektiin yli 430 tuntia. Kunkin jäsenen työmäärä vastasi lopulta 16-18 opintopistettä, jonka lisäksi he käyttivät oheiskursseihin yhteensä 121 tuntia. Yhteensä työtunteja koko projektiryhmälle kertyi 2309, joka on noin 690 tuntia yli suunnitellun tavoitteen. Timber-ryhmän viikkotuntitavoite oli 125 tuntia viikossa, jolloin toteutunut tuntimäärän ylitys vastaa yli viittä työviikkoa. Projektiryhmän sovelluskehitykseen käyttämät tunnit (määrittely, suunnitellu, toteutus ja testaus) ylittivät yhteenlaskettuna noin 500 tuntia suunnitellun tavoitteen, joka vastaa neljää työviikkoa.

Projektiryhmä jakoi tehtäviä alussa vastuualueitten mukaan. Työnjaossa ja työmäärien suunnittelussa huomioitiin jäsenten tietotaidot ja toimenkuva. Varsinaisia etukäteen tiedettyjä menoja ei ollut alkuvaiheessa tiedossa. Arvioidut työtunnit perustuivat projektipäällikön kokemukseen aikaisemmasta projektikurssista. Projektin työmäärä jakautui tehtävittäin jäsenille kuvan 6.2. mukaisesti.

Projektin hallintaan käytetyt työtunnit koostuivat pääosin projektipäällikön projektisuunnitelman ja projektiraportin laatimiseen, projektin seurantaan ja hallintaan, tilaraportointiin ja tiedotukseen käyttämistä työtunneista. Projektiryhmä jakoi alussa tehtävänsä tarkasti, joten projektipäällikön harteille jäi paljolti projektisuunnitelman kirjoittaminen, kokousten valmistelu ja raportointi. Kirjatut tunnit ylittävät yli 170 tunnilla suunnitellut osaksi siitä syystä, että projektin hallintaan kirjattiin paljon siihen kuulumatonta työtä. Tämä johtui siitä, että ryhmän jäsenillä ei ollut selkeää käytäntöä työtuntien kirjauksesta.

Palaverien työtunnit ylittivät suunnitellut noin 40 tunnilla, sillä osa palavereista venyi ylipitkiksi. Niissä keskusteltiin pitkään siitä, mitä toimeksiantaja halusi sovellukselta. Lisäksi osa pöytäkirjojen laatimisesta on kirjattu projektin hallintaan.

Projektiorganisaation palaverit kirjattiin johdonmukaisesti palavereiden tehtäväkokonaisuuteen, mutta käytäntö tehtävän kirjaukseen puuttui. Suunnitelmasta poiketen palavereita ei kirjattu palaverit-tehtävän alle, vaan vaihtelevasti palavereissa käydyn keskustelun mukaisesti joko
suunnitteluun, käyttöliittymään, seurantaan ja hallintaan tai johonkin muuhun.

Esitutkimukseen käytettiin 30 tuntia suunniteltua vähemmän. Toteutuksen ja suunnitteluun tehtäväkokonaisuuteen kirjattiin tunteja, jotka olisi tullut kirjata esitutkimukseen.

Määrittelyyn käytettiin vain vähän yli kolmetoista tuntia, kun 88 tuntia oli alun perin suunniteltu. Tehtäväkokonaisuuden tunteja todennäköisesti kirjattiin sovelluksen suunnitteluun. Jäsenillä ei ollut yhtenäisiä käytänteitä siitä, mihin mikäkin tehtävä merkitään.

Suunnittelun työtunnit ylittivät arvioidut noin 250 tunnilla, joka vastaa kahta työviikkoa. Aikaa kului paljon mm. käsitteiden, tietokannan, käyttöoikeuksien ja sovelluksen suunnitteluun. Sovelluksen suunnittelua tehtiin useimmiten yhdessä koko ryhmän kanssa. Suunnitteluun kirjattiin myös esitutkimuksen, määrittelyn ja esittelyjen tehtäväkokonaisuuksien tunteja.

Toteutuksen tunnit ylittivät arvioidut melkein 500 tunnilla, joka vastaa neljää työviikkoa. Tarvittavien vaatimusten toteuttamiseen kulunut työaika osoittautui vaikeaksi arvioida, sillä jäsenillä ei ollut aiempaa kokemusta TIMin tai muidenkaan WWW-sovellusten kehittämisestä. Lisäksi ryhmän olisi tullut enemmän yhdessä arvioida työtunteja, jolloin kaikkien asiantuntemusta olisi pystytty hyödyntämään. Tästä syystä työtuntien arviointi meni reilusti pieleen toteutuksen osalta.

Ryhmässä ei osattu priorisoida tilaajan tavoitteita, mihin olisivat käyttötapauskuvaukset auttaneet. Tämä johtui osaltaan siitä, että TIM:n tehtävien vastauksiin ei heti alkuvaiheessa pystytty tekemään merkintöjä, vaan ominaisuutta jouduttiin odottamaan TIMin kehittäjien puolelta. Huhtikuun alussa oli mahdollisuus kokeilla merkintöjen tekemistä tehtävien vastauksiin, mutta ominaisuus tuli lopulliseen muotoonsa vasta huhtikuun lopussa. Tämän vuoksi ryhmän jäsenet eivät pitäneet merkintöjen kirjaamista tehtävien vastauksiin ensisijaisena ominaisuutena, vaikka tämä oli tilaajan päätavoite.

Testauksen tunnit jäivät noin 150 tuntia alle suunnitellun. Ainoastaan järjestelmätestauksen suunnittelu ja toteutus merkittiin tähän tehtäväkokonaisuuteen. Yksikkötestauksen tunteja on merkitty suurelta osin suunnitellusti toteutukseen. Testaus keskitettiin Ismo Huhtiniemelle, kuten kuvan 6.2 tehtävätaulukosta on nähtävissä.

Tulosten luovutuksen tehtäväkokonaisuuteen on merkitty tunteja, jotka ehkä olisivat kuuluneet projektin hallinnan tehtäväkokonaisuuteen. Tulosten luovutusta ja viimeistelyä ei ollut suunnitelmassa varattu omaksi tehtäväkokonaisuudeksi, vaan se oli sisällytetty toteutuksen ja projektin hallinnan tehtäväkokonaisuuksiin. Tästä johtuen jäsenillä ei ollut tulosten luovutuksen osalta selkeää käytäntöä työtuntien kirjauksesta.

Oheiskurssien eri kurssien toteutuneita tuntimääriä ei eritelty, joten kaikki kurssit näkyvät yhtenä tuntimääränä. Itkonen ja Palojärvi eivät osallistuneet viestintäkurssille.

Ryhmän jäsenillä suurin ero (yli 60 tuntia) tunneissa on Latun ja Tarvaisen välillä. Tarvainen hoiti ison osan käyttöliittymän toimintojen ohjelmoinnista sekä kirjoitti sovellus- ja projektiraporttia. Latulla taasen oli projektin ulkopuolisia velvollisuuksia hoidettavana.

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

Työtunnit kirjattuina tehtäväkokonaisuuksittain on esitetty kuvassa 6.3. Toteutuksen osuus käytetyistä työtunneista on noin 38%. Sovelluskehitykseen käytetty osuus kokonaistuntimäärästä on yhteensä noin 61%. Käytetyt kehitystyökalut ja -menetelmät olivat pääosin uusia jäsenille, joten osa toteutukselle merkityistä työtunneista kuuluisi pikemminkin esitutkimuksen kokonaisuudelle. Palaverin pöytäkirjan kirjoittamista merkittiin myös projektin hallintaan, sillä jäsenten tuntien kirjaaminen ei ollut yhtenäistä.

6.4 Ismo Huhtiniemen työtunnit tehtäväkokonaisuuksittain

Projektin hallinnan lisäksi Huhtiniemi osallistui myös merkittävällä tuntimäärällä sovelluksen suunnitteluun ja pienellä tuntimäärällä sovelluksen toteutukseen. Palaverien suuri osuus johtuu niihin valmistautumiseen merkityistä tunneista. Lisäksi Huhtiniemi vastasi järjestelmätestauksen suunnittelusta, suorittamisesta ja raportoinnista.

6.5 Paavo Itkosen työtunnit tehtäväkokonaisuuksittain

Itkosen työtehtävät projektissa painottuivat käyttöliittymän toteutukseen ja testauksen suunnitteluun sekä ohjedokumentin ja sovellusraportin laatimiseen.

6.6 Joonas Latun työtunnit tehtäväkokonaisuuksittain

Latun työtehtävät koostuivat suurelta osin palvelinohjelmiston toteutuksesta, joten suuri osuus toteutuksessa oli ennakoitavissa. Esitutkimuksen tunnit johtuvat kehitysympäristöön tutustumisesta.

6.7 Petteri Palojärven työtunnit tehtäväkokonaisuuksittain

Palojärvi suunnitteli ohjelmiston ja tietokannan rakennetta. Tästä johtuen hänellä kertyi melko paljon suunnittelutunteja. Palvelinpuolen ohjelmointi oli hänen päävastuualueitaan, josta johtuen toteutuksen tunnit ovat määrältään suuret.

6.8 Seppo Tarvaisen työtunnit tehtäväkokonaisuuksittain

Tarvainen toimi projektin varapäällikkönä. Jonkin verran hän otti projektipäällikön tehtäviä hoitaakseen osallistuen projektiraportin laatimiseen ja projektipäällikön ollessa estynyt. Hänen työtehtävänsä projektissa painottuivat kuitenkin vahvasti käyttöliittymän suunnitteluun ja toteutukseen sekä vaatimusmäärittelyyn, joka on merkitty projektin hallinnan tehtäväkokonaisuuteen.

7. Prosessi ja aikataulu

Luvussa kuvataan projektin läpiviennissä käytettyä ohjelmistokehitysprosessia ja toteutunutta aikataulua. Suunnitelman mukaista prosessia pystyttiin noudattamaan pitkälti, mutta viimeistely sisälsi lisäksi paljon sovelluskehitystä. Viimeistelyvaiheen pitkittyminen johtui siitä, että jäsenten tuli vielä kehittää sovellusta tilaajan vaatimusten mukaisesti. Lisäksi kaikkien jäsenten suunnitellut työtunnit tulivat täyteen ja kesällä heillä oli muita sitoumuksia, jotka osaltaan viivästyttivät projektin läpivientiä.

Projekti viivästyi noin 20 viikkoa suunnitellusta aikataulusta. Kokonaistyötunnit ylittyivät suunnitellusta noin 690 tuntia. Viivästyminen johtui osittain siitä, että projektiin tarvittava työmäärä oli arvioitu liian pieneksi, joka osaltaan johtui kokemattomuudesta projektinhallinnassa. Lisäksi sovellukselle asetetut tavoitteet tarkentuivat projektin edetessä, mikä lisäsi paljon sovelluskehitystyötä. Myös jäsenten tavoitetta pienemmät viikkotyötuntimäärät viivästyttivät projektin läpivientiä.

7.1 Prosessi

Projekti vietiin läpi useassa vaiheessa. Ensimmäisessä vaiheessa asennettiin tarvittavat kehitystyökalut ryhmän jäsenten koneille, tutustuttiin ohjelmointiympäristöön ja TIMin lähdekoodiin sekä suunniteltiin toteutettavaa sovellusta, sen käyttöliittymää ja rakennekaaviota. Vaiheeseen sisältyi myös käsitteiden määrittely, joka valmistui vasta maaliskuun puolen välin jälkeen. Ensimmäisen vaiheen loppupuolella aloitettiin projektisuunnitelman laatiminen ja suunniteltiin projektin läpivientiä.

Sovelluksen kehityksessä pyrittiin noudattamaan ketteristä menetelmistä Scrumia räätälöitynä. Sovelluksen kehitystä tehtiin kahden viikon tai kolmen viikon mittaisissa kehitysvaiheissa niin, että toiminnallisuuksia lisättiin ohjelmaan vaatimusten prioriteettien mukaisessa järjestyksessä.

Neljän kehitysvaiheen loputtua merkittäviä vaatimuksia toteutettiin sovellukseen vielä viimeistelyvaiheessa. Viimeistelyvaiheessa laadittiin vaatimusmäärittelydokumentti, käyttöohje, projektiraportti ja sovellusraportti, suunniteltiin ja suoritettiin järjestelmätestauksen testauskerrat sekä viimeisteltiin sovellus, lähdekoodi ja luokkadokumentaatio tilaajalle luovutusta varten.

Palavereissa esiteltiin toteutettuja tuloksia. Kaikki jäsenet pääsääntöisesti osallistuivat kaikkiin projektipalavereihin muutamaa poikkeusta lukuunottamatta. Jäsenet koittivat kokoontua maanantaisin yhtä aikaa projektihuoneeseen, jolloin voitiin suunnitella tehtäväjakoa ja tiedottaa ajankohtaisista asioista. Viimeinen palaveri pidettiin 22. kesäkuuta.

Vaiheet päättyivät likimain suunnitelman mukaisesti lukuunottamatta viimeistelyvaihetta. Eri kehitysvaiheet päättyivät useimmiten palaverin jälkeisenä päivänä, mutta sovelluksen viimeistely poikkesi suunnitellusta aikataulusta. Tilaaja hyväksyi sovelluksen 25. heinäkuuta ja tekninen ohjaaja lähdekoodin ehdollisena 17. elokuuta.

7.2 Aikataulu

Projekti alkoi torstaina 28.1.2016, ja sen suunniteltiin päättyvän viimeistään toukokuun lopussa. Projekti päättyi 15.9.2016, yli kolme kuukautta suunniteltua myöhemmin.

Projektin läpiviennin suunniteltu ja toteutunut aikataulu on esitetty olennaisimpien tehtäväkokonaisuuksien ja toteutettavien tulosten osalta kuvissa 7.1 ja 7.2. Sovellusprojektin kokonaistyötunnit ylittyivät suunnitellusta noin 690 tunnilla, joten projektia ei olisi ollut mahdollista läpiviedä suunnitellun aikataulun puitteissa.

Projektin viivästyminen johtui kokemattomuudesta projektinhallinnassa, liian tiukasta tehtävien jaosta ja sovellukselle asetettujen tavoitteiden epätarkkuudesta. Myös tavoitetta pienemmät viikkotunnit melkein joka viikolla osaltaan viivästyttivät projektia. Huhtikuun lopussa TIMin kehittäjät toteuttivat ominaisuuden, joka mahdollisti sovelluskehityksen merkinnän kirjaamiseksi tehtävien vastauksiin. Tähän mennessä osalla jäsenistä oli suunnitelman mukaisesti enää noin yksi työviikko käytettävissä. Tehtävien vastausten vertaisarviointiin liittyvät toiminnallisuudet sovittiin jatkokehitykseen.

.

7.3 Ryhmän työtunnit viikoittain

Ryhmän toteutuneiden työtuntien jakautuminen eri viikoille on esitetty kuvassa 7.3. Sovellusprojektille suunniteltu kunkin jäsenen työtuntimäärä oli noin 25 tuntia viikossa, eli koko ryhmältä yhteensä noin 125 tuntia viikossa. Viikkotavoite toteutui kuitenkin vain parilla viikolla, joka osaltaan johti projektin viivästymiseen. Oheiskurssit vaativat lisäksi omat viikoittain vaihtelevat työtuntimääränsä. Viikoilla 6-25 (6.2.-26.6.) kertyi vähintään 80 tuntia, ja projektin tehtävät etenivät. Viikosta 26 eteenpäin muut sitoumukset ja motivaatiohaasteet vähensivät työtunteja.

Projektin kahdella ensimmäisellä viikolla jäsenillä ei ollut yhteistä aikaa, eivätkä he juuri kokoontuneet yhteen projektihuoneessa. Viikolla 6 jäsenet pääsivät paremmin kiinni työkaluihin ja roolijakoihin. Viikko 18 oli projektin hiljaisin viikko johtuen vapusta ja helatorstaista. Lisäksi Tarvainen oli tuolloin lomamatkalla ja muutenkin projektilaisilla oli paljon menoja.

7.4 Ismo Huhtiniemen työtunnit viikoittain

Huhtiniemen tunnit olivat viikoilla 6-10 noin 10 tuntia viikossa, joka johtui suurelta osin pro gradu -tutkielman tekoon liittyvistä velvotteista. Viikoilla 13-14 tunteihin vaikutti sairastelu. Viikoilla 18-24 Huhtiniemen tunnit olivat tavoitteen mukaiset, jolloin hän kirjoitti projektiraporttia ja suoritti käyttöliittymätestausta. Kesällä viikoista 27 eteenpäin motivaation lasku ja muut menot pienensivät tuntimääriä, vaikka Huhtiniemi suorittikin järjestelmätestausta ja ohjelmoi sovelluksesta löytyneitä puutteita. Kesä-syyskuussa Huhtiniemi laati projektiraporttia sekä koosti tuloksia projektikansioon ja projekti-CD:lle.

7.5 Paavo Itkosen työtunnit viikoittain

Itkosen työtunnit olivat viikoilla 8-11 ja 14-15 yli 25 tuntia viikossa. Viikon 12 ja 13 hieman alhaisemmat tuntimäärät johtuvat pääsiäisen pyhistä. Viikosta 18 eteenpäin käyttöliittymän toteuttamista ei ollut enää niin paljon, joten tuntien määrä oli siitä eteenpäin alhaisempia. Alussa projektia Itkonen osallistui sovelluksen suunnitteluun ja toteutti käyttöliittymän graafisia osuuksia. Loppupuoli koostui käyttöohjeen ja sovellusraportin kirjoittamisesta.

7.6 Joonas Latun työtunnit viikoittain

Latun tunnit nousivat projektin alusta viikolle 18 asti. Lattu jäi työtunneissa jälkeen muista jäsenistä alkuvaiheessa. Alussa Linux-ympäristön työkalut eivät lähteneet toimimaan ja laaja kehitysympäristö ei ollut kovin tuttu. Muut velvoitteet ja menot veivät häneltä usealta viikolta resursseja viikkojen 4-17 aikana. Viikoilla 18-24 tuntien määrän ollessa suurempia kuroi Lattu muita kiinni. Viikosta 26 eteenpäin hänelle tuli muita velvoitteita.

7.7 Petteri Palojärven työtunnit viikoittain

Palojärvi käytti viikoilla 6-10 noin 20 tuntia viikossa, ja viikoilla 11-17 hänen työtuntinsa olivat keskimäärin yli 25 tuntia viikossa. Viikolla 18 oli helatorstai, ja viikoilla 18-20 Palojärvellä oli muita velvoItteita. Projektin alussa aikaa kului sovelluksen suunnitteluun sekä myöhemmin sovelluksen toteuttamiseen ja tietokannan suunnitteluun. Viikosta 26 eteenpäin suurin osa ohjelmoinnista oli tehty ja varsinaiseen ohjelmointiin ei kulunut häneltä enää aikaa. Viikoilla 31-33 Palojärvi ei osallistunut projektin viimeistelyvaiheeseen muiden velvoitteiden vuoksi.

7.8 Seppo Tarvaisen työtunnit viikoittain

Tarvainen käytti reilut 20 tuntia aina 23 viikolle asti, jonka jälkeen sovellukseen ei tullut juurikaan muutoksia. Käyttöliittymän toiminnallisuuteen ja sovelluslogiikkaan kului suurin osa hänen työtunneistaan. Lisäksi vaatimusmäärittelyn, sovellusraportin ja projektiraportin kirjoittamiseen kului osan hänen työtunneistaan. Tarvainen oli viikon 18 lomamatkalla, jolloin hänelle ei kertynyt tunteja.

8. Riskit ja niiden hallinta

Luvussa kuvataan projektisuunnitelmassa ennakoitujen riskien toteutumista ja hallintaa sekä vaikutuksia projektin läpivientiin ja tuloksiin. Lisäksi esitellään käytettyjä toimenpiteitä riskien ehkäisemiseen, ennakoimiseen ja niistä toipumiseen. Pahimmaksi koetti riski oli sovellukselle asetettujen tavoitteiden epätarkkuus, jota ei oltu ennakoitu projektisuunnitelmassa. Myös keskinkertaisiksi riskeiksi koettiin kokemattomuus projektinhallinnassa ja tehtävien jakaminen projektiryhmän kesken. Näistä jälkimmäistä ei oltu projektisuunnitelmassa ennakoitu. Kaikki toteutuneet riskit hidastivat projektin etenemistä ja vaikuttivat myöhästymiseen suunnitellusta aikataulusta.

8.1 Riskien todennäköisyydet ja haittavaikutukset

Arvioidut ja toteutuneet projektin läpivientiä hidastaneet tai projektin tuloksiin vaikuttaneet riskit on listattu taulukkoon 8.1. Riskien toteutumisen todennäköisyyksiä ja haittavaikutuksia on arvioitu asteikolla pieni, keskinkertainen ja suuri.

8.2 TIM-oppimisympäristön haasteet

Ryhmällä ei ollut aiempaa tietämystä siitä, miten TIM-oppimisympäristöä kehitetään. Alkuun oli haastavaa saada selville rakenne, miten näkymästä lähtevä komento saadaan reittien kautta tietokantaan asti. Muutenkin suuri osa käytetystä ajasta sovelluskehityksen alkuvaiheessa meni olemassa olevaan lähdekoodiin tutustumiseen etenkin, kun kaikkia metodeja ei oltu kommentoitu. Eritysesti kommentoimatonta lähdekoodia oli JavaScript-koodeissa, mikä hidasti sovelluksen toiminnallisuuden selvittämistä. Palvelinpuolella lähdekoodi oli paremmin dokumentoitua, joten siitä ryhmän oli helppo ottaa mallia.

Ryhmällä oli aluksi myös vaikea päättää, mihin kansioihin omaa lähdekoodia toteutetaan, sillä TIMissä ei ollut valmiina selkeää käytäntöä tästä. Johdonmukaisuuden vuoksi Timber-ryhmä päätyi käyttämään samaa logiikka kuin edellisen vuoden Timppa-projekti. TIMin kehittämiseen liittyvien haasteiden selvittämisessä projektiryhmä katsoi mallia edellisen vuoden Timppa-projektista sekä sai neuvoja tekniseltä ohjaajalta.

Vaikka TIMin kehittäminen oli ryhmän jäsenille vierasta, ei tämä osoittautunut kuitenkaan ryhmälle ongelmaksi. Tutustuminen vei projektin alussa aikaa, mutta kun muutamia toimintoja oltiin saatu toteutettua, muodostui ryhmän jäsenille selkeä käsitys TIMin kehittämisestä.

8.3 Kehittäjien tietotaitojen puutteet

Kenelläkään ryhmän jäsenellä ei ollut aiempaa työkokemusta WWW-sovellusten jatkokehittämisestä, ja TIMissä käytetyt työkalut olivat suurelle osalle ryhmän jäsenistä vieraita. Tämän vuoksi työkaluihin ja tekniikoihin liittyviä ongelmia oli vaikea ennakoida. Tämän riskin ehkäisemiseksi ryhmän jäsenet tutustuivat käytettyihin työkaluihin ja tekniikoihin sekä osallistuivat teknisen ohjaajan pitämään perehdytysluentoon.

Työkaluihin tutustuminen oli aluksi hidasta, sillä ne eivät kunnolla toimineet Linux-käyttöjärjestelmän Red Hat -jakelupaketissa. Työkaluja yritettiin saada toimimaan, mutta lopulta käyttöjärjestelmät vaihdettiin Windows 7:aan, jolloin ongelmat vähenivät. Teknisten ongelmien jälkeen työkaluihin tutustuminen eteni normaalisti, ja ryhmä oli varannut tälle riittävästi aikaa.

Ryhmän kokemattomuus näkyi myös jossain määrin projektin vaatimusten suunnittelussa. Ryhmä ehdotti aluksi paljon eri toiminnallisuuksia, joita sovellukseen voitaisiin toteuttaa. Ryhmä huomasi liian myöhään, ettei niiden tekemiseen riitä aika.

Kehittäjien tietotaitojen puutteet vaikuttivat sovelluskehityksen alkuvaiheessa, mutta riski ei osoittautunut merkittäväksi ongelmaksi. Riskin ehkäisemiseksi ryhmän jäsenet tutustuivat TIMissä käytettyihin ohjelmointikieliin ennen sovelluskehityksen aloittamista ja opiskelivat niistä lisää sovelluskehityksen aikana.

8.4 Jäsenten poissaolot ja muut velvoitteet

Jäsenten poissaolot ja muut velvoitteet eivät olleet esteenä projektin etenemiselle, sillä kaikki ryhmän jäsenet olivat hyvin sitoutuneita projektin läpiviemiseen. Joonaksella oli paljon muita sitoumuksia huhtikuulle asti, mutta hän sai hyvin tehtyä hänelle asetetut tehtävät. Jäsenten lyhyetkin poissaolot olivat lähes aina ennalta tiedossa, ja pidemmistä poissaolojaksoista oli ilmoitettu hyvissä ajoin. Jäsenten poissaolot eivät vaikuttaneet merkittävästi projektin läpivientiin tai tuloksiin.

8.5 Kokemattomuus projektinhallinnassa

Projektiryhmän jäsenillä ei ollut ennen Sovellusprojekti-kurssia kokemusta projektin hallinnasta sovelluskehityksessä. Tämä näkyi ensisijaisesti ajanhallinnan suunnittelussa. Jäsenet arvioivat usein toteutettavat toiminnallisuudet helpommiksi kuin ne todellisuudessa olivat, jonka vuoksi seuraavaan asiakaspalaveriin ei saatu toteutettua kaikkia sovittuja vaatimuksia. Tämän vuoksi palavereissa meni paljon aikaa käyttöliittymän läpikäymiseen, sillä tilaaja ehti tutustua uuteen versioon sovelluksesta usein vasta palavereissa. Mikäli sovelluksen prototyyppi olisi saatu toteutettua aiemmin, tilaajalla olisi todennäköisesti ollut helpompi miettiä, miten sovellusta tulisi kehittää.

Projektiryhmä määritteli sovelluksen välttämättömät vaatimukset yhdessä tilaajan kanssa, mutta ei osannut realistisesti arvioida työaikaa niiden toteuttamiseen. Ryhmä koki, että tilaajan odotukset kasvoivat projektin edetessä, jolloin sovelluksen tavoitteiden saavuttaminen hankaloitui entisestään. Vankempi kokemus projektinhallinnasta, projektin läpiviennistä ja asiakastyöstä olisi auttanut näiden ongelmien huomaamisessa etukäteen. Kokemattomuus projektinhallinnassa yhdistettynä kehittäjien tietotaitojen puutteisiin oli varmasti yksi syy työmäärän kasvamiselle ja projektin viivästymiselle.

8.6 Tehtävien jakaminen projektiryhmän kesken

Projektiryhmä jakoi sovelluskehityksen tehtävät tarkasti sovelluksen palvelimen ja näkymän välille. Tämä auttoi aluksi, sillä kaikkien ryhmän jäsenten ei tarvinnut tutustua heti koko TIMin lähdekoodiin, vaan ryhmän jäsenten riitti sopia metodien nimet, käytetyt parametrit ja paluuarvon JSON-objektin rakenteen. Sovelluskehityksen loppupuolella tarkasta tehtävienjaosta oli kuitenkin enemmän haittaa kuin hyötyä. Sovelluksessa oli usein joko palvelinsovellus tai käyttöliittymä selkeästi edellä, ja varsinkin sovelluskehityksen loppupuolella käyttöliittymä alkoi jäädä jälkeen. Mikäli jäsenillä olisi ollut enemmän valmiuksia toteuttaa sovellusta toistensa vastuualueilta, sovelluskehitys olisi ollut tasaisempaa palvelinsovelluksen ja näkymän välillä.

Projektiryhmä päätti, että projektinhallinnan vastuu on projektipäälliköllä, mistä johtuen projektipäällikön vastuulle jäi liian paljon projektin hallintaan liittyvää dokumentaatiota. Myöskään viestintä ryhmän sisällä ei tältä osin kulkenut riittävän hyvin, eikä ryhmä osannut nähdä projektipäällikön työmäärän suuruutta projektisuunnitelman osalta. Muut ryhmän jäsenet halusivat ensisijaisesti olla sovelluksen toteutuksessa mukana, jonka vuoksi projektin hallintaan liittyvä työ näyttäytyi heille vähemmän merkittävänä.

Tehtävien liian selkeä jakaminen projektiryhmän kesken vaikutti projektin tuloksiin ja läpivientiin. Liian selkeät vastuualueet saattoivat johtaa siihen, että vastuuhenkilön tuli itse hoitaa hänelle asetettu tehtävä ilman muiden jäsenten apua. Ongelma olisi voitu korjata joustavammalla työtavalla tai asettaa tehtäville useampi vastuuhenkilö.

8.7 Sovellukselle asetettujen tavoitteiden epätarkkuus

Sovellukselle asetettujen tavoitteiden epätarkkuus toi projektin läpivientiin omat haasteensa ja vaikutti projektin tulosten osalta siihen, ettei sovellusta saatu toteutettua aikataulussa. Projektin viimeisissä palavereissa käytiin tilaajan kanssa läpi sovellukseen toteutettavat toiminnallisuudet. Vaikka projektiryhmä mielestään toteutti nämä, seuraavassa palaverissa saatettiin sopia vielä lisää toteutettavia toiminnallisuuksia tai tarkentaa edellisiä.

Riskin vaikutus alkoi erityisesti näkyä ryhmän jäsenten motivaatiossa saattaa projekti loppuun sekä turhautumisena sovelluksen kehittämiseen. Sovelluksen viivästyminen vaikutti myös projektin dokumentaation viivästymiseen. Motivaation puute projektin loppuvaiheessa johti osaltaan siihen, ettei projektiryhmän jäsenet ymmärtäneet toimeksiantajan näkemyksiä, jonka vuoksi useassa palaverissa jouduttiin käymään läpi sovellukseen toteutettavat toiminnallisuudet. Tämä puolestaan laski motivaatiota ja ryhmän jäsenistä usein tuntui, ettei projekti tulisi ikinä päätökseen.

Projektin viivästymisestä ja motivaation puutteesta huolimatta ryhmän jäsenet jaksoivat kuitenkin jatkaa sovelluksen kehittämistä ja projektin dokumentointia. Loppuvaiheessa projektiryhmä alkoi jakaa tehtäviä enemmän ristiin, eikä välittänyt niin paljoa enää työjaosta, mikä edesauttoi projektin loppuunsaattamista. Ryhmän jäsenet eivät myöskään välittäneet, vaikka kaikilla kului enemmän tunteja kuin kurssista oli mahdollista saada opintopisteitä. Erityisen positiivista oli se, että ryhmä jaksoi viedä projektin loppuun asti ryhmänä, eikä vastuu kasautunut yksistään projektipäällikön harteille.

9. Jäsenten kokemuksia ja oppimaa

Luvussa kuvataan jäsenten kokemuksia ja oppimaa Sovellusprojekti kurssista. Yleisesti ottaen ryhmän jäsenet kokivat kurssin työlääksi, mutta opettavaiseksi.

9.1 Ismo Huhtiniemen kokemuksia ja oppimaa

Sovellusprojektikurssi tuntui mielenkiintoiselta maisterivaiheen opinnoissa. Jouduin miettimään jonkin aikaa, haluaisinko projektipäälliköksi. Muutkaan eivät olleet innostuneita projektipäällikön roolista. Itseäni kiinnostivat myös testaus ja AngularJS, joihin pääsin tutustumaan loppupuolella projektia.

Eniten pidin siitä, että suunnittelu ja keskustelu oli avointa projektihuoneessa. Suunnittelu tuntui mielenkiintoiselta. Yhdessä suunnittelu oli parasta, ja toisten kokemuksia hyödynnettiin tarvittaessa. Muiden motivaatio näkyi ja tuntui hyvältä projektihuoneessa. Ryhmän jäsenet osasivat tehdä ammattimaisesti projektin tehtäviä. Jokaiselle oli riittävästi tekemistä, ja varsinkin kevään aikana motivaatio oli korkealla.

Projektin haasteeksi osoittautui toimeksiantajan ymmärtäminen, mihin vaikutti varmaan paljon ryhmän jäsenten mielikuvat siitä mitä ollaan tekemässä. Enemmän olisi voitu käydä läpi kuvausta, joka alunperin saatiin toimeksiantajalta.

Projektipäällikön osuus kuitenkin tuntui sopivan minulle, vaikkakin projektisuunnitelma jäi suurelta osin harteilleni ja se jäädytettiin. Työmäärä dokumentaation parissa lopulta vaikutti turhankin suurelta. Palaverien järjestäminen ja niihin valmistautuminen oli mielekästä hommaa. Loppupuolella projektissa motivaatiotani haittasi muiden ryhmän jäsenten motivaation laskeminen.

Jos jotain voisi projektista oppia, niin kannattaa paremmin tutustua toimeksiantajan toiveisiin ja käyttää omaa osaamista enemmän toteuttamiseen. Kaikki toiveet kannattaa tutkia hyvin ja tarkentaa toimeksiantajalta projektin alussa. Kannattaa tehdä selkeät käyttötapaukset ja tutkia niitä toimeksiantajan kanssa.

9.2 Paavo Itkosen kokemuksia ja oppimaa

Sovellusprojekti oli ensimmäinen laajahko projektikurssini, ja en ennalta oikein tiennyt, mitä kurssilta pitäisi odottaa. Olin orientoitunut kurssin vaatimaan työmäärään, ja suoritin kevään aikana vain muutaman muun kurssin.

Ennalta luulin kurssin koostuvan lähinnä ohjelmoinnista ja siten myös edellyttävän erittäin hyviä ohjelmointitaitoja. Itselleni oli pieni helpotus huomata, että kurssiin sisältyy paljon muutakin. Olin toki saanut ohjelmoinnin perustaidot aiemmilla kursseilla, mutta toisaalta tiesin, ettei varsinkaan "back-endin" koodaaminen kuulu vahvuuksiini. Yhteisymmärrys työnjaosta saavutettiin nopeasti. Päätimme mielestäni oikein, että ryhmän jäsenet eivät ala kehittää heikointa osa-aluettaan, koska silloin aikaa olisi voinut kulua melko paljonkin pelkkään opetteluun. Oma kontribuutioni itse sovellukseen koostui lähinnä käyttöliittymän ulkoasun muokkaamisesta.

Suurin yllätys oli, kuinka paljon aikaa kului sovelluksen suunnitteluun ja alussa ehkä hieman liikaakin. Sovelluskehityksemme eteni välillä yrityksen ja erehdyksen kautta, ja suunnittelua jouduttiin tekemään paljon vielä toteutuksen lomassakin. Kurssi oli kuitenkin hyvää käytännön oppia siitä, mitä sovelluskehitys todellisuudessa on. Sovellus voidaan toteuttaa monella eri tavalla, ja suunnitteluun on sinänsä pakko panostaa.

Kuten ohjaajamme kurssin alussa totesi, tilaajilla ei ole tapana antaa kovinkaan yksityiskohtaisia vaatimuksia. Luulisin työelämässäkin olevan yleinen ongelma, että jotain vaatimusta ei lopulta pystytäkään toteuttamaan tai ehkä pystyttäisiin, mutta se ei ole ajan ja vaivan arvoista. Tämän lisäksi vaatimuksia ja ideoita tulee projektin aikana koko ajan lisää, minkä vuoksi myös priorisointia täytyy tehdä koko ajan enemmän. Koska sovelluskehityksemme ei edennyt niin suoraviivaisesti kuin aluksi luulimme, jouduimme lopulta keskittymään vain keskeisimpien vaatimusten toteuttamiseen. Toinen yllätys oli, kuinka paljon kurssiin sisältyi raportointia ja muuta dokumentointia. En tiedä olisiko esimerkiksi muodollisia kokouspöytäkirjoja varsinaisesti tarvittu, mutta harjoituksen kannalta niitä oli ihan hyvä laatia.

Työskentely ryhmässä onnistui hyvin, ja kommunikaatio oli riittävää. Kaikki ryhmän jäsenet eivät aina olleet paikalla samaan aikaan, missä oli hyvät ja huonot puolensa. Se tietysti vaikeutti tai ainakin hidasti kommunikaatiota, mutta toisaalta tiedostojen samanaikainen muokkaaminen aiheutti helposti konflikteja versiohallintaohjelmistossa. Kaiken kaikkiaan kurssi oli laajuudessaan ja erilaisuudessaan hyvää vaihtelua opintoihin. Kurssin aikana tuntui jossain määrin kuin olisi käynyt töissä, mikä luultavasti oli tarkoituskin. Vaikka osa sovelluksellemme asetetuista vaatimuksista jäi toteuttamatta, kurssilla oppi käytännön sovelluskehityksestä paljon sellaista, mitä ei luennoilla ja oppikirjoista oppisi.

9.3 Joonas Latun kokemuksia ja oppimaa

Suunnitelmanani on suorittaa maisterin opinnot pelit ja pelillisyys -linjalla, joten sen puolesta syventävän projektikurssin olisin voinut suorittaa myös syventävänä peliprojektina. Arvelin kuitenkin ns. normaalin sovellusprojektikurssin olevan hyödyllisempi ohjelmointitaitojeni monipuolistamiseksi. Käytäntö vastasi näitä odotuksia.

Olin suorittanut viiden opintopisteen peliprojektin vuotta aiemmin, joten ryhmämuotoinen projektityöskentely oli hyvässä muistissa. Kyseisellä kurssilla ryhmähengen ja -työskentelyn eteen jouduttiin käyttämään huomattavasti keskimääräistä enemmän energiaa, joten oli helpotus, että sovellusprojektissa kaikki klikkasi hyvin heti ensimmäisestä päivästä lähtien. Koska ryhmähenki oli erinomainen ja huumori kukki, oli tehtävistä sopiminen helppoa. Mahdollisista ongelmatilanteistakin selvittiin ilman hampaiden kiristelyä.

Kurssin alussa suunnitteluun meni enemmän aikaa kuin olimme kenties odottaneet. Syitä löytyy monia. Kukaan ei ollut kehittänyt aiemmin vastaavia järjestelmiä, eikä siten edes osittain optimaalisimmat ratkaisut olleet selkeitä. Toisaalta TIM oli "sisuskaluiltaan" kaikille uusi tuttavuus, mikä hidasti suunnittelua. Rakenne alkoi selvitä kunnolla vasta hyvän matkaa ohjelmoinnin aloitettua. Tämä tarkoitti tiettyjen suunnitelmien suuriakin muutoksia myöhemmin ja osittain "hukkaan" mennyttä työtä, kun päädyimmekin täysin erilaisiin toteutusratkaisuihin.

Pian kurssin alkuvaiheiden jälkeen oli myös huomattavissa, että olin jäämässä muiden työtunneista jälkeen. Tämä selittyy kohtuu suurelta osin erinäisistä ainejärjestön hallitustehtävistä, jotka tuntuivat menevän päällekkäin ryhmän suunnitteluhetkien kanssa. Toisaalta ohjelmoinnin alkamisen yhteydessä oli aluksi haastavaa päästä oikeaan flow-tilaan, kun ei oikein tiennyt, mitä ja miten pitäisi tehdä. Nähdäkseni näistä ongelmista ei tullut kuitenkaan mitään kiilaa ryhmätyöskentelyn väliin. Työtunneista ja niiden suorittamisesta keskusteltiin avoimesti niin ryhmän kesken kuin palavereissakin. Lopulta kevään edetessä löysin enemmän aikaa ja toisaalta ohjelmaankin oli kertynyt enemmän kehitettävää, joten sain lopulta muut jäsenet kiinni kunnialla. Lopussa kaikilla tuntien täytyttyä ja ylityttyä, eroa kertyi taas hieman asioiden loppudokumentoinnin vuoksi, johon käytin selkeästi vähiten aikaa.

Melko pian kurssin alkamisen jälkeen saimme sovittua ohjelmointiin liittyvät työtehtävät. Minulla ei ollut erityisiä preferenssejä, joten päädyin tekemään Petterin kanssa backendiä, joka ohjelmoitiin pitkälti Pythonilla ja SQLitella. Pythonin kanssa olin aiemmin raapaissut lähinnä pintaa, enkä SQL:kään ollut käsitellyt aikoihin, joten alku meni muistelun ja uuden opiskelun parissa. Kokemus oli aikaavievä mutta palkitseva, sillä en ollut koskaan aiemmin työskennellyt minkään likimainkaan yhtä monimutkaisen ohjelman parissa. Vaikka olemassa olevan koodin jatkokehitys voi olla uuden luontia haastavampaa, antoi projekti hyvän kuvan, kuinka suurempia kokonaisuuksia voidaan lähestyä.

Selkeä jako front endin ja back endin välillä toisaalta helpotti työskentelyä ja toisaalta hankaloitti. Toinen koodaaja front endiin olisi luultavasti helpottanut, sillä nyt Seppo hoiti koodin kirjoittamisen yksin. Projektin edetessä päädyimmekin Petterin kanssa koodaamaan myös hieman front endiä AngularJS:n muodossa. Vaikka tämä olisi voinut olla hyödyllistä jo aiemmin, riitti back endin puolella sen verran opettelemista, ettei front endiin koskeminen olisi silloin vielä ollut kovin realistista.

Yhteinen projektihuone työskentelyä varten toimi erittäin hyvin. Vaikka joskus tuntuikin, ettei muiden pyöriessä ympärillä saa mitään tehtyä, oli muiden läsnäolo pääsääntöisesti hyvä asia. Erityisesti Sepon kanssa oli hyödyllistä käydä vuoropuhelua siitä, minkälaista dataa hän kulloinkin tarvitsisi käyttöliittymää varten ja missä muodossa.

Kaikenkaikkiaan koin sovellusprojektin olevan kaikista käymistäni yksittäisistä kursseista ylivoimaisesti hyödyllisin opettavaisuuden osalta. Kurssilla oppi mm. uusia kieliä (Python, AngularJS), lukemaan paremmin valmista koodia, suuremman ohjelmistokokonaisuuden vaatimia yksityiskohtia ja ryhmätyöskentelyä. Kaikkia kyseisiä taitoja tarvitsee opiskelunjälkeisessä työelämässä.

9.4 Petteri Palojärven kokemuksia ja oppimaa

En ollut varma, tekisinkö tutkintooni tarvitsemani projektiopinnot sovellusprojektina vai tutkimusprojektina. Valmistuttuani en tavoittele akateemista uraa, joten arvelin sovellusprojektin tarjoavan arvokkaampaa kokemusta. Odotin projektin olevan melko työläs, ja varasinkin suurimman osan keväästä projektin suorittamiseen.

Jätin projektiin liittyvän viestintäkurssin pois saatuani tietää, ettei se ole pakollinen osa kurssia. Aihe olisi ollut minusta kiinnostava, mutta en tarvinnut enempää opintopisteitä, ja se ei siksi tuntunut vaivan arvoiselta.

Projektin suorittaminen antoi kokemusta siitä, millaista saattaisi olla tehdä sovelluskehitystä työkseen. Valitettavasti en pysty sanomaan, vastaako kokemukseni kaikilta osin todellisuutta, mutta luulen saaneeni projektin ansiosta kohtalaisen käsityksen asiasta. Samalla sain kokemusta projektiluontoisesta työnteosta ylipäätään.

Projektiin kuului muutamia luentoja, joista erityisesti jäi mieleen tekijänoikeuksiin keskittynyt luento. Aihe oli minulle uusi, mutta on hyvä saada siitä jonkinlainen käsitys, jos sovelluskehitystä päätyy tekemään.

Ryhmätyöskentely sujui hyvin, ja ryhmän eri jäsenillä oli selkeästi eri vastuualueet. Valittu työtapa säästi aikaa siten, että ryhmän jokaisen jäsenen ei tarvinnut tutustua koko TIMiin, vaan saattoi keskittyä osaan siitä. Toisaalta tämä myös hidasti työntekoa, kun osa-alueet väistämättä kohtasivat sekä toteutuksesta ja rajapinnoista piti neuvotella. Ajoittain olisi ollut tarvetta useammallekin keskustelulle yhtäaikaa, mutta pieni projektihuoneemme ei oikein sopinut siihen. Lisäksi keskustelu haittasi silloin tällöin työhön keskittymistä, jos käytävä keskustelu ei koskenut omia töitä. Projektin kuluessa opimme toki laajemmin TIMin toimintaa. Vähän kerrassaan jaottelu osa-alueisiin väheni ja olisi ehkä poistunut kokonaan, jos projekti olisi jatkunut riittävän kauan.

Projektissa sain arvokasta kokemusta REST-arkkitehtuurista, tietokannan suunnittelusta ja AngularJS-ohjelmistokehyksestä. Lisäksi palvelimen toteutukseen käyttämämme Python oli minulle uusi ohjelmointikieli.

9.5 Seppo Tarvaisen kokemuksia ja oppimaa

Ilmoittaudun sovellusprojektiin, sillä olen kiinnostunut WWW-sovellusten toteuttamisesta ja halusin oppia sovelluskehitystä käytännössä. Tavoitteenani oli päästä mahdollisimman paljon käytännön ohjelmointityöhön käsiksi, ja tämä tavoite kyllä toteutuikin.

Olin kuullut, että kurssi on työläs, jonka vuoksi kävin keväällä ainoastaan kolme muuta kurssia. Vaikka olin järjestänyt kurssin suorittamiselle sen tuntiarvion mukaisesti aikaa, pääsi kurssin työmäärä yllättämään. Ryhmällämme meni aluksi hyvin paljon aikaa sovelluksen suunnitteluun ja sovelluksessa käytettävien käsitteiden määrittelyyn. Jälkiviisaana voisi todeta, että sovellusta olisi voinut kehittää enemmän asteittain, eikä ensin suunnittelemalla ja sitten vasta toteuttamalla. Nyt sovellukseen jäi paljon ominaisuuksia, joita palvelin tarjoaa, mutta joita käyttöliittymä ei tue.

Kurssiin kuuluvista luennoista päällimmäisenä mieleen jäi käytettävyysluento, jossa käytiin läpi ryhmän toteuttamaa sovellusta ja arvioitiin esimerkkisivuston käytettävyyttä. Luento oli mielestäni tärkeä, sillä tässäkin projektissa useissa palavereissa keskusteltiin pääasiassa sovelluksen käytettävyydestä. Luento sijoittui puoliväliin projektia, mikä oli mielestäni ihan hyvä ajankohta. Tosin meidän sovelluksemme koki tässä kohti suuria käyttöliittymämuutoksia. Periaatteessa käytettävyysluento voitaisiin jatkossa jakaa myös kahteen osuuteen, jossa ensimmäisessä käytäisiin läpi esimerkkisivustoa ja vasta toisessa toteutetun sovelluksen käytettävyyttä. Tällöin käytettävyydestä olisi tekijöillä enemmän tietoa ennen kuin käyttöliittymää olisi ehditty alkaa toteuttamaan.

Mielestäni ryhmätyöskentelymme sujui oikein hyvin ja jokaisella oli selkeä tehtävä projektissa. Tarkassa tehtäväjaossa oli selkeitä hyöty- ja haittapuolia. Suurin hyöty oli se, ettei kaikkien ryhmän jäsenten tarvinnut tuntea kaikkea sovellukseen liittyvää koodia, vaan riitti sopia metodien nimet, parametrit ja paluuarvot. Tämä varmastikin säästi projektin alussa aikaa, mutta projektin loppupuolella käyttöliittymän toteutukseen tarvitsi enemmän työvoimaa. Onneksi Petteri ja Joonas kuitenkin ottivat tämän osan nopeasti haltuunsa. Vaikka projektimme venyi odotettua pidemmäksi, jokainen ryhmän jäsen jaksoi työskennellä loppuun saakka, vaikka motivaatio varmasti itse kullakin oli pohjalukemissa.

Sovellusprojekti-kurssi oli mielestäni yksi opettavaisimpia kursseja yliopistossa. Kurssilla tuli luettua hyvin paljon muiden tekemää koodia, kun muilla kursseilla ensisijaisesti tuotetaan omaa koodia. Lisäksi muilla kursseilla ohjelmakoodi on usein toimivaa tai vähintäänkin oikein dokumentoitua, mikä helpottaa koodin tulkitsemista. Ainakin javaScriptin osalta TIMissä oli paljon dokumentoimattomia metodeja, mikä oli tietysti valitettavaa, mutta kehitti varmasti koodinlukutaitoa. Tämän lisäksi kurssilla oppi väistämättä työskentelyä asiakkaan kanssa, ryhmätyöskentelyä ja projektimuotoista työtapaa.

10. Yhteenveto

Timber-projekti kehitti Sovellusprojekti-kurssilla keväällä ja kesällä 2016 Jyväskylän yliopiston tietotekniikan laitokselle TIM-järjestelmään sovelluksen, jonka avulla tehtävien vastausten tarkastusta voidaan yhdenmukaistaa ja nopeuttaa. Projektissa toteutettu prototyyppi on mahdollista ottaa koekäyttöön Jyväskylän yliopiston tietotekniikan laitoksella.

Timber-sovelluksen avulla opettajat voivat tehdä TIM-ympäristössä olevien tehtävien vastauksiin merkintöjä, jotka sisältävät vakioidun huomion ("velppi") sekä mahdollisen pistemäärän ja vapaita kommentteja. Oppilas puolestaan näkee opettajan antaman palautteen ja voi lisätä saamiinsa merkintöihin kommentteja opettajalle.

Projektissa sovellukselle asetetut tavoitteet toteutuivat osittain, mutta joitain vaatimusmäärittelyyn kirjattuja toimintokokonaisuuksia sovittiin tilaajan kanssa jatkokehitykseen. Suurin toteuttamaton kokonaisuus oli vertaisarvioinnin mahdollistaminen. Sovelluksen kehitysvaiheissa keskityttiin erityisesti käyttöliittymän toiminnallisuuteen ja sovelluksen rakenteen suunnitteluun.

Projektin suunniteltu päättymispäivä oli toukokuun puolessa välissä, jotta ryhmällä olisi ollut vielä pari viikkoa aikaa vielä viimeistellä sovellusta ja kirjoittaa dokumentaatiota. Tilaajan hyväksyntä sovellukselle saatiin kuitenkin vasta heinäkuun lopulla, kun sovellus pääosin vastasi tilaajan toiveita ja tavoitteita. Sovelluksen viivästymisestä johtuen myös sovellusraportti ja projektiraportti viivästyivät. Suurimmat syyt viivästymiselle olivat kokemattomuus projektinhallinnassa, jäsenten tavoitetta pienemmät viikkotunnit, työtehtävien jakamiseen liittyvät ongelmat sekä sovellukselle asetettujen tavoitteiden epätarkkuus. Projektin jäsenet olivat kuitenkin sitoutuneita projektin läpiviemiseen suunniteltujen tuntimäärien ylittymisestä huolimatta.

Sovellusprojekti-kurssi tarjosi ryhmän jäsenille paljon kokemusta WWW-sovellusten suunnittelusta ja toteutuksesta sekä oppia projektimuotoisesta työskentelystä ja työtavoista. Lisäksi ryhmä sai kokemusta ohjelmistoprojektin suunnittelusta ja hallinnasta. WWW-sovelluksen kehittämisessä jäsenet pääsivät soveltamaan aiemmilla kursseilla opittuja asioita käytännön sovelluskehitystyössä.