introduzione

logo namcookL'industria del software è una delle industrie più grandi e di maggior successo della storia. Ma le applicazioni software sono tra gli oggetti prodotti più costosi e soggetti a errori nella storia. Il software necessita di stime accurate dei programmi, costi, e qualità. Questi sono difficili da raggiungere se le metriche fondamentali sono sbagliate e distorcono la realtà. Come di 2014 l'industria del software lavora con una varietà di misure e metriche non standard e altamente imprecise aggravate da pratiche di misurazione molto approssimative. Gli errori nelle misure e nelle metriche del software causano errori nelle stime del software. Di seguito sono riportate le descrizioni degli argomenti di metrica del software più preoccupanti in ordine alfabetico dal mio punto di vista. Due di loro sono entrambi diffusi e fastidiosi:

  • Il costo per difetto penalizza la qualità
  • Le righe di codice penalizzano i linguaggi di alto livello e rendono invisibili i requisiti e il design

Metriche problematiche

Costo per difetto le metriche penalizzano la qualità e fanno sembrare il software più difettoso più economico. Non ci sono ISO o altri standard per il calcolo del costo per difetto. Il costo per difetto non misura il valore economico della qualità del software. La leggenda metropolitana che costa 100 volte tanto per correggere i difetti post-rilascio rispetto ai difetti precoci non è vero e si basa sull'ignorare i costi fissi. A causa dei costi fissi di scrittura ed esecuzione dei casi di test, il costo per difetto aumenta costantemente perché vengono rilevati sempre meno difetti. Ciò è causato da una regola standard dell'economia di produzione: “se un processo ha un'alta percentuale di costi fissi e vi è una riduzione delle unità prodotte, il costo unitario aumenterà.” Questo spiega perché il costo per difetto sembra aumentare nel tempo anche se i costi effettivi di riparazione del difetto sono fissi e non cambiano molto. Ovviamente ci sono difetti molto preoccupanti che sono costosi e richiedono tempo, ma questi sono relativamente rari.

Densità dei difetti le metriche misurano il numero di bug rilasciati ai client. Non ci sono ISO o altri standard per il calcolo della densità dei difetti. Un metodo conta solo i difetti del codice rilasciati. Un metodo più completo include bug originati nei requisiti e nella progettazione, nonché difetti del codice, e include anche "correzioni errate" o bug nelle riparazioni dei difetti stessi. Ci possono essere più di un 300% variazione tra il conteggio dei soli bug del codice e il conteggio dei bug da tutte le fonti.

Metriche dei punti funzione sono stati inventati da IBM circa 1975 e posto nel pubblico dominio circa 1978. Le metriche dei punti funzione misurano la produttività economica utilizzando entrambi "ore di lavoro per punto funzione" E "punti funzione al mese". Sono anche utili per normalizzare i dati di qualità come "difetti per punto funzione". Tuttavia ci sono numerose variazioni dei punti funzione e tutte producono risultati diversi: Automatico, fallito, COSMICO, Veloce, FISM, IFPUG, Mark II, Nesma, non regolato, eccetera. Ci sono standard ISO per COSMICO, FISM, IFPUG, Mark II e Nesma. Tuttavia, nonostante gli standard ISO, tutti e cinque producono conteggi diversi. Gli aderenti a ciascuna variante del punto funzione affermano che la "precisione" è una virtù, ma non esiste un atomo di cesio o un modo indipendente per accertare l'accuratezza, quindi queste affermazioni sono false. Ad esempio, i punti funzione COSMIC producono conteggi più elevati rispetto ai punti funzione IFPUG per molte applicazioni, ma ciò non indica "accuratezza" poiché non esiste un modo oggettivo per conoscere l'accuratezza.

Metriche obiettivo/domanda (GQM) sono stati inventati dal Dott. Victor Basili dell'Università del Maryland. Il concetto è accattivante. L'idea è di specificare una sorta di obiettivo o target tangibile, e poi pensa alle domande a cui è necessario rispondere per raggiungere l'obiettivo. Questo è un buon concetto per tutta la scienza e l'ingegneria e non solo per il software. tuttavia, poiché ogni azienda e progetto tende a specificare obiettivi unici il Metodo GQM non si presta né a strumenti di stima parametrica né alla raccolta di dati di benchmark. Non sarebbe difficile fondere GQM con metriche dei punti funzione e altre metriche software efficaci come l'efficienza di rimozione dei difetti. Ad esempio diversi obiettivi utili potrebbero essere "Come possiamo ottenere potenziali di difetto inferiori a 1.0 per punto funzione?" O "Come possiamo raggiungere tassi di produttività di 100 punti funzione al mese?" Un altro buon obiettivo che dovrebbe effettivamente essere un obiettivo per ogni azienda e ogni progetto software nel mondo sarebbe "Come possiamo ottenere più di 99% nell'efficienza della rimozione dei difetti?"

Righe di codice (POSTO) le metriche penalizzano i linguaggi di alto livello e fanno sembrare i linguaggi di basso livello migliori di quello che sono. Metriche LOC anche rendere invisibili i requisiti e il design. Non ci sono ISO o altri standard per il conteggio delle metriche LOC. Circa la metà dei giornali e degli articoli di riviste utilizza il LOC fisico e l'altra metà utilizza il LOC logico. La differenza tra i conteggi di LOC fisico e logico può essere superiore 500%. Le metriche LOC rendono invisibili requisiti e progettazione e ignorano anche requisiti e difetti di progettazione, che superano i difetti del codice. Sebbene ci siano benchmark basati su LOC, gli errori intrinseci delle metriche LOC le rendono inaffidabili. A causa della mancanza di standard per il conteggio dei LOC, i benchmark di fornitori diversi per le stesse applicazioni possono contenere risultati molto diversi.

Punto della storia le metriche sono ampiamente utilizzate per progetti agili con "storie utente". Punti della storia non hanno standard ISO per il conteggio o qualsiasi altro standard. Sono molto ambigui e possono variare tanto quanto 400% da azienda ad azienda e da progetto a progetto. Ci sono pochi benchmark utili che utilizzano i punti della storia. Ovviamente i punti della storia non possono essere utilizzati per progetti che non utilizzano le storie degli utenti, quindi sono inutili per il confronto con altri metodi di progettazione.

Debito tecnico è una nuova metrica e si sta rapidamente diffondendo. È una brillante metafora sviluppata da Ward Cunningham. Il concetto di "debito tecnico” è che gli argomenti differiti durante lo sviluppo nell'interesse della velocità di pianificazione costeranno di più dopo il rilascio di quanto sarebbero costati inizialmente. Tuttavia non esistono standard ISO per il debito tecnico e il concetto è molto ambiguo. Può variare di oltre 500% da azienda ad azienda e da progetto a progetto. Peggio, il debito tecnico non include tutti i costi associati alla scarsa qualità e alle scorciatoie di sviluppo. Il debito tecnico omette i progetti annullati, danni consequenziali o danni agli utenti, e i costi del contenzioso per la scarsa qualità.

Usa i punti del caso vengono utilizzati da progetti con design basati su "casi d'uso" che spesso utilizzano il Rational Unified Process di IBM (RUP). Non ci sono standard ISO per i casi d'uso. Usa i punti del caso sono ambigui e possono variare di oltre 200% da azienda ad azienda e da progetto a progetto. Ovviamente i casi d'uso sono inutili per misurare progetti che non utilizzano casi d'uso, quindi hanno pochissimi dati di riferimento.

Definizione della produttività del software

Per più di 200 anni la definizione economica standard di produttività è stata, “Beni o servizi prodotti per unità di lavoro o spesa.” Questa definizione è utilizzata in tutti i settori, ma è stato difficile da usare nell'industria del software. Per il software c'è ambiguità in ciò che costituisce il nostro "beni o servizi."

L'unità più antica per i "beni" software era un "riga di codice” o LOC. Più recentemente i beni software sono stati definiti come “punti funzione". Definizioni ancora più recenti di beni includono “punti della storia" E "usa i punti del caso". Il pro e contro di queste unità sono state ampiamente discusse in letteratura.

Un altro importante argomento tratto dall'economia manifatturiera ha un grande impatto su produttività del software che non è ancora ben compreso nemmeno in 2014: prezzi fissi.

Una legge fondamentale dell'economia di produzione valida per tutti i settori, incluso il software, è la seguente: “Quando un processo di sviluppo ha un'alta percentuale di costi fissi, e c'è un calo nel numero di unità prodotte, il costo unitario aumenterà."

Quando un "riga di codice” viene selezionato come unità di produzione e si passa da un linguaggio di basso livello come l'assembly a un linguaggio di alto livello come Java, ci sarà una riduzione del numero di unità sviluppate.

Ma le attività non codificate di requisiti e progettazione agiscono come costi fissi. Pertanto il costo per riga di codice aumenterà per i linguaggi di alto livello. Ciò significa che LOC non è una metrica valida per misurare la produttività economica.

Per il software ci sono due definizioni di produttività che corrispondono a concetti economici standard:

  1. Produrre una quantità specifica di unità consegnabili per il minor numero di ore di lavoro.
  2. Produrre il maggior numero di unità consegnabili in un periodo di lavoro standard come un'ora, mese, o anno.

Per definizione 1 i beni consegnabili sono costanti e l'orario di lavoro è variabile.

Per definizione 2 i beni consegnabili sono variabili ei periodi di lavoro sono costanti.

Definizione della qualità del software

Come tutti sappiamo l'argomento di "qualità" è alquanto ambiguo in ogni settore. Le definizioni di qualità possono comprendere la qualità estetica soggettiva e anche unità quantitative precise come il numero di difetti e i loro livelli di gravità.

Nel corso degli anni il software ha provato una serie di definizioni alternative per la qualità che in realtà non sono utili. Ad esempio, una definizione per la qualità del software è stata "conformità ai requisiti."

I requisiti stessi sono pieni di bug o errori che comprendono about 20% dei difetti complessivi riscontrati nelle applicazioni software. Definire la qualità come conformità a una delle principali fonti di errore è un ragionamento circolare e chiaramente non valido. Dobbiamo includere gli errori relativi ai requisiti nella nostra definizione di qualità.

Un'altra definizione di qualità è stata "idoneità all'uso.Ma questa definizione è ambigua e non può essere prevista prima del rilascio del software, o anche misurato bene dopo il rilascio.

Un'altra definizione per la qualità del software è stata una stringa di parole che terminano con "...ility" come affidabilità e manutenibilità. Per quanto lodevoli siano questi attributi, sono tutti ambigui e difficili da misurare. Ulteriore, sono difficili da prevedere prima della creazione delle applicazioni.

Una definizione efficace per la qualità del software che può essere sia prevista prima della creazione delle applicazioni sia misurata dopo la consegna delle applicazioni è: “La qualità del software è l'assenza di difetti che potrebbero causare l'interruzione del funzionamento dell'applicazione, o far sì che produca risultati errati."

Perché i difetti forniti incidono sull'affidabilità, manutenibilità, usabilità, idoneità all'uso, conformità ai requisiti, e anche la soddisfazione del cliente qualsiasi definizione efficace della qualità del software deve riconoscere l'importanza centrale di ottenere bassi volumi di difetti consegnati. La qualità del software è impossibile senza bassi livelli di difetti forniti, indipendentemente dalla definizione utilizzata.

 

Circa l'autore:

Capperi Jones è CTO di Analisi di Namcook, un'azienda che costruisce un rischio avanzato, qualità, e strumenti di stima dei costi. Questo post sul blog è stato originariamente pubblicato sul blog di Namcook Analytics.

Un post sul blog rappresenta l'opinione personale dell'autore
e potrebbe non coincidere necessariamente con le politiche ufficiali di Nesma.
Condividi questo post su:

1 Commenti

Lascia un commento
  1. Jean-Pierre Fayolle dice:

    Sempre bello leggere qualcosa di Capers.

    Solo un commento sul debito tecnico: che non sia ISO non significa che non sia utilizzabile, e alcune persone hanno costruito una buona metodologia attorno ad esso: http://www.sqale.org/

    L'ho utilizzato per definire alcuni piani di refactoring e stimare lo sforzo di refactoring di un'applicazione Legacy C (http://qualilogy.com/blog/legacy-application-refactoring-sqale-plugin-2/).

    Adesso è giusto che ognuno abbia il suo modo di misurare il debito tecnico, quindi otterrai risultati diversi in base ai diversi editor di software. Secondo me, questo è uno strumento pratico per un team di progetto per verificare che non ci sia una grande deriva con ogni nuova versione. Ma può essere utile per la gestione se correttamente utilizzato e spiegato. Non usare i numeri fuori dagli schemi.

lascia un commento