Ryhmän nimi: Crossing

Transkriptio

1 Loppuraportti Ryhmän nimi: Crossing Tekijät: Timo Nummenmaa (PM) Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått Toimeksiantaja: Timo Poranen (UTA) Päivämäärä:

2 Sisällysluettelo 1. Johdanto Yleistä Yleiskatsaus dokumenttiin Yleiskuvaus ohjelmasta Ohjelman tehtävä Ympäristö Ohjelman sijainti järjestelmässä Projektiorganisaatio Projektiryhmä Asiakas Ongelmat ja niiden analysointi Ennakoituja riskitekijöitä Ennakoimattomia riskitekijöitä Projektin hallinta Palaverit Viikkoraportit Tarkastukset ja katselmoinnit Muut Välineet, menetelmät ja tekniikat Välineet Menetelmät ja tekniikat Projektin eteneminen ja työmäärät vaiheittain Johtopäätökset projektista Kokemuksia Parannusehdotuksia Hylättyjä ratkaisuvaihtoehtoja Jatkokehitysajatuksia Kommentteja kurssista Hyvää Huonoa Uusia asioita Tilastot

3 1. Johdanto 1.1 Yleistä Tämä dokumentti on Tampereen Yliopiston Projektityö-kurssin loppuraportti. Sen tarkoituksena on koota yhteen projektin tulokset. Lisäksi arvioidaan projektin heikkoja ja vahvoja puolia sekä mietitään projektin läpiviemisestä saatuja kokemuksia. Projektityö on toiminnallisuuden osalta lähes valmis. Joitakin pieniä korjauksia on vielä työn alla, mutta tärkeimmät osat on toteutettu. Testausta suoritetaan edelleen. 1.2 Yleiskatsaus dokumenttiin Dokumentin ensimmäisissä kappaleissa esitellään yleisesti projektityönä laadittu arkkitehtuuri sekä sen toteuttamiseen osallistunut projektiorganisaatio. Seuraavaksi käsitellään projektin aikana kohdattuja erilaisia riskitekijöitä. Projektin hallintaa tarkastellaan muun muassa palaverien sekä katselmointien kannalta. Lisäksi esitellään apuna käytettyjä välineitä, kuten erilaisia ohjelmistoja, ja tarkastellaan projektin etenemistä aikataulun ja työtuntien perusteella. Dokumentin loppuosassa keskitytään projektin arviointiin. Koetun perusteella tarkastellaan kurssin onnistumista niin hyvässä kuin pahassa. Samoin käydään läpi hylättyjä ratkaisuvaihtoehtoja ja esitellään mahdollisia jatkokehitysnäkymiä. 2. Yleiskuvaus ohjelmasta 2.1 Ohjelman tehtävä Projektityönämme oli kehittää ohjelmistoarkkitehtuuri graafien ominaisuuksien, kuten risteämäarvojen, suurimman ulkotasograafin (mops) tai suurimman tasograafin (mps), laskemiseen. Lisätavoitteena oli toteuttaa arkkitehtuuri niin, että jatkossa sen pohjalle voivat kohdekäyttäjät rakentaa omia sovelluksia. Lähtökohtana toteutuksessa oli olemassa oleva apptopinv-ohjelma, jonka algoritmeista suurin osa siirrettiin osaksi arkkitehtuuria. Rakensimme myös apptopinv-ohjelman toiminnallisuutta vastaavat mps- ja mops-ohjelmat. Tämän lisäksi liitimme arkkitehtuuriin useita algoritmeja graafin risteämäarvon minimointiin ja teimme toiminnallisuutta esittelevän ohjelman. Nämä ohjelmat toimivat sekä oikeina sovelluksina että esimerkkeinä arkkitehtuurin käytöstä. 3

4 2.2 Ympäristö Asiakas käyttää arkkitehtuuria graafien tutkimiseen testaamalla erilaisten algoritmien tehokkuutta esimerkiksi graafien risteämäarvojen laskemisessa. Arkkitehtuuri tarjoaa monipuolisten ominaisuuksien lisäksi hyvän lähtökohdan toiminnallisuuden lisäämiseen olemassa olevaan kokonaisuuteen. Ensisijaisena tarkoituksena oli toteuttaa arkkitehtuuri *nix-ympäristöissä toimivaksi. Tämän lisäksi on luotu Visual Studio -projektitiedostot, joten ohjelman käyttäminen on mahdollista myös Windows-ympäristöissä. Arkkitehtuuria on kehitetty ja testattu molemmissa käyttöjärjestelmissä. Projektin eräs tarkoitus oli pilkkoa apptopinv-ohjelman toiminnallisuus pienemmiksi, tiettyyn osaalueeseen suunnatuiksi, erillisiksi ohjelmiksi. Arkkitehtuurin toteutuksessa hyödynnettiin vapaasti saatavilla olevaa GTL-graafikirjastoa. Tulevaisuutta varten tämän kirjaston tarjoamat palvelut eriytettiin muusta arkkitehtuurista niin, että asiakas pystyy tarvittaessa korvaamaan kirjaston tarjoamat palvelut paremmiksi katsomillaan toteutuksilla. 2.3 Ohjelman sijainti järjestelmässä Kyseessä on erillinen ohjelma, joka ei ole minkään suuremman kokonaisuuden osa. Tulevaisuudessa arkkitehtuurimme saattaa olla osa suurempaa ohjelmistoa, koska kyseessä on arkkitehtuuri ja kirjasto. Tämä tietenkin riippuu jatkokäyttäjien omista tarpeista. 3. Projektiorganisaatio 3.1 Projektiryhmä Projektiryhmään kuuluvat seuraavat henkilöt: Timo Nummenmaa (projektipäällikkö), Aki Mäkinen, Jussi Rantala, Rami Saarinen ja Harri Smått. Ryhmän kokoonpano pysyi samana projektin alusta lähtien. Timo Nummenmaa on projektipäällikön ominaisuudessa huolehtinut ryhmän hallinnoimisesta sekä laatinut tapaamisten pohjalta viikkoraportit. Muuten vastuut projektiryhmän sisällä voidaan jakaa karkeasti ohjelmakoodiin perehtyneisiin ja vastaavasti muihin tehtäviin keskittyneisiin. Rami ja Harri ovat olleet päävastuussa ohjelman kirjoittamisesta, kun taas Aki ja Jussi ovat keskittyneet raporttien hiomiseen ja WWW-sivujen ylläpitoon. 4

5 3.2 Asiakas Projektin asiakaana on Tampereen yliopiston tietojenkäsittelyopin laitos. Asiakkaan edustajana on toiminut Timo Poranen. Projekti julkaistaan GPL-lisenssin alaisuudessa. 4. Ongelmat ja niiden analysointi 4.1 Ennakoituja riskitekijöitä Projektin laajuus. Projektiryhmäläisten tietous graafiteoriasta oli varsin rajoittunut projektin alkaessa. Siitä huolimatta täytyi ensimmäisiä toteutussuunnitelman versioita alkaa laatimaan varsin pian. Tämä näkyi projektin edetessä (kts. seuraava riski). UTAG:n toteuttaminen. Alkuperäiset UTAG:n arkkitehtuurisuunnitelmamme menivät uusiksi useaan otteeseen projektin edetessä. Tämä johtui osaksi siitä, että ensimmäisiä suunnitelmia tehdessämme tietämyksemme projektin aihealueesta oli selvästi heikompi kuin projektin myöhemmissä vaiheissa, jolloin pystyimme havaitsemaan edellisten hahmotelmien ongelmakohdat. Tämä taas vaikeutti vastaavasti toteutusta, koska jo tehtyä koodia jouduttiin muokkaamaan jälkikäteen. GTL:n toiminta. Kuten pelkäsimme, GTL:stä löytyi bugeja. Vakavin näistä liittyi tasoominaisuuden testaukseen. Virheen paikantaminen oli sen satunnaisen esiintymisen vuoksi varsin vaikeaa. Lisäksi virheellisen toiminnan estäminen niin, ettei oma ohjelmamme kaatuisi kyseiseen kohtaan, oli haastavaa, eikä siinä lopulta täysin onnistuttukaan. Olemassa olevan kirjaston (GTL) upottamisesta oman kirjaston sisään oli ryhmäläisillä hyvin vähän käytännön kokemusta, joten ryhmä joutui yrityksen ja erehdyksen kautta etsimään luontevimman ratkaisun. Loppujen lopuksi arkkitehtuuri tältä osalta vakiintui jo varsin varhaisessa suunnittelun vaiheessa ja on osoittautunut hyväksi ratkaisuksi. Muokatun koodin testaaminen. Ohjelmamme on luonteeltaan sellainen, että sen kokonaisvaltainen testaaminen oli varsin vaikeaa. Algoritmien toiminta pystytään todentamaan pienillä syötteillä, mutta suurempien graafien yhteydessä muodostuu ohjelman ajoaika varsin pitkäksi. Samoin eri aikaan valmistuneiden toimintojen riippuvuus toisistaan oli testausta vaikeuttava tekijä. Testausta saatiin suoritettua, mutta enemmänkin aikaa siihen olisi aikataulun niin salliessa varmasti käytetty. 4.2 Ennakoimattomia riskitekijöitä Iteraattoreiden toteuttaminen. Iteraattoreiden luominen graafin solmujen ja kaarien helppoa läpikäymistä varten osoittautui ennakoitua hankalammaksi. Tämä johtui GTL:n 5

6 tietoalkioiden kapseloimisesta omiin väliaikaisiin luokkiimme. Iteraattorit saatiin toteutettua, mutta aikaa tähän kului suunniteltua enemmän. Iteraatoreita lähdettiin toteuttamaan vasta myöhäisessä vaiheessa, eikä niitä näin ole edes käytetty hyväksi arkkitehtuurissamme. Ne ovat kuitenkin olemassa. GTL:n kääntäminen 64-bittisessä (Linux) ympäristössä ei onnistu ilman konfiguraatiotiedostojen muokkausta. Näin voi olla myös UTAG:n laita, mutta emme ole päässeet sitä vielä todentamaan (koska GTL ei käänny ja tämä ongelma havaittiin vaista ihan viime hetkellä). Mikäli asiakas niin toivoo, voimme yrittää tehdä konfiguraatiosta yhteensopivan 64-bittisten järjestelmien kanssa. 5. Projektin hallinta 5.1 Palaverit Palavereja pidettiin noin viikon välein. Lomien ja pyhien sattuessa palaverien välinen aika oli joskus pidempi. Pääsääntöisesti kaikki projektiryhmäläiset olivat paikalla. Tämä säästi aikaa ja teki palavereista hyödyllisempiä, sillä läpikäytyjä asioita ei tarvinnut kerrata poissaolleille. Palaverien kesto vaihteli tunnista kolmeen tuntiin käsiteltävien asioiden määrän mukaan. Varsinkin suunnitteluvaiheessa palaverien hyöty tuli esille, sillä esimerkiksi ohjelman rakenteeseen liittyvien asioiden päättämiseen kasvotusten tapahtuva kommunikointi oli omiaan. Eri näkökulmista pystyttiin keskustelemaan välittömästi ja kaikkia tyydyttävät ratkaisut saatiin tehtyä. Palavereissa sovittiin myös kunkin ryhmäläisen seuraavan viikon tehtävistä ja täten viikkopalaverit toimivat myös työn seurannan apuna. Seuraavassa taulukossa on esitelty palaverit lyhyesti viikkoraporttien pohjalta. Päivämäärä Pituus Kokouksen aihe tuntia Toisiimme ja projektiin tutustuminen tuntia Asiakkaan pitämä esitys ja projektin varsinainen aloittaminen tuntia Projektisuunnitelma tuntia Projektisuunnitelma ja katselmoinnit tuntia Projektisuunnitelma ja vaatimusmäärittely tunti Projektisuunnitelman katselmoinnin jälkeinen lyhyt mietintätuokio tuntia Vaatimusmäärittely ja esitys tuntia Vaatimusmäärittely ja esitys tuntia Testaus- ja arkkitehtuurisuunnitelma tuntia Arkkitehtuurisuunnitelma, Doxygen tuntia Arkkitehtuuri, testaus- ja toteutussuunitelma. Hakemistorakenne 6

7 Päivämäärä Pituus Kokouksen aihe tuntia Dokumentit. GTL ja nimeämiskäytäntö tuntia CPPUnit. Dokumentit. Luokkahierarkia tunti Testaus- ja toteutussuunitelma. Lauantaina (12.2.) pidempi tapaaminen tuntia Dokumentit tuntia Toteutussuunnitelma. CA-algoritmit ja tiedostoformaatit tuntia Toteutussuunnitelma. CA-algoritmit ja tiedostoformaatit. MOPS tuntia Toteutussuunnitelma. CA-, DFS-algoritmit tuntia Arkkitehtuurimuutos. CA-, DFS-algoritmit tuntia Yhdistys/maksimointi ja id-numerot. Iteraattorit. Satunnaiset graafit. GTL:n bugi koskien taso-ominaisuuden testausta tuntia Yhdistys/maksimointi ja id-numerot. Iteraattorit. Satunnaiset graafit. GTL:n bugi koskien taso-ominaisuuden testausta tuntia Yksikkötestit. Poikkeukset ja bound-luokat. Hyperkuutio tuntia Poikkeukset. Testit. Loppuraportti. GTL:n taso-ominaisuuden testaus ja sen aiheuttama päänvaiva tuntia Poikkeukset. Esimerkkisovellukset. Loput testit. Loppuraportti ja -esitys. GTL:n taso-ominaisuuden testaus ja sen aiheuttama päänvaiva tunti Jäljellä oleva työ. Loppuraportti ja esitys. 5.2 Viikkoraportit Raportit laadittiin palaverien pohjalta. Toisinaan siis viikossa tehtiin useampiakin raportteja ja välillä taas yksi kahdessa viikossa. Raporteissa käsiteltiin edellisessä palaverissa asetettujen tehtävien edistymistä sekä kirjattiin vastaavasti uudet tavoitteet ja niiden valmistumispäivämäärät. 5.3 Tarkastukset ja katselmoinnit Projektin puitteissa järjestettiin neljä virallista katselmointia. Ne koskivat projektisuunnitelmaa, vaatimusmäärittelyä, testaussuunnitelmaa sekä toteutussuunnitelmaa. Asiakas oli kyseisissä katselmoinneissa läsnä antamassa palautetta ja mahdollisia tarkennuksia projektin suhteen. Katselmointien ehkäpä paras anti olivat keskustelut asiakkaan kanssa, joiden perusteella niin projektin aihealueeseen kuin yksittäisten ominaisuuksien toteuttamiseenkin saatiin selvennystä. 7

8 Seuraavassa taulukossa katselmointien aikataulu ja roolit. Katselmointi Päivämäärä Harri Rami Jussi Aki projektisuunnitelma sihteeri puheenjohtaja esittelijä vaatimusmäärittely sihteeri puheenjohtaja esittelijä testaussuunnitelma esittelijä sihteeri puheenjohtaja toteutussuunnitelma puheenjohtaja esittelijä sihteeri Ryhmän sisällä emme järjestäneet erillisiä katselmointeja. 5.4 Muut Projektin sisällä pidimme yhteyttä muutamia kertoja viikossa palaverien lisäksi. Ensisijaisena keinona oli sähköpostiviestintä, jota riippuen projektin vaiheesta käytettiin huomattavan paljon. Kaikkia asioita käsiteltiin jossakin määrin sähköpostin välityksellä. Reaaliaikaiseen kontaktiin palaverien lisäksi emme juurikaan nähneet tarvetta. Ircciä käytimme pariin kertaan. Joulukuun esitykseen valmistautumiseen irc osottautui hyödylliseksi. Lisäksi meillä oli yksi pidempi tapaaminen lauantaina 12.2, joka olikin hyödyllinen jatkosuunnitelmien kannalta. Tuolloin pidimme reilun seitsemän tunnin kokoontumisen arkkitehtuurin rakenteesta ja olemuksesta. 6 Välineet, menetelmät ja tekniikat 6.1 Välineet Projektin alussa ja sen kuluessa suoritettiin olemassa olevien kirjastojen ja apuohjelmien etsintää ja arviointia. Pyrkimyksenä oli etsiä hyviä perustyökaluja projektityön helpottamiseksi aina koodauksesta dokumentointiin ja asioiden organisointiin saakka. Ensinnäkin varsinaista koodia ollaan kirjoitettu sekä Linux- että Windows-ympäristössä. Linuxin puolella koodin kirjoittamiseen käytettiin ohjelmia KDevelop 1 ja Anjuta 2. Lisäksi Linuxin puolella käytettiin projektin konfigurointiin ja kääntämiseen käytetään Automakea 3 ja Autoconfia 4, joiden avulla saadaan tehtyä käännösprosessista *nix ympäristöille hyvin tunnisomaisen ja vakiintuneen tavan mukaisen. Windowsissa puolestaan käytettiin Visual Studio C Express Editionin beta

9 versioita 5. Pyrimme käyttämään C++-kielen lähes standardia STL-apukirjastoa 6 Template Library) mahdollisimman tehokkaasti hyväksi. (Standard Yksikkötestaamisen apuna käytettiin CPPUnit-ohjelmaa 7, josta meillä oli käytössä versio CPPUnit oli hyödyllinen apuväline, koska sillä sai helposti luotua testirutiineja. Testijoukoista pystyttiin koostamaan kokonaisia sarjoja, joiden ajaminen ja raportointi voitiin automatisoida. Suurena apuna projektia tehtäessä on ollut myös CVS-versionhallintajärjestelmä. Ilman CVSoikeuksia tällaista projektia olisi ollut hyvin hankala tehdä, sillä tämä mahdollisti sen, että pystyimme hallitsemaan arkkitehtuurimme versoita keskenämme. Koodin dokumentoinnin apuvälineenä meillä oli käytössä Doxygen 8. Artistic Style 9 -nimistä ohjelmaa käytimme, jotta saimme koodimme sisennykset yhtenäistettyä. Meillä oli myös pienessä käytössä sekä Tulip 10 että yed 11, joilla voidaan visualisoida gml-muodossa tallennettuja graafeja. 6.2 Menetelmät ja tekniikat Kehitetty arkkitehtuuri perustuu arkkitehtuurissa olevan toiminnallisuuden suoraan käyttämiseen ja sen laajentamiseen perinnän kautta. Olemassa olevia suunnittelumalleja pyrittiin käyttämään sopivissa kohdin. Arkkitehtuuri suunnittelun puolesta tosin on varsin selkeä ja selvisimme lähinnä polymorfismin ja tehdasmetodien hyödyntämisellä. DataElement luokkarakenne noudattaa pitkälti prototyyppi-suunnittelumallin periaatteita. Pääosin kuitenkin pitäydyttiin olio-ohjelmoinnin perusteissa. 7 Projektin eteneminen ja työmäärät vaiheittain Projekti voidaan jakaa kolmeen osaan. Ensimmäisessä vaiheessa tutustuttiin projektiin, apptopinv-ohjelmaan, etsittiin LEDAn korvaaja ja luotiin pohja tulevalle projektisuunnitelmassa ja vaatimusmäärittelyssä. Arvioimme alkuvaiheessa, että tämä jakso saadaan suoritettua marrasjoulukuun vaihteessa. Seuraavassa vaiheessa korvattiin LEDA, tehtiin arkkitehtuuri-, testaus- ja toteutussuunnitelmat. Tämän arvioimme kestävän joulukuulta helmikuun loppuun. Viimeisessä vaiheessa suoritettiin varsinainen toteutus ja testaus, jonka oli määrä kestää maaliskuun alusta toukokuulle

10 Ensimmäinen vaihe kesti suunniteltua pidempään, mutta toisaalta toinen jakso oli huomattavasti lyhyempi. Ensimmäiseen vaiheeseen meni oikeastaan koko vuosi Toinen vaihe puolestaan alkoi vuoden 2005 alusta, mutta se saatiin kuitenkin päätökseen jo hieman helmikuun puolenvälin jälkeen. Jos on pakko laitta jokin raja, jolloin siirryttiin vaiheesta II vaiheeseen III, niin se on viikon seitsemän loppuminen. Toisaalta aivan selkeitä rajoja on hankala laittaa, sillä vaiheissa oli selkeät ylimenojaksot, jolloin vaiheet menivät osittain päällekkäin. Seuraavassa taulukoissa on esitetty projektin jäsenten käyttämät tuntimäärät sekä yhteistuntimäärät vaiheittain. Vaihe I: viikko Aki Harri Jussi Rami Timo yhteensä: yhteensä: Vaihe II: viikko Aki Harri Jussi Rami Timo yhteensä: yhteensä:

11 Vaihe III ja lopulliset tuntimäärät: viikko Aki Harri Jussi Rami Timo yhteensä: yhteensä vaihe III yht. koko projekti Projektin aikana siis käytettiin työtunteja tasan Tämä ylittää 40 tunnilla projektille varatun määrän, eli 1060 tuntia, joka saadaan, kun lasketaan mahdolliset opintoviikot yhteen ja muutetaan tuntimuotoon. Kaikki jäsenet pysyivät kuitenkin suurinpiirtein tavoitellussa tuntiaikataulussa. Rami Saarisen selkeästi suurempi tuntimäärä selittyy viikon 19 bugin etsimiselle, johon hänellä meni lähes kokonaisuudessaan yksi viikonloppu. Projektisuunnitelmassa käytettiin Cocomo-malleja arvioimaan työnmäärää. Arviot menivät onneksi yläkanttiin, sillä aikamäärät olivat 1325 tunnista 1540 tuntiin. Näin suuria tuntimääriä ei oltaisi mitenkään pystytty hallitsemaan. Seuraavassa kaaviossa havainnollistetaan vielä työtuntien jakautumista. Janasta näkee helposti myös vaiheiden päättymisen ja uuden alkamisen. Ensimmäinen vaihe päättyi selvästi joululomaan, jolloin kaikki keskittyivät rauhoittumiseen ja energiavarastojen lataamiseen. Toinen vaihe puolestaan loppui hiljaisempaan viikkoon seitsemän. Sen jälkeen alkoi varsinaisesti toteutus kiihtyvällä tahdille huipentuen lopulta toiseksi viimeiseen viikkoon. 11

12 90 Tuntimäärät Tunnit Viikko Tuntikaavioita ei voi tarkentaa enää työnlaadun mukaan, sillä projektin jäsenet eivät pitäneet kirjaa, minkälaista työtä kulloinkin oli tekemässä. Vaihe I oli kuitenkin jokaisella jäsenellä oikeastaan samanlainen. Vaiheessa II alkoi erikoistuminen. Aki Mäkinen ja Jussi Rantala keskittyivät enemmän dokumenttien viimeistelyyn, kun puolestaan Harri Smått ja Rami Saarinen erikoistuivat lähinnä koodaamiseen. Projektipäällikkö Timo Nummenmaan urakka puolestaan väheni projektin edetessä suhteessa muihin jäseniin, sillä hänellä oli kaksi projektia vedettävänään. Jokainen jäsen kuitenkin osallistui kaikkiin työlaatuihin. Seuraavassa projektissa tehdyt dokumentit sekä näiden kehityskaari: Projektisuunnitelma: versio Projektiryhmä Dokumentin ensimmäinen yhteenkoottu raaka versio versio Projektiryhmä Lähes valmis dokumentti versio Projektiryhmä Valmis tarkastukseen laitettu dokumentti versio Mäkinen, Saarinen, Katselmoinnin perusteella korjattu versio Smått 12

13 Vaatimusmäärittely: versio Projektiryhmä Dokumentin ensimmäinen yhteenkoottu raaka versio versio Projektiryhmä Lähes valmis dokumentti versio Projektiryhmä Valmis tarkastukseen laitettu dokumentti versio Mäkinen, Saarinen Katselmoinnin perusteella korjattu versio versio Mäkinen Lisätty yksi tarkennus asiakkaan toivomuksesta Testaussuunnitelma: versio Projektiryhmä Dokumentin ensimmäinen yhteenkoottu raaka versio versio Projektiryhmä Lähes valmis dokumentti versio Mäkinen, Saarinen Valmis tarkastukseen laitettu dokumentti versio Mäkinen, Saarinen, Katselmoinnin perusteella korjattu versio Smått Toteutussuunnitelma: versio Projektiryhmä Dokumentin ensimmäinen yhteenkoottu raaka versio versio Projektiryhmä Muokattu esiversio versio Projektiryhmä Valmis tarkastukseen laitettu dokumentti versio Mäkinen, Saarinen, Katselmoinnin perusteella korjattu versio Smått Ryhmä teki projektissa yhteensä 5230 riviä koodia. Sellaisenaan uudelleenkäytettyä koodia ei ole yhtään. Suurin osa koodista on kuitenkin muokattua koodia alkuperäisestä apptopinv-ohjelmasta. Jonkun verran olemme tehneet myös täysin uutta koodia, mutta tämän osuus on alle puolet. Arvioimme, että täysin uuden koodin osuus koko määrästä on noin 35%. Cocomo-mallien mukaan arvioitiin projektin alussa, että koodia tulisi noin 4600 riviä. Tämä ylittyi kuitenkin melko selvästi. Virheenkorjauksiin käytettyä aikaa on todella hankala, ellei jopa mahdotonta kertoa. Arvioita voidaan aina antaa, mutta nämä voivat heittää pahastikin. Aika ei kuitenkaan ole kovin iso, sillä todella suuria ongelmia ei ilmaantunut kuin muutama: GTL:n taso-ominaisuuden testauksen ongelmat ja viime viikonloppuna ilmaantunut ongelma CA-algoritmissa. Asiakkaalle on luovutettu jo kaikki projektin aikana tuotetut dokumentit (projektisuunnitelma, vaatimusmäärittely, testaus- ja toteutussuunnitelma). Asiakkaalle toimitetaan vielä lopullinen tuote, eli UTAG-kirjasto esimerkkiohjelmineen sekä mahdollisesti pieniä päivityksiä aikaisempiin dokumentteihin. 13

14 8 Johtopäätökset projektista Tämä projektityö oli hieman erilainen lähtökohdiltaan kuin monet muut projektit. Tästä syystä ohjeistus ei välttämättä kaikilta osiltaan sopinut tämän projektin läpiviemiseen. Onneksi esimerkiksi dokumenttipohjat olivat vain suuntaa antavia, joten saatoimme soveltaa niitä haluamallamme tavalla. Tietenkin tämänlaatuinen projekti on ihan erityylinen kuin aikaisemmat yliopiston kurssit. Osalla meidän ryhmäläisistä oli kuitenkin ennestäänkin kokemusta projekteista työelämän puolelta. Kurssina projektityö on tietenkin varsin teoreettinen, sillä kaikki käydään oppikirjan mukaisesti läpi. Tällainen järjestelmällinen tapa tehdä töitä auttaa varmasti tulevaisuudessa, sillä jokaisen ryhmän jäsenen piti olla kaikessa mukana aina projektisuunnitelmasta loppuraporttiin antaen hyvän yleiskuvan keskimääräisestä projektin kulusta. Projekti on kokonaisuudessaan onnistunut hyvin. Olemme saaneet valmiiksi kaikki projektin suunnitteluvaiheessa listatut ensisijaiset tavoitteet ja toissijaisistakin tavoitteista olemme saaneet muutaman suoritettua. Aikataulukin on pitänyt melko hyvin, tosin muutamassa kohdassa on täytynyt joustaa, mutta ei pahasti. Muutaman kerran ehkä olemme laittaneet liian optimistiset aikataulutavoitteet viikkopalavereissa, joissa sitten olemme joutuneet hieman antamaan periksi. Lopulta aikataulukaan ei kuitenkaan ole ollut ongelma. 8.1 Kokemuksia Projektin aikana mietittiin monia eri vaihtoehtoja ongelmien ratkaisemiseksi. Harvemmin ongelmiin oli edes esillä yhtä tiettyä ratkaisua. Joskus paras ratkaisumalli löytyi vasta kokeilun kautta. Mitään yksittäistä syytä ratkaisujen hylkäämiseksi ei oikeastaan löydy. Suunnittelu ja päätökset pyrittiin tekemään yhteistuumin ja ristiriitatilanteissakin saavuttiin nopeasti kaikkia tyydyttäviin ratkaisuihin. Positiivisesti kurssin aikana yllätti itse projekti. Alussa ryhmän käsitys projektin aihepiiristä ei ollut selvillä, sillä graafiteoriat eivät kenelläkään olleet täysin tuttuja. Projektin aikana kuitenkin asiat kävivät hiljalleen tutuiksi ja lopulta UTAG-kirjaston rakentaminen sujui melko kivuttomasti. Katselmoinnit olivat todella hyödyllisiä tilaisuuksia, sillä niissä asiakas myös selitti paljon graafeihin liittyviä asioita ja selvennyksiä. Usein dokumentteja tehtäessä asia ei ollut vielä täysin selkeytynyt, mutta viimeistään katselmoinneissa saimme varmuutta monista asioista. 14

15 8.2 Parannusehdotuksia Näin jälkikäteen katsottuna emme juurikaan olisi pystynyt tekemään asioita eri tavalla, sillä projektin läpiviemiseen vaikutti suuresti aihe, joka ei ollut tuttu. Jos nyt lähdettäisiin tekemään projektia uudelleen, aikaa tuskin kuluisi yhtä paljon kuin nyt, mutta tämä ei riipu mitenkään projektin aikana tehdyistä päätöksistä. Ainoa suurempi asia, jonka kanssa olisi voinut toimia hieman erilailla, on iteraattorit. Aloimme suunnitelemaan iteraattoreiden toteutusta liian myöhään, joten vaikka saimme ne toteutettua, emme ehtineet ottamaan niitä käyttöön algoritmien toteutuksessa. 9 Hylättyjä ratkaisuvaihtoehtoja Projektin ensimmäisessä vaiheessa jouduttiin päättämään LEDA:lle 12 korvaaja. Kävimme läpi muutamia eri vaihtoehtoja, joista valittiin GTL. Hylätyissä vaihtoehdoissa olivat mm. GOBLIN 13, joka vaikutti liian laajalta, ja kokonaan oman graafikirjaston luominen. Monet hylätyt ratkaisuvaihtoehdot liittyvät kirjaston luokkarakenteeseen. Rakennetta ollaan käännelty ja väännelty moneen otteeseen ennen kuin päädyttiin nykyisen kaltaiseen yhdistelmään. Toteutussuunnitelmaan hahmoteltu luokkarakenne muuttui todella radikaalisti katselmoinnissa. Tämä vanha idea on edelleen nähtävissä toteutussuunnitelman versiossa Jatkokehitysajatuksia Seuraava jatkokehitysaskel on varmasti GTL-graafikirjaston korvaaminen. Käytössä oleva versio on GTL-kirjaston viimeinen ilmaisjakelussa ollut versio. Sitä uudemmat versiot ovat maksullisia. GTL asettaa ohjelmallemme joitakin rajoitteita sekä tietyissä tilanteissa epävakaan alustan. Lähitulevaisuudessa GTL korvataan ehkä jollain toisella vapaassa jakelussa olevalla graafikirjastolla tai sitten kokonaan omalla toteutuksella. Yhtenä vaihtoehtona GTL:n korvaajaksi ollaan mainittu GOBLIN, johon olemme ottaneet jo yhteyttäkin, tosin vastausta emme ole vielä saaneet. Lisäksi jatkossa kirjastoon voidaan lisätä uusia algoritmeja, kuten esimerkiksi algoritmit graafin paksuuden ja ulkopaksuuden laskemiseen. Tästä syystä UTAG-kirjasto on rakennettu siten, että siihen on helppo lisätä uusia ominaisuuksia

16 Parametrisoituun graafiin voidaan tallettaa erilaisia DataElement-luokan periviä luokkia. Tällä hetkellä toteutus on toimiva, mutta rajoittunut sillä tavalla, että parametrisoitua graafia ei voida kopioida toiseen siten, että tietoalkiot kopioituisivat myös. Tämä johtuu siitä, että tietoalkioon voi olla liitettynä tietoa, joka on graafille ominaista, ja jonka kopioiminen voi olla erittäin hankalaa. Varsinkin kun kopioinnille pitää tehdä yhtenäinen rajapinta, jotta parametrisoitu graafi pystyy kopioinnin suorittamaan automaattisesti. Esimerkiksi tietoalkio, johon on liitetty yksittäinen kaari, aiheuttaa jo vakavan ongelman: Kaari yhdistää kaksi graafin solmua. Tehdessämme kopion graafista teemme kopioon uudet vastaavat solmut. Koska käytämme GTL kirjastoa, on meillä ainoa tapa identifioida solmuja niiden Id numeron perusteella. Id tulee GTL:stä. Id numerointi tapahtuu automaattisesti siten että ensimmäinen luotu solmu on id arvoltaan nolla. Solmuja voi poistaa. Id:t eivät muutu. Koska solmuja voi poistaa ei kaarten kopioita voi tehdä Id numeroiden perusteella, sillä kopion solmujen Id:t voivat olla eri kuin alkuperäisten solmujen. Tehtäessä uutta graafitoteutusta tämä kannattaa ottaa huomioon ja miettiä olisiko mahdollista toteutta tietoalkioiden kopionti jollain mielekkäällä tavalla, jolloin parametrisoiduista graafeista tulisi entistäkin hyödyllisempiä. Jatkossa voisi myös ajatella hajautetun järjestelmän rakentamista arkkitehtuurin varaan. Monet graafialgoritmit vaativat pitkiä suoritusaikoja ja useita iteraatioita ja prosessikuorman jakaminen usealle koneelle nopeuttaisi toimintaa huomattavasti. Jatkoprojektina voisi esimerkiksi olla ohjelmiston mukauttaminen laitoksen klusterissa toimivaksi. 11 Kommentteja kurssista 11.1 Hyvää Hyvää kurssissa oli kokonaisen kehitysprosessin läpikäynti ja kaikkien osallistuminen jokaiseen prosessin vaiheeseen. Tämä on tarjonnut hyvän yleiskuvan tavanomaisesta projektin kulusta ja on täten valmentanut kurssilaisia työelämään ja todelliseen ohjelmistotyöhön. Dokumenttien tekeminen on tuottanut varsin hyviä näkökulmia tällaisiin suurempiin projekteihin ja kaikkeen mitä niissä pitää ottaa huomioon. Katselmointitilaisuudet olivat kurssin aikana todella hyödyllisiä. Näissä saimme paljon uusia ideoita ja selvennyksiä koskien aihetta. 16

17 11.2 Huonoa Kurssilla käsiteltiin liian vähän raportoinnissa vaadittuja tekniikoita ja teorioita. Raporttien aloittaminen oli täten vaikeata, sillä ainoa lähtökohta oli välillä hieman sekavat dokumenttipohjat, jotka eivät edes sopineet täysin meidän projektiimme. Jatkossa olisi hyvä, jos jokaisen raportin teosta voitaisiin pitää luentoja. Tämä avartaisi myös kurssilaisten näkemystä erilaisista tekniikoista ja teorioista, kun nyt ne katsotaan nopeasti Pressmanin kirjasta ehkä ymmärtämättä syytä tai teorian tai tekniikan syvällisempää tarkoitusta. Toisaalta myös katselmointien ennalta määrätyt ajankohdat tuottivat hiukan turhautumista. Kaikki projektit kulkevat kuitenkin omia ratojansa, joten valmiiksi määrätty jako ei välttämättä näin ole paras mahdollinen ositus. Tästä johtuen myös suunnitelu- ja toteutusvaiheet sekoittuivat hieman. Toteuttaminen piti aloittaa jo, vaikka suunnittelu ei ollut edes valmis Uusia asioita Projektin hallinnalliset teoriat ja tekniikat. Katselmointitilaisuudet olivat myös uusia osalla projektin jäsenistä sekä tällaisen suuremman projektin läpivienti kokonaisuudessa. 17

18 12 Tilastot Ryhmän nimi: Crossing Asiakas: Tampereen yliopiston tietojenkäsittelyopin laitos (edustajana Timo Poranen) Viikkotyötunnit: Vaihe I: 25,7% (283 tuntia) Vaihe II: 17,6% (194 tuntia) Vaihe III: 56,7% (623 tuntia) 90 Tuntimäärät Tunnit Viikko Dokumenttien sivumäärät yhteensä: 100 sivua Projektisuunnitelma: 24 sivua Vaatimusmäärittely: 32 sivua Testaussuunitelma: 20 sivua Toteutussuunnitelma: 24 sivua Koodirivien määrä yhteensä: 5230 riviä Kokonaan itse tehty: n. 35% Uudelleenkäytetty: n. 65% 18