1 Johdanto

Kokako-projekti on kevään -06 Jyväskylän yliopiston tietotekniikan laitoksen Sovellusprojekti. Projekti kehitti opinto-oppaan laatimis- ja koostamistyökalua Jyväskylän yliopiston informaatioteknologian tiedekunnalle. Työkalusta oli tarkoitus laatia niin yleis- ja helppokäyttöinen, että sitä on mahdollista käyttää vastaaviin tarkoituksiin esimerkiksi muissa tiedekunnissa. Sovelluksella on kaksi erilaista käyttäjäryhmää sisällöntuottaja ja koostaja. Työkalun tarkoituksena on tehdä lähdedokumenteista yhtenäisiä, ja täten helpottaa koostajan työtä automatisoimalla koostajan koostamisprosessia.

Kokako-projekti on jatkoa XooZoo- ja Xoo-projekteille. XooZoo-projektin tehtävänä oli IT-tiedekunnan opinto-oppaan hallinnan, sisällön ja rakenteen kehittäminen. Projekti keskittyi tutkimukseen ja suunnitteluun. Käytännön toteutukselle jäi vähemmän aikaa, ja niinpä projekti jatkui Xoo-jatko-projektilla, jonka tehtävänä oli viedä XooZoo-projektissa aloitettu työ loppuun.

Xoo-projekti koosti IT-tiedekunnalle lukukauden 2005-2006 opinto-oppaan XooZoo-projektissa saatujen tuloksien pohjalta. Koostamistyössä havaittiin kuitenkin vielä useita puutteita, joista haluttiin eroon. Kokako-projektin tehtävänä oli korjata nämä puutteet ja kehittää koostamisprosessia edelleen.

Tämä dokumentti kuvaa projektisuunnitelmassa hahmoteltujen suunnitelmien toteutumista aikataulun, tavoitteiden, työnjaon, hallintatapojen ja riskien osalta. Tämän lisäksi dokumentti sisältää myös kuvauksen projektin käytössä olleista resursseista ja sidosryhmistä. Dokumentti sisältää myös kunkin tekijäryhmän jäsenen henkilökohtaisen arvion projektin kulusta ja läpiviennistä.

2 Projektiin liittyvä termistö

Tässä luvussa kuvataan projektiraportissa esiintyviä termejä.

XML (eXtensible Markup Language	on metakieli, jolla määritellään rakenteisia merkkauskieliä. XML- ja HTML-merkkauskielten erona on se, että HTML-merkkauskielessä käytetään ennalta määriteltyjä merkkaustunnisteita, kun taas XML-merkkauskielen dokumenteille voi laatia sovellus- ja aihekohtaisia omia merkkauskieliä skeemamääritystä käyttäen. XML siis tarjoaa syntaksin ja merkkaussäännöt, joiden pohjalta voidaan määritellä omia merkkauskieliä.
DTD (Document Type Definition)	Määrittää rakenteisen dokumentin skeeman. Tämän avulla XML-prosessorille kerrotaan mitä elementtejä ja attribuutteja dokumentti saa sisältää, missä järjestyksessä ne saavat ilmetä ja mitkä ovat niiden keskinäiset suhteet.
Luku.dtd	on opinto-oppaan koostamistyökalun käyttämä DTD. Tämä on opinto-oppaan tekstilukujen käyttämä DTD-määritys. (Opinto-oppaan koostaminen perustuu kooste.dtd-määritykseen.)
OpenOffice 2.0	on Microsoft Officen kaltainen ohjelma, josta löytyy hyvin pitkälti samat ominaisuudet. OpenOfficea on käytetään dokumenttien tuottamis- ja muokkausohjelmana opinto-oppaan tuottamisprosessissa.
XSLT (Extensible Style Language and Transformations)	on laajasti käytetty XML-dokumenttin muunnoskieli. Tyypillisiä XSLT:n sovelluskohteita ovat XML-aineiston muunnokset toiseen XML-merkkauskielen mukaiseksi, HTML-muotoon tai tekstiksi.

3 Taustaa

Tässä luvussa selvitetään, mitkä olivat Kokako-projektin lähtökohdat. Lisäksi luvussa kuvataan projektin taustaa, kuten tätä projektia edeltäneitä XooZoo- ja Xoo-projekteja.

3.1 XooZoo-projekti

XooZoo-projektin tarkoituksena oli kartoittaa IT-tiedekunnan opiskelijoiden mielipiteitä opinto-oppaasta, selvittää oppaan laadintaprosessin ongelmakohdat ja esittää niihin parannusehdotuksia. Lisäksi, mikä tämän tutkimuksen kannalta on tärkeintä, projektin tehtävänä oli laatia alustavat XML-määritykset opinto-oppaan laadintaprosessin teknologiaperustaksi sekä oppaan monikanavajulkaisun tueksi.

3.2 Xoo-projekti

XooZoo-projektin jälkeen kehittämistyötä jatkoi tiedekunnan yhteinen työryhmä. Jatkokehittäminen tarkoitti käytännössä IT-tiedekunnan lukuvuoden 2005–2006 opinto-oppaiden tuottamista XooZoo-projektin tuotosten pohjalta, koostamista ja monikanavajulkaisua XML-kielen ja XooZoo-projektissa luotujen DTD:n avulla, sekä opinto-oppaiden uuden julkaisujärjestelmän rakentamista, pilotointia, testausta ja dokumentointia.

3.3 Kokako-projektin lähtökohdat

Projektin lähtökohtana oli lähteä kehittämään edelleen XooZoo- ja Xoo-projektien tuotoksia. Korkein prioriteetti oli luoda yhtenäinen tuottamisympäristö opinto-oppaan dokumenteille ja niiden muuntaminen Xoo-projektin luoman koostamisohjelman typpimääritysten mukaiseksi. Tämän lisäksi tuottamisprosessiin oli tarkoitus lisätä versionhallinta, joka toimisi opasjärjestelmänä eli dokumenttien tallennuspaikkana. Xoo-projektissa koostamistyötä varten oli kehitetty web-pohjainen käyttöliittymä. Kyseinen työkalu oli kuitenkin niin ”kankea” ja vaikeakäyttöinen, että tilaaja halusi uuden, huomattavasti joustavamman ja helppokäyttöisemmän koostamistyökalun.

Käytännössä Kokako-ryhmälle oli siis annettu varsin selkeät tavoitteet, joiden saavuttamiseksi ryhmä työskenteli. Tavoitteet oli kuitenkin listattu varsin abstraktilla tasolla, ja esimerkiksi tekniseen toteutukseen otettiin ainoastaan vähän kantaa. Tekijäryhmän tehtäväksi jäi näin ollen selvittää teknisesti mielekkäimmät ratkaisut tilaajan toiveiden täyttämiseksi.

4 Tavoitteet

Tässä luvussa kuvataan projektin tavoitteiden toteutumista osa-alueittain liittyen julkaisuprosessiin, ohjelmistoihin, projektin dokumentteihin ja projektiryhmän tavoitteisiin. Kunkin aihealueen tavoitteet on kuvattu projektisuunnitelmassa [3].

4.1 Julkaisuprosessi

Kuva 1 esittää miten opinto-oppaan julkaisuprosessi etenee. Projektin tavoitteet ovat jäsennettävissä tämän kuvauksen perusteella.

Kuva 1: Julkaisuprosessi

4.1.1 OpenOffice ja XSLT

Tavoitteena oli saada aikaan helppokäyttöinen dokumenttien luomisympäristö, jossa voi luoda ja muokata opinto-oppaan dokumentteja. Xoo-projektissa XML-dokumenttien laatiminen oli osoittautunut liian vaikeaksi tavallista käyttäjää ajatellen, ja näinpä tilaaja halusi sovelluksen sisältävän helppokäyttöisen XML-tekstieditorin.

Editorin toteutusta suunniteltaessa kävi nopeasti ilmi, ettei editoria kannata lähteä toteuttamaan alusta alkaen, vaan mielekkäämpää on muokata jotain olemassa olevaa editoria tilaajan käyttötarpeisiin sopivaksi. Editorivalintaa tehtäessä päädyttiin nopeasti Open Office Writer -sovellukseen, joka on Microsoft Wordia vastaava tekstinkäsittelyohjelma.

XSLT-muunnosta tarvitaan OpenOfficessa tuotettavien ODT-dokumenttien muuntamisessa XML-muotoon. OpenOfficen käyttämä ODT-muoto merkkaa tekstin OpenOfficen mukaisella XML-merkkauksella, joka pitää muuntaa luku.dtd:n mukaiseksi XML-merkkaukseksi. Olemassa olevia XML-dokumentteja muokattaessa muunnos pitää tehdä toisinpäin, ennen kuin muokattava dokumentti on mahdollista avata OO:ssa.

XML-editoriin liittyvä työ jaettiin kahteen osaan: OpenOfficen muokkaamiseen ja rajaamiseen projektin tarpeiden mukaiseksi sekä XSLT-muunnoskriptien tekemiseen. Tuomas Räsänen työsti OpenOfficea ja Turo Lamminen XSLT-muunnoksia. Kumpikaan aihealue ei ollut tekijöille aiemmin tuttua, joten OO:n muokkaamiseen ja XSLT-muunnoksien opettelu vei jonkin verran aikaa. Tämän lisäksi myös itse muokkaus- ja ohjelmointityö vaati kummaltakin henkilöltä huomattavasti aikaa, ja näiden komponenttien työstäminen jatkui läpi projektin.

Toiminnallisuudeltaan muunnoksista ja editorista saatiin kohtuullisen hyviä, mutta toisaalta joitakin tärkeitä toimintoja jäi edelleen puuttumaan. XML-editorilla on mahdollista laatia XML-dokumentteja varsin helposti, kunhan editorissa käytetään ns. peruselementtejä. Kaikkien elementtien, kuten taulukoiden, käsittelyä ei ehditty toteuttamaan editoriin käytössä olleiden resurssien puitteissa. Tästä johtuen osa elementeistä pitää lisätä XML-dokumentteihin edelleen käsin, ja näin ollen tavoite toteutui vain osittain.

Tavoitteen täydellisen toteutumisen esteenä oli ryhmän omien arvioiden mukaan erityisesti OO:n muokkaamisen ja XSLT-skriptaamiseen haasteellisuus. Kummastakaan työvaiheesta ei kyetty laatimaan suunnitteluvaiheessa mitään realistisia arvioita, koska tekijöillä ei ollut aiempaa kokemusta vastaavasta työstä. Tästä johtuen työn määrä yllätti ryhmän, ja osaa suunnitelluista toiminnoista ei kyetty toteuttamaan. Tämän hetkinen editori on kuitenkin huomattava parannus projektia edeltäneeseen tilanteeseen verrattuna, joten tekijäryhmällä on myös aihetta olla tyytyväinen.

4.1.2 Versionhallinta

Versionhallinnan on tarkoitus suojata dokumentteja samanaikaisilta muutoksilta, tallentaa dokumenttien elinkaaren aikaiset tekstimuutokset mahdollista palautustarvetta varten, sekä antaa tietoa dokumenttien elinkaaren tilasta ja valmiusasteesta; onko dokumentti esimerkiksi vasta luonnosasteella, vai jo valmis julkaistavaksi. Versionhallinta toimii siis koosteprojekteihin liittyvien dokumenttien tallennusmediana, eli niin sanottuna opasjärjestelmänä. Xoo-projektissa opasjärjestelmänä toimi projektin käytössä ollut verkkolevy, jonne kaikki koosteeseen liittyvät dokumentit tallennettiin.

Verkkolevy tallennusmediana asettaa tiettyjä rajoituksia ja riskejä dokumenttien ryhmäkäytölle. Tilaaja halusi järjestelmän monipuolisemmaksi ja varmatoimisemmaksi, ja versionhallintajärjestelmää pidettiin hyvänä toteutusalustana uudelle opasjärjestelmälle.

Tekijäryhmän ryhdyttyä perehtymään versionhallintajärjestelmän toteutukseen kävi nopeasti ilmi, että sen integrointi osaksi koostamistyökalua tulee olemaan haastavaa. Eri käyttäjätunnuksien hallinta ja niiden kierrätys esimerkiksi Korppi-järjestelmän kautta osoittautui kompleksiseksi prosessiksi, varsinkin kun yliopistolla käytössä olevaan versionhallintajärjestelmään ei voi tehdä mitään koostamistyökalua varten räätälöityjä ratkaisuja. Ryhmä havaittua tilanteen, resurssit päätettiin keskittää ensisijaisesti oppaan koostamisprosessin kannalta kriittisiin komponentteihin ja versionhallintajärjestelmän integrointiin päätettiin ryhtyä vain, jos resursseja on vielä käytettävissä prioriteetiltaan tärkeämpien työvaiheiden jälkeen. Resursseja ei kuitenkaan jäänyt käytettäväksi versionhallinnan integrointiin osaksi sovellusta, ja se jää toteutettavaksi mahdollisessa jatkokehitystyössä.

Vaikkei versionhallinnan integrointi osaksi sovellusta toteutunutkaan, niin asiasta päästiin tilaajan kanssa nopeasti yksimielisyyteen, koska opas on mahdollista koostaa myös verkkolevyä käyttämällä. Versionhallinnan avulla saavutettavat hyödyt ja edut tulisivat esiin vasta siinä vaiheessa, kun järjestelmään olisi ehditty tehdä riittävät hienosäädöt ja asetukset. Näiden löytäminen vaatii niin paljon resursseja ja testaamista, ettei se ollut millään mahdollista tämän projektin puitteissa.

4.1.3 Koostamistyökalu

Koostamistyökalu ja XML-editori olivat kehitysprioriteetiltaan sovelluksen tärkeimmät komponentit. Koostamistyökalun kehitykseen käytettiin siis huomattavasti resursseja, ja myös tulos oli sen mukaista. Koostamistyökalusta saatiin huomattavasti aiempaa graafista käyttöliittymää selkeämpi ja helppokäyttöisempi, sekä samalla myös joustavampi.

Koostamiskäyttöliittymän kehitystyö keskittyi erityisesti graafisen käyttöliittymään, joka hyödyntää varsinaisessa koostamisprosessissa jo olemassa olevia koostamisskriptejä. Koostamistyökalu integrointiin osaksi sovelluksen hallintakäyttöliittymää, ja tästä johtuen sen käytettävyyteen kiinnitettiin paljon huomioita. Koostamiskäyttöliittymän pitää tarjota koostajalle nopea ja tehokas käyttöliittymä koosteiden tekemiseen, mistä johtuen käyttöliittymän kehitystyö vaatii vuorovaikutteista iterointityötä yhdessä tilaajan kanssa. Iterointityö onnistui tekijäryhmän mielestä hyvin, ja ainakin ryhmä itse on tyytyväinen syntyneeseen lopputulokseen.

Koostamistyökalun kehitystyöhön osallistui koko ryhmä mm. työkalun vaatimasta suuresta työmäärästä johtuen. Työnjako onnistui hyvin, ja työskentely oli saumatonta ryhmän jäsenten välillä.

Tavoitteiden kannalta koostamistyökalun toteutus onnistui hyvin, joskin mm. alilukujen käsittely jäi vielä toteuttamatta. Tilaaja kuitenkin hyväksyi tämän ja piti koostamistyökalua hyvänä saavutuksena jo sellaisenaankin.

4.2 Ohjelmistot

Seuraavassa kuvataan ohjelmistojen testauksen ja integroinnin tavoitteiden toteutumista.

4.2.1 Integrointi

Projektin loppuvaiheessa tavoitteena oli integroida sovelluksen osat toimimaan kokonaisuutena. Projektin vaiheet jakautuivat siten, että toteutus aloitettiin OO:n muokkaamisesta ja rajaamisesta sekä hallintakäyttöliittymän toteutuksesta. Hallintakäyttöliittymän valmistuttua ryhdyttiin toteuttamaan koostamistyökalua, jonka kehitys jatkui projektin loppuun saakka OO:n kehitystyön rinnalla. Versionhallintajärjestelmää ei toteutettu lainkaan, joten sen integroiminen osaksi kokonaisuutta ei ollut edes mahdollista.

Integrointityö aloitettiin OO:n ja koostamistyökalun osalta varsin aikaisessa vaiheessa, minkä ansiosta se myös onnistui hyvin. Julkaisuskriptien integrointi osaksi sovellusta oli välttämätöntä koostamisprosessin toiminnan kannalta, ja siinä myös onnistuttiin hyvin. Korppi-liitäntä saatiin toteutettua vain osittain, koska kurssitietojen haku ei ole mahdollista suoraan sovelluksesta käsin, vaan se pitää tehdä manuaalisesti. Sen sijaan autentikointi tapahtuu Korppi-järjestelmään perustuvan tarkistuksen avulla.

Integroinnin tavoitteet saavutettiin siis osittain, muttei kokonaan. Tämä johtui pitkälti siitä, että projektilta loppui resurssit kesken ennen kuin kaikkia integrointitehtäviä oli ehditty edes aloittamaan.

4.2.2 Testaus

Testauksen tavoitteena oli varmistaa, että oppaan laatimisprosessi sisällön tuottamisesta julkaisuun asti toimii. Projektin työmäärän yllättäessä tekijäryhmän jouduttiin myös testaamiseen allokoituja resursseja rajaamaan huomattavasti. Mitään erillistä ja kattavaa testaussuunnitelmaa ei laadittu, vaan testaamistyötä päätettiin tehdä jatkuvasti sovelluskehityksen yhteydessä. Sovellusta esiteltiin myös tilaajalle tasaisin väliajoin erityisesti käytettävyyteen liittyvien toiminnallisuuksien osalta. Näin tekijäryhmä pystyi kehittämään sovellusta käyttäjäkeskeisen suunnittelun pohjalta, ja vastaavasti myös pitämään loppukäyttäjän osana toteutusprosessia. Toisaalta tilaaja myös kritisoi ryhmää siitä, että osakomponenttien esittelyn lisäksi myös koko sovellusta ja sen toimintaa olisi voitu demonstroida jo nykyistä aiemmin tilaajalle. Viive koko sovelluksen demonstroinnissa johtui kuitenkin yksinkertaisesti siitä, ettei sovellusta saatu aiemmin siihen kuntoon, että sen täysimittainen demonstrointi olisi mahdollista.

Testaamisen osalta tavoitteet jäivät osin toteutumatta, koska alun perin ryhmällä oli tarkoitus laatia testaamista varten kattava testaussuunnitelma. Nyt testaaminen oli enemmän ad-hoc -tyyppistä työskentelyä, jossa on tosin siinäkin omat hyvät puolensa. Perustoiminnallisuus pystyttiin varmentamaan hyvin tällaisellakin testaamisella, mutta erikoisemmat käyttötilanteet saattavat aiheuttaa edelleen virheilmoituksia.

4.3 Suunnittelu- sekä raportointidokumentit

Projektin aikana syntyi useita projektin suunnitteluun ja raportointiin liittyviä dokumentteja. Suunnitteludokumenttien osalta tavoitteena oli kuvata ennen kaikkea projektin lähtökohdat ja tavoitteet, kehitettävälle sovellukselle asetetut toiminnalliset vaatimukset sekä sovelluksen rakennetta ja käyttöliittymää. Raportointidokumenteissa, joita tämäkin dokumentti edustaa, kuvataan tavoitteiden toteutumista ja toteutetun sovelluksen rakenne ja hierarkia yksityiskohtaisesti. Näiden kahden dokumenttikategorian lisäksi ryhmä laati esityslistan ja pöytäkirjan kuhunkin palaveriin liittyen, sekä väliesittelyraportit kahdesta väliesittelystä.

Dokumentit kirjoitettiin DOC- ja RTF-muodossa, ja ne käännettiin aina HTML-muotoon. Dokumentit on myös tallennettu projektin CD-levylle ja tulostettu projektikansioon mahdollista jatkokäyttöä varten. Ryhmän mielestä dokumentit ovat kattavia ja niiden laatimisessa onnistuttiin hyvin.

4.4 Projektiryhmän oppimistavoitteet

Ryhmän tavoitteena oli hankkia kokemusta projektiryhmässä toimimisesta sekä projektin läpiviennistä eri tehtävissä. Projektin alkuvaiheista lähtien oli selvää, että kyseessä on yliopisto-opiskelun kannalta täysin ainutlaatuinen kurssi, eikä ainakaan Jyväskylän yliopiston tietotekniikan laitoksella ole tarjota mitään vastaavaa. Jokainen ryhmän jäsen otti projektimuotoisen työskentelyn ilolla vastaan, ja kukin jäsen koki vapaamuotoisen työskentelyn mielekkääksi vaihtoehdoksi perinteiselle kurssipohjaiselle opiskelulle.

Projektia ryhdyttiin tekemän ryhmätyönä heti alusta alkaen, ja sellaisena sitä jatkettiin aina projektin loppuun saakka. Työskentely sisälsi totta kai myös yksilötyötä, mutta jokainen työvaihe oli kuitenkin askel kohti yhteistä päämäärää eli toimivaa sovellusta.

Vapaamuotoinen ja itse aikarajat asettavat työskentely vaatii huomattavasti ohjattua työskentelyä kovempaa itsekuria. Ryhmän jäsenet saivat huomata tämän ennemmin tai myöhemmin ― viimeistään siinä vaiheessa kun tehtyjä työtunteja ja jäljellä olevaa projektiaikaa alettiin tarkastella ensimmäistä kertaa. Eri henkilöiden työskentely eteni erilaista vauhtia, koska projektin aikaiset muut oheiskurssit tai työt vaikuttivat projektin etenemiseen. Yhteinen ryhmän ”konttorilla” vietettävä työaika huomattiin jossakin vaiheessa projektin kannalta välttämättömäksi, koska monet päätökset ja valinnat vaativat vähintään kahden, ellei jopa useamman henkilön mielipiteen tai kannanoton. Yhteisen ajan löytäminen osoittautui ajoittain hieman hankalaksi, koska lähes kaikilla ryhmän jäsenillä oli myös muita aktiviteetteja kuin Sovellusprojekti. Tähän vaikutti omalta osaltaan myös se, että osa ryhmän jäsenistä oli valmiimpia joustamaan ja ”uhrautumaan” joiden asioiden läpiviennin mahdollistamiseksi. Ajankäytön oikeanlainen oppiminen oli siis selkeä haaste, jonka voittamisessa onnistuttiin osittain. Täysin koherenttia ryhmän työskentelyajoista ei saatu missään vaiheessa, mutta riittävälle tasolle kuitenkin päästiin. Projektin jäsenten muut menot huomioon ottaen tasoa voidaan pitää jopa hyvänä.

Yhteiset työskentelyajat vaikuttavat suorasti ryhmätyön onnistumiseen. Pienessä toimistossa intensiivinen ryhmätyö on mahdollista, ja tällaisissa olosuhteissa sitä kannattaa myös tavoitella. Ryhmä yhteen työskenteleminen onnistui vaihtelevalla menestyksellä. Ajoittain ryhmä pystyi saumattomaan yhteistyöhön, jossa tulosta syntyi nopeasti ja vaivattomasti. Välillä koettiin kuitenkin täysin päinvastaisia tilanteita, kun jokin ryhmän jäsen oli tehnyt päätöksiä yksin ja ryhtynyt työskentelemään sen mukaisesti. Joskus tällainen saattoi toimiakin, mutta useimmiten ”sooloilua” seurasi palautekeskustelu muun ryhmän kanssa, ja mahdolliset korjaavat toimenpiteet esimerkiksi tuotettuun koodiin. Tällainen ”soutaminen ja huopaaminen” huomattiin varsin turhauttavaksi ja turhaksi, mistä johtuen siitä pyrittiin pääsemään eroon. Mitä pidemmälle projekti eteni, niin sen paremmin ryhmä oppi työskentelemään yhdessä.

Intensiivinen projektityöskentely ei voi olla aiheuttamatta joitakin erimielisyyksiä neljän kuukauden ajanjaksolla. Kokako-projektissa erimielisyyksiä ilmeni ainoastaan satunnaisesti ja silloinkin kyse oli näkemyksellisistä eroavaisuuksista. Suurempia riitoja ei ilmennyt missään vaiheessa, ja projektin jäsenet tulivat hyvin toimeen keskenään.

Paineiden ja stressin sietäminen osoittautuivat olennaisiksi taidoiksi erityisesti silloin kun väli- tai loppuesittelyt lähestyivät ja sovelluksen kehitys oli vielä pahasti kesken. Näissä tilanteissa ainakin ryhmän yhteinen paineen- ja stressinsieto oli huippuluokkaa, koska varsinkin toisen väliesittelyn kohdalla sovellus oli vielä pahasti kesken, mutta siitä huolimatta sovellus pystyttiin esittelemään hienosti. Varsinaisen toteutuksen suhteen vastaavia määräaikoja ei ollut, eikä normaalityössä pystytty havaitsemaan samanlaisia stressiä aiheuttavia tilanteita. Työelämän projektien simulointi olisi onnistunut näiltä osin paremmin, jos tilaaja eikä projektiryhmä itse olisi asettanut määräaikoja sovelluksen valmistumiselle. Toisaalta opiskeluprojektissa ei voida odottaa, että ryhmän jäsenet kykenisivät tekemään jatkuvasti 40-tuntista työviikkoa muiden kurssien ohella. Tällöin myös tiukkojen ja ehdottomien määräaikojen asettaminen saattaa olla ongelmallista. Suurin paine ja stressi aiheutuivat ainakin osalle ryhmän jäsenistä siitä tunteesta, kun työtä oli vielä paljon jäljellä ja se ei tuntunut tekemällä loppuvan.

Käyttäjäkeskeisessä suunnittelussa ryhmä oppi käytettävyyden huomiointia ohjelmiston suunnittelussa. Käytettävyys pyrittiin ottamaan huomioon erityisesti esittelemällä käyttöliittymää tilaajalle aina määrätyin väliajoin. Käyttäjän mielipiteiden ja toiveiden huomiointi on käyttäjäkeskeisen suunnittelun perusta, joten ainakin osittain tämän tavoitteen toteutuminen onnistui. Käyttäjän eli tilaajan mielipiteitä olisi tosin voinut tiedustella hieman useammin ja vuorovaikutus olisi voinut olla tiiviimpääkin.

Esiintymisen osalta ryhmä sai projektin aikana rutkasti lisää kokemusta. Jokaisella ryhmän jäsenellä oli jo aiempaa kokemusta yleisölle esiintymisestä, mutta ryhmänä esiintymisestä vähemmän. Haasteena väli- ja loppuesittelyissä oli esityksen mahduttaminen tiukkaan aikarajaan eli maksimissaan 17 minuuttiin. Kyseisen ajan puitteissa ryhmän piti esitellä itsensä, tilaaja, projektin taustaa sekä toteutettava sovellus. Esityksen sujuva läpivienti vaati runsaasti suunnittelua ja harjoittelemista varsinkin ensimmäisellä kerralla. Toisessa väliesittelyssä sovellus oli niin keskeneräinen, että esityksen läpiviennin onnistuminen vaikutti epävarmalta. Se onnistui kuitenkin hyvin, ja loppuesittelyssä esittely sujui jo melko vaivattomasti. Esiintymisen osalta oppimistavoitteet toteutuivat hyvin.

Palaverikäyttäytymisestä kaikilla ryhmän jäsenillä ei ollut aiempaa kokemusta. Osalle palavereissa istuminen oli jo valmiiksi tuttua, eikä se tuntunut enää uudelta tai jännittävältä asialta. Lisäharjoitus teki kuitenkin kaikille hyvää, ja jokainen pääsi kokeilemaan mm. puheenjohtajan ja sihteerin roolia. Palaverikäyttäytyminen on ryhmän omien arvioiden mukaan niitä projektiin liittyviä asioita, joista ryhmän jäsenille tulee olemaan erityisesti hyötyä tulevaisuudessa. Pöytäkirjojen kirjoittaminen antoi myös hyvää kokemusta siitä miten virallisia asiakirjoja laaditaan.

5 Organisaatio ja resurssit

Luvussa kuvataan projektiorganisaatio ja projektin käytössä olleet resurssit.

5.1 Projektin henkilöt ja yhteystiedot

Seuraavista kohdista selviävät projektiin liittyvät henkilöt ja heidän yhteystietonsa.

5.1.1 Projektiryhmä

Ryhmän jäseniä ovat

Honkonen Tapio, fil. yo, jonka erityisosaaminen keskittyy aikuiskoulutukseen ja sulautettuihin järjestelmiin.
Lamminen Turo, fil. yo, jonka erityisosaaminen keskittyy ohjelmistotekniikkaan.
Räsänen Tuomas, fil. yo, jonka erityisosaaminen keskittyy ohjelmistotekniikkaan.
Väärämäki Tapio, fil. yo, jonka erityisosaaminen keskittyy tietoliikenteeseen.

Ryhmän jäsenten yhteystiedot on kuvattu taulukossa 1.

Nimi	Sähköposti	Puhelin
Honkonen Tapio	taphonko@jyu.fi	040 762 9083
Lamminen Turo	tulammin@jyu.fi	0400 340 766
Räsänen Tuomas	tuos@jyu.fi	040 777 4149
Väärämäki Tapio	tapiov@jyu.fi	044 078 0780

Taulukko 1: Projektiryhmän yhteystiedot

5.1.2 Ohjaajat

Projektia ohjaavat

· Korhonen Vesa, yliopistonopettaja, vastaava ohjaaja

· Suomalainen Matti, tekninen ohjaaja

Ohjaajien yhteystiedot ovat kuvattu taulukossa 2.

Nimi	Sähköposti	Puhelin
Korhonen Vesa	vkorhone@mit.jyu.fi	014 260 4976
Suomalainen Matti	msuomal@jyu.fi	044 321 4236

Taulukko 2: Ohjaajien yhteystiedot

5.1.3 Tilaajan edustajat

Tilaajan edustajina toimivat

Ihanainen Eija, opintoasiainpäällikkö, informaatioteknologian tiedekunta. Eijan tehtävänä projektissa oli esiintuoda koostajan ja sisällöntuottajan mielipiteitä sovelluksen kehitykseen liittyen sekä toimia tilaajan toisena virallisena edustajana.
Auer Antti, koordinaattori, Virtuaaliyliopisto. Antti toimi projektin aikana asiantuntijana ja toisena tilaajan edustajana.
Honkaranta Anne, lehtori, tekninen neuvonantaja, tietojenkäsittelytieteen laitos. Anne toimi projektissa teknisenä asiantuntijana erityisesti XML ja XSLT asioissa.
Nurminen Miika, suunnittelija, tekninen neuvonantaja, informaatioteknologian tiedekunta. Miika toimi projektin teknisenä asiantuntijana sovelluskehityksen kaikilla sektoreilla.
Lappalainen Vesa, lehtori, tekninen neuvonantaja, tietotekniikan laitos. Vesa Lappalainen toimi asiantuntijana erityisesti Java-ohjelmointiin liittyvissä asioissa.

Tilaajan edustajien yhteystiedot on kuvattu taulukossa 3.

Nimi	Sähköposti	Puhelin
Ihanainen Eija	opintoasiat@it.jyu.fi	014 260 2791
Auer Antti	auer@jyu.fi	014 260 4319
Honkaranta Anne	anne.honkaranta@it.jyu.fi	014 260 3041
Nurminen Miika	minurmin@jyu.fi	014 260 2530
Lappalainen Vesa	vesal@mit.jyu.fi	014 260 2722

Taulukko 3: Tilaajan edustajien yhteystiedot

5.2 Työtilat, laitteet, ohjelmistot ja tuki

Jyväskylän yliopiston tietotekniikan laitos oli luovuttanut projektiryhmän käyttöön lukittavan huoneen AgC223.3. Kyseisessä tilassa oli kolme Windows XP SP2- ja yksi Linux- käyttöjärjestelmällä varustettua tietokonetta. Lisäksi yhteen tietokoneeseen oli asennettu MS Project 2000-, Oxygen 7.1- ja Altova XMLSpy prof 2004-ohjelmisto. Muut mahdollisesti projektin tarvitsemat ohjelmistot projektiryhmälle saatiin informaatioteknologian tiedekunnan ATK-tuen kautta, joka toimii myös projektin ATK-tukena. Lisäksi ryhmällä oli käytössä tarvittaessa tietotekniikan laitoksen Sovellusprojektien MiniDisc-tallennin, digitaalikamera, digitaalisanelin, 2 kannettavaa tietokonetta, videoprojektori, kopiokone, kokoustila (AgC223.1) sekä projektitiloista löytyvät tulostin, tee- ja kahvinkeitin.

5.3 Perehdytykset

Sovellusprojektien käytännön perehdytykset hoiti tietotekniikan laitos Sovellusprojektien oheiskurssin muodossa. Projektiryhmän perehdytyksen olemassa olevaan opinto-oppaan koostamisohjelmaan hoiti Miika Nurminen ja XML- sekä XSLT-perehdytykset Anne Honkaranta.

Perehdytyksistä oli erityisesti projektin alkuvaiheilla paljon hyötyä, kun ryhmä ei vielä tiennyt käsiteltävistä aiheista juuri lainkaan ja perehdyttäjä pystyi tarjoamaan tiiviin paketin olennaisesta informaatiosta aiheeseen liittyen.

Oheiskurssiin liittyvät koulutukset olivat nekin varsin hyödyllisiä, sillä niissä opetettiin useita projektityöskentelyn peruskäytänteitä. Käytettävyys- ja tekijänoikeuspäivistä erityisesti käytettävyyspäivä oli varsin hyödyllinen, koska sen aikana ryhmä sai koulutusta käyttöliittymien käyttäjäystävällisestä suunnittelusta. Versionhallintakoulutusta voidaan pitää lähes välttämättömänä, koska ryhmän tuottamaa koodia säilytettiin versionhallintapalvelimella.

6 Tehtävät, työmäärät ja työnjako

Tässä kappaleessa kuvataan Kokako-projektiin liittyviä tehtäviä, niiden tekemiseen käytettyä aikaa ja työn jakautumista eri projektijäsenien kesken.

6.1 Suunnitelmat

Alun perin projektin työnjaon suunniteltiin jakautuvan seuraavasti: Tapio Honkonen toimii projektipäällikkönä ja hoitaa asiaan kuuluvat suunnittelut sekä projektin seurannan. Hän osallistuu myös XSLT:n liittyviin suunnittelu- ja toteutustehtäviin. Tapio Väärämäki hoitaa suurimman osan projektin dokumentoinnista ja osallistuu myös toteutusvaiheen tehtäviin. Turo Lamminen ja Tuomas Räsänen kantavat päävastuun järjestelmän suunnittelusta ja toteutuksesta [3].

Yksityiskohtaisemmassa ajankäyttösuunnitelamassa eli Gantt-kaaviossa työtunnit oli allokoitu eri työtehtäville yhden tunnin tarkkuudella. Gantt-kaavio on nähtävissä projektisuunnitelmassa [1]. Yleisellä tasolla kuvattuna työn oli suunniteltu jakautuvan hieman kategoriakohtaisesti eri projektin jäsenten kesken.

6.2 Toteutunut työnjako

Ajankäyttösuunnitelma ja siihen liittyvä tehtävälista piti laatia koko projektin ajalle yhdellä kertaa ja vieläpä yhden tunnin tarkkuudella. Ottaen huomioon ryhmänjäsenien vähäisen aiemman kokemuksen aiemmista ohjelmistoprojekteista, tällaista vähäisillä lähtötiedoilla laadittua ajankäyttösuunnitelmaa ei voida pitää kovin realistina, ja ryhmä epäili heti alusta pitäen suunnitelman paikkansapitävyyttä ja toteutumista. Ryhmän epäilyt kävivät varsin nopeasti toteen, kun esimerkiksi Ploneen liittyvät työtehtävät karsiutuivat pois jo projektin alkuvaiheilla.

Projektin tehtävät on läpikäyty alla olevassa listassa, ja niihin osallistuneet henkilöt on merkitty kunkin tehtävän yhteyteen:

Projektin hallinta:

Projektin suunnittelu oli allokoitu projektipäällikön tehtäväksi. Tämän tehtävän osalta suunnitelmat vastasivat hyvin toteutunutta työnjakoa ja projektipäällikkö vastasi käytännössä yksin projektin suunnittelusta.
Projektisopimus oli allokoitu alun perin TL:n tehtäväksi. Tehtävän toteutukseen osallistuivat myös muut jäsenet lähinnä sopivan lisenssiformaatin valinnassa, joten työnjako vastasi suunniteltua.
Tiedotus oli allokoitu suunnitelmissa projektipäällikön vastuulle. Toteutunutta työnjakoa tarkasteltaessa suunnitelmat eivät kuitenkaan toteutuneet, koska tiedotukseen osallistui olennaisesti TH:n lisäksi myös TV.
Projektin hallinnan toteutukseen kuuluvilla tehtävillä tarkoitetaan ensisijaisesti projektipäällikön päivittäisiä tai viikoittaisia tehtäviä, kuten ajankäyttöraporttien koostamista. Tämä tehtävä oli allokoitu kokonaan projektipäällikölle. Toteutunut työnjako vastasi suunniteltua.
Projektin raportointi oli allokoitu alun perin projektipäällikön tehtäväksi, mutta todellisuudessa TV vastasi pääosin sen laatimisesta. Raportin laatimiseen tarvittiin tietysti ryhmän jokaisen jäsenen kontribuutiota, mutta kirjoitusvastuu jäi pääosin kuitenkin TV:lle.
Kotisivut oli allokoitu suunnitelmissa TR:lle ja TV:lle. Työnjako toteutui suunnitelmien mukaisesti.
Loppuesittely ja valmistelu oli allokoitu koko ryhmän tehtäväksi. Varsinaiseen esitykseen ja myös sen valmisteluun osallistui koko ryhmä.

Perehdytykset:

Aiheeseen ja työkaluihin tutustuminen oli allokoitu suunnitelmassa koko ryhmän tehtäväksi, ja se myös toteutui näin.

Palaverit:

Palaverit oli allokoitu koko ryhmän tehtäväksi, ja niihin luonnollisesti osallistui koko ryhmä. Pöytäkirjojen laatimisesta vastasi TV ja hänen työnsä osuus tässä kohtaa oli jonkin verran muita suurempi.

Suunnittelu:

Vaatimusten määrittely oli allokoitu TV:n tehtäväksi. Toteutunut vastasi hyvin suunniteltua ja TV vastasi dokumentin laadinnasta. TH kontribuoi tehtävää määrittelemällä dokumentin ulkoasun projektisuunnitelman mukaiseksi.
XSLT-muunnokset oli allokoitu TL:n tehtäväksi. Toteutunut vastasi suunniteltua varsin hyvin, koska TL vastasi käytännössä yksin XSLT-muunnoksien suunnittelusta ja toteutuksesta.
OpenOffice 2.0 oli allokoitu TR:n tehtäväksi. Suunnittelutehtäviin osallistui TR:n lisäksi myös muu ryhmä editorin käytettävyyteen liittyvissä asioissa.
Ploneen liittyviä suunniteltuja tehtäviä ei toteutettu missään vaiheessa, koska Plone järjestelmän integroinnista osaksi koostamissovellusta ei koettu saatavan minkäänlaista lisähyötyä.
Koostamistyökalu käsittää varsinaisen koostamistyökalun lisäksi myös koko sovelluksen käyttöliittymän. Tehtävän laajuudesta johtuen suunniteltu työnjako ei vastannut toteutunutta, vaan tehtävään osallistuivat kaikki projektin jäsenet. Koostamistyökaluun liittyvät suunnittelutehtävät sisälsivät lähinnä käyttöliittymän suunnittelua ja ohjelmointikielen valinnan. Tehtäviin osallistuivat kaikki ryhmän jäsenet.
Versionhallinta oli allokoitu alun perin TH:n ja TR:n tehtäväksi. Suunnitteluun osallistui kuitenkin erityisesti TL, jolla oli paljon aiempaa kokemusta versionhallintajärjestelmistä. Versionhallintakomponentti jäi pysyvästi suunnitteluasteelle, koska projektin resurssit eivät antaneet myötä itse toteutukselle. Tähän työtehtävään osallistuivat kaikki ryhmän jäsenet palavereissa, joissa asiasta usein keskusteltiin.
Integrointi oli allokoitu TR:lle ja TL:lle, mutta siihen osallistuivat kaikki ryhmän jäsenet. Komponenttien yhteen sovittaminen on niin laaja kokonaisuus, että sen suunnittelun osallistuminen katsottiin olevan aiheellista jokaiselle ryhmän jäsenelle.
Sovellussuunitelma oli allokoitu alun perin TH:n tehtäväksi. Tehtävä siirtyi kuitenkin kokonaan TV:lle, mikä oli osittain odotettavissa, koska dokumentointi oli suunniteltu olevan pääasiassa TV:n vastuulla.

Toteutus:

XSLT-muunnokset oli allokoitu TL:n tehtäväksi. Suunnitelma toteutui hyvin, kun TL vastasi muunnoksien toteutuksesta kokonaan yksin.
OpenOffice 2.0 oli allokoitu TR:lle. Suunnitelma vastasi toteutunutta ja TR vastasi OO2 muokkaamisesta yksin.
Koostamistyökalu oli niin laaja-aiheinen työtehtävä, että sen toteutukseen tarvittiin koko ryhmän kontribuutiota. TR vastasi raahaamispuun toteutuksesta, TH käyttöliittymästä, TV graafisista komponenteista ja TL viimeisteli työtä.
Versionhallinta ei päässyt toteutusasteelle.
Integrointityö oli allokoitu TR:lle ja TL:lle. Heidän lisäksi siihen osallistui joiltakin osin myös TH.

Testaus ja viimeistely:

Testauksen suunnittelu jäi tekemättä kokonaan, koska millekään erilliselle testiohjelmalle ei pystytty varaamaan resursseja.
Testaus oli allokoitu TL:n ja TR:n tehtäviksi, mutta siihen osallistui kukin ryhmän jäsen sovelluksen eri komponenttien kehitystyön yhteydessä.
Asennus- ja käyttöohje oli allokoitu TV:n tehtäväksi. Suunnitelma vastasi toteutunutta.
Tulosten viimeistely oli allokoitu kaikkien paitsi TL:n tehtäväksi. Tähän osallistuivat pääasiassa TH ja TL.
Sovellusraportti oli allokoitu koko ryhmän tehtäväksi. Kirjoitusvastuu jäi todellisuudessa TH:lle, mutta sisällön määrittämiseen osallistui koko ryhmä.

Yleiskommenttina työnjaon toteutumisesta voitaneen sanoa, että se toteutui suunnitelmiin nähden puolittain. Työnjakoa jouduttiin mukauttamaan useita kertoja työtilanteen mukaan esimerkiksi jonkin työtehtävän venyttyä kestoltaan odotettua pitemmäksi. Työn uudelleenjakautuminen ei ollut kuitenkaan mikään ongelma, koska yleensä työ pystyttiin ohjaamaan sellaiselle henkilölle, jolla oli aikaa perehtyä siihen. Suuremman ongelman muodosti työtehtävien keston venyminen odotettua pidemmäksi. Aikataulun toteutumista arvioidaan tarkemmin seuraavassa alaluvussa.

6.3 Aikataulu

Projektin aikataulutus suunniteltiin siten, että projekti olisi valmis toukokuun loppuun mennessä. Jo toukokuun puoliväliin mennessä oli kuitenkin selvää, ettei projektia saada millään valmiiksi suunnitellun aikataulun puitteissa. Projektin venymiseen vaikutti keskeisesti kaksi eri tekijää: työn käynnistämisen hitaus ja tekijäryhmän muut velvollisuudet sovellusprojektin ohessa. Työn ennakoitua suurempi määrä oli myös eräs osatekijä projektin venymisessä.

Kokako-projekti saatiin todenteolla käyntiin vasta maaliskuun alussa, mikä tarkoittaa projektin ensimmäisen kuukauden olleen huomattavasti muita kuukausia tehottomampi. Helmikuun aikana ryhmä pystyi työskentelemään enimmilläänkin vain 65 tuntia viikossa, kun parhaina viikkoina työtunteja kertyi lähes 120. Ensimmäinen kuukausi kului pääasiassa projektin aiheen kartoittamiseen, työkaluihin tutustumiseen, projektikäytänteiden opetteluun ja muuhun projektin käynnistykseen liittyvään toimintaan. Kaikille ryhmän jäsenille ei ollut myöskään alkuvaiheessa selvää mitä he voisivat oikeastaan tehdä.

Projektin hitaan aloituksen jälkeen ryhmä työskenteli keskimäärin vajaat 100 tuntia viikossa. Tämä tarkoittaa noin 25 tuntia henkilöä kohti. Tehostettavaa olisi ollut 40-tuntiseen työviikkoon verrattuna noin 15 tuntia per henkilö. Ryhmän jäsenten muut velvoitteet eivät kuitenkaan mahdollistaneet juuri yli 30-tuntisia työviikkoja. Osa ryhmän jäsenistä joutui työskentelemään huomattavia määriä myös viikonloppuisin, kyetäkseen työskentelemään riittävästi. Mikäli ryhmän kaikilla jäsenillä olisi ollut mahdollisuus tehdä 40-tuntisia työviikkoja koko projektin ajan, niin työ olisi saatu valmiiksi useita viikkoja nykyistä aiemmin.

Työtehtävien venymisen osalta erityisesti toteutus aiheutti moninaisia ongelmia. Varsinkin OpenOfficen ja XSLT-muunnoksien työstäminen vaativat niin paljon odotettua enemmän aikaa, että resurssien allokointi suunnitelmien mukaisiin tehtäviin ajallaan ei ollut mahdollista. Tästä seurasi väistämättä se, että projektin tavoitteita ja tehtäviä jouduttiin karsimaan. Noin huhtikuun puolivälissä ryhmä sopi tilaajan kanssa, että projektin tärkein tavoite on toteuttaa helppokäyttöinen ja tehokas XML-editori sekä koostamistyökalu. Muut suunnitellut toiminnallisuudet, kuten Korppi-kytkentä ja alilukujen käsittely, määriteltiin toteutusprioriteetiltaan toissijaisiksi. Aiheen uudelleenrajaukset olivat välttämättömiä, jotta projektin valmistuminen edes jollain tapaa aikarajojen puitteissa oli mahdollista.

Aikataulun toteutuminen suunnitellusti ei onnistunut kovin hyvin. Asiaa puitiin ryhmän jäsenten ja tilaajan toimesta useissa projektipalavereissa. Tilaaja ja ryhmän vastaava ohjaaja pitivät aikataulun venymistä kuitenkin täysin ymmärrettävänä, koska kyseessä on ryhmän ensimmäinen projekti. Ryhmän vastaavan ohjaajan mukaan eräs projektin oppimistavoitteista oli havaita suunnitelmissa tehdyt virheet ja oppia niistä. Ryhmän mielestä seuraavassa projektissa realistisemman aikataulutuksen suunnitteleminen olisi huomattavasti helpompaa, kun projektityöskentelyyn liittyvät käytänteet ovat tuttuja. Projekti valmistui lopulta noin neljä kuukautta suunniteltua myöhemmin.

6.4 Ajankäyttökaaviot

Kokako-projektin ajankäytöstä pidettiin ns. tuntikirjaa, johon kirjattiin kaikki projektin aikana tehdyt työtunnit. Kukin työtunti sijoitettiin aina johonkin seuraavista kategorioista: projektin hallinta, perehdytykset, palaverit, suunnittelu, toteutus, testaus ja viimeistely sekä oheiskurssi. Kategorioiden selitykset ovat seuraavat:

Projektin hallinnalla tarkoitetaan projektin johtamiseen ja hallinnointiin liittyviä tehtäviä. Tähän kategoriaan liittyvät tehtävät kuuluvat ensisijaisesti projektipäällikölle.

Perehdytykset tarkoittavat erilaisia koulutus- ja perehdytystilaisuuksia. Tähän kategoriaan liittyvät tehtävät ajoittuivat pääasiassa kurssin alkuun.

Palaverit tarkoittavat viikkopalavereita ja pöytäkirjan laatimista, sekä palavereiden valmistelua. Koko ryhmä osallistui palavereihin lähes viikottain.

Suunnittelu tarkoittaa kaikkea suunnittelutyötä projektiin ja toteutukseen liittyen. Dokumentointi on myös suunnittelua.

Toteutus tarkoittaa kaikkia sovelluksen toteutukseen liittyviä tehtäviä. Esimerkiksi ohjelmointi, graafinen suunnittelu ja OO:n modifiointi ovat tällaisia tehtäviä.

Testaus ja viimeistely tarkoittavat testaamiseen liittyviä tehtäviä. Testaukseen liittyviä työtunteja ei ole merkitty lainkaan tähän kategoriaan, koska ryhmä on tehnyt testaustyötä muun työn ohessa. Viimeistelytehtäviä on ollut ainoastaan projektin loppuvaiheilla, eikä sitä ole myöskään merkitty kirjanpitoon erikseen.

Oheiskurssi tarkoittaa kaikkia oheiskurssiin käytettyjä työtunteja. Näitä ovat esimerkiksi tekijänoikeus- ja käytettävyyskoulutukset.

Ajankäytön jakautuminen eri kategorioihin oli täysin henkilöstä kiinni. Esimerkiksi TV, joka toimi erityisesti suunnittelu- ja dokumentointitehtävissä kerrytti työtunteja suunnittelu-kategoriaan huomattavasti muita enemmän. Vastaavasti projektipäälliköllä kertyi huomattavasti muita enemmän tunteja projektin hallinta -kategoriaan. TL ja TR työstivät itse sovellusta huomattavan osan projektista, joten heillä on toteutus-kategoriassa eniten tunteja. Palavereihin kullekin ryhmän jäsenelle kertyi TV:tä lukuun ottamatta sama määrä työtunteja. TV vastasi pöytäkirjojen laatimisesta, joten hänelle palaveri-kategoriaan kuuluvia työntunteja kertyi noin puolet enemmän kuin muille.

Käytössä ollut tuntikirja oli ryhmän mielestä varsin kätevä, koska sen avulla oli helppo seurata työmäärien edistymistä projektin edetessä. Sen avulla oli myös kätevää esitellä projektin etenemistä tilaajalle ja vastaavalle ohjaajalle viikkopalavereissa.

Ryhmän ajankäyttö on nähtävissä alla olevissa graafeissa ja taulukoissa.

Taulukko 4. esittää projektin suunniteltua ja toteutunutta ajankäyttöä tunnin tarkkuudella.

Kuva 2. esittää projektin suunnitellun ajankäytön jakautumista piirakkadiagrammin muodossa.

Kuva 3. esittää projektin toteutuneen ajankäytön jakautumista piirakkadiagrammin muodossa.

Kuva 4. esittää ryhmän jäsenten ajankäytön jakautumista viikoittain.

Taulukko 4. Projektin suunniteltu ja toteutunut ajankäyttö

Kuva 2. Projektin suunnitellun ajankäytön jakautuminen

Kuva 3. Projektin toteutuneen ajankäytön jakautuminen

Kuva 4. Ajankäytön jakautuminen viikottain

Projektin suunniteltua ja toteutunutta ajankäyttöä tarkasteltaessa on nähtävissä selkeitä eroja suunniteltujen ja toteutuneiden työtuntien välillä. Itse työtuntimäärissä ei ollut valtaisaa eroa, ainoastaan 54 tuntia. Sen sijaan käytettyjen resurssien allokointi poikkesi suunnitelman ja käytännön välillä huomattavasti. Tämä on havaittavissa erityisen hyvin yllä olevista piirakkadiagrammeista.

Suunnitelmissa toteutuksen arvioitiin vaativan 15% kokonaistyötunneista, mutta lopulta toteutuksen osuus oli jopa 47% kokonaistyötunneista.

Vastaavasti suunnitteluun oli ennakoitu 25% kaikista työtunneista, mutta siihen kului ainoastaan 15% työtunneista.

Testauksen ja viimeistelyn arvioitiin vaativan 11% työtunneista, mutta lopulta se vaati ainoastaan 5%. Tämä johtunee pitkälti siitä, ettei testaamiselle jäänyt käytännössä lainkaan aikaa. Viimeistelyä oli sen sijaan ”pakko” tehdä, jotta kehitetystä ohjelmistosta saatiin edes jonkinasteinen loppuversio.

Oheiskurssi vaati ainoastaan puolet suunnitellusta 12% osuudesta, eli 6% kaikista työtunneista. Eroavaisuudet suunniteltujen ja toteutuneiden tuntien kohdalla johtuvat merkinnällisistä käytänteistä. Osa toteutuneista tunneista kirjattiin muihin kategorioihin.

Projektin hallintaan käytetyt työtunnit vastasivat suunniteltuja melko hyvin. Suunnitelluista 14% kaikista työtunneista toteutui 12%. Työtunnit jakautuivat suunniteltua useammalle henkilölle, koska projektin raportointiin osallistui TH:n lisäksi myös TV.

Perehdytyksiä tarvittiin odotettua vähemmän, ja niinpä suunnitellut 11% kaikista työtunneista kutistui 5%. Perehdytyksiä tapahtui myös epävirallisemmassa muodossa esimerkiksi teknisen ohjaajan saapuessa projektitilaan. Tällaisia tilanteita ei merkitty perehdytykseksi.

Palaverit osattiin ennakoida hyvin, eikä niiden suunnitellussa ja toteutuneessa ajankäytössä ollut merkittäviä eroja. Suunniteltu 12%, toteutunut 11%.

Merkittävimmät eroavaisuudet suunniteltujen ja toteutuneiden työtuntien välillä syntyivät selvästi toteutuksessa. Tämä selittyy luontevasti sillä, että projektin suunnitteluvaiheessa ryhmällä ei ollut vielä tarkkaa tietoa toteutettavasta sovelluksesta ja kaikista sen toiminnallisista vaatimuksista.

Suunnitteluvaiheesta siirryttiin nopeasti varsinaiseen toteutukseen, johon kuluikin lähes puolet kaikista projektin työtunneista. Runsas ajankäyttö toteutuksessa kertoo toteutuspainotteisesta projektista, jossa on luotu paljon uutta. Kokako-projektia tarkasteltaessa tämä pitää pitkälti paikkansa.

Toteutuksen runsasta ajankäyttöä kompensointiin pienemmällä ajankäytöllä muissa osa-alueissa. Ryhmän mielestä tällainen on hyvä esimerkki mukautumisesta vallitseviin työolosuhteisiin ja asiakkaan toiveisiin. Resursseja kyettiin siis keskittämään olennaisiin tehtäviin, ja vähemmän tärkeät asiat jätettiin vähemmällä – niitä kuitenkaan unohtamatta.

Suunniteltua ja toteutunutta ajankäyttöä ei ryhdytä erittelemään henkilökohtaisella tasolla, koska se ei anna ryhmän mielestä lisäarvoa ajankäytön analysointiin. Lisäksi tiedot kunkin henkilön työtunneista löytyvät jo taulukosta 4. sekä viikkotarkkuudella kuvasta 4.

Suunnitteluvaiheessa ei tiedetty vielä eri henkilöiden välisiä erovaisuuksia osaamisessa, ja niinpä työtehtävien lopullinen allokointi oli vaikeaa. Henkilökohtaisella tasolla suunniteltujen ja toteutuneiden työtuntien välillä olikin huomattavia eroja, mikä on nähtävissä taulukosta 4.

7 Riskit, niiden seuranta ja hallinta

Tässä luvussa kuvataan projektiin liittyneitä toteutuneita ja toteutumattomia riskejä. Kunkin riskin kohdalla on kuvattu miten riskiä on pyritty ehkäisemään, havaitsemaan ja hallitsemaan.

Taulukossa 5 on nähtävillä projektisuunnitelmassa ennakoidut riskit:

Riski	Todennäköisyys	Haitta	Toteutui	Tot. vaikutus
Projektin vaatimusten epätarkkuus	Keskinkertainen	Keskinkertainen	Kyllä	keskinkertainen
Projektikokemuksen puute	Korkea	Matala	Kyllä	Matala
Projektin lähtökohtiin perehdyttämisen puute	Matala	Korkea	Kyllä	Matala
Viestinnän ongelmat	Matala	Keskinkertainen	Kyllä	Matala
Dokumentoinnin puute	Matala	Korkea	Kyllä	Matala
Laitteistoviat	Matala	Korkea	Kyllä	Matala
Versionhallinnan puutteellinen käyttö	Matala	Keskinkertainen	Ei	-
Integrointiongelmat	Keskinkertainen	Keskinkertainen	Kyllä	Matala
Käytettävien työkalujen sopimattomuus	Matala	Korkea	Kyllä	Korkea
Ohjauksen puute	Keskinkertainen	Korkea	Kyllä	Matala
Sairastuminen	Pieni	Keskinkertainen	Kyllä	Matala

Taulukko 5: Projektiin kohdistuvat riskit

7.1 Projektin vaatimusten epätarkkuus

Projektin vaatimusten epätarkkuus oli havaittavissa jo projektin aloitusvaiheessa, kun ryhmällä ei ollut ennen ensimmäistä asiakastapaamista juuri minkäänlaista käsitystä toteutettavasta sovelluksesta, ja asia tuntui olevan hieman iterointivaiheessa myös tilaajan osalta. Riski ei kuitenkaan konkretisoitunut kriittiseksi ongelmaksi missään vaiheessa, koska ryhmä pääsi tilaajan kanssa nopeasti rakentavaan vuoropuheluun. Vaatimuksia alettiinkin listata nopeasti niin tilaajan kuin myös tekijäryhmän toimesta.

Ryhmän näkemyksen mukaan vaatimusten epätarkkuudella oli jonkinasteinen vaikutus projektin alun hitauteen, ja myös tilaaja oli asiasta samaa mieltä. Riski saatiin kuitenkin hallittua ryhtymällä töihin riittävän nopeasti, ja siitä ei aiheutunut pahaa viivästymistä missään vaiheessa.

7.2 Projektikokemuksen puute

Suurin osa ryhmän jäsenistä ei ole ollut aiemmin mukana vastaavan kokoisessa ja tasoisessa projektissa. Tätä ei pidetty millään tapaa suurena ongelmana, koska tilanne on luultavasti lähes samanlainen kaikissa muissakin ryhmissä, ja Sovellusprojektit-kurssin tehtävänä on nimenomaan opettaa projektityöskentelyä.

Ennen projektin käynnistymistä pahimpia tähän riskiin liittyviä mahdollisia ongelmia arvioitiin olevan mahdollinen tehottomuus ja projektimuotoisen työskentelyn hallitsemiseen liittyvät ongelmat. Tällaisia ongelmia ei kuitenkaan juuri esiintynyt. Tähän vaikuttaa omalta osaltaan varmasti se, että ryhmä oli hyvin motivoitunut projektiin ja myös projektin sisäinen ilmapiiri oli tekemisen osalta kannustava. Tehdyistä virheistä ei myöskään moitittu, vaan niistä pyrittiin enneminkin oppimaan ja löytämään hyviä puolia. Suurin tähän riskiin liittynyt ongelma oli ajoittainen ryhmätyön puute, joka ilmentyessään haittasi erityisesti toteutusvaiheen työskentelyä.

7.3 Projektin lähtökohtiin perehdyttämisen puute

Projektin lähtökohtien perehtymisen puutetta pidettiin epätodennäköisenä, mutta vakavana riskinä. Vakavan siitä teki erityisesti se, ettei ryhmä tiennyt ennen ensimmäistä asiakastapaamista juuri mitään toteutettavasta sovelluksesta tai sen taustasta.

Perehdyttäminen alkoi välittömästi heti ensimmäisessä projektipalaverissa, ja ryhmälle annettiin runsaasti kirjallista materiaalia mm. aiempiin projekteihin, XML:n ja XSLT:n liittyen. Hyvästä perehtymisestä huolimatta tähän riskiin liittyviä ongelmia oli havaittavissa satunnaisesti kun ryhmä ei tiennyt jotain koostamisprosessiin liittyvää yksityiskohtaa. Riski oli kuitenkin äärimmäisen helppo hallita, koska tilaajan edustajat opastivat ryhmää aina tarvittaessa.

7.4 Viestinnän ongelmat

Viestintään liittyvien ongelmien arveltiin esiintyvän erityisesti projektin jäsenten tai tilaajan edustajien muista kiireistä johtuen. Projektiryhmän TV kävi omiin työasioihinsa liittyen Helsingissä vähintään kerran kahdessa viikossa aina huhtikuun puoleen väliin saakka, ja projektin muilla jäsenillä oli paljon opiskeluun liittyviä kiireitä koko kevään ajan. Tällaisessa tilanteessa viestinnän sujuvuus on toimivan projektin lähtökohta.

Ryhmä pyrki hoitamaan viestintää usein eri keinoin, kuten tapaamisilla, sähköpostilla, kotisivuilla ja puhelimitse. Tämän lisäksi projektihuoneen seinällä oli fläppi-taulu, johon kirjattiin projektin kunkin ajanhetken tärkeimmät tehtävät. Hyvän viestinnän opettelu vaati aikansa, ja varsinkin projektin alkuvaiheessa viestinnässä ilmeni puutteita. Ryhmä kuitenkin oppi viestinnän merkityksen projektin edetessä, ja myöhemmin keväällä se toimi huomattavasti paremmin projektin ensimmäisiin kuukausiin verrattuna. Tilaajan mielestä edellisten palaverien pöytäkirjat olisi voinut lähettää hieman nopeammin katsottavaksi. Nyt ne lähetettiin katsottavaksi aina seuraavaa kokousta edeltävänä päivänä.

Riskin havaitseminen oli varsin helppoa, koska viestinnän ollessa puutteellista sen huomasi välittömästi. Tietokatkoksien ilmentyessä samoja asioita piti kertoa moneen kertaan, mikä vei ylimääräistä ja turhaa aikaa. Tietokatkoksien välttämiseksi viestinnän merkitystä korostettiin ryhmän sisäisissä palavereissa.

7.5 Dokumentoinnin puute

Dokumentoinnin puutteen arveltiin olevan painoarvoltaan vakavia riskejä. Sen ehkäisemiseksi ryhmä laati kohtuullisen kattavat pöytäkirjat aina kustakin palaverista heti ensimmäisestä palaverista lähtien. Näin kaikki tilaajalta saadut ideat pystyttiin kirjaaman paperille heti niiden kuulemisen jälkeen. Projektisuunnitelma [3], vaatimusmäärittely [1] ja sovellussuunnitelma [2] olivat myös sellaisia dokumentteja, joista ryhmä halusi työstää selkeitä ja riittävän kattavia.

Tähän riskiin liittyviä ongelmia ilmeni lähinnä satunnaisesti. Tilaajan mielestä dokumenttien palautus olisi voinut olla nopeampaa mm. pöytäkirjojen osalta, mutta sisällöllisesti dokumentit olivat kunnossa. Riski hallittiin dokumentoimalla asioita mieluimmin hieman liian paljon kuin liian vähän.

7.6 Laitteistoviat

Laitteistoviat saattavat olla pahimmillaan ja huonosti ennakoituna jopa projektin lamaannuttavia vikoja. Aiemmissa projekteissa oli jo huomattu, että kaikki tärkeä ohjelmistokoodi, dokumentointi ja muu aineisto on syytä säilyttää varmennetuissa tallennusmedioissa. Näin pystytään varautumaan ainakin mahdollisiin tallennusmedioihin kohdistuviin laitteistovikoihin. Muita mahdollisia ongelmia arveltiin esiintyvän tietokoneiden ja verkkoyhteyksien toimimattomuudessa. Tallennusmediaan liittyviä ongelmia ei esiintynyt missään vaiheessa, mutta työasemiin liittyviä ongelmia riitti jonkin verran. Paikoitellen työasemakoneiden hitaus oli jopa sietämätöntä, eikä työskentelystä meinannut onnistua kun esimerkiksi ohjelman käynnistäminen saattoi viedä jopa kymmeniä sekunteja. Normaalisti vastaava ohjelma olisi käynnistynyt joissakin sekunneissa. Hitauteen ryhmä ei saanut missään vaiheessa mitään konkreettia ratkaisua mikrotuen yrityksistä huolimatta, ja hitauden arveltiin johtuvan lähinnä laitteiston tai tietojärjestelmien huonosta tasosta. Muuten tämä riski pystyttiin hallitsemaan eikä siihen liittyviä ongelmia ilmennyt.

7.7 Versionhallinnan puutteellinen käyttö

Tallennusmedioiden rikkoontumisesta mahdollisesti aiheutuvia riskejä haluttiin välttää käyttämällä versionhallintaa, jonne tallennettiin kaikki ohjelmakoodi ja tärkeimmät dokumentit. Versionhallintajärjestelmä on tiedon varmistukseen liittyvien ominaisuuksien lisäksi äärimmäisen hyödyllinen myös ryhmätyöskentelyssä. Mikäli jokin ryhmän jäsen oli tehnyt muutoksia ohjelmakoodiin, niin muut jäsenet näkivät listan muutoksista yhden komennon avulla. Riski ei toteutunut.

7.8 Integrointiongelmat

Toteutettavan sovelluksen koostuessa useista eri komponenteista eräs aiheellinen riski on integrointiongelmat. Varsinkin projektin alkuvaiheessa ryhmällä ei ollut tarkkaa tietoa lopullisen sovelluksen osakomponenteista, joten niiden yhteensovittaminen oli selvä haaste.

Integrointityötä ryhdyttiin tekemään heti ensimmäisten komponenttien valmistumisen jälkeen integroimalla komponentteja osaksi hallintakäyttöliittymää. Riskin hallintaa vaikeutti komponenttien valmistumisen hitaus, sillä ensimmäinen komponentti valmistui vasta huhtikuun alussa. XSLT-muunnoksien ja OpenOfficen yhteen sovittaminen oli varsin haasteellista, kuten myös kummankin komponentin liittäminen osaksi hallintakäyttöliittymää. Tiedostonäkymien liittämisessä osaksi koostamistyökalua oli myös oma haasteensa.

Riskiä pyrittiin hallitsemaan tekemällä integrointityötä aina kun se oli mahdollista. Tällä tavoin hallinta myös onnistui hyvin, eivätkä integrointiin liittyvät ongelmat päässeet muodostumaan kriittisiksi. Riskiin varautuminen auttoi ryhmää, koska nyt ennakoituihin ongelmiin osattiin jo hieman varautua.

7.9 Käytettävien työkalujen sopimattomuus

Tämän riskin arveltiin kohdistuvan lähinnä niihin työkaluihin ja sovelluksiin, joita muokataan tilaajan käyttötarpeiden mukaiseksi. Käytännössä riski rajattiin siis OpenOfficen modifiointiin ja XSLT-muunnoksiin.

Riski ilmentyi varsin pikaisesti hieman odotettua suurempana, kun TR huomasi OpenOfficen modifioinnin vaativan huomattavaa perehtymistä erilaisiin manuaaleihin. Kattavasta perehtymisestä huolimatta TR ei kyennyt toteuttamaan haluamiansa ratkaisuita ja muutoksia OO:n sen useista rajoitteista johtuen. Mitä pidemmälle modifioinnissa edettiin, niin sen enemmän ongelmia havaittiin. TL:n työstämät XSLT-muunnokset käyttäytyivät joiltakin osin samalla tavalla, ja myös niiden toteutuksessa oli useita yhteensopivuusongelmia.

Riskiä ja siitä aiheutuvia ongelmia pyrittiin hallitsemalla lukemalla ja tutustumalla muokattaviin rajapintoihin ja sovelluksiin mahdollisimman hyvin. Monessa tapauksessa tämä ei kuitenkaan riittänyt, ja ryhmän piti keksiä jokin vaihtoehtoinen ratkaisu. Usein tällainen ratkaisu syntyi muuttamalla hieman suunnittelua toteutusta. Mahdollisista sovelluksen toimintaan liittyvistä muutoksista keskusteltiin aina tilaajan kanssa ennakkoon. Tämä oli ryhmän ehkäpä eniten ongelmiksi konkretisoitunut riski.

7.10 Ohjauksen puute

Mahdollisen ohjauksen puutteen arveltiin hankaloittavan ryhmän työskentelyä jonkin verran. Varsinaiseen projektityöskentelyyn liittyvän ohjauksen puutetta ryhmä ei havainnut missään vaiheessa, kuten ei myöskään tilaajalta pyydetyssä ohjauksessa. Sen sijaan ohjelmointiin ja erityisesti OO:n muokkaukseen liittyvää ohjausta ryhmä olisi kaivannut huomattavasti enemmän. Riskin konkretisoituminen ongelmaksi johtui pääasiassa siitä, että esimerkiksi OO:n muokkaamisesta oli vähän tietoa koko tietotekniikan laitoksella. Useimmat muut tekniset ongelmat, joissa ohjaamista olisi kaivattu, olivat myös sellaisia, ettei niille löytynyt asiantuntijaa koko projektiorganisaatiosta.

Tätä riskiä pyrittiin hallitsemaan pyytämällä myös yliopiston ulkopuolista apua esimerkiksi sähköpostilistoilta. Useimmiten tämä auttoi ja apua saatiin – joskin pienellä viiveellä.

7.11 Sairastuminen

Sairastumisen tai muun vastaavan vastoinkäymisen aiheuttamaa poissaoloa pidettiin ennakkoon painoarvoltaan pienenä riskinä. Arvioi osoittautui projektin aikana oikeaksi, koska kukaan ryhmän jäsenistä ei joutunut olemaan sairauden takia poissa projektin etenemisen kannalta liian pitkään. Ryhmän jäsenet olivat sairaina kevään aikana, mutta sairastumiset olivat kestoltaan korkeintaan viikon mittaisia. Riskiä hallittiin tiedottamalla asioista mm. sähköpostilla poissaoleville henkilöille.

8 Projektin hallintatavat

Projektin hallinnalliset käytännöt määriteltiin projektisuunnitelmassa [3]. Tässä luvussa kuvataan käytänteiden noudattamista ja niihin mahdollisesti tehtyjä muutoksia.

8.1 Ajankäyttö ja tehtävät

Projektipäällikkö määritteli ryhmälle ajankäyttö- ja tehtäväsuunnitelman heti projektin alussa. Suunnitelma toteutettiin Gantt-kaaviona, josta oli yksinkertaista tarkastella projektin etenemistä kunkin tehtävän osalta. Kuten aiemmin tässä dokumentissa on jo kerrottu, ei ajankäyttösuunnitelma vastannut toteutunutta ajankäyttöä kuin osittain. Realististen arvion laatimista pidettiin jo ennakkoon vaikeana, eikä suunnitelman paikkansapitävyys tullut täten yllätyksenä.

Luvussa 6 on kuvattu tarkemmin toteutunutta työnjako ajankäyttöä. Siinä myös kerrotaan, kuinka ryhmä piti kirjaa tehdyistä työtunneista ja miten tehtävien etenemistä seurattiin.

8.2 Tiedostojen hallinta

Projektiryhmän jäsenillä oli käytössään oma verkkolevyllä sijaitseva kotihakemisto, jonne luotiin henkilökohtaiset hakemistot. Tämän lisäksi verkkolevylle luotiin myös yksi yhteinen hakemisto, joka sisälsi mm. projektia koskevat ohjeet, esimerkit sekä ajankäyttöseurantaan liittyvät dokumentit. Henkilökohtaisissa kotihakemistoissa pyrittiin säilyttämään kunkin henkilön omaan työskentelyyn liittyvää aineistoa. Verkkolevyllä säilytettäessä ne ovat kätevästi myös muiden saatavilla, minkä ansiosta verkkolevyn käytöstä tuli suosittua projektin aikana.

Versionhallintajärjestelmässä säilytettiin kaikkea projektin aikana tuotettua ohjelmistokoodia, www-sivujen uusinta versiota ja dokumentteja. Versionhallintajärjestelmä profiloitui ensisijaisesti ohjelmistokoodin tallennusmediaksi ja säilytyspaikaksi sen monipuolisuuden ansiosta.

WWW-sivuilla ryhmä säilytti pääasiassa dokumentteja, pöytäkirjat ja esityslistat mukaan lukien. Tällä tavoin dokumentit pystyttiin pitämään jatkuvasti kaikkien projektiorganisaation saatavilla. Dokumenttien jakelu tapahtui WWW-sivujen välityksellä.

8.2.1 Dokumentointi

Dokumentoinnissa käytettiin MS Office -ohjelmistoa. Kyseiseen ohjelmistoon päädyttiin heti projektin alussa, koska sitä pidettiin tehokkaana ja kaikille tuttuna sovelluksena. Dokumentointi tehtiin suomenkielellä. Dokumenttien laatimisessa ja tarkastamisessa käytettiin iterointimallia. Pöytäkirjoissa ja esityslistoissa iterointimallia ei käytetty muutaman ensimmäisen viikon jälkeen.

Iteroinnissa dokumentit lähetettiin ensin ohjaajan tarkistettavaksi, minkä jälkeen dokumenttien korjattiin ja muokattiin ohjaajan antaman palautteen perusteella. Ohjaajan oltua tyytyväinen dokumenttiin lähetettiin se myös tilaajan katsottavaksi. Tässä vaiheessa dokumentin versionumero oli yleensä 0.9. Kuitenkin esimerkiksi vaatimusmäärittelyn sisältöä läpikäytiin useissa eri palavereissa jo heti projektin alkuvaiheilla, joten mitään eksaktia numerointia tarkastettavien dokumenttien osalta ei ollut käytössä. Lopulta kun dokumentti oli kaikkia osapuolia tyydyttävässä kunnossa, niin siitä julkaistiin versio 1.0, jonka allekirjoittivat tilaajan edustaja, vastaava ohjaaja ja projektipäällikkö. Projektin aikana tuotetut dokumentit ovat julkisia ja ne lisättiin ryhmän WWW-sivuille kaikkien saataville.

Laadittuja dokumentteja olivat:

Allekirjoitettavat	Muut
Projektisuunnitelma [3] Vaatimusmäärittely [1] Sovellussuunnitelma [2] Projektiraportti Sovellusraportti [4]	palaverien esityslistat ja pöytäkirjat arviointiin käytettävät dokumentit ryhmän ajankäytön seuranta käyttöohje

8.3 Tiedotus

Kokako-projektin tiedotukseen käytettiin useita eri kanavia ja menetelmiä. Ryhmän sisäisessä viestinnässä yleisin tapa oli tietenkin kasvotusten keskusteleminen, koska kaikki ryhmän jäsenet työskentelivät samassa huoneessa. Ryhmän sisäisessä viestinnässä käytettiin jossain määrin myös puhelinta ja sähköpostia silloin kun kaikki ryhmän jäsenet eivät olleet paikalla. Tekijäryhmän sisäisenä sähköpostilistana toimi kokako_opis.group@korppi.jyu.fi. Tekijäryhmän ja ohjaajien yhteinen sähköpostituslista oli kokako06_opetus@korppi.jyu.fi.

Koko projektin tiedotuskanavana toimi sähköpostilista kokako06@korppi.jyu.fi. Sen kautta välitettiin kaikki tieto, jonka haluttiin tavoittavan myös tilaajan edustajat. Tätä sähköpostilistaa käytettiin esimerkiksi kokouskutsujen, tilaajalle tarkoitettujen kysymyksien ja pöytäkirjojen välittämiseen.

Ohjaajan kanssa ryhmä keskusteli jonkin verran kasvotusten sekä sähköpostitse. Puhelinta käytettiin lähinnä silloin, kun ohjaaja haluttiin kutsua lyhyellä varoitusajalla käymään ryhmän konttorilla.

8.4 Palaverit

Palavereita pidettiin tilaajan kanssa heti projektin alusta lähtien kerran viikossa. Ryhmän virallinen palaveripäivä oli tiistai, ja kellonaika oli yleensä joko klo 10-12 tai 12-14. Yksi palaveri jouduttiin pitämään keskiviikkona. Muutamana viikkona palaveria ei pidetty lainkaan. Yhteensä virallisia viikkotapaamisia kertyi 14 kappaletta.

Palavereiden sisältö koostui yleensä edellisen viikon tuloksien esittelystä ja tulevan viikon töiden kartoittamisesta. Projektipäällikkö vastasi edellisen viikon tehtävien toteutumisen esittelystä. Tehtävien lisäksi palavereissa keskusteltiin paljon sovelluksen kehityksestä ja siihen liittyvistä ratkaisuista. Ryhmän mielestä palaverit olivatkin äärettömän hyödyllisiä, koska niiden aikana ryhmä sai useimmiten kerättyä huomattavan määrän tilaajan mielipiteitä ja kommentteja lyhyessä ajassa. Tästä johtuen palavereita pidettiinkin viikoittain joitakin poikkeuksia lukuun ottamatta. Siinä vaiheessa kun projektissa oli intensiivisin toteutusvaihe käynnissä, jätettiin muutama viikkopalaveri pitämättä, koska ryhmän mielestä heillä ei ollut tarjota riittävästi asioita esityslistalle.

Palavereiden puheenjohtajan ja sihteerin roolia kokeilivat projektin alussa kaikki ryhmän jäsenet vuorotellen. Kahden ensimmäisen kuukauden jälkeen puheenjohtajana toimi jokaisessa palaverissa TH ja sihteerinä TV.

8.5 Katselmoinnit

Katselmoinneilla tarkoitettiin toteutetun sovelluksen ja sen koodin tarkastamista aina määrätyin väliajoin. Yleensä katselmointia pidettiin viikkotapaamisten yhteydessä erityisesti silloin, kun sovellukseen oli saatu toteutettua merkittäviä lisäominaisuuksia.

Virallinen koodikatselmointi järjestettiin teknisen ohjaajan kanssa kaksi kertaa. Koodikatselmoinnin tarkoituksena oli kehittää sovelluksen koodia parempaan suuntaan asiantuntijan ohjaamana. Tässä projektissa erityisesti kommentoinnin taso parani koodikatselmoinnin jälkeen.

8.6 Versiointi

Versiointia käytettiin lähinnä dokumentoinnin yhteydessä. Kunkin dokumentin ensimmäinen versio oli 0.1 ja julkaisuversio 1.0. Näiden kahden ääripään väliin mahtui vaihteleva määrä erilaisia työversioita samasta dokumentista. Dokumentit lähetettiin ryhmän vastaavalle ohjaajalle kommentoitavaksi yleensä ensimmäisen kerran versoin 0.5 kohdalla. Vaatimusmäärittelyn ja projektisuunnitelman kohdalla iterointityö alkoi jo hieman aiemmin. Dokumentin versio 0.9 lähetettiin tilaajalle kommentoitavaksi ja allekirjoitettava versio oli 1.0.

Ryhmä ei kokenut dokumenttien työvaiheversiointia kovin hyödylliseksi, mutta sen sijaan työvaiheiden 0.9 ja 1.0 versioinnista oli hyötyä, koska ne olivat dokumentoinnin kannalta ehkäpä kriittisimmät työvaiheet.

9 Testaus

Projektin odotettua suuremmasta työmäärästä johtuen ryhmälle ei jäänyt aikaa erilliselle testaustyölle, jolloin testaamista jouduttiin tekemään muun työn ohessa. Tästä johtuen testaamista ei pystytty tekemään niin järjestelmällisesti ja suunnitellusti kuin alun perin ajateltiin. Omalta osaltaan testaamista vaikeutti myös sovelluksen valmistuminen toimintakuntoon vasta aivan projektin lopussa. Tällöin sovelluksen kaikkien komponenttien yhteiskäytön ja koko julkaisuprosessin läpiviennin perusteellinen testaaminen oli lähes mahdotonta.

Eri komponentteja testattiin niiden kehityksen ohessa, ja esimerkiksi OO:n ja XSLT-muunnoksien kehitystyö perustui osin kokeile kokeile ja opi -menetelmään. Tällaisessa tilanteessa testaamista tulee tehtyä jopa tahattomasti, kun komponentin kehittäjä joutuu testaamaan muutoksiensa toimintaa lähes jatkuvasti.

Testaamista sovittiin jatkettavan kesän aikana, kun sovellus otetaan koekäyttöön seuraavan vuoden opinto-oppaan koostamisprosessissa. Tekijäryhmä on lupautunut toimimaan koostamisprosessissa teknisenä tukena, sekä korjaaman ainakin pienellä työmäärällä ratkaistavia ongelmia.

Kesällä pidettävänä testijakson jälkeen oli tarkoitus pitää yhteinen palaveri koko projektiorganisaation kesken ja kartoittaa millaisia ongelmia testaamisessa havaittiin. Tämän jälkeen pohditaan miten havaitut ongelmat pystyttäisiin korjaamaan mahdollisimman mielekkäällä tavalla. Sovelluksen testaus jatkuu siis vielä projektin päättymisen jälkeenkin.

10 Kokemukset ja oppiminen

Projektin aikana ryhmä sai paljon uutta kokemusta ja tietoa projektityöskentelystä sekä ohjelmistoprojekteista. Kunkin jäsenen kohdalla kokemukset olivat hieman erilaisia henkilöiden aiemmasta projektikokemuksesta ja myös projektin aikaisista tehtävistä johtuen. Alla kukin projektinjäsen on kuvannut oppimistaan ja tuntemuksiaan projektin aikana.

10.1 Henkilökohtaiset kokemukset

Tapio Väärämäki

Sovellusprojektien alkaessa olin hieman epävarma projektin läpiviennin onnistumisesta omalta kohdaltani, koska työskentelin samanaikaisesti toisessa hankkeessa melko intensiivisesti. Vesa Korhosen kerrottua vastaavan tilanteen vallinneen myös monen muun henkilön kohdalla aiempina vuosina, rohkaistun ja päätin lähteä mukaan projekteihin. Asia oli huomioitu myös projektiryhmäämme valittaessa, koska pääsin samaan ryhmään kahden jo aiemmin tuntemani henkilön kanssa. Yleensä ennestään tutut henkilöt pyritään kuulemma sijoittamaan eri ryhmiin.

Omasin aiempaa kokemusta projektityöskentelystä jo ennen sovellusprojekteja oman työhistoriani kautta. Tästä johtuen päätin lähteä projektiin varsin avoimin mielin ja ryhtyä tekemään lähes mitä tahansa työtä, kunhan se on minulle edes hieman tuttua. Muut ryhmämme jäsenet Turo Lamminen, Tapio Honkonen ja Tuomas Räsänen eivät omanneet yhtä paljon kokemusta projektityöskentelystä kuin minä.

Roolitusta ja työnjakoa sovittaessa päätin toimia ns. normaalina työntekijänä, eli en edes tavoitellut projektipäällikön paikkaa. Valinnallani halusin tarjota muille paremman mahdollisuuden päästä tutustumaan projektipäällikön tehtäviin. Tässä projektissa se oli erinomaisesti mahdollista, koska projektin johtajalta ei edellytetty aiempaa kokemusta. Kokeneemmalla henkilöllä olisi ollut päällikön roolissa tietysti se etu, että ainakin projektin käynnistys olisi saattanut tapahtua nopeammin, jos päällikkönä on aiemmin projekteissa mukana ollut henkilö.

Projektin käynnistymisen jälkeen tehtäväkseni muodostui ennen kaikkea suunnittelu ja dokumentointi, muiden keskittyessä enemmän toteutukseen. Työnjako sopi minulle mainiosti, vaikka halusin osallistua tietysti myös itse ohjelmistotuotantoon jossakin vaiheessa projektia.

Dokumentointi oli omalta osaltaan varsin mielenkiintoista, mutta välillä myös melko tylsää työtä. Tästä johtuen pyrin projektin edetessä haalimaan itselleni yhä enemmän toteutukseen liittyviä työtehtäviä. Tämä oli välttämätöntä myös niiltäkin osin, ettei dokumentointityötä olisi millään riittänyt koko projektin ajalle. Koen dokumentointityön olleen varsin kehittävää ja hyödyllistä itseäni ajatellen, ja siitä on minulle luultavasti vielä paljon hyötyä tulevaisuudessa.

Eräs omaan toimenkuvaani olennaisesti kuulunut tehtävä oli suunnittelu. Olin mukana suunnittelemassa lähes jokaisen komponentin ja erityisesti hallintakäyttöliittymän ulkoasua ja toimintaa. Mielestäni ohjelmistokehityksessä on äärimmäisen tärkeää huomioida myös käyttäjän mielipide, ja tästä johtuen pyrin suunnittelemaan toteutusta aina mahdollisimman käyttäjäystävällisesti.

Toteutukseen osallistuin graafisen toteutuksen ja jossain määrin myös ohjelmoinnin osalta. Projektin muihin jäseniin verrattuna vähäisestä ohjelmointikokemuksestani johtuen varsinainen koodaaminen kannatti kuitenkin jättää muille projektin jäsenille, koska he pystyivät tekemään vastaavaa työtä huomattavasti nopeammin. Tein itse lähinnä pienempiä korjauksia ja osallistuin aina välillä ns. parikoodaukseen. Se osoittautui välillä jopa yllättävänkin tehokkaaksi työskentelytavaksi.

Eräs vastuualueeni oli loppu- ja väliesittelyiden esittelyaineiston laatiminen. Se oli mielestäni varsin mielenkiintoista työtä, koska pidän esiintymisestä sekä myös esityksien alustamisesta. Esitykset onnistuivat omasta mielestämme, sekä myös palautteen antajien mielestä, hyvin.

Projektityöskentelyn sovittaminen muuhun elämään ei ollut mitenkään vaikeata, ja siitä tuli varsin rutiininomaista noin puolentoista kuukauden työskentelyn jälkeen. Muista aktiviteeteistani johtuen jouduin työskentelemään melko paljon myös viikonloppuisin ja iltaisin. Tästä johtuen päivät ja usein myös viikot venyivät varsin pitkiksi, eikä vapaa-aika ollut aina läheskään niin paljon kuin olisi kaivannut. Hyvät projektikaverit ja ryhmän työmoraali kuitenkin kannustivat myös hieman raskaampina aikoina. Erityisesti Tuomas Räsäsen seura konttorilla myös viikonloppuisin on huomionarvoista.

Yleisarviona projektista voin todeta, että se opetti minulle paljon ohjelmistoprojektiin liittyviä asioita. Näin jälkeenpäin olen varsin iloinen, että lähdin projektiin mukaan, enkä yrittänyt siirtää tai korvata sitä muilla projekteilla. Laajan sovelluksen kehittyminen tyhjältä pöydältä valmiiksi sovellukseksi on mielenkiintoinen prosessi, ja ainakin minussa se sytytti jonkinasteisen kipinän olla mukana vastaavissa projekteissa myös jatkossakin. Sovellusprojektit ovat loistava osoitus siitä mihin opiskelijat pystyvät, kun heille annetaan riittävät puitteet ja sopivasti ohjausta.

Tuomas Räsänen

Aloitin sovellusprojektin hyvin innostuneena ja uteliaana. Positiivisiin

tunteisiin vaikutti halu päästä soveltamaan muilla kursseilla opittuja taitoja

käytännössä. Toki ohjelmointikursseilla oli jo päässyt näkemään konkreettisesti työn tuloksen, mutta sovellusprojekti tarjosi astetta suuremman leikkikentän. En omannut kurssin alkaessa kokemusta suuremman mittaluokan projektityöskentelystä ja tämäkin lisäsi motivaatiota entisestään. Ajattelin myös, että sovelllusprojektin suorittaminen antaisi enemmän valmiuksia saada kesätyöpaikka alan yrityksestä. Tämänkin sain huomata ilokseni kevään myötä.

Kurssi lähti käyntiin melkoisella vauhdilla. Ryhmät valittiin ja ryhmien sisällä

karkeat työnjaot ja tehtävät. Olin asennoitunut toimimaan kehitystehtävissä,

mutta myös tarpeen tullen projektipäällikön roolissa mikäli ryhmän muiden

jäsenten keskuudesta ei halukasta tehtävään olisi löytynyt. Työnjako kävi

ryhmällämme kuitenkin hyvin helposti.

Projektimme ei kuitenkaan käynnistynyt aivan yhtä vauhdikkaasti kuin kurssi. Alun kankeuteen vaikutti kohtuullisen suuri epäselvyys projektin tavoitteista ja vaatimuksista. Alussa olisi pitänyt olla huomattavasti enemmän

projektipalavereja tai ainakin epävirallisempia tapaamisia. Kun kahden viikon jälkeenkään ei ollut vielä aivan selvää tavoitetta, tajusimme että kiinniotettavaa on ainakin riittävästi. Alun epätietoisuuden ja hämmennyksen jälkeen pääsimme kuitenkin yskien liikkeelle ja projekti lähtikin kulkemaan varsin mallikkaasti oikeaan suuntaan.

Projektin edetessä tuli kokouskäytäntö oikein tutuksi. Itselläni ei ollut

juurikaan aikaisempaa kokemusta kokouksista, siispä hieman virallisemman kokouskaavan oppiminen tuli tarpeeseen. Pöytäkirjojen laatiminen kävi myös muiden käytänteiden ohella tutuksi. Näin jälkeenpäin ajatellen, ryhmämme olisi pitänyt laatia pöytäkirjoista vieläkin yksiselitteisempiä ja

yksityiskohtaisempia. Pöytäkirjathan toimivat ns. sopimuksina tilaajan ja

ryhmän välillä.

Toinen asia mikä selvisi minulle projektin edetessä, oli se ettei jokaiselta

ryhmän jäseneltä löytynyt aivan samanlaista panostusta projektia kohtaan. Tämä aiheutti projektin lopun lähestyessä hieman harmahtavia pilviä muuten varsin mallikkaasti toimineeseen ryhmähenkeen. Omaa työpanosta projektin loppuun saattamiseen suunnitellun aikataulun puitteissa lisäsi tieto pääsystä töihin alan yritykseen kesäkuun alussa. Samanarvoista sitoutumista on tosin hyvin vaikeata, jollei mahdotonta, saavuttaa tämän tyyppisissä opiskelijaprojekteissa.

Projektin lopun lähestyessä kävi jokaiselle ryhmän jäsenelle selväksi ettei

kaikkea suunniteltua kerittäisi toteuttamaan. Tämän asian sekä sen seurausten ymmärtäminen vei meiltä kuitenkin aikansa, eikä riittäviin toimenpiteisiin oivallettu ryhtyä tarpeeksi ajoissa. Mitään valtavaa ongelmaa tästä ei syntynyt, mutta viimeisien tehtävien suorittaminen venyi aivan tarpeettoman paljon.

Tästä syystä kuten usein muissakin vastaavissa projekteissa, sovelluksen testaus jäi valitettavan vähälle. Ajan riittämättömyyteen vaikutti moni tekijä, muun muassa:

-Laajamittainen projektityöskentely oli monille uutta.

-Toteutuksessa käytettävät tekniikat olivat osittain uusia.

-Alussa pitkään kestänyt epätietoisuus projektin tavoitteista.

-Projektin johdon kokemattomuus.

-Itse toteutuksessa arkkitehtuurin puute.

Mitä siis opin? Opin mielestäni paljon. Ensinnäkin itse projektityöskentelystä

sen miten tärkeää on laatia täysin yksiselitteiset vaatimusmäärittelyt.

Jälkeenpäin väärinkäsityksistä johtuneiden virheiden korjaaminen on usein

hidasta, mutta myös turhaa. Täysin onnistuneen projektin läpiviemiseksi

tarvitaan myös kokenut projektinjohto, jolla on kykyä reagoida ajoissa

yllättäviin tilanteisiin. Mielestäni ainakin tämän tyyppisissä projekteissä yksi

tärkeimmistä tehtävistä projektipäälliköllä on tarkkailla aikataulua ja sen

suhdetta nykytilanteeseen. Jos ja kun ongelmatilanteita syntyy, tulee niihin

pystyä myös vastaamaan oikein menetelmin. Projektipäällikön tehtävä on vaativa, mutta mielestäni yksi työkalu projektihallinnan helpottamiseen olisi erittäin tarkaksi hiottu aikataulusuunnitelma, jonka osatavoitteiden toteumista tarkastellaan sopivin lyhyin väliajoin. Toteutuksen puolella, varsinkin jos kehittäjät ovat hieman kokemattomampia, tarvitaan selvä sovellusarkkitehtuuri, jonka pohjalta tuotetta voidaan kehittää. Tämä vaatimus on hieman paradoksaalinen siinä mielessä, että kokemattomammat kehittäjät eivät tarvittavaa arkkitehtuuria pysty luomaan.

Omalla kohdallani havaitsin myös ongelmaksi liian kovan henkilökohtaisen vaatimustason. Alusta alkaen pyrin toteuttamaan asioita "liian täydellisesti", kun oikea menetelmä olisi ollut toteuttaa asiat "riittävän hyvin". Kun toteutetaan sovellusta aikataulun kanssa, ei ole väliä miten se on toteutettu, kunhan se vain toimii. Edellä mainittuihin oppeihini sain vielä varmistuksen havaittuani samoja ongelmia työkokemusta kerätessäni kaupallisen sektorin sovelluskehityksessä. Kokonaisuudessaan koin projektin erittäin opettavaisena oppimistapahtumana. Alun innostus ei siis laantunut, osa siitä vain vaihtoi muotoaan kokemukseksi.

Tapio Honkonen

Sovellusprojektin alkaessa yllätyin hieman siitä, että ryhmässäni oli jo ennestään tuttuja henkilöitä. Itse projektia odotin hiukan kauhulla, koska olin kuullut kuinka työläs se on. Ongelmana oli että tarvitsin aika lailla muitakin opintoja valmiiksi kevään aikana. Stressi oli aika kovanlainen.

Mitä aiempaan projektikokemukseen tuleen niin minulla ei sitä mitenkään paljoa ollut. Ainoastaan olin vetänyt muutamia projekteja ainejärjestötoiminnassa ja muutenkin koulumaailmassa. Rooliksini projektissa muodostui projektipäällikkö. Olin kiinnostunut tehtävästä ja muut eivät ilmaisseet isompaa halukkuutta siihen. Myöhemmin huomasin että tehtävä on yksi työläimmistä koko projektissa. Varsinkin kun ei ollut aiempaa kokemusta ja piti opetella kaikki siihen liittyvät tehtävät. Lisäksi toimenkuvaani kuului käyttöliittymän graafisen käyttöliittymän kehittäminen.

Sovellusprojektin aloitus ei oikein ole toimiva. Olisi hyvä varsinkin projektipäällikön näkökulmasta että oheiskurssi järjestettäisiin ennen varsinaisen projektin alkua, jolloin projektin käynnistäminen ei kestäisin niin kauan ja olisi paremmat valmiudet työskennellä asiakkaan kanssa. Lisäksi projektin suunnitteluun ja ylläpitoon liittyviä sovelluksia olisi hyvä kouluttaa ennen niiden käyttöönottoa. Aina yritys ja erehdys-taktiikka ei ole se tehokkain.

Yleisesti ottaen projekti on erittäin hyvä kokemus. Se antaa hyvät lähtökohdat työelämään ja kuvaa siitä millaista projektityöskentely oikeasti on. Lisäyksenä täytyy kyllä sanoa että prosessimallit olisi hyvä ottaa tehokkaammin käyttöön projektin toteutuksessa, koska ne tehostavat työskentelyä ja ne ovat oleellinen osa projektin toteutusta työelämässä. Valitettavasti projektimme jäi sen laajuuden ja vaatimusten epäselvyyden takia keskeneräiseksi. Olisi ollut mielenkiintoista nähdä sovellus täysin valmiina. Mutta yleiskuvaksi sovellusprojektista jäi mieluinen ja se osoittaa oikein hyvin kuinka paljon ja millaisia haasteita sovelluksen kehittäminen asettaa kehitystiimille. Tämä tietämys auttaa näkemään sovelluksien kehityksen uusin silmin.

Turo Lamminen

Projektin alkaessa minulla ei ollut lainkaan kokemusta isosta ohjelmistoprojektista. Tästä johtuen en edes tavoitellut projektipäällikön virkaa. Koska minulla oli paljon ohjelmointikokemusta, tehtävääni kuului enimmäkseen teknistä toteutusta mutta osallistuin jossakin määrin myös muihin tehtäviin.

Ensimmäisenä tehtävänäni oli tutustua projektissa käytettyyn DTD:hen ja OpenOfficen omaan tiedostomuotoon. Tämän jälkeen piti selvittää miten helposti niiden välillä voi tehdä muunnoksia käyttäen XSLT -kieltä. Minulla ei ollut juurikaan aiempaa kokemusta XML:stä eikä XSLT:stä, mutta Anne Honkarannan järjestämien pikakurssien jälkeen opin homman nopeasti ja sain muunnokset toimimaan mutta niiden saaminen täydellisiksi kesti melko pitkään. Itse käyttöliittymässä toteutin lähinnä XML:ään liittyvää toiminnallisuutta enkä puuttunut paljoa käyttöliittymän ulkoasuun.

Muuta opiskelua minulla oli projektin aikana melko vähän joten tein työtä vain harvoin iltaisin ja viikonloppuisin. Jatkoin kuitenkin kesän alussa töitä aina juhannukseen saakka koska muilla projektin jäsenillä oli kesällä rajoitetusti aikaa. Näin käyttöliittymän viimeistely jäi suurimmaksi osaksi minulle.

Koska minulla ei ollut aiempaa projektikokemusta, uusia asioita olivat mm. viikoittaiset palaverit, työskentely isommassa ryhmässä ja dokumentointi. Olin aiemmin tutustunut jonkin verran isojen ohjelmien kehittämiseen ja minulla oli paljon ohjelmointikokemusta joten ohjelmoinnista opin vain vähän uutta. Yleisarviona projekti oli mielenkiintoinen ja opettavainen kokemus josta on varmasti hyötyä myöhemmin.

11 Yhteenveto

Kokako-projekti toteutettiin 1.2.2006 – 17.10.2006 –välisenä aikana. Projektin päämääränä oli kehittää opinto-oppaan koostamis- ja sisällöntuotantotyökalu. Sovelluksesta oli tavoitteena kehittää niin yleiskäyttöinen, että sitä on mahdollista hyödyntää myös muuhun koostamistoimintaan. Projektin tilaajana toimi Jyväskylän yliopiston IT-tiedekunta ja Virtuaaliyliopisto. Toteutuksesta vastasi Kokako-ryhmä.

Kokako-projekti oli osalle ryhmän jäsenistä heidän ensimmäinen tämän kokoluokan projekti, jossa he ovat olleet mukana. Toisille projektityöskentely oli jo ennestään tuttua. Ryhmässä mukana olleet persoonat olivat muutenkin varsin erilaisia, mitä ryhmä itse piti arvokkaana kokemuksena. Kestoltaan hieman yli neljän kuukauden mittainen projekti opetti erityisesti yhteistyötä varsin tehokkaasti. Sen lisäksi ryhmä oppi paljon ohjelmistotuotantoon ja yleensäkin sovellusprojekteihin liittyviä asioita. Yliopistolla tarjottavista kursseista ryhmä pitää sovellusprojekteja eräänä parhaana ja mielenkiintoisimpana vaihtoehtona. Kurssi tarjoaa varsin hyvän pohjan työelämän vastaaviin projekteihin.

Lopputuloksia arvioitaessa voidaan sanoa projektin alussa asetettujen tavoitteiden toteutuneen vain osittain. Jälkikäteen ajateltuna tämä on kuitenkin varsin ymmärrettävää, kun ryhmällä tai tilaajalla ei ollut projektin alkuvaiheessa realistista käsitystä siitä, kuinka paljon eri työtehtävät tulevat vaatimaan aikaa. Osa tehtävistä vei suunniteltua vähemmän aikaa, mutta yleensä kävi juuri päinvastoin. Tästä johtuen projektia ja sen tavoitteita jouduttiin mukauttamaan työn edetessä. Lopputuloksena saatiin rajattu, mutta ainakin kohtuullisesti toimiva sovellus. Testaamista sovellukselle olisi pitänyt ehtiä tekemään huomattavasti nykyistä enemmän.

Kokonaisuutena Kokako-projekti onnistui ryhmän mielestä hyvin, joskin projektin päätös olisi voitu hoitaa tehokkaamminkin. Projektin jatkuminen kesäkuun alkupuolelle aiheutti selviä ongelmia, koska kolme neljästä ryhmänjäsenestä aloittivat kesätyöt kesäkuun alussa – yksi jo aiemmin. Ryhmä arvioi, että myös muilla ryhmillä on ollut osittain vastaavanlaisia ongelmia. Ratkaisuna voisi toimia kevään projektien aloittaminen jo tammikuun alkupuolella.

Kokako-projektin lopputuloksena syntyi opinto-oppaan koostamiseen ja sisällöntuotantoon kykenevä sovellus. Kehitystyö jäi joiltakin osin kesken, mutta sitä toivottavasti jatketaan kesän jälkeen mm. erikoistöiden muodossa. Kehitetyssä sovelluksessa on paljon potentiaalia, joka kannattaa pyrkiä hyödyntämään mahdollisimman tehokkaasti. Projektin jälkeinen kesä on varattu sovelluksen koekäyttöön. Tuolloin sovelluksella pyritään laatiman lukukauden 06-07 opinto-opas ja sen sisältö. Ryhmä jää mielenkiinnolla odottamaan, kuinka sovellus selviytyy tulikokeesta.

12 Viitteet

[1] Kokako-ryhmä, Kokako-vaatimusmäärittely v. 1.0, viitattu 23.6.2006.

[2] Kokako-ryhmä, Kokako-sovellusuunnitelma v. 1.0, viitattu 23.6.2006

[3] Kokako-ryhmä, Kokako-projektisuunnitelma v. 1.0, viitattu 23.6.2006

[4] Kokako-ryhmä, Kokako-sovellusraportti v. 1.0, viitattu 27.9.2006

Hyväksyjä	Päivämäärä	Allekirjoitus	Nimenselvennys
Projektipäällikkö	___.___.2006
Tilaaja	___.___.2006
Tilaaja	___.___.2006
Ohjaaja	___.___.2006

Versio	Päivämäärä	Muutokset	Tekijät
0.1	27.5.2006	Projektiraportin laatiminen aloitettiin.	Tapio Väärämäki
0.8	27.9.2006	Ajankäytön lisääminen	Tapio Väärämäki Tapio Honkonen
0.9	17.10.2006	Edelliseen versioon kommentoitujen muutosehdotuksien korjaaminen.	Tapio Väärämäki Tapio Honkonen