L models. Projektisuunnitelma. Ryhmä Rajoitteiset

Transkriptio

1 Teknillinen Korkeakoulu T Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Projektisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset Jouni Karppinen Dokumenttipohja otettu käyttöön Hannu Kauppinen Lisätty paljon sisältöä Hannu Kauppinen Viimeistelty sisältöjä, lisätty taulukoita kurssin vaatimusten mukaisesti Tuomas Luttinen Kuvausta teknisestä puolesta lisätty Jouni Karppinen & Mitro Kuha Lisätty riskienhallintaa koskeva osuus. Dokumentti tarkastettu ja korjattu palautusta varten.

2 Sisällysluettelo 1 Esittely Projektin tarkoitus ja tavoite Järjestelmä ja ympäristö Oikeudet projektin lopputuloksiin Projektin sidosryhmät Työryhmä Jouni Karppinen Hannu Kauppinen Joonas Kekoni Mitro Kuha Tuomas Luttinen Vesa Salento Kalle Valo Asiakas Kurssin edustajat Projektin tavoitteet ja päätöskriteerit Asiakkaan tavoitteet Työryhmän tavoitteet Jouni Karppinen Hannu Kauppinen Joonas Kekoni Mitro Kuha Tuomas Luttinen Vesa Salento Kalle Valo Yhteenveto Projektin keskeytyskriteeri Projektin päätöskriteeri Resurssit ja talousarvio Henkilöresurssit Materiaalit Talousarvio Työkäytännöt ja työkalut Työkäytännöt Testauskäytäntö Ohjelmointikäytäntö Dokumentointikäytäntö Kokouskäytäntö Yhteenveto henkilökohtaisista harjoituksista Käytetyt työkalut Java GNU Make CVS JLex... 13

3 5.2.5 Cup GNU Linear Programming Kit (GLPK) Bugzilla Trapoli OpenOffice.org Dia CCCC Noudatetut standardit Aikataulutus Yleiskuva Projektin suunnittelu Toteutus Toteutus Toteutus Toimitus Riskienhallintasuunnitelma Riskien kartoitus Projektinaikainen riskienhallinta Riskien luokittelu ja analysointi Valmiit komponentit Osaaminen Mentor Ryhmä Laitteistot Asiakas Viitteet... 19

4

5 1 Esittely 1.1 Projektin tarkoitus ja tavoite Projektin tavoitteena on kehittää Teknillisen korkeakoulun Ohjelmistoliiketoiminnan ja -tuotannon instituutin WeCoTin (Web Configuration Technology) -tutkimusryhmälle lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija, jota tutkimusryhmä voi hyödyntää osana omaa järjestelmäänsä. WeCoTin-projektissa tutkitaan verkkokaupan ja verkostotalouden vaikutuksia tuotekonfiguroinnin prosesseihin ja konfiguraattoreihin. Ideoita demonstroidaan edistyneellä konfiguraattoriprototyypillä. [1] Projektin kuluessa on tarkoitus myös tutustua nykyisiin työkaluihin lineaaristen rajoitteiden tyydyttämistehtävien ratkaisemiseksi sekä näiden käyttökelpoisuuteen verkkosovelluksissa. 1.2 Järjestelmä ja ympäristö Järjestelmä toteutetaan Java-ohjelmointikielellä, jotta asiakas pystyy käyttämään kehitettyä järjestelmää missä tahansa laiteympäristössä, johon on saatavilla Javavirtuaalikone. Järjestelmän arkkitehtuuri perustuu yksinkertaiseen asiakas-palvelinrakenteeseen, ja testikäyttöä varten järjestelmään tehdään selaimella toimiva käyttöliittymä. 1.3 Oikeudet projektin lopputuloksiin Projektin päättyessä projektin lopputulokset luovutetaan asiakkaalle hyödynnettäviksi tieteellisessä tutkimuksessa. Tutkimustarkoitukseen asiakas saa järjestelmään käyttö- ja jatkokehitysoikeudet. Kaupallisista oikeuksista syntyneeseen järjestelmään keskustellaan asiakkaan kanssa erikseen ensimmäisen toteutusvaiheen aikana. 2 Projektin sidosryhmät Projektin sidosryhmät voidaan jakaa kolmeen ryhmään. Oleellisimman ryhmän muodostaa projektia suorittava ryhmä eli työryhmä. Kaksi muuta sidosryhmää ovat asiakkaan edustajat sekä kurssin edustajat. 2.1 Työryhmä Työryhmän muodostavat Jouni Karppinen, Hannu Kauppinen, Joonas Kekoni, Mitro Kuha, Tuomas Luttinen, Vesa Salento ja Kalle Valo. Vastuunjako projektin sisällä on toteutettu matriisiorganisaationa. Vastuunjako on esitetty kaaviossa 1. 1

6 Projektipäällikkö Hannu Kauppinen Palvelin N/A Translaattori N/A Asiakas N/A Ratkaisija N/A Vaatimusten hallinta Vesa Salento Testaus Kalle Valo Arkkitehtuuri Tuomas Luttinen Käytettävyys Mitro Kuha Kielen omaisuudet Joonas Kekoni Dokumentointi Jouni Karppinen Kaavio 1: Organisaatiomatriisi. Matriisiorganisaation ideana on varmistaa asioiden hallinta kokonaisuuksina useista eri näkökulmista. Toisaalta vastuut on jaettu osa-alueisiin tehtävien mukaan (kuten vaatimusten hallinta, testaus tai käytettävyys), toisaalta taas lopputuotteen kokonaisuuksien mukaan (kuten palvelin tai käyttöliittymä). Kokonaisuuksista vastuulliset henkilöt valitaan ensimmäisen toteutusvaiheen alussa. Matriisiorganisaatiossa jokaisesta yksittäisestä tehtävästä on vastuussa kaksi henkilöä, toinen tehtävän luonteen mukaisesti ja toinen lopputuotteen kokonaisuuden mukaisesti. Tällä varmistetaan se, että kaikkia työmenetelmiä noudatetaan samalla tavalla kaikissa komponenteissa ja että lopputuotteen kokonaisuudet ovat todella kokonaisuuksia. Oleellista on kuitenkin huomata, että vastuullisuus tietystä tehtävästä ei tarkoita samaa kuin velvollisuus toteuttaa kyseessä oleva tehtävä. Tehtävät jaetaan resurssitilanteen mukaisesti eri henkilöille. Organisaatiomatriisin mukaisilla vastuullisilla on tällöin velvollisuus huolehtia, että toteuttajan ratkaisut ovat linjassa toisaalta komponentille asetettujen tarpeiden ja vaatimusten kanssa ja toisaalta koko projektin menetelmien kanssa. Lisäetuna matriisimalli luo automaattisen varavastuullisen kullekin tehtävälle, sillä mikäli projektia joudutaan toteuttamaan pitkän aikaa ilman dokumentointivastuuta, siirtyy vastuu dokumentoinnista kustakin komponentista vastaavalle henkilölle. Jotta suojaus olisi täydellinen yhden henkilön poistumista ajatellen, valitaan kullekin toiminnalliselle kokonaisuudelle myös varavastuullinen. 2

7 Projektipäällikkö on matriisin ulkopuolella, sillä hänen vastuulleen kuuluvat erilaiset hallinnolliset tehtävät, joilla ei ole suoranaista yhteyttä mihinkään tehtäväalueeseen tai lopputuotteen kokonaisuuteen. Lisäksi projektipäällikkö ratkoo tarvittaessa mahdolliset erimielisyydet projektiryhmän jäsenten välillä. Kun tehtävillä on useita vastuullisia, ovat ristiriidat mahdollisia. Vastuualueet on esitetty taulukossa 1. Henkilö Jouni Karppinen Joonas Kekoni Mitro Kuha Tuomas Luttinen Vesa Salento Kalle Valo Vastuut Dokumentointi Kielen määrittely Käytettävyys Järjestelmäarkkitehtuuri Vaatimusten hallinta Testijärjestelyt Taulukko 1: Projektiryhmän jäsenten vastuut. Seuraavassa on lyhyt esittelyt kaikista projektiryhmän jäsenistä Jouni Karppinen Jouni on 6. vuosikurssin sähkö- ja tietoliikennetekniikan opiskelija. Hänen pääaineensa on ohjelmistojärjestelmät ja sivuaineina käyttöliittymät ja käytettävyys sekä vuorovaikutteinen digitaalinen media. Teknillisen korkeakoulun lisäksi Jouni opiskelee myös Helsingin Kauppakorkeakoulussa. Jouni on kiinnostunut dokumentointiprosesseista sekä käyttöliittymien kehittämisestä, erityisesti käytettävyydestä ja multimediasta Hannu Kauppinen Hannu on 6. vuoden tuotantotalouden opiskelija, jonka pääaine on yrityksen strategia ja kansainvälisen liiketoiminnan kehittäminen. Sivuaineenaan Hannu lukee digitaalisten tuotteiden kehittämistä. Hannu työskentelee Syslore Oy:n myyntijohtajana, mikä on tarjonnut hänelle mahdollisuuden tutustua kaupallisiin ohjelmistoprojekteihin. Hannu toimii projektissa projektipäällikkönä, mikä tarkoittaa, että hänen vastuullaan on ensisijaisesti raportointi sidosryhmille sekä projektin yleinen hallinointi Joonas Kekoni Joonas opiskelee sähkötekniikan osastolla tietoliikenneohjelmistoja pääaineekseen ja 3

8 sivuaineena digitaalista signaalinkäsittelyä. Hän on työskennellyt 4 vuotta täysipainoisesti ja nyt palannut koulun penkille saadakseen tutkintotodistuksen opinnoistaan. Joonaksen laajaa kokemusta erilaisista ohjelmistoprojekteista tullaan hyödyntämään laajalti toteutusvaiheiden vaikeimmissa tehtävissä kuten mallien ratkaisun optimoinnissa Mitro Kuha mkuha@cc.hut.fi Mitro on opintojensa loppuvaiheessa oleva tietotekniikan opiskelija, joka lukee pääaineenaan vuorovaikutteista digitaalista mediaa ja sivuaineena sisällöntuotantoa. Mitrolla on työkokemusta ohjelmistoliiketoiminnasta kahden vuoden ajalta, mutta hän on tällä hetkellä täysipäiväinen opiskelija. Mitron ensisijainen vastuu on hänen kiinnostuksensa mukaisesti käytettävyys ja käyttöliittymä, mutta koska näiden rooli on projektissa pieni, tulee Mitro osallistumaan myös muihin tehtäviin Tuomas Luttinen tuomas.luttinen@hut.fi Tuomas on tietoteekkari, jonka pääaineena on ohjelmistojärjestelmät. Sivuaineekseen Tuomas lukee vuorovaikutteista digitaalista mediaa. Tuomas on työskennellyt ohjelmistoalalla viimeiset kuusi vuotta, mikä on antanut hänelle merkittävästi näkemystä ohjelmistoprojektien toteutuksesta. Tuomaksen pääasiallinen vastuu on järjestelmän arkkitehtuurin hallinta. Lisäksi Tuomaksen kokemusta jäsennyspuista ja kieliä tulkitsevista järjestelmistä tullaan hyödyntämään projektin toteutusvaiheessa Vesa Salento vsalento@cc.hut.fi Vesa on tietotekniikan opiskelija, jonka pääaineena on tietoliikenneohjelmistot. Hän on työskennellyt päätoimisesti viimeiset neljä vuotta ja siinä sivussa suorittanut tutkintoa eteenpäin. Tällä hetkellä valmistuminen näyttäisi sijoittuvat vuoden 2004 loppuun. Vesan kiinnostus on pääasiassa huolehtia koko järjestelmän toimivuudesta ja huolehtia, että asiat tehdään kunnolla. Vastuuna hänellä on vaatimusmäärittely, mutta hän on myös kiinnostunut testikäyttöliittymän tekemisestä sekä sen testaamisen automatisoinnista Kalle Valo kalle.valo@iki.fi Kalle on 6. vuosikurssin tietoliikennetekniikan opiskelija, jonka pääaineena on ohjelmistojärjestelmät ja sivuaineena tietoliikenneohjelmistot. Kalle on opiskeluaikoina työskennellyt useissa tietotekniikan tuotekehitykseen ja ylläpitoon liittyvissä tehtävissä eri 4

9 yrityksissä. Kallen pääasiallinen vastuu projektin puitteissa liittyy järjestelmän testauksen järjestämiseen sekä projektiryhmän yhteisen koodikannan ympäristöstä huolehtimiseen. Tarpeen mukaan Kalle osallistuu myös muihin tehtäviin. 2.2 Asiakas Projektin asiakkaana toimii Teknillisen Korkeakoulun Ohjelmistoliiketoiminnan ja -tuotannon instituutin WeCoTin-tutkimusryhmä. Tutkimusryhmän projektipäällikkö Juha Tiihonen toimii projektin asiakkaana siten, kuin se kurssin puitteissa on määritelty, ja teknisenä neuvonantajana toimii Juha Nurmilaakso. Asiakas Juha Tiihonen (09) Tekninen neuvonantaja Juha Nurmilaakso (09) Kurssin edustajat Projekti toteutetaan osana Teknillisen Korkeakoulun kurssia T Tietojenkäsittelyopin ohjelmatyö. Tämä tarkoittaa, että asiakkaan ja työryhmän lisäksi projektia toteutettaessa on huomioitava myös kurssin vaatimukset. Kurssin puolesta työhön osallistuu ohjaajana eli mentorina Pietu Pohjalainen. Mentor Pietu Pohjalainen 3 Projektin tavoitteet ja päätöskriteerit 3.1 Asiakkaan tavoitteet Asiakkaan kannalta projektissa on kyse tutkimusprojektia edistävästä hankkeesta, jonka ensisijainen tavoite on saada tutkimusprojektin käyttöön lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija. Koska tämän projektin resurssit ovat rajalliset, on tärkeää, että järjestelmä toteutetaan siten, että sen jatkokehitys on mahdollisimman helppoa. Tieteellisesti oleellinen sisältö liittyy disjunktiivisen ja konjunktiivisen normaalimuodon käyttökelpoisuuden vertaamiseen konfiguraatiotehtävien ratkaisun yhteydessä. Projektin aikana ilmi tulleita asioita julkaistaan mahdollisesti myös tieteellisissä julkaisuissa tutkimusryhmän jäsenten puolesta. Asiakkaan tavoitteet on esitetty taulukossa 2. Ne on numeroitu tärkeysjärjestykseen siten, että ensimmäinen on tärkein. 5

10 Tavoite 1. Saada tutkimusryhmän käyttöön määritelty ratkaisija. 2. Mallien kuvaamiseen käytetty kieli kattaa kaikki suunnitellut käyttötarkoitukset. 3. Pystyä käyttämään järjestelmää pohjana jatkokehitykselle. Varmistuskriteeri Asiakkaan edustaja pystyy ratkaisemaan kielellä esitetyn mallin omalla koneellaan. Kielen määrittely tehdään läheisessä yhteistyössä asiakkaan kanssa, ja asiakas hyväksyy kielen määrittelyn. Asiakas hyväksyy projektin dokumentaation ja lisenssin. 4. Julkaista aiheesta tieteellisiä artikkeleita. Asiakas on tyytyväinen saamaansa palautteeseen kehityksen aikana ilmitulleista asioista. 5. Disjunktiivisen ja konjunktiivisen normaalimuodon käytettävyyden vertailu. 6. Jatkokehitystä voi tehdä myös eisuomalainen tutkija. 7. Järjestelmän pohjana olevaa ratkaisijakomponenttia voi vaihtaa. 8. Järjestelmässä tulee käyttää vain vapaita ohjelmistoja. Dokumentaatio sisältää raportointia muotojen välillä olevista eroista ratkaisun kannalta. Ohjelmakoodi kommentteineen on kirjoitettu englanniksi. Rajapinnat ratkaisijan ja muiden komponenttien välillä ovat selkeitä ja hyvin dokumentoituja. Ulkopuoliset lisenssit eivät rajoita ohjelman levitystä. 9. Projekti valmistuu aikataulussa. Projektin tavoitteet saadaan toteutettua projektin päättymiseen mennessä. 10. Projektin lopputulos on laadullisesti korkeatasoinen. Taulukko 2: Asiakkaan tavoitteet tärkeysjärjestyksessä. 3.2 Työryhmän tavoitteet Määritellään käytettävät menetelmät selkeästi ja pyritään jatkuvasti kehittämään omaa toimintaa. Analysoidessamme työryhmän tavoitteita projektin osalta lähdimme liikkeelle kunkin ryhmän jäsenen henkilökohtaisista tavoitteista pyrkien siten muodostamaan yhteisen näkemyksen tavoitteista ryhmän tasolla. Seuraavassa on esitetty kunkin ryhmän jäsenen henkilökohtaiset tavoitteet ja sen jälkeen työryhmän tavoite Jouni Karppinen Päästä kurssista läpi arvosanalla 4 Oppia tuottamaan laadukasta dokumentaatiota Oppia työskentelemään suuressa ryhmässä Nähdä ja kokea, millaista on olla mukana oikeassa ohjelmistoprojektissa Oppia käyttämään uusia työkaluja 6

11 Nähdä, miten erilaisia menetelmiä ja koulun teoreettisia oppeja voidaan soveltaa käytännössä Hannu Kauppinen Saada pakollinen kurssi suoritettua kunnialla valmistumista ajatellen Oppia ohjelmistoprojektin hallintaa ja johtamista Tutustua uusiin ihmisiin Oppia lisää ohjelmistokehityksestä ja siihen liittyvistä työkaluista ja menetelmistä Luoda lopputulos, johon voi olla itse tyytyväinen Joonas Kekoni Saada hyväksytty arvosana valmistumista varten Oppia mielenkiintoisia asioita kielen kääntämisestä ja rajoitteista Kirjoittaa haastavaa ohjelmakoodia, joka tekee muutakin kuin relaatiotietokannan sisällön käsittelyä Mitro Kuha Suorittaa kurssi hyvällä arvosanalla Kartuttaa kokemuksia tiimityöskentelystä ohjelmistoprojektissa Kasvattaa osaamista ohjelmistoprojektin menestyksekkäästä läpiviennistä projektin kaikilla osa-alueilla Tuomas Luttinen Kurssin läpäisy Ohjelmistotuotantoprosessin oppiminen aikaisempaa tarkemmin Ohjelmointikielen kääntäjät -kurssin oppien syventäminen Uusiin ihmisiin tutustuminen Vesa Salento Saada pakollinen kurssi suoritettua kunnialla valmistumista ajatellen Kasvattaa osaamista ohjelmistoprojektin menestyksekkäästä läpiviennistä projektin kaikilla osa-alueilla Tutustua uusiin ihmisiin Luoda lopputulos, johon voi olla itse tyytyväinen Kalle Valo Kurssin kunniallinen läpäisy Lopputuote, jota kehtaa esitellä omanaan 7

12 3.2.8 Yhteenveto Projektiryhmän jäsenten henkilökohtaisissa tavoitteissa korostuivat kurssin läpäisy kunnialla (arvosanatavoitteena 4), kurssin aihepiirin syvällinen oppiminen sekä lopputuloksen korkea laatu. Lisäksi esille nousivat alan toimijoihin tutustuminen sekä yksittäisten menetelmien tai käytäntöjen opiskelu. Tästä yhteenvetona voidaan todeta, että ryhmän tavoitteena on hyödyntää projekti oppimiskokemuksena ja siten kartuttaa kunkin ryhmän jäsenen henkilökohtaisia valmiuksia osallistua vastaavantyyppisiin projekteihin jatkossa. Tämä tavoite pyritään saavuttamaan työskentelemällä sitoutuneesti projektin eteen ja ylläpitämällä projektin läpi sisäisesti kriittistä suhtautumista omaan työhön. Työtä tehdessä huomioidaan myös kurssin asettamat vaatimukset, jotta tärkein henkilökohtaisista tavoitteista eli kurssin läpäisy tulee kaikkien kohdalta toteutumaan. 3.3 Projektin keskeytyskriteeri Koska projektin loppuunsaattaminen on edellytyksenä useiden työryhmän jäsenten valmistumiselle, ei projektia helposti keskeytetä. Ainoa syy projektin keskeyttämiselle on, että työryhmä katsoo mahdottomaksi sen loppuun saattamisen kurssin vaatimusten mukaisesti. Luonnollisesti, jos kaikki henkilöt jättävät projektin kesken, projekti keskeytyy. 3.4 Projektin päätöskriteeri Projekti toteutetaan vaiheittain kurssin aikataulun mukaisesti. Projekti päättyy viimeisen vaiheen päätyttyä huhtikuussa Resurssit ja talousarvio 4.1 Henkilöresurssit Projektin käytössä on 190 työtuntia projektin työryhmän jäsentä kohti. Näin ollen kokonaisuutena projektiin on käytettävissä 630 henkilötyötuntia. Taulukko 3 kuvaa alustavan työpanosjaon per iteraatiokierros. Hannu Kauppinen Jouni Karppinen Joonas Kekoni Mitro Kuha Tuomas Luttinen Vesa Salento PP I I I DD TOTAL Taulukko 3: Henkilöresurssien jakautuminen projektin vaiheittain. Kalle Valo Tämän lisäksi projektin toteutuminen vaatii henkilöresursseja asiakkaalta. Ennalta arvioituna asiakkaan on sidottava projektin läpivientiin noin 1 tunti joka viikko sekä lisäksi teknisen neuvonantajan aikaa noin 2 tuntia viikossa. Koko projektin kestolta tämä 8

13 tarkoittaa yhteensä noin 75 henkilötyötuntia. Henkilöresurssien suunnittelussa on pyritty huomioimaan riittävä joululoma koko ryhmälle. Lisäksi on huomioitu Mitro Kuhan loma marraskuussa. Muuten painotus on pyritty tekemään projektin alkupäähän, sillä tällä tavoin projektin loppuosaan saadaan enemmän joustavuutta mahdollisten muutosten tai yllätysten varalta. Jos henkilöresursseille halutaan laskea rahallinen arvo, on laskennassa huomioitava projektille kustannuksena myös asiakkaan tekemän työn arvo. Erityisesti tekninen ohjaaja joutuu käyttämään suuren määrän työtunteja projektin menestyksekkään läpiviennin varmistamiseen. Karkea arvio kustannuksista on esitetty taulukossa 4. Henkeä Iteraatioita Työmäärä iteraatiossa Työtunnin hinta Yhteensä Projektiryhmä Tekninen ohjaaja Asiakas Yhteensä Taulukko 4: Henkilötyökustannukset projektissa. 4.2 Materiaalit Projektin materiaalitarve rajoittuu käytännössä ohjelmointi- ja testausympäristöihin. Tähän soveltuvat kuitenkin esimerkiksi Teknillisen Korkeakoulun ATK-keskuksen tarjoamat palvelut, jotka ovat projektin osallisilla automaattisesti käytettävissä. Lisäksi kaikilla ryhmän jäsenillä on oikeus käyttää muita ympäristöjä harkintansa mukaan, mikäli heillä on siihen mahdollisuus. Ajatus on se, että jokainen ryhmän jäsen voi työskennellä siinä ympäristössä, joka on hänelle helpoin. Ryhmän sisäistä tiedonkulkua varten on perustettu kolme sähköpostilistaa, jotka arkistoidaan verkkoon. Koko projektiryhmän kattavan listan lisäksi erilliset sähköpostilistat luotiin kielen ominaisuuksia ja järjestelmän arkkitehtuuria koskevia keskusteluja varten. Kielen ominaisuuksia käsittelevällä listalla on mukana myös asiakkaan edustaja. Muuten listat ovat vain ryhmän sisäiseen käyttöön. Yhteinen koodikanta tallennetaan versionhallintaa ja varmuuskopiointia varten samaan paikkaan Teknillisen Korkeakoulun ATK-keskuksen verkossa. 4.3 Talousarvio Projektissa ei ole tiedossa mitään erityisiä hankintoja, joita varten tarvitsisi varata taloudellisia resursseja. Juoksevat kulut (toimistotarvikkeet, sähkö, laitteiston kulut) ovat merkityksettömiä, eikä niitä tarvitse siksi huomioida. Mikäli merkittäviä investointitarpeita ilmenee, keskustellaan niistä asiakkaan kanssa erikseen. 9

14 5 Työkäytännöt ja työkalut 5.1 Työkäytännöt Testauskäytäntö Projektissa testaus painottuu suurelta osin koko järjestelmän testaamiseen johtuen toteutettavan järjestelmän luonteesta. Järjestelmän toiminta perustuu mallien lukemiseen ja kyseiselle mallille ominaisten rajoitteiden palauttamiseen, joten järjestelmän komponenttien toimiminen yhdessä on tärkeää. Järjestelmätason testaus tullaan automatisoimaan mahdollisimman suurilta osin, jotta kuka tahansa projektiryhmän jäsenistä pystyy ajamaan tärkeimmät testit aina tarvittaessa, esim. ennen muutosten lisäämistä CVS:ään. Uusien testien luominen pitää olla tarpeeksi helppoa ja hyvin dokumentoitua, jotta systeemitestausta saadaan aina tarvittaessa laajennettua. Luonnollisestikin projektissa käytetään myös yksikkötestausta, mutta projektin luonteen vuoksi painopiste on järjestelmätason testauksessa. Perustestit kaikkien luokkien toimivuudesta tehdään yksikkötestauksella. Bugzillaa käytetään puutteiden ja suoranaisten virheiden raportointiin. Kaikki testauksessa esiin tulleet virheet kirjataan Bugzillaan, jotta ne eivät unohdu ja jotta ne voidaan käsitellä systemaattisesti. Myös kehittäjien löytämät bugit, joita he eivät heti ehdi korjaamaan, kirjataan Bugzillaan. Testauksen päävastuu prosessitasolla on Kalle Valolla ja hän huolehtii käytännön järjestelyistä testaukseen liittyen. Testauksesta tehdään tarkempi suunnitelma ensimmäisen toteutusvaiheen yhteydessä. Tässä suunnitelmassa määritellään projektin testauskäytännöt ja erityisesti siihen sovelletut menetelmät tarkemmin Ohjelmointikäytäntö Projektin toteutuskielenä käytetään Javaa ja versiota Ohjelmointityylin pohjana on Sunin ohjelmointityylistandardi, jota täydennetään vielä ryhmän sisäisesti, jotta ei tulisi tulkintaerimielisyyksiä asioista, joihin mainittu standardi ei ota kantaa. Toteutuksen ulkoasussa pyritään selkeään ja luettavaan koodiin käyttämällä hyvin nimettyjä muuttujia ja metodeja sekä kommentoimalla koodia riittävässä määrin. Kaikkien luokkien rajapinnat tullaan kommentoimaan javadoc-tyyliin, jotta lähdekoodista saadaan haluttaessa tulostettua rajapintakuvaukset. Muuta kommentointia käytetään tapauksissa, joissa voidaan olettaa, että koodin toiminta ei koodia syvällisesti tuntemattomalle lukijalle aukea aivan helpolla pelkkää koodia lukien. Pariohjelmointia käytetään tämän projektin kohdalla ainakin kriittisten osioiden toteuttamiseen. Pariohjelmointia suositellaan myös muihin osioihin, mutta ainakin osa niistä tullaan toteuttamaan perinteisellä yksinohjelmoinnilla, jotta saadaan vertailutietoa työtapojen tulosten analysoimiseksi. Pariohjelmoinnilla pyritään parempaan koodin laatuun, selkeämpään toteutukseen ja ryhmän sisäisen tietotason tasaamiseen. Jotta näihin tavoitteisiin päästäisiin, pitää pareja vaihtaa useamman kerran viikossa. Niihin osioihin, joihin käytetään yksinohjelmointia, voidaan mahdollisesti käyttää muita työn jäljen parantamiseen tähtääviä työskentelytapoja, mutta tästä päätetään tarkemmin 10

15 ensimmäisen toteutusvaiheen yhteydessä, kun testaussuunnitelma ja muut vastaavat dokumentit ovat valmistuneet. Lisäksi asiakkaan kanssa on erikseen sovittu, että ohjelmakoodia kirjoitettaessa käytetään työkielenä englantia, eli luokkien nimet ja kaikki ohjelmakoodin sekaan kirjoitetut kommentit ovat englanniksi. Tämän tarkoitus on mahdollistaa ohjelman jatkokehitys myös suomea osaamattomalle henkilölle Dokumentointikäytäntö Projektin lopputulosten kannalta on erittäin tärkeää, että asiakas saa ohjelmakoodin ja käyttöohjeiden lisäksi myös erilaista materiaalia mahdollisen jatkokehityksen tueksi. Tämä asettaa projektissa dokumentoinnille tiettyjä vaatimuksia. Dokumentointikäytännöstä vastaa Jouni Karppinen, joka laatii tarkemmat ohjeet dokumenttien käsittelystä. Pääsääntönä voidaan todeta, että kaikki dokumentit käyvät läpi katselmuksen, ennen kuin ne ovat valmiita. Katselmuksessa kaksi projektiryhmän jäsentä arvioi dokumentin sisällön ja kieliasun. Tarkoitus on kirjoitusvirheiden korjaamisen lisäksi myös varmistua dokumenttien yhtenevyydestä sekä visuaaliselta ilmeeltään että käytetyn terminologian osalta. Huomionarvoista on myös, että dokumenttien pitää olla ymmärrettävissä, sillä dokumenttien käyttäjäryhmä on varsin laaja ulottuen mentorista, jolla ei ole mitään sidettä projektin matemaattiseen taustaan, WeCoTin-projektin tutkijoihin, joiden mielenkiinto kohdistuu ensisijaisesti työryhmän kokemuksiin käytettyjen työkalujen todellisista kyvyistä Kokouskäytäntö Projektin aikana pidettävät tapaamiset voidaan jakaa eri ryhmiin. Tapaamiset, joihin mentor osallistuu, on kurssin puolelta jaettu projektikatselmuksiin (yksi iteraatiota kohden, mukana myös asiakasorganisaation edustajat) ja mentortapaamisiin (yksi iteraatiota kohden, vain mentor ja ryhmä). Näihin tapaamisiin on olemassa valmiiksi tietty runko ja niiden kesto ja ajankohta on ennalta määrätty. Muut tapaamiset voidaan jakaa kahteen ryhmään sen mukaan, ovatko ne projektiryhmän sisäisiä tapahtumia vai osallistuuko niihin myös asiakkaan edustajia. Näiden tapaamisten osalta ryhmän käyttämät kokouskäytännöt vaihtelevat projektin vaiheiden mukaisesti, sillä tarpeet näihin tapaamisiin vaihtelevat merkittävästi. Projektin suunnitteluvaiheessa ryhmä on pitänyt viikottain ryhmäpalaverin, jossa on käyty läpi tehtyjä töitä ja suunniteltu tulevia. Näissä kokouksissa käsiteltyjä asioita on löyhästi valmistellut projektipäällikkö, joka on myös pitänyt kirjaa tehdyistä päätöksistä. Päätökset on kirjattu vapaamuotoisesti ja toimitettu ryhmälle sähköpostilla. Ryhmän sisäisten ryhmäpalaverien lisäksi tapaamisia pidetään myös asiakkaan edustajien kanssa. Projektin suunnitteluvaiheessa nämä ovat olleet pääasiassa työpalavereja liittyen joko järjestelmän arkkitehtuuriin tai mallien kuvaamisessa käytettävään kieleen, mutta projektin jatkuessa näiden tapaamisten painopiste tulee siirtymään projektin edistymisen seurantaan ja mahdollisten haasteiden ratkomiseen. Nyt kokousten valmistelu on ollut arkkitehtuurista tai kielestä vastaavien vastuulla, mutta painopisteen siirtyessä projektin seurantaan siirtyy valmisteluvastuu projektipäällikölle. Projektin seurantakokouksia pidetään ensimmäisen toteutusvaiheen alusta alkaen arviolta 11

16 neljän viikon välein, ellei mitään erityistä ilmene. Kokousten asialistan valmistelee projektipäällikkö keräämällä tietoa ajankohtaisista asioista projektiryhmältä. Kokousten jälkeen projektipäällikkö toimittaa muistiinpanot kokouksen kulusta asiakkaan edustajille, projektiryhmälle sekä mentorille projektin etenemisen seuraamista varten. Seurantakokousten välillä projektipäällikkö tiedottaa sekä asiakasta että mentoria projektin tilasta sähköpostilla Yhteenveto henkilökohtaisista harjoituksista Projektin aikana kukin työryhmän jäsen tutustuu tarkemmin johonkin ohjelmistoprojektin menetelmään ja suunnittelee tämän menetelmän hyödyntämistä projektissa. Menetelmät ja niistä vastaavat henkilöt on esitetty taulukossa 5. Menetelmä Dokumentaation hallinta Kokouskäytännöt Suunnittelumallit (engl. Design patterns) Heuristinen arviointi Pariohjelmointi Systeemitason testien automatisointi Automatisoitu yksikkötestaus Taulukko 5: Henkilökohtaiset ohjelmistoprojektimenetelmät. Vastuullinen Jouni Karppinen Hannu Kauppinen Joonas Kekoni Mitro Kuha Tuomas Luttinen Kalle Valo Vesa Salento Menetelmien tarkemmasta käytöstä päätetään ensimmäisen toteutusvaiheen aikana ja kunkin menetelmän hyödyntämisestä tehdään erillinen suunnitelma. 5.2 Käytetyt työkalut Projektin osalliset käyttävät pääasiassa itse valitsemiaan työkaluja ja ympäristöjä varsinaiseen ohjelmointityöhön. Projektin puitteissa kuitenkin on päätetty tiettyjen työkalujen käytöstä yhteisten toimintojen suorittamiseen. Nämä työkalut ovat Javaohjelmointikieli, GNU Make kääntämiseen ja testaamiseen, CVS versionhallintaan, Cup ja JLex mallien jäsentämiseen, GPLK mallien ratkaisuun, Bugzilla virheraporttien hallintaan, Trapoli työtuntien seurantaan, OpenOffice.org ja Dia dokumentointiin sekä CCCC lähdetiedostojen analyysiin Java Projektissa käytetään ohjelmointikielenä Sun Microsystems Inc.:n kehittämää Javaa. Kääntämiseen ja ohjelman ajamiseen projektin aikana käytetään ATK-keskuksen palvelimille asennettua versiota Java-kääntäjästä ja Java virtuaalikoneesta. Nämä ovat projektin alkaessa Java 2, versio 1.4.1:n mukaisia GNU Make Projektin puitteissa käytetään GNU Make -järjestelmää tiettyjen toimintojen automatisointiin. Tällaisia ovat esimerkiksi komponenttien kääntäminen, yksikkötestaus ja lopullisen tuotteen paketointi. 12

17 5.2.3 CVS Versionhallinta on oleellinen osa projektia, kun ohjelmoijia on useampia kuin yksi. Ilman versionhallintaa on kunkin komponentin kehityksestä sovittava tarkalleen kaikkien kehittäjien kesken, jottei yhtäaikainen kehitystyö tuhoa jonkun tekemiä muutoksia. Lisäksi CVS:n avulla kaikki tuotettu ohjelmakoodi saadaan helposti varmuuskopioinnin piiriin ja erilaisia virheitä voidaan jäljittää ohjelmakoodin muutosten mukaan JLex Jotta tuotteemme osaisi tulkita loogisia malleja, tullaan näiden mallien määrittelemiseen käyttämään kieltä, joka täyttää asiakkaan antamat vaatimukset siitä, millaisia ongelmia kielellä on mahdollista määritellä. Ensimmäiseksi tällä kielellä annetun syötteen analysoinnissa on tekstistä osattava poimia erilaisia avainsanoja ja operaattoreita. Tähän tarkoitukseen on toteutettava selaaja, joka osaa poimia syötteestä sanoja ja antaa niille merkityksiä. Selaajan toteuttaminen käsin ei ole kovin vaikeaa, mutta se on työlästä ja virhealtista. Tämän työvaiheen tekemiseen on siksi suunniteltu automatisoituja selaajageneraattoreita. Projektimme käyttää JLex:iä, joka on Java-ohjelmointikieltä tukeva selaajageneraattori Cup Selaajan antamat terminaalit on järjestettävä jäsennyspuuksi, jotta mallille saadaan aikaan syvempi merkitys, jolloin voidaan esimerkiksi tarkistaa, että onko muuttujan arvo kyseiselle muuttujalle annetun tyypin mukainen. Tätä työvaihetta varten on toteutettava jäsentäjä, jonka toteuttaminen on selaajan tapaan työlästä, virhealtista ja helposti automatisoitavaa. Siksi tässäkin vaiheessa käytetään valmista automatisoitua työkalua, joksi tähän projektiin on valittu Cup, joka on yleiskäyttöinen Java-ohjelmointikieltä tukeva jäsentäjägeneraattori GNU Linear Programming Kit (GLPK) Tämän projektin puitteissa ei ole mahdollista ryhtyä toteuttamaan lineaaristen ongelmien ratkaisijaa nollasta, sillä moisen työmäärä on moninkertaistainen verrattuna tämän projektin laajuuteen. Tästä syystä projektin alussa tutkittiin eri vaihtoehtoja vapaan ratkaisijan löytämiseksi, joka toteuttaisi projektissa vaadittavan matemaattisen rajojen laskentaa käsittelevän osuuden. Ratkaisuna päädyttiin ottamaan käyttöön GNU Linear Programming Kit. GLPK on GNU-lisenssin alla jaettava lineaaristen ongelmien ratkaisija, joka täyttää projektin vaatimukset ratkaisijalle Bugzilla Virheraporttien hallinta on tärkeää varsinkin projektin loppupuolella, kun kehitettyä järjestelmää viimeistellään toimitusta varten. Ohjelmistotuotteisiin tyypillisesti jää kehitysvaiheessa puutteita, joita on korjattava jälkikäteen. Näistä puutteista kertovien raporttien hallintaan on oltava työkalu, jotta aikaa ei turhaan kuluisi hukkaan pohdittaessa, mitkä puutteet on jo korjattu tai mitä tietoa eri puutteista on saatu. Bugzilla on Mozilla-projektin kehittämä järjestelmä, joka tarjoaa hyvin monipuoliset työkalut raporttien hallintaan ja sitä kautta kehitystyön ohjaamiseen. Kurssin puitteissa vain osa järjestelmän mahdollisuuksista on hyödynnettävissä, mutta ottaen huomioon 13

18 projektin luonteen ovat nämä ominaisuudet riittävät. Projektista puuttuu varsinainen järjestelmän ylläpitovaihe, joka tuo tyypillisesti suurimmat vaateet virheraporttien hallintajärjestelmälle useiden ohjelmaversioiden ja erilaisten käyttöympäristöjen kautta Trapoli Projektin resurssien seurannan kannalta on oleellista tietää, paljonko resursseja projektiin on kulloisellakin hetkellä kulutettu ja paljonko vielä suunnitelmien mukaan projekti tulee vaatimaan. Trapoli on kurssin tarjoama työkalu työtuntien suunnitteluun ja kirjaamiseen. Järjestelmä on suunniteltu projektina samalle kurssille aiempana vuonna ja sitä käytetään nyt ensimmäistä kertaa. Se ei ole paras mahdollinen työkalu tähän tarkoitukseen, mutta koska se tarjoaa kurssin henkilökunnalle mahdollisuuden tarkastella kaikkien projektien resurssikäytön tilannetta, pidetään sitä kurssin tarkoitusperiin sopivimpana OpenOffice.org Suuri osa mitä tahansa ohjelmistoprojektia on dokumentaation laatiminen. Koska jokaisella projektiryhmän jäsenellä on oltava mahdollisuus muokata dokumentteja, valitsimme dokumentaatiota varten työkaluksi OpenOffice.org:n. OpenOffice.org on saatavilla sekä Windows- että Linux-ympäristöihin, mikä mahdollistaa jokaiselle työryhmän jäsenelle työskentelyn itse parhaaksi katsomassaan ympäristössä. Ominaisuuksiltaan OpenOffice.org on riittävä projektin tavoitteiden toteuttamiseksi, joten mitään estettä sen käytölle ei ole. Käytössä ovat versiot 1.0 ja Dia Projektin dokumentaatiossa tarvittavat kuvat piirretään Dia-ohjelmalla. Diaan tutustuminen on vielä kesken, joten tarkempi versio Diasta määritellään tarvittaessa CCCC Projektin raportoinnissa tarvitaan tiettyjä tilastotietoja. Näiden keräämiseen käytetään CCCC-ohjelmaa. Samalla ohjelma tarkistaa, että kaikki ohjelmakoodi on kirjoitettu valitun standardin mukaisesti. 5.3 Noudatetut standardit Java-ohjelmoinnissa noudatetaan Sun Microsystems Inc.:n määrittelemää ohjelmointityylistandardia [2]. 6 Aikataulutus 6.1 Yleiskuva Projekti toteutetaan osana Teknillisen Korkeakoulun kurssia, mikä aiheuttaa vaatimuksia projektin aikataulutukselle. Kurssin asettaman perusmallin pohjalta projekti on jaettu viiteen vaiheeseen, jotka ovat projektin suunnittelu ja toimitus sekä kolme toteutusvaihetta näiden välissä. Taulukossa 6 on esitetty kurssin vaatima aikataulutus vaiheille sekä kunkin iteraation pituus viikkoina. 14

19 Iteraatio Ajanjakso Kesto Projektin suunnittelu viikkoa Toteutus viikkoa Toteutus viikkoa Toteutus viikkoa Toimitus viikkoa Taulukko 6: Kurssin aikataulu. Seuraavassa on käyty projektin eri iteraatiot läpi ja esitelty kunkin vaiheen tavoitteet sekä ensimmäisten vaiheiden tehtävät ja toimitettavat tulokset. 6.2 Projektin suunnittelu Tavoitteet: projektin suunnittelu vaatimusmäärittely kielen määrittely ja dokumentointi arkkitehtuurisuunnitelma yleisellä tasolla lineaarimallin suunnittelu kielellä esitetyn mallin jäsentäminen puuksi Toimitettavat tulokset: projektisuunnitelma kielen määrittely tekninen määrittely edistymisraportti Tehtävät: projektin käynnistys projektisuunnitelma kielen määrittely vaatimusmäärittely tekninen määrittely karkealla tasolla luennoille osallistuminen tapaamiset (ryhmän sisäiset, mentor ja asiakas) CVS:n pystytys seuraavan iteraation suunnittelu projektikatselmus ja etenemisraportti 15

20 6.3 Toteutus 1 Tavoitteet: asiakas-palvelin-mallin suunnittelu arkkitehtuurisuunnitelman viimeistely lineaarimallin toteutus kielellä esitetyn mallin kääntäminen linearisaattorin suunnittelu linearisaattorin rajapinnan määrittely ratkaisijan rajapinnan määrittely käyttöliittymän rungon rakentaminen (kielen syöttö) Toimitettavat tulokset: päivitetty projektisuunnitelma päivitetty vaatimusmäärittely päivitetty tekninen määrittely testisuunnitelma rajapintamääritykset tietyille rajapinnoille (ohjelmakoodina) Tehtävät: linearisaattorin ja sen rajapintojen suunnittelu asiakas-palvelin-rakenteen suunnittelu teknisen määrittelyn tarkennus tapaamiset (ryhmän sisäiset, asiakas ja mentor) ratkaisijan rajapintojen määrittelyt lineaarimallin toteutus translaattorin toteutus asiakasohjelman rungon toteutus käännösympäristön rakentaminen Bugzillan valmistelu käyttöä varten testisuunnitelma ja testien valmistelu seuraavan iteraation suunnittelu projektikatselmus ja etenemisraportti 6.4 Toteutus 2 Tavoitteet: 16

21 mallin optimointi ratkaisuajan lyhentämiseksi linearisaattorin toteutus ratkaisijan toteutus käyttöliittymän toiminnallisuuksien rakentaminen asiakas-palvelin-rakenteen toteutus 6.5 Toteutus 3 Tavoitteet: ilmenneiden puutteiden korjaus mallin optimoinnin parantaminen ratkaisuajan lyhentämiseksi dokumentaation päivitys muutosten mukaisesti järjestelmän käytettävyyden parantaminen 6.6 Toimitus Tavoitteet: ilmenneiden puutteiden korjaus järjestelmän viimeistely toimitusta varten dokumentaation ja ohjeistuksen viimeistely asiakkaan kouluttaminen järjestelmän ominaisuuksiin lopullisen järjestelmän toimittaminen asiakkaalle 7 Riskienhallintasuunnitelma 7.1 Riskien kartoitus Projektin riskienhallinta tapahtuu läpi projektin keston ja käsittää riskien kartoittamisen sekä niihin varautumisen. Tähän projektiin liittyvien riskien kartoitus ja analysointi suoritettiin riskienkartoitustilaisuudessa, joka järjestettiin kurssiin T Special Course in Software Engineering: Risk Management liittyen. Ryhmäläisistä kolme osallistuu em. kurssille. Riskien kartoitus suoritettiin vapaalla ideoinnilla (brainstorming), mieleen tulleet riskit luokiteltiin aihepiireittäin kuuteen eri ryhmään, ja niiden vakavuutta ja realisoitumisen todennäköisyyttä ja seurauksia pohdittiin ryhmän kesken. 7.2 Projektinaikainen riskienhallinta Riskienhallinta jatkuu läpi koko projektin. Kurssin edetessä ja tilanteen muuttuessa tutkitaan myös mahdollisten uusien riskien syntyminen ja pyritään minimoimaan niiden vaikutukset. Myös jo tunnistettujen ja olemassaolevien riskien tilaa ja todennäköisyyttä arvioidaan uudelleen kurssin kuluessa. 17

22 7.3 Riskien luokittelu ja analysointi Ideoinnissa esille tulleet riskit luokiteltiin kuuteen ryhmään: valmiisiin komponentteihin, osaamiseen, mentoriin, ryhmän sisäisiin, laitteistoihin ja asiakkaaseen liittyviin riskeihin Valmiit komponentit Projektissa tehtävän ohjelmiston yhtenä osana käytetään ulkopuolista komponenttia, jonka toimivuudesta ja integroitavuudesta ei ole täyttä varmuutta. Vaatimus ulkopuolisen komponentin käyttämisestä on tullut asiakkaalta, joten projektissa tehtävän ohjelmiston toimimattomuutta kyseisen komponentin osalta ei katsota projektin epäonnistumiseksi. Tuote voidaan tehdä muilta osiltaan toimivaksi esimerkiksi käyttämällä valmiin komponentin sijasta toiminnallisuudeltaan vajaata testikomponenttia. Valmiin komponentin aiheuttama riski on siis asiakkaan riski, ja sen toteutumiseen ei varsinaisesti voida vaikuttaa Osaaminen Projektin yleinen vaikeus, työkalujen vaikeus ja vaatimusmäärittelyyn mahdollisesti tulevat liiat ominaisuudet muodostavat riskin, että projektista tulisi ryhmälle liian vaikea. Osaamiseen liittyvä riski todettiin pieneksi, sillä ryhmäläiset ovat kokeneita ja osaavia. Uusien ohjelmien opetteluun varataan aikaa ja ryhmäläiset tukevat ja neuvovat toisiaan, mikäli apua tarvitaan Mentor Mentoriin liittyviksi riskeiksi katsottiin mentorin mahdollinen sairastuminen tai muu syy, minkä takia hän ei enää pystyisi suorittamaan mentorin tehtäviä. Mentorin estymisen aiheuttama riski todettiin projektin kannalta vähäiseksi. Riskin realisoituessa kurssin taholta nimettäisiin uusi mentor. Menetykset olisivat pieniä, lähinnä uuden mentorin perehdyttämiseen kuluvaan aikaan liittyviä. Projektiryhmä ei voi vaikuttaa riskin toteutumistodennäköisyyteen Ryhmä Ryhmään liittyvät riskit ovat ryhmän mahdollinen riitaantuminen ja hajoaminen sekä jonkun ryhmäläisen sairastuminen, kurssin keskeyttäminen tai ajanpuute. Ryhmäläiset ovat hyvin motivoituneita, joten ryhmäläisen keskeyttämistodennäköisyys on pieni. Ryhmän hajoaminen riitaantumisen johdosta on epätodennäköistä, sillä ryhmäläiset ovat mukavia ja leppoisia. Sairastumisia todennäköisesti tapahtuu ja siihen on varauduttu aikatauluttamalla projekti siten, että mitään ei jätetä viimehetkeen. Yksittäisen jäsenen keskeyttämiseen on varauduttu siten, että mikään projektin osa-alueista ei ole vain yhden avainhenkilön hallussa. Riskin toteutuminen tarkoittaisi uutta työnjakoa ja organisointia sekä jäljelle jäävien henkilöiden työmäärän kasvamista, mutta se ei olisi kohtalokasta projektin menestykselliselle läpiviennille Laitteistot Laitteistoihin ja työkaluihin liittyviä riskejä ovat esimerkiksi vialliset työkalut, katkot verkkoyhteyksissä ja ATK-keskukseen liittyvät ongelmat. Projektin CVS on ATK- 18

23 keskuksessa erään ryhmän jäsenen kotihakemiston lisätilassa, joten katko ATKkeskuksen toiminnassa aiheuttaisi ongelmia. Riippuvuutta ATK-keskuksesta pyritään vähentämään tekemällä säännöllisin väliajoin kopioita CVS:n tiedostoista. Mikäli ATK-keskuksen palveluissa on pitkäaikainen katko, tuotekehitys siirretään muuhun ympäristöön, esimerkiksi Niksulaan tai ryhmäläisten omille koneille. Mikäli koodia katoaa tai vaurioituu versionhallinnasta, vaurioitunut koodi pyritään palauttamaan varmuuskopioista. Mikäli verkkoyhteyksissä on pitkäaikaisia katkoja, siirrytään käyttämään vaihtoehtoisia viestintävälineitä Asiakas Asiakkaaseen liittyviä riskejä on esimerkiksi tukihenkilön sairastuminen, tutkimusprojektin keskeytyminen ja asiakkaan vetäytyminen projektista. Ryhmä ei pysty vaikuttamaan asiakkaan aiheuttamaan riskiin. Projekti ei kaadu asiakkaan poisjäämiseen, mutta se vaikuttaa lopputuotteeseen ja aiheuttaa lisää työtä uudelleenorganisoinnin ja opettelun muodossa. Viitteet [1] WeCoTin-verkkosivusto, viitattu , [2] Code Conventions for the Java Programming Language, viitattu , 19