T Ohjelmistokehitysprojekti I - Loppuraportti

T-76.4115 Ohjelmistokehitysprojekti I - Loppuraportti Versio Päiväys Muokkaaja Kuvaus 1.0 Markus Kattilamäki Kuvaajat lisätty, viimeistely 0.7 21.2.2006 Markus Kattilamäki Projektin haasteellisuus lisätty 0.6 18.2.2006 Markus Kattilamäki Kokemuksia työkaluista 0.5 10.2.2006 Markus Kattilamäki Dokumentti luotu

1 Johdanto 3 2 Projektin eteneminen 5 2.1 Projektin suunnittelu (PP) 5 2.2 Implementaatio 1 6 2.3 Implementaatio 2 7 2.4 Yhteenveto 8 3 Tavoitteiden täyttyminen 10 4 Loppuanalyysi 12 4.1 Työtunnit 12 4.2 Ohjelmiston koko 15 4.3 Projektin haasteellisuus 15 4.4 Vertaistestaus 16 5 Työmenetelmät ja työkalut 18 5.1 Työmenetelmät 18 5.2 Työkalut 19 6 Opetuksellinen arvo 22 6.1 Markus Kattilamäki 22 6.2 Kirsi Rönkkö 23 6.3 Tuukka Laakso 24 6.4 Antti Kettunen 24 6.5 Mikko Halttunen 25 6.6 Mikko Närjänen 25 6.7 Antti Poikela 26 6.8 Markku Huttunen 26 7 Kurssipalaute 26 8 Jatkokehitys 27 8.1 Spring 27 8.2 Quartz 27 8.3 Linjan tarkastus 27 8.4 Aktiiviset laitteet 27 8.5 Releet hälytinkeskuksessa 27 8.6 Viestien välitys 27 8.7 Tietokanta 28 8.8 GSM, sähköposti 28 8.9 Komentorivikäyttöliittymä 28 8.10 Web-käyttöliittymä 29 8.11 Muuta 29 2

1 Johdanto T-76.4110 Ohjelmistoprojekti I Projektin oli tarkoitus toimia kurssin T-76.4115 Ohjelmistokehitysprojekti I harjoitustyönä. Tarkoituksena oli toteuttaa laaja ohjelmistoprojekti kahdeksan hengen ryhmässä, toteuttaen ohjelmistoprojektiin liittyviä erilaisia rooleja ja hyväksi havaittuja menetelmiä. Projekti oli tarkoitus toteuttaa ajanjaksolla 27.9.2005 2.3.2006. Kokonaisuudessaan projektin laajuudeksi oli määrätty kiinteästi 1500 tuntia. Projektin asiakkaana toimi Indagon Oy, jonka ehdottama projektin aihe oli. Tavoitteena oli toteuttaa valvottu liittymä. Tämä dokumentti toimii projektin loppuraporttina, kooten projektissa opitut asiat ja pohtien mikä onnistui ja missä olisi ollut parantamisen varaa. Kuva 1: Tilanne ennen projektia Nykyisessä tilanteessaan julkisten ja suurien rakennusten paloturvallisuudelle ja sen valvonnalle on asetettu määräyksiä jotka eivät nykytilanteessa toteudu lähinnä hälytinkanavan luotettavuuden osalta. Järjestelmä vastaa tähän tarpeeseen ja tuo kaivattua luotettavuutta tarjoamalla valvotun liittymän VIRVE-verkossa. Seuraavassa kuvassa on kuvattu tilanne ennen projektin mahdollistamaa ratkaisua. Kuva 2: Tilanne projektin jälkeen 3

Projektin lopputuotteen on tarkoitus toimia prototyyppinä yllä kuvatusta järjestelmästä ja tarjota tietoa mahdollisen järjestelmän luotettavuudesta jatkokehitystä varten. Jatkokehitettävän tuotteen tavoitetilassa hälyttimiä valvotaan Valpas-järjestelmällä VIRVEverkon yli. Järjestelmä tarjoaa käyttäjälleen myös kattavat seurantavälineet ja työkalut järjestelmän hallintaan. Lopputuotteella saadaan valvontalinjan luotettavuus nostettua viranomaisten määräämälle tasolle. Tästä dokumentista puuttuvat kaikki projektin laadullisten asioiden analyysi ja pohdinta. Erillisenä dokumenttinaan on luotu laadunvarmistuksen loppuraportti joka kattaa mm. vertaistestauksen ja laatumetriikat. 4

2 Projektin eteneminen T-76.4110 Ohjelmistoprojekti I Projekti oli jaettu kolmeen iteraatioon: Projektin suunnittelu, Implementaatio 1 sekä Implementaatio 2. Projektin suunnitteluvaiheen tarkoituksena oli suunnitella tulevaa työtä sekä valmistella seuraavat toteutusvaiheet. Ensimmäisen toteutusvaiheen tavoitteena oli rakentaa ohjelmiston tärkein toiminnallisuus. Implementaatio 2 tärkeimpänä tavoitteena oli kehittää www-selaimella käytettävä käyttöliittymä. Seuraavassa kappaleessa seurataan projektin etenemistä. 2.1 Projektin suunnittelu (PP) Projektin suunnittelu alkoi käytännössä ryhmän muodostamisella. Ryhmä saatiin kasaan tuttujen välityksellä ja roolijako onnistui varsin hyvin. Koska koko ryhmä oli kasassa jo ensimmäiseltä luennolta, saimme varsin hyvin onnistuneen startin kurssille ja projektille. Ongelmia tuotti kuitenkin aiheenvalinta, jossa emme olleet tarpeeksi aggressiivisia ja valmistautuneita hakemaan kurssin tarjoamia miellyttäviä aiheita. Uskoisin että asiakkaan ryhmän valinnassa vaikutti eniten juuri esityö joka meidän ryhmän osalta jäi melko kevyeksi. Toisaalta myös kurssi olisi voinut painottaa hieman enemmän aiheen valintaa. Koska emme saaneet itseämme miellyttävää aihetta, ryhmämme jäsen ehdotti työnantajansa aluillaan olevaa aihetta. Nopealla aikataululla kurssin listaukseen tuotu projektiaihe oli kuitenkin paras ratkaisu motivaation kannalta, koska kaikki halusivat pysyä erossa aiheista jotka liittyivät mobiililaitteisiin. Itse suunnitteluvaihe toteutettiin pääasiassa johtoryhmän toimesta. Tämä johtui osakseen myös kurssin suosituksesta. Tuntien osalta projektin suunnitteluvaiheessa jäätiin tavoitteesta yhteensä 37 tuntia. Suurimpana virhearviona pidettäköön suunnitteluun varattua aikaa. Toisaalta olisi ollut loppuprojektin suhteen parempi että suunnitteluun varatut tunnit olisivat tulleet käytettyä. Myös kehittäjiä olisi voinut sitouttaa enemmän tuotteen suunnitteluun alkuvaiheessa. Työskentelytahtia jouduttiin myös kirimään vaiheen loppua kohden. Tässä vaiheessa ryhmän työskentely haki vielä muotojaan. Suunnitteluvaihe oli muutenkin tutustumista ryhmään, aiheeseen ja asiakkaaseen. Vaihe oli varsin dokumenttipainotteinen ja varsin vaativa, koska loppujärjestelmän hahmottamisessa oli vaikeuksia. 5

Kuva 3: Projektin suunnitteluun käytetyt tunnit osa-alueittain Projektin suunnitteluvaihe oli myös tärkeä johtoryhmän toiminnan muodostumiselle. Vaiheen tuotokset olivat pääasiassa dokumentteja, tärkeimpinä projektisuunnitelma ja vaatimusmäärittelydokumentti. Näiden muodostamisessa työtaakkaa olisi ollut hyvä hajauttaa useiden ihmisten kesken, jotta niihin olisi yhden henkilön näkemyksen sijasta saatu useampaa näkökulmaa. Toisaalta dokumenttien työstäminen tässä vaiheessa vaikutti dokumentoinnilta dokumentoinnin ja kurssin vaateiden takia. Arkkitehtuurin suunnittelu oli myös vaiheen oleellinen tuotos. Jälkeenpäin tarkasteltaessa arkkitehtuuri oli melko kattava ja onnistunut mutta olisi kaivannut osakseen vielä syvempää panostusta. 2.2 Implementaatio 1 Implementaatio 1 alussa projekti saatiin vauhtiin täydellä teholla. Oleellista projektin aloittamiselle oli saada kaikki kehittäjät aktiivisiksi ja tietoisiksi projektin vaateista. Vaiheen alussa pidimme vapaamuotoisemman kick-offin jossa projektin toimintaa ja tavoitteita käytiin läpi. Kick-off toimi hyvänä aloituksena projektille. Iteraatiolle oli varattu varsin runsaasti tehtävää jokaiselle ryhmän jäsenelle ja varsinkin loppupuolella vaiheen raskaus rupesi näkymään työssä. Myös tehdyt työtunnit raahasivat suunnitellusta perässä ja niiden kiinni ottaminen kävi työstä. Osaltaan tähän oli vaikuttamassa seurannan lievä puutteellisuus. Toteutuksen ja suunnittelun välinen ero saatiin kuitenkin kirittyä kiinni ennen iteraation loppua. Myös joulun mahdollistama tauko tuli jokaiselle projektin jäsenelle tarpeeseen. 6

Kuva 4: Implementaatio 1 toteutuneet ja suunnitellut tunnit osa-alueittan Työmäärän arviointi oli kehittynyt edellisestä vaiheesta. Toteutuneet työt vastasivat suunniteltuja osa-alueittain erityisen hyvin. Henkilömäärän lisääntyessä ja uudehkon aiheen vaikutuksesta etenkin kommunikoinnin merkitys korostui. Toisaalta tärkeimmän toiminnallisuuden kehittäminen vei aikaa kunnolliselta laadunvarmistukselta. Etenkin sovittujen yksikkötestien kirjoittamisessa kehittäjillä oli hankaluuksia. Täten testaus jäi viime tippaan. Myöskään laadunvarmistusprosessin tehokas toteuttaminen ei onnistunut. Johtoryhmän osalta jakso meni suurelta osin projektin vetämistä opetellessa. 2.3 Implementaatio 2 Projektin viimeisen vaiheen tarkoitus oli valmistaa järjestelmälle web-käyttöliittymä, jatkaa toteutetun toiminnallisuuden laadunvarmistusta sekä mahdollistaa järjestelmän luotettavuudesta statiikkaa. Uuden toiminnallisuuden rakentaminen oli mahdollista näiden suoritteiden jälkeen, kuitenkin ennen lopputuotoksen vertaistestaukseen toimittamista. Tavoitteenamme iteraation suorittamisessa oli parantaa osaltaan myös projektin johtamista ja seurantaa. Tässä onnistuttiin uuden tuntiseurannan myötä sekä jakamalla viikkokohtaiset tehtävät tarkemmin henkilöille edelliseen vaiheeseen verrattuna. Projektin viimeiselle vaiheelle oli varattu melko lyhyt ajankohta vuoden alusta. Onnistuimme saamaan kaikki loman jälkeen projektin pariin varsin hyvin. Työskentely oli myös toimivampaa ja kommunikaatio pelasi paremmin projektin edellisiin vaiheisiin verrattuna. Jos projektia tultaisiin tästä vielä jatkamaan, voisi myös tavoitteiden asettelua nostaa. 7

Suurimpina ongelmina koettiin kokonaistuntien riittämättömyys henkilöittäin sekä kokonaisuudessaan. Tiettyjen järjestelmän osien avainhenkilöiden tunnit kuluivat liian nopeasti ja tehtäviä jouduttiin uudelleen resursoimaan. Ennen vertaistestausvaihetta toiminnallisuuden ollessa valmis, huomattiin että Valpas ei toimi. Tämän seurauksena pelättiin että projekti epäonnistuu. Tämä johti osaltaan myös syyttelyyn. Kuva 5: Implementaatio 1 toteutuneet ja suunnitellut tunnit osa-alueittan 2.4 Yhteenveto Projekti saatiin suoritettua kohtuullisen hyvin aikataulussa sekä laatutavoitteissa. Aikataulun suhteen jouduimme kuitenkin kirimään toteutusvaiheiden puolivälin jälkeen. Toisaalta ensimmäistä projektia suoritettaessa työarviot olivat todella hyviä. Jälkeenpäin katsottuna työskentelyä olisi voinut tehostaa. Tälläkin asetelmalla tehokkuus oli kuitenkin projektin onnistuneen suorituksen tasolla. Projektin loppuvaiheessa ilmeni haastavia suorituskyvyllisiä ja aikataulullisia ongelmia. Suorituskyvyllisiin ongelmiin syynä oli tarpeellisen testaustason puutteellisuus sekä joululoman aiheuttamat kommunikaatio-ongelmat tällä saralla. Tämän johdosta jouduimme hieman tinkimään suunnitelluista työtehtävistä. Toisten tehtävien laajemmalla tutustumisella ja toteuttamalla järjestelmää vähemmän hajautetusti, kriittisten ja yksilöriippuvaisten resurssien määrää olisi saatu pienennettyä. Projekti lähti todella vaivalloisesti käyntiin. Alussa kului runsaasti turhaa aikaa aiheen metsästämiseen. Motivaatio olisi ollut todella surkea lähteä jämäaiheita tekemään, mutta onneksi saimme aiheen "suhteilla". Tämän seurauksena oli se ongelma, että asiakas ei 8

ollut ehtinyt valmistella aihetta kovinkaan paljon. Tästä taas seurasi, että koko suunnitteluiteraatio meni aiheen speksaamiseen eikä niinkään sen suunnitteluun. Kun pohja oli näinkin varma, implementaatio 1 kului kalenteriaikaa ihmettelyyn ja varsinaisiin hommiin päästiin aika myöhään. Tästä syntyi paljon paineita kaikille projektiryhmän jäsenille ja aikataulu saatiin hätäisesti kirittyä iteraation loppuun mennessä toteutuksen osalta, testaus jäi todella vähäiseksi. Testauksen suuremmat ongelmat olivat kuitenkin projektiryhmästä riippumattomia, tästä lisää myöhemmin. Toinen iteraatio puolestaan on maistunut hyvin monelle pelkältä pakkopullalta. Suurimpana syynä tähän on ollut tunnit. "Oikeissa" projekteissa oltaisiin hyvinkin tyytyväisiä siihen että budjetti pystytään alittamaan, kurssin tapauksessa taas pitää pyrkiä mahdollisimman lähelle nollaa. Tästä taas seuraa se, että mielekästä tekemistä ei ole aina ollut. Kaikista suurimpia ongelmia projektin etenemiselle ovat kuitenkin antaneet ulkoiset tekijät. EPA oli täysi murheenkryyni koko ensimmäisen iteraation ajan, pidän ihmeenä sitä, että saimme ensimmäisen kehitysiteraation demossa ylipäätään demottua järjestelmäämme. Iso osa testauksen urakasta meni hukkaan, kun EPAssa oli ongelmia. Toisessa iteraatiossa testauksen ongelmana puolestaan oli, että tarvittavaa laitteistoa eli puhelimia ei saatu tarpeeksi ajoissa. Tämän puutteen johdosta pitkäaikaista testausta ei pystytty ajoissa suorittamaan ja tietenkin kun se vihdoin saatiin tehtyä, havaittiin Valppaassa suuria ongelmia vakaudessa - kaksi viikkoa ennen projektin loppua. 9

3 Tavoitteiden täyttyminen T-76.4110 Ohjelmistoprojekti I Seuraava kappale tarkastelee projektin tuloksia sille asetettuja tavoitteita vastaan projektiryhmän, asiakkaan ja vertaistestausryhmän näkökulmasta. Päällimmäinen tavoite projektille opiskelijoiden opintojen kannalta oli kurssin suoritus hyvällä arvosanalla. Tähän tavoitteeseen tullaan pääsemään. Jokaiselle on varmasti jäänyt tekemisestä myös oppia ohjelmistoprojektissa toimimisesta. Tämä dokumentti kerää yhteen myös kaikkien kokemukset. Projekti saatiin myös tavoitteiden ja laajuuden mukaisesti päätökseen ilman vakavia ongelmia. Projekti toimitetaan asiakkaalle ja heidän kommenttiensa mukaan projektia tullaan kehittämään kohti lopullista tuotetta. Taulukko 1: Projektiryhmän asettamat tavoitteet projektille ID Tavoite Täyttymiskriteeri R1 Opintosuoritus hyvällä arvosanalla Kurssin suoritus vähintään arvosanalla 4 R2 Aihealueesta oppiminen R3 Laajemmassa ohjelmistoprojektissa toimiminen R4 Laadukkaan ja asiakkaalle arvoa tuottavan ohjelmiston toimittaminen R5 Projektin loppuun saattaminen Oppimiskokemusten kerääminen projektin jälkeen, oppimisen toteaminen Projektin tyydyttävä suoritus Asiakas päättää projektin perusteella jatkokehittää tuotetta Kurssin laajuuden täyttäminen ja suoritusmerkinnän saaminen Taulukko 2: Asiakkaan projektille asettamat tavoitteet ID Tavoite Täyttymiskriteeri A1 Mahdollinen kaupallinen tuote tuhansille käyttäjille Prototyypin onnistunut toteuttaminen ja sen soveltuminen jatkokehitykseen. A2 Tetra-verkon käytettävyyden lisäselvitys A3 Kaupallistamisen selvittäminen A4 Aihealueesta oppiminen ja tietämyksen laajentaminen asiakkaan taholta A5 Asiakkaan ohjelmistoprosessin kehittäminen A6 Teknisen neuvojan tavoitteena lopputyön tekeminen aiheesta Prototyypin toimivuus ja skaalautuvuus sekä Tetra-verkon soveltuvuus käyttötarkoitukseen. Prototyypin toimivuus ja sopivuus sekä kaupalliset näkymät. Projekti tuo organisaatioon uutta osaamista ja tietoa aihealueesta. Asiakkaan prosessien kehittyminen ja menetelmien oppiminen. Projekti auttaa ja mahdollistaa lisätietoa aiheesta. Projektin hyödyllisyyden arvio lopussa teknisen neuvojan toimesta. 10

Asiakkaan vaatimukset projektille muuttuivat hieman projektin kuluessa. Viimeisessä vaiheessa asiakkaan pääasiallinen vaatimus oli saada järjestelmän luotettavuudesta kattavaa tietoa. Kuten alussa asia nousi esille, osa asiakkaan vaatimuksista on melko vaikea verifioida näin projektin lopussa. Asiakkaalta ei saatu annettuun määräaikaan mennessä kunnollisia kommentteja omista tavoitteidensa täyttymisestä. Loppudemossa asiakas arvioi projektia kokonaisuutena ja silloin on mahdollista saada asiakkaan tavoitteiden täyttymisestä lisätietoa. Pääasiassa asiakkaan tavoitteet voidaan katsoa täytetyksi. 11

4 Loppuanalyysi T-76.4110 Ohjelmistoprojekti I Seuraavassa kappaleessa on käyty läpi projekti numeerisesti. Kappaleessa esitetään työtuntien kehittyminen, laatumetriikoita sekä ohjelmiston koon kehitystä. 4.1 Työtunnit Kuva 6: Henkilöiden työn jakautuminen osa-alueittain 12

Kuva 7: Tuntikehitys henkilöittäin Kuva 8: Ensimmäisen vaiheen tuntikehitys 13

Kuva 9: Toisen vaiheen tuntikehitys 14

Kuva 10: Viimeisen vaiheen tuntikehitys (I2) Kuva 11: Tuntien jakautuminen osa-alueittain 4.2 Ohjelmiston koko Taulukko 3: Ohjelmiston koodirivien määrä 4.3 Projektin haasteellisuus Projektin aihe oli mielestämme keskihaastava. Rakensimme järjestelmän alusta alkaen toisin kuin osa muista projekteista. Myös sovellusalue oli ympäristönä haastava. Onnistuimme kuitenkin hyvin vastaamaan aihealueen haasteisiin ja toteuttamaan haluttu 15

toiminnallisuus ja sille asetetut vaatimukset. Projektin suurimmat haasteet voitaisiin jakaa kahteen osa-alueeseen: Asiakkaan toiminta loi ongelmia: Asiakkaan edustaja vaihtui kesken projektia joka osaltaan loi epävarmuutta projektin epävarman aloituksen lisäksi. Asiakkaan yhteyshenkilön vaihtuminen toi osaltaan lisätyötä ja nollasi siihen mennessä rakennetun asiakaskontaktin. Myös teknisen asiantuntijan työsuhteen lopettaminen vaikeutti resurssien (testipuhelimien ja muun materiaalin) saamista. Asiakkaan taholta löysä asenne kommunikaatiota kohtaan vaikutti kriittisten päätösten tekemisen nopeuteen ja projektin etenemiseen. Tämä tuli esille vastaamattomuutena sähköposteihin ja kyselyihin ongelmista. Asiakkaan paremmalla sitoutumisella projektiin, olisimme päässeet etenemään projektissa nopeammin ja ilman turhaa vaivaa. Projektista riippumattomat ongelmat: Projektin vaikuttamattomissa olevista asioista johtuen jouduimme tekemään kompromisseja sekä uudelleen aikatauluttamaan ja resursoimaan projektin työtä. Eritoten kolmannesta osapuolesta riippuva Edustapalvelin (EPA) aiheutti päänvaivaa. Se ei valmistunut aikataulussa ja aiheutti muitakin ongelmia. Projektin kehittäminen meistä riippumatonta alati muuttuvaa järjestelmää vasten oli haasteellista. Mm. projektin testaus viivästyi osittain EPA:n epästabiiliuden takia. Tietoturvatason takia projektiryhmä ei saanut missään vaiheessa suoraa yhteyttä EPA:n missään vaiheessa. Sitä ei myöskään päästy itse testaamaan missään vaiheessa. 4.4 Vertaistestaus Mikko Halttusen mukaan: Vertaistestausta suoritettiin kahden hengen voimin toiselle ryhmälle käyttämällä exploratory testing menetelmää. Testattavan ohjelman tehnyt ryhmä oli valmistellut 5 erilaista testi tapausta, joiden mukaan tuli testata. Itselleni kokemus tämän tyylisestä testaamisesta oli melkoisen uusi. Olen muutamia kertoja aikaisemmin testannut samalla tavalla, vaikkakaan silloin ei ole tullut käytettyä Session-Based Test Management:ia. Tästä syystä vertaistestaus oli erittäin valaiseva kokemus ja herätti ajatuksia testaamisesta perinteisesti määriteltyjen testitapauksien sekä exploratory testingin avulla. Tämän lisäksi oli erittäin mielenkiintoista nähdä, minkälaisen systeemin toinen ryhmä oli onnistunut kasaamaan samassa ajassa kuin oma ryhmäni. Molemmille testaajille määritelty 5 tuntia testaamista oli kohtuullisen paljon toisen ryhmän ohjelmaan käytettynä. Vertaisryhmän ohjelmasta ei tullut mukana dokumentaatiota siitä miten sen olisi pitänyt esimerkiksi laskea tuloksia, vaan testitapauksissa luki, että ei ole väliä sillä, mitä tuloksia ohjelma antaa. Jos ei tiedä kunnolla mitä ohjelma tekee tai tulisi tehdä, on virheiden ja ongelmakohtien löytäminen melkoisen hankalaa ja tuskaista. Asiaa ei myöskään auttanut se, että jokaisessa testissä fokuksena oli pyrkiä toimimaan kuin laitteen loppukäyttäjä, mikä taas ei kertonut minulle testaajana yhtään mitään. Loppukäyttäjä voi tehdä mitä tahansa, etenkin kun ohjelmaa tulevat käyttämään opiskelijat. Nämä molemmat yhdistettynä voisin sanoa, että vaikka ohjelmasta löytyikin ongelmakohtia, olisi niitä varmasti löytynyt enemmän jos olisi oikeasti ymmärtänyt mitä tekee. Tästä johtuen en pystynyt testaamaan järjestelmää kuin yhden tai kaksi tapausta päivässä. 16

Vaikka lähdin erittäin tehokkaasti tutkimaan ohjelmaa ja yritin panostaa siihen, että testaus olisi mahdollisimman hyödyllinen vertaisryhmälle, oli viimeisten testien tekeminen hampaat irvessä vääntämistä. Tämän myös huomannee löytyneiden bugien määrästä. Ensimmäisessä testissä löytyi puolet kaikkien sessioiden ongelmista, toisessa sessiossa jäljellä olevista puolet jne.. Suuri osa käytetystä ajasta meni myös miettimiseen, että onko tavattu ongelma bugi vai olisiko se mahdollisesti tarkoitus toimia kyseisellä tavalla. Vertaisryhmä sai varmasti runsaasti uusia bugeja, mutta uskon, että ne bugit, jotka löysin, olisi vertaisryhmä löytynyt myös käymällä yksinkertaisesti läpi ohjelman toiminnallisuuden kohta kohdalta. Tähän tuskin olisi mennyt puoliakaan siitä ajasta mitä itse kulutin ohjelman opetteluun ja turhaan säätämiseen. Uskon, että testaus olisi ollut tehokkaampaa, jos se olisi suoritettu useammassa osassa projektin eri vaiheissa. Esimerkiksi toisen iteraation alussa sekä lopussa. Tällöin ryhmä olisi päässyt korjaamaan bugeja heti toisen iteraation alussa, sekä itse olisin päässyt tutustumaan ohjelmaan aikaisemmassa vaiheessa, jolloin toisen vaiheen testaus olisi sujunut vielä paremmin. 17

5 Työmenetelmät ja työkalut Seuraavassa kappaleessa on käyty läpi kurssin vaatimat työmenetelmät ja työkalut sekä kokemukset niiden käytöstä ja sopivuus projektiin. 5.1 Työmenetelmät 5.1.1 Iteratiivinen kehitys Projekti oli hajautettu kolmeen vaiheeseen ts. iteraatioon. Kaksi varsinaista toteutusiteraatiosta oli varsin vähän todelliseen iteratiiviseen kehittämiseen. Todellista hyötyä sillä olisi saatu n. kuukauden mittaisista useammasta jaksosta. Toisaalta Nykyisen iteraatiot jaksottivat varsin hyvin projektin kulkua. 5.1.2 Iteraatioiden suunnittelu Ennen jokaista iteraatiota tehtävät ja kokonaisuudet suunniteltiin ja resursoitiin. Suunnittelun tuloksena jokaisesta vaiheesta valmistui iteraatiosuunnitelma. Iteraatiosuunnitelma sisältämien asioiden kommunikointiin olisi voinut kiinnittää ensimmäisessä vaiheessa enemmän huomiota ja varmistaa että kaikki lukisivat ja ymmärtäisivät sen. Tässä parannettiin huomattavasti viimeiseen iteraatioon mentäessä. 5.1.3 Dokumentointi Emme saaneet käytettyä dokumentaatiota kommunikoimaan projektiin liittyviä tietoja tehokkaasti kaikille osapuolille johtuen sen paljoudesta ja ryhmän viitsimättömyydestä. Dokumentaation lukemiselle ja ajantasaistamiselle olisi voinut varata enemmän aikaa ja seurata sen toteutumista. Välillä kurssin vaatimien dokumentaatioiden luomisen tarkoitus oli ennemminkin dokumentaatio itse. 5.1.4 Riskienhallinta Riskien hallinnalle suunniteltiin projektin alussa prosessi jossa niitä seurataan viikoittain johtoryhmän viikkopalaverissa. Riskien viikoittainen perusteellinen läpikäynti vaikutti hieman turhalta, joten sykliä päätettiin hieman pidentää. Riskejä päivitettiin sitä mukaan kun johtoryhmän palaverissa asioita nousi esille. Harva kriittinen riski pääsi toteutumaan. Vältimme myös suuret työn tekemistä ja jatkamista estävät riskit. 5.1.5 Tuntiraportointi Tuntiraportointi oli oleellisin mittari projektin seurannan ja työn edistymisen kannalta. Tuntiseurantaan erikoistuneen järjestelmän puuttuessa seurantaan käytettiin pääasiassa Wikiä sekä Exel-taulukkoa. Itse seurantaprosessin alkuvaiheen ongelmat saatiin ratkaistua projektin edetessä ja seurantaprosessia kehitettyä. Toteutuneet tunnit raportoitiin Wikissä viikoittain. Myös tunturaportointiin ja sen suunnitteluun olisi voinut varata enemmän aikaa varsinkin projektin alkuvaiheissa. 18

5.1.6 Ohjelmiston koon raportointi T-76.4110 Ohjelmistoprojekti I Projektissa ohjelmiston koon raportointi jäi melko huteraksi. Ohjelmiston kokoa ei juuri julkaistu kuin iteraatiodemossa. Kokoa olisi ollut hyvä seurata viikoittain ja julkaista se Wikissä. Seurannan puute johtui käytännössä että sille ei ollut varattu aikaa eikä varsinaista vastuuhenkilöä. 5.1.7 Kommunikaatio Kommunikaatio osoittautui projektin onnistumisen kannalta oleelliseksi. Vaikka olimme miettineet kommunikaatioprosesseja, olisi niiden toimintaan saattamiseen voitu panostaa vielä enemmän. Puhelu, tekstiviesti, IRC, sähköposti, Wiki ja palaverit olivat ensisijaisia kommunikaatiokanavia. Ylivoimaisesti suosituimmaksi kommunikaatiokanavaksi osoittautui IRC, 5.1.8 Iteraatiodemot Iteraatiodemot olivat hyvä keino kommunikoida projektin tilaa ja tuotoksia asiakkaalle sekä mentorille. Toisaalta kurssin antama valmis kalvopohja rajasi ja ohjasi demoa tiettyyn suuntaan. Demon vaatimukset olivat myös melko hämäriä. Paransimme demojemme ulosantia projektin edetessä ja eritoten I1 jälkeinen demo oli varsin onnistunut. Muita demoja vaivasi turha rikkonaisuus sekä epäoleelliset asiat. Demojen tarkoitus olisi ilmeisesti ollut myydä tuotetta, kaunistella tuloksia ja projektia. Tarkastelimme kuitenkin tuotoksiamme objektiivisesti joka mielestäni johti huonompiin arvosanoihin. Kurssin järjestelyssä painotetaan virheiden myöntämiseen projektin aikana oppimistarkoituksessa mutta arvosana perustuu osittain juuri epäonnistumisiin sekä dokumentaation oikeellisuuteen. 5.1.9 Vaatimusten hallinta Vaatimusten hallinta jäi projektin edetessä hieman oman onnensa nojaan johtuen resurssien puutteesta ja väärästä allokoinnista. Osittain vaatimusten hallinta kaatui kurssin vaatimaan mahdottoman pitkään dokumenttiin jota oli vaikea pitää päivitettynä asiakkaan nopeastikin muuttuvien vaatimusten suhteen. Pyrimme kuitenkin pääasiassa tarkistamaan huolellisemmin vaatimukset jokaisen iteraation alussa, jotta tiesimme minne mennä. 5.1.10 Vertaistestaus Vertaistestauksen suorittamiseen käytettiin melko vähän resursseja (n. 10 h). Tavoitteenamme oli arvioida lähinnä asennus- ja käyttöohjetta sekä toiminnallisuutta pääosin. Järjestelmää tuntemattomien henkilöiden edut saatiin käytettyä juuri tämän kaltaisessa tehtävässä. Toisaalta samantasoisen testauksen suorittaminen itsenäisesti olisi voinut tuoda tehokkaampaa laadunvarmistusta itse järjestelmän toiminnallisuuteen. 5.2 Työkalut 5.2.1 CVS Käytimme projektissa ohjelmiston versionhallintaan CVS:ää. Ilman kunnollista versionhallintaa tämän kokoinen projekti ei olisi pysynyt hallinnassa. Työkalun käytössä 19

ongelmana oli että versiomme ei ollut täysin yhteensopiva käyttämämme Eclipsen version kanssa. Välillä ajantasaisesta versiosta jouduttiin keskustelemaan ja kyselemään ennen toimenpiteitä. Välillä projektin alussa sopimamme versionhallinnan käytännöt myös rakoilivat. Paremmalla työkalulla versionhallinta olisi onnistunut helpommin. CVS:n tilalle ehdotettaisiin esim. SVN:n käyttöä (Subversion, kilpaileva versionhallintasysteemi) 5.2.2 MoinMoinWiki Projektin Wiki toimi varsin onnistuneesti apuna projektin kommunikaatiossa. Wikin vahvuuksia oli helppokäyttöisyys sekä saavutettavuus. Dokumentteja kehitettiin sen kautta, jolloin saimme dokumentteihin kaikkien näkemyksen koottua. Toisaalta dokumenttien kokoaminen Wikissä oli haastavaa. Tehtävien ja tuntien hallintaan olisi voitu käyttää tehokkaampaa työkalua. Wikin rakenteeseen olisi tullut kiinnittää enemmän huomiota ja sille olisi pitänyt varata aikaa ja henkilö ylläpitämään sitä. Nyt osa tärkeästäkin tiedosta hukkui usean otsikon alle. Wikin lukemista olisi pitänyt painottaa myös enemmän kehittäjien keskuudessa. 5.2.3 Bugzilla Käytimme bugiraportointiin Bugzillaa. Sen toiminnallisuus vastasi tarpeitamme kohtuullisesti. Sen käyttämisessä oli projektin aikana joitain ongelmia, kuten bugien kriittisyyden väärät merkinnät ja ääkkös-ongelmat. Työkalua oli välillä vaikea hahmottaa ja raportoinnin kannalta se ei välttämättä ollut kovinkaan järkevä työkalu. Työkalulta olisi myös toivottu samalla tehtävien hallintaa. 5.2.4 JUnit Kehittäjät tuppasivat välillä unohtamaan yksikkötestien tekemisen ja JUnitin käyttämisen. Heidän mielestään työkalu toi projektiin lisää turhaa säätöä ja overheadia. Kaikkia testejä oli vaikea saada toimimaan Apache ant:lla ajettuna vaikka kehittäjät olivat testeistään varmoja. Kehittäjistä yksikkötestausten tekeminen olisi voitu jättää vain kriittisille osille jos projektia ei toteuteta testivetoisella kehityksellä (Test Driven Development). Toisaalta yksikkötesteillä ja työkalulla saatiin tietoa laadusta ja testien tekeminen auttoi kehittäjiä myös koodin suunnittelussa. Testien ansiosta löydettiin bugeja ja testit auttoivat hahmottamaan jos jotain meni muutoksissa rikki. 5.2.5 Cobertura Coberturaa käytettiin ilmaisemaan yksikkötestien kattavuutta. Työkalu vaati ryhmän mielestä turhaa säätöä. Työkalun nähtiin ilmaisevan tärkeitä mittareita, mutta koska JUnit:n kanssa oli paljon ongelmia, raporttien luominen oli haasteellista. Kritiikkiä nousi myös esille työkalun kertoessa testien kattavuudesta, mutta ei mitään niiden laadusta. 5.2.6 Quartz Käytimme projektissamme Quartz-nimistä skeduloijaa. Quartz toimi osaltaa projektin selkärankana. Koska projektiryhmällä ei ollut aikaisempaa kokemusta työkalusta, ongelmista oli vaikea välttyä. Toisaalta myöskään oman skeduloijan tyhjästä kirjoittaminen ei olisi onnistunut. 20

5.2.7 IRC T-76.4110 Ohjelmistoprojekti I Projektin kommunikaatiota hoidettiin varsin tehokkaasti IRC:n kautta. Perustimme useamman kanava kattamaan projektin eri ryhmien tarpeet. IRC:n puolidokumentoiva kommunikaatio oli hyvä. Täten ihmiset pysyivät kärryllä lukemalla käytyjä keskusteluja. IRC helpotti tiedonkulkua ja mahdollisti asioiden kertomisen laajalle joukolle yhtä aikaa. IRC oli kommunikaatiovälineenä oleellinen osa projektia. Kaikkea keskustelua oli kuitenkin hankala seurata jälkeenpäin, jos se ei koskenut itseä. 5.2.8 Eclipse Käytimme projektin kehityksessä Eclipse kehitysympäristöä (IDE). Se vastasi hyvin tarpeisiimme ja sai hyvää palautetta kehittäjiltä. Toimiva kehitystyökalu oli yksi onnistuneen projektin kulmakivistä. 21

6 Opetuksellinen arvo T-76.4110 Ohjelmistoprojekti I Seuraavaan kappaleeseen on kerätty projektin jokaisen jäsenen ennen projektia asettamat tavoitteet sekä seurattu niiden täyttymistä ja muuta opetuksellista arvoa. Osallistujat kertovat seuraavassa projektista. Taulukko 4: Projektin jäsenten oppimistavoitteet projektin alussa Jäsen Oppimistavoite Kattilamäki Saada kokemusta ohjelmistoprojektin vetämisestä ja oppia tehokkaita menetelmiä projektin läpiviemiseksi. Laajentaa näkemystä ohjelmistoprojektista ja sen eri vaiheista. Laakso Rönkkö Huttunen Poikela Närjänen Halttunen Kettunen Oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä Oppia vetämään projektia paremmin, hallitsemaan sitä sekä oppia laadunvarmistukseen liittyviä asioita. Lisäksi tavoitteena on kehittyä testauksen saralla sekä oppia luottamaan enemmän muiden työhön ja keskittyä paremmin omaan. Uusien tekniikoiden oppiminen, kommunikointi laajemmassa projektissa sekä oman ajankäytön ja arvioinnin parempi hallitseminen Aiemman testauskokemuksen puuttuessa pääasiallisena tavoitteenani on oppia rooliin kuuluvat tehtävät ja käytännöt. Projektin koko tuo mukanaan haasteita, joten oppia projektin kulkuun vaikuttavista asioista, esimerkiksi tiimin sisäisestä kommunikoinnista ja asiakkaan kanssa toimimisesta. Ryhmätyötaitojen kehittäminen, laajemman projektin toimintaan tutustuminen, uusien työkalujen (Borland Together, JUnit, jne.) käytön oppiminen, ohjelmointitaitojen kehittäminen. Laajentaa tietoani ohjelmistoprojekteiden kulusta ja päästä kokeilemaan sellaisessa mukana olemista. Yksikkötestauksen oppiminen ja käyttäminen. Oppia soveltamaan käytännössä uusia ohjelmiston tuottamisen käytäntöjä sekä oppia niiden käyttökelpoisuus erilaisissa tilanteissa. 6.1 Markus Kattilamäki Roolini projektipäällikkönä oli varsin haastava ja erilainen kuin ennalta saattoi odottaa. Opintojen kautta kerääntyneestä projektikokemuksesta ei ollut niin paljon apua kuin olisi osannut kuvitella. Suurimman haasteen projektin vetämiseen toi ehdottomasti sen hajautettu luonne. Tämän takia vuorovaikutus ja kommunikaatio keskittyivät pääosin sähköisiin kanaviin. Myös työn seuranta jäi lukujen tuijottelun asteelle, koska konkreettista ja jatkuvaa kontaktia kehittäjiin ei ollut. Projektin vetämistä olisi helpottanut jos olisi varannut itselleen myös pienen roolin tuotteen kehityksessä. Tavoitteiden mukaisesti projektipäällikön rooli tarjosi näköaloja projektin kaikkiin osa-alueisiin ja vaiheisiin. Kokemus projektin vetämisestä karttui ja hyödyllisimmäksi työkaluksi osoittautuivat vuorovaikutustaidot. 22

6.2 Kirsi Rönkkö T-76.4110 Ohjelmistoprojekti I Tavoitteeni oli oppia paremmin projektin vetämistä, laadunvarmistukseen liittyviä asioita ja delegointia. Tavoitteet ainakin jollakin tasolla myös saavutin. Ainoat puutteet tavoitteiden täyttymisessä koen vaatimustenhallinnan tasossa. Aihe on vaativa, työkalut vähissä ja loppupeleissä roolini projektin johtoryhmässä ehkä hivenen väärä kunnolliseen vaatimustenhallintaan. Projektin johtaminen tuntui ensimmäisen iteraation kohdalla hyvin kaoottiselta. Tieto ei tuntunut liikkuvan riittävästi, asioista oli vaikea tehdä konkreettisia ja projektin tilaa oli vaikea hahmottaa. Resurssien käytön hallinta ei myöskään tuntunut toimivan. Itse en ehkä myöskään tiennyt miten asiat oli aikataulutettu ja miten tai milloin tehtävät olisi tullut hoitaa. Tuntui, että asioihin kyettiin reagoimaan hyvin hitaasti. Asioita oli myös vaikea korjata "kesken" iteraation. Toinen iteraatio toimi mielestäni paremmin. Aikataulutus oli tehty viikkotasolle edellisestä iteraatiosta opittujen virheiden korjaamiseksi. Omalta osaltani asiaa auttoi myös huomattavasti se, että johtuen projektipäällikön tuntien vähyydestä, olin vahvasti mukana tehtävien ja aikataulun suunnittelussa. Se, ettei projektipäällikkö osallistunut tähän toi kuitenkin mukanaan ongelmia. Iteraation alussa tuntui, että projektipäällikkö oli tietyllä tavalla kadonnut projektista. Asia onneksi nostettiin molemmin puolin esille johtoryhmän kokouksessa ja tilanne parani. Koen oppineeni asioita johtamisesta. Havaitsin, että ilman kunnollista aikataulusuunnitelmaa ja sen päivittämistä, projektin seuranta on lähes mahdotonta. Opin myös, että hienot suunnitelmat eivät kovin helposti välity johtoryhmästä alemmille tasoille varsinkaan dokumenttien välityksellä. Lisäksi asioita pitää kerrata riittävän usein tai ne vain unohtuvat, kuten JUnit-testien teko joululoman jälkeen. Olen myös tajunnut miten suuri merkitys on kasvokkain kommunikoinnilla tai ylipäätään sillä, että on kanssakäymisessä muiden projektin tekijöiden kanssa. Projektiryhmän johtamista voi kyllä myös kohdaltamme parantaa. Vastuunjako eri asioiden välillä oli määritelty, samoin johtovastuut henkilöiden suhteen. Toisessa iteraatiossa testausta suorittivat käytännön syistä kehittäjät. Alussa tämä oli vaikeaa, koska kehittäjät kuuluivat pääarkkitehdin alaisuuteen, mutta testaukseen liittyvät asiat olivat vastuullani. Tällaisissa tilanteissa ei ollut selkeää pelisääntöä siitä kuka hoitaa ja mitä. Toinen roolien välinen ongelma oli laadunvarmistuksen ja testauksen välillä. Vaatimustenhallinta ja erilaiset muut asiat veivät aikaani niin paljon, että testitapausten miettimien jäi testaajan vastuulle. Tämän jälkeen testauksen hallinta oli hyvin haasteellista. Suosittelen lämpimästi, että laadunvarmistuksesta vastaava henkilö vastaa vain laadusta ja suunnittelee siihen liittyen testitapaukset. Testaajan tehtäväksi jäisi sitten enemmän itse testaaminen ja sen raportointi. Tällöin laadunvarmistukseen saataisiin helpommin myös seuranta johtoryhmään asti. Lisäksi vaatimustenhallinta sopii paremmin pääarkkitehdin toimenkuvaan. Tällöin on helpompi suorittaa vaatimusten tilan seurantaa samalla kun kerää tietoa siitä missä vaiheessa kehittäjät kulloinkin menevät. Huomaan myös, että omista taipumuksistaan on vaikea luopua. Toisessa iteraatiossa jouduin rankalla kädellä delegoimaan asioita muille, sillä omat tuntini olivat vähissä. Oli 23

vaikea luottaa siihen, että asiat saadaan aikaan myös vähemmällä omalla panostuksella. Toisaalta on myös vaikea saada muita sitoutumaan asioihin samalla tavalla kuin itse on. Asiakkaan puolelta oli myös vaikea havaita sitoutumista, vaikka tiedän, että tekemämme projekti oli tärkeä. Siitä huolimatta vastauksia maileihin ei aina kuulunut, projektiin vaikuttavista asioista ei ollut tietoa. Asia nostettiin jossain vaiheessa pöydälle, mutta loppujen lopuksi tilanne ei korjaantunut kuin hetkeksi. Yleisesti ryhmän toiminnasta sanoisin, että meitä vaivasi kokemattomuus. Johtoryhmä on lukenut ohjelmistoprojektien hallinasta jo aika paljon. Silti osa tärkeistä kursseista oli käymättä: vaatimustenhallinta, arkkitehtuuri, testaus. Osaa kursseista käytiin kyllä samaan aikaan, mutta projekti olisi varmasti hyötynyt siitä, että nämä kurssit olisivat olleet täysin suoritettuja ennen tämän kurssin alkamista. Väitän, että silloin ihmisillä olisi ollut enemmän näkemystä omiin tehtäviinsä. 6.3 Tuukka Laakso Kurssin alussa asetin itselleni kaksi tavoitetta: oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä. Kehittäjäryhmämme oli onneksi mukavan helposti johdettava, joten suuria ristiriitoja en joutunut selvittämään. Suurelta osaltaan tämä johtui tietenkin siitä, että ryhmä tunsi toisensa jo entuudestaan. Tästä huolimatta koen, että olen kurssin aikana saanut arvokasta kokemusta töiden jakamisesta taidoiltaan erilaisille kehittäjille ja kommunikaation osittaisesta hankaluudesta täysin hajautetussa projektityöskentelyssä. Varsinaisista arkkitehdin tehtävistä ei kovinkaan runsaasti kokemusta tullut, roolini kun muodostui enempi johtavaksi kehittäjäksi kuin varsinaiseksi arkkitehdiksi. Tämä siitä syystä, että jo projektin varhaisessa vaiheessa havaitsimme, että järjestelmä on todella monimutkainen yhden henkilön kovinkaan pitkälle suunniteltavaksi. Lisäksi projektin alussa ei kovinkaan pitkään suunnitteluvaiheeseen loppujen lopuksi ollut aikaa, vaan kehittäjät piti saada nopeasti töihin, jotta tunteja saatiin kulumaan. Joten arkkitehtuurilliseksi tehtäväksi minulle jäi lähinnä järjestelmän jakaminen osiin ja kehittäjien vastuiden jakaminen eri järjestelmän paloille. 6.4 Antti Kettunen Kurssista paistoi monessa kohtaa läpi "pääasia, että dokumentaatiot on kunnossa" - asenne, joka vaikeutti siihen vakavasti suhtautumista. Opetuksellisista tavoitteista täyttyi aika harva, tosin en niitä kovin tarkkaan kirjannut projektia aloitettaessa. Halusin kokeilla uusia menetelmiä ohjelmistotuotannossa, mutta nämä jäivät loppujenlopuksi aika harvaan. Mutta testauksen suorittamisesta tai varsinkin mahdollisista ongelmista testauksen suorittamisessa sain hyvää tietoa, emme ehkä pystyneet niitä täysin ratkomaan, mutta jatkossa luulisin osaavani ottaa paremmin huomioon tähän vaikuttavia tekijöitä. Yksikkötestien teko projektin laajuisesti tarjosi hyvää kokemusta ja tietoa missä niitä tarvitaan. Etenkin se, että testit vaikuttavat myös itse koodin rakenteeseen tuottaen selkeämpää ja testattavampaa koodia. Myös koodikatselmoinneista sain hyvän käytännön kuvan. Tärkeimpänä opetuksena ehkä se, että kommunikointi tiimin välillä on tärkeintä varsinkin tällaisessa täysin hajautetussa projektissa, jossa kukaan ei tunne koko järjestelmää täysin 24

ja ihmiset työskentelee eri aikoihin. Useamman ongelman olisin voinut välttää avaamalla suuni ajoissa. 6.5 Mikko Halttunen Oppimistavoitteeni oli laajentaa tietoa ohjelmistoprojektien kulusta ja päästä kokeilemaan sellaisessa mukana olemista. Lisäksi halusin erityisesti tutustua yksikkötestaamiseen. Projekti oli omien oppimistavoitteideni kannalta täysin onnistunut. Pääsin tutustumaan yksikkötestauksen saloihin oikein runsaasti ja projektiin osallistuminen valaisi hieman isommassa projektissa olemista ja toimimista erittäin paljon. Projektista on varmasti hyötyä tulevissa koitoksissa työelämässä. Mielenkiintoista tässäkin projektissa oli se, että vaikka aika ja aihe oli melkoisen rajoitettu, tuli selkeästi esille samoja elementtejä ja ongelmia mitä työelämässä on tullut vastaan, kuten kommunikaation ongelmat sekä aikataulun ja vaatimusten muutoksien takia. Muutokset aikatauluun ja vaatimuksiin sekä ongelmat kommunikaatiossa aiheuttivat myöhästymisiä ja kavensivat kehittäjille varattua aikaa projektin alussa. Tämän lisäksi, kun en itsekään alkanut tekemään töitä riittävällä tahdilla, jäi ensimmäinen osa ainakin omalta osaltani vajavaiseksi ja loppupäästä raskaaksi. Kevään osiossa ryhmällä ollut selkeämpi prosessi auttoi projektin ja oikean elämän aikataulujen yhdistämisessä 6.6 Mikko Närjänen Tavoitteinani tässä projektissa olivat ryhmätyötaitojeni kehittäminen, tämän kokoisen projektin toimintaan tutustuminen, uusiin tekniikoihin ja työkaluihin tutustuminen ja ohjelmointitaitojeni kehittäminen. Katson saavuttaneeni tavoitteeni ainakin osittain kaikilla näillä osa-alueilla. Antoisinta ja opettavaisinta tässä kurssissa on ollut projektin ja ryhmän toimintaan tutustuminen. Ymmärrän nyt paremmin tämän kokoluokan ohjelmistoprojektiin liittyviä haasteita erityisesti ryhmän sisäisen kommunikaation, kehittyvän ohjelmiston hahmottamisen ja hallinnan, sekä testauksen ja laadunvarmistuksen osalta. Näin jälkeenpäin ajatellen olisi ollut mielenkiintoista paneutua testauspuoleen vieläkin tarkemmin. Omien ryhmätyötaitojen kehittymistä on vaikea arvioida näin lyhyellä aikavälillä. Uskon kuitenkin tuntevani omat heikkouteni ja vahvuuteni paremmin kuin kurssin alkaessa. Ohjelmointitaitoni sekä Java-kielen tuntemukseni ovat kehittyneet projektin aikana. Tämä johtuu suurelta osin muista samaan aikaan käymistäni kursseista ja omasta harrastuneisuudestani. Jotkin asiat, esimerkiksi suunnittelumallit, ovat tulleet tutummiksi tämän kurssin kautta. Toisten ohjelmoijien koodiin tutustuminen erityisesti koodikatselmointien kautta ja palautteen saaminen omasta koodista on myös ollut hyödyllistä. Odotin ja toivoin, että olisin ehtinyt tutustua projektin aikana suurempaan määrään uusia tekniikoita ja työkaluja. Opin kuitenkin hyödyllisimmän ja yleiskäyttöisimmän yksittäisen uuden tekniikan, mitä tältä projektilta oli odotettavissa, eli yksikkötestauksen. 25

6.7 Antti Poikela T-76.4110 Ohjelmistoprojekti I Oppimistavoitteenani oli testaajan rooliin kuuluvat tehtävät ja käytännöt sekä oppia projektin kulkuun vaikuttavista seikoista tiimin sisällä sekä asiakkaan kanssa. Oppimistavoitteeni täytynee katsoa täyttyneiksi, opin testaajan rooliin kuuluvista tehtävistä ja jotain myös projektin kommunikaatiosta käytännössä, joskin asiakkaan kanssa kommunikointia seurasin lähinnä johtoryhmän toimien kautta. Projektin opetuksellinen arvo ja projektin vaatima työmäärä eivät mielestäni kuitenkaan olleet missään suhteessa. Suuri osa tehtävistä ei ollut motivoivia ja pääasiassa projekti tuntuikin vain yritykselle tehtävältä käytännössä ilmaiselta työltä. Puuttuva motivaatio johti aikatauluongelmiin, sillä tehtävien teko ei usein kerta kaikkiaan kiinnostanut riittävästi ennen lähestyvää deadlinea (projektiryhmän viikkodeadline ja päivän töille asetettu oma deadline, joka käytännössä tarkoitti aamua), jolloin päästiinkin tinkimään yöunista. Tehottomasta ajankäytöstä johtuen työmäärä tuntui moninkertaiselta todellisiin käytettyihin tunteihin nähden. En väitä, ettei projektissa olisi oppinut uusia asioita, mutta ei työmäärään nähden lainkaan riittävää määrää. 6.8 Markku Huttunen Yhtenä oppimistavoitteenani oli kommunikaation parantaminen varsinkin projekteissa, joissa on mukana monta henkeä. Kuten odotettua, kurssi osoitti sen faktan, että kommunikaatio asettaa todellisen haasteen kahdeksan hengen yhteistyölle. Loppujen lopuksi selvisimme mielestäni ilman suurempia ongelmia pitkälti moninaisten kommunikaatiotyökalujen ansioista. Irc ja kehittäjäpalaverit olivat mielestäni tärkeimmät kommunikaatiomenetelmät. Kurssi opetti ajoittain jopa kantapään kautta sen, että kommunikaatiota on syytä harrastaa paljon ja ettei ole tyhmiä kysymyksiä. Tavoitteenani kurssilla oli myös uusien tekniikoiden oppiminen. Uusina asioina projektissa pääsin tutustumaan Web Servicien aksessointiin ja web-käyttöliittymän tekemiseen. Lisäksi pääsin tutustumaan hieman Spring frameworkkiin, josta voi myös olla hyötyä jatkossa. Muilta osin ohjelmointityö ei varsinaisesti tuonut esille mitään uutta ja ihmeellistä. Kuitenkin kaikki uusi opittu asia on aina positiivista. Viimeinen oppimistavoitteeni, kehittyminen ajankäytön arvioinnissa osoittautui kaikista haastavimmaksi tavoitteeksi. Vaikka työtehtävien keston arviointi tuntuukin edelleen todella hankalalta, sain kuitenkin kurssin puitteessa siihen vähän harjoitusta. Sinällään tämän tavoitteen täyttyminen olisikin ollut epärealistinen tavoite, koska tämä oli ainoa TKK:lla käymäni kurssi jossa pidin kirjaa tunneistani ja koetin arvioida tehtävien kestoja. 7 Kurssipalaute Arvosanan kannalta olimme liiankin kilttejä tarjotessamme varsin läpinäkyvän rajapinna projektimme sisälle. Näin projektin lopuksi voisi todeta että emme myyneet projektiamme tarpeeksi asiakkaalle emmekä mentorille. Osan ongelmistamme ja toimintatavoista itsellä pitäessämme olisimme voineet yltää parempiin arvosanoihin. Tämä on hieman ristiriidassa Mentorin kannustaman avoimen kommunikaation kanssa. Asiakassuhde olisi voinut olla myös hieman erilainen jos olisimme toimineet tuntemattomalle asiakkaalle. 26

Asiakassuhde olisi voitu myös pitää enemmän alihankintana kuin talon sisällä tehtynä. Tällä olisi saavutettu tietty raja asiakkaan ja projektiryhmän välille. Kokonaisuudessaan kurssi on erittäin raskas ja vaatii opintoviikkoihin nähden huomattavan paljon työtä. 8 Jatkokehitys Seuraavassa on esitetty näkemyksiä järjestelmän jatkokehitysmahdollisuuksista. 8.1 Spring Valppaan selkäranka. Deklaratiiviset transaktiomääritykset Valppaan kannalta ehkä tärkein ominaisuus, joten sen käyttö lienee perusteltua jatkossakin. Lisäksi kokoonpanoa voidaan muutella kääntämättä koodia. 8.2 Quartz Tarkistusten skedulointi. Jatkossa kaikki ajastetut työt voidaan toteuttaa käyttäen Quartzia. 8.3 Linjan tarkastus Nykyinen toteutus lopettaa linjatarkisukset jos automaattinen laitetarkkailu otetaan pois päältä. Tarkoitus kuitenkin olisi, että niitä jatketaan edelleen. 8.4 Aktiiviset laitteet Valppaan laitetaulussa on tarvittavat kentät myös aktiivisten laitteiden tarkkailuun. Lähinnä tähän tarvitaan yhtä päivämäärä kenttää, jota päivitetään laitteen lähettäessä tietyn tyyppisen viestin, että se on kunnossa. Kyseeseen tulisi lastdeliverymessagetime, jota käytetään passiivisten laitteiden yhteydessä tallentamaan välitystietojen päivämäärä. Aktiivisille laitteille ei lähetetä ikinä viestejä, joten kenttää ei käytetä mihinkään. Yhtähyvin voitaisiin käyttää lastservicemessagetimeä, jota käytetään passiivisten laitteiden yhteydessä tallentamaan aika jolloin testiin saapui vastaus. Lisäksi aktiivisten laitteiden tarkkailuun olisi hyvä tehdä oma job, joka delegoi tarkistuksen jollekin aktiivisia laitteita käsittelevälle oliolle. Periaatteessa tähän voitaisiin käyttää nykyistä DeviceStatusCheckerjobia, joka delegoi tarkistuksen laitteen tyypistä riippuen oikealle käsittelijälle. 8.5 Releet hälytinkeskuksessa Valppaan passiivisten laitteiden tarkistukseen on liitetty nykyisellään komponentti, joka lähettää releiden nollausviestit kun tarkistus on suoritettu, joten releiden pitäisi Valppaan puolesta toimia. Käytännössä tarvittaisiin tarkempaa testausta aikaväleistä, joita voidaan käyttää ennenkuin seuraava testi aloitetaan. Valpas ei niihin juuri ota kantaa ja käyttäjä voi syöttää arvoja, joilla testauksen suorittamista ei voi erilaisista viiveistä johtuen tekemään. 8.6 Viestien välitys Valpas lähettää jokaisen viestin EPA:lle asynkronisesti yksitellen. EPA:n kannalta tehokkaampaa voisi olla, että viestejä puskuroitaisiin ja lähettäisiin vaikka 500 millisekunnin aikana kertyneet viestit kerralla. Tämä tosin vaikeuttaa virheiden logittamista 27

sillä logitus tehdään lähetyksestä tulevien poikkeusten perusteella. Toisaalta kyseinen informaatio tuskin enää kiinnostaa jatkossa. 8.7 Tietokanta Hibernate on edelleen hyvä ratkaisu Valppaan toteutuksessa. Tekemällä suora JDBC toteutus voitaisiin tietokannan saantia ehkä tehostaa, mutta tarvittaisiin kuitenkin cachet ja käsin tehdyt implementaatiot jo Hibernatessa mukana oleville ominaisuuksille. Jos saantia halutaan tehostaa lienee aluksi helponta muokata kannan skeemaa optimaalisemmaksi Hibernaten kannalta sekä laittaa lazy loading päälle. Ainut syy miksi se nyt on pois päältä on se, että Valpas on haluttu pitää riippumattomana Hibernatesta ja jos lazy loading on päällä niin Spring ei enää pysty muuntamaan Hibernaten poikkeuksia oman hierarkiansa mukaiseksi ja Valppaassa joudutaan ottamaan kiinni varsinaisia Hibernaten poikkeuksia. Lisäksi jatkossa olisi järkevää erottaa käyttöliittymissä näkyvät kentät omaan kantaolioonsa ja pitää Valppaan sisäisesti käyttämät kentät omassaan. Näin voitaisiin käyttää Hibernaten optimistic locking -suunnittelumallia käyttöliittymässä esitettävien tietojen kanssa ja välttyä näin vanhentuneen datan päivitykseltä jos laitteen tietoja muokataan rinnakkaisesti. Sisäkkäisillä kentillä optimistic locking -mallia ei haluta käyttää sillä se voi estää yhtäaikaisten transaktioiden kirjoitusoperaatiot. Valpas on suunniteltu niin, että samaa sisäistä kenttää ei voi kirjoittaa kuin yksi transaktio kerrallaan, joten yhtäaikainen kirjoitus ei ole ongelma. Mutta jos ne ovat samassa kantaoliossa niin optimistic-locking estää huonossa tapauksessa toisen transaktion kirjoituksen kokonaan vaikka ne eivät samaa kenttää kirjoittaisikaan. Lisäksi dynamic-update on ehdottomasti pidettävä päällä, ettei kenttiä, jotka eivät ole muuttuneet, päivitetä. 8.8 GSM, sähköposti Valppaaseen voidaan lisätä komponentteja, jotka saavat tietoa tarkistusten tilasta muttei varsinaisista vioista tai hälytyksistä toteuttamalla DeviceStatusListener-rajapinta. Rajapintaa tulisi laajentaa käsittämään myös varsinaiset vika- ja hälytysviestit ja välittää nuo tiedot tarkkailijalle ReceivedMessageHandler-luokasta. Huomautuksena viestejä vastaanottavan työn tulisi valmistua mahdollisimman nopeasti, joten ReceivedMessageHandlerin ei ehkä tulisi ajaa tarkkailijoiden metodeja suoraan samassa säikeessä. Sama pätee myös tarkistuksiin. Nykyinen DeviceStatusChecker-toteutus kutsuu tarkkailijan metodeja suoraan. 8.9 Komentorivikäyttöliittymä Nopea laajentaa testausta varten jos tehdään uusia ominaisuuksia. Voidaan lisäksi käyttää esim. skriptien ajoon syöttämällä käyttöliittymälle skripti tekstitiedostona. Esim. add device "plaa" "plaa" false 10000 10 1000 (TEST_ALARM) remove device 1 remove device 2 remove device 3 remove device 4 exit 28

8.10 Web-käyttöliittymä T-76.4110 Ohjelmistoprojekti I JSTL:n ja EL-expressioiden käyttöä tulisi miettiä. Onko niistä mitään etua verrattuna skripletteihin? JSTL:llä asiat onnistuu kuitenkin astetta hankalammin kuin vastaavalla Java-koodilla ja ainut hyöty on lähinnä JSP:n xml-muoto. Paljoa selkeämpää se ei ole. Spring MVC on sopivan joustava eikä pakota mihinkään toteutusta mihinkään sopimattomaan muottiin. Tosin sen kehitys tuskin etenee enää isommin ja esim. JSF alkaa kypsymään teknologiana ja on standardi. Springin Web Flow voisí myös olla varteenotettava vaihtoehto sillä Valpas nojautuu muuten vahvasti Springiin. Tehdessä laajempaa web-sovellusta Valppaan päälle tulisi toteutusteknologiaa harkita sillä nykyinen toiminnallisuus on vielä suppeaa ja vaihto onnistuu järkevällä työmäärällä. Lisäksi tulisi miettiä miten laitteita hallitaan asiakaskohtaisesti. Valppaaseen voitaisiin rakentaa asiakkaiden hallintaan oma julkisivu ja taulut tarvittaville tiedoille, jolloin käyttöliittymä pysyisi edelleen aika ohuena. Kaikki transaktioita vaativat operaatiot olisi hyvä suorittaa Valppaassa ja tarjota käyttöliittymille RMI-rajapinnat julkisivuihin. Näiden yli kulkeva tieto on kuitenkin vähäistä. Toisaalta jos Valppaan suorituskyky halutaan maksimoida, voisi käyttäjienhallinta sijaita erillään Valppaasta. 8.11 Muuta Valppaan laajetessa J2EE:n tarjoamat palvelut voisivat myös tulla tarpeeseen, joten Valppaan refraktorointia ja ajoa sovelluspalvelimessa lienee myös syytä harkita. Spring, Quartz ja Hibernate eivät sulje tätä vaihtoehtoa pois vaan ovat suunniteltu integroitaviksi sovelluspalvelimiin. 29