Determinare il costo di sviluppo di un software è un'operazione complessa, che va ben oltre la semplice somma delle ore di lavoro dei programmatori. Infatti, influiscono numerosi fattori, dalla complessità del progetto alla tecnologia utilizzata, passando per l'esperienza del team e le eventuali necessità di infrastrutture. Uno dei metodi più consolidati per stimare il costo, prima ancora di iniziare la programmazione vera e propria, si basa sui Function Points (FP). Ma cosa sono esattamente e come si calcolano?
A differenza di metodi che si concentrano sul codice (linee di codice, ad esempio), i Function Points si focalizzano sulla funzionalità offerta dal software al cliente. Si tratta di un'unità di misura astratta, che rappresenta la quantità di lavoro necessaria per sviluppare una specifica funzionalità, indipendentemente dalla tecnologia utilizzata.
Immaginiamo di dover sviluppare un'applicazione per una pizzeria che permetta ai clienti di ordinare online. Invece di chiederci "quante righe di codice serviranno?", con i Function Points ci chiediamo "quali funzionalità deve offrire l'app al cliente?". Il cliente deve poter visualizzare il menu con i prezzi, aggiungere pizze al carrello, personalizzare gli ingredienti, effettuare il pagamento e tracciare lo stato dell'ordine. Ognuna di queste funzionalità rappresenta un valore per l'utente finale, indipendentemente dal linguaggio di programmazione scelto.
Questo approccio presenta diversi vantaggi. L'indipendenza dalla tecnologia permette di confrontare progetti sviluppati con linguaggi diversi: che si tratti di Java, Python o C++, il calcolo dei Function Points rimane sostanzialmente lo stesso. La nostra app della pizzeria avrà lo stesso valore funzionale sia se la sviluppiamo con React Native che con Flutter. Il focus sulla funzionalità sposta l'attenzione dalla complessità tecnica alla reale utilità del software per l'utente, aiutando a mantenere l'attenzione sulle esigenze del cliente. Il pizzaiolo non si preoccupa se usiamo MongoDB o PostgreSQL, ma vuole essere sicuro che gli ordini arrivino correttamente. Infine, la possibilità di effettuare una stima precoce, quando la specifica è ancora in fase di definizione, facilita enormemente la pianificazione e la gestione del progetto.
Come si calcolano i Function Points: Un'analisi dettagliata
Il calcolo dei Function Points è un processo iterativo che richiede una comprensione approfondita dei requisiti del software. Si basa sull'identificazione e sulla quantificazione di cinque elementi principali, ciascuno con caratteristiche e livelli di complessità specifici.
Immagina di dover analizzare un progetto come un archeologo che studia le diverse stratificazioni di un sito: ogni elemento va esaminato con attenzione, contestualizzato e valutato in relazione agli altri. Non si tratta di un'operazione meccanica che si può completare in un'ora davanti a un documento di specifiche. Al contrario, richiede diverse sessioni di analisi, discussioni con il team di sviluppo e, soprattutto, confronti con gli stakeholder per assicurarsi di aver compreso davvero cosa il sistema deve fare.
La natura iterativa del processo è fondamentale: nella prima passata potresti identificare le funzionalità macro, nella seconda entrare nel dettaglio di ciascuna transazione, nella terza rivalutare alcune classificazioni alla luce di quanto scoperto. È normale tornare indietro e rivedere valutazioni precedenti quando emergono nuove informazioni. Un analista esperto sa che la prima stima è raramente quella definitiva, e che l'accuratezza cresce attraverso raffinamenti successivi. Questo approccio graduale non è un difetto del metodo, ma la sua forza: permette di costruire una comprensione sempre più precisa del progetto man mano che i requisiti si chiarificano.
File di dati esterni (External Interface Files - EIF)
Questi sono i dati in ingresso al sistema provenienti da fonti esterne, come file, database o dispositivi. Per ogni file, si valuta la complessità considerando il numero di dati in ingresso e la loro struttura. Torniamo alla nostra app della pizzeria per rendere il concetto più concreto. Un EIF semplice, a cui assegneremmo circa 3-5 Function Points, potrebbe essere l'importazione della lista ingredienti disponibili da un file CSV del fornitore che contiene solo nome e disponibilità. Un EIF di media complessità, valutabile in 5-7 FP, potrebbe essere l'importazione dei dati dei corrieri esterni con nome, zona di competenza, orari di disponibilità e tariffe. Un EIF complesso, che può arrivare a 7-10 FP, sarebbe invece la sincronizzazione con un sistema di pagamento esterno come Stripe o PayPal, che include token, dettagli delle transazioni, storico, gestione rimborsi e verifiche di sicurezza.
File di dati interni (Internal Logical Files - ILF)
Questi sono i dati memorizzati all'interno del sistema. La complessità viene valutata in base alla struttura e al numero di dati. Nella nostra pizzeria digitale, un ILF semplice da 7-10 Function Points potrebbe essere la tabella "Clienti" con campi base come nome, email, telefono e indirizzo. Un ILF medio, valutabile tra 10 e 15 FP, sarebbe la tabella "Menu" che gestisce pizze, ingredienti, allergeni, prezzi diversificati per dimensione e promozioni applicabili. Un ILF complesso, che supera i 15 FP, è rappresentato dal database "Ordini" che gestisce le complesse relazioni tra clienti, pizze, personalizzazioni, pagamenti, stato di consegna, storico delle modifiche, feedback dei clienti e programma fedeltà.
Output esterni (External Outputs - EO)
Questi sono i dati in uscita dal sistema che producono report o informazioni elaborate destinate all'utente o ad altri sistemi. Un EO semplice da 4-5 Function Points potrebbe essere la stampa della ricevuta dell'ordine con l'elenco delle pizze e il totale. Un EO medio, valutabile tra 5 e 7 FP, sarebbe un report settimanale delle vendite con grafici per tipo di pizza, fasce orarie e metodo di pagamento. Un EO complesso da 7-10 FP rappresenta invece una dashboard analitica per il gestore con previsioni di vendita basate su dati storici, stagionalità, eventi locali e meteo, con suggerimenti automatici per ottimizzare le scorte degli ingredienti.
Interrogazioni esterne (External Inquiries - EQ)
Queste sono le richieste di informazioni al sistema che restituiscono dati all'utente senza elaborazioni complesse. A differenza degli EO, le EQ non trasformano significativamente i dati. Nella nostra app, un EQ semplice da 3-4 Function Points è la ricerca di una pizza per nome nel menu. Un EQ medio da 4-6 FP potrebbe essere un filtro avanzato che permette di cercare pizze per ingredienti, prezzo e allergeni con risultati ordinabili. Un EQ complesso da 6-8 FP è rappresentato dal tracker dell'ordine in tempo reale che interroga la posizione del corriere, lo stato di preparazione in cucina e il tempo stimato di arrivo, combinando dati interni ed esterni.
Transazioni esterne (External Inputs - EI)
Questi rappresentano i processi che ricevono dati dall'esterno e li elaborano per aggiornare il sistema, applicando logiche di business. Un EI semplice da 3-4 Function Points potrebbe essere l'aggiunta di una pizza al carrello con validazione base della disponibilità. Un EI medio da 4-6 FP è la registrazione di un nuovo cliente con validazione dell'email, controllo della password sicura e verifica dell'indirizzo di consegna tramite API di Google Maps. Un EI complesso da 6-10 FP è rappresentato dal processo di checkout completo che valida il carrello, applica sconti e promozioni cumulative, verifica la disponibilità degli ingredienti in tempo reale, elabora il pagamento con gestione degli errori, genera l'ordine, notifica la cucina e il cliente e aggiorna i punti fedeltà.
Esempio di calcolo completo: L'app della pizzeria
Mettiamo insieme tutti i pezzi per calcolare i Function Points della nostra app. Il database clienti, essendo un ILF semplice, vale 7 FP. Il database del menu, di media complessità, vale 12 FP, mentre il complesso database degli ordini arriva a 18 FP. L'import dei dati dei corrieri, un EIF medio, contribuisce con 6 FP, mentre l'integrazione con i sistemi di pagamento, decisamente complessa, aggiunge 9 FP.
Sul fronte delle transazioni, la registrazione del cliente (EI medio) vale 5 FP, l'aggiunta al carrello (EI semplice) 3 FP, il processo di checkout complesso 8 FP e la modifica degli ingredienti della pizza (EI medio) altri 5 FP. Le interrogazioni includono la ricerca nel menu (EQ semplice) per 3 FP, il filtro avanzato (EQ medio) per 5 FP e il tracker dell'ordine (EQ complesso) per 7 FP. Infine, gli output comprendono la ricevuta dell'ordine (EO semplice) da 4 FP, il report delle vendite (EO medio) da 6 FP e la dashboard analytics (EO complesso) da 9 FP.
Sommando tutti questi elementi, otteniamo un totale di 107 Function Points non aggiustati. Ma il calcolo non è ancora completo.
I fattori di aggiustamento
Prima di arrivare al calcolo finale, si applicano 14 fattori di aggiustamento che considerano caratteristiche generali del sistema come le prestazioni richieste, la configurabilità, la facilità di installazione e la riutilizzabilità. Ogni fattore ha un punteggio da 0 a 5 che viene poi utilizzato per calcolare il Value Adjustment Factor (VAF).
Per la nostra app della pizzeria, valutiamo alcuni fattori chiave. La comunicazione dati è alta, visto che l'app deve comunicare costantemente con server, sistemi di pagamento e corrieri, quindi assegniamo 5 punti. Le prestazioni sono medie, con un punteggio di 3, mentre la configurabilità è bassa (1 punto) perché l'app è pensata specificamente per il business della pizzeria. Le transazioni online sono ovviamente alte (5 punti), la riutilizzabilità è media (3 punti) dato che alcuni componenti potrebbero essere riutilizzati per altri ristoranti. L'installazione deve essere facilitata per gli utenti finali (4 punti), la facilità d'uso è fondamentale (5 punti) e la capacità di aggiornamenti online è essenziale (5 punti). Gli altri fattori sommati contribuiscono con 18 punti.
La somma totale di questi fattori (TDI) è 49. Il VAF si calcola con la formula 0.65 + (0.01 × TDI), che nel nostro caso dà 1.14. I Function Points aggiustati sono quindi 107 × 1.14, ovvero 122 FP.
Dal numero di Function Points al costo: Il ruolo degli indicatori di produttività
Ottenuto il numero di Function Points, non abbiamo ancora il costo del progetto. A questo punto, entra in gioco un parametro cruciale: l'indicatore di produttività, espresso solitamente in Function Points per persona-mese (FP/PM). Questo indicatore rappresenta la quantità di Function Points che un programmatore esperto riesce a sviluppare in un mese di lavoro.
Supponiamo che il nostro team abbia un indicatore di produttività di 10 FP/PM, un valore tipico per applicazioni web sviluppate da un team di media esperienza. Dividendo i 122 FP per 10 FP/PM, otteniamo 12.2 persona-mesi necessari per completare il progetto. Se il costo medio di uno sviluppatore è 5.000€ al mese (comprensivo di stipendio, contributi e spese generali), il costo totale per lo sviluppo puro è di circa 61.000€.
Questo costo, tuttavia, copre solo l'attività di sviluppo. Dobbiamo aggiungere il project management, che tipicamente rappresenta il 15-20% del costo di sviluppo, circa 10.000€ nel nostro caso. Il testing e il controllo qualità richiedono un ulteriore 20-25%, ovvero circa 13.000€. La documentazione tecnica e utente assorbe un altro 5-10%, circa 5.000€, mentre il deployment e l'infrastruttura iniziale richiedono circa 3.000€. Il costo totale del progetto si aggira quindi intorno ai 92.000€.
Come varia la produttività
L'indicatore di produttività varia significativamente in base a diversi fattori. La tecnologia utilizzata ha un impatto enorme: linguaggi di basso livello come C o C++ permettono di sviluppare solo 5-8 FP al mese per programmatore, mentre linguaggi ad alto livello come Java o C# arrivano a 10-15 FP/PM. I framework moderni come React o Vue possono spingere la produttività fino a 15-20 FP/PM, mentre le piattaforme no-code o low-code possono addirittura raggiungere i 25-40 FP/PM.
L'esperienza del team è altrettanto determinante. Un team composto principalmente da sviluppatori junior può avere una produttività inferiore del 30% rispetto alla media, mentre un team senior può superare i valori standard del 40%. Un team misto si posiziona su valori intermedi. Anche il dominio applicativo influisce: un'app gestionale standard si mantiene sui valori base di produttività, un sistema real-time critico può ridurre la produttività del 40% a causa del testing più rigoroso necessario, mentre un e-commerce semplice può aumentarla del 20% grazie all'abbondanza di componenti riutilizzabili disponibili.
Caso studio comparativo
Consideriamo due progetti reali per capire meglio come i Function Points permettano confronti significativi. Il primo progetto riguarda un sistema di gestione per biblioteche, con 450 FP totali. Il team, esperto in Java, ha una produttività di 12 FP/PM, quindi il progetto richiede 37.5 mesi-persona per un costo di 187.500€. Il secondo progetto è un'app mobile per il fitness tracking, con 280 FP totali. Il team usa React Native e ha una produttività media di 15 FP/PM, quindi servono 18.7 mesi-persona per un costo di 93.500€.
Anche se il progetto della biblioteca è più grande in termini di funzionalità assolute, grazie a una tecnologia più produttiva e un team più snello, l'app di fitness risulta più veloce da completare in termini relativi. Questo dimostra come i Function Points permettano di confrontare progetti completamente diversi su una base comune.
Limiti e considerazioni finali
Nonostante la sua utilità, il metodo dei Function Points presenta alcuni limiti che è importante conoscere. La soggettività nella classificazione è uno dei problemi principali: due analisti potrebbero valutare diversamente la complessità dello stesso elemento. Per mitigare questo rischio, è fondamentale usare checklist standardizzate, far validare le stime da più persone e basarsi su progetti simili già completati dall'organizzazione.
Il metodo non copre esplicitamente tutti gli aspetti dello sviluppo. La complessità dell'interfaccia utente e dell'esperienza d'uso, per esempio, non è direttamente catturata dai FP. L'integrazione con sistemi legacy particolarmente problematici può richiedere sforzi aggiuntivi non previsti. I requisiti non funzionali complessi, come la sicurezza avanzata o la compliance con regolamenti specifici, possono aumentare significativamente i costi. Anche il debito tecnico esistente, se si lavora su sistemi già in produzione, può influenzare negativamente la produttività.
L'applicazione corretta del metodo richiede esperienza. Un analista inesperto potrebbe, per esempio, contare "modifica ingredienti" e "personalizza pizza" come due EI separati nella nostra app della pizzeria, quando in realtà sono la stessa funzionalità vista da due prospettive. Questo gonfia artificialmente i FP e distorce la stima, portando a budget sovrastimati e perdita di competitività.
Consigli pratici per iniziare
Se stai applicando il metodo per la prima volta, inizia con un approccio conservativo. Per il primo progetto, classifica tutto come "medio" e raffina la tecnica nelle iterazioni successive, basandoti sui dati reali che raccoglierai. Documenta sempre le assunzioni e le motivazioni dietro ogni classificazione: questi appunti saranno preziosi per calibrare le stime future e costruire una base di conoscenza organizzativa.
Usa sempre un buffer di contingenza, specialmente se il team è nuovo al metodo. Un margine del 15-20% è ragionevole per i primi progetti. Dopo ogni progetto completato, confronta la stima iniziale con il consuntivo effettivo: questa analisi retrospettiva è fondamentale per migliorare l'accuratezza delle stime successive e calcolare l'indicatore di produttività reale del tuo team.
Integra i Function Points con altre tecniche di stima. Usa il metodo Delphi per coinvolgere più esperti nella valutazione, applica la pianificazione agile per progetti iterativi e considera sempre buffer per i rischi identificati durante l'analisi. I Function Points sono uno strumento potente, ma danno il meglio quando inseriti in un processo di stima più ampio e strutturato.
In conclusione, i Function Points offrono un metodo robusto e relativamente indipendente dalla tecnologia per stimare il costo di sviluppo del software. Se applicato correttamente, con una buona comprensione dei requisiti e un'adeguata calibrazione dell'indicatore di produttività basata su dati storici reali, può rappresentare uno strumento prezioso per la pianificazione e la gestione dei progetti software. Tuttavia, è importante ricordare che si tratta solo di una stima, per quanto accurata, e che altri fattori organizzativi, tecnologici e umani possono influenzare il costo finale. L'utilizzo dei Function Points dovrebbe quindi essere integrato con altre tecniche di stima del costo e con un processo di monitoraggio continuo durante l'esecuzione del progetto, per ottenere una valutazione più completa, accurata e soprattutto utile per prendere decisioni informate.
