Projektisuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 27.9.2005 Elina Kontro Ensimmäinen mallipohjaan täytetty versio, englanninkielinen 0.2 5.10.2005 Elina Kontro 0.3 6.10.2005 Laura Lehtola Dokumentointi kielen vaihto, rakenteen muuttamista, sisältöä budjetti, termejä Asiakkaan tavoitteet, riskienhallintasuunnitelma ja riskiloki. Kirjoitusvirheiden korjausta. 0.4 8.10.2005 Kari Ylihärsilä Ohjelmointikäytännöt ja työkalut, ideoiden lisäystä. 0.5 8.10.2005 Elina Kontro Templaten vaihto, sisällön päivitystä, PP-iteraatio suunnitelman tietojen siirtäminen tähän dokumenttiin ja päivittäminen 0.6 9.10.2005 Laura Lehtola Terminologiaa, vaatimustenhallinta, alustava budjetti, katselmointikäytännöt. 0.7 9.10.2005 Elina Kontro 0.8 12.10.2005 Kari Ylihärsilä 0.9 12.10.2005 Elina Kontro Aikatauluja, termejä, korjauksia Tarkka kuvaus työkaluista, versionumerot ja linkit työkaluihin. Yleisiä parannuksia. Merkitsin avoimia kohtia TODO merkinnöillä. Työmääräarvioita, palaverikäytäntöjen & budjetin päivitys, kehittäjä -> suunnittelija 0.95 14.10.2005 Kari Ylihärsilä Parannuksia, lisätty rakennekaavio, tekstin selvennystä. 0.96 14.10.2005 Elina Kontro 0.97 15.10.2005 Elina Kontro SEPA päivitystä 0.98 16.10.2005 Elina Kontro 1.00 16.10.2005 Laura Lehtola 1.01 21.10.2005 Santeri Saarinen QA-osuuden aloitus lukuun 5.2.1. Oppimistavoitteita, SEPA aiheet, kokouskäytäntöjen päivitys, virheiden korjausta SEPA päivitystä, oppimistavoitteiden päivitystä, työmääräarvio PP iteraatioon päivitetty, johdanto, tuntiraportointia tarkennettu, pienryhmät lisätty, korjauksia Käyttäjä- ja asiakasnäkökulman varmistaminen, vaatimusten hallinnan uusi versio, kirjoitusvirheiden korjausta ja muotoilua. 1.02 21.10.2005 Elina Kontro QA-kohdan hieromista 1.03 23.10.2005 Elina kontro Henkilöstö kohtaan työmäärä korjaus, SEPA aiheen korjaus 1.04 24.10.2005 Elina Kontro QA-asiat siirretty omaan tiedostoon 1.05 7.11.2005 Elina Kontro Suunnitelman päivitystä (I1 iteraatio suunnitelma), vastuumuutokset 1.06 15.11.2005 Elina Kontro Riski-login tarkastusta, lähdeluettelo, I1 päivitystä 1.07 21.11.2005 Elina Kontro 1.08 22.11.2005 Elina Kontro Projektisuunnitelman päivitys välietappikatselmuksen jälkeen: käytäntöjä päivitetty, katselmointipäivämäärät ja ryhmät I1 Työmääräarviotaulukko päivitetty, riskilogi siirretty liitteeksi. Muita korjauksia 1.09 28.11.2005 Elina Kontro Riskilokin päivitys, korjauksia 2.0 2.12.2005 Elina Kontro Katselmoinnin perusteella tehtyjä korjauksia 1
Sisällysluettelo 1 Johdanto 1 1.1 Projektin tarkoitus ja laajuus 1 1.2 Terminologia ja määritykset 2 1.3 Järjestelmä ja ympäristö 3 2 Osapuolet ja henkilöstö 4 2.1 Projektiryhmä 4 2.2 Muut osapuolet 5 3 Tavoitteet ja lopetuskriteerit 6 3.1 Asiakkaan tavoitteet 6 3.2 Projektiryhmän tavoitteet 7 3.3 Henkilökohtaiset oppimistavoitteet 8 3.4 Projektin keskeytyskriteerit 9 3.5 Projektin lopetuskriteerit 9 4 Resurssit ja budjetti 10 4.1 Henkilöt 10 4.2 Materiaalihankinnat 10 4.3 Budjetti 11 5 Työkäytännöt ja työkalut 12 5.1 Käytännöt 12 5.1.1 Iteratiivinen kehitys 12 5.1.2 Iteraation suunnittelu 12 5.1.3 Dokumentointi 13 5.1.4 Riskienhallinta 14 5.1.5 Tuntiraportointi 15 5.1.6 Ohjelmakoodin koon raportointi 15 5.1.7 Kommunikointi ja palaverikäytännöt 15 5.1.8 Pienryhmät 16 5.1.9 Katselmointikäytäntö 17 5.1.10 Iteraatiodemot 17 5.1.11 Vikojen seuranta 18 5.1.12 Versionhallinta 18 5.1.13 Koodauskäytäntö 18 5.1.14 Vertaistestaus 19 5.1.15 Vaatimusten määrittely ja hallinta 19 5.2 Laadunvarmistussuunnitelma 22 5.3 Työkalut 22 5.3.1 Kehityslaitteisto 22 5.3.2 Ohjelmistot 22 5.3.3 Kehitystyökalut 23 5.4 Standardit 24 1
5.5 SEPA -työt 24 5.5.1 Coding Camp 25 5.5.2 Käytettävyyden arviointi 25 5.5.3 Staattiset menetelmät 25 6 Vaiheistus 27 6.1 Projektin suunnittelu (PP) 28 6.2 Toteutusiteraatio 1 (I1) 31 6.2.1 I1 iteraation tavoitteet: 31 6.2.2 I1 iteraation tuotokset: 31 6.2.3 I1-iteraation tehtävät 32 6.2.4 I1 iteraation vaiheistus ja aikataulutus 33 6.3 Toteutusiteraatio 2 (I2) 38 6.4 Tavoitteet: 38 6.5 Tuotokset: 38 7 Riskiloki 40 8 Lähdeluettelo 41 2
1 Johdanto Tämä dokumentti on TeamDC -projektiryhmän projektisuunnitelma Teknillisen Korkeakoulun kurssilla T-76.4115 Ohjelmistoprojekti I. Dokumenttia päivitetään koko projektin ajan. 1.1 Projektin tarkoitus ja laajuus Tehdastuotannon päivittäisenä haasteena on tehdä nopeasti päätöksiä tilausten aikataulutuksesta. Tällaisia päätöksiä ovat esimerkiksi koska toimitetaan, kenelle ja milloin tuotantoresurssit ovat käytettävissä. Päätösprosessi on yritykselle tärkeä, kuitenkin vain harvat yritykset käyttävät hyväkseen oman toimitusketjun hallitaan alan tutkijoiden kehittämiä satoja eri sääntöjä, jotka auttavat parempaan tilausten hallitsemiseen ja aikataulutukseen. Helsingin Kauppakorkeakoulussa (HKKK) kehitetyn CoSCA (Coordination of Supply Chain Activities) simulaattorin avulla on ollut tarkoitus mallintaa tilaus-toimitusketjun päätöksiä ja hajautettua tuotannonohjausta. Tällä hetkellä simulaattorilla on ollut yksi käyttäjä eikä siihen näin ollen ole kehitetty graafista käyttöliittymää. Asiakkaan keskeisenä tavoitteena on päästä hyödyntämään simulaattoria tuotannon suunnittelun ja ohjauksen sekä toimitusketjun hallinnan opetuksessa. Lisäksi asiakas haluaisi tarjota yritysmaailmassa työskenteleville käytännönihmisille mahdollisuuden ymmärtää kokeilun kautta, miten erilaisten päätössääntöjen käyttäminen vaikuttaa tilaus-toimitusprosessin ennustettavuuteen ja tehokkuuteen. Tässä ohjelmistokehitysprojektissa on tarkoitus toteuttaa 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. Projektin alussa tullaan kartoittamaan myös muiden lisätoiminnallisuuksien tarvetta ja toteutusmahdollisuuksia tässä projektissa. Tämän ohjelmistokehitysprojektin toteuttaa TeamDC- projektiryhmä T-76.4115 Ohjelmistoprojekti I-kurssin harjoitustyönä. Projektiryhmässä on 7 henkilöä, joista kaikilla on kiinteä 150 tunnin työmäärä käytettävissä projektiin. Osa ryhmän jäsenistä suorittaa projektin ohessa parityönä työmäärältään 20h/henkilö olevan T- 76.5633 Ohjelmistotuotannon erikoiskurssin projektia tukevasta aiheesta ja panostavat projektiin 20h/henkilö lisää. Projektin aikataulu on kiinteä alkaen 27.9.2005 ja loppuen 2.3.2006, sisältäen joululoman 8.12.2005-9.1.2006. 1
1.2 Terminologia ja määritykset Seuraavassa taulukossa 1 on kuvattu tässä dokumentissa ja projektissa käytettäviä termejä ja lyhenteitä. Taulukko 1. Projektissa käytettäviä lyhenteitä ja terminologiaa Termi tai lyhyenne Kuvaus CoSCA Coordination of Supply Chain Activities CoSCA järjestelmä Tässä projektissa kehitettävä järjestelmä, joka käsittää sekä jo kehitetyn simulaattorin, että siihen kehitettävän käyttöliittymän. CosCA simulaattori HKKK:ssa kehitetty CoSCA simulaattori, jossa ei toistaiseksi ole varsinaista käyttöliittymää. HKKK Helsingin Kauppakorkeakoulu I1 1. Toteutusiteraatio (Implementation 1) I2 2. Toteutusiteraatio (Implementation 2) LOC Lines of Code Koodirivien määrä Management ryhmä Projektin johtoryhmä, johon kuuluvat projektipäällikkö (Elina), vaatimusmäärittelijä (Laura) sekä pääsuunnittelija(kari). NCLOC Lines of code without comments and blank lines Koodirivien määrä, poislukien kommenttirivit ja tyhjät rivit PP Projektisuunnittelu iteraatio Projektiryhmä Projektin toteuttava ryhmä (management ryhmä + suunnittelijat), jossa on seitsemän jäsentä. SEPA Software Engineering Practice Assignment, erillinen projektin ohessa pääasiassa parityönä toteutettava työ Suunnittelijat Projektin 4 jäsentä (Santeri, Samuel, Aleksi ja Vesa), joiden päävastuulla on järjestelmän tekninen suunnittelu, ohjelmointi ja testaus. TKK Teknillinen korkeakoulu XML Extensible Markup Language, tiedosto formaatti 2
1.3 Järjestelmä ja ympäristö Tämän projektin keskeisin tavoite on toteuttaa olemassa olevaan CoSCA-simulaattoriin graafinen käyttöliittymä. Olemassa oleva CoSCA -simulaattori on toteutettu Javalla, käyttäen open source työkaluja. Järjestelmää kehitetään ja testataan Windows-ympäristössä. Järjestelmän simulaatioajo kestää tyypillisesti (opetuskäytössä) muutaman sekunnin, haastavassa tapauksessa (tutkimuskäytössä) noin tunnin. Simulaattoria varten ei tarvita erillistä erikoisalustaa. Aiemmin kehitetty simulaattori lukee asetuksensa XML-tiedostosta ja raportoi tuloksensa tekstimuodossa tiedostoon, jota voidaan jatkokäsitellä esim. Excelillä. Laajennusprojektin tuotoksen on tarkoitus mahdollistaa asetusten syöttäminen, simulaation ajon hallinta ja tulosten raportointi käyttöliittymästä. Tarkempaa tietoa uuden järjestelmän toteutuksesta löytyy CoSCA GUI Technical Specification dokumentista. Järjestelmä toimii seuraavanlaisessa esimerkkikokoonpanossa: Pentium 4 (2,6 Ghz), 512Mb muistia, Windows 2000/XP, Java 5.0. 3
2 Osapuolet ja henkilöstö Kuvassa 2 on esitetty projektin osapuolet. Asiakas Katariina Kemppainen Tekninen ohjaaja Lauri Svan Käyttäjät Projektiryhmä TeamDC Projektipäällikkö Elina Kontro Vaatimustenhallinta Pääsuunnittelija Laura Lehtola Vesa Haukkavaara Suunnittelijat Aleksi Airola Kari Ylihärsilä Samuel Korpi Santeri Saarinen Mentor Kari Suhonen Kuva 2. Projektin osapuolet 2.1 Projektiryhmä Projektiryhmän vastuulla on selvittää asiakkaan vaatimukset ja toteuttaa niiden mukainen käyttöliittymä ja toiminnallisuus CoSCA-simulaattoriin. Taulukossa 2 on esitetty projektiryhmän jäsenten roolit yleisellä tasolla sekä heidän yhteystietonsa. Taulukko 2. TeamDC-projektiryhmä ja yhteystiedot Rooli Nimi Puhelinnumero Sähköpostiosoite Projektipäällikkö Elina Kontro 040 569 8496 elina.kontro(at)pp.inet.fi Mentoryhteyshenkilö Vaatimustenhallinta, Laura Lehtola 050 591 0358 laura.lehtola(at)hut.fi Asiakasyhteyshenkilö Pääsuunnittelija Vesa Haukkavaara 040 731 1467 vthaukka(at)cc.hut.fi Tekninenyhteyshenkilö Suunnittelija Kari Ylihärsilä 050 574 1463 kylihars(at)cc.hut.fi Suunnittelija Aleksi Airola 0400 511 144 aleksi.airola(at)tkk.fi Suunnittelija Samuel Korpi 040 821 954 sjkorpi(at)cc.hut.fi Suunnittelija Santeri Saarinen 050 585 7981 santeri.saarinen(at)hut.fi 4
2.2 Muut osapuolet Projektin muut osapuolet ovat asiakas ja T-76.4115 Ohjelmistoprojekti 1 -kurssin henkilökunta. Asiakas-osapuoli voidaan jaotella itse asiakkaaseen, tekniseen ohjaajaan sekä ohjelmiston tuleviin käyttäjiin. Projektin asiakas ja yhteyshenkilö on Katariina Kemppainen Helsingin Kauppakorkeakoulusta. Asiakkaan vastuulla on esittää tavoitteet ja vaatimukset projektille prioriteettijärjestyksessä sekä hyväksyä toteutettu järjestelmä. Tekninen ohjaaja Lauri Svan on toteuttanut CoSCA simulaatorin nykyisen version ja hän on käytettävissä olemassa olevan toteutuksen teknisten ratkaisujen opastamisessa, sekä tulevan toiminnallisuuden suunnittelussa tekniseltä kannalta. Ohjelmiston käyttäjää projektissa edustaa joukko Helsingin Kauppakorkeakoulun opiskelijoita. Asiakaan vastuulla on auttaa etsimään vähintään kolme opiskelijaa, jotka tulevat olemaan käytettävissä projektin aikana (max. 5h/hlö). Käyttäjiltä pyritään kartoittamaan simulaattorin käyttöön liittyviä tarpeita ja lisäksi käyttäjät osallistuvat projektin puitteissa järjestettäviin käytettävyystesteihin. Mentor Kari Suhonen edustaa kurssin henkilökuntaan, auttaa projektiryhmää projektissa erityisesti kurssin suorittamiseen liittyvissä kysymyksissä sekä arvostelee palautukset. Taulukko 3. Muiden osapuolien yhteystietoja Rooli Nimi Puhelinnumero Sähköpostiosoite Asiakas Katariina Kemppainen 050-514 9749 katariina.kemppainen(at)hkkk.fi Tekninen ohjaaja Lauri Svan lauri.svan(at)hut.fi Mentor Kari Suhonen kari.suhonen(at)hut.fi 5
3 Tavoitteet ja lopetuskriteerit Seuraavissa kappaleissa kuvataan projektiryhmän ja asiakkaan asettamia tavoitteita projektille sekä projektin keskeytys ja lopetuskriteerit 3.1 Asiakkaan tavoitteet Taulukko 3 listaa asiakkaan tärkeimmät tavoitteet ja niiden hyväksyntäkriteerit prioriteettijärjestyksessä. Taulukko 4: Asiakkaan tärkeimmät tavoitteet Tavoite 1. Kyetä käyttämään järjestelmää opetuksen apuvälineenä HKKK:n tilaus-toimitus kurssilla sekä yritysyhteistyössä 1.1 Havainnollistaa tilaus-toimitus -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 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 Hyväksyntäkriteeri Kohtien 1.1-1.5 toteutuminen Järjestelmällä kykenee helposti luomaan erilaisia testitilanteita (= systeemeitä) Käyttöliittymän avulla kykenee ajamaan läpi erilaisia testitilanteita, joiden tulokset järjestelmä esittää opiskelijan ymmärtämässä muodossa. Käyttöliittymä ilmoittaa tilanteen valittujen muuttujien suhteen valittuna ajanhetkenä. Järjestelmä on niin helppokäyttöinen ja intuitiivinen, että käyttäjän ei tarvitse olla aihealueen asiantuntija. Käyttöliittymässä on mahdollisuus tarkastella ajon tilannetta tärkeimpien muuttujien suhteen tietyissä ajonaikaisissa pisteissä. 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 yliopistoopiskelijoille. 6
3.2 Projektiryhmän tavoitteet Projektiryhmän tavoitteet ja kriteerit, joilla nämä tavoitteet todetaan saavutetuiksi on listattuna taulukossa 5. Taulukko 5: Projektiryhmän yhteiset tavoitteet Tavoite Hyväksyntäkriteeri 1. Kurssin läpäiseminen Ryhmä saa kurssista hyväksytyn arvosanan 2. Saada aikaan asiakkaan tarpeita vastaava tuote 3. Saada käytännön kokemusta ohjelmistotuotteen toteuttamisesta iteratiivisesti ja inkrementaalisesti 4. Henkilökohtaiset oppimistavoitteet saavutetaan 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) 5. Kurssista saadaan arvosana 5 Ryhmän lopullinen arvosana kurssista on 5 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 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ä. 10. Tavoitteet on asetettu oikein suhteessa käytettäviin resursseihin Projektin tavoitteet saavutetaan ylittämättä kurssin asettamaa työpanosta (150 h tai 190h/ henkilö). 7
3.3 Henkilökohtaiset oppimistavoitteet Taulukossa 6 on lueteltu jokaisen ryhmän jäsenen henkilökohtaiset oppimistavoitteet. Taulukko 6: Henkilökohtaiset oppimistavoitteet Ryhmän jäsen Rooli Henkilökohtainen oppimistavoite Santeri Saarinen Samuel Korpi Kari Ylihärsilä Aleksi Airola Vesa Haukkavaara Laura Lehtola Elina Kontro Suunnittelija Suunnittelija Suunnittelija Suunnittelija Pääsuunnittelija Vaatimusmäärittelijä Projektipäällikkö Saada käytännön kokemusta tämän suuruusluokan (7 henkeä, 6kk) ohjelmistoprojektista. Projektissa haluaisin erityisesti saada kokemusta projektin laadunhallinnasta, dokumentoinnista, sekä projektin etenemisen seuraamisesta sille asetettujen vaatimusten näkökulmasta. Oppia paremmin hyödyntämään tarjolla olevia ohjelmistokehitystyökaluja (erityisesti Eclipse) erilaisissa ohjelmistokehitysprojekteissa. Kehittää olemassa olevia ryhmätyöskentelytaitojaan. Opettelen, miten 7-henkisen projektiryhmän toimintaa pyöritetään niin, että projekti kantaa hedelmää. Opin tuntemaan ohjelmistoprojekteja niin, että voisin muun koulutuksen avulla madollisesti konsultoida alalla. Opin ihmisten johtamisesta ja ohjelmistoarkkitehtuurin suunnittelusta niin, että selvästi koen olevani valmis näihin myös työtehtävissä. Odotan pääseväni soveltamaan opittuja asioita siinä laajuudessa, että se valmistaa työelämää varten. Olen perehtynyt jonkin verran käytettävyyteen ja on aika päästä kokeilemaan omia siipiään. Konkreettisina oppimistavoitteina on tutustuminen tarkemmin vaatimustenmäärittelyyn ja - hallintaan sekä Eclipse kehitysympäristön ja sen plug-inien kokonaisvaltaisempi hallitseminen. Tärkein tavoitteeni on oppia käyttöliittymä- ja käytettävyyssuunnittelun perusteet sekä käytettävyystestauksen asioita. Toinen tavoitteeni on syventää osaamistani oliopohjaisen järjestelmän suunnittelutavoissa. Lisäksi toivon projektin suorittamisen välillisesti tukevan tuotantotalouden opintojani. Saada käytännön kokemusta käyttäjälähtöisestä vaatimusmäärittelytyöstä tiiviissä yhteistyössä asiakkaan kanssa, sekä oppia lisää asiakkaan odotuksien hallitsemisesta ja asettamisesta oikealle tasolle. Oppia lisää menestyksellisestä toimimisesta asiaorientoituneen asiakkaan ja teknisesti orientoituneiden kehittäjien välillä. Saada kokemusta ohjelmistokehitysprojektin vetämisestä Käytettävyys-näkökulman soveltaminen käytännön projektissa 8
3.4 Projektin keskeytyskriteerit Projekti keskeytetään projektiryhmän, asiakkan ja mentorin yhteisellä päätöksellä, mikäli kaksi tai useampi projektiryhmän jäsen jättää projektin kesken tai mikäli asiakas lopettaa yhteistyön projektiryhmän kanssa. 3.5 Projektin lopetuskriteerit Projekti loppuu, kun jokin seuraavista kriteereistä täyttyy: Kurssi päättyy aikataulunsa mukaisesti Asetettuja tavoitteita vastaava tuote on toimitettu asiakkaalle, ja asiakas on sen hyväksynyt Asiakas hyväksyy projektin päättyneeksi muista syistä 9
4 Resurssit ja budjetti Seuraavassa kuvataan projektin suunnitellut resurssit ja budjetti. 4.1 Henkilöt Projektin työmääräarviot vaiheittain kullekin henkilölle on esitetty taulukossa 7. Työmääräarvioita päivitetään, kun todelliset työmäärät selviävät ja myöhempien vaiheiden suunnittelu tarkentuu. Koko projektissa yksittäisen henkilö työmäärä kokonaisuudessaan on joko 150h tai 190h. Laajempi työmäärä pitää sisällään SEPA-työn. Taulukko 7: Projektin työmääräarviot PP iteraatiossa vaiheittain Elina Kontro Laura Lehtola Kari Ylihärsilä Aleksi Airola Vesa Haukkavaara Samuel Korpi Santeri Saarinen Yhteensä PP 88 80 78 23 22 23 23 337 I1 52 40 55 85 80 80 80 452 I2 50 30 57 82 88 87 87 461 Yhteensä 190 150 190 190 190 190 190 1290 Taulukko 8: Projektin työmääräarviot I1 iteraatiossa henkilöittäin (PP kohdassa toteutuneet) Elina Kontro Laura Lehtola Kari Ylihärsilä Aleksi Airola Vesa Haukkavaara Samuel Korpi Santeri Saarinen Yhteensä PP toteutunut 82,5 76 72 25,5 13,5 19 28 316,5 I1 86,5 54,5 83 92 116 79,5 88 599,5 I2 21 19,5 35 72,5 60,5 91,5 74 374 Yhteensä 190 150 190 190 190 190 190 1290 4.2 Materiaalihankinnat Työn tekeminen ei edellytä erityisiä ohjelmisto- tai laitteistohankintoja. Projektissa tullaan käyttämään omia sekä SoberIT -laboratorion laitteistoja, sekä ohjelmistoja jotka ovat joko open source tuotteita tai käytettävissä SoberIT -laboratorion tai TKK:n ATK-keskuksen puolesta. 10
4.3 Budjetti Taulukossa 8 on esitetty projektin teoreettinen budjetti, jonka tarkoituksena on havinnollistaa mitä tämän kokoinen projektin todellisuudessa voisi maksaa. Projektiryhmän työstä ei todellisuudessa laskuteta, joten se ei aiheuta kuluja asiakkaalle. Taulukko 8: Projektin arvioitu budjetti Kustannuserä Työmääräarvio Palkkio/h Kustannukset Asiakkaan SoberIT:lle maksama summa 3 000 Asiakkaan projektiin käyttämä aika 100 h 50 5 000 Projektiryhmän työ 1 290 h 50 64 500 Kustannukset yhteensä 72 500 11
5 Työkäytännöt ja työkalut Tässä kappaleessa kuvataan projektissa käytettävät työkäytännöt sekä työkalut. Osa käytännöistä on pakollisia kurssin puolesta ja osa on erikseen valittu helpottamaan projektin kulkua. 5.1 Käytännöt Seuraavissa kappaleissa on kuvattu projektissa noudatettavat käytännöt. Lisäksi luvussa 5.2 on listattu SEPA - käytännöt, joita projektissa käytetään. 5.1.1 Iteratiivinen kehitys Projektissa tuotettava ohjelmisto toteutetaan käyttäen iteratiivista ja inkrementaalista kehitysmallia. Projekti koostuu kolmesta iteraatiosta, joita ovat projektin suunnittelu (PP), toteutusiteraatio 1 (I1) sekä toteutusiteraatio 2 (I2). Vaiheiden tavoitteet, tehtävät ja aikataulut on kuvattu tarkemmin kappaleessa 6 Vaiheistus. I1-iteraatiossa pyritään toteuttamaan asiakkaan vaatimusten mukaiset keskeisimmät ominaisuudet siten, että iteraation lopussa pidettävässä iteraatiodemossa esitetään testattu ja toimiva sovellus. I2-iteraatiossa sovellukseen lisätään toiminnallisuutta iteraation alussa tehtävän suunnitelman mukaisesti. Toteutusiteraatiot voidaan vielä sisäisesti jakaa seuraaviin päävaiheisiin: suunnittelu, toteutus, testaus ja iteraatio demo. Toteutusiteraatiot toteutetaan käytänössä vähintään kahdessa kehityssyklissä, jolloin totetustehtävien osalta tavoitteet asetetaan erikseen näille kehityssykleille ja syklien välissä pidetään ns. välietappikatselmus, jossa tavoitteet ja niiden tilanne tarkastetaan sekä tehdään tarvittavat korjaustoimenpiteet. Tarkemmin iteraatioiden sisäinen vaiheistus aikatauluineen on kuvattu kappaleissa 6.2 Toteutusiteraatio 1 ja 6.3 Toteutusiteraatio 2. 5.1.2 Iteraation suunnittelu Iteraation tarkempi suunnittelu tehdään ko. iteraation alussa. I1 ja I2 iteraatioiden suunnittelu tehdään yhdessä asiakkaan kanssa edellisen vaiheen iteraatiodemon jälkeen. Iteraation suunnittelupalaverissa projektiryhmä esittää alustavan ehdotuksen tulevalle iteraatiolla työmääräarvioineen. Asiakas voi esittää muutoksia ja asiakas on vastuussa iteraatioon valittujen vaatimusten asettamisesta toteutusjärjestykseen. Asiakaspalaverin jälkeen, iteraation ensimmäisen viikon aikana suunnitelmaa ja työmääräarvioita tarkennetaan. Suunnittelijat osallistuvat suunnitelman tekemiseen ja työmäärien arviointiin I1 ja I2-iteraatioiden osalta. Iteraation suunnitelmat päivitetään tämän dokumentin lukuun 6. Vaiheistus. Ennen virallista aikataulun mukaista palautusta lähetetään suunnitelma asiakkaalle katselmoitavaksi. 12
5.1.3 Dokumentointi Projektissa tuotettava dokumentaatio palautetaan viimeistään sille määriteltynä palautuspäivänä sekä asiakkaalle että mentorille. Dokumentit lähetetään asianosaisille sähköpostitse PDF-formaatissa. Lisäksi dokumentit julkaistaan projektiryhmän kotisivulla. Projektissa käytettävä dokumentointikieli on suomi, paitsi teknisen spesifikaation, käyttäjän käsikirjan sekä koodin kommentoinnin osalta, jotka tulee tehdä englannin kielellä. Projektissa tuotettava dokumentaatio, vastuuhenkilöt ja dokumenttien palautuspäivämäärät on koostettu taulukkoon 9. Mikäli dokumentti katselmoidaan, on katselmoinnit myös merkitty. Taulukkoa päivitetään projektin edetessä kunkin vaiheen osalta. Vastuuhenkilöt huolehtivat siitä, että päivitetyt dokumentin päivitetään myös ryhmän kotisivulle. Taulukko 9. Dokumentit ja niiden vastuuhenkilöt PP Päävastuu Katselmointi pvm Katselmointi ryhmä Palautus pvm Projektisuunnitteluvaiheen Elina Kontro 3.10.2005 suunnitelma Projektisuunnitelma Elina Kontro 14.10.2005 Asiakas, 17.10.2005 Projektiryhmä Vaatimusmäärittely Laura Lehtola 15.10.2005 Asiakas, Projektiryhmä 17.10.2005 Tilannekatsausraportti Elina Kontro 18.10.2005 Managementtiimi 19.10.2005 Kehitystyöohjeistus Kari Ylihärsilä 17.10.2005 SEPA: Käyttäjätestit Elina Kontro 17.10.2005 SEPA: Coding Camp Kari Ylihärsilä 17.10.2005 I1 I1-iteraation suunnitelma Elina Kontro 29.10.2005 Managementtiimi 31.10.2005 Projektisuunnitelma Elina Kontro 1.12.2005 Managementtiimi 5.12.2005 Laadunvarmistussuunnitelma Santeri Saarinen 30.11.2005 Vesa, Samuel 5.12.2005 -sisältää Testaussuunnitelman I1 Tekninen määrittely Vesa Haukkavaara 30.11.2005 Kari, Santeri, 5.12.2005 Samuel Vaatimusmäärittely Laura Lehtola 30.11.2005 Elina, Vesa, 5.12.2005 Santeri Tilannekatsausraportti Elina Kontro 2.12.2005 Managementtiimi 5.12.2005 SEPA : Coding Camp Kari Ylihärsilä - - 5.12.2005 Samuel Korpi SEPA : Saattiset Menetelmät Santeri Saarinen - - 5.12.2005 SEPA: Käytettävyydenarvointi Aleksi Airola Vesa Haukkavaara Elina Kontro - - 5.12.2005 13
Käyttöliittymän paperiproto Aleksi Airola - - 27.10 I2 Projektisuunnitelma Elina Kontro 13.1.2006 Managementtiimi 18.1.2005 Laatusuunnitelma Santeri Saarinen 13.1.2006 Vesa, Kari 18.1.2005 Tekninen määrittely Vaatimusmäärittely Vertaisryhmän testiraportti Vertaisryhmän Käyttäjän käsikirja Loppuraportti Tilannekatsausraportti Vesa Haukkavaara Laura Lehtola Elina Kontro Elina Kontro SEPA : Coding Camp Kari Ylihärsilä - - Samuel Korpi SEPA : Saattiset Menetelmät Santeri Saarinen - - SEPA: Käytettävyydenarvointi SEPA päiväkirjat Aleksi Airola Vesa Haukkavaara Elina Kontro - - 5.1.4 Riskienhallinta Projektin riskienhallintaan käytetään kevennettyä ja modifioitua versiota Jyrki Kontion kehittämästä Riskit menetelmästä. Projektiin liittyvät keskeisimmät riskit pyritään tunnistamaan heti projektin alussa ja lisäksi yksittäisiin iteraatioihin liittyvät riskit tunnistetaan jokaisen iteraation aloituspalaverissa. Yleisimpien riskien osalta niiden tilaa monitoroidaan kerran kunkin iteraation aikana sen puolivälissä olevassa viikkopalaverissa. Mikäli jonkin riskin realisoitumisesta havaitaan merkkejä, analysoidaan sitä tarkemmin ja se otetaan erityistarkkailun alle. Riskilokia päivitetään kunkin seurantapalaverin yhteydessä. Projektin riskienhallintakäytäntö koostuu seuraavista askeleista: Uhkien tunnistaminen Uhkien syiden tunnistaminen Uhkien todennäköisyyden arviointi Uhkien vaikutusten arviointi Riskejä vähentävien toimien käyttäminen Riskitilanteen seuranta 14
Tunnistetut uhat kootaan riskilokiin (Luku 7). Lokiin merkitään erikseen myös se, mikäli riski liittyy johonkin tiettyyn projektin vaiheeseen. 5.1.5 Tuntiraportointi Työtuntien raportointiin käytetään Excelillä tehtyä taulukkoa. Kullakin ryhmän jäsennellä on oma Excel - tiedosto, johon tunnit raportoidaan ja johon jokainen huolehtii omien tuntiensa raportoinnista. Tiedostossa on oma sivunsa jokaiselle iteraatiolle. Tiedostoja säilytetään ryhmän TikiWiki sivuilla. Tunnit tulee raportoida päivittäin, mieluiten heti suoritetun tehtävän jälkeen. Jokaisen viikon maanantaina klo 12:00 tulee edellisen viikon tuntien olla ajan tasalla. Tämän jälkeen projektipäällikkö koostaa yhteenvedon raportoiduista tunneista ja kooste julkaistaan tiistaina projektiryhmän www-sivuilla. Tuntiraportointikoosteen perusteella tarkistetaan, onko tarvetta tehdä muutoksia esim. iteraation työmääräarvoihin, työtehtävien jakamiseen tai suunniteltuun toteutustoiminnallisuuteen. 5.1.6 Ohjelmakoodin koon raportointi Ohjelmakoodin koosta pidetään kirjaa koodirivien määrän perusteella (LOC ja NCLOC). Koodirivien määrä on helposti mitattavissa oleva, muihin projekteihin suhteuttamiskelpoinen elementti. Arkkitehtuurikaavio auttaa ymmärtämään ohjelman kompleksisuutta koodirivien määrää paremmin, ja antaa kokonaiskuvan ohjelman rakenteesta, mutta ei suranaisesti auta ohjelmakoodin koon raportointia. 5.1.7 Kommunikointi ja palaverikäytännöt Kaikkiin ennalta sovittuihin palavereihin tulee olla agenda, joka toimitetaan osallistujille etukäteen. Palaverin alussa agenda käydään läpi ja tehdään tarvittaessa muutoksia. Viikkopalavereiden yhteydessä erillistä agendaa ei tarvitse lähettää, sillä palaverin agenda sovitaan aina edellisessä palaverissa. Kaikista palavereista tehdään pöytäkirjat, joihin kirjataan tärkeimmät päätökset. Pöytäkirjat tallennetaan TikiWikiin ryhmän kotisivuilla niille varattuun paikaan. Projektiryhmän sisäinen kommunikointi Projektinsuunnitteluiteraation aikana management -ryhmä kokoontuu viikkopalavereihin, jossa käydään läpi suunnittelua, tarkistetaan kunkin tehtävien eteneminen ja sovitaan seuraavat toimenpiteet. Tämän vaiheen aikana suunnittelijat pidetään ajan tasalla tärkeimmistä päätöksistä ja tapahtumista lähettämällä vähintään kerran viikossa tiedotuksia sähköpostitse. Suunnittelijoille järjestetään myös projektin käynnistyspalaveri PPiteraation aikana. I1 iteraatioissa alussa noudatettiin myös viikkopalaverikäytäntöä, tästä käytännöstä luovuttiin heti, kun se töiden etenemisen kannalta oli mahdollista. Viikkopalaverin tilalla pidetään tiistaisin 9-12 SEPA aiheen mukainen Coding Camp (kts. Luku 5.5.1). Tarvittaessa Coding Campin alussa pidetään lyhyt palaveriosuus esim. informoidaan projektiin liittyvisät yleisistä asoista. 15
Tarpeen mukaan järjestetään myös muita palavereita (kts. Esim. luku 5.1.8 Pienryhmät). Palaverien lisäksi ryhmän sisäiseen kommunikointiin käytetään sähköpostia ja kiireellisiä asioita sovitaan myös puhelimitse. Dokumentaation tallentamiseen ja jakamiseen ryhmän sisällä käytetään TikiWikiä. Toteutustyötä tukemaan on avattu ryhmälle oma IRC-kanava. I2:n osalta palaveri käytönnösitä sovitaan vielä erikseen, kunhan projektiryhmänjäsenten muu aikataulu IIIopintojakson aikana. Kommunkointi projektiryhmän ulkopuolelle Asiakkaan, teknisen ohjaajan ja mentorin kanssa kommunikoidaan sähköpostitse sekä tarvittaessa järjestetään yhteisiä palavereita. Mentorin kanssa palavereita järjestetään vähintään yksi jokaisessa iteraatiossa. Asiakkaalle, tekniselle ohjaalle ja mentorille tarjotaan pääsy projektissa tuotettavaan materiaalin, kuten esim. vaatimusmäärittely, projektisuunnitelma ja yhteisten palaverien pöytäkirjat. Ko. dokumentit jaetaan joko TikiWikin tai erillisten www-sivujen kautta. Projektin vastuuhenkilö asiakkaan suuntaan on Laura Lehtola. Hänen tehtävänsä on sopia asiakkaan kanssa tarvittavista tapaamisista ja toimista, sekä monitoroida asiakkaan tyytyväisyyttä ja pitää huolta siitä, että projekti on asiakkaan näkökulmasta menossa oikeaan suuntaan. Projektin vastuuhenkilö mentorin suuntaan on Elina Kontro. Kommunikaatiosta teknisen ohjaajan kanssa vastaa Vesa Haukkavaara. 5.1.8 Pienryhmät PP-iteraation loppupuolella projektiryhmä jaetaan kolmeen ns. pienryhmään. Pienryhmätoiminnan tarkoituksena ottaa suunnittelijat mukaan suunnittelutehtäviin PP-iteraation aikana ja tämän avulla myös tehostetaan I1- iteraation käynnistymistä. Nyt sovitut pienryhmät ovat toiminnassa vähintään I1-iteraation alussa, mutta tarvittaessa vastuualueestaan riippuen myös I2-iteraation aikana. Ryhmät raportoivat edistymisestään viikkopalavereissa. Taulukkossa 10 on lueteltu sovitut pienryhmät ja niiden kokoonpanot. Ryhmien tuotosten aikataulut noudattavat projektin aikatauluja. Taulukko 10. Pienryhmät Pienryhmän vastuualue Tuotos Vaiheet Ryhmän jäsenet Arkkitehtuurin suunnittelu Käyttöliittymäsuunnittelu Laadunvarmistussuunnittelu Arkkitehtuurisuunnitelma Ns. Paperiprototyyppi järjestelmän käyttöliittymästä Käyttöliittymäsuunnittelua Laatusuunnitelma (Testaussuunnitelma) I1 I1 I1,I2 Vesa Haukkavaara Kari Ylihärsilä Samuel Korpi Laura Lehtola Aleksi Airola Elina Kontro Santeri Saarinen Elina Kontro 16
Myöhemmin ryhmien kokoonpanoja voidaan muuttaa ja tarvittaessa voidaan sopia kokoaan uusia pienryhmiä. 5.1.9 Katselmointikäytäntö Projektin katselmoinnit toteutetaan alla kuvatun kaltaisena ns. kevyenä katselmointina. Varsinaisia katselmointipalavereita ei käytettävissä olevilla resursseilla ja aikataululla tulla pitämään. Projektin sisäinen katselmointiprosessi on viisivaiheinen ja se on esitetty seuraavassa numeroidussa listassa. 1) Jokaiselle projektissa tuotettavalle dokumentille määritellään vastuuhenkilö ja katselmointiryhmä. (Termillä dokumentti tarkoitetaan myös iteratiivisesti kehitettävän dokumentin uutta toimitettavaa versiota.) 2) Dokumentille määritellään palautuspäivämäärä sekä katselmointiajankohta. 3) Tuotettavan dokumentin vastuuhenkilö on velvollinen toimittamaan dokumentin katselmoitavaksi katselmointiryhmän jäsenille vuorokautta ennen katselmointiajankohtaa. 4) Katselmointiryhmän tehtävänä on katselmoida dokumentti seuraavista näkökulmista: Pienet puutteet, suuret puutteet, virheet, heränneet kysymykset. Katselmointikommentit lähetetään sähköpostilla dokumentin kirjoittajalle, joka koostaa saapuneet kommentit yhteen tiedostoon ja tallentaa sen ryhmän TWikiin Katselmointidokumentaatio-galleriaan. 5) Dokumentin vastuuhenkilö määrittää palautettujen kommenttien perusteella, miten ongelmat korjataan siten, että saadaan palautettua hyvä versio dokumentista. Kun korjaukset on tehty, ilmoitaa dokumentin vastuuhenkilö dokumentin uudesta versiosta sähköpostitse ryhmän jäseniä. Taulukossa 9 (kts. 5.1.3 Dokumentointi) on lueteltu katselmoitavilla dokementeille katselmointipäivä ja katselmointiryhmä. Osa dokumenteista lähetetään myös asiakkaan katselmoitavaksi. Edellä kuvatun käytännön mukaisesti katselmoitava dokumentti lähtetään katselmointiryhmälle viimeistään vuorokautta ennen määriteltyä katselmointipäivää ja kommentit lähetetään dokumentin vastuuhenkilölle viimeistään katselmointipäivää seuraavana päivänä. 5.1.10 Iteraatiodemot Iteraatiodemo toteutetaan kurssin ohjeistuksen mukaisesti. Projektipäällikkö valmistelee kalvoesitysmuotoon tilannekatsausraportin ennen iteraatiodemoa niin, että se voidaan katselmoida demoa edeltävässä viikkopalaverissa. Ohjelmiston toiminnallisuuden demonstroinnista I1 ja I2 iteraatiodemoissa vastaa pääsuunnittelija. Iteraatio demossa esitettävän sovelluksen version tulee olla, esitysmateriaalin tavoin, läpikäytävissä demoa edeltävässä viikkopalaverissa. 17
Iteraatiodemon päivämäärät on asetettu kurssin puolesta ja iteraatiodemot pidetään Innopoli2:ssa SoberITtiloissa. Tarkemmat kellonajat ehdotetaan myös kurssin puolesta ja ovat nähtävissä kurssin kotisivuilla. Asiakasyhteyshenkilö varmistaa ajan sopimisen asiakkaalle ja tekniselle ohjaajalle. PP iteraation demo pidetään 19.10 klo 13 ja I1-iteraation demo pidetään 7.12 klo 13. Iteraatio demojen paikkan on Innopoli 2. Projektipäällikön vastuulla on, että katselmointitilaisuudessa pysytään aikataulussa ja kaikki olennaiset asiat saadaan esitettyä. 5.1.11 Vikojen seuranta Vikojen seurantaan käytetään julkisesti saatavilla olevaa Bugzilla-työkalua (www.bugzilla.org). Yksityiskohtainen ohje Bugzillan käytöstä tehdään I1 iteraation alussa tehtävään erilliseen työkaluohje-dokumenttiin. 5.1.12 Versionhallinta Projektin versionhallintatyökaluna käytetään CVS-versionhallintajärjestelmää. Repositorio sijaitsee ryhmän yhteisen työhakemiston alle ATK-keskuksella ja järjestelmään kytkeydytään suoraan Eclipsen kautta. Versionhallinnan käyttämisestä on tarkempi ohje TikiWikissä olevassa työkaluohjeessa. 5.1.13 Koodauskäytäntö Ohjelmointi tehdään Javalla. Javan koodauskäytäntöinä käytetään Sunin määrittelemää Javakoodauskonventiota (http://java.sun.com/docs/codeconv), josta tehdään lyhyt yhteenveto-ohje työkaluohjeisiin. Monen suunnittelijan projektissa koodin selvä kommentointi (kriteerinä: ymmärtävätkö muut?) nousee tärkeään asemaan, tämä on myös vaatimus jatkokehtitettävyyden helpottamiseksi. Tästä syystä koodin tulee olla kommentoitua ennen CVS:n laittamista. Ei-itsestäänselvien metodien ja kenttien lisäksi kommentoidaan ratkaisun vieressä myös ongelmissa käytettyjä ratkaisutapoja. Lisäksi ohjelmakoodin kommentteihin upotetaan viestejä, ehdotuksia ja kysymyksiä toisillemme TODO-ja FIXME tagien tapaan. Tähän käytetään KYS: -tageja paikallistamaan kysymykseen relevanttia koodia. KYS: -tagin perään voidaan kirjoittaa henkilön nimi, kenelle kysymys on osoitettu ja kysymyksen perään oma nimi, jotta kysymyksen saaja voi halutessaan vastata suoraan kysyjälle. Tagin ja kysymyksen vastaanottajan nimen väliin laitetaan kaksoispiste, mutta ei välilyöntiä. Tämä sen takia, että kehittäjien on helppo etsiä vakiomuotoisella tavalla koodista itselleen osoitettuja kysymyksiä. Esimerkkejä: o //KYS:Samuel Miten luokkien tyyppihierarkia tarkistetaan? Kari o //TODO:Kari Koko puurakenteen läpikäynti. -Kari 18
5.1.14 Vertaistestaus Vertaistestaus tehdään kurssin ohjeiden mukaisesti I2 iteraatiossa ja siitä laaditaan tarkempi suunnitelma ko. iteraation alussa. 5.1.15 Vaatimusten määrittely ja hallinta Vaatimusmäärittely on silta asiakkaan ja projektiryhmän välissä. Siksi vaatimusten määrittelyyn ja hallintaan kiinnitetään erityistä huomiota projektin aikana ja sitä pyritetään tekemään mahdollisimman paljon yhteistyössä asiakkaan kanssa. 5.1.15.1 Hankinta Projektin asiakas- ja käyttäjätarpeet hankitaan iteratiivisesti. Tarpeiden kartoitus aloitetaan asiakkaan korkeantason tavoitteiden ja projektin tärkeimpien käyttäjäryhmien selvittämisestä ja priorisoinnista. Näiden perusteella tehdään käyttäjätutkimus simulaattorin toistaiseksi ainoalla käyttäjällä, joka on myös tämän projektin asiakas. Käyttäjätutkimuksessa seurataan simulaattorin käyttöä sen todellisessa käyttöympäristössä, sekä pyydetään käyttäjää mm. kuvailemaan tekemiään toimia ja toiminnan vaiheita sanallisesti käyttäjän termistön selvittämiseksi. Edellisten aktiviteettien tulosten pohjalta tehdään vaatimusmäärittelyn ensimmäinen versio sekä käyttöliittymäprototyyppi, josta haetaan palautetta asiakkaalta ja jota testataan tärkeimmällä käyttäjäryhmällä, opiskelijakäyttäjillä. 5.1.15.2 Analysointi ja priorisointi Hankittuja vaatimuksia analysoidaan kolmesta näkökulmasta, joiden perusteella niille annetaan toteutusprioriteetti (= vaihe). Näkökulmia ovat: tärkeys asiakkaalle, kiireys arkkitehtuurin kannalta ja toteutuskustannukset Tärkeyttä asiakkaalle arvioidaan neliportaisella asteikolla (1-4), joista kaikista ylimpään luokkaan asiakas saa asettaa korkeintaan 20% vaatimuksista. Kiireyttä arkkitehtuurin kannalta ja toteutuskustannuksia arvioidaan kolmiportaisella asteikolla. Nämä arviot tekee projektiryhmä. Toteutuskustannusten arvioinnissa otetaan huomioon kaikki vaatimuksen eteen tehtävä työn määrittelystä testaukseen ja käyttöohjeiden kirjoittamiseen. Jokaisen iteraation alussa valitaan arvioitujen näkökulmien perusteella yhdessä asiakkaan kanssa vaatimukset, jotka iteraation aikana tullaan toteuttamaan. Asiakkaan on asetettava vaatimukset asetetaan kolmeen prioriteettiluokkaan siten, että korkeimpaan prioriteettiluokkaan asiakas saa asettaa ainoastaan 20% vaatimuksista, ja toisiksi korkeimpaan 50%. Alimman luokan prioriteetteja suhteessa toisiinsa tarkennetaan iteraation aikana asiakaspalaverissa mikäli tarpeellista. 19
5.1.15.3 Toteutusiteraatioiden aikainen vaatimustenhallinta Iteraation alussa toteutettaviksi valittuja käyttötapauksia tarkennetaan yksityiskohtaisiksi käyttötapauksiksi. Kaikentyyppisten vaatimusten tilaa monitoroidaan koko projektin ajan. Mahdolliset tilat vaatimukselle on esitetty taulukossa 11. Taulukko 11: Vaatimusten tilat ja niiden kuvaus Tila Kuvaus Ehdotettu Vaatimus on esitetty ja jossakin määrin analysoitu ohjelmiston kannalta olennaiseksi, mutta ei vielä hyväksytty mihinkään toteutusiteraatioon. Hyväksytty ieraatioon X Vaatimus on sovittu toteutettavaksi iteraatiossa x. Toteutettu Vaatimus on toteutettu, mutta sitä ei vielä ole testattu. Testattu Vaatimus on testattu ja projektiryhmän näkökulmasta valmis. Toimitettu Vaatimus on toteutettu asiakkaalle, joka sen on hyväksynyt. Hylätty Vaatimus on hylätty. 5.1.16 Asiakas- ja käyttäjänäkökulman varmistaminen projektin aikana Asiakkaan ja käyttäjän äänen kuulumiseksi ja säilymiseksi koko projektin ajan kiinnitetään erityistä huomiota. Keskeistä tämän asian varmistamiseen on tiivis yhteistyö asiakkaan kanssa koko projektin kanssa. Lisäksi tämä varmistetaan iteraatiokohtaisilla toimenpiteillä, joista keskeisimmät on lyhyesti lueteltu seuraavassa. Projektisuunnittelu iteraatio 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 Tiivis yhteistyö asiakkaan kanssa tärkeimpien käyttäjäryhmien ja heidän keskeisten tarpeidensa selvittämiseksi 20
Asiakkaan osallistuminen vaatimusmäärittelyyn iteratiivisesti (raakaversioiden komentointi + puhelinkeskustelut) Toteutusiteraatio 1 Käyttöliittymäprototyypin kehittäminen palautteen saamiseksi. Prototyyppi tehdään quick and dirty tyylisesti Eclipsen käyttöliittymätyökalulla siten, että se ei ole kiinni nykyisen simulaattorin koodissa. Käyttöliittymäprototyypin testaus. Testihenkilöinä 2 opiskelijakäyttäjää. Iteraation lopussa käyttäjätestit simulaattorin senhetkisellä versiolla (2 opiskelijakäyttäjää). Toteutusiteraatio 2 On-line helpin rakentaminen Käyttöohjeen kirjoittaminen 21
5.2 Laadunvarmistussuunnitelma Projektin laadunvarmistussuunnitelma kuvataan erillisessä Laadunvarmistussuunnitelma-dokumentissa (viite). 5.3 Työkalut Projektissa käytetään seuraavia työkaluja. 5.3.1 Kehityslaitteisto Projektissa tuotettavan ohjelmiston kehittämiseen ei tarvita mitään erikoislaitteistoa. Tavallinen kotitietokone (teholuokkaa P4 2,6 Ghz, 512Mb muistia) riittää hyvin. Ohjelman kehitys tapahtuu sekä ryhmän jäsenten omilla tietokoneilla, että SoberIT:n tietokoneilla. Kaikki käytettävät työkalut ovat joko open source -tuotteita tai ne on saatavilla TKK ATK-keskuksen tai SoberITlaboratorin puolelta. Borlandin Together Architectia, tarjotaan käyttöön projektin ajaksi kurssin puolesta. 5.3.2 Ohjelmistot Eclipse 3.1 Kehitysympäristö: Tulee Together Architectin mukana. Lisätietoa: http://www.eclipse.org Borland Together Architect: Ladataan kurssin kotisivuilta Työkalut -osiosta. http://www.soberit.hut.fi/t-76.115/ Sun Java Java 2 Platform Standard Edition 5.0 Development Kit (JDK) http://java.sun.com/j2se/1.5.0/download.jsp (JDK 5.0 Update 5 Paketti) CVS Versionhallintatyökalu: Sisältyy Eclipseen Apukirjastot: Nämä tulevat ohjelmakoodin mukana. o Groovy-skriptauskieli: Groovy 1.0 JSR-03 tai uudempi (esim. groovy-1.0-jsr-03.zip osoitteesta http://dist.codehaus.org/groovy/distributions/) o COLT-matematiikkakirjasto: Colt 1.2.0 (esim. colt-1.2.0.zip osoitteesta http://dsd.lbl.gov/~hoschek/colt-download/releases/) o Commons Beanutils-apukirjasto: Beanutils 1.7.0 (esim. commons-beanutils-1.7.0.zip osoitteesta http://jakarta.apache.org/site/downloads/downloads_commons-beanutils.cgi) o Commons Logging-apukirjasto: Logging 1.0.4 (esim. commons-logging-1.0.4.zip osoitteesta http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi) o Commons Digester-apukirjasto: Digester 1.7.0 (esim. commons-digester-1.7.zip osoitteesta http://jakarta.apache.org/site/downloads/downloads_commons-digester.cgi) Bugzilla 2.20: http://www.bugzilla.org/download/ 22
Ohjelmaprojektin toteuttamiseen käytetään Javaa, kehitysympäristönä Eclipse 3.1. Borlandin Together Architectia käytetään ohjelmistoarkkitehtuurin suunnittelussa. Graafisista käyttöliittymäeditoreista käyttöliittymän toteuttamisessa käytetään Eclipsen lisäpalikkana: Jigloo SWT/Swing GUI Builder for Eclipse and WebSphere 3.5.2 http://www.cloudgarden.com/jigloo/ 5.3.3 Kehitystyökalut Versionhallinta Versionhallintaan ja ohjelmakoodin säilyttämiseen käytämme CVS-versionhallintajärjestelmää. Repositorio asennetaan TKK:lle ryhmän yhteiseen kansioon. Tähän kansioon on kaikilla ryhmäläisillä luku-, suoritus- ja kirjoitusoikeudet. Tiedostot haetaan ja tallennetaan Eclipsen kautta repositorioon. Uusia tiedostoja luotaessa ryhmäläisten on muistettava erikseen jakaa oikeudet koko ryhmälle näihin tiedostoihin. Vain toimivaa ohjelmakoodia saa laittaa repositorioon. CVS:stä ja sen käytöstä tehdään yksityiskohtainen ohjeet I1-iteraation alussa kirjoitettavassa erillisessä työkaluohjeessa. Projektiryhmää varten on luotu ATK-keskuksen UNIX-järjestelmään a-teamdc niminen ryhmä, johon kuuluvat kaikki projektiryhmän jäsenet. Ohjelmointi Java-kehitysympäristönä käytetään Eclipse 3.1:htä, Javasta versiota 5.0. Lisäksi käytetään jotakin yllämainituista Eclipsen lisäpalikoista käyttöliittymän toteuttamisessa. Luokkakaaviot Borlandin Together Architect-työkalua käytetään luokkakaavioiden piirtämisessä ja ohjelmistoarkkitehtuurin suunnittelussa. Käännös Ohjelma käännetän suoraan Eclipsestä. Jos myöhemmin on tarkoituksenmukaista, otetaan myös ant - käännöstyökaluksi monimutkaisempiin asioita, kuten ohjelman paketointia varten. Vikaraportointi Vikaraportointiin käytetään Bugzilla-työkalua. Kommunikointi Ryhmän sisäiseen kommunikointiin käytetään Wiki-ympäristöä. Wikiin laitetaan asioita kuten dokumenttien uusia versioita muutoslogeineen. Nopeaan yleiseen asioista tiedottamiseen käytetään sähköpostia. Asiakkaalla on 23
käytettävissä ryhmän kotisivu ja mentorille on pääsy ryhmän Twiki sivuilla. Sähköpostin otsikoissa käytetään [TeamDC] tagia tunnistamaan projektin sisäiset viestit. Projektiryhmällä on yhteistä palaveriaikaa tiistaisin klo 9-12. I1-Iteraartion alussa tämä jakautuu ensin tunnin manageripalaveriin, sitten kaikkien yhteiseen osioon ja lopuksi kehittäjien omaan osioon. Nyt palaveri aika käytetään Coding Camp tarkoitukseen ja varsinainen lyhyt palaveri osuus pidetään vain tarvittaessa. Tuntiseuranta Tuntiseurantaan käytetään Excelillä tehtyä taulukkoa. Tarkemmat ohjeet tuntiseurannasta on kuvattu kohdassa 5.1.5 tuntiraportointi. 5.4 Standardit Projektissa käytetään Sunin Java-ohjelmointikonventioita, joka on lyhyesti määritelty ryhmän työkalu-ohjeessa. Linkki koko dokumenttiin löytyy täältä: http://java.sun.com/docs/codeconv/html/codeconvtoc.doc.html Käyttöliittymäsuunnittelussa pyritään noudattamaan Nielsenin (5) kymmentä käytettävyysheuristiikkaa, jotka ovat: Yksinkertainen ja luonnollinen kieli, Puhu käyttäjän kieltä, Minimoi käyttäjän muistikuorma, Yhdenmukaisuus, Palaute, Selvästi merkityty poistumistiet, Oikopolut, Hyvät virheilmoitukset, Virheiden estäminen ja Opastus ja ohjeistus. 5.5 SEPA -työt Osa projektiryhmän jäsenistä suorittaa projektin ohessa T-76.5633 Ohjelmistotuotannin erikoiskurssia, jossa perehdytään johonkin ohjelmistonkehityskäytäntöön ja sovelletaan sitä tähän ohjelmistoprojektiin. Aiheen voi valita joko kurssin ehdottamista vaihtoehdoista tai omasta aiheesta, joka on kuitenkin hyväksytettävä mentorilla. Työ toteutetaan tekemällä ns. SEPA päiväkirja, jonka työmäärä on noin 20h/henkilö sekä tekemällä 20h/henkilö lisätyötä ohjelmistokehitysprojektiin. Projektiryhmän SEPA-työt tehdään työpareina ja oheisessa taulukossa 12 on listattu ryhmän SEPA aiheet. Aiheista ensimmäinen on ns. oma aihe, muut kaksi kurssin puolesta ehdotettuja aiheita. Aiheet on valittu niin, että niiden on katsottu olevan hyödyllisiä projektin kannalta. Seuraavissa luvuissa on lyhyt kuvaus valituista aiheista. Tarkemmat kuvaukset ja valintaperusteet kuvataan kunkin aiheen erillisessä dokumentissa, SEPA päiväkirjassa. Taulukko 12: TeamDC SEPAt Käytäntö Vastuuhenkilö Vaiheet Coding Camp Kari Ylihärsilä Samuel Korpi I1 ja I2 24
Käyttettävyyden arvointi Aleksi Airola Vesa Haukkavaara Elina Kontro I1 ja I2 Staatiset menetemät Santeri Saarinen I1 ja I2 5.5.1 Coding Camp Kyseessä on käytäntö, jossa vähintään kerran kussakin iteraatiossa järjestetään kokonainen etukäteen suunniteltu työpäivä, jolloin kaikki ryhmämme jäsenet tekevät töitä projektin eteen yhdessä, samassa paikassa ja samaan aikaan. Tutkimme eri näkökulmista keskitetyn työskentelytavan tuottavuutta verrattuna hajautettuun työhön, jossa useimmat ryhmän jäsenet tekevät asioita eri paikoissa eri aikaan. Hajautetun työn etuja ovat keskittyminen tehtävään sekä ajan tehokas käyttäminen siltä osin, kun tekijälle on oma tehtävä täysin selvä. Keskitetyn työn etuja taas ovat tehokas tiedon siirtyminen kokemusten kautta sekä parempi ongelmanratkaisu, kun kaikkien taitoja saadaan hyödynnettyä samaan aikaan. Tutkimme "Coding Camp" käytännön tuottavuutta ainakin seuraavista näkökulmista: Ryhmän tuottavuus työtunteihin nähden, tuotetun koodin / tuotosten laatu (virheettömyys), tiedon siirtyminen ryhmän sisällä sekä työskentelytapojen nautittavuus. 5.5.2 Käytettävyyden arviointi Käytettävyyden arvoinnin avoitteena on testata ja parantaa kehitteillä olevan tuotteen käytettävyyttä. Tuotetta kehitettäesssä pyritään kiinnittämään erityistä huomiota tuotteen tulevien käyttäjien näkökulmaan. Käytettävyyden arvointia tulaa tekemään sekä käytettäsyystesteillä että heuristisella arviolla. Koska tässä ohjelmistokehitysprojektissa tavoitteena on toteutetaan olemassa olevaan CoSCA-simulaattoriin helppokäyttöinen ja opittava käyttöliittymä, joka mahdollistaa simulaattorin hyödyntämisen mm. HKKK:ssa opetuksen apuvälineenä, on luontevaa ottaa käytettävyyden arvointi yhdeksi projektissa käytettäväksi menetelmäksi, jolla pyritään varmistamaan tämän tavoitteen saavuttaminen. Käyttäjäryhmä, johon testauksessa keskitytään ovat HKKK:n opiskeljat, joita käytettävyystestauksen osallistuu vähintään kolme henkilöä. 5.5.3 Staattiset menetelmät Staattisella analysoinnilla tarkoitetaan sellaista esim. lähdekoodin analysointia, jossa koodia ei ajeta. Koodikatselmointi on yksi staattinen ohjelmistonanalysointi menetelmä. Menetelmän avulla voidaan mitata, analysoida ja parantaa ohjelmiston suunnittelua sekä löytää virheitä. Työssä tullaan käyttämään jotakin staattista analysointimenetelmää mittaamaan ja parantamaan ohjelmiston laatua sekä vähentämään ohjelmistossa olevien virheiden määrää. 25