Hirviö Loppuraportti

Transkriptio

1 Hirviö Loppuraportti Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 15. maaliskuuta 2005 Tiivistelmä: Loppuraportti käy läpi projektin vaiheet alusta loppuun. Raportissa analysoidaan projektin tavoitteiden onnistuminen sekä kerrotaan tavoista, miten tavoitteisiin päästiin. 1

2 Sisältö 1 Johdanto Termit ja määritelmät Projektin eteneminen Projektin suunnittelu Toteutus I Toteutus II Viimeistely ja toimitus Tulokset Tavoitteet Ryhmän tavoitteet Asiakkaan tavoitteet ohjelmistolta Lopullisen tuotteen laatu Jälkipuinti Työtunnit Ohjelmiston koko Kirjatut viat Tietoturva-analyysi Työmenetelmät ja työkalut Menetelmät Viestintä Suunnittelumallit Refaktorointi Katselmoinnit Heuristinen analyysi Testaus Järjestelmätestaus Integraatiotestaus Yksikkötestaus Hyväksymistestaus Vertaistestaus Vikojen hallinta Lähdekoodin ja dokumentaation versiohallinta Työkalut Eclipse PHPUnit UML Poseidon for UML

3 6 Opitut asiat ja kurssin arvo Henkilökohtaiset tavoitteet Palautetta kurssista 17 8 Jatkokehitys 17 3

4 Sorvakko Ensiversio Sorvakko Rakenne ja sisältöideat Sorvakko Täytetty luvut 1, Sorvakko Täytetty luvut 6,7,8 soveltuvin osin Sorvakko Integrointi, loput kohdat 1 Johdanto Tämä dokumentti on Hirviö-ryhmän T Tietojenkäsittelyopin ohjelmatyö -kurssille tehdyn projektin loppuraportti. Projektissa oli tarkoituksena tuottaa hajautettu muistikirja TKK:n Tietoliikenneohjelmistojen ja multimedian laboratorion tarpeisiin. Projektin lähtökohtana oli laboratorion professorien käyttöön tarkoitettu ohjelmisto, johon he voisivat merkitä muistiinpanoja opiskelijoiden kanssa käymistään keskusteluista. Projektia suunniteltaessa ja ohjelmistoa määriteltäessä asiakkaan ja ryhmän lopulliseksi kannaksi muodostui ohjelmisto, jota voidaan käyttää ym. päätehtävän lisäksi myös opiskelijan diplomityön ja jatko-opintojen seurantaan sekä opiskelijoille annettujen lupausten seurantaan laboratorion järjestämillä kursseilla. 1.1 Termit ja määritelmät CVS Concurrent Versioning System IRC Internet Relay Chat PEAR PHP Extension and Add-on Repository, PHP:n laajennuskirjasto PHP PHP: Hypertext Preprocessor, erityisesti WWW-sivujen luontiin tarkoitettu skriptikieli SEPA Software Engineering Practice Assignment, ohjelmistotuotannon harjoitus SBTM Session-Based Test Management TML Tietoliikenneohjelmistojen ja multimedian laboratorio UML Uniform Modelling Language, ohjelmiston mallinnuskieli XHTML extensible Hypertext Markup Language, sivunkuvauskieli 2 Projektin eteneminen Tässä kappaleessa kuvataan projektin eteneminen vaihe vaiheelta, suunnitteluvaiheesta toteutusvaiheiden kautta viimeistelyyn ja palautukseen. Allaoleviin alakohtiin on koottu tiivistetysti kunkin kierroksen tärkeimmät tapahtumat, pääongelmat ja ratkaisut ongelmiin. Tarkempaa tietoa projektin etenemisestä resurssoinnin ja tavoitteiden suhteen löytyy kunkin kierroksen edistymisraporteista. 2.1 Projektin suunnittelu Projektin suunnitteluvaiheessa tärkeimpänä tehtävänä oli ryhmän sisäinen järjestäytyminen sekä projektin vaatimusten määrittäminen. Ryhmäkokoonpanoa mietittäessä sovittiin, että sitä voidaan kurssin edessä vaihtaa, mikäli suurta tyytymättömyyttä omaan tehtävänkuvaan ilmenee. Näin ei kuitenkaan tarvinnut tehdä. Kierroksella nousi esiin muutamia lähinnä kokemattomuudesta johtuvia ongelmia. Ensimmäisenä ongelmana oli ryhmämme hieman myöhäinen aloitus. Saimme ryhmämme kasaan, aloituspalaverin pidettyä ja ennenkaikkea asiakkaalta varmuuden projektin sisällöstä hieman 4

5 myöhään. Tämän takia suunnittelukierroksen työpanos painottui hyvin vahvasti kierroksen loppuosaan suurimman työpanoksen jäädessä suunnitelmien mukaisesti projektipäällikölle. Seuraavana ongelmana ryhmällämme oli hieman hajanainen käsitys siitä, mistä koko touhussa oli kyse. Alkuun ei ollut ollenkaan selvää, mitä kaikkea kurssin vaatimuksiin kuuluu, mitä kaikkea asiakkaan vaatimuksiin kuuluu, mitkä ovat asiakkaan edustajien roolit, miten mentor liittyy kaikkeen tähän... Kurssin kotisivulta löytyi paljon hyvinkin yksityiskohtaista tietoa monesta asiasta, mutta kokonaiskuvan hahmottumiseen meni yllättävän paljon aikaa. Ongelmasta lopulta selvittiin pontevalla sivujenlukemisella sekä keskustelulla mentorin ja työn ohjaajien kanssa. Kierroksen viimeisenä ongelmana oli suunnaton epätietoisuus siitä, mitä katselmointitilaisuudessa oikeasti tapahtuu. Tämä ratkaistiin sillä, että päätimme pitää ensimmäistä tilaisuutta lähinnä oppimiskokemuksena. Projektipäällikkö teki hieman huonoja valintoja sen suhteen, mikä informaatio on katselmoinnissa relevanttia ja mikä ei. Tästä syystä menetimme puoli pistettä, minkä kuitenkin ilolla oppirahoina maksamme. 2.2 Toteutus I Ensimmäisen toteutuskierroksen tavoitteena oli suunnitella ja toteuttaa ohjelmiston pääarkkitehtuuri sekä toteuttaa sisäänkirjautuminen ja ohjelman päänäkymä sekä yksinkertaisen muistiinpanon lisäys. Toteutettavat ominaisuudet valittiin sen perusteella, että niiden toimiminen vaatii valtaosan sovelluslogiikasta alleen; näin pystyttiin järkevästi testaamaan suurta osaa ohjelmiston runkorakenteesta. Kierroksella ilmeni, nyt kun pääsimme varsinaiseen tekemiseen käsiksi, erinäisiä ongelmia, jotka kaikki liittyvät jollain tavalla toisiinsa. Ryhmämme ei vielä tässä vaiheessa ollut kovin kokenut isoissa projekteissa työskentelemiseen. Lisäksi omien resurssien arviointi oli monelle ryhmäläiselle vaikeaa. Ensimmäinen havaittu ongelma liittyi työnjakoon ja työtehtävien laajuuden ennustamiseen. Osa annetuista tehtävistä osoittautui loppujen lopuksi huomattavasti työläämmiksi kuin alunperin ennakoitiin. Tämä aiheutti sen, että yksi projektin jäsenistä kulutti jo tässä vaiheessa valtaosan työtunneistaan. Jälkikäteen tilannetta analysoituamme totesimme kuintenkin, että vaikka tilanne olisi hahmotettu jo etukäteen, ei ko. tehtävän pilkkominen useammalle henkilölle olisi ollut kovinkaan järkevää tai tuottoisaa. Seuraava ongelma liittyi ryhmäläisten omaan ajankäyttöön. Kaikille ei vielä tässä vaiheessa projektia ollut aivan selvää, miten paljon aikaa projektiin todella menee. Lisäksi kaikki eivät vielä täysin kyenneet arvioimaan aikaa, mikä heiltä kuluu minkäkin ominaisuuden toteuttamiseen. Tämä johti lopulta siihen, että toteutunut työtuntikertymä jäi eräiltä ryhmäläiseltä kohtuullisen reippaasti. Ongelma tiedostettiin jo kohtuullisen aikaisessa vaiheessa, mutta varsinaista ratkaisua ei kierroksen aikana enää kyetty saamaan aikaan. Edellämainitut ongelmat korjattiin huomioimalla muuttunut resursointitilanne loppukierrosten tuntisuunnitelmissa ja jakamalla tehtäviä uudelleen niille, joilla tunteja oli käytössä enemmän. Viimeisenä ongelmana kierroksella törmättiin, odotetusti, tuotetun koodin laadun vaihteluun ryhmän jäsenten kesken. Oli ennakkoon tiedossa, että osa ryhmäläisistä on kokeneita ohjelmoijia ja osan ohjelmointikokemus rajoittuu muutamaan suoritettuun ohjelmointikurssiin. Ongelmaa kärjisti entisestään jossain määrin ylläkuvatut aikaongelmat, jotka supistivat yksikkötestausta. Myöhemmissä testausvaiheissa saatiin kuitenkin puutteet ja virheelliset toiminallisuudet kiinni ja niiden korjauskin saatiin suoritettua ripeästi. 2.3 Toteutus II Toisella toteutuskierroksella järjestelmään lisättiin Toteutus I -kierroksella tehdyn rungon päälle kaikki varsinainen toiminnallisuus. Vasta tällä kierroksella ohjelman käyttöliittymä ja toimintatavat saivat lopullisen muotonsa aiempien kierrosten suunnitelmien mukaisesti. 5

6 Edellisten kierrosten ajankäyttöongelmista viisastuneena tälle kierrokselle otettiin käyttöön henkilökohtaiset viikkotuntisuunnitelmat. Suunnitelmiin kirjattiin kunkin henkilön oma arvio siitä, miten aikoo kierroksen työtuntinsa käyttää. Näin onnistuttiin sekä helpottamaan tuntien seurantaa että konkretisoimaan joka ryhmäläiselle tehtävän työn määrä. Kierroksen pääasiallisena ongelmana oli jonkinlaiset kommunikointiongelmat eri dokumenttien, pääasiallisesti vaatimusmäärittelyn, sisällön suhteen. Tämä ongelma ratkaistiin istumalla pöydän ääreen ja keskustelemalla ja kirjaamalla ylös syntynyt konsensus. 2.4 Viimeistely ja toimitus Viimeistelykierroksella korjattiin aikaisemmilta kierroksilta jääneitä virheitä ennenkaikkea käyttöliittymälogiikan suhteen, asiakkaalta saadun palautteen ja oman käyttöliittymäanalyysin tulosten mukaisesti. Lisäksi käyttöohje toteutettiin tällä kierroksella lopulliseen muotoonsa. Kierroksella myös lopullisesti hyväksyttiin toteutettu toiminnallisuus. Kierroksen ainoat ongelmat liittyivät lähinnä kierroksen luonteeseen, eli viimeistelyyn. Tehtävänä oli paljon kaikkea pikkusilppua, joista osan tekemiseen oli varauduttu, osan ei. Tehtäviä pyrittiin jakamaan ihmisille, joilla oli vielä tunteja jäljellä, mutta käyttöliittymäkorjausten jakaminen usealle henkilölle ei vain onnistunut. Tästä johtuen käyttöliittymävastaavamme joutui jonkin verran ylittämään tuntibudjettinsta. 3 Tulokset 3.1 Tavoitteet Ryhmän tavoitteet Ryhmän yhteisenä tavoitteena oli kerätä kokemusta ohjelmiston suunnittelu-, kehitys- ja toteutusprosessista. Näkisimme tässä onnistuneemmekin. Kurssi oli suurelle osalle ryhmästä ensimmäinen isompi ohjelmistoprojekti, ja sen puitteissa tapahtuneista onnistumisista ja epäonnistumisista ryhmän jäsenet voivat ammentaa tietoa ja kokemuksia tuleviin haasteisiinsa. Ryhmän kokonaistavoitteena oli saada kurssista kiitettävä arvosana (5); tämän tekstin kirjoittamishetkellä lopullinen tulos on vielä epävarma mutta tähän mennessä tavoite on vielä hyvin saavutettavissa Asiakkaan tavoitteet ohjelmistolta Opiskelijakohtaisten muistiinpanojen tallentaminen Järjestelmän ensimmäisenä tavoitteena oli kyetä tallentamaan muistiinpanoja, jotka koskevat yhtä opiskelijaa. Tämä oli myös ensimmäinen toteuttamamme toiminnallisuus heti järjestelmän runkotoimintojen ja sisäänkirjautumisen valmistuttua. Muistiinpano koostuu tekstistä, mahdollisesta arkistointipäivämäärästä 1 sekä tiedosta, mihin opiskelijaan ja työryhmään se liittyy. Hakujen tekeminen nimen tai opiskelijanumeron perusteella Hakutoiminnallisuus on järjestelmän käytön kannalta ensiarvoisen tärkeä. Järjestelmä tarjoaa mahdollisuuden hakea opiskelijoita nimen tai opiskelijanumeron tai niiden osien lisäksi myös muilla kriteereillä, esim. diplomityön vaiheen tai sisäänkirjautumisvuoden mukaan. 1 Arkistoinnin yhteydessä muistiinpano katoaa näkyvistä oletusnäkymissä 6

7 Järjestelmän käyttäminen sekä laboratorion sisältä että ulkoa Järjestelmä on suunniteltu ja toteutettu käytettäväksi selaimella, tavallisten HTTP- ja HTTPS-yhteyksien kautta. Järjestelmää on toteutusvaiheessakin käytetty laboratorion koneiden lisäksi myös mm. kehittäjien kotikoneilta. Järjestelmän lopullinen asentaminen palvelimelle, joka näkyy myös laboratorion verkon ulkopuolelle, jää asiakkaan vastuulle. Opiskelijan perustietojen tallentaminen Järjestelmän toteutettiin asiakkaan määrittelemät opiskelijatietokentät. Tiedot pystyy syöttämään uutta opiskelijaa luotaessa, ja niitä on mahdollista muokata jälkeenpäin. Järjestelmän mukana toimitetaan lain vaatiman rekisteriselosteen runko. Rekisteriselosteen täydentäminen vastaamaan käyttöönoton jälkeistä tilannetta jää asiakkaan vastuulle henkilö- ja vastuukysymysten vuoksi. Tietoturvallinen järjestelmä Koska järjestelmä sisältää ihmisten henkilötietoja sekä mahdollisesti luottamuksellisia muistiinpanotietoja, on järjestelmän tietoturvaan jouduttu kiinnittämään huomiota. Järjestelmä käsittelee sisäisesti salasanoja sekä muita autentikointivälineitä vain hasheina, eikä selväkielistä salasanaa tallenneta koskaan minnekään. Myöskin on pyritty siihen, että järjestelmä ei virhetilanteessakaan tulostaisi tietokannan sisältöä. Asiakkaan vastuulle jää järjestelmän asentaminen siten, että sitä käytetään salatun HTTPSyhteyden yli. Diplomitöiden seuraaminen Järjestelmän oli alusta lähtien tarkoitus kyetä pitämään kirjaa opiskelijoiden diplomitöiden tilanteesta. Projektin edetessä vaatimukset seurantatavalle sekä seurannan tarkkuudelle muuttuivat moneen kertaan, mutta toteutettuun versioon ovat tyytyväisiä sekä projektiryhmä että asiakas. Työryhmät Hirviössä on mahdollista ylläpitää kokoelmaa työryhmiä. Ryhmien tarkka kokoonpano on kiinni käyttäjäorganisaatiosta, mutta järjestelmää on ajateltu käytettäväksi esim. siten, että kullekin kurssille on oma ryhmänsä, diplomitöille oma ryhmänsä sekä tarpeen mukaan muita ryhmiä. Työryhmien avulla voidaan rajata sitä, mitkä käyttäjät pääsevät näkemään ja käsittelemään mitäkin tietoa. Raportit Ohjelmaan toteutettiin, tavallisten hakujen lisäksi, myös erinäisiä asiakkaan toivomia tallennettuja hakuja, joista saa helposti tietoa ulos eri tilanteissa olevista opiskelijoista. Raporttien tuottamat tulokset eivät tällä hetkellä eroa tavallisista hakutuloksista mitenkään, jatkokehitysideaksi ehdotettiinkin jonkinlaisen tulostusnäkymän toteuttamista raporteista ja muista hakutuloksista. Opiskelijakäyttöliittymä Alunperinkin vähiten tärkeäksi ominaisuudeksi koettu opiskelijakäyttöliittymä päätettiin jättää projektin puitteissa toteuttamatta, yhteisymmärryksessä asiakkaiden kanssa. Pohdinnoista huolimatta emme kyenneet määrittelemään tarkalleen mitä kaikkia ominaisuuksia opiskelijakäyttöliittymässä tulisi olla, miten sen autentikointi tulisi hoitaa 2 ja kuka vastaisi opiskelijoiden ohjeistamisesta järjestelmän käyttöön. Tästä johtuen opiskelijakäyttöliittymän toteuttaminen jätettiin myöhemmin toteutettavaksi. 3.2 Lopullisen tuotteen laatu Lopullinen asiakkaalle toimitettava versio, Hirviö 1.0, ei sisällä yhtään merkittäväksi tai kriittiseksi luokiteltavaa havaittua ongelma. FD-iteraatiolla vianhallintajärjestelmään tehtiin vain muutamia merkintöjä ongelmista, joista vain yksi oli kriittinen 2. Hirviön keskeinen toiminnallisuus on testattu kattavasti ja järjestelmällisesti, joten kyseisistä ominaisuuksista ei oleteta enää löytyvän vikoja kuin pienellä todennäköisyyksillä. 2 Jatkokehitysideoissa on mainittu ATK-keskuksen Shibboleth -autentikointijärjestelmä joka valitettavasti ehti testivaiheeseen liian myöhään 7

8 Liitteenä on toimitettu lista kaikista avoinna olevista vioista ja ongelmista. Asiakkaan palaute Asiakas oli tyytyväinen tuotteen toiminnallisuuteen. Ryhmä kävi läpi vaatimusmäärittelyn asiakkaan kanssa, ja kummatkin osapuolet antoivat näkemyksensä siitä, täyttääkö ohjelmisto vaatimukset. Asiakkaalla oli beta-versio ohjelmistosta käytössään ennen tätä kokousta, ja asiakkaat kertoivat mitä toimintoja he toivoivat järjestelmään. Nämä toiveet koskivat toiminnallisuksia, joita ei suoraan mainittu vaatimusmäärittelyssä, vaan ne muotoutuivat testikäytön aikana. Ne toiveet, jotka koskivat käyttöliittymää pyrittiin ottamaan huomioon. Asiat, jotka vaatisivat isompia lisäyksiä ja muutoksia, kirjattiin muistiin jatkokehitysideoina. Ryhmä kertoi rehellisesti testauksessa ilmenneistä bugeista asiakkaalle. Vaikkakin osa bugeista oli näkyviä, ne olivat teknisesti helppoja korjata. Asiakkaan kanssa sovittiin aikataulu korjauksille, ja asiakas valtuutti ryhmän hyväksymään korjaukset heidän puolestaan. Vertaistestausryhmän palaute Vertaistestauksessa ilmeni vain muutama vähäinen uusi ongelma. Osa vioista oli väärinymmärryksiä, ja osa käytettävyyteen liittyviä ongelmia. Vertaistestausryhmä arvioi tuotteen laadun suppeasti ilmaisulla testatuissa komponenteissa ei ollu kriittisiä vikoja ja tärkeimmät toiminnot vaikuttivat toimivan oikein. Vertaistestausryhmä ottii kantaa vain testaamiinsa ominaisuuksiin, eikä arvioinut tuotteen yleistä laatua. Tämän vuoksi vertaistestausryhmän mielipidettä ja palautetta ei voitu analysoida kovinkaan syvällisesti. Vertaistestausryhmä ei kertonut suorittamansa testauksen kattavuutta testausraportissa, joten kattavuuden arviointi jäi projektiryhmälle. Vikaraporttien perusteella määriteltyjä toiminnallisia ominaisuuksia testattiin kohtuullisella kattavuudella, mutta käyttöohjeen soveltuvuuden arviointi oli heikko vaikka sen tärkeyttä korostettiin testausohjeistuksessa. 4 Jälkipuinti 4.1 Työtunnit Kurssin alussa määriteltiin jokaiselle ryhmän jäsenelle kokonaistyötuntimääräksi 190h. Alun palavereissa myös sovittiin, että yli- ja alitunteja pyritään viimeiseen saakka välttämään. Samalla todettiin kuitenkin, että kokemattomuutemme vuoksi n. 10% heitto suunniteltuun on vielä täysin hyväksyttävissä. Aivan täysin tässä tavoitteessa ei onnistuttu. Käyttöliittymävastaavamme keräsi viimeisellä kierroksella itselleen reippaasti ennakoitua enemmän tunteja, ottamalla vastuun käyttöliittymän parantamisesta sekä käytönaikaisen ohjeen tekemisestä. Muilta osin työtunnit pysyivät hyvinkin suunnitelluissa rajoissa. Henkilö Kokonaistunnit Kalliolahti Heikkinen Larja Nylund Sarjakoski Sorvakko Toivanen Ohjelmiston koko Kuvassa 1 on esitetty ohjelmiston tehollisten koodirivien (varsinainen ohjelmakoodi, ei sisällä testejä) kehitys projektin kuluessa. Käyrästä näkyy selvänä piikkinä aivan projektin alkuvaiheessa toteutettu arkkitehtuurirunko, joka liitettiin projektiin lähinnä kerralla. Lisäksi 8

9 käyrästä on havaittavissa refaktorointia tehneen SEPA-parin toiminta selkeänä notkahduksena tammikuun puolenvälin paikkeilla. Vastaavantyyppisistä projekteista kenelläkään ryhmän jäsenellä ei ollut omakohtaista kokemusta, mutta tutkittuamme esim. phpbb:n[5] ja Horde-projektin[6] soveltuvien osien koodimääriä, totesimme oman projektimme koodin määrän olevan varsin hyvin linjassa ainakin näiden avoimen lähdekoodin projektien kanssa. Kuva 1: Koodirivien määrän kehitys projektin kuluessa 4.3 Kirjatut viat Kaaviossa 2 on esitetty kaikki vianhallintajärjestelmään tehdyt merkinnät kehityksen aikana. Kirjattujen ongelmien lukumäärät korreloivat melko hyvin uusien ominaisuuksien lisäämisen kanssa: I1-iteraatiolla toteutettiin sovelluksen runko sekä muutamia ominaisuuksia, I2-iteraatiolla toteutettiin lähes kaikki loput ominaisuudet, joka näkyy myös kirjattujen virheiden määrässä. FD-iteraatiolla vianhallintajärjestelmään kirjattiin lähinnä asiakkaan muutospyyntöjä sekä muutamia havaittuja ongelmia. 4.4 Tietoturva-analyysi Julkisessa Internetissä toimivan sovelluksen kehityksessä on aina otettava huomioon tietoturva, koska sovellus on jatkuvasti alttiina murtautujille ja muille pahantekijöille. Vaikkei järjestelmään olemassa olevien suunnitelmien mukaan tulla tallentamaan mitään salaiseksi määriteltävää tietoa kuten arvosanoja, se sisältää paljon yksityisyydensuojan piiriin kuuluvaa dataa. Lisäksi siihen on tallennettu henkilörekisteri, jota on jo lainkin mukaan varjeltava ulkopuolisilta. Tietoturvanäkökohdat onkin otettu huomioon jo suunnitteluvaiheen alusta alkaen. 9

10 Vähäinen Merkittävä Kriittinen I1 I2 FD Yhteensä Kuva 2: Iteraatioilla kirjatut virheet vakavuusasteittain Alusta alkaen oli selvää että järjestelmään tarvitaan käyttäjien tunnistus ja todennus sekä useampia ns. oikeustasoja, joilla määritellään mihin tietoihin kullakin käyttäjällä on pääsy. Tunnistus ja todennus toteutettiin käyttäjätunnuksen sekä salasanan avulla ja alunperin sen oli tarkoitus toimia järjestelmän oman tietokannan lisäksi laboratorion hakemistopalvelimen sekä Atk-keskuksen uuden Shibboleth-todennusjärjestelmän avulla. Näitä kahta jälkimmäistä ei loppujen lopuksi toteutettu, koska niiden oma käyttöönotto viivästyi liikaa. Niille kuitenkin on jätetty järjestelmän arkkitehtuuriin paikat mahdollista jatkokehitystä varten. Mentorin vinkin perusteella järjestelmään suunniteltiin kaikkia merkittäviä tapahtumia kirjaava Audit Trail, jonka avulla vikatilanteita sekä mahdollisia murtautumisia voidaan jäljittää. Lokia kirjataan normaalisti tietokantaan omaan tauluunsa, mutta se voidaan ohjata myös tekstitiedostoon, josta sen lukeminen on vikatilanteita tutkittaessa helpompaa. Kustakin tapahtumasta tallentuu merkintä josta selviää tapahtumahetki, tekijä, tapahtuman tyyppi, tekijän IP-osoite, istunnon tunniste sekä mahdollisia tarkentavia lisätietoja. Järjestelmän tietoturvaa pyrittiin parantamaan monilla pienillä toiminnoilla, joista useimmat eivät näy loppukäyttäjälle. Tärkeimpinä näistä ovat syötteiden tarkistaminen sekä vanhentumisaika käyttämättömälle istunnolle. Syötteiden tarkistamisella tarkoitetaan mahdollisesti vahingollisten osien, kuten SQL-komentojen tai HTML-tagien, poistamista tai vaarattomaksi tekemistä kaikista käyttäjän syöttämistä tiedoista. Ilman tarkistusta sopivalla syötteellä tietokantaa on mahdollista tutkia tai jopa muuttaa sekä tehdä muuta harmia järjestelmälle. Istunnon vanheneminen puolestaan hankaloittaa auki jääneen istunnon kaappaamista, koska hyökkääjälle jää tällöin rajallinen määrä aikaa pahojen aikeiden toteuttamiseen. Hyökkääjän elämää hankaloittaa hieman myös se, ettei tietokantaan md5-tiivisteenä tallennettua salasanaa koskaan oteta ulos kannasta, vaan annetun salasanan oikeellisuus testataan tarjoamalla sen tiivistettä tietokannalle yhtenä hakukriteerinä. Järjestelmässä on myös joitakin eksplisiittiä tarkistuksia, joilla estetään käyttäjää tekemästä operaatioita, joihin hänellä ei ole oikeutta, johtuipa tilanne sitten virhetoiminnosta taikka murtautumisyrityksestä. Toteuttamamme ohjelma on vastuussa vain pienestä osasta koko järjestelmän tietoturvaa. Tarvittavista kolmannen osapuolen sovelluksista (http-palvelin, PHP, tietokanta jne.) valittiin käyttöön versiot jotka ovat olleet tuotantokäytössä jo jonkin aikaa, jolloin niistä on todennäköisesti jo löydetty ja korjattu pahimmat tietoturva-aukot. Nämä sovellukset on myös konfiguroitu siten, ettei turhia tai potentiaalisesti vaarallisia toimintoja ole käytössä. Sama koskee muitakin samalla palvelimella käytössä olevia ohjelmia. 10

11 Merkittävä osa tietoturvaongelmista on lähtöisin käyttäjistä, joten heidän ohjeistaminen esimerkiksi salasanojen ja käyttötapojen suhteen on erittäin tärkeää. Hyvät salasanat ja muut perusasiat ovat todennäköisesti järjestelmän käyttäjäkunnalle tuttuja, mutta niiden noudattaminen tuntuu olevan vaikeaa kaikesta ohjeistamisesta huolimatta. 5 Työmenetelmät ja työkalut 5.1 Menetelmät Viestintä Projektissa viestintä jakautui kahteen, kohtuullisen selkeästi eroteltavaan osaan, projektiryhmän sisäiseen viestintään sekä viestintään sidosryhmien kanssa. Viestintätapoja on kuvattu tarkemmin projektipäällikön SEPA-päiväkirjassa[7]. Projektiryhmän sisäinen viestintä Projektiryhmän sisäisessä viestinnässä tärkeimpänä työkaluna oli jo projektin alkuvaiheessa käyttöönotettu viikkopalaverikäytäntö. Viikkopalavereissa käytiin läpi projektin tila kunkin ryhmäläisen osalta, jaettiin suoritettavia tehtäviä sekä seurattiin aikaisemmissa palavereissa jaettujen tehtävien valmistumista. Viikkopalaverien tärkeimpänä tavoitteena oli pitää koko ryhmä tietoisena ryhmän kokonaistilanteesta sekä pyrkiä erilaisten ongelmatilanteiden mahdollisimman aikaiseen havaitsemiseen. Toinen käytössä ollut muodollinen viestintäkäytäntö otettiin käyttöön I2-kierroksen alussa. Kukin ryhmän jäsen teki tästä eteenpäin kierrosten alussa itselleen tuntisuunnitelman, johon merkittiin viikon tarkkuudella käytettäväksi suunnitellut tunnit sekä arvio siitä, minkä asian tekemiseen kyseisten tuntien on suunniteltu menevän. Tämä käytäntö helpotti rutkasti projektipäällikön seurantatehtäviä ja antoi myös jokaiselle ryhmäläiselle konkreettisen kuvan siitä, miten paljon tunteja seuraavan iteraation aikana oikeasti pitää saada käytettyä. Epämuodollisena kommunikointimuotona ryhmä käytti hyvin paljon IRC:iä. Mitään koko ryhmää koskevia päätöksia ei tietoisesti IRC:iä käyttäen tehty, mutta eri ominaisuuksien toteuttajat pystyivät sitä kautta sopimaan toteutusyksityiskohdista. IRC toimi siis jonkinlaisena korvikkeena pari- ja ryhmäohjelmoinnille; työtavan teho ei varmasti ole yhtä hyvä kuin aidossa ryhmäohjelmoinnissa, mutta henkilölogistiikka helpottuu ratkaisevasti. Lisäksi IRCkeskusteluista jää logi, jolloin tehtyjä päätöksiä päästään tarkastelemaan myöhemminkin. Viestintä sidosryhmien kanssa Projektin sidosryhmiin voidaan laskea kuuluvan projektin asiakas kaikkine edustajineen (2 professoria ja 2 tutkijaa) sekä projektille kurssin puolesta osoitettu mentor. Näiden osalta kurssin puolelta oli määritelty, että kunkin kierroksen aluksi pitää lähettää iteraatiosuunnitelma sekä asiakkaalle että mentorille. Kurssin ohjeistus lisäksi jos ei nyt pakottanut niin ainakin painokkaasti suositteli palaverien pitoa asiakkaan kanssa. Tämän lisäksi mentor järjesti muutamia kokouksia ryhmän kanssa. Asiakkaan kanssa kommunikoitiin muodollisesti asiakaspalavereissa, joita järjestettiin projektin kuluessa tarpeen mukaan. Asiakaspalavereissa käytiin läpi tehtyjä asioita sekä paranneltiin ja tarkennettiin asiakkaan vaatimuksia. Koska valtaosa projektiryhmästä työskentelee samassa paikassa asiakkaan kanssa, kommunikoitiin asiakkaan kanssa myös epämuodollisesti kahvipöytä- ja käytäväkeskusteluissa. Näiden arvoa on dokumentaation puuttuessa vaikea määritellä, mutta useampaan kertaan käytäväkeskusteluissa havaittiin tarve pitää oikea asiakaspalaveri. Lisäksi vapaamuotoiset keskustelut olivat hyvä tapa pitää asiakasta tietoisena siitä, mitä projektille kulloinkin kuuluu. 11

12 5.1.2 Suunnittelumallit Järjestelmän arkkitehtuurisuunnittelussa hyödynnettiin suunnittelumalleja ( design patterns ). Suunnittelumallit ovat dokumentoituja ja toimiviksi todettuja ratkaisuja yleisiin suunnitteluongelmiin olio-ohjelmoinnissa. Toisin sanottuna suunnittelumallit ovat uudelleenkäytettävän suunnittelun rakennuspalikoita. Arkkitehtuurisissa ratkaisuissa pyrittiin hyödyntämään valmiita suunnittelumalleja sen sijaan, että kaikille ongelmille olisi yritetty keksiä ratkaisut itse. Suunnittelumalleja hyödynnettiin kuitenkin vain soveltuvilta osilta, eikä arkkitehtuuria yritetty väkisin pakottaa niiden mukaiseksi. Järjestelmän arkkitehtuurissa päädyttiin hyödyntämään useita suunnittelumalleja, tärkeimpänä näistä sovelluksen noudattama MVC-malli, joka helpotti toiminnallisuuksien toteuttamista merkittävästi. Järjestelmäarkkitehti SEPA-pareineen arvioi suunnittelumallien helpottaneen arkkitehtuurin suunnittelua sekä auttaneen paremman lopputuloksen saavuttamisessa. Lisää tietoa käytetyistä suunnittelumalleista sekä kokemuksia niistä löytyy SEPA-päiväkirjasta Design Patterns [1] Refaktorointi Suunnittelumallien vastapainoksi toinen SEPA-pari hyödynsi lähdekoodin uudelleen muokkaamista eli refaktorointia. Tämän tuloksena arkkitehtuuri saatiin selkeämmäksi luokkasuunnittelutasolla. Selkeän suunnittelumallin ansiosta, mittaaville muutoksille ei ollut tarvetta. Mittaavimmat muutokset johtuivat nopeasti kasvavasta koodista; tietokantaa käsittelevä luokka kehitettiin luomalla tarpeen mukaan uusia metodeja jolloin metoditason suunnittelun puute näkyi päällekkäisenä koodina. Tätä luokkaa refaktoroitiin kun järjestelmän toiminnallisuutta ei enää laajennettu, jolloin se oli stabiilissa tilassa. Lisää tietoa käytetystä refaktorointimenetelmästä on SEPA-päiväkirjassa Refaktorointi [2] Katselmoinnit Dokumenttien katselmoinnit hoidettiin sähköpostikatselmointina jokaisen iteraation lopuksi. Katselmoitavat dokumentit ja vastuulliset henkilöt määriteltiin iteraation testisuunnitelmassa ja niitä tarkennettiin myöhemmin. Katselmoinneissa ei yleensä havaittu enää merkittäviä ongelmia, joten niiden arvo projektissa ei ollut kovin suuri. Tämä johtui todennäköisesti katselmointien liian nopeasta suorittamisesta, varsinaisten tarkastuslistojen puutteesta, sekä suppeasta ohjeistuksesta Heuristinen analyysi Järjestelmän käyttöliittymälle tehtiin käytettävyyden heuristinen arviointi, koska muita järkeviä menetelmiä järjestelmän käyttäjäystävällisyyden tutkimiseen ei ollut tarjolla. Arviointi käyttäjätestauksen perusteella ei ole järkevää, koska käyttäjäryhmän pienuuden ja erikoislaatuisuuden takia heidän tekemänsä arviot olisivat olleet liiaksi henkilökohtaisten mielipiteiden värittämiä, eikä asiakkaalla luultavasti olisi ollut edes aikaa käyttöliittymän järjestelmälliseen testaukseen. Ilman heuristista arviointia käyttäjäystävällisyys olisikin ollut käyttäjiltä sekä kehitystiimiltä saadun hajanaisen palautteen varassa. Arviointi toteutettiin soveltamalla järjestelmän sivuihin ja toimintoihin Jakob Nielsenin kehittämää ns. kymmenen kohdan heuristiikkaa[8]. Arviointi tehtiin molempien iteraatiokierrosten loppuvaiheessa ja yksityiskohtaiset tulokset on kirjattu sepa-päiväkirjaan[3]. Arvioinnilla löydettiin lukuisia pieniä käytettävyyttä haittaavia virheitä ja epäjohdonmukaisuuksia, joita korjattiin aina seuraavan kierroksen aluksi. Käytettävyysvirheiden lisäksi löysimme 12

13 myös muutamia varsinaisesta testauksesta läpipäässeitä toiminnallisia bugeja sekä törmäsimme odotetusti käytettävyyden ja tietoturvan ristiriitaisiin intresseihin. Heuristisen arvioinnin avulla järjestelmän käytettävyyttä saatiin parannettua merkittävästi, ja vaikkei kaikkia ongelmia voitukaan korjata, ne ovat ainakin tiedossa. Arviointi myös todisti miten helposti käytettävyysongelmia voi syntyä, mikäli asiaan ei kiinnitetä huomiota järjestelmän kehityksen aikana. 5.2 Testaus Testaus- ja laadunvarmistusmenetelmien käyttö onnistui kohtuullisesti. Käytetyt menetelmät olivat täysin riittäviä takaamaan lopulliselle tuotteelle halutun laadun. Käytetyt menetelmät keskittyivät suurilta osin tuotosten testaukseen jälkikäteen, ei niinkään ennakoivaan vikojen vähentämiseen. Lyhyet iteraatiot, sekä projektin kokoluokka mahdollistivat tämän; Hiukan tarkempi testaus kierroksen lopuksi nähtiin myös edullisempana ratkaisuna kuin ennakoivien menetelmien käyttö Järjestelmätestaus Tärkein testausmenetelmä oli implementaatiokierrosten lopuksi suoritettu järjestelmätestaus. Järjestelmätestaus suoritettiin osittain suunniteltujen testitapausten mukaisesti ja osittain ad hoc -testauksena. Järjestelmätestausta varten sovellus jäädytettiin, eli kaikkien koodiin liittyvien muutosten tuli olla jo tehtynä ennen testausta. Testattavat ominaisuudet suunniteltiin kierroksen aluksi ja niitä päivitettiin ennen testausta vastaamana todellista tilannetta. Tämän lisäksi kaikille ominaisuuksille oli osoitettu vastuullinen testaaja. Tämä osoittautui riittäväksi menetelmäksi ottaen huomioon projektin koon ja sovelluksen luonteen, joten kierroksen aikaista laatua ei tarkkailtu järjestelmällisesti. Tästä aiheutui joitakin ongelmia, mutta niiden estäminen laadunvarmistuksen keinoin olisi ollut työläämpää kuin korjaaminen jälkikäteen Integraatiotestaus Integraatiotestausta suoritettiin sovelluksen komponenttien integroinnin yhteydessä implementaatiokierroksella 1, osittain pakon vaatimana. Testaus suoritettiin ilman suunnitelmaa integroivien henkilöiden toimesta Yksikkötestaus Yksikkötestauksen käyttö epäonnistui projektissa suurilta osin. Yksikkötestejä oli tarkoitus tehdä implementaatiokierroksella 1 sovelluksen runkomoduulien toteutuksen yhteydessä testdriven-developement -periaatteen mukaisesti. Toteutus aloitettiin kuitenkin liian myöhään, jolloin lähes kaikki moduuleista vastanneet henkilöt jättivät testit tekemättä. Tätä yritettiin korjata testaamalla moduuleita jälkikäteen, mutta myös tässä epäonnistuttiin. Epäonnistuminen yksikkötestauksessa kostautui huomattavasti pitkittyneellä integroinnilla suuren vikamäärän vuoksi. Syyksi yksikkötestauksen epäonnistumiseen voidaan arvioida huono ohjeistus, yksikkötestien tärkeyden painotuksen puute, sekä kokonaisuudessaan epäonnistunut implementaatiokierroksen 1 tehtävien koordinointi ja suunnittelu Hyväksymistestaus Hyväksymistestausta varten ohjelmisto annettiin asiakkaalle käyttöön. Asiakasta ohjeistettiin järjestelmän käytössä sekä pyydettiin heitä kirjaamaan ylös kaikki mieleentulevat puutteet, ongelmat ja viat. Ainakin osa asiakkaan edustajista käyttikin järjestelmää testausvaiheen 13

14 aikana tositilanteessa, kirjaten järjestelmään muistiinpanoja opiskelijakeskustelujen yhteydessä. Asiakkaan hyväksymistestauksen jälkeen pidetyssä palaverissa asiakkaalta kerättiin testauksen aikana muodostunut palaute. Asiakas oli löytänyt muutamia järjestelmän hyväksymisen estäviä vikoja, jotka korjattiin hyvin nopeasti. Muu saamamme palaute koski järjestelmän jatkokehitystä; asiakkaalla oli tarjolla monta hyvää ajatusta järjestelmän toiminnan laajentamiseksi tai tositilanteihin paremmin sopivaksi. Hyväksymistestauksen lopputulos oli se, että asiakas totesi virhekorjausten jälkeen tuotteen toteuttavan annetut vaatimukset Vertaistestaus Hirviö-ryhmä suoritti kurssin vaatimusten mukaisesti vertaistestausta Malliperheen sovellukselle. Malliperheen sovellus oli testausvaiheessa vielä keskeneräinen, sekä varsin buginen. Sovellusta pyydettiin myös arvioimaan teknologiademona, mutta mitään varsinaisia arviointikriteereitä ei raportointi- ja testausvaiheessa ollut käytettävissä. Tämän lisäksi sovelluksen aihealue oli testaajille täysin tuntematon ja siihen tutustuminen olisi vaatinut suhteettoman paljon aikaa suositeltuun aikamäärään verrattuna. Näiden seikkojen vuoksi vertaistestaus ja sen rapotointi koettiin melko hankalaksi. Kurssi myös pakotti käyttämään SBTM-menetelmää, tarjoamatta kunnollista ohjeistusta. Tarkempi tutustuminen ja sen hyödyntäminen olisi todenneköisesti syönyt jo vähissä ollutta aikaa. Malliperheen suorittaman vertaistestauksen tuloksena ei saatu enää merkittäviä ongelmia, jotka olisivat muuttaneet ryhmän suunnitelmia. Malliperhe ei myöskään antanut arvioita Hirviö-sovelluksen yleisestä laadusta, joten kaikenkaikkiaan vertaistestaus todettiin myös tältä osin turhaksi. Yhteenvetona voidaan arvioida, että vertaistestauksesta oli enemmän haittaa kuin hyötyä ohjeistukseen (vaikkakin minimaalisen) ja raportointiin menetetyn ajan merkeissä. 5.3 Vikojen hallinta Vikojen hallintaan käytettiin kurssin tarjoamaa Bugzilla -järjestelmää. Bugzilla osoittautui kaikessa yksinkertaisuudessaan erittäin toimivaksi ratkaisuksi, jolla vikojen raportointi, seuranta ja hallinta saatiin hoidettua keskitetysti. Käyttöönotossa oli aluksi havaittavissa pientä kankeutta, johtuen ehkä vian raportoinnin monimutkaisuudesta verrattuna satunnaiseen muistiinpanoon koodiin / omaan päähän / muuhun dokumentaatioon. Käytännössä keskitetty järjestelmä osoittautui kuitenkin välttämättömyydeksi seurannan kannalta. 5.4 Lähdekoodin ja dokumentaation versiohallinta Lähdekoodin ja dokumentaation versiohallintaan käytettiin TML:n tarjoamaa cvs-palvelua, joka myös varmuuskopioitiin säännöllisti laboratorion puolesta. Varmuuskopioita ei tarvittu käyttää kertaakaan projektin aikana. 5.5 Työkalut Eclipse Projektin alkuvaiheessa ohjelmointityöhön osallistuneita suositeltiin käyttämään tai ainakin kokeilemaan Eclipse -kehitysympäristöä. Projektin edetessä jokainen näin tekikin. Osa ryhmän jäsenistä kuitenkin piti eclipseä liian raskaana käyttää monine ominaisuuksineen ja päätyi käyttämään perinteisiä editoreita (emacs). Lisäksi eräät Eclipsen ominaisuudet tai suo- 14

15 ranaiset virhetoiminnallisuudet etenkin CVS:n suhteen aiheuttivat pariin otteeseen harmaita hiuksia PHPUnit Suurimmalle osalla ryhmän jäsenistä tämä kurssi oli ensikosketus käytännön yksikkötestaukseen ja sitä kautta yksikkötestaustyökaluihin. PHPUnitin käyttö toivottavasti jäi kaikille mieleen tulevia projekteja varten UML UML:ää hyödynnettiin monipuolisesti useissa vaiheissa projektia. Projektin alussa vaatimusten määrittelyssä käytettiin apuna UML:n mukaisia käyttötapauksia selventämään järjestelmän toimintaa käyttäjän näkökulmasta. Arkkitehtuurisuunnittelussa taas hyödynnettiin UMLluokkakaavioita arkkitehtuurisien ratkaisuiden dokumentointiin tekniseen spesifikaatioon. Tässä vaiheessa luokkakaavioiden päätarkoitus oli kommunikoida arkkitehtuuria modulien toteuttajille. FD-kierroksella luokkakaaviot piirrettiin uudestaan tekniseen spesifikaatioon, tällä kertaa jatkokehityksen näkökulmasta Poseidon for UML UML-kaavioiden piirtämiseen käytettiin Poseidon for UML community editionia. Käyttökokemukset olivat myönteisiä Poseidonin piirto-ominaisuuksien osalta, mutta UML-kaavioiden siirtäminen Poseidonista mihin tahansa yleiseen kuvaformaattiin osoittautui liki mahdottomaksi Poseidonin tuottaessa muodoltaan rikkinäisiä kuvia. 6 Opitut asiat ja kurssin arvo 6.1 Henkilökohtaiset tavoitteet Heikkinen Antoisinta harjoitusprojektissa oli nähdä, miten hyvin käytäntö vastaa eri kursseilla opittuja asioita ohjelmistojen kehityksestä. Projektissa pystyi helposti havaitsemaan monissa paikoissa toitotetun nyrkkisäännön paikkansa pitävyyden: jos realistisia suunnitelmia ei ole, ei voi odottaa asioiden toteutumistakaan toivotussa ajassa. Lisäksi prosessin kannalta on tärkeää, että perusasiat ovat kunnossa. Esimerkiksi ilman versionhallintaa ja ryhmän jäsenten välistä kommunointia harjoitusprojektimme olisi ollut hankala toteuttaa. Kurssin puolesta annettu prosessikehys antoi liikkumavaraa prosessin muokkaamiselle ryhmää varten. Ongelmia prosessin muovaamisessa ryhmälle sopivaksi aiheutti kuitenkin projektin alkuvaiheessa ryhmän jäsenten aikataulujen yhteensopimattomuus. Tälläisen ohjelmistoprojektin aloittaminen opiskelijoille on vaikeampaa kuin kokopäiväisesti ohjelmistotuotannon parissa olevalle ryhmälle, jolla on muutoinkin pitkäaikaisempaa kokemusta alalta. Lisäksi dokumentaatioon painottaminen vaikutti prosessin tempoon hidastavasti. Näin jälkikäteen analysoitaessa, prosessin olisi ollut hyvä heti alusta saada nopea tempoinen syke, jolla olisi voitu ehkäistä kuvassa 1 (s. 9) näkyvä lähdekoodin nopea pyrähdys. Myöhemmin I2- vaiheessa käyttöönotetut viikkosuunnitelmat auttoivat tasaamaan projektin edistymistä. Kalliolahti Projekti kokonaisuudessaan oli kurssin kaikkein hyödyllisin anti. Toteutettu sovellus oli juuri sopiva kurssin mittakaavaan, jolloin kaikkiin projektin osa-alueisiin oli mahdollista panostaa riittävästi. En näe yksittäisistä tehtävistä kerättyä kokemusta (kuten suunnittelu, testaus ja koodaus) niin tärkeänä kuin koko projektin kokonaiskuvan hahmottamista. Toisinsanoen, oli erittäin opettavaista nähdä miten asiat nivoutuvat yhteen, mitä ongelmia tehdyistä valinnoista syntyi sekä arvioida miten työskentelytapoja voisi kehittää ongelmien välttämiseksi. 15

16 Tärkeänä pointtina tuli myös opittua koordinoinnin, töiden jakamisen ja suunnittelun sekä kommunikoinnin tärkeys. Kärjistetysti sanottuna, asiat joilla ei ollut tekijää eivät tulleet tehdyksi, ja asiat joiden tekemistä ei suunniteltu kasaantuivat aina iteraation loppuun. Larja Kuten moni muukin ryhmässämme, yllätyin kurssin suuresta työmäärästä. Ensimmäisen iteraation lopun melkein paniikinomainen koodaus opetti suunnittelemaan aikataulunsa paremmin seuraavilla kierroksilla. Myös Wiion viestinnän ensimmäinen laki, kommunikointi epäonnistuu aina, paitsi milloin se sattumalta onnistuu, tuli opittua kantapään kautta. Tylyistä opetuksista huolimatta kurssi kokonaisuutena oli varsin palkitseva kokemus. Kun asiat vain suunniteltiin kunnolla ja tehtävät jaettiin selkeästi, syntyi tulostakin. Tärkeimpänä oppina pitäisinkin tietynlaisen kokonaiskuvan hahmottumista ohjelmistokehityksestä. Teoreettiset tiedot saivat konkreettiset puitteet ympärilleen. Nylund Kurssi oli erittäin työläs, mutta opettavainen. Kurssin hyödyllisin osa oli oppia koordinoimaan ryhmän koodauspanosta. Kurssin alussa järjestelmän arkkitehtuuria kehitettiin samalla kun osa ryhmästä jo koodasi, ja nopeasti muuttuva todellisuus aiheutti ongelmia. Opimme projektin aikana miten tärkeää on dokumentoida kaikki tehty työ, ja varmistaa että kaikki ovat ajan tasalla. Toinen tärkeä opetus oli ajankäytön hallinta. Ryhmän sisäinen viestintä parani koko projektin ajan, ja työn lopussa tehdyt aikabudjetit pitivät parin tunnin sisällä paikkansa. Aikabudjetit paranivat sekä kokemuksen myötä että parantuneen tiedonkulun ansiosta. Sarjakoski Kurssi osoittautui työlääksi mutta hyödylliseksi. Hyödyllisin osa oli ehdottomasti erilaisten ohjelmistokehitysmenetelmien oppiminen sekä hyödyntäminen käytännössä. Opittuja asioita olivat muun muassa: ryhmän kommunikoinnin tärkeys ja vaikeus sekä sen monet menetelmät, tehtävien koordinointi, arkkitehtuurisuunnittelu, vaatimusmäärittely, versionhallinta suuremmassa projektissa, IDE:n täysimittainen hyödyntäminen sekä dokumentoinnin jalo taito. Sorvakko Vaikka kurssista oli paljon aikaisemmin kurssin suorittaneilta kuullutkin, tuli kurssin työmäärä ja tietynlainen hektisyys silti melkoisena yllätyksenä. Ryhmämme työnjaolla projektipäällikön suurin tehtäväkuorma ajoittui ensimmäiselle ja viimeiselle kierrokselle projektisuunnitelman ja loppuraportin muodossa. Kuitenkin tekemistä tuntui riittävän muillakin kierroksilla. Kurssista jäi käteen paljon opittuja asioita projektinjohtamisesta sekä ryhmädynamiikasta. Paljon toisteltua huomiota siitä, että jollekulle suoritettavaksi ajatellut tehtävät jäävät kokonaan suorittamatta, ei myöskään suostu uskomaan ennenkuin se on konkreettisesti purrut nilkkaan. Kaiken kaikkiaan, yksi opettavaisimmista kursseista mitä tähän mennessä on tullut eteen. Toivanen Kuten muidenkin kohdalla, kurssi osoittautui sangen työlääksi, mutta samalla erittäin opettavaiseksi. Päällimmäisenä kurssin opettamista asioista tulee mieleen suunnittelun sekä aikataulutuksen tärkeys sekä ryhmän jäsenten välisen kommunikoinnin merkitys. Tämä kurssi oli myös ensimmänen kerta kun käytössä oli organisoitu järjestelmällinen ohjelmiston testaus. Pienet projektit joihin tähän mennessä olen osallistunut on pystytty toteuttamaan puutteellisella suunnittelulla ja organisoimattomalla testauksella, mutta näin suuressa projektissa se olisi ollut mahdotonta. Minulla oli myös ensimmäistä kertaa käytössä paljon kehuttu kehitysympäristö Eclipse. Vaikkei siitä saanutkaan kaikkea hyötyä irti koska koodia ei voinut ajaa samalla koneella se osoittautui erittäin näppäräksi työkaluksi. Suurimpia ongelmia olivat kurssin vaatima aika sekä paikoin puutteellinen ja hankalasti löydettävä ohjeistus. Kokonaisuutena kurssi oli kuitenkin erittäin hyödyllinen ja opettavainen. 16

17 7 Palautetta kurssista Kurssin tärkein anti oli turvallisen hiekkalaatikon tarjoaminen ohjelmistoprojektissa toimimisen opettelulle. Kokeiluja ja virheitä on huomattavasti rakentavampaa tehdä ympäristössä jossa niiden raportoinnista jopa palkitaan, kuin tosielämän ympäristössä jossa jokainen virhe maksaa. Lisäksi ryhmämme koki kurssin tarjoaman mentoroinnin erittäin hyödylliseksi; mentor toimi erittäin hyvänä rajapintana muuhun kurssihenkilökuntaan ja auttoi huomattavasti projektin eri vaiheissa, kokonaisuuden hahmottamisesta kurssibyrokratian yksityiskohtien selvittämiseen. Kurssin huonoimpana puolena täytyy tällä hetkellä pitää kurssin kotisivuja. Sivut ovat laajat ja niiltä löytyy paljon hyödyllistä tietoa, mutta tietosisällön sisäistäminen ja ennenkaikkea oikean tiedon löytäminen on usein hankalaa. Tätä voisi helpottaa sivujen uudelleenorganisoinnilla, esim. jonkinlaisella roadmapilla siitä miten projekti etenee ja mitä missäkin vaiheessa tarvitaan. Yhtenä ideana tilanteen parantamiseksi ryhmällemme tuli mieleen jonkun kurssin suorittaneen opiskelijan palkkaaminen esim. kesäksi miettimään uuden sivurakenteen ja sen, mitä tietoa ryhmät missäkin työvaiheessa oikeasti tarvitsevat. Kurssin tarjoamista työkaluista Trapoli aiheutti luultavasti eniten päänsärkyä. Järjestelmä kyllä sinänsä toimii, mutta sen käyttölogiikka etenkin työitemien suodatuksen suhteen ei ollut ollenkaan selvä, ja aiheutti usein päänraapimista 3 vielä logiikan hahmottamisen jälkeenkin. Parannusehdotuksia on vaikea keksiä, toimivampia työaikakirjanpitojärjestelmiä on nähty mutta ne ovat kaikki joko kalliin kaupallisen järjestelmän osia tai sitten jonkin yrityksen sisäiseen käyttöön toteutettuja, eivätkä sinällään soveltuvia kurssin käyttöön. 8 Jatkokehitys Projektin loppuvaiheilla sekä projektiryhmälle että asiakkaalle tuli useita ideoita järjestelmän jatkokehitykseen liittyen. Opiskelijakäyttöliittymä Alun perinkin järjestelmän vähiten merkitseväksi ominaisuudeksi määritelty opiskelijakäyttöliittymä jätettiin yhteisellä sopimuksella toteuttamatta projektin puitteissa. Kunhan järjestelmä on ollut asiakkalla käytössä jonkin aikaa, lienee selvillä opiskelijakäyttöliittymän tarve sekä siltä vaadittavat ominaisuudet. Ulkoinen autentikointi Järjestelmään on toteutettu valmius ulkoisiin autentikointimetodeihin. Projektin alussa suunnitellut metodit, laboratorion sisäinen hakemistopalvelin sekä ATK-keskuksen Sibboleth -palvelu valmistuivat käyttöön projektin kannalta liian myöhään, jolloin niitä ei enää ehditty projektin puitteissa ottaa käyttöön. Etenkin hakemistopalvelimen hyödyntäminen jatkokehityksen kannalta olisi mielenkiintoista, silloin käyttäjät välttyisivät jälleen yhden salasanan muistamiselta. Muistiinpanot useammalle opiskelijalle Lyhyehkön tositilannetestin jälkeen yhdelle asiakkaan edustajalle tuli eteen tilanne, joka olisi vaatinut saman muistiinpanon liittämistä useampaan opiskelijaan. 4 Tämä ei ollut tullut kenellekään mieleen projektin aikana, mielenkiintoista olisikin nähdä miten helposti näinkin tietorakennemielessä poikkeavan ominaisuuden saisi toteutettua. Tulostusnäkymä hakuihin Järjestelmä antaa tällä hetkellä hakutuloksina navigoitavaksi tarkoitetun listan opiskelijoista. Etenkin raporttien osalta voisi olla perusteltua tehdä erillinen tulostusnäkymä, johon kerättäisiin hieman enemmän tietoa kustakin opiskelijasta selkeästi paperille tulostuvassa muodossa. Tunnetuista virheistä toimitetaan yhteenveto kierroksen palautuksen yhteydessä. 3 Mihin ihmeeseen se just luotu työtyyppi muka katosi... 4 Koskien kahden henkilön suorittamaa toisiltaan kopiointia jossain harjoitustyössä 17

18 Viitteet [1] Anssi Kalliolahti ja Liia Sarjakoski, SEPA-päiväkirja Design Patterns [2] Jani Heikkinen ja Kim Nylund, SEPA-päiväkirja Refaktorointi [3] Jukka Larja ja Timo Toivanen, SEPA-päiväkirja Heuristinen Arviointi [4] SLLOCCount, [5] phpbb.com :: Creating Communities, [6] The Horde Project, [7] Samuli Sorvakko, SEPA-päiväkirja Viestintäkäytännöt [8] J. Nielsen, Heuristics for User Interface Design, heuristic/heuristic_list.html, viitattu