AgilElephant Projektisuunnitelma Tekijä: Juha Kaarlas Omistaja: ElectricSeven Aihe: Projektisuunnitelma Sivu 1 / 29
Dokumentin Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 1.0 2004-10-04 Ensimmäinen versio Juha Kaarlas 1.1 2004-10-10 Aikatauluja sekä henkilökohtaisia tavoitteita lisätty Juha Kaarlas 1.2 2004-10-11 Ensimmäinen iteraatiosuunnitelma tehty. Juha Kaarlas 1.3 2004-10-19 Lisätty otsikko riskilogille, SEPA-aiheita, hieman resursointia Juha Kaarlas 1.4 2004-10-26 Seurannasta ja kommunikoinnista Juha Kaarlas 1.5 2004-10-31 Laadunvarmistussuunnitelma lisätty, kappale 5.3 Juha Kaarlas 1.6 2004-11-01 Riskiloki Juha Kaarlas 1.7 2004-11-01 Päivitetty käytäntöjä ja riskejä Juha Kaarlas 1.8 2004-11-02 Katselmoinnin korjaukset Juha Kaarlas 1.9 2004-11-09 I1:n tavoitteet ja tehtävät lisätty, puutteita korjattu. Juha Kaarlas 2.0 2004-11-29 Lisätty CVS-ohjeistusta, riskiloki päivitetty. Juha Kaarlas 2.1 2005-01-09 Dokumentin rakennetta muutettu Esa Mommo 2.2 2005-01-16 I2-suunnitelma lisätty Juha Kaarlas 2.3 2005-01-17 Katselmointiohje uudistettu Heikki Salminen 2.4 2005-01-31 Päivämääriä muutettu, kirjattu toteutuneita riskejä Juha Kaarlas 2.5 2005-02-02 Virheellinen tavoite poistettu Juha Kaarlas 2.6 2005-02-08 Korjattu taulukon asettelua, päivitetty tuntibudjettia Juha Kaarlas 2.7 2005-02-17 FD-tavoitteet ja suunnitelma, lisätty uusi riski (#8) Juha Kaarlas 2.8 2005-03-12 Viimeinen revisio Juha Kaarlas Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Juha Kaarlas Tehtävä Projektipäällikkö Katselmoinnit Tämä dokumentti vaatii seuraavien henkilöiden katselmoinnin Nimi Pauli Vesterinen Heikki Salminen Tehtävä Katselmointi Katselmointi Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Aihe: Projektisuunnitelma Sivu 2 / 29
Nimi Projektiryhmä Tehtävä Aihe: Projektisuunnitelma Sivu 3 / 29
Sisällysluettelo 1. Esittely...6 1.1 Tarkoitus ja laajuus...6 1.2 Järjestelmä ja ympäristö...6 1.3 Terminologia ja viittaukset...6 2. Sidosryhmät ja henkilöstö...7 2.1 Projektiryhmä...7 2.2 Muut sidosryhmät...8 2.2.1 Asiakas...8 2.2.2 Kurssi...8 2.2.3 Järjestelmän jatkokehittäjät...8 2.2.4 Loppukäyttäjät...8 2.2.5 Vertaistestaajat...8 3. Tavoitteet ja kriteerit...9 3.1 Asiakkaan tavoitteet...9 3.2 Ryhmän tavoitteet...9 3.3 Henkilökohtaiset oppimistavoitteet...9 3.4 Projektin keskeyttäminen...10 3.5 Projektin päättäminen...10 4. Resurssit ja budjetti...11 4.1 Henkilöstö...11 4.2 Materiaalit...11 4.3 Budjetti...11 5. Käytännöt ja työkalut...12 5.1 Käytännöt...12 5.1.1 Iteratiivinen prosessi...12 5.1.2 Inkrementtien suunnittelu...12 5.1.3 Raportointi...13 5.1.4 Virheiden seuranta...13 5.1.5 Projektin seuranta...13 5.1.6 Dokumentointi...13 5.1.7 Kommunikaatio...14 5.1.8 Vaatimusten hallinta...15 5.1.9 Muutosten hallinta...15 5.1.10 Ohjelmointikäytäntö...16 5.1.11 Riskien hallinta...17 5.1.12 Vertaistestaus...17 Aihe: Projektisuunnitelma Sivu 4 / 29
5.2 SEPA yhteenveto...17 5.3 Laadunvarmistus...17 5.3.1 Automaattiset yksikkötestit...17 5.3.2 Käsin tehtävä toiminnallinen testaus...17 5.3.3 Staattiset menetelmät ohjelmakoodin analysoinnissa...17 5.3.4 Heuristinen käytettävyyden arviointi...18 5.4 Työkalut...18 5.5 Standardit...18 6. Aikataulu...19 6.1 Yleinen aikataulu, tavoitteet ja tehtävät...19 6.2 Projektin suunnittelu (28.9.- 4.11.2004)...20 6.2.1 Tavoitteet...20 6.2.2 Toimitettavat asiat...20 6.2.3 Tehtävät...20 6.3 Implementaatio 1 (5.11.- 2.12.2004)...21 6.3.1 Tavoitteet...21 6.3.2 Toimitettavat asiat...21 6.3.3 Tehtävät...21 6.4 Implementaatio 2 (7.1.2005 10.2.2005)...23 6.4.1 Tavoitteet...23 6.4.2 Toimitettavat asiat...24 6.4.3 Tehtävät...24 6.5 Viimeistely ja toimitus (11.2. 17.3.2005)...25 6.5.1 Tavoitteet...25 6.5.2 Toimitettavat asiat...26 6.5.3 Tehtävät...26 7. Riskiloki...28 7.1 Toteutuneet riskit...29 Aihe: Projektisuunnitelma Sivu 5 / 29
1. Esittely AgilElephant-projektin tarkoitus on kehittää Ohjelmatyökurssin puitteissa ketterään ohjelmistokehitykseen ja erityisesti SEMS-malliin [http://www.soberit.hut.fi/sems/info.html] sopiva ohjelmistoprojektien hallintatyökalu. 1.1 Tarkoitus ja laajuus AgilElephant-projektin tarkoitus on luoda hyvä pohja SEMS-mallin mukaiselle ohjelmistokehitystyökalulle. Järjestelmän laajuus tarkentuu projektin edetessä, alussa tiukin kriteeri on ohjelmatyökurssilla määritetty tuntibudjetti eli noin 190 h / henkilö ryhmän koostuessa seitsemästä henkilöstä. 1.2 Järjestelmä ja ympäristö Asiakaskriteerien mukaisesti järjestelmä on webbipohjainen ja se pohjautuu Java-kieleen ja ilmaisiin Java-teknologioihin. Aluksi järjestelmälle toteutetaan yksinkertainen selainkäyttöliittymä, mutta suunnittelussa otetaan huomioon myös rajapinnat mahdollisesti jatkokehityksenä tehtäviä muita käyttöliittymiä varten. Järjestelmän tavoitekäyttöympäristö on pk-yritys ja loppukäyttäjinä noin kymmenen hengen tuotekehitystiimit. 1.3 Terminologia ja viittaukset AgilElephant: järjestelmän nimi, ks. aiheen alkuperäinen kuvaus: http://www.soberit.hut.fi/~mrusama/rusama.htm Ohjelmatyökurssi 2004-2005: http://www.soberit.hut.fi/t-76.115/ SEMS: Software Engineering Management System: http://www.soberit.hut.fi/sems/info.html Pert-estimointi: Yksinkertainen tehtävien estimointimenetelmä. http://www.augustana.ca/~mohrj/courses/2004.winter/csc320/notes/project_mngmt.html Aihe: Projektisuunnitelma Sivu 6 / 29
2. Sidosryhmät ja henkilöstö Asiakas Kurssi Mikko Rusama Juha Itkonen Seppo Sahi Mentor Muu kurssihenkilökunta Electric Seven Juha Kaarlas Projektipäällikkö Rauli Ikonen Pasi Kallioniemi Petri Kalsi Esa Mommo Heikki Salminen Pauli Vesterinen 2.1 Projektiryhmä Ryhmän jäsenet ovat: Rooli Nimi Sähköposti Puhelin Projektipäällikkö, demopalvelimen Juha Kaarlas juha.kaarlas (ät) hut fi 050-3423 511 ylläpito Ohjelmoija, dokumentit, testaus Esa Mommo esa.mommo (ät) fi.ibm.com 040-5562 021 Tietokantaekspertti, SCM, QA Heikki Salminen heikki.salminen (ät) hut.fi 040-8221 657 Ohjelmoija, testaus, dokumentit Pauli Vesterinen pjvester (ät) cc.hut.fi 044-5372 260 Seniorohjelmoija/arkkitehti Pasi Kallioniemi pkallion (ät) cc.hut.fi 050-4033 396 QA, testaus, käyttöliittymä Petri Kalsi petri.kalsi (ät) iki.fi 040-7324 004 Seniorohjelmoija/arkkitehti, speksaus Rauli Ikonen rauli.ikonen (ät) hut.fi 040-8328 628 Taulukko 1: Projektiryhmä Ryhmän postituslista on osoitteessa ot (ät) thraexsoftware.com. Aihe: Projektisuunnitelma Sivu 7 / 29
2.2 Muut sidosryhmät 2.2.1 Asiakas Asiakkaana toimii SoberIT, jonka edustajina Mikko Rusama firstname.lastname@hut.fi 050-5722229 Juha Itkonen firstname.lastname@hut.fi 09-451 6041 2.2.2 Kurssi Teknillisen korkeakoulun tietojenkäsittelyopin ohjelmatyökurssi vuonna 2004-2005 : T-76.115 [http://www.soberit.hut.fi/t-76.115/]. Kurssihenkilökunta on esitelty sivulla http://www.soberit.hut.fi/t- 76.115/04-05/Personnel.html. 2.2.2.1 Mentor Mentor on erityinen osa kurssihenkilökuntaa, joka neuvoo ryhmää projektin edetessä sekä arvostelee ryhmää yhdessä asiakkaan kanssa. Ryhmän mentorina toimii Seppo Sahi (etunimi.sukunimi@hut.fi). 2.2.3 Järjestelmän jatkokehittäjät Jatkokehittäjät on kokoonpanoltaan tuntematon sidosryhmä, joka pitää ottaa huomioon järjestelmän kehitystyössä ja dokumentaatiossa. 2.2.4 Loppukäyttäjät Loppukäyttäjinä toimivat ainakin tuotepäälliköt, projektipäälliköt ja ohjelmoijat. 2.2.5 Vertaistestaajat Vertaistestauksen tekee toinen kurssia suorittava opiskelijaryhmä, joka on toistaiseksi tuntematon. Vertaistestaus tapahtuu 1.3. 8.3. 2005. Lopullisen järjestelmän ja sen testausohjeiden tulee olla valmiit 28.02.2005. Samoihin aikoihin oma ryhmämme testaa vertaisryhmän järjestelmää. Aihe: Projektisuunnitelma Sivu 8 / 29
3. Tavoitteet ja kriteerit 3.1 Asiakkaan tavoitteet Tavoite 1. Hyvä pohja SEMS-mallin mukaiselle projektinhallintatyökalulle. 2. Tehtävälistat Cycles of Controlviitekehyksen mukaisesti 3. Laadunvarmistuksen näkökulman esittäminen 4. Edistymisen seuranta 5. Helposti jatkokehitettävä, laadukas 6. Stabiilius 7. Riittävä suorituskyky 8. Helposti laajennettava 9. Raporttien luonti 10. Käytettävyys Taulukko 2: Asiakkaan tavoitteet Verifiointikriteeri Asiakkaan priorisoimat vaatimukset on toteutettu. Järjestelmä sisältää tehtävälistat eri aikajänteille. Järjestelmä sisältää laatutehtäviin liittyviä ominaisuuksia, esim. laadun tarkistuslistat ohjelmointitehtäville. Järjestelmä tarjoaa menetelmän arvioida ja päivittää tehtävien edistämistä ja seurata ajankäyttöä esim. burndown -graafilla. Järjestelmän arkkitehtuuri ja dokumentaatio tukevat jatkokehitystä. Järjestelmä ei saa hukata tai korruptoida tietoa eikä kaatua hyväksymistestauksessa. Suorituskyvyn on oltava riittävä noin 10 käyttäjän ryhmälle, eli muutamalle yhtäaikaiselle käyttäjälle. Arkkitehtuurin on tuettava laajennettavuutta; jatkokehitykselle tarjotaan ulkoiset rajapinnat. Järjestelmä sisältää tarpeeksi tietoa erilaisten raporttien generointiin (esim. käytetyt tunnit). Käyttöliittymän kehityksessä on käytetty heuristista arviointia. Eri käyttäjille näytetään kerralla vain olennaisimmat asiat. Asiakkaan hyväksyntä. 3.2 Ryhmän tavoitteet Tavoite 1. Saada AgilElephant valmiiksi ja tuntea tehneensä hyvän tuotteen. Verifiointikriteeri Asiakas hyväksyy lopullisen version. Ryhmä päättää onko tyytyväinen lopputulokseen vai ei. 2. Saada hyvä arvosana kurssista. Jokaisen kurssiarvosana on 3. 3. Ohjelmistotuotannon teorioiden soveltaminen käytännössä, uusien teknologioiden ja menetelmien oppiminen. Taulukko 3: Ryhmän yhteiset tavoitteet Järjestelmän kehityksessä käytetään jäsenille osittain uusia teknologioita. SEPA-harjoituksessa sovelletaan aiemmin opittuja tai nyt opeteltavia menetelmiä. 3.3 Henkilökohtaiset oppimistavoitteet Jotta kurssista saisi enemmän irti on jokaisella myös henkilökohtaisia oppimistavoitteita. Aihe: Projektisuunnitelma Sivu 9 / 29
Nimi Juha Kaarlas Esa Mommo Heikki Salminen Pauli Vesterinen Pasi Kallioniemi Petri Kalsi Rauli Ikonen Taulukko 4: Henkilökohtaiset tavoitteet Tavoitteet Kokeilla projektinhallintaa käytännössä erityisesti ketterän kehityksen näkökulmasta, organisoida työnjako ja seuranta tehokkaasti. Kokeilla, miten ajallisesti ja maantieteellisesti hajautetun ryhmän kommunikaatio ja yhteistyö saadaan toimimaan. Näkemystä ja kokemusta ohjelmistoprojektin hoitamisesta hajautetussa ympäristössä sekä yleisesti tietoa ketteristä menetelmistä ja kokemuksia niistä käytännössä. Java-tekniikkoihin, mm. J2EE:iin, perehtyminen. Laadunvarmistuksen ja konfiguraationhallinnan suunnittelu. Automaattisen testauksen opettelu työelämä ja käytännöllisyys mielessä pitäen. Moderneihin Java-teknologioihin tutustuminen. Saada kokonaisvaltainen kuva "oikean" ohjelmiston kehittämisen eri vaiheista, sekä siitä miten ohjelmistoa kehitetään ryhmässä. J2EE sekä beanit ja serveripuolen opetteleminen ovat myös listalla tavoitteissa. Oppia toimimaan projektiryhmän jäsenenä. Oppia uusia teknologioita. Oppia arkkitehtuurin suunnittelua. Saada kokemusta ohjelmistontuotantoprojekteista ja ketteristä menetelmistä käytännössä, projektissa käytettävien Java-tekniikoiden (erityisesti J2EE) oppiminen. Oppia toimimaan projektiryhmän jäsenenä. Oppia uusia teknologioita. Oppia arkkitehtuurin suunnittelua. 3.4 Projektin keskeyttäminen Projektin keskeyttämisen harkitseminen tulee ajankohtaiseksi, jos ryhmän pääluku vähenee kahdella ja ryhmän mielestä jäljellä olevia tehtäviä ei pystytä hoitamaan vajaalla miehityksellä. Projektin keskeyttämisestä päättää koko ryhmä. 3.5 Projektin päättäminen Projekti päättyy viimeistään, kun kurssi päättyy, eli 15.3. 2005. Aikaisempi päättäminen vaati, että 1. Järjestelmä ja sen tekninen dokumentaatio on toimitettuna asiakkaalle. 2. Asiakas on hyväksynyt järjestelmän. 3. Kurssin vaatimat dokumentit ja raportit on toimitettu. 4. Vertaistestaus on suoritettu ja sen palaute toimitettu. Aihe: Projektisuunnitelma Sivu 10 / 29
4. Resurssit ja budjetti 4.1 Henkilöstö Juha Esa Heikki Petri Pauli Pasi Rauli Yht PP 50 45 40 45 45 45 45 315 I1 45 45 45 45 45 45 50 320 I2 50 50 55 50 50 55 50 360 FD 51,5 64 44 55 75 73,5 32 395 Yht. 190 190 190 190 190 190 190 1330 Taulukko 5: Tuntibudjetti, FD-rivi ja tavoitesummat ajan tasalla 4.2 Materiaalit Projektin materiaaliset tarpeet ovat lähinnä palvelinkoneita: Palvelin yöllisiä buildeja varten (bannedwagon.net) CVS-palvelin (qa.soberit.hut.fi) Ryhmällä on käytössään myös projektin aihepiiriä käsittelevää kirjallisuutta: Pacing Software Product Development: A Framework and Practical Implementation Guidelines (2nd printing). Helsinki University of Technology, Software Business and Engineering Institute, Technical Reports 3. K. Rautiainen and C. Lassenius (editors). Espoo: Otamedia Oy, 2004 [4 kpl] 4.3 Budjetti Suunnitteluvaiheessa projektille ei ole nähtävissä rahallista budjettia. Suurin menoerä on eri sidosryhmien projektiin käyttämä aika. Mikäli projektin jäsenten tuntipalkaksi kuviteltaisiin esim. 40 tulisi AgilElephant 1.0:n hinnaksi arvioidulla 1330 tunnin ajankäytöllä 53 200. Aihe: Projektisuunnitelma Sivu 11 / 29
5. Käytännöt ja työkalut 5.1 Käytännöt 5.1.1 Iteratiivinen prosessi Projektin prosessimalli on ketterä ja iteratiivinen ohjelmistokehitysmalli. Ryhmä käyttää projektissaan SEMS-projektimallia, joka on yhteensopiva kurssin vaatimusten kanssa. 5.1.1.1 Inkrementit SEMS-mallin määrittämät inkrementit ovat synkronisoituja kurssin iteraatioiden kanssa. Inkrementtien jaottelu ja aikataulu on esitetty seuraavassa taulukossa. Inkrementtien sisältöön on kurssivaatimusten lisäksi sisällytetty asiakkaan kanssa sovittuja tehtäviä. Inkrementtien tavoitteet ja tuotokset on tarkemmin määritelty luvussa 6.2. Inkrementti PP: Projektin suunnittelu Aikaväli 28.9.- 4.11.2004 (5 viikkoa) I1: Implementaatio 1 5.11.- 2.12.2004 (4 viikkoa) I2: Implementaatio 2 7.1.2005-10.2.2005 (5 viikkoa) FD: Viimeistely ja 11.2.- 17.3.2005 (5 viikkoa) toimitus Taulukko 6: Inkrementtiaikataulu 5.1.1.2 Asiakaspalaute Asiakkaan näkökulmaa tullaan kuulemaan suunnittelu- ja seurantapalavereissa ja yksityiskohtien osalta aina tarvittaessa. Seurantapalavereita pidetään n. 2 kpl per inkrementti. 5.1.1.3 Opittujen asioiden soveltaminen tulevissa inkrementeissä Käytäntöjen suunnittelulla pyritään luomaan projektille vahva pohja heti suunnitteluvaiheessa. Käytäntöjä pyritään jalostamaan jatkuvasti. Huonosti toimiviksi todettuja käytäntöjä pyritään parantamaan tai jopa poistamaan tulevissa inkrementeissä. Hyväksi havaitut käytännöt pidetään käytössä sellaisenaan, ellei niihin keksitä parannuksia 5.1.2 Inkrementtien suunnittelu Inkrementtien alussa päätetään yhdessä asiakkaan kanssa siinä toteutettavat ominaisuudet. Asiakas priorisoi haluamiaan ominaisuuksia ja projektiryhmä noudattaa priorisointia. Mikäli kaikkia suunniteltuja tehtäviä ei ehditä suorittaa yksittäisen inkrementin aikana, mietitään mitkä siirretään mahdollisesti seuraavaan inkrementtiin. Koska varsinaisia implementaatiosyklejä on vain kaksi kappaletta (I1 ja I2) ja viimeinen inkrementti on järjestelmän stabilointia varten, pitää I2:sta FD:hen siirrettävien tehtävien olla hyvin perusteltuja. Aihe: Projektisuunnitelma Sivu 12 / 29
5.1.3 Raportointi 5.1.3.1 Tehtävät Projektipäällikkö ylläpitää tehtävälistaa omassa Excel-taulukossa (burndown -graafia ja muita metriikoita varten) sekä Trapolissa. 5.1.3.2 Raportit Käyttämäämme SEMS-ohjelmistokehitysmalliin kuuluvat ns. sykäykset, jotka määritetään projektille sopivaksi. Pienin aikaväli on vuorokausi ja se sopisi täysipäiväisesti samoissa tiloissa työskentelevälle tiimille. Viikon väli on jo hieman SEMS-ideologian vastainen, joten ajallisesti hajautuneessa projektissamme raportointi tapahtuu kaksi kertaa viikossa: maanantaina ja perjantaina. Raportointipäivinä kukin ryhmän jäsen lähettää projektipäällikölle lyhyen sähköpostin (myös muu kommunikaatio käy). Sykäysraportti sisältää kaikessa lyhykäisyydessään seuraavat asiat: mitä tein ja kuinka kauan mitä tehtäviä on jäljellä ja niiden aika-arviot mahdolliset ongelmat Sykäysraportin lisäksi kukin päivittää tuntinsa Trapoliin. Projektipäällikkö päivittää raporttien perusteella omaa tehtävälistaansa ja suorittaa ohjaavia toimenpiteitä kuten ongelmien ratkomista, tehtävien priorisointia ja uusien tehtävien antamista. 5.1.3.3 Ohjaavat toimenpiteet Projektipäällikkö päättää viime kädessä ohjaavista toimenpiteistä painottaen ryhmän mielipidettä ja asiantuntemusta. Yleistä käytäntöä eri toimenpiteille ei ole. Poikkeuksena on riskien toteutuminen, jolloin edetään riskienhallintasuunnitelman mukaisesti. 5.1.4 Virheiden seuranta Projektin toisen vaiheen aikana otetaan käyttöön vikojenhallinta- ja seurantajärjestelmä (defect tracking system). Järjestelmänä käytetään Bugzillaa, koska se on ryhmälle entuudestaan tuttu ja se on helpoiten saatavilla. Järjestelmän käyttöönottohetkestä päätetään toisen vaiheen (I1) aikana. Tarkoituksena on välttää suuren itsestäänselvien bugien tai puutteiden määrän kirjaaminen. 5.1.5 Projektin seuranta Materiaalin keräämisestä ja valmistelusta seurantaraportteihin huolehtii pääasiassa projektipäällikkö, joka voi kuitenkin pyytää tarvitsemaansa dataa ryhmän muilta jäseniltä. Projektipäällikkö huolehtii myös asiakkaan informoimisesta. 5.1.6 Dokumentointi Yleinen vastuu dokumenttien ylläpidosta on Esa Mommolla ja Pauli Vesterisellä. Vastuu käsittää kirjoitusvaiheessa dokumenttien kokoamisen ja päivittämisen. Poikkeuksia ovat muiden projektin jäsenten rooleihin liittyvät dokumentit kuten konfiguraationhallinta, arkkitehtuuri ja testaussuunnitelma. Taulukko 7: Dokumenttien vastuut. Aihe: Projektisuunnitelma Sivu 13 / 29
Dokumentti Vastuuhenkilö(t) Kieli Katselmoija(t) Dokumenttipohja Esa Mommo Suomi Ei katselmointia Projektisuunnitelma Juha Kaarlas Suomi Vaatimusdokumentti Esa Mommo Englanti Heikki Salminen, Pauli Vesterinen Rauli Ikonen, Pasi Kallioniemi Testaussuunnitelma Heikki Salminen, Petri Kalsi suomi Esa Mommo Testiraportit ja testiloki Petri Kalsi Suomi Ei katselmointia Käyttötapausdokumentti Heikki Salminen Englanti Esa Mommo Ohjelmointiohjesääntö Esa Mommo Suomi Ei katselmointia Arkkitehtuuri ja tekninen spesifikaatio Rauli Ikonen, Pasi Kallioniemi Englanti Juha Kaarlas Käyttöohje Pauli Vesterinen Englanti Juha Kaarlas Taulukko 7: Dokumenttien vastuut Projektin sisäisten dokumenttien formaattina käytetään tarkoitukseen sopivaa MS Office 2003 formaattia. Järjestelmän käyttöohje toteutetaan HTML:nä. Jatkokehitystä varten tuotettu dokumentaatio kirjoitetaan englanniksi ja julkaistaan PDF- tai HTML-muodossa asiakkaan toiveiden mukaisesti. Dokumenttien toimitusajankohdat käyvät ilmi projektin aikataulusta. 5.1.7 Kommunikaatio 5.1.7.1 Sisäinen Yleisenä kommunikaatiokanavana toimii ryhmän sähköpostilista. Sähköpostiviestin otsikko-kentän alussa on tagi [AgilElephant] postien helppoa tunnistamista varten. Posteissa esitetyt kysymykset tulee kuitata arkipäivisin 24 h kuluessa. Soittopyynnöt ovat yleensä kiireellisiä asioita varten ja sen takia niihin tulee vastata mahdollisuuksien mukaan samana päivänä, kuitenkin viimeistään 24 h kuluessa. Vaihtoehtoinen media on ryhmän oma IRC-kanava (#norsu @ irc.bannedwagon.net:8000). IRC-kanavalla kannattaa sopia kiireellisistä asioista varsinkin isommalla porukalla. Ryhmä on jakautunut töiden ja SEPA-aiheiden osalta pareihin (poislukien projektipäällikkö). Parit järjestävät kommunikaationsa parhaiten katsomallaan tavalla. Kokouksia koko ryhmälle järjestetään tarpeen mukaan. Ennalta nähtäviä kokouksia ovat iteraatioiden seuranta- ja suunnittelupalaverit. 5.1.7.2 Ulkoinen Yhteydenpito asiakkaaseen, mentoriin, kurssiin ja vertaisryhmään on oletusarvoisesti projektipäällikön tehtävä. Hänen vastuullaan on pitää tarvittavat sidosryhmät ajan tasalla toimittamalla materiaalia ja tiedottamalla tärkeistä asioista. Sähköpostin [AgilElephant]-tagia käytetään erityisesti asiakkaalle lähetettävissä sähköposteissa. Aihe: Projektisuunnitelma Sivu 14 / 29
5.1.8 Vaatimusten hallinta Projektin ensimmäisessä vaiheessa (PP) kerätään tuotteen tärkeimmät vaatimukset epämuodollisella tavalla dokumentiksi. Toisessa vaiheessa (I1) ilmi tulevista (kolmannessa vaiheessa toteutettavista) vaatimuksista aletaan pitää kirjaa formaalina Excel-taulukkona. Vaatimukset priorisoidaan ja numeroidaan. Dokumentin tarkkaa muotoa ei suunnitella etukäteen, vaan sen annetaan muotoutua vähitellen. 5.1.9 Muutosten hallinta Projektin toisen vaiheen aikana (mahdollisesti samaan aikaan Bugzillan kanssa) otetaan käyttöön muutostenhallinta. Työkaluna käytetään Excel-taulukkoa. Taulukkoon kirjataan yksittäiset tekniset muutokset. Muutokset numeroidaan ja niihin merkitään, mihin vaatimukseen/iin ne liittyvät. 5.1.9.1 Versionhallinta Projektissa käytetään versionhallintajärjestelmää. Versiokanta pystytetään heti projektin alussa. Järjestelmänä on CVS, koska se on ryhmälle entuudestaan parhaiten tuttu ja sille on paras työkaluintegrointi (mm. Eclipse-plugin). Järjestelmällä hallitaan myös kaikkien dokumenttien, käännösskriptien ja asetustiedostojen versioita. Tekstimuotoisiin dokumentteihin lisätään CVS-avainsanoista muodostuva otsake, mutta lähdekooditiedostoihin ei. Projektinhallintadokumentit tallennetaan binäärimuodossa ilman avainsanoja. Asiakkaalle toimitettava dokumentaatio tallennetaan asiakkaan toivomassa tekstipohjaisessa muodossa (ilmeisesti HTML) rivitettynä siten, että muutosten seuraaminen diff-ohjelmalla on havainnollista. Automaattisen build-prosessin käyttämät versiot merkitään CVS-tagilla, joka on muotoa b###, missä # on buildin järjestysnumero (esim. b007). Asiakkaalle toimitettavat ja järjestelmätestauksessa käytettävät versiot tunnistetaan näiden tagien perusteella. 5.1.9.1.1 Muutamia CVS-ohjeita 1. Aina kommitoitaessa on pyrittävä kohtalaisen mielekkäästi kertomaan mitä ja miksi siinä on muutettu. Suuriin yksityiskohtiin ei tarvitse mennä varsinkaan jos muutokset ovat itsestäänselviä. 2. Kohtaan 1 liittyen, usean (kymmenen) tiedoston kommitoiminen jollain yleispätevällä kommentilla on kielletty. 3. Kaikki kommentit englanniksi mahdollista jatkokehitystä silmällä pitäen. 4. Muutokset tulee kommitoida mahdollisimman usein eikä lojuttaa valmista koodia omalla koneella. 5. Kommitoitavan koodin pitäisi kääntyä ja mielellään toimia tai jos se ei toimi niin siitä pitää olla selkeä merkintä. Toimimaton koodi voi olla esim. kommentoitu pois niin että se ei tee mitään. Näin yhdessä kohdan 4 kanssa vältetään se, että koodit hukkuvat levyrikon tai jumalallisen väliintulon sattuessa, sekä se, että kaksi henkilöä työstää samaa koodia koska eivät tiedä sen olemassaolosta. 5.1.9.2 Buildien hallinta Versiokannasta tehdään automaattinen ajastettu build vähintään kerran vuorokaudessa. Ajankohta pyritään valitsemaan niin, että versiokantaa käytetään silloin mahdollisimman vähän (todennäköisesti myöhäinen aamuyö tai varhainen aamu). Samassa yhteydessä ajetaan kaikki automatisoidut testit. 5.1.9.3 Versiomuutosten seuranta Projektin neljännessä vaiheessa (FD) kaikkiin versionhallintajärjestelmiin tallennettaviin muutoksiin liitetään muutoksenhallintaan viittaava tunniste. Bugikorjauksissa tunnisteena toimii bugin id, muissa Aihe: Projektisuunnitelma Sivu 15 / 29
muutoksissa muutostenhallintadokumentin tunniste. Tunniste kirjataan commitin yhetydessä CVSkommentin alkuun. 5.1.9.4 Koodikatselmoinnit Katselmoinnin tavoitteena on varmistaa, että korjausten ja pienten muutosten mukana ei synny uusia vikoja. Osittain kyse on myös manuaalisen toiminnallisen testauksen tarpeen minimoimisesta. Alkuperäisestä suunnitelmasta poiketen kaikkia koodimuutoksia ei katselmoida vielä vaiheessa I2. Tämä johtuu siitä, että koodiin tehdään edelleen suuria toiminnallisia muutoksia ja isoja uusia toimintoja, joiden katselmoiminen olisi työläämpää kuin kattava testaaminen. Vaiheessa I2 katselmoidaan korjaukset ja pienehköt muutokset toimintaan, mutta muuttuneista vaatimuksista johtuvat laajat muutokset ja uusi koodi jätetään katselmoimatta. Vastaavasti laajat muutokset ja uudet toiminnot pyritään testaamaan kattavalla toiminnallisella testauksella ja yksikkötesteillä, mutta pienemmissä muutoksissa ja korjauksissa tyydytään kevyempään testaukseen ja pidetään pääpaino katselmoinnissa. Vaiheessa FD kaikki muutokset katselmoidaan. Muutetuille tiedostoille nimetään tarvittaessa (projektipäällikön harkinnan mukaan) katselmoija. Ellei näin tehdä, tiedoston seuraavan muokkaajan tulee katselmoida edelliset muutokset, jos tähän on suinkin aikaa. Muutoksen tekijä voi myös pyytää katselmointia keneltä tahansa. Katselmointi tehdään alkuperäisen suunnitelman mukaisesti vertaiskatselmointina eli katselmoija on toinen, kyseisen ajueen mahdollisimman hyvin tunteva koodaaja. Jos katselmoinnin yhteydessä havaitaan mahdollinen virhe, katselmoijan kertoo asiasta muutoksen tekijälle ja he käyvät tapauksen yhdessä läpi. Jos virhe osoittautuu todelliseksi, korjauksen tekee joko katselmoija ja alkuperäisen muutoksen tekijä, kumpi sattuu olemaan käytännöllisempää. Korjaus katselmoidaan uudelleen. Uudelleenkatselmoinnin tekee em. kahdesta henkilöstä se, joka ei tehnyt muutosta. Katselmoinneista pidetään lokia. Loki tallennetaan tekstitiedostona nimellä koodikatselmointi.txt CVS:n docs-haaraan. Lokiin merkitään jokaisen katselmoinnin yhteydessä katselmoija, päivämäärä ja aika, katselmoitava(t) tiedosto(t) CVS-versionumeroineen sekä katselmoinnin tulos. Jos mahdollisia virheitä ei löydetä, tulokseksi riittää pelkkä "ok". Jos katselmoija havaitsee mielestään mahdollisen virheen, se merkitään lokiin, vaikka se myöhemmin osoittautuisikin aiheettomaksi. Myös todellisten virheiden ja niiden korjauksen yksityiskohdat sekä korjausten uudelleenkatselmoinnit kirjataan. Katselmointi tehdään graafisen diff-työkalun avulla vertaamalla uusinta (muutettua tai korjattua) versiota edellsieen katselmoituun tai testattuun versioon. Useampia samaan tiedostoon kohdistuvia peräkkäisiä muutoksia voidaan katselmoida kerralla, jotta tiedostojen CVS-committeja ei tarvitsisi turhaan lykätä. Kuitenkin pyritään siihen, että aktselmoimattomia muutoksia ei otettaisi perusteellisiin toiminnallisiin testeihin tai uusien suurempien muutosten pohjaksi. Katselmointia varten ei toimiteta erillistä tarkistuslistaa, koska katselmointi koskee vain muutoksia. Virhekorjauiksien yhteydessä katselmoijan on tärkeää tietää tarkkaan, millaisesta viasta oli kyse. Katselmoijan on luettava vian Bugzilla-tiedot tarkkaan ja tarvittaessa pyydettävä lisätietoja vian raportijalta tai yritettävä toistaa bugi. Kallioniemi ja Ikonen tekevät SEPA-työhönsä liittyen laajempia koodikatselmointeja, jotka koskevat kokonaisia tiedostoja ja toiminnallisia kokonaisuuksia, eivät pelkkiä muutoksia. Niiden avulla pyritään arvioimaan myös koodin yleistä laatua laajemmin. 5.1.10 Ohjelmointikäytäntö Ohjelmakoodin kirjoittamiseen liittyvät käytännöt on määritelty dokumentissa AgilElephant Ohjelmointiohjesääntö. Aihe: Projektisuunnitelma Sivu 16 / 29
5.1.11 Riskien hallinta Riskien tunnistaminen tehdään yhteistyössä ja havaitut riskit toimintasuunnitelmineen kirjataan riskilokiin. Riskilokia päivitetään aina uusien riskien ilmetessä. Riskiloki käydään perusteellisemmin läpi aina uuden inkrementin alkaessa. 5.1.12 Vertaistestaus Vertaistestaus suunnitellaan erikseen vertaisryhmältä saatavien ohjeiden ja kurssin vaatiman käytännön mukaisesti. Vertaistestaus keskittynee käyttöliittymäpohjaiseen testaukseen. 5.2 SEPA yhteenveto Aihe Vastuullinen henkilö Soveltamisaika Edistymisen seuranta ja ohjaaminen Juha Kaarlas I1 - FD Staattinen koodianalyysi Rauli Ikonen ja Pasi Kallioniemi I1 - FD Automatisoidut yksikkötestit Petri Kalsi ja Heikki Salminen I1 - FD Heuristinen analyysi Pauli Vesterinen ja Esa Mommo I1 - FD Taulukko 8: SEPA-aiheet 5.3 Laadunvarmistus Laadunvarmistus- ja testaussuunnitelma tulee omaan dokumenttiinsa: Testaussuunnitelma.doc Laadunvarmistukseen ja testaukseen käytetään alla lueteltuja menetelmiä. 5.3.1 Automaattiset yksikkötestit Yksikkötestaus tehdään järjestelmän tärkeimmälle matalan tason toiminnallisuudelle ja ulkoisille rajapinnoille. Yksikkötestien kirjoittamiselle rajataan kiinteä osa vastaavan toiminnallisuuden implementointiin kuluvasta ajasta. Testeissä pyritään keskittymään luokkien tärkeimpään toiminnallisuuteen, niin että samalla saavutetaan kohtuullinen lausekattavuus muutamalla testitapauksella. Testit ajetaan joka yö automaattisen buildin yhteydessä. 5.3.2 Käsin tehtävä toiminnallinen testaus Pääosa toiminnallisesta testauksesta tehdään käsin. Testitapauksista ylläpidetään kompaktia listaa Excel-taulukkona. Testitapausten kuvaus, suoritusohje ja toivottu lopputulos pidetään yksinkertaisena ajan säästämiseksi, sillä testien suunnittelija ja suorittaja on sama henkilö. Osa näin säästetystä ajasta käytetään laadukkaisiin bugiraportteihin, joihin kirjataan tarkka toistosekvenssi, havaittu lopputulos sekä testaajan odottama lopputulos. 5.3.3 Staattiset menetelmät ohjelmakoodin analysoinnissa Ohjelmakoodista generoituja tunnuslukuja, kuten metodien pituutta ja kompleksisuutta analysoimalla pyritään löytämään kohtia koodista, joissa virheiden esiintymistodennäköisyys on erityisen suuri. Aihe: Projektisuunnitelma Sivu 17 / 29
5.3.4 Heuristinen käytettävyyden arviointi Varsinaiseen käyttäjien kanssa tehtävään käytettävyystestaukseen ei ole aikaa, joten käytettävyyttä pyritään arvioimaan heuristiikkojen avulla. 5.4 Työkalut Käytettäviä ohjelmistotyökaluja ovat Eclipse 3.0 Java Development Kit 1.4 JBoss 4.0 (sis. Tomcat) Hibernate CVS versio 1.11.17 Bugzilla (kurssin tarjoama) Ant 1.6.2 CruiseControl 2.1.6 TikiWiki 1.8.3 Trapoli MySQL 4.0 (saattaa muuttua projektin edetessä) 5.5 Standardit Projektille ei toistaiseksi ole määritetty noudatettavia standardeja. Aihe: Projektisuunnitelma Sivu 18 / 29
6. Aikataulu 6.1 Yleinen aikataulu, tavoitteet ja tehtävät Päivämäärä Tapahtuma Ti 12.10. DL 13:00 Postita iteraation suunnitelma (6.1 & 6.2) mentorille ja asiakkaalle. Ke 27.10. Seurantakokous asiakkaan kanssa. Toimita vaatimusdokumentti ja tekniikkademo. Ti 2.11. PP-iteraation dokumenttien ja raporttien toimittaminen kurssille. Ke 3.11. Projektin seuranta kurssin kanssa klo 16.00. Ti 9.11. DL 13:00 Postita iteraation suunnitelma (6.1 & 6.3) asiakkaalle ja mentorille. Ke 17.11. Käyttöliittymän HTML-prototyyppi asiakkaalle kommentoitavaksi To 25. 11 Tilannekatsaus asiakkaan kanssa klo 13-15 Ma 29.11. DL 13:00 Iteraation dokumenttien ja raporttien toimitus kurssille Ke 1.12. Projektin seurantapalaveri klo 16.00 To 2.12. Implementoidun ympäristön toimittaminen asiakkaalle 3.12.-6.1. Joululoma Ti 11.1. Ti 8.2. Ma 14.2. DL 13:00 Postita iteraation suunnitelma (6.1 & 6.4) asiakkaalle ja mentorille. DL 13:00 Iteraation dokumenttien ja raporttien toimitus kurssille 9-10 Projektin seurantapalaveri To 17.2. Ti 1.3. Ti 8.3. Ti 15.3. 16. 17.3. 8-18 Loppudemot DL 13:00 Postita iteraation suunnitelma (6.1 & 6.5) asiakkaalle ja mentorille. DL 13:00 Toimita lopullinen järjestelmä ja sen dokumentaatio vertaisryhmälle testausta varten. DL 13:00 Raportoi testitulokset vertaisryhmän järjestelmästä. DL 13:00 Iteraation dokumenttien ja raporttien toimittaminen kurssille. Taulukko 9: Yleinen aikataulu ja tärkeimmät tapahtumat Aihe: Projektisuunnitelma Sivu 19 / 29
6.2 Projektin suunnittelu (28.9.- 4.11.2004) 6.2.1 Tavoitteet Ensimmäisen inkrementin tavoitteet ovat: Projektin määrittely ja organisointi Alustavan projektisuunnitelman kirjoittaminen Alustavat vaatimusmäärittelyt ja tärkeimmät käyttötapaukset SEPA-aiheiden valinta Teknologia-alustan valinta Teknologiademo 6.2.2 Toimitettavat asiat Projektisuunnitelma (pl. 5.3 Laadunvarmistus) Vaatimusmäärittelydokumentti (kappaleet 1-5, 6-9, 11-12) Edistymisraportti SEPA-päiväkirjat (kappaleet 1, mahdollisesti 2-3) Teknologia-alustan demoaminen asiakkaalle 6.2.3 Tehtävät Taulukko 10 on yhteenveto ensimmäisen inkrementin tehtäväsuunnitelmasta (snapshot ajan hetkestä 2004-10-11). Kolmanteen sarakkeeseen on laskettu aika-arviot yhteensä koko ryhmälle per tehtäväkategoria. Tehtävä Aloituspäivä Aika-arvio yht. (h) DS:Study domain X 1) 28.09.2004 21 GE:Lectures 28.09.2004 45 GE:Meetings (status/mentor) 28.09.2004 15 PM:Adopt tool X (e.g. CVS) 2) 28.09.2004 15 PM:Plan work methods and tools 28.09.2004 15 PM:Personal SE practice 1.10.2004 14 PM:Risk management 1.10.2004 5 PM:Write the project plan 1.10.2004 15 PM:Project review and preparation 3.11.2004 7 DS:Req. documentation 7.10.2004 35 DS:Req. elicitation and analysis 7.10.2004 6 DS:Technology demo 8.10.2004 20 DS:Use case definitions 18.10.2004 21 Aihe: Projektisuunnitelma Sivu 20 / 29
Tehtävät yhteensä 234 Taulukko 10: Yhteenveto tehtävistä 11. lokakuuta 2004 Päivitys: Ajan hetkellä 2004-11-01 Suunniteltu tuntimäärä on jo ylitetty ja realistisempi arvio on yhteensä 315 h. 1) Kaikkien alueiden opiskelut yhteensä 2) Kaikkien työkalujen käyttöönotto yhteensä 6.3 Implementaatio 1 (5.11.- 2.12.2004) 6.3.1 Tavoitteet Tämän iteraation tavoitteena on saada valmiiksi järjestelmän tietomalli ja tietokantakuvaus sekä toteuttaa käyttötapaukset P1, P3, P5, P6, P7 ja T1. Nämä käyttötapaukset muodostavat yhdessä Cycles of Control toiminnallisuuden jonka toteuttaminen on iteraation suurin ja haastavin tavoite. Muita tavoitteita ovat HTML-prototyyppi Arkkitehtuurin suunnittelu ja dokumentointi Testauksen suunnittelu Toteutetun toiminnallisuuden testaus 6.3.2 Toimitettavat asiat Järjestelmä, johon implementoitu CoC. Tarkennettu projektisuunnitelma + testaussuunnitelma Tarkennetut käyttötapaukset (P1, P3, P5, P6, P7 ja T1) Päivitetty vaatimusdokumentti Tekninen spesifikaatio Arkkitehtuurin dokumentaatio Testitapaukset Testiraportit ja testiloki Edistymisraportti Päivitetyt SEPA-päiväkirjat. 6.3.3 Tehtävät Taulukossa 11 on esitetty iteraation suunnitellut tehtävät aika-arvioineen. Resurssien jakauma eri tehtävien välillä on esitetty kuvassa 1. Viikko Päivä(t) Tapahtuma/tehtävä Tunnit 46 8.11. Suunnittelupalaveri 10 Projektisuunnitelman päivitys 2 Aihe: Projektisuunnitelma Sivu 21 / 29
Viikko Päivä(t) Tapahtuma/tehtävä Tunnit Käyttötapauksien P1, P3, P5, P6, P7 ja T1 määrittely 24 Staattisten menetelmien valmistelua 4 8.-9.11. Testauksen/testien suunnittelua 10 Vaatimusdokumentin parannus 6 Automaattisen buildijärjestelmän parannus: ongelmien korjaus, dokumenttien julkaisu 4 Projektinhallintaa 10 SEPA-työtä 7 Yht. 77 47 Järjestelmän rakenteen tarkentaminen 10 HTML-prototyyppi CoC:sta (P1, P3, P5, 15.-17.11 P6, P7, T1) 20 17.11. HTML-prototyyppi, käyttötapaukset ja järjestelmän kuvaus asiakkaalle < 20.11. Staattisten menetelmien integrointi 6 19. -21.11. Prototyypin muokkaaminen palautteesta 8 Käyttötapauksien muokkaus 4 Testauksen/testien suunnittelua 10 Buildijärjestelmän säätäminen: staattiset työkalut, tagit 3 Projektinhallintaa 8 Tietokantasuunnittelu 12 Yht. 81 48 Tietokantasuunnittelu 4 Hibernate-luokkien kirjoittaminen 8 HTML:n konvertointi Servleteiksi ja JSP:ksi (stub) 10 Projektinhallintaa 10 SessionBean API 15 Yksikkötestejä API:lle 5 Tilannepalaveri asiakkaan kanssa klo 25.11. 13-15 3 Tekninen dokumentaatio 5 28.11. Palautusten valmistelu 4 Servletit ja JSP:t dynaamisiksi 20 Yht. 84 49 Servletit ja JSP:t dynaamisiksi 20 SessionBean API:n täydentämistä 6 Funktionaalista testausta 18 Projektinhallintaa 10 Testiraporttien tuottaminen 4 Yksikkötestejä API:lle 10 29.11. Iteraation palautukset 1 30.11. Katselmuksen valmistelu, erit. demo 2 1.12. Projektikatselmus 7 Aihe: Projektisuunnitelma Sivu 22 / 29
Viikko Päivä(t) Tapahtuma/tehtävä Tunnit 2.12. CoC-toteutettu, P1, P3, P5, P6, P7 ja T1 implementoitu Yht. 78 Kaikki yhteensä 320 Taulukko 11: Implementaatio 1 tuntisuunnitelma Resurssijakauma Projektinhallinta 12 % Dokumentointi 8 % Kokoukset 7 % Muu 4 % Implementointi 25 % QA 20 % Suunnittelu 24 % QA Suunnittelu Implementointi Kokoukset Dokumentointi Muu Projektinhallinta Kuva 2: Suunniteltu resurssien jakautuminen I1:ssä 6.4 Implementaatio 2 (7.1.2005 10.2.2005) 6.4.1 Tavoitteet Iteraation päätavoite on kehittää järjestelmä sellaiseen kuntoon, että sitä olisi mahdollista käyttää ryhmän oman työn suunnitteluun ja seurantaan. Tavoitteen täyttyminen vaatii ainakin seuraavien ominaisuuksien implementoinnin: Ajankäyttöön liittyvä toiminnallisuus o o o Tuntiarviot Tuntien kirjaus Burndown-graafi Tehtävälistojen laadinta ja muokkaus Tehtävähierarkian toteuttaminen Editoitavien näkymien ja filtterien toteuttaminen (timeline käsite poistuu ja nämä tulevat tilalle) Käyttäjien, tehtävien, projektien yms. poistamisen suunnittelu ja speksaus Iteraation muita tavoitteita ovat: Aihe: Projektisuunnitelma Sivu 23 / 29
Koodin esittely asiakkaalle Vertaistestauksen järjestelyt Käyttöohjeen vedos Tietomallin päivittäminen vastaamaan tuoreimpia vaatimuksia Tietomallin/tietokantascheman jäädyttäminen viimeisten muutoksien jälkeen 6.4.2 Toimitettavat asiat Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittelydokumentti Päivitetty käyttötapausdokumentti Päivitetty tekninen spesifikaatio Päivitetyt testitapaukset Testitapaukset ja testiloki Käyttöohjeen vedos Edistymisraportti Päivitetyt SEPA-päiväkirjat 6.4.3 Tehtävät Viikko Päivä(t) Tapahtuma/tehtävä Kuorma 2 12.1. Suunnittelupalaveri 7,5 Projektisuunnitelman päivitys 1 Uusien ominaisuuksien listaus 14 Javadoc-automatisointi 3 Uusien ominaisuuksien speksaus ja suunnittelu 24 Dokumentaation päivitystä 6 Käyttöliittymämuutoksia 4 Testien päivitystä 6 Tietomallin muutostyöt 5 Buildijärjestelmän dokumentointi ja päivitys 4 Projektinhallintaa 4 SEPA-työtä 7 3 Javadocien lisäystä 6 Tuntiseurannan suunnittelu ja speksaus 10 Katselmoinnin käyttöönoton suunnittelu 6 Portfolion raporttinäkymän (graafinen esitys) protoilu 5 Resurssien kiinnityksen suunnittelu 8 Issue templaten speksaus 3 Testitapausten laatimista 10 Bugzillan perustaminen ja käyttöönotto 4 Yksikkötestien lisäystä 3 Aihe: Projektisuunnitelma Sivu 24 / 29
Projektinhallintaa 3 Vertaistestauksen organisointi 2 Tehtävälistan/linkityksen suunnittelu 8 Portfolio-ominaisuuden implementointia 6 SEPA-työtä 7 4 Tietokantascheman jäädyttäminen 2 Tuntiseurannan implementointi 8 Issue templaten implementointi 8 Resurssien kiinnityksen implementointi 5 Portfoliofilttereiden implementointi 8 Tehtävälistan implementointi 4 Tehtävähierarkian/linkityksen implem. 4 Käyttöohjeen vedostaminen 4 Projektinhallintaa 3 Koodikatselmoinnit yhteensä 12 SEPA-työtä 7 5 Bugien korjausta 10 1.2. Feature demo ja asiakaspalaveri 6 Palautteeseen reagoiminen 21 Vaiheessa olevien tehtävien loppuunsaattaminen 12 Testitapausten laatimista 10 Testausta 6 SEPA-työtä 7 6 Yleistä viimeistelyä 21 Katselmukseen valmistautuminen 7 Testausta 12 8.2 I2 DL klo 13:00 Bugien korjausta 12 14.2. I2-katselmus 7 Kaikki yhteensä 362,5 6.5 Viimeistely ja toimitus (11.2. 17.3.2005) 6.5.1 Tavoitteet Viimeisen iteraation päätavoitteina ovat järjestelmän viimeistely ja toimitus sekä AgilElephantin ottaminen ryhmän omaan tuotantokäyttöön Trapolin rinnalle. Tehtävien suunnittelu ja seuranta tapahtuu pääosin AgilElephanttia käyttämällä, mutta tunnit kirjataan myös Trapoliin kurssivaatimusten täyttämiseksi ja riskien (ks. riski #8) minimoimiseksi. Iteraatiossa panostetaan myös käytettävyyden (käyttöliittymä) parantamiseen asiakkaalta suunnittelupalaverissa saadun palautteen perusteella. Toimitukseen liittyvät osatavoitteet ovat: Ohjelmiston paketointi helppoa toimitusta ja asennusta varten Seuraavien osa-alueiden dokumentointi: o o o CruiseControl buildisysteemi Asennus ja deployment AgilElephantin kehitysympäristön (esim. Eclipse) pystytysohjeet Aihe: Projektisuunnitelma Sivu 25 / 29
o Ulkoisten rajapintojen dokumentointi ja ohjeet laajennettavuuteen Lisäksi suoritetaan kurssin vaatimat asiat kuten julkaisukandidaatin valmistaminen, järjestelmän lopputestaus, vertaistestaus, projektin päätös ja analyysi sekä mahdollinen järjestelmän esittely suurelle yleisölle. 6.5.2 Toimitettavat asiat Järjestelmän toimittaminen vertaistestaukseen 1.3. (Juha, bannedwagon) Järjestelmän toimittaminen asiakkaan hyväksymistestaukseen 1.3. (Petri, kyläverkko) Testiraportti vertaisryhmän järjestelmästä 8.3. Päivitetty projektisuunnitelma Päivitetty vaatimusdokumentti Päivitetty käyttöohje Päivitetyt testitapaukset Testiraportti ja testiloki Vertaistestauksen suunnitelmat (sekä vertaisryhmän tekemä että heille tehty) Vertaistestauksen raportit (sekä vertaisryhmän tekemä että heille tehty) Loppuraportti Lopulliset versiot kaikista muista projektin tuottamista dokumenteista Päivitetyt SEPA-päiväkirjat 6.5.3 Tehtävät Backlog item ID Summary Assignee Priority Status AE-23 All-Releases nappi Product-sivulle Minor New AE-22 Product-sivun parannukset Heikki Salminen High New AE-21 Home-sivun muutokset Pasi Kallioniemi High New AE-20 Jatkokehityksen dokumentoiminen Heikki Salminen High New AE-19 Dokumentoi ulkoisten rajapintojen käyttö Rauli Ikonen Normal New AE-24 Taulukoiden sorttaus Pasi Kallioniemi Normal New AE-18 Järjestelmän paketointi ja paketoinnin dokumentointi Esa Mommo High New AE-16 Koodipolun esittely Pauli Vesterinen High In progress AE-15 Bugzilla-tunnusten luonti Juha Kaarlas Normal Open AE-17 CruiseControl dokumentaatio Juha Kaarlas Normal New AE-25 Iteration backlogin muutokset Pasi Kallioniemi High New AE-26 Backlog item -näkymän parannukset Esa Mommo High New AE-27 Iteraatiot graafiseen portfolioesitykseen. Petri Kalsi Normal New AE-28 Portfolioiden editointi ja poisto Heikki Salminen Normal New AE-29 Itemien bulk-import product backlogiin Pasi Normal New Aihe: Projektisuunnitelma Sivu 26 / 29
Kallioniemi AE-30 Portfolioiden ryhmittely Petri Kalsi Minor New AE-31 Tuntiraporttien export Pasi Kallioniemi Minor New AE-32 Valmistele palvelin hyväksymistestausta varten Petri Kalsi High New AE-33 AgilElephantin test charter Heikki Salminen High New AE-34 Vertaistestauksen suunnittelu ja raportointi Petri Kalsi High New AE-35 Vertaistestaus hutikolle Esa Mommo High New AE-36 Vertaistestaus hutikolle Pauli Vesterinen High New AE-37 Kirjoita ohje kehitysympäristöstä Esa Mommo Normal New AE-38 AgilElephantin testaus Heikki Salminen High New AE-39 Projektin päätös ja analyysi Juha Kaarlas Critical New AE-40 Projektinhallintatehtävät Juha Kaarlas Normal In progress AE-41 CruiseControl-muutokset Juha Kaarlas High New AE-42 Testitapausten päivittäminen Heikki Salminen Normal New AE-43 SEPAt Normal New AE-44 Testidokumenttien palautus Petri Kalsi High New AE-45 Korjaa bugi #2: newissue.jsp does not show large values for estimated effort or give warnings Rauli Ikonen Normal New AE-46 Bugi #7: Product backlogin virhe status-muutoksille Rauli Ikonen High New AE-47 Bugi #9: HTML-koodi tekstikentissä Rauli Ikonen Minor New AE-48 Bugi #12: Kaksi tuotetta samalla keyllä tuottaa JDBC errorin Rauli Ikonen Normal New AE-49 Bugi #16: Väärä virheilmoitus Rauli Ikonen Normal New AE-50 Dokumenttien katselmointi Juha Kaarlas Normal New AE-51 Dokumenttien katselmointi Esa Mommo Normal New AE-52 Bugi #17: Päivämäärien tuhoutuminen Rauli Ikonen High New AE-53 Bugi #19: Päivämäärät ja SQL Rauli Ikonen Normal New AE-54 Bugi #22: Graafisen portfolion leveys Petri Kalsi Minor New AE-55 Bugi #8: Väärä completeness luku Pasi Kallioniemi Normal New AE-56 Bugi #24: Itemin lisäys product backlogiin Pasi Kallioniemi Critical New AE-57 Koodikatselmoinnit Normal New AE-58 Javadoc-parannukset Esa Mommo Normal New AE-59 Yksikkötestejä Esa Mommo Normal New AE-60 Yksikkötestejä Pauli Vesterinen Normal New AE-61 Iteraatioiden ja releasien poistot Pauli Vesterinen High New Taulukko 12: FD-iteraation tehtävälista Aihe: Projektisuunnitelma Sivu 27 / 29
1 7. Riskiloki ID Riskitekijä Toteutuma Vaikutukset Kontrolli Projektiryhmän jäsenten poissaolo. 2 3 4 5 6 7 8 SoberIT:n palvelimien käyttäminen, käytettävän laitteiston yleiset häiriöt. Työmäärä ja sen laatu Kaikki eivät ole ajan tasalla projekti- ja laadunvarmistussuunnitelmien suhteen. Vaatimusten muuttuminen Tehtävien epätarkat aika-arviot. Ulkoisten ohjelmistojen versiot. Tuotantokäytön ongelmat Taulukko 13: Riskit Projektiryhmän jäsen sairastuu tai joutuu keskeyttämään kurssin. SoberIT:n tiloissa sijaitseviin palvelimiin ei saada yhteyttä kriittisellä hetkellä. Jokin käytettävistä resursseista kaatuu tai menee epäkuntoon. Jotkin tehtävät ovat projektin jäsenille liian vaikeita tai tehtävää ei ole tarpeeksi Suunnitelmien muutoksia ei kommunikoida riittävän hyvin. Vaatimukset muuttuvat kesken projektin. Inkrementtien tehtävät arvioidaan liian lyhyiksi, työtä on liikaa. Käytettävien työkalujen tai kirjastojen eri versioiden välillä syntyy arvaamattomia konflikteja. Tuotantokannasta häviää dataa, työn seuraaminen ei onnistu, järjestelmästä ei saa kurssin vaatimia raportteja. Käytettävissä olevien tuntien määrä vähenee. Joitakin tehtäviä joudutaan lykkäämään tai tiputtamaan. Palautukset myöhästyvät, CVS ei ole käytettävissä. Tehtävien viivästyminen Alhainen motivaatio, väärinkäsitykset, ryhmä ei pysty sitoutumaan suunnitelmiin. Backlogien uusiminen, mahdollisesti isoja suunnittelumuutoksia. Pahoja viivästyksiä, tärkeimpiä ominaisuuksia ei saada valmiiksi. Odottamattomia virhetilanteita. Työtä menee hukkaan ja tehtävien seuranta epäonnistuu katastrofaalisesti. Ryhmän tehtävät on jaettu siten, että kukaan ei ole yksin vastuussa tietystä osa-alueesta. Järjestelmän ja projektin eri osien dokumentaatio pidetään ajan tasalla. CVS-repositorio mirroroidaan CruiseControlin ja/tai cvsrup:in avulla. Jäsenet pitävät oman kopionsa repositoriosta ajan tasalla. Palautukset koostetaan viimeistään yksi arkipäivä ennen määräaikaa. Tehtävät jaetaan tarpeeksi pieniin osiin. Jäsenten oltava omaaloitteisia ja avoimia työtaakan ja ongelmien suhteen. Suunitelmien muutoksista tiedotetaan. Suunnitelmat katselmoidaan. Iteratiivinen prosessi, asiakkaan ja ryhmän sitouttaminen vaatimuksiin mahdollisimman aikaisessa vaiheessa. Jaetaan tehtävät enintään kymmenen työtunnin taskeihin. Aika-arvioihin käytetään Pert-estimointia. Kaikki käyttävät samoja versioita. Tuotantokannan käyttöoikeudet tiukoiksi, viikoittaiset backupit tietokannasta, käytetään AgilElephantia rinnan Trapolin kanssa Aihe: Projektisuunnitelma Sivu 28 / 29
7.1 Toteutuneet riskit I1-vaiheessa toteutuneita riskejä oli kolme: Pasi Kallioniemen poissaolo (1) tiedettiin ennalta, mutta sitä ei osattu huomioida riittävästi iteraation suunnittelussa. Tästä seurasi aikataulun epärealistisuus (6), vaativia tehtäviä kasautui liikaa viimeiselle viikolle (3) ja skooppia jouduttiin pienentämään. Tehtävien kasautuminen johtui osittain myös siitä, että alkuvaiheessa tehty työmäärä jäi liian pieneksi. I2-vaiheessa toteutuneita riskejä oli kaksi: Pasi oli alkuvaiheessa sairas, mikä vaikutti hieman tuntiraportoinnin valmistumiseen. Lisäksi asiakkaan vaatimukset muuttuivat hieman ja yksi järjestelmän keskeisistä käsitteistä meni uusiksi. Kummankaan riskin toteuttaminen ei aiheuttanut kohtuuttomia viivästyksiä. FD-vaihe sujui ilman, että yksikään riski toteutui. Aihe: Projektisuunnitelma Sivu 29 / 29