AgilElephant Projektisuunnitelma Tekijä: Juha Kaarlas Omistaja: ElectricSeven Aihe: Projektisuunnitelma Sivu 1 / 27
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öja 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-31 Päivämääriä muutettu, kirjattu toteutuneita riskejä Juha Kaarlas 2.4 2005-02-02 Virheellinen tavoite poistettu Juha Kaarlas 2.5 2005-02-08 Korjattu taulukon asettelua, päivitetty tuntibudjettia 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 Nimi Projektiryhmä Tehtävä Aihe: Projektisuunnitelma Sivu 2 / 27
Sisällysluettelo 1. Esittely...5 1.1 Tarkoitus ja laajuus...5 1.2 Järjestelmä ja ympäristö...5 1.3 Terminologia ja viittaukset...5 2. Sidosryhmät ja henkilöstö...6 2.1 Projektiryhmä...6 2.2 Muut sidosryhmät...7 2.2.1 Asiakas...7 2.2.2 Kurssi...7 2.2.3 Järjestelmän jatkokehittäjät...7 2.2.4 Loppukäyttäjät...7 2.2.5 Vertaistestaajat...7 3. Tavoitteet ja kriteerit...8 3.1 Asiakkaan tavoitteet...8 3.2 Ryhmän tavoitteet...8 3.3 Henkilökohtaiset oppimistavoitteet...8 3.4 Projektin keskeyttäminen...9 3.5 Projektin päättäminen...9 4. Resurssit ja budjetti...10 4.1 Henkilöstö...10 4.2 Materiaalit...10 4.3 Budjetti...10 5. Käytännöt ja työkalut...11 5.1 Käytännöt...11 5.1.1 Iteratiivinen prosessi...11 5.1.2 Inkrementtien suunnittelu...11 5.1.3 Raportointi...12 5.1.4 Virheiden seuranta...12 5.1.5 Projektin seuranta...12 5.1.6 Dokumentointi...12 5.1.7 Kommunikaatio...13 5.1.8 Vaatimusten hallinta...14 5.1.9 Muutosten hallinta...14 5.1.10 Ohjelmointikäytäntö...15 5.1.11 Riskien hallinta...15 5.1.12 Vertaistestaus...15 Aihe: Projektisuunnitelma Sivu 3 / 27
5.2 SEPA yhteenveto...15 5.3 Laadunvarmistus...16 5.3.1 Automaattiset yksikkötestit...16 5.3.2 Automatisoitu toiminnallinen testaus HTTPUnitilla...16 5.3.3 Käsin tehtävä toiminnallinen testaus...16 5.3.4 Staattiset menetelmät ohjelmakoodin analysoinnissa...16 5.3.5 Heuristinen käytettävyyden arviointi...16 5.4 Työkalut...16 5.5 Standardit...17 6. Aikataulu...18 6.1 Yleinen aikataulu, tavoitteet ja tehtävät...18 6.2 Projektin suunnittelu (28.9.- 4.11.2004)...19 6.2.1 Tavoitteet...19 6.2.2 Toimitettavat asiat...19 6.2.3 Tehtävät...19 6.3 Implementaatio 1 (5.11.- 2.12.2004)...20 6.3.1 Tavoitteet...20 6.3.2 Toimitettavat asiat...20 6.3.3 Tehtävät...20 6.4 Implementaatio 2 (7.1.2005 10.2.2005)...22 6.4.1 Tavoitteet...22 6.4.2 Toimitettavat asiat...23 6.4.3 Tehtävät...23 6.5 Viimeistely ja toimitus (11.2. 17.3.2005)...24 6.5.1 Tavoitteet...24 6.5.2 Toimitettavat asiat...25 6.5.3 Tehtävät...25 7. Riskiloki...26 Aihe: Projektisuunnitelma Sivu 4 / 27
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 5 / 27
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 6 / 27
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ökuna 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 7 / 27
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. burn down -graafilla. Järjestelmän arkkitehtuuri ja dokumentaatio tukevat jatkokehitystä. Järjestelmä ei saa hukata tai korrupoida 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 8 / 27
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-teknologiohin 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 9 / 27
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 10 / 27
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 11 / 27
5.1.3 Raportointi 5.1.3.1 Tehtävät Projektipäällikkö ylläpitää tehtävälistaa omassa Excel-taulukossa (burn down -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 12 / 27
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 Päätetään myöhemmin Testiraportit ja testiloki Petri Kalsi Suomi Ei katselmointia Käyttötapausdokumentti Heikki Salminen Englanti Päätetään myöhemmin Ohjelmointiohjesääntö Esa Mommo Suomi Ei katselmointia Arkkitehtuuri ja tekninen spesifikaatio Rauli Ikonen, Pasi Kallioniemi Englanti Päätetään myöhemmin Käyttöohje Pauli Vesterinen Englanti Päätetään myöhemmin 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ä asiota 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 13 / 27
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) otetan 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. Ssuuriin 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 14 / 27
muutoksissa muutostenhallintadokumentin tunniste. Tunniste kirjataan commitin yhetydessä CVSkommentin alkuun. 5.1.9.4 Koodikatselmointien seuranta Projektin joissain vaiheissa koodikatselmointi tehdään järjestelmällisesti muutosten versiokantaan tallentamisen jälkeen. Tällöin katselmointi merkitään versionhallintaan CVS-tagilla (jos tämä osoittautuu liian hankalaksi, siitä voidaan luopua). Säännölliset koodikatselmoinnit aloitetaan projektin kolmannessa (I2) vaiheessa. Katselmointi tehdään vertaisarviointina eli toinen ohjelmoija käy läpi tehdyt muutokset ja antaa niistä tarvittaessa palautetta. Projektin kolmannessa vaiheessa katselmoinnit tehdään järjestelmällisesti kaikille muutoksille mahdollisimman pian niiden versionhallintaan tallentamisen jälkeen. Suuremmille muutoksille nimetään katselmoija etukäteen. Ellei näin tehdä, katselmoinnin suorittaa viimeistään se, joka seuraavaksi muuttaa kyseistä tiedostoa. Projektin neljännessä vaiheessa (FD) katselmointi tehdään jo ennen muutosten versionhallintaan tallentamista. Jokaiselle muutokselle nimetään erikseen tekijä ja katselmoija. Muutos tallennetaan versionhallintaan vasta, kun katselmoinnissa ilmi tulleet virheet on korjattu ja uudelleenkatselmoitu. Kaikkein suurimmista muutoksista voidaan järjestää useamman henkilön katselmoititilaisuus. Tavoitteena on, että lähes kaikki katselmoinnit tehtäisiin hajautetusti. 5.1.10 Ohjelmointikäytäntö Ohjelmakoodin kirjoittamiseen liittyvät käytännöt on määritelty dokumentissa AgilElephant Ohjelmointiohjesääntö. 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 Aihe: Projektisuunnitelma Sivu 15 / 27
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 Automatisoitu toiminnallinen testaus HTTPUnitilla Toiminnalliset testit ajetaan myös öisin buildin yhteydessä. Toiminnallista testausta varten toteutetaan erillinen www-käyttöliittymä, johon tehdään mahdollisimman vähän muutoksia. Käyttöliittymän navigointi tehdään HTTPUnitilla, ja vastauksena saatua sivua verrataan CVS:stä löytyvään haluttuun lopputulokseen. 5.3.3 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.4 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. 5.3.5 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) Aihe: Projektisuunnitelma Sivu 16 / 27
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 17 / 27
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 Ti 15.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 18 / 27
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 19 / 27
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 20 / 27
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 Serveleiksi 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 21 / 27
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ä Ryhmän jäsenistön osittaisen poissaolon takia kaikkia suunniteltuja tunteja ei käytetä ennen 2.12.2004 vaan erotus kurotaan kiinni projektin joululoman aikana 3.12. 2004 5.1. 2005 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 ominaisuuksen 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) Aihe: Projektisuunnitelma Sivu 22 / 27
Käyttäjien, tehtävien, projektien yms. poistamisen suunnittelu ja speksaus Iteraation muita tavoitteita ovat: 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 Aihe: Projektisuunnitelma Sivu 23 / 27
Issue templaten speksaus 3 Testitapausten laatimista 10 Bugzillan perustaminen ja käyttöönotto 4 Yksikkötestien lisäystä 3 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 Järjestelmän toimittaminen vertaistestaukseen Vertaisryhmälle suoritettu testaus Järjestelmän stabilointi Asiakkaan hyväksymistestaus Projektin analyysi ja päätös Loppuraportti Aihe: Projektisuunnitelma Sivu 24 / 27
Järjestelmän esittely suurelle yleisölle 6.5.2 Toimitettavat asiat 6.5.3 Tehtävät Aihe: Projektisuunnitelma Sivu 25 / 27
1 7. Riskiloki ID Riskitekijä Toteutuma Vaikutukset Kontrolli Projektiryhmän jäsenten poissaolo. 2 3 4 5 6 7 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. Taulukko 12: 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ä resurssiesta 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. 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. 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. 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. Aihe: Projektisuunnitelma Sivu 26 / 27
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ä. Aihe: Projektisuunnitelma Sivu 27 / 27