OtaShop2 T-76.115 Versio Päivämäärä Tekijä Kuvaus 4.3 15.3.2004 P. Ranne & Halme Muutokset hyväksytty 4.2 15.3.2004 Halme Muutoksia kappaleeseen 4.1 ja 6.6 4.1 12.3.2004 Halme Muutoksia kappaleeseen 6.6 4.0 10.2.2004 Halme Muutoksia kappaleeseen 4.3 3.0 5.2.2004 Halme Muutoksia kappaleisiin 4.1, 5.3 ja 6.5 2.1 1.12.2003 P. Ranne & Halme Muutokset hyväksytty 2.03 30.11.2003 Halme Riskitaulukko poistettu, kpl 6 muokattu 2.02 27.11.2003 Halme 1.5, 2.2, 3.2, 4.1, 5.2, 6.4 muokattu 2.01 8.11.2003 Halme Kappaleet 5.1 ja 5.2 yhdistetty, 4.2 ja 5.3 muokattu 2.00 8.11.2003 Halme Muutettu PDF:ksi, Toteutus1-vaihe alkaa 1.7 27.10.2003 Halme Oikoluettu ja korjattu 1.6 27.10.2003 Halme Viimeistelty palautusta varten 1.5 26.10.2003 Ojanen Lisätty tavoitteet, täydennetty refaktorointia 1.4 25.10.2003 Inkinen Lisäsin henk.koht tehtävä, sekä tavoitteet 1.3 25.10.2003 Halme Muokattu kappaletta 6 1.21 23.10.2003 Larmo Lisätty kohta 5.1.X 1.2 19.10.2003 Larmo Riskienhallintasuunnitelma 1.1 18.10.2003 Inkinen Työtavat ja henkilökohtaiset tehtävät 1.01 28.9.2003 Larmo.css tyylimäärittelyt lisätty 1 (25)
1. JOHDANTO... 4 1.1. PROJEKTIN TARKOITUS JA LAAJUUS... 4 1.2. JÄRJESTELMÄ JA KÄYTTÖYMPÄRISTÖ... 4 1.3. OIKEUDET PROJEKTIN TULOKSEEN... 4 1.4. KÄYTETTÄVÄ TERMINOLOGIA... 4 1.5. PROJEKTISUUNNITELMAN MUUTTAMINEN... 5 2. PROJEKTIIN OSALLISTUJAT...5 2.1. PROJEKTIRYHMÄ... 5 2.1.1. Vastuualue: Projektipäällikkö... 5 2.1.2. Vastuualue: Käyttöliittymä, käyttöohjeiden ja koulutuksen suunnittelu... 5 2.1.3. Vastuualue: Kehitysalusta, käyttöönoton ja ylläpidon suunnittelu... 6 2.1.4. Vastuualue: Tietoturva... 6 2.1.5. Vastuualue: Testaus... 6 2.1.6. Vastuualue: Ohjelmistoarkkitehtuuri... 6 2.1.7. Vastuualue: Tietokanta... 7 2.2. MUUT OSALLISTUJAT... 7 2.2.1. Mentor... 7 2.2.2. Asiakkaan yhdyshenkilö... 7 2.2.3. Ylikirjastonhoitaja... 7 2.2.4. Toimistosihteeri, kirjanpito- ja maksuliikennepalvelut... 8 2.2.5. OtaShop1-järjestelmän toteuttaja... 8 3. TAVOITTEET JA ARVIOINTIPERUSTEET... 8 3.1. ASIAKKAAN TAVOITTEET... 8 3.2. PROJEKTIRYHMÄN TAVOITE... 8 3.3. PERUSTEET PROJEKTIN KESKEYTTÄMISELLE... 9 3.4. PERUSTEET PROJEKTIN LOPETTAMISELLE... 9 4. RESURSSIT JA KUSTANNUSARVIO... 9 4.1. HENKILÖSTÖ... 10 4.2. MATERIAALIT... 10 4.2.1. Laitteistot... 10 4.2.2. Ohjelmistot... 10 4.2.3. Muut resurssit... 10 4.3. MENOARVIO... 11 5. TYÖTAVAT JA TYÖKALUT... 11 5.1. TYÖTAVAT... 11 5.1.1. Iteratiivinen kehitys ja suunnittelu... 11 5.1.2. Riskienhallinta... 11 5.1.3. Tunti- ja muu raportointi, projektinhallinta... 11 5.1.4. Vikojen hallinta... 12 5.1.5. Dokumentointi ja dokumenttien jakelu... 12 5.1.6. Projektin katselmointitilaisuudet... 13 5.1.7. Vaatimusten priorisointi...13 5.1.8. Vaatimusten hallinta... 13 5.1.9. Käyttötapaukset... 13 5.1.10. Versionhallinta... 13 5.1.11. Ohjelmointityyli ja koodin kommentointi... 14 5.1.12. Testaus... 14 5.1.13. Vertaistestaus... 15 5.1.14. Suunnittelumallit... 15 5.1.15. Refaktorointi... 16 5.2. HENKILÖKOHTAISET OHJELMISTOTUOTANNON TEHTÄVÄT... 16 5.3. TYÖKALUT... 17 5.4. STANDARDIT... 17 2 (25)
6. PROJEKTIN VAIHEET... 17 6.1. AIKATAULU... 17 6.2. PROJEKTIN SUUNNITTELU... 18 6.3. TOTEUTTAMISVAIHE 1... 18 6.4. TOTEUTTAMISVAIHE 2... 20 6.5. TOTEUTTAMISVAIHE 3... 21 6.6. JAKELU... 23 7. RISKIENHALLINTASUUNNITELMA... 24 7.1. RISKIENHALLINTAKÄYTÄNNÖT... 24 8. LÄHTEET... 25 3 (25)
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-76.115 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. 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 4 (25)
Projektissa ja dokumenteissa käytettävä terminologia määritellään vaatimusmäärittelydokumentin [3] kappaleessa 3.1. 1.5. n 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 http://grapefruit.tky.hut.fi/otashop2. Ryhmään voi ottaa yhteyttä projektipäällikön kautta (erkka.halme@hut.fi). 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 2.1.1. Vastuualue: Projektipäällikkö Nimi: Erkka Halme Puhelin: 040-5322635 Sähköposti: erkka.halme@hut.fi Mielenkiinnon kohteet ja erikoistaidot: Kiinnostunut asiantuntijaorganisaation johtamisesta sekä projektityöskentelyn menetelmistä Koulutus ja työkokemus: 4. vuosikurssin tietotekniikan opiskelija (Ohjelmistotuotanto ja -liiketoiminta), työkokemusta Oracle:n tietokannoista ja J2EE-sovelluksista. 2.1.2. Vastuualue: Käyttöliittymä, käyttöohjeiden ja koulutuksen suunnittelu 5 (25)
Nimi: Anna Larmo Puhelin: 050-3376227 Sähköposti: alarmo@iki.fi 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. 2.1.3. Vastuualue: Kehitysalusta, käyttöönoton ja ylläpidon suunnittelu Nimi: Antti Kärkkäinen Puhelin: 050-5304041 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 2.1.4. Vastuualue: Tietoturva Nimi: Kai Inkinen Puhelin: 050-3426252 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. 2.1.5. Vastuualue: Testaus Nimi: Karri Karanko Puhelin: 040-5713286 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ä. 2.1.6. Vastuualue: Ohjelmistoarkkitehtuuri Nimi: Matti Kosunen Puhelin: 040-5786600 6 (25)
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 Accenturelle (ATS) jossa edelleen. Työpaikka sijaitsee tällä hetkellä TeliaSoneralla, jossa tekee SoneraPlaza sivustoa kymmenen muun Accenturelaisen kanssa. 2.1.7. Vastuualue: Tietokanta Nimi: Simo Ojanen Puhelin:050-5575500 Sähköposti: simo.ojanen@iki.fi 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 2.2.1. Mentor Nimi: Joonas Iivonen Puhelin: 040-760 8550 Sähköposti: jiivonen@cc.hut.fi 2.2.2. Asiakkaan yhdyshenkilö Nimi: Pasi Ranne (hallinnon atk-pääll.) Puhelin: (09-451)4378 Sähköposti: Pasi.Ranne@hut.fi 2.2.3. Ylikirjastonhoitaja Nimi: Ari Muhonen Puhelin: (09-451)4112 Sähköposti: Ari.Muhonen@hut.fi 7 (25)
2.2.4. Toimistosihteeri, kirjanpito- ja maksuliikennepalvelut Nimi: Paula Latvala Puhelin: (09-451)4521 Sähköposti: Paula.Latvala@hut.fi 2.2.5. OtaShop1-järjestelmän toteuttaja Nimi: Jaakko Salmela Puhelin: Sähköposti: Jaakko.Salmela@hut.fi 3. Tavoitteet ja arviointiperusteet 3.1. Asiakkaan tavoitteet Taulukko 1: Asiakkaan 10 tärkeintä tavoitetta Tavoite Varmennusperuste Kenen tavoite 1. yhteistyö muiden yksiköiden ja toimistojen kanssa Projektiin osallistuneiden yksiköiden ja toimistojen näkemykset järjestelmästä ovat Kirjasto 2. opitaan tietojärjestelmän kehitystyötä käytännössä 3. saadaan kokemusta J2EEtoteutusympäristöstä 4. saadaan nykyaikaiset kuvaus- ja dokumentaatiopohjat 5. saadaan lisää projektinjohtotaitoa atkkeskukseen 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 3.2. Projektiryhmän tavoite 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 atkkeskuksessa 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 atkkeskuksessa. 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. Taulukko 2: Projektiryhmän tavoitteet Projektiryhmän tavoitteet Kirjasto Pasi Ranne,atkkeskus Pasi Ranne, atkkeskus Pasi Ranne, atkkeskus kirjasto, Pasi Ranne Taloustoimisto Kirjasto Pilottivaiheen laboratoriot Pilottivaiheen laboratoriot 8 (25)
Tuottaa sovitulla työmäärällä (1200-1500 h) ohjelmisto, joka täyttää vaatimusmäärittelydokumentissa sille asetetut vaatimukset, ja on asiakkaalle hyödyllinen ja käyttökelpoinen. Tuottaa sellaiset dokumentit, joita asiakas voi käyttää mallina myöhemmissä projekteissaan. Suorittaa kurssi hyvällä arvosanalla. (Arvosana 4 tai 5) Taulukko 3: Henkilökohtaiset oppimistavoitteet Jäsen Henkilökohtaiset oppimistavoitteet Erkka Halme - Projektinhallintataitojen oppiminen - Ohjelmistoprojektin kokonaisuuden ymmärtäminen - Asiantuntijoiden johtamisen oppiminen Anna Larmo - 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ä Antti - Toimiminen oikeaoppisessa ja kiireettömässä projektissa Kärkkäinen - Uusien ratkaisujen löytäminen perinteisiin ohjelmistoprojektien ongelmiin - Uusien työkalujen kokeileminen kehitystyössä Kai Inkinen - Toimiminen isomassa ryhmässä ja projektissa - Tietoturvan soveltaminen ohjelmistoprojekteissa - Oppia projektin dokumentoinnista ja sen tehostamisesta (Documentation practices) Karri Karanko - 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ä Matti Kosunen - Henkilökohtaisen työtavan (Design patterns) oppiminen ja sen käyttö tehokkaasti ohjelmistoprojekteissa. - Laadukkaan ohjelman tuottaminen annetusta aiheesta ja annetussa ajassa. Simo Ojanen - 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. 3.4. Perusteet projektin lopettamiselle Projekti lopetetaan kurssin päättyessä, eli kun kaikki kurssin asettamat vaatimukset on täytetty. 4. Resurssit ja kustannusarvio 9 (25)
4.1. Henkilöstö Taulukko 4: Suunniteltu(S) ja toteutunut(t) työmäärä PP I1 I2 I3 DE Yht. su tot su tot su tot su tot su tot su tot Erkka 50 48 39 42 40 38 30 33 18 18 190 179 Anna 40 28 40 39 50 24 48 44 40 40 190 175 Antti 40 37 45 23 66 48 45 44 23 23 190 175 Kai 40 27 45 42 61 32 48 28 40 40 190 169 Karri 35 33 46 35 59 47 40 41,5 22 22 190 179 Matti 40 37 45 33 60 49 40 32,5 27 27 190 179 Simo 40 25 45 40 63 36 48 42 35 35 190 178 Yhteensä 285 235 305 254 399 274 299 265 205 205 1330 1233 Tarkempi suunnitelma työmääristä on kappaleessa 6. 4.2. Materiaalit 4.2.1. 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 4.2.2. 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 OpenSourceohjelmistoja tai koulun tarjoamia ohjelmistoja 4.2.3. Muut resurssit 10 (25)
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 50 2500 Ryhmä 1230 61500 YHTEENSÄ 1380 64000 5. 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öä. 5.1.1. 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. 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 7. 5.1.3. Tunti- ja muu raportointi, projektinhallinta 11 (25)
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ä. 5.1.4. 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. 5.1.5. 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: Sovitaan ryhmä joka tarkastuksen suorittaa Sovitaan tarkastettava dokumentti, sekä päivämäärä jolloin tarkastaminen tapahtuu Jokainen ryhmän jäsen lukee dokumentin läpi ja tekee merkintöjä Kokous, dokumentti luetaan ääneen Keskeytetään lukeminen mikäli virheitä on löydetty. Todetaan virheet ja epäselvyydet jonka jälkeen joko 12 (25)
Dokumentti korjataan Palautetaan virhe korjattavaksi kirjoittajalle 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. 5.1.6. Projektin katselmointitilaisuudet Jokaisen vaiheen lopussa pidetään katselmointitilaisuus, jossa projektin eteneminen raportoidaan sekä asiakkaalle että kurssihenkilökunnalle. 5.1.7. Vaatimusten priorisointi OtaShop2-järjestelmän ominaisuudet pyritään priorisoimaan, ja toteuttamaan tärkeimmät ominaisuudet ensin. 5.1.8. 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. 5.1.9. 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. 5.1.10. 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ä 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 13 (25)
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. 5.1.11. Ohjelmointityyli ja koodin kommentointi OtaShop2-verkkokauppa tullaan toteuttamaan Java Enterprise Editionia-käyttäen, JSPsivuina. 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. 5.1.12. 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. Projektin toisessa ja kolmannessa toteutusvaiheessa on tarkoitus käyttää automaatiota järjestelmätestauksen tukemiseen. Kun automaatti tietyn asian testaamiseksi on tehty, 14 (25)
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. 5.1.13. Vertaistestaus Toteutusvaihe 3:n aikana järjestelmä annetaan toisen projektiryhmän testattavaksi. 5.1.14. 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 15 (25)
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ä. 5.1.15. 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 16 (25)
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 pdfmuotoon(http://user.it.uu.se/~jan/html2ps.html, http://stat.tamu.edu/doc/gs/ps2pdf.htm) CVS - versionhallintaan(http://www.cvshome.org/) junit - yksikkötestaamiseen(http://www.junit.org) httpunit - järjestelmätestaamiseen(http://httpunit.sourceforge.net/) Maven - käännöstyökalu(http://maven.apache.org/) Microsoft Office 2003 - dokumenttien kirjoittamiseen 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 http://www.hut.fi/atk/tietoturva/turvaevaluointi.html. 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. 6.1. Aikataulu Päivämäärä Vaihe 17 (25)
23.9.- 30.10.2003 (~4 vko) PROJEKTIN SUUNNITTELU 31.10.- 4.12.2003 (5 vko) TOTEUTUS 1 5.12.2003-12.2.2004 (10 vko) TOTEUTUS 2 13.2.- 18.3.2004 (5 vko) TOTEUTUS 3 19.3.2004-7.4.2004 (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) name effort responsible start_date finish_date DS:Ohjelmistoarkkitehtuurin suunnittelu 15 mjkosune 2003-10-23 2003-10-30 DS:Testausmenetelmien opiskelu 10 kkaranko 2003-10-23 2003-10-30 DS:Tietoturvaan tutustuminen ja suunnittelu 10 kinkinen 2003-10-23 2003-10-30 DS:Vaatimusmäärittely 27 ALL 2003-09-23 2003-10-30 DS:Vaatimusten dokumentointi 15 ALL 2003-09-23 2003-10-30 GE:Dokumenttipohjien luonti ja www-sivusto 10 alarmo 2003-10-23 2003-10-30 GE:Kehitysymp. pystytys ja ylläpito 15 akarkkai 2003-09-23 2003-10-30 GE:Luennot 10 ALL 2003-09-23 2003-10-14 GE:Tapaamiset (ryhmä/mentor) 15 ALL 2003-09-23 2003-10-30 GE:Tietokannan asennus ja testaus 15 siojanen 2003-09-23 2003-10-30 PM:ANNA:henk.koht. harj 7 alarmo 2003-10-07 2003-10-30 PM:ANTTI:henk.koht. harj 7 akarkkai 2003-10-07 2003-10-30 PM:Edistymisraportin kirj. 6 ALL 2003-09-23 2003-10-30 PM:ERKKA:henk.koht. harj 7 eshalme 2003-10-07 2003-10-30 PM:KAI:henk.koht. harj 7 kinkinen 2003-10-07 2003-10-30 PM:KARRI:henk.koht. harj 7 kkaranko 2003-10-07 2003-10-30 PM:MATTI:henk.koht. harj 7 mjkosune 2003-10-07 2003-10-30 PM:Projektin katsaus ja valmistaut. 8 ALL 2003-10-27 2003-10-30 PM:Projektin tavoitteiden määrittely 20 ALL 2003-09-23 2003-10-30 PM:Projektisuun. kirj. 15 ALL 2003-10-23 2003-10-30 PM:Riskienhallinta 8 ALL 2003-09-23 2003-10-30 PM:Sekal. proj.hallinta 12 eshalme 2003-09-23 2003-10-30 PM:Seuraavan vaiheen suunn. 10 ALL 2003-09-23 2003-10-30 PM:SIMO:henk.koht. harj. 7 siojanen 2003-10-07 2003-10-30 PM:Työtapojen suunnittelu 15 ALL 2003-09-23 2003-10-30 6.3. Toteuttamisvaihe 1 Tavoitteet: 18 (25)
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 2003-10-31 2003-12-04 DS: Tietoturva-vaatimuksien selvittäminen 10 ALL 2003-10-31 2003-12-04 DS:Arkkitehtuurin suunn. 15 mjkosune 2003-10-31 2003-12-04 DS:Kirjoita tekn. dokum. 17 ALL 2003-10-31 2003-12-04 DS:Päivitä proj.suunn. 5 eshalme 2003-10-31 2003-12-04 DS:Päivitä vaat. määr. dok. 10 ALL 2003-10-31 2003-12-04 GE: Dokumenttien tarkastelu (Kain harj.) 12 ALL 2003-10-31 2003-12-04 GE: Käännösympäristön luominen 10 akarkkai 2003-10-31 2003-12-04 GE: Kehitysymp. ylläpito 5 akarkkai 2003-10-31 2003-12-04 GE:Muut tehtävät 5 ALL 2003-10-31 2003-12-04 GE:Tapaamiset (ryhmä/mentor) 25 ALL 2003-10-31 2003-12-04 IM: Sivukehyksen luominen 8 alarmo 2003-10-31 2003-12-04 IM: Tuotetietokannan suun ja tot. 8 siojanen 2003-10-31 2003-12-04 IM:Tot. arkkitehtuuri (CART) 5 ALL 2003-10-31 2003-12-04 IM:Tot. arkkitehtuuri (DAO) 20 ALL 2003-10-31 2003-12-04 IM:Tot. arkkitehtuuri (ORDER) 10 ALL 2003-10-31 2003-12-04 IM:Tot. arkkitehtuuri (PAYMENT) 10 ALL 2003-10-31 2003-12-04 IM:Use Case 1 (tilaus) 8 ALL 2003-10-31 2003-12-04 IM:Use Case 2 (selaus) 10 ALL 2003-10-31 2003-12-04 IM:Use Case 3 (ostoskori) 10 ALL 2003-10-31 2003-12-04 IPM: SIMO henk.koht har 7 siojanen 2003-10-31 2003-12-04 PM:ANNA henk.koht har 7 alarmo 2003-10-31 2003-12-04 PM:ANTTI henk.koht har 5 akarkkai 2003-10-31 2003-12-04 PM:ERKKA henk.koht har 2 eshalme 2003-10-31 2003-12-04 PM:KAI henk.koht har 2 kinkinen 2003-10-31 2003-12-04 PM:KARRI henk.koht har 7 kkaranko 2003-10-31 2003-12-04 19 (25)
PM:Kirjoita edistymisraportti 5 eshalme 2003-10-31 2003-12-04 PM:MATTI henk.koht har 2 mjkosune 2003-10-31 2003-12-04 PM:review ja valmistautuminen 10 ALL 2003-10-31 2003-12-04 PM:Suun. seur. vaihe 15 ALL 2003-10-31 2003-12-04 PM:Yleinen proj.hallinta 10 eshalme 2003-10-31 2003-12-04 TE:Toteuta ja raportoi testaus 15 ALL 2003-10-31 2003-12-04 TE:Valmistele testaus 10 kkaranko 2003-10-31 2003-12-04 6.4. 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) 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: 20 (25)
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 Tässä vaiheessa järjestelmää pyritään testaamaan ja havaintojen perusteella toteutetaan uusia ominaisuuksia sekä korjataan virheitä. Tarkoituksena on mahdollisimman nopeassa rytmissä kirjata puutteet bugzillaan, priorisoida ne sekä jakaa kehittäjille korjattaviksi. Tavoitteet: Järjestelmän antaminen testikäyttöön Vertaistestauksen tekeminen Vikojen ja puutteiden korjaaminen testikäytön perusteella Tarvittavien raporttien toteuttaminen (käyttötapaus 8) Toimitettavat osat: Toimitettavat järjestelmän osat järjestelmä kokonaisuudessaan 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) Tehtävät: Tehtävä Alkup.suunn. vastuu GE: Kehitysymp. ylläpito 5 akarkkai PM:ANTTI henk.koht har 2 akarkkai IM:Korjaa ja muokkaa 25 akarkkai DS: Tekn.dok. Päivitys (Antti) 2 akarkkai DS: Käyttöönoton suunnittelu 3 akarkkai 37 akarkkai Yhteensä DS: Päiv. käyttöohje (Anna) 10 alarmo PM:ANNA henk.koht har 2 alarmo TE: Käyt.testin analyysi(anna) 2 alarmo TE: Vertaistestaus () 7 alarmo DS: Koul.materiaalin teko 6 alarmo DS: Ulkoasudok. päivitys 5 alarmo 21 (25)
DS:Päivitä tekn. dokum. 8 alarmo 40 alarmo Yhteensä GE: Dokumenttien tarkastelu (tekn.doku) 4 ALL GE:Muut tehtävät 3 ALL GE:Tapaamiset (ryhmä/mentor) 35 ALL PM:review ja valmistautuminen 9 ALL PM:Suun. seur. vaihe 7 ALL 58 ALL Yhteensä DS:Päivitä proj.suunn. 4 eshalme DS:Päivitä vaat. määr. dok. 6 eshalme PM:ERKKA henk.koht har 2 eshalme PM:Kirjoita edistymisraportti 3 eshalme PM:Yleinen proj.hallinta 6 eshalme TE: Käyt.testin analyysi(erkka) 1 eshalme 22 eshalme Yhteensä DS: Tietoturva-vaatimuksien selvittäminen 5 kinkinen DS:Päivitä tekn. dokum. 3 kinkinen PM:KAI henk.koht har 2 kinkinen TE: Käyt.testin analyysi(kai) 1 kinkinen IM:Korjaa ja muokkaa 29 kinkinen 40 kinkinen Yhteensä TE: Toteuta puuttuvat testiluokat 5 kkaranko TE:Raportoi testaus 7 kkaranko IM: Admin-osion authorisointi 5 kkaranko PM:KARRI henk.koht har 2 kkaranko GE: Kehitysympäristön refaktor. 2 kkaranko TE: Vertaistestaus (Karri) 4 kkaranko TE:Testiskriptien kirjoittaminen 7 kkaranko 32 kkaranko Yhteensä IM: vanhan koodin refaktorointi 5 mjkosune PM:MATTI henk.koht har 2 mjkosune IM:Korjaa ja muokkaa 25 mjkosune 32 mjkosune Yhteensä IPM: SIMO henk.koht har 2 siojanen IM:Korjaa ja muokkaa 33 siojanen TE: Käyt.testin analyysi(simo) 1 siojanen DS: Tekn.dok. Päivitys (Simo) 2 siojanen 38 siojanen Yhteensä 299 Kaikki yhteensä Tavoitteiden priorisointi: Käyttötapaus 8 (raportit) toteutetaan, jos muut tavoitteet on täytetty Riskit ja epävarmuustekijät: Suurimmat riskit liittyvät siihen, löydetäänkö järjestelmästä kaikki kriittiset virheet ja ehditäänkö ne korjata. 22 (25)
6.6. Jakelu Tavoitteet: Järjestelmää testataan ja korjataan virheitä. Tarkoituksena on mahdollisimman nopeassa rytmissä kirjata puutteet bugzillaan, priorisoida ne sekä jakaa kehittäjille korjattaviksi. Tietokannan vaihtaminen Oraclesta PostgreSQL:ään Dokumenttien viimeistely Asennusohjeen tekeminen ja ohjelmiston paketointi Testilaitteiston toimittaminen asiakkaalle Koko projektin analysointi ja loppuraportin laatiminen Toimitettavat osat: Dokumentit: loppuraportti ajantasaiset versiot kaikista projektin dokumenteista Tehtävät: Tehtävä Alkup.suunn. vastuu GE: Luovutusympäristön suunn & kokoaminen 6 akarkkai PM:ANTTI henk.koht har 2 akarkkai DS: Asennusohjeen kirjoittaminen 2 akarkkai DS: Tekn.dok. Päivitys (Antti) 2 akarkkai DS: Ohjelmiston luovutuspaketointi 4 akarkkai 16 akarkkai Yhteensä DS: Päiv. käyttöohje (Anna) 10 alarmo PM:ANNA henk.koht har 2 alarmo IM: Korjaa ja muokkaa 5 alarmo DS: Ulkoasudok. päivitys 4 alarmo DS:Päivitä tekn. dokum. 8 alarmo 29 alarmo Yhteensä GE: Dokumenttien tarkastelu (tekn.doku) 4 ALL GE:Muut tehtävät 3 ALL GE:Tapaamiset (ryhmä/mentor) 20 ALL PM:review ja valmistautuminen 8 ALL DS: Loppuraportti 18 ALL 53 ALL Yhteensä DS:Päivitä proj.suunn. 2 eshalme DS:Päivitä vaat. määr. dok. 2 eshalme PM:ERKKA henk.koht har 1 eshalme PM:Kirjoita edistymisraportti 3 eshalme PM:Yleinen proj.hallinta 5 eshalme 13 eshalme Yhteensä DS: Asennusohjeen kirjoittaminen 2 kinkinen DS:Päivitä tekn. dokum. 14 kinkinen PM:KAI henk.koht har 2 kinkinen IM: Korjaa ja muokkaa 15 kinkinen 23 (25)
33 kinkinen Yhteensä TE:Raportoi testaus 4 kkaranko IM: Korjaa ja muokkaa 5 kkaranko PM:KARRI henk.koht har 2 kkaranko TE:Järjestelmätestausta 5 kkaranko 16 kkaranko Yhteensä DS: Tekn.dok. Päivitys 3 mjkosune PM:MATTI henk.koht har 2 mjkosune IM:Korjaa ja muokkaa 15 mjkosune 20 mjkosune Yhteensä IPM: SIMO henk.koht har 2 siojanen IM:Kannan vaihto 15 siojanen IM: Korjaa ja muokkaa 5 siojanen DS: Tekn.dok. Päivitys (Simo) 4 siojanen 26 siojanen Yhteensä Tavoitteiden priorisointi: 206 Kaikki yhteensä Jos tietokannan vaihtamisesta tulee ongelmia, ei sitä tehdä Testilaitteiston toimittaminen asiakkaalle ei ole välttämätöntä, jos ohjelmistopaketti on mahdollista ottaa käyttöön asennusohjeiden yms. dokumenttien perusteella Tärkeimmät riskit ja epävarmuustekijät: Jos tietokannan vaihdossa tulee vaikeuksia, sitä ei ehditä tekemään Järjestelmän testauksessa voi nousta esille ennen havaitsemattomia ongelmia/vikoja 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 24 (25)
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ä). 8. Lähteet [1] http://usability.gov/methods/how_many.html [2] Sopimus oikeuksien luovuttamisesta [3] Vaatimusmäärittelydokumentti 25 (25)