Desmond-opiskelijakalenteri Loppuraportti

Transkriptio

1 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

2 Versio Päivämäärä Kommentti Tekijä Loppukokouksen Mikko Hämäläinen pohjalta tehty versio

3 Sisältö 1 Johdanto 1 2 Työnkulku Projektisuunnitelma Määrittely Suunnittelu Toteutus Testaus Toteutettu ohjelmisto 4 4 Opittua 5

4 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

5 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

6 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

7 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 fyysistä riviä ja 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

8 control: 224 2% data: % db: % ui: % taglib: % JSP-sivut: % Yhteensä: % 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

9 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: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Projektisuunnitelma Määrittelydokumentti Käyttöliittymän suunnittelu Projektisuunnitelma Ajanjakso: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Suunnitteludokumentti Määrittelydokumentti 6

10 Ajanjakso: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Siirrettiin FTR:ää viikolla. Ajanjakso: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Toteutus Suunnitteludokumentti Ajanjakso: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen

11 Matti Koskimies poissa välillä Ajanjakso: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Ajanjakso: Matti Koskimies Miika Hartikainen Mikko Hämäläinen Ville Karjalainen Toteutusdokumentti Testaus 8