1 / 20

ODC

ODC. Ortogonaalinen virheluokittelu. Mikä ODC on?. IBM:llä kehitetty virheluokittelumenetelmä (Ram Chillarege et al. 1991) V irheiden luokittelun avulla pyritään selittämään erilaisia syy-seuraussuhteita sovelluskehitysprosessissa ja sovelluksen laadussa

farica
Download Presentation

ODC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related