Come calcolare la qualità del progetto software [duplicato]

Un aspetto importante è lasciato fuori nella domanda. Stai provando a misurare su individui, su una squadra o sull'intera organizzazione che produce il software? Questo fa un'enorme differenza per le misure da usare.

Misure di processo

Nei sistemi software complessi, la misurazione della copertura del test e il commit di test di rottura aiutano a focalizzare la mente degli sviluppatori.

In tema di misurazione dei bug

Dall'esperienza, ho scoperto che l'utilizzo di misure quantitative di bug per misurare le prestazioni di sviluppo del software tende ad avere un grande impatto su come e se i bug vengono entrambi segnalati e risolti. In sostanza, il fatto di attribuire il prestigio o la perdita della stessa alla segnalazione di bug e / o alla risoluzione dei bug tende a ridurre sia la qualità del rapporto bug che le prestazioni di sviluppo del software.

Penso che la ragione principale di ciò sia che la maggior parte dei bug sono molto soggettivi.

Invece, misurare le prestazioni (dei bit del processo utente direttamente interessati dal software) e la soddisfazione degli utenti del software. Anche se questo è altrettanto soggettivo, focalizzerà il tuo team di sviluppo sul tentativo di comprendere il dominio del problema e di produrre clienti soddisfatti.

Prima di metriche e grafici specifici, pensa a 5-10 domande a cui vuoi rispondere con queste metriche in parole semplici. Dopo tale piano, le informazioni necessarie per rispondere a tali domande. Da lì puoi ricavare grafici e rapporti.

Ad esempio: - Quanti difetti significativi sono ancora irrisolti per il progetto? - > può essere semplice come definire il filtro corretto (che rappresenta i problemi "significativi" nel sistema di tracciamento dei difetti) e ottenere il numero totale di tali difetti - Quante volte i tester trovano problemi significativi? - > può essere presentato come un grafico di tendenza nel tempo per il filtro simile alla domanda uno - Quanti difetti sono stati rilevati esternamente dagli utenti, piuttosto che internamente dai tester? ecc.

Per quanto riguarda gli strumenti, dipende principalmente da cosa si utilizza per il proprio software di gestione difetti / test e cosa si ha nella propria azienda. Tali strumenti possono fornirti tutti i report necessari, oppure può essere semplice come impostare un documento MS Excel o OpenOffice Calc, oppure puoi andare alle opzioni di lusso, ad es. impostazione del sistema di segnalazione BI.

Dovrei pensare che è onere del cliente indicare alla tua squadra quali metriche di qualità lui / lei vuole vedere. Se questo non è il caso, si dovrebbe chiarire al cliente se quello che lui / lei vuole veramente è la prova (sotto forma di metriche) che il tuo negozio di software produce un lavoro di qualità.

Per il dopo, i difetti per release (o un delta per release come SLOC e / o FP modificati o requisiti implementati) dovrebbero essere presi in considerazione. Questo accanto a

1. soddisfazione del cliente,
2. tasso di rimozione dei difetti per release / release delta,
3. età media dei difetti (dalla rilevazione alla rimozione), sia come media per gli ultimi X mesi, per l'ultimo numero Y di uscite e annuale dall'inizio del tempo (si spera di mostrare l'età dei difetti non lo è aumentando.)
4. metriche di livello del codice sorgente come complessità ciclomatica e LCOM (a mostra la qualità della struttura del codice stesso.)

Esistono strumenti come Sonar che possono semplificare molto questo tipo di raccolta delle metriche. Una volta che l'infrastruttura di QA è stata installata e integrata con i cicli di build-release, è solo questione di raccogliere i dati nel tempo.