Introduzione
Qualora un'organizzazione appalti ad un fornitore esterno gli sviluppi e le manutenzioni (correttive o evolutive che siano) del software applicativo, è necessario inserire contrattualmente dei Service Level Agreement (SLA) che vadano a regolamentare il rapporto che si va ad instaurare tra gli attori.
Al fine di garantire una relazione win-win tra cliente e fornitore è necessario che gli SLA siano misurabili oggettivamente e siano raggiungibili dal fornitore nell’ambito del contesto contrattuale: ad esempio, devono essere previsti i tempi e gli effort necessari affinché lo SLA possa essere garantito, senza dimenticare il “costo” della misura stessa.
La suite CAST misura una serie di indicatori, relativi al rischio delle applicazioni, declinati secondo una serie Business Criteria (Sicurezza, Manutenibilità, ecc.) riconducibili alle più note normative internazionali in materia di qualità e sicurezza del software.
Tali indicatori sono la base naturale, o se preferite la misura elementare, di uno o più SLA correlati a quei Business Risk Factors che le organizzazioni devono monitorare sia per ovvi motivi di qualità dei servizi erogati, sia per motivi di compliance normativa: a tale scopo, nell’ambito delle Pubbliche Amministrazioni (PA), la stessa Agenzia per l’Italia Digitale (AgID) raccomanda fortemente l’utilizzo di questa tipologia di SLA negli appalti di fornitura di sviluppo/manutenzione software.
Fgura 1 - in evidenza gli indicatori dalle dashboard CAST sui quali basare gli SLA
Vediamo di seguito come costruire questa tipologia di SLA a partire dagli indicatori misurati da CAST e come misurarli ed applicarli nel lasso temporale dell’esecuzione contrattuale.
Gli standard di riferimento
Stante la forte relazione tra il Consortium for Information & Software Quality™ (CISQ™) e CAST, quest’ultima ha implementato il modello CISQ per il calcolo degli indicatori di rischio relativi ai vari Business Criteria: Security, Efficiency, Robustness, Changeability e Transferability.
Detti Business Criteria sono facilmente comparabili con le caratteristiche/sottocaratteristiche di qualità del software espresse dalla famiglia ISO 25000 e, in particolare, dalla ISO/IEC 25010:2011, in genere presa a modello dalla PA.
Figura 2 - Modello di qualità proposto dalla ISO/IEC 25010:2010
La famiglia ISO 25000 solo recentemente ha espresso un modello di indicatori implementabile per la misura delle caratteristiche di qualità del software, con particolare riferimento alla norma ISO/IEC 25023:2016, le cui relazioni con la ISO/IEC 25010:2011 sono schematizzate in Figura 3.
Al fine di rendere effettive delle modalità di misura, ISO, di concerto con il CISQ, ha emanato la norma la ISO/IEC 5055:2021 che definisce, appunto, detto modello.
Figura 3 - Relazione tra modello di qualità e modello di misura nella famiglia ISO 25000 e modello di misura ISO/IEC 5055:2021
Gli algoritmi proposti dalla ISO 5055 sono ovviamente mappati sulle caratteristiche della ISO 25000 rendendoli così utilizzabili in qualsiasi contesto contrattuale.
CAST è in grado di calcolare gli indicatori di rischio secondo il modello ISO 5055 presentandone i risultati con una vista specifica sulle dashboard messe a disposizione per la data consumption da parte dei clienti.
Best Practices per l’adozione di questi SLA
La prima indicazione per l’adozione di questi SLA è di definirli per singola applicazione presente nel portfolio dell’organizzazione: allo scopo si rende necessario effettuare una misurazione in fase di definizione del capitolato/contratto (o esperimento dell’eventuale gara pubblica).
Un'ulteriore misurazione dovrà essere effettuata all’inizio dell’esecuzione contrattuale da considerarsi quale “baseline” per le misurazioni successive che si effettueranno nel corso del contratto.
La seconda indicazione è sulla tipologia di SLA che si intende realizzare.
- Mantenimento dei livelli di rischio rilevati: essendo noto che le attività di manutenzione tendono a deteriorare qualità, sicurezza e altri aspetti non funzionali del software, una tipologia di SLA è quella che il fornitore, nel corso dell’esecuzione contrattuale, non peggiori gli indicatori rilevati tramite la suite di CAST.
- Miglioramento dei livelli di rischio rilevati: avendo a disposizione budget ed effort sufficienti ad alimentare le attività di miglioramento degli indicatori, il sistema di misurazione deve essere in grado di indicare quanto è possibile migliorare gli indicatori e con quali modalità di manutenzione correttiva.
In entrambi i casi, è utile prevedere un risk cap in percentuale del valore del contratto nell’unità di tempo (p.e. canone mensile); ad ogni singolo SLA viene assegnato un peso che rappresenta l'importo del risk cap che viene, eventualmente, applicato come penale.
Un punto di attenzione consta nella definizione del peso da assegnare al singolo SLA: qualora il peso sia eccessivo il fornitore potrebbe non adempiere allo SLA e pagare la penale.
All’inizio dell’esecuzione contrattuale, è utile definire un grace period per verificare la capacità del fornitore di raggiungere le soglie indicate contrattualmente.
Può, altresì essere utile includere una percentuale bonus che può essere utilizzata sia per recuperare una penale precedente, sia per incentivare un miglioramento della qualità complessiva. Questa può essere valutata a fine contratto per ogni SLA, e, statisticamente, tende ad essere pari al 5% circa.
La misurazione degli indicatori può essere cadenzata ad intervalli di tempo relativamente brevi (p.e. settimanale), differenziati in funzione del modello di sviluppo (waterfall, agile, ecc.); invece, l’applicazione degli SLA semestrale o annuale, in funzione della durata contrattuale, è sicuramente più appropriata.
A queste semplici indicazioni, si aggiungono quelle previste da AgID nel documento Guida tecnica all’uso di metriche per il software applicativo sviluppato per conto delle pubbliche amministrazioni le cui considerazioni sono valide anche per organizzazioni non facenti parte della Pubblica Amministrazione.
Comments: