Projektisuunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 22.11.2013 Verkkoperä Alustava luonnos / rakenne. 1.1 29.11.2013 Westin Tekstin kirjoittamista ja rakenteen päivitystä 1.2 1.12.2013 Westin Lukujen 2, 3.2, 5 ja 6 kirjoittamista. 1.3 3.12.2013 Verkkoperä Luvun 1 ja 5 kirjoittamista. 1.4 4.12 2013 Pöyry Luvut 5.1.8 ja 5.1.11. 1.5 6.12.2013 Westin Hienosäätöä. 1.6 8.12.2013 Verkkoperä Luvun 1 ja 3 kirjoittamista. 1.7 10.1.2014 Westin Luvun 5.2 kirjoittamista (QA-suunnitelma). 1.8 17.1.2014 Westin Lukujen 5.2 ja 6.1 päivittämistä. 1. Johdanto 2. Sidosryhmät ja projektin henkilöstö 3. Tavoitteet 3.1 Projektin tavoitteet 3.2 Henkilökohtaiset oppimistavoitteet 4. Resurssit 4.1 Henkilöresurssit 4.2 Muut resurssit 5. Työskentelytavat ja käytännöt 5.1 Käytännöt 5.2 Laadunvarmistussuunnitelma 6. Projektin vaiheet 6.1 Aikataulu 6.2 Sprinttikohtaiset suunnitelmat 7. Riskianalyysi 1
1. Johdanto Tämä projekti on Aalto-yliopiston T-76.4115 Software development project -kurssin pakollinen työ. Projektisuunnitelma on kirjoitettu kurssin henkilökunnalle. Statbeat on selainpohjainen joukkueurheilupalvelu, jossa voi keskitetysti hallita joukkuetta sekä kartuttaa tilastoja. Ensi vuoden aikana Statbeatin käyttäjät tulevat odotusten mukaan lisääntymään turnauspalvelun myötä, jonka takia palvelun kehitys on ajankohtaista. Projektin tavoitteena on parantaa yleisesti käyttäjien mobiilikokemusta applikaatiolla sekä tehdä nykyisistä ominaisuuksista helppokäyttöisempiä. Lisäksi tavoitteena on vertailla natiivin applikaation, hybridin applikaation ja selaimen nopeuseroja. Projektiryhmästä neljä (4) on kehittänyt Statbeatia jo aikaisemmin. Projektin asiakkaana on Fast Monkeys. 2. Sidosryhmät ja projektin henkilöstö Projektiryhmän kokoonpano on taulukossa alla. Henkilöstön yhteystiedot, esimerkiksi sähköpostiosoitteet ja puhelinnumerot, eivät ole tässä julkisessa dokumentissa vaan löytyvät ryhmän Google Drive -tallennuspaikasta, johon asiakkaalla, mentorilla ja kurssin vastuuhenkilöllä on käyttöoikeudet. Nimi Rooli Kurssi Verkkoperä, Sami PP 5115-8cr Westin, Arne QA 5115-8cr Pöyry, Pekka AR 4115-5cr Anttilainen, Eero Keh 4115-5cr Belt, Teemu Keh 4115-5cr Hiltunen, Oskari Keh 4115-8cr Leppäkorpi, Tuomas Keh 4115-6cr Raivio, Lauri Keh 4115-6cr Väyrynen, Joni Keh 4115-8cr Asiakkaana on Eero Vehmanen FastMonkeysilta. Mentorina toimii Petteri Räty. 2
3. Tavoitteet 3.1 Projektin tavoitteet Projektin ensimmäisenä tavoitteena on Statbeat-käyttäjien mobiilikokemuksen parantaminen. Tällä hetkellä Statbeatilla on responsiivinen sivusto, jota halutaan viedä askel eteenpäin hybridi -applikaation toteuttamisella. Hybridi applikaatio tarkoittaa sitä, että natiivin applikaation sisään rakennetaan HTML -pohjaisesti sisältöä. Toisena tavoitteena on, ettei sidota palvelua liikaa natiiviteknologioihin. Asiakkaalle on tärkeää, että otamme huomioon Statbeatin jatkokehityksen. Hybridi -applikaatioon pystyy tekemään natiivisti paljon ominaisuuksia haluttaessa. Tärkein natiivi ominaisuus projektissa on notifikaatiot. Kolmantena tavoitteena on tuottaa laadukasta jälkeä, jotta jatkokehitys onnistuu helposti HTML5 -ja JavaScript/CoffeeScript -painotteisesti. Pyrimme tarkastamaan koodin laadun aina kun sitä kirjoitetaan lisää. 3.2 Henkilökohtaiset oppimistavoitteet Henkilö Sami Arne Oppimistavoite Löytää toimivia toimintatapoja projektin johtamiseen ja saada asioita tapahtumaan. Oppia virheistä ja huomata mikä toimii ja mikä ei. Luoda miellyttävä ryhmähenki ja saada kaikki puhaltamaan yhteen hiileen yhteisen tavoitteen eteen. Työskentelen suuressa IT-talossa, jossa talon prosessien ja tehtävien projektien luonteiden takia ei aina voida tehdä asioita erityisen ketterästi. Tässä projektissa haluan nähdä ja kokea miten hyvin ketterä, hieman Kanban-tyylinen eteneminen onnistuu, ja mitä hyötyjä ja haittapuolia toimintatavassa on. Tavoitteeni on auttaa projektipäällikköä projektin pyörittämisessä, tarjota kehittäjille parhaat mahdolliset edellytykset tehokkaaseen työskentelyyn ja varmistaa korkealaatuinen lopputuote. Pekka Tavoitteena oppia tekemään ja perustelemaan projektin teknisistä asioista tehtäviä päätöksiä. Lisäksi haluan saada kokemusta hybridi applikaatioiden kehityksestä Android ja mahdollisesti myös ios alustalla. Oppia löytämään 3
teknisesti mahdollisimman yksinkertaisia ratkaisuja, jotka täyttävät mahdollisimman hyvin asiakkaan nykyiset ja tulevat vaatimukset. Eero Teemu Oskari Tuomas Lauri Joni Saada hieman lisää kokemusta mobiilikehityksestä, suunnittelusta ja käytettävyyden testaamisesta. Tutustua ketterään ohjelmistokehitykseen ja saada käytännön kokemusta työskentelystä kaupallisen ohjelmistoprojektin parissa. Oppia lisää responsiivisten nettisivujen kehityksestä, Android-kehityksestä sekä hybridiapplikaatioista. Oppia ohjelmistoprojektin käytännön toiminnasta sekä saada kokemusta mobiili- ja Android kehityksestä. Oppia JavaScript koodin järkevä jäsentäminen ja testaaminen sekä projektien kehittäminen Angular.js:llä. Test driven development menetelmän hyödyntäminen kehityksessä. Oppia toimimaan ohjelmistoprojektin jäsenenä ja kehittää osaamistani HTML, Javascript ja CSS tekniikoiden kanssa. 4. Resurssit 4.1 Henkilöresurssit Projektiryhmän budjetoidut kokonaistyömäärät, viikkokohtaiset työmääräarviot ja toteutuneet työtunnit löytyvät erillisestä tuntikirjanpitodokumentista. 4.2 Muut resurssit Projektissa käytetään omia tietokoneita sekä Aalto-yliopiston tiloissa olevia julkisia tietokoneita. Erillisiä kehitys- tai testilaitteita ei ole. Ensimmäisessä iteraatiossa ryhmä työskentelee yhdessä Maarintalon tiloissa, myöhemmin mahdollisesti asiakkaan tiloissa. 5. Työskentelytavat ja käytännöt 5.1 Käytännöt 5.1.1 Iteratiivinen kehittäminen PALAVERI KERRAN VIIKOSSA Perjantaisin ryhmällä on devauspäivä. Tarkoituksena on jauhaa yhdessä kokonainen päivä 4
koodia ja saada tehtäviä valmiiksi. Jossain vaiheessa päivää pidämme palaverin, jossa katsotaan ryhmän status. Selvitetään mitä on saatu aikaiseksi, täytetään tehtävien toteutuneita tunteja ja tuntiarvioita, mietitään uusia tehtäviä ja sovitaan mitä tehdään. TEHTÄVIEN ASETTAMINEN Tehtävät sovitaan yhdessä devauspäivän palavereissa projektipäällikön tai jonkun muun vetäjän aloitteesta. Tehtävät asetetaan sprinttien alkaessa. Kun tehtävä on valmis, se siirretään sprintin aikana tehtyjen tehtävien listaan. Jos sprintin ajaksi asetetut tehtävät saadaan valmiiksi, sprintille voidaan lisätä uusia tehtäviä. Käytämme Trelloa tehtävien hallinnoimiseen kanban -tyylisesti. Esimerkiksi tällä hetkellä Trellossa ovat nämä vaiheet: Backlog, Sprint 0 Done, Sprint 1, Sprint 1 Done. Backlogissa on aiemmissa palavereissa sovittuja tehtäväehdotuksia ja asiakkaan tehtäväehdotuksia, joiden tekemisestä ei ole vielä päätetty. Haluamme tehdä koko ajan tärkeintä tehtävää emmekä voi mitenkään tietää sitä etukäteen. Esimerkissä esitetty Sprint 0 Done jätetään kanbaniin siksi, että kaikki projektin jäsenet tietävät myöhemminkin, mitä on tehty. TEHTÄVÄN JAKAMINEN OSIIN Tehtävät koostuvat eri tyyppisistä osista. Eri henkilöt kuuluvat usein samoihin tehtäviin, joissa he toteuttavat oman osansa. Tehtävän osat voivat koostua mm. ohjelmoinnista, suunnittelusta ja testauksesta. Mitään ei tämän tarkemmin aikatauluteta, vaan oletus on että tehtävät tehdään niin nopeasti ja hyvin kuin osataan, jonka jälkeen mennään eteenpäin. TEHTÄVÄN ELINKAARI Tehtävä ensin määritellään yhdessä, jonka jälkeen se tehdään, testataan, demotaan ja sen jälkeen mietitään pitääkö sitä parantaa. Jos tehtävää pitää parantaa, se laitetaan kanbanin backlogiin josta se saatetaan ketterästi vaihtaa jonkun uuden sprintin tehtävän kanssa. Valmiit tehtävät voidaan näyttää asiakkaalle tai kenelle tahansa helposti tarjoamalla aina linkki uusimman aplikaation lataamiseen. (https://www.dropbox.com/s/ygb5bsou5tz4bbj/statbeat.apk) Kaikki sprintille asetetut tehtävät eivät välttämättä toteudu sprintin aikana, eikä ole tarkoituskaan. Ne voidaan siirtää seuraavalle sprintille. Yritämme kuitenkin arvioida mahdollisimman tarkasti kuinka paljon tehtäviä voidaan sprintin aikana tehdä ja oppia lisää arvioimisesta. TESTI EDELLÄ Tehtävän alussa luodaan testejä valmiille toimivalle funktiolle. Testit eivät aluksi tietenkään onnistu, koska koodia ei ole vielä kirjoitettu. Kun tehtävä on valmis, testit ajetaan läpi ja saatetaan tehdä lisää testejä tarvittaessa. Luomme myös testiympäristön 5
jonka tarkoituksena on automatisoida testaus. Testiympäristö koostuu merkittävästä määrästä yksikkötestejä ja END-to-END -testejä. 5.1.2 Sprinttien suunnittelu SPRINTIN HUUMAA Jaamme projektin sprintteihin kurssin takia. Yksi sprintti voi kestää parista viikosta kuukauteen riippuen joululomista ja muista hätäpäivistä. Yhden sprintin aikana voidaan tehdä tässä projektissa muutamia tehtäviä / henkilö. SPRINTTEJÄ EI SUUNNITELLA ETUKÄTEEN Tarkoituksena on tehdä jatkuvasti projektin tärkeintä tehtävää, jonka takia emme voi suunnitella sprinttejä, koska jatkamme aina vain tärkeimmän tehtävän tekemisellä. Tällä tavalla teemme suunnittelussa vähiten virheitä ja pystymme muuttamaan päätöksiä tarvittaessa nopeasti. TEHTÄVIEN ARVIOINTI SPRINTEITTÄIN Vaikka emme suunnittele etukäteen sprinttejä, pyrimme arvioimaan kurssin takia mahdollisimman tarkasti mihin pystymme sprintin aikana ja päätämme tehtävät sprintin alkaessa. Emme siis suunnittele sprinttejä etukäteen, mutta suunnittelemme tehtävämme silloin kun sprintti alkaa. PARIOHJELMOINTI VAIKEUTTAA ARVIOINTIA Projektiryhmässämme on eritasoisia henkilöitä, jonka takia päätimme käyttää pariohjelmointia. Pariohjelmoinnin tarkoitus tässä projektissa on, että devauspäivinä parista kokemattomampi oppii asioita nopeasti. Ryhmämme muodosti kaksi paria: Lauri ja Joni sekä Eero ja Tuomas. Pariohjelmointi vaikuttaa tehtävien tuntiarvioihin. 5.1.3 Dokumentointi Projektissa käytetään Google Drivea dokumenttien luomiseen ja tallentamiseen. Koko ryhmällä, asiakkaan edustajalla ja mentorilla on käyttöoikeudet tallennuspaikkaan. 5.1.4 Riskienhallinta Projektin riskienhallintaprosessi on seuraavanlainen: 1. Riski tunnistetaan ja sen hetkinen tilanne kartoitetaan 2. Riski analysoidaan yrittämällä selvittää sen vaikutukset ja erilaiset korjaavat toimenpiteet 3. Riskin realisoituessa suoritetaan korjaavat toimenpiteet 4. Korjaavien toimenpiteiden vaikutus tarkistetaan ja riskin tilanne kartoitetaan uudestaan 6
Riskienhallintaa suoritetaan koko projektin elinkaaren ajan. Riskiloki löytyy erillisestä dokumentista. 5.1.5 Työajan seuranta Kokonaistyöajan seurantaa suoritetaan viikkotasolla. Projektiryhmä merkitsee tunnit vähintään kerran viikossa Google Drivessa sijaitsevaan tuntikirjanpitotaulukkoon, johon on merkitty henkilökohtaiset työmäärätavoitteet (kurssin pistemäärän mukaisesti, 1 opintopiste vastaa 27 tuntia) sekä iteraatio- ja viikkokohtaiset aikatauluarviot. Ominaisuus- tai tehtäväkohtaiset tunnit merkitään Trelloon (kts. luku 5.1.6 Viestintä). Ryhmä käyttää Scrum for Trello -selainlisäosaa, joka hyödyntää Trellon tietyllä syntaksilla merkittyjä työmääräarvioita ja kokonaistuntimääriä. 5.1.6 Viestintä Ryhmä työskentelee kerran viikossa (pääsääntöisesti perjantaisin) yhdessä samassa tilassa, jolloin viestintä onnistuu kasvokkain. Kun kaikki osallistujat ovat paikalla, pidetään lyhyt Scrum-tyyppinen palaveri jossa kukin kertoo mitä on tehnyt sitten viime palaverin, mitä ongelmia on ollut ja mitä tulee tekemään seuraavaksi. Yhteisten työskentelypäivien ohella pääasiallisena viestintämenetelmänä käytetään Flowdockia, jonka käyttöoikeudet on myönnetty projektiryhmälle, asiakkaan edustajalle ja mentorille. Viestintää muissa järjestelmissä pyritään välttämään, jotta kaikki oleellinen viestintätieto löytyisi yhdestä järjestelmästä. Projektinhallintajärjestelmänä toimii Trello, jonne kirjataan ominaisuudet ja tehtävät sekä niiden työmääräarviot ja toteutuneet työtunnit. Trellosta ryhmän jäsenet näkevät mitä muut tekevät ja saavat kokonaiskuvan projektin etenemisestä. Trello on integroitu Flowdockiin, jolloin sinne tulee merkintä Trellossa tapahtuneista muutoksista (esim. ominaisuus valmistuu). Ryhmän Trello-alue ei ole julkisessa käytössä, mutta asiakkaalla, mentorilla ja kurssivastuuhenkilöllä on käyttöoikeudet. Ryhmällä on oma Google-kalenteri, johon merkitään tapaamiset, deadlinet ja muut projektiin liittyvät tapahtumat. Kalenterimerkinnöistä ja -päivityksistä tulee automaattisesti tieto Flowdockiin. Projektin GitHub-repositorio on myös integroitu Flowdockiin, jolloin versiohallintamuutoksista ja GitHub-issueista tulee automaattinen ilmoitus. Ryhmällä on kotisivu dokumenttien toimittamista ja tärkeiden resurssien ja linkkien jakamista varten. 7
5.1.7 Bugien seuranta Löydetyt bugit kirjataan GitHubiin issueiksi. Laajemmista ongelmista tai isommista virheistä tehdään Trelloon tehtävä, joka aikataulutetaan tilanteesta riippuen joko kyseiseen tai tulevaan sprintiin (alhaisen prioriteetin tehtävän tapauksessa se saatetaan asettaa backlogiin odottamaan tarkempaa aikataulutusta). 5.1.8 Versionhallinta Projektissa käytetään asiakkaan myöntämiä GitHub-versiohallintarepositoriota. Sovelluksen taustalla pyörivälle verkkosivustolle ja jokaiselle mobiilisovellukselle on omat repositoriot. Kaikki kunkin sovelluksen käyttämä sisältö on sen omassa repositoriossa. Jokaisen commitin tulisi sisältää vain yhteen asiaan liittyviä muutoksia, ja sillä tulisi olla sen sisältöä kuvaava selkeä kommentti. Verkkosivustossa pyritään siihen, että kaikki uusi koodi lisätään omaan branchiin, josta joku toinen ohjelmoija käy hyväksymässä tämän muutokset, ennen kuin ne lisätään varsinaiseen tuotantoversioon. Verkkosivuston repositorio on linkitetty testauspalveluun, joka ajaa jokaiselle muutossarjalle kaikki testit. Koska verkkosivusto päivittyy jatkuvasti, ei sen repositoriossa käytetä tageja. Mobiilipuolen ohjelmissa jokainen sovelluskauppaan lähetetty versio merkitään sen versionumeroa vastaavalla tagilla. Mobiilipuolella julkaisujen välillä pidetään kirjaa tehdyistä muutoksista, jotta nämä tiedot voidaan näyttää ohjelman käyttäjille ohjelmakaupassa. Kaikki suuremmat prototyyppitestaukset pyritään tekemään omiin brancheihin, jotta niiden välillä voidaan liikkua helposti. 5.1.9 Prosessien kehittäminen Jokaisen iteraation viimeisessä tapaamisessa ryhmällä on retrospektiivi, jossa käydään läpi iteraation tapahtumat. Ryhmä yrittää selvittää mikä onnistui, mikä olisi voinut mennä paremmin ja miten tilannetta voidaan parantaa seuraavassa iteraatiossa. PI-vaiheen retrospektiivissä 5.12.2013 todettiin, että vaikka projekti oli lähtenyt vauhdilla käyntiin ja tuloksia saatiin nopeasti, olisi projektin kokonaiskuvan ja vision muodostamiseen voinut käyttää enemmän aikaa ryhmänä yhteisesti. Päätettiin, että seuraavan iteraation alussa pidetään ylimääräinen suunnittelusessio, jossa asiaan paneudutaan tarkemmin. 5.1.10 Vaatimusmäärittely Ryhmä suorittaa vaatimusmäärittelyä asiakkaan kanssa käytyjen keskustelujen perusteella. Vaatimukset kirjataan korkealla tasolla Trellon backlog-listaan ja pilkotaan pienempiin 8
osiin checklistin avulla. Ryhmä määrittelee vaatimuksille työmääräarviot ja priorisoi ne asiakkaan toiveiden mukaan. 5.1.11 Arkkitehtuurisuunnittelu Rakennettavan projektin arkkitehtuurista päätettiin asiakkaan kanssa tehtyjen kattavien keskustelujen aikana asiakkaan tavoitteiden perusteella. Kyseisiä keskusteluja järjestettiin muutamia kertoja, ja niiden välillä suoritettiin eri vaihtoehtojen teknistä arviointia. Kyseisissä keskusteluissa kaikki suurimmat tekniset ratkaisut lyötiin lukkoon. Ketterän kehitystekniikan ja joustavien tavoitteiden takia koko projektin kaikkia arkkitehtuurisia päätöksiä ei yritetä tehdä heti projektin alkuvaiheessa, vaan ilmenevät ongelmat ratkaistaan kun ne tulevat ajankohtaisiksi. 5.2 Laadunvarmistussuunnitelma 5.2.1 Laatutavoitteet ID Nimi ja kuvaus Toteutus ja verifiointi Prioriteetti LT 1 Helppokäyttöisyys Sovelluksen on oltava helppokäyttöinen ja helposti opittava. Arviointi ryhmässä sisäisesti, asiakkaan kanssa ja vertaistestausryhmän kanssa. Korkea LT 2 Nopeus ja sulavuus Sovelluksen on toimittava sulavasti, ilman selkeästi häiritsevää hidastelua, nykyaikaisilla puhelimilla. Arviointi ryhmässä sisäisesti, asiakkaan kanssa ja vertaistestausryhmän kanssa. Testausta eri puhelinmalleilla ja -käyttöjärjestelmillä. Korkea LT 3 Ylläpidettävyys Sovelluksen on oltava helposti ylläpidettävä ja jatkokehitettävä asiakkaan resursseilla. Koodin arviointi ja katselmointi ryhmän sisällä. Natiivikoodin on oltava mahdollisimman kevyttä pitäen suurimman osan sovelluslogiikasta frontend-puolella. Korkea LT 4 Koodin laatu ja ymmärrettävyys Koodi on laadukasta, yhtenevää sekä helposti ymmärrettävää ja muokattavaa. Noudatetaan ohjelmointikonventioita ja -standardeja. Koodia vertaiskatselmoidaan (Git pull Kohtalainen 9
request) ja analysoidaan ryhmän sisällä. 5.2.2 Laatukäytännöt Käytäntö Kuvaus Vaikuttaa Milloin Yksikkötestaus Koodi yksikkötestataan ja testejä ajetaan jatkuvasti (myös CI:n avulla, kts. jatkuva integraatio). TDD (testausvetoinen kehitys) Mahdollisuuksien mukaan hyödynnetään TDD:tä, jossa (yksikkö-)testi kirjoitetaan ennen sitä toteuttavaa funktiota/toimintoa. Kaikkea koodia ei ole järkevä tai edes mahdollista testata, mutta mikäli koodi on testattavaa, kirjoitetaan testi ensin. Pariohjelmointi Ominaisuuksia toteutetaan pariohjelmoinnin avulla, jossa kaksi henkilöä kirjoittaa koodia ja selvittää ongelmia yhdessä. Koodin vertaiskatselmointi Koodi vertaiskatselmoidaan Githubin pull requestien avulla. Kts. luku 5.1.8. Koodin staattinen analysointi Ohjelmakoodia analysoidaan erilaisilla työkaluilla (esim. jshint), jotka pyrkivät löytämään syntaksi- ja logiikkavirheitä. Asiakasviestintä Asiakkaan kanssa viestitään jatkuvasti. LT1, LT2, LT3 Vertaistestaus Vertaistestausryhmä testaa sovellusta toisen iteraation aikana ja raportoi löydöksensä ja kommenttinsa kirjallisesti. LT1, LT2 I2 Tutkiva testaus (exploratory testing) Ryhmän jäsenet suorittavat tutkivaa testausta kehitystyön ohessa. Lisäksi ryhmä järjestää I1:n ja I2:n aikana keskitetyt ET-istunnot. LT1, LT2 I1, I2 / jatkuvasti Koodin refaktorointi Koodia ylläpidetään, modularisoidaan ja parannellaan jatkuvasti tarpeen mukaan. 10
Bugien seuranta Bugien seurannassa ja raportoinnissa käytetään Githubin issueita. Kts. luku 5.1.7. Jatkuva integrointi Versiohallintarepositorio kytketään FastMonkeysin Travis CI -instanssiin, joka ajaa testit jokaisen versiohallintamuutoksen yhteydessä. Lisätietoja luvussa 5.1.7. I1:stä lähtien jatkuvasti Testitapauspohjaine n testaus I1:n ja I2:n lopussa ryhmä suorittaa testausta ennalta määriteltyjen testitapausten pohjalta. Kts. testitapausdokumentti. LT1, LT2 I1:n ja I2:n lopussa Koodikonventiot ja tyyliohjeet Frontendin osalta noudatetaan AngularJS:n ja Javascriptin tyyliohjeita. Androidissa seurataan Oraclen Java Code Conventionsia. ios-sovelluksen osalta pyritään mahdollisimman pitkälle noudattamaan Applen ohjeita. 6. Projektin vaiheet 6.1 Aikataulu 6.2 Sprinttikohtaiset suunnitelmat Projektin sprinttikohtaiset suunnitelmat löytyvät ryhmän Trello-alueelta (ei julkinen). 11
7. Riskianalyysi Projektin riskianalyysi löytyy erillisestä dokumentista. 12