OtaShop2 T-76.115 Versio Päivämäärä Tekijä Kuvaus 1.5 5.4.2004 Halme Valmis 1.0 25.3.2004 Halme Runko kasassa 1 (22)
1. JOHDANTO... 3 1.1. PROJEKTIN TAUSTA... 3 1.2. PROJEKTIN TAVOITTEET... 3 2. PROJEKTIN ETENEMINEN... 4 2.1. PROJEKTIN ETENEMINEN VAIHEITTAIN... 4 2.1.1. Suunnitteluvaihe... 4 2.1.2. Toteutus 1... 4 2.1.3. Toteutus 2... 4 2.1.4. Toteutus 3... 5 2.1.5. Toimitus... 6 3. JÄLKIPUINTI... 6 3.1. KÄYTETYT TYÖTUNNIT... 6 3.2. OHJELMISTON KOKO... 8 3.3. OHJELMISTON LAATU... 9 3.4. RISKIENHALLINTA... 11 3.5. RYHMÄN TYÖNJAKO... 11 4. TULOKSET... 11 4.1. ASIAKKAAN TAVOITTEIDEN TOTEUTUMINEN... 11 4.2. PROJEKTIRYHMÄN TAVOITTEIDEN TOTEUTUMINEN... 12 4.2.1. Tuottaa sovitulla työmäärällä (1200-1500 h) ohjelmisto, joka täyttää vaatimusmäärittelydokumentissa sille asetetut vaatimukset, ja on asiakkaalle hyödyllinen ja käyttökelpoinen.... 12 4.2.2. Tuottaa sellaiset dokumentit, joita asiakas voi käyttää mallina myöhemmissä projekteissaan.... 12 4.2.3. Suorittaa kurssi hyvällä arvosanalla. (Arvosana 4 tai 5)... 12 5. TYÖTAVAT JA TYÖKALUT... 12 5.1. TYÖTAVAT... 12 5.1.1. Iteratiivinen kehitys ja suunnittelu... 13 5.1.2. Riskienhallinta... 13 5.1.3. Tunti- ja muu raportointi, projektinhallinta... 13 5.1.4. Vikojen hallinta... 13 5.1.5. Dokumentointi ja dokumenttien jakelu... 13 5.1.6. Projektin katselmointitilaisuudet... 13 5.1.7. Vaatimusten priorisointi...14 5.1.8. Vaatimusten hallinta... 14 5.1.9. Käyttötapaukset... 14 5.1.10. Versionhallinta... 14 5.1.11. Testaus... 14 5.1.12. Vertaistestaus... 14 5.1.13. Suunnittelumallit... 15 5.1.14. Refaktorointi... 15 5.2. HENKILÖKOHTAISET OHJELMISTOTUOTANNON TEHTÄVÄT... 15 5.3. TYÖKALUT... 15 6. OPETUKSELLINEN ARVO... 16 6.1. ARVIOIJANA ERKKA HALME... 16 6.2. ARVIOIJANA KAI INKINEN... 17 6.3. ARVIOIJANA KARRI KARANKO... 17 6.4. ARVIOIJANA MATTI KOSUNEN... 18 6.5. ARVIOIJANA ANTTI KÄRKKÄINEN... 19 6.6. ARVIOIJANA ANNA LARMO... 19 6.7. ARVIOIJANA SIMO OJANEN... 20 7. KURSSIPALAUTE... 20 7.1. ARVIOIJANA ERKKA HALME... 20 2 (22)
7.2. ARVIOIJANA KAI INKINEN... 21 7.3. ARVIOIJANA KARRI KARANKO... 21 7.4. ARVIOIJANA MATTI KOSUNEN... 21 7.5. ARVIOIJANA ANTTI KÄRKKÄINEN... 21 7.6. ARVIOIJANA ANNA LARMO... 22 7.7. ARVIOIJANA SIMO OJANEN... 22 1. Johdanto 1.1. Projektin tausta 1.2. Projektin tavoitteet Taulukko 1: Asiakkaan 10 tärkeintä tavoitetta Tavoite Varmennusperuste Kenen tavoite 1. yhteistyö muiden yksiköiden ja toimistojen kanssa Projektiin osallistuneiden yksiköiden ja toimistojen näkemykset järjestelmästä ovat Kirjasto 2. opitaan tietojärjestelmän kehitystyötä käytännössä 3. saadaan kokemusta J2EEtoteutusympäristöstä 4. saadaan nykyaikaiset kuvaus- ja dokumentaatiopohjat 5. saadaan lisää projektinjohtotaitoa atkkeskukseen 6. osoittaa, että opiskelijatyönä saadaan hyviä tuloksia 7. Tuottaa järjestelmä, joka toimii Taloustoimiston prosessien kanssa 8. Käytettävyys tilaajan kannalta 9. Käytettävyys julkaisujen toimittajan kannalta 10. Käytettävyys myynnin seurannan kannalta yhtenevät. Kirjastolle jää projektista dokumentaatio, jossa kuvataan tässä projektissa käytetty ohjelmistokehitysprosessi ja menetelmät. Järjestelmällä on testikäytössä joko atkkeskuksessa tai ulkopuolella ja sille on järjestetty ylläpito. Atk-päällikkö tarkastaa että toimitettuja dokumentteja voidaan käyttää pohjana myös tulevissa projekteissa Projektipäällikkö on tulevaisuudessa valmis ohjaamaan muita vastaavia projekteja atkkeskuksessa. Kirjasto tarkastaa, että valmis järjestelmä toimii riittävän hyvin. Taloustoimisto tarkastaa, että järjestelmässä on toteutettuna määritetyt liitännät olemassa oleviin järjestelmiin. Järjestelmää tuntemattoman käyttäjän pitää pystyä tilaaman ja maksamaan tietty julkaisu alle 5 minuutissa. Julkaisun toimittajan pitää pystyä tulostamaan 5 viimeisen tilauksen toimitustiedot alle 5 minuutissa. Laboratorion pitää pystyä listaamaan määrittelemänään aikavälinä myytyjen julkaisuiden nimet ja lukumäärät. Kirjasto Pasi Ranne,atkkeskus Pasi Ranne, atkkeskus Pasi Ranne, atkkeskus kirjasto, Pasi Ranne Taloustoimisto Kirjasto Pilottivaiheen laboratoriot Pilottivaiheen laboratoriot Taulukko 2: Projektiryhmän tavoitteet Projektiryhmän tavoitteet Tuottaa sovitulla työmäärällä (1200-1500 h) ohjelmisto, joka täyttää vaatimusmäärittelydokumentissa sille asetetut vaatimukset, ja on asiakkaalle hyödyllinen ja käyttökelpoinen. Tuottaa sellaiset dokumentit, joita asiakas voi käyttää mallina myöhemmissä projekteissaan. Suorittaa kurssi hyvällä arvosanalla. (Arvosana 4 tai 5) 3 (22)
2. Projektin eteneminen 2.1. Projektin eteneminen vaiheittain Projekti oli kurssin vaatimuksien mukaan jaettu eri vaiheisiin, iteraatioihin. Iteraatiot oli nimetty niiden pääasiallisen tehtävän mukaan vaiheisiin suunnittelu, Toteutus 1, 2 ja 3 sekä toimitus. Vaiheet olivat ajoitettu siten että suunnitteluvaihe ajoittui kurssin alkuun, syyskuun lopusta lokakuun loppuun. Toteutus 1 ajoittui marraskuun alusta joulukuun alkuun. Toteutus 2 oli vaiheista pisin, kymmenen viikkoa, joulukuusta helmikuun puoleen väliin. Toteutus 3 oli taas lyhyempi ja kesti maaliskuun puoleen väliin. Toimitus-vaihe on 3 viikon mittainen. 2.1.1. Suunnitteluvaihe Suunnitteluvaiheessa projektimme lähti hyvin käyntiin, ja intoa riitti vaiheen alussa. Pidimme palavereita viikoittain, ja yhteydenpito asiakkaaseen oli aktiivista. Osalla ryhmästä oli ennestään kokemusta vastaavista sovelluksista, joten emme kokeneet että tehtävästä tulisi enempiä ongelmia. Vaiheen tärkeimpänä tavoitteena oli tehdä vaatimusmäärittely asiakkaan kanssa, sekä aikataulut projektin myöhempiä vaiheita varten. Myös työtavat sekä henkilökohtaiset harjoitukset päätettiin tässä vaiheessa. Kaiken kaikkiaan suunnitteluvaihe meni meidän osaltamme odotusten mukaan ja työnteko saatiin hyvin alkuun. 2.1.2. Toteutus 1 Vaiheessa Toteutus 1 alkoi projektin varsinainen toteuttaminen, mikä meidän osaltamme tarkoitti pääosin ohjelmointia. Tässä vaiheessa asiakkaan kanssa sovittiin, että toteutamme kaupan, ja ylläpito sekä tilausten toimitus ja hallinta toteutettaisiin seuraavissa vaiheissa. Päätimme ryhmän sisällä että ohjelmointi jaetaan kaikkien kesken, jotta mahdollisimman monella säilyisi tuntuma toteuttamaamme sovellukseen. Projektipäällikkö ei kuitenkaan osallistunut ohjelmointiin. Osalla ryhmää oli ennestään vankka kokemus vastaavista sovelluksista, sekä J2EEstä, ja toisilla hieman vähemmän, mutta pyrimme jakamaan tehtävät siten että jokaiselle tulisi sopiva määrä työtä. Alussa työtapojen ja tekniikoiden käyttö aiheutti ongelmia, varsinkin jäsenille joilla ei ollut runsasta kokemusta, mutta ongelmat selvitettiin ja vaiheen toteutus saatiin tehtyä aikataulun mukaan. Aikaa jäi jopa hieman yli, joten toteutukseen voitiin panostaa, ja tehdä siitä helposti laajennettava myöhempiä vaiheita varten. Vaiheessa oli palautettavana myös runsaasti eri dokumentteja. Dokumenteissa määriteltiin toteutettava järjestelmä tarkemmin sekä laitteiston, toteutustekniikoiden sekä ulkoasun osalta. Dokumenttien kirjoittamiseen jäi hyvin aikaa, ja myös niiden laatu oli hyvä. Vaihe onnistui osaltamme erittäin hyvin ja samaa mieltä olivat myös mentor ja asiakas. 2.1.3. Toteutus 2 Tämä vaihe oli projektin pisin, kymmenen viikkoa, ajoittui joulun yli helmikuun puoleen väliin. Vaiheen pituus hämäsi meitä hiukan, sillä vaiheen alussa aikaa näytti olevan erittäin paljon. Vaiheen alkuun ajoittui myös tenttikausi, jolloin useimmilla ryhmän jäsenillä oli erinäisiä tenttejä ja harjoitustöiden palautuksia. Heti tämän jälkeen oli joulu, ja sitten kevään ensimmäinen tenttikausi. Aikatauluja ei tässä vaiheessa valvottu niin tarkkaan kuin olisi pitänyt, kokouksia ei pidetty eikä toimintaa ollut muutenkaan kovin paljon. Ennen 4 (22)
kuin saimme joulukinkun sulamaan, oli tammikuu lähestymässä loppuaan. Vaiheessa oli tarkoitus toteuttaa ylläpito-osuutta sekä jonkin verran laajentaa kauppaa joten töitä kyllä riitti. Vaiheen alussa päätettiin keskittää ohjelmointi neljälle henkilölle, kaksi muuta vastaisivat dokumenteista ja raporteista ja projektipäällikkö valvoisi toimintaa. Oman aikataulumme vuoksi meille tuli lopussa todella kiire. Dokumentteja ei kirjoitettu, kun järjestelmää ei ollut olemassa. Työtahtia kuitenkin kiristettiin merkittävästi kohti vaiheen loppua, joten kaikki suunniteltu toiminnallisuus saatiin toteutettua ja dokumentoitua. Aikaa ei kuitenkaan jäänyt yli, jolloin olisi voitu toteuttaa "ylimääräistä" toiminnallisuutta, kuten vaiheessa 1 tehtiin. Näin jälkikäteen voidaan todeta, että loppuvaiheen työtehon kiristäminen onnistui, sillä toiminnallisuus saatiin toteutettua. Kiireen alla ohjelmien toteutus luonnollisesti kärsii jonkin verran ja osa bugeista olisi varmasti voitu välttää paremmalla suunnittelulla ja rauhallisemmalla työtahdilla. Koska dokumenttien kirjoittaminen viivästyi samalla tavalla kuin kurssin vaiheen muut suoritteet, ei niidenkään laatu ollut parhaalla mahdollisella tasolla. Tämä johtui myös osaltaan siitä, että vaiheessa työtehtävät oli eriytetty, ei kommunikaatio ohjelmoijien ja dokumentoijien välillä toiminut aivan odotetulla tavalla. Loppuvaiheessa koodaajien työpanos keskittyi ohjelmakoodin tuottamiseen eikä aikaa dokumentaatioon jäänyt tarpeeksi. Tämä vaihe oli osaltamme melko heikko. Lähdimme liikkeelle liian itsevarmoina siitä, että toteutus olisi helppo toteuttaa annetussa ajassa. Olihan edellinen vaihe ollut menestyksekäs. Emme osanneet ottaa huomioon sitä että ylläpitojärjestelmän implementointi olisi vähintään yhtä haastavaa kuin itse kaupan. Emme myöskään olleet kokeneet viikoittaisia tapaamisia niin tärkeinä kuin ne itse asiassa olivat. 2.1.4. Toteutus 3 Edellisen vaiheen vastoinkäymisistä otimme opiksemme vaiheeseen Toteutus 3, joka ajoittui helmikuun ja maaliskuun vaihteeseen. Järjestelmän laatu oli hieman kärsinyt edellisen vaiheen kiireestä, joten tässä vaiheessa toiminnan pääpaino oli bugien ja vikojen korjaus, sekä järjestelmän yleinen parantaminen. Myös asiakkaan vaatimukset olivat tarkentuneet edellisen vaiheen lopussa, ja tämä vaati meiltä jonkin verran työtä. Vaiheeseen ajoittui myös vertaistestaus, jossa testaisimme toisen ryhmä tuotteen, ja vastaavasti OtaShop2 tulisi tämän ryhmän testaamaksi. Järjestelmän laatua saatiin merkittävästi parannettua heti vaiheen alussa. Bugeja saatiin korjattua melko nopeaan tahtiin ja uusia bugeja ei enää löytynyt yhtä nopeasti. Huomattavaa on että bugien korjaus aloitettiin vakavimmista, ja löydetyt uudet bugit olivat yleensä tasoltaan alhaisia tai mitättömiä, lähinnä makuasioita. Koska luottamus järjestelmän toimintaan kasvoi, annettiin se vaiheen aikana myös testikäyttöön asiakkaan edustajille. Tämän lisäksi järjestettiin tilaisuus, jossa asiakkaan edustaja pääsi kokeilemaan ja kommentoimaan järjestelmää hieman tarkemmin. Asiakkaalla oli jonkin verran huomautettavaa järjestelmästä ja samoin vertaistestausryhmällä, mutta kuten jo aiemmin mainittu, niin vakavia bugeja ei juurikaan löytynyt. Vaiheen lopussa avoimet bugit keskittyivät pääasiassa ylläpito-osuuteen. Vertaistestauksesta vastuullisiksi valittiin Anna ja Karri. Kurssin puolesta suunnitellun yleisen testi-istunnon lisäksi pyysimme vertaisryhmää keskittymään kaupan käytettävyyden tutkimiseen ja ylläpitoliittymän tekniseen läpikäyntiin. Vertaistestausta on analysoitu myöhemmin tässä dokumentissa. 5 (22)
Vaiheen aikana ei enää tuotettu juurikaan uusia dokumentteja, vaan olemassa olevia parannettiin ja tarkennettiin. Uutta materiaalia oli pääasiassa vertaistestaukseen liittyvät dokumentit. Huomattavaa on että vaiheen lopussa asiakkaan vaatimukset muuttuivat käytetyn laitteiston osalta. Projektilla oli tähän asti ollut käytössään Oraclen tietokantapalvelin joka nyt haluttiin muutettavan vastaavaan ilmaiseen palvelimeen. Päätimme käyttää PostgreSQL-järjestelmää. Järjestelmä oli suunniteltu siten että tietokannan vaihtaminen olisi helppoa, mutta koska asiaa ei ole voitu testata aiemmin, ei sen toteuttamisesta ollut varmuutta. Kanta saatiin kuitenkin ilman suurempia ongelmia vaihdettu, ja samalla voitiin todeta järjestelmän yhteensopivuus eri tietokantojen kanssa. Samalla asiaan tehtiin parannus ja jatkossa kannan vaihtaminen onnistuu entistä helpommin. Vaiheen lopussa saimme tietää muutoksesta jota olimme osanneet odottaa jo hetken aikaa. Järjestelmän käyttöönotosta ei ollut varmuutta, sillä sen sijoituksesta ja ylläpidosta ei vielä oltu sovittu, asiakkaan taholta. Tästä johtuen järjestelmää ei projektin aikataulun puitteissa tulla asentamaan asiakkaalle, vaan hänelle toimitetaan toimiva demo-järjestelmä, asennettuna kehityskoneelle, sekä asennuslevyt joilla järjestelmä voidaan myöhemmin asentaa asiakkaan päättämään paikkaan. Vaihe 3 oli osaltamme onnistunut. Kaikki vaiheen tavoitteet saatiin täytettyä. Tämän lisäksi ylimääräisenä tehtävänä tullut tietokannan vaihto saatiin tehtyä jo tämän vaiheen aikana. Toiminnallisuutta ei järjestelmään juurikaan lisätty, mutta laatua parannettiin merkittävästi. Myös asiakas ja mentor olivat vaiheeseen tyytyväisiä. 2.1.5. Toimitus Toimitusvaiheessa järjestelmä on tarkoitus palauttaa asiakkaalle. Tässä vaiheessa oli myös tarkoitus antaa palautetta kurssin etenemisestä ja järjestelyistä. Vaiheen tärkeimpinä tavoitteina oli viimeisten bugien korjaaminen ennen järjestelmän luovuttamista, sekä omien henkilökohtaisten tavoitteiden toteutumisten ja saavutusten arviointi. Vaiheen tavoitteet täyttyivät varsin hyvin. 3. Jälkipuinti 3.1. Käytetyt työtunnit Projektiin käytettiin kaikkiaan noin 100 tuntia vähemmän, kuin alkuperäisessä suunnitelmassa oli. Tuntimäärä osuu kuitenkin projektisuunnitelmassa olevan tavoitteen sisälle. Käytetyt tunnit henkilöittäin ja vaiheittain on esitetty alla olevissa taulukossa ja kaaviossa. PP I1 I2 I3 DE Yht. su tot su tot su tot su tot su tot su tot Erkka 50 50 39 37 40 39 30 35 18 21 190 182 Anna 40 30 40 37 50 24 48 44 40 20 190 155 Antti 40 38 45 25 66 48 45 52 23 20 190 183 Kai 40 28 45 43 61 37 48 33 40 31 190 172 6 (22)
Karri 35 35 46 40 59 47 40 42 22 24 190 188 Matti 40 38 45 31 60 51 40 34 27 23 190 177 Simo 40 27 45 38 63 36 48 47 35 18 190 166 Yhteensä 285 246 305 251 399 282 299 287 205 157 1330 1223 Toteutuneet tunnit henkilöittäin 200,00 180,00 160,00 140,00 Tunnit 120,00 100,00 80,00 akarkkai alarmo eshalme kinkinen kkaranko mjkosune siojanen 60,00 40,00 20,00 0,00 PP I1 I2 I3 DE Vaihe Alla olevassa kaaviossa on esitetty työtuntien jakaantuminen eri työtyyppeihin. Dokumentoinnin suuri osuus johtuu osaltaan kurssin vaatimuksista, ja "oikeissa" projekteissa dokumentointia olisikin luultavasti selvästi vähemmän. Lisäksi osa dokumentointiin merkityistä tunneista kuuluisivat varmasti paremminkin "design" osaan. 7 (22)
Työtunnit tyypeittäin proj. management 5 % studying 3 % testing 8 % comp. maintenance 5 % design 1 % programming 31 % documentation 24 % lectures 0 % comp. maintenance design documentation lectures meetings pair programming programming proj. management studying testing pair programming 1 % meetings 22 % 3.2. Ohjelmiston koko Toteutettujen koodirivien määrä on esitelty alla olevassa taulukossa sekä kaaviossa. Koodirivit 12000 10000 8000 Rivit 6000 Kommenttirivit Koodirivit 4000 2000 0 I1 I2 I3 DE Vaihe 8 (22)
I1 I2 I3 DE koodi kom. koodi kom. koodi kom. koodi kom. CART 77 38 77 38 109 60 109 60 DAO 354 214 360 224 366 235 239 236 LANGUAGE 94 49 102 49 102 49 102 49 ORDER 236 216 298 313 347 364 347 364 PAYMENT 246 165 593 399 765 415 765 415 ORDERDAO 855 501 1018 574 937 667 VALIDATOR 41 45 41 45 JSP 104 58 77 61 77 61 JSP-tiedostot* 722 919 1025 1771 OS2ADMIN 238 47 238 47 352 66 ACTIONS 442 128 353 133 426 140 ACTIONFORMS 366 81 329 80 USERADMIN 460 115 539 97 544 97 JSP/os2admin 952 725 772 Testiluokat* 239 548 610 750 YHTEENSÄ 1968 682 5948 1872 6681 2161 7561 2280 YHTEENSÄ 2650 7820 8842 9841 Taulukosta voidaan havaita, että suurin osa koodista kirjoitettiin I2-vaiheessa. Rivimääriä tarkastellessa on syytä huomioida, että refaktorointi saattaa myös vähentää koodin määrää. 3.3. Ohjelmiston laatu 9 (22)
Järjestelmästä löydetyt bugit sekä korjatut bugit on esitetty alla olevassa kaaviossa. Bugien/korjausehdotusten lukumäärät 90 80 70 60 Määrä (kpl) 50 40 Korjatut Avoimet Havaitut 30 20 10 0 9.2.2004 16.2.2004 23.2.2004 1.3.2004 8.3.2004 15.3.2004 22.3.2004 29.3.2004 5.4.2004 Päivä Bugien jakautuminen niiden vakavuuden mukaan on esitetty seuraavassa kaaviossa. Kaaviosta voidaan nähdä, että järjestelmän laadun parantuessa vakavampien bugien suhteellinen osuus vähenee selvästi. Bugit ryhmiteltynä vakavuuden mukaan 35 30 25 Määrä (kpl) 20 15 trivial minor major critical blocker 10 5 0 9.2.2004 16.2.2004 23.2.2004 1.3.2004 8.3.2004 15.3.2004 22.3.2004 29.3.2004 5.4.2004 Päivä 10 (22)
3.4. Riskienhallinta Projektin aikana ylläpidettiin erillistä riskienhallintadokumenttia, jossa riskit on esitetty taulukkomuodossa. Dokumenttia päivitettiin, kunkin vaiheen aikana, kun riskeissä tapahtui muutoksia. 3.5. Ryhmän työnjako Heti projektin alussa kullekin ryhmän jäsenelle sovittiin oma vastuualue. Näitä vastuualueita ei projektin aikana muutettu. Vastuualueet olivat: Projektipäällikkö: Vastaa projektista kokonaisuutena, huolehtii aikataulun suunnittelemisesta ja valvoo aikataulun toteutumista. Projektipäällikkö myös vastaa, että tarpeelliset dokumentit tulevat tehtyä. Käyttöliittymä: Vastaa käyttöliittymän suunnittelemisesta ja testaamisesta sekä käyttöohjeiden ja käyttäjien koulutuksen suunnittelusta. Kehitysympäristö: Vastaa kehitysalustasta sekä käyttöönoton ja ylläpidon suunnittelusta. Tietoturva: Vastaa järjestelmän suunnittelusta tietoturva-näkökulmasta. Testaus: Vastaa testauksen suunnittelusta ja dokumentoinnista. Ohjelmistoarkkitehtuuri: Vastaa järjestelmän ohjelmistoarkkitehtuurin suunnittelusta. Tietokanta: Vastaa järjestelmän tarvitsemien tietokantojen suunnittelusta sekä tietokantayhteyksistä jo olemassa oleviin kantoihin Vastuualueita ei ollut tarvetta muuttaa projektin aikana, sillä joustimme tarpeen mukaan, kun tehtäviä jaettiin eri henkilöille. Käytännössä muutoksia työnjakoon aiheutti se, että osa tietokannan ylläpidosta siirrettiin kehitysympäristöstä vastaavalle, ja toisaalta se, että tietoturva-vastaavalle annettiin paljon myös muiden vastuualueiden tehtäviä. 4. Tulokset 4.1. Asiakkaan tavoitteiden toteutuminen Esitämme tässä vain ryhmän arvion asiakkaan tavoitteiden toteutumisesta. Tavoite Varmennusperuste Ryhmän arvio toteutumisesta 1. yhteistyö muiden yksiköiden ja toimistojen kanssa Projektiin osallistuneiden yksiköiden ja toimistojen näkemykset järjestelmästä ovat Toteutunut, eri osapuolten välillä ei ollut oikeastaan missään vaiheessa epäselvyyksiä 2. opitaan tietojärjestelmän kehitystyötä käytännössä 3. saadaan kokemusta J2EEtoteutusympäristöstä yhtenevät. Kirjastolle jää projektista dokumentaatio, jossa kuvataan tässä projektissa käytetty ohjelmistokehitysprosessi ja menetelmät. Järjestelmällä on testikäytössä joko atk-keskuksessa tai ulkopuolella ja sille on järjestetty ylläpito. järjestelmän toiminnallisuudesta. Toteutunut, kirjastolle jää kurssin aikana syntynyt dokumentaatio, sekä lisäksi useampi kirjaston henkilökuntaan kuuluva on osallistunut jossakin vaiheessa projektiin. Puoliksi toteutunut. Järjestelmä on asennettuna suppeaa testikäyttöä varten, mutta sen ylläpidosta ei ole varmuutta. 11 (22)
4. saadaan nykyaikaiset kuvaus- ja dokumentaatiopohjat 5. saadaan lisää projektinjohtotaitoa atkkeskukseen 6. osoittaa, että opiskelijatyönä saadaan hyviä tuloksia 7. Tuottaa järjestelmä, joka toimii Taloustoimiston prosessien kanssa 8. Käytettävyys tilaajan kannalta 9. Käytettävyys julkaisujen toimittajan kannalta 10. Käytettävyys myynnin seurannan kannalta Atk-päällikkö tarkastaa että toimitettuja dokumentteja voidaan käyttää pohjana myös tulevissa projekteissa Projektipäällikkö on tulevaisuudessa valmis ohjaamaan muita vastaavia projekteja atkkeskuksessa. Kirjasto tarkastaa, että valmis järjestelmä toimii riittävän hyvin. Taloustoimisto tarkastaa, että järjestelmässä on toteutettuna määritetyt liitännät olemassa oleviin järjestelmiin. Järjestelmää tuntemattoman käyttäjän pitää pystyä tilaaman ja maksamaan tietty julkaisu alle 5 minuutissa. Julkaisun toimittajan pitää pystyä tulostamaan 5 viimeisen tilauksen toimitustiedot alle 5 minuutissa. Laboratorion pitää pystyä listaamaan määrittelemänään aikavälinä myytyjen julkaisuiden nimet ja lukumäärät. Toteutunut. Dokumentteja on jo käytetty mallina muissa atkkeskuksen projekteissa. Toteutunut. Projektipäällikkö on saanut arvokasta kokemusta projektin ohjaamisesta, ja on edelleen töissä atk-keskuksessa. Toteutunut Toteutunut, liitännät on tehty taloustoimiston ohjeiden mukaan. Ei ole testattu, mutta omien käytettävyystestien mukaan ei pitäisi olla ongelma. Ei ole testattu, mutta omien käytettävyystestien mukaan ei pitäisi olla ongelma. Toteutunut 4.2. Projektiryhmän tavoitteiden toteutuminen 4.2.1. Tuottaa sovitulla työmäärällä (1200-1500 h) ohjelmisto, joka täyttää vaatimusmäärittelydokumentissa sille asetetut vaatimukset, ja on asiakkaalle hyödyllinen ja käyttökelpoinen. Tavoite on toteutunut työmäärän ja ohjelmiston ominaisuuksien osalta. Ohjelmiston hyödyllisyys ja lopullinen käyttökelpoisuus selviää vasta, jos järjestelmä otetaan käyttöön. 4.2.2. Tuottaa sellaiset dokumentit, joita asiakas voi käyttää mallina myöhemmissä projekteissaan. Tavoite on toteutunut, sillä asiakas on jo käyttänyt dokumentteja malleina muissa omissa projekteissaan. 4.2.3. Suorittaa kurssi hyvällä arvosanalla. (Arvosana 4 tai 5) Tämän tavoitteen toteutuminen selviää, kun kurssin arvostelu julkaistaan. Toistaiseksi näyttää siltä, että tavoite on mahdollista saavuttaa. 5. Työtavat ja työkalut 5.1. Työtavat Projektin aikana käytettiin seuraavissa kappaleissa lueteltuja työtapoja ja -menetelmiä. Kukin ryhmän jäsen tutki lisäksi tarkemmin yhden menetelmän käyttöä. 12 (22)
5.1.1. Iteratiivinen kehitys ja suunnittelu Projektissa käytettiin kevyttä sekä modernia iteratiivista kehitysmallia. Iteratiivisessa mallissa projekti jaksotetaan useampaan vaiheeseen. Tämä projekti toteutettiin viidessä; vaiheessa jotka ovat suunnittelu, toteutus 1, 2 ja 3 sekä jakelu. Jaoimme toteutettavat ominaisuudet kahteen osaan toteutettavaksi kahdessa ensimmäisessä toteutusvaiheessa. Viimeisen toteutusvaiheen käytimme testaamiseen ja asiakkaalta saadun palautteen mukaan muutosten tekemiseen. Iteratiivisesta mallista olisi ehkäpä saanut vieläkin enemmän hyötyä, jos olisimme pitäneet aktiivisempaa yhteyttä sovelluksen tuleviin käyttäjiin koko projektin ajan. 5.1.2. Riskienhallinta Projektin onnistumista uhkaavia riskejä seurattiin säännöllisesti kirjaamalla riskitapahtumat, vaikutukset ja ehkäisevät toimenpiteet. Ajantasainen taulukko havaituista riskeistä on erillisessä riskienhallintadokumentissa. Riskien tiedostamisesta oli hyötyä, sillä projektin lopussa toteutui kaksi riskiä, joihin olimme kuitenkin osanneet varautua ajoissa. 5.1.3. Tunti- ja muu raportointi, projektinhallinta OtaShop2-projektissa käytettiin kurssin tuntiraportointijärjestelmää, Trapoli:a. Jokainen ryhmän jäsen raportoi tuntinsa järjestelmään vähintään muutaman kerran viikossa. Projektin etenemisen seurannassa käytettiin kahta toisiaan täydentävää menetelmää, tuntikirjanpitoa ja jäljellä olevan työmäärän arviointia. Tuntikirjanpitoon ja työmäärän arviointiin käytettiin Trapoli-järjestelmää. Työmääräarvioiden perusteella piirrettiin säännöllisesti ns. burndown-kaavioita, joiden avulla voi helposti tarkkailla projektin kunkin vaiheen etenemistä. Lisäksi projektin loppuvaiheesa edistymistä seurattiin löydettyjen ja avointen bugien perusteella. Projektinhallinta vaatii avukseen hyviä työkaluja aivan kuten muutkin ohjelmointitehtävät. Paremmilla työkaluilla projektinhallinnan rutiineihin menevää aikaa olisi varmasti voinut vielä vähentää. 5.1.4. Vikojen hallinta Ohjelmatyö-kurssi tarjoaa projektien bugien ja vikojen hallintaan Bugzilla-työkalua. Koska Bugzilla on osoittautunut toimivaksi järjestelmäksi isoissa projekteissa, päätimme että käytämme kurssin tarjoamaa järjestelmää omassa projektissamme. Bugzillan käytössä ei ollut erityisiä ongelmia, mutta esimerkiksi sen automaattisesti lähettämät sähköposteja ei juurikaan hyödynnetty, vaan kommunikointi hoidettiin manuaalisesti. 5.1.5. Dokumentointi ja dokumenttien jakelu Projektin aikana dokumenttien avulla pyritään kommunikoimaan sekä ryhmän sisällä että asiakkaan suuntaan. Dokumentit toimivat myös pöytäkirjana siitä miksi jotain päätöksiä on tehty tietyllä tavalla. Kurssin puolesta on jo tarjottu dokumenttipohjat joita käytetään pääosaan dokumentoinnista. Dokumenttien hallinta onnistui ilman suurempia sekaannuksia, mutta toisinaan dokumenttien muuttaminen muodosta toiseen aiheutti turhaa työtä. 5.1.6. Projektin katselmointitilaisuudet Jokaisen vaiheen lopussa pidettiin katselmointitilaisuus, jossa projektin eteneminen raportoitiin sekä asiakkaalle että kurssihenkilökunnalle. Tilaisuudet olivat hyödyllisiä, 13 (22)
mutta ehkäpä ne voisivat kestää hieman enemmän kuin 45 minuuttia, jolloin myös kysymyksille/keskustelulle jäisi aikaa. 5.1.7. Vaatimusten priorisointi OtaShop2-järjestelmän ominaisuudet pyrittiin priorisoimaan, ja toteuttamaan tärkeimmät ominaisuudet ensin. Käytännössä järjestelmän "ylimääräisten" raporttien toteuttaminen oli ainut suurempi kokonaisuus, joka jätettiin toteuttamatta. 5.1.8. Vaatimusten hallinta Asiakkaan kanssa määritellyt järjestelmän vaatimukset kirjattiin vaatimusmäärittelydokumenttiin, ja kunkin vaatimuksen toteutumista seurattiin jokaisessa vaiheessa. Luotimme ehkä hieman liikaa iteratiiviseen prosessiin, emmekä selvittäneet kaikkia vaatimuksia yksityiskohtaisesti projektin alussa. Iteratiivista prosessia käytettäessä pitäisi kuitenkin muistaa, että jos määrittelyjen siirtämisellä myöhempään ajanhetkeen ei voiteta mitään, olisi ehkä kuitenkin parempi miettiä vaatimukset kerralla valmiiksi. 5.1.9. Käyttötapaukset Käyttötapauksia käytettiin vaatimusten määrittelyn apuna. Jotta vaatimusten hahmottaminen on helpompaa, kuvattiin käyttötapaukset melko korkealla tasolla. Järjestelmän muut toiminnalliset vaatimukset kirjattiin erikseen. 5.1.10. Versionhallinta Versionhallinnan tavoitteena on hallita dokumentteja ja ennen kaikkea lähdekoodia, siten että koodi pysyy luettavan ja toimivana. Tästä syystä kaikki tuottamamme materiaali, kokousmuistioista lähdekoodin asti tallennettiin CVS-puuhun. Versionhallintatyökalu jota käytämme on avoimen lähdekoodin CVS, joka tulee lähdes jokaisen Linux-distribuution mukana. CVS-puu sijaitsee kehitys-palvelimella ja siihen on pääsy vain ryhmän jäsenillä. CVS:n käytössä ei ollut suuria ongelmia, ja se oli ehdottomasti välttämätön työkalu. 5.1.11. Testaus Teimme projektin aikana jatkuvasti yksikkötestausta, sekä eri moduulien valmistuttua integrointitestausta. Lisäksi teimme joulukuussa käytettävyysarvioinnin, josta saimmekin erittäin paljon hyödyllistä palautetta. 5.1.12. Vertaistestaus Projektin kolmannessa iteraatiossa suoritettu vertaistestaus oli avartava lisätehtävä kurssin puolesta. Vahinko vaan, että kaikki ryhmän jäsenet eivät päässeet kokeilemaan vieraan, kehitteillä olevan, sovelluksen testaamista. Täytyy kuitenkin todeta, että mielenkiintoisuudestaan huolimatta vertaistestauksen tekeminen oli kuitenkin vain pinnan raapaisemista. Kurssin puitteissa dokumentaatioon tutustumiseen ja kolmeen testausistuntoon varattu aika ei päätä huimannut. Tästä huolimatta uskon, että pystyimme antamaan vertaisryhmällemme jotain. Ainakin jos mittarina käyttää löytämiemme bugien määrää. Otashop2 -projekti hyötyi vertaistestauksesta muutamalla osa-alueella. Erityisesti pyytämäämme käytettävyystestiin saimme erittäin asiantuntevaa palautetta. Tämä siitä syystä, että vertaisryhmässämme sattui olemaan asiaa opiskelleita henkilöitä. Toisaalta 14 (22)
ylläpitoliittymän tekniseen testaukseen emme saaneet niin kattavaa palautetta, kuin olisimme toivoneet. Tämä johtui käytännössä siitä, että vertaisryhmällämme ei ollut paljoa kokemusta web-pohjaisista sovelluksista. Vaikka vertaistestausta ehditäänkin kurssin tuntibudjetin takia tekemään vain rajoitetusti, on se silti hyvä osa kurssia ja kannattaa pitää mukana tulevaisuudessakin. 5.1.13. Suunnittelumallit Verkkokaupan suunnittelussa sekä toteutuksessa käytettiin yleisesti hyväksi havaittuja ohjelmiston suunnittelumalleja. Nämä parantavat oikein käytettynä ohjelman laatua tekemällä siitä helpommin laajennettavan sekä vähemmän virhealttiin. Käytetyt mallit on tarkemmin esitelty Matti Kosusen henkilökohtaisen harjoituksen dokumenteissa. Suunnittelumallien käyttö mahdollisti projektin loppupuolella tulleiden muutosten toteuttamisen järjellisessä ajassa hajottamatta jo toimivaa järjestelmää. 5.1.14. Refaktorointi Refaktorointimenetelmää käytettiin kaikissa projektin implementaatiovaiheissa koodin laadun parantamiseksi. Refaktorointi tehtiin pienissä osissa siten, että pääsääntöisesti kukin kehittäjä refaktoroi omaa koodiaan. 5.2. Henkilökohtaiset ohjelmistotuotannon tehtävät Seuraavissa taulukossa on kerrottu kunkin ryhmän jäsenen henkilökohtaisen ohjelmistotuotannon tehtävän aihe. Table 5: Henkilökohtaiset ohjelmistotuotannon tehtävät Käytäntö Vastuussa oleva jäsen Käyttö Projektin etenemisen seuranta ja hallinta Erkka Halme PP-DE Käytettävyystestit Anna Larmo I2-I3 Konfiguraation hallinta Antti Kärkkäinen PP-DE Dokumentointikäytännöt Kai Inkinen PP-DE Automaatio järjestelmätestauksessa Karri Karanko I2-I3 Suunnittelumallit Matti Kosunen PP-I3 Refaktorointi Simo Ojanen I1-I3 Henkilökohtaiset harjoitukset esitellään ja raportoidaan tarkemmin erillisissä dokumenteissa. 5.3. Työkalut Projektissa käytetyt työkalut on lueteltu alla: Eclipse - Ohjelmointiympäristö jedit - Java-ohjelmointiin tehty editori Microsoft Visio - Kaavioiden piirtämiseen html2ps ja ps2pdf - Dokumenttien muuntamiseksi pdfmuotoon(http://user.it.uu.se/~jan/html2ps.html, http://stat.tamu.edu/doc/gs/ps2pdf.htm) 15 (22)
CVS - versionhallintaan(http://www.cvshome.org/) junit - yksikkötestaamiseen(http://www.junit.org) httpunit - järjestelmätestaamiseen(http://httpunit.sourceforge.net/) Maven - käännöstyökalu(http://maven.apache.org/) Microsoft Office 2003 - dokumenttien kirjoittamiseen Työkalujen kanssa ei ollut suuria ongelmia. Eri kehittäjillä olevat hieman erilaiset ympäristöt, sekä se että välillä työskenneltiin koulussa ja välillä kotona, aiheutti toisinaan hieman turhaa työtä. Pääasiassa kyse oli kuitenkin työkalujen käytön opettelusta, mikä on tietysti välttämätöntä, jos työkaluja haluaa käyttää. Dokumentoinnissa käytettävät työkalut vaihtuivat myös jonkin verran kurssin aikana, kun projektipäällikkö päätti ryhtyä tekemään osaa dokumenteista MS Wordilla HTML:n sijasta. CVS:ssä pidettävät HTML-dokumentit olivat parempi ratkaisu silloin, kun usean ihmisen piti samaan aikaan muokata dokumenttia, mutta muuten Word tuntui käytännöllisemmältä. 6. Opetuksellinen arvo 6.1. Arvioijana Erkka Halme Tavoitteenani olivat projektinhallintataitojen oppiminen, ohjelmistoprojektin kokonaisuuden ymmärtäminen ja asiantuntijoiden johtamisen oppiminen. Projektinhallintataitojen osalta kurssilla tuli paljon harjoitusta. Kevään aikana huomasin, että olisi ollut kovin hyvä, jos "Projektien suunnittelu ja ohjaus" sekä "Ohjelmistoprojektin hallinta" olisivat olleet suoritettuina ennen kurssia, niin olisi päässyt kokeilemaan niiden oppeja käytännössä. Nyt toiminta oli enemmän kantapään kautta oppimista, mutta ihan mukavaa sellaista. Kurssi antoi myös hyvää kokemusta "oikeiden" asiakkaiden kanssa toimimisesta, ja ryhmämme tapauksessa mielenkiintoa lisäsi se, että asiakas ei henkilöitynyt vain yhteen ihmiseen, vaan saimme asioida monien ihmisten kanssa ja huomioida erilaisten käyttäjien ja asianosaisten erilaiset tarpeet. Kurssin aikana sai nähdä yhden melkein kokonaisen ohjelmistoprojektin. Tosin meidän tapauksessa projektin kannalta suuri työ on vielä tekemättä, kun suurelle käyttäjämäärälle tarkoitettua järjestelmää ei ole vielä jalkautettu tuotantoon. Projektipäällikkönä oli erittäin mukavaa saada työskennellä jo työelämässä kokeneiden ohjelmistokehittäjien kanssa. Meillä kuten varmasti monessa muussakin ryhmässä, projektipäälliköllä oli huomattavasti vähemmän kokemusta projektinhallinnasta kuin ryhmän muilla jäsenillä omien alojensa tehtävistä. Toisaalta kehittäjien kannaltakin on varmasti ihan hyödyllistä tottua toimimaan esimiehen kanssa, jota saa jatkuvasti neuvoa ja opastaa. Projektipäällikkönä oli jännittävää havaita, kuinka paljon aikaa kului pelkästään projektin seurannan ja hallinnan tehtäviin. Kertaakaan ei tullut oloa, että olisi voinut vain istua alas ja katsella kuin muut tekevät töitä. Toisaalta toisinaan tuli kyllä mieleen, että hienojen taulukoiden ja käyrien piirtelyyn saattaa helposti innostua liikaa, ja ehkäpä unohtaa jotain projektin kannalta tärkeämpiä tehtäviä. 16 (22)
6.2. Arvioijana Kai Inkinen Kurssin pääasiallisena tavoitteena minulla oli toimiminen isommassa ryhmässä, isomman projektin puitteissa. Tätä on saatu harjoitella ja olen jopa hieman yllättynyt siitä miten paljon erilaisia tilanteita ja tehtäviä projektiin lopulta kuului. Toteutettava järjestelmä vaikutti syksyllä melko yksinkertaiselta toteuttaa, ja oletin että homma hoituu pitkälti omalla painollaan. Kuitenkin jo ensimmäisessä vaiheessa sain huomata, että 7 henkilön ryhmässä toimiminen eroaa merkittävästi pienemmistä ryhmistä joissa olen toiminut. Eniten minua yllätti se määrä tunteja joita tarvittiin projektin eteenpäin viemiseen, eli tunteja joita ei normaalisti katsottaisi "tuottavina" koodirivien tuottamisen suhteen. Tätä tavoitetta voin omalta osaltani pitää onnistuneena, sillä ryhmätyötä on tullut harjoiteltua ja olen myös kokenut oppineeni tästä jotain. Toisena tavoitteena kurssille olin asettanut tietoturvan soveltaminen ohjelmistoprojektissa. Tätä tavoitetta en ollut määritellyt sen tarkemmin, koska en vielä ensimmäisessä vaiheessa osannut arvioida projektin laajuutta tai lopputuotetta tarkemmin. Voin todeta että myös tämä tavoite on omalta osaltani täyttynyt, sillä myös kyseinen aihe oli esillä kurssin aikana. Sain huomata että koulussa opittu teoriaa on melko hankalaa soveltaa sellaisenaan tällaiseen aiheeseen. Olen lukenut melko paljon kryptologiaan liittyviä kursseja, mutta menetelmien toteuttaminen käytännössä on huomattavan paljon vaikeampaa. Usein sain huomata että jokin asia oli jäänyt huomiotta ja tämän joutuin korjaamaan myöhemmin. Kurssin aikana sain paremman kuvan tietoturvan soveltamisesta, mutta nyt ymmärrän että aihe on liian monimutkainen ja laaja jota sitä voisi oppia yhden tai kahden ohjelmistoprojektin aikana, vaan osaajaksi tulee vasta vuosien kokemuksen myötä. Kolmas tavoitteeni liittyi henkilökohtaiseen harjoitukseeni, eli dokumentointikäytäntöihin. Aiheen sisältä valitsin dokumenttien tarkastamisen tarkemmaksi tutkimuskohteeksi. Aihe kiinnosti minua, koska koen että dokumentointi koetaan monissa projekteissa välttämättömänä pahana, joka ei ole kovinkaan haastavaa. Menetelmää sovellettiin tekniseen dokumenttiin, jota pyrittiin jokaisen vaiheen lopussa tarkastamaan pienryhmässä. Yllätyksekseni havaitsin että dokumenttiin ehti vaiheen sisällä hiipimään runsaasti virheitä, jotka monesti johtuivat väärinkäsityksistä. Yleensä nämä väärinkäsitykset johtuivat kommunikaation puutteesta. En kuitenkaan koe että olisin projektin puitteissa oppinut mitään merkittävää aiheesta, joten tämä tavoite on minun osaltani epäonnistunut. Uskon kuitenkin että tarkastettujen dokumenttien laatu on kohentunut huomattavasti, menetelmän käytön ansiota. Kurssin yleisistä työtavoista voin todeta sen verran että useimmat olivat opettavaisia, kuten esim. tuntiraportoinnin tekeminen. Olen tehnyt vastaavaa raportointia töissä jo pidemmän aikaa, mutta tilanne eroaa silti merkittävästi koulutöistä. Koen että olen töissä paljon järjestelmällisempi, kuin mitä olen koulussa. Tästä johtuen tuntiraportoinnin tekeminen sekä tuntimäärien arviointi olivat osaltani vaikeita. Tuntiraporttini heittävät varmasti jonkin verran todellisesta työmäärästä, sillä tarkemman valvonnan puuttuessa raportointi meinasi välillä unohtua. Tuntimäärien arviointi oli minusta vaikeaa, sillä työnteko ajoittuu niin eri aikoihin ja mielentiloihin. Välillä yksinkertaisen tehtävän tekemiseen kului paljonkin aikaa, kun taas toisaalta välillä vaikeammat hommatkin hoituivat hetkessä. Tämä menee varmasti hyvin pitkälle sen piikkiin, että töissä vastaaviin tehtäviin on aikaa keskittyä ihan eri tavalla, kuin jos tekee koulutöitä kotona. Tällöin arki painaa päälle aivan eri tavalla, kuin rauhoitetussa työympäristössä. 6.3. Arvioijana Karri Karanko 17 (22)
Tärkein asia, joka kurssista jäi käteen, oli käytännön kokemus varsin tarkkaan määritellyssä ohjelmistoprojektissa toimimisesta. Ryhmämme koostui hyvistä tyypeistä ja ohjelmistotekniikan eri osa-alueiden asiantuntijoista, minkä takia saimme osavastuut jaettua varsin sujuvasti. Emme tunteneet toisiamme entuudestaan hyvin, joten projektin alkuvaiheessa jouduimme myös sosiaalisen haasteen eteen. Ryhmäläisten taidot, mieltymykset ja toimintamallit yms. on syytä tuntea, kun halutaan saada porukka toimimaan tehokkaasti. Olin kirjannut yhdeksi tavoitteekseni toimia yli kolmihenkisen ryhmän jäsenenä. Tavoite tuli saavutettua, mutta sen sisältö ei ollut aivan sitä mitä odotin. Tämä siitä syystä, että ryhmä oli harvoin tekemässä mitään kokonaisuudessaan. Osavastuut oli jaettu ja työtä tehtiin mm. parityönä ja etäyhteyksien päästä. Seitsemän ihmistä loi projektin puitteissa ohjelmistokokonaisuuden mutta olisin kaivannut lisää vuorovaikutusta yksilöiden välille. En kokenut kehittyneeni omassa ajankäytössäni projektin aikana, vaikka tämän olinkin kirjannut tavoitteeksi. Se mitä kuitenkin tein oli tuntien kirjaaminen raportointijärjestelmään. Testausautomaatioon tutustuminen ja sen soveltaminen käytännössä oli henkilökohtaisen harjoitukseni tavoite. Tämä oli minulle täysin uusi aihe ja olin siitä myös hyvin kiinnostunut. Käytännössä tutustuin vapaassa jakelussa oleviin työkaluihin, mutta käytäntö osoitti kaupallisten vaihtoehtojen olevan monta askelta edellä tällä osa-alueella. Päällimmäisenä asiana pidän kuitenkin sen ymmärtämistä, että automaation rakentaminen voimakkaasti kehittyvään järjestelmään on ajan tuhlaamista. Automaatiota kannattaa rakentaa siinä vaiheessa, kun järjestelmä on järkevällä tavalla stabiili. Yksi mielenkiintoisimmista asioista projektissa oli autenttisen ja ei teknisen asiakkaan kohtaaminen. Koulun kursseilla on paljon puhuttu asiakkaan huomioimisen merkityksestä ohjelmistoprojekteissa. Oli erittäin opettavaista olla tekemässä järjestelmää asiakkaalle, joka ei kovinkaan yksityiskohtaisella tasolla tiennyt millaisen kokonaisuuden he tarvitsisivat. 6.4. Arvioijana Matti Kosunen Sain huomattavasti paremman kuvan suunnittelumalleista ja niiden käytöstä kurssilla. Suunnittelumallit olivat minun henkilökohtaisena harjoituksena sekä arkkitehtuurin suunnittelijana myös minun vastuulla ottaa käyttöön. Suunnittelumallien hyödyt tulivat selvästi esiin isommassa projektissa jonka tuote muuttuu nopeaan tahtiin. Näin pystyttiin etukäteen ennakoimaan ja reagoimaan nopeasti muutoksiin joita tuli useaan eri osaan kaupassa sekä ylläpidon puolella. Suurin ongelma suurissa ohjelmistoprojekteissa on selvästi epäselvät/puutteelliset määritelmät sekä asiakkaan toiveet. Näitä ongelmia oli selvästi havaittavissa myös meidän projektissa sillä osa halutuista toiminnallisuuksista voitiin toteuttaa vasta hyvin myöhäisessä vaiheessa, koska tarkkoja tietoja halutusta toiminnasta ei ollut. Samaten tarvittavan dokumentaation saaminen oli välillä vaikeaa. Projekti on antanut jonkin verran tietoa myös projektien suunnittelemisesta sekä sen seuraamisesta noin yleisellä tasolla. Mitään kovin mullistavaa en kuitenkaan projektisuunnittelusta saanut. Tämä johtuu epäilemättä siitä että olin pääasiassa teknisenä henkilönä projektissa ja jätin muut asiat toisille. Kurssi myös opettaa hyvin työmaailman työtapoja: dokumentteja, dokumentteja ja lisää dokumentteja. Näitä syntyikin kurssin aikana kiitettävä määrä. Harjoitus oli ihan hyvä 18 (22)
opettamaan varsinkin vähemmän työelämässä olevia tulevasta. Itse olen ollut alalla töissä jo pitemmän aikaa ja kurssin sisältö ei tullut mitenkään yllätyksenä. 6.5. Arvioijana Antti Kärkkäinen Ensimmäiseksi tavoitteekseni olin kirjannut saada näkökulma toimimiseen kiireettömässä ja oikeaoppisesti jaetussa projektissa verrattuna normaaleihin työelämässä vastaantuleviin ylioptimistisilla budjeteilla ja aikatauluilla laadittuihin. Tavoite täyttyi kurssin aikana vaikka työolosuhteiden pakosta jouduinkin kurssillakin samantyyppisiin aikataulutusongelmiin kuten työelämässä tavallisestikin. Toisena tavoitteenani oli uusien ratkaisujen löytäminen ongelmiin ohjelmistoprojekteissa. Vaikka projekti antoi uuden näkökulman tapaan vetää läpi projekteja, en voi väittää oppineeni mitään oikotietä onneen. Joitain menetelmiä tulen varmasti käyttämään jatkossakin, mutta kyse on lähinnä pienistä yksityiskohdista. Tämä tavoite jäi siis osaltaan saavuttamatta. Viimeisenä oli uusien työkalujen kokeileminen ja ajatuksena tässä oli lähinnä tutustua Eclipse IDEn käyttöön java:n kanssa. Tavoite täyttyi yli odotusten. Nykyään käytän osittain myös töissä Eclipseä lähinnä siihen löytyvien lisäosien vuoksi. Myös Maven oli tuotantokäytössä uusi tuttavuus ja aivan tervetullut ohjelmisto sekin. 6.6. Arvioijana Anna Larmo Projektin alussa määrittelemäni oppimistavoitteet olivat: toimiminen projektin osana ja projektiryhmän osana, uusien työkalujen ja -käytäntöjen oppiminen, oman ajankäytön arvioinnin oppiminen sekä henkilökohtaisen tehtävän (Usability tests) soveltaminen käytännössä. Tärkeimmät oppimani asiat kurssin aikana olivat isommassa projektiryhmässä työskentelyn säännöt ja tavat. Erityisesti lähdin hakemaan kokemusta ohjelmistoprojektista, mutta loppupeleissä voin todeta saaneeni rautaisannoksen kokemusta tietotekniikan alan ihmisten kanssa työskentelystä ja siihen liittyvistä kirjoittamattomista sekä kirjoitetuista säännöistä, tavoista ja käyttäytymisestä. Uusista työkaluista hyödyllisin oli ehdottomasti cvs:n käytön oppiminen. Opin myös tunneloimaan ssh-yhteyden, joka myös on todella tarpeellinen taito. Ohjelmoinnista sinänsä en juurikaan oppinut uutta, en ollut tosin ennen tehnyt jsp-sivuja joita pääsin nyt tekemään muutaman projektin alussa. Muista työkaluista mainittakoon vielä tuntiraportointi ja bugzilla, jotka vaikuttivat ihan hyviltä työtavoilta. Omaa ajankäyttöä en oikeastaan oppinut arvioimaan yhtään paremmin. Toimin edelleen sillä periaatteella, että kunhan homma on hoidettu, ei jäljellä olevilla tunneilla ole niin väliä. Oma henkilökohtainen harjoitukseni oli mielenkiintoinen toteuttaa. Sitä toteuttaessani opin aimo annoksen siitä, miten käytettävyystestiin kannattaa valmistautua, ja erityisesti siitä, miten tulosten analysointi kannattaa tehdä. Lopuksi voidaan todeta, että olen huomannut kuinka tietotekniikka alan projektiluontoinen työskentely vaatii ryhmältä vielä tavallista parempia kommunikaatio taitoja onnistuakseen. Myös projektin johto on avainasemassa, sekä prosessin noudattamisen, että aikataulussa pysymisen suhteen. On hyvin paljon projektin johdosta kiinni, kuinka hyvin 19 (22)
projektiryhmän jäsenillä pysyy mielenkiinto yllä meneillään olevaa projektia kohtaa ja että aikataulussa oikeasti pysytään. 6.7. Arvioijana Simo Ojanen Tavoitteinani projektin alussa mainitsin kokemuksen saamisen aiempia isommassa projektiryhmässä toimimisesta, tietokannan ylläpidosta sekä oppikirjojen mukaan toteutetussa ohjelmistoprojektissa toimimisesta. Näistä tavoitteista ensin mainittu osoittautui kurssin aikana merkittävimmäksi, sillä kaikki aiemmat projektityökokemukseni sekä työelämästä että opiskeluajalta olivat pienissä, n. kolmen hengen ryhmissä tehdyistä töistä. Seitsemän hengen ryhmässä ryhmän sisäinen kommunikaatio, yhteisen ajan löytäminen sekä tehtävien tasapuolinen jakaminen osoittautuivat olettamaani vaikeammiksi tehtäviksi. Opin myös uusia asioita projektin hallinnasta, tällaisessa projektissa projektipäällikön toiminnan seuraaminen sivusta on varmasti lähes yhtä opettavaista kuin itse projektipäällikkönä toimiminen. Tekniset tavoitteeni kurssille olin asettanut tietokannan ylläpitotaitojen kehittämiseen. Käytännössä kuitenkin melko suuri osa kannan ylläpidosta siirtyi projektin palvelinkoneen ylläpitäjälle käytännön syistä. Vaikka projekti pyrittiin toteuttamaan oppikirjamallien mukaan, en havainnut tämän projektin etenemisessä merkittäviä eroja projekteihin, joihin olin aiemmin osallistunut. Käytetyt menetelmät ja järjestelyt tuntuivat toimivilta, ja projekti eteni erittäin hyvin suunnitelmien mukaan. Varmasti projekti olisi ollut erittäin opettavainen myös ohjelmistoprosessitekniseltä kannalta henkilölle, jolla ei ole paljoa kokemusta työmaailman projekteista. Ehkä eniten tällä kurssilla opin henkilökohtaisesta harjoituksestani, joka oli refaktorointi. Refaktorointi on useille ohjelmoijille melko vaikea asia, ja sen suorittaminen kontrolloidusti ja itse dokumentoiden on vaativaa. Onkin lähes mahdotonta vaatia ohjelmoijia tekemään kontrolloitua ja dokumentoitua refaktorointia tämän kaltaisessa projektissa, jossa ohjelmoijan palkka tai muut etuudet eivät ole uhattuna menetelmän käyttämättäjättämisen seurauksena. Oli opettavaista pohtia miten refaktoroinnin kaltainen, jokaiselta ohjelmoijalta resursseja ja panostusta vaativa menetelmä saataisiin mahdollisimman tehokkaasti käyttöön vaatimatta kuitenkaan liikoja. 7. Kurssipalaute 7.1. Arvioijana Erkka Halme Muihin ryhmätyökursseihin verrattuna suurempi ryhmäkoko oli hyvä, koska näin projektipäällikölläkin oli riittävästi töitä. Juuri suuremmassa ryhmässä toimiminen oli varmasti kurssin parasta antia. Tietysti myös projektin pitkä kesto teki projektista omalla tavallaan mielenkiintoisen. Ajankäytön seuranta (Trapoli) oli toimiva, mutta projektipäällikön tarpeisiin liian suppea. Tietysti on hyvä, että kaikkien ryhmien ei tarvitse keksiä omaa ajanseurantajärjestelmää, mutta ainakin tiedon siirtäminen Trapoliin/Trapolista oli turhan hankalaa. Itse käytin aina seuraavan vaiheen suunnitelmien tekemiseen Exceliä, ja toisaalta vein säännöllisesti Trapolista tietoja Exceliin kaavioiden piirtoa yms. varten. Olisi erittäin hyödyllistä, jos Trapoliin saisi viedä "task list" -tiedot esim. jossakin tekstiformaatissa. 20 (22)
Toinen vaihtoehto helpottaa raportointia olisi miettiä, missä kaikkialla samaa tietoa tarvitaan. Ainakin meillä samat luvut kopioitiin hiukan eri muodoissa omaan Exceltaulukkoon, projektisuunnitelmaan, edistymisraportteihin ja Trapoliin. Henkilökohtaisten harjoitusten tekeminen oli välillä hiukan hukassa, ts. ei ollut esim. selvää mitä pitää palauttaa ja milloin. Kurssin kotisivuilla alkaa olla jo ohjeita niin paljon, että oikeiden ohjeiden löytäminen oli välillä hankalaa. Mentorilta saatu palaute kunkin vaiheen lopuksi oli riittävän tarkkaa, kehitystä viime vuoden kurssiin on ilmeisesti tässä tapahtunut. 7.2. Arvioijana Kai Inkinen Kurssin tavoitteet tuntuivat minusta hieman ristiriitaisilta. Vaikka työt tuli hoidettua, niin tuntien kertymistä seurattiin silti kurssin puolesta jopa liian tarkkaan. Ymmärrän että kyseessä on kurssi jossa harjoitellaan tuntien arvioimista, mutta nyt tuntui välillä että itse ohjelmistoprojekti on toissijainen, ja Trapoliin merkityt tunnit ovat pääasia. Opiskelijoiden, ja varmaan myös asiakkaiden kannalta pääasia on kuitenkin itse projektin lopputulos. Henkilökohtaiset harjoitukset olivat minusta hyvä idea. Tosin niiden "uskottavuutta" söi se että osa niistä olisi ilman tällaista myös itsestäänselvyyksiä. Esimerkiksi, kukaan tuskin voisi hallita tämän kokoista projektia ilman CVS:ää. Meillä ryhmän sisällä CVS ja muu ympäristön hallinta oli ensiluokkaista joten siitä ei ole valittamista. 7.3. Arvioijana Karri Karanko Yleisellä tasolla olen tyytyväinen kurssin järjestelyihin. Pieniä yksityiskohtia tulee mieleen mm. Trapolin kaatuilu, joka häiritsi toistuvasti iteraatioiden loppuvaiheen toiminta. Projektin alkuvaiheessa ei saisi olla liian kiire tekemään prototyyppejä asiakkaan ja mentorin ihmeteltäväksi. Tärkeämpänä täytyisi pitää kattavaa vaatimusmäärittelyä ja ohjelmistoarkkitehtuurin suunnittelua. 7.4. Arvioijana Matti Kosunen Suurin ongelma minusta oli löytää yhteistä aikaa. Jotkut taskit projektissa olisi hyvä tehdä ryhmässä. Ryhmä- ja parityöt parantavat oppimista ja yleensä myös lopputuotteen laatua. Siinä mielessä pienemmässä ryhmässä toteutetut projektit saattaisivat olla parempia. Tapaamiset noin yleensäkin kärsivät vähän samasta syystä. Ryhmän jokaiselle jäsenelle tarkoitettu henkilökohtainen harjoitus on mielestäni erittäin hyvä idea. Näin saadaan jokainen ryhmän jäsen keskittymään itse valitsemaansa aiheeseen ja oppimaan aihe perusteellisesti. Harjoituksesta tehtävä dokumentaatiokin oli sopivan pienimuotoista, jolloin se ei päässyt rasittamaan ollenkaan. Mentoroinnissa on ongelmana oikeastaan mentorin etäisyys projektista. Hän ei voi koskaan tietää projektin asioista tarpeeksi hyvin ja näin arvostella suorituksia parhaalla mahdollisella tavalla. Yksi mahdollisuus olisi tietenkin esimerkiksi joka toinen viikko tehtävä review, mutta tämä saattaisi helposti muodostua rasitteeksi. Mitään muuta ratkaisuehdotusta minulla ei tähän ongelmaan ole, valitettavasti. 7.5. Arvioijana Antti Kärkkäinen 21 (22)
Trapolista joutuu antamaan kielteistä palautetta, vaikka ymmärränkin yhtenäisen ohjelmiston olevan tarpeellinen. Lastentaudeista päästyään kyse voi olla ihan toimivasta järjestelmästä. Suunnitteluvaiheen aikataulua olisin entisestäänkin pidentänyt lähinnä asiakasrajapinnan hitauden vuoksi. Yhtenä mahdollisuutena olisi, ryhmän niin halutessa, aloittaa kurssi tai ainoastaan esivalmistelut huomattavasti aiemmin. Tilannetta auttaisi myös asiakkaan selkeä näkemys haluttavasta järjestelmästä. Yleisestikin kurssin aikataulutus ja tarkat eri vaiheiden vaatimukset vähentävät joustavuutta, mutta ovat tietenkin tarpeellisia tällaisissa kursseissa, että päästäisiin tavoitteisiin ilman useamman vuoden ikuisuusprojekteja. 7.6. Arvioijana Anna Larmo Työskentely kurssin vaatimien työkalujen kuten Trapolin ja Bugzillan kanssa oli ajoittain todella hankalaa, sillä ne tuntuivat olevan aina silloin jumissa kun niitä olisi halunnut käyttää. Eli jos jotain vaaditaan (kuten Trapolin käyttöä) olisi suotavaa, että järjestelmä toimisi. Mentorin arvosteluperusteet olisi hyvä olla tiedossa jo etukäteen, jotta voitaisiin hieman tietää, mitä projektilta halutaan mentorin kannalta. 7.7. Arvioijana Simo Ojanen Vaatimusmäärittelyvaihetta voisi mielestäni painottaa kurssilla entisestään. Suurimmat ongelmat projektin toteutuksessa johtuvat kuitenkin lähes aina huonosti tehdyistä suunnitelmista ja vaatimusmäärittelyistä, ja kurssin puitteissa ensimmäiselle iteraatiokierrokselle annettu aika tuntui selvästi liian lyhyeltä. Koska kurssilla asiakkaina (asiakkaiden edustajina) on henkilöitä, joiden aikataulu ei välttämättä anna mahdollisuutta riittävän useiden tapaamisten pitämiseen projektin alkuvaiheessa, saattaa projektiryhmän työ kärsiä myös ryhmän ulkopuolisista syistä. Ehkä olisi syytä olla erillinen vaatimusmäärittelyvaihe ennen varsinaista suunnitteluvaihetta? Tämä antaisi lisäaikaa toteuttavan järjestelmän kunnolliselle suunnittelulle ja parantaisi lopputuotteiden laatua, sekä antaisi projektiryhmille paremmat mahdollisuudet onnistumiseen. 22 (22)