Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Applicazioni: metodologie e tecnologie per svilupparle e mantenerle in salute

pittogramma Zerouno

Tech InDepth

Applicazioni: metodologie e tecnologie per svilupparle e mantenerle in salute

27 Set 2017

di Giorgio Fusari

Un rapporto della società Cast traccia lo scenario sui trend globali che caratterizzano la qualità strutturale del software per applicazioni business, soffermandosi sull’analisi di cinque fattori determinanti che ne condizionano il risultato. La ricerca fornisce anche alcune valide linee guida per elevare il livello della qualità strutturale, attraverso il presidio di alcuni aspetti strategici, sia tecnologici, sia organizzativi

Per tenere sotto controllo la qualità strutturale del software, e migliorarlo, è necessario:

  • 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.

Figura 1 – I ‘fattori di salute’ del software – fonte: Crash Report 2017 di Cast

Crash Report 2017: i cinque fattori di qualità

La dettagliata ricerca è stata condotta da Cast, società di primo piano a livello globale nella fornitura di strumenti di analisi e misura del software, e si chiama Crash (Cast Research on Application Software Health) Report 2017: il rapporto si occupa di fare il punto sul livello di salute del software enterprise, 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.

Figura 2 – Le tecnologie analizzate nel campione della ricerca Crash – fonte: Crash Report 2017 di Cast

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).

Campione della ricerca

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à strutturale

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.

Figura 3 – Qualità strutturale: cresce con la maturità organizzativa – fonte: Crash Report 2017 di Cast

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.

Giorgio Fusari
Giornalista

Nel settore giornalistico dal 1989, Giorgio Fusari negli anni ha collaborato per numerose pubblicazioni nel panorama tecnologico e ICT italiano, tra cui la rivista NetworkWorld Italia (gruppo IDG); il settimanale di tecnologia @alfa, del quotidiano Il Sole 24 Ore, la testata Linea EDP. Dal 2012 collabora con il gruppo Digital360 e in particolare con ZeroUno. Tra le aree di maggior specializzazione di Giorgio, il crescente universo dei servizi cloud, il networking, le tecnologie di cybersecurity.

Articolo 1 di 4