“Non si può gestire ciò che non si può misurare”. Così Carlo Capeccia, Industrial Capability of Software Technology Engineering per la Divisione Land & Naval Defence Electronic Division di Leonardo (ex Finmeccanica, realtà storica italiana nei settori aerospazio, difesa e sicurezza), sintetizza uno degli obiettivi del progetto avviato dalla multinazionale italiana, e tuttora in corso, per la standardizzazione e il miglioramento della qualità dello sviluppo software. Capeccia ha illustrato il progetto nel corso della 15ma Conferenza Internazionale ISMA svoltasi a Roma lo scorso 11 maggio e organizzata da IFPUG (International Function Point User Group).
Who's Who
Carlo Capeccia
Il contesto: la Divisione che produce software e sistemi utilizzati in ambito militare per il comando e la comunicazione con le forze di terra e navali, “è quello di una realtà che nasce dall’acquisizione di società differenti, ciascuna con propri processi di sviluppo, KPI, metriche e tool per le analisi del codice sorgente – spiega Capeccia -. Una situazione confusa, non sostenibile in una realtà high-tech come la nostra, tra i principali player nel settore aerospaziale, Difesa e Sicurezza [Leonardo ha oggi circa 50 mila dipendenti, uffici e impianti in 180 siti nel mondo, ndr]. Con la nascita, tre anni fa, della Land & Naval Defence Electronic Division si è quindi deciso di standardizzare i processi di engineering, adottando KPI e metriche comuni per la misurazione della qualità del software, garantendo più uniformità strutturale e funzionale delle soluzioni rilasciate”.
Per affrontare il problema, Leonardo ha scelto l’adozione della piattaforma IBM Rational a supporto dell’engineering delle applicazioni e del software che è parte integrante dei suoi sistemi: “In questo modo è possibile supportare tutte le fasi dello sviluppo software e ottenere informazioni più affidabili e coerenti dai vari processi. Rational consente inoltre di integrare gli altri tool in uso”, precisa Capeccia. Con i tool, la Divisione ha standardizzato anche le notazioni, i metodi di sviluppo e il supporto per la formazione delle persone. Altro aspetto importante è il miglioramento nella documentazione dei processi: “La gestione unificata e integrata delle informazioni ci permette di avere più uniformità tra i contenuti tecnici redatti nei differenti stadi del ciclo di vita del software e quindi disporre di migliori informazioni su requisiti, modelli, test e misure eseguite, oltre che di generare la documentazione secondo gli standard aziendali”. Tra i vantaggi dell’adozione di un sistema più coerente per l’engineering del software, c’è l’automazione dei controlli, la possibilità di fare analisi d’impatto sulle modifiche e il reverse engineering. “In generale rende possibile una migliore governance dello sviluppo e sui processi, facilitando chi deve prendere le giuste decisioni. Sul fronte della produttività, rende possibile riusare requisiti e componenti in progetti diversi, facilitando la condivisione della conoscenza tra team differenti”, spiega Capeccia.
La scelta di piattaforme e metodi per la qualità del software
Uno degli obiettivi più importanti della razionalizzazione avviata da Leonardo nel campo del software engineering riguarda la riduzione dei rischi applicativi legati allo sviluppo software, ossia la capacità di misurare lo stato delle applicazioni esistenti, di eseguire nuove valutazioni in occasione dei cambiamenti nei processi, di monitorare i requisiti e quindi scoprire i difetti nelle prime fasi dello sviluppo, quando i costi per trovare rimedi sono più bassi. “Questo è possibile solo disponendo di parametri e misure per stimare il livello di qualità – spiega Alberto Leardi, Responsabile per la gestione e amministrazione della tool chain per il software engineering della Divisione -. Per questo abbiamo avviato un’indagine di mercato sui tool specifici, adatti a essere integrati nella nostra piattaforma di engineering”.
Who's Who
Alberto Leardi
Tra ottobre e novembre del 2016 è stato realizzato il ‘proof of concept’ caricando e analizzando con i tool di differenti vendor un set di tre applicazioni scritte nei linguaggi comunemente usati in azienda (C++ Java e C#): “Abbiamo valutato i benefici che potevamo ottenere sia dal tool sia dalla metodologia supportata, l’efficacia delle metriche per la riduzione del rischio applicativo – precisa Leardi –, la capacità di trattare applicazioni complesse, costituite da più livelli di business logic, quindi da dati distribuiti e interfacce multiple sia verso gli utenti sia verso altri sistemi. Abbiamo studiato la capacità delle piattaforme di alimentare dashboard informative oltre che di consentire la personalizzazione del modello di analisi con le nostre metriche interne”.
Un aspetto importante della selezione ha riguardato inoltre la capacità di aggiungere regole per assicurarsi che l’applicazione risponda ai requisiti architetturali e di comunicazione previsti. La scelta di Leonardo è caduta su Cast AIP (Application Intelligence Platform) per tutte le funzioni di software assessment strutturale e di qualità. “La piattaforma Cast AIP ha dimostrato di poter analizzare tutti i livelli di un’applicazione complessa – prosegue Leardi -, partendo dall’uso delle best practice nel coding, fino alla rispondenza con gli standard architetturali comprendendo middleware e framework d’integrazione, identificando i problemi nei diversi strati applicativi”.
Il workflow associato con l’uso di AIP prevede l’intervento di tre figure professionali: “Il process manager che registra l’applicazione da analizzare nella platform; il delivery manager che estrae e prepara il codice sorgente per l’analisi e l’administrator che ha il compito di configurare l’acquisizione delle applicazioni”, spiega Leardi.
L’amministratore AIP deve definire ciò che sta alla periferia dell’applicazione: librerie esterne, sistemi operativi e così via. Quindi dà l’avvio al processo di analisi generando i dati che vengono memorizzati e storicizzati nel database centrale, resi disponibili per la fruizione. “Il punto di arrivo è costituito da portali Web e Dashboard analitiche con diversi livelli di navigazione – spiega Leardi -. Il portale per i manager offre indicatori sintetici, quello per i software architect e i responsabili delle applicazioni ha dati più dettagliati. Il sistema permette di ottenere dati categorizzati in modo differente, per valutare fattori come la ‘salute del codice’ o la produttività, che servono per prendere decisioni e gestire il rischio applicativo”.
La roadmap d’implementazione di AIP e i consigli ‘dal campo’
Leonardo ha perfezionato l’acquisizione della piattaforma AIP nel giugno del 2017 e completato l’integrazione nella tool-chain di engineering nel corso del mese di settembre dello stesso anno, facendo formazione agli amministratori e realizzando l’analisi di un primo gruppo di applicazioni. “Tra ottobre e dicembre 2017 è stato analizzato un secondo gruppo di applicazioni e istituito un processo, su base mensile, per il controllo del portafoglio applicativo – spiega Capeccia -. A fine anno è stato redatto il primo rapporto sulla software quality, con i KPI, l’action plan e le guideline per la nostra software community”. Nell’aprile di quest’anno è stata data accelerazione all’analisi delle applicazioni e avviati training dedicati e workshop sulla metodologia Automated Function Point. “Entro il mese di giugno prevediamo di completare la certificazione degli amministratori e di avviare i processi di calibrazione automatica nella piattaforma di qualità – continua Capeccia – Ci interessa realizzare nuovi indicatori, per esempio per rilevare la densità dei difetti non soltanto in funzione della dimensione del codice, ma per Automated Function Point. Entro dicembre prevediamo di aver completato il caricamento e l’analisi della parte rimanente del nostro portafoglio applicativo e realizzato un secondo rapporto sulla software quality”. Seppure non completata, l’esperienza d’implementazione di AIP consente ai manager Leonardo di dare indicazioni utili a chi si avventura in progetti simili: “Il primo consiglio è di operare senza fretta, preoccupandosi degli ‘aspetti culturali’ del cambiamento – spiega Leardi –, partendo da un piccolo team e quindi favorendo la disseminazione dell’esperienza”. L’adozione del metodo Automated Function Point richiede un supporto formativo. Un altro consiglio riguarda l’integrazione. “Facilita il processing automatico del sorgente, mentre l’uso di strutture di repository omogenee minimizza il lavoro di configurazione nel caricamento permettendo di automatizzare i processi di analisi periodica”. Sul fronte organizzativo è importante identificare tutti i soggetti che sono coinvolti sugli aspetti della qualità dello sviluppo a cui indirizzare dashboard e report contenenti le informazioni di specifico interesse.
