TAVI
Tapahtumapohjaisten järjestelmien jonomallien visualisointi
Loppuraportti 1.0
10.5.2002
Sisällys
2. Projektin organisaatio ja eteneminen
Tässä dokumentissa kerrotaan projektin aikaansaannoksista ja arvioidaan projektin onnistumista. Projektin kaikki dokumentit on talletettu projektin kotihakemistoon osoitteeseen: http://www.cs.helsinki.fi/group/ohtu1k02.
Ohjaajan suosituksesta projektiryhmä päätti ottaa käyttöön Extreme Programming -prosessimallin (XP). Yksi XP:n pääperiaatteita on pariohjelmointi, ja tässä projektissa pyrkimyksenä oli työskennellä pareittain koko projektin ajan. Ohjaaja oli itse perehtynyt XP:hen, ja asiakas antoi ryhmälle luettavaksi XP:stä kirjoitetun kirjan, Kent Beck: Extreme programming explained. Nämä helpottivat prosessimallin mukaisen työskentelyn liikkeelle lähtöä.
Prosessimallin mukaisesti työ eteni kolmessa iteratiivisessa jaksossa, ja kukin jakso tuotti toimivan ohjelmaversion. Ohjaaja laati asiakkaan haluamista toiminnoista käyttäjäkertomuskortteja. Kortteja laadittiin työn edetessä ja niitä kertyi yhteensä 21 kappaletta. Korteista toteutettiin 18 kappaletta. Osa toimeksiannoista peruttiin, koska asiakkaan tarpeet muuttuivat työn aikana. Käyttäjäkertomuksista valittiin yhteistyössä asiakkaan kanssa ne, jotka ryhmä arvioi ehtivänsä toteuttaa seuraavan kolmen viikon aikana. Jokaista kolmen viikon ohjelmointijaksoa seurasi aina yhden viikon viimeistelyjakso, jonka aikana ryhmä viimeisteli tuotetta, ja ohjaaja suoritti version hyväksymistestauksen. Viimeistelyjakson aikana valittiin myös seuraavan kolmen viikon jakson aikana toteutettavat tehtävät. Projektissa onnistuttiin seuraamaan hyvin projektisuunnitelmaa - johtuen tietysti osittain suunnitelman jatkuvasta täsmentymisestä.
Projektin kokouksia pidettiin säännöllisesti joka maanantai ja torstai. Kahden ensimmäisen jakson aikana asiakas kävi kokouksessa lähes joka maanantai, jolloin ryhmällä oli mahdollisuus esittää täsmentäviä kysymyksiä asiakkaan tarpeista, ja esitellä työn etenemistä. Kolmannella jaksolla asiakas ei ehtinyt kokouksiin kolmeen viikkoon, mikä aiheutti epätietoisuutta siitä, miten tuote vastasi asiakkaan tarpeita. Projektikokousten lisäksi koko ryhmä kokoontui lähes poikkeuksetta maanantaisin ja torstaisin kuuden tunnin ajaksi toteuttamaan työtä. Tällöin koko ryhmä työskenteli samassa atk-luokassa pareittain - ja tarvittaessa pidettiin yhdessä lyhyitä suunnittelupalavereja. Pääosin tämä toimi erittäin hyvin. Pikku viivytyksiä tehokkaan työskentelyn alkuun syntyi siitä, kun yhteisinä koodauspäivinä kaikki henkilöt eivät saapuneet paikalle samanaikaisesti, vaan ajoittain työskenneltiin kolmenkin hengen ryhmissä. Osa projektin jäsenistä pääsi säännöllisesti koodaamaan myös lauantaisin. Kokousten ja yhteisten koodauskertojen ulkopuolella tiedottaminen hoidettiin sähköpostitse. Projektin aikana kertyi kaikkiaan 170 koko ryhmälle postitettua sähköpostiviestiä.
Kaksi projektikokouskertaa käytettiin koodikatselmusten (FTR) pitoon. Ensimmäisessä katselmuksessa käytiin tarkasti läpi osa koodista, ja toisella kerralla katselmoitiin lopullisen ohjelmaversion käyttöohje. Koodikatselmukset eivät kuulu XP-prosessimalliin, mutta ryhmä halusi kuitenkin pitää katselmukset vastuuhenkilön lausunnoista poiketen.
Toisen ohjelmointijakson jälkeen projekti esitteli aikaansaannoksiaan TKTL:n laitospäivillä. Projektimme oli ainoa esillä ollut ohjelmistotuotantoprojekti, koska perinteisen vesiputousmallin mukaisesti etenevät projektit eivät olleet vielä saaneet valmiiksi mitään toimivaa sovellusta. Tällä esittelyllä ryhmä sai vapautuksen toukokuisesta kaikkien ohjelmistotuotantoprojektien yhteisestä esittelytilaisuudesta.
Ohjelmassa on työkalupalkki, josta käyttäjä valitsee symbolit, joita hän haluaa lisätä piirtoalustalle. Alku- ja loppupistettä kuvaavat symbolit ovat mukana työkalupalkissa, mutta niitä ei vielä tässä versiossa voi lisätä piirtoalustalle.
Halutessaan käyttäjä voi muuttaa piirtoalustan kokoa ja taustavärejä. Lisäksi käyttäjä voi halutessaan tyhjentää koko piirtoalustan.
Ensimmäisen version toteuttamisen aikana hieman haettiin ryhmän jäsenten rooleja. Ryhmä valitsi ensimmäiselle kierrokselle liian monta korttia toteutettavaksi, koska uusien työkalujen opettelukin vei oman aikansa. Myös mm. graafisen esityksen mukaisten nuolten piirto tuotti odotettua enemmän työtä. Näistä syistä muutama ensimmäiselle kierrokselle valituista korteista jouduttiin viimeistelemään toisen kierroksen aikana. Myös testaus jäi huomattavasti suunniteltua vähäisemmäksi.
Toisen version toteuttamisen aikana ryhmätyöskentely sujui jo lähes rutiinilla ja suunnitellut toimintojen lisäykset saatiin toteutettua nopeasti. Varsinaisen koodauksen jälkeen keskityttiin ohjelmakoodin laadunparannukseen, kommentointiin ja testaukseen. Jakson lopussa oli metodeista testattu 80%.
Kolmannen version koodauksen jälkeen keskityttiin projektin loppuunsaattamiseen: ohjelmakoodin kommentointiin ja dokumentointiin.
Projektipäällikkö kokosi projektisuunnitelman, mutta eri aihepiirien vastuuhenkilöt osallistuivat omalta osaltaan dokumentin laatimiseen. Projektin kokouksissa sihteerivuoro oli kiertävä, joten kukin jäsen laati vuorollaan kokouspöytäkirjan. Käyttöohjeet ja loppuraportin laati projektipäällikkö, mutta kaikki ryhmän jäsenet osallistuivat näiden viimeistelyyn.
| Kimmo Airamaa | 200 h | |
| Esko Kupiainen | 300 h | |
| Liisa Länkä | 245 h | |
| Janne Petäjä | 161 h | |
| Heikki Tuominen | 242 h | |
| Johannes Ukkonen | 200 h | |
| Yhteensä | 1348 h | |
Projektin vastuuhenkilö osoitti projektisuunnitelmaa kohtaan hieman kritiikkiä: ei suunnitelmaan sinänsä vaan valitun prosessimallin tuottaman dokumenttimäärän niukkuuteen. Hetken aikaa projektiryhmä epäili jopa luottamuspulaa, mutta ohjaajan kannustuksella projektiryhmä pysyi vakaasti omalla tiellään. Ensimmäisen kokouksen jälkeen vastuuhenkilö ei ollut välittömästi yhteydessä projektiin.
Toteutuksen alkuvaiheessa yksikkötestauksia ei tehty niin paljoa, kuin alun perin oli tavoitteena. Tähän oli useita syitä. Ensimmäiselle kierrokselle valittiin liian paljon tehtäväkortteja toteutettavaksi. Testaustyökalun (JUnit) opetteluun ja testien laatimiseenkin meni yllättävän paljon aikaa, ja valmiissa tuotteessa käytettiin jonkin verran Javan omia, valmiiksi testattuja käyttöliittymätyökaluja. Käyttöliittymäominaisuuksien testaamiseen JUnit ei sovellu. Toisen jakson aikana testaustilanne saatiin jo varsin kattavaksi. Tähän vaikutti se, että ryhmä otti toiselle kierrokselle toteutettavaksi realistisemman määrän tehtäväkortteja, ja aikaa jäi enemmän myös testaukseen. Lisäksi ohjelmakoodissa oli paljon JUnit-testaukseen sopivaa aineistoa: jonomallien visualisointia ja rakentelua. Javan käyttöliittymätestaustyökalu olisi ollut paikallaan tämän työn testauksessa.
Ensimmäiselle kierrokselle valitut toimeksiannot olivat pääosin käyttöliittymän rakentamista. Tähän löytyy Javasta puolivalmiita työkaluja, joten valmista syntyi nopeaan tahtiin. Jokaisessa kokouksessa ryhmällä oli esittää asiakkaalle ja ohjaajalle uusia toteutettuja ominaisuuksia. Määrä ei kuitenkaan korvaa laatua, joten asiakkaan ja ohjaajan esittämien uusien piirteiden toteuttamisesta jouduttiin kieltäytymäänkin. Toisen ja kolmannen kierroksen toimeksiantojen toteutuksessa päästiin jo varsinaiseen ongelmanratkaisuun: tehtävät eivät enää olleet nopeasti toteutettavia ja testattavaa oli paljon. Lisäksi XP:n ominaisuuksien mukainen lyhytnäköisyys johti toisella kierroksella kokonaisten luokkien uudelleenrakenteluun.
Graafiseen toteutukseen ja varsinkin nuolenkärkien piirtämisen toteutukseen ja viimeistelyyn tarvittiin uskomattoman paljon aikaa, koodia, laskentakaavoja ja sisua. Ohjaajan esittämät pienet lisäominaisuudet eivät aina olleet kovin yksinkertaisia toteuttaa. Lopputulos oli kuitenkin hyvä - uskoaksemme parempi kuin mitä asiakas osasi toivoakaan.
XP-prosessimallin noudattaminen sisälsi riskejä: asiakas voi antaa uusia tehtävämäärityksiä, jotka saattavat pakottaa uusimaan tietorakenteita rajustikin. Prosessimallin mukaanhan tuotetaan mahdollisimman yksinkertaista ja helppotajuista ohjelmakoodia. Työskentelyssä ei kuulu - eikä voikaan - ennakoida ohjelman tietorakenteilta tulevaisuudessa odotettavia piirteitä. Meidänkin projektimme aikana asiakkaan tarpeet ja prioriteetit muuttuivat, mikä osaltaan aiheutti varsin isojakin muutoksia ohjelmakoodiin.
Ensimmäiset käyttäjäkertomukset olivat selkeitä ja nopeasti toteutettavia. Valtaosa käyttäjäkertomuskorteista sisälsi kuitenkin melko laajan toimeksiannon. Ryhmän olisi kannattanut suunnitella paremmin kunkin toimeksiannon toteutusta ja jakaa käyttäjäkertomukset selkeiksi, yhdellä ohjelmointikerralla toteutettaviksi tehtäväkorteiksi.
Ohjaaja kirjoitti asiakkaan puolesta valtaosan käyttäjäkertomuksista. Projektipäällikkö kirjoitti muutaman viimeisimmistä korteista kokouksessa asiakkaan toiveiden perusteella. Tehtävämääritykset eivät aina olleet kovin täsmällisiä, joten olisi ollut toivottavaa, että asiakas olisi itse miettinyt tehtävämääritykset etukäteen ja kirjoittanut kortit itse. XP:n mukaisesti asiakkaan edustajan kuuluisi myös olla mukana koodausryhmässä, jolloin palaute olisi välitöntä ja vältyttäisiin varmasti turhalta työltä ja varautumiselta erilaisiin vaihtoehtoihin. Nyt kolmannen jakson alussa oli kolmen viikon jakso, jolloin ei tavattu asiakasta lainkaan.
Projektikokousten ajankohta kuuden tunnin koodauksen jälkeen oli hieman epäonnistunut: projektin jäsenistä oli jo tuohon mennessä puhti pois, eikä kokouksissa jaksettu aina kovin paljoa keskustella. Kokoukset olivat useimmiten luonteeltaan tiedotustilaisuuksia, joissa asiakkaalle ja ohjaajalle esiteltiin aikaansaannokset ja suunnitelmat työn jatkamiseksi.
XP antoi asiakkaalle oivan tilaisuuden täsmentää toiveitaan tuotteen suhteen, mikä olisi tietysti mahdollistanut sen, että työ paisuu hallitsemattoman suureksi. Ryhmän jäsenet kehittyivät kuitenkin päteviksi työmäärän ja resurssien arvioijiksi. Lisäksi käyttäjäkertomusten lukemisessa ja tulkitsemisessa kehityttiin tarvittaessa toteuttamaan juuri se, mitä korttiin oli kirjoitettu - eikä mitään ylimääräistä. Projektin aikana asiakkaan tarpeet muuttuivat: hänelle ilmeni uusia tarpeita ja joidenkin aikaisemmin pyydettyjen ominaisuuksien toteuttaminen ei ollutkaan enää tarpeellista ja niinpä osa toimeksiannoista peruttiin. Joidenkin graafisten ominaisuuksien kohdalla toteutettiin enemmänkin kuin asiakkaan tarpeet, koska ryhmä halusi tehdä toimivan, helppokäyttöisen ja ulkoasultaan siistin työkalun. Asiakas oli tyytyväinen työn etenemiseen ja projektiryhmän ilmapiiriin.
Versionhallinta (CVS) otettiin käyttöön heti alusta asti, ja joitain testikoodeja lukuun ottamatta kaikista ohjelmatiedostoista syntyi useita versioita. Tämä helpotti huomattavasti ohjelmiston osien yhdistämistä ja ohjelmakoodin viimeistelyä. Toisen jakson lopussa versionhallinnassa ilmeni hankaluuksia, kun laitoksen koneiden eri kernel-versiot eivät sopineetkaan yhteen. Ongelma saatiin selvitettyä ja työssä päästiin etenemään menettelytapojen täsmentämisellä ja ohjeistamisella. Projektin tuottamat dokumentit oli rajattu CVS:n ulkopuolelle.
Vaikka projektin kokoukset eivät olleet kovin virallisia, eteni jokainen kokous kuitenkin esityslistan mukaisesti, ja jokaisesta kokouksesta laadittiin asianmukaiset kokouspöytäkirjat. Projektin ilmapiiri oli hyvä ja kokoukset olivat asiallisia ja avoimia.
Aikataulussa pysyttiin hyvin. Kolmen viikon jaksolle valitut käyttäjäkertomukset ohjasivat hyvin aikataulunhallintaa.
Lopputuloksena on toimiva ohjelmisto, joka vastaa käyttäjäkertomuksia ja projektikuvausta. Testauksen perusteella ohjelmisto ei kaadu normaalin suorituksen tai käytön yhteydessä. Myös mahdollisiin virhetilanteisiin on pyritty varautumaan.
Ryhmä on tyytyväinen lopputulokseen tämän ajan puitteissa. Jos aikaa olisi ollut enemmän, oltaisiin ohjelmistoon voitu vielä tehdä laajennuksia, joista asiakkaalla oli jo selvä visio. Näiden toteutus kuitenkin jää projektia seuraavalle ryhmälle.
XP-prosessimallin valinta oli onnistunut päätös tämäntyyppiseen lyhytkestoiseen projektiin. Ryhmä pääsi heti alussa toteuttamaan asiakkaan toimeksiannon mukaisia tehtäviä, jolloin motivaatio säilyi ja työ tuntui etenevän koko ajan. Prosessimallin mukaan tehtiin ohjelmakoodin refaktorointia tarvittaessa, mutta se ei aiheuttanut dokumentaation päivitystä eikä iteraatiota projektin hallinnassa. XP:n onnistumiseen vaikutti oleellisesti se, että pystyttiin varaamaan paljon yhteistä aikaa toteutukselle. Ryhmä ei kuitenkaan usko XP:n toimivan isoissa ja pitkäkestoisissa projekteissa.
Heti toisen kierroksen alussa luotiin toiminnot, joiden avulla JavaDoc-kuvaukset päivittyivät automaattisesti ja yksikkötestit ajettiin aina ohjelman käännöksen yhteydessä. Näin saatiin testattua välittömästi, että koodimuutosten jälkeenkin testit menivät läpi. Samoin JavaDoc-kuvausten päivitys onnistui helposti.