Viimeksi päivitetty 2001-04-23 - Juha T. Vainio
1. Johdanto
2. Projektin eteneminen
3. Lopputulokset
4. Työmääräanalyysi
5. Jälkilaskelmat
6. Projektityöskentely
7. Kehitysnäkymät
8. Oppiminen
9. Kurssipalaute
Langattoman viestinnän tekninen kehitys on johtanut murrosvaiheeseen, jossa uudet teknologiat mahdollistavat muutoksen päätelaitteiden käyttökulttuurissa. Erityisen merkittäviä teknologioita ovat GPRS, joka mahdollistaa kohtuuhintaisen "always-connected" -yhteyden, sekä J2ME, joka mahdollistaa päätelaitteisiin dynaamisesti ladattavat sovellusohjelmistot. Nämä teknologiat yhdistäviä tuotteita odotetaan markkinoille jo vuonna 2001. Todennäköisesti päätelaitteet tulevat olemaan EPOC-puhelimia tai PDA-laitteita, joihin on integroitu GPRS-toiminnallisuus.
Projektin tavoitteena oli tuottaa ei-kaupallinen prototyyppi monen pelaajan seikkailupelialustasta, sekä alustan päälle rakennettu yksinkertainen peli. Alustan moninpeliprotokollan tuli olla optimoitu ohuisiin ja pitkiin langattomiin (GPRS) verkkoihin. Protokollan tuli toimia Client-Server -arkkitehtuurissa ja sen tuli käyttää UDP-protokollaa. Verkon kuormitus tuli minimoida ja toteutuksen tuli toipua kadonneista paketeista ja pitkistä tai vaihtelevista verkkoviiveistä.
Alustan esittelemiseksi tuli rakentaa yksinkertainen moninpeli.
Projekti on yleisesti ottaen edennyt täysin ajallaan, aikataulumuutoksia ei ole jälkikäteen tarvinnut tehdä, ja kaikki deadlinet on saavutettu kunnialla. Kaiken kaikkiaan voidaan sanoa, että kaikissa vaiheissa on etukäteen asetetut tavoitteet saavutettu.
Seuraavassa vaiheittaiset kuvaukset projektin etenemisestä.
Vaihe 1 oli kokonaisuuden kannalta projektiryhmältä huonoiten suoritettu vaihe. Kokematon projektipäällikkö ja suurehko ryhmä toivat hallinnallisia vaikeuksia, ja vaikka tavoitteet määrällisesti saavutettiinkin, laadullisesti jäi toivomisen varaa. Kolmen viikon suunnitteluvaihe meni äkkiä ja deadline tuli huomaamatta vastaan. Työmäärien arviointi oli huomattavan hankalaa ja lopputulos oli sen mukainen.
Vaihe 2 meni jo huomattavasti ensimmäistä vaihetta paremmin, vaikkei se valitettavasti kurssin arvostelussa näkynytkään. Ensimmäisen vaiheen puutteet saatiin suurelta osin korjattua ja toisen vaiheen tavoitteet lisäksi melko lailla hyvin saavutettiin. Dokumentaatioon jäi hieman epäselvyyksiä oikolukukäytännön laukeamisesta johtuen.
Tässä vaiheessa suurimpana ongelmana voidaan pitää ryhmän motivaatiota, joka alkoi rappeutua. Suunnittelua pidettiin turhana ja lähes kaikki halusivat jo kirjoittaa koodia. Tämä lienee suora seuraus projektiryhmän jäsenten taustasta ohjelmoijina, ei niinkään ohjelmistosuunnittelijoina. Projektipäälliköllä oli täysi työ saada ryhmä tekemään vaiheessa vaaditut tehtävät.
Kolmanteen vaiheeseen oli annettu aikaa kaksi viikkoa lisää edellisiin vaiheisiin verrattuna, mutta tehtävääkin oli paljon. Ryhmän jäsenten roolijako ja tehtävien resurssointi alkoi viimeinkin olla selkeää ja tällä olikin suuri merkitys vaiheen onnistumiselle. Tässä vaiheessa saatiin jo jotain konkreettista aikaan lopputuotetta ajatellen, nimittäin käyttöliittymän prototyyppi.
Edellisen vaiheen motivaatio-ongelmat helpottivat, vaikkeivät vielä kokonaan hävinneetkään. Tämä oli kuitenkin viimeinen vaihe, jossa pääpaino oli suunnittelussa, joten helpotusta oli luvassa.
Alustava testaussuunnitelma sai osakseen kritiikkiä sekä asiakkaalta, että kurssilta. Tämä oli toisaalta odotettavissakin, sillä kurssin tarjoama testaussuunnitelman pohja ei soveltunut juurikaan tarpeisiimme, vaan se jouduttiin kirjoittamaan uusiksi. Tämä, testauspäällikön kokemattomuus, ja testaussuunnitelman kirjoittamiseen kulunut suuri työmäärä aiheutti sen, että yksityiskohdat ja termit testaussuunnitelmassa jäivät hiomatta. Ongelma ei kuitenkaan ollut suuren suuri, sillä testausta tässä vaiheessa ei modulitestauksen lisäksi ollut tarvittu.
Vaihe 4 oli ensimmäinen täysin ongelmitta sujunut vaihe projektin aikana. Kaikilla oli mielekästä tehtävää riittävästi, motivaatio-ongelmat loistivat poissaolollaan, eikä kukaan lyyhistynyt liiallisen stressin alle, vaikka asetetut tavoitteet olivatkin erittäin kovat.
Asetetuista tavoitteista ainoa saavuttamatta jäänyt oli Monrovia-pelin käyttöliittymän täysi toimiminen Palm-kämmenmikrossa. Muuten kaikki tavoitteet, ja näin myös kaikki alunperin määritetyt lopullisen ohjelmiston ensisijaiset tavoitteet saavutettiin jo tässä vaiheessa.
Erikseen on vielä mainittava edellisessä vaiheessa erityistä kritiikkiä saanut testisuunnitelma, joka tässä vaiheessa oli aivan loistava ja sai ansaitsemiaan kehuja sekä kurssin, että asiakkaan puolelta.
Vaihe meni jälleen erinomaisesti, eikä ongelmia kohdattu. Käyttöliittymä saatiin toimimaan Palmissa hyvin. Testaus suoritettiin mallikkaasti ja peliin saatiin uusia ulottuvuuksia vihollisten ja lisätoimintojen muodossa.
Projektin viimeinen vaihe tuntui sujuvan jälleen nihkeämmin kuin edeltäjänsä. Ohjelmisto oli kutakuinkin valmiina, joten osalla ryhmän jäsenistä oli vaikeuksia löytää motivaatiota asioiden tekemiseen. Tehtävät olivat lisäksi erityyppisiä kuin mitä edellisissä vaiheissa oli totuttu resurssoimaan, joten resurssoinnissakin oli hieman vaikeuksia. Tehtävät saatiin kuitenkin kunnialla tehtyä, vaikkakin projektipäällikön mielenterveyden kustannuksella.
Ongelmalliseksi osoittautui opponenttiryhmän järjestelmä, joka vaati useiden tuntien valmistelun ja asennustyön ennenkuin testaukseen päästiin käsiksi. Opponentit kyllä tarjosivat testausmahdollisuutta työpaikallaan, mutta käytännössä tämä olisi ollut ns. napinpainallustestaus, jossa olisi suoritettu opponenttien ennalta tekemä testaussysteemi ja katsottu kuinka se toimii. Testausryhmän ambitiot olivat kuitenkin korkeammalla, joten oli rakennettava oma testausympäristö ja omat testiohjelmat.
Tässä kappaleessa käsitellään projektin alkuvaiheessa määriteltyjä tavoitteita ja projektissa saavutettuja tuloksia. Näitä analysoimalla selvitetään, kuinka hyvin projektiryhmä pääsi tavoitteisiinsa.
| # | Tavoite | Saavutettu | Kommentti |
|---|---|---|---|
| 1 | Järjestelmä on toteutettu Java-ohjelmointikielellä | Kyllä | Sekä käyttöliittymä, että palvelinohjelmisto on toteutettu käyttäen pelkästään Java-ohjelmointikieltä |
| 2 | Järjestelmä on asiakkaan mielestä demottavassa kunnossa | Kyllä | Asiakas on tuonut julki tyytyväisyytensä demotilaisuuksissa |
| 3 | Järjestelmän osana toteutettu peli on monen pelaajan vuoropohjainen seikkailupeli | Kyllä | Ei kommenttia |
| 4 | Suurimmat viiveet pelissä eivät ylitä 10 sekuntia | Ei tietoa | Epäselvä tapaus. Ks. kappale 3.3 |
| 5 | Pelin omaksumisen ja pelaamisen täytyy olla helppoa | Kyllä | Asiakkaan luona järjestetty testaus, jossa asia todettiin |
| 6 | Dokumentaatio on asiakkaan mielestä laadullisesti ja määrällisesti riittävää | Kyllä | Asiakas on tuonut ilmi tyytyväisyytensä dokumentointiin |
| 7 | Jos vaatimukset eivät täyty, täytyy syyt olla tarkasti dokumentoitu | Kyllä | Ei kommenttia |
| 8 | Peliä pitää pystyä pelaamaan yhtäaikaisesti vähintään 10 pelaajaa | Kyllä | Peliä on testattu 12 pelaajalla yhtäaikaisesti ja todettu toimivaksi |
| 9 | Pelin keskeinen idea liittyy karttapohjaisuuteen | Kyllä | Peli on karttapohjainen |
| 10 | Järjestelmä on toteutettu asiakkaan hyväksymillä resursseilla | Kyllä | Kaikki käytetyt resurssit ovat asiakkaan hyväksymiä |
Nämä on esitetty niiltä osin kuin ne puuttuvat edellisestä taulukosta.
| Vaatimus | Taso | Saavutettu | Kommentti |
|---|---|---|---|
| Palvelin hoitaa pelaajien välistä yhteyttä | Pakollinen | Kyllä | Järjestelmä on toteutettu siten, että pelaajien välillä ei ole suoria yhteyksiä |
| Yhteyden katkeaminen on huomattava ja osattava reagoida | Suotava | Kyllä | Yhteyden katkeaminen huomataan ja siihen reagoidaan |
| Palvelin ei liity itse peliin muuta kuin alustana | Suotava | Kyllä | Järjestelmä on toteutettu niin, että palvelimen päälle voi itse rakentaa haluamiaan pelejä |
| Käyttöliittymä on graafinen | Pakollinen | Kyllä | Ei kommenttia |
| Palmin asettamat rajoitukset on huomioitava | Pakollinen | Kyllä | Palmin ja Palmin ohjelmistojen rajoitukset on huomioitu |
| Pelissä voi liikkua | Pakollinen | Kyllä | Ei kommenttia |
| Peliin voi kirjoittautua sisään (henkilökohtaiset tiedot) | Suotava | Kyllä | Palvelin tunnistaa pelaajan käyttäjätunnuksesta ja salasanasta, jotka annetaan sisäänkirjoittautumisen yhteydessä |
| Peliä voi jatkaa, tiedot tallentuvat | Suotava | Kyllä | Palvelin tallentaa pelaajan tiedot tämän poistuessa tai yhteyden katketessa |
| Pelissä voi luoda hahmon | Suotava | Kyllä | Ylläpitäjä voi työkalulla lisätä ja poistaa hahmoja |
| Pelissä voi taistella | Suotava | Kyllä | Pelissä voi taistella sekä toisia pelaajia että tietokoneen ohjaamia vihollisia vastaan |
| Pelissä voi puhua muille pelaajille | Suotava | Kyllä | Ei kommenttia |
| Pelissä hahmo kehittyy | Lisäominaisuus | Kyllä | Pelissä hahmo saa lisää elinvoimaa, lihasvoimaa ja kestävyyttä taistellessaan voitokkaasti |
| Pelissä on esineitä | Lisäominaisuus | Ei | Pienen prioriteetin lisäominaisuus jätettiin pois suuremman prioriteetin tehtävien takia |
Eräänä tavoitteena oli, että epäluotettavan langattoman verkon yli pitäisi pystyä pelaamaan peliä, eivätkä viiveet tällöin ylitä 10 sekuntia.
Projektiryhmä ei onnistuneesti kyennyt toteamaan tämän tavoitteen saavuttamista, sillä vasta viimeisen vaiheen lopulla saadun GPRS-puhelimen testaus jäi vähäiseksi. Peli saatiin toimimaan, mutta joko verkon tai infrapunayhteyden (Palmin ja GPRS-puhelimen välillä) bufferoinnin takia viive kasvoi 10 sekunnin tietämille useammin kuin olisi haluttu.
Varmuudella voitaneen sanoa, että viive ei johdu Monrovia-ohjelmistosta, mutta tarkempi analyysi jouduttiin jättämään ajan loppuessa. Seuraavilla asioilla kuitenkin todennäköisesti saataisiin tulosta aikaan ja mahdollisesti systeemi toimimaan:
Projektin aikana saatiin ohjelmiston lisäksi aikaan seuraavat dokumentit:
Tässä kappaleessa käydään läpi projektiin käytettyjä tunteja tehtävien, henkilöiden ja tehtävälajien osalta.
| Tehtävä | Toteuma | Suunniteltu | Syy poikkeamaan |
|---|---|---|---|
| Luennot | 38 | 54 | Kaikki eivät katsoneet kaikkia luentoja tarpeellisiksi |
| UML-opettelu | 0 | 10 | Katsoimme UML:n käytön tässä projektin vaiheessa turhaksi |
| Projektisuunnitelman teon opiskelu | 8 | 6 | |
| MS Project -opiskelu | 4 | 5 | |
| Ryhmäpalaverit | 8 | 56 | Mahdollinen ajatusvirhe resurssoinnissa, mahdollisesti unohtuneita merkintöjä tuntiraportoinneissa |
| Asiakaspalaverit | 13 | 18 | |
| Projektin organisointi | 9 | 12 | |
| Asiakkaan toivomusten analysointi | 9 | 8 | |
| Vaatimusten järkevyyden pohdinta | 0 | 4 | Merkitty suoraan vaatimusmäärittelyn kirjoitukseen |
| Vaatimusmäärittelyn kirjoitus | 9 | 8 | |
| Aikataulun suunnittelu | 1 | 1 | |
| Tehtävien jako | 1 | 1 | |
| Menetelmien valinta | 2 | 8 | Osoittautui luultua helpommaksi |
| Riskisuunnitelma | 18 | 4 | Tehty laajempi ja parempi riskisuunnitelma kuin aluksi ajateltiin |
| Resurssointi | 2 | 4 | |
| Projektisuunnitelman kirjoitus | 9 | 8 | |
| Seuraavan vaiheen suunnittelu | 3 | 4 | |
| WWW-sivujen suunnittelu ja valmistus | 0 | 8 | Sivujen valmistus jätettiin tärkeämpien tehtävien tieltä |
| Tehtävä | Toteuma | Suunniteltu | Syy poikkeamaan |
|---|---|---|---|
| OP: Luennot | 34 | 42 | Kaikki eivät ehtineet kaikille luennoille |
| OP: Rational Rose | 12 | 28 | Rational Rosea eivät päässeet opiskelemaan kaikki halukkaat |
| OP: Palmin ominaisuudet | 0 | 4 | Koodaus jätettiin seuraavaan vaiheeseen, joten Palmin ominaisuuksiinkaan ei tarvinnut läheisemmin vielä tutustua |
| OP: Java | 0 | 5 | Koodaus jätettiin seuraavaan vaiheeseen, joten Javaa ei vielä tarvinnut erikseen opetella |
| Ryhmäpalaverit | 27 | 28 | |
| Asiakaspalaverit | 12 | 12 | |
| Toiminnallinen määrittely, palvelin | 12 | 16 | |
| Toiminnallinen määrittely, käyttöliittymä | 12 | 14 | |
| Toiminnallinen määrittely, protokolla | 3 | 9 | Protokollasta enemmän asiaa tekniseen määrittelyyn |
| Toiminnallinen määrittely, kirjoitus | 10 | 35 | Kirjoittajia oli vähemmän kuin oli suunniteltu |
| Tekninen määrittely, kaikki osa-alueet | 19 | 47 | Ks. yllä |
| WWW-sivujen päivitys | 9 | 10 | |
| Vanhojen dokumenttien päivitys | 10 | 4 | Vanhoissa dokumenteissa oli paljon enemmän päivitettävää kuin alun perin kuviteltiin |
| Seuraavan vaiheen suunnittelu | 5 | 4 |
| Tehtävä | Toteuma | Suunniteltu | Syy poikkeamaan |
|---|---|---|---|
| OP: Java | 27 | 16 | Java-taitoja piti elvyttää |
| Ryhmäpalaverit | 22 | 35 | Kaikki eivät päässeet kaikkiin palavereihin |
| Asiakaspalaverit | 10 | 12 | |
| Projektin organisointi | 3 | 5 | |
| Toiminnallisen määrittelyn päivitys | 4 | 13 | Toiminnallinen määrittely oli paremmassa kunnossa kuin arvioitiin |
| Protokollan signaloinnin suunnittelu | 9 | 10 | |
| Protokollan PDUiden suunnittelu | 14 | 10 | |
| Palvelimen ytimen suunnittelu | 6 | 10 | |
| Pelin käyttöliittymän suunnittelu | 10 | 7 | |
| PC- ja NPC-luokkien suunnittelu | 0 | 5 | Luokkien suunnittelusta päätetään myöhemmin |
| Teknisen määrittelyn kirjoitus | 19 | 13 | |
| Pelin käyttöliittymän koodaus | 14 | 5 | Koodaukseen käytettiin enemmän aikaa paremman lopputuloksen aikaansaamiseksi |
| Pelin alustan koodaus | 2 | 10 | Pelin alustaa ei tässä vaiheessa vielä tarvinnut sen kummemmin tehdä |
| Testaussuunnitelma | 11 | 5 | Testaussuunnitelmasta tehtiin hieman yksityiskohtaisempi kuin alun perin suunniteltiin |
| Burana-raporttien teko | 0 | 14 | Resurssoitu liikaa ja mahdollisesti jätetty merkitsemättä |
| Projektisuunnitelman muokkaus | 3 | 3 | |
| Dokumenttien oikoluku ja hiominen | 4 | 10 | Oikoluvussa vähemmän tekemistä kuin alunperin ajateltiin |
| Seuraavan vaiheen suunnittelu | 8 | 5 |
| Tehtävä | Toteuma | Suunniteltu | Syy poikkeamaan |
|---|---|---|---|
| OP: Java | 5 | 12 | Java-taitoja tuli elvytettyä jo edellisessä vaiheessa |
| OP: XML | 5 | 2 | XML oli luultua tuntemattomampaa |
| Ryhmäpalaverit | 37 | 49 | |
| Asiakaspalaverit | 6 | 20 | Asiakaspalavereihin osallistuvien henkilöiden määrää karsittiin |
| Toiminnallisen määrittelyn päivitys | 4 | 8 | Toiminnallinen määrittely oli valmiiksi hyvin ajan tasalla |
| Teknisen määrittelyn päivitys | 27 | 12 | Tekniseen määrittelyyn tuli paljon tarkennuksia koodin pohjalta |
| Palm-alustan koodaus | 12 | 7 | Alusta koodattiin hyvin ja perusteellisesti |
| Pelin käyttöliittymän koodaus | 9 | 3 | Käyttöliittymään tuli yllättävän paljon muutoksia |
| Alustan koodaus palvelimelle | 37 | 9 | Alustasta tehtiin parempi ja hienompi. Lisäksi käytettiin aikaa alustan riippumattomuuden saavuttamiseksi |
| Pelin koodaus palvelimelle | 12 | 15 | |
| Protokollan latausvaiheen koodaus | 15 | 14 | |
| Protokollan pelinaikaisen toiminnan koodaus | 14 | 7 | Protokollasta tuli monimutkaisempi kuin osattiin odottaa |
| Protokollan lopullinen integrointi palvelimeen ja Palmiin | 23 | 15 | Hieman odottamattomia, mutta hyvin selvitettyjä ongelmia |
| Testaussuunnitelman yleinen viimeistely | 12,5 | 3 | Testisuunnitelmassa oli vielä paljon viimeisteltävää |
| Pelispesifisten testausten yksityiskohdat suunnitelmaan | 4 | 6 | |
| Alustaspesifisten asioiden testaus suunnitelmaan | 0 | 6 | Alustan testaus on hoidettu muiden testien yhteydessä |
| Vaiheen aikana kehitettyjen toimintojen lisäys testisuunnitelmaan | 3 | 6 | |
| Suunnitelman mukainen testaus | 12 | 14 | |
| Testausraportin kirjoitus | 16 | 12 | |
| Burana-raporttien teko | 1 | 8 | Burana-raporttien teko on hyvin nopeaa toimintaa, jolloin yksittäisten raporttien teko jää helposti merkitsemättä |
| Pelidatan luominen | 4 | 5 | |
| Ylläpitäjän käyttöohjeen kirjoitus | 5 | 5 | |
| Loppukäyttäjän käyttöohjeen kirjoitus | 3 | 2 | |
| WWW-sivujen päivitys | 14 | 5 | WWW-sivujen ulkonäköä on muokattu hienommaksi |
| Projektisuunnitelman päivitys | 2 | 3 | |
| Dokumenttien oikoluku | 14 | 10 | |
| Seuraavan vaiheen suunnittelu | 5 | 5 |
| Tehtävä | Toteuma | Suunniteltu | Syy poikkeamaan |
|---|---|---|---|
| Ryhmäpalaverit | 23 | 21 | |
| Asiakaspalaverit | 8 | 12 | |
| Toiminnallisen määrittelyn muokkaus | 0 | 4 | Ei tullut tarvetta viilata toiminnallista määrittelyä enää |
| Teknisen määrittelyn muokkaus | 6 | 8 | |
| Käyttöliittymän toimintojen hiominen | 8 | 5 | |
| Käyttöliittymän koodin optimointi | 21 | 5 | UDP:n täydellinen toimimattomuus Palmin virtuaalikoneessa aiheutti paljon lisätyötä |
| NPC- ja PC-hahmojen koodaus | 32 | 5 | Örkkien tekoäly ja käyttäytyminen tehtiin vaatimustasoa paremmaksi |
| Pelin toiminnallinen koodaus | 6 | 5 | |
| Pelin yksityiskohtien koodaus | 0 | 6 | Mitään sen kummempia yksityiskohtia ei peliin tehty, panostettiin enemmän örkkien toimintaan |
| Palvelinohjelmiston hiominen | 11 | 6 | |
| Palvelimen ylläpidettävyyden hiominen | 13 | 6 | Ylläpitojärjestelmän rajapinnan teko oli luultua työläämpi |
| Protokollan laajentaminen | 11 | 8 | |
| Protokollan optimointi | 15 | 8 | Edellämainittu UDP:n toimimattomuus Palmissa aiheutti lisämuutoksia protokollaan |
| Testisuunnitelman hiominen | 1 | 5 | Testisuunnitelma oli jo viime vaiheen pohjalta erinomainen |
| Funktionaalinen testaus | 12 | 7 | Testauspäällikkö kehitti paljon testicaseja, joiden testaukseen vierähti aikaa |
| Suorituskykytestaus | 2 | 7 | Testaus suoritettiin pienemmillä resursseilla kuin oli suunniteltu |
| Käytettävyystestaus | 6 | 7 | |
| Testausraportin kirjoitus | 14 | 6 | Testicasejen lukumäärästä johtuen myös raportin kirjoitus vei enemmän aikaa |
| Burana-raporttien toteutus | 2 | 7 | Buranan käyttö on niin nopeaa, että tunnit on yleensä tullut merkittyä testauksen tai koodauksen yhteyteen |
| Projektin hallinnointi | 5 | 5 | |
| Loppukäyttäjän käyttöohjeen kirjoitus | 4 | 2 | |
| Ylläpitäjän käyttöohjeen kirjoitus | 8 | 10 | |
| Projektisuunnitelman päivitys | 2 | 3 | |
| WWW-sivujen päivitys | 0 | 5 | Oskarin ollessa sairaana hän ei pystynyt päivittämään WWW-sivuja |
| Pelidatan luonti | 5 | 1 | Pelidataa tarvittiin tässä vaiheessa enemmän kuin osattiin odottaa |
| Dokumenttien oikoluku | 3 | 7 | Oskarin ollessa sairaana hän ei ehtinyt suorittamaan paljon oikolukemista |
| Seuraavan vaiheen suunnittelu | 5 | 5 |
| Tehtävä | Toteuma | Suunniteltu | Syy poikkeamaan |
|---|---|---|---|
| Ryhmäpalaverit | 29 | 35 | |
| Asiakaspalaverit | 0 | 6 | Asiakaspalaverit katsottiin turhiksi, koska yksityiskohdat olivat jo selvillä edellisen vaiheen jälkeen |
| Bugien korjaus | 5 | 8 | |
| Koodin viimeistely | 6 | 8 | |
| Funktionaalinen testaus | 3 | 3 | |
| Suorituskykytestaus | 0 | 3 | Koodia muutettiin niin vähän, ettei suorituskykytestausta enää tässä vaiheessa tarvittu |
| Käytettävyystestaus | 0 | 3 | Käytettävyystestaus suoritettiin tässä vaiheessa asiakkaalla |
| Asiakkaan suorittaman testauksen valvominen | 3 | 4 | |
| Testausraportin kirjoitus | 7 | 3 | Joku on laittanut opponenttirestausraportin kirjoituksen tunteja väärään paikkaan |
| Järjestelmän valmistelu opponenteille | 5 | 10 | Ei ollut paljon valmisteltavaa |
| Opponenttien järjestelmän testaus | 27 | 15 | Systeemin monimutkaisuuden vuoksi asennustyöhön meni aikaa |
| Projektin hallinta | 5 | 4 | |
| Asiakaskoulutus | 10 | 6 | |
| Lopullisen pelidatan luonti | 11 | 12 | |
| Burana-raporttien toteutus | 0 | 7 | Buranaa ei tässä vaiheessa paljon tarvinnut käyttää |
| Pelinkehittäjän opas, rakenteen suunnittelu | 3,5 | 6 | |
| Pelinkehittäjän opas, kirjoitus | 10 | 8 | |
| Pelinkehittäjän opas, viimeistely | 1 | 4 | Viimeistely on merkitty osittain kirjoitusosioon |
| Vanhojen dokumenttien päivitys | 2 | 7 | Dokumentit olivat jo hyvällä mallilla |
| Dokumenttien oikoluku | 5 | 2 | |
| WWW-sivujen päivitys | 0 | 1 | Sivut olivat jo hyvät |
| Loppuraportin kirjoitus | 12 | 8 |
| Ryhmän jäsen | PS-vaihe | T1-vaihe | T2-vaihe | T3-vaihe | T4-vaihe | LU-vaihe | Yhteensä | Kommentti |
|---|---|---|---|---|---|---|---|---|
| Juha T. Vainio | 54 / 60 | 38 / 32 | 31 / 31 | 37 / 30 | 45 / 36 | 34 / 30 | 239 / 219 | Kaikenlaista ennalta-arvaamatonta työtä ilmeni lähestulkoon joka vaiheessa |
| Oskari Mertalo | 13,5 / 40 | 15 / 37 | 16 / 38 | 37 / 40 | 13 / 32 | 25,5 / 35 | 120 / 222 | Oskarin työpanokset ovat olleet epätasaisia mutta loppuvaiheissa löytyy hieman yritystä |
| Anssi Kanninen | 16,5 / 20 | 20 / 40 | 69 / 40 | 67 / 41 | 46 / 28 | 15 / 20 | 233,5 / 189 | Anssi on tehnyt loistavaa ja hyvää työtä joka vaiheessa |
| Christian Jalio | 30 / 20 | 41 / 40 | 21 / 36 | 60 / 38 | 33 / 26 | 31 / 24 | 216 / 184 | Jalio on tehnyt myös hyvää työtä kaiken aikaa |
| Joni Pajarinen | 18 / 20 | 35 / 41 | 20 / 37 | 32 / 40 | 53 / 26 | 24 / 24 | 182 / 188 | Joninkaan työssä ei ole ollut valittamista |
| Ilpo Nyyssönen | 16,5 / 20 | 26 / 40 | 25 / 37 | 50 / 42 | 32 / 27 | 27 / 22 | 176,5 / 188 | Mainiota ja laadukasta toimintaa palvelimen ja ylläpidon parantamiseksi |
| Jarmo Mäki | 20 / 20 | 16 / 40 | 35 / 41 | 51,5 / 41 | 30 / 27 | 26 / 23 | 178,5 / 192 | Jarmo on tehnyt tasaisen hyvää työtä projektin aikana |
| Yhteensä | 168,5 / 200 | 191 / 270 | 217 / 260 | 334,5 / 272 | 252 / 202 | 182,5 / 178 | 1345,5 / 1382 |
| Tehtävälaji | Selitys | Tunnit | Prosenttia työmäärästä |
|---|---|---|---|
| A | ATK-ylläpito | 52 | 4 % |
| D | Dokumentointi | 269 | 20 % |
| K | Kokoukset | 235 | 18 % |
| L | Luennot | 62 | 5 % |
| O | Ohjelmointi | 281 | 21 % |
| S | Suunnittelu | 211 | 16 % |
| T | Testaus | 66 | 5 % |
| U | Opiskelu | 79 | 6 % |
| P | Projektin hallinta | 41 | 3 % |
Projektisuunnitelmassa määritettiin projektin alussa projektin hinnaksi 525.000mk (e 88.235), jakautuen seuraavasti:
Projektin todelliset kulut olivat seuraavat:
Ohjelmiston lopulliseksi kooksi tuli 8.827 riviä ja se jakaantui seuraavasti ohjelmiston eri osiin:
Ohjelmistossa ei ole luovutushetkellä tunnettuja virheitä. Ainoa sulkematon bugiraportti on virhetilanteesta, joka ei johdu ohjelmistostamme: Kun Monrovia-pelistä poistuu erikseen sulkematta yhteyttä, soketit jäävät auki ja takaisin peliin kirjoittautuminen ei onnistu. Tämä johtuu J2ME:ssä olevasta bugista, eikä siihen valitettavasti voi vaikuttaa. Tämä pitää huomioida peliä pelattaessa ja muistaa sulkea yhteys erikseen ennen pelistä poistumista.
Projektiryhmä ei käyttänyt mitään hirveän eriskummallisia ohjelmistotuotannon menetelmiä projektin aikana. Tämä johtui suurelta osin siitä, että projektipäällikön tausta on tietoliikenneohjelmistoista, eikä ohjelmistotuotannon alueelta. Tässä kappaleessa kuitenkin esitellään käyttämiämme menetelmiä ja työkaluja.
Riskienhallintasuunnitelma tehtiin riskit-menetelmää käyttäen ja se osoittautuikin erittäin hyväksi. Useita riskejä tunnistettiin heti alussa ja näin saatettiin huolehtia siitä, että riskit eivät toteudu projektin edetessä. Riskienhallintasuunnitelmaa pidettiin silmällä ja tarkennettiin projektin edetessä ja käytännössä toteutuneilta riskeiltä vältyttiin täysin.
Projektin hallinassa käytettiin jo muinaisten ohjelmistotuottajien kehittämää hajoita ja hallitse -menetelmää. Projekti jaettiin loogisiin osakokonaisuuksiin ja niille asetettiin omat vastuuhenkilönsä ja/tai -ryhmänsä.
Tämäkin menetelmä toimi erinomaisesti, osaprojektien päälliköt hoitivat ryhmiensä johdoissa tehtävänsä ja kaikki saatiin ajallaan valmiiksi.
Projekti on tehty iteratiivisuuteen ja inkrementaalisuuteen perustuvaa USDP-menetelmää (Unified Software Development Process) käyttäen, eli jokaisessa vaiheessa on vanhat dokumentit tarkastettu ja päivitetty, ja ohjelmistoa kasvatettu toimivissa inkrementeissä. Ohjelmisto on jokaisessa toteutusvaiheessa käynyt läpi USDP-inkrementin, eli muutokset on suunniteltu ja ohjelmoitu, ja vaiheen lopulla ohjelmisto on aina testattu täydellisesti.
USDP-menetelmä otettiin käyttöön kurssin painostuksesta, ja on osoittautunut ihan toimivaksi. Epäilemättä kuitenkin projekti olisi saatu kunnialla loppuun myös käyttämällä jotain kilpailevaa prosessimallia, kuten vesiputousmenetelmää. USDP:n käyttö on ajoittain aiheuttanut kitkaa projektiryhmän sisällä, joten siitä saavutetut edut ja haitat menevät suurin piirtein tasan. Em. kitka liittyy tarkemmin USDP:n osittain paikallaan junnaavaan luonteeseen, kun taas projektiryhmän jäsenet ovat tottuneet enemmänkin vesiputousmallin suoraviivaisesti etenevään prosessiin.
Projektin edistymistä seurattiin satunnaisen sähköpostikirjeenvaihdon lisäksi jokaviikkoisissa viikkopalavereissa, joihin osallistuivat kaikki projektiryhmän jäsenet. Näissä palavereissa käytiin tehtävä tehtävältä läpi kaikki ajankohtaiset asiat ja pidettiin huolta, että kaikilla alueilla tapahtuu edistystä ja kaikki asiat saadaan valmiiksi ajallaan.
Menetelmä toimi hyvin koko projektin ajan, sillä kaikki tehtävät tulivat ajallaan tehdyiksi.
Ohjelmiston ja dokumenttien versiot hallittiin CVS-versionhallintajärjestelmällä. Tiedostoja sai editoida kuka tahansa milloin vain, kunhan muisti aina päivittää hakemiston, sitouttaa muutokset järjestelmään ja yhdistää versiot automaattiyhdistämisen epäonnistuessa.
Tuntimäärän seurantaan käytettiin kurssin tukemaa Tirana-järjestelmää, joka osoittautui ihan toimivaksi silloin kun ryhmän jäsenet muistivat tai jaksoivat tunteja syöttää. Tirana-järjestelmän hitaus ja toimimattomuus muilla kuin Internet Explorer -selaimella vaikutti asiaan. Tiranassa voisi myös olla mahdollisuus syöttää kerralla useamman päivän tunteja nopeammin.
Tilastotietoa tunneista sai hyvin kurssin tarjoamalta ViCA-järjestelmältä. Se toimi moitteetta sekä Internet Explorerissa, että Operassa, mutta oli Tiranan tavoin erittäin hidas.
Luokkakaavioita tehtiin tekniseen määritelmään käyttäen UML (Unified Modeling Language) -kieltä. Kurssin puolelta tuettiin Rational Rose -ohjelmiston käyttöä, joten UML-kaaviot tehtiin tätä käyttäen.
UML osoittautui tehokkaaksi ja hyväksi tavaksi kuvata ohjelmiston protokollaa ja Javan luokkahierarkioita. Rational Rose hoiti hommansa erinomaisesti, mutta ongelmia aiheutti itse ohjelman hankinta. Kaikkea suunnittelutyötä kun ei pystynyt tekemään ohjelmatyöluokassa, vaan täysipainoinen ohjelmatyön suorittaminen vaati, että kaikki käytettävät ohjelmat ovat saatavilla kotona. Linux-ihmiset olivat Rational Rose -asiassa erityisen huonossa asemassa.
Monrovia-alustalle on nähtävissä hyvät kehitysnäkymät, sillä järjestelmä ohjelmoitiin laajennettavuutta kaiken aikaa silmälläpitäen.
Käyttöliittymän muokkaus EPOC-käyttöjärjestelmällä toimivaksi olisi varmasti erinomainen hanke. Peli saattaa toimia mainiosti Nokian tulevalla 9210 Communicatorilla, jossa on EPOC-käyttöjärjestelmä.
Käyttöliittymä on tällä hetkellä mustavalkoinen, mutta jo tällä hetkellä on olemassa Palmeja, joissa on värinäyttö. Lisäksi edellämainitussa Nokia 9210 Communicatorissa on värinäyttö. Värillisyys on siis eräs erittäin varteenotettava kehitysehdotus.
Ei oppinut kurssilla mitään uutta
Kurssi oli erinomaisesti järjestetty ja ainakin TML-laboratorion kursseihin verrattuna käytännön asiat toimivat erittäin hyvin. Vaiheiden arvostelut tulivat nopeasti, vaikka arvosteltavaa olikin paljon, eikä tarvinnut kuukausikaupalla kysellä perään.
Projektiryhmässä keskustelua on aiheuttanut eri assistenttien hieman erilaisilta tuntuvat arvosteluperusteet, samoin kuin projektien keskinäinen erilaisuus. Kaikkien projektien pakottaminen samanlaiseen muottiin, vaikka projektien luonne saattaa olla hyvinkin erilainen, saattaa vaikeuttaa toisten projektien suorittamista.
Projektissa käytettävät kurssin tarjoamat työkalut ovat myös saaneet kritiikkiä osakseen. Vaikka työkalut ovat hienoja ja toimintaperiaatteet perin hyödyllisiä, on niiden hitaus monesti aiheuttanut ongelmia. Jopa siinä määrin, että kaikkien projektin jäsenten kaikkia tunteja ei välttämättä ole esim. Tiranaan syötetty. Lisäksi työkalut tuntuvat toimivan oikein ainoastaan Internet Explorerilla. Operalla on lähes mahdoton käyttää Tiranaa (syötetyt tunnit menevät kantaan ehkä n. joka kolmannella kerralla), ViCA taasen ei toimi ollenkaan Netscapessa (jos sitä nyt kukaan edes haluaisi käyttää).