Qualità del software: metodologie e tecnologie per garantirla

Come tenere sotto controllo la qualità del software e migliorarlo per adeguarlo alle esigenze degli utenti? Ecco una sintesi delle principali cose da sapere.

Come essere certi della qualità del software

• Porre maggior attenzione al tipo di tecnologia e applicazione utilizzate;
• attenersi alle pratiche di codifica sicure adottando un approccio di security by design;
• concentrarsi sulla maturità e sull’integrazione delle metodologie di sviluppo;
• controllare costantemente le violazioni delle regole che possono mettere a rischio la qualità del codice sorgente;
• far diventare le pratiche di miglioramento della qualità del codice processi metodici, reiterati con sistematicità.

Questi, in sintesi, i punti strategici da presidiare, così come risulta da una corposa indagine che ha avuto l’obiettivo di comprendere quali siano attualmente i trend globali sulla qualità strutturale del software e delle applicazioni IT sviluppate nel mondo. Da premettere che con l’espressione ‘qualità strutturale’ lo studio si riferisce soprattutto alla solidità di ingegnerizzazione dell’architettura e alla ‘sanità’ di codifica di un’applicazione, piuttosto che alla correttezza con cui vengono implementati i requisiti funzionali richiesti dall’utente.

I cinque fattori della qualità del software

Partiamo da una dettagliata ricerca condotta da Cast nel 2017, e nei suoi tratti essenziali qui riassunto tutt’oggi valida, (Crash (Cast Research on Application Software Health) Report 2017): il rapporto si occupa di fare il punto sul livello di salute del software enterprise e qual è il suo valore dal punto di vista del business, misurando la sua qualità strutturale sulla base di alcuni benchmark e parametri di riferimento o, se si preferisce, di cinque ‘fattori di salute’ o caratteristiche fondamentali della qualità strutturale, che vengono identificate con robustezza, sicurezza, efficienza delle prestazioni, trasferibilità, modificabilità.

In sostanza, la qualità strutturale è misurata individuando le violazioni delle regole che rappresentano le buone pratiche architetturali e di sviluppo del codice in ciascuna di queste cinque aree nevralgiche. Vediamo quindi di definirle meglio.

1. Il fattore robustezza misura la probabilità di interruzioni, la difficoltà di ripristino e la possibilità di corruzione dei dati, legati a pratiche di codifica mediocri.
2. Il fattore sicurezza misura invece le violazioni di metodologie di codifica sicure che aprono la strada ad accessi non autorizzati, interazioni ingannevoli, furti di dati, o rotture della riservatezza.
3. L’efficienza è il fattore di salute che misura la probabilità di una potenziale degradazione delle prestazioni, e di utilizzo inefficiente delle risorse (processori, memoria, reti), ancora una volta causati da metodologie scadenti di sviluppo del codice.
4. Il fattore modificabilità misura la difficoltà di modificare le applicazioni, aggiungere funzionalità, correggere errori o cambiare l’ambiente dell’applicazione.
5. Infine, per trasferibilità si intende il fattore che misura la difficoltà di trasporto del lavoro o la difficoltà di comprensione dell’applicazione e di diventare produttivi nel lavorare con essa.

I punteggi per questi cinque fattori di salute sono calcolati su una scala da 1 (basso/mediocre) a 4 (elevato/buono), in base alla quale analizzare l’applicazione per identificare violazioni di oltre 1200 regole di buone metodologie architetturali e di codifica.

Miglioramento del software: le raccomandazioni chiave

Prima di illustrare il campione di riferimento, come è stata condotta la ricerca ed entrare maggiormente nel merito di alcuni specifici aspetti salienti dello studio, vale la pena evidenziare subito quali preziose raccomandazioni per i team di sviluppo emergano dai risultati di sintesi del rapporto di Cast.

1. Per ottenere informazioni precise e utili su prestazioni comparabili, le attività di benchmarking e valutazione del software dovrebbero essere condotte nell’ambito della categoria tecnologica e del tipo di applicazione specifiche. Infatti, i risultati derivanti dall’analisi comparativa eseguita puramente rispetto al tipo di settore industriale possono risultare fuorvianti, a causa degli effetti di altri fattori, con più grande influenza, che possono variare all’interno delle organizzazioni.
2. Va riservata maggior attenzione alle pratiche di codifica sicure, poiché in questo ambito molte applicazioni hanno ottenuto punteggi inaccettabilmente bassi. Infatti, i punteggi relativi alla categoria ‘security’ hanno mostrato variazioni più ampie di quelli di ogni altro fattore di salute.
3. La terza raccomandazione riguarda il fatto che, per migliorare i punteggi sui fattori di salute, le organizzazioni devono migliorare la maturità dei loro processi e metodologie di sviluppo. Le organizzazioni a bassa maturità hanno infatti segnato, in maniera costante, punteggi più bassi nei fattori di salute.
4. È consigliabile adottare metodologie ibride per lo sviluppo di applicazioni ‘business-critical’, perché i metodi ibridi hanno ottenuto punteggi più elevati nei fattori di salute rispetto a entrambe le metodologie ‘agile’ e ‘waterfall’, integrando la pianificazione dell’analisi architetturale con rapidi feedback sulla qualità.
5. È preferibile evitare la creazione di team formati da oltre 20 sviluppatori; le squadre costituite da meno di dieci membri appaiono essere quelle ottimali.
6. Nel considerare strategie come quelle di outsourcing o offshoring, è bene prestare attenzione ai fattori che hanno mostrato di influenzare la qualità strutturale, come la maturità organizzativa, la metodologia di sviluppo o la dimensione del team, dal momento che tali fattori hanno maggiore influenza rispetto ad altri, come la fonte (in-house, outsourcing) o il luogo di sviluppo (offshore, onshore).
7. È importante analizzare il codice sorgente su una base regolare prima di rilasciarlo, per identificare violazioni delle regole di qualità che mettono a rischio le operation o i costi. Le violazioni a livello di sistema sono le più critiche, poiché sono molto più costose da risolvere, e possono richiedere svariati cicli di rilascio prima di essere completamente eliminate.
8. È necessario concepire il miglioramento della qualità strutturale come un processo iterativo, da perseguire attraverso numerosi rilasci del software per raggiungere le soglie di qualità ottimale.

Due livelli di regole di qualità

Un aspetto essenziale nella valutazione della qualità strutturale del codice è dividere le regole di qualità in due livelli di analisi: le regole a livello di codice, e le regole a livello di sistema. Le prime, chiarisce Cast, sono regole valutate a livello di unità di codice (per esempio dentro una classe, un metodo, una sub-routine, un modulo) e le violazioni in questo ambito tipicamente implicano problemi di ‘igiene’ della codifica e semplici difetti.

Le regole a livello di sistema, invece, sono regole architetturali la cui valutazione coinvolge molteplici componenti, spesso distribuiti a diversi livelli dell’applicazione. Le violazioni in questo ambito sono difficili o impossibili da individuare attraverso le normali attività di testing, ma tipicamente sono le colpevoli di interruzioni, falle di sicurezza, corruzione di dati, e difficoltà di supporto o espansione dell’applicazione (scaling).

I dati utilizzati come campione per le analisi elaborate nel rapporto Crash provengono da Appmarq, il repository digitale di Cast, che la società indica come il più grande database su sistemi IT reali, contenente dati raccolti durante analisi strutturali, a livello di sistema, di grandi applicazioni IT. Il repository include 1.850 applicazioni presentate da 329 organizzazioni per la successiva analisi. Applicazioni che nel complesso hanno totalizzato 1,03 Bloc (billion lines of code), ossia oltre un miliardo di linee di codice. Le organizzazioni partecipanti alla ricerca sono localizzate principalmente in Europa continentale (Francia, Belgio, Italia, Germania, Spagna), Regno Unito, Nord America (Stati Uniti e Canada) e India. Dal punto di vista tecnologico, il campione include applicazioni scritte principalmente in Cobol, Java-EE, .NET, Oracle Server e altre tecnologie, come PHP, C/C++, PowerBuilder, C# e Visual Basic.

In termini di dimensioni dell’applicazione, la soglia minima per accettare applicazioni nel campione è stata di 10 Kloc (kilo o migliaia di linee di codice), per poi salire, e arrivare fino ad applicazioni contenenti più di un Mloc (million lines of code).

Parlando di sviluppo del codice, le tecnologie utilizzate con maggior frequenza nel campione di Crash sono Java-EE (40%) e Cobol (22%).

Dal punto di vista dei segmenti industriali, il campione include applicazioni delle 329 aziende in dodici settori: servizi finanziari, assicurazioni, telecomunicazioni, manufacturing, consulenza IT, energia, utility, pubblica amministrazione, retail, fornitori di software, prodotti farmaceutici, media.

Infine, a livello di tipologie di applicazioni, i tipi di sistemi che figurano con maggior frequenza nel campione sono i sistemi transazionali core (core transaction systems) e i sistemi ERP (enterprise resource planning).

Fattori chiave che influenzano la qualità del software

La dimensione di un’applicazione è risultata avere effetti trascurabili o nulli sulla sua qualità strutturale. Quest’ultima risulta, invece, manifestare significative differenze quando si vanno a comparare le tecnologie di sviluppo: su questo piano, infatti, Cobol e Oracle Server generalmente ottengono i punteggi più bassi, mentre la tecnologia JEE (Java-EE) raggiunge i punteggi più elevati. L’effetto della tecnologia sulla qualità strutturale risulta comunque più forte di quello del settore industriale a cui appartiene l’applicazione. Ancora, la tecnologia utilizzata nello sviluppo del sistema applicativo può essere più importante del tipo di sistema stesso (sistema transazionale core, ERP, sito web, portale, CRM, applicazione analitica) nel determinare i suoi punteggi nei fattori di salute.

Maturità organizzativa: è determinante

Riuscire a trasformarsi da organizzazione ‘indisciplinata’ in azienda innovativa e matura nei processi di sviluppo fa la differenza quando si tratta di raggiungere la qualità strutturale del software. Un grado di maturità di cui Cast misura l’evoluzione utilizzando il modello CMMI (Capability Maturity Model Integration), suddiviso in tre livelli.

Al Livello 1 (rischio incontrollato) si trovano le organizzazioni in cui pianificazione e disciplina mediocri creano tempistiche di progetto insostenibili, che portano gli sviluppatori a produrre eccessivi difetti nel software, con poco tempo per identificarli.

Al Livello 2 (rischio limitato) si pongono le organizzazioni in cui i progetti vengono condotti con proprie metodologie, ma dove impegni e linee di base dei progetti sono gestiti per far sì che gli sviluppatori abbiano tempo per eseguire un lavoro di qualità.

Al Livello 3 (rischio controllato) si collocano le organizzazioni in cui i progetti utilizzano standard e processi organizzativi creati attraverso metodologie di cui gli sviluppatori si fidano per fornire sistemi di elevata qualità.

Non stupisce quindi che le applicazioni sviluppate nelle organizzazioni al Livello 1 del CMMI, in cui si commettono molti errori, senza tempo sufficiente per correggerli, abbiamo registrato punteggi più bassi di quelle create nelle organizzazioni di Livello 2, dove le attività di sviluppo sono più disciplinate e la qualità strutturale del software migliora, o del Livello 3, in cui si applicano le migliori pratiche, implementando le capacità del Livello 2 e integrandole in processi organizzativi standard.

Figura 4 – Metodo di sviluppo ibrido: la strada migliore verso la qualità – fonte: Crash Report 2017 di Cast

Metodologia di sviluppo ‘ibrida’, la scelta vincente

Parlando di pratiche di codifica, i punteggi più elevati per la qualità strutturale del software sono stati ottenuti dalle metodologie di sviluppo ibride: infatti, le differenze nei fattori di salute tra metodi di sviluppo ‘agile’ e ‘waterfall’ sono state minime, con entrambi che hanno segnato punteggi più bassi dei metodi ibridi, che risultano dalla combinazione della pianificazione e progettazione dell’architettura dell’applicazione, con rapidi feedback sui difetti, feedback che vengono reiterati lungo il ciclo di design. Ciò infatti consente agli sviluppatori di indirizzare in anticipo i problemi di qualità del sistema e a livello architetturale, e di identificare in maniera più accurata gli inconvenienti, già mentre stanno sviluppando il codice.

Software intelligence: una priorità per i CIO

Un altro report di riferimento è Software Intelligence Report – CIO Priorities in the Digital Age pubblicato quest’anno sempre da Cast che ha sondato i pareri di 500 IT leader (includendo fra questi 150 CIO, 125 software architect e 125 sviluppatori di applicazioni, in organizzazioni di medie e grandi dimensioni) riguardo gli obiettivi della tecnologia e la loro abilità di soddisfare tali obiettivi sulla base della Software Intelligence cui possono attingere, rispetto ai portfoli software esistenti.

Tra le principali conclusioni dello studio non solo emerge che i CIO non posseggono una visibilità adeguata sulla progettazione software per prendere decisioni valide sugli asset IT aziendali, ma anche che i reparti dei sistemi informativi non sono in grado di prevenire i rischi operativi, correggendo i difetti strutturali troppo tardi perché non ci sia un rallentamento nel processo di digitalizzazione.

Un aspetto interessante della survey, infatti, rileva che non sussistono carenze in termini di capacità tecnologiche; quando il business richiede soluzioni che implicano competenze anche tecnologicamente avanzate, i team IT sono in grado di svilupparle. Quello che manca, invece, è un’analisi chiara e coerente che sia in grado di esplorare a fondo i sistemi software, critici per le business operation.

In particolare si identificano due principali sfide: da un lato la prevalenza di sistemi legacy, ereditati nel tempo, che ancora supportano le business operation nevralgiche all’interno dell’organizzazione; dall’altro l’esistenza di dati incongruenti sulle attività di progettazione e manutenzione del software.

Qualità del software e ISO 9126, ecco cosa dice

ISO (Organizzazione internazionale per la normazione) in collaborazione con l’IEC (Commissione Elettrotecnica Internazionale), preposte a descrivere un modello di qualità del software, hanno collaborato alla redazione delle normative e linee guida ISO/IEC 9126.

Ne è emerso un modello che suggerisce un approccio alla qualità che i vendor possono adottare per migliorare i propri processi e, di conseguenza, la qualità del software da loro prodotto.

Gli aspetti tecnici trattati dalla normativa riguardano, oltre al modello di qualità del software classificato da 6 caratteristiche (funzionalità, affidabilità, efficienza, usabilità, manutenibilità e portabilità) le metriche per la qualità esterna (che misurano i comportamenti del codice su base di test, sull’osservazione dell’esecuzione eccetera); le metriche per la qualità interna (che si applicano al software non eseguibile, per esempio il codice sorgente, durante le fasi di progettazione e codifica); le metriche per la qualità in uso, ossia il punto di vista dell’utilizzatore del software stesso.