LA MISURA DEL SOFTWARE
s
Rubrica a cura di Luigi Buglione – GUFPI-ISMA
Metrologia e Contratti Parte 13 – Requisiti funzionali: 40 anni di Function Point Analysis (FPA) METROLOGY AND CONTRACTS - PART 13: FUNCTIONAL REQUIREMENTS: 40 YEARS OF FUNCTION POINT ANALYSIS (FPA) Thirteenth 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 first 40 years of Function Point Analysis (FPA), a technique born in 1979 for assigning a functional size to software products and improving the estimation process yet from the early project lifecycle stages.
RIASSUNTO Tredicesimo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di ‘Principi, Assunzioni e Best Practice Contrattuali’ (vol.1, 2016), relativo ai primi 40 anni della Function Point Analysis (FPA), tecnica nata nel 1979 per assegnare una dimensione funzionale ai prodotti software e migliorare il processo di stima sin dalle prime fasi di un progetto. INTRODUZIONE
Tredicesimo appuntamento con la disamina dell’applicazione di buoni principi di misurazione ai contratti (ICT e non). Stavolta parleremo di una delle tecniche di misurazione più usate negli ultimi decenni, la Function Point Analysis (FPA), tecnica per dimensionare i requisiti funzionali dei prodotti software, usata anche quale base di corresponsione per i progetti di sviluppo e manutenzione evolutiva, altro tema incluso nelle ‘linee guida contrattuali’ GUFPI-ISMA 2016 [1]. FUNCTION POINT ANALYSIS (FPA): LE ORIGINI
Nell’ottobre 1979 Allan J. Albrecht, un ricercatore IBM, proponeva per la prima volta in pubblico la Function Point Analysis (FPA) [2], una metodologia per migliorare i processi di stima (prima) e dimensionamento (poi) del software, superando il conteggio che tuttora sopravvive in diversi settori industriali in LOC (Lines of Code) e i
relativi problemi legati al cosiddetto “paradosso della produttività” [3]. L’esigenza (e l’opportunità) era quella di poter quantificare la dimensione delle funzionalità di un software già dalle fasi alte del ciclo di vita, ben prima di scrivere il codice, a supporto delle trattative iniziali tra Cliente e Fornitore. Il metodo è vissuto (e sopravvissuto) già per quattro decadi e – diversamente da quanto affermato da alcuni analisti di mercato – non potrà mai andare in pensione semplicemente perchè non è legato alle tecnologie bensì alla misurazione di processi e dati, derivati per l’appunto dai requisiti funzionali utente (FUR – Functional User Requirements). I cambiamenti di tecnologia hanno (e avranno) impatto sui tempi e i costi di realizzazione ma non sulla dimensione funzionale (e non) del prodotto software. Un semplice esempio: lo stesso software realizzato in Java nel 1996 e nel 2019 può sviluppare le stesse funzionalità (e avere quindi la stessa dimensione funzionale) ma nel corso degli anni le diverse facility quali Eclipse e J-Unit – solo per citarne alcune – hanno facilitato gli sviuppatori ridu-
cendo i tempi di realizzazione e i relativi costi, incrementando pertanto la produttività. L’intuizione di Albrecht permette quindi ancora oggi attraverso cinque varianti standard ISO (IFPUG, COSMIC, NESMA, FISMA, Mark-II) di definire dei mattoni elementari che seguono una grammatica di base, come previsto dai criteri della norma ISO 14143-1:2007 [4]. I “processi elementari” e i “file logici” rappresentano pertanto l’étalon [5] di riferimento per la misurazione funzionale e il “controllo degli orfani” [6] permette di verificare che un processo usi i dati dichiarati e che ciascun dato sia usato da uno o più processi, al fine di evitare sovra/sottodimensionamenti. FPA: BASE FUNCTIONAL COMPONENTS (BFC) E I DUE PRINCIPALI STANDARD
Parlando dei due principali metodi attualmente in uso, il metodo di Albrecht, ereditato dall’IFPUG (International Function Point Users Group), prevede di derivare processi d’input (EI – External Input) e di output (EQ – External inQuiry; EO – External Output) e dati in lettura/scrittura (ILF – Internal Logical Files) e sola lettura (EIF – External Interface File), considerando tre fasce di complessità (Bassa, Medio, Alta) con un sistema di pesatura – rappresentativo del relativo effort – derivato da un dataset di una ventina di progetti IBM tra la fine anni ’70 e inizio anni ’80. Per un’overview della tecnica ci si riferisca a questa presentazione [7].
Presidente GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org
T_M
N.
3/19 ƒ 213
