L models. Loppuraportti. Ryhmä Rajoitteiset

Transkriptio

1 Teknillinen korkeakoulu T Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Loppuraportti Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset Hannu Kauppinen Ensimmäinen versio, dokumentin runko Hannu Kauppinen Täydennetty projektin tarkoitus ja kulku Hannu Kauppinen Lisätty tekstiä projektin lopputuloksista Hannu Kauppinen Viimeistelty sisältöä ajankäytöstä ja koodimääristä Jouni Karppinen Lisätty Hannun toimittamat puuttuvat kohdat tekstistä. Dokumentti tarkastettu ja korjattu DE-vaiheen palautusta varten.

2 Sisällysluettelo 1 Johdanto Projektin kulku Projektin suunnittelu Toteutus Toteutus Toteutus Toimitus Jälkivaikutus Tulokset Työkäytännöt Työkalut Projektista opittua Palaute kurssista Kurssin luonteen esiintuominen Projektipäällikön luonne Kurssin arvostelumalli Pakollisten työkalujen käyttö... 11

3 1 Johdanto Projektin tavoitteena oli kehittää Teknillisen korkeakoulun Ohjelmistoliiketoiminnan ja -tuotannon instituutin WeCoTin (Web Configuration Technology) -tutkimusryhmälle lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija. Projektin kuluessa oli tarkoitus myös tutustua nykyisiin työkaluihin lineaaristen rajoitteiden tyydyttämistehtävien ratkaisemiseksi sekä näiden käyttökelpoisuuteen verkkosovelluksissa. 1

4 2 Projektin kulku Projekti jaettiin viiteen vaiheeseen, jotka olivat projektin suunnittelu (PP), toteutus 1 (I1), toteutus 2 (I2), toteutus 3 (I3) ja toimitus (DE). Taulukko 1 esittää näiden vaiheiden aikataulut. Kahden viimeisen vaiheen aikatauluja muutettiin suunnitellusta, sillä toteutus 3 vaiheen päättänyt projektikatselmus voitiin aikatauluteknisistä syistä pitää vasta , jolloin viimeinen vaihe alkoi päivää suunniteltua myöhemmin. Iteraatio Ajanjakso Kesto Projektin suunnittelu (PP) viikkoa Toteutus 1 (I1) viikkoa Toteutus 2 (I2) viikkoa Toteutus 3 (I3) viikkoa Toimitus (DE) viikkoa Taulukko 1: Projektin vaiheiden aikataulutus. Missään vaiheessa projektia ei mitään suurempia haasteita tullut vastaan. Suurimmat ongelmat liittyivät motivaation ylläpitoon ja työnohjaukseen. Nämä aiheutuivat kokemattomasta projektipäälliköstä, joka luotti liiaksi ryhmän jäsenten henkilökohtaiseen työnohjaukseen. Kokematon ryhmä sai kuitenkin projektin etenemään kohtuullisesti myös omalla painollaan, mikä mahdollisti projekin loppuunsaattamisen lähes tavoitteiden mukaisesti. Kurssin ulkopuolella projektin haasteeksi muodostui kehitettävän järjestelmän hyödyntämistä koskevan sopimuksen laatiminen. Teknillisen korkeakoulun sopimuskäytäntö osoittautui hyvin kankeaksi, jonka vuoksi sopimuksen viimeistely jäi projekin loppuessa keskeneräiseksi. Osapuolet ovat hyväksyneet sopimuksen ehdot jo vuoden 2003 puolella, mutta sopimuksen teknistä toteutusta ei ole saatu valmiiksi. Seuraavassa käydään läpi projektin kaikki vaiheet ja esitellään niissä esille tulleita asioita. 2.1 Projektin suunnittelu Projektin suurin haaste liittyi järjestelmän matemaattisen taustan ymmärtämiseen. Ensimmäinen vaihe kuluikin tutustuttaessa lineaaristen rajoitteiden ratkaisemiseen. Samaan aikaan suunniteltiin myös projektin toteutusta, työnjakoa ihmisten välillä sekä valittiin käytettävät työkalut. Vaiheen suurin yllätys liittyi käytettyihin resursseihin, sillä järjestelmän toimintaperiaatteen ymmärtäminen vei enemmän resursseja kuin oli oletettu. Kun käytössä ollut henkilöresurssien seurantajärjestelmä ei ollut vielä käytössä täysipainoisesti, muodostui resurssien käytöstä pieni ongelma myöhempiä iteraatioita suunniteltaessa. 2.2 Toteutus 1 Ensimmäinen varsinainen toteutusvaihe sujui kohtuullisen hyvin. Työt painottuivat järjestelmän komponenttien toimintaan ja niitä ei pyrittykään vielä liittämään kokonaisuudeksi, vaan järjestelmän integrointi oli suunniteltu tapahtuvan seuraavassa vaiheessa. 2

5 Ensimmäisestä vaiheesta saadun palautteen perusteella ryhmän sisäistä vastuunjakoa mietittiin hieman uudelleen ja vaiheen aikana ryhmän jäsenten vastuujako muotoutuikin kohdalleen. Tästä jouduttiin poikkeamaan vasta aivan projektin loppuvaiheessa. Vaiheen ainoa ongelma muodostui yhden projektiryhmän jäsenen pidemmästä lomasta, jonka yksityiskohtia hän ei tiedottanut tarpeesti selvästi muulle ryhmälle. Tämän vuoksi hänen tehtäväkseen suunniteltujen komponenttien toteutus jouduttiin siirtämään seuraavaan vaiheeseen. Vaiheesta saadusta palautteesta ilmeni, että vaiheesta saamaamme arviointia oli heikentänyt se, että emme palauttaneet vaiheen päättyessä toteuttamaamme ohjelmakoodia mentorille tai asiakkaalle. Tämä yllätti meidät, sillä olimme olettaneet, että irrallisten komponenttien toimittamisesta ei olisi kenellekään hyötyä. Lisäksi ohjeistuksessa asiaa ei ollut tuotu tarpeeksi selvästi esille. 2.3 Toteutus 2 Toisen toteutusvaiheen oli tarkoitus olla projektimme työmäärällisesti laajin. Ajatus oli saattaa tuote tässä vaiheessa sellaiseen vaiheeseen, että kahdessa viimeisessä vaiheessa voidaan keskittyä parantelemaan tuotetta asiakkaan antaman palautteen perusteella. Vaihe osoittautui kuitenkin pitkästä kestostaan huolimatta hankalaksi hyödyntää täysipainoisesti. Kaikki projektiryhmän jäsenet olivat vaiheesta pitkän osan henkisesti joululomalla ja pitkä kesto korosti mielikuvaa siitä, että projektityön kanssa ei ole kiire. Tämän seurauksena vaiheessa jäi merkittävästi työtä tekemättä, mikä heijastui sitten myöhempien vaiheiden sisältöön. Jälkikäteen ajateltuna tämä vaihe oli kriittinen projektin onnistuneen toteutuksen kannalta. Kymmenen viikkoa kestänyt jakso olisi pitänyt käyttää tehokkaammin hyväksi ja tämän asian järjestäminen olisi ollut projektipäällikön tehtävä. Tarkempi henkilökohtainen seuranta olisi varmasti edistänyt töitä vaiheen aikana. Nyt kun myös projektipäällikkö oli henkisesti lomalla, ei kukaan ollut painostamassa töitä tekemään. 2.4 Toteutus 3 Myös vaihetta toteutus 3 vaivasi jonkinasteinen väsymys, sillä tehtävät edistyivät suunniteltua hitaammin. Loppuvaiheessa ryhmään alkoi kuitenkin herätä uudestaan näyttämisen halu ja työt etenivät jälleen. Työ painottui paljon dokumentaation viimeistelyyn sekä tiettyjen suurempien puutteiden korjaamiseen. Ongelmia aiheutti jonkin verran se, että puutteellisien komponenttien tekijöillä oli työtunteja käytettynä jo huomattavan paljon, kun taas muutamalla muulla ryhmän jäsenellä oli tunteja vielä reilusti käyttämättä. Komponenttien kehittäjien vaihtaminen söi jonkin verran resursseja aikaisempaan toteutukseen tutustumisessa, mutta tämä ei muodostunut ylipääsemättömäksi esteeksi. Toisaalta tämä toimi myös hyvänä testinä ohjelman jatkokehitettävyydestä. 2.5 Toimitus Projektin viimeinen vaihe oli tarkoitettu dokumentaation viimeistelyyn. Edellisten vaiheiden jälkeen projekti oli kuitenkin vielä keskeneräinen ja erilaisia lisäpiirteitä jäi toteutettavaksi viimeiseen vaiheeseen. Töiden painopiste oli kuitenkin lopputuotteen viimeistelyssä ja 3

6 vaiheen lopussa julkaistiin versio 1.0 projektin lopputuotteesta eli Lmodels-ohjelmasta. Vaiheen ongelmat aiheutuivat aikatauluteknisistä kysymyksistä. Vaihe oli erittäin lyhyt, varsinkin kun vaiheiden vaihtuessa lähes viikko kuluu hukkaan palautuksen ja katselmoinnin vaikutuksesta. Näin ollen tehokasta työaikaa vaiheeseen jäi vain reilu viikko. Pitkillä päivillä työt kuitenkin etenivät ja päästiin hyvään lopputulokseen. 4

7 3 Jälkivaikutus Projektiin suunniteltiin käytettävän 190 tuntia jokaista projektiryhmän jäsentä kohden eli yhteensä 1330 tuntia. Lopputulos jäi hieman tämän alle eli 1250 tuntiin, joskin vaihtelua projektiryhmän jäsenten välillä myös oli. Käytetyt tuntimäärät vaihtelivat 140:n ja 220:n välillä. Projektille asetettiin alkuvaiheessa selkeät vaatimukset, jotka oli priorisoitu kolmeen eri kategoriaan. Kaksi tärkeintä vaatimuskategoriaa pystyttiin kattamaan täysin ja kolmannestakin kategoriasta suuri osa pystyttiin huomioimaan kehitystyössä. Osa piirteistä hylättiin jo aikaisessa vaiheessa ja lisäksi asiakkaalta tuli tiettyjä uusia toiveita kolmannen kategorian vaatimusten tilalle. Projektin aikana käytössä olleeseen bugi-järjestelmään kirjattiin 76 erilaista puutetta tai parannusehdotusta ohjelmaan liittyen. Näistä valtaosa huomioitiin kehitystyössä, ja ainoastaan 3 jäi toteuttamatta. Nämäkin liittyivät lähinnä uusiin toimintoihin, jotka jossain vaiheessa projektia uskottiin saatavan lopputuotteeseen mukaan. Ohjelman koko kasvoi tasaisesti projektin edetessä. Projektin päättyessä ohjelman koko oli hieman yli riviä koodia, jota oli höystetty yli rivillä kommentteja. Taulukko 2 osoittaa hyvin, kuinka projektin alkuvaiheessa koodin kommentointi oli puutteellista. Tämän vuoksi projektin loppuvaiheessa on tehty paljon töitä asian kanssa. Kommentointi on oleellista, sillä järjestelmän on tarkoitus olla jatkokehitettävissä ulkopuolisin voimin. I1 I2 I3 DE NCLOC Kommentteja Yhteensä Taulukko 2: Ohjelmakoodi- ja kommenttirivien määrän kehitys. Projektin lopputuloksia voidaan suhteuttaa normaalituottavuuteen käyttämällä Boehmin 1970 luvulla laatimaa COCOMO (Constructive Cost Model) -mallia vastaavankokoisen projektin työmäärän arviointiin ja suhteuttamalla tässä projektissa tehty työmäärä tähän arvioon. Kuten edellä esitettiin, sisältää Lmodels noin riviä koodia. COCOMO-mallin mukaan kyseessä oli orgaaninen tuote (organic), jolloin työmääräarvio projektille (henkilötyökuukausina) saadaan korottamalla arvioitu tuhansien rivien lukumäärä (kloc) potenssiin 1,05 ja kertomalla saatu tulos luvulla 2,4. Näin arvioituna projektin työmäärä olisi ollut noin 11,8 henkilötyökuukautta eli tuntia. Projektiin käytettiin kuitenkin vain noin tuntia eli huomattavasti vähemmän kuin mitä arviointimenetelmä olisi ehdottanut. Käyttämällä COCOMO81:n korjauskertoimia olisi arvio ollut varmasti lähempänä totuutta, sillä vaikka tuotteen monimutkaisuus olisi mahdollisesti kasvattanut kerrointa, olisi käyttöjärjestelmän ja käytetyn ohjelmointikielen tuntemus vastaavasti laskenut sitä merkittävästi. Lisäksi tuotettu ohjelmakoodi sisälsi kohtalaisen paljon käyttöliittymän toteutukseen liittyvää toteutusta, joka on rivimäärältään suurta mutta toiminnallisuudeltaan varsin vähäistä. Tällaista koodia pystyy kirjoittamaan suuret määrät helposti, mikä osaltaan nostaa projektin näennäistä tuottavuutta. 5

8 4 Tulokset Projektisuunnitelmassa projektille oli asetettu asiakkaan lähtökohdista 10 tavoitetta sekä niille varmistuskriteerit. Näissä tavoitteissa onnistumista voi arvioida vain projektin asiakas. Projektiryhmän kannalta tavoitteissa pysyttiin suunnitellulla tavalla ja yhtään asiakkaalla ollutta tavoitetta ei ole projektin aikana hylätty. Projektiryhmän omista tavoitteista suurin osa täytyi projektin aikana. Näitä on käyty tarkemmin läpi kappaleessa 7. Kehitetyn järjestelmän laatu on vaikea kysymys, mikä asettaa testaukselle omat haasteensa. Suunnitellut testitapaukset on saatu suoritettua onnistuneesti, mutta pieniä virheitä on järjestelmässä jouduttu korjaamaan loppuun asti. Tämän vuoksi on hyvin mahdollista, että joitain ei-toivottuja piirteitä järjestelmästä vielä ilmenee. Asiakkaan palaute on ollut pääosin positiivista, joten siltä osin projekti on ollut onnistunut. Mitään suuria puutteita järjestelmässä ei tältä osin ilmennyt, mutta toisaalta muutamia toivottuja ominaisuuksia ei loppujen lopuksi ehditty toteuttaa, vaikka välillä uskoimmekin pystyvämme ottamaan vielä tiettyjä kehitysajatuksia mukaan toteutukseen. Vertaisryhmän tekemässä testauksessa ei toiminnallisia puutteita pääjärjestelmässä ilmennyt, mutta toisaalta aiheen haasteellisuus pakotti meidät ohjaamaan heidän testaustaan enemmän järjestelmän käytettävyyteen kuin varsinaiseen toimintaan. Käytettävyyden osalta saimme kuitenkin arvokasta palautetta, joka huomioitiin vielä kehitystyössä. Muutamia vaatimusmäärittelyssä esitettyjä toimintoja ei projekin aikana saatu toteutettua. Lisäksi projekin aikana syntyi huomattavasti uusia ideoita järjestelmän kehittämiseksi. Nämä ajatukset on toimitettu asiakkaalle, sillä osa niistä vaatii teoreettista analyysia ennen toteutukseen ryhtymistä. Muutamia yksinkertaisia ideoita, joilla järjestelmää voi jatkokehittää, ovat erilaisten ratkaisutapojen vertailu sekä mallin optimoinnin parantaminen. Erilaisilla ratkaisutavoilla viitataan tässä lopullisen sekalukumallin ratkaisuun. Järjestelmään voidaan liittää erilaisia ratkaisijoita tai käyttää saman ratkaisijan eri toimintatapoja ratkaisun hakemiseen. Näin voidaan saada lisää tietoa mallien käsittelystä sekä ratkaisutapojen tehokkuudesta erilaisten ongelmien ratkaisussa. Optimoinnilla voidaan pyrkiä pienentämään sekalukumallia ennen ratkaisua, jolloin ratkaisijan laskennallinen työmäärä pienenee. Tutkimalla suoritusaikojen muuttumista optimointia kehitettäessä saadaan tietoa käytetyn ratkaisijan soveltaman ratkaisutavan tehokkuudesta. Ratkaisija saattaa sisältää myös itsessään jonkinlaista ratkaistavan mallin optimointia. 6

9 5 Työkäytännöt Projektissä tutustuttiin tarkemmin seitsemään työkäytäntöön. Nämä olivat dokumentointikäytäntö, kokouskäytäntö, suunnittelumallit, heuristinen arviointi, pariohjelmointi, automatisoitu systeemitestaus sekä yksikkötestaus. Dokumentointikäytäntö osoittautui hyväksi tavaksi varmistaa tuotettujen dokumentaatioiden laatu ja yhtenäinen ilme. Tämä lisäsi huomattavasti lopputulosten vakuuttavuutta. Käytäntöä ei saatu vielä täydelliseksi, vaan parannettavaa löytyi, mutta projektin tavoitteiden tukemisessa käytäntö toimi hyvin. Kokouskäytäntö osoittautui periaatteessa toimivaksi, mutta se kattoi vain osan kommunikaatiotarpeesta. Kurssin suurimmat puutteet liittyivätkin säännöllisen kommunikaation puutteeseen, minkä osasyynä saattoi olla liian isoja kokouksia painottava käytäntö. Kokouskäytäntöä olisi pitänyt ehkä täydentää jollain säännöllisellä virtuaalisella kokouksella, joka olisi pitänyt ryhmän jäsenet henkisesti mukana projektissa. Suunnittelumallien koulutus jäi projektissa vähäiseksi, minkä takia käytännön tulokset olivat vaihtelevia. Suunnittelumallit tuntevien mielestä niistä oli suuresti apua järjestelmää suunniteltaessa, kun taas malleja tuntemattomat eivät hahmottaneet niistä saatavia hyötyjä. Tuotteen arkkitehtuurin suunnitteluun osallistuivat lähinnä malleja tuntevat henkilöt, joten lisäkoulutuksen hyöty projektin lopputulosten kannalta olisi ollut pieni. Heuristista arviointia käytettiin projektissa käyttöliittymän suunnittelun apuna. Malli toimi varsin hyvin ja antoi arvokasta palautetta käyttöliittymän suunnittelun pohjaksi. Myös vertaisryhmä testasi kehitettävää järjestelmää muun muassa heuristisen arvioinnin perusteiden mukaisesti. Pariohjelmointi oli työkäytäntö, jonka käytöstä ei saatu selkeitä tuloksia. Teimme projektin alkuvaiheessa ratkaisun, että käytämme pariohjelmointia vaikeimmissa komponenteissa, jotka ovat kuitenkin keskeisessä asemassa toteutuksemme kannalta. Tämän vuoksi emme saaneet järkeviä vertailukohtia resurssien käytön tai virhemäärien osalta. Työtapa koettiin mielekkääksi, mutta sen tehokkuudesta ei oltu vakuuttuneita. Työkäytännöistä pahiten epäonnistui automatisoitu systeemitestaus, sillä testauksessa käytetty itse kehitetty järjestelmä valmistui liian myöhään eikä siten pystynyt auttamaan ongelmakohtien paikannuksessa. Lisäksi järjestelmän toteutuksesta graafinen käyttöliittymä oli suuressa osassa ja valittu testaustapa ei mahdollistanut sen testauksen automatisointia. Tämä oli kuitenkin tietoinen valinta, sillä käyttöliittymä kehitettiin ainoastaan testikäyttöä varten sekä esimerkiksi siitä, kuinka järjestelmää on mahdollista käyttää. Yksikkötestaus sai vaihtelevan vastaanoton projekin puitteissa. Koska projektiin ei sisälly kehitetyn järjestelmän ylläpitoa, ei yksikkötestauksen kaikki hyödyt tulleet lainkaan esille. Lisäksi yksikkötestausta ei aloitettu tarpeeksi ajossa projektissa, joten testitapauksien tekeminen vastasi pitkälti normaalia testausta. 7

10 6 Työkalut Työkaluina projektissa olivat Java, GNU Make, CVS, Jlex, Cup, GLPK, Bugzilla, Trapoli, OpenOffice.org, Javadoc, Dia, CCCC, Junit, Checkstyle, PMD, FindBugs sekä Jetty. Java, GNU Make, CVS, Javadoc ja Bugzilla olivat projektiryhmän jäsenille tuttuja työkaluja jo ennestään, ja ne toimivat juuri niin kuin niiden odotettiinkin toimivan. Mitään vaikeuksia niiden käytön kanssa ei projektissa ilmennyt, ja niitä voidaankin suositella minkä tahansa projektin perustyökaluiksi. Jlex ja Cup toimivat hyvin kielen käsittelyn työkaluina täyttäen niille suunnitellun tehtävän täysin. GLPK oli ennestään tuntematon työkalu, joka loppujen lopuksi todettiinkin lopputuotteen komponentiksi pikemminkin kuin työkaluksi. Se ei ollut täydellinen tarkoituksiamme ajatellen, ja jouduimme muun muassa parantamaan sen säiesuojausta, jotta pystyimme käyttämään sitä haluamallamme tavalla. Lisäksi osa suunnitelluista piirteistä jäi toteuttamatta, koska GLPK:n rajapinnoista ei löytynyt haluttuja ominaisuuksia. Trapoli oli pakollinen ajanhallintatyökalu, johon liittyi projektin aikana paljon vaikeuksia. Emme pitäneet sitä hyvänä valintana tarkoitukseensa, joten emme suosittele sitä vastaaville projekteille myöhemminkään. Dokumentointiin käytettiin OpenOffice.orgia ja Diaa varsinaisten dokumenttien luomiseen. Lisäksi Javadocin avulla luotiin jatkokehittäjiä varten kaikista luokista, rajapinnoista ja metodeista kuvaukset Java-standardin mukaisesti. OpenOffice.org osoittautui oikein toimivaksi työkaluksi ja sillä saatiin erinomaisia dokumentteja aikaan. Voimme suositella sitä mille tahansa muulle projektille, joka haluaa valita työkalun, joka toimii sekä Windowsettä Linux-ympäristössä. Diaa vaivasi eri versioiden yhteensopimattomuus. Ongelmia oli sekä versioiden että ympäristöjen välillä. Parempaa piirtotyökalua emme kuitenkaan Linux-ympäristöön tunne, joten siinä mielessä Dia on ymmärrettävä valinta. CCCC, Checkstyle, PMD ja FindBugs olivat työkaluja, joilla pyrimme analysoimaan kirjoitetun ohjelmakoodia. CCCC:n käyttö jäi lopulta lähinnä ohjelma- ja kommenttirivien laskentaan. Se ei alunperin ymmärtänyt kaikkia käyttämiämme määrityksiä, joten jouduimme hieman muokkaamaan sitä tarkoituksiimme paremmin soveltuvaksi. Muiden työkalujen käyttö jäi vähäiseksi, osa kehittäjistä käytti niitä oman työnsä tukena, mutta systemaattisesti niiden tarjoamia tietoja ei pystytty hyödyntämään. Jetty valittiin projektin aikana pohjaksi käyttöliittymän toteutukselle. Valinta osoittautui onnistuneeksi ja voimmekin suositella Jettyä muihinkin projekteihin, joissa pitää luoda selaimella käytettävä käyttöliittymä Javalla toteutettuun ohjelmaan. 8

11 7 Projektista opittua Kävimme projektiryhmän sisäisesti läpi projektissa opittuja asioita ja henkilökohtaisten tavoitteiden täyttymistä. Yleisellä tasolla voidaan todeta, että kaikki ryhmän jäsenet olivat vähintään tyytyväisiä projektiin omien tavoitteidensa kannalta, ja osa oli jopa aidosti yllättyneitä siitä, miten paljon uutta aiheesta pystyi vielä oppimaan. Henkilökohtaisten tavoitteiden laajempi analyysi ei vielä ole mahdollista, sillä suurella osalla tärkeimpänä tavoitteena oli kurssin läpäisy tai kurssin läpäisy kunniallisesti. Tämän onnistumista voidaan arvioida vasta projektin päättymisen jälkeen. Toinen yleinen tavoite oli uusiin ihmisiin tutustuminen. Tämä on varmasti onnistunut kaikkien kohdalla, sillä projektin aikana on järjestetty useita erilaisia kokouksia erilaisilla kokoonpanoilla ja näissä on ollut mahdollisuus tutustua muihin ryhmän jäseniin. Tämä on opettanut kaikille myös ryhmässä toimimista sekä muita sosiaalisia taitoja, joita tarvitaan muissakin ryhmässä tehtävissä projekteissa. Projektista opetut asiat vaihtelevat kunkin henkilön roolin mukaisesti. Jokainen kertoo oppineensa uutta sekä teknisistä asioita kuin myös ohjelmistoprojektissa työskentelemisestä. Erityisesti projektipäällikkö katsoo nyt ymmärtävänsä monia ohjelmistotuotannon erityispiirteitä aikaisempaa paremmin. 9

12 8 Palaute kurssista Kurssi oli kokonaisuutena hyvin opettavainen. Tämä oli joillekin projektiryhmän jäsenille ensimmäinen kerta, kun he osallistuivat laajempaan ohjelmistoprojektiin. Osa ryhmästä oli ollut ryhmissä mukana työpaikoillaan, mutta silti projektissa noudatetut käytännöt antoivat heillekin ajateltavaa. Yleiskuvaksi koko ryhmälle jäi positiivinen kuva kurssista, mutta muutamat asioita voidaan tulevina vuosina varmasti parantaa. Nämä asiat ovat kurssin luonteen ja projektipäällikön roolin esiintuominen, kurssin arvostelumalli sekä pakollisten työkalujen käyttö. 8.1 Kurssin luonteen esiintuominen Kurssin luennoilla kannattaisi painottaa enemmän sitä tosiasiaa, että kurssin arvostelu perustuu lähes ainoastaan projektin tuottaman dokumentaation arviointiin. Kokeneille ohjelmoijille on vaikea tottua ajatukseen, että kirjoitetun ohjelmakoodin laatu on toissijaista dokumentaatioon nähden ja tätä kannattaakin painottaa kurssin aloitusvaiheessa reilusti. 8.2 Projektipäällikön luonne Ryhmämme projektipäällikkö oli suorittanut kaikki kurssin esitietoina vaaditut kurssit ja suoritti syventäviä opintojaan ohjelmistotuotannossa kurssin aikana. Tämä toi esiin sen, että kurssin alussa voisi painottaa, että ryhmän projektipäällikölle suositellaan esitiedoiksi laajemmin aiheeseen liittyviä kursseja. Voisi jopa ajatella, että kurssin jakaisi kahteen erilliseen kurssiin, joilla on erilaiset esitietovaatimukset. Projektipäälliköille olisi siis oma kurssinsa ja projektipäälliköt saisivat erilaista koulutusta kuin muu projektiryhmä. Tämän lisäksi voisi harkita arvostelussa samankaltaista mallia, kuin mitä armeijassa käytetään, eli projektipäällikkö saisi vaikuttaa projektiryhmän jäsenten arviointiin ja projektiryhmän jäsenet taas voisivat antaa palautetta projektipäälliköstä esimerkiksi ryhmän mentorille, joka arvioisi lopullisesti projektipäällikön menestyksen projektin vetämisessä. Tämä edellyttäisi luonnollisestikin lisää resursseja projektin ohjaamiseen, mutta uskoisin, että tällä tavalla kurssi pystyisi tuottamaan todella osaavia projektipäälliköitä ja siten vastaamaan alan yritysten tarpeisiin. Monien yritysten suuri ongelma on pula osaavista projektipäälliköistä, ja tämä on mielestäni tarve, johon tämän kurssin puitteissa olisi mahdollista nykyistä paremmin panostaa. 8.3 Kurssin arvostelumalli Kurssin arvostelumalliin liittyy ongelmia, sillä asiakkaat arvioivat ryhmät viisi kertaa asteikolla nollasta kuuteen. Kuitenkin kullakin arvostelijalla on henkilökohtainen tapansa käyttää arvosanoja. Osalle täydet pisteet tarkoittavat suoritusta ilman merkittäviä puutteita, osalle taas kaikki odotukset ylittävää suoritusta. Tämän vuoksi pelkästään asiakkaan projektien kestäessä antamissa arvosteluissa voi olla helposti viiden pisteen eroja pelkästään asiakkaiden erilaisten käytäntöjen takia. Toisaalta mentorit käyttävät omaa arvosteluaan tämän epäkohdan korjaamiseen. Tämä ei kuitenkaan ongelmatonta, sillä se vaikeuttaa suorituksen epäkohtien havaitsemista. Ainakin meidän ryhmämme tapauksessa ensimmäisissä vaiheissa saimme hyvin palautetta työstämme, mutta loppua kohti mentor muuttui vaihe vaiheelta vähäsanaisemmaksi, ja viimeisestä toteutusvaiheesta ei varsinaista palautetta saatu enää 10

13 lainkaan. Ilman palautetta projektin eteenpäin vieminen on varsin vaikeaa. Toimivan arvostelumallin rakentaminen on varmasti hyvin vaikeaa, mutta mielestämme jonkinlaista muutosta malli silti tarvitsee. 8.4 Pakollisten työkalujen käyttö Kurssilla oli pakollisena työkaluna Trapoli-työajanseurantajärjestelmä. Sen toiminta osoittautui kuitenkin kurssin aikana epävarmaksi, sillä järjestelmä oli usein kriittisinä hetkinä poissa käytöstä. Kun kurssin järjestäjillä ei ollut resursseja huolehtia järjestelmän ympärivuorokautisesta ylläpidosta, osuivat ongelmahetket usein lähelle palautusten aikarajoja, jolloin kaikki ryhmät tekivät töitä järjestelmän kanssa. Lisäksi järjestelmän toimintatavat eivät olleet aivan odotettuja. Erityisesti raporttien sisältämät työmäärät olivat usein ihmetyksen kohteena. Lisäksi Trapolin tapa käsitellä tehtävien vastuuhenkilöitä oli huono, sillä tehtävästä vastaaminen ei tarkoita samaa kuin että henkilö olisi ainoa sitä suorittava henkilö, kuten Trapoli ilmeisesti olettaa. Kurssin organisaatio ansaitsee kuitenkin kiitokset järjestelmää kurssin alussa vaivanneiden vakavien virheiden korjaamisesta. Virheet saatiin poistettua järjestelmästä, ja näiltä osin järjestelmä toimi projektin loppupuolella luotettavasti. 11