Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 4 di 107
Sommario della tesi (Abstract)
In questo capitolo è descritta brevemente la tesi svolta enunciando l‘obiettivo primario che ci si è
posto con il presente lavoro, le modalità con cui è stato condotto il lavoro, i risultati conseguiti e la
relativa valutazione finale.
Per migliorare la comprensione del lavoro svolto è stato dedicato un intero capitolo alla descrizione
della metrica di misurazione e stima dei Function Point ed un altro capitolo sul progetto oggetto di
conteggio.
La tesi include una descrizione sintetica dei criteri e dei metodi di conteggio dei Function Point
adottati in un progetto reale di grande complessità realizzato da un‘azienda di software italiana per
la Pubblica Amministrazione (PA).
Obbiettivi ed ambito della tesi
L‘obbiettivo principale della tesi svolta è di quantificare gli attributi dimensionali e qualitativi per
un progetto software complesso per la Pubblica Amministrazione.
La tesi consiste quindi nell‘individuare le caratteristiche di un progetto complesso realizzato per la
PA e quantificare la grandezza, in termini funzionali, di tale progetto.
Modalità di conduzione del lavoro
Il lavoro svolto è stato condotto secondo la sequenza che segue:
Prima di tutto si è studiato a fondo la teoria della Function Point Analysis allo stato dell‘arte in
questo settore specifico da parte dell‘ingegneria del software. In particolare, si è fatto ricorso alle
lezioni seguite all‘università, ai manuali disponibili ed alla Rete.
In secondo luogo si sono studiate le caratteristiche dei progetti complessi per capire quale strategia
fosse ritenuta più adatta per effettuare una misurazione affidabile dell‘applicazione.
Come terzo passo si sono studiate le caratteristiche dei progetti complessi realizzati per la Pubblica
Amministrazione. In altre parole si è calato quanto studiato in generale sui progetti complessi in un
mondo reale come quello della PA. Il tema è stato affrontato studiando i quaderni pubblicati dal
CNIPA (Autorità Nazionale per l‘Informatica nella Pubblica Amministrazione). In particolare, si
sono studiati ―i Quaderni, numero 26 e numero 27‖ che trattano appunto il tema in oggetto.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 5 di 107
Come quarto argomento si è studiata la strategia più adatta a gestire progetti complessi e la relativa
strategia per la misurazione del software. La strategia studiata è quella utilizzata da una importante
azienda di software italiana (Insiel S.p.A.) in progetti simili. In sintesi, la strategia di conduzione del
progetto è quella di scomporre il progetto in progetti di dimensioni e complessità minore. Ciascuno
di questi progetti è gestito come un singolo progetto da parte dei team leader cui esso è affidato,
lasciando al Capo Progetto di maggiore esperienza la gestione complessiva dell‘intero progetto.
Ciascun progetto include le attività di misurazione proprie per la parte sviluppata. La misurazione
complessiva dell‘intero progetto consiste nell‘integrazione di tutte le misurazioni effettuate sui
―sotto-progetti‖.
Come ultima parte del lavoro, si è descritto come ―caso di studio‖ l‘esperienza maturata nel
―Progetto SIAC‖. Nel caso reale descritto si è infatti adottata proprio la strategia menzionata sopra.
Risultati Conseguiti
Durante la produzione del conteggio sono state incontrate non poche difficoltà, come l‘alta
complessità del progetto caso di studio, che sono state ovviate grazie alle esperienze
precedentemente acquisite da conteggi analoghi che hanno portato a produrre una misurazione
realistica e attinente alle aspettative.
Valutazione Finale
La valutazione finale del lavoro svolto si può considerare positiva in quanto la strategia di sviluppo
adoperata (scomposizione del progetto in sotto-progetti) e i relativi metodi e criteri di misurazione
adoperati (integrazione e relativo collaudo) si sono dimostrati efficaci ai fini della realizzazione del
prodotto finale riducendo i rischi legati proprio alla complessità e dimensioni del progetto.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 6 di 107
1 Teoria del calcolo dei Function Point
Questo capitolo ha lo scopo di fornire una chiara e dettagliata descrizione del conteggio dei function
point, la fonte normativa per il conteggio dei Function Point IFPUG è il Manuale delle Regole di
Conteggio (CPM – Counting Practices Manual), versione 4.2, edito nel 2005 dall‘IFPUG; copia
ufficiale del manuale e ulteriori riferimenti sono disponibili, previa registrazione, presso il sito web
ufficiale dell‘organizzazione (www.ifpug.org).
1.1 Cenni storici
L‘interesse verso i Function Point è iniziato in Italia agli inizi degli anni ‘90, negli USA negli anni
‘80, anche se il metodo è stato definito in IBM da Allan Albercht nella seconda metà degli anni ‘70.
La misura più utilizzata era in quegli anni la Linea di codice, ma il FP, grazie anche ad associazioni
come IFPUG e l‘ISO (International Organization for Standardization), è diventata nel tempo una
misura di dimensione standard. In Italia la metrica è utilizzata in varie organizzazioni e
l‘associazione italiana GUFPI/ISMA è il riferimento degli utenti dei Function Point.
1.2 Diagramma di procedura del conteggio
Prima di iniziare la procedura di un conteggio, occorre determinare la fase del ciclo di vita
dell‘applicazione, o progetto, e se si sta effettuando una approssimazione (stima) o una misura.
In ambo i casi è necessario documentare qualsiasi assunzione.
L‘approssimazione permette di fare delle assunzioni sulle funzionalità e/o sulla loro complessità
non conosciute, al fine di poter effettuare una analisi dei function point.
La misura include l‘identificazione di tutte le funzionalità e della loro complessità al fine di poter
effettuare una analisi dei function point.
In seguito alla determinazione della fase del ciclo di vita si procede con l‘analisi utilizzando come
linea guida il diagramma della procedura di conteggio mostrato nella figura sottostante, Figura 1.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 7 di 107
Figura 1 – Diagramma della Procedura di conteggio
1.3 Tipo di Conteggio
Il primo passo nella procedura per il conteggio dei function point è quello di individuare il tipo di
conteggio.
Il conteggio dei function point può essere associato, come già accennato, ad un progetto o ad
un‘applicazione. Sono definiti tre tipi di conteggio:
Progetto di sviluppo: il numero di function point per questo tipo di progetto misura funzioni
fornite all‘utente finale quando il progetto è stato realizzato e si effettua la prima
installazione del software;
Progetto di manutenzione evolutiva: il numero di function point misura le modifiche
apportate ad una applicazione già esistente. Tali modifiche comportano aggiunte,
cambiamenti o cancellazioni di funzioni utente ad un progetto già realizzato;
Applicazione: il numero di function point è associato ad un‘applicazione installata. Esso è
anche denotato come numero di function point della baseline o installati. Questo numero
costituisce una misura delle attuali funzioni che l‘applicazione fornisce all‘utente.
1.4 Ambito del Conteggio e del Confine dell’Applicazione
La definizione dell‘ambito del conteggio e del confine dell‘applicazione è fortemente influenzata
dall‘obbiettivo del conteggio che consiste nel fornire risposte ad un problema applicativo.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 8 di 107
1.4.1 Definizione dell’ambito del conteggio
L‘ambito del conteggio definisce le funzionalità che dovranno essere incluse in un particolare
conteggio di function point.
L‘ambito di:
Un conteggio per un progetto di manutenzione evolutiva include tutte le funzionalità che
sono state aggiunte, variate e cancellate;
Un conteggio per un progetto di sviluppo include tutte le funzionalità coinvolte dalle attività
del progetto;
Un conteggio per un‘applicazione può includere, in base all‘obiettivo:
Solo le funzionalità che sono utilizzate dagli utenti
Tutte le funzionalità disponibili
1.4.2 Definizione del confine dell’applicazione
Il confine dell‘applicazione indica la linea di separazione fra il software oggetto di misura e
l‘utente.
Il confine dell‘applicazione:
Definisce che cosa è esterno all‘applicazione
È l‘interfaccia concettuale tra l‘applicazione, che costituisce l‘―interno‖, e il mondo utente,
che costituisce l‘―esterno‖
Agisce come una ―membrana‖ attraverso la quale i dati elaborati dalle transazioni (EI,EO ed
EQ) entrano ed escono dall‘applicazione
Comprende i dati logici mantenuti dall‘applicazione (ILF)
Aiuta a identificare i dati logici referenziati ma non mantenuti dall‘applicazione (EIF)
Dipende dal punto di vista applicativo esterno che ha l‘utente sull‘applicazione. È
indipendente da considerazioni tecniche e/o di natura implementativi.
1.5 Funzioni di Tipo Dati
Le funzioni di tipo dati rappresentano le funzionalità fornite all‘utente per soddisfare i requisiti
relativi ai dati interni ed esterni. Le funzioni di tipo dati sono definite come file logici interni (ILF,
Internal Logical Files) e file d‘interfaccia esterni (EIF, External Interface Files).
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 9 di 107
Le procedure di conteggio degli ILF e degli EIF includono le due attività seguenti:
1. Identificare gli ILF e gli EIF.
2. Determinare la complessità degli ILF e degli EIF ed il loro contributo al numero di function
point.
1.5.1 File Logici Interni
Un file logico interno (ILF) è un gruppo di dati logicamente collegati o di informazioni di controllo,
riconosciuti dall‘utente, mantenuti all‘interno del confine dell‘applicazione. L‘intento primario di
un ILF è contenere dati mantenuti da uno o più processi elementari dell‘applicazione sottoposta al
conteggio.
Tutte le seguenti regole di conteggio devono valere affinché le informazioni possano essere contate
come un ILF.
o Il gruppo di dati o di informazioni di controllo è un gruppo di dati logico e riconoscibile
dall‘utente.
o Il gruppo di dati è mantenuto da un processo elementare all‘interno del confine
dell‘applicazione che si sta misurando.
Di seguito è mostrata la tabella di conversione per gli ILF, utilizzata per convertire gli ILF in
function point non pesati.
Valore Complessità
Funzionale
Function Point non
Pesati
Bassa 7
Media 10
Alta 15
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 10 di 107
1.5.2 File d’Interfaccia Esterni
Un file d‘interfaccia esterno (EIF) è un gruppo di dati logicamente collegati o di informazioni di
controllo, riconoscibile dall‘utente, referenziati dall‘applicazione ma mantenuti all‘interno del
confine di un‘altra applicazione. Ciò significa che un EIF contato per un‘applicazione deve essere
un ILF, o parte di un ILF, in un‘altra applicazione.
Tutte le seguenti regole di conteggio devono valere affinché le informazioni possono essere contate
come un EIF.
o Il gruppo di dati o di informazioni di controllo è un gruppo di dati logico e riconoscibile
dall‘utente.
o Il gruppo di dati è referenziato dall‘applicazione che si sta misurando ed è ad essa esterno.
o Il gruppo di dati non è mantenuto dall‘applicazione che si sta misurando.
o Il gruppo di dati è mantenuto in un ILF di un‘altra applicazione.
Di seguito è mostrata la tabella di conversione per gli EIF, utilizzata per convertire gli EIF in
function point non pesati.
Valore Complessità
Funzionale
Function Point non
Pesati
Bassa 5
Media 7
Alta 10
1.5.3 Complessità e Contributo
Il numero di ILF, EIF e la loro relativa complessità funzionale determinano il contributo delle
funzioni di tipo dati al numero di function point non pesati.
La complessità funzionale da assegnare ad ogni ILF ed EIF identificato si basa sul numero di tipi di
elemento dati (DET, Data Element Types) e tipi di elemento record (RET, Record Element Types)
associati con l‘ILF o l‘EIF.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 11 di 107
La complessità funzionale è calcolata basandosi sulla seguente matrice di complessità.
1-19
DET
20-50
DET
51 o più
DET
1 RET Bassa Bassa Media
2-5 RET Bassa Media Alta
6 o più
RET
Media Alta Alta
1.5.3.1 Data Element Types
Un tipo di elemento dati (DET) è un campo unico riconoscibile dall‘utente, non ripetuto.
Le seguenti regole si applicano quando si contano i DET:
o Contare un DET per ogni campo unico, riconoscibile dall‘utente, non ripetuto, mantenuto o
reperito da un ILF o EIF attraverso l‘esecuzione di un processo elementare.
o Quando due applicazione mantengono e/o referenziano lo stesso ILF/EIF, ma ciascuna
mantiene/referenzia DET distinti, per dimensionare l‘ILF/EIF si contano solo i DET
effettivamente utilizzati da ciascuna applicazione.
o Si conta un DET per ogni singolo dato richiesto dall‘utente per stabilire una relazione con
un altro ILF o EIF.
1.5.3.2 Record Element Types
Un tipo di elemento record (RET) è un sottogruppo, riconoscibile dall‘utente, di elementi dati in un
ILF o EIF.
Ci sono due tipi di sottogruppi:
Opzionali
Obbligatori
I sottogruppi opzionali sono quelli per cui l‘utente ha la possibilità di usarne uno o nessuno durante
un processo elementare che crea o aggiunge un‘occorrenza di dati.
I sottogruppi obbligatori sono quelli tra cui l‘utente deve utilizzarne almeno uno.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 12 di 107
Una delle seguenti regole si applica quando si contano i RET.
o Si conta un RET per ciascun sottogruppo opzionale o obbligatorio di un ILF o EIF.
oppure
o Se non ci sono sottogruppi, contare l‘ILF o l‘EIF come un solo RET.
1.5.4 Esempio ILF: Definizione Report
Requisiti Utente
L‘utente richiede la possibilità di eseguire le seguenti attività:
1. Inserire la definizione di un report che includa:
- un identificativo unico per il report,
- un nome del report,
- i campi usati nel report,
- i calcoli per generare il report.
2. Riusare il report definito in qualsiasi momento, anche per cambiare la definizione se necessario.
3. Visualizzare e stampare un report usando la sua definizione.
Interrogare le definizioni dei report esistenti utilizzando il nome del report o l‘identificativo.
Identificare gli ILF
In base ai requisiti utente, l‘identificativo report, il nome report, i campi sul report e i calcoli
costituiscono insieme un raggruppamento logico di dati per la definizione di un report, poiché sono
mantenuti come un gruppo.
La seguente tabella illustra l‘analisi per determinare se le informazioni sulla definizione di un report
sono un ILF.
Università degli studi ―Tor Vergata‖, Roma – Facoltà di Scienze MM.FF.NN.
Tesi di Laurea di Marco Ziccardi – a.a. 2006-2007 Pagina 13 di 107
ILF: Regole di Identificazione Si applica la regola?
Il gruppo di dati o di informazioni
di controllo è un gruppo di dati
logico e riconoscibile dall‘utente.
Sì. I dati sono utilizzati per
visualizzare e produrre report sulle
informazioni dell‘applicazione
RU.
Il gruppo di dati è mantenuto
attraverso un processo elementare
all‘interno del confine della
applicazione che si sta misurando.
Sì. I processi sono quelli di
aggiungere e modificare la
definizione.
In base all‘analisi, le informazioni sulla definizione di un report sono un ILF.
Contare i RET e i DET
Contare il numero di tipi di elemento dati (DET) e il numero di tipi di elemento record (RET).
Per i DET, considerare ogni campo associato con l‘ILF Definizione Report e valutare se le regole
di conteggio dei DET sono ad essi applicabili.
L‘ILF Definizione Report comprende i seguenti campi:
Nome report
Identificativo report
Campi
Calcoli
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
