LAATUSUUNNITELMA Versio 1.0
1(2) 1. JOHDANTO 4 1.1 Laatusuunnitelman tarkoitus 4 1.2 Viittaukset muihin dokumentteihin 4 1.3 Laatudokumentin hyväksyminen ja muuttaminen 4 1.3.1 Laatusuunnitelman hyväksyminen 4 1.3.2 Suunnitelman muuttaminen 4 1.4 Määritelmät, termit, lyhenteet ja merkintätavat 4 2. LAATUORGANISAATIO 6 2.1 Jäsenet ja roolit 6 2.2 Vastuut 6 2.2.1 Suunnitteluryhmän vastuut 6 2.2.2 Laatuvastaavan vastuut 6 2.2.3 Projektipäällikön vastuu 6 2.2.4 Asiakkaan vastuu 6 2.2.5 Ulkopuolinen näkökulma 6 3. LAADUNVARMISTUS 7 3.1 Läpikäynnit ja katselmukset 7 3.1.1 Projektin johtoryhmän katselmukset 7 3.1.2 Läpikäynnit 7 3.1.3 Paritarkistukset 7 3.2 Testaus 8 3.2.1 Johdanto 8 3.3 Laatukriteerien seuranta 8 4. LAATUPROSESSIT 10 4.1 Muutostenhallinta 10 4.1.1 Yleistä 10 4.1.2 Kriteerejä 10 4.2 Dokumenttien hallinta 10 4.2.1 Yleistä 10 4.2.2 Kriteerejä 10 4.3 Suunnittelu 10 4.3.1 Suunnitteluprosessi 10 4.3.2 Kriteerejä 10 4.4 Toteutus 11 4.4.1 Toteutus- ja testausprosessi 11
2(3) 4.4.2 Toteutuksen laatutavoitteet 11 4.4.3 Kriteerejä 11 4.5 Ylläpito 11 5. LAATUKRITEERIT 12 5.1 Johdanto 12 5.2 Yleiset laatutavoitteet 12 5.3 Ohjelmiston laatutavoitteet 16 6. LAATUKATSELMUKSET 17 6.1 Yleistä 17 6.2 T1 vaiheen laatukatselmus 6.11.2000 17 6.3 T2 vaiheen laatukatselmus 7.12.2000 18 6.4 T3 vaiheen laatukatselmus 7.2.2001 19 6.5 T4 vaiheen laatukatselmus 14.3.2001 20 6.6 LU vaiheen laatukatselmus 18.4.2001 20
3(4) Dokumentin versiot Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt 1.0 Harri Kauhanen 29.9.2000 Ensimmäinen luonnosversio (Luonnos 1) 1.0 Harri Kauhanen 7.10.2000 Toinen luonnosversio. Monia lisäyksiä, mutta erityisesti mittareita on lisätty ja tarkennettu. 1.0 Harri Kauhanen 13.10.2000 Palaverissa 11.10.2000 todetut tarkennukset ja lisäykset. Erityisesti mittareita lisätty ja tarkennettu. 1.0 Harri Kauhanen 19.10.2000 Muutoksia opponointitilaisuuden kommenttien pohjalta. Laadun seurantaa on täsmennetty lisäämällä kokonaan uusi luku 6, jossa käsitellään tarkemmin, miten ja milloin laatukriteerejä tulee seurata. Muihin osiin muutama pieni täsmennys. (Luonnos 2) (Luonnos 3) (Luonnos 4) 1.0 Harri Kauhanen 7.11.2000 Hyväksytty versio Antti Tuomaala
4(5) 1. Johdanto 1.1 Laatusuunnitelman tarkoitus Tässä laatusuunnitelmassa kuvataan laadun varmistukseen liittyvät toimet, jotka tulee toteuttaa. Dokumentti liittyy kiinteästi projektisuunnitelmaan ja tarvittaessa sitä voidaan päivittää projektin aikana. Laatukriteerejä voidaan kuitenkin muuttaa vain asiakkaan ja projektiryhmän yhteisellä päätöksellä. Tässä laatusuunnitelmassa esitetyt laatukriteerit toimivat laadun mittareina projektin laatua arvioitaessa. 1.2 Viittaukset muihin dokumentteihin # Documentti Selitys 1 Projektisuunnitelma Koko projektin läpiviennin suunnitelma. Laatusuunnitelman voidaan katsoa olevan osa projektisuunnitelmaa. 2 Dokumenttienhallintasuunnitelma Dokumentoinnin työkalut ja menetelmät. Dokumenttien versiointi, nimeäminen ja sijainti. Myös tyyliseikkoihin kiinnitetään huomiota. 3 Testaussuunnitelma Tehdään myöhemmin. 1.3 Laatudokumentin hyväksyminen ja muuttaminen 1.3.1 Laatusuunnitelman hyväksyminen Laatusuunnitelma hyväksytään yhdessä asiakkaan ja työryhmän kanssa. 1.3.2 Suunnitelman muuttaminen Laatusuunnitelmaa voidaan muuttaa normaaliin muutoksenhallinta menettelytapaan. Tarkemmin tämä prosessi on selvitetty Projektisuunnitelmassa (1) esitetyllä tavalla. Laatukriteerejä voidaan päivittää vain yhdessä työryhmän ja asiakkaan kanssa. 1.4 Määritelmät, termit, lyhenteet ja merkintätavat Termi tai käsite Työryhmä / Toimittaja Tilaaja Ohjaaja Asiakas Kurssin vetäjät Johtoryhmä Merkitys Harjoitustyöryhmän varsinaiset jäsenet. Kaikki ovat Teknillisen Korkeakoulun opiskelijoita. Työn varsinainen tilaaja. Osallistuu erityisesti toiminnallisen määrittelyn laatimiseen. Asiakkaan osoittama työn ohjaaja, joka sitoutuu auttamaan työryhmää projektiin liittyvissä ongelmissa. Yleisnimitys viitatessa joko tilaajaan, ohjaajaan tai koko yritykseen. Ohjelmistoprojekti kurssin henkilökuntaa, jotka osallistuvat projektin katselmuksiin ja työn arvosteluun. Toimittaja, tilaaja, ohjaaja ja kurssin vetäjät muodostavat kurssin johtoryhmän.
5(6) Termi tai käsite Laatuvastaava Läpikäynti Katselmus Paritarkistus Laadunvarmistus Merkitys Työryhmän jäsen, joka vastaa projektin edistymisestä laatutavoitteiden mukaisesti. Laatuvastaava seuraa aktiivisesti muitten työryhmän jäsenten laadullista toimintaa ja auttaa ryhmän jäseniä laatuun liittyvissä ongelmissa. Projektin tuotoksia käydään läpi ja löydetyt virheet/ongelmat kirjataan ylös. Läpikäynti voi olla esim. dokumenttien/lähdekoodin tarkastusta, yhdessä tai yksikseen. Projektin tuotokset käydään huolellisesti läpi ja tarkastetaan. Materiaali jaetaan osallistujille etukäteen. Tilaisuudessa osallistuja antavat kommentteja. Kommenteista ja tehdyistä päätöksistä tehdään pöytäkirja. Tarkastettavat asiakirjat joko hyväksytään, hyväksytään kommentein tai hylätään. Toisen harjoitusryhmän jäsen tarkistaa tämän harjoitustyön tuotoksia ja päinvastoin. Projektin sisäinen mekanismi, jolla pyritään varmistamaan projektin tuotosten (dokumenttien, lähdekoodin, ohjelman jne.) laatu. Projektin laatuvastaava huolehtii laadunvarmistuksen toimimisesta, mutta jokainen ryhmän jäsen osaltaan velvollinen huolehtimaan siitä, että oma toiminta on laadukasta. Laadunvarmistuksen mekanismeja ovat: läpikäynnit, katselmukset testaus Laadunvarmistus pyrkii vastaamaan kysymykseen ovatko tulokset/tuotokset riittävän hyviä, jotta projektia voi edetä? Siis, projekti ei voi jatkua seuraavaan vaiheeseensa ennen kuin kunkin vaiheen laadulliset kriteerit on täytetty.
6(7) 2. Laatuorganisaatio 2.1 Jäsenet ja roolit Varsinainen ryhmän koostumus ja roolit on esitetty projektisuunnitelmassa (1). Tässä organisaatio on esitetty nimenomaan laadunvarmistuksen kannalta. Henkilö / Organisaatio Työryhmä Harri Kauhanen Antti Tuomaala Tuija Rinne Kurssin vetäjät, toinen ryhmä Rooli Suunnitteluryhmä Laatuvastaava Projektipäällikkö Asiakas Ulkopuolinen näkökulma 2.2 Vastuut 2.2.1 Suunnitteluryhmän vastuut Koko työryhmä osallistuu laadunvarmistuksen suunnitteluun ja hyväksyy suunnitelmat. 2.2.2 Laatuvastaavan vastuut Laatuvastaava vastaa laatukriteerien seurannasta projektin aikana. 2.2.3 Projektipäällikön vastuu Projektipäällikkö on viime kädessä vastuussa myös projektin laadullisesta onnistumisesta. Varsinaisista laatukriteereistä projektipäällikkö huolehtii erityisesti suunnitellun aikataulun toteutumisesta ja kokousten laadukkaasta valmistelusta ja toteutumisesta. Lisäksi riskienhallinta on projektinpäällikön vastuulla. 2.2.4 Asiakkaan vastuu Myös asiakas vastaa osaltaan siitä, että projekti edistyy laadullisesti suunnitelmien mukaan. Erityisesti katselmuksiin on syytä panostaa, jotta sekä työryhmällä ja asiakkaalla on yhteneväinen kuva projektin todellisesta tilasta. 2.2.5 Ulkopuolinen näkökulma Projektille ei järjestetä varsinaista ulkopuolista auditointia sen harjoitustyöluonteen vuoksi. TKK:n ohjelmistoprojektin kurssin henkilökunta on lähinnä tätä funktiota. Lisäksi järjestetään joitakin paritarkistuksia, jossa jonkin toisen (parit jaetaan myöhemmin) tarkistavat projektin tuotoksia.
7(8) 3. Laadunvarmistus 3.1 Läpikäynnit ja katselmukset 3.1.1 Projektin johtoryhmän katselmukset Jokaisen osapalautuksen jälkeen järjestetään johtoryhmän katselmustilaisuus. Tilaisuuteen valmistaudutaan etukäteen huolella käymällä käsiteltävät asiakirjat läpi, tehden jo valmiiksi muistiinpanoja varsinaista tilaisuutta varten. Tämä koskee erityisesti asiakasta ja kurssien vetäjiä. Toimittaja eli työryhmä valmistautuu tilaisuuteen järjestämällä läpikäyntejä tai jopa pienimuotoisia sisäisiä katselmustilaisuuksia. Itse tilaisuudessa tulokset käydään yhdessä läpi. Mahdolliset huomautukset ja ongelmakohdat käsitellään yhdessä ja samalla voidaan jo esittää korjausehdotuksia. Kaikista kommenteista ja päätöksistä pidetään kirjaa. Lopuksi tuotokset joko hyväksytään, hyväksytään korjauksin tai hylätään. Hylätyt tuotokset korjataan ja hyväksytetään uudelleen johtoryhmällä (tai vähintään asiakkaalla). Mahdollisiin ongelmiin puututaan mahdollisimman pian tilaisuuden jälkeen. Pienet virheet kunkin tuotoksen vastuuhenkilö korjaa itsenäisesti ja isommat ratkotaan järjestämällä palaveri. 3.1.2 Läpikäynnit Läpikäyntejä järjestetään jonkin projektin osakokonaisuuden valmistuttua. Erityisesti läpikäyntejä järjestetään ennen johtoryhmän katselmusta. Työkokonaisuuden tekijä/vastuuhenkilö valitsee läpikäyntiin osallistuvat henkilöt ja valmistaa tilaisuuden. Kaikkien ryhmän jäsenten osallistuminen ei ole aina välttämätöntä, mutta usein tarpeellista. Päätös kokoonpanosta kuuluu työkokonaisuuden vastuuhenkilölle. Tarkastettava työ jaetaan hyvissä ajoin osallistuville. Läpikäynnissä tarkastettava tuotos käydään järjestelmällisesti läpi. Tilaisuudessa vastuuhenkilö kirjaa löydetyt puutteet, virheet ja kommentit. Tilaisuuden päätteeksi päätetään tarvitaanko uutta läpikäyntiä. Läpikäyntejä tulee järjestää kaikille projektissa syntyville tuotoksille sekä varsinaiselle dokumentaatiolle, teknisille suunnitelmille (kaavioille yms.) sekä itse tuotetulle koodille. 3.1.3 Paritarkistukset Kurssilla muodostetaan ryhmistä parit, jotka tarkastavat toistensa tuotoksia. Parintarkistuksissa joku toinen kurssille osallistuva ryhmä (kurssin henkilökunnan osoittama opponointiryhmä) tarkistaa projektimme tuotoksia. Tarkastuksen kohteena voi olla dokumentaatio tai syntyvä sovellus tai sen osa. Löytyneet virheet ja puutteet raportoidaan kurssin Burana järjestelmään. Oma ryhmämme tekee samantapainen tarkistuksen opponointiryhmän tuotoksille.
8(9) 3.2 Testaus 3.2.1 Johdanto Syntyvä ohjelmisto on testattava huolellisesti. Testaus voidaan jakaa kolmentyyppiseen perustapaukseen: Moduulitestaus Integraatiotestaus Järjestelmätestaus Moduulitestauksessa keskitytään testaamaan selkeän ohjelmakokonaisuuden (moduulin) toimivuutta. Integraatiotestauksessa testataan moduulien toimivuutta yhdessä. Järjestelmätestauksessa läpikäydään koko järjestelmän toimivuus. Jokaista testitilaisuutta varten laaditaan testaussuunnitelma. Testaussuunnitelma tulee laatia riittävän aikaisessa vaiheessa. Sen sisällön tulee perustaa nimenomaan järjestelmän toiminnalliseen ja tekniseen suunnitteluun ei esimerkiksi siihen, mitä on keritty koodata. Jälkimmäinen tapa johtaa helposti siihen, että testaussuunnitelmassa keskitytään toimintoihin, joiden tiedetään toimivan. Käytännössä testisuunnitelman laatiminen ajoitetaan suunnitteluvaiheen loppupuolelle ja tarvittaessa suunnitelmaa voidaan täydentää myös toteutuksen aikana. Itse testaus tulee ajoittaa vaiheisiin, kun projektin tilassa on saavutettu jokin virstanpylväs (esim. moduuli katsotaan olevan valmis ). Testauksessa kerätään järjestelmällisesti dataa ohjelmiston toimivuudesta testaussuunnitelman mukaan. Testitilaisuuden jälkeen laaditaan testiraportti. Testiraportti sisältää vähintään testilokin, jossa kunkin testivaiheen tulos kirjataan ylös. Lisäksi testiraportissa on syytä tutkiskella testin kokonaistulosta laatimalla virhe- ja testausraportti, jossa testausjärjestelyjä ja tuloksia analysoidaan tarkemmin. Testisuunnitelmien ja raporttien laadinta tarkennetaan myöhemmin tehtävässä testaussuunnitelmassa. 3.3 Laatukriteerien seuranta Laatukriteerien toteutumista tulee säännöllisesti seurata. Seurannasta vastaa ensisijaisesti laatuvastaava. Käytännössä laatukriteerien seuraus voidaan järjestää suorittamalla laatukatselmuksia. Laatukatselmuksia tulee järjestää ennen projektin vaiheiden virstanpylväitä eli ennen palautuksia. Laatukatselmuksessa käydään mittarit läpi ja todetaan, onko laatutavoitteissa pysytty vai ei. Poikkeamat tulee kirjata palautuksen yhteydessä tehtävään edistymisraporttiin. Kaikkia laatukriteerejä ei pysty projektin alkuvaiheessa edes mittaamaan, mutta mitä pidemmälle projekti edistyy, sitä tärkeämmäksi laatukriteerien seuraaminen muodostuu.
9(10) Laatukatselmusten päivämäärät ja tarkistettavat osa-alueet on listattu kappaleessa 6.
10(11) 4. Laatuprosessit 4.1 Muutostenhallinta 4.1.1 Yleistä Muutosten hallintaa on käsitelty projektisuunnitelmassa (1). Muutokset tulee aina käsitellä sovitun prosessin mukaisesti. 4.1.2 Kriteerejä Ovatko muutokset hallittuja? 4.2 Dokumenttien hallinta 4.2.1 Yleistä Dokumenttien hallintaa on käsitelty dokumenttienhallintasuunnitelmassa (2). Dokumentista käy mm. ilmi erilaiset nimeämiskäytännöt ja versionhallinnan järjestelyt. 4.2.2 Kriteerejä Ovatko dokumentit/ohjelmakoodi helppolukuisia? Onko dokumentaatio/ohjelmakoodi aina konsistenssia (tieto löytyy sieltä mistä loogisesti pitääkin, samoja asioita ei ole tehty useaan kertaan)? Onko projektiin liittyvät dokumentit aina saatavilla ja ajan tasalla? 4.3 Suunnittelu 4.3.1 Suunnitteluprosessi Suunnitteluprosessia ei tämän projektin tiimoilla erikseen dokumentoida. Kurssin mukaisesti kuitenkin noudatetaan USDP (Unified Software Development Process) prosessia. Prosessi on esitelty lyhyesti kurssin kotisivulla: http://mordor.cs.hut.fi/tik-76.115/ohjeet/prosessiohje.htm Suunnittelun apuna voi myös käyttää Comptelin omia käsikirjoja, joissa prosessin vaiheisiin pureudutaan yksityiskohtaisemmin. Koska Comptelin CoMet-menetelmistö hiukan poikkeaa USDP prosessista, tulee edellä mainittuja käsikirjoja noudattaa vain soveltaen. Yksittäisiin projektin vaiheisiin Comptelin käsikirjat sopivat erinomaisesti, mutta suurissa linjoissa on pitäydyttävä kurssin vaatimassa prosessissa. 4.3.2 Kriteerejä Onko suunnitteluun ja sen osa-alueisiin panostettu riittävästi?
11(12) Onko asiakas tyytyväinen? 4.4 Toteutus 4.4.1 Toteutus- ja testausprosessi Toteutus- ja testausprosesseja ei määritellä omina dokumentteinaan. Sen sijaan toimitaan luvussa 4.3.1 esitetyn USDP prosessin mukaisesti. 4.4.2 Toteutuksen laatutavoitteet Toteutuksen laatutavoitteilla tarkoitetaan esimerkiksi ohjelmiston suorituskyky ominaisuuksia. 4.4.3 Kriteerejä 4.5 Ylläpito Onko toteutettu mitä on suunniteltu? Onko toteutus ollut laadukasta? Onko asiakas tyytyväinen? Koska projekti on tutkimusluontoinen, ylläpito ei ole oleellista. Asiakas on kiinnostunut projektissa syntyvistä mahdollisista menetelmistä (algoritmeista) ja ohjelmistosta pohjana vastaaville hankkeille tulevaisuudessa.
12(13) 5. Laatukriteerit 5.1 Johdanto Laatukriteerien laatiminen voi olla hankalaa. Erityisesti sellaisten mittareiden kehittäminen voi olla hankalaa, jotka todella mittaavat halutun kriteerin toteutumista numeerisesti. Tällaisia mittareita kannattaa kuitenkin yrittää kehittää, sillä projektin kiireessä subjektiivinen tarkastelu voi jäädä puolitiehen. Numeerisella mittareilla saadaan objektiivista tietoa projektin tilasta (olettaen että itse mittarit on laadittu huolella). Subjektiiviset mittarit ovat yhtä tärkeitä, mutta niitä analysoitaessa voi olla vaikea olla objektiivinen. Tähän tulee kuitenkin pyrkiä missään tapauksessa ei pidä mennä siihen, että luo projektin tilasta paremman kuvan kuin se itse asiassa on! Ohjelmistoprojektin läpiviennin kannalta on tärkeää että itse tuotantoprosessi olisi laadukkaasta. Erityisen tärkeää on myös itse ohjelmiston laatukriteerien muodostaminen. Ilman näitä kriteerejä voi käydä niin, että ohjelmisto toteuttaa tarkalleen määritellyn funktion, mutta on kuitenkin käytännössä käyttökelvoton. Esimerkiksi ohjelmisto toimii hyvin testidatalla, mutta todellisessa käytössä valitut algoritmit voivat osoittautua niin hitaiksi, että se muuttuu käyttökelvottomaksi. Kaikkien mittareiden laatiminen ei ole mahdollista tässä vaiheessa, mutta periaatteessa laatukriteerit on pyrittävä asettamaan jo ennen suunnittelua tai jossain (vähemmän tärkeissä) tapauksissa ennen toteutusta. Muuten käy helposti niin, että kriteerit laaditaan toteutuksen pohjalta eikä päinvastoin. 5.2 Yleiset laatutavoitteet Projektin yleisiä laatutavoitteita on koottu seuraavaan taulukkoon. No Pri Kriteeri Mittari Tavoite Perustelut 1 2 Ovatko dokumentit helppolukuisia? Todetaan dokumenteista miten hyvin ne noudattavat dokumenttienhallintasu unnitelman ohjeita. Esimerkiksi: dokumenttien nimeäminen tyyli ja rakenne versiointi käsitteet selitetty sujuva suomen kieli Kaikki mittarit toteutuvat. Asioiden omaksuminen helpottuu, jos dokumentit ovat helppolukuisia ja jossain määrin samantapaisia. Sujuva suomenkieli on tärkeämpää kuin hienojen termien viljely. Ryhmän jäsenten työskentely helpottuu, kun käytännöt on samanlaisia. Muiden tekemiä dokumentteja on helppo päivittää.
13(14) No Pri Kriteeri Mittari Tavoite Perustelut 2 2 Onko dokumentaatio konsistenssia? 3 5 Onko ohjelmakoodi helppolukuista? 4 5 Onko projektiin liittyvät dokumentit aina saatavilla ja ajan tasalla? 5 10 Onko suunnittelun panostettu riittävästi (onko tekninen suunnittelu ollut riittävää)? Vertaillaan dokumentteja toisiinsa ja todetaan vähintään seuraavat asiat: tietosisällön päällekkäisyys dokumenttien välillä tiedon löytyminen mahdollisimman loogisesta paikasta (oikea dokumentti, oikea kappale) Todetaan koodista miten hyvin se noudattaa dokumenttienhallintasu unnitelman ohjeita. Esimerkiksi: kommenttien käyttö JavaDoc kommentointi nimeämiskäytänn öt (luokat, metodit, muuttujat jne.) sisentäminen Todetaan, onko projektin kotisivulla olevat dokumentit niiden viimeisemmät versiot. Tarkistetaan, onko dokumentteihin liittyvä muu aineisto saatavilla (kuvat, kaaviot jne.) Todetaan tilanteet, jolloin tarkasteltava dokumentti (esim. läpikäynti) ei ole ollut saatavilla kahta päivää ennen tilaisuutta. Todetaan suunnitteluvaiheen jälkeen tehtyjen muutosten lukumäärä ja niiden vaikutus aikatauluun ja työmääriin. Pieni päällekkäisyys sallitaan silloin kun pelkkä viittaus toiseen dokumenttiin vaikeuttaisi asian ymmärtämistä. Oikea tiedon kirjauspaikka voi olla vaikea määritellä, mutta tähän pyritään. Tavoitteena on, että ohjeita on noudatettu. Koodiläpikäynnissä kiinnitetään näihinkin asioihin huomiota. Mittari toteutuu täydellisesti. Tavoitteena, että mikään muutos ei lisäisi tuntimääriä yli 50 % alkuperäisestä suunnitelmasta. Toisen tekemän koodin ymmärtäminen helpottuu ja koodia voi jatkossa päivittää muutkin kuin alkuperäinen kirjoittaja. Oleellinen osa projektin toimivuutta.
14(15) No Pri Kriteeri Mittari Tavoite Perustelut 6 10 Onko suunnitteluun panostettu riittävästi (onko pystytty arvioimaan työmääriä)? Todetaan ovatko suunnitellut tehtävät ajoissa valmiina. Tarkastellaan tilastollisesti ViCa työkalulla tehtyjä mittareita. Vähintäänkin tulee tarkastella seuraavia mittareita tehtäväkohtainen myöhästyminen (tai ajoissa valmistuminen) suhteessa suunniteltuun kestoon edellisten keskiarvo ja keskihajonta niiden tehtävien lukumäärä, joiden aloittaminen myöhästyy toisen tehtävän myöhästymisestä johtuen edellisen kohdan tehtäväkohtainen myöhästyminen ja näiden keskiarvoa vastaavat tarkastelut tehdyille tuntimäärille toteutusvaiheessa lasketaan vaihekohtaisesti ja luovutusvaiheessa lisäksi koko projektin osalta Ajallisesti alle 10% tehtäväkohtainen myöhästyminen katsotaan läpi sormien, mutta keskimäärin tehtävät eivät saa kuitenkaan myöhästyä. Jos yksittäinen tehtävä myöhästyy yli 50 %, on järjestettävä tilaisuus, jossa arvioidaan tapahtunut ja haetaan tilanteelle ratkaisua. Erityisen tärkeät tehtävät tai sellaiset, joiden myöhästyminen vaikeuttaa merkittävästi muita tehtäviä, tulee tarkastella tiukemmin kriteerein. Tällöin pieneenkin myöhästymiseen kiinnitetään erityistä huomiota. Mikäli kaikki tehtävät myöhästyvät keskimäärin yli 10 %, niin em. kaltainen tilaisuus järjestettävä. Käytettyihin tuntimääriin kiinnitetään myös huomiota. Koska tuntimäärien arvioiminen voi olla vaikeaa, niin yksittäisten tehtävien tuntimäärien seurantaan ei kiinnitetä niin suurta huomiota, mutta kokonaistuntimäärään kylläkin. 10 % ylitys katsotaan läpi sormien, suurempaan puututaan ja jos kokonaistuntimäärät ylittyvät 50% arvioidusta, on järjestettävä kriisikokous, pohdittava syitä miksi arviointi meni pieleen ja mahdollisesti muutettava projektin vaatimuksia.
15(16) No Pri Kriteeri Mittari Tavoite Perustelut 7 10 Onko toteutettu mitä on suunniteltu? 8 10 Onko toteutus ollut laadukasta (virheetöntä)? 9 10 Onko toteutus ollut laadukasta (asiakkaan tyytyväisyys)? Vertaillaan suunnitteludokumenttej a teknisiin dokumentteihin ja ohjelmistoon. Todetaan seuraavat asiat: ominaisuudet, jotka on toteutettu kuten suunniteltu ominaisuudet, jotka puuttuvat kokonaan ominaisuudet, jotka on toteutettu puutteellisesti tai väärin ominaisuudet, jotka on toteutettu, mutta ei suunniteltu Opponointiryhmän löytämien virheiden (eri vakavuusasteineen) lukumäärä. Omassa testauksessa löytyneet virheet, kun projekti on palautusvaiheessa. Erityisesti luovutus / asiakkaan hyväksymistestaus. Virheiden korjaukseen tarvittava aika. Asiakkaan antamat arvosanat. Asiakkaan haastattelu. On toteutettu juuri ne ominaisuudet mitä on suunniteltu. Puuttuvat ja puutteelliset ominaisuudet todetaan, pohditaan miksi näin on käynyt ja pyritään korjaamaan projektin seuraavassa vaiheessa. Vakavia virheitä ei saisi löytyä lainkaan. Muiden virheiden sallitulle lukumäärälle ei tässä esitetä tavoitetta. Toimitaan mutu pohjalta eli muutamia virheitä aina sattuu, mutta jos esimerkiksi yksi moduuli sisältää yli kolme keskivakavaa virhettä, niin syy koetaan selvittää. Todetaan mm. onko tehtävä ollut liian vaativa ja resursoidaan tehtäviä uudelleen. Tavoitteen mahdollisimman tyytyväinen asiakas.
16(17) No Pri Kriteeri Mittari Tavoite Perustelut 10 5 Toimiiko kommunikointi ryhmän sisällä ja asiakkaan kanssa? 11 5 Noudatetaanko projektissa sovittuja menetelmiä? 12 5 Onko projektia riskejä osattu arvioida riittävästi? 13 5 Ovatko muutokset hallittuja? Todetaan tilanteet, joissa jotakin on jäänyt tekemättä tai joku asia on turhaan vaikeutunut en tiennyt tilanteiden takia. Todetaan tilanteet, joissa jotakin on jäänyt tekemättä tai joku asia on turhaan vaikeutunut tiedottamisen myöhäisen ajankohdan takia. Todetaan tilanteet, jolloin asiakkaan ja ryhmän näkemykset jostain sovitusta asiasta poikkeavat. Katselmuksissa hylättyjen dokumenttien lukumäärä. Sellaisten takaiskujen lukumäärä ja vakavuus, joihin ei ole varauduttu (projektisuunnitelman riskit). Todetaan, onko muutos kirjautunut muutosta koskevaan dokumentteihin. Tavoitteena, että en tiennyt tilanteita ei tapahdu lainkaan. Jos tapahtuu, niin on tarkasteltava miksi näin pääsi tapahtumaan. Tärkeistä asioista, tapaamisista yms. on oltava tieto ryhmän jäsenillä ajoissa. Sovituista kokouksista tulee tiedottaa kahta päivää ennen kokouskutsulla. Tavoitteena on myös, että asiakkaan ja ryhmän näkemyksen ovat aina yhteneväiset. Tavoitteena on että kaikki dokumentit hyväksytään sellaisenaan tai korjauksin. Tavoitteena on, että sellaisia vakavia takaiskuja ei tule, joihin ei ole osattu valmistautua. Tavoitteena on, että kaikki muutokset on tehty muutostenhallintaprose ssin mukaisesti ja se näkyy myös dokumenteissa. Osin päällekkäinen kriteerin 7 kanssa. Näkökulma kuitenkin toinen, joten kriteeri on perusteltu. 5.3 Ohjelmiston laatutavoitteet Kirjoitetaan vaiheen T2 alussa.
17(18) 6. Laatukatselmukset 6.1 Yleistä Laatukatselmukset järjestetään aina ennen projektin sisäistä katselmustilaisuutta (poikkeuksena T1 vaihe). Laatukatselmukset eivät yleensä ole yhteisiä tilaisuuksia, vaan kunkin jäsenen (tai jäsenten yhdessä) laatumittareiden tarkastelu laadittuja laatukriteerejä vastaan. Katselmuksen tulokset toimitetaan oheisen taulukon päivämäärään mennessä ryhmän muiden jäsenten tietoon. Oheisessa taulukossa sarake painotus on todellakin painotus, sillä muitakin osaalueita tulee tarkastella projektin eri vaiheissa. Vaihe Pvm Painotus T1 6.11.2000 (ma) Prosessien noudattaminen. T2 7.12.2000 (to) Koodauksen yleislaatu. T3 7.2.2001 (ke) Älykoneen toimivuus. Suunnitelmien ja toteutuman vastaaminen. T4 14.3.2001 (ke) Järjestelmätestaus LU 18.4.2001 (ke) Kokonaisvaltainen Seuraavien kappaleiden taulukoissa painotus on esitetty siten, että vaiheen kannalta tärkeimmät laatutarkastelut on esitetty ensin. Luvussa 5 esitettyjen kriteerien prioriteetit painavat itsessään enemmän eli taulukossa alempi tarkastelu voi olla kokonaisuuden kannalta tärkeämpi, mutta järjestys pyrkiikin kuvaamaan tärkeysjärjestystä vaiheen kannalta. Suluissa merkitty mittarin numero tarkoittaa sitä, että kriteerin seurannalle voi tässä vaiheessa antaa vähemmän painoarvoa, jos ryhmä on osoittanut edellisessä vaiheessa kypsyytensä tavoitteiden tasolle. Kokonaan näitäkään mittareita ei saa silti jättää seuraamatta. 6.2 T1 vaiheen laatukatselmus 6.11.2000 Toteutus 1 vaiheessa keskitytään ohjelmiston määrittelyyn. Myös projektiryhmän työskentelytavat alkavat toivon mukaan asettua oikeille uomilleen. Tehtävässä laatukatselmuksessa painotetaan tässä vaiheessa enemmän projektin työskentelyn kriteerejä itse tuotettavan ohjelmiston sijaan. Laatukatselmus järjestetään juuri ennen palautusta ja tämän katselmuksen tuloksilla ei juurikaan enää palautettavia dokumentteja korjailla. Sen sijaan katselmuksen tulokset esitellään edistymisraportissa Mittari Tekijä Selitys / Perustelut
18(19) Mittari Tekijä Selitys / Perustelut 6 AT Työmäärän arviointi meidän kaltaisessa projektissa on oikeasti vaikeata, mutta siihen tulee kuitenkin pyrkiä. Projektipäällikkö tarkastelee tilanteen huolellisesti. Mikäli mittarin määräämiä poikkeamia esiintyy, niin tulee jokaisen poikkeaman kohdalla miettiä miksi arvioitiin väärin. Näin kerättyä kokemusta pyritään hyödyntämään seuraavan vaiheen tarkemmassa suunnittelussa. 10 AT Ryhmän kommunikaation toimiminen on oleellista. Tämän mittarin tarkastelu voi olla hankalaa, mutta projektipäällikön tulee pyrkiä mahdollisimman ryhmäitsekriittiseen tarkasteluun ja todeta rehellisesti miten mittari täyttyy. 1, 2 HK Tarkistetaan, onko dokumenttien rakenne ja hallinta määritellyn mukaista. Tässä vaiheessa tarkastukset suoritetaan liioitellut tarkasti, jotta jatkossa asioihin ei tarvitsisi enää puuttua. Mikäli nämä kriteerit todetaan hyvin täytetyiksi ilman huomautuksia, voidaan olettaa, että dokumenttien hallinta on yleisesti ryhmän hallussa. Tällöin asia tuskin vaatii jatkossa enää opettelua, mutta jatkossakin näitä mittareita seurataan. Mikäli todetaan ongelmia, kriteerejä tarkastellaan seuraavissa katselmuksissa yhtä huolellisesti. 4 HK Onko pysytty dokumenttien valmistumiselle asetetuissa päivämäärissä. Palautusvaiheen lopusta pitää pyrkiä luomaan yhtä kiireetöntä aikaa kun projektin muukin aika. Mikäli aikataulussa ei pysytä, niin pohditaan mikä tähän on johtanut. Muut laadunvarmistukseen liittyvät prosessit: Sisäinen katselmustilaisuus läpikäynteineen (dokumentit) Johtoryhmän katselmustilaisuus. 6.3 T2 vaiheen laatukatselmus 7.12.2000 Toteutus 2 vaiheessa ryhmän jäsenet ovat päässet jo koodauksen makuun ja on syytä tarkastella näiden prosessien laadukkuutta. Proto 1 tavoitteena on ulkoisten puitteiden luonti muodostajakonetta varten (rajapinnat, kenties jo yksinkertainen käyttöliittymä). Koodin yleisen laadun lisäksi kiinnitetään huomiota rajapintojen toimivuuteen ja kattavuuteen. Pientä huomiota kiinnitetään käyttöliittymän käytettävyyteen. Älykkään muodostajakoneen toimivuutta ei mitata, kun sitä ei todennäköisesti ole. Sen sijaan kiinnitetään huomiota siihen, että tälläkin rintamalla on edetty. Mittari Tekijä Selitys / Perustelut 5 TM Tarkastellaan kuinka hyvin suunnittelu on pitänyt kutinsa projektin tässä vaiheessa. Jos muutoksia on tullut ja aikataulut on muuttuneet, niin toivottavasti siitä osataan ottaa jo tässä vaiheessa opiksi, jotta projektin loppuvaihe ei menisi pipariksi. Tarkoitus ei ole oppia asioita kantapään kautta, mutta pyritään oppimaan kuinka muutokset vaikuttavat työmääriin. 6 AT Voidaan poikkeuksellisesti tehdä sisäisen katselmustilaisuuden jälkeen, jotta tuntimääriä voisi paremmin arvioida. Pitkällä juoksulla tavoitellaan, että arvioiduissa aikatauluissa ja työmäärissä pysytään paremmin ja paremmin. Suositetaan tarkastus vaihe T1:n mukaisesti.
19(20) Mittari Tekijä Selitys / Perustelut 3 HK Koodaukseen pyritään noudattamaan sovittuja tapoja ja löytämään yhteiset työtavat sellaisissa asioissa, joita on vaikea määritellä. Kiinnitetään erityistä huomiota yleisimpiin puutteisiin eli nimeämiskäytäntöjen seuranta, kommentointi ja luokkien dokumentointi. 1, 2, 4 HK Tämän mittauksen painoarvoon vaikuttaa edelliseen vaiheen onnistuminen. 10 AT Kuten edellä Muut laadunvarmistukseen liittyvät prosessit: Moduulitestausta vaiheen aikana Sisäinen katselmustilaisuus läpikäynteineen (dokumentit, rajapinnat, lähdekoodi, tietokanta) Johtoryhmän katselmustilaisuus 6.4 T3 vaiheen laatukatselmus 7.2.2001 Toteutus 3 vaiheessa on tavoitteena saada aikaiseksi proto, joka toimii ainakin jotenkin älykkäästi. Demoluontoinen käyttöliittymä tulisi tässä vaiheessa olla mahdollisimman valmis. Käyttöliittymälle ei aseta tässä projektissa suuria vaatimuksia, mutta senkin vähimmäistoimivuus mitataan. Älykkäästi toimivan muodostajakoneen toimintaa mitataan eri kriteerein. Mahdollisten vaihtoehtoisten koneiden toimintaa vertaillaan. Mittari Tekijä Selitys / Perustelut 7 TM Tarkastellaan erityisen huolellisesti, onko toteutettu se mitä on suunniteltu. Mikäli todetaan, että ohjelmistossa on puutteita tai ylimääräisiä ominaisuuksia, niin pohditaan siihen syitä ja laaditaan suunnitelma, kuinka tehdyt virheet korjataan ja äärimmäisessä tapauksessa muutetaan projektin vaatimuksia (asiakkaan kanssa). 8 NS + kaikki HUOM! Moduulitestausta tulee suorittaa aina moduulin valmistuttua eikä jättää niitä viime vaiheeseen. Eri osien välistä integraatiotestausta tulee järjestää viimeistään laatukatselmuksen yhteydessä. Tarkemmat ohjeet testaussuunnitelmassa (3). 13 HK Tarkastellaan onko muutosprosessi toiminut niin kuin pitää. 5 TM Kuten edellä. 6, (10) AT Kuten edellä. 3, (1, 2, 4) HK Kuten edellä. Muut laadunvarmistukseen liittyvät prosessit:
20(21) Moduulitestausta vaiheen aikana Integraatiotestausta vaiheen lopussa Sisäinen katselmustilaisuus läpikäynteineen (dokumentit, rajapinnat, lähdekoodi, tietokanta) Johtoryhmän katselmustilaisuus 6.5 T4 vaiheen laatukatselmus 14.3.2001 Toteutus 4 vaiheen tavoitteena on mahdollisimman toimiva järjestelmä ja ennen kaikkea tulos siitä, miten projektin tutkimuksellinen osuus on onnistunut. Muodostajakoneen toteutusmallit ja ainakin yhden toteutettu sovellus tulee olla tässä vaiheessa tehty. Koko järjestelmän tulee olla tässä vaiheessa toiminnallisesti valmis, jotta luovutusvaihe todellakin toimii luovutusvaiheena Järjestelmä tulee testata tässä vaiheessa kokonaisuudessaan. Mittari Tekijä Selitys / Perustelut 8 NS + kaikki 5 TM Kuten edellä. 6, (10) AT Kuten edellä. (1, 2, 3, 4) HK Kuten edellä. Kaikenkattava järjestelmätestaus, jossa selvitetään vielä mahdolliset puuttet. Muut laadunvarmistukseen liittyvät prosessit: Moduulitestausta vaiheen aikana Integraatiotestausta vaiheen lopussa Järjestelmätestaus vaiheen lopussa Sisäinen katselmustilaisuus läpikäynteineen (dokumentit, rajapinnat, lähdekoodi, tietokanta) Johtoryhmän katselmustilaisuus 6.6 LU vaiheen laatukatselmus 18.4.2001 Luovutusvaiheen tavoitteena on korjata vielä löytyvät puutteet ja viimeistellä ohjelma asiakkaalle. Tutkimuksellisista tuloksista laaditaan asiakkaalle raportti, jossa arvioidaan käyttäjä- ja palveluprofiilien, sääntöjen ja muodostajakoneen muodostamaa problematiikkaa teoreettisesti ja esitellään mahdollisia ratkaisumalleja. Lisäksi
21(22) esitellään meidän toteuttamaa ratkaisua, verrataan sitä tutkimuksellisiin tuloksiin (esim. mitä on toteutettu) ja pohdiskellaan mikä omassa ratkaisussamme on hyvää ja huonoa. Tuotteen lopullista laatua pyritään arvioimaan huolellisesti tarkastelemalla kaikkia edellä mainittuja kriteerejä. Lisäksi kerätään subjektiivista tietoa asiakkaalta tyytyväisyydestä projektin tuloksiin ja mahdollisesti sen suoritustavasta. Mittari Tekijä Selitys / Perustelut 8 NS + kaikki Kaikenkattava järjestelmätestaus, jossa selvitetään vielä mahdolliset puuttet. Muut laadunvarmistukseen liittyvät prosessit: Moduulitestausta vaiheen aikana Integraatiotestausta vaiheen lopussa Järjestelmätestaus vaiheen lopussa Sisäinen katselmustilaisuus läpikäynteineen (dokumentit, rajapinnat, lähdekoodi, tietokanta) Luovutustilaisuus