T Projektisuunnitelma

Transkriptio

1 T Projektisuunnitelma OtaShop2 Versio Päivämäärä Tekijä Kuvaus P. Ranne & Halme Muutokset hyväksytty Halme Riskitaulukko poistettu, kpl 6 muokattu Halme 1.5, 2.2, 3.2, 4.1, 5.2, 6.4 muokattu Halme Kappaleet 5.1 ja 5.2 yhdistetty, 4.2 ja 5.3 muokattu Halme Muutettu PDF:ksi, Toteutus1-vaihe alkaa Halme Oikoluettu ja korjattu Halme Viimeistelty palautusta varten Ojanen Lisätty tavoitteet, täydennetty refaktorointia Inkinen Lisäsin henk.koht tehtävä, sekä tavoitteet Halme Muokattu kappaletta Larmo Lisätty kohta 5.1.X Larmo Riskienhallintasuunnitelma Inkinen Työtavat ja henkilökohtaiset tehtävät Larmo.css tyylimäärittelyt lisätty Sisältö 1. Johdanto 1.1 Projektin tarkoitus ja laajuus 1.2 Järjestelmä ja käyttöympäristö 1.3 Oikeudet projektin tulokseen 1.4 Käytettävä terminologia 1.5 Projektisuunnitelman muuttaminen 2. Projektiin osallistujat 2.1 Projektiryhmä 2.2 Muut osallistujat 3. Tavoitteet ja arviointiperusteet 3.1 Asiakkaan tavoitteet 3.2 Projektiryhmän tavoitteet 3.3 Perusteet projektin keskeyttämiselle 3.4 Projektin päättyminen 4. Resurssit ja kustannusarvio 4.1 Henkilöstö 4.2 Materiaalit

2 4.3 Kustannusarvio 5. Työtavat ja -kalut 5.1 Työtavat 5.2 Henkilökohtaiset ohjelmistotuotannon tehtävät 5.3 Työkalut 5.4 Standardit 6. Vaiheistus 6.1 Aikataulu 6.2 Projektin suunnittelu 6.3 Toteuttamisvaihe Toteuttamisvaihe Toteuttamisvaihe Jakelu 7. Riskienhallintasuunnitelma 7.1 Riskienhallintakäytännöt 1. Johdanto 1.1 Projektin tarkoitus ja laajuus Teknillinen Korkeakoulu ja sen laboratoriot sekä muut yksiköt julkaisevat vuosittain lukuisia väitöskirjoja ja muita julkaisuja. Julkaisuja on mahdollista tilata laboratorioilta kulu- ja toimitusmaksua vastaan. Tähän asti tilaukset on hoidettu keskitetysti siten, että kirjaston kaukopalvelu on ottanut tilaukset vastaan ja välittänyt tilaukset manuaalisesti julkaisijoille. Menettely vaatii runsaasti aikaa ja resursseja, sekä aiheuttaa välillä sekaannuksia, kun kaukopalvelu toimii prosessissa vain "ylimääräisenä" välittäjänä. OtaShop2-järjestelmä on tarkoitus kehittää automatisoimaan tätä prosessia. Tällä tavalla pyritään helpottamaan sekä asiakkaiden, TKK:n kirjaston että julkaisijoiden työtä. Samalla halutaan antaa TKK:sta modernimpi kuva; moni muu julkaisuja myyvä koulu tarjoaa jo www-pohjaista automatisoitua palvelua. OtaShop2-järjestelmän kehittäminen tullaan toteuttamaan TKK:n kurssin "T Tietojenkäsittelyopin ohjelmatyö" harjoitustyönä. Varsinaiseen projektiryhmään kuuluu seitsemän opiskelijaa, joista kukin tulee tekemään projektin aikana noin 190 tuntia töitä. Projektiryhmän osalta kokonaistyömäärä tulee siis olemaan noin 1330 tuntia. Tämän lisäksi projektiin osallistuu asiakkaan edustajia sekä TKK:n hallinnon atk-päällikkö Pasi Ranne. Tässä dokumentissa järjestelmän toimittajalla tarkoitetaan opiskelijoista koostuvaa ryhmää (lyhyemmin "ryhmä") ja tuotteen tilaajalla eli asiakkaalla järjestelmän määrittelyyn osallistuvia ryhmän ulkopuolisia tahoja (mm. TKK:n kirjasto, Hallinnon ATK-päällikkö Pasi Ranne, TKK:n kirjanpito- ja maksuliikennepalvelut, TKK:n viestintä). 1.2 Järjestelmä ja käyttöympäristö OtaShop2-järjestelmä on verkkokauppa, josta voi tilata toimitusmaksua vastaan TKK:n laboratorioiden ja muiden yksiköiden julkaisuja. Asiakas voi selata tietokannasta löytyviä julkaisuja hakea esimerkiksi tietyn laboratorion julkaisuja. Kun asiakas on löytänyt hakemansa julkaisut, on hänen helposti pystyttävä tekemään tilaus, sekä maksaa toimituskulut suoraan verkkopankkia käyttäen.

3 Järjestelmän tulee rekisteröidä tehdyt tilaukset ja mahdollistaa laboratorion henkilökunnan selata heille tulleita tilauksia. Samalla henkilökunta saa tietää että julkaisut on jo maksettu. Henkilökunnan tehtäväksi jää ottaa asiakkaan yhteystiedot järjestelmästä, ja lähettää tilaus postitse asiakkaalle. Järjestelmä suunnitellaan palvelemaan kaikkia TKK:n julkaisuja toimittavia yksiköitä. Julkaisujen tilaaminen tulee mahdolliseksi kaikkialta maailmasta. 1.3 Oikeudet projektin tulokseen Ryhmän jäsenet ja asiakas ovat allekirjoittaneet sopimuksen, jossa rinnakkaiset tekijänoikeudet siirretään asiakkaalle. Sopimuspohja löytyy palautettujen dokumenttien joukosta. 1.4 Käytettävä terminologia Projektissa ja dokumenteissa käytettävä terminologia määritellään vaatimusmäärittelydokumentin [3] kappaleessa Projektisuunnitelman muuttaminen Projektiin (suunnitelmaan) tehtävät muutokset on hyväksytettävä asiakkaan edustajalla sekä projektipäälliköllä. Hyväksynnästä on tehtävä merkintä projektisuunnitelman versiohistoriaan dokumentin alussa. 2. Projektiin osallistujat 2.1 Projektiryhmä Ryhmän www-sivu löytyy osoitteesta Ryhmään voi ottaa yhteyttä projektipäällikön kautta Projektiryhmään kuuluu seitsemän opiskelijaa, joilla kullakin on oma vastuualueensa projektin aikana. Henkilöt sekä vastuualueet on esitelty alla: Projektipäällikkö: Vastaa projektista kokonaisuutena, huolehtii aikataulun suunnittelemisesta ja valvoo aikataulun toteutumista. Projektipäällikkö myös vastaa, että tarpeelliset dokumentit tulevat tehtyä. Käyttöliittymä: Vastaa käyttöliittymän suunnittelemisesta ja testaamisesta sekä käyttöohjeiden ja käyttäjien koulutuksen suunnittelusta. Kehitysympäristö: Vastaa kehitysalustasta sekä käyttöönoton ja ylläpidon suunnittelusta. Tietoturva: Vastaa järjestelmän suunnittelusta tietoturva-näkökulmasta. Testaus: Vastaa testauksen suunnittelusta ja dokumentoinnista. Ohjelmistoarkkitehtuuri: Vastaa järjestelmän ohjelmistoarkkitehtuurin suunnittelusta. Tietokanta: Vastaa järjestelmän tarvitsemien tietokantojen suunnittelusta sekä tietokantayhteyksistä jo olemassa oleviin kantoihin Vastuualue: Projektipäällikkö Nimi: Erkka Halme Puhelin: Sähköposti: Mielenkiinnon kohteet ja erikoistaidot: Kiinnostunut asiantuntijaorganisaation johtamisesta

4 sekä projektityöskentelyn menetelmistä Koulutus ja työkokemus: 4. vuosikurssin tietotekniikan opiskelija (Ohjelmistotuotanto ja -liiketoiminta), työkokemusta Oracle:n tietokannoista ja J2EE-sovelluksista. Vastuualue: Käyttöliittymä, käyttöohjeiden ja koulutuksen suunnittelu Nimi: Anna Larmo Puhelin: Sähköposti: Mielenkiinnon kohteet ja erikoistaidot: Käyttöliittymät, Java, html, css Koulutus ja työkokemus: 5 vuoden sähköteekkari Tietoliikennetekniikan koulutusohjelmasta. Pääaineena Vuorovaikutteinen digitaalinen media ja sivuaineena Televiestintäjärjestelmät. Vastuualue: Kehitysalusta, käyttöönoton ja ylläpidon suunnittelu Nimi: Antti Kärkkäinen Puhelin: Sähköposti: antti.karkkainen@iki.fi Mielenkiinnon kohteet ja erikoistaidot: J2EE, C++, Tietokannat, laitteistot, tietoliikenne Koulutus ja työkokemus: TKK/Tietotekniikka. Työkokemusta kuutisen vuotta ohjelmistoprojektien sekä tietojärjestelmien suunnittelun ja ylläpidon parissa Vastuualue: Tietoturva Nimi: Kai Inkinen Puhelin: Sähköposti: kai.inkinen@hut.fi Mielenkiinnon kohteet ja erikoistaidot: tietokoneet, tietoturva, salibandyn pelaaminen ja valmentaminen, maastopyöräily Koulutus ja työkokemus: 5 vuoden tietoteekkari, pääaine tietoturva. Työkokemusta 2,5 vuotta Linux-ylläpitäjänä sekä mukana erilaisissa koulutus- ja softaprojekteissa. Muuta sekalaista alan työkokemusta. Vastuualue: Testaus Nimi: Karri Karanko Puhelin: Sähköposti: karkar@iki.fi Mielenkiinnon kohteet ja erikoistaidot: Ohjelmistojen testaus, tietokannat, palvelinalustat, järjestelmäintegraatiot Koulutus ja työkokemus: Tietoliikennetekniikan teekkari, kokemusta työelämässä Data Warehouse -kannoista, replikoinnista ja on-line raportoinnin järjestelmistä. Vastuualue: Ohjelmistoarkkitehtuuri Nimi: Matti Kosunen Puhelin: Sähköposti: mjkosune@cc.hut.fi Mielenkiinnon kohteet ja erikoistaidot: Osaamista seuraavista ohjelmointikielistä: C/C++, Assembler, Java, JavaScript, Pascal, Perl, TCL ja Lisp. Lisäksi HTML ja XML kuvauskielistä laajalti kokemusta. SQL kyselykieli hyvin hallinnassa. Ohjelmointikielien lisäksi hallitsee mm. seuraavat ohjelmointi tekniikat/metodit: Windows api & dll, Microsoft Foundation Classes (MFC), TCP/IP, CGI, OBDC api, DirectX api, 3DSMAX 4 plugins, Java Crypto, Java servlets, Java Server Pages ja Java custom tags. Myöskään UML ei ole täysin vierasta. Koulutus ja työkokemus: Neljännen vuosikurssin teekkari. Työkokemusta ohjelmoinnista vuodesta 2000 lähtien (DP-Group OY, Object Informatics OY) Vuoden 2002 kesällä töihin

5 Accenturelle (ATS) jossa edelleen. Työpaikka sijaitsee tällä hetkellä TeliaSoneralla, jossa tekee SoneraPlaza sivustoa kymmenen muun Accenturelaisen kanssa. Vastuualue: Tietokanta Nimi: Simo Ojanen Puhelin: Sähköposti: Mielenkiinnon kohteet ja erikoistaidot: Ohjelmointi C++ ja Java -kielillä, tietokannat sekä julkaisutekniikat ja käyttöliittymät. Koulutus ja työkokemus: TKK/Tietotekniikka, pääaineena ohjelmistojärjestelmät. Työkokemus: Ohjelmistosuunnittelijana TietoEnator Oyj:llä vuosina 2000 ja 2001 sekä Vilant Systems Oy:llä vuoden 2003 alusta alkaen. 2.2 Muut osallistujat Rooli: Mentor Nimi: Joonas Iivonen Puhelin: Sähköposti: Rooli: Asiakkaan yhdyshenkilö Nimi: Pasi Ranne (hallinnon atk-pääll.) Puhelin: (09-451)4378 Sähköposti: Rooli: ylikirjastonhoitaja Nimi: Ari Muhonen Puhelin: (09-451)4112 Sähköposti: Rooli: toimistosihteeri, kirjanpito- ja maksuliikennepalvelut Nimi: Paula Latvala Puhelin: (09-451)4521 Sähköposti: Rooli: OtaShop1-järjestelmän toteuttaja Nimi: Jaakko Salmela Puhelin: Sähköposti: 3. Tavoitteet ja arviointiperusteet 3.1 Asiakkaan tavoitteet Taulukko 1: Asiakkaan 10 tärkeintä tavoitetta

6 Tavoite Varmennusperuste Kenen tavoite 1. yhteistyö muiden yksiköiden ja toimistojen kanssa 2. opitaan tietojärjestelmän kehitystyötä käytännössä 3. saadaan kokemusta J2EE-toteutusympäristöstä 4. saadaan nykyaikaiset kuvausja dokumentaatiopohjat 5. saadaan lisää projektinjohtotaitoa atk-keskukseen 6. osoittaa, että opiskelijatyönä saadaan hyviä tuloksia 7. Tuottaa järjestelmä, joka toimii Taloustoimiston prosessien kanssa 8. Käytettävyys tilaajan kannalta 9. Käytettävyys julkaisujen toimittajan kannalta 10. Käytettävyys myynnin seurannan kannalta Projektiin osallistuneiden yksiköiden ja toimistojen näkemykset järjestelmästä ovat yhtenevät. Kirjastolle jää projektista dokumentaatio, jossa kuvataan tässä projektissa käytetty ohjelmistokehitysprosessi ja menetelmät. Järjestelmällä on testikäytössä joko atk-keskuksessa tai ulkopuolella ja sille on järjestetty ylläpito. Atk-päällikkö tarkastaa että toimitettuja dokumentteja voidaan käyttää pohjana myös tulevissa projekteissa Projektipäällikkö on tulevaisuudessa valmis ohjaamaan muita vastaavia projekteja atk-keskuksessa. Kirjasto tarkastaa, että valmis järjestelmä toimii riittävän hyvin. Taloustoimisto tarkastaa, että järjestelmässä on toteutettuna määritetyt liitännät olemassa oleviin järjestelmiin. Järjestelmää tuntemattoman käyttäjän pitää pystyä tilaaman ja maksamaan tietty julkaisu alle 5 minuutissa. Julkaisun toimittajan pitää pystyä tulostamaan 5 viimeisen tilauksen toimitustiedot alle 5 minuutissa. Laboratorion pitää pystyä listaamaan määrittelemänään aikavälinä myytyjen julkaisuiden nimet ja lukumäärät. Kirjasto Kirjasto Pasi Ranne,atk-keskus Pasi Ranne, atk-keskus Pasi Ranne, atk-keskus kirjasto, Pasi Ranne Taloustoimisto Kirjasto Pilottivaiheen laboratoriot Pilottivaiheen laboratoriot 3.2 Projektiryhmän tavoite Taulukko 2: Projektiryhmän tavoitteet Projektiryhmän tavoitteet 1. Tuottaa sovitulla työmäärällä ( h) ohjelmisto, joka täyttää vaatimusmäärittelydokumentissa sille asetetut vaatimukset, ja on asiakkaalle hyödyllinen ja käyttökelpoinen. 2. Tuottaa sellaiset dokumentit, joita asiakas voi käyttää mallina myöhemmissä projekteissaan. 3. Suorittaa kurssi hyvällä arvosanalla. (Arvosana 4 tai 5)

7 Taulukko 3: Henkilökohtaiset oppimistavoitteet Jäsen Erkka Halme Anna Larmo Antti Kärkkäinen Kai Inkinen Karri Karanko Matti Kosunen Simo Ojanen Henkilökohtaiset oppimistavoitteet - Projektinhallintataitojen oppiminen - Ohjelmistoprojektin kokonaisuuden ymmärtäminen - Asiantuntijoiden johtamisen oppiminen - Toimiminen projektin osana ja projektiryhmän osana - Uusien työkalujen ja -käytäntöjen oppiminen - Oman ajankäytön arvioinnin oppiminen - Henkilökohtaisen tehtävän (Usability tests) soveltaminen käytännössä - Toimiminen oikeaoppisessa ja kiireettömässä projektissa - Uusien ratkaisujen löytäminen perinteisiin ohjelmistoprojektien ongelmiin - Uusien työkalujen kokeileminen kehitystyössä - Toimiminen isomassa ryhmässä ja projektissa - Tietoturvan soveltaminen ohjelmistoprojekteissa - Oppia projektin dokumentoinnista ja sen tehostamisesta (Documentation practices) - Toimiminen yli 3-henkisen kehitysryhmän jäsenenä - Oman ajankäytön ymmärtäminen ja kehittäminen - Järjestelmäintegraatiot ja niissä käytettävät toteutusmenetelmät - Testausautomaatioon tutustuminen ja sen soveltaminen käytännössä - Henkilökohtaisen työtavan (Design patterns) oppiminen ja sen käyttö tehokkaasti ohjelmistoprojekteissa. - Laadukkaan ohjelman tuottaminen annetusta aiheesta ja annetussa ajassa. - Toimiminen isommassa ryhmässä - Lisäkokemuksen saaminen tietokannan ylläpidosta - Toimiminen oppikirjojen mukaan toteutetussa projektissa 3.3 Perusteet projektin keskeyttämiselle Projekti keskeytetään, jos jokin seuraavista tapahtuu: Kolme tai useampi ryhmän jäsen lähtee ryhmästä Jokin projektin vaiheista on mennyt niin huonosti, että kurssin läpäiseminen ei ole enää mahdollista Kurssihenkilökunta määrää projektin lopetettavaksi Ensimmäisen keskeyttämisehdon mukaan projekti keskeytetään jos kolme tai useampi ryhmän jäsen niin haluaa. Jos joku ryhmän jäsenistä haluaa keskeyttää projektin, tulee hänen ilmoittaa siitä projektipäällikölle, asiakkaalle, mentorille ja muille ryhmän jäsenille. Jos kolma tai useampi jäsen haluaa keskeyttää projektin, ilmoittaa projektipäällikkö projektin keskeyttämisestä asiakkaalle, mentorille ja muille ryhmän jäsenille.

8 3.4 Perusteet projektin lopettamiselle Projekti lopetetaan kurssin päättyessä, eli kun kaikki kurssin asettamat vaatimukset on täytetty. 4. Resurssit ja kustannusarvio 4.1 Henkilöstö Taulukko 4: Suunniteltu(S) ja toteutunut(t) työmäärä Erkka Anna Antti Kai Karri Matti Simo Yhteensä S T S T S T S T S T S T S T S T PP I I2 40 xx 50 xx 66 xx 61 xx 59 xx 60 xx 63 xx 399 xx I3 35 xx 48 xx 47 xx 43 xx 46 xx 43 xx 43 xx 307 xx DE 25 xx 25 xx 17 xx 17 xx 17 xx 17 xx 17 xx 135 xx Yhteensä 190 xx 190 xx 190 xx 190 xx 190 xx 190 xx 190 xx 1330 xx Tarkempi suunnitelma työmääristä on kappaleessa Materiaalit Laitteistot Palvelinkone kehitysympäristöksi: Asiakas lainaa ryhmän käyttöön riittävän tehokkaan tietokoneen. Kone sijoitetaan projektin ajaksi Teekkarikylään kyläverkkoon Antti Kärkkäisen kotiin. Työasemat: Ryhmän jäsenet käyttävät joko omia tai koulun tarjoamia työasemia. Palvelimen tekniset tiedot: Emolevy: Asustek P2B-DS Muisti: 1024MB Prosessori: 2 kpl PIII 450Mhz Ohjelmistot Tietokanta: Asiakas antaa ryhmän käyttöön Oracle9i -tietokantaohjelmiston Standard-lisenssillä. Sovelluspalvelin: Kehitystyössä käytetään Tomcat -sovelluspalvelinta (OpenSource) WWW-palvelin: Kehitystyössä käytetään Apache www-palvelinta (OpenSource) Muut ohjelmistot: Projektissa käytetään tarvittaessa muita OpenSource-ohjelmistoja tai koulun tarjoamia ohjelmistoja

9 Muut resurssit Neuvotteluhuone: Asiakas järjestää asiakkaan ja ryhmän yhteisiin palavereihin tarvittaessa neuvotteluhuoneen ja videotykin. 4.3 Menoarvio Projekti ei aiheuta asiakkaalle mitään hankintakuluja, koska tarvittavat ohjelmistot ja laitteistot ovat jo olemassa. Asiakkaalle aiheutuu projektista työtä maksimissaan keskimäärin kaksi tuntia viikossa, eli yhteensä noin 50 tuntia. Sekä asiakkaan että ryhmän työpanokselle on alla olevaan taulukkoon laskettu arvo käyttäen 50 euron tuntihintaa. Suorittaja Tunnit Summa (e) Asiakas Ryhmä YHTEENSÄ Työtavat ja työkalut 5.1 Työtavat Projektin aikana käytetään seuraavissa kappaleissa lueteltuja työtapoja ja -menetelmiä. Kukin ryhmän jäsen tutkii lisäksi tarkemmin yhden menetelmän käyttöä Iteratiivinen kehitys ja suunnittelu Projektissa käytetään kevyttä sekä modernia iteratiivista kehitysmallia. Iteratiivisessa mallissa projekti jaksotetaan useampaan vaiheeseen. Tämä projekti toteutetaan viidessä; vaiheessa jotka ovat suunnittelu, toteutus 1, 2 ja 3 sekä jakelu. Näistä vaiheista kolme keskimmäistä toteutusvaihetta tulevat pitämään sisällään pääpiirteittäin kaikki vesiputousmallin vaiheet (1. Ongelman ja vaatimusten analysointi, 2. Ohjelmiston suunnittelu, 3. Toteutus, 4. Testaus, 5. Käyttöönotto, 6. Huoltotoimet) Iteratiivisessa mallissa lähdetään siitä mitä asiakas pitää järjestelmän tärkeimpinä ominaisuuksina. Osat ja toiminnot, jotka asiakas kokee tärkeiksi, toteutetaan ensimmäisen iteraation aikana. Näin asiakas saa osittain toimivan järjestelmän jo tuotekehityksen alkuvaiheessa. Samalla myös asiakkaalle tärkeät komponentit saavat osakseen enemmän testausta, sillä näitä osia testataan jokaisen vaiheen testausjaksossa. Käytännössä tämä tarkoittaa sitä, että jokaisessa vaiheessa tulee olla selkeät tavoitteet ja kriteerit, ja prosessin jokainen vaihe dokumentoida kunnolla, jotta prosessia voidaan jälkikäteen arvioida. Jokainen vaihe suunnitellaan etukäteen, niin että viimeistään edellisen vaiheen päättyessä on seuraava vaihe suunniteltuna.

10 5.1.2 Riskienhallinta Projektin onnistumista uhkaavia riskejä seurataan säännöllisesti kirjaamalla riskitapahtumat, vaikutukset ja ehkäisevät toimenpiteet. Ajantasainen taulukko havaituista riskeistä on erillisessä riskienhallintadokumentissa, ja riskienhallinnan menettelytavoista kerrotaan lisää tämän dokumentin kappaleessa Tunti- ja muu raportointi, projektinhallinta OtaShop2-projektissa käytetään kurssin tuntiraportointijärjestelmää, Trapoli:a. Jokainen ryhmän jäsen raportoi tuntinsa järjestelmään vähintään muutaman kerran viikossa. Lyhyt raportointiväli antaa projektipäällikölle, sekä kurssin henkilökunnalle mahdollisuuden seurata projektin etenemistä. Trapoli toimii myös apuna projektin suunnittelussa. Jokaisen vaiheen lopussa tulee suunnitella seuraava vaihe. Suunnitelman tuntiarviot ja yksityiskohdat annetaan Trapoliin, jossa ne myös toimivat arviointikriteereinä, kun kyseisen vaiheen lopussa tarkastellaan vaiheen onnistumista. Pidetyistä kokouksista tehdään lyhyt muistiot, joka sitten talletetaan projektin versionhallintatyökaluun. Tällä tavalla on myös helppo jälkikäteen tarkastaa ketkä ovat kokouksiin osallistuneet, mitä niissä on päätetty ja mistä syystä. Projektin etenemisen seurannassa käytetään kahta toisiaan täydentävää menetelmää, tuntikirjanpitoa ja jäljellä olevan työmäärän arviointia. Tuntikirjanpitoon ja työmäärän arviointiin käytetään Trapoli-järjestelmää. Työmääräarvioiden perusteella piirretään säännöllisesti ns. burndown-kaavioita, joiden avulla voi helposti tarkkailla projektin kunkin vaiheen etenemistä. Mikäli arvioidun työmäärän perusteella vaikuttaa siltä, että kaikkia suunniteltuja tehtäviä ei tietyssä vaiheessa ehditä tekemään, voidaan jokin alhaisemman prioriteetin tehtävä jättää tekemättä Vikojen hallinta Ohjelmatyö-kurssi tarjoaa projektien bugien ja vikojen hallintaan Bugzilla-työkalua. Työkalu on laajalti käytössä eri avoimen lähdekoodin sekä kaupallisissa projekteissa kautta maailman. Muun muassa Mozilla-, Linux kernel-, Apache- sekä Gnome- ja KDE-projektit käyttävät Bugzillaa vikojenhallintaan. Koska Bugzilla on osoittautunut toimivaksi järjestelmäksi näinkin isoissa projekteissa, päätimme että käytämme kurssin tarjoamaa järjestelmää omassa projektissamme Dokumentointi ja dokumenttien jakelu Tuotettavat ja jaettavat dokumentit on lueteltu kappaleessa 6. Projektin aikana dokumenttien avulla pyritään kommunikoimaan sekä ryhmän sisällä että asiakkaan suuntaan. Dokumentit toimivat myös pöytäkirjana siitä miksi jotain päätöksiä on tehty tietyllä tavalla. Kurssin puolesta on jo tarjottu dokumenttipohjat joita käytetään pääosaan dokumentoinnista. Jotta dokumentointi pysyisi yhdenmukaisena läpi koko projektin, tullaan tekemään nk. dokumenttien formaalia tarkastamista. Tämä tarkoittaa että ennen kuin lopulliset dokumentit palautetaan asiakkaalle tai kurssin henkilökunnalle, niin ne tarkastetaan ryhmän sisällä. Tarkastaminen on jaettu seuraaviin pääasiallisiin vaiheisiin: 1. Sovitaan ryhmä joka tarkastuksen suorittaa 2. Sovitaan tarkastettava dokumentti, sekä päivämäärä jolloin tarkastaminen tapahtuu 3. Jokainen ryhmän jäsen lukee dokumentin läpi ja tekee merkintöjä

11 4. Kokous, dokumentti luetaan ääneen 5. Keskeytetään lukeminen mikäli virheitä on löydetty. Todetaan virheet ja epäselvyydet jonka jälkeen joko a) Dokumentti korjataan b) Palautetaan virhe korjattavaksi kirjoittajalle 6. Tarkastuskokous, jossa korjaukset tarkastetaan. Kokous voidaan pitää lyhyempänä versiona Kokouksen pyritään pitämään lyhyenä, alle tunnin mittaisena, jolloin tehokkuus säilyy. Ryhmän koostumus on kiinni siitä, miten iso tarkastettava dokumentti on ja siitä onko dokumenttia ennen luettu läpi. Pyrkimys olisi että ryhmä olisi suhteellisen pieni, neljä tai viisi jäsentä. Puheenjohtaja lukee dokumenttia ääneen ja kirjanpitäjä kirjaa ehdotukset sekä muutokset. Dokumentin kirjoittajan olisi myös hyvä olla paikalla, sillä hän voi selventää jos jotain jää epäselväksi, sekä kertoa miksi tiettyjä päätöksiä dokumenttien sisällöstä on tehty. Tarkoitus olisi siis että jokainen dokumentti tarkastettaisiin kerran ennen palauttamista. Mikäli dokumentti on pitkä tai monimutkainen se voidaan jakaa osiin. Osaan dokumenteista ei ole annettu valmiita pohjia, joten näiden suhteen on enemmän vapauksia. Tulemme pyrkimään siihen että ainakin ohjelmiston manuaali olisi tehty tekniikalla joka mahdollistaa sekä verkossa katsomisen että tulostamisen, siten että ulkoasu säilyy haluttuna. Sopiva tekniikka on XML, joka mahdollistaa tällaisen Projektin katselmointitilaisuudet Jokaisen vaiheen lopussa pidetään katselmointitilaisuus, jossa projektin eteneminen raportoidaan sekä asiakkaalle että kurssihenkilökunnalle Vaatimusten priorisointi OtaShop2-järjestelmän ominaisuudet pyritään priorisoimaan, ja toteuttamaan tärkeimmät ominaisuudet ensin Vaatimusten hallinta Asiakkaan kanssa määritellyt järjestelmän vaatimukset kirjataan vaatimusmäärittelydokumenttiin [3], ja kunkin vaatimuksen toteutumista seurataan jokaisessa vaiheessa. Jos vaatimuksiin tehdään muutoksia, on muutokset hyväksytettävä asiakkaalla Käyttötapaukset Käyttötapauksia käytetään vaatimusten määrittelyn apuna. Jotta vaatimusten hahmottaminen on helpompaa, on käyttötapaukset kuvattu tässä vaiheessa melko korkealla tasolla. Järjestelmän muut toiminnalliset vaatimukset kirjataan erikseen Versionhallinta Versionhallinnan tavoitteena on hallita dokumentteja ja ennen kaikkea lähdekoodia, siten että koodi pysyy luettavan ja toimivana. Tästä syystä kaikki tuottamamme materiaali, kokousmuistioista lähdekoodin asti tullaan tallettamaan CVS-puuhun. Versionhallintatyökalu jota käytämme on avoimen lähdekoodin CVS, joka tulee lähdes jokaisen Linux-distribuution mukana. CVS-puu sijaitsee kehitys-palvelimella ja siihen on pääsy vain ryhmän jäsenillä

12 Versionhallinta on tehokas työkalu, mikäli kaikki käyttävät sitä sovitulla tavalla. Muutoksia tehdessä on muutokset lisättävä CVS-puuhun parin tunnin välein. Näin vältetäänn mahdolliset epäjohdonmukaisuudet, jotka saattavat tulla mikäli useampi henkilö tekee muutoksia samaan tiedostoon samanaikaisesti. Tämä parin tunnin väli pätee kaikkiin tiedostoihin, mutta siitä tullaan pitämään huolta varsinkin dokumentteja kirjoitettaessa. Kun itse toteutus alkaa on tarkkojen rajojen antaminen hieman vaikeampaa, sillä versionhallinnassa pitäisi aina olla käännettävä versio koodista. Täten rajoja joudutaan ehkä hieman joustamaan Ohjelmointityyli ja koodin kommentointi OtaShop2-verkkokauppa tullaan toteuttamaan Java Enterprise Editionia-käyttäen, JSP-sivuina. Sun on antanut suositukset miten Java-koodia tulee kommentoida. Useammilla koulun kursseilla on tätä tapaa suosittu sekä opetettu. Olemme päättäneet käyttää näitä suosituksia koodin kommentoinnissa. Jotta kaikki koodi saataisiin näyttämään yhdenmukaiselta saatamme käyttää jotain tarkoitukseen tehtyä työkalua. Suuremman ongelman muodostaa dokumentit jotka kirjoitetaan HTML-koodina. HTML on avoin standardi, jota eri selainten valmistajat ovat laajentaneet lähes mielensä mukaan. Tästä johtuen sivut saattavat näyttää ja käyttäytyä eri tavalla riippuen siitä mitä selainta käytetään niitä katsottaessa. Näistä epämääräisyyksistä johtuen olemme päättäneet että kirjoitamme HTML-standardin mukaista koodia. Tällä pyritään saamaan dokumentaatio näkymään yhdenmukaisena kaikilla laitealustoilla. Tarpeen vaatiessa saatamme käyttää jotain HTML-koodille tehtyä "Beautifier"-työkalua Testaus Testaussuunnitelman ensimmäinen kattava version tehdään toteuttamisvaihe 1:n aikana. Yleisellä tasolla voidaan eritellä seuraavat testauksen osa-alueet: -Yksikkötestaus, jossa järjestelmän kehittäjät tekevät testiskriptit jokaista toteutettavaa moduulia varten. Käytännössä yksikkötestausta tehdään koko kehityskaaren ajan. Erityisen paljon hyötyä tehdyistä yksikkötesteistä on silloin, kun joudutaan muokkaamaan ylläpitovaiheessa olevaa järjestelmää. Tällöin voidaan ajaa yksikkötestit uudelleen ja todeta miten tehty muutos vaikuttaa muuhun ympäröivään järjestelmään. -Integraatiotestaus, jossa järjestelmän eri osion yhteensopivuus pyritään varmistamaan. Tämä vaihe on ajankohtainen koko projektin ajan. Integraatiotestauksen piiriin kuuluvat myös yhteydet ydinjärjestelmän ulkopuolisiin komponentteihin ja tietovarastoihin. -Käyttöliittymätestaus, jossa on tarkoituksena selvittää mm. liittymän toimivuus ja käytettävyys. Käytettävyyden tutkimiseen tullaan käyttämään myös tuotteen kohderyhmään kuuluvia projektin ulkopuolisia henkilöitä. Käytännössä käyttöliittymän testaus voidaan aloittaa siinä vaiheessa, kun sopivia osakokonaisuuksia on valmiina. -Järjestelmätestaus, jossa tarkoituksena on selvittää vastaako järjestelmä sille asetettuja toiminnallisia vaatimuksia ja voidaanko kaikki käyttötapaukset suorittaa. Käytännössä kattava järjestelmätestaus voidaan tehdä vasta siinä vaiheessa, kun vallitsevan käsityksen mukaan järjestelmä voi yleensä täyttää annetut kriteerit eli viimeistään Toteuttamisvaihe 3:ssa. -Hyväksyntätestaus, jossa asiakas saa testattavakseen valmiin kokonaisuuden. Käytännössä asiakas on jo aikaisemmin voinut tutustua ja kommentoida tiettyjä järjestelmän osia. Hyväksyntään tähtäävän testauksen asiakas suorittaa projektin Toimitusvaiheessa.

13 Projektin toisessa ja kolmannessa toteutusvaiheessa on tarkoitus käyttää automaatiota järjestelmätestauksen tukemiseen. Kun automaatti tietyn asian testaamiseksi on tehty, voidaan sitä suorittaa toistuvasti pienellä vaivalla ja jopa erilaisten ketjujen osana. Nämä ketjut ovat käytännössä tapahtumapolkuja, joita käyttäjän on voitava suorittaa sovelluksessa ilman poikkeustilanteita. Automaation toteuttamisessa käytetään apuna valmiita testaussovelluksia. Projektin puitteissa otetaan selvää erilaisista tarjolla olevista vapaista ja kaupallisista sovelluksista. Käytännössä vaihtoehdot tulevat olemaan osaltaan graafisia sovelluksia tai pelkästään API:ja, joilla voidaan tehdään testausskriptejä manuaalisesti. Automaattista järjestelmätestausta voidaan, toimivuutta tulkitsevien testien lisäksi, käyttää myös sovellusten skaalautuvuuden tutkimiseen. Riittävillä rasitustesteillä voidaan paikallistaa sovelluksen toteutuksen pullonkaulat ja reagoida niihin ennen, kuin järjestelmä siirtyy tuotantoon. Käytettävyysarvioinnit tehdään iteratiivisesti. Ensimmäiset testit pyritään tekemään toisessa implementaatiovaiheessa ja loput testit kolmannessa implementaatiovaiheessa. Käytettävyysarvioinnissa käytetään vähintään kahta tarkkailijaa ja vähintään kolmea koehenkilöä [1]. Käytettävyystestin koehenkilöiksi pyritään saamaan ihmisiä, jotka toimivat sellaisissa työtehtävissä, joissa palvelua tultaisiin todennäköisimmin käyttämään. Testitilaisuudet pyritään mahdollisuuksien mukaan järjestämään testaajan normaalissa työtilassa, jotta testitilanteesta saadaan mahdollisimman aito. Otashop-verkkokauppa tulee käsittämään useamman kuin yhden käyttöliittymän. Tässä käyttöliittymällä tarkoitetaan yhden toiminnon tekemiseen tarkoitettua näkymää. Verkkokaupassa tulee olemaan ainakin näkymä verkkokaupan asiakkaalle ja erillinen näkymä järjestelmää käyttäville laboratoriolle. Käytettävyysarvioinnit suoritetaan vain joillekin näkymille Vertaistestaus Toteutusvaihe 3:n aikana järjestelmä annetaan toisen projektiryhmän testattavaksi Suunnittelumallit Verkkokaupan suunnittelussa sekä toteutuksessa käytetään yleisesti hyväksi havaittuja ohjelmiston suunnittelumalleja. Nämä parantavat oikein käytettynä ohjelman laatua tekemällä siitä helpommin laajennettavan sekä vähemmän virhealttiin. Projektin ensimmäisessä vaiheessa käytetään erinäisiä suunnittelumalleja kun suunnittelemme luokkakaavioita sekä mietimme ohjelman rakennetta ja toimintaa. Toisessa vaiheessa ja siitä eteenpäin viimeiseen ohjelmointikierrokseen asti pidämme huolen että ohjelmassa käytetään suunniteltuja malleja, ellei jokin painava syy tee mallien käytöstä mahdotonta. Toteuttamisvaiheissa on tarpeellista, että käymme ohjelmointiin osallistuvien kanssa ohjelman rakenteen sekä syyt näihin ratkaisuihin tarkoin läpi, että jokainen osaa tämän jälkeen toteuttaa heille annetun osan suunnitellulla tavalla. Jälkeenpäin mallien lisääminen järjestelmään on melkein mahdotonta. Verkkokaupassa käytämme seuraavia suunnittelumalleja. Factory method Factory method suunnittelumalli kuuluu objekteja luoviin malleihin. Mallia käytetään luomalla rajapinta joka delegoi uusien luokkien luomisen tämän alaluokille. Alaluokka saa

14 vapauden instantioida minkä luokan se haluaa kunhan instantioitu luokka toteuttaa vaaditun rajapinnan. Näin saamme luokkien luomisen toiminnallisuuden kasattua pienelle osalle ohjelmaa ja näin saamme ohjelmasta helpommin hallittavan, kun eri osia ei ole ripoteltu ympäri ohjelman koodia. Builder Builder suunnittelumalli kuuluu myös objekteja luoviin malleihin. Sitä käytetään erottelemaan objektin rakenne sen datasta. Se mahdollistaa datan käsittelyn siten että myös samasta informaatiosta voidaan muodostaa erilaisia presentaatioita. Yleensä ohjelmat luodaan siten että dataa käyttävä luokka käsittelee sitä suoraan. Builder mallissa luokka käyttää sille annettua apuluokkaa (builder) joka muodostaa ensin annetusta datas jonkin yleisen muodon jota luokka voi sitten käyttää. Näin datan muodon muuttuessa meidän tarvitsee vain päivittää builder luokkaa. Template method Template method kuuluu toiminnallisiin malleihin. Tämä malli on edellä esitellyistä malleista yleisesti yksi kaikkein eniten käytetyistä. Mallissa tehdään halutusta toiminnallisuudesta tai algoritmista yleinen struktuuri luokaksi. Tämän jälkeen uudet luokat periytetään tästä luokasta. Perityt luokat täydentävät määritellyn rajapinnan ja lisäävät/korvaavat osan toteutettavan algoritmin toiminnallisuudesta. Näin saadaan algoritmien toiminnallisuus piilotettua luokkaa käytettäessä yhteisen rajapinnan taakse sekä algoritmin käyttö onnistuu yleisen rajapinnan kautta. Samalla pystytään välttämään tiettyjen algoritmin osien uudelleenkirjoittamista ja näin saadaan koodia helposti myös uudelleenkäytettyä Refaktorointi Refaktorointimenetelmää on tarkoitus käyttää kaikissa projektin implementaatiovaiheissa koodin laadun parantamiseksi. Refaktorointi tarkoittaa lähdekoodin yleistä muokkaamista paremmaksi muuttamatta itse toiminnallisuutta, ja sen avulla koodista saadaan paremmin luettavaa, muokattavaa ja uudelleen käytettävää. Käytännössä refaktorointi koodin rakenteen muuttamista järkevämpään muotoon. Koska OtaShop2 verkkokauppaprojektissa syntyvää koodia tulee luultavasti olemaan melko vähän, ja ohjelmiston suunnittelu tehdään tarkasti, pysyy tarvittavan refaktoroinnin määrä melko alhaisena. Projektissa on kuitenkin tarkoitus käyttää refaktorointia säännöllisesti ja kontrolloidusti jokaisessa implementaatiovaiheessa. Jokainen ohjelmoija käy vähintään kerran viikossa kaiken kirjoittamansa koodin läpi, kirjaa havaitsemansa muutostarpeet ja toteuttaa muutokset. Myös varsinaisen ohjelmoinnin aikana tapahtuva, suunnittelematon refaktorointi kirjataan ylös. Jokaisen vaiheen lopussa jokainen ohjelmoija lukee läpi jonkun toisen ohjelmijan tuottaman koodin, ja merkitsee ylös havaitsemansa refaktorointitarpeet. 5.2 Henkilökohtaiset ohjelmistotuotannon tehtävät Seuraavissa taulukossa on kerrottu kunkin ryhmän jäsenen henkilökohtaisen ohjelmistotuotannon tehtävän aihe. Table 5: Henkilökohtaiset ohjelmistotuotannon tehtävät

15 Käytäntö Vastuussa oleva jäsen Käyttö Projektin etenemisen seuranta ja hallinta Erkka Halme PP-DE Käytettävyystestit Anna Larmo I2-I3 Konfiguraation hallinta Antti Kärkkäinen PP-DE Dokumentointikäytännöt Kai Inkinen PP-DE Automaatio järjestelmätestauksessa Karri Karanko I2-I3 Suunnittelumallit Matti Kosunen PP-I3 Refaktorointi Simo Ojanen I1-I3 Henkilökohtaiset harjoitukset esitellään ja raportoidaan tarkemmin erillisissä dokumenteissa. 5.3 Työkalut Projektissa käytettävät työkalut on lueteltu alla: Eclipse - Ohjelmointiympäristö jedit - Java-ohjelmointiin tehty editori Microsoft Visio - Kaavioiden piirtämiseen html2ps ja ps2pdf - Dokumenttien muuntamiseksi pdf-muotoon( CVS - versionhallintaan( junit - yksikkötestaamiseen( httpunit - järjestelmätestaamiseen( Maven - käännöstyökalu( 5.4 Standardit Järjestelmän ulkoasu on pyrittävä tekemään TKK:n graafisen ohjeiston mukaan. Järjestelmän tietoturvan suunnittelussa on otettava huomioon TKK:n atk-keskuksen tietoturvaevaluointipohja. Graafinen ohjeisto on saatavissa TKK:n Viestinnästä. Tietoturvaevaluointipohja löytyy osoitteesta 6. Projektin vaiheet Projekti toteutetaan viidessä vaiheessa, joista kolmen keskimmäisen aikana tehdään varsinaista järjestelmän toteutustyötä. Tässä kappaleessa esitellään vaiheistuksen aikataulu ja kunkin vaiheen sisältö pääpiirteittäin. Myöhempien vaiheiden suunnitelmia tarkennetaan siten, että kunkin vaiheen lopussa on seuraavan vaiheen tarkemmat suunnitelmat tehty.

16 6.1 Aikataulu Päivämäärä Vaihe (~4 vko) PROJEKTIN SUUNNITTELU (5 vko) TOTEUTUS (10 vko) TOTEUTUS (5 vko) TOTEUTUS (3 vko) JAKELU 6.2 Projektin suunnittelu Tavoitteet: saada kokonaiskuva tavoiteltavasta järjestelmästä sopia ja opetella ryhmän käyttämät työtavat määritellä vaatimukset niin, että vähintään järjestelmän perustoiminnot on määritelty suunnitella projektin aikataulu ja vaiheet yleisellä tasolla Toimitettavat dokumentit: projektisuunnitelma vaatimusmäärittelydokumentti edistymisraportti (kalvosarja) Tehtävät: (Trapolista)

17 name effort responsible start_date finish_date DS:Ohjelmistoarkkitehtuurin suunnittelu 15 mjkosune DS:Testausmenetelmien opiskelu 10 kkaranko DS:Tietoturvaan tutustuminen ja suunnittelu 10 kinkinen DS:Vaatimusmäärittely 27 ALL DS:Vaatimusten dokumentointi 15 ALL GE:Dokumenttipohjien luonti ja www-sivusto 10 alarmo GE:Kehitysymp. pystytys ja ylläpito 15 akarkkai GE:Luennot 10 ALL GE:Tapaamiset (ryhmä/mentor) 15 ALL GE:Tietokannan asennus ja testaus 15 siojanen PM:ANNA:henk.koht. harj 7 alarmo PM:ANTTI:henk.koht. harj 7 akarkkai PM:Edistymisraportin kirj. 6 ALL PM:ERKKA:henk.koht. harj 7 eshalme PM:KAI:henk.koht. harj 7 kinkinen PM:KARRI:henk.koht. harj 7 kkaranko PM:MATTI:henk.koht. harj 7 mjkosune PM:Projektin katsaus ja valmistaut. 8 ALL PM:Projektin tavoitteiden määrittely 20 ALL PM:Projektisuun. kirj. 15 ALL PM:Riskienhallinta 8 ALL PM:Sekal. proj.hallinta 12 eshalme PM:Seuraavan vaiheen suunn. 10 ALL PM:SIMO:henk.koht. harj. 7 siojanen PM:Työtapojen suunnittelu 15 ALL Toteuttamisvaihe 1 Tavoitteet:

18 Järjestelmän arkkitehtuurin suunnittelu vähintään toteutettavin toimintojen osalta Järjestelmän perusrungon toteuttaminen WWW-asiakkaille näkyvien toimintojen toteuttaminen (käyttötapaukset 1-3) Testausmenetelmien käyttöönotto Toimitettavat osat: Toteutettavat järjestelmän osat: Use Case 1 (tilaus) Use Case 2 (selaus) Use Case 3 (ostoskori) Järjestelmän kokonaisuudessaan sellaisessa kunnossa, että asiakas voi kokeilla käyttötapauksia Dokumentit: päivitetty projektisuunnitelma päivitetty vaatimusmäärittelydokumentti tekninen dokumentti testitapausten määrittelyt testiraportti edistymisraportti (kalvosarja) Tehtävät: name effort responsible start_date finish_date DS: Kirj. ulkoasudokumentti 5 alarmo DS: Tietoturva-vaatimuksien selvittäminen 10 ALL DS:Arkkitehtuurin suunn. 15 mjkosune DS:Kirjoita tekn. dokum. 17 ALL DS:Päivitä proj.suunn. 5 eshalme DS:Päivitä vaat. määr. dok. 10 ALL GE: Dokumenttien tarkastelu (Kain harj.) 12 ALL GE: Käännösympäristön luominen 10 akarkkai GE: Kehitysymp. ylläpito 5 akarkkai GE:Muut tehtävät 5 ALL GE:Tapaamiset (ryhmä/mentor) 25 ALL IM: Sivukehyksen luominen 8 alarmo IM: Tuotetietokannan suun ja tot. 8 siojanen IM:Tot. arkkitehtuuri (CART) 5 ALL

19 IM:Tot. arkkitehtuuri (DAO) 20 ALL IM:Tot. arkkitehtuuri (ORDER) 10 ALL IM:Tot. arkkitehtuuri (PAYMENT) 10 ALL IM:Use Case 1 (tilaus) 8 ALL IM:Use Case 2 (selaus) 10 ALL IM:Use Case 3 (ostoskori) 10 ALL IPM: SIMO henk.koht har 7 siojanen PM:ANNA henk.koht har 7 alarmo PM:ANTTI henk.koht har 5 akarkkai PM:ERKKA henk.koht har 2 eshalme PM:KAI henk.koht har 2 kinkinen PM:KARRI henk.koht har 7 kkaranko PM:Kirjoita edistymisraportti 5 eshalme PM:MATTI henk.koht har 2 mjkosune PM:review ja valmistautuminen 10 ALL PM:Suun. seur. vaihe 15 ALL PM:Yleinen proj.hallinta 10 eshalme TE:Toteuta ja raportoi testaus 15 ALL TE:Valmistele testaus 10 kkaranko Toteuttamisvaihe 2 Tavoitteet: Järjestelmän arkkitehtuurin suunnittelu ja toteutus valmiiksi Käyttötapausten toteuttaminen siten että kaikki toiminnallisuus on testattavissa Käyttöliittymätestauksen tekeminen Palautteen saaminen loppukäyttäjiltä Toimitettavat osat: Toteutettavat järjestelmän osat: Use Case 4 (maksujen tilitys) Use Case 5 (tilausten hallinta) Use Case 6 (ongelmatapauksen selvitys) Use Case 7 (kannan päivityksen pakotus) Use Case 8 (raportit)

20 Use Case 9 (käyttäjätunnusten ylläpito) Use Case 10 (kaupan avaaminen ja sulkeminen) Use Case 11 (tuoteluettelon automaattinen päivitys) Dokumentit: päivitetty projektisuunnitelma päivitetty vaatimusmäärittelydokumentti päivitetty tekninen dokumentti päivitetyt testitapausten määrittelyt testiraportti käyttöohje edistymisraportti (kalvosarja) Tehtävät: Tehtävät ja niiden sijoittelu kalenteriin erillisessä dokumentissa. Tavoitteiden priorisointi Toteutettavista osista käyttötapaukset 7,8 ja 10 tehdään lopuksi jos aikaa riittää. Riskit ja epävarmuustekijät Tällä hetkellä suurimmat riskit liittyvät käyttöönoton suunnitteluun, koska ei tiedetä kenen ylläpitoon järjestelmä tulee ja mitä teknisiä vaatimuksia tämä asettaa. 6.5 Toteuttamisvaihe 3 Tavoitteet: Tarvittavien raporttien toteuttaminen (käyttötapaus 8) Käyttäjien ehdottamien korjausten/lisäysten tekeminen Toimitettavat osat: Toimitettavat järjestelmän osat... Dokumentit: päivitetty projektisuunnitelma päivitetty vaatimusmäärittelydokumentti päivitetty tekninen dokumentti päivitetyt testitapausten määrittelyt päivitetty käyttöohje vertaistestaussuunnitelma vertaistestausraportti testiraportti edistymisraportti (kalvosarja)

21 6.6 Jakelu Tavoitteet:... Toimitettavat osat: Dokumentit: loppuraportti ajantasaiset versiot kaikista projektin dokumenteista 7. Riskienhallintasuunnitelma 7.1 Riskienhallintakäytännöt OtaShop2 projektin riskienhallinnasta ovat vastuussa kaikki projektiryhmän jäsenet omalla vastuualueellaan. Koko projektia koskevien riskien hallinnasta on erityisesti vastuussa ryhmän projektipäällikkö. Riskien tila dokumentoidaan erillisessä riskienraportointitaulukossa. Jos joku ryhmän jäsen huomaa jonkin aiemmin huomioimatta jääneen riskitekijän, se lisätään riskiluetteloon. Projektipäällikkö tarkastaa riskiluettelon joka toinen viikko. Riskiluettelon tarkistamisessa on projektipäällikön harkinnan mukaan mukana koko ryhmä, päävastuullinen on projektipäällikkö. Jokainen ryhmän jäsen hoitaa lisäksi omalta osaltaan sovitut toimenpiteet riskien toteutumisen minimoimiseksi. Riskienhallinta kattaa koko projektin ja kaikki sen osa-alueet. Lähinnä riskienhallinnassa pyritään kuitenkin ottamaan huomioon sellaiset riskit, jotka koskettavat suoranaisesti ryhmän työtä. Riskienhallinnassa ei oteta huomioon riskejä, joita saattaa tulla esiin järjestelmän jo ollessa asiakkaan käytössä. Riskienhallinnassa ei myöskään paneuduta tarkemmin käyttöönottovaiheessa mahdollisesti eteen tuleviin riskeihin. Riskit ryhmitellään taulukossa uhkan todennäköisyyden ja ajankohtaisuuden mukaan kolmeen ryhmään (1=merkittävä riski, 2=saattaa muuttua merkittäväksi,3=ei uhkaa tällä hetkellä). Lähteet [1] [2] Sopimus oikeuksien luovuttamisesta [3] Vaatimusmäärittelydokumentti

22