T-76.4115 Ohjelmistokehitysprojekti I Projektisuunnitelma (PP)

T-76.4115 Ohjelmistokehitysprojekti I Projektisuunnitelma (PP) Versio Päiväys Muokkaaja Kuvaus 1.50 16.10.2005 Kattilamäki Kattilamäki Palautettava versio 1.00 02.10.2005 Rönkkö Rönkkö Lisätty muutosloki 1. Johdanto...2 1.1 Yleiskatsaus projektiin Valpas...3 1.2 Käytetyt termit...4 2. Sidosryhmät ja jäsenet...4 2.1 Organisaatiokaavio...4 2.2 Yhteystiedot...5 3. Tavoitteet ja lopettamiskriteerit...5 3.1 Asiakkaan tavoitteet...6 3.2 Projektiryhmän tavoitteet...6 3.3 Henkilökohtaiset oppimistavoitteet...6 3.4 Projektin keskeytys- ja lopetuskriteerit...7 4. Resurssit ja budjetti...7 4.1 Henkilökunta...8 4.2 Materiaalit...8 4.3 Budjetti...8 5. Työkalut ja menetelmät...9 5.1 Menetelmät...9 5.1.1 Iteratiivinen kehittäminen...9 5.1.2 Iteraatiosuunnittelu...9 5.1.3 Dokumentointi...10 1

5.1.4 Riskien hallinta...10 5.1.5 Tuntiraportointi...10 5.1.6 Ohjelmiston koon raportointi...10 5.1.7 Kommunikaatio...10 5.1.8 Iteraatiodemo...11 5.1.9 Virheiden seuranta...11 5.1.10 Versionhallinta...11 5.1.11 Ohjelmointikäytännöt...12 5.1.12 Vertaistestaus...12 5.1.13 Vaatimusten hallinta...12 5.1.14 SEPA - Heuristinen arviointi...12 5.1.15 SEPA - Design Patterns...13 5.1.16 SEPA - Static Methods...13 5.1.17 SEPA Refactoring...13 5.3 Työkalut...13 5.4 Standardit...14 6. Jaksotus...14 6.1 Aikataulu...14 6.2 Projektisuunnnittelu...16 6.2.1 Projektin suunnittelu (PP)...16 6.2.2 Ensimmäinen iteraatio...17 6.2.3 Toinen iteraatio...17 7. Riskienhallinta...17 7.1 Prosessi...17 7.2 Riskikategoriat...18 7.2.1 TOP 5 riskit...18 7.3.1 Asiakas...19 7.3.2 Teknologia...19 7.3.3 Sidosryhmä...19 7.3.4 Projektinhallinta...20 7.3.5 Järjestelmä...21 7.3.6 Kurssi...21 7.3.7 Laillinen / Kaupallinen...21 8. Lähteet...22 1. Johdanto Tämä dokumentti on ryhmän Neptune projektisuunnitelma Teknillisen Korkeakoulun kurssin T-76.4115 Ohjelmistokehitysprojekti I puitteissa toteutettavaan projektiin. Asiakkaana toimii Indagon Oy. Indagon Oy on mobiilipaikannukseen erikoistunut yritys. Projekti on tarkoitus suorittaa aikavälillä 27.9.2005-2.3.2006. 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ä 2

noudatettavia käytäntöjä. Ne on mainittu tässä dokumentissa. Projektin aihe on Indagon Oy esittämä ja kuvataan seuraavassa kappaleessa. 1.1 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 luotettavasti niiden toimivuus. Järjestelmä vastaa tähän tarpeeseen ja toteuttaa toiminnallisuuden Tetra-verkossa. Projektin tarkoitus on ensimmäisessä vaiheessa toteuttaa prototyyppi järjestelmästä, jonka perusteella voidaan tarpeen mukaan jatkokehittää kaupallinen tuote. Kuva 1 - Projektin toteuttama järjestelmä Projektin tarkoituksena on kehittää TETRA-verkon päällä toimiva simulaatio, jolla on tarkoitus testata tulevaisuudessa toimivan järjestelmän luotettavuutta. 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 SDSviestejä kuten myös vastaanottamaan niitä. 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ää. 3

1.2 Käytetyt termit Termi/Lyhenne Selitys EPA Downlink Edustapalvelin, Tetra-verkon reunalla oleva palvelin, joka tarjoaa Tetraverkon palveluita helpommin käytettävällä tavalla sovelluksille. Kanava jota pitkin viesti kulkee Valppaalta puhelimelle. Ilmoitinkeskus Rakennuksessa oleva keskus, johon kaikki rakennuksessa olevat hälytin anturit/sensorit on kytketty. Linjavika MTT Vika yhteydessä Valppaan ja puhelimen välillä. Mobile Telematics Terminal. Indagon Oy:n kehittämä laite, joka osaa kertoa koordinaatit paikasta, jossa laite sijaitsee. Ryhmäosoite SDS Tetra TMR880 Uplink Valpas Virve Yksilöosoite (K)loc SEPA 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 vaihtelevan pituinen. Terrestial Trunked Radio (Tetra-verkko on viranomaiskäyttöön tarkoitettu puhelinverkko) Nokian puhelinmalli TETRA-verkkoon. Kanava jota pitkin viesti kulkee puhelimelta Valppaalle. Toteutettava järjestelmä (ValvontaPalvelinSysteemi) Suomessa oleva viranomaisverkko joka toimii tetra-järjestelmällä. Vastaa TETRA-verkossa tavallista puhelinnumeroa. (Kilo) Lines Of Code, Koodirivien määrä (tuhansissa) Software Engineering Practice. Kurssin vaatima selvitys käytettävistä menetelmistä. 2. Sidosryhmät ja jäsenet Taulukko 1 - Käytetyt termit 2.1 Organisaatiokaavio Liitteessä 1 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. 4

Kuva 2 - Sidosryhmien väliset riippuvuudet 2.2 Yhteystiedot Nimike Nimi Email Luennoija Jari Vanhanen jari.vanhanen#hut.fi Laatupalkinto Vesa Luomala vesa.luomala#accenture.com Mentor Kari Suhonen kari.suhonen#hut.fi Asiakas Markus Maanoja markus.maanoja#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 Kehittäjä Antti Poikela aspoikel#cc.hut.fi Taulukko 2 - Yhteystiedot Projektin Wiki löytyy osoitteesta http://rivendell.tky.hut.fi/projekti/ ja vaatii käyttäjältään käyttäjätunnuksen ja salasanan. 3. Tavoitteet ja lopettamiskriteerit Projektin tavoitteena on rakentaa seurantajärjestelmän 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. 5

3.1 Asiakkaan tavoitteet ID Tavoite Täyttymiskriteeri A1 Mahdollinen kaupallinen tuote tuhansille käyttäjille Prototyypin onnistunut toteuttaminen A2 Teknisen neuvojan lopputyön tekeminen aiheesta A3 Aihealueesta oppiminen ja tietämyksen laajentaminen A4 Kaupallistamisen selvittäminen A5 Asiakkaan ohjelmistoprosessin kehittäminen A6 Tetra-verkon käytettävyyden lisäselvitys Lopputyön toteuttaminen Projektin menestyksekäs suorittaminen Prototyypin toimivuus Asiakkaan prosessien kehittyminen, asiakas toteaa itse. Prototyypin toimivuus ja skaalautuvuus Taulukko 3 - Asiakkaan tavoitteet 3.2 Projektiryhmän tavoitteet ID Tavoite Täyttymiskriteeri R1 Opintosuoritus hyvällä arvosanalla Kurssin suoritus hyvällä arvosanalla R2 Aihealueesta oppiminen R3 Laajemmassa ohjelmistoprojektissa toimiminen R4 Laadukkaan ja asiakkaalle arvoa tuottavan ohjelmiston toimittaminen Oppimiskokemusten kerääminen projektin jälkeen Projektin tyydyttävä suoritus Projektin lopputuotetta jatkokehitetään Taulukko 4 - Projektiryhmän tavoitteet 3.3 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 Oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä 6

Rönkkö Oppia vetämään projektia paremmin, hallitsemaan sitä sekä oppia laadunvarmistukseen liittyviä asioita, sekä kehittyä testauksen saralla Taulukko 5 - Henkilökohtaiset oppimistavoitteet 3.4 Projektin keskeytys- ja lopetuskriteerit Projekti ja kurssin suorittaminen voidaan keskeyttää ryhmän yhteisellä päätöksellä jos jokin seuraavista tilanteista toteutuu 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ä 2.3.2006. Tällöin dokumentit ja lopputuote toimitetaan viimeistään asiakkaalle kaikissa tapauksissa. Muita mahdollisia projektin lopetuskriteereitä voivat olla seuraavia edellyttäen että työ on toimitettu asiakkaalle. Käytettävän työmäärän täyttyminen Projektin valmistuminen ennen määräpäivää 4. Resurssit ja budjetti PP I1 I2 yht. Suunnittelu 50 32 20 102 Dokumentointi 64,8 80 90 234,8 Infrastruktuuri 4,4 40 10 54,4 Luento 40,8 0 0 40,8 Palaveri 40 98 90 228 Ohjelmointi 0 200 205 405 Hallinnointi 20 40 35,2 95,2 Opiskelu 20 51,6 10 81,6 Testaus 0 41,6 56,6 98,2 Kommunikaatio 5 5 0 10 Muu 5 5 0 10 Yhteensä 250 593,2 516,8 1360 Taulukko 6 - Kurssin edellisiin projekteihin perustuva arvio ajankäytöstä 7

4.1 Henkilökunta Jäsen I0 I1 I2 Yhteensä Kattilamäki 78 47 45 170 Rönkkö 72 50 48 170 Laakso 50 61 59 170 Halttunen 10 89 71 170 Huttunen 10 89 71 170 Kettunen 10 89 71 170 Närjänen 10 89 71 170 Poikela 10 80 80 170 250 594 516 1360 Taulukko 7 - Arvioidut työmäärät kussakin iteraatiossa 4.2 Materiaalit 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 tarjoamien koneiden puitteissa. 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: 1 kpl kannettava tietokone 1-3 kpl Tetra-verkon puhelinta MTT & antenni sijainnin määrittämiseksi 4.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. Kustannuserä Yksikköhinta Määrä Summa Projektiryhmän työ 50 e/h 1360 h 68 000 e 8

Asiakkaan käyttämät tunnit 50 e/h 200 h 10 000 e Asiakkaan materiaalikulut 5000 e Yhteensä: 83 000 e Taulukko 8 - Teoreettinen kustannuslaskelma Vastaavanlainen projekti tulisi arvioiden mukaan maksamaan 83 000 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. 5. Työkalut ja menetelmät 5.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. 5.1.1 Iteratiivinen kehittäminen Projekti tullaan kehittämään kolmessa iteraatiossa: Projektin suunnittelu (PP) - Projektin alustus ja suunnitelmat Iteraatio 1 (I1) - Tärkein toiminnallisuus ja käyttöliittymä Iteraatio 2 (I2) - Toiminnallisuuden integrointi ja projektin 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 aikana viikoittaisissa sykleissä (Heartbeat) vaatimukset ja tekniset määrittelyt tarkentuvat. Asiakkaalla on mahdollisuus viikoittaisen seurannan lisäksi tarkistaan jokaisen iteraation tuotokset iteraation lopulla järjestettävässä iteraatiodemossa. 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. 5.1.2 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. Iteraation kuuluvien tehtävien tarkempi työmääräarvio tehdään ennen päätöstä toteutettavista komponenteista jotta asiakkaalla on mahdollisuus vaikuttaa budjetin mukaisesti iteraation 9

tehtäviin. Projektin budjetointi ja tehtävien ajastuksen vastuu on projektipäälliköllä. Pääarkkitehti hyväksyy iteraatiosuunnitelman työkokonaisuudet ja niiden ajastuksen. 5.1.3 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ä 5.1.4 Riskien hallinta Kts. luku 7. 5.1.5 Tuntiraportointi Jokaisen henkilökohtaiset tunnit raportoidaan Wikiin välittömästi kyseisen tehtävän suoritettua. Tuntilistaan merkitään tehtävän osa-alue ja seurannasta löytyvä tehtävä tai sen kuvaus. Viikoittainen tuntiseuranta tapahtuu projektipäällikön toimesta tiistaisin, jolloin tärkeimmät mittarit ovat seurattavissa Seuranta-sivulla. Samalta sivulta voidaan seurata myös yksittäisten tehtävien ajankäyttöä verrattuna suunniteluun. Projektipäällikkö vastaa myös tehtävien luomisesta ja päivittämisestä. 5.1.6 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 statiikoiden tuottamisesta ja esittelemisestä johtoryhmän viikkopalaverissa. Projektipäällikkö seuraa kehitystä ja päättää mahdollisista toimenpiteistä yhdessä projektin johtoryhmän kanssa. 5.1.7 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) ja sähköposti. 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ä. CC-kenttää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 10

taulukkoon odotetun vastausajan perusteella. Taulukosta voidaan myös johtaa aikavälit joiden sisällä ryhmän jäsenen tulisi olla tavoitettavissa kussakin mediassa. 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ä Taulukko 9 - Kommunikaatiokanavat 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ö. 5.1.8 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. 5.1.9 Virheiden seuranta Testeissä löydetyistä vioista (bugeista) pidetään kirjaa. Oleellista on selvittää mistä syystä vika on päässyt syntymään ja kuinka jatkossa menetellään jotta vastaavanlaista virhettä ei pääse syntymään. Laatupäällikkö on vastuussa virhelokin ylläpidosta ja virheiden vaatimista toimenpiteistä. Loki tulee olla kaikkien saatavilla ja nähtävillä jotta siitä olisi myös hyötyä. (Esim. Wiki) Vertaistestausta suorittavan ryhmän kanssa voidaan sopia menettelyistä jos listaus on salasanan takana. 5.1.10 Versionhallinta Versionhallintaan käytetään koulun tarjoamaa (Niksula) CVS (Concurrent Versions System) työkalua. Repositorio sijaitsee koulun ympäristössä ja on täten ryhmäläisten tavoitettavissa. Ohje CVS käyttämiseksi löytyy http://rivendell.tky.hut.fi/projekti/cvs-ohje. Työkalu on valittu sen toiminnallisuuden ja tuttuuden takia. CVS käytössä noudatetaan seuraavia käytäntöjä: Vain valmiit ominaisuudet ja kääntyvä koodi päivitetään repositorioon. Muutokset kirjataan dokumentin muutoshistoriaan. 11

Check-in tehdään selkeän kokonaisuuden jälkeen (Usean paikan muuttaminen yhdellä commitilla ei toivottavaaa) Käytäntöjä tullaan päivittämään kun työkalu saadaan käyttöön. 5.1.11 Ohjelmointikäytännöt Yleisesti käytetään koodauskäytäntönä SUN:in esittelemää käytäntöä http://java.sun.com/docs/codeconv/html/codeconvtoc.doc.html 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 muuttuja kutsuihin suorittaja eteen (this, super), ellei kyseessä ole staattinen metodi. 5.1.12 Vertaistestaus Kurssin vaatimusten perusteella tullaan suorittamaan vertaistestausta yhteistyössä toisen kurssia suorittavan projektiryhmän kanssa. Asiakkaan vaatimuksena on että lähdekoodia ei näytetä projektin ulkopuolelle. Tämä otetaan huomioon testattaessa ainoastaan valmiita paketteja. Toisen rajoitteet testaukselle asettaa testauksen vaatima laitteisto. Riippuen ryhmien sopimista menettelyistä, vertaistestaukseen tullaan sopimaan tietty määrä resursseja kummastakin ryhmästä. Vertaistestaus suunnitellaan vertaisryhmän projektin ominaisuuksista riippuen. Vertaistestauksesta lisää laadunvarmistusdokumentissa. 5.1.13 Vaatimusten hallinta Katso Vaatimustenhallintadokumentti 5.1.14 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ämisessä. 12

5.1.15 SEPA - Design Patterns Suunnittelumallit (Design Patterns) ovat ohjelmiston rakenteen 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, facade, jne. 5.1.16 SEPA - Static Methods Static methods tarkoitetaan ohjelmiston (esim. lähdekoodin) analysointia ilman että sitä ajetaan. Static methods analyysi voi olla mm. 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. 5.1.17 SEPA Refactoring Refactoring tarkoittaa ohjelmakoodin rakenteen muuttamista ilman sen toiminnallisuuden muuttamista. Tällä tavoitellaan selkeämpää, luettavampaa ja ylläpidettävämpää koodia lyhyemmässä ja alkuperäistä paremmassa muodossa. Projektin kannalta nämä ominaisuudet ovat varsin tärkeät asiakkaan jatkokehityksen kannalta. Tarkoituksena on suorittaa refactorointia jatkuvasti kehityksen aikana. Esimerkiksi hyvä käytäntö tarkistaa refactorointitarve on jokaisen metodin kirjoittamisen jälkeen ja työskentelyjakson päätyttyä. Näin koodin toiminnallisuutta ei tarvitse välttämättä kerrata. Yksinkertaisimmillaan refactoring voi olla esim. koodin muotoilu konventioiden mukaiseksi metodin kirjoittamisen jälkeen. 5.3 Työkalut Nimi Versio Lähde Tarkoitus Apache Ant http://ant.apache.org/ Kääntäjä CVS http://cvsbook.redbean.com/cvsbook.html Versionhallinta Jetty http://jetty.mortbay.org/jetty/ Www-palvelin Log4j http://logging.apache.org/log4j/ Ohjelman toiminnan raportoija JUnit http://www.junit.org/ Testaustyökalu MagicDraw http://www.magicdraw.com/ UML-työkalu Eclipse http://www.eclipse.org/ Koodin kehitystyökalu javadoc http://java.sun.com/j2se/javadoc/ Kommentointi Wiki http://moinmoin.wikiwikiweb.de/ Tiedon välittäminen ja ylläpitäminen Irc http://www.irc.org/ Kommunikointi Cobertura http://cobertura.sourceforge.net/ Testien kattavuuden mittaaja 13

Borland Together Architect 2006 http://www.borland.com/us/ Asennusohjeet kurssin kotisivuilla Tools-valikon alla. products/together/index.html Hibernate 3.0.5 http://www.hibernate.org/ Tietokannan käsittely Quartz 1.5.1 http://www.opensymphony.com/quartz/ Skeduloija Spring Framework 5.4 Standardit 1.2.5 http://www.springframework.org/ UI Framework Taulukko 10 - Käytetyt työkalut Standardeja tullaan päivittämään projektin kuluessa. Tähän mennessä mainittavan arvoiset käytettävät standardit tai protokollat ovat: TCS (Tetra Connectivity Server) LIP (Location Information Protocol) o Paikkatiedon välitys Tetra-verkossa HTML 4.01 (HyperText Markup Language) o Tai vaihtoehtoisesti XHTML 1.0 Säädökset palovaroittimien valvomiselle 6. 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. 6.1 Aikataulu Projektin aikataulun kuvaaja löytyy liitteestä 2. Päivä Kello Tapahtuma Selitys Osallistujat 27.9.2005 11.30 Viikkopalaveri Johtoryhmä 27.9.2005 16.15 Luento Software process, project planning 3.10.2005 13.00 Palautus Iteraatiosuunnitelma 4.10.2005 16.15 Luento Requirements management 9.10.2005 18.00 Vaatimusmäärittely Ensimmäinen versio valmis 11.10.2005 16.15 Luento Borland's development tools 18.00 Arkkitehtuuri Iteraation arkkitehtuuri valmis 17.10.2005 13.00 Palautus Projektisuunnitelma, 14

Vaatimusdokumentti, Edistymisraportti 18.10.2005 16.15 Luento Quality assurance 19.10.2005 Iteraatiodemo Johtoryhmä, Mentor, Asiakas Taulukko 11 - Projektin Suunnittelu (27.9.- 20.10.2005) Päivä Kello Tapahtuma Selitys Osallistujat 20.10.2005 Project Kick-off Projektiryhmä, Asiakas, Mentor 24. - Asiakaspalaveri 26.10.2005 31.10.2005 13.00 Iteraatiosuunnitelman palautus 1.11. - Mentor-tapaaminen 4.11.2005 Iteraation suunnittelu Iteraatio- ja QAsuunnitelma Johtoryhmä Kattilamäki, Rönkkö Johtoryhmä 5.12.2005 13.00 Iteraation toiminnallisuus valmis 5.12.2005 13.00 Palautus SEPA-päiväkirjat 5.12.2005 13.00 Palautus Kts. kurssin sivut 7. - 8.12.2005 Iteraatiodemo Johtoryhmä, asiakas, Menor 9.12.2005-15.1.2006 Joululoma Päätetään muöhemmin Kaikki Taulukko 12 - Ensimmäinen Iteraatio (21.10.- 8.12.2005) Päivä Kello Tapahtuma Selitys Osallistujat 18.1.2006 13.00 Palautus Iteraatio- ja QAsuunnitelma Kattilamäki, Rönkkö 1. - 3.2.2006 Iteraatiodemo 10.2.2006 13.00 Järjestelmän toiminnallisuus valmis 17.2.2006 13.00 Vertaistestaukseen luovutus Edistymisen seuraus Lopullinen järjestelmä ja ohjeet 21.2.2006 13.00 Vertaistestauksen palaute Palaute vertaisryhmälle Rönkkö Rönkkö 27.2.2006 13.00 Dokumenttien palautus Johtoryhmä 15

1. - 2.3.2006 3. - 4.3.2006 Iteraatiodemot Project Close-Out Party Mentor, Asiakas, Projektiryhmä Projektiryhmä, Asiakas, Mentor 6.2 Projektisuunnnittelu 6.2.1 Projektin suunnittelu (PP) Taulukko 13 - Toinen Iteraatio (16.1. - 2.3.2006) Projektin suunnitteluvaiheen tavoitteena on Aihealueen ymmärtäminen Asiakaskontaktin luominen Projektin alkuun saattaminen Alustava arkkitehtuuri Vaatimusmäärittely Laadunvarmistuksen suunnittelu Projektin suunnitteluvaiheen tuotokset ja työarvio Suunnittelu (50 h) o Projektisuunnitelma o Arkkitehtuuri Dokumentointi (64,8 h) o Iteraatiosuunnitelma (20 h) o Vaatimusdokumentti (5,8 h) o Edistymisraportti (7 h) o Projektisuunnitelma (10 h) o Arkkitehtuuri (3 h) o Vaatimusmäärittely (19 h) Infrastruktuuri (4,4 h) o Wikin pystytys (3 h) o CVS pystytys (1,4 h) Luento (40,8 h) Palaveri (40 h) o Viikkopalaverit 38-42 (12 h) o Asiakaspalaveri (9 h) o Mentor-tapaaminen (10 h) Hallinnointi (20 h) o Tuntiraportointi 11.10 (3 h) o Aiheen valmistelu (6 h) o Palaverien valmistelu (3,5 h) o Projektinhallinta (7,5 h) Opiskelu (20 h) 16

o Kertaus (1 h) o Laatuasiat (1,5 h) o Käytettävät työkalut (16 h) o Muu (1,5) Kommunikaatio (5 h) Muu (5 h) 6.2.2 Ensimmäinen iteraatio Projektin ensimmäisen iteraation tavoitteena on Tärkeimpien toiminnallisuuksien toteuttaminen Arkkitehtuurin ja vaatimusten tarkentaminen Käyttöliittymän kehittäminen, testaus ja arviointi Kattava testaus ja käytäntöjen juurruttaminen Projektin osa-alueille varattu aika nähdään taulukosta 5. Tarkempi tehtäväkuvaus ja aikataulu ensimmäisen ja toisen iteraation suunnitelmasta. 6.2.3 Toinen iteraatio Projektin toisen iteraation tavoitteena on Laadukkaan lopputuotteen toimittaminen asiakkaalle Projektin oppien kokoaminen Toiminnallisuuksien integrointi Mahdollisen jatkokehityksen edistäminen (dokumentaatio, käyttöohje) Kurssin tavoitteellinen suorittaminen 7. Riskienhallinta 7.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. 17

Kuva 3 - 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. 7.2 Riskikategoriat Riskin poistuttua riski poistetaan listalta, uudet riskit kirjataan. K = Kriittinen, T = Todennäköinen 7.2.1 TOP 5 riskit ID Toimenpiteet poistamiseksi listalta Vastuu S1 Varmistetaan projektiryhmän osaamistaso. Järjestetään tarvittaessa Laakso koulutusta T1 Valittavat teknologiat tutkitaan perusteellisesti ja hyväksytetään ne myös asiakkaalla S3 Varmistetaan että jokainen on tietoinen vaaditusta työmäärästä ja on valmis varaamaan sen J2 Tehdään verkolle rasitustestit Rönkkö Kattilamäki Rönkkö 18

L3 Huolehditaan että kaikki ymmärtävät vastuunsa ja noudattavat sitä Kattilamäki 7.3.1 Asiakas ID Riski Vaikutus Korjaavat toimenpiteet A1 K Asiakkaalta ei saada selkeitä, tai edes selkeähköjä, vaatimuksia Projektia on vaikea saada onnistumaan Parannetaan kommunikaatiota ja vaatimusten määrittelyprosessia Vastuuhenkilö Rönkkö A2 Asiakas ei ymmärrä projektin prosessia ja siihen liittyviä asioita riittävällä tasolla Asiakkaan ja projektiryhmän näkemys projektista ristiriitainen Lisäämällä kommunikaatiota ja sen laatua yhtenäistetään näkemykset Rönkkö 7.3.2 Teknologia ID Riski Vaikutus Korjaavat toimenpiteet T1 Teknologiavalinnat Teknologioiden Soveltuvat eivät sovellu muuttaminen syö teknologiat valitaan projektiin resursseja projektin alussa T2 K Verkko ei kestä vaadittua kuormitusta Tuotteen jatkokehitys ei mielekästä tarkasti Hyödynnetään kertynyt kokemus muuten Vastuuhenkilö Laakso Rönkkö 7.3.3 Sidosryhmä ID Riski Vaikutus Korjaavat toimenpiteet S1 K Sidosryhmillä ei ole tarpeeksi tietoa järjestelmän rakentamiseen Järjestelmä ei vastaa odotuksia Taataan kaikkien osapuolien näkemys projektiin Vastuuhenkilö Kattilamäki 19

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 7.3.4 Projektinhallinta ID Riski Vaikutus Korjaavat toimenpiteet P1 Arkkitehtuurin alkuun Arkkitehtuuri Toteutetaan saattamisen myöhästyy arkkitehtuuria sen kannalta tärkeiden hetkisten vaatimusten vaatimusten etsintä perusteella ja tehdään kestää liian pitkään siitä mahdollisimman helposti muutettava P2 K Alihankkija ei saa ajoissa toimitettua tarvittavia komponentteja P3 T Vaatimukset ovat puutteelliset P4 T Projekti ei pysy budjetissa P5 Kriittinen osakokonaisuus ylittää budjetin Suunnittelu ja toteutus vaikeutuvat ja myöhästyvät Lopputuote ei vastaa asiakkaan tarpeita Ei pystytä vastaamaan asiakkaan vaatimuksiin Projektia ei pystytä jatkamaan suunnitellusti Toteutetaan mahdollisimman joustavia komponentteja ja rajapintoja Tarpeeksi lyhyt palautesykli, prototyyppien käyttö ja läpinäkyvä prosessi Vaatimusten priorisointi ja karsiminen Projektin uudelleen aikatauluttaminen ja korvaavien toimenpiteiden suorittaminen Vastuuhenkilö Laakso Laakso Rönkkö Kattilamäki Kattilamäki 20

7.3.5 Järjestelmä ID Riski Vaikutus Korjaavat toimenpiteet J1 K Projektin lopputuote ei skaalaudu jatkotuotantoon Projektin tarkoituksen menettäminen enne toista iteraatiota Toisen iteraation työn varmistaminen Vastuuhenkilö Kattilamäki J2 K Virve ei sovellu projektin vaatimaan toimintaan Ei tarkoitusta jatkotuottaa projektia Varmistetaan Virven toiminnallisuus projektin kontekstissa Rönkkö 7.3.6 Kurssi ID Riski Vaikutus Korjaavat toimenpiteet K1 Johtoryhmä ei Vaikutus näkyy Ylimääräisen ajan opiskelullaan pysty projektin käyttäminen paikkaamaan lopputuotteessa ja opiskeluun ja osaamisessaan arvostelussa neuvojen olevia puutteita hankkimiseen K2 T Projektin laatu ei vastaa ryhmän tavoitteita Motivaatio projektiin laskee Tarkistetaan ryhmän motivaatiotaso ja tavoitteet ja johdetaan niistä projektin tuotteiden laatutaso Vastuuhenkilö Johtoryhmä Kattilamäki 7.3.7 Laillinen / Kaupallinen ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö L1 K Projektista vuotaa kriittistä tietoa ulos Asiakkaalle huono maine Dokumentit tarkistetaan ennen julkaisua ja rajataan kriittinen informaatio ulkopuolisilta (NDA) Kattilamäki 21

L2 Asiakkaan tuotteet sekoitetaan projektin tuotoksiin Asiakkaan myynnin lasku Projektin selkeä nimeämiskäytäntö ja huhujen rajoittaminen Projektiryhmä L3 K Projektiryhmä rikkoo NDA:ta Mahdollinen haitta asiakkaalle ja rikkovan osapuolen vastuu Varmistetaan että kaikille osapuolille sopimuksen alainen aineisto on selvä ja rikkomustapauksissa neuvotellaan. TEK:n jäsenillä mahdollisuus asianajajaan. Projektiryhmä 8. Lähteet 1. "Software Project Management", Hughes, B. Cotterell, M. McGraw-Hill 2002, ISBN 00770 9834X 2. "Projektihallinnan käsikirja", Pelin, R. 1. painos Projektijohtaminen Oy 1996 3. "Software Engineering 7", Sommerville, I. ISBN 0-321-21026-3 4. "Object-Oriented and Classical Software Engineering", Schach, S. McGraw-Hill 2002 5. "An introduction to SEMS Approach", Rautiainen, R. Vähäniitty, J. 22

23 T-76.4110 Ohjelmistoprojekti I

24 T-76.4110 Ohjelmistoprojekti I