Nero

Loppuraportti

Versio 1.0

16.12.2004

Ohjelmistotuotantoprojekti Nero

Helsingin yliopisto

Tietojenkäsittelytieteen laitos

Sisällys

Versiohistoria	2

Alkusanat	2

Projektiryhmä ja vastuualueet	2

Ensivaikutelma ja projektin käynnistäminen	3

Projektisuunnitelman teko	4

Vaatimusmäärittely	5

Tekninen suunnittelu	7

Toteutus	9

Testaus	10

Dokumentointi	11

Loppusanat	12

Versiohistoria

Päivämäärä	Versio	Tekijät	Muutokset
15.12.04	0.9	kaikki	Omat tekstit toimitettu sähköpostilla Osmalle
16.12.04	1.0	Osma Suominen	Dokumentti koottu yhteen

Alkusanat

Nero oli Helsingin yliopiston Tietojenkäsittelytieteen laitoksen syksyn 2004 ohjelmistotuotantoprojekti, jonka tavoitteena oli tehdä sovellus kiinteistön tilojen hallintaan laitoksen hallintohenkilöstön käyttöön. Nero jatkoi siitä, mihin edellisen kesän Rooma-projekti jäi. Lisävaatimuksena Roomaan nähden oli se, että sovelluksen käyttöliittymän piti perustua Exactum-rakennuksen pohjapiirrokseen.

Projektiryhmä ja vastuualueet

Johannes Kuusela (projektipäällikkö)

Jyrki Muukkonen (testaus)

Teemu Sjöblom (tekninen suunnittelu)

Ville Sundberg (vaatimusmäärittely)

Osma Suominen (mittaus)

Timi Tuohenmaa (tekninen toteutus)

Ensivaikutelma ja projektin käynnistäminen

Timi: Keväällä projektivaihtoehtoja katsellessani mietin, että eikös täällä ole yhtään kiinnostavaa aihetta. Johonkin ilmoittauduin kuitenkin, mutta kesän päättyessä sain kuin taivaan lahjana mailiin Juha Tainan postin, jossa tarjottiin lisävaihtoehtoja. Huoneidenhallintajärjestelmä kuulosti oikeasti kiinnostavalta.

Ensimmäisellä tapaamisella tuli hyvä tunne siitä, että projektista saattaa tullakin jotain. Jokainen ryhmän jäsen tuntui sellaiselta, että näiden kanssa pystyy tekemään töitäkin.

Valitettavasti itse projektin pohja oli aikalailla sekavaa möhjää. Näytti siltä, että asiakkaat olisivat olleet tyytyväisiä ihan mihin tahansa oikeasti toimivaan järjestelmään, kun samaa projektia oli kuuleman mukaan yrittetty jo kolmesti aikaisemmin laihoin tuloksin.

Hilpeintä oli saada pohjaksi kesän projekti nimeltä Rooma, joka ei sitten toiminut juuri ollenkaan. Asiakas halusi saada sen korjatuksi ja poltimme (tai lähinnä Teemu poltti) aikaa korjaamiseen tolkuttomasti ja kaikki nämä tunnit menivät hukkaan, koska jouduimme toteamaan Rooman olevan polttokunnossa.

Jonttu: Aloitin projektin vähän pelokkain mielin, sillä en oikein tiennyt mitä odottaa. Kaverini, joka oli kurssin käynyt, kertoi työmäärän olevan ”kauhea”, joten olin hieman peloissani.

Otin projektipäällikön tehtävän lähinnä koska kukaan muu ei sitä halunnut ja halusin olla alusta asti mahdollisimman solidaarinen. Tämä osoittautui hyväksi valinnaksi, sillä onnistuin mielestäni melko hyvin tässä tehtävässä.

Ville: Projektin aihe oli kiinnostava itseni ja luullakseni myös kaikkien muiden mielestä. Olinkin todella tyytyväinen, ettei tarvinnut lähteä alkuperäiseen aihevaihtoehtooni (taksikeskusalgoritmit). Ryhmämme tuntui alusta alkaen erittäin hyvältä kokonaisuudelta, sillä teknistä osaamista oli ryhmän sisällä riittävästi eikä henkilökemioissa ollut mitään ongelmia. Rooma vaikutti siltä, että sen korjaaminen saattaisi olla helppokin juttu... joopajoo

Teemu: Projektin alku ei ollut mitenkään ihmeellinen omalta osaltani. Olin luottavainen omaan osaamiseeni. Luotin myös siihen, ettei kurssi olisi raskas siksi, että joutuisi opiskelemaan paljon uutta asiaa. Aloituskokouksessa asiakas ei voinut demota Roomaa ja sen tilannetta, minkä seurauksena itselleni jäi pidemmäksi ajaksi epäselväksi se, mikä päälle ja mitä ollaan rakentamassa.

Osma: Projektin käynnistäminen sujui jähmeästi, tuntui että kaikki ryhmäläiset olivat enemmän tai vähemmän pihalla. Osittain tämä johtui tehtävänannon epämääräisyydestä. Kesti aikansa tajuta mikä on Rooma, miten meidän pitäisi/kannattaisi siihen suhtautua ja minkälaisia odotuksia meihin kohdistuu.

Jyrki: Syksy 2004 oli suurinpiirtein viimeinen mahdollisuus käydä ohtuprojekti, kun varsinaisen kurssin suorituksesta oli jo aikaa. Kaikki annetut aiheet tuntuivat olevan hieman turhia, ja olin sitä mieltä ettei tämä kurssi mitenkään liity tutkintooni. Onneksi kuitenkin perustettiin tämä uusi ryhmä, ja kerkesin sähköpostikisassa kuuden ensimmäisen joukkoon. Ehkä tästä sittenkin vielä tulisi kiva kurssi.

Projektissa tuotettavalla softalla oli selvästi joku merkitys. Samaa ei välttämättä voi sanoa kaikista aiheista. Oli lisäksi mukavaa päästä ryhmään jossa oli osaavaa porukkaa ja jonkin verran tuttuja naamojakin. Aihealue oli selkeästi määritelty, mutta lukuisten edellisten samaa aihetta käsitelleiden projektien jonkinasteinen epäonnistuminen hieman pelotti. Voiko tällaista softaa ikinä saada valmiiksi tällaisen kurssin puitteissa?

Projektisuunnitelman teko

Jonttu: Heti projektin alettua sain tehtäväkseni projektisuunnitelman laatimisen. Olin melko hukassa ja kopioin suuren osan dokumentin rakenteesta aikaisemmilta projektiryhmiltä. Suunnitelmasta tuli samansuuntainen kuin tällä kurssilla yleensäkin; melkoinen raakile.

Jyrki: Projektin alku oli pienoista paikallaan juoksemista, tai oikeastaan konttaamista. Edellisen ryhmän tuotos, Rooma, ei toiminutkaan, joten kesti kauan hahmottaa mistä tässä varsinaisesti on kyse, ja miten Rooma oikeastaan toimii. Onneksi dokumentaatiota kahlaamalla sai aika hyvän yleiskäsityksen ohjelmistosta, vaikkakin lähes kaikki yksityiskohdat jäivät hämärän peittoon.

Teemu: Projektisuunnitelman eteen en muista tehneeni paljoakaan, ainuaksi tuotokseski taisi jäädä suunnitteluvaiheen alustavat tuntiaikataulut tms.. Tässä vaiheessa Viulu-projekti käynnistyi ja Roomaan tutustuminen sekä sen korjaaminen vei tuntuvasti tuntejani. Haluan mainita sen, että Rooma tuli kuntoon, sen asentaminen laitoksen ympäristöön ei onnistunutkaan ja sitten peli puhallettiin poikki. (Kyllä mä vielä oisin sen db:n selättänyt!).

Timi: Tässä vaiheessa ei muista kovin hyvin projektisuunnitelman teosta mitään muuta kuin sen, että päivämäärien säätäminen tuntui kovin mahdottomalta. Siitä huolimatta, että päivämäärät olivat silkkaa arpapeliä jota ohjaaja vähän yritti tukea järkevään suuntaan, saimme loppujen lopuksi jokseenkin järkevän pituiset aikarajat. Sen sijaan tuntimäärät eri työvaiheille ja varsinkin työvaiheiden sisälle taisivat heittää härän pyllyä.

Osma: Projektisuunnitelman tekemisestä jäi sellainen olo, että sen tarkoitus oli kerrata ohtu-kurssilla opittua, mutta juuri mitään yhteyttä käsillä olevaan projektiin sillä ei ollut. Luulen että mitään vahinkoa ei olisi tapahtunut, vaikka projektisuunnitelma olisi lopuksi vaihdettu päittäin jonkin toisen ryhmän kanssa. Tämä kuvastaa kurssin kahtalaista luonnetta: yhtäältä opetellaan projektien vetämistä, toisaalta yritetään saada jotain aikaan. Prosun kohdalla toteutui näistä korkeintaan ensimmäinen. Jos tarkoituksena olisi vain ja ainoastaan saada toimiva (ja hyvin testattu ja dokumentoitu jne) ohjelmisto aikaan, voisi ihan hyvin antaa kaikille ryhmille saman projektisuunnitelman rungon johon korkeintaan täytetään muutama yksityiskohta luukkuihin. Mitään järjellistä, erityisesti tähän projektiin liittyvää sanottavaa ei ainakaan tällä ryhmällä ollut prosun sisältöön, paitsi ohtu-kurssilla opittujen asioiden toistoa ja mieleen palauttamista.

Vaatimusmäärittely

Osma: Vaatimusanalyysissä alkoi juju valjeta. Ryhmä elätteli pitkään toiveita, että Rooman tuotosta voisi hyödyntää laajemminkin, ja että pääsisimme varsin vähällä työllä. Pala palalta tästä haaveesta kuitenkin luovuttii, kun huomattiin Rooman suunnittelun ja koodin ongelmat. Ihmeen paljon varsinkin Teemun aikaa uppoutui Rooman korjauksiin. Tajusimme, että asiakkaan näkökulmasta Rooman korjaaminen saattaisi tuntua fiksummalta kuin oman ohjelmiston tekeminen, koska jälkimmäisessä tapauksessa vaarana olisi taas kerran epäonnistua ja saada tuloksena käyttökelvoton sovellus. Tilanteen ratkaisi kaiketi lopullisesti se, että saimme aikaan uuden vision siitä, mitä kiinteistönhallintasovellus voisi olla ja miltä se voisi näyttää. Tätä kun oli riittävästi kehitelty, ei paluuta Roomaan enää ollut. Toisaalta Rooma-ryhmän tekemästä analyysista ja erityisesti sen pohjalta tehdystä tietokannasta oli meille selkeästi hyötyä: Rooma-ryhmän dokumenteista käy ilmi, että heille työpiste-varaus-henkilö -problematiikka aiheutti paljon väärinymmärryksiä ja päänvaivaa, mutta heidän työnsä pohjalta meillä oli käytettävissä selkeä tapa jäsentää käsitteet.

Jyrki: Määrittelyvaiheen kanssa samanaikaisesti Roomaa yritettiin saada henkiin, jotta nähtäisiin mitä sen osia voidaan käyttää projektimme päätavoitteessa, graafisen karttanäkymän lisäämisessä ohjelmistoon. Vaikka ohjelmisto saatiinkin toimimaan erillisessä tomcat-ympäristössä, ei se kuitenkaan toiminut laitoksella. Rooman bugeja löytyi lisää. Jossain vaiheessa niihin keskittyi aliprojekti Viulu, joka kuopattiin myöhemmin todettuamme ettei Rooman koodissa ole meidän ohjelmamme kannalta mitään käyttökelpoista.

Määrittelyvaiheessa ravasimme myös aika usein asiakkaiden luona, ja kyselimme varmaankin vähän liikaakin samoja asioita, sekä detaileja jotka olisi voinut kaivaa myös Rooman dokumenttien syövereistä. Usein asiakkaiden vastaukset olivat myös melko ympäripyöreitä. Saimme kaivettua kuitenkin irti tarpeeksi tarkat vaatimukset.

Teemu: Vaatimusanalyysin aikaan Viulu oli myös menossa ja siihen meni iso osa tunneistani. Muut tunnit käytin tapaamisiin joissa keskusteltiin projektista yleensä, sen termistöstä ja suuremman linjan suunnitelmista. Jälkeenpäin sanoneena voisi todeta, että käytimme vaatimusanalyysin tekemiseen ehkä hiukan liikaa aikaa. Osaltaan tähän vaikutti varmasti se, että resurssit eivät olleet täydessä käytössä. Aikaisemman ryhmän tuotoksia olisi pitänyt käyttää hyväksi aikaisemmin. Toisaalta tässä vaiheessa tehtiin suuren linjan suunnitelmia, jotka myös veivät aikaa, Esimerkiksi käyttöliittymän suunnittelu ja hiukan toteutustakin jo.

Jonttu: Vaatimusanalyysille varattiin aikaa lopulta enemmän kuin olin siihen alunperin projektisuunnitelmassa halunnut. Tämä osoittautui jälkeenpäin virheeksi mutta ei suuremmin haitannut projektia. Olin määrittelyvaiheessa melko aktiivinen ja mielestäni vaihe onnistui erittäin hyvin, ollen toteutuksen jälkeen onnistunein vaihe koko projektissa. Tämä vaihe oli hyvin opettavainen, erityisesti se opetti että asiakkaalta ei saa haluamaansa tietoa ellei sitä osaa kysyä.

Timi: Vaatimusmäärittelyä voisi jälkikäteen pitää kaikkein hyödyllisimpänä vaiheena (tietenkin toteutuksen jälkeen). Tässä vaiheessa päädyimme varsin runsaan keskustelun päätteeksi toteuttaa projekti Java-ohjelmana, eikä weppikilkkeenä. Moinen päätös ei tähän vaiheeseen toki kuulunut, mutta se antoi meille paremmat eväät käyttöliittymän suunnittelulle. Asiakkaita vainosimme aika paljon. Asiakkaamme olivat avuliaita ja patistivat tulemaan kyselemään asiota. Onnellisia tuntuivat kyllä olevan, kun pääsimme vaiheesta ohi emmekä enää käyneet paikan päällä.

Saimme paljon hyvää materiaalia ja käyttötapauksia joiden pohjalta ohjelmaa oli hyvä alkaa suunnitella.

Ville: Asiakkaiden taustoista johtuen keskustelu asiakkaan kanssa oli suhteellisen helppoa (vs. ei-atk-tietämystä asiakkaat). Koska kyseessä oli jatkoprojekti, oli suhde vaatimuksiin kutakuinkin omituinen; mitä kopioida Roomalta ja mitä kalastella itse? Vaatimusmäärittely onnistui mielestäni kuitenkin kohtalaisesti, vaikkakin aikaa kului liikaa (muistaakseni osittain myös Rooman korjailun takia). Jossain vaiheessa oli puhetta, että asiakkaan luona olisi tullut liian vähän käytyä, mutta mielestäni siellä käytiin tarpeeksi usein. Joitakin tapaamisia olisi tosin ehdottomasti pitänyt valmistella huolellisemmin, jotta tapaamisista olisi aina saatu kaikki hyöty irti. Rooman kanssa kikkailuun meni liikaa aikaa, mutta toisaalta aluksi kaikki vaikutti olevan "lähes" kunnossa. Eli oikeastaan täysin rationaalista toimintaa. Sovellukseen päätyminen oli erittäin hyvä ratkaisu projektin kannalta, kuten myös SVG + batik yhdistelmän
käyttöönotto.

Tekninen suunnittelu

Jyrki: Suunnitteluvaiheessa Rooma poltettiin lopullisesti tuhkaksi. Oma ohjelmistomme olisi graafinen Java-sovellus, eikä www:ssä pyörivä servlet/jsp-viritelmä. Tämä mahdollisti intuitiivisemman käyttöliittymän suunnittelun, sekä villejä visioita ties mistä. Sekä ohjelman ulkoasu että sisäinen rakenne hahmottuivat pikkuhiljaa kohti lopullista versiota, eikä oikeastaan missään vaiheessa tehty mitään erittäin huonoa, toteutuskelvotonta ratkaisua.

Jossain vaiheessa huomattiin suunnitteluvaiheen vievän liikaa aikaa, ja päätettiin lopettaa yksityiskohtien hiominen. Joitakin asioita ei saatu sovittua tarpeeksi yksityiskohtaisesti, mutta ratkaisu lopettaa suunnitteluvaihe oli mielestäni oikea ratkaisu.

Timi: Tässä vaiheessa lähdimme muistaakseni aika pitkälle Osman näkemyksin liikkeelle ja päädyimme kolmikerroksiseen arkitehtuuriin, jossa pohjalla pidettiin tietokantapalikkaa ja sen päällä oli sessio-luokka, jonka läpi kaikki kommunikointi tapahtui. Päälimmäisenä oli käyttöliittymä, jonka suunnittelu jäi melkein piirustustasolle. Vaikka suunnitteluvaihe näyttää dokumentoinnin pohjalta suorastaan heppoiselta, niin mietimme paljon asioita etukäteen ja tiesimme melko hyvin miten edetä. Totetusdokkari jyrättiin kokouksessa läpi, jotta aikataulu pitäisi ja meille jäisi riittävästi aikaa toteutukseen. Ja hyvä niin...

Teemu: Suunnitteluvaiheessa mielestäni eniten ongelmia tuotti projektiryhmän tuntien vähyys. Liioitellen voisi sanoa, että yksi viikko meni siten, että samat tehtävät jaettiin uusiksi.

Suunnitteluvaiheen deadlineä jouduttiin siirtämään viikolla aiottua myöhäisemmäksi, siirtäminen oli pakollinen teko, jotta saimme aikaiseksi kootun dokumentin. Suunnitteludokumentti olisi kaivannut vielä paljon lisää työtä. Merkittävää mielestäni on kuitenkin se, että ryhmämme kaikille jäsenille tuli selkeä kuva siitä mitä ollaan tekemässä ja miten se tehdään, vaikkei sitä paperille saatu. Tämä varmasti auttoi toteutusvaiheessa ja oli osaltansa monien suunnittelua koskeneiden ryhmäkeskutelujemme seurausta.

Osma: Suunnittelu oli isoista vaiheista varmaankin kaoottisin. Vaatimusanalyysissä oli vielä mahdollista esittää suuria ideoita ja maalailla taivaanrantaa ottamatta juuri kantaa teknisiin yksityiskohtiin, mutta suunnittelussa pudottiin harmilliseen välitilaan, jossa visioiden toteutuskelpoisuus ja -tavat pitäisi lyödä lukkoon, mutta kukaan ei oikeastaan tiennyt tarkalleen miten se kannattaisi tehdä (kokemusta tarvittavasta tekniikasta oli heikonlaisesti) eikä koodauskaan juuri ollut vaihtoehto. Tuloksena oli “vähän sinne päin” -suunnitelma jossa isoja osia oli jätetty vain ylimalkaisen kuvailun varaan. Jos suunnitelmaa vertaa lopputulokseen, niin paljon ominaisuuksia ja yksityiskohtia yksinkertaisest sivuutettiin suunnittelussa. Toisaalta suunnittelussa aikaansaatu runko ja perusratkaisut osoittautuivat myöhemmin varsin toimiviksi. Jälkikäteen voisi todeta, että suunnittelussa olisi kannattanutkin pyrkiä vain rungon rakentamiseen, koska ajan käyttäminen yksityiskohtaiseen viilailuun olisi tuhlausta. Näin käytännössä tapahtuikin, mutta päätös olisi voinut olla selkeämpi ja sen olisi voinut sanoa ääneen jo ennen FTR:ää.

Ville: Suunnitteluvaiheelle varatun/jääneen ajan puitteissa ei olisi pitänyt lähteä kasaamaan niin isoa dokumenttia, vaan olisi ehkä pitänyt alusta asti tyytyä kompaktimpaan esitykseen ja jättää turhat proosat pois. Suunnitteluvaihe onnistui kuitenkin tärkeimmässä tehtävässään hyvin eli vaiheen jälkeen ryhmällä oli yhtenäinen käsitys siitä mitä ollaan lähdössä toteuttamaan.

Jonttu: Suunnitteluvaiheelle varattiin lopulta paljon vähemmän aikaa kuin oli tarkoitus (kts. edellinen kohta). Vaikka tämän johdosta suunnittelu jäi melko vaillinaiseksi paperilla, se oli todellisuudessa tehty suhteellisen hyvin ja ryhmällä oli hyvä käsitys siitä mitä olemme tekemässä toteutusvaiheessa. Myös tämä vaihe oli opettavainen, erityisesti opin ettei suunnitelma ole välttämättä osiensa summa.

Toteutus

Osma: Toteutusvaiheessa ei juuri tuijoteltu suunnitteludokumentteja vaan jatkettiin käytännössä samaa prosessia, mutta hiukan konkreettisemmin. Yleensä kai heikko suunnittelu johtaa ongelmiin toteutuksessa, mutta minusta ongelmia tuli yllättävän vähän. Rajapintojen määrittelyt eivät paukkuneet kovin usein eikä pahoja väärinymmärryksiä sattunut. Loppuvaiheessa toteutus meni jo aika reippaasti ohi suunnitelmien sekä vesiputousmallin periaatteiden ja toimi ehkä pikemminkin open source -maailman “scratch a developer's personal itch” -periaatteen mukaan: jos jotakuta ärsytti ohjelman puutteellisuus jossakin asiassa, hän yleensä otti asiakseen korjata tilanteen. Työnjako valui luonnostaan sellaiseksi, että eri ihmisillä oli omat yksityiset osa-alueensa, kuten minulla kartta. Uskoisin että siistimpää koodia olisi saatu aikaan, jos oltaisiin käytetty XP-mäisempää “koodi ei ole kenenkään omaa” -työnjakoa, jossa arvioidaan ja refaktoroidaan jatkuvasti muiden kirjoittamaa koodia, mutta tämä olisi vaatinut myös aivan toisenlaisia työskentelytapoja eli vähemmän henkilökohtaisia nakkeja ja enemmän ryhmätyötä.

Jyrki: Toteutusvaiheen alussa kaikki olivat innoissaan, pääsihän nyt vihdoin tekemään jotain konkreettista. Osa-alueiden jako oli melko onnistunut: kukin teki sitä minkä parhaiten osasi, ja kaikille riitti jotain näperreltävää. Testausvastaavana on todettava, että testien tekeminen jäi alkuvaiheesta pois, vaikka se oli siihen suunniteltu. Tämä lähinnä sen takia, että testaus valitettavasti olisi se asia josta karsittaisiin mahdollisten aikataulukiireiden vuoksi.

Kun käyttöliittymän osat ja varsinainen sovelluslogiikka lopulta liimattiin toisiinsa kiinni, toimivat ne yllättävän saumattomasti toistensa kanssa. Suunnittelu ei siis ollut täysi susi, vaikkakin pientä API-viilailua tarvittiin. Lopussa aikaa ilmestyi (tai sitä tehtiin väkisin) myös testeille. Suunnitelmat DbUnit-testien tekemisestä tietokantakomponenteille kuitenkin kariutui erinäisiin kehitysympäristön asettamiin rajoituksiin. Muilta osin testit olivat lopulta melko kattavia ja sekä yksikkötestauksen että loppuvaiheessa tehdyn järjestelmätestauksen avulla kerettiin korjaamaan ne muutamat inhottavat, "jonkun" tekemät bugit. Yöllä ne siihen ilmestyi...

Timi: Pääsimme toteutusvaiheeseen likimain ajallaan. Ilokseni huomasin, että jokainen porukassa oli kykeneväinen ohjelmoimaan melko hyvin ja hommia pystyttiin jakamaan aika mukavasti. Kuvittelin etukäteen, että voisin yrittää jotenkin johtaa tätä vaihetta ja panostamaan enemmänkin lankojen pitelemiseen ja dokumentoinnin tekemiseen, mutta ohjaaja lynkkasi dokkareiden aloittamisen ja tuntui, että vapaaehtoisia riitti koodatessa, joten istahdin puuhailemaan sitä mitä muutkin. Minulle ei varsinaisesti jäänyt mitään osa-aluetta käteen, mutta tein kaikkea irtoroipetta sinne tänne melko paljon ja korjailin pieniä vikoja.

Homma toimi mielestäni loistavasti. Ja lopputulos puhuu puolestaan.

Ville: Parhaat koodaajat tekivät vaikeimpia asioita, mikä takasi sen, että tuloksena oli hyvä kokonaisuus. Suunnitteluvaiheen onnistuminen näkyi myös siinä, että kokonaisuuteen oli kohtalaisen helppo liittää palikoita. Rajapintoja jouduttiin toteutuksessa tosin muokkaamaan, mutta sehän on ihan yleistä.

Teemu: Toteutusvaiheesta tuli projektin onnistunein vaihe, porukka innostui tekemään tunteja ja homma saatiin hienosti kasaan, mikä yllättävintä, toteutuksessa ei missään vaiheessa tullut ongelmia tai väärinkäsityksiä vastaan. Vaikka eri henkilöt tekivät eri osia yhteenliittämisen jälkeen ne toimivat yhdessä moitteettomasti, uskomatonta!

Jonttu: Nero-projektin onnistunein osuus. Koodia tuotettiin tasaisen tappavaa tahtia, eikä missään menty vikaan. Tuotokset toimivat lähes poikkeuksetta kuin junan vessa. Poikkeuksen tähän muodostivat omat tuotokseni, mistä olen hieman pettynyt. Kaiken kaikkiaan olen enemmän kuin tyytyväinen, koska tekemämme ohjelma on mielestäni todella upea.

Testaus

Timi: Saimme projektin valmiiksi siinä määrin ajoissa, että ehdimme testailla ohjelmaa aika paljon. Varsinaiset JUnit-testit olivat hyvin pitkälle Jyrkin käsialaa (niitä kyllä kirjoitettiin jo toteutuksen alussa, mutta tuppasivat unohtumaan, kun oikea ohjelmointi oli niin mukavaa puuhaa). Jyrki teki hyvää jälkeä ja testausraportti näyttää melko hyvältä ja ennen kaikkea virheettömältä.

Teemu: Toteutuksen jälkeen omat tuntini projektin osalta alkoivat olla täynnä, niinpä en testauksessa suoranaisesti tehnyt mitään, ainut testaukseni liittyi toteutusvaiheeseen jossa testasin tekemääni käyttöliittymäosuutta ja metodeja toeutuksen yhteydessä.

Jonttu: Testaus varsinaisena työvaiheena jäi hieman häilyväksi käsitteeksi, sillä testausta tehtiin toteutusvaiheen aikana lähes jatkuvasti. Yksikkötestaus saatiin hoidettua hyvin ja integraatiotestauskin koko lailla tyydyttävästi.

Osma: Testaus jäi aika nimelliseksi. Alussa puhutut ylevät periaatteet – yksikkötestien kirjoitus ja ylläpito, jatkuva testaus jne. jäivät ainakin minun osaltani toteutumatta. Käytännössä Jyrki hoiti melkeinpä yksinään koko yksikkötestauksen ja sen vähän integraatio- ja järjestelmätestauksen mitä tehtiin. Ohjelman rakenne oli testauksen kannalta ehkä hiukan keskivertoa hankalampi: suurin osa tärkeästä koodista oli joko käyttöliittymä- tai tietokantaosissa, joille on vaikeaa tai hyvin työlästä tehdä testejä. Ohtu-projekteissa perinteisesti testaus on jäänyt aika heikoille kantimille. Tässä suhteessa ryhmämme tuskin oli muita huonompi. Jos testaukseen tosissaan haluttaisiin panostaa, pitäisi siitä saada käytännön kokemusta jo esimerkiksi aiempien harjoitustöiden yhteydessä – on aika paljon vaadittu opetella projektin puitteissa kokonaan uusia menetelmiä ja niihin liittyviä periaatteita. Toki ohtu-kurssilla käsiteltiin hieman testausta, mutta käsittely jäi aika teoreettiseksi.

Ville: Jyrkin suuren työpanoksen ansiosta Neroa on testattu yllättävänkin paljon
(ohtu-projektiksi) ja hyvä niin, sillä virheitäkin löytyi.

Dokumentointi

Teemu: Toteutusdokumentin tekeminen jäi itselläni vähiin käytettävissä olevan ajan puutteen vuoksi ja suoranaisen väsymisen, softa oli toimiva ja asiakkaalla. Toteutusdokumentointiin olisi saanut vielä uhrattua uskomattomasti tunteja, mikäli sen olisi halunnut tehdä täydelliseti loppuun saakka.

Jonttu: Dokumenttien taso oli melko ailahteleva, kuten näissä projekteissa ilmeisesti on tapana. Onnistunein dokumentti oli mielestäni määrittelydokumentti, mutta kaikki muutkin olivat täysin tyydyttäviä olosuhteisiin nähden.

Timi: Tässä onkin projektin akilleen kantapää. Dokumentit eivät varsinaisesti ole kovin hyviä ja niiden pohjalta projektin teknisestä puolesta ei hirveämmin voi sanoa mitään. Tietoa oli kaikkien päässä, mutta paperille sitä ei osattu hirveän hyvin laittaa. Koska ryhmä oli kuitenkin hyvin yhtenäinen ja irc:ssä kommunikointi runsasta, niin saimme tiedon kulkemaan sulavasti ja heikompi dokumentointi ei päässyt häiritsemään projektia.

Loppusanat

Jyrki: Kaikenkaikkiaan projekti sujui hyvin, vaikkei alussa kaikille riittänytkään oikein tekemistä. Jossain määrin kuuden hengen ryhmä on siis mielestäni liian iso. Ryhmä sulautui hyvin kasaan, ja tunnelma oli leppoisa. Missään vaiheessa ei ollut mitään kauheata paniikkia, ja kaikki vaiheet vietiin tarpeeksi hyvin läpi että lopputulokseksi saatiin toimiva ja tarpeeksi viimeistelty softa. Pientä viilaamista tietenkin aina jää, mutta on selvää ettei näin lyhyen kurssin aikana voida jäädä hiomaan jokaista yksityiskohtaa loppuun asti. Kurssi oli lopulta paljon mukavampi kuin etukäteismielikuvani antoivat olettaa. Tämä luultavasti johtui siitä että projektiryhmästä löytyi tarpeeksi osaamista ja aihepiirinä oli oikean softan tuottaminen oikeaan käyttöön.

Osma: Kokonaisuutena sanoisin, että projekti oli projektina melko hyvin onnistunut ja tällä hetkellä olen sitä mieltä, että tekemämme sovellus onnistui erinomaisesti; dokumentaation laatu ei ole yhtä hyvä. Projektin aikana myös opittiin kaikenlaista. Teknisellä puolella tutustuin SVG-grafiikkaan ja Batik-kirjastoon sekä opin käyttämään Eclipseä. Sanottakoon kuitenkin, että projektin jälkeen luultavasti palaan takaisin komentorivityökaluihin – ellen sitten joskus vielä hairahdu tekemään jotain Javalla. Minun kannaltani Eclipse on osittain toimivaa vastamyrkkyä Javan aiheuttamaan tuskaan. ;-)

Teemu: Projektisuunnitelmassa oli eritelty yksi merkittävä riski, “Väärät jätkät väärässä projektissa”, mielestäni asia oli juuri päinvastoin. Yksikään projektin vaihe ei sujunut niin hyvin kuin se voisi mennä, eikä yhdenkään tuotos ole paras mahdollinen. Mielestäni muuta ei voi odottaakkaan, kun ennen yhdessä työskentelemättömät ihmiset tekevät suhteessa aikaan ylimitoitettua projektia vielä siten, että tehtävät asiat tulisi oppia projektin aikana! Huolimatta prosessin “lipsumisesta” ja tuotosten keskeneräisyydestä merkittävää mielestäni on työn tulos, toimiva ohjelma jota asiakas voi käytää haluamaansa tarkoitukseen. Onnistuimme pitämään projektin osaset hyvin kasassa, oikeassa mittakaavassa ja järjestyksessä annettuihin resursseihin nähden.

Ville: Asiakkaalle annettiin ohjelma, joka (todennäköisesti ;) täyttää sille asetetut vaatimukset ja auttaa asiakasta jokapäiväisessä työskentelyssä. Ohtu-projektilta tämä on mielestäni loistava saavutus, ottaen huomioon projektiin käytettävän ajan (ja siitä saatavan palkan ;). Dokumenteissa olisi ollut varmaankin paljon toivomisen varaa, mutta niiden tekoon oli aika vaikeaa motivoitua.
Onnistumisen kannalta olennaisimmat asiat olivat:

oikeat jätkät oikeassa projektissa

valmis kanta ja kopiointiosajärjestelmä

svg + batik

kunniamaininta myös eclipselle

Timi: Mielestäni projekti onnistui yli odotusten. Vaatimusdokumentissa olevat kälisuunnitelmat näyttivät vähän liiankin hienoilta, kun niitä piirrettiin, enkä ollut aivan vakuuttunut niiden toteutumisesta. Lopputulos kuitenkin näyttää, että käyttöliittymä on kuin vaatimusdokumentin kuvan eriomaisen komea veli.

Hienointa on, ettei tässä tapauksessa voi edes käyttää sanontaa "Moni kakku päältä kaunis", kun ohjelma todella toimii ja hyvin.

Jonttu:
Tämä projekti oli kuin romanssi; se alkoi hitaasti ja siitä kasvoi jotain elämää suurempaa.

Sovelluslogiikan ohjelmointi on kuin kirjoittaisi tietosanakirjaa – käyttöliittymän kuin kirjottaisi runoja.

13

2004-12-15T22:19:04