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 Sovelluksen kuvaukset alkavat valmistua Lähes lopullinen (paitsi työlistat) Enemmän vaihdosta PHP-kieleen./SL Lisätty henkilökohtainen osa./sl Lisätty hlokoht osat hannalle ja sannalle./sl Sampon hlokoht osio valmis./sl

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 sannan henkilökoihtainen ajatuksenvirta Sampo Lehtinen kurssin aluku jossittelua ryhmäkoon vaikutuksista ohjelmiston tuottamisen sietämätön vaikeus Mitä tapahtui, miksi. Opinko mitään Mitä jatkossa Kiitokset hannan henkilökoihtainen ajatuksenvirta Seppo Syrjänen Omat kokemukset Projektityön ongelmista Jälkisanat 10 7 Työtunnit (liitteeksi) 11

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 Yleisenä huomiona sovelluksen koodia ja rakennetta voisi refaktoroida siistimmäksi. Nykyiselläänkin se on kuitenkin varsin hyvin ylläpidettävää ja laajennettavaa 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 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.

5 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 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

6 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 /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.

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

8 5 Henkilökohtaiset kokemukset sannan henkilökoihtainen ajatuksenvirta 5.2 Sampo Lehtinen VAROITUS: Seuraava teksti on suht summittaista ajatuksen virtaa. Siitä ei välttämättä muodostu lukijalle järjellistä kokonaisuutta, mutta sen kirjoittaminen puhdisti mukavasti mieltä. Vuodatus noudattelee jotakinkin tuntemuksia projektin ajalta hieman aikajärjestystä muistuttavana ajatuksen virtana. Otsikot on ympätty pötkönä kirjoitettuun tuubaan jälkikäteen kurssin aluku Halusin projektipäälliköksi. Jälkikäteen arvioituna ihan liiaksi. Mikäli projektia olisi toteutettu oikeina töinä oikeassa firmassa ja olisin ollut vastuussa ryhmän henkilöresurssoinnista, olisin antanut ensimmäisenä kenkää itselleni. Varsinkin, jos ryhmä olisi ollut suurempi, potkujen antaminen itselleni olisi ollut helpompaa. Olin yksinkertaisesti järjestänyt itselleni liiaksi tekemistä ehtiäkseni ja jaksaakseni hoitaa hommaa kunnolla jossittelua ryhmäkoon vaikutuksista Suurempi ryhmä on kuitenkin jossittelua. Voi olla, että projektia olisi viety eteenpäin toisella tavalla, mikäli ryhmä olisi ollut suurempi, voi olla, että oikea päivätyö ja ohjelmistotuotantoprojektin suorittaminen eivät olisi törmänneet niin pahasti. Koen henkilökohtaisesti suhteellisen pahaksi miinukseksi sen, että en saanut projektisuunnitelmaa valmiiksi ajallaan. Mikäli projektiryhmä olisi ollut suurempi, tästä olisi aiheutunut todella pahoja ongelmia ohjelmiston tuottamisen sietämätön vaikeus Ohjelmiston tuottaminen tuntui alkukesästä vaikealta, suorastaan mahdottomalta. Syksyä kohti helpotti, sillä sovin kahteen otteeseen päivätyöhön käytettävän ajan lyhentämisestä (kiitokset joustavuudesta Helsingin yliopiston opiskelijarekisterille). Pahimmillaan tilanne oli hieman ennen lomaa, lomani aikana ja kaksi loman jälkeistä viikkoa. Tällä ajanjaksolla en jaksanut, pystynyt tai yksinkertaisesti kyennyt tekemään projektille käytännössä katsoen tuntiakaan kokouksissa käymistä lukuunottamatta. Ajanjakson kahdella viimeisellä viikolla kokouksia ei järjestetty ja kaksi viikkoa tätä ennen olin niistä pois. Tässä vaiheessa myös tuntikirjanpito meni ketuiksi. Onnistuin hävittämään osan tunneista jonnekin. Onnistuin myös olemaan kirjaamatta tunteja kirjanpitojärjestelmään sekä tilanteen parannuttua olemaan kirjaamatta tunteja kunnolla ylös.

9 Myös graafisen itsenäisen javasovelluksen suunnittelu ja varsinkin teknisen puolen miettiminen tuntui raskaalta taakalta. Kellään ryhmästä ei ollut vähäistäkään kokemusta graafisten käyttöliittymien ohjelmoinnista. Graafisen käyttöliittymän toteutus olisi hyvinkin saattanut onnistua, jos aikaa olisi ollut rutkasti enemmän tai ryhmässä edes yksi, jolla olisi ollut kokemusta riittävästi auttaakseen muut alkuun. Uuden, tämän kaltaisen asian oppiminen ei sinäällään todennäköisesti ole vaikeaa, onhan graafisen käyttöliittymän ohjelmointia luonnehdittu helpoksi. Käytännössä pitäisi kuitenkin osata perusteet voidakseen oppia itse lisää. Kynnys tyhjästä aloittaessa on liian suuri. Eikä asiaa opeteta laitoksella. Noh sama suutarin lapsilla ei ole varpaita ongelma näkyy tietokantasovellus-kurssin kohdalla. Kahden tunnin tekniikkaluento ei riitä. Ohjlemoinnin harjoitustyössä vaaditaan testaukselta lausekattavuutta, mutta ei kerrota koodin instrumentoinnista tai muustakaan, millä kattavuutta voisi mitata. Liioin testausta ei ole opetettu juuri yhtään harjoitustyön suorittamiseen mennessä. Koska laitoksella vaaditaan ties minkä asian osaamista opettamatta, on tietorakenteiden harjoitustyö näistä helpoin. Siinä ei tarvitse osata mitään, minkä perusteita ei olisi opetettu. Tietokannoista kyllä opetetaan perusteet, mutta ei perusteita tietokantasovelluksen tekemisen välineistä Mitä tapahtui, miksi. Opinko mitään Kysymys siitä, miksi näin kävi, on suurempi kuin kysymys miksi näin kävi ohjelmistotuotantoprojektin kohdalla. Projektin suorittaminen on ollut hyödyllistä. Suurimmat hyödyt tästä tuntuvat tällä hetkellä olevan kolme yksittäistä seikkaa. Opin, että jonkinmoista koodia pystyy sisuksistaan oksentamaan myös välineillä, joita ei tunne, ja että tämän kaltainen tekeminen opettaa välineen (tässä tapauksessa PHP-kielen) käyttöä suhteellisen nopeasti. Mielestäni parhaiten tämä tulee esin verratessa ensimmäistä projektiin tekemääni osaa viimeiseen. lukujarjestys.php on se ensimmäinen ja sahkoposti.php on se viimeinen. Toki sähköpostista huolehtiva osuus on kaiken kaikkiaan yksinkertaisempi, mutta mielestäni myös laatu on parantunut eikä vain tehtävän yksinkertaistumisen vuoksi. Toteutusympäristön vaihdos olisi pitänyt tehdä aiemmin, mutta ryhmä uskoi liiaksi mahdollisuuksiinsa selvitä. Projektin puitteissa, vaikka kehitysmalli pitkälti jotain keveää prosessia muistuttikin, ei valitettavasti ollut aikaa refaktoroida tuotoksiaan. Tuntuu siltä, että tässä vaiheessa lukujarjestys.php ei ehkä syntyisi sinäällään helpommin, mutta siitä tulisi kauniimpi. Muuttujia ei väliteltäisi miten sattuu jne. Yleisemmällä tasolla tarkoitan tällä sitä, että saan aikaan asioita, jos ei muuten, niin väkisin yrittämällä. Toivon oppivani tästä olemaan antamatta periksi asioiden tuntuessa vaikealta. En tosin tiedä, miten olisi käynyt, mikäli hommaa olisi yritetty loppuun asti väkertää Javalla itsenäiseksi sovellukseksi. Javalla sinäällään olisi koodista todennäköisesti tullut laadukkaampaa, mutta muu projektiryhmä valitsi kieleksi PHP:n projektipäälliköltä kysymättä. Tulipahan sitten opittua sekin kieli ja että sillä voi tehdä

10 asioita myös kauniisti. Suurin osa PHP:llä toteutettuja juttuja lienee kuitenkin rumia, sillä kielellä saa aikaan asioita ymmärtämättä mitä oikeasti tekee. Tavoitteiden asettaminen. Asettamalla liian kovat tavoitteet ja liian paljon tekemistä kalenteriin, tulee varmistaneeksi, ettei ainakaan kaikkea ehdi tehdä laadukkasti.vaikka tekemistä olisi liiaksi, se helpottaa, kun järjestää mahdollisuuden keskittyä kerrallaan yhteen asiaan. Tämä ei tällä kerralla projektin alkutaipaleella onnistunut. Kongnitiivinen dissonanssi sen suhteen, mitä pitäisi tehdä, vaikeutti asioihin keskittymistä ja paneutumista. Lisäksi aloittaminen tuntui vaikealta, kun taakkaa oli liiaksi. Kun tehtävät kilpailevat ajasta, seuraa helposti näivettyminen. Tässä olisi paikka sille kolmannelle, se ei tule mieleen tätä kirjoittaessa. Tuskin se lopullisesti on unohtunut, mutta jää dokumentoimatta. Miten mielstäni ohtuprojektin saisi suoritettua parhaiten. Otetaan kymmenen viikon jakso. Käytetään näistä viisi. Tutustutetaan ryhmä toisilleen ensimmäisen viikon iltoina, valitaan tehtävät ja päästetään heput kotiin kolmeksi viikoksi. Testausvastaava harsii tuona aikana testaussuunnitelmaa itseksiin, projektipäällikkö omaa suunnitelmaansa, koodista vastaava koodaustandardia jne. Tuotokset annetaan muille nähtäviksi. Kolmen viikon kuluttua projekti hoidetaan loppuun siten, että kaikki ovat paikalla 5/7 klo Järjestelyn voisi kuvitella sopivan täysipäiväisesti töissä käyville. Näin ei tarvitsisi yrittää jakaa niukkaa resurssia ja jaksamista kahden, usein tärkeän asian, eli töiden ja ohtuprojektin välillä Mitä jatkossa Palkitsen itseni tästä raatamisesta päivittämällä b-luokan ajokorttini ab-luokan ajokortiksi Kiitokset Haluan kiittää kaikkia projektiin osallistuneita. Tuntuu jopa vähän herkältä kirjoittaa näin; ihan kuin pitäisi Oscar-gaalan kiitospuhetta. Hyvää jatkoa kaikille. 5.3 hannan henkilökoihtainen ajatuksenvirta 5.4 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. Ryhmän piennennyttyä porukkamme alkoi olla tosin aika tukalan pieni.

11 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 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

12 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... ;-) 9

13 6 Jälkisanat 10 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ä, 17 taikakarkkia, 1 kokoillan elokuva nimeltä Sahara, sekä polkupyörän rengasraudat.

14 7 Työtunnit (liitteeksi) 11