Tradizionalmente, il concetto di qualità si definisce come la corrispondenza di un prodotto (o di un servizio) alle specifiche secondo le quali è stato progettato e realizzato. Questa definizione ha il grande vantaggio di essere semplice e quindi facilmente applicabile in un qualsiasi processo di controllo e gestione aziendale ma considera la qualità solo in quanto relativa a dati (di progetto e realizzazione) esterni al prodotto, trascurando l’esistenza di una qualità intrinseca che prescinde dalle specifiche di cui sopra, ma in difetto della quale anche la risposta del prodotto a queste stesse specifiche viene inficiata. Per quanto riguarda i prodotti software bisogna quindi distinguere tra qualità funzionale, che investe la correttezza con la quale il prodotto soddisfa alle specifiche previste in sede di progetto, realizzazione e messa in opera, e qualità strutturale. Quest’ultima si riferisce a proprietà intrinseche dell’architettura e del codice che permettono al prodotto di rispondere con maggiore o minore efficienza e affidabilità alle specifiche di cui sopra, ed è un fattore critico poiché, sebbene sia la causa più frequente dei problemi relativi alle operazioni (degrado delle prestazioni, interruzione del servizio, corruzione dei dati, accessi illegali e così via) è difficile da individuare tramite i normali test.
Lo scorso anno Cast Research Labs [1], ha pubblicato il primo di una serie di report, previsti in seguito a cadenza annuale, sulla qualità strutturale delle applicazioni business allo scopo di fornire sul tema una base di discussione oggettiva e fondata sull’esperienza. Lo studio [2] si basa sull’analisi di 288 applicazioni, per un totale di 108 milioni di linee di codice e 3,4 milioni di function-points, che 75 organizzazioni operanti in otto settori diversi (energia, consulenza It, finanza, assicurazioni, tecnologia, telecomunicazioni, manifatture, enti governativi) hanno sottoposto a Cast perché venissero, appunto, esaminate nelle loro caratteristiche strutturali. Gli ambienti di sviluppo delle applicazioni considerate sono cinque: Cobol, Oracle 4GL, .Net, Java EE, C/C++, mentre la dimensione varia da 10 mila a 5 milioni di linee di codice (con un terzo fra 50 e 150 mila). Per quanto non si possa considerare rappresentativo dell’intero universo degli applicativi aziendali, si tratta del più grande campione di applicazioni che sia mai stato studiato e misurato a fronte di un ampio spettro di caratteristiche strutturali di diverse tecnologie.
Le caratteristiche strutturali sulle quali si è concentrato lo studio sono quattro: robustezza, prestazioni, sicurezza e modificabilità. Le violazioni alle ‘good practices’ di architettura e codifica sono state individuate e aggregate secondo algoritmi che ne valutano la gravità intrinseca e la rilevanza rispetto a ciascuna delle quattro caratteristiche considerate. Lo scopo finale di tale analisi era di dare una risposta alle seguenti domande:
1) quanto pesano i difetti insiti nel codice sul cost-of-ownership dell’applicazione;
2) quali sono le migliori tecnologie e settori d’industria sul fronte della sicurezza;
3) quale tecnologia di sviluppo presenta il maggior numero di problemi strutturali che possono degradare le prestazioni;
4) in quale settore d’industria le applicazioni sono più difficili da mantenere e modificare;
5) se c’è un rapporto tra la dimensione e la qualità delle applicazioni;
6) quali sono le più frequenti violazioni alle best-practices architetturali e di codifica.
Qui di seguito, e nello stesso ordine, diamo una sintesi delle risposte ottenute; o meglio, degli elementi emersi in merito a questi argomenti.
Costi – Il costo del lavoro richiesto per ovviare ai problemi di un prodotto software già rilasciato e operativo prende il nome di “debito tecnologico”. Come i debiti finanziari, i debiti tecnologici hanno un interesse passivo dato dai costi extra che la manutenzione di un’applicazione strutturalmente difettosa esige. In base alle informazioni raccolte, Cast ha elaborato una formula empirica [3] che consente di stimare il debito tecnologico di un’applicazione in funzione dei difetti strutturali del codice sorgente. Si è quindi potuto calcolare un costo medio di 2,82 dollari per linea di codice, che per le 374 mila linee dell’applicativo medio del campione porta a un totale di oltre un milione di dollari per ogni applicazione. Il debito tecnologico è quindi una delle voci principali del cost-of-ownership del software, che assorbe gran parte del budget It. Non tutte le piattaforme di sviluppo portano, però, a debiti tecnologici uguali: quanto è più alto il livello di astrazione della tecnologia adottata tanto è più basso il rischio per lo sviluppatore di commettere errori, dato che molti compiti di basso livello sono svolti dalla piattaforma sottostante (figura 1).
Figura 1 – Analisi dei costi extra per la manutenzione di un'applicazioni strutturalmente difettosa
Sicurezza – I livelli di sicurezza rilevati nel campione sono distribuiti in modo molto più ampio che per le altre caratteristiche, il che suggerisce come l’attenzione alla sicurezza sia notevolmente diversa riguardo al tipo di applicazione e al settore d’industria. Gli applicativi più sicuri sono concentrati, come prevedibile, presso le società di servizi finanziari, mentre negli altri settori una maggior attenzione alla sicurezza sarà spinta dagli obblighi di conformità normativa. Sul lato tecnologico dominano gli applicativi per mainframe, meno esposti ai rischi dei servizi aperti al Web, e il ‘vecchio’ Cobol, che risulta nettamente più sicuro di ogni altro ambiente di sviluppo (figura 2).
Figura 2 – Livelli di sicurezza per tecnologie
Prestazioni – Al pari dei livelli di sicurezza, anche quelli relativi alle prestazioni sono largamente distribuiti nel campione. Ciò può essere legato alla diffusione degli strumenti di testing automatico, che sebbene non scoprano i problemi a livello di codice evidenziano i colli di bottiglia che rallentano l’esecuzione dei programmi. Le prestazioni sono, inoltre, un punto sul quale gli utenti finali sono molto sensibili, dato che ne abbassa la produttività, per cui la soluzione dei relativi problemi diventa prioritaria rispetto ad altri aspetti della qualità. Riguardo alle tecnologie, le applicazioni in Java EE risultano meno performanti rispetto ad altri linguaggi (figura 3). Anche .Net presenta la stessa tendenza, sebbene meno pronunciata, il che fa credere che ciò possa essere dovuto alla modularità tipica di questi nuovi linguaggi.
Figura 3 – Performance delle applicazioni in relazioni agli ambienti di sviluppo
Manutenzione – La facilità con la quale un’applicazione può essere mantenuta e si presta ad essere modificata è un fattore chiave del suo cost-of-ownership, ma lo studio dimostra come, accanto ad applicativi aventi buone doti di modificabilità, vi sia un’ampia presenza di soluzioni rigide e difficili da mantenere (figura 4). L’analisi per settori d’industria evidenzia come queste applicazioni siano concentrate, negli Usa come in Europa, nella pubblica amministrazione, il che spiega come la Pa spenda in manutenzione il 73% del budget It [4], più di ogni altro settore. Questa situazione può essere in parte dovuta all’outsourcing applicativo, che nel settore pubblico ha una presenza del 75% rispetto al 51% del privato. Va detto però che eliminando la Pa dal campione, la differenza fra applicazioni mantenute all’esterno e in casa è irrilevante. Quindi non è l’outsourcing, in sé, la causa della rigidità ma come questo viene attuato nel settore pubblico.
Figura 4 – Livello di facilità e rapidità di modifica delle applicazioni
Dimensioni – Contrariamente a un’opinione diffusa, la qualità di un applicativo non scade con l’aumentare delle sue dimensioni: il Total Quality Index (che comprende robustezza, prestazioni, sicurezza e modificabilità) non ha relazione significativa con le dimensioni delle applicazioni esaminate. Con una sola eccezione: nelle applicazioni Cobol il rapporto tra dimensioni e qualità è evidente e negativo (figura 5). Ciò dipende dal fatto che il Cobol è un linguaggio che non aiuta la modularità ma porta a costruire componenti complesse in modo molto più spiccato che altri linguaggi (figura 6).
Figura 5 – Correlazione tra qualità software e dimensione delle applicazioni sviluppate in Cobol
Figura 6 – Percentuale di componenti ad elevata complessità nelle applicazioni in relazione aggli ambienti di sviluppo
(cliccare sull'immagine per visualizzarla correttamente)
Errori – Tra gli errori degli sviluppatori, quello che compare con maggiore frequenza e continuità è l’uso dello statement Goto [istruzione che consente di effettuare salti incondizionati da un punto all’altro del codice ndr]. Già considerato pericoloso 40 anni fa per la tendenza a rendere i programmi inutilmente complessi e fragili, sebbene la maggioranza dei linguaggi di programmazione l’abbia eliminato, il Goto continua ad essere usato nei vecchi linguaggi e specialmente nel Cobol, dove ce n’è in media uno ogni 100 linee di codice. Dopo il Goto, la più frequente violazione alle buone regole di programmazione è l’uso eccessivo di connessioni ‘a ventaglio’ (fan-out) verso altri componenti. Questa pratica aumenta drasticamente il lavoro necessario per introdurre cambiamenti o migliorie e pesa quindi sul cost-of-ownership dell’applicazione.
Note
1 – Cast Research Labs (Crl) è una società nata per perfezionare l’analisi scientifica del software applicativo al fine di individuare gli aspetti che ne possano migliorare la qualità strutturale. Crl fornisce strumenti di benchmark e consigli pratici agli sviluppatori e alle comunità accademiche e scientifiche interessate. Nel 2007 ha avviato un programma di raccolta delle caratteristiche strutturali relative ad applicazioni custom implementate da grandi organizzazioni in Nord America, Europa e India, realizzando un data-set che ad oggi riguarda oltre 500 applicazioni business e forma la base empirica delle proprie analisi.
2 – Cast Worldwide Application Software Quality Study 2010.
3 – I criteri e i parametri di costo adottati, che permettono di stimare il debito tecnologico tarando la formula sulla propria realtà ed esperienza, sono descritti in dettaglio nel documento citato.
4 – Fonte: Gartner 2010 It Staffing & Spending Report
Partecipa alla community