LA MISURA DEL SOFTWARE
s
Rubrica a cura di Luigi Buglione – GUFPI-ISMA
Metrologia e Contratti Parte 19 – Stimare un progetto è una “black art”? METROLOGY AND CONTRACTS – PART 19: MEASURING MATURITY AND CAPACITY Nineteenth paper based on the new GUFPI-ISMA guidelines on the proper use of “Principles, Assumptions and Contractual Best Practices” (vol. 1, 2016) is about the measurability of maturity and capability of organizations (not only in the ICT field) and their processes.
RIASSUNTO Diciannovesimo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di ‘Principi, Assunzioni e Best Practice Contrattuali’ (vol.1, 2016), relativo alla misurabilità dei livelli di maturità e capacità delle organizzazioni (non solo del comparto ICT) e dei loro processi. Diciannovesimo 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” GUFPI-ISMA 2016 [1]. Stavolta parliamo della misurabilità del livello di maturità di un’organizzazione e della capacità espressa dai suoi processi: per migliorarsi, si deve partire da dove siamo oggi (“as-is”) per stabilire un traguardo raggiungibile (“to-be”). Ok, ma come? Vediamo meglio di cosa si tratta....
processes that are documented, managed, measured, controlled, and continually improved” [2]. Questo grado di maturità è stato spesso rappresentato graficamente come una scala con una serie di gradini, in genere da 1 a 5 (scala Likert), come indicato in Fig.1.
PARTIAMO DALL’INIZIO: LA POLITICA DEI “PICCOLI PASSI” …
Figura 1 – IFPUG FPA: fasce di complessità
L’obiettivo di ogni organizzazione è quello di migliorarsi e migliorare le proprie performance nel tempo in modo graduale, quella che potremmo definire una politica dei “piccoli passi”, risultati positivi al giusto costo, un po’ per volta, modulando gli investimenti per realizzare le attività necessarie a raggiungere tali obiettivi. L’ISO definisce la maturità organizzativa un “extent to which an organization has explicitly and consistently deployed
Questo approccio nacque negli anni ’70 dapprima in ambito manifatturiero [3] partendo dagli studi di Philip Crosby sotto forma di griglia (Fig. 2), immaginando una serie di parametri di valutazione relativi alle performance di un’organizzazione, ciascuno dei quali da valutare rispetto a una serie di definizioni sempre più sfidanti, tra un livello 1 e un livello 5. A metà degli anni ’80 venne ripreso il concetto anche nel settore informatico
con uno studio in IBM condotto da Ron Radice [4] (Fig. 3), in questo caso intendendo il livello 1 come il valore massimo e il livello 5 come il punteggio minimo e iniziando a posizionare processi e/o macro-attività legate allo sviluppo software quali parametri da valutare. Alla fine degli anni ’80 il Software Engineering Institute (SEI) emise la prima versione di Sw-CMM (Capability Maturity Model) [5] (Fig. 4) e iniziò a proporre un criterio per aggregare il “profilo” di maturità in un solo valore, quel “maturity level” complessivo, creando una struttura organica per definire un insieme di meta-processi da considerare quale punto di riferimento negli appraisal così come un ordine d’introduzione di tali processi nella gestione di una divisione/organizzazione software, quello che prese nel tempo il termine di rappresentazione “staged”, a gradini. Qualche anno dopo, alla fine degli anni ’90, considerando anche le possibili integrazioni tra parti componenti di un sistema IT, il SEI diventa CMMI Institute (recentemente acquisito da ISACA, l’associazione che gestisce COBIT e altri modelli/certificazioni di Governance) e crea una serie di Capability Maturity Model Integration (CMMI), con tre “constellation” (CMMI-DEV, CMMI-SVC, CMMI-ACQ), rispettivamente relative agli sviluppi del software (evoluzione del Sw-CMM), gestione dei servizi e delle forniture e degli acquisti. Nella seguente figura si presenta la versione “staged” del modello CMMI-DEV con le 22 PA (Process Area) da poter valutare [6]. Dal mondo del software/IT, l’approccio
Presidente GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org
T_M
N.
1/21 87
