Desmond-opiskelijakalenteri Loppuraportti Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Matti Koskimies 25. toukokuuta 2003 Ohjelmistotuotantoprojekti, kevät 2003 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Versio Päivämäärä Kommentti Tekijä 1.0 21.5.2003 Loppukokouksen Mikko Hämäläinen pohjalta tehty versio
Sisältö 1 Johdanto 1 2 Työnkulku 1 2.1 Projektisuunnitelma......................... 2 2.2 Määrittely............................... 2 2.3 Suunnittelu.............................. 2 2.4 Toteutus................................ 3 2.5 Testaus................................ 3 3 Toteutettu ohjelmisto 4 4 Opittua 5
1 Johdanto Ohjelmistotuotantoprojektissa Desmond-opiskelijakalenteri suunniteltiin ja toteutettiin opiskelijakalenteri Helsingin yliopiston tietojenkäsittelytieteen laitokselle. Tämän dokumentin tarkoituksena on muodostaa yhteenveto aikaansaannoksista, projektin kulusta ja suoritetusta työmäärästä. Ryhmän jäsenet olivat: Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Matti Koskimies Ohjaajana toimi Toni Strandell ja asiakkaat olivat Vilho Raatikka ja Anni Rytkönen. 2 Työnkulku Projektin projektimalliksi valittiin yksimielisesti vesiputousmalli. Malli ei kuitenkaan pysynyt puhtaana vesiputousmallina projektin loppuun asti vaan alkoi toteutusvaiheessa siirtyä enemmän iteratiiviseen suuntaan, jossa ryhmä toteutti uudet ominaisuudet, testasi ne ja siirtyi toteuttamaan seuraavia. Tämä kuitenkin tuntui hyvin luontevalta lähestymistavalta eikä sitä pyritty keinotekoisesti rajoittamaan projektimallin takia. Määrittely ja suunnitteluvaiheessa ryhmän kommunikointi rajoittui lähinnä yhteisiin kokouksiin, mikä vaikeutti välillä hieman töiden koordinointia. Toteutusvaiheeseen siirryttäessä alettiin kuitenkin pitää enemmän epävirallisia koodaus- ja testauskokouksia, jotka paransivat yhteistyötä ja olivat tärkeä osa varsinkin järjestelmän integroinnissa ja testauksessa. Näitä kokouksia pidettiin epäsäännöllisesti ja ne olivat usein kestoltaan hyvinkin pitkiä, mutta ryhmäläiset osoittivat hyvää joustavuutta sopiessaan yhteisiä aikatauluja. Töissä käyville yhteiset tapaamiset olivat luonnollisesti vaikeampia, mutta mitään suuria ongelmia ei yhteisten tapaamisten järjestämisessä tullut. Ryhmän jäsenien välistä kommunikaatiota paransi toteutus ja testausvaiheessa aktiivisessa käytössä ollut IRC-kanava, jossa setvittiin ongelmia koodauksesta dokumenttien sanamuotoihin. IRC-kanavan perustamista ja käyttöä suositellaan tulevillekkin projekteille. Projektin aikana tuotettiin seuraavat dokumentit: Projektisuunnitelma Määrittelydokumentti Suunnitteludokumentti Toteutusdokumentti 1
Käyttöohje Testausdokumentti Loppuraportti Näiden lisäksi kirjoitettiin 28 kokouspöytäkirjaa sekä joukko ryhmänsisäisiä ohje ja suunnitelmadokumentteja. 2.1 Projektisuunnitelma Projektisuunnitelmaa pidettiin varsin onnistuneena. Aikataulutus muuttui kaikkein eniten alunperin suunnitellusta, mitä pidemmälle projektissa päästiin, johtuen pitkälti siirtymisestä iteratiivisempaan malliin toteutus ja testausvaiheessa. Lisäksi suunniteltujen lisäominaisuuksien toteutus toi arvioitua enemmän työtä. Projektiryhmä ei rajoittanut itseään kovin tiukasti ensimmäisessä kokouksessa jaettuihin vastuualueisiin. Dokumenttivastaavan ja projektipäällikön töitä hajautettiin luontevasti useammalle henkilölle eikä web-vastaavuuskaan ollut kovin selväpiirteinen. Selkein vastuualue oli Villellä, joka toimi projektin tietokantavastaavana alusta loppuun. Projektisuunnitelmaan kirjatut riskit osoittautuivat hyviksi eikä projektin aikana tullut esiin mitään suurempia riskejä, joita ei oltaisi alussa mietitty. Toteutettavan ohjelmiston arkkitehtuuri oli jo projektisuunnitelmaa tehdessä pääpiirteittäin selvillä, josta se projektin aikana tarkentui. Ohjelmiston koko arvioitiin vahvasti alakanttiin ja tiettyjen komponenttien roolit muuttuivat hieman, jolloin niiden koko kasvoi suunnitelmaan verrattuna. 2.2 Määrittely Määrittelyvaiheessa projekti alkoi tarkentua ja hieman epäselvään tehtävämääritykseen saatiin selkeyttä asiakkaiden kiitettävällä ja aktiivisella osallistumisella. Tietyt tehtävämäärityksen kohdat karsiutuivat pois ja uusia ominaisuuksia keksittiin runsaasti ryhmän taholta. Käyttötapauksien keksimistä ja järjestelmän määrittelyä helpotti suuresti se, että järjestelmä oli suunnattu opiskelijoiden käyttöön. Näin ryhmän jäsenillä oli helpompi hahmottaa mitä asiakas halusi ja ehdottaa itse parannuksia. Näin ei myöskään päässyt tulemaan tilannetta, jossa asiakas olisi muuttanut tai lisännyt määrityksiä tämän vaiheen jälkeen. Tavoitepohjaisten käyttötapausten kartoitus helpotti myöhemmin järjestelmän suunnittelua ja toteutusta erityisesti käyttöliittymän osalta. Määrittelyä tehdessä ohjelmistotuotantoprojektin formaalius ja dokumenttipainotteisuus sekä määrittelyiden tarkkuus meinasi rasittaa ryhmää verrattuna vastaaviin projekteihin työelämässä. 2.3 Suunnittelu Suunnitteluvaiheessa arkkitehtuuri tarkentui lopulliseen muotoonsa lukuunottamatta kirjautumisjärjestelmää, johon ei lopulta tarvittu erillisiä istunnonvalvonta komponentteja. Suunnitelmaa pyrittiin tekemään kattavasti, mutta silti 2
jäi jäljelle aika paljon ominaisuuksia ja järjestelmän osia, jotka jäivät epäselviksi ja niitä jouduttiin suunnittelemaan vielä tarkemmin toteutuksen ohessa. Näiden osien toteutus ei kuitenkaan tuntunut merkittävästi hitaammalta tai vaikeammalta, vaikka tarkempi suunnittelu olisikin varmasti helpottanut. Suunnitteluvaiheessa yritettiin välttää turhaa suunnittelua, koska suunnitelman uskottiin muuttuvan kuitenkin toteutusvaiheessa. 2.4 Toteutus Kaikki pitivät Javaa hyvänä kielenä järjestelmän toteutukseen eikä kukaan olisi lähtenyt vaihtamaan kieltä vaikka siihen olisikin ollut mahdollisuus. Jotkut järjestelmän osat olisivat olleet helpommin toteutettavissa esimerkiksi Perlillä, mutta Java toimi kokonaisuutena hyvin ja kaikilla oli siitä aikaisempaa kokemusta. Työkaluista varsinkin Jakarta-projektin Struts-kehys käyttöliittymän toteutukseen osoittautui erittäin käyttökelpoiseksi. Sen avulla saattoi keskittyä varsinaiseen ohjelman logiikkaan ja käyttää perustoiminnallisuuden luomiseen Strutsin palveluita, jotka helpottivat Servlettien ja JSP-sivujen toteutusta sekä selkeyttivät käyttöliittymän rakennetta. Laitokselle juuri ennen projektin alkua asennettu Tomcat ympäristö helpotti suuresti järjestelmän toteutusta ja testausta. Jokaisella jäsenellä oli omassa kotihakemistossaan oma Tomcat-asennus, jossa he saattoivat ajaa versiotaan järjestelmästä, eikä yhteistä asennusta tarvinnut tehdä ollenkaan. Helposti asennettava CVS-järjestelmä oli kätevä koodin jakamiseen ja versionhallintaan. Järjestelmä oli jaettu selkeästi vastuualueisiin toteutuksen ja testauksen osalta. Nämä vastuualueet säilyivät läpi toteutus ja testausvaiheiden ja vaikka ne eivät vastanneetkaan kooltaan aivan toisiaan ei tämä haitannut projektin jäseniä. Neljän hengen projektissa jaetut vastuualueet tuntuivat ainoilta loogisilta. Vastuualueista ja järjestelmän arkkitehtuurista aiheutui välillä pieniä koordinaationgelmia. Arkkitehtuuri oli suunniteltu hyvin pitkänomaiseksi, jossa kutsut kulkivat päästä päähän jokaisen vastuualueen läpi, jolloin uuden kutsun lisääminen tarkoitti vastaavien kontrollien lisäämistä jokaisen vastuualueeseen. Leveämmänmallisen arkkitehtuurin suunnittelulla tästä ongelmasta oltaisiin voitu päästä, mutta sitä ei tultu ajatelleeksi arkkitehtuuria suunniteltaessa tai vastuualueita jaettaessa. Muuten arkkitehtuuri ei tuottanut ongelmia ja siihen oltiin tyytyväisiä. 2.5 Testaus Testaus tuntui vaikeimmalta vaiheelta projektin jäsenille. Vaikka testauksesta on saatu lähinnä teoreettista opetusta ohjelmistotuotanto kurssilla, sen soveltaminen käytäntöön osoittautui vaikeammaksi. Vaikka työkaluja kuten JUnit tunnettiin ja käytettiinkin, ei koskaan tuntunut kovin selvältä kuinka testejä tulisi tehdä ja näin virallisten yksikkö ja integraatiotestien määrä jäikin vähäiseksi. Ryhmän mielestä laitoksen tulisi panostaa enemmän myös käytännön testauksen opetukseen. Monilla kursseilla korostetaan testauksen tärkeyttä, mutta sitä 3
ei varsinaisesti opeteta missään. Esimerkiksi syksyn Ohjelmistotekniikka (Java) kurssilla se oli ensimmäinen asia mikä pudotettiin pois kurssin ohjelmasta kun aika ei riittänyt kaikkeen suunniteltuun. Erillisen harjoitustyökurssin järjestäminen tai testaukseen panostamisen muilla harjoitustyökursseilla voisi olla järkevää. Järjestelmää testattiin kuitenkin tyydyttävästi yhteisissä integraatiotestikokouksissa ja omalla ajalla. Useat testit suoritettiin kuitenkin ilman varsinaisia testiluokkia ja seuraten lokiin virtaavia viestejä, mikä teki testauksen dokumentoinnista myöhemmin vaikeaa. Järjestelmätestejä tehtiin kattavasti ja niiden pohjalta järjestelmä vaikuttaa toimivan palautettaessa ilman näkyviä virheitä. 3 Toteutettu ohjelmisto Projektin jäsenet olivat yhtä mieltä siitä, että suuri syy tähän ryhmään hakemiseen oli se että järjestelmä tulisi opiskelijakäyttöön laitokselle eikä pelkästään tutkimukselliseksi kuriositeetiksi. Jäseniä motivoi, että oman työn tulokset näkyy oikeassa käytössä. Kaikki olivat tyytyväisiä valmiiseen ohjelmistoon ja uskoivat sen olevan hyödyllinen varsinkin uusille opiskelijoille. Projektisuunnitelmaa tehtäessä ohjelmiston kooksi arvioitiin 2200 riviä fyysistä koodia ilman kommentteja tai tyhjiä rivejä. Toteutuneen ohjelmiston koko oli 13701 fyysistä riviä ja 21519 kommentit ja tyhjät rivit mukaan luettuna. Valmis ohjelmisto oli siis noin kuusi kertaa arvioitua suurempi mikä selittyy osaltaan sillä, että projektisuunnitelmaa tehtäessä kuva järjestelmästä oli rajallinen verrattuna siihen miksi se selkeytyi määrittelyvaiheessa. Lisäksi määrittelyvaiheessa keksittiin useita lisäominaisuuksia, jotka toteutettiin järjestelmään. Koodirivit jakautuivat ohjelmiston pakettirakenteen mukaan seuraavasti: 4
control: 224 2% data: 2057 15% db: 4835 35% ui: 3147 23% taglib: 2017 15% JSP-sivut: 1421 10% Yhteensä: 13701 100 % 4 Opittua Projektin jäsenet tunsivat oppineensa uutta projektin aikana. Projektin suunnittelusta ja aikataulutuksesta saatiin kokemusta, josta katsottiin olevan hyötyä tulevaisuudessa. Uskottiin, että virheistä ja onnistumisista opittiin ja projektityö osataan hoitaa paremmin ensi kerralla. Javasta ja JDBC:stä opittiin uutta ja niiden käyttö muuttui sitä sujuvammaksi mitä lähemmäksi projektin loppua päästiin. Oracle tuotti välillä ongelmia, mutta nyt tiedetään ero date ja timestamp luokkien välillä. Struts osoittautui kehujen arvoiseksi ja JSP-sivut ihan toimivaksi dynaamisen HTML:n esittämiseen. Custom tagit ovat hyvä tapa siirtää esityskoodia JSP-sivuilta omiin kokonaisuuksiin. 5
Kurssia pidettiin ehdottomasti hyödyllisenä työelämää varten. Vaikkeivat monet kurssilla hyvinkin kärjistetyn tuntuiset vaiheet toteudu työpaikoilla on kurssista hyötyä tosielämään valmennuksessa. A Tunnit Seuraavassa ryhmän editysmisraportit projektin ajalta. Ajanjakso: 13.1.2003-2.2.2003 Matti Koskimies 37 37 Miika Hartikainen 36 36 Mikko Hämäläinen 47 47 Ville Karjalainen 35 35 19.1.2003 Projektisuunnitelma 22.1.2003 Määrittelydokumentti 30.1.2003 Käyttöliittymän suunnittelu 28.1.2003 Projektisuunnitelma Ajanjakso: 3.2.2003-16.2.2003 Matti Koskimies 32 69 Miika Hartikainen 33 71 Mikko Hämäläinen 31 78 Ville Karjalainen 41 76 7.2.2003 Suunnitteludokumentti 14.2.2003 Määrittelydokumentti 6
Ajanjakso: 17.2.2003-2.3.2003 Matti Koskimies 37 106 Miika Hartikainen 37 108 Mikko Hämäläinen 38 116 Ville Karjalainen 36 112 Siirrettiin FTR:ää viikolla. Ajanjakso: 3.3.2003-16.3.2003 Matti Koskimies 39 145 Miika Hartikainen 21 135 Mikko Hämäläinen 38 154 Ville Karjalainen 52 172 11.3.2003 Toteutus 14.3.2003 Suunnitteludokumentti Ajanjakso: 17.3.2003-30.3.2003 Matti Koskimies 33 178 Miika Hartikainen 53 188 Mikko Hämäläinen 39 193 Ville Karjalainen 59 231 7
Matti Koskimies poissa välillä 26.-29.3. Ajanjakso: 31.3.2003-13.4.2003 Matti Koskimies 46 224 Miika Hartikainen 39 227 Mikko Hämäläinen 55 248 Ville Karjalainen 84 315 Ajanjakso: 14.4.2003-27.4.2003 Matti Koskimies 41 265 Miika Hartikainen 32 259 Mikko Hämäläinen 43 291 Ville Karjalainen 55 370 22.4.2003 Toteutusdokumentti 22.4.2003 Testaus 8