“Quando si deve trattare una fornitura software, gestire e redigere il relativo contratto, l’adozione di best practice, linee guida e metriche corrette e complete risulta fondamentale per considerare tutti gli elementi che concorrono a costituire la fornitura stessa.” Lo sottolinea Luigi Buglione, presidente di GUFPI-ISMA (Gruppo Utenti Function Point Italia – Italian Software Metrics Association) l’Associazione Italiana di riferimento per la misurazione (del software e non solo), attiva dal 1990.
Vi sono però alcune lacune metodologiche da colmare, ma quali? In particolare, nei progetti software, e sempre più con la diffusione delle nuove tecnologie come le applicazioni cloud e l’Internet of Things (IoT), spiega l’esperto, l’uso della Function Point Analysis (FPA), una tecnica di misurazione della dimensione funzionale dei prodotti software, va integrato con altre metodologie, in grado di quantificare anche altri requisiti: nelle applicazioni cloud, ad esempio, la velocità di connessione o il grado di sicurezza nella digitazione di una password, sono aspetti che i function point tradizionalmente non misurano.
“Il nostro obiettivo come GUFPI-ISMA, nei prossimi anni, sarà allora cercare di rendere sempre più facile misurare le cose che non si sono misurate finora: in particolar modo i requisiti non-funzionali dei progetti software, ossia tutto quello che generalmente viene definito qualità del software – spiega Buglione -. Quindi gli aspetti legati all’usabilità, alla portabilità, all’accessibilità delle funzioni del software; ma anche alla verifica della qualità dei dati. Questo tema assume forte interesse adesso, in particolar modo con l’avvento del regolamento europeo GDPR: alcuni bandi di gara, infatti, già stanno richiedendo ai fornitori che risponderanno, sia nel settore pubblico sia nel privato, di progettare nuovi sistemi informativi partendo dalla qualità dei dati”. Un punto di riferimento è, ad esempio, lo standard ISO/IEC 25012:2008, che definisce un modello generale di qualità dei dati gestiti da un sistema informativo.
Fare bene i conti
“La radice del problema – spiega – quando ad esempio un committente commissiona un nuovo software a un fornitore, è appunto che il calcolo del valore della fornitura viene eseguito soltanto sulla base dei requisiti funzionali (punti funzione) del prodotto software che, in alcuni casi, arrivano a coprire anche il 70% dell’effort: poi però non vengono conteggiate, e remunerate in maniera adeguata, tutte le altre attività che concorrono a costituire il progetto software nella sua interezza. Queste incongruenze si creano perché, in genere, chi redige capitolati dei contratti e bandi di gara è il personale amministrativo, che non sempre richiede supporto o ausilio al settore tecnico”.
Proprio per stimolare la PA, ma anche enti privati, a tener conto, nelle stime tecniche eseguite per i nuovi contratti, di tutti gli elementi che compongono un progetto software, AgID, l’Agenzia per l’Italia Digitale, ha emanato la “Guida tecnica all’uso di metriche per il software applicativo sviluppato per conto delle pubbliche amministrazioni”, a cui GUFPI-ISMA ha contribuito.
In particolare, tra le metodologie disponibili per quantificare anche le caratteristiche non-funzionali del software, AgID cita, ad esempio, lo ‘Schema ABC’ definito dall’Associazione nel documento PABPC, ossia un modello che classifica e certifica i requisiti in tre tipologie: quelli di tipo A sono i requisiti funzionali del prodotto software, e si misurano in punti funzione; i requisiti di tipo B sono i requisiti non funzionali, misurabili ad esempio attraverso la metodologia SNAP (Software Non-functional Assessment Process) pubblicata da IFPUG (International Function Point Users Group) nel 2011; infine vi sono i requisiti di tipo C, che tengono conto dell’effort rimanente, ossia di tutti gli aspetti organizzativi e gestionali necessari per realizzare e manutenere il progetto software commissionato. “I requisiti di tipo C contemplano la componente che, negli anni, tutti hanno dimenticato di considerare, quella che spesso genera il problema di stima: nessuno infatti calcola il tempo per la misurazione dei requisiti, il tempo per i meeting, per la formazione, la quality assurance. Questi sono tutti task di natura organizzativa, che noi chiamiamo requisiti di tipo C” conclude Buglione.
Ampliare la prospettiva sulla misurazione
Quali iniziative ha però in corso l’Associazione? Proprio con l’obiettivo di sensibilizzare il settore, e di fornire una prospettiva più ampia possibile nel mondo della misurazione, GUFPI-ISMA, soprattutto negli ultimi due anni, oltre ai classici eventi programmati su scala nazionale (EventoMetrico – il prossimo si terrà il prossimo 17 maggio a Roma), ha attivato anche altri appuntamenti, come i webinar ‘metrici’. Questi ultimi si propongono di far luce sulle molteplici sfaccettature della misurazione, ad esempio in aree come la sicurezza, l’architettura applicativa, il cloud, e di far nascere nelle organizzazioni una visione sempre più olistica in materia di misurazione dei progetti software. “Nel 2016, nel volume Principi, Assunzioni e Best Practice Contrattuali (PABPC), abbiamo anche ridefinito le nostre linee guida e suggerimenti per l’analisi degli aspetti non-funzionali e per un uso corretto delle metriche nei contratti ICT, al fine di verificare le aree di copertura, o scopertura, nei contratti stessi, attraverso metodologie basate non solo sui Function Point” aggiunge Buglione.
