8. Laadunvalvonta Ohjelmistojen laatu on parantunut paljon viimeisen 15 vuoden aikana. Tämä näkyy mm. siinä, että asiakkaat ovat keskimäärin tyytyväisempiä tuotteiden toimintaan kuin 90-luvun alussa. Tähän on muutama pääsyy: Yrityksissä on otettu käyttöön uusia entistä laadukkaampia tekniikoita. Laadunvalvonta on saanut huomiota. Standardointi on helpottanut projekteja. Kevät 2005 Ohjelmistotuotanto / Taina 1 Mitä laatu on? Laatu on yllättävän vaikea määriteltävä: Asiakkaan vaatimukset eivät riitä: Implisiittisiä vaatimuksia ei kirjata. Myös muilla kuin asiakkaan sidosryhmillä voi olla laatuvaatimuksia. Esim. ylläpidettävyys. Kaikkia laatuvaatimuksia ei vielä osata kuvata yksiselitteisesti. Onko tuote laadukas, jos asiakkaan odotukset tuotteelle eivät täyty, vaikka kirjatut vaatimukset täyttyvät? Kevät 2005 Ohjelmistotuotanto / Taina 2 Taina 1
Eräs laadun määritelmä Pressman: Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. Toiminnalliset ja ei-toiminnalliset vaatimukset. Standardoitu ohjelmistotuotantoprosessi. Implisiittiset vaatimukset. (R. Pressman, Software Engineering, a Practitioner s Approach. McGraw-Hill) Kevät 2005 Ohjelmistotuotanto / Taina 3 Laadun hallinta Laadun varmistus (quality assurance): määritellään joukko menettelytapoja ja standardeja, joiden avulla päästään hyvään laatuun. Laadun suunnittelu (quality planning): valitaan tietyssä projektissa käytettävät laatuun tähtäävät menettelytavat. Laadun seuranta (quality control): valvotaan, että laatuun tähtäävät toiminnot toteutuvat. Kevät 2005 Ohjelmistotuotanto / Taina 4 Taina 2
Prosessin ja tuotteen laatu Kehitettävän tuotteen laatu riippuu käytetyn prosessin laadusta. Tämä on hyvä asia, sillä jotkut laatuattribuutit ovat vaikeita mitattavia, mutta prosessin hyvyyttä voidaan kyllä mitata. Prosessin ja tuotteen laadun suhde on huonosti hallittu ohjelmistotekniikan ala. Tiedetään, että prosessin laatu vaikuttaa lopputulokseen, mutta ei tiedetä miten. Kevät 2005 Ohjelmistotuotanto / Taina 5 Laatuvaatimukset Laatuvaatimukset ovat ei-toiminnallisia vaatimuksia, liittyvät usein koko järjestelmään, mutta ne voivat liittyä myös johonkin yksittäiseen toimintoon, on kerättävä kuten muutkin vaatimukset, voivat olla myös implisiittisiä. Laatuvaatimusten painotus riippuu toteutettavan ohjelmiston tyypistä. Kevät 2005 Ohjelmistotuotanto / Taina 6 Taina 3
Laatukomponentit käyttöturvallisuus tietoturvallisuus luotettavuus tehokkuus käytettävyys opittavuus joustavuus virheettömyys monimutkaisuus modulaarisuus testattavuus siirrettävyys ylläpidettävyys uuskäyttöisyys Kunkin projektin kohdalla on päätettävä, mitkä laatukomponenteista ovat lopputuotteen kannalta merkittäviä. Kevät 2005 Ohjelmistotuotanto / Taina 7 Kuka huolehtii laadusta? Laadun hallinta on syytä erottaa projektin hallinnasta. Näiden välillä voi olla eturistiriita: tehdäänkö nopeasti vai laadukasta? Yrityksen yhteinen laaturyhmä valvoo projektien laatua. Laaturyhmä tarjoaa johdonmukaiset menettelytavat, vertailukelpoiset havainnot ja Riippumattomuuden yksittäisten projektien aikataulu- ja kustannuspaineista. Kevät 2005 Ohjelmistotuotanto / Taina 8 Taina 4
Mittaus Etenemisen ja laadun seuranta: saadaan täsmällistä tietoa, verrataan suunnitelmaa ja toteutumaa. Projektin lopussa tapahtuva mittaus: kerätään historiatietoa tulevia projekteja varten. Projektin aikana tapahtuva mittaus: ohjataan käynnissä olevaa projektia. Kevät 2005 Ohjelmistotuotanto / Taina 9 Ennustaminen ja mittaus Software process Control measurements Management decisions Kuva I. Sommerville 2004 Software product Predictor measurements Prosessin mitat: prosessin seuranta Tuotteen mitat: laadun seuranta ja ennustaminen Mitattavien suureiden suhde laatukomponentteihin on selvitettävä ennen projektin alkua. Kevät 2005 Ohjelmistotuotanto / Taina 10 Taina 5
Kiinnostavat ja mitattavat suureet Halutaan tietää (laatukomponentit): M ain ta i na b il it y Voidaan mitata: Number of procedure parameters Cyclomatic complexity Reliability Portability U s ab il it y Program size in lines o f code Number of error m e ss ag es Len gth of user m anual Yhteys laatukomponenttien ja mitattavien suureiden välillä ei ole selvä Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 11 Mittausprosessi Prosessin avulla etsitään osia, joiden laatu poikkeaa muiden osien laadusta. Prosessin kulku: 1. Valitse mitattavat suureet. 2. Valitse tutkittavat komponentit. 3. Mittaa komponentit. 4. Tunnista poikkeavat havainnot. 5. Analysoi poikkeavat komponentit. Kevät 2005 Ohjelmistotuotanto / Taina 12 Taina 6
Mitä mitataan? Staattiset mitat: kerätään mittaamalla projektin tuotoksia suunnitelmia koodia dokumentteja kerättävissä projektin alusta alkaen Dynaamiset mitat: kerätään mittaamalla toimivaa ohjelmaa mitan arvo riippuu myös siitä, miten ohjelmaa käytetään: eri toimintojen käyttö syötteet kerättävissä vasta kun on jotakin joka toimii Kevät 2005 Ohjelmistotuotanto / Taina 13 Mitä mitat kuvaavat? Staattiset mitat liittyvät tuotteen rakenteellisiin ominaisuuksiin voi olla välillinen yhteys joihinkin laatuominaisuuksiin esim. monimutkainen rakenne => vaikea ymmärtää Dynaamiset mitat liittyvät tuotteen käyttäytymiseen usein suora yhteys laatuominaisuuksiin esim. suoritusaika, havaittujen häiriöiden määrä edustavuus: mitan arvo kuvaa vain sitä tilannetta, jossa ohjelmaa on käytetty Kevät 2005 Ohjelmistotuotanto / Taina 14 Taina 7
Esimerkkejä tuotteen mitoista Staattisia mittoja: Kutsuttujen metodien (tai funktioiden) lkm Perintähierarkian syvyys Luokkien lkm Käyttötapausten lkm Dynaamisia mittoja: Suoritusaika Tietokantahakujen lkm Kutsuttujen metodien lkm Tulostetun raportin rivien lkm Useat mitat ovat kuvaavampia skaalattuna jollakin (tuotteen tai tehtävän) kokoa kuvaavalla suureella. Kevät 2005 Ohjelmistotuotanto / Taina 15 Prosessin mitat Aikamitat esim. tiettyyn vaiheeseen kulunut aika Resurssimitat esim. henkilötyöpäivien määrä, koneaika Tapahtumamitat esim. testauksessa löytyneiden vikojen lkm, muutospyyntöjen lkm Käytetään prosessin seurantaan ja parantamiseen. Kevät 2005 Ohjelmistotuotanto / Taina 16 Taina 8
Mittaustietojen keruu Mittaus onnistuu parhaiten silloin, kun se ei häiritse normaalia työtä: Mittauksen pitää olla mahdollisimman automaattista. Mitattavat suureet pitää päättää etukäteen. Minimaalisuus: ei turhia mitattavia suureita. Mittauksiin osallistuvien työntekijöiden pitää saada tieto mitattavista suureista, tulosten tulkintatavoista ja tulosten käytöstä. Kevät 2005 Ohjelmistotuotanto / Taina 17 Mittatulosten analysointi Mitattavaan suureeseen vaikuttaa yleensä monta samanaikaista tekijää. Tulosten tulkintaan liittyy epävarmuutta. Esimerkiksi jos testauksessa löytyi vain pieni määrä vikoja, johtuuko se hyvästä koodauksesta? pinnallisesta testauksesta? taitavasta suunnittelusta? huolellisesta katselmoinnista? runsaasta uudelleenkäytöstä? Kevät 2005 Ohjelmistotuotanto / Taina 18 Taina 9
8.1 Prosessin parantaminen Prosessia voi olla tarpeen muuttaa: työ- tai sovellusympäristö muuttuu, työn tavoitteet muuttuvat, tarjolla olevat menetelmät kehittyvät, käytetty prosessi on jäykistynyt Tarkoituksellisen muutoksen tavoitteita: tuotteen laadun parantaminen, kustannusten vähentäminen, työskentelyn tehostaminen Kevät 2005 Ohjelmistotuotanto / Taina 19 Prosessin parannussykli Prosessia parannetaan syklissä: 1. Prosessia mitataan: Käynnissä olevan projektin tai projektissa tehtävän tuotteen attribuutteja mitataan. 2. Prosessia analysoidaan: Mittausten perusteella käytetystä prosessista tunnistetaan heikkoudet ja puollonkaulat. 3. Prosessia muutetaan Analyysissa löydetyt heikkoudet ja pullonkaulat korjataan. Jatketaan vaiheesta 1. Kevät 2005 Ohjelmistotuotanto / Taina 20 Taina 10
Prosessin parantamisprosessi Analyse process Identify improvements Introduce process change Train engineers Tune process changes Process model Process change plan Training plan Feedback on improvements Revised process model Jatkuva, iteratiivinen prosessi Lähtökohtana prosessissa havaitut ongelmat Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 21 Prosessin analysointi Prosessin parantamisen lähtökohtana on malli = kuvaus nykyprosessista. Yrityksen formaali prosessimalli. Mallin analysointi: Todellisen (käytössä olevan) prosessin tunnistaminen. Kytkennät toimintojen, tuotoksien, henkilöiden, rajoitteiden yms. Välillä. Voidaan kuvata kaavioina. Kevät 2005 Ohjelmistotuotanto / Taina 22 Taina 11
Muutosten todentaminen Muutosten todentaminen: mittaukset Mitataan tilannetta kuvaavia suureita ennen muutosta. Mitataan samat suureet muutoksen jälkeen Mitattavien suureiden valinta: Lähtökohtana on usein havaittu ongelma esim. tehoton testaus: mitataan löytyneiden vikojen määrää, testatun koodin määrää ja käytettyä aikaa. Kevät 2005 Ohjelmistotuotanto / Taina 23 Prosessin kypsyys (maturity) Prosessien vertailussa käytettävä käsite Prosessien vertailuun tarkoitetut mallit luokittelevat prosesseja kypsyydeltään erilaisille tasoille. Kuvaa prosessin kyvykkyyttä: tasaisesti laadukas tuotantolinja, hyvin hallittu prosessi, suunnitelmien ja aikataulun pitävyys, sopeutuminen tarvittaviin muutoksiin. Kevät 2005 Ohjelmistotuotanto / Taina 24 Taina 12
SEI CMM SEI CMM (Software Engineering Institute Capability Maturity Model) on tunnetuin kypsyystasomalli. Se kehitettiin alkuaan Yhdysvaltain puolustusministeriön tarpeisiin. SEI CMM on tarkoitettu esimerkiksi ohjelmistoyrityksen alihankkijoiden tason arviointiin. Kevät 2005 Ohjelmistotuotanto / Taina 25 CMM:n kypsyystasot 5. Optimoiva prosessi Level 5 Optimizing Eteneminen alhaalta ylös 4. Hallittu prosessi Level 3 Defined Level 4 Managed 3. Määritelty prosessi Level 2 Repeatable 2. Toistettava prosessi Level 1 Initial 1. Perusprosessi Kuva I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 26 Taina 13
1. Perusprosessi ad hoc -toiminta 2. Toistettava prosessi projektinhallinta laadunvarmistus tuotteenhallinta voidaan toteuttaa vastaavia projekteja kuin ennenkin ei omaa määriteltyä prosessimallia CMM:n tasot 3. Määritelty prosessi oman organisaation tarpeisiin määritelty standardoitu prosessi 4. Hallittu prosessi prosessia ja tuotetta mitataan 5. Optimoiva prosessi jatkuva prosessin parantaminen Kevät 2005 Ohjelmistotuotanto / Taina 27 CMM:n painopistealueet Kuhunkin tasoon liittyy joukko keskeisiä parannuskohtia (key process areas). Prosessin parantaminen ei voi tapahtua missä järjestyksessä hyvänsä. Tietyt asiat täytyy saada kuntoon ennen kuin voi/kannattaa edetä kovin pitkälle muilla osa-alueilla. CMM sisältää konreettisia parannustoimenpiteitä (key practices). Kevät 2005 Ohjelmistotuotanto / Taina 28 Taina 14
Kypsyystason arviointi Tavoitteena on yrityksen (organisaation) kypsyyden arviointi. Yksittäiset projektit voivat olla tasoltaan paljon korkeammalla kuin yrityksen yleinen taso. Arvioinnin tekee ulkopuolinen ryhmä käyttämällä kyselylomakkeita ja kyselyjä täydentäviä haastatteluja. Tuloksena saadaan arviointi ja loppuraportti. Kevät 2005 Ohjelmistotuotanto / Taina 29 Kypsyystasomallin käyttö Kypsyystason arvioinnin tavoitteena on saada puolueeton kuva yrityksen kokonaistasosta ja selvittää tärkeimmät korjattavat kohdat. Yritystä ei voi kuvata yhdellä numerolla. Osa-alueisiin liittyvä tieto on prosessin parantamisen kannalta olennaista. Malli sopii parhaiten suuriin organisaatioihin ja pitkiin projekteihin. Kevät 2005 Ohjelmistotuotanto / Taina 30 Taina 15