T-76.4115 Projektisuunnitelma Team Tubeless Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 3.10.2005 Kekkonen Ensimmäinen mallipohjaan täytetty versio 0.2 11.10.2005 Kekkonen Projektisuunnitelman täydennystä 0.3 13.10.2005 Kekkonen 0.4 17.10.2005 Kekkonen Projektisuunnitelman edelleentäydennys asiakkaan ja mentorin kommentteja varten Projektisuunnitelman täydennys PP iteraation palautusta varten 0.5 29.10.2005 Tikkanen QA suunnitelman lisääminen osaksi projektisuunnitelmaa 0.6 30.10.2005 Kekkonen, Tikkanen I1 Iteraatiosuunnitelman viimeistely 0.7 2.12.2005 Kekkonen Tehty pieniä päivityksiä ja tarkennuksia useisiin kohtiin 0.8 5.12.2005 Tikkanen Tuntiraportti ja muutamia tarkennuksia 0.87 17.1.2005 Tikkanen QA-suunnitelman päivitys 0.9 17.1.2005 Kekkonen I2 Iteraatiosuunnitelman teko ja viimeistely 1.0 27.2.2006 Kekkonen Lopullisen version esiversio Sisältö 1. Johdanto Tämä dokumentti on Team Tubelessin projektisuunnitelma Teknillisen korkeakoulun kurssilla T-76.4115 Ohjelmistokehitysprojekti I. 1.1 Projektin tarkoitus ja laajuus Projektissa toteutetaan Test World Oy:lle järjestelmä rengastestien mittaustulosten käsittelyyn. Projektin työmäärä on rajattu 1190 tuntiin ja projekti alkaa 27.9.2005 ja päättyy 2.3.2006. Test World Oy on yksityinen, puolueeton ja riippumaton yritys, joka on erikoistunut autojen ja renkaiden talvitestaukseen. Yritys tekee tilaustyönä talvitestausta auto- ja rengasvalmistajille, viranomaisille sekä autoalan lehdille. Test World Oy palvelee asiakkaitaan myös vuokraamalla testiratoja, halleja, toimistoja ja avustavaa henkilökuntaa. [1] Testiraportteja luotaessa tehdään paljon virhealtista käsityötä esim. syötettäessä eri renkaiden nimiä laskentaohjelmaan. Testiraportit eivät ole tällä hetkellä yhdenmukaisia eli asiakkaille lähtee erilaisia ja -näköisiä raportteja.
Projektissa tehdään TestWorld Oy:lle NohevaII-järjestelmä, jonka avulla testiraporttien luomista automatisoidaan sekä vähennetään virheitä poistamalla ylimääräiset käsisyöttövaiheet. Laskentaohjelmistosta tehdään stand alone -tyyppinen jolloin testiraportteja voidaan luoda välittömästi kun testitulokset on siirretty mittalaitteilta järjestelmään. 2. Osapuolet ja henkilöstö Projektiin osallistuu projektiryhmä, asiakas ja mentor. Projektiryhmä muodostuu kurssin opiskelijoista, jotka tuottavat projektin aikana asiakkaalle eli Test World Oy:lle ohjelmiston. Mentor on kurssin puolesta oleva assistentti joka ohjaa projektiryhmää ja antaa tarvittaessa apua. Projektin osapuolet on esitelty kaaviossa 1. Kaavio 1: Projektiryhmän osapuolet 2.1 Projektiryhmä Projektiryhmä tuottaa NohevaII-järjestelmän asiakkaalle yhdessä sovittujen vaatimusten pohjalta. Alle on merkitty projektiryhmän jäsenet sekä kunkin päävastuualueet. Ryhmän webbisivut ovat osoitteessa http://users.tkk.fi/~stikkane/tt/. 2.1.1 Manageriryhmä
Nimi: Markku Kekkonen Roolit: projektipäällikkö, työn suunnittelu ja seuranta, asiakasvastaavuus E-mail: markku.kekkonen#hut.fi Nimi: Sami Tikkanen Roolit: Vaatimustenmäärittely, laadunvalvonta ja testaus E-mail: stikkane#cc.hut.fi Nimi: Juha Kauppi Roolit: Pääkehittäjä E-mail: juha.kauppi#hut.fi 2.1.2 Kehittäjät Nimi: Tuomas Hellstén Roolit: TBD E-mail: thellste#cc.hut.fi Nimi: Tiina Korhonen Roolit: TBD E-mail: tjkorho3#cc.hut.fi Nimi: Marko Lindström Roolit: TBD E-mail: marko.lindstrom#hut.fi Nimi: Jaakko Manelius
Roolit: TBD E-mail: jmaneliu#cc.hut.fi 2.2 Muut osapuolet Projektiryhmän lisäksi projektissa ovat mukana asiakkaan eli Test World Oy:n edustajat Jukka Antila sekä Harri Eskelinen sekä kurssin puolesta mentor Markus Rautopuro. Asiakkaan vastuulla on kertoa projektiryhmälle toteutettavan järjestelmän vaatimukset sekä hyväksyä toteutettu järjestelmä. Nimi: Jukka Antila Rooli: asiakas E-mail: jukka.antila#testworld.fi Nimi: Harri Eskelinen Rooli: asiakas E-mail: harri.eskelinen#testworld.fi Nimi: Markus Rautopuro Rooli: mentor E-mail: markus.rautopuro#aureolis.com 3. Tavoitteet ja lopetuskriteerit 3.1 Asiakkaan tavoitteet Taulukko 1 listaa asiakkaan tärkeimmät tavoitteet ja niiden hyväksyntäkriteerit prioriteettijärjestyksessä. Taulukko 1: Asiakkaan tärkeimmät tavoitteet
Tavoite 1. Toimiva, asiakasta hyödyttävä ja asiakkaan raportointitoimintaa kehittävä järjestelmä. Lisäksi vaatimuksissa tärkeydellä välttämätön olevat kohdat on testattava erityisen huolellisesti Hyväksyntäkriteeri Asiakkaan tekemä oma arvio projektin lopussa. ja toteuttaa ne laadulla hyvä. 2. Hyvä toimintavarmuus ja pieni virhealttius 3. Priorisointi eli avainkohtien toteuttamisjärjestys 4. Jatkokehitys - mahdollisuudet projektin jälkeen, koodin ja dokumentaation selkeys Järjestelmä täyttää toimintavarmuudelle asetetut tavoitteet ja mittaustulosten laskennan on toimittava vrheettömästi. Vaatimukset toteutetaan sovitussa järjestyksessä. Koodi noudattaa koodauskäytäntöä ja dokumentaatio on asiakkaan kannalta selkeätä ja kuvaa toteutetun järjestelmän, joka mahdollistaa järjestelmän myöhemmän laajentamisen. 3.2 Projektiryhmän tavoitteet Taulukko 2 listaa projektiryhmän tavoitteet ja kriteerit, joilla nämä tavoitteet todetaan saavutetuiksi. Taulukko 2: Projektiryhmän tavoitteet Tavoite 1. Kurssin läpäiseminen 2. Arvosana vähintään 4 ja kurssin tavoitteiden täyttäminen 3. Sujuva ja tehokas yhteistyö ja kommunikaatio asiakkaan kanssa Hyväksyntäkriteeri Ryhmä saa kurssista hyväksytyn arvosanan. Ryhmän lopullinen arvosana kurssista on 4 tai 5 ja kukin ryhmän jäsen kokee saavuttaneensa kurssin asettamat oppimistavoitteet. Asiakkaaseen pidetään yhteyttä, siten ettei asiakas koe olevansa missään vaiheessa projektia pimennossa projektin tilasta. Toisaalta projektiryhmän työskentely ei saa keskeytyä siitä syystä ettei asiakkaalta saada tarvittavaa tietoa. 4. Toimiva ryhmätyöskentely Ryhmän jäsenet suorittavat määrätyt omat
5. Ajankäytön jakaminen siten että rajoissa ja tavoitteissa pysytään tehtävänsä ajoissa sovittuihin päivämääriin mennessä, siten että työmäärä jakautuu kokonaisuudessaan tasaisesti. Tehtävät jaetaan jo alussa ryhmän jäsenten kesken siten että työmäärä on jokaisen osalla mahdollisimman samansuuruinen ja ettei kenenkään työmäärä ylitä kurssin puitteissa 170 tuntia. Tehtävät priorisoidaan jotta vähintään välttämättömät tehtävät tulevat suoritetuiksi. 3.3 Henkilökohtaiset oppimistavoitteet Taulukossa kolme on listattuna projektiryhmän jäsenten henkilökohtaiset oppimistavoitteet. Taulukko 3: Ryhmän jäsenten henkilökohtaiset oppimistavoitteet Ryhmän jäsen Markku Kekkonen Sami Tikkanen Juha Kauppi Tuomas Hellstén Henkilökohtainen oppimistavoite Oppia (ohjelmisto)projektin johtamista ja saada parempi käsitys hieman isommista ohjelmistoprojekteista oikean asiakkaan kanssa. Ohjelmiston kehittäminen suunnitelmallisesti ja riittävillä resursseilla. Ohjelmistotuotannon ja - testauksen suosituimpien menetelmien käyttö ja kokeilu, erityisesti laadunvarmistus- ja testauskäytännöt. Toiminta manageriryhmässä. Asiakkaan tarpeiden ymmärtäminen ja vaatimustenhallinta. Tuloksellisen testauksen suunnittelu ja toteutus. Laadukkaan koodin ja dokumentaation tuottaminen. Syventää osaamistani ja saada kokemusta mana-geriryhmässä olemisesta, erityisesti pääkehittäjän näkökulmasta. Tavoiteenani on myös saada lisää kokemusta Javasta ja kommunikoinnista tämän kokoisessa ryhmässä. Oppia toimimaan hieman isomman projektiryhmän osana, sekä saada
tuntumaa Tiina Korhonen Marko Lindström Jaakko Manelius projektista oikean asiakkaan kanssa. Oppia ryhmätyötaitoja, oikean asiakkaan kanssa toimimista sekä saada käytännön kokemusta ohjelmistokehitysprosessista. 3.4 Projektin keskeytyskriteerit Projekti keskeytetään ryhmän yhteisellä päätöksellä, mikäli jokin seuraavista tilanteista toteutuu: Kolme tai useampia jäseniä lähtee ryhmästä Asiakasyhteistyö loppuu (esim. asiakkaan kiinnostus loppuu, resurssit loppuvat, avainhenkilöstö poistuu tai liiketoiminta muuttuu) Asiakas ei toimita materiaalia tai informaatiota sopimusten mukaan Kurssin läpäiseminen ei muusta syystä ole mahdollista 3.5 Projektin lopetuskriteerit Projekti lopetetaan, kun jokin seuraavista kriteereistä täyttyy: Kurssi päättyy aikataulunsa mukaan Tuote on toimitettu asiakkaalle sovitussa laajuudessa, asiakas on sen hyväksynyt ja asiakas hyväksyy projektin päättyneeksi Henkilökohtaiset aikarajat on täytetty 4. Resurssit ja budjetti 4.1 Henkilöt Projekti on jaettu kolmeen eri vaiheeseen ja alla olevasta taulukosta selviää kuhunkin osaan budjetoitu työmäärä Taulukko 4: projektin suunniteltu työmäärä Kekkonen Tikkanen Kauppi Hellsten Korhonen Lindström Manelius Yhteensä PP 60 50 40 0 0 0 0 150 I1 60 60 70 100 100 100 100 590 I2 50 60 60 70 70 70 70 450
Yhteensä 170 170 170 170 170 170 170 1190 4.2 Materiaalit Käytämme projektin aikana hyväksi Asiakkaan olemassaolevaa testi- ja tuotantopalvelinta jossa tällä hetkellä pyörii Noheva I ohjelmisto. Projektiryhmä saa tarvittavat ylläpitotunnukset Asiakkaalta. 4.3 Budjetti Taulukossa 4 on hahmoteltu projektin budjettia, jos projektia ei toteutettaisi tämän kurssin puitteissa. Projektiryhmän työstähän ei todellisuudessa nyt laskuteta asiakkaalta mitään. Taulukko 5: projektin budjetti Kustannuserä Määrä Hinta Asiakkaan SoberIT:lle maksama summa kertasumma 3000 3 000 Asiakkaan käyttämä oma aika 2 hlö * 3 h/vko * 17 vko * 30 /h 3 060 Projektiryhmän työ 1190 h, à 50 /h 59 500 Yhteensä 65 560 5. Työkäytännöt ja työkalut 5.1 Käytännöt Tässä luvussa kuvataan projektin aikana käytettävät työkäytännöt sekä tarvittavat työkalut. 5.1.1 Iteratiivinen kehitys Projektin aikana projektiryhmä käyttää iteratiivista kehitystä. Iteratiivisessa kehityksessä jokaista iteraatiota voisi ajatella minivesiputouksena. Jokainen vaihe alkaa iteraatiosuunnittelulla, jossa käydään läpi ne asiat jotka tulisi toteuttaa kyseisen iteraation aikana. Tämän jälkeen jatketaan vaatimusten keräyksellä ja vaatimusmäärittelyllä, jonka jälkeen päästään suunnittelemaan itse toteutusta ennen toteutusvaihetta. Toteusvaiheen jälkeen ohjemiston kaikki siihen asti tehdyt toteutukset testataan, ei ainoastaan uudet lisäykset. Testauksen jälkeen valmistellaan iteraation palautus. Aiakkaalta saadaan palautetta jokaisen iteraation aluksi edellisen iteraation osalta. Tämän lisäksi jokaisen iteraation aikana, noin kahden viikon päästä iteraation alkamisesta, asiakkaalle järjestetään demo edistymisestä jossa asiakkaalla on hyvä mahdollisuus vaikuttaa kehityksen ja antaa palautetta aikaisessa vaiheessa jos jokin toteutus ei täytä asiakkaan asettamia vaatimuksia.
5.1.2 Iteraation suunnittelu Iteraation suunnittelu aloitetaan välittömästi iteraatiodemon jälkeen olevalla tapaamisella asiakkaan kanssa. Iteraatiosuunnitelma tehdään iteraation ensimmäisen viikon aikana ja se toimitetaan sekä asiakkaalle että mentorille. Asiakas hyväksyy suunnitelman tai ehdottaa siihen tehtävät muutokset esimerkiksi niissä tapauksissa jolloin jonkin ominaisuuden toteuttaminen priorisoidaan korkeammalle. Projektiryhmän johtoryhmä suunnittelee ajankäytön ja arvioi iteraation kuluvan ajan kunkin yksittäisen henkilön kohdalla ja esittää arvionsa asiakkaalle iteraatiosuunnitelman palautuksen yhteydessä. 5.1.3 Dokumentointi Jokainen ryhmän jäsen on vastuussa itse tuottamistaan dokumenteista, mutta päävastuu on projektipäälliköllä. Hän huolehtii siitä että odkumentit palautetaan ajoissa ja oikeassa muodossa. Dokumentteja palautetaan HTML ja PDF muodoissa. Projektiryhmän johtoryhmä käy läpi palautettavat dokumentit ennen palautusta ja korjaa niissä mahdollisesti olevia puutteita. Dokumentteja pidetään versionhallinnassa. Jokainen kehittäjä luo dokumentoinnin omasta työstään ja pääkehittäjä tarkastaa näin tuotetut dokumentit. 5.1.4 Riskien hallinta Riskit todennetaan aluksi sen mukaan mitä oletettavia ongelmia projektin edetessä saattaa ilmaantua. Lokia päivitetään tarpeen mukaan. 5.1.5 Tuntiraportointi Tuntiraportointiin ei käytetä erillistä työkalua. Jokainen ryhmän jäsen laskee viikon aikana käyttämänsä tunnit ja ilmoittaa ne viikon päätteeksi sunnuntaina tai maanantaina projektipäällikölle, joka päivittää tehdyt tunnit ryhmän www-sivuille. 5.1.6 Ohjelmiston koon määrittäminen Ohjelmiston koko määritetään ensisijaisesti tuotettujen koodirivien määränä (LOC). Koodirivien määrästä ilmoitetaan myös todellinen arvo eli ne koodirivit jotka eivät ole kommentteja tai dokumentointia koodin sisällä.
5.1.7 Kommunikointi Kommunikointi ryhmän sisällä tapahtuu kurssin puolesta tarjottavan TikiWiki ohjelmiston avulla. Myös asiakkaalle ja mentorille annetaan pääsy kyseiseen ohjelmaan. Yleisluontoiseen, kaikkia koskevaan yhteydenpitoon käytetään sähköpostia. Ryhmän www-sivut toimivat myös kommuninkointi välineenä ryhmän sisällä. Tarvittaessa käytetään pikaviestiohjelmia kuten Messenger ja Miranda. 5.1.8 Iteraatiodemo Projektipäällikkö suunnittelee iteraatiodemoon otettavan materiaalin ja valmistelee esitettävän edistymisraportin iteraatiodemossa. Projektipäällikkö huolehtii iteraatiodemon pysymisestä aikataulussa ja toimii demon puheenjohtajana. Pääkehittäjä valmistelee ohjelman demoamisen ja suorittaa sen mahdollisesti yhdessä kyseisistä osista vastuussa olevien kehittäjien kanssa. 5.1.9 Vikojen seuranta Järjestelmän vikaraportointiin käytetään kurssin tarjoamaa Bugzilla-ohjelmistoa. 5.1.10 Versionhallinta Versionhallintaan käytettävä työkalu on CVS (Concurrent Versions System). CVS repositorio sijaitsee yhden projekryhmäläisen TKK:n ATK-keskuksen kotihakemistossa. Versionhallinnassa noudatetaan seuraavia käytäntöjä uuden version päivityksen yhteydessä kirjoitetaan lokiviesti, jossa kuvataan tehdyt muutokset dokumentit päivitetään vähintään päivän päätteeksi ja muutokset kirjataan myös dokumentin muutoshistoriaan koodin päivitetään versionhallintaan, kun ominaisuus on valmis. Vain kääntyvää ja toimivaa lähdekoodia saa päivittää repositorioon. versiot merkitään tagilla palautusten, käyttöönottojen ja järjestelmä- tai hyväksymistestaukseen otettavien versioiden yhteydessä 5.1.11 Koodauskäytäntö Koodi kirjoitetaan Java -kielellä ja muotoillaan Sun:in koodauskäytännön mukaisesti, joka on saatavissa osoitteesta http://java.sun.com/docs/codeconv/.
5.1.12 Vertaistestaus Vertaistestausta aloitetaan sunnittelemaan välittömästi kun vertaistestausryhmät on vahvistettu. Pyrimme siihen että vertaistestausta suoritetaan jo ennen iteraation yksi palautusta tai ainakin iteraation kaksi alussa, jolloin ohjelmiston kehittämistä varten toisen iteraatiokierroksen aikana saadaan riittävän ajoissa arvokasta näkemystä täysin uudelta kantilta. Vertaistestauksen suunnittelu toteutetaan siten että molemmista ryhmistä testauksesta vastuussa olevat henkilöt tapaavaat muutaman kerran ennen varsinaista vertaistestauksen aloittamista, jotta itse testaus voidaan suorittaa ennalta suunniteltujen määrityksien mukaisesti. 5.1.13 Vaatimusten hallinta Vaatimukset projektin suhteen tulee ensisijaisesti asiakkaalta sillä he ovat myös tuotteen loppukäyttäjiä sen lisäksi että he ovat tuotteen tilaajia. Vaatimukset selvitetään asiakkaan ja projektiryhmän välisissä kokouksissa, joiden perusteella projektiryhmä esittelee vaatimusmäärittelyn asiakkaalle, joka hyväksyy määrittelyn tai ehdottaa korjauksia. Projektiryhmä voi myös ehdottaa asiakkaalle vaatimuksia joita ohjelmistolla tulee olla jotta sen toteuttaminen olisi esimerkiksi realistista. 5.1.14 Prototyyppi Asiakkaan pyynnöstä projektiryhmä aloittaa välittömästi ensimmäisen kehitysiteraatiovaiheen alussa käyttöliittymäprototyypin rakentamisen. Tämä prototyyppi demotaan asiakkaalle toisen kehitysviikon lopulla. 5.2 Laadunvarmistussuunnitelma 5.2.1 Koko projektin laatu 5.2.1.1 Tärkeimmät laatutavoitteet Kehitettävän ohjelmiston tärkeimmät laatutavoitteet ovat: Käytön yksinkertaisuus ja luotettavuus. Käytön on oltava vaivatonta, eikä ohjelma saa kaatua normaalikäytössä. Laskennan virheettömyys. Testitulosten laskennan on tapahduttava poikkeuksetta suunnitellulla tavalla. Raporttien oikeellisuus ja yhdenmukaisuus. Raportti on rengastestin lopputulos ja yksi osoitus Test Worldin asiakkaille yhtiön toiminnan korkeasta laadusta. Ohjelmisto on laadullisesti onnistunut, kun nämä tavoitteet on saavutettu.
5.2.1.2 Toiminta ja käytännöt laatutavoitteiden saavuttamiseksi Ohjelmaa testataan neljällä testitasolla: Yksikkötestaus tehdään pääsääntöisesti jokaiselle luokalle. Testeillä varmistetaan luokkien toimivuus odotetulla tavalla. Integraatiotestaus tehdään mahdollisuuksien mukaan toiminnallisille kokonaisuuksille, esimerkiksi tulosten laskennalle. Järjestelmätestauksessa käydään läpi kaikki ohjelman valmiit toiminnot molempien iteraatioiden lopussa. Hyväksymistestaus tehdään toisen iteraation lopuksi. Siinä varmistetaan, että ohjelma täyttää sille alunperin asetetut tai asiakkaan muuten ilmaisemat vaatimukset. Suorituskykyyn ja käytettävyyteen liittyvien asioiden ei oleteta muodostavan ongelmaa tässä projektissa. Näin ollen tarvittavat testityypit ovat: Toiminnalliset testit. Kaikista ohjelmiston osista varmistetaan, että ne toimivat tarkoitetulla tavalla yhdessä ja erikseen. Luotettavuustestit. Ohjelmisto ei saa kaatua normaalikäytössä. Tässä projektissa ohjelma lukee syötteitä varsin rajoitetusti, ainoastaan mittalaitteiden tuottamista ascii-tiedostoista sekä käyttäjän syötteen muutamista käyttöliittymän tekstikentistä. Virheelliset syötteet on hylättävä, ja hyväksytyllä syötteellä ohjelman on toimittava. Asennustestit. Ohjelmisto on voitava helposti asentaa asiakkaan käytössä oleviin tietokoneisiin myös jatkossa. Tietokoneiden vähimmäisvaatimukset on määriteltävä projektin kuluessa. Projektin laatua hallitaan testauksen lisäksi seuraavilla tavoilla: Käytetään Javan koodausstandardeja. Tuotettua ohjelmakoodia tutkitaan koodikatselmuksissa. Huonolaatuinen koodi korjataan ja tarvittaessa kirjoitetaan uudelleen. Kaikki dokumentit tarkastetaan vähintään manageriryhmässä ennen niiden lähettämistä eteenpäin. Asiakkaalle ja mentorille tiedotetaan projektin etenemisestä viikoittain. Näin saadut kommentit ja mahdolliset parannusehdotukset käsitellään manageriryhmässä. Kehittäjät ohjeistetaan ja motivoidaan työhönsä. Kehittäjät pidetään tietoisina projektin tavoitteista, etenemisestä ja esiin tulleista ongelmista. Projektiryhmän jäsenet pyrkivät korkeaan laatuun. Havaituista epäkohdista ilmoitetaan heti ja rohkeasti ryhmän sisällä. Epäkohdat eivät ole henkilökohtaisia moitteita vaan arvokasta palautetta jokaisen oman osaamisen kehittämiseksi. Kukaan ei tee täydellistä työtä. Sen sijaan jokainen on jossain määrin sokea omille virheilleen. Kaikki ovat ohjelmoijina erilaisia, joten ryhmätyö tarjoaa kaikkien käytettävissä olevien taitojen hyödyntämiseen mahdollisuuden, jota itsenäisessä työskentelyssä ei ole. 5.2.1.3 Laatukäytäntöjen aikataulu ja vastuuhenkilöt
Laatukäytäntöjen aikataulu Koko ajan tehdään mahdollisimman laadukasta ohjelmakoodia testataan luokkia sitä mukaa, kun ne valmistuvat tiedotetaan riittävästi projektiin liittyvistä asioista ilmoitetaan esiin tulleista ongelmista kysytään neuvoa tarvittaessa Toiminnallisen kokonaisuuden valmistuttua laaditaan ja suoritetaan integraatiotestit Iteraatioiden lopuksi laaditaan ja suoritetaan järjestelmätestit dokumentoidaan tehty työ Projektin lopuksi testataan järjestelmä yhdessä asiakkaan kanssa ja varmistetaan, että se on vaatimusten mukainen Laatukäytäntöjen vastuuhenkilöt Projektin manageriryhmä vastaa seuraavista asioista: koodikatselmusten järjestäminen dokumenttien tarkastaminen ennen niiden lähettämistä eteenpäin kehittäjien informointi projektin tavoitteista ja tilanteesta Projektipäällikkö Markku Kekkosen vastuulla ovat viime kädessä kaikki projektiin liittyvät asiat. Vaatimus- ja laatuvastaava Sami Tikkanen vastaa siitä, että: testaustoiminta aloitetaan ajoissa ja että se on riittävän tiivistä vaatimuksia hallitaan tarkoituksenmukaisella tavalla testit laaditaan ja raportoidaan, kuten on suunniteltu projektin lopulliset dokumentit ovat kattavia ja selkeitä Pääkehittäjä Juha Kaupin vastuulla ovat: kehittäjien ohjeistus ja työnjako Javan koodausstandardien noudattamisen valvonta 5.2.1.4 Testitapaukset
Testauksessa käytettävät testitapaukset kootaan testijoukoiksi, jotka vastaavat toiminnallisia kokonaisuuksia (esim. raakadatan käsittely, laskentatulosten käsittely). Testitapaukset luodaan käyttötapauksiin perustuen siten, että muutamilla testitapauksilla saadaan katetuksi yksi käyttötapaus. Joissakin tapauksissa yksikin testitapaus voi kattaa käyttötapauksen, jos siihen liittyy vain yksi käyttöliittymätoiminto. Testitapaukset luodaan suunnilleen samaan aikaan vastaavien toimintojen valmistumisen kanssa. Tavoitteena on, että jonkin toiminnon valmistuttua sitä voidaan heti testata. Testitapauksista kirjataan numero, yhteydet käyttötapauksiin, testin suoritusohjeet, edellytykset, mahdollisesti käytettävä syöte ja oletetut tulokset. 5.2.1.5 Testeihin liittyvät dokumentit Testaustoiminnasta dokumentoidaan periaatteet (tässä dokumentissa) testitapaukset järjestettyinä testijoukkoihin automaattiset yksikkötestit (dokumentaatio mieluiten koodin yhteydessä) suoritettujen testien tulokset yhteenveto testitoiminnasta iteraatioiden lopussa 5.2.1.6 Testitulosten käsittely Yksikkötestien tuloksista tiedotetaan kyseisestä luokasta vastaavalle kehittäjälle, ellei hän ole itse tehnyt testejä. Jos testi epäonnistuu, moduulista vastaava kehittäjä raportoi vian vikojen- ja virheidenhallintajärjestelmään (Bugzilla) ja aloittaa toimenpiteet vian korjaamiseksi. Vikojenhallintajärjestelmään syötetään yleisestikin tiedot kaikista havaituista vioista. Pääkehittäjä seuraa vikoja ja ohjeistaa tarvittavat korjaustoimet. Manageriryhmä seuraa vikojen määrää ja niiden jakautumista ohjelman osien välillä. Jos tiettyyn toimintoon liittyy jatkuvasti suuri määrä vikoja eikä tilanne näytä korjaantuvan, ohjelmoidaan kyseinen osa uudelleen. 5.2.1.7 Laadun mittaaminen Laatua mitataan ensisijaisesti ohjelman toiminnan kautta. Numeroarvoisena mittarina voidaan käyttää vikojen määrää suhteessa koodirivien määrään. Tätä osamäärää voidaan tarkastella koko projektin tai toiminnallisten kokonaisuuksien osalta. 5.2.2 Iteraatio 1:n laatu 5.2.2.1 Testattavat ominaisuudet Iteraatio 1:ssä tehdään yksittäisohjelma ilman verkkotoimintoja. Yksittäisohjelman toiminnot muodostavat valtaosan koko projektin työmäärästä. Kaikki yksittäisohjelman ominaisuudet ja toiminnot testataan I1:n aikana, pääpaino on
kuitenkin laskennan oikeellisuudessa ja ohjelman toiminnan vakaudessa. Käyttöliittymän toimivuutta voidaan parantaa iteraatio 2:ssa asiakkaan antaman palautteen avulla. Myös raportointia voidaan tarvittaessa vielä parantaa I2:ssa. 5.2.2.2 Testiympäristö ja testidata Testiympäristönä käytetään yksittäisiä mikrotietokoneita, eli samoja, joilla ohjelmointikin tehdään ja joita myös asiakas jatkossa käyttää. Testidata saadaan asiakkaalta. Testidataa voidaan tarvittaessa generoida itse lisää, mutta tämä ei ole suositeltavaa. Ohjelman pitää pystyä lukemaan VBox-ohjelmiston tuottamia asciitiedostoja, vaikkakin tiedostojen luku on vain yksi osa ohjelman toiminnasta. 5.2.2.3 Resurssit Testitoiminnasta vastaa Sami Tikkanen, mutta testit järjestetään yhteistyössä pääkehittäjän ja kehittäjäryhmän kanssa. Testejä voi sinänsä kirjoittaa kuka tahansa, mutta kehittäjät kirjoittavat ainakin osan testeistä. Projektipäällikkö valvoo testaustoimintaa. 5.2.2.4 Aikataulu 19.11. mennessä tietorakenteiden ja käyttöliittymien testauksen aloittaminen, aikaa 5 vrk 26.11. mennessä raakadatan ja laskennan testauksen aloittaminen, aikaa 5 vrk 3.12. mennessä aloitetaan tietojen luvun ja tallennuksen sekä raporttien testaaminen, aikaa 2 vrk 5.12. mennessä I1:n testit suoritettu ja dokumentoitu Päivämääriä siirretään aikaisemmaksi, jos kehitys etenee suunniteltua nopeammin. 5.2.2.5 Testikierrokset Automaattisia yksikkötestejä ajetaan jatkuvasti testitoiminnan aikana sitä mukaa, kun ne valmistuvat. Muita testejä suoritetaan, kun kohteena oleva toiminnallisuus on saatu valmiiksi. Testit pyritään saamaan valmiiksi seuraavana päivänä testattavien osien valmistuttua. Iteraation lopussa testataan siihen kuuluvat toiminnot kokonaisuutena. Kokonaisuutta ei voida testata aikaisemmin, mutta tässä vaiheessa ei odoteta löytyvän merkittävää määrää virheitä, koska alemman tason komponentit on jo testattu. Suurten vikojen korjaamisen jälkeen tarkastetaan kyseisen ohjelman osan tila. Lisäksi tarkastetaan tätä osaa seuraavien osien tila seuraavassa järjestyksessä: raakadatan lukeminen tietojen luku ja tallennus (tiedostomalli) laskenta raportti 5.2.3 Iteraatio 2:n laatu
5.2.3.1 Testattavat ominaisuudet Iteraatio 2:n testitoiminta jakautuu uusien ominaisuuksien testaamiseen (myöhemmin iteraation aikana) sekä jo toteutettujen ominaisuuksien uudelleen testaamiseen, kunhan niihin liittyvät tunnetut virheet on korjattu. Uusia ominaisuuksia ovat toisaalta raportti, toisaalta verkkoyhteyttä hyödyntävät säätietojen haku, projekti- ja rengastietojen haku sekä projektitiedostojen tallennus palvelimelle. Kuten I1:ssäkin, laatuvaatimuksista tärkeimmät ovat laskennan oikeellisuus sekä ohjelman toiminnan vakaus. Käytettävyyttä ei testata erikseen, vaan sitä parannetaan ainoastaan omien sekä asiakkaalta saatujen kokemusten perusteella. Raporttiin liittyvä erityinen laatuvaatimus on siisti ja yhdenmukainen ulkoasu. 5.2.3.2 Testiympäristö ja testidata Testiympäristönä käytetään yksittäisiä Windows 2000 tai Windows XP - mikrotietokoneita, eli samoja, joilla ohjelmointikin tehdään ja joita myös asiakas jatkossa käyttää. Testidata saadaan asiakkaalta. Testidataa voidaan tarvittaessa generoida itse lisää, mutta tämä ei ole suositeltavaa. Ohjelma pystyy lukemaan VBoxohjelmiston tuottamia ascii-tiedostoja. 5.2.3.3 Resurssit Testitoiminnasta vastaa Sami Tikkanen, mutta testit järjestetään yhteistyössä pääkehittäjän ja kehittäjäryhmän kanssa. Testejä voi sinänsä kirjoittaa kuka tahansa, mutta kehittäjät kirjoittavat ainakin osan testeistä. Projektipäällikkö valvoo testaustoimintaa. Testit tehdään samoilla tietokoneilla kuin ohjelmointikin. Testeihin ei liity erityisiä ohjelmistotarpeita. 5.2.3.4 Aikataulu yksittäisohjelman testaus alkaa heti ja päättyy, kun järkevää testattavaa ei enää ole (tavoitteena 17.2.) 20.1. dynaamisen raportin testaus alkaa (jos valmis), aikaa 3 vrk 30.1. säädatan haun testaus alkaa, aikaa 3 vrk 10.2. projekti- ja rengastietojen haun testaus alkaa, aikaa 5 vrk 13.2. projektitiedostojen palvelintallennuksen testaus alkaa, aikaa 3 vrk 16.2. testausohjeen teko vertaisryhmälle, aikaa 1 vrk 26.2. mennessä kaikki I2:n testit suoritettu ja dokumentoitu Päivämääriä siirretään aikaisemmaksi, jos kehitys etenee suunniteltua nopeammin. 5.2.3.5 Testikierrokset Automaattisia yksikkötestejä ajetaan jatkuvasti testitoiminnan aikana sitä mukaa, kun ne valmistuvat. Muita testejä suoritetaan, kun kohteena oleva toiminnallisuus on saatu valmiiksi. Testit pyritään saamaan valmiiksi seuraavana päivänä testattavien osien valmistuttua. Iteraatio 2:n lopussa testataan kaikki toiminnot kokonaisuutena. Kokonaisuutta ei voida testata aikaisemmin, mutta tässä vaiheessa ei odoteta löytyvän merkittävää
määrää virheitä, koska alemman tason komponentit on jo testattu. Projektiryhmä tekee järjestelmätestit, minkä lisäksi pyritään tekemään asiakkaan kanssa hyväksymistesti. Suurten vikojen korjaamisen jälkeen tarkastetaan kyseisen ohjelman osan tila. Lisäksi tarkastetaan tätä osaa seuraavien osien tila seuraavassa järjestyksessä: raakadatan lukeminen säädatan sekä projektin perus- ja rengastietojen haku palvelimelta tietojen luku ja tallennus (tiedostomalli) tiedostomallin tallennus palvelimelle laskenta raportti 5.3 Työkalut Versionhallinta Versionhallintaan käytetään CVS -ohjelmaa, jonka kanta on asennettu ATKkeskuksen kotihakemistoon. Ohjelmointi Ohjelmistokehitysympäristönä käytetään integroitua Eclipse -kehitysympäristöä. Vikaraportointi Järjestelmän vikaraportointiin käytetään kurssin puolesta tarjolla olevaa Bugzilla - ohjelmistoa. Kommunikointi Kommunikointi ryhmän sisällä tapahtuu IRC-kanavalla, kun tehdään ohjelmointityötä. Yleisluontoiseen, kaikkia koskevaan yhteydenpitoon käytetään sähköpostia. Ryhmän www-sivut toimivat kommuninkointivälineenä myös ryhmän sisällä. Tarvittaessa käytetään pikaviestiohjelmia kuten Messenger ja Miranda. 6. Vaiheistus Projekti on jaettu kolmeen iteraatioon. Seuraavassa kuvataan niiden päätavoitteet, tuotettavat dokumentit ja muut tuotokset, tehtävät sekä työmääräarviot. Lisäksi projektin kannalta tärkeimmät päivämäärät on merkitty taulukkoon. Iteraatiot ja niiden aikataulut ovat kurssin määräämiä 6.1 Aikataulu Taulukko 6 sisältää projektin aikataulun ja tärkeimmät päivämäärät. Taulukko 6: Projektin aikataulu
Pvm Tapahtuma PROJEKTIN SUUNNITTELU (27.9.- 20.10.2005) Pe 30.9 Ma 3.10 Ma 17.10. To 20.10 Ensimmäinen asiakastapaaminen DL 13:00 Iteraatiosuunnitelman palautus (projektisuunnitelman luvut 6.1 ja 6.2) sähköpostilla mentorille ja asiakkaalle DL 13:00 Vaiheen tuotosten palautus 08.00 Iteraatiodemo TOTEUTUS 1 (21.10.- 8.12.2005) Ma 31.10. Pe 4.11 Ma 14.11 Ma 21.11 Ke 23.11 Ma 28.11 Ma 28.11 Ke 30.11 Pe 2.12 Pe 2.12 DL 13:00 Iteraatio- ja laadunvarmistussuunnitelman palautus plan (proj. suunn. luvut. 5.2. & 6.1 & 6.3) sähköpostilla mentorille ja asiakkaalle käyttöliittymäprototyyppi valmis ja sen esittely asiakkaalle Rajapinnat valmiina eri osien (modulien) välillä Tietorakenteet ja käyttöliittymä valmis siltä osiin että niihen voi syöttää tarvittavat tiedot laskentaa ja raportti varten Tietorakenteet ja käyttöliittymät testattu Tietojen (raakadatan) luku valmis ja laskenta valmis Referenssi ja paikkakorjauksen tekeminen käyttöliittymän kautta mahdollista Raakadatan käsittely ja laskenta testattu Tietojen luku ja tallennus paikallisesti valmis Raportti valmis 3.12-6.12 Kokonaisuuden testausta ja demoon valmistautuminen Ma 5.12. Ma 5.12 To 8.12. 9.12.-15.1. Joululoma DL 13:00 Vaiheen tuotosten palautus Tiedostojen käsittely ja raportit testattu I1:n toiminnallisuus testattu 8.00 Iteraatiodemo Innopoli 2 Seminaarisali TOTEUTUS 2 (16.1. - 2.3.2006) Ti 17.1. 17:00 Asiakastapaaminen (pakollinen manageriryhmälle) Ke 18.1 DL 13:00 Iteraatio- ja laadunvarmistussuunnitelman palautus plan (proj. suunn. luvut. 5.2.3 & 6.1 & 6.4) sähköpostilla mentorille ja asiakkaalle Su 22.1 Ma 23.1 Ma 30.1 DL 23:59 Seuraavan kehitysversion lähetys sähköpostilla asiakkaalle Dynaamisen raportin luonti käyttöliittymästä valmis I1 vaiheesta jääneet (pienet) bugit korjattu, säädatan luku? valmis 30.1-3.2 Testausta, tietojen luku Noheva I:stä valmis, tietokannan ja siitä lukemisen sekä
To 2.2. Ma 13.2 Ke 15.2 tallentamisen toteuttamista klo 09:00 Demo asiakkaalle ja mentorille (I2:n ensimmäinen vaihe päättyy) Tietojen tallennus ja luku tietokannasta valmis ja yhteys käyttöliittymään tehty Lähes valmiin tuotteen demo asiakkaalle, tämän jälkeen ei tule lisää toiminnallisuuksia 13-17.2 Testausta, testausohjeen tekeminen sekä dokumentoinnin viimeistelyä Pe 17.2. Ti 21.2. DL 13:00 Valmiin järjestelmän toimitus ja testausohjeet vertaisryhmälle DL 13:00 Vertaistestauksen tulosten raportointi vertaisryhmälle 21-27.2 DL 27.2 13:00 (Mahdollisten) bugien korjausta, dokumentoinnin viimeistely, koodin viilausta Ma 27.2 Ke-To 1.- 2.3. DL 13:00 Vaiheen tuotosten palautus 8-19 Iteraatiodemo 6.2 Projektin suunnittelu (PP) Tavoitteet: projektin suunnittelu menetelmien ja työkalujen valinta asiakkaan toimintaympäristön ymmärtäminen vaatimusmäärittely yleisellä tasolla sisältäen tärkeimmät käyttötapaukset lopputulosten oikeuksista sopiminen käytettävien työkalujen sekä kehitysympäristön pystyttäminen Tuotokset: projektisuunnitelma (paitsi luku 5.2 Laadunvarmistussuunnitelma) vaatimusmäärittely (luvut 1-5, luvut 6-9 ainakin tärkeimpien vaatimusten osalta, luvut 11-12) edistymisraportti ohjeet menetelmien ja työkalujen käytöstä Taulukko 7; tehtävät: Nimi Arvio Vastuuhlö Alku_pvm Loppu_pvm Tehty Ero Vaatimusmäärittely 30 stikkane 30.9.2005 17.10.2005 20-10 Työkalujen ja toimintaypä- ristön pystyttäminen Projektin tavoitteiden määrittely 10 jkaupp2 1.10.2005 17.10.2005 8-2 20 MGM 30.9.2005 17.10.2005 14-6 Luennot 18 MGM 27.9.2005 17.10.2005 32 14 Ryhmätapaamiset 18 MGM 27.9.2005 21 3
Asiakastapaamiset 12 MGM 30.9.2005 17.10.2005 6-6 Mentortapaaminen 4 MGM 3.10.1005 17.10.2005 0-4 Iteraatiosuunnitelma 5 mjkekkon 3.10.2005 3.10.2005 5 0 Riskienhallinnan suunnitelma Edistymisraportin tekeminen Projektisuunnitelman kirjoitus 5 MGM 3.10.2005 17.10.2005 5 0 4 mjkekkon 3.10.2005 17.10.2005 6 2 20 mjkekkon 3.10.2005 17.10.2005 22 2 Yhteensä 150 MGM 27.9.2005 17.10.2005 *MGM = Management ryhmä, DEV = kehittäjät, ALL = kaikki 6.3 Toteutus 1 (I1) Tavoitteet: arkkitehtuurin suunnittelu yksittäisohjelman toimintojen toteutus toimintojen testaaminen toteutettujen osien dokumentointi Tuotokset: Ohjelmisto käyttöliittymä raakadatan lukeminen testitulosten laskenta tiedostojen käsittely raportti Dokumentit päivitetty projektisuunnitelma päivitetty vaatimusdokumentti tekninen kuvaus (ainakin yleisellä tasolla) testitapaukset testiloki testiraportit edistymisraportti Taulukko 8; tehtävät: Nimi Käyttöliittymäprototyypin teko Raportti ja (liittyminen) tietokanta(an) Arvio Vastuuhlö Alkupvm Loppupvm Tehty Ero 20 jkaupp2 21.10.2005 4.11.2005 17-3 80 tjkorho3 21.10.2005 2.12.2005 14-66 Laskennan toteutus 80 jmaneliu 21.10.2005 28.11.2005 28-52
Käyttöliittymä 80 thellste, jkaupp2 21.10.2005 28.11.2005 100 +20 Raakadatan käsittely 80 marko 30-50 Testauksen suunnittelua ja testausta 40 mjkekkon 21.10.2005 7.12.2005 0-40 Testaus 60 DEV 21.10.2005 7.12.2005 4-56 Testaus 30 jkaupp2 21.10.2005 7.12.2005 7-23 Testauksen suunnittelua ja testausta 50 stikkane 21.10.2005 7.12.2005 12-38 Ryhmätapaamiset 28 ALL 21.10.2005 7.12.2005 48 +20 Asiakastapaamiset ja prototyypin demo 19 MGM/ALL 11-8 Mentortapaamiset 6 MGM 3-3 Arkkitehtuurikuvaus 15 jkaupp2 17 +2 Laadunvarmistussuunnitelma 15 stikkane 10-5 Iteraatiosuunnitelma 4 mjkekkon 21.10.2005 31.10.2005 7 +3 Riskienhallinnan suunnitelma 5 MGM 3.10.2005 17.10.2005 5 0 Edistymisraportin tekeminen 4 mjkekkon 1.12.2005 5.12.2005 0-4 Yhteensä 616 21.10.2005 5.12.2005 313-303 *MGM = Management ryhmä, DEV = kehittäjät, ALL = kaikki 6.4 Toteutus 2 (I2) Tavoitteet: järjestelmän viimeistely dokumentaation viimeistely vertaistestaus järjestelmän luovuttaminen asiakkaalle projektin päättäminen Tuotokset: Ohelmistoon korjattavat/lisättävät toiminnallisuudet tärkeysjärjestyksessä: bugien korjaus asiakkaan ilmoittamien kehityskohteiden toteuttaminen, mm.
mittaustietojen DDE-siirto (Dynamic Data Exchange), ts. mahdollisuus kopioida taulukon sisältämää dataa kätevästi Noheva II:n ja Excelin välillä tietojen vienti: CSV raportti säädatan hakeminen kannasta projektin perus- ja rengastietojen haku kannasta yksittäisohjelmaan xml-muotoisen projektitiedoston tallennus kantaan sääkäyrät esille tulevat ja/tai asiakkaan esittämät ns. nice to have ominaisuudet Dokumentit: käyttöohje, testiraportit ja lokit, sepa-päiväkirjat, projektisuunnitelma jne. Projektisuunnitelma SEPA-päiväkirjat Vaatimusmäärittely Tehtävät: Nimi Arvio Vastuuhlö Alkupvm Loppupvm Tehty Ero Raportti ja raportointi 120 (liittyminen) tietokanta(an) Laskentaan liittyvät toimet tjkorho3, thellste, stikkane 1.1.2006 2.3.2006 113-7 60 tjkorho3, thellste 18.1.2006 2.3.2006 83 23 50 jmaneliu 18.1.2006 2.3.2006 37-13 Käyttöliittymä 45 jmaneliu 18.1.2006 2.3.2006 40-5 Raakadatan käsittely 40 marko 14.1.2006 2.3.2006 8-32 Säädatan käsittely ja CSV export Testauksen suunnittelua ja testausta 30 marko 18.1.2006 2.3.2006 57 27 50 mjkekkon,stikkane 18.1.2006 2.3.2006 40-10 Testaus 60 DEV 18.1.2006 2.3.2006 56-4 Vertaistestaus 35 ALL 17.2.2006 2.3.2006 8-27 Testauksen suunnittelua ja testausta 20 stikkane 18.1.2006 2.3.2006 22 +2 Ryhmätapaamiset 40 ALL 18.1.2006 2.3.2006 34-6 Asiakastapaamiset ja demot 15 MGM/ALL 17.1.2006 2.3.2006 6-9 Mentortapaamiset 6 MGM 18.1.2006 2.3.2006 2-4 Iteraatiosuunnitelma 5 mjkekkon 16.1.2006 2.3.2006 4-1
Dokumentointi 62 ALL 18.1.2006 2.3.2006 27-35 Edistymisraportin tekeminen 4 mjkekkon 25.2.2006 2.3.2006 5 1 Yleistä suunnitelua 15 MGM 1.1.2006 2.3.2006 6-9 Laadunvarmistus 0 MGM 1.1.2006 2.3.2006 4 4 Yhteensä 657 552-105
7. Riskiloki Taulukko 9: Riskilogi ID Riski Vaikutukset Hallintatoimenpiteet Vastuuhenkilö 1 2 3 4 5 Ryhmän jäsen keskeyttää Ryhmän jäsenten ajankäytölle on asetettu rajat etukäteen. Jokin proejktiryhmän jäsenistä sairastuu kriittisellä hetkellä ennen demoa / palautusta Tuotteen vaatimusmäärittely ei ole onnistunut Asiakas ei ole tyytyväinen tuotteeseen Projektin kannalta tärkeää tietoa poistuu ryhmästä. Muut kuormittuvat, projektin laajuutta tulee vähentää. Aika loppuu kesken, eikä tuotetta saada aikarajojen puitteissa valmiiksi Tuotteen toiminnallisuus jää vajaaksi Koko projektin aikataulu siirtyy ja aika loppuu kesken Asiakas on tuhlannut arvokasta aikaa ja rahaa projektiin Tulee ylläpitää hyvää yhteishenkeä ryhmän sisällä. Toteutuksen elintärkeät osa-alueet tulee suorittaa pariohjelmointina. Tehtävät priorisoidaan, ja ensiksi toteutetaan tärkeimmät tehtävät Mitä lähempänä iteraation loppua ollaan, sitä useamman henkilön täytyy olla selvillä kehityksen kulusta Panostetaan suunnitteluun Pidetään asiakkaan kanssa tapaamisia ja demotaan ohjelmistoa iteraatioiden aikana jolloin saadaan palautetta riittävän usein Koko projektiryhmä / projektipäällikkö projektipäällikkö projektipäällikkö manageriryhmä Koko projektiryhmä Lähdeluettelo [1] Test World Oy, http://www.testworld.fi/?sivu=testworld&kieli=fi, tarkistettu 11.10.2005