Introduzione
Negli ultimi anni il mondo dell’ICT ha subito un cambiamento notevole per quanto riguarda l’evoluzione delle architetture passando dalle normali architetture J2EE, ad architetture distribuite dove si rilasciano “servizi” sulla rete, grazie ai quali le applicazioni possono espandere le proprie funzionalità senza sapere dove e come questi servizi vengano erogati, fino alle attuali architetture a microservizi, erogate tramite cloud-container.
Tale innovazione tecnologica non ha “de facto” diminuito la necessità delle organizzazioni di avere un software di qualità, anche al fine di contenere i costi complessivi dell’IT; anzi, questa esigenza si è andata incrementando vista l’esigenza del mercato che esige software di elevata qualità a costi sempre più contenuti.
Le soluzioni di CAST MRI forniscono una risposta a questa esigenza garantendo una misurazione del software efficace in breve tempo e con effort di attuazione molto basso.
Relazione tra Violazioni e Costi del Software
Come noto, CAST MRI rileva le violazioni del codice analizzato sia delle weakness architetturali e di coding incluse nelle CISQ Structural Quality Measures, sia di quelle considerate dalla ISO 5055, correlati a degli aspetti di sicurezza e di qualità del software, mappabili, sul modello delle medesime caratteristiche proposto dalla ISO/IEC 25010:2011.
Detto metodo prevede che ad ogni violazione sia associato un peso, e la modalità di calcolo dell’indicatore complessivo è esemplificata come segue.
L’utilizzo di questo approccio, unito a processi di misura di gestione delle violazioni rilevate, la cui definizione può essere supportata dalla CAST Advisory, consente un significativo risparmio dei costi legati alla risoluzione delle violazioni, in funzione della fase del ciclo di vita del software nel quale vengono individuate.
Consideriamo la curva di distribuzione degli errori, indicata dal NIST nel Report The Economic Impacts of Inadeguate Infrastructure for Testing, in un generico SDLC (Software Development Life Cycle)
Figura 1 - Curva di distribuzione degli errori nelle fasi del ciclo di vita del sofware
Fissando ad “X” il costo di risoluzione di una violazione, possiamo stabilire una tabella di discretizzazione dei costi di fixing in relazione alla fase del Ciclo di Vita o del Ciclo di Manutenzione del Software, di cui riportiamo una esemplificazione: 
Tabella 1 - Coefficiente correttivo del costo di una violazione per fase. Fonte: Gufpi-Isma - Metriche del software: Esperienze e ricerche - Franco Angeli Ed. - §Evoluzioni delle metriche per la Qualità del Software (M. Argiolu)
Combinando la curva di distribuzione degli errori con la Tabella 1, relativa ai fattori correttivi dei costi di violation fixing, otteniamo un grafico che indica i costi della mancanza di qualità in funzione di dove vengono individuate le violazioni stesse nel codice.
Figura 2 - Discretizzazione della curva di distribuzione dei costi delle violazioni per fase
La rilevazione costante delle violazioni, come per esempio accade presso alcuni clienti CAST, presso i quali detta rilevazione ha frequenza giornaliera, consente di anticipare l’individuazione e la risoluzione degli errori nel software, abbattendone notevolmente i costi. Una possibile quantificazione è espressa dal grafico che segue.
Figura 3 - Curva discretizzata dell’abbattimento dei costi delle violazioni per fase
Assumendo che il numero delle violazioni introdotte sia costante, l’esempio proposto indica che il costo di una violazione introdotta nella fase di codifica ed individuato nella fase di integration/system test può decrescere da C0 a C1; tale riduzione è possibile tramite la sopramenzionata adozione di un processo di misurazione che effettui la rilevazione delle violazioni; detto processo, che si suggerisce sia il più possibile automatizzato, consente, sia il decrescere dell’intervallo di tempo tra l’individuazione e la risoluzione delle violazioni, sia un incremento del 15-20% del numero di violazioni individuate nelle fasi antecedenti quelle di test/collaudo.
Il L’OMG nel suo documento Automated Technical Debt Measure fornisce una stima dell’effort di risoluzione unadjusted delle singole violazioni ossia l’effort necessario alla risoluzione di una violazione in un generico codice sorgente indipendentemente dal contesto e dalle condizioni del SDLC, per ogni singolo pattern di misura automatica che riportiamo di seguito per comodità:
- Automated Source Code Reliability Measure
- Automated Source Code Security Measure
- Automated Source Code Performance Efficiency Measure
- Automated Source Code Maintainability Measure
Questo consente di avere a disposizione tutti gli elementi necessari alla corretta quantificazione dell’abbattimento dei costi di risoluzione di una violazione, in funzione della fase del SDLC nella quale viene individuata e risolta.
Relazione tra Misurazione e Costi del Software
L’utilizzo appropriato dello strumento, cioè al termine delle fasi del SDLC aventi il coefficiente correttivo del costo di una violazione più basso (cfr. Tabella 1) consente di minimizzarne il costo complessivo; pertanto, applicando la misurazione con CAST MRI in due momenti distinti, seguendo un canonico Gate Quality Model è possibile anticipare l’individuazione e la risoluzione della violazione
La Figura 4 schematizza la relazione tra il Gate Quality Model, spesso proposto dalla struttura di Advisory di CAST, e il coefficiente correttivo.
Figura 4 - Gate Quality Model e Coefficiente correttivo del costo della violazione individuata
Questo modello, altresì, consente di avere a disposizione un Action Plan relativo alle violazioni individuate in ciascuna fase del SDLC; di conseguenza, è possibile prevedere quale sia il costo effettivo della risoluzione delle violazioni che sono state comunque portate in collaudo e/o in esercizio.
Comments: