Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Projektisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 0.1 24.10.2003 Jouni Karppinen Dokumenttipohja otettu käyttöön. 0.2 25.10.2003 Hannu Kauppinen Lisätty paljon sisältöä. 0.3 26.10.2003 Hannu Kauppinen Viimeistelty sisältöjä, lisätty taulukoita kurssin vaatimusten mukaisesti. 0.4 26.10.2003 Tuomas Luttinen Kuvausta teknisestä puolesta lisätty. 1.0 26.10.2003 Jouni Karppinen & Mitro Kuha Lisätty riskienhallintaa koskeva osuus. Dokumentti tarkastettu ja korjattu PP-vaiheen palautusta varten. 1.1 26.11.2003 Hannu Kauppinen Päivitetty dokumenttia palautteen perusteella sekä täsmennetty projektin vaiheiden kuvauksia. 1.2 29.11.2003 Hannu Kauppinen Muutettu organisaatiorakennetta ja lisätty uusien työkalujen kuvaukset. 2.0 30.11.2003 Jouni Karppinen Päivitetty aikataulutuskappaletta. Dokumentti tarkastettu ja korjattu I1-vaiheen palautusta varten.
Sisällysluettelo 1 Esittely... 1 1.1 Projektin tarkoitus ja tavoite... 1 1.2 Järjestelmä ja ympäristö... 1 1.3 Oikeudet projektin lopputuloksiin... 1 2 Projektin sidosryhmät... 2 2.1 Työryhmä... 2 2.1.1 Jouni Karppinen... 3 2.1.2 Hannu Kauppinen... 3 2.1.3 Joonas Kekoni... 3 2.1.4 Mitro Kuha... 4 2.1.5 Tuomas Luttinen... 4 2.1.6 Vesa Salento... 4 2.1.7 Kalle Valo... 4 2.2 Asiakas... 5 2.3 Kurssin edustajat... 5 3 Projektin tavoitteet ja päätöskriteerit... 6 3.1 Asiakkaan tavoitteet... 6 3.2 Työryhmän tavoitteet... 7 3.2.1 Jouni Karppinen... 7 3.2.2 Hannu Kauppinen... 7 3.2.3 Joonas Kekoni... 7 3.2.4 Mitro Kuha... 7 3.2.5 Tuomas Luttinen... 7 3.2.6 Vesa Salento... 8 3.2.7 Kalle Valo... 8 3.2.8 Yhteenveto... 8 3.3 Projektin keskeytyskriteeri... 8 3.4 Projektin päätöskriteeri... 8 4 Resurssit ja talousarvio... 9 4.1 Henkilöresurssit... 9 4.2 Materiaalit... 10 4.3 Talousarvio... 10 5 Työkäytännöt ja työkalut... 11 5.1 Työkäytännöt... 11 5.1.1 Testauskäytäntö... 11 5.1.2 Ohjelmointikäytäntö... 11 5.1.3 Dokumentointikäytäntö... 12 5.1.4 Kokouskäytäntö... 12 5.1.5 Yhteenveto henkilökohtaisista harjoituksista... 13 5.2 Käytetyt työkalut... 13 5.2.1 Java... 13 5.2.2 GNU Make... 13 5.2.3 CVS... 14 5.2.4 JLex... 14
5.2.5 Cup... 14 5.2.6 GNU Linear Programming Kit (GLPK)... 14 5.2.7 Bugzilla... 14 5.2.8 Trapoli... 15 5.2.9 OpenOffice.org... 15 5.2.10 Javadoc... 15 5.2.11 Dia... 15 5.2.12 CCCC... 15 5.2.13 JUnit... 15 5.2.14 HttpUnit... 16 5.2.15 Checkstyle... 16 5.2.16 PMD... 16 5.2.17 FindBugs... 16 5.3 Noudatetut standardit... 16 6 Aikataulutus... 17 6.1 Yleiskuva... 17 6.2 Projektin suunnittelu... 17 6.3 Toteutus 1... 18 6.4 Toteutus 2... 18 6.5 Toteutus 3... 19 6.6 Toimitus... 20 7 Riskienhallintasuunnitelma... 22 7.1 Riskien kartoitus... 22 7.2 Projektinaikainen riskienhallinta... 22 7.3 Riskien luokittelu ja analysointi... 22 7.3.1 Valmiit komponentit... 22 7.3.2 Osaaminen... 22 7.3.3 Mentor... 22 7.3.4 Ryhmä... 23 7.3.5 Laitteistot... 23 7.3.6 Asiakas... 23 Viitteet... 24
1 Esittely 1.1 Projektin tarkoitus ja tavoite Projektin tavoitteena on kehittää Teknillisen korkeakoulun Ohjelmistoliiketoiminnan ja -tuotannon instituutin WeCoTin (Web Configuration Technology) -tutkimusryhmälle lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija, jota tutkimusryhmä voi hyödyntää osana omaa järjestelmäänsä. WeCoTin-projektissa tutkitaan verkkokaupan ja verkostotalouden vaikutuksia tuotekonfiguroinnin prosesseihin ja konfiguraattoreihin. Ideoita demonstroidaan edistyneellä konfiguraattoriprototyypillä. [1] Projektin kuluessa on tarkoitus myös tutustua nykyisiin työkaluihin lineaaristen rajoitteiden tyydyttämistehtävien ratkaisemiseksi sekä näiden käyttökelpoisuuteen verkkosovelluksissa. 1.2 Järjestelmä ja ympäristö Järjestelmä toteutetaan Java-ohjelmointikielellä, jotta asiakas pystyy käyttämään kehitettyä järjestelmää missä tahansa laiteympäristössä, johon on saatavilla Javavirtuaalikone. Järjestelmän arkkitehtuuri perustuu yksinkertaiseen asiakas-palvelinrakenteeseen, ja testikäyttöä varten järjestelmään tehdään selaimella toimiva käyttöliittymä. 1.3 Oikeudet projektin lopputuloksiin Projektin päättyessä projektin lopputulokset luovutetaan asiakkaalle hyödynnettäviksi tieteellisessä tutkimuksessa. Tutkimustarkoitukseen asiakas saa järjestelmään käyttö- ja jatkokehitysoikeudet. Tämän lisäksi asiakkaan kanssa on sovittu, että ryhmä saa tietyn korvauksen järjestelmän mahdollisesta kaupallisesta hyödyntämisestä. Tästä tehdään erillinen sopimus Teknillisen korkeakoulun ja projektiryhmän jäsenten välille. 1
2 Projektin sidosryhmät Projektin sidosryhmät voidaan jakaa kolmeen ryhmään. Oleellisimman ryhmän muodostaa projektia suorittava ryhmä eli työryhmä. Kaksi muuta sidosryhmää ovat asiakkaan edustajat sekä kurssin edustajat. 2.1 Työryhmä Työryhmän muodostavat Jouni Karppinen, Hannu Kauppinen, Joonas Kekoni, Mitro Kuha, Tuomas Luttinen, Vesa Salento ja Kalle Valo. Vastuunjako projektin sisällä on jaettu kahteen osaan, prosessivastuisiin ja osa-aluevastuisiin. Osa-alueet viittaavat tässä valmistuvan järjestelmän toiminnallisiin osa-alueisiin. Vastuunjako on esitetty kaavioissa 1 ja 2. Prosessivastuut Projektipäällikkö Vaatimusten hallinta Dokumentointi Pääarkkitehti Testaus Kaavio 1: Ryhmän sisäiset prosessivastuut. Hannu Kauppinen Vesa Salento Jouni Karppinen Tuomas Luttinen Kalle Valo Osa-aluevastuut Mallien käsittely Kontrolleri Asiakas-palvelin -rakenne Käyttöliittymä Joonas Kekoni Tuomas Luttinen Vesa Salento Mitro Kuha Kaavio 2: Ryhmän sisäiset osa-aluevastuut. Jakamalla vastuut kahteen eri kategoriaan on tarkoitus varmistaa asioiden hallinta kokonaisuuksina useista eri näkökulmista. Toisaalta vastuut on jaettu osa-alueisiin tehtävien mukaan (kuten vaatimusten hallinta tai testaus), toisaalta taas lopputuotteen kokonaisuuksien mukaan (kuten kontrolleri tai käyttöliittymä). Osa-aluevastuita saatetaan täsmentää projektin edetessä. Vastuunjaon ansiosta jokaisesta yksittäisestä tehtävästä on vastuussa kaksi henkilöä, toinen tehtävän luonteen mukaisesti ja toinen lopputuotteen kokonaisuuden mukaisesti. Tällä varmistetaan se, että kaikkia työmenetelmiä noudatetaan samalla tavalla kaikissa komponenteissa ja että lopputuotteen kokonaisuudet ovat todella kokonaisuuksia. Oleellista on kuitenkin huomata, että vastuullisuus tietystä tehtävästä ei tarkoita samaa kuin velvollisuus toteuttaa kyseessä oleva tehtävä. Tehtävät jaetaan resurssitilanteen mukaisesti eri henkilöille. Vastuullisilla on tällöin velvollisuus huolehtia, että toteuttajan ratkaisut ovat linjassa toisaalta komponentille asetettujen tarpeiden ja vaatimusten kanssa ja toisaalta koko projektin menetelmien kanssa. 2
Lisäetuna malli luo automaattisen varavastuullisen kullekin tehtävälle, sillä mikäli projektia joudutaan toteuttamaan pitkän aikaa ilman dokumentointivastuuta, siirtyy vastuu dokumentoinnista kustakin komponentista vastaavalle henkilölle. Täydellistä suojaa henkilöriskeiltä tämä ei tarjoa, sillä yksittäisillä henkilöillä on sekä prosessi- että osaaluevastuita. Näin ollen syntyy tilanteita, joissa sama henkilö on vastuussa sekä prosessin että lopputuloksen kannalta. Projektipäällikkö vastaa vain projektin hallinnasta, sillä hänen vastuulleen kuuluvat erilaiset hallinnolliset tehtävät, joilla ei ole suoranaista yhteyttä mihinkään tehtäväalueeseen tai lopputuotteen kokonaisuuteen. Lisäksi projektipäällikkö ratkoo tarvittaessa mahdolliset erimielisyydet projektiryhmän jäsenten välillä. Kun tehtävillä on useita vastuullisia, ovat ristiriidat mahdollisia. Seuraavassa on lyhyt esittelyt kaikista projektiryhmän jäsenistä. 2.1.1 Jouni Karppinen jjkarppi@cc.hut.fi 050 347 1703 Jouni on 6. vuosikurssin sähkö- ja tietoliikennetekniikan opiskelija. Hänen pääaineensa on ohjelmistojärjestelmät ja sivuaineina käyttöliittymät ja käytettävyys sekä vuorovaikutteinen digitaalinen media. Teknillisen korkeakoulun lisäksi Jouni opiskelee myös Helsingin Kauppakorkeakoulussa. Jouni on kiinnostunut dokumentointiprosesseista sekä käyttöliittymien kehittämisestä, erityisesti käytettävyydestä ja multimediasta. 2.1.2 Hannu Kauppinen hannu.kauppinen@iki.fi 040 506 3444 Hannu on 6. vuoden tuotantotalouden opiskelija, jonka pääaine on yrityksen strategia ja kansainvälisen liiketoiminnan kehittäminen. Sivuaineenaan Hannu lukee digitaalisten tuotteiden kehittämistä. Hannu työskentelee Syslore Oy:n myyntijohtajana, mikä on tarjonnut hänelle mahdollisuuden tutustua kaupallisiin ohjelmistoprojekteihin. Hannu toimii projektissa projektipäällikkönä, mikä tarkoittaa, että hänen vastuullaan on ensisijaisesti raportointi sidosryhmille sekä projektin yleinen hallinnointi. 2.1.3 Joonas Kekoni jkekoni@cc.hut.fi 040 826 7552 Joonas opiskelee sähkötekniikan osastolla tietoliikenneohjelmistoja pääaineekseen ja sivuaineena digitaalista signaalinkäsittelyä. Hän on työskennellyt 4 vuotta täysipainoisesti ja nyt palannut koulun penkille saadakseen tutkintotodistuksen opinnoistaan. Joonaksen laajaa kokemusta erilaisista ohjelmistoprojekteista tullaan hyödyntämään laajalti toteutusvaiheiden vaikeimmissa tehtävissä kuten mallien ratkaisun optimoinnissa. 3
2.1.4 Mitro Kuha mkuha@cc.hut.fi 050 357 6132 Mitro on opintojensa loppuvaiheessa oleva tietotekniikan opiskelija, joka lukee pääaineenaan vuorovaikutteista digitaalista mediaa ja sivuaineena sisällöntuotantoa. Mitrolla on työkokemusta ohjelmistoliiketoiminnasta kahden vuoden ajalta, mutta hän on tällä hetkellä täysipäiväinen opiskelija. Mitron ensisijainen vastuu on hänen kiinnostuksensa mukaisesti käytettävyys ja käyttöliittymä, mutta koska näiden rooli on projektissa pieni, tulee Mitro osallistumaan myös muihin tehtäviin. 2.1.5 Tuomas Luttinen tuomas.luttinen@hut.fi 050 587 4110 Tuomas on tietoteekkari, jonka pääaineena on ohjelmistojärjestelmät. Sivuaineekseen Tuomas lukee vuorovaikutteista digitaalista mediaa. Tuomas on työskennellyt ohjelmistoalalla viimeiset kuusi vuotta, mikä on antanut hänelle merkittävästi näkemystä ohjelmistoprojektien toteutuksesta. Tuomaksen pääasiallinen vastuu on järjestelmän arkkitehtuurin hallinta. Lisäksi Tuomaksen kokemusta jäsennyspuista ja kieliä tulkitsevista järjestelmistä tullaan hyödyntämään projektin toteutusvaiheessa. 2.1.6 Vesa Salento vsalento@cc.hut.fi 040 740 0468 Vesa on tietotekniikan opiskelija, jonka pääaineena on tietoliikenneohjelmistot. Hän on työskennellyt päätoimisesti viimeiset neljä vuotta ja siinä sivussa suorittanut tutkintoa eteenpäin. Tällä hetkellä valmistuminen näyttäisi sijoittuvat vuoden 2004 loppuun. Vesan kiinnostus on pääasiassa huolehtia koko järjestelmän toimivuudesta ja huolehtia, että asiat tehdään kunnolla. Vastuuna hänellä on vaatimusmäärittely, mutta hän on myös kiinnostunut testikäyttöliittymän tekemisestä sekä sen testaamisen automatisoinnista. 2.1.7 Kalle Valo kalle.valo@iki.fi 050 464 2740 Kalle on 6. vuosikurssin tietoliikennetekniikan opiskelija, jonka pääaineena on ohjelmistojärjestelmät ja sivuaineena tietoliikenneohjelmistot. Kalle on opiskeluaikoina työskennellyt useissa tietotekniikan tuotekehitykseen ja ylläpitoon liittyvissä tehtävissä eri yrityksissä. Kallen pääasiallinen vastuu projektin puitteissa liittyy järjestelmän testauksen järjestämiseen sekä projektiryhmän yhteisen koodikannan ympäristöstä huolehtimiseen. Tarpeen mukaan Kalle osallistuu myös muihin tehtäviin. 4
2.2 Asiakas Projektin asiakkaana toimii Teknillisen Korkeakoulun Ohjelmistoliiketoiminnan ja -tuotannon instituutin WeCoTin-tutkimusryhmä. Tutkimusryhmän projektipäällikkö Juha Tiihonen toimii projektin asiakkaana siten, kuin se kurssin puitteissa on määritelty, ja teknisenä neuvonantajana toimii Juha Nurmilaakso. Asiakas Juha Tiihonen juha.tiihonen@hut.fi (09) 451 3242 Tekninen neuvonantaja Juha Nurmilaakso juhnu@cc.hut.fi (09) 451 5066 2.3 Kurssin edustajat Projekti toteutetaan osana Teknillisen Korkeakoulun kurssia T-76.115 Tietojenkäsittelyopin ohjelmatyö. Tämä tarkoittaa, että asiakkaan ja työryhmän lisäksi projektia toteutettaessa on huomioitava myös kurssin vaatimukset. Kurssin puolesta työhön osallistuu ohjaajana eli mentorina Pietu Pohjalainen. Mentor Pietu Pohjalainen pietu.pohjalainen@hut.fi 5
3 Projektin tavoitteet ja päätöskriteerit 3.1 Asiakkaan tavoitteet Asiakkaan kannalta projektissa on kyse tutkimusprojektia edistävästä hankkeesta, jonka ensisijainen tavoite on saada tutkimusprojektin käyttöön lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija. Koska tämän projektin resurssit ovat rajalliset, on tärkeää, että järjestelmä toteutetaan siten, että sen jatkokehitys on mahdollisimman helppoa. Tieteellisesti oleellinen sisältö liittyy disjunktiivisen ja konjunktiivisen normaalimuodon käyttökelpoisuuden vertaamiseen konfiguraatiotehtävien ratkaisun yhteydessä. Projektin aikana ilmi tulleita asioita julkaistaan mahdollisesti myös tieteellisissä julkaisuissa tutkimusryhmän jäsenten puolesta. Asiakkaan tavoitteet on esitetty taulukossa 1. Ne on numeroitu tärkeysjärjestykseen siten, että ensimmäinen on tärkein. Tavoite 1. Saada tutkimusryhmän käyttöön määritelty ratkaisija. 2. Mallien kuvaamiseen käytetty kieli kattaa kaikki suunnitellut käyttötarkoitukset. 3. Pystyä käyttämään järjestelmää pohjana jatkokehitykselle. Varmistuskriteeri Asiakkaan edustaja pystyy ratkaisemaan kielellä esitetyn mallin omalla koneellaan. Kielen määrittely tehdään läheisessä yhteistyössä asiakkaan kanssa, ja asiakas hyväksyy kielen määrittelyn. Asiakas hyväksyy projektin dokumentaation ja lisenssin. 4. Julkaista aiheesta tieteellisiä artikkeleita. Asiakas on tyytyväinen saamaansa palautteeseen kehityksen aikana ilmitulleista asioista. 5. Disjunktiivisen ja konjunktiivisen normaalimuodon käytettävyyden vertailu. 6. Jatkokehitystä voi tehdä myös eisuomalainen tutkija. 7. Järjestelmän pohjana olevaa ratkaisijakomponenttia voi vaihtaa. 8. Järjestelmässä tulee käyttää vain vapaita ohjelmistoja. Dokumentaatio sisältää raportointia muotojen välillä olevista eroista ratkaisun kannalta. Ohjelmakoodi kommentteineen on kirjoitettu englanniksi. Rajapinnat ratkaisijan ja muiden komponenttien välillä ovat selkeitä ja hyvin dokumentoituja. Ulkopuoliset lisenssit eivät rajoita ohjelman levitystä. 9. Projekti valmistuu aikataulussa. Projektin tavoitteet saadaan toteutettua projektin päättymiseen mennessä. 10. Projektin lopputulos on laadullisesti korkeatasoinen. Taulukko 1: Asiakkaan tavoitteet tärkeysjärjestyksessä. Määritellään käytettävät menetelmät selkeästi ja pyritään jatkuvasti kehittämään omaa toimintaa. 6
3.2 Työryhmän tavoitteet Analysoidessamme työryhmän tavoitteita projektin osalta lähdimme liikkeelle kunkin ryhmän jäsenen henkilökohtaisista tavoitteista pyrkien siten muodostamaan yhteisen näkemyksen tavoitteista ryhmän tasolla. Seuraavassa on esitetty kunkin ryhmän jäsenen henkilökohtaiset tavoitteet ja sen jälkeen työryhmän tavoite. 3.2.1 Jouni Karppinen Päästä kurssista läpi arvosanalla 4 Oppia tuottamaan laadukasta dokumentaatiota Oppia työskentelemään suuressa ryhmässä Nähdä ja kokea, millaista on olla mukana oikeassa ohjelmistoprojektissa Oppia käyttämään uusia työkaluja Nähdä, miten erilaisia menetelmiä ja koulun teoreettisia oppeja voidaan soveltaa käytännössä 3.2.2 Hannu Kauppinen Saada pakollinen kurssi suoritettua kunnialla valmistumista ajatellen Oppia ohjelmistoprojektin hallintaa ja johtamista Tutustua uusiin ihmisiin Oppia lisää ohjelmistokehityksestä ja siihen liittyvistä työkaluista ja menetelmistä Luoda lopputulos, johon voi olla itse tyytyväinen 3.2.3 Joonas Kekoni Saada hyväksytty arvosana valmistumista varten Oppia mielenkiintoisia asioita kielen kääntämisestä ja rajoitteista Kirjoittaa haastavaa ohjelmakoodia, joka tekee muutakin kuin relaatiotietokannan sisällön käsittelyä 3.2.4 Mitro Kuha Suorittaa kurssi hyvällä arvosanalla Kartuttaa kokemuksia tiimityöskentelystä ohjelmistoprojektissa Kasvattaa osaamista ohjelmistoprojektin menestyksekkäästä läpiviennistä projektin kaikilla osa-alueilla 3.2.5 Tuomas Luttinen Kurssin läpäisy Ohjelmistotuotantoprosessin oppiminen aikaisempaa tarkemmin Ohjelmointikielen kääntäjät -kurssin oppien syventäminen 7
Uusiin ihmisiin tutustuminen 3.2.6 Vesa Salento Saada pakollinen kurssi suoritettua kunnialla valmistumista ajatellen Kasvattaa osaamista ohjelmistoprojektin menestyksekkäästä läpiviennistä projektin kaikilla osa-alueilla Tutustua uusiin ihmisiin Luoda lopputulos, johon voi olla itse tyytyväinen 3.2.7 Kalle Valo Kurssin kunniallinen läpäisy Lopputuote, jota kehtaa esitellä omanaan 3.2.8 Yhteenveto Projektiryhmän jäsenten henkilökohtaisissa tavoitteissa korostuivat kurssin läpäisy kunnialla (arvosanatavoitteena 4), kurssin aihepiirin syvällinen oppiminen sekä lopputuloksen korkea laatu. Lisäksi esille nousivat alan toimijoihin tutustuminen sekä yksittäisten menetelmien tai käytäntöjen opiskelu. Tästä yhteenvetona voidaan todeta, että ryhmän tavoitteena on hyödyntää projekti oppimiskokemuksena ja siten kartuttaa kunkin ryhmän jäsenen henkilökohtaisia valmiuksia osallistua vastaavantyyppisiin projekteihin jatkossa. Tämä tavoite pyritään saavuttamaan työskentelemällä sitoutuneesti projektin eteen ja ylläpitämällä projektin läpi sisäisesti kriittistä suhtautumista omaan työhön. Työtä tehdessä huomioidaan myös kurssin asettamat vaatimukset, jotta tärkein henkilökohtaisista tavoitteista eli kurssin läpäisy tulee kaikkien kohdalta toteutumaan. 3.3 Projektin keskeytyskriteeri Koska projektin loppuunsaattaminen on edellytyksenä useiden työryhmän jäsenten valmistumiselle, ei projektia helposti keskeytetä. Ainoa syy projektin keskeyttämiselle on, että työryhmä katsoo mahdottomaksi sen loppuun saattamisen kurssin vaatimusten mukaisesti. Luonnollisesti, jos kaikki henkilöt jättävät projektin kesken, projekti keskeytyy. 3.4 Projektin päätöskriteeri Projekti toteutetaan vaiheittain kurssin aikataulun mukaisesti. Projekti päättyy viimeisen vaiheen päätyttyä huhtikuussa 2004. 8
4 Resurssit ja talousarvio 4.1 Henkilöresurssit Projektin käytössä on 190 työtuntia projektin työryhmän jäsentä kohti. Näin ollen kokonaisuutena projektiin on käytettävissä 630 henkilötyötuntia. Taulukko 2 kuvaa alustavan työpanosjaon jokaiselle iteraatiokierrokselle. Hannu Kauppinen Jouni Karppinen Joonas Kekoni Mitro Kuha Tuomas Luttinen Vesa Salento Kalle Valo Yhteensä PP 40 45 85 35 45 30 30 310 I1 30 35 40 10 70 40 35 260 I2 45 30 30 55 35 55 55 305 I3 45 40 20 55 25 40 40 265 DE 30 40 15 35 15 25 30 190 Yht. 190 190 190 190 190 190 190 1330 Taulukko 2: Henkilöresurssien jakautuminen projektin eri vaiheissa. Tämän lisäksi projektin toteutuminen vaatii henkilöresursseja asiakkaalta. Ennalta arvioituna asiakkaan on sidottava projektin läpivientiin noin 1 tunti joka viikko sekä lisäksi teknisen neuvonantajan aikaa noin 2 tuntia viikossa. Koko projektin kestolta tämä tarkoittaa yhteensä noin 75 henkilötyötuntia. Henkilöresurssien suunnittelussa on pyritty huomioimaan riittävä joululoma koko ryhmälle. Tämän vuoksi vaiheen I2 tuntimäärät ovat pieniä suhteessa vaiheen kestoon. Lisäksi on huomioitu Mitro Kuhan loma marraskuussa. Muuten painotus on pyritty tekemään projektin alkupäähän, sillä tällä tavoin projektin loppuosaan saadaan enemmän joustavuutta mahdollisten muutosten tai yllätysten varalta. Jos henkilöresursseille halutaan laskea rahallinen arvo, on laskennassa huomioitava projektille kustannuksena myös asiakkaan tekemän työn arvo. Erityisesti tekninen ohjaaja joutuu käyttämään suuren määrän työtunteja projektin menestyksekkään läpiviennin varmistamiseen. Karkea arvio kustannuksista on esitetty taulukossa 3. Henkeä Iteraatioita Työmäärä iteraatiossa Työtunnin hinta Yhteensä Projektiryhmä 7 5 40 75 105 000 Tekninen ohjaaja 1 5 10 120 6 000 Asiakas 1 5 5 160 4 000 Yhteensä 9 5 55 115 000 Taulukko 3: Henkilötyökustannukset projektissa. 9
4.2 Materiaalit Projektin materiaalitarve rajoittuu käytännössä ohjelmointi- ja testausympäristöihin. Tähän soveltuvat kuitenkin esimerkiksi Teknillisen korkeakoulun ATK-keskuksen tarjoamat palvelut, jotka ovat projektin osallisilla automaattisesti käytettävissä. Lisäksi kaikilla ryhmän jäsenillä on oikeus käyttää muita ympäristöjä harkintansa mukaan, mikäli heillä on siihen mahdollisuus. Ajatus on se, että jokainen ryhmän jäsen voi työskennellä siinä ympäristössä, joka on hänelle helpoin. Ryhmän sisäistä tiedonkulkua varten on perustettu kolme sähköpostilistaa, jotka arkistoidaan verkkoon. Koko projektiryhmän kattavan listan lisäksi erilliset sähköpostilistat luotiin kielen ominaisuuksia ja järjestelmän arkkitehtuuria koskevia keskusteluja varten. Kielen ominaisuuksia käsittelevällä listalla on mukana myös asiakkaan edustaja. Muuten listat ovat vain ryhmän sisäiseen käyttöön. Yhteinen lähdekoodi tallennetaan versionhallintaa ja varmuuskopiointia varten samaan paikkaan Teknillisen korkeakoulun ATK-keskuksen verkossa. 4.3 Talousarvio Projektissa ei ole tiedossa mitään erityisiä hankintoja, joita varten tarvitsisi varata taloudellisia resursseja. Juoksevat kulut (toimistotarvikkeet, sähkö, laitteiston kulut) ovat merkityksettömiä, eikä niitä tarvitse siksi huomioida. Mikäli merkittäviä investointitarpeita ilmenee, keskustellaan niistä asiakkaan kanssa erikseen. 10
5 Työkäytännöt ja työkalut 5.1 Työkäytännöt 5.1.1 Testauskäytäntö Projektissa testaus painottuu suurelta osin koko järjestelmän testaamiseen johtuen toteutettavan järjestelmän luonteesta. Järjestelmän toiminta perustuu mallien lukemiseen ja kyseiselle mallille ominaisten rajoitteiden palauttamiseen, joten järjestelmän komponenttien toimiminen yhdessä on tärkeää. Järjestelmätason testaus automatisoidaan mahdollisimman suurilta osin, jotta kuka tahansa projektiryhmän jäsenistä pystyy ajamaan tärkeimmät testit aina tarvittaessa, esim. ennen muutosten lisäämistä CVS:ään. Uusien testien luominen pitää olla tarpeeksi helppoa ja hyvin dokumentoitua, jotta systeemitestausta saadaan aina tarvittaessa laajennettua. Luonnollisestikin projektissa käytetään myös yksikkötestausta, mutta projektin luonteen vuoksi painopiste on järjestelmätason testauksessa. Perustestit kaikkien luokkien toimivuudesta tehdään yksikkötestauksella. Testauksen päävastuu prosessitasolla on Kalle Valolla ja hän huolehtii käytännön järjestelyistä testaukseen liittyen. Testauksesta tehdään tarkempi suunnitelma ensimmäisen toteutusvaiheen yhteydessä. Tässä suunnitelmassa määritellään projektin testauskäytännöt ja erityisesti siihen sovelletut menetelmät tarkemmin. 5.1.2 Ohjelmointikäytäntö Projektin toteutuskielenä käytetään Javaa ja ohjelmointityylin pohjana on Sunin ohjelmointityylistandardi. Standardia täydennetään vielä ryhmän sisäisesti, jotta ei tulisi tulkintaerimielisyyksiä asioista, joihin mainittu standardi ei ota kantaa. Toteutuksen ulkoasussa pyritään selkeään ja luettavaan koodiin käyttämällä hyvin nimettyjä muuttujia ja metodeja sekä kommentoimalla koodia riittävässä määrin. Kaikkien luokkien rajapinnat kommentoidaan Javadoc-tyyliin, jotta lähdekoodista saadaan haluttaessa tulostettua rajapintakuvaukset. Muuta kommentointia käytetään tapauksissa, joissa voidaan olettaa, että koodin toiminta ei koodia syvällisesti tuntemattomalle lukijalle aukea aivan helpolla pelkkää koodia lukien. Pariohjelmointia käytetään tämän projektin kohdalla ainakin kriittisten osioiden toteuttamiseen. Pariohjelmointia suositellaan myös muihin osioihin, mutta ainakin osa niistä tullaan toteuttamaan perinteisellä yksinohjelmoinnilla, jotta saadaan vertailutietoa työtapojen tulosten analysoimiseksi. Pariohjelmoinnilla pyritään parempaan koodin laatuun, selkeämpään toteutukseen ja ryhmän sisäisen tietotason nostamiseen. Jotta näihin tavoitteisiin päästäisiin, pitää pareja myös vaihdella. Niihin osioihin, joihin käytetään yksinohjelmointia, voidaan mahdollisesti käyttää muita työn jäljen parantamiseen tähtääviä työskentelytapoja, mutta tästä päätetään tarkemmin ensimmäisen toteutusvaiheen yhteydessä, kun testaussuunnitelma ja muut vastaavat dokumentit ovat valmistuneet. Lisäksi asiakkaan kanssa on erikseen sovittu, että ohjelmakoodia kirjoitettaessa käytetään työkielenä englantia, eli luokkien nimet ja kaikki ohjelmakoodin sekaan kirjoitetut 11
kommentit ovat englanniksi. Tämän tarkoitus on mahdollistaa ohjelman jatkokehitys myös suomea osaamattomalle henkilölle. 5.1.3 Dokumentointikäytäntö Projektin lopputulosten kannalta on erittäin tärkeää, että asiakas saa ohjelmakoodin ja käyttöohjeiden lisäksi myös erilaista materiaalia mahdollisen jatkokehityksen tueksi. Tämä asettaa projektissa dokumentoinnille tiettyjä vaatimuksia. Dokumentointikäytännöstä vastaa Jouni Karppinen, joka laatii tarkemmat ohjeet dokumenttien käsittelystä. Pääsääntönä voidaan todeta, että kaikki dokumentit käyvät läpi katselmuksen, ennen kuin ne ovat valmiita. Katselmuksessa kaksi projektiryhmän jäsentä arvioi dokumentin sisällön ja kieliasun. Tarkoitus on kirjoitusvirheiden korjaamisen lisäksi myös varmistua dokumenttien yhtenevyydestä sekä visuaaliselta ilmeeltään että käytetyn terminologian osalta. Huomionarvoista on myös, että dokumenttien pitää olla ymmärrettävissä, sillä dokumenttien käyttäjäryhmä on varsin laaja ulottuen mentorista, jolla ei ole mitään sidettä projektin matemaattiseen taustaan, WeCoTin-projektin tutkijoihin, joiden mielenkiinto kohdistuu ensisijaisesti työryhmän kokemuksiin käytettyjen työkalujen todellisista kyvyistä. 5.1.4 Kokouskäytäntö Projektin aikana pidettävät tapaamiset voidaan jakaa eri ryhmiin. Tapaamiset, joihin mentor osallistuu, on kurssin puolelta jaettu projektikatselmuksiin (yksi iteraatiota kohden, mukana myös asiakasorganisaation edustajat) ja mentortapaamisiin (yksi iteraatiota kohden, vain mentor ja ryhmä). Näihin tapaamisiin on olemassa valmiiksi tietty runko ja niiden kesto ja ajankohta on ennalta määrätty. Muut tapaamiset voidaan jakaa kahteen ryhmään sen mukaan, ovatko ne projektiryhmän sisäisiä tapahtumia vai osallistuuko niihin myös asiakkaan edustajia. Näiden tapaamisten osalta ryhmän käyttämät kokouskäytännöt vaihtelevat projektin vaiheiden mukaisesti, sillä tarpeet näihin tapaamisiin vaihtelevat merkittävästi. Projektin suunnitteluvaiheessa ryhmä on pitänyt viikoittain ryhmäpalaverin, jossa on käyty läpi tehtyjä töitä ja suunniteltu tulevia. Näissä kokouksissa käsiteltyjä asioita on löyhästi valmistellut projektipäällikkö, joka on myös pitänyt kirjaa tehdyistä päätöksistä. Päätökset on kirjattu vapaamuotoisesti ja toimitettu ryhmälle sähköpostilla. Ryhmän sisäisten ryhmäpalaverien lisäksi tapaamisia pidetään myös asiakkaan edustajien kanssa. Projektin suunnitteluvaiheessa nämä ovat olleet pääasiassa työpalavereja liittyen joko järjestelmän arkkitehtuuriin tai mallien kuvaamisessa käytettävään kieleen, mutta projektin jatkuessa näiden tapaamisten painopiste tulee siirtymään projektin edistymisen seurantaan ja mahdollisten haasteiden ratkomiseen. Nyt kokousten valmistelu on ollut arkkitehtuurista tai kielestä vastaavien vastuulla, mutta painopisteen siirtyessä projektin seurantaan vaihtuu valmisteluvastuu projektipäällikölle. Projektin seurantakokouksia pidetään ensimmäisen toteutusvaiheen alusta alkaen arviolta neljän viikon välein, ellei mitään erityistä ilmene. Kokousten asialistan valmistelee projektipäällikkö keräämällä tietoa ajankohtaisista asioista projektiryhmältä. Kokousten jälkeen projektipäällikkö toimittaa muistiinpanot kokouksen kulusta asiakkaan edustajille, projektiryhmälle sekä mentorille projektin etenemisen seuraamista varten. 12
Seurantakokousten välillä projektipäällikkö tiedottaa sekä asiakasta että mentoria projektin tilasta sähköpostilla. 5.1.5 Yhteenveto henkilökohtaisista harjoituksista Projektin aikana kukin työryhmän jäsen tutustuu tarkemmin johonkin ohjelmistoprojektin menetelmään ja suunnittelee tämän menetelmän hyödyntämistä projektissa. Menetelmät ja niistä vastaavat henkilöt on esitetty taulukossa 4. Menetelmä Vastuullinen Esittely Raportointi Dokumentaation hallinta Jouni Karppinen I1 DE Kokouskäytännöt Hannu Kauppinen I1 I3 Suunnittelumallit (engl. Design patterns) Joonas Kekoni I1 I3 Heuristinen arviointi Mitro Kuha I2 DE Pariohjelmointi Tuomas Luttinen I2 I3 Systeemitason testien automatisointi Kalle Valo I2 DE Automatisoitu yksikkötestaus Vesa Salento I2 DE Taulukko 4: Henkilökohtaiset ohjelmistoprojektimenetelmät. Menetelmien tarkemmasta käytöstä päätetään ensimmäisen toteutusvaiheen aikana ja kunkin menetelmän hyödyntämisestä tehdään erillinen suunnitelma. 5.2 Käytetyt työkalut Projektin osalliset käyttävät pääasiassa itse valitsemiaan työkaluja ja ympäristöjä varsinaiseen ohjelmointityöhön. Projektin puitteissa kuitenkin on päätetty tiettyjen työkalujen käytöstä yhteisten toimintojen suorittamiseen. Nämä työkalut ovat Javaohjelmointikieli, GNU Make kääntämiseen ja testaamiseen, CVS versionhallintaan, Cup ja JLex mallien jäsentämiseen, GLPK mallien ratkaisuun, Bugzilla virheraporttien hallintaan, Trapoli työtuntien seurantaan, OpenOffice.org, Javadoc ja Dia dokumentointiin sekä CCCC, JUnit, HttpUnit, Checkstyle, PMD ja FindBugs ohjelmatiedostojen analyysiin. 5.2.1 Java Projektissa käytetään ohjelmointikielenä Sun Microsystems Inc.:n kehittämää Javaa. Kääntämiseen ja ohjelman ajamiseen projektin aikana käytetään ATK-keskuksen palvelimille asennettua versiota Java-kääntäjästä ja Java virtuaalikoneesta. Nämä ovat projektin alkaessa Java 2, versio 1.4.1:n mukaisia. Mikäli ympäristössä tapahtuu merkittäviä muutoksia projektin aikana, keskustellaan asiakkaan kanssa version valinnasta. 5.2.2 GNU Make Projektin puitteissa käytetään GNU Make -järjestelmää tiettyjen toimintojen automatisointiin. Tällaisia ovat esimerkiksi komponenttien kääntäminen, yksikkötestaus ja lopullisen tuotteen paketointi. 13
5.2.3 CVS Versionhallinta on oleellinen osa projektia, kun ohjelmoijia on useampia kuin yksi. Ilman versionhallintaa on kunkin komponentin kehityksestä sovittava tarkalleen kaikkien kehittäjien kesken, jottei yhtäaikainen kehitystyö tuhoa jonkun tekemiä muutoksia. Lisäksi CVS:n avulla kaikki tuotettu ohjelmakoodi saadaan helposti varmuuskopioinnin piiriin ja erilaisia virheitä voidaan jäljittää ohjelmakoodin muutosten mukaan. 5.2.4 JLex Jotta tuotteemme osaisi tulkita loogisia malleja, käytetään näiden mallien määrittelemiseen kieltä, joka täyttää asiakkaan antamat vaatimukset siitä, millaisia ongelmia kielellä on mahdollista määritellä. Ensimmäiseksi tällä kielellä annetun syötteen analysoinnissa on tekstistä osattava poimia erilaisia avainsanoja ja operaattoreita. Tähän tarkoitukseen on toteutettava selaaja, joka osaa poimia syötteestä sanoja ja antaa niille merkityksiä. Selaajan toteuttaminen käsin ei ole kovin vaikeaa, mutta se on työlästä ja virhealtista. Tämän työvaiheen tekemiseen on siksi suunniteltu automatisoituja selaajageneraattoreita. Projektimme käyttää JLex:iä, joka on Java-ohjelmointikieltä tukeva selaajageneraattori. 5.2.5 Cup Selaajan antamat terminaalit on järjestettävä jäsennyspuuksi, jotta mallille saadaan aikaan syvempi merkitys, jolloin voidaan esimerkiksi tarkistaa, että onko muuttujan arvo kyseiselle muuttujalle annetun tyypin mukainen. Tätä työvaihetta varten on toteutettava jäsentäjä, jonka toteuttaminen on selaajan tapaan työlästä, virhealtista ja helposti automatisoitavaa. Siksi tässäkin vaiheessa käytetään valmista automatisoitua työkalua, joksi tähän projektiin on valittu Cup. Se on yleiskäyttöinen Java-ohjelmointikieltä tukeva jäsentäjägeneraattori. 5.2.6 GNU Linear Programming Kit (GLPK) Tämän projektin puitteissa ei ole mahdollista ryhtyä toteuttamaan lineaaristen ongelmien ratkaisijaa nollasta, sillä moisen työmäärä on moninkertainen verrattuna tämän projektin laajuuteen. Tästä syystä projektin alussa tutkittiin eri vaihtoehtoja vapaan ratkaisijan löytämiseksi, joka toteuttaisi projektissa vaadittavan matemaattisen rajojen laskentaa käsittelevän osuuden. Ratkaisuna päädyttiin ottamaan käyttöön GNU Linear Programming Kit. GLPK on GNU-lisenssin alla jaettava lineaaristen ongelmien ratkaisija, joka täyttää projektin vaatimukset ratkaisijalle. 5.2.7 Bugzilla Virheraporttien hallinta on tärkeää varsinkin projektin loppupuolella, kun kehitettyä järjestelmää viimeistellään toimitusta varten. Ohjelmistotuotteisiin tyypillisesti jää kehitysvaiheessa puutteita, joita on korjattava jälkikäteen. Näistä puutteista kertovien raporttien hallintaan on oltava työkalu, jotta aikaa ei turhaan kuluisi hukkaan pohdittaessa, mitkä puutteet on jo korjattu tai mitä tietoa eri puutteista on saatu. Bugzilla on Mozilla-projektin kehittämä järjestelmä, joka tarjoaa hyvin monipuoliset työkalut raporttien hallintaan ja sitä kautta kehitystyön ohjaamiseen. Kurssin puitteissa vain osa järjestelmän mahdollisuuksista on hyödynnettävissä, mutta ottaen huomioon 14
projektin luonteen ovat nämä ominaisuudet riittävät. Projektista puuttuu varsinainen järjestelmän ylläpitovaihe, joka tuo tyypillisesti suurimmat vaateet virheraporttien hallintajärjestelmälle useiden ohjelmaversioiden ja erilaisten käyttöympäristöjen kautta. 5.2.8 Trapoli Projektin resurssien seurannan kannalta on oleellista tietää, paljonko resursseja projektiin on kulloisellakin hetkellä kulutettu ja paljonko vielä suunnitelmien mukaan projekti tulee vaatimaan. Trapoli on kurssin tarjoama työkalu työtuntien suunnitteluun ja kirjaamiseen. Järjestelmä on suunniteltu projektina samalle kurssille aiempana vuonna ja sitä käytetään nyt ensimmäistä kertaa. Se ei ole paras mahdollinen työkalu tähän tarkoitukseen, mutta koska se tarjoaa kurssin henkilökunnalle mahdollisuuden tarkastella kaikkien projektien resurssikäytön tilannetta, pidetään sitä kurssin tarkoitusperiin sopivimpana. 5.2.9 OpenOffice.org Suuri osa mitä tahansa ohjelmistoprojektia on dokumentaation laatiminen. Koska jokaisella projektiryhmän jäsenellä on oltava mahdollisuus muokata dokumentteja, valitsimme dokumentaatiota varten työkaluksi OpenOffice.org:n. OpenOffice.org on saatavilla sekä Windows- että Linux-ympäristöihin, mikä mahdollistaa jokaiselle työryhmän jäsenelle työskentelyn itse parhaaksi katsomassaan ympäristössä. Ominaisuuksiltaan OpenOffice.org on riittävä projektin tavoitteiden toteuttamiseksi, joten mitään estettä sen käytölle ei ole. Käytössä ovat versiot 1.0 ja 1.1. 5.2.10 Javadoc Javadoc on automaattinen dokumentointityökalu Java-luokille. Se perustuu ohjelmakoodin määrämuotoiseen kommentointiin. Javadoc luo ohjelmakoodin perusteella standardimuotoisen dokumentaation eri rajapinnoista ja niiden metodeista. Työkalu on hyvin käytännöllinen, sillä sen luoma dokumentaatio on samankaltainen kaikille Javaohjelmille, mikä tekee sen käyttämisestä ohjelmoijille helpompaa. 5.2.11 Dia Projektin dokumentaatiossa tarvittavat kuvat piirretään Dia-ohjelmalla. Diaan tutustuminen on vielä kesken, joten tarkempi versio Diasta määritellään tarvittaessa. 5.2.12 CCCC Projektin raportoinnissa tarvitaan tiettyjä tilastotietoja. Näiden keräämiseen käytetään CCCC-ohjelmaa. Ohjelma myös tarkistaa, että kaikki ohjelmakoodi on kirjoitettu valitun standardin mukaisesti. 5.2.13 JUnit JUnit on järjestelmä, joka mahdollistaa yksikkötestauksen automatisoinnin. Järjestelmä perustuu erillisiin testitapausluokkiin, joissa kuvataan suoritettava testi sekä sen odotettu tulos. 15
5.2.14 HttpUnit HttpUnit on JUnit-järjestelmää vastaava toteutus WWW-pohjaisten järjestelmien testaukseen. Se pystyy matkimaan erilaisten lomakkeiden täyttämistä ja painikkeiden painamista. 5.2.15 Checkstyle Checkstyle tutkii lähdekooditiedostoja ja tarkistaa, että ohjelmointi on toteutettu sovitun standardin mukaisesti. 5.2.16 PMD PMD on hyvin laaja lähdekooditiedostojen analysaattori, josta on projektin käyttöön valittu vain tietyt moduulit. Checkstylen tavoin PMD tarkkailee lähdekoodia ja pyrkii löytämään siitä mahdollisia virheitä. 5.2.17 FindBugs Edellä kuvatuista analysaattoreista poiketen FindBugs tutkii käännettyjä luokkatiedostoja. Muiden analysaattoreiden tavoin se pyrkii löytämään huonoja toteutuksia, jotka saattaisivat altistaa järjestelmän virheille. 5.3 Noudatetut standardit Java-ohjelmoinnissa noudatetaan Sun Microsystems Inc.:n määrittelemää ohjelmointityylistandardia [2]. 16
6 Aikataulutus 6.1 Yleiskuva Projekti toteutetaan osana Teknillisen korkeakoulun kurssia, mikä aiheuttaa vaatimuksia projektin aikataulutukselle. Kurssin asettaman perusmallin pohjalta projekti on jaettu viiteen vaiheeseen, jotka ovat projektin suunnittelu ja toimitus sekä kolme toteutusvaihetta näiden välissä. Taulukossa 5 on esitetty kurssin vaatima aikataulutus vaiheille sekä kunkin iteraation pituus viikkoina. Iteraatio Ajanjakso Kesto Projektin suunnittelu (PP) 23.9. - 30.10. 4 viikkoa Toteutus 1 (I1) 31.10. - 4.12. 5 viikkoa Toteutus 2 (I2) 5.12. - 12.2. 10 viikkoa Toteutus 3 (I3) 13.2. - 18.3. 5 viikkoa Toimitus (DE) 19.3. - 7.4. 3 viikkoa Taulukko 5: Kurssin aikataulu. Huomionarvoista on, että vaikka iteraatio I2 on muita selvästi pidempi, ei siinä ole tehollista työaikaa käytettävissä merkittävästi muita vaiheita enempää, sillä ajanjaksolle osuvat joulun ajan lomajaksot, jotka projektissakin on tarkoitus pyhittää vapaiksi. Seuraavassa on käyty projektin eri iteraatiot läpi ja esitelty kunkin vaiheen tavoitteet sekä ensimmäisten vaiheiden tehtävät ja toimitettavat tulokset. 6.2 Projektin suunnittelu Tavoitteet: Projektin suunnittelu Vaatimusmäärittely Kielen määrittely ja dokumentointi Arkkitehtuurisuunnitelma yleisellä tasolla Lineaarimallin suunnittelu Kielellä esitetyn mallin jäsentäminen puuksi Toimitettavat tulokset: Projektisuunnitelma Kielen määrittely Tekninen määrittely Etenemisraportti Tehtävät: Projektin käynnistys Projektisuunnitelma Kielen määrittely Vaatimusmäärittely Tekninen määrittely karkealla tasolla 17
Luennoille osallistuminen Tapaamiset (ryhmän sisäiset, mentor ja asiakas) CVS:n pystytys Seuraavan iteraation suunnittelu Projektikatselmus ja etenemisraportti 6.3 Toteutus 1 Tavoitteet: Asiakas-palvelin-mallin suunnittelu Arkkitehtuurisuunnitelman viimeistely Lineaarimallin toteutus Kielellä esitetyn mallin kääntäminen Linearisaattorin suunnittelu Linearisaattorin rajapinnan määrittely Ratkaisijan rajapinnan määrittely Käyttöliittymän rungon rakentaminen (kielen syöttö) Toimitettavat tulokset: Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen määrittely Testisuunnitelma Rajapintamääritykset tietyille rajapinnoille (ohjelmakoodina) Etenemisraportti Tehtävät: Linearisaattorin ja sen rajapintojen suunnittelu Asiakas-palvelin-rakenteen suunnittelu Teknisen määrittelyn tarkennus Tapaamiset (ryhmän sisäiset, asiakas ja mentor) Ratkaisijan rajapintojen määrittelyt Lineaarimallin toteutus Translaattorin toteutus Asiakasohjelman rungon toteutus Käännösympäristön rakentaminen Bugzillan valmistelu käyttöä varten Testisuunnitelma ja testien valmistelu Seuraavan iteraation suunnittelu Projektikatselmus ja etenemisraportti 6.4 Toteutus 2 Tavoitteet: Mallin optimointi ratkaisuajan lyhentämiseksi Linearisaattorin toteutus Ratkaisijan toteutus 18
Käyttöliittymän toiminnallisuuksien rakentaminen Asiakas-palvelin-rakenteen toteutus Toimitettavat tulokset: Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen määrittely Päivitetty testisuunnitelma Testiraportti Testitapaukset Toteutetut ohjelmakomponentit Etenemisraportti Tehtävät: Linearisaattorin toteutus Ratkaisijan toteutus Palvelimen (server) toteutus Asiakkaan (client) toteutus Käyttöliittymän näkymän luominen Käyttöliittymän toiminnallisuuden rakentaminen Mallin optimointi Testitapausten suunnittelu Järjestelmätestauksen suunnittelu Julkaisutestaus Ryhmäkokoukset Asiakastapaamiset Mentortapaaminen Dokumentaation tarkastaminen Seuraavan iteraation suunnittelu Etenemisraportti Projektikatselmus ja siihen valmistautuminen 6.5 Toteutus 3 Tavoitteet: Ilmenneiden puutteiden korjaus Mallin optimoinnin parantaminen ratkaisuajan lyhentämiseksi Dokumentaation päivitys muutosten mukaisesti Järjestelmän käytettävyyden parantaminen Toimitettavat tulokset: Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen määrittely Päivitetty testisuunnitelma Testiraportti Testitapaukset 19
Toteutetut ohjelmakomponentit Vertaistestisuunnitelma Vertaistestin raportti Käyttöohje Etenemisraportti Tehtävät: Bugiraporttien läpikäynti Optimoinnin parantaminen Heuristinen arviointi Javadoc-ohjeiden tarkastaminen Asennuspaketin rakentaminen Asennusohjeen kirjoittaminen Käyttöohjeen kirjoittaminen Julkaisutestaus Henkilökohtaiset tehtävät Projektisuunnitelman päivitys Vaatimusmäärittelyn päivitys Teknisen määrittelyn päivitys Testisuunnitelman päivitys Ryhmäkokoukset Asiakastapaamiset Mentortapaaminen Dokumentaation tarkastaminen Seuraavan iteraation suunnittelu Etenemisraportti Projektikatselmus ja siihen valmistautuminen 6.6 Toimitus Tavoitteet: Ilmenneiden puutteiden korjaus Järjestelmän viimeistely toimitusta varten Dokumentaation ja ohjeistuksen viimeistely Asiakkaan kouluttaminen järjestelmän ominaisuuksiin Lopullisen järjestelmän toimittaminen asiakkaalle Toimitettavat tulokset: Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty tekninen määrittely Päivitetty testisuunnitelma Testiraportti Testitapaukset Päivitetty käyttöohje Etenemisraportti Loppuraportti 20
Lmodels v. 1.0 (valmis ohjelmisto) Tehtävät: Käyttäjäpalautteen perusteella tehtävät muutokset Bugiraporttien läpikäynti Rasitustestaus Julkaisutestaus Hyväksyntätestaus Demon valmistelu Asennus- ja käyttökoulutus Henkilökohtaiset tehtävät Dokumentaation päivitys Ryhmäkokoukset Asiakastapaamiset Mentortapaaminen Dokumentaation tarkastaminen Etenemisraportti Loppuraportti Projektikatselmus ja siihen valmistautuminen Projektin päättäminen 21
7 Riskienhallintasuunnitelma 7.1 Riskien kartoitus Projektin riskienhallinta tapahtuu läpi projektin keston ja käsittää riskien kartoittamisen sekä niihin varautumisen. Tähän projektiin liittyvien riskien kartoitus ja analysointi suoritettiin riskienkartoitustilaisuudessa, joka järjestettiin kurssiin T-76.633 Special Course in Software Engineering: Risk Management liittyen. Ryhmäläisistä kolme osallistuu em. kurssille. Riskien kartoitus suoritettiin vapaalla ideoinnilla (brainstorming), mieleen tulleet riskit luokiteltiin aihepiireittäin kuuteen eri ryhmään, ja niiden vakavuutta ja realisoitumisen todennäköisyyttä ja seurauksia pohdittiin ryhmän kesken. 7.2 Projektinaikainen riskienhallinta Riskienhallinta jatkuu läpi koko projektin. Kurssin edetessä ja tilanteen muuttuessa tutkitaan myös mahdollisten uusien riskien syntyminen ja pyritään minimoimaan niiden vaikutukset. Myös jo tunnistettujen ja olemassa olevien riskien tilaa ja todennäköisyyttä arvioidaan uudelleen kurssin kuluessa. Todennäköistä kuitenkin on, että aktiivisiin toimiin riskien minimoimiseksi ei lähdetä. Suurin osa tunnistetuista riskeistä on sellaisia, joiden ehkäisyyn panostaminen on hyvin kallista, eikä se siten ole projektin kannalta kokonaistaloudellisesti kannattavaa. 7.3 Riskien luokittelu ja analysointi Ideoinnissa esille tulleet riskit luokiteltiin kuuteen ryhmään: valmiisiin komponentteihin, osaamiseen, mentoriin, ryhmän sisäisiin, laitteistoihin ja asiakkaaseen liittyviin riskeihin. 7.3.1 Valmiit komponentit Projektissa tehtävän ohjelmiston yhtenä osana käytetään ulkopuolista komponenttia, jonka toimivuudesta ja integroitavuudesta ei ole täyttä varmuutta. Vaatimus ulkopuolisen komponentin käyttämisestä on tullut asiakkaalta, joten projektissa tehtävän ohjelmiston toimimattomuutta kyseisen komponentin osalta ei katsota projektin epäonnistumiseksi. Tuote voidaan tehdä muilta osiltaan toimivaksi esimerkiksi käyttämällä valmiin komponentin sijasta toiminnallisuudeltaan vajaata testikomponenttia. Valmiin komponentin aiheuttama riski on siis asiakkaan riski, ja sen toteutumiseen ei varsinaisesti voida vaikuttaa. 7.3.2 Osaaminen Projektin yleinen vaikeus, työkalujen vaikeus ja vaatimusmäärittelyyn mahdollisesti tulevat liiat ominaisuudet muodostavat riskin, että projektista tulisi ryhmälle liian vaikea. Osaamiseen liittyvä riski todettiin pieneksi, sillä ryhmäläiset ovat kokeneita ja osaavia. Uusien ohjelmien opetteluun varataan aikaa, ja ryhmäläiset tukevat ja neuvovat toisiaan, mikäli apua tarvitaan. 7.3.3 Mentor Mentoriin liittyviksi riskeiksi katsottiin mentorin mahdollinen sairastuminen tai muu syy, minkä takia hän ei enää pystyisi suorittamaan mentorin tehtäviä. 22
Mentorin estymisen aiheuttama riski todettiin projektin kannalta vähäiseksi. Riskin realisoituessa kurssin taholta nimettäisiin uusi mentor. Menetykset olisivat pieniä, lähinnä uuden mentorin perehdyttämiseen kuluvaan aikaan liittyviä. Projektiryhmä ei voi vaikuttaa riskin toteutumistodennäköisyyteen. 7.3.4 Ryhmä Ryhmään liittyvät riskit ovat ryhmän mahdollinen riitaantuminen ja hajoaminen sekä jonkun ryhmäläisen sairastuminen, kurssin keskeyttäminen tai ajanpuute. Ryhmäläiset ovat hyvin motivoituneita, joten ryhmäläisen keskeyttämistodennäköisyys on pieni. Ryhmän hajoaminen riitaantumisen johdosta on epätodennäköistä, sillä ryhmäläiset ovat mukavia ja leppoisia. Sairastumisia todennäköisesti tapahtuu ja siihen on varauduttu aikatauluttamalla projekti siten, että mitään ei jätetä viime hetkeen. Yksittäisen jäsenen keskeyttämiseen on varauduttu siten, että mikään projektin osa-alueista ei ole vain yhden avainhenkilön hallussa. Riskin toteutuminen tarkoittaisi uutta työnjakoa ja organisointia sekä jäljelle jäävien henkilöiden työmäärän kasvamista, mutta se ei olisi kohtalokasta projektin menestykselliselle läpiviennille. 7.3.5 Laitteistot Laitteistoihin ja työkaluihin liittyviä riskejä ovat esimerkiksi vialliset työkalut, katkot verkkoyhteyksissä ja ATK-keskukseen liittyvät ongelmat. Projektin CVS on ATKkeskuksessa erään ryhmän jäsenen kotihakemiston lisätilassa, joten katko ATKkeskuksen toiminnassa aiheuttaisi ongelmia. Riippuvuutta ATK-keskuksesta pyritään vähentämään tekemällä säännöllisin väliajoin kopioita CVS:n tiedostoista. Mikäli ATK-keskuksen palveluissa on pitkäaikainen katko, tuotekehitys siirretään muuhun ympäristöön, esimerkiksi Niksulaan tai ryhmäläisten omille koneille. Mikäli koodia katoaa tai vaurioituu versionhallinnasta, vaurioitunut koodi pyritään palauttamaan varmuuskopioista. Mikäli verkkoyhteyksissä on pitkäaikaisia katkoja, siirrytään käyttämään vaihtoehtoisia viestintävälineitä. 7.3.6 Asiakas Asiakkaaseen liittyviä riskejä on esimerkiksi tukihenkilön sairastuminen, tutkimusprojektin keskeytyminen ja asiakkaan vetäytyminen projektista. Ryhmä ei pysty vaikuttamaan asiakkaan aiheuttamaan riskiin. Projekti ei kaadu asiakkaan poisjäämiseen, mutta se vaikuttaa lopputuotteeseen ja aiheuttaa lisää työtä uudelleenorganisoinnin ja opettelun muodossa. 23
Viitteet [1] WeCoTin-verkkosivusto, viitattu 26.10.2003, http://www.soberit.hut.fi/wecotin/suomi/index.html [2] Code Conventions for the Java Programming Language, viitattu 26.10.2003, http://java.sun.com/docs/codeconv/ 24