Loppuraportti. Sahara-ryhmä. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Transkriptio

1 Loppuraportti Sahara-ryhmä Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 Kurssi Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Sanna Keskioja Sampo Lehtinen Hanna Liedenpohja Seppo Syrjänen Asiakas Joni Salmi Johtoryhmä Juha Taina Kimmo Simola Kotisivu Versiohistoria Versio Päiväys Tehdyt muutokset Ensimmäinen parannettu versio./ss

3 Sisältö i 1 Johdanto 1 2 Sovellus Sovelluksen synty Sovelluksen kehittäminen Tunnettujen vikojen lista Toiminnallisuus Käyttöliittymä Tietokanta Projektityöskentely 2 4 Käytetyt työkalut 3 5 Henkilökohtaiset kokemukset Sampo Lehtinen Seppo Syrjänen Omat kokemukset Projektin ongelmat Jälkisanat 7 7 Työtunnit (liiteeksi) 8

4 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 Sovelluksen koodi olisi hyvä refaktoroida siistimmäksi Tunnettujen vikojen lista Sähköpostiosoitteen uniikkius muutosten ja rekisteröitymisten yhteydessä Sisäänkirjautumistunnuksena käytetty sähköpostiosoite ei välttämättä säily uniikkina. Saman sähköpostiosoitteen aktivoiminen useampaan kertaan on mahdollista aloittamalla useita rekisteröitymisiä tai sähköpostin vaihtamisia ja vahvistamalla useita näin aikaan saatuja varmistuksia. Testauksessa ei otettu selvää, miten toteutettu ohjelmisto toimii tällaisessa tapauksessa. Todennäköisesti sisäänkirjautuminen onnistuu sillä salasanalla ja käyttäjällä, jonka kanta sattuu palauttamaan ensimmäisenä. Myöskään unohtuneen salasanan tilaamista ei tällaisella tapauksella testattu. Ratkaisuehdotukset: Uuden sähköpostiosoitteeen vertailu aktivoitujen lisäksi aktivointia odottaviin Muiden aktivointia odottavien samojen sähköpostiosoitteiden aktivoinnin estäminen yhden aktivoituessa Aktivoinnin estäminen, mikäli sama osoite on jo aktivoituna Sähköpostiosoite kantaan uniikiksi (estäisi tosin useammat sähköpostiosoitteettomat osallistujat)

5 Toiminnallisuus Osallistujat itse antamaan sopivuutensa (ns. versio 2). aikataulu.php paremmin osaksi sovelluksen normaalilogiikkaa (toimintojen siirto yleisest.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 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 parempi aikataulujen muokkaus. 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 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. 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

6 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 integroitaisi, 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 /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. 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 vedoksen pdf-muodossa projektin kotisivulla (sekä versioidun pdf-tiedoston työhakemistossa). Tällä tavalla dokumetteja pystyi työstämään pelkän ssh-yhteyden ja selaimen varassa (ilman X-ympäristöä). Käytetty Makefile on mukana dokumenttihakemistossa.

7 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. Graafisen Java-sovelluksen tekoon suunniteltiin Eclipsen Visual Editor -kehitintä, mutta se oli niin iso möhkäle, että protosovellukset koodatiin käsin. Ajatukset yksikkötesteistä. Vaihtaminen php hen. Koodaustandardin (sisennykset, nimentä jne.) ja kokemuksen puuttuminen. 4

8 5 Henkilökohtaiset kokemukset Sampo Lehtinen Tänne tulee jotain sepustusta. 5.2 Seppo Syrjänen 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. Rakelin lopetettua terveydellisistä syistä 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"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-RPC-protojen 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 testivaiheessa käytettyn selailutyökalu) virittäminen olivat hommia, joissa tunsi todella auttavansa projektia eteenpäin. 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.

9 Projektin ongelmat 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. Sahara opettaa, sanotaan silti meilläpäin nykyään... ;-)

10 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.

11 7 Työtunnit (liiteeksi) 8