Metriche di qualità del software

Le metriche del software possono essere classificate in tre categorie:

  • Product metrics - Descrive le caratteristiche del prodotto come dimensioni, complessità, caratteristiche del design, prestazioni e livello di qualità.

  • Process metrics - Queste caratteristiche possono essere utilizzate per migliorare le attività di sviluppo e manutenzione del software.

  • Project metrics- Queste metriche descrivono le caratteristiche e l'esecuzione del progetto. Gli esempi includono il numero di sviluppatori software, il modello di personale durante il ciclo di vita del software, il costo, la pianificazione e la produttività.

Alcune metriche appartengono a più categorie. Ad esempio, le metriche di qualità in-process di un progetto sono sia metriche di processo che metriche di progetto.

Software quality metricssono un sottoinsieme di metriche software che si concentrano sugli aspetti di qualità del prodotto, processo e progetto. Questi sono più strettamente associati alle metriche di processo e di prodotto che a quelle di progetto.

Le metriche sulla qualità del software possono essere ulteriormente suddivise in tre categorie:

  • Metriche di qualità del prodotto
  • Metriche di qualità in-process
  • Metriche di qualità della manutenzione

Metriche di qualità del prodotto

Queste metriche includono quanto segue:

  • Tempo medio per il fallimento
  • Densità dei difetti
  • Problemi del cliente
  • Soddisfazione del cliente

Tempo medio per il fallimento

È il tempo tra i fallimenti. Questa metrica viene utilizzata principalmente con sistemi critici per la sicurezza come i sistemi di controllo del traffico aereo, l'avionica e le armi.

Densità dei difetti

Misura i difetti relativi alla dimensione del software espressa come righe di codice o punto di funzione, ecc., Ovvero misura la qualità del codice per unità. Questa metrica viene utilizzata in molti sistemi software commerciali.

Problemi del cliente

Misura i problemi che i clienti incontrano durante l'utilizzo del prodotto. Contiene la prospettiva del cliente rispetto allo spazio problematico del software, che include i problemi non orientati al difetto insieme ai problemi del difetto.

La metrica dei problemi viene solitamente espressa in termini di Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Dove,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

Il PUM viene solitamente calcolato per ogni mese successivo al rilascio del software sul mercato e anche per le medie mensili per anno.

Soddisfazione del cliente

La soddisfazione del cliente viene spesso misurata dai dati dell'indagine sui clienti attraverso la scala a cinque punti:

  • Molto soddisfatto
  • Satisfied
  • Neutral
  • Dissatisfied
  • Molto insoddisfatto

La soddisfazione per la qualità complessiva del prodotto e le sue dimensioni specifiche si ottiene solitamente attraverso vari metodi di indagine sui clienti. Sulla base dei dati su scala a cinque punti, è possibile costruire e utilizzare diverse metriche con lievi variazioni, a seconda dello scopo dell'analisi. Ad esempio:

  • Percentuale di clienti completamente soddisfatti
  • Percentuale di clienti soddisfatti
  • Percentuale di clienti insoddisfatti
  • Percentuale di clienti non soddisfatti

Di solito, viene utilizzata questa percentuale di soddisfazione.

Metriche di qualità in-process

Le metriche di qualità in-process si occupano del monitoraggio dell'arrivo dei difetti durante i test formali delle macchine per alcune organizzazioni. Questa metrica include:

  • Densità dei difetti durante il test della macchina
  • Schema di arrivo dei difetti durante il test della macchina
  • Schema di rimozione dei difetti basato sulla fase
  • Efficacia della rimozione dei difetti

Densità dei difetti durante il test della macchina

La percentuale di difetti durante il test formale della macchina (test dopo che il codice è stato integrato nella libreria di sistema) è correlata alla percentuale di difetti sul campo. Le percentuali di errore più elevate rilevate durante il test sono un indicatore che il software ha riscontrato una maggiore iniezione di errori durante il processo di sviluppo, a meno che la percentuale di errori di test più elevata sia dovuta a uno straordinario sforzo di test.

Questa semplice metrica dei difetti per KLOC o punto funzione è un buon indicatore di qualità, mentre il software è ancora in fase di test. È particolarmente utile monitorare le versioni successive di un prodotto nella stessa organizzazione di sviluppo.

Schema di arrivo dei difetti durante il test della macchina

La densità complessiva dei difetti durante il test fornirà solo il riepilogo dei difetti. Il modello di arrivo dei difetti fornisce maggiori informazioni sui diversi livelli di qualità sul campo. Include quanto segue:

  • Gli arrivi di difetti o difetti segnalati durante la fase di test per intervallo di tempo (ad esempio, settimana). Qui non saranno tutti difetti validi.

  • Il modello di arrivi di difetti validi quando viene eseguita la determinazione del problema sui problemi segnalati. Questo è il vero modello di difetto.

  • Il modello degli straordinari arretrati di difetti. Questa metrica è necessaria perché le organizzazioni di sviluppo non possono indagare e risolvere immediatamente tutti i problemi segnalati. Questa è una dichiarazione del carico di lavoro e una dichiarazione di qualità. Se il backlog di difetti è elevato alla fine del ciclo di sviluppo e molte correzioni devono ancora essere integrate nel sistema, la stabilità del sistema (quindi la sua qualità) ne risentirà. È necessario ripetere il test (test di regressione) per garantire il raggiungimento dei livelli di qualità del prodotto mirati.

Schema di rimozione dei difetti basato sulla fase

Questa è un'estensione della metrica della densità dei difetti durante il test. Oltre al test, tiene traccia dei difetti in tutte le fasi del ciclo di sviluppo, comprese le revisioni del progetto, le ispezioni del codice e le verifiche formali prima del test.

Poiché una grande percentuale di difetti di programmazione è correlata a problemi di progettazione, l'esecuzione di revisioni formali o verifiche funzionali per migliorare la capacità di rimozione dei difetti del processo sul front-end riduce gli errori nel software. Il modello di rimozione dei difetti basata sulla fase riflette la capacità complessiva di rimozione dei difetti del processo di sviluppo.

Per quanto riguarda le metriche per le fasi di progettazione e codifica, oltre ai tassi di difetto, molte organizzazioni di sviluppo utilizzano metriche come la copertura dell'ispezione e lo sforzo di ispezione per la gestione della qualità in-process.

Efficacia della rimozione dei difetti

Può essere definito come segue:

$$ DRE = \ frac {Difetto \: rimosso \: durante \: a \: sviluppo \: fase} {Difetti \: latente \: in \: il \: prodotto} \ volte 100 \% $$

Questa metrica può essere calcolata per l'intero processo di sviluppo, per il front-end prima dell'integrazione del codice e per ogni fase. È chiamatoearly defect removal se utilizzato per il front-end e phase effectivenessper fasi specifiche. Maggiore è il valore della metrica, più efficace è il processo di sviluppo e minori sono i difetti passati alla fase successiva o al campo. Questa metrica è un concetto chiave del modello di rimozione dei difetti per lo sviluppo del software.

Metriche della qualità della manutenzione

Sebbene non si possa fare molto per alterare la qualità del prodotto durante questa fase, di seguito sono riportate le correzioni che possono essere effettuate per eliminare i difetti il ​​prima possibile con un'eccellente qualità di correzione.

  • Correzione del backlog e dell'indice di gestione del backlog
  • Correggi i tempi di risposta e fissa la reattività
  • Percentuale di correzioni delinquenti
  • Qualità della correzione

Correzione del backlog e dell'indice di gestione del backlog

La correzione degli arretrati è correlata al tasso di arrivi di difetti e alla velocità con cui si rendono disponibili soluzioni per i problemi segnalati. È un semplice conteggio dei problemi segnalati che rimangono alla fine di ogni mese o ogni settimana. Usandolo nel formato di un grafico di tendenza, questa metrica può fornire informazioni significative per la gestione del processo di manutenzione.

Backlog Management Index (BMI) viene utilizzato per gestire il backlog di problemi aperti e irrisolti.

$$ BMI = \ frac {Numero \: di \: problemi \: chiuso \: durante \: il \: mese} {Numero \: di \: problemi \: arrivato \: durante \: il \: mese} \ volte 100 \% $$

Se il BMI è maggiore di 100, significa che il backlog è ridotto. Se il BMI è inferiore a 100, il backlog è aumentato.

Correggi i tempi di risposta e fissa la reattività

La metrica del tempo di risposta della correzione viene solitamente calcolata come il tempo medio di tutti i problemi dall'apertura alla chiusura. Il breve tempo di risposta fisso porta alla soddisfazione del cliente.

Gli elementi importanti della reattività della correzione sono le aspettative del cliente, il tempo concordato per la correzione e la capacità di soddisfare il proprio impegno nei confronti del cliente.

Percentuale di correzioni delinquenti

Viene calcolato come segue:

$ Percent \: Delinquent \: Fixes = $

$ \ frac {Numero \: di \: correzioni \: che \: superato \: \: risposta \: tempo \: criteri \: da \: ceverity \: livello} {Numero \: di \: correzioni \: consegnato \: in \: a \: specificato \: time} \ times 100 \% $

Qualità della correzione

La qualità delle correzioni o il numero di correzioni difettose è un'altra metrica di qualità importante per la fase di manutenzione. Una correzione è difettosa se non ha risolto il problema segnalato o se ha risolto il problema originale ma ha inserito un nuovo difetto. Per il software mission-critical, le correzioni difettose sono dannose per la soddisfazione del cliente. La metrica della percentuale di correzioni difettose è la percentuale di tutte le correzioni in un intervallo di tempo difettoso.

Una correzione difettosa può essere registrata in due modi: registrarla nel mese in cui è stata rilevata o registrarla nel mese in cui è stata consegnata la correzione. Il primo è una misura del cliente; la seconda è una misura di processo. La differenza tra le due date è il periodo di latenza della correzione difettosa.

Di solito, maggiore è la latenza, maggiori saranno i clienti che ne risentiranno. Se il numero di difetti è elevato, il valore piccolo della metrica percentuale mostrerà un'immagine ottimistica. L'obiettivo di qualità per il processo di manutenzione, ovviamente, è zero correzioni difettose senza delinquenza.