T Loppuraportti

T-76.115 Loppuraportti Confuse 22. huhtikuuta 2002 Tila Versio: 1.0 Vaihe: LU Jakelu: Julkinen Luontipäivä: 04.04.2002 Tuomo Koskenvaara Muutettu viimeksi: 20.04.2002 Tuomo Koskenvaara 1

Versiohistoria Versio Pvm Tekijä Kuvaus 0.01 04.04.2002 Koskenvaara Tuomo Pohjan tekeminen 0.1 05.04.2002 Koskenvaara Tuomo Pohjan vieminen CVS:sään 0.2 09.04.2002 Koskenvaara Tuomo Johdannon päivitystä 0.3 10.04.2002 Koskenvaara Tuomo Raportin kirjoittamista 0.31 11.04.2002 Haapakoski Antti Tekstiä UML-menetelmästä (Kappale 5.5). 0.32 11.04.2002 Koskenvaara Tuomo Ohjeita muille raportin täydentämiseen 0.4 11.04.2002 Koskenvaara Tuomo Tekstiä CVS-menetelmästä (Kappale 5.1), tavoitteista (Kappale 2) ja Projektin etenemisestä (Kappale 3) 0.5 13.04.2002 Vainionpää Jussi Tekstiä jäljitettävyysmatriisi-menetelmästä ja vaatimusmäärittelyn tavoitteista. 0.6 15.04.2002 Koskenvaara Tuomo Testauksesta ja V-mallista 0.7 17.04.2002 Ari Haapaniemi Tekstiä loppulaskelmiin 0.8 17.04.2002 Mikko Martsola Java-koodausstandardit 0.85 18.04.2002 Petri Kujala Delfoi ja testaus 0.9 19.04.2002 Tuomo Koskenvaara Pieniä korjauksia sillä täällä 1.0 20.04.2002 Tuomo Koskenvaara Palautetta ryhmältä ja pieniä korjailuja 2

Sisältö 1 Johdanto 4 2 Projektin tavoitteet ja niiden toteutuminen 6 2.1 Ryhmän omat tavoitteet......................................... 6 2.2 Asiakkaan tavoitteet........................................... 6 2.3 Vaatimusmäärittelyn tavoitteet..................................... 6 3 Projektin eteneminen 8 3.1 Tehtävänjako ja suunniteltu ajankäyttö................................. 8 3.2 Työmääräarviot vaiheittain....................................... 9 3.3 Muut loppulaskelmat.......................................... 10 4 Ohjelmiston virheet 11 5 Käytetyt menetelmät 12 5.1 CVS................................................... 12 5.2 Delfoi.................................................. 12 5.3 Java-koodausstandardit......................................... 12 5.4 Jäljitettävyysmatriisi.......................................... 13 5.5 UML.................................................. 13 5.6 V-malli................................................. 13 6 Mitä meille tapahtui 14 6.1 Mitä me opimme............................................ 14 6.2 Missä teimme väärin.......................................... 15 7 Ryhmäläisten ideoita ohjelmiston jatkokehittämiseksi 16 8 Palautetta kurssista 17 3

1 Johdanto Tämä asiakirja on T-76.115 Tietojenkäsittelyopin ohjelmatyö-kurssin suorittavan ryhmän Confuse loppuraportti. Tämän projektin aikana toteutettiin Teknillisen korkeakoulun SoberIT 1 SARCOUS tutkimusprojektiin liittyvä yksinkertainen konfigurointiympäristö mobiilipäätelaitteelle. SARCOUS tutkimusprojekti tutkii tuoteperheiden ja niiden osien dynaamista ja staattista konfiguraatiota. Konfigurointiympäristön avulla pyrittään esittelemään tällaisen järjestelmän toimivuutta. Se käyttää apunaan Tommi Syrjäsen tekemää päättelykonelogiikkaa oikeiden konfiguraatioiden hyväksymiseen. Järjestelmä autaa käyttäjää valitsemaan itselleen toimivan konfiguraation päätelaitteeseensa. Asiakas oli jo ennalta hieman suunnitellut tulevaa systeemiä ja sen perusteelta projektiryhmä jakoi työnsä kolmeen osaan: Lajittelija, jota käytetään tallentamaan konfiguraation teossa käytettävätohjelmapakettien tiedot järjestelmään. Valitsin, jonka avulla käyttäjä voi muokata, testata, asentaa, ladata ja tallentaa valitsemaansa konfiguraatiota. Asentaja, joka suorittaa varsinaisen pakettien asentamisen päätelaitteeseen. 1 Software Business and Engineering Institute 4

<<binääri>> Pakettitiedosto Linux PC Lajittelija Configurator logic <<tekstitiedosto>> KL valintamäärittelyt <<tekstitiedosto>> Konfiguraatiomalli Päättelykone Valitsin GUI <<XML file>> Konfiguraation pakettilista Asentaja PDA Asentaja Kuva 1: Systeemiarkkitehtuurin UML komponentti diagrammi Järjestelmän mobiilipäätelaitteena toimi Compaq:n valmistama ipaq-kämmenmikro, johon asennettiin Familiar Linux-käyttöjärjestelmä. Lajittelijan avulla Familiar-Linux:n käyttämät IPKG-pakettien tiedot syötettiin päättelykonelogiikalle. Tässä järjestelmässä päättelykonelogiikka, sen käyttöliittymä ja lajittelija asennettiin tavalliseen PC-tietokoneeseen, jonka käyttöjärjestelmänä toimi Linux. Tulevaisuudessa logiikan ja käyttöliittymän integroiminen itse päätelaitteeseen ei ole ongelma, koska järjestelmä on tätä ja muita mahdollisia muutoksia varten pyritty pitämään mahdollisimman modulaarisena. Ratkaisulla on pyritty mahdollistamaan myös paketointijärjestelmän vaihtaminen ilman, että koko järjestelmä pitäisi kirjoittaa uudelleen. Tiedonsiirto päätelaitteen ja palvelimen (PCtietokoneen) välillä käytetään tavallista LAN-yhteyttä. 5

2 Projektin tavoitteet ja niiden toteutuminen Projektin tavoitteena oli toteuttaa SARCOUS projektin osana toteutettu rajattu mobiililaitteen konfigurointiympäristö. Samalla projektin jäsenet suorittivat kurssin T-76.115 Tietojenkäsittelyopin ohjelmatyö. Projektityön olessa samalla osa opintoja vaadittiin projektiryhmää raportoimaan kurssin kulusta myös kurssin ylläpidolle. Suurin osa tästä raportoinnista voidaan mieltää normaaliksi projektin yläpuolella olevalle tasolle raportoimiseksi. 2.1 Ryhmän omat tavoitteet Projektiryhmän päätavoitteena oli kurssin suorittaminen. Samalla pyrittiin keräämään kokemusta projektityöskentelystä. Ryhmä kokeili kurssilla ja elämässä muuallakin oppimiaan taitoja tämän projektin aikana. Toisena tavoitteena oli asiakkaan vaatimusten täyttäminen ja tätä kautta asiakkaan tyytyväiseksi saaminen. 2.2 Asiakkaan tavoitteet Asiakas halusi saada modulaarisen mobiililaitteiden konfigurointiympäristön. Projektiryhmän toteuttama projekti on vain osa SARCOUS projektia. Aluksi oli tavoitteena määritellä onko tällaista järjestelmää edes mahdollista toteuttaa kämmenmikrojen mittakaavassa ja toisaalta kuinka paljon siitä voidaan sisällyttää suoraan kämmenmikroon sen rajallisen kapasiteetin takia. Toinen asiakasta kiinnostanut asia oli järjestelmän toimivuus huonommankin siirtoyhteyden kanssa. Tähän kohtaan työssämme ei varsinaisesti puututtu. Järjestelmä toimii tavallisen TCP/IP-yhteyden avulla ja jos tällainen yhteys on luotavissa, järjestelmä toimii verkkoyhteyden edellyttämällä nopeudella. Asiakkaan vaatimusten perusteella tehtiin vaatimusdokumentaatio, josta enemmän seuraavassa kappaleessa. Asiakkaan kymmenen tärkeintä tavoitetta tuotettavan järjestelmän ja osittain projektin suhteen on lueteltu taulukossa 1. No Katso Kuvaus Verifiointi 1. UR-27 Graafinen käyttöliittymä, jolla PDA:n konfiguraatiota muutetaan valitsemalla paketteja Pakettien valinta/poisto onnistuu hiiren kursoria käyttäen. listasta. 2. UR-07, UR-11-13 Järjestelmä hallitsee konfiguraation oikeellisuutta ja valintojen yhteensopivuutta. Kaikki asennetun konfiguraation ohjelmat toimivat PDA:ssa. 3. UR-02 Järjestelmä käyttää Tommi Syrjäsen lo- Järjestelmä kutsuu päättelykonetta ja käyt- 4. UR-05, UR-14, UR-21 5. UR-06, UR-16 giikkapäättelykonetta. Järjestelmä osaa asentaa PDA:han paketteja. Järjestelmällä voi poistaa PDA:n paketteja. 6. UR-08 Järjestelmä osaa lukea Familiar Linuxin ipkg -muotoisia paketteja. 7. UR-23 Järjestelmän osat ovat modulaarisia ja löyhästi kytkettyjä. 8. UR-19, Järjestelmä muistaa PDA:n konfiguraation. UR-20 9. UR-22 Lähdekoodi on hyvin englanniksi kommentoituna. 10. Järjestelmän tekninen dokumentaatio on englanninkielinen. tää sen antamia tuloksia. PDA:han ilmestyy haluttu ohjelma. PDA:sta poistuu valittu ohjelma. Kyseinen paketti ilmestyy konfiguraattorin käyttöliittymään. Ohjaajan mielipide asiasta kyllä/ei. Verrataan käyttöliittymän näyttämää ja PDA:n todellista konfiguraatiota. Tarkistetaan että lähdekooditiedostojen, luokkien ja metodien alussa on kommentit. Tarkastetaan kaikki tekninen dokumentaatio. Taulukko 1: Asiakkaan kymmenen tärkeintä tavoitetta. UR-xx:t ovat vaatimusten koodeja vaatimusmäärittelyssä. 2.3 Vaatimusmäärittelyn tavoitteet Projektin ensimmäisessä vaiheessa projektin tavoitteista ja asiakkaan tarpeista keskusteltiin asiakkaan kanssa. Näiden neuvotteluiden pohjalta pyrimme kiteyttämään tavoitteet selkeiksi vaatimuksiksi, jotka kirjatttiin vaatimusmää- 6

rittelyyn. Vaatimusmäärittelyn tarkoituksena on toimia pohjana toiminnallisen ja teknisen määrittelyn tekemiseen. Tarvittavat toiminnot on helppo suunnitella kun vaatimukset ovat tiedossa. Lisäksi toiminnallinen määrittely voidaan tarkistaa vaatimusmäärittelyä vasten eli varmistaa, että kaikki vaaditut toiminnalisuudet ovat mukana ja toisaalta ettei kehitetä toimintoja, joita asiakas ei tarvitse. Vaatimusmäärittelyn tarkoituksena on myös toimia sopimuksena asiakkaan ja projektiryhmän välillä. Tästä syystä vaatimusmäärittely hyväksytettiin asiakkaalla projektin alussa sekä aina kun siihen tuli muutoksia. Vaatimusmäärittelyyn on tarkoitus kirjata ainoastaan käyttäjien todellisista tarpeista tulevia vaatimuksia, jolloin toteutus voidaan suunnitella vapaasti kunhan se täyttää vaatimukset. Siksi vaatimusmäärittelyssä ei yleensä määritellä teknisiä yksityiskohtia tai komponentteja. Confuse-projekti on kuitenkin osa asiakkaan suuremmasta tutkimusprojektista, joten oli ensiarvoisen tärkeää, että järjestelmässä voitiin käyttää aikaisempia komponentteja ja että järjestelmä sopi asiakkaan aikaisempaan arkkitehtuuriin. Lisäksi asiakas halusi varmistaa helpon jatkokehityksen. Näistä syistä vaatimusmäärittelyyn otettiinkin huomattavasti asiakkaan haluamia teknisiä rajapintoja, tiedostomuotoja ja komponenttijakoja. Käytännössä vaatimusmäärittely toimi hyvin ja siinä tehdyistä selkeistä linjauksista oli huomattavaa hyötyä projektia toteutettaessa. Hieman projektin puolivälin jälkeen vaatimusmäärittelyyn tehtiin muutamia melko huomattavia muutoksia: Vaatimuksien prioriteetteja muutettiin ja muutama uusi vaatimus lisättiin. Muutokset tehtiin osittain koska asiakas ymmärsi proton nähtyään paremmin mitkä ominaisuudet ovat tarpeen ja toisaalta koska siihen mennessä toteutetut ominaisuudet eivät olleet vaatineet niin paljoa työtä kuin aluksi oli ennakoitu. 7

3 Projektin eteneminen Projektin toteuttaminen jaettiin viiteen ajanjaksoon, joista ensimmäinen käytettiin pääosin järjestelmän suunnitteluun. Toinen, kolmas ja neljäs kuuluivat toteuttamiseen ja viimeisessä osassa viimeisteltään ja hyväksytettään kurssin aikana valmistunut tuote asiakkaalla. Projekti eteni alusta loppuun suuremmitta tuotannollisitta ongelmitta. Enemmän päänvaivaa ryhmälle tuotti kurssiin kuuluva raportointi, jonka muistaminen tuntui olevan hieman hankalaa. Erityisesti nyt loppuvaiheessa ollut lähes joka viikkoinen raportointi kurssille (ja samalla asiakkaalle) on ollut hankalaa, koska mitään isompaa raportoitavaa ei ole joka viikko edes ollut. 3.1 Tehtävänjako ja suunniteltu ajankäyttö Kurssin alussa pyrittiin luomaan ryhmän jäsenille selkeät roolit, jotta tulevat työt saataisiin järkevästi jeattua ryhmän sisällä. Projektipäälikön vaihtaminen toi tähän pienen muutoksen tammikuun puolivälissä. Alla lista tehtävänjaosta ryhmän sisällä: Koskenvaara Tuomo (Projektipäällikkö 15.1.2002 asti) - Projektin kokonaisvastuu 15.1.2002 asti - Työnjako, suunnittelu, raportointi (Haapaniemi Arin kanssa) - Aikataulutus (Haapaniemi Arin kanssa) - Mittarien seuranta (Haapaniemi Arin kanssa) - Avustaa muita apua tarvitsevia - Petri Kujalan varamies Kujala Petri (Ohjelmistosuunnittelija II) - Riskienhallintasuunnitelma - Kokoonpanovastuu, vastaa osien yhteensovittamisesta - Tekninen määrittely Jussi Vainionpään kanssa - Avustaa kaikissa ohjelmiston suunnitteluun tarvittavissa asioissa - Antti Haapakosken varamies Haapaniemi Ari (käyttöliittymävastaava ja projektipäälikkö 16.1.2002 lähtien) - Projektin kokonaisvastuu 16.1.2002 lähtien. - Työnjako, suunnittelu, raportointi (Koskenvaara Tuomon kanssa) - Aikataulutus (Koskenvaara Tuomon kanssa) - Mittarien seuranta (Koskenvaara Tuomon kanssa) - Konfiguraattorin ohjelmoinnin päävastuu - Käyttöliittymäsuunnittelu - Mikko Martsolan varamies Haapakoski Antti (Ohjelmistosuunnittelija I) - Dokumenttien hallinta/tarkastaminen - Vaatimusmäärittely - Lajittelija-osion ohjelmointivastuu - Tuomo Koskenvaaran varamies Martsola Mikko (Ohjelmoija I) - Asennusohjelmiston ohjelmoinnin päävastuu - Laitteistovaatimukset - Ari Haapaniemen varamies Myyry Jani (Testi- ja päättelykoneintegrointi-vastaava) - Päättelykoneintegrointi - Testisuunnitelma ja toteuttaminen - Projektin www-sivujen ylläpito - Jussi Vainionpään varamies Vainionpää Jussi (Ohjelmoija II) - Tekninen määrittely Petri Kujalan kanssa 8

- Mittarit, niiden valinta ja käyttöperiaatteet - ipaq:n asennus ja ylläpito - Jani Myyryn varamies Ajanköyttö näiden viiden osan osalta pyrittiin järjestämään niin, että suunnitteluun panostettiin kunnolla heti alussa, jotta myöhemmissä vaiheissa voitaisiin paneutua enemmän vain toteuttamiseen. Ensimmäisessä vaiheessa suunniteltiin käytettäväksi 279 tuntia, joista 261 käytettiin. Seuraavien kolmen vaiheen aikana suunnittelua jatkettiin mutta toteuttaminen oli pääosassa näille kolmelle seuraavalle vaiheelle varattiin käytettäväksi 987 tuntia, joista käytimme niiden aikana 720. Vaikka tunteja käytettiinkin suunniteltua vähemmän, emme kuitenkaan joutuneet tinkimään mistää asiakasvaatimuksista, vaan pystyimme jopa toteuttamaan muutaman alkuperäistä enemmän tuona aikana. Luovutusvaiheeseen on varattu 194 tuntia. 3.2 Työmääräarviot vaiheittain Tuntisuunnitelmaa jouduttiin muuttamaan useaan otteeseen kurssin aikana ja käyttämämme Microsoft Project ohjelmisto ei ollut tähän työhön kovinkaan käytännöllinen. Onneksi projekti oli niin pieni, että automaattiset korjailut pystyi vielä korjaamaan käsin uudestaan. Muokkausten suunnitteluun käytimme pääasiassa Microsoft:n Exel ohjelmistoa, koska sillä taulukon muokkaaminen oli huomattavasti nopeampaa, kuin Projectin työkaluilla. Tuntisuunnitalmaa jouduttiin päivittämään lähes jokaisen vaiheen jälkeen. Alussa koska projektipäälikkö yritti olla liian tarkka tuntien suhteen ja kurssin puolivälin jälkeen, koska tunteja oli jäänyt niin runsaasti tekemättä. Alla taulukot suunnitelluista ja toteutuneista tunneista. LU-vaiheen tunnit ovat hyvin raakoja arvioita, koska vaihe on tätä kirjoitettaessa vasta puolivälissä. Tuntisuunnitelma on esitetty taulukossa 2 ja toteutuneet tunnit taulukossa 3. Taulukon LU-vaiheen tunnit ovat arvioita tässä jaksossa raportoiduista ja vielä tulevista tunneista. Yhteensä luku on otettu myös suoraan Tiranasta ja siihen on lisätty oletettavat vielä tulevat tunnit. Laskut eivät kuitenkaan täsmää, joten Tirana lienee piilottanut muutamia tunteja, jotka on esim. syötetty edelliselle jaksolle palautuksen jälkeen tai muuten suunnittelemattomalle työlle. Antti Ari Jani Jussi Mikko Petri Tuomo Yhteensä PS 45 20 40 50 20 40 64 279 T1 50 50 30 40 50 40 34 294 T2 40 60 45 45 60 55 34 339 T3 35 45 60 50 60 30 34 354 LU 30 20 30 20 20 20 34 194 Yhteensä 200 200 200 200 200 200 200 1400 Taulukko 2: Suunnitellut resurssit Antti Ari Jani Jussi Mikko Petri Tuomo Yhteensä PS 50 21 30 41 24 21 74 261 T1 29 44 37 35 29 52 30 256 T2 26,5 31 25 8,5 26 4,5 23 144 T3 42 53 60 50 60 30 25 320 LU (Arvio) 25 27 27 30 42 19 32 202 Yhteensä (Arvio) 192 193 187 182 184 181 189 1308 Taulukko 3: Käytetyt resurssit 9

3.3 Muut loppulaskelmat Konfigurointi ympäristön toteutuksessa valitsimme käytettäväksi Java- ja Perl-ohjelmointikieliä sekä JSP-skriptikieltä. Valitsimen toteutus on tehty käyttäen Javaa, jolla toteutetaan pääasiallisin konfiguraatioden hallinta. Tämä toteutuson paketoitu JavaBean-komponentiksi. Valitsimen graafinen puoli on tehty JSP-skriptillä, joka mahdollistaa dynaamisten web-sivujen luonnin. Lajittelija- ja Asentaja-moduulit on toteutettu Perl-kielellä. Koska Perl tukee säännöllisiä lausekkeita, on se erinomainen työkalu merkkijonon käsittelyyn. Merkkijonojen käsitteli näyttelee suurta roolia molemmissa moduuleissa. Kokonaisuudessaan konfigurointiympäristön toteutus käsittää n. 3220 ohjelmointikoodiriviä. Tähän voitasiin myös laskea mukaan myös muutama sata riviä skripteistä, jotka pitävät huolta ympäristön asennuksesta ja pakkauksesta. Mutta koska ne eivät ole suoraan ympäristön toimintaan osallistuvia ei niitä käsitellä tastä eteenpäin. Moduulikohtaiset koodirivien lukumäärät ja virheiden lukumääräovat nähtävissä taulukossa 4 Valitsin Lajittelija Asentaja Yhteensä Koodirivit 2367 225 431 3023 Löydetyt Virheet 5 1 1 7 Korjauksiin Käytetyt tunnit 3 2 1 6 Taulukko 4: Moduulikohtaiset rivimäärät ja virheet Verrattuna muihin kurssin projekteihin, toteutuksemme jäi koodirivimäärältään pieninpien joukkoon. Projektimme painottuikin koodauksen lisäksi voimakkaasti modulien välisten XML-rajapintojen määrittelemiseen, ohjelmistopakettien välisten riippuvuussääntöjen kartoittamiseen ja Tommi Syrjäsen jo valmiiksi toteuttaman päättelykoneen integroimiseen itse järjestelmään. Myös Perl-kielen käyttö vähensi huomattavasti tarvittavien koodirivien lukumäärää johtuen vahvasta säännöllisten lausekkeiden-tuesta, joka on kieleen sisäänrakennettu. V-mallin mukaisten testi-iteratioden aikana Buranaan raportoitujen ja korjattujen virheiden määrä oli kokonaisuudessaan 7. Virheiden lukumäärä moduulikohtaisesti on nähtävissä taulukossa 4 Suurin osa virheistä tuli ilmi jo kehittäjän itse testatessa modulinsa toimintaa. Tämä selittää osaltaan sen miksi Buranaan raportoitiin vain 7 virhettä. Myös kehityksen yhteydessä tapahtunut toisen henkilön tekemä ad-hoc testaus vaikutti virallista kanavaa raportoitujen virheiden pieneen määrään. Suurin osa Buranaan raportiuduista virheistä oli low-tasoa, joilla ei ollut suurta merkitystä itse järjestelmän käytön kannalta, mutta, jotka olivat akateemisessa mielessä katsottava virheiksi. Myös määrittelemättömät moduulien palatusarvot aiheuttivat muutaman virheraportoinnin. Kaikki Buraanaan rapotoidut virheet päätyivät Closed-tilaan. Suurin osa virheistä tuli ilmi jo kehittäjän itse testatessa modulinsa toimintaa. Tämä selittää osaltaan sen miksi Buranaan raportoitiin vain 7 virhettä. Myöskehityksen yhteydessä tapahtunut toisen henkilön tekemä ad-hoc testaus vaikuttivirallista kanavaa raportoitujen virheiden pieneen määrään.nämä testausmenetelmät olivat luonollinen osa itse kehitysprosessia, joten mitään erillistä ulkopuolista raportointia emme näistä testeistä tehneet. Suurin osa virheistä, jotka löysimme sisäisessä testauksessa olivat low-tasoa. Sisäisessä ad-hoc testauksessa löytyi yksi high-tason virhe, joka aiheutti virheen palvelun alla toimivassa Tomcat Servlet Containerissa. Kattavan testauksen ansiosta virhe löytyi jo ensimmäisellä sisäisellä testauskierroksella, jonka jälkeen se korjattiin välittömästi. Virheiden korjausaika oli kokonaisuudessaan kuusi tuntia. Kuten jo taulukosta 4 käy ilmi, suurin osa virheistä oli hyvin alhaista tasoa, ja näin ollen niiden korjauskaan ei viennyt kovin paljoa aikaa. Koska jouduimme loppuajasta kehittämään konfiguraatioympäritöä suoraan palvelimelta käsin, suurin aika virheidenkorjauksen yhteydessä meni ympäristön käynnistämiseen ja itse virheen toistamisen mahdollistamiseen. Kaikki asiakkaan määrittelemät vaatimukset saatiin valmiiksi ajallaan. Projektin alussa huolellisesti asiakkaan kanssa tehdystä vaatimuskartoituksesta johtuen, emme joutuneet toteuttamaan ominaisuuksia, joita itse lopputuotteessa ei tarvittaisikaan. Tämä osaltaan mahdollisti huolellisen suunnittelun ennen itse varsinaisen toteutuksen aloittamista, jolloin myös vaatimusten toteutuminen voitiin tehdä aikataulun mukaisesti. Itse asiassa T2-vaiheen lopussa havaitsimme olevamme omituisessa tilanteessa; Olimme käyttäneet vain n. 60 prosenttia vaiheeseen budjetoiduista tunneista, ja siitä huolimatta olimme saaneet kaikki vaadittavat vaatimukset toteutettua. Tästä johtuen otimme T3-vaiheeseen toteutettavaksemmae joitakin ominaisuuksia, joita tämän projektin puitteissa ei ollut suunniteltu toteutettavaksi. Näistä voisi mainita mm. PDA-laitteen yhteysparametrien määrittelyn mahdollisuuden GUI:n kautta ja PDA-laitteelle asennetun konfiguraation luvun suoraan PDA-laitteelta ja sen lisäämisen GUI:n aktiiviseen konfiguraatioon. 10

4 Ohjelmiston virheet Testaus suoritettiin T2-, T3- ja LU-vaiheiden aikana useammassa vaiheissa. T2-vaiheen lopulla aloitettiin moduulitestaus, joka valmistui T3-vaiheen lopulla. Moduulitestauksessa keskityttiin tarkemmin toiminnallisuuden yksityiskohtiin, jotta mahdolliset virheet varsinkin erikoistilanteissa tulisivat esille. Testaus suoritettiin black-boxtyyppisillä ajoilla, joissa oli etukäteen määritetty syöte ja osoitettu oikea lopputulos, joita analysoimalla ja vertailemalla testin tulokset saatiin selville. Integraatiotestaus tehtiin yhdistelemällä moduulien toiminnallisuuksia, niin että järjestelmä oli jo suurimmalta osaltaan lopullisessa muodossa. Integraatiotestauksessa pyrittiin löytämään virheitä, jotka johtuivat epäyhteensopivuuksista moduulien välillä. Lisäksi mm. ajastukseen liittyvät ongelmat olisivat tuulleet tässä vaiheessa esille. Järjestelmätestaus tehtiin lopullisella järjestelmällä, käyttäen hyödyksi testitapauksia, jotka hyödynsivät kattavasti järjestelmän toimintoja. Testitapauksista saatiin ennakkotietoja opponointitestauksen kautta, koska testitapaukset olivat melkein identtisiä näiden kahden testin välillä. Testausvaiheet ja miten niissä reagoitiin virheisiin: Moduulitestaus suoritettiin kahdesti, koska ensimmäisellä kierroksella löytyi bugeja, jotka estivät testien hyväksymisen määritettyjen läpäisykriteerien mukaan. Moduulitestien virheistä osa oli hyvinkin vakavasti moduulien toimintaan vaikuttavia, myös täysin valideilla syötteillä. Virheet raportoitiin Buranaan, josta ne poistettiin, kun virheet oli korjattu. Integraatiotestauksessa suoritettiin myös kaksi kierrosta, koska ensimmäisellä kerralla löytyi muutamia virheitä, jotka olisivat erikoistilanteissa haitanneet käyttöä. Testin tulosten perusteella paranettiin järjestelmän virheenhallintaa läpikotaisin, niin että mahdollisimman vähän ongelmista vuotaisi moduulien ulkopuolelle. Samalla luotiin myös Installerin osalta helposti päällekytkettävä debug-optio, jotta ohjelmistostamme riippumattomien ongelmien kohdentaminen helpottuisi. Opponointitestauksen suoritti Petri Kujala ja opponointitestauksen kohteena oli EVTrader. Opponointitestaukseen käytettiin aikaa noin kahdeksan tuntia. Opponointitestaus vastasi oman ryhmämme osalta lähinnä järjestelmätestausta. Testauksessa löytyikin muutama virhe, joka olisi saattanut oman ryhmämme testaamana jäädä löytymättä. Tästä syystä opponointitestaus todettiinkin erittäin hyväksi ja toimivaksi testausmenetelmäksi. Opponointitestauksessa ilmitulleet virheet todettiin korjatuiksi tätä seuranneessa ryhmän omassa järjestelmätestauksessa. Testaus suoritettin LU-vaiheessa ja järjestelmätestauksen suoritti Petri Kujala. Opponointitestaus, joka suoritettiin ryhmän omaa järjestelmätestausta ennen, vastasi hyvinkin monilta osin järjestelmätestausta. Ryhmän oman järjestelmätestauksen tarkoitus olikin lähinnä todeta opponointitestauksessa tulleet virheet korjatuiksi ja todeta myös, että korjauksista ei ole aiheutunut uusia virheitä. Opponointitestauksen jälkeen korjatuista moduuleista ei uusia virheitä löytynyt, joten järjestelmätestaus todettiin onnistuneeksi ja järjestelmä toimivaksi. Luovutustestaus sovittiin asiakkaan kanssa suoritetuksi demoilla, joita normaalin kommunikoinnin kautta heille suoritetaan. Erillistä luovutustestausta ei siis pidetty. Ilmenneitä virheitä yhdistävät tekijät: Virheet olivat usein erikoistapauksia, joita ei käytännösä ilmene. Palautearvoja ei oltu rajoitettu, eli oli ns. epämääräisiä tiloja. Osa johtui viallisesta Familiar Linuxin pakettilistauksista. Verkkohäiriöt ipaq:iin olivat myös syynä. Analysointi ja johtopäätökset: Virheitä voi käytännössä ilmetä melkein missä tahansa, tarkistuksia kannattaa käyttää ja myös viestejä järjestelmän toiminnasta. Käyttäjän täytyy saada ilmoitus, että virhe on tapahtunut. Syötteeseen ei kannata luottaa, myös se voi olla rikki. 11

5 Käytetyt menetelmät Kurssin aikana käytimme lukemattomia menetelmiä, joko suunnitellusti tai jopa tietämättämme. Projektissa pyrittiin toimimaan USDP 2 mukaan, kehittäen tuotetta incrementaaliseseti. Toteutuksessa käytettiin UML- ja use-casemallinnusta. Projketiryhmän jäsenille jaettiin selkeät vastuualueet heti kurssin alettua. Projektinhallinnasssa käytettiin pääosin kurssin tarjoamia työvälineitä ja menetelmiä. Riskinhallinnassa käytimme Delfoi-menetelmää. Vaatimustenhallinnan apuna meillä oli käytössä jäljitettävyysmatriisi, jonka tehoa näin pienessä projektissa hieman alussa epäiltiin, mutta 4. vaiheen alussa tulleiden uusien vaatimusten integroinnin yhteydessä tuo matriisi paljasti todelliset kykynsä. Ohjelmoinnissa käytettiin useita eri kieliä ja niiden dokumentoinnissa kullekin kielelle ominaista dokumentointitapaa. Näissä kuten muissakin asiakkaalle suunnatuissa dokumentaatiossa kielenä käytettiin englantia. Sen sijaan kurssin suuntaan kielenä käytettiin suomenkieltä. Tämä rajaus tehtiin heti kurssin alussa asiakkaan kanssa. Dokumentaatiota katselmoitiin soveltuvilta osin mutta esimerkiksi edistymisraportit eivät tuohon katselmointiin kovinkaan usein ehtineet, koska ne kirjoitettiin aivan viimeisenä, jotta kaikki siihen mennessä tapahtuneet tiedot siihen tulisivat. Tuotteen hallinnassa käytettiin CVS-versionhallintaa ja sen testaamisessa käytettiin V-mallia. Projektiryhmän sisäinen tiedottaminen tapahtui sähköpostilistan ja viikottaisen tapaamisen avulla. Sidosryhmien tiedotus oli suureltaosin sähköpostin varassa. Tapaamisia järjestettiin kuitenkin aina kun tarvetta esiintyi. Muutaman kerran asiakas tosin toivoi, että olisimme tavanneet useamminkin. Kurssin suorittamiseen kuului kuuden menetelmän raportoiminen. Alun perin ryhmällämme oli tarkoituksena tehdä seitsemän raporttia, jotta jokainen ryhmän jäsen tekisi omansa. Kurssin puolivälin tapahtumien johdosta Ari Haapaniemeltä tämä velvollisuus kuitenkin poistettiin ja näin ollen valmistuneita raportteja on kurssin vaatimat kuusi kappaletta. 5.1 CVS Concurrent Versions System on tarkoitettu tiedostojen versioiden hallintaan. Se ei ota kantaa tiedostojen sisältöön, joten sitä voidaan käyttää niin koodin, binäärien, kuin dokumentaationkin hallintaan. Projektin aikana tämä työkalu tuli varmasti tutuksi jokaiselle ryhmämme jäsenelle, ellei ollut sitä jo ennen kurssia. Näinkään pienen ryhmän olisi ollut mahdotonta työskennellä samojen tiedostojen kanssa samanaikaisesti ilman version hallintaa, joten sen asentaminen kurssia varten oli välttämätöntä. CVS käyttöliittymänä käytettiin komentoriviä, sekä graafisia lisävälineitä. Se on saatavissa monille eri arkkitehtuureille. Kaikki työstettävät tiedostot pyrittiin tallentamaan varmennettavaan versionhallintaan. Kuten jo aikasemmin mainittiin, oli tämän versionhallinnan käyttäminen välttämätöntä, jotta toisten tekemät muutokset eivät häviä välillä. Näin monta henkilöä pystyi työskentelemään saman tiedoston kimpussa yhtä aikaa. Versionhallintaa käytettäessä on kuitenkin aina muistettava, että ohjelmakaan ei pysty kaikkea päättelemään, mutta toisinkuin ihmiset se ei tällaisessa tilanteessa muokkaa mitään vaan merkkaa ainoastaa kohdat, jota se ei osaa ratkaista selkeästi ja informoi käyttäjää korjaamaan ongelmakohdat itse. 5.2 Delfoi Delfoi-menetelmää käytettiin riskienhallinnassa riskien kartoittamiseen ja niiden vakavuuden arvioimiseen. Menetelmä tuntuikin sopivan välttävästi osin sovellettuna projektin tarpeisiin.monia riskejä havaittiin ja melko moni havaituista riskeistä myöskin toteutui. Riskien vakavuuden arviointi asteikolla 1-5 ei tuntunut olevan paras mahdollinen käytäntö ja tuntui olevan myös erittäin vaikea arvioida miten eri riskien toteutumiset projektin lopputulokseen tulevat vaikuttamaan. Riskienkartoitus Delfoi-menetelmällä projektissa jossa jokainen projektin kanssa tekemisissä oleva tunteen toisensa ei ole paras mahdollinen, koska tulosta vääristävät tekijät (esim. laumaefekti) tulevat esille liian voimakkaasti. 5.3 Java-koodausstandardit Java-koodausstandardit ovat tärkeitä pitää mielessä aina kun Javalla jotain koodataan. Tässäkin projektissa samojen ohjelmapätkien kehitykseen osallistui useita henkilöitä. Mikäli koodaamisessa ei olisi käytetty Java koodausstandardeja vaan itse kukin olisi koodannut miten haluaa, olisi lopputulos saattanut olla se, että korjatessa toisen koodia olisi koodin joutunut uudelleenkirjoittamaan koska koodin alkuperäinen toimintatapa olisi jäänyt korjaajalle epäselväksi. Koodausstandardien mukainen koodi mahdollistaa erityisesti sen että kaikkien on helppo tulkita ja korjata 2 Unified Software Development Process 12

kenen tahansa tekemää koodia. Tässä projektissa koodin luettavuus on erittäin tärkeässä asemassa, sillä mahdolliseen jatkehehitykseen eivät ryhmän alkuperäiset jäsenet todennäköisesti osallistu ollenkaan. 5.4 Jäljitettävyysmatriisi Jäljitettävyysmatriisi on ensisijaisesti menetelmä vaatimusten ja toimintojen välisten riippuvuuksien dokumentointiin ja seurantaan. Sitä voidaan kuitenkin käyttää myös muiden projektissa ilmenevien monen-suhde-moneen - riippuvuuksien mallintamiseen. Tässä projektissa jäljitettävyysmatriisia käytettiin vaatimusten ja toimintojen, toimintojen ja moduulien sekä vaatimusten ja testitapausten välisten riippuvuuksien dokumentointiin. Jäljitettävyys matriisi esitettiin jokaisessa tapauksessa kirjaamalla jälkimmäisten luetteloon mistä ensinmainituista se riippuu tai on johdettu. Esimerkiksi toiminnallisessa määrittelyssä jokaiselle toiminnolle oli lueteltu vaatimukset joista toiminto oli johdettu. Tämä oli niin tärkeä riippuvuus, että sitä haluttiin havainnollistaa lisäksi myös matriisimaisella esityksellä, joka löytyy myös toiminnallisesta määrittelystä. Matriisimaisella esityksellä on listoihin nähden se etu, että matriisissa on helppo nähdä kerralla kaikki riippuvuudet molempiin suuntiin. Matriisi osoittautui hyödylliseksi, kun haluttiin varmistaa, että kaikki vaatimukset on toteutettu ja tehtäessä muutoksia vaatimusmäärittelyyn. Myös testitapauksien vakavuusasteet oli helppo määrittää, kun tiedettiin kuinka tärkeää vaatimusta ne testasivat. 5.5 UML Unified Modeling Language (UML) on tarkoitettu ohjelmistojärjestelmien ja niiden osien määrittelyyn, visualisointiin, rakentamiseen ja dokumentointiin. UML:ää käytettiin projektissamme vaatimusmäärittelyssä, toiminnallisessa sekä teknisessä määrittelyssä. Käyttöliittymän toteuttamiseen käytettiin olio-ohjelmointikieltä (Java), joten sen mallintamiseen voitiin käyttää teknisessä määrittelyssä UML:n luokkakaavioita. Vaatimusmäärittelyssä ja toiminnallisessa määrittelyssä käytettiin arkkitehtuurin kuvaukseen UML:n sijoittelukaavioita (deployment diagram) ja toimintojonojen kuvaukseen sekvenssikaavioita (sequence diagram). Osa kaavioista piirrettiin tavallisella piirto-ohjelmalla ja osa Microsoft Visiolla. MS Visio aiheutti joitain yhteensopivuusongelmia. UML sopi projektiimme hyvin. UML:n standardi tapa järjestelmän mallintamiseen ja dokumentointiin helpotti asiakkaan ja ryhmän välistä, sekä ryhmän sisäistä kommunikointia. 5.6 V-malli Testauksemme perustui V-mallin pohjalle ja suoritimme oikeaoppisesti myös useita iteraatioita testausvaiheissa korjataksemme viat. Johtuen projektin modulaarisuudesta, sopi V-mallin mukainen jaottelu hyvin projektimme testaukseen ja testaustasot oli helppo määritellä etukäteen. V-malli antoi mahdollisuuden rajoittaa myöhempien kierrosten testauksen detalji-tasoa, joten testitapaukset eivät lopussa hukkuneet yksityiskohtiin. Projektin suunnittelussa luotujen määrittelyjen pohjalta generoitiin testitapauksia liittyen meneillään olevaan testaukseen siihen läheisimmin soveltuvan määrittelyn perusteelta. Moduulitestukseen käytettiin teknisen määrittelyn pohjalta luotuja testitapauksia, joilla pyrittiin löytämään toiminnot, jotka olisivat tärkeitä järjestelmän kokonaistoiminnan kannalta. Integraatiotestaukseen liittyi kiinteästi toiminnallinen määrittely, joka rajasi moduulien välisen kommunikoinnin ja helpotti testien suunnittelua. Vaatimusmäärittely oli projektien tavoitteiden määrittely, jonka pohjalta koko projektin testitapauksetkin lopulta tehtiin, kokonaisuus ilmeni parhaiten järjestelmätestauksessa lopullisella ympäristöllä. Yleisesti V-malli oli toimiva ratkaisu tämänkaltaiseen projektiin, jossa oli paljon irrallisia ja itsenäisiä osia. Lisäksi heterogeeniset toteutusmenetelmät estivät yhteen osa-alueeseen tai kieleen sopivan testausmenetelmän käytön, V-malli taasen antoi enemmän vapautta. Lisäksi se toi selkeän jaksotuksen testaukseen projektin kuluessa ja auttoi löytämään virheitä riittävän ajoissa. 13

6 Mitä meille tapahtui Kurssin alussa onnistuimme hyvissäajoin kokoamaan ryhmän enemmän ja vähemmän tutuista henkilöistä. Kurssin alussa loimme nopeasti oman postituslistamme, joka toimikin kurssin aikana pääasiallisena tiedotuskanavanamme. Kun kurssi varsinaisesti alkoi oli meillä jo jonkinlainen käsitys ryhmämme kyvyistä. Kaikki ryhmämme jäsenet olivat jo opintojensa loppupuoliskolla, joten taitoa ryhmästä löytyi. Enemmän jouduimme puhumaan tapaamisissamme motivaation hankkimisesta tällaiselle pitkälle, aikaavievälle erikoiskurssille. Useimmat meistä käyvät jo töissä opiskelun ohessa ja osalla tämäkin on jo toisinpäin. Yhteisen ajan löytäminen oli kuitenkin suhteellisen helppoa, kun saimme tapaamisajan vakiinnutettua tiistai-iltaan. Tehtävän jako oli alussa aika yksimielinen ja projekti alkoi lupaavasti tapaamisella asiakkaan tiloissa syksyn alussa. Ensimmäisessä vaiheessa luodut suunnitelmat loivat hyvän pohjan kurssilla tehtävlle tuotteelle. Ensimmäisen vaiheen palautustilaisuus sujui mukavissa merkeissä, mutta palaute kurssin puolelta oli yllättävää. Hyvästä numeroarvostelusta huolimatta palautteessa oli ainoastaan yksi plussa, jonka vastapainona oli lähes kaksikymmentä miinusta. Arvostelusta keskusteltiin rakentavassa ilmapiirissä ja saimme selityksen miinuksillemme. Toisessa vaiheessa aloitimme tuotteen ensimmäisen version kehittämisen ja teimme muutamia uusia dokumentteja. Näiden lisäksi päivitimme vanhoja. Tämän vaiheen lopussa saapui tieto silloisen projektipäälikön siirtymisestä CERN:iin jatkamaan opintojaan. Jakso vietiin loppuun suunnitelmien mukaan. Kolmas jakso oli kaikella tavalla erikoinen. Sinä aikana ryhmämme suoritti projektipäälikön vaihtamisen, töiden uudelleen organisoinnin ja joululoman. Näillä eväillä alkuperäinen suunnitelma jouduttiin osittain muotoilemaan uudelleen. Kaiken muutoksen keskellä itse tuote kuitenkin kehittyi suunnitelman mukaisesti. Joulun tuoman muutaman viikon loman jälkeen projektin uusi käynnistyminen oli aika raskasta. Joulu on opiskelijoille selkeä lukukausien jakaja, jonka aikana on helppo nollata edellisen lukukauden asiat. Projektipäälikön siirtyminen tavalliseksi rivimieheksi ja toisen henkilön siirtyminen projektipääliköksi aiheuttivat omaa stressiään kaikissa, kunnes korvaajaa koskevat päätökset oli saatu tehtyä. Myös yhden projektihenkilön lähes kahden viikon mittainen työkomennus ulkomailla aiheutti töiden uudelleen organisointia. Jakson loppuun tultaessa huomasimme, että tunteja oli käytetty vain noin puolet suunnitelluista, joten asiakkaan kanssa sovittiin alkuperäisten vaatimusten uudesta läpikäynnistä. Neljännen jaksin suunniltelmaa päivitettiin heti jakson alussa vastaamaan edellisen jakson tuntienvajausta. uudet vaatimukset sisällytettiin nopeasti suunnitelmaan ja niiden kehittäminen ja integrointi jo valmiiseen järjestelmään. Testaamista oli suoritettu kehtyksen rinnalla joka inkrementin aikana. Tämän jakson aikana valmistuivat viimeisetkin menetelmädokumentit. Kaikki osallistuneet olivat tyytyväisi palautustilaisuudessa esitettyyn loppudemonstraatioon. Seuraavaan vaiheeseen jäi kuitenkin tämän vaiheen suunnitelmassa ollut järjestelmätestaus. Viimeisessä jaksossa, jonka nimeksikin on annettu luovutus on tarkoitus vielä yrittää etsiä järjestelmätestauksen ja opponointitestauksen avulla viimeisetkin virheet järjestelmästä ja tilanteen mukaan joko korjata tai ainakin dokumentoida ne. Tämän jälkeen järjestelmä on vielä hyväksytettävä asiakkaalla ja dokumentaatio päivitettävä ja tarkistettava. Kurssin pituus ja näiden töiden valitettavan vähäinen arvostus normaalissa työympäristössä vaativat projektinvetäjältä erityistä kykyä saada projektin henkilöt innostumaan vielä tähän viimeiseen vaiheeseen. Tässä vaiheessa paljastuvat yleensä salakavalimmat virheet, joita ei tavallisella testaamisella edes löydy. Ne saattavat kuitenkin olla juuri niitä ongelmia, jotka tulevat tavalliselle käyttäjälle heti esille. 6.1 Mitä me opimme Nyt kun projektia voi jo jossain määrin katsella taaksepäin olemme varmasti kaikki ylpeitä siitä, miten olemme vieneet tämänkin projektin tähän asti. En voi vielä kirjoittaa loppuun, koska sitä projekti ei vielä tätä kirjoitettaessa ole. Itse alkuosan projektipäälikkönä voin sanoa oppineeni paljon projektin aikana. Teknistä oppimista on tapahtunut varmasti jokaisella. Jouduimme tutustumaan moneen erilaiseen teknologiaan. Ohjelman kirjoittamiseenkin käytettiin monia eri kieliä. Myös käyttämämme menetelmät kuuluvat opittujen asioiden listalle. Nämä kaikki edelllä mainitsemani ovat kuitenkin niin sanottuja teknisiä asioita, kuten nämä kurssin aikana syntyneet dokumentaatiot. Tärkeimpänä oppinani tältä kurssilta pidän kuitenkin kanssakäymistä asiakkaan kanssa. Tämä jos mikä on valmistanut meitä tulevaa työelämää silmällä pitäen. Uskoisin tämän olleen muutamalle ryhmämme jäsenelle ensimmäinen kerta, kun he ovat joutuneet asiakkaansa kanssa silmäkkäin. Monelle TKK:n opiskelijalle asiakas on vain sana, josta vain puhutaan. Harvempi meistä on joutunut tämän asiakkaan kanssa samaan huoneeseen neuvottelemaan. Nyt jälkeenpäin voisi jopa sanoa, että harmi kun kaikki meni asiakkaan kanssa niin hyvin. Nyt olisi ollut hyvä hetki joutua vähän kiistelemään asiakkaan kanssa, kun vielä ei ollut niin paljoa pelissä. Myöhemmin näitä kiistoja kuitenkin kaikille valitettavasti tulee. Ohjaus kurssin puolelta ymmärtääkseni hakee edelleen hieman muotoaan, mutta auttoi joka tapauksessa meitä pysymään oikealla polulla raportointien suhteen. Ilman siltä puolelta tulevaa valvontaa olisi tuote varmasti ollut 14

aikaisemminkin jo valmiina, mutta sen ja dokumentaation laatu ei välttämättä olisi yltänyt samalle tasolle. Näin jälkeenpäin on huomattavasti helpompi nähdä, miksi menetelmistä oli hyvä kirjoittaa jonkinlaisia dokumentteja. Mitä hyötyä oli mentor-tapaamisista jne. Jälkeenpäin ne voi helposti mieltää esimerkiksi keskusteluiksi ja raportoinniksi esimiehen kanssa. 6.2 Missä teimme väärin Kurssin aikaisessa tuntiraportoinnissamme olisi osittain ollut paljon parannettavaa. Alussa tuntien syötön aloittaminen viivästyi Microsoft-Projektin käytön opettelun takia ja kun tunteja ei heti niitä tehtyään päässyt syöttämään järjestelmään, ne jäivät välillä syöttämättä. Samoin kurssin tarjoaman järjestelmän oma lisä lajittelu syötettäville tunneille tuotti alussa ihmetystä. Tuntiraportointi laahasi kurssin puoliväliin saakka perässä ja aiheutti puolivälin suuren tuntikadon. Tähän toki osaltaan vaikutti myös siinä tapahtunut organisaatiomuutos ja muutama ulkopuolinen työkomennus. Organisaatiomuttos, joka omalta osaltaan sujui melko hyvin, aiheutti tämänkokoiselle projektille huomattavia lisätekijöitä. Töiden uudellleenorganisointi, uusien työvälineiden opettelu vain muutamia mainitaksemme. Yksi asia, johon olisi pitänyt heti alusta lähtien kiinnittää enemmän huomiota on se, että ryhmän jäsenet olisivat varanneet etukäteen aikaa tätä projektia varten ja kertoneet tulevista menemisistään reilusti aikaisemmin. Aina tälläinen ei tietenkään ole mahdollista ja sellaisen seurauksia selvittelimme tammikuun ja helmikuun vaihteessa. 15

7 Ryhmäläisten ideoita ohjelmiston jatkokehittämiseksi Käyttöliittymän käytettävyyden parantaminen Diagnostiikkaa, joka selvittää miksi konfiguraatio ei ole validi Paketit, jotka tulevat riippuvuuksien kautta mukaan konfiguraatioon, lähtevät pois konfiguraatiosta kun riippuvuuden aiheuttajakin poistetaan. Tuki monen käyttäjän/pda:n yhtäaikaiselle käytölle pakettien hierarkiselle näkymälle ruudulla Alloinnin etenemisen näyttäminen käyttäjälle Konfiguraation tiedostojen yhteiskoon hallinta ja rajoittaminen logiikka-engineen 16

8 Palautetta kurssista Tässä erinäisiä lauseita ja mietelmiä, palautteeksi kurssista. Osa näistä olisi varmasti kuulunut mitä opimme kappaleeseen, osa on palautetta kurssin organisaatiolle. Kaiken kaikkiaan ryhmämme kuitenkin piti kurssia hyvin onnistuneena. Kurssi oli erittäin hyvää kokemusta tyulevaa työelämää ja sen projekteja varten. Samalla se antoi mahdollisuuden käytännössä soveltaa muilla kursseilla opittuja teorioita. Kerrankin työ suunniteltiin aluksi kunnolla ennen kuin aloitettiin ohjelmiston kokoaminen. Aikataulutus oli hyvä, jotta tuli selkeitä välitavoitteita ja toisaalta se myös pakotti suorittamaan kurssia koko ajan, eikä voinut jättää koko hjommaa viimeisen kuukauden ajaksi. Projektin hallinnasta jäi ryhmämme jäsenille edes jonkinlainen kuva, joka usein on opiskelijoilta vielä työpaikoilla aika hyvin piilotettu. Nyt se ei tule yllätyksellisesti kulmantakaa, vaan siihen osaa jo varautua. Käytetyämme eri menetelmiä saimme hieman kuvaa siitä, minkälaisia menetelmiä voi käyttää missäkin vaiheessa ja toisalta oliko projektimme liian pieni tai iso jollekin käyttämällemme menetelmälle.. Loppuraportti on hankala kirjoittaa kurssin vielä ollessa käynnissä. Se olisi voitava palauttaa vaikka viikko pari harjoitustyön loppumisen jälkeen. Dokumentoinnin osuus tuntui olevan aika suuri kurssin muun tarjoaman opin kannalta, toisaalta isommassa projektissa tämä olisi hyvä ja tämä on suurin projekti, minkä opintojen aikana todennäköisesti tulee suorittaneeksi, joten hyvä, että dokumentointikin käsitellään mahdollisimman laajasti. Mentorin merkitys jäi hieman kysymysmerkiksi ainakin meidän ryhmän osalta - kenen puolella hän työorganisaatiossa oikeasti olisi? Miksi mentor raportointia on lähes joka viikko kurssin lopussa. Niihin ei enää oikein riitä kerrottavaa, jos edellisellä viikolla on ollut vaikka vaiheen palautus? Projektipäälikölle vähän enemmän opetusta tiranan ja buranan käytön mahdollisuuksista ja MS-projectista. Niiden hyötyjä tuskin ainakaan me osasimme käyttää kokonaan hyväksi. 17