Determinare il costo di sviluppo di un software è un’attività complessa che richiede più di una semplice moltiplicazione delle ore di lavoro dei programmatori. Numerosi fattori — dalla complessità del progetto alla tecnologia scelta, dall’esperienza del team alle infrastrutture necessarie — influiscono sul risultato finale. Per affrontare questa sfida, le aziende si affidano a metodologie di stima collaudate che permettono di ottenere valutazioni affidabili fin dalle fasi preliminari del progetto.
Tra le tecniche più diffuse troviamo i Function Points (FP), un approccio che si concentra sulla funzionalità offerta al cliente anziché sul codice sorgente. Questa prospettiva consente di valutare il valore reale del prodotto, indipendentemente dal linguaggio di programmazione o dalla piattaforma utilizzata. In questo articolo approfondiremo il concetto di Function Points, illustreremo il loro calcolo passo per passo e mostreremo come tradurre il risultato in una stima di costo concreta.
Seguendo una struttura chiara e ricca di esempi pratici, potrai comprendere come i Function Points rappresentino uno strumento efficace per la pianificazione, la gestione e il controllo dei progetti software, migliorando la precisione delle previsioni e favorendo decisioni più informate.
Cos’è il metodo dei Function Points
I Function Points sono un’unità di misura astratta che quantifica la quantità di lavoro necessaria a realizzare una determinata funzionalità. A differenza di metodi basati sul codice — come il conteggio delle linee di codice — i FP valutano ciò che il software deve fare per l’utente finale. Questo significa che la stima è indipendente dalla tecnologia e può essere applicata a progetti sviluppati in Java, Python, C++, o qualsiasi altro linguaggio.
Il vantaggio principale è la possibilità di confrontare progetti diversi su una base comune, focalizzandosi sulla reale utilità per il cliente. Un’app per una pizzeria, ad esempio, ha lo stesso valore funzionale sia se realizzata con React Native che con Flutter, perché le funzionalità richieste (visualizzare il menu, gestire il carrello, effettuare il pagamento, tracciare l’ordine) rimangono invariate.
Inoltre, i Function Points consentono di effettuare una stima precoce, quando le specifiche sono ancora in fase di definizione. Questo supporta la pianificazione finanziaria e la definizione di milestone, riducendo il rischio di sorprese durante lo sviluppo.
Come si calcolano i Function Points: analisi dettagliata
Il calcolo dei Function Points è un processo iterativo che parte dall’identificazione di cinque tipologie di componenti: External Interface Files (EIF), Internal Logical Files (ILF), External Outputs (EO), External Inquiries (EQ) e External Inputs (EI). Ogni componente viene valutato in base alla sua complessità — semplice, media o complessa — e assegnato un valore di FP corrispondente.
Questa fase richiede una comprensione approfondita dei requisiti, spesso ottenuta attraverso sessioni di analisi con gli stakeholder, workshop di definizione dei casi d’uso e revisioni continue dei documenti di specifica. Un’analisi completa evita errori di classificazione e garantisce che i valori di FP riflettano fedelmente la reale portata del progetto.
Il processo è iterativo: nella prima passata si identificano le funzionalità macro, nella seconda si dettagliano le transazioni, nella terza si rivalutano le classificazioni alla luce di nuove informazioni. La stima si affina gradualmente, migliorando la precisione man mano che il progetto evolve.
File di dati esterni (External Interface Files - EIF)
Gli EIF rappresentano i dati provenienti da fonti esterne al sistema, come file, database o dispositivi di terze parti. La complessità di ciascun EIF dipende dal numero di attributi e dalla struttura dei dati importati.
Nel caso della nostra app per la pizzeria, un EIF semplice potrebbe essere l’importazione della lista degli ingredienti da un file CSV con solo nome e disponibilità, valutata intorno ai 3‑5 FP. Un EIF medio potrebbe includere i dati dei corrieri, con nome, zona di competenza, orari e tariffe, attribuendo 5‑7 FP. Infine, un EIF complesso come l’integrazione con sistemi di pagamento esterni (Stripe, PayPal) richiede la gestione di token, dettagli di transazione e sicurezza, giustificando 7‑10 FP.
Questa classificazione consente di quantificare l’impatto delle dipendenze esterne sulla complessità complessiva del progetto, fornendo una base solida per la stima dei costi.
File di dati interni (Internal Logical Files - ILF)
Gli ILF sono le strutture di dati custodite all’interno del sistema. Anche qui la valutazione dipende dal numero di attributi e dalla complessità delle relazioni tra le entità.
Un ILF semplice per la pizzeria potrebbe essere la tabella “Clienti”, contenente nome, email, telefono e indirizzo, con un valore di 7‑10 FP. Un ILF medio è la tabella “Menu”, che gestisce pizze, ingredienti, allergeni, prezzi variabili e promozioni, attribuendo 10‑15 FP. Un ILF complesso è il database “Ordini”, che collega clienti, pizze, personalizzazioni, pagamenti, stato di consegna, storico modifiche e programma fedeltà, superando i 15 FP.
La corretta identificazione degli ILF è fondamentale per riflettere la densità di informazioni gestite dal software e il relativo sforzo di sviluppo.
Output esterni (External Outputs - EO)
Gli EO sono i risultati prodotti dal sistema destinati a utenti o a sistemi esterni. La classificazione dipende dalla quantità di elaborazione e dal formato di presentazione.
Un EO semplice è la stampa della ricevuta d’ordine, con i dettagli delle pizze e il totale, valutato a 4‑5 FP. Un EO medio comprende un report settimanale delle vendite con grafici per tipologia di pizza, fascia oraria e metodo di pagamento, stimato a 5‑7 FP. Un EO complesso è una dashboard analitica che fornisce previsioni di vendita basate su dati storici, stagionalità, eventi locali e meteo, con suggerimenti automatici per la gestione delle scorte, attribuendo 7‑10 FP.
Questi output rappresentano il valore aggiunto fornito al cliente e influenzano direttamente la percezione della qualità del prodotto.
Interrogazioni esterne (External Inquiries - EQ)
Le EQ sono richieste di informazioni al sistema che restituiscono dati senza trasformazioni complesse. La loro valutazione si concentra sulla semplicità della query.
Una EQ semplice è la ricerca di una pizza per nome nel menu, con un valore di 3‑4 FP. Una EQ media è un filtro avanzato che consente di ricercare pizze per ingredienti, prezzo e allergeni, valutato a 4‑6 FP. Una EQ complessa è il tracker in tempo reale dell’ordine, che combina dati interni ed esterni (posizione del corriere, stato di preparazione, tempo stimato di arrivo), attribuendo 6‑8 FP.
Le interrogazioni sono cruciali per garantire una buona esperienza utente, poiché forniscono rapidamente le informazioni richieste.
Transazioni esterne (External Inputs - EI)
Gli EI rappresentano le operazioni che ricevono dati dall’esterno e li elaborano per aggiornare il sistema, includendo logiche di business.
Un EI semplice è l’aggiunta di una pizza al carrello con validazione di disponibilità, valutato a 3‑4 FP. Un EI medio è la registrazione di un nuovo cliente con verifica dell’email, password sicura e indirizzo di consegna tramite API di Google Maps, attribuendo 4‑6 FP. Un EI complesso è il processo di checkout completo: validazione del carrello, applicazione di sconti, verifica della disponibilità degli ingredienti, elaborazione del pagamento, generazione dell’ordine, notifiche a cucina e cliente, e aggiornamento del programma fedeltà, con un valore di 6‑10 FP.
Le transazioni definiscono le interazioni chiave che generano valore per il cliente e, di conseguenza, il peso complessivo dei Function Points.
Esempio di calcolo completo: l’app della pizzeria
Per illustrare il processo, riepiloghiamo i valori di FP assegnati alle componenti della nostra app. Il ILF “Clienti” è semplice (7 FP), “Menu” è medio (12 FP) e “Ordini” è complesso (18 FP). Per gli EIF, l’import dei dati dei corrieri è medio (6 FP) e l’integrazione con i sistemi di pagamento è complessa (9 FP).
Tra gli EI, la registrazione del cliente (5 FP), l’aggiunta al carrello (3 FP), il checkout complesso (8 FP) e la modifica degli ingredienti (5 FP) contribuiscono al totale. Le EQ includono la ricerca nel menu (3 FP), il filtro avanzato (5 FP) e il tracker dell’ordine (7 FP). Infine, gli EO comprendono la ricevuta (4 FP), il report vendite (6 FP) e la dashboard analytics (9 FP).
Sommando tutti questi valori otteniamo 107 Function Points non aggiustati. Questa cifra rappresenta la dimensione funzionale grezza del progetto, ma per arrivare a una stima di costo affidabile è necessario applicare i fattori di aggiustamento.
I fattori di aggiustamento
Il metodo dei Function Points prevede 14 fattori di aggiustamento (VAF) che riflettono caratteristiche generali del sistema, come prestazioni, configurabilità, facilità di installazione e riutilizzabilità. Ogni fattore è valutato da 0 a 5; la somma totale (TDI) consente di calcolare il Value Adjustment Factor (VAF) con la formula : 0,65 + (0,01 × TDI).
Nel caso della pizzeria, i punteggi più alti riguardano la comunicazione dati (5), le transazioni online (5) e la facilità d’uso (5). Altri fattori, come prestazioni (3), configurabilità (1) e riutilizzabilità (3), completano il quadro, portando a un TDI di 49. Il VAF risultante è 1,14, e i Function Points aggiustati ammontano a 122 FP.
Questa fase affinata garantisce che la stima tenga conto delle specificità del progetto, rendendo più accurata la previsione dei costi.
Dal numero di Function Points al costo: il ruolo degli indicatori di produttività
Una volta ottenuti i Function Points aggiustati, è necessario tradurli in un costo economico. Il parametro chiave è l’indicatore di produttività, espresso in Function Points per persona‑mese (FP/PM). Questo valore indica quanti FP un programmatore esperto può realizzare in un mese di lavoro.
Assumendo una produttività di 10 FP/PM, i 122 FP richiedono 12,2 persona‑mesi. Con un costo medio mensile di 5.000 € per sviluppatore (comprensivo di stipendio, contributi e spese generali), il costo di sviluppo puro è di circa 61.000 €.
A questo importo si aggiungono le spese di project management (15‑20 % del costo di sviluppo), testing e controllo qualità (20‑25 %), documentazione (5‑10 %) e deployment/infrastruttura (circa 3 %). Sommando tutti gli elementi, il costo totale del progetto si avvicina a 92.000 €.
Questo esempio dimostra come i Function Points forniscano una base solida per la conversione da metriche tecniche a costi concreti.
Come varia la produttività
La produttività dipende da molteplici fattori. La tecnologia è determinante: linguaggi a basso livello come C o C++ consentono circa 5‑8 FP/PM, mentre linguaggi ad alto livello (Java, C#) raggiungono 10‑15 FP/PM; framework moderni (React, Vue) possono arrivare a 15‑20 FP/PM, e le piattaforme no‑code/low‑code superano i 25‑40 FP/PM.
L’esperienza del team influisce notevolmente: un team junior può vedere una riduzione della produttività del 30 %, mentre un team senior può superare i valori standard del 40 %. Il dominio applicativo è anch’esso un fattore: sistemi real‑time critici richiedono più testing e quindi riducono la produttività del 40 %, mentre applicazioni e‑commerce standard possono aumentarla del 20 % grazie alla disponibilità di componenti riutilizzabili.
Comprendere questi driver permette di adattare le stime in base al contesto reale del progetto, ottenendo previsioni più attendibili.
Caso studio comparativo
Consideriamo due progetti reali per evidenziare l’utilità dei Function Points nel confronto tra iniziative diverse.
Il primo è un sistema di gestione per biblioteche con 450 FP. Il team, esperto in Java, ha una produttività di 12 FP/PM, richiedendo 37,5 persona‑mesi e generando un costo di circa 187 500 €.
Il secondo è un’app mobile per il fitness tracking con 280 FP. Il team utilizza React Native e registra una produttività media di 15 FP/PM, quindi occorrono 18,7 persona‑mesi per un costo di 93 500 €.
Pur avendo un valore FP inferiore, l’app di fitness si realizza più rapidamente e con costi inferiori grazie a una tecnologia più produttiva e a un team più snello. Questo esempio dimostra come i Function Points forniscano una lente comune per confrontare progetti di diversa natura, evidenziando l’impatto di tecnologia e competenze sulla tempistica e sul budget.
Limiti e considerazioni finali
Il metodo dei Function Points presenta alcuni limiti da tenere presenti. La soggettività nella classificazione può generare differenze tra analisti; per mitigare il rischio è consigliabile utilizzare checklist standardizzate, effettuare revisioni incrociate e basarsi su dati storici di progetti analoghi.
Inoltre, i FP non catturano direttamente la complessità dell’interfaccia utente, l’esperienza d’uso, né le sfide legate all’integrazione con sistemi legacy particolarmente complessi. Requisiti non funzionali come sicurezza avanzata o conformità normativa possono introdurre costi aggiuntivi non riflessi nei FP.
Infine, il debito tecnico presente in sistemi già in produzione può ridurre la produttività reale, distorcendo le stime. Pertanto, l’applicazione efficace del metodo richiede esperienza, consapevolezza dei propri limiti e un approccio integrato con altre tecniche di stima.
Consigli pratici per iniziare
Se è la prima volta che utilizzi i Function Points, adotta un approccio conservativo: classifica tutte le componenti come “media” nella prima iterazione e affina le valutazioni nei cicli successivi, basandoti sui dati raccolti. Documenta ogni ipotesi e motivazione; questi appunti diventeranno una preziosa base di conoscenza per futuri progetti.
Inserisci un buffer di contingenza del 15‑20 % per tenere conto di incertezze iniziali. Dopo la conclusione del progetto, confronta la stima iniziale con i costi effettivi per calibrare il valore di produttività del tuo team (FP/PM).
Integra i Function Points con altre metodologie di stima, come il Metodo Delphi per raccogliere opinioni multiple, la pianificazione agile per gestire iterazioni frequenti e i risk registers per valutare i potenziali ostacoli. Un approccio ibrido massimizza l’affidabilità delle previsioni e migliora la governance del progetto.
Conclusione
I Function Points rappresentano un metodo solido, indipendente dalla tecnologia, per stimare il costo di sviluppo di un software. Quando applicati correttamente, insieme a una valutazione accurata della produttività del team e a un'analisi dettagliata dei fattori di aggiustamento, consentono di ottenere previsioni di budget e tempo più affidabili.
È importante ricordare che i Function Points offrono una stima, non una certezza assoluta: la precisione dipende dalla qualità dei requisiti, dall’esperienza del team e dall’integrazione con altre tecniche di valutazione. Un approccio continuo di monitoraggio, revisione e apprendimento garantisce che le stime rimangano allineate alla realtà del progetto, supportando decisioni informate e contribuendo al successo del prodotto finale.
