Classificazione dei difetti ortogonali
Orthogonal Defect Classification (ODC) è un modello per la classificazione degli errori nello sviluppo del software sviluppato presso IBM . Classificando gli errori in base a determinate categorie e attributi, è possibile mostrare le connessioni tra il processo di sviluppo e la causa degli errori. Sulla base delle conoscenze acquisite, è possibile derivare misure per migliorare il processo di sviluppo.
concetto
L'ODC appartiene alla classe dell'analisi della causa principale ( analisi della causa principale ) ed è una tecnica del campo dell'ingegneria del software . Contrariamente alla classica analisi delle cause, i singoli errori non vengono analizzati in dettaglio e richiedono tempo, ma vengono classificati semanticamente utilizzando categorie predefinite.
Classificazione dei guasti
Con la classificazione dell'errore con ODC, l'errore viene classificato due volte - quando l'errore viene rilevato secondo i criteri della cosiddetta " sezione di apertura "; dopo la riparazione poi di nuovo dopo quelle della " Sezione più vicina ". Nella sezione di apertura , l'attenzione è sulle circostanze che hanno portato alla cattiva condotta, quindi queste possono essere riprodotte anche in seguito. La causa che ha portato all'errore è determinata nella sezione più vicina . La sezione di apertura offre tre categorie, la sezione più vicina cinque.
Sezione Opener
La sezione opener è composta dalle seguenti categorie:
- Attività : quando è stato trovato un bug? Questo non significa la data, ma il momento all'interno del processo di sviluppo o del ciclo di vita del prodotto.
- Esempio: revisione della progettazione o del codice, test di moduli, componenti o sistemi.
- Trigger : come è stato rilevato l'errore? Il trigger non deve essere confuso con il sintomo, ovvero l'effetto di un errore o il malfunzionamento di un programma.
- Esempio: un errore in un ciclo di conteggio causa la visualizzazione di un valore errato sull'interfaccia utente. Il sintomo è il valore errato visualizzato. In questo caso, il trigger potrebbe essere stato un test del valore limite. Il fattore scatenante è, per così dire, il "catalizzatore" che trasforma un errore in un malfunzionamento.
- Impatto : quali effetti ci sarebbero per il cliente o cosa sarebbe potuto accadere se l'errore fosse stato scoperto solo presso la sede del cliente in relazione alla ISO 9126 ?
Sezione più vicina
La sezione più vicina è composta dalle seguenti categorie:
- Obiettivo : quale oggetto è stato migliorato in modo da poter correggere il bug?
- Tipo di difetto : cosa doveva essere migliorato esattamente per correggere l'errore?
- Esempio: assegnazione , interfaccia , algoritmo
- Qualificatore : specifica se un errore è stato corretto a causa di: codice sorgente mancante, errato o ridondante .
- Età : specifica se l'errore si è verificato in un ramo di codice nuovo, di base, riscritto ( codice refactoring ) o corretto da errori.
- Origine : specifica se l'errore all'interno del codice sorgente proviene da sviluppo interno, riutilizzo, porting o da un provider di terze parti.
Possibilità di valutazioni con ODC
La classificazione dei difetti ortogonali come rappresentante delle metriche del software è adatta per la sua classificazione dei dati di errore per poter creare valutazioni in merito al rispettivo processo di sviluppo del software sulla base di un database ODC . Il concetto ODC fornisce un totale di due metodi con cui è possibile analizzare e valutare l'affidabilità e la qualità di un processo di test e sviluppo per il software:
- Root Cause Analysis (RCA) e
- Modellazione statistica dei difetti (SDM).
Analisi della causa principale
Come già accennato all'inizio, l'RCA appartiene al sottogruppo dell'analisi delle cause profonde degli errori nell'ingegneria del software . L'ODC-RCA è caratterizzato dal fatto che, rispetto ad altri metodi di analisi della causa principale, non solo può essere eseguito in modo molto più efficiente o più veloce, ma anche più preciso. Ciò è dovuto alla strutturazione del rispettivo errore software sotto forma di attributi ODC per la sezione di apertura e chiusura. Durante l'implementazione pratica di un ODC-RCA, i valori per gli attributi ODC dell'apri e del chiudiporta vengono analizzati e valutati. Osservando i valori ODC e gli attributi ODC collegati, l'operatore RCA può localizzare e determinare una potenziale causa di errore in modo più preciso. Nonostante il miglioramento delle prestazioni attraverso l'ODC-RCA, la procedura generale dell'RCA può essere classificata come relativamente complessa e richiede tempo. Per questo motivo, un RCA (ODC) dovrebbe, se possibile, essere eseguito da uno sviluppatore di software esperto e principalmente per errori software con priorità più alta o rilevanti .
Modellazione statistica dei difetti
Contrariamente all'ODC-RCA, in cui viene esaminato più da vicino un solo errore software, l'SDM include un intero set di dati ODC nella valutazione. In SDM, gli errori del software vengono analizzati automaticamente nella loro forma ODC strutturata, combinando tra loro gli attributi ODC dell'apertura e delle sezioni più vicine o con altri determinanti, come: B. periodo di sviluppo, componenti del prodotto, progetti, ecc. Possono essere messi in relazione. I risultati di queste valutazioni non forniscono informazioni sull'origine di un singolo errore software come l'ODC-RCA , ma piuttosto rappresentano graficamente lo stato attuale del processo di sviluppo in termini di affidabilità e qualità delle rispettive fasi di test e sviluppo.
I diagrammi oi cosiddetti alberi di inferenza vengono utilizzati per rappresentare la valutazione dei dati ODC nell'ambito dell'SDM . A causa della forma strutturata del database ODC, questi grafici e alberi di inferenza possono essere generati e valutati automaticamente.
Difficoltà nell'utilizzo di ODC
Poiché la classificazione dell'errore con ODC è un processo svolto dall'uomo, c'è il rischio che la classificazione di un errore porti a differenze dovute a diverse percezioni soggettive. Ciò può essere positivamente influenzato da un adattamento mirato degli attributi alle rispettive circostanze nello sviluppo per le singole categorie nella sezione di apertura e chiusura . Pertanto, i singoli attributi di una categoria dovrebbero essere ortogonali tra loro in modo da mantenere piccolo lo spazio per ogni possibile interpretazione da parte dell'individuo.
Guarda anche
Prove individuali
- ↑ a b Ram Chillarege et al.: Classificazione dei difetti ortogonali - Un concetto per le misurazioni in-process. In: Transazioni IEEE sull'ingegneria del software. N. 18, 1992, pagg. 943-956
- ↑ Ram Chillarege: ODC - un 10x per l'analisi delle cause alla radice. 2006
- ↑ un b archiviati copia ( ricordo del l' originale datata 6 dicembre 2013 in Internet Archive ) Info: Il dell'archivio collegamento è stato inserito automaticamente e non è stata ancora verificata. Controllare l'originale e il collegamento all'archivio secondo le istruzioni, quindi rimuovere questo avviso.
- ↑ archiviati copia ( Memento del l' originale del 6 dicembre 2013, l'Internet Archive ) Info: Il dell'archivio collegamento è stato inserito automaticamente e non ancora verificata. Controllare l'originale e il collegamento all'archivio secondo le istruzioni, quindi rimuovere questo avviso.
- ↑ archiviati copia ( Memento del l' originale del 6 dicembre 2013, l'Internet Archive ) Info: Il dell'archivio collegamento è stato inserito automaticamente e non ancora verificata. Controllare l'originale e il collegamento all'archivio secondo le istruzioni, quindi rimuovere questo avviso.
letteratura
- Ram Chillarege et al.: Classificazione dei difetti ortogonali - Un concetto per le misurazioni in-process . In: Transazioni IEEE sull'ingegneria del software . No. 18 , 1992, pag. 943-956 ( Articolo ).
- Ram Chillarege: ODC - un 10x per l'analisi delle cause alla radice . 2006 ( file PDF ).
- Pankaj Jalote et al.: Utilizzo del feedback dell'analisi dei difetti per migliorare la qualità e la produttività nello sviluppo iterativo del software . In: Atti della scienza dell'informazione e della tecnologia delle comunicazioni (ICICT 2005) . 2005, p. 701-713 ( file PDF ).
- M. Butcher et al .: Migliorare i test del software tramite ODC: tre casi di studio . In: IBM System Journal . No. 41 , 2002 ( articolo ).
