T2-vaiheen edistymisraportti Kuopio
Kuopio, T2-vaiheen edistymisraportti, 12.2.2002 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 11.2.2002 Ossi Jokinen Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 2
SISÄLLYSLUETTELO 1. PROJEKTIN TILA... 5 2. SUORITETUT TEHTÄVÄT... 7 3. KÄYTETYT MENETELMÄT... 8 3.1 VAATIMUSMUUTOSTEN HALLINTA... 9 3.2 VERSIONHALLINTA CVS 1.11 OHJELMISTON AVULLA... 10 3.2.1 Käyttöönotto... 10 3.2.2 Ensivaikutelma... 10 3.2.3 Konflikti... 10 3.2.4 Tulokset... 10 3.3 KOODIKATSELMOINNIT... 10 3.3.1 Käytännön toteutus Henkilöt-osakokonaisuudessa... 11 3.3.2 Käytännön toteutus Asiakkaat-osakokonaisuudessa... 11 3.3.3 Löydetyistä eroavaisuuksista... 11 3.3.4 Yhteenveto ja jatkosuunnitelmat... 12 3.4 RASITUSTESTAUS CENTERTEST.NET TYÖKALUN AVULLA... 12 3.4.1 Toteutuksen ajankohta... 12 3.4.2 Turvallisuusnäkökohtia... 13 3.4.3 Vastatut pyynnöt aikayksikössä yhteyksien funktiona... 13 3.4.4 Tiedonsiirtoaika yhteyksien funktiona... 13 3.4.5 Virheanalyysi ja lopulliset tulokset... 13 3.4.6 Puutteet... 14 3.4.7 Yhteenveto...14 3.5 MONIKERROSARKKITEHTUURI... 14 3.5.1 Vaatimukset... 14 3.5.2 Puutteita... 15 3.5.3 Yhteenveto ja jatkosuunnitelmat... 15 3.6 PROJEKTIN TUNTIENSEURANTA... 15 3.7 PROJEKTIN RISKIEN HALLINTA... 16 4. ONGELMAT...17 Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 3
TAULUKOT Taulukko 1 Kertyneet ja arvioidut tunnit henkilöittäin sekä vaiheittain...5 Taulukko 2 Vaiheiden testitapaus- ja virhemäärät...6 Taulukko 3 T1-vaiheen toteutuksesta löydettyjen virheiden vakavuudet...6 Taulukko 4 T2-vaiheessa löydettyjen virheiden vakavuudet...6 Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 4
1. PROJEKTIN TILA Projektille allokoitiin tähän vaiheeseen 320 tuntia, joista käytettiin 270. Tämä aiheutti pieniä puutteita suunniteltuihin vaiheessa saavutettaviin tuloksiin. Syyt poikkeamille on esitetty kappaleessa 4. Ongelmat. Poikkeamat on kuvattu kappaleessa 2. Suoritetut tehtävät. Projektiteknisesti projekti on hallitusti hieman myöhässä. Tämä tarkoittaa sitä että aivan kaikkea mitä oli tarkoitus ei saatu tehtyä. Tosin edellisessä vaiheessa tekemättä jäi enemmän, joten suunnitelma saatiin jo lähes kiinni. Siirretty tehtävä on Asiakkaatosakokonaisuuden matalimman prioriteetin testitapausten testaus. Testitapaukset ehdittiin kuitenkin laatia. Tämä olisi arviolta vaatinut 10 tunnin lisätyön. Projekti olisi siis saavuttanut sille asetetut tavoitteet arviolta 10 lisätunnilla, joka tarkoittaa sitä että se olisi alittanut sille budjetoidut tunnit 40 tunnilla. Tehokkuus on siis ollut kohdallaan ongelmana on ollut enemmänkin resurssien saatavuus johtuen projektin ulkopuolisesta resursoinnista sekä aikataulun kireys. Projektiin on tällä hetkellä käytetty resursseja 742.5 tuntia alun perin suunnitellusta 1400 tunnista. Tämä on liian vähän sillä alkuperäinen tavoiteltu arvio oli noin 900 tuntia. Arvion alittaminen ei sinänsä ole ongelma, sillä näyttäisi siltä, että kaikki sovittu saadaan tehtyä hieman pienemmällä tuntimäärällä. Lisäksi on mahdollisuus jopa hieman ylittää alkuperäiset tavoitteet, mutta tämä varmistuu vasta seuraavassa vaiheessa. Järjestelmäähän ei ollut tämän projektin puitteissa tarkoitus tehdä loppuun asti valmiiksi, joten toteutettavia lisäkokonaisuuksia on helppo ottaa lisää mukaan projektiin. Projektin resurssitaulukko on nyt päivitetty vastaamaan projektipäällikön realistisia ajatuksia tulevasta resurssin käytöstä. Enää mukaan ei ole sisällytetty tavoitteita, joihin pääseminen vaikuttaa epätodennäköiseltä. Seuraavassa taulukossa on esitetty tuntien kertyminen henkilöittäin ja vaiheittain sekä arvio tulevista kertymistä: Taulukko 1 Kertyneet ja arvioidut tunnit henkilöittäin sekä vaiheittain Wesa Aapro Ossi Jokinen Rami Laiho Mikko Lampi Matti Peltomäki Lasse Tolvanen Matias Ärje Yhteen sä PS 12 109 12 65 6 10 5 219 T1 55 39 15 16 30 55 3 213 T2 26 25 18 34 87 40 40 270 T3 57 25 30 50 40 50 60 312 LU 50 22 25 35 37 45 32 246 Yhteen sä 200 220 100 200 200 200 140 1260 Taulukosta nähdään tehdyn työn painottuminen hyvin eritavoin eri henkilöiden kesken. Tämä on ongelma, jota on analysoitu tarkemmin kappaleessa 4 Ongelmat. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 5
Suunnitellun ja toteutuman välinen ero oli siis hyvin pieni kaikessa muussa kuin resurssimielessä. Seuraaville vaiheille budjetoidut resurssit vaikuttavat realistisilta ja edellisten vaiheiden perusteella voi päätellä että niillä saadaan toteutettua kaikki mitä on alun perin suunniteltu. Projekti on siis oikein hyvin hallinnassa. Taulukossa 2 on esitetty vaiheiden testitapaus- ja virhemäärät. Tässä vaiheessahan testattiin myös edellisen vaiheen tuotosta. Taulukko 2 Vaiheiden testitapaus- ja virhemäärät Vaihe Testitapauksia Virheitä Hyväksyttyjä T1 96 22 74 T2 105 7 98 Kuten taulukosta nähdään, virheitä on löytynyt noin 10% testitapauksista. Tämä kertoo testitapausten suunnittelun olleen onnistunutta (tai ohjelman laadun huonoa). Testaushan tehtiin vasta koodikatselmointien jälkeen. Koodikatselmoinnit löysivät virheitä myös varsin tehokkaasti. Onkin syytä olettaa, että testaus on ollut onnistunutta ja ohjelman virheiden määrä korjausten jälkeen riittävän vähäinen. Testaus on projektissa edennyt hyvin ja sitä jatketaan seuraavissa vaiheissa samaan malliin. Löydettyjen virheiden vakavuusluokittelu Buranan määräämiin luokkiin on esitetty seuraavissa taulukoissa. Taulukko 3 T1-vaiheen toteutuksesta löydettyjen virheiden vakavuudet Vakavuusluokitus Virheiden määrä Urgent - High - Before Release 7 Semilow 4 Low 9 Taulukko 4 T2-vaiheessa löydettyjen virheiden vakavuudet Vakavuusluokitus Virheiden määrä Urgent 1 High 1 Before Release 4 Semilow - Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 6
Vakavuusluokitus Virheiden määrä Low 1 Kuten taulukoista nähdään, ei T1-vaiheessa löydetty ollenkaan kriittisiä virheitä. T2- vaiheessa niitä löydettiin pari. Myös tämä vahvistaa päätelmän ohjelmoinnin ja ohjelman laadusta. T2-vaiheeseen saattaa tosin tulla muutama matalamman prioriteetin virhe kun loppuja testejä ajetaan seuraavan vaiheen alussa. mutta tämä ei muuta kokonaiskuvaa mihinkään. Ohjelmiston koko koodiriveinä oli T1-vaiheen toteutuksen jälkeen 2100 riviä. Nyt T2- vaiheen toteutuksen jälkeen ohjelmiston koko on 3400 riviä koodia. Vauhti siis tässä mielessä on hieman hidastunut mikä on aivan normaalia ja odotettua, sillä T1-vaiheessa jouduttiin koodaamaan Henkilöt-osakokonaisuuden lisäksi myös koko järjestelmän alusta. Asiakasyhteistyö on sujunut hyvässä yhteisymmärryksessä. Ongelmista puhutaan ja niihin mietitään yhdessä ratkaisuja. Valittamista tällä saralla ei ole. 2. SUORITETUT TEHTÄVÄT Tämän vaiheen aikana ryhmä on saanut aikaan seuraavat kokonaan uudet palautettavat dokumentit: Testitapausluettelo Henkilöt osakokonaisuus Testitapausluettelo Asiakkaat osakokonaisuus Testiloki Henkilöt osakokonaisuus Testitapausloki Asiakkaat osakokonaisuus Testiraportti Henkilöt osakokonaisuus Testiraportti Asiakkaat -osakokonaisuus Käyttöohje Lisäksi ryhmä on päivittänyt seuraavia dokumentteja: Projektisuunnitelma: kappaleet 7, 8, 11 Projektisuunnitelma (MS Project) Laatukäsikirja: kappale 5.3 Vaatimusmäärittely: päivitetty vaatimusmuutosten osalta kappaleet: 3.1.8, 3.1.12, 3.1.6, 3.3.3 Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 7
Toiminnallinen määrittely: muutosten ja Asiakkaat osakokonaisuuden päivitys Tekninen määrittely: muutosten ja Asiakkaat osakokonaisuuden päivitys Tämän lisäksi ryhmä on saanut valmiiksi uuden demon ohjelmasta, jossa on toteutettu henkilöt- sekä asiakkaat-osakokonaisuudet kuten oli suunniteltu. Testauksessa tehtiin heti vaiheen alussa edellisessä vaiheessa toteutetun Henkilöt osakokonaisuuden testaus. Lisäksi vaiheen lopussa suoritettiin tässä vaiheessa toteutetun Asiakkaat osakokonaisuuden testaus. T2-vaiheessa saatiin kaikki muu toteutettua suunnitelmien mukaan lukuun ottamatta testausta, josta tehtiin suurin osa, mutta ei aivan kaikkea mitä oli tarkoitus. Testauksessa jouduttiin jättämään testaamatta Asiakkaat osakokonaisuuden alimman prioriteettitason testitapaukset. Nämäkin testitapaukset ehdittiin kuitenkin suunnitella. Testitapaukset ajetaan T3-vaiheen alussa, jonka jälkeen löydetyt virheet korjataan. Samaan aikaan tehdään seuraavan vaiheen vaatimusmuutoskierros, jonka vaatimat muutokset otetaan huomioon seuraavan vaiheen varsinaisen suunnittelun alkaessa heti näiden tehtävien jälkeen. Merkittävin muutos aikaisemmin tehtyihin suunnitelmiin oli asiakkaan kanssa tehty päätös Matias Ärjen resurssien kohdentamisesta kalenterimoduuliin. Tämä tehtiin asiakkaan pyynnöstä. Muutos katsottiin mahdolliseksi, sillä näyttäisi siltä, että ryhmä selviää ilman Matiaksen panosta seuraavan vaiheen Projektit-osakokonaisuuden toteuttamisesta. Tarkoitus on siis ylittää projektin alkuperäiset tavoitteet integroimalla kalenterimoduuli järjestelmään seuraavassa vaiheessa. 3. KÄYTETYT MENETELMÄT Vaiheen aikana käytettiin seitsemää ohjelmistotuotannon menetelmää, joista raportoidaan tässä kappaleessa kurssin vaatimusten mukaisesti: Vaatimusmuutosten hallinta Versionhallinta CVS 1.11 ohjelmiston avulla Koodikatselmoinnit Rasitustestaus CenterTest.NET työkalun avulla Kolmikerrosmalli Projektin tuntienseuranta Projektin riskien hallinta Kaikkia edellisiä lukuun ottamatta CenterTest.NET rasitustestaustyökalua jo käytettiinkin T2-vaiheessa. Rasitustestausta tehdään vasta seuraavassa vaiheessa CenterTest.NET työkalun avulla. Tässä vaiheessa työkaluun tutustuttiin ja sen käyttöä harjoiteltiin. Työkalu oli kaikille ryhmän jäsenille aidosti uusi, joten tutustuminen oli jo Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 8
itsessään suuri osa menetelmää. Myös tutustumisesta CenterTest.NET työkaluun raportoidaan tässä menetelmäraportoinnin merkeissä. Seuraavan vaiheen käyttökokemuksien perusteella asiakkaan on tarkoitus tehdä päätös CenterTest.NET työkaluun käyttöönotosta myös muissa projekteissaan. Menetelmäksi Kuopio-projektiin se otettiin osaksi juuri tämän seikan takia. 3.1 Vaatimusmuutosten hallinta Kuopio-projektin vaatimusmuutosten hallintaan tarkoitettu menetelmä otettiin käyttöön T2-vaiheen alussa. Menetelmästä vastaa Mikko Lampi. Tammikuun alussa pidettiin asiakkaan kanssa palaveri, jossa hän esitteli muutosehdotuksensa ja näiden prioriteetit. Tähän kokoukseen osallistui asiakkaan lisäksi projektiryhmän jäseniä. Kokouksen päämääränä oli kerätä talteen asiakkaan muutosehdotukset ottamatta niihin tässä vaiheessa vielä mitenkään kantaa. Kokouksen jälkeen pidettiin projektiryhmän sisäinen palaveri, jossa käytiin jokainen muutosehdotus yksityiskohtaisesti läpi. Tämä tapahtui siten, että ensimmäiseksi muutosehdotus esitettiin, sitten jokainen sai mahdollisuuden kommentoida sitä, ja lopuksi siitä kirjattiin päätösehdotus. Ennen päätöksen tekoa tutkittiin mm. sen vaikutuksia projektin aikatauluun, toteuttamisen mahdollisuutta tekniseltä kannalta, vaikutuksia käyttöliittymään jne. Jokaisesta muutosehdotuksesta tehtiin päätösehdotus. Nämä ehdotuksen hyväksytettiin asiakkaalla ja sen jälkeen dokumentteihin tehtiin tarvittavat muutokset. Yllä kuvattu prosessi todettiin hyväksi varsinkin sen takia, että siinä ei tarvitse antaa välitöntä vastausta asiakkaalle jonkin muutoksen vaikutuksista muuhun projektiin eikä sen teknisestä toteuttamisesta. Välittömien vastausten antaminen muutosehdotuksiin jo tämän kokoluokan projekteissa on erittäin riskialtista. Tämä menettely on myös asiakkaan edun mukaista, koska hän saa tarkempaa tietoa sen vaikutuksista esim. projektin aikatauluun. Tämän menetelmän soveltamisesta oli jo tässä vaiheessa konkreettista hyötyä: Eräs asiakkaan ehdottama vaatimusmuutos käsitteli tietyn osakokonaisuuden prioriteetin nostamista siten, että se olisi mahdollista ottaa käyttöön aikaisemmin. Tämä muutos vaikutti aluksi yksinkertaiselta, tehdään se vain ennen muita osioita. Tarkemman tutkimisen jälkeen havaittiin kuitenkin, että tämän osakokonaisuuden järkevä käyttö osana järjestelmää vaatii muiden osakokonaisuuksien tekemisen ensin. Ilman muutosprosessia tämä asia olisi huomattu luultavasti liian myöhään. Prosessin avulla saatiin muutoksista tehtyä tarkat aika- ja resurssiarviot. Tämä helpotti huomattavasti projektin jatkon suunnittelua. Prosessi pitää huolen siitä, että asiakas ei pääse vaatimaan liikaa. Vaatimuksilla on aina hintansa. Muutoksen vaikutukset projektiin kerrottiin asiakkaalle, jonka jälkeen asiakas päätti onko muutos todellakin kustannusten arvoinen. Prosessista löydettiin myös parannettavaa. Tässä vaiheessa vaatimusmuutosehdotusten käsittely on hoidettu kerran vaiheen alussa. Nyt todettiin kuitenkin, että näitä kokouksia Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 9
tulisi jatkossa pitää useammin. Päädyttiin siihen tulokseen, että vaatimusmuutospalaveri pidetään aina, kun asiakas tai projektiryhmä näkee sen tarpeelliseksi. T3-vaiheen alkuun on jo tulossa seuraava muutospalaveri ja mahdollisesti ennen vaiheen loppua pidetään vielä toinen palaveri. 3.2 Versionhallinta CVS 1.11 ohjelmiston avulla 3.2.1 Käyttöönotto Käyttöönotto toteutettiin menetelmän vastaavan, Lasse Tolvasen, sekä Mikko Lammen johdolla. Asentaminen asennusohjeiden mukaan sujui melko kivuttomasti. Muutamia konffauksia Cvs-palvelimelle oli kuitenkin tehtävä ennen ohjelmiston saamista toimivaksi. Käyttöohjeisiin ja wincvs-ohjelmaan tutustumisen jälkeen oli Cvs:n perusidea hyvin selvillä. Ainakin tähän projektiin tarvittavat toiminnot olivat hallussa. Ensimmäinen testaus ohjelmiston lataamisesta ja päivittämisestä onnistui mainiosti. 3.2.2 Ensivaikutelma 3.2.3 Konflikti 3.2.4 Tulokset Muutaman tunnin käytön jälkeen Wincvs tuntui jo erittäin luontevalta. Tiedostojen latailu ja päivittäminen sujui kuin vettä vain. Heräsi kysymys miksei menetelmää oltu otettu käyttöön aikaisemmin muissa projekteissa. Heräsi myös mielenkiinto käyttää ohjelmaa haastavammassa eri tuotteiden tuoteversioiden hallintatoiminnassa. Vapauttavin tunne oli se, ettei omat virheet ja keskeneräiset ohjelmat haitanneet muiden työskentelyä. Syntyi ensimmäinen konflikti. Kaksi ohjelmoijaa oli muokannut saman tiedoston samaa kohtaa. Wincvs valitti välittömästi yrittäessäni päivittää tiedostoa. Ohjelma listasi ehkä hieman epäselvästi mutta loogisesti mitä tiedostossa oli muokattu ja mikä aiheutti konfliktin. Mielestäni väreillä olisi saanut konfliktitilanteen selvemmin esille, mutta hyvin konfliktin korjaaminen sujui näinkin. Cvs tuntuu tämän vaiheen kokemuksien perusteella erittäin pätevältä versionhallintajärjestelmältä. Suurin hyöty minun näkökulmasta oli se, että jokainen ohjelmoija sai tehdä vapaasti koodia välittämättä muista. Toki käytössä menee hieman enemmän aikaa, mutta se maksaa varmasti itsensä takaisin kun sattuu pahoja kommelluksia eri versioiden ja päällekkäisyyksien kanssa. Toinen saavutettu hyöty on eri versioiden helppo julkaiseminen esimerkiksi kehitys- demo tai tuotantopalvelimille. 3.3 Koodikatselmoinnit Kuopio-projektissa kokeiltiin koodikatselmointeja. Menetelmä oli koko ryhmälle aidosti uusi. Siitä oli kuitenkin ollut runsaasti keskusteluja ryhmän keskuudessa jo ennen Kuopio-projektin aloittamista ja ryhmällä oli kiinnostusta koodikatselmointeihin. Ohjelmatyökurssi tarjosi varsin hyvän alustan kiinnostusta herättäneen menetelmän kokeiluun käytännössä. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 10
Menetelmän käyttöönotosta ja kokeilusta vastaavana henkilönä toimi testausvastaava Matti Peltomäki. Kehysajatukset koodikatselmoinnista kirjattiin projektin laatukäsikirjaan jo PS-vaiheessa. Katselmointi toteutettiin käytännössä niiden mukaisesti. 3.3.1 Käytännön toteutus Henkilöt-osakokonaisuudessa Henkilöt-osakokonaisuuden koodi katselmoitiin tammikuun alussa. Katselmoijana toimi Matti Peltomäki; lisäksi formaaliin katselmointipalaveriin osallistui pääohjelmoija Lasse Tolvanen. Katselmoija tulosti koodin paperille ja tutustui siihen huolellisesti ennen katselmointia. Tämän vaiheen kesto oli noin viisi tuntia. Formaalissa katselmointipalaverissa katselmoija ja pääohjelmoija kävivät läpi katselmoinnissa löytyneet eroavaisuudet tekniseen ja toiminnalliseen määrittelyyn sekä potentiaaliset virhekohdat. Löytyneistä seikoista kirjoitettiin myöhemmin puhtaaksi luettelo, joka toimitettiin pääohjelmoijalle virheiden korjaamista varten. 3.3.2 Käytännön toteutus Asiakkaat-osakokonaisuudessa Asiakkaat-osakokonaisuuden koodi katselmoitiin helmikuun alussa. Katselmoijina toimivat Matti Peltomäki, Mikko Lampi ja Rami Laiho. Katselmoijat tulostivat koodin paperille ja tutustuivat siihen. Tähän vaiheeseen kulunut aika vaihteli katselmoijakohtaisesti. Keskiarvoksi muodostui noin kolme tuntia. Formaalissa katselmointipalaverissa mukana oli lisäksi asiakkaan edustaja. Palaverissä käytiin katselmoijien löytämät eroavaisuudet määrittelyihin nähden ja potentiaaliset virheet läpi kohta kohdalta, ja ne kirjattiin ylös. Asiakkaat-osakokonaisuuden korjattavien asioiden listasta muodostui huomattavasti pidempi kuin Henkilötosakokonaisuudessa. Menetelmävastaava kirjoitti listan puhtaaksi ja toimitti sen toisen katselmoijan tarkistuksen jälkeen pääohjelmoijalle virheiden korjaamista varten. Kummankin osakokonaisuuden formaalikatselmointi kesti noin kaksi tuntia. 3.3.3 Löydetyistä eroavaisuuksista Koodikatselmoinnissa löydettyjä eroavaisuuksia oli muutamaa päätyyppiä: selkeitä ristiriitoja toiminnalliseen määrittelyyn (mm. epähuomiossa puuttumaan jääneitä toiminnallisuuksia), ristiriitoja tekniseen määrittelyyn (vähäisiä luokka- ja metodirakenteen eroavaisuuksia), sekavaa koodia ja monikielituen ohjelmoinnin laiminlyöntiä. Ristiriidat toiminnalliseen ja tekniseen määrittelyyn nähden olivat varsin selkeitä ja niistä oltiin yksimielisiä. Teknisen määrittelyn ristiriitojen korjaustavasta kuitenkin keskusteltiin formaaleissa palavereissa. Osa poikkeamista päätettiin korjata hienosäätämällä määrittelyä, osa muuttamalla koodia. Eroavaisuuksia, etenkin monikielitukeen liittyviä, karakterisoi usein se, että ohjelmoijat olivat tietoisia eroavaisuuksien olemassaolosta, eikä katselmointi siis suoranaisesti tuottanut uutta tietoa. Havaittiin kuitenkin hyödylliseksi, että eroavaisuuksista syntyy koodikatselmoinnin tuloksena luettelo, jonka avulla kaikkien tarpeellisten korjausten Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 11
tekeminen ja hallinta on helpompaa. Lisäksi ohjelmoijille syntyy terveitä paineita korjata löydetyt eroavaisuudet. Koodin kommentointi oli molemmissa osakokonaisuuksissa olematonta. Katselmoijat olivat yksimielisesti sitä mieltä, että kommentointia täytyy ehdottomasti lisätä jatkossa. Löytyneiden eroavaisuuksien kokonaismäärä Henkilöt-osakokonaisuudessa oli 11, Asiakkaat-osakokonaisuudessa 28. 3.3.4 Yhteenveto ja jatkosuunnitelmat Kuopio-projektissa koodikatselmointikäytäntöä tullaan jatkamaan projektin loppuun asti. Vaiheessa T3 tullaan katselmoimaan ainakin Projektit-osakokonaisuuden koodi - mahdollisesti myös muita moduuleita. Koodikatselmointikäytäntö on osoittautunut tehokkaaksi ja mielekkääksi ohjelmistotuotannon menetelmäksi. Sen suurin etu järjestelmää toteuttavaan testaukseen verrattuna on se, että se mahdollistaa virheiden löytämisen lisäksi hyvien ja yhdenmukaisten ohjelmointitapojen noudattamisen valvomisen. Se on myös havaittu varsin tehokkaaksi testausmenetelmäksi, sillä virheitä on löytynyt tehokkaasti. Kaiken tämän lisäksi koodikatselmointi on hyvin mielekäs testauksen muoto, sillä se tarjoaa käyttäjilleen oppimiskokemuksia, joita perinteisessä testauksessa ei tule. Näin ollen menetelmä on motivoiva tapa testaukseen niin sen toteuttajille kuin yrityksellekin, niin sen tehokkuus ja hyötymielessä kuin yksilön ja yrityksen tietopääoman kasvun mielessä. Näiden positiivisten käyttökokemusten vuoksi asiakas parhaillaan suunnittelee koodikatselmointien käyttöönottoa myös muissa projekteissaan. 3.4 Rasitustestaus CenterTest.NET työkalun avulla CenterTest.NET on Microsoftin integroidun kehitysympäristön Visual Studion.NETversion osa. CenterTest on suunniteltu erityisesti www-sivustojen testaukseen. Se on yhteensopiva virtuaalisesti minkä tahansa www-palvelinohjelmiston kanssa, mutta se on suunniteltu erityisesti ASP.NET-sovelluksia silmälläpitäen. CenterTest on Kuopio-projektissa kokeiltava testauksen aputyökalu. Se on koko projektiryhmälle aidosti uusi. Projektissa CenterTestin ominaisuuksista käytetään mahdollisuutta sivustojen rasitustesteihin, joita CenterTestiin voi ohjelmoida HTTPpyyntökohtaisesti. Muita CenterTestin ominaisuuksia ei resurssipuutteen vuoksi voida ohjelmatyöprojektissa kokeilla. 3.4.1 Toteutuksen ajankohta CenterTest valjastetaan todelliseen käyttöön projektin todellisen etenemisen mukaan vaiheessa T3 tai LU, jolloin sitä käytetään tuottamaan realistisia tunnuslukuja järjestelmän rasituksensietokyvystä. Testausvastaava on vaiheen T2 aikana tutustunut huolellisesti ja kattavasti CenterTestin mahdollisuuksiin ja ominaisuuksiin. CenterTestin käyttö suunnitellaan testitapauksen tarkkuudella järjestelmätestauksen testitapausten luonnin yhteydessä vaiheessa T3. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 12
3.4.2 Turvallisuusnäkökohtia CenterTestin rasitustestien tarkoituksena on aiheuttaa keinotekoisesti www-palvelimelle määrätyn suuruista kuormaa ja samalla tarkkailla yhdeltä tai usealta työasemalta käsin verkon ja palvelimen kuormitusta. Tällainen kuormitus rasittaa suuresti verkkoa, jossa testaus tapahtuu. Tämän vuoksi rasitustestit tehdään sellaiseen vuorokaudenaikaan, jolloin muu liikenne Innofactorin sisäisessä verkossa on pienimmillään. Näin pyritään varmistamaan, että rasitustestit eivät aiheuta huomattavaa haittaa muulle liiketoiminnan kannalta oleelliselle tietoliikenteelle. 3.4.3 Vastatut pyynnöt aikayksikössä yhteyksien funktiona Ensimmäinen rasituksesta tutkittava asia on vastatut pyynnöt yhteyksien funktiona. Tähän liittyy myös olennaisesti TCP- ja HTTP -virheiden määrä pyyntöä kohden yhteyksien funktiona. Näitä asioita tutkitaan peräkkäisillä samanlaisilla testeillä, joissa samanaikaisesti otettavien yhteyksien määrää nostetaan tietyn kaavan mukaisesti, esimerkiksi 1,2,4,8,16,... Tuloksista piirretään graafi. Tämä onnistuu CenterTestin toiminnoilla. Graafi on luonnollisesti murtoviiva, jonka muodoksi saadaan tiettyyn pisteeseen c asti nouseva käyrä ja pisteen c jälkeen laskeva käyrä. Pisteeseen c muodostuu siis globaali maksimi, jonka tulkitaan esittävän tässä mielessä optimaalista yhtäaikaisten yhteyksien määrää. Tulokset tulkitaan siten, että kun yhteyksien määrä on c tai pienempi, palvelimen suorituskyky on tarpeeksi niin suuri, että järjestelmälle ei aiheudu ongelmia. Samaan graafiin piirretään myös TCP- ja HTTP virheiden määrä yhteyksien lukumäärän funktiona. Erityisesti HTTP-virheitä aiheutuu, kun palvelin on siinä määrin kuormittunut, että se ei voi vastata kaikkien pyyntöihin. Odotettavissa on, että virheiden määrä kasvaa yhteyksien määrän funktiona. Virheiden määrän ja pyyntöjen määrän erotus on onnistuneiden pyyntöjen määrä. Kun erotus menee pieneksi, muuttuu järjestelmä kuormituksen vuoksi käyttökelvottomaksi. Joissain tapauksissa tämä voidaan ottaa silmämääräisesti huomioon c:n arvoa laskevana tekijänä. 3.4.4 Tiedonsiirtoaika yhteyksien funktiona Toinen rasituksesta tutkittava asia on tiedon siirtämiseen kuluva aika yhteyksien funktiona. Tässä yhteydessä tiedon siirtämisellä tarkoitetaan pyynnön lähettämisestä viimeisen tavun perille saapumiseen kuluvaa aikaa (TTLB = Time To Last Byte). Testaus suoritetaan useana peräkkäisenä CenterTestin testinä, joissa vaihdellaan yhtäaikaisten yhteyksien määrää esimerkiksi jonon 1,2,4,8,... mukaisesti. Tuloksista piirretään graafi CenterTestin toimintojen avulla. Odotettavissa oleva graafin muoto on tiettyyn rajapisteeseen c asti lineaarinen ja pisteen c jälkeen eksponentiaalisesti kasvava. Tulokset tulkitaan siten, että jos yhteyksien määrä on c tai pienempi, palvelimen suorituskyky on riittävä sovelluksen ajamiselle. 3.4.5 Virheanalyysi ja lopulliset tulokset Kahdessa edellisessä luvussa laskettiin yhtäaikaisten yhteyksien määrälle raja-arvo c. Lopullinen tulos muodostetaan pienempänä näistä kahdesta c:n arvosta ja siihen Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 13
3.4.6 Puutteet 3.4.7 Yhteenveto liittyvästä virhearvioinnista. Kevyeen virhearviointiin päästään suorittamalla edellä kuvattuja testisarjoja toistokokeena. CenterTest tarjoaa mahdollisuuden testata sivustoja kuormituksen lisäksi toimivuuden suhteen. Tällainen testaus edellyttää kuitenkin testitapausten laadintaa Visual Basic.NET skriptikielellä. Arvioitu työmäärä on yli tunti testitapausta kohden, ja tulosten luotettavuuden varmistamiseksi tarvitaan lisäksi manuaalista testausta. Näistä syistä ja resurssien vähyyden vuoksi testausta CenterTestillä toiminnallisuuksien suhteen ei toteuteta ohjelmatyöprojektissa. CenterTest laskee testiaineistoista testiajokohtaisesti tilastollisia tunnuslukuja, kuten diskreetin aikakeskiarvon pyyntöjen määrästä aikayksikköä kohden. Saatavien erilaisten tunnuslukujen määrä on kuitenkin varsin rajoitettu. Esimerkiksi testiajokohtaista tai edes kaikkien testiajojen yli laskettua keskihajontaa diskreetin ajan suhteen CenterTest ei laske. Tämä asettaa rajoituksia virheanalyysille, mikä joudutaan tästä syystä tekemään pelkästään toistokokeisiin perustuen. Vaiheessa T2 tutkittiin mahdollisuutta käyttää CenterTest.NET sovellusta testauksen aputyökaluna. Päätettiin, että CenterTest sopii Kuopio-projektin tarpeisiin parhaiten sovelluksen ja sitä ajavien palvelimien suorituskyvyn mittaukseen. Projektiryhmä tulee käyttämään CenterTestiä käytännössä vaiheessa T3, tai viimeistään vaiheessa LU. 3.5 Monikerrosarkkitehtuuri 3.5.1 Vaatimukset Kuopio projektissa on tarkoitus käyttää monikerrosarkkitehtuuria, jotta järjestelmästä saadaan modulaarinen ja skaalautuva ja se on helppo integroida muihin järjestelmiin. Monikerrossovellusten tekoon on vasta viime aikoina alkanut tulla kunnon sovellus kehittimiä, joista uusimpana Kuopiossa käytetty Microsoftin.Net Framework. Monikerrosarkkitehtuuri on ylevä tavoite, jonka toteuttaminen aivan täydellisesti ei useissa tapauksissa ole järkevin ja kustannustehokkain vaihtoehto. Se antaa kuitenkin suuntaviivat arkkitehtuurille eikä niistä ei tulisi poiketa kuin harkitusti ja perustellen. Jotta projekti Kuopio olisi aidosti monikerrosarkkitehtuurin mukainen, tulisi siinä olla ainakin selkeät data-, toiminta- ja käyttöliittymäkerrokset. Näiden lisäksi voi olla myös muita kerroksia mikäli näille ilmenee tarvetta tai mahdollisuuksia niiden toteuttamiseen. Kukin kerros tulisi olla erillinen kokonaisuus, johon pystytään tarvittaessa tekemään helposti oma rajapinta ja se voidaan siirtää eri palvelimelle tai arkkitehtuurille. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 14
3.5.2 Puutteita Koodikatselmoinnissa ilmeni että aivan kaikki tietokannankäsittely ei ole sijoitettuna data-kerrokseen, mutta näiden toimintojen siirto oikeaan paikkaan on mahdollista ja eikä vaadi kovin suurta työtä. Käyttöliittymää ja käyttöliittymän toiminallisuutta ei ole eroteltu. Tätä ei välttämättä kolmikerrosmallin mukaisessa arkkitehtuurissa tarvita, mutta ohjelmiston tuotteistamisen ja ulkoasun sekä käyttöliittymän helpon muunneltavuuden kannalta tämä olisi varsin perusteltua ja järkevää. Toiminnallinen kerros ei ole täysin yhtenäisenä sillä se sisältää muutamia toimintoja jotka kuuluisivat data-kerrokseen. Se on myös varsin tiiviisti liitettynä käyttöliittymä kerrokseen, joten näiden erottamisessa ja määrittelyssä on jonkin verran tehtävää. 3.5.3 Yhteenveto ja jatkosuunnitelmat Monikerrosarkkitehtuuri on Kuopiossa varsin hyvällä alulla. data ja data yhteys kerros ovat valmiiksi omina lohkoinaan joten niihin on hyvin helposti tarvittaessa luotava rajapinnat niiden erottamiseksi omiksi tasoikseen. Käyttöliittymä- ja Toiminta-logiikka kerrosten erottaminen täysin omiksi kerroksikseen vaatii jonkin verran työtä. Tähän pyritään kiinnittämään huomiota seuraavassa vaiheessa entistä enemmän. 3.6 Projektin tuntienseuranta Projektin tuntien seurantaa jatkettiin edellisen vaiheen tapaan projektipäällikön johdolla. Lähes reaaliaikainen tuntiensyöttö mahdollistaa projektin tarkan seuraamisen joskin pienehköä ryhmäkurin herpaantumista oli vaiheen kuluessa havaittavissa, jolloin projektipäällikkö joutui hieman ärähtelemään tuntisyötön puolesta. Tällainen raportointisysteemi pakottaa tehtävien tekijät seuraamaan tuntiensa käyttöä ja pohtimaan kuinka kauan tehtävän loppuunsaattaminen vielä kestää. Tällaisessa jo hieman suuremmassa projektissa eri tehtävien etenemisen lähes reaaliaikainen näkyvyys helpottaa huomattavasti projektipäällikön työtä. Arviointisysteemi kehittää myös koodaajien arviointitaitoja, joka on varsin hyödyllistä, sillä hyväksi arvioijaksi ei opi kuin arvioimalla. Projektin pilkkominen pieniksi tehtäviksi parantaa selkeästi projektin hallittavuutta ja tuntiraportointisysteemimme pakottaa siihen. Raportoiduista tunneista voidaan kerätä dataa projektin tuntien kohdistumisesta projektin eri vaiheille, osakokonaisuuksille ja tehtäville. Näiden tietojen perusteella voidaan parantaa tulevien saman tyyppisten projektien työmääräarvioita ja resurssitarpeita. Tämä aspekti on organisaation jatkuvan kehittämisen ja laadun parantamisen kannalta erittäin keskeistä. Yhteenvetona järjestelmän käyttökokemuksista voisi todeta sen olevan koko projektin hallinnan sydän. Ilman tietoa siitä mitä on tehty ja kuinka paljon resursseja tehtävät vielä vaativat on projektin johtaminen hyvin hankalaa (kokemusta on). Kokemukset ovat olleet projektipäällikölle niin myönteisiä, että seuraavaan projektiin ei mielellään lähde ilman tehokasta tuntiraportointisysteemiä. Vastaavan tyyppistä raportointisysteemiä on suunniteltu toteuttavaksi vielä tämänkin projektin tuottamaan järjestelmään tosin ei kuitenkaan ehkä tämän kurssin puitteissa. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 15
Menetelmän käyttöä voisi tehostaa erityisesti kurinalaisemmalla tuntiraportoinnilla sekä tarkemmalla tehtäväsuunnittelulla. Näitä onkin tarkoitus parantaa vielä entisestään seuraavassa vaiheessa. Menetelmästä on projektipäällikön kannalta vaikea nähdä huonoja puolia. Koodaajien mielessä se tietysti on lisätyö ellei heitä ole saatu motivoitua kertomalla järjestelmän hyödyistä. Tämän ei kuitenkaan pitäisi olla kovin hankalaa. Menetelmän suurimpana toiminnallisena puutteena näkisin kuitenkin arviointiaspektin. Arviointi tällaisenaan ei aivan tue PSP-prosessimallin näkemyksiä arvioinninkehittämistoimista. Arviointitaitojen kehittämisessä on oleellista se että tehtävän toteuttaja itse arvioi tehtävän keston juuri henkilökohtaisille ominaisuuksilleen. Tehtävän jälkeen oppimisen kannalta on oleellista verrata arvioitua aika-arviota toteutuneeseen. Tämän jälkeen voi mahdollisesti korjata jo tekemiään seuraavien toteutettavien tehtävien aika-arvioita, ja toistaa prosessia jatkuvasti työnsä lomassa. Tällainen toimintamalli tehostaisi arviointitaitojen kehittymistä entisestään. 3.7 Projektin riskien hallinta Projektin riskien hallintaa jatkettiin vanhaan malliin projektipäällikön johdolla. Prosessi on kuvattu laatukäsikirjassa. Riskien hallinnan kolmannen vaiheen riskienhallintakokouksen tuloksena syntynyt projektin riskitaulukko löytyy projektisuunnitelmasta. Kokemukset riskienhallinnasta ovat varsin neutraalit. Riskejä on sen avulla luultavasti tunnistettu paremmin, ja ehkä myös osattu välttyä niiltä paremmin tunnistettavuuden myötä. Riskejä on kuitenkin myös päässyt toteutumaan menetelmästä huolimatta, joten parantamisen varaa menetelmässä siinä mielessä vielä löytyy tosin täydellisyyttä ei luonnollisesti koskaan saavuteta. Menetelmän suurimmat hyödyt ovat mielestäni siinä, että projektiryhmä ja asiakas saadaan kiinnittämään huomiota riskeihin, sisäistämään sen että niitä esiintyy ja keskittymään niiden ehkäisemiseen. Tästä on oltava hyötyä vaikkei sitä tässä projektissa pystyisikään todistamaan. Asiakkaan sitouttaminen riskienhallintaan aiheuttaa positiivisen psykologisen reaktion: asiakas ei syytä niistä pelkästään toimittajaa vaan ymmärtää myös itse olevansa osavastuussa. Tämä pätee myös koko projektiryhmään. Yhteinen sitoutuminen asiaan aikaansaa yhdessä tekemisen fiiliksen, joka keskittyy ongelmien ratkaisemiseen eikä niistä purnaamiseen. Riskien hallintaan liittyy myös vaatimustenhallinnasta tuttuja positiivisia ilmiöitä, joiden mukaan asiakas ymmärtää paremmin ettei kaikkea voi vaatia, ja sen että kaikella on hintansa. Tällöin asiakaskin ymmärtää paremmin tekemiensä vaatimusten hinnan ja osaa tehdä ratkaisunsa paremmin perustein. Menetelmän hyödyt ovat kuitenkin mielestäni suhteellisen pienet, joten kovin suuria panostuksia en lähtisi projekteissa siihen tekemään. Kevyt projektisuunnitelmassa määritelty prosessi ja muutama riskienhallintakokous ovat varmasti kuitenkin paikallaan kaikissa hieman suuremmissa ja pidemmissä projekteissa. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 16
4. ONGELMAT Osalla ryhmän jäsenistä on ollut ongelmia motivaatiossa ja/tai mahdollisuuksissa järjestää aikaa projektille. Tämä on aiheuttanut vaikeuksia projektin läpiviennissä ja kasvattanut resurssien käyttöä projektin hallintaan (eli pienentänyt projektin tuottavuutta). Tämän lisäksi osa projektiryhmän jäsenistä on joutunut joustamaan toisten vuoksi. Tämä on johtanut siihen, että osa projektiryhmän jäsenistä on käyttänyt projektille allokoiduista resursseistaan jo suuren osan ja toinen osa projektiryhmästä ei vielä ole käyttänyt kuin hieman allokoiduista resursseistaan. Lisäksi enemmän tunteja käyttäneiden tunteet alkavat kuumenemaan kaikkien pitäisi tehdä hommia yhtälailla. Tähän ongelmaan ei kuitenkaan ole näkyvissä ratkaisua; osa ryhmän jäsenistä ei tule tekemään 200 tuntia projektin eteen. Näitä henkilöitä on näillä näkymin kaksi. Toisaalta kyseiset henkilöt ovat ryhmän kokeneimpia ja taitavimpia ohjelmoijia, joten he saavat vähemmässäkin ajassa aikaan paljon. Projektissa on jouduttu hieman joustamaan myös vaiheessa suoritettavista tehtävistä (matalan prioriteetin testauksen osalta), sillä 320:sta vaiheelle budjetoidusta tunnista saatiin käyttöön 270. Koko projektin tuntikertymä ei tule näillä näkymin olemaan 1400 tuntia vaan hieman vähemmän, noin 1250 tuntia. Näillä tunneilla uskotaan kuitenkin saatavan kaikki sovittu toteutettua ja jopa hieman ylimääräistäkin. Ajan järjestäminen projektille ei kuitenkaan pelkästään ole ryhmän jäsenten motivaatiosta kiinni, sillä asiakas on myös pyytänyt projektia pienentämään tässä vaiheessa joidenkin ryhmän jäsenten työtaakkaa, jotta saisi ohjattua heidän työpanostaan toisiin projekteihin. Tässä mielessä tämä lipsuminen suunnitellusta on tapahtunut asiakkaan kanssa yhteisymmärryksessä asiakkaan näin pyytäessä. Tällainen menettely vaikeuttaa projektin toteuttamista huomattavasti ja siitä olisi syytä päästä eroon. Toisaalta harvemmin oikeassakaan elämässä käy niin, että saa projektilleen ennalta määrätyn kiinnitetyn määrän resursseja johon ei projektin kuluessa tule muutoksia. Siinä mielessä tämä projekti antaa hyvin harjoittelua oikean elämän tilanteisiin. Onneksi projektipäällikkö oli varautunut tämän tyyppisiin ongelmiin jo projektia suunnitellessaan, eikä asiakkaalle tullut alussa luvattua liikoja. Asiakkaat meinaan pitävät enemmän positiivisista kuin negatiivisista yllätyksistä. Kuopio2002, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 17