Kokako - projekti
Projektisuunnitelma
Honkonen Tapio
Lamminen Turo
Räsänen Tuomas
Väärämäki Tapio
Versio 1.0
Julkinen
18. huhtikuuta 2006
Jyväskylän Yliopisto
Tietotekniikan Laitos
Jyväskylä
Hyväksyjä |
Päivämäärä |
Allekirjoitus |
Nimenselvennys |
Projektipäällikkö |
___.___.2006 |
|
|
Tilaaja |
___.___.2006 |
|
|
Tilaaja |
___.___.2006 |
|
|
Ohjaaja |
___.___.2006 |
|
|
Tietoa dokumentista
Tekijät:
Dokumentin nimi: Kokako-projekti,
Projektisuunnitelma
Sivumäärä: 27
Tiedosto:
Projektisuunnitelma.doc
Tiivistelmä: Tämä on Jyväskylän
yliopiston tietotekniikan laitoksella toteutettavan Kokako-sovellusprojektin
projektisuunnitelma. Projektisuunnitelma kuluu olennaisena osana projektin
suunnitteluun ja läpivientiin. Suunitelmassa selvitetään projektin läpivientiä,
työkäytänteitä, hallintaa, resursseja ja aikataulutusta.
Avainsanat: ajankäytönseuranta, dokumentointi, ajankäytönsuunnitelma,
resurssit, projektisuunnitelma, sovellusprojekti.
Muutoshistoria
Versio |
Päivämäärä |
Muutokset |
Tekijät |
0.1 |
13.2.2006 |
Alustavan
ajankäyttösuunnitelman laatiminen alkoi. |
Honkonen Tapio |
0.12 |
15.2.2006 |
Alustavan
ajankäyttösuunnitelman laatiminen jatkui. |
Honkonen Tapio |
0.14 |
17.2.2006 |
Ajankäyttösuunnitelman
viimeistely. |
Honkonen Tapio |
0.16 |
22.2.2006 |
Gantt-kaavion
laadinta alkoi. |
Honkonen Tapio |
0.18 |
23.2.2006 |
Gantt-kaavion
laadinta jatkui. |
Honkonen Tapio |
0.19 |
23.2.2006 |
Gantt-kaavion
viimeistely. |
Honkonen Tapio |
0.2 |
1.3.2006 |
Projektisuunnitelman
kirjoittaminen alkoi. |
Honkonen Tapio |
0.25 |
2.3.2006 |
Projektisuunnitelman
kirjoittaminen jatkui |
Honkonen Tapio |
0.3 |
3.3.2006 |
Projektisuunnitelma
viimeisteltiin ensimmäiseen tarkastukseen. |
Honkonen Tapio |
0.35 |
7.3.2006 |
Projektisuunnitelman
korjaus aloitettiin ensimmäisen tarkastuskierroksen kommenttien mukaan. |
Honkonen Tapio |
0.4 |
8.3.2006 |
Projektisuunnitelma
korjattiin ensimmäisen tarkastuskierroksien kommenttien mukaan ja
toimitettiin tarkastukseen. |
Honkonen Tapio |
0.42 |
10.3.2006 |
Projektisuunnitelman
korjaus aloitettiin toisen tarkastuksen kommenttien mukaan. |
Honkonen Tapio |
0.45 |
13.3.2006 |
Projektisuunnitelman
korjaus jatkui toisen tarkastuksen kommenttien mukaan ja se toimitettiin
tarkastukseen. |
Honkonen Tapio |
0.5 |
14.3.2006 |
Projektisuunnitelma
viimeisteltiin ja toimitettiin yleiseen tarkasteluun. |
Honkonen Tapio |
0.9 |
22.3.2006 |
Projektisuunnitelma
viimeisteltiin asiakkaan antamien kommenttien mukaan. |
Honkonen Tapio |
0.95 |
27.3.2006 |
Projektisuunnitelma
viimeisteltiin allekirjoitusta varten. |
Honkonen Tapio |
1.0 |
28.3.2006 |
Projektisuunnitelma
allekirjoitettiin |
|
Tietoa projektista
Kokako-projekti jatkaa
opinto-oppaan XML-pohjaisen monikanavajulkaisujärjestelmän kehittämistä Jyväskylän
yliopiston Informaatioteknologian tiedekunnalle. Julkaisujärjestelmää on
tarkoitus kehittää helppokäyttöisemmäksi ja yleisemmäksi niin, että sitä voisi
mahdollisesti käyttää vastaaviin tarkoituksiin esimerkiksi muissa tiedekunnissa.
Ensisijaisesti on tarkoitus toteuttaa ympäristö opinto-oppaaseen tulevien
XML-dokumenttien laadintaan ja muokkaukseen Xoo-projektin laatiman luku.dtd:n mukaisiksi dokumenteiksi. Tämän jälkeen
on tarkoitus toteuttaa olemassa olevaan koostamistyökaluun helppokäyttöisempi
käyttöliittymä sekä dokumenttien käsittelyssä tarvittava versionhallinta
Tekijät:
Tilaaja:
·
Ihanainen Eija opintoasiat@it.jyu.fi 014 260 2791
·
Auer
Antti auer@jyu.fi 014 260
4319
·
Honkaranta Anne anne.honkaranta@it.jyu.fi 050 357 3002
·
Nurminen Miika minurmin@jyu.fi 014 260 2530
·
Lappalainen Vesa vesal@mit.jyu.fi 014 260 2722
Ohjaajat:
Yhteystiedot:
kokako_opis.group@korppi.jyu.fi
https://korppi.jyu.fi/list-archive/kokako06_opetus
Sisältö
2 Projektiin liittyvä termistö
3.3 Kokako-projektin lähtökohdat
4.3 Suunnittelu- sekä raportointidokumentit
4.3.4 Palaverien pöytäkirjat, projekti- ja
sovellusraportti
4.4 Projektiryhmän oppimistavoitteet
5.1 Projektin henkilöt ja yhteystiedot
5.2 Työtilat, laitteet, ohjelmistot ja tuki
6 Tehtävät, työmäärät ja työnjako
6.3 Projektin jäsenten tehtävät.
7 Riskit, niiden seuranta ja hallinta
7.1 Projektin vaatimusten epätarkkuus
7.3 Projektin lähtökohtiin perehdyttämisen puute
7.7 Versionhallinnan puutteellinen käyttö
7.9 Käytettävien työkalujen sopimattomuus
Kuvaluettelo
Kuva 3: Gantt-kaavio projektin
aikataulusta
Taulukkoluettelo
Taulukko
1: Projektiryhmän yhteystiedot
Taulukko
2: Ohjaajien yhteystiedot
Taulukko
3: Tilaajan edustajien yhteystiedot
Taulukko
4: Projektiin kohdistuvat riskit
Kokako-projekti
on kevään -06 Jyväskylän yliopiston tietotekniikan laitoksen sovellusprojekti.
Projekti kehittää opinto-oppaan laatimis- ja koostamistyökalua Jyväskylän yliopiston
informaatioteknologian tiedekunnalle. Työkalusta on tarkoitus laatia niin
yleis- ja helppokäyttöinen, että sitä on mahdollista käyttää vastaaviin
tarkoituksiin esimerkiksi muissa tiedekunnissa. Sitä tulee käyttämään kaksi eri
käyttäjäryhmää, dokumentin sisällöntuottaja ja koostaja. Työkalun tarkoituksena
on tehdä lähdedokumenteista yhtenäisiä, ja täten helpottaa koostajan työtä
automatisoimalla koostamisprosessia.
Kokako-projekti
on jatkoa XooZoo- ja Xoo-projekteille. XooZoo-projektin tehtävänä oli
IT-tiedekunnan opinto-oppaan hallinnan, sisällön ja rakenteen kehittäminen.
Projekti keskittyi tutkimukseen ja suunnitteluun. Käytännön toteutukselle jäi vähemmän
aikaa, ja niinpä projekti jatkui Xoo-jatko-projektilla, jonka tehtävänä oli
viedä XooZoo-projektissa aloitettu työ loppuun.
Xoo-projekti
koosti IT-tiedekunnalle opinto-oppaan XooZoo-projektissa saatujen tuloksien
pohjalta. Koostamistyössä havaittiin kuitenkin vielä useita puutteita, joista
halutaan eroon. Nyt Kokako-projektin tehtävänä on jatkaa koostamisjärjestelmän
kehittämistä edelleen.
Kokako-projektin
kesto on neljä kuukautta, ja se on valmis viimeistään 31.5.2006. Ensisijaisesti
on tarkoitus toteuttaa ympäristö opinto-oppaaseen tulevien XML-dokumenttien
laadintaan XooZoo-projektin laatiman luku.dtd-määrityksen mukaiseksi. Tämän jälkeen on tarkoitus toteuttaa
olemassa olevaan koostamistyökaluun helppokäyttöisempi käyttöliittymä sekä
dokumenttien käsittelyyn tarvittava versionhallinta.
Tässä luvussa kuvataan
projektisuunnitelmassa esille tulleita termejä.
XML (eXtensible Markup Language |
on metakieli,
jolla määritellään rakenteisia merkkauskieliä. XML- ja HTML-merkkauskielten
erona on se, että HTML-merkkauskielessä käytetään ennalta määriteltyjä
merkkaustunnisteita, kun taas XML-merkkauskielen dokumenteille voi laatia
sovellus- ja aihekohtaisia omia merkkauskieliä skeemamääritystä käyttäen. XML
siis tarjoaa syntaksin ja merkkaussäännöt, joiden pohjalta voidaan määritellä
omia merkkauskieliä. |
DTD (Document Type
Definition) |
Määrittää rakenteisen dokumentin skeeman. Tämän avulla XML-prosessorille
kerrotaan mitä elementtejä ja attribuutteja dokumentti saa sisältää, missä järjestyksessä ne saavat
ilmetä ja mitkä ovat niiden keskinäiset suhteet. |
Luku.dtd |
on opinto-oppaan koostamistyökalun käyttämä DTD. Tämä on opinto-oppaan
tekstilukujen käyttämä DTD-määritys. (Opinto-oppaan koostaminen perustuu
kooste.dtd-määritykseen). |
OpenOffice 2.0 |
on Microsoft Officen kaltainen ohjelma, josta löytyy hyvin pitkälti samat
ominaisuudet. OpenOfficea on tarkoitus käyttää dokumenttien tuottamis- ja
muokkausohjelmana opinto-oppaan tuottamisprosessissa. |
XSLT (Extensible Style Language and Transformations) |
on laajasti käytetty XML-dokumenttin
muunnoskieli. Tyypillisiä XSLT:n sovelluskohteita ovat XML-aineiston muunnokset
toiseen XML-merkkauskielen mukaiseksi, HTML-muotoon tai tekstiksi. |
|
|
Tässä luvussa
selvitetään, mitkä ovat Kokako-projektin lähtökohdat. Lisäksi luvussa kuvataan
projektin taustaa, kuten tätä projektia edeltäneitä XooZoo- ja Xoo-projekteja.
XooZoo-projektin
tarkoituksena oli kartoittaa IT-tiedekunnan opiskelijoiden mielipiteitä opinto-oppaasta,
selvittää oppaan laadintaprosessin ongelmakohdat ja esittää niihin parannusehdotuksia.
Lisäksi, mikä tämän tutkimuksen kannalta on tärkeintä, projektin tehtävänä oli
laatia alustavat XML-määritykset opinto-oppaan laadintaprosessin teknologiaperustaksi
sekä oppaan monikanavajulkaisun tueksi.
XooZoo-projektin
jälkeen kehittämistyötä jatkoi tiedekunnan yhteinen työryhmä. Jatkokehittäminen
tarkoitti käytännössä IT-tiedekunnan lukuvuoden 2005–2006 opinto-oppaiden
tuottamista XooZoo-projektin tuotosten pohjalta, koostamista ja monikanavajulkaisua
XML-kielen ja XooZoo-projektissa luotujen DTD:n avulla sekä opinto-oppaiden
uuden julkaisujärjestelmän rakentamista, pilotointia, testausta ja
dokumentointia.
Projektin
lähtökohtana on lähteä kehittämään edelleen XooZoo- ja Xoo-projektien tuotoksia.
Korkein prioriteetti on luoda yhtenäinen tuottamisympäristö opinto-oppaan
dokumenteille ja niiden muuntaminen Xoo-projektin luoman koostamisohjelman
typpimääritysten mukaiseksi. Tämän lisäksi tuottamisprosessiin lisätään versionhallinta.
Lisäksi tarkoitus on luoda graafinen käyttöliittymä kyseiseen
koostamisohjelmaan ja versionhallintaan tai sitten käyttää olemassa olevia
työkaluja. Tarvittavien työkalujen selvittäminen on myös projektin vastuulla.
Tässä luvussa
kuvataan projektin tavoitteita osa-alueittain liittyen julkaisuprosessiin, ohjelmistoihin,
projektin dokumentteihin ja projektiryhmän tavoitteisiin.
Kuva 1 esittää
miten opinto-oppaan julkaisuprosessi etenee. Projektin tavoitteet ovat jäsennettävissä
tämän kuvauksen perusteella.
Kuva 1: Julkaisuprosessi
Tavoitteena on
saada aikaan helppokäyttöinen dokumenttien luomisympäristö, jossa voi luoda ja
muokata opinto-oppaan dokumentteja. Itse XML-merkkaus ja XSLT-muunnokset eivät
näy käyttäjälle ollenkaan, vaan käyttäjä ainoastaan tuottaa sisältötekstiä
ohjelman dokumenttipohjaan määrteltyjä tyylejä käyttäen. Sisällöntuottajan
laatimasta OpenOffice-dokumentista muunnetaan XSLT-muunnoksia käyttäen luku.dtd:n mukainen XML-dokumentti. Toisin sanoen
loppukäyttäjät /sisällöntuottajat voivat luoda uusia ja muokata vanhoja
opinto-opas dokumentteja. Lisäksi käyttöön otetaan mukaan versionhallinta.
Versionhallinnan
tarkoitus suojata dokumentteja samanaikaisilta muutoksilta, tallentaa dokumenttien
elinkaaren aikaiset tekstimuutokset mahdollista palautustarvetta varten, sekä
antaa tietoa dokumenttien elinkaaren tilasta ja valmiusasteesta; onko dokumentti
esimerkiksi vasta luonnosasteella, vai jo valmis julkaistavaksi. Versionhallinnan
avulla voidaan siis palauttaa voimaan vanhempi versio dokumentista.
Tarkoituksena siis päästä eroon mahdollisuudesta, että jo tehtyjä dokumentteja
tai osia niistä katoaisi. Versionhallinnasta selviää missä vaiheessa dokumentin
tuotanto on, eli onko se keskeneräinen vai valmis koosteeseen. Kyseisen versionhallinnan
käyttöliittymässä on myös kiinnitettävä huomiota sen helppokäyttöisyyteen,
koska dokumenttien tuottajat eivät todennäköisesti tunne järjestelmän
toimintaperiaatteita. Version- ja dokumenttien hallintaan kehitetään mahdollisesti
käyttöliittymä, joka on myös osa koostamissovelluksen käyttöliittymään.
Tällä hetkellä
olemassa olevaan koostamistyökaluun on tavoitteena luoda helppokäyttöinen
graafinen käyttöliittymä, tai sisällyttää se johonkin olemassa olevaan
koostamistyökaluun. Koostamistyökalun on tarkoitus olla käytössä vain hyvin
rajatulle käyttäjäryhmälle, joka ymmärtää koostamisen toiminnan ja koostaa
opinto-oppaan julkaisua varten.
Seuraavassa
kuvataan ohjelmistojen testauksen ja integroinnin tavoitteita.
Projektin
loppuvaiheessa tavoitteena on integroida sovelluksen osat toimimaan kokonaisuutena.
Projektin vaiheet jakautuvat siten, että ensiksi toteutetaan OpenOfficeen
asiakirjamalli, jota käytetään dokumenttien laadinnassa ja muokkaamisessa, sekä
XSLT-muunnokset OpenOffice-formaatissa olevista dokumenteista luku.dtd:n mukaisiksi XML-dokumenteiksi. Tämän
jälkeen on vuorossa koostamistyökalun graafinen käyttöliittymä ja versionhallinta
sekä sen käyttöliittymä. Nämä käyttöliittymät todennäköisesti yhdistetään
yhdeksi käyttöliittymäksi, johon eri käyttäjäryhmillä on erilaiset käyttöoikeudet.
Lopuksi näiden toiminta integroidaan keskenään. Pyrkimyksenä on ottaa huomioon
jo toteutusvaiheessa mahdolliset integrointiin liittyvät ongelmat.
Testauksen
tavoitteena on varmistaa, että oppaan laatimisprosessi sisällön tuottamisesta
julkaisuun asti toimii. Lisäksi tarkistetaan, että on otettu tarvittavat
käyttöön liittyvät asiat huomioon.
Nämä dokumentit
kuvaavat projektin suunnittelua ja läpivientiä. Osa dokumenteista on
suunnitteludokumentteja ja osa raportointidokumentteja.
Projektisuunnitelmassa
kuvataan projektin käytänteitä ja se toimii suunnitteludokumenttina projektin
läpiviennissä. Se sisältää kuvauksen projektin luonteesta, sen tavoitteista ja
käytänteistä. Lisäksi siihen sisältyvät aikataulusuunnitelmat ja työnjako projektiryhmän
kesken. Suunnitelmasta ilmenevät myös projektin käytettävissä olevat resurssit.
Vaatimusmäärittelyssä
kuvataan ne vaatimukset, mitä järjestelmän eri osilla on, sekä toiminta
yleisellä tasolla. Lisäksi siinä kuvataan kyseisen opinto-oppaan
koostamisprosessi prosessi- ja käyttötapauskuvausten avulla. Vaatimusmäärittely
hahmottaa projektiryhmälle vaatimuksen, joiden perusteella lähdetään
suunnittelemaan ja toteuttamaan sovellusta. Sen pohjalta toteutetaan
sovellussuunnitelmaa.
Sovellussuunnitelma
kuvaa, miten tilaajan kanssa määritellyt vaatimukset toteutetaan ja mitä
työkaluja käytetään. Lisäksi se kuvaa myös minkälaisista teknisistä osista
tuotettava sovellus koostuu ja miten ne toteutetaan. Sovellussuunnitelma
laaditaan vaatimusmäärittelyn perusteella, jotta sovellus tulisi olemaan
vaatimusten mukainen.
Palaverin
pöytäkirjoista selviää, miten projekti on edennyt ja mitä päätöksiä on tehty.
Projekti- ja sovellusraportti kuvaavat, miten projektin eri osa-alueet ovat
toteutuneet edellä mainittuihin suunnitelmiin verrattuna.
Ryhmän
tavoitteena on hankkia kokemusta projektiryhmässä toimimisesta sekä erilaisista
tehtävistä sen sisällä. Kurinalaisen työskentelyn ja ajanhallinnan taidon
kehittäminen on oleellinen osa projektia. Virallisten dokumenttien kirjoitusasu
ja tyyli ovat myös yksi oppimistavoitteista. Lisäksi XML-kielen opettelu ja sen
käyttö on yleissivistävää ja hyödyllistä. Projektin yhteydessä käytettävät
apuohjelmat, kuten CVS ja Bugzilla, ovat hyödyllisiä ja yleiskäyttöisiä
ohjelmia, joita myös hyödynnetään mahdollisesti monen muunkin projektin
yhteydessä. Projektin aikana tehtävä käyttöliittymän suunnittelu ja toteutus antaa
näkökulmia käytettävyyteen ja asioihin, mitä käytettävyydessä tulee ottaa
huomioon. Myös projektiin liittyvät tekijänoikeuskeskustelut antavat mallia,
miten tällaiset asiat tulisi hoitaa. Nämä kaikki seikat antavat hyviä vinkkejä
ja lähtökohtia työelämään astuttaessa.
Luvussa kuvataan
projektiorganisaatio ja projektin käytössä olevat resurssit.
Seuraavista
kohdista selviävät projektiin liittyvät henkilöt ja heidän yhteystietonsa.
Ryhmän jäseniä
ovat
Ryhmän jäsenten
yhteystiedot on kuvattu taulukossa 1.
Nimi |
Sähköposti |
Puhelin |
Honkonen Tapio |
040 762
9083 |
|
Lamminen Turo |
0400 340 766 |
|
Räsänen Tuomas |
040 777
4149 |
|
Väärämäki Tapio |
044 078 0780 |
Taulukko 1: Projektiryhmän yhteystiedot
Projektia
ohjaavat
·
Korhonen
Vesa, yliopistonopettaja, vastaava ohjaaja
·
Suomalainen
Matti, tekninen ohjaaja
Ohjaajien
yhteystiedot ovat kuvattu taulukossa 2.
Nimi |
Sähköposti |
Puhelin |
Korhonen Vesa |
014 260
4976 |
|
Suomalainen
Matti |
044 321 4236 |
Taulukko 2: Ohjaajien yhteystiedot
Tilaajan
edustajina toimivat
Tilaajan
edustajien yhteystiedot on kuvattu taulukossa 3.
Nimi |
Sähköposti |
Puhelin |
Ihanainen Eija |
014 260
2791 |
|
Auer Antti |
014 260
4319 |
|
Honkaranta Anne |
014 260
3041 |
|
Nurminen Miika |
014 260
2530 |
|
Lappalainen
Vesa |
014 260 2722 |
Taulukko 3: Tilaajan edustajien yhteystiedot
Jyväskylän
yliopiston tietotekniikan laitos on luovuttanut projektiryhmän käyttöön lukittavan
huoneen AgC223.3. Kyseisestä tilasta löytyy kolme Windows XP SP2- ja yksi
Linux- käyttöjärjestelmällä varustettua tietokonetta. Lisäksi yhteen tietokoneeseen
on asennettu MS Project 2000-, Oxygen 7.1- ja Altova XMLSpy prof 2004-ohjelmisto.
Muut mahdollisesti projektin tarvitsemat ohjelmistot projektiryhmä saa
Informaatioteknologian tiedekunnan ATK-tuen kautta, joka toimii myös projektin
ATK-tukena. Lisäksi ryhmällä on käytössä tarvittaessa tietotekniikan laitoksen
sovellusprojektien MiniDisc-tallennin, digitaalikamera, digitaalisanelin, 2
kannettavaa tietokonetta, videoprojektori, kopiokone, kokoustila (AgC223.1)
sekä projektitiloista löytyvät tulostin, tee- ja kahvinkeitin.
Sovellusprojektien
käytännön perehdytykset hoitaa tietotekniikan laitos sovellusprojektien
oheiskurssin muodossa. Projektiryhmän perehdytyksen olemassa olevaan opinto-oppaan
koostamisohjelmaan hoitaa Miika Nurminen ja XML- sekä XSLT-perehdytykset hoitaa
Anne Honkaranta.
Kuva 2 kuvaa ryhmän jäsenten vastuualueet sekä
suunnitellun ajankäytön. Tehtävät on jaettu tehtäväkokonaisuuksiin.
Kuva 2: Ajankäyttösuunnitelma
Kuva 3 kuvaa projektin aikataulua ja miten kukin
osio kuormittaa ryhmän jäseniä. Projektin aikataulusta selviää sovitut päivämäärät,
milloin tietyt osiot ovat valmiina. Projektisuunnitelma on asiakkaan
tarkastettavana 14.3.2006 ja sovellussuunnitelma 26.4.2006. Itse sovellus on
valmiina 15.5.2006.
Kuva 3: Gantt-kaavio projektin aikataulusta
Projektin jäsenten
tehtävät jakautuvat karkeasti jaoteltuina seuraavasti: Tapio Honkonen toimii
projektipäällikkönä ja hoitaa asiaan kuuluvat suunnittelut sekä projektin
seurannan. Hän osallistuu myös XSLT:n liittyviin suunnittelu- ja toteutustehtäviin.
Tapio Väärämäki hoitaa suurimman osan projektin dokumentoinnista ja osallistuu
myös toteutusvaiheen tehtäviin. Turo Lamminen ja Tuomas Räsänen kantavat
päävastuun järjestelmän suunnittelusta ja toteutuksesta. Tarkemmin työjako
selviää kuvasta 2, jossa on yksityiskohtaisesti kuvattu, mikä on kunkin ryhmän
jäsenen vastuualue. Näiden tehtävien sijoittuminen kalenteriajan suhteen
selviää kuvasta 3, josta myös ilmenee kunkin jäsenen kuormitus projektin
läpiviennin aikana.
Luvussa
esitellään projektin edetessä eteen tulevia riskejä, miten niihin reagoidaan, sekä
mitä toimia ja käytänteitä käytetään niiden ehkäisemiseksi.
Taulukko 4 kuvaa
projektiin kohdistuvia riskejä.
Riski |
Todennäköisyys |
Haitta |
Projektin
vaatimusten epätarkkuus |
Keskinkertainen |
Keskinkertainen |
Projektikokemuksen
puute |
Korkea |
Matala |
Projektin lähtökohtiin
perehdyttämisen puute |
Matala |
Korkea |
Viestinnän
ongelmat |
Matala |
Keskinkertainen |
Dokumentoinnin
puute |
Matala |
Korkea |
Laitteistoviat |
Matala |
Korkea |
Versionhallinnan
puutteellinen käyttö |
Matala |
Keskinkertainen |
Integrointiongelmat |
Keskinkertainen |
Keskinkertainen |
Käytettävien
työkalujen sopimattomuus |
Matala |
Korkea |
Ohjauksen puute |
Keskinkertainen |
Korkea |
Sairastuminen |
Pieni |
Keskinkertainen |
Taulukko 4: Projektiin kohdistuvat riskit
Vaatimusmäärittely
on oleellinen osa projektin käynnistystä ja sitä miten projekti etenee. Riskin toteutuminen pyritään estämään ja
hallinnoimaan tekemällä mahdollisimman tarkka vaatimusmäärittely asiakkaan
kanssa. Projektin luonteen vuoksi on myös syytä ottaa huomioon mitkä asiat ovat
prioriteetiltaan korkeimmat, jolloin voidaan tehdä tärkeimmät osa-alueet
ensiksi valmiiksi. Jos riski toteutuu, kutsutaan koolle palaveri asiakkaan
kanssa mahdollisimman nopeasti ja keskustellaan kyseisestä vaatimuksesta.
Riskin toteutuminen tulee ilmi erimielisyyksinä asiakkaan kanssa toteutukseen
liittyvistä asioista.
Suurimmalle
osalle ryhmän jäsenistä projektiluontoinen työskentely on uutta, mikä voi aiheuttaa
ongelmia projektin sisäisen työnjaon ja työskentelyn suhteen. Myös käytännön hallinnointi
voi tuottaa hankaluuksia kokemuksen puutteen vuoksi. Kyseisen riskin toteutumisen
huomaa, jos projektiryhmä ei tahdo saada mitään aikaiseksi. Tämä riski tuskin
toteutuu, koska ryhmä on motivoitunut projektiin ja näin ollen kaikki uudet
asiat ovat haasteita ja opettelun arvoisia. Hallinnollisesti myös hyvin laaditut
projektin suunnitteludokumentit auttavat hallitsemaan ja ehkäisemään ongelmatapauksia.
Riskin uhatessa pyydetään projektin ohjaajilta lisää ohjausta käytännön
asioissa.
Projektin on
kahden edellisen projektin jatkoprojekti, joten tämä tuo tullessaan haasteita
niin projektiryhmälle kuin asiakkaalle. Ongelmaksi voi osoittautua vanhan
järjestelmän tietämyksen siirto projektiryhmälle asiakkaan asiantuntijoilta.
Riskin toteutumisen mahdollisuus on pieni, koska asiakkaan tekninen tuki on helposti
saatavilla aiempiin projekteihin ja olemassa olevaan työkaluun liittyen. Tämän
riskin havaitsee, jos edellisen sovelluksen tulkinnassa on ongelmia ja syntyy
paljon väärinkäsityksiä. Jos tämä toteutuu, otetaan välittömästi yhteyttä
asiakkaan tekniseen neuvontaan ja pyydetään heiltä lisää perehdytystä.
Projektin
viestinnän ongelmia saattaa syntyä projektiryhmän päällekkäisten kurssien vuoksi
sekä töissä olevien tilaajan edustajien kiireiden vuoksi. Näitä ongelmia
pyrimme ehkäisemään laittamalla dokumentoinnit projektin Internet-sivuille,
josta ne voi lukea mihin aikaan tahansa. Myös palaverien ajankohdat pyritään
suunnittelemaan niin, että mahdollisimman moni pääsee paikalle, mielellään
kaikki. Lisäksi projektin kommunikointiin käytetään sille luotuja
sähköpostilistoja, joiden kautta tieto kulkee kaikille. Jos projektin jäsenet
eivät ole tietoisia, mitä projektissa tapahtuu, se on merkki tämän riskin
uhasta. Riskin toteutuessa lisätään tiedotusta listoilla ja palavereissa.
Dokumentoinnin
puute hankaloittaa projektin läpiviemistä ja lisäksi aiheuttaa suuria ongelmia
mahdollisille jatkoprojekteille. Niinpä pyrimme pitämään dokumentoinnin ja koodin
kommentoinnin mahdollisimman selkeänä ja tarkkana, jolloin säästytään
ylimääräiseltä työltä myöhemmin. Etenkin projektin läpiviennin aikana pyrimme
tekemään raportteja kustakin vaiheesta ja sen läpiviennistä. Dokumentoinnin
puutteen uhkaa on vaikea huomata, koska se vaikuttaa kaikkiin projektin
osa-alueisiin. Uhan toteutuessa ja kun se on huomattu, tehdään dokumentointia
tarkemmin ja korjataan olemassa olevia dokumentteja.
Laitteissa
ilmenevät tekniset viat saattavat aiheuttaa tiedon katoamista ja näin ollen
pilata jopa viikkojen mittaisen työn. Tämä riski on olemassa koko projektin
ajan ja näin ollen siihen on varauduttava koko ajan. Tämä tapahtuu käyttämällä
versionhallintaa oikein ja varmistamalla, että tärkeät dokumentit ovat kunnolla
tallessa. Lisäksi projektin käytössä oleva verkkolevy on nauhavarmistettu,
jotta levyrikon tapahtuessa eivät katoaisi kuin viimeisimmät versiot. Riskin
ilmenemismuotoja ovat esimerkiksi verkkolevyn katoaminen, koneen kaatuilu,
koneen käynnistysongelmat ja verkkoyhteyksien katoaminen.
Jos
versionhallintaa ei käytetä kunnolla projektin aikana, se saattaa aiheuttaa
yllättävän suuria ongelmia. Versionhallinnan käyttö on läheisessä suhteessa
laitteistovikoihin, joihin liittyviä riskejä esiteltiin edellä. Lisäksi
käyttäjien virheistä toipumiseen voidaan käyttää versionhallintaa, esimerkiksi
kun halutaan palauttaa jokin aiempi dokumentti. CVS-palvelimella tiedot pysyvät
tallessa ja niistä on versiohistoria, josta näkyy mitä muutoksia ja milloin
muutokset on tehty. Näiden perusteella voidaan palauttaa voimaan mikä versio
tahansa. Tämän riskin uhatessa pyritään versionhallinnan käyttöä tehostamaan ja
laittamaan versionhallinnan ulkopuolella olevat tärkeät dokumentit sinne.
Projekti on
jaettu näennäisesti kolmeen osaan, OpenOffice ja XSLT-muunnokset, versionhallinta
sekä käyttöliittymä ja testaus. Yhteensopivuusongelmia voi tulla integroidessa
olemassa olevaa järjestelmää siihen tehtyyn käyttöliittymään ja tästä edelleen
itse tuottamistyökaluihin. Tämä ongelma voi tulla vastaan aika myöhäisessä
vaiheessa projektia ja sitä pyritään ehkäisemään ottamalla mahdollisia
kriittisiä kohtia huomioon tuotettaessa eri komponentteja. Integrointiongelmien
haitat kasvavat mahdollisesti suuriksi, jos ne ilmenevät ihan projektin
loppuvaiheessa, jolloin on muutenkin kiire.
Tämä ongelma kohdistuu
lähinnä työkaluihin, joita muokataan tuottamis- ja koostamisprosessia varten.
Jokin yhteensopivuusongelma voi tulla vastaan vasta hyvin myöhäisessä vaiheessa
kyseisen työkalun muokkaamista tehtävään sopivaksi. Tämä pyritään ehkäisemään
tutkimalla ja testaamalla työkalua ennen sen muokkaamiseen ryhtymistä. Riskin
ilmetessä tehdään vaatimusten priorisointi uudelleen resurssien mukaan.
Projektiin kuuluu
paljon uusiin työkaluihin, ohjelmistoihin ja kieliin tutustumista. Jos näihin
ei saada kunnon perehdytystä, se hidastaa projektin etenemistä huomattavasti.
Riski ei todennäköisesti toteudu johtuen asiakkaan ja ohjaajien valmiudesta perehdyttää
ryhmää mainittuihin alueisiin. Jonkun ohjaajan poissa ollessa käännytään toisen
ohjaajan puoleen, jolla voisi olla kokemusta aihealueesta. Mikäli yhteisiä
palaveriaikoja ei löydy, niin ohjaus yritetään järjestää sähköpostikeskusteluilla
tai esimerkeillä ongelmista.
Ryhmän jäsenet
voivat sairastua tai joutua onnettomuuteen projektin läpiviennin aikana, mikä
voi aiheuttaa pitkiä poissaoloja ja johtaa projektin työpanoksen pienenemisen.
Riskiä voidaan ehkäistä projektiryhmän hyvällä sisäisellä kommunikaatiolla ja
työnjaolla. Näin mahdolliset poissaolot eivät välttämättä aiheuta selkeää
viivästymistä projektin läpiviennissä.
Tämä luku kuvaa
projektin käytänteitä ja läpivientiä palaverien, dokumentaatioiden ja tiedostojen
osalta.
Tässä osiossa
selviävät projektin yleiset hallintakäytänteet liittyen ajankäyttöön, dokumentointiin
ja tiedostoihin.
Projektipäällikkö
määrittelee ja suunnittelee ryhmän ajankäytön MS Project-aikataulunhallintaohjelmalla.
Jos asiakkaalle esitettyyn suunnitelmaan tulee muutoksia projektin edetessä,
niistä keskustellaan palavereissa asiakkaan kanssa.
Projektiryhmällä
on käytössä oma kotihakemisto, johon luodaan jokaiselle yksi henkilökohtainen
hakemisto. Tämän lisäksi luodaan yksi yhteinen hakemisto, joka sisältää projektia
koskevat ohjeet, esimerkit sekä ajankäytönseurantaan liittyvät dokumentit.
Lisäksi projekti käyttää CVS-versionhallintajärjestelmää, johon luodaan
seuraavat hakemistot: dokumentit, softa, webbisivut. Näistä
dokumentit-hakemisto sisältää kaikki projektiin liittyvät dokumentoinnit
poislukien pöytäkirjat ja esityslistat, jotka löytyvät webbisivut-hakemistosta
itse sivujen lisäksi. Webbisivut-hakemisto sisältää alihakemiston tiedostot,
josta löytyvät projektin julkaisemat dokumentit. Softa-hakemisto sisältää
kaikki tuotetut lähdekoodit ja skriptit.
Dokumentoinneissa
käytetään Microsoft Office-ohjelmistoa, jolloin saadaan yhtenäinen ulkoasu
dokumenteille. Dokumenttien kielenä on Suomi. Yli version 0.5 ylittävät dokumentit
laitetaan projektin kotisivuille näkyviin ja luettavaksi. Tärkeimpien
dokumenttien tarkastuksessa käytetään hyväksi iteraatiomallia. Dokumentit
lähetetään ohjaajille ensiksi luettavaksi ja heidän palautteidensa mukaan
tehdään tarvittavat muutokset. Version 0.9 dokumenttia ehdotetaan kaikkien
osapuolten hyväksyttäväksi. Dokumentin hyväksymisen jälkeen dokumentti
allekirjoitetaan ja versio on 1.0. Alustavasti kaikki ryhmän laatimat dokumentit
ovat julkisia, ellei asiakas toisin halua jonkin yksittäisen dokumentin
kohdalta.
Laadittavat
dokumentit ovat:
Allekirjoitettavat |
Muut |
|
|
Koko projektin
tiedotuskanavana toimii sähköpostilista kokako06@korppi.jyu.fi,
jonka kautta lähetetään linkit, joiden takaa löytyvät esityslistat, pöytäkirjat
ja muut yleiset dokumentit. Kyseiset dokumentit ja muu projektiin liittyvä
materiaali löytyy siis projektin kotisivuilta http://sovellusprojektit.it.jyu.fi/kokako.
Ryhmä käyttää sisäiseen kommunikoitiin kokako_opis.group@korppi.jyu.fi
sähköpostilistaa. Lisäksi on olemassa sähköpostilista kokako06_opetus@korppi.jyu.fi,
jonka kautta kommunikointi ohjaajien kanssa tapahtuu. Lisäksi projektipäällikkö
tiedottaa viikkopalavereissa yleiset projektin läpivientiin liittyvät asiat,
jollei niistä ole sähköpostin kautta tiedotettu.
Palaverit
tilaajan edustajien kanssa pyritään pitämään projektin alku- ja viimeistelyvaiheessa
joka viikko. Projektin keskivaiheilla mietitään mikä on tarpeellinen palaverien
lukumäärä ja aikaväli. Oletusajankohta palavereille on tiistai klo 10-12 jollei
muuten sovita. Palavereissa käsitellään projektin etenemistä ja ajankäyttöä
projektipäällikön raportin osuudessa, sekä muita yksittäisiä asioita omissa
esityslistan kohdissaan; esimerkiksi OpenOffice, XSLT. Palavereissa sovitaan
ryhmän seuraavat tehtävät tai jatkuvat tehtävät sekä sovitaan seuraavan
palaverin ajankohta. Lisäksi palaverin alussa tarkastetaan edellisten kokousten
pöytäkirjat sekä mahdollisesti hyväksytään ne. Palaverien esityslistat lähetetään
viimeistään palaveria edeltävänä päivänä ennen klo 14.00.
Projektipäällikkö
raportoi projektin etenemisestä viikkopalavereissa. Hän esittelee ajankäyttöseurannan
sekä muut mahdolliset dokumentit, jotka on koostanut jokaisen ryhmäläisen
erillisestä raportista. Lisäksi jokaisesta osa-alueesta vastaava esittelee
kyseisen osa-alueen etenemisen erikseen omissa esityslistan kohdissaan, joissa
myös tarkastetaan tehtävien toteutuminen.
Järjestelmän
toteutettua koodia voidaan tarkastella sekä ohjaajien että tilaajan edustajien
kanssa erikseen sovittuna ajankohtana. Tavallisimmin nämä tarkastelut pidetään
viikkopalaverien yhteydessä. Katselmoinneista ei laadita erillisiä raportteja,
ellei tilaaja niitä vaadi, vaan niistä mainitaan palaverien pöytäkirjoissa.
Dokumentit hyväksytetään ensin projektin ohjaajilla, jonka jälkeen ne esitetään
tilaajalle, joka halutessaan pyytää niihin muutoksia.
Projektin
kotisivuilla säilytetään kaikki projektin aikana hyväksytyt dokumentit sekä kaikki
version 0.5 ylittävät dokumentit. Dokumentteja muokatessa käytetään CVS-versionhallintaa
ja dokumenttien eri versiot löytyvät sieltä.
Testaus on jaettu
tässä projektissa kahteen osaan, koska projekti jakautuu loogisesti kahteen
toiminnalliseen ja itsenäiseen osaan. Testaukset suunnittelevat ja toteuttavat
Tuomas Räsänen ja Turo Lamminen.
Tässä osassa
testataan OpenOffice:ssa tuotettavien dokumenttien tuottamisprosessia siltä
osin, että käyttäjä ei mahdollisesti pääse sekoittamaan määrättyjä tyylejä
joita käytetään. Myös itse OpenOffice:n käyttöliittymää näiden dokumenttien
tuoton yhteydessä testataan, jotta siitä ei tulisi liian monimutkainen käyttää.
Lisäksi tässä osassa testataan OpenOffice:lla tuotettujen dokumenttien
tyyppimääritysten muuntamisprosessi XSLT-muunnoksilla luku.dtd mukaiseksi, mahdollisten muunnosvirheiden
löytämiseksi.
Testauksen
toisessa osassa testataan versionhallinnan toimintaa dokumentteja tuotettaessa
ja muokatessa sekä versionhallinnan mahdollista käyttöliittymää. Myös itse
koostamisohjelmaan luodun graafisen käyttöliittymän toiminnallisuutta ja
käytettävyyttä testataan.
Kokako-projekti
kehittää eteenpäin opinto-oppaan sisällöntuotanto- ja koostamistyökaluja.
Projektisuunnitelman olennaisimmat kohdat keskittyvät projektin
aikataulutukseen, versionhallintaan, hallintaan sekä riskeihin.
Projektisuunnitelmaa noudattamalla projekti on mahdollista viedä läpi
tehokkaasti. Projektin kehittämää järjestelmää voidaan tulevaisuudessa kehittää
eteenpäin.