PROJEKTIN LOPPURAPORTTI

Transkriptio

1 LOPPURAPORTTI /8 TEAM TUBELESS RENGASTESTIEN MITTAUSTULOSTEN KÄSITTELY - NOHEVA II PROJEKTIN LOPPURAPORTTI SISÄLLYS 1 Johdanto Projektin eteneminen Suunnitteluvaihe Ensimmäinen toteutusvaihe Toinen toteutusvaihe Tulokset Tavoitteiden saavuttaminen Laatu Viat, toteuttamattomat ominaisuudet, kehitysideat Numerotietoja Työkalut ja -käytännöt Oppimishyödyt Kaikkia kurssin opiskelijoita koskevat hyödyt Projektiryhmäämme liittyvät asiat Henkilökohtaiset kommentit Markku Kekkonen Juha Kauppi Sami Tikkanen Tuomas Hellstén Tiina Korhonen Marko Lindström Jaakko Manelius Kurssipalaute...8

2 LOPPURAPORTTI /8 1 Johdanto Projektin tavoitteena oli suunnitella ja toteuttaa rengastestien mittaustulosten käsittelyohjelma, Noheva II, Test World Oy:lle. Ohjelmalle määriteltyjä vaatimuksia olivat kokonaisen testiprojektin käsittely testityyppeineen, koesarjoineen ja kokeineen, mittaustulosten lukeminen VBOX-tiedostoista, tulosten muokkaaminen ja esitys kuvaajina, vertailuindeksien laskenta ja esitys kuvaajina, testiraportin tulostaminen, mittaustulosten vienti CSV-muodossa, projektitiedostojen tallennus keskustietokantaan sekä tietojen haku edellisvuonna toteutetusta Noheva I -ohjelmasta. 2 Projektin eteneminen 2.1 Suunnitteluvaihe Projektityön teko alkoi tapaamisella asiakkaan kanssa. Ensimmäisessä tapaamisessa 30. syyskuuta tutustuttiin asiakkaan tavoitteisiin ja vaatimuksiin. Todettiin, että projektilla on selkeät tavoitteet. Asiakas toimitti pian rengastesteihin liittyvää lisämateriaalia, ja vaatimusmäärittelyn laatiminen saatiin käyntiin. Samanaikaisesti aloitettiin kehittäjien rekrytointi. Projektiryhmä saatiin lopullisesti kokoon 6. lokakuuta. Suunnitteluvaiheen lopuksi oli ainakin manageriryhmälle muodostunut selkeä käsitys siitä, mitä ollaan tekemässä. Ryhmätapaamisissa käytiin läpi ohjelmistolta vaadittavia ominaisuuksia, jotta myös kehittäjät saisivat tarvittavat yleistiedot projektista. Näin tapahtuikin; epäselvyyttä projektin tavoitteista ei esiintynyt missään vaiheessa. 2.2 Ensimmäinen toteutusvaihe Ensimmäisen toteutusvaiheen työ alkoi käyttöliittymäprototyypin tekemisellä. Asiakkaalla oli tästä hyviä kokemuksia edelliseltä vuodelta. Proton perusteella saatiin määritellyksi ohjelmiston perusrakenne, joka ei juuri projektin edetessä muuttunut. Haittapuolena tästä oli melkein kaikkien käyttöliittymätoimintojen sisältyminen samaan java-tiedostoon, minkä vuoksi tästä tiedostosta tuli hyvin suuri. Käyttöliittymän toteutukseen liittyi jonkin verran ongelmia. Kaikkia komponentteja ei saatu heti toimimaan halutulla tavalla.

3 LOPPURAPORTTI /8 Käyttöliittymän lisäksi toteutettiin ohjelmaan liittyvät rajapintamääritykset, tarvittavat tietorakenteet, VBOX-tiedostojen lukeminen, vertailuindeksien laskenta sekä tietojen tallennus xml-muotoiseen tiedostoon. Raportin toteuttaminen viivästyi, koska malliraporttia ei saatu ajoissa käyttöön. Varsinaista malliraporttia ei itse asiassa koskaan saatu käyttöön, mutta raporttiin kuuluvat tiedot saatiin muuten selville. Asiakastapaamisissa kerrottiin projektin etenemisestä ja saatiin lisätietoja siitä, minkälaisia ominaisuuksia ohjelmistolta halutaan. Pienimpiä yksityiskohtia ei huomattu kirjata tarkasti ylös vaatimusmäärittelyyn, mikä vuoksi osa niistä unohtui pitkäksi aikaa eikä niitä saatu toteutetuksi projektin aikana. Koska ohjelma ja sen toteutus näyttivät varsin selkeiltä, asiakkalta tulevat uudet ideat hyväksyttiin sellaisinaan toteutettaviksi, luonnollisesti tärkeysjärjestys huomioiden. Iteraatiodemossa esiteltiin ohjelma, jolla pystyttiin käsittelemään testiprojektien tietoja, lukemaan VBOX-tiedostoja sekä laskemaan tulosindeksejä. Ohjelma ei kuitenkaan ollut riittävän vakaa tuotantokäyttöä ajatellen mutta se toimitettiin silti asiakkaalle kokeiltavaksi ja kommenttien saamiseksi. 2.3 Toinen toteutusvaihe Toinen toteutusvaihe aloitettiin osittain jo joululoman aikana korjaamalla ensimmäisestä toteutusvaiheesta jääneitä vikoja. Iteraatiosuunnitelmassa lähdettiin edelleen siitä, että raportti ja tietokantaominaisuudet saadaan toteutettua yhdessä käyttöliittymään kohdistuvien pienten parannusten kanssa. Asiakkaalta otettiin edelleen vastaan uusia kehitysehdotuksia, mutta niitä ei taaskaan huomattu kirjata järjestelmällisesti ylös, minkä vuoksi vain osa ehdotuksista toteutettiin. Osa unohtui, kun riittävän pitkä aika oli kulunut ehdotusten käsittelystä asiakkaan ja ryhmän välisessä sekä toisaalta ryhmän sisäisessä viestinnässä. Keskeisimmät vaatimukset kuitenkin kirjattiin vaatimusmäärittelydokumenttiin. Ohjelman käyttöliittymän kehittämistä jatkettiin ja olemassaolevien toimintojen luotettavuutta parannettiin. Tietokantayhteyksiin liittyvät toiminnot olivat ajatuksellisesti yksinkertaisia, mutta käytännön hankaluudeksi muodostui se, että käytettävä MySQL-tietokanta oli niin vanhaa versiota, ettei se tukenut salattuja SSL-yhteyksiä. Tietojen siirtämien salaamattomana olisi ollut vastoin asiakkaan esittämiä eitoiminnallisia vaatimuksia. Lopulta ratkaisuksi tuli SSH-tunnelointi tietokantapalvelimelle. Tietokantatoiminnot jäivät kuitenkin jälkeen aikataulustaan. Ajan käydessä vähiin oli yhteys edellisvuonna toteutetun Noheva I:n tietokantaan jätettävä tekemättä. Tätä kirjoitettaessa tämä ominaisuus on ainoa alkuperäiseen vaatimusmäärittelyyn kuuluva, jota ei varmuudella saatu tehdyksi.

4 LOPPURAPORTTI /8 Varsinaiseksi ongelmaksi muodostui kuitenkin raportti. Javalle ei ollut tarjolla ilmaista, hyvin dokumentoitua ja riittävän monipuolista raportintekokirjastoa. Valittu kirjasto oli kyllä ilmainen, lisenssiehdoiltaan sopiva ja monipuolinen, mutta siitä puuttui kaikki dokumentaatio. Tästä johtuen raportin laatiminen oli pakko tehdä yrityksen ja erehdyksen kautta, mikä vei erittäin paljon aikaa. Koska työ kuitenkin näytti koko ajan etenevän, toivottiin sen johtavan lopulta toimivan raportin aikaansaamiseen, minkä vuoksi korvaavaa ratkaisua ei ryhdytty ajoissa miettimään. Tätä kirjoitettaessa mahdollisuus saada raportti valmiiksi projektin aikana on edelleen olemassa, mutta se ei ole varmaa. Raportin jääminen pois projektista vähentäisi merkittävästi asiakkaan projektista saamaa hyötyä. Muilta osin ohjelma saatiin koko lailla käyttökelpoiseen kuntoon. Ohjelmaa testattiin ahkerasti niin kehittäjien, asiakkaan kuin vertaisryhmänkin toimesta. Erillisessä dokumentissa kuvatulla, testitapauksiin perustuvalla järjestelmätestauksella pystyttiin löytämään vain osa vioista. Tutkiva ja kokeileva testaus vaikutti vähintään yhtä tehokkaalta. Käyttöliittymä oli muodostunut kohtalaisen monimutkaiseksi siihen tehtyjen lukuisten muutosten ja lisäysten vuoksi. Tästä johtuen ohjelmaa vaivasivat useat pienet viat, jotka eivät estäneet käyttöä mutta häiritsivät sitä kyllä. Suurin osa vioista on jo korjattu, mutta tätä kirjoitettaessa muutamia vikoja on vielä korjaamatta. Ne pyritään korjaamaan ennen ohjelman luovutusta asiakkaalle. 3 Tulokset 3.1 Tavoitteiden saavuttaminen Suurin osa ohjelmalle asetetuista tavoitteista saavutettiin. 3.2 Laatu Projektin tärkeimmät laatutavoitteet olivat käytön yksinkertaisuus ja luotettavuus, laskennan virheettömyys sekä raporttien oikeellisuus ja yhdenmukaisuus. Näistä kaksi ensimmäistä on mielestämme saavutettu. Raportin tilanne on tätä kirjoitettaessa vielä epävarma, mutta senkin valmistuminen on vielä mahdollista. Ohjelman käyttöliittymä on yksinkertainen ja selkeä. Käytön luotettavuus on hyvällä tasolla, varsinkin sen jälkeen, kun tunnetut viat saadaan korjatuksi. Laskennan on todettu tapahtuvan oikein. Ohjelmasta on löydetty tähän mennessä 20 vikojenhallintaan raportoitua vikaa. Muulla tavalla havaittuja ja korjattuja vikoja on kuitenkin ollut enemmän, arviolta Vikojen määrä ei ole ollut poikkeuksellisen suuri ottaen

5 LOPPURAPORTTI /8 huomioon ohjelman rakentamisen usean ohjelmoijan yhteistyönä, toteutuskielen sekä kuitenkin melko monipuoliset ominaisuudet. Vikojen kokonaismäärä (n. 60) suhteutettuna ohjelman koodirivien määrään (x) on mielestämme melko vähäinen. Viat ovat kuitenkin harmillisesti painottuneet käyttöliittymään. 3.3 Viat, toteuttamattomat ominaisuudet, kehitysideat Toimitamme loppudemoon mennessä listan vioista, joita ei ole saatu korjatuksi, jos sellaisia on. Loppudemossa selviää myös, onko raportti saatu toteutetuksi. Toistaiseksi ainoa toteuttamatta jäänyt ominaisuus on tietojen haku Noheva I:n tietokannasta. Meillä ei ole ohjelmistoon liittyviä kehitysideoita, mutta asiakkaalla niitä on. Yksi ryhmämme jäsen jatkaa tarvittaessa ohjelmiston kehitystä yhdessä asiakkaan kanssa. 4 Numerotietoja Työtä tehtiin 1101 tuntia. Se jakaantui 433 ohjelmointituntiin eli noin 40 % ajasta käytettiin ohjelmointiin. Vikoja löytyi n. 60 kpl ja koodirivejä kirjoitettiin noin kpl. Projekti oli laajempi kuin missä projektiryhmän jäsenet olivat aikasemmin olleet mukana. 5 Työkalut ja -käytännöt Työkaluina käytettiin Windows-työasemia, joissa pääasiallinen ohjelmointiympäristö oli Eclipse. Pääkehittäjä käytti myös Borland Together Architect -ohjelmistoa. Toteutuskielenä oli Sunin Java 1.5. Viestintään käytettiin sähköpostia sekä IRC-ohjelmistoa. Versionhallinta hoidettiin CVS:llä. Tuntikirjaukseen käytettiin omaa tuotantoa olevaa Tunkki-tuntikirjausta. Viat raportoitiin Bugzilla-järjestelmään. Tapaamisia ryhmäläisten kesken järjestettiin usein, asiakkaan kanssa harvemmin ja mentoria tapasimme asioiksemme vain yhden kerran. Vertaistestaus oli tämän projektin kokemusten valossa hyödyllinen osa kurssia. Vertaisryhmältä saatiin käyttökelpoista palautetta ohjelman toiminnasta. Oli myös mukava tutustua toisen ryhmän projektiin ja havaita, miten he olivat edistyneet siinä.

6 LOPPURAPORTTI /8 Vertaisryhmä testasi projektiamme ilmeisen huolellisesti. Näkökulma kuitenkin oli testaajan, ei loppukäyttäjän näkökulma. Tämän vuoksi huomiota kiinnitettiin osin asioihin, joilla ei asiakkaallemme ole suurta merkitystä. Osittain havainnot kuitenkin olivat hyödyllisiä ja saimme muutaman vian korjatuksi vertaispalautteen ansiosta. Nämä viat olisivat muuten saattaneet jäädä huomaamatta. Vertaisryhmän arvio käyttöliittymän vikojen määrästä ei yllättänyt; osasimme odottaa tällaista mainintaa. Asiaan vaikutti myös se, että emme ehtineet testata ohjelmaa tarpeeksi ennen sen toimittamista vertaisryhmälle. Vertaisryhmän toimittamat testiohjeet heidän omaa järjestelmäänsä varten olivat riittävät, joskin ne tulivat hieman myöhässä. Tästä ei kuitenkaan aiheutunut merkittävää haittaa. OSLC on käyttöliittymän osalta varsin yksinkertainen ohjelma. Ilmeisesti suurin osa sen kehittelyajasta on kulunut lisenssintarkastusalgoritmien toteuttamiseen. Niitä emme pystyneet testaamaan kuin pintapuolisesti tarkempien tietojen puuttuessa. 6 Oppimishyödyt 6.1 Kaikkia kurssin opiskelijoita koskevat hyödyt Kurssilla oppii tehokkaasti, miten ohjelmistoprojekti käytännössä toteutetaan. Yhteydenpito asiakkaaseen, vaatimustenmäärittely, ryhmän työnjako ja viestintä ovat asioita, joita ei juuri tule eteen muilla kursseilla ainakaan tässä mittakaavassa. Todellinen asiakas tekee projektista mielenkiintoisemman verrattuna TKK:n tavallisiin harjoitustöihin. 6.2 Projektiryhmäämme liittyvät asiat Kurssin varsinainen opetus oli se, että yksinkertaiselta näyttävä projekti ei välttämättä loppujen lopuksi olekaan sellainen. Monimutkainen käyttöliittymä yhdistettynä ennalta-arvaamattomiin ongelmiin tietokantayhteyksissä ja erityisesti raportin laatimisessa johtivat siihen, että kaikkia alun perin suunniteltuja ominaisuuksia ei kerta kaikkiaan ehditty toteuttaa. 6.3 Henkilökohtaiset kommentit Markku Kekkonen Toimin projektissa projektipäällikkönä ja vastasin työn suunnittelusta ja seurannasta sekä yhteyksistä asiakkaan suuntaan. Projektin kasassa pitäminen on tuottanut haasteita lähinnä sen takia että projektiryhmä teki usein töitä erillään

7 LOPPURAPORTTI /8 toisistaan. Tavallisestihan projekteissa projektiryhmä on usein tiiviisti samassa paikassa jolloin yhteydenpito on helpompaa. Myös aikarajojen ehdottomuus aiheuttaa rajoituksia tällaisille projekteille, koska kaikkeen pitäisi varautua etukäteen ja ohjelmistosta tulee jättää ominaisuuksia pois ennemmin kuin joustaa aikarajoista. Kurssista teki mielenkiintoisen se että tässä toteutettiin hyötykäyttöön tuleva ohjelmisto oikealle asiakkaalle toisin kuin monissa muissa TKK:n kursseissa Juha Kauppi Sami Tikkanen Vastasin projektissa vaatimustenhallinnasta sekä laadunvarmistuksesta. Projektin keskeinen opetus liittyi vaatimustenhallintaan. Aiemman työkokemukseni perusteella olen pitänyt pikkutarkkaa vaatimustenhallintaa ja siihen liittyvää muutosvastarintaa osittain tarpeettomana asiana, joka hidastaa ohjelmistokehitystä ja vähentää asiakkaan mahdollisuuksia saada halutun kaltainen ohjelma. Olen osittain samaa mieltä edelleen. Tämä projekti kuitenkin poikkesi työhistoriani projekteista siten, että takarajaa ei voinut siirtää. Tästä johtuen toteutettavat (oikeammin pois jätettävät) ominaisuudet olisi pitänyt valita aikaisemmin. Koska työtä tehtiin suuressa ryhmässä, olisi pienetkin vaatimuksiin liittyvät yksityiskohdat pitänyt aina kirjata ylös. Toinen keskeinen havainto oli käyttöliittymään ja raporttiin liittyvän ohjelmoinnin kankeus Java-ohjelmointikielellä. Tämä saattaa johtua osittain sopivien työkalujen puutteesta ja vähäisestä kokemuksesta. Kolmas, eikä mitenkään yllättävä, havainto oli ajan loppuminen kesken yleisesti. Tämän johdosta emme kaikilta osin saavuttaneet sellaista laatutasoa, joka oli tavoitteena projektin alussa. Kokonaisuutena projekti oli kuitenkin hyödyllinen kokemus. Toivon, että myös asiakas pystyy hyödyntämään tekemäämme ohjelmistoa liiketoiminnassaan suunnitelmien mukaisesti.

8 LOPPURAPORTTI / Tuomas Hellstén Tiina Korhonen Marko Lindström Jaakko Manelius 7 Kurssipalaute Kurssiin liittyy paljon erilaisia ohjeita, joiden pelkkään lukemiseenkin menee tuntikaupalla aikaa. Ohjeita ja vaatimuksia voisi ehkä hieman karsia, jotta varsinaiseen projektityöhön liikenisi enemmän resursseja. Kolmas iteraatio, joka aiempina vuosina on ollut käytössä, ei ehkä myöskään olisi huono ajatus.