Quale frequenza di errori posso prevedere in una base di codice C++ scritta per un processore incorporato (DSP), dato che non sono stati effettuati test di unità, revisioni di codice, analisi del codice statico e che compila il il progetto genera circa 1500 avvisi. 5 difetti/100 linee di codice sono una stima ragionevole?Errore software incorporato
Nonostante il mio scetticismo sulla validità di qualsiasi stima in questo caso, ho trovato alcune statistiche che potrebbero essere rilevanti.
In this article, l'autore cita figure da un "grande corpo di studi empirici", pubblicato in Software Assessments, Benchmarks, and Best Practices (Jones, 2000). A SIE CMM Level 1, che suona come il livello di questo codice, ci si può aspettare un tasso di difetto di 0,75 per function point. Lo lascerò a te per determinare in che modo i punti funzionali e LOC possono essere correlati al tuo codice: probabilmente avrai bisogno di un metrics tool per eseguire tale analisi.
Steve McConnell nel codice Completa cites a study di 11 progetti sviluppati dallo stesso team, 5 senza recensioni di codice, 6 con recensioni di codice. Il tasso di difetto per il codice non revisionato era 4.5 per 100 LOC, e per la recensione era 0.82. Quindi su questa base, la tua stima sembra equa in assenza di altre informazioni. Comunque devo assumere un livello di professionalità tra questa squadra (solo dal fatto che sentivano la necessità di eseguire lo studio), e che avrebbero almeno assistito agli avvertimenti; il tuo tasso di difetto potrebbe essere molto più alto.
Il punto sugli avvertimenti è che alcuni sono benigni, e alcuni sono errori (cioè comporterà un comportamento indesiderato del software), se li ignori nell'assunzione che siano tutti benigni, introdurrai degli errori. Inoltre alcuni diventano errori in manutenzione quando cambiano altre condizioni, ma se hai già scelto di accettare un avviso, non hai difesa contro l'introduzione di tali errori.
Grazie mille per la risposta ben studiata. Devo ammettere che non avevo mai sentito parlare di punti funzione prima. – geschema
Ciò dipende anche da chi ha scritto il codice (livello di esperienza) e quanto grande è la base di codice.
Tratterei tutti gli avvisi come errori.
Quanti errori si ottengono quando si esegue uno strumento di analisi statico sul codice?
EDIT
Run cccc e controllare la complessità ciclica del McCabe. Dovrebbe dire quanto sia complesso il codice.
http://sourceforge.net/projects/cccc/
Run altri strumenti di analisi statica.
Non ho nemmeno provato a eseguire uno strumento di analisi statico sul codice base. Penso che dovremmo prima provare a far contare gli avvertimenti a zero. Questo sembra ragionevole? – geschema
@geschema Sì, fuori rotta. Secondo me, il codice dovrebbe essere compilato senza avvisi, poiché la maggior parte degli avvisi è valida. –
Inoltre, aggiungere quanti più test di unità possibile. –
Dai un'occhiata alla qualità del codice. Ti darebbe rapidamente un'indicazione della quantità di problemi nascosti nella fonte. Se la fonte è brutta e impiega molto tempo per capire ci saranno molti bug nel codice.
Il codice ben strutturato con uno stile coerente e facile da comprendere conterrà meno problemi. Il codice mostra quanto sforzo e pensiero ci sono stati dentro.
La mia ipotesi è che se la fonte contiene molti avvertimenti ci saranno molti bug che si nascondono nel codice.
La qualità del codice è relativa e molto difficile da misurare. Solo guardando il codice non darò molte informazioni. –
Vero, ma ti dà un'idea di cosa sta succedendo nel software. – Gerhard
La tua domanda è "I 5 difetti/100 linee di codice sono una stima ragionevole?" Questa domanda è estremamente difficile da rispondere, ed è altamente dipendente dalla complessità del codice 01bcodebase.
Hai anche menzionato in un commento "per mostrare alla direzione che ci sono molti bug nella base di codice" - è grandioso, complimenti, proprio così.
Al fine di aprire gli occhi figurativi del management, io suggerirei almeno un approccio 3 fronti:
Un altro punto: richiedo compilazioni pulite nei miei gruppi e pulisco anche l'output di filaccia. Solitamente questo può essere ottenuto solo scrivendo un buon codice, ma a volte gli avvisi di compilatore/sfilacciamento devono essere ottimizzati per mettere a tacere lo strumento per cose che non sono problemi (usare giudiziosamente).
Ma il punto importante che voglio fare è questo: essere molto attenti quando si va in & fissaggio compilatore & avvertimenti lint. È un obiettivo ammirevole, ma puoi anche inavvertitamente interrompere il codice di lavoro e/o scoprire un comportamento indefinito che ha funzionato accidentalmente nel codice "rotto". Sì, succede davvero. Quindi percorri con attenzione.
Infine, se si dispone già di una serie completa di test, ciò consentirà di determinare se si interrompe accidentalmente qualcosa durante il refactoring.
Buona fortuna!
+1 per un consiglio attento. Vedi anche questo libro per aiuto per effettuare la transizione dal codice non testato al codice di riferimento per i refactors: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 – Matthieu
@matthieu: questo è un bel libro. Lo consiglio anche vivamente. – geschema
Grazie per l'ottimo consiglio e per segnalare il rischio di introdurre nuovi bug durante la correzione di avvertimenti apparentemente innocui, specialmente quando non ci sono test. – geschema
Se si desidera ottenere una stima del numero di difetti, il modo usuale di stima statistica è quello di sottocampione dei dati. Selezionerei casualmente tre subroutine di medie dimensioni e controllarle attentamente per trovare bug (eliminare gli avvertimenti del compilatore, eseguire lo strumento di analisi statica, ecc.). Se trovi tre errori in 100 linee totali di codice selezionate a caso, sembra ragionevole che una simile densità di bug si trovi nel resto del codice.
Il problema menzionato qui di introdurre nuovi bug è un problema importante, ma non è necessario ricontrollare il codice modificato nel ramo di produzione per eseguire questo test. Vorrei suggerire una serie completa di test unitari prima di modificare qualsiasi subroutine e pulire tutto il codice seguito da test di sistema molto accurati prima di rilasciare un nuovo codice in produzione.
Se è sfortunato, il suo campione potrebbe essere molto buono ... –
@VJo: * Sottocampione * non significa * un campione *! Questa è la statistica per te. – Clifford
@Clifford Le statistiche vanno bene, ma la legge di Murfy è al di sopra delle statistiche;) –
Se si desidera dimostrare i vantaggi dei test unitari, revisioni del codice, strumenti di analisi statici, 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 alla gestione quanti bug trovi con questi metodi. Si spera che i risultati parlino da soli.
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 in grado di influenzare i risultati in modo drammatico, che porta alla grande variazione delle figure mostrate nella Tabella 1. In questa tabella, il numero di anomalie per mille righe di codice per C varia da 500 (!) a circa 10 (generato automaticamente).
Perché vuoi sapere? – Jan
È davvero difficile dire quanto sia rilevante il numero di avvisi. La maggior parte degli avvisi provenienti da un'intestazione verrà riportata in tutte le unità di traduzione che includono quell'intestazione. – MSalters
@ Jan: per mostrare al management che ci sono molti bug nella base di codice, e che dovremmo iniziare a fare qualcosa al riguardo adesso. – geschema