T-76.115 Projektisuunnitelma

T-76.115 Projektisuunnitelma ETL-työkalu Versio Päivämäärä Tekijä Kuvaus 0.1 20.10.2004 Timo Sallinen Ensimmäinen versio 1.0 22.10.2004 Timo Sallinen Korjauksia, lisätty 1.4 ja 5.3 1.1 26.10.2004 Mikko Ruokojoki Korjauksia 1.2 26.10.2004 Teemu Nousiainen 5.1, kommunikointi 1.3 27.10.2004 Mikko Ruokojoki 5.1.3 & 5.3.1.4 Katselmointien muokkaus 1.4 27.10.2004 Teemu Nousiainen 5.3 täydennystä 1.5 27.10.2004 Teemu Nousiainen Katselmoinnissa löydetyt virheet 1.6 27.10.2004 Timo Sallinen 5.1.5 muutoksia. 1.7 28.10.2004 Teemu Nousiainen Kappaleasettelu oikeaksi 1.8 28.10.2004 Mikko Ruokojoki Asiakkaan topten päivitetty 2.0 28.10.2004 Teemu Nousiainen Dokumenttien yhdistely 2.1 1.11.2004 Mikko Ruokojoki 3. kappaletta päivitetty 2.2 18.11.2004 Mikko Ruokojoki Korjattu kappale 5.1.6 2.2 23.11.2004 Timo Sallinen Korjattu 4.3 & 3, pieniä viilauksia 2.3 28.11.2004 Mikko Ruokojoki Päivitetty työarvioita ja pieniä viilauksia 2.4 28.11.2004 Mika Suvanto Oikolukua, laadunvarmistus viitteeksi 2.5 29.11.2004 Timo Sallinen Oikolukua, korjattu 3. kappale 2.6 7.2.2005 Mikko Ruokojoki Päivitetty tuntikirjanpito Sivu 1 / 21

Sisällysluettelo 1 Johdanto... 2 1.1 Projektin tarkoitus ja laajuus... 2 1.2 Järjestelmät ja ympäristö... 3 1.3 Oikeudet tuotteeseen... 3 1.4 Termistö...4 2 Projektin organisaatio... 5 2.1 Projektiryhmä... 5 2.2 Muut sidosryhmät...8 3 Tavoitteet... 8 3.1 Asiakkaan tavoitteet... 8 3.2 Ryhmän tavoitteet...10 3.3 Projektin keskeyttämisen kriteerit... 10 3.4 Projektin lopettamisen kriteerit... 11 4 Resurssit ja budjetti...11 4.1 Henkilöstö- ja aikaresurssit... 11 4.2 Laite- ja ohjelmistoresurssit...12 4.3 Budjetti... 12 5 Työskentelytavat ja työkalut... 13 5.1 Käytännöt...13 5.2 Ryhmän SEPA-aiheet...17 5.3 Laadunvarmistuksen suunnitelma... 18 5.4 Työvälineet... 18 5.5 Standardit...18 6 Vaiheistus...18 6.1 Aikataulu... 21 7 Riskiloki...21 8 Dokumentin hyväksyntä...21 9 Liitteet... 21 1 Johdanto 1.1 Projektin tarkoitus ja laajuus Projektin tarkoitus on suunnitella ja toteuttaa ETL-työkalu Aureolis Oy:lle osana Teknillisen korkeakoulun Tietojenkäsittelyopin ohjelmatyö (T-76.115) kurssia. Projekti kestää koko lukuvuoden 2004-2005 ja sisältää neljä eri vaihetta, suunnittelun (PP), kaksi toteutuskierrosta (I1 ja I2) ja viimeistely/toimitusvaiheen (FD). Jokaisen vaiheen sisällä työt pilkotaan pienemmiksi, iteratiivisiksi prosesseiksi. Projektin aihe, ETL-työkalu, tulee sanoista Extract-Transform-Load. Kyseessä on tiedon poiminta, sen käsittely eri tavoin ja tiedon lataaminen tietovarastoon. Tietovarastoinnissa tarvitaan työkalua, jonka avulla tietoa voidaan muokata mahdollisimman automaattisesti erilaisin toimenpitein. Yleinen esimerkki on tiedon denormalisointi, jonka avulla Sivu 2 / 21

helpotetaan tiedon jalostamisen ja raportoinnin tarpeita. Projekti vaatii laajaa tietämystä tietokannoista ja tietovarastoinnista. Työ toteutetaan seitsemän hengen opiskelijaryhmässä. Työmäärä on kiinnitetty 1400 työtuntiin. Projektiryhmän työtä ohjaa ja vetää ryhmän keskuudestaan valitsema projektipäällikkö. Hän on pääasiallinen vastuuhenkilö myös asiakkaan suuntaan projektin onnistumisesta. Teknillisen korkeakoulun puolelta työtä ohjaa mentor. Opiskelijoiden tarkoituksena on oppia laajan ohjelmistoprojektin läpikäymistä ja asiakasta kiinnostaa lopputuloksena syntyvä, omassa liiketoiminnassaan hyödyllinen ohjelmisto. Asiakkaan eli Aureoliksen puolelta työssä avustavat tekninen asiantuntija ja tekninen johtaja. 1.2 Järjestelmät ja ympäristö Ohjelmisto toteutetaan käyttöjärjestelmästä ja laitealustasta riippumattomaksi pääosin Java- ohjelmointikielellä. Taustalla olevia järjestelmiä ovat erilaiset tietovarastot ja operatiiviset tietokannat. Ohjelmisto on tarkoitettu lähinnä asiakkaan asiantuntijoiden käyttöön. Tulevaisuudessa on mahdollista, että käyttäjiä ovat myös Aureoliksen asiakkaat. Olennainen osa ohjelmistoa on kuvauskieli, jonka avulla voidaan kuvata ETL-työkalun sisältämiä prosesseja ja niiden suhteita toisiinsa. Prosesseista voidaan luoda verkkomainen kuvaus, jolloin eri aliprosessit voivat toimia rinnakkaisesti. Ohjelmistoon suunnitellaan useita rajapintoja, joiden tarkoituksena on käsitellä erimuotoista tietoa ja mahdollistaa prosesseihin liitettävien toimenpiteiden luonti: Erilaisten syötteiden käsittelyrajapinnat (eri tietokantatyypit, eri tiedostotyypit) Prosesseihin liitettävien toimenpiteiden rajapinta 1.3 Oikeudet tuotteeseen Tekijänoikeuksista on sovittu erillisellä sopimuksella. Sivu 3 / 21

1.4 Termistö Suomeksi Englanniksi Selitys DW, tietovarasto DW, data warehouse Kohdetietokanta, johon tallennetaan kunkin ETLprosessin suorituksesta saatu lopputulos. Tietovarastoa ei juuri muokata (paitsi silloin kun suoritetaan ETL-prosessi), vaan siihen tehdään ainoastaan kyselyjä. ETL-prosessi (myös ETT tai ETM) ETL process Datan lukeminen lähdeaineistosta (extract), muokkaaminen (transformation) ja tallentaminen tietovarastoon (load / transportation / move) Osaprosessi, tehtävä Subprocess, task ETL-prosessiin kuuluva yksittäinen datan muokkaus-, kopiointi- tai muu toimenpide. Mentor Mentor Projektiryhmän tukihenkilö ja ohjaaja PP-vaihe Project Planning Projektin suunnitteluvaihe. Muita vaiheita esim. toteutusvaihe I ja toteutusvaihe II Iteraatio Iteration Tietyn pituinen aikajakso, jonka kuluessa ohjelmaa kehitetään eteenpäin suunnitelman mukaisesti. Syöte Input Osaprosessin saama syöte, josta tulos muodostetaan. Tulos Output Osaprosessin syötteestä muodostama tulos. Toimenpide Ks. osaprosessi Operaatio Operation Toimenpide. Ks. osaprosessi Taulukko 1: Termistö Sivu 4 / 21

Kaavio 1- Projektin osapuolet ja organisaatio 2 Projektin organisaatio 2.1 Projektiryhmä Sivu 5 / 21

Nimi: Rooli / vastuu: Kiinnostuksen aiheet: Mikko Ruokojoki Projektipäällikkö, riskienhallinta - Oppia projektijohtamista ohjelmistoprojekteissa - Oppia toimimaan hyvänä asiakasrajapintana projektissa - Oppia projektin ajanseurantaa, toteutumisseurantaa - Tulla tutuksi projektihallinnan työkaluihin Puhelin: 0400 709 319 Sähköposti: mikko.ruokojoki(at)nomenal.fi Nimi: Rooli / vastuu: Kiinnostuksen aiheet: Risto Kunnas Testaus, dokumentointi - Tavoitteena tulla paremmaksi Javaohjelmoijaksi - Tavoitteena syventää tietämystä testauksesta Puhelin: 050 5893560 Sähköposti: Nimi: Rooli / vastuu: Kiinnostuksen aiheet: rkunnas(at)cc.hut.fi Mika Suvanto Riskienhallinta Tavoitteinani on ensisijaisesti saada kokemusta ohjelmistokehityksestä vähän suuremmassa ryhmässä, sillä aiemmin olen työskennellyt lähinnä 2-4 hengen ryhmissä. Tarkoitus olisi myöskin kerätä kokemusta hieman hallitummasta projektin läpiviennistä ja tässä hyödyllisistä käytännöistä ja työkaluista. Toki tavoitteisiin kuuluu kurssin läpäiseminen siihen varatuilla resursseilla ja lopputulos, joka tyydyttää koko ryhmää sekä asiakasta. Puhelin: 050 338 5345 Sähköposti: mika.suvanto(at)hut.fi Sivu 6 / 21

Nimi: Rooli / vastuut: Kiinnostuksen aiheet: Teemu Nousiainen Pääohjelmoija, testaus Tärkeimpänä oppimispäämääränä kurssilla on selkeän kokonaiskuvan saaminen ohjelmistoprojektista. Aikaisempi kokemukseni ohjelmistoprojektin läpiviemisestä on vähäistä, joten yritän saada mahdollisimman paljon käytännön kokemusta. Keskityn testaamisen suunnitteluun ja testauksen toteuttamiseen. Puhelin: 040 743 8174 Sähköposti: Nimi: Rooli / vastuut: Kiinnostuksen aiheet: tnousiai(at)cc.hut.fi Timo Sallinen Dokumentointi -Kokemuksen saaminen laajemmassa projektiryhmässä toimimisesta -Henkilökohtaisten ohjelmistokehitysmetodien kehittäminen ja kokonaiskuvan saaminen ohjelmistotuotannon formaaleista menetelmistä Puhelin: 040 701 8179 Sähköposti: timo.sallinen(at)hut.fi Nimi: Rooli / vastuut: Kiinnostuksen aiheet: Jani Malmi Vaatimusmäärittely, muutosten hallinta Tavoitteenani on oppia uusia asioita tiimityöskentelystä vähän isommassa ryhmässä. Harvinainen tilanne, että näin monta työskentelee saman ohjelmiston parissa. Haluna oppia myös uusia asioita ohjelmistotuotannosta sekä jotain uutta testauksesta ja erilaisista järjestelmistä. Haluna myös läpäistä kurssi ja tehdä hyvää työtä. Puhelin: 040 715 9214 Sähköposti: jani.malmi(at)tietoenator.fi Sivu 7 / 21

Nimi: Rooli / vastuut: Kiinnostuksen aiheet: Jani Honkanen Arkkitehtuuri, vaatimusmäärittely, muutosten hallinta. - kokemusta projektityöskentelystä - kokemusta oikean asiakkaan vaatimusten huomioinnista - kokemusta arkkitehtuurisuunnittelusta - kurssin läpäisy (pakollinen) - merkintä kurssista CV:hen Puhelin: 040 774 0220 Sähköposti: jmhonka2(at)cc.hut.fi 2.2 Muut sidosryhmät Asiakas: Arto Arffman, Tekninen johtaja / Aureolis Oy arto.arffman(at)aureolis.com puh. 040 8422 750 Markus Rautopuro, Tekninen asiantuntija/ Aureolis Oy markus.rautopuro(at)aureolis.com puh. 040 8422 751 Kurssihenkilökunta: Petri Saloma, Mentori psaloma(at)cc.hut.fi 3 Tavoitteet Tässä kappaleessa kuvaillaan projektin tavoitteita eri näkökulmista. Varsinaiset vaatimukset on kuvattu vaatimustenmäärittelydokumentissa. 3.1 Asiakkaan tavoitteet Alla olevassa taulukossa on kuvattu asiakkaan Top-10 tavoitteet projektista: Sivu 8 / 21

Taulukko 2: Asiakkaan tavoitteet Tavoite Toiminnoiltaan karsittu ETL-työkalu, jonka perusteella voimme päättää jatketaanko oman ETL-työkalun kehitystä ETL-työkalun kuvauskieli, joka on laajennettavissa tarpeen mukaan Riittävä operaatioiden rajapinta, jotta sitä voidaan käyttää myöhemmin toteutettavien operaatioiden toteuttamiseen Versio ETL-työkalusta, josta voidaan jatkojalostaa käyttökelpoinen kehittynyt versio (ohjelman perustukset tehty huolella) ETL-työkalu toimii vaatimusten mukaisesti. ETL-työkalun prosessien dokumentointitoiminnosta prototyyppitasoinen versio ETL-työkaluun liittyvien, uusien tekniikoiden testaus käytännössä Tietovarastopuolen kehittäminen Tarjota parempia palveluita asiakkaille Asiakaskunnan kasvattaminen uuden työkalun avustuksella Arviointikriteeri Työkalu täyttää vähintään sille asetetut kriittiset ja korkeat vaatimukset. Voidaan käyttää toteutettujen toimenpiteiden osalta ETL-prosessien ajamiseen. Kuvauskielellä voidaan määritellä toimiva ETL-prosessi. Rakenteellisia muutoksia ei vaadita uusia toimenpiteitä lisättäessä. Rajapinnat ja arkkitehtuuri mahdollistavat uusien toimenpidekomponenttien suoraviivaisen lisäämisen ilman muutoksia muihin sovelluksen osiin. Ohjelman arkkitehtuuri ja rajapinnat on suunniteltu huomioonottaen myös tulevat vaatimukset, joita ei toteuteta projektin aikana. ETL-työkalun moottori pystyy suorittamaan prosessin ja toimimaan virhetilanteissa määrittelyjen mukaisesti ETL-prosessista voidaan luoda automaattisesti kuvaus, josta käy ilmi vähintään toimenpiteiden syötteet/tulokset ja keskinäiset suhteet. Toteutettu vähintään prototyyppitasoinen versio tekniikoista. Asiakas arvioi projektin tulosten sovelluskelpoisuuden perusteella. Asiakas arvioi projektien tulosten sovelluskelpoisuuden perusteella. Asiakas arvioi työkalun toiminnallisuuden ja jatkokehityskelpoisuuden perusteella. Muut tavoitteet Näiden lisäksi Aureolis asettaa hankkeelle kokonaisuudessaan seuraavia tavoitteita: 1. Oman ETL-työkalun järkevyyden arviointi 2. Kaupallisia työkaluja paremman välineistön kehittäminen. (ominaisuuksien painotus ETL:n kehittämisen näkökulmasta ja käytännössä havaittujen puutteiden "paikkaus") 3. Kannoista ja käyttöjärjestelmistä riippumattoman sekä hinnaltaan skaalautuvan välineen saaminen käyttöön 4. Uudet tekniikat ja menetelmät Sivu 9 / 21

5. Oma väline -> kontrolli hinnoitteluun -> järkevä hinnoittelumalli tuotteeseen integroitaessa tai myytäessä ratkaisuja pienille asiakkaille (lisäarvon myynti) 6. Kehittämisen ja ylläpidon kustannustehokkuuden parantaminen 7. Kehityksen nopeuttaminen 8. Ratkaisujen uudelleenkäytettävyyden helpottaminen 9. Riippuvuuden vähentäminen välinetoimittajista 10.Yrityskuvan muuttaminen/parantaminen (välineen ja projektiryhmän kautta) 3.2 Ryhmän tavoitteet Projektiryhmän tavoitteita ovat: Tavoite Kehittää jatkokehityskelpoinen tietovarastointijärjestelmän runko. Oppia työskentelemään ja kehittää taitojaan ohjelmistoprojektissa. Oppia toimimaan osana ohjelmistokehitysryhmää ja kehittää omaa tietotaitoa asian tiimoilta Kurssin menestyksellinen suoritus annettujen rajoitteiden puitteissa (tuntimäärät). Arviointikriteeri Arvioidaan suhteessa vaatimusten toteutusasteeseen ja arkkitehtuurisuunnittelun huolellisuuteen. Ryhmän jäsenet arvioivat suhteessa henkilökohtaisiin tavoitteisiinsa. Ryhmän jäsenet ovat päässeet tutustumaan mahdollisimman laajasti eri tehtäviin ja haasteisiin, joita hajautetussa ryhmätyöskentelyssä tulee vastaan. Arvioidaan projektin lopputuloksen ja käytettyjen resurssien perusteella. Taulukko 3: Ryhmän tavoitteet 3.3 Projektin keskeyttämisen kriteerit Riippuen ongelmien vakavuudesta, on mahdollista, että projekti joudutaan keskeyttämään ennen sen loppumista. Tällaisia riskejä on kuvattu erikseen riskienhallinnan dokumentissa ja ne ovat luokiteltu kriittisiksi. Näitä ovat esimerkiksi tilanne, jossa useampi ryhmän jäsen joutuu jättämään projektin kesken. Tällöin on syytä harkita projektin keskeyttämistä. Kriiteerit keskeyttämiselle ovat seuraavat: Muutoksista johtuva töiden lisäys tulee ylivoimaiseksi nykyisille ryhmän jäsenille toteuttaa kurssin antamassa aikataulussa Asiakkaan puolelta tullut pyyntö lopettaa kehitystyöt Projektin keskeyttämisestä keskustellaan yhdessä asiakkaan, mentorin ja ryhmän jäsenten kesken ja sovitaan asiaan liittyvistä tehtävistä. Voidaan kuitenkin todeta, että projektin keskeyttäminen ei ole tarkoitus ja syiden pitää olla painavia, jotta kyseistä toimenpidettä tehdään. Sivu 10 / 21

3.4 Projektin lopettamisen kriteerit Projektin lopettamisen kriteerit määritellään, jotta voidaan todeta milloin projekti on syytä lopettaa. Kurssi määrittelee projektille aikarajat, jonka sisällä projektin toteutus pitää tehdä. Sitä ei kuitenkaan ole estetty, etteikö kehitystyö voisi jatkua seuraavassa projektissa, asiakkaan järjestelmänä. Projekti loppuu jos jokin seuraavista toteutuu: Kurssin määrittelemät aikarajat toteutukselle umpeutuvat Sovitut tavoitteet asiakkaan, ryhmän ja kurssin puolelta ovat saavutettu Projektin lopettaminen hyväksytään kurssin ja asiakkaan puolelta. Tällöin keskustelua käydään tavoitteiden onnistumisesta ja tuloksien sisällöstä. 4 Resurssit ja budjetti 4.1 Henkilöstö- ja aikaresurssit Kurssin laajuudeksi on määritelty 5 opintoviikkoa, joka vastaa noin 190 h työtä per opiskelija. Ryhmässämme on 7 henkilöä, jolloin yhteinen työmäärä on 1330 miestyötuntia. Alla on määritelty tarkemmin jokaisen henkilön arvio työtunneista ja niiden jakautumisesta projektin aikana. Vaihe Mikko Jani H Jani M Risto Mika Teemu Timo PP 78 57 51 25 44 55 36 346 I1 69 93 38 40 49 59 39 387 I2 39 33 78 50 55 61 62 378 DE 4 8 23 75 42 16 52 220 190 190 190 190 190 190 190 1330 Taulukko 4: Henkilöstö- ja aikaresurssit päivitetty 7.2.2005 Työmääräarviot jäsenten kesken Työtunneista on laskettu yhteensä 190 tuntia, koska kurssin puolelta on arvioitu SEPAaiheiden työstämiseen kuluvan erikseen 10h/henkilö. Työmäärät perustuvat ryhmän jäsenien eri vastuualueisiin ja heidän henkilökohtaisiin toiveisiinsa. Alla on määritelty tarkemmin painotuksien syitä. Henkilö Mikko Jani H Työmäärien painotuksien syyt Projektipäällikön työt vaikuttavat paljon työmääriin. Projektin käynnistäminen, suunnitelmien teko ja rutiinien hiominen työllistävät alkuvaiheessa enemmän. Vastuualueena arkkitehtuuri, painotusta alkupuolelle. Varamiehenä vaatimusmäärittelyissä. Sivu 11 / 21

Henkilö Jani M Risto Mika Teemu Timo Työmäärien painotuksien syyt Vastuualueena vaatimusmäärittelyt, painotus alkupuolelle. Varamiehen arkkitehtuurissa. Vastuualueena testaus ja laadunvalvonta, painotusta toteutusvaiheisiin. Varamiehenä dokumentoinnissa. Vastuualueena riskienhallinta, painotusta alkupuolelle ja toteutusvaiheisiin. Pääohjelmoija ja panostusta työkalujen ylläpitoon ja toteutukseen, varamiehenä testauksessa ja laadunvalvonnassa. Vastuualueena dokumentointi, painotusta loppupuolelle. Taulukko 5: Työmääräarviot jäsenten kesken 4.2 Laite- ja ohjelmistoresurssit Työn toteutuksessa ryhmän jäsenet käyttävät omia kotitietokoneitaan ja tarvittaessa Teknillisen korkeakoulun tarjoamia tietokoneluokkia. Ohjelmistoresurssit ovat kaikki saatavilla ilman maksullisia lisenssejä. Mikäli tarvetta maksullisille ohjelmistoille ilmenee, asiasta sovitaan asiakkaan kanssa 4.3 Budjetti Projektin ollessa opiskelutyö, ei työtunteja laskuteta asiakkaalta. Mielenkiinnon vuoksi kuitenkin oheisena on laskettu arvio projektin toteuttamisesta todellisuutta lähellä olevilla hinnoilla. Kyseisessä tilanteessa ohjelmiston toteutus tilattaisiin yritykseltä, joka toteuttaisi työn tuntilaskutuksen perusteella. Näin tilauksen tehneen yrityksen ei tarvitse huolehtia työntekijöiden työkaluista tai työtiloista. Arvio perustuu olettamuksiin, että tuntilaskutushinnat eri osaamistasoille ovat seuraavat: Titteli Hinta/tunti Projektipäällikkö 90 Vanhempi suunnittelija/ohjelmoija 55 Suunnittelija/ohjelmoija 45 Jonka perusteella asiakkaan hinta koko projektille olisi seuraava: Titteli Hlömäärä Tunnit Yhteensä Projektipäällikkö 1 190 h 17 100 Vanhempi suunnittelija/ohjelmoija 4 760 h 41 800 Suunnittelija/ohjelmoija 2 380 h 17 100 Yhteensä 7 1330 h 76 000 Projektin toteuttavan yrityksen sisäinen laskutus perustuisi seuraaviin palkkoihin: 1330 h = 177,3 htp / 7 työntekijällä = 25,3 työpäivää / henkilö. Keskimäärin kuitenkin voidaan olettaa, että tehokasta työaikaa 7,5 tunnista on noin 5,5 tuntia, jolloin työpäivien Sivu 12 / 21

määräksi tulee 34,5. Tämä taas vastaa noin 1,5 kuukauden työtä. Palkkaus on kuukausitasolla: Titteli Palkka/kk Todelliset kustannukset yritykselle (~=palkka * 1.5 * hlömäärä) Henkilömäärä Projektipäällikkö 4200 6 300,00 1 Vanhempi suunnittelija/ohjelmoija 3800 22 800,00 4 Suunnittelija/ohjelmoija 2900 8 700,00 2 Joista laskemalla saadaan 1,5 kuukauden palkkamenoiksi 37800 Tämän lisäksi pitää laskea laitehankinnat työntekijöille, työtilojen vuokrat ja mahdolliset muut henkilöstöetujen maksut. Laskukaava on hieman optimistinen, sillä siinä ei huomioida työntekijöihin liittyviä riskejä, taustatyötä tekevien ihmisten palkkoja jne. Perimmäinen tarkoitus, eli budjetoinnin havainnollistaminen kuitenkin selviää yllä olevista laskelmista. 5 Työskentelytavat ja työkalut Projektiryhmä on sopinut työskentelytavoista projektin alussa. Ne sisältävät mm. kokous-, kommunikaatio-, koodaus- ja testauskäytännöt. Yhteisesti sovittujen tapojen tarkoituksena on helpottaa ryhmätyöskentelyä ja madaltaa käytännön esteitä kommunikoinnille, suunnittelulle ja kehitystyölle. 5.1 Käytännöt Palaverit Projektiryhmän työskentelytapoihin kuuluvat viikottaiset palaverit, joita varten projektipäällikkö tekee agendan. Palaverissa sihteeriksi valittu tekee kokousmuistion, joka julkaistaan agendan kanssa projektin kotisivulla. Koko ryhmää koskevat palaverit järjestetään pääsääntöisesti torstaisin, sillä tämä päivä todettiin parhaiten sopivaksi. Tämän lisäksi eri vastuualueiden pienemmät ryhmät pitävät tarvittaessa omia tapaamisia. Asiakkaan kanssa ollaan yhteyksissä vähintään viikottain (viikkoraportti, ks. 5.1.3). Kommunikointi Projektiryhmällä on kotisivut osoitteessa http://www.hut.fi/~tnousiai/t-76.115/. Sivuilla julkaistaan: Kokousmuistiot Viikkoraportit Työtehtävälistat Sivu 13 / 21

Kurssin palautukset Tapaamisten kalvot Kotisivujen päivittämisestä vastaa Teemu. Projektiryhmän uutispalvelin toimii tietopankkina ja ryhmän sisäisenä dokumenttien levityskanavana sekä keskusteluvälineenä. Ryhmällä on käytössään myös web-pohjainen kalenteri, johon kirjataan ryhmää koskevat aikataulut ja tapaamiset. Ryhmällä on käytössään Internet News-palvelin (snntpd, progress.tky.hut.fi), jota käytetään SSH-tunnelin yli tietoturvan takaamiseksi. Se on ryhmän pääasiallinen keskustelukanava ja sinne lähetetään myös uusimmat aineistot ja keskustellaan tilanteesta. Keskustelun ahkeruutta kuvaa se, että uutisryhmään on 26.10.2004 mennessä tullut 130 viestiä. Muita kommunikointitapoja ovat sähköposti ja MSN Messenger. Sähköpostia käytetään vain kiireelliseen ja henkilökohtaiseen kommunikointiin. Tällä pyritään välttämään sähköpostitulvaa ja sitä, että tärkeä viesti jäisi huomaamatta. 5.1.1 Iteratiivinen kehitystyö Työn pilkkominen riittävän pieniksi tehtäviksi ja kehitysvaiheiden iterointi on tärkeää suuren kokonaisuuden hallitsemiseksi. Iterointia toteutetaan erityisesti jokaisen vaiheen alussa läpikäymällä sovitut tehtävät vaiheelle ja pilkkomalla ne pieniksi kokonaisuuksiksi viikottain. Tehtävän sopiva koko arvioidaan niin, että sen voi tehdä yksi henkilö alle viikossa (kurssin työviikkona, n. 10 h). Laadun takaamiseksi työn tuloksia katselmoidaan ryhmissä ja laaditaan tärkeille kokonaisuuksille useita iterointikierroksia. 5.1.1.1 Neuvottelut asiakkaan kanssa Projekti sisältää neljä eri vaihetta ja jokaisen vaiheen jälkeen on syytä keskustella asiakkaan kanssa edellisen vaiheen tuloksista. Samoin tutkitaan, mitä uutta seuraavassa vaiheessa pitää ottaa huomioon: Mietteet edellisestä vaiheesta ja mahdolliset parannus/muutosehdotukset Vaatimusmäärittelyiden paikkaansapitävyys ja mahdolliset korjaukset Riskienhallinnan tilanne ja mahdolliset uudet riskit Mahdollisuuksien kartoitus ja niiden kirjaaminen (positiiviset riskit) Asiakkaan kanssa keskustelu asiasta tehdään jo osittain palautetilaisuudessa, joka on pakollinen kurssin puolelta. Tämän lisäksi on hyvä pitää erillinen kokous, jossa voidaan keskustella lisää yllä olevista aiheista. 5.1.1.2 Vaatimusmäärittelyn hallinta Vaatimusmäärittelyn luonti tehdään kolmella viikon kestävällä iterointikierroksella PPvaiheessa. Tämä jälkeen vaatimusmäärittelyä käydään läpi vaiheiden alussa ja Sivu 14 / 21

keskustellaan muutoksista asiakkaan kanssa. Kaikki muutokset sovitaan kirjallisesti ja niiden aiheuttamat lisätyöt/poistot arvioidaan. Vaatimushallintaa hoitaa vastuuhenkilönä Jani Malmi. 5.1.1.3 Arkkitehtuurin hallinta Ohjelmistoarkkitehtuurin määrittely luodaan pääosin I1-vaiheessa, mutta sitä ylläpidetään jatkuvasti toteutusvaiheiden aikana. Muutoksien vaikutukset selvitetään ennen muutoksia ja kaikista oleellisista muutoksista neuvotellaan asiakkaan kanssa ensin. Vastuuhenkilönä arkkitehtuurissa on Jani Honkanen. Muutostenhallinta tullaan suorittamaan formaalisti. 5.1.1.4 Testauksen hallinta Testaussuunnitelmat tehdään alustavasti PP-vaiheessa, mutta varsinainen tarkempi suunnittelu toteutetaan toteutusvaiheissa. Testaukselle on määritelty oma vastuuhenkilö (Risto), joka pitää kirjaa tilanteesta ja ilmoittaa projektipäällikölle ja riskienhallinnasta vastaavalle mahdollisista ongelmista. Testaus on hyvin tärkeässä osassa, sillä työkalun toimintaan pitää ehdottomasti pystyä luottamaan. 5.1.2 Iteraatiovaiheiden suunnittelu Vaiheiden tarkempi suunnittelu tehdään aina ennen vaiheen alkua. PP-vaiheessa kuitenkin luodaan alustavat pohjat kaikelle toiminnalle projektin aikana. Suunnittelu tehdään asiakkaan ja ryhmän yhteisten sopimusten pohjalta kussakin tilanteessa. 5.1.3 Ajankäytön raportointi ja tehtävien jako Ajankäytön raportointiin ryhmä käyttää kurssin puolelta annettua Trapoli -järjestelmää. Projektipäällikkö tekee asiakkaalle ja mentorille viikoittain viikkoraportin, jossa käydään läpi edellisen viikon tehdyt työt ja työmäärät. Samoin arvioidaan tulevan viikon ohjelmaa ja työmääriä. Vaiheiden lopuksi arvioidaan työmäärien toteutuminen verrattuna suunnitelmiin. Työtehtävien jako on pääasiallisesti projektipäällikön vastuulla. Ryhmällä on viikoittaiset palaverit, joiden yhteydessä läpikäydään viikon aikana tehdyt työt. Samalla jaetaan uusia työtehtäviä seuraavalle viikolle. Projektin eri aihealueet ovat vastuutettu ryhmän jäsenille. Näiden kyseisten vastuualueiden tehtäväjakoa tekee myös kyseessä oleva vastuuhenkilö. Viikoittain ylläpidetään työtehtävälistaa, josta kukin ryhmän jäsen näkee hänelle tarkoitetut työt ja niiden tarkat määräajat. Jos suunnitelmiin tulee muutoksia, niin projektipäällikkö tai aihealueen vastuuhenkilö siirtää tarvittaessa työtehtävän toiselle henkilölle. 5.1.4 Virheiden seuranta Virheistä pidetään kirjaa asiakkaan järjestämällä JIRA-sovelluksella. Virhetietokantaan on pääsy sekä projektiryhmän jäsenillä että asiakkaalla. Virheen kirjaaminen on aina virheen löytäjän vastuulla. Mikäli virhe löytyy smoke test -testauksella tai automaattisella testauksella ja virhe pystytään saman tien korjaamaan, sitä ei kuitenkaan Sivu 15 / 21

merkitä tietokantaan. 5.1.5 Dokumentointi Kaikki dokumentaatio tuotetaan doc- ja sxw-formaatissa yhteensopivuusongelmien välttämiseksi. Dokumentteihin luodaan yhtenäinen tyylipohja, joilla ulkoasu saadaan yhtenäiseksi. Jokaisella dokumentilla on vastuuhenkilö, joka vastaa lopullisen dokumentin tuottamisesta. Kaikki tuotettu dokumentaatio käydään läpi katselmusmenettelyllä. Dokumentti Projektisuunnitelma Riskienhallintadokumentti Vaatimusmäärittely Tekninen spesifikaatio Testaussuunnitelma Testausraportti Käyttöohjeet Loppuraportti Taulukko 6: Dokumenttien vastuuhenkilöt 5.1.6 Projektin katselmoinnit Vastuuhenkilö Timo Mika Jani Malmi Jani Honkanen Risto Risto Jani Honkanen Mikko Katselmoinnit toteutetaan aina vaiheen lopussa. Kyseisessä tilaisuudessa käydään läpi menneen vaiheen tulokset ja nykyinen tilanne tehtävien ja työmäärien kannalta. Katselmointiaineisto luodaan ryhmän kesken jakamalla osatehtäviä ja luomalla yhteinen dokumentti. Pääasiallisesti katselmoinnin sisällöstä on vastuussa projektipäällikkö, joka esittelee tuotokset tilaisuudessa. Katselmointi eroaa hieman projektissa muuten käytettävästä, formaalista katselmoinnista, josta puhutaan laadunvarmistusdokumentissa [2]. Projektin katselmoinnissa on mukana asiakkaan edustajat, mentor, kurssin puolelta edustaja(t) ja ryhmän jäsenet. 5.1.7 Vaatimustenhallinta Pyrimme keskustelemaan projektin eri vaiheessa vaatimuksista asiakkaan kanssa niin paljon kuin tarpeellista, jotta saamme todelliset vaatimukset tuotua esille. Asiakkaan kanssa kommunikoi vaatimuksista kolmen hengen ryhmä: Jani Honkanen, Mikko Ruokojoki ja Jani Malmi. Tarvittaessa myös muut voivat osallistua näihin tapaamisiin. Pyrimme analysoimaan ja validoimaan vaatimukset myös useamman henkilön avulla, mutta päävastuussa tästä ja vaatimusten hallinnasta on Jani Malmi. Luokittelemme vaatimukset kurssin suosittamalla tavalla seuraavasti: toiminnalliset vaatimukset ei-toiminnalliset vaatimukset rajoitteet Sivu 16 / 21

käyttäjävaatimukset (käyttötapaukset). Muutenkin noudatamme kurssin vaatimustenmäärittelyn suosituksia ja ainoastaan tiettyjen taulukoiden rakenteen kohdalla olemme tehneet omia valintojamme. Tulemme päivittämään viikottain vaatimustenmäärittelydokumenttia sen vaatimusten statusten suhteen. Samoin tarkkailemme vaatimusten muutoksia viikottain. Mikäli asiakas haluaa lisätä jonkun uuden vaatimuksen, tulemme tarkastelemaan asiaa vähintään kolmen hengen ryhmässä ja miettimään uuden vaatimuksen aiheuttamaa työmäärän lisäystä. Muutokset vaatimuksiin hyväksytään niiden ollessa järkeviä ja mahdollisia projektin kannalta. Muuten ne hylätään. Mikäli koemme omalta osaltamme tarpeelliseksi muuttaa vaatimuksia, tulemme keskustelemaan niistä asiakkaan kanssa hyvissä ajoin. 5.1.8 Versionhallinta Versionhallintaan käytetään CVS:ää. Sääntönä on, että vain kääntyvää koodia saa viedä kantaan. Muutoslokiin tulee aina kirjata tehdyt muutokset tiiviisti, mutta mahdollisimman kuvaavasti. Jokainen iteraatiopalautus leimataan leimalla muotoa: ITER_X_Y, jossa X on iteraation numero ja Y iteraation sisäinen juokseva numero. Leimaamisen ja muut CVS:ään liittyvät suuremmat operaatiot hoitaa keskitetysti Pääohjelmoija (Teemu). 5.1.9 Ohjelmointikäytännöt Käytämme Sun Microsystemsin virallisia koodikäytäntöjä (ks. http://java.sun.com/docs/codeconv/html/codeconvtoc.doc.html). Suurin osa kehitystyöstä tehdään Eclipse IDE:llä, johon on määritelty Sunin koodikäytännöt. Hyödynnämme sen automaattisia koodin generointi- ja muotoiluominaisuuksia. 5.1.10 Riskienhallinta Riskienhallinnasta on erillinen dokumentti, joka on tämän projektisuunnitelman liitteenä [1]. 5.1.11 Vertaistestaus Vertaistestauksen järjestämisestä sovitaan yhdessä asiakkaan ja vertaisryhmän kanssa. Vertaisryhmän testauksesta saadaan eniten irti, jos vertaisryhmä keskittyy destruktiiviseen testaukseen. Yleisesti ottaen negatiivisia testitapauksia on helpompi keksiä, jos ei tunne järjestelmää kovin hyvin. Vertaisryhmän tekemistä testeistä kerätään talteen syötteet ja tulosteet, jotta voidaan jälkeenpäin analysoida mitä testattiin. Monimutkaisessa prosessissa ei ole aina itsestään selvää, oliko ohjelman toiminta virheellistä vai ei. 5.2 Ryhmän SEPA-aiheet SEPA (Software Engineering Practice Assignment) on jaettu ryhmän kesken seuraavasti: Sivu 17 / 21

Työmäärät / vaihe Pari Vastuuhlö SEPA-aihe PP I1 I2 DE Jani H & Mika Jani H Design patterns 60% 40% Jani M & Teemu Teemu Test automation on system test level 20% 40% 40% Risto & Timo Timo Static Methods 20% 60% 20% Mikko Mikko Progress tracking and control 30% 25% 20% 25% SEPA-päiväkirja kuuluu kurssin vaatimuksiin. 5.3 Laadunvarmistuksen suunnitelma Laadunvarmistuksen suunnitelma on erillinen dokumentti, joka on tämän projektisuunnitelman liitteenä [2]. 5.4 Työvälineet Käytettävät kehitystyökalut Ohjelmointi: Eclipse 3.0, Java SDK 1.4 Kaavioiden suunnittelu: MS Visio, Poseidon (tarvittaessa) Versionhallinta: Concurrent Versions System (CVS), eri client-versioita ja implementaatioita, mm. WinCVS Virhetietokanta: Atlassian JIRA 5.5 Standardit Projektissa käytämme seuraavia standardeja: J2EE (Java 2 Enterprise Edition) XML (Extensible Markup Language) UML (Unified Modeling Language) HTML (HyperText Markup Language) Sunin Code Conventions for the Java Programming Language Jyrki Kontion kehittämä RiskIt-mentelmä (Riskienhallinnan osalta osittain) 6 Vaiheistus Vaihe 1 projektin suunnittelu (PP) Tavoitteet Projektin suunnittelu Sivu 18 / 21

Asiakkaaseen tutustuminen Asiakkaan tarpeisiin tutustuminen Aiheeseen tutustuminen (ETL) Ryhmän jäsenten tutustuminen toisiinsa Työtavoista ja työkaluista sopiminen Ohjelmiston arkkitehtuurin suunnittelu Ohjelmiston rajapintojen suunnittelu Kommunikointi asiakkaan, mentorin ja ryhmän välillä Kommunikointi ryhmän sisällä Käyttötapauksien määrittely Vaatimusmäärittelyt Riskienhallinnan arviointi ja sovitut tavat seurata riskien kehitystä SEPA aiheiden valinta pareittain Toimitettava aineisto Projektisuunnitelma Vaatimusmäärittely Riskienhallinta Kokouspöytäkirjat ja viikoittaiset tilanneraportit Edistymisraportti (kalvoina) SEPA-päiväkirjat Vaihe 2 Toteutus 1 (I1) Tavoitteet Työtapojen ja työajan optimointi o Kokouksien vähentäminen o Kokouksien osallistujajoukon vähentäminen o Kommunikoinnin parantaminen Jatkaa arkkitehtuurista suunnittelua Aloittaa tekninen määrittely Aloittaa ohjelman toteuttaminen Toimitettava aineisto Päivitetty projektisuunnitelma Sivu 19 / 21

Päivitetty vaatimusmäärittely Tekninen spesifikaatio Testaussuunnitelma o Testausraportti o Testatut toiminnot Edistymisraportti Päivitetyt SEPA-päiväkirjat Näiden lisäksi asiakkaalle toimitetaan ensimmäinen versio ohjelmasta sisältäen tärkeimpiä perustoimintoja. Tarkempi suunnitelma I1 vaiheen sisällöstä ja iteraatiosta tehdään PP vaiheen lopussa. Vaihe 3 Toteutus 2 (I2) Tässä vaiheessa on tarkoitus edetä ohjelman toteuttamisessa seuraaviksi tärkeimpiin käyttötilanteisiin ja toteuttaa ne. Käyttöohjeiden laadinta aloitetaan ja arvioidaan nykytilanne vaatimusmäärittelyn ja toteutuneiden työaikojen tiedot. Tarkempi tämän vaiheen suunnittelu tehdään I1 vaiheen lopulla. Toimitettava aineisto Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen spesifikaatio Päivitetty testaussuunnitelma o Testausraportti o Testatut toiminnot Edistymisraportti Päivitetyt SEPA-päiväkirjat Käyttöohjeiden esiversio Näiden lisäksi asiakkaalle toimitetaan toinen versio ohjelmasta sisältäen uusia ominaisuuksia. Vaihe 4 Viimeistely/toimitus (FD) Tässä vaiheessa vertaisryhmän testituloksien mukaan korjataan ohjelmassa mahdollisesti esiin tulleet viat ja ongelmat. Viimeistellään käyttöohjeet, luodaan loppuraportti ja valmistellaan tuotteen toimitus asiakkaalle. Tarkempi vaiheen suunnittelu tehdään I2- vaiheen lopulla. Toimitettava aineisto Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen spesifikaatio Päivitetty testaussuunnitelma o Testausraportti o Testatut toiminnot Edistymisraportti Päivitetyt SEPA-päiväkirjat Sivu 20 / 21