È possibile applicare prontamente le metriche di contenimento dei contatori a livello organizzativo quando esiste una struttura coerente del processo organizzativo?

Question

È possibile applicare prontamente le metriche di contenimento dei contatori a livello organizzativo quando esiste una struttura coerente del processo organizzativo?

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

6

Le metriche di contenimento dei difetti, come l'efficacia di contenimento dei difetti totali (TDCE) e l'efficacia di contenimento delle fasi (PCE), possono essere utilizzate per fornire un buon indicatore della qualità del processo. TDCE cattura i difetti che vengono catturati in un punto tra i requisiti e il rilascio di un prodotto nel campo, indicando l'efficacia complessiva dell'intero processo per trovare e rimuovere i difetti. PCE fornisce più dettagli in ogni fase del ciclo di vita dello sviluppo del software e come funzionano le tecniche di rilevamento e rimozione dei difetti.

L'applicazione di queste metriche ha senso a un livello in cui si dispone di un processo e una metodologia ben definiti per lo sviluppo del prodotto, spesso un progetto. Tuttavia, alcune organizzazioni forniscono una struttura di processo che è adattata a livello di progetto. Questa struttura di processo includerebbe la guida necessaria per soddisfare le certificazioni (ISO9001, CMMI), le pratiche per l'incorporazione di tecniche note (metodi agili, Lean, Six Sigma) e requisiti per ragioni legali o normative. Tuttavia, i dettagli specifici su come raccogliere i requisiti, progettare il sistema, produrre il software, condurre test e rilasciare sono lasciati ai team di sviluppo del prodotto.

Esiste un modo efficace per applicare le metriche di contenimento dei difetti a livello organizzativo quando esiste solo un framework di processo a livello organizzativo? In caso contrario, quali potrebbero essere alcune idee per le metriche che possono essere distillate da ciascun progetto (ognuna utilizzando un processo personalizzato che si inserisce nel framework del processo organizzativo) che acquisisce le metriche di contenimento dei difetti per discutere la capacità del processo di trovare e rimuovere i difetti? / p>

L'obiettivo finale di tale metrica sarebbe quello di consolidare le pratiche di contenimento dei difetti di un gran numero di progetti in corso e riferire alla direzione. Il pubblico di riferimento sarebbe costituito da persone in ruoli come il capo ingegnere del software e l'ingegnere capo (di tutte le discipline ingegneristiche) per l'organizzazione. Anche se i dati specifici del progetto sarebbero disponibili, l'idea è di produrre qualcosa che quantifica l'efficacia generale di tutti i processi su misura in tutti i progetti in corso. Sospetto che questi dati vengano anche presentati come parte di CMMI, ISO o audit simili per dimostrare la qualità del processo.

quality defect metrics

posta Thomas Owens 11.04.2012 - 14:29

fonte

3 risposte

Leggi altre domande sui tag quality defect metrics

Come gestire due versioni principali usando SVN? Ci sono aziende che usano BDD in un ambiente .NET?

score 3 · Answer 1

Il consolidamento della gestione dei difetti sembra una buona idea, a meno che i progetti non siano così ortogonali da richiedere sistemi di gestione dei difetti separati. Ad esempio, uno sviluppatore solista che fa i suoi test può andare avanti con la lista dei proiettili, mentre un'organizzazione distribuita con clienti che segnalano bug a un team di supporto richiede un processo molto più pesante. Questo è ovvio, ma è importante considerare in che modo il consolidamento influirà su tutti gli sviluppatori coinvolti e se saranno motivati a comprarlo.

Il problema con le metriche dei bug è se gli sviluppatori ritengono che il conteggio degli errori sia un modo per misurare le loro prestazioni, quindi potrebbero ottenere dei numeri fudge (raggruppando più bug in uno, sottovalutando l'impatto dell'insetto l'insetto più a monte). Questo è particolarmente rischioso se presentate i report alla direzione. Anche se ottieni il supporto di tutti gli sviluppatori, ci possono essere grandi differenze semplicemente dal modo in cui riportano individualmente i bug.

Le metriche di contenimento dei difetti , in particolare, sembrano sostenere l'ipotesi di una curva di costo esponenzialmente crescente a valle. Mentre questo potrebbe essere il caso, gli agilisti fanno un argomento convincente per cambiare la curva dei costi invece di fermare i difetti il prima possibile . Sarei scettico nei confronti di qualsiasi metrica che presuppone una curva di costo fissa, dal momento che ogni progetto e tipo di bug può avere curve di costo notevolmente diverse.

Se è molto più costoso catturare un bug a valle, abbassare la curva dei costi adottando strumenti migliori, adottando integrazione continua, test automatizzati o altre pratiche agili può essere una soluzione migliore. Naturalmente, in alcuni progetti potrebbero esserci notevoli costi a valle inevitabili (ad esempio codice dello space shuttle), nel qual caso le metriche di contenimento dei difetti hanno più senso.

Altrimenti, utili "metriche" secondo me stanno categorizzando bug per tipo per aiutare ad analizzare eventuali difetti sistemici. Tracciare dove è stato catturato il bug (sviluppo, integrazione o nel campo) è anche importante per l'analisi, ma come ho detto prima sarei restio a collegarli a una curva di costo fisso per ottenere un singolo numero. Il costo per la correzione dei bug può invece essere stimato monitorando le ore trascorse da uno sviluppatore utilizzando uno strumento come Mylyn, sebbene ciò richieda una certa disciplina da parte dello sviluppatore.

score 1 · Answer 2

Opinione IMHO (downvote se non sei d'accordo) questo è un piolo quadrato, buco rotondo.

I framework di processo specificatamente come Agile esistono puramente perché il processo non è importante quanto le persone (vedi il Agile Manifesto ). Questo non vuol dire che le metriche non siano così importanti. Quelli importanti come Velocity, ad esempio, hanno a che fare con il ritmo del completamento della trama dell'utente. I difetti dovrebbero essere associati a una storia utente e di breve durata, altrimenti dovrebbero semplicemente diventare un'altra storia utente. Ma sto divagando.

Le metriche come TDCE e PCE non hanno senso nei framework di processo come Agile perché Agile funziona in modo specifico contro la visualizzazione del software a livello di macro progetto, in particolare la risoluzione dei bug che implica intrinsecamente un insieme rigido di requisiti prima della fase di sviluppo.

È come provare a misurare la Dustiness of Bacon. Certo, potrebbe misurarlo probabilmente se lo hai provato, ma perché vorresti farlo?

Con ciò detto, un framework di processo incoraggia lo sviluppo di un framework personalizzato che risponda specificamente al progetto o alle esigenze organizzative. Non vedo perché una metrica Mini-PCE non possa essere concepita finché si ritiene che sia pertinente e vantaggiosa per l'organizzazione, il prodotto e il cliente.

score 0 · Answer 3

Ho trovato un articolo dalla rivista CrossTalk intitolato Advancing Defect Containment to Quantitative Defect Management , scritto da due ingegneri di Raytheon. Questo articolo descrive una tecnica per fare esattamente ciò che voglio fare: portare le metriche di contenimento dei difetti del software e cercare di renderle significative a livello organizzativo. Chiamano questa tecnica Quantitative Defect Management (QDM).

Si concentra sui dati dei difetti storici e confronta i dati del progetto corrente con i dati storici. Determinando il numero di difetti generati in una determinata fase in progetti passati simili, è possibile stimare il numero di difetti che ci si aspetta di generare nel progetto corrente nella stessa fase. Naturalmente, in un ambiente che comprende il miglioramento continuo, ci si aspetterebbe di vedere una tendenza al ribasso dei difetti nel tempo, ma è possibile tenerne conto.

Una volta che conosci i tuoi dati storici, puoi confrontare i tuoi difetti in fase trovati con quel numero previsto. Ciò consente di allocare tempo e risorse a varie strategie di rilevamento dei difetti per ciascuna fase di sviluppo, oltre a rivedere i dati di rimozione e contenimento dei difetti per migliorare il processo per prevenire i difetti nei progetti futuri. Dedicando il tempo necessario per pianificare ogni fase e monitorando e migliorando continuamente le tecniche utilizzate per rilevare i difetti, ci si può aspettare un miglioramento sia della qualità dei processi che dei prodotti.

Gli autori parlano anche di questa metrica in relazione a Six Sigma e CMMI (specialmente Livello 4 e Livello 5).

Sebbene ciò non corrisponda esattamente al contenimento dei difetti, ritengo che ciò sia appropriato per la gestione. Fornirà dati che possono essere utilizzati tra i progetti per confrontare l'attuale qualità del processo con progetti precedenti, fornire dati aggiuntivi per il monitoraggio della qualità del prodotto e (nel tempo) dimostrare l'efficacia degli sforzi di miglioramento del processo.