Tik-76.115 Projektisuunnitelma

1. Johdanto

1.1 Yleiskuvaus projektista

Tämä projekti on TKK:n Tik-76.115 Tietojenkäsittelyopin ohjelmatyö -kurssin harjoitustyö. Projektin asiakkaana on Osuuspankkikeskus Oyj, jolle projektin tarkoituksena on tuottaa ratkaisu pankin ja pankin asiakkaan välinen tietoturvaratkaisu.

1.3.1 Projektiryhmän jäsenet

Projektiryhmässä on neljä jäsentä. Allaolevasta listasta käy nimitietojen lisäksi ilmi kullekin jäsenelle osoitettu pääasiallinen työtehtävä. Työtehtävät ovat kuitenkin osittain muodollisia ja jokainen ryhmän jäsen on yhteisvastuussa kaikista projektin vaiheista ja osista.

Nimen perässä on esitetty suluissa nimikirjaimet, joita käytetään myöhemmin dokumentissa viitatessa kyseiseen henkilöön.

Rooli	Nimi	E-mail
Projektipäällikkö	Markus Vartiovaara (MV)	mvartiov@cc.hut.fi
Laatupäällikkö	Petteri Kaski (PK)	pkaski@cc.hut.fi
Suunnittelupäällikkö	Arto Vuori (AV)	avuori@cc.hut.fi
Ohjelmoija	Juha Räsänen (JR)	juha.rasanen@hut.fi

1.3.2 Muut projektin osapuolet

Asiakas: Osuuspankkikeskus	Yhteyshenkilö ja ohjaaja: Kauko Metsä	E-mail: kauko.metsa@osuuspankki.fi
Kurssin edustaja:	Kari Alho	kari.alho@hut.fi

1.3.3 Kotisivu

Projektiryhmä luovuttaa asiakkaan kanssa erillisessä työsopimuksessa määritellyn tuotteen ja siihen liittyvät sopimuksessa esitetyt dokumentit asiakkaalle. Työsopimusta ei toistaiseksi ole tehty.

2.1 Yleinen jaottelu

Projekti on jaettu ohjelmatyökurssin vaiheiden mukaisesti

• projektin suunnitteluvaiheeseen
• määrittelyvaiheeseen,
• suunnitteluvaiheeseen,
• ensimmäiseen prototyyppivaiheeseen
• toiseen prototyyppivaiheeseen
• luovutusvaiheeseen

Vaiheiden yhteisinä tavoitteina ovat

• tiivis yhteistyö asiakkaan kanssa
• eri vaiheille asetettujen tavoitteiden saavuttaminen siten, että projekti edistyy kohti lopputuotetta
• asetetussa aikataulussa pysyminen
• laatu jokaisessa vaiheessa

Ohjelmatyökurssin aikana on joukko jatkuvia prosesseja, joista huolehtiminen on kriittinen edellytys projektin onnistumiselle. Näiden prosessien tunnistaminen heti alkuvaiheessa on välttämätöntä. Alla olevassa taulukossa on kuvailtu näistä tärkeimpiä. Jos prosessin luonne on erityisesti jonkun ryhmän jäsenen erikoisalaa on hän merkitty vastuuhenkilöksi ko. prosessin suhteen. Kuten edellä jo mainittiin, ryhmän kaikilla jäsenillä on kuitenkin täysi vastuu projektin kaikista osista. Vastuuhenkilöiden avulla pyrimme vain selventämään työnjakoa.

Osa prosesseista jatkuu koko projektin ajan, osa on erikseen merkitty aikatauluun (esim. palaverit). Prosesseista voidaan ajatella saatavan tulos, joka on myös kuvattu lyhyesti taulukon neljännessä sarakkeessa. Vastuuhenkilö huolehtii, että määritelty lopputulos toteutuu aikataulussa määritetyn aikajänteen puitteissa.

Tehtävä	Vastuuhenkilö(t)	Aikajänne / Deadline	Lopputulos
Projektisuunnitelman ja määritelmädokumenttien kehittäminen ja päivittäminen	MV	Jatkuva	Kattava kuvaus projektista
Tuntiraporttien laatiminen	Kaikki	Koko projekti, raportit kootaan maanantaisin	Projektiin käytetyt työtunnit
Projektipalaverit	Kaikki	Aikataulun mukaisesti	Tiivis yhteistyö asiakkaan kanssa johtaa haluttuun lopputulokseen
Tekninen suunnittelu	AV (+kaikki)	Jatkuva	Teknisen kokonaisuuden hallinta tekee työstä tehokasta
Koodin toimivuudesta huolehtiminen	PK	Jatkuva	Ohjelmiston kasvaessa tulee olla toimiva perusta minkä päälle kehittää.
Projektiryhmä- palaverit	Kaikki	Aikataulun mukaisesti	Projektin etenemistä kontrolloidaan pitämällä tiiviisti ryhmän omia palavereja
Asiakas-palaverit	Kaikki + Asiakas	Aikataulun mukaisesti	Ryhmä pitää aina tarvittaessa palavereja asiakkaan kanssa
Projektipalaverit	Kaikki + Asiakas + kurssin edustaja	Aikataulun mukaisesti
WWW-sivujen päivitys	MV (+kaikki)	Jatkuva	Ryhmän lisäksi myös kurssin ja asiakkaan vastaavat voivat seurata projektin kehitystä.

Luvuissa 2.2 - 2.7 on näiden perustoimintojen lisäksi kuvattu jokaiselle vaiheelle tyypillisiä asioita kuten dokumentaatiota.

Dokumenttitaulukossa on esitetty kurssin eri vaiheissa palautettavat dokumentit. Palaverien pöytäkirjat sekä mahdollinen asiakkaalle toimitettava erillinen dokumentaatio on eritelty kohdassa "Muu dokumentaatio".

Jokaisella dokumentilla on määritelty päävastuuhenkilö, jonka tehtävänä on huolehtia kyseisen dokumentin tekemisestä (tai ainakin kasaamisesta, toimittamisesta ja aikataulunmukaisesta valmistumisesta). Vastuuhenkilön tulee palauttaa dokumentti hyvissä ajoin vastaavalle tarkastajalle, joka lukee sen läpi ja tekee tarvittaessa muutoksia ja tarkennuksia.

2.2.1 Vaiheen kuvaus

Projektin suunnitteluvaiheessa kartoitetaan asiakkaan vaatimuksia projektin hallinnan sekä lopputuotteen toiminnallisuuden suhteen. Suunnitellaan projektin läpivienti käytettävissä olevilla resursseilla ja laaditaan aikataulu johon kaikki projektin osapuolet sitoutuvat. Lisäksi projektin riskienhallinta kuuluu olennaisena osana projektin suunnitteluun.

2.2.2 Vaiheen tavoitteet

Projektin suunnitteluvaiheen tärkein tavoite on saada projekti onnistuneesti käyntiin. Projektin eri osapuolien välille on saatava yhteysymmärrys lopputuotteen vaatimuksista sekä projektin aikataulusta.

Tavoite	Strategia
Lopputuotteen vaatimusten huolellinen tarkka määrittely	Käyttää paljon aikaa huolellisen vaatimusmäärittelyn tekemiseen. Sen päälle (ja jota täydentäen ja täsmentäen) projektia voidaan joustavasti rakentaa ja viedä eteenpäin oikeaan suuntaan
Työn jakaminen, aikataulusta sopiminen	Työ jaetaan kurssin antaman viitekehyksen mukaisesti osiin. Työmäärä mitoitetaan siten, että jokaisessa vaiheessa on mahdollista saavuttaa haluttu lopputulos. Ryhmä tutustuu aikatauluun niin että kaikki osaavat varata resursseja riittävästi sovittuina ajankohtina.

2.2.3 Vaiheen ennakoidut tulokset

Asiakkaan kanssa tarkkaan laadittu vaatimusmäärittely. Vaatimusmäärittelyä tarkennetaan projektin aikana, mutta jo suunnitteluvaiheessa laaditun määrittelyn tulee olla mahdollisimman kattava ja suuntaa-antava.

2.2.4 Vaiheen dokumentaatio

Suunnitteluvaiheessa laadittu projektisuunnitelma on keskeinen työväline eri tehtävien ja töiden hallinnassa, sekä yhdessä aikataulun kanssa se asettaa keskeisille tavoitteille ja vaatimuksille aikarajat.

Vaatimusmäärittely on asiakkaan kanssa yhteistyössä tehty määritelmä lopputuotteen toiminnallisuudesta sekä kaikesta siihen liittyvästä. Vaatimusmäärittelystä käy ilmi ohjelmatyölle asetetut vaatimukset toiminnallisuuden ja dokumentaation osalta. Lopputuotteen onnistuneisuuden ja laadun evaluointi suoritetaan myös tätä määrittelyä vastaan. Vaatimusmäärittelyllä on lisäksi merkittävä rooli ryhmän sisäisenä työkaluna.

Edistymisraportti antaa palautetta eri osapuolille projektin nykytilasta. Kuinka on pystytty pysymään suunnitellussa aikataulussa. Mitä tehtäviä on suoritettu ja mitä ongelmia on tullut vastaan. PS-tuntiraportti kertoo ryhmän jäsenten käyttämät työtunnit projektin suunnitteluvaiheessa.

Kurssin dokumentti	Vastuu (tarkastaja)	Kuvaus
Projektisuunnitelma	MV (PK)	Suunnitelma projektin läpiviemisestä ja aikataulusta. Projektin riskienhallinta.
Vaatimusmäärittely	Kaikki	Asiakkaan vaatimukset tuotteen toiminnallisuuteen
Edistymisraportti	JR (MV)	Kuvaus projektin nykytilasta.
PS-tuntiraportti	Kaikki	Projektin suunnitteluvaiheeseen käytetyt työtunnit

Muut dokumentit ja raportit	Vastuu (tarkastaja)	Kuvaus
Työsopimus-proto	Kaikki	Projektiryhmä ja asiakas tekevät sopimuksen ohjelmatyön tekemisestä. Sopimuksen liitteenä käytetään vaatimusmäärittelyä.
Palaverien pöytäkirjat	MV (JR)	Ryhmän ja asiakkaan pitämistä palavereistä tehdään lyhyet mutta ytimekkäät pöytäkirjat.

2.2.5 Vaiheen toteutuminen

Projekti suunniteltiin huolellisesti. Tuotteen tarkempi määrittely siirrettiin seuraavaan vaiheeseen vaikkakin alustavia suunnitelmia tehtiin jo tässäkin vaiheessa.

2.3.1 Vaiheen kuvaus

Määrittelyvaiheessa paneudutaan tarkemmin vaatimusmäärittelyyn ja siihen mitä se pitää sisällään. Määritellään projektissa toteutettava ohjelmisto projektin nykyhetken puitteissa. Ohjelmiston arkkitehtuuri ja toimintaympäristö analysoidaan niin, että toiminnallisen määrittelyn pohjalta voidaan tehdä tekninen määrittely. Erityisesti painotetaan ohjelmiston rajapintoja muihin systeemeihin sekä käyttäjille.

2.3.2 Vaiheen tavoitteet

Määrittelyvaiheen ehdottomasti tärkein tavoite on mahdollisimman kattava toiminnallinen määrittely. Tämä dokumentti on keskeinen lähtökohta ohjelmiston tekniseen määrittelyyn sekä toteutukseen. Tavoitteena on analysoida useita toteutustapoja, niiden hyviä ja huonoja puolia. Tässä vaiheessa pitäisi olla selvää mitä toimintoja ohjelmisto pitää sisällään ja mitkä toiminnot jätetään projektin ulkopuolelle.

2.3.3 Vaiheen ennakoidut tulokset

Asiakkaan kanssa laadittu lopputuotteen toiminnallinen määrittely vaatimusmäärittelyn päälle. Tämä antaa hyvän pohjan ohjelmiston tarkalle tekniselle määritykselle sekä toteutukselle. Asiakkaan ja ryhmän kanssa on päästy yhteysymmärrykseen ohjelmiston toteutettavista toiminnoista.

2.3.4 Vaiheen dokumentaatio

Projektin suunnitteluvaiheessa tuotettuun projektisuunnitelmaan tarkennetaan suunnitteluvaiheen suunnittelua sekä riskienhallintaa. Vaatimusmäärittelyä tarkennetaan, toiminnallisen määrittelyn mahdollisesti antamien uusien tietojen valossa.

Toiminnallinen määrittely on projektin suunnitteluvaiheen aikana aikaansaadun vaatimusmäärittelyn analyysi. MÄ-tuntiraportti kertoo ryhmän jäsenten käyttämät työtunnit projektin määrittelyvaiheessa.

2.4.1 Vaiheen kuvaus

Suunnitteluvaihe on lopputuotteen toteutuksen kannalla tärkein vaihe. Siinä paineudutaan entistä syvemmälle toteuttavaan ohjelmistoon. Määritellään kaikki ohjelmistoon liittyvät modulit sekä rajapinnat. Tarvittaessa laaditaan pseudokoodi joistain palasista. Lisäksi laaditaan testaussuunnitelma tuotettavan ohjelmiston testauksesta. Määritellään mitkä modulit testaan erillisinä, mitkä yhdessä sekä kuvataan testausympäristö.

2.4.2 Vaiheen tavoitteet

Suunnitteluvaiheessa on kaksi samanarvoista ja erittäin tärkeää tavoitetta. Ensinnäkin tavoitteena on laatia perinpohjainen suunnitelma toteutettavasta ohjelmistosta, että itse toteutus olisi erittäin virtaviivaista ja tehokasta. Toiseksi kattavan, virheet poissulkevan testaussuunnitelman laatiminen.

2.4.3 Vaiheen ennakoidut tulokset

Suunnitteluvaiheen tuloksena on laaja ja yksityiskohtainen suunnitelma toteutettavasta ohjelmistosta sekä sen toimivuuden testaamisesta.

2.4.4 Vaiheen dokumentaatio

Projektisuunnitelmaa tarkennetaan ensimmäisen prototyyppivaiheen suunnittelua sekä siihen liittyvän riskienhallinnan osalta. Lisäksi toiminnallista määrittelyä tarkennetaan tarvittaessa.

Tekninen määrittely sekä testaussuunnittelma on avaindokumentit tässä vaiheessa. Niistä käy ilmi toteuttavan ohjelmiston toiminta ja ympäristö ohjelmistoteknisesti määriteltynä sekä miten ohjelmiston toimivuus testataan.

SU-tuntiraportti kertoo ryhmän jäsenten käyttämät työtunnit suunnitteluvaiheessa.

Kurssin dokumentti	Vastuu (tarkastaja)	Kuvaus
Projektisuunnitelma	MV (PK)	Tarkennettu projektisuunnitelma
Toiminnallinen määrittely	AV (Kaikki)	Tarkennettu toiminnallinen määrittely
Tekninen määrittely	Kaikki	Määrittely ohjelmiston arkkitehtuurista ja eri modulien rajapinnoista ja yhteyksistä.
Testaussuunnitelma	PK (Kaikki)	Suunnitelma tuotteen kattavasta testauksesta.
Edistymisraportti	JR (MV)	Kuvaus projektin nykytilasta
SU-tuntiraportti	Kaikki	Suunnitteluvaiheeseen käytetyt työtunnit

2.4.5 Vaiheen toteutuminen

2.5.1 Vaiheen kuvaus

Ensimmäisessä prototyyppivaiheessa toteutetaan ohjelmistosta toimiva versio, johon ei ole vielä toteutettu kaikkia vaadittuja toimintoja. Protoa voi testata ja liittymät muihin systeemeihin on pääosiltaan toteutettu.

2.5.2 Vaiheen tavoitteet

Tavoitteena on käytännössä toteuttaa suunnitteluvaiheessa määritellyn ohjelmiston pääkomponentit niin, että mahdollisimman moni liittymät muihin systeemeihin voidaan todeta toimiviksi.

Proton avulla asiakas pystyy muodostamaan hyvän käsityksen lopputuotteen toiminnallisuudesta. Vaiheen tärkein tavoite on tarjota asiakkaalle testiversio tuotteesta ja näin saada mahdollisesti uusia (tarkempia) ideoita lopullisen tuotteen yksityiskohdista.

Mahdolliset epätoimivuudet ja yhteensopivuusongelmat tulisi havaita tässä vaiheessa.

2.5.3 Vaiheen ennakoidut tulokset

Vaiheen tuloksena ohjelmistosta on versio, joka on periaatteessa toimiva, mutta ei sisällä kaikkia vaadittuja ominaisuuksia. Asiakkaalta pyydetään palautetta proton testaamisesta, jotta halutut korjaukset ja lisäykset voidaan toteuttaa seuraavassa vaiheessa.

2.5.4 Vaiheen dokumentaatio

Projektisuunnitelmaa tarkennetaan toisen prototyyppivaiheen sekä siihen liittyvän riskienhallinnan osalta. Ensimmäisen prototyypin testauksen tuloksista kertoo testiraportti. Lisäksi tässä vaiheessa hahmotellan ensimmäiset käyttöohjeet ohjelmiston asennuksesta, käytöstä ja käyttäytymisestä eri tilanteissa.

P1-tuntiraportti kertoo ryhmän jäsenten ensimmäiseen protityyppivaiheeseen käyttämät työtunnit. Edistymisraportti kuvaa projektin nykytilaa.

Kurssin dokumentti	Vastuu (tarkastaja)	Kuvaus
Projektisuunnitelma	MV (PK)	Tarkennettu projektisuunnitelma
Toiminnallinen määrittely	AV (Kaikki)	Tarkennettu toiminnallinen määrittely
Tekninen määrittely	AV (Kaikki)	Tarkennettu tekninen määrittely
Testiraportti	PK (MV)	Raportti olemassa olevan ohjelmiston testauksesta
Käyttöohje	JR (Kaikki)	Ohjeet ohjelmiston asennuksesta, toiminnoista, virheilmoituksista, käyttöliittymästä sekä ylläpidosta.
Edistymisraportti	JR (MV)	Kuvaus projektin nykytilasta
P1-tuntiraportti	Kaikki	Ensimmäiseen prototyyppivaiheeseen käytetyt työtunnit

2.5.5 Vaiheen toteutuminen

2.6.1 Vaiheen kuvaus

Toisessa prototyyppivaiheessa ohjelmistoon lisätään loput vaaditut toiminnot, joita ei oltu toteuttu ensimmäisessä prototyypissä. Asiakkaalta saadaan erittäin yksityiskohtaista palautetta tuotteesta.

2.6.2 Vaiheen tavoitteet

Tavoitteena on saada aikaan ohjelmisto, johon on toteutettu kaikki vaaditut ominaisuudet. Toisessa protossa asiakas testaa huolellisesti tuotetta tuotteen lopullisessa ympäristössä.

2.6.3 Vaiheen ennakoidut tulokset

Asiakas antaa viimeiset kommentit ohjelman kehittämiseksi lopulliseksi tuotteeksi. Tuloksena ei tulisi olla kuin pieniä muutoksia. Erityistä huomiota tulee kiinnittää laatukriteereissä esitettyihin seikkoihin, joiden avulla (pääasiassa asiakas) arvioi tuotetta.

2.6.4 Vaiheen dokumentaatio

Toisessa prototyyppivaiheessa ei laadita mitään uusia dokumentteja, vaan pitäydytään tarkentamaan jo olemassaolevia dokumentteja.

Kurssin dokumentti	Vastuu (tarkastaja)	Kuvaus
Projektisuunnitelma	MV (PK)	Tarkennettu projektisuunnitelma
Toiminnallinen määrittely	Kaikki	Tarkennettu toiminnallinen määrittely
Tekninen määrittely	AV (Kaikki)	Tarkennettu tekninen määrittely
Testiraportti	PK (Kaikki)	Raportti olemassa olevan ohjelmiston testauksesta
Käyttöohje	JR (Kaikki)	Tarkennetut käyttöohjeet
Edistymisraportti	JR (MV)	Kuvaus projektin nykytilasta
P2-tuntiraportti	Kaikki	Toiseen prototyyppivaiheeseen käytetyt työtunnit

2.6.5 Vaiheen toteutuminen

2.7.1 Vaiheen kuvaus

Luovutusvaiheessa testataan ohjelmisto lopullisesti ja korjataan viimeiset havaitut virheet. Viimeistellään projektin suunnittelu- ja määritysdokumentit sekä WWW-sivut. Lisäksi ohjelmisto valmistellaan loppudemonstraatiota ja mahdollista laatupalkintoa varten.

2.7.2 Vaiheen tavoitteet

Kaikkien dokumenttien sekä ohjelmiston tulee olla luovuttamista vailla valmiita.

2.7.3 Vaiheen ennakoidut tulokset

Ennakoidusti ohjelmisto on valmis luovutusta varten.

2.7.4 Vaiheen dokumentaatio

Lopputuotteen luovutuksen yhteydessä laaditaan loppuraportti projektista. Siinä tarkastellaan projektin elinkaarta ja yritetään vastata kysymykseen "Mikä on onnistunutta ja missä mentiin metsään?".

Loput dokumentit tarkennetaan siinä laajuudessa, että ne vastaavat olemassa olevaa ohjelmistoa.

Mahdollisista jatkotoimenpiteitä projektin suhteen ovat mm.

• ohjelmiston laajentaminen valinnaisilla lisätoiminnoilla, joita on määrittelyvaiheessa määritelty
• ohjelmiston jatkosuunnittelu ja uusien lisäominaisuuksien kehittäminen
• ohjelmiston ylläpito

3. Tehtävät ja resurssit

3.1 Koko projekti

Projektiin voidaan olettaa olevan käytettävissä n. 4 x 5 ov x 40 h/ov eli 800 työtuntia. Seuraavassa on arvio eri projektin vaiheisiin jokaiselta ryhmän jäseneltä kuluvasta ajasta. Vaiheen toteuduttua merkitään arvion perään toteutunut arvo. PS vaiheelle ei aika-arviota laadittu, joten arvio ja toteutunut on merkitty samoiksi.

3.2.1 Projektin suunnittelu

Suunnitteluvaiheessa paljon aikaa kului aiheen määrittelemiseen sekä dokumenttien kirjoittamiseen. Lähtökohtana oli kuitenkin se, että suunnitteluun käytetyt resurssit maksavat itsensä takaisin projektin myöhemmissä vaiheissa.

3.2.2 Määrittely

Kustannuksia muodostuu pitkin projektia. Projektin alussa eniten kustannuksia voidaan katsoa aiheutuvan tehdystä työstä. Puhelin-, bensa- ja monistuskuluja aiheutuu satunnaisesti, mutta niistä ei tulla pitämään kirjaa sen tarkemmin (suuruudeltaan mitättömiä).

Työn lisäksi saatetaan joutua hankkimaan tarvittavia ohjelmistoja ja mahdollisesti testityöasema ryhmän omaan käyttöön. Toistaiseksi projektia pystytään viemään eteenpäin kuitenkin ryhmän omalla laitteistokannalla, eikä tässä vaiheessa osata vielä ennustaa tarkkoja hankintatarpeita.

Projektiryhmän työkustannukset lasketaan ryhmänjäsenten vaihtoehtoiskustannusten perusteella. TEKin vuoden 1999 suositus (reilut 60 mk/h) ei vastaa ryhmän keskimääräistä vaatimusta tuntipalkalle, joka arvioidaan tässä vaiheessa olevan 100 mk/h.

4.1 Työkalut ja laitteistot

4.1.1 Työasemat

Työ tehdään pääasiallisesti ryhmän jäsenten omilla koneilla. Testausvaiheessa tullaan käyttämään myös asiakkaan omia järjestelmiä, kun ohjelmaa testataan sen lopullisessa ympäristössään.

4.1.2 Ohjelmistot

Dokumentteja kirjoittaessa pyritään koko projektin ajan säilyttämään yhteneväinen linja tyylin ja laadun suhteen. Yhtenäisestä tyylistä huolehditaan tarkastamalla dokumentti aina toisella (kuin kirjoittaja) ryhmän jäsenellä. Laadusta vastaa koko ryhmä. Dokumentteja aloitetaan kirjoittamaan kurssin ylläpitäjien antamien pohjien perusteella mahdollisimman aikaisin, jotta deadlinet eivät pääse yllättämään ja rokottamaan laatua.

Lähtökohtaisesti kaikki materiaali on WWW:ssä linkattuna projektin kotisivulla. Eri dokumentteja editoidaan eri työkaluilla, mutta siirto tapahtuu pääasiallisesti FTP:llä kotikoneilta ATK-keskuksen koneelle. Dokumentoinnin kattavuudesta vastaa projektipäällikkö, mutta eri dokumenttien vastuuta on jaettu eri jäsenille.

Lisäksi dokumentoinnissa noudatetaan lähtökohtaisesti seuraavia periaatteita

• formaatti on HTML
• kieli suomi (asiakkaan toivomuksesta)
• projektin kotisivulla on esillä lopullinen materiaali (ja eri vaiheiden palautusversiot)
• projektin kehityspuolella päivityksiä tehdään tiheämmin, jotta asiakas (ja ryhmän jäsenet) voivat seurata työn kehitystä "on-line"

Tärkeimpiä dokumentteja kuten asiakkaalle tuotteen mukana jaettavia käyttöohjeita yms. voidaan toimittaa lisäksi vaihtoehtoisissa formaateissa kuten PostScript ja MS Word. Uusimmat dokumentit on toimitettu ainoastaan PDF-formaatissa.

4.3.1 Palaverit

Ryhmä kokoontuu kerran viikossa projektin tiimoilta, johon osallistuvat kaikki jäsenet. Ryhmäpalaverissä käydään läpi projektin tila, tehtävien edistyminen, mahdollisia ongelmia, seuraavan viikon tehtävät sekä projektia koskevat päätettävät asiat.

Ohjelmatyökurssin aikataulun mukaisesti järjestetään muutama katselmus, johon osallistuvat ryhmän jäsenet, asiakas sekä kurssin henkilökuntaa. Viikko ennen katselmuksen ajankohtaa pidetään ryhmän sisäinen palaveri, jossa käydään läpi katselmukseen menevien dokumenttien ja koodin laatu.

Asiakkaan kanssa pyritään pitämään palavereja parin viikon välein. Näin pyritään kumpikin osapuoli pitämään projektin ajantasalla. Tarpeen vaatiessa palavereja pidetään tiuhemmin.

4.3.2 Työajan raportointi

Jokainen ryhmän jäsen raportoi kerran viikossa käyttämänsä työtunnit. Tämä tapahtuu kurssin WWW-sivuilla olevalla tuntiraportointijärjestelmällä. Projektipäällikkö kerää ryhmän jäsenten raportoimat tunnit kerran kuukaudessa ja vertaa käytettyjä tuntimääriä projektisuunnitelmaan. Näin projektipäällikkö voi tarvittaessa tehdä muutoksia projektin aikatauluun ja tuleviin suunnitelmiin.

4.3.3 Virheiden raportointi

Ohjelmiston testausvaiheessa havaittavista virheistä lähetetään muille ryhmän jäsenille sähköpostitse ilmoitus. Ilmoituksessa tulee olla kuvaus virheestä, kuinka se havaittiin sekä kuka on vastuussa virheen korjauksesta. Lisäksi kaikki havaitut virheet talletetaan erilliseen tietokantaan. Virheen tultua korjatuksi, korjauksesta vastuussa ollut henkilö lähettää sähköpostitse muille ryhmän jäsenille kuittauksen virheen korjaamisesta. Lisäksi hän päivittää virhetietokantaa, korjauksen osalta.

4.3.4 Ryhmän sisäinen tiedonvälitys

Riskienhallinnan tarkoituksena on kartoittaa mahdollisia riskitekijöitä, jotka voivat vaikuttaa projektin onnistumiseen negatiivisesti/positiivisesti. Tärkeintä on tiedostaa, että millaisia riskejä on olemassa ja mitä toimenpiteitä on tehtävissä niiden ehkäisemiseksi. Jokaisen projektin vaiheen lopussa tarkennetaan projektin riskienhallintaa seuraavan vaiheen osalta.

Seuraavassa on taulukoitu mahdollisia riskejä projektin onnistumiseen, keinoja niiden hallitsemiseen sekä riskin vaikutus projektin toteutuessaan. Alla olevat riskit ovat olemassa koko projektin ajan. Lisäksi on suuri joukko vaihekohtaisia riskejä.

Kuvaus	Hallintamenetelmät	Vaikutus
Pula henkilöresursseista	Projekti suunnitellaan alusta lähtien toteutettavaksi olettamatta lisäresursseja. Ohjelmiston vaatimuksia ei lisätä ilman sen toteutusmahdollisuuksien analysointia.	Projekti ei valmistu ajallaan.
Asiakas vetäytyy projektista	Asiakkaan kanssa tehdään sopimus projektin etenemisestä. Asiakas sitoutuu noudattamaan kurssin viitekehyksen mukaista aikataulua.	Projekti keskeytyy
Asiakas vaatii uusia toimintoja tai muutoksia nykyisiin toimintoihin	Asiakkaan kanssa tehdään läheistä yhteistyötä projektin määrittely- ja suunnitteluvaiheessa. Lisämuutoksiin vaaditaan sekä ryhmän että asiakkaan puolto.	Projekti ei valmistu ajallaan
Pula osaamisresursseista	Varataan riittävästi aikaa projektin eri vaiheille, käytetään aikaa huolellisten suunnitelmien tekemiseen	Työmäärä kasvaa, laatu kärsii, aikataulu venyy
Ryhmän jäsen poistuu projektista	Ryhmän henki pidetään hyvänä ja luovana. Seurataan ryhmän jäsenten mielipiteitä projektin aikana.	Projekti keskeytyy tai ei valmistu ajallaan
Valittu järjestelmäarkkitehtuuri on huono	Määrittely- ja suunnitteluvaiheessa analysoidaan useita mahdollisia vaihtoehtoja.	Projekti ei valmistu ajallaan
Valitut salausalgoritmit ovat liian heikkoja	Nojaudutaan tunnettuihin vahvoihin salausalgoritmeihin, joille on olemassa tieteellistä tukea	Asiakas on hyvin vihainen
Isojen lukujen aritmetiikka on liian hidas	Käytetään julkisia hyväksi todettuja toteutuksia	Projekti viivästyy
Proxyjen välinen protokollassa on turvallisuusaukkoja	Kaikki mahdolliset tapaukset protokollassa analysoidaan	Asiakas on hyvin vihainen
Proxyjen sisäinen kompleksisuus on liian suuri	Pyritään pitämään arkkitehtuuri mahdollisimman yksinkertaisena	Projekti viivästyy huomattavasti
Yhteensopivuusongelmia eri ympäristöjen kanssa	Käyttämällä asiakkaan teknistä tietämystä ympäristöistä	Projekti viivästyy aikataulusta tai keskeytyy
Gygwin kirjastototeutus POSIX threads -kirjastosta ei ole tarpeeksi toimiva	Toteutetaan asiakkaan proxyn monisäkeisyys Windowsin omilla säikeillä	Projekti viivästyy
Puutteellinen ohjelmiston testaus	Testaus suoritetaan useassa vaiheessa. Testauksen laajuutta pyritään suurentamaan asteittain	Projekti viivästyy ja ohjelmiston laatu kärsii
Salaustoimintojen testaukseen ei pätevyyttä	Salausalgoritmit pyritään testaamaan julkisesti saatavilla olevilla testivektoreilla.	Ohjelmiston laatu kärsisi
Ohjelmiston integrointi asiakkaan ympäristöön ongelmallinen	Asiakas pidetään tiiviisti mukana ohjelmiston kehityksessä ja testauksessa	Projekti viivästyy tai keskeytyy

4.4.1 Projektin suunnittelu

Suunnitteluvaiheessa moni asia on epäselvä ja on suuri riski tehdä hätiköityjä päätöksiä. Asiakkaan tarvetta ei kartoiteta riittävän perusteellisesti, aikataulu voidaan suunnitella liian tiukaksi, tehtävät voidaan jakaa tehottomasti, tarvittavista esitiedoista ja lähteistä ei oteta riittävän ajoissa selvää jne.

4.4.2 Määrittely

Määrittely muodostaa pohjan koko ohjelmistolle ja on näinollen syytä tehdä huolella. Riskejä epäonnistumiseen aiheuttaa väärät lähtötiedot, huonosti määritelty tuote, puutteellinen yhteistyö asiakkaan kanssa, väärä arvio käytettävissä olevasta ajasta ja osaamisresursseista jne.

4.4.3 Suunnittelu

Luistaminen suunnitteluvaiheessa aiheuttaa moninkertaisen työn toteutusvaiheissa. On riski, että aika ei anna myöten tehdä suunnittelua huolellisesti ja näin joko laatu kärsii tai aikataulu pettää (tai molemmat). Suunnittelu voidaan tehdä myös virheellisesti pohjautuen esim. virheelliseen määrittelyyn. Tällöin suunniteltua tuotetta ei ehkä koskaan saada valmiiksi tai ei ainakaan sellaisena kuin asiakas sen haluaa.

4.4.4 Prototyyppi 1

Proto tarkoittaa jo jonkinasteista toiminnallisuutta tuotteessa eli ei riitä pelkkä paperidokumentaatio. Se mitä protossa toteutetaan tulee olla huolellisesti punnittu, jotta resurssit riittävät ja toteutunut proto toimii halutulla tavalla. On riski, että koodaaminen ei pysy aikataulussa eikä proto täytä tehtäväänsä.

4.4.5 Prototyyppi 2

Asiakas antaa palautetta myös tästä kehittyneemmästä proto-versiosta. On riski, ettei kokeiluversio olekaan tarpeeksi lähellä asiakkaan tarvetta. Jos aikataulu pettää, ei protoon saada toteutettua riittävää toiminnallisuutta eikä haluttua havainnollisuutta saavuteta.

4.4.6 Luovutus

5. Ohjaussuunnitelma

5.1 Projektin tilan seuranta

5.1.1 Raportit Jokaisen projektin vaiheen lopussa laaditaan edistymisraportti projektin tilasta. Siinä kartoitetaan mitä on suoritettu ja mitä ongelmia on ilmennyt. Lisäksi asiakkaalle raportoidaan jokaisen vaiheen jälkeen mitä projektissa on saavutettu. Tämä voi olla sama kuin edistymisraportti.

5.1.2 Palaverit

Ryhmän sisäisiä palavereja pidetään viikottain ja tarvittaessa jopa useamminkin. Näissä käydään läpi projektin tila ja kuinka projektin on edistynyt. Asiakkaan kanssa pidetään palavereja pari kertaa kuukaudessa tarpeen mukaan, joissa asiakkaalle kerrotaan mitä projektissa on jo suoritettu ja mitä on suunnitelmissa seuraavaan palaveriin asti.

5.1.3 Katselmukset

Ohjelmatyökurssin mukaisesti pidetään projektin aikataulussa muutama katselmus, joissa on läsnä ryhmän lisäksi asiakkaan edustaja sekä kurssin henkilökuntaa. Ennen katselmusta ryhmän pitää sisäisesti oman esikatsemuksen, jossa käydään läpi katselmukseen menevien dokumenttien ja koodien julkaisukelpoisuus ja laadullisuus.

5.1.4 Tarkastuskäytännöt

Jokaisessa projektin vaiheessa laadituille dokumenteille on nimetty vastaava tarkastaja, jonka tehtävänä on kriittisesti käydä läpi ko. dokumentti ja antaa ryhmälle palautetta. Ennen dokumenttien virallista luovutusta yhtään mihinkään, jokainen ryhmän jäsen käy dokumentit vähintään kerran läpi ja ryhmän esikatselmuksessa käydään dokumentit läpi kootusti.

Sama käytäntö kuin dokumenteilla pätee myös demoissa esitettäviin toteutettuihin ohjelmistoihin. Jokaisella toteutetulla modulilla on eri testaaja kuin suunnittelija ja toteuttaja. Ennen demoa kaikki luovutettavat tarkastetaan ryhmän omassa demossa ja laatupäällikkö tarkastaa koodin laadun.

5.1.5 Mittarit

Projektipäällikkö seuraa koko ajan projektin aikataulun paikkaansapitävyyttä ja ilmoittaa projektin eri osapuolille aikataulumuutoksista sekä päivittää projektisuunnitelmaa. Erityisesti valvotaan projektin eri tehtävien aikataulun venymistä.

Kunkin vaiheen päättyessä verrataan toteutuneita työmääriä projektisuunnitelmassa arvioituihin lukuihin. Projektipäällikkö päivittää projektisuunnitelmaa jokaisen vaiheen päätyttyä työmäärien osalta. Vaiheen päätyttyä seuraavassa ryhmäpalaverissa analysoidaan ryhmän kesken toteutuneiden ja arvioitujen työmäärien erotusta.

Projektin eri vaiheiden aikana projektipäällikkö seuraa eri riskien todennäköisyyksiä kullekin tehtävälle ja mahdolliset muutokset päivitetään projektisuunnitelmaan kohtaan "Riskienhallinta".

6.1 Sanasto