Introduzione

I Function Point sono oggi la metrica del software di riferimento in molte aziende.
In questo articolo descriveremo, in modo semplice e conciso (speriamo), gli elementi e le caratteristiche di base della metrica, con le sue tipiche applicazioni.
Inoltre, ritenendole interessanti per il lettore, vogliamo riportare alcune esperienze da noi maturate nell'introdurre i Function Point in diverse realtà aziendali.

Che cosa sono i Function Point

"I Function Point misurano il software quantificando le funzionalità in esso contenute e fornite all'utente, basandosi principalmente sul disegno logico"

(IFPUG - CPM4.2)

I Function Point sono una metrica del software di tipo "funzionale", cioè definiscono le dimensioni del prodotto software in termini di funzionalità fornite all'utilizzatore.

Essi sono:

Vediamo, in sintesi, i punti di forza e di debolezza dei Function Point.

PRO:

CONTRO:

Quest'ultimo aspetto è da non sottovalutare. A nostro avviso, infatti, la certificazione del GUFPI, (che, tramite esame, rilascia un certificato di conteggiatore secondo il metodo IFPUG CPM 4.2) è un aspetto essenziale ma, di per sé, non sufficiente per affrontare le innumerevoli situazioni e casistiche che si presentano nell'applicazione pratica dei Function Point: in breve, ad una buona preparazione teorica occorre accompagnare l'esperienza "sul campo".

Elementi di base per il conteggio in Function Point

La dimensione in Function Point di un'applicazione software viene determinata a partire dall'identificazione delle componenti logiche che ne fanno parte, classificate come:

In sintesi, due parole per ognuno dei passi sopra esposti:

Individuare il Tipo di Conteggio

La metrica Function Point è applicabile a:

Per ciascuno di essi sono definiti criteri di conteggio e formule di calcolo specifiche

Identificare Ambito del Conteggio e Confine dell'Applicazione

L'Ambito del Conteggio individua il dominio funzionale che è preso in considerazione ai fini del conteggio, in relazione alle sue finalità:

Il Confine dell'Applicazione delimita il sistema oggetto di misurazione, consentendo di riconoscere, ai fini del conteggio, ciò che è interno al sistema e ciò che è esterno.

Contare le funzioni di tipo dati

Le Funzioni di Tipo Dati rappresentano le funzionalità fornite all'utente per soddisfare i requisiti informativi manifestati. Gli elementi di conteggio sono identificati come:

Contare le funzioni di tipo transazione

Le Funzioni di Tipo Transazione rappresentano le funzionalità fornite all'utente per il trattamento dei dati dell'applicazione. Gli elementi di conteggio sono identificati come:

Chi si appresti a effettuare un conteggio non deve aspettarsi di poter individuare, in modo sempre immediato, gli elementi funzionali appena descritti. Spesso, anzi, le funzionalità e le strutture dati, così come sono state realizzate, come le si trova in documentazione di analisi o come vengono descritte da esperti dell'applicazione, comprendono più elementi singoli della metrica (ILF, EI, . . .). Analogamente, più elementi funzionali realizzati, possono concorrere a comporre un solo elemento del calcolo dei Function Point. In sostanza, nell'ambito di un conteggio, individuare correttamente i singoli elementi che concorrono al dimensionamento in Function Point è una delle principali difficoltà.

Individuato il grado di complessità di ciascuna funzione, è possibile attribuire ad essa un valore in Function Point, in relazione alla specifica tipologia (vedi tabella sottostante). La somma dei contributi relativi a tutte le funzioni individuate costituisce la dimensione in Function Point non Pesati (UFP - Unadjusted Function Point) dell'applicazione.

Al valore in Function Point non Pesati, viene applicato un coefficiente correttivo (VAF - Value of Adjustment Factor), ottenuto valutando il "grado di influenza" di 14 fattori specifici, detti Caratteristiche Generali del Sistema, che rappresentano i requisiti non funzionali dell'applicazione.

Il VAF può correggere il valore in UFP in misura del ±35%

La dimensione finale dell'applicazione, espressa in Function Point Pesati (AFP - Adjusted Function Point), si determina applicando formule di calcolo differenziate in base al tipo di conteggio.
Nelle formule che seguono, per ottenere gli UFP, bisogna non applicare il VAF, cioè considerarlo uguale ad 1.

Progetti di nuovo sviluppo
AFP = (UFP funzioni applicative + UFP funzioni di conversione) x VAF

Interventi di manutenzione evolutiva
AFP = [ (UFP funzioni applicative aggiunte +
UFP funzioni applicative modificate +
UFP funzioni di conversione)
x VAF post modifiche ] +
(UFP funzioni applicative eliminate) x VAF ante modifiche

Applicazione in esercizio
AFP = (UFP funzioni applicative) x VAF dopo il primo rilascio: baseline

AFP = [(UFP funzioni applicative BASELINE +
UFP funzioni applicative aggiunte +
UFP funzioni applicative modificate) -
(UFP funzioni applicative eliminate)] x VAF dopo ogni intervento di manutenzione evolutiva

Le Stime

Il conteggio dei Function Point richiede un buon livello di conoscenza funzionale del sistema, che talvolta NON è disponibile: in particolare

Con un minimo di conoscenza funzionale dell'applicazione, si può effettuare una stima delle dimensioni dell'applicazione da sviluppare (o della parte di applicazione da modificare) utilizzando tecniche di conteggio "per approssimazione".
Fra le tecniche di stima più conosciute citiamo:

Riteniamo il Dutch Method del NESMA e il metodo Early and Quick Function Points un ottimo metodo di stima, mentre la tecnica del backfiring è estremamente pericolosa e può portare a stime molto distanti dal valore reale (tant'è che lo stesso Capers Jones, il padre di questa tecnica, l'ha parzialmente disconosciuta)

Vediamo, in breve, alcune di queste tecniche.

Per la tecnica di stima proposta dal NESMA (Estimated Function Point) i passi da seguire sono:
1.identificare le funzioni di Tipo Dati (ILF, EIF) e di Tipo Transazione (EI, EO, EQ) con le regole standard
2. assegnare una complessità "di default":
a. Bassa per ILF - EIF
b. Media per EI - EO - EQ
3.calcolare gli UFP attribuendo i valori secondo la tabella standard
4.considerare VAF = 1 (da cui AFP = UFP)

La differenza rispetto al conteggio standard normalmente non eccede il 10-15%.

L'ISBSG propone una tecnica di stima valida per nuovi sviluppi.
La tecnica è basata su valori medi ricavati dall'analisi di più di 400 casi (questa base statistica viene continuamente ampliata).
Valori ricavati dall'ISBSG:

Si ha quindi (considerando, ad esempio, gli ILF):
UFP (ILF only) = 7,4 * #ILF
UFP (total)= (UFP (ILF only) / 22,3) * 100

Al valore così ottenuto va aggiunto un 30% di contingency (funzionalità implicite).

Naturalmente la stima con questo metodo risulta mediamente più precisa quando si parte dagli EI, EO e ILF, che hanno una maggiore incidenza percentuale sul totale, mentre lo è molto meno quando si basa sugli EIF o sugli EQ. Il grosso limite delle stime rispetto al conteggio è che queste non forniscono una baseline del conteggio della applicazione, per cui la stima non può essere aggiornata con manutenzioni evolutive, né è possibile valutare l'impatto di un intervento, calcolando le variazioni in Function Point che l'intervento comporta sugli elementi funzionali dell'applicazione (ILF, EI, . . .).

La cancellazione di funzionalità nell'ambito di manutenzioni evolutive

Il size dell'intervento, che si ottiene applicando le regole di conteggio standard, nel caso di modifica o cancellazione di funzionalità esistenti non sempre riflette in modo corretto l'effettivo sforzo richiesto.
Infatti, ad esempio, il conteggio canonico richiede che una funzionalità cancellata sia contata per intero nel dimensionamento dell'intervento, come se fosse interamente da sviluppare. In realtà, lo sforzo per cancellare una funzionalità è, di solito, minore di quello necessario per realizzarla (ma, in casi particolari, potrebbe addirittura essere maggiore).
Per meglio calibrare l'impegno in funzione dell'effettivo lavoro da svolgere, nel dimensionamento degli interventi di manutenzione evolutiva si può applicare, alle modifiche e rimozioni di funzionalità, un fattore K di ponderazione che, sebbene non sia standard IFPUG (e quindi il conteggio così effettuato non è conforme agli standard CPM 4.2), è di estremo buon senso, tanto che diverse aziende lo adottano.

Conclusione

La dimensione del software è, ovviamente, una componente fondamentale per determinare impegni e costi delle attività di predisposizione di una nuova applicazione (o di un intervento di manutenzione evolutiva), ma non è la sola. Esistono altri fattori che incidono in modo significativo, tra questi:

Naturalmente è solo la valutazione dell'insieme di tutti questi fattori che fa arrivare a stime attendibili su tempi e costi di uno sviluppo. I Function Point sono, in questo quadro, un elemento importante, che garantisce un punto di partenza stabile, oggettivo e verificabile, e quindi getta solide basi per il lavoro che segue.

L'introduzione dei Function Point in azienda: esperienze e riflessioni

Quanto segue non è altro che una breve discussione di alcune esperienze e riflessioni che abbiamo avuto modo di maturare nel corso di attività che ci hanno visto partecipi, "in prima linea", per introdurre i Function Point in diverse realtà aziendali.
Diamo, subito, un elenco dei punti che tratteremo, dedicando in seguito un approfondimento ad ognuno di essi.

Diffidenza sull'efficacia della metrica

Capita spesso, a chi introduce i Function Point in azienda di scontrarsi con uno scetticismo diffuso sull'efficacia della metrica. Nei casi peggiori questo scetticismo si traduce nella convinzione che i Function Point siano inutili, una perdita di tempo e soldi, e quindi sia giustificato non collaborare (o farlo di malavoglia, senza intenti costruttivi) con coloro che stanno lavorando per portare i Function Point in azienda.
A ciò si può ovviare con:

Problemi "psicologici" sull'utilizzo dei Function Point per misurare la produttività

E' ovvio che la produttività, tipicamente misurata in (Function Point)/ (mese-uomo), è un parametro di enorme importanza: il fatto di stimare, nelle fasi alte del ciclo di sviluppo, la dimensione di un'applicazione ha ben poco valore se poi non siamo in grado di applicare un parametro di produttività che ci traduca questa stima di size in stima di effort (e poi, ovviamente, occorre una tabella di distribuzione dell'effort nelle varie attività del ciclo di sviluppo, ma questo è un altro discorso). Tuttavia, in ambito aziendale, la rilevazione degli indici di produttività è un'attività delicata, che spesso viene avvertita dalle persone come la volontà di inquisire sul loro impegno e professionalità.
Per ovviare a questi timori occorre che siano chiari alcuni punti fermi circa gli indici di produttività:

Esistono, nella letteratura internazionale, degli indici di produttività standard che, in mancanza d'altro, possono essere presi come primo riferimento; tuttavia la rilevazione di indici di produttività specifici per il proprio ambito aziendale è un'attività imprescindibile dall'adozione dei Function Point

L'importanza di definire una "strategia" di utilizzo dei Function Point in azienda

E', forse, questo il primo punto da affrontare in termini temporali. Si tratta, avendone chiariti le potenzialità ed i limiti, di definire l'utilizzo che si intende fare dei Function Point in ambito aziendale. Occorre stabilire tempi e modalità con cui arrivare ai risultati attesi, ottenere un forte impegno del management in tal senso (avendo fornito chiare premesse in termini di costi e sforzi necessari); garantire la presenza di uno sponsor accreditato, che si impegni a monitorare l'andamento dell'attività e ad intervenire per risolvere i problemi e rimuovere gli ostacoli. Senza queste premesse, per nostra esperienza, l'attività è destinata a fallire, superata da altre esigenze ritenute più importanti o più urgenti o più redditizie (senza pretesa di addentrarci in temi al di fuori del nostro ambito, si può dire che il ritorno economico derivato dall'uso dei Function Point deve essere atteso in tempi medio/lunghi, non certo brevi).

Aspetti organizzativi: il gruppo di supporto

Si tratta di un elemento, se vogliamo, di dettaglio nell'ambito del più ampio tema del punto precedente. Tuttavia lo riteniamo particolarmente importante e tale da meritare qualche parola in più.
E' impensabile, anche solo in strutture che superano le poche unità di personale, di effettuare un training completo sui Function Point a tutto il personale addetto al software, che renda in grado chiunque di applicare la tecnica di conteggio in autonomia.
Quindi occorre dotarsi di una struttura di supporto, con persone altamente qualificate che possano supportare gli applicativi nella corretta applicazione delle tecniche di conteggio e stima dei Function Point.
Queste persone, oltre al conteggio o alla stima, devono anche "diffondere il verbo" in tutti i settori aziendali, cioè fare cultura sul tema, sfatare eventuali miti deleteri, paure ingiustificate, voci incontrollate e infondate su ciò che i Function Point potranno portare e, in sostanza, diffondere l'utilizzo dei Function Point, garantendo il raggiungimento degli obiettivi prefissati.
La sola competenza tecnica non è sufficiente per svolgere questo compito al meglio: occorre curare anche aspetti legati al rapporto con il personale delle aree applicative (il rischio è quello di venire calati nel ruolo di inquisitori o "carabinieri") e non sottovalutare le specificità delle aree applicative, avendo sempre presente che i Function Point, in certi casi, non sono in grado di dare una misura corretta dell'applicazione.
In una realtà aziendale in cui operiamo da diversi anni, caratterizzata dalle notevoli dimensioni e dalla varietà estrema del tipo di applicazioni presenti, è stato rilevato che anche la presenza di un gruppo di supporto per i Function Point non era, di per sè, sufficiente a garantire il supporto necessario a tutte le aree applicative. In questo caso si è quindi deciso di istituire una figura di "focal point", nella misura di almeno uno per area (alcune aree più grandi ne hanno anche tre). I focal point sono personale addetto allo sviluppo opportunamente formato, ed hanno il compito di supportare e monitorare l'applicazione della tecnica dei Function Point nelle rispettive aree, rimandando al gruppo di supporto solo i casi che non sono in grado di risolvere da soli. Viene così garantito un presidio più puntuale e specifico per l'area di competenza.

Aspetti legati ai tools: buy vs build ?

Sebbene siano disponibili in commercio diversi tool che supportano l'applicazione in azienda dei Function Point, l'adozione di uno di questi non è, a nostro avviso, un problema urgente: può benissimo essere valutato in un secondo tempo, chiarendosi prima bene le idee su ciò che si vuole da un tool di questo genere.
Inoltre, con poco sforzo, è possibile realizzare dei semplici fogli excel o delle applicazioni custom (ad esempio su Access o Oracle) tramite i quali si possono raccogliere i dati di dimensionamento delle applicazioni, mantenerne allineata la baseline a fronte di manutenzioni evolutive, calcolare indici di produttività (se vengono raccolti i dati di impegno), valutare l'impegno richiesto per effettuare un intervento di evolutiva.
Oltre a ciò, quando non vi è documentazione tecnica aggiornata di un'applicazione (e ciò succede spesso), il fatto di averne effettuato un conteggio in Function Point, e quindi averne catalogate, classificate e minimamente documentate le funzionalità, fornisce utili elementi anche per riappropriarsi della conoscenza di una applicazione con benefici, ad esempio, per l'analisi di impatto di interventi di manutenzione.