LAATUSUUNNITELMA Virtuaaliyhteisöjen muodostamien Versio 1.0 (Luonnos 3)

Transkriptio

1 LAATUSUUNNITELMA Versio 1.0 (Luonnos 3)

2 1(2) 1. JOHDANTO Laatusuunnitelman tarkoitus Viittaukset muihin dokumentteihin Laatudokumentin hyväksyminen ja muuttaminen Laatusuunnitelman hyväksyminen Suunnitelman muuttaminen Määritelmät, termit, lyhenteet ja merkintätavat 4 2. LAATUORGANISAATIO Jäsenet ja roolit Vastuut Suunnitteluryhmän vastuut Laatuvastaavan vastuut Projektipäällikön vastuu Asiakkaan vastuu Ulkopuolinen näkökulma 6 3. LAADUNVARMISTUS Läpikäynnit ja katselmukset Projektin johtoryhmän katselmukset Läpikäynnit Paritarkistukset Testaus Johdanto Laatukriteerien seuranta 8 4. LAATUPROSESSIT Muutostenhallinta Yleistä Kriteerejä Dokumenttien hallinta Yleistä Kriteerejä Suunnittelu Suunnitteluprosessi Kriteerejä Toteutus Toteutus- ja testausprosessi 11

3 2(3) Toteutuksen laatutavoitteet Kriteerejä Ylläpito LAATUKRITEERIT Johdanto Yleiset laatutavoitteet Ohjelmiston laatutavoitteet 16

4 3(4) Dokumentin versiot Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt 1.0 Harri Kauhanen Ensimmäinen luonnosversio (Luonnos 1) 1.0 Harri Kauhanen Toinen luonnosversio. Monia lisäyksiä, mutta erityisesti mittareita on lisätty ja tarkennettu. 1.0 Harri Kauhanen Palaverissa todetut tarkennukset ja lisäykset. Erityisesti mittareita lisätty ja tarkennettu. (Luonnos 2) (Luonnos 3)

5 4(5) Johdanto 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 Laatusuunnitelman hyväksyminen Laatusuunnitelma hyväksytään yhdessä asiakkaan ja työryhmän kanssa 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.

6 5(6) Johdanto 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.

7 6(7) Laatuorganisaatio 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 Suunnitteluryhmän vastuut Koko työryhmä osallistuu laadunvarmistuksen suunnitteluun ja hyväksyy suunnitelmat Laatuvastaavan vastuut Laatuvastaava vastaa laatukriteerien seurannasta projektin aikana 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 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 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.

8 7(8) Laadunvarmistus 3. Laadunvarmistus 3.1 Läpikäynnit ja katselmukset 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 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 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.

9 8(9) Laadunvarmistus 3.2 Testaus 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. Löytyvät virheet/puutteet ja huomautukset tulee raportoida myös käyttäen kurssin Burana työkalua. 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ää ainakin 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

10 9(10) Laadunvarmistus projektin alkuvaiheessa edes mittaamaan, mutta mitä pidemmälle projekti edistyy, sitä tärkeämmäksi laatukriteerien seuraamine muodostuu.

11 10(11) Laatuprosessit 4. Laatuprosessit 4.1 Muutostenhallinta Yleistä Muutosten hallintaa on käsitelty projektisuunnitelmassa (1) Kriteerejä Ovatko kaikki muutokset kirjautuneet dokumentteihin? 4.2 Dokumenttien hallinta Yleistä Dokumenttien hallintaa on käsitelty dokumenttienhallintasuunnitelmassa (2). Dokumentista käy mm. ilmi erilaiset nimeämiskäytännöt ja versionhallinnan järjestelyt 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 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: 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 Kriteerejä Onko suunnitteluun ja sen osa-alueisiin panostettu riittävästi? Onko asiakas tyytyväinen?

12 11(12) Laatuprosessit 4.4 Toteutus Toteutus- ja testausprosessi Toteutus- ja testausprosesseja ei määritellä omina dokumentteinaan. Sen sijaan toimitaan luvussa esitetyn USDP prosessin mukaisesti Toteutuksen laatutavoitteet Toteutuksen laatutavoitteilla tarkoitetaan esimerkiksi ohjelmiston suorituskyky ominaisuuksia 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.

13 12(13) Laatukriteerit 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 Pri Kriteeri Mittari Tavoite Perustelut 2 Ovatko dokumentit helppolukuisia? Todetaan dokumenteista miten hyvin ne noudattavat dokumenttienhallintasuu nnitelman 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ää.

14 13(14) Laatukriteerit Pri Kriteeri Mittari Tavoite Perustelut 5 Onko dokumentaatio konsistenssia? 5 Onko ohjelmakoodi helppolukuista? 5 Onko projektiin liittyvät dokumentit aina saatavilla ja ajan tasalla? 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 dokumenttienhallintasuu nnitelman 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.

15 14(15) Laatukriteerit Pri Kriteeri Mittari Tavoite Perustelut 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 Ajallisesti alle 10% tehtäväkohtainen myöhästyminen katsotaan läpi sormien, mutta keskimäärin tehtävät ei 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. 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 ja mahdollisesti muutettava projektin vaatimuksia.

16 15(16) Laatukriteerit Pri Kriteeri Mittari Tavoite Perustelut 10 Onko toteutettu mitä on suunniteltu? 10 Onko toteutus ollut laadukasta (virheetöntä)? 10 Onko toteutus ollut laadukasta (asiakkaan tyytyväisyys)? 5 Toimiiko kommunikointi ryhmän sisällä ja asiakkaan kanssa? 5 Noudatetaanko projektissa sovittuja menetelmiä? 5 Onko projektia riskejä osattu arvioida riittävästi? Vertaillaan suunnitteludokumentteja 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. Todetaan tilanteet, joissa jotakin on jäänyt tekemättä tai joku asia on turhaan vaikeutunut en tiennyt tilanteiden 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). 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. Tavoitteena, että en tiennyt tilanteita ei tapahdu. Jos tapahtuu, niin on tarkasteltava miksi näin pääsi tapahtumaan. Tavoitteena on että kaikki dokumentit hyväksytään sellaisenaan tai korjauksin. Tavoitteena on, että sellaisia vakavia takaiskuja ei tule, joihin ei ole osattu valmistautua.

17 16(17) Laatukriteerit 5.3 Ohjelmiston laatutavoitteet Tämä osa kirjoitetaan myöhemmin.