LOPPURAPORTTI Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen
i Sisällysluettelo DOKUMENTIN VERSIOT 2 VIITTAUKSET MUIHIN DOKUMENTTEIHIN 3 1. JOHDANTO 4 2. PROJEKTIN ETENEMINEN 5 3. LOPPUTULOKSET 7 4. PROJEKTITYÖSKENTELY 9 5. JÄLKILASKELMAT 11 6. OPPIMINEN 14 7. TESTIEN HYVÄKSYNTÄ 16 8. KURSSIPALAUTE 17
2(16) Dokumentin versiot Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt 1.0 Antti Tuomaala 22.4.2001 Alkuperäinen versio Luonnos 1 1.1 Antti Tuomaala 23.4.2001 Tuntimäärien arvioinnin tarkennus, oppiminen. Harri Kauhanen
3(16) Viittaukset muihin dokumentteihin # Dokumentin nimi ja versio Selitys 1 Tutkimusraportti Tutkimus, jota tehtiin projektin edetessä. 2 jatkokehitys Miten systeemiä voitaisiin jatkokehittää. 3 Projektisuunnitelma Projektin alkuperäinen suunnitelma. 4 Editymisraportit: Jokaisen vaiheen lopussa kirjoitettu raportti. Edistymisraportti PS Edistymisraportti T1 Edistymisraportti T2 Edistymisraportti T3 Edistymisraportti T4 5 Laatukatselmus LU Luovutukseen liittyvä laatukatselmus. 6 Hallintatyökalun käyttöohje 7 Portaalin käyttöohje
4(16) 1. Johdanto Projektin alkuperäisenä tavoitteena oli lähteä ratkaisemaan ongelmaa, miten muodostaa suuresta joukosta käyttäjiä virtuaaliyhteisöjä. Koska käsite ei ole aivan yksiselitteinen, on asiaa pohdittu tarkemmin dokumentissa tutkimusraportti [1]. Dokumentti antaa yleiskäsityksen minkä tyyppistä ongelmaa ollaan ratkaisemassa ja selventää käsitteitä, joita tässä dokumentissa ei erikseen selitetä. Ongelmaa varten päätettiin rakentaa ohjelmisto, jonka avulla tällaisia virtuaaliyhteisöjä voitaisiin muodostaa. Ohjelmiston tulisi olla sellainen, että kehitystyötä voitaisiin jatkaa itse varsinaisen projektin päätyttyä. Valmiin ohjelmapakettiin tuli sisältyä ohjelmiston hallintatyökalu ja ohjelmiston demoamista varten web-portaali. Tavallaan projektin tarkoituksena oli tehdä tutkimusta, pystyykö virtuaalihteisöjä ylipäätään muodostamaan järkevästi ja jos pystyy, niin miten ne muodostettaisiin. Koska projekti toteutettiin TKK:n kurssina, jouduttiin noudattamaan myös kurssin antamia aikatauluja ja vaatimuksia. Projektin asiakkaana oli Comptel Oyj, joka tulee myös vastaamaan ohjelman jatkokehityksestä.
5(16) 2. Projektin eteneminen Projekti eteni vaiheittain projektin suunnittelusta projektin luovutukseen, Jokaisen vaiheen lopussa on kirjoitettu edistymisraportti, jossa kuvataan tarkemmin miten projektin osio on mennyt. Dokumenteissa pohditaan ajankäyttöä, resursseja, ongelmia ja verrataan suunnitelmia tehtyihin töihin. Projektin jakautui seuraaviin osiin: Projektinsuunnittelu Toteutus 1 Toteutus 2 Toteutus 3 Toteutus 4 Luovutus Kun ensimmäisissä projektin vaiheissa maksettiin oppirahoja, niin loppuvaiheessa työskentely alkoi sujumaan paljon paremmin ja ennen kaikkea tehokkaammin. Projektin alussa ei ollut selkeää mitä edes ryhdyttäisiin tekemään. Asiakkaan ongelma tuntui todella vaikealta ja sen vangitseminen ohjelmiston muotoon vielä vaikeammalta. Projektin alkuvaiheissa ongelmia tuottivat tuntiraportointi sekä yhteiset palaverit. Tuntiraportointia ei viitsitty hoitaa ajoissa, joten projektin työmäärien seuranta ja arviointi muodostui vaikeaksi. Kokouksissa puolestaan asiat puolestaan pyrkivät ajautumaan niin sanottuun mukavaan jutusteluun. Osasyynä tähän oli se, että ei oikeastaan tiedetty mitä tultaisiin tekemään ja roolijako ei ollut aivan tarkasti jakautunut. Lisäksi alussa oli vaikeaa saada koko projektiryhmää työskentelemään yhdessä, vain osa teki töitä. Kaiken kaikkiaan voi todeta, että kevätpuolella kaikki on sujunut paljon paremmin kuin syksyllä. Kokouksissa on puhuttu asiaa ja niiden kesto on lyhentynyt. Alkuvaiheissa työmäärä jakautui melko epätasaisesti, mutta loppuvaiheessa asiaa pyrittiin korjaamaan. Asiakkaan määritteli ohjelmatyön aiheen tutkimusluontoiseksi, mutta edelleen projektiryhmän pienuuden (5 henkilöä) vuoksi resursseja ei tähän tutkimuksen tekemiseen ollut riittävästi. Kurssin tavoitteena oli toisaalta rakentaa valmis ohjelmisto annetun prosessin mukaisesti. Useissa eri projektin vaiheissa asiakkaan ja kurssin tavoitteita oli vaikea liittää yhteen. Asiakasta olisi kiinnostanut enemmän perusteellinen tutkimus, mutta kurssin vaatimusten vuoksi tätä ei yksinkertaisesti pystytty tekemään. Alkuperäisissä suunnitelmissa oli tarkoitus tehdä tutkimusta, mutta resurssipulasta johtuen kunnollinen perehtyminen on jäänyt tekemättä. Tällä hetkellä ohjelmisto antaa vain pohjan jatkokehitykselle, enemmän aiheesta dokumentissa jatkokehitys [2]. Projekti oli vaikeaa pistää liikkeelle, koska asiakkaallakaan ei ollut selkeää käsitystä mitä tulisi tehdä, vain kourallinen ideoita jotka pitäisi muuttaa ohjelmiston muotoon. Vaatimusmäärittely tehtiin asiakkaan kanssa yhteistyössä, mutta projektiryhmä sai ideoida melko vapaasti millainen ohjelmistosta tulisi.
6(16) Tarkemmin jokaisesta vaiheesta on dokumentoituna edistymisraportti. Projektin etenemiseen on otettu kantaa myös laatukatselmus LU dokumentissa [5].
7(16) 3. Lopputulokset Projektin lopputuloksena oli virtuaaliyhteisöjä muodostava ohjelmisto, jota voidaan käyttää pohjana jatkokehitystä silmällä pitäen. Ohjelmisto sisältää itse VYM koneen, joka pitää sisällään algoritmin yhteisöjen muodostamiseksi. Ohjelmisto on rakennettu sellaiseksi, että VYM kone on helppo vaihtaa uuteen versioon. Tämä tarkoittaa sitä, että yhteisöjä voidaan muodostaa erilaisilla algoritmeilla. Algoritmeista lisää tutkimusraportissa [1]. Osana järjestelmää on ohjelmistonhallinta työkalu, jonka avulla järjestelmän ylläpitäjä voi muokata erilaisia ominaisuuksia. Työkalusta lisää Halintatyökalun käyttöohjeessa [6]. Lisäksi ohjelmisto varten on rakennettu demoamistarkoitukseen web portaali. Ohjelmisto on rakennettu siten, että portaalin tilalla voisi olla vaikkapa WML sivusto. Ohjelmiston rakenne pysyi samankaltaisena koko projektin läpi, eikä projektisuunnitelmassa mainittuun muutostenhallinta suunnitelmaan tarvinnut ryhtyä missään vaiheessa projektia. Piirteiden lukumäärä rajoitettiin demossa yksinkertaisuuden vuoksi neljään, mutta ohjelmisto antaa mahdollisuuden antaa käyttäjille lisää piirteitä. Ohjelmaa ei ole testattu suurilla käyttäjämäärillä, sillä sen tarkoitus on ainoastaan pyrkiä testaamaan erilaisia algoritmeja pienillä käyttäjämäärillä. Työ onnistui vaatimusmäärittelyn pelattuna hyvin ja myös alemman prioriteetin vaatimuksia pystyttiin toteuttamaan. Asiakkaan kantilta asiaa katsottuna tutkimusta olisi pitänyt tehdä perusteellisemmin, mutta kuten edellä jo todettiin, ei se ollut kurssin puitteissa aivan mahdollista. Projektisuunnitelmassa määriteltiin asiakkaan 10 tärkeintä tavoitetta, projektin tavoite ja projektiryhmän tavoitteet. Seuraavassa pieni analyysi, miten nämä tavoitteet saavutettiin. Asiakkaan 10 tavoitetta. 1. Asiakkaalle on toimitettu tutkimusraportti ja jatkokehitysraportti. Kuten jo aikaisemminkin on jo mainittu, asiakkaan tärkeintä tavoitetta oli vaikea saattaa yhteen kurssin antamien vaatimusten kanssa. Joka tapauksessa aikataulujen sallimissa rajoissa tutkimusta pystyttiin kuitenkin hieman tekemään. 2. Palvelun voi rakentaa muuhunkin kuin webportaalin yhteyteen. 3. Itse erilaista sääntökokoelmaa ei erikseen luotu. Säännöt liittyvät lähinnä ei algoritmeihin joita on käsitelty tutkimusraportisssa. 4. Kommunikointi järjestettiin muodostetulle yhteisölle chatboardina. 5. Käyttöliittymät rakennettiin sovitun mukaisesti.
8(16) 6. Systeemin automaattista opetusta ei ole tehty. Syynä oli resurssipula. 7. Ohjelmisto pyrittiin rakentamaan mahdollisimman modulaariseksi, jotta sitä voitaisiin laajentaa tulevaisuudessa. Erilaisten VYM koneiden vaihtaminen on yksinkertaista, joka on ilmeisen tärkeä osuus modulaarisuutta. 8. Laatukriteerejä pyrittiin valvomaan koko projektin ajan. Laadunvalvonnan pääpaino sijoittui T4 ja LU vaiheisiin, jolloin pidettiin erilliset laatukatselmukset. 9. Projektiryhmän oppimisesta enemmän kappaleessa 6. 10. Projektiaikatauluista pidettiin kiinni, mutta liian usein suurin taakka jäi aina vaiheen loppuun. Projektiryhmän tavoitteisiin päästiin aika hyvin. Tärkeimpänä ollut oppiminen on ainakin täyttynyt (katso kappale 6). Ryhmä pystyi myös viemään kurssin alusta loppuun asti, samalle tarjoten asiakkaalle valmiin tuotteen. Ryhmä kokee, että asiakas olisi hyötynyt projektista huomattavasti, jos tutkimusta virtuaaliyhteisöjen muodostamiseksi olisi pystytty tekemään perusteellisemmin. Projektin tavoitteena oli löytää algoritmeja virtuaaliyhteisöjen muodostamiseksi. Näitä toki löydettiin, mutta pääpainoa ei voitu tälle antaa, koska kurssin vaatimuksena oli rakentaa valmis tuote. Koko projektin laatua on arvioitu dokumentissa laatukatselmus LU. Projekti päättyy normaalisti 27.4.2001. Loppudemossa esitellään tuote ja jolloin myös asiakkaalle luovutetaan CD levyke, joka sisältää kaiken projektiin liittyvän materiaalin, lähdekoodeista dokumentteihin.
9(16) 4. Projektityöskentely Itse projektiluontoinen työ onnistui aluksi kehnosti, koska ainakaan projektipäälliköllä ei ollut minkäänlaista kokemusta projektin vetämisestä. Alkuvaiheessa pidettiin paljon asiakaspalavereita, joissa ei oikeastaan päästy puusta pitkälle. Asiakaspalavereiden määrä putosi, kun projektin suunnittelu-vaihe saatiin päätökseen. Myös aluksi projektiryhmän sisäiset kokoukset olivat rönsyileviä ja asiassa ei tahdottu millään pysyä, koska ei oltu tietoisia mitä ylipäätään ollaan tekemässä. Projektin alkuvaiheessa meni myös aikaa erilaisten raportointityökalujen käytön opetteluun, sekä MSProject - projektinhallintaohjelmiston käyttöön. Ohjelmaa ei hirveän luonnollisesti pystynyt käyttämään, koska projektissa annettiin ensin aikataulu ja sen jälkeen työmäärä. Normaalistihan asian pitäisi olla toisinpäin. Kommunikointi ongelmia ei liiemmin ilmennyt, ainoastaan asiakkaalle tiedottaminen jäi vähäiseksi projektin loppuvaiheissa. Projektinsuunnittelu vaiheessa asiakaspalavereita oli paljon, joten asiakkaan kanssa kommunikointi sujui luontevasti näissä tilaisuuksissa. Lopussa tiedottaminen jäi vähäiseksi, koska erillistä asiakasvastaava ei ollut ja tiedottaminen jäi projektipäällikön vastuulle ja aikaa kunnolliseen tiedottamiseen ei riittänyt. Osasyynä oli myös viitseliättömyys. Asiakaspalavereita olisi voinut pitää lopussa hieman useammin, kuin kerran kuussa. Välillä tuntui, ettei asiakas varmasti tiedä missä vaiheessa projektissa edetään. Toisaalta dokumentaatio oli koko ajan sellaisessa paikassa, että asiakas pystyi siihen tutustua. Alkuvaiheissa ongelmana oli, ettei koko projektiryhmää saatu tekemään töitä ja tunnit jakautuivat melko epätasaisesti. Loppuvaiheissa projektityö alkoi koko ryhmältä sujua paremmin ja tuntejakin saatiin ainakin hieman tasatuksi ryhmän jäsenten kesken. Tuntiraportointi aiheutti pään vaivaa koko ensimmäisen projektin puolikkaan. Niin yksinkertainen ja pieni asia kuin se olikin, sitä ei viitsitty tehdä kunnolla. Työmäärien valvomista oli siis koko projektin alkuvaiheen ajan vaikea kontrolloida. Lopussa tunnit merkittiin säännöllisesti ja näin ollen työmääriä pystyttiin kontrolloimaan paremmin, joka helpotti projektipäällikön päätöksiä resurssien allokoinnissa. Erilaisten työmäärien arvioinnissa onnistuttiin melko kehnosti, mutta ainakin opittiin, että itsearviointi on vaikeaa ja aikaa menee aina suunniteltua enemmän! Jokaisen vaiheen lopussa tehty seuraavan vaiheen tarkka suunnittelu olisi pitänyt tehdä, joka vaiheessa hieman tarkemmin. Työt tuntuivat kasautuvan aina vaiheen loppuun, kun deadlineen oli enää vain pari päivää. Ainoastaan kerran päätettiin, että ryhmän sisäinen deadline on viikkoa ennen kurssin antamaa. Tämä oli onnistunut toimenpide, jota olisi pitänyt käyttää joka vaiheessa. Kun kaikki oli valmista viikkoa ennen varsinaista palautusta, jäi vielä aikaa viilailla palautukseen liittyvää aineistoa. Suurin osa ryhmäläisistä oli jokseenkin tai täysin tyytyväisiä projektin toimintatapoihin. Kurssin mukanaan tuoma ylimääräinen dokumentointi aiheutti melkoista päänvaivaa joillekin ryhmän jäsenille.
10(16) Ryhmän työskentely oli läpi projektin varsin demokraattista. Vastuualueita jaettiin suurinpiirtein ja ne tarkistettiin aina mentäessä seuraavaan vaiheeseen. Erityisesti ryhmän toimintaa koskevat päätökset pyrittiin aina tekemään ryhmän kesken, mutta myös suunnittelu osallistui kaikki ryhmäläiset.
11(16) 5. Jälkilaskelmat Alkuperäisen suunnitelman mukaan tunteja olisi projektissa käytetty yhteensä n. 1125. Henkilötyötunnin voitaisiin arvioda työnantajalle maksavan n. 150 mk tunti, mistä päästäisiin kustannusarvioon n. 170 000 mk. Yhteensä toteutuneita tunteja oli n. 1171, joka on todella lähellä alkuperäistä arviota. Kustannushinnaksi tulisi tällöin n 176 000mk Alla olevasta taulukosta selviävät suunnitellut ja toteutuneet työtunnit henkilöittäin ja vaiheittain. Korostettu on toteutunut tuntimäärä. Luvut ovat ViCa:sta. Projektin suunnittelu AT HK JP NS TM Yhteensä 60 49 45 53,5 45 41,5 20 17 20 19 190 180 Toteutus 1 27 31 19 16,5 39 25 38 9 60 26 190 108 Toteutus 2 50 75,5 50 66,5 60 60 30 44 40 19 250 265 Toteutus 3 40 29 30 64 40 32 40 40 30 40 200 205 Toteutus 4 30 27 30 100 20 44 30 33,5 30 39 150 244 Luovutus 36 29 39 51,5 34 33,5 25 30,5 24 24 150 169 Yhteensä 250 241 220 352 240 236 190 174 210 167 1125 1171 Tuntimäärät Tunnit 400 350 300 250 200 150 100 50 0 Antti(S) Antti(T) Harri(S) Harri(T) Juha(S) Juha(T) Niko(S) Niko(T) Tuomo(S) Tuomo(T) LUO T4 T3 T2 T1 PS Henkilö Kuva Tuntimäärät Kokonaisuudessa tuntimäärän arviointi on osunut melkoisen kohdalleen. Onnella on varmasti ollut osuutta, että tehty tuntimäärä on kohtuullisesti täsmännyt, sillä osissa vaiheissa tuntiarvio ei onnistunut lähellekään kohdalleen. Kun katsotaan henkilökohtaisia tuntimäärä arvioita kuvassa Tuntimäärät voidaan niiden katsoa osuneen melkein kohdalleen. Harrin tunti määrä on tosin aivan omaa luokkaansa, johtuen T4 vaiheen
12(16) koodaus osuudesta, joka osoittautui arvioitua työläämmäksi. Kuvasta voidaan myös todeta, että Niko ja Tuomo ovat aloittaneet työn teon oikeastaan vasta vaiheessa T2. Kuvassa Tunnit vaiheittain on tunnit jaettu jokaiseen vaiheeseen erikseen. Kuvasta voidaan todeta, Tunnit vaiheittain että T1 vaiheen arviointi on 300 mennyt huonosti. Toteutuneiden 250 tuntien vähyyteen 200 Suunniteltu T1 vaiheessa on 150 Toteutunut ollut myös se, ettei 100 Tiranaan ole 50 syötetty oikeita 0 koodeja, mutta PS T1 T2 T3 T4 LUO puutteellinen suunnittelu oli Vaihe selvin peruste. T4 Kuva Tunnit vaiheittain. vaiheessa suuren tunti heiton aiheutti portaalin ja varsinkin AdminToolin koodaaminen. AdminTool arvioitiin helpommaksi toteuttaa ja niinpä tunti arvio heitti todella rajusti. Lukuun ottamatta vaiheita T1 ja T4 arviointi on sujunut melko hyvin. Tunnit Prosentuaalisesti tunnit jakautuivat työlajeittaan kuvan prosentuaaliset tunnit työlajeittain. Ohjelmointi, kokoukset ja dokumentointi ovat haukanneet melkein ¾ koko projektista. Testaamisen osuus on jäänyt vain 8 prosenttiin. Prosentuaaliset osuudet työlajeittain S 7 % P 6 % T 8 % U A 2 % 5 % D 22 % O 28 % L 2 % K 20 %
13(16) Oheisesta kuvasta voi todeta, että ohjelmointiin on mennyt reilusti eniten aikaa, mutta myös dokumentoinnin pylväs on korkea. Toisaalta tämä tuntuu luonnolliselta, sillä projektiryhmä tuottikin suurenmäärän dokumentaatiota. Kokouksiin upposi paljon aikaa, mutta se oli väistämätöntä. Alussa kokouksia oli useammin ja ne kestivät pidempää. Lopussa puolestaan vähemmän ja kestoltaan ne olivat lyhyempiä. Tämä lienee osoitus kokouskäytännöiden oppimisesta ja siitä, että projekti sujuu suunnitelmien mukaan. Vaikka aluksi tuntui, ettei Tunnit työlajeittain testaamista oltu kunnollisesti 350 tehty, nousi 300 siihen käytetty tuntimäärä aina 250 sataan tuntiin. 200 150 100 50 0 A D K L O P S T U
14(16) 6. Oppiminen Seuraavassa on jokainen kuvannut lyhyesti projektin aikana oppimiaan asioita. Antti - UML notaatio - MSProject käyttöä - JavaDoc kommentointi - CVS version hallintatyökalu - Oma itsearviointi tuntimäärissä - Töiden jakaminen pienempiin palasiin - JSP / Servlet ohjelmointi - Ajan hallinta - Ohjelmistoprosessi kokonaisuutena. Harri - ohjelmistotuotannon elinkaaren konkreettinen läpikäynti - oppinut ymmärtämään, miten työmäärien arviointi ja aika-taulutus on vaikeaa - stressinsietokykyä lisää :) - laadun luonne, siis mitä kaikkea "laatu" ohjelmistoprojektissa voi tarkoittaa - vastuunottotaitoa ja itseluottamusta lisää Juha Työn tekemisestä muiden ihmisten kanssa: -hyvän kommunikoinnin ja selkeiden määrittelyjen tärkeys -inhimillisistä tekijöistä aiheutuu aina ongelmia -ryhmätyöskentely työn aiheesta: -ryhmittelyn monimutkaisuus -XML projektityöskentelystä: -ryhmän sisällä samojen menetelmien käytöstä syntyy etua pidemmän päälle -aikaa on aina vähemmmän kuin luulisi Niko Kurssilla oppi mielestäni hyvin lähinnä projektinhallintaa ja
15(16) ohjelmistotuotannon menetelmiä. Ennestään projektin vaiheistus oli jotakuinkin selvää. Työmäärästä selkeästi suurin osa meni projektihallintoon palaverien merkeissä ja runsaaseen dokumentointiin. Dokumentoinnin määrä oli ehkä hieman yllätys, koska siihen ei tosielämässä ole joutunut ihan samoissa mitoissa panostamaan. Toisaalta sen taas ymmärtää, koska kyseessä oli oppimisprosessi, jossa asiat tehdään 'by the book'. Varsinaisesti kurssin tavoitteiden ulkopuolelta tuli myös opittua jonkin verran, koska luonnollisesti aihetta () joutui opiskelemaan ja tutkimaan missä opittua voisi hyödyntää. Ohjelmistopuolella joitain pieniä osa-alueita (lähinnä javan saloja) oppi hieman lisää, mutta niiden osuus oli hyvin pieni.
16(16) 7. Testien hyväksyntä Testaus on kokonaisuudessaan hyväksytty päivämäärällä 23.4.2001. Testauksen hyväksyjinä ovat - Antti Tuomaala, projektipäällikkö - Harri Kauhanen, laatuvastaava - Niko Stenberg, testausvastaava
17(16) 8. Kurssipalaute Kaiken kaikkiaan koko projektiryhmän mielestä kurssi oli erittäin työläs ja 5 opintoviikkoa ei ole kohtuullinen korvaus. Omaan projektiimme kurssin vaatimukset eivät oikein soveltuneet, koska asiakas olisi halunnut hieman toisenlaista lähestymistapaa. Asiakas olisi halunnut, että lähdetään tekemään tutkimusta, mutta kurssilla vaadittiin tuote ja suuri määrä dokumentaatiota. Se mistä koko projektiryhmä on samaa mieltä, että paljon on opittu ja kurssi on hyödyllinen kokonaisuus.