Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu LOPPURAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: Hyväksytty Päivämäärä: 23.04.2001 Tekijä: Katariina Ylinen Kommentit: Hyväksyi: Maaret Pyhäjärvi, Niko Tolvanen
VERSIOHISTORIA Versio Päivämäärä Muutokset Muuttaja 0.1 18.04.2001 Alustava versio Katariina Ylinen 1.0 22.04.2001 Sisäisen katselmoinnin korjaukset tehty Niko Tolvanen 1.1 23.04.2001 Viimeistelty palautukseen Katariina Ylinen
1. JOHDANTO 1 2. PROJEKTIN TAVOITTEET JA NIIDEN TOTEUTUMINEN 2 2.1 RYHMÄN OMAT TAVOITTEET 2 2.2 ASIAKKAAN TAVOITTEET 2 2.3 VAATIMUSMÄÄRITTELYSSÄ TUNNISTETUT TAVOITTEET 5 3. PROJEKTIN KULKU 7 3.1 TYÖMÄÄRÄARVIOT VAIHEITTAIN 8 3.2 TEHTÄVÄJAKO JA TYÖMÄÄRÄT 10 4. JÄRJESTELMÄN VIRHEET 11 4.1 T4 JÄRJESTELMÄTESTAUS 11 4.2 OPPONENTTITESTAUS 11 5. KÄYTETYT MENETELMÄT 12 6. RISKIEN HALLINTA 13 7. ARVIO PROJEKTIN ONNISTUMISESTA 15 7.1 MITÄ OPITTIIN? 15 7.2 MITÄ TEKISIMME TOISIN? 15 8. ARVIO KURSSISTA 16
1. JOHDANTO LiKe-projektin tarkoituksena on luoda TAI-tutkimuslaitoksen KOOKOS-projektin tarpeisiin liiketoiminnan kehityksen tukijärjestelmä, jonka avulla KOOKOS-projektin liiketoiminnan tukemisen materiaalit saadaan käytettäviksi hajautetusti verkon yli. Järjestelmä tukee organisaatioiden työntekijöitä liiketoiminnan kehittämiseen tähtäävissä moninaisissa projekteissa vaiheistetun Kehittäjän karttakirjan polun avulla, ja osaltaan rakentaa KOOKOS-ajatusmaailmaa, jossa jatkuvakin liiketoiminnan kehittäminen on projektoitavaa mitattavuuden ja tavoitteellisuuden saavuttamiseksi. TAI-tutkimuslaitoksen luoman Kehittäjän karttakirjan polun ajatuksena on ohjata käyttäjää luontevasti projektin vaiheesta toiseen ja tarjota tarvittava materiaali projektin eteenpäin viemiseen dokumenttipohjineen ja ohjeineen. Järjestelmän tärkeimpiä vaatimuksia on, että sitä tulee voida käyttää verkon yli ja että monen käyttäjän yhtäaikainen järjestelmän käyttö on tuettua. Tarkempi projektin kuvaus on projektisuunnitelmassa. Järjestelmä on luovutettu asiakkaalle ja asiakas on sen hyväksynyt. Tämä projekti kuului aloittavana osana kolmivuotiseen KOOKOS-projektiin, ja järjestelmän kehitystä jatketaan asiakkaan toimesta seuraavat kaksi vuotta. Asiakkaan tavoitteena on tässä ajassa toteuttaa kaikki määritellyt ja toteuttamatta toistaiseksi jääneet suositeltavat ja lisäominaisuudet sekä SSL-salaus. Asiakas on jo työn aloittanut, mutta tarkkaa tietoa työn etenemisestä ei ryhmällä ole. Järjestelmä lienee ensimmäisellä loppuasiakkaalla vuoden 2002 aikana. Tämän dokumentin tarkoituksena on vetää yhteen projektin vaiheet ja tavoitteet sekä niiden toteutuminen. Tässä dokumentissa käydään läpi projektin tavoitteet, vaiheet ja tuotokset sekä riskienhallinta ja vedetään yhteen projektiryhmän kokemukset vuoden ajalta. 1
2. PROJEKTIN TAVOITTEET JA NIIDEN TOTEUTUMINEN 2.1 RYHMÄN OMAT TAVOITTEET Ryhmän tavoite on alusta saakka ollut luoda asiakkaalle heidän tarpeensa täyttävä järjestelmä noudattaen järjestelmän toteuttamisessa mahdollisimman järkeviä menetelmiä. Ryhmä haluaa toteuttaa järjestelmän kurssin aikataulun ja ohjeellisten työmäärien puitteissa hyvällä arvosanalla. Ryhmän kannalta tavoitteet ovat täyttyneet erinomaisesti. n ja asiakkaan yhteistyö on ollut palkitsevaa, ja sekä asiakkaalta että kurssilta saadut arvosanat ovat olleet hyviä. Suunnitelluissa työmäärissä on pysytty, joskin T3-vaiheen lopussa projektin onnistumiseksi projektiin hetkellisesti panostettiin lähinnä ryhmäläisten samanaikaista aikaa määrää pysyessä kohtuullisena. Erilaisia menetelmiä ja työkaluja on kokeiltu, osaa paremmalla menestyksellä kuin toisia. Menetelmien järkevyyttä pohdittiin sekä jäsenten yksilöllisten tarpeitten että ryhmän tarpeitten kannalta, oppimismahdollisuuksiin keskittyen. 2.2 ASIAKKAAN TAVOITTEET Asiakkaan tärkeimpänä tavoitteena on saada Kehittäjän karttakirjan ominaisuudet ja aineisto hajautetusti useiden käyttäjien käyttöön ilman että käyttäjän koneelle on tarpeen asentaa erillisiä ohjelmistoja. Asiakkaan kymmenen tärkeintä tavoitetta ja niiden tila projektin lopussa on esitetty alla. (Määritelty mittari suluissa) 1. Pakollisiksi määritettyjen käyttötapausten kuvaamien toimintojen toteuttaminen (Prosenttiosuus, joka tällaisista ominaisuuksista on toteutettu) Projektin tuloksena syntynyt järjestelmä toteuttaa pakollisiksi määriteltyjen käyttötapausten kuvaukset. Tarkemmin analysoitaessa järjestelmällä on kuitenkin vaatimuksia, joita ei yksikäsitteisesti ole merkitty vaatimusmäärittelyyn, mutta ne ovat olleet ryhmän ja asiakkaan samoin ymmärtämiä. Vaatimukset ovat välittyneet erityisesti projektin alkupuolella palavereissa ja niitä on kirjattu palaverien pöytäkirjoihin. 2
Loppujen lopuksi järjestelmästä toteutettiin kaikki pakolliset käyttötapaukset sekä yksitoista suositeltavaa käyttötapausta. 2. Suositeltavien ominaisuuksien toteuttamisen helppous (Asiakkaan ja ohjaajan subjektiivinen näkemys ryhmän jatkokehitysehdotuksista) Projektin puitteissa toteutettiin yksitoista suositeltavaa käyttötapausta. Järjestelmä luovutettiin asiakkaalle T4-vaiheen lopuksi ja asiakas on jo aloittanut jatkokehityksen SSL-salauksen toteuttamisesta järjestelmään. Asiakas on saanut järjestelmän asennettua asennusohjeen pohjalta eikä ole ollut yhteydessä projektiryhmään tarkentavien kysymysten vuoksi. Asiakkaalle on pidetty koulutus järjestelmän rakenteesta. 3. Järjestelmän jatkokehityskelpoisuus (Asiakkaan ja ohjaajan subjektiivinen näkemys koodin kommentoinnin ja järjestelmän dokumentoinnin laadusta. Järjestelmän modulaarisuus) Järjestelmän rakenne ja rajapinnat on dokumentoitu ja ryhmä uskoo jatkokehityksen olevan helppoa. Koodi on kommentoitu ja kommentit on ennen järjestelmän viimeisen version luovuttamista asiakkaalle katselmoitu ryhmän toimesta. Järjestelmän modulaarisuutta parannettiin T4-vaiheen alussa ja se dokumentoitiin Rational Rosella. 4. Dokumentaation laatu (Asiakkaan subjektiivinen näkemys katselmointiprosessin kautta.) Asiakkaalla ei ole ollut suuria muutoksia ryhmän katselmointiin toimittamiin dokumentteihin. Keskustelua ja tiedonvälitystä parhaiten tuki käyttöliittymäprototyypin määrittelevä dokumentti. 5. Järjestelmä tukee useita samanaikaisia käyttäjiä (Mahdollisten yhtäaikaisten käyttäjien enimmäismäärä) Järjestelmää on kokeiltu projektiryhmän toimesta 7:llä yhtäaikaisella käyttäjällä. Yhtäaikaisuuden hallinnassa ei ole havaittu ongelmia. Käyttäjien enimmäismäärää ei mitattu työkalu- ja aikarajoitteen yhdistelmän vuoksi. 3
6. Järjestelmä on helposti lokalisoitavissa (Lokalisointikriteerien täyttyminen) Järjestelmän käyttöliittymän kaikki viestit tulevat tietokannan lokalisointitaulusta ja näin ollen ovat helposti muutettavissa keskitetysti. Toteutuksessa on seurattu ryhmän alussa määrittämää lokalisointiohjetta ja kriteerit täyttyvät halutussa laajuudessa. 7. Järjestelmän helppokäyttöisyys (Järjestelmän käytön opettelemiseen kuluva aika uudelta käyttäjältä) Järjestelmän opponenttitestaukseen käytettiin kahdelta ihmiseltä yhteensä noin työpäivä. Opponenttitestauksessa ilmeni joitain puutteita helppokäyttöisyydessä ja nämä puutteet on saatettu asiakkaan tietoon, joka pyrkii ne korjaamaan jatkokehityksessään. Opponenttitestauksessa kuitenkin järjestelmän käyttö onnistui kohtuullisen lyhyessä ajassa, joten järjestelmää voi pitää melko helppokäyttöisenä, se pyrkii noudattamaan normaalien Web-sovellusten asettamaa mallia. Järjestelmän käytettävyyden testaaminen todettiin jo projektin alkupuolella viimeisessä vaiheessa oikeilla käyttäjillä projektin tavoitteiden kannalta tarpeettomaksi viimeisessä vaiheessa muutoksien tekeminen olisi ollut liian myöhäistä. Käytettävyyden tutkimiseen panostettiin sen sijaan jo paperiprotovaiheessa järjestämällä erilaisia käyttöliittymäläpikäyntejä sekä ryhmän kesken että asiakkaan kanssa. 8. Järjestelmän toteutuksen on oltava selainpohjainen (Toimii selaimessa) Järjestelmä toimii selaimessa eikä vaadi selaimelta lisäominaisuuksia. Järjestelmä on testattu sekä Internet Explorer että Netscape Navigator selaimilla. 9. Järjestelmän on tarjottava mahdollisuus TAI:n tutkimustulosten levittämiseen (TAI:n tuottamaa materiaalia on mahdollista käyttää järjestelmän kautta) Järjestelmään vietiin Kehittäjän karttakirjan peruskarttakirjan aineisto ja sitä käytettiin pohjana testi- ja demotarkoituksiin luoduissa tiedoissa. 10. TAI:n on saatava tarvittavat tiedot järjestelmästä, jotta se voi tehokkaasti suunnitella ja toteuttaa järjestelmän käyttöönoton kohdeyrityksissään. (Luvatut 4
materiaalit toimitetaan ajallaan ja projektiryhmä raportoi viikkotasolla projektin edistymisestä) Dokumentit on toimitettu asiakkaalle kuten on sovittu ja asiakas on voinut käyttää niitä pilottiyritystensä kanssa toimiessa. Asiakkaalle on järjestetty koulutus projektin lopussa, jossa käsiteltiin järjestelmän toimintojen lisäksi jatkokehitystä. Kaikki projektissa tuotettu dokumentaatio on luovutettu asiakkaalle asennus-cd:llä myös Word-muodossa, jotta asiakas voi muuttaa luotuja dokumentteja vastaamaan jatkokehitetyn järjestelmän tilaa. 2.3 VAATIMUSMÄÄRITTELYSSÄ TUNNISTETUT TAVOITTEET Vaatimusmäärittelyssä tavoitteiksi on asetettu vaadittujen toiminnallisuuksien toteuttamisen lisäksi seuraavat. 1. Projektissa noudatetaan sille asetettuja laatutoimenpiteitä mahdollisimman laadukkaan tuotteen toimittamiseksi (ryhmä arvioi itse, onko laatuprosesseja noudatettu) Määritettyjä laatukäytäntöjä analysoidaan tarkemmin kohdassa 5 Käytetyt menetelmät. 2. Tuote vastaa toiminnoiltaan asiakkaan vaatimuksia (asiakkaan palaute kurssin loputtua) Asiakas on läpi projektin kertonut olevansa tyytyväinen ryhmän työhän. Asiakkaan kanssa on käyty läpi ryhmän testauksessa havaitsemat puutteet ja sovittu korjattavat asiat, joten näiden nyt tehtyjen korjausten jälkeen järjestelmä on valmis asiakkaan jatkokehitykseen. 3. Suorituskyky (Asiakkaan palaute käytön sujuvuudesta) Asiakkaalla ei ole ollut huomautettavaa suorituskyvystä. Suurien dokumenttien siirtäminen verkon yli järjestelmästä käyttäjän koneelle saattaa olla hidasta, mikä on tunnettu ongelma. Mikäli verkko on ongelma pilottiyrityksissä, asiakkaan 5
kanssa on T2-vaiheessa keskusteltu mahdollisista vaihtoehdoista asiakkaan pohjien pienentämiseksi värejä ja fontteja muuttamalla tai mahdollisesti zippaamalla. 4. Ohjelmiston jatkokehityksen vaivattomuus (oma arvio ja jatkokehittäjän palaute) KOOKOS-projektiin on palkattu uusi ohjelmoija, jonka vastuulle järjestelmän jatkokehitys siirtyi. Hän on asentanut järjestelmän ja lähtenyt toteuttamaan SSLsalausta eikä ole joutunut pyytämään projektiryhmän tukea, joten jatkokehityksen voi arvioida olevan kohtuullisen vaivatonta. 5. Luotettavuus (testaamalla ongelmatilanteita) Järjestelmää on testattu sekä projektiryhmän, asiakkaan että opponentin toimesta. Ongelmia luotettavuudessa ei ole havaittu, tiedot säilyvät järjestelmässä odotetusti. 6. Tietoturva (todetaan asiakkaan kanssa riittävyys) Tietoturvan toteutukseen sisältyi oletus SSL-salauksen toteutuksesta, joka kehitysympäristön muuttamiseen liittyvän riskin vuoksi sovittiin jätettäväksi asiakkaan toteutukseen. Käyttäjäryhmät on toteutettu ja niiden toimintaa on testattu. Asiakkaalla ei ole ollut huomautettavaa. SSL-salaus jätettiin toteuttamatta, koska sen implementointi koettiin riskiksi projektin edistymiselle. SSL-salauksen toteutus olisi vaatinut Apache-palvelimen muuntamista https-palvelimeksi, jonka jälkeen palvelimemme ei olisi vastaanottanut perus-http-kutsuja. Koska SSL:n ja TomCatin yhteensovittamisen vaatimat operaatiot eivät olleet täysin tiedossa (palvelinsovellusten tuki Windowsalustalla ei ole vastaavalla tasolla kuin Unixissa) ja sen toteuttamiseen kuluvaa aikaa ei pystytty hyvin arvioimaan, korvattiin tämä viiden suositeltavan käyttötapauksen toteuttamisella. Jos työ olisi aloitettu, järjestelmän muu kehitys olisi jouduttu pysäyttämään kunnes SSL-salaus toimisi päästä päähän. Koska toteutuksella oli kiire ja se oli alustaan alkaen myöhässä aikataulustaan (toteutuksen piti alkaa T2-vaiheessa ja päättyä T3-vaiheen loppuun kun se alkoikin vasta T3-vaiheessa päättyen T4-vaiheeseen), nähtiin aiheelliseksi varmistaa muiden vaatimusten täyttyminen. 6
7. Dokumentoinnin laatu (asiakaskatselmoinnit) Asiakaskatselmoinneissa ei ole havaittu suuria puutteita dokumenteissa. Projektin tuottama dokumentaatio valmistui hyvin ajallaan ja täytti sille asetetut vaatimukset. Dokumentaatio on suurimmaksi osaksi katselmoitu myös asiakkaalla, erityisesti vaatimusmäärittely- ja suunnitteluvaiheissa, jolloin yhtäläinen näkemys asioista oli erityisen tärkeä. Näin asiakkaan kanssa on saavutettu hyvä yhteisymmärrys projektin asioista. 8. Selkeä, hyvin kommentoitu toteutus (asiakas tutustuu) Asiakkaalle luovutetusta järjestelmästä ei kysymiseen kannustamisesta huolimatta ole tullut tarkentavia kysymyksiä. Kommentoinnit katselmoitiin ryhmän toimesta ennen viimeisen version (4.1) luovutusta. 9. Käytettävyys (asiakas ja käyttäjäpalaute) Järjestelmän käyttäminen on melko suoraviivaista. Käyttäjäpalautetta kuulemme varsinaisesti vasta projektin loputtua, kun järjestelmä siirtyy pilottiyrityksiin käyttöön. 10. Aikataulun pitäminen (vertailu, pakollisten toteutus) Aikataulu on pitänyt kohtuullisesti ja siinä tapahtuneet heitot on saatu korjattua. 3. PROJEKTIN KULKU Projektisuunnitelmasta poikettiin monella eri tavalla projektin aikana, eikä laatukäsikirjaakaan voitu noudattaa kaikissa kohdissa. Suurimmat linjaukset kuitenkin pitivät koko projektin ajan, mitä voidaan pitää hyvänä saavutuksena. Tässä kappaleessa arvioidaan projektiryhmän menestystä projektin hallinnassa niin projektisuunnitelman noudattamisen ja arvioiden onnistumisen, kuin riskienhallinnan ja laatukontrollinkin kannalta. 7
3.1 TYÖMÄÄRÄARVIOT VAIHEITTAIN Projektin työmääräarvioissa pysyttiin kokonaisuutena kiitettävästi: kokonaistyömäärä jäi alle alkuperäisen arvion. Alla alkuperäisen projektisuunnitelman työmääräarvioiden taulukko sekä taulukko työmäärien toteutumista (KY = Katariina Ylinen, NT = Niko Tolvanen, KK = Kimmo Kujala, MR = Minna Reino, EJ = Eero Jyske ja AS = Antti Sillanpää). Suunnitelma: Vaihe KY NT KK MR EJ MP AS Yhteensä PS 55 50 30 35 30 50 30 280 T1 40 50 30 50 40 50 40 300 T2 40 40 25 54 20 50 35 264 T3 40 40 35 30 65 50 72 332 T4 40 40 40 30 54 40 40 284 LU 40 30 35 40 35 30 48 258 Yht. 255 250 195 239 244 270 265 1718 Toteutuma: Vaihe KY NT KK MR EJ MP AS Yhteensä PS 48.5 46.5 39.5 39.5 51.5 51.5 39.5 316.5 (+13%) T1 41.5 27 21 41 47.5 60 44.5 282.5 (-5,8%) T2 21 48 22 27.5 40 42 14 214.5 (-18.7%) T3 17.7 12 66.3 34.8 165 27.2 81.3 404.3 (+21.7%) T4 34 38 90 3 14 37.3 71 287.3 (+1,1%) LU 24 7 7 5.5 4 16 4 67, 5 (-73,8%) YHT. 185 179 245 158 321 234 250 1572 (-8,5%) 8
Taulukoista on nähtävissä, että vaikka vaihekohtaisissa työmääräarvioissa oli suurta heittoa niin alle kuin ylikin, kokonaistuntimäärässä päästiin selvästi alle alkuperäisen arvion. Heitto on jopa merkittävän suuri, 8,5 prosenttia. Henkilökohtaisissa työmäärissä sen sijaan heitot ovat valitettavan suuria. Tämä johtuu siitä, että työmääräarviot heittelivät suuresti nimenomaan tehtäväkohtaisesti ja erityisesti toteutukseen arvioitu työmäärä ylittyi reilusti. Tämä aiheutti sen, että toteutukseen osallistujilla työmäärät kasvoivat liikaa kun taas muilla työtä ei tullut niin paljon kuin oli arvioitu. Osa hallinnollisista ja laaduntarkkailutehtävistä tosin on luultavasti jäänyt merkitsemättä tuntitarkkailuun, koska sitä on tehty satunnaisesti eikä sitä ole ollut helppo merkitä. Valitettavaa oli erityisesti Eero Jyskeen työmäärän merkittävä ylittyminen, joka johtui nimenomaan toteutukseen menneestä ajasta. Toteuttajien väliset erot ovat syntyneet lähinnä siitä, kenellä on ollut parhaiten kulloinkin aikaa toteuttaa, eikä näitä siis olla voitu täysin tasoittaa. Kurssin lopussa etenemiskäyrä on hieman harhaanjohtava, koska työmääräarvioita muutettiin kurssin kuluessa ja täten viimeisimmässä versiossa kokonaistuntimäärä onkin 1488,5 tuntia. Tämä aiheuttaa sen, että VICA-kaavio projektin etenemisestä osoittaa työmääräarvion pitäneen paikkaansa ja projektin päätyneen toteumaltaan oikeisiin tuntimääriin. Käyrästä voidaan kuitenkin nähdä suurpiirteisesti projektin työmäärän kehitys ja missä vaiheissa se on ylittänyt arviot ja palannut takaisin oikeille urille. Projekti on siis pysynyt lähes koko matkan ajan arvion alla suunnitteluvaiheessa mentiin hivenen yli, samoin kuin toteutus 3 -vaiheessa joulu-tammikuussa. Vaihekohtaisien tuntiarvioiden pettämisessä merkittävä rooli oli käyttöliittymäproton valmistumisen lykkääntyminen. Kun käyttöliittymäproto ei ollut valmis, toteutuksen aloittaminen 9
viivästyi. Tällöin T1- ja T2- vaiheisiin ei tullut toteutustunteja niin paljon kuin arvioitiin ja T3-vaiheessa sekä vielä T4-vaiheessakin jouduttiin ottamaan toteutuksen aikataulua kiinni. 3.2 TEHTÄVÄJAKO JA TYÖMÄÄRÄT Projektin alussa tehdyn suunnitelman mukaisesti projektin hallintaan, laaduntarkkailuun ja testaukseen arvioitiin menevän huomattavasti enemmän aikaa kuin mihin päädyttiin. Toisaalta toteutukseen kului huomattavasti enemmän aikaa. Virhearviot johtuvat siitä, että ryhmällä ei ollut kokemusta kokonaisen ohjelmistoprojektin työmääräarvioiden laatimisesta. Koska opinnoissa on usein painotettu projektin suunnitteluun ja järjestelmän määrittelyyn menevän merkittävän suuri prosentuaalinen osuus koko projektin työmäärästä, arvio pitkälti perustui tähän tietämykseen. Projektimme toteutustavat olivat kuitenkin projektin osallistujille ennestään tuntemattomia, ja täten toteutukseen meni aikaa enemmän kuin keskiverto ohjelmistoprojektissa kun osa ohjelmointiajasta meni opiskeluun ja asioiden kokeilemiseen. Testauksen työmäärä on myöskin mittarien mukaan jäänyt hyvin alhaiseksi. Tämä johtuu ryhmän toteutustyylistä. Ohjelmointia ei jaettu koko ajan selkeästi eri kokonaisuuksiin, joista kukin olisi ollut yhden henkilön vastuulla vaan kaikki käytännössä työskentelivät jossakin määrin samojen ohjelmatiedostojen parissa. Näin ollen kaikki ohjelmoijat itse työskennellessään tulivat samalla katselmoineeksi muiden koodia, eikä tätä voitu selkeästi kuitenkaan erottaa tuntiraportoinnissa. Samoin käyttöliittymän ollessa yksinkertainen websivusto, jokainen ohjelmoidessaan testasi aina toiminnon tehtyään sen toiminnallisuutta. Näin ollen moduulitestausta ei myöskään pystytty helposti erottamaan ohjelmoinnista raportoinnin osalta. Tunnit oltaisiin toki pystytty laskemaan, mutta ryhmä tuli siihen lopputulokseen että on parempi pyrkiä työskentelyn tehokkuuteen kuin minuutintarkkaan pöytäkirjan pitämiseen. Näin ollen kaikki järjestelmän toteutukseen liittyvät tunnit merkittiin ohjelmointiin, kun niistä todellisuudessa merkittävä osa oli moduulitestausta ja koodin katselmointia. Tämä myös osaltaan selittää toteutukseen kuluneiden tuntien valtavan ylityksen sekä sen, että toteuttajille tuli enemmän tunteja kuin mitä oli arvioitu. Alun perin kun testaus oli pitkälti eritelty eri henkilöiden tehtäväksi. 10
4. JÄRJESTELMÄN VIRHEET Edellä mainituista toteutuksen ja testauksen työnjakoon liittyvistä syistä myös virhemäärien arviointi ja niistä johtopäätösten vetäminen on hyvin hankalaa. Referenssinä voidaan käyttää vain järjestelmätestauksessa vaiheissa T3-T4 löytyneitä virheitä sekä opponenttitestauksessa löytyneitä virheitä. Kyseiset mittarit eivät kerro mitään moduulitestauksessa löytyneistä virheistä, koska ne on aina korjattu välittömästi eikä niitä ole merkitty ylös. T3-vaiheen järjestelmätestaus suoritettiin melko pikaisesti, koska sen merkitys ei ollut kovin merkittävä järjestelmän ollessa pahasti kesken erityisesti testattavan käyttöliittymään osalta. Sen sijaan vaiheen T4 järjestelmätestauksen ja opponenttitestauksen tuloksista voisi tehdä johtopäätöksiä. 4.1 T4 JÄRJESTELMÄTESTAUS Järjestelmätestauksen vaiheessa T4 suorittivat Maaret Pyhäjärvi ja Niko Tolvanen. Tuloksista voitiin vetää se johtopäätös, että järjestelmä toimii hyvin vaatimusten mukaisesti, mutta käyttöliittymää ei ole hiottu loppuun saakka spesifikaatioiden mukaan. Lähes kaikki järjestelmän virheet liittyivät käyttöliittymän epäjohdonmukaisuuksiin sekä poikkeamiin suunnitellusta. Toiminnalliset virheet (2 kappaletta) korjattiin asiakkaan kanssa sovitulla tavalla. 4.2 OPPONENTTITESTAUS Opponenttitestauksessa merkittäviä toiminnallisia virheitä ei myöskään löytynyt sen lisäksi mitä järjestelmätestauksessa itse oli löydetty. Ainoa merkittävä toiminnallisuuteen liittyvä bugi, joka katsottiin tarpeelliseksi korjata, oli salasanan vaihdon epäonnistuminen. Tämän huomattiin olevan ohjelman siirrettävyysongelma alkuperäisessä järjestelmässä toiminto toimi, mutta yksi tähän tarvittava ohjelmatiedosto oli jäänyt kopioimatta testattavaan instanssiin. Näin ollen asennusohjetta sekä levyä jouduttiin hivenen muuttamaan mutta ohjelmallisia korjauksia ei jouduttu tekemään. 11
Loppuyhteenvetona testauksista voitaisiin todeta järjestelmän toiminnallisuuden toimineen odotettua paremmin, mutta käytettävyydessä olevan ongelmia. Nämä voidaan katsoa virheiksi, koska järjestelmän hyvä käytettävyys oli pakollinen ominaisuus. Käyttöliittymään liittyvistä ongelmista päästiin kuitenkin sopimukseen asiakkaan kanssa eikä niitä ollut tarpeellista lähteä korjaamaan. 5. KÄYTETYT MENETELMÄT Projektissa oli suunniteltu käytettävän USDP-prosessia, jonka erityispiirteitä ovat sekä inkrementaalisuus että iteratiivisuus. Menetelmää myös sovellettiin jossakin määrin, joskin tulkinnasta riippuen menetelmän käyttö ontui. Ryhmä ymmärsi, osin omien odotustensa pohjalta, kurssin antamia ohjeita projektin alussa väärin, ja pyrki kirjoittamaan teknisen määrittelyn heti aluksi kokonaisuudessaan. Tästä johtuen inkrementaalisuuteen ei kunnolla päästy, kun koko järjestelmä tuli määritellyksi kerralla ja korjattua tarkentamisen sijasta. Toisaalta iteratiivisuutta toteutettiin niin käyttöliittymäsuunnittelussakin (lukuisat kierrokset asiakkaan kommentoitavina ja hiottavina) sekä toteutuksessa ja teknisessä määrittelyssä (määrittely muuttui toteutuksen edetessä, kun toteutustekniikoista opittiin lisää). Inkrementaalisuuden vähyyteen johti myös se, että järjestelmä pyrittiin määrittelemään hyvin pitkälle käyttöliittymäprototyypin avulla. Toteutus aloitettiin vasta prototyypin ollessa valmis, jottei vääriä toteutustapoja jouduttaisi turhan paljon korjailemaan. Tästä syystä toisaalta kaikki järjestelmän toiminnallisuus tuli suunniteltua kerralla kokonaisuudessaan. Vaikka suunnittelu tehtiin iteratiivisesti, koko ajan suunnittelun alla oli täysi kokonaisuus, jota ei osattu laajentaa ajan myötä. Osasyynä tähän pohdimme olevan ryhmän kokemustaso epävarmuuksia on muutenkin paljon osaamattomuudessa ja kokemattomuudessa ja osien tietoinen ulosjättäminen kun niitä ei ymmärrä on vaikeaa. Inkrementaalisuuden arvioinnissa toki voidaan käyttää eri katsontakantoja, ja toki järjestelmää pyrittiin toteuttamaan kerros kerrallaan jolloin järjestelmä kehittyi inkrementaalisesti toteutusvaiheessa. Kokouskäytännöt ja katselmointiprosessi, jotka määriteltiin kurssin alussa, toimivat projektin kuluessa hyvin. Kokouskäytännöstä tingittiin toteutuksen päästyä vauhtiin, sillä suunnittelu- ja organisointityötä oli hyvin vähän eikä ajan kuluttamista viikoittaisiin 12
palavereihin nähty enää tarpeelliseksi. Myös asiakaskatselmointeja supistettiin, koska palautettavissa dokumenteissa ei enää muunneltu kovin merkittäviä asioita, ja nämä käytiin yleensä lähinnä sähköpostitse tai puhelimitse asiakkaan kanssa läpi ja neuvoteltiin muutosten sopivuudesta. Edistymisestä raportoitiin suunnitelmien mukaan ja asiakas on ilmaissut olleensa tyytyväinen tiedotuksen määrään ja laatuun. Testauksen menetelmiä käytettiin aluksi, mutta esimerkiksi testauksen automatisointi nähtiin hyötyyn nähden varsin resursseja kuluttavaksi ja niistä täten osittain luovuttiin. Uusia työkaluja kokeiltiin ja osa koettiin hyödyllisiksi siinä missä osa lähinnä taakaksi testaajille. Työkalujen käytöstä opittiin ja tämäkin koettiin kokemuksena hyväksi, erityisesti tähän voitiin käyttää vähän ylimääräistä aikaa kun testauksen ja koko projektin tuntimäärät olivat jäämässä alle odotetun. Nämä tunnit katsottiin tulevan projektin hyödyksi koska ne palvelivat ryhmän jäsenten oppimisintressejä. 6. RISKIEN HALLINTA Projektin riskien hallinta onnistui kohtuullisen hyvin. Alussa tehty riskianalyysi kattoi hyvin kaikki merkittävät riskit, eikä suuria yllätyksiä täten päässyt tulemaan. Myös riskien ennalta ehkäisyssä voidaan katsoa onnistutun. Ainoa projektin riskianalyysissa listattu riski, joka on toteutunut, on riski numero 3: Valitaan toteutustekniikka, josta ei ole kokemuksia. Tämä oli oikeastaan välttämätöntä järjestelmän arkkitehtuurin ja käytännön kannalta toteutustekniikkavalinnat olivat pitkälti ainoita järkeviä, ja kuitenkaan monilla ei ollut niistä kokemusta. Tämä on aiheuttanut, kuten jo aiemmin totesimme, toteutuksen työmäärien kasvamista ennakoidusta. Lisäksi tämä on aiheuttanut SSL-salauksen pois jättämisen järjestelmän toteutuksesta. Periaatteessa myös riski 7: Yhteisiä sovittuja prosesseja ei noudateta, on toteutunut USDP-prosessin vaillinaisen implementoinnin vuoksi. Tämä ei kuitenkaan vastaa riskin taustalla ollutta ajatusta, sillä prosessin vaillinainen toteutus ei suuresti haitannut projektin kulkua, eikä siihen johtaneihin tekijöihin juuri voitu projektiryhmän keinoin vaikuttaa. Ongelmana riskienhallintaprosessissa oli lähinnä riskianalyysin tulkinnan ja varautumiskeinojen yksipuolisuus. Molempien mainittujen riskien tapauksessa niiden ilmenemismuoto oli hivenen erilainen, kuin riskienhallintasuunnitelmaa laadittaessa oli 13
ajateltu. Tällöin myöskään sama torjuntamenetelmä ei suoraan toiminut. Tuntemattoman toteutustekniikan pelättiin aiheuttavan sen, että toteutustekniikka ei ole toimiva ja sitä joudutan muuttamaan kesken projektin, kun se todellisuudessa toikin ainoastaan lisätunteja opiskelun ja harjoittelun ansiosta. Prosessien laiminlyönnin taas arveltiin johtuvan sitoumuksen puutteesta, joskaan sitoumuksen puutetta ei ollut projektissa muuten havaittavissa. Lisäksi ongelmaksi koitui käyttöliittymäproton merkittävä myöhästyminen, joka omalta osaltaan myöhästytti toteutuksen alkamisajankohtaa. Tähän ei osattu suoranaisesti valmistautua. Riskiksi kyllä merkittiin asiakkaan mahdollinen mielenmuutos tai vaatimusten ymmärtäminen väärin, ja osittain juuri näiden riskien välttämiseksi protoa iteroitiin pitkään ja huolella. Näin vältettiin kahden riskin toteutuminen, mutta jälkikäteen ajateltuna olisi voinut olla aikataulullisesti kannattavampaa ottaa suurempia riskejä näiden suhteen. Jos toteutus olisi päässyt alkamaan aikataulussa, jossakin määrin käyttöliittymään olisi varmasti voitu tehdä muutoksia jälkikäteenkin työmäärän kovasti ylittymättä. Tätä ei osattu määrittelyvaiheessa varmaksi arvioida ja siksi ehkä näiden riskien torjumiseen käytettiin kohtuuttomasti aikaa. Toisaalta käyttöliittymäprotot olivat paras keinomme saada asiakkaalta palautetta kehityksen oikeasta suunnasta. Yleisesti ottaen voidaan todeta riskienhallinnan onnistuneen projektissa hyvin mikään analysoiduista riskeistä ei ole toteutunut sellaisenaan, ja vain yksi täysin listan ulkopuolinen riski on toteutunut. Riskit pystyttiin yhtä lukuun ottamatta kartoittamaan kattavasti, joskin niiden tarkempi analysointi olisi voinut olla huolellisempaa. Samoin riskien torjunnassa olisi voitu käyttää enemmän harkintaa, jotta toteutusta olisi voitu lähteä tekemään ajoissa. 14
7. ARVIO PROJEKTIN ONNISTUMISESTA Projektin voi todeta onnistuneen tavoitteissaan sekä ryhmän että asiakkaan kannalta. Olemme oppineet tekemisen aikana paljon, joten voisi olettaa, että olemme myös kurssin tavoitteiden kannalta saavuttaneet sen mitä oli tarkoituskin. Järjestelmä on valmis, ja asiakas on sen hyväksynyt. Riskienhallinta on onnistunut kohtuullisen hyvin, työmääräarviot kokonaisuutena varsin mainiosti, budjetti alitettiin ja projektiryhmän tavoitteena pidettyjä hyviä arvosanojakin on projektin aikana saatu. Pakollisena ominaisuutena olleen SSL-salauksen poisjäännistä päästiin asiakkaan kanssa sopimukseen. Asiakas on myös antanut ymmärtää olleensa tyytyväinen ryhmän työskentelyyn ja tiedottamiseen, jotka ovat käytännön yritysmaailmassa erittäin arvokkaita asioita. 7.1 MITÄ OPITTIIN? Projektiryhmä on oppinut kurssin aikana merkittävästi asiakasyhteistyöstä, vaatimusmäärittelyyn liittyvistä asioista, riskien hallinnasta ja projektin hallinnasta. Uudet teknologiat kuten JSP-ohjelmointi sekä kokonaisen client/server-ohjelmiston toteutus ovat olleet valtaosalle ryhmästä uusia asioita. Myös käyttöliittymäsuunnittelusta opittiin monta läksyä, niin asiakkaan mielipiteiden ja yleisen käytettävyyden välisestä tasapainottamisesta kuin riskinoton tarpeellisuudesta. Projektin sisäisen kommunikaation tärkeys on tullut esille ja sen tärkeys on ymmärretty ehkä laajemmin kuin ennen. 7.2 MITÄ TEKISIMME TOISIN? Jos projekti pitäisi nyt aloittaa alusta, ryhmämme tekisi varmasti monta asiaa eri lailla kuin ensimmäisellä kerralla. Yksi selkeä virheeksi tunnistettu asia, joka korjattaisiin, oli käyttöliittymäproton odottaminen toteuttamisen alkamiseksi. Järjestelmän toteuttaminen olisi pitänyt aloittaa jo aiemmin tarvittavien muutosten implementointi ei suurimmassa osaa tapauksista olisi aiheuttanut suurta lisätyötä, ja toteutuksella olisi ollut paljon enemmän aikaa. Tällöin myös oltaisiin osittain vältytty työtaakan kertymiltä, joihin nyt törmättiin, kun työnjakoa olisi voitu tehdä vapaammin eikä se tekee joka ehtii periaatteella. 15
Ryhmämme ei myöskään pyrkisi tekemään koko teknistä määrittelyä heti projektin alussa. Päinvastoin ainoastaan arkkitehtuurin suuremmat linjaukset tehtäisiin alussa, ja määrittelyä tarkennettaisiin toteutuksen edetessä. Näin edellytykset USDP-prosessin tarkempaan seurantaan olisivat paremmat, ja toisaalta siihen voitaisiin myös kiinnittää enemmän huomiota. Muuta ryhmä tuskin muuttaisi merkittävästi. Ryhmän sisäinen ymmärtämys toistensa osaamistasosta ja yhteistyökyky olisi luultavasti heti aluksi parempi, jolloin yhteistyö olisi saumattomampaa kuin mitä se tässä tapauksessa heti projektin alettua saattoi olla. Kunkin erityisosaamisia voitaisiin näin käyttää paremmin hyödyksi heti kurssin alussa. Projektia suunniteltaessa otettaisiin myös paremmin huomioon, millaisille kokonaisuuksille tunnit on helppo jakaa ja merkitä tuntikirjanpidossa nyt tuntimerkintöjä ei tehty kuin suurille kokonaisuuksille ja niiden seuraaminen siksi vaikeutui. Lisäksi palavereihin ja projektin hallintaan kulutettavia työmääriä ei tulisi arvioitua niin suuriksi enää projektin loppuvaiheessa. Suuria muutoksia tähänkään tuskin tulisi. 8. ARVIO KURSSISTA Kurssi on täyttänyt projektiryhmän sille asettamat odotukset. Kurssin järjestelyt toimivat sujuvasti; arvostelut tulivat ajallaan ja olivat jokseenkin yhdenmukaisia. Kurssin tarjoamien työkalujen käyttöön olisi saanut olla enemmän ohjeistusta. Ryhmämme kohdalla ongelmia huomattiin vasta myöhäisessä vaiheessa edistymisraporttien yhteydessä, kun VICA- kuvaajia analysoitiin. Kuvaajat antoivat erheellistä kuvaa projektista, koska Tiranaa ja PMIX-dumppauksia oli käytetty virheellisesti. Tiranasta annettu ohjeistus olisi siis saanut olla syventävämpi, lähinnä sen kannalta että ymmärtäisi paremmin, mikä vaikuttaa mihinkin kuvaajaan jo ennen tuntien syöttämistä. Kurssin työmäärä oli ryhmän mielestä jonkin verran suurempi kuin viiden opintoviikon suoritus, jonka siitä saa. Tosin tämä oli odotettavissa kurssin alusta lähtien. Toki projekti olisi voitu suunnitella siten, että vain opintoviikkojen edellyttämä tuntimäärä tulee tehdyksi ja noudattaa tätä, mutta käytännössä projektityön kokoista järjestelmää ei olisi 16
voitu toteuttaa niin lyhyessä ajassa lähtien ryhmän jäsenten osaamistasosta projektin alussa. Näin ollen valittavissa oli joko epäonnistunut projekti tai ylimääräinen työ. Tämän valinnan tekeminen taas suoraan vastaa sitä, että saadakseen hyvän arvosanan kurssilla on tehtävä enemmän tunteja kuin viisi opintoviikkoa edellyttävät. Toisaalta, opintoviikko on suhteellinen käsite ja käytetyn työmäärän suhteuttaminen opintoviikkoihin vaatisi pidempää pohdintaa kurssin esitietovaatimuksia ja tavoitteita vasten. Assistentin roolia ja kurssin vaatimuksia voisi jollain tapaa koittaa selkiyttää. Projektit ovat erilaisia ja näin arvostelu voi olla hyvinkin haastavaa. Asiakkaan ei-teknisyyden ja ohjaajan toimimattomuuden kannalta olisimme jostain suunnalta voineet kaivata myös teknisiä kommentteja. Kurssin anti oli kiitettävä. Ryhmän jäsenet oppivat hyvin paljon projektin hallinnasta, asiakkaan kanssa toimimisesta, käyttöliittymäsuunnittelusta sekä eri toteutustekniikoista. 17