Projektisuunnitelma. Sahara-ryhmä. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Transkriptio

1 Projektisuunnitelma Sahara-ryhmä Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 Kurssi Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Sanna Keskioja Sampo Lehtinen Hanna Liedenpohja Seppo Syrjänen Asiakas Joni Salmi Johtoryhmä Juha Taina Kimmo Simola Kotisivu Versiohistoria Versio Päiväys Tehdyt muutokset Ensimmäinen versio/sl Päivitys/SK Editointia/SL Valmis/SL

3 Sisältö i 1 Johdanto 1 2 Organisaatio 1 3 Työn yleiskuvaus Nykytilanne Laitteisto- ja ohjelmistovaatimukset Käyttöliittymä Sovelluslogiikka Tietokanta Kokoarvio Toteutuma Arviot Aikataulu Päättyneet vaiheet Käynnissä olevat vaiheet Alkavat vaiheet Tulevia määräpäiviä Työskentelytavat Kokouskäytäntö Koollekutsuminen Asialista Pöytäkirjat Poissaolot Myöhästymiset Projektin tehtävät Aloitus Projektisuunnitelma Käyttöliittymäsuunnittelu Vaatimusmäärittely

4 ii Suunnittelu Toteutus Testaus Riskianalyysi Viisi suurinta riskiä Projektiryhmän riskit Projektityön riskit Tekniikan ja työkalujen riskit Toteutettavaan ohjelmistoon liittyvät riskit

5 1 Johdanto 1 Sahara on Helsingin yliopiston tietojenkäsittelytieteen laitoksen ohjelmistotuotantoprojekti. Projektissa tuotetaan Tanja-järjestelmä, jonka avulla tietojenkäsittelytieteen laitoksella työskentelevä tuntiohjaaja tai joku muu ryhmiä kokoonkutsuva henkilö voi jakaa ryhmänsä jäsenille sekä ryhmän yhteisiä että osallistujien henkilökohtaisia tapaamisaikoja. Tämän projektisuunnitelman tehtävänä on toimia ryhmän sisäisenä ohjeistuksena ja auttaa projektia pysymään aikataulussa. Tässä dokumentissa määritellään ryhmän sisäinen työnjako, ryhmän noudattama prosessi, siihen liittyvät työvaiheet ja niiden aikataulut. Projektin aikana ryhmä työskentelee projektisuunnitelman mukaisesta työvaiheesta toiseen. Työvaiheen tuloksena saadaan vaiheen tulokset kokoava dokumentti. Dokumentissa määritellään myös projektissa käytettävät työmenetelmät ja ohjelmistot. 2 Organisaatio Projektin osapuolet ja heidän tehtävänsä: Projektiryhmä Sahara Sanna Keskioja Käyttöliittymä ja dokumenttivastaava, skeskioj@cs.helsinki.fi Sampo Lehtinen Projektipäällikkö, sampo.lehtinen@helsinki.fi Hanna Liedenpohja Koodi- ja www-vastaava, hliedenp@cs.helsinki.fi Seppo Syrjänen Suunnittelu- ja testausvastaava, seppo.syrjanen@helsinki.fi Muut osapuolet Joni Salmi Juha Taina Kimmo Simola 3 Työn yleiskuvaus 3.1 Nykytilanne Asiakas, joni.salmi@helsinki.fi Vastuuhenkilö, juha.taina@helsinki.fi Ohjaaja, ksimola@cs.helsinki.fi Tällä hetkellä Helsingin yliopiston tietojen Tietojenkäsittelytieteen laitoksen opintoihin kuuluu harjoitustyökursseja. Laitos tarjoaa harjoitustöiden ohjausta viisi kertaa lukuvuodessa: kaksi kertaa sekä syksyllä että keväällä sekä kerran kesällä. Opiskelijat ilmoittautuvat suorittamaan harjoitustyötä toteutettavasta Tanja-järjestelmästä erillisen Ilmojärjestelmän kautta,josta tiedot siirtyvät laitoksen kurssikirjanpitoon Kurki-järjestelmään. Ohjaaja laatii aikataulut harjoitustyöryhmän aloitustapaamisessa manuaalisesti "huutoäänestyksellä", kierrättämällä listaa istumajärjestyksessä tai jollain monimutkaisemmalla menetelmällä.manuaalisilla menetelmillä tuotetut tapaamisaikataulut eivät välttämättä ole parhaita mahdollisia tai reiluja. Nopeimmat ja röyhkeimmät saavat parhaat ajat hiljaisten ja hitaiden joutuessa tyytymään jäljelle jääviin aikoihin. Lisäksi aikataulun laatiminen

6 manuaalisilla menetelmillä vie aikaa, kun aikojen sopivuuksia selvitetään yksi opiskelija kerrallaan muiden opiskelijoiden odotellessa Laitteisto- ja ohjelmistovaatimukset Järjestelmän tarkoituksena on helpottaa ja tasapuolistaa ohjausajoista sopimista sekä parantaa tapaamisaikojen sopivuutta kokonaisuudessaan. Järjestelmää kaavaillaan käytettäväksi erilaisiin harjoitustöihin liittyvien tapaamisten, erilaisten ryhmätapaamisten ja palaverien sekä kehityskeskusteluiden ajankohtien sopimiseen. Asiakkaan alkuperäisten kaavailuiden mukaan järjestelmää käytetään ohjaajalähtöisesti. Tällöin ohjelman tehtäväksi jää lähinnä sopivimman aikataulun laskeminen ja visuaalisena apuna toimiminen mahdollisen huutoäänestyksen tapahtuessa. Asiakas toivoo myös mahdollisuutta laajentaa järjestelmä hajautetuksi, niin että ryhmän osallistujat voivat syöttää omat tietonsa itse. Järjestelmän arkkitehtuurin tulee muodostua kolmesta osasta: käyttäjän kanssa kommunikoivasta käyttöliittymästä, syötetietojen perusteella varsinaiset tapaamisajat muodostavasta sovelluslogiikasta sekä tiedot tallentavasta tietokannasta. Ohjelmiston on sovelluttava käytettäväksi tietojenkäsittelytieteen laite ja ohjelmistoympäristössä. Tietojen tallettamiseen käytetään jotain tietokannanhallintajärjestelmää Käyttöliittymä Käyttöliittymä toimii normaalissa nykyaikaisessa kannettavassa tai työpöytäkoneessa joko selaimen kautta tai sellaisenaan itsenäisenä sovelluksena. Toteutukseen kaavaillaan käytettävän Javan 1.5 versiota. Käyttöliittymän toimintaa missa laitteissa ei mitenkään tietoisesti estetä tai hankaloiteta, mutta testauksessa ja toteutuksessa näitä laitteita ei oteta huomioon Sovelluslogiikka Sovelluslogiikka tarkistaa käyttäjän käyttöliittymän kautta antamien syötetietojen oikeellisuuden ja muodostaa niiden perusteella ryhmän aikataulun. Sovelluslogiikka toimii sovelluspalvelimella, joka varmistaa tietojen oikeellisuuden, tallettaa ja noutaa tietoa varastosta käyttöliittymältä saatavien pyyntöjen mukaan. Riippuen valittavasta ohjelmiston toteutustavasta voidaan mahdollisia ympäristöjäovat esimerkiksi Tomcat, JBoss tai lopulta valituksi tullut PHP. Valittavan toteutusympäristön tuli myös olla joko valmiiksi asennettuna tai helposti asennettavissa laitoksen ympäristöön Tietokanta Tietokanta halutaan eristää muusta ohjelmistosta. Voidaan käyttää DAL-mallia (data access layer), jonka avulla voidaan abstrahoida käytettävä tietokanta muun tietojärjestelmän suuntaan. DAL-mallin käyttämisestä saadaan hyötynä mahdollisuus vaihtaa tietokanta toiseen

7 vähällä työlla tai pidemmälle vietynä toteutettua koko ohjelmisto tietokantariippumattomasti. Tähän on olemassa valmiiksi toteutettuja ja testattuja välineitä, kuten Enterprise Java Beans. Lopulta tietokannan abstrahointi jätettiin toteuttamatta. 3 4 Kokoarvio 4.1 Toteutuma Kokoarviot on tehty Java-kielistä toteutusta silmällä pitäen. Vaihdettaessa toteutustavaksi PHP laskelmia ei tehty uudestaan. Jätämme laskelmat kuitenkin tähän, ne toimivat PHP:n kohdalla suuntaa-antavina sekä osoituksena siitä, että arviointimahdollisuuksiin tutustuttiin ja että niitä pyrittiin käyttämään hyödyksi. PHP-koodia kirjoitettiin lopulta lähes 5000 riviä. Kokonaisuudessaan projekti käytti PHPkoodia lähes 7000 riviä. Projektin puitteissa kirjoitettiin myös muutamia satoja rivejä JavaScript (ECMAScript) koodia, sh- ja perl-scriptejä sekä tuntematon määrä lopulta käyttämättä jääneitä kokeiluja Java-kielellä. 4.2 Arviot Järjestelmän ohjelmointikielenä on valtaosin Java. Lisäksi käytetään vähäisessä määrin SQL- ja XML-kieliä. Järjestelmän toteutukseen vaadittaneen todennäköisimmän arvion mukaan yhteensä noin 8000 riviä koodia (LOC). Tämä jakautuu järjestelmän kolmitasoarkkitehtuurin mukaan seuraavasti: Käyttöliittymä (sis. tietoliikenteen) 5000 loc Sovelluslogiikka (sis. aikataulun laskevan algoritmin) 1000 loc Tietokanta (sis. käyttöliittymän kanssa keskustelun) 2000 loc Arvio perustuu järjestelmän syötteiden, tulosteiden, kyselyiden, tiedostojen lukumäärän ja ulkoisten liittymien lukumäärän perusteella laskettujen toimintopisteiden lukumäärään. Kutakin toimintopistettä on arvioitu sen tekemisen vaikeuden perusteella asteikolla yksinkertainen, keskinkertainen ja vaikea. Syötteet (7 kpl) Omien tietojen muokkaaminen Aikataulun laatiminen Ryhmän perustaminen Salasanan tilaus Aikataulun muokkaus Rekisteröityminen Kirjautuminen Keskinkertainen Keskinkertainen Vaikea

8 Tulosteet (10 kpl) Kaikkien sopivuudet ok Osallistujien lkm > aikojen lkm Rekisteröityminen OK Salasana lähetetty Virhe kirjautumisessa Virhe rekisteröitymisessä Virhe salasanan tilauksessa Valmiin aikataulun lähetys Kutsun lähetys Valmis aikataulu Kyselyt (5 kpl) Aikojen lkm Osallistujien lkm Current date Kutsujan ryhmät ja aikataulut Osallistujan ryhmät ja aikataulut Tiedostojen lukumäärä (10 kpl) Konfiguraatiotiedosto Muita aputiedostoja Tietokanta Keskinkertainen Vaikea Vaikea Keskinkertainen Keskinkertainen Ulkoisten liittymien lukumäärä (2 kpl) Sähköpostin lähetys (SMTP) CSV-import Keskinkertainen Toteutuksen vaikeus helppo *k Normaali *k Vaikea *k pisteet Syötteitä Tulosteita Kyselyjä Tiedostoja Liittymiä FP Σ (N) 176 Lisäksi otetaan huomioon erilaisia ohjelmistolle asetettuja vaatimuksia, jotka painotetaan asteikolla 0-5 (0 - ei koskaan, 1 - harvoin, 2 - toisinaan, 3 - keskimääräisesti, 4 - merkittävästi, 5 - oleellisesti) sen mukaan kuinka merkityksellisiä ne ovat tämän Tanja-projektin osalta. Sovituskertoimet 4

9 1 Vikasietoisuus 1 2 Tietoliikenneominaisuudet 2 3 Hajautettu laskenta 0 4 Suorituskykyvaatimukset 1 5 Käytettävän koneympäristön kuormitus 1 6 Interaktiivinen tietojen syöttö 5 7 Interaktiivinen tietojen syötön synkronointi 5 8 Interaktiivinen tietojen päivitys 5 9 Syötteiden, tulosteiden, tiedostojen tai kyselyiden monimutkaisuus 2 10 Ohjelman toiminnan monimutkaisuus 2 11 Koodin uudelleenkäytettävyys 1 12 Ohjelmiston muunnoksen ja sennuksen sisällyttäminen suunnitelmaan 4 13 Ohjelman toimivuus eri organisaatioissa 0 14 Sovelluksen käyttäjäystävällisyys 5 Yhteensä 34 Toimintopisteiden ja sovituskertoimien pisteet sijoitetaan kaavaan FP = N*(0,65+0,01*S(Fi)) = 176*(0,65+0,01*34)=174 Tähän saatuun lukuun sovelletaan LOC:in ja FP:n välisistä suhteista tehtyjä arvioita. Koska Tanja-järjestelmä toteutetaan Java-kielellä käytetään kertoimena optimistista arvioita FP/LOC = 40, todennäköistä arvioita FP/LOC = 50 ja konservatiivista arvioita FP/LOC = 55. Tällöin saadaan seuraavat arvioit ohjelmiston yhteenlasketulle koodirivimäärälle: FP/LOC=40 => 7000 loc FP/LOC=50 => 7800 loc FP/LOC=55 => 9600 loc 5 5 Aikataulu Tässä kappaleessa kuvataan, miten projekti jakaantuu pienempiin osiin. Aikataulua laadittaessa on otettu huomioon ennalta päätetyt eri tuotosten eräpäivät, seurantakokousten päivämäärät, projektiryhmän jäsenten poissaolot sekä kaikille projekteille yhteinen demotilaisuus. 5.1 Päättyneet vaiheet Aloitus Vaatimusmäärittely

10 6 5.2 Käynnissä olevat vaiheet Projektisuunnitelma Suunnittelu Toteutus Alkavat vaiheet Testaus (MYÖHÄSSÄ, piti alkaa 4.7) Viimeistely Tulevia määräpäiviä Projektisuunnitelma v Suunnitteludokumentti 1.8 Asennusohje 22.8 Käyttöohje 22.8 Toteutusdokumentti 26.8 Testausdokumentti 26.8 Loppuraportti Työskentelytavat 6.1 Kokouskäytäntö Kokousten puheenjohtajana toimii projektipäällikkö tai hänen poissaollessaan varaprojektipäällikkö. Lähtökohtaisesti jokaisen olisi hyvä olla paikalla jokaisessa kokouksessa. Projektin puitteissa saattaa olla tarvetta tai estymisen johdosta olla pakko, pitää kokouksia vajaalla ryhmällä. Mikäli etukäteen tiedetään, että joitain ryhmäläisiä ei tarvita, ei heidän läsnäolonsa ole pakollista. Tällaisissa tapauksissa kyseisiä ryhmäläisiä informoidaan riittävän ajoissa. Kokoukset pyritään pitämään kahdesti viikolla ennalta sovittuina aikoina seuraavasti: : ma klo 14:15 ja to klo 9: : ei kokouksia : ma klo 14:15 ja to klo 9: : ei sovittu

11 Koollekutsuminen Kokoukset kutsutaan koolle sähköpostitse riittävän ajoissa ennen kokousta että ryhmäläiset ja ohjaaja saavat riittävästi aikaa perehtyä kokouksessa käsiteltäviin asioihin Asialista Ryhmäläiset voivat ehdottaa aiheita kokousten asialistalle ilmoittamalle niistä projektipäällikölle riittävän aikaisin. Kokousten asialista hyväksytään aina kokousten alussa, joten asioiden saaminen käsittelyyn on mahdollista asialistan julkaisemisenkin jälkeen. Lisäksi kokouksissa pyritään käytettävän ajan puitteissa käsittelemään muut esille tulevat asiat Pöytäkirjat Kaikista viikkokokouksista pidetään pöytäkirjaa. Pöytäkirjaa pidetään myös asiakaspalavereista ja muista ryhmän sisäisistä muodollista kokouksista kuten esimerkiksi katselmuksista. Pöytäkirjaa pitää aina kunkin kokouksen alussa valittava sihteeri, joka kirjaa muistiin kokouksen tapahtumat ja siinä päätetyt asiat. Ryhmä pyrkii kierrättämään tehtävää niin että kaikki toimisivat vuorollaan sihteerinä. Pöytäkirjan tulee olla valmis seuraavaan kokoukseen mennessä, jolloin se tarkastetaan Poissaolot Kokousista poissaoloista ilmoitetaan muulle ryhmälle sähköpostitse tai viikkokokouksessa mahdollisimman aikaisin etukäteen. Yllättävistä poissaoloista ilmoitetaan mahdollisuuksien mukaan tekstiviestillä jollekin toiselle ryhmän jäsenelle. Tarpeen vaatiessa kokous voidaan aloittaa tietämättä onko ryhmän jäsen myöhässä vai kokonaan poissa. Tällöin asialistaa pyritään muokkaamaan siten, että ryhmän jäsenen poissaolosta koituu mahdollisimman vähän haittaa Myöhästymiset Kokouksista myöhästymiset kirjataan kokouspöytäkirjaan. Samoin toimitaan mikäli joku joutuu poistumaan kokouksesta ennen sen päättymistä. 6.2 Projektin tehtävät Aloitus Ohjelmistotuotantoprojektin ensimmäinen ryhmätapaaminen ja ensimmäisen viikon järjestäytyminen. Tapaamisen kutsui sähköpostitse koolle ohjaaja Kimmo Simola. Tapaami-

12 sessa sovittiin projektiryhmän sisäisestä roolijaosta, alustavasta aikataulusta sekä suunniteltiin tulevaa Projektisuunnitelma Projektisuunnitelmassa kuvataan ryhmän työtavat ja -käytännöt. Tämän dokumentin alustavan version tekeminen on projektipäällikön vastuulla. Vedosta työstettäessä muu projektiryhmä osallistuu projektisuunnitelman työstämiseen ja vedoksen valmistuttua lukukierrokseen. Projektisuunnitelmaa päivitetään projektin edetessä Käyttöliittymäsuunnittelu Käyttöliittymäsuunnittelussa toimitaan läheisessä yhteistyössä asiakkaan kanssa. Käyttöliittymäprotoja käytettiin apuna myös vaatimusmäärittelyssä ja suunnittelu valmistui yhdessä vaatimusdokumentin loppuunsaattamisen yhteydessä viikolla 25. Käyttöliittymäsuunnittelun tuloksena syntyi käyttöliittymäsuunnitelma sellaisella tarkkuudella ja kattavuudella, että se kelpaa toteutuksen ohjeeksi. Tämä tarkoittaa sitä, että kaikki oleelliset näytöt on kuvattu niihin liittyvän toiminnan, mahdollisten poikkeuksien ja virhetilanteiden sekä käyttötapausten osalta. Dokumentoidut käyttötapaukset toimivat moduuli- ja integraatiotestauksen sekä validoinnin pohjana. Suunnitellun ja toteutettavan käyttöliittymän eroavuudet kirjataan suunnitteludokumenttiin Vaatimusmäärittely Vaatimusmäärittelyssä selvitettiin asiakkaan ohjelmistolle asettamat vaatimukset ja tuotettiin niiden pohjalta vaatimusdokumentti. Vaatimusten kartuttamisessa käytiin yhdessä asiakkaan kanssa läpikäytyjä käyttötapauksia ja niiden perusteella suunniteltuja käyttöliittymäprotoja. Vaatimusdokumentti lähetettiin asiakkaalle katselmoitavaksi Asiakkaan toivomien korjausten ja muutosten hyväksymisen jälkeen vaatimusdokumentti jäädytettiin 30.6 ryhmän viikkopalaverissa. Mikäli vaatimusdokumenttia on jäädyttämisen jälkeen muutettava, neuvotellaan muutoksista asiakkaan kanssa. Poikkeuksena tähän käytäntöön ovat vähäiset ulko- tai kieliasuun liittyvät korjaukset kuten sellaiset kirjoitusvirheiden korjaukset, jotka eivät oleellisesti vaikuta vaatimuksiin tai vaatimusten yksiselitteisyyteen, ristiriidattomuuten tai kattavuuteen Suunnittelu Toteutuksen suunnittelu muilta kuin käyttöliittymän osalta alkaa vaatimusmäärittelyn loppuvaiheessa kun järjestelmän toiminnan kannalta keskeisen vaatimukset on selvitetty ja analysoitu. Suunnittelu tehdään vaatimusdokumenttiin kirjattujen pohjalta eli ohjelmistolle suunnitellaan ainaostaan sellaisia toimintoja, jotka on eksplisiittisesti määritelty. Suunnittelun tuloksena syntyy suunnitteludokumentti, johon kirjataan riittävän tarkalla tasol-

13 la ohjeet toteutusta varten. Tähän sisältyy tarvittavista tekniikoista, ohjelmointikielistä ja laitteistoista päättäminen. Käytettävät algoritmit ja keskeiset metodit kuvataan tarkasti, tarvittaessa pseudo-koodilla, ja luokista piirretään tarkat luokkakaaviot. Tässä vaiheessa suunnitellaan ainoastaan sellaiset järjestelmän ominaisuudet, jotka tullaan myös toteuttamaan Toteutus Toteutusvaiheen kriittinen tuotos on asiakkaan tilaama ohjelmisto. Kurssin lyhyydestä johtuen toteutus tullaan rajaamaan vaatimusmäärittelyä pienemmäksi. Toteutus tehdään siten, että yksittäiset ohjelman osata ovat vaihedettavissa ohjelmiston toiminnan muuttumatta. Toteutuksessa pidetään huoli, ettei suunniteltua laajempia riippuvuuksia pääse syntymään Testaus Testataan ohjelmaa toteutuksen edetessä alkuun yksikkötestein ja sitten suurempia osia kerrallaan. Toteutuksen aikaisen testauksen tarkoituksena on pitää huoli, ettei ohjelmistoon pääse syntymyään virheitä, joiden korjaaminen vaatii huomattavan suuren työn ja jotka huomataan myöhäisessä vaiheessa. Testaus suoritetaan suunnitteludokumentissan kuvattavalla tavalla. Tämä testaus-vaiheen konkreettinen tuotos on testausdokumentti, jossa on kuvataan suoritetut testit ja niiden tulokset.

14 7 Riskianalyysi Ensimmäinen versio Lisätty luku "Viisi suurinta riskiä" Lisätty riskit R2.3, R3.3, R4.4, R4.5. Uudelleenarvioitu top Lisätty R3.4. Stilisointeja Siirretty LaTeX-muotoon. Säädetty riskiä R Arvioitu riskien top-5. Riskianalyysissä kartoitetaan projektiin liittyvät riskit, niiden vakavuus ja niiden todennäköisyys. Lisäksi kuvaillaan toimintatavat riskien ennaltaehkäisemiseksi ja toimintaa riskien toteutuessa. Riskit esitellään seuraavalla tavalla: Riski N.N: Riskin nimi ja kuvaus Asteikolla vähäinen=1, mahdollinen=2, todennäköinen=3, lähes varma=4. Asteikoilla vähäpätöinen=1, siedettävä=2, vakava=3, tuhoisa=4. Millä toimilla riskin toteutumista voidaan torjua. Millä tavalla toimimalla riskin toteutumisen seurauksia ennakolta pienentää, jos se kuitenkin toteutuu. Varasuunnitelma eli millä tavoilla toteutuneesta riskistä toivutaan sen realisoitumisen jälkeen ts. miten projekti jatkuu riskin toteutumisen jälkeen. Riskianalyysissä ei erikseen tarkastella kovin epätodennäköisiä riskejä kuten ohjaajan tai asiakkaan vaihtuminen, pitkät laitoksen tietojärjestelmien käyttökatkot tai useamman projektiryhmäläisen poistuminen. 7.1 Viisi suurinta riskiä Seuraavassa taulukossa on esitetty viisi vakavimmaksi koettua riskiä. Näiden riskien muodostamia uhkia seurataan projektin viikkokokouksissa. R2.2 Aikatauluongelmat Kokemattoman projektiryhmän vakio-ongelmia. R2.1 Työmäärien virhearviot Kokemattoman projektiryhmän vakio-ongelmia. R2.3 Projektin laatuongelmat Syntyy helposti lumivyöry projektin edetessä. R3.1 Toteutuksen ongelmat Teknisiin ongelmiin menee helposti paljon aikaa. R1.3 Tiedonkulkuongelmat Kokemattoman projektiryhmän vakio-ongelmia.

15 Projektiryhmän riskit Riski R1.1: Ryhmän jäsenen pitkäaikainen sairastuminen tai poissaolo. Mahdollinen. Siedettävä ->Vakava (loppuvaiheissa). Tiedotetaan poissaoloista ajoissa. Huolehditaan omasta ja projektiryhmän terveydestä. Jaetaan tehtävät tasaisesti projektiryhmän jäsenille. Pidetään ryhmä tietoisena omasta työtilanteesta. Pyydetään apua muulta ryhmältä ennen kuin tilanne muuttuu kriittiseksi. Kartoitetaan jäljellä olevat resurssit ja jaetaan tehtävät uudelleen jäljellä olevien projektiryhmän jäsenien kesken. Riski R1.2: Riski R1.3.1: Ryhmän jäsen keskeyttää. Vähäinen. Huolehditaan siitä, että kaikilla on riittävästi mielekästä tehtävävää eikä toisaalta kukaan tule ylikuormitetuksi. Varaudutaan aikataulujen lipsumiseen. Ryhmän jäsenet pyrkivät varaamaan riittävästi aikaa projektille. Kriittisten tehtävien varavastuutus. Kattava ja järjestelmällinen dokumentointi myös luonnosten ja epäonnistuneiden osaratkaisujen osalta, jotta jäljelle jäävä ryhmä ei käytä aikaa jo kerran hylätyn ratkaisun tutkimiseen. Siirretään keskeyttäneen jäsenen tehtävät varamiehille. Jaetaan tehtävät uudelleen. Jos jäljelle jäävien työmäärä kasvaa liian suureksi, neuvotellaan asiakkaan kanssa alemman prioriteetin ominaisuuksien karsimisesta toteutettavasta tuotteesta. Tiedonkulkuongelmat ryhmän sisällä. Todennäköinen. Siedettävä. Riittävä projektitapaamisten määrä. Runsas sähköpostin käyttö. Kattava ja järjestelmällinen dokumentointi. Myös epävirallisten tapaamisien sekä yksilötason havaintojen johtopäätösten tiedottaminen muulle ryhmälle. Otetaan opiksi. Vaikutukset on arvioitava tapauskohtaisesti.

16 12 Riski R1.3.2: Tiedonkulkuongelmat ryhmän ja asiakkaan välillä. Todennäköinen. Siedettävä. Riittävä asiakastapaamisten määrä. Täsmällinen dokumentointi. Kattava ja järjestelmällinen dokumentointi. Tuotosten läpikäynti asiakkaan kanssa. Lisätään yhteydenpitoa asiakkaan kanssa, jos ongelmia esiintyy. Riski R1.4: Ristiriidat tehtävien valintojen suhteen. Mahdollinen. Siedettävä. Riittävä ajatustenvaihto ja mielipiteiden ilmaisu. Vaihtoehtoihin tutustuminen. Joustava suhtautuminen projektiin. Projektipäällikkö tekee päätöksen, johon muut tyytyvät. 7.3 Projektityön riskit Riski R2.1: Riski R2.2: Työmäärät arvioidaan liian pieniksi Mahdollinen. Toteutettavan ohjelmiston vaatimusten analysointi. Tarvittavien työmäärien tilastointi ja seuranta. Jaettujen tehtävien valmistumisen seuranta. Huolellinen tuntimäärien tilastointi. Joustovarojen hyödyntäminen. Vaatimusten uudelleenpriorisointi. Projekti ei pysy aikataulussa. Todennäköinen. Tarkistuspisteiden käyttö. Työn huolellinen suunnittelu ja toteutumisen seuranta viikkokokouksissa. Suunnitelman jatkuva päivittäminen toteutuneiden työmäärien perusteella. Jaettujen tehtävien valmistumisen seuranta. Huolellinen tuntimäärien tilastointi. Henkilökohtaisten aikatauluongelmien julkituominen. Joustovarojen hyödyntäminen. Vaatimusten uudelleenpriorisointi.

17 13 Riski R2.3: Projektityön laatu on heikko: vaatimusmäärittely, toteutus, testaus tms. epäonnistuu. Mahdollinen. Tuotosten tarkastukset. Ulkopuolisen konsultin käyttö tärkeimpien tuotosten arvioinnissa. Tehtyjen päätösten perusteluiden dokumentointi: miksi päädyttiin tekemään asiat tietyllä tavalla. Tällä tiedolla pystytään jäljittämään kohta, jossa prosessi alkoi epäonnistua. Paluu prosessissa taaksepäin. Onnistuneiden osien tunnistaminen ja uudelleenkäyttö. 7.4 Tekniikan ja työkalujen riskit Riski R3.1: Riski R3.2: Valitut ydintekniikat (esim. käyttöliittymä) osoittautuvat liian vaikeiksi toteuttaa. Mahdollinen. Testataan ja kokeillaan vaikeimpia tekniikoita ja komponentteja. Rakennetaan ohjelmiston ydintoiminnat tekniikkariippumattomiksi. Siirrytään käyttämään yksinkertaisempia ratkaisuja. Valitut työvälineet (kehitysympäristö, versionhallinta) osoittautuvat liian vaikeiksi. Vähäinen. Vähäpätöinen. Välineisiin tutustuminen testiaineistoilla. Omaehtoinen opiskelu. Ei sitouduta välineisiin. Vaihdetaan työkaluja yksinkertaisemmiksi. Keskitetään ongelmallisten työkalujen käyttö niitä parhaiten osaaville ryhmän jäsenille. Riski R3.3: Yhteensopivuusongelmat hajautetussa ratkaisussa (Java/JavaScript-ongelmat). Mahdollinen. Pitäydytään konservatiivisissa ratkaisuissa, jotka toimivat vaatimattomilla laitteilla. Eristetään koodista vaativampia ominaisuuksia edellyttävät osat. Yksinkertaistetaan käyttöliittymää.

18 14 Riski R3.4: Kehitettävä ohjelma tai sen osat tuhoutuvat. Mahdollinen. Vähäinen. Versionhallinnan säntillinen käyttö. Ryhmähakemisto on laitoksen varmuuskopioinnin piirissä. Versionhallinnan säntillinen käyttö. Palataan versionhallintajärjestelmän avulla edelliseen versioon. 7.5 Toteutettavaan ohjelmistoon liittyvät riskit Riski R4.1: Riski R4.2: Muuttuvat vaatimukset. Todennäköinen. Siedettävä. Asiakkaan pitäminen ajan tasalla projektin etenemisestä ja mahdollisista vaikeuksista. Vaatimusten jäädyttäminen. Ohjelmiston selkeät sisäiset rajapinnnat. Vaatimusten priorisointi uusien tarpeiden mukaan. Liian suuret vaatimukset. Vähäinen. Selkeä vaatimussuunnittelu asiakkaan kanssa. Selkeä vaatimusten priorisointi, jotta ongelmatilanteessa voidaan valita mitä vaatimuksia toteutetaan. Pienennetään toteutettavien vaatimusten joukkoa prioriteettien mukaan. Riski R4.3: Toteuttava ohjelmisto ei toimi ollenkaan tai toimii huonosti. Vähäinen. Ydintekniikoiden ja algoritmien kokeilu prototyyppisovelluksilla. Suorityskyvyn kuormitustestaus. Prototyyppien käyttö. Toimivien komponenttien eristäminen jatkoprojektin käyttöön.

19 15 Riski R4.4: Riski R4.5: Asiakas ei ole tyytyväinen toimitettuun ohjelmistoon. Vähäinen. Pyritään ymmärtämään ja dokumentoimaan selvästi asiakkaan tuotteelle asettamat vaatimukset. Pidetään kiinteää yhteyttä asiakkaaseen väärinkäsitysten havaitsemiseksi mahdollisimman aikaisin. Toimitetaan asiakkaalle riittävästi tuotoksia, joiden avulla hän pysyy selvillä tuotteen ominaisuuksista - kysytään myös aktiivisesti asiakkaalta kommentteja tuotoksista. Muutetaan tuotetta tarvittavilta osin ja neuvotellaan tarvittaessa asiakkaan kanssa muutoksista projektiaikatauluun. Toteuttava ohjelmisto ei ole laadukas. Vähäinen. Pyritään ymmärtämään ja dokumentoimaan tarkasti asiakkaan tuotteelle asettamat laadulliset ominaisuudet (nopeus, käytön helppous, virheettömyys). Mietitään testitapaukset huolella ja testataan tuotetta riittävästi kaikissa tuotannon vaiheissa. Ensisijaisesti pyritään muuttamaan tuotetta asiakkaan toiveita vastaavaksi. Mikäli aikataulu muodostuu ongelmaksi, niin pyritään neuvottelemaan asiakkaan kanssa aikataulumuutoksista.