Capers Jones è uno dei “big” del settore Ict. Ingegnere americano, Jones ha da sempre “speso” la sua vita professionale nell’ambito dello sviluppo software concentrandosi sugli aspetti metodologici e le best practice della software quality (è stato per molti anni manager e ricercatore per Ibm in California). Oggi è presidente e Ceo della Capers Jones & Associates nonché fondatore della Software Productivity Research (Src), realtà presso la quale hanno svolto la loro attività alcuni dei principali esperti di software management, tra cui Allan Albrecht, inventore dei Function Points (unità di misura che esprime la dimensione delle funzionalità fornite da un software). Insieme a Olivier Bonsignour, vice president of product development di Cast, con un passato in qualità di Cio alla Advanced Research Division del
Ministero della Difesa Francese, è autore di “The economics of software quality” (nella foto la copertina), interessantissimo libro che aiuta a definire in modo dettagliato i costi e gli economics della qualità del software e la loro diretta relazione con il business value. I due autori partono da una considerazione precisa: in piccoli progetti, le competenze individuali e l’esperienza degli sviluppatori software giocano un peso determinante sul successo finale. La qualità del software, cioè, dipende quasi esclusivamente dagli skill individuali. In progetti ampi e complessi, nei quali sono coinvolti team numerosi (da 20 a oltre 1000 persone, citano gli autori), i fattori impattanti, invece, sono molteplici facendo crescere in modo esponenziale il rischio della “non qualità”, che si traduce in costi.Obiettivo di Capers e Bonsignour è fornire ai lettori gli spunti, nonché i metodi, per misurare in modo efficace e attendibile la qualità del software. “Per raggiungere alti livelli di qualità anche su grandi progetti e ampi sistemi è fondamentale adottare un sinergico set di metodi. Questo, include: defect prevention, finalizzato a ridurre i difetti del software; pretest defect removal, metodo utile per gestire i controlli, le ispezioni e le analisi statiche; infine, oltre 40 tipi di testing”, scrivono gli autori. “Inoltre, ci sono molte metodologie di sviluppo software consolidate che, comparate ai tradizionali sistemi di sviluppo “waterfall” (a cascata), hanno portato enormi benefici in termini di qualità. Parliamo, per esempio, di Agile, Crystal, Extreme Programming (Xp), Personal Software Process (Psp), Rational Unified Process (Rup), Team Software Process (Tsp), e molti altri”.
L’alta qualità costa meno
Prima di entrare nel cuore del volume, però, riportiamo alcune considerazioni che Capers e Bonsignour esprimono più volte nelle pagine del loro libro circa alcune pratiche dell’industria software che hanno offuscato il concetto di “software quality economics” e generato molte incomprensioni. “Molti executives e, a dire il vero, anche qualche professionista It tendono a considerare la qualità del software come una forte spesa. Non solo, considerano l’argomento un “intoppo” che allunga i tempi di sviluppo e ne fa crescere i costi. Per fortuna – scrivono gli autori – da un’analisi effettuata su oltre 13 mila progetti software tra il 1973 e oggi, emerge che gli alti livelli di qualità delle applicazioni analizzate sono associate anche a uno schedule di sviluppo più breve rispetto alla media e ad un costo minore. La ragione dei ritardi e dei costi crescenti, dunque, non è da cercare nelle pratiche e nei metodi preposti alla qualità. Spesso – aggiungono gli autori – i problemi sono relativi al testing. Quando iniziano le fasi di test, la miriade di difetti che si riscontrano tendono ad allungare gli interventi e, di conseguenza, anche i tempi produttivi e di rilascio delle applicazioni”.
Stando a quanto riportato nel libro (testimoniato per altro da diverse ricerche e analisi internazionali nonché dalla voce diretta di alcuni casi utente – ndr), in generale, su ampi progetti software il testing low-quality risulta due o tre volte più lungo e più costoso (almeno il doppio) delle attività di testing high-quality. Questo perché, se il difetto rimane non-individuato e non- rimosso al momento di inizio delle fasi di test, diventa molto difficoltoso (e costoso) riuscire a controllare il progetto (bisogna praticamente “tornare indietro”, capire dov’è e da cosa è causato il difetto, in quale fase è emerso – cosa che a posteriori è piuttosto difficile – e attuare le azioni correttive che potrebbero anche essere interventi di riscrittura del codice). “E’ decisamente più cost-effective agire sulla prevenzione del difetto e sulla sua rimozione prima della fase di testing”, sottolineano Capers e Bonsignour.
Un altro malinteso che ha offuscato (se non addirittura nascosto) il valore economico della qualità del software è l’utilizzo non totalmente corretto da parte di molti sviluppatori e team It della cosiddetta metrica “cost-per-defect”. Facendo un mero calcolo economico dei costi It sostenuti per la gestione dei difetti di sviluppo, si è andata diffondendosi la “leggenda metropolitana” secondo la quale “i costi It sono 100 volte superiori se si individuano i bug dopo il rilascio applicativo anziché durante”. Benché l’affermazione sia corretta (sull’aumento dei costi, non tanto nel valore delle 100 volte superiore) e sia necessario, come abbiamo detto, individuare gli errori ancor prima delle fasi di test (e non solo del rilascio, quindi), la metrica cost-per-defect penalizza il concetto di qualità perché attribuisce il valore economico di quest’ultima solo in funzione della diminuzione dei difetti. Al crescere della qualità crescono ovviamente anche i costi sostenuti per far diminuire i difetti; quando si raggiunge il livello “zero difetti”, si raggiunge la massima qualità (il valore economico di questa combacia con i costi sostenuti per eliminare i difetti). Benché utile, secondo i due autori, questa metrica non è sufficiente per determinare il reale valore economico dell’alta qualità del software. Secondo Capers e Bonsignour, infatti, i benefici economici maggiori sono ben altri e non sono limitati alla migliore qualità: minori tempi di sviluppo, minori conflitti con eventuali team esterni e outsourcer; minori costi complessivi di sviluppo; minori costi di mantenimento delle applicazioni; minori costi di garanzia; miglior soddisfazione dell’utente e maggior produttività.
Ma cos'é la qualità?
Riuscire a determinare i costi della qualità del software e farne un’analisi economica è alquanto complesso. Soprattutto perché c’è ancora molta confusione sul concetto stesso di qualità che, lo ricordiamo, non è la quality assurance e non è nemmeno il testing. Gli stessi autori non ne danno una definizione specifica ma evidenziano l’importanza di considerare il tema sotto tre differenti aspetti (complementari): qualità funzionale (che identifica usabilità, affidabilità e performance delle applicazioni non solo da un punto di vista tecnico ma in funzione dell’utilizzo che ne fanno gli utenti); qualità non-funzionale (identifica gli aspetti più tecnici, quanto bene o male lavora il software rispetto a quello per cui è stato creato); qualità strutturale (identifica quanto la soluzione riesce e riuscirà a servire i business needs così come la sua capacità di evoluzione in funzione di nuove condizioni).
Se non è fattibile “confinare” la qualità del software all’interno di una descrizione chiara, è tuttavia possibile individuare quelli che sono i criteri che consentono di definirne gli elementi. Capers e Bonsignour ne identificano 7:
1) Prevedibilità: la qualità dovrebbe essere definita prima dell’inizio del progetto;
2) Misurabilità, durante tutti i cicli del progetto e anche alla sua conclusione;
3) Provabile in caso di controversie;
4) Migliorabile anche con il passare del tempo;
5) Flessibile e adattabile a tutti gli sviluppi e rilasci applicativi;
6) Prorogabile e in grado di coprire tutte le fasi e le attività;
7) Espandibile alle nuove tecnologie (come il cloud computing).
E come la si valuta?
Come accennato, gli elementi che incidono sul valore economico della qualità del software sono molteplici. Nei primi 20 anni dell’industria del software (1950-1970) la prima priorità dello sviluppo software era la riduzione dei costi operativi, quindi il valore economico della qualità si riferiva alla capacità del software di abbassare tali costi. Tra il 1970 e il 1990 la priorità, invece, era la crescita di fatturato con la maggiore vendita di beni e servizi (perciò, la qualità del software derivava dalla sua capacità di supporto a tale obiettivo). Dal 1990 ad oggi, le priorità sono nuovamente cambiate e al software è stata chiesta la capacità di far crescere fatturato attraverso la creazione di nuove linee di business oppure di nuovi prodotti e servizi.
Se poi pensiamo a società come Google, Amazon, eBay e molte altre, queste nemmeno esistono senza software al quale è chiesto “innovazione continua”.
Il valore economico della qualità del software, oggi, dipende da tutti questi elementi messi insieme: riduzione dei costi operativi, incremento di fatturato e di market share, miglior capacità competitiva con la proposta di beni e servizi innovativi.
Insomma, tutt’altro che dati tecnici! Ed è proprio su questo aspetto che insistono i due autori per far comprendere quanto la qualità sia prima di tutto un valore di business.
Il business value framework
Per dare concretezza alle teorie, Capers e Bonsignour riportano nei vari capitoli del libro interessanti analisi sulle diverse pratiche oggi in uso per valutare e misurare la qualità del software dimostrando, attraverso esempi e riportando casi concreti di aziende, la necessità di focalizzarsi su alcuni elementi ben precisi: individuazione e prioritizzazione di potenziali difetti; definizione di metodi di defect prevention e defect removal; impostazione degli adeguati metodi di pretest e test per l’individuazione e la rimozione degli errori; stima dei costi e dei tempi dedicati alla gestione dei difetti prima del rilascio e dopo, ecc. A supporto di tutte queste attività, naturalmente, esistono metodologie e sistemi metrici consolidati per i quali gli autori analizzano pro e contro.
L’approfondita disamina si conclude con la definizione di un vero e proprio framework.
Sfruttando i dati relativi alla qualità strutturale di circa 295 applicazioni analizzate (provenienti da 75 aziende a livello mondiale), i due autori introducono la nozione di “technical debt”, che identifica il costo del “fixing problem” durante la lavorazione del software che, se non fissato, causerà sicuramente problemi rilevanti al business (definiscono cioè un vero e proprio metodo per stabilire i costi dell’individuazione e gestione di tutti i problemi che si verificano nel corso dell’intero ciclo di vita dello sviluppo software). Il technical debt viene poi giustapposto ad un framework specifico finalizzato alla quantificazione della perdita di valore per il business a seguito della scarsa qualità del software. Il technical debt e il “framework for quantifying the loss of business value” sono i pilastri di un vero e proprio “business value framework” che, secondo i due autori, fornisce una piattaforma di riferimento per la ricerca, l’analisi e la misurazione degli economics del software.
