La documentazione deve prevedere le seguenti informazioni:

1. scopo e tipo di conteggio
2. scopo del conteggio e confini dell’applicazione
3. la dta del conteggio
4. la lista di tutte le data function individuate, specificando il tipo (ILF o ELF), la relativa complessità e gli FP assegnati
5. la lista di tutte le transaction function individuate, specificando il tipo (EI, EQ o EO), la relativa complessità e gli FP assegnati
6. il risultato del conteggio
7. assunzioni fatte e issue risolte.

Come informazioni aggiuntive è possibile prevedere i seguenti step :

1. identificazione della documentazione di riferimento
2. identificazione dei partecipanti, relativi ruoli e qualifiche
3. per ogni data function viene specificato il numero dei DET e RET
4. per ogni transaction function viene specificato il numero di DET e FTR
5. vengono specificate le relazioni tra data function e transaction function
6. vengono specificate le relazioni tra data function e documentazione di riferimento
7. vengono specificate le relazioni tra transaction function e documentazione di riferimento

Il livello di dettaglio sarà concordato di volta in volta con il cliente.

Infine il risultato dell’elaborazione sarà indicato nel formato

S FP (IFPUG–IS)

dove S è il numero individuato, FP è l’unità di misura e IS indica lo standard di riferimento.

Esempio 250 FP (IFPUG-ISO/IEC 20926:200x)

La formula da utilizzare dipende dallo scopo del conteggio. Vediamo quali sono le formule da applicare in base ai vari casi.

• Sviluppo di un progetto

DFP = ADD + CFP

dove ADD è la dimensione della funzioni da rilasciare e CFP indica la dimensione delle funzioni di conversioni.

• Misura di un applicativo

DFP = ADD

• Evolutiva di un progetto

EFP = ADD + CHGA + CFP + DEL

dove ADD indica la dimensione delle nuove funzioni aggiunte, CHGA la dimensione delle funzioni che hanno subito una modifica, CFP indica la dimensione delle funzioni di conversione e DEL indica la dimensioni delle funzioni da cancellare.

• Misura dell’applicativo a seguito di un’evolutiva

AFPA = (AFPB + ADD + CHGA) – (CHGB + DEL)

dove AFPA indica la dimensione del progetto prima dell’evolutiva, AFPB è la dimensione del progetto dopo l’evolutiva, ADD indica la dimensione delle nuove funzioni, CHGA è la dimensione delle funzioni di conversioni prima dell’evolutiva, CHGB è la dimensioni delle funzioni di conversione dopo l’evolutiva e DEL è la dimensione delle funzioni cancellata con l’evolutiva.

• identificazione dei processi elementari secondo specifica
• classificazione dei processi elementari individuati in External Input (EI), External Output (EO) o External Inquiry (EQ) secondo specifica
• conteggio dei File Typed References per ogni processo individuato
• conteggio dei Data Element Types per ogni processo individuato
• individuazione della complessità funzionale di ogni processo
• individuazione dei function point per ogni processo

Come prima azione occorre scomporre i requisiti funzionali in processi elementari. Per processo elementare si intende una transazione facilmente individuabile dall’utente e che lascia l’applicazione in uno stato consistente. Ad esempio un requisito funzionale relativo alla gestione di una rubrica è scomponibile dei processi elementari di creazione, cancellazione, modifica e lettura di un contatto.

Individuati i processi occorre catalogarli nelle 3 tipologia sopra menzionate.

• Un EI è un processo elementare che riceve dati e informazioni di controllo dall’esterno e che modifica un ILF o cambia lo stato corrente della nostra applicazione.
• Un EO è un processo elementare che mostra dati all’utente eseguendo delle elaborazioni, che spaziano dal calcolo di formule all’aggiornamento di ILF o dello stato corrente della nostra applicazione.
• UN EQ è un processo elementare che mostra dati all’utente senza essere catalogabile come EO.

La seguente tabelle riassume le relazioni tra i processi elementari e lo scopo del processo:

La specifica relaziona i processi elementari alle elaborazioni possibili:

Si conta un FTR per ogni data function individuata coinvolta nel processo

Definiti i FTR si contano i DET secondo le seguenti regole:

• analisi di ciò che attraversa i confini dell’applicativo
• si conta un DET per ogni attributo riconoscibile dall’utente  che attraversa i confini dell’applicativo
• si conta un solo DET per la capacità del processo di inviare messaggi di risposta all’utente
• si conta un solo DET per la capacità di iniziare una determinata azione, anche se sono possibili diversi modi
• non si considerano nel conteggio gli attributi usati dai processi ma che non attraversano i confini dell’applicativo, nè i pulsanti di navigazione o gli attributi tipici di una stampa come i numeri di pagina

Definiti FTR e DET è possibile stabilire la complessità delle transaction function tramite le seguenti tabelle:

Complessità degli EI

Complessità degli EO/EQ

Individuata la complessità è possibile assegnare un punteggio alla singola transaction function secondo questa tabella

• identificare e raggruppare i dati in data function
• classificare i data function in ILF e ELF
• per ogni data function individuare i DET
• per ogni data function individuare i RET
• determinare la complessità della singola data function
• determinare il punteggio della singola data function

Nell’indentificazione dei data function consideriamo solo gruppi di dati riconosciuti dall’utente, mentre eventuali dati non espressamente richiesti non vengono considerati. Ad esempio i dati di audit se non espressamente richiesti da un requisito utenti non vengono considerati nel conteggio.

Nella distinzione tra ILF e ELF è importante stabilire l’applicativo che gestisce il data function individuato. Se la gestione è in carico al nostro applicativo si identifica come ILF, in caso contrario come ELF. Ad esempio nell’invocazione di un servizio esterno l’entità logica scambiata viene mappata come ELF.

Nel conteggio dei DET consideriamo solo gli attributi univoci riconoscibili dall’utente.

Nel conteggio dei RET consideriamo un RET per ogni data function individuato. Per ogni gruppo di DET individuato viene aggiunto un RET

Stabiliti il numero di DET e RET è possibile stabilire la complessità dei data function secondo la seguente tabella:

		DETs
		1-19	20-50	>50
RETs	1	Bassa	Bassa	Media
	2-5	Bassa	Media	Alta
	>5	Media	Alta	Alta

Individuata la complessità è possibile assegnare un punteggio alla singola data function secondo questa tabella

• Raccogliere la documentazione disponibile
• Determinare il tipo di conteggio, i confini del nostro sistema e identificare i requisiti utenti funzionali
• misurare le data function, individuando ILF e ELF
• misurare le transaction function, individuanto EI, EO e EQ
• calcolare i function point
• documentare i function point
• restituire il risultato del punteggio secondo specifica

La documentazione disponibile deve permettere di definire tutte le nuove funzionalità richieste al software o le eventuali modifiche richieste per le funzionalià esistenti.

Raccolta la documentazione occorre stabilire quale è l’obiettivo del conteggio, perchè esso influenzerà le nostre valutazioni successive. Fondamentalmente sono 3 gli scenari che si prospettano:

• Misurare la complessità dello sviluppo di un progetto
• Misurare la complessità di una evolutiva
• Misura la complessità di un’applicazione

In questo articolo ci limiteremo a vedere quelli propedeutici all’applicazione della metodologia:

• Elementary Process – individuano la più piccola attività individuata dall’utente.
• data function – individuano funzionalità che soddisfano un requisito di storage di entità interne o esterne al sistema
• transactional function – sono dei processi elementari che permettono all’utente di processare i dati

I data function si distinguono in 2 categorie:

• ILF – Internal Logical File – individuano un gruppo di dati o informazioni di controllo riconosciuti dall’utente, la cui gestione avviene all’interno del nostro software
• EIF – External Interface File – individuano un gruppo di dati o informazioni di controllo riconosciuti dall’utente,utilizzati all’interno del nostro software ma la cui gestione è di competenza di un altro software.

I componenti sinora visti ILF, EIF, EI, EQ e EO sono definiti BFC (Base Functional Component). Essi indicano gli elementi in cui è scomponibile un requisito funzionale. Ad esempio il requisito funzionale ‘gestione di un libro’ si scompone in requisisti più semplice: inserimento, visualizzazione e modifica del libro. Per maggiori dettaglia rimando alla specifica [ISO/IEC 14143-1:2007, definition 3.1], che definisce i BFC elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes

Nella definizione della complessità delle BFC un ruolo fondamentali assumono i seguenti elementi

• DET – Data Element Type – individuano attributi unici, riconoscibili dall’utente e non ripetuti.
• RET – Record Element Type – individuano un set di DET usati da una data function
• FTR – File Type Referenced -individuano le data function lette o gestite da transactional function

Nel prossimo articolo vedremo come usare questi componenti per misurare il nostro software.

L’unità di misura function point è stata individuata per la prima volta da Allan Albrecht nel 1975, e la relativa metodologia per il suo calcolo ha subito nel tempo diverse evoluzioni fino all’ultima versione 4.3.1 ad opera di una associazione internazionaleIFPUG – International Function Point Users Group. IFPUG opera dal 1986 perseguendo come obiettivo il miglioramento continuo dell’analisi dei function point.

In Italia è presente la GUFPI-ISMA – GRUPPO UTENTI FUNCTION POINT ITALIA ITALIAN SOFTWARE METRICS ASSOCIATION – l’associazione italiana per la promozione, la diffusione e lo sviluppo delle tecniche quantitative di misurazione del software, inclusi i metodi di misurazione della dimensione funzionale Function Point COSMIC e IFPUG.

I vantaggi dell’adozione di una metrica per la misurazione della dimensione di un software sono diversi:

• permette una stima dei costi e delle risorse necessarie per lo sviluppo software, valorizzazione e manutenzione;
• fornisce un fattore di normalizzazione per il confronto di software diversi;
• permette di determinare la dimensione di un software acquistato in base alle funzionalità offerte;
• permette di valutare i vantaggi offerti da un software in base ai punti funzioni ad esso associato.

Va precisato che i Function Point misurano esclusivamente i requisiti funzionali e pertanto sono indipendenti dalla tecnologia utilizzata per lo sviluppo del software. Per i requisiti non funzionali, ad esempio requisiti prestazionali o implementativi, occorre utilizzare altre metriche.

Nei prossimi articoli vedremo le regole, le definizioni e gli step da seguire per applicare la metodologia.