Loppuraportti Sahara-ryhmä Helsinki 1.9.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Sanna Keskioja Sampo Lehtinen Hanna Liedenpohja Seppo Syrjänen Asiakas Joni Salmi Johtoryhmä Juha Taina Kimmo Simola Kotisivu http://www.cs.helsinki.fi/group/sahara Versiohistoria Versio Päiväys Tehdyt muutokset 0.11 25.8.2005 Ensimmäinen parannettu versio./ss 0.3 31.8.2005 Sovelluksen kuvaukset alkavat valmistua. 0.4 31.8.2005 Lähes lopullinen (paitsi työlistat) 0.5 1.9.2005 Lähes lopullinen (paitsi työlistat) sisältäen enemmän vaihdosta PHP-kieleen./
Sisältö i 1 Johdanto 1 2 Sovellus 1 2.1 Sovelluksen synty.............................. 1 2.2 Sovelluksen kehittäminen.......................... 1 2.2.1 Tunnettujen vikojen lista...................... 1 2.2.2 Toiminnallisuus........................... 1 2.2.3 Käyttöliittymä........................... 2 2.2.4 Tietokanta.............................. 2 3 Projektityöskentely 2 4 Käytetyt työkalut 3 5 Henkilökohtaiset kokemukset 5 5.1 Sampo Lehtinen............................... 5 5.2 Seppo Syrjänen............................... 5 5.2.1 Omat kokemukset......................... 5 5.2.2 Projektityön ongelmista...................... 6 6 Jälkisanat 7 7 Työtunnit (liitteeksi) 8
1 Johdanto 1 Tämä dokumentti kertoo Sahara-ohjelmistotuotantoprojektin (kesä 2005) keräämät kokemukset. Dokumentin alussa kuvataan Tanja-järjestelmän tunnetut viat ja tunnetut ominaisuudet, jotka olisi hyvä jatkossa korjata tai muuttaa paremmin toimiviksi. 2 Sovellus 2.1 Sovelluksen synty Tanja-sovellus syntyi varsin nopealla aikataululla lähes XP-hengessä pari- ja ryhmätyöskentelynä. Kun yhdellä tuli ongelmia, toiset pystyivät auttamaan. Olemme lopputulokseen tyytyväisiä seuraavassa luvussa esitettyjä suhteellisen triviaaleja parannusehdotuksia lukuunottamatta. Projektin loppuvaiheessa päätimme mielestämme viisaasti olla lisäämättä tai jopa korjaamatta alla mainittuja asioita, jotta saamme tärkeämmät asiat ajoissa hyvälle mallille. 2.2 Sovelluksen kehittäminen Yleisenä huomiona sovelluksen koodia ja rakennetta voisi refaktoroida siistimmäksi. Nykyiselläänkin se on kuitenkin varsin hyvin ylläpidettävää ja laajennettavaa. 2.2.1 Tunnettujen vikojen lista Kutsuja voi vaihtaa osallistujana olevan toisen kutsujan tietoja Järjestelmä käyttää yhtä käyttäjätaulua, jossa tietty sähköpostiosoite on vain yhden kerran. Tästä on se seuraus, että ryhmän kutsuja voi muuttaa osallistujana olevan sähköpostiosoitteen tietoja (nimet, sähköpostiosoite) silloinkin kun ko. osoite on myös kutsujana. Saman sähköpostiosoitteen esiintymistä eri rooleissa on selkeytettävä kun järjestelmää kehitetään hajautetun sopivuuksien syöttämisen suuntaan. 2.2.2 Toiminnallisuus Osallistujat itse antamaan sopivuutensa (ns. versio 2). aikataulu.php paremmin osaksi sovelluksen normaalilogiikkaa (toimintojen siirto yleiset.php-moduuliin). Nykytoteutuksella isot aikataulun laskentamoduulit ladataan mukaan vain tarvittaessa. Näin pienissä sovelluksissa tällaista asiaa ei kuitenkaan tarvitsisi optimoida näin pitkälle.
2 2.2.3 Käyttöliittymä Tarjottujen aikojen ja sopivuuksien muistaminen käyttöliittymässä niin, että niitä ei poisteta tietokannasta kun sivu luodaan. Nykyinen käytäntö estää hyödyllisten triggereiden toteuttamisen. Viikkojakson valinta (kuukausi)kalenterista. Hiukan intuitiivisempi aikataulujen muokkaus. JavaScriptillä voisi korostaa muokkauksen kannalta sopivia sarakkeita, kun hiiri tuodaan taulukon soluun. Osallistujaluetteloon merkintä, jos osallistujalle ei ole annettu sopivuuksia. Mahdollisuus merkata sopivuusnäytöllä kerralla kaikki tarjotut ajat tietyllä sopivuusarvolla. Tämä tukisi osallistujia, joilla esimerkiksi suurin osa ajoista sopii hyvin ja muutama huonosti. 2.2.4 Tietokanta Tietokantaan cascade-triggerit tietojen poistoon (sovellus vähän yksinkertaistuisi). Monipuolisemmat triggerit viimkaytto-kentän päivittämiseen, kunhan käyttöliittymä osaa asettaa tarjottuja aikoja ja sopivuuksia poistamatta niitä kaikkia aluksi. Vanhojen tietojen poiston parempi ohjeistaminen/automatisointi. Tähän on prototyökalu asennus/poista-vanhentuneet.sh, josta voisi muokata tarvittavat SQL-lauseet ajettavaksi esim. silloin kun käyttäjä loggaa ulos. aikataulut.php:n funktiossa varaaaika() ajetaan konepellin alta ($tk->conn->exec()) SQL-lause, jolla poistetaan osallistujan edelliset varaukset annetut-taulukossa. Asia olisi kauniimpi tehdä hakemalla annetut-taulu sopimuksen mukaan ja siivota kohdalle osuvat ko. käyttäjän varaukset. Toinen vaihtoehto on laajentaa tietokantataulujen apumoduulia sisältämään jotain vastaavaa. 3 Projektityöskentely Projektiryhmä Sahara koottiin Ohjelmistotuotantoprojekti -kurssia kesäksi 2005 suorittamaan ilmoittautuneista opiskelijoista. Emme tiedä, millä perustein kurssille osallistujat eri ryhmiin sijoitettiin. Tässä sijoittelussa Sahara-ryhmään osui hieman vanhempaa ja työelämää nähnyttä porukkaa. Projektityöskentely oli mukavaa ja sujui hyvin, vaikka matkalle joitain mutkia mahtuikin. Ryhmässä oli alun perin viisi jäsentä, mutta yksi joutui valitettavasti keskeyttämään jo varsin aikaisessa vaiheessa. Neljän hengen ryhmä tuntui hieman pieneltä tämän kokoisen projektin läpi saattamiseen. Projektiryhmän pienuus ei olisi ehkä haitannut, mikäli alusta
lähtien tavoitteet olisi asetettu vähemmän kunnianhimoisesti. Suoriutumista eivät myöskään helpottaneet projektipäällikköä kesällä vaivanneet asennevammat. Kaiken kaikkiaan lähtökohdat huomioiden työskentely sujui hyvin. Ryhmän kesken päätettiin pitää kaksi kokousta viikossa. Maanantain kokouksessa tarkasteltiin rutiinin omaisesti riskien toteutumista ja listattiin viisi uhkaavinta riskiä sekä tarkasteltiin projektin etenemistä suhteessa löysästi suunniteltuun, lähinnä mielissä siintäneeseen aikatauluun. Käyttöliittymän suunnittelu jäi pääasiassa Hannan ja Sannan harteille, Seppo vastasi tietokannan käytöstä ja sisällöstä sekä aikataulujen laskentapuolesta. Hanna toteutti alkuperäisen PHP-kielellä tehdyn sovelluksen sivustorungon sekä tapahtumakäsittelijät, joihin varsinainen toiminnallisuus sitten kirjoitettiin. Vaikka prosessimallina oli vesiputous, muodostui projektin toteutus lähinnä keveitä malleja muistuttavaksi. Johtuen toteutuskielestä ei perinteistä yksikkötestausta toteutettu täydessä laajuudessaan. Toisaalta, koska toteutusta ei lähdetty tekemään yksittäisistä osista, jotka myöhemmin integroitaisiin, toteutettava sovellus oli käytännössä jatkuvasti toimintakuntoinen ja suhteellisen virheetön jo toteutettujen ominaisuuksien ja toiminnallisuuksien osalta. Koodia pidettiin kaikkien yhteisenä vaikka yksittäisen tiedoston tai toiminnallisuuden parissa työskentelikin kerrallaan yleensä vain yksi projektiryhmän jäsen. Toteutettavan sovelluksen alkuperäinen määrittely olisi mahdollistanut kätevästi myös iteratiivisen kahdessa osassa sovelluksen toteuttamiseen tähtäävän mallin käyttämisen. 3 4 Käytetyt työkalut Saimme tarvittavat työkalut suhteellisen helposti käyttöömme, joskus vimmatulla googlettamisella, joskus suoraan laitoksen ohjeita seuraten. LaTeXin kanssa tappelimme säännöllisesti, mutta olimme siihen kuitenkin koko ajan tyytyväisiä. Kuvat olivat kyllä painajainen. OpenOfficen EPS-vienti tuotti puutteellisia kuvia (fontit vinossa, viivoja tai elementtejä puuttui). Useiden tuntien taistelun jälkeen kuvat tehtiin lopulta sivun http://vv.cs.byu.edu/~jones/blog/archives/ 2003/09/importing\_power.html ohjeiden mukaan asentamalla Windows-koneeseen tiedostoon tulostava virtuaalinen PS-tulostin, jonka asetuksista valittiin tulostusmuodoksi EPS. Tämän jälkeen kuvat olivat kunnossa. Ratkaisua voi (varauksin) suositella muillekin. Olisimme kaivannneet käyttöön LaTeX-paketteja, joilla kuvat olisivat voineet olla PDF-muodossa, mutta ohtu- ja tiki-pohjat käyttivät vain EPS-kykyisiä työkaluja. Ehkä temppu ei olisi ollut vaikea, mutta LaTeX-dokumetteja työstettiin myös erilaisilla Perl-scripteillä: esim. vaatimuslistoja pidettiin omissa määrämuotoisissa tiedostoissaan, joista scriptillä tehtiin halutut tex-tiedostot Makefileen avulla. Makefileen lisättiin myös toiminto make www, joka julkaisi dokumentin päiväkohtaisen vedoksen sekä versionumeron avulla nimetyn vedoksen pdfmuodossa projektin kotisivulla. Tällä tavalla dokumentteja pystyi työstämään pelkän sshyhteyden ja www-selaimen varassa (ilman X-ympäristöä). Käytetty Makefile on mukana dokumenttihakemistossa.
CVS osoittautui pidetyksi ja hyödylliseksi tavaksi tehdä asioita ryhmätyönä. Sen aikakoneominaisuuksia päästiin käyttämäänkin kerran, kun viimeiset koodimuutokset rikkoivat liian monta vanhaa asiaa ja testausryhmä halusi alleen toimivan sovelluksen. Projektin alkuvaiheissa graafisen Java-sovelluksen tekoon suunniteltiin Eclipsen Visual Editor -kehitintä, mutta se oli niin iso möhkäle, että protosovellukset koodatiin käsin. UML-kaavioita tehtiin Poseidon-ohjelmalla. Kuvat tehtiin PowerPointilla tai OpenOfficella. PHP-kielen rajoittuneisuus näkyi hyvin jo näinkin pienessä projektissa. Olisimme alkuvaiheessa kaivanneet tulkilta tiukempia varoituksia ja virheilmoituksia (jotka sitten kyllä saimme esille). Ripeästä alusta olisi kannattanut laittaa päivä hiukan parempien debug- ja lokitustyökalujen tekemiseen. Kokonaisuutena koodaus pysyi kuitenkin hyvin käsissä. Tietokannan selailuun ja muokkaukseen käytimme Sepon tekemää dbtesti.php-työkalua (ei ole Tanjan jakelussa mukana), jolla kannan tauluja pystyi muokkaamaan WWW-selaimella. Ryhmän kokemukset yksikkötestauksesta ja siihen tehtyjen testaustyökalujen käytöstä olivat varsin pienet. Kokemattomuus yksikkötestien tekemisestä ja testausluennon myöhäinen ajankohta luultavasti aiheuttivats sen, että koodista tuli käytännössä vaikeastitestattavaa eikä yksikkötestien tekeminen jälkikäteen onnistunut. PHP-kielellä toteutettujen ohjelmapalasten yksikkötestaukseen löytyi työkalu, joka olisi sinäällän kelvannut käytettäväksi, mikäli koodi olisi muutamaa poikkeusta lukuunottamatta soveltunut näin testattavaksi. Nyt koodissa on muutama yksikkötestattavaksi soveltuva poikkeus, jotka vahvistavat säännön yksikkötestaukseen sopimattomuudesta. Toteutusympäristön vaihtaminen graafisesta oikeasta itsenäisestä sovelluksesta www-ympäristössä toimivaan ja samalla toteutuskielen vaihtaminen Javasta PHP-kieleen tapahtui vasta niinkin myöhään kuin 2.8. Toteutus käynnistyi tämän jälkeen välittömästi. Käyttöliittymäsuunnitelma toimi hyvin näistä toteutukseen liittyvistä vaihdoksista huolimatta. Toisaalta, miksi se ei olisi toiminut, olihan se tehty sinäällään ympäristöstä riippumattomaksi. Alkuun näytti, että käyttöliittymään muodostuisi pienehköjä synkronointiongelmia, mutta näistä hankkiuduttiin lopulta eroon laittamalla kaikki tiedot yhteen HTML-lomakkeeseen ja kertomalla piilotetuissa parametreissa, mille kaikille tapahtumakäsittelijöille kaikki parametrit oli välitettävä tallennusta varten. Toteutusta olisi helpottanut koodistandardin suunnittelu ja käyttäminen. Ilman tätä ohjeistusta jokainen kirjoitti koodinsa miten kirjoitti. Tästä johtuen tiedostot ovat sisennetty miten mistäkin kohdasta, muuttujien nimentä on sitä sun tätä, eikä toteutuskieli ainakaan helpota näitä ongelmia kokemattomien käyttäjien käsissä. Java-kielisen toteutuksen kirjoittamiseen oli ajateltu käytettäväksi Eclipse-nimistä integroitua kehitysympäristöä. Vaihdettuamme PHP:hen, emme kuitenkaan nopeasti löytäneet korvaavaa tuotetta, joka olisi huolehtinut sisennyksistä, lohkojen aloittamisesta jne. automaattisesti puolestamme. 4
5 Henkilökohtaiset kokemukset 5 5.1 Sampo Lehtinen Tänne tulee jotain sepustusta. 5.2 Seppo Syrjänen 5.2.1 Omat kokemukset Olin pois aivan ensimmäisestä tapaamisesta, koska minut siirrettiin rinnakkaisryhmästä (Aija) Saharaan. Pääsin kuitenkin hyvin porukkaan ja projektiin mukaan ja huomasin olevani tekemässä mukavassa seurassa mielenkiintoista ohjelmistoa. Ryhmän piennennyttyä porukkamme alkoi olla tosin aika tukalan pieni. Halusin oppia projektin aikana mahdollisimman paljon kaikenlaista hyödyllistä tai ainakin mielenkiintoista (Javan käyttö suuremmissa sovelluksissa, graafisten käyttöliittymien teko Javalla, Eclipse, CVS, LaTEX jne.) Etenkin kiinnostus graafisen käyttöliittymien tekoon sai minut ajamaan projektia kyseiseen suuntaan, näin jälkiviisaasti, turhan pitkään ja turhan kunnianhimoisesti. Onneksi Hanna nosti kissan pöydälle ja päädyimme tekemään Tanjaa PHP-versiona. Tarkoitushan oli oppia ohjelmistotuotantoprojektityöskentelyä eikä XML-RPC-ohjelmointia... Elokuun koodausviikot olivat projektin kannalta iloista ja onnellista aikaa: vihdoinkin pääsimme tekemään jotain "oikeaa"ja ohjelmistomme eteni huimaa vauhtia. Kahdessa viikossa suurin osa perustyöstä oli tehty ja jäljellä oli "vain"toinen mokoma käytettävyyden parantamista ja testausta. Pari- ja ryhmätyöskentely kakkoskerroksen käytävämikroilla oli hyvin toimiva tapa saada asioita eteenpäin. Henkilökohtaisesti hauskinta oli XML-RPCprotojen teko, Munkres-Kuhn-algoritmin porttaus Javasta PHP:ksi sekä PostgreSQL:n hienompien ominaisuuksien (triggerit jne.) opettelu. Myös kaikenlaisten apuvälineiden (perl-scriptit LaTeX-dokumenttien teossa, tietokannan selailutyökalu) virittäminen olivat hommia, joissa tunsi todella auttavansa projektia eteenpäin isolla vaihteella. Projektissa työskentelemisen mielekkyys aaltoili etenemisen tahtiin: suunnittelun takkuillessa pahasti heinäkuussa selvän etenemissuunnan puuttuessa oli motivaatiokin pohjalukemissa. Onneksi muu ryhmä osasi kammeta mukaan. Lopettaminen ei sinänsä olisi tullut kuuloonkaan; projektille oli tullut uhrattua jo niin monta hienoa kesäpäivää. Vastoinkäymisistä huolimatta projektin henki oli koko ajan hyvä ja osallistujien inhimillisiä puolia ymmärrettiin. Parhaimmillaan homma on ollut todella hauskaa ja meno hervotonta. Vastapainoksi toki itse kukin sai istua koneella yömyöhään vääntämässä dokumentteja tai koodia, yksin tai porukassa.
6 5.2.2 Projektityön ongelmista Projektin tuottamien dokumenttien suhteen olimme melkein koko ajan miten tämä tulisi tehtyä hyvin? -moodissa: koimme turhauttavaksi sen, että dokumenteista ei ollut tarjolla virallisia tai edes hyväksi koettuja esimerkkejä, vaan saimme tehdä kaiken miten halusimme. Tämä olisi ollut varmasti palkitsevampaa, jos edes jollakulla meistä olisi ollut selvä visio tai käytännön kokemusta toimivasta projektidokumentoinnista. Mutta koska olimme kaikki liikkeellä koulupohjalta, emme olleet täysin tyytyväisiä mihinkään tuotokseemme. Hiukan samankaltaisia tuntemuksia koimme itse toteutuksen suhteen: projektiryhmät ovat vapaita maalaamaan itsensä nurkkaan valitsemalla tai suostumalla sellaisten tekniikoiden käyttöön tai sellaisten vaatimusten toteuttamiseen, joista he eivät millään voi kokemattomuuttaan selvitä. Meille kävi näin ajauduttuamme toteuttamaan todella hienoa graafista käyttöliittymää porukalla, jolla ei ollut siitä aikaisempaa kokemusta eikä mahdollisuuksia/resursseja (vain neljä henkeä, joista vain kolme riittävän ohjelmointitaitoista). Tekniikanvaihto tutumpaan sai projektin päättymään onnellisesti, mutta tällöinkin hyödynnettiin laajalti projektilaisten muualla hankkimaa osaamista. Laitoksen kurssien tiedoilla tällä porukalla homma olisi kyllä jäänyt tekemättä. Tässä olikin ehkä projektimme suurin dilemma: olimme kaikki valmiita opettelemaan paljon uutta, mutta valitsemallamme tiellä opeteltavien asioiden määrä olisi ylittänyt käytettävissä olevat resurssit. Asiantilan huomaaminen vei aikansa. Normaalitilanteessa todellisessa elämässä kumpaakaan edellä esitetyistä ongelmista ei juurikaan esiinny, vaan sekä hyväksi koetut toimintamallit että tekniset reunaehdot saadaan valmiina projektin ulkopuolelta yrityksen tietotaidon tai edellisten projektien kautta. Jos ohtuprojektien tarkoituksena on opettaa ohjelmistotuotantoprojekteissa toimimista, tuntuu em. matalan tason (dokumenttihallinnollisten ja etenkin teknisten) asioiden kanssa painiskelu suhteellisen tehottomasti käytetyltä ajalta. Yleisenä yliopistollisena oppimistapahtumana ja opinnäytetyönä projektin saldo jää onneksi reilusti plussalle. Ainakin meikäläinen tulee muistamaan tämän Saharassa vietetyn kesän yhtenä opiskelu-urani hienoimmista kokemuksista. Sahara opettaa, sanotaan silti meilläpäin nykyään... ;-)
6 Jälkisanat 7 Sahara-ohjelmistotuotantoprojektin toteuttamiseen tarvittiin: Alla Sepon luvut, plussatkaa omanne... (vai haluaako joku tehdä tästä taulukon?) 10 kuppia lattea (koska Physicumin kahvila oli kiinni kesän!), 25 kuppia kahvia (maidolla ja kanelilla), 10 kuppia kahvia (maidolla), 3 kuppia kahvia (raakana), X kuppia teetä, 6 Frezza Mochaa, 6 pullaa, 2 viineriä, 3 kakunpalaa (porkkana-, aito-sacher-, vadelmakakkuja), 20 suklaapatukkaa (pääasiassa Dove), 7 karkkipussia, 11 olutta, 5 siideriä, 1/4 pulloa viskiä, 1 kokoillan elokuva nimeltä Sahara, sekä polkupyörän rengasraudat.
7 Työtunnit (liitteeksi) 8