COTOOL dokumentaatio Projektisuunnitelma

Transkriptio

1

2 Table of Contents 1 Johdanto Versiohistoria Projektin kuvaus Projektissa käytetyt termit ja lyhenteet Osapuolet ja henkilöstö Asiakas Toimittaja Mentor Tavoitteet ja lopetuskriteerit Asiakkaan tavoitteet Toimittajan tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeytyskriteerit Projektin lopetuskriteerit Resurssit ja budjetointi Henkilöstö Materiaalit Budjetti Työkäytännöt ja työkalut Käytännöt Iteratiivinen kehitys Iteraation suunnitelu Katselmoinnit Pariohjelmointi Evolutiivinen kehitys, yksinkertainen suunnittelu ja refaktorointi Automaattiset testit läpäisevä koodi Reflection Workshop Testaus Priorisointi Käytettävät työkalut Testausalueet ja niiden vastuuhenkilöt Testausmetodit Virheiden raportointi Virheiden luokitus ja priorisointi Testitulosten käyttö Dokumentointi Dokumentit ja vastuut Riskienhallinta Tuntiraportointi Sovelluksen koon raportointi Kommunikaatio Iteraatiodemo Bugien hallinta Versionhallinta Ohjelmointikäytännöt Ohjelmakoodin kommentointi Vertaisryhmätestaus Vaatimusten hallinta Laadunvarmistussuunnitelma Johdanto Projektitason aiheet

3 Projektin tärkeimmät laatutavoitteet Laadun arviointi Iteraatiotason aiheet Ensimmäinen iteraatio Toinen iteraatio Työkalut Palvelimella Työasemissa Standardit Projektin vaiheistus Aikataulu Projektisuunnittelu Toteutus Toteutus 1a ( ) Toteutus 1b ( ) Toteutus 1a ja 1b tehtävät Toteutus Toteutus 2a Toteutus 2b Toteutus 2a ja 2b tehtävät Riskienhallinta ja -loki Viitteet

4 1 (45) 1 Johdanto 1.1 Versiohistoria Versiohistoria Versio Pvm Tekijä Kuvaus Hyväksyjä JI Pohjan luonti, lisätty kappale JI Lisätty kappale JI Päivitetty kappale 1 Lisätty kappaleet 2, 3, 5.1.1, ja Lisätty tehtävä luentoja varten JI Päivitetty kappaleita 1, 2, 3 ja 5 Lisätty kappale JI Päivitetty käsite- ja lyhenneluetteloa, päivitetty osapuolet toimittajan osalta. Siirretty internet-viittaukset kappaleeseen Viitteet. Arvioitu resurssimatriisi (4.1) Laskettu projektin budjetti (4.3) Lisätty kappaleet 5.1.6, 5.1.9, , , ja 5.13 Päivitetty kappale Siirretty riskienhallinta (5.1.4) omaan dokumenttiinsa Korjattu kirjoitusvirheitä JI Lisätty tekstiä dokumentaatio ja versionhallinta kappaleisiin. Korjattu kirjoitusvirheitä. Päivitetty tuntilistat JI Lisätty kappaleet 6.3, 6.4. Päivitetty aikataulua kappaleessa JI Päivitetty kappaleita (tavoitteet ja tehtävät) 6.3 ja 6.4 Ulkoasun muotoilua TH Laadunvarmistussuunnitelma tarkennettu, lisätty dokumentteja kappaleeseen Dokumentit ja vastuut. Kappaleeeseen pieniä muutoksia JI Päivitetty kappaleen 4.1 resurssimatriisi, päivitetty tehtävälista ja palautettavat dokumentit kappaleessa TH Laadunvarmistussuunnitelman päivitys: Uudet kappaleet: Valitut käytännöt, pari ohjelmointi, automaattiset testit läpäisevä koodi,testaus: Priorisointi. Lisätty:HttpUnit käytettyihin työkaluihin. Poistettu: Exploratiivinen testaus yksikkötestauksesta JI Työkäytäntöjen päivitys: Tuntiraportointikäytännöt JI Päivitetty kappaleen 4.1 resurssimatriisi ja päivitetty tehtävälista kappaleessa JI Päivitetty kappaleen 2.2 vastuita ja varahenkilöitä. Lisätty AA:n ja JW:n kuvaukset ja tavoitteet kappaleeseen 3.3. Versiotaulukko jatkuu seuraavalla sivulla Petteri Hyytiäinen

5 2 (45) Versio Pvm Tekijä Kuvaus Hyväksyjä JI Päivitetty Pariohjelmointikappaletta Projektitason valittuihin käytäntöihin. Lisätty valittuihin käytäntöihin evolutiivinen kehitys ja refaktorointi TH Laadunvarmistussuunnitelmassa esiintyviä aikatauluja muutettu JI Yksinkertaistettu 5 kappaleen rakennetta. Siirretty mm. Laadunvarmistussuunnitelman Käytettävät työmenetelmät ja Testaus suoraan kappaleen 5.1 alle. Päivitetty useita työmenetelmitä kappaleessa JI Päivitetty aikataulu kappaleessa 6.1. Päivitetty työkalut työasemissa. Päivitetty viitteisiin/termeihin EMMA ja JUnit. Lisätty laadun arviointiin LOC ja EMMA. Poistettu yksikkötestien taso "huomautettavaa". Lisätty työmenetelmä Reflection Workshop kappaleeseen JI Päivitetty resurssimatriisi ja kumulatiiviset tunnit kappaleessa 4. Päivitetty toteutus 1a ja 1b iteraatioiden tehtävätaulukko kappaleessa TH Laadunvarmistussuunnitelmaan lisätty I2:n tiedot. Bugien raportointiin muutoksia JI n 6.4 Toteutus 2 tarkennettu TH Laadunvarmistussuunnitelman I2:sta tarkennettu JI Päivitetty työmenetelmiä ja tarkennettu aikataulua JI Korjattu aikataulu JI Resurssimatriisi, kumulatiiviset tunnit ja tehtävien toteutuminen (kappaleet 4.1, 6.4.3) JI Toimittajan organisaatiokuvan päivitys, vastuualueiden päivitys ajantasalla (kappale 2). Päivitetty dokumenttivastuut (kappale 5.1.9) Oikolukua ja sivutusta Petri Saloma Projektin kuvaus Tavoitteena on luoda visuaalisesti vakuuttava käyttöliittymä kiinteistön ilmastoon liittyvien lukemien helppolukuiseen esittämiseen. Haasteina tehtävässä on jouhevan sovelluksen toteuttaminen www-ympäristöön, jonka lähtöaineistona on niin CAD pohjapiirustusta kuin tietokannasta haettavaa antureiden antamaa numeerista dataa. Myöskin open source komponenttien, sekä avoimien standardien käyttäminen projektin toteutuksessa tuo lisäarvoa asiakkaalle. Nykyisin on helppo myydä sekä ylläpitää järjestelmää jos se pohjautuu avoimiin standardeihin.

6 3 (45) 1.3 Projektissa käytetyt termit ja lyhenteet Ainakin toistaiseksi projektin termit ja lyhenteet on listattu alla oleviin taulukoihin. Helpottaaksemme terminologian käyttöä saatamme myöhemmässä vaiheessa eriyttää nämä omaan dokumenttiinsa. Taulukko 1 Dokumentaatiossa käytetyt termit Asiakas, tilaaja Tuotteen tilaaja, eli Jaakko Pöyry Infra AutoCAD 2D/3D suunnitteluohjelmisto. /3/ Bugzilla Kurssin tarjoama työkalu bugien seurantaan /11/. EMMA Sovelluksen ajon rivikattavuuden mittaustyökalu. /19/. JUnit Yksikkötestauskirjasto Java-ohjelmointikielelle. /18/. Loppukäyttäjä Valmiin tuotteen peruskäyttäjä, ts. käyttäjä joka seuraa kiinteistön ilmastointia. StatCVS Lähdekoodista statistiikkaa tuottava sovellus /12/. Switch Toimittaja Tuote, järjestelmä Ylläpitäjä Verkkokytkin, jonka kautta esim. lähiverkkoon kytketään useita koneita. Data Sailors, eli projektiryhmä. COTOOL - Room Air Conditions Reporting Tool for buildings. Projektin lopuksi asiakkaalle toimitettava ohjelmistokokonaisuus. Valmiin tuotteen ylläpitäjä, ts. käyttäjä joka syöttää kiinteistön ilmastoinnin seurannan vaatimat lähdetiedot. Taulukko 2 Dokumentaatiossa käytetyt lyhenteet AA Nimikirjaimet, Aleksi Autere COTOOL Room Air Conditions Reporting Tool for buildings. Toimitettava tuote. /1/ CVS DWG Concurrent Versions System. Versionhallintajärjestelmä, jossa säilytetään projektin dokumentaatio ja lähdekoodit. /2/ AutoCAD Drawing Database. AutoCAD ohjelmiston tallennusmuoto. DXF Drawing Interchange Format /4/. HTML HyperText Markup Language /5/. JI JP JW KR ML PDF PS Nimikirjaimet, Jukka Ignatius Jaakko Pöyry Infra Nimikirjaimet, Jan Welin Nimikirjaimet, Kimmo Rouhiainen Nimikirjaimet, Matti Liljavirta Portable Document Format. Adoben luoma, nykyisin de facto standardi sivutetun median levittämiseen. Nimikirjaimet, Pekka Silvekoski SVG Scalable Vector Graphics /6/ TH Nimikirjaimet, Turo Honkaniemi Vex A Visual Editor for XML /7/. XML Extensible Markup Language /8/. XSL/XSL-FO Extensible Stylesheet Language /9/. XSLT XSL Muunnokset /10/.

7 4 (45) 2 Osapuolet ja henkilöstö Projektiin liittyvien osapuolien ja henkilöstön suhteet on esitetty alla esitetyssä organisaatiokaaviossa. Projektin onnistumista varmasti helpottaa se, että asiakkaalla on jo useamman vuoden kokemus TKK:n ohjelmistokehitysprojekteihin osallistumisista. Asiakkaan ja toimittajan välinen kommunikaatio pyritään keskittämään lähinnä asiakasta helpottaakseen projektipäällikön kautta. Kuitenkin kaikille toimittajan henkilöille nimetään varahenkilöt heti I1 vaiheen alussa mahdollisten sairaustapausten tai muiden odottamattomien poissaolojen vuoksi. Projektin organisaatio

8 5 (45) 2.1 Asiakas Projektin asiakas on Jaakko Pöyry Infra. Asiakkaan yhteyshenkilönä toimii Petteri Hyytiäinen. Teknisenä asiantuntijana asiakkaan puolesta toimii Petri Saloma. Alla olevaan taulukkoon on listattu asiakkaan yhteystiedot Asiakkaan yhteystiedot Rooli Asiakas Nimi Yhteystiedot Hyytiäinen, Petteri petteri.hyytiainen#poyry.fi Rooli Nimi Yhteystiedot Jaakko Pöyry Infra JP-Talotekniikka, Rakennusautomaatio Tekniikantie 4D (PL2), Espoo Tekninen asiantuntija Saloma, Petri petri.saloma#poyry.fi Jaakko Pöyry Infra JP-Talotekniikka, Rakennusautomaatio Tekniikantie 4D (PL2), Espoo

9 6 (45) 2.2 Toimittaja Projektin toimittajana toimii kurssin projektiryhmä nimeltä Data Sailors. Toimittajan yhteystiedot ja vastuualueet Rooli Testaaja Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Autere, Aleksi (AA) Silvekoski, Pekka (PS) aautere#gmail.com Testauskäytönnöt yhdessä TH:n kanssa. Yksikkötesteihin liittyvä koulutus. Testaus. Myöhemmin valittavien sovelluskomponenttien toteuttaminen Aleksi on neljännen vuoden tietotekniikan opiskelija, ja lukee pääaineenaan ohjelmistoliiketuotantoa. Aleksilla on kokemusta yksittäisistä pienistä ohjelmistoprojekteista liittyen koulukursseihin. Laatupäällikkö Honkaniemi, Turo (TH) Ignatius, Jukka thonkani#cc.hut.fi Laatupäällikkö vastaa toiminnallisesta ja ei-toiminnallisesta määrittelystä, sekä tuotteen testauksesta läpi projektin keston. Turo opiskelee kuudetta vuotta tietotekniikan osastolla pääaineenaan ohjelmistotuotanto- ja liiketoiminta. Sivuaineena hän lukee yritysstrategiaa ja kansainvälistä liiketoimintaa. Koulukurssien lisäksi Turolla on yli kahden vuoden työkokemus ohjelmistontuotannosta, josta 9 kuukautta on suoritettu ulkomailla. Aikaisemmisssa projekteissa tutustunut muun muassa VBA:han, Java SE:hen, tietokantoihin ja käyttöliittymien suunnitteluun. Projektipäällikkö Ignatius, Jukka (JI) Honkaniemi, Turo jukka.ignatius#hut.fi Projektipäällikkö vastaa tehtävien jakamisesta ryhmän sisällä, yhteydenpidosta asiakkaan, toimittajan ja mentorin välillä sekä vastaa viime kädessä koko projektista. Jukka on n vuosikurssin laivateekkari, joka lukee sivuaineenaan ohjelmistotuotannon- ja liiketoiminnan kokonaisuutta. Opiskelun ohella hän on työskennellyt IT-alalla saaden monen vuoden työkokemusta niin webdesignerin, ohjelmoijan kuin ohjelmistosuunnittelijan roolista. Työskentelee nykyisin Napalla ja diplomityö on seuraavan kesän tavoitteissa.

10 7 (45) Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Arkkitehti (PP,I1), Kehittäjä (I2) Liljavirta, Matti (ML) Rouhiainen, Kimmo (KR) Welin, Jan (JW) Aleksi Autere (AA) matti.liljavirta#hut.fi Arkkitehti suunnittelee tuotteen arkkitehtuurin, jakaa sen toiminnallisiin osiin, toteuttaa tarvittavat kaaviot, ja organisoi kehittäjien mahdollisesti tarvitseman koulutuksen. ML toimi arkkitehdin roolissa PP ja I1 iteraation.i2 vaiheeseen tehtiin roolivaihdos, jolloin ML ja KR vaihtoivat tehtäviä keskenään. Kahdeksannen vuoden opiskelija tietotekniikan osastolla pääaineena tietoliikenneohjelmistot ja sivuaineena yritysturvallisuus. Pää- ja sivuaineopintojen kautta tutut aihekokonaisuudet ovat tietoturvasta ja turvallisuudesta yleensäkin. Opiskelun ohella työkokemusta on karttunut monen vuoden ajalta TKK:n atk-keskuksen palveluksessa erilaisissa ylläpidon tehtävissä. Ohjelmoija (I1), Arkkitehti (I2) Rouhiainen, Kimmo (KR) Liljavirta, Matti (ML) krouhiai#cc.hut.fi Alustavasti KR:n vastuualueina olivat SVG/DXF-formaatit ja niiden väliset konversiot. I2 vaiheeseen tehtiin roolivaihdos, jolloin ML ja KR vaihtoivat tehtäviä keskenään. Kimmo on kuudennen vuoden tietoliikennetekniikan opiskelija. Pääaineena hänellä on tietoliikenneohjelmistot ja sivuaineena vuorovaikutteinen digitaalinen media. Työkokemusta hänelle on kertynyt jonkin verran mm. tietokanta- ja ohjelmistosuunnittelusta, projektinhallinnasta, ohjelmistotestauksesta, sekä ohjelmoinnista PHP:llä. Koulun kurssien kautta Kimmolle ovat tulleet tutuksi myös mm: Java, C ja HTML. Käyttöliittymäsuunnittelija Silvekoski, Pekka (PS) Welin, Jan (JW) mpsilvek#cc.hut.fi Käyttöliittymän suunnittelu ja HTML/DHTML toteutus. Myöhemmin valittavien sovelluskomponenttien toteuttaminen. Seitsemännen vuoden opiskelija tietotekniikan ostastolla TKK:lla. Pääine tietoliikenneohjelmistot ja sivuaine sisällöntuotanto. Kokemusta koulun kursseilta käyttöliittymien suunnittelusta ja testauksesta, niin teorian, kuin käytännön puoleltakin. Pääaineen puolesta osaamista tietoturvasta ja salausmenetelmistä, mikäli niille sattuu olemaan projektissa tarvetta.

11 8 (45) Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Ohjelmoija Welin, Jan (JW) Kimmo Rouhiainen jwelin#cc.hut.fi Käyttöliittymän skriptaus. Myöhemmin valittavien sovelluskomponenttien toteuttaminen.. Opiskelen kuudetta vuotta tietotekniikan osastolla. Pääaineenani on tietoliikenneohjelmistot ja sivuaineena vuorovaikutteinen digitaalinen media. Ominta alaa ovat tietoliikennesovellukset pääaineen johdosta, mutta töitä teen tällä hetkellä tietokantaraportoinnin parissa. 2.3 Mentor Projektin mentorina toimii Seppo Sahi SoberIT:ltä. Asiakkaan yhteystiedot Rooli Mentor Nimi Yhteystiedot Sahi, Seppo ssahi#soberit.hut.fi

12 9 (45) 3 Tavoitteet ja lopetuskriteerit 3.1 Asiakkaan tavoitteet Asiakkaan tavoitteena on saada olemassa olevaan Rauinfo www-palveluun lisäsovellus, jolla loppukäyttäjä pystyy seuraamaan kiinteistönsä/kiinteistöjensä ilmastoinnin tilaa. Asiakkaan tavoitteena on saada tärkeää markkinointilisää tuottava osa jo toimivaan www-palveluun, ja siksi tuotteen visuaalinen näyttävyys sekä helppokäyttöisyys ovat erittäin merkittävässä roolissa. Tuotteen tulee toimia vaatimusmäärittelyn mukaisesti, mikä on tärkeä tuotetta kuvaava dokumentti ja käytännössä sopimus asiakkaan ja toimittajan välillä siitä, minkälaista tuotetta ollaan toteuttamassa. Vaatimusmäärittelyn lisäksi asiakas on listannut kvalitatiivisia ja kvantitatiivisia tavoitteita seuraavaan taulukkoon. Asiakkaan tavoitteet Nro Tavoite Tarkistuskriteeri 1. Tuotteen jatkokehitys on mahdollista Asiakas arvio jatkokehitysvaiheessa. Lisäksi asiakas arvio, onko vaatimusmäärittelyssä otettu huomioon tuotteen laajentaminen. 2. Toteutettu järjestelmä on käytettävyydeltään hyvä, sekä visuaalisesti vakuuttava 3. Sovitut toiminnot on toteutettava laadukkaasti ja järjestelmän tulee olla luotettava 4. Järjestelmän arkkitehtuuri sopii olemassa olevaan järjestelmään. 5. Onnistunut yhteistyö asiakkaan ja toimittajan välillä Asiakas arvioi käyttöliittymätestauksen perusteella. Asiakas arvioi myös valmiin tuotteen ulkoasun. Asiakas arvioi luovutusvaiheessa työn laadun, sekä arvioi testitapausten ja rinnakkaisryhmävertailun tulosten perusteella luotettavuuden. Asiakas arvioi, onko tämä otettu huomioon vaatimusmäärittelyssä. Asiakas ja toimittaja arvioivat projektin lopussa. 6. Toteutus on hyvin dokumentoitu Asiakas arvostelee toimitetun dokumentaation. 7. Tuotettu järjestelmä on riittävän suorituskykyinen. Asiakas arvioi toimittajan suorittamien testitapausten, rinnakkaisryhmävertailun tulosten sekä omien testiensä perusteella. 8. Projekti saadaan toteutettua aikataulussa. Täyttyy kun projekti pysyy kurssin aikataulussa. 9. Tuote on skaalautuva. Asiakkaan suorittamat rasitustestit. 10. Palkitseva projekti molemmin puolin Arvioidaan projektin aikana opittu ja koettu. Asiakas saa toivomansa tuotteen, ja toimittaja hyvän arvosanan sekä saunaillan.

13 10 (45) 3.2 Toimittajan tavoitteet Projektiryhmän keskeisenä tavoitteena on syventää ohjelmistokehitysprojektin tuntemustaan. Osalla ryhmän jäsenistä on jo kokemusta laajoistakin ohjelmistoprojekteista, mutta toisille tämä on ensimmäinen kerta kun näin laaja projekti vedetään kokonaisuudessaan läpi. Koko projektiryhmän yhteiset tavoitteet on listattu seuraavassa taulukossa. Toimittajan tavoitteet Nro Tavoite Tarkistuskriteeri 1. Projektiryhmä kykenee tuottamaan asiakkalle lisäarvoa tuottavan sovelluksen vaatimusmäärittelyn mukaisesti. Asiakas arvioi työn tuloksen projektin päätteeksi 2. Uusien tekniikoiden/käytäntöjen oppiminen Valmiissa tuotteessa käytettyjen tekniikoiden henkilökohtainen arvioiminen kurssin päätteeksi. 3. Opitaan työskentelemään ryhmässä Henkilökohtainen arvio ryhmätyöskentelyn laadusta iteraatiokierroksen päätteeksi 4. Kiitettävä kurssiarvostelu Kurssiarvostelu 5. Laadukas ja tuottava työskentely asiakkaan kanssa Arvioidaan yhdessä asiakkaan kanssa projektin päätteeksi. 3.3 Henkilökohtaiset oppimistavoitteet Henkilökohtaiset oppimistavoitteet on kerätty projektiryhmän jäseniltä seuraavaan taulukkoon. Vaikka henkilökohtaisille oppimistavoitteille ei ollut tarpeen määrittää todentamismenetelmiä, niin varmasti projektin päätöspalaverissa tulee esille mitä kukin on asiasta oppinut. Henkilökohtaiset tavoitteet Jäsen Autere, Aleksi Honkaniemi, Turo Ignatius, Jukka Liljavirta, Matti Henkilökohtainen oppimistavoite Mukava olisi oppia kaikkea uutta. Ryhmätyötaitojen hiominen lienee tälläisessa projektissa kaikkein arvokkainta, uusia tekniikkoja kun voi opiskella pelkän koneen äärellä. Toki uusia tekniikoitakin on mukava oppia, lähinnä testaukseen liittyen. Kurssi tarjoaa hyvät puitteet olla mukana ohjelmistonkehitysprojektissa alusta loppuun. Aikasemmin olen ollut mukana vain projektin keskivaiheessa tai lopussa. En ole aikaisemmin ollut mukana projektin johtamisessa, joten toivon saavani hyvää kokemusta myös siihen liittyen. Asiakas rajapinnassa toiminen tarjoaa hyödyllistä kokemusta ja uutta minulle on myös vaatimusmäärittelyjen tekeminen käytännön projektissa. Edellä mainittujen lisäksi toivon oppivani jotain minulle ennestään tuntemattomista teknologioista ja niiden käytöstä. Vaikka itselleni on kertynyt kokemusta ohjelmistoprojekteista työelämästä, niin haluaisin saada käytännön opeilleni hieman teoreettista pohjaa. Usein myös kantapään kautta opittu ei ole se oikea tapa, vaan toivoisin löytäväni lisätietoutta ja korjausta mahdollisesti "väärin" oppimaani. Tavoitteena on myöskin tutustuminen uusin teknologioihin (esimerkiksi SVG). Koska aiempi kokemukseni projektityökentelystä rajoittuu lähinnä joko teknisenä asiantuntijana toimimiseen tai puhtaasti tekniikkaan liittyvistä projekteista. Kurssin puitteissa pääsee tutustumaan ohjelmistonkehistysprojektin kaikkiin vaiheisiin ja osa-alueisiin syvällisemmin ja oppii hyviä työskentelytapoja, joita voi hyödyntää muunkinlaisissa projekteissa ja työelämässä yleensäkin. Projektin johtamisespuolesta saatavat käytännön kokemukset toivottavasti antavat myöskin uusia näkökulmia asioihin. Lisäksi tämän projektin puitteissa on tavoitteissa uusiin tai ennalta vain päällisin puolin tuttuihin tekniikoihin syvällisempi tutustuminen.

14 11 (45) Rouhiainen, Kimmo Silvekoski, Pekka Welin, Jan Tavoitteenani on oppia järjestelmällistä ohjelmistokehitystä, oppia entistä parempi ja selkeämpi ohjelmointitapa, sekä saada kokemusta ohjelmointityökaluista ja kielistä. Myös kunnon kokemuksen saaminen isommassa ryhmässä työskentelystä olisi tärkeää. Saada hyvä yleiskuva ohjelmistoprojektista ja sen eri vaiheista. Päästä mukaan suunnitteleemaan ja testaamaan käyttöliittymää, että näkee miten teoriassa opitut asiat taipuvat käytäntöön. Lisäksi oppia tiimityöskentelystä ja oikeanlaisesta dokumentoinnista projektissa. Myös oppia projektissa käytettävä SVG tekniikka sopivalle tasolle. Tavoitteena on oppia käytännön ohjelmistoprojektin kulkua. Tähän mennessä lähes kaikki ohjelmointitehtävät koulussa ovat olleet pieniä yksin tai kaksin tehtyjä harjoitustöitä, ilman iteraatioita. Varsinaista työkokemustakaan en omaa ohjelmistoprojektien parista. 3.4 Projektin keskeytyskriteerit Projekti voidaan keskeyttää vain toimittajan ja asiakkaan välisellä sopimuksella. Käytännössä projekti keskeytetään vasta todella vakavan tapahtuman johdosta. Tällaisia mahdollisia keskeytyskriteerejä ovat: - Toimittaja on käyttänyt 80% resurssoiduista tunneista, eikä mitään toimivaa ole saatu aikaiseksi - Kaksi tai useampi toimittajan jäsenistä jättää kurssin kesken. - Force Major: Esimerkiksi tulipalo tuhoaa toimittajan työn. 3.5 Projektin lopetuskriteerit Projekti päättyy kurssin aikataulun mukaan , jolloin kaikki sovittu materiaali toimitetaan asiakkaalle. Samassa yhteydessä palautetaan myös kulkuluvat, avaimet, käyttöön saadut työvälineet ja muut asiakkaan omaisuutta olevat esineet/asiat. Aikaisempia lopetuskriteerejä ei ole tarpeen määritellä, koska asiakkaalla on varmasti tuotteeseen liittyviä jatkokehitystoiveita, jos resursseja jää ennen kurssin päättymistä käyttämättä. Viimeisen palautuspäivämäärän jälkeen järjestelmää vielä demotaan projektikatselmuksessa

15 12 (45) 4 Resurssit ja budjetointi 4.1 Henkilöstö Toimittajan jäsenten suunnitellut resurssit projektin eri vaiheissa on listattu seuraavaan taulukkoon. Ainoastaan Jukka Ignatius'ella, Turo Honkaniemellä sekä Matti Liljavirralla on taas varattu tunteja jo PP vaiheessa. Ensimmäinen toteutus iteraatio on jaettu kahteen ali-iteraatioon. Pidempiä poissaoloja ei ole tässä vaiheessa tiedossa. Myöskin ainakin osa projektiryhmästä voisi olla halukas työskentelemään lähemmäs joulua ja aloittamaan nopeammin uudenvuoden jälkeen. Taulukon "Yht Suun."-sarakkeen muodostaa kirjoitushetkeen asti toteutuneet tunnit + tulevaisuuden suunnitellut tunnit. Tämä summa pyrittiin pitämään mahdollisimman pitkälle 170h/hlö (170h + 20h SEPAsta). Tunnit kuitenkin ylittyivät odottamattomien haasteiden takia, mutta eivät merkittävästi. Toteutusiteraatioiden tuntiraportoinnit löytyvät kokonaisuudessaan Excel-tiedostoina dokumentaation liitetiedostoista. Resurssimatriisi PP Toteutus1a Toteutus1b Toteutus2a Toteutus2b Yht. Henkilö Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. AA ,3 26,2 65,3 38,1 71,2 91,9 43,8 41, ,3 JI , ,5 43,5 23,6 27,0 34,4 40, JW ,3 23,5 70,5 20,5 54,7 45,5 71,3 102, ,5 KR , ,2 80,5 37, ,5 ML , ,5 22,7 4,3 77,3 89, ,8 PS ,8 38, ,5 37,2 65,8 38, ,8 TH 49 51, ,5 22,5 11,5 27,8 28,5 48,2 45, ,5 Yht ,5 329,9 236,2 362,8 196,6 313,4 343,5 351,1 417, ,1

16 13 (45) Alla olevassa kuvaajassa näkyy kirjoitushetkeen asti suunnitellut ja toteutuneet kumulatiiviset tunnit. Lisäksi kaavioon on arvioitu palautuksen sekä iteraatiodemon vaatimat tunnit kaikille toimittajan jäsenille. Ensimmäisesssä toteutusiteraatioissa oli vaikeuksia käyttää kaikkia resursoituja tunteja, mutta toisessa tehtiin jo ylitöitä tavoitteiden saavuttamiseksi. Kumulatiiviset tunnit 4.2 Materiaalit Toimittaja saa asiakkaalta käyttöön työhuoneen, yhteensä neljä pöytäkonetta ja yhden kannettavan tarvittavine ohjelmistoineen. Asiakas mahdollistaa toimittajan pääsyyn työtiloihin ympäri vuorokauden (kulkuluvat ja kolme kappaletta avaimia). Tarkemmat tiedot työvälineistä löytyy kappaleesta 5.3 Työkalut. Asiakkaan verkkoon saa liittää myös toimittajan omia kannettavia, kunhan niissä on ajantasalla oleva virustorjuntaohjelmisto sekä palomuuri. Tämän lisäksi asiakkaan verkkoon kytkeydytään ainoastaan palomuurina toimivan switchin läpi (Asiakas toimittaa/asentaa).

17 14 (45) 4.3 Budjetti Tämän kappaleen on tarkoitus antaa suuntaa-antava arvio "todellisen maailman" kustannuksista. Kustannukset perustuvat seuraavaan jaotteluun: - Konsultointi (projektinhallinta/määrittely/suunnittelu): 150 /h - Ohjelmointi/dokumentointi: 85 /h - Koulutus: 100 /h + materiaali erikseen sovitusti - Matkakustannukset: Sisältyvät tuntihintoihin Koska tarkkaa jakautumaa konsultoinnin, ohjelmoinnin sekä koulutuksen kesken ei osata tässä vaiheessa sanoa, jakauman on arvioitu olevan 40%, 50% ja 10% vastaavasti. Koska asiakkaalla on jo tarvittava tuotantoympäristö, tämän hankinta ei aiheuta lisäkustannuksia. Asiakkaan toimittajan käyttöön hankkimia tietokoneita ei myöskään lasketa projektin kustannuksiin, koska ne uusiokäytetään projektin päättyessä JP:n muihin tarpeisiin. Kokonaissummassa on otettu huomioon 1000 mahdollisesti tarvittavina lisensseinä. Koulutuksessa mahdollisesti tarvittava materiaali laskutetaan erikseen. Kustannusarvio Tyyppi % /yks yks Konsultointi Ohjelmointi Koulutus Lisenssit Yht Jos projektia verrataan "todelliseen maailmaan", voidaan todeta ainakin se, että kurssin vaatimuksien takia näinkin pienelle projektille sovelletaan melko raskasta frameworkia, joka tuottaa suuren määrän dokumentaatiota. Mutta tarkoituksenahan on oppia soveltamaan opittua käytönnössä.

18 15 (45) 5 Työkäytännöt ja työkalut 5.1 Käytännöt t työkäytännöt-kappaletta täydennetään projektin aikana sitä mukaan, kun käytäntöjä suunnitellaan ja otetaan käyttöön. Kaikki kirjoitushetkellä hetkellä sovitut ja käytetyt menetelmät on pyritty kuvamaan tähän kappaleeseen Iteratiivinen kehitys Projektissa sovelletaan kurssin vaatimaa iteratiivista kehitystapaa /16/. COTOOL-projektiin iteratiivinen kehitystapa sopii hyvin, koska kuten vaatimusmäärittelystä nähdään, tuote on toteutettavissa toivottu osuus kerrallaan. Myöskin asiakkaalla on ajan riittäessä varmasti jatkokehitystoiveita Iteraation suunnitelu Ennen iteraation alkua tehdään iteraatiosuunnittelu, jossa yhdessä projektiryhmän (PP-vaihe) ja asiakkaan (I1 ja I2 vaiheet) kanssa määritellään iteraation tavoitteet ja sovitaan palautettavista dokumenteista ja sovelluksen osista. Käytännössä tämän takia jokainen iteraatio voidaan nähdä omana projektinaan, koska ne täyttävät projektin kriteerit. Niillä on määrättivissä oleva alku, tavoitteet ja sovitut lopetuskriteerit. Kun abstraktimmat tavoitteet on määrätty, ne jaetaan pienempiin osatehtäviin, joiden avulla iteraation resursointi pystytään suunnittelemaan. Iteraation ensimmäisessä vaiheessa aloitetaan toteutettavien ominaisuuksien suunnittelu. Toteutettavia ohjelmiston osasia, jotka jaetaan käyttötapauksiin, varten luodaan testitapaukset, joiden jatketaan läpi projektin. Jos iteraationsuunnittelun aikana arvioidut tuntiarviot havaitaan liian pieniksi, sovitaan palaveri asiakkaan kanssa, jossa mahdollisesti tiputetaan tavoitteita pois, tai ryhdytään muihin toimenpiteisiin puuttuvien resurssien hankkimiseksi.

19 16 (45) Katselmoinnit Dokumenttien katselmointit Tekijän lisäksi vähintään yksi projektiin kuuluva henkilö tulee aina tarkastamaan dokumentin ennen sen palautusta. Lisäksi projektiryhmä tulee oman harkintansa mukaan varmistamaan asiakkaalta palautettavien dokumenttien oikeellisuuden ja hyväksynnän. Koodikatselmointit Asiakkaan tekninen avustaja ja ML tulevat suorittamaan projektin kuluessa koodikatselmointia. Täten he varmistavat, ettei koodissa ole oleellisia virheitä. ML huolehtii siitä, että koodin on tehty valitun ohjelmointikäytännön mukaisesti. Tämän lisäksi kehittäjät voivat keskenään sopia toistensa koodin tarkastamisesta Pariohjelmointi Projektissa tullaan myös käyttämään XP metodologiasta tuttua pariohjelmointia. Tällöin kaksi kehittäjää istuu saman koneen ääressä tuotamassa koodia toisen ollessa näppäimistön äärellä ja toisen toimiessa navigaattorina. Kehittäjät sopivat keskenään parien muodostamisesta. Pareja tulee myös vaihtaa jotta saamme tietouden siirtymään kaikkien kehittäjien välillä. Yksinkertaisissa operaatioissa kuten refaktoroinnissa pariohjelmointi ei ole välttämätön käytäntö. Kehittäjien pitää itsekriittisesti arvioida nämä "helpot" tehtävät Evolutiivinen kehitys, yksinkertainen suunnittelu ja refaktorointi Toinen XP:n menetelmä, jota projektissa osittain sovelletaan on yksinkertaisen suunnittelun ja refaktoroinnin menetelmä, jossa pyritään yksinkertaisella suunnittelulla päästä tehtävän vaatimiin tavoitteisiin. Myöhemmässä vaiheessa refaktoroinnilla mahdollistetaan uusia ominaisuuksia tai yksinkertaisimmillaan vain selkiytettään lähdekoodia. Tämän menetelmän käyttöönottoon rohkaisi arkkitehtuurin suunnittelun alkuvaiheen tuska, joka johti siihen, että emme päässeet tuottamaan ohjelmistokoodia riittävän aikaisin. Nyt evolutiivisella kehityksellä pystymme jakamaan arkkitehtuurisia päätöksiä koko ryhmän tehtäviksi, jolloin epävarmuustekijä poistuu tai ainakin pienenee Automaattiset testit läpäisevä koodi Tuotettavan koodin laadukkuutta pyritään projektissa parantamaan siten, että ainoastaan automaattiset yksikkötestit läpäisevä koodi päivitetään CVS:ään. Vaikka kyseessä on loppujen lopuksi Servlet, jonka yksikkötestaaminen on hankalaa (kts. Käytettävät työkalut) niin arkkitehtuuri tullaan suunnittelmaan siten, että Servlet-luokkaan/luokkiin ei juuri tehdä logiikkaa Reflection Workshop Halusimme kehittää toimintaamme projektiryhmänä sekä kerätä jollain tavalla palautetta käytettävistä työmenetelmistä. Metodin käyttöönottamiseksi (esimerkiksi pariohjelmointi, evolutiivinen kehitys) ei riitä pelkästään metodin valitseminen, sillä jokainen ihminen, projektiryhmä ja projekti on erilainen. Menetelmiä pitäisi siis pystyä muokkaamaan juuri omaan projektiin soveltuvaksi, mutta ongelmaksi muodostuu miten tehdä tämä tuhlaamatta siihen tarpeettoman paljon resursseja. /20/ Yksi tapa kerätä palautetta on pitää iteraation päätteeksi Reflection Workshop, jossa pyritään yksinkertaisesti keräämään kokemuksiä käytetyistä menetelmistä kolmeen kategoriaan: Hyvät, kokeilun arvoiset ja ongelmalliset. Ensin

20 17 (45) keskustellaan menetelmistä, jotka ovat toimineet hyvin, ja jotka varmasti halutaan mukaan seuraavaan iteraation. Samalla mietitään mitä uusia menetelmiä voisimme kokeilla. Keskustelun lomassa esille tulevat ongelmat kirjataan myös ylös. Päätimme tämän vuoksi pitää kaksi Reflection workshoppia, yhden kummankin toteutusiteraation päätteeksi Testaus Priorisointi Projektissa tullaan testaamaan tuotettava COTOOLin koodi, käyttöliittymä sekä sen toiminta integroituna olemassa olevaan järjestelmää. Järjestelmän aikasemmin kehitettyjen osien oletetaan toimivan oikein eikä niitä tulla testaamaan. Koska pontentiaalisten testattavien asioiden määrä on valtava ja käytössä hyvin rajalliset resurssit, täytyy projektissa suorittaa priorisointia. Tämä tapahtuu siten, että ennalta suunniteltuihin integraatio- ja järjestelmätesteihin merkitään prioriteetti. Testitapauksen prioriteetti määräytyy hyvin pitkälti sen mukaan, kuinka tärkeäksi asiakas on kokenut järjestelmän ominaisuuden, johon testitapaus liittyy Käytettävät työkalut Eclipseen hyvin integroituvaa JUnittia tullaan käyttämään automaattisten yksikkötestien tekemiseen. JUnittiin perustuvaa HttpUnit on hyödyllinen lisä automaattisten testiscriptien luontiin webbi puolen testausta varten. HttpUnitin mukana tulevaa ServletUnittia voidaan käyttää Servlettien testauksessa. Jokaisen kehittäjän vastuulla on tutustua edellä mainittuihin ohjelmiin ja käyttää niitä projektissa Testausalueet ja niiden vastuuhenkilöt Testausalueet Testausalue Testausmetodi Vastuuhenkilö Arkkitehtuuri Katselmointi JI,KR Rajapinnat Katselmointi JI,KR Moduulit Automaatiset testitapaukset Kehittäjät Koodin luettavuus Verrataan ohjelmointikäytäntöihin ML Moduulien yhteensopivuus Järjestelmän toiminta ja yhteensopivuus Automaattiset testitapaukset,exploratiivinen testaus, Ennalta suunnitellut integraatiotestit Ennalta suunnitellut järjestelmätestit, Exploratiivinen testaus Käytettävyys Käytettävyystestit TH,PS Ohjelman toimintojen oikeellisuus Katselmointi AA TH Asiakas Testausmetodit Smoketestaus Smoketestauksen tavoitteena on varmistaa, että järjestelmän kriittisimmät toiminnallisuudet toimivat pinnallisesti tarkastettuna. Smoketestaus toimii toisin sanoen porttina syvällisemmälle järjestelmätestaukselle. Smoketestausta tullaan suorittamaan aina,kun ollaan tehty järjestelmään suurempia muutoksia ja aina ennen järjestelmä-, käytettävvyys-, vertaisryhmätestausta.

21 18 (45) Exploratiivista testaus (White box) Exploratiivisessa testauksessa testataan järjestelmää ilman ennalta suunniteltuja ja automatisoituja testitapauksia käytten. AA ja TH tulevat käyttämään tätä menetelmää integraatio- ja järjestelmätestauksessa. Automaattiset yksikkötestit (White box) Projektissa tullaan käyttämään JUnitia automaattiseen moduulitestaukseen. Kehittäjät aloittavat testitapausten tekemisen, kun varsinaisten luokkien kehittäminen alkaa. Yksikkötestien kattavuutta pyritään arvioimaan EMMA-työkalulla /19/. Ennalta suunnitellut integraatiotestit (White box) Kehitystyön aikana kehittäjät tulevat käyttämään hyväkseen testauksessa AA:n tekemiä ennalta suunniteltuja integraatiotestejä. Kunkin iteraation loppupuolella AA suorittaa lopulliset integraatiotestit. Ennaltasuunnitellut järjestelmätestit (Black box) Molempien iteraatioiden aikana TH tulee tekemään järjestelmälle testitapauksia, jotka hän suorittaa pääasiassa ennen demotilaisuuksia. Käytettävyystestaus (Black box) Kun projektissa ollaan päästy siihen vaiheeseen, että ollaan saatu luotua loppukäyttäjän käyttöliittymästä toimiva versio suoritetaan JP Infran tiloissa SEPA:n perustuva käytettävyystestaus. Tällöin järjestetään testitilanne, jossa testihenkilö (JP Infran ei- tekninen työntekijä) suorittaa etukäteen annettuja tehtäviä testikäyttöliittymällä. Testiryhmä pyrkii tällöin arvioimaan ongelmakohtia ja tiedustelemaan parannusehdotuksia testihenkilöiltä. Tarkemmat tiedot käytettävyystestauksesta tullaan esittämään SEPA dokumentissa, joka tuotetaan viikoilla Käytettävyystestaus SEPAn tuottamisesta ja testitilanteen järjestelyistä vastaa TH ja PS. Vertaisryhmätestaus (Black box) Projektiin kuuluu myös osana vertaisryhmätestaus, jossa toinen projektiryhmä testaa järjestelmää annettujen chartereiden pohjalta. Kurssi tarjoaa yhden charterin ja projektiryhmä, jonka järjestelmää testataan, tuottaa toisen. Vertaisryhmätestaus on tarkoitus suorittaa toisen iteraation aikana, jolloin järjestelmä luovutetaan ja vertaisryhmä palauttaa testiraportin. Projektiryhmän tulee mielellään suunnitella charterit ja sopia vertaisryhmätestauksesta jo ennen toista iteraatiota. Yhteensopivuustestaus Eri testauksen vaiheessa tullaan huolehtimaan siitä, että työkalu toimii vanhan järjestelmän ja IE SVG plugin yhdistelmällä. Lisäksi jos aikaa jää, järjestelmää voidaan testata Firefoxin kanssa Virheiden raportointi Nopeasti korjattavat virheet kehittäjä voi korjata saman tien eikä niitä tarvitse merkitä mihinkään. Myöhemmin korjattavat virheet merkataan tarralapulla seinälle. Virheet tullaan korjataan niiiden prioriteettien mukaan. Projektin päättyessä korjaamatta jääneet bugit dokumentoidaan Virheiden luokitus ja priorisointi Virheiden raportoinnissa tullaan käyttämään seuraavia luokituksia. Testauksen laajuus: - Ei tarkastettu - Alustava - Testattu

22 19 (45) Automaattinen testaus (JUnit): - Läpäisty - Virhe Raportoidun virheen vakavuusaste: - Estävä - Kriittinen - Vakava - Lievä - Kosmeettinen Raportoidun Virheiden priorisointi: - Korkea - Normaali - Matala Testitulosten käyttö Kunkin iteraation puolivälissä ja lopussa projektin johtoryhmä kerää kehittäjiltä testidataa, joka dokumentoidaan ja analysoidaan. Testidokumentaatiota pyritään käyttämään hyväksi projektinsuunnittelussa muun muassa siten, että ongelmakohtiin lisätään resursseja ja uusia ominaisuuksia kehitetään vasta sitten, kun vanhat on saatu onnistuneesti tuotettua. Suuremmista ongelmista projektiryhmä tulee informoimaan asiakasta ja mentoria Dokumentointi Dokumentointiin käytämme Napa Ltd:ltä projektin ajaksi käyttöön saamaamme NManGen sovellusta, joka tuottaa XML-lähdeaineistosta HTML ja PDF tulosteet. Dokumenttien säilyttäminen tekstimuotoisina (XML) mahdollistaa helpon versionhallinnan, ja myös mahdollistaa dokumentoinnin käytännössä millä tahansa päätelaitteella. XML-muotoisuus tuottaa tiettyä overheadia, mutta uskomme pienen ylimääräisen vaivan olevan kannattavaa XML-muotoisen datan siirrettävyyden ansiosta. Käytettävä työkalu mahdollistaa myös ulkoasultaan yhteneväisen dokumentaation tuottamisen. Käytettävän sovelluksen ansiosta saamme kaiken dokumentaation suoraan Data Sailorsin suojatuille www-sivuille ( avautuu uuteen ikkunaan). Dokumentointiin suosittelemme ilmaista XML WYSIWYG editoria nimeltään Vex (kts. kuva alla), mutta dokumentaatiota tuottavat saavat itse valita käyttämänsä editorin. Vexiin päädyttiin koska se käyttää Eclipsen IDEä jonka ansiosta mm. integrointi CVS:ään onnistuu ilman erillistä asiakassovellusta.

23 20 (45) Esimerkki Vex-näkymästä. Dokumentaatio sijaitsee CVS:n modulissa _input kts. tarkemmat yhteystiedot versionhallintaan. VEX:iin on myös integroitu NManGen sovellus ulkoisiin työkaluihin: NManGen HTML luo paikalliselle kovalevylle HTML-muotoisen dokumentaation ja NManGen ALL luo sekä HTML- että PDF-muotoisen dokumentaation. NManGen ALL -työkalu tulee ajaa ennen kuin päivittää dokumentaation versionhallintaan. Tällä varmistetaan sisällön eheys. Kun CVS sisältää halutun sisällön, tulee unix:issa suorittaa seuraava komento: vipunen ~ 51 % touch /p/work/may2006/mliljavi/datasailors/runq/runme Tämän jälkeen dokumentaatiosisältö päivittyy www-sivuille seuraavan 15 minuutin sisään. Tuotteelle ei tässä vaiheessa tarvita erillistä manuaalia, vaan käyttöliittymä tulee olemaan itse-selittävä. Mahdollisesti tarvittavat käyttöohjeet pyritään yhdistämään käyttöliittymään.

24 21 (45) Dokumentit ja vastuut Olemme määritelleet alla olevaan taulukkoon tiedossa oleville dokumenteille vastuuhenkilöt sekä varahenkilöt. Dokumentit ja vastuu Dokumentti Kuvaus Vastuuhenkilö Varahenkilö Vaatimusmäärittely a päivitetään läpi projektin kuvaamaan sitä mitä tehdään, mutta myös osittain sitä mitä on tehty. Vaatimusmäärittely kuvaa käyttäjälle näkyvää tuotteen toiminnallisuutta ja ominaisuuksia. Riskiloki Riskienhallintasuunnitelma ja riskiloki.. JI TH PP-edistymisraportti Edistymisraportti esitetään iteraatiodemossa projektin osapuolille. SEPA-päiväkirjat SEPA-tehtävä. ALL Testitapaussuunnitelma Sisältää suunnitelman, mitä tullaan testaamaan. TH,AA JI Testicharter Testicharteri on testaussuunnitelma vertaisryhmälle. Testiraportti Yhteenveto testituloksista. TH JI Testilogit Tekninen spesifikaatio Tekninen spesifikaatio ja kehittäjän opas Sisältää tietoa siitä, mitä testattiin, mitkä tuloksia saatiin ja kuka testasi. Arkkitehtuurin kuva/selitys (I1 iteraation palautettava dokumentti). Tarkempi spesifikaatio ja kehittäjän avuksi tarkoitettu opas (I2 iteraation palautettava dokumentti). Dokumentti kuvaa sovelluksen tilan. JI TH ML TH Kehittäjät Loppuraportti Kattava raportti projektin lopputilasta. JI TH/KR I2 iteraation edistymisraportti Edistymisraportti loppudemoon JI TH/KR Metriikat StatCVS, EMMA ML AA/JI Javadoc Private näkyvyyden Javadoc luonti projektidokumentaatioon ML ML AA TH JI JI JI JI JI JI

25 22 (45) Riskienhallinta Riskiloki ja selitys käytetyistä menetelmistä löytyy erillisestä dokumentista riskiloki Tuntiraportointi PP-iteraatiovaiheessa tuntiraportointi hoidetaan ilman erillistä raportointityökalua toimittamalla viikon päätteeksi projektipäällikölle iteraatiosuunnitelman mukaista tehtäväjakoa noudattava tuntilistaus. Jos iteraatiosuunnitelmasta puuttuu tarvittava tehtävä, siitä tulee ilmoittaa projektipäällikössä. Tämän jälkeen projektipäällikkö arvioi tehtävän tarpeellisuuden ja lisää sen tarvittaessa tehtävälistaan. I1 ja I2 iteraatioissa kehittäjät lisäävät omat tuntinsa suoraan Excel-muotoiseen tehtävälistaan, joka on noudettavissa CVS:stä. Raportointi hoidetaan vähintään viikon tarkkuudella, viimeistään jokaisen viikon keskiviikkoiltana. JI tekee torstai-aamuna yhteenvedon projektisuunnitelmaan asiakkaan sekä mentorin seurattavaksi. Toimittaja ei näe tarpeelliseksi erillisen tuntiraportointisovelluksen käyttöönottoa Sovelluksen koon raportointi Sovelluksen koon raportointia ja seurantaa tehdään suoraan versionhallintajärjestelmästä StatCVS ohjelmiston avulla /12/. Mitattavia suureita ovat LOC itse sovelluskoodille ja erikseen yksikkötestikoodille. Sovelluksen koon raportoinnista on vastuussa ML.

26 23 (45) Kommunikaatio Kommunikointi projektin osapuolien välillä hoidetaan seuraavilla menetelmillä: Palaverit: Projektin yhteydessä tullaan järjestämään useita palavereita. Kaikkiin kokouksiin pyritään kirjoittamaan etukäteen kaikille osallistujille tiedoksi agenda. Kaikista palavereista tulee kirjoittaa muistio dokumentointijärjestelmään. Muistiosta vastaava päätetään palaverikohtaisesti. Oletusarvoisesti ei pyritä kutsumaan kaikkia palaveriin, vaan ainoastaan ne, keitä asia koskee. Sekä palaveriagendaa että -muistiota varten on luotu mallipohjat CVS:ään ( [cvsroot]/head/_input/palaveriagendat/mallipohja/mallipohja.xml ja [cvsroot]/head/_input/palaverimuistiot/mallipohja/mallipohja.xml ) Viikkopalaverit: Ryhmällä on joka torstai kello 9:00 yhteinen viikkopalaveri, jossa käydään läpi yhteiset asiat (esimerkiksi esiteltävä ohjelmiston kokonaisuus), ryhmäläisten edistyminen ja jatkon tehtävät, muut ilmoitusasiat sekä sovitaan jatkon vastuista ja deadlineista. Tästä viikkopalaverista ei tehdä erillistä agendaa, mutta muistiota varten on luotu mallipohja CVS:ään ( [cvsroot]/head/_input/viikkopalaverit/mallipohja/mallipohja.xml ) Kotisivut: Kotisivuille julkaistaan kaikki projektia koskeva dokumentaatio (suojattu sivusto), mukaan lukien agendat, palaverimuistiot jne. Toimittajan jäsenet ovat velvollisia seuraamaan sivustoa, mutta merkittävistä muutoksista dokumentaatioon tiedotetaan projektin kaikille osapuolille sähköpostitse. Tällainen tapaus on esimerkiksi projektisuunnitelman valmistuminen katselmointia varten. Pikaviestimet: Sovitut työmentelmät (yhteiset työajat, työskentely samoissa tiloissa ja pariohjelmointi) johtivat pikaviestimien tarpeettomuuteen. Sähköposti: Kaikkien projektia koskevien sähköpostiviestin otsikkorivin aloittaa teksti "[COTOOL]". Projektiryhmää varten on perustettu sähköpostilista, datasailors#list.hut.fi. Tätä listaa käytetään koko ryhmää koskevaan tiedottamiseen, kuten palaverikutsuihin. Projektin erillisten jäsenten sähköpostiosoitteita käytetään kun sähköposti selvästi koskee vain tiettyä/tiettyjä henkilöitä. Puhelin: Puhelinta käytetään kun on tarpeen saada toinen osapuoli nopeasti kiinni tai konteksti vaatii enemmän vuorovaikutusta osapuolien kesken. Keskustelut: Koska asiakas tarjoaa toimittajalle työtilat, paljon tietoa saadaan vaihdettua yhteisissä työtilaisuuksissa. Koska näissä "käytäväkeskusteluissa" mitä todennäköisimmin tulee esille koko ryhmää koskevia asioita on niistä informoitava sähköpostilistan kautta muulle ryhmälle.

27 24 (45) Iteraatiodemo Iteraatiodemosta on ensisijaisesti vastuussa projektipäällikkö (JI), mutta ensimmäisen iteraatiodemon tapauksessa vastuu on annettu arkkitehdille (ML). Ensimmäiseen iteraatiodemoon kuuluu kurssin asettamat vaatimukset, sekä "Proof of Concept" -tyyppinen prototyyppi SVG-käyttöliittymästä /13/. Prototyypin tarkoitus on todistaa ketju AutoCAD ohjelmasta SVG-formaattiin ja selaimeen asti toimivaksi ja mahdolliseksi toteuttaa. Prototyypistä vastaa ensisijaisesti JI/ML Bugien hallinta Löydetyt virheet ja parannusehdotukset merkitään paperilapuille, jotka kiinnitetään seinälle. Paperille merkitään tarvittavat tiedot korjaamista varten sekä bugin vakavuusta aste ja prioriteetti. Projektin loputtua korjaamatta jääneet bugit tullaan raportoimaan loppudokumenttiin Versionhallinta Versionhallintaan käytetään CVS ohjelmistoa, ja repository sijaitsee atk-keskuksen work-levyaluella, jonka varmistamisesta atk-keskus huolehtii /2/ /14/. Versionhallintaan lisätään kaikki sellaiset tiedostot, joita ei pystytä tuottamaan automaattisesti jostain muista lähdetiedostoista. Versionhallintaa käytetään projektissa seuraavien periaatteiden mukaan: - Aloitettaessa työskentely, oma työkopio päivitetään repositorysta vastaamaan uusinta tilannetta (update). Samoin ennen omien muutosten päivittämistä repositoryyn tehdään update, jotta voidaan olla varmoja, että omat muutokset tulevat uusinta versiota vasten. - Päivitettäessä/lisättäessä (commit) ohjelmakoodia repositoryyn lisätään aina logi viesti siitä mitä on muutettu tai mitä on lisätty. - Repositoryyn lisätään (commit) vain toimivia ja kääntyviä ohjelma kokonaisuuksia. - Tageja käytetään palautusta tai testausta varten muodostettavien ohjelmakokonaisuuksien versioiden eroittamiseen ja merkitsemiseen. Versionhallinnan yhteystiedot: - palvelin: kosh.hut.fi, vipunen.hut.fi - polku: /p/work/may2006/mliljavi/datasailors/cvsroot - tunnus: atk-keskuksen tunnus - yhteystyyppi: extssh Versionhallinnan ylläpidosta ja käytännöistä vastaa ML.