T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on tietokonegrafiikka-algoritmien visualisointijärjestelmän projektisuunnitelma. Päivämäärä 28.10.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi Kirjoittajat Johan Engström johan.engstrom@hut.fi Muutokset PVM Tekijä Versio Selitys 28.10.2002 Engström 1.0 Projektikatselmointiin valmis versio 28.10.2002 Engström 0.6 (s) Sisällön päivitystä 27.10.2002 Engström 0.5 (s) Sisällön päivitystä 27.10.2002 Engström 0.4 (s) Sisällön päivitystä 20.10.2002 Engström 0.3 (s) Sisällön päivitystä 15.10.2002 Engström 0.2 (s) Rungon työstäminen, kuvien lisäys 8.10.2002 Engström 0.1 (s) Rungon muodostaminen (s) = projektiryhmän sisäinen versio 1(1)
Sisällysluettelo 1. Johdanto... 4 1.1 Dokumentin tarkoitus... 4 1.2 Projektin tarkoitus... 4 1.3 Projektin kattavuus... 4 1.4 Tuote ja ympäristö... 4 1.5 Oikeudet projektin tuloksiin... 4 1.6 Yleiskatsaus dokumentteihin... 5 2. Terminologia ja määritelmät... 6 2.1 Tekniset termit ja määritelmät... 6 2.2 Projektiin liittyviä käsitteitä... 6 3. Projektin toteutusperusteet... 6 3.1 Asiakkaan nykyinen ratkaisu... 7 3.2 Hyödyt asiakkaalle... 7 3.3 Projektin kustannukset... 7 3.3.1 Työkustannukset... 7 3.3.2 Muut kustannukset... 7 3.3.1 Yhteenveto... 8 4. Projektiorganisaatio... 8 4.1 Yhteystiedot lyhyesti... 9 4.1 Projektiryhmä... 9 4.2 Sidosryhmät... 12 5. Projektin tavoitteet ja päättäminen... 12 5.1 Asiakkaan tavoitteet... 12 5.1.1 Visualisointijärjestelmän runko... 13 5.1.2 Esimerkkivisualisoinnit... 13 5.1.3 Asiakkaan TOP-10 tavoitteet... 13 5.2 Projektiryhmän tavoitteet... 13 5.2.1 Asiakastyytyväisyys... 13 5.2.2 Oppimistavoitteet... 14 5.2.3 Projektiryhmän TOP-10 tavoitteet... 14 5.3 Projektin keskeyttämiskriteerit... 15 5.4 Projektin päättämiskriteerit... 15 6. Projektin resurssit... 15 6.1 Henkilöresurssit... 15 6.2 Muut resurssit... 15 7. Käytettävät menetelmät ja työkalut... 16 7.1 Projektinhallinta... 16 7.2 Vaatimustenhallinta... 16 7.3 Riskienhallinta... 17 7.4 Suunnittelu... 17 7.5 Ohjelmointi... 17 7.6 Testaus... 17 7.6.1 Tekninen testaus... 18 7.6.2 Käytettävyystestaus... 18 7.7 Dokumentointi... 18 2(2)
7.7.1 Sisäiset dokumentit... 18 7.7.2 Tekninen dokumentointi... 19 7.8 Tiedonkulku ja työskentelytavat... 19 7.8.1 Viikkopalaverit... 19 7.8.2 Asiakastapaamiset... 19 8. Projektin ositus, vaiheistus ja resursointi... 19 8.1 Projektin suunnittelu (PS)... 20 8.2 Toteutus 1 (T1)... 21 8.3 Toteutus 2 (T2)... 22 8.4 Toteutus 3 (T3)... 22 8.5 Luovutus (LU)... 23 9. Riskienhallintasuunnitelma... 23 9.1 Johdanto... 23 9.2 Hallintamenetelmä... 24 9.2.1 Riskienhallintapäällikkö... 24 9.2.2 Top 10 Riskit... 24 9.3 Top 10 Riskilista... 24 10. Asennussuunnitelma... 25 11. Käyttöönottosuunnitelma... 25 12. Koulutussuunnitelma... 26 12.1 Projektiryhmän sisäinen koulutussuunnitelma... 26 12.2 Asiakkaalle tarjottava koulutussuunnitelma... 26 Lähteet... 26 Liitteet... 26 LIITE 1 Alustava testaussuunnitelma... 27 3(3)
1. Johdanto 1.1 Dokumentin tarkoitus Tämän dokumentin tarkoitus on toimia elävänä suunnitelmana ja päiväkirjana siitä, mihin projektilla pyritään ja missä vaiheessa kulloinkin ollaan. Sisältö pyritään pitämään mahdollisimman selkeänä ja yksinkertaisena siten että kuka tahansa voi tämän dokumentin avulla vaivattomasti tutustua projektiin. Dokumentin ylläpitämisestä vastaa projektipäällikkö Johan Engström. 1.2 Projektin tarkoitus Projektin pääasiallinen tarkoitus on aikataulussa pysyen tuottaa asiakkaalle järjestelmä joka vastaa hänen tarpeitaan ja hänen esittämiään vaatimuksiaan. 1.3 Projektin kattavuus Projektissa toteutetaan kaksiosainen järjestelmä joka koostuu: a) visualisointijärjestelmän rungosta (framework) sekä b) muutaman algoritmin esimerkkivisualisoinnista, a-kohdan runkoa käyttäen. Järjestelmän tarkat ominaisuudet ja esimerkkivisualisointien lukumäärä ja yksityiskohdat määritellään 1. toteutusvaiheen loppuun mennessä. 1.4 Tuote ja ympäristö Projektin tuotteena syntyy tietokonegrafiikan algoritmien visualisointijärjestelmä jota käytetään pääsääntöisesti Teknillisen korkeakoulun Tietokonegrafiikka-kurssin (T- 111.300) luentojen aikana algoritmien toiminnan havainnollistamiseen. 1.5 Oikeudet projektin tuloksiin Projektin tuloksien oikeuksista on määrä sopia mahdollisimman pian, heti kun sopiva sopimusrunko on löydetty ja tarkastettu. Ensimmäisen asiakastapaamisen aikana sovittiin avoimesti, että kehitys perustuu julkiseen lähdekoodiin ja että tuotteen oikeudet jäävät tasavertaisesti sekä projektiryhmälle että asiakkaalle. 4(4)
1.6 Yleiskatsaus dokumentteihin Projektin aikana tuotetaan alla olevassa taulukossa luetellut dokumentit. Taulukko 1 Projektin aikana tuotettavat dokumentit Dokumentti Kuvaus Vaihe Kieli Vastuuhenkilö Ohjata projektin kulkua ja toimia yleistiedon lähteenä projektin osapuolille PS Suomi Johan Engström Edistymisraportti Riskienhallintasuunnitelma Vaatimusmäärittely Arkkitehtuuriluonnos Tekninen määritelmä Testaussuunnitelma Testausraportti Toteutus- ja tyyliohje Käytettävyyden testaussuunnitelma Käytettävyyden testausraportti Avoimet virheet ja tiedostetut ongelmat Työkaluja ja menetelmiä Dokumentissa esitetään miten projektin riskit ja kuinka niihin varaudutaan. Päätettiin sijoittaa suoraan projektisuunnitelmaan. Asiakkaan vaatimuksien luettelointi ja analysointi Visualisointijärjestelmän teknisen arkkitehtuurin luonnos Raportti projektin etenemisestä ja tilanteesta Järjestelmän teknisten komponenttien kuvaus Suunnitelma järjestelmän ja sen komponenttien toimivuuden testaamiseen Raportti järjestelmän ja sen komponenttien testaamisesta Ohjelmointikäytäntöjen ohjeistusdokumentti (esim. luokkien ja metodien nimeäminen) Suunnitelma järjestelmän käytettävyyden arviointiin ja parantamiseen Raportti käytettävyystestauksen tuloksista sekä käytettävyyden parantamiseksi suoritetuista toimenpiteistä Luettelo virheistä/ongelmista joita ei projektin kuluessa saatu korjattua/selvitettyä Raportti projektijäsenten tutkimista ja käyttämistä työkaluista/menetelmistä PS Suomi Petri Kero PS Suomi Matti Kannala PS Englanti Samuli Laine Kaikki Suomi Johan Engström T1 Suomi Samuli Laine T1 Suomi Tero Karras T1-T3 Suomi Tero Karras T1 Suomi Iiro Ojala T2 Suomi Iiro Ojala T2 Suomi Iiro Ojala LU Suomi Tero Karras PS/LU Suomi Samuli Laine Käyttöohje Ohjeistus järjestelmän T2-LU Englanti Iiro Ojala 5(5)
Sovellusrajapinnan määritelmä (API reference) Asennusohje Loppuraportti käyttöön Visualisointijärjestelmän ohjelmointirajapinnan määritelmä Yksityiskohtainen ohje järjestelmän asennukseen Yhteenveto projektin kulusta, tuloksista sekä opituista asioista T1-LU Englanti Samuli Laine LU Englanti Samuli Laine LU Suomi Johan Engström 2. Terminologia ja määritelmät 2.1 Tekniset termit ja määritelmät FOV, eli Field Of View tarkoittaa katselukulmaa tai kuinka laajan kuvan kamera tallentaa ympäristöstä kolmiulotteisessa sovelluksessa. API, Application Programming Interface tarkoittaa ohjelmointirajapintaa, eli määritelmää siitä miten tiettyä ohjelmakirjastoa käytetään. UML - UML (Unified Modeling Language) on teollisuusstandardi ohjelmistojärjestelmien mallinnukseen, määrittelyyn, rakentamiseen ja dokumentointiin. Se sopii erittäin hyvin oliopohjaisten järjestelmien kuvaamiseen. 2.2 Projektiin liittyviä käsitteitä Mentorhenkilö on osa kurssin henkilökuntaa ja vastaa projektiryhmän ohjaamisesta projektityöskentelyyn ja työtapoihin liittyen. Viikkopalaveri on projekti ryhmän sisäinen palaveri. Viikkopalavereita pidetään kerran viikossa T-talon kahvilassa jotta pysytään perillä siitä, missä vaiheessa projektia mennään. Katselmointitilaisuus on jokaisen projektivaiheen jälkeen järjestettävä tilaisuus, jossa käydään läpi projektin tilanne. Paikalla ovat koko projektiryhmä, asiakkaan edustaja sekä mentor-henkilö. 3. Projektin toteutusperusteet Teknillisen korkeakoulun Tietokonegrafiikka-kurssilla (T-111.300) käydään läpi yleisimmät tietokonegrafiikassa käytettävät algoritmit joiden sisäistäminen on olennainen osa kurssia. Algoritmien opettaminen on kuitenkin hyvin haasteellista sillä ne etenevät usein useassa ulottuvuudessa (x, y, z, aika) eikä helposti seurattavan punaisen langan ylläpitäminen näin ollen ole helppo tehtävä. 6(6)
3.1 Asiakkaan nykyinen ratkaisu Nykyisellään Tietokonegrafiikka-kurssin luentojen oheismateriaali koostuu Internetistä löytyvistä kalvosarjoista sekä vuorovaikutteisista Java-appleteista. Näiden taso ei kuitenkaan aina vastaa luennoitsijan tarpeita eivätkä sisällä kaikkia algoritmeja joita haluttaisiin havainnollistettavan. Esim. Z-buffer-menetelmään ei ole olemassa hyvää vuorovaikutteista visualisointitapaa. 3.2 Hyödyt asiakkaalle Yleinen ongelma monimutkaisten ja etenkin kolmiulotteisten algoritmien havainnollistamisessa on luoda oppilaille kuva tietyn algoritmin etenemisestä useassa ulottuvuudessa. Toteutettavan järjestelmän avulla asiakas pystyy helpommin havainnollistamaan tietokonegrafiikan algoritmeihin liittyviä käsitteitä ja periaatteita vuorovaikutteisessa katseluohjelmassa. Projektin toisena tuotteena syntyy kolmiulotteisen grafiikan kirjastorunko, jota voidaan tarvittaessa myöhemmin laajentaa ja soveltaa myös muihin tarpeisiin. 3.3 Projektin kustannukset Kappaleessa on arvioitu projektista asiakkaalle koituvia kuvitteellisia kustannuksia. Arviossa on lähdetty olettamuksesta, että asiakas tilaisi työn freelance-pohjalta toimivalta seitsemän hengen ryhmältä, jolle tämä sitoutuisi toimittamaan kaikki tarvittavat työvälineet. Asiakkaan sisäisen työn (esim. ryhmän kanssa pidettäviin tapaamisiin kuluva asiakkaan työaika) aiheuttamia kustannuksia ei ole huomioitu. 3.3.1 Työkustannukset Projektin toteuttaa seitsemän hengen ryhmä. Jokaisen ryhmän jäsenen on arvioitu käyttävän projektiin tehokasta työaikaa 200 tuntia. Kaikki työn sivukulut sisältävänä työn hintana käytetään 50 / h. Projektista syntyvät työkustannukset ovat siis: 7 * 200 h * 50 / h = 70 000 3.3.2 Muut kustannukset Muita kustannuksia aiheutuu etenkin projektin toteuttamiseen vaadittavien laitteistojen ja ohjelmistojen hankinnasta. Työtiloista ei oleteta syntyvän ylimääräisiä kustannuksia, tapaamiset pidetään asiakkaan tiloissa ja freelancerit työskentelevät omissa tiloissaan. Puhelin yms. kuluja ei oleteta syntyvän merkittävissä määrin, ja niiden voidaan katsoa sisältyvän työkustannuksiin. Ryhmä tarvitsee käyttöönsä seitsemän PC-työasemaa sekä seitsemän lisenssiä MS Office ja MS Visual C++ 6.0 ohjelmistoista. Tällaisen kokoonpanon hinnaksi arvioidaan 3500 7(7)
euroa. Yleisesti käytetty elinikä PC-laitteistoille ja ohjelmistoille on kolme vuotta. Tämän jälkeen niiden arvosta lasketaan olevan jäljellä noin 20%. Koska projekti kestään noin 8 kalenterikuukautta, saadaan projektista aiheutuvat likimääräiset laitteisto- ja ohjelmistokustannukset seuraavasti: 7 * (8/36) * 0.8 * 3500 = 4356 3.3.1 Yhteenveto Projektin kokonaiskustannuksiksi arvioidaan 74 356 euroa, josta teetetyn työn osuus on yli 94 %. Arvioiduissa työmäärissä pysyminen on siis projektin talouden kannalta kriittisen tärkeää. Lisäksi projektin kuluessa voidaan harkita uusien kaupallisen ohjelmistojen käyttöönottoa, mikäli niiden avulla pystytään vähentämään rutiinitehtäviin kuluvaa arvokasta työaikaa. 4. Projektiorganisaatio Projektiorganisaatio koostuu asiakkaasta, mentorista ja projektiryhmästä. Asiakas toimii projektin toimeksiantajana ja on näin ollen pääasiallinen tietolähde tuotettavan järjestelmän vaatimuksia kartoitettaessa. Asiakkaalla on tekninen neuvonantaja joka antaa tarvittaessa lisätietoja järjestelmän teknisistä vaatimuksista ja rajauksista. Itse projektin toimeenpaneva elin on projektiryhmä, joka projektipäällikön johdolla tähtää projektin onnistuneeseen läpiviemiseen asetettujen tavoitteiden mukaisesti. Projektiryhmä kantaa päävastuun projektin etenemisestä ja sisäisestä tiedotuksesta. Mentor-henkilö toimii projektiryhmän projektiteknisenä neuvonantajana ja vastaa myös katselmointitilaisuuksien yhteydessä projektin arvioinnista yhdessä asiakkaan kanssa. PROJEKTIRYHMÄ ASIAKAS 7 henk. Lauri Savioja - Projektihallinta - Ohjelmistokehitys - Tiedotus - Asiakaspalaverit - Katselmointitilaisuudet TEKNINEN NEUVONTANTAJA Timo Aila - Mentorpalaverit - Projektitekninen ohjaus - Arviointi MENTOR Cemo Timucin Kuva 1 Organisaation vastuualueet ja kommunikointi 8(8)
4.1 Yhteystiedot lyhyesti Projektin kotisivut http://www.hut.fi/~mkannala/keimo/ Sivujen ylläpidosta vastaa Matti Kannala (matti.kannala@hut.fi). Yhteydenotot ryhmän jäseniin suositellaan tehtäväksi sähköpostitse ja yleisluontoiset kysymykset kannattaa ensisijaisesti ohjata projektipäällikkö Johan Engströmille (johan.engstrom@hut.fi). Mikäli haluaa tavoittaa kaikki ryhmän jäsenet voi lähettää sähköpostin osoitteeseen keimo-dev@list.hut.fi. Projektiryhmä Johan Engström Projektipäällikkö johan.engstrom@hut.fi 040-565 6751 Matti Kannala Tuotepäällikkö matti.kannala@hut.fi 0500-908 700 Iiro Ojala Laatupäällikkö iaojala@cc.hut.fi 0400-699 360 Yrjö Peussa Konfiguraatiopäällikkö peussa@iki.fi 050-531 1222 Samuli Laine Järjestelmäarkkitehti, smlaine2@cc.hut.fi 050-542 3694 ohjelmoija Tero Karras Testauspäällikkö, tkarras@cc.hut.fi 044-501 1281 käyttöliittymäsuunn., ohjelmoija Petri Kero Riskienhallintapäällikkö, ohjelmoija pkero@cc.hut.fi 040-722 2239 Sidosryhmät Lauri Savioja Asiakas lauri.savioja@hut.fi 09-451 3237 Timo Aila Tekninen neuv. timo@hybrid.fi 050-542 1898 Cemo Timucin Mentor-henkilö ctimucin@cc.hut.fi 050-548 1535 4.1 Projektiryhmä Projektiryhmä koostuu tietotekniikan opiskelijoista jotka kaikki omaavat jonkinlaisen taustan tietokonegrafiikan alueelta tai vähintäänkin kiinnostuksen tietokonegrafiikan sovelluksiin. Ryhmän 7-henkinen kokoonpano on seuraava: 9(9)
Nimi: Johan Engström Rooli: Projektipäällikkö E-Mail: Johan.engstrom@hut.fi Puhelin: 040-565 6751 Kotisivu: - Opiskelen T-osastolla N:ttä vuotta pääaineenani Vuorovaikutteinen digitaalinen media. Sivuaineeksi olen valinnut teknispainotteisuutta vähentämään Työpsykologian ja johtamisen. Tietokonegrafiikasta minulla on kokemuksia jo kymmenen vuoden takaa jolloin olin jäsenenä koodaajan tittelillä ns. "demo-gruupissa. Teimme huviksemme multimediaesityksiä joilla kilpailimme muiden ryhmien tuotosten kanssa vuosittaisissa tapahtumissa. Tuolloin kertyi huomattavan paljon kokemusta tietokonegrafiikan matalan tason ohjelmoinnista (assembly-kielellä). Nykyään työskentelen opintojen ohessa omassa yrityksessä ja tätä kautta olen saanut runsaasti arvokkaita kokemuksia pienempien ohjelmistoprojektien toteuttamisesta. Ohjelmointikielenä olen lähiaikojen projekteissa käyttänyt lähinnä Javaa. Nimi: Matti Kannala Rooli: Tuotepäällikkö E-Mail: matti.kannala@hut.fi Puhelin: 0500-908 700 Kotisivu: - Opiskelen T osastolla 4:ttä vuotta. Pääaineenani on Digitaalisten tuotteiden kehittäminen ja sivuaineena on Vuorovaikutteinen digitaalinen media. Tällä kurssilla haluaisin saada kokemusta ohjelmistoprojektista kokonaisuudessaan ja saada kokeilla opittuja ohjelmistoprosessiin kuuluvia menetelmiä. Menetelmistä erityisesti kiinnostaa vaatimustenhallinta ja testaus. Tällä hetkellä olen töissä kehittämässä rakennusalan 3D-CAD ohjelmistoa. Työn kautta minulla on kokemusta keskisuuresta ohjelmistotuoteprojektista. Aiempaa harrastuspohjaista ohjelmointikokemusta on C64-ajoilta asti. Nimi: Iiro Ojala Rooli: Laatupäällikkö E-Mail: iaojala@cc.hut.fi Puhelin: 0400-699 360 Kotisivu: Olen neljännen vuoden tietotekniikan opiskelija. Pääaineeni on Ohjelmistojärjestelmät. Tietokonegrafiikasta olen varsinaisesti kiinnostunut vasta opintojen aikana. Tätä kiinnostusta tyydyttämään olen valinnut sivuaineekseni 10(10)
Vuorovaikutteisen digitaalisen median. Ohjelmointikokemusta minulla on puolentoista vuoden ajalta 3DCAD-kehityksestä. Kurssilla odotan oppivani lisää pienen tiimin projektiluontoisesta ohjelmistokehityksestä. Nimi: Yrjö Peussa Rooli: Konfiguraatiopäällikkö E-Mail: peussa@iki.fi Puhelin: 050-531 1222 Kotisivu: - Olen noin 50 ov opiskellut 3. vuoden tietoteekkari. Osa- tai lyhytaikaista työkokemusta on kahdesta firmasta ja kolmelta paikkakunnalta, lähinnä tietokonepelien parista. Olen suorittanut projektin kannalta ehkä oleellisimmat (ohjelmistotuotannon ja tietokonegrafiikan) peruskurssit. Tässä projektissa minua kiinnostavat eniten korkean tason grafiikkaohjelmointi sekä ohjelmistotuotannon tekniset apuneuvot. Nimi: Samuli Laine Rooli: Järjestelmäarkkitehti, ohjelmoija E-Mail: smlaine2@cc.hut.fi Puhelin: 050-542 3694 Kotisivu: - Olen ohjelmoinut harrastuksen ja työn merkeissä kirjavaa joukkoa erilaisia laitteita ulottuen 8-bittisistä mikro-ohjaimista moderniin numeronmurskauskalustoon. Sovellusalueet ovat niinikään vaihdelleet laidasta laitaan. Muutaman kerran olen päässyt osallistumaan kansainvälisiin tietotekniikkakilpailuihin, ja olin mukana järjestämässä vuoden 2001 kansainvälisiä informatiikkaolympialaisia (IOI) Tampereella. Työrintamalla vedän paraikaa projektia, jossa kehitetään näkyvyyslaskentaohjelmistoa peliteollisuuden ja miksei muidenkin staattisesta piilopintojen poistosta kiinnostuneiden käyttöön. Nimi: Tero Karras Rooli: Testauspäällikkö, käyttöliittymäsuunnittelija, ohjelmoija E-Mail: tkarras@cc.hut.fi Puhelin: 044-501 1281 Kotisivu: - Opiskelen tietotekniikkaa kolmatta vuotta, tulevana pääaineenani akustiikka ja äänenkäsittelytekniikka, sivuaineena ohjelmistojärjestelmät. Koulutusta 11(11)
ohjelmistoprojekteista tai tietokonegrafiikasta en vielä varsinaisesti ole saanut, mutta molemmista on kertynyt jonkin verran kokemusta harrastuspohjalta. Kuusi vuotta sitten toimin eräässä pienehkössä demoryhmässä koodaajana. Tämän jälkeen olen toteuttanut monenlaisia järjestelmiä ja algoritmeja puhtaasti kiinnostuksen vuoksi. 3D-grafiikan luulisi siis olevan varsin hyvin hallussa. Nimi: Petri Kero Rooli: Riskienhallintapäällikkö, ohjelmoija E-Mail: pkero@cc.hut.fi Puhelin: 040-722 2239 Kotisivu: - 4.2 Sidosryhmät Projektin asiakkaana toimii professori Lauri Savioja Teknillisestä korkeakoulusta. Asiakkaan teknisenä neuvonantajana toimii tutkija Timo Aila Teknillisestä korkeakoulusta. Projektin mentor-henkilönä toimii tekniikan ylioppilas Cemo Timucin. 5. Projektin tavoitteet ja päättäminen 5.1 Asiakkaan tavoitteet Asiakkaan itse järjestelmää koskevat tavoitteet jakautuvat raasti kahteen osaan: 1. visualisointijärjestelmän runko (framework) ja ohjelmointirajapinta (API) sekä 2. muutaman algoritmin esimerkkivisualisoinnista, a-kohdan runkoa käyttäen. Asiakkaan vaatimuksia kerätään projektin alkuvaiheessa ja osittain myös myöhemmin erilliseen vaatimusmäärittely-dokumenttiin. Yleisemmät projektia koskevat tavoitteet on lueteltu TOP-10 otsikon alla. 12(12)
5.1.1 Visualisointijärjestelmän runko Asiakas toivoo visualisointijärjestelmän rungon toteutettavaksi mahdollisimman yleiskattavaksi siten, että sitä voidaan hyödyntää yleisellä tasolla eri tyyppisten visualisointien toteutukseen. Visualisointiin liittyvät perustoiminnot kuten objektien sisään luku ja siirtely, geometriset muunnokset, kameroiden määrittely ja sijoitus ym. tulee integroida järjestelmään perusominaisuuksiksi. 5.1.2 Esimerkkivisualisoinnit Projektissa toteutetaan muutama esimerkkivisualisointi toteutettua järjestelmärunkoa käyttäen. Nämä toimivat sekä suoraan työkaluina Tietokonegrafiikka-kurssin opetukseen sekä visualisointijärjestelmän rungon käyttöesimerkkeinä. 5.1.3 Asiakkaan TOP-10 tavoitteet Alla asiakkaan määrittelemät kymmenen tärkeintä yleisen tason tavoitetta projektin suhteen. Tavoitteiden toteutumista tarkastellaan projektin lopussa. 1. Korkeantason ohjelmointirajapinta visualisointia varten 2. Joukko valmiita visualisointeja 3. Tekninen dokumentaatio 4. Käyttöohjeet 5. Käytettävyys visualisointien käyttäjän kannalta 6. Käytettävyys visualisointien tekijän kannalta 7. Robustius 8. Laajennettavuus 9. Opittavuus 10. Siirrettävyys muille alustoille 5.2 Projektiryhmän tavoitteet 5.2.1 Asiakastyytyväisyys Projektiryhmän pääasiallisena tavoitteena on pystyä kohtaamaan asiakkaan tavoitteet ja vaatimukset siten, että asiakas tuntee projektin jälkeen saaneensa sitä mitä projektilta alun perin toivoikin (ja kenties vähän enemmänkin). Jotta tähän tavoitteeseen päästäisiin on projekti suoritettava järjestelmällisesti ja kurinalaisesti asianmukaisia yleisesti hyväksi todettuja ohjelmistotuotannon menetelmiä käyttäen. Käytettävistä työkaluista ja menetelmistä enemmän tämän dokumentin kappaleessa 7. 13(13)
5.2.2 Oppimistavoitteet Kaikkien ryhmäjäsenten yhteisenä tavoitteena on projektin avulla oppia ymmärtämään paremmin ohjelmistotuotantoon liittyviä työkaluja, prosesseja ja hallintamenetelmiä sekä oppia näiden käytännön soveltamista. Kukin projektiryhmän jäsenistä on valinnut itselleen työkalun tai menetelmän johon aikoo perehtyä syvemmin projektin aikana. Valitut työkalut ja menetelmät on lueteltu taulukossa. Kukin ryhmäjäsen raportoi projektin päätteeksi kokemuksistaan valitsemansa työkalun/menetelmän käytännön soveltamisesta. Tulokset raportoidaan erillisissä käyttöönottosuunnitelma-dokumenteissa. Taulukko 2 Johan Käytettävyystestaus, heuristinen arviointi http://www.useit.com/papers/heuristic/ Ykä Versionhallinta, CVS http://www.cvshome.org/ Samuli Ohjelmakoodin dokumentointi, Doxygen http://www.doxygen.org/ Iiro Koodikatselmukset (Code reviews) Petri Riskienhallinta Matti Vaatimustenhallinta Tero Yksikkötestaus, CppUnit http://cppunit.sourceforge.net/ 5.2.3 Projektiryhmän TOP-10 tavoitteet Alla projektiryhmän määrittelemät kymmenen tärkeintä yleisen tason tavoitetta projektin suhteen. Tavoitteiden toteutumista tarkastellaan projektin lopussa. 1. Kurssin läpäisy 2. Arvosana >= 3 3. Uuden oppiminen 4. Laajempi ymmärrys ohjelmistotuotannon menetelmistä ja työkaluista sekä niiden tehokkaasta hyväksikäytöstä 5. Asiakastyytyväisyys 6. Tyytyväisyys omaan panokseen 7. Ammattimainen lopputulos eri vaiheiden tuotoksissa 8. Visuaalisesti vaikuttava sovellus (demo-efekti) 9. Vaiheiden vaatimusten täyttäminen (ja vähän päälle) 10. Aikataulussa pysyminen 14(14)
5.3 Projektin keskeyttämiskriteerit Projekti keskeytetään mikäli 2 tai useampi projektiryhmän jäsenistä jättää ryhmän, koska näin ollen projektin hyväksyttävä loppuun vieminen katsotaan mahdottomaksi. Toinen projektin keskeyttämiseen johtava tilanne on, jos projektiin budjetoidut kokonaistuntimäärät ylitetään. Kaikissa tapauksissa projektia voidaan kuitenkin jatkaa, mikäli projektiryhmän jäsenet näin yhdessä päättävät. 5.4 Projektin päättämiskriteerit Projektin päättyminen on sidottu kurssin (T-76.115) aikatauluun jonka mukaan palautusvaihe päättyy 14.4. johon mennessä järjestelmä on siis toteutettu, testattu ja asennettu sekä asianmukaiset dokumentaatiot toimitettu. Tämän jälkeen jäljellä on enää demo-tilaisuuteen osallistuminen 15.-16.4. 6. Projektin resurssit Projektille on resursoitu kunkin projektijäsenen osalta 200 työtuntia. Muita resursseja ei ole varattu. Koska projektin on kuitenkin tarkoitus vastata oikeata ohjelmistoprojektia tehdään tämän mukaisesti myös asianmukaiset kustannusarviot ja laskelmat. Yleisesti projektissa pyritään käyttämään ilmaisia avoimeen lähdekoodiin perustuvia ohjelmistoratkaisuja mutta myös kaupallisten tuotteiden käyttö on mahdollista siinä määrin kuin niiden virtuaaliset kustannusseuraamukset ovat järkevissä mitoissa. 6.1 Henkilöresurssit Projektille on allokoitu jokaiselta projektiryhmän seitsemältä jäseneltä 200 työtuntia, joiden jakautuminen projektin eri vaiheisiin on määritelty luvussa 8 Projektin ositus, vaiheistus, ja resursointi. Yhteensä projektiin on siis resursoitu 1400 työtuntia. Resursoinnissa ja aikatalutuksessa otetaan huomioon seuraavat rajoittavat ajanjaksot. Mitään pidempiä poissaolojaksoja ei ole toistaiseksi tiedossa minkään projektijäsenen osalta. Tenttikausi: 9.12. 20.12.2002 Joululoma: 21.12.2002 6.1.2003 Tenttikausi: 7.1.2003 11.1.2003 Pääsiäisloma: 17.-23.4.2003 6.2 Muut resurssit Projektissa käytetään pääasiassa projektiryhmän jäsenten omia sekä korkeakoulun tarjoamia tietokoneita ja muita välineitä. Mikäli projektissa esiintyy tarvetta muiden, 15(15)
kenties maksullisten resurssien käyttöön, tästä informoidaan välittömästi asiakkaalle ja keskustellaan resurssiongelman ratkaisuun johtavista vaihtoehtoisista menettelytavoista. 7. Käytettävät menetelmät ja työkalut Yleisesti projektissa pyritään eri osa-alueiden laadun varmistamiseksi käyttämään mahdollisimman pitkälle yleisesti tunnettuja ja toimiviksi todettuja työkaluja ja menetelmiä. Tässä luvussa on lyhyesti esitelty projektin eri osa-alueissa hyödynnettäviä työkaluja ja menetelmiä. 7.1 Projektinhallinta Projektissa ei varsinaisesti sovelleta mitään virallista projektinhallintametodiikkaa, mutta projektin edistymistä seurataan jatkuvasti projektipäällikön toimesta ja viikoittaiset palaverit toimivat tämän periaatteen toteutumisen kulmakivenä. 7.2 Vaatimustenhallinta Vaatimukset ovat järjestelmän toimintoja, ominaisuuksia ja rajoituksia. Vaatimustenhallinta on systemaattinen menetelmä vaatimuksien löytämiseen, dokumentointiin, organisointiin ja muutosten hallintaan. Vaatimustenhallintaa tehdään koko projektin ajan. Vaatimustenhallinnassa ei käytetä mitään erityistä siihen tarkoitettua ohjelmistoa vaan käytössä on Microsoft Word 2000 ja tavallinen tekstieditori. Tässä projektissa vaatimukset kerätään asiakastapaamisissa ja projektiryhmän palavereissa. Kaikille vaatimuksille annetaan yksilöllinen tunnus ja ne dokumentoidaan vaatimuslistaan. Vaatimuslista on yksinkertainen lista vaatimuksista tunnisteineen. Listasta jalostetaan käyttäjävaatimusdokumentti, johon toiminnalliset vaatimukset kirjataan käyttäjätapauksina ja ominaisuudet sekä rajoitukset kirjataan normaaleina vaatimuksina. Käyttäjävaatimusdokumentissa on vaatimusten lisäksi määritelty käyttäjäryhmät ja vaatimuksien prioriteettivaihtoehdot. Jokaiselle vaatimukselle määritellään molemmat näistä. Käyttäjävaatimusdokumentissa on lisäksi kerrottu vaatimuksienmuutosprosessi ja vaatimuksientoteutumisen mittaamiseen käytettävät mittarit. -vaiheen loputtua vaatimusmääritelmä hyväksytetään asiakkaalla ja samalla sitoudutaan noudattamaan vaatimuksia toimitettavassa tuotteessa. Sen jälkeen vaatimustenhallinnassa jokainen muutos vaatimuksiin käy läpi vaatimustenmuutosprosessin. Vaatimuksia, varsinkin käyttäjätapauksia käytetään tuotteen testien määrittelyyn. Näistä tärkein on vaatimuksien kannalta hyväksymistestaus, joka perustuu tarkasti vaatimuksiin. Sen avulla voidaan todeta onko tuote toteuttanut sille annetut vaatimukset ja onko se hyväksyttävä toimitettavaksi. 16(16)
7.3 Riskienhallinta Projektin riskinhallintakäytäntö on kuvattu riskienhallintasuunnitelmassa luvussa 9. 7.4 Suunnittelu Ohjelmisto toteutetaan oliopohjaisena. Järjestelmän staattisen luokkamallin esittämiseen käytetään soveltuvilta osin UML:ää. UML muun muassa tehostaa ohjelmoijien välistä kommunikointia ja helpottaa järjestelmän arkkitehtuurin ylläpitoa. Suunnitteluprosessin ei kuitenkaan haluta muodostuvan liian raskaaksi, eikä UML:n kaikkia piirteitä siksi tulla aktiivisesti käyttämään. Ohjelmiston suunnittelussa käytetään yleisesti hyväksi havaittuja suunnittelumalleja. Suunnittelumallien käyttö selkeyttää ohjelman rakennetta ja helpottaa sen ylläpidettävyyttä. Yleisimpien, niin sanottujen Gang of Four suunnittelumallien sovelluskohteet myös nimetään mallin mukaan. Sekä UML:n että suunnittelumallien käyttöönotto on järjestelmäarkkitehdin vastuulla, ja siihen tullaan ottamaan tarkemmin kantaa T1-vaiheessa. Tällöin myös päätetään käytettävistä valmisohjelmistoista ja muista työkaluista. 7.5 Ohjelmointi Ohjelmiston ensisijainen kohdeympäristö on Windows. Ohjelmisto myös toteutetaan Windows-ympäristössä. Toteutuskieli on C++ ja käytettävä kehitysympäristö MS Visual C++ 6.0. VC++ on yksi monista kaupallisista integroiduista kehitysympäristöistä. Sen valinnan ensisijainen peruste oli kaikkien ryhmän jäsenten positiiviset kokemukset sen käytöstä. Lisäksi siitä ei ole ryhmän tiedossa mitään sellaisia oleellisia puutteita, jotka tulisivat haittaamaan ohjelman kehitystä ja jotka kilpailevissa tuotteissa olisi toteutettu paremmin. Versio 6.0 päätettiin valita sen saatavuuden takia. Uudempaa.NET versiota ei ole koulun tarjoamissa työkaluvalikoimissa ja yhteensopivuuden takaamiseksi on parasta, että kaikki ohjelmoijat käyttävät samaa versiota. Ohjelmointityyliä koskevista säännöistä laaditaan T1-vaiheessa erillinen ohje, jota tarpeen mukaan tarkennetaan myöhemmin. Kaikkien ryhmän jäseten tulee noudattaa sovittuja tyyliohjeita, jotta koodi säilyy mahdollisimman yhtenäisenä. Näin koodin sekä lukeminen että ylläpito nopeutuvat. Ohjetta tullaan käyttämään myös koodikatselmuksia pidettäessä. 7.6 Testaus Testaus on olennainen osa tuotteen laadunvalvontaa ja pyrimmekin projektin resurssien rajoissa harjoittamaan yleisesti tunnettuihin menetelmiin perustuvaa järjestelmällistä testausta järjestelmän eri osille. 17(17)
7.6.1 Tekninen testaus Projektissa käytetään testausstrategioina erityisesti yksikkötestausta ja järjestelmätestausta. Yksikkötestaus suoritetaan osana ohjelmointityötä siten, että kukin ohjelmoija kehittää joukon testitapauksia jokaiselle kirjoittamalleen moduulille. Työkaluna käytetään CppUnit-kirjastoa, joka hoitaa testien ajon ja tulosten raportoinnin sekä yhdenmukaistaa testitapausten esitysmuodon. Testitapaukset säilytetään osana lähdekoodia, ja ne ajetaan uudelleen jokaisen muutoksen yhteydessä. Periaatteena on, että kaikki versionhallintaan liitettävä koodi läpäisee sitä koskevat yksikkötestit. Järjestelmätestauksessa sovelletaan enimmäkseen ad-hoc-menetelmää. Testausta suorittavat sekä ryhmän jäsenet että asiakas. Tällä tavalla saadaan hyvä kuva siitä, mitä todellinen käyttäjä järjestelmältä haluaa, ja miten hyvin tämä hänen vaatimuksensa toteuttaa. Yleisimmät testit automatisoidaan tarvittaessa, jolloin niiden tulokset ovat tarkkaan määriteltyjä ja vertailukelpoisia. Myös automatisoitua kuormitus- ja suorituskykytestausta sovelletaan projektin viimeisessä implementaatiovaiheessa. Integraatiotestaus hoidetaan noudattamalla jatkuva integraatioperiaatetta siten, että uudet moduulit integroidaan järjestelmään viimeistään heti niiden valmistuttua. Näin järjestelmästä on aina olemassa jonkinlainen toimiva kokonaisuus, ja mahdolliset rajapintoihin liittyvät ongelmat tulevat esille jo aikaisessa vaiheessa. Kattavampi testaussuunnitelmaluonnos liitteenä. 7.6.2 Käytettävyystestaus Käyttöliittymätestaukseen käytetään heuristista tarkastelua joka on yksinkertainen ja halpa tarkistuslista-pohjainen menetelmä käytettävyyden parantamiseen. Menetelmästä enemmän tietoa Työkalut ja menetelmät dokumentissa. 7.7 Dokumentointi Dokumentointi on olennainen osa projektin sisäistä ja ulkoista tiedonkulkua joten dokumentaation kattavuuteen, ajan tasalla pitämiseen sekä laatuun tullaan panostamaan huomattava määrä resursseista. 7.7.1 Sisäiset dokumentit Projektin sisäiset dokumentit, eli projektiorganisaatiolle suunnatut dokumentit kirjoitetaan pääsääntöisesti Microsoft Word 2000 ohjelmistolla (http://www.microsoft.com/office/word/). Tiedostoilla on näin ollen.doc-pääte. 18(18)
7.7.2 Tekninen dokumentointi Tekninen dokumentointi sekä ohjeistusdokumentaatio kirjoitetaan Latex:lla. API:n dokumentaatio generoidaan ohjelmakoodista Doxygen nimisellä ohjelmistolla (http://www.doxygen.org/). 7.8 Tiedonkulku ja työskentelytavat Jotta projektin etenemistä voitaisiin seurata ja jotta kaikki projektin jäsenet voisivat pysyä perillä siitä missä vaiheessa kulloinkin ollaan, pidetään tasaisin väliajoin palavereita jossa näitä asioita käydään läpi. Viikoittain kokoonnutaan projektiryhmän kesken ja asiakkaan sekä muiden sidosryhmien kanssa järjestetään myös aika ajoin tarpeen mukaan. Sähköposti on pääasiallinen yhteydenpitoväline ja kaikilla ryhmänjäsenillä on sähköpostilaatikko jonka sisältö tarkistetaan mahdollisuuksien mukaan päivittäin. Projektiryhmälle on myös muodostettu sähköpostilista keimo-dev@list.hut.fi johon lähetetyt sähköpostiviestit ohjautuvat kaikille ryhmän jäsenille. 7.8.1 Viikkopalaverit Ryhmän jäsenet tapaavat kerran viikossa viikkopalaverissa, jossa käydään läpi tehtyjä töitä ja suunnitellaan seuraavan viikon tehtäviä. Viikkopalaveri pidetään tiistaisin klo. 15:30 16:15 T-talon ruokalassa. Palavereja edeltää lyhyt tapaaminen asiakkaan kanssa. 7.8.2 Asiakastapaamiset Asiakas tavataan viikoittain viikkopalaverin yhteydessä klo. 15:30 tiistaisin T-talon ruokalassa, ellei muuta sovita. Pidempiä palavereja voidaan tarvittaessa sopia näiden lyhyiden yhteenvetopalavereiden yhteydessä. 8. Projektin ositus, vaiheistus ja resursointi Projekti on jaettu viiteen vaiheeseen Projektinsuunnittelu (PS), Toteutus 1-3 (T1-T3) ja Luovutus (LU), ks. kuva 2. Kunkin vaiheen jälkeen pidetään katselmointitilaisuus jossa käydään läpi projektin tilanne, projisoidaan seuraavaa vaihetta sekä toimitetaan kunkin vaiheen aikana tuotetut dokumentit. 19(19)
ALKU LOPPU 10.9.2002 28.10.2002 2.12.2002 10.2.2003 24.3.2003 24.3.2003 PS T1 T2 T3 LU - v1 - Vaatimusmääritelmä v1 - Riskienhallintasuunnitelma - v3 - Vaatimusmääritelmä v3 - Tekninen määritelmä v2 - Testausraportti v2 - Käytettävyyden testaussuunnitelma - Käytettävyyden testausraportti v1 - v5 - Tekninen määritelmä v4 - Avoimet virheet ja tiedostetut ongelmat - Käytettyjä työkaluja ja menetelmiä - Käyttöohje - Asennusohje - Loppuraportti - v2 - Vaatimusmääritelmä v2 - Tekninen määritelmä v1 - Testaussuunnitelma - Testausraportti v1 - v4 - Tekninen määritelmä v3 - Testausraportti v3 - Käytettävyyden testausraportti v2 Kuva 2 Projektin vaiheet 8.1 Projektin suunnittelu (PS) PS-vaiheen alussa projektiryhmä järjestäytyy ja tutustuu asiakkaaseen sekä mentoriin. Vaiheen tärkein tärkein tarkoitus on projektisuunnitelman, laatukäsikirjan sekä alustavan vaatimusmäärittelyn tuottaminen. PS-vaiheen aikataulu Palautettavat dokumentit valmiit 21.10.2002 15:00 tarkastettaviksi Dokumentit katselmoitu 23.10.2002 15:00 Dokumenttien korjaus tehty 24.10.2002 09:00 Dokumentit asiakkaalle hyväksyttäväksi 25.10.2002 15:00 Kurssin palautuksen takaraja 28.10.2002 15:00 20(20)
PS-vaiheen resursointi Tehtävä Tekijät Budjetoidut tunnit Luennot Kaikki 52,5 Opiskelu Kaikki 66 - MS Project - Uudet teknologiat - Oma menetelmä/työkalu Ryhmäpalaverit Kaikki 42 Asiakaspalaverit Kaikki 15 Mentorpalaverit Kaikki 14 Projektin organisointi Johan, Matti 12 Vaatimusten hallinta Matti 20 Projektisuunnittelu Johan + osittain muut 32 Kehitysympäristön Ykä, Matti 5 pystyttäminen Www-ylläpito Matti 4 Seuraavan vaiheen suunnittelu Johan 10 Edistysraportin kirjoittaminen Johan 2 Valmistautuminen Johan 2 katselmointiin Katselmointitilaisuus Kaikki 7 Yhteensä 283,5 8.2 Toteutus 1 (T1) T1-vaiheessa aloitetaan itse järjestelmän suunnittelu ja aloitetaan ohjelmointityö. Vaiheen tuotteina syntyy tekninen määritelmä, testaussuunnitelma, testausraportti sekä ensimmäinen versio visualisointijärjestelmän rungosta (framework) sekä sen ohjelmointirajapinnasta (API). T1-vaiheen aikataulu Toiminnallinen määrittely valmis 5.11.2002 Tekninen määrittely valmis 5.11.2002 Testaussuunnitelma valmis 8.11.2002 Rungon 1. versio valmis testaukseen 19.11.2002 Testaus suoritettu 22.11.2002 Korjaukset tehty ohjelmistoon 26.11.2002 Palautettavat dokumentit valmiit tarkastettaviksi 26.11.2002 Dokumentit katselmoitu 27.11.2002 Dokumenttien korjaus tehty 28.11.2002 Dokumentit asiakkaalle hyväksyttäväksi 29.11.2002 Kurssin palautuksen takaraja 2.12.2002 21(21)
T1-vaiheen resursointi Tehtävä Tekijät Budjetoidut tunnit Opiskelu Kaikki 28 Ryhmäpalaverit Kaikki 28 Asiakaspalaverit Kaikki 8 Mentorpalaveri Kaikki 7 Projektin organisointi Johan 12 Toiminnallinen määrittely Matti 8 Tekninen suunnittelu Samuli, Tero 18 Ohjelmointi Samuli, Tero, Petri + 148 muut Testaus Tero, Ykä 18 WWW-ylläpito Matti 10 Seuraavan vaiheen suunnittelu Johan 6 Edistysraportin kirjoittaminen Johan 2 Valmistautuminen Johan 2 katselmointiin Katselmointitilaisuus Kaikki 7 Yhteensä 302 8.3 Toteutus 2 (T2) Tämän vaiheen tarkempi suunnitelma tehdään vaiheessa T1. Alustavasti ajatuksena on tuottaa visualisointijärjestelmän rungosta versio kaksi sekä yksi tätä hyväksi käyttävä visualisointi. Käytettävyyden testaaminen aloitetaan. T2-vaiheen alustava aikataulu Palautettavat dokumentit valmiit tarkastettaviksi 10.02.2003 Dokumentit katselmoitu 10.02.2003 Dokumenttien korjaus tehty 10.02.2003 Dokumentit asiakkaalle hyväksyttäväksi 10.02.2003 Kurssin palautuksen takaraja 10.02.2003 8.4 Toteutus 3 (T3) Tämän vaiheen tarkempi suunnitelma tehdään vaiheessa T2. Alustavasti tässä vaiheessa toteutetaan tärkeysjärjestyksessä jäljellä olevat vaatimukset tavoitteena saada kaikki vaatimukset täytettyä. 22(22)
T3-vaiheen aikataulu Palautettavat dokumentit valmiit tarkastettaviksi 17.3.2003 Dokumentit katselmoitu 19.3.2003 Dokumenttien korjaus tehty 20.3.2003 Dokumentit asiakkaalle hyväksyttäväksi 21.3.2003 Kurssin palautuksen takaraja 24.3.2003 8.5 Luovutus (LU) Tämän vaiheen tarkempi suunnitelma tehdään vaiheessa T3. Alustavasti järjestelmä viimeistellään vaiheen aikana luovutuskuntoon ja laaditaan sekä viimeistellään asennusja käyttöohjeet sekä muut dokumentit. Tähän vaiheeseen kuuluu myös järjestelmän testaaminen toisen ohjelmatyö-projektiryhmän toimesta. Vastaavasti tämän projektin ryhmä testaa toisen ryhmän järjestelmää ja kirjoittaa tästä raportin. T3-vaiheen aikataulu Palautettavat dokumentit valmiit tarkastettaviksi 7.4.2003 Dokumentit katselmoitu 9.4.2003 Dokumenttien korjaus tehty 10.4.2003 Dokumentit asiakkaalle hyväksyttäväksi 11.4.2003 Kurssin palautuksen takaraja 14.4.2003 9. Riskienhallintasuunnitelma 9.1 Johdanto Ohjelmistoprojektit ovat niin monimutkaisia, että ne ovat väistämättä alttiita riskeille. Kustannukset voivat ylittää arviot tai projektit voivat valmistua myöhässä tai keskeytyä kokonaan, mikäli riskit pääsevät realisoitumaan vahingoiksi asti. Siksi onkin tärkeää, ettei riskien anneta kehittyä rauhassa, vaan niitä seurataan ja niitä yritetään pienentää aktiivisesti projektin alusta loppuun saakka. Käytännössä riskien hallintaa toteutetaan kahdella tavalla: projektiin nimitetään riskienhallintapäällikkö, jonka vastuualueena on kaikki riskeihin liittyvä toiminta. Lisäksi projektille laaditaan kymmenen pahimmaksi arvioidun riskin lista, joka on avoin kaikille projektiin osallistujille ja jota päivitetään säännöllisesti. 23(23)
9.2 Hallintamenetelmä 9.2.1 Riskienhallintapäällikkö Riskien hallintaan kuuluu olennaisena osana uusien riskien havaitseminen ja vanhojen uudelleenarviointi koko projektin ajan. Tästä syystä kyseisessä roolissa toimivan projektin jäsenen täytyy omaksua itselleen pessimistinen suhtautuminen projektiin. Henkilön täytyy siis kiinnittää huomionsa erilaisista päätöksistä aiheutuviin mahdollisiin riskeihin. Lisäksi riskienhallintapäällikkö toimii projektin riskilistan moderaattorina; kaikki muutokset listaan kulkevat hänen kauttaan. 9.2.2 Top 10 Riskit Projektin riskeistä pidetään jatkuvasti kirjaa ja niiden tilannetta pyritään arvioimaan uudelleen, mikäli niihin vaikuttavat asiat ovat muuttuneet. Näin projektin onnistumista heikentävät tekijät voidaan nopeasti havaita ja vastatoimet aloittaa. Jokaiseen riskiin kirjataan luonnollisesti myös keinot, joilla kyseisen riskin realisoitumista pyritään ehkäisemään. Itse lista on suhteellisen yksinkertainen, jotta riskienhallinta olisi mahdollisimman kevyttä, eikä turhaa byrokratiaa pääsisi syntymään. Lista itsessään on kaikkien nähtävillä, jotta jokaisella projektiin osallistujalla olisi tieto kaikista riskeistä ja niitä vastaan käytettävistä menetelmistä. Näin jokainen voi tehdä osansa riskien ehkäisemisessä sekä auttamalla riskilistan ajankohtaisena pitämisessä että toteuttamalla riskien torjuntaan käytettäviä keinoja. 9.3 Top 10 Riskilista Tällä viikolla Viime viikolla Viikkoja listalla Riski 1-1 Projektin jäsenten ajanpuute Menetelmät riskin ehkäisemiseksi Työt pyritään jakamaan sen mukaan miten kelläkin on aikaa, kuitenkin siten, että yhteensä koko projektin aikana kaikki tekevät riittävän määrän. 2-1 Feature creep Suunnittelussa pyritään minimalismiin. Vaatimusdokumentti määrittelee tuetut ominaisuudet tarkasti. 3-1 Aikataulun ylittyminen Suunnitteluvaiheessa projektin vaatimusdokumentti annetaan asiakkaan allekirjoitettavaksi, jonka jälkeen siihen ei enää tehdä muutoksia. Projektista tehdään mahdollisimman tarkka aikataulu vaatimusdokumentin jälkeen. Aikataulua uudelleen arvioidaan kesken projektin. 24(24)
4-1 Perfektionismi suunnittelussa tai toteutuksessa 5-1 Valmis projekti on huonolaatuinen 6-1 Viivästykset työkalujen takia 7-1 Ongelmat asiakkaan ja kehittäjien välillä Projektia seurataan aktiivisesti, jotta aikataulun rikkoutuminen huomattaisiin mahdollisimman aikaisin. Suunnittelussa pyritään minimalismiin. Vaatimusdokumentti määrittelee tuetut ominaisuudet tarkasti. Tekniset katselmukset suoritetaan koodille, vaatimuksille ja suunnitteludokumenteille. Testaussuunnitelma varmistaa, että kaikki määritelty funktionaalisuus on toteutettu. Käytetään yhteistä ohjelmointitapaa. Ohjelman testaus suoritetaan erillisesti ohjelman kehityksestä. Käytetään projektijäsenille jo entuudestaan tuttuja työkaluja. Vaatimusdokumentti tehdään yhteistyössä asiakkaan kanssa ja annetaan lopuksi asiakkaan hyväksyttäväksi. 10. Asennussuunnitelma Ohjelmiston asennukseen liittyvät yksityiskohdat tarkentuvat myöhemmässä vaiheessa projektia. Erillisessä käyttöohjeessa ohjelmiston asentaminen ohjeistetaan vaihe vaiheelta. Koska kyseessä on irrallinen ohjelmisto, ei varsinaista tuotantoympäristöä ole olemassa. Asennus pyritään luonnollisesti tekemään mahdollisimman yksinkertaiseksi. 11. Käyttöönottosuunnitelma Käyttöönottoon liittyvät yksityiskohdat tarkentuvat myöhemmässä vaiheessa projektia. Käyttöohje ja ohjelmointirajapinnan määrittely pyritään laatimaan niin perusteellisesti, että käyttöönotto sujuu kaikilta käyttäjäryhmiltä ongelmitta. Käyttäjäryhmät olemme hahmotelleet seuraavasti: a) Tietokonegrafiikka-kurssin luennoitsija (visualisointien esitys) b) Tietokonegrafiikka-kurssin assistentti (visualisointien suunnittelu) c) Opiskelijat (itseopiskelua) d) Muut (3D-grafiikkarungon käyttöä eri sovelluksiin) 25(25)
12. Koulutussuunnitelma 12.1 Projektiryhmän sisäinen koulutussuunnitelma Projektilla ei ole sisäistä koulutusta. Jokainen projektiryhmän jäsen opettelee tarvittaessa itsenäisesti projektityökalujen käyttöä ja projektin käyttämiä menetelmiä. Lisäksi ryhmä hyödyntää kurssiin sisältyviä luentoja ja ryhmän projektipäällikkö osallistui kurssin puitteissa järjestettyyn MS Project -koulutukseen. 12.2 Asiakkaalle tarjottava koulutussuunnitelma Projektiin ei sisälly asiakkaalle tarjottavaa koulutusta. Se olisi tuskin mielekästä projektin luonteen takia; dokumentaatio on tässä tapauksessa oleellisesti järkevämpi tapa siirtää projektiin liittyvä osaaminen mahdollisille jatkokehittäjille. Lähteet [1] Sommerville, I., Software Engineering, 6th Edition, Addison-Wesley, 2001 [2] Haikala, I. ja Märijärvi, J., Ohjelmistotuotanto, 5. painos, Suomen ATK-Kustannus Oy, 1998 Liitteet LIITE 1 Alustava testaussuunnitelma 26(26)
LIITE 1 Alustava testaussuunnitelma Projektin aikana sovelletaan testaukseen kaikkia kolmea perusstrategiaa: yksikkötestausta, integraatiotestausta ja järjestelmätestausta [2]. Testausmenetelmät noudattavat soveltuvin osin XP-konseptia, vaikkei tätä muutoin projektissa käytetäkään. Yksikkötestaus Jokaiselle järjestelmän moduulille kirjoitetaan sen kehityksen yhteydessä joukko testitapauksia [1]. Yleisenä periaatteena on, että ohjelmakoodin lisäämistä tai päivittämistä versionhallintaan pyritään välttämään, elleivät kaikki vaaditut testit tule läpäistyiksi. Testitapauksia päivitetään aina, kun järjestelmästä löydetään aikaisemmin havaitsematta jääneitä virheitä, jolloin niiden toistumiselta voidaan jatkossa välttyä. Menetelmän ansiosta ohjelmakoodin taso saadaan pidettyä korkeana, ja pahimmat virheet löytyvät jo aikaisessa vaiheessa, jolloin niiden korjaaminen onnistuu kohtuullisen pienellä vaivalla. Myös kynnys koodin muuttamiseen myöhemmässä vaiheessa, esimerkiksi uusia ominaisuuksia lisättäessä, on matalampi, sillä ajamalla testit uudelleen on helppo varmistua muutosten oikeellisuudesta. Testitapaukset toimivat lisäksi osana ryhmän sisäistä kommunikaatiota, ja niistä käy suoraan ilmi kunkin moduulin haluttu toiminta. Yksikkötestaus pyritään hoitamaan osana itse kehitystyötä, jolloin se samalla auttaa hahmottamaan kunkin moduulin käyttötapauksia. Työkaluna käytetään CppUnitkirjastoa, joka hoitaa testitapausten ajon ja tulosten raportoinnin [1]. Testitapausten kirjoittamiseen on alustavasti varattu noin neljäsosa kaikesta ohjelmointityöstä. Integraatiotestaus Järjestelmän kehitys aloitetaan arkkitehtuurihierarkian korkeimmalta tasolta, siirtyen projektin edetessä vähitellen matalammille tasoille. Alempien tasojen moduulit korvataan alkuvaiheessa tyngillä (stub), jotka toteuttavat vain välttämättömimmän toiminnallisuuden. Menettelyn ansiosta järjestelmästä on aina olemassa toimiva versio esimerkiksi esittelyä ja järjestelmätestausta varten. [2] Integraatiotestaus etenee ohjelmoinnin kanssa käsi kädessä ns. ylhäältä alas - menetelmällä. Mahdolliset testitapaukset toteutetaan tynkämoduuleista käsin pyytämällä ylempiä tasoja suorittamaan tiettyjä toimintoja. Tällöin järjestelmän tärkeimmät osat ovat jatkuvasti välillisen testauksen kohteena, ja niistä saadaan vakavimmat virheet selville jo hyvin aikaisessa vaiheessa. Integraatiotestaukselle sinänsä ei projektissa ole varattu muutamaa erikoistapausta lukuun ottamatta paljonkaan ylimääräisiä resursseja. Tavoitteena on kuitenkin yhdistää uudet moduulit järjestelmään mahdollisimman nopeasti, jatkuva integrointi -menetelmää 27(27)
noudattaen, jolloin tietty osa integraatiotestauksesta tulee hoidettua jo ohjelmointivaiheessa. Jos integrointi ei onnistu, on jossain todennäköisesti virhe. Järjestelmätestaus Järjestelmää testataan luonnollisesti myös kokonaisuutena. Tärkeimpänä menetelmänä käytetään ad-hoc-testausta, jota asiakas sekä kukin ryhmän jäsen harrastaa resurssiensa mukaan. Menetelmässä testaaja asettuu järjestelmän käyttäjän asemaan ja suorittaa vaatimusten mukaisia toimintoja etsien samalla tietoisesti virheitä ja epäkohtia. Tällä tavalla voidaan varmistua siitä, että tuote todella täyttää asiakkaan vaatimukset koskien sekä toiminnallisuutta että käytettävyyttä. Tiettyjen toimintojen ja käyttötapausten testaus voidaan myös automatisoida korvaamalla osa moduuleista riiviöillä (gremlin), jotka tuottavat keinotekoista käyttäjäsyötettä muulle järjestelmälle. Samalla menetelmällä hoidetaan myös kuormitustestaus (stress testing) ja suorituskykytestaus (performance testing). Riiviöiden etuna on, että jokainen testitapaus voidaan määritellä täsmällisesti ja käyttäjäriippumattomasti, jolloin tulokset ovat vertailukelpoisia eri suorituskertojen välillä. Vaiheistus Koska yksikkötestaus ja integraatiotestaus ovat vahvasti sidoksissa varsinaiseen kehitystyöhön, pyritään niiden soveltaminen aloittamaan heti ensimmäisessä implementaatiovaiheessa. Näin myös vältytään huonosta testauksesta johtuvilta ongelmilta myöhemmissä vaiheissa. Käytännössä on havaittu, ettei yksikkötestauksen testitapauksista saada yleensä tarpeeksi kattavia, jos niiden tekeminen aloitetaan vasta jälkikäteen [3]. Järjestelmätestausta ei varsinaisesti voida aloittaa ennen kuin jonkinlainen toimiva kokonaisuus on saatu aikaiseksi. Tämän vuoksi suuremman mittakaavan järjestelmätestaus jätetäänkin kolmanteen implementaatiovaiheeseen, mutta jonkinasteista ad-hoc-testausta sovelletaan jo ainakin toisessa vaiheessa. Viitteet [1] CppUnit Home Page, 25.10.2002 [viitattu 25.10.2002] URL: http://cppunit.sourceforge.net/ [2] Milan Springl, Software Testing, 24.2.1998 [viitattu 25.10.2002] URL: http://sern.cpsc.ucalgary.ca/~springl/seng621/621essay.html [3] Rutherford, Kevin, Retrofitting Unit Tests with JUnit, XP2000-konferenssi 28(28)