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 Riskienhallinta ja -loki Viitteet

4 1 (40) 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 Petteri Hyytiäinen

5 2 (40) 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 Petri Saloma 1.2 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 (40) 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 (40) 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 (40) 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 (40) 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 Rooli Nimi Varahenkilö 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. Arkkitehti Liljavirta, Matti (ML) Rouhiainen, Kimmo (KR) Welin, Jan (JW)

10 7 (40) Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa Rooli Nimi Varahenkilö Yhteystiedot Vastuualueet Taustaa 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. 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 Rouhiainen, Kimmo (KR) Liljavirta, Matti (ML) krouhiai#cc.hut.fi SVG/DXF-formaatit ja niiden väliset konversiot. Myöhemmin valittavien sovelluskomponenttien toteuttaminen. 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. 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ä

11 8 (40) 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 (40) 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 (40) 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 Rouhiainen, Kimmo 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. Tavoitteenani on oppia järjestelmällistä ohjelmistokehitystä, oppia entistä parempi ja

14 11 (40) Silvekoski, Pekka Welin, Jan 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.

15 12 (40) 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 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 pyritään pitämään mahdollisimman pitkälle 190h/hlö (170h + 20h SEPAsta). Resurssimatriisi PP Toteutus1a Toteutus1b Toteutus2 Yht. Henkilö Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. Suun. Tot. AA ,3 26,2 65,3 38, ,2 JI , ,5 43,5 58, JW ,3 23,5 70,5 20, KR , ML , , ,5 PS ,8 38, , ,5 TH 49 51, ,5 22,5 11,5 93, Yht ,5 329,9 236,2 362,8 196,6 761, ,3

16 13 (40) Alla olevassa kuvaajassa näkyy kirjoitushetkeen asti suunnitellut ja toteutuneet kumulatiiviset tunnit. Kuten kuvaajasta näkyy, kaikkia resursoituja tunteja ei ole käytetty. Tähän johtaneita ongelmia on pohdittu riskilokissa. 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 (40) 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 (40) 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 (40) 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 (40) 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. Löydettyjen virheet raportoidaan kurssin tarjoamalla Bugzillalla. 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,ML Rajapinnat Katselmointi JI,ML 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 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.