Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria........................................................................... 1 1.2 Projektista.............................................................................. 2 2 Edistymisraportti.......................................................................... 3 2.1 PP Projektinsuunnittelu.................................................................... 3 2.2 I1a Toteutus 1a.......................................................................... 3 2.3 I1b Toteutus 1b.......................................................................... 3 2.4 I2a Toteutus 2a.......................................................................... 4 2.5 I2b Toteutus 2b.......................................................................... 4 3 Tulokset.................................................................................. 5 3.1 Asiakkaan tavoitteet...................................................................... 5 3.2 Toimittajan tavoitteet..................................................................... 7 3.3 Järjestelmän laatu........................................................................ 8 3.4 Jatkokehitys............................................................................. 9 4 Jälkianalyysi............................................................................. 10 4.1 Resurssit.............................................................................. 10 4.2 Laatumetriikat.......................................................................... 11 4.3 Sovelluksen koko....................................................................... 12 4.4 Vertailu muihin projekteihin............................................................... 12 5 Työkäytännöt ja työkalut.................................................................. 14 5.1 Työkäytännöt........................................................................... 14 5.1.1 Testaus........................................................................... 14 5.1.1.1 Yksikkötestaus................................................................. 14 5.1.1.2 Integraatiotestaus............................................................... 14 5.1.1.3 Järjestelmätestaus............................................................... 14 5.1.1.4 Vertaisryhmän suorittama testaus.................................................. 15 5.1.1.5 Käytettävyystestaus............................................................. 15 5.1.2 Kommunikaatio.................................................................... 16 5.1.3 Tuntiraportointi..................................................................... 16 5.1.4 Dokumentointi..................................................................... 16 5.1.5 Pariohjelmointi..................................................................... 16 5.1.6 Progress Radiator................................................................... 17 5.1.7 Muita käytäntöjä.................................................................... 17 5.2 Työkalut.............................................................................. 18 5.2.1 Palvelimella....................................................................... 18 5.2.2 Työasemissa....................................................................... 18 5.2.3 Borland Together Architect 2006....................................................... 18 5.3 Standardit............................................................................. 19 6 Oppiminen............................................................................... 20 6.1 Autere, Aleksi.......................................................................... 20 6.2 Honkaniemi, Turo....................................................................... 20 6.3 Ignatius, Jukka.......................................................................... 20 6.4 Liljavirta, Matti......................................................................... 21 6.5 Rouhiainen, Kimmo..................................................................... 21 6.6 Silvekoski, Pekka....................................................................... 22 6.7 Welin, Jan............................................................................. 22 7 Kurssipalaute............................................................................. 23 7.1 Hyvää................................................................................ 23 7.2 Huonoa............................................................................... 23
8 Viitteet................................................................................... 24
1 (24) 1 Johdanto 1.1 Versiohistoria Versiohistoria Versio Pvm Tekijä Kuvaus Hyväksyjä 0.1 20.2.2006 JI Mallipohja, materiaalin ensimmäisen version keräily - 0.2 20.2.2006 JI Yleistä projektista - 0.3 21.2.2006 JI Etenemiskappaleen taustadatan kerääminen - 0.4 21.2.2006 JI Tavoitteiden täyttymisestä tekstiä. - 0.5 22.2.2006 JI Standardeista ja työkäytännöistä tekstiä - 0.6 23.2.2006 JI Oppimiskappaleen kirjoittamista - 0.7 23.2.2006 JI Oppiminen-kappaleeseen lisäyksiä. Progress Radiator teksti. - 0.8 24.2.2006 JI Kurssipalautteen kirjoittaminen. - 0.9 27.2.2006 TH Järjestelmän laatu, metriikat, testaus - 1.0 27.2.2006 JI Toimittajan tavoitteet, viittaukset tuntiraportti ja metriikkatiedostoihin suojatussa dokumentaatiossa. 2b iteraation tarina. Laatumetriikoista. -
2 (24) 1.2 Projektista Tavoitteena oli luoda visuaalisesti vakuuttava käyttöliittymä kiinteistön ilmastoon liittyvien lukemien helppolukuiseen esittämiseen. Haasteina tehtävässä olivat jouhevan sovelluksen toteuttaminen www-ympäristöön, jonka lähtöaineistona on niin CAD pohjapiirustusta kuin tietokannasta haettavaa antureiden antamaa numeerista dataa. /1/ COTOOL-työkalun tarkoitus on helpottaa Jaakko Pöyryn asiakkaiden, eli kiinteistön omistajien, kiinteistöjen raportointia. Hyvä ja standardeilla työkaluilla toteuteutettava työkalu mahdollistaa COTOOL-seurantaan kytkettävien kiinteistöjen perustamisen Jaakko Pöyryn työntekijöiden toimesta. Jaakko Pöyryllä on itsellään paljon tietämystä Autocad sovelluksesta ja siksi olikin ensisijaisen tärkeää, että kiinteistöjen esitysgrafiikka voidaan luoda ko. ohjelmistolla. Toinen eikä varmasti vähäpätöisempi syy on se, että kiinteistöistä on lähes poikkeuksetta Autocad-piirtustukset saatavilla. Päätimme käyttää hyväksemme SVG-tekniikkaa COTOOLin kuvien esittämiseen. SVG:n avulla pystytään jouhevasti esittämään vektorigrafiikkaa selainympäristössä.lisäksi se mahdollistaa esitysmuodon tekemisen niin hienoksi kuin graafikko pystyy.
3 (24) 2 Edistymisraportti Seuraaviin kappaleisiin olemme keränneet tietoutta projektin edistymisestä. 2.1 PP Projektinsuunnittelu PP-vaiheessa tarkoituksena oli löytää asiakas sekä myydä oma projektiryhmämme asiakkaalle. Löysimme useita mielenkiintoisia projekteja joiden valintaan käytimme management-ryhmän työ/koulukokemusta. Painotimme projekteja jotka olivat meille tutumpia tekniikaltaan (tämä sulki pois esimerkiksi Symbian projektit). Jaakko Pöyryllä oli todella mielenkiintoisen kuuloinen projekti, jossa management-ryhmän visiossa pystyttiin hyödyntämään uutta ja mielenkiintoista tekniikka, ainakin osittain tutussa frameworkissa. Projektisuunnitteluiteraatio oli siitä kokemuksen arvoinen, että ensimmäistä kertaa kurssilla projektin käytännössä aloitti management-ryhmä ja vasta projektisuunnittelu iteraation päätteeksi rekrytoitiin kehittäjät. Tämä aiheutti sinänsä ongelmia, että suurin osa kurssilaisista oli jo heti kurssin alkaessa muodostaneet "kaveripohjalta" ryhmät, ja vapaiden/sopivien kehittjäien löytäminen oli vaikeaa. Onnistuimme kuitenkin löytämään kehittäjiä, joilla oli Java-ohjelmointikokemusta, tietämystä tietokannoista sekä käytettävyyskokemusta. Yksi tärkeimmistä PP-vaiheen tuloksista oli "Proof-of-concept"-tyyppinen prototyyppi Autocad/SVG/www-selain toiminnasta. Tämä vakuuttikin sekä asiakkaan, että kurssin henkilökunnan projektin onnistumismahdollisuudesta huolimatta tiedossa olevasta suuresta haasteesta: Vektorimuotoisen grafiikan esittämisen ja visualisoiminen www-selainympäristössä on tunnetusti haastavaa ja käytännössä ainoat tällaiset sovellutukset tehdään nykyään kustomoiduilla Shockwave-grafiikoilla. PP projektisuunnittelu meni kaiken kaikkiaan erinomaisesti, emmekä pysty sanomaan, millä olisimme sen voineet kovin paljon paremmin hoitaa. 2.2 I1a Toteutus 1a Heti toteutusiteraation alkuun huomasimme, että kehittäjien J2EE kokemus vaati koulutusta, ja järjestimmekin kehittäjille arkkitehdin pitämän Rauinfo-koulutuksen. Tämäkin koulutus osoittautui riittämättömäksi, ja järjestimme uuden koulutuksen asiakkaan teknisen asiantuntijan avulla. Pikkuhiljaa näiden, sekä muiden sovellettujen työmenetelmien avulla tietämus kasvoi. Samaan aikaan oli tarkoitus saada arkkitehtuuri suunniteltua ja lyötyä asiakkaan teknisen asiantuntijan kanssa lukkoon sille tasolle, että heti seuraavassa ali-iteraatiossa voisimme toteuttaa loppukäyttäjän käyttöliittymää. 2.3 I1b Toteutus 1b Arkkitehtuuri ei valmistunut ajallaan, ja tässä vaiheessa teimme yhteistyössä kehittäjien kanssa projektipäällikön esittämän draftin päälle tarkempaa suunnittelua. Tämä aiheutti valitettavan menetyksen käytettävissä olevissa kalenteriajassa, vaikka resursseja ei ollutkaan kulunut paljoa. Kalenteriaika ei vain yksinkertaisesti riittänyt käyttöliittymän toteuttamiseen aikataulussa. Samaan aikaan teimme roolivaihdoksen, jossa kehittäjä Kimmo Rouhiainen astui arkkitehdin roolin, Matti Liljavirran siirtyessä kehittäjäksi. Rouhiainen teki ylimääräistä työtä joululoman aikaan, jotta toisen iteraation alusta todella pääsisimme toteuttamaan. Joululoman aikana Rouhiainen ja Ignatius pitivät muutaman katselmuksen arkkitehtuuriin liittyen, ja tällä saimme vihdoin arkkitehtuurin sille mallille kuin se oli alunperin aikataulutettu 1a iteraatioon.
4 (24) 2.4 I2a Toteutus 2a Koska olimme edellisen iteraation ongelmien takia myöhässä aikataulusta, teimme asiakkaan kanssa varsin paljon priorisointia toteutettavien toiminnallisuuksien suhteen. Päätimme mm. tehdä ylläpitäjän liittymästä varsin minimaalisen toteutuksen, sekä luopua koodin optimoinnista. Pystyimme valitsemaan näin koska asiakkaan tekninen asiantuntija pystyy tekemään optimointia varsinaisen Rauinfo-integroinnin yhteydessä. Tässä iteraatiossa pääsimme vasta todellisten toteutustehtävien pariin ja COTOOL-sovellus lähtikin edistymään hyvin. Iteraatiodemossa pääsimme jo esittämään visuaalisesti tietokannasta haettua anturidataa. Toki tässäkin iteraatiossa vastaan tuli aikataulu. Työmäärään nähden kalenteriaikaa on kurssilla nykymallissaan hyvin rajatusti. Kulutimme edeleen paljon aikaa Struts/Apache/SVG-opiskeluun, mutta toteutustehtävät sujuivat hyvin. Ensimmäisen iteraation palautteessa saimme haukkuja laadusta, vaikka käytännössä mitään sovelluskoodia ei oltu tehty. Siksi laatupäällikkö Turo Honkaniemi kiinnitti huomattavasti huomiota testauksen suunnitteluun, ja jalkautimme JUnit-testausta modulitestauksen toteuttamiseen. Kehittäjä Autere kunnostautui ryhmän JUnit-guruna ja toimikin varsinaisena tukijalkana sovelluskoodin laadun varmistamisessa. Flunssilta ei projektimme välttynyt: Arkkitehdin rooliin siirtynyt Rouhiainen sairasteli juuri 2a iteraation päätteeksi, mutta saimme silti tarvittavat tehtävät hoidettua. 2a iteraatiodemossa asiakas oli varsin tyytyväinen aikaansaannokseen, mutta huolta aiheutti Matti Liljavirran panos projektin suorittamisessa. Yhteistyössä kurssin henkilökunnan kanssa motivoimme Liljavirran takaisin projektin pariin. Suoritimme iteraation aikana myös järjestelmän käytettävyystestauksen. Sen avulla saimme hyvää palautetta käytettävyyteen liittyen. 2.5 I2b Toteutus 2b Iteraatiosuunnittelussa priorisoimme entisestään tärkeimpiä toiminnallisuuksia, ja luovuimme esim JFreeChart -työkalulla luotujen olosuhderaporttien tekemisestä COTOOL:in lisätietovälilehdelle. Tämänkin syynä oli se, että näiden tekemisestä asiakkaan teknisellä asiantuntijalla on huomattavasti kokemusta ko. raporttien tekemisestä. Eli ytimeytettynä: Keskityimme tekemään COTOOL:in ydinlogiikkaan, jonka laadukkaalla toteutuksella on jatkokehittämistä helpottava vaikutus. 2b vaiheen loppupuolella suoritimme vertaisryhmätestauksen, jonka avulla saimme ulkopuolista näkemystä järjestelmäämme liittyen. Vertaisryhmätestauksen tulokset olivat kannustavat eikä suuria puutteita löydetty. Asiakkaan työntekijöille tehty käytettävyystestaus meni myös se mukavasti, ja saimme rakentavaa palautetta käyttöliittymän toimivuudesta. Koska vasta 2b iteraatiossa pääsimme vasta kunnolla vauhtiin, tuli tuntiarviot ylitettyä ja itse kukin meistä teki ylitöitä. Valitettavasti kalenteriaika loppui kesken, ja vaikka tietotaito olisi ollut hankittuna emme yksinkertaisesti ehtineet toteuttamaan ylläpitäjän liittymää sille tasolle kuin asiakkaan toivomus oli.
5 (24) 3 Tulokset 3.1 Asiakkaan tavoitteet Asiakkaan tavoitteena oli saada olemassa olevaan Rauinfo www-palveluun lisäsovellus, jolla loppukäyttäjä pystyy seuraamaan kiinteistönsä/kiinteistöjensä ilmastoinnin tilaa. Asiakkaan tavoitteena oli saada tärkeää markkinointilisää tuottava osa jo toimivaan www-palveluun, ja siksi tuotteen visuaalinen näyttävyys sekä helppokäyttöisyys olivat erittäin merkittävässä roolissa. /2/ Seuraavassa taulukossa on listattu projektisuunnitelmaan kirjoitetut asiakkaan tavoitteet ja saavutetut tulokset. Toteutumisen kattavuus arvioitiin seuraavalla asteikolla: 1. Ei täyttynyt 2. Täyttyi osittain 3. Täyttyi Asiakkaan tavoitteet Nro Tavoite Tarkistuskriteeri Toteutuminen Kattavuus 1. Tuotteen jatkokehitys on mahdollista 2. Toteutettu järjestelmä on käytettävyydeltään hyvä, sekä visuaalisesti vakuuttava 3. Sovitut toiminnot on toteutettava laadukkaasti ja järjestelmän tulee olla luotettava 4. Järjestelmän arkkitehtuuri sopii olemassa olevaan järjestelmään. Asiakas arvio jatkokehitysvaiheessa. Lisäksi asiakas arvio, onko vaatimusmäärittelyssä otettu huomioon tuotteen laajentaminen. Asiakas arvioi käyttöliittymätestauksen perusteella. Asiakas arvioi myös valmiin tuotteen ulkoasun. Asiakas arvioi luovutusvaiheessa työn laadun, sekä arvioi testitapausten ja rinnakkaisryhmävertailun tulosten perusteella luotettavuuden. Asiakas arvioi, onko tämä otettu huomioon vaatimusmäärittelyssä. Katsemoinnin yhteydessä asiakkaan tekninen asiantuntija tarkasti tuotetun koodin jatkokehitettävyyden ja hyväksyi sen. Käytettävyystestaus paljasti muutamia asioita, mutta ne ehdittiin korjaamaan. Testitulokset ovat hyvät loppukäyttäjän käyttöliittymän osalta, mutta aikatauluongelmien takia ylläpitäjän liittymää ei ehditty täydellä kattavuudella toteuttamaan käytettävyystestaamaan. COTOOL on tehty hyvin Rauinfon olemassa olevaa järjestelmää hyväksikäyttäen (mm. kuvan lataaminen, anturidatan hakeminen olemassa olevien rajapintojen avulla.) 3 3 2 3
6 (24) Asiakkaan tavoitteet Nro Tavoite Tarkistuskriteeri Toteutuminen Kattavuus 5. Onnistunut yhteistyö asiakkaan ja toimittajan välillä 6. Toteutus on hyvin dokumentoitu 7. Tuotettu järjestelmä on riittävän suorituskykyinen. 8. Projekti saadaan toteutettua aikataulussa. Asiakas ja toimittaja arvioivat projektin lopussa. Asiakas arvostelee toimitetun dokumentaation. Asiakas arvioi toimittajan suorittamien testitapausten, rinnakkaisryhmävertailun tulosten sekä omien testiensä perusteella. Täyttyy kun projekti pysyy kurssin aikataulussa. 9. Tuote on skaalautuva. Asiakkaan suorittamat rasitustestit. 10. Palkitseva projekti molemmin puolin Arvioidaan projektin aikana opittu ja koettu. Asiakas saa toivomansa tuotteen, ja toimittaja hyvän arvosanan sekä saunaillan. Yhteistyö on toiminut hyvin, ja olemme pystyneet vaihtamaan tietoutta paljon. Katselmoinnin yhteydessä 3 asiakkaan tekninen asiantuntija oli suurimmilta osiltaan tyytyväinen dokumentaatioon/kommentteihin, Muutamat puutteet (Javascript-kommentointi) korjattiin vielä katselmoinnin jälkeen Suorituskyky sovelluksella on latautuessa huono, johtuen asiakkaan kanssa tehdystä priorisoinnista. Sovelluksen arkkitehtuuri on kuitenkin riittävän nopea, ja suorituskykyongelmat tulevat tämänhetkisesta tavasta käyttää tietokantarajapintaa (rajapinta mahdollistaa yhden anturin haun kerrallaan). Viimeisen priorisoinnin mukaiset tavoitteet ehdittiin toteuttaa kurssin aikataulun puitteissa. Kts. kohta 7. 1 Projekti oli ainakin toimittajalle hyvin opettavainen ja asiakas sai priorisoinnin ansiosta käyttöönä käyttökelposen sovelluksen. 3 1 3 3
7 (24) 3.2 Toimittajan tavoitteet Projektiryhmän keskeisenä tavoitteena oli syventää ohjelmistokehitysprojektin tuntemustaan. Osalla ryhmän jäsenistä oli jo kokemusta laajoistakin ohjelmistoprojekteista, mutta toisille tämä on ensimmäinen kerta kun näin laaja projekti vedetään kokonaisuudessaan läpi. Koko projektiryhmän yhteiset tavoitteet, sekä niiden toteutuminen on listattu seuraavassa taulukossa. /2/ Toteutumisen kattavuus arvioitiin seuraavalla asteikolla: 1. Ei täyttynyt 2. Täyttyi osittain 3. Täyttyi Toimittajan tavoitteet Nro Tavoite Tarkistuskriteeri Toteutuminen Kattavuus 1. Projektiryhmä kykenee tuottamaan asiakkalle lisäarvoa tuottavan sovelluksen vaatimusmäärittelyn mukaisesti. 2. Uusien tekniikoiden/käytäntöjen oppiminen 3. Opitaan työskentelemään ryhmässä Asiakas arvioi työn tuloksen projektin päätteeksi Valmiissa tuotteessa käytettyjen tekniikoiden henkilökohtainen arvioiminen kurssin päätteeksi. Henkilökohtainen arvio ryhmätyöskentelyn laadusta iteraatiokierroksen päätteeksi Vaatimusmäärittelyn kriteerien perusteella pystyimme toteuttamaan asiakkalle lisäarvio tuottavan sovelluksen. Lisäksi asiakas on ilmaissut olevansa tyytyväinen aikaansaannokseen Koko ryhmä oppi paljon uutta, ja on tyytyväinen projektityön mahdollistamaan lisäoppimiseen. Ryhmätyöskentely alkoi toimimaan hyvin ja viihdyimme yhteisissä työsessioissa. 4. Kiitettävä kurssiarvostelu Kurssiarvostelu Kurssiarvostelu saadaan vasta dokumentin kirjoittamisen jälkeen. 5. Laadukas ja tuottava työskentely asiakkaan kanssa Arvioidaan yhdessä asiakkaan kanssa projektin päätteeksi. Yhteistyö onnistui hyvin, ja asiakkaalta saatiin arvokasta lisäopetusta/tukea. 3 3 3? 3
8 (24) 3.3 Järjestelmän laatu Seuraavassa matriisissa on arvioitu tuotteen laatua. COTOOLin laatu osa-alueittain Laatuluokitukset Projektissa pyrimme arvioimaan järjestelmän laatua muun muassa yksikkötestien rivimäärällä ja kattavuudella, integraatio ja järjestelmätestien lukumäärällä, käytettävyys- ja vertaisryhmätestauksesta saadulla palautteella, koodi tarkasteluiden kattavuudella sekä havaittujen bugien lukumäärällä. Kokonaisuudessaan voidaan todeta, että järjestelmän laatu on hyvä. Käyttöliittymä saatiin hyvin testattua sekä ryhmän omassa, että käytettävyys- ja vertausryhmätestauksessa.bisneslogiikka, DAO ja kantaproceduurit testattiin kattavasti yksikkötestien avulla.tehty koodi myös katselmoitiin yhdessä JP:n teknisen henkilön kanssa ja häneltä tulleet parannusehdotukset otettiin huomioon. Koodin tehtiin tarpeelliset JavaDocit.
9 (24) 3.4 Jatkokehitys Jatkokehitystä on pyritty helpottamaan niin paljon kuin mahdollista kattavalla kehittäjän manuaalilla ja teknisellä dokumentaatiolla. Ohjelmakoodista on lisäksi hyvät private -näkyvyyden Javadoc -dokumentaatiot. Sovellukseen jäi muutamia (4 kpl) avoimia bugeja, joiden kriittisyystaso on melko matala. - SVG-pluginin menun disablointi ei toimi - Aluetta (Area) haettaessa ei varmisteta sen kuuluuvuutta oikeaan rakennukseen (Building). - ParentAreaId:tä ei varmisteta validiksi parentiksi arealle - Jos Devicellä ei ole mittausarvoja, kaatuu joko Cotool tai Rauinfo Avoimista bugeista tarkka kuvaus teknisessä dokumentaatiossa. Kaikki tiedossa olevat jatkokehityskohteet ovat olleet tiedossa jo pitkään ja arkkitehtuurin sekä tietorakenteen tiedetään mukautuvan näiden toteutukseen hyvin. Jatkokehityskohteita ovat: - Uudentyyppiset tunnusluvut (mittausarvot) - Uudentyyppiset mittalaitteet - Aikavälin valinta - Päällekäisten alueiden esittäminen samassa kuvassa Jatkokehityskohteet ja tukea niiden toteuttamiseksi löytyy myös teknisestä dokumentaatiosta.
10 (24) 4 Jälkianalyysi 4.1 Resurssit Projektille oli alunperin resursoitu yhteensä 1330 tuntia. Ylimääräisen opiskelun takia lähes kaikkien tunnit ylittyivät hieman, n. 10% verran. Tunnit jakautuivat varsin tasaisesti, vaikka toteutus 2 iteraation alussa oli huoli yhden kehittäjän panoksesta. Alla olevaan taulukkoon on listattu toteutuneiden tuntien jakautuma henkilöittäin. Raporttiin on lisätty kirjoitushetken jälkeen pidettävän demotilaisuuden tunnit (1h/hlö). Toteutusiteraatioiden tuntiraportoinnit löytyvät kokonaisuudessaan Excel-tiedostoina dokumentaation liitetiedostoista. Resurssimatriisi PP Toteutus1a Toteutus1b Toteutus2a Toteutus2b Yht. Henkilö Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. AA 0 0 36,3 26,2 65,3 38,1 71,2 91,9 43,8 41,1 170 197,3 JI 49 48 51,7 40 49,5 43,5 23,6 27,0 34,4 40,5 170 199 JW 0 0 44,3 23,5 70,5 20,5 54,7 45,5 71,3 102,0 170 191,5 KR 0 0 55,8 33 61 31 76,2 80,5 37,8 60 170 204,5 ML 44 36 61 41,5 39 20,5 22,7 4,3 77,3 89,5 170 191,8 PS 0 0 43,8 38,5 55 31,5 37,2 65,8 38,3 39 170 174,8 TH 49 51,5 37 33,5 22,5 11,5 27,8 28,5 48,2 45,5 170 170,5 Yht. 142 135,5 329,9 236,2 362,8 196,6 313,4 343,5 351,1 417,6 1190 1329,1 Alla olevassa kuvaajassa näkyy kirjoitushetkeen asti suunnitellut ja toteutuneet kumulatiiviset tunnit. Lisäksi kaavioon on arvioitu palautuksen sekä iteraatiodemon vaatimat tunnit kaikille toimittajan jäsenille. Ensimmäisesssä toteutusiteraatioissa oli vaikeuksia käyttää kaikkia resursoituja tunteja, mutta toisessa tehtiin jo ylitöitä tavoitteiden saavuttamiseksi.
11 (24) Kumulatiiviset tunnit 4.2 Laatumetriikat I1:ssa esille tulleet bugit Vakavuus Estävä 0 Kriittinen 0 Vakava 0 Lievä 2 Kosmeettinen 2 Yhteensä 4 I2:ssa esille tulleet bugit Vakavuus Estävä 0 Kriittinen 1 Vakava 3 Lievä 4 Kosmeettinen 2 Yhteensä 10 Palautusversiossa olevat BUGIT Vakavuus Estävä 0 Kriittinen 0 Vakava 1 Lukumäärä Lukumäärä Lukumäärä
12 (24) Lievä 3 Kosmeettinen 0 Yhteensä 4 On huomioitava, ettei ensimmäisen iteraation aikana ehditty tehdä muuta kuin käyttöliittymään liityvää toiminallisuutta, joten luvut eivät ole täysin vertailukelpoisia. Ensimmäisessä iteraatiossa oli myös erittäin vaikea vetää rajaa bugille ja ei-vielä-tehdyille toiminallisuuksille. Yksikötestauksen perusteella saimme seuraavia laatuun liittyviä tunnuslukuja: Yksikkötestien suhde tuotettuun koodiin on LOC / (DAO LOC + BL LOC) = 37%. Yksikkötestit kattavat 36% DAO:n rivimääristä ja Bisneslogiikasta 44%. Tarkemmat metriikat löytyvät liitetiedostoista Tuotteen laatua pyrittiin myös mittaamaan käytettävyystestauksen avulla. Pääkriteereinä oli se, miten havainnollinen, helposti ja nopeasti käytettävä tuote oli. Testisession perustella voidaan todeta, että tuote oli helppokäyttöinen ja hyvin intuitiivinen. Lisäksi sekä käytettävyystestauksen ja vertaistestauksessa saatu palaute oli pääasiassa positiivista. 4.3 Sovelluksen koko Tarkastimme toteutetun sovelluksen ohjelmistokoodirivimäärän StatCVS ohjelmalla. Tulokset eri kokonaisuuksittain alla olevassa taulukossa sekä kuvaajassa. Kaikki metriikka löytyy dokumentaatiosta liitetiedostoista LOC statistiikat kokonaisuuksittain LOC statistiikat kokonaisuuksittain graafisesti esitettynä 4.4 Vertailu muihin projekteihin
13 (24) Projektimme oli ensimmäisen toteutusiteraation jälkeen seitsemäntenä 17sta kurssin projekstista. Tämä oli vielä pitkälti projektisuunnitteluiteraation hyvien pisteiden ansiosta. Toisaalta suurin osa pisteistä on tässä vaiheessa jakamatta joten on hyvin vaikea arvioida miten tilanne on projektin päätteeksi. Vertailimme muutamia tunnuslukuja muutamaan kouluprojektina tehtyyn ohjelmistoprojektiin. Ainakin näillä tunnusluvuilla mitaten olemme tehneet melko keskiverron projektin. Vertailu vanhoihin ohjelmistoprojekteihin Ryhmän nimi LOC COM JUnit/LOC Ryhmäkoko Tunnit Data Sailors 12839 - * 7 1329 Kamomilla 12784 6658-7 1330 Electric Seven 31000?? 4,3% 7 1284 PPT 35000 9000-7 1454 * Emme saaneet StatCVS-ohjelmistolla kommenttirivien määrää mukaan raportteihin.
14 (24) 5 Työkäytännöt ja työkalut 5.1 Työkäytännöt Tähän kappaleeseen on kerätty tärkeimmät projektiss sovelletut työkäytännöt. Työkäytännöistä on pyritty löytämään projektille hyödylliset sekä haitalliset näkökulmat, jotta niiden soveltaminen tulevissa projekteissa olisi mahdollista. 5.1.1 Testaus Käytimme testauksessa perinteistä V-mallia: 5.1.1.1 Yksikkötestaus Yksikkötestauksella pyrittiin varmistamaan yksittäisen moduulin laatu. Testaus suoritettiin käyttäen JUnit-työkalua ja se sopi hyvin tarkoitukseen. Saimme tehtyä yksikkötestit kaikille tärkeimmille moduuleille. Positiiviset kokemukset: - Löydettiin virheitä, joita koodatessa ei tullut ajatelleeksi. - Hyvä tapa varmistua yksittäisen moduulin laadusta. - Auttoi refaktoroinnissa. Negatiiviset kokemukset: - Hankala tehdä JavaScripteillle. - Testitapauksia olisi pitänyt miettiä ennen kuin niitä alkaa tekemään. - Ei olisi pitänyt jättää testausta yhden henkilön harteille. 5.1.1.2 Integraatiotestaus Integraatiotestauksella pyrimme varmistamaan, että kahden tai useamman moduulin yhteistoiminnan. Tällöin testattiin alueiden ja laitteiden tulemista bisneslogiikan läpi yksi- ja monikerroksissa kuvissa. Suoritimme integraatiotestit manuaalisesti ja ne menivät onnistuneesti läpi. Positiiviset kokemukset: - Hyvä tapa testata useamman moduulin yhteistyötä. Negatiiviset kokemukset: - Abstraktio taso korkea, vaikea käsittää mitä tarkoitetaan. - Mahdollisten inputtien lukumäärä todella suuri. 5.1.1.3 Järjestelmätestaus
15 (24) Järjestelmätestin avulla varmistimme, että järjestelmän eri osat toimivat halutulla tavalla yhdessä. Ne suoritettiin ns. blackbox tekniikka käyttäen. Järjestelmätestit tuotettiin pääasiassa vaatimusmäärittelyissä esitettyjen käyttötapausten pohjalta. Testit suoritettiin sekä ensimmäisen että toisen iteraation aikana aina ennen demotilaisuuksia sekä ennen käytettävyys-, ja vertaisryhmätestausta. Iteraatioiden lopulla suoritimme viralliset järjestelmätestit. Testaus oli ensimmäisessä iteraatiossa hyvin suppeaa koska toiminnallisuutta ei oltu saatu paljon valmiiksi siihen menessä. Toiseen iteraatiossa saimme järjestelmätestit todelliseen hyötykäyttön. Niillä saatiin katettua todella hyvin järjestelmätason testaus, johtuen osittain toiminnallisuuden rajoittuneisuudesta.kirjattujen testitapausten lisäksi järjestelmälle tehtiin erillaista exploratiivista testausta ja pyrittiin erilaisille syötteillä "hajoittamaan" se. Positiiviset kokemukset: - Hyvä tapata testata kokonaisuutta. - Hyvä tapa testata vaadittuja käyttötapauksia. - Testauksen pystyy suorittamaan henkilö joka ei välttämättä tunne koodia/järjestelmää Negatiiviset kokemukset: - Pinnallinen 5.1.1.4 Vertaisryhmän suorittama testaus Kaffetauko toimi DataSailorssin vertaistestausryhmänä. Testichartereiden tehtiin järjestelmän testien perusteella, jonka lisäksi vertaistestausryhmältä pyydettiin kommentteja käytettävyyteen ja järjestelmän ulkoasuun liittyen. Testisessiot suoritettiin viikko ennen kurssin suosittelemaa ajankohtaa. Vertaisryhmä löysi muutaman pienehkön bugin, jotka korjattiin. Muuten järjestelmä toimi hyvin ja ryhmältä saatu palaute oli positiivista. Vertaustestaus oli projektin kannalta hyödyllistä ja oli hyvä idea suorittaa testit hieman aikaisemmin, koska siten meille jäi enemmän aikaa korjailla esiin tulleita ongelmakohtia. Positiiviset kokemukset: - Ulkopuolinen arvio järjestelmästä. - Tuo esille ongelmakohtia, joille itse on "sokea" Negatiiviset kokemukset: - Käytännön järjestelyt vievät aikaaa - Testauksessa ei päästä "pintaa syvemmälle" 5.1.1.5 Käytettävyystestaus Koska käyttöliittymän käytettävyydellä oli projektissa suuri merkitys, päätimme suorittaa käytettävyystestauksen projektissa. Alun perin tavoitteena oli, että olisimme suorittaneet käytettävyystestauksen ensimmäisen iteraation aikana, mutta valitettavasti emme saaneet siihen meneessä tarpeeksi toiminallisuutta valmiiksi, jotta testaus olisi ollut järkevää, siksi suoritimme sen vasta toisen iteraation alkuvaiheessa. Valitsimme kaksi Jaakko Pöyryn työntekijää koehenkilöiksi ja he testasivat erikseen käyttöliitymän. Alunperin tavoitteena oli, että testihenkilöt olisivat olleet ei-teknisiä henkilöitä, mutta jouduimme tyytymään pariin insinöörin, mikä ei välttämättä ollut huono asia, koska he osasivat antaa hyviä vinkkejä koskien käyttöliitymään. Testaussessiot menivät kokonaisuudessaan hyvin ja ne olivat hyödyllisiä testauksen kannalta.kuten vertaisryhmätestauksessa, saatu palaute oli pääasiassa positiivista. Muutama parannusehdotuskin saatiin ja niitä käytettiinkin järjestelmän kehityksessä. Positiiviset kokemukset: - Ulkopuolinen arvio järjestelmästä.
16 (24) - Mahdollistaa, että ei-tekniset henkilöt testaavat järjestelmän. - Tuo esille ongelmakohtia, joille itse on "sokea" Negatiiviset kokemukset: - Käytännön järjestelyt vievät aikaaa - Testauksessa ei päästä "pintaa syvemmälle" 5.1.2 Kommunikaatio Vaikka kommunikaatiomenetelmiin kiinnitettiin projektisuunnitelmassa paljon huomiota, loppujen lopuksi selkeästi tehokkaimmiksi tavoiksi muodostuivat: - Viikkopalaverit - Sähköpostilista Mm. puhelinta ei juurikaan käytetty, eikä myöskään pikaviestimiä kuin satunnaisten projektiryhmän jäsenten välillä. Kommunikointi oli riittävän tehokasta mutta suurimpana osasyynä tähän oli asiakkaan tarjoamat hyvät työtilat, jossa koko toimittajan ryhmä pystyi työskentelemään kerralla. 5.1.3 Tuntiraportointi Tuntiraportointi tehtiin vain tätä projektia varten perustettuun Excel-tiedostoon. Excel-tiedosto pidettiin kaikkien saatavilla versionhallintajärjestelmässä ja sinne raportoitiin tunnit vähintään viikon tarkkuudella. Järjestelmä toimi hyvin lukuunottamatta muutamia ongelmia, jotka johtuivat ei-ajantasalla olevaan tiedostoon tehdyistä muutoksista. Koska Excel-tiedostot ovat binäärisiä, ei CVS:n työkaluin niiden yhdistämistä pystynyt tekemään, vaan joutui käsin siirtämään tuntejaan tiedostosta toiseen. Raportointitarkkuus oli tällaiseen projektiin riittävä, ja käytettyjä resursseja pystyttiin seuraamaan hyvin. Varsinaiseen työkäyttöön tällainen Excel-tiedosto ei tosin sovellu johtuen mm. yllämainituista versiontiongelmista. Oikea, esim intranetissä toimiva, tuntiraportointisovellus olisi suuremmissa tai pienemmissäkin, mutta toistuvissa projekteissa tarpeen. 5.1.4 Dokumentointi Kaikki olivat tyytyväisiä dokumentiin käytetyn työkalun tulostusjäljestä ja versiointimahdollisuuksista. Esimerkiksi Word olisi tuottanut paljon hajanaisempaa jälkeä, ja sen versioiminen CVS:llä olisi ollut vaikeata. Ainoat haittapuolet oli dokumentaation XML-pohjaisuus ja sen kohtuullisen tiukka XML-Schema. Käytännössä tämä näkyi niin, että muotoilun tekeminen ei ollut niin triviaalia kuin esim. Wordiä käyttäessä. 5.1.5 Pariohjelmointi Pariohjelmointi oli Jukka Ignatius'en ja Kimmo Rouhiaisen SEPA-aiheena. Menetelmä saatiin jalkautetuksi projektiin todella hyvin ja sen tuoma hyöty projektin onnistumiselle on kiistaton. Projekti olisi hyvin saattanut kaatua täysin tarvittavan kompetenssin puutteeseen, ellei tietämystä olisi levitetty tällä työmenetelmällä. Katso tarkemmin SEPA työstä Pariohjelmointi.
17 (24) 5.1.6 Progress Radiator Toiseen iteraatioon otimme oman sovellutuksen ns. Progress Radiatorista. Tällä saimme helpotettua tehtäväjakoa sekä näimme konkreettisesti projektin etenemisen. Avoimet tehtävät kirjoitettiin tehtävälistaan, ja kehittäjät ottivat sieltä aukiolevia. Tehtävät saattoivat olla myös määrättyjä, jolloin lapussa luki ko. kehittäjän/kehittäjäparin nimi. Tehtävälista Sovelsimme myös projektimme laajuudelle sopivan bugiseurantajärjestelmän Progress Radiator -ajatuksen pohjalta. Perusidea oli, että bugi-listaan lisättävät kuvaukset sisältävät joko a) muistilapun kehittäjälle itselleen b) taskilapun muille. Kuvauksen määrä pidettiin minimaalisena ja sen sijaan lappuun kirjoitettiin vian löytäjän nimi jolloin pystyi kysymään mahdollisesti tarvittavia lisätietoja Bugiseuranta 5.1.7 Muita käytäntöjä
18 (24) Muita mainitsemisen arvoisia, projektin toteutuksessa käytettyjä työmenetelmiä olivat: - Katselmoinnit - Evolutiivinen kehitys, yksinkertainen suunnittelu ja refaktorointi - Reflection Workshop Kaikilla näillä menetelmillä pystyimme parantamaan tuotteen laatua, ryhmätyöskentelyn laatua sekä pääsemään tavoitteisiin riippumatta projektin alkuvaiheen kompetenssipulasta. 5.2 Työkalut Projektissa käytetyt työkalut olivat jo alunalkajaan melko tarkasti määrätyt, koska sovellus tehtiin valmiin alustan (Rauinfo) päälle. COTOOL:in yhteydessä käytimme tämän lisäksi esimerkiksi koodin kattavuuden arviointiin EMMA-työkalua, SVG-tiedoston näyttämiseen selaimessa Adoben pluginia. 5.2.1 Palvelimella Tuotantoympäristö on jo olemassa, joten palvelinympäristö on siltä osin määrätty: - Käyttöjärjestelmä: Microsoft Windows Server 2003 Standard Edition - Tietokantapalvelin: Microsoft SQL Server 2000 - WWW-palvelin: Tomcat 5.5 Lisäksi WWW-palvelimelle on asennettu seuraavat kolmannen osapuolen kirjastot: - Tietokantayhteydet: Microsoftin oma JDBC kirjasto - Graafien tuottamiseen: jfreechart 0.9.20 - Lokitus: java.util.logging 5.2.2 Työasemissa Työasemien kehitysympäristö on myös olemassa: - Käyttöjärjestelmä: Microsoft Windows XP - WWW-palvelin: Apache Tomcat 5.5 - IDE: Eclipse 3.1M7 + Pluginit: JUnit 3.8.1 /3/, EMMA 2 /4/ - Dokumentointi: Vex 1.2.1 - Versiohallinta: Eclipisen sisäänrakennettu CVS - Adobe SVG Viewer 3.03, Build 94 & 6.0 Development Release 1, build 38363 5.2.3 Borland Together Architect 2006 Käytimme Borland Together Architect 2006 (stand alone asennus) sovellusta arkkitehtuurikaavioiden suunnittelussa. Työkalun käyttöliittymä ei ole mitään parhaita mutta emme ole mitään puutteita ohjelmasta löytäneet. Together vaatii melko paljon tehoa/muistia ja järjettömän määrän hiiriklikkauksia per operaatio, mutta muuten sovellus on tarkoitukseensa hyvä. Käytimme myös reverse-engineerin osuutta tehdessämme kaavioita tekniseen dokumentaatioon. Tämäkin toimi, mutta
19 (24) vasta tuntien harjoittelun jälkeen hyvin. Jotain pientä epävakaisuutta 2006 versiossa on, varsinkin Eclipse pluginina käytettäessä. Stand-alone asennus toimii tätä paremmin. Lisäksi käytännön hankaluuksia aiheutui, kun ohjelmaa pyörittettiin käytännön pakosta hieman alitehoisella koneella (PIII 1,1 GHz ja 512MB). 5.3 Standardit Kuten asiakkaan projektille asettamat tavoitteet kertoivat, standardin ja jatkokehitettävän tuotteen tekeminen oli tärkeää: (kts. lyhenteet) Projektissa päädyttiin alkuperäisen suunnitelman mukaan käyttämään seuraavia standardeja: - XML /5/ - XSL/XSL-.FO /6/ - SVG /7/ Käytetyistä standardeista tarkemmin lisää teknisessä dokumentaatiossa. /9/
20 (24) 6 Oppiminen Tässä kappaleessa on pyritty arvioimaan henkilökohtaista oppimista. Lähteenä ovat henkilökohtaiset kirjoitukset projektinryhmän jäseniltä, sekä alkuperäiset tavoitteet projektisuunnitelmasta. /2/ 6.1 Autere, Aleksi Alkupäinen tavoite: Mukava olisi oppia kaikkea uutta. Ryhmätyötaitojen hiominen lienee tälläisessa projektissa kaikkein arvokkainta, uusia tekniikkoja kun voi opiskella pelkän koneen äärellä. Toki uusia tekniikoitakin on mukava oppia, lähinnä testaukseen liittyen. Oppimisen toteutuminen: Tämä projektikurssi yhdessä SoberIT:n testauskurssin (T-76.5613) kanssa ovat yhdessä opettaneet "oikeasta" testauksesta sekä sen tarpeellisuudesta. Odotin että olisin saanut vain suoritettavia testaus tehtäviä, mutta sattuneista syistä sain kontolleni myös jonkin verran järjestelmän arkkitehtuurin suunnittelua ja toteutusta, testauksen lisäksi. Lisäksi jouduin itse suunnittelemaan ja toteuttamaan lähes kaikki yksikkötestit. Nämä olivat opettavia kokemuksia niin tekniikoiden kuin projektin hallinollisenkin puolen (kaikki ei mene aina niin kuin suunnitellaan) osalta. Tekniikoista tutuiksi kiitettävästi tuli yksikkötestaus (JUnit), mielestäni pääsin hyvin myös ennen tuntemattomasta J2EE:stä, Strutsta perille lisäksi Javan käyttöä yritysympäristössä oli myös hyödyllistä oppia. Myös ohjelmistoprojektin ryhmän toimivuuden teorioita (esim. kommunikaation vaikeus) pystyi hyvin todentamaan käytännössä vaikka en projektin johtoon kuulunutkaan. 6.2 Honkaniemi, Turo Alkupäinen tavoite: Kurssi tarjoaa hyvät puitteet olla mukana ohjelmistonkehitysprojektissa alusta loppuun. Aikasemmin olen ollut mukana vain projektin keskivaiheessa tai lopussa. En ole aikaisemmin ollut mukana projektin johtamisessa, joten toivon saavani hyvää kokemusta myös siihen liittyen. Asiakas rajapinnassa toiminen tarjoaa hyödyllistä kokemusta ja uutta minulle on myös vaatimusmäärittelyjen tekeminen käytännön projektissa. Edellä mainittujen lisäksi toivon oppivani jotain minulle ennestään tuntemattomista teknologioista ja niiden käytöstä. Oppimisen toteutuminen: Projektin Management tiimissä toimiessani vastaan on tullut useita haasteita, jotka ovat opettaneet paljon. Näihin haasteisiin kuuluivat muun muassa kehittäjien rekrytointi, uusiin teknologioihin tutustuminen, projektin aikataulussa pysyminen sekä erilaiset laadunvarmistuksen hallintaa liittyvät tehtävät. Olen varma, että tämän kurssin jälkeen minulla on paremmat puitteet toimia projektin johtoon/laadunhallintaan liityvissä tehtävissä. Projekti tarjosi myös hyvät mahdollisuudet suorittaa vaatimustenmäärittelyä, käytettävyystestausta ja laadunhallinta käytännössä. Ainoastaan uusien teknologien käytöstä jäin hieman tavoitteistani. Projektissa aikaa meni niin paljon hallinnollisten asioiden hoitamiseen, joten en ehtinyt tutustua syvällisemmin käytettyihin teknologioihin. Kuitenkin kokonaisuudessaan kurssi opetti paljon ja siitä oli varmasti hyötyä myös tulevaisuussa eri ohjelmistoprojekteissa toimimiseen. 6.3 Ignatius, Jukka Alkupäinen tavoite: Vaikka itselleni on kertynyt kokemusta ohjelmistoprojekteista työelämästä, niin haluaisin saada käytännön opeilleni hieman teoreettista pohjaa. Usein myös kantapään kautta opittu ei ole se oikea tapa, vaan toivoisin löytäväni lisätietoutta ja korjausta mahdollisesti "väärin" oppimaani. Tavoitteena on myöskin tutustuminen uusin teknologioihin (esimerkiksi SVG).
21 (24) Oppimisen toteutuminen: Alunperin pienen kompromissin takia päädyin työkokemukseni takia projektipäälliköksi, vaikka minulla olisi ehkä ollut paremmin rahkeita arkkitehdin tehtäviin. Olin kuitenkin hyvin tyytyväinen projektipäällikön tehtävästä, koska sain konkreettisesti oppia miten paljon merkitsee hyvä projektisuunnittelu, tehtäväsuunnittelu ja kommunikaatiomenetelmät niin ryhmän sisällä kuin muiden projektin jäsenien kanssa. Suuri haaste olikin jakaa tietämystä teknisistä osuuksista siten, että työmäärä ei räjähtäisi käsiin (jo pelkässä projektipäällikön työssä on näkjöään riittämiin tekemistä). Osallistumalla oikeisiin pariohjelmointisessioihin tämä onnistuikin melko hyvin. Henkilökohtaisesti olin tyytyväinen myös "spikingilla" kokeiltun prototyypin onnistumisesta, sekä arkkitehtuurin viivästyessä tekemäni arkkitehtuuridraftin istumisesta lopulliseen malliin melko hyvällä tarkkuudella. Kaiken kaikkiaan ohjelmatyökurssi on hyvin opettavainen, ja nykymallillaan hyvin mielenkiintoinen. Itse COTOOL-projekti oli itselleni mielenkiintoinen, ryhmädynamiikka toimi mielestäni hyvin sekä niin asiakas- kuin viikkopalavereihin oli aina mukava mennä. 6.4 Liljavirta, Matti Alkupäinen tavoite: Koska aiempi kokemukseni projektityökentelystä rajoittuu lähinnä joko teknisenä asiantuntijana toimimiseen tai puhtaasti tekniikkaan liittyvistä projekteista. Kurssin puitteissa pääsee tutustumaan ohjelmistonkehistysprojektin kaikkiin vaiheisiin ja osa-alueisiin syvällisemmin ja oppii hyviä työskentelytapoja, joita voi hyödyntää muunkinlaisissa projekteissa ja työelämässä yleensäkin. Projektin johtamisespuolesta saatavat käytännön kokemukset toivottavasti antavat myöskin uusia näkökulmia asioihin. Lisäksi tämän projektin puitteissa on tavoitteissa uusiin tai ennalta vain päällisin puolin tuttuihin tekniikoihin syvällisempi tutustuminen. Oppimisen toteutuminen: Projektin aikana projektin suunnitteluun ja hallinntaan liittyvät näkökulmat ja asiat tulivat hyvin tutuiksi, ja se mitä vaaditaan tällaisen projektin kasassa pitämiseen ja läpiviemiseen on näin jälkikäteen huomattavasti selvempää nyt jälkikäteen, kuin ennen projektia. Ajatus sitä että projekti on erillinen entiteetti itse varsinaisesta työstä, on muuttunut selvästi aiemmasta, sillä aiemmin oli tottunut siihen, että tehdään hommat niin kuin aina ja projekti itsessään on vain hallinnollinen pieni sivuseikka, johon ei tarvise niin paljoa kiinnittää huomiota. Todellisuuden näkeminen projektin suunnan pieleen menosta ja sen hallintaan ototasta myöskin ovat olleet opettaavaisia kokemuksia. Todellisuudessa koskaan kaikki ei mene niin kuin on aluksi ja ensimmäisissä visoissa ajateltu, vaan myöhemmin projektin edetessä todellisuus iskee, jolloin hyvällä suunnittelulla ja hallitulla toimisella pystytään pitämään kokonaisuus hallinnassa. Projektin aikana tutustui hyvin uusiin tekniikoihin ja niiden hyödyntämiseen, sekä tuntemus lisääntyi ennalta tutuistakin asioista ja menetelmistä. Kokonaisuutena kurssi oli hyvin opettavainen ja mielenkiintoinen sekä tarjosi realistisen kuvan projektin läpiviemisestä, kaikkine vastoinkäymisineen. 6.5 Rouhiainen, Kimmo Alkupäinen tavoite: Tavoitteenani on oppia järjestelmällistä ohjelmistokehitystä, oppia entistä parempi ja selkeämpi ohjelmointitapa, sekä saada kokemusta ohjelmointityökaluista ja kielistä. Myös kunnon kokemuksen saaminen isommassa ryhmässä työskentelystä olisi tärkeää. Oppimisen toteutuminen: Alkuperäiset tavoitteeni toteutuivat osittain. Projekti opetti paljon ohjelmistokehityksestä käytännössä. Sain tutustuttua mm. J2EE:hen, Eclipseen, Together Architechtiin, Strutsiin, MS-SQL:ään, Javascriptiin ja SVG:hen, joskin Eclipseä lukuunottamatta ehkä oletettua pintapuolisemmin. Tähän vaikutti paljolti siirtymiseni kehittäjän paikalta pääarkkitehdiksi, mikä muutti vähän työtehtäviä. Arkkitehtina toimiminen oli hyvin mielenkiintoista ja opetti ratkaisuntekoa, sekä järkevän ohjelmarakenteen suunnittelua. Kesken projektin tehtävään siirtyminen tosin aiheutti enemmän paineita toteuttamisen suuntaan ja aiheen opiskelu jäi haluttua vähemmälle.
22 (24) Ryhmätyöskentelystä oppiminen jäi vähäisemmäksi, epäsäännöllisten työaikojen ja vaihtelevasti osallistuvan porukan ansioista. Tosin haasteet tässäkin saattoivat kuitenkin opettaa jossain mielessä enemmän, kuin asioiden itsestään sujuminen olisi voinut tehdä. 6.6 Silvekoski, Pekka Alkupäinen tavoite: Saada hyvä yleiskuva ohjelmistoprojektista ja sen eri vaiheista. Päästä mukaan suunnitteleemaan ja testaamaan käyttöliittymää, että näkee miten teoriassa opitut asiat taipuvat käytäntöön. Lisäksi oppia tiimityöskentelystä ja oikeanlaisesta dokumentoinnista projektissa. Myös oppia projektissa käytettävä SVG tekniikka sopivalle tasolle. Oppimisen toteutuminen: Opin eniten ryhmätyöskentelystä ja kuinka yhdessä toimimalla voi saada asioita aikaan, kun työnteko on suunniteltua ja koordinoitua. Ensimmäisessä iteraatiossa oppi kuinka asiat voivat mennä pieleen ja toisessa kuinka asiat toimivat onnistuneesti. Näin hyvin kaikki ohjelmistoprojektin vaiheet. Omalta osaltani sain suunnitella ja testata käyttöliittymästä selkeää ja helppokäyttöistä. 6.7 Welin, Jan Alkupäinen tavoite: Tavoitteena on oppia käytännön ohjelmistoprojektin kulkua. Tähän mennessä lähes kaikki ohjelmointitehtävät koulussa ovat olleet pieniä yksin tai kaksin tehtyjä harjoitustöitä, ilman iteraatioita. Varsinaista työkokemustakaan en omaa ohjelmistoprojektien parista. Oppimisen toteutuminen: Kurssin aikana opin paljon ohjelmistoprojektin haasteista, kuten hyvän suunnittelun ja ryhmän sisäisen kommunikoinnin tärkeydestä. Pahin ongelmamme oli arkkitehtuurisuunnittelun viivästyminen, mikä vaikeutti ohjelmointityön aloittamista. Projektin läpiviennin lisäksi opin kurssin aikana erittäin paljon uusien työkalujen käytöstä, kuten Eclipse, SqlServer, J2EE sekä Struts. Edellä mainitut olivat itselleni täysin tuntemattomia ennen kurssia.
23 (24) 7 Kurssipalaute 7.1 Hyvää Emme voisi keksiä juuri parempaa tapaa, jolla oppia ohjelmistoprojektin toteutuksesta. Hoitamalla projektin kaikkine osa-alueineen alusta loppuun opettaa jokaiselle paljon. Mentorointi on hyvä asia, ja toimii useita muita kursseja paremmin, joissa mentorin (tai oikeastaan assistentin) roolissa olevalta koulun edustajalta ei saa juuri muuta palautetta kuin arvosanat. Nyt mentorilta ja muutenkin kurssin henkilökunnalta sai niin sähköpostitse kuin tavatessakin hyvää ja nopeaa palautetta/apua. Vielä se, että projektit tehdään oikeille yrityksille korottaa kurssin arvostusta. Kurssin avulla useat saavat arvokkaita yhteyksiä yritysmaailmaan ja ehkä jopa ensimmäisen kontaktin ohjelmointitöihin "yrityksen palveluksessa". Jaakko Pöyry oli asiakkaana erinomainen. He tarjosivat todella mainion työtilan tarvittavine välineineen/ohjelmistoineen sekä motivoivat hyvin työskentelyä. Asiakkaan tekninen asiantuntija oli kehittäjille suureksi avuksi käytettävään tekniikkaan tutustuessa. 7.2 Huonoa Kaikki muutkin varmaan yhtyvät kommenttiin, että kurssissa on hyvin paljon työtä nähden opintoviikkomäärään. Myöskin pidämme kurssia kalenteriajaltaan hieman tiiviinä pakettina. Monet meistä eivät ehtineet kunnolla keskittyä muihin samanaikaan suoritettaviin kursseihin. Toinen asia mikä aiheuttaa tilanteen hieman haasteelliseksi on se, että kehittäjät pitää rekrytoida ryhmiin. Hyvin monet ryhmät olivat kuitenkin jo muodostuneet kaveripohjalta joten oli vaikea löytää vapaita kehittäjiä. Itse onnistuimme vasta henkilökohtaisia meileja kaikille vapaille lähetettyämme. Nyt kurssin arvosanaan vaikuttaa suuresti tekninen tietotaito ja projektit ovat hyvin eritasoisia vaikeusasteeltaan. Tämä on varmasti erittäin vaikea ottaa huomioon arvostelussa.
24 (24) 8 Viitteet 1. COTOOL Projektisuunnitelma, Johdanto 2. COTOOL Projektisuunnitelma, Tavoitteet ja lopetuskriteerit 3. http://www.junit.org/, 3.12.2005 4. http://emma.sourceforge.net/, 3.12.2005 5. http://www.w3.org/xml/, 13.10.2005 6. http://www.w3.org/tr/xsl, 13.10.2005 7. http://www.w3.org/graphics/svg/, 13.10.2005 8. COTOOL Liitetiedostot 9. COTOOL Kehittäjän manuaali ja tekninen spesifikaatio