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.

28 25 (45) Ohjelmointikäytännöt Tuotteen ohjelmakoodi tullaan kirjoitamaan Java -kielellä ja se muotoillaan Sun:n koodauskäytännön mukaisesti. Tarkennuksena Sun:in käytäntöihin sisennykset tehdään välilyönneillä, ja yksi sisennys on kahden merkin suuruinen. /15/ Ohjelmakoodin kommentointi Ohjelmakoodi tullaan asiakkaan pyynnöstä kommentoimaan englanniksi, vaikka tämänhetkinen Rauinfo-kommentointi on kirjoitettu suomeksi. Englanninkielisellä kommentoinnilla pyritään helpottamaan jatkokehitettävyyttä. Suomeksi saa kuitenkin kirjoittaa lyhytikäiset TODO ja FIXME kommentit, jotka ohjelmoija tarkoittaa itselleen muistutukseksi. Kaikille metodeille (myös private) kirjoitetetaan JavaDoc kommentointi, jonka perustarkoituksena on kuvata metodin toiminta sillä tarkkuudella, että sen ymmärtäisi asiaan hieman perehtynyt. Instanssimuuttujat kommentoidaan, mutta kommenteissa tulee käyttää maalaisjärkeä. Esimerkki turhasta kommentista: // ID of the area private int areaid = null; Turhien kommenttien välttämisellä helpotetaan koodin lukemista Vertaisryhmätestaus Vertaisryhmätestaus toteutetaan varsin myöhäisessä vaiheessa projektia (palaute saadaan vajaa viikko ennen kurssin viimeistä palautusta!). Tästä syystä heti kun vertaisryhmä on tiedossa, projektipäällikkö ottaa yhteyttä vertaisryhmään ja keskustelee mahdollisuudesta toteuttaa testaus aikaisemmin. Vertaisryhmätestauksen toteuttamisesta vastaa ensisijaisesti laatupäällikkö ja testaaja. Tuotteen testaaminen kuuluu jokatapauksessa pääasiallisesti toimittajalle, joten vertaisryhmätestauksesta pitää pyrkiä saamaan irti jotain, mikä mahdollisesti jäisi muuten toimittajalta vähälle huomiolle. Koska toimitettavan tuotteen tapauksessa on suuresti kyse käytettävyydestä ja visuaalisuudesta, voisi testaus keskittyä nimenomaan näihin asioihin. Vertaisryhmätestaussuunnitelma tehdään viimeistään I2 vaiheessa Vaatimusten hallinta Tässä projektissa vaatimusten määrittelyjen pääasiallisena lähteenä toimii asiakashaastattelut ja heidän tarjoama materiaali. Projektin ensimmäisessä iteraatiossa järjestettiin haastattelu, jonka perusteella luotiin ensimmäinen versio vaatimusmäärittelyistä. Vaatimusten kerääminen tulee olemaan iteratiivinen prosessi ja dokumentteja on tarkoitus päivittää ja korjata aina tarpeen mukaan. Vaatimuksia määriteltäessä käytetään seuraavanlaista prosessia: projektiryhmä tekee esityksen vaatimuksesta, asiakas tutustuu vaatimuksiin, tarkistaa niiden oikeellisuuden, tarvittaessa pyytää tekemään muutoksia ja lopulta hyväksyy tai hylkää ehdotuksen. Tämän jälkeen hyväksytty vaatimusmäärittely otetaan osaksi järjestelmän kehitystä.

29 26 (45) 5.2 Laadunvarmistussuunnitelma Johdanto Koska COTOOL-työkalu tulee Jaakko Pöyry Infran omien asiakkaiden käyttöön, on huomioitava, että tuotteen laadulla tulee olemaan erittäin suuri merkitys. Projektissa tämä näkyy muun muassa siten, että esimerkiksi ajan käydessä vähiin, tullaan tinkimään lisäominaisuuksista, mutta ei laadusta. Tämä laadunvarmistussuunnitelma on toteutettu siten, että aluksi on esitelty koko projektiin liittyvät laatuasiat ja sen jälkeen iteraatiokohtaiset. Kuten monet muutkin projekti dokumentit, laadunvarmistussuunnitelmaa tullaan tarpeen mukaan päivittämään, mikä on projektin osapuolten hyvä huomioida. Jotta tuotteesta tulee hyvä, koko projektiryhmän on sitouduttava laaduvarmistukseen. TH on päävastuussa laadunvarmistuksesta ja siihen liittyvästä dokumentaatiosta. Muun projektiryhmän velvoitteena on tehdä laadunvarmistukseen liittyvät toimenpiteet ja toimittaa TH:lle tarvittava dokumentaatio muun muassa testaukseen liittyen. Lisätietoja laadunvarmistukseen liittyvistä palautettavista dokumenteista kappaleessa Dokumentit ja vastuut Projektitason aiheet Projektin tärkeimmät laatutavoitteet Olemme asettaneet neljä tärkeintä laatuvaatimusta, joihin projektin ryhmän tulisi kiinnittää erityisesti huomiota: Tärkeimmät laatutavoitteet Nr Laatutavoite Tarkistus 1. Loppukäyttäjän käyttöliittymän tulee olla visuaalisesti näyttävä ja helppokäyttöinen 2. Sovitut toiminnot on kehitettävä laadukkaasti ja järjestelmän on oltava luotettava 3. Koodi on laadukasta ja tuote on jatkokehitettävä Helppokäyttöisyys arvioidaan käytettävyystestauksen avulla. Lisäksi asiakas itse arvioi visuaalista näyttävyyttä Asiakas arvioi luovutusvaiheessa työn laadun, sekä arvioi testitapausten ja rinnakkaisryhmävertailun tulosten perusteella luotettavuuden Asiakkaan tekninen avustaja arvioi luovutusvaiheessa 4. Toteutus on hyvin dokumentoitu Asiakas arvioi projektin loputtua

30 27 (45) Laadun arviointi Projektin johtoryhmä pyrkii arvioimaan tuotteen laatua muun muassa seuraavilla tunnusluvuilla: - Testaukseen käytetty aika - Suoritettujen testitapausten määrä - LOC vs. Yksikkötestien LOC ja niiden kattavuus sovelluskoodista EMMA-työkalulla. - Löydettyjen virheiden lukumäärä per moduuli - Löydettyjen virheiden lukumäärä vakavuustason mukaan luokiteltuna - Korjattujen virheiden lukumäärä - Korjaamattomien virheiden lukumäärä - Käytettävyystestaus ja vertaisryhmätestaus: Saatu palaute - Käytettävyystestaus: Henkilön vihreiden lkm testitapausta suorittaessa Kunkin iteraation lopussa tunnusluvut pyritään analysoimaan ja niistä tehdään yhteenveto, joka toimitetaan sekä asiakkaalle että mentorille Iteraatiotason aiheet Ensimmäinen iteraatio Tärkeimmät ensimmäiseen iteraation testaustoimenpiteet liittyvät testien suunnitteluun, arkkitehtuurin ja rajapintojen katselmointiin. Koska aluksi suurin osa koodista on staattista, ei automatisoituja yksikkötestejä tulla heti tarvitsemaan vaan ne otetaan käyttöön vasta kun varsinaisten luokkien kehitys alkaa. Ensimmäisessä iteraation testivastuut: Testivastuut Vastuualue AA JI JW KR ML PS TH Katselmointi X X Testitapausten suunnittelu X X X Yksikkötestaus X X X X Integraatiotestaus Järjestelmätestaus X Käytettävyystestaus X X Testauksen raportointi X X

31 28 (45) Ensimmäisen iteraation testiaikataulu: Testiaikataulu Testialue VK 43 VK 44 VK 45 VK 46 VK 47 VK 48 VK 49 Katselmointi X X X X X Testitapausten suunnittelu X X X X X Yksikkötestaus X X Integraatiotestaus X X Järjestelmätestaus X X Käytettävyystestaus Testauksen raportointi Ensimmäisen iteraation lopulla tullaan palauttamaan päivitetty laadunvarmistussuunnitelma, testitapaukset ja testilogi sekä testiraportti. Katso tarkemmin kappaleesta Dokumentit ja vastuut X Toinen iteraatio Toisen iteraation alussa arkkitehtuurista vastaava henkilö vaihtui ML:stä KR:ksi. Siten KR vastaa koodi ja arkkitehtuuri katselmoinneista. Ensimmäisessä iteraatiossa ei ehditty tekemään käytettävyystestausta, joten se toteutetaan toisen iteraation aikana. Toisessa iteraatiossa yksikkötesteillä tulee olemaan huomattava paino. Ensimmäisen iteraation kangertelun jälkeen yksikkötestien luonti on kehittäjille helpompaa ja tarkoituksena onkin, että he tulisivat myös ainakin testaamaan test driven developmenttia. Yksikkötestien lisäksi integraatio ja järjestelmätesteihin tulee kiinnittää huomiota. Päävastuu niiden suunnittelemisesta ja toteutuksesta on edelleen AA:lla ja TH:lla. Tärkeä osa I2:sta on myös vertaisryhmätestaus. Vertaisryhmänä toimii Kaffetauko. TH vastaa vertaisryhmätestauksen käytännön järjestelyistä. Tarkoituksena on sopia toisen ryhmän kanssa vertaistestauksen suorittamisesta muutamaa viikkoa ennen kurssin määräämään DL:ää. Täten ryhmälle jää enemmän aikaa bugien korjaamiseen ja siten vertaistestauksesta on mahdollista saada enemmän irti. Vertaisryhmätestauksen painotuksesta tullaan sopimaan mahdollisimman nopeasti ryhmän kesken, mutta alustavasti sen oletetaan painottuvan käyttöliittymän testaukseen sekä tärkeimpiin käyttötapauksiin. Tärkeimpiä ohjelman testattavia osa-alueita ovat käyttöliittymä, toteutettavat java-luokat sekä järjestelmän rajapinta olemassa olevaan JP:n järjestelmään ja tietokantoihin. I2:ssa on ehdottoman tärkeää, että kaikista virheistä/parannusta vaativista toiminnoista pidetään tarkkaa seurantaa (muun muassa tarralappujen avulla), jotta niistä ollaan tietoisia aina järjestelmän luovuttamiseen saakka. Toisen iteraatiossa palautetaan päivitetty laadunvarmistussuunnitelma,käytettävyystestaus SEPA:n tulokset, testitapaukset ja testilogi, testiraportti ja virhe raporttien yhteenveto.

32 29 (45) Toisen iteraation testivastuut: Testivastuut Vastuualue AA JI JW KR ML PS TH Katselmointi X X Testitapausten suunnittelu X X X Yksikkötestaus X X X X Integraatiotestaus Järjestelmätestaus X Käytettävyystestaus X X Testauksen raportointi Vertaisryhmätestauksen suunnittelu Vertaisryhmätestaus X X Toisen iteraation testiaikataulu: Testiaikataulu Testialue VK 2 VK 3 VK 4 VK 5 VK 6 VK 7 VK 8 Katselmointi X X X X X X X Testitapausten suunnittelu X X X X X Yksikkötestaus X X X X X X X Integraatiotestaus X X X X X X Järjestelmätestaus X X X X X Käytettävyystestaus Testauksen raportointi X X X Vertaisryhmätestauksen suunnittelu Vertaisryhmätestaus X X X X X X

33 30 (45) 5.3 Työkalut Palvelimella Tuotantoympäristö on jo olemassa, joten palvelinympäristö on siltä osin määrätty: - Käyttöjärjestelmä: Microsoft Windows Server 2003 Standard Edition - Tietokantapalvelin: Microsoft SQL Server WWW-palvelin: Tomcat 5.5 Lisäksi WWW-palvelimelle on asennettu seuraavat kolmannen osapuolen kirjastot: - Tietokantayhteydet: Microsoftin oma JDBC kirjasto - Graafien tuottamiseen: jfreechart Lokitus: java.util.logging Työasemissa Työasemien kehitysympäristö on myös olemassa: - Käyttöjärjestelmä: Microsoft Windows XP - WWW-palvelin: Apache Tomcat IDE: Eclipse 3.1M7 + Pluginit: JUnit /18/, EMMA 2 /19/ - Dokumentointi: Vex Versiohallinta: Eclipisen sisäänrakennettu CVS 5.4 Standardit Kuten asiakkaan projektille asettamat tavoitteet kertoivat, standardin ja jatkokehitettävän tuotteen tekeminen oli tärkeää: (kts. lyhenteet) Projektissa päädyttiin alkuperäisen suunnitelman mukaan käyttämään seuraavia standardeja: - XML /5/ - XSL/XSL-.FO /6/ - SVG /7/ Käytetyistä standardeista tarkemmin lisää teknisessä dokumentaatiossa. /9/

34 31 (45) 6 Projektin vaiheistus 6.1 Aikataulu Seuraavassa taulukossa on projektin tärkeimmät päivämäärät, jotka kurssi tässä vaiheessa määrittelee. Lisäksi taulukossa on asiakkaan/mentorin kanssa jo sovitut tapaamiset ja deadlinet. Ryhmän sisäisiä viikkopalavereita aikatauluun ei ole kirjoitettu poikkeuksia lukuunottamatta. Projektiaikataulu Pvm Tapahtuma PP Projektisuunnittelu To :00 PP-Iteraatiosuunnittelu/Kick-off palaveri Ma DL 13:00 Lähetä iteraatiosuunnitelma (n kappaleet 6.1 & 6.2) sähköpostitse mentorille ja asiakkaalle Ma To Ma Vko 41 Ma To :00 Asiakkaan tuotantoympäristöön tutustuminen 9:00 Käyttäjävaatimukset, I palaveri asiakkaan kanssa 15:00 I Mentortapaaminen I1a Toteutus 1a Ma Su Ma To Tarvittaessa: Käyttäjävaatimukset, II palaveri asiakkaan kanssa DL 13:00 Dokumenttien palautus 9:00-10:00 Projektisuunnittelu iteraatiodemo Innopolissa, 4.krs, huone Saarikoski DL 13:00 Ryhmän rekisteröinti. Lähetä nimet ja opiskelijanumerot kurssin vastuuhenkilölle. 17:00 Tehtävät ja työkäytännot. Projektiryhmän tapaaminen Maarilla. DL 13:00 Lähetä iteraatiosuunnitelma ja laatusuunnitelma (n kappaleet 5.2, 6.1 ja 6.3) sähköpostitse mentorille ja asiakkaalle 9:00 Toteutus 1a iteraatiodemo I1b Toteutus 1b Ma Ke To Joululoma Aikataulu jatkuu seuraavalla sivulla. DL 13:00 Dokumenttien palautus 9:00-10:00 Huom! poikkeus viikkopalaveri torstain sijaan keskiviikkona! 10:00-11:00 Reflection workshop 9:00-10:00 Toteutus 1b iteraatiodemo Innopolissa, 4.krs, huone Saarikoski

35 32 (45) Projektiaikataulu Pvm Tapahtuma I2a Toteutus 2a Ke DL 13:00 Lähetä iteraatiosuunnitelma ja laatusuunnitelma (n kappaleet 5.2.2, 6.1 ja 6.4) sähköpostitse mentorille ja asiakkaalle :00 Toteutus 2a iteraatiodemo asiakkaalle ja mentorille JPn tiloissa I2b Toteutus 2b Pe Ti Ma To 2.3. DL 13:00 Toimita järjestelmä ja testausohjeet vertailuryhmälle. DL 13:00 Raportoi vertailuryhmän testauksen tulokset. DL 13:00 Dokumenttien palautus 15:00-16:00 Projektikatselmus Innopolissa, 4.krs, seminaarisalissa hissien takana. 6.2 Projektisuunnittelu Tavoiteet: - Ryhmän, asiakkaan ja mentorin tutustuminen - Kehitysympäristön pystyttäminen asiakkaan osoittamiin tiloihin - Kehittäjien rekrytointi - Asiakkaan tuotantoympäristöön tutustuminen - Asiakkaan tarpeiden määrittely (sisältäen tärkeimmät toiminnalliset vaatimukset ja käyttötapaukset) - Käytettävien tekniikoiden määrittely ja niiden vaatima lisäopiskelu - Henkilökohtaisten ohjelmistotuotannon käytäntötehtävien (SEPA) suunnittelu - Projektiryhmän WWW-sivuston perustaminen - CVS-versiohallinnan perustaminen Palautettavat dokumentit: - Projektisuuunnitelma (poislukien kappale. 5.2 Laatusuunnitelma) - Vaatimusdokumentti (kappaleet 1-5, 6-9 ainakin tärkeimmille vaatimuksille ja 11-12) - Edistymisraportti - SEPA-päiväkirjat - "Proof of concept" prototyyppi ainakin SVG-pohjaisesta käyttöliittymästä

36 33 (45) Projektisuunnittelun tavoitteet on jaettu pienempiin osatehtäviin alla olevaan taulukkoon. Huomattavaa on, että PP-iteraation pituus on vain kaksi kalenteriviikkoa. Projektisuunnittelun tehtävät Tehtävä Työpan. [h/hlö] Vastuu Yht [h] Toteut. Deadline Dokumentointi: Edistymisraportti iteraatiodemoon 2 ML :00 Dokumentointi: n johdanto 1 JI :00 Dokumentointi: n osapuolet ja henkilöstö Dokumentointi: n tavoitteet ja lopetuskriteerit Dokumentointi: n resurssit ja budjetointi Dokumentointi: n työkäytännöt ja työkalut, poislukien kappaleet 5.1.6, 5.1.9, , , ja 5.2. Dokumentointi: n sovelluksen koon raportointi, bugienhallinta, versionhallinta ja ohjelmointikäytännöt. Dokumentointi: n vaatimusten hallinta. [h] 3 JI :00 2 JI, TH :00 2 JI :00 4 JI :00 2 ML 2 2, :00 1 TH 1 1, :00 Dokumentointi: n viimeistely 3 JI 3 1, :00 Dokumentointi: 6.1 ja JI :00 Dokumentointi: Vaatimusmäärittely 20 TH :00 Dokumentointi: WWW-sivujen päivitys 2 ML :00 Infra: CVS-repository 2 ML 2 2, :00 Infra: Dokumentointijärjestelmän pystytys 2 JI 2 2, :00 Infra: Kehitysympäristö asiakkaan tiloihin 3 ML :00 Infra: WWW-sivusto 2 ML :00 Opiskelu: Henkilökohtaiset SEPA päiväkirjat 3 JI, TH, ML Opiskelu: Luennot 5 JI, TH, ML Opiskelu: Toteutusteknologiavaihtoehtojen kartoitus, opiskelu ja valinta 3 JI, TH, ML Projektinhallinta: Ryhmän tapaamiset 3 JI, TH, ML Projektinhallinta: Asiakkaan tuotantoympäristöön tutustuminen Projektinhallinta: Tarvittavat sopimukset, kulkuluvat jne kuntoon asiakkaan kanssa Taulukko jatkuu seuraavalla sivulla. 2 JI, TH, ML : :00 2 JI :00

37 34 (45) Projektisuunnittelun tehtävät Tehtävä Työpan. [h/hlö] Vastuu Projektinhallinta: Kehittäjien rekrytointi 2 JI, TH, ML Projektinhallinta: Kick-off/PP-iteraatiosuunnittelupalaveri 2 JI, TH, ML Projektinhallinta: Käyttäjävaatimukset, I palaveri asiakkaan kanssa Projektinhallinta: Käyttäjävaatimukset, II palaveri asiakkaan kanssa 2 JI, TH, ML 2 JI, TH, ML Projektinhallinta: Mentortapaaminen 1 JI, TH, ML Yht [h] Toteut. Deadline [h] : vko :00 Projektinhallinta: Tuntiseuranta 1 JI :00 Suunnittelu: SVG Proof of concept 3 JI, ML :00 Suunnittelu: Yleiskuva arkkitehtuurista 3 ML :00 Henkilökohtaiset resurssoinit näkyy kappaleessa 4.1 Henkilöstö. Yhteensä ,5

38 35 (45) 6.3 Toteutus 1 Toteutus 1 on jaettu kahteen pienempään iteraatioon vaiheistuksen, rerurssoinnin ja testaamisen helpottamiseksi. Kutsumme näitä "ali-iteraatioita" Toteutus 1a ja 1b nimikkeillä. Toteutus 1b -vaiheen tavoitteetkin tarkentuvat vasta 1a iteraatiodemon jälkeen Toteutus 1a ( ) Tavoiteet: - Kehitysympäristön pystyttäminen asiakkaan osoittamiin tiloihin (Siirtyi PP-vaiheesta) - Kehittäjien tutustuttaminen asiakkaan tuotantoympäristöön - Kehittäjien kouluttaminen tarvittaviin tekniikoihin - Loppukäyttäjän käyttöliittymä - Toteuttaa ensimmäinen versio Rauinfoon (YHT_KT04 ja YHT_KT06) - Suunnitella toteutustekniikka "heti näytettävälle" (esim lämpötila) datalle ja erikseen serveriltä haettavalle datalle (esim viikon hiilidioksidipitoisuus graafi). - Kartoitetaan ja toteutetaan tarvittavia "alueiden" välisiä relaatioita. - Kartoitetaan ja suunnitellaan tarvittavia "alueiden" eventtejä. - Tarkentaa tietoutta AutoCAD ohjelmistosta - Kartoittaa DXF-SVG konversion mahdollisuudet (Ylläpitoliittymän työkalujen kartoitus) Palautettavat dokumentit: - Tekninen dokumentti (drafti palvelin ja asiakasarkkitehtuureista) - Riskienhallintasuunnitelma varteenotettaville riskeille. - Päivitetty vaatimusmäärittely Palautettavat sovelluksen osat: - Loppukäyttäjän käyttöliittymän ensimmäinen versio Rauinfoon toteutettuna asiakkaan valitsemalla pohjapiirustuksella ilman haettavaa anturidataa. Palvelimen päässä alustava tietorakenne pohjapiirustukselle/piirustuksille ja niiden alueille.

39 36 (45) Toteutus 1b ( ) Tavoiteet: - Loppukäyttäjän käyttöliittymästä: - Parantaa käyttöliittymää 1a iteraation palautteen perusteella. - Toteuttaa staattisten "heti näytettävän" (esim lämpötila) datan sekä erikseen serveriltä kutsuttavan datan haku (esim viikon hiilidioksidipitoisuus graafi). - Toteuttaa tarvittavat "alueiden" eventit. - Sopia tietokantarajapinta - Suunnitella ja toteuttaa viikoittainen releaserutiini Palautettavat dokumentit: - Projektisuuunnitelma (Erityisesti kappale 5.2 Laatusuunnitelma) - Tarkennettu vaatimusdokumentti - Tekninen dokumentti (Vähintään yleinen arkkitehtuuri) - Testaustapaukset, -raportti ja -loki - Edistymisraportti - SEPA-päiväkirjat Palautettavat sovelluksen osat: - Loppukäyttäjän käyttöliittymän toinen versio Rauinfoon toteutettuna ainakin staattisella, palvelimelta haetulla anturidatalla. Palvelimen päässä tarkennettu tietorakenne kiinteistön pohjapiirustukselle/piirustuksille, niiden alueille ja aluesiin kytketyille antureille.

40 37 (45) Toteutus 1a ja 1b tehtävät Toteutus 1a ja 1b vaiheiden tavoitteet on jaettu tehtäviin alla olevaan taulukkoon. 1a loppuu ja 1b alkaa viikolla 46. Toteutus 1b vaiheen tehtävät tarkentuvat, ja niiden tuntimäärät arvioidaan viikolla 46. Tämä siksi, jotta vaiheen 1b tavoitteisiin voidaan vaikuttaa 1a iteraatiodemossa tekemättä "turhaa työtä". Toteutuneet tunnit perustuvat tuntiraportointeihin,jotka löytyvät kokonaisuudessaan Excel-tiedostoina dokumentaation liitetiedostoista. Toteutus 1a ja 1b tehtävät Työpanos[h/vko] Yht. Tot. Erot. ID Tehtävän selitys Vastuu [h] [h] [h] DL PR005 PP Iteraatiodemo PR006 I1 Iteraatiosuunnittelupalaveri TH, JI, ML, KR, PS, JW TH, JI, ML, KR, PS, JW 6,0 6,0 5,0 1, ,0 7,0 4,0 3, OP001 Luennot ALL 14,0 14,0 4,0 10, IN002 Kehitysympäristö asiakkaan tiloihin DO002 Laadunvarmistussuunnitelman kirjoittaminen ML 1,5 1,5 3,0 14,0-11, TH, JI 6,0 6,0 12,0 17,5-5, PR001 Tunnit.xls JI 2,5 2,5 5,0 5,5-0, IN001 CVS/WWW-ylläpito ML 0,6 0,6 0,6 0,6 0,6 0,6 0,6 4,0 8,5-4, DO010 Työmenetelmien tarkentaminen DO004 Tehtävien suunnittelu 1a vaiheeseen DO001 Projektin tavoitteet 1a vaiheeseen OP003 Rauinfo opiskelu SU003 Demo servletti kehitysympäristöön koulutusta varten DO009 Riskienhallintasuunnitelma todennäköisimmille skenaarioille OP002 SVG konversiotyökalujen testaus/kartoitus SU001 COTOOL palvelinarkkitehtuuri Taulukko jatkuu seuraavalla sivulla. JI 2,5 2,5 5,0 5,0 0, JI, ML 4,0 4,0 2,0 2, TH, JI, ML AA, ML, KR, PS, JW 4,5 4,5 9,0 2,0 7, ,5 8,5 17,0 30,5-13, ML 2,0 2,0 4,0 18,7-14, JI 2,0 2,0 4,0 3,5 0, KR 3,8 3,8 7,5 2,5 5, AA, JI, ML, KR, JW 6,3 6,3 6,3 6,3 25,0 26,5-1,

41 38 (45) Toteutus 1a ja 1b tehtävät Työpanos[h/vko] Yht. Tot. Erot. ID Tehtävän selitys Vastuu [h] [h] [h] DL DO011 Vaatimusmäärittelyn tarkentaminen DO012 n työmenetelmien tarkentaminen DO003 WWW-sivujen päivitys PR002 Tuntien/(edistymisen) seuranta TH 1,7 1,7 1,7 1,7 1,7 1,7 10,0 2,0 8, JI 0,7 0,7 0,7 0,7 0,7 0,7 4,0 3,5 0, ML 0,3 0,3 0,3 0,3 0,3 0,3 2,0 0,0 2, JI 1,2 1,2 1,2 1,2 1,2 1,2 7,0 6,0 1, PR003 Ryhmätapaamiset ALL 5,8 5,8 5,8 5,8 5,8 5,8 35,0 31,1 3, TO001 Staattinen demo rauinfoon OP004 SVG formaattiin tutustuminen TE001 Testauksen suunnittelu OP005 XSLT muunnoksien opiskelu PR004 Viikkopalaveri torstaisin asiakkaalla (Ryhmän sisäinen) SU004 Käyttöliittymä versio 1 (leiska) OP006 AutoCAD tietouden syventäminen TO010 Asiakkaan oma pohjapiirustus käyttöön DO013 Tavoitteiden tarkentaminen 1b vaiheeseen PR007 1a iteraatiodemo asiakkaan kanssa PR009 Riskienhallintapalaveri ja tarvittavat toimenpiteet TO002 Käyttöliittymä versio 2 (html/svg) DO005 Tehtävien tarkentaminen 1b vaiheeseen Taulukko jatkuu seuraavalla sivulla. ML, PS 5,0 5,0 19,5-14, AA, KR, PS, JW 10,0 10,0 20,0 9,5 10, AA, TH 5,0 5,0 10,0 9,0 1, JW 2,0 2,0 2,0 2,0 2,0 10,0 2,0 8, ALL 7,0 7,0 7,0 7,0 7,0 35,0 30,5 4, PS 7,5 7,5 5,0 2, KR 3,8 3,8 7,5 4,0 3, KR 3,8 3,8 7,5 2,5 5, JI 1,0 1,0 2,0 0,0 2, ALL 14,0 14,0 8,2 5, TH, JI, ML 6,0 6,0 2,0 4, PS 10,0 10,0 18,5-8, JI, ML 4,0 4,0 5,0-1,

42 39 (45) Toteutus 1a ja 1b tehtävät Työpanos[h/vko] Yht. Tot. Erot. ID Tehtävän selitys Vastuu [h] [h] [h] DL TO004 Toteutetaan alueiden eventit IN003 Releaserutiinin suunnittelu/toteutus demosivustolle TO007 Käyttöliittymä versio 3 ensimmäisten kommenttien perusteella (html/svg) SU005 Kartoitetaan alueiden väliset relaatiot SU006 Kartoitetaan alueiden eventit OP007 Junit testauskäytännöt OP008 Bugzilla käytännöt SU002 COTOOL asiakaspalvelinarkkitehtuuri TO003 Toteutetaan alueiden väliset relaatiot TO009 COTOOL palvelinarkkitehtuurin toteuttamista SU007 Sovitaan tietokantarajapinta asiakkaan kanssa TO005 Haetaan palvelimelta "heti näytettävä" (staattinen) data TO006 Haetaan palvelimelta "erikseen haettava" (staattinen) data TO008 Release kerran viikossa TO011 Käyttöliittymä versio 4 iteraatiodemoon (html/svg) AA, JW 5,0 5,0 5,0 15,0 6,5 8, AA 10,0 10,0 0,0 10, PS 17,0 17,0 16,0 1, JI, ML 4,5 4,5 9,0 4,7 4, JI, ML 4,3 4,3 8,5 7,0 1, AA, KR, PS, JW AA, KR, PS, JW AA, JI, ML, KR, JW AA, ML, KR, JW AA, KR, JW ML, KR, JW 4,0 4,0 8,0 4,5 3, ,0 2,0 4,0 1,0 3, ,8 13,8 27,5 25,5 2, ,0 11,0 22,0 24,6-2, ,5 7,5 15,0 19,0-4, ,5 8,5 17,0 4,0 13, AA 2,5 2,5 5,0 0,0 5, AA, KR, JW 7,5 7,5 15,0 0,0 15, AA 2,0 2,0 0,0 2, PS 17,0 17,0 12,5 4, PR008 1b Iteraatiodemo ALL 14,0 14,0 0,0 14, Yhteensä 37,6 53,7 68,7 56,5 73,0 116,7 108,7 14,0 529,0 432,8 96,2

43 40 (45) 6.4 Toteutus 2 Kuten toteutus 1, myös toteutus 2 on jaettu kahteen pienempään ali-iteraatioon vaiheistuksen, rerurssoinnin ja testaamisen helpottamiseksi. Kutsumme näitä "ali-iteraatioita" Toteutus 2a ja 2b nimikkeillä. Toteutus 2b -vaiheen tavoitteetkin tarkentuvat vasta 2a iteraatiodemon jälkeen Toteutus 2a Tavoiteet: - DAO:n sopiminen ja toteuttaminen (kaikki muu data DAO:n taakse tietokantaan paitsi SVG) - Tarkennetaan vaatimusmäärittelyä käyttötapausten kuvausten osalta - Toteutetaan arkkitehtuurin mukaisesti tämänhetkinen käyttöliittymä Java-luokkiin Palautettavat sovelluksen osat: - Loppukäyttäjän käyttöliittymän kolmas versio Rauinfoon toteutettuna tietokannasta haettavalla anturidatalla (lämpötila: keskiarvo, minimi ja maksimi kiinteältä aikaväliltä). Palvelimen päässä tarkennettu tietorakenne kiinteistön pohjapiirustukselle/piirustuksille, niiden alueille ja alueisiin kytketyille antureille Toteutus 2b Tavoiteet: - Testauttaa käyttöliittymää loppukäyttäjillä - Myös SVG-tiedosto DAO:n taakse ja tietokantaan - Ainakin minimi ylläpitäjän liittymästä. - SVG pakkaus jos pakkaamaton tiedostokoko vaikuttaa olevan liian suuri. - Kouluttaa asiakas järjestelmän ylläpitäjäksi Palautettavat dokumentit: - - Vaatimusmäärittely - Tekninen määrittely - Testitapaukset, testiraportti ja testiloki - Vertaisryhmätestaussuunnitelma - Vertaisryhmätestausraportti - Käyttäjämanuaali (Tehdään asiakkaan pyynnöstä "Developer's Guide") - Loppuraportti - Iteraatiodemon edistymisraportti - T : SEPA päiväkirjat Palautettavat sovelluksen osat: - Loppukäyttäjän käyttöliittymän viimeinen versio testauksen tuoman palautteen perusteella päivitettynä. - Minimi ylläpitäjän liittymästä

44 41 (45) Toteutus 2a ja 2b tehtävät Toteutus 2a ja 2b vaiheiden tavoitteet on jaettu tehtäviin alla olevaan taulukkoon. Taulukon lopussa on myös muutama tehtävä, joiden parissa ei näillä näkymin enää työskennellä. Siksi nämä ovat "nollarivejä". 2a loppuu ja 2b alkaa viikolla 5. Toteutus 2b vaiheen tehtävät tarkentuvat, ja niiden tuntimäärät arvioidaan viikolla 5. Tämä siksi, jotta vaiheen 2b tavoitteisiin voidaan vaikuttaa 2a iteraatiodemossa tekemättä "turhaa työtä". Toteutuneet tunnit perustuvat tuntiraportointeihin,jotka löytyvät kokonaisuudessaan Excel-tiedostoina dokumentaation liitetiedostoista. Toteutus 1a ja 1b tehtävät Työpanos[h/vko] Yht. Tot. Erot. ID Tehtävän selitys Vastuu [h] [h] [h] DL PR_001 I2 Iteraatiosuunnittelupalaveri SU_001 interactivity\impl\ IEJavascriptLoader.java Taulukoitavat arvot SU_002 interactivity\impl\ IEJavascriptLoader.java suunnittelu ALL 7,0 7,0 7,9-0, KR, JW 4,0 4,0 8,0 5,5 2, KR, PS 6,2 6,2 6,2 18,5 26,5-8, DO_001 Arkkitehtuuri JI, KR 9,8 9,8 9,8 9,8 39,0 42,5-3, PR_008 StructureLoader.java toteutus DO_004 Riskienhallintasuunnitelma DO_003 Sovitaan tietokantarajapinta asiakkaan kanssa DO_005 StructureLoader.java alarmit TO_008 Tehtävien tarkentaminen I2a vaiheeseen TO_038 Projektin tavoitteet I2a vaiheeseen TO_012 interactivity\impl\ IEJavascriptLoader.java Taulukointi dynaaminen luominen AA, KR 5,5 5,5 5,5 5,5 22,0 39,3-17, TH 0,8 0,8 0,8 0,8 0,8 4,0 3,5 0, KR 5,0 5,0 4,0 1, KR 5,0 5,0 5,0 0, JI, KR 3,0 3,0 6,0 12,0-6, TH, JI, KR 3,0 3,0 6,0 4,0 2, JW 4,0 4,0 4,0 4,0 16,0 20,5-4, TO_013 Staattiset javascriptit AA, JW 6,5 6,5 6,5 6,5 26,0 32,0-6, TO_014 Vaatimusmäärittelyn tarkentaminen TO_015 Laadunvarmistussuunnitelman TH, JI, kirjoittaminen KR TO_016 n ylläpitäminen Taulukko jatkuu seuraavalla sivulla. TH 3,3 3,3 3,3 3,3 3,3 3,3 20,0 16,5 3, ,0 2,0 2,0 2,0 2,0 2,0 2,0 14,0 19,0-5, JI 0,6 0,6 0,6 0,6 0,6 0,6 0,6 4,0 5,0-1,

45 42 (45) Toteutus 1a ja 1b tehtävät Työpanos[h/vko] Yht. Tot. Erot. ID Tehtävän selitys Vastuu [h] [h] [h] DL TO_017 DAO metodit ja SPt AA, KR 24,0 24,0 33,2-9, TO_018 interactivity\ Loader.java TO_019 interactivity\ LoaderFactory.java DO_006 beans\ DeviceList.java AA 2,0 2,0 4,0 9,8-5, AA 1,0 1,0 2,0 6,0-4, AA, ML DO_007 beans\ AA, DeviceMeasurement.javaML DO_008 beans\ Parameters.java PR_003 Ulkoasun toteuttaminen I2a vaiheessa AA, ML 0,7 0,7 0,7 2,0 4,0-2, ,0 2,0 2,0 6,0 8,3-2, ,7 2,7 2,7 8,0 7,5 0, PS 6,7 6,7 6,7 20,0 17,0 3, PR_005 SVG lataus servletti AA, JW 3,3 3,3 3,3 10,0 13,0-3, SU_004 JS lataus servletti AA, ML 2,0 2,0 2,0 6,0 11,1-5, TO_002 Hakupuu servletti AA, JW 2,0 2,0 2,0 6,0 6,0 0, TO_003 Constants.java AA 1,3 1,3 1,3 4,0 5,5-1, TO_020 TreeLoader.java TO_030 beans\area.java TO_032 beans\arealist.java TO_033 beans\building.java TO_035 beans\device.java AA, PS, JW AA, ML AA, ML AA, ML AA, ML 13,3 13,3 13,3 40,0 38,7 1, ,0 2,0 2,0 6,0 4,4 1, ,7 0,7 0,7 2,0 0,3 1, ,3 1,3 1,3 4,0 0,3 3, ,3 3,3 3,3 10,0 8,5 1, TO_004 Testauksen suunnittelu TH 2,5 2,5 2,5 2,5 10,0 15,0-5, TO_005 WWW/CVS-ylläpito + metriikat ML 1,7 1,7 1,7 1,7 1,7 1,7 10,0 6,0 4, TO_006 Tunnit.xsl JI 0,8 0,8 0,8 0,8 0,8 0,8 5,0 0,0 5, TO_007 Tuntien/edistymisen seuranta JI 1,2 1,2 1,2 1,2 1,2 1,2 7,0 9,5-2, TO_023 Ryhmätapaamiset ALL 4,7 4,7 4,7 4,7 4,7 4,7 28,0 35,5-7, TO_024 Testauksen toteutus TH 0,8 0,8 0,8 0,8 0,8 0,8 5,0 10,0-5, TO_027 AutoCAD + konvertointi tietouden lisääminen Taulukko jatkuu seuraavalla sivulla. PS 1,3 1,3 1,3 4,0 3,0 1,

46 43 (45) Toteutus 1a ja 1b tehtävät Työpanos[h/vko] Yht. Tot. Erot. ID Tehtävän selitys Vastuu [h] [h] [h] DL TO_028 Viikonpalaveri asiakkaalla maanantaisin TO_029 I2a iteraatiodemo mentorille ja asiakkaalle OP_001 Tehtävien tarkentaminen I2b vaiheeseen TO_036 Projektin tavoitteet I2b vaiheeseen PR_004 StructureLoader.java testausta ja muutoksia ALL 7,0 7,0 7,0 7,0 7,0 35,0 31,5 3, ALL 14,0 14,0 16,8-2, JI, KR 4,0 4,0 0,0 4, TH, JI, KR 6,0 6,0 3,0 3, AA, KR 6,0 6,0 6,0 18,0 13,0 5, PR_006 Final report kirjoittelu JI, KR 1,8 1,8 1,8 1,8 7,0 10,0-3, DO_002 Riskienhallintapalaveri PR_009 Vertaisryhmätestauksen suunnittelu PR_007 Vertaisryhmätestauksen toteutus TH, JI, KR 3,0 3,0 1,5 1, TH 12,0 12,0 8,0 4, ML, JW 4,0 4,0 8,0 15,5-7, SU_003 Developer's Guide KR 1,7 1,7 1,7 5,0 20,5-15, TO_001 exceptions\ AA, KR 3,3 3,3 3,3 10,0 18,0-8, COTOOLException.java TO_034 Lisätietosivu servletti TO_037 Ulkoasun toteuttaminen I2b vaiheessa AA, ML AA, PS, JW 2,0 2,0 2,0 6,0 0,0 6, ,3 10,3 10,3 31,0 33,5-2, TO_031 Stringien kielikoodaus ML 7,5 7,5 15,0 14,0 1, IN_002 Palautuspaketti toimitettavasta sovelluksesta ML 3,0 3,0 3,0 0, TO_039 Ylläpitoliittymä ML, JW 50,0 50,0 59,0-9, PR_010 I2b iteraatiodemo ALL 14,0 14,0 7,0 7, TO_009 ReportLoader.java suunnittelu TO_010 ReportLoader.java nappien dynaaminen luonti TO_011 ReportLoader.java raporttien luonti 0,0 0,0 0, ,0 0,0 0, ,0 0,0 0, IN_001 beans\ SVGPicture.java 0,0 0,0 0, PR_002 beans\ SVGPictureAreas.java 0,0 0,0 0, TO_025 SVGLoader.java - 0,0 0,0 0,0 5.3.

47 44 (45) käytetään tod näk. rauinfon omaa image-loaderia. TO_026 commandlineui\ Tester.java 0,0 0,0 0, Yht. 33,2 58,6 124,6 96,8 110,3 70,0 58,7 98,3 14,0 664,5 750,1-85,6 7 Riskienhallinta ja -loki Riskiloki löytyy erillisestä dokumentista riskiloki.

48 45 (45) 8 Viitteet Kaikki internet-viittaukset avautuvat uuteen ikkunaan Cockburn Alistrait, Agile Software Development, Addison-Wesley Pub Co, 2000