Projektiryhmä Tete Työajanseurantajärjestelmä
T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(30) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja 0.20 19.10.2003 Niilo Fredrikson Ensimmäinen integroitu versio, johon koottu kaikki eri tekijöiden tekstit 0.30 19.10.2003 Niilo Fredrikson Ensimmäinen järkevä kokonaisuus, lisätty työmäärät yms. 0.40 21.10.2003 Pauli Aho Korjauksia 0.41 22.10.2003 Niilo Fredrikson Pieniä ulkoasukorjauksia 0.42 26.10.2003 Mika Lindroos Siirretty riskienhallinta erilliseen dokumenttiin riskienhallintasuunnitelma.rtf 0.43 26.10.2003 Marc Josefsson Päivitys henkilökohtaisiin tavoitteisiin 0.44 26.10.2003 Niilo Fredrikson Lisätty koulutussuunnitelma, korjattu tavoitteita ja muutenkin viimeistelty palautusta varten. 1.00 27.10.2003 Miikka Lötjönen Oikoluku/hyväksyntä toimitusta varten. 1.10 24.11.2003 Niilo Fredrikson Seuraavan iteraation suunnittelua ja päivityksiä 1.20 28.11.2003 Niilo Fredrikson Korjauksia ja päivityksiä mm. mentorin kommenttien perusteella 2.00 1.12.2003 Miikka Lötjönen Oikoluku/hyväksyntä toimitusta varten 2.01 1.12.2003 Pauli Aho Hienosäätöä 2.02 22.1.2004 Niilo Fredrikson Päivitetty extended checkin/checkout I2:n toimitukseen
T-76.115 Tietojenkäsittelyopin ohjelmatyö 3(30) 2.10 3.2.2004 Jaakko Nyrölä Muutettu 5.1.1 testauksen hyväksymismäärittelyjä 2.20 4.2.2004 Niilo Fredrikson Päivitetty I3:n suunnitelmia 2.30 6.2.2004 Jaakko Nyrölä Päivitetty I3:n suunnitelmia peer-testauksen osalta, sekä yleistä aikataulua 2.31 7.2.2004 Niilo Fredrikson Pieniä korjauksia tyyleihin liittyen 2.40 8.2.2004 Niilo Fredrikson Päivitetty ajankäyttösuunnitelmat ja tehtävälistat sekä riskienhallintaosuutta 3.00 8.2.2004 Miikka Lötjönen Oikoluku/hyväksyntä toimitusta varten
T-76.115 Tietojenkäsittelyopin ohjelmatyö 4(30) Sisällysluettelo Muutoshistoria... 2 Sisällysluettelo... 4 1. Johdanto... 6 1.1 Projektin tarkoitus ja laajuus... 6 1.2 Järjestelmä ja käytetty ympäristö... 6 1.3 Oikeudet projektin tulosten käyttöön... 6 1.4 Sanasto ja määritelmät... 6 2. Henkilöstö ja asianosaiset... 7 2.1 Projektiryhmä... 7 2.1.1 Projektiryhmän tiedot... 7 2.1.2 Projektiryhmän jäsenet ja roolit (vastuut)... 7 2.1.3 Erityistyöryhmät projektiryhmän sisällä... 7 2.2 Muut asianosaiset... 7 3. Tavoitteet ja loppukriteerit... 7 3.1 Asiakkaan tavoitteet... 7 3.2 Projektiryhmän tavoitteet... 7 3.3 Projektin keskeyttämiskriteerit... 7 3.4 Projektin päättämiskriteerit... 7 4. Resurssit ja budjetti... 7 4.1 Henkilöstö... 7 4.2 Materiaali... 7 4.3 Budjetti... 7 5. Työkäytännöt ja työkalut... 7 5.1 Käytännöt... 7 5.1.1 Testaus... 7 5.1.2 Kokouskäytännöt... 7 5.1.3 Raportointi... 7 5.1.4 Dokumentointi... 7 5.1.5 Henkilökohtaiset SE-tehtävät... 7 5.1.6 Muut käytännöt... 7 5.2 Työkalut... 7 5.3 Standardit... 7 6. Projektin vaiheet... 7
T-76.115 Tietojenkäsittelyopin ohjelmatyö 5(30) 6.1 Yhteenveto... 7 6.2 Projektin suunnittelu... 7 6.2.1 Tavoitteet... 7 6.3 Toteutus 1... 7 6.3.1 Tavoitteet... 7 6.3.2 Toimitettavat asiat... 7 6.3.3 Työtehtävät... 7 6.4 Toteutus 2... 7 6.4.1 Tavoitteet... 7 6.4.2 Toimitettavat asiat... 7 6.4.3 Työtehtävät... 7 6.5 Toteutus 3... 7 6.5.1 Tavoitteet... 7 6.5.2 Toimitettavat asiat... 7 6.5.3 Työtehtävät... 7 6.6 Toimitus... 7 6.6.1 Tavoitteet... 7 6.6.2 Toimitettavat asiat... 7 6.6.3 Työtehtävät... 7 6.7 Jatkokehitys... 7 7. Riskienhallintasuunnitelma... 7 8. Koulutussuunnitelma... 7 Viitteet... 7 Liitteet... 7
T-76.115 Tietojenkäsittelyopin ohjelmatyö 6(30) 1. Johdanto 1.1 Projektin tarkoitus ja laajuus Projektin tarkoituksena on tuottaa työajanseurantaan käytettävä ohjelmisto ( WTAS ), jonka projektin asiakas Tamtron Solution Oy voi ottaa tuotevalikoimaansa myytäväksi edelleen omille asiakkailleen ( loppuasiakas ). Projektin toteuttaa kurssin T-76.115 Tietojenkäsittelyopin ohjelmatyö puitteissa projektiryhmä Tete. Tamtron Solution Oy auttaa omia asiakkaitaan parantamaan tehokkuutta, tarkkuutta ja turvallisuutta niin tuotanto-, toimisto- kuin myymälätiloissa tarjoamalla kulunvalvonta-, työajanseuranta- ja tiedonkeruujärjestelmiä. Tamtron Solutionin asiakkaat ovat teollisuuden, kaupan ja julkishallinnon aloilta. WTAS:sta on tarkoitus tulla asiakkaan ensimmäinen pelkästään ohjelmistopohjainen työajanseurantajärjestelmä. Aikaisemmat järjestelmät ovat perustuneet erikoislaitteistoihin (esim. leimauslaitteet), eikä niitä ole tarkoitettu pelkästään tietokoneen kautta tapahtuvaan työaikakirjanpitoon. Erityisesti asiantuntijaorganisaatioilla on kuitenkin ilmennyt tarvetta tietokoneen kautta tapahtuvalla työaikakirjanpidolle. WTAS on Tamtron Solutionin ensimmäinen askel tälle alueelle. 1.2 Järjestelmä ja käytetty ympäristö WTAS on ohjelmisto, joka yhdessä tietokoneen kanssa muodostaa tietokonepohjaisen työajanseurantajärjestelmän. WTAS:ia tulevat käyttämään Tamtron Solutionin asiakkaiden työntekijät ( käyttäjät ) omilta henkilökohtaisilta tietokoneiltaan. Tarkoituksena on vapauttaa työntekijät tarpeesta kävellä leimauslaitteen kautta töihin ja töistä pois; työaikakirjanpidon voisi hoitaa kokonaan omasta työpisteestä käsin. WTAS toteutetaan client-server-mallin mukaisesti. Ohjelmisto asennetaan loppuasiakkaan palvelimelle, ja käyttäjät käyttävät sitä omalta tietokoneeltaan ensisijaisesti www-selaimen kautta. Projektin kuluessa saatetaan toteuttaa myös Windows-ympäristöön erillinen client-ohjelma leimausten suorittamista varten. 1.3 Oikeudet projektin tulosten käyttöön Projektiryhmä ja asiakas ovat sopivat projektin alussa tekevänsä erillisen sopimuksen immateriaalioikeuksista. Sopimus on allekirjoitettu 24.11. ja siitä on asiakkaalla yksi kappale ja projektiryhmällä (projektipäälliköllä) yksi kappale. Myöhemmin sopimuksesta otetaan kopiot jokaiselle ryhmän jäsenelle. 1.4 Sanasto ja määritelmät Asiakas Järjestelmä Käyttäjä Käyttäjät Loppuasiakas Ohjelmisto Projektiryhmä Projektin asiakas Tamtron Solution Oy (yhteyshenkilö Teppo Rinta-Filppula) Projektissa kehitettävä työajanseurantajärjestelmä WTAS Järjestelmän käyttäjä, tyypillisesti loppuasiakkaan työntekijä Järjestelmän kaikki käyttäjät, suurin osa loppuasiakkaiden työntekijöitä Asiakkaan asiakas, joka on ottanut käyttöön järjestelmän Ks. järjestelmä Projektiryhmä Tete, joka suorittaa projektin. Yksityiskohdat projektisuunnitelman kohdassa 2
T-76.115 Tietojenkäsittelyopin ohjelmatyö 7(30) Työlaji WTAS Työlaji on sovittu yläkäsitteeksi erilaisille työlajeille kuten jokin projekti, firman sisäinen työ, jne. Work Time Attendance System (ks. Järjestelmä) 2. Henkilöstö ja asianosaiset Projektin asiakas on Tamtron Solution Oy. Asiakkaan yhteyshenkilö on Teppo Rinta-Filppula. Yrityksen toimitusjohtaja Mika Leppäkoski seuraa myös projektin etenemistä. Teknisenä asiantuntijana asiakkaan puolelta on Jussi Hirvonen. Kaikki yhteydenpito asiakkaaseen tapahtuu oletusarvoisesti yhteyshenkilön kautta. Kurssin puolesta projektiin osallistuu mentorin roolissa Markus Rautopuro. Projektiryhmää johtaa projektipäällikkönä Niilo Fredrikson. Kaikki yhteydenpito ryhmään tapahtuu oletusarvoisesti projektipäällikön kautta. Asiakas Asiakas / ohjaaja: Mika Leppäkoski Tekninen asiantuntija: Jussi Hirvonen Asiakas / ohjaaja: Teppo Rinta-Filppula SoberIT Mentor: Markus Rautopuro Projektiryhmä Projektipäällikkö: Niilo Fredrikson Arkkitehtuurisuunnittelu: Marko Nikula Ohjelmointiasiantuntija: Tuomas Heino Dokumentaatio: Mika Lindroos Viestintä: Miikka Lötjönen Käyttöliittymäsuunnittelu: Marc Josefsson Testaus: Jaakko Nyrölä Tietoturva: Pauli Aho Kuva 1: Organisaatiokaavio
T-76.115 Tietojenkäsittelyopin ohjelmatyö 8(30) 2.1 Projektiryhmä 2.1.1 Projektiryhmän tiedot Ryhmän nimi: TeTe Sähköposti: nfredrik#cc.hut.fi Kotisivut: http://www.hut.fi/~nfredrik/t76115/indeks.html (rajoitettu pääsy) Projektiryhmä koostuu kahdeksasta neljännen ja viidennen vuosikurssin opiskelijasta Teknillisen korkeakoulun tietotekniikan osastolla. Ryhmän kaikki jäsenet on esitelty alla aakkosjärjestyksessä. 2.1.2 Projektiryhmän jäsenet ja roolit (vastuut) Rooli ja vastuut: Tietoturvavastaavan vastuualueena on tietoliikenne ja turvallisuus mukaan lukien käyttäjien tunnistus ja sisään kirjautuminen. Nimi: Aho, Pauli Puhelin: 050-3835626 Sähköposti: pkaho#cc.hut.fi Kiinnostuksen kohteet ja taidot: Salausmenetelmät ja Java-ohjelmointi. Opinnot ja työkokemus: Neljännen vuosikurssin opiskelija TKK:n tietotekniikan osastolla pääaineena Tietoliikenneohjelmistot ja sivuaineena Formaalit menetelmät tietojenkäsittelytekniikassa. Teki kesän 2003 Java-ohjelmistokehitystä Tietojenkäsittelyteorian laboratoriossa ja toimii tällä hetkellä tuntiassistenttina Tietojenkäsittelyteorian perusteet kurssilla. Rooli ja vastuut: Projektipäällikkö hoitaa tehtävien jaon ryhmän sisällä, pitää yhteyttä asiakkaaseen ja mentoriin sekä vastaa viime kädessä koko projektista. Niilo osallistuu vaatimusten- ja riskienhallintatyöryhmien toimintaan. Nimi: Fredrikson, Niilo Puhelin: 050-3567177 Sähköposti: nfredrik#cc.hut.fi Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Viidennen vuosikurssin opiskelija TKK:n tietotekniikan osastolla pääaineena Digitaalisten tuotteiden kehittäminen ja sivuaine tuotantotalouden osastolta sekä lisäksi kolmannen vuosikurssin opiskelija HKKK:lla. Toiminut harjoittelijana Elisa Communicationsin tutkimuskeskuksella, Nokia Networksillä, Oulun Tietomaalla, toimitusjohtajana Nobman Informatics Oy:llä 1999-2002, tuotepäällikkönä Ch5 Finland Oy:llä 6/2002 2/2003. Toimii tällä hetkellä tuotantopäällikkönä Ch5 Finland Oy:llä. Rooli ja vastuut: Ohjelmointiasiantuntijan vastuualueena teknisesti haastavimpien osien toteutus sekä versionhallinta. Tuomas osallistuu myös riskienhallintatyöryhmään. Nimi: Heino, Tuomas Puhelin: 09-468 2671 Sähköposti: iheino#cc.hut.fi Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Viidennen vuosikurssin opiskelija TKK:n tietotekniikan osastolla pääaineena Ohjelmistojärjestelmät. Toiminut kesän 1997 ohjelmoijana Nokia-Maillefer Oy:llä ja vuodesta 1999 lähtien ohjelmoijana Sam-Systems Oy:llä vastuunaan pankkien itsepalvelujärjestelmien (pankkikortit, verkkopankki, yms.) taustajärjestelmien toteutusta (pääosin C, informix) ja suunnittelua.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 9(30) Rooli ja vastuut: Käyttöliittymäsuunnittelijan vastuualueena on käyttöliittymien suunnittelu ja toteutus. Marc osallistuu myös riskienhallintatyöryhmään. Nimi: Josefsson, Marc Puhelin: 041-5078499 Sähköposti: mjosefss#cc.hut.fi Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Neljännen vuosikurssin opiskelija TKK:n tietotekniikan osastolla pääaineena Digitaalisten tuotteiden kehittäminen ja sivuaineena Ohjelmistojärjestelmät. Teki kesän 2003 WWW-sovellusten ohjelmointia.net:n ja Perlin avulla Tilastokeskuksella ja tarjoaa tällä hetkellä samoja palveluja Tilastokeskukselle omalla toiminimellään. Rooli ja vastuut: Dokumentointivastaavan vastuualueena on dokumentointiin liittyvät prosessit. Mika osallistuu myös vaatimusten- ja riskienhallintatyöryhmiin. Nimi: Lindroos, Mika Puhelin: 040-5747330 Sähköposti: mklindro#cc.hut.fi Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Neljännen vuosikurssin opiskelija TKK:n tietotekniikan osastolla pääaineena Digitaalisten tuotteiden kehittäminen ja sivuaineena Vuorovaikutteinen digitaalinen media. Saanut työkokemusta koulukursseilla tehdyistä ohjelmointiprojekteista. Rooli ja vastuut: Viestintävastaavan vastuualueena ovat projektin viestintään liittyvät menetelmät sekä projektin WWW-sivujen luominen ja ylläpito. Nimi: Lötjönen, Miikka Puhelin: 050-3692581 Sähköposti: mlotjone#cc.hut.fi Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Rooli ja vastuut: Arkkitehtuurisuunnittelija vastaa arkkitehtuurin linjauksista sekä ryhmän sisäisestä koulutuksesta. Nimi: Nikula, Marko Puhelin: 050-3315514 Sähköposti: marko.nikula#nobman.com Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Viidennen vuoden opiskelija TKK:n tietotekniikan osastolla pääaineena Tietämystekniikka ja sivuaineena Informaatiotekniikka. Toiminut harjoittelijana Oulun Tietomaalla ja Nokia Networksillä, kehityspäällikkönä Nobman Informatics Oy:llä 1999-2002 ja toimii tällä hetkellä tuotekehityspäällikkönä Ch5 Finland Oy:llä. Rooli ja vastuut: Testausvastaavan vastuualueena ovat testaukseen liittyvät prosessit. Jaakko osallistuu vaatimustenhallintatyöryhmän toimintaan. Nimi: Nyrölä, Jaakko Puhelin: 050-3268930 Sähköposti: jnyrola#cc.hut.fi Kiinnostuksen kohteet ja taidot: Opinnot ja työkokemus: Neljännen vuosikurssin opiskelija TKK:n tietotekniikan osastolla pääaineena ohjelmistotekniikka ja sivuaineena tuotantotalouden osastolta Työpsykologia ja johtaminen. Hoiti kesän 2003 tietokoneylläpitäjän tehtäviä ja ohjelmoi Javalla mobiili- ja WWWsovelluksia Jaakko Pöyryllä. Jatkaa tällä hetkellä kyseisiä tehtäviä osa-aikaisena työntekijänä.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 10(30) 2.1.3 Erityistyöryhmät projektiryhmän sisällä Projektiryhmä jakaantuu sisäisesti muutamaan erityistyöryhmään: Vaatimustenhallintaryhmän muodostavat Niilo Fredrikson (pj), Mika Lindroos ja Jaakko Nyrölä. Riskienhallintaryhmän muodostavat Mika Lindroos (pj), Marc Josefsson, Tuomas Heino ja Niilo Fredrikson. Riskienhallintaryhmä toimii kurssin T-76.633 Risk Management puitteissa, ja riskienhallintaan käytettyjä tunteja ei siten huomioida tässä projektissa. 2.2 Muut asianosaiset Projektin kaksi muuta asianosaisten ryhmää ovat asiakas ja kurssin järjestävä SoberIT, jonka kurssihenkilökunnasta tässä on esiteltynä vain projektiryhmän mentor Markus Rautopuro. Rooli: Asiakkaan yhteyshenkilö Työn kuvaus: Vastaa projektista Tamtron Solution Oy:n sisällä. Nimi: Rinta-Filppula, Teppo Puhelin: 09-25305307 Sähköposti: teppo.rinta-filppula#tamtron.fi Rooli: Asiakas Työn kuvaus: Toimitusjohtaja, seuraa projektin etenemistä ajoittain Nimi: Leppäkoski, Mika Puhelin: 09-25305300 Sähköposti: mika.leppakoski#tamtron.fi Rooli: Asiakas / Tekninen asiantuntija Työn kuvaus: Vastaa teknisistä kysymyksistä asiakkaan puolella. Nimi: Hirvonen, Jussi Puhelin: - Sähköposti: - Rooli: Mentor Työn kuvaus: Toimii projektin mentorina. Tekninen asiantuntija omassa työpaikassaan (Aureolis Oy). Nimi: Rautopuro, Markus Puhelin: Sähköposti: markus.rautopuro#aureolis.com 3. Tavoitteet ja loppukriteerit Eri tavoitteita on paljon, mutta niissä ei toistaiseksi ole havaittu merkittäviä ristiriitoja. Tämä johtunee siitä, että projektiryhmän sisällä ja kaikkien projektin asianosaisten kesken on ennen projektin alkua ja projektin alussa käyty riittävä keskustelu eri osapuolten tavoitteista ja toiveista. 3.1 Asiakkaan tavoitteet Asiakkaan tavoitteena on saada tuotevalikoimaansa selainpohjainen työajanseurantajärjestelmä. Tämän järjestelmän tulisi toimia vaatimusmäärittelyn mukaisesti. Tuotteessa pitäisi olla ainakin kaikki työajanseurantajärjestelmän perustoiminnot, mutta asiakas on kiinnostunut myös tämän projektin jälkeisestä
T-76.115 Tietojenkäsittelyopin ohjelmatyö 11(30) jatkokehityksestä projektin onnistuessa hyvin. Asiakas tulee itse arvostelullaan ilmaisemaan heidän yleisten tavoitteidensa täyttymisen. Yleisten tavoitteiden lisäksi asiakas on määritellyt myös erikseen mitattavia ja arvioitavia tavoitteita (Taulukko 1). Taulukko 1: Asiakkaan kymmenen tärkeintä tavoitetta Tavoite Tarkistuskriteerit 1. Vaatimusten täyttäminen Asiakas arvioi subjektiivisesti kuinka hyvin ja kuinka monta vaatimusdokumentissa esitetyistä vaatimuksista tulee täytetyksi. 2. Laajennettavuus ja jatkokehitettävyys 3. Projekti suoritetaan onnistuneesti kaikkien projektiin osallistuvien sidosryhmien näkökulmasta. Järjestelmän on oltava mahdollisimman helposti laajennettavissa ja jatkokehitettävissä projektin jälkeen. Asiakkaan tekninen asiantuntija ja mentor laativat subjektiivisen arvion projektin jälkeen. Tavoite on saavutettu, jos ryhmän arvosanaksi tulee 5 (kun henkilökohtaisten, ei koko ryhmää koskevien SE-tehtävien vaikutus eliminoitu). 4. Suorituskyky Vasteaika ei saa perustoiminnoissa olla sekuntia ja perushauissa viittä sekuntia enempää. 5. Käytettävyys. Asiakas arvioi subjektiivisesti tuotteen käytettävyyttä. 6. Skaalautuvuus (kuinka järjestelmä toimii suurella tietokannalla ja useilla käyttäjillä) 7. Riippumattomuus kolmansien osapuolten ohjelmista Tallennetun tietomäärän kasvaminen ei saa laskea suorituskykyä niin että käytettävyys vaarantuu. Asiakas arvio skaalautuvuutta subjektiivisesti käyttäen testitietokantaa, johon on tallennettu pk-yrityksen (n. 100 henkilöä) yrityksen yhden vuoden kirjauksia vastaava tietomäärä. Mahdollisimman suuri riippumattomuus käytetystä tietokannasta, servletmoottorista, selaimesta, käyttöjärjestelmästä ja näiden versioista. Asiakkaan tekninen asiantuntijan ja mentorin subjektiivinen arvio projektin jälkeen. 8. Tietoturvallisuus Käyttäjien tunnistaminen, tietokanta ja salasanatiedot on suojattu mahdollisimman hyvin Asiakkaan teknisen asiantuntijan ja mentorin subjektiivinen arvio. 9. Toistettavuus Saman haun tulee palauttaa sama raportti (tiedot samassa järjestyksessä) joka kerta toistettaessa. Asiakkaan subjektiivinen arvio. 10. Projekti suoritetaan onnistuneesti myös ulkopuolisten tarkkailijoiden mielestä (Accenture) Tavoite on saavutettu, mikäli kurssin arviointiryhmä kutsuu projektiryhmän esittelemään projektinsa sisältöä.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 12(30) 3.2 Projektiryhmän tavoitteet Jokaisen ryhmän jäsenen tavoite on syventää tietämystään ohjelmistotuotteen kehitysprosesseista ja niihin liittyvistä tukitoiminnoista. Joillekin ryhmän jäsenille tämän on ensimmäinen kerta, kun he saavat olla mukana näinkin laajassa ohjelmistoprojektissa; projekti tuo heille varmasti uutta näkemystä. Ryhmän vähemmän työelämässä olleet henkilöt arvostavat varmasti myös projektin tuomaa lisää ansioluetteloihinsa. Tavoitteena on, että jokainen ryhmän jäsen oppisi jotakin uutta. Koska projekti on ryhmän jäsenille taloudellisesti riskitön, vastuualueita ja työtehtäviä voidaan vaihdella kiinnostusten mukaisesti; jokainen päässee kokeilemaan itseään kiinnostavia asioita projektin kuluessa. Projektiryhmän asiakasta ja kurssia sivuavat tavoitteet ovat seuraavat. Tahdomme saada aikaan mahdollisimman hyvin asiakkaan tarpeita vastaavan tuotteen. Tämän tavoitteet saavuttaminen edellyttää hyvälaatuisen koodin lisäksi aikataulussa pysymistä, hyvälaatuista dokumentaatiota ja erityisesti sujuvaa kommunikaatiota projektin tärkeimpien sidosryhmien välillä (ryhmän jäsenet, asiakas ja mentor). Kurssin näkökulmasta ryhmän tavoitteet ovat melko samankaltaiset. Kaikki ryhmän jäsenet tuntuvat olevan kiinnostuneita tästä kurssista ja sen käsittelemästä aiheesta. Tarkoituksemme on luoda projektimme tueksi sellaisia prosesseja, jotka täyttävät kurssin henkilökunnan odotukset. Arvosanatavoite on 5. Projektin eri osapuolten välille ei ole vielä syntynyt suuria eturistiriitoja. Asiakkaamme tuntuu sisäistäneen projektin kuulumisen TKK:n kurssin alaisuuteen, eikä toistaiseksi ole vaatinut liikoja. Ainoa tähän mennessä tavattu perusongelma on se, että projektiryhmämme jättää tuotteen tämän kurssin jälkeen. Tämä ongelma on jo siinä mielessä ratkaistu, että ryhmän jäsenistä useampi on ilmoittanut asiakkaalle olevansa todennäköisesti käytettävissä jatkokehitystä varten. Taulukko 2: Projektiryhmän tavoitteet Projektiryhmän tavoitteet 1. Oppia uusia asioita käytännön ohjelmistoprojekteihin liittyen. 2. Asiakkaan vaatimusten ja toiveiden täyttäminen. 3. Kurssin vaatimusten täyttäminen (hyvä kurssiarvosana). Taulukko 3: Henkilökohtaiset oppimistavoitteet Ryhmän jäsen Pauli Aho Niilo Fredrikson Henkilökohtainen oppimistavoite Kattavan kokonaiskuvan saaminen ohjelmistokehitysprosessista, ryhmätyötaitojen kehittäminen ja kontaktien luominen. Kokeilla kerrankin miten asioiden tekeminen oikein vaikuttaa ohjelmistoprojektin lopputulokseen (dokumentaatio, prosessit, jne.) Tuomas Heino Soveltaa uusia versionhallintatyökaluja ja - menetelmiä käytännössä.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 13(30) Marc Josefsson Mika Lindroos Miikka Lötjönen Marko Nikula Jaakko Nyrölä Nähdä läheltä ja kokeilla ohjelmistoprosessin eri osa-alueita. Tutustua ohjelmiston käytettävyyden tutkintaan. Kokea ensimmäistä kertaa käytännössä ohjelmistontuotantoprosessi kokonaisuudessaan ja oppia samalla mahdollisimman paljon sekä kokonaisuudesta että yksittäisistä osa-alueista. Saada lisäkokemusta ohjelmistoprosesseista ja oppia projektinryhmän sisäisen viestinnän käytännön ongelmien ratkaisemista. Saada kokemusta ohjelmistoprojektista, jossa on suuri määrä kehittäjiä ja käytössä järjestelmälliset työskentelymenetelmät. Mahdollisuus soveltaa uusia ideoita ja menetelmiä välittömästi työelämässä tekee kurssista entistäkin mielenkiintoisemman. Nähdä ohjelmistoprojekti läheltä, ja oppia mahdollisimman paljon uutta. Käyttää uusia menetelmiä ohjelmiston testaukseen liittyen. 3.3 Projektin keskeyttämiskriteerit Projekti tullaan keskeyttämään vain sellaisessa tilanteessa, jossa projektin jatkaminen järkevästi olisi mahdotonta. Tällä hetkellä ainoa projektiryhmästä lähtöisin oleva projektin keskeytymissyy olisi kolmen tai useamman ryhmän jäsenen lähteminen ryhmästä. Toinen mahdollinen syy projektin keskeytymiseen voisi olla esimerkiksi asiakasyhteistyön yllättävä loppuminen. 3.4 Projektin päättämiskriteerit Projekti päätetään 7.4.2004 kurssin päättyessä loppudemoon. Varmaa on, että kurssin puitteissa järjestelmään ei ehditä toteutettua kaikkia mahdollisia työajanseurantaan liittyviä komponentteja tai toimintoja. Tästä syystä projekti ei tule päättymään aikaisemmin. Asiakkaan kanssa on käyty alustavia keskusteluja jatkosta. Asiakas on ilmaissut olevansa kiinnostunut jatkamaan projektia osan projektiryhmästä kanssa, mikäli projekti onnistuu hyvin. 4. Resurssit ja budjetti 4.1 Henkilöstö Taulukko 4: Suunnitellut työtunnit projektin aikana Niilo Marko Tuomas Marc Jaakko Mika Pauli Miikka Yht.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 14(30) PP 58 25 65 31 25 37 35,5 20 296,5 I1 36 40 61 48 51 55 47 27,5 365,5 I2 42,5 39,5 43,5 78,5 61 43,5 85,5 54 448 I3 33,5 48 15 20 32 36,5 15 50 250 DE 20 37,5 5,5 12,5 21 18 7 38,5 160 Yht. 190 190 190 190 190 190 190 190 1520 4.2 Materiaali Asiakas on hankkinut testipalvelimen. Koska testipalvelinta ei onnistuttu sijoittamaan asiakkaan tiloihin, sijoitettiin se toistaiseksi Tuomaksen kotiin. Muuta fyysistä materiaalia ei projektiryhmän käytössä suoraan projektin puolesta ole. 4.3 Budjetti Alla (taulukko 5) on esitetty projektin kuvitteelliset kustannukset asiakkaan näkökulmasta jokaista vaihetta kohden. Projektiryhmän suorittaman työn hinnaksi on oletettu 100 euroa per tunti (ilman arvonlisäveroa). Asiakkaan oman henkilöstön, mentorin ja muun kurssihenkilökunnan työtä ei ole huomioitu. Laskutus voisi tapahtua siten, että asiakas maksaa puolet kunkin vaiheen hinnasta aina vaiheen alkaessa, ja toisen puolen sen jälkeen kun kyseisen vaiheen toimitus on hyväksytty. Taulukko 5: Projektin budjetti Vaihe Työmäärä (tuntia) Hinta () PP 296,5 29650 I1 346,5 34650 I2 428 42800 I3 294 29400 DE 155 15500 Yht. 1520 152000 Lisäksi asiakkaalle koituu kehitysvaiheessa laitteistokustannuksia noin 1500 euron (+ ALV) edestä kehityspalvelimen hankinnan takia.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 15(30) 5. Työkäytännöt ja työkalut 5.1 Käytännöt 5.1.1 Testaus Tuotteen testauksessa noudatetaan V-mallia, eli matalimmalta tasolta lähtien: Yksikkötestauksella varmistetaan moduulien yhdenmukaisuus moduulisuunnittelun kanssa. Ryhmän yksittäinen ohjelmoija suunnittelee toteuttamalleen moduulille testisarjoja, joista ainakin yhden sarjan tulee taata black box ajatusmallin mukaisesti oikean ja väärän syötteen ja tulosteen käsittely. Sarjan sisältämien testitapausten määrä on suoraan riippuvainen syötteen ja tulosteen mahdollisista muodoista. Vähintään yhden testisarjan on testattava koodia white box ajatusmallin mukaisesti eli etsiä suorituksenaikaisia virhetiloja ja kuolleita koodinpätkiä. Testisarjojen tekijän on huolehdittava tarvittavien driverien ja stubien luomisesta (moduulia kutsuvien ja moduulin kutsumien ohjelmien simulointi). Staattisten menetelmien käytöstä vastaava (Jaakko) huolehtii kriittisten moduulien katselmuksien järjestämisestä. Integraatiotestauksella taataan yhdistettyjen moduulien yhdenmukaisuus arkkitehtuurisuunnittelun kanssa. Tämä testaus tehdään inkrementaalisesti lisäämällä moduuleja toisiinsa. Tällöin joudutaan edelleen luomaan drivereita ja stubeja. Toisaalta pienet viat löytyvät nopeammin ja vältytään mahdollisesti kaikkien moduulien samanaikaisesta yhdistämisestä aiheutuvasta kaaoksesta. Ryhmäpalavereissa päätetään, missä järjestyksessä moduulit liitetään, kuka vastaa liittämisestä ja testisarjojen luomisesta. Testisarjat luodaan samoilla periaatteilla kuin yksikkötestauksessa. Tässäkin yhteydessä käytetään staattisia menetelmiä. Järjestelmätestauksella huolehditaan kaikkien laitteiden ja ohjelmistojen yhteistoiminnasta ja yhdenmukaisuus toiminnallisen määrittelyn kanssa. Ryhmäpalavereissa päätetään vastuuhenkilöt ainakin seuraavien ei-toiminnallisten ominaisuuksien testaamiselle: volyymi-, kuormitus-, turvallisuus-, suorituskyky-, konfiguraatio-, asennettavuus- ja luotettavuustestaus. Käytettävyystestaus kuuluu jo henkilökohtaisiin SE-tehtäviin. Resurssienkäytölle ei ole asetettu erityisiä vaatimuksia ja markkinoilta saatavat laitteistot ovat jo sen verran kehittyneitä, joten resurssienkäyttöä ei testata. Kukin ei-toiminnallisen ominaisuuden testaamisen vastuuhenkilö huolehtii ainakin yhden testisarjan luomisesta mittaamalleen ominaisuudella. Testaus tehdään black box ajatusmallin mukaisesti. Jos jossakin tuotteen osassa ilmenee erityisen paljon vikoja, niin ryhmäpalaverissa päätetään kootun testaustilaisuuden järjestämisestä. o Järjestelmätestauksessa käytetään soveltuvin osin ekvivalenssiluokkia ja raja-arvo tarkistuksia. Sovellamme menetelmiä siten, että jokaiseen testitapaukseen valitaan jokaisesta ekvivalenssiluokasta vähintään yksi arvo ja lisäksi testataan raja-arvot erikseen raja-arvon molemmin puolin. Hyväksymistestauksella varmistetaan tuotteen yhdenmukaisuus vaatimusten kanssa. Testaus tehdään asiakkaan tiloissa, joten projektiryhmä konfiguroi tarvittavat laitteet ja ohjelmistot kuntoon ennen testausta. Paikalla on projektiryhmän jäsenien lisäksi asiakas ja tuotteen varsinaisia käyttäjiä. Asiakkaan niin halutessa ryhmä voi järjestää aikaisemmin alpha- ja beetatestaustilaisuuksia. Näille ei kuitenkaan ole todennäköisesti tarvetta, jos käytettävyystestaus päätetään toteuttaa prototyypeillä. Yksikkö- ja integraatiotestauksen yksittäinen testisarja katsotaan suoritetuksi, kun tuotteen testattava osuus läpäisee kaikki testitapaukset. Järjestelmätestauksen ei-toiminnallisten ominaisuuksien testaamiseen käytettyjen testisarjojen hyväksyntää varten asiakkaan on määriteltävä myöhemmin kriteerit. Hyväksymistestausosuus katsotaan suoritetuksi, kun asiakas hyväksyy tuotteen. Tuotteeseen toteutetaan vaatimusmäärittelydokumentin mukaiset ominaisuudet. Yksikkötestauksen tasolla testaustapahtumasta ei
T-76.115 Tietojenkäsittelyopin ohjelmatyö 16(30) pidetä kirjaa, mutta puutteet on luetteloitava. Integraatio- ja järjestelmätestauksen tasolla testitapahtumista tehdään muistiot. Järjestelmätestauksen kattavuutta mitataan käyttötapaustasolla. Jokaisesta toimitettavasta käyttötapauksesta tehdään testitapaukset, jotka määritellään vaatimusten pohjalta ja ryhmitellään käyttötapauksittain. Järjestelmätestauksessa yksittäisen käyttötapauksen testisarja katsotaan suoritetuksi, kun käyttötapauksesta ei löydy yhtään avointa blocker, critical tai major -tason virhettä ja lisäksi minor-tason virheiden lukumäärän suhde testitapausten lukumäärään ei saa ylittää arvoa 0,5. 5.1.2 Kokouskäytännöt Projektiryhmä kokoontuu T-talolla tiistaisin aikavälillä 16-20 ryhmäpalaveriin, johon osallistuminen on erittäin suotavaa jokaiselle ryhmän jäsenelle. Palaverin kesto on tunnista kahteen tuntiin, ja sinä aikana käydään läpi asiakkaalta ja / tai mentorilta tullutta informaatiota ja sen edellyttämiä toimenpiteitä, projektin aikana ilmenneitä kysymyksiä ja ongelmia sekä tulevia tehtäviä ja aikataulua. Jos jokin edellisessä palaverissa sovituista toimenpiteistä on edelleen kesken tai kokonaan suorittamatta, niin toimenpiteeseen kohdennetaan lisää resursseja. Kaikissa ryhmäpalavereissa toimii puheenjohtajana projektipäällikkö. Mentor-tapaamisia on kurssin aikana viisi kappaletta, joihin osallistuminen on pakollista. Tapaamiset kestävät tunnista puoleentoista tuntiin, ja ne järjestetään joko mentorin tai projektiryhmän varaamissa tiloissa. Niiden aikana käydään läpi projektipäällikön mentorille toimittamaa listaa heränneistä kysymyksistä sekä mentorin ehdottamia parannusehdotuksia tuotekokonaisuuteen ja menettelytapoja työskentelyyn. Myös henkilökohtaiset SE-tehtävät esitellään näissä tilaisuuksissa lyhyesti. Mentor-tapaamisissa puheenjohtajan tehtäviä hoitaa mentor, ja tapaamisten järjestämisestä sopivat mentor ja projektipäällikkö keskenään. Asiakastapaamiset ovat projektipäällikön ja asiakkaan keskenään sopimia tapaamisia yleensä asiakkaan tiloissa Westendissä mutta tarvittaessa muuallakin. Niiden kesto on tunnista puoleentoista tuntiin, ja osallistujina ovat asiakasedustajien lisäksi kohdennettu osajoukko projektiryhmästä. Osajoukolla tarkoitetaan tässä kyseiseen vaiheeseen ja tehtävään ryhmäpalaverissa valittua ryhmää. Kaikki eivät osallistu asiakastapaamisiin, koska koko projektiryhmän kokoaminen paikalle ei ole tarpeellista eikä järkevää resurssien käyttöä. Kokouksia järjestetään esimerkiksi tuotteen vaatimusmäärittelyä varten, ja niissä toimii puheenjohtajana projektipäällikkö. Asiakas ja projektipäällikkö sopivat tapaamisten järjestämisestä keskenään. Kaikissa edellä mainituissa kokouksissa agendasta vastaa puheenjohtaja. Jokainen ryhmäläinen toimii vuorollaan sihteerinä ja toimittaa muutaman päivän kuluessa kokouksesta RTF-muotoisen muistion versionhallintaan. 5.1.3 Raportointi Työajan raportointi tehdään kurssilla käytössä olevalla projektinhallintaohjelmistolla Trapoli. Projektipäällikkö määrittelee järjestelmään tarvittavat tehtäväkuvaukset, ja ryhmäläisten tulee kirjata tehdyt tunnit heti toimenpiteiden jälkeen tietokantaan oikean nimikkeen alle. Kirjauksissa käytetään puolen tunnin tarkkuutta. Muutosten raportointiin käytetään sähköpostituslistaa koko ryhmälle. Tähän lukeutuvat vähäistä merkittävämmät päivitykset hyödynnettävien työkalujen ohjeistuksiin sekä muutokset dokumentaatiossa ja ohjelmistossa. Versionhallintaohjelmisto Bitkeeper pitää tarvittavaa kirjausta tiedostojen versioista. Vikojen raportoinnissa hyödynnetään kurssilla käytössä olevaa ohjelmistoa Bugzilla. Viat raportoidaan järjestelmään heti niiden löydyttyä prioriteeteittain, ja järjestelmä välittää
T-76.115 Tietojenkäsittelyopin ohjelmatyö 17(30) sähköpostiviestin eteenpäin kyseisestä viasta koko ryhmälle. Ryhmäpalavereissa päätetään, kuka ottaa vastuun mistäkin viasta ja minkä aikataulun mukaisesti se on korjattava. Edistymisraportista käy ilmi projektin kulku, ja projektipäällikkö vastaa tämän dokumentin tekemisestä. Edistymisraportti palautetaan joka vaiheen lopussa. Loppuraportti kuvaa projektin etenemisen kokonaisuudessaan vaiheittain alusta loppuun. Raportissa käydään läpi ryhmätyöskentelyä, ilmenneitä ongelmia ja niiden ratkaisuja. Vastuu raportin tekemisestä annetaan jollekin ryhmäläiselle, ja raportti palautetaan viimeisessä vaiheessa. 5.1.4 Dokumentointi Dokumentaatio, kuten palaverimuistiot, tuotetaan aluksi Microsoft Wordilla RTF-muodossa. Normaali teksti on kirjoitettu 11pt kokoisena ja Times New Roman fontilla. Otsikoinnissa käytetään Wordin tukemaa otsikkohierarkiaa yhdestä kolmeen. Palaverimuistiot nimetään muodossa muistio_vvvv-kk-pp.rtf, ja muun dokumentaation nimeäminen tulee olemaan yhtä kuvaavaa. Kaikkien dokumenttien alussa säilytetään versiohistoriaa. Dokumentit oikoluetaan ohjelmallisesti, ja lisäksi palautuksiin kuuluvien dokumenttien osalta vähintään yksi ryhmän jäsen, joka ei ole osallistunut dokumentin kirjoittamiseen, oikolukee, tarkistaa ja hyväksyy dokumentin. Dokumentit konvertoidaan lopuksi HTML-muotoon. 5.1.5 Henkilökohtaiset SE-tehtävät Kukin projektiryhmän jäsen on valinnut itselleen henkilökohtaiseksi SE-tehtäväkseen jonkin kurssilla annetun käytännön, ja valittu käytäntöjen kokonaisuus auttaa tekemään tuotteesta laadukkaan. Käytäntöjä vastuuhenkilöineen on esitelty seuraavassa, ja taulukko 6 kertoo, missä vaiheessa käytäntöä tullaan soveltamaan. Heuristinen arviointi (Marc) ja käytettävyystestit (Pauli): Tuotteen käytettävyyttä arvioidaan ilman käyttäjää heuristisella arvioinnilla eli vertaamalla käyttöliittymää systemaattisesti käytettävyyssääntöihin. Käytettävyysteillä pyritään saamaan käyttöliittymästä käytettävyystietoa jo mahdollisimman aikaisessa vaiheessa, sillä muutosten tekeminen vaikeutuu, mitä pidemmälle tuotetta kehitetään. Arkkitehtuurin arviointi (Marko): Kehitettävän tuotteen arkkitehtuurin arvioinnissa hyödynnetään hyväksi havaittuja menetelmiä. Pariohjelmointi (Mika): Pariohjelmoinnilla saavutetaan yksittäisohjelmointia pienempi vikojen määrä, työnteosta tulee mielekkäämpää ja yhden henkilön sairastuminen ei vaaranna koko projektia. Projektin aikana pyritään osoittamaan todeksi edellä esitettyjä väitteitä. Versionhallinta (Tuomas): Projektissa käytetään versionhallintaa dokumentaation ja ohjelmakoodin hallitsemiseen, jolloin vältytään massiivisten liitetiedostojen lähettämiseltä ryhmäpostituksilla. Lisäksi yksittäisen ohjelmakooditiedostojen käsittelystä voi tulla painajaismaista ilman kunnollista versionhallintatyökalua. Staattiset menetelmät (Jaakko): Staattisilla menetelmillä voidaan vähentää ohjelmakoodin vikojen määrää, vaikka usein kiistelläänkin staattisten ja dynaamisten menetelmien eduista. Kyseisillä menetelmillä löydetään erilaisia vikoja. Projektin tuotteeseen sovelletaan jotakin hyväksi havaittua staattista menetelmää laadun parantamiseksi. Viestintäkäytännöt (Miikka): Projektiryhmän koko on itsessään jo 8 henkilöä, ja mukaan lukien asiakas ja mentor saadaan melkoisen monimutkainen viestiyhteyksien verkko. Tätä verkkoa varten on suunniteltava erityisiä käytäntöjä, eli kuka keskustelee kenen kanssa ja minkä välityksellä.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 18(30) Projektin etenemisen seuranta ja hallinta (Niilo): Projektipäällikkö joutuu jokaisen vaiheen palautuksen yhteydessä toimittamaan edistymisraportin, joten seuranta kuuluu luonnostaan hänen tehtäviin. Tätä varten on kehitettävä tiettyjä käytäntöjä, jotta kerätty tieto olisi järkevässä muodossa. Taulukko 6: Henkilökohtaiset SE-tehtävät Käytäntö Vastuuhenkilö Vaihe Heuristinen arviointi Marc Josefsson I1-DE Käytettävyystestit Pauli Aho I1-DE Arkkitehtuurin arviointi Marko Nikula I1 Pariohjelmointi Mika Lindroos I1-I3 Versionhallinta Tuomas Heino PP-DE Staattiset menetelmät Jaakko Nyrölä I1-I3 Viestintäkäytännöt Miikka Lötjönen I1-DE Projektin etenemisen seuranta ja hallinta Niilo Fredrikson I1-DE 5.1.6 Muut käytännöt Alla on listattu muita käytäntöjä, joita projektissa noudatetaan. Niiden käytäntöjen osalta, joita tässä projektisuunnitelmassa ei tarkemmin määritellä, noudatetaan kurssin kotisivuilla [1] annettuja määritelmiä sellaisenaan. Iteratiivinen kehitys Iteratiivinen suunnittelu Riskienhallinta (ks. kohta 7 Riskienhallinta) Tuntiseuranta ja -raportointi Bugienseuranta Dokumentointi ja dokumenttien toimitus Projektikatselmukset Vaatimusten priorisointi Vaatimusten hallinta Käyttötapausten käyttäminen Versionhallinta Koodauskonventiot Vertaisryhmätestaus vaiheessa I3
T-76.115 Tietojenkäsittelyopin ohjelmatyö 19(30) 5.2 Työkalut Ohjelmisto toteutetaan client-server mallin mukaisesti. Asiakasohjelmistona toimii ensisijaisesti wwwselain. Käyttöliittymä optimoidaan Internet Explorer 6 selaimelle. Palvelinpuolen ohjelmointikielenä käytetään Javaa, ja kehitysalustoiksi on valittu Linux ja Windows, joista Linux on ensisijainen kohdealusta. Taulukossa 7 on listattu käytettävät ohjelmistot. Taulukko 7: Projektissa käytettävät ohjelmistot Työväline Versio Kuvaus Lisenssi BitKeeper 3.0.x Versionhallinta. BitKeeper Open License Bugzilla 2.16.2 Vikojenhallinta. SoberIT GNU Emacs 21.2 / 21.3 J2EE 1.4 Ohjelmointi- ja dokumentointityökalu. JavaBeans-, JDBC-, Servlet- ja JavaServer Pages -API:t. GNU General Public License Sun Public License Microsoft Word 2000 / XP Dokumentointityökalu. Kaupallinen, TKK Poseidon for UML: Community Edition 2.0 UML-työkalu. Ilmainen PostgreSQL 7.3 Tietokanta. BSD License Struts - Model-View-Controller suunnitteluparadigman mukainen kehitysympäristö. Apache Software License The Apache Jakarta Project - Kirjastot. Apache Software License Tomcat 4.x / 5.x Servlet-moottori. Apache Software License Trapoli 1.0 Projektin hallinta. SoberIT 5.3 Standardit Projektia koskevien sähköpostiviestien otsikkoriville laitetaan aina tunniste [76.115] helpottamaan sähköpostien automaattista lajittelua.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 20(30) 6. Projektin vaiheet 6.1 Yhteenveto Taulukko 8: Projektin aikataulu PVM Iteraatio / tapahtuma 23.9.- 30.10.2003 (~4 viikkoa) Projektin suunnittelu (PP) alkaa 13.10. Bitkeeper (versionhallinta) käytössä kaikilla 20.10. Koulutuksen vaihe 1 alkaa 26.10. / 27.10. Koulutuksen vaihe 1 päättyy / vaihe 2 alkaa 27.10. klo 15 Toimitus (dokumentit) 30.10. Asiakkaan hankkima testipalvelin ryhmän käytettävissä 30.10. klo 15 Projektikatselmus 31.10. Toteutus 1 (I1) alkaa 2.11. / 3.11. Koulutuksen vaihe 2 päättyy / vaihe 3 alkaa 3.11. Bugzilla (bugit/muutospyynnöt) otettu käyttöön 4.11. klo 16 Koulutustilaisuus / arkkitehtuurin arviointi 9.11. Koulutuksen vaihe 3 päättyy 1.12. klo 15 Toimitus (dokumentit) 4.12. klo 15 Projektikatselmus 5.12.2003-12.2.2004 (10 viikkoa) Toteutus 2 (I2) 19.12. Valikoidut I1:n aikana havaitut bugit korjattu 19.12. Tuntien syöttämiseen liittyvät UC:t tehty 20.12.2003 4.1.2004 Joululoma 12.1. Leimaukseen liittyvät UC:t tehty 26.1. Käyttäjiin liittyvät UC:t tehty 30.1.2004 Uutta toiminnallisuutta ei enää ohjelmoida.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 21(30) 4.2.2004 Dokumentit valmiina, viimeistely ja oikoluku alkaa 9.2.2004 klo 15 Toimitus (dokumentit) 12.2. klo 15 Projektikatselmus 13.2.- 18.3.2004 (5 viikkoa) Toteutus 3 (I3) 16.2. klo 20 Statuspalaveri (IRC), töiden jako 19.2. Asiakkaan testikäyttö käynnistyy 27.2. klo 14 (alustava aika) Workshop käytettävyyden ja toiminnallisuuden parantamisesta 29.2. Uudet toiminnallisuudet ohjelmoitu 1.3.-3.3. Testaus 1.3.-7.3. Bugien korjausta 8.3. klo 15 Toimitus (ohjelma testausta varten vertaisryhmälle) 10.3. Palautettavien dokumenttien ensimmäiset versiot valmiina 12.3. Peer-testaus dokumenttien toimitus peer-ryhmälle 12.3. klo 10 Peer-testauksessa ilmenneiden kokemusten vertailupalaveri 15.3. klo 15 Toimitus (dokumentit) 18.3. klo 15 Projektikatselmus 19.3.2004-7.4.2004 (3 viikkoa) Lopullinen toimitus (DE) 5.4. klo 15 Lopullinen toimitus (dokumentit) 7.4. klo 15 Loppuesittely 6.2 Projektin suunnittelu 6.2.1 Tavoitteet Projektin suunnittelu Ongelmakenttään tutustuminen Vaatimusten määrittely yleisellä tasolla pitäen sisällään tärkeimpien käyttötapausten määrittelyn Ryhmän sisäisen koulutuksen aloittaminen
T-76.115 Tietojenkäsittelyopin ohjelmatyö 22(30) 6.2.2 Toimitettavat asiat Toimitettavat dokumentit Vaatimusmäärittely Edistymisraportti 6.2.3 Työtehtävät Taulukko 9: Suunnitellut työtehtävät PP-vaiheessa 6.3 Toteutus 1 6.3.1 Tavoitteet Ensimmäisen toteutusiteraation tärkein tavoite on toimittaa asiakkaalle ensimmäisen toimiva versio WTAS:sta, jossa vähintään kaikki prioriteettiluokan high käyttötapaukset on toteutettu (ks. vaatimusmäärittely). Jotta tämä olisi mahdollista ja projekti voisi edetä jatkossakin sujuvasti, täytyy seuraavien osatavoitteiden toteutua: Arkkitehtuurin suunnittelu ja toteutus
T-76.115 Tietojenkäsittelyopin ohjelmatyö 23(30) Ryhmän sisäisen koulutuksen viimeistely 6.3.2 Toimitettavat asiat Toteutettavat käyttötapaukset / ydinarkkitehtuuriosat UC 1.1 Log in UC 1.2 Log out UC 2.1 Report hours for a work category UC 3.1 View reported hours UC 4.1 Add user UC 4.4 View user list UC 5.1 Add work category Toimitettavat dokumentit Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Technical specification (englanniksi) Testitapausmäärittely Testausraportti Edistymisraportti
T-76.115 Tietojenkäsittelyopin ohjelmatyö 24(30) 6.3.3 Työtehtävät Taulukko 10: Suunnitellut työtehtävät I1-vaiheessa 6.4 Toteutus 2 6.4.1 Tavoitteet Toisen toteutusiteraation tärkeimmät tavoitteet ovat: Toimittaa asiakkaalle uusi versio WTAS:sta Toteuttaa leimaustoiminnallisuus (check in / check out) Kehittää raportointitoimintoa Lisäksi on sovittu asiakkaan kanssa, että iteraation puolen välin tienoilla pohditaan yhdessä seuraavia projektin loppuvaihetta koskettavia kysymyksiä: Lähdetäänkö tekemään erillistä client-ohjelmistoa extended check in / check out toimintojen toteuttamiseksi? Mitkä ovat UC 6.2-6.5 prioriteetit ja toteutetaanko niitä?
T-76.115 Tietojenkäsittelyopin ohjelmatyö 25(30) 6.4.2 Toimitettavat asiat Toteutettavat käyttötapaukset UC 2.6 View own reported hours UC 2.7 Delete reported hours UC 2.8 Change reported hours UC 2.9 Check in UC 2.10 Check out UC 2.13 Automated check in and check out UC 2.14-2.15 Extended check in and check out UC 2.16 Search own hours UC 3.2 Accept hours UC 3.3 Mark hours as billed UC 4.3 Assign user to one or more user groups UC 4.5 Delete user UC 4.6 Change user details UC 5.2 View work category list UC 5.3 Delete work category UC 5.4 Change work category details UC 5.8 Group work categories Toimitettavat dokumentit Edistymisraportti Käyttöohje Päivitetyt versiot aikaisemmista dokumenteista 6.4.3 Työtehtävät Trapolin ongelmien 30.11. takia alla I2-iteraation tehtävät on esitetty aikaisemmasta Trapoli-muodosta poiketen excel-taulukkona. Tehtäväjaon granulariteettia on myös hieman muutettu. I2:n aikana kokeillaan jakoa, jossa use caseja ei ole erikseen eritelty, vaan ohjelmointitehtävät on koottu isompien kokonaisuuksien alle. Tämän uskotaan parantavan tuntien raportoinnin mielekkyyttä (edellisen iteraation tarkempi use case pohjainen jako ei tuntunut realistiselta käytössä).
T-76.115 Tietojenkäsittelyopin ohjelmatyö 26(30) Tehtävä Työmäärä IM: Framework 16 IM: User-related functionality 40 IM: Check in / out related functionality 40 IM: Work time item related functionality 40 IM: Work category related functionality 50 GE:Meetings (status/mentor) 34 GE:Meetings (customer) 20 GE:Test server administration 12 GE:Work station / dev. environ. maintenance 24 PM:Personal SE practice 32 PM:Other project management 20 PM:Plan the next iteration 8 PM:Project review and preparation 16 PM:Update documentation 40 TE:Prepare testing 24 TE:Execute and report tests 16 Yhteensä 432 6.5 Toteutus 3 6.5.1 Tavoitteet Kolmannen toteutusiteraation tärkeimmät tavoitteet ovat: Toimittaa asiakkaalle uusi versio WTAS:sta, jossa olisi jo kaikki tämän projektin aikana toteutetuksi tarkoitetut merkittävät toiminnallisuudet. I3:n jälkeen olevassa toimitusiteraatiossa on tarkoitus keskittyä sovelluksen ja dokumentaation viimeistelyyn, bugien korjaukseen, käytettävyyden parantamiseen ja käytön virtaviivaistamiseen. Kehittää raportointitoimintoa Lisenssipolitiikan toteutus Käytettävyyden parantaminen (hyödyntäen mm. käytettävyystestin tuloksia): work category favorites toiminnon toteutus, tuntien massakirjauksen parantaminen, terminologia, jne. Lisäksi tavoitteena on järjestää iteraation aikana asiakkaan omaa testikäyttöä ja sen jälkeen yhteinen workshop projektiryhmän kanssa, jotta saadaan palautetta tässä iteraatiossa ja viimeisessä toimitusiteraatiossa tehtäviä käytettävyyden parantamisia varten. Samalla kun pohditaan käytettävyyden parantamista, huomataan mahdollisesti myös perustoiminnallisuutta koskevia ongelmia; näistä suurimmat on siten vielä mahdollista korjata iteraation lopussa tai toimitusiteraation aikana. Tarkoituksena on siis ylipäätään varmistaa, että toimitettava ohjelmisto vastaisi mahdollisimman hyvin asiakkaan tarpeita. Lisäksi testaamme peer-ryhmämme kanssa ristiin toistemme ohjelmistoja käyttäen Session-Based Exploratory Testing-metodia. Tulokset kirjataan raportteihin sekä ne myös käydään läpi erillisessä palaverissa. 6.5.2 Toimitettavat asiat Toteutettavat käyttötapaukset UC 2.3 View work category favorites
T-76.115 Tietojenkäsittelyopin ohjelmatyö 27(30) UC 2.4 Change work category favorites UC 3.4 Print reports UC 3.5 View extended report UC 3.6 Export report to CSV UC 3.7 View predefined report UC 4.2 Change a user s work category favorites UC 6.1 Change system configuration UC 6.2-6.5 Add/Change/Delete/View report templates UC 6.6 Change license details Peer-ryhmälle viimeistään 8.3. toimitettavat dokumentit Mistä järjestelmämme löytyy sekä järjestelmän sisäänpääsyyn vaadittavat tiedot (käyttäjätunnus ja salasana) Vaatimusmäärittely Käyttöohje Testitapausmäärittely Suositeltu vikaraportointitapa Lista avoimista bugeista Peer-ryhmälle viimeistään 12.3. toimitettavat dokumentit Testisessioiden raportit Testisessioista kerätty testausraportti Palautuksessa toimitettavat dokumentit Edistymisraportti Asennusohje Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty technical specification (englanniksi) Päivitetty testitapausmäärittely Testausraportti I3:sta Peer-ryhmältä saadut peer-testausdokumentit o Testisessioiden raportit o Testausraportti
T-76.115 Tietojenkäsittelyopin ohjelmatyö 28(30) 6.5.3 Työtehtävät Trapolissa ei vielä ollut käytettävissä I3:n raportteja, joten taulukko on jälleen esitetty Excelistä tuodussa muodossa (ks. myös 6.4.3 Työtehtävät). I2:ssa kokeiltiin granulariteetiltaan karkeampaa tehtävänjakoa, mikä osoittautui toimivaksi käytännöksi. I3:n tehtävät on siis jaettu vastaaviin kokonaisuuksiin kuin I2:ssa. Tehtävä Työmäärä IM:Work category related functionality 24 IM:Report related functionality 32 IM:Configuration related functionality 12 IM:Other programming 24 GE:Meetings (status/mentor) 24 GE:Meetings and other contacts (customer) 12 GE:Work station and test server maintenance 12 PM:Personal SE practice 20 PM:Other project management 12 PM:Plan the next iteration 4 PM:Project review and preparation 8 PM:Update documentation 24 TE:Prepare testing 14 TE:Execute and report tests 16 TE:Peer testing 12 Yhteensä 250 6.6 Toimitus Lopullinen toimitus. 6.6.1 Tavoitteet 6.6.2 Toimitettavat asiat 6.6.3 Työtehtävät 6.7 Jatkokehitys Tässä on listattu ominaisuuksia, joita on esitetty, mutta ei tulla tämän projektin puitteissa toteuttamaan: UC 2.11-2.12 Check in / check out together with login o Ulkoinen client on jo toteutettu, joten tälle ei liene suurta tarvetta UC 4.7-4.10 Add/view/delete/change user group o Dynaamisien käyttäjäryhmien toteuttamisen kustannus/hyöty-suhde ei ole järkevä.. Käyttäjiä voi jo ryhmitellä eri käyttäjäryhmiin (rooleihin), mutta ne ovat kiinteitä. Tuntuu, että kiinteä roolitus on täysin riittävä työajanseurantaohjelmiston tarpeisiin. Toiminto olisi työläs tehdä, ja tämänhetkisen (I2:n loppu) tiedon perusteella hyöty asiakkaalle olisi hyvin pieni ja tätä tarvittaisiin vain poikkeustapauksissa. Lisäksi ominaisuus myös monimutkaistaisi ohjelmiston käyttöä turhaan.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 29(30) UC 5.5-5.7, 5.9 Add/view/delete/change customer o Asiakas-roolille ei tämänhetkisen (I2:n loppu) tiedon perusteella tunnu olevan suurta tarvetta (tarkoittaa siis sitä, että tuntiseurantaa käyttävän yrityksen asiakkaat pääsisivät sisään järjestelmään). UC 7.1 View customer s report on a project o Asiakas-roolille ei tämänhetkisen (I2:n loppu) tiedon perusteella tunnu olevan suurta tarvetta (tarkoittaa siis sitä, että tuntiseurantaa käyttävän yrityksen asiakkaat pääsisivät sisään järjestelmään). 7. Riskienhallintasuunnitelma Projektin riskienhallintasuunnitelma on kirjattu erilliseen dokumenttiin (riskienhallintasuunitelma.rtf). I2:n palautuksesta lähtien riskienhallintasuunnitelman lisäksi on olemassa viisi erillistä dokumenttia (register.xls, riskit_executive_report.doc, riskit_riskaction.xls, risklist.xls ja kokemuksia.rtf), joihin on hajautettu osa riskienhallintasuunnitelman sisällöstä. Lisätietoja asiasta on riskienhallintasuunnitelmassa. 8. Koulutussuunnitelma Ryhmän jäsenten kokemus- ja osaamistausta on hyvin vaihteleva. Jotta varsinainen ohjelmointi voitaisiin toteuttaa tehokkaasti, on ryhmän jäsenten osaaminen keskeisimpiin teknologioihin ja työkaluihin liittyen saatava yhteiselle lähtötasolle. Tähän päästään ryhmän sisäisen koulutuksen avulla. Koulutus jakaantuu kolmeen viikon mittaiseen vaiheeseen, joista ensimmäinen toteutetaan PP-vaiheessa ja kaksi jälkimmäistä I1-vaiheessa. Marko toimittaa etukäteen ohjeet kunkin vaiheen suorittamiseen ja vastaa koulutuksen järjestämisestä ylipäätään. Ryhmän kaikki jäsenet osallistuvat koulutukseen. Koulutuksen vaiheet: Vaihe 1: itsenäistä perehtymistä käytettäviin teknologioihin o 20.10. 26.10. o itseopiskelua Vaihe 2: hands-on harjoittelu kehitysympäristössä o 27.10. 2.11 o itseopiskelua, tehtäviä o kaikilla kehitysympäristö tämän jälkeen toiminnassa Vaihe 3: arkkitehtuuri teoriassa ja käytännössä o 3.11. 9.11. o pidetään yhteinen koulutustilaisuus, joka yhdistetään Markon henkilökohtaiseen SEtehtävään koskien arkkitehtuurin arviointia Viitteet [1] SoberIT T-76.115 Software Project, http://www.soberit.hut.fi/t-76.115/, viittauspäivä 30.11.2003
T-76.115 Tietojenkäsittelyopin ohjelmatyö 30(30) Liitteet Requirements Document (vaatimusmäärittely) Versionhallintasuunnitelma Riskienhallintasuunnitelma Technology base Edistysmisraportti Technical Specification Test Cases Test Report Process Guide