|
L'uomo è il computer più straordinario di tutti
|
|
|
|
|
Misurare il software con i Function Points
By
Monica Lelli
29 maggio 2007
|
 |
|
Da sempre i responsabili IT si pongono il problema di quantificare la consistenza dei propri sistemi software per dar luogo ad una valutazione sostanziale, economica e patrimoniale degli stessi. Oggi i Function Points vengono utilizzati dalle aziende e nei gruppi di lavoro per gestire, controllare e migliorare i processi di produzione.
Sono utilizzati anche dalla Pubblica Amministrazione per definire e governare i costi e le caratteristiche delle le forniture di sviluppo e di manutenzione del software nonché per valutare la qualità e i livelli di servizio.
Il presente articolo vuole offrire una panoramica dei Function Points, il metodo di conteggio ed il loro campo di applicazione.
|
|
|
Function Points & Software Measurement
|
top
|
I Function Points (FP) si collocano all’interno di una più ampia disciplina conosciuta come Software Measurement, misurazione del software, appunto, il cui oggetto è la quantificazione degli attributi dimensionali e qualitativi dei prodotti software e delle attività correlate al loro sviluppo (i processi).
I Function Point rilevano la dimensione funzionale del software a partire dai requisiti funzionali, indipendentemente dal modo in cui questi vengono espressi, ad esempio, specifiche, manuali utente, diagrammi e disegni logici, ecc.
La tecnica per la misurazione è la Function Point Analysis (FPA). Tale tecnica è descritta nell'apposito manuale rilasciato dall’IFPUG (International Function Point Users Group), il Counting Practices Manual, ed è disponibile anche in lingua italiana grazie ad una traduzione realizzata dal GUFPI (Gruppo Utenti Function Point Italia).
La FPA è uno standard internazionale per la misurazione funzionale riconosciuto a livello ISO (International Organization for Standardization) che dimensiona la parte funzionale del software, ovvero, considera le funzionalità in esso contenute a partire dal punto di vista dell’utente finale e indipendentemente da considerazioni di tipo tecnico come linguaggi, piattaforma, architettura, ecc.
|
|
Campo di applicazione dei Function Points
|
top
|
Come avviene in molte realtà produttive, la misurazione si realizza allo scopo di avere uno strumento obiettivo di analisi, valutazione e confronto delle proprie e altrui capacità e mezzi di produzione. In questo senso e poiché la dimensione funzionale, derivante dalla quantificazione delle funzionalità logiche di un applicativo, costituisce uno dei fattori di costo più rilevanti nella produzione del software, viene spesso utilizzata per le seguenti attività:
- stima dei costi e delle risorse necessarie per lo sviluppo e la manutenzione del software, ad esempio: costo per FP;
- determinazione del livello di produttività di un progetto dopo il rilascio, ad esempio: ore di sviluppo/FP sviluppati;
- attività di benchmarking e confronto di processi di sviluppo e software diversi, ad esempio: ore di sviluppo/FP sviluppati tra organizzazioni diverse;
- stima dei costi di manutenzione del patrimonio software di un organizzazione, ad esempio: impegno/numero FP in esercizio;
- valutazioni di tipo qualitativo, ad esempio: difetti nel primo anno/FP; numero di casi di test/FP.
|
|
Procedura di conteggio
|
top
|
|
Di seguito viene illustrata, a grandi linee, la procedura per il conteggio dei Function Points e le sue componenti:
Individuare l'obiettivo e determinare il tipo di conteggio
L'obiettivo del conteggio stabilisce il motivo per cui viene realizzato, ad esempio: misurazione per un nuovo progetto di sviluppo; per la stima di un progetto di manutenzione evolutiva, ecc.
Tipo di conteggio, la FPA prevedere tre tipi di conteggio:
Conteggio di nuovo sviluppo software: misura le funzioni che verranno fornite all'utente finale con il progetto fino al primo rilascio del software (con la prima installazione, comprese eventuali funzionalità associate alla conversione di dati).
Conteggio di un progetto di manutenzione evolutiva, misura le nuove funzionalità “aggiunte”, le funzionalità “modificate” e le funzionalità “cancellate” dall'applicazione.
(Si pensi a questo tipo di conteggio come a un progetto di ristrutturazione di una casa dove ad esempio si elimina un bagno si crea una nuova camera e si ingrandisce la cucina, la sommatoria della superficie di ognuno di questi ambienti produrrà la dimensione dell’intervento). L’utilizzo di questo tipo di conteggio può essere di utilità per stimare il costo dell’intervento.
Conteggio di Baseline, FP Installati: misura la dimensione di una base installata di applicazioni (come se fosse una misurazione in metri quadri di un’immobile). Rappresenta le dimensioni delle funzioni che l'applicazione o un gruppo di applicazioni forniscono all'utente. Questo tipo di conteggio è utile quando si desiderano confrontare aspetti tra applicazioni diverse. Ad esempio: numero di difetti per FPs, costo per FP, oppure per rilevare il parco software in un’organizzazione per scopi patrimoniali.
|
|
Elementi di base per il conteggio in Function Point
|
top
|
|
La dimensione in Function Point di un'applicazione viene determinata a partire dall'identificazione delle sue componenti logiche, classificate come:
ILF - Internal Logical File, Dati mantenuti internamente
EIF - External Interface File, Dati esterni referenziati
EI - External Input, Funzionalità di Input
EO - External Output, Funzionalità di Output
EQ - External Inquiry, Funzionalità di Inquiry
ILFs - Internal Logical Files: sono raggruppamenti di dati logici, entità logiche mantenute dall’applicazione.
EIFs - External Interface Files: sono raggruppamenti di dati logici, entità logiche solo referenziate (in lettura) dall’applicazione oggetto di misurazione ma mantenute (aggiornate) da un’altra applicazione.
EIs - External Inputs: sono transazioni o “processi logici elementari” che consentono l'immissione dei dati nell’applicazione allo scopo di mantenere un ILF, oppure, transazioni che attraverso l’immissione di dati di controllo o di configurazione permettono di assicurare il funzionamento del sistema in base alle esigenze espresse dall’utente.
EOs - External Outputs: sono transazioni o “processi logici elementari” che presentano dati all’utente e sono caratterizzati da un'elaborazione matematica, calcoli semplici o complessi in base alle esigenze espresse dall’utente. Possono essere EO, ad esempio: reports, videate, riepiloghi, ecc.
EQs - External Inquiries: sono transazioni o “processi logici elementari” che presentano dati all’esterno del confine dell’applicazione ma non realizzano calcoli matematici, semplici o complessi, semplicemente reperiscono e mostrano i dati all’utente. Possono essere EQ, ad esempio: reports semplici senza calcoli, liste, videate, ecc.
Per chiarezza, nella figura sono rappresentate le diverse componenti del software secondo la FPA.
E’ importante sottolineare che le componenti logiche si riferiscono sempre a obiettivi funzionali che l’utente finale del software è in grado di riconoscere, tali requisiti sono rilevabili indipendentemente da fattori di tipo tecnico o implementativo.
Ad esempio, un componente di tipo ILF può non avere una corrispondenza diretta con una tabella o database fisico, d’altra parte più tabelle potrebbero invece rappresentare un unico ILF, tutto ciò è fortemente influenzato dalla visione dell’utente finale. A questo scopo possono essere molto utili per il conteggio dei FP i diagrammi concettuali dei dati oppure, nel caso di documentazione UML, le classi di business.
|
|
Complessità delle componenti e calcolo del numero di FP non pesati
|
top
|
La complessità viene determinata per ognuno dei componenti e dipenderà a sua volta dalla quantità di determinati attributi associati ai componenti, specificamente:
- dal numero di DET (elementi di tipo dato) o campi riconoscibili dall’utente,
- dal numero di RET (record elements type) elementi di tipo record o sottoinsiemi di dati appartenenti ad un gruppo logico di dati, considerati solo per il dimensionamento degli ILF ed EIF ed infine,
- dagli FTR, File Type Referenced, i gruppi logici di dati referenziati, in lettura o in scrittura, da una transazione.
Le tabelle per la determinazione della complessità non sono riportate nel presente articolo, per sinteticità, comunque a seconda del numero di DET e RET per i dati e, dei DET e FTR per le transazioni, si arriva alla determinazione uno dei tre livelli di complessità previsti: Bassa, Media o Alta, a cui corrispondono un predefinito numero di UFP (Unadjusted Function Points).
La seguente tabella riassume i pesi in UFP delle diverse componenti a seconda della loro complessità.
La parte finale del conteggio prevede un possibile aggiustamento di questi valori attraverso il calcolo del VAF (Value Adjustment Factor)
Calcolo del "Value Adjustment Factor" (VAF ) e calcolo dei FP pesati.
Il VAF è un fattore che tiene conto di alcune caratteristiche non funzionali dell’applicazione, identificate come Caratteristiche Generali del Sistema (GSC) e di seguito brevemente elencate:
1. Comunicazione dati.
2. Distribuzione dell'elaborazione.
3. Prestazioni.
4. Utilizzo intensivo configurazione.
5. Frequenza delle transazioni.
6. Inserimento dati interattivo.
7. Efficienza per l'utente finale.
8. Aggiornamento interattivo.
9. Complessità elaborativi.
10. Riusabilità.
11. Facilità di installazione.
12. Facilità di gestione operativa.
13. Molteplicità di siti.
14. Facilità di modifica.
La valutazione di ognuna di queste caratteristiche, in una scala che va da 0 a 5, interviene in un’equazione per il calcolo del Valore di Aggiustamento (VAF).
VAF = 0.65 + (S of GSCs x 0.01)
Infine, il calcolo del valore finale dei FP aggiustati, si ricava dalla semplice formula:
Function Points= UFP * VAF,
dove UFP sta per Unadjusted Function Point, ovvero i Function Point non pesati calcolati nei passi precedenti.
Il VAF può modificare il valore UFP in un range massino del +/- 35% rispetto al valore iniziale, tuttavia, in molte organizzazioni si opta per non usarlo ( VAF=1 ) in modo tale da non alterare il valore funzionale puro dell’applicazione (UFP).
Tale pratica deriva anche dal fatto che il VAF essendo un fattore che riconsidera gli aspetti non-funzionali, non è riconosciuto dallo standard ISO come parte integrante della metrica funzionale propriamente definita.
Infine, aggiustamenti non-funzionali, che potremo considerare proprietari, vengono eventualmente adottati dalle organizzazioni in funzione di specifiche esigenze e linee guida interne.
|
|
Formule di calcolo di Function Points
|
top
|
Il Function Points possono essere calcolati per diversi scopi, in ogni caso ci sono delle formule da applicare.
Dimensioni di un Progetto di sviluppo:
FP = (UFP + CFP) • VAF
Dimensioni di un Progetto di Manutenzione Evolutiva:
FP = [(ADD + CHGA + CFP) • VAFA] + (DEL • VAFB)
Dimensione di un applicazione:
FP = UFP • VAF
Dimensione di un applicazione dopo un intervento di manutenzione evolutiva:
FP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] • VAFA
ADD = FP non pesati delle funzionalità applicative aggiunte dalla manutenzione
CFP = FP non pesati delle funzionalità di conversione
CHGA = FP non pesati delle funzionalità modificate dalla manutenzione (dopo)
CHGB = FP non pesati delle funzionalità modificate dalla manutenzione (prima)
DEL = FP non pesati delle funzionalità cancellate dalla manutenzione
VAF = VAF dell’applicazione
VAFA = VAF dell’applicazione dopo la manutenzione
VAFB = VAF dell’applicazione prima della manutenzione
UFP = FP non pesati delle funzionalità applicative
UFPB = FP non pesati delle funzionalità applicative, prima della manutenzione (se non disponibile, si calcola dividendo il numero di FP pesati dell’applicazione prima della manutenzione per il VAFB)
|
|
Esempio semplice di calcolo dei Function Points di un’applicazione
|
top
|
Quanto segue è riportato a titolo esemplificativo.
Supponiamo di avere un applicativo per la gestione di una biblioteca, ovvero per gestire i testi, i relativi prestiti e i soci iscritti. I dati e i servizi che l’applicativo consente di gestire determinano di per sé il confine dell’applicazione e l’utente in questo caso è il bibliotecario.
Per iniziare il conteggio si individuano le entità di dati riconoscibili dall’utente bibliotecario (l’utente finale del sistema) che conformeranno i raggruppamenti logici dell’applicazione da conteggiare, in questo caso, l’utente riconosce: dati sui Testi, i Soci e i Prestiti, da cui si ricavano 3 raggruppamenti logici o ILF, supponiamo che questi siano di complessità Bassa.
L’applicazione inoltre consente all’utente bibliotecario di svolgere le seguenti azioni
Il conteggio complessivo si ottiene semplicemente moltiplicando il numero di componenti di ogni tipo per la rispettiva complessità e sommandone i totali. Nella seguente tabella è riepilogata la misurazione dell’esempio fornito.
Assumendo, per semplicità e per rendere leggero e veloce l’esempio, che tutti i processi e i raggruppamenti di dati siano di bassa complessità la dimensione funzionale dell’applicazione conteggiata è pari a 58 UFP (Unadjusted Function Points) con un VAF=1, 58 FP.
Se per la realizzazione dell’applicazione fossero richiesti 40 giorni/persona per 2 mesi e con una spesa complessiva di 15.000 € si potrebbero ricavare i seguenti indicatori:
produttività media: 40 gg/p / 58 FP= 0,69 gg/p per ogni FP
velocità di produzione: 58 FP / 40 giorni = 1,45 FP/giorno
costo per unità di prodotto software pari a: 15.000€/58 FP= 259 €/FP
Come descritto all’inizio del articolo, questo tipo di informazioni sui progetti consente di eseguire analisi e confronti di vario genere nonché, con dati storici sui progetti, costruire una base informativa di riferimento per la stima di nuovi progetti.
|
|
Vantaggi e svantaggi della FPA
|
top
|
Vantaggi:
• È uno standard
• Misura le funzionalità dal punto di vista utente;
• È indipendente dalle tecniche e dalle tecnologie;
• È disponibile fin dalle prime fasi del ciclo di vita del software;
• Supporta in modo obiettivo rapporti tra acquirente e fornitore.
Svantaggi:
• Le matrici di complessità previste dal metodo impongono dei limiti nella quantificazione funzionale di componenti particolarmente complessi;
• No rilevano in modo efficace la dimensione di applicazioni real time o del middleware; di fatto, vengono principalmente utilizzati in software di tipo gestionale dove la parte dati e funzioni è sufficiente per descrivere il software;
• Non sono rilevabili in maniera automatica, occorre un analista con conoscenza della FPA, preferibilmente certificato CFPS.
|
|
Conclusione e riferimenti
|
top
|
|
La misurazione del software rappresenta un campo relativamente giovane dell'Ingegneria del Software. I Function Points sono già una metrica di riferimento in molte attività collegate con la stima, il benchmarking, la gestione della qualità e la valutazione del livello di maturità dei processi di sviluppo software, come ad esempio il CMM (Capability Maturity Model del SEI).
La quantificazione della dimensione del software, come illustrato, supporta le attività budgeting e pianificazione dei progetti, nonché le analisi sia quantitative che qualitative, di prodotto e di processo. In Italia segnalo tra le iniziative in corso, le “Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione” pubblicate dal CNIPA dove si danno indicazioni su una serie di metriche e indicatori per il software, tra cui i FP.
L’aspettativa è che oggi più di ieri la stima e la gestione del processo software siano supportate dall’integrazione di misure, metriche e indicatori quantitativi e qualitativi ma mai in sostituzione della fiducia nelle capacità umane e professionali dei professionisti del settore. Una metrica emergente, considerata da molti come un’evoluzione della Function Point Analisys è la metrica COSMIC-FFP (Full Function Point). Tale metrica consente di rilevare in maniera più granulare la dimensione funzionale del software, anche per sistemi real-time.
Per eventuali chiarimenti e ulteriori informazioni in merito potete contattare l’autore m.lelli(AT)tiscali.it CFPS (Certified Function Point Specialist).
Riferimenti utili:
Libro: Metriche del software. Esperienze e ricerche. Edizioni Franco Angeli.
Libro: Misurare il software. Quantità, qualità, standards e miglioramento di processo nell’Information & Comunication Technology (2e)
Sito: ISBSG - International Software Benchmarking Standard Group
|
|
|
| |
| JavaPortal è ideato da: |
 |
Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto licenza Creative Commons
|
|
|
Documentazione
>
