Resoconto: Misurare gli Open Source Software, la Qualità di prodotto

4unnamed

Roma- LUISS iLAB, 8 Maggio 2015
Misurare per gestire” diceva Tom Demarco – uno dei guru dell’Ingegneria del Software, ma facendo un passo indietro è necessario “definire (opportunamente) ciò che si intende misurare” per evitare ambiguità e tirar fuori numeri non comparabili in alcuni casi tra loro. Un esempio? Provate a domandare a diverse persone di darvi una definizione di cosa sia una linea di codice (LOC – Line of Code) ed avrete diverse possibili definizioni in ritorno: linee fisiche o logiche, con o senza righe di commento…risultato: valori alquanto distanti con il rischio di commettere errori di stima sui tempi e i costi di lavoro di un progetto. Ultimo passo, tornando indietro, è quello fondamentale di “conoscere ciò che si intende definire”. Sembra lapalissiano, ma conoscere ed approfondire un oggetto di interesse per poterlo meglio descrivere (e quindi misurare) sembra non essere negli ultimi anni una pratica diffusa in molte organizzazioni, a prescindere dalle dimensioni. Si può migliorare il proprio modo di lavorare solo fermandosi e riflettendo su come siamo organizzati e misurare “q.b.” (quanto basta) è sicuramente la prima delle soluzioni, per controllare le variabilità dai livelli ottimali per il nostro lavoro.

Ma misurare spesso spaventa, meglio a volte non sapere troppo e quindi la misurazione viene percepita sempre più come un costo non necessario che come opportunità informativa per dirigere un cambiamento (pro)positivo per migliori risultati (economici e non). E nel caso in cui si intenda misurare, lo scoglio successivo è cosa misurare…tempi e costi o anche altro? E relativamente a quale entità? Il progetto e/o il prodotto/servizio finale? È vero o no che ‘one size doesn’t fit all’?

Esistono diversi suggerimenti da cui poter trarre spunti utili, tra cui:

  • EAM (Entity-Attribute-Measure) – è uno schema che permette di esplicitare l’entità che si intende misurare (organizzazione, progetto, risorse, processi, prodotti/servizi) rispetto all’attributo di interesse (es: funzionalità, complessità, difettosità, …) attraverso una o più misure. Obiettivo: chiarire cosa misura ciascun KPI tra quelli definiti nel sistema di misurazione di un’organizzazione, aiutando ad evidenziare carenze o possibili sovrapposizioni;
  • BSC (Balanced Scorecard) – riportata all’attenzione da Kaplan e Norton negli anni ’90, è una tecnica francese (Tableau de Bord) di fine ‘800 che intende rappresentare il funzionamento di un’organizzazione tramite prospettive contenenti obiettivi misurabili, collegati tra di loro secondo una serie di relazioni causa-effetto. I ‘semafori’ ottenuti permettono di comprendere tramite la redazione di ‘mappe strategiche’ quale possa essere il driver dal quale partire per un intervento correttivo/migliorativo;
  • BMP (Balancing Measurement Perspectives) – è una tecnica complementare alla BSC che permette di poter valutare, una volta associate le misure inizialmente selezionate alle prospettive di una scorecard, quali mantenere nel piano di misurazione e quali eventualmente scartare, in base al valore informativo che possono restituire;
  • QM (Quality Models) – un ‘modello di qualità’ è espresso tipicamente da una scomposizione in 3 livelli di caratteristiche, sotto-caratteristiche e misure per descrivere una data entità di interesse in modo misurabile. Un QM esprime quindi requisiti qualitativi che insieme a quelli tecnici rappresentano i NFR (Non-Functional Requirements), ovverosia il ‘come’ si desidera che un software sia realizzato. L’attuale standard ISO è indicato nella norma ISO/IEC 25010:2011 (evoluzione della 9126-1:2001), raccontata nelle presentazione dell’8 maggio, ed applicabile sia a prodotti software che a servizi puri.
  • FPA (Function Point Analysis) – tecnica di misurazione delle funzionalità di un prodotto software ideata da Allan Albrecht nel 1979, revisionata nel 1983 ed evoluta in una serie di varianti (le principali sono quelle di IFPUG e COSMIC): partendo dall’analisi dei FUR (Functional User Requirements – ovverosia il ‘cosa’ si desidera che venga realizzato) di un progetto software è possibile quantificarli tramite un algoritmo che restituisce una dimensione funzionale del prodotto software tramite un dato numero di ‘Function Point’ (Punti Funzione). Maggiore il numero di FP, maggiore la dimensione funzionale e pertanto l’effort richiesto per la realizzazione del relativo progetto.
  • SNAP (Software Non-functional Assessment Process) – La FPA è e rimane importante ma, come detto, sono due le parti da considerare, il ‘cosa’ fare (FUR) e il ‘come’ farlo (NFR). IFPUG ha recentemente prodotto una nuova tecnica (SNAP) per assegnare una dimensione ai NFR di un prodotto software, valore da affiancare a quello dei FP nella gestione di un progetto software.

Come misurare quindi un progetto OSS? Esattamente come ogni altro progetto software, con le varianti del caso: saranno differenti modalità e tempi per le diverse fasi del ciclo di vita rispetto ad un progetto ‘commerciale’, saranno progetti classificabili come ‘enhancement’ di una baseline iniziale condivisa tra gli stakeholder di una community di riferimento, ma di fondo sono e rimangono progetti software a cui applicare le conoscenze, i modelli e le tecniche di Ingegneria del Software, ovviamente proporzionati in base alle sue dimensioni e caratteristiche.

Su cosa puntare? Su una gestione dei requisiti completa, a partire dalla loro elicitazione, che coinvolga i giusti stakeholder e un livello di descrizione sintetico ma esaustivo in termini informativi, usando ad esempio alcuni diagrammi UML che facilmente permettano di poter cogliere le varie ‘dimensioni’ utili del prodotto e del progetto software in esame.

Per maggiori informazioni sul misurare gli Open Source Software, scarica la presentazione completa di Luigi Buglione e consulta il sito di GUFPI – ISMA.

Vuoi contribuire (segnalare problemi, proposte o suggerimenti) alla nostra associazione?
Il nostro progetto Industria Aperta su GitLab ti permette di scriverci in modo pubblico e trasparente!