SHAMAN-projekti

Marko Andersson

Mika Rinkinen

Matti Törmä

Timo Valonen

Projektiraportti

16.6.2005

Versio 1.0

Tietoja projektista ja dokumentista

Tekijät:	Marko Andersson (maenande@cc.jyu.fi)

Mika Rinkinen (mikarin@cc.jyu.fi)

Matti Törmä (matorma@cc.jyu.fi)

Timo Valonen (tijovalo@cc.jyu.fi)

Yhteystiedot:	Postilista shaman@korppi.jyu.fi.

Postilistan arkisto

https://korppi.it.jyu.fi/list-	archive/shaman/.

WWW-sivu	http://sovellusprojektit.it.jyu.fi/shaman.

Työn nimi:	SHAMAN-projekti, projektiraportti

Työ:	Projektiraportti tietotekniikan sovellusprojektiin

Sivumäärä:	56

Tilaaja:	Jyväskylän yliopisto, ATK-keskus

Tiivistelmä:	SHAMAN-projekti määritteli ja suunnitteli keskitetystä	käyttäjähallinnasta vastaavan AMAN-järjestelmän seuraajan.	Projekti toteutti järjestelmän prototyyppiasteelle. Dokumentti	kuvaa projektin toteutuksen ja läpiviennin.

Avainsanat:	AMAN, tietokanta, käyttäjätunnus, salasana, käyttäjähallinta,	hallinta.

Versiohistoria

Versio	Päiväys	Tekijä	Kuvaus
0.510	10.5.2005	Marko Andersson	Dokumentin kirjoitus aloitettu. Luvut 3-6 ja 9.
0.516	16.5.2005	Marko Andersson	Luvut 6-8 ja 10.
0.517	17.5.2005	Marko Andersson	Luvut 7 ja 10.6.
0.519	19.5.2005	Marko Andersson	Luvut 1, 7, 10.1 ja liitteet.
0.523	23.5.2005	Marko Andersson	Luvut 1-12. Kirjoitusasun korjausta.
0.524	24.5.2005	Marko Andersson	Luku 9 lisätty.
0.525	25.5.2005	Marko Andersson	Luvut 7.2, 8.2 ja 13.
0.526	26.5.2005	Matti Törmä	Luku 12.2.
0.526	26.5.2005	Timo Valonen	Luku 12.4.
0.527	27.5.2005	Mika Rinkinen	Luku 12.3.
0.527	27.5.2005	Marko Andersson	Kirjoitusasun korjausta. Luvut 1-12.
0.530	30.5.2005	Timo Valonen	Pienet korjaukset luvuissa 9.4 ja 13.
0.601	1.6.2005	Timo Valonen	Pienet korjaukset luvuissa 7.2 ja 9.1.
1.0	16.6.2005	Timo Valonen	Julkaistu versio.

Termiluettelo

Projektin aiheeseen ja toteutustekniikoihin liittyviä termejä ja käsitteitä ovat seuraavat:

Acta	on Jyväskylän avoimessa yliopistossa käytössä oleva	opintosuoritusrekisteri.

Alaryhmät	ovat ryhmiä, jotka ovat tietyn ryhmän jäseniä.

Apache	on ilmainen HTTP-palvelinohjelmisto.

SHELL-skripti	on UNIX- ja Linux-koneissa ajettava komentorivitiedosto.

CSS	(Cascade Style Sheets) on WWW-sivujen ulkoasun	määrittelyyn käytetty kieli, jolla voidaan erottaa sivujen sisältö ja	esitysasu toisistaan.

Fortime	on rekisteri, jossa säilytetään tietoja henkilökunnasta ja muista	Jyväskylän yliopistolta palkkioita saavista.

FunetEduPerson	on skeema, joka määrittelee henkilöön liitettävät tietotyypit	korkeakoulujen välisessä viestinnässä.

HAKA	on Suomen yliopistojen ja ammattikorkeakoulujen yhteinen	käyttäjätunnistusjärjestelmä. Siihen liittyneen korkeakoulun	käyttäjät pääsevät yhdellä kirjautumisella korkeakoulusektorin	palveluihin riippumatta, siitä kuka palvelun tuottaa.

Henkilö	kuvaa henkilöä ja hänen tietojaan.

HTML-template	on Perlin moduuli, joka mahdollistaa skriptien erottamisen	HTML-sivusta.

JORE	on Jyväskylän yliopistossa kehitetty ja käytössä oleva	opintosuoritusrekisteri.

Kohdejärjestelmät	ovat järjestelmiä, joihin käyttäjähallintajärjestelmä vie tietoa.	Kohdejärjestelmiä käytetään rajapintojen kautta, ja niitä ovat mm.	Kerberos, LDAP ja CGI.

Korppi	on Jyväskylän yliopiston opintotietojärjestelmä.

Lähdejärjestelmät	ovat järjestelmiä, joista käyttäjähallintajärjestelmä saa tietonsa	käyttäjistä. Järjestelmät ovat Fortime, Jore, Acta ja Korppi sekä	salasana.jyu.fi.

Perl	on vapaan lähdekoodin skriptikieli, jolla voidaan toteuttaa myös	ajettavia ohjelmia.

PostgreSQL	on vapaan lähdekoodin tietokannanhallintajärjestelmä.

Ryhmä	on osana ryhmähierarkiaa ja siihen voi liittyä muita ryhmiä.	Ryhmä voi myös kuvata erilaisia rooleja. Tunnuskohtaiseen	ryhmään voi liittyä vain yksi tunnus.

Shibboleth	on organisaatiorajat ylittävä käyttäjien hallintaprotokolla, joka	tarjoaa autentikointi-, autorisointi- ja pääsynvalvontapalveluja.

Tunnukset	ovat henkilöiden käyttäjätunnuksia. Henkilöllä voi olla useampia	tunnuksia.

Yläryhmät	ovat tietyn ryhmän yläpuolella olevia ryhmiä, joiden jäsenenä	ryhmä on.

Sisältö

1 Johdanto	1

2 Projektin taustaa ja tavoitteet	3

2.1 AMAN ja yliopiston tietojärjestelmät	3

2.2 AMANin heikkouksia	5

3 Tavoitteiden toteutuminen	7

3.1 Tietokannan tavoitteet	7

3.2 Käyttöliittymän ja rajapintojen tavoitteet	8

3.3 Oppimistavoitteet	9

4 Projektin resurssit	11

4.1 Projektiorganisaatio	11

4.2 Työtila, laitteet ja ohjelmistot	12

5 Oheiskurssin koulutukset ja perehdytykset	13

5.1 Aloitusluento ja projektiluento	13

5.2 Perl-perehdytys	13

5.3 Eclipse-perehdytys	13

5.4 Projektipäälliköiden tapaamiset	14

5.5 CVS-versionhallinta	14

5.6 Tekijänoikeusluento	15

5.7 Ensimmäinen ja toinen väliesittely	15

5.8 Käytettävyyspäivä	15

5.9 Loppuesittely	16

6 Projektiin liittyvät perehdytykset ja tutustumiset	17

6.1 Tutustuminen Korpin ryhmärakenteeseen	17

6.2 Tutustuminen AMAN-järjestelmään	17

6.3 Perehdytys HTML::Template-moduulin käyttöön	17

7 Projektin tehtävät ja niiden jakautuminen	18

7.1 Vastuualuejako	18

7.2 Tehtävien työmäärä ja jakautuminen	19

7.3 Muutokset tehtäväjaossa ja työmäärissä	21

8 Projektin aikataulu	24

8.1 Vaiheet ja tulokset	24

8.2 Tehtävien aikataulu	26

8.3 Aikataulun muutokset	29

9 Projektin ajankäyttö	30

9.1 Koko ryhmä	30

9.2 Marko	32

9.3 Matti	34

9.4 Mika	36

9.5 Timo	38

10 Riskien arviointi ja hallinta	40

10.1 Riskitaulukko	40

10.2 Henkilöihin liittyvät riskit	41

10.3 Aihealueeseen liittyvät ja tekniset riskit	42

11 Projektin käytänteet	44

11.1 Dokumentointi	44

11.2 Kokoukset	44

11.3 Tiedottaminen	45

11.4 Tiedostot ja hakemistot	46

11.5 CVS-hakemistorakenne	47

11.6 Testaus	48

12 Projektin jäsenten kokemukset	49

12.1 Marko	49

12.2 Matti	50

12.3 Mika	51

12.4 Timo	52

13 Yhteenveto	54

Lähteet	55

Johdanto

SHAMAN-niminen tietotekniikan sovellusprojekti määritteli, suunnitteli ja osittain toteutti käyttäjätunnusten, salasanojen ja käyttöoikeuksien hallinnointiin käytettävän järjestelmän. Järjestelmä kehitettiin AMAN-nimisen järjestelmän korvaajaksi, joka ei enää vastaa sille asetettuja uusia vaatimuksia.

AMAN-järjestelmällä hallitaan Jyväskylän yliopiston opiskelijoiden, henkilökunnan ja muiden käyttäjien käyttäjätunnuksia ja salasanoja eri kohdejärjestelmissä. AMAN välittää käyttäjätunnukset ja salasanat eri autentikointipalvelimille, joista eri järjestelmät voivat autentikoida käyttäjän. AMAN saa tietonsa automaattisesti lähdejärjestelmistä, joita ovat mm. JORE, Fortime, Acta ja Korppi. AMAN-järjestelmän heikkoutena on tietokannan puutteellinen suunnittelu, joten tietokanta ei enää suoriudu uusista vaatimuksista. Käyttöliittymä on toteutettu skripteillä, joten sen ylläpitäminen ja muokkaaminen on hyvin hankalaa.

SHAMAN-projekti määritteli uudelle SHAMAN-järjestelmälle asetettavat tavoitteet ja vaatimukset nykyisten ja tulevien tarpeiden pohjalta. Projekti myös määritteli, suunnitteli ja toteutti tietokannan, joka vastaa uuden järjestelmän tarpeita. Ryhmä myös määritteli ja suunnitteli rajapinnat, joiden kautta järjestelmään voidaan syöttää tietoja eri lähdejärjestelmistä, sekä rajapinnat tietojen vientiin kohdejärjestelmiin.

Projektiraportissa tarkastellaan tavoitteiden ja aikataulun toteutumista projektisuunnitelmaan nähden. Myös tehtävien jakoa ja aikataulutusta verrataan suunnitelmaan nähden. Lisäksi dokumentissa kuvataan projektin taustoja, organisaatiota, resursseja ja käytänteitä.

Sovelluksen vaatimuksia ja käyttötapauksia on kuvattu SHAMAN-projektin vaatimusmäärittelyssä. Sovellusraportissa on kuvattu sovelluksen rakenne ja toiminta.

Luvussa 2 kuvataan projektin taustoja ja tavoitteita. Projektin tavoitteiden toteutumista käsitellään luvussa 3. Luvussa 4 kuvataan projektin organisaatiota ja resursseja. Luvussa 5 tarkastellaan oheiskurssin koulutuksia ja perehdytyksiä, sekä niiden vaikutusta projektiin. Luvussa 6 käsitellään projektiin liittyviä perehdytyksiä. Luvussa 7 tarkastellaan projektin tehtäviä ja niiden jakautumista sekä verrataan ajankäyttöä projektisuunnitelmassa esitettyihin arvioihin. Projektin toteutunutta aikataulua verrataan ja analysoidaan luvussa 8. Luvussa 9 tarkastellaan projektin ajankäytön jakautumista tehtävätyypeittäin ja viikoittain. Luku 10 tarkastelee projektin arvioitujen riskien toteutumista ja vaikutuksia projektiin. Luvussa 11 kuvataan projektin käytänteitä. Luku 12 sisältää projektin jäsenten henkilökohtaiset kokemukset projektista.

Projektin taustaa ja tavoitteet

Projekti määritteli ja suunnitteli sekä osaksi toteutti SHAMAN-järjestelmän, joka korvaa vanhan AMAN-järjestelmän. Uudessa järjestelmässä pyrittiin välttämään vanhan järjestelmän heikkouksia ja huonoja toteutustapoja, joita ovat esimerkiksi skripteinä käytetty ohjelmointikieli sekä käyttöliittymän upottaminen osaksi skriptejä. Vaatimukset ja toteutustekniikat kuvataan tarkemmin vaatimusmäärittelyssä ja sovellusraportissa.

AMAN ja yliopiston tietojärjestelmät

AMAN-järjestelmä on vuonna 2001 käyttöön otettu ATK-keskuksen käyttäjien ja käyttöoikeuksien hallintajärjestelmä, jonka päätehtävänä on ylläpitää Jyväskylän yliopiston eri tietojärjestelmien käyttöoikeuksia. AMAN on toteutettu Perl- ja SHELL-skripteillä sekä tiedot on tallennettu PostgreSQL-tietokannanhallintajärjestelmällä.

Kuva 1 esittää AMANille tietoja toimittavat lähdejärjestelmät sekä kohdejärjestelmät, joille AMAN välittää käyttöoikeustietoja.

Kuva 1. AMAN-järjestelmän yhteydet muihin järjestelmiin [Toivonen].

Kuvassa 2 on Jyväskylän yliopiston palvelimet, joiden kanssa AMAN-järjestelmä keskustelee.

Kuva 2. AMAN-järjestelmä on yhteydessä useisiin palvelimiin [Toivonen]. AMANin heikkouksia

Keskeisin tarve kehittää korvaaja AMAN-järjestelmälle on käyttäjien suuren vaihtuvuuden asettamat vaatimukset järjestelmän ylläpidettävyydelle. ATK-keskuksen järjestelmissä vuosittainen vaihtuvuus on n. 2000 henkilöä. Sama henkilö voi esiintyä eri järjestelmissä eri rooleissa, joita ovat mm. opiskelija tai henkilökuntaan kuuluva. Yliopistolla on käytössä useita tietojärjestelmiä, joissa kussakin on erillinen käyttäjien autentikointi.

AMAN-järjestelmässä tuki saman henkilön eri rooleille eri organisaatioissa ja eri järjestelmissä on puutteellinen, sillä nykyiseen järjestelmään ei ole sisällytetty ryhmäkäsitteitä. AMANin ryhmät perustuvat UNIX-järjestelmästä perittyihin ryhmiin. Nykyinen käyttöoikeuksien hallintajärjestelmä soveltuu huonosti erityisesti avoimen yliopiston opiskelijoiden sekä yliopistolla väliaikaisesti kirjoilla olevien opiskelijoiden ja henkilökuntaan kuuluvien käyttöoikeuksien hallintaan. Käyttäjätunnusta luotaessa sille ei nimittäin voida määrittää voimassaoloaikaa AMAN-järjestelmässä. Tämä hankaloittaa varsinkin kurssikohtaisia oikeuksien hallintaa, jolloin oikeudet on lisättävä ja poistettava käsin.

Merkittävä heikkous AMAN-järjestelmässä on käyttöliittymä, jonka ulkoasun muokkaaminen vaatii ohjelmointitietämystä. Käyttöliittymä on koodattu osaksi Perl-koodia, jolloin sen muuttaminen on äärimmäisen hankalaa ja aikaa vievää. AMAN-järjestelmä muodostuu noin 50 skriptistä.

Järjestelmää on laajennettu kasvavien vaatimusten ja tarpeiden mukaisesti sen sijaan, että järjestelmä olisi alusta alkaen suunniteltu tukemaan yliopiston tietojärjestelmien keskitettyä käyttäjähallintaa. AMAN-järjestelmää ei ole siten mieltä enää kehittää, vaan järjestelmä on toteutettava kokonaan uusiksi.

Tavoitteiden toteutuminen

Luvussa tarkastellaan projektille asetettujen tavoitteiden toteutumista ja projektin ulkopuolelle sovittuja SHAMAN-järjestelmän ominaisuuksia.

Ryhmä keskittyi uuden järjestelmän määrittelyyn ja suunnitteluun. Se onnistui varsin hyvin tietokannan ja järjestelmän hallintamoduulien määrittelyssä ja suunnittelussa. Koska projektin aika oli hyvin rajallinen, järjestelmästä toteutettiin vain tietokannan hallintamoduulit, sekä prototyyppiasteelle kehitetty käyttöliittymä.

Tietokannan tavoitteet

Ryhmä määritteli, suunnitteli ja toteutti uuden SHAMAN-järjestelmän tietokannan siten, että se vastaa nykyisiä tarpeita ja mahdollistaa tietokannan laajentamisen myös tulevaisuudessa. Tietokannan suunnittelussa pyrittiin ajattelemaan käyttötapauksia hyvin abstraktilla tasolla, jottei tietokantaa suunnitella vain yhden järjestelmän ehdoilla. Rajapinnat huolehtivat eri kohdejärjestelmien käyttöoikeuksien hallinnasta tietokannan välittämien tietojen perusteella.

Tietokantaan suunniteltiin paljon parametrisoituja rakenteita, jotka mahdollistavat monien erilaisten tietotyyppien lisäämisen tietokantaan. Esimerkiksi henkilölle voidaan lisätä tarpeen mukaan erilaisia tietotyyppejä, kuten puhelinnumeroita tai osoitteita. Myös oikeuksia kuvaaville resursseille lisättiin parametreja, joilla voidaan määritellä yhdelle resurssille monta erityyppistä parametria.

Tietokantaan suunniteltiin ryhmärakenne, jonka avulla voidaan kuvata erilaisia organisaatiohierarkioita. Myös erilaiset oikeudet voidaan kuvata ryhminä, jolloin niiden käsittely ja oikeuksien antaminen helpottuvat. Ryhmään voidaan liittää haluttu määrä eri kohdejärjestelmien resursseja. Ne periytyvät kaikille tunnuksille, jotka kuuluvat ryhmään joko suoraan tai välillisesti.

Tietokannan suunnitteluun käytettiin paljon aikaa ja sen rakenne muuttui useita kertoja. Joskus hyvinkin radikaalit muutokset kuitenkin edesauttoivat tietokannalle asetettujen vaatimusten toteuttamista.

Ryhmän suunnittelema tietokanta toteuttaa lähes kaikki sille asetetut vaatimukset, vaikka muutamat vaatimukset tuntuivatkin alussa hankalilta toteuttaa. Useat vaatimukset voidaan toteuttaa käyttämällä parametrisoituja rakenteita tai resursseja. Tällaisia ovat esimerkiksi henkilöltä tai ryhmältä oikeuksia poistavat negatiiviset oikeudet, joista oltiin useaa eri mieltä. Lopuksi päätettiin, että negatiivisia oikeuksia ei toteuteta suoraan, vaan negatiivista oikeutta voi kuvata tietty resurssi ja kohdejärjestelmän rajapinnan tehtäväksi jää käsitellä negatiivinen oikeus.

Suunnitteluvaiheen loputtua ryhmä oli hyvin tyytyväinen suunnitelmaansa tietokantaan ja uskoi sen täyttävän myös tulevaisuudessa sille asetetut vaatimukset. Tarkempi kuvaus tietokannan rakenteesta löytyy SHAMAN-projektin sovellusraportista.

Käyttöliittymän ja rajapintojen tavoitteet

Ryhmän tuli suunnitella ja toteuttaa rajapinnat tietojen tuomiseksi, viemiseksi ja muuttamiseksi tietokantaan. Ajanpuutteen takia keskityttiin ainoastaan pääkäyttäjän käyttöliittymään ja sille tarkoitettuun rajapintaan, sillä kaikkien muiden käyttäjien käyttöliittymät saadaan helposti muuttamalla pääkäyttäjän käyttöliittymää. Myös rajapinnat siirtotiedostojen tuomiseksi lähdejärjestelmistä ja viemiseksi kohdejärjestelmiin sovittiin rajattaviksi projektin ulkopuolelle, sillä ne on myös helppo toteuttaa jälkikäteen pääkäyttäjän käyttöliittymän rajapinnan avulla.

Ryhmä keskittyi ajan puutteen takia tietokannanhallintamoduulien toteuttamiseen, joiden päälle voidaan tulevaisuudessa rakentaa muut rajapinnat käyttöliittymille sekä kohde- ja lähdejärjestelmille.

Ylläpitäjän käyttöliittymästä pyrittiin suunnittelemaan mahdollisimman helppokäyttöinen ja muokattava. Perl-ohjelmointikielen HTML::Template-moduulin avulla käyttöliittymän koodi ja ulkoasu voitiin erottaa toisistaan, jolloin saavutettiin helppo muokattavuus. Myös CSS-tyylitiedostojen käyttö edesauttaa sivujen muokattavuutta. Ryhmän tavoitteena ei ollut ajanpuutteen takia hioa käyttöliittymästä mahdollisimman käytettävää, vaan saada pääkäyttäjille prototyyppi palautteen ja jatkokehitysideoiden keräämiseksi. Alusta asti oli nimittäin selvää, että käyttöliittymää tullaan joka tapauksessa jatkokehittämään SHAMAN-projektin jälkeen.

Ryhmä kuitenkin mietti suuntaviivoja, joiden mukaan käyttöliittymää tullaan kehittämään. He vierailivat ATK-keskuksen palvelupisteessä tutustumassa henkilöihin, jotka tulisivat käyttämään järjestelmää päivittäin. Näistä vierailuista saatiin hyviä ideoita, jotka auttavat käyttöliittymän jatkokehityksessä.

Oppimistavoitteet

Projektisuunnitelmassa olleet oppimistavoitteet toteutuivat lähes kokonaan, kuten oli ennakoitu. Ryhmä oppi erilaisia projektin läpivientiin liittyviä taitoja, kuten ryhmätyöskentelyä, kokouksissa toimimista, kommunikointia, aikataulussa pysymistä sekä vastuun ottamista omasta ja muiden työstä.

Ryhmätyöskentely sujui projektin aikana pääsääntöisesti hyvin. Varsinkin suunnitteluvaiheessa ryhmä työskenteli paljon yhdessä ja järjestelmän ongelmakohtia pohdittiin monen henkilön voimin. Sovelluksen suunnitteluvaiheessa ryhmän sisällä esitettiin eriäviä mielipiteitä sovelluksen toteuttamistavoista. Myös tilaajalla oli oma näkemyksensä toteutustavasta. Koska sovelluksen suunnittelussa ei ole mitään oikeaa tapaa, ryhmä päätti toteuttaa sovelluksen suunnittelemallaan tavalla ja katsoa, tuottaisiko suunnitelma mitään toteutusongelmia.

Ryhmän sisällä ei ilmennyt muista suuria ristiriitoja. Normaalit suunnitteluun ja toteutukseen liittyvät erimielisyydet ratkottiin keskustelemalla. Suurin mielipiteitä jakanut asia oli projektihuoneessa soitettavan musiikin laji. Koko ryhmä kannatti musiikin soittamista, sillä kaikki olivat tottuneet kuuntelemaan musiikkia työskennellessään.

Ryhmän motivaatio pysyi korkealla koko projektin ajan. Suurin syy korkeaan motivaatioon oli projektin aiheen haastavuus ja oman suunnittelupanoksen näkyminen tulevassa järjestelmässä. Ryhmä myös oppi sitoutumaan projektiin, eikä töiden välttelyä esiintynyt.

Kommunikointi ryhmän sisällä ja tilaajien kanssa sujui hyvin. Ryhmä tiedotti edistymisestään muuta projektiorganisaatiota ja tilaajat antoivat palautetta ryhmälle. Ryhmä huomioi tilaajan palautteen ja kommentit suunnitelmissa ja toteutuksessa.

Eniten ryhmä oppi Perl-ohjelmointikielestä, sillä se oli entuudestaan kaikille kohtuullisen tuntematon. Ohjelmointikielessä oli joitakin erikoisia toteutuksia, jotka tuottivat ryhmälle ja tekniselle ohjaajalle päänvaivaa. Koska testaukseen ei jäänyt aikaa, sisältää sovellus virheitä ja siitä uupuvat parametrien tyyppien tarkistukset. Kuitenkin sovellus on toimiva niiltä osin, jotka ehdittiin toteuttaa ja testata käyttöliittymän avulla.

Projektipäällikkö oppi varsinkin töiden suunnittelua ja jakamista, sillä suunniteltu töiden jakautuminen ei juurikaan toiminut tositilanteessa ja töitä jouduttiin usein uudelleenjakamaan lennosta. Tämä johtui varsinkin siitä, että suunnitteluun kuluvaa aikaa oli hankala arvioida. Projektipäällikkö johti projektia rennolla, mutta määrätietoisella otteella. Muut ryhmän jäsenet eivät toimineet projektipäällikkönä, joten heidän kokemuksensa projektin johtamisesta olivat pienemmät. Matti tosin oli hyvin selvillä projektin tilasta ja toimikin usein varajohtajana.

Palavereissa jokainen pääsi vuorollaan toimimaan puheenjohtajana, ja jokaisessa palaverissa käytettiin kahta sihteeriä. Myös dokumenttien ja raporttien kirjoittaminen tuli kaikille tutuksi, tosin projektipäällikölle hieman enemmän kuin muille. Alussa palavereista tehtyjä pöytäkirjoja jouduttiin hiomaan, mutta lopussa pöytäkirjat syntyivät lähes itsestään. Usein jopa niin, että ryhmän jäsen oli ehtinyt tehdä pöytäkirjan valmiiksi heti kokouksen jälkeen muun ryhmän tietämättä.

Ryhmän jäsenet saivat myös lisää kokemusta esiintymisestä, joka on yleensä kompastuskivi sosiaalisia tilanteita välttäville koodareille.

Projektin resurssit

Luvussa kuvataan projektin organisaatiota ja käytettävissä olleita resursseja.

Projektiorganisaatio

Projektiorganisaatioon kuuluivat neljä tietotekniikan opiskelijaa, jotka suunnittelivat ja toteuttivat järjestelmän tietotekniikan Sovellusprojektina. Ryhmään kuuluivat Marko Andersson, Mika Rinkinen, Matti Törmä ja Timo Valonen.

Tilaajan edustajina toimivat Matti Levänen ja Tero Toivonen Jyväskylän yliopiston ATK-keskuksesta. Projektiorganisaatioon kuului myös Sirpa Turjanmäki, joka vastaa nykyisen AMAN-järjestelmän toiminnasta.

Teknisenä ohjaajana toimi Lassi Paavolainen sekä vastaavana ohjaajana Jukka-Pekka Santanen tietotekniikan laitokselta.

Projektissa kuultiin myös eri tieto- ja käyttöjärjestelmien asiantuntijoita, jotka auttoivat projektia kartoittamaan AMAN-järjestelmään tallennettavia tietoja ja kohdejärjestelmien tarpeita. Sähköpostijärjestelmien ylläpitäjistä mukana olivat Seppo Kallio ja Tapani Tarvainen sekä UNIX-järjestelmien osalta Tuomas Kautto ja Mika Videnoja. Mikroverkkojen asiantuntijana toimi Mika Mattila. Korppia edustivat Minna Hillebrand ja Pauli Kujala. Optiman edustajana oli Markku Närhi. Yliopiston WWW-järjestelmien asiantuntijoina olivat Jenni Hytönen sekä Jussi Talaskivi. Kirjaston asiantuntijana kuultiin Risto Heikkistä.

Käyttöliittymän ulkoasua ja toteutusta kommentoi yliopiston ATK-keskuksen palvelupisteen työntekijöistä, etenkin Marjut Hartikainen.

Projektin ATK-tukena toimivat Jyväskylän yliopiston informaatioteknologian tiedekunnasta Mika Harju, Jussi Kokkonen, Jari Lepistö, Juha-Matti Sulander ja Harri Tuomi.

Työtila, laitteet ja ohjelmistot

Projektin työhuone sijaitsi Sovellusprojektin tiloissa Agoran toisessa kerroksessa huoneessa AgC223.3. Puhelinnumero huoneeseen on (014) 260 4965

Projektin käytössä oli neljä PC-tietokonetta, joista kaksi on varustettu Windows XP -käyttöjärjestelmällä ja toiset kaksi Linux Fedora Core 2 -käyttöjärjestelmällä.

Tietokoneisiin oli asennettu perusohjelmistot, jotka sisältivät esimerkiksi toimisto-ohjelmat. Windows-koneet sisältivät sekä Microsoft Officen version 2003 (11.6359.6360) SP1, että OpenOfficen version 1.1.4. Linux-koneissa oli vain OpenOfficen versio 1.1.3. Lisäksi yhteen Windows-koneeseen oli asennettu Microsoft Projectin versio 9.0.2000.0224 sekä Microsoft Vision versio 6.0.2072. Linux-koneille oli asennettu Perl-tulkeista versio 5.8.3 built for i386-linux-thread-multi sekä PostgreSQL-tietokannanhallintajärjestelmästä versio 7.4.7. Windows-koneisiin oli asennettu ActivePerl versio 5.8.0 built for MSWin32-x86-multi-thread. Tietokannan suunnittelussa käytettiin Erkka-tietokannan mallinnussovelluksen versiota 1.1 ja Microsoft Paintin versiota 5.1. Käyttöliittymän testauksessa käytettiin Internet Explorer -selaimen versiota 6.0, Operan versiota 7.54 ja Mozilla FireFoxin versiota 1.0.3. Projektin käytössä oli myös yksi yhteinen verkkotulostin sekä laitoksen kopiokone.

Projektin dokumentointi ja sovellukset sijoitettiin projektin kotisivuille osoitteeseen http://sovellusprojektit.it.jyu.fi/shaman/. Projektilla oli käytössään sähköpostilista shaman@korppi.jyu.fi. Sähköpostilistan arkisto on nähtävissä osoitteessa https://korppi.it.jyu.fi/list-archive/shaman/. Arkisto on suojattu käyttäjätunnuksella ja salasanalla, jotta viestit eivät näkyisi kaikille käyttäjille.

Sähköpostilistalla olevalla Sirpa Turjanmäellä on pääsy ATK-keskuksen aman-devel -sähköpostilistalle. Hän pystyi siten lähettämään projektiorganisaatiolle hyödyllisiä AMAN-järjestelmään liittyviä kehitysideoita projektin sähköpostilistalle.

Oheiskurssin koulutukset ja perehdytykset

Luvussa kuvataan ryhmän saamia perehdytyksiä ja koulutuksia, jotka koskivat projektissa käytettäviä työkaluja.

Aloitusluento ja projektiluento

Projektin aloitusluento pidettiin 28.1.2005, jossa oppilaat jaettiin projektiryhmiin ja heille annettiin projektien aiheet.

Projektin hallintaa ja läpivientiä koskeva luento pidettiin 8.2.2005. Luennolta sai ohjeita projektin läpiviemiseksi sekä erilaisten riitatilanteiden välttämiseksi ja korjaamiseksi ryhmän sisällä. Projektipäällikkö oli jo tuolloin valittu ja päällikkö yrittikin ottaa luennosta vinkkejä myöhempiä tilanteita varten. Todellisuudessa huomattiin, että mitään ennalta määrättyä johtamistapaa oli turha miettiä.

Perl-perehdytys

Ryhmä sai 16.2.2005 perehdytystä Perl-ohjelmointikieleen, joka oli jokseenkin tuntematon koko ryhmälle. Perehdytyksessä käsiteltiin Perlin syntaksi tavallisimpien ohjelmarakenteiden kohdalta. Perehdytyksessä ei juurikaan käsitelty Perlin tapaa käsitellä olioita, ja tästä aiheutuikin ryhmälle ongelmia myöhemmin. Mielestämme tavanomaisten syntaksien osalta olisi riittänyt pelkkä perehdytysmateriaali, sillä ne ovat pääsääntöisesti tuttuja muista kielistä, ja suullinen perehdytys olisi käsitellyt Perlin ominaispiirteitä.

Eclipse-perehdytys

Ryhmille järjestettiin myös perehdytys Eclipse-kehitysympäristöön. SHAMAN-ryhmä ei osallistunut perehdytykseen, koska emme tuolloin aikoneet käyttää Eclipse-kehitysympäristöä. Myöhemmin saimme kuulla Eclipseen löytyvän Perl-pluginin, joten teimme Eclipsen osalta yhteistyötä ECSS07-ryhmän kanssa. Itse ympäristön opetteluun ei juurikaan tarvinnut käyttää aikaa.

Projektipäälliköiden tapaamiset

Eri ryhmien projektipäälliköiden kesken järjestettiin kaksi tapaamista 15.2.2005 ja 1.3.2005. Tapaamisissa tarkasteltiin projektien aikataulu- ja tehtävienjakosuunnitelmia. Tapaamiset antoivat joitakin vinkkejä projektin suunnittelusta ja auttoivat huomaamaan virheitä ajankäytön suunnittelussa.

CVS-versionhallinta

Perehdytys CVS-versionhallintajärjestelmään pidettiin 22.2.2005. Versionhallinta oli projektin mielestä hyvin tervetullut. CVS-versionhallinnan lupailtiin ratkaisevan lähes kaikki ongelmat, joita syntyy usean henkilön muokatessa samoja tiedostoja samaan aikaan. Todellisuudessa CVS-versionhallinnasta oli hyötyä vasta Eclipse-ympäristössä, kun sen käytöstä tuli nopeaa ja helppoa. Tällöinkin se toimi vain tietovarastona, jonka kautta pystyttiin lähdekoodi jakamaan ryhmän kesken nopeasti. Saman tiedoston muokkaukseen siitä ei juurikaan ollut apua, tai ainakaan ryhmä ei osannut sitä käyttää. Ennen Eclipsen käyttöönottoa ryhmä käytti CVS:ää komentoriviltä ja se toimi vain varmuuskopiovarastona.

Itse koulutus oli huonosti suunniteltu ja puuduttava. Hienon FreeMind-piirroksen avulla yritettiin todistaa CVS-järjestelmän hyötyä, mutta ainakin tuolloin se ei juurikaan vakuuttanut. CVS:n käyttöä harjoiteltiin FreeMind-piirroksen ohjeiden avulla, jotka olivat huonosti laadittuja ja epäselviä. Missään vaiheessa ei syntynyt kuvaa, mitä konkreettista hyötyä CVS:tä oli projektin kannalta.

Koulutuksen ajan jo umpeutuessa siirryttiin projektihuoneisiin asentamaan jokaiselle koneelle CVS käyttövalmiiksi. Tämä oli ainoa perehdytyksen osa, josta oli jotain hyötyä. Perehdytyksen alun olisi voinut jättää pois.

Tekijänoikeusluento

Sovellusprojekteille järjestettiin luento tekijänoikeuksista 21.3.2005. Luennolla käsiteltiin tekijänoikeuksia eri näkökulmista ja esitettiin muutamia esimerkkejä. Osa luennon sisällöstä oli mielenkiintoista, mutta luennolla opitun perusteella on turha alkaa tekemään sopimuksia, joissa olisi huomioitu mahdollisimman paljon eri ristiriitatilanteita. Kokonaisuudessaan tekijänoikeusluento ei hyödyttänyt ryhmää mitenkään, sillä ryhmän ja tilaajan välisessä sopimuksessa jäsenet eivät luopuneet oikeuksistaan sovellukseen.

Ensimmäinen ja toinen väliesittely

Projektien ensimmäinen ja toinen väliesittely järjestettiin 23.3.2005 ja 4.5.2005. Esittelyiden tarkoituksena oli valmistaa ryhmää loppuesittelyä varten. Ryhmä koki esittelyt hieman turhiksi, sillä yleisölle esiintymistä on kouluissa harrastettu jo kautta aikojen. Esityksistä saadusta palautteesta oli hyötyä loppuesittelyyn valmistautumiseen.

Väliesittelyihin ryhmä ei juurikaan valmistautunut ja materiaali oli hyvin nopeasti kasattua. Varsinkin toinen väliesittely ajoittui pahasti kiivaimpaan toteutusvaiheeseen, joten ryhmä laati käytetyt kalvot noin 1,5 tuntia ennen esitystä ja esitykset vedettiin ns. lonkalta.

Käytettävyyspäivä

Ryhmille järjestettiin käytettävyyspäivä 11.4.2005. Käytettävyyspäivän tarkoituksena oli opettaa ryhmille pääasiassa WWW-sivujen ulkoasun ja käytettävyyden suunnittelua. Luennolla käydyt aiheet olivat kaikille tuttuja aikaisemmin suoritetuilta kursseilta ja tieto niiden kuulemisesta uudelleen ei nostattanut mielialaa.

WWW-sivujen käytettävyyteen liittyneet asiat olivat hyvin itsestään selviä ja esimerkeissä tarkasteltiinkin WWW-sivuja, joiden oli tarkoitus olla huomiota herättäviä ja hienon näköisiä. SHAMAN-ryhmän kohdalla käytettävyysluennosta ei ollut juurikaan apua. Sovelluksen käyttöliittymän suunnittelussa käytettiin tervettä järkeä, jolloin sivujen käytettävyys saatiin riittävälle tasolle. SHAMAN-ryhmä ei ollut alkanut vielä suunnittelemaan käyttöliittymää, joten luennolla olisi voinut olla hyötyä suunnittelussa. Useimmista muista ryhmistä käytettävyyspäivän ajankohta oli huono.

Loppuesittely

Projektin loppuesittely järjestettiin 18.5.2005. Ryhmä esitteli projektin tuloksia muiden ryhmien jäsenille, tilaajille ja ohjaajille. Esitykseen oli vapaa pääsy, joten yleisön joukossa oli muitakin aiheesta kiinnostuneita. SHAMAN-projektin esitystä oli tullut seuraamaan paljon yliopiston henkilökuntaa, joita SHAMAN-projektin tulokset kiinnostivat. Useimmat heistä poistuivat ryhmän esityksen jälkeen.

Esityksen lopuksi tilaajan edustaja Matti Levänen kertoi projektin taustoja ja kommentoi projektin tuloksia. Myös vastaava ohjaaja ja tekninen ohjaaja antoivat suulliset kommentit ryhmän onnistumisesta.

Projektiin liittyvät perehdytykset ja tutustumiset

Luvussa kuvataan perehdytyksiä, joissa ryhmä pääsi tutustumaan vanhaan AMAN-järjestelmään sekä sitä käyttäviin ATK-keskuksen palvelupisteen henkilökuntaan ja heidän toimintatapoihinsa.

Tutustuminen Korpin ryhmärakenteeseen

Ryhmä kävi 18.2.2005 tutustumassa Minna Hillebrandin luona Korpin ryhmärakenteeseen ja sen toteutukseen, sekä keskustelemassa toteutuksessa kohdattavista ongelmista. Hillebrand kertoi, että Korpin ryhmärakenne vastaa pitkälle SHAMAN-ryhmän suunnittelemaa ryhmärakennetta. Hän myös kertoi suorituskykyongelmista, joita ryhmähierarkia muodostaa. Keskustelu antoi ryhmälle lisävarmuutta jatkaa valitsemaansa suunnittelulinjaa.

Tutustuminen AMAN-järjestelmään

Ryhmä kävi ensimmäisen kerran tutustumassa 18.2.2005 tilaajan edustajan Tero Toivosen luona nykyiseen AMAN-järjestelmään. Toivonen esitteli ryhmälle AMANiin tallennettuja tietoja, käyttöliittymää ja hieman toteutusta. Tällöin ryhmällä ei ollut täysin selvää kuvaa uuden järjestelmän tarpeista ja vaatimuksista, joten esittelystä ei saatu täyttä hyötyä. Esille tulivat kuitenkin nykyisen järjestelmän puutteet ja heikkoudet, joita ryhmän tuli välttää.

Toinen tutustuminen AMAN-järjestelmään tapahtui 18.4.2005 ATK-keskuksen palvelupisteessä. Ryhmä tutustui palvelupisteen henkilökunnan suorittamiin toimiin AMAN-järjestelmällä ja sai hyvän kuvan siitä, mitä normaalisti järjestelmällä tullaan tekemään. Tutustumisen pohjalta luotiin käyttöliittymän prototyyppi, jossa oltiin huomioitu palvelupisteen työntekijöiden toivomuksia.

Perehdytys HTML::Template-moduulin käyttöön

Tekninen ohjaaja Lassi Paavolainen esitteli ryhmälle 15.4.2005 Perlin HTML::Template-moduulin käyttöä käyttöliittymän kehityksessä. Perehdytys oli hyvin tervetullut, sillä kenelläkään ei ollut aikaisempaa kokemusta moduulin käytöstä.

Projektin tehtävät ja niiden jakautuminen

Luvussa kuvataan projektin tehtävien jakautumista ryhmän jäsenten kesken, sekä tehtävien muutoksia suunnitelmiin verrattuna.

Projektin aikataulun suunnittelu oli hyvin haastavaa, koska suunnitteluun oli varattava paljon aikaa. Määrittelyyn ja suunnitteluun tarvittavaa aikaa oli hyvin hankala arvioida ja tehtävien järkevä jaottelu muodostui hankalaksi. Projektisuunnitelmassa tehtävät jaettiin tasaisesti ryhmän kesken. Jotkin tehtävät veivät kuitenkin niin paljon aikaa, että muita samalle henkilölle suunniteltuja tehtäviä piti organisoida uudelleen muille ryhmän jäsenille.

Vastuualuejako

Vain noin puolet tehtävistä suoritti henkilö, jolle tehtävä oli suunniteltu. Muissa tapauksissa tehtävä annettiin ryhmän jäsenelle, jolla oli vähiten kuormitusta. Tämä oli välttämätöntä, sillä muuten projektin eteneminen olisi keskeytynyt muiden odottaessa tehtävien valmistumista. Loppujen lopuksi tehtävät saatiin jaettua kaikkia tyydyttävällä tavalla projektin jäsenten kesken.

Projektin alussa koko ryhmä osallistui yhdessä järjestelmän määrittelyyn ja suunnitteluun. Kun projektin aihealue ja vaatimukset alkoivat olemaan kaikille selvät, ryhmä hajaantui suunnittelemaan omia osuuksiaan. Matti Törmä ja Timo Valonen osallistuivat tietokannan määrittelyyn ja suunnitteluun. Marko Anderssonia työllisti projektin alussa projektisuunnitelman laatiminen. Mika Rinkinen laati sovelluksen vaatimusmäärittelyn, joka suunnitelmien muuttuessa vaati paljon korjauksia ja päivityksiä.

Matti Törmä vastasi pitkälle järjestelmän moduulien suunnittelusta. Samalla Timo Valonen ja Marko Andersson kehittivät tietokannan hallintaan ja hakujen nopeuden arviointiin käytettyjä testiskriptejä.

Toteutusvaiheessa tietokannasta vastasi Timo Valonen, joka toteutti tietokannan luontilauseet sekä piirsi ER-kaaviot ja relaatiokuvat. Marko Andersson ja Matti Törmä toteuttivat tietokannan hallintaan käytettyjä moduuleja. Mika Rinkisen tehtävänä oli ryhmähierarkian hallintaan käytettyjen funktioiden toteutus.

Koska projektin aikana sovelluksen suunnitelmat olivat muuttuneet useaan kertaan, sovellussuunnitelma vastasi pitkälti nykyistä tilannetta. Jukka-Pekka Santanen ehdottikin, että ryhmä luopuu yhtenäisen sovellussuunnitelman tekemisestä ja laatii suoraan sovellusraportin. Projektipalaverissa päätettiin, että Matti Törmän tekemät oliosuunnitelmat voidaan liittää sellaisinaan suunnitteludokumenteiksi.

Koko projektin ajan projektipäällikkönä toimi Marko Andersson, joka vastasi projektin suunnittelusta ja hallinnasta.

Tehtävien työmäärä ja jakautuminen

Taulukossa 1 on esitetty projektisuunnitelmassa arvioidut työtunnit ja niiden toteutuminen projektin aikana. Tarkkaa tuntien jakautumista on hankala esittää, sillä usein ajankäyttösovelluksella kirjattiin vain päivän aikana tehdyt suuremmat työtehtävät. Esimerkiksi tiedottaminen hoidettiin osana muita tehtäviä, kuten suunnittelua tai pöytäkirjan kirjoittamista. Jokainen ryhmän jäsen on kirjannut omat tuntinsa taulukkoon.

Projektin jäsenten tekemät työtunnit eroavat varsinkin projektipäällikön osalta. Hän huomaamattaan otti projektin alussa etumatkaa muihin ryhmän jäseniin nähden ja säilytti etumatkansa koko projektin ajan. Projektipäällikkö panosti projektisuunnitelman laatimiseen paljon projektin alkuvaiheessa. Projektipäällikkö osallistui myös toteutukseen suunniteltua suuremmalla panoksella, sillä hänellä oli ohjelmoinnista paljon kokemusta. Muiden jäsenten opiskelut myös laskivat heidän tuntimääräänsä.

Taulukko 1. Projektin tehtävät sekä niiden jakautuminen ja niihin kuluva aika.

Muutokset tehtäväjaossa ja työmäärissä

Kotisivuihin käytetty aika jäi arvioitua pienemmäksi. Tämä johtui lähinnä kotisivujen askeettisesta ulkoasusta, jota ei haluttu muuttaa. Ryhmän mielestä kotisivujen ulkoasulla ei ollut projektin kannalta merkitystä.

Palavereihin kulunut aika oli suurempi kuin ennalta osattiin arvioida. Tämä johtui pääasiassa projektin suunnittelupainotteisuudesta, jonka takia palaverien kestot olivat pitkiä, keskimäärin noin 3 tuntia. Suunnitelmissa palaverien keskimääräinen kesto arvioitiin olevan 2 tuntia. Viikkopalaverien määräksi arvioitiin projektisuunnitelmassa 15 palaveria, kun todellisuudessa palavereja oli 14. Palavereihin kuluneeseen aikaan laskettiin myös palaveriin valmistautuminen, joka oli kultakin jäseneltä keskimäärin 30 minuuttia palaveria kohden.

Projektin edetessä Timosta kehittyi projektin pöytäkirjojen laatija. Hän usein ehti laatia pöytäkirjat heti palaverin jälkeen, ennenkuin muut edes huomasivat sitä. Projektin loppupuolella pöytäkirjojen laatiminen kävi hyvin nopeasti edellisen pöytäkirjan pohjalta.

Myös Marko ja Mika laativat muutamia pöytäkirjoja, mutta Mattia ei pöytäkirjojen kirjoittaminen juurikaan kiinnostanut. Hän oli laatimassa projektin ensimmäistä pöytäkirjaa ja totesi jo tuolloin, ettei välitä niiden kirjoittamisesta. Suurempien dokumenttien kirjoitukseen hän kuitenkin osallistui.

Tämän lisäksi pidettiin kaksi työpajaa, johon osallistuivat projektiorganisaatioon kuuluneita eri järjestelmien asiantuntijoita. Tietokannan suunnittelun yhteydessä pidettiin myös tietokantapalaveri, jossa tarkasteltiin ja pohdittiin tietokannan suunnittelua. Työpajoihin kului vähemmän aikaa kuin oli suunniteltu, sillä työpajojen lukumääräksi oletettiin kolmea. Taulukossa tietokantapalaveri on luettu palavereihin, eikä työpajoihin.

SHAMAN-järjestelmän suunnitteluun käytetty aika jäi huomattavasti suunnitellusta. Matti toimi järjestelmän pääsuunnittelijana ja ainoastaan hänen tuntinsa vastasivat kutakuinkin suunniteltua. Muiden tunnit jäivät alle puoleen suunnitellusta. Ryhmä ei juurikaan ehtinyt suunnitellut käyttöliittymää tai kohde- ja lähdejärjestelmien rajapintoja. Tilaajan mielestä tietokannanhallintamoduulien suunnittelu ja toteutus olivat pääsijalla. Rajapinnat olisi helppo toteuttaa niiden pohjalta.

Suunnitelmissa vaatimusmäärittelyn kirjoittaminen oli jaettu Matin ja Mikan kesken, mutta SHAMAN-järjestelmän suunnittelu vaati Matin huomion, joten Mika joutui selviytymään vaatimusmäärittelystä yksin. Projektin luonteesta johtuen vaatimusmäärittelyä jouduttiin muuttamaan ja korjaamaan useita kertoja. Tämä näkyy dokumenttien kirjoitusasun korjaamiseen käytettyjen tuntien määrässä.

Sovellussuunnitelmaan ehdittiin käyttämään noin 10 tuntia, kunnes sovelluksen toteutusratkaisut päätettiin kirjata suoraan sovellusraportiksi.

Suunnitelmissa toteutusvaihe arvioitiin pienemmäksi kuin suunnitteluvaihe, mutta projektin lopussa toteutusvaiheen tunnit olivat huomattavasti suunniteltua suurempia. Toteutukseen käytetyt ylimääräiset tunnit olivat pitkälti suunnitteluun varattuja tunteja. Mikalla toteutuksen tunnit eivät ylittyneet, sillä häntä työllisti toteutusvaiheessa vaatimusmäärittelyn korjaus.

Rajapintojen toteutus priorisoitiin projektin aikana pienemmälle prioriteetille kuin projektin alussa oli suunniteltu. Tästä johtuen sovelluksen rajapintoja ei toteutettu ollenkaan, vaan ne ainoastaan määriteltiin ja osaksi suunniteltiin.

Alkuperäisessä suunnitelmassa käyttöliittymän toteutus oli jaettu Matin ja Timon kesken. Matin työpanosta tarvittiin kuitenkin tietokantamoduulien toteutuksessa, joten Timo toteutti käyttöliittymää yksin. Muu ryhmä pyrki auttamaan Timoa miettimällä käyttöliittymän ulkoasua ja toiminnallisuutta muiden töiden ohessa. Käyttöliittymää ei varsinaisesti suunniteltu, mutta sen ulkoasua ja toiminnallisuutta mietittiin ryhmän ja tilaajien kesken. Ideoita pyydettiin myös ATK-keskuksen palvelupisteen henkilökunnalta.

Sovellusta ei juurikaan ehditty testaamaan tai viimeistelemään. Projektisuunnitelmassa testaukselle oli suunniteltu muutamia tunteja, mutta käytännössä järjestelmä oli vielä niin keskeneräinen, ettei laajoja testauksia pystytty tekemään.

Sovellusraporttiin käytettiin suunniteltua enemmän työaikaa. Tämä johtui osaksi sovellussuunnitelman puutteesta. Toinen syy oli Perlin dokumentointityökalujen puute Eclipsessä. Tästä syystä metodien kuvaukset jouduttiin kirjoittamaan käsin.

Sovelluksen käyttöliittymää hiottiin hieman ennen loppuesittelyä. Muutamia koodissa olleita virheitä korjattiin teknisen ohjaajan huomioiden perusteella.

Projektin aikataulu

Luvussa kuvataan projektin aikataulun toteutumista projektisuunnitelmassa suunniteltuun aikatauluun verrattuna.

Vaiheet ja tulokset

Taulukossa 2 on esitetty projektisuunnitelmassa määritellyt vaiheiden aikajanat ja niiden toteutuminen.

Vaiheet ja tulokset	Suunniteltu	Toteutunut
Aiheeseen ja työkaluihin tutustuminen.	29.1. – 21.3.	29.1. – 21.3.
Projektin suunnittelu ja vaatimusten määrittely.	7.2. – 12.3.	10.2 – 1.5.
Sovelluksen suunnittelu.	14.3. – 2.4.	28.3 – 3.5.
Sovelluksen toteutus.	27.3. – 5.5.	4.3. – 17.5.
Sovelluksen järjestelmätestausta.	8.4. – 5.5.	-
Sovelluksen viimeistely.	2.5. – 20.5.	17.5 – 18.5.

Taulukko 2. Projektin aikataulu.

Aiheeseen ja työkaluihin tutustuminen vastasi suurin piirtein suunniteltua. Aiheeseen tutustumisjakson loppumista on hankala määritellä ajankäyttöraporteista.

Vaatimusmäärittelydokumentin hyväksyminen venytti vaatimusmäärittelyajanjaksoa. Todellisuudessa vaatimusmäärittelyjakso loppui noin 16.3.

Toteutunut aikataulu venyi sovelluksen määrittelyn ja suunnittelun osalta verrattuna projektisuunnitelmassa olleeseen suunnitelmaan. Sovelluksen määrittelyyn ja suunnitteluun käytetty aika oli pois sovelluksen toteutuksesta ja testauksesta. Sovellusta saatiin toteutettua kohtuullisen pitkälle, mutta testaus jäi lähes olemattomaksi.

Sovellusta ei ehditty testaamaan järjestelmällisesti ja viimeistely tapahtui ennen loppuesittelyä, jolloin käyttöliittymän ulkoasua parannettiin ja havaittuja virheitä korjattiin.

Taulukossa 3 on esitetty suunnitellut dokumenttien tarkastuspisteet ja niiden toteutuminen. Ajanpuutteen takia sovellussuunnitelmasta ja testaussuunnitelmasta jouduttiin luopumaan.

Dokumentti	Suunniteltu	Alustava versio	Hyväksytty
Projektisuunnitelma	1.3.	23.2.	1.4.
Vaatimusmäärittely	14.3.	15.3.	13.5.
Sovellussuunnitelma	1.4.	Ei toteutettu.
Testattava prototyyppi	29.4.	4.5.	-
Testaussuunnitelma	18.4.	Ei toteutettu.
Sovellusraportti	16.5.	19.5	16.6
Asennusohje	16.5.	23.5	31.5
Projektiraportti	20.5.	19.5	2.6

Taulukko 3. Projektin dokumenttien tarkastuspisteet.

Dokumenteista valmistuivat alustavat versiot pääsääntöisesti ajallaan, mutta esimerkiksi vaatimusmäärittelyn lopullinen versio hyväksyttiin vasta kahden kuukauden päästä suunnitellusta. Vaatimusmäärittelyä jouduttiin muokkaamaan ja korjaamaan useasti, sillä vaatimukset ja sovelluksen suunnitelmat muuttuivat useasti projektin aikana ja vaatimusmäärittely sisälsi vanhaa tietoa.

Ironisesti projektisuunnitelma hyväksyttiin aprillipäivänä ja vaatimusmäärittely perjantaina 13. päivänä toukokuuta.

Tehtävien aikataulu

Kuvissa 3 ja 4 on esitetty projektin suunniteltu ja toteutunut aikataulu Gantt-kaaviona. Tilanpuutteen takia kuvista puuttuvat taulukossa 4 esitetyt oheiskurssin tehtävät.

Toteutunutta aikataulua kuvaavassa kaaviossa nuolet tarkoittavat dokumenttien alustavien versioiden valmistumispäivää ja tähdet dokumenttien hyväksymispäivää.

Kuva 3. Gantt-kaavio tehtävien suunnitellusta aikataulusta.

Kuva 4. Gantt-kaavio tehtävien toteutuneesta aikataulusta.

Aikataulun muutokset

Projektin aiheen määrittely pääsi alkamaan virallisesti hieman suunniteltua myöhemmin ja se saatiin suoritettua suunnitelman mukaan. Määrittelyvaiheessa ryhmä kulutti paljon aikaa kuulemalla eri järjestelmien asiantuntijoita, joiden avulla kartoitettiin SHAMAN-järjestelmän vaatimuksia.

Suunnittelujakson aloitti tietokannan suunnittelu. Suunnittelujakso alkoi pari viikkoa suunniteltua myöhemmin. Tämä johtui lähinnä aiheeseen ja AMAN-järjestelmään tutustumiseen käytetystä ajasta määrittelyvaiheessa. Eniten aikaa suunnitteluvaiheessa käytettiin tietokannanhallintamoduulien suunnitteluun. Ryhmä pohti myös lähde- ja kohdejärjestelmien rajapintojen toteutustapoja. Käyttöliittymää ei suunniteltu järjestelmällisesti, mutta sen rakennetta ja toiminnallisuutta mietittiin ryhmän sisällä ja tilaajan edustajan kanssa. Suunnitelmista antoivat kommentteja ATK-keskuksen palvelupisteen henkilökunta. Suunnitteluvaihe kesti odotettua pidempään.

Tietokannan suunnittelun lomassa tietokannasta toteutettiin jo alustavia versioita. Toteutus tapahtui lähes automaattisesti, sillä suunnitteluun käytetty Erkka-ohjelma osasi tehdä tietokannan luontilauseet suoraan suunnitelmista. Moduulien toteutusvaiheen pituus oli suurin piirtein suunniteltu, mutta intensiivinen toteutus pääsi alkamaan muutamia viikkoja suunniteltua myöhemmin.

Koska projekti oli lopussa noin kaksi viikkoa myöhässä suunnitellusta aikataulusta, ei järjestelmää testattu käytännössä ollenkaan. Laajamittaista testausta ei myöskään ollut järkevä toteuttaa, sillä järjestelmä oli vielä hyvin keskeneräinen.

Sovelluksen käyttöliittymää viimeisteltiin hieman ennen loppuesittelyä esityskelpoiseen kuntoon.

Projektin ajankäyttö

Luvussa tarkastellaan projektin jäsenten tehtävien ajankäytön jakautumista sekä viikottaista työmäärää.

Koko ryhmä

Kuvassa 5 on esitetty tehtävien jakautuminen koko projektin osalta. Eniten aikaa vieneet tehtävät olivat suunnittelu, dokumentointi, ohjelmointi ja palaverit. Nämä veivät noin 75% koko projektin ajankäytöstä.

Kuva 5. Jäsenten yhteenlaskettu ajankäyttö tehtävittäin.

Projektin viikottainen työmäärä pysyi tasaisena projektin puoliväliin saakka (katso kuva 6). Tämän jälkeen työtahti kiihtyi, kun pääsimme toteutusvaiheeseen. Projektin loppuvaiheen tunnit pysyivät hallinnassa, eikä viime hetken hurjaa loppukiriä ollut.

Kuva 6. Jäsenten yhteenlaskettu ajankäyttö viikottain.

Viikon 13 pieni notkahdus selittyy pääsiäislomalla. Muita lomia projektin aikana oli esimerkiksi helatorstai, mutta suurin osa ryhmästä oli silloin paikalla tekemässä projektia, joten se ei vaikuttanut ajankäyttöön.

Marko

Kuvassa 7 on kuvattu Markon ajankäytön jakautuminen tehtävittäin. Projektipäällikkö joutui laatimaan kaksi suurta dokumenttia, joten hänen osuutensa dokumenteissa on suurempi kuin muilla. Projektisuunnitelmaan käytetyn ajan takia määrittely puuttuu kokonaan.

Kuva 7. Markon ajankäyttö tehtävittäin.

Kuvassa 8 on esitetty Markon ajankäytön jakaantuminen viikottain. Ajankäyttö on tasaista koko projektin ajan. Projektin keskivaiheilla on tullut pieni notkahdus, mutta se on korjattu nopeasti. Alun suuret tuntimäärät kuluivat projektisuunnitelman laatimiseen.

Kuva 8. Markon ajankäyttö viikottain.

Matti

Kuvassa 9 on esitetty Matin ajankäytön jakautuminen tehtävittäin projektin aikana. Matti vastasi paljon suunnittelusta, joka näkyy hänellä suurempana suunnittelun osuutena kuin muilla.

Kuva 9. Matin ajankäyttö tehtävittäin.

Kuvassa 10 on esitetty Matin ajankäyttö viikottain projektin aikana. Ajankäyttö projektin alkuvaiheessa on kohtuullisen tasaista. Projektin toteutusvaiheen alettua Matin työtunnit ovat lisääntyneet selvästi. Kuitenkin Matin työtunnit ovat hieman pienempiä koko projektin ajan kuin muiden ryhmän jäsenten.

Kuva 10. Matin ajankäyttö viikottain. Mika

Kuvassa 11 on esitetty Mikan ajankäytön jakautuminen tehtävittäin projektin aikana. Mikalla kului paljon aikaa vaatimusmäärittelyn kirjoittamiseen, joka näkyy dokumentoinnin, dokumenttien kirjoitusasun ja vaatimusmäärittelyn suurena osuutena.

Kuva 11. Mikan ajankäyttö tehtävittäin.

Kuvassa 12 on esitetty Mikan ajankäyttö viikottain. Mikan ajankäyttö projektin alussa oli hieman muita vähäisempää. Tämä johtui Mikan suorittamista muista kursseista. Toteutusvaiheen alkaessa työtunnit lähes kaksinkertaistuivat.

Kuva 12. Mikan ajankäyttö viikottain. Timo

Kuvassa 13 on esitetty Timon ajankäytön jakautuminen tehtävittäin projektissa. Timo panosti paljon käyttöliittymän toteuttamiseen. Tämä näkyy suurempana ohjelmoinnin osuutena kuin muilla.

Kuva 13. Timon ajankäyttö tehtävittäin.

Kuvassa 14 on esitetty Timon ajankäyttö viikottain. Timon ajankäyttö projektin alussa oli hyvin tasaista. Toteutusvaiheen alussa työtunnit lisääntyivät hieman. Viikon 13 notkahdus selittyy pääsiäislomalla.

Kuva 14. Timon ajankäyttö viikottain. Riskien arviointi ja hallinta

Luvussa käsitellään projektisuunnitelmassa määriteltyjä riskejä, niiden toteutumista ja toimia riskien vaikutusten minimoimiseksi.

Riskitaulukko

Taulukossa 3 on kuvattu projektiin liittyviä riskejä sekä niiden toteutuminen ja vaikutukset projektiin. Projektissa toteutuneet riskit ja niiden vaikutukset on korostettu taulukossa. Taulukossa on myös toteutumistodennäköisyydet, jotka määriteltiin SHAMAN-projektin projektisuunnitelmassa. Riskit on jaettu toteutumistodennäköisyyden ja vaikutuksen osalta luokkiin ei lainkaan, pieni, keskinkertainen ja suuri.

Riski	Toteutui	Vaikutus	Todennäköisyys
Henkilöihin liittyvät riskit			
Jäsenten kokemattomuus	Kyllä	Pieni	Keskinkertainen
Sairastumiset ja muut menot	Kyllä	Pieni	Keskinkertainen
Tiedotuksen ja viestinnän riskit	Ei	Keskinkertainen	Keskinkertainen
Ohjaajien ja tilaajan edustajien kiireet	Ei	Pieni	Keskinkertainen
Projektiryhmän koon pienentyminen	Ei	-	Pieni
Aihealueen ja tekniset riskit			
Aihealueen laajuus	Kyllä	Keskinkertainen	Keskinkertainen
Nykyisen järjestelmän heikkouksia siirtyy uuteen järjestelmään	Ei	-	Pieni
Tietoturvariskit	Ei	-	Keskinkertainen
Tietoturvariskit kehitysvaiheessa	Ei	-	Ei lainkaan
Toteutustyökaluista johtuvat riskit	Pieni	Keskinkertainen	Pieni

Taulukko 4. Projektin riskit ja niiden toteutumistodennäköisyys.

Henkilöihin liittyvät riskit

Projektin suunnittelu oli hyvin haastava ja ryhmän jäsenten kokemattomuus vaikutti hieman projektin suunnittelussa. Varsinkin työnjakoa koskevat suunnitelmat muuttuivat projektin myötä useaan otteeseen. Töitä pyrittiin jakamaan kaikkien jäsenten kesken mahdollisimman tasaisesti ja ryhmän jäsenten kokemuksen mukaan. Yleisesti kokemattomuus ei havaittavasti vaikuttanut projektin etenemiseen ja vaatimukset saatiin täytettyä.

Ryhmässä esiintyi hieman sairastelua projektin aikana, mutta se ei haitannut projektin etenemistä. Suurempi haitta oli joidenkin projektin jäsenten suorittamat kurssit sovellusprojektin aikana. Tästä syystä joillekin jäsenille kertyi vähemmän tunteja kuin toisille. Riskiä oli hankala hallinnoida, sillä kursseille kulunut aika oli suoraan pois projektin ajasta. Aikaa oli hankala korvata ilman, että ryhmän jäsenet olisivat tehneet liian pitkiä päiviä. Kokonaisuudessaan jäsenten menot eivät suuremmin haitanneet projektin etenemistä ja työt saatiin hoidettua.

Ryhmän sisällä tapahtuvaa tiedonkulun ongelmia ei havaittu projektin aikana. Joissakin suunnittelun vaiheessa jokainen ryhmän jäsen suunnitteli oman alueensa toteutusta. Tällöin muut ryhmän jäsenet olivat hetkellisesti tietämättömiä suunnitelmista, mutta viimeistään toteutusvaiheessa kaikilla oli suunnitelmat selvillä.

Tilaajan edustajia ja teknistä ohjaajaa pyrittiin käyttämään mahdollisimman paljon ongelmatilanteita ratkottaessa. Projektin aikana vain muutamat ongelmat hidastivat projektia, mutta ne saatiin ratkaistua muutaman päivän sisällä. Tämä tapahtui usein teknisen ohjaajan tietämyksen avulla.

Ohjaajilla ja tilaajilla oli varmasti kiireitä projektin aikana, mutta ne eivät juurikaan vaikuttaneet projektin toteutumiseen. Kaikkiin ongelmiin, joihin tiedusteltiin ratkaisua tilaajilta tai ohjaajilta, saatiin vastaus saman päivän sisällä. Tätä helpotti tilaajan edustajien tietämys Perl-ohjelmoinnista, joten ongelmiin saatiin vastauksia myös heiltä.

Projektin alussa oli mahdollista, että projektiryhmän koko saattaisi pienentyä projektin aikana. Onneksi tätä ei tapahtunut ja projekti saatiin vietyä päätökseen koko ryhmän voimin.

Aihealueeseen liittyvät ja tekniset riskit

Projektia suunniteltaessa oli selvää, että aihealueen laajuuden takia projektin puitteissa ei ehditä toteuttamaan kaikkia projektille asetettuja tavoitteita. Nämä koskivat lähinnä toteutusta, sillä kaikki suunnittelun tavoitteet saavutettiin. Projektin lähetessä loppua toteutusta karsittiin huomattavasti, jättämällä esimerkiksi käyttäjien tunnistus ja muokkausoikeudet toteuttamatta kokonaan.

Projektin vaatimukset olivat kohtuullisen hyvin selvillä, kun järjestelmää alettiin suunnitella. Joitakin lisävaatimuksia ilmeni, mutta ne voitiin toteuttaa muokkaamalla suunniteltua tietokantaa. Lopulta tietokanta toteutti kaikki suunnitellut vaatimukset ja myöhemmin ilmenneet lisävaatimukset. Toteutusvaiheessa ei tullut lisävaatimuksia, jotka olisivat vaikuttaneet projektiin, vaan ne päätettiin siirtää jatkokehitykseen.

Vanhan järjestelmän heikkouksia ei ilmennyt uudessa järjestelmässä. Tietokannassa varauduttiin uusien tietotyyppien lisäämiseen henkilön ja resurssien osalta, joten tulevaisuudessa niille voidaan lisätä esimerkiksi FunetEduPerson-skeeman attribuutteja. Varsinkin tietokannan suunnittelussa projektin sidosryhmiin kuuluneiden henkilöiden, kuten Pauli Kujalan, kommentit suunnitelmista olivat todella hyödyllisiä.

Ajanpuutteen takia sovelluksen tietoturvaan ei ehditty panostamaan. Tästä johtuen sovellukseen on saattanut jäädä ominaisuuksia, jotka mahdollistavat kolmannen osapuolen pääsyn tarkastelemaan käyttäjien henkilötietoja. Tietoturvaan tullaan kuitenkin panostamaan projektin jatkokehityksessä.

Sovelluksen toteutuksessa käytetty Perl-ohjelmointikieli oli koko ryhmälle entuudestaan tuntematon. Tämä aiheutti toteutusvaiheen alussa muutamia ongelmia, jotka johtuivat Perl-kielen tavasta käsitellä olioiden attribuutteja. Ryhmä luuli attribuuttien määrittelemisen tapahtuvan samalla tavalla kuin muissakin oliokielissä. Tämä johti attribuuttien määrittelemiseen siten, että attribuutit olivat samat jokaiselle olion ilmentymälle. Tämä kuitenkin saatiin muutaman päivän pohdinnan jälkeen toimimaan Lassi Paavolaisen avustuksella. Perl-perehdytyksessä olisi voitu käsitellä tarkemmin Perlin olioita, jolloin tätä ongelmaa ei välttämättä olisi tapahtunut. Ongelma ei pahemmin haitannut projektin etenemistä ja olion globaalit attribuutit helpottivat erään toisen toiminnon toteuttamista.

Projektin käytänteet

Luvussa tarkastellaan projektiin liittyviä käytänteitä ja niiden onnistumista.

Dokumentointi

Ryhmä kirjoitti projektin dokumentoinnin OpenOfficella, sillä ryhmällä oli käytössään kaksi Linux-konetta. Projektin alussa joitakin dokumentteja kirjoitettiin Wordillä ja muokattiin OpenOfficella, jolloin huomattiin kyseisten ohjelmien yhteensopimattomuus tyylien osalta. Asiasta viisastuneena loput dokumentit kirjoitettiin suosiolla OpenOffice-muodossa. Tätä tuki myös tilaajan toivomus saada dokumentit OpenOffice-muodossa. Yleisenä toiveena oli, että sähköpostilistalle lähetettävät pöytäkirjat ja esityslistat liitetään osaksi sähköpostiviestiä ASCII-muodossa. Ryhmä tallensi kaikki laatimansa dokumentit PDF-muodossa verkkosivuille, joilta löytyvät myös OpenOffice- ja ASCII-versiot.

Projektin lopussa huomattiin, että ajankäyttöraportteja olisi pitänyt muokata vain Windows-koneiden Excel-ohjelmalla, sillä OpenOffice ei jostain syystä ymmärtänyt käsitellä tunteja aikana, vaan teki niistä desimaalilukuja. Ajankäytön raportoinnissa suurta etua oli Petri Heinosen toteuttamista Excel-pohjaisista ajankäyttöraporteista, jotka osasivat piirtää automaattisesti graafit projektin ajankäytöstä.

Excelin graafien ulkoasun selkeyttämisessä kiitämme Konttori-projektia, jonka projektipäällikkö kehitteli korjauskertoimet Excelin ajankäytön jakaumakaavioon, joiden ansiosta pystyakselin väliksi saatiin tasatunnit (katso kuvat 6, 8, 10, 12 ja 14).

Kokoukset

SHAMAN-projektin ollessa suunnittelupainotteinen jouduttiin pitämään useita erilaisia kokouksia. Normaalien viikkopalaverien lisäksi pidettiin kaksi työpajatyylistä palaveria, joihin oli kokoontunut useita eri järjestelmien asiantuntijoita pohtimaan uuden järjestelmän vaatimuksia ja toiminnallisuutta.

Viikkopalavereja pidettiin lähes joka viikko. Vain helatorstaina viikkopalaveri jätettiin pitämättä loman takia. Jokainen ryhmän jäsen toimi vuorollaan kokouksen puheenjohtajana ja kaksi muuta sihteereinä. Kokouksen puheenjohtaja valmisteli kokouksen ja lähetti esityslistan kokousta edeltävänä päivänä. Ryhmä pyrki nauhoittamaan jokaisen palaverin, mutta tallentimien toimimattomuus pilasi kuitenkin joitakin nauhoituksia. Nauhoitteista oli hyötyä pöytäkirjaa kirjoitettaessa, jos sihteerit olivat unohtaneet kirjata jonkin asian. Kokousten pöytäkirjat pyrittiin kirjoittamaan ja lähettämään projektin sähköpostilistalle seuraavana päivänä.

Työpajoista saatiin paljon uusia vaatimuksia ja ne auttoivat ryhmää saamaan kokonaiskuvan uudesta järjestelmästä. Koska jokainen osallistuja yritti ajaa oman järjestelmänsä etua, tuli esille myös paljon vaatimuksia, jotka koskivat vain tiettyä järjestelmää. Nämä vaatimukset eivät välttämättä olleet ajankohtaisia tai mielekkäitä toteuttaa projektin puitteissa. Aluksi ryhmä koki nämä vaatimukset ja niiden esittäjät häiritseviksi tekijöiksi. Myöhemmin kuitenkin pystyimme sanomaan, että tietokantamme toteuttaa myös nämä vaatimukset, vaikkei niitä toteutettukaan järjestelmään tämän projektin puitteissa.

Erillinen tietokantapalaveri järjestettiin Korppi-kehittäjä Pauli Kujalan kanssa, jolla on paljon kokemusta tietokantojen kehittämisestä ja niiden optimoinnista. Ryhmä koki tämän palaverin todella antoisaksi ja sähköpostilistalle lähetetyt Kujalan ehdotukset koskien tietokantaa olivat rakentavia. Jukka-Pekka Santanen ehdotti omaa näkemystään tietokannan History- ja Pending-taulujen rakenteesta, mutta se hylättiin, koska yhteen tauluun olisi tullut liikaa rivejä.

Tiedottaminen

Tiedottaminen ryhmän sisällä sujui pääsääntöisesti hyvin. Ryhmän jäsenet olivat selvillä toistensa tekemisistä ja projektipäällikön oli helppo seurata töiden edistymistä. Ainoastaan suunnitteluvaiheessa ryhmän jäsenten suunnitellessa eri asioita, osa ryhmästä ei ollut täysin selvillä toisten suunnitelmista. Tämä ei kuitenkaan kokonaisuutena haitannut suunnittelua.

Tiedottaminen tilaajille ja muulle projektiorganisaatiolle hoidettiin pääsääntöisesti sähköpostilistan välityksellä. Tilaajan edustajalla oli myös pääsy ryhmän CVS-hakemistoon, joten hän pystyi seuraamaan työn edistymistä ilman, että ryhmä tiedotti siitä erikseen.

Koska tilaajan edustajista Tero Toivosella oli paljon kokemusta sovellusten ja tietokantojen suunnittelusta, pyrittiin häneltä ja tekniseltä ohjaajalta kysymään neuvoa ongelmiin mahdollisimman nopeasti. Koska tilaajan edustajilla ja ohjaajilla oli paljon kiireitä, huomattiin sähköposti tehokkaimmaksi viestintävälineeksi.

Tiedostot ja hakemistot

Projektilla on käytössään kaksi yhteistä verkkolevyä. Niiden hakemistot nimettiin yhdenmukaisesti ja kuvaavasti, jolloin jokainen ryhmän jäsen löysi helposti haluamansa dokumentit. Linux-koneissa oli luotu hakemistot shaman ja shamanwww projektin hakemistoille, kun Windows-koneissa shaman-hakemisto on S-asemalla.

Shaman-hakemistoissa käytettiin dokumenttien ja muiden tiedostojen luokittelussa seuraavaa hakemistorakennetta:

Ajankaytto	sisälsi ajankäyttöraportit ja -kaaviot.

Dokumentit	sisälsi valmiit dokumentit. Hakemiston alta löytyivät hakemistot kullekin dokumenttityypille.

Esitelmat	sisälsi esitelmiin liittyvän materiaalin. Jokaisen esitelmän materiaali sijoitettiin omaan alihakemistoonsa.

Lahdekoodi	sisälsi sovelluksen lähdekoodit.

Muuta	sisälsi muuta materiaalia, kuten SHAMAN-logon.

Ohjeet	sisälsi sovelluksen asennus- ja käyttöohjeet.

Palaverit	sisälsi palaverien ja työpajojen esityslistat ja pöytäkirjat.

Sahkopostit	sisälsi projektin sähköpostilistalle lähetetyt sähköpostit.

Tallenteet	sisälsi palavereissa nauhoitetut tallenteet. Hakemiston alta löytyvät palaverien päivämäärän mukaan nimetyt hakemistot.

Tulosta	sisälsi Linuxista tulostetut dokumentit. Hakemistoon oli luotu skriptit tulosta ja pdf, jotka hoitavat tulostuksen joko kirjoittimelle tai pdf-tiedostoksi.

Vaiheessa	sisälsi keskeneräiset työt. Hakemiston alta löytyivät hakemistot eri tyyppisille dokumenteille sekä jokaiselle ryhmän jäsenelle oma kansio väliaikaisten tiedostojen tallentamiseen.

Tiedostot pyrittiin nimeämään mahdollisimman selkeästi. Tiedoston nimissä ilmoitettiin tapahtuman päivämäärä, jolloin oikean pöytäkirjan löytäminen helpottui.

Projektin loppupuolella ryhmä siirtyi käyttämään kokonaan CVS-versionhallintaa, jolloin verkkolevyn käyttö lopetettiin lähes kokonaan. Verkkolevylle kerättiin vain keskeneräisiä tiedostoja ja muissa dokumenteissa tarvittuja tiedostoja.

CVS-hakemistorakenne

Projektiryhmä käytti lähdekoodien ja dokumenttien versioiden hallintaa CVS-järjestelmää, joten ko. tiedostoista löytyy koko versiohistoria ja muutokset CVS-palvelimelta. CVS myös ennaltaehkäisee dokumentteja muokatessa sattuvia virheitä. Dokumenteista tallennettiin vain muokattavat versiot, esimerkiksi OpenOffice-muodossa olevat tiedostot.

CVS-hakemistorakenne noudatti seuraavaa mallia:

dokumentit/projektisuunnitelma

dokumentit/projektiraportti

dokumentit/vaatimusmaarittely

dokumentit/sovellussuunnitelma

dokumentit/esityslistat

dokumentit/poytakirjat

dokumentit/sopimukset

koodi/data

koodi/interface

koodi/system

Testaus

Rajallisen ajan takia sovelluksen laajamittaista testausta ei pystytty suorittamaan. Ajanpuutteen takia sovelluksen testauksesta ei laadittu testaussuunnitelmaa, vaan järjestelmällinen testaus sovittiin jatkokehitykseen.

Moduulien toimintaa testattiin yksitellen käyttämällä testiskriptejä, jotka käyttivät moduulien tarjoamia palveluita. Käyttöliittymää toteutettaessa moduulien toimintaa voitiin testata, mutta järjestelmällinen testaus sovittiin jatkokehitykseen.

Moduulien funktioiden syötteitä ei testattu juuri ollenkaan ja tämä aiheuttaa varsinkin Perlin tapauksessa varmasti virheitä sovelluksen toiminnassa. Perl-kielessä ei ole vahvaa tyypitystä, vaan kaikki muuttujat voivat sisältää minkä tyyppistä tietoa tahansa.

Suunnitelmissa mainittua lähdekoodin tarkastusta muilla projektin jäsenillä ei ehditty suorittaa, vaan jokainen vastasi oman koodinsa toiminnasta. Tekninen ohjaaja tarkasti lähdekoodin projektin lopussa ja löysikin monia kohtia, jotka kaipaavat korjausta. Suurimmat virheet korjattiin ennen projektin loppua, mutta suurin osa siirrettiin jatkokehitykseen.

Myöskään testausta keksityillä siirtotiedostoilla ei ehditty testaamaan, sillä sovelluksen toteutus oli näiltä osin projektin lopussa vielä hyvin keskeneräinen.

Käyttöliittymän kehityksessä käytettiin testaukseen pääasiassa Internet Explorer -selainta, mutta aika-ajoin käyttöliittymää testattiin myös Operalla ja FireFoxilla. Käyttöliittymä ei sisällä selainkohtaisia ratkaisuja, joten se toimii kaikilla selaimilla. Ainoastaan ulkoasu voi hieman vaihdella selaimesta riippuen. Käyttöliittymän hiominen on myös sovittu jatkokehitykseen.

Projektin jäsenten kokemukset

Luvussa jokainen ryhmän jäsen kuvaa omia kokemuksiaan sovellusprojektista.

Marko

Sovellusprojekti vastasi hyvin pitkälle niitä kuvitelmia, mitä minulla oli ennen projektin alkua. Neljä ihmistä istuisivat ahtaassa ja kuumassa huoneessa sekä viettäisivät aikaa yliopistolla enemmän aikaa kuin tähän asti yhteensä.

Ennen projektia olimme muutamien kaverien kanssa täyttäneet Korpin kyselylomakkeeseen toistemme nimet, jotta pääsisimme samaan ryhmään. Tuolloin ajattelimme, että projektin läpivienti olisi helpompaa, kun samassa ryhmässä olisi ennestään tuttuja henkilöitä. Ensimmäisellä projektiluennolla huomasimme tulleemme huijatuksi ja ryhmät oli muodostettu niin, että ennestään tuttuja henkilöitä ei olisi samassa ryhmässä.

Projektin edetessä huomasimme, että ennestään tuttujen erottaminen oli pääasiassa hyvä asia. Projektin alussa joutui tutustumaan jokaiseen ryhmän jäseneen erikseen, eikä ryhmän sisälle syntynyt mitään pienempiä ryhmiä, joiden jäsenet olisivat tunteneet toisensa paremmin.

Projektin puitteissa järjestettiin keilaustapahtuma, jossa oli tarkoituksena oppia tuntemaan muita ryhmän jäseniä. Tämä oli mielestäni hyvä tilaisuus, mutta sen ajankohta olisi ehkä pitänyt olla hieman myöhemmin, kunnes ryhmä oli ensin itsekseen tutustunut toisiinsa. Mielestäni tällöin tilaisuuden vaikutus olisi ollut parempi.

Projektiryhmä koostui pääasiassa samankaltaisista ja -henkisistä ihmisistä. Yleinen ilmapiiri oli rento, eikä kukaan yrittänyt olla toista parempi tai määräilevä. Ryhmällä ei ollut ongelmia kommunikoidessaan toistensa tai tilaajien edustajien kanssa. Yleisesti olimme tyytyväisiä ryhmän rakenteesta. Epäilimme samoihin tuloksiin pääsemisestä, jos olisimme olleet osallisena muissa ryhmissä.

Projektina SHAMAN-projekti oli haastava ja ryhmä sai kohtuullisen vapaat kädet suunnitellessaan järjestelmää. Alussa vain tuntui, ettei aika riitä ollenkaan toteuttamiseen, vaan projektin tulokset sisältävät pelkkiä dokumentteja. Onneksi näin ei käynyt ja jokaisen jäsenen sisällä asunut pieni koodari pääsi myös toteuttamaan järjestelmää.

Itse tunsin, että projektissa oli sopivassa suhteessa määrittelyä, suunnittelua ja toteutusta. Toteutusvaihe ei asettanut paineita, sillä alusta asti tiedettiin projektissa toteutettavan vain prototyypin. Näin suunnittelusta ei tarvinnut luistaa. Myös tieto projektin jatkumisesta vähensi paineita saada täysin toimiva järjestelmä. Tämä myös vähensi hätäisesti tehdyn koodin osuutta, jota olisi kiireessä voinut syntyä.

Matti

Minulla ei juurikaan ollut ennakko-odotuksia sovellusprojektista. Projektin alussa mietitytti, miten tulen muiden ryhmän jäsenten kanssa toimeen. Jäsenet muodostivat kuitenkin melko nopeasti toimivan ryhmän.

Projektiryhmän suhteet projektin sidosryhmiin muodostuivat nekin nopeasti toimiviksi. Sidosryhmien ja projektiryhmän välinen toimiva kommunikaatio muodosti hyvän pohjan vaatimuksien määrittelylle ja järjestelmän suunnittelulle.

Projektin aihealue oli laaja ja järjestelmän kehittäminen aloitettiin ”puhtaalta pöydältä”, vaatimuksien määrittelystä. Toisaalta tämä oli hyvästä oppiessamme, miten ohjelmistoprojekti lähtee alkuun nollapisteestä ja kuinka vaatimusten määrittelystä edetään suunnittelun kautta toteutukseen. Toisaalta valmiille pohjalle jatkavassa projektissa olisi oppinut aiempiin työn tuloksiin tutustumisen ja toisen tekemän koodin jatkokehittämisen, mistä olisi varmasti ollut hyötyä mahdollisissa työelämän ohjelmistonkehitystehtävissä.

Aihealue tuntui projektin alussa melkeinpä ylivoimaisen laajalta. Mielessä kävi, saataisiinko projektin aikana tuotettua riviäkään koodia, vai jäisikö projekti pelkästään vaatimusten määrittelyyn. Määrittelyn ja suunnittelun sujuvuus yllätti kuitenkin positiivisesti ja järjestelmän suunnitelmat saatiin hyvissä ajoin niin pitkälle, että pääsimme toteuttamaan järjestelmää. Suunnittelu onnistui kohtalaisesti, joten toteutusvaiheessa ei ilmennyt tarvetta ratkaisevasti muuttaa suunnitelmia. Järjestelmän kehitys saatiin projektin aikana mielestäni riittävän pitkälle ja muutoinkin pitäisin projektia kaikin puolin onnistuneena.

Mika

Sovellusprojektin alkuvaiheessa oli hieman ristiriitaisia ajatuksia sovellusprojektia kohtaan. Tapahtuman ensikertaisuus toi hieman epävarmuutta ja varsinkin projektin käyntiinlähtö tuntui hitaalta, kun ei ollut kokemuksen tuomaa tietoa siitä, mitä pitäisi tehdä ja millä tavalla. Alku kuitenkin lähti käyntiin omalla painollaan ja omaksuin ryhmän työskentelytavat melko nopeasti.

Palaverit olivat minulle täysin uusi kokemus. Ne kuitenkin olivat lähes sellaisia kuin oletin. Sihteerinä oleminen ajautti joskus ajatukset liikaa pelkkään kirjoittamiseen. Enkä osannut aina aina ajatella muiden ehdotuksia tavalla, jolla olisi osannut kommentoida niiden hyviä tai huonoja puolia ja esittää omia mielipiteitä. Aina en kirjoittanutkaan aivan kaikkea, ehkä jopa tärkeääkin asiaa paperille, vaan luotin mp3-tallentimeen, josta voisi jälkikäteen varmistaa unohtuneet asiat.

Kokemusta tuli paljon lisää myös dokumenttien kirjoittamisesta. Tähän asti muut kirjoittamani kurssien harjoitustehtävät ovat olleet paljon suppeampia, eikä niihin ole tarvinnut käyttää niin paljon aikaa. Kieliopin ja kirjoitustyylin korjaamiseen täytyikin panostaa suuresti projektin aikana, mutta se antoi varmasti kokemusta jatkossa parempien dokumenttien kirjoittamiseen.

Projektiryhmän kommunikaatio onnistui mielestäni hyvin. Samassa työtilassa työskenteleminen mahdollisti helpon viestinnän ja pysymisen ajan tasalla. Myös ajatuksien esittäminen ja suunnittelu oli yksinkertaista viestinnän osalta, kun ryhmän jäsenet olivat aina vieressä. Ryhmän yhteishenki pysyi tätä kautta tiiviinä, ja ryhmän jäsenet tulivat toistensa kanssa erinomaisesti toimeen.

Työn jakautuminen ryhmän kesken oli tasaista. Pieniä eroja jäsenten panostamisessa oli havaittavissa projektin eri vaiheissa, muttei se häiritsevästi haitannut. Joskus itselläkin tuntui olevan huono päivä, jolloin oli vaikea keskittyä työn tekemiseen. Poikkeuksellisesti ryhmässämme oli jäsen, jonka täytyi lopettaa työpäivä viimeistään kello neljä iltapäivällä, joten yritimme kaikki lopettaa työnpäivän samaan aikaan ajankäytön tasaamiseksi. Aina se ei kuitenkaan onnistunut töiden paljouden vuoksi.

Kokonaisuudessaan sovellusprojekti on opettanut paljon uusia työtapoja ja on mielestäni erittäin hyödyllinen opiskelujen aikana. Ensimmäistä kertaa tuntui todella, että muilla kursseilla opittuja asioita pääsi täysin hyödyntämään. Samalla pystyi tarkkailemaan itseään ja omia vahvuuksia ja heikkouksia.

Timo

Odotukset sovellusprojektista olivat korkealla. Dokumenttien hiomista, pahaa kahvia ja myöhästynyt kesäloman aloitus. Eivätkä odotukset juurikaan pettäneet.

Projektin alkupuolella tuntui, että käytettävä aika menee kaikkeen muuhun paitsi itse olennaiseen. Palaverit, pöytäkirjat ja kokouskutsut veivät ajan. Alkutotuttelun jälkeen jonkinlainen rutiini alkoi kuitenkin kehittyä ja palavereihin liittyvä ajankäyttö väheni.

Projektin keskittyminen vaatimusmäärittelyyn ja suunnitteluun oli opettavaista. Oli virkistävää saada uusi näkökulma suunnitteluun ja ohjelmointiin käytetyn ajan suhteeseen.

Suunnitteluun käytetty aika ei välttämättä ole pelkästään pois ohjelmoinnista, vaan myös ohjelmointia helpottava ja tukeva tekijä.

Projektityöskentely aiemmin tuntemattomien henkilöiden kanssa sujui alkutotuttelun jälkeen luontevasti, mistä voi kiittää hyvää sisäistä ilmapiiriä. Kommunikointi ja mielipiteiden vaihto onnistui mutkattomasti niin projektiryhmän, ohjaajien kuin tilaajan edustajienkin kanssa.

Negatiivisin projektista esille tuleva liittyy ajankäyttöön. Projektiin menee koko kevätlukukausi ja muiden opintojen suorittaminen samanaikaisesti on hankalaa. Muihin yliopiston kursseihin verrattuna projektista saatavat opintoviikot ovat työläitä. Lisäksi jos vain harvat kevään ryhmät saavat kevään projektin päätökseen toukokuun aikana, voisi olla syytä pohtia, pitäisikö projektin ajankäyttöä miettiä uudelleen kurssin pitäjien taholta.

Kokonaisuudessaan sovellusprojekti antoi muita yliopiston kursseja läheisemmän näkökulman työelämään ja erityisesti projektityöskentelyyn. Konkreettista oppia sain ainakin dokumenttien kirjoitukseen, tietokantojen suunnitteluun ja Perl-kieleen.

Yhteenveto

Projekti oli ryhmälle sopivan haastava ja monipuolinen. Tilaaja antoi ryhmälle lähes vapaat kädet suunnitella uutta SHAMAN-järjestelmää. Projekti sisälsi sopivasti määrittelyä, suunnittelua ja toteutusta. Tämän takia ryhmän motivaatio ja sitoutuminen projektiin pysyivät korkealla koko projektin ajan.

Ryhmä tuli hyvin toimeen keskenään ja tilaajien kanssa, eikä projektia haittaavia ristiriitoja ilmennyt. Yhteydenpito tilaajien kanssa sujui mallikkaasti ja ideoita vaihdettiin puolin ja toisin.

Projekti vietiin läpi kunnialla, vaikka ajanpuutteen takia sovelluksesta karsittiin paljon ominaisuuksia. Projektin aikataulu ei vastannut suunniteltua, mutta tilaaja oli tyytyväinen projektin etenemiseen ja lopputuloksiin.

Suunniteltu tehtävienjako ei vastannut toteutunutta, sillä eri tehtävien toteuttamiseen varattu aika ei vastannut todellisuutta. Tämän takia tehtäviä organisoitiin uudelleen useita kertoja. Tehtävät jaettiin kuitenkin kohtuullisen tasaisesti projektiryhmän kesken.

Kaikenkaikkiaan projekti onnistui hyvin määrittelyn ja suunnittelun osalta, sekä tietokannan toteutuksessa. Järjestelmän toteutus jäi kesken aikapulan takia, mutta silti ryhmä ehti toteuttaa sitä yllättävän pitkälle.

Lähteet

Andersson Marko, Rinkinen Mika, Törmä Matti ja Valonen Timo, ”SHAMAN-projekti, projektisuunnitelma”, saatavilla PDF-muodossa osoitteesta <URL: http://sovellusprojektit.it.jyu.fi/shaman/dokumentit/projektisuunnitelma/projektisuunnitelma_31.3.2005.pdf>, Jyväskylän yliopisto, tietotekniikan laitos, 1.4.2005.

Andersson Marko, Rinkinen Mika, Törmä Matti ja Valonen Timo, ”SHAMAN-projekti, vaatimusmäärittely”, saatavilla PDF-muodossa osoitteesta <URL: http://sovellusprojektit.it.jyu.fi/shaman/dokumentit/vaatimusmaar/16.05.2005_Vaatimusmaarittely.pdf>, Jyväskylän yliopisto, tietotekniikan laitos, 16.5.2005.

Christiansen Tom and Torkington Nathan, ”Perl Cookbook”, O'Reilly & Associates, Inc., Sebastopol, California, 2003.

Christiansen Tom, Wall Larry and Schwartz Randal L, ”Programming Perl”, O'Reilly & Associates, Inc., Sebastopol, California, 1996.

Hietaniemi Jarkko, ”Comprehensive Perl Archive Network” <URL: http://www.cpan.org/>, CPAN, 23.5.2005.

Lahtonen Tommi, ”SQL”, Docendo Finland Oy, Jyväskylä, 2002.

Santanen Jukka-Pekka, ”Opinnäytteiden kirjoittaminen, lyhyt oppimäärä”, saatavilla HTML-muodossa osoitteesta <URL: http://www.mit.jyu.fi/santanen/info/kirjoittamisesta.html>, Jyväskylän yliopisto, tietotekniikan laitos, 23.8.2000.

Santanen Jukka-Pekka, ”Tietotekniikan Sovellusprojektien ohje”, saatavilla HTML-muodossa osoitteesta <URL: http://www.mit.jyu.fi/palvelut/sovellusprojektit/ projohje.html>, Jyväskylän yliopisto, tietotekniikan laitos, 27.1.2005.

Toivonen Tero, ”AMAN-järjestelmän kaaviot”, saatavilla PNG-muodossa osoitteesta <URL: http://www.cc.jyu.fi/~tptoivon/aman/>, Jyväskylän yliopisto, ATK-keskus, 2.3.2005.

Jyväskylän yliopisto

Tietotekniikan laitos

I

SHAMAN-projekti

Projektisuunnitelma

Administrator

2005-02-08T10:47:00