Tämä dokumentti on ryhmän 11, Converge projektisuunnitelma. Projekti toteutetaan Helsingin yliopiston Tietojenkäsittelytieteen laitoksella syksyllä 2002 suoritettavan Ohjelmistotuotantoprojekti-kurssin harjoitustyönä.

Projektisuunnitelma sisältää lyhyen kuvauksen toteutettavasta aiheesta, toteutuksen rajauksista (tarkennetaan määrittelydokumentissa) sekä ryhmään kuuluvien henkilöiden vastuualueet ja vastuualueiden kuvaukset.

Yksi nykypäivän viestinnän kehityssuunnista on viestintämuotojen konvergoituminen, jonka vaikutuksesta tulevaisuudessa viestien välitystä vaikkapa sähköpostista kännykkään tullaan pitämään itsestäänselvyytenä.

Toinen vahva suuntaus on, että viestintään käytettyjen ohjelmistojen toimintaan liitetään myös tiedostonhallintaa, vaikka tällainen toiminnallisuus tuhlaa sellaisenaan turhaan aika- ja tilaresursseja.

Kolmas aihepiiriin liittyvä suuntaus on pyrkiä profiloimaan käyttäjä siten, että välitettävä viesti liittyisi käyttäjän tarpeisiin hänen käyttökontekstinsa mukaan.

Projektin tehtävät, tavoitteet ja rajaus

Tässä luvussa pyritään kattamaan mahdollisimman paljon toteutettavaan projektityöhön liittyvistä tavoitteista kokonaisuutena. Tarkemmat kuvaukset toiminnallisista vaatimuksista kirjataan määrittelydokumenttiin.

Tavoitteet ja tehtävät

Kurssille osallistuvilla opiskelijoilla on tavoitteena oppia ohjelmistotuotantotekniikkaa, ryhmässä työskentelyä, dokumentointia ja uusia sovellustekniikoita sekä tuotantovälineiden käyttöä.

Ohjelmistotuotantoprojektiryhmän tavoitteena on suunnitella ja toteuttaa määriteltyjen aikarajojen puitteissa sellainen viestien hallintajärjestelmän arkkitehtuuri, joka tukee aiemmin mainittuja viestinnän suuntauksia, muita rakenteellisia vaatimuksia arkkitehtuurille ei ole tällähetkellä vielä asetettu. Arkkitehtuurin tukeman järjestelmän on kuitenkin tuettava, käyttäjälle toteutettavan prototyyppin kautta näkyvä toiminnallisuus, jonka ominaisuuksien avulla viestinnän suuntauksia on mahdollista käsitellä.Työn pääpaino toteutuksessa on tutkia ja evaluoida toteutettavan arkkitehtuurin hyviä ja huonoja puolia sekä vertailla toteutettua mahdollisiin vaihtoehtoisiin arkkitehtuuritoteutuksiin.

Toteutettavalle arkkitehtuurille on asetettu muutamia ominaisuuksia, joita sen on tuettava. Yksi tällainen ominaisuus on, että viestintäohjelmisto pystyy tekemään sisäisten tietojensa perusteella päätöksen viestin mahdollisesta lähettämisestä käyttäjlle, jolloin lähettävän viestin on siis oltava sidoksissa käyttäjän sen hetken kontekstiin. Toteutukseen tulee liittää käyttäjä- ja tietoturva ominaisuuksia takaamaan peruskäyttöturvallisuus esim. käyttäjällä on oltava salasana.

Asiakkaan tavoitteena on saada yksi toteutettu viestintäarkkitehtuurin prototyyppi ja tutkimus- ja vertailutulokset muihin arkkitehtuuriratkaisuihin verrattuna.

Projektin tavoitteet on saavutettu, kun tämän projektisuunnitelman seuraavassa luvussa mainitut tulokset on saavutettu ja asiakas on ne hyväksynyt. Projektin katsotaan päättyneeksi kun kaikki tavoitteet on saavutettu kuitenkin viimeistään 31.12.2002, jolloin projekti päättyy automaattisesti siinä tilassa kuin se sillä hetkellä on.

Tulokset

Jotta voidaan todentaa, että projekti on saavuttanut sille asetetut tavoitteet, on seuraavien tulosten oltava olemassa ja vahvistettavissa.

Arkkitehtuurin toiminnallinen määrittely, jossa kuvataan mahdollisimman tarkasti ja yksiselitteisesti järjestelmälle asettetut vaatimukset sen toiminnallisuudesta ja ominaisuuksista. Määrittely on valmis, kun se on asiakkaan ja toimittajan yhteistyönä täydennetty ja yhteisesti hyväksytty.

Ohjelmiston tiedontalletusratkaisujen, toimintojen, rajapintojen ja teknisten ratkaisujen toteutussuunnitelmat, jotka kuvaavat järjestelmän toiminnalisuuden teknisentoteutuksen. Toteutussuunnitelmat ovat valmiita, kun ne on yhteisesti hyväksytty.

Käyttöohje sovitussa formaatissa (paperilla/sähköisessä muodossa), jossa kuvataan järjestelmän käyttö sekä sen tarjoamien toiminnallisuuksien kuvaukset loppukäyttäjille ymmärrettävässä muodossa.

Hyväksytysti toteutettu viestintäohjelmisto ja sen dokumentit sovittuina kokonaisuuksina l. dokumentti ja mahdolliset liitteet.

Rajaus

Projektin toimitukseen sisältyy yhdessä asiakkaan kanssa sovitun mukainen ohjelmistotoimitus, jonka tarkempi toiminnallisten ja teknisten ominaisuuksien rajaus kirjataan määrittelydokumenttiin.

Määrittelyssä mainitsemattomat asiat eivät sisälly toimitukseen tai toimitettavaan ohjelmistoon. Tällaisia toimituksen ulkopuolelle jääviä asiota ovat laitteistojen, ohjelmistojen ja tiedonhallintajärjestelmän versioiden vaihdosta aiheutuvat tehtävät, asiakkaan omat testaukset, loppukäyttäjien koulutus sekä sovelluksen käyttöönotto asiakkaan organisaatiossa.

Organisointi ja resurssit

Organisointi ja resurssit määrittelee käytettävissä olevat henkilöresurssit, niiden jaottelun projektin aikana sekä osaryhmille kuuluvat vastuut.

Projektin hallinnointi

Projektiryhmä koostuu viidestä tietojenkäsittelytieteen pääaineopiskelijasta ja yhdestä muuntokouluttautuvasta henkilöstä.

Projektin edistymistä seurataan säännöllisesti tai tarpeen vaatiessa järjestettävissä seurantakokouksissa, joissa projektiryhmä käy läpi siihen asti saavutetut tavoitteet tarkastelemalla projektin etenemistä projektisuunnitelmaa vastaan. FTR-kokouksissa (Formal Technical Review) pyritään varmistamaan, että tarkasteltu osakokonaisuus vastaa sille asetettua laatutavoitetta esim. alijärjestelmän tekninentoteutus tai määrittelydokumentti. Lisäksi projektiryhmä kokoontuu viikoittain työpalavereihin. Mahdolliset poissaolot kokouksista ilmoitetaan mahdollisimman aikaisin.

Projektin edistyminen dokumentoidaan työ- ja muiden kokouspöytäkirjojen ja muistioiden avulla. Kaikki toimitukseen liittyvät hyväksymiset kirjataan projektiryhmän seurantakokouspöytäkirjaan. Kaikki asiakkaan ja toimittajan väliset suoritetut katselmukset, joissa muutetaan tai tarkistetaan jo olemassa olevia määrityksiä, kirjataan erillisiin pöytäkirjoihin. Kokouksissa sihteerinä toimii kulloinkin sihteerivuorossa oleva projektiryhmän jäsen, joka laatii pöytäkirjan kokouksen tapahtumista.

Pöytäkirjat ja dokumentit kirjoitetaan suomeksi ja kirjoittamiseen käytetään Latex ladontaohjelmalla. Dokumentit säilytetään projektinversiohallinnassa hakemistossa /home/group/converge/cvsroot/docs. Projektin kotisivu sijaitsee osoitteessa www.cs.helsinki.fi/group/converge, johon kaikki projektin aineisto kerätään ja jonka kautta niihin pääsee käsiksi. Jokaiseen dokumenttiin liitetään myös tilatieto, josta voi todentaa onko dokumentti muokattavissa vai onko versio jo hyväksytty ja jäädytetty. Jäädytetyt versiot suojataan siten, ettei niihin ole mahdollista enää tehdä muutoksia. Jo jäädytettyyn dokumenttiin tulevat pakottavat muutostarpeet käydään läpi seurantakokouksien yhteydessä tehtävillä versionhallintapäätöksillä ja jos muutokset hyväksytään tehtäviksi, luodaan dokumentista uusi versio, johon liitetään kuvaus päätetyistä muutoksista. Dokumenttien versiot erotetaan toisistaan versionumeroinnilla siten, että hyväksytyn version numero on X.0 ja muokattavat versiot X.X esim. 1.4.

Projektisuunnitelman täsmennetyistä versioista ilmoitetaan myös projektiryhmän jäsenille sähköpostilla sekä asiakkaalle, ryhmän ohjaajalle ja Ohtu-projektin vastuuhenkilölle.

Ohjausryhmä

Ohjausryhmän vastuihin tämän projektin kuluessa kuuluvat projektin seuranta, dokumennoinin tarkkuustason määrittely, toteutuksen valvonta ja muutosten hyväksyntä sekä niistä päättäminen tarvittaessa.

Projektiryhmä

Projektin harjoituskurssiluonteesta johtuen, projektiryhmän jäsenille kuuluu yhteinen vastuu työn etenemisestä ja tuloksista. Jäsenien kesken on kuitenkin hajautettu yleisiä tehtäviä, millä pyritään varmistamaan, että kaikkia osa-alueita seurataan ja ylläpidetään.

Projektipäällikkö : Mikko Hiipakka
Projektipäällikölle kuuluviin tehtäviin kuuluu huolehtia ryhmän sisäisestä yhtenäisyydestä siten, että jokaisella jäsennellä on yhtenevät tiedot sekä käsitys projektin tilasta. Projektipäällikkö varmistaa, että projekti toteutetaan hyväksytyn projektisuunnitelman mukaisesti, huolehtii projektin tulosten valmistelevan työn tekemisestä sekä yleistä hallintoa, esimerkiksi raportointia.

WWW-vastaava : Joni Karppinen
Vastaavan tehtäviin kuuluu ryhmän kotisivujen ylläpito siten, että saatava tieto vastaa projektin todellista tilaa ja huolehtii dokumenttien saatavuudesta tarvittavissa formaateissa.

Dokumentointivastaava : Timo Ranta-Ojala
Vastaavan tehtäviin kuuluu dokumenttien sisällön oikoluku, dokumenttien sisältörakenteen tarkistus esimerkiksi tarkistaa, että asiat on jäsennelty otsikoihin oikein ja tarvittaessa dokumenttien sisältörakenteen muokkaus. Vastaava myös huolehtii hyväksyttyjen versioiden jäädytyksestä siten, että versioon ei ole mahdollista tehdä enää muutoksia.

Työvälinevastaava : Olli Pettay
Vastaavan tehtäviin kuuluu ryhmän käyttämien työvälineiden ylläpito sekä uusiin välineisiin tutustuminen ja niiden esittely muulle projektiryhmälle.

Määrittelyvastaava : Mikko Hiipakka
Vastaavan tehtäviin kuuluu valvoa määrittelydokumentin etenemistä.

Suunnitteluvastaavat : Joni Karppinen
Vastaavien tehtäviin kuuluu valvoa suunnitteludokumentin etenemistä.

Toteutusvastaavat : Anssi Johansson
Vastaavien tehtäviin kuuluu valvoa toteutusdokumentin etenemistä ja huolehtia toteutettujen alijärjestelmien integroinnista kolmannen osapuolen komponentteihin.

Testausvastaava : Tea Silander
Vastaavan tehtäviin kuuluu valvoa testaussuunitelman ja testausdokumentin etenemistä sekä valvoa testausta.

Toimittajan ja asiakkaan välinen vastuunjako

Projetityöhön liittyvien tehtävävien vastuu on jaettu toimittajan ja asiakkaan välillä. Tämän projektin ja projektisuunnitelman puitteissa ei määritellä ulkoistettavia vastuita, vaikka kolmannen osapuolen toteuttamia tuotteita tultaisiinkin toimituksessa käyttämään.

Toimittajan vastuut

Toimittajan vastuulle kuuluvat toimituksen suunnittelu, johtaminen ja valvonta sekä työpalavereiden koordinointi siten, että asiakkaan paikalla ollessa käsiteltävät asiat vaativat asiakkaan tuomaa tietoa. Toimittaja vastaa työsuunnitelman mukaisesti työn etenemisestä, sovittujen tulosten (dokumentit ja ohjelmisto) toimittaminen toimitusaikataulujen ja muiden toimitusvelvoitteiden mukaisesti, joita ovat toimituksen osakokonaisuuksien integrointi- ja koordinointitehtävät, sovellusratkaisujen toiminnallinen eheys ja tekninen laatu sekä dokumentointi.

Asiakkaan vastuut

Projektiin liittyviä asiakkaan vastuita ovat tarvittavien asiakkaan päätösten saaminen projektin käyttöön esim. mahdolliset muutokset vaatimuksiin. Ohjelmiston toiminnallisuuden määrittely siten, että toteutuksen tarkastelussa on mahdollista todentaa määrittely saavutetuksi tai saavuttamattomaksi esim. järjestelmällä on mahdollista lukea sähköpostia. Asiakkaalta odotetaan myös aiheasiantuntemuksen tuomista projektiin, siltä osalta kuin, asiakkaalla on järjestelmälle asetettava vaatimus, jonka alalta asiantuntemusta on. Asiakas päättää vastaako toimitettu ohjelmisto sille asetettuja määrityksiä ja toimitettavien tulosten hyväksyminen projektisuunnitelman menettelyjen mukaisesti.

Toimitusvaiheet ja vaiheiden tehtävät

Projektin toteutuksessa käytetään Ohelmistotuotantokurssilla esiteltyä vesiputousmallia. Työn luonteen vuoksi mallia kuitenkin toteutetaan tarpeen mukaan muutoksin. Yksi tällainen muutos on mahdollinen uusi kierros suunnittelusta tai toteutuksen alkuvaiheesta takaisin määrittelyyn, josta jatketaan jälleen mallin mukaisesti - tämä todennäköinen kierros merkitään myös aikatauluun. Tällaisen uuden kierroksen aloittaminen vaatii kaikkien projektiin liityvien ryhmien (projektiryhmä, asiakas ja vastuuhenkilö) yhteisen päätöksen. Ehtoina uuden kierroksen aloittamiselle on, että nykyistä linjaa jatkamalle ei ole enää pienillä muutoksilla mahdollista tuottaa asiakkaalle hyväksyttävä toimitusta ja ennen uuden kierroksen aloittamista on jo olemassa uusia parantavia määrityksiä olemassa.

Toimitusvaiheet

Käytettävä vesiputousmalli sisältää seuraavat tehtäväkokonaisuudet, joita käytetään myös projektin toimituksen vaiheina.

Projektinhallinta
Määrittely (vaatimusanalyysi)
Suunnittelu
Toteutus
Testaus
Korjaukset

Projektinhallinta

Projektihallinnalla pyritään hallitsemaan projektiin liittyviä osa-alueita kokonaisuutena siten, että saavutetaan määrätietoisesti etenevä ohjelmistotuotantoprojekti.

Vaihe pyrkii keskeisesti antamaan yleiskuvan tehtävästä ohjelmistosta. Muita tehtäviä ovat tuottaa projektin kokoarvio, projektin läpiviennin suunnittelu ja seuranta, tuotetaan vaihejako (esim. dokumenttien jäädytys) ja aikatauluarviot, projektiryhmän työnjako, projektisuunnitelman tarkennus 7.10.2002. Projektinhallinta sisältää myös projektin ohjauksen, laadunvarmistuksen ja raportoinnin sekä ohjausryhmän päätöksiä vaativien asioiden valmistelun. Osa projektinhallintaan liittyvistä tehtävistä on kirjoitettu tähän projektisuunnitelmaan, jota voi pitää projektinhallinnan ohjeistuksena.

Määrittely (vaatimusanalyysi)

Määrittelyssä tarkennetaan selvitystyössä (eli aiheeseen tutustumisessa) tehtyä alustavaa määrittelyä ja sen tarkoituksena on selvittää asiakkaan tuotteelle asettamat vaatimukset ja haluamat ominaisuudet eli mitä toteutettavan järjestelmän pitää tehdä.

Vaiheen tehtäviin kuuluu antaa käyttötapauksien avulla yleiskuvaus ohjelmistosta sidosryhmien kannalta eli sidosryhmille tarjottavat ominaisuudet. Vaihe määrittelee järjestelmän toiminnallisuuden määrittelylle tarvittavan tarkkuustason sekä rajaa ja tarkennetaa toiminnallisuutta esim. välttämättömät ja lisäominaisuudet sekä käytettävyysvaatimukset.

Vaiheen lopputuloksena on järjestelmän toiminnallinen määrittely l. määrittelydokumentti.

Suunnittelu

Suunnittelussa mietitään, miten määrittelyssä kuvatut toiminnot toteutetaan.

Vaiheen tehtäviin kuuluu kuvata toteutusympäristö, antaa ohjelmiston tekninen kuvaus toteutettavassa ympäristössä, luetella suunnittelu- sekä tekniset rajoitteet, kuvata määrittelyt toiminnot toteutuskelpoisina kokonaisuuksina siten, että toteutus voidaan suoritaa suoraviivaisesti. Muita vaiheeseen kuuluvia tehtäviä on luoda kaaviokuva ja selitykset ohjelmiston osajärjestelmistä, kuvata toteutuksessa tarvittavien tietojen käsittely ja varastointi, kuvata osajärjestelmien välinen kommunikointi ja siirtyminen järjestelmän eri osien välillä sekä rinnakkaisuussuunnittelu, mikäli järjestelmän vaatimuksissa rinnakkaisuutta vaaditaan tai jos sen avulla vaatimus tavoitetaan. Osajärjestelmän käyttöliittymäkuvaus, jos osaan sellainen liittyy, luokkakuvaukset; toiminta- ja rajapintamäärittelyt toteutettavista luokista sekä toiminnallisuuden rajaus ja tarkennus.

Vaiheen lopputuloksena tuotetaan järjestelmän toiminnallisuuden toteuttamissuunnitelma l. suunnitteludokumentti, jonka tarkkuus mahdollistaa suoraviivaisen toteutuksen. Alustetaan suunnittelun pohjalta testaussuunnitelma.

Toteutus

Toteutusvaiheessa toteutetaan suunnitteluvaiheessa mietityt kokonaisuudet sovitulla toteutusvälineellä sovitussa toteutusympäristössä.

Vaiheen keskeisin tehtävä on tuottaa suunnitteludokumentissa kuvattu, annetusta syötteestä määritellyn lopputuloksen. Muita vaiheen tehtäviä on täsmentää ja mahdollisesti korjata suunnittelua pienessä mittakaavassa, toteuttaa ohjelma tai funktio, havaita ja kirjata ylös toteutuksessa ilmenneet puutteet ja ongelmat sekä toteutetun moduulin yksikkötestaus.

Vaiheen lopputuloksena tulee toteutettu ohjelmisto, jonka ongelmat, puutteet ja muutokset suunnittelun suhteen on kirjattu toteutusdokumenttiin. Tarkennetaan suunnitteluvaiheen aikana tuotettua testaussuunnitelmaa. Suunnitelmassa on kuvaukset suoritettavista moduulitason, luokkatason ja integroimistason testeistä sekä käytettävistä testiaineistoista.

Testaus

Testausvaiheessa testataan, että toteutuksessa on huomioitu kaikki määrittelyvaiheessa tuotteelle asetetut vaatimukset. Testaus tehdään suunnitteluvaiheen lopussa tehdyn testaussuunnitelman mukaisesti.

Keskeisenä tehtävänä on varmistaa, että toteutettu järjestelmä toimii virheettömästi ja toteuttaa sille määritellyt tehtävät tehokkaasti ja luotettavasti.

Lopputuloksena työvaiheesta saadaan testattu tuote sekä testausdokumentti, jossa testitulokset on kirjattuna.

Tuotteen hallinta

Tuotteen hallinnassa käyttetään versionhallintaa, jonka avulla pyritää varmistamaan, että on aina olemassa toimiva kokonaisuus alijärjestelmiä, vaikka jonkin alijärjestelmän uusin versio ei olisikaan yhteensopiva muiden kanssa. Lähdekoodien versionhallintaan käytetään samaa CVS-versionhallintajärjestelmää kuin dokumenttien versiohallintaan (kts. Projektin hallinnointi).

Varmuuskopioinnissa luotetaan pääasiassa TKTL:n päivittäiseen varmuuskopiointiin. Versionhallintajärjestelmä pyritään kuitenkin tuplavarmistamaan vähintään joka toinen viikko tallentamalla uusimpien lähdekoodien versiot toiselle levylle esim. atk-keskuksen ylläpitämille.

Muu dokumentaatio

Työtuntilistoihin ryhmän jäsenet kirjaavat projektiin käytetyt päiväkohtaiset tuntimäärät.

Kokousten sihteeri kirjaa kokouspöytäkirjoihin ylös käsiteltävien asioiden pääkohdat ja päätökset.

Toteutetun ohjelmiston käyttöohjeet sekä arkkitehtuuriratkaisun ylläpitodokumentti, sisältää sellaisen kuvauksen järjestelmän toiminnallisuudesta, että mahdollinen ohjelmiston ylläpitohenkilö pystyy suoriutumaan tehtävästään.

Loppuraporttiin, joka on lyhyt yhteenveto projektista, pistetään liitteeksi sellaiset jatkuvasti päivitetyt dokumentit, joista ei kuitenkaan ole tehty omaa raporttia esim. työtuntilistat, pöytäkirjat ja epävirallisista kokouksista syntyneet muistiot.

Välineet ja menetelmät

Toteutusta varten TKTL:n 3. kerroksen mikrosalista varataan vähintään yksi tietokone projektiryhmän käyttöön.

Toteutuksessa käytettäviä työvälineitä ja menetelmiä:

Java-ohjelmointikieli, versio 1.4.1
Javadoc
XML ja XSL, versiot 1.0
HTML versio 4.01
Linux, Unix, Windows
LaTeX-ladontaohjelma dokumentoinnissa
CVS-versionhallintaohjelmisto

Ohjelmisto tulee toimimaan Helsingin yliopiston Tietojenkäsittelytieteen laitoksen Linux-ympäristössä.

Aikataulu

Taulukko 2: Projektin suunniteltu aikataulu

Vaihe Kesto

Projektin hallinta 26.08. - 31.12.

- Projektisuunnitelma hyväksytty versio 01.10.

Määrittely 09.09 - 31.10

- Määrittelydokumentin hyväksytty versio 31.10.

Suunnittelu 27.10. - 10.11.

- Suunnitteludokumentin hyväksytty versio 10.11.

Toteutus 10.11. - 01.12.

Testaus 01.12. - 20.12.

Luovutus asiakkaalle 20.12

**Kuva 1:** Projektiaikataulu
$\includegraphics[width=1.0\textwidth]{graphics/gantt.eps}$

Työmääräarviot

Jokaisen projektiryhmän jäsenen kuuluu tehdä noin 20 tuntia viikossa työtä projektin eteen. Tähän työmäärään lasketaan myös kaikki ryhmän sisäiset tapaamiset ja palaverit.

Projektin kuitenkin kiinteästä (loppuu viimeistään 31.12.2002) aikataulusta voidaan laskea, että ryhmän tuottama koodi olisi noin 4000 riviä. Työn tutkiva luonne asettaa tälle arviolle varauksen, että tuotettu määrä voi erota huomattavasti tästä.

Vaihe Työmääräarvio

(tuntia)

Projektin hallinta 80 5,9 %

Määrittely 320 23,5 %

Suunnittelu 300 22,1 %

Toteutus 220 16,2 %

Testaus 370 27,2 %

Korjaukset 30 2,2 %

Yhteensä 1360

Vaihe	Työmääräarvio
	(tuntia)
Projektin hallinta	80	5,9 %
Määrittely	320	23,5 %
Suunnittelu	300	22,1 %
Toteutus	220	16,2 %
Testaus	370	27,2 %
Korjaukset	30	2,2 %
Yhteensä	1360

Laadunvarmistus

Projektin loppu- ja välitulokset arviodaan yhdessä asiakkaan kanssa ja projektin edistymistä ja toteutuksen teknistä laatua seurataan säännöllisesti tai tarvittaessa pidettävissä seurantakokouksissa, joista pidetään pöytäkirjaa. Työn etenemisen ja toteutuksen laadun seuraaminen on koko ryhmän tehtävä, päävastuu on kuitenkin kulloisenkin vaiheen vastuuhenkilöllä.

Projektiin liittyvien riskien hallinta

Tässä ohjelmistotuotantoprojektissa tarkastellaan riskejä karkealla tasolla, koska projektiin ei sisälly samanlaisia tuotannollisia ja taloudellisia riskejä kuin liike-elämän ohjelmistotuotantoprojekteihin.

Työ laajenee liikaa

Ongelma : Työhön valitaan toteutettavaksi sellaisia osia, joita ryhmän ei ole mahdollista toteuttaa kurssin aikarajojen puitteissa.

Todennäköisyys : Keski

Vakavuus : Keski

Hallinta : Toteutettavaksi valitaan asiakkaan määrittelemät minimivaatimukset ja laajennukset tähän tehdään projektiryhmän yhteisellä päätöksellä.

Työmäärä arvioitua suurempi

Ongelma : Kaikkien toteutettavaksi valittujen osien suunnittelu, toteuttaminen ja testaaminen vaativat enemmän aikaa kuin suunniteltu.

Todennäköisyys : Korkea

Vakavuus : Korkea - projektilla on ehdoton päättymispäivä.

Hallinta : Määrittelyvaiheessa arvioidaan kriittisesti omia resursseja projektin suorittamiseksi, jotta toteutettavaksi ei oteta liian paljon ominaisuuksia. Jos ilmenee, että määrittelyvaiheessa on valittu liikaa ominaisuuksia, neuvotellaan asiakkaan kanssa vaatimusten rajaamisesta.

Aikataulu pettää

Ongelma : Määrittelylle, suunnittelulle, toteutukselle ja testaukselle asetetut aikarajat ylittyvät.

Todennäköisyys : Keski

Vakavuus : Keski - vaiheita voidaa toteuttaa mahdollisuuksien mukaan limittäin

Hallinta : Projektille laaditaan realistinen aikataulu ja työn edistymistä seurataan jatkuvasti. Jos huomataan aikataulusta jäämistä, selvitetään syy ja tarvittaessa muutetaan aikataulua tai kohdistetaan resursseja uudelleen.

Aikarajat epärealistisia

Ongelma : Aikarajoja asetettaessa ollaan aliarvioitu tehtävien toteuttamisen vaatimat ajat.

Todennäköisyys : Keski

Vakavuus : Korkea - projektilla ehdoton päättymispäivä

Hallinta : Aikataulua suunniteltaessa arvioidaan kriittisesti omia resursseja ja aikatauluja, jotta toteutettavaksi ei oteta liian paljon ominaisuuksia.

Tehty työ tai osa siitä katoaa

Ongelma : Tehty työ tai osa siitä menetetään.

Todennäköisyys : Matala

Vakavuus : Korkea

Hallinta : Versionhallinta ja varmuuskopiointi.

Valittu tekniikka ei sovi projektin toteuttamiseen

Ongelma : Osoittautuu, että ryhmän jo valitsema toteutustekniikka ei sovi projektin toteuttamiseen.

Todennäköisyys : Matala

Vakavuus : Korkea

Hallinta : Ennen valintaa ryhmä tutustuu vaihtoehtoihin riittävän huolellisesti, jotta riski ei toteudu. Jos näin kuitenkin käy, vaihdetaan valittu teknologia toiseen ja tarvittaessa aloitetaan projekti alusta.

Sopivaa teknologiaa ei löydy

Ongelma : Ryhmä ei löydä sopivaa teknologiaa, joka olisi välttämätön projektin toteuttamiseksi.

Todennäköisyys : Matala

Vakavuus : Korkea

Hallinta : Tarvittaessa muutetaan ohjelman toimintaa tai määrittelyä, jotta löydetään sopiva teknologia projektin toteuttamiseen. Määritellyn ominaisuuden toteuttamista voidaan myös lykätä, jos sopiva teknologia on jo kehitteillä tai tullaan tulevaisuudessa kehittämään.

Työvälineitä ei hallita

Ongelma : Projektin toteuttamiseksi tarvittavia tai valittuja työvälineitä ei osata käyttää, tai niitä ei osata käyttää oikein.

Todennäköisyys : Matala

Vakavuus : Keski

Hallinta : Ennen työvälineiden käyttöä niihin tutustutaan asian vaatimalla tavalla.

Katkokset tiedonvälityksessä

Ongelma : Tieto asiakkaalta tai muilta ryhmän jäseniltä ei tavoita kaikkia ryhmän jäseniä tai asiakasta riittävän ajoissa.

Todennäköisyys : Keski

Vakavuus : Keski

Hallinta : Ryhmän ja asiakkaan välillä käydään jatkuvaa avointa keskustelua, yhteydenpitoon käytetään ryhmän sähköpostilistaa ja tarvittaessa kännykkää.

Ryhmän jäsen lopettaa

Ongelma : Joku ryhmän jäsenistä lopettaa, ennen kuin projekti saadaan päätökseen.

Todennäköisyys : Matala

Vakavuus : Keski

Hallinta : Jos ryhmän jäsen lopettaa kesken projektin, jaetaan hänen vastuualueensa ryhmän muiden jäsenten kesken. Tarvittaessa keskustellaan asiakkaan kanssa vähemmän tärkeiden ominaisuuksien karsimisesta.

Ryhmän ihmisiltä puuttuu tarvittavaa tietoa projektin toteuttamiseen

Ongelma : Ryhmän jäseniltä ei löydy tarvittavaa osaamista projektin toteuttamiseen. Puuttuva osaaminen voi olla ohjelmointikieli, toteutusympäristö tai muu vastaava aihealue.

Todennäköisyys : Keski

Vakavuus : Keski

Hallinta : Ensisijaisesti voidaan olettaa, että ainakin joku ryhmän jäsenistä hallitsee tarvittavan tiedon. Jos kuitenkaan näin ei ole, ryhmä hankkii itselleen tarvittavan tiedon.

Asiakkaan tarpeita ei ymmärretä

Ongelma : Ryhmä ei saa käsitystä siitä, mitkä ovat asiakkaan vaatimukset ja odotukset tuotetta kohtaan tai mitä ominaisuuksia asiakas haluaa tuotteeseen liittyvän.

Todennäköisyys : Keski

Vakavuus : Keski

Hallinta : Asiakkaaseen ollaan aktiivisesti yhteydessä ja varmistetaan ollaanko asiat ymmärretty oikein.

Asiakas ei tiedä, mitä haluaa

Ongelma : Asiakas ei tiedä, mitä ominaisuuksia hän haluaisi ohjelmiston sisältävän

Todennäköisyys : Keski

Vakavuus : Korkea

Hallinta : Jatkuva avoin keskustelu ryhmän ja asiakkaan välillä koskien haluttuja ja mahdollisia ominaisuuksia sekä niiden toteuttamiskelpoisuutta,ryhmän oma aktiivisuus.

Asiakkaan tarpeet muuttuvat

Ongelma : Asiakas haluaa karsia, lisätä tai muuttaa ohjelmiston ominaisuuksia tai ei ole itsekkään varma millaisen tuotteen haluaa.

Todennäköisyys : Keski

Vakavuus : Korkea

Hallinta : Vaatimukset tarkastetaan asiakkaan kanssa ja lisäksi pyritään jatkuvaan yhteydenpitoon, jotta tieto asiakkaan tarpeiden muuttumisesta saataisiin mahdollisimman pian.

Asiakas ei ole tyytyväinen valmiiseen tuotteeseen

Ongelma : Valmis tuote ei vastaa ominaisuuksiltaan tai toiminnallisuudeltaan sitä, mitä asiakas toivoi.

Todennäköisyys : Matala

Vakavuus : Korkea

Hallinta : Varmistetaan, että asiakkaan tarpeet tulevat ymmärretyiksi ja että asiakas todella tietää mitä haluaa.

Virheellisen ohjelmakoodin tuottaminen

Ongelma : Tuotetaan koodia, joka ei toimi ollenkaan tai toimii virheellisesti.

Todennäköisyys : Matala

Vakavuus : Korkea

Hallinta : Laaditaan ja dokumentoidaan koodi huolellisesti sekä jatkuvasti verrataan sitä suunnitteludokumenttiin.

Laitteisto-ongelmat

Ongelma : Ryhmällä on ongelmia TKTL:n laitteistojen toimivuuden kanssa.

Todennäköisyys : Matala

Vakavuus : Keski

Hallinta : Jos havaitaan ongelmia laitteiston kanssa, raportoidaan siitä viipymättä koko projektiryhmälle sekä ylläpidolle, jota pyydetään korjaamaan ongelma.

Ohjelmisto-ongelmat

Ongelma : Ryhmällä on ongelmia TKTL:n ohjelmistojen toimivuuden kanssa.

Todennäköisyys : Matala

Vakavuus : Keski

Hallinta : Jos havaitaan ongelmia ohjelmiston kanssa, raportoidaan siitä viipymättä koko projektiryhmälle ja pyritään selvittämään ongelma. Jos ryhmä ei saa ongelmaa ratkaistuksi, pyydetään ylläpitoa ratkaisemaan ongelma.

Yhteensopivuusongelmat

Ongelma : Ohjelmiston eri komponentit eivät toimi keskenään, ohjelmisto ei toimi vaadituissa ympäristöissä tai asiakkaan laitteiston kanssa.

Todennäköisyys : Matala

Vakavuus : Korkea

Hallinta : Jotta ohjelmiston eri komponenteista saadaan keskenään yhteensopivia, käytetään universaalia ohjelmointikieltä (tässä tapauksessa Javaa) sekä ohjelmoidaan standardien mukaisesti. Lisäksi testataan ohjelmisto vaadituissa ympäristöissä ja asiakkaan laitteiston tai vastaavan kanssa. Tarvittaessa muutetaan ohjelmiston rajapintoja tai koodia niin, että ohjelmisto toimii vaadittavien ohjelmistojen kanssa vaadituissa ympäristöissä.

Ylläpito-ongelmat

Ongelma : Asiakkaalla ei ole tarvittavia resursseja ohjelmiston ylläpitämiseksi.

Todennäköisyys : Matala

Vakavuus : Keski

Hallinta : Kerrotaan asiakkaalle, millaisia resursseja tuotteen ylläpito vaatii ja varmistetaan, että asiakas osaa ylläpitää ohjelmistoa.

Käytetyt termit ja lyhenteet

Merkintä Selitys

HTML Hypertext Markup Language, WWWsivujen sisällön

kuvauksessa käytetty kieli

Lisätietoja: http://www.w3.org/pub/WWW/MarkUp/

Java Sunin kehittämä ohjelmointikieli ja järjestelmäriippumaton

ajoympäristö

Lisätietoja: http://java.sun.com

Javadoc Sunin kehittämä Javakoodin dokumentointimenetelmä

Lisätietoja: http://java.sun.com

TKTL Helsingin yliopiston tietojenkäsittelytieteen laitos

Lisätietoja: http://www.cs.helsinki.fi

W3C World Wide Web Consortium, kansainvälinen yhteistyöelin, joka

koordinoi WWWtekniikan ja standardien kehitystä

Lisätietoja: http://www.w3.org/pub/WWW/Consortium/

XML Extensible Markup Language, W3C:n kehittämä rakenteisten

dokumenttien määrittelykieli

Lisätietoja: http://www.w3.org/XML/

XSL Extensible Stylesheet Language, W3C:n kehittämä XMLdokumenttien

ulkoasun määritykseen tarkoitettu kieli

Lisätietoja: http://www.w3.org/Style/XSL/

Merkintä	Selitys
HTML	Hypertext Markup Language, WWWsivujen sisällön
	kuvauksessa käytetty kieli
	Lisätietoja: http://www.w3.org/pub/WWW/MarkUp/
Java	Sunin kehittämä ohjelmointikieli ja järjestelmäriippumaton
	ajoympäristö
	Lisätietoja: http://java.sun.com
Javadoc	Sunin kehittämä Javakoodin dokumentointimenetelmä
	Lisätietoja: http://java.sun.com
TKTL	Helsingin yliopiston tietojenkäsittelytieteen laitos
	Lisätietoja: http://www.cs.helsinki.fi
W3C	World Wide Web Consortium, kansainvälinen yhteistyöelin, joka
	koordinoi WWWtekniikan ja standardien kehitystä
	Lisätietoja: http://www.w3.org/pub/WWW/Consortium/
XML	Extensible Markup Language, W3C:n kehittämä rakenteisten
	dokumenttien määrittelykieli
	Lisätietoja: http://www.w3.org/XML/
XSL	Extensible Stylesheet Language, W3C:n kehittämä XMLdokumenttien
	ulkoasun määritykseen tarkoitettu kieli
	Lisätietoja: http://www.w3.org/Style/XSL/

Tästä dokumentista ...

Convergence of messaging

Tämä dokumentti tehtiin ohjelmistolla LaTeX2HTML translator Version 2002 (1.62)

Komentoriviargumentit olivat:
latex2html -split 0 proj_suunnitelma.tex.

Komennon ajoi Joni J Karppinen 2002-12-20

Joni J Karppinen 2002-12-20