Lo stato di salute del software, come verificare la qualità delle applicazioni

Quando si può affermare che un software sia ‘scritto bene’ dal punto di vista della sua ingegnerizzazione? Qual è il suo ‘stato di salute’ e come lo si misura? Benché non abbia la pretesa di fornire una base statistica di analisi, il Crash Report condotto da Cast offre mediamente ogni biennio un’importante fotografia globale sullo stato della ‘qualità strutturale’ delle applicazioni It in uso nelle aziende.

Il report 2014-2015 è stato condotto su un campione di 1316 applicazioni (installate in 212 organizzazioni aziendali rappresentative di 12 settori industriali differenti ed operanti in Usa, Europa e India) per un totale approssimativo di 706 milioni di linee di codice (scritte con linguaggi che vanno da Java-EE, Cobol, .Net, Oracle e Abap, specie nelle grandi organizzazioni, ad altri come C, C++, Asp e linguaggi ‘misti’ che integrano ai precedenti linee di programmazione in Db2, Delphi, Pacbase, Peoplesoft, Php, PL1, Powerbuilder, Powercenter, Rdl, Rpg, script languages, Siebel, Sql Server e Visual Basic).

Come misurare la qualità strutturale

Ma partiamo dai fondamentali, cosa si intende per qualità strutturale di un software?

“La qualità strutturale si riferisce alla ‘solidità’ ingegneristica dell’architettura e del codice di un’applicazione non tanto alla correttezza e all’allineamento con cui risponde ai requisiti funzionali richiesti dagli utenti o dal business”, si legge nel report. Partendo da questo assunto, cinque sono le aree di analisi prese in esame:

1. robustezza: è indice della stabilità e della resilienza di un’applicazione, diventa anche l’indicatore primario delle probabilità di ‘difetti’ quando si va a modificare il codice del software;
2. prestazioni: in questo caso le performance indicano l’efficienza del software rispetto ai tempi di ‘lavorazione’ ed alle risorse utilizzate;
3. sicurezza: si misura in base all’abilità di un’applicazione di prevenire intrusioni non autorizzate;
4. variabilità: indica la flessibilità di un software nell’essere facilmente e velocemente modificato quando necessario;
5. trasferibilità: in questo caso la misurazione serve a definire quanto complessa o meno sia un’applicazione nel momento in cui questa debba essere trasferita ad altri team di lavoro (indica quanto sia semplice per un nuovo team comprenderla per poterci poi lavorare in tempi rapidi).

Le relazioni ‘pericolose’

Figura 1 – Risultati del Crash Report sulla base delle aree analizzate (sull’ordinata la frequenza, sull’ascissa l’indice di rischio) – fonte: Cast

Il punteggio per stabilire ‘lo stato di salute’ di un’applicazione sul piano della qualità strutturale è calcolato mediante una scala che va da 1 (alto rischio) a 4 (basso rischio) analizzando l’applicazione per rilevare le violazioni delle oltre 1200 regole e pratiche di ‘buona architettura e coding’ (che derivano dai framework metodologici, dalle pratiche condivise nelle community di sviluppatori, ecc.). Il punteggio si basa sulle evidenze che emergono mediante un algoritmo che valuta il numero di volte che si è verificata una violazione comparandolo al numero di opportunità ‘mancate’ (le volte cioè che si sarebbe potuto intervenire preventivamente per evitare la violazione), ponderando la gravità della violazione e la sua ‘rilevanza’ in base ad ogni singola caratteristica di qualità (robustezza, prestazioni, sicurezza, variabilità, trasferibilità).

Tale premessa è doverosa per l’analisi dei risultati emersi dall’ultimo Crash Report dal quale si evince, in linea di massima, una prevalenza di punteggi medio-alti nell’ambito di robustezza, sicurezza e variabilità (figura 1).

Tuttavia, sottolineano gli esperti, il Total Qualiy Index (Tqi) è dato dall’insieme dei cinque fattori e dei punteggi che vengono analizzati sia nel loro insieme (il singolo fattore analizzato attraverso milioni di righe di codice) sia nella ‘relazione’ e ‘correlazione’ che ciascuno di essi ha con gli altri fattori (figura 2). Partendo quindi da questa considerazione generale, quattro sono le osservazioni primarie emerse dalle rilevazioni effettuate nel biennio 2014-2015:

1. mentre la sicurezza ‘condivide’ oltre un terzo della sua variazione con il fattore robustezza, le relazioni con gli altri fattori di salute risultano ‘deboli’ (condivisione, in generale, pari a meno del 7% della loro varianza); ciò significa che le violazioni delle pratiche di coding e sviluppo che ne riducono la robustezza incidono in modo determinante sulla sicurezza del software, mentre la relazione tra la minor sicurezza del software e le violazioni sul fronte di prestazioni, variabilità e trasferibilità non è poi così ‘forte’;
   Figura 2 – I fattori che contribuiscono a definire il Total Quality Index – fonte: Cast
2. il fattore prestazioni ha ‘relazioni deboli’ con gli altri fattori di salute condividendo solo tra il 5 e il 14% delle variazioni con gli altri elementi. “Tipicamente gli sviluppatori hanno sempre creduto che attributi strutturali volti a migliorare ed accrescere le performance potessero in qualche modo influenzare negativamente gli altri fattori”, si legge nel report, “ma i risultati temperano tale convinzione”. Questo non significa, ovviamente, che si possano tenere bassi i punteggi delle performance (ciò che è stato preso in esame, in questo caso, è l’influenza dei fattori sugli altri nella loro variazione);
3. il Tqi è maggiormente e fortemente influenzato dalla combinazione tra i fattori robustezza, variabilità e trasferibilità. Questi tre elementi, infatti, condividono tra il 56 ed il 72% delle loro variazioni (si influenzano quindi in modo significativo), mentre prestazioni e sicurezza condividono con gli altri fattori ed incidono sul Tqi in percentuali minori (tra il 32 e il 37%);
4. i cinque fattori di salute della qualità strutturale del software hanno poche relazioni dirette con le dimensioni dell’architettura applicativa e con il numero delle linee di codice (le loro variazioni incidono sul codice meno del 5%). In realtà, questa ‘relazione’ varia a seconda del tipo di linguaggio: nel campione di applicazioni sviluppate in Java-EE, per esempio, benché vi siano ‘relazioni deboli’ tra le dimensioni ed il fattore prestazioni emerge al contrario un’influenza diretta e abbastanza significativa con il fattore robustezza (al crescere delle dimensioni dell’applicazioni diminuisce il punteggio sulla salute della sua robustezza); nel campione di applicazioni scritte in Cobol, invece, la relazione più significativa tra le dimensioni del software ed il fattore di salute più influenzato riguarda la sicurezza (in particolare, questa diminuisce quando si superano i 3 milioni di linee di codice).

Il peso dei linguaggi e delle metodologie

Nel Crash Report sono riportate tutte le analisi condotte in modo dettagliato su ogni singolo linguaggio di programmazione, su ciascuna tipologia di azienda (in base al settore industriale di appartenenza) e in base alle strategie adottate in tema di sviluppo e testing delle applicazioni (framework metodologici adottati, scelte di outsourcing, ecc.). Di seguito forniamo una sintesi delle principali evidenze emerse:

1. linguaggi di programmazione: il fattore sicurezza risulta quello con il punteggio più elevato nei linguaggi di programmazione Cobol e Abap, elemento che evidenzia quanto questi linguaggi siano ancora utilizzati per lo sviluppo di applicazioni specifiche del settore finanziario. Nei linguaggi C, C++, Oracle Forms e Asp il fattore di salute con il punteggio più elevato risulta essere quello delle performance (accanto al quale figura la sicurezza) mentre ottengono una valutazione minore variabilità e trasferibilità che hanno punteggi più bassi anche nel linguaggio Oracle Erp/Crm. L’evidenza più significativa relativa a Java-EE riguarda i costi relativamente bassi inerenti la trasferibilità del software.
2. framework metodologici: nelle organizzazioni dove la maturità del CMMI (Capability Maturity Model Integration) è a livello 1, le applicazioni sviluppate, in linea di massima, ottengono punteggi minori su tutti e cinque i fattori di salute rispetto alle aziende dove la metodologia ha invece raggiunto un livello di maturità superiore (livello 2 e livello 3). A risultare particolarmente impattati dal livello di maturità del framework sono i fattori robustezza e sicurezza. Gli impatti delle metodologie di sviluppo sui punteggi dei fattori di salute delle applicazioni sono minori rispetto a quelli dei framework di processo (come CMMMI), tuttavia hanno comunque una certa rilevanza dato che, lungo i cinque fattori ed in uno scenario generale che mostra un mix ibrido di metodologie Agile e Waterfall in uso, i punteggi più elevati e lo stato di salute generale migliore emergono nelle applicazioni sviluppate con metodologie Agile.
3. le scelte di sourcing: la tipologia di azienda, le sue dimensioni o l’appartenenza ad un settore piuttosto che ad un altro sembrano avere poco peso rispetto allo stato di salute generale di un’applicazione dal punto di vista della sua qualità strutturale, fermo restando, come accennato, che in certi segmenti come quello finanziario vengono utilizzati linguaggi di programmazione che mostrano maggiori livelli di sicurezza e performance. Dal Crash Report non emergono infine particolari correlazioni nemmeno con le scelte di sourcing; i fattori di salute più impattati, con punteggi minori, in opzioni di outsourcing sono variabilità e robustezza ma con risultati tutto sommato non troppo significativi. “Sono molto più significative le metodologie ed i processi in uso piuttosto che i ‘luoghi’ dove le applicazioni sono sviluppate”, scrivono gli analisti a chiusura del report.