PROJEKTISUUNNITELMA

Transkriptio

1 PROJEKTISUUNNITELMA

2 PROJEKTISUUNNITELMA 2 (27) 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 0.16 Kaarlo Lahtela Dokumentin läpiluku ja taiton tarkistaminen Tuomas Tolvanen Päivitetty työkalu-kappaletta 1.0 Aleksi Airola Julkaisu versio

3 PROJEKTISUUNNITELMA 3 (27) SISÄLLYS 1. JOHDANTO SIDOSRYHMÄT JA HENKILÖSTÖ Projektiryhmä: Dentego SE expert -ryhmä Kehittäjät TAVOITTEET Projektin 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 Laatusuunnitelma Työkalut Kehityslaitteisto Ohjelmistot Kehitysympäristö Standardit VAIHEISTUS...24

4 PROJEKTISUUNNITELMA 4 (27) 6.1. Aikataulu Projektin suunnittelu Toteutus Toteutus RISKI LOGI...27

5 PROJEKTISUUNNITELMA 5 (27) 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 (27) 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 Dentego-palvelin välittää sanomia Plusterveydeltä Pohjolaan Projektiryhmä: Dentego SE expert -ryhmä Kuva 1. Sidosryhmät ja henkilöstö 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ö Nimi Aleksi Airola Puhelin Sähköposti aleksi.airola##tkk.fi Kiinnostus Luistelu, sulkapallo, elokuvat ja hyvä ruoka.

7 PROJEKTISUUNNITELMA 7 (27) Rooli QA-vastaava, tietoliikenneadapterin vastaava Nimi Lahtela, Kaarlo Puhelin Sähköposti kaarlo.lahtela##tkk.fi Kiinnostus Elokuvat, liikunta, ohjelmointi. Rooli Pääarkkitehti, sovellusadapterin vastaava, MediaWiki admin, SVN admin Nimi Tolvanen, Tuomas Puhelin Sähköposti tttolvan##cc.hut.fi Kiinnostus Kehittäjät Rooli Kehittäjä, projektipäällikön assistentti Nimi Ahti, Lari Puhelin Sähköposti lahti##cc.hut.fi Kiinnostus Suunnistus, ohjelmointi Rooli Kehittäjä Nimi Kauppinen, Antti Puhelin Sähköposti aekaupp1##cc.hut.fi Kiinnostus Rooli Kehittäjä, QA-assistentti Nimi Kiiski, Lauri Puhelin Sähköposti Lauri.kiiski##iki.fi Kiinnostus Kehittäjät toimivat projektissa pienryhmissä myös suunnittelijoina. 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ä, arkkitehdin assistentti Nimi Vanhapiha, Olli Puhelin Sähköposti ovanhapi##cc.hut.fi Kiinnostus

8 PROJEKTISUUNNITELMA 8 (27) 3. TAVOITTEET 3.1. Projektin 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

9 PROJEKTISUUNNITELMA 9 (27) 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 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.

10 PROJEKTISUUNNITELMA 10 (27) 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 Kaarlo Lahtela Tuomas Tolvanen Lari Ahti Antti Kauppinen Lauri Kiiski Timo Töyry Olli Vanhapiha Yhteensä 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.

11 PROJEKTISUUNNITELMA 11 (27) 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 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

12 PROJEKTISUUNNITELMA 12 (27) 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. 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äärittelydokumentti Aleksi Airola, Kaarlo Lahtela to Projektiryhmä kello 11

13 PROJEKTISUUNNITELMA 13 (27) 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 Aleksi Airola to SE expert kello 11 -iteraatiosuunnitelma -ryhmä Vertaistestausohjeet kello 11 Vertaistestausraportti kello 11 Iteraatio 2 -dokumentit kello 11 Tuotos Dokumentit Kaaviot Demot Työkalu MS Word MS Visio, MS Powerpoint, Magic Draw MS Powerpoint Riskienhallinta Tuntiraportointi 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 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).

14 PROJEKTISUUNNITELMA 14 (27) Kommunikaatio 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. 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ä

15 PROJEKTISUUNNITELMA 15 (27) 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 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.

16 PROJEKTISUUNNITELMA 16 (27) Virheiden seuranta Versionhallinta 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 kurssin tarjoamaa Bugzilla järjestelmää. Virheet täytyy kirjata järjestelmään, jos Virhettä ei korjata Virhe löytyy järjestelmä- tai hyväksyntätestauksessa Vertaisryhmä tai asiakas löytää sen Virhettä ei kirjata järjestelmään, jos Virhe havaitaan toteutuksen yhteydessä ja se korjataan heti Virhettä raportoitaessa täytyy mahdollisimman hyvin kuvata virhe ja ympäristö, jossa virhe ilmenee. Lisäksi täytyy kuvata virheen ilmentymistiheys ja miten sen pystyy tuottamaan uudestaan, sekä työmääräarvion. Virheelle tulee antaa vakavuusluokitus neliportaisella asteikolla: 1. Kriittinen Estää ohjelman käytön. Kehitystyö on keskeytettävä ohjelmiston korjaamisen ajaksi. 2. Vakava Vaikeuttaa vakavasti ohjelman käyttöä. Kehitystyötä voidaan jatkaa, mutta virheestä vastuullinen ei jatka kehitystyötä ennen kuin virhe on korjattu. 3. Pieni Vaikeuttaa ohjelman käyttöä, mutta ohjelman saa toimimaan jollakin muulla tavalla. Virhe tulee korjata ennen iteraatioiden loppua. 4. Mitätön Virhe on kosmeettinen, eikä vaikeuta ohjelmiston käyttöä. Korjataan jos aikaa riittää. Virheiden seurannasta on vastuussa QA-ryhmä (Kaarlo lahtela ja Lauri Kiiski). QA-ryhmä asettaa kullekin virheelle vastuullisen ellei raportoija ole ottanut sitä omalle vastuulleen. Lisäksi QA-ryhmä seuraa virheiden tilaa ja tarvittaessa korjaa myös työmäärä arvoita. Kaikille ryhmän jäsenille luodaan tunnukset Bugzillaan, kuten myös asiakkaalle, mentorille ja vertaistestaajille. PP-iteraation lopulla tutkitaan mahdollisuutta käyttää Jira-ohjelmistoa virheidenseurantaan. Bugzillan käyttö on koettu vaikeaksi ja että se ei vastaa tarpeita. Päätös käytettävästä työkalusta tehdään I1:en alussa. 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.

17 PROJEKTISUUNNITELMA 17 (27) Koodausstandardi 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. 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 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

18 PROJEKTISUUNNITELMA 18 (27) Vertaistestaus Vaatimustenhallinta Team Building tapahtuma Pienryhmät 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. Testaukseen on varattu kahdeksan tuntia. Vertaistestaussuunnitelma laaditaan iteraatio 2:n alussa, kun tiedetään miten vertaustestauksella 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. 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ä. 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

19 PROJEKTISUUNNITELMA 19 (27) protoryhmä proto Olli Vanhapiha XML Schema ryhmä Sovellusadapterin XSD Schema Tuomas Tolvanen Lari Ahti Antti Kauppinen QA-ryhmä Laatusuunnitelma Kaarlo Lahtela SE expert ryhmä Vaatimustenmäärittelyryhmä Prototypisointi Katselmointikäytännöt 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ö. 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.

20 PROJEKTISUUNNITELMA 20 (27) 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ä. Cruise Control Ohjelmistoa käytetään testauksen automatisointiin Ant-build työkalun kanssa Lauri Kiiski ja Olli Vanhapiha CaliberRM Ohjelmisto tarjoaa palvelun vaatimusten keräämiseen ja hallinnointiin. Aleksi Airola ja Kaarlo Lahtela Static methods Tuomas Tolvanen ja Timo Töyry Pariohjelmointi / TDD Antti Kauppinen ja Lari Ahti 5.2. Laatusuunnitelma 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)

21 PROJEKTISUUNNITELMA 21 (27) Määrittely o Käytetään tuntikirjanpidon apuna. o Lisenssi: MSDN Academic Alliance. o Lisätietoja: Borland CaliberRM. (Versio 2005) o Lisenssi: Kaupallinen. Saadaan asiakkaalta. o Lisätietoja: 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öä

22 PROJEKTISUUNNITELMA 22 (27) Ohjelmointikielet XML Kehitysympäristö 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: 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ö

23 PROJEKTISUUNNITELMA 23 (27) 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ä 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 FNVOICE versio 1.3 Sähköisen laskun rakenteen

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

25 PROJEKTISUUNNITELMA 25 (27) 6.3. Toteutus 1 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) 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öä 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

26 PROJEKTISUUNNITELMA 26 (27) Tehtävät: Tämä tarkentuu I1 iteraation alussa 6.4. Toteutus 2 Toteutus iteraatiossa kaksi toteutetaan hoitoehdotuksen ja maksusitoumuksen välittäminen.

27 PROJEKTISUUNNITELMA 27 (27) 7. RISKI LOGI ID Seloste Toden näköisyys 1 Opiskelija lopettaa kurssin kesken 2 Projektiin valitaan teknologioita, joita ei pystytä hallitsemaan kurssin puitteissa. 3 Asiakkaalla ei ole tarpeeksi aikaa projektiin 4 Järjestelmätoimitt ajalta ei saada tarpeeksi dokumentointia 5 Kehittäjät eivät tiedä mitä tehdä. 6 Järjestelmän integraatiossa tapahtuu ongelmia. 7 Kehityskoneen hajoaminen 8 Projektiryhmän jäsen sairastuu 9 Versionhallinta järjestelmä ei ole käytettävissä Riskilokin asteikko on 1-5, viitosen ollessa todennäköisin ja vakavin. Vaka vuus 2 4 Työryhmän allokoitavissa olevat tunnit vähenevät, joten myös laajuutta on pienennettävä. 2 4 Osaa projektista ei pystytä toteuttamaan kurssin puitteissa. Pidetään huolta yhteishengestä ja jaetaan tehtävät tasaisesti. Otetaan huomioon henkilöiden mielenkiinnot ja tehtävien haastavuus. Minimoidaan uusien tuntemattomien tekniikoiden valintaa. Ja tutustutaan vaihtoehtoisiin tekniikoihin riskialtteissa teknologioissa. Prototypisoinnilla pyritään vähentämään riskejä. 1 2 Projekti viivästyy. Pidetään säännöllisesti kommunikointia, ja otetaan selvää asioista tarpeeksi ajoissa. 3 4 Projektin suunnittelu ja toteutus viivästyy. 3 3 Projekti ei etene ja viivästyy. 3 5 Järjestelmää pitää muuttaa Neuvotellaan tilannetta asiakkaan kanssa. Pidetään yhteyttä kehittäjiin. Minimoidaan uusien teknologioiden valinta. 5 3 Kehitystyö viivästyy Tehdään töitä etupainotteisesti ja hyvällä aikavaralla. Kehitystyössä käytetään versionhallintaa. 4 2 Kehitystyö viivästyy Tehdään töitä etupainotteisesti ja riippuvuuksien takia hyvällä aikavaralla. 1 4 Työt seisovat Projektiryhmän jäsenillä on oma working copy omalla koneellaan Taulu 9. Riskiloki Vaikutus Hallintatoimenpiteet Vastuuhenkilö Projektipäällikkö ja Scrum masterit Arkkitehdit Projektipäällikkö. Projektipäällikkö Projektipäällikkö ja Scrum masterit. Projektipäällikkö ja Scrum masterit. Projektiryhmä Projektipäällikkö SVN-admin