Software Embedded Il Tasso Di Difetto

Question

Che cosa il tasso di difetto posso aspettarmi in C++ il codice che è stato scritto per un embedded processor (DSP), dato che non ci sono stati test di unità, non di revisioni del codice, non di analisi statica del codice, e che la compilazione del progetto genera circa 1500 avvertenze.5 difetti/100 righe di codice una stima ragionevole?

Answer 1

Nonostante il mio scetticismo la validità di ogni stima in questo caso, ho trovato alcune statistiche che possono essere rilevanti.

In questo articolo, l'autore cita cifre da "un grande corpo di studi empirici", pubblicato nel Valutazioni del Software, Benchmark e Best Practices (Jones, 2000).A SIE CMM Livello 1, che suona come il livello di questo codice, si può prevedere un tasso di difetto di 0,75 per la funzione di punto di.Lascio a voi decidere come la funzione di punti di e LOC possono riguardare in codice - avrete probabilmente bisogno di un strumento metriche per eseguire l'analisi.

Steve McConnell in Codice Completo cita uno studio di 11 progetti sviluppati dallo stesso team, 5 senza codice, recensioni, 6 con le revisioni del codice.Il tasso di difetto per non rivedendo il codice è stato del 4,5 per 100 LOC, e per la rivista era 0,82.Quindi, su questa base, la tua stima mi sembra giusto, in assenza di altre informazioni.Tuttavia devo assumere un livello di professionalità tra questa squadra (solo dal fatto che hanno sentito il bisogno di eseguire lo studio), e che avrebbero almeno hanno partecipato all'avviso;il tasso di difetto potrebbe essere molto più alto.

Il punto sugli avvisi è che alcuni sono benigni, e alcuni sono errori (es.comporterà comportamento indesiderato del software), se li ignoriamo sul presupposto che essi sono tutti benigna, di introdurre errori.Inoltre alcuni diventare errori in manutenzione quando altre condizioni cambiano, ma se hai già scelto di accettare un avvertimento, non hanno alcuna difesa contro l'introduzione di tali errori.

Answer 2

La tua domanda è "è di 5 difetti / 100 righe di codice una stima ragionevole?" Tale questione è estremamente difficile rispondere, ed è fortemente dipendente dalla base di codice e la complessità del codice.

È anche menzionato in un commento "per mostrare la direzione che probabilmente ci sono un sacco di bug nel codice di base" -. E 'fantastico, complimenti, proprio sul

Al fine di occhi figurativi di gestione aperta, io suggerirei almeno un approccio 3 fronti:

• prendere specifici avvisi del compilatore, e mostrare come alcuni di essi possono causare undefined comportamento / disastroso. Non tutti gli avvisi saranno come pesante. Per esempio, se avete qualcuno che utilizza un puntatore non inizializzato, questo è oro puro. Se avete qualcuno ripieno un valore senza segno a 16 bit in un valore senza segno a 8 bit, e si può dimostrare che il valore a 16 bit sarà sempre <= 255, che non si è intenzione di contribuire a rendere il vostro caso come fortemente.
• Esegui uno strumento di analisi statica. PC-Lint (o FlexeLint) è a buon mercato e fornisce una buona "bang for the buck". Sarà quasi certamente prendere roba il compilatore non, e può anche funzionare attraverso unità di traduzione (lint tutto insieme, anche con 2 o più passaggi) e trovare i bug più sottili. Anche in questo caso, utilizzare alcuni di questi come indicazioni.
• eseguire uno strumento che darà altre metriche della complessità del codice, un'altra fonte di bug. Vi consiglio Resource standard metriche di M Squared (RSM) che sarà darvi maggiori informazioni e metriche (tra cui la complessità del codice) di quanto si potesse sperare. Quando dite di gestione che un punteggio di complessità oltre il 50 è "fondamentalmente non verificabile" e si dispone di un punteggio di 200 in una di routine, che dovrebbe aprire alcuni occhi.

Un altro punto: Ho bisogno di compilazioni pulite nei miei gruppi e uscita Lint pulito. Di solito questo può ottenuto esclusivamente da scrivere codice buono, ma a volte gli avvertimenti del compilatore / lint ha bisogno di essere ottimizzato per calmare lo strumento per le cose che non sono problemi (uso giudizio).

Ma il punto importante che voglio fare è questo: essere molto attenti quando si va in & fissaggio del compilatore e lint avvertenze . E 'un obiettivo ammirevole, ma si può anche inavvertitamente rompere il codice di lavoro e / o di uncover comportamento indefinito che accidentalmente ha lavorato nel codice "rotto". Sì, davvero accade. Quindi procedere con cautela.

Infine, se si dispone di un solido set di test già in atto, che vi aiuterà a determinare se si rompe qualcosa mentre il refactoring.

In bocca al lupo!

Answer 3

Date un'occhiata alla qualità del codice. Sarebbe rapidamente dare un'indicazione della quantità di problemi che si nascondono nella fonte. Se l'origine è brutto e richiedere molto tempo per capire che ci saranno un sacco di bug nel codice.

codice ben strutturato con stile coerente e che è facile da capire stanno per contenere meno problemi. mostra il codice quanta fatica e il pensiero è andato in esso.

La mia ipotesi è che se l'origine contiene molti avvertimenti che ci sta per essere un sacco di insetti che si nascondono nel codice.

Answer 4

Questo dipende anche da chi ha scritto il codice (livello di esperienza), e quanto grande sia il codice di base è.

I tratterebbe tutti gli avvisi come errori.

Quanti errori si ottiene quando si esegue uno strumento di analisi statica del codice?

Modifica

Esegui cccc e controllare la complessità ciclica del McCabe. Si dovrebbe dire quanto sia complesso il codice di esso.

http://sourceforge.net/projects/cccc/

Run altri strumenti di analisi statica.

Answer 5

Se si desidera ottenere una stima del numero di difetti, il solito modo di estimatation statistiche è quello di sottocampionare i dati. Vorrei prendere subroutine tre di medie dimensioni in modo casuale, e controllare attentamente per insetti (eliminare gli avvisi del compilatore, eseguire lo strumento di analisi statica, ecc). Se trovate tre bug in 100 linee totali di codice selezionato a caso, sembra ragionevole che una densità simile di bug sono nel resto del codice.

Il problema menzionato qui di introdurre nuovi bug è una questione importante, ma non è necessario per controllare il retro codice modificato nel ramo di produzione per eseguire questo test. Vorrei suggerire una serie completa di test di unità prima di modificare qualsiasi subroutine, e ripulire tutto il codice seguita da test sistema molto spinto prima di rilasciare nuovo codice di produzione.

Answer 6

Se si vuole dimostrare i benefici di test di unità, le revisioni del codice, strumenti di analisi statica, io suggerisco di fare uno studio pilota.

Fare alcuni test di unità, le revisioni del codice, ed eseguire strumenti di analisi statica su una porzione del codice. Mostra gestione quanti bug a trovare con questi metodi. Si spera, i risultati parlano da soli.

Answer 7

L'articolo richiesto è qualche numero sulla base di progetti di vita reale a cui l'analisi statica è stata applicata a: http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html

Naturalmente i criteri con cui un'anomalia viene contato possono influenzare il risultato drammaticamente, portando alla grande variazione nei dati riportati nella tabella 1. In questa tabella, il numero di anomalie per mille linee di codice per C varia da 500 (!) a circa 10 (auto generato).