Projektiryhmä Tete Työajanseurantajärjestelmä. Projektisuunnitelma

Transkriptio

1 Projektiryhmä Tete Työajanseurantajärjestelmä

2 T Tietojenkäsittelyopin ohjelmatyö 2(31) Muutoshistoria Versio PVM Tekijä Kuvaus Miikka Lötjönen Dokumenttipohja Niilo Fredrikson Ensimmäinen integroitu versio, johon koottu kaikki eri tekijöiden tekstit Niilo Fredrikson Ensimmäinen järkevä kokonaisuus, lisätty työmäärät yms Pauli Aho Korjauksia Niilo Fredrikson Pieniä ulkoasukorjauksia Mika Lindroos Siirretty riskienhallinta erilliseen dokumenttiin riskienhallintasuunnitelma.rtf Marc Josefsson Päivitys henkilökohtaisiin tavoitteisiin Niilo Fredrikson Lisätty koulutussuunnitelma, korjattu tavoitteita ja muutenkin viimeistelty palautusta varten Miikka Lötjönen Oikoluku/hyväksyntä toimitusta varten Niilo Fredrikson Seuraavan iteraation suunnittelua ja päivityksiä Niilo Fredrikson Korjauksia ja päivityksiä mm. mentorin kommenttien perusteella Miikka Lötjönen Oikoluku/hyväksyntä toimitusta varten Pauli Aho Hienosäätöä Niilo Fredrikson Päivitetty extended checkin/checkout I2:n toimitukseen

3 T Tietojenkäsittelyopin ohjelmatyö 3(31) Jaakko Nyrölä Muutettu testauksen hyväksymismäärittelyjä Niilo Fredrikson Päivitetty I3:n suunnitelmia Jaakko Nyrölä Päivitetty I3:n suunnitelmia peer-testauksen osalta, sekä yleistä aikataulua Niilo Fredrikson Pieniä korjauksia tyyleihin liittyen Niilo Fredrikson Päivitetty ajankäyttösuunnitelmat ja tehtävälistat sekä riskienhallintaosuutta Miikka Lötjönen Oikoluku/hyväksyntä toimitusta varten Mika Lindroos Dokumentin katselmointi ja korjaukset Niilo Fredrikson Päivitetty DE-iteraation suunnitelmia Mika Lindroos Oikoluku/hyväksyntä toimitusta varten Marko Nikula Oikoluku/hyväksyntä toimitusta varten

4 T Tietojenkäsittelyopin ohjelmatyö 4(31) Sisällysluettelo Muutoshistoria... 2 Sisällysluettelo Johdanto Projektin tarkoitus ja laajuus Järjestelmä ja käytetty ympäristö Oikeudet projektin tulosten käyttöön Sanasto ja määritelmät Henkilöstö ja asianosaiset Projektiryhmä Projektiryhmän tiedot Projektiryhmän jäsenet ja roolit (vastuut) Erityistyöryhmät projektiryhmän sisällä Muut asianosaiset Tavoitteet ja päättämiskriteerit Asiakkaan tavoitteet Projektiryhmän tavoitteet Projektin keskeyttämiskriteerit Projektin päättämiskriteerit Resurssit ja budjetti Henkilöstö Materiaali Budjetti Työkäytännöt ja työkalut Käytännöt Testaus Kokouskäytännöt Raportointi Dokumentointi Henkilökohtaiset SE-tehtävät Muut käytännöt Työkalut Standardit Projektin vaiheet... 20

5 T Tietojenkäsittelyopin ohjelmatyö 5(31) 6.1 Yhteenveto Projektin suunnittelu Tavoitteet Toteutus Tavoitteet Toimitettavat asiat Työtehtävät Toteutus Tavoitteet Toimitettavat asiat Työtehtävät Toteutus Tavoitteet Toimitettavat asiat Työtehtävät Toimitus Tavoitteet Toimitettavat asiat Työtehtävät Jatkokehitys Riskienhallintasuunnitelma Koulutussuunnitelma Viitteet Liitteet... 31

6 T Tietojenkäsittelyopin ohjelmatyö 6(31) 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 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 tapahtuvalle 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:a 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 tullessaan ja töistä lähtiessään; 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 on toteutettu myös erillinen client-ohjelma Windows-ympäristöön leimausten suorittamista varten. 1.3 Oikeudet projektin tulosten käyttöön Projektiryhmä ja asiakas sopivat projektin alussa tekevänsä erillisen sopimuksen immateriaalioikeuksista. Sopimus on allekirjoitettu ja siitä on asiakkaalla yksi kappale ja projektiryhmällä (projektipäälliköllä) yksi kappale. Lisäksi sopimuksesta on otettu 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

7 T Tietojenkäsittelyopin ohjelmatyö 7(31) 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

8 T Tietojenkäsittelyopin ohjelmatyö 8(31) 2.1 Projektiryhmä Projektiryhmän tiedot Ryhmän nimi: TeTe Sähköposti: nfredrik#cc.hut.fi Kotisivut: Projektiryhmä koostuu kahdeksasta Teknillisen korkeakoulun tietotekniikan osaston neljännen ja viidennen vuosikurssin opiskelijasta. Ryhmän kaikki jäsenet on esitelty alla aakkosjärjestyksessä 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: 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 myös vaatimusten- ja riskienhallintatyöryhmien toimintaan. Nimi: Fredrikson, Niilo Puhelin: 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ä , 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: 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.

9 T Tietojenkäsittelyopin ohjelmatyö 9(31) 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: 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: 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: 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: 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ä ja toimii tällä hetkellä tuotekehityspäällikkönä Ch5 Finland Oy:llä. Rooli ja vastuut: Testausvastaavan vastuualueena ovat testaukseen liittyvät prosessit. Jaakko osallistuu myös vaatimustenhallintatyöryhmän toimintaan. Nimi: Nyrölä, Jaakko Puhelin: 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ä.

10 T Tietojenkäsittelyopin ohjelmatyö 10(31) 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 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: Sähköposti: teppo.rinta-filppula#tamtron.fi Rooli: Asiakas Työn kuvaus: Toimitusjohtaja, seuraa projektin etenemistä ajoittain. Nimi: Leppäkoski, Mika Puhelin: 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 päättämiskriteerit 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ä

11 T Tietojenkäsittelyopin ohjelmatyö 11(31) 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 on 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 arvioi skaalautuvuutta subjektiivisesti käyttäen testitietokantaa, johon on tallennettu pk-yrityksen (n. 100 henkilöä) yhden vuoden kirjauksia vastaava tietomäärä. Mahdollisimman suuri riippumattomuus käytetystä tietokannasta, servletmoottorista, selaimesta, käyttöjärjestelmästä ja näiden versioista. Asiakkaan teknisen 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öä.

12 T Tietojenkäsittelyopin ohjelmatyö 12(31) 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ä 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 tavoitteen 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ä.

13 T Tietojenkäsittelyopin ohjelmatyö 13(31) 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. Ennen projektin mahdollista keskeytystä projektipäällikkö keskustelee asiakkaan, mentorin sekä kaikkien ryhmäläisten kanssa. Tämän jälkeen projekti keskeytetään, mikäli ei keksitä mitään keinoa sen jatkamiseen. 3.4 Projektin päättämiskriteerit Projekti päätetään 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

14 T Tietojenkäsittelyopin ohjelmatyö 14(31) Niilo Marko Tuomas Marc Jaakko Mika Pauli Miikka Yht. PP , ,5 I ,5 365,5 I2 42,5 39,5 43,5 78, ,5 85, I3 33, , DE 20 37,5 5,5 12, ,5 160 Yht 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, I1 346, I I DE Yht Lisäksi asiakkaalle koituu kehitysvaiheessa laitteistokustannuksia noin 1500 euron (+ ALV) edestä kehityspalvelimen hankinnan takia.

15 T Tietojenkäsittelyopin ohjelmatyö 15(31) 5. Työkäytännöt ja työkalut 5.1 Käytännöt 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 varmistetaan 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ä, että resurssienkäyttöä ei erikseen testata. Kukin ei-toiminnallisen ominaisuuden testaamisen vastuuhenkilö huolehtii ainakin yhden testisarjan luomisesta mittaamalleen ominaisuudelle. 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

16 T Tietojenkäsittelyopin ohjelmatyö 16(31) 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. Iteraatiossa I3 suoritettiin lisäksi vertaisryhmätestausta. Projektiryhmä Verkokauppa on projektiryhmämme vertaisryhmä, ja he suorittivat testauksen I3:n lopussa. DE-iteraation aikana käydään läpi heidän testauksen tulokset ja ryhdytään tarvittaessa korjaustoimiin. Ohjelmistoa testattiin käyttäen Session-Based Exploratory Testing-metodia. Tulokset kirjattiin raportteihin ja ne käydään myös läpi erillisessä palaverissa. Oma ryhmämme suoritti vastaavan testauksen Verkokaupan ohjelmistolle Kokouskäytännöt Projektiryhmä kokoontuu ainakin kurssin alkupuolella (PP-I1) T-talolla tiistaisin aikavälillä 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, kohdennetaan toimenpiteeseen 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 Raportointi Työajan raportointi tehdään kurssilla käytössä olevalla Trapoli-projektinhallintaohjelmistolla. 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.

17 T Tietojenkäsittelyopin ohjelmatyö 17(31) 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 Bugzilla-ohjelmistoa. Viat raportoidaan järjestelmään heti niiden löydyttyä prioriteeteittain ja järjestelmä välittää sähköpostiviestin eteenpäin kyseisestä viasta kyseisen toiminnallisuuden vastuuhenkilölle, projektipäällikölle tai koko ryhmälle. Ryhmäpalavereissa tai projektipäällikön toimesta 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 jokaisen 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 se palautetaan viimeisessä vaiheessa 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- tai PDF-muotoon 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. Valittujen käytäntöjen kokonaisuus auttaa omalta osaltaan 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ävyystesteillä 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äisten 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ä

18 T Tietojenkäsittelyopin ohjelmatyö 18(31) 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ä. Projektin etenemisen seuranta ja hallinta (Niilo): Projektipäällikkö joutuu jokaisen vaiheen palautuksen yhteydessä toimittamaan edistymisraportin, joten seuranta kuuluu luonnostaan hänen tehtäviinsä. 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 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

19 T Tietojenkäsittelyopin ohjelmatyö 19(31) Käyttötapausten käyttäminen Versionhallinta Koodauskonventiot Vertaisryhmätestaus vaiheessa I3 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 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

20 T Tietojenkäsittelyopin ohjelmatyö 20(31) 5.3 Standardit Projektia koskevien sähköpostiviestien otsikkoriville laitetaan aina tunniste [76.115] helpottamaan sähköpostien automaattista lajittelua. 6. Projektin vaiheet 6.1 Yhteenveto Taulukko 8: Projektin aikataulu PVM Iteraatio / tapahtuma (~4 viikkoa) Projektin suunnittelu (PP) alkaa Bitkeeper (versionhallinta) käytössä kaikilla Koulutuksen vaihe 1 alkaa / Koulutuksen vaihe 1 päättyy / vaihe 2 alkaa klo 15 Toimitus (dokumentit) Asiakkaan hankkima testipalvelin ryhmän käytettävissä klo 15 Projektikatselmus Toteutus 1 (I1) alkaa / Koulutuksen vaihe 2 päättyy / vaihe 3 alkaa Bugzilla (bugit/muutospyynnöt) otettu käyttöön klo 16 Koulutustilaisuus / arkkitehtuurin arviointi Koulutuksen vaihe 3 päättyy klo 15 Toimitus (dokumentit) klo 15 Projektikatselmus (10 viikkoa) Toteutus 2 (I2) Valikoidut I1:n aikana havaitut bugit korjattu Tuntien syöttämiseen liittyvät UC:t tehty Joululoma

21 T Tietojenkäsittelyopin ohjelmatyö 21(31) Leimaukseen liittyvät UC:t tehty Käyttäjiin liittyvät UC:t tehty Uutta toiminnallisuutta ei enää ohjelmoida Dokumentit valmiina, viimeistely ja oikoluku alkaa klo 15 Toimitus (dokumentit) klo 15 Projektikatselmus (5 viikkoa) Toteutus 3 (I3) klo 20 Statuspalaveri (IRC), töiden jako Asiakkaan testikäyttö käynnistyy klo 14 (alustava aika) Workshop käytettävyyden ja toiminnallisuuden parantamisesta Uudet toiminnallisuudet ohjelmoitu Testaus Bugien korjausta 8.3. klo 15 Toimitus (ohjelma testausta varten vertaisryhmälle) Palautettavien dokumenttien ensimmäiset versiot valmiina Peer-testaus dokumenttien toimitus peer-ryhmälle klo 10 Peer-testauksessa ilmenneiden kokemusten vertailupalaveri klo 15 Toimitus (dokumentit) klo 15 Projektikatselmus (3 viikkoa) Lopullinen toimitus (DE) Niilo on toimittanut jo etukäteen (ennen iteraation alkamista) tarkemmat ohjeet työnjaosta klo 17 Statuspalaveri T-talolla Kaikki toiminnallisuus valmiina Testaus

22 T Tietojenkäsittelyopin ohjelmatyö 22(31) Bugikorjaukset 5.4. Palautus 7.4. Viimeinen projektikatselmus 6.2 Projektin suunnittelu 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 Toimitettavat asiat Toimitettavat dokumentit Vaatimusmäärittely Edistymisraportti Työtehtävät Taulukko 9: Suunnitellut työtehtävät PP-vaiheessa

23 T Tietojenkäsittelyopin ohjelmatyö 23(31) 6.3 Toteutus Tavoitteet Ensimmäisen toteutusiteraation tärkein tavoite on toimittaa asiakkaalle ensimmäinen 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 Ryhmän sisäisen koulutuksen viimeistely 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

24 T Tietojenkäsittelyopin ohjelmatyö 24(31) 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 Työtehtävät Taulukko 10: Suunnitellut työtehtävät I1-vaiheessa

25 T Tietojenkäsittelyopin ohjelmatyö 25(31) 6.4 Toteutus 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 prioriteetit ja toteutetaanko niitä? 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 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

26 T Tietojenkäsittelyopin ohjelmatyö 26(31) Käyttöohje Päivitetyt versiot aikaisemmista dokumenteista Työtehtävät Trapolin ongelmien 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 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 pohjainen jako ei tuntunut realistiselta käytössä). 6.5 Toteutus 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

27 T Tietojenkäsittelyopin ohjelmatyö 27(31) 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 ja ne myös käydään läpi erillisessä palaverissa Toimitettavat asiat Toteutettavat käyttötapaukset UC 2.3 View work category favorites 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 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 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)

28 T Tietojenkäsittelyopin ohjelmatyö 28(31) Päivitetty testitapausmäärittely Testausraportti I3:sta Peer-ryhmältä saadut peer-testausdokumentit o Testisessioiden raportit o Testausraportti 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 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ä Toimitus Lopullinen toimitus. Tämän vaiheen jälkeen projekti päättyy Tavoitteet Toimitusiteraation tavoitteet on alla määritelty aiempia iteraatioita yksityiskohtaisemmin, koska kyseessä on projektin viimeinen vaihe. Tässä vaiheessa ei enää ole seuraavaa iteraatiota, jossa tarvittaessa voitaisiin korjata tässä iteraatiossa tapahtuvia poikkeamia suunnitelmasta. Toimitusiteraation tavoitteet ovat: 1. WTAS-ohjelmiston ja siihen liittyvän materiaalin lopullinen luovutus asiakkaalle 2. Asiakkaan edustajan/edustajien perehdytys käyttöön sekä arkkitehtuuriin 3. Ohjelmiston viimeistely: bugikorjauksia ja käytettävyysparannuksia 4. Dokumentaation viimeistely (mm. loppuraportti) 5. Pieniä parannuksia toiminnallisuuteen: a. Työlajien syöttämisen virtaviivaistaminen

29 T Tietojenkäsittelyopin ohjelmatyö 29(31) b. Ylläpitäjätoimintojen toteutus (ylläpitäjälle mahdollisuus muokata muiden käyttäjien tapahtumia) c. Leimausten pilkkominen tuntiensyöttönäkymässä d. Välisummat raportteihin e. Import-toiminto Tepon lähettämän formaatin mukaisesti f. Lisenssisysteemin asiakaskohtaisuus Prioriteetit ovat yllä olevan listan mukaisia, eli kohta 1 on tärkein ja kohta 5-f vähiten tärkeä Toimitettavat asiat Toteutettavat käyttötapaukset UC 2.17 View free slots for reporting hours UC 3.8 View object specific summary information in report UC 3.9 Change user s events UC 3.10 Import checkin/checkout data UC 5.10 Alternative view for adding work categories UC 6.6 Change licensing details o Implemented already in I3. Now a change is implemented: instead of general licensing keys, customer specific licensing keys should be used. Palautuksessa toimitettavat dokumentit Loppuraportti Kaikista aiemmin mainituista dokumenteista lopullinen versio Työtehtävät Tehtävä Työmäärä IM:Work category editing 10 IM:Report related functionality 10 IM:Administrator functionality 15 IM:Other programming 20 GE:Meetings (status/mentor) 18 GE:Meetings and other contacts (customer) 12 GE:Delivery to customer including training 12 PM:Personal SE practice 20 PM:Other project management 8 PM:Project review and preparation 12 PM:Update and finalize documentation 32 TE:Prepare testing 12 TE:Execute and report tests 20 Yhteensä 201

30 T Tietojenkäsittelyopin ohjelmatyö 30(31) 6.7 Jatkokehitys Tässä on listattu ominaisuuksia, joita on esitetty, mutta ei tulla tämän projektin puitteissa toteuttamaan: UC Check in / check out together with login o Ulkoinen client on jo toteutettu, joten tälle ei liene suurta tarvetta UC Add/view/delete/change user group o Dynaamisten 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. UC , 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 o itseopiskelua Vaihe 2: hands-on harjoittelu kehitysympäristössä o o itseopiskelua, tehtäviä