1 Johdanto

URAANI-niminen Tietotekniikan cum laude -työprojekti toteutti kevään 2002 aikana Vainu-nimisen WWW-pohjaisen opintoneuvonta- ja urasuunnittelusovelluksen Jyväskylän yliopiston avoimelle yliopistolle. Sovelluksen taustalla oleva tietokanta pyrittiin toteuttamaan mahdollisimman joustavaksi. Tällöin uusia ominaisuuksia voidaan lisätä myöhemmin ja käyttöä voidaan laajentaa Jyväskylän yliopiston muiden laitosten tarpeisiin.

Tällä hetkellä Jyväskylän yliopiston avoimen yliopiston opintoneuvontapalvelu on ruuhkautunut. Pääasiallisena syynä on se, että opiskelijamäärä avoimessa yliopistossa kasvaa koko ajan. Perinteisellä tavalla, puhelimen välityksellä ja kasvokkain, tapahtuvan opintoneuvonnan rinnalle haluttiin saada WWW-pohjainen sovellus. Sovelluksen avulla saadaan opintoneuvontapalvelu tehokkaammaksi ja sen tavoitettavuus helpommaksi. Opiskelijat saavat yleisen opiskeluun tarvitsemansa tiedon verkon välityksellä ja avoimen (henkilökohtainen) opiskeluneuvonta voi keskittyä vaikeampien kysymysten tarkasteluun.

Vainu-järjestelmän tietokanta toteutettiin yhteensopiviksi KOTKA-järjestelmän tietokantarakenteen kanssa myöhemmin toteutettavaa tietokantojen yhdistämistä silmälläpitäen.

KOTKA-järjestelmän kehitti syksyn 2000 KOTKA-työprojekti. Se suunnitteli ja toteutti korvaavan järjestelmän Jyväskylän yliopiston tietotekniikan laitoksella käytössä olleelle KURKI-nimiselle kurssikirjanpitojärjestelmälle. KOTKA-projektiryhmä keskittyi lähinnä järjestelmän ominaisuuksien määrittelemiseen, ohjelmistojen ominaisuuksien kartoittamiseen ja vertailuun sekä tietokannan suunnitteluun. Tämän lisäksi syksyn 2000 ryhmä tuotti henkilötietojen hallintamoduulin prototyypin testaustarpeisiin ja malliksi seuraavalle ryhmälle. Työn laajuudesta johtuen työ jaettiin alusta lähtien useamman projektiryhmän kesken. Kevään 2001 KORPPI-projektiryhmän tehtävänä oli jatkaa kehitystyötä kurssikirjanpitomoduulin kehittämisen osalta. Järjestelmään kehittivät WWW-pohjaisen päivyriosion syksyn 2001 KOLIBRI-projektiryhmä. Kevään 2002 KOPPELO-projekti kehitti opinnäytteiden hallintasovelluksen osaksi KOTKA-järjestelmää.

Projektiraportissa kuvataan projektin toteutusta keskittyen itse projektiorganisaatioon, tehtäviin, tavoitteisiin ja aikatauluun sekä niiden toteutumiseen verrattuna alkuperäiseen projektisuunnitelmaan. Erillisessä sovellusraportissa käsitellään sovelluksen toteutusta ja verrataan sitä sovellussuunnitelmaan. Tietokantaraportissa käsitellään Vainu-sovelluksen omia tietokantaratkaisuja.

Luvussa 2 esitellään aiheeseen oleellisesti liittyviä käsitteitä. Luku 3 esittelee projektiorganisaation ja resurssit. Luvussa 4 kuvataan projektin tavoitteita ja niiden toteutumista. Luvussa 5 käsitellään projektin tehtäviä ja niiden jakautumista projektin jäsenten kesken. Luvussa 6 analysoidaan projektin toteutunutta aikataulua. Luku 7 esittää henkilökohtaiset kokemukset projektin kulusta ja kokemuksista.

2 Termejä

URAANI- projektiin keskeisesti liittyviä käsitteitä ovat seuraavat:

Apache on ilmainen HTTP-palvelinohjelmisto.

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

ER-kaavio on tietokannan rakennetta kuvaava kaavio (engl. Entity Relationship diagram).

GPL-lisenssi on ns. vapaa lisenssi, jonka mukaan ohjelman mukana tulee toimittaa sen lähdekoodi tai se tulee olla vapaasti saatavilla verkossa.

HTML on WWW-sivujen rakennetta ja ulkoasua 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.

JServ on ilmainen Java-servlettimoottori.

JSP (engl. Java Server Pages) on ohjelmointitekniikka. JSP-sivut sisältävät HTML-muotoiluelementtejä ja WWW-sivujen dynaamisuuden aikaansaavaa Java-kielistä skriptausta. Palvelin kääntää JSP-sivun servletiksi ja TomCat Java-skriptauksen selainohjelman ymmärtämäksi HTML:ksi.

KORPPI on kurssikirjanpitosovellus ja osa KOTKA-järjestelmää.

KOTKA on Jyväskylän yliopistossa käytössä oleva WWW-pohjainen opetuksen ja tutkimuksen hallintajärjestelmä.

Poolman on ohjelma, joka kontrolloi tietokantayhteyksiä.

PostgreSQL on ilmainen tietokannanhallintajärjestelmä.

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.

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

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

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

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

TomCat on ilmainen servletti- ja JSP-moottori.

Vainu-sovellukseen liittyvät seuraavat käsitteet:

Approbatur on perusopintokokonaisuus (15 ov).

Avoin yliopisto järjestää maksullista yliopistotasoista opetusta kaikille.

Avoimen yliopiston väylä on yksi tapa päästä yliopistoon tiettyjen opintokriteerien perusteella.

Chat on WWW-pohjainen reaaliaikainen keskustelualue.

Cum laude approbatur on aineopintokokonaisuus (35 ov).

Dynaaminen sivu on Vainu-sovelluksessa HTML-sivu, jonne tietoa haetaan tietokannasta käyttötapauskohtaisesti JSP-sivujen avulla.

FAQ on dokumentti usein esitettyjen kysymysten vastauksista.

Lokitieto on tietoa sivujen käyttöhistoriasta (tässä yhteydessä).

Opintokokonaisuus koostuu tietyistä opintojaksoista muodostaen esim. approbaturin, cum laude approbaturin tai laudaturin.

Staattinen sivu on normaali HTML-sivu, jonka selainohjelma tulkitsee aina samalla tavalla.

Tutkintovaatimus kertoo, mitä opintoja vaaditaan tietyn tutkinnon suorittamiseksi.

3 Projektin organisaatio ja resurssit

Kevään 2002 URAANI-projektin jäsenet olivat Teemu Lappalainen, Anu Valkonen, Mikko Vieru ja Markus Viklund. Tilaajatahon eli Avoimen yliopiston puolelta projektin vastuuhenkilöitä olivat Mervi Gröhn, Carita Haapanen, Tommi Lahtonen ja Minna Lehtonen. Mervi Gröhn, Carita Haapanen ja Minna Lehtonen vastasivat sisällön tuottamisesta. Projektin vastaavana ohjaajana toimi Jukka-Pekka Santanen ja teknisenä ohjaajana Markku Vire. Merja Ruuska toimi projektin visuaalisena konsulttina.

Projektiryhmä sai käyttöönsä huoneen AgC223.2 Agorasta, jonne asennettiin yksi Linux-palvelin, kaksi Red Hat Linux -työasemaa ja yksi Windows 2000 -työasema. Palvelimelle oli asennettuina HTTP-palvelinohjelmistoksi Apache 1.3.17, ohjelmointiympäristöksi Java 2 SDK Standard Edition, JSP-moottoriksi Tomcat 3.2.1, tietokannan hallintaohjelmistoksi PoolMan 1.4.1 ja tietokannanhallintaohjelmistoksi PostgreSQL 7.0.3. Ohjelmointityökaluna projektiryhmä käytti NetBeansin versiota 3.3.1.

Projektidokumentointi ja testattavat sovellukset ovat luettavissa projektin kotisivuilla URL-osoitteessa http://kotka.it.jyu.fi/uraani/. Projektilla oli käytössä sähköpostilista uraani@mit.jyu.fi.

4 Projektin tavoitteet ja niiden toteutuminen

Projektin tavoitteena oli toteuttaa prototyyppi WWW-pohjaisesta opintoneuvontasovelluksesta, jonka jatkokehitystä on helppo jatkaa. Projektiryhmä saikin toteutetuksi varsin valmiin sovelluksen, johon kaikki keskeisemmät ominaisuudet on toteutettu. Erillisessä sovellusraportissa kuvataan sovellukseen toteutetut toiminnot ja jatkokehitykseen siirretyt ominaisuudet.

Luvussa 4.1 kuvataan projektin tavoitteiden toteutumista. Luvussa 4.2 arvioidaan tavoitteiden toteutumista sovelluksen osalta sekä luvussa 4.3 kuvataan projektin aikana opittuja ja havaittuja asioita. Luvussa 4.4 tarkastellaan asioita, joita ryhmä nyt tekisi toisin.

4.1. Projektin tavoitteiden toteutuminen

Jokainen projektin jäsenistä oppi uutta JSP-tekniikasta, Java-ohjelmoinnista, tietokannan hallinnasta sekä NetBeans-ohjelmointityökalun käytöstä projektin kuluessa. Projektimuotoisesta työskentelystä jäi hyvä tunne, vaikka ryhmä huomasi, että parantamisen varaa projektityössä on vielä paljon.

Suunnitteluvaiheessa toiminnallisia vaatimuksia tuli lisää tilaajan edustajien taholta melkein joka palaverissa. Nämä vaatimukset pystyttiin huomioimaan tietokannan rakenteessa melko kivuttomasti. Ryhmä hahmotti sovelluksen sisällölliset vaatimukset melko nopeasti, mutta toteutusvaiheessa vaatimusten yksityiskohtien oikeanlaiseen hahmottamiseen ja toteutustapaan kului palavereissa jokunen tovi. Tämä saattoi johtua siitä, että kaikki ryhmän jäsenet eivät olleet riittävän hyvin tutustuneet avoimen yliopiston toimintaan niiltä osin, joita oltiin nyt muuttamassa WWW-pohjaisiksi. Ryhmän ohjelmointitaitoisille ohjelmointi oli niin tärkeää, etteivät he ajoittain osoittaneet riittävää kiinnostusta itse toteutettavaan aiheeseen. On kuitenkin tärkeää perehtyä sovellusalueeseen ohjelmoitaessa sovellusta reaalimaailman tarpeisiin.

Kaikki sovelluksen rakenteen ja ulkoasun linjaukseen liittyvät suunnittelutehtävät eivät olleet onneksi yksin työprojektilaisten työstettävinä. Avoimen yliopiston edustajat ja visuaalinen konsultti olivat voimakkaasti vaikuttamassa sovelluksen sivuston rakenteen ja käyttöliittymän ulkoasun muodostumiseen.

Projektiryhmän työskentelyä on hivenen hankala arvioida. Sellaista ei oikein syntynyt. Ryhmä oli nimittäin kokonaisuudessaan paikalla harvoin. Sähköpostilista ja Vainu-sovelluksen Ajankohtaista-palsta olivat ne paikat, joita seuraamalla saattoi selvitä, mitä ryhmässä oli tekeillä.

Ryhmän jäsenten välillä ei ollut ongelmia ja ryhmähenki oli hyvä. Yhteinen suunnittelu ja kommunikointi rajoittui suurimmalta osalta asioihin, jotka liittyivät ohjelmointiin. Kiinnostus sovelluksen suunnittelua kohtaan ennen ohjelmointivaiheen alkamista oli paljon vähäisempää. Sitä ei ainakaan suoritettu niin oma-aloitteisesti ja innokkaasti kuin ohjelmointitehtäviä.

Projektiryhmätyöskentely ei kehittynyt kevään aikana samalla tavalla sovelluksen kehittymiseen nähden. Liekö tämä johtunut siitä, että ohjaus keskittyi enemmänkin sovelluksen tilan seurantaan ja valvontaan kuin projektiryhmätyöskentelyn seurantaan. Ryhmätyöskentelyn sujumiseen tai sen kehittämiseen ei ollut lainkaan ohjausta ja valvontaa kevään aikana. Palavereissakin tämä valvonta keskittyi ajankäyttövihkojen tarkastukseen.

Kaiken kaikkiaan sovelluksen tekeminen edistyi ripeästi. Tilaajien, vastaavan ohjaajan ja ryhmän jäsenten palautteenanto alkoi jo toukokuun ensimmäisten viikkojen aikana, joten sovelluksen sisältämien virheiden ja puutteiden korjaamiseen käytettiin projektin loppuvaiheessa reilusti aikaa.

4.2. Sovellukselle asetettujen tavoitteiden toteutuminen

Sovelluksen tarkoituksena on auttaa opiskelijaa valitsemaan itselleen tarkoituksenmukaisia opintoja (opintojaksoja ja opintokokonaisuuksia) avoimen yliopiston opetustarjonnasta. Sen avulla käyttäjä voi selvittää, mihin ammatteihin jonkin aineen opinnot valmistavat. Tietoa on myös tiettyyn ammattiin vaadittavista ja suositeltavista opinnoista. Eri elämäntilanteissa oleville on tietoa opiskelumuodoista ja lisäkoulutusmahdollisuuksista. Avoimen väylän kriteereistä on myös tietoa.

Edellisessä kappaleessa mainitut ominaisuudet ja toiminnot on ryhmitelty sovelluksen sivuille omiin kohtiinsa. Tavoitteena tutkinto –osion sivut Mitä opiskella? ja Mihin valmistun?

ryhmä toteutti ensimmäisenä. Näiden sivujen toimintoja suunniteltiin ajallisesti kaikista eniten. Pääsivun Ajankohtaista-osio, Avoimen väylä -osion Väylävaatimukset-sivu sekä Keskustelu & palaute-kohdan Viesti Avoimelle -kohta olivat myös ensimmäisiä toteutettuja toimintoja.

Edellisessä kappaleessa mainitut osiot toteutettiin ensimmäiseksi, sillä niiden ajateltiin sisältävän eniten dynaamisuutta (tietokantakyselyjä). Nämä JSP-sivut sisältävät pääosin JSP-skriptausta. Osa sivuista sisältää pelkkää staattista tekstiä ja HTML-muotoiluelementtejä. Näille sivuille teksti haetaan tietokannasta JSP-sivuilla olevien teksti-elementtien avulla, sillä toteutusratkaisut mahdollistavat itsenäisten tekstielementtien lisäämisen JSP-sivuille. Niiden päivittäminen onnistuu ylläpitopuolen HTML-sivun muokkaustoiminnon avulla. Muut sovelluksen osiot selviävät erillisestä sovellusraportista.

Henkilökunnan ylläpitopuolen toimintoja alettiin ohjelmoimaan opiskelijan käyttöliittymän pääkohtien ohjelmointityön ja suunnittelun siinä vaiheessa, jolloin niiden avulla voitiin selkeästi hahmottaa, mitä toimintoja ylläpitopuolelle tarvitaan. Opinnot-osion sivun Oppiaineet, Opintokokonaisuudet ja Kurssit, Ammatit-kohdan Ammatti-sivu ja Kiinnostus-kohta olivat ensimmäisiä ylläpitopuolelle ohjelmoituja sivuja.

Toteutusvaihe sujui ryhmältä kivuttomasti, sillä ohjelmoinnissa ei juurikaan ollut ongelmia Jos ongelmia oli, niistä selvittiin itsenäisesti eteenpäin. Tilaajien toiveet ja toiveiden muutoksetkin pystyttiin toteuttamaan lähes aina.

4.3. Opittuja ja havaittuja asioita

URAANI-projektiryhmä koostui oman tiensä kulkijoista eli projektiryhmä oli harvoin paikalla kokonaisuudessaan. Kukin projektin jäsen kävi omana aikanaan tekemässä kiinnostuksensa mukaisia tehtäviä.

Sovelluksen toteutusratkaisuista ei liiemmin etukäteen keskusteltu, vaan kukin teki niitä näkemyksensä mukaisesti. Ratkaisuja päästiin siten yhdessä kommentoimaan vasta projektipalavereissa. Tästä syystä kaikilla projektin jäsenillä ei ehkä ajoittain ollut kokonaiskäsitystä projektin tilasta. Se oli jätetty projektipäällikön vastuulle. Hänen vastuulleen jäivät monet muutkin tehtävät, jotka kuuluivat yhdessä hoidettaviin tehtäviin. Tähän seikkaan varmasti vaikutti se, että kolme projektin jäsentä kävi projektin aikana töissä. Tämän vuoksi suurin osa ohjelmoinnista suoritettiin iltaisin.

Projektipäällikön roolin saanutta pidettiin projektipäällikkönä dokumentointiin liittyvän työnjaon suhteen, mutta muutoin hänen roolinsa tehtävässä oli lähinnä nimikkeellinen. Tehtävien vastuujako oltiin käsitetty siten, että muita töitä ei tarvitse tehdä kuin nuo nimetyt, projektipäällikön hoitaessa muut tehtävät.

Työprojektin alkuvaiheessa olisi dokumentointi- ja ohjelmointitehtävien jakautumisesta ryhmän jäsenten välillä pitänyt päättää tarkemmin. Ei nimittäin ole tarkoituksenmukaista, että yhden ryhmän jäsenen vastuulle jää kaikkien projektidokumenttien työstäminen. Jos työnjaon todella kuuluu tapahtua tuolla tavalla, antaa se aivan väärän kuvan työprojekteista, sillä kaikki opiskelijat eivät tuollaisessa tilanteessa pääse tekemään koulutustaan vastaavia tehtäviä. Dokumenttien kirjoittajallehan ei tuollaisessa tilanteessa jää aikaa varsinaiseen ohjelmointiin lainkaan.

Työprojektiohjeessa tulisikin tarkemmin ilmaista se, millainen rooli- ja tehtävänjako projektiryhmässä tulee tehdä tai tapahtuu ja mitä tuo jako käytännössä tarkoittaa. Erityisesti työprojektiohjeessa tulisi olla enemmän tietoa siitä, mitä käytännön asioita projektidokumenttien työstämiseen liittyy. Missä vaiheessa niiden kirjoittaminen on syytä aloittaa sekä miten ja kuinka usein niiden tarkistaminen ja palautteen anto tapahtuu? Myös suuntaa-antavat ohjeet siitä, miten projektiryhmän tulee organisoida projektidokumenttien kirjoittaminen, olisivat tarpeellisia. Niiden avulla ryhmän olisi helpompi suunnitella projektiaikataulua.

4.4. Mitä tekisimme toisin?

Jos nyt olisi mahdollista aloittaa projekti uudelleen, luvuissa 5 ja 4.1-4.3 mainitut tehtävät kiertäisivät ryhmän henkilöltä toiselle. Näin kaikki ryhmän jäsenet oppisivat hoitamaan ja ottamaan vastuuta kaikista projektin tehtävistä. Tietojärjestelmätieteen laitoksen projekteissa käytäntö on juuri tällainen.

URAANI-sähköpostilistan avulla kommunikointi sujui helposti. Sen avulla pystyi keskustelemaan ja informoimaan projektiin liittyvistä asioita laajalle ihmisjoukolle. Viestintä onnistui hyvin myös tahoille, jotka eivät fyysisesti osallistuneet projektin toteutukseen, vaan olivat taustajoukoissa edesauttamassa projektin läpivientiä.

Tiettyjen aihealueiden, kuten esimerkiksi VAINU-tietokannan yhteensopivuus ja yhdistäminen KOTKA-tietokantaan, tiimoilta eri osapuolet lähettivät viestejä aika paljon. Viestejä lähetettiin ajallisesti aihealueeseen liittyen monen päivän aikana. Kaikki eivät välttämättä lukeneet viestejä heti, joten kommentoinnit ja palaute edelliseen viestiin saatiin luettavaksi sähköpostilistalle viiveellä. Olisiko nopeampi ratkaisu ollut se, että kaikki osapuolet olisivat kokoontuneet palaveriin ja keskustelleet asian kerralla kuntoon? Nyt monella kului sähköpostiviestien kirjoittamiseen varmasti paljon aikaa. Niitä lähetettäessä asiat kun täytyy ilmaista laaja-alaisemmin kuin puhuttaessa. Pelkkää tekstiä lukiessaan lukija saattaa nimittäin ymmärtää asiat aivan väärällä tavalla, jos asiaa ei ole ilmaistu riittävän tarkasti. Lisäksi viestin lukija ei voi niin nopeasti ja perusteellisesti tarkistaa lukemastaan asiasta saamaansa käsityksen oikeellisuutta kuin verbaalisessa viestintätilanteessa.

Projektityöskentelystä päällimmäiseksi jäi se huomio, että sovelluksen ohjelmointi ja sen ominaisuuksien kehittäminen ovat projektin hallintatehtäviin verrattuna aivan erityyppisiä, omia tehtäväkokonaisuuksiaan.

Projektidokumenteissa tuli suunnitella ja raportoida erikseen projektia ja sovellusta. Näiden raporttien laatiminen jäi URAANI-projektissa yksinomaan projektipäällikön vastuulle. Kuitenkin edellisessä kappaleessa mainitusta syystä johtuen olisi hyvä erottaa näiden dokumenttien tekeminen eri henkilöille.

Projektin alkuvaiheessa olisi ollut aiheellista nimetä joku ryhmän jäsenistä vastaamaan sovelluskehitystyöstä (henkilö, jonka ohjelmointitaidot ovat ryhmän parhaimmasta päästä). Hänen tehtäviinsä olisivat kuuluneet sovellusdokumenttien työstäminen ja ohjelmointitehtävien koordinointi ja ohjelmointi. Näin projektipäällikön tehtävät olisivat vähentyneet ja useampi ryhmän jäsenistä olisi ollut vastuussa ryhmässä. Tällöin myös sovellussuunnitelma olisi vastannut enemmän ohjelmoijien tarpeita etenkin, kun projektipäällikkö ei tässä projektissa ohjelmoinut oikeastaan lainkaan. Näin sovellussuunnitelman laatiminen sulautuisi jouhevasti sovellusohjelmoinnin kanssa. Tällöin ohjelmoijat olisivat työstäneet sovellukseen tulevia ominaisuuksia jo ennen ohjelmointivaiheen alkamista. Tällöin aikaa ei kuluisi ohjelmointivaiheeseen siirryttäessä sovellusominaisuuksien miettimiseen (nyt ne luettiin sovellussuunnitelmasta). Helmikuussa useampi ryhmän jäsenistä olisi voinut laatia sovellussuunnitelmaa (URAANI-projektissa niitä laati pääosin yksi henkilö).

Projektipalaverit olivat usein ryhmän ainut yhteinen tapaaminen viikon aikana. Ennen kokouksia ryhmän olisi tullut kokoontua omaan palaveriin kuulemaan ryhmän eri jäsenten tekemisistä viikon aikana.

Etenkin suunnitteludokumenttien yhteinen läpikäyminen ennen ohjelmointivaiheen alkamista olisi ollut paikallaan. Palavereissa niitä käsiteltiin lähinnä tarkastus- ja hyväksymismielessä. Jos niitä olisi käsitelty palavereissa yksityiskohtaisemmin olisivat ne ajallisesti venyneet vielä pidemmiksi. Koko projektiryhmän yhteiset palaverit ovat tarkoitettu projektin etenemisen ja sovelluksen vaatimusmäärittelyyn ja sovelluksen kehityksen seurantaan. Näissä palaverissa ei kai ole järkevää käsitellä asioita, jotka eivät ole tilaajataholle tarpeellisia (toteutusratkaisujen tekninen toteutus esim. ohjelmointitekniikat ja -tavat). Ohjelmointitehtävien suunnitteluun, koordinointiin ja toteutukseen liittyen olisi pitänyt järjestää ryhmän neljän opiskelijajäsenen (sekä teknisen ohjaajan) yhteisiä, erillisiä palavereita. Nyt ohjelmointitehtävät toteutettiin aika hallitsemattomasti.

5 Projektin tehtävät ja niiden jakautuminen

Projektin alkuvaiheessa ryhmä tutustui KOTKA-järjestelmän tietokantaratkaisuihin. Vainu-sovelluksen tietokanta nimittäin kehitettiin yhteensopivaksi KOTKA-järjestelmän tietokannan kurssikirjanpito-osion kanssa. Vainu-sovelluksen toteutustekniikat olivat myös samat kuin KOTKA-järjestelmän. Kevään toisen työprojektin KOPPELOn kanssa tehtiin yhteistyötä tietokantaratkaisujen yhtenäistämiseksi.

Projektissa helmikuu kului vaatimusmäärittelyn ja suunnittelun merkeissä. Vaatimusmäärittelyn kohdalta voinee tiivistetysti sanoa, että ryhmä teki sitä yhdessä vain palavereissa. Dokumenttien laatijana toiminut Anu Valkonen joutui vastaamaan yksin vaatimusten analysoinnista sekä niiden työstämisestä muiden luettavaksi.

Alkuperäisen suunnitelman mukaan Teemu Lappalaisen vastuulla olivat tietokantaratkaisut ja SQL, jotka hän myös suoritti. Henkilökunnan ylläpitopuolen toteutusta ei aluksi määritelty kenenkään tehtäväksi. Koska JSP-ohjelmointi sujui ripeästi, hänen vastuulleen tuli myös ylläpitopuolen toteutus. Hän toteutti myös käyttöoikeuksien käsittelyn ja hallinnan. Muita hänen suorittamiaan tehtäviä olivat CSS-määritykset sekä tietokantaratkaisujen dokumentointi.

Alustavan suunnitelman mukaan Markus Viklundin vastuulle kuuluivat opiskelijapuolen käyttöliittymän toteutus ja CSS. Toteutusvaiheen aikana hän myös ohjelmoi opiskelijapuolen toimintoja. Lisäksi hän vastasi palaveripöytäkirjojen pääosan kirjoittamisesta.

Alkuperäisen suunnitelman mukaan Mikko Vierun vastuulla olivat JSP-sivujen ja Java-papujen toteutus. Hän ohjelmoi JDBC-pohjaisen (liittymärajapinnan) tietokantayhteyden Vainu-tietokantaan. Tämän tietokantayhteyden kautta suoritetaan SQL-kyselyjä tietokantaan. Hän ohjelmoi uuden käyttäjän luomiseen ja sisäänkirjautumiseen liittyvät toiminnot sekä istunnonhallinnan. Hän vastasi myös JSP-sivujen ja Java-papujen ohjelmakoodin kommentoinnista.

Anu Valkosen vastuulla olivat projektipäällikön toimet eli tiedotus, projektikansion hoitaminen, palaverien esityslistojen laatiminen sekä pääosin projektidokumenttien laatiminen ja kirjoittaminen. JSP-ohjelmointiin hän osallistui ajan käytön salliessa, sillä dokumenttien muokkaukseen kului yllättävän paljon aikaa. Dokumenttien tekeminen jäi täysin Anun vastuulle, sillä kukaan muu ei osoittanut kiinnostusta dokumenttien kirjoittamiseen. Lisäksi hän vastasi URAANI-työprojektin WWW-sivujen päivityksestä. Hän teki myös ensimmäisiä staattisia WWW-sivuhahmotelmia.

Merja Ruuskan tehtävänä projektissa oli suunnitella Vainu-sovelluksen ulkoasu. Hän toteutti Vainu-koiran ja -logon sekä päiväkirjakuvakkeen. Hän oli myös vaikuttamassa sovelluksen värimaailman muodostumiseen. Hän antoi myös kommentteja käyttöliittymän käytettävyydestä.

6 Projektin toteutunut aikataulu

Luvussa kuvataan toteutusvaiheittain aikataulua ja pohditaan sen toteutumista käytännössä. Luvussa 6.1. tarkastellaan toteutunutta aikataulua tarkistuspisteiden avulla. Luvussa 6.2. analysoidaan vaatimusmäärittely- ja suunnitteluvaiheen tapahtumia. Luvussa 6.3. analysoidaan järjestelmän toteutus- ja testausvaiheen tapahtumia.

6.1 Tarkistuspisteiden toteutuminen

Aikataulusuunnitelma on esitetty projektisuunnitelmassa. Taulukossa 1 kuvataan toteutunutta aikataulua tarkistuspisteiden avulla.

Toteutunut ajankohta	Suunniteltu ajankohta	Tarkistuspiste
23.1.		Kevään 2002 työprojektien aloitusluento.
31.1.	6.2.	Sovelluksen vaatimusmäärittely alkoi.
6.2.	6.2.	Tietokannan ja projektisuunnitelman laadinta alkoi.
7.2.		URAANI-projektin työhuoneen koneille on asennettu ohjelmia. URAANI-projektin WWW-sivut on laadittu.
20.2.	25.2.	Sivustokartan laadinta alkoi.
27.2.	20.2.	Sovellussuunnitelman työstäminen aloitettiin.
4.3.		guano.it.jyu.fi -koneeseen on asennettu ryhmän tarvitsemat ohjelmat.
8.3.		Ohjelmointi alkoi pienillä hauilla tietokantaan.
15.3.		1. opponointitilaisuus.
16.3.	18.3.	Toteutusvaihe alkaa laajamittaisesti. Merja Ruuska osallistui 1. kerran projektipalaveriin.
18.3.	18.3.	Tietokanta on toteutettu kokonaisuudessaan.
25.3.	10.4.	Henkilökunnan ylläpitosivuston toteutus alkoi.
25.3.		Ensimmäiset toimivat SQL-kyselyt tietokantaan on ohjelmoitu. Vainu-koira on toteutettu.
15.4.	8.3.	Projektisuunnitelma on hyväksytty.
18.4.	10.4.	Ensimmäinen testiversio on valmis.
29.4.		2. opponointitilaisuus.
2.5.		Pääsivun navigointipalkki on saanut lopulliseen muotonsa. Ensimmäinen materiaali avoimen opettajilta saadaan tietokantaan lisättäväksi.
6.5.		Tiedon syöttäminen tietokantaan alkoi laajamittaisesti.
7.5.		Vainu-sovelluksen testaaminen alkoi.
14.5.		Pidettiin projektien loppuesittelyt.
15.6.	15.5.	Vainu-sovellus on saatu URAANI-projektin osalta päätökseen.
1.7.	18.3.	Sovellussuunnitelma on hyväksytty.
30.8. 0.6.	20.5.	Sovellus dokumentteineen on hyväksytty.

Taulukko 1. Projektitehtävien tarkistuspisteet.

6.2 Vaatimusmäärittely ja suunnittelu

Projektin ensimmäinen palaveri pidettiin 23.1., jossa projekteihin osallistujat jaettiin projektiryhmiin ja he saivat sovellusten aihemääritykset. Vaatimusmäärittelyvaiheen voidaan katsoa alkaneen tästä ajankohdasta. Projektiorganisaation yhteinen vaatimusmäärittelyvaihe alkoi ensimmäisessä projektipalaverissa 31.1.. Vaatimusmäärittelyn päättymisajankohtaa ja suunnitteluvaiheen alkamisajankohtaa ei voi tarkkaan määrittää. Suunnitteluvaiheen voidaan katsoa alkaneen maaliskuun alussa, jolloin tehtiin ensimmäiset staattiset WWW-sivuhahmotelmat.

Aikaväli ensimmäisestä palaverista ensimmäisten JSP-sivujen ohjelmointiin 6.3. on vähän yli viisi viikkoa. Tänä aikana aloitettiin ensin projektisuunnitelman (helmikuun 1. viikolla) ja sitten sovellussuunnitelman kirjoittaminen vaatimusmäärittelyn pohjalta (maaliskuun 1. viikolla). Niiden molempien valmistumiset myöhästyivät yli kuukauden. Sovellussuunnitelman hyväksyminen myöhästyi peräti kolme ja puoli kuukautta. Helmikuun olisikin voinut käyttää paljon tehokkaammin näiden dokumenttien kirjoittamiseen. Tuona aikana myös suunniteltiin tietokantaa, mutta sen tekeminenhän on hyvin paljon sidoksissa sovellussuunnitelman laadinnan kanssa.

Ajankäyttöraporteista (katso projektikansion kohta 7) selviää kunkin projektilaisen ajankäyttö tuona aikana. Dokumenttien laadinta kuormitti liikaa yhtä ryhmän jäsentä. Muut ryhmän jäsenet taisivat tuona aikana vain odottaa ohjelmien asentamista koneille, jotta ohjelmointitehtävät voitaisiin aloittaa. Muillakin ryhmän jäsenillä olisi varmasti ollut aikaa dokumenttien työstämiseen. Oppimisen kannalta dokumenttien kirjoittaminen olisi ollut kaikille hyväksi.

Tilaajataho tiesi tarkkaan sen, mitä sovellukselta halusi, mutta ei sitä, kuinka heidän toiveet voidaan sovellukseen toteuttaa. Ensimmäisessä palaverissa Lahtonen kehotti ryhmää laatimaan WWW-sivuprotoja, joiden pohjalta sovelluksen työstäminen ja kehittäminen onnistuisi helpommin. Näiden demosivujen toteuttaminen päästiin aloittamaan kuitenkin vasta maaliskuussa. Syytä tähän on vaikea löytää. Vaatimusmäärittelyä laadittiin ja tarkennettiin kirjallisten dokumenttien avulla koko helmikuun ajan. Tuolloin olisi voinut vallan mainiosti tehdä staattisia sivuhahmotelmia. Kokiko jokin taho näiden tekemisen tietotekniikan ammattilaisilla nöyryyttävänä työnä? Tämä saattoi olla syynä siihen, ettei niitä alettu toteuttamaan aikaisemmin.

Tietokannan määrittäminen alkoi heti ensimmäisestä palaverista. Se saatiin muodostettua maaliskuun puoleenväliin mennessä. Sen rakenne eli kuitenkin projektin loppuun saakka, sillä pieniä muutoksia ja lisäyksiä tehtiin siihen koko ajan.

6.3. Järjestelmän toteutus ja testaus

Sovelluksen toteutusvaihe alkoi maaliskuun puolessa välissä. Ensin toteutettiin tärkeimpiä opiskelijapuolen toimintoja. JSP-ohjelmoinnin omaksuminen sujui vaivattomasti. Niinpä henkilökunnan ylläpitopuolen toteutus päätettiin aloittaa suunniteltua aikaisemmin. Opiskelijapuolen toimintoja suunniteltiin aluksi staattisten sivujen avulla. Henkilökunnan ylläpitosivut ohjelmoitiin heti (niitä ei suunniteltu staattisten sivujen avulla). Huhtikuussa Teemu Lappalainen keskittyi ainoana ylläpitosivujen tekemiseen. Markus Viklund ohjelmoi opiskelijapuolen toiminnallisuuksia.

Projektissa toukokuu oli määritelty alun perin testaamiseen ja dokumentointiin. Tässä tapauksessa testaaminen tarkoittaa sivujen toiminnallisuuden testausta, eikä ulkoasun muotoiluseikkojen muokkausta. Testaamiseen ei liiemmin tarvinnut käyttää aikaa, sillä ohjelmakoodin toimivuus testattiin heti ohjelmoinnin yhteydessä. Suurempia ohjelmointivirheitä ei havaittu. Tietokantakyselyjä optimoitiin niiden suorituksen nopeuttamiseksi. Suurin osa testausajasta käytettiin ulkoasun muokkaukseen pienien virheiden ja puutteiden poistamiseen vastaavalta ohjaajalta, tilaajan edustajilta ja visuaaliselta konsultilta tulleen palautteen pohjalta.

Ohjelmointivaihe jatkui koko toukokuun ajan. Se olisi kuitenkin pitänyt lopettaa kerralla tiettyyn päivämäärään mennessä. Aloittaessamme toukokuun toisella viikolla projektipalaverissa kartoittamaan ja priorisoimaan toteuttamattomia toimintoja, niitä ilmeni niin paljon, että ohjelmointia tehtiin vielä kesäkuun puolellakin.

Toukokuun toisella viikolla (ohjelmointi-) työ olisi pitänyt keskeyttää kerralla. Yleisestihän tiedettiin se, että olimme tekemässä prototyyppiä, jota tullaan jatkokehittämään kesän aikana. Sähköpostiviesteistä ilmenee, että projektipäällikkö lähetti viestin koskien projektin lopettamista. Viestin sisältö ymmärrettiin siten, että hän yrittää omavaltaisesti päättää ryhmän työskentelystä. Tällainen menettely on mielestäni oikein, sillä tilaajan edustajat eivät ehkä tienneet sitä, kuinka paljon loppudokumentointi vie aikaa (tämä aika on pois ohjelmointiajasta).

Vastaavalla ohjaajalla oli tässä asiassa kyllä varmaan omia intressejä, sillä hän ei missään vaiheessa ohjannut ryhmää selkeästi ohjelmointityön lopettamiseen ja dokumentointivaiheeseen siirtymiseen. Hän vain painotti, että tekemättömät toiminnot pitää projektissa priorisoida ja toteuttaa tilaajan toivomat ominaisuudet. Kuinka tilaaja voi tietää sitä, mitä ryhmä pystyy parissa päivässä tekemään? Ryhmä itse sen parhaiten tietää. Ohjelmointihaluja ryhmäläisillä oli vielä vaikka kuinka paljon, dokumentointihaluja ei läheskään niin paljoa.

Dokumentointi (kaikilla osa-alueilla) pääsi alkamaan edellä mainituista syistä vasta kesäkuun puolella ja jatkui elokuulle saakka. Itse sovellus saatiin hyväksytyksi kesäkuun puolessa välissä.

7 Henkilökohtaiset kokemukset

Luvussa projektilaiset esittävät omia kokemuksiaan projektista. Projektin läpivienti oli opettava kokemus kaikille projektilaisille.

7.1. Teemu Lappalainen

Jos olisin osallistunut työprojektiin aiemmin, olisin varmasti ollut aika epävarma oman pätevyyteni suhteen. Tähän kevääseen mennessä olin kuitenkin jo ehtinyt hankkimaan hieman työkokemustakin, joten suhtauduin asiaan huomattavasti luottavaisemmin. Etenkin aiheen saatuani olin varsin tyytyväinen ja luottavaisella tuulella, sillä olihan sovellusalue juuri sama, kuin mitä olen tottunut töissä tekemään eli tietokantapohjainen WWW-sovellus. Ainoastaan työkaluissa oli eroavaisuuksia, sillä JSP ja Java eivät olleet minulle juuri lainkaan tuttuja.

Kokonaisuutena projekti eteni mielestäni varsin onnistuneesti. Tyypillisesti alussa olimme hieman liian aikaansaamattomia, joka aiheutti loppua kohden kiirettä ja aikataulun venymistä. Toisaalta aikataulun venymiseen oli syynä myös sovelluksen prototyyppimäisyys. Ei nimittäin ollut selvää, mihin vetää raja tämän projektin ja jatkokehityksen välille.

Oppimisen ja tasapäisyyden kannalta olisi varmasti ollut parempi, jos olisimme jakaneet erilaisia työtehtäviä tasaisemmin. Nyt suurin osa dokumentoinnista kasautui osan harteille, ja vastaavasti muutama henkilö vastasi varsinaisesta toteutuspuolesta. Monessa suhteessa hommat vain etenivät luonnollisesti tällä tapaa. Esimerkiksi tietokantavastuu istui parhaiten minun harteilleni, koska olin niissä asioissa kokenein.

Olen lisäksi vakuuttunut siitä, että ilman tiettyihin tehtäviin erikoistumista emme varmasti olisi saaneet sovellusta näin valmiiksi. Näinhän hommat etenevät työelämässäkin. Joka paikan höyliä ei enää tiedon määrän kasvaessa ole, vaan erikoistuminen ja töiden jakaminen siltä pohjalta on välttämättömyys.

Kommunikoinnissa, kuten aina, olisi totta kai ollut parantamisenkin varaa, mutta kokonaisuutena ainakin itse pysyin riittävän hyvin ajan tasalla. Sähköpostin ohella sovelluksen oman Ajankohtaista-palstan käyttö ryhmän sisäiseen tiedottamiseen toimi mielestäni varsin hyvin, joskaan siitä ei otettu kaikkea hyötyä irti. Liian usein etusivulle tultaessa palstalla komeili minun kirjoitukseni. Eniten projektin onnistumiseen vaikuttanut tekijä lienee kahvinkeitin. Siitä kiitos asianomaisille ja muista syistä kaikille projektiin osallistuneille.

7.2. Anu Valkonen

Tammikuussa ennen työprojektien alkamista mielessäni oli monenlaisia ajatuksia työprojektin suhteen. Eniten mietin seuraavia asioita: miten projektiryhmätyöskentely tulisi sujumaan uusien ihmisten kanssa ja millaisen aiheen saa toteutettavakseen. Kun sitten projektiryhmät ja aiheet oli jaettu projektien aloitustilaisuudessa, oli suurin jännitys osaltani ohitse. Itse toteutettava aihealue ja sovelluksen tavoitteet olivat selvillä heti, sillä ne oli niin selvästi muotoiltu tehtäväantolappuseen.

Itse projektityöskentelyn suhteen minulla ei ollut minkäänlaisia ajatuksia. Näin jälkikäteen katsottuna, niitä olisi pitänyt olla hiukan enemmän. Ainakin olisi pitänyt tiettyjen asioiden suhteen olla paljon itsekkäämpi ja pitää puolensa enemmän. URAANI-työprojektissa sain projektipäällikön roolin. Ennen projektia käsityksenäni oli se, että ryhmän kaikki jäsenet ohjelmoivat, mutta totuus paljastui sitten projektin kuluessa.

Projektidokumenttien kirjoittamisesta muodostui niin iso urakka, että se vei yhden ihmisen ajan täysin. Huhtikuun alussa olin vielä projektisuunnitelman kimpussa, vaikka projekti oli siirtynyt jo toteutusvaiheeseen. Täytyy sanoa, että tipuin kelkasta jossain määrin tietokannan ja Gate-pavun toteutuksen aikoihin. Liekö johtunut siitä, etten ollut paikalla, kun niitä ohjelmoitiin. Toisaalta esim. tietokanta dokumentoitiin kunnolla vasta projektin loppudokumentaatioon. On projektiryhmän muita jäseniä kohtaan aika itsekästä se, ettei toteutusratkaisujaan millään tavalla ilmianna muille ryhmän jäsenille. Tuollainen menettelytapa hankaloittaa suotta ryhmän muiden jäsenten työskentelyä.

Itse toteutustekniikat, kuten JSP-tekniikka, Java-pavut sekä Java-kieli, olivat minulle entuudestaan tuttuja. Käytetty JSP-toteutustapa, tuotti aluksi vähän aikaa ongelmia, mutta totuin siihen lopulta. SQL-kieli oli entuudestaan tuttu, mutta sen käyttöä tietokannan toteutukseen liittyvässä ohjelmoinnissa en päässyt kokemaan, sillä sen toteuttaminen sujui niin itsenäisesti. Myös HTML- ja CSS-kielet olivat entuudestaan hallussa. Eniten tältä saralta opin CSS:stä esim. div-komennon käyttöä. Word- ja PowerPoint-työkalut olivat myös entuudestaan tuttuja. Rutiini niiden käytön suhteen tietenkin karttui.

Palaverikäytännöt olivat entuudestaan tutut, sillä olen aikaisemmin toiminut monen vuoden ajan urheiluseuran sihteerinä. Jokaisella yhteisöllä on kuitenkin omat tapansa toteuttaa asioita, joten opin uutta erityisesti siitä, kuinka erilaisten ihmisten kanssa työskennellään.

Kevään aikana kävin Yomi Oy:n järjestämän OMT++-kurssin ja kuten yksi vetäjä siellä sanoi, mikään ei ikinä suju niin kuin opetetaan. Kurssilla painotettiin sitä, kuinka tärkeää on suunnitella sovelluksen toiminnot ennen ohjelmointia. Tällöin vältytään lisätyöltä silloin, jos toteutusratkaisu ei olekaan toimiva. Itse olisin suunnitellut sovelluksen toimintoja tarkemmin etukäteen, mutta se taisi johtua siitä, etteivät ohjelmointitaitoni olleet ryhmän parhaimmat.

7.3. Markus Viklund

Minun osaltani työprojekti sujui uusia asioita ihmetellessä ja projektityöskentelytavan opettelussa. Projektin alussa projektipalavereiden perusteellinen dokumentointi osoittautui hyödylliseksi apukeinoksi pysyä edes jotenkuten kärryillä mm. siitä, mitkä Vainun ominaisuuksista oli lyöty lukkoon. Myös kaiken muun uuden asian hahmottaminen ehkä hieman helpottui, kun joutui tarkasti litteroimaan kokouksen kulun.

Alussa projekti lähti käyntiin hieman laiskanlaisesti. Ryhmämme ei ottanut tavakseen kokoontua säännöllisesti miettimään senhetkistä tilannetta, vaan kukin kävi projektihuoneessa puuhailemassa silloin, kun ehti. Tästä johtuen tiedonkulku ja vuorovaikutus projektin jäsenten välillä ei ollut kovin tehokasta ja ”know-how” ei juurikaan levinnyt ryhmässä. Ryhmässä oli siitä huolimatta hyvä henki. Työskentely oli kuitenkin tehokasta ajoittain, varsinkin silloin, kun oli pakko saada joku asia tehdyksi määräaikaan mennessä.

Työt jakaantuivat melko epätasaisesti projektin alun vastuualueiden jaosta huolimatta. Itselläni oli vastuualueena (projektisuunnitelman mukaan) HTML-koodi, tyylitiedostot ja käyttöliittymä. Käytännössä tein kuitenkin vähän kaikkea sieltä täältä omien kykyjeni mukaan ja vastasin siitä, minkä olin tehnyt. Projektin edetessä toteutusvaiheeseen tehtävät ja vastuualueet olivat muodostuneet itsestään sellaisiksi kuin ne olivat.

Projektin alkuvaiheessa järjestettiin koulutus- ja perehdyttämistilaisuuksia eri aiheisiin ja teknologioihin, mikä oli hyvä juttu.

Kaiken kaikkiaan työprojekti antoi varsin hyödyllistä käytännön kokemusta projektityöskentelystä, WWW-tietokantaohjelmoinnista sekä kokouskäytännöistä.

7.4. Mikko Vieru

Tammikuussa projektia alkaessa tiesin yliopiston työprojekteista vain sen, että ne tapaavat olla työläitä ja aikaa vaativia. Projekti alkoi rivakasti ja ensimmäinen kokous opetti minulle projektikokouskäytännön, joka oli minulle vieras asia entuudestaan. Aluksi puheenjohtajan ja sihteerin tehtävät kiersivät henkilöltä toiselle. Myöhemmissä kokouksissa palaverien sujuvuuden kannalta edellä mainitut tehtävät nimettiin henkilöille, jotka vastasivat niistä lopun projektin ajan.

Projektissa omaksi tehtäväkseni tuli vastata Java-ohjelmoinnista ja JSP-sivujen kirjoittamisesta. JSP-teknologia oli minulle uusi asia, joten jouduin opiskelemaan sen aivan alkeista. Asiaa kuitenkin helpotti se, että minulla oli jo jonkin verran kokemusta Java-ohjelmoinnista. Javaa käytetään Java-papujen ja JSP-sivujen toteuttamisessa, joka oli minulle entuudestaan tuttua työelämän kautta. Todellisuudessa suurin työ teknisen toteutuksen puolella jakautui kuitenkin kahden ihmisen kesken.

Huonoa tässä karkeassa tehtävien jaossa oli se, että kaikki ryhmän jäsenet eivät olleet aina perillä kaikesta, mitä tapahtui teknisellä puolella, varsinkin JSP-sivujen ja Java-papujen sisällössä. Itsekään en aina tiennyt täysin, mitä toinen JSP-sivuja päätoimenaan kirjoittava oli koodissaan aikonut tehdä.

Uusia asioita projektissa oli kokouskäytäntö ja JSP. Teknologioista SQL palautui mieleen hetken sitä pähkäiltyäni. Hyvää kokemusta sain projektityöskentelystä yleensä. Jokainen projektihan on aina erilainen, koska projektiryhmät vaihtelevat ja yhteistyö kaikkien ryhmän jäsenten kesken on edellytys hyvälle projektille. Mielestäni ryhmässämme oli hyvä henki koko projektin ajan. Myös projektille varatut tilat, projektihuone ja varsinkin projektin koneet olivat moitteettomat. Mikrotuki toimi hyvin ainakin meidän projektin osalta ja hyvää oli erityisesti projektiryhmille varattu ilmainen kahvi ja maito koko projektin ajan.

Huonona asiana voisin mainita miltei jokaiseen projektiin kuuluvan, mutta silti tässä yllättävästikin iskeneen kiireen. Muuta erityisen huonoa asiaa ei mieleeni tule ja kaiken kaikkiaan projektista jäi hyvä maku suuhun. Omalta osaltani Vainu-sovelluksen kanssa työskentely ei lopu vielä projektin päättyessä, vaan jatkan sovelluksen kehitystä yhteistyössä Avoimen yliopiston kanssa vielä kesällä.

8 Yhteenveto

Uraani-työprojekti toteutti Vainu-nimisen opintoneuvonta- ja urasuunnittelu sovelluksen Jyväskylän yliopiston avoimelle yliopistolle. Jo projektin alkuvaiheessa projektin tavoitteeksi määriteltiin prototyypin toteuttaminen, joten projektilaisten ei tarvinnut toteuttaa täysin valmista sovellusta. Projektiryhmä sai kevään aikana toteutettua tilaajien vaatimusten mukaisen prototyypin, jota jatkokehitysryhmän tulee kehittää ennen sovelluksen käyttöönottoa.

Itse sovelluksen toteutuminen sujui hyvin johtuen siitä, että ryhmässä oli kaksi alan ammattilaista. He hoitivat ohjelmointitehtävät erittäin itsenäisesti ja oma-aloitteisesti. Ilman heidän ammattitaitoaan Vainu-sovellus ei olisi kehittynyt niin pitkälle kuin se nyt kehittyi. Heidän tehtävänsä rajoittuivatkin sitten täysin tuohon ohjelmointiin. Ryhmän muut jäsenet hoitivat palavereiden esityslistojen laadinnan, sihteerin tehtävät ja palaveripöytäkirjojen kirjoittamisen. Projektityöskentelyssä ja projektin hallinnassa oli ajoittain ongelmia ja puutteita johtuen kaikkien ryhmän jäsenten asenteista erilaisten tehtävien suorittamista kohtaan ja heidän omista tavoitteistaan projektin suhteen.

Sovelluksen kaikki tärkeimmät ominaisuudet saatiin toteutettua kesäkuun puoleenväliin mennessä. Toukokuussa ohjelmointivaihe ei päättynyt tai sitä ei lopetettu missään vaiheessa. Toteutumattomien ja toteutettavien ominaisuuksien priorisointi aloitettiin liian myöhään. Ohjausta ohjelmoinnin lopettamiseen olisi pitänyt saada enemmän ja aikaisemmassa vaiheessa. Nyt ryhmä ohjelmoi vaadittavia ominaisuuksia vielä kesäkuussakin. Alunperinhän projektiajaksi oli määritelty tammikuun ja toukokuun välinen ajanjakso. Dokumentointivaiheen alkaminen viivästyi tästä syystä monella viikolla. Niinpä projekti jatkui vielä elokuulle asti ennen kuin se saatiin päätökseen.

Lähteet

Arnold Ken, James Gosling and David Holmes, “The Javaä Programming Language Third Edition”, Sun Microsystems, 2000.

Bloch Joshua, ”Effective Javaä Programming Language Guide”, Sun Microsystems, 2001.

Horppu Ismo, Mielityinen Markku ja Vire Markku, ”KOTKA-projektin projektikansio”, saatavilla HTML-muodossa <URL: http://kotka.it.jyu.fi/kotka>, Jyväskylän yliopisto, tietotekniikan laitos, 2000.

Lahtonen Tommi, ”SQL”, Docendo Finland Oy, 2002.

Lahtonen Tommi, ”Tietokannat 2000”, Jyväskylän yliopiston tietotekniikan laitos / avoin yliopisto 2000.

Lesonen Minna, Pekkanen Hannu, Tawast Tuukka ja Uuksulainen Heikki, ”KORPPI-projektin projektikansio”, saatavilla HTML-muodossa <URL:http://kotka.it.jyu.fi/korppi>, Jyväskylän yliopisto, tietotekniikan laitos, 2001.

Jaakkola Mia, Juutinen Sanna, Lupari Matti ja Nieminen Mikko, ”KOLIBRI-projektin projektikansio”, saatavilla HTML-muodossa <URL: http://kotka.it.jyu.fi/kolibri>, Jyväskylän Yliopisto, tietotekniikan laitos, 2002.

Santanen Jukka-Pekka, ''Tietotekniikan cum laude -harjoitustöiden ohje'', saatavilla HTML-muodossa

<URL: http://www.mit.jyu.fi/santanen/info/projohje.html>, Jyväskylän yliopisto, tietotekniikan laitos, 20.1.2002.

Lappalainen Teemu, Valkonen Anu, Vieru Mikko ja Viklund Markus, ”URAANI-projektin projektisuunnitelma”, Jyväskylän Yliopisto, tietotekniikan laitos, 2002.

Lappalainen Teemu, Valkonen Anu, Vieru Mikko ja Viklund Markus, ”URAANI-projektin sovellussuunnitelma”, Jyväskylän Yliopisto, tietotekniikan laitos, 2002.

Lappalainen Teemu, Valkonen Anu, Vieru Mikko ja Viklund Markus, ”URAANI-sovellusraportti”, Jyväskylän Yliopisto, tietotekniikan laitos, 2002.

Lappalainen Teemu, Valkonen Anu, Vieru Mikko ja Viklund Markus, ”URAANI-projektin tietokantaraportti”, Jyväskylän Yliopisto, tietotekniikan laitos, 2002.

Versio	Päiväys	Muutokset	Tehnyt
0.1	25.5.2002	- 1. versio.	Anu Valkonen
0.2	29.5.2002	- 2. versio.	Anu Valkonen
0.3	5.6.2002	- Lisätty projektin jäsenten projektiarviot.	Anu Valkonen
0.4	24.6.2002	- Muotoilu- ja kirjoitusvirheiden korjaus. Asiasisällön lisäystä. Lukujen rakenteen muokkausta.	Anu Valkonen
0.5	26.6.2002	- Asiasisällön lisäystä. Lukujen rakenteen muokkausta.	Anu Valkonen
0.6	1.7.2002	- Kielioppi-, asia- ja -muotoiluvirheiden korjausta. Tarkennuksia tiettyihin asioihin.	Anu Valkonen
0.7	12.7.2002	- Asiakokonaisuuksien lisäystä lukuihin 4, 5 ja 6.	Anu Valkonen
0.8	20.7.2002	- Lauserakenteiden muokkausta.	Anu Valkonen
0.9	29.7.2002	- Puuttuvien kokemusten lisäys.	Anu Valkonen
1.0	7.8.2002	- Kielioppi-, asia- ja muotoiluvirheiden korjausta.	Anu Valkonen