PROJEKTISUUNNITELMA
PROJEKTISUUNNITELMA 2 (30) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus 0.1 22.9.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 22.9.2006 Aleksi Airola Lisäyksiä riskilogiin ja resursseihin 0.3 28.9.2006 Kaarlo Lahtela Riskin hallintaa lisätty. Aleksi Airola 0.4 1.10.2006 Aleksi Airola Lisätty kohdat 6-6.2 0.5 1.10.2006 Kaarlo Lahtela Oikoluku 0.6 2.10.2006 Aleksi Airola Kappale 1 lisätty 0.7 3.10.2006 Aleksi Airola Kappaleeseen 6.1 lisätty tekstiä ja kappaleeseen 6.2 lisätty tehtäviin allokoidut tunnit ja vastuulliset 0.8 4.10.2006 Aleksi Airola Päivitetty kappaleita 2.1 ja 3.2-3.4 0.9 5.10.2006 Aleksi Airola Lisätty kappale 4 ja 5.1.1 0.10 12.10.2006 Aleksi Airola Lisätty kappaleet 5.1.2, 5.1.3,5.1.5, 5.1.9-5.1.11, 5.1.13 ja 5.1.14 0.11 17.10.2006 Aleksi Airola Lisätty kappaleet 5.1.7-8, 5.1.12 ja 5.1.15-16 0.12 19.10.2006 Aleksi Airola Lisätty kappaleeseen 2 organisaatiokaavio ja kappaleet 5.1.4, 5.1.6 ja 5.1.17. Päivitetty riskilogi 0.13 21.10.2006 Aleksi Airola Päivitetty katselmoinnissa havaittujen puutteiden mukaan kappaleita 1.-5.1 0.14 21.10.2006 Aleksi Airola Päivitetty kappaleita 6, 6.1, 6.2 ja lisätty kappale 6.3 0.15 21.10.2006 Aleksi Airola Päivitetty kappaleeseen 4.1 varatut työtunnit taulukkoa 0.16 Kaarlo Lahtela Dokumentin läpiluku ja taiton tarkistaminen. 0.17 Tuomas Tolvanen Päivitetty työkalu-kappaletta 1.0 Aleksi Airola Julkaisu versio 1.1 2.11.2006 Aleksi Airola Lisätty kappaleet 5.1.18, 5.1.19 ja 6.3 sekä muokattu kappaletta 5.1.3 1.2 2.11.2006 Aleksi Airola Muokattu kappaletta 2.1 vastuiden osalta ja riskit päivitetty 1.3 2.11.2006 Kaarlo Lahtela 5.1.8 virheiden seuranta siirretty laatudokumenttiin 1.4 3.11.2006 Aleksi Airola Muokattu kappaleita 6.3, 5.1.2 ja riski loki päivitetty 1.5 3.11.2006 Kaarlo Lahtela Katselmoitu palautettava dokumentti
PROJEKTISUUNNITELMA 3 (30) SISÄLLYS 1. JOHDANTO...5 2. SIDOSRYHMÄT JA HENKILÖSTÖ...6 2.1. Projektiryhmä: Dentego... 6 2.1.1. SE expert -ryhmä...6 2.1.2. Kehittäjät... 7 3. TAVOITTEET...9 3.1. Asiakkaan tavoitteet... 9 3.2. Henkilökohtaiset oppimistavoitteet... 9 3.3. Projektin keskeytysehdot... 10 3.4. Projektin päättämisehdot... 10 4. RESURSSIT JA BUDJETTI...11 4.1. Henkilöstö... 11 4.2. Materiaali... 11 4.3. Budjetti... 12 5. TYÖMENETELMÄT JA TYÖKALUT...13 5.1. Työmenetelmät... 13 5.1.1. Iteratiivinen kehitys... 13 5.1.2. Iteraation suunnittelu... 13 5.1.3. Dokumentointi... 13 5.1.4. Riskienhallinta... 14 5.1.5. Tuntiraportointi... 14 5.1.6. Kommunikaatio... 15 5.1.7. Iteraatiodemo... 16 5.1.8. Virheiden seuranta... 17 5.1.9. Versionhallinta... 17 5.1.10. Koodausstandardi... 17 5.1.11. Vertaistestaus... 18 5.1.12. Vaatimustenhallinta... 18 5.1.13. Team Building tapahtuma... 19 5.1.14. Pienryhmät... 19 5.1.15. Prototypisointi... 19 5.1.16. Katselmointikäytännöt... 20 5.1.17. Sepa-aiheet... 20 5.1.18. Suunnitelu... 21 5.1.19. Prosessinkehitys... 21 5.2. Laatusuunnitelma... 21 5.3. Työkalut... 21 5.3.1. Kehityslaitteisto... 21 5.3.2. Ohjelmistot... 21 5.3.3. Kehitysympäristö... 23 5.4. Standardit... 24
PROJEKTISUUNNITELMA 4 (30) 6. VAIHEISTUS...25 6.1. Aikataulu... 25 6.2. Projektin suunnittelu... 25 6.3. Toteutus 1... 26 6.4. Toteutus 2... 29 7. RISKI LOGI...30
PROJEKTISUUNNITELMA 5 (30) 1. JOHDANTO Korvauskäsittely lakisääteisissä tapaturmakäsittelyissä elektronisoidaan ja projektissa toteutetaan elektronisen hoitoonohjausjärjestelmän keskitetty välitys- ja viitetietopalvelin. Sanomissa käytetään kansallisen terveyshankkeen (HL7) mukaista XML muotoista standardia. Järjestelmän tarkoituksena on lyhentää asiakkaiden odotusaikoja hoitoon pääsyyn ja vastaavasti takaisin töihin. Vuotuinen kustannus sairaspäivärahojen osalta on 120 000 000 euroa ja yhden päivän nopeutus säästää miljoonia euroja puhumattakaan inhimillisestä kärsimyksestä. Vastaanotot täyttävät hoitoehdotuksen, jonka järjestelmä välittää vakuutusyhtiöön ja tallentaa. Vakuutusyhtiö antaa maksusitoumuksen, joka puolestaan välitetään vastaanotolle ja tallennetaan. Lisäksi vaatimuksena on keskitetty laskutus, jonka järjestelmä välittää elektronisessa muodossa (Finvoice) vakuutusyhtiölle. Dentego-palvelin välittää viestejä Doctoral-ohjelmistolta TE-palvelimen kautta Doctorex-ohjelmistoon, eikä sen toiminta näy suoraan loppukäyttäjille.
PROJEKTISUUNNITELMA 6 (30) 2. SIDOSRYHMÄT JA HENKILÖSTÖ Projektin asiakas on Plusterveys Hammaslääkärit Oy ja heidän sopimusosapuolena on Pohjola Oy. TietoEnator Oy ylläpitää Pohjola Oy:n välityspalvelinta, jonka kautta Dentegopalvelin välittää sanomia Plusterveydeltä Pohjolaan. Kuva 1. Sidosryhmät ja henkilöstö 2.1. Projektiryhmä: Dentego Projektiryhmän kotivut ovat http://www.dentego.com, sekä postituslista on dentego##list.hut.fi. Käytössä on MediaWiki osoitteessa wiki.dentego.com. 2.1.1. SE expert -ryhmä SE Expert ryhmä on vastuussa projektinhallinnallisista asioista ja työn koordinoinnista. Rooli Projektipäällikkö, vaatimusmäärittely-vastaava Nimi Aleksi Airola Puhelin +358 400 511 144 Sähköposti aleksi.airola##tkk.fi Kiinnostus Luistelu, sulkapallo, elokuvat ja hyvä ruoka.
PROJEKTISUUNNITELMA 7 (30) Rooli QA-vastaava, tietoliikenneadapteri-vastaava Nimi Lahtela, Kaarlo Puhelin +358 40 730 3750 Sähköposti kaarlo.lahtela##tkk.fi Kiinnostus Elokuvat, liikunta, ohjelmointi. Rooli Pääarkkitehti, sovellusadapteri-vastaava, MediaWiki admin, SVN admin, Schema ja tietokanta-vastaava Nimi Tolvanen, Tuomas Puhelin +358 44 295 6362 Sähköposti tttolvan##cc.hut.fi Kiinnostus 2.1.2. Kehittäjät Kehittäjät toimivat projektissa pienryhmissä myös suunnittelijoina. Rooli Kehittäjä, projektipäällikön assistentti Nimi Ahti, Lari Puhelin +358 40 773 8089 Sähköposti lahti##cc.hut.fi Kiinnostus Suunnistus, ohjelmointi Rooli Kehittäjä, tietokanta assistentti Nimi Kauppinen, Antti Puhelin +358 40 847 6787 Sähköposti aekaupp1##cc.hut.fi Kiinnostus Rooli Kehittäjä, QA-assistentti Nimi Kiiski, Lauri Puhelin +358 40 7011 858 Sähköposti Lauri.kiiski##iki.fi Kiinnostus Rooli Kehittäjä Nimi Töyry, Timo Puhelin +358 40 839 7253 Sähköposti ttoyry##cc.hut.fi Kiinnostus Valokuvaus, kuvienkäsittely, tietokoneet (ja ym. elektroniikka), ohjelmointi, pienoismallit Rooli Kehittäjä, arkkitehdin assistentti Nimi Vanhapiha, Olli Puhelin 040-738 6780 Sähköposti ovanhapi##cc.hut.fi
Kiinnostus PROJEKTISUUNNITELMA 8 (30)
PROJEKTISUUNNITELMA 9 (30) 3. TAVOITTEET 3.1. Asiakkaan tavoitteet Asiakkaan tavoitteet kuvattuna korkealla abrtraktiolla. Asiakas hakee toimivan, tietoturvallisen ja luotettavan ohjelmiston lisäksi kokemusta ohjelmistokehityksen prosesseista ja siinä käytettävistä työkaluista. Tavoite 1 Saada ohjelmisto, joka toteuttaa PlusTerveyden ja Pohjolan välisen sopimuksen mukaisen hoito- ja korvauskäsittelyn sekä laskun elektronisessa muodossa. 2 Sähköisen tiedonsiirron kehittäminen ulkopuolisiin osapuoliin. 3 Vastaanottojen tehokkuuden parantaminen sähköisen tiedonsiirron avulla. 4 Vastaanottojen sähköisten tiedonsiirto valmiuksien kehittäminen tarvittavalle tasolle kaikilla vastaanotoilla. 5 Helpottaa uusien viestityyppien määrittelyä (viestinvälitys rungon määrittely). 6 Oppia uutta prosesseista ja olio-pohjaisesta mallintamisesta ja niissä käytetyistä työkaluista. 7 Sopeutuminen tulevaisuuden vaatimuksiin(mobiili). Taulu 1. Asiakkaan tavoitteet prioriteettijärjestyksessä 3.2. Henkilökohtaiset oppimistavoitteet Jäsen Ahti, Lari Airola, Aleksi Lahtela, Kaarlo Kauppinen, Antti Kiiski, Lauri Tolvanen, Tuomas Töyry, Henkilökohtainen oppimistavoite Tavoitteena kurssissa on tutustua laajan projektin toteuttamiseen ja oppia suurikokoisessa ryhmässä toimimista. Erityisesti kommunikaatio ja suunnittelu ovat mielenkiintoisia aiheita, joista on myös hyötyä tulevaisuudessa. Projektissa saa tutustua uusiin teknologioihin ja tekniikoihin, joita ei koulussa opeteta. Lisäksi projekti antaa kokemusta myös työelämää ajatellen. Haen kokemusta 8 hengen ja 6 kuukautta kestävän projektin hallinnasta, sekä tarvittavan dokumentoinnin luomisesta ja hallinnasta. Uudet teknologiat tulevat toissijaisena oppimistavoitteena. Tavoitteena on saada kokemusta ryhmän ohjaamisesta. Tarkoitus on myös opetella parhaat kommunikointitavat kehittäjien kanssa. On kiinnostavaa oppia uusien tekniikoiden käyttöönottoa yleisesti projekteissa, ja hallita niiden tuomia riskejä. Haasteen tuo myös projektin suuret laatuvaatimukset, joihin tuotettavien testien pitää pystyä vastaamaan. Tavoitteena on saada kokemusta suuremman projektin toteuttamisesta ryhmässä, sekä oppia projektissa käytettävistä tekniikoista, esimerkiksi webserviceistä, XML:n käytöstä ja tietokannoista. Myös ryhmän kommunikaatio on mielenkiintoinen aihe. Tavoitteena on oppia suuremman projektin toteuttamisesta ja työskentelystä suuressa ryhmässä. On mielenkiintoista nähdä, miten tällainen kaupallinen projekti toteutetaan asiakkaalle. Projektissa on mahdollisuus oppia lisää jo ennestään tutuista ja joukosta uusia tekniikoita. Kiinnostavia opeteltavia tekniikoita ovat tietokannan ja XML:n käyttö Javalla ja webserviceihin liittyvät tekniikat ja toteutukset yleisesti. Myös tietoliikenneprotokollan toteuttaminen spesifikaation perusteella kiinnostaa. Tavoitteena on saada käytännön kokemusta kaupallisen ohjelmatuotteen toteuttamisesta Java-ympäristössä, sekä siihen liittyvistä teollisuudessa käytetyistä avoimen lähdekoodin tekniikoista. Arkkitehtuurisuunnittelussa tavoitteena on saada kokemusta arkkitehtuurin määrittelystä, dokumentoinnista ja käytännön toteutuksen koordinoinnista arkkitehdin roolissa. Lisäksi tavoitteena on saada kokemuksia kommunikaatiokäytännöistä hajautetussa projektissa sekä yleisesti projektin hallinnasta osana SE-ryhmää. Tavoitteena on saada kokemusta isomman projektin toteuttamisesta suuremmassa
PROJEKTISUUNNITELMA 10 (30) Timo Vanhapiha, Olli ryhmässä. Sekä miten toimitaan suuremmassa ryhmässä ja miten ryhmän kommunikointi toimii. Myös työssä käytettävien uusien tekniikoiden oppiminen kiinnostaa. Tavoitteena on kerätä käytännön kokemusta ja uusia ideoita suhteellisen ison hajautetun kehitysryhmän toiminnasta. Teknologiapuolelta kiinnostusta herättää erityisesti Web Services -tekniikoiden toteuttaminen Java-alustalle sekä monitasoarkkitehtuurin suunnittelu toteutettavalle järjestelmälle. Yksi tavoitteistani on myös tutustua uusiin osaaviin ja oppimishaluisiin henkilöihin ja kasvattaa näin omaa kontaktiverkostoa. Taulu 2. Henkilökohtaiset oppimistavoitteet 3.3. Projektin keskeytysehdot Projektin keskeyttämisestä neuvotellaan asiakkaan kanssa, jos kolme tai useampi ryhmän jäsen keskeyttää projektin. Ensisijaisena keinona on projektin laajuuden supistaminen. Asiakkaalla on oikeus milloin vain keskeyttää projekti. 3.4. Projektin päättämisehdot Projekti päättyy 1.3.2006 iteraatiodemoon. Tähän mennessä kaikki tuotokset ovat toimitettu asiakkaalle. Projektin päättyessä myös kaikki projektiryhmän vastuut projektin tuotosten suhteen raukeavat.
PROJEKTISUUNNITELMA 11 (30) 4. RESURSSIT JA BUDJETTI 4.1. Henkilöstö Kappaleessa kerrotaan projektissa tarvittavat ja käytössä olevat resurssit, materiaalit ja budjetti. Taulussa 3 on resursoitu käytössä olevat työtunnit ja allokoitu ne iteraatioittain. Henkilö PP I1 I2 Yhteensä Aleksi Airola 90 50 50 190 Kaarlo Lahtela 60 80 50 190 Tuomas Tolvanen 60 80 50 190 Lari Ahti 30 100 60 190 Antti Kauppinen 40 100 50 190 Lauri Kiiski 40 100 50 190 Timo Töyry 20 100 70 190 Olli Vanhapiha 40 100 50 190 Yhteensä 380 710 430 1520 Taulu 3. Varatut työtunnit Ryhmän poissaolot iteraatioiden aikana: Lauri on poissa kaksi tammikuun viimeistä viikkoa ja haluaa aloittaa iteraatio 2:n tammikuun alussa. Muut osapuolet ovat luvanneet käyttää resursseja seuraavasti: Asiakas Pekka Korhonen 100h Mentor Mika Mäntylä 35h Asiakas Mika Alho 75h Asiakas Jussi Rautio 75h Sopimusosapuoli Minna Markkula 5h Sopimusosapuoli Katja Havastila 10h Taulu 4. Muiden osapuolien työtunnit 4.2. Materiaali Asiakas on toimittanut projektiryhmän käyttöön CaliberRM vaatimustenhallintaohjelmiston koneineen. Lisäksi harkitaan web-lisenssin hankintaa parantamaan kommunikaatiota. Asiakkaalla on myös hankittuna Borlandin Together Architect lisenssi projektiryhmän käyttöön. Asiakas on hankkinut kaksi XMLSpy Suite professional versiota kehitysryhmän käyttöön. Muista hankinnoista neuvotellaan erikseen asiakkaan kanssa. Kurssin puolesta on käytössä MagicDraw uml-työkalun lisenssejä. Kehitysympäristöt (Eclipse) toimivat projektiryhmän omilla koneilla. MediaWiki ja SVN toimivat iteraatio 1:n loppuun projektiryhmän käytössä olevalla www-palvelimella. Jatkuvaan integrointiin käytetään Ant-build työkalua ja Cruise Controllia.
PROJEKTISUUNNITELMA 12 (30) 4.3. Budjetti Asiakkaan lisenssit ovat kehitysryhmän käytössä projektin loppuun asti, jonka jälkeen lisenssit palautuvat asiakkaalle. Taulukossa 4 kuvataan mitä projekti todellisuudessa voisi maksaa. Asiakkaalle realisoituu kustannuksista oma työaika, lisenssit ja SoberIT:n maksu. Kustannuserä Työmääräarvio Palkkio /h Kustannukset Sisäinen työ Asiakkaan käyttämä aika 100h 40 4 000 Ympäristöjen pystytys 50h 40 2 000 Hankittavat resurssit Ryhmän käyttämä aika 1520h 60 91 200 Materiaalit SoberIT:n maksu 3 000 Together Architect lisenssi 1 500 CaliberRM lisenssi 5 000 Alihankinta Mentor konsultointi 35h 100 3 500 Kustannukset yhteensä 110 200 Taulu 5. Kustannuserät
PROJEKTISUUNNITELMA 13 (30) 5. TYÖMENETELMÄT JA TYÖKALUT 5.1. Työmenetelmät Kappaleessa kuvataan projektissa käytettävät työkäytännöt ja työkalut. 5.1.1. Iteratiivinen kehitys Projektissa käytetään iteraratiivistä ja inkrementaalista kehitysmallia. Iteraatiota on kolme kappaletta, jotka on kuvattu tarkemmin tavoitteineen kappaleessa 6. Perusperiaatteena on mahdollisimman aikaisin saada protoilemalla toimiva viestinvälitysjärjestelmä, jonka päälle rakennetaan ominaisuuksia siten, että jatkuvasti on toimiva ohjelmisto. Kunkin iteraation jälkeen toimitetaan toimiva ja testattu ohjelmisto. Tämä jatkuvasti toimiva ohjelmisto tuo haasteita kehittäjille. Iteraatioiden aikana puolessa välissä on sisäiset välidemot, joilla seurataan työn edistymistä. Iteratiivisen kehitysmallin mukaisesti tehdään suunnittelua, ohjelmointia ja testausta rinnakkain. Suunnittelu ja protoilu painottuvat PP-iteraatioon ja I1- iteraation alkuun. 5.1.2. Iteraation suunnittelu SE expert ryhmä suunnittelee iteraatiot edellisen iteraation lopulla omassa iteraation suunnittelu palaverissa. Asiakaspalaverissa heti iteraatiodemon jälkeen arvioidaan edellisen iteraation tulokset ja määritellään seuraavan iteraation tavoitteet. Tavoitteiden määrittelyn jälkeen viikkopalaverissa tehdään työmääräarviot yhdessä kehittäjien kanssa. Iteraatioiden alussa arviot ja tavoitteet lähetetään asiakkaalle katselmoitavaksi ennen kuin ne palautetaan kurssille. Iteraatioiden suunnittelu, sekä tietojen päivitys projektisuunnitelman kappaleeseen 6 on projektipäällikön vastuulla. 5.1.3. Dokumentointi Dokumentit palautetaan viimeistään määräpäivänä PDF-muodossa mentorille, asiakkaalle, sekä julkaistaan ryhmän kotisivulla. Dokumentit säilytetään kehitysvaiheessa versionhallinnassa, missä ne ovat kaikkien saatavilla. Dokumentit versioidaan PP-iteraatiossa 0.x, toetutusiteraatiossa 1 1.x ja toteutusiteraatiossa 2 2.x. Kaikki dokumentit katselmoidaan ennen palautusta ja katselmointivastuut ja määräajat näkyvät alla olevasta taulukosta. Dokumentointikielenä on suomenkieli. Dokumentti Vastuuhenkilö Katselmointipäivämäärryhmä Katselmointi- Palautuspäivämäärä Projektisuunnitteluvaiheen Aleksi Airola su 1.10.2006 SE expert ryhmä 2.10.2006 kello 11 suunnitelma Projektisuunnitelma Aleksi Airola to 19.10.2006 Projektiryhmä 23.10.2006 kello 11 Arkkitehtuuridokumentti Tuomas su SE expert 23.10.2006 kello 11 Tolvanen -ryhmä Vaatimustenmäärittely- Aleksi Airola, to 19.10.2006 Projektiryhmä 23.10.2006 kello 11
PROJEKTISUUNNITELMA 14 (30) dokumentti Kaarlo Lahtela Laatusuunnitelma Kaarlo Lahtela to 26.10.2006 SE expert 3.11.2006 kello 11 Lauri Kiiski -ryhmä Iteraatio 1 Aleksi Airola to 2.11.2006 SE expert 3.11.2006 kello 11 -iteraatiosuunnitelma -ryhmä Iteraatio 1 -dokumentit Yllä mainitut ti 4.12.2006 SE expert 11.12.2006 kello 11 -ryhmä Iteraatio 2 Aleksi Airola to 11.1.2006 SE expert 16.1.2006 kello 11 -iteraatiosuunnitelma -ryhmä Vertaistestausohjeet 17.2.2006 kello 11 Vertaistestausraportti 21.2.2006 kello 11 Iteraatio 2 -dokumentit 26.2.2006 kello 11 Tuotos Dokumentit Kaaviot Demot Työkalu MS Word MS Visio, MS Powerpoint, Magic Draw MS Powerpoint Taulu 6. Dokumentit, niiden vastuut ja määräajat Katselmointivastuita jaetaan myös asioiden edetessä kehittäjille. PP-iteraation ja Iteraatio 1 -iteraatiosuunnitelman osalta päivät ovat lopulliset. Dokumenttien laatimiseen käytetään Microsoft Word ohjelmaa ja kaavioiden piirtämiseen käytetään MS Visio ja Powerpoint ohjelmia. Demot tuotetaan MS Powerpoint:lla. Taulu 7. Työkalut 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 tunnistetan ja analysoidaan heti projektin alussa ja lisäksi yksittäisiin iteraatioihin liittyvät riskit tunnistetaan jokaisen iteraation aloituspalaverissa brain storming menetelmällä. Riskien realisoitumista seurataan ja niiden prioriteetit arvioidaan iteraatoiden puolivälissä ja lopussa. Jos jonkin riskin realisoitumisesta havaitaan merkkejä, tehdään tarvittavat korjaustoimenpiteet ja sitä seurataan viikottain. Riskien tunnistaminen ja seuranta on expert-ryhmän vastuulla. Projektin riskienhallintakäytäntö koostuu seuraavista askeleista: 1. Riskien tunnistaminen 2. Riskien syiden tunnistaminen 3. Riskien todennäköisyyden arviointi 4. Riskien vaikutusten arviointi 5. Riskejä vähentävien toimien käyttäminen 6. Riskitilanteen seuranta Alustavat riskit ovat tunnistettu brain storming menetelmällä Team Building tapahtumassa ja ne ovat koottu riskilokiin (kappale 7). 5.1.5. Tuntiraportointi
PROJEKTISUUNNITELMA 15 (30) Tuntiraportointiin käytetään Excel taulukkoa. Jokaisella ryhmän jäsenellä on oma Excel- sheet, johon he itse päivittävät käyttämänsä tunnit. Tiedostossa on oma sheet kullekin iteraatiolle. Kunkin viikon sunnuntaina kello 24 mennessä tulee edellisen viikon tunnit olla raportoituna. Tuntiraportointitiedostoja säilytetään SVN:ssä hakemistossa dokumentit/tuntiraportointi. Keskiviikkoon mennessä projektipäällikkö koostaa tunnit ja raportoi ne tuntiraportointi sivulle MediaWikiin. Koostamisen yhteydessä arvioidaan onko tarvetta muuttaa tuntiarvioita viikottain. Tuntiraportoinnin vastuullinen on projektipäällikkö, joka yhdessä expert-ryhmän kanssa allokoi tunnit kehittäjille. Ennen allokointia pyydetään kehittäjiltä omat arviot tarvittavista tunneista. Team building tapahtumassa kerättiin kehittäjiltä arviot heidän projektiin käytössään olevista tunneista iteraatioittain. 5.1.6. Kommunikaatio Projektissa on asiakas, sopimuspuolet ja mentor mukaan lukien mukana 15 henkilöä. Kukaan ei tee projektia täyspäiväisesti, eikä kehittäjille ole yhteistä työskentelytilaa. Projekti on hajautettu. Seuraavilla menetelmillä tullaan hoitamaan kommunikaatio siten, että se on riittävä ja tehokas. Projektisuunnitelma Projektisuunnitelma toimii referenssi kommunikaatiovälineenä, jolla projektin alussa kommunikoidaan käytännöt sidosryhmille. Dokumentti katselmoidaan asiakkaan ja ryhmän kesken palaverissa. Projektin edetessä suunnitelman kommunikaatioarvo laskee. Wiki MediaWikiä käytetään koko projektin aikana tehokkaaseen kommunikointiin. Kaarlo Lahtela on vastuussa sivujen ylläpidosta. Ryhmän jäsenillä on täydet muokkaus oikeudet sivustoon. Projektinhallinnalliset tehtävät löytyvät Wikistä. Lisäksi sieltä löytyy linkit tuntiraportointiin, tapaamisajat, tehtävälistat, henkilöiden esittelyt työkaluohjeet, käytetyt menetelmät ja FAQ-osiot. Projektin edetessä sivuston koko kasvaa ja muutoksia on vaikea havaita, joten Wiki ei ole riittävä kaikkiin muutoksiin. Postituslista & viikkoraportti Ryhmälle on perustettu postituslista TKK:n ATK-osastolle. Sen osoite on: dentego##list.hut.fi Kaikilla on oikeus lähettää sinne sähköpostia, joka ohjautuu kaikille ryhmän jäsenille. Pääasiassa postituslista on viikkoraporttia varten, jolla kommunikoidaan viikon status ryhmän jäsenille. Pienryhmät Projektin aikana tunteja palaa paljon palavereissa jos ryhmän koko on enemmän kuin neljä, eikä tuloksia synny. PP-iteraation aikana toiminta on jaettu viiteen pienryhmään, joiden kesken työ on jaettu. Kukin ryhmä kokoontuu heille
PROJEKTISUUNNITELMA 16 (30) sopivina ajankohtina ja työmäärän mukaan. Pienen ryhmän on helpompi löytää yhteinen aika, kuin koko projektiryhmän. Ryhmiä tehdään suorittamaan tehtäviä dynaamisesti projektin aikana. Jokaisella ryhmällä on vastuullinen, joka raportoi työn edistymisestä projektipäällikölle. Expert ryhmä kokoontuu viikoittain ennen viikkopalaveria. Viikkopalaverit Viikkopalavereissa pidetään Scrum muotoinen statuspalaveri, mitä ollaan tehty, missä nyt ollaan ja mitä seuraavaksi viikoksi. Lisäksi PP-iteraatiossa katselmoidaan projektisuunnitelma ja vaatimusmäärittely dokumentit. On huomattu, että dokumenttien katselmointi koko ryhmän kanssa on tarpeen käytäntöjen kommunikoinnin takia. Jokaisella palaverilla on agenda, joka lähetetään postituslistan avulla kaikille ryhmän jäsenille vähintään päivää ennen palaveria. Kustakin palaverista tehdään pöytäkirja, joka tallennetaan Wikiin aikataulun yhteyteen. Viikkopalaverien määrää tullaan vähentämään projektin edetessä, kun Wikiin raportointi kehittyy ja jäsenet saavat karistettua alkukankeuden. Puhelimet & Skype & MSN Messenger Ensisijaisesti tullaan käyttämään ilmaisia kommunikaatiovälineitä, kuten Skypeä mikrofonilla ja kuulokkeilla. Jollei ryhmän jäsenet ole koneen ääressä käytetään puhelinta. Puhelinlaskua tulee seurata ja liittymän tyypin vaihtamista kannattaa harkita projektin ajaksi. Projektipäällikön kokemuksesta puhelinlasku kolminkertaistuu projektin aikana. Suositeltava liittymätyyppi on 500 minuuttia puheaikaa ja 100 tekstiviestiä. IRC-kanava Ryhmän käytössä on #dentego IRC-kanava kehityksen aikana. Kommunikointi projektiryhmän ulkopuolelle Projektipäällikkö on asiakasvastaava ja hoitaa kommunikoinnin projektiryhmän ulkopuoleisiin sidosryhmiin. Asiakas tapaa projektiryhmän PP-iteraation demotilaisuudessa. Mentorille ja asiakkaalle on järjestetty pääsy projektin dokumentointiin. 5.1.7. Iteraatiodemo Iteraatiodemo toteutetaan kurssin ohjeistuksen mukaisesti. Projektipäällikkö valmistelee tilannekatsausraportin PowerPoint esityksenä iteraatiodemoon niin, että se voidaan katselmoida päivän ennen palautusta. Ohjelmiston toiminnallisuuden demonstroinnista I1 ja I2 iteraatiodemoissa vastaa Tuomas Tolvanen. Iteraatiodemossa esitettävän sovelluksen version tulee olla läpikäytävissä kaksi päivää ennen palautusta. Iteraatiodemon päivämäärät on asetettu kurssin puolesta ja iteraatiodemot pidetään Innopoli2:ssa SoberIT:n tiloissa. Tarkemmat kellonajat ehdotetaan kurssin puolesta ja ovat nähtävissä kurssin kotisivuilla.
PROJEKTISUUNNITELMA 17 (30) Projektipäällikkö varmistaa ajan sopimisen asiakkaalle ja tekniselle ohjaajalle. PP iteraation demo pidetään 24.10 klo 11 ja I1-demo 12.12. 5.1.8. Virheiden seuranta Virheiden seurantaan käytetään Jira ohjelmistoa. Virheiden seurannasta on vastuussa QA-ryhmä. Käytännöt on tarkemmin määritelty laatudokumentissa kappaleessa 2.7. 5.1.9. Versionhallinta Tuomas Tolvanen on versionhallinnan vastuuhenkilö. Versionhallintaan käytetään SubVersionia ja käytäntönä on long transaction. Merge tapauksissa jälkimmäinen committaaja ottaa yhteyttä aikaisempaan committaajaan, ellei tilanne ole itsestään selvä, jolloin jälkimmäinen suorittaa mergen. Lukitusta ei voida käyttää, koska lukitus ilmenee vasta commit tilanteessa, eikä update tilanteessa. Version ulos checkaamiseen käytetään, joko TortoiseSVN:ä tai Eclipsen Subclipse plug-in:a. Jokainen commit on kommentoitava kuvaavasti, koodin täytyy olla toimivaa ja kommentoitua. Koodin toimivuus testataan ainakin, että se kääntyy ja olemassa olevat testit menevät läpi. Kommentoinnin on oltava kappaleen 5.1.10. koodausstandardin mukaista. Kukin demo versio tagataan ennen tapahtumaa. Demoista tarkemmin kappaleessa 6. Versionhallinnassa säilytetään tuotantokoodin lisäksi dokumentaatio ja tuntiraportointi. Versionhallinta siirretään asiakkaan palvelimille iteraatio 1:n jälkeen. PP- ja I1- iteraatioiden aikana versionhallinta-repositorio sijaitsee projektin internet palvelimella, jonka palvelut projektiryhmän käyttöön tarjoaa Aurentia Solutions Ky. 5.1.10. Koodausstandardi Ohjelmoinnissa käytetään Java Coding Convention standardia (http://java.sun.com/docs/codeconv/). Koodi kommentoidaan JavaDoc:n (http://java.sun.com/j2se/javadoc/writingdoccomments/index.html) ohjeiden mukaisesti. Koodin kommentoiminen Metodien, luokkien ja muuttujien nimet kirjoitetaan englanninkielellä. Nimissä tulee käyttää kuvaavia nimiä, eikä lyhennettyjä nimiä. Tämä siksi, että kehitysympäristö Eclipse tukee auto täydennystä. Muuttujien ja luokkien nimet ovat substantiiveja ja metodien nimet alkavat verbeillä. Liiketoimintaluokkien nimeämisessä voidaan käyttää suomenkielisiä nimiä siltä osin kun englanninkielisen vastineen käyttö ei ole selkeyden kannalta mielekästä. Esim. setadapterbit(); setadb(); // EI NÄIN
PROJEKTISUUNNITELMA 18 (30) Eclipse tukee //TODO: kommenttien käyttöä, joilla kuvataan keskeneräisiä tehtäviä. Commitoitavassa koodissa saa olla //TODO: kohtia, mutta ei keskeneräisiä JavaDoc:ja. Kysymyksiin muille käytetään //KYS: tagia. Tagin perään tulee keneltä kysytään, kysymys ja kysyjä väliviivalla erotettuna. Esim. //KYS:Allu Miten Acknowlement käsitellään? -Kaarlo Tämä helpottaa search ominaisuuden käyttöä. JavaDoc Rajapinta tulee dokumentoida suomenkielellä siten, että jokaisessa luokassa on ainakin @author tagi ja kuvaus luokasta ja sen tarjoamista toiminnoista. Kaikki public, protected ja package tason metodeissa ja muuttujissa tulee olla ainakin @param, @returns ja @throws tagit kommentoituina. Private metodien ja muuttujien nimiä ei tarvitse erikseen kommentoida, jos nimi on kuvaava. QA-ryhmä on vastuullinen koodaus käytäntöjen noudattamisen seurannasta 5.1.11. Vertaistestaus Dentego ryhmän vertaistestausryhmä on ryhmä numero 8. Vertaistestaussuunnitelma laaditaan iteraatio 2:n alussa, kun tiedetään miten vertaistestauksella voidaan parhaiten tukea projektin testaustavoitteita. 5.1.12. Vaatimustenhallinta Vaatimustenhallintaan käytetään Word-dokumenttia ja CaliberRM-ohjelmistoa rinnakkain. CaliberRM ei tue vaatimusten kommunikointia riittävästi, minkä takia käytetään Word dokumenttia. Asiakas haluaa vaatimukset CaliberRM muodossa. CaliberRM vaatimukset päivitetään vastaamaan Word dokumenttia iteraatioiden alussa, välidemon aikaan ja lopussa. CaliberRM ohjelmisto toimitetaan asiakkaan intranettiin toimivaksi projektin aikana. Vaatimusten perustana on kattava OpenCDA2006 dokumentointi. Projektissa käytetään HL7 CDA R2 määrittelemää dokumenttien XML-formaattia sekä HL7 v3 määrittelemiä tiedonsiirtoprotokollia. Muina lähteinä vaatimusten keräämiseen toimivat Pohjola ja TietoEnator. He toimittavat aineistoa ja henkilöitä haastatellaan. Dokumentointi perustuu käyttötapausten kuvaamiseen. Projektipäällikkö on vaatimustenmäärittely ryhmän vetäjä ja vastuussa muutostenhallinnasta yhdessä vaatimusmäärittelyryhmän kanssa. Vaatimusten muutoksissa noudatetaan seuraavia askeleita: Muuttunut vaatimus identifioidaan Vaatimustenmäärittely ryhmä analysoi muutoksen ja tekee työmääräarvion Muutoksesta neuvotellaan asiakkaan kanssa Tarvittaessa projektin laajuutta arvioidaan uudestaan
PROJEKTISUUNNITELMA 19 (30) 5.1.13. Team Building tapahtuma Team Building tapahtuma pidettiin torstaina 5.10.2006 kello 14-18. Tapahtumassa käytiin läpi kurssin yleiset ja henkilökohtaiset tavoitteet, opittiin tuntemaan toisiamme ja luotiin yhteishenkeä. Tapahtumassa saatiin sovittua kuuden palaverin ajankohdat seuraavaksi viikoksi eli työt saivat varsinaisen Kick-Offin tilaisuudesta. Lisäksi käytiin läpi viimeisimmät vaatimus- ja arkkitehtuuridokumentit. Tapahtuman jälkeen saatiin palautetta, siitä miten asiat olivat selkiytyneet kehittäjille huomattavasti. Projektipäällikkö on vastuussa tapaamisen järjestelyistä. 5.1.14. Pienryhmät Työskentely projektissa tapahtuu pienryhmissä. Pienryhmien tarkoituksena on tehostaa työskentelyä ja selkiyttää vastuita. PP-iteraatiossa käynnistetään ainakin seuraavat ryhmät: Vastuualue Tuotos Ryhmän jäsenet Arkkitehtiryhmä Arkkitehtuuri-suunnitelma Tuomas Tolvanen Kaarlo Lahtela Olli Vanhapiha Tietoliikenne adapteri Web Service pohjainen Kaarlo Lahtela protoryhmä XML Schema ryhmä proto Olli Vanhapiha Sovellusadapterin XSD Tuomas Tolvanen Schema Lari Ahti Antti Kauppinen QA-ryhmä Laatusuunnitelma Kaarlo Lahtela SE expert ryhmä Vaatimustenmäärittelyryhmä Projektin hallintaan liittyvä dokumentointi Vaatimustenmäärittely dokumentti Taulu 8. Pienryhmien kokoonpanot Lauri Kiiski Aleksi Airola Kaarlo Lahtela Tuomas Tolvanen Aleksi Airola Kaarlo Lahtela Lari Ahti Ryhmien aikataulutus on tarkennettu kappaleessa 6. Pienryhmät raportoivat edistymisestä viikkopalaverissa ja myöhemmin tarvittaessa sähköpostitse, jos viikkopalavereja karsitaan myöhemmissä iteraatioissa. Ryhmien organisoinnista on vastuussa projektipäällikkö. 5.1.15. Prototypisointi Prototypisoinnilla vähennetään riskejä projektin aikana. Kaikista uusista tekniikoista tehdään yksinkertainen prototyyppi kommunikoinnin edistämiseksi ryhmän sisällä. Prototyyppi toimii esimerkkinä, josta kehitystyö lähtee liikkeelle. Web service tekniikka ja Hibernate prototypisoidaan ennen kuin tekniikka valitaan ja tämä tapahtuu PP-iteraation aikana ja iteraatio 1:n alussa. Prototypisointi on pienryhmien vastuulla
PROJEKTISUUNNITELMA 20 (30) 5.1.16. Katselmointikäytännöt Projektissa käytetään kolmetasoista katselmointikäytäntöä. Kevyt katselmointi Dokumentin vastuuhenkilö toimittaa katselmoitavan dokumentin ja siihen kommentoidaan sähköpostitse. Projektin sisäisessä käytössä, kun dokumenttiin on tehty muutoksia, sekä projektin ulkopuolisiin tahoihin I1:ssä ja I2:ssa. Semi-perusteellinen Dokumentin vastuuhenkilö toimittaa katselmoitavan dokumentin ja se käydään läpi pienryhmässä tai asiakkaan kanssa. Projektin sisäisessä käytössä I1:ssä ja I2:ssa, sekä ennen lopullisten dokumenttien palautusta asiakkaan kanssa. Perusteellinen katselmointi Käytetään lähinnä uusien dokumenttien kommunikoimiseen PP-iteraatiossa. Projektin sisäinen perusteellinen katselmointiprosessi on viisivaiheinen: 1. Jokaisella projektissa tuotettavalle dokumentille määritellään vastuuhenkilö, katselmointiryhmä, palautuspäivämäärä sekä katselmointiajankohta. (Termillä dokumentti tarkoitetaan myös iteratiivisesti kehitettävän dokumentin uutta toimitettavaa versiota.) 2. Tuotettavan dokumentin vastuuhenkilö on velvollinen toimittamaan dokumentin katselmoitavaksi katselmointiryhmän jäsenille vuorokautta ennen katselmointiajankohtaa. 3. Katselmointiryhmän tehtävänä on katselmoida dokumentti seuraavista näkökulmista: pienet puutteet, suuret puutteet, virheet ja heränneet kysymykset. 4. Dokumentin vastuuhenkilö korjaa havaitut ja ilmoittaa muille katselmointiryhmän jäsenille sähköpostitse, kun korjaukset ovat tehty. 5. Ryhmän jäsenet kommentoivat korjauksista sähköpostitse dokumentin vastuuhenkilölle. Katselmointikäytäntö on erityisen tärkeä PP-iteraatiossa kommunikaation työvälineenä. Tällä varmistetaan, että kaikki ovat tietoisia projektissa käytettävistä käytännöistä. Projektisuunnitelma ja vaatimusmäärittely dokumentit katselmoidaan koko projektiryhmän kesken PP-iteraatiossa. Formaalia koodikatselmointia käytetään I1:ssä ja I2:ssa koodin laadunvarmistukseen. 5.1.17. Sepa-aiheet Kaikki ryhmän jäsenet suorittavat kurssin puitteissa ylimääräisen opinnäytteen Sepa-aiheena. Sepa-kurssin tarkoituksena on täyttää korvaavuus vanhan T- 76.115 kurssin kanssa. Aiheet tukevat projektin aikana kehitystyötä. Jatkuva Integrointi Jatkuvaan integrointiin käytetään CruiseControllia, jolla automatisoidaan mm. testejä ja niistä raportoimista Lauri Kiiski ja Olli Vanhapiha CaliberRM Ohjelmisto tarjoaa palvelun vaatimusten keräämiseen ja hallinnointiin. Aleksi Airola ja Kaarlo Lahtela
PROJEKTISUUNNITELMA 21 (30) Static methods Tuomas Tolvanen ja Timo Töyry Pariohjelmointi / TDD Antti Kauppinen ja Lari Ahti 5.1.18. Suunnitelu Arkkitehtuuri suunnittelua varten perustetaan pienryhmä, joka vastaa arkkitehtuurisuunnitelmasta ja teknisestä määrittelystä. Ryhmä aloittaa toiminnan PP-iteraation aikana ja tuottaa alustan suunnitelman iteraation loppuun mennessä. Ryhmän kokoonpano on määritelty kohdassa 5.1.14 Pienryhmät. Arkkitehtuuriryhmän toiminnasta vastaa pääarkkitehti. 5.1.19. Prosessinkehitys Prosessinkehitys toteutetaan kevyenä menetelmänä, jota johtaa projektipäällikkö. Jokaisessa viikkopalaverissa kysytään kehittäjiltä heidän tarpeensa ja mahdolliset prosessinparannus ideat. Prosessin parantaminen on jatkuvaa, eikä tähän mennessä ole nähty tarvetta formaalimpaan määrittelyyn, koska projektissa on mukana kaksi jo kurssin käynyttä ja useammilla on työkokemusta. Molemmat kurssin käyneet olivat vuonna 2006 laatupalkinto ryhmäehdokkaita. Viikkopalaverien vähetessä projektin loppu kohti, prosessien parannusta analysoidaan välidemojen yhteydessä. Projektipäällikkö seuraa aktiivisesti muiden ryhmien edistymistä ja prosesseja. 5.2. Laatusuunnitelma QA-dokumentointi on siirretty erilliseen QA-dokumenttiin. 5.3. Työkalut Projektissa käytetään seuraavia työkaluja. 5.3.1. Kehityslaitteisto Ohjelmiston kehityksessä käytetään ryhmän omia tietokoneita, koska projektin vaatimat teknologiat eivät aseta suuria vaatimuksia tietokoneen resurssien suhteen. Tavallinen kotikone (esim. ~3 GHz prosessori ja 512 Mb käyttömuistia) riittää kehitysympäristön sujuvaan ajamiseen. 5.3.2. Ohjelmistot Projektinhallinta Micrsoft Excel. (Versio 2003) o Käytetään tuntikirjanpidon apuna. o Lisenssi: MSDN Academic Alliance. o Lisätietoja: http://msdn62.eacademy.com/elms/storefront/home.aspx?campus=hut_cse. Määrittely
PROJEKTISUUNNITELMA 22 (30) Borland CaliberRM. (Versio 2005) o Lisenssi: Kaupallinen. Saadaan asiakkaalta. o Lisätietoja: http://www.borland.com/us/products/caliber/. Suunnittelu MagicDraw UML-työkalu o http://www.magicdraw.com o Lisenssi tarjotaan kurssin puolesta. Dokumentointi Microsoft Word. (Versio 2003) o Lisenssi: MSDN Academic Alliance. o Lisätietoja: http://msdn62.eacademy.com/elms/storefront/home.aspx?campus=hut_cse. Kommunikaatio MediaWiki. (Versio 1.8.2) o Lisenssi: GNU General Public License version 2. o Lisätietoja: http://www.mediawiki.org/. Skype MSN Messenger Irc Ohjelmointiympäristö Eclipse. (Versio 3.2.1) o Lisenssi: Eclipse Public License versio 1.0. o Lisätietoja: http://www.eclipse.org. JBoss Eclipse IDE. (Versio 1.5) o Lisenssi: Open source. o Lisätietoja: http://www.jboss.org/products/jbosside. Subclipse. (Versio 1.0.3) o Käytetään versionhallintaan yhdessä Subversion:in kanssa. o Lisenssi: Eclipse Public License versio 1.0. o Lisätietoja: http://subclipse.tigris.org/. Tietokanta Microsoft SQL Server 2005 o Lisenssi: Kaupallinen, saadaan asiakkaalta Microsoft SQL Server 2005 Express o Lisenssi: Ilmainen o Käytetään kehitystyöhön kehittäjien koneilla MySQL 5 o Lisenssi: GNU General Public License o Käytetään kehityksessä vain silloin kun ei ole käytössä Windows ympäristöä Ohjelmointikielet Java JDK (Versio 1.5 SE) o Käytetään ohjelmiston toteutuksessa. o Lisenssi: Sun's Binary Code License. XML
PROJEKTISUUNNITELMA 23 (30) 5.3.3. Kehitysympäristö Altova XMLSpy Suite. (Versio 2006 Professional edition) o Lisenssi: Kaupallinen. Saadaan asiakkaalta. o Lisätietoja: http://www.softwarecasa.com/publ/altova.htm. Kuva 2. Kehitysympäristö kehittäjän näkökulmasta Kehitysympäristö koostuu kehittäjän työasemasta, projektin www- ja versionhallintapalvelimesta, sekä asiakkaan tiloissa olevasta testaus- ja tulevasta tuotantopalvelimesta. Kehittäjän kone Kehittäjän oma tietokone toimii kehitysympäristönä. Windows, Linux tai OS X käyttöjärjestelmä Kehitystietokanta o SQL Server 2005 Express Edition o MySQL-tietokanta, jos ei ole Windows ympäristö Elipse 3.2 ohjelmistokehitysympäristö Apache Tomcat-palvelin Java 1.5 SDK Dentego.com-kone
PROJEKTISUUNNITELMA 24 (30) Dentego.com palvelin tarjoaa Subversion-versionhallintaympäristön, sekä Mediawikin projektin käyttöön. Palvelimen palveluja käytetään HTTPprotokollan yli. Versionhallinta tapahtuu suojatun HTTPS-protokollan yli. Gentoo Linux käyttöjärjestelmä Mediawiki Subversion Testaus- ja tuotantopalvelin Asiakkaan tiloissa toimiva palvelin, joka toimii testausympäristönä, sekä tulevana tuotantoympäristönä. Yhteys palvelimelle toteutetaan VPN-yhteyden kautta. Windows Server 2003 käyttöjärjestelmä SQL Server 2005 tietokanta Apache Tomcat 5.4. Standardit OpenCDA 2006 R2 Määrittelee datan sisällön http://virtual.vtt.fi/virtual/hl7/cda/faq-lista/open-cda2006-faq2006-09- 29.htm#_3_HL7_CDA_R2 määritykset HL7 CDA v3 Määritelee tiedonsiirron http://virtual.vtt.fi/virtual/hl7/cda/faq-lista/open-cda2006-faq2006-09- 29.htm#_6_HL7_V3_sanomat_1 Finvoice versio 1.2 Sähköisen laskun rakenteen www.pankkiyhdistys.fi/verkkolasku
PROJEKTISUUNNITELMA 25 (30) 6. VAIHEISTUS Kuva 3. Vaiheistus Projektin suunnittelu iteraation tavoitteena on saada projektisuunnitelma valmiiksi iteraatio 1:stä varten, sekä myös vaatimusmäärittely ja arkkitehtuuri laatuvaatimuksineen maksusitoumuksen, hoitoehdotuksen ja elektronisen laskun osalta. Iteraatio 1:n tavoitteena on saada valmiiksi välityspalvelin, joka pystyy välittämään elektronisia laskuja. Iteraatio 2:n tavoitteena on toteuttaa hoitoehdotusten ja maksusitoumusten välitys. Tätä osiota päivitetään iteraatioiden edetessä. 6.1. Aikataulu Projektin suunnittelu (PP) iteraatio on 27.9.-25.10.2006 sisältäen kaksi deadlinea. 2.10.2006 on iteraatiosuunnitelman palautus ja 23.10. dokumenttien palautus. Dokumentteihin kuuluu projektisuunnitelma, vaatimustenmäärittely dokumentti, sekä edistymisraportti. Iteraatio demo pidetään 24.10. tai 25.10. Sisäisiä virstanpylväitä on team-building tapahtuma 5.10.2006 arkkitehtuuri ja vaatimusmäärittely draftien osalta. Projektisuunnitelma ja vaatimustenmäärittely dokumenttien toinen luonnos valmistuu 18.10.2006 kello 18 mennessä vuorokautta ennen niiden katselmointitilaisuutta. Dokumentit jäädytetään kello 18 ja ne palautetaan 23.10.2006 kello 11 mennessä kurssin palautusjärjestelmään. Arkkitehtuuri dokumentin luonnosta viimeistellään viikon 42 viikonloppuna ja se julkaistaan maanantaina 23.10.2006. Toteutus iteraatiot on jaettu kahtia ja niiden puolessa välissä iteraatiota pidetään välidemo. I1 iteraatio on 26.10.-13.12.2006 ja välidemo pidetään torstaina 16.11.2006. I2 iteraatio on 15.1.-1.3.2007 ja välidemo pidetään perjantaina 1.2.2007. 6.2. Projektin suunnittelu Tavoitteet: Projektin suunnittelu ja seurantamenetelmien käyttöönotto mm. tuntikirjanpito
PROJEKTISUUNNITELMA 26 (30) Aihealueen, tavoitteiden, riskien ja bisnestavoitteiden ymmärtäminen Vaatimusmäärittely hoitoehdotuksen, maksusitoumuksen ja elektronisen laskun, sekä niiden välittämisen osalta Dokumenttien hankinta TietoEnatorilta Ryhmän organisointi vaiheittain Sepa-aiheiden valinta ja tarvittaessa käyttöönotto Tuntea käytettävät teknologiat Tuotokset: Projektisuunnitelma, paitsi 5.2 QA-suunnitelma alustava Vaatimustenmäärittely dokumentti (ch. 1-5, ch. 6-9 ainakin tärkeimmät vaatimukset, ch. 11-12) Edistymisraportti kalvoesityksenä Tehtävät: (allokoidut tunnit - valmiusaste vastuulliset) Dokumenttien hankinta eri osapuolilta (4h 100% tehty projektipäällikkö) Laatuvaatimusten määrittely (2h 100% tehty - Arkkitehtiryhmä) Arkkitehtuuri valmis välityspalvelimen hoitoehdotuksen, maksusitoumuksen ja elektronisen laskun välittämisen osalta (40h 80% tehty Arkkitehtiryhmä + review vastuu projektipäällikkö) Työkalujen asennus ja käyttöönotto koulutuksineen (15h 100% tehty kaikki) Aikataulun suunnittelu (8h 100% tehty projektipäällikkö) Alustava laatukäsikirja (16h 50% QA-manageri ja assistentti) Projektin riskien tunnistaminen, analysointi ja hallinta (6h 100% tehty expert ryhmä + review vastuu muilla jäsenillä) Protota käytettävät teknologiat, riskien välttämiseksi (30h 80% tehty pääarkkitehti + QA-manager + toteuttajat) Tarkempi tehtävien allokointi on nähtävissä SVN:ssa tuntiraportointi hakemistossa. 6.3. Toteutus 1 ID Task Name Start Finish Duration marras 2006 joulu 2006 29.10 5.11 12.11 19.11 26.11 3.12 1 Arkkitehtuurisuunnitelma 26.10.2006 6.11.2006 10d 2 Toteutus 1 2.11.2006 16.11.2006 13d 3 Testaus 1 9.11.2006 20.11.2006 10d 4 Välidemo 23.11.2006 23.11.2006 0d 5 Toteutus 2 24.11.2006 5.12.2006 10d 6 Testaus 2 29.11.2006 9.12.2006 10d 7 Iteraatiodemo 12.12.2006 12.12.2006 0d
PROJEKTISUUNNITELMA 27 (30) Toteutus iteraatio1 yksi on jaettu kahteen osaan. Välidemo pidetään 23.11.2006 kello 9 SoberIT:n tiloissa ja se on kuin iteraatiodemo ja toimii virstanpylväänä, jossa suoritetaan samat tehtävät kuin iteraatiodemossa. Iteraatio on jaettu kahtia, koska kuusi viikkoa on liian pitkä väli ohjelmistotuotannossa ja näkyvyyttä halutaan lisätä. Välidemon jälkeen tarkennetaan koko iteraation tavoitteita. Alustavasti silloin on valmiina viestinvälitys-palvelin, joka osaa välittää elektronisia laskuja. Poikkeus tilanteiden käsittelyt toteutetaan I2:ssa. Välidemon tuotosten tavoitteet Sovellusadapteri: Ensimmäinen versio peruskyselyn ja -vastaanoton viestinkäsittelystä Tietokantaobjektien luominen viestiobjektista Tietoliikenneadapteri: Webservicestä ensimmäinen versio Perus clientti Webserviceille SOAP Viestin parsiminen luokkamuotoon SOAP-viestiä esittävän objektin toteuttaminen Tietokanta: Tärkeimmät taulut ja relaatiot Perustietokantaluokkien toteutus Iteraatiotason tavoitteet Iteraation alussa saada arkkitehtuurisuunnitelma valmiiksi siten, että ohjelmistoa voidaan alkaa kehittämään inkrementaalisesti. Teknisen määrittelyn kirjoittaminen toteutettujen ohjelmistojen osien osalta Kehittää projektinhallinnallisia prosesseja Kehittää kehitystyökalujen käyttöä Valmistella tuotantoympäristön pystytyssuunnitelma ja versionhallinnan siirto asiakkaan tuotantoympäristöön Tuotokset: Ohjelmisto Dokumentit Tietoliikenneadapteri prototyyppi Päivitetty projektisuunnitelma Hibernate prototyyppi Päivitetty vaatimustenmäärittelydokumentti Testattu välityspalvelu ohjelmisto Tekninen määrittelydokumentti Elektronisen laskun sovellus Laatusuunnitelma Test caset Laaturaportti ja testiloki Edistysmisraportti kalvoesitys
PROJEKTISUUNNITELMA 28 (30) Tehtävät: Vastuut ovat määritelty kappaleessa 2.1. Toteustusiteraatio 1 (I1) 26.10-13.12.2005 I1 EE 710,0 Projektinhallinta 220,0 Projektinhallinnointi 8,0 Projektin status raportointi 4,0 Iteraatiodemo 4,0 Projektisuunnittelu ja hallinta 43,0 Projektisuunnittelua 10,0 Projektinhallinta 25,0 Projektisuunnitelman kirjoittaminen 8,0 Informointi ja kommunkointi 169,0 Viikkopalaverit 56,0 Asiakaspalaverit 16,0 Mentorpalaverit 8,0 Pienryhmä palaverit 40,0 Muut mahdolliset palaverit 15,0 Asiakaskommunikointi 10,0 Mentorkommunikointi 4,0 Projektiryhmän kommunikointi 20,0 Ohjelmistonsuunnittelu 71,0 Käyttäjätutkimus Vaatimustenselvittäminen 5,0 Vaatimusmäärittelydokumentti 15,0 Prototyypisointi 8,0 Schema suunnittelu 8,0 Arkkitehtuurisuunnittelu 35,0 Arkkitehtuuri 20,0 Teknisenmäärittelydokumentin kirjoitus 15,0 Laadunvarmistus 74,0 Laatusuunnitelma 5,0 Laatusuunniteman dokumentointi 15,0 Testausuunnitelma 10,0 Testauksen suorittaminen 30,0 Tietoliikenneadapterin testaus 4,0 Käytettävyystestit 0,0 Heuristinen arvio 2,0 Dokumenttikatselmoinnit 8,0 Vertaistestaus 0,0 Työkalujen käyttöönotto ja ohjeistus 25,0 Projektihallinnan työkalut 8,0 Kehitystyökalujen valinta 8,0 Työkalujen käyttöönotto 5,0 Ohjeistus 4,0 Ohjelmointi 243,0 Sovellusadapteri 70,0 Viestin validointi 15,0 Viestin tallentaminen 10,0
PROJEKTISUUNNITELMA 29 (30) Viestien käsittelylogiikka 35,0 Lokitietojen tallennus 10,0 Tietoliikenne-adapteri 74,0 Prototyyppi 10,0 Server puoli 22,0 Client puoli 18,0 Testi stubit 6,0 Sovellusadapterin rajapinta 10,0 SOAP parser 8,0 Tietokanta-adapteri 36,0 Tietokannan toteutus 15,0 Hibernate-mäppäystiedostot 6,0 Persistoitavien objektien hallintarajapinta 15,0 Schema 8,0 Schemojen luominen 4,0 Schemojen validointi 4,0 Käyttöliittymä 6,0 Käyttäjien hallinta 6,0 Vastaanottojen hallinta Auditointi Lokitietojen käsittely 10,0 Loggerin toteutus 10,0 Integrointi 9,0 Integrointi 9,0 Koodin kommentointi 10,0 Koodin kommentoinnin korjausta 10,0 Muu ohjelmointi 10,0 Muu ohjelmointi 10,0 Opiskelu 48,0 Aihealueeseen perehtyminen 16,0 Web Serviceen perehtyminen 8,0 Työkaluihin perehtyminen 9,0 Teknologia 8,0 Ohjeistukseen perehtyminen 7,0 Muu dokumenointi 39,0 Dokumenttien kirjoitus 15,0 SEPA päiväkirjat 24,0 Tarkempi tuntien allokointi on SVN:ssa tuntiraportointi hakemistossa. 6.4. Toteutus 2 Toteutus iteraatiossa kaksi toteutetaan hoitoehdotuksen ja maksusitoumuksen välittäminen, sekä poikkeus tilanteiden käsittely.
PROJEKTISUUNNITELMA 30 (30) 7. RISKI LOGI ID Seloste Toden näköisyys 1 Kehityskoneen hajoaminen 2 Järjestelmän integraatiossa tapahtuu ongelmia. 3 Kehittäjät eivät tiedä mitä tehdä. 4 Projektiryhmän jäsen sairastuu 5 Järjestelmätoimittajalta ei saada tarpeeksi dokumentointia 6 Versionhallinta järjestelmä ei ole käytettävissä 7 Tieto ei kulje (kommunikaatio) 8 Projektiin valitaan teknologioita, joita ei pystytä hallitsemaan kurssin puitteissa. 9 Opiskelija lopettaa kurssin kesken 10 Asiakkaalla ei ole tarpeeksi aikaa projektiin Riskilokin asteikko on 1-5, viitosen ollessa todennäköisin ja vakavin. Riskit priorisoitu risk exposure mentelmällä, jossa exposure luku saadaa kertomalla todennäköisyys vakavuudella. Vaka vuus 5 2 Kehitystyö viivästyy Tehdään töitä etupainotteisesti ja hyvällä aikavaralla. Kehitystyössä käytetään versionhallintaa. 3 5 Järjestelmää pitää muuttaa 2 3 Projekti ei etene ja viivästyy. 4 1 Kehitystyö viivästyy riippuvuuksien takia 2 2 Projektin suunnittelu ja toteutus viivästyy. 1 4 Työt seisovat, mutta tiedot eivät katoa Minimoidaan uusien teknologioiden valinta. Aloitetaan integraatio mahdollisimman pian. Pidetään yhteyttä kehittäjiin. Tehdään töitä etupainotteisesti ja hyvällä aikavaralla. Tehdään järjestelmästä modulaarinen ja vältetään töiden riippuvuuksia. Neuvotellaan tilannetta asiakkaan kanssa. Projektiryhmän jäsenillä on oma working copy omalla koneellaan 1 4 Työt eivät etene Tiedetään, että hajautetussa projektissa kommunikaatio on haasteellista ja tämän takia on luotu postituslista ja määritelty kommunikaatiokanavat huolella. Wikiä puhdistetaan säännöllisesti. 1 4 Osaa projektista ei pystytä toteuttamaan kurssin puitteissa. 1 3 Työryhmän allokoitavissa olevat tunnit vähenevät, joten myös laajuutta on pienennettävä. Minimoidaan uusien tuntemattomien tekniikoiden valintaa. Ja tutustutaan vaihtoehtoisiin tekniikoihin riskialtteissa teknologioissa. Prototypisoinnilla pyritään vähentämään riskejä. Pidetään huolta yhteishengestä ja jaetaan tehtävät tasaisesti. Otetaan huomioon henkilöiden mielenkiinnot ja tehtävien haastavuus. 1 2 Projekti viivästyy. Pidetään säännöllisesti kommunikointia, ja otetaan selvää asioista tarpeeksi ajoissa. Taulu 9. Riskiloki Vaikutus Hallintatoimenpiteet Vastuuhenkilö Projektiryhmä Projektipäällikkö ja adapterivastaavat Projektipäällikkö ja adapterivastaavat Projektipäällikkö SVN-admin Arkkitehdit Projektipäällikkö Projektipäällikkö Projektipäällikkö ja adapterivastaavat Projektipäällikkö.