Oggi le pubbliche amministrazioni italiane, stipulando specifici contratti, acquisiscono da fornitori esterni servizi di sviluppo applicativo e di manutenzione di applicazioni informatiche. La PA utilizza tali parchi applicativi per espletare i propri compiti istituzionali: tuttavia, AgID, l’Agenzia per l’Italia digitale, nella propria attività, ha rilevato negli ultimi anni diverse criticità frequentemente riscontrate nella gestione di questi contratti pubblici: in particolare, tra i problemi chiave, vi è la mancanza di strumenti e meccanismi contrattuali per garantire la qualità di quanto è stato ricevuto dal fornitore, cioè dei prodotti software e dei relativi servizi.
Con l’obiettivo di fornire sul tema utili indicazioni alla PA e di aggiornare le precedenti linee guida, lo scorso maggio AgID ha quindi emanato un documento, o meglio una “Guida tecnica all’uso di metriche per il software applicativo sviluppato per conto delle pubbliche amministrazioni”. La guida, spiega AgID, si propone d’integrare le novità introdotte dal “Piano Triennale per l’informatica nella Pubblica amministrazione 2017-2019”, di rispondere alle esigenze connesse al contenimento della spesa pubblica e al rapporto costi/benefici nelle acquisizioni e nei progetti delle amministrazioni, nonché alle criticità riscontrate in molti contratti per lo sviluppo applicativo, talvolta derivanti da interpretazioni non corrette di indicazioni e passaggi delle precedenti linee guida.
Guida e standard CISQ: insieme in aiuto alla PA
La guida è il risultato di un tavolo di lavoro durato un anno, al quale hanno partecipato, oltre ad AgID, il Team per la Trasformazione Digitale, amministrazioni, fornitori, esponenti del mondo accademico, associazioni nazionali per la misurazione del software come GUFPI-ISMA, organismi come CISQ-OMG, che sviluppano standard internazionali per automatizzare la misura delle dimensioni e della qualità strutturale del software, aziende come CAST con il suo country manager Massimo Crubellati.
Proprio lo scorso settembre, Michele Slocovich, che ha partecipato al tavolo di lavoro in qualità di Director of Outreach Italy del CISQ, ma che è anche Solution Design Director di CAST, società di fornitura di soluzioni di software analysis e measurement che naturalmente implementa gli standard CISQ, e docente di Computer Science all’Università Luigi Bocconi, ha delineato in un webinar le motivazioni che hanno portato alla creazione della guida, approfondendo poi le relazioni tra questa e gli standard offerti dal CISQ. “Questi due strumenti – dice Slocovich – possono coesistere e fornire valore alle pubbliche amministrazioni che intendono implementare le nuove metriche, che sono state, appunto, oggetto del tavolo di lavoro che ha portato alla redazione del documento-guida”.
Metriche non funzionali in primo piano
“Eseguendo una disamina delle metriche del software a livello internazionale, il tavolo di lavoro – spiega Slocovich – si è subito concentrato sulla ricognizione delle metriche per quantificare le caratteristiche non funzionali del software applicativo, rispetto a quelle funzionali, basate in sostanza sulla misura delle funzionalità erogate”. Questo perché, in generale, gli attuali schemi contrattuali risultano troppo rigidi, con casi di contratti di sviluppo applicativo in cui l’unica metrica prevista, ossia i punti di funzione (PF), si dimostrava chiaramente inadatta a quantificare tutte le attività connesse alla fornitura, come ad esempio la realizzazione di documentazione e tutorial dedicati all’utente.
Tra le asserzioni condivise dal tavolo di lavoro, la necessità di definire metriche di prodotto, oggettivamente misurabili, e non metriche di processo/servizio; di concentrarsi su software applicativo ad hoc, quindi di tipo ‘custom’ (non da banco); di usare metriche diffuse e conformi a standard, “ma anche di definire metriche semplici da utilizzare e con un basso costo implementativo, perché altrimenti – sottolinea Slocovich – complessità e costi porteranno le amministrazioni a non applicarle”.
Ferma restando, nonostante le criticità riscontrate, la validità delle metriche funzionali, che sarebbe irragionevole abbandonare o sostituire anche perché molto diffuse in gare e contratti, come detto, il focus è stato sulle metriche per valutare i requisiti non funzionali, e i requisiti di qualità, che sono un sottoinsieme degli stessi e vengono disciplinati dalla norma ISO/IEC 25010.
Le metriche implementate e proposte da CISQ-OMG sono coerenti con la norma ISO 25010 e costituiscono un’estensione della norma ISO 25023. “Più in dettaglio, CISQ individua 86 regole che servono a prevenire carenze non-funzionali, o meglio a determinare quali sono i livelli di qualità ottimali e quelli minimi di accettabilità in una fornitura software, prima della messa in produzione delle applicazioni”. Queste regole si concentrano su quattro delle otto caratteristiche di qualità definite da ISO 25010: quattro requisiti che risultano oggettivamente subito misurabili a partire dal software sviluppato, e sono: affidabilità, performance, sicurezza, manutenibilità. “Tali metriche – conclude Slocovich – hanno l’obiettivo di valutare la qualità strutturale dell’intero sistema, che quando è fragile diventa responsabile della maggior parte dei problemi e dei costi riscontrati in produzione, e sono state consigliate da AgID nel documento-guida come possibile strumento da adottare nella gestione dei contratti di fornitura”.
Agid, nelle sue linee guida, come strumento per la misurazione delle baseline, suggerisce lo standard Automated function point (AFP) dell’OMG che fornisce le specifiche per il conteggio automatizzato del function point: i punti funzione si dimostrano tutt’ora l’unico metodo realmente efficace per misurare la produttività nel campo dello sviluppo applicativo, ma la loro natura manuale ne rende difficile l’applicabilità su larga scala. Grazie alla standardizzazione di OMG (ISO 19515), pubblicata all’inizio del 2013, il conteggio dei function point si è trasformato invece in una pratica di analisi universale, affidabile, veloce e più economica.
