AgilElephant - Projektisuunnitelma. Dokumentti: projektisuunnitelma.doc Päiväys: Projekti : AgileElephant Versio: V1.8

Transkriptio

1 AgilElephant Projektisuunnitelma Tekijä: Juha Kaarlas Omistaja: ElectricSeven Aihe: Projektisuunnitelma Sivu 1 / 21

2 Dokumentin Historia Muutoshistoria Revision päiväys: Seuraavan revision päiväys Revision Numero Revision Päiväys Yhteenveto muutoksista Muutokset merkitty Ensimmäinen versio Ei Aikatauluja sekä henkilökohtaisia tavoitteita lisätty Ei Ensimmäinen iteraatiosuunnitelma tehty. Ei Lisätty otsikko riskilogille, SEPA-aiheita, hieman resursointia Ei Seurannasta ja kommunikoinnista Ei Laadunvarmistussuunnitelma lisätty, kappale 5.3 Ei Riskiloki Ei Päivitetty käytäntöja ja riskejä Ei Katselmoinnin korjaukset Ei 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 / 21

3 Sisällysluettelo 1. Esittely Tarkoitus ja laajuus Järjestelmä ja ympäristö Terminologia ja viittaukset Sidosryhmät ja henkilöstö Projektiryhmä Muut sidosryhmät Asiakas Kurssi Järjestelmän jatkokehittäjät Loppukäyttäjät Vertaistestaajat Tavoitteet ja kriteerit Asiakkaan tavoitteet Ryhmän tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeyttäminen Projektin päättäminen Resurssit ja budjetti Henkilöstö Materiaalit Budjetti Käytännöt ja työkalut Käytännöt Iteratiivinen prosessi Inkrementtien suunnittelu Raportointi Virheiden seuranta Projektin seuranta Dokumentointi Kommunikaatio Vaatimusten hallinta Muutosten hallinta Ohjelmointikäytäntö Riskien hallinta Vertaistestaus...14 Aihe: Projektisuunnitelma Sivu 3 / 21

4 5.2 SEPA yhteenveto Laadunvarmistus Automaattiset yksikkötestit Automatisoitu toiminnallinen testaus HTTPUnitilla Käsin tehtävä toiminnallinen testaus Staattiset menetelmät ohjelmakoodin analysoinnissa Heuristinen käytettävyyden arviointi Työkalut Standardit Aikataulu Yleinen aikataulu, tavoitteet ja tehtävät Projektin suunnittelu ( ) Tavoitteet Toimitettavat asiat Tehtävät Implementaatio 1 ( ) Tavoitteet Toimitettavat asiat Tehtävät Implementaatio 2 ( ) Tavoitteet Toimitettavat asiat Tehtävät Viimeistely ja toimitus ( ) Tavoitteet Toimitettavat asiat Tehtävät Riskiloki...21 Aihe: Projektisuunnitelma Sivu 4 / 21

5 1. Esittely AgilElephant-projektin tarkoitus on kehittää Ohjelmatyökurssin puitteissa ketterään ohjelmistokehitykseen ja erityisesti SEMS-malliin [ 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: Ohjelmatyökurssi : SEMS: Software Engineering Management System: Pert-estimointi: Yksinkertainen tehtävien estimointimenetelmä. Aihe: Projektisuunnitelma Sivu 5 / 21

6 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 ylläpito Ohjelmoija, dokumentit, testaus Esa Mommo esa.mommo (ät) fi.ibm.com Tietokantaekspertti, SCM, QA Heikki Salminen heikki.salminen (ät) hut.fi Ohjelmoija, testaus, dokumentit Pauli Vesterinen pjvester (ät) cc.hut.fi Seniorohjelmoija/arkkitehti Pasi Kallioniemi pkallion (ät) cc.hut.fi QA, testaus, käyttöliittymä Petri Kalsi petri.kalsi (ät) iki.fi Seniorohjelmoija/arkkitehti, speksaus Rauli Ikonen rauli.ikonen (ät) hut.fi Taulukko 1: Projektiryhmä Ryhmän postituslista on osoitteessa ot (ät) thraexsoftware.com. Aihe: Projektisuunnitelma Sivu 6 / 21

7 2.2 Muut sidosryhmät Asiakas Asiakkaana toimii SoberIT, jonka edustajina Mikko Rusama Juha Itkonen Kurssi Teknillisen korkeakoulun tietojenkäsittelyopin ohjelmatyökurssi vuonna : T [ Kurssihenkilökuna on esitelty sivulla /04-05/Personnel.html 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) Järjestelmän jatkokehittäjät Jatkokehittäjät on kokoonpanoltaan tuntematon sidosryhmä, joka pitää ottaa huomioon järjestelmän kehitystyössä ja dokumentaatiossa Loppukäyttäjät Loppukäyttäjinä toimivat ainakin tuotepäälliköt, projektipäälliköt ja ohjelmoijat Vertaistestaajat Vertaistestauksen tekee toinen kurssia suorittava opiskelijaryhmä, joka on toistaiseksi tuntematon. Vertaistestaus tapahtuu Lopullisen järjestelmän ja sen testausohjeiden tulee olla valmiit Samoihin aikoihin oma ryhmämme testaa vertaisryhmän järjestelmää. Aihe: Projektisuunnitelma Sivu 7 / 21

8 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 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 / 21

9 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 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 / 21

10 4. Resurssit ja budjetti 4.1 Henkilöstö Juha Esa Heikki Petri Pauli Pasi Rauli Subtotal PP I I FD Total Taulukko 5: Tuntibudjetti 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. Aihe: Projektisuunnitelma Sivu 10 / 21

11 5. Käytännöt ja työkalut 5.1 Käytännöt Iteratiivinen prosessi Projektin prosessimalli on ketterä ja iteratiivinen ohjelmistokehitysmalli. Ryhmä käyttää projektissaan SEMS-projektimallia, joka on yhteensopiva kurssin vaatimusten kanssa 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 (5 viikkoa) I1: Implementaatio (4 viikkoa) I2: Implementaatio (5 viikkoa) FD: Viimeistely ja (5 viikkoa) toimitus Taulukko 6: Inkrementtiaikataulu Asiakaspalaute Asiakkaan näkökulmaa tullaan kuulemaan suunnittelu- ja seurantapalavereissa ja yksityiskohtien osalta aina tarvittaessa. Seurantapalavereita pidetään n. 2 kpl per inkrementti 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 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 / 21

12 5.1.3 Raportointi Tehtävät Projektipäällikkö ylläpitää tehtävälistaa omassa Excel-taulukossa (burn down -graafia ja muita metriikoita varten). Tehtävien valmistuttua jokainen luo vastaavan taskin Trapoliin 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 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 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 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 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. Projektisuunnitelma on projektipäällikön vastuulla. Aihe: Projektisuunnitelma Sivu 12 / 21

13 5.1.7 Kommunikaatio 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 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. Ennaltanähtäviä kokouksia ovat iteraatioiden seuranta- ja suunnittelupalaverit 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 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 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 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. Aihe: Projektisuunnitelma Sivu 13 / 21

14 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 Versiomuutosten seuranta Projektin neljännessä vaiheessa (FD) kaikkiin versionhallintajärjestelmiin tallennettaviin muutoksiin liitetään muutoksenhallintaan viittaava tunniste. Bugikorjauksissa tunnisteena toimii bugin id, muissa muutoksissa muutostenhallintadokumentin tunniste. Tunniste kirjataan commitin yhetydessä CVSkommentin alkuun 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. Koko kappale siirretään QA-suunnitelmaan kun sellainen tehdään Ohjelmointikäytäntö Ohjelmakoodin kirjoittamiseen liittyvät käytännöt on määritelty dokumentissa AgilElephant Ohjelmointiohjesääntö 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 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 Aihe: Projektisuunnitelma Sivu 14 / 21

15 Aihe Vastuullinen henkilö Soveltamisaika 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 7: SEPA-aiheet 5.3 Laadunvarmistus Laadunvarmistus- ja testaussuunnitelma tulee omaan dokumenttiinsa. Laadunvarmistukseen ja testaukseen käytetään alla lueteltuja menetelmiä. Muista päivittää dokkarin nimi 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ä 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 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 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 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 Aihe: Projektisuunnitelma Sivu 15 / 21

16 Eclipse 3.0 Java Development Kit 1.4 JBoss 4.0 (sis. Tomcat) Hibernate CVS versio Bugzilla (kurssin tarjoama) Ant CruiseControl TikiWiki Trapoli MySQL 4.0 (saattaa muuttua projektin edetessä) 5.5 Standardit Projektille ei toistaiseksi ole määritetty noudatettavia standardeja. Aihe: Projektisuunnitelma Sivu 16 / 21

17 6. Aikataulu 6.1 Yleinen aikataulu, tavoitteet ja tehtävät Päivämäärä Tapahtuma Ti DL 13:00 Postita iteraation suunnitelma (6.1 & 6.2) mentorille ja asiakkaalle. Ke Seurantakokous asiakkaan kanssa. Toimita vaatimusdokumentti ja tekniikkademo. Ti PP-iteraation dokumenttien ja raporttien toimittaminen kurssille. Ke Projektin seuranta kurssin kanssa klo Ti DL 13:00 Postita iteraation suunnitelma (6.1 & 6.3) asiakkaalle ja mentorille. Ti DL 13:00 Iteraation dokumenttien ja raporttien toimitus kurssille Ke Projektin seurantapalaveri Joululoma Ti Ti 8.2. Ke DL 13:00 Postita iteraation suunnitelma (6.1 & 6.4) asiakkaalle ja mentorille. DL 13:00 Iteraation dokumenttien ja raporttien toimitus kurssille 8-18 Projektin seurantapalaveri Ti Ti 1.3. Ti 8.3. Ti 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 8: Yleinen aikataulu ja tärkeimmät tapahtumat 6.2 Projektin suunnittelu ( ) Tavoitteet Ensimmäisen inkrementin tavoitteet ovat: Projektin määrittely ja organisointi Aihe: Projektisuunnitelma Sivu 17 / 21

18 Alustavan projektisuunnitelman kirjoittaminen Alustavat vaatimusmäärittelyt ja tärkeimmät käyttötapaukset SEPA-aiheiden valinta Teknologia-alustan valinta Teknologiademo 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 Tehtävät Taulukko 9 on yhteenveto ensimmäisen inkrementin tehtäväsuunnitelmasta (snapshot ajan hetkestä ). 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) GE:Lectures GE:Meetings (status/mentor) PM:Adopt tool X (e.g. CVS) 2) PM:Plan work methods and tools PM:Personal SE practice PM:Risk management PM:Write the project plan PM:Project review and preparation DS:Req. documentation DS:Req. elicitation and analysis DS:Technology demo DS:Use case definitions Tehtävät yhteensä 234 Taulukko 9: Yhteenveto tehtävistä 11. lokakuuta 2004 Päivitys: Ajan hetkellä 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ä Aihe: Projektisuunnitelma Sivu 18 / 21

19 6.3 Implementaatio 1 ( ) Tavoitteet Tarkennettu projektisuunnitelma Tarkennetut käyttötapaukset valituista vaatimuksista Arkkitehtuurin suunnittelu ja dokumentointi Tekninen spesifikaatio Muutaman tärkeimmän ominaisuuden toteuttaminen Testauksen suunnittelu Toteutetun toiminnallisuuden testaus Toimitettavat asiat Tehtävät 6.4 Implementaatio 2 ( ) Tavoitteet Lisää käyttötapausten analyysiä ja toteuttamista Olemassaolevan järjestelmän toimittaminen asiakkaalle palautetta varten Vertaistestauksen järjestelyt Käyttöohjeen vedos Toimitettavat asiat Tehtävät 6.5 Viimeistely ja toimitus ( ) Tavoitteet Järjestelmän toimittaminen vertaistestaukseen Vertaisryhmälle suoritettu testaus Järjestelmän stabilointi Aihe: Projektisuunnitelma Sivu 19 / 21

20 Asiakkaan hyväksymistestaus Projektin analyysi ja päätös Loppuraportti Järjestelmän esittely suurelle yleisölle Toimitettavat asiat Tehtävät Aihe: Projektisuunnitelma Sivu 20 / 21

21 7. Riskiloki ID Riskitekijä Toteutuma Vaikutukset Kontrolli Projektiryhmän jäsenten poissaolo 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 10: 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ä kukaa ei ole yksin vastuussa tietystä osa-alueesta. Järjestelmän ja projekt eri osien dokumentaati pidetään ajan tasalla. CVS-repositorio mirroroidaan CruiseControlin ja/tai cvsrup:in avulla. Jäsen 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 tiedotetaa 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ää Pert-estimointia. Kaikki käyttävät samoja versioita. Aihe: Projektisuunnitelma Sivu 21 / 21