Sto provando a creare alcune metriche interne per dimostrare (determinare?) Quanto bene TDD migliora i tassi di difetti nel codice.Che cosa è il migliore rilevamento dei difetti? Difetti per KLOC?
C'è un modo migliore di difetti/KLOC? Che dire della "densità funzionale" di una lingua?
Qualsiasi commento o suggerimento sarebbe utile.
Grazie - Jonathan
Si può anche prendere in considerazione la mappatura tasso di scoperta dei difetti e tassi di risoluzione di difetti ... quanto tempo ci vuole per trovare bug, e una volta che sono trovati, per quanto tempo si vuole per risolvere? Per quanto ne so, TDD dovrebbe migliorare i tempi di correzione perché rende i difetti noti in precedenza ... giusto?
Qualsiasi misura è un confronto arbitrario di difetti con le dimensioni del codice; finché il confronto è simile, dovrebbe funzionare. Ad esempio, i difetti/kloc in C ai difetti/kloc in C. Se si sono cambiate le lingue, ciò influenzerebbe in ogni caso la metrica, poiché lo stesso programma in un'altra lingua potrebbe essere meno incline ai difetti.
suggerisco di utilizzare il rapporto tra i tempi:
Questo sembra valida in tutta lingue ...
Funziona anche se si dispone solo di una stima approssimativa di alcuni grandi codici di base. Puoi ancora confrontarlo con il nuovo codice che stai scrivendo, per impressionare la tua gestione ;-)
Misurare i difetti non è una cosa facile. Si vorrebbe rendere conto della complessità del codice, ma questo è incredibilmente disordinato e spiacevole. Quando si misura la qualità del codice vi consiglio:
Se avete intenzione di confrontare i codificatori assicurarsi di confrontare i codificatori facendo un lavoro simile nella stessa lingua. Non confrontare il codificatore che lavora nel profondo del suo motore di calcolo più complesso con il codificatore che scrive il codice che memorizza le cose nel database.
Cerco di assicurarmi che i programmatori sappiano che il processo viene misurato e non i programmatori. Questo aiuta a migliorare la qualità delle metriche.
Trovo che confrontare i codificatori sia in gran parte contrario al principio del lavoro di squadra, quindi non lo farei comunque. Grazie per il commento. – jdharley
Potresti essere scioccato da quanti "manager" pensano che sia una buona idea. Se misuri individualmente i programmatori, troveranno un modo per giocare al sistema. –
Sono scettico su tutte le misurazioni relative a LOC, non solo a causa della diversa espressività relativa delle lingue, ma perché i singoli programmatori variano abbastanza nell'espressività del loro codice per rendere questa metrica "sfocata" al meglio.
Le cose che vorrei misurare nell'interesse della gestione del progetto sono:
Tutti questi numeri sono più utili se si combinano con le informazioni di severità. Un prodotto con 20 bug minori potrebbe essere più vicino al rilascio di uno con 2 bug di arresto anomalo. Se stai eliminando i bug minori ma non quelli gravi, devi convincere gli sviluppatori a focalizzare la loro attenzione.
Vorrei tenere traccia di questi numeri per progetto e per sviluppatore. La ragione per eseguirli per progetto dovrebbe essere chiara. I numeri per sviluppatori non rappresentano certamente l'immagine completa delle competenze o della produttività di un singolo collaboratore, ma possono indirizzarti a persone che potrebbero aver bisogno di formazione o di riparazione.
È inoltre possibile contrassegnare tutti i ticket nel sistema di tracciamento dei difetti anche per modulo di progetto (in particolare per i progetti più grandi), in modo da poter rilevare quando i moduli critici si trovano in uno stato fragile.
Perché non si considerano i difetti per caso d'uso? o difetti per requisito. Abbiamo affrontato problemi pratici per arrivare al KLOC.
Ho votato per aver menzionato il * mio * lavoro più facile. –
Direi che meno difetti escono dal team di sviluppo e in QA, ma è quello che spero di dimostrare (e quantificare). Grazie - Jonathan – jdharley
Fateci sapere i risultati – Burt