Tik-76.115 Projektisuunnitelma, v5.0

Ryhmä: Hayabusa, Aihe: Monrovia, Vastuu: Juha T. Vainio

Viimeksi päivitetty 2001-04-22 - Juha T. Vainio

Muutosloki

• 2001-04-22 Resurssitaulukkoon laitettu LU-vaiheen tunnit
• 2001-04-18 Ryhmän jäsenten tietoja muutettu
• 2001-04-18 Resurssitaulukkoon lisätty edellisen vaiheen tunnit
• 2001-03-18 LU-vaiheen tavoitteita tarkennettu
• 2001-03-13 LU-vaiheen tavoitteita tarkennettu
• 2001-03-13 Resurssitaulukkoa muokattu
• 2001-03-13 Riskitaulukkoa muutettu, riskit ovat enää pieniä ja epätodennäköisiä
• 2001-02-09 Hayabusa-ryhmän tietoja päivitetty
• 2001-02-09 Riskienhallintaa muokattu
• 2001-02-09 T4-vaiheen tavoitteita tarkennettu
• 2001-02-09 Resurssitaulukkoa muokattu
• 2000-12-30 Muokattu riskianalyysin taulukkoa
• 2000-12-02 Lisätty kustannusarvio, päivitetty vaiheiden sisältöjä ja edellisen vaiheen tuntimäärät
• 2000-11-03 Muutettu tehtäviä, menetelmiä ja yleiskuvausta
• 2000-10-15 Ensimmäinen versio

Projektiryhmällä tarkoitetaan opiskelijoiden muodostamaa työryhmää, jonka vastuulla on projektin toteutus. Asiakkaalla tarkoitetaan projektin lopputuotteen vastaanottajaa, eli projektin asiakasta.

Lyhyt tiivistelmä

Tämä projektisuunnitelma kuvaa Teknillisen Korkeakoulun Tik-76.115 Tietojenkäsittelyopin Ohjelmatyö -kurssilla lukuvuonna 2000-2001 tehtävää Monrovia-projektia. Projektia toteuttaa Hayabusa-ryhmä, johon kuuluu 7 edistynyttä tietotekniikan opiskelijaa. Asiakkaana projektilla on Mgine Technologies, jota edustaa kolme työntekijää asiakkaan, ohjaajan ja asiantuntijan rooleissa.

Monrovia-projektissa on tarkoituksena tehdä monen käyttäjän karttapohjainen seikkailupeli mobiililaitteille. Päätelaitteiksi on suunniteltu Palm-kämmenmikroja ja itse pelin hallinta tapahtuu normaalissa PC-palvelimessa Linux-käyttöjärjestelmän päällä. Toteutus tehdään käyttäen Java-ohjelmointikieltä niin pitkälle kuin mahdollista. Oikeudet syntyneeseen materiaaliin saa sekä asiakas että projektiryhmä.

Tässä suunnitelmassa on esitelty projektin yksityiskohdat aihetta, ryhmän jäseniä, asiakasta, resurssointia ja käytettäviä menetelmiä myöten. Tämä suunnitelma elää kaiken aikaa ja vanhassa versiossa saattaa olla jo vanhentunutta informaatiota.

Sisällysluettelo

1. Johdanto
2. Termit ja määritelmät
3. Projektin toteutusperusteet
4. Projektin organisaatio
5. Projektin tavoitteet ja päättäminen
6. Projektin resurssit
7. Projektissa käytettävät menetelmät ja työkalut
8. Projektin ositus, vaiheistus ja resurssointi
9. Seuranta ja ohjaus
10. Riskienhallintasuunnitelma
11. Koulutussuunnitelma

1. Johdanto

1.1 Projektin motivaatiotekijät

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.

1.2 Projektin tarkoitus ja kattavuus

Projektissa on tarkoitus suunnitella monen käyttäjän karttapohjainen seikkailupeli mobiilikäyttäjille. Projektiin kuuluu yleisellä tasolla tutkia, onko kyseisenlainen palvelu järkevä annettuun ympäristöön ja samalla näyttää tietä muiden karttapohjaisten palveluiden implementointiin myöhemmin.

1.3 Tuote ja ympäristö

Projektin tuotteena syntyy monen pelaajan asiakas-palvelin arkkitehtuuri, joka soveltuu käytettäväksi mukana kuljetettavilla mobiililaitteilla, kuten matkapuhelin ja kämmenmikro.

Työssä käytetään Palm-kämmenmikroa, jolle implementoidaan Java-ohjelmointikielellä asiakasohjelmisto karttapohjaiseen peliin. Palvelinohjelmisto ohjelmoidaan niin ikään Java-kielellä ja sitä tullaan ajamaan Linux-pohjaisessa PC-palvelimessa.

1.4 Asiakkaan nykyinen ratkaisu

Asiakkaalla ei ole nykyistä ratkaisua, vaan eräs projektin tarkoituksista on juuri selvittää uusia mahdollisuuksia ja ennennäkemättömiä tekniikoita tulevaisuuden projekteja silmälläpitäen.

1.5 Oikeudet työn tuloksiin

Oikeudet työn tuloksiin jäävät sekä projektiryhmälle, että asiakkaalle. Tästä on allekirjoitettu sopimukset Mginen ja jokaisen työntekijän välille.

1.6 Yleiskatsaus dokumenttiin

Projektisuunnitelma on jaettu loogisiin kappaleisiin. Aluksi puhutaan yleisemmin dokumentissa esiintyvistä määritelmistä ja termeistä, jotta epäselvyyksiä ei myöhemmin jää. Tästä jatketaan projektin toteutusperusteisiin, joihin sisältyy asiakkaan motivaatiotekijöiden tarkempi selvitys.

Projektin organisaatio kuvataan omassa kappaleessaan 4. Siitä ilmenee tarkempi kuvaus ja yhteystiedot sekä projektiryhmän jäsenistä, että projektin asiakkaasta ja mahdollisista muista sidosryhmistä. Tästä jatketaan projektin tavoitteiden tarkempaan läpikäyntiin sekä keskeytysperusteiden kuvaukseen.

Projektin resurssit on tarkemmin luetteloitu kappaleessa 6, jossa on taulukko kunkin jäsenen työmääristä projektin eri vaiheissa. Projektissa käytettävät menetelmät ja työkalut eritellään kappaleessa 7 ja projektin yleisrakenteesta ja seurannasta on yksityiskohtaista tietoa kappaleissa 8 ja 9.

Projektiin liittyvät standardit eritellään ja kuvaillaan seuraavassa kappaleessa. Tästä jatketaan riskienhallintasuunnitelmaan kappaleessa 10. Viimeisessä kappaleessa käsitellään ryhmän koulutuksen järjestelyitä.

2. Termit ja määritelmät

2.1 Dokumentissa esiintyvät termit

2.2 Dokumentissa esiintyvät lyhenteet

3. Projektin toteutusperusteet

Asiakkaan pääasiallisena tavoitteena on hankkia projektin kautta tietoa karttapohjaisten palveluiden toiminnasta mobiilimaailmassa. Kolmannen sukupolven matkapuhelinjärjestelmät tekevät tuloaan ja nopealle yrittäjälle kyseessä on epäilemättä hurja rahasampo.

Päätavoitteen ilmentymänä aikaansaadaan toimiva ja demottava tuote mahdollisesta tulevaisuuden mobiilipalvelusta. Tämä on jo aikaisemminkin mainittu monen käyttäjän seikkailupeli.

Tavoitetta voidaan osittaa vielä pienempiin tavoitekokonaisuuksiin, jotka sisältyvät päätavoitteeseen. Näitä pienempiä osatavoitteita ovat seuraavat:

• Onko systeemi mahdollista tehdä
• Onko systeemi järkevää tehdä
• Miten systeemi voidaan tehdä

Asiakkaan saama suora hyöty projektista on siis ensisijaisesti tietotaito, jolla päästään edelläkävijöiden joukkoon varsin rahakkaaksi ennustetussa liiketoiminnassa. Lisäksi asiakas saa oikeudet projektiryhmän tuottamaan koodiin, jossa on toteutettuna valmis arkkitehtuuri pohjaksi useammanlaisille palveluille.

Projektin suorat kustannukset ovat pienehköt. Tarvitaan yksi kappale palvelimina toimivia PC-laitteita sekä useampi kappale Palm-kämmenmikroja testikäyttöä silmälläpitäen. Muita kustannuksia tulee asiakkaan työtunneista palavereissa, seurannoissa ja muussa osallistumisessa.

4. Projektin organisaatio

Tässä kappaleessa esitellään yksityiskohtaisesti projektin organisaatio.

4.1 Projektiryhmä Hayabusa

Hayabusan kotisivu: http://monrovia.mginetechnologies.com/
Hayabusan sähköpostiosoite: ohjelmatyo@ypy.tky.hut.fi

Hayabusan jäsenet:

Rooli: Projektipäällikkö

Nimi: Juha T. Vainio

Vastuualueet: Vastaa projektin yleisestä kulusta, käytännön asioista sekä hallinnoinnista. Vastaa lisäksi projektisuunnitelmasta ja edistymisraporteista.

Puhelin: 0400 740 000

E-mail:

WWW-kotisivu: http://www.iki.fi/jiitv/

Kiinnostus- ja osaamisalueet: Tietokoneverkot, tietoturvallisuus

Opiskelu- ja työkokemus: 7 vuotta opiskelua TKK:lla, 10 vuotta tutkimus- ja kehitystyötä Soneralla ja Stonesoftilla

Rooli: WWW- ja dokumentointivastaava

Nimi: Oskari Mertalo

Vastuualueet: Vastaa ryhmän WWW-sivuista, niiden kattavuudesta ja ajantasaisuudesta. Vastaa myös dokumenttien ulkoasusta ja sisällön oikeellisuudesta.

Puhelin: 040 725 0459

E-mail: /dd>

Kiinnostus- ja osaamisalueet: Multimedia ja sisällöntuotanto

Opiskelu- ja työkokemus: 7 vuotta opiskelua TKK:lla, useita vuosia työtä erinäisissä uusmediayrityksissä

Rooli: Käyttöliittymävastaava

Nimi: Anssi Kanninen

Vastuualueet: Vastaa Palmiin tulevan ohjelmiston suunnittelusta ja toteutuksesta. Vastuussa loppukäyttäjän käyttöohjeesta.

Puhelin: 040 750 4141

E-mail: AnssiKanninen

WWW-kotisivu: http://www.iki.fi/anssi/

Kiinnostus- ja osaamisalueet: Käyttöliittymät, tietokoneverkot

Opiskelu- ja työkokemus: 7 vuotta opiskelua TKK:lla, 5 vuotta ohjelmointityötä Stonesoftilla

Rooli: Palvelinvastaava

Nimi: Ilpo Nyyssönen

Vastuualueet: Vastaa palvelinpään ohjelmiston suunnittelusta ja toteutuksesta. Hoitaa palvelimeen liittyvät asiat, kuten uusien ohjelmien asennukset ja systeemien päivitykset. Vastaa toiminnallisesta määrittelystä.

Puhelin: 040 530 9902

E-mail: iny@iki.fi

Kiinnostus- ja osaamisalueet: Java, Linux

Opiskelu- ja työkokemus: 4 vuotta opiskelua TKK:lla, 2 vuotta ohjelmointityötä Stonesoftilla

Rooli: Protokollavastaava

Nimi: Christian Jalio

Vastuualueet: Vastaa Palmin ja palvelimen välillä toimivasta protokollasta ja rajapinnoista. Pitää huolen suunnitteluryhmän sisäisistä asioista. Vastaa vaatimusmäärittelystä.

Puhelin: 040 523 8644

E-mail: wjalio@cc.hut.fi

Kiinnostus- ja osaamisalueet: Java, tietokoneverkot, käyttöjärjestelmät

Opiskelu- ja työkokemus: 5 vuotta opiskelua TKK:lla, useita vuosia töitä Avantcompissa ja Stonesoftilla

Rooli: Testauspäällikkö

Nimi: Jarmo Mäki

Vastuualueet: Vastaa testauksesta kaikilta osin. Vastuussa testaussuunnitelmasta.

Puhelin: 040 820 2579

E-mail: jamaki@cc.hut.fi

Kiinnostus- ja osaamisalueet: Tietoturvallisuus

Opiskelu- ja työkokemus: 4 vuotta opiskelua TKK:lla, useita vuosia töitä Stonesoftilla

Rooli: Pelivastaava

Nimi: Joni Pajarinen

Vastuualueet: Vastaa pelistä, peliin liittyvistä yksityiskohdista ja pelin rakentamisesta. Voidaan irroittaa myös muihin tehtäviin, mikäli resurssipulaa ilmenee. Vastaa teknisestä määrittelystä.

Puhelin: 040 758 6696

E-mail: jpajarin@cc.hut.fi

Kiinnostus- ja osaamisalueet: Java, käyttöjärjestelmät

Opiskelu- ja työkokemus: 4 vuotta opiskelua TKK:lla, useita vuosia töitä Avantcompissa ja Stonesoftilla

4.2 Asiakas

Projektin asiakkaana on Mgine Technologies, joka muotoutui aikoinaan Done Wirelessistä, osasta suurempaa Done konsernia. Mgine Technologies vastaa langattoman viestinnän tuotteiden ja palveluiden kehittämisestä ja myynnistä sekä langattoman viestinnän konsultoinnista. Mgine Technologiesin painopistealueita ovat langattoman viestinnän personointi- ja paikantamispalvelut.

Mgine Technologiesilta projektiin lähemmin osallistuvat jäsenet:

Rooli: Ohjaaja

Toimenkuva: Seuranta sekä projektin edistymisen valvonta ja ohjaus

Nimi: Teppo Koskinen

Puhelin: 040 762 9405

E-mail: Teppo.Koskinen@mginetechnologies.com

Rooli: Asiakas

Toimenkuva: Projektin edistymisen valvonta ja raiteillaan pitäminen

Nimi: Marjo Sjöberg

Puhelin: 040 525 9268

E-mail: Marjo.Sjoberg@mginetechnologies.com

Rooli: Linux-asiantuntija

Toimenkuva: Mgine Technologiesin päässä palvelinkoneen rutiiniylläpitotehtävät

Nimi: Lauri Jutila

E-mail: Lauri.Jutila@mginetechnologies.com

5. Projektin tavoitteet ja päättäminen

5.1 Projektiryhmän tavoitteet

Ensisijainen tavoite projektiryhmällä on saada aikaan toimiva järjestelmäkokonaisuus, jota voidaan demota asiakkaalle ja sitä kautta läpäistä kurssi mahdollisimman hyvällä arvosanalla. Tämä tulee saavuttaa sovitussa aikataulussa ja alkuperäisiä suunnitelmia noudattaen. Työnjaon tavoitteena on, että jokaiselle tulee suurinpiirtein saman verran työtunteja ja jokainen saisi tasapuolisesti haastavia tehtäviä.

5.2 Asiakkaan tavoitteet

Välttämättömat tavoitteet järjestelmälle:

• Pelijärjestelmän toteutuksessa käytetään Java-kieltä
• Päätelaitteeksi valitaan joko Palm- tai EPOC-pohjaiset laitteet
• Pelialustalle toteutetaan yksinkertainen ja demottava monen pelaajan vuoropohjainen peli
• Pelin käyttöliittymän täytyy olla itsestäänselvä, ja vähänkään tekniikasta perillä olevan ihmisen täytyy pystyä pelaamaan peliä ilman ohjeita tai opastusta.
• Verkkoteknologiana käytetään GPRS-verkkoa UDP-protokollalla
• Järjestelmän suorituskyky pitää olla riittävä vuoropohjaiselle pelille
• Dokumentaatiokieli on englanti

Toivottavat tavoitteet:

• Peliä pitää pystyä pelaamaan väh. 10 pelaajaa
• Pelin tulee olla karttapohjainen sovellus
• Pelin toiminnan tulee olla helposti omaksuttavissa
• Pelijärjestelmässä tulee olla mahdollisuus pelien kulkuun liittyvän lokitiedon tallentamiseen

Käytettävissä olevan ajan puitteissa toteutettavat lisätoiminnot

• Pelijärjestelmän ylläpitotyökaluja
• Karttaeditori pelialueita varten

Kymmenen tärkeintä lopputavoitetta tärkeysjärjestyksessä:

1. Järjestelmä on toteutettu Javalla.
2. Järjestelmä on asiakkaan mielestä demottavassa kunnossa.
3. Järjestelmän osana toteutettu peli on monen pelaajan vuoropohjainen seikkailupeli.
4. Järjestelmässä on kiinnitetty huomiota toimivaan interaktiivisuuteen siten, että suurimmat viiveet pelissä langattoman epäluotettavan verkon yli eivät ylitä kymmentä sekuntia.
5. Pelin omaksumisen ja pelaamisen täytyy olla helppoa. Tämä mitataan käytettävyystesteillä joko asiakkaan luona tai ulkopuolisia testikäyttäjiä käyttäen.
6. Dokumentaatio on asiakkaan seuraamaa ja laadultaan riittäväksi toteamaa.
7. Jos järjestelmää ei ole pystytty toteuttamaan asiakkaan vaatimusten mukaisesti, on asiaan vaikuttavat seikat dokumentoitu asiakkaan hyväksymällä tavalla.
8. Peliä pitää pystyä pelaamaan yhtäaikaisesti ainakin 10 pelaajaa.
9. Pelin keskeinen idea liittyy karttapohjaisuuteen.
10. Järjestelmä on toteutettu asiakkaan hyväksymillä resursseilla.

5.3 Projektin tavoitteet

Projektin pääasiallinen tavoite on selvittää, voiko asiakkaan välttämättömät ja toivottavat vaatimukset täyttävää pelijärjestelmää toteuttaa. Jos järjestelmä todetaan toimivaksi, selvitetään vielä mahdollisuudet haluttujen lisätoimintojen toteuttamiseksi. Jos todetaan, että toivottavia ja/tai välttämättömiä tavoitteita ei voida toteuttaa, selvitetään toteutuksen estävät pullonkaulat.

5.4 Projektin keskeyttämiskriteerit

Jos projektiryhmän henkilömäärä projektin aikana pienenee niin paljon, että jäljellä olevat henkilöt katsovat projektin olevan mahdotonta toteuttaa määritellyssä aikataulussa, projekti voidaan keskeyttää.

Myös asiakas voi keskeyttää projektin. Tällöin projektiryhmä selvittää kurssin henkilökunnalta vaihtoehtoisen tavan suorittaa kurssi.

5.5 Projektin päättämiskriteerit

Projektille on ohjelmatyökurssin puolesta määrätty ajankohta, johon mennessä projektin tulee olla valmis. Kun järjestelmän katsotaan olevan asiakkaan ja projektiryhmän vaatimukset täyttävässä kunnossa, pidetään ryhmän ja asiakkaan kesken projektin loppupalaveri ennen kurssiaikataulun mukaista projektikatselmusta. Projektin dokumenttien pitää olla valmiita 24.4.2001 ja valmis projekti katselmoidaan 26.-27.4.2001.

Projektin lopputuote ja dokumentaatio laitetaan lopuksi asiakkaan saataville projektin kehitysympäristökoneelle. Mikäli projektiin on toteutettu ylläpitäjille tarkoitettuja työkaluja, järjestetään myös näiden koulutus asiakkaalle.

6. Projektin resurssit

Seuraavasta taulukosta ilmenee arvioitu työpanos tunteina jokaista Hayabusa-ryhmän jäsentä kohti kunkin projektin vaiheen aikana. Mikäli vaihe on ohi, voi kustakin sarakkeesta lukea sekä arvioidun että toteutuneen työpanoksen (toteuma/arvio).

Asiakkaan puolelta tarvitsemme resursseja asiakaspalavereihin, seurantaan sekä paikanpäällä tapahtuvaan palvelimen ylläpitoon. Nämä resurssit käytetään sopimuksen mukaan projektin eri vaiheissa.

Projektisuunnitteluvaihetta lukuunottamatta projektin jokaisessa vaiheessa tarvitaan laitteistona Linux-palvelinta. Tämän on oltava kaikkina aikoina käsillä. Palvelin on asennettu ja se on toiminnassa. Myöhemmissä projektin vaiheissa tarvitaan testikäyttöön Palm-kämmenmikroja.

Kustannusarvio

• Työn hinta: 1410h * 350mk/h = 493.500mk
• Palvelin: ~10.000mk
• Palm-kämmenmikrot: 7 * ~3000mk = ~21.000mk
• Juoksevat kulut: ~1.000mk
• Yhteensä: ~525.500mk

7. Projektissa käytettävät menetelmät ja työkalut

7.1 Työkalut ja apuvälineet

• Ilpo Nyyssönen vastaa työkalujen ja apuvälineiden olemassaolosta, hankinnasta sekä muista asiaan liittyvistä yksityiskohdista.
• Editorina käytetään xemacs 21.1:tä.
• Java-kääntäjäksi jikes nopeutensa vuoksi.
• Versionhallintaohjelmistona käytetään CVS:ää.

7.2 Tiedonkulku

• Pääasiallinen tiedonkulkukanava on ryhmän sähköpostiosoite ohjelmatyo@ypy.tky.hut.fi.
• Projektipäällikkö hoitaa sekä sisäisen, että ulkoisen tiedotuksen.
• Jokaisella ryhmän jäsenellä on myös henkilökohtainen sähköpostiosoite sekä matkaviestin.

7.3 Raportointi

• Raportointiin käytetään kurssin ylläpidon järjestämiä raportointimenetelmiä:
  • Tuntien raportointiin Tirana-järjestelmä
  • Vikojen raportointiin Burana-järjestelmä
  • Koodirivien raportointiin myös Burana-järjestelmä

7.4 Dokumentointi

• Dokumentteihin liitetään mukaan versio, author, date, aihe, ks. Vaatimusmäärittely
• Pohjana käytetään tarvittavassa määrin kurssin järjestämiä template-dokumentteja.
• Kaikki dokumentaatio muotoillaan HTML-muotoon.
• Alkuperäisen suunnitelman mukaan tuotteeseen liittyvät dokumentit tehdään englanniksi ja muut kurssiin liittyvät dokumentit suomeksi. Tämä on kuitenkin aiheuttanut sekaannusta, joten on päätetty, että kaikki ensimmäisen vaiheen jälkeen aloitetut dokumentit tehdään englanniksi. Näin ollen siis ainoastaan jo suomeksi tehdyt dokumentit "Projektisuunnitelma", "Vaatimusmäärittely" sekä "Edistymisraportti" tehdään jatkossakin suomeksi, muut dokumentit englanniksi.

7.5 Nimeämiskäytäntö, hakemisto

• Oskari Mertalo hoitaa nimeämiskaytännön ja ottaa vastuun asiasta, hän ylläpitää dokumenttihakemistoa ryhmän palvelimella.
• Projektipäällikkö vastaa kulloinkin palautettavista dokumenteista ja palautussivusta.

7.6 Suunnittelumenetelmät

• Suunnitteluun käytetään UML-kieltä
• Suunnittelu tehdään Rational Rose -ohjelmistolla mahdollisuuksien mukaan.

7.7 Ohjelmakoodin ulkomuoto ja kommentointi

• Perustana Sunin suosittelema koodaustyyli: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
• Luokkamuuttujien eteen m eli esimerkiksi mVariableName
• Metodiparametrien eteen p eli esimerkiksi pMethodParameter
• Javadoc-kommentointi
• Epäselvät kohdat kommentoitava
• Kielenä englanti
• Kooditiedostoihin mukaan author, cvs id, luontipäiväys

7.8 Laadunvarmistus

• Testaus (2 henk. + opponointi + asiakas) joka vaihe
• Vaiheiden lopussa tarkastetaan asiakkaalla

7.9 Muutosten hallinta

• Selvitetään mihin osiin muutokset vaikuttavat
• Selvitetään mikä on muutettujen komponenttien yhteensopivuus
• Selvitetään miten asiakkaan versio rakennetaan uudestaan
• Koodin osalta käytetään CVS:ää
• Ennen kommitointia käytettävä diffiä, jotta CVS:ään ei mene asiaankuulumattomuuksia

7.10 Tarkastukset

• Oskari Mertalo oikolukee jokaisen dokumentin ennen deadlineä ja vastaa siitä, että dokumentti on järkevä. Hän myös vastaa dokumentin ulkonäöstä ja muodollisista seikoista.
• Versiohallinta ks. yllä, CVS koodi

7.11 Varmuuskopiointi

• Palvelimen varmuuskopiointi ja täten myös kaiken materiaalin varmuuskopiointi hoidetaan asiakkaan puolelta, toivottavasti DAT-nauhalle kerran päivässä, nauha vaihdetaan päivittäin, 7 nauhan kierto

7.12 Palaverikäytännöt

• Viikkopalavereissa käydään läpi projektin edistymistä sekä viikon aikana ilmenneitä hallinnollisia asioita. Projektipäällikkö hoitaa viikkopalaverin järjestämisen, agendan ja koolle kutsumisen.
• Muita palavereita (esim. suunnittelu-) kutsutaan koolle tarpeen vaatiessa. Hallinnollisten palavereiden käytännön järjestelyt hoitaa Projektipäällikkö. Suunnittelu- ja koodausryhmän palavereista on vastuussa Christian Jalio.
• Asiakkaan kanssa pidetään palaveri vähintään jokaisen vaiheen alussa. Voidaan sopia tarpeen vaatiessa myös muita palavereja.
• Jokaisesta palaverista tehdään palaverimuistio, josta ilmenee päivämäärä, kellonaika, paikka, paikallaolijat sekä kokouksessa käsitellyt asiat ja tehdyt päätökset. Palaverimuistio lähetetään palaverin jälkeen niin pian kuin mahdollista ryhmän postituslistalle, ja asetetaan näytille ryhmän kotisivulle.

7.13 Ryhmätyökäytännöt

• Jaetaan työt riittävän pieniin (kesto max. 10 tuntia) ja selkeisiin osiin henkilöä kohden
• Arkkitehtuurin komponenteilla on omat vastuuhenkilönsä
• Projektipäällikkö johtaa koko ryhmää
• Jokaisella dokumentilla on vastuuhenkilönsä, joka johtaa ja on vastuussa ko. dokumentin sisällöstä ja päivittämisestä.
• Suunnittelu- ja toteutusryhmästä, johon kuuluu kaikki muut paitsi Projektipäällikkö ja WWW-vastaava, vastaa Christian Jalio. Suunnittelu- ja koodausasioista raportoidaan herra Jaliolle, muista asioista raportoidaan Projektipäällikölle. Herra Jalio raportoi kaiken Projektipäällikölle.

8. Projektin ositus, vaiheistus ja resurssointi

Projekti on ositettu, vaiheistettu ja resurssoitu käyttäen MS Project -ohjelmistoa. Tässä kappaleessa on esitelty projektin päävaiheet ja niiden sisältö. Tarkempaa ositus-, vaiheistus- ja resurssointitietoa hakevan kehoitetaan kääntymään MS Project -tiedoston puoleen. Tiedoston voi hakea projektisuunnitelman lopussa olevan liitelistan liitteen [A] takaa.

Vaihe 1: Projektin suunnittelu

Sisältö: Suunnitellaan projekti, tehdään projektisuunnitelma ja vaatimusmäärittely. Resurssoidaan alustavasti.

Kesto: 3 viikkoa

Deadline: 2000-10-16

Palautetaan:

• Projektisuunnitelma
• Vaatimusmäärittely
• Edistymisraportti

Vaihe 2: Toteutus 1

Sisältö:

• Suunnitellaan tarkasti järjestelmän toiminnallisuudet
• Suunnitellaan ainakin päällisin puolin tekniset yksityiskohdat
• Suunnitellaan tarkasti projektin seuraava vaihe

Kesto: 3 viikkoa

Deadline: 2000-11-7

Palautetaan:

• Päivitetty projektisuunnitelma
• Päivitetty vaatimusmäärittely
• Päivitetty edistymisraportti
• Toiminnallinen määrittely
• Tekninen määrittely

Vaihe 3: Toteutus 2

Sisältö:

• Viimeistellään tekninen määrittely
• Tehdään alustava testaussuunnitelma
• Toteutetaan käyttöliittymäprototyyppi
• Suunnitellaan tarkasti projektin seuraava vaihe

Kesto: 5 viikkoa

Deadline: 2000-12-12

Palautetaan:

• Päivitetty projektisuunnitelma
• Päivitetty vaatimusmäärittely
• Päivitetty edistymisraportti
• Päivitetty toiminnallinen määrittely
• Päivitetty tekninen määrittely
• Testaussuunnitelma
• Käyttöohje

Vaihe 4: Toteutus 3

Sisältö:

• Tarkistetaan toiminnallista määrittelyä
• Tarkistetaan teknistä määrittelyä
• Testaussuunnitelma valmiiksi
• Tehdään lisää toiminnallisuutta järjestelmään. Tämän vaiheen lopussa ovat ensisijaiset vaatimukset täytetty arkkitehtuurin toiminnallisuuden suhteen. Tämä tarkoittaa sitä, että on olemassa Palm-kämmenmikrossa pyörivä pelin käyttöliittymä, palvelimella pyörivä peli ja näiden välillä toimiva protokolla.
• Testataan arkkitehtuuria, kirjoitetaan testausraportti
• Suunnitellaan tarkasti projektin seuraava vaihe

Kesto: 9 viikkoa

Deadline: 2001-02-13

Palautetaan:

• Päivitetty projektisuunnitelma
• Päivitetty toiminnallinen määrittely
• Päivitetty tekninen määrittely
• Päivitetty testaussuunnitelma
• Edistymisraportti
• Testausraportti
• Loppukäyttäjän käyttöohje-esite
• Alustava ylläpidon käyttöohje

Vaihe 5: Toteutus 4

Sisältö:

• Toteutetaan järjestelmään lisää toiminnallisuutta toissijaisten tavoitteiden toiminnallisuusluettelosta.
• Optimoidaan koodia ja toimintaa
• Testataan, korjataan virheitä
• Lopputavoitteena on saada miellyttävästi pelattava monen käyttäjän peli, johon on lisätty peli-iloa lisääviä elementtejä, kuten vihollisia.
• Suunnitellaan tarkasti projektin seuraava vaihe

Kesto: 5 viikkoa

Deadline: 2001-03-20

Palautetaan:

• Päivitetty ylläpitäjän käyttöohje
• Päivitetty loppukäyttäjän käyttöohje
• Päivitetty projektisuunnitelma
• Päivitetty toiminnallinen määrittely
• Päivitetty tekninen määrittely
• Päivitetty testaussuunnitelma
• Edistymisraportti
• Testausraportti T4-vaiheen testauksista

Vaihe 6: Luovutus

Sisältö:

• Kirjoitetaan pelinkehittäjän opas, jossa on ohjeet omien pelien tekemiseen Monrovia-alustalle
• Tarjotaan asiakkaalle koulutusta ylläpitoasioissa
• Testataan oma järjestelmä lopullisesti yhdessä asiakkaan kanssa
• Korjataan tai dokumentoidaan avoimet virheet
• Hiotaan ulkoasu täydelliseksi
• Viimeistellään dokumentit sisällöllisesti ja ulkoasullisesti
• Paketoidaan palvelinohjelmisto ja työkalut
• Paketoidaan asiakasohjelmisto
• Testataan opponenttiryhmän järjestelmää
• Arvioidaan omaa työtä ja kurssia, kirjoitetaan loppuraportti

Kesto: 5 viikkoa

Deadline: 2001-04-24

Palautetaan:

• Pelinkehittäjän opas
• Lopulliset versiot aiempien vaiheiden dokumenteista
• Opponenttiryhmän testausraportti
• Loppuraportti

9. Seuranta ja ohjaus

9.1 Projektiryhmän sisäinen seuranta

Projektiryhmä seuraa itse omaa edistymistään pääpiirteittäin jokaviikkoisissa viikkopalavereissa. Näissä käydään läpi projektin vaiheet ja kunkin jäsenen aikaansaannokset. Lisäksi jokainen ryhmän jäsen syöttää vähintään viikon välein kaikki projektin eteen tekemänsä tunnit kurssin ylläpidon tarjoamaan Tirana-järjestelmään. Järjestelmästä saatujen tietojen perusteella projektipäällikkö ja hänen kauttaan koko muu ryhmä kykenee seuraamaan tarkemmin ajankäyttöä.

9.2 Projektin seuranta asiakkaan puolelta

Asiakas seuraa tiiviisti projektin etenemistä projektin joka vaiheessa. Ennen jokaisen vaiheen deadlineä asiakkaalle lähetetään kaikki saatavilla oleva materiaali läpikäytäväksi ja kommentoitavaksi. Jokaisen vaiheen alussa pidetään asiakaspalaveri, jossa mietitään ja kuvaillaan strategiaa ja lähtökohtia kyseiseen vaiheeseen. Tämän lisäksi voidaan kutsua koolle asiakaspalavereita, jos tilanne sitä joko projektiryhmän tai asiakkaan puolelta vaatii.

9.3 Projektin seuranta kurssin puolelta

Kurssin puolelta ohjelmatyön edistymistä seurataan deadlinejen sekä katselmusten avulla. Jokaisen vaiheen lopulla pitää olla palautettavaa materiaalia kasassa kurssin johtoa varten. Kurssin johto on myös paikalla vaiheen lopuilla pidettävissä katselmuksissa, joissa selvitetään projektin tila ja tulevaisuus.

10. Riskienhallintasuunnitelma

10.1 Sovelletut menetelmät

Pohjana riskianalyysin, riskiskenaarioiden sekä ennakoivien toimenpiteiden ja riskien toteutuessa käytettävien toimenpiteiden määrittelemiseen on käytetty RiskIt [1] menetelmää. Aluksi on etsitty ryhmälle ja asiakkaalle projektin kannalta tärkeät tavoitteet, jonka jälkeen on tehty vapaamuotoinen lista riskeistä, jotka voivat vaikuttaa negatiivisesti tavoitteiden saavuttamiseen. Riskit on hajoitettu tekijöihinsä ja muodostettu riskiskenaariot. Jokainen skenaario voi koostua tekijästä, tapahtumaketjusta, reaktiosta tapahtumaan sekä reaktion vaikutuksesta tavoitteisiin. Skenaarioiden tarkoituksena on havainnollistaa mitkä tekijät vaikuttavat erityisesti tähän projektiin, mitä mahdollisia tapahtumia voi sattua, miten tapahtumiin voidaan reagoida ja miten se vaikuttaa tavoitteisiin. Tekijöiden, tapahtumien, reaktioiden ja vaikutusten suhteet havainnoillistetaan diagrammeilla kuten [1]:ssä on kuvattu.

Kun skenaariot on muodostettu asetetaan ne todennäköisyyden ja vakavuuden mukaan tauluun. Saadusta taulusta on helppo havaita ne riskiskenaariot, jotka ovat sekä vakavia, että todennäköisiä. Näille riskiskenaarioille tehdään tarkemi analyysi ja pohditaan toimenpiteitä, joita voidaan tehdä ennen toteutuksen alkua ja vastatoimenpiteitä riskin toteutumisen varalta.

Lopussa on yhteenveto, jossa kerrotaan tärkeimmät analyysissä selvinneet asiat ja parhaimmat tämänhetkiset varasuunnitelmat.

10.2 Tavoitteet

• Projekti valmistuu aikataulussa
• Tehty työmäärä ei ylitä suunnattomasti kurssin tavoitetta
• Valmis tuote vastaa asiakkaan tarpeita, sekä projektiryhmän jäsenten käsitystä hyvästä tuotteesta
• Ryhmän jäsenet oppivat

10.3 Vapaamuotoinen lista mahdollisista riskeistä

• Tehty työ tuhoutuu(laitteisto menee rikki, vahingossa pyyhkiytyy koodia jne.)
• Huomataan, että valittu päätelaite ei olekaan paras vaihtoehto
• GPRS ei sovellu kaavailtuun projektiin
• Java liian hidas päätelaitteille
• Java liian hidas palvelimelle

• Peli liian monimutkainen
• Suunniteltu pelimoottori liian monimutkainen
• Käyttöliittymästä ei saada hyvää päätelaitteelle
• Tehtävän alustan ohjelmointirajapinta on liian vaikeasti käytettävä
• Koko tai osaprojektin epärealistinen aikataulu
• Tehdään liian monipuolinen peli pelimoottorin päälle tai liian paljon ominaisuuksia käyttöliittymään tai liian paljon ominaisuuksia pelimoottoriin
• Liikaa hienosäätöä verrattuna tarpeeseen, yritetään tehdä näyttävämpi tuote kuin mitä asiakas edes haluaisi
• Määrittely muuttuu, ei ehkä ymmärretty alunperinkään
• Ongelmia hankitussa kehitysympäristössä
• Sovelluksen määritellyt vaatimukset teknisesti mahdottomia täyttää valitulla laitteistolla
• Ohjelmointikielten tai alustojen opettelu kestää liian kauan
• Avainhenkilö tulee hulluksi(juha)/lopettaa/lähtee/alkoholisoituu
• Keskinäiset suhteet huonoja, ei välitetä muiden mielipiteistä tai neuvoista

• Keskinäinen kommunikointi huonoa, rajapinnat eroavat, tehdään eri asioita
• Kommunikointi asiakkaan ja kaikkien tai osan projektiin osallistuvien välillä puutteellista
• Ymmärretään asiakkaan vaatimukset väärin
• Hankitaan väärä kehitysympäristö kuin sovittiin
• Työtä ei voida jakaa ja joudutaan odottamaan toimettomana muiden työn valmistumista
• Kriittinen osa myöhästyy ja muut joutuvat odottamaan sen valmistumista
• Suunnitelmasta ei selviä mitä tietyn henkilön tulisi tehdä

10.4 Riskiskenaariot

Yhteenveto riskiskenaarioista:
Skenaario 1:
Avainhenkilö muuttuu työkyvyttömäksi. Joku muu hoitaa henkilön hommat.
Skenaario 2:
Avainhenkilö muuttuu työkyvyttömäksi. Moni muu hoitaa henkilön hommat.
Skenaario 3:
Keskinäiset suhteet huononevat. Pidetään yhteistyöleiri tai yhteistyöpalavereja.
Skenaario 4:
Henkilö tekee tarpeettomasti virheitä. Joku muu hoita henkilön hommat.
Skenaario 5:
Henkilö tekee tarpeettomasti virheitä. Moni muu hoitaa henkilön hommat.
Skenaario 6:
Toinen henkilö tekee erilaisen rajapinnan kuin toinen odottaa. Suunnitellaan kokonaan uusi rajapinta
Skenaario 7:
Toinen henkilö tekee erilaisen rajapinnan kuin toinen odottaa. Valitaan toinen rajapinnoista
Skenaario 8:
Ei voida edetä, koska osa projektista ei ole valmis. Muutetaan toteutussuunnitelmaa
Skenaario 9:
Ei voida edetä, koska osa projektista ei ole valmis. Jätetään osa ominaisuuksista pois
Skenaario 10:
Projekti edistyy kokonaisuutena suunniteltua hitaammin. Jätetään osa ominaisuuksista pois
Skenaario 11:
Projekti edistyy kokonaisuutena suunniteltua hitaammin. Tehdään enemmän töitä.
Skenaario 12:
Määrittely muuttuu. Ei välitetä.
Skenaario 13:
Määrittely muuttuu. Tehdään uudestaan vaadittavat osat.
Skenaario 14:
Opetteluun kuluu todella paljon aikaa. Vaihdetaan kieltä tai muutetaan ympäristöä.
Skenaario 15:
Huomataan, että tarvitaan lisää budjettia hankintoihin. Pyydetään tarvittava lisä asiakkaalta
Skenaario 16:
Laitteisto hajoaa ja tehty työ tuhoutuu. Palautetaan työ varmistuksilta ja hommataan uudet laitteet
Skenaario 17:
Ohjelmointi kestää liian kauan. Vähennetään ominaisuuksia
Skenaario 18:
Ohjelmointi kestää liian kauan. Ei reaktiota
Skenaario 19:
GPRS:llä mahdotonta toteuttaa järjestelmää. Muutetaan vaatimusmäärittelyssä protokolla jo tunnetuksi.
Skenaario 20:
GPRS:llä mahdotonta toteuttaa järjestelmää. Muutetaan vaatimusmäärittelyssä muita järjestelmän osia
Skenaario 21:
Käyttöliittymän teko hidasta. Poistetaan ominaisuuksia.
Skenaario 22:
Palmin teho ei riitä ohjelmiston kelvolliseen pyörittämiseen. Kevennetään ohjelmistoa ja optimoidaan koodia.

Taulukko 1. Skenaariot todennäköisyyksien ja vakavuuden mukaan

	Suurin todennäköisyys	Suuri todennäköisyys	Pieni todennäköisyys	Pienin todennäköisyys
Suurin vakavuusaste			Sk 2
Suuri vakavuusaste			Sk 1, Sk 12, Sk 22	Sk 4, Sk 5
Pieni vakavuusaste		Sk 15	Sk 3
Pienin vakavuusaste			Sk 16

10.5 Toimenpiteet

Valitaan pahimmat uhkat taulukosta 1 ja analysoidaan ne ja muodostetaan varasuunnitelmat riskien toteutumista varten. Sekä tekijään, tapahtumaan, reaktioon, että vaikutukseen vaikuttamista varten esitetään vaihtoehtoja kyseisessä kohdassa. Eli esitetään uhkaavimmat skenaariot, niiden eri osat ja toiminnat ja vaihtoehdot osille. Skenaariot 7, 9, 14 ja 22 vaikuttavat olevan pahimmat riskit:

Tekijät: Henkilöstö, Toteutussuunnitelma
Henkilöstön valitsemista ei enää voi muuttaa, mutta henkilöiden välistä kommunikaatiota voi yrittää parantaa.
Suunnitelmat kannattaa tehdä mahdollisimman tarkoiksi, jotta myöhemmin ei synny ongelmia.
Tapahtuma: Toinen henkilö tekee erilaisen rajapinnan kuin toinen odottaa
Joku voisi tarkkailla toisten ohjelmointia ja suunnittelua, jotta vältytään tältä tilanteelta.
Reaktio: Valitaan toinen rajapinnoista
Toinen reaktio, eli suunnitellaan uusi rajapinta.
Tehdään etukäteen varasuunnitelmia erilaisista rajapinnoista, jolloin päästään nopeammin ratkaisuun.
Vaikutus: Projekti hidastuu vähän ja työmäärä kasvaa vähän
Yritetään oppia tästä seuraavia samanlaisia ongelmia varten projektin edetessä.

Tekijä: Toteutussuunnitelma
Tarkalla suunnittelulla ja töiden osituksella etukäteen vältetään monia ongelmia. Myöskin se, että kaikki lukevat tarkkaan suunnitelmat auttaa asiaa ja se, että kaikki ymmärtävät suunnitelmat samalla tavalla ja tajuavat oman työnsä riippuvaisuuden muiden töistä.
Tapahtuma: Ei voida edetä, koska osa projektista ei ole valmis
Yritetään tehdä asioita, jotka edistävät projektia, vaikka ne ei olekaan suunniteltu tehtäväksi vielä tai yritetään parantaa jo olemassa olevia osia.
Reaktio: Jätetään osa ominaisuuksista pois
Toinen reaktio eli muutetaan suunnitelmia tilanteeseen sopiviksi.
Vaikutus: Tuotteen laatu ei vastaa odotuksia
Yritetään ylläpitää laatua tai parantaa sitä projektin eri osien kautta.

Tekijät: Java ohjelmointikieli, Kehitysympäristö J2SE/ J2Me, linux, Palm
Ohjelmointikielen ja ympäristön valinta on ratkaisevimpia asioita tässä projektissa. Nämä on pakko valita siten, että niiden opettelu ei kestä niin kauan, että projekti viivästyy. Javasta kaikilla henkilöillä on jo kokemuksia ja myös muista kehitysympäristön osista on kokemuksia. Etukäteen voidaan hankkia oppimismateriaalia, kuten kirjoja jne.
Tapahtuma: Opetteluun kuluu todella paljon aikaa
Projektiryhmän jäsenet voivat auttaa toisiaan oppimaan. Suunnitellaan etukäteen mitä ja miten tulee oppia ja välitetään
tämä kaikille ryhmän jäsenille.
Reaktio: Vaihdetaan kieltä tai muutetaan ympäristöä
Kulutetaan enemmän aikaa opiskeluun.
Vaikutus: Tuotteen laatu ei vastaa odotuksia
Yritetään saada uuden vaihtoehdon tuomat edut esiin, jos mahdollista.

Tekijät: Java ohjelmointikieli, J2ME, Palm, ohjelmoinnin tehokkuus
Kalenteri- ja muistiokäyttöön alunperin tarkoitettu Palm ei ole teholtaan lähelläkään pöytäkoneiden luokkaa. Palmin oman käyttöjärjestelmän päällä ajetaan vielä J2ME:tä, jolloin tehokkuus kärsii entisestään. Monen käyttäjän interaktiivinen seikkailupeli ei ole kaikista vähätehoisimpia implementoitavia, joten on olemassa selkeä riski, että lopullinen ohjelmisto ei pyöri hyvin Palmissa.
Tapahtuma: Palm on liian tehoton pyörittämään Monrovia-peliä
Tehdään tehokasta koodia Palmin tarpeet silmälläpitäen. Optimoidaan ankarasti. Suunnitellaan koko järjestelmä mahdollisimman tehokkaaksi Palmin kannalta.
Vaikutus: Pelin pelattavuus on huono tai peli ei toimi ollenkaan
Tältä voi välttyä vain etukäteen asiat huomioimalla.

10.6 Yhteenveto

Kaikista pahimmat riskit liittyvät jollakin tavalla projektin suunnitteluun. Paljon riskejä voidaan eliminoida suunnittelemalla tarkkaan miten eri järjestelmän osat sovitetaan yhteen ja minkälaisessa aikataulussa se tehdään. Ryhmän kommunikoinnista pitää pitää huolta koko projektin ajan, jotta kaikki ovat selvillä tilanteesta ja suunnitelmista. Myöskin etukäteen pitää suunnitella minkälaista oppimateriaalia tarvitaan uusien menetelmien, protokollien tai teknologioiden oppimiseen.

Parhaat varasuunnitelmat kolmelle edellä esitetyille riskeille niiden toteutuessa ovat kuitenkin tässä:

Skenaario 7:
Suunnitellaan uusi rajapinta valmiiden avulla. Yritetään saada käytettyä mahdollisimman paljon valmista koodia.

Skenaario 9:
Järjestellään asiat uudestaan mahdollisuuksien mukaan ja keskitytään olennaiseen ja parannetaan jo olemassa olevaa.

Skenaario 14:
Pidetään opiskeluviikonloppu, jolloin kaikki auttavat toisiaan ja perehtyvät asioihin joita eivät vielä hallitse.

11. Koulutussuunnitelma

11.1 Koulutus kurssin puolelta

Mahdollisuuksien mukaan kaikki ryhmän jäsenet käyvät kaikilla kurssin ylläpidon pitämillä ja järjestämillä luennoilla. Lisäksi projektipäällikkö kävi MS Project -koulutuksessa ja projektipäällikkö sekä suunnitteluryhmän edustajat kävivät Rational Rose -koulutuksessa. Näillä näkymin muuta koulutusta ei kurssin puolelta ole tulossa, mutta muutoksiin reagoidaan jos ja kun niitä ilmenee.

11.2 Ryhmän sisäinen koulutus

Ryhmällä ei ole virallista koulutussunnitelmaa, koska kaikki ryhmän jäsenet osaavat oman aihepiirinsä asiat ammattimaisella tasolla. Koulutus järjestetään tapauskohtaisesti, mikäli tarvetta ilmenee.

11.3 Asiakkaalle tarjottava koulutus

Kuudennen vaiheen aikana järjestetään asiakkaalle koulutustilaisuus asiakkaan valitsemana ajankohtana. Koulutustilaisuudessa selvitetään palvelinohjelmiston asennus, käyttö ja ylläpito, mikäli asiat eivät ole täysin itsestäänselviä. Tilaisuudessa voidaan myös käydä läpi asiakasohjelmistoa, mutta koska eräs sen kriteereistä on käyttöliittymän helppous, lienee koulutus tämän osalta turhaa.

Lähdeluettelo

[1] J. Kontio, The Riskit Method for Software Risk Management, version 1.00, CS-TR- 3782, 1997. Computer Science Technical Reports. University of Maryland. College Park, MD.

Tämän dokumenttipohjan teossa on käytetty Tero Ahteen (TTKK/Ohjelmistotekniikka) projektisuunnitelman mallia.

Liiteluettelo

[A] MS Project -tiedosto