PROJEKTISUUNNITELMA Dentego-palvelin

Transkriptio

1 PROJEKTISUUNNITELMA Dentego-palvelin

2 PROJEKTISUUNNITELMA 2 (36) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus Kaarlo Lahtela Ensimmäinen versio Aleksi Airola Lisäyksiä riskilogiin ja resursseihin Kaarlo Lahtela Riskin hallintaa lisätty. Aleksi Airola Aleksi Airola Lisätty kohdat Kaarlo Lahtela Oikoluku Aleksi Airola Kappale 1 lisätty Aleksi Airola Kappaleeseen 6.1 lisätty tekstiä ja kappaleeseen 6.2 lisätty tehtäviin allokoidut tunnit ja vastuulliset Aleksi Airola Päivitetty kappaleita 2.1 ja Aleksi Airola Lisätty kappale 4 ja Aleksi Airola Lisätty kappaleet 5.1.2, 5.1.3,5.1.5, , ja Aleksi Airola Lisätty kappaleet , ja Aleksi Airola Lisätty kappaleeseen 2 organisaatiokaavio ja kappaleet 5.1.4, ja Päivitetty riskilogi Aleksi Airola Päivitetty katselmoinnissa havaittujen puutteiden mukaan kappaleita Aleksi Airola Päivitetty kappaleita 6, 6.1, 6.2 ja lisätty kappale Aleksi Airola Päivitetty kappaleeseen 4.1 varatut työtunnit taulukkoa Kaarlo Lahtela Dokumentin läpiluku ja taiton tarkistaminen Tuomas Tolvanen Päivitetty työkalu-kappaletta Aleksi Airola Julkaisu versio Aleksi Airola Lisätty kappaleet , ja 6.3 sekä muokattu kappaletta Aleksi Airola Muokattu kappaletta 2.1 vastuiden osalta ja riskit päivitetty Kaarlo Lahtela virheiden seuranta siirretty laatudokumenttiin Aleksi Airola Muokattu kappaleita 6.3, ja riski loki päivitetty Kaarlo Lahtela Katselmoitu palautettava dokumentti Tuomas Tolvanen Päivitetty iteraatiosuunnitelma ja resurssointi. Päivetty menetelmiä. Dokumenttien katselmointiaikataulut I2 kp Sepa tilanteet päivitetty Riskiloki on päivitetty I2:sta varten Tuomas Tolvanen Päivitetty projektin toteutuneet tiedot. Päivitetty roolit vastaamaan roolimuutoksia. Viimeinen versio

3 PROJEKTISUUNNITELMA 3 (36) SISÄLLYS 1. JOHDANTO SIDOSRYHMÄT JA HENKILÖSTÖ Projektiryhmä: Dentego SE expert -ryhmä Kehittäjät TAVOITTEET Asiakkaan tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeytysehdot Projektin päättämisehdot RESURSSIT JA BUDJETTI Henkilöstö Materiaali Budjetti TYÖMENETELMÄT JA TYÖKALUT Työmenetelmät Iteratiivinen kehitys Iteraation suunnittelu Dokumentointi Riskienhallinta Tuntiraportointi Kommunikaatio Iteraatiodemo Virheiden seuranta Versionhallinta Koodausstandardi Vertaistestaus Vaatimustenhallinta Team Building tapahtuma Pienryhmät Prototypisointi Katselmointikäytännöt Sepa-aiheet Suunnitelu Prosessinkehitys Laatusuunnitelma Työkalut Kehityslaitteisto Ohjelmistot Kehitysympäristö Standardit... 25

4 PROJEKTISUUNNITELMA 4 (36) 6. VAIHEISTUS Aikataulu Projektin suunnittelu Toteutus Toteutus RISKI LOGI Riskien seuranta Nykyiset riskit Toteutuneet riskit... 36

5 PROJEKTISUUNNITELMA 5 (36) 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 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.

6 PROJEKTISUUNNITELMA 6 (36) 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ö

7 PROJEKTISUUNNITELMA 7 (36) 2.1. Projektiryhmä: Dentego SE expert -ryhmä Projektiryhmän kotivut ovat sekä postituslista on dentego##list.hut.fi. Käytössä on MediaWiki osoitteessa wiki.dentego.com. SE Expert ryhmä on vastuussa projektinhallinnallisista asioista ja työn koordinoinnista. Rooli Projektipäällikkö, vaatimusmäärittely-vastaava Nimi Aleksi Airola Puhelin Sähköposti aleksi.airola##tkk.fi Kiinnostus Luistelu, sulkapallo, elokuvat ja hyvä ruoka. Rooli QA-vastaava, tietoliikenneadapteri-vastaava Nimi Lahtela, Kaarlo Puhelin Sähköposti kaarlo.lahtela##tkk.fi Kiinnostus Elokuvat, liikunta, ohjelmointi. Rooli Projektipäällikön sijainen, Pääarkkitehti, sovellusadapteri-vastaava, SVN admin Nimi Tolvanen, Tuomas Puhelin Sähköposti tttolvan##cc.hut.fi Kiinnostus Kehittäjät Kehittäjät toimivat projektissa pienryhmissä myös suunnittelijoina. Rooli Kehittäjä, projektipäällikön assistentti Nimi Ahti, Lari Puhelin Sähköposti lahti##cc.hut.fi Kiinnostus Suunnistus, ohjelmointi Rooli Kehittäjä, Tietokantavastaava Nimi Kauppinen, Antti Puhelin Sähköposti aekaupp1##cc.hut.fi Kiinnostus

8 PROJEKTISUUNNITELMA 8 (36) Rooli Kehittäjä, QA-assistentti Nimi Kiiski, Lauri Puhelin Sähköposti Lauri.kiiski##iki.fi Kiinnostus Rooli Kehittäjä Nimi Töyry, Timo Puhelin Sähköposti ttoyry##cc.hut.fi Kiinnostus Valokuvaus, kuvienkäsittely, tietokoneet (ja ym. elektroniikka), ohjelmointi, pienoismallit Rooli Kehittäjä, Arkkitehti Nimi Vanhapiha, Olli Puhelin Sähköposti ovanhapi##cc.hut.fi Kiinnostus

9 PROJEKTISUUNNITELMA 9 (36) 3. TAVOITTEET 3.1. Asiakkaan tavoitteet Asiakkaan tavoitteet kuvattuna korkealla abstraktiolla. Asiakas hakee toimivan, tietoturvallisen ja luotettavan ohjelmiston lisäksi kokemusta ohjelmistokehityksen prosesseista ja siinä käytettävistä työkaluista. Tavoite kurssiprojektiin liittyen 1 Saada ohjelmisto, joka toteuttaa PlusTerveyden ja Pohjolan välisen sopimuksen mukaisen hoito- ja korvauskäsittelyn sekä laskun elektronisessa muodossa. Kriteerit: Välityspalvelinohjelmisto on toteutettu ja viestiyhteys on testattu Doctoral-järjestelmän ja TEpalvelimen kanssa. Ohjelmisto on valmiudessa ottaa tuotantokäyttöön. 2 Helpottaa uusien viestityyppien määrittelyä (viestinvälitys rungon määrittely). Kriteerit: Viestityyppejä voidaan määritellä kääntämättä ohjelmakoodia 3 Oppia uutta prosesseista ja olio-pohjaisesta mallintamisesta ja niissä käytetyistä työkaluista. Kriteerit: Käytetyt menetelmät ja suunnitelmat esitellään asiakkaalle. Muut tavoitteet projektiin liittyen 4 Vastaanottojen sähköisten tiedonsiirto valmiuksien kehittäminen tarvittavalle tasolle kaikilla vastaanotoilla Kriteerit:. Asiakkaan toteuttamat muutokset Doctoral-ohjelmistoihin tehty. 5 Sähköisen tiedonsiirron kehittäminen ulkopuolisiin osapuoliin. 6 Vastaanottojen tehokkuuden parantaminen sähköisen tiedonsiirron avulla. 7 Sopeutuminen tulevaisuuden vaatimuksiin(mobiili). Taulu 1. Asiakkaan tavoitteet prioriteettijärjestyksessä Asiakaan tavoitteet on jaettu kurssiprojektiin liittyviin tavoitteisiin, sekä muihin projektiin liittyviin tavoitteisiin. Kurssiprojektiin liittyvät tavoitteet tarkastellaan projektiryhmän näkökulmasta. Tavoitteille on määritelty kriteerit validointia varten Henkilökohtaiset oppimistavoitteet Jäsen Ahti, Lari Airola, Aleksi Lahtela, Kaarlo Kauppinen, 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ä

10 PROJEKTISUUNNITELMA 10 (36) Antti Kiiski, Lauri Tolvanen, Tuomas Töyry, Timo Vanhapiha, Olli 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 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 3.4. Projektin päättämisehdot 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. Projekti päättyy iteraatiodemoon. Tähän mennessä kaikki tuotokset ovat toimitettu asiakkaalle. Projektin päättyessä myös kaikki projektiryhmän vastuut projektin tuotosten suhteen raukeavat.

11 PROJEKTISUUNNITELMA 11 (36) 4. RESURSSIT JA BUDJETTI Kappaleessa kerrotaan projektissa tarvittavat ja käytössä olevat resurssit, materiaalit ja budjetti Henkilöstö 4.2. Materiaali Taulukko 3 on resursoitu käytössä olevat työtunnit ja allokoitu ne iteraatioittain. Päivitetty Henkilö PP I1 I2 Yhteensä Aleksi Airola Kaarlo Lahtela Tuomas Tolvanen Lari Ahti Antti Kauppinen Lauri Kiiski Timo Töyry Olli Vanhapiha Yhteensä Taulukko 3. Varatut työtunnit Ryhmän poissaolot iteraatioiden aikana: Lauri on poissa kaksi tammikuun viimeistä viikkoa ja haluaa aloittaa iteraatio 2:n tammikuun alussa. Aleksi on sairaslomalla 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 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, sekä Atlassia JIRA issue tracker. 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.

12 PROJEKTISUUNNITELMA 12 (36) MediaWiki ja SVN toimivat projektin ajan projektiryhmän käytössä olevalla www-palvelimella. Jatkuvaan integrointiin käytetään Ant-build työkalua ja Cruise Controllia. Asiakkaan lisenssit ovat kehitysryhmän käytössä projektin loppuun asti, jonka jälkeen lisenssit palautuvat asiakkaalle Budjetti 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 Ympäristöjen pystytys 50h Hankittavat resurssit Ryhmän käyttämä aika 1520h Materiaalit SoberIT:n maksu Together Architect lisenssi CaliberRM lisenssi Alihankinta Mentor konsultointi 35h Kustannukset yhteensä Taulu 5. Kustannuserät

13 PROJEKTISUUNNITELMA 13 (36) 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 Iteratiivinen kehitys Iteraation suunnittelu Dokumentointi 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. 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. 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, toteutusiteraatiossa 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 SE expert ryhmä kello 11 suunnitelma Projektisuunnitelma Aleksi Airola to Projektiryhmä kello 11 Arkkitehtuuridokumentti Tuomas su SE expert kello 11 Tolvanen -ryhmä Vaatimustenmäärittely- Aleksi Airola, to Projektiryhmä kello 11

14 PROJEKTISUUNNITELMA 14 (36) dokumentti Kaarlo Lahtela Laatusuunnitelma Kaarlo Lahtela to SE expert kello 11 Lauri Kiiski -ryhmä Iteraatio 1 Aleksi Airola to SE expert kello 11 -iteraatiosuunnitelma -ryhmä Iteraatio 1 -dokumentit Yllä mainitut ti SE expert kello 11 -ryhmä Iteraatio 2 Tuomas ma SE expert kello 11 -iteraatiosuunnitelma Tolvanen -ryhmä Vertaistestausohjeet Kaarlo Lahtela to SE expertit kello 11 Vertaistestausraportti Kaarlo Lahtela ti SE expert-ryhmä kello 11 Iteraatio 2 -dokumentit Tuomas Tolvanen Pienryhmät kello Riskienhallinta Taulu 6. Dokumentit, niiden vastuut ja määräajat 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. Tuotos Dokumentit Kaaviot Demot Taulu 7. Työkalut Työkalu MS Word MS Visio, MS Powerpoint, Magic Draw MS Powerpoint 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). Riskienhallinnan käytetyt menetelmät ja riskien toteutumista on seurattu kappaleessa 7.

15 PROJEKTISUUNNITELMA 15 (36) Tuntiraportointi Kommunikaatio Riskit ovat päivitetty jokaisen iteraation lopussa ja suunniteltu toimenpiteet seuraavaan iteraatioon. Tuntiraportointiin käytetään Excel taulukkoa. Jokaisella ryhmän jäsenellä on oma Excel-tiedosto, 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. 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

16 PROJEKTISUUNNITELMA 16 (36) 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 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 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 Olli Vanhapiha. 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.

17 PROJEKTISUUNNITELMA 17 (36) Virheiden seuranta Versionhallinta Koodausstandardi Tarkemmat kellonajat ehdotetaan kurssin puolesta ja ovat nähtävissä kurssin kotisivuilla. Projektipäällikkö varmistaa ajan sopimisen asiakkaalle ja tekniselle ohjaajalle. PP iteraation demo pidetään klo 11 ja I1-demo 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. 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 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. Ohjelmoinnissa käytetään Java Coding Convention standardia ( Koodi kommentoidaan JavaDoc:n ( 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.

18 PROJEKTISUUNNITELMA 18 (36) Vertaistestaus setadapterbit(); setadb(); // EI NÄIN 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 Vaatimustenhallinta Rajapinta tulee dokumentoida suomenkielellä siten, että jokaisessa luokassa on tagi ja kuvaus luokasta ja sen tarjoamista toiminnoista. Kaikki public, protected ja package tason metodeissa ja muuttujissa tulee 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 Dentego ryhmän vertaistestausryhmä on ryhmä numero 8. Vertaistestaussuunnitelma laaditaan iteraatio 2:n alussa, kun tiedetään miten vertaistestauksella voidaan parhaiten tukea projektin testaustavoitteita. 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

19 PROJEKTISUUNNITELMA 19 (36) Tarvittaessa projektin laajuutta arvioidaan uudestaan Ryhmähengen ylläpito Team Building tapahtuma Team Building tapahtuma pidettiin torstaina kello 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ä. Iteraation kaatotilaisuus I1-iteraation jälkeen järjestettiin ryhmän sisäinen vapaamuotoinen iteraation päätösillallinen Cantina West-ravintolassa 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 protoryhmä Web Service pohjainen proto Kaarlo Lahtela Olli Vanhapiha XML Schema ryhmä Sovellusadapterin XSD Schema Tuomas Tolvanen Lari Ahti Antti Kauppinen QA-ryhmä Laatusuunnitelma Kaarlo Lahtela SE expert ryhmä Vaatimustenmäärittelyryhmä Taulu 8. Pienryhmien kokoonpanot Projektin hallintaan liittyvä dokumentointi Vaatimustenmäärittely dokumentti 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ö.

20 PROJEKTISUUNNITELMA 20 (36) Prototypisointi Katselmointikäytännöt 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. 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 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 kurssin kanssa. Aiheet tukevat projektin aikana kehitystyötä.

21 PROJEKTISUUNNITELMA 21 (36) Jatkuva Integrointi Jatkuvaan integrointiin käytetään CruiseControllia, jolla automatisoidaan mm. testejä ja niistä raportoimista Lauri Kiiski ja Olli Vanhapiha Edistyminen: CruiseControl-palvelin on pystytetty Ryhmän käyttöön osoitteeseen Palvelin kääntää koodit kerran tunnissa ja ajaa testit. CaliberRM Ohjelmisto tarjoaa palvelun vaatimusten keräämiseen ja hallinnointiin. Aleksi Airola ja Kaarlo Lahtela Edistyminen: Vaatimusmäärittely on toteutettu CaliberRM-järjestelmään. Static methods Tuomas Tolvanen ja Timo Töyry Edistyminen: I1:ssä järjestettiin formaali koodikatselmointi ja sitä ennen koulutus katselmointikäytännöistä. Katselmoinnin tulokset on kirjattu ja havaitut puutteet ohjelmassa jaettu tehtäviksi. Katselmoinnin analysointi on kesken. I2:ssa järjestettiin koodin läpikäynti arkkitehtiryhmän kesken. Lisäksi loppudokumentit katselmointiin. Staattisessa analyysissä on tutustuttu erilaisiin työkaluihin ja valittu CCCC käytettäväksi CruiseControlin yhteydessä. CCCC on integroitu cruisecontrolpalvelimelle. Staattisten työkalujen antamien tulosten analysointi on vielä kesken. Pariohjelmointi / TDD Antti Kauppinen ja Lari Ahti Edistyminen: Suunnitelman mukaisesti pariohjelmoinnista pidettiin lyhyt esitys viikkopalaverissa I1-iteraatiosa. Samalla päätettiin järjestää viikoittain yhteisiä tilaisuuksia, joissa pariohjelmointa tehtäisiin. Näitä ehdittiin ensimmäisessä iteraatiossa järjestää kolme kertaa 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 Pienryhmät. Arkkitehtuuriryhmän toiminnasta vastaa pääarkkitehti. Arkkitehtuurisuunnittelussa otetaan huomioon järjestelmän toiminnalliset vaatimukset, laatuvaatimukset, sekä muut projektiin arkkitehtuurisesti

22 PROJEKTISUUNNITELMA 22 (36) merkittävät rajoitteet. Arkkitehtuurisuunnittelussa asiakkaiden kanssa käytävien suunnittelukeskusteluiden ja arkkitehtuuriryhmän tapaamisten perusteella pääarkkitehti laatii arkkitehtuurisuunnitelman, joka kuvaa järjestelmän arkkitehtuurin eri näkökulmien (toiminnallinen, informaatio, prosessi ) mukaisesti. Ohelmistosuunnittelussa käytetään UML-mallinnusta suunnittelupäätösten visualisointiin. UML-mallit toimivat toteutuksen pohjana, eivätkä niiden ole tarkoitus kuvata lopullista järjestelmää täydellisesti. Lopullisen järjestelmän kuvaus laadittiin arkkitehtuurimäärittelyn yhteyteen jatkokehitystä silmälläpitäen I2-iteraation lopussa Prosessinkehitys 5.2. Laatusuunnitelma 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. QA-dokumentointi on siirretty erilliseen QA-dokumenttiin Työkalut Projektissa käytetään seuraavia työkaluja 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 Ohjelmistot Projektinhallinta Micrsoft Excel. (Versio 2003) o Käytetään tuntikirjanpidon apuna. o Lisenssi: MSDN Academic Alliance. o Lisätietoja: Määrittely Borland CaliberRM. (Versio 2005) o Lisenssi: Kaupallinen. Saadaan asiakkaalta. o Lisätietoja:

23 PROJEKTISUUNNITELMA 23 (36) Suunnittelu MagicDraw UML-työkalu o o Lisenssi tarjotaan kurssin puolesta. Dokumentointi Microsoft Word. (Versio 2003) o Lisenssi: MSDN Academic Alliance. o Lisätietoja: Kommunikaatio MediaWiki. (Versio 1.8.2) o Lisenssi: GNU General Public License version 2. o Lisätietoja: Skype MSN Messenger Irc Ohjelmointiympäristö Eclipse. (Versio 3.2.1) o Lisenssi: Eclipse Public License versio 1.0. o Lisätietoja: JBoss Eclipse IDE. (Versio 1.5) o Lisenssi: Open source. o Lisätietoja: 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: 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 XML Java JDK (Versio 1.5 SE) o Käytetään ohjelmiston toteutuksessa. o Lisenssi: Sun's Binary Code License. Altova XMLSpy Suite. (Versio 2006 Professional edition) o Lisenssi: Kaupallinen. Saadaan asiakkaalta. o Lisätietoja:

24 PROJEKTISUUNNITELMA 24 (36) Kehitysympäristö 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 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ä

25 PROJEKTISUUNNITELMA 25 (36) 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 29.htm#_3_HL7_CDA_R2 määritykset HL7 CDA v3 Määritelee tiedonsiirron 29.htm#_6_HL7_V3_sanomat_1 Finvoice versio 1.2 Sähköisen laskun rakenteen

26 PROJEKTISUUNNITELMA 26 (36) 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ä Aikataulu Projektin suunnittelu (PP) iteraatio on sisältäen kaksi deadlinea on iteraatiosuunnitelman palautus ja dokumenttien palautus. Dokumentteihin kuuluu projektisuunnitelma, vaatimustenmäärittely dokumentti, sekä edistymisraportti. Iteraatio demo pidetään tai Sisäisiä virstanpylväitä on team-building tapahtuma arkkitehtuuri ja vaatimusmäärittely draftien osalta. Projektisuunnitelma ja vaatimustenmäärittely dokumenttien toinen luonnos valmistuu kello 18 mennessä vuorokautta ennen niiden katselmointitilaisuutta. Dokumentit jäädytetään kello 18 ja ne palautetaan kello 11 mennessä kurssin palautusjärjestelmään. Arkkitehtuuri dokumentin luonnosta viimeistellään viikon 42 viikonloppuna ja se julkaistaan maanantaina Toteutus iteraatiot on jaettu kahtia ja niiden puolessa välissä iteraatiota pidetään välidemo. I1 iteraatio on ja välidemo pidetään torstaina I2 iteraatio on ja välidemo pidetään perjantaina Iteraatio 2. aikataulu on esitelty kappaleessa Projektin suunnittelu Tavoitteet:

27 PROJEKTISUUNNITELMA 27 (36) Projektin suunnittelu ja seurantamenetelmien käyttöönotto mm. tuntikirjanpito 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 ) 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.

28 PROJEKTISUUNNITELMA 28 (36) 6.3. Toteutus 1 Toteutus iteraatio1 yksi on jaettu kahteen osaan. Välidemo pidetään 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

29 PROJEKTISUUNNITELMA 29 (36) Kehittää projektinhallinnallisia prosesseja Kehittää kehitystyökalujen käyttöä Valmistella tuotantoympäristön pystytyssuunnitelma ja versionhallinnan siirto asiakkaan tuotantoympäristöön Tuotokset: Ohjelmisto Tietoliikenneadapteri prototyyppi Hibernate prototyyppi Testattu välityspalvelu ohjelmisto Elektronisen laskun sovellus Dokumentit Päivitetty projektisuunnitelma Päivitetty vaatimustenmäärittelydokumentti Tekninen määrittelydokumentti Laatusuunnitelma Test caset Laaturaportti ja testiloki Edistysmisraportti kalvoesitys

30 PROJEKTISUUNNITELMA 30 (36) Tehtävät: Vastuut ovat määritelty kappaleessa 2.1. Toteustusiteraatio 1 (I1) 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

31 PROJEKTISUUNNITELMA 31 (36) 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.

32 PROJEKTISUUNNITELMA 32 (36) 6.4. Toteutus 2 Toteutus 2. iteraatiossa toteutetaan ohjelman loppu toiminnallisuus, suoritetaan järjestelmätason testaus, sekä tuotetaan kaikki ohjelman luovuttamiseen tarvittavat dokumentit ja asennetaan järjestelmä asiakkaan käyttöön. Iteraation aikana asiakkaan tekninen henkilöstö koulutetaan järjestelmän ylläpitoon ja jatkokehitykseen. Iteraatio jakautuu kahteen osaan, jossa ensimmäinen osa Toteutus 1. ja Testaus 1. päättyy asiakasdemoon. Ennen asiakasdemoa pidetään feature freeze. Tavoitteena on, että kaikki ohjelma-toiminnallisuus on toteutettuna asiakasdemoon mennessä. Toteutus 2. iteraatiossa keskitytään toimintojen laadun parantamiseen ja Testaus 2. pitää sisällään järjestelmien välistä testausta ja hyväksymistestausta. Iteraation tuotosten tavoitteet Toteuttaa jäljellä oleva toiminnallisuus Suorittaa järjestelmä- ja hyväksyntätestit ohjelmistolle Dokumentoida järjestelmä luovutusta varten Asentaa järjestelmä asiakkaan käyttöön

33 PROJEKTISUUNNITELMA 33 (36) Yksilöidyt tehtävät koko iteraatiolle on kuvattu kohdassa tehtävät: Tuotokset: Ohjelmisto Lopullinen käyttötapausten mukainen viestinvälitystoiminnallisuus. Ylläpitokäyttöliittymä. Lopullinen tietokanta. Asennus-skriptit ja konfiguraatio Dokumentit Projektisuunnitelma Vaatimusmäärittely Arkkitehtuurimäärittely ja kuvaus Tekninen määrittelydokumentti Vertaistestaussession logit oma ja toinen ryhmä. Vertaistestauksen yhteenveto. Laatusuunnitelma Test caset Laaturaportti ja testiloki Käyttöohje Loppuraportti Projektin lopputaportti kalvoesitys Sepa-raportit ja päiväkirjat Iteraation tehtävät: Toteustusiteraatio Projektinhallinta Projektinhallinta 27 Demo ja valmistelu 16 Suunnittelu ja Dokumentointi Projektisuunnitelma 12 Iteraatiosuunnitelma 2 Vaatimusmäärittely 7 Arkkitehtuuri 9 Tekninen määrittely 14 Laatudokumentti 3 Testaussuunnittelu 5 Laaturaportti 4 Vertaistestaus ohje & raportti 8 SEPA-raportit ja päiväkirjat 24 Informointi ja kommunkointi Viikkopalaverit 46 Mentor ja Asiakaspalaverit 10 Muut palaverit 16 Kommunikointi 19 Tekninen koulutus asiakkaalle 16 Laadunvarmistus Intergaatiotestaus 22 Systeemitestaus, Hyväksymistestaus 6 Katselmoinnit 27 Vertaistestaus 14