[ yleistä ] [ julkaisut ] [ yhteystiedot ] [ pohjat ] [ palautukset ]

MobSSH
MobSSH Projektin Laatukäsikirja		http://www.niksula.cs.hut.fi:80/~mkomu/mobssh/julkaisut/laatukasikirja.html
1.2		Sisäinen dokumentti
Saari Tuomo		Viimeksi muokattu: 16.10.2000 17.10.2000
Versiohistoria
1.0	14.10.2000	Saari Tuomo	Lisätty vastuualueet (kappale 6) ja kirjoitettu riskienhallintaprosessi (kappale 5)
1.1	15.10.2000	Saari Tuomo	Katselmoitiin dokumentti, korjattiin kirjoitusvirheitä
Tarkastanut		Hyväksynyt
16.10.2000	Jukka Ahonen	16.10.2000	Mika Kousa

Sisällysluettelo
1. Johdanto
2. Projektin laadun määritelmät: 2.1 Projektin lopputuotteen laadun määritelmä; 2.2 Projektin prosessin laadun määritelmä
3. Projektin laadun mittarit: 3.1 Projektin lopputuotteen laadun mittarit; 3.2 Projektin prosessin laadun mittarit
4. Projektin toimintatavat: 4.1 Projektinhallinnalliset toimintatavat ja -ohjeet; 4.2 Projektin lopputuotteen tuotannon ohjeet ja käytännöt
5. Projektin riskienhallintaprosessi: 5.1 Riskien tunnistaminen; 5.2 Riskien monitorointi; 5.3 Riskien vastatoimet; 5.4 Riskien uudelleenarviointi
6. Projektin vastuunjako

1. Johdanto

MobSSH projektin tarkoitus on tarkastella SSH1 protokollan käyttömahdollisuuksia EPOC-ympäristössä ja kerätä kokemuksia tulevaisuutta varten. Projektin tuotteena on tarkoitus tuottaa SSH1 standardin mukainen implementaatio protokollasta valikoiduin osin. Projektiprosessi ei varsinaisesti vastaa mitään esimerkkiprosessia, koska lopputuotteesta on olemassa tarkka spesifikaatio, mutta toteutusympäristö on niin uusi, että projektia on pidettävä luonteeltaan eksploratiivisenä.

Projektin lopputuotteen ja prosessin laadun varmistamiseksi projektille on laadittu tämä laatukäsikirja, joka määrittelee mitä laatu tarkoittaa tässä projektissa, sekä lopputuotteen että prosessin osalta, esitettyjen kriteerien mittarit ja lukuisia toimintaohjeista ja -tapoja, joilla pyritään varmistamaan projektin laatua.

Laatujärjestelmän toteuttamisvastuu on ensisijaisesti kaikilla MobSSH projektin osapuolilla ja kokonaisuus on jaettu siten, että Tuomo Saari vastaa projektin prosessin laadusta ja Tero Nordstöm projektin lopputuotteen laadusta teknisessä mielessä. Laatukäsikirjaan on myös dokumentoitu projektin riskienhallintaprosessi, joka on oma osansa projektin laadun varmistamista.

2. Projektin laadun määritelmät

Tässä kappaleessa määritellään projektin lopputuotteen ja - prosessin laatukriteerit. Kriteerit on tehty yhteistyössä projektin asiakkaan kanssa ja laatukäsikirjan noudattaminen on yksi keskeinen osa asiakkaan kanssa sovittua tason kaksi toteutusta. Lisää tietoa projektista ja projektin toteutuksen tasoista löytyy projektisuunnitelmasta ja vaatimusmäärittelystä.

2.1 Projektin lopputuotteen laadun määritelmä

Ohjelmisto toimii oikein sisäisesti myös pitempään käytettynä. Eli ohjelma ei kaadu ja toimii oikein eikä kadota resursseja.
Ohjelmisto toimii oikein ulkoisesti eli ohjelman toiminta ei häiritse muita epoc-sovelluksia.
Ohjelmiston osille, jotka ovat funktioita, tehdään testiohjelmia, joilla voidaan todentaa ja testata eri osien toimivuutta epocissa. Näitä voidaan myöhemmin käyttää regressiotestaukseen. Käyttöliittymän eli terminaaliemulaattorin kohdalla käytetään vapaavalintaista äänitysohjelmaa jolla tehdään skriptejä, jotka jäljittelevät käyttöä. Toiminnallisuus todennetaan ajamalla näitä scriptejä tai erillisiä testiohjelmia.
Ohjelman on oltava käytettävä. Jos osoittautuu, että toteus uhkaa tulla liian hitaaksi järkevillä salausavainten pituuksilla, niin tilanteesta sovitaan erikseen.
Lopputuotteen koodin rakenne ja kommentointi tulee olla sillä tasolla, että koodin edelleen kehittäminen tai uudelleenkäyttäminen on mielekästä.
Projektin aikana käytetään toimintatapana sovellettua daily build-tapaa, missä ohjelmisto käännetään tarvittaessa vaikka joka yö ja testit ajetaan aina – mielellään päivän päätteeksi tai muuten sovittuina aikoina.

2.2 Projektin prosessin laadun määritelmä

Projektin prosessin keskeisin laatutavoite on asiakastyytyväisyys ja projektin kaikkien sidosryhmien tavoitteiden saavuttaminen. Asiakastyytyväisyyden takaamiseksi on yhteistyössä asiakkaan kanssa identifioitu useita teknisiä laatukriteerejä, jotka esiteltiin edellisessä kappaleessa.

Projektiryhmän omien tavoitteiden saavuttamisen kannalta kriittisintä on aikataulun pitäminen ja kurssin esittämien vaatimusten täyttäminen mahdollisimman täydellisesti. Näillä perusteilla projektin prosessin laadun määritelmänä on taata projektin kaikkien osapuolien tyytyväisyys projektin loppuessa ja sen saavuttamiseksi laatukäsikirjassa esitellään lukuisia toimintatapoja, mittareita ja käytäntöjä, joilla tämän tavoitteen saavuttaminen pyritään varmistamaan.

3. Projektin laadun mittarit

Projekti noudattaa kurssin vaatimusten mukaisesti pääpiirteissään USDP [1] ohjelmistokehitysprosessia ja tässä prosessissa käytettävät mittarit jaetaan kahteen pääluokkaan, tietoa lisääviin ja muutosta mittaaviin. Projektin keston ollessa varsin lyhyt, tulee projektin laadun mittareiden pääpaino olemaan tietoa lisäävissä mittareissa.

Projektin luonteen ollessa eksploratiivinen ei projektin laadun mittareille ole mielekästä määrittää heti alkuvaiheessa tavoitearvoja, vaan mittareiden tavoitearvot määritetään ensimmäisen ja toisen toteutusvaiheen aikana siten, että ennen joululomaa (alkaa 22.12.2000) on olemassa mittaristo tavoitearvoineen kevään toteutusjaksoille ja toisen toteutusjakson loppuosalle.

Mittarit on projektin laadun määrittelyn mukaisesti jaettu kahteen eri kategoriaan, eli teknistä laatua ja teknistä toteutusta mittaviin (taulukko 3.1) ja projektin prosessia mittaaviin (taulukko 3.2) mittareihin. Teknisen laadun mittarit määritellään ensimmäisen toteutusvaiheen aikana ja prosessin laadun mittareihin voi tulla myös muutoksia.

3.1 Projektin lopputuotteen laadun mittarit

Taulukko 3.1 Projektin lopputuotteen laadun mittarit

Mittari	Perustelut	Implementointi

3.2 Projektin prosessin laadun mittarit

Taulukko 3.2 Projektin prosessin laadun mittarit

Mittari	Perustelut	Implementointi
Projektinhallintaan ja muihin hallinnollisiin toimenpiteisiin käytettyjen tuntien suhde tuotantoon käytetyistä tunneista	Hallinnolliset toimet kuuluvat osana projektiin ja niitä tulee olla tietty määrä projektista. Jos hallinnollisia toimia on vähän (pieni suhde), niin projektinhallinta on tulkittava liian kevyeksi ja jos toimia on paljon (suuri suhde), niin projektinhallinta on liian raskasta ja tehokkuus kärsii.	Etsitään kirjallisuudesta sopivia lähtökohtia vertailuarvoiksi Seurataan tunteja kurssin tarjoamalla Tirana - järjestelmällä Kerätään havaintoja ensimmäisestä toteutusvaiheesta ja muodostetaan hypoteesi suhteesta oman kokemustiedon ja kirjallisuustiedon perusteella toista toteutusvaihetta varten
Kurssille palautettavien dokumenttien sisäisissä katselmoinneissa ilmi tulleiden virheiden ja puutteiden lukumäärä	Katselmointien tulisi prosessin toimiessa olla lähinnä muodollisia tilanteita, joissa varmistuksena tarkastetaan viimeisen kerran palautettavat dokumentit. Jos virheitä tai erimielisyyksiä syntyy, tämä voi johtua esim. tulevista aikatauluongelmista, motivaatio-ongelmista, sisäisistä erimielisyyksistä, jne.	Katselmustilanteessa lasketaan kuinka monta ongelmaa ja korjausta vaativaa tilannetta havaittiin.
Aikatauluun perustuva edistymisen mittaaminen vs. arvioitu valmiusaste vs. suunniteltu valmiusaste projektin eri vaiheissa	Projektilla on kurssin asettamien vaatimusten mukaan useita mile-stone kohtia aikataulussa. Jokaista vaihetta varten laaditaan ohjeen mukainen suunnitelma ko. vaiheen tavoitteista ja arvio valmiusasteesta. Jokaisen vaiheen lopussa tarkastellaan, saavutettiinko asetetut tavoitteet ja onko projektin valmiusaste todella suunnitelman mukainen. Lisäksi verrataan tehtyä työmäärää valmiusasteeseen, onko suhde järkevä	Kirjataan tehdyt tunnit Tirana - järjestelmään Laaditaan toimintaohjeiden mukainen tavoite joka vaiheelle Tarkastellaan yhteistyössä asiakkaan kanssa, että saavutettiinko vaiheen tavoite Arvioidaan koko projektin valmiusastetta joka vaiheen lopussa mahdollisimman puhtaalta pohjalta, ts. pyritään arvioivia henkilöitä vaihtamalla saamaan mahdollisimman realistinen arvio. Mitataan 'earned value' ja 'budgeted value' mittareilla projektin edistymistä suhteessa tehtyyn työhön ViCa - järjestelmän avulla.
Projektin tavoitteen tai lopputuotteen muutosvaatimusten lukumäärä	Projektin onnistumiselle on tärkeää, että projektin määrittely on onnistunut hyvin ja kaikki sidosryhmät ovat yksimielisiä projektin tavoitteesta. Jos muutoksia tulee paljon, on projektin määrittelyvaihe epäonnistunut	Etsitään kirjallisuudesta tai muualta referenssejä, kuinka paljon vaatimukset ja tavoitteet yleensä muuttuvat. Pyritään löytämään yhteistyössä asiakkaan kanssa jokin järkevä mittausarvo. Kirjataan ylös kaikki muutokset ja verrataan mittausarvoon.
Poikkeamat laatukäsikirjan mukaisista toimintatavoista	Laatukäsikirja määrittelee lukuisia toimintatapoja, joiden tarkoitus on varmistaa, että projekti toteutetaan oikeaoppisesti. Jos poikkeusia tulee paljon, voi määritelty toimintapa olla väärä tai huono ja sitä on korjattava	Kokousmuistioissa pidetään kirjaa tapahtuneista poikkeamista ja ongelmista ja prosessin laadusta vastaava tarkkailee lukumäärän kehitystä. Jos poikkeamisia tulee paljon, asiasta neuvotellaan ja tehdään tarvittavat muutokset.

4. Projektin toimintatavat

Tässä kappaleessa esitellään projektin toimintatapoja projektin eri osa-alueille. Projektinhallinnalliset käytännöt on laadittu kirjallisuuden perusteella MobSSH projektiin soveltaen. Projektin lopputuotteen tuotannon ohjeet laaditaan ensikokemusten ja kirjallisuuden perusteella ensimmäisen toteutusvaiheen aikana.

4.1 Projektinhallinnalliset toimintatavat ja -ohjeet

4.1.1 Projektin yhteydenpito

Ilman eri sopimusta jokaisen työviikon torstaina järjestetään tietotalolla klo 12.00 projektin viikkopalaveri, johon osallistuu koko projektiryhmä ja asiakkaan edustaja. Jos osallistuja on estynyt tai myöhästyy, siitä tulee ilmoittaa siten, että se kenelle ilmoitetaan estymisestä tai myöhästymisestä osallistuu viikkopalaveriin. Viikkopalaveriä voidaan tarpeen vaatiessa siirtää tai niitä voidaan järjestää useampia.
Projektiryhmä kokoontuu alustavasti kerran viikossa omaan ryhmäpalaveriinsa, jossa käsitellään seuraavan viikon tehtäviä ja keskustellaan projektin tilanteesta.
Projektilla on sähköpostilista mobssh@tml.hut.fi, jonka kautta kommunikoidaan sähköpostitse kaikki projektia ja kaikkia jäseniä koskevat asiat. Kaikki projektin sidosryhmät ovat velvoitettuja lukemaan sähköpostinsa säännöllisesti.
Projektin www-sivuille (www.iki.fi/miika/mobssh) perustetaan kalenteri, jonne kirjataan kaikki koko projektiryhmää koskevat tapahtumat aikoineen ja paikkoineen. Kaikki projektin sidosryhmät ovat velvoitettuja seuraamaan tätä kalenteria sen perustamisen jälkeen säännöllisesti.

4.1.2 Projektin työmäärän ja ajankäytön seuranta

Jokainen projektiryhmän jäsen on velvollinen seuraamaan omaa ajankäyttöään projektissa Tiranassa olevien taskien tarkkuudella.
Jokainen projektiryhmän jäsen on velvollinen kirjaamaan käytetyt tuntinsa Tiranaan vähintään kerran viikossa.
Jos Tiranaan tarvitaan uusia taskeja, niin ilmoitus Tuomolle.
Projektin viikkopalaverissa käydään läpi jokaisen henkilön vastuulla olevien tehtävien valmiusaste ja Tuomo seuraa tehtävien valmistumista.

4.1.3 Asiakasraportointi ja -kommunikaatio

Jokaisen projektin päävaiheen alussa asiakkaalle toimitetaan kirjallisena kuvaus ko. vaiheen tavoitteesta. Kuvauksesta tulee ilmetä mielekkäällä tarkkuudella mitä tässä projektin vaiheessa aiotaan tehdä. Kuvauksen pituus on n. kahdenksan riviä ja raporttia varten laaditaan erillinen raporttipohja.
Asiakaalle tulee välittömästi ilmoittaa projektia uhkaavista ongelmista.
Erillistä viikkoraporttia ei tarvita, vaan viikon tapahtumat käsitellään viikkopalaverissa.
Pääasiallisina kommunikointikanavina asiakkaan suuntaan toimivat Tuomo ja Tero, mutta kommunikointia ei ole suljettu.

4.1.4 Kokous- ja palaverikäytännöt

Jokaisesta asiakaspalaverista tehdään kokousmuisto käyttäen dokumenttipohjaa. Muistion kirjoittaja vastaa muistion sisällöstä
Merkittävistä ryhmäpalavereista tehdään kokousmuisto käyttäen dokumenttipohjaa. Kaikista ryhmäpalavereista ei tarvitse tehdä muistiota, mikäli palaverit käsittelevät ainoastaan rutiiniasioita.
Jokaisen kokouksen tai palaverin alussa, josta tehdään kokousmuistio, valitaan muistion tekijä.
Kokousten ja palaverien agendan valmistelee pääosiltaan Tuomo Saari tai henkilö, kenen vastuulle se erikseen on annettu. Erillistä asialistaa kokouksesta tai palaverista ei tarvitse julkaista.
Kokouksiin ja palavareihin on pyrittävä saapumaan ajoissa ja myöhästymisestä on ilmoitettava. Jos osallistujalla on ollut jokin valmistelutehtävä palaveria varten, niin sen tekemättömyydestä tai ajan puutteesta tekemiseen on kerrottava projektiryhmälle mahdollisimman ajoissa, jotta palaveria voidaan siirtää.

4.1.5 Katselmointikäytäntö

Katselmoinnin tarkoitus on varmistaa, että palautettava dokumentti on palautuskelpoinen.
Katselmointi toteutetaan siten, että katselmoitavan dokumentin editointi on välittömästi mahdollista. (kannettava tietokone, tietokoneluokassa, jne.)
Katselmoinnissa on läsnä vähintään kolme henkilöä, katselmoitavan dokumentin vastuuhenkilö, katselmoija ja katselmoinnin valvoja.
Katselmoitavan dokumentin vastuuhenkilö esitettelee dokumentin ja katselmoija tarkastaa sen ja esittää tarvittavia kysymyksiä.
Jos löytyy virheitä tai puutteita, dokumentin vastuuhenkilö pyrkii korjaamaan ne välittömästi.
Kun dokumentin katselmointi on valmis, katselmoija hyväksyy dokumentin.
Katselmoinnin valvoja kirjaa ylös virheiden ja puutteiden lukumäärän ja toimii tarvittaessa ristiriitojen ratkaisija. Virheiden ja puutteiden lukumäärä ja katselmoidun dokumentin nimi toimitetaan Tuomolle.

4.1.6 Dokumenttien julkaisukäytäntö

Jokaisella kurssille palautettavalla dokumentilla tulee olla vastuuhenkilö, joka vastaa dokumentin valmistumisesta ajallaan, kirjoitustyön jakamisesta, dokumentit versioista ja sen julkaisemisesta yhdessä Miikan kanssa.
Kaikki projektin dokumentit ovat HTML-muotoisia
HTML-koodista ja sen tuottamisesta ja korjaamisesta on erillinen www-ohje, josta vastaa Miika.
Kurssille palautettavat dokumentit julkaistaan palautuspäivänä ennen palautuksen takarajaa.
Kokousmuistiot ja muut dokumentit, joita ei palauteta kurssille, ovat koko ajan julkisia.

4.2 Projektin lopputuotteen tuotannon ohjeet ja käytännöt

4.2.1 Käytettävät kehitystyökalut

4.2.2 Koodin suunnittelu- ja suunnitelmien dokumentointiohje

4.2.3 Koodin yleinen tuotanto-ohje

4.2.4 Koodin kommentointi- ja muoto-ohje

4.2.5 Koodin muuttujien nimeämisohje

4.2.6 Versionhallinnan ja konfiguraation hallinan ohje

4.2.7 Koodin testauksen ohje

4.2.8 Koodin katselmointi/tarkastus käytäntö

5. Projektin riskienhallintaprosessi

Projektissa pyritään riskienhallinnan avulla pienentämään tulevien ongelmatilanteiden vaikutusta projektiin. Projektin eksploratiivisen luonteen perusteella on selvää, että projekti tulee kuluessaan kohtaamaan joitain teknisiä ongelmia, mutta tunnistamalla mahdollisimman paljon näitä ongelmia etukäteen, voidaan jo valmiiksi sopia miten erilaisia ongelmia kohdatessa toimitaan ja projektin eteneminen ei ole vaarassa. Seuraavat kappaleet esittelevät projektissa käytettävää riskienhallintaprosessia, joka on sovelluttu käyttäen lähteinä Project Management Body of Knowledgeä (1996, s. 111-112) ja Software Project Managementia (Hughes, Cotterell, Second Edition, McGraw-Hill, 1999, s. 131-150). Projektin riskienhallintaprosessi on pääpiirteissään kuvattu kuvassa 5.1.
riskiprosessi

Kuva 5.1 Projektin riskienhallintaprosessi

5.1 Riskien tunnistaminen

Ensimmäinen riskientunnistusvaihe toteutettiin osana projektin suunnittelua ja se on dokumentoitu projektisuunnitelmassa. Projektin edetessä riskien tunnistus tapahtuu jokaisen projektin päävaiheen alussa kootusti Tuomo Saaren vetämänä ja jos joku projektiryhmän jäsen tai asiakkaan edustja katsoo olevan tarvetta päivittää riskienhallintasuunnitelmaa, se tapahtuu viikkopalaverissa.

Uusia riskejä tunnistettaessa tulee määrittää riskille nimi, riskin toteutumisen indikaattorit, riskin hallintakeinoja joita voidaan toteuttaa riskin toteutumisen estämiseksi, riskin toteutumisen seuraukset ja vakavuus projektille asteikolla 1 - 5 (5 erittäin vakava, 1 ei merkittävä) sekä pitää kirjaa toteutetuista riskiä ehkäisevistä vastatoimenpiteistä, jos ne katsotaan tarpeellisiksi. Riskit ja tunnistusvaiheessa kerätty tieto kootaan projektin "topkymppi" - taulukkoon, jota päivitetään edellisen kappaleen mukaisesti.

5.2 Riskien monitorointi

Riskien monitorointi eli indikaattorien seuraaminen ja toteutumismahdollisuuden arviointi on jokaisen projektiryhmän jäsenen ja asiakkaan vastuu. Jos joku projektin osapuolista katsoo, että jokin riski saattaa totetua hyvin suurella todennäköisyydella, niin hänen tulee ottaa riski keskustelun aiheeksi viikkopalaverissa.

5.3 Riskien vastatoimet

Jos jokin riski toteutuu, toteutetaan riskille vastatoimenpiteitä yhteistyössä asiakkaan kanssa projekti etenemisen turvaamiseksi. Vastatoimenpiteet ovat tapauskohtaisia, periaatteena kuitenkin turvata projektin jatkuminen

5.4 Riskien uudelleenarviointi

Riskien uudelleenarvioinilla tarkoitetaan säännöllisen riskien tunnistamisvaiheen yhteydessä tapahtuvaa toimintaa, jossa aikaisemmin tunnistettuja riskejä tarkastellaan ja päätetään, kuuluvatko ne enää projektin topkymppiin vai tuleeko jotain muuta tunnistamisvaiheen osa-aluetta päivittää topkymppiin.

Uudelleenarviointi on myös jatkuvaa toimintaa, joka tapahtuu monitoroinnin rinnalla, mutta erityistä merkitys sillä on, jos jokin riski toteutuu.

6. Projektin vastuunjako

Tässä kappaleessa selvitetään projektin roolien ja eri osa-alueiden vastuiden jakautuminen projektiryhmän kesken. Jokaisen henkilön roolit ja erityisvastuualueet on koottu taulukkoon 6.1. Taulukko 6.1 Projektiryhmän roolit ja erityisvastuualueet

Nimi	Rooli	Vastuualueet	Erityisasiantuntemus
Tuomo Saari	Projektipäällikkö, Laatupäällikkö	Projektin organisointi Projektinhallinta ja sen laatu Väliraportointi Yhteudenpito asiakkaaseen Sopimukset asiakkaan kanssa	MS Project Tirana ViCA
Tero Nordström	Laatupäällikkö, Tietoturva-asiantuntija	Tietoturva-algoritmien porttaus/toteutus EPOC - järjestelmään Projektin lopputuotteen ja toteutuksen laatu Yhteydenpito asiakkaaseen Lopputuotteen vaatimusten hallinta	Windows 2000
Miika Komu	WWW-päällikkö, versionhallinnan asiantuntija	MobSSH:n www-sivujen ylläpito Projektiryhmän sähköpostilistat EPOC - käyttöliittymän toteutus	CVS HTML
Kristian Slavov	Protokolla-asiantuntija	Protokollaohjelmointi	SSH1
Mika Kousa	Käytettävyyspäällikkö	Protokollan suunnittelu EPOC - käyttöliittymän ohjelmointi ja käytettävyyden kehittäminen	TCP/IP
Antti Järvinen	Dokumentointipäällikkö, Protokolla-asiantuntija	Dokumenttien pohjat Dokumenttien palautus Protokollan toteutus ja suunnittelu Protokollan luotettavuus	SSH1
Jukka Ahonen	Testauspäällikkö, Kehitysympäristö- ja laitteistoarkkitehtuuriasiantuntija	Ohjelmiston testauksen ja arkkitehtuurin suunnittelu Tietoturvan toteutus	EPOC
Arto Sinkkonen	Asiakas, Valvoja	Projektiryhmän ohjaus Kustannukset ja tarvittavat laitteisto- ja ohjelmistoresurssit	Protokollakehitys yleisesti Ohjelmistoprojektin toteutus

Lähdeluettelo

[1] The Unified Software Development Process, Ivar Jacobson, Grady Booch, James Rumbaugh, Addison-Wesley, 1999

URL: http://www.niksula.cs.hut.fi:80/~mkomu/mobssh/julkaisut/laatukasikirja.html
Viimeksi päivitetty: 17.10.2000

Sisällysluettelo