Laadunvarmistuksesta. Luennon tavoitteista. Motivointia. Sommerville, Software Engineering (6th ed.)

Transkriptio

1 Laadunvarmistuksesta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Sommerville, Software Engineering (6th ed.) 1

2 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata: ymmärtää laadunhallintaprosessin perusteita ymmärtää standardien merkitys laadunhallinnassa ymmärtää metriikkojen käytön perusteita 2

3 Sisällöstä Tavoitekalvon asioita. laadunvalvonnasta ja standardeista laatusuunnitelmien tekemisestä laadun kontrolloinnista ohjelmiston mittaamisesta ja metriikoista 3

4 Motivointia Useimpien organisaatioiden tavoitteena on tuottaa korkean laatutason tuotteita ja palveluja. Ohjelmiston laatu ei käsitteenä ole mitenkään selvä. Standardeja käytetään useissa organisaatioissa. 4

5 Laadunvalvonnan vaikeudesta Määrittelyjen tulisi olla asiakkaan toiveiden mukaisia. Kuitenkin kehitysorganisaatio saattaa asettaa omia tavoitteitaan (esim. ylläpidettävyyden suhteen), joita ei aina näy määrittelyissä. Kaikkia määrittelyjä ei voida esittää yksiselitteisesti (esim. ylläpidettävyys). Määrittelyjä on vaikea kirjoittaa oikein mutkikkaalle ohjelmistolle: toiminta saattaa vastata määrittelyjä mutta ei käyttäjien toiveita. 5

6 Ylläpidettävyys, siirrettävyys ja tehokkuus voivat olla kriittisiä laatuominaisuuksia, joita ei aina (voida) määritellä riittävän tarkasti ja jotka kuitenkin vaikuttavat laatuun. 6

7 Laadunvalvonnan tehtäviä määrittää organisaation/projektin toimintoja ja standardeja tarkastaa, että kaikki noudattavat noita määrittelyjä rohkaista ammattimaista otetta ryhmissä, kaikkea laatuun liittyviä asioita ei voi mitata (eleganssi, luettavuus jne). 7

8 Kolme päätehtävää: Laadun varmistus. Organisaatiossa laadukkaaseen ohjelmistoihin johtavien toimintojen ja standardien kehyksen perustaminen. Laadun suunnittelu. Sopivien toimintojen ja standardien valinta kehyksestä kullekin projektille. Laadun seuranta ja kontrollointi. Niiden prosessien määrittely ja käyttö, joiden avulla varmistutaan, että valittuja laatutoimintoja ja -standardeja noudatetaan. 8

9 Riippumattomuus kehitysprosessista Laadunhallinta on ohjelmiston kehitysprosessiin nähden riippumatonta tarkastustoimintaa! Tarkoitus saada prosesseista riippumaton, objektiivinen kuva. Laadunhallintaryhmän tulisi raportoida ongelmista ja vaikeuksista johdolle (yli projektipäällikkötason). tulisi olla erillinen organisaation projektiryhmiin nähden. 9

10 Standardeista ISO Kansainvälinen standardi, soveltuu monelle teollisuuden alalle. ISO 9001 on laajin ISO standardeista organisaatioille, joissa on tuotteiden suunnittelua, kehitystä ja ylläpitoa. ISO sisältää tulkinnan ohjelmistotuotannolle. 10

11 ISO On geneerinen laatuprosessien malli. Organisaation laatuprosessit tulisi olla määriteltyinä ja dokumentoituna asianmukaisesti organisaation laatukäsikirjassa. On erilaisia laatusysteemejä, joita voi soveltaa erilaisiin hallinnollisiin vastuihin. Standardeja on muitakin: IEEE, ANSI, NATO, BSI, US DoD, kansainvälisiä ja kansallisia 11

12 Laadunvarmistuksesta ja laatustandardeista Tarjotaan kehys, jonka puitteissa tavoitellaan laatua. Tuotestandardeja. Sisältää asiaa mm. dokumenteista ja koodin dokumentoinnista. Prosessistandardeja. Noudatettavien prosessien kuvaukset. Standardit ovat tärkeitä: Kertovat hyvistä ja toimivaksi havaituista käytännöistä. Antavat kehyksen, jonka ympärille laadunvarmistusprosessi rakentuu. Varmistavat jatkuvuutta: henkilöriskit pienempiä. 12

13 Tuotestandardeja Suunnitelmien katselmointilomake Vaatimusmäärittelydokumentin rakenne Ohjelmointikielen tyyliopas Projektisuunnitelman formaatti Muutospyyntölomake... 13

14 Prosessistandardeja Suunnitelmien katselmointien pitäminen. Dokumenttien lähettäminen tuotehallintaan (versionhallintajärjestelmään). Version julkistamisprosessi. Projektisuunnitelman hyväksymisprosessi. Muutosten hallintaprosessi

15 Byrokraattisia, turhaa työtä? Ohjelmistosuunnittelijoiden tulisi osallistua myös standardien kehittämiseen. Motivaatiot standardien käytölle tulevat paremmin tällöin näkyville. Standardien tulisi myös perustella, miksi niitä käytetään. Katselmoi ja muokkaa standardeja vastaamaan muuttuvia teknologioita ja työskentelyolosuhteita. Työkaluja tukemaan standardien käsittelyä, jotta rutiinien kuormaa saisi pienennettyä. Harkinnan käytön sallimista suositellaan: järjettömia ohjeistuksia ei kannata noudattaa poisjättämisiä tulee kuitenkin harkita tarkkaan. 15

16 Dokumentointistandardit Dokumentointiprosessistandardit. Kuinka dokumentteja tuotetaan? Dokumenttistandardit. Esimerkkejä: Dokumenttien identifiointistandardi Dokumenttien rakennestandardi Dokumenttien esitysstandardi Dokumenttien päivitysstandardi. Dokumenttien vaihto(välitys)standardit. Esim. että dokumenttien elektroniset versiot yhteensopivia. 16

17 Prosessin laatu Prosessin laatu vaikuttaa ohjelmiston laatuun. Prosessin laadunhallinta sisältää: Prosessistandardien määrittelyn. Esim. kuinka ja milloin katselmoinnit pidetään. Kehittämisprosessin tarkkailun sen varmistamiseksi, että standardeja noudatetaan. Ohjelmistoprosessin raportoinnista projektipäällikölle ja ohjelmiston ostajalle. Prosessipohjaisessa laadunvalvonta ei aina toimi, esim. standardi voi vaatia tiettyjä toimia, kun tarvittaisiin prototyyppejä. Tällöin johdon pitäisi varmistaa, että laatuprosessit tukevat ennemmin kuin haittaavat tuotekehitystä. 17

18 Laatusuunnitelmat Johdatus tuotteeseen Tuotesuunnitelmat Prosessien kuvaukset Laatutavoitteet Riskit ja riskien hallinta 18

19 Laadun kontrollointi Tarkastetaan tuotoksia määriteltyjä laatustandardeja vasten. Laatukatselmoinnit. Joukko ihmisiä katselmoi tuotoksia. Tarkistetaan, että standardeja noudatetaan ja että dokumentit noudattavat standardeja. Poikkeamista tiedotetaan. (Näistä omat kalvot.) Automaattiset ohjelmiston arvioimiset. (Ks. mittaamisesta ja metriikoista seuraavilla kalvoilla.) 19

20 Ohjelmiston mittaaminen ja metriikat Haetaan numeerinen arvo jollekin ohjelmistotuotteen tai -prosessin ominaisuudelle. motivointia mittausprosessi tuotemetriikat mittausten analysointi 20

21 Motivointia Johto voi käyttää: eri osastojen tai ryhmien laadukkuuden (tehokkuuden ym) vertailuun. tuotteiden ja prosessien vertailuun. osana prosessien parannustoimenpiteitä. Hyötyjä ei aina tunneta ja jotkut pitävät (tätäkin toimintaa) akateemisena puuhasteluna. 21

22 Esimerkkejä Tuotteen koko koodiriveinä. Kirjoitetun tekstiosuuden luettavuus (Fog indeksi). Toimitetun tuotteen virheiden ja bugien määrä. Komponentin kehitykseen tarvittu henkilötyömäärä. 22

23 Tyyppejä Metriikat voivat olla: Kontrollimetriikoita (prosessi-) korjauksien vaatima km. työmäärä Ennustemetriikoita (liittyvät yleensä tuotteeseen) Syklomaattinen kompleksisuus Muuttujien km. pituus koodissa Objektien sisältämien muuttujien ja metodien km. lukumäärät 23

24 Tiettyjä ominaisuuksia voi mitata suoraan. Ylläpidettävyys, kompleksisuus, ymmärrettävyys riippuvat monesta tekijästä ja niitä ei voi mitata suoraan (ovat ulkoisia ominaisuuksia). Noille johdetaan arvot muita, helpommin mitattavia tekijöitä ja ominaisuuksia käyttäen (näitä kutsutaan sisäisiksi ominaisuuksiksi). Yksi ulkoinen ominaisuus voi riippua useasta sisäisestä ominaisuudesta. Riippuvuussuhteiden kunnollinen selvittäminen vaatii jatkuvaa mallikehitystä, historiadatan jatkuvaa keruuta, tilastomenetelmien hyvää osaamista. 24

25 Mittausprosessi Valitse mittaustavat. Mihin halutaan vastauksia? GQM (Goal-Question-Metric) paradigma. Valitse arvioitavat komponentit. Kaikkia systeemin komponentteja ei ehkä tarvitse tai kannata mitata (arvioida). Kriittiset ja edustusjoukko. Mittaa komponenttien ominaisuudet. (Automaattisesti kerätään dataa.) 25

26 Havannoi poikkeavat arvot. Verrataan komponentteja toisiinsa. Verrataan vanhoihin arvoihin. Analysoi poikkeavat komponentit. Tarkoittaako poikkeava arvo heikentynyttä laatua? Kerättyä dataa tulee säilyttää. Dataa tulisi kerätä myös projekteista, joissa sitä ei hyödynnetä suoraan. 26

27 GQM Tavoitteet. Mitä halutaan saada aikaan? Organisaation tavoitteet? Kysymykset. Kuinka saadaan aikaan...? Tavoitteiden hienonnuksia. Yleensä tavoitteeseen liittyy kysymyksiä. Metriikat. Näiden avulla vastataan kysymyksiin. Kertovat, onko tavoitteisiin päästy. Tämän lähestyminen erottaa organisaatioon liittyvät (tavoitteet) asiat prosesseihin liittyvistä (kysymykset). 27

28 Tuotemetriikat Liittyvät suoraan ohjelmiin. Helposti mitattavilla ominaisuuksilla epäsuorat yhteydet laatuominaisuuksiin. Dynaamiset mitat, joita kerätään ohjelman toiminnasta. tehokkuus luotettavuus suoritusajat tietyille funktioille systeemin käynnistymisaika systeemin kaatumisten määrä tietyn ajan sisällä kohtuu suora yhteys laatuominaisuuksiin 28

29 Staattiset mitat, joita kerätään systeemin eri esityksistä (suunnitelmista, koodista, dokumentaatiosta). helposti (automaattisesti) kerättävissä löytyy useita Komponentin pituus ja kontrollin mutkikkuus -mittarit luotettavimpia ennustajia ymmärrettävyydelle, systeemin mutkikkuudelle ja ylläpidettävyydelle. 29

30 Esimerkkejä metriikoista Fan-in/Fan-out Koodin pituus Syklom. kompl. Funktiota x kutsuvien funktioiden lkm per funktion x kutsumien funktioiden lkm. Iso F-i tarkoittaa tiukkaa kytkentää muuhun rakenteeseen ja iso F-o mutkikasta kontrollilogiikkaa. Pituuden kasvaessa mutkikkuus ja virhealttius kasvaa. Ohjelman kontrollikompleksisuus. 30

31 Muuttujien km. pituus Ehtolauseiden sisäkkäisyys Pidempien muuttujanimien toivotaan olevan kuvaavia. Usean sisäkkäisen if-lauseen toimintaa vaikea ymmärtää. Fog indeksi Km. sanojen ja lauseiden pituus dokumenteissa. Iso luku voi kieliä vaikeasti ymmärrettävästä dokumentista. 31

32 Esimerkkejä olisuuntautuneista metriikoista Perintäpuiden korkeus Metodien Fanin / Fan-out Luokan pain. metodien lkm. Ylilataamisen määrä Korkeus tarkoittaa usein mutkikkuutta. Ed. kalvon lisäksi luokan sisäiset ja ulkopuoliset. Yks.kert. metodien paino yksi, muilla enemmän. Painavat luokat usein mutkikkaita. Jos iso, onko yliluokka ok kyseisille aliluokille? 32

33 Mittausten analysointi Kvantitatiivista dataa, jota on helppo tulkita väärin. Muutuspyyntöjen lukumäärä esimerkki: Seurataan tuota lukua ja pyritään saamaan sitä pienemmäksi. Tuloksena, että joltain osin pienenee ja joltain ei. Pitäisi kuitenkin ymmärtää, mistä syystä asiakkaat lähettävät muutospyyntöjä, jotka voivat olla merkki sekä hyvästä että huonosta laadusta. Pitää tietää, kuka teki, kuinka käyttävät ohjelmistoa, miksi tekivät, onko markkinoilla tapahtunut muutoksia. Siis, yksioikoinen johtopäätösten tekeminen vaarallista, tulkintaan liittyy epävarmuustekijöitä. 33