T Loppuraportti Sivu 1 (19) Loppuraportti. Ryhmä ExtraTerrestriaLs Asiakas Aureolis Oy

T-76.115 Loppuraportti Sivu 1 (19) Loppuraportti Ryhmä ExtraTerrestriaLs Asiakas Aureolis Oy Versio Päiväys Tekijä Kuvaus 0.1 8.3.2005 Mikko Ruokojoki Alustava pohja 0.2 13.3.2005 Jani Malmi Lisätty vaatimusten tilastointia sekä omat kokemukset. 0.3 13.3.2005 Timo Sallinen Johdanto, kokemukset, tuotokset, kehitysideat 0.4 13.3.2005 Mika Suvanto Tilastot, kokemukset, ulkoasun muokkausta 0.5 13.3.2005 Mika Suvanto Yhdistetty osat ja oikoluettu 0.6 14.3.2005 Mikko Ruokojoki Korjattu kohtia 2.1, 2.2, 2.3, 2.4, 5.1 ja 5.4 0.7 14.3.2005 Jani Malmi Korjattu kohtaa 4.1 0.8 14.3.2005 Mika Suvanto Lisätty kohta 5.6 Työkalut 0.9 14.3.2005 Mika Suvanto Lisätty taulukoita 3.2, 3.4, 4.4 0.91 14.3.2005 Mikko Ruokojoki Lisätty kaavio tunnit per viikko 1.0 15.3.2005 Mika Suvanto Korjattu kirjoitusvirheitä 1.1 15.03.05 Risto Kunnas Lisätty viite testiraportin bugilistaan

T-76.115 Loppuraportti Sivu 2 (19) Sisällysluettelo 1 Johdanto...3 2 Projektin kulku... 3 2.1 Suunnitteluvaihe... 3 2.2 Toteutusvaihe 1...4 2.3 Toteutusvaihe 2...4 2.4 Toimitusvaihe... 4 3 Projektin tulokset...4 3.1 Projektin tuotokset... 4 3.2 Asiakkaan palaute... 5 3.3 Vertaisryhmän palaute... 6 3.4 Ryhmän palaute... 6 4 Tilastot...8 4.1 Vaatimusten toteutuminen... 8 4.2 Ohjelmiston koko...9 4.3 Muita tilastoja... 10 4.4 Toteutuneet työmäärät... 10 5 Käytetyt työkalut ja työtavat...12 5.1 Ohjelman kehitysprosessi... 12 5.2 Laadunvarmistus...12 5.3 Riskienhallinta... 13 5.4 Projektin hallinta...13 5.5 Suunnittelumallit...14 5.6 Työkalut... 14 6 Kokemukset...15 6.1 Mikko Ruokojoki...15 6.2 Risto Kunnas...15 6.3 Timo Sallinen...16 6.4 Teemu Nousiainen... 16 6.5 Jani Honkanen...17 6.6 Jani Malmi... 17 6.7 Mika Suvanto...17 7 Kurssipalaute... 18 8 Jatkokehitys... 19 9 Viitteet... 19

T-76.115 Loppuraportti Sivu 3 (19) 1 Johdanto Projektin tavoitteena oli kehittää Aureolis Oy:lle ETL-työkalu. ETL on lyhenne sanoista Extract- Transform-Load, ja kyseessä on tietovarastoinnissa käytettävä apuväline. Työkalun toimenkuvaan kuuluu tiedon poimiminen operatiivisista tietojärjestelmistä, sen jalostaminen eri tavoin ja lataaminen tietovarastoon. Työkalulla voidaan automatisoida toisteista ja monella tapaa ongelmallista manuaalista tiedon jalostamista. Tuotettava ohjelmisto oli luonteeltaan jossain määrin kokeellinen. Tavoitteina ei ollut täysin tuotantovalmiin järjestelmän kehittäminen, vaan jatkokehityskelpoisen pohjan luominen, josta asiakas voi kehittää omiin tarkoituksiinsa sopivan sovelluksen. Asiakkaan kannalta tavoitteena oli myös ylipäänsä oman työkalun tekemisen kannattavuuden arviointi. Projekti toteutettiin Teknillisen Korkeakoulun Tietojenkäsittelyopin ohjelmatyö-kurssin puitteissa seitsemän hengen projektiryhmällä. Kurssi asetti omat kehysvaatimuksensa mm. aikataulun ja osittain käytettävien menetelmien osalta. 2 Projektin kulku Projektin suunnitteluvaiheessa ja toteutusvaiheessa 1 luotiin projektisuunnitelma ja tavoitteet projektille. Tavoitteiden määrittely pysyi hyvin hallinnassa koko projektin ja pieniä muutoksia suuntaan tehtiin toteutusvaihe 2 keskivaiheilla. Projektin tavoitteena ei ollut valmis järjestelmä, joten tämä vaati erilaisen etenemistyylin. Projektin yhtenä tavoitteena oli arvioida uuden tekniikan ja idean järkevyyttä ja myös asiakkaan mielikuva järjestelmä kehittyi projektin edetessä. Etenemistyyli erityispiirteet näkyvät siinä, että suunnittelu jatkui myös toteutusvaihe 1 aikana ja varsinaisen toteutuksen täysinäinen käynnistäminen oli suuri prosessi. Tällöin teoreettiset mielikuvat järjestelmän sisällöstä piti luoda lukkoon. 2.1 Suunnitteluvaihe Suunnitteluvaihe alkoi siitä, että ryhmä ja asiakas tutustuivat toisiinsa ja asiakas esitteli ajatuksiaan järjestelmästä. Ryhmä teki taustatutkimusta tietojärjestelmistä, tiedon louhinnasta ja järjestelmän teoriasta. Suunnitteluvaiheen sisältöön kuului tavoitteiden ja vaatimusten määrittely ja toteutettavan järjestelmän arkkitehtuurin suunnittelu. Työ liittyy olennaisesti tiedon louhintaan ja siinä käytettyihin tehtäviin. Tavoitteena on työkalu ammattilaiselle, joten tietokantojen tuntemus oli ensiarvoisen tärkeä ponnistuslauta, jonka avulla asiakkaan ideaa hahmoteltiin. Suunnitteluvaiheessa sovittiin käytännöistä ryhmän ja asiakkaan kesken. Panostettiin siihen, että kommunikaation pitää toimia. Arvioitiin eri vaihtoehtoja ja parhaimmaksi vaihtoehdoksi syntyi ryhmän oma uutisryhmä. Asiakkaan kanssa sovittiin viikoittaisesta tilanneraportista ja noin asiakastapaamisista noin parin viikon välein. Ajankäytöstä sovittiin ryhmän kanssa, että tunnit kirjataan viimeistään sunnuntaisin, jotta tilanneraportti voidaan tehdä maanantaina. Ryhmä sopi pitävänsä myös ryhmätapaamisen joka viikko. Tehtävien jako toteutettiin Excel-taulukolla, jonka projektipäällikkö määritteli viikoittain. Tehtävien jaosta keskusteltiin ryhmän viikkokokouksessa.

T-76.115 Loppuraportti Sivu 4 (19) 2.2 Toteutusvaihe 1 Vaiheen tavoitteina olivat arkkitehtuurin suunnittelun jatkaminen, demo-version toteuttaminen ja kriittisimpien toimintojen luonti. Näiden lisäksi haluttiin parantaa kommunikointia ja vähentää kokouksiin kuluvaa aikaa. Ensimmäiselle toteutusvaiheelle oli annettu kuukausi aikaa. Aika tuntui tuossa vaiheessa hyvin vähäiseltä ja tunteja paloi runsaasti, kun asioita vietiin eteenpäin mahdollisimman nopeasti. Järjestelmän vaatimuksiin ei tässä vaiheessa tullut paljon muutoksia. Vaikein tavoite oli saada itse toteutustyö alkamaan. Tehtävien jakoon sovittiin muutos niin, että käyttöön otetaan JIRA-työkalun antama tehtävien hallinta. Tätä ei otettu vielä tässä vaiheessa käyttöön, vaan seuraavassa vaiheessa. 2.3 Toteutusvaihe 2 Vaiheen tavoitteet olivat toteutuksen jatkaminen, järjestelmän perusosat kuntoon ja toimitus testikäyttöön asiakkaalle. Ryhmä päätti myös, että haluaa tehdä työtä myös joululoman aikana. Samoin myös vaihe jaettiin kahteen osaan A ja B. Tarkoituksena oli helpottaa suunnittelua ja katsoa tilannetta tammikuun alussa yhdessä asiakkaan ja mentorin kanssa. Vaiheen jako toimi. Tosin tuntimäärissä mitattuna ryhmä ei tehnyt arvioimaansa määriä tunteja joululomalla. Tavoitteet kuitenkin saavutettiin ja tammikuun alkupuolella järjestelmän esittely asiakkaalle onnistui hyvin. Joululoman töitä varjosti myös paljon työtunteja vienyt selvittely sopimusasioista ja salassapitosopimuksesta. Erimielisyyttä neuvoteltiin useamman kymmenen tunnin edestä ennen kuin asia saatiin hoidettua. Vaiheen loppuosalle vaatimuksia muokattiin hieman. Vaatimuksista poistettiin osaksi vanhentuneita tavoitteita ja myös asioita, joiden tärkeys oli huomattu vähäisemmäksi projektin osalta. Tilanteen tarkistus oli yksi tavoite toteutusvaiheen jakamisessa kahteen osaan. Vaiheen loppuosan työskentely sujui hyvin. Toteuttamiseen oli syntynyt rutiinia ja alkuvaikeuksien jälkeen hyvän rungon päälle oli suhteellisen helppo toteuttaa järjestelmään liittyviä toimintoja. Toteutusvaiheen lopussa vaatimusmäärittelyn mukaan arvioituna kriittisistä vaatimuksista oli toteutettu 100%, korkeista 89% ja matalan prioriteetin 35%. 2.4 Toimitusvaihe Toimitusvaiheen tavoitteena olivat dokumentointi, testaus, viimeistely ja toimitus asiakkaalle. Vaiheen alussa vielä osaksi aikaa myös toteuttaa puutteellisiksi jääneitä osia ja pari vaatimusta. Työt sujuivat kohtuullisesti. Järjestelmää on dokumentointia käytiin läpi useassa kohtaa. Varsinkin kehitysohjeen sisältöä kehitettiin, jotta asiakkaan tavoitteena ollut mahdollinen jatkokehitys olisi mahdollisimman helppoa. 3 Projektin tulokset 3.1 Projektin tuotokset 3.1.1 ETL-työkalu ETL-työkalu tarkentui lopulta ETL-työkalun prototyypiksi. Alussa puhuttiin enemmän jopa tuotantokäyttöön sopivasta työkalusta, mutta tätä ei kuitenkaan asetettu ehdottomaksi tavoitteeksi. Projekti sisälsi tavoitteen osalta paljon liikkumavaraa. Itse työkalun osalta kaikkia alun perin ajateltuja ta-

T-76.115 Loppuraportti Sivu 5 (19) voitteita ei täytetty, mutta suurin osa kuitenkin täytettiin ja projektin edetessä pystyttiin asiakkaan kanssa hyvässä hengessä sopimaan siitä, mitä toteutetaan ja mitä jätetään ulkopuolelle. ETL-työkalulla voi toteuttaa pienimuotoisia ETL-prosesseja. Sellaiset prosessit, joita ETL-työkalulla voi tässä vaiheessa toteuttaa, ovat kuitenkin helpommin (ja varmemmin) toteutettavissa esimerkiksi open source työkaluilla. Projektin yhtenä tarkoituksena oli kuitenkin arvioida, että onko tällaista työkalua ylipäätään järkevä yrittää toteuttaa, ja tästä projektista saadut kokemukset ovat asiakkaalle jopa tärkeämpi kuin itse lopputulos. 3.1.2 Dokumentaatio Projektin yhden tavoitteen, jatkokehityskelpoisuuden, kannalta tärkeimmät tuotokset olivat tekninen spesifikaatio ja kehitysohje. Ryhmälle itselleen sekä asiakkaalle tuotettu dokumentaatio on ollut riittävää, mutta sellaiselle, joka ei ole ollut mukana projektissa, voi tuotettu dokumentaatio olla joiltain osin liian ylimalkaista. Vertaisryhmä kaipasi dokumentaatioon enemmän konkreettisuutta. 3.2 Asiakkaan palaute Kurssin lopussa laadimme asiakkaalle lyhyen kyselyn [3], jolla pyrittiin kartoittamaan asiakkaan mielipidettä projektin tavoitteiden saavuttamisesta loppuraporttia varten. Arviointia toteutettiin asteikolla 1-5 (täysin eri mieltä täysin samaa mieltä). Lisäksi kommentteja pystyi antamaan vapaasti. Kyselyn perusteella projektin tavoitteet saavutettiin varsin hyvin (4,00). Jatkokehityksen mielekkyys on tosin vielä harkinnassa: Ehdottoasti tuosta on hyvä jatkaa eteenpäin, mutta homman järkevyydestä en osaa sanoa :) Kohtaan Saimme riittävästi tietoa projektin etenemisestä tuli yksimielisesti arvosana 5,00, ja projektin kulkuun pystyttiin vaikuttamaan riittävästi (4,50). Eniten kehitettävää nähtiin dokumentaatiossa. Dokumentaatio on ehkä puutteellisin osa-alue. Siitä on kyllä aikaa, kun viimeksi dokkareita selasin. Kokonaisarvosana on 5, jos dokumentaatio on nyt niin hyvä, kun uskon se olevan. Taulukossa 1 on arvioitu asiakkaan projektin alussa asettamat tavoitteet. Arviointiperusteet löytyvät Projektisuunnitelmasta [11].

T-76.115 Loppuraportti Sivu 6 (19) Tavoite Toiminnoiltaan karsittu ETL-työkalu, jonka perusteella voimme päättää jatketaanko oman ETL-työkalun kehitystä ETL-työkalun kuvauskieli, joka on laajennettavissa tarpeen mukaan Riittävä operaatioiden rajapinta, jotta sitä voidaan käyttää myöhemmin toteutettavien operaatioiden toteuttamiseen Versio ETL-työkalusta, josta voidaan jatkojalostaa käyttökelpoinen kehittynyt versio (ohjelman perustukset tehty huolella) ETL-työkalu toimii vaatimusten mukaisesti. ETL-työkalun prosessien dokumentointitoiminnosta prototyyppi-tasoinen versio ETL-työkaluun liittyvien, uusien tekniikoiden testaus käytännössä Tietovarastopuolen kehittäminen Tarjota parempia palveluita asiakkaille Asiakaskunnan kasvattaminen uuden työkalun avustuksella Tilanne Osittain toteutunut Toteutunut Toteutunut Toteutunut Osittain toteutunut Toteutunut Toteutunut Asiakas arvioi myöhemmin Asiakas arvioi myöhemmin Asiakas arvioi myöhemmin Taulukko 1: Asiakkaan tavoitteet 3.3 Vertaisryhmän palaute Vertaisryhmällä oli vaikeuksia prosessikuvausten muodostamisessa. Varsinaiseen testaukseen vertaisryhmä ei päässyt, joten vertaistestaus muodostui käytännössä käytettävyystestaukseksi. Dokumentaation laadussa on tämän perusteella parantamisen varaa. Toisaalta, työkalua ei ole vielä tässä vaiheessa tarkoitettu varsinaiseen tuotantokäyttöön, jossa asiaan perehtymätön henkilö pystyisi toteuttamaan helposti ETL-prosessin vaan asiantuntijoiden käsityötä vähentämään. 3.4 Ryhmän palaute Ryhmälle toteutettiin strukturoitu kysely [4], jonka avulla kerättiin kokemuksia kurssista ja arviointeja toteutuneista tavoitteista. Tarkempi kyselyn yhteenveto löytyy tämän dokumentin liitteistä. Ryhmän tavoitteiden arviointiperusteet löytyvät Projektisuunnitelmasta [11].

T-76.115 Loppuraportti Sivu 7 (19) Tavoite Kehittää jatkokehityskelpoinen tietovarastointijärjestelmän runko. Oppia työskentelemään ja kehittää taitojaan ohjelmistoprojektissa. Oppia toimimaan osana ohjelmistokehitysryhmää ja kehittää omaa tietotaitoa asian tiimoilta Kurssin menestyksellinen suoritus annettujen rajoitteiden puitteissa (tuntimäärät). Tilanne Toteutunut Toteutunut Toteutunut Ryhmä toteaa loppuarvostelun jälkeen Taulukko 2: Ryhmän tavoitteet Arviointia toteutettiin asteikolla 1-5 (täysin eri mieltä täysin samaa mieltä). Lisäksi kommentteja pystyi antamaan vapaasti. Alla on käyty läpi tuloksien tärkeimmät viestit. 3.4.1 Tavoitteet Ryhmä koki oppineensa paljon uutta ohjelmistoprojektissa työskentelystä, 71 % oli asiasta täysin samaa mieltä. (ka 4,57). Koettiin myös, että oppimista oli tapahtunut paljon taidoissa ja ryhmätyöskentelystä. Projektin tavoitteiden saavuttamisesta keskiarvo oli 4,00. Ryhmä antoi itselleen kurssiarvosanan 4 86% äänimäärästä (ka 4,14). 3.4.2 Tuote Tuotetta pidettiin jatkokehityskelpoisena (ka 4,29) Tuotteen vakaudesta ei osattu sanoa (ka 3,00). Tuotteen kyky toipua virhetilanteista keräsi negatiivista palautetta. (ka 2,50) Kommentteina oli seuraavaa: Virhetilanteiden käsittely jäi taka-alalle ja muiden ominaisuuksien kehittämisen alle. Toisaalta tämä oli tutkimusluontoinen projekti, ja virheiden hallinta on enemmänkin eduksi tuotantokäytössä. Järjestelemä ei selviydy virheistä kovin hyvin. Tosin kehitysvaiheessa tätä ei ehkä kannatakaan tehdä kovin aikaisessa vaiheessa. 3.4.3 Työkalut Työkalujen mielipidettä kysyttiin ja kaikki saivat poikkeuksetta positiivisen vastaanoton. Työnjako aiheutti hieman eriäviä mielipiteitä (ka 3,43 kh 0,79) Johtamista pidettiin hyvänä keskiarvolla 3,83. Projekti vietiin läpi hallitusti ka 3,71. 3.4.4 Osa-alueet Osa-alueista kaikki saivat positiivista kommenttia. Huonoimman keskiarvon sai testaus (3,29). Siitä myös annettiin suurin osa kommenteista: Testaukseen olisi pitänyt panostaa ja luoda automatisointikäytäntö aiemmin. Toisaalta testattavaa koodia tuli myös liian myöhään. Testausta olisi pitänyt tehdä enemmän aiemmin. Ylipäänsä koko projektia olisi voinut lähestyä vähän modernimmalla mallilla, nyt mentiin pitkälti vesiputousmallin mukaan. Tosin kohtuullisen onnistuneesti. Iteratiivisuus puuttui projektin alkuvaiheessa, mutta parantui loppua kohden.

T-76.115 Loppuraportti Sivu 8 (19) Yhteenvetona voidaan sanoa, että kyselyn avulla ryhmän ajattelee positiivisesti kurssista ja työn tuloksista. Ryhmä pitää tavoitteita saavutettuina ja työn laatua hyvänä. 4 Tilastot 4.1 Vaatimusten toteutuminen Ensimmäisessä iteraatiossa emme toteuttaneet kovin montaa vaatimusta, koska panostimme kuvauskielen suunnitteluun, jotta siitä ei tulisi missään vaiheessa kompastuskiveä projektille. Tämä oli erityisesti asiakkaan puolelta esitetty vaatimus. Toisessa iteraatiossa toteutimme kaikki kriittiset vaatimukset ja suuren osan korkeista vaatimuksista sekä monia matalia vaatimuksia. Viimeisessä vaiheessa emme enää niin paljon koodanneet uutta vaan keskityimme testaamiseen ja virheiden korjaamiseen, mutta saimme jotain uutta siinäkin toteutettua. Alla olevassa taulukossa (kuva 1) on kuvattuna projektin eri vaiheissa eri tyyppisten vaatimusten toteutuminen. Koska vaatimukset ovat tässä luokiteltu karkeasti toteutetuiksi tai ei-toteutetuiksi on jotkin ei-toteutetuista kuitenkin suunniteltuja tai kesken. Joitakin ei-kriittisiä vaatimuksia hylkäsimme (7 kpl) projektin aikana asiakkaan kanssa neuvotellen. Vaatimusten hylkäämisestä ja muista vaatimusten muutoksista johtuen kuvassa näkyy lukumäärän muuttumista projektin eri vaiheiden aikana. 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 I1:Kriittinen I1:Korkea I1:Matala I2:Kriittinen I2:Korkea I2:Matala FD:Kriittinen FD:Korkea FD:Matala Kuva 1: Vaatimusten toteuttaminen Toteuttamatta Toteutettu Toiminnalliset vaatimukset ja niiden toteutuminen prosentuaalisesti sekä niiden lukumäärä projektin lopussa on kuvattu alla olevassa taulukossa. Vaatimus Lkm Toteutusosuus Kriittinen 13 100% Korkea 19 90% Matala 17 41% Taulukko 3: Toiminnalliset vaatimukset

T-76.115 Loppuraportti Sivu 9 (19) Ei-toiminnallisia vaatimuksia emme ole seuranneet vaiheittain. Näistä 10 kpl on projektin loppuvaiheessa hyvällä tasolla ja 2 kpl kehitettävällä tasolla. Yksi kehitettävä vaatimus on kriittinen (ET8), koska emme vielä meidän testaustemme perusteella uskaltaisi käyttää sitä tuotantokannoissa ilman lisätestausta. Eli mikäli asiakas haluaa tuotetta käyttää tuotantokannoissa olisi suositeltavaa että he myös testaavat sitä paremmin ja laajemmin, myös todellisella datalla. Alla olevassa taulukossa näkyy ei-toiminnallisten vaatimusten tila projektin lopussa. 4.2 Ohjelmiston koko Vaatimus Lkm Hyvällä tasolla Kriittinen 2 50% Korkea 10 90% Taulukko 4: Ei-toiminnalliset vaatimukset Ohjelmiston koko on laskettu statcvs ja cccc -työkaluilla. Vertailuryhmäksi on otettu kurssin 2003-2004 kolme parasta ryhmää, Ampel, PPT ja tete. Koodiriveissä on huomioitu varsinainen ohjelmakoodi, mm. XML- tiedostojen rivimääriä ei ole laskettu mukaan. Mittari ExtraTerrestriaLs Ampel PPT tete LOC + COM 12000 19092 35200 9680 NLOC 6057 7271-4689 COM / LOC 49 % 62 % 25 % 9 % Taulukko 5: Ohjelmiston koko On syytä huomata, että erityyppisten ohjelmistojen vertailu koodirivien määrän perusteella on hyvin karkeaa. Tuloksista voikin lähinnä päätellä, että projektimme koko on vertailukelpoinen aiempien projektien kanssa. Kuvassa 2 on statcvs -ohjelmalla tuotettu kuvaaja rivimäärän kehityksestä. Ohjelma huomioi lähdekoodin java -päätteiset tiedostot, ja laskee koodirivien lisäksi kommentti- ja tyhjät rivit mukaan arvoihin.

T-76.115 Loppuraportti Sivu 10 (19) Kuva 2: Ohjelmiston koon kehitys 4.3 Muita tilastoja Julkaistavaa dokumentaatiota News -viestejä Sähköposteja ~150 sivua ~1000 kpl ~200 400 / henkilö 4.4 Toteutuneet työmäärät Kurssiin budjetoitu työmäärä, 190 h /henkilö, toteutui keskimäärin hyvin, tosin Risto ei pystynyt käyttämään kaikkia suunniteltuja tuntejaan projektin aikana. Taulukko 6 erittelee toteutuneet tuntimäärät eri jäsenten välillä ja perustuu jokaisen tekemiin kirjauksiin Trapoliin. Luonnollisesti kirjausperuste vaihtelee hieman henkilöstä riippuen, joten lukemat ovat suuntaa-antavia. Luvut mm. sisältävät vain pieneltä osin sähköpostien ja news-viestien luvun/kirjoittamisen, matkat, odottelut tms. vaikeasti kirjattavat tehtävät. Näin ollen todellinen työllistävä vaikutus on vielä näitä lukuja suurempi. Vaihe Jani M Jani H Mikko Mika Risto Teemu Timo PP 53 57 78 44 25 55 38 I1 38 93 69 49 40 59 39 I2 78 33 40 60 54 63 62 FD 20 10 16 36 22 17 46 Yhteensä 189 (-1) 193 (+3) 203 (+13) 189 (-1) 141 (-49) 194 (+4) 185 (-5) Taulukko 6: Toteutuneet työmäärät (h)

T-76.115 Loppuraportti Sivu 11 (19) Taulukko 7: Tunnit per viikko 4.4.1 Tuntijakauma työtavoittain Kuvassa 3 on esitetty työtuntien jakauma työtavoittain. Vertailuryhmäksi on valittu edellisen kurssin 2003 2004 keskiarvo [1].

T-76.115 Loppuraportti Sivu 12 (19) 27,5 25 22,5 20 17,5 % 15 12,5 10 ExtraTerrestriaLs Keskiarvo 2003 2004 7,5 5 2,5 0 design docum enting infrastr ucture Kuva 3: Työtapojen prosentuaalinen jakauma Projektin luonne näkyy tässä kaaviossa selvästi. Aihepiiri oli uusi, ja tämä näkyy ainakin tapaamisten ja opiskelun keskiarvoa suuremmissa luvuissa. Ryhmän jäsenet eivät ennalta tunteneet toisiaan, joten varsinkin alussa tapaamiset ja asioiden sopiminen veivät paljon aikaa. Keskeinen tavoite oli jatkokehityskelpoisen ETL-työkalun rungon luominen. Jatkokehityskelpoisuuden varmistamiseksi dokumentointiin panostettiin myös paljon. Lisäksi ryhmä käytti paljon aikaa projektin seurannan raportointiin sekä iteraatiosuunnitelmiin, jotka tehtiin varsin tarkasti. Arkkitehtuurisuunnittelu vei runsaasti aikaa, sillä suunnitelmissa piti huomioida myös ohjelman jatkokehitys. Tämän vuoksi asioita piti suunnitella selvästi enemmän kuin projektin aikana ehdittiin toteuttaa. Vastaavasti ohjelmoinnin ja testauksen tuntimäärät jäivät keskiarvoa alhaisemmiksi. Ohjelmointi pääsi kunnolla vauhtiin vasta I1 -vaiheen puolivälissä, ja testaus varsinaisesti vasta I2 -vaiheessa. Testauksen tuntimääriä vähentää myös se, että varsinaista yksikkötestausta ei suoritettu. Myöskään käytettävyystestausta tai muuta interaktiivista testausta ei juuri tarvittu eikä tehty, ja järjestelmätestausta saatiin automatisoitua melko hyvin. 5 Käytetyt työkalut ja työtavat 5.1 Ohjelman kehitysprosessi Projekti vedettiin läpi iteraatioiden ja osittain vesiputousmallin mukaisesti. Kurssin ohjeistus ohjasi etenemistä tarkasti. Asiakkaan kanssa tehtiin tiiviisti yhteistyötä. Tämä varmisti, että ryhmä ymmärsi asiakkaan tavoitteet ja teki töitä sen mukaisesti. Iteratiivinen ohjelmistokehitysprosessi toimi hyvin. Aikataulu tosin tuntui tiukalta, mutta pakotti kuitenkin opettelemaan tiukempia aikarajoja. Käyntitahti oli yksi viikko, jonka sisälle määriteltiin tehtävät ja ohjelma. 5.2 Laadunvarmistus lecture s meetin gs progra mming progra mming (pair) proj, manag ement studyin g Koodin laatua pyrittiin varmistamaan funktionaalisella testauksella sekä katselmoinnilla. Doku- testing

T-76.115 Loppuraportti Sivu 13 (19) menttien laatua pyrittiin varmistamaan katselmoinnilla. Laadunvarmistusprosessi on kuvattu tarkemmin laatukäsikirjassa [9]. 5.2.1 Testaus Testauksessa pyrittiin testausten automatisointiin prosessikuvauksista ja lähdeaineistosta koostuvien skriptien avulla. Perinteisiä testitapauksiakin tehtiin, kun koettiin että testauksen eteen pitäisi edes jotain yrittää tehdä, mutta niistä ei ollut varsinaisesti mitään hyötyä. Tämän tyylisen työkalun testaukseen on vaikea kuvitella muun tyylistä lähestymistapaa. Yhdellä prosessikuvauksella saa testattua monta eri toimintavaihtoehtoa ja testit voi ajaa uudelleen nopeasti. Virheiden paikallistaminen oli kuitenkin huomattavasti hankalampaa. Todennäköisesti tämän kaltaisen testauksen suurin hyöty onkin siinä vaiheessa, kun koodi on valmiimpaa. [6] Koodin katselmointia suoritettiin kerran, mutta tulokset jäivät huonoiksi. [7] 5.2.2 Katselmoinnit Dokumenttien katselmoinnista on kerrottu enemmän Timon ja Riston SEPAssa [7]. Palautettavia dokumentteja pyrittiin katselmoimaan ennen palautusta. Tässä ei aina onnistuttu tai sitä ei resurssien käytön takia pidetty tarpeellisena, ja käytäntö muuttuikin lähinnä läpikäynniksi jonkin toisen henkilön toimesta. Pelkkä läpikäyntikin paransi laatua joissain tapauksissa, mutta läpikäynnit olivat melko pintapuolisia, ja niissä puututtiin lähinnä silmiin pistäviin virheisiin. 5.2.3 Käytettävyystestaus Vertaistestauksen suunnitelma tuntui tarkentuvan koko ajan, kun testattava lopputuloskin tarkentui. Käytännössä vertaistestaus muistutti käytettävyystestausta, mihin oli osittain varauduttukin, mutta ei kuitenkaan siinä määrin, kuin lopulta olisi ollut tarve. Ryhmän jäsenille XML-muotoisen prosessikuvauksen muodostaminen oli päivänselvää, mutta vertaisryhmälle, jolle koko tietovarastoinnin käsite ei ollut aivan selvää, tämä aiheutti hankaluuksia. Perinteistä käytettävyystestausta ei skriptityyliselle käyttöliittymälle ole välttämättä varsinaisen käytettävyyden kannalta tarpeen tehdäkään, mutta ongelmat dokumentaatiossa paljastuivat juuri käytettävyystestauksessa. 5.3 Riskienhallinta Projektin riskienhallintamenettely ja arviointi on kuvattu Riskienhallintadokumentissa [2]. 5.4 Projektin hallinta Projektin tavoitteena oli tunteina 190h/ryhmän jäsen. Työmäärät ja projektin tavoitteet piti suunnitella niin, että pysyttäisiin suunnilleen tavoitteissa ja aikarajoissa. Suunnittelua tehtiin jokaiseen iteraation alussa. Pääsuunnittelu tehtiin ensimmäisessä iteraatiossa. Projektin hallintaan käytettiin ajanseurantatyökalua Trapolia ja tehtävälistoja. Tehtävien etenemistä arvioitiin projektin eri vaiheissa prosentuaalisesti tai jäljellä olevissa tunneissa. Iteraatioiden lopussa arvioinnit tarkastettiin ja sitä kautta tulleiden ehdotuksien kautta projektin hallintaa pyrittiin parantamaan. Oppimiskäyrä oli jyrkkä ja se hyvin kehittävä. Kurssin puolelta määriteltiin korkeat tavoitteet projektin hallinnasta ja sen seurannasta. Vaatimuksien avulla saatiin hyvin kokemusta miten isojakin projekteja pitää hallita. Projektihallinta oli projektipäällikön vastuulla. Hänen työnään oli varmistaa, että jokaisen henkilön työt etenevät ja tehtävät tulevat tehdyksi ajoissa. Asiakkaalle tehtyjen viikoittaisia tilanneraporttien

T-76.115 Loppuraportti Sivu 14 (19) avulla myös projektipäällikkö hahmotteli tilannetta ja otti tarvittaessa ryhmän jäseniin yhteyttä. Eri osa-alueille oli määritelty vastuuhenkilöt ja jokaisella vastuuhenkilöllä oli varahenkilö. Tällä haluttiin varmistaa, että jokainen osa-alue tulee hoidetuksi. Projektin hallinta toteutui kohtuullisesti. Etenemistilanne oli hallinnassa ja se tarkistettiin tuntikirjanpidon kautta viikoittain. Suurempia virhearviointeja ei syntynyt. Riskienhallinta tuki ongelmakohtien valvontaa. Tarkempaa kuvausta projektinhallinnasta löytyy projektipäällikön SEPA-dokumentista.[10] 5.5 Suunnittelumallit Arkkitehtuurisuunnittelun apuna käytettiin joitakin suunnittelumalleja (Design Patterns). Näistä kokemuksista kerrotaan tarkemmin Jani H:n ja Mikan SEPAssa [8]. 5.6 Työkalut 5.6.1 CVS Versionhallintaan käytettiin yleisesti käytössä olevaa cvs -ohjelmistoa. Palvelin sijaitsi asiakkaan koneella, joten asiakkaalla on koko ajan ollut mahdollisuus seurata projektin etenemistä myös tällä tavoin. CVS toimi ryhmän käytössä hyvin. 5.6.2 Eclipse Eclipse oli pääasiallisin kehitystyössä käytetty kehitysympäristö (IDE). Ohjelma todettiin laadukkaaksi ja hyvin tarkoitukseensa Java -kehitykseen soveltuvaksi. Osalla ryhmästä oli aiempaa kokemusta Eclipsestä, mutta osalle ohjelmisto oli uusi tuttavuus. 5.6.3 MySQL Asiakas ei tarkemmin rajoittanut käytettävää tietokantaa, joten ryhmämme valitsi MySQL -tietokannan kehityksen pohjaksi. Perusteena oli ohjelman ilmaisuus sekä tuttuus usealle jäsenelle. Myös MySQL sopi tarkoitukseen hyvin. 5.6.4 News Kurssin alussa yhteydenpitoa hoidettiin pitkälti sähköpostilla. Tämä ei kuitenkaan ollut toimiva keino, joten ryhmän tarpeisiin perustettiin news-palvelin. Se toimi pääasiallisena keskustelukanavana projektin ajan, ja täytti tehtävänsä hyvin. Myös binäärimuotoiset tiedostot pidettiin news:eissä, jolloin se toimi tavallaan versionhallintajärjestelmänä niille. Tässä tarkoituksessa news oli välttävä työkalu; riitti tarkoitukseensa, mutta parempikin tapa voisi olla. 5.6.5 Atlassian JIRA Asiakas tarjosi ryhmän käyttöön Atlassian JIRA -ohjelmiston. Tänne kirjattiin järjestelmästä löydetyt bugit. I2 -vaiheessa myös tehtävien kirjaus ja seuranta siirrettiin hoidettavaksi JIRAlla. Tässä tarkoituksessa ohjelmisto toimi kohtuullisen hyvin, tosin joitain parannuksia lähinnä oikeuksien konfigurointiin voisi tehdä.

T-76.115 Loppuraportti Sivu 15 (19) 5.6.6 Trapoli Kurssin puolelta tarjottu Trapoli oli pakollinen järjestelmä tuntikirjauksessa. Järjestelmä toimi tarkoituksessaan välttävästi; kehitysideoita on kirjattu Kurssipalaute -kappaleeseen. Suurin ongelma oli tehtävien kaksoiskirjaus Trapoli ei sovellu tehtävien jakoon ja bugien seurantaan, joten JIRAa käytettiin tässä. Kuitenkin työmäärät piti kirjata Trapoliin, jolloin samat tehtävät täytyi ylläpitää molemmissa järjestelmissä. Tästä seurasi, että tiedot eivät useinkaan olleet ajan tasalla, mikä vaikeutti projektin etenemisen seurantaa. 5.6.7 OpenOffice OpenOffice:a käytettiin projektin dokumentaation tuottamiseen. Alkuksi sovimme, että dokumentit tehdään RTF-muodossa ja myös Word:iä voi siihen käyttää. Tämä osoittautui huonoksi ideaksi RTF:n rajoitusten ja ohjelmien yhteensopivuuden takia, joten siirryimme OpenOffice:en ja sen omaan tallennusmuotoon. OpenOffice riitti hyvin dokumentaation tuottamiseen. Kenties suurin puute, suomenkielisen oikoluvun toimimattomuuskin korjaantui projektin aikana uuden version myötä. 6 Kokemukset 6.1 Mikko Ruokojoki Olen ollut työelämässä useita vuosia tietotekniikan alueella ja toteuttanut ja ollut mukana toteuttamassa erilaisia projekteja. Kurssi antoi minulle kuitenkin hyvin paljon kokemuksia projektipäällikkönä olemisesta. Ryhmä ei tuntenut toisiaan ennalta ja ryhmän koko (7 hlöä) oli suuri haaste. Aluksi piti saada ihmiset tutustumaan ja toimimaan yhdessä. Erilaisten vastuiden jako oli hyvin tärkeää, jotta jokainen osaalue tuli hoidetuksi. Opettelua vaati kurssin kautta neuvotut projektihallinnan työkalut ja erilaisten ihmisten kanssa työskentely. Henkilökohtaisesti opin paljon projektin organisoinnista, tehtävien jakamisesta, etenemisen seurannasta ja myös kriisitilanteiden sovittelusta. Työmäärään nähden kurssi vastasi pikemminkin 10 opintoviikon kokonaisuutta. Kokemuksena kurssi kuitenkin on hyvin tärkeä ja koen, että se erinomainen tapa opettaa projektityöskentelyä todellisissa töissä. Projektipäällikkönä sanon suuren kiitoksen osaavalle ja tietävälle ryhmälle. Tietoa ja taitoa ei ryhmän jäseniltä puuttunut. Pikemminkin oli haaste saada kaikki tämä tietotaito käyttöön. Intoa ja tekemisen halua ei puuttunut ja toivon myös että itse osasin kaikkia riittävästi tukea ja neuvoa. Pidän, että lopputuloksena syntynyt järjestelmä on jatkokehityskelpoinen. Se voi olla tulevaisuudessa hyvä työkalu asiakkaalle. 6.2 Risto Kunnas Projektissa pääsin toimimaan ensimmäistä kertaa osana isompaa ryhmää ohjelmistoprojektin puitteissa. Pienissä ohjelmistoprojekteissa sekä suuremmissa harjoitustyöprojekteissa olen ennenkin ollut mukana. Kurssin aikana opin jonkin verran lisää tietokannoista, sekä palautin mieleeni Java-ohjelmointikieltä. Ohjelmistoprojekteista ja niiden läpiviennistä tein joitain sekalaisia huomioita, miten asioita kannattaa tehdä ja miten asioita ei kannata tehdä. Projekti oli kuitenkin sen verran laaja ja monipuolinen, että on vaikea nimetä tiettyjä opittuja asioita, kaikesta tuntui oppivan jotain.

T-76.115 Loppuraportti Sivu 16 (19) Yllättävänä haasteena projektin aikana oli yhtäaikaisen työssäkäynnin yhteensovittaminen. Täysipäiväisenä opiskelijana oli tottunut siihen, että aikaa kursseille järjestyy, ja että viikonloppuisinkin pystyy opiskelemaan. Joskus rankan työviikon jälkeen ei kerta kaikkiaan enää jaksanut ajatella koko projektia. Oma vastuualueeni oli testaus. Testauksen järjestelemisen kannalta hankalinta oli se, että alussa puhuttiin tuotantokäyttöön suunnatusta tuotteesta, toisaalta prototyypistä. Projektin kuluessa tarkoitukseksi tuntui tarkentuvan prototyyppi. Jos tämä olisi ollut selvä alusta asti, olisi erilaisia ratkaisuja voitu kokeilla rohkeammin, nyt pelättiin liikaa sitä, että jos jonkun asian suunnittelu epäonnistuu, joudutaan aloittamaan kokonaan alusta. Tämä taas johti vesiputousmalliseen projektiin, jossa testauskin tapahtuu vasta loppuvaiheessa. Toisaalta lopussa, kun huomattiin että kyseessä onkin enemmän prototyyppi, jonka ei tarvitse toimia virheettömästi, koska sitä kuitenkin vielä radikaalisti muutetaan, ei testauksen tarve enää tuntunut niin suurelta. 6.3 Timo Sallinen Tavoitteenani oli ennen kaikkea saada kokonaisnäkemystä ohjelmistoprojektin läpiviemisestä ja suuremmassa ryhmästä toimimisesta. Työssäni sovelluskehittäjänä monet osa-alueet ovat toki tulleet tutuiksi, mutta kokonaisnäkemys kaikesta ohjelmistoprojektiin liittyvästä on jäänyt puutteelliseksi. Koen, että kurssi opetti varsinkin tältä kannalta paljon ja antoi hyvät eväät jatkoa ajatellen. Positiivista oli myös mahdollisuus erilaisten työvälineiden ja menetelmien toimivuuden arviointiin. Teknisessä mielessä suurinta antia oli erilaiset testausmenetelmät ja laadunvarmistusmenetelmät. Omaan opinto-ohjelmaani ei kuulu peruskurssien lisäksi muita ohjelmistotuotannon kursseja, joten tutustuin moniin käsitteisiin käytännön tasolla vasta tällä kurssilla. Suurempia ongelmia tämä ei kuitenkaan aiheuttanut. Omalta osaltani ongelmia aiheutti kurssin ulkopuoliset aikataulukiireet, joitten takia tuntien käyttö kasaantui jossain määrin kurssin loppupuolelle. Kurssin vaatima työmäärä ehkä kuitenkin yllätti, vaikka tuntimäärät olivat ennakkoon rajatut. Erityisiä haasteita kurssin läpiviemiselle aiheutti sekä ajallisesti, että sijainnillisesti hajautettu toimintaympäristö, jossa toimivien kommunikaatiomenetelmien kehittäminen oli ensiarvoisen tärkeää. Mielestäni tässä onnistuttiin kokonaisuudessaan varsin hyvin. Eri tekniikoiden yhdistäminen (uutisryhmä, pikaviestit, sähköpostit) osoittautui hyväksi ratkaisuksi. 6.4 Teemu Nousiainen Tämä kurssi oli mielenkiintoinen kokemus itselleni ohjelmistoprojektista. Aikaisemmin en ollut työelämässäkään osallistunut näin laajaan projektiin näin pitkäksi aikaa. Kurssi oli työläs, sillä aiheemme vaati niin paljon tutkimusta, suunnittelua ja aiheen opiskelua. Tämä oli hieman kurssin rakenteen kanssa ristiriidassa, koska kurssi painotti toteuttamista enemmän, kuin mitä ryhmällämme oli alussa mahdollista toteuttaa. Pääohjelmoijana keskityin moniin käytännön kysymyksiin, kuten infrastruktuurin ylläpitoon (cvs, uutisryhmä, testauksen automatisointi). Harmillista kyllä, toteutuksen painottuessa projektin jälkipuoliskolle, testausta päästiin käyttämään turhan lyhyellä aikajaksolla. Ryhmän jäsenistä minulla on vähiten kokemusta ohjelmistoprojekteista. Tämän vuoksi pidän tätä kurssia tärkeänä itselleni. Ryhmän koko jo itsessään pakotti toiminnan määrämuotoistamiseen, mikä teki tutuksi eri ryhmätyöskentelyn käytäntöjä. Ongelmana oli työtaakan epätasainen jakautuminen, mutta omalla kohdallani työt painottuivat sopivaan ajankohtaan. Yleisesti ottaen, pidän projektia positiivisena kokemuksena, koska opimme selviämään ongelmista ja haasteista.

T-76.115 Loppuraportti Sivu 17 (19) 6.5 Jani Honkanen Tavoitteenani oli lähinnä saada lisää kokemusta projektityöskentelystä, mikä onnistui kohtuullisen hyvin. Projektin aihe oli oppimisen kannalta mielekäs ja sisälsi paljon haasteita, vaikka kaikkia ohjelmistoprojektin osa-alueita ei päästy kunnolla kokeilemaan. Projektiryhmän koko tuntui suurelta ja tämä pakotti ryhmän toimimaan hieman formaalimmin, mikä tuntui olevan oppimisen kannalta hyvä asia. Ryhmän jäsenistä löytyi melko erilaisiin työskentelytapoihin tottuneita ihmisiä, joiden kanssa työskenteleminen oli avartava kokemus. Omana vastuualueenani oli arkkitehtuurin suunnittelu tai sen koordinointi. Haasteena oli projektin tavoitteiden epämääräisyys (projekti oli kokeiluluonteinen), vaikka vaatimuksista oltiinkin saatu tietoa asiakkaalta. Itse arkkitehtuurin suunnittelu onnistui mielestäni alkuvaiheessa hyvin, mutta kommunikoinnissa ja koko ryhmän aivokapasiteetin ja ideavaraston hyödyntämisessä oli vielä oppimista. Toisaalta tätä vaikeutti se, etteivät ryhmäläiset tunteneet toisiaan ennalta ja ettei ryhmällä ollut kovin paljon yhteistä työskentelyaikaa. Projektin tavoitteina oli tuottaa jatkokehityskelpoinen ETL-työkalun runko, sekä arvioida oman ETL-työkalun toteuttamiseen vaatimaa työmäärää. Ensimmäinen tavoite ei uskoakseni toteutunut kovin hyvin, vaan tuotteesta tuli melko prototyyppimäinen. Syy tähän lienee se, että kenelläkään ryhmäläisellä ei ollut juuri kokemusta ETL-maailmasta, eikä vaatimusmäärittelyyn ja suunnitteluun panostamisesta huolimatta osattu keskittyä oikeisiin ongelmiin. Työmäärältään kurssi vastasi Trapoliin merkittyjen tuntien perusteella opintoviikkomäärää, mutta todellisuudessa projektin tiiviin rytmin ja ongelmatilanteiden takia kurssi oli huomattavasti työläämpi. 6.6 Jani Malmi Kurssi oli yllättävän työläs, mutta myös antoisa. Opin uusia asioita koodaamisesta, isomman projektin ongelmista ja ETL-maailmasta. Harvemmin tulee näin isolla porukalla tehtyä projektia yhdessä joten sinänsä harvinainen kokemus. Ryhmän suuruus ja se että emme aluksi tunteneet toisiamme asetti omat haasteensa projektille, mutta mielestäni selviydyimme ongelmista hyvin. Osallistuin dokumenteista eniten vaatimusmäärittelyn tekemiseen ja päivittämiseen. Sen osalta huomasin kuten olen jo työelämässäkin huomannut että on hyvin tärkeää olla asiakkaan kanssa tekemisissä ja varmistaa että kumpikin on ymmärtänyt asiat samalla tavalla. Pääsimme mielestäni hyvin yhteisymmärrykseen asiakkaan kanssa projektin vaatimuksista ja vaatimusmäärittelystä tuli onnistunut. Epäselvätkin asiat saimme selvitettyä, koska tapasimme asiakkaan kanssa melko usein ja kävimme yhdessä vaatimusmäärittelyä lävitse useampaan otteeseen. Koodaamisessa osallistuin eniten toimenpiteiden toteutukseen. Vaikka välillä oli vaikeaa löytää aikaa tehtäville varsinkin keväällä sain niitä kuitenkin toteutettua. Ryhmämme toteutti yllättävän paljon koodia ja välillä joutui käyttämään aikaa myös toisten tekemien koodien lukemiseen. Ideaalista olisi ollut tietysti se, että olisimme voineet enemmän koodata ja suunnitella yhdessä, mutta monet asiat ja kiireet tekivät sen valitettavasti osaltani melkein mahdottomaksi. Pahoittelen omaa kiireellisyyttäni. Ryhmämme oli mielestäni taitava ja osaamista löytyi monelta alueelta joten mahdottomaksi esteeksi yhteisten koodaushetkien vähyys ei tullut. Mielestäni ryhmänä selviydyimme hyvin erilaisista haasteista. Mielestäni porukka oli mukavaa sekä kurssilla että asiakkaan puolella. Kiitokset tästä tiimille ja asiakkaalle. 6.7 Mika Suvanto Projekti oli kokonaisuudessaan pitkä ja työläs, mutta samalla opettavainen. Haastava aihe, aikatau-

T-76.115 Loppuraportti Sivu 18 (19) lujen sovittamisen vaikeudet, entuudestaan täysin tuntematon projektiryhmä ja kurssin asettamat vaatimukset lisäsivät projektin vaikeutta. Kenties tärkeimmät kokemukset ja oppi tuli jo projektin alkuvaiheissa kahden ensimmäisen iteraation aikana. Tällöin täytyi sopia kaikista mahdollisesta käytännöistä, ja tämän vaiheen raskaus ja välttämättömyys tuli selväksi. Seitsemän hengen ryhmässä on kuitenkin aina erilaisia mielipiteitä asiassa kuin asiassa, ja ryhmän jäsenten tasavertainen asema tarkoitti, että näistä asioista keskusteltiin runsaasti. Jokaisella on myös oma tapansa ja rytminsä työskennellä, mikä vaatii tottumista ja yhteensovittelua. Projektin loppupuolella tähänkin osasi jo paremmin varautua. Projektin johdon ja hallinnan suuri tarve tuli myös havaittua. Aiemmissa projekteissani, 2-4 hengen ryhmissä, tässä on päästy paljon helpommalla. Suurempi ryhmä ja ajallisesti pitkä projekti, jossa on paljon välitavoitteita ja määräaikoja, vaatii kuitenkin tiukkaa projektinhallintaa. Näiden käytäntöjen miettiminen ja kokeminen oikeassa projektissa oli opettavaista. Teknisistä asioista opin uutta ennen kaikkea tietovarastoinnista, joka oli käsitteenäkin minulle uusi. Samoin XML:stä tuli uutta ja hyödyllistä oppia. Kokonaisuutena voin sanoa, että projektille asettamani oppimistavoitteet täyttyivät varsin hyvin. 7 Kurssipalaute Mielestämme kurssi on erittäin hyödyllinen, koska se antaa mahdollisuuden tutustua työskentelyyn laajemmassa ohjelmistoprojektissa. Käytännön järjestelyissä oli sikäli ongelmia, että kurssi olisi voinut tarjota riittävän varhaisessa vaiheessa luotettavan webportaaliohjelmiston (Wiki) ja CVS:n ryhmän käyttöön nyt käyttöönotto kesti turhan kauan ja toteutimme palvelut omin voimin. Myös ryhmämme kohdalla ilmenneet epäselvyydet salassapitosopimuksen kanssa olisi ehkä voitu välttää, jos kurssin henkilökunta olisi informoinut asiakasta riittävästi etukäteen, kenties ehdot voisi olla selvillä jo projektin valintatilanteessa. Tilanne oli kuitenkin uusi ja yllättävä kaikille osapuolille. SEPA:t koettiin hieman irrallisiksi osiksi kurssia, kuitenkin projektipäällikön päiväkirja on hyvä käytäntö josta myös muille selviää projektipäällikön roolin ongelmia. Työmenetelmien ohjaus ei ole aina kovin toimiva idea; iteratiivinen kehitys, käyttötapaukset tms. eivät joka projektissa ole parhaita tapoja. Mentor voisi ottaa aktiivisemmin kantaa asioihin myös iteraation aikana eikä vain loppuarvostelussa, esim. lukemalla esiversioita palautettavista dokumenteista jne. Toisaalta on hyvä, että ryhmä saa itse tehdä omat ratkaisut. Projektien erilaisuus huomioitu hyvin. Trapolista: Saisiko tänne graafisia raportteja? Raportointi työtyypin mukaan on hieman keinotekoista ongelmana määrittely, mikä kuuluu minnekin Tuntikirjauksessa status: started on huono oletusarvo, parempi olisi no filter. Voisiko Trapolin korvata jollain muulla? Yleisesti olisi hyvä, että on yksi työkalu, johon kirjataan tehtävät, tunnit ja bugit. Kaksoiskirjaus meidän tapauksessamme Trapoliin ja JIRAan ei ollut järkevää.

T-76.115 Loppuraportti Sivu 19 (19) 8 Jatkokehitys 8.1.1 Tunnetut bugit Ohjelmistosta löydetyt bugit on kirjattu asiakkaan toimittamaan JIRA -järjestelmään koko kehitystyön ajan, ja ajantasainen informaatio löytyy sieltä. Raportti avoimista bugeista on uusimmassa testiraportissa.[12]. 8.1.2 Kehitysideat Alla on listattu kohteita jatkokehitystä ajatellen, näistä tarkempi kuvaus on Kehitysohjeessa [5]. Virheidenhallinnan jatkokehittäminen ja varmistaminen Dokumentaatiogeneraattorin jalostus Graafinen käyttöliittymä prosessikuvausten luomiseen Tuen lisääminen eri tietokannoille Suorituskyvyn optimointi indeksien käytöillä 9 Viitteet [1] T-76.115 kurssin kotisivut, http://www.soberit.hut.fi/t-76.115/ [2] Riskienhallintadokumentti, ExtraTerrestriaLs [3] Kysely asiakkaalle projektista [4] Kysely ryhmälle projektista [5] Kehitysohje, ExtraTerrestriaLs [6] SEPA, Teemu Nousiainen, Jani Malmi [7] SEPA, Risto Kunnas, Timo Sallinen [8] SEPA, Mika Suvanto, Jani Honkanen [9] Laatukäsikirja, ExtraTerrestriaLs [10] SEPA, Mikko Ruokojoki [11] Projektisuunnitelma, ExtraTerrestriaLs [12] Testiraportti TR-3, ExtraTerrestriaLs

Kehitysversio Yhteenveto: ETL-työkalu - Kysely ryhmälle Sivu 1 Asteikko negatiivinen <-> positiivinen 5 Vastausprosentti: 100 % 6 Kommentit Raporttiin poimittu 7 / 7 vastausta. Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Tavoitteet kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 1 Olen oppinut paljon uutta ohjelmistoprojektissa 7 100% 14% 14% 71% 4,57 0,79 työskentelystä 2 Olen pystynyt kehittämään taitojani ja laajentamaan 7 100% 14% 57% 29% 4,14 0,69 tietotaitoani 3 Ryhmätyö on mielestäni sujunut hyvin 7 100% 29% 71% 3,71 0,49 4 Projektin tavoitteet saavutettiin 7 100% 14% 71% 14% 4,00 0,58 Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Tuote kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 7 Tuote on mielestäni laadukas 7 100% 57% 43% 3,43 0,53 8 ETL työkalu on jatkokehityskelpoinen 7 100% 14% 43% 43% 4,29 0,76 9 Koodi on hyvin dokumentoitua ja kommentoitua (ET7) 7 100% 43% 57% 3,57 0,53 10 Koodi on helposti ylläpidettävää (ET6) 7 100% 57% 29% 14% 3,57 0,79 11 Uuden toimenpideluokan lisääminen on riittävän 6 86% 33% 50% 17% 3,83 0,75 helppoa (ET10) 12 Järjestelmä on vakaa 6 86% 100% 3,00 13 Järjestelmä pystyy toipumaan virhetilanteista (ET11) 6 86% 67% 17% 17% 2,50 0,84 Asteikko negatiivinen <-> positiivinen 14 Kommentit Virhetilanteiden käsittely jäi taka-alalle ja muiden ominaisuuksien kehittämisen alle. Toisaalta tämä oli tutkimusluontoinen projekti, ja virheiden hallinta on enemmänkin eduksi tuotantokäytössä. Järjestelemä ei selviydy virheistä kovin hyvin. Tosin kehitysvaiheessa tätä ei ehkä kannatakaan tehdä kovin aikaisessa vaiheessa.

Kehitysversio Yhteenveto: ETL-työkalu - Kysely ryhmälle Sivu 2 Asteikko negatiivinen <-> positiivinen 27 Kommentit JIRAssa oli pieniä ongelmia oikeuksien kanssa. CVS ei sovellu binääristen dokumenttien hallintaan, jos niitä kehittää useampi henkilö yhtaikaisesti. Ehkä html olisi ollut parempi (minulla on testauskurssilta hyviä kokemuksia). Uutisryhmä toimi kohtuullisen hyvin, mutta tiedostojen levittämisessä se on hieman kömpelö. Työnjako oli epätasaista, koska parilla jäsenellä hommat kasautuivat loppuun. Työkaluista ja työtavoista pystyttiin löytämään alkuvaikeuksien jälkeen varsin hyvin toimivat vaihtoehdot. Projekti mielestäni on ollut koko ajan varsin hyvin hallussa ja tilanne ryhmän ja asiakkaan tiedossa. Tehtävien kaksoiskirjaus sekä jiraan että trapoliin ei tuntunut järkevältä. Raporttiin poimittu 7 / 7 vastausta. Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Työkalut ja työtavat kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 15 Trapoli soveltui projektin tarpeisiin 7 100% 29% 14% 29% 29% 3,57 1,27 16 JIRA soveltui projektin tarpeisiin 7 100% 14% 43% 43% 4,29 0,76 17 CVS soveltui projektin tavoitteisiin 7 100% 14% 29% 57% 4,43 0,79 18 MySQL soveltui projektin tavoitteisiin 6 86% 17% 33% 50% 4,33 0,82 19 OpenOffice soveltui projektin tavoitteisiin 7 100% 29% 43% 29% 4,00 0,82 20 News soveltui projektin tavoitteisiin 7 100% 14% 57% 29% 4,14 0,69 21 Sähköposti soveltui projektin tavoitteisiin 7 100% 29% 43% 29% 4,00 0,82 22 Viikkopalaverit soveltuivat projektin tavoitteisiin 7 100% 14% 43% 43% 4,29 0,76 23 Työnjako oli tasapuolista 7 100% 14% 29% 57% 3,43 0,79 24 Työnjako oli riittävän selkeätä 7 100% 43% 57% 3,57 0,53 25 Johtaminen oli hyvää 6 86% 33% 50% 17% 3,83 0,75 26 Projekti vietiin läpi hallitusti 7 100% 43% 43% 14% 3,71 0,76 Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Osa-alueet kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 28 Riskienhallinta tuki projektia 7 100% 43% 43% 14% 3,71 0,76 29 Vaatimusmäärittely onnistui 7 100% 14% 57% 29% 4,14 0,69 30 Projektisuunnitelma onnistui 7 100% 29% 43% 29% 4,00 0,82 31 Arkkitehtuurinen suunnittelu onnistui 6 86% 33% 67% 3,67 0,52 32 Testaus onnistui 7 100% 71% 29% 3,29 0,49 Asteikko negatiivinen <-> positiivinen 33 Kommentit Testaukseen olisi pitänyt panostaa ja luoda automatisointikäytäntö aiemmin. Toisaalta testattavaa koodia tuli myös liian myöhään. Testausta olisi pitänyt tehdä enemmän aiemmin. Ylipäänsä koko projektia olisi voinut lähestyä vähän modernimmalla mallilla, nyt mentiin pitkälti vesiputousmallin mukaan. Tosin kohtuullisen onnistuneesti. Iteratiivisuus puuttui projektin alkuvaiheessa, mutta parantui loppua kohden.

Kehitysversio Yhteenveto: ETL-työkalun kysely asiakkaalle Sivu 1 Asteikko negatiivinen <-> positiivinen 4 Vapaat kommentit Ehdottoasti tuosta on hyvä jatkaa eteenpäin, mutta homman järkevyydestä en osaa sanoa :) Asteikko negatiivinen <-> positiivinen 8 Vapaat kommentit Lopputulokseen vaikuttamisesta: Myös ryhmäläset toivat ajatuksiaan esille melko hyvin, mikä on hyvä asia. Välillä tosin tuntui, että joitain mielipiteitä jäi sanomatta. Raporttiin poimittu 2 / 2 vastausta. Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Tavoitteet kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 1 Projektin tavoitteet saavutettiin 2 100% 100% 4,00 2 Oman ETL-työkalun kehittäminen on järkevää 2 100% 100% 3,00 3 ETL työkalu on jatkokehityskelpoinen 2 100% 50% 50% 4,50 0,71 Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Työtavat kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 5 Saimme riittävästi tietoa projektin etenemisestä 2 100% 100% 5,00 6 Projektin johtaminen oli hyvää 2 100% 50% 50% 4,50 0,71 7 Pystyimme riittävästi vaikuttamaan projektin 2 100% 50% 50% 4,50 0,71 etenemiseen Vastauksia Vastausvaihtoehtojen vastausprosentit Keskiarvhajonta Keski- # Laatu kysymykseen kpl Vast.% VV1 VV2 VV3 VV4 VV5 9 Dokumentaatio on riittävää 2 100% 50% 50% 3,50 0,71 10 Tuote on mielestäni laadukas 2 100% 100% 4,00 Asteikko negatiivinen <-> positiivinen 11 Vastausprosentti: 100 % 12 Vapaat kommentit Dokumentaatio on ehkä puutteellisin osa-alue. Siitä on kyllä aikaa, kun viimeksi dokkareita selasin. Kokonaisarvosana on 5, jos dokumentaatio on nyt niin hyvä, kun uskon se olevan.