T Ohjelmistokehitysprojekti I Projektisuunnitelma (PP)

Transkriptio

1 T Ohjelmistokehitysprojekti I Projektisuunnitelma (PP) Versio Päiväys Muokkaaja Kuvaus Markus Kattilamäki Riskit päivitetty 2.10 Markus Kattilamäki Katselmoinnissa löydetyt virheet korjattu Markus Kattilamäki Laadunvarmistussuunnitelma lisätty Markus Kattilamäki Kehittäjien tavoitteet lisätty Markus Kattilamäki Jaksotuksen alaotsikot muutettu Markus Kattilamäki Muuta huomioitavaa lisätty aikatauluun Markus Kattilamäki Lisätty sairastumista käsittelevä riski Markus Kattilamäki Viittaus myöhempään poistettu Markus Kattilamäki Virheiden seuranta päivitetty (Bugzilla) Markus Kattilamäki Rönkön oppimistavoite päivitetty Markus Kattilamäki Iteraation lopun tarkentaminen Markus Kattilamäki Maininta ohjelmointikielestä (Johdanto) Markus Kattilamäki Asiakkaan laitteiden määräpäivä (kappale 4.2) Markus Kattilamäki Ryhmän tavoitteiden päivitys Markus Kattilamäki Resurssit ja budjetti päivitetty Markus Kattilamäki Organisaatiokaavion ja lyhenteiden siirto Markus Kattilamäki Asiakkaan tavoitteiden muokkaus ja prioriteetti Markus Kattilamäki Muokkaus palautteen pohjalta Markus Kattilamäki Palautettava versio Kirsi Rönkkö Lisätty muutosloki

2 1 Sisällysluettelo 2.2 Yleiskatsaus projektiin Valpas Sidosryhmät ja jäsenet Organisaatiokaavio Yhteystiedot Tavoitteet ja lopettamiskriteerit Asiakkaan tavoitteet Projektiryhmän tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeytys- ja lopetuskriteerit Resurssit ja budjetti Henkilökunta Materiaali Budjetti Työkalut ja menetelmät Menetelmät Iteratiivinen kehittäminen Iteraatiosuunnittelu Dokumentointi Tuntiraportointi Ohjelmiston koon raportointi Kommunikaatio Iteraatiodemo Virheiden seuranta Versionhallinta Ohjelmointikäytännöt SEPA - Heuristinen arviointi SEPA Design patterns SEPA Staattiset metodit SEPA Refaktorointi Työkalut Standardit ja protokollat Jaksotus Huomioitavaa Aikataulu Projektin suunnittelu (PP) Implementaatio 2 (I2) Riskienhallinta Prosessi Riskikategoriat Lähteet

3 2 Johdanto Tämä dokumentti on ryhmän Neptune projektisuunnitelma Teknillisen Korkeakoulun kurssin T Ohjelmistokehitysprojekti I puitteissa toteutettavaan projektiin. Asiakkaana toimii Indagon Oy. Indagon Oy on mobiilipaikannukseen erikoistunut yritys. Projekti suoritetaan aikavälillä Tämä dokumentti toimii epävirallisena sopimuksena projektiin liittyvien osapuolien välillä. Projektin suorittava ryhmä käsittää kahdeksan kurssin opiskelijaa, jotka toimivat erilaisissa ohjelmistoprojektille tyypillisissä rooleissa. Kurssin toimesta projektille on asetettu toimintavaatimuksia sekä noudatettavia käytäntöjä. Ne on mainittu tässä dokumentissa. Projektin aihe on Indagon Oy:n esittämä ja se kuvataan seuraavassa kappaleessa. Tässä luvussa tullaan käsittelemään lyhyesti projektiin liittyvät oleelliset seikat, selitetään tässä dokumentissa käytetyt termit, tutustutaan toteutettavaan tuotteeseen sekä selitetään projektin viitekehys. 2.1 Käytetyt termit Seuraavassa taulukossa on lueteltu tässä dokumentissa sekä projektissa käytetyt termit ja niiden selitykset. Termien avaaminen on oleellista jotta projektiryhmä sekä asiakas ja muut sidosryhmät puhuvat asioista samoilla käsitteillä. Sillä vältetään ongelmat termien erilaisesta käytöstä kommunikoitaessa järjestelmästä ja siihen liittyvistä asioista. Taulukko 1: Käytetyt termit 2

4 Termi/Lyhenne EPA Selitys Edusta palvelin, Tetra-verkon reunalla oleva palvelin, joka tarjoaa Tetraverkon palveluita helpommin käytettävällä tavalla sovelluksille. Downlink Ilmoitinkeskus Itseohjaava laite Laitetyyppi Laitemalli Se kanava, jota pitkin viesti kulkee Valppaalta puhelimelle. Rakennuksessa oleva keskus, johon kaikki rakennuksessa olevat hälytin anturit/sensorit on kytketty. Laite, joka omalla toiminnallaan testaa linjan toimivuutta (laite itse on aktiivinen linjavian suhteen). Joukko samaan tarkoitukseen tehtyjä laitteita. Esimerkiksi palohälyytin ja poiju ovat laitetyyppejä. Joukko samaan laitteita, jotka toimivat samalla tavalla ja ovat saman valmistajan tekemiä. Linjavika MTT Ohjattava laite Ryhmäosoite SDS Tetra Vika yhdeydessä Valppaan ja puhelimen välillä. Mobile Telematics Terminal. Indagon Oy:n kehittämä laite, joka osaa kertoa koordinaatit paikasta, jossa laite sijaitsee. Laite, jonka kohdalla linjavikaa testataan lähettämällä laitteelle viesti (laite itse on passiivinen linjavian suhteen). TETRA-verkon "puhelinnumero", jonka vastaanottajina on useampia tahoja samaan aikaan. Tetra-verkon vastine SMS-viestille. SDS-viestejä on useampia tyyppejä, joista kolmella on kiinteä pituus ja neljäs on vaihelevan pituinen. Terrestial Trunked Radio. Omanlaisensa radiopuhelin verkko, jota useimmiten käytetään viranomaistarkoituksiin. TMR880 Nokian puhelin malli TETRA-verkkoon. Uplink Se kanava, jota pitkin viesti kulkee puhelimelta Valppaalle. Valpas Toteuttettava järjestelmä (ValvontaPalvelinSysteemi) Valvottava objekti Yksittäinen laite, jota Valpas valvoo. Virve Suomen viranomaisverkko. Toimii TETRA-järjestelmällä Yksilöosoite Vastaa TETRA-verkossa tavallista puhelinnumeroa. (K)loc SEPA (Kilo) Lines Of Code, koodirivien määrä (tuhansissa) (Software Engineering Practice), Kurssin vaatima selvitys käytettävästä menetelmästä 2.2 Yleiskatsaus projektiin Valpas Nykypäivänä viranomaiset ovat asettaneet vaatimuksia palohälyttimille, joita on pakko olla julkisissa ja riittävän isoissa rakennuksissa. Hälyttimiä tulee voida tarkkailla ja varmistaa 3

5 luotettavasti niiden toimivuus. Rakennettava järjestelmä, Valpas, vastaa tähän tarpeeseen ja toteuttaa kyseisen toiminnallisuuden Tetra-verkossa. Projektin tarkoitus on ensimmäisessä vaiheessa toteuttaa prototyyppi järjestelmästä, jonka perusteella voidaan tarpeen mukaan jatkokehittää kaupallinen tuote. Kuva 1: Projektissa toteutettava järjestelmä Projektin tarkoituksena on kehittää TETRA-verkon päällä toimiva simulaatio, jolla on tarkoitus testata tulevaisuudessa toimivaa järjestelmää. TETRA-puhelin voidaan yhdistää sarjaportin kautta PC:hen, jolloin puhelinta voidaan käyttää AT Command Interfacen avulla. Tämä PC simuloi ilmoitinkeskusta ja laskee perille tulleita viestejä ja lähetettyjä viestejä. TETRA-verkon toisella laidalla on EPA, joka tarjoaa palveluita rakennettavalle Valppaalle. EPA:n kautta Valpas pystyy lähettämään ja vastaanottamaan SDS-viestejä. Tärkeää projektin kannalta on pystyä tilastoimaan järjestelmän luotettavuutta. Lisäksi Valppaaseen tarvitaan WWW-palvelu, jolla järjestelmän toimintaa voidaan ylläpitää. Toiminnallisuus tullaan toteuttamaan Java-ohjelmointikielellä. 4

6 3 Sidosryhmät ja jäsenet Projekti on tarkoitus suorittaa kahdeksan opiskelijaa käsittävällä projektiryhmällä. Projektiryhmän jäsenillä on erilaisia rooleja käsittäen yleisimmät ohjelmistoprojektin roolit. Tehtäviä on mahdollista vaihtaa projektin edetessä jos ryhmältä siihen kiinnostusta löytyy. Projektin muita sidosryhmiä ovat asiakas, Indagon Oy, tekninen neuvoja, kurssin henkilökunta (Mentor, luennoitsija) sekä laatupalkinnon jakava edustaja Accenture Oy:stä. 3.1 Organisaatiokaavio Kuvassa 2 on esitetty projektin organisaatiokaavio ja projektin sidosryhmät. Täydelliset yhteystiedot löytyvät projektin kotisivuilta (Wiki) ja ne on jätetty tästä dokumentista pois tarkoituksella. Tästä dokumentista löytyvät kuitenkin projektiin osallistuvien henkilöiden sähköpostiosoitteet. 5

7 6 T Ohjelmistoprojekti I

8 Kuva 2: Sidosryhmien väliset riippuvuudet 3.2 Yhteystiedot Projektin Wiki löytyy osoitteesta ja vaatii käyttäjältään käyttäjätunnuksen ja salasanan. Seuraavassa taulukossa on listattu projektiin osallistuvien henkilöiden toimenkuvat sekä sähköpostiosoitteet. Taulukko 2: Yhteystiedot Nimike Nimi Luennoitsija Jari Vanhanen jari.vanhanen#hut.fi Laatupalkinto Vesa Luomala vesa.luomala#accenture.com Mentor Kari Suhonen kari.suhonen#hut.fi Asiakas Mikko Weckström mikko.weckstrom#indagon.com Tekninen neuvoja Pete Lyly peteveikko.lyly#everkot.fi Projektipäällikkö Markus Kattilamäki markus.kattilamaki#hut.fi Pääarkkitehti Tuukka Laakso tjlaakso#cc.hut.fi Laatupäällikkö Kirsi Rönkkö catangel#iki.fi Kehittäjä Mikko Halttunen mikko.halttunen#hut.fi Kehittäjä Markku Huttunen mahuttun#cc.hut.fi Kehittäjä Antti Kettunen ajkettun#niksula.hut.fi Kehittäjä Mikko Närjänen mtnarjan#cc.hut.fi Testaaja Antti Poikela aspoikel#cc.hut.fi 7

9 4 Tavoitteet ja lopettamiskriteerit Projektin tavoitteena on rakentaa prototyyppi, jonka avulla voidaan selvittää tuotteen kaupalliset ja jatkokehitykseen liittyvät näkymät. Projektiryhmälle kurssi toimii opetuksellisena harjoitustyönä, tarkoituksena syventää näkemystä ohjelmistoprojektiin ja erilaisiin ohjelmistoprojektille ominaisiin menetelmiin ja rooleihin. 4.1 Asiakkaan tavoitteet Seuraavaan taulukkoon on kirjattu asiakkaan tavoitteet projektille tärkeysjärjestykseen. Täyttymiskriteeriä verrataan projektin aikaansaannoksiin ja sen perusteella voidaan mitata tavoitteen täyttyminen. Asiakkaan tavoitteita ei voida katsoa täyttyväksi projektiryhmän toimesta. Asiakas määrittelee tavoitteiden täyttymisen projektin päätyttyä. Taulukko 3: Asiakkaan tavoitteet ID Tavoite Täyttymiskriteeri A1 Mahdollinen kaupallinen tuote tuhansille käyttäjille Prototyypin onnistunut toteuttaminen ja sen soveltuminen jatkokehitykseen. A2 Tetra-verkon käytettävyyden lisäselvitys A3 Kaupallistamisen selvittäminen A4 Aihealueesta oppiminen ja tietämyksen laajentaminen asiakkaan taholta A5 Asiakkaan ohjelmistoprosessin kehittäminen A6 Teknisen neuvojan tavoitteena lopputyön tekeminen aiheesta Prototyypin toimivuus ja skaalautuvuus sekä Tetra-verkon soveltuvuus käyttötarkoitukseen. Prototyypin toimivuus ja sopivuus sekä kaupalliset näkymät. Projekti tuo organisaatioon uutta osaamista ja tietoa aihealueesta. Asiakkaan prosessien kehittyminen ja menetelmien oppiminen. Projekti auttaa ja mahdollistaa lisätietoa aiheesta. Projektin hyödyllisyyden arvio lopussa teknisen neuvojan toimesta. 4.2 Projektiryhmän tavoitteet Seuraavassa taulukossa on listattu projektiryhmän tavoitteet projektille ja tavoitteiden täyttymiskriteerit. Tavoitteet ovat projektiryhmän yhteisiä, projektin alussa sille asetettuja tavoitteita. Taulukko 4: Projektiryhmän tavoitteet ID Tavoite Täyttymiskriteeri R1 Opintosuoritus hyvällä arvosanalla Kurssin suoritus vähintään arvosanalla 4 8

10 R2 Aihealueesta oppiminen R3 Laajemmassa ohjelmistoprojektissa toimiminen R4 Laadukkaan ja asiakkaalle arvoa tuottavan ohjelmiston toimittaminen R5 Projektin loppuun saattaminen Oppimiskokemusten kerääminen projektin jälkeen, oppimisen toteaminen Projektin tyydyttävä suoritus Asiakas päättää projektin perusteella jatkokehittää tuotetta Kurssin laajuuden täyttäminen ja suoritusmerkinnän saaminen 4.3 Henkilökohtaiset oppimistavoitteet Projektin oppimistavoitteiden seuraamisen kannalta jokainen projektiryhmän jäsen on listannut omat oppimistavoitteensa ja odotuksensa projektista. Henkilökohtaiset oppimistavoitteet on listattu seuraavassa taulukossa. Taulukko 5: Henkilökohtaiset oppimistavoitteet Jäsen Oppimistavoite Kattilamäki Saada kokemusta ohjelmistoprojektin vetämisestä ja oppia tehokkaita menetelmiä projektin läpiviemiseksi. Laajentaa näkemystä ohjelmistoprojektista ja sen eri vaiheista. Laakso Rönkkö Huttunen Poikela Närjänen Halttunen Kettunen Oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä Oppia vetämään projektia paremmin, hallitsemaan sitä sekä oppia laadunvarmistukseen liittyviä asioita. Lisäksi tavoitteena on kehittyä testauksen saralla sekä oppia luottamaan enemmän muiden työhön ja keskittyä paremmin omaan. Uusien tekniikoiden oppiminen, kommunikointi laajemmassa projektissa sekä oman ajankäytön ja arvioinnin parempi hallitseminen Aiemman testauskokemuksen puuttuessa pääasiallisena tavoitteenani on oppia rooliin kuuluvat tehtävät ja käytännöt. Projektin koko tuo mukanaan haasteita, joten oppia projektin kulkuun vaikuttavista asioista, esimerkiksi tiimin sisäisestä kommunikoinnista ja asiakkaan kanssa toimimisesta. Ryhmätyötaitojen kehittäminen, laajemman projektin toimintaan tutustuminen, uusien työkalujen (Borland Together, JUnit, jne.) käytön oppiminen, ohjelmointitaitojen kehittäminen. Laajentaa tietoani ohjelmistoprojekteiden kulusta ja päästä kokeilemaan sellaisessa mukana olemista. Yksikkötestauksen oppiminen ja käyttäminen. Oppia soveltamaan käytännössä uusia ohjelmiston tuottamisen käytäntöjä sekä oppia niiden käyttökelpoisuus erilaisissa tilanteissa. 4.4 Projektin keskeytys- ja lopetuskriteerit Projekti ja kurssin suorittaminen voidaan keskeyttää ryhmän yhteisellä päätöksellä jos jokin seuraavista tilanteista toteutuu 9

11 Prototyyppi ei vastaa jatkokehityksen vaatimuksia Asiakas lopettaa projektin Kaksi tai useampi henkilö jättää ryhmän Kurssia ei ole enää mahdollista läpäistä Projekti päättyy viimeisen iteraation päätyttyä Tällöin dokumentit ja lopputuote toimitetaan asiakkaalle kaikissa tapauksissa. Projektin päättymiskriteerit ennen projektin määräpäivää ovat: Käytettävän työmäärän täyttyminen Projektin valmistuminen ennen määräpäivää 5 Resurssit ja budjetti Seuraavassa on esitetty projektin käytössä olevat resurssit ja budjetoitu niiden käyttö. Projektin budjetti on suunniteltu osa-alueittain sekä henkilöiden työtunneittain. Budjetit ja arviot on esitetty seuraavassa. Taulukko 6: Arvio ajankäytöstä PP PP tot. I1 I2 yht. Suunnittelu Dokumentointi 64, Infrastruktuuri 4, Luento 40,8 55, ,5 Palaveri Ohjelmointi Hallinnointi 20 27, ,2 105,7 Opiskelu 20 12, ,2 54,7 Testaus ,6 142,6 Kommunikaatio 5 5, ,5 Muu Yhteensä Taulukon arvioiden pohjana on ollut kurssin edellisten vuosien tuntimäärien jakautuminen tehtävien kesken, projektin edellisten vaiheiden realisoituminen sekä kirjallisuuden antamat esitykset sopivasta tuntien jakautumisesta projektin kesken. 5.1 Henkilökunta Projektiryhmän jäsenille on budjetoitu seuraavan taulukon mukainen työmäärä kuhunkin iteraatioon. Arviota päivitetään realisoituneiden tuntien mukaisesti. Jokaisen tulee pyrkiä täyttämään iteraatiolle varatut tunnit jotta työ ei kasaudu. Jokainen on laatinut myös viikoittaisen tuntisuunnitelman jonka toteutumista projektipäällikkö seuraa. 10

12 Taulukko 7: Iteraatioiden arvioidut työmäärät Henkilö I0 I1 I2 Yhteensä Kattilamäki Rönkkö Laakso 31, ,5 170 Halttunen Huttunen 5, ,5 170 Kettunen 12, ,5 170 Närjänen Poikela 11, , Materiaali Projektin kehitystyö tullaan pääosin suorittamaan projektiryhmän omilla laitteistoilla. Lisäksi ryhmällä on käytettävissään Teknillisen Korkeakoulun opiskelijoilleen tarjoamat laitteistot ja palvelut (ATK-keskus ja Niksula). Paras mahdollinen tilanne olisi että jokaisella projektiin osallistuvalla olisi käytössään samanlainen kehitysympäristö ja alusta. Tämä on käytännössä mahdollista koulun tarjoamia koneita käyttäen. Emme voi kuitenkaan vaatia ainoastaan niiden käyttöä kehitystyössä. Ympäristöissä ja työkaluissa pyritään mahdollisimman samankaltaiseen asetteluun. Indagon Oy mahdollistaa projektille testilaitteistoa ohjelmiston testausta varten. Laitteiston tulisi olla käytettävissä viimeistään kpl kannettava tietokone (Käytössä iteraatiodemon ajan) 1-3 kpl Tetra-verkon puhelinta 5.3 Budjetti Seuraavassa taulukossa on esitetty projektin teoreettinen budjetti. Se on laskettu arvioita käyttäen eikä asiakasta laskelman mukaisesti veloiteta. Osa kuluista kuten asiakkaan omat tunnit ja asiakkaan tarjoamat materiaalit tuottavat asiakkaalle oikeita kuluja. Kurssi veloittaa asiakkaalta myös osallistumismaksun. Taulukko 8: Teoreettinen kustannuslaskelma Kustannuserä Yksikköhinta Määrä Summa Projektiryhmän työ 50 e/h 1360 h e Asiakkaan käyttämät tunnit 50 e/h 200 h e Asiakkaan materiaalikulut Yhteensä: 5000 e e 11

13 Vastaavanlainen projekti tulisi arvioiden mukaan maksamaan euroa asiakkaalle suurimpana menoeränään henkilöstökulut. Henkilöstökulut ovat laskettu kuitenkin varsin maltillisesti. Riippuen projektia tuottavan yrityksen sisäisistä kuluista ei ko. hinnalla kovin suuri voittomarginaali ole mahdollinen. 6 Työkalut ja menetelmät Kappaleessa käydään läpi projektissa käytettävät työkalut sekä kurssin vaatimat käytännöt projektin toteutuksessa. Lisäksi kurssin T Ohjelmistotuotannon erikoiskurssin vaatimuksen mukaiset SEPA-päiväkirjojen aiheet listataan luvussa. 6.1 Menetelmät Luku käsittelee projektissa käytetyt menetelmät, käytännöt ja työkalut. Osa menetelmistä on pakollisia kurssin puolesta ja niiden käyttö on arvostelun lähtökohtana Iteratiivinen kehittäminen Projekti tullaan kehittämään kolmessa iteraatiossa: Projektin suunnittelu (PP) - Projektin alustus ja suunnitelmat Implementaatio 1 (I1) - Tärkein toiminnallisuus Implementaatio 2 (I2) - Toiminnallisuuden integrointi, käyttöliittymä ja luovutus Jokaisen iteraation alussa karkealla tasolla suunnitellut tehtävät jaetaan pienempiin ja hallittavampiin osakokonaisuuksiin asiakkaan vaatimuksia kuunnellen. Perustana iteraation suunnitteluun on vaatimusmäärittely sekä tekniset määrittelyt joiden ajantasaisuus tarkistetaan asiakkaan kanssa ennen iteraation alkua. Iteraation pitää sisällään viikon mittaisia syklejä, joissa kyetään toteuttamaan ja seuraamaan projektia. Tämä tarkoittaa osaltaan sitä, että palavereissa hahmotetaan ja jaetaan seuraavan viikon työ ja seurataan sen edistymistä sekä tehtäväkohtaisesti että tunneittain sekä päätetään mahdolliset korjaavat toimenpiteet. Asiakkaalla on mahdollisuus viikoittaisen seurannan lisäksi (Projektin edistyminen on nähtävillä seuranta osiossa Wikissä keskiviikkoisin) tarkastaa jokaisen iteraation tuotokset iteraation lopulla järjestettävässä iteraatiodemossa. Jokaisen iteraation lopulla ryhmällä on esittää sovitun toiminnallisuuden sisältävä ja testattu ohjelmakokonaisuus. Tehtävä työ pyritään suunnittelemaan ja sopimaan mahdollisimman tarkasti ennen iteraation alkua, jotta iteraation aikana suuremmilta muutoksilta vältytään. Tällä osaltaan taataan kehittäjille työrauha ja edesautetaan asiakasta miettimään tarpeitaan mahdollisimman tarkasti Iteraatiosuunnittelu Ennen iteraatiota tai sen alussa pidetään asiakkaan kanssa palaveri jossa sovitaan ennalta mietittyjen kokonaisuuksien toteuttamisesta, vaatimusten priorisoinnista ja niiden toteuttamisesta sekä tulevan iteraation näkymistä. Toinen palaveri pyritään pitämään iteraation aikana, jolloin projektin eteneminen ja sovitut asiat tarkistetaan. Iteraation lopullinen tilannekatsaus pidetään jokaisen iteraation lopulla iteraatiodemossa. Iteraatioon kuuluvien tehtävien tarkempi työmääräarvio tehdään ennen päätöstä toteutettavista komponenteista, jotta asiakkaalla on mahdollisuus vaikuttaa budjetin mukaisesti iteraation 12

14 tehtäviin. Projektin budjetointi ja tehtävien ajastuksen vastuu on projektipäälliköllä. Pääarkkitehti hyväksyy iteraatiosuunnitelman työkokonaisuudet ja niiden ajastuksen Dokumentointi Projektipäällikön vastuulla on projektisuunnitelma, edistymisraportti ja iteraatiosuunnitelma. Laatupäällikkö vastaa vaatimusdokumentista ja testaukseen liittyvistä muista dokumenteista. (katselmointidokumentti, testaussuunnitelma, yms.) Pääarkkitehdin vastuulla on arkkitehtuuridokumentti. Dokumentit tuotetaan ensisijaisesti Wikiin jotta kaikilla on mahdollisuus tutustua niiden sisältöön jo kehitysvaiheessa. Lähempänä määräpäivää ne katselmoidaan ja hyväksyvän päätöksen jälkeen ne vedostetaan pdfformaattiin. Ennen julkaisua asiakas hyväksyy vielä dokumentin sisällön. Projektipäällikkö vastaa dokumenttien lopullisesta hyväksymisestä ja on vastuussa niiden jakelusta ja palauttamisesta. Dokumenteissa ja Wikissä olevat kuvat tuotetaan png-formaattiin. Dokumentin luoja on vastuussa myös siitä, että viimeisin versio ja palautettu versio ovat saatavilla Wikissä. Dokumenttikohtaisesti voidaan niiden tehtäviä jakaa. Jakamisesta ja koostamisesta vastaa kokonaisuudessaan projektiryhmä Tuntiraportointi Jokaisen henkilökohtaiset tunnit raportoidaan Wikiin välittömästi kyseisen tehtävän suorittamisen jälkeen. Tuntilistaan merkitään tehtävän osa-alue ja Wikin seuranta osiosta löytyvä tehtävä sekä mahdollinen kuvaus. Viikoittainen tuntiseuranta tapahtuu projektipäällikön toimesta tiistaisin, jolloin tärkeimmät mittarit ovat seurattavissa Seurantasivulla. Samalta sivulta voidaan seurata myös yksittäisten tehtävien ajankäyttöä verrattuna suunniteltuun. Projektipäällikkö vastaa myös tehtävien luomisesta ja päivittämisestä Ohjelmiston koon raportointi Borland Together kerää automaattista statiikkaan projektin lähdekoodista ja generoi niistä myös valmiita kaavioita. Alustavasti projektin kokoa tullaan seuraamaan koodirivien määrällä (yksikkö Kloc). Projektin edetessä tulee miettiä seurannan muita tarpeita ja työkalun niihin tarjoamia mahdollisuuksia. Pääarkkitehti on vastuussa tarpeellisten statistiikkojen tuottamisesta ja esittelemisestä johtoryhmän viikkopalaverissa. Projektipäällikkö seuraa kehitystä ja päättää mahdollisista toimenpiteistä yhdessä projektin johtoryhmän kanssa Kommunikaatio Projektilla on käytössään useita kommunikaatiokanavia. Ensisijainen kanava projektin jäsenten kesken ovat viikoittaiset palaverit (Projektin johtoryhmällä omansa ja pääarkkitehdin järjestämänä kehittäjille omansa). Muita kanavia ovat IRC (#softarojekti) johtoryhmän käyttöön, (#simutiimi) simulaattoritiimin käyttöön, (#valpastiimi) valpastiimin käyttöön sekä #epa EPA:a käsitteleviä asioita varten. Sähköpostin käytössä oleellista on harkita kenelle kaikille tieto on tarpeellinen ja osoittaa posti ainoastaan heille. Sähköpostissa TO-kenttään laitetaan sellaiset henkilöt joilta odotetaan toimenpiteitä. CCkenttään laitettaville sähköposti menee tiedoksi. Projektipäälliköllä on myös käytössä 20 tekstiviestiä päivittäin ryhmän sisäiseen nopeaa reagointia tai kriittistä informaatiota varten. Kommunikaatiokanavat on koottu seuraavaan taulukkoon odotetun vastausajan 13

15 perusteella. Taulukosta voidaan myös johtaa aikavälit joiden sisällä ryhmän jäsenen tulisi olla tavoitettavissa kussakin mediassa. Taulukko 9: Kommunikaatiokanavat ja vasteajat Kanava Odotettu vasteaika Kohderyhmä Puhelu Välitön - muutama tunti Kahdenkeskinen asia Tekstiviesti Välitön - muutama tunti Yksilö - Koko ryhmä IRC Välitön - vuorokausi Yksilö - Koko ryhmä Sähköposti Vuorokausi Yksilö - Projektin osaryhmä Wiki Yli vuorokausi Koko ryhmä Kyseisiä kanavia voidaan käyttää kommunikointiin myös ryhmän ulkopuolelle. Asiakkaalta ja Mentorilta odotetaan myös vastaavia vasteaikoja. Mentoriin ensisijaisesti on yhteydessä projektipäällikkö ja asiakkaaseen laatu- tai projektipäällikkö. Jokaisesta palaverista sen järjestämisesta vastuussa oleva henkilö kirjoittaa pöytäkirjan tai vapaamuotoisemman palaverimuistion. Muistiot lisätään Wikiin, SovitutPalaverit sivun alle. Projektipäällikkö lähettää asiakkaalle ja mentorille keskiviikkoon mennessä viikkoraportin edistymisestä ja tulevan viikon näkymistä Iteraatiodemo Projektipäällikkö vastaa iteraatiodemon järjestämisestä, kutsuu asianosaiset paikalle ja toimii iteraatiodemossa puheenjohtajana. Projektipäällikkö vastaa myös tilaisuudessa tarvittavasta materiaalista. Laatupäällikön vastuulla on järjestää iteraatiodemossa tuotteen esittely, varmistaa esityksen onnistuminen ja hankkia tarvittavat laitteet paikalle. Pääarkkitehti kertaa iteraation tuotannolliset asiat, tekniset yksityiskohdat ja oleelliset muutokset tuotteeseen ja arkkitehtuuriin Virheiden seuranta Virheiden seurantaan käytetään kurssin tarjoamaa Bugzilla-ohjelmistoa. Laatupäälliköllä on ensisijainen vastuu virheiden seurannasta ja menetelmän käytöstä. Kattavampi kuvaus virheiden seurannasta löytyy tämän dokumentin kappaleesta laadunvarmistussuunnitelma Versionhallinta Versionhallintaan käytetään Niksulan tarjoamaa CVS-työkalua (Concurrent Versions System). Repositorio sijaitsee koulun ympäristössä ja on täten ryhmäläisten tavoitettavissa. Ohje CVS:n käyttämiseksi löytyy Wikistä. Työkalu on valittu sen toiminnallisuuden ja tuttuuden takia. CVS:n käytössä noudatetaan seuraavia käytäntöjä: Vain valmiit ominaisuudet ja kääntyvä koodi päivitetään repositorioon. Muutokset kirjataan dokumentin muutoshistoriaan. Check-in tehdään selkeän kokonaisuuden jälkeen (Usean paikan muuttaminen yhdellä commitilla ei toivottavaaa) 14

16 Ohjelmointikäytännöt Yleisesti käytetään koodauskäytäntönä SUN:in esittelemää käytäntöä Lisäksi käytämme seuraavia käytäntöjä: Koodin kommentointi Javadoc-kommentointi o Jokaiselle luokalle o Jokaiselle metodille o Jokaiselle tärkeälle muuttujalle Geneeristä kommentointia o Luokan alkuun luonti- ja lyhyet muuttamistiedot (kuka, mitä, milloin?) o Yli viiden rivin metodiin selventäviä kommentteja mukaan Koodin ulkoasu Sisennys 4 välilyöntiä (ei tabulaattoria) Rivinleveys 80 merkkiä Vältetään yli sivun mittaisia metodeja Metodi- ja muuttujakutsuihin suorittaja eteen (this, super), ellei kyseessä ole staattinen metodi SEPA - Heuristinen arviointi Heuristinen arviointi on tuotteen tai käyttöliittymän arviointia ilman käyttäjiä tiettyihin käytettävyyssääntöihin vertaamalla. Heuristinen arvio tulisi tehdä 3-5 asiantuntijan voimin. Heuristisella arvioinnilla haetaan lopputuotteen hyvää käytettävyyttä. Projektissa menetelmää tullaan käyttämään ainakin ensimmäisen iteraation alussa prototyypin arviointiin ja parantamiseen sekä lopussa edesauttamaan käyttöliittymän kehittämistä SEPA Design patterns Suunnittelumallit (Design Patterns) ovat ohjelmiston rakenteen suunnittelussa hyväksi havaittuja yleisiä malleja. Suunnittelumallit toimivat arkkitehdin apuna suunnittelutyössä. SEPA tulee käsittelemään ns. Gang-of-Four suunnittelumalleja joita ovat mm. adapter, factory ja facade SEPA Staattiset metodit Käytännöllä staattiset metodit tarkoitetaan ohjelmiston (esim. lähdekoodin) analysointia ilman että sitä ajetaan. Staattisten metodien analyysi voi olla esimerkiksi koodikatselmuksien suorittamista. Tarkoituksena on mitata, analysoida ja parantaa ohjelmiston rakennetta sekä löytää siinä ilmeneviä virheitä. Projektin kontekstissa ohjelmiston kriittisiä osia tullaan katselmoimaan muiden tuotosten ohella SEPA Refaktorointi Refactoring tarkoittaa ohjelmakoodin rakenteen muuttamista ilman sen toiminnallisuuden muuttamista. Tällä tavoitellaan selkeämpää, luettavampaa ja ylläpidettävämpää koodia 15

17 lyhyemmässä ja alkuperäistä paremmassa muodossa. Projektin kannalta nämä ominaisuudet ovat varsin tärkeitä asiakkaan jatkokehityksen kannalta. Tarkoituksena on suorittaa refaktorointia jatkuvasti kehityksen aikana. Hyvä käytäntö on tarkistaa refaktorointitarve jokaisen metodin kirjoittamisen jälkeen ja työskentelyjakson päätyttyä. Näin koodin toiminnallisuutta ei tarvitse välttämättä kerrata. Yksinkertaisimmillaan refaktorointi voi olla esim. koodin muotoilu konventioiden mukaiseksi metodin kirjoittamisen jälkeen. 6.2 Työkalut Projektissa tullaan käyttämään seuraavan taulukon mukaisesti listaamia työkaluja. Listaus löytyy myös projektin Wikistä jossa listattu myös mahdollinen käyttöohje ja henkilö joka hallitsee työkalun käytön. Taulukko 10: Käytetyt työkalut Nimi Versio Lähde Tarkoitus Apache Ant Kääntäjä CVS Versionhallinta Jetty Www-palvelin Log4j Ohjelman toiminnan raportoija JUnit Testaustyökalu MagicDraw UML-työkalu Eclipse Koodin kehitystyökalu javadoc Kommentointi Wiki Tiedon välittäminen ja ylläpitäminen Irc Kommunikointi Cobertura Testien kattavuuden mittaaja Borland Together Architect products/together/index.html Asennusohjeet kurssin kotisivuilla Tools-valikon alla. Hibernate Tietokannan käsittely Quartz Skeduloija Spring Framework UI Framework 6.3 Standardit ja protokollat Standardeja tullaan päivittämään projektin kuluessa. Tähän mennessä mainittavan arvoiset käytettävät standardit tai protokollat ovat: TETRA (Terrestrial Trunked Radio) 16

18 LIP (Location Information Protocol) o Paikkatiedon välitys TETRA-verkossa HTML 4.01 (HyperText Markup Language) o Vaihtoehtoisesti XHTML 1.0 Säädökset palovaroittimien valvomiselle 7 Jaksotus Projekti on jaettu kolmeen iteraatioon. Seuraavassa luvussa kuvataan iteraatioiden tavoitteet, tuotokset, tehtävät sekä niiden työarviot ja tärkeät päivämäärät iteraation aikana. 7.1 Huomioitavaa Kurssin mahdollistama joululoma Loman käyttämisestä sovitaan I1 lopussa Aikavälillä projektia ei toteuteta Tuukka Laakso mahdollisesti lomamatkalla Joululomalla useat lyhyemmillä matkoilla tai lomalla 7.2 Aikataulu Seuraavassa on listattu projektin kolmen osan aikataulu. On huomioitava että vuoden 2005 lopussa on kurssin mahdollistama joululoma jonka käytöstä sovitaan etukäteen. näyttää siltä että lomaa lyhennetään kurssin mahdollistamasta osallistujien riittämättömän ajankäytön takia. Taulukko 11: Projektin Suunnittelu ( ) Päivä Kello Tapahtuma Selitys Osallistujat Viikkopalaveri Johtoryhmä Luento Software process, project planning Palautus Iteraatiosuunnitelma Luento Requirements management Vaatimusmäärittely Ensimmäinen versio valmis Luento Borland's development tools Arkkitehtuuri Iteraation arkkitehtuuri valmis Palautus Projektisuunnitelma, Vaatimusdokumentti, Edistymisraportti Luento Quality assurance Iteraatiodemo Mentor, Asiakas Taulukko 12: Implementaatio 1 ( ) 17

19 Päivä Kello Tapahtuma Selitys Osallistujat Projektin Kick-off Projektiryhmä Iteraatiosuunnitelman Iteraatio- ja QAsuunnitelma Markus, Kirsi palautus Mentor-tapaaminen Johtoryhmä Iteraation toiminnallisuus valmis Palautus SEPA-päiväkirjat Kaikki Palautus Kts. kurssin sivut Iteraatiodemo Johtoryhmä, asiakas, Menor Joululoma Päätetään Kaikki muöhemmin Pakollinen joululoma Kaikki Taulukko 13: Implementaatio 2 ( ) Päivä Kello Tapahtuma Selitys Osallistujat Palautus Iteraatio- ja QAsuunnitelma Kattilamäki, Rönkkö Iteraatiodemo Järjestelmän toiminnallisuus valmis Vertaistestaukseen luovutus Vertaistestauksen palaute Edistymisen seuraus Lopullinen järjestelmä ja ohjeet Palaute vertaisryhmälle Rönkkö Rönkkö Dokumenttien palautus Johtoryhmä 1. - Iteraatiodemot Mentor, Asiakas, Projektiryhmä Project Close-Out Party Taulukko 14: Testauksen aikataulu Projektiryhmä, Asiakas, Mentor Päivä/Viikko Mitä valmiina päivän lopussa/kyseisen viikon perjantaina? Viikko 44 Testeissä tarvittavat stubit Viikko 45 Testitapaukset Viikko 46 Automatisoidut intergointi testit Viikko Järjestelmän kehitys, noin viikko aikaa korjata löydetyt onglemat. Viikko 48 Systeemitason testaus 18

20 7.3 Projektin suunnittelu (PP) Projektin suunnitteluvaiheen tavoitteena on Aihealueen ymmärtäminen Asiakaskontaktin luominen Projektin alkuun saattaminen Alustava arkkitehtuuri Vaatimusmäärittely Laadunvarmistuksen suunnittelu Taulukko 15: Projektin suunnitteluvaiheen tehtävät 19

21 Kuva 3 - Projektin suunnitteluvaiheen aikataulu 7.4 Implementaatio 2 (I2) Projektin toisen iteraation tavoitteena on Laadukkaan lopputuotteen toimittaminen asiakkaalle Projektin oppien kokoaminen Toiminnallisuuksien integrointi Mahdollisen jatkokehityksen edistäminen (dokumentaatio, käyttöohje) Käyttöliittymän toteuttaminen Kurssin tavoitteellinen suorittaminen 8 Riskienhallinta Seuraavassa kappaleessa käsitellään projektiin liittyviä riskejä, niiden huomioimista, seurantaa ja torjuntaa. Riskienhallinnan päävastuu on projektipäälliköllä yhdessä johtoryhmän kanssa. Riskien seuranta tapahtuu viikoittain ja tulokset käsitellään johtoryhmän palaverissa. 20

22 8.1 Prosessi Oleellisena osana projektin seurantaa on riskien hallinta. Päävastuu riskien hallinnasta ja seurannasta kuuluu projektipäällikölle. Riskejä seurataan viikoittain johtoryhmän viikkopalaverissa ja projektipäällikkö päättää seuraavista toimenpiteistä. Jokaisen projektiin osallistuvan henkilön velvollisuus on ilmoittaa havaitsemastaan uudesta riskistä viipymättä projektipäällikölle. Näin riski saadaan kartoitettua, siihen voidaan valmistautua ja vaikutusta minimoida. Oleellista riskien hallinnassa on tunnistaa riskit, arvioida niiden vaikutus sekä hallita ja tarkkailla niitä. Riskin alttius riippuu sen todennäköisyydestä ja vaikutuksesta. Näiden määreiden korkeat arvot tietyssä riskissä on kirjattu kuhunkin riskiin. Kuva 4 - Riskienhallintaprosessi Projektin aikana on mahdollista käydä toteen myös projektista riippumattomia riskejä joihin ei voida varautua tai se ei ole järkevää. (esim. poikkeustila, luonnonmullistus) Kyseisenlaisia riskejä ei ole listattu riskilokiin. 8.2 Riskikategoriat Riskin poistuttua riski poistetaan listalta, uudet riskit kirjataan. K = Kriittinen, T = Todennäköinen Taulukko 16: Top 5 riskit 21

23 ID Toimenpiteet poistamiseksi listalta Vastuu S3 Tehostetaan tuntisuunnitelmien tekemistä ja seurantaa Kattilamäki P5 Pyritään tekemään projektin alijäämä pois joululomalla Johtoryhmä K2 Asetetaan realistiset tavoitteet, tiedostetaan tekemisen ja arvostelun yhteys Projektiryhmä T4 Perehdytään pimennossa oleviin osa-alueisiin joululomalla Johtoryhmä K4 Huolehditaan asiakkaan kanssa I2 suunnitelmassa että tekemistä riittää Kattilamäki Taulukko 17: Asiakkaan riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö A2 A3 Asiakas ei ymmärrä projektin prosessia ja siihen liittyviä asioita riittävällä tasolla Asiakkaalla ei riitä aikaa ja kiinnostusta projektille Asiakkaan ja projektiryhmän näkemys projektista ristiriitainen Vaadittava palaute asiakkaalta jää saamatta ja projektin laatu kärsii Lisäämällä kommunikaatiota ja sen laatua yhtenäistetään näkemykset Pyritään sitouttamaan asiakas projektiin ja saamaan riittävästi palautetta Rönkkö Kattilamäki Taulukko 18: Teknologiaan liittyvät riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Verkko ei kestä Tuotteen jatkokehitys ei Asiakas hyödyntää kertyneen kokemuksen T2 K vaadittua kuormitusta mielekästä muuten Rönkkö T3 K Ryhmällä ei demottavaa tuotetta iteraatiodemossa Arvosanan aleneminen Huolehditaan hyvissä ajoin ennen demoa ongelmien poistamisesta Kattilamäki T4 T Ryhmän jäsenillä ei tarvittavan laajuista kokonaisnäkemystä tuotteeseen Kokonaisuuden kannalta vääränlaisten ratkaisujen toteuttaminen, ei pystytä korvaamaan toisen työtä Tutustutaan toisten suorittamiin töihin sekä tutustutaan järjestelmään kokonaisuutena Laakso Taulukko 19: Sidosryhmään liittyvät riskit 22

24 ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Sidosryhmillä ei ole tarpeeksi tietoa järjestelmän Järjestelmä ei vastaa Taataan kaikkien osapuolein vahva S1 K rakentamiseen odotuksia näkemys projektiin Kattilamäki S2 Projektiryhmästä keskeyttää useampi henkilö Työpanoksen ja tietotaidon menetys Tehtävien jakaminen ja projektin scopen muutos vastaamaan resursseja Kattilamäki S3 T Projektiin osallistujilla ei ole tarpeeksi aikaa projektille Projekti ei pysy aikataulussa eikä määriteltyjä tavoitteita saavuteta Projektin edistymistä ja osallistujien ajankäyttöä on seurattava tarkasti. Kriittisessä tilanteessa resurssien käyttö suunniteltava uudelleen Kattilamäki Taulukko 20: Projektinhallintaan liittyvät riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö P2 K P3 T P4 T P5 Alihankkija ei saa ajoissa toimitettua tarvittavia komponentteja Vaatimukset ovat puutteelliset Projekti ei pysy budjetissa Projekti ei etene suunnitellussa tahdissa Suunnittelu ja toteutus vaikeutuu ja myöhästyy Lopputuote ei vastaa asiakkaan tarpeita Ei pystytä vastaamaan asiakkaan vaatimuksiin Vaadittu tuntimäärä ei täyty ja projekti myöhästyy Toteutetaan mahdollisimman joustavia komponentteja ja rajapintoja Tarpeeksi lyhyt palautesykli, prototyyppien käyttö ja läpinäkyvä prosessi Vaatimusten priorisointi ja karsiminen Budjetin ja ajankäyttösuunnitelmien päivittäminen ja työtuntien kiristäminen Laakso Rönkkö Kattilamäki Kattilamäki Taulukko 21: Järjestelmään liittyvät riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Projektin lopputuote ei skaalaudu Projektin tarkoituksen menettäminen enne Kolmannen iteraation J1 K jatkotuotantoon toista iteraatiota työn varmistaminen Kattilamäki J2 K Virve ei sovellu projektin vaatimaan toimintaan Ei tarkoitusta jatkotuottaa projektia Taulukko 22: Kurssin suorittamiseen liittyvät riskit Varmistetaan Virven toiminnallisuus projektin kontekstissa Kattilamäki 23

25 ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Projektin laatu ei vastaa Motivaatio projektiin Tarkistetaan ryhmän motivaatiotaso ja tavoitteet ja johdetaan niistä projektin tuotteiden K2 T ryhmän tavoitteita laskee laatutaso Kattilamäki K3 K K4 K Kurssin asettamat vaatimukset eivät täyty Projektin laajuus ei riitä kattamaan kurssin vaatimaa työmäärää Epätyydyttävä kurssin arvosana tai kurssin suorittamisen epäonnistuminen Kurssin laajuus ei täyty Verrataan toimintaa ja tuotoksia kurssin vaatimuksiin ja reagoidaan mentorin antamaan palautteeseen Johtoryhmä Huolehditaan ennen I2 alkua tarpeellisen työmäärän sopimisesta asiakkaan kanssa Kattilamäki Taulukko 23: Lailliset & kaupalliset riskit ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Dokumentit tarkisteaan ennen julkaisua ja rajataan kriittinen Erillisverkoille huono informaatio ulkopuolisilta L1 K maine (NDA) Kattilamäki L2 Projektista vuotaa kriittistä tietoa ulos Erillisverkkojen tuotteet sekoitetaan projektin tuotoksiin Erillisverkkojen myynin lasku Projektin selkeä nimeämiskäytäntö ja huhujen rajoittaminen Projektiryhmä L3 K Projektiryhmä rikkoo NDAta Mahdollinen haitta asiakkaalle ja rikkovan osapuolen vastuu Varmistetaan että kaikille osapuolille sopimuksen alainen aineisto on selvä ja rikkomustapauksissa neuvotellaan. TEKn jäsenillä mahdollisuus asianajajaan. Projektiryhmä Taulukko 24: Poistuneet riskit 24

26 ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö Teknologioiden Soveltuvat teknologiat Teknologiavalinnat eivät muuttaminen syö valitaan projektin alussa T1 sovellu projektiin resursseja tarkasti Laakso P1 K1 A1 K,T Arkkitehtuurin alkuunsaattamisen kannalta tärkeiden vaatimusten etsintä kestää liian pitkään Johtoryhmä ei opiskelullaan pysty paikkaamaan osaamisessaan olevia puutteita 9 Lähteet Arkkitehtuuri myöhästyy Vaikutus näkyy projektin lopputoutteessa ja arvostelussa Asiakkaalta ei saada selkeitä, tai edes Projektia on vaikea selkeähköjä, vaatimuksia saada onnistumaan Toteutetaan arkkitehtuuria sen hetkisten vaatimusten perusteella ja tehdään siitä mahdollisimman helposti muutettava Ylimääräisen ajan käyttäminen opiskeluun ja neuvojen hankkimiseen Parannetaan kommunikaatiota ja vaatimusten määrittelyprosessia Laakso Johtoryhmä Rönkkö 1. "Software Project Management", Hughes, B. Cotterell, M. McGraw-Hill 2002, ISBN X 2. "Projektihallinnan käsikirja", Pelin, R. 1. painos Projektijohtaminen Oy "Software Engineering 7", Sommerville, I. ISBN "Object-Oriented and Classical Software Engineering", Schach, S. McGraw-Hill "An introduction to SEMS Approach", Rautiainen, R. Vähäniitty, J. 25