1 Johdanto

Koskikara-niminen tietotekniikan Sovellusprojekti jatkokehitti WWW-pohjaista kyselysovellusta Jyväskylän yliopiston käyttöön. Projektin puitteissa toteutettuja osia ovat kyselyiden haku ja vastausten analysointi.

Kyselysovellus on yksi Korppi-nimisen opintotietojärjestelmän sovelluksista. Järjestelmään ovat aiemmin toteuttaneet sovelluksia Kotka-, Korppi-, Halko-, Kottarainen-, Koppelo-, Kiuru- ja Kolibri-projektit. Niitä on edelleen jatkokehitetty Jyväskylän yliopiston tietotekniikan laitoksella.

Dokumentissa kuvataan Koskikara-projektin läpivientiä. Sovelluksen rakennetta ja toteutuksessa käytettyjä ratkaisuja esitellään Sovellusraportissa. Aiemmin laadittuja dokumentteja ovat Projektisuunnitelma, Sovellussuunnitelma ja Vaatimusmäärittely.

Luvussa 2 esitellään aiheeseen liittyviä käsitteitä. Projektin taustoja sekä tavoitteita ja niiden toteutumista kuvataan luvuissa 3 ja 4. Luvussa 5 kuvataan projektin organisaatio ja resurssit. Luvussa 6 käsitellään projektin tehtäviä ja niiden jakautumista projektin jäsenten kesken. Luvussa 7 kuvataan projektin toteutunut aikataulu ja verrataan sitä suunniteltuun. Luvussa 8 tarkastellaan projektiin liittyneiden riskitekijöiden toteutumista ja hallintaa. Luvussa 9 ryhmän jäsenet kertovat omista mietteistään projektin suhteen.

2 Termejä

Luvussa on selvennetty Koskikara-projektissa käytettävää termistöä. Koskikara-projektin aiheeseen ja Korppi-järjestelmään liittyviä termejä ovat seuraavat:

Analysointi on vastausten oleellisten havaintojen tiivistämistä pienemmäksi tulosjoukoksi.

Benchmarking on arviointitapa, jossa useampi organisaatio suorittaa matriisimuotoisen laadunarviointikyselyn ja vertailee saamiaan tuloksia keskenään.

Keskiarvo on havaintojen summa jaettuna havaintojen lukumäärällä.

Keskihajonta kuvaa havaintoarvojen keskimääräistä etäisyyttä keskiarvosta.

Kohde tarkoittaa kysymystä, kysymysryhmää tai kyselyä.

Korppi on Jyväskylän yliopistossa kehitetty opintotietojärjestelmä.

Kotka on Korppi-järjestelmän tietokanta ja henkilötietojen hallintaosio.

Kysely käsittää koko kyselyn ja voi koostua yhdestä tai useasta kysymysryhmästä.

Kyselypankki varastoi kyselyt julkisuusasteen mukaan kyselyjen analysointia ja uusien kyselyiden luontia varten.

Kyselytulokset ovat yksittäisen kyselyn tuottamaa dataa, johon luetaan vastaukset ja analysoinnin tuottamat raportit.

Kysymysryhmä käsittää yhden tai useampia loogisesti tai visuaalisesti samaan aihepiiriin liittyviä kysymyksiä.

Kysymystyyppi luokittelee kysymykset kyselyn luontivaiheessa kysymyksen esitysmuodon mukaan.

Maksimi on havaintoaineiston suurin arvo.

Mediaani on suuruusjärjestykseen asetettujen havaintoarvojen keskimmäinen arvo tai kaksi keskimmäistä, mikäli havaintoja on parillinen määrä.

Metatieto on kohteisiin liitettävää tarkoitusta, käyttömuotoa ja laatimista kuvaavaa lisätietoa, joka helpottaa kyselyitä haettaessa ja vastauksia analysoitaessa eri kohteiden liittämistä toisiinsa. Mahdollisia metatietoja ovat esimerkiksi kyselyn laatija ja laatimisajankohta.

Minimi on havaintoaineiston pienin arvo.

Moodi on havaintoaineiston todennäköisin arvo.

Raportti on vastauksia analysoimalla saatu tulosjoukko, johon sisältyy tekstiä ja graafeja.

Vastattava kysely on kysely, jonka voimassaoloaika ei ole vielä ohi.

Vastaustyyppi luokittelee kysymykset kyselyn analysointivaiheessa. Yleensä kysymystyyppi kiinnittää vastaustyypin.

Projektin toteutusympäristöön sekä käytettäviin työkaluihin ja tekniikoihin liittyviä termejä ovat seuraavat:

Bugzilla on WWW-pohjainen monipuolinen virheiden korjausten hallintajärjestelmä.

CSS eli Cascading Style Sheets on WWW-sivujen ulkoasua kuvaava kieli.

CSV (Comma Separated Values) on tiedon esitysmuoto, jossa eri muuttujien arvot erotetaan toisistaan pilkulla.

CVS (Concurrent Version System) on ohjelmistokehityksessä käytettävä versionhallintajärjestelmä.

Eväste (engl. cookie) on Netscapen luoma, mutta nykyään jo standardoitu menetelmä saada WWW-sivuista vuorovaikutteisempia. Palvelin lähettää pieniä tietopaketteja selaimelle, jonka perusteella käyttäjä asetuksineen tunnistetaan jatkossa.

HTML on WWW-sivujen sisältöä kuvaava kieli.

HTTP on WWW-arkkitehtuurin käyttämä tiedonsiirtoprotokolla.

Java on Sunin kehittämä laitteistoriippumaton olio-ohjelmointikieli.

Java-pavut (engl. JavaBeans) ovat Java-ohjelmointikielellä luotuja komponentteja, joita voidaan kutsua JSP-sivuilla.

JBuilder on ohjelmistonkehitystyökalu mm. Java- ja JSP-ohjelmointiin.

JDBC eli Java Database Connectivity on Java-teknologian käyttämä tietosilta erilaisiin tietokantoihin.

JSP eli Java Server Pages on skriptikieli, jossa HTML-koodin sekaan on mahdollista lisätä Java-koodia.

Palvelin on WWW-sovellusten tapauksessa ohjelmisto, joka palvelee asiakkaana toimivien selainten hakupyyntöjä.

Selain on ohjelma, joka käyttäjän koneella tulkkaa HTML-kieliset sivut kuvaruudulla esitettävään muotoon.

Servletti on palvelimella sijaitseva sovelma (engl. applet), joka toteuttaa HTTP-palvelimen pyynnöstä tietyn toiminnon.

Skripti on ohjelmointikieltä muistuttava ja usein hieman yksinkertaistettu tulkattava kieli.

Skriptaus tarkoittaa WWW-sivujen tapauksessa ohjelmakoodin kirjoittamista HTML-dokumenttien sisään. Palvelinpuolen skriptauksessa koodi ajetaan palvelinkoneessa ja asiakaspään skriptauksessa selaimessa.

SQL eli Structured Query Language on tietokantojen hallintaan kehitetty standardi kieli.

TomCat on ilmainen servletti- ja JSP-moottori.

XML on rakenteisten dokumenttien määrittely- ja kuvauskieli.

3 Projektin taustaa

Luvussa käsitellään projektin lähtökohtia sekä yliopiston ja sen eri alaorganisaatioiden tarpeita toteutettaville kyselysovelluksen haku- ja analysointitoiminnoille. Luku kuvaa myös Korppi-järjestelmän historiaa ja olemassaolevia sovelluksia.

3.1 Yliopiston tarpeita sovellukselle

Jyväskylän yliopistossa OPLAA! opetuksen laatuhankkeen ja virtuaaliyliopisto-hankkeen tavoitteena on luoda pysyviä rakenteita. Yksi tällainen rakenne on opetuksen jatkuvan arvioinnin mahdollistava järjestelmä. Arvioinnissa tarvittavan tiedon hankintaan, keräämiseen ja käsittelyyn tarvitaan WWW-selaimella toimiva kyselytiedon keruun ja hallinnan järjestelmä.

Laitoksilla on myös tarve saada kurssipalautteen analysointia helpommaksi ja nopeammaksi. Aiemmin esimerkiksi avoimella yliopistolla kukaan ei ole ehtinyt käydä läpi yli 18 000 opiskelijan palautetta. Siirtämällä palautteen antaminen WWW-ympäristöön saadaan perusanalyysien tekemistä automatisoitua. Samalla kerätty tieto saadaan koottua tietokantaan mahdollista myöhempää käsittelyä varten.

Yliopiston eri laitoksilla on muitakin tarpeita laatia lomakkeita ja koota tietoa verkon kautta. Tällaisia tarpeita ovat muun muassa erilaisiin tilaisuuksiin ja henkilöstön työtyytyväisyyteen liittyvät sekä erilaisissa tutkimuksissa käytettävät kyselyt.

Korppi-järjestelmässä oli olemassa Kottarainen-projektin kehittämä kyselysovellus. Sen tulokset olivat kuitenkin vaikeasti luettavissa ja vastausten analysointityökalu puuttui kokonaan. Myöskään kyselyiden haku- ja koostamistyökalua ei ollut olemassa. Nämä toiminnot Koskikara-projekti loi Korppi-järjestelmään.

3.2 Korppi-järjestelmä

Ensimmäinen Jyväskylän yliopistossa yleiseen käyttöön toteutettu WWW-pohjainen kurssikirjanpitosovellus, Kurki, toteutettiin matematiikan laitokselle tietotekniikan cum laude -työprojektina keväällä 1998. Sen tarkoituksena oli yhdenmukaistaa laitoksella käytetyt kurssikirjanpitojärjestelmät ja laajentaa niiden käytettävyys verkkoon. Kurki huomattiin ideana hyväksi ja sen käyttöä haluttiin laajentaa. Toisaalta sen kehitystyökalua ei enää tuettu ja käytettävyydessä oli puutteita, jonka vuoksi päätettiin aloittaa sen seuraajan toteuttaminen.

Uuden Korppi-nimisen opintotietojärjestelmän ensimmäinen kehittäjä oli syksyllä 2000 Kotka-niminen cum laude -työprojekti. Kotka-projekti määritteli uuden järjestelmän ominaisuudet, suunnitteli sille tietokannan, vertaili mahdollisia ohjelmistoja ja valitsi niistä järjestelmässä käytettävät sekä toteutti henkilötieto-osuuden.

Keväällä 2001 Korppi-projekti jatkoi järjestelmän kehitystä toteuttamalla järjestelmän kurssikirjanpito-osion. Samana keväänä Halko-projekti toteutti Heinolan kansalaisopistolle prototyypin opintotietojärjestelmästä. Näiden kyseisten projektien kesken tehtiin läheistä yhteistyötä.

Kolibri-projekti toteutti syksyllä 2001 WWW-pohjaisen päivyri- ja ajanvarausosion Korppi-järjestelmään. Koppelo-projekti kehitti keväällä 2002 WWW-pohjaisen opinnäytteiden hallintasovelluksen.

Kiuru toteutti syksyllä 2002 WWW-pohjaisen salivaraussovelluksen Korppi-järjestelmään. Projektin työhön sisältyi myös rajapinnan määrittely ja toteuttaminen ulkopuoliseen salivarausjärjestelmään salivarausten synkronointia varten.

Kottarainen-projekti toteutti keväällä 2003 järjestelmään monipuolisen kyselyjen luontityökalun. Tätä Korppi-järjestelmän sovellusta Koskikara-projekti jatkokehitti.

Lisätietoa Korppi-järjestelmästä ja Kotka-tietokannasta ja niiden dokumentaatiosta löytyy WWW:stä osoitteesta http://kotka.it.jyu.fi/.

4 Projektin tavoitteet ja niiden toteutuminen

Luvussa kuvataan projektin tavoitteiden toteutuminen sovelluksen ja jäsenten henkilökohtaisen oppimisen suhteen. Projektin tavoitteita kuvataan tarkemmin Projektisuunnitelmassa.

4.1 Toteutettu sovellus

Projekti toteutti kyselysovellukseen kyselypankin, kyselyn koostamisen sekä vastausten analysointityökalun. Vaatimusmäärittelyn mukaiset toiminnot saatiin tyydyttävästi toteutettua. Tuloksena oli toimiva sovellus, jolla pystyy tekemään hakuja kyselyihin ja koostamaan kyselyitä sekä vastauksia analysoimalla luomaan raportteja.

Kyselyn luoja pystyy sovelluksella analysoimaan vastaukset ja luomaan niiden pohjalta raportin. Analysoinnin aikana jokaiselle kysymykselle voidaan määrittää vastausten esitystavat ja valitsemaan tunnuslukujen tulostuminen. Jokaisesta kysymyksestä tulostetaan aina raporttiin frekvenssitaulukko.

Kyselypankilla käyttäjä voi hakea monipuolisesti tietokannasta kyselyyn liittyviä kysymysryhmiä ja kysymyksiä ja koostaa niistä haluamansa kyselyn. Sovelluksen toimintaa on tarkemmin kuvattu Sovellusraportissa.

Edellä mainitut sovelluksen toiminnot saatiin projektin puitteissa toteutettua toimiviksi. Projektin aikana sovelluksen käyttöliittymää muutettiin ja mukaan tuli lisää ominaisuuksia. Käyttöliittymä koki suuria muutoksia ja sen hiomiseen käytettiin liian paljon aikaa.

Sovelluksen toiminnoista projektin puitteissa ei ehditty toteuttamaan taustamuuttujan käyttöä analysoinnissa. Muut jatkokehitykseen sovitut sovelluksen osat on kuvattu tarkemmin sovellusraportissa.

4.2 Oppiminen

Projektin läpiviennin yhteydessä oli tavoitteena oppia ohjelmistoprojektin toimintatavat ja yleistä projektityöskentelyä. Nämä tavoitteet saavutettiin.

Yleiset projektissa käytetyt viestintä- ja kommunikaatiotavat tulivat tutuiksi jo hyvin aikaisessa vaiheessa projektia. Dokumenttien esitysmuodon oppiminen vei aikaa, ja dokumentit saivatkin palautetta vastaavalta ohjaajalta. Jokaisen toimiessa palavereissa puheenjohtajana ja sihteerinä vuorotellen tulivat yleiset kokous- ja asioiden kirjaamiskäytännöt tutuiksi.

Eniten oppimista tapahtui sovelluksen kehittämistyökaluihin tutustumisessa ja itse ohjelmakoodin kirjoittamisen yhteydessä, jossa noudatettiin Korppi-järjestelmän mukaista ohjelmointityyliä. Ilmeisesti tämä tavoite saavutettiin, koska valmis sovellus toimii Korppi-järjestelmän yhteydessä moitteettomasti.

Projektisuunnitelmassa ennakoidut riskit saatiin ratkaistua käyttämällä erilaisia viestintätapoja sekä jakamalla töitä tilanteen mukaan. Etenkin sähköpostilla saatiin ratkaisuja useisiin ongelmiin ohjelmiston kehittämisessä.

Projektisuunnitelmassa määritellyt oppimistavoitteet täyttyivät täten osittain.

5 Projektin resurssit ja organisaatio

Luvussa kuvataan projektin käytössä olleita resursseja sekä organisaatioon kuuluneet henkilöt ja heidän suhteensa projektiin.

5.1 Henkilöt ja yhteystiedot

Projektiryhmään kuuluivat tietotekniikan opiskelijat Ville Laitila, Pekka Moisio, Aapo Mäkinen ja Harri Pölkki. Sovelluksen tilaajia olivat yliopiston organisaatioista avoin yliopisto edustajanaan Eija Ihanainen, hallinto edustajanaan Mauno Väisänen, opetuksen laadun kehittämishanke OPLAA! edustajanaan Jari Rantamäki sekä virtuaaliyliopisto, jota edusti Antti Auer. Laitoksen vastaavana ohjaajana toimi Jukka-Pekka Santanen sekä teknisinä ohjaajina Teemu Vähä-Ruka ja Vesa Lappalainen. Projektin edetessä konsultoitiin Pekka Penttistä tilastotieteen kyselyjen tulosten esitystapojen osalta sekä Pauli Kujalaa JSP:n ja Kotka-tietokannan osalta.

Projektin dokumentaatio on luettavissa projektin kotisivuilla http://kotka.it.jyu.fi/koskikara/. Projektilla oli käytössä sähköpostilista koskikara@korppi.jyu.fi, jolle lähetettyihin viesteihin pääsee tutustumaan WWW-osoitteessa http://korppi.it.jyu.fi/list-archive/koskikara.

5.2 Laitteet ja ohjelmistot

Koskikara-projektin tarvitsemat resurssit tulivat tietotekniikan laitokselta.

Projektiryhmällä oli käytössään projektihuoneessa AgC222.2 kaksi Windows XP -työasemaa ja kolme RedHat 9 Linux -työasemaa.

Projektiryhmän mikroilla oli asennettuna työssä tarvittavat ohjelmistot. Tekstinkäsittelyä varten oli MS Word 2000 Windows-koneissa ja OpenOffice Linux-koneissa. Sovelluskehitysympäristönä toimi JBuilder Enterprisen versio 9. Kahdessa koneessa oli asennettuina Tomcat 4, Apache 2.0 ja PostgreSQL 7.3.2, sekä kopiot Kotka-tietokannasta ja Korppi-järjestelmän kehitysversiosta. Versionhallinnan työkaluina käytettiin CVS:ää sekä JBuilderin sisäänrakennettuja CVS-ominaisuuksia.

Laitteisiin saatiin kesken projektin lisää muistia 512 MB asti. Tämä lisäys auttoi nopeuttamaan ohjelmien toimintaa. Projektiryhmälle toimitettiin myös rannetuet sitä tarvitseville.

6 Projektin tehtävät ja niiden jakautuminen

Kokonaisuutena kaikki ryhmän jäsenet osallistuivat hieman eri painotuksin kaikkiin tehtäviin, joita olivat tiedonkeruu, vaatimusmäärittely, suunnittelu, toteutus ja dokumentointi. Näin kaikki saivat arvokasta kokemusta ohjelmistoprosessin vaiheista ja niihin sisältyvistä tehtävistä.

Liitteessä 1 on kuvattu ajankäytön jakautuminen tehtävittäin. Jakautuma on kuitenkin vain suuntaa-antava, sillä esimerkiksi käytännössä kaikki testaaminen merkittiin ajankäyttövihkoihin ohjelmoinnin yhteyteen.

6.1 Vaatimusmäärittely ja sovellussuunnitelma

Vaatimusmäärittelyn, sovellussuunnitelman ja projektisuunnitelman toteuttaminen alkoi ensimmäisen projektipalaverin jälkeen. Vaatimusmäärittely ja projektisuunnitelma saatiin ajoissa toteutettua.

Sovellussuunnitelma jäädytettiin projektipalaverissa 28.11.2003, koska sen valmistuminen oli viivästynyt huomattavasti ja toteutusratkaisut olivat tuolloin jo pääosin ohjelmakoodissa. Näin ollen sitä ei ollut järkevää enää jatkaa. Vaatimusmäärittelyä laativat Ville Laitila ja Pekka Moisio. Projektisuunnitelma oli projektipäällikkö Harri Pölkin vastuulla. Sovellussuunnitelma oli ryhmän kaikkien jäsenten vastuulla.

6.2 Toteutusvaihe

Kyselypankkia alkoivat toteuttamaan Aapo Mäkinen ja Harri Pölkki. Kyselypankki jakautuu pienempiin kokonaisuuksiin kyselyiden haun ja koostamisen sekä koostettujen kyselyiden tallentamisen osalta.

Pekka Moisio ja Ville Laitila toteuttivat kyselyiden analysointityökalun. Analysointityökaluun liittyivät vastausten analysointi, raportin koostaminen analyysista, graafien tuottaminen ja esikatselu.

Yksikkötestaus suoritettiin siten, että Harri testasi Aapon koodin ja päinvastoin. Pekka ja Ville testasivat toistensa koodit vastaavasti. Näin varmistettiin, että koodista löydettiin useimmat virheet. Ohjelmoija itse ei yleensä ole kykenevä testaamaan riittävän tarkasti koodiaan. Dokumentoinnista vastasi Pekka Moisio.

Suunnitteluvaiheen aikana jaetut tehtävät säilyivät pääasiallisesti suunnitelmaa vastaavina. Pieniä poikkeuksia aiheuttivat sairastumiset ja poissaolot. Pekka Moision ohjelmointi jäi vähäiseksi hänen keskittyessä toimimaan projektiryhmän dokumentoijana ja analyysityökalun käyttöliittymän ulkoasun suunnittelijana. Projektipalavereissa puheenjohtajuus vuorotteli projektiryhmän jäsenten kesken. Sihteerinä toimi pääsääntöisesti Pekka Moisio.

6.3 Projektipäällikön tehtävät

Koko projektin ajan projektipäällikkönä toimi Harri Pölkki. Ratkaisun perusteena oli projektin läpiviennin tehostuminen verrattuna vaihtuvaan projektipäällikköön.

Projektin alussa projektipäällikkö hoiti työnsä hyvin. Projektipäällikkö laati projektisuunnitelman, jakoi vastuualueet projektilaisille sekä laati aikataulun projektin läpiviennille. Hän oli ajantasalla projektin etenemisen, tehtävien ja ongelmien suhteen.

Projektipäällikön työ alkoi hiukan vaikeutua ohjelmointivaiheessa. Siinä vaiheessa projektipäällikön tehtävät jäivät vähemmälle huomiolle siten, että tiedotus projektiorganisaatiolle jäi liian vähäiseksi. Projekti kuitenkin eteni aikataulussaan hyvin.

Jälkeenpäin ajateltuna projektipäällikön olisi pitänyt keskittyä tarkemmin projektipäällikön tehtäviin. Nyt suuri osa hänen ajastaan kului ohjelmointiin ja itse projektin johtaminen jäi vähemmälle. Kuitenkin projekti saatiin ryhmän jäsenten mielestä melko hyvin vietyä läpi.

6.4 Dokumentointi

Projektin vaiheiden tulokset dokumentoitiin projektiryhmän toimesta huolellisesti. Pääasiallisesti dokumentoinnista vastasi Pekka Moisio. Dokumentoinnissa oli koko projektin ajan ongelmia kirjoitusasun osalta. Ongelmaa olisi pystytty pienentämään, jos ryhmän toiset jäsenet olisivat tarkastaneet kirjalliset tuotokset ennen tilaajien ja edustajille ja ohjaajille esittämistä.

Kaikki dokumentit laadittiin samalle dokumenttipohjalle, jolloin projektin dokumentaation laatiminen ja siihen tutustuminen oli helpompaa. Dokumenttien pohjana käytettiin muokattua Kottarainen-projektin dokumenttipohjaa. Dokumentit laadittiin MS Wordilla ja tallennettiin RTF-formaattiin.

Projektiryhmä dokumentoi koko projektin etenemisen ajan, mutta painopiste oli projektin loppupuolella. Silloin toteutettiin mm. sovelluksen käyttöohje, projektiraportti ja sovellusraportti.

Projektiryhmä asetti dokumentit nähtäväksi projektin kotisivulle. Kotisivulla dokumentit ovat saatavissa sekä HTML- että RTF-formaatissa osoitteessa. http://kotka.it.jyu.fi/koskikara/.

Dokumentoinnit toimitettiin Jukka-Pekka Santasen kommentoitaviksi ja dokumentit hyväksyttiin projektipalavereissa.

6.5 Toteutunut työmäärä

Taulukossa 1 on kuvattu projektiin käytetyt työtunnit kutakin projektin jäsentä kohden. Projektiryhmä käytti projektiin kokonaisuudessaan 1455,6 tuntia.

Työmäärien epälooginen jakautuminen tehtävien mukaan selittyy suurelta osin ryhmän jäsenten näkemyseroista käsitteiden suhteen. Esimerkiksi projektinhallinnasta on ollut jäsenillä erilaiset näkemykset. Työtuntien kirjaamisperiaatteista olisi kannattanut keskustella tarkemmin projektin alussa, jotta olisi saatu yhtenäisempi jakautuminen.

Ville

Pekka

Aapo

Harri

Yhteensä

Palaveri

51,4

38,3

64,7

25,2

179,5

Materiaaliin tutustuminen

3,0

1,0

19,5

14,3

37,8

Opetus

12,0

9,5

2,8

18,3

42,6

Projektinhallinta

5,9

10,5

43,9

15,4

75,7

Määrittely

37,3

17,8

0,0

1,5

76,5

Suunnittelu

9,5

64,8

10,0

18,3

102,5

Ohjelmointi

251,6

14,3

203,2

207,7

676,8

Testaus

8,3

5,5

0,0

11,1

24,8

Dokumentointi

31,2

210,1

46,8

65,3

353,3

Yhteensä (tuntia)

410,1

371,6

390,9

377,1

1569,6

Taulukko 1. Projektiin käytetyt tunnit.

7 Projektin aikataulu

Luvussa tarkastellaan projektin suunnitellun aikataulun toteutumista ja siihen vaikuttaneita asioita.

7.1 Toteutunut aikataulu

Suunnitelman mukaan projektin oli tarkoitus kestää 16 viikkoa. Projekti jaettiin suunnitellessa neljään pääosaan: määrittelyyn, toteutukseen sekä testaukseen ja dokumentointiin. Taulukossa 2 esitetään projektin eri tarkastuspisteiden suunniteltu ja toteutunut aikataulu. Liitteessä 2 kuvataan työnjakautuminen eri viikoille kultakin projektin jäsenen osalta.

Vaihe	Tulos	Toteutunut pvm.	Suunniteltu pvm.
Projektin aloitus	Päätös aloittamisesta	25.9.	25.9.
Määrittely	Vaatimusmäärittely ja projektisuunnitelma	28.10. (projektisuunn.) 23.10. (vaatimusmäär.)	19.10.
Suunnittelu	Sovellussuunnitelma	Jäädytettiin 25.11.	7.11.
Sovelluksen prototyyppi	Versio 0.1	27.11.	27.11.
Testaus		Alkoi 3.11., päättyi 15.1.	15.12.
Valmis sovellus	Valmis sovellus	15.1.	15.12.
Loppuraportointi	Projektiraportti, sovellusraportti	23.1.	8.1.

Taulukko 2: Projektin eri tarkastuspisteiden toteutuminen.

Kuvassa 1 on esitetty projektin päävaiheiden suunniteltu ja toteutunut aikataulu janakaaviona.

Kuva 1: Suunniteltu ja toteutunut aikataulu.

7.2 Aikataulumuutosten pohdintaa

Projektin aikataulu kuvassa 1 kertoo vaiheiden tarkkuudella projektin etenemisen. Alun aikataulussa pysymisen jälkeen projektin toteutus hidastui ja jäi hieman jälkeen aikataulusta.

Projektisuunnitelmaan laadittu aikataulu sai projektipalavereissa ehdotuksia tiivistämisestä, vaikka projektipäällikön mielestä se oli jo valmiiksikin tiukka. Projektipäällikkö laati kuitenkin uuden tiukemman aikataulun, joka kuitenkin osoittautui liian tiukaksi projektille. Olisi ollut syytä pysyä ensimmäisessä versiossa, eikä kuunnella liiaksi muun organisaation ehdotuksia. Näin projektin toteutunut aikataulu olisi vastannut tarkemmin suunniteltua.

Sovelluksen kehittämisessä ilmenneet ongelmat ja ohjelmointivaiheen yllättävän suuri työmäärä johtivat aikataulun pettämiseen.

Sovellussuunnitelman toteutus jäi kesken, koska sovellukseen oltiin jo ohjelmoitu sovellussuunnitelmaan kuuluvia osia. Sovellussuunnitelman viivästyminen osaltaan myöhästytti hiukan projektin myöhempiä vaiheita.

Projektin lopetus kuitenkin tapahtui lähes suunniteltujen aikataulujen mukaan. Toteuttamatta jääneet ominaisuudet sovittiin jatkokehitykseen. Tarkemmin jatkokehitykseen jääneistä ominaisuuksista kerrotaan sovellussuunnitelmassa.

8 Riskien toteutuminen ja hallinta

Luvussa kuvataan projektin arvioituja riskejä sekä niiden toteutumista, välttämistä ja hallintaa.

8.1 Eriävät näkemykset toteutettavasta järjestelmästä

Tilaajien epätietoisuus sovellukseen haluttavista ominaisuuksista aiheuttivat vaatimusmäärittelyä laadittaessa suuren määrän pohtimista. Toisaalta Lappalaisen Vesa Korppi-asiantuntijana auttoi sovelluksen määrittelyn tarkentamisessa tuomalla tietoa tekniikan rajoitteista joidenkin vaatimusten kohdalla.

Liiallinen suunnittelu ja dokumenttien ulkoasun korjaamiseen keskittyminen aiheutti itse ohjelmoinnin aloittamisen myöhästymisen.

Vaatimusmäärittelystä saimme kuitenkin hyvän pohjan sovellussuunnitelmalle ja ohjelmointivaiheelle. Ilman tarkkaa vaatimusten määritystä sovellus tuskin vastaisi kovinkaan tarkasti tilaajien toiveita. Joitakin vaatimusmäärittelyssä kuvattuja sovelluksen osia siirrettiin jatkokehitykseen toteutusajan puutteen vuoksi.

Sovellussuunnitelman toteuttaminen oli todella hankalaa, koska kaikkia vaatimuksia ei saatu ajoissa tietoon. Myöskään sovelluksen toteutustavat eivät olleet riittävän hyvin selvillä sovellussuunnitelmaa laadittaessa. Oikeat toteutustavat tulivat esille vasta ohjelmointivaiheessa. Toteutustapojen selvittäminen olisi vaatinut tietoa esim. vastaavista järjestelmistä. Tietoa ei kuitenkaan ollut saatavilla ja jouduimme miettimään järkevät toteutustavat itse.

8.2 Yhtenäisyys olemassaolevan järjestelmän kanssa

Yhtenäisyys kyselysovelluksen ja Korppi-järjestelmän kanssa oli eräs projektin suuria haasteita sovelluksen kehittämisen loppuvaiheissa. Ohjelmakoodia kirjoittaessa tuli huomioida Korppi-järjestelmän aiemmat toteutustavat ja -tekniikat sekä saada koodista mahdollisimman luettavaa ja ”Korppi-standardin” mukaista.

Kottarainen-projektin ohjelmakoodin luettavuus oli jokseenkin vaikeaa, koska se poikkeaa ”Korppi-standardista”. Kottarainen oli toteuttanut hankalasti ja jatkokehitystä ajattelematta useita sovelluksen osia, joita Koskikara-projektin kyselypankki olisi voinut käyttää sellaisinaan.

8.3 Ohjelmointi

Sovelluksen ohjelmointi aloitettiin projektisuunnitelman mukaisesti ja saatiin alun kehitystyökaluongelmien jälkeen alkuun hyvin. Projektiryhmän jäsenten aiemmat ohjelmointikokemukset auttoivat ohjelmoinnin etenemisessä. Prototyyppi valmistui ajoissa ja sen esittely tilaajille onnistui.

Ohjelmointiin aiheutti ongelmia Kottarainen-projektin toteuttaman sovelluksen epäselvä rakenne ja toiminnan ongelmat. Tämä vaikutti sovelluksen toteuttamisen viivästymiseen. Pääsyynä lopullisen sovelluksen valmistumisen viivästymiseen oli ennakoimattomat ongelmat graafien toteuttamisessa sekä kyselyn koostamiseen liittyvissä toteutusongelmissa.

Graafien piirtämisongelma johtui Java-ohjelmointikieleen toteutettujen piirto-ominaisuuksien toteutustavasta, joka ei soveltunut verkon yli käytettäväksi. Ongelmaa ei voinut ennakoida, koska se ei johtunut sovelluksen toiminnasta, vaan ulkopuolisesta tekijöistä. Tästä johtuivat myös loppuesittelyssä ilmenneet sovelluksen käyttöongelmat. Ongelma ratkaistiin käyttämällä WWW:stä löydettyä PJA-luokkakirjastoa. Luokkakirjaston käyttöönotossa oli aikaavieviä ongelmia, jotka saatiin ratkaistua atk-tuen avulla.

Ohjelman toteutuksen työmäärä oli huomattavasti suurempi kuin mitä projektisuunnitelmassa ja vaatimusmäärittelyssä oli ennakoitu. Myös jatkuvat käyttöliittymän muutokset tilaajilta ja teknisiltä ohjaajilta hidastivat hiukan ohjelmointivaiheen alkua.

8.4 Riskien vaikutus aikatauluun ja tavoitteisiin

Kuten luvussa 8.3 todettiin, suurin vaikutus aikatauluun oli ennakoimattomien ongelmien aiheuttamat myöhästymiset. Suurin osa näistä oli ulkopuolisen ongelman aiheuttamia myöhästymisiä.

Ennakoimattoman suuresta työmäärästä johtuen jouduttiin vaatimusmäärittelyssä olevia kohtia siirtämään jatkokehitykseen. Nämä jatkokehitykseen sovitut sovelluksen ominaisuudet ovat luettavissa Sovellusraportista.

9 Henkilökohtaiset kokemukset projektista

Luvussa projektin jäsenet kuvailevat henkilökohtaisia kokemuksiaan syksyn 2003 sovellusprojektista.

9.1 Ville Laitila

Sovellusprojektin omiin tavoitteisiini kuului ohjelmistotekniikan opiskelijana ohjelmistosuunnittelun ja ohjelmoinnin tekeminen. Projektityöskentely ja -työtavat olivat jo tuttuja aikaisemmista työtehtävistä. Lisäksi tavoitteena oli oppia erilaisia suunnittelumalleja ja suunnitteluperiaatteita sekä kehittää yhteistyökykyä. Päätavoitteena oli kuitenkin toimiva sovellus.

Toteutusvaihe venyi pitkäksi ja sinä aikana opin eniten. Pettymyksiäkin tuli vastaan, kun tekniikat eivät toimineetkaan yhteen. Hermoja rassasi saman ongelman kanssa taisteleminen päivästä toiseen. Apua kuitenkin löysin ja varsinainen työ pääsi jatkumaan.

Projektiryhmän työnjakoon olen hyvin tyytyväinen. Jokainen pääsi tekemään kunnolla töitä eikä ketään jätetty pulaan.

CVS:n käyttö oli aivan uutta ennen projektia ja sen opiskelu oli erittäin hyödyllistä tulevaisuutta varten. JSP-ohjelmointitaitokaan ei ollut kovin vankka ennen projektia. Java-ohjelmoinnissa ei mitään erityisen suurta tullut vastaa, mutta ainahan sitä kielestä jotain pientä uutta oppii. Ohjelmointivälineisiin en ole tyytyväinen. JBuilder jumittui Linux-ympäristössä päivittäin. Esimerkiksi ilmainen vapaan lähdekoodin kehitystyökalu Eclipse voisi toimia paljon paremmin sovellusprojektien Java-kehitysalustana.

Tärkein asia sovellusprojektissa oli yhteistyö. Sopivalla työnjaolla pystyimme toteuttamaan varsin laajan kokonaisuuden. Korppi-järjestelmä täydentyy projektin myötä 13 000 rivillä Java-koodia, 46 Java-luokalla ja 6 JSP-sivulla. Tämä on mielestäni hyvin suuri järjestelmä neljän opiskelijan toteuttamaksi neljän kuukauden sisällä.

Tietokantasuunnittelu vaati itseltäni opettelua enemmän kuin olisin osannut arvata. Minulla oli vain vähän kokemusta SQL:sta ja tietokannoista, koska en ollut ehtinyt suorittamaan mitään kurssia asiaan liittyen. Tässäkin asiassa voin kiittää muita jäseniä asioiden opettamisesta. Kottarainen-projektin toteuttama sovellus ja sen tietokantarakenne koettiin monimutkaisiksi ja sen tutkiminen pitkitti osaltaan projektin aikataulua ja työmäärää.

Vaatimusmäärittelyn rooli kehitystyössä oli ongelmallinen. Siinä sovitut asiat unohtuivat äkkiä ja sovellukseen suunniteltiin jo uusia toiminnallisuuksia. Kaikkia asioita ei tietysti voi kiinnittää vaatimusmäärittelyvaiheessa mutta silti pitäisi järki pitää mukana vaatimuksia määritettäessä ja niihin muutoksia ehdotettaessa.

Projektin aikana tuli opittua se, että mahdollisimman aikaisin pitäisi pyrkiä saamaan testattava versio tilaajan testattavaksi. Projektimme ongelmana oli osittain se, että ennakoimattomat tekniset vaikeudet viivästyttivät testattavan version valmiiksi saamista ja testauksen aloitusta. Onneksi koko sovelluksen testaus ei viivästynyt, vaan osia voitiin testata aikataulun mukaan.

Olen tyytyväinen projektissa mukana oloon, kokemuksiin ja siihen, mitä se on opettanut. Projektimme oli todella työläs ja vaativa. Tavoitteisiin kuitenkin päästiin.

9.2 Pekka Moisio

Projekti kuului pakollisena kurssina muuntokoulutustutkintooni. Kurssille hakeutuminen kuitenkin venyi johtuen omasta laiskuudestani ja projektin vaativuuden ansiosta.

Nyt oikeastaan projektin ollessa melkein viimeistelyä vaille ohi, harmittelen vain sitä, että en ottanut kurssia suoritettavaksi suoraan ohjelmointikurssien jälkeen. Tästä johtuen oli hieman hidasta ja vaikeaa alkaa vuoden tauon jälkeen kirjoittamaan ohjelmakoodia.

Lopulta ohjelmistolinjalle erikoistuneet ryhmän jäsenet ottivat vastuun sovelluksen kehittämisessä ja jättivät minun harteille dokumentoinnin ja eräät ulkoasulliset muutokset sovelluksessa. Tärkeimpänä tehtävänäni oli Korppi-järjestelmän CSS:ään tehdyt muutokset. Dokumentointi oli hyvin suuri osa-alue projektissa ja keskittämällä dokumenttien tuotanto saatiin aina tasalaatuisia dokumentteja.

Vaikka en jatkuvasti ohjelmoinut ja osallistunut kehittämiseen, tuli kuitenkin tutuksi ongelmat ja tavat, joilla sovellusta kehitettiin. Dokumentoinnista vastaavana henkilönä opin siitä paljon. Samalla tiedostin omat heikkoudet akateemisen tekstin kirjoittamisessa.

Aina projektin edetessä ei tiennyt, mihin panostaa resursseja. Täten arviot ja ennen koodausta määritellyt vaatimukset menivätkin joutuivat uudelleen tarkistettavaksi.

Projekti antoi hyvät pohjat projektityöskentelyyn, vaikka välillä ryhmän jäsenten hermot olivatkin kireällä ongelmien takia. Netistä löytyi mukavaa metallimusiikkia ohjelmoinnin vauhdittajaksi. Kuitenkin sain projektista enemmän, mitä olin luullut saavani. Etenkin saman ryhmän jäsenet saavat kiitosta hyvästä työilmapiiristä.

9.3 Aapo Mäkinen

Sovellusprojekti on kaikille tietotekniikkaa pääaineenaan opiskeleville pakollinen opintojakso. Oli tullut osaltani aika suorittaa projekti. Suuntautumisvaihtoehtoni on ohjelmistotekniikka, joten en odottanut projektin tuottavan itselleni paljoakaan vaikeuksia. Kun vielä olin varannut tarpeeksi aikaakin projektille.

Projektin alussa tuli ilmi että, ryhmämme tehtävä on jatkokehittää WWW-pohjaista kyselysovellusta. Aihe tuntui aluksi hieman vaikealta, koska minulla ei ollut paljoakaan kokemusta WWW-sovellusten kehittämisestä.

Projektin alussa tutustuin kehitysympäristöön ja kieleen melkein kuukauden verran. Tänä aikana en saanut paljoa muuta aikaiseksi, koska Harri, Pekka ja Ville huolehtivat projektisuunnitelman ja vaatimusmäärittelyn laatimisesta. Tutustumisesta ei ollut niin paljoa hyötyä kuin olin kuvitellut, mutta kyselysovelluksen tietokantaan tutustumisesta ja SQL-kielen kertaamisesta oli näin jälkikäteen ajatellen eniten hyötyä.

Tuntuu siltä että suunnitelmien laatimiseen ja hiomiseen kului ehkä liikaakin aikaa. Projektisuunnitelman hyödyllisyys toteutuneen projektin kannalta tuntuu mielestäni hieman kyseenalaiselta. Uskoisin ettei juuri kukaan ole lukenut tai koskenut projektisuunnitelmaan sen tultua hyväksytyksi. Ehkäpä tämä johtuu projektiorganisaation ja varsinaisen projektiryhmän pienuudesta ja siitä, että kaikki projektiryhmän jäsenet olivat entuudestaan tuttuja projektin läpivientikäytännön kanssa.

Kun vaatimusmäärittely rupesi saamaan sisältöä ja palavereissa oli tehty hahmotelmia mahdollisesta käyttöliittymästä, ryhdyin omatoimisesti suunnittelemaan HTML-kielellä JSP-sivujen mahdollisia ulkoasuja. Aikaa siihen kului 2-3 viikkoa. Suunnittelun ohessa jatkoin materiaaliin tutustumista. Sivujen ulkoasun suunnittelu herätti keskustelua projektipalavereissa, jonka jälkeen sivuja muokattiin tilaajien edustajien näkemysten mukaisiksi. Palavereissa ei oikein selkeästi ja ytimekkäästi saatu lyötyä lukkoon sivujen lopullista ulkoasua. Hakutyökalun osalta tuli ilmi lähinnä, miten hakua halutaan rajata. Kyselyn analyysi- ja raporttisivujen osalta voidaan todeta, että nyt toteutetut sivut eivät paljoa muistuta hahmottelemiani sivuja. Kaikki sivujen suunnitteluun käyttämäni aika ei välttämättä ollut loppujen lopuksi kovin tuottavaa.

Projektiaikataulun mukaan ohjelmointi aloitettiin suurin piirtein marraskuun toisella viikolla. Työnjaoksi oli sovittu minulle ja Harrille kyselypankin hakutoiminnot ja hakua käyttäen kyselyn koostaminen. Aloitimme työn ”pariohjelmointina” ja saimme aikaan muutaman luokan rungon. Vähän ajan päästä kuitenkin siirryimme työnjakoon, jossa Harri otti tehtäväkseen hakutyökalun JSP-sivujen tekemisen ja minä ryhdyin tekemään itse haun toteuttavaa Java-koodia. Javan kanssa menikin sitten koko loppuprojekti.

Minulla ei ollut paljon ideoita, kuinka toteuttaa haku järkevästi ja nopeasti. Tästä johtuen muutaman kerran meni useita päiviä vanhan koodin uudelleenkirjoittamiseen, jotta se taipui uusiin vaatimuksiin ja oli edes jollain tapaa järkevä. Yleensä ongelman tullessa vastaan tyydyin ensimmäiseen vastaan tulleeseen ratkaisuun paneutumatta paljoakaan siihen, kuinka tehokas tai järkevä se oli. Osaltaan tähän vaikutti myös projektin suhteellisen tiukka aikataulu. Ei aina ollut aikaa pohtia ja testata jokaista asiaa kunnolla.

Eräs lisätyötä aiheuttanut seikka oli se, että tilaajan edustajat eivät olleet saaneet kunnollista kuvaa hakutyökalusta vaatimusmäärittelyn yhteydessä. Yritin toteuttaa sovellusta, jonka toiminta ja ominaisuudet vastasivat vaatimusmäärittelyä. Kuitenkin vaatimusmäärittelyn kiinnittämisen jälkeen vielä projektipalavereissa haluttiin uusia ominaisuuksia tai muuttaa jo toteutettua toiminnallisuutta. Tämä valitettava lisätyö olisi voitu välttää, jos ominaisuudet ja haluttu toiminnallisuus olisivat olleet täysin tiedossa jo ennen koodaamiseen aloittamista. Aikaa kului koodin muuttamiseen niin, että se kykeni täyttämään nämä uudet vaatimukset. Tässä valossa vaatimusmäärittelyn hyöty jää kyseenalaiseksi. Kun määrittely on kerran kiinnitetty, ei sitä enää sen jälkeen pitäisi mennä muuttamaan.

Kuitenkin loppujen lopuksi arvioisin, että hakutyökalu ei varmaan työmäärältään (jos kaikki asiat määrittelystä ja suunnittelusta lähtien olisi tehty kunnolla) ole kovin suuri verrattuna analyysityökaluun. Hakutyökalu sellaisena kuin se nyt tällä hetkellä tätä kirjoittaessa on, lienee koko projektin toteuttaman sovelluksen toimivin osa. Nimittäin se on ollut käytettävissä kuukauden päivät, jonka jälkeen olen vain korjannut ja hionut sitä palautteen ja huomaamieni puutteiden ja virheiden perusteella.

Projektiorganisaatio on mielestäni toiminut kohtuullisesti. ATK-tuelta on useimmiten saatu vastaus ja ongelmat hoidettua kuluneen päivän aikana. Vastaava ohjaaja on ollut hyvin aktiivinen antamaan runsaasti palautetta, jonka huomioinen ja toteuttaminen on vienyt kosolti aikaa. Mutta toisaalta tällainen projekti laajuudessaan ja johtuen projektiryhmän kokemattomuudesta vaati paljon ohjausta ja palautetta, jotta tarvittava rutiini saavutetaan.

Projektin tekninen ohjaaja Teemu Vähä-Ruka auttoi aina apua kysyttäessä ja piti projektin alussa muutaman hyödyllisen perehdytystilaisuuden. Tiina Pöyhönen ei varsinaisesti kuulunut alunperin projektiorganisaatioon, mutta hänestä oli kuitenkin ehkä enemmän apua kuin Teemusta. Tiina oli jatkokehittämässä kyselysovellusta viereisessä projektihuoneessa ja oli usein paikalla, joten häneltä oli helppo mennä kysymään apua. Sen sijaan Teemun kanssa yleensä piti sopia tapaamisesta erikseen. Kun avunpyynnöt osoitti projektiorganisaation sähköpostilistalle, myös häneltä sai vastauksen nopeasti. Hän myös tiesi kertoa muiden Korppia kehittävien tekemistä muutoksista, jotka taas aiheuttivat meille mysteerisiä ongelmia aina, kun suoritettiin CVS-päähaarapäivitys. Tiinalle ja Teemulle suuret kiitokset heidän avustaan.

Tilaajien edustajat tuntuivat olevan jotenkin ”rutinoituneita” projektiin ja heillä oli hieman ”vaimea” mielenkiinto projektipalaverien ”muodollisiin” osiin, kuten dokumenttien läpikäyntiin. Sen sijaan itse sovelluksen liittyvissä asioissa he olivat varsin aktiivisia. Ideoita ja toivomuksia tuli paljon. Niillä oli kuitenkin joskus tapana olla ympäripyöreitä ja vaihdella eri palaverien välillä, jolloin kokonaiskuvan muodostaminen ja määrittelyn rakentaminen oli vaikeata.

Palavereissa yleensäkin keskustelu rönsyili aiheesta toiseen. Joskus saatettiin keskustella kymmeniä minuutteja aiheesta joka ei varsinaisesti koskettanut käsillä ollutta asiaa. Ilmeisesti tämä olisi vaatinut puheenjohtajina toimineilta projektiryhmän jäseniltä huomattavasti ohjailevampaa ja aktiivisempaa toimintaa. Kenties olisi ollut viisaampaa, jos jokaisen olisi pitänyt pyytää puheenvuoroa viittaamalla.

Vesa Lappalainen toimi sekä tilaajan edustajana että ”Korppi-asiantuntijana”. Hän yritti osaltaan selkeyttää muiden tilaajan edustajien näkemyksiä toteutusläheiseen suuntaan. Hän myös auttoi teknisen toteuttamisen tasolla kertoen, mitkä ratkaisut ovat tietokanta- ja kooditasolla hyväksyttäviä.

Projektin aikana järjestettiin erinäisiä perehdyttämistilaisuuksia ja luentoja. Projektin aloitus- ja projektiluennot olivat varsin hyödyllisiä, vaikka jokseenkin pitkiä ja tietomääriltään puuduttavia. Tekniset perehdytystilaisuudet CVS:stä ja BugZillasta olivat mielenkiintoisia ja hyödyllisiä, vaikka projektissamme emme koskaan käyttäneetkään BugZillaa. CVS sen sijaan oli välttämättömyys. Käyttöliittymäluennon hyödyllisyys sen sijaan on mielestäni kyseenalainen. Olen käynyt kurssin ”Graafiset käyttöliittymät”. Se käsitteli luennon aihealuetta varsin kattavasti, jolloin kaikki luennon asiat olivat entuudestaan tuttuja. Ehkäpä kyseinen luento tulisi suunnata pelkästään niille, jotka eivät ole käyneet kyseistä kurssia.

Kuten vastaava ohjaaja totesi loppuesittelyssä, olivat projektin palaverit hieman rönsyileviä ja tiedotuksessa oli joitain puutteita. Myös loppuvaiheessa projektin aikataulu oli liian tiukka aliarvioidun ohjelmoinnin kestoajan vuoksi. On myös otettava huomioon ne muutamat ennalta odottamattomat toteutusympäristöstä johtuvat tekijät, jotka aiheuttivat analyysityökalun työmäärän huomattavan kasvun. Mielestäni projekti loppujen lopuksi onnistui hyvin täyttäen sille asetetut tavoitteet. Tavoitteenahan oli toteuttaa prototyyppi, ei täyttä tuotantokelpoista versiota.

Omistauduin projektille sen vaatimalla tavalla, mutta kokemattomuus ja suunnittelun puute lisäsivät työmäärää huomattavasti. Projektin alussa työstäni ei ollut paljoa välitöntä hyötyä projektin etenemiselle.

9.4 Harri Pölkki

Sovellusprojektin alku on varmaan kaikille jännittävä tilanne. Useilla on edessään ensimmäinen laajempi sovelluskehitysprojekti. Näin oli myös minulla. Odotukset uusista asioista ja kavereista olivat korkeat.

Aivan projektin alkuvaiheessa aikaa meni projektin laajuuden sisäistämiseen. Hommaa olikin luvassa paljon odotettua enemmän. Ensimmäiset päivät projektihuoneessa menivät uusiin naamoihin tutustuessa. Meidän ryhmämme jäsenet olivat kaikki mukavia ja innostuneita. Minut valittiin projektipäälliköksi ja suostuin tietämättä sitä, mihin olen sitoutumassa. Aloinkin heti valinnan jälkeen selvittämään projektipäällikön tehtäviä ja vastuita.

Opastusta ja ohjausta tuli alkuvaiheessa hyvin ja melko kattavasti, mutta projektipäällikön näkökulmasta tätä aluetta olisi kannattanut ohjastaa enemmän. Olisin kaivannut enemmän tietoa projektinhallinnasta, vastuista ja tehtävistä, mutta ennen kaikkea painottaa tehtävän tärkeyttä menestyksekkään läpiviennin takaamiseksi.

Ohjelmointivaihe oli projektissa kaikkein työläin, odotetusti. Vaikeinta oli varmasti edeltäneen projektin tuotoksiin perehtyminen. Kaikki pääsivät hyvin tekniikoihin ja olemassaolevan sovelluksen toiminnallisuuteen sisälle. Onneksi ryhmässä oli yksi jäsen, jolla oli työkokemusta käytetyistä tekniikoista. Siitä oli ongelmatilanteissa usein hyötyä.

Oppimiskokemuksena tämä projekti on tarjonnut todella paljon. Olen saanut kokea melko laajan projektin läpiviennin ja tästä on varmasti hyötyä tulevaisuudessa. Uusia tekniikoita ja sovelluksia tuli opittua sekä laajaan WWW-sovellukseen osakokonaisuuden tekeminen oli arvokas kokemus.

10 Yhteenveto

Koskikara-sovellusprojekti jatkokehitti WWW-pohjaista kyselysovellusta Jyväskylän yliopiston käyttöön. Projektin puitteissa toteutuneita prototyypin osia olivat kyselyiden haku ja vastausten analysointi.

Sovelluksen valmistuminen myöhästyi suunnitellusta aikataulustaan noin neljä viikkoa. Projektin aikataulun myöhästyminen johtui pääosin sovelluksen kehittämiseen liittyvistä ennakoimattomista ongelmista. Sovellus ei täytä kaikkia sille alunperin asetettuja vaatimuksia.

Jatkokehitykseen sovittiin sovelluksen toteuttamatta jääneitä isompia kokonaisuuksia. Valmiilla sovelluksella pystyy kuitenkin koostamaan kyselyitä hakutyökalun avulla sekä analysoimaan vastauksia ja tuottamaan analysointityökalun avulla vastauksista graafeilla ja tunnusluvuilla varustettuja HTML-raportteja.

Projektin johtamiseen ja sen hallitsemiseen olisi pitänyt olla enemmän koulutusta. Sen sijaan keskityttiin liikaa tekniikoiden ja ohjelmointityökalujen opetukseen. Projektityöskentelyähän kurssilla kokonaisuudella piti opiskella.

Lähteet

Lintunen Sampsa, Pöyhönen Tiina, Vähä-Ruka Teemu ja Ylönen Timo, ”Kottarainen-projektin Projektiraportti”, Jyväskylän yliopisto, <URL: http://kotka.it.jyu.fi/kottarainen/dokumentit/viralliset/Projektiraportti.rtf>, tietotekniikan laitos, 2003.

Laitila Ville, Moisio Pekka, Mäkinen Aapo, Pölkki Harri, ”Koskikara-projektin projektisuunnitelma”, <URL:

http://kotka.it.jyu.fi/koskikara/projektisuunnitelma/Projektisuunnitelma.rtf>, Jyväskylän yliopisto, tietotekniikan laitos, 2003.

David M. Geary, ”Advanced JavaServer Pages”, Prentice Hall, 2001.

Lahtonen Tommi, “SQL ToolKit”, Docendo, 2002.

Mika Vesterholm. Jorma Kyppö, “Java-ohjelmointi Pro Training”, Satku, 2000.

Liitteet

Liite 1. Työmäärän jakautuminen tehtävittäin

Liitteessä on esitetty projektin työmäärän jakautuminen tehtävittäin. Määrissä on pientä epätarkkuutta, sillä ajat on otettu jäsenten ajankäyttöraporteista määrät on dokumenttiin otettu 7.1.2004 tilanteen mukaan.

Versio	Päiväys	Tehnyt	Muutokset
0.1	24.11.	Pekka Moisio	Dokumentti luotu
0.2	12.12.	Pekka Moisio	Sisältöä lisätty
0.3	15.12.	Pekka Moisio	Riskien hallinta ja aikataulut
0.4	17.12.	Pekka Moisio	Henkilökohtaiset kokemukset
0.5	30.12.	Pekka Moisio	Viimeistely ja virheiden korjaus.
0.6	3.1.	Pekka Moisio	Taulukoiden lisääminen.
0.7	7.1.	Pekka Moisio	Ajankäyttöliitteet.
0.8	8.1.	Pekka Moisio	Korjaus Santasen palautteen mukaan.
0.9	20.1.	Harri Pölkki	Korjaus Santasen palautteen mukaan.
1.0	26.1.	Ville Laitila	Korjaus Santasen palautteen mukaan.
1.01	27.1	Harri Pölkki	Korjaus Santasen palautteen mukaan.
1.02	29.1	Aapo Mäkinen	Korjaus Santasen palautteen mukaan.