Loppuraportti CoSCA-simulaattorin jatkokehitysprojekti TeamDC
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 4.1.2006 Elina Kontro Raportin runko 0.2 30.1.2006 Elina Kontro Runkoa täydennetty, johdantoon lisätty tekstiä 0.3 19.2.2006 Elina Kontro Lisäyksiä ja korjauksia alkukappaleisiin. 0.4 20.2.2006 Elina Kontro Työkäytäntöjä, projekti etenemisestä 0.5 22.2.2006 Elina Kontro Projektin etenemisestä 0.6 23.2.2006 Elina Kontro 0.7 24.2.2006 Elina Kontro Työkäytäntö ja -oppimiskokemustekstejä Wikistä, Iteraatioiden kuvausta, loppuarvio aloitettu Lisätty lähetettyjä arvioita opetuksen merkityksellisyydestä, jotain työkaluista, korjauksia 0.8 25.2.2006 Elina Kontro I2-iteraation etenemisestä, oppimisarvioita ja työkalukokemuksia lisätty 0.9 25.2.2006 Laura Lehtola Työkäytäntöjä, oppimistavoite, kirjoitus- ja asiasisällön tarkistukset ja korjaukset 1.0 26.2.2006 Vesa Haukkavaara Kirjoitusvirheiden korjailua, työkaluosion kirjoittaminen 1.1 26.2.2006 Elina Kontro Korjauksia ja lisäyksiä. 1.2 26.2.2006 Vesa Haukkavaara Koodin koko osuus. 1.3 26.2.2006 Santeri Saarinen Laatumetriikat 1.4 26.2.2006 Elina Kontro Täydennystä työtunnit ja laatumetriikat osioihin, asiakkan tavoitteiden saavuttaminen päivitetty 1
Sisällysluettelo 1 Johdanto 1 1.1 Projektin esittely 1 2 Projektin eteneminen 1 2.1 Projektin suunnitteluiteraatio (PP) 2 2.2 1. Toteutusiteraatio (I1) 2 2.3 2. Toteutusiteraatio (I2) 3 2.4 Projektin haasteet - yhteenveto 4 3 Projektin tulokset 6 3.1 Asiakkaan tavoitteiden toteutuminen 6 3.2 Projektiryhmän tavoitteiden toteutuminen 7 3.3 Toiminnalliset vaatimusten toteutuminen 9 3.4 Laadullisten tavoitteiden toteutuminen 10 4 Projektimetriikat 11 4.1 Työtunnit 11 4.2 Laatumetriikat 13 4.3 Koodin koko 14 5 Työkäytännöt ja työkalut 16 5.1 Työkäytännöt 16 5.2 Työkalut 24 6 Opetuksellinen merkitys 27 7 Kurssiarvio 30 8 Lähdeluettelo 31 1
1 Johdanto Tämä dokumentti on TeamDC -projektiryhmän loppuraportti Teknillisen korkeakoulun kurssilla T-76.4115 Ohjelmistoprojekti 1. Raportin tarkoitus on kuvata CoSCA -simulaattorin jatkokehitysprojektin etenemistä ja esittää loppuarvio projektista eri näkökulmista; asiakkaan ja projektin jäsenten tavoitteiden täyttymisen ja oppimisen sekä erilaisten metriikoiden kannalta. 1.1 Projektin esittely Tämän ohjelmistokehitysprojektin tarkoitus oli tuottaa olemassa olevaan CoSCA -simulaattoriin helposti opittava ja miellyttävä käyttöliittymä, jonka avulla oppijat pystyvät kokeilemaan, miten erityyppisten päätössääntöjen käyttäminen erilaisissa tilanteissa vaikuttaa töiden läpimenoon liittyviin tunnuslukuihin. Helsingin Kauppakorkeakoulussa (HKKK) kehitetyn CoSCA (Coordination of Supply Chain Activities) simulaattorin avulla on tarkoitus mallintaa tuotannonohjaukseen liittyviä päätöksiä ja hajautettua tuotannonohjausta. Ennen jatkokehitysprojektia simulaattorilla oli ollut yksi käyttäjä eikä siihen näin ollen ole kehitetty graafista käyttöliittymää. Projekti toteutettiin TeamDC- projektiryhmän toimesta T-76.4115 Ohjelmistoprojekti I-kurssin harjoitustyönä. Projektiryhmässä oli 7 henkilöä ja projektiin käytettiin kokonaisuudessaan 1301,5 tuntia. Työmääräarvio projektin alussa oli 1290 tuntia, joka ylitettiin vain 0,88 %. 2 Projektin eteneminen Ennen virallista projektin aloitusta alkoi management-tiimin muodostus kurssin uutisryhmän kautta. Management -tiimi tapasi ensimmäisen kerran ennen yritysten esittelyluentoa valiten muutaman mielenkiintoisimman aiheen, jotka voisivat olla potentiaalisia projektiaiheita. Luennon aikana päädyttiin yksimielisesti CoSCA -aiheeseen. Tapasimme asiakkaan heti ja sovimme jatkoyhteydenotosta sekä esittelykalvojen tekemisestä. Projektin katsotaan virallisesti alkaneen siitä, kun projektiryhmällä oli aihe sovittuna asiakkaan kanssa. Projekti koostui kolmesta iteraatiosta: projektisuunnittelu (PP), 1. toteutusiteraatio (I1) ja 2. toteutusiteraatio (I2). Seuraavissa kappaleissa kuvataan tarkemmin projektin etenemistä näissä vaiheissa sekä lopuksi yhteenvetona projektissa kohdattuja keskeisiä haasteita. Yleisesti ottaen voidaan todeta projektin edenneen hyvin ja suunnitelmien mukaisesti, joskin suunnitelmia muutettiin tai tarkennettiin projektin edetessä. 1
2.1 Projektin suunnitteluiteraatio (PP) Kurssin ohjeistuksen mukaan projektin suunnitteluvaihe toteutettiin kolmen hengen management tiimin voimin ja yksi ensimmäisen vaiheen tehtävistä olikin suunnittelijoiden rekrytointi. Ryhmä muodostettiin pieneltä osin vanhojen tuttavuuksien kautta, mutta enimmäkseen kurssin uutisryhmän avulla. Koko seitsemän henkinen projektiryhmä oli muodostettu 28.9. mennessä. Projektin ensimmäinen suunnittelutapaaminen pidettiin 30.9. 2005, ensin management tiimin kesken ja tämän jälkeen asiakkaan kanssa HKKK:lla. Tuolloin tutustuttiin mm. aihealueeseen, olemassa olevaan simulaattorin sekä käytiin läpi asiakkaan tavoitteita ja sovittiin projektiin liittyvistä käytännön asioista kuten dokumentoinnista ja sopimuksista. PP-iteraatiossa keskityttiin projektin suunnitteluun, vaatimusten selvittämiseen ja näiden dokumentointiin. Suunnittelua tehtiin viikoittaisissa management tiimin tapaamisessa. Tässä vaiheessa pidettiin myös hyvin tiivistä yhteyttä asiakkaaseen, jotta asiakkaan ja tulevan simulaattorin käyttäjien tarpeet saatiin kattavasti kartoitettua. Iteraation loppupuolella pidettiin kick-off palaveri suunnittelijoille ja aloitettiin töiden tekeminen koko projektiryhmällä jakautuen ns. pienryhmiin. Pienryhmissä keskityttiin käyttöliittymäprototyypin suunnitteluun ja toteutukseen, laatusuunnitelmaan ja arkkitehtuurisuunnitteluun. Pienryhmät olivat suhteellisen aikaa vievä tapa, mutta toisaalta välttämättömyys töiden käyntiin saamiseksi toisilleen pääasiassa vieraiden ihmisten kesken. Kommunikointi tapahtui aluksi lähinnä viikkopalavereissa ja sähköpostilla. Hieman hankaluuksia aiheutti se, ettei TikiWiki ollut kurssin puolesta käytettävissä heti kurssin alusta alkaen. TikiWiki otettiin käyttöön heti, kun se oli mahdollista ja se helpottikin monin tavoin esim. dokumentaation jakamista ja keskustelun käymistä muutoinkin kuin tapaamisten muodossa. Pääosin PP-iteraatio sujui suunnitelmien mukaisesti ja hyvin. Projektin suunnittelu ja vaatimusten määrittely saatiin tehtyä hyvin. Projektiryhmän ymmärrys olemassa olevan simulaattorin arkkitehtuurista sekä alustava näkemys toteutettavasta arkkitehtuurista olisi pitänyt olla iteraation lopussa parempi kuin mitä se oli. Tämä olisi selkeästi helpottanut seuraavan iteraation aloittamista. 2.2 1. Toteutusiteraatio (I1) I1-iteraation tavoitteista sovittiin asiakkaan kanssa PP -iteraation demon jälkeen pidetyssä palaverissa. Iteraation alussa pidettiin koko projektiryhmän WorkShop, jossa tarkoituksena oli tutustua aihealueeseen, olemassa olevaan simulaattorin rakenteeseen sekä jatkaa suunnittelutöitä niin, että itsenäinen työskentely olisi mahdollisimman pian mahdollista. Koska ryhmän yhtenä SEPA aiheena oli Coding Camp käytännön kokeileminen ja tutkiminen, järjestettiin iteraation alussa myös ensimmäinen Coding Camp, joka heti ensimmäisellä kerralla todettiin hyväksi ja ryhmälle sopivaksi toimintatavaksi. Tämän vuoksi käytännöstä tuli viikoittainen käytäntö. 2
Iteraatiossa toteutettiin ensimmäinen toimiva versio sovelluksesta alussa sovittujen vaatimusten mukaisesti. Lyhyesti voidaan todeta, että ensimmäisellä versiolla oli tarkoitus simuloida kolmea ennalta sovittua esimerkkisysteemiä, joiden simulointiin liittyviä parametreja voitiin muuttaa tiettyjen esimerkkien rajoissa. I1- iteraation tavoitteet saavutettiin erinomaisesti: kaikki sovitut vaatimukset saatiin toteutettua, vain pienin muutoksin. Tämä tarkoittaa käytännössä sitä, että jokin epärealistinen ominaisuus jätettiin pois ja joitakin I2- iteraation vaatimuksia päästiin jo toteuttamaan. Suurimpia haasteita I1-iteraation alussa oli saada riittävä ja oikea ymmärrys olemassa olevan simulaattorin arkkitehtuurista sekä suunnitella siihen järkevästi yhteensopiva arkkitehtuuri projektissa toteutettavien osien osalta. Arkkitehtuurin suunnittelu oli yksi keskeisimmistä projektin haasteista ja yksittäisenä tehtävänä siihen käytetty työmäärä oli huomattavan suuri ja enemmän kuin sen oletettiin olevan. Osaltaan arkkitehtuuriin kului paljon aikaa johtuen pääsuunnittelijan roolin vaihdoksesta, joka tehtiin iteraation alussa. Muutos edellytti tiedonsiirtoa henkilöiden välillä. I1-iteraation alussa oli myös haasteellista löytää riittävä ymmärrystaso aihealueesta, jonka kanssa oltiin tekemisissä. Se näkökulma, josta tuotannonohjaus -aihepiiriä tuli projektissamme tarkastella, oli meille suurimmaksi osaksi vieras. Haasteista johtuen iteraation alussa oli havaittavissa jonkin verran turhautumista projektin etenemisen suhteen kaikkien projektin jäsenten osalta. Vaikka tiesimme selvästi, että iteraation alussa tehdään suunnittelua ja perehdytään sekä aihealueeseen ja simulaattoriin olivathan suunnittelijat vasta hypänneet kelkkaan mukaan - oli kaikilla jo kova into päästä oikeisiin töihin eli koodaamaan. Kokonaisuutena iteraatio kuitenkin toteutui hienosti, asetetut tavoitteet saavutettiin ja mikä tärkeintä, asiakas oli tyytyväinen tuotoksiin. 2.3 2. Toteutusiteraatio (I2) Asiakkaan kanssa I2-iteraation suuntaviivoista sovittiin I1-iteraatio demon jälkeen pidetyssä palaverissa. Näiden suuntaviivojen pohjalta teimme ensimmäisen iteraatiosuunnitelman joululoman aikaista työskentelyä varten. Tuolloin sovimme, että suunnitelmaan merkittyjä tehtäviä saa tehdä joululomankin aikana, mikäli haluaa, mutta varsinaisesti joululoma ei kuulunut projektin aikataulutukseen. Käytännössä moni olikin matkoilla tai muutoin poissa koneiden äärestä, joten joululoman aikana projektitöitä tehtiin hyvin vähän. Tarkempi iteraatiosuunnittelu jatkui suunnitelman mukaisesti joululoman jälkeen sekä management-tiimin että asiakastapaamisen merkeissä. I2-iteraatio suunniteltiin toteutettavaksi vastaavissa sykleissä kuin I1-iteraatiossa oli hyväksi havaittu. Coding Camp (CC) käytäntöä päätettiin jatkaa, mutta sen alkuun lisättiin lyhyt palaveriosuus, jossa käytiin läpi kolme kysymystä kunkin suunnittelijan osalta: mitä olen tehnyt edellisen CC:n jälkeen, mitä ongelmia olen kohdannut ja mitä aion tehdä seuraavaan kertaan mennessä. Lisäksi iteraatiossa pyrittiin kiinnittämään huomiota järkevämpään sähköpostin käyttöön, jotta tieto tavoittaa ne henkilöt, joita pitääkin mutta ei tuki kaikkien sähköpostilaatikoita. Aivan iteraation loppua lukuun ottamatta tämä toimi hyvin. I1-iteraation lopulla pois jääneet viikoittaiset management-tiimin palaverit palautettiin lyhyiksi status palavereiksi. Käytännön palauttaminen oli kommunikoinnin ja työn seurannan kannalta hyvä ratkaisu 3
I2-iteraatiossa keskeisimmät vaatimuksiin tulleet muutokset olivat esimerkkityövirtojen poistuminen ja niiden korvaaminen parametreiltaan säädettävillä työvirroilla, esimerkkikustannusrakenteiden poistuminen ja niiden korvaaminen parametreiltaan säädettävillä kustannusrakenteilla sekä järjestelmän muokattavuus puun kautta. I2 -Iteraation ja samalla koko projektin lopussa kohtasimme kiireen, joka oli kyllä odotettavissa, mutta virheiden korjaamiseen sekä muuhun viimeistelyyn kului odotettua enemmän aikaa. Koimme kuitenkin tärkeäksi panostaa viimeistelyyn, halusimme reagoida projektin lopussa löytyneiden virheiden korjaamiseen sekä muuhun asiakkaalta saatuun palautteeseen mahdollisimman hyvin. Kaikki I2 Iteraatiosuunnitelmassa määritellyt tavoitteet, sisältäen asiakkaan kanssa sovitut vaatimukset, on saatu toteutettua, joten iteraation voidaan sanoa onnistuneen hyvin. 2.4 Projektin haasteet - yhteenveto Projektin keskeisimpiä haasteita olivat arkkitehtuurisuunnittelu, aihe-alueen ymmärtäminen sekä kommunikointi ikään kuin hajautetussa organisaatiossa. Arkkitehtuurin haasteellisuus johtui osin projektiryhmän osaamisesta projektin alussa, mutta suuremman haasteellisuuden suunnitteluun toi olemassa olevan simulaattorin arkkitehtuurin ymmärtäminen ja projektissa toteuttavan osuuden arkkitehtuurisuunnittelu siten, että se olisi olemassa olevan kanssa yhteensopiva. Arkkitehtuurisuunnittelu olisi saattanut olla meille helpompaa, jos se olisi voitu tehdä kokonaan puhtaalta pöydältä. Toisaalta olisimme voineet myös rohkeammin keskustella olemassa olevan arkkitehtuurin haasteellisuudesta teknisen ohjaajan kanssa projektin alussa. Arkkitehtuurin haasteellisuus heijastui alusta lähtien koko projektiin. Nyt voimme kuitenkin todeta, että tehdyt ratkaisut ovat olleet onnistuneita ja tästä haasteesta on suoriuduttu kunnialla. Aihe-alue, tuotannonohjaus kaikkine siihen liittyvine seikkoineen, oli projektinjäsenille tuttu vain etäältä, mutta vieras siltä näkökannalta, joka sovelluksen toteutuksen kannalta oli pääroolissa (päätössäännöt ja niiden vaikuttaminen eri tuotannonohjauksen tunnuslukuihin). Ideaalitilanne olisi ollut, että projektissa olisi ollut niin paljon aikaa käytettävissä, että meistä jokainen olisi voinut perehtyä aiheeseen syvällisesti. Haasteena oli löytää riittävä ymmärryksen taso, jotta työn tekeminen oli mahdollista käytettävissä olevilla resursseilla ja aikataululla. Myös tämä haaste on heijastunut projektiin koko ajan. Ensimmäisen toteutusiteraation aikana meidän oli lähes mahdotonta itse arvioida simulaattorin antamien tulosten oikeellisuutta, järkevyyttä tai sovelluksen hyötyä opiskelijoiden kannalta. Käytännössä päätimme, että yksi ryhmästämme eli pääsuunnittelija oman opiskelutaustansa vuoksi on henkilö, joka keskittyy aihealueen syvällisempään ymmärtämiseen. Loppua kohti tämä haaste on helpottanut jonkin verran meidän kaikkien osalta. Olemme erityisen tyytyväisiä, että asiakkaalla on ollut kaikista kiireistä huolimatta aikaa ja tahtoa antaa tukensa ja apunsa aihealueeseen liittyvän problematiikan kanssa koko projektin ajan. Kommunikointia ja sen selkeyden merkitystä ei voi korostaa liikaa. Projektiryhmämme voidaan katsoa olevan kuin hajautettu organisaatio erilaisia työaikoja myöten. Projektissa on siis kohdattu keskeisimmät hajautetun organisaation kommunikaatiohaasteet. Pyrimmekin selkeyttämään kommunikointikäytäntöjämme projektin aikana. Coding Camp-käytönnön ansiosta monien viestin perille saattaminen puolin ja toisin oli mahdollista ja 4
ongelmia saatiin usein korjattua välittömästi kooditasolta asti. Kommunikointi Coding Camp -tapaamisten välillä perustui paljon sähköpostiin ja puheluihin. I1-iteraatiossa käytimme myös TikiWikiä keskusteluun. TikiWIki olisimme voineet käyttää tehokkaammin koko projektissa mutta varsinkin I2-iteraatiossa. Esimerkiksi töiden etenemistä olisi voitu seurata TikiWikissä koko projektin ajan eikä vain loppurutistuksen osalta. Puhelimitse sovittuja tehtävien haasteena oli muistaa kirjata ne ylös, jotta sovitut asiat eivät jäisi vain muistinvaraisiksi. Edellä kuvatuista haasteista huolimatta olemme onnistuneet projektissa hyvin. Luonnollisesti aina on parannettavaa ja kehitettävää, tuskin on olemassa yhtään täydellistä projektia. Tämä projekti on täyttänyt paikkansa erinomaisena oppimismahdollisuutena monin tavoin, erityisesti kohdattujen haasteiden osalta. 5
3 Projektin tulokset Seuraavissa kappaleissa käydään läpi sekä asiakkaan että projektiryhmän projektin alussa projektille asettamat tavoitteet ja arviot niiden toteutumisesta. 3.1 Asiakkaan tavoitteiden toteutuminen Yhteenvetona voidaan todeta, että projektissa on saavutettu suurin osa asiakkaan projektille asettamista tavoitteista hyvin; asiakas on ollut joko tyytyväinen tai erittäin tyytyväinen tavoitteiden saavuttamiseksi tehtyjen ratkaisujen suhteen. Asiakkaan omien kommenttien mukaan, jotkin tavoitteista saattoivat olla jo alun alkaen liian haasteellisia ja näiden osalta tavoitteet voidaan todeta saavuttaneen osittain. Projektiryhmän kannalta aihealueen haasteellisuus osittain vaikutti ryhmän kykyyn arvioida asiakkaan ylätason tavoitteiden realistisuus suhteessa resursseihin. Iteraatiosuunnitteluissa keskityttiin toiminnallisista vaatimuksista sopimiseen. Tämän lisäksi olisimme voineet projektin aikana uudelleen arvioida myös näitä tavoitteita. Oheiseen taulukkoon on koostettu asiakkaan tavoitteet ja arvio onko tavoite saavutettu sekä kuinka tyytyväinen asiakas on tavoitteen saavuttamisen suhteen. Arviointiasteikkona on 1-erittäin tyytymätön, 2-tyytymätön, 3- menettelee, 4- tyytyväinen, 5- erittäin tyytyväinen. Taulukko 1: Asiakkaan tärkeimmät tavoitteet ja niiden toteutuminen Tavoite Hyväksyntäkriteeri Arvio 1. Kyetä käyttämään järjestelmää opetuksen apuvälineenä HKKK:n tilaustoimitus kurssilla sekä yritysyhteistyössä 1.1 Havainnollistaa tilaustoimitus -aihealueen pääkäsitteitä ja niiden välisiä suhteita 1.2 Havainnollistaa graafisesti päätössääntöjen ominaisuuksia ja kyvykkyyttä erilaisissa tilanteissa 1.3 Tarjota opiskelijoille mahdollisuus pelata toisiaan vastaan tilaus-toimitus päätösvalintojen tekemisessä 1.4 Tarjota opiskelijoille mahdollisuus itse kokeilla käytettyjen päätössääntöjen vaikutusta läpimenoaikoihin erilaisilla koeasetelmilla Kohtien 1.1-1.5 toteutuminen Järjestelmällä kykenee luomaan erilaisia testitilanteita (= systeemeitä) Käyttöliittymän avulla kykenee ajamaan läpi erilaisia testitilanteita, joiden tulokset järjestelmä esittää sekä numeerisessa että graafisessa muodossa. Käyttäjä voi nähdä käyttöliittymän avulla, miten hänen tekemänsä päätökset vaikuttavat tärkeimpiin tunnuslukuihin eri ajanhetkillä Järjestelmä on niin helppokäyttöinen ja intuitiivinen, että käyttäjän ei tarvitse olla aihealueen asiantuntija. Toteutunut osittain 4 Toteutunut 4 Toteutunut 4 Toteutunut osittain 3 Toteutunut 5 6
Tavoite Hyväksyntäkriteeri Arvio 1.5 Tarjota opiskelijalle mahdollisuus tarkastella simulaatioajon vaiheita graafisesti 2. Käyttää olemassa olevan CoSCA simulaattorin tärkeimpiä toiminnallisuuksia graafisen käyttöliittymän avulla 3. Järjestelmän jatkokehitettävyys 4. Erilaiset käyttäjäryhmät kykenevät helposti saamaan ja asentamaan ohjelman itselleen 5. Lisätä asiakkaan omaa ymmärrystä siitä, miten tilaus-toimitus -aihealueen asioita pitäisi opettaa Käyttöliittymässä on mahdollisuus tarkastella graafisesti käyttäjän käyttämien päätössääntöjen menestymistä ajan funktiona. Tutkija voi itse käyttää itselleen tärkeimmiksi nimeämiään simulaattorin ominaisuuksia nykyistä toimintatapaa helpommin. Koodi on modulaarista ja kommentoitu projektissa päätetyn käytännön mukaisesti. Järjestelmä on paketoitu ja siinä on käyttö- ja asennusohjeet. Järjestelmän voi kätevästi asentaa Windows XP käyttöjärjestelmään. Asiakas pystyy nimeämään vähintään kaksi oivallustaan siitä, miten aihealueen vaikeimmat asiat selitetään aihealuetta tuntemattomille yliopisto-opiskelijoille. Toteutunut 4 Toteutunut 4 Toteutunut 4 Toteutunut 5 Toteutunut 4 3.2 Projektiryhmän tavoitteiden toteutuminen Oheiseen taulukkoon on koostettu projektiryhmän yhteiset tavoitteet ja arviot niiden toteutumisesta. Taulukko 2: Projektiryhmän yhteiset tavoitteet ja niiden toteutuminen Tavoite Hyväksyntäkriteeri Arvio 1. Kurssin läpäiseminen 2. Saada aikaan asiakkaan tarpeita vastaava tuote 3. Saada käytännön kokemusta ohjelmistotuotteen toteuttamisesta iteratiivisesti ja inkrementaalisesti 4. Henkilökohtaiset oppimistavoitteet saavutetaan 5. Kurssista saadaan arvosana 5 Ryhmä saa kurssista hyväksytyn arvosanan Asiakas on tyytyväinen toteutettuun ja toimitettuun ohjelmistoon, ja kokee sen täyttävän sille asetetut vaatimukset. Projektin jälkeen jokainen ryhmän jäsen kokee tietävänsä enemmän ko. ohjelmistokehitysmenetelmästä kuin ennen projektin alkua ja pystyy mainitsemaan jonkin menetelmästä käytännön kautta oppimansa asian. Jokainen ryhmän jäsen kokee saavuttaneensa itselleen asettamansa oppimistavoitteet (luku 3.3) Ryhmän lopullinen arvosana kurssista on 5 26.2.06 tilannearvion mukaan tämä kriteeri täyttyy erittäin hyvin Asiakkaan hyväksyntätestissä antaman palautteen perusteella saavutettu kohtuullisen hyvin. Tavoite toteutunut hyvin Tavoite toteutunut hyvin 26.2 arvosanat eivät ole vielä tiedossa, joten tätä ei voi arvioida 7
Tavoite Hyväksyntäkriteeri Arvio 6. Saada onnistuneesta projektista maininta ansioluetteloihin 7. Oppia uusia ohjelmistotuotannon tekniikoita 8. Sujuva kommunikaatio asiakkaan kanssa 9. Projektiryhmän toimiva kommunikointi ja ryhmätyöskentely 10. Tavoitteet on asetettu oikein suhteessa käytettäviin resursseihin Projektiryhmä saa työstään positiivisen arvion sekä asiakkaalta että järjestävältä kurssilta ja voi tätä tunnustusta hyödyntää tulevissa työnhakutilanteissaan. Kukin projektiryhmän jäsen pystyy listaamaan 3 ohjelmistotuotannon tekniikkaa tai työkalua, joista kokee tietävänsä enemmän kuin ennen projektin alkua. Asiakas kokee saaneensa riittävästi tietoa projektin etenemisestä koko projektin ajan ja voineensa vaikuttaa siihen, mitä ominaisuuksia järjestelmään toteutetaan. Sovitut tehtävät hoidetaan sovittuihin päivämääriin mennessä ja työmäärä jakaantuu tasaisesti ryhmän kesken. Ryhmänjäsenet kokevat pysyvänsä riittävällä tarkkuudella ajan tasalla muiden ryhmäläisten tekemisistä. Projektin tavoitteet saavutetaan ylittämättä kurssin asettamaa työpanosta (150 h tai 190h/ henkilö). Tavoite toteutunut Toteutunut erityisesti työkalujen osalta. Useita projektissa käytettyjä työkaluja (useat apukirjastot, Borland Architect) ei oltu käytetty lainkaan tai vain vähän ennen projektia. Asiakkaan antaman palautteen perustella tavoite on toteutunut erittäin hyvin. Tavoitteen voidaan todeta toteutuneen kohtuullisen hyvin: Työt on tehty ja päällekkäisyydet vältetty. Pari kertaa epäselvästä kommunikoinnista johtuen jokin asia oli vähällä jäädä tekemättä. Tavoite saavutettiin kohtuullisen hyvin, sillä projektiin käytetyt tunnit ylittivät tavoitteen 0,88 % Projektiryhmä selviytyi projektista kaiken kaikkiaan erinomaisesti. Kiinnitimme erityistä huomiota loppukäyttäjien tarpeiden ymmärtämiseen ja näiden täyttämisen testaamiseen, mikä mielestäni osoittautui vaivan arvoiseksi. Ryhmämme koostui ihmisistä, joilla oli hyvin erilaisia vahvuuksia. Tämä aiheutti joissakin tilanteissa projektin alussa ehkä jopa sutimista paikallaan ja kommunikointivaikeuksia, mutta loppujen lopuksi tämä oli projektimme vahvuuksia. Ihmiset kiinnittivät huomiota ja kiinnostusta hyvin eritasoisiin asioihin, mikä lopulta johti siihen, että monen tasoiset haasteet tulivat lopulta ratkaistuiksi. Projektin varsinaisena tuloksena syntyi ensimmäinen versio simulaattorista, jota asiakas voi käyttää apuvälineenä HKKK:n kursseilla. Simulaattori ei vielä varsinaisesti ole sellainen pelattava peli sanan varsinaisessa merkityksessä, mistä asiakas ehkä pitkällä tähtäimellä haaveili, mutta se on erinomainen pohja jatkokehitykselle tähän suuntaan. 8
3.3 Toiminnalliset vaatimusten toteutuminen Järjestelmän toiminnallisten vaatimusten toteutuminen arvioitiin hyväksyntätestissä asiakkaan ja teknisen ohjaan toimesta. Ainostaan yhtä käyttötapasta (UC1.6 Simullaation poistamine järjestelmästä) ei voitu täysin testauksessa todentaa, mutta kaikki muut 25 käyttötapausta todettiin toteutetuiksi. Oheiseen taulukkon on koostettuna toiminnalliset vaatimusten käyttötapaukset ylätasolla. Asiakasta pyydettiin myös arvioimaan tyytyväisyyttä tehtyjen ratkaisujen suhteen ja alikohtien keskiarvot on ilmoitettu taulukossa. Lyheysti voidaan todeta, että ylätason käyttötapauksista asiakas on ollut joko tyytyväine tai erittäin tyytyväinen toteutukseen. Yksityiskohatisemmat tulokset ja kommentit on kirjattu hyväksyntätestin lokiin. Myös projektiryhmän oman arvion mukaan kaikki toiminnalliset vaatimukset on saatu toteutettua projektin aikana. Taulukko 3 Käyttätapaukset ID Nimi Tila Tyytyväisyys asteikolla 1-5 1=erittäin tyytymätön, 2=tyytymätön, 3=Menettelee 4=tyytyväinen 5= Erittäin tyytyväinen UC1 Systeemin määrittäminen Toteutettu 4,11 UC2 Työvirran määrittäminen Toteutettu 4 UC3 Kustannusrakenteen määrittäminen Toteutettu 5 UC5 Käytettävien päätössääntöjen valinta Toteutettu 5 UC6 Tulosten tarkastelu Toteutettu 4,5 UC7 Simulaation ajaminen Toteutettu 4,5 UC8 Simulaattorin asentaminen Toteutettu 5 9
3.4 Laadullisten tavoitteiden toteutuminen Projektin laadulliset tavoitttet voidaan kiteyttää kolmeen asiaan; käytettävyys, jatkokehitettävyys sekä virheettömyys. Virheetömyydellä tarkoitetaan tässä yhtydessä sitä, ettei ohjelmassa ole yhtään sellaista virhettä joka estäisi sovelluksen käytön. Ohjelman virheetöntä toimintaa on projektissa pyritti taklaamaan epäsuorasti sovituilla koodauskäytönnöillä ja koodin kommentoille sekä mittaamaan eritasoisten ja tyyppiset testin avulla. Testauksissa simulaatiosta löytyneet virheet on korjattu kahta lukuun ottamatta (kts. Laatumetriikat) eikä sovelluksessa ole avoinna yhtään sellaista virhettä, joka estäisi sen käytön. Tuotteen toiminnallisuutta on testattu eri tahojen toimesta ja erilaisia testityyppejä hyväksikäyttäen, eikä tuotteesta ole löytynyt viimeisissä testeissä uusia vakavia bugeja, joten tuotteen toiminnallisuuden voidaan katsoa olevan laadultaan hyvää. Testaukset ja niiden tulokset on tarkemmin kuvattuna I2- testausraportissa. Käytettävyyden varmistamiseen on projektissa käytetty useita tapoja. Käyttäjälähtöinen suunnittelu oli alusta lähtien keskeisessä roolissa. Käytettävyyden arviointiin on käytetty käytettävyystestejä kohderyhmän käyttäjien kanssa sekä tekemällä heuristista arviota projektin aikana. Ohjelmisto on läpäissyt kaikki käytettävyyden testit ja sovelluksen on tehty parannuksia testitulosten perusteella. Käyttäjät ovat pitäneet sovelluksen käyttöä pääasiassa helppona. Tarkemmin käytettävyystestin tuloksista on kerrottu Käytettävyyden arviointi SEPAssa. Näiden lisäksi vertaistestauksessa ja hyväksymistestauksessa löytyi ohjelmiston käytettävyyden kannalta ainoastaan pieniä huomautettavia asioita. Tämän perusteella ohjelmiston käytettävyyden voidaan todeta olevan laadultaan hyvää ja tavoite saavutettu. Jatkokehitettävyyttä on pyritty varmistamaan modulaarisella arkitehtuurisuunnittelulla ja toteutuksella sekä jo aiemmin mainitulla koodauskäytännöllä. Jatkokehitettävyyden varmistamiseksi koodista on tuotettu JavaDocdokumentaatio sekä teknisen ohjaajan vaatimusten mukainen tekninen määrittelydokumentti. Jatkokehitettävyyden mittaaminen on hankala ja lähinnä sitä on pystytty testaamaan staattisen analyysin avulla, jonka mukaan ohjelmisto on laadultaan pääosin hyvää. Näin ollen myös tuotteen jatkokehitettävyyttä voidaan pitää hyvänä. 10
4 Projektimetriikat Seuraavaksi käydään projektia etenemistä ja toteutumista erilaisten metriikoiden valossa. 4.1 Työtunnit Projektiin käytettiin yhteensä 1301,5 työtuntia joka ylitti projektille alussa asetetun kokonaisarvio vain 11,5 tunnilla, joka vastaa vain 0,88 % ylitystä. Projektissa käytetyt tunnit on esitetty taulukossa 4. Henkilöiden välillä ylityksen ja alitukset vaihtelevat hiukan rooleista riippuen samoin kuin tuntien jakaantuminen eri iteraatioihin. PP-iteraatiossa työtunnit ovat kertyneet management-tiimille ja toteutusiteraatioissa painotus on ollut suunnittelijoiden työssä. Kokonaisuuden kannalta olisi ehkä ollut parempi jos PP-iteraatioon management-tiimin osalta olisi käytetty vähemmän tunteja. Kaikkien henkilöiden kohdalla jakautuminen ei ole ollut aivan tasaista. Osaltaan tähän on ollut syynä esim. sairastapukset jotka ovat vähetäneet tunteja joltakin ja lisänneet niitä vastavasti jollekin toisella lisäksi esim. pääsuunnittelijan vaihtaminen I1-iteraation alussa kasvatti ko. iteraatiossa uuden pääsuunnittelinan työtunteja alkuperäsiin suunnitelmiin nähden. Projektimme keskeisin ero työtuntien osalta verrattuna muutamiin muihin kurssin projekteihin on se, että olemme pitäneet SEPA-työt ja niihin varatut työtunnit osana projektia. Kaiken kaikkiaan työmäärien jakautumien iteraatioiden kesken on ollut hyvä. Taulukko 4. Työmääräarvio ja Työtuntien toteuma projektissa EE PP I1 I2 Yhteensä Elina 190 82,5 73 41 196,5 Laura 150 76 55 26 157 Kari 190 72 69,5 43 184,5 Santeri 190 28 79,5 85 192,5 Samuel 190 19 67,5 106 192,5 Aleksi 190 25,5 73,5 78,5 177,5 Vesa 190 13,5 108 79,5 201 Yhteensä 1290 316,5 526 459 1301,5 PP-iteraatiossa työtunnit kohdistuivat projektinsuunnittelu ja hallinta toimenpiteisiin sekä vaatimusten selvittämiseen ja dokumentointiin. I1-iteraatiossa työtuntien jakautuminen eri tehtävien kesken yläotsikkotasolla on esitetty kuvassa 1. Projektinhallinta pitää sisällään mm. projektiryhmän kommunikoinnin ja työnohjauksen, johon on ko. tunneista on käytetty yli 70%. Ohjelmistosuunnittelusta 61% on käytetty arkkitehtuurin parissa ja ohjelmointitunneista 35% on käytetty käyttöliittymän työstämiseen. 11
Opiskelu 8 % Muu dokumenointi 6 % Projektinhallinta 27 % Ohjelmointi 22 % Työkalujen käyttöönotto ja ohjeistus 1 % Laadunvarmistus 12 % Ohjelmistonsuunnittelu 24 % Kuva 1. Työtuntien jakautuminen I1-iteraatiossa Kuvassa 2 on havainnollistettu työtuntien jakautuminen tehtävien kesken I2-iteraatiossa. Projektinhallinnoinnista 64 % on käytetty erilaiseen informointiin ja kommunikointiin. Ohjelmointitunneista 39% on käytetty käyttöliittymän toteutukseen ja 42 % facade luokkien toteutukseen. Virhekorjauksiin on raportoitu 12% tunneista. Prosenttijakaumat kaiken kaikkiaan todentavat jo muutoinkin haittuja seikkoja; kommunikointiin eri muodoissaan on käytetty paljon aikaa, kuitenkin toimintaa tehostamalla osuutta on saatu pienennettyä vaikka ensi sijainen tavoite ei olekaan ollut osuuden pienentäminen sillä kommunikointi on tärkeää. Ohjelmistosuunnittelussa on käytetty paljon aikaa arkkitehtuuriin joka kertoo myös sen haasteellisuudesta, toisaalta tehdyt ratkaisut ovat olleet onnistuneita, joten aika ei suinkaan ole mennyt hukkaan. 12
Opiskelu 2 % Muu dokumenointi 6 % Projektinhallinta 24 % Ohjelmointi 44 % Työkalujen käyttöönotto ja ohjeistus 1 % Ohjelmiston suunnittelu 6 % Laadunvarmistus 16 % Kuva 2. Työtuntien jakautuminen I2-iteraatiossa 4.2 Laatumetriikat Oheisiin taulukkon 5 koostettu projektin aikana havaitut virheet sekä niiden vakavuus eritelyinä iteraatioiden kesken sekä yhteenvetona projektille kokonaisuudessaan. Taulukon perusteella voidaan todeta, että havaittujen virheiden määrä kasvoi sekä toiminnallisuuden lisätyksen myötä että suhteessa suoritteuhin testauksiin. I2- iteraatiossa suoritettiin testauksia kattavammin ja monipuolisemmin. Tarkemmin I2-testauksesta sekä projektin laadun arvioinnista kerrotaan I2-Testausraportissa. Projektin loppuessa avoimiksi jäi 2 minor-luokan bugia, jotka sijaitsevat käyttöliittymässä. Kyseiset bugit löytyivät hyväksymistestauksessa, mutta niitä pystytty toistamaan ryhmän jäsenten toimesta. Kyseisistä bugeista informoidaan simulaattorin jatkokehitysdokumentissa. Taulukko 5 Projektissa havaitut virheet ja niiden vakavuus 1. iteraatio blocker major minor enhancement Yhteensä Facade-luokat - 2 1 1 4 GUI - 1 1 9 11 CoSCA-simulaattori - - - - - Yhteensä - 3 2 9 15 2. iteraatio blocker major minor enhancement Yhteensä Facade-luokat - 5 1-6 GUI 1 6 14 8 29 13
CoSCA-simulaattori 1 - - - 1 Yhteensä 2 11 15 8 36 Koko projekti blocker major minor enhancement Yhteensä Facade-luokat - 2 5 2 1 10 GUI 1 7 15 17 40 CoSCA-simulaattori 1 - - - 1 Yhteensä 2 14 17 18 51 Lisäksi keskeisimmät projektidoukmentit katselmoitiin sovitun käytännön mukaisesti. Dokumenti katselmoi vähintään kaksi projektin henkilöä, lisäksi tekninen ohjaaja on katselmoinut teknisen määrittelydokumentin. Katselmoitujen dokumenttien osalta voidaan todeta laadun olevan hyvää. 4.3 Koodin koko Taulukossa 6 on esitetty koodin kokoon liittyviä metriikoita projektin eri vaiheista. Facade- ja GUI-kerrosten lisäksi olemme toteuttaneet pieniä muutoksia myös muihin simulaattorin osiin, näitä muutoksia on kuvattu rivillä muut. Muut-kategorian koodiriviarvo pieneni toisessa iteraatiossa sen seurauksena, että simulaattorin kehityksen alkuvaiheissa havainnollistamiseen käytetyt esimerkkiluokat poistettiin default packagesta tarpeettomina. Taulukko 6: Koodirivit ja kommenttien osuus kokonaisriveistä projektin eri vaiheissa PP I1 I2/S1 I2/END Façade-layer (NCLOC/CR) 0 1041/27 1120/25 1182/25 GUI-layer (NCLOC/CR) 0 2488/16 3078/18 4559/17 Muut (NCLOC) 0 414 423 335 Yhteensä (NCLOC) 0 3943 4621 6076 Taulukossa koodin kokoa on tarkasteltu niin puhtaiden koodirivien (NCLOC, non-comment lines of code) kuin kommenttisuhteenkin (CR, comment ratio) osalta. Koodin koossa on tapahtunut tasaista kasvua läpi projektin ja kommenttien suhde rivien kokonaismäärään näyttäisi säilyneen suunnilleen samoissa lukemissa läpi projektin. GUI-kerroksen suhteellisen alhaiset kommenttisuhteet ovat selitettävissä sillä, että GUI-toteutuksessa komponenteille joudutaan yleensä asettamaan suhteellisen paljon erilaisia esim. muotoiluun ja asetteluun liittyviä parametreja, jotka kasvattavat koodirivien määrää, mutteivät vaadi sinänsä kommentointia. Kuva 1 havainnollistaa taulukon 5 tulokset graafisessa muodossa. Kuvassa korostuu se, miten facade-layerin ja muut-kategorian koot ovat pysyneet lähes samana I1-iteraation jälkeen ja kehitys I2:n aikana on tapahtunut lähinnä käyttöliittymäkerroksella. Tämä on osaltaan osoitus siitä, että alkuperäisen simulaattorin komponenttien 14
käsittelyyn vaadittava koodi saatiin melko hyvin toteutettua ensimmäisen iteraation aikana, kun suuria lisäyksiä ei kakkositeraatiossa enää tarvinnut tehdä. 7000 6000 5000 NCLOC 4000 3000 2000 Façade-layer GUI-layer Muut 1000 0 I1 I2/S1 I2/END Kuva 3. Koodin koko projektin eri vaiheissa 15
5 Työkäytännöt ja työkalut Seuraavissa kappaleissa kuvataan projektissa käytetyt menetelmät ja työkalut sekä arvioidaan niiden soveltuvuus tässä projektissa. 5.1 Työkäytännöt Iteratiivinen kehitys Projektissa käytettiin kurssin ohjeistuksen mukaisesti iteratiivista kehitystä. Projekti oli jaettu kolmeen iteraatioon, joista ensimmäinen keskittyi projektin suunnitteluun ja kaksi jälkimmäistä varsinaiseen sovelluksen toteuttamiseen. Menetelmän mukaisesti ensimmäisen toteutusiteraation lopussa julkaisimme ensimmäisen toimivan sovelluksen, joka tarjosi rajallisen määrän toiminnallisuutta ja jonka avulla pystyttiin tarkentamaan vaatimuksia seuraavaan iteraatioon. Menetelmä soveltui projektiin hyvin, sillä projektin alussa kaikki vaatimukset eivät olleet selvät. Myöskään se, miten laajan tuotoksen pystymme resursseillamme toteuttamaan ei ollut aluksi kovin selvää. Iteraatiivinen kehitysmenetelmä mahdollisti vaatimusten tarkentamisen ja muuttamisen viimeistä iteraatiota varten. Toteutusiteraatiot jaetiin 4. sykliin: iteraation suunnitteluun, kahteen toteutus- ja testaussykliin sekä viimeistelyyn. Toteutettavat vaatimukset jaettiin toteutussyklien kesken ja syklien välissä pidettiin ns. välietappikatselmukset, joissa vaatimusten toteutumisen lisäksi tarkistettiin tarkemmin projektin muu eteneminen (esim. dokumentaatio), työmääräarviot ja riskit. Välietappikatselmukset olivat erityisen hyödyllisiä, sillä niissä projektia katsottiin kokonaisuutena ja tarvittavien muutosten vaikutus myös arvioitiin kokonaisuuden kannalta. Lisäksi pidimme viikoittaisia management-tiimin ja kehittäjien omia lyhyitä palavereja (kts. palaverikäytännöt ja Coding Camp SEPA), jotka keskittyivät projektin statuksen seuraamiseen ja mahdollisten ongelmien pikaiseen tunnistamiseen. Iteraation suunnittelu Projektipäällikkö vastasi iteraatiosuunnitelman tekemisestä, mutta käytännössä koko management tiimi osallistui suunnitteluun. Toteutettavat vaatimukset ja niiden priorisointi sovittiin asiakkaan kanssa. Toteutusiteraatioissa näin tehtiin jo edellisen iteraation lopuksi. Iteraatiosuunnittelu on luonteva osa iteratiivista kehitystä. Iteraatiosuunnitelmasta päätettiin tehdä oma dokumenttinsa ja tämä koettiin toimivaksi käytännöksi. Varsinkin projektin alussa olisi ollut epäkäytännöllistä palauttaa iteraatiosuunnitelmana projektisuunnitelma, josta vain muutamassa kappaleessa olisi ollut tekstiä. Erillinen dokumentti teki suunnitelmasta oman kokonaisuutensa ja mahdollisti iteraation aikana ja lopussa suunnitelmien sekä toteuman vertaamisen alkuperäiseen suunnitelmaan. 16
Iteraatiosuunnittelun yhteydessä olisi voitu myös tarkistaa projektin ylätason tavoitteita ja arvioida tarvetta niiden muuttamiselle tai korjaamiselle. 17
Dokumentointi Projektisuunnittelun (ja iteraationsuunnittelun) ohessa tuotettavat dokumentin jaettiin ryhmän jäsenten vastuiden mukaisesti. Dokumentteihin päätettiin käyttää samanlaista Word-pohjaa ja tallennuspaikaksi sovittiin TikiWiki. Suurin osa projektin dokumenteista on tuotettu saman Word-pohja avulla, jonka avulla projektidokumentaation on yhtenäinen kokonaisuus. Dokumentit on tuotettu sovitun mukaisesti pääasiassa suomenkielisinä, ainoastaan käyttöohje ja tekninen määrittelydokumentti on tuotettu englanniksi. Alussa suunniteltujen dokumenttien lisäksi projektin lopussa tuotettiin oma englannin kielinen dokumenttinsa ns. jatkokehitysnäkemyksistä. Dokumenttien tallennuspaikkana TikiWiki ei ollut riittävän toimiva, sillä suurien tiedostojen (yli 800kB) tallentaminen TikiWikiin ei enää onnistunut. Pärjäsimme tämän epämukavuuden kanssa kohtuullisesti, sillä onneksi näiden isojen tiedostojen osalta ei ollut jatkuvaan usean henkilön yhtäaikaista päivitystarvetta, joten kesken projektin emme lähteneet siirtämään kaikkia dokumentteja esim. CVS:iin. Riskienhallinta Riskien hallintaan käytettiin modifioitua ja kevennettyä versiota Jyrki Kontion kehittämästä Riskit - menetelmästä. Projektiin liittyvät keskeisimmät riskit tunnistettiin projektin alussa. Jokaiselle riskille arvioitiin riskitekijät, vaikutukset toteutuessa, toteutumisen todennäköisyys, riskinhallintatoimet sekä vaihe, jossa riskin olisi mahdollista realisoitua. Riskien tilaa monitoroitiin kerran kunkin iteraation aikana sen puolivälissä olevassa statuspalaverissa. Samalla käytettiin hetki aikaa mahdollisten uusien riskien tunnistamiseen. Mahdolliset muutokset kirjattiin riskilokiin. Totesimme käyttämämme riskienhallintamenetelmän suhteellisen toimivaksi. Oli hyödyllistä erotella toisistaan toteutumisen todennäköisyys sekä toteutumisen vaarallisuus. Hyödyllistä oli myös se, että riskienhallintatoimet oli määritelty etukäteen. Projektin aikana muutaman riskin suhteen oli havaittavissa toteutumista siinä määrin, että se vaati toimenpiteitä. Laitteisto-ongelmaan liittyvä riski toteutui ohjelmatyöluokan verkko-ongelman muodossa. Tästä syystä Coding Campit siirrettiin Ohjelmatyöluokasta Maarintalolle. Toinen toimenpiteitä aiheuttanut riski oli ryhmän jäsenten sairastumiset, joka aiheutti tehtävien siirtoja suunnittelijoiden kesken ja uudelleen aikataulutusta. Tuntiraportointi Projektin alussa käytettiin muutama tunti valmiin tuntiraportointijärjestelmän etsimiseen siinä kuitenkaan onnistumatta. Tuntiraportoinnissa päädyttiin itse tehtyihin Excel -taulukkomuotoiseen raportointiin. Kullekin henkilölle oli oma tiedostonsa, jossa oli vastaavasti kullekin iteratiolle oma sivunsa. Lisäksi oli yksi yhteenvetotiedosto, jossa laskettiin projektin aikana eri raportointeihin tarvittavia yhteenvetoja raportoiduista tunneista. Tiedostoja säilytettiin TikiWikissä. Ryhmän jäsenten tuli huolehtia oman tuntiraporttinsa ajantasaisuudesta vähintään joka viikon maanantaina klo 12 mennessä. Tämän jälkeen projektipäällikkö teki raportoidusta tunneista koosteen projektiryhmän WWW-sivuilla. 18
Projektipäällikkö oli vastuussa ko. tiedostojen tekemisestä ja päivittämisestä. Menetelmä oli toimiva, mutta erityisesti alussa varsin työläs ja aikaa vievä. Tiedostojen toteuttaminen automaattisia laskentakaavoja myöten vei aikaa. Uusien tehtävien lisääminen silloin, kun iteraation tuntiraportointi oli jo aloitettu, oli myös aikaa vievää. Loppua kohti automaattiset laskukaavat kuitenkin nopeuttivat yhteenvetojen tekemistä ja tuntiraportoinnin seurantaa. Menetelmä oli siis riittävän toimiva, mutta varmasti ajankäytön kannalta olisi ollut hyödyllistä, mikäli olisi ollut mahdollisuus käyttää jotakin valmista tuntiseuranta- ja raportointisovellusta. Kommunikointi ja palaverikäytännöt Projektiryhmän sisäiseen kommunikointiin käytettiin TikiWikiä, sähköpostia, puheluita ja Coding Camptapaamisia. Iteraation I1:n alussa harkitsimme IRC:n käyttöä mutta vähäisen kannatuksen vuoksi se jäi pian pois käytöstä. Iteraatio I1:n aikana TikiWikiä käytettiin dokumenttien jakelun lisäksi aktiivisesti myös keskusteluun ja ongelmien ratkomiseen. Coding Campien kehittymisen ja asioiden selkiintymisen myötä TikiWikin käyttö keskustelufoorumina väheni. Toisaalta osa sovituista asioista olisi voitu tallentaa edelleen wikiin, etteivät asiat olisi jääneet pelkästään sähköposteihin. Sähköpostien etuna on se, että kerralla saavuttaa koko projektiryhmän yhdellä viestillä ja eri aikataulujen mukaan toimivat ihmiset saavat tiedon silloin, kun voivat lukea postinsa. Sähköposti ei kuitenkaan sovellu kovin hyvin nopeaa reagointia vaativien asioiden kommunikointiin. Puhelut toimivat hyvin silloin, kun piti nopeasti saada vastauksia tai vietyä viesti perille. Puheluita myös käytettiin ja se näkyi puhelinlaskuissa. Puheluiden heikkoutena on, että aina jotkin sovitut asiat eivät tulleet kirjatuksi ja jolloin jäi muistinvaraiseksi seurata asioiden etenemistä. PP-iteraatiossa ja I1-iteraatiossa pidettiin viikoittaisia projektiryhmän palavereita, jotka kommunikoinnin kannalta olivat hyviä, mutta vastaavasti myös aikaa vieviä. Viikkopalavereista luovuttiin sen jälkeen, kun Coding Camp-käytäntö otettiin viikoittaiseen käyttöön. I2-iteraatiossa Coding Campin alkuun sovittiin lyhyt palaveri osuus, jossa tarkistettiin mitä kukin oli tehnyt edellisen kerran jälkeen, mitä ongelmia oli kohdannut ja mitä aikoo seuraavaksi tehdä. Lisäksi palaveriosuutta käytettiin työnohjaukseen. Management-tiimin lyhyet seurantapalaverit palautettiin viikoittaiseksi käytännöksi I2-iteraatiossa ja tämä oli varsin toimiva ratkaisu. Käytännössä mihinkään vakiopalaveriin ei projektin alun jälkeen tehty erillistä agendaa, koska ne olivat vakiomuotoisia. Sen sijaan erikseen pidettyihin esim. välietappikatselmuksiin ja asiakaspalavereihin agendat mietittiin etukäteen. Mentorilla ja asiakkaan teknisellä edustajalla oli pääsy projektiryhmän TikiWiki sivuille, joista he pystyivät seuraaman projektin tapahtumia näin halutessaan. Lisäksi projektipäällikkö oli vastuussa kommunikoinnista mentorin kanssa. Yleensä mentor -kommunikointi tapahtui sähköpostitse, erikseen järjestettyjä mentor - tapaamisia lukuun ottamatta. Asiakaskontakteista vastasi vaatimusmäärittelijä ja tämä kommunikointi hoidettiin pääasiassa sähköpostitse asiakkaan toivomuksesta. Tämän lisäksi kaikissa iteraatioissa järjestettiin asiakaspalavereita, joissa sovittiin ja selviteltiin vaatimuksiin yms. projektiin liittyviä asioita. Projektiryhmällä oli myös julkiset www-sivut, joiden kautta oli pääsy virallisiin dokumentteihin ja mahdollisuus seurata viikoittain päivitettyä tuntiraportointia. 19
Pienryhmät Toteutusiteraation 1 alussa projektiryhmämme jakaantui kolmeen pienryhmään, joiden aihealueita olivat arkkitehtuurisuunnittelu, käyttöliittymäsuunnittelu sekä laadunvarmistussuunnittelu. Tärkein syy pienryhmiin jakautumiseen oli se, että nämä aihealueet nähtiin niin keskeisinä, että ne haluttiin suunnitella huolella ja siten, ettei mikään keskeisistä ratkaisuista jäisi vain yhden henkilön vastuulle. Muita syitä pienryhmiin jakautumiselle olivat suunnittelijoiden nopeampi integrointi projektiryhmään sekä heidän oppimiskäyränsä nopeuttaminen suhteessa projektin aiheeseen. Etenkin arkkitehtuuriryhmän perustaminen oli kriittistä, koska pääsuunnittelijan vaihdos edellytti tiedonsiirtoa. Katselmointikäytäntö Projektin alussa päätimme kahdesta katselmointi käytännöstä; perinteisestä formaalista katselmoinnista palaverineen sekä kevyemmästä sähköpostinvälityksellä tehtävästä katselmoinnista. Hyvin nopeasti havaitsimme ettei formaali katselmointikäytäntö ollut käytettävissä olevilla resursseilla ja aikataululla järkevä ratkaisu, joten kaikki projektissa tehdyt katselmoinnit tehtiin kevyellä katselmointimenetelmällä, jossa dokumentti vastuullinen toimittaa katselmoitavan dokumentin katselmoijille sähköpostitse ja katselmointikommentit lähetetään dokumenttivastaavalle sähköpostilla. Katselmointikäytännössä oli määritelty muutama kategoria katselmoinnissa tehdyille havainnoille (pienet puutteet, suuret puutteet, virheet ja heränneet kysymykset). Käytännössä näistä ei pidetty tiukasti kiinni, pääasia oli että katselmointi tehtiin ja kommentit saatiin lähetettyä. Kevyt katselmointimenetelmä oli projektille riittävä katselmointitapa. Projektin alussa pohdittiin koodikatselmointien pitämistä, mutta käytännössä käytettävissä olleilla resursseilla tämä olisi ollut hidas ja resursseja syövä käytäntö, eikä sitä näin ollen tehty. Projektin lopussa tuotettua koodia käytiin läpi siitä näkökulmasta oliko esim. kommentointia tehty sovitun käytännön mukaisesti ja tehtiin tarvittavia korjauksia. Iteraatiodemot Iteraatiodemot pidettiin kurssin ohjeistuksen ja aikataulutuksen mukaisesti. Paikalla olivat asiakkaan ja projektiryhmän lisäksi kurssinhenkilökunnan edustajina mentor ja kurssin vastaavaopettaja. Iteraatiodemot sujuivat hyvin suunniteltujen agendojen mukaisesti ja pysyivät aikataulussa. Kokemuksena iteraatiodemot olivat mielenkiintoisia ja opettavaisia. Vikojen seuranta Vikojen seuranta suoritettiin kurssin tarjoaman bugzilla -työkalun avulla suunnitelman mukaisesti niin, että testauksesta vastaava Santeri vastasi bugien tilojen päivittämisestä ja Vesa puolestaan vastasi bugien osoittamisesta ryhmän jäsenille korjaamista varten. Ainoaksi pieneksi ongelmaksi vikojen seurannassa muodostui bugzillan ominaisuuksien määrä, joka oli projektin kokoon nähden hiukan suuri. Mitään todellisia ongelmia vikojen seurannassa ei ilmennyt koko projektin aikana. 20
Versionhallinta Versionhallintajärjestelmänä projektissamme käytettiin CVS:ää, johon oltiin yhteydessä Eclipseen integroidun CVS -rajapinnan kautta. Järjestelmä koettiin erittäin toimivaksi. Versionhallintastrategiamme oli melko vapaa, eli samanaikaiset muokkaukset samoihin tiedostoihin olivat sallittuja, joskin niitä pyrittiin välttämään työnohjauksellisilla keinoilla. Tiedostojen päivittämisessä CVS:ään noudatettiin seuraavia perussääntöjä: a) koodin tulee olla ei itsestään selviltä osiltaan kommentoitua, b) päivitetty koodi ei saa estää järjestelmän ajamista, ja c) mikäli kaksi kehittäjää on muokannut samaa tiedostoa, jälkimmäinen päivittäjä vastaa koodin integroinnista ja toimivuudesta. Versionhallintastrategian kanssa ei tullut ongelmia. Koodauskäytäntö Projektissamme oli useita kehittäjiä, joten yhtenäisen koodauskäytännön merkitys korostui niin oman työn kuin koodin jatkokehitettävyydenkin kannalta. Erityisesti koodin jatkuva kommentointi oli merkittävässä osassa, paitsi oman työskentelyn myös projektin teknisen dokumentaation kannalta: alhaisen tason dokumentaationa käytetään JavaDoc:ja. Koodin muotoilussa on käytetty Sunin Java Coding Conventionia. Lisäksi projektin aikana hyödynnettiin Eclipsen mahdollisuutta omien tagien korostamiseen, erityisesti FIXME ja TODO palvelivat hyvin "kirjanmerkkeinä". Sovittua koodauskäytäntöä noudatettiin projektissa hyvin. Ohjelmakoodin koon raportointi Ohjelmakoodin kokoa raportoitiin kahden muuttujan suhteen, Non-Comment Lines Of Coden (NCLOC) ja Comment Ration (CR) suhteen. Ohjelmakoodin koko raportoitiin projektin aikana kolmesti: ensimmäisen iteraation lopuksi, toisen iteraation välidemossa ja koko projektin loppuraportissa. Koodin koon raportoinnissa käytettiin apuna SourceForgen Metricsiä (NCLOC:t) ja Borlandin Metricsiä (CR:t). Koodin koon raportointi yksiselitteisesti oli hankalaa sillä käytetyt työkalut eivät selkeästi ilmaisseet kuinka arvot tarkkaan ottaen lasketaan, mitä niissä tekijöitä otetaan huomioon (tyhjät rivit jne.). Tämän projektin kannalta koodin koon raportoinnin hyödyt olivat vähäiset eli esim. kehitystyön arvioinnin apuvälineeksi näitä tietoja ei vielä voinut käyttää. Vertaistestaus Projektissa käytettiin vertaistestausta suunnitelman ja kurssin aikataulun mukaisesti toisen iteraation lopussa. Testaus suoritettiin vertaisryhmän toimesta viiden tutkivan testauksen sessiokuvauksen avulla, joista kunkin ajaminen vei noin tunnin ja joista jokainen ajettiin kahdesti eri testaajan toimesta. Bugeja vertaisryhmä löysi 10, joista neljää ei ollut vielä löydetty projektiryhmän omissa testeissä. Tämän lisäksi vertaistestaus tuotti kiitettävästi palautetta simulaattorin käytettävyyden parantamiseksi. Vertaistestaus koettiin hyväksi ja toimivaksi käytännöksi. 21
Vaatimusten määrittely ja hallinta Vaatimusten määrittely ja hallinta koostui projektissa karkeasti jaoteltuna kolmesta osasta: Vaatimusten hankinnasta ja dokumentoinnista, vaatimusten analysoinnista ja priorisoinnista, sekä toteutusiteraatioiden aikaisesta vaatimusten hallinnasta. Tarpeiden kartoitus aloitettiin asiakkaan korkean tason tavoitteiden ja projektin tärkeimpien käyttäjäryhmien selvittämisestä ja priorisoinnista. Näiden perusteella tehtiin käyttäjätutkimus simulaattorin toistaiseksi ainoalla käyttäjällä, joka oli myös tämän projektin asiakas. Käyttäjätutkimuksessa seurattiin simulaattorin käyttöä sen todellisessa käyttöympäristössä, sekä pyydettiin käyttäjää mm. kuvailemaan tekemiään toimia ja toiminnan vaiheita sanallisesti käyttäjän termistön selvittämiseksi. Edellisten aktiviteettien tulosten pohjalta tehtiin vaatimusmäärittelyn ensimmäinen versio, jossa vaatimukset kuvattiin käyttäjän näkökulmasta. Lisäksi tehtiin käyttöliittymäprototyyppi, josta haettiin palautetta asiakkaalta. Prototyyppiä myös testattiin projektin kannalta keskeisellä käyttäjäryhmällä, opiskelijakäyttäjillä. Vaatimukset priorisoitiin katsomalla jokaista vaatimusta sekä tärkeyden, että toteutuskustannusten näkökulmasta. Asiakkaan tärkeyden määritteli asiakas ja toteutuksen kustannusarviosta vastasi pääsuunnittelija. Toteutusiteraatioihin asiakkaan kanssa valitut käyttötapaukset kirjoitettiin auki. Jokaisen dokumenttiin kirjoitetun vaatimuksen tilaa monitoroitiin seuraavalla asteikolla: ehdotettu, hyväksytty iteraatioon x, toteutettu, testattu, toimitettu, hylätty. Erityisen tyytyväisiä olimme, että käytimme paljon aikaa käyttäjien todellisten tarpeiden ymmärtämiseen ja vaatimusten syvälliseen hankkimiseen. Etenkin projektin alkuvaiheessa oli ensiarvoisen tärkeää tutustua käytettyihin termeihin ja käsitteisiin, sekä niiden välisiin suhteisiin perusteellisesti. Myös priorisointikäytännöt koettiin varsin toimiviksi. Iteraatioiden aikaisessa vaatimustenhallinnassa koettiin haasteita, kun käyttöliittymäprototyypit lähtivät helposti elämään omaa elämäänsä, eikä suoraa linkkiä vaatimuksiin muistettu aina tehdä, vaikka ne taustalla vaikuttivatkin. Summa summarum: Vaatimustenmäärittely toimi erinomaisesti, mutta hallintakäytännöissä olisimme voineet ottaa vielä tiukemmat periaatteet, jotta projektiin ei olisi uinut vaatimuksia ohi prosessin. Käyttäjälähtöinen suunnittelu Asiakkaan ja käyttäjän äänen kuulumiseksi ja säilymiseksi koko projektin ajan kiinnitettiin erityistä huomiota käyttäjälähtöiseen suunnitteluun. Keskeinen toimi tämän asian varmistamiseksi oli tiivis yhteistyö asiakkaan ja teknisen ohjaajan kanssa koko projektin kanssa. Lisäksi määriteltiin iteraatiokohtaiset toimenpiteet käyttäjänäkökulman varmistamiseksi projektissa. Projektisuunnittelu -iteraatiossa tehtiin kevyt käyttäjätutkimus, jossa selvitettiin simulaattorin toistaiseksi ainoan käyttäjän kanssa aidossa käyttötilanteessa, mitkä ovat käytön perussekvenssit ja kuinka paljon erilaisia toimintoja käytetään. Lisäksi PP -iteraatiossa tehtiin tiivistä yhteistyötä asiakkaan kanssa tärkeimpien käyttäjäryhmien ja heidän keskeisten tarpeidensa selvittämiseksi sekä tuotettiin vaatimusmäärittely dokumentti 22