LA MISURA DEL SOFTWARE
s
Rubrica a cura di Luigi Buglione – GUFPI-ISMA
Metrologia e Contratti Parte 16 – Qualità dei dati non solo software METROLOGY AND CONTRACTS - PART 16: DATA QUALITY: NOT ONLY SOFTWARE! Sixteenth paper based on the new GUFPI-ISMA guidelines on the proper use of “Principles, Assumptions and Contractual Best Practices” (vol.1, 2016) is about data quality, that’s a new perspective for understanding – more than ever – how much a software is valuable.
RIASSUNTO Sedicesimo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di ’Principi, Assunzioni e Best Practice Contrattuali’ (vol.1, 2016), relativo alla qualità dei dati che rappresenta sempre di più una nuova prospettiva per comprendere – più che mai – quanto un software valga. INTRODUZIONE
Sedicesimo appuntamento con la disamina dell’applicazione di buoni principi di misurazione ai contratti (ICT e non), relativo agli aspetti di corretto censimento delle misure e loro utilizzo in un piano di misurazione, altro spunto incluso nelle “linee guida contrattuali” GUFPIISMA 2016 [1]. Stavolta parliamo di qualità di dati: troppo spesso si è parlato di software in termini di programmi e procedure da eseguire ma troppo poco dei dati che tali programmi debbono usare e della loro qualità che in realtà, tornando indietro nel tempo, erano il punto di partenza per la creazione di un software qualitativamente valido e sempre più invece sono passati (erroneamente) in secondo piano. Ma vediamo meglio di cosa si tratta.... SOFTWARE = FUNZIONI + DATI
La creazione di un software, fino ai linguaggi c.d. di terza generazione, spesso partiva dalla definizione delle strutture dati per poi costruirci sopra le istruzioni e poi compilare. Basti ricordare le division in COBOL: si definiva prima la “data division” per poi passa-
re alla “procedure division”, dovendosi definire prima variabili e tracciati record da usare nelle istruzioni. Un errore nella prima delle due parti avrebbe generato ovviamente maggiori problemi per completare la compilazione del codice e generare il relativo eseguibile. Questo tipo di logica è stato ad esempio anche riportato nella redazione delle prime versioni della Function Point Analysis (FPA) che nella propria procedura di conteggio tuttora riporta nell’ordine dei passi da eseguire prima la misurazione dei dati e poi dei processi, proprio perché nasceva nel 1979 in casa IBM, quindi nel ’regno’ di DB2 e del mainframe. Passando gli anni, si è parzialmente invertito il punto di vista, ponendo maggiore enfasi all’aspetto delle funzionalità, al punto da iniziare dal 1977 in poi a creare una serie di modelli di qualità del software che ne osservavano l’aspetto “dinamico” (funzioni/processi). Anche la creazione di dati di test oggi viene vista talvolta nei progetti ICT quale “male necessario” per verificare le procedure più che non come un’opportunità – in ottica DevOps (“shift left”) – per anticipare possibili errori e difetti che altrimenti resterebbero magari latenti in eserci-
zio, generando possibilmente difetti in produzione con pagamento di possibili penali contrattuali per il superamento di soglie nei relativi livelli di servizio. Dal FCM (Factor/Criteria Model) al quality model di Boehm, alla prima versione di ISO 9126 e all’attuale ISO/IEC 25010 [2], si sono andate raffinando le caratteristiche cosiddette “non-funzionali” di un prodotto software, come indicato nella Fig. 1. Solo all’inizio degli anni 2000 questi modelli hanno esteso il loro raggio abbracciando anche la valutazione della qualità dei servizi e dei dati con il progetto SQuARE (System and Software Quality Requirements and Evaluation), ovverosia con le norme della famiglia ISO 25000 [3]. In particolare, la norma ISO 25012 propone il modello per la qualità dei dati, le cui misure sono indicate nella norma ISO 25024, seguendo come sempre una tassonomia a tre livelli, come nella tecnica Goal-Question-Metric (GQM), in questo caso: caratteristica; sotto-caratteristica; misura. Nel mondo delle metriche funzionali per i prodotti software ogni metodologia sottolinea questa complementarietà: IFPUG propone BFC di tipo dato (ILF, EIF) che vengono usate da quelle di tipo processo (EI, EO, EQ) mentre COSMIC conta i c.d. “data movement” (Entry, eXit, Read, Write) considerando però per le letture/scritture quali siano – sebbene non entrino direttamente nella formula di conteggio – i c.d. “oggetti d’interesse” (ovverosia i dati “persistenti”). E questo lo stiamo denominando nei conteggi funzionali il “controllo degli orfani”, ovverosia non può esserci un processo che non usi un dato (in lettura e/o scritPresidente GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org
T_M
N.
2/20 65
