Function Points nei progetti software

Per quanto riguarda le stime di progetto, nei progetti di sviluppo software ci si è per lungo tempo basati sul numero di linee di codice stimate per ricavare il valore dell’impegno necessario (effort).

La valutazione a linee di codice, anche se molto semplice da comprendere, non risolve il problema  in quanto costituisce una valutazione molto imprecisa in questo tipo di progetti poichè soggetta a forte volatilità. Nel 1979 A. J. Albrecht, della IBM Corporation, pubblicò un rapporto su una nuova metodologia di misurazione del software, chiamata function points (punti funzionali).

Questa metodologia fu a suo tempo resa di dominio pubblico dalla IBM, ed ha raggiunto un notevole successo, tanto che buona parte degli attuali software per la stima di progetti EDP continuano ad essere basati su questo approccio.

La teoria dei function points, in pratica, “conta” quante funzioni elementari vengono fomite all’utente (numero dei campi in output su schermata, numero dei campi aggiornabili, numero delle schermate o pagine web ecc.). Considera poi il numero di database utilizzati dall’applicazione e il numero di interfacce. Da buon ultimo considera alcuni fattori di complessità che possono far variare i calcoli precedenti fino a un 25% in più o in meno. Questi fattori di complessità valutano il tipo di ambiente in cui l’applicazione viene sviluppata, l’interattivita o meno dell’applicazione ecc.

Calcolati i function points di un’applicazione, si può usare una matrice in cui viene inserita la produttività attesa (quanti punti funzionali per mese uno sviluppatore è in grado di realizzare), e si ottiene la stima dell’impegno tecnico necessario alla realizzazione dell’applicazione.

Visto però che spesso la produttivita delle persone non è generalizzabile, i dati di stima saranno tanto più validi quanto più si potrà influire sui suoi parametri di calcolo. E’ un tentativo di approccio al problema che, seppur non risolutivo al 100%, è comunque migliore di quello a suo tempo tentato con le linee di codice.

I punti “forti” di questa metodologia sono molti:

• Il conteggio è basato sui criteri di utilizzo del software da parte dell’utilizzatore.
• Essendo basata sull’aspetto estemo dell’applicazione, lascia più flessibilità alla fase di realizzazione (l’importante è fornire le funzioni previste).
• Rimuove la pesante dipendenza dal numero di linee di codice da stimare.
• Quando usata come misura di produttività non penalizza chi utilizza linguaggi “evoluti” e ottimizza i programmi sviluppati (anzi, dimostra che c’è un aumento di produttività effettiva, in quanto vengono date più funzioni agli utenti finali).

I punti “deboli” sono pochi, anche se interessanti:

• Il processo di stima richiede tempo. Contare tutte le schermate (campo per campo), le funzioni, i dati ecc. è un’impresa che può occupare settimane di lavoro intenso.
• Un calcolo realistico può essere fatto solo quando le idee su cosa bisogna sviluppare sono ben chiare, in pratica dopo la fase di progettazione esterna.

Oltre alla produttività in fase di realizzazione, i function points possono essere usati per valutare i requisiti di supporto per i sistemi nella successiva fase di manutenzione . In questa analisi, la produttività è determinata dal calcolo del numero di punti funzionali che ciascuno sviluppatore è mediamente in grado di supportare per un dato sistema in un anno (ossia FP / FTE anno).

I valori ottenuti consentono di identificare i sistemi o le componenti software che richiedono il massimo supporto. L’analisi aiuta quindi un’organizzazione a sviluppare una strategia di manutenzione e sostituzione di quei sistemi che hanno esigenze di manutenzione più elevate.

La gestione delle modifiche all’ambito di progetto è un altro vantaggio chiave della Function Point Analysis.

Una volta che un progetto è stato approvato ed il numero di function points è stato stabilito, diventa un compito relativamente facile identificare, tracciare e comunicare nuove richieste di modifica. Ogni richiesta viene valutata in termini di impatto e di nuovi punti funzionali da realizzare.

Questo risultato viene poi utilizzato per determinare l’effort ed il nuovo budget richiesto. E’ quindi possibile determinare l’importanza di ogni richiesta assegnando ad ognuna un diverso livello di priorità.

Alla conclusione del progetto il numero finale di function points può essere valutato in rapporto alle stime iniziali per determinare l’efficacia delle tecniche di raccolta dei requisiti utilizzate. Questa analisi aiuta a identificare le opportunità per migliorare il processo di definizione dei requisiti.

La comunicazione dei requisiti funzionali è oltretutto l’obiettivo per cui fu a suo tempo sviluppata la tecnica dei function points. Dal momento che evita la terminologia tecnica e si concentra sulle esigenze degli utenti, è un veicolo eccellente per comunicare con gli utenti. La tecnica può essere utilizzata per indirizzare le interviste agli utenti e documentare i risultati della progettazione. La documentazione risultante fornisce un quadro che descrive sia i requisiti funzionali che i requisiti tecnici.

In conclusione, l’analisi dei function points ha dimostrato di essere una tecnica accurata per il dimensionare, documentare e comunicare le capacità di un sistema.