ODC

1. ODC Ortogonaalinen virheluokittelu

2. Mikä ODC on? • IBM:llä kehitetty virheluokittelumenetelmä (Ram Chillarege et al. 1991) • Virheiden luokittelun avulla pyritään selittämään erilaisia syy-seuraussuhteita sovelluskehitysprosessissa ja sovelluksen laadussa • Välitön palaute mahdollistaa reagoinnin ongelmatilanteisiin jo yksittäisen ohjelmistotuotantoprojektin kuluessa, mikä on selkeä etu erilaisiin projektin jälkeen palautetta antaviin mittareihin • Ortogonaalinen; toisistaan riippumattomat, hyvin erotellut.

3. Mikä ODC on? • Yksinkertaisella virheiden luokittelulla oli mahdollista saada tietoa kehitysprosessin ongelmista jo ohjelman kehitysvaiheessa [Chillarege et al. 1991] • Edellytyksenä virheiden luokittelujärjestelmä, jolla erilaiset virheluokat suhteutetaan sovelluksen kehitysprosessiin ja seurataan sovelluksen edistymistä prosessin läpi.

4. ODC pähkinänkuoressa • Perusajatuksena on, että yksittäiseen virheeseen liitetään erilaisia ominaisuuksia • ominaisuudet ortogonaalisia • Ominaisuuksien kollektiivisen jakauman perusteella voidaan tehdä päätelmiä • tuotteen kypsyydestä prosessin eri vaiheissa, • kypsyyden muutoksista sekä • prosessin eri vaiheiden toimivuudesta tuotteen kypsyyden lisääjänä. • Varsinaisena mittarina toimii siis virheen ominaisuuksien jakaumassa tapahtunut muutos, joka kertoo kehityssuunnan. • ODC pyrkii tarjoamaan prosessin sisäisen mittarin, jonka avulla virheistä saadaan avaintiedot ja voidaan mitata erilaisia syy-seuraussuhteita [Chillarege 1994].

5. ODC versio 5.1 • Erilaisia virheen ominaisuuksia on kahdeksan. • Tunnistettavissa heti virheen löydyttyä: • Aktiviteetti • Laukaisin • Asiakasvaikutus • Korjauksen yhteydessä • Kohde • Virhetyyppi • Laatu • Lähde • Historia

6. Aktiviteetit ja laukaisimet [Bassin et al. 1998]

7. Muita ominaisuuksia [Bassin et al. 1998]

8. Aktiviteetti • Aktiviteetti viittaa siihen todelliseen ohjelmakehityksen vaiheeseen, jossa virhe havaittiin. • Jakamalla prosessi vaiheisiin, aktiviteetteihin, luokittelusta saadaan sovellettavasta prosessimallista riippumaton. • Geneerinen aktiviteettilista voisi sisältää esimerkiksi seuraavat aktiviteetit: arkkitehtuurin katselmointi, koodikatselmointi, yksikkötestaus, toiminnallinen testaus ja järjestelmätestaus [Bassin et al. 1998] • Toiminnallinen testaus [Chillarege 1995] sisältää paitsi yksikkötestauksen, myös rajapintojen toiminnallisuuden varmistamisen. • Kunkin organisaation tulee muokata aktiviteettilista oman todentamisprosessinsa ja sen osa-alueiden perusteella parhaiten vastaamaan omia tarpeitaan.

9. Virhetyyppi (1/2) • Virheen tyyppi -ominaisuus kuvaa virheen luonnetta ja sen korjaustoimien vaikutusaluetta • Luokkien ortogonaalisuudella vähennetään luokitteluissa ilmenevää inhimillistä subjektiivisuutta ja virhemahdollisuutta tarjoamalla käyttöön virheluokat, jotka ovat selkeästi toisistaan erottuvia ja samalla toisensa poissulkevia, kattaen kuitenkin kaikki luokittelussa tarvittavat vaihtoehdot • Tarkoituksellisen yksinkertaisia ja niitä on pieni joukko, jotta valinta niiden välillä on helppoa.

10. Virhetyyppi (2/2) • Pilotoinnin jälkeen kahdeksan erillistä virhetyyppiä [Chillarege et al. 1991]: • toiminnallinen virhe (function error), • sijoitus- (assignment error), • rajapinta- (interface error), • tarkistusvirhe (checking error), • ajoitus/sarjallistamisvirheet (timing/serialization error), • käännös/pakkaus/liitosvirhe (build/package/merge error), • dokumentointivirhe (documentation error) ja • algoritmivirhe (algorithm error). • Virhetyypeistä on pyritty tekemään mahdollisimman yleiskäyttöisiä, jotta ne soveltuisivat käytettäväksi kaiken tyyppisissä ohjelmakehitysprosesseissa tuotteesta riippumatta • Sittemmin virhetyypeistä dokumentointi on siirretty Asiakasvaikutukset-ominaisuuden joukkoon ja olio-ohjelmien myötä virheluokkia on täsmennetty (kts. versio 5.1)

11. Virhetyyppien käyttö • Kussakin ohjelmakehityksen vaiheessa löydetyt virheet tyypitetään ja kunkin tyypin suhteellinen osuus kaikista kyseisessä vaiheessa löydetyistä virheistä lasketaan. • Näin muodostuu kyseisen vaiheen virhetyyppien jakauma (virheprofiili, defect type signature), joka indikoi tuotteen vakautta suhteessa sen etenemiseen sovelluskehitysprosessissa • Löydettyjen virheiden jakauman tulisi kussakin kehitysprosessin vaiheessa olla kyseiselle vaiheelle tyypillinen ja noudattaa tiettyä trendiä prosessin edistyessä. • Yksittäisessä projektissa ilmenevät poikkeamat vaiheen tavanomaisesta virhejakaumasta osoittavat mahdollisia ongelmakohtia projektin kulussa.

12. Virhetyyppien jakauma eri vaiheissa [Chillarege 1992]

13. Virhetyypit ja tyypillisimmät syntyvaiheet [Chillarege et al. 1992]

14. Virhetyyppien löytymisen sormenjälki • Eri virhetyyppien tulisi myös löytyä prosessin eri vaiheissa. • Esimerkiksi järjestelmätestausvaiheessa löytyy paljon toiminnallisia virheitä, joiden tulisi normaalissa kehitysprosessissa suurimmalta osaltaan löytyä jo arkkitehtuurin katselmoinnissa,  arkkitehtuurin katselmoinnissa ei jostakin syystä kyseisen projektin osalta ole päästy tavoitteisiin.

15. Eri virhetyyppien tavanomaisimmat synty- ja löytöpaikat [Chillarege et al. 1992]

16. Laukaisin • Laukaisin on tekijä tai olosuhde, jonka seurauksena virheellinen ohjelman osa suoritetaan ja virhe ilmenee. • Myös laukaisinten jakauma muuttuu ohjelmistotuotantoprosessin aikana ja tarjoaa menetelmän arvioida sovelluksen verifiointiprosessia. • Laukaisinten arvojoukon kokeellinentodentaminen kyseisen ohjelmistotuotantoprosessin tarpeisiin vie aikaa. • Kun arvojoukko on selvillä ja kalibroitu kyseiseen prosessiin, on erilaisten jakauma- ja tulostietojen tuottaminen varsin yksinkertaista. • Toisin kuin virhetyypit, joiden luokat säilyvät samoina koko tuotteen elinkaaren ajan, laukaisimet ovat erilaisia ohjelmistotuotantoprosessin eri vaiheissa. • Yhteistä kaikille laukaisimille kuitenkin on, että ne yrittävät emuloida asiakkaan suorittamaa ohjelman käyttöä kyseiselle verifiointivaiheelle ominaisella tavalla. • Tietoa laukaisinten jakaumasta prosessin eri vaiheissa voidaan käyttää hyväksi testaus- ja muiden verifiointiresurssien oikeassa keskittämisessä.

17. DB2 tuotantokäytön laukaisinjakauma (3 vuotta)

18. Kerätyn aineiston oikeellisuus • Aineiston oikeellisuuden varmistaminen on erityisen tärkeää luokittelun alussa • Luokittelun suorittajilla voi vielä olla epävarmuutta peruskäsitteistä ja luokkien käytöstä. • Aineiston laatu ei yleensä enää myöhemmissä vaiheissa ole ongelma [Butcher et al. 2002]

19. DPP (Defect prevention Process) käsittelee syiden analysointia Neljä pääaktiviteettia (Mays 1990; Mays et al. 1990): Syiden pohtimispalaveri Toimintatiimi Vaiheittaiset aloitustilaisuudet Aineiston kerääminen ja analysointi Kulu tyypillisesti 1 henkilötyövuosi 150-200 kehityshenkilöstön jäsentä kohden perustuen IBM:n kokemuksiin DLDA (Defect Logging, Defect Analysis) PSP:n inspiroimana menetelmänä tehostaa oppimista PSP hyödyllinen mutta erittäin raskas Osajoukko PSP-käytäntöjä virheisiin pohjautuen on osoittautunut saavan aikaan vastaavia parannuksia kuin PSP kokonaisuutena (Prechelt 2001) Profiilien/sormenjäljien järjestelmällinen hyödyntäminen

20. Bassin, K.A., Kratschmer, T., Santhanam, P., Evaluating software development objectively. IEEE Software, 15, 6, (1998), 66-74. Butcher, M., Munro, H., Kratschmer, T., Improving software testing via ODC: three case studies. Software Testing and Verification, 41, 1, (2002). Chillarege, R., Kao, W.-L., Condit, G., Defect type and its impact on the growth curve. Proceedings of the 13th Conference of Software Engineering. 1991.http://www.chillarege.com/odc/articles/aixps2/aixps2.html Chillarege, R., Bhandari, I.S., Char J.K., Halliday, M.J., Moebus, D.S., Ray, B.K., Wong, M, Orthogonal Defect Classification-A Concept for In-Process Measurements. IEEE Transactions on Software Engineering, 18, 11, (1992), 943-956. Chillarege, R., ODC for process measurement, analysis and control. Proceedings of the 4th International Conference on Software Quality, 1994.http://www.chillarege.com/odc/articles/asqc/asqc.html Chillarege, R., Bassin, K.A., Software triggers as a function of time – ODC on field faults. Fifth IFIP Working Conference on Dependable Computing for Critical Applications, 1995.http://www.chillarege.com/odc/articles/trig/trig.html Sullivan, M., Chillarege, R., Software defects and their impact on system availability - a study of field failures in operating systems. Digest of Papers: The 21 st Int. Symp. Fault-Tolerant Computing, 1991 , 2-9. Lähteet