Un'esperienza di utilizzo delle metriche dei Function Point nelle Applicazioni Web

Il mercato dell’Information & Comunication Technology sta evolvendo rapidamente e le nuove forme di rapporto tra Cliente, sia esso soggetto pubblico o privato, e Fornitore necessitano di flessibilità ed articolazione adeguate nei relativi contratti di fornitura. Si avverte in particolar modo l’esigenza, per quanto riguarda la componente software, di prevedere forme di determinazione dei corrispettivi che consentano una maggiore equità e adattabilità ai diversi tipi di rapporto e ai diversi oggetti di fornitura.
Una transazione commerciale tra fornitore e cliente è basata sulla fornitura di prodotti/servizi a fronte della corresponsione di un prezzo. La transazione ha luogo quando è ritenuta equa da entrambi i contraenti, quindi non necessariamente quando è oggettivamente equa, questo sta a significare che lo scambio può avvenire anche quando una delle due o addirittura entrambe le parti non siano perfettamente consapevoli di tutte le reali implicazioni della transazione.
Il fenomeno appena descritto non si verifica in caso di transazioni che avvengono ripetutamente tra le stesse due parti, infatti nel caso di una transazione iniqua a favore del fornitore, il cliente non sarà soddisfatto quando scoprirà “la trappola” e potrà risultare insolvente o abbandonare il fornitore screditandolo sul mercato, nel caso di una transazione iniqua a favore del cliente, invece il fornitore subirà una perdita economica che potrà portare a difficoltà finanziarie e ritardi nelle consegne, aumento del rischio di fornitura e scarsa disponibilità verso la realizzazione della qualità attesa e del supporto nel tempo. Tali fenomeni contribuiscono a rimettere le transazioni future sui binari di equità oppure portando al degrado del rapporto commerciale e, potenzialmente, del sistema nel suo complesso.
La percezione di equità alla base delle transazioni può essere raggiunta più rapidamente e con maggiore realismo se sono disponibili misure oggettive per le variabili coinvolte dalle forniture e dati di riferimento di mercato che raccontano i trend di prezzo e la storia delle occasioni di incontro della domanda con l’offerta per beni analoghi.
Inoltre le prassi correnti di utilizzo delle misure funzionali nei contratti, da parte dei soggetti di mercato, sono spesso inadeguate a coprire i bisogni di flessibilità e articolazione presenti.
Alcune conseguenze di questa inadeguatezza sono che:
- i contratti per il software "custom", apparentemente facili da valorizzare in base a modelli che considerano la sola variabile "Function Point", si rivelano difficili da gestire e generano molti contenziosi, spesso risolti con negoziazioni extra-contrattuali;
- si acquistano prodotti molto diversi usando lo stesso, unico parametro di prezzo per Function Point;
- i cambiamenti di requisiti in corso d’opera sono fonte di conflittualità permanente nell’esecuzione contrattuale perché non valorizzati quantitativamente o non adeguatamente coperti da remunerazione aggiuntiva;
- si usano unità di misura funzionali per misurare entità diverse dal prodotto software (es. infrastrutture hardware, servizi);
- si confondono spesso variabili di input con variabili di output del processo produttivo (es. si misura il prodotto software usando le unità tempo-persona);
- si esprimono i budget aziendali usando i Function Point ("quest’anno non possiamo spendere più di 30000 FP!"), confondendo la quantità di software con l’impiego economico per realizzarlo.

L’analisi dei function point (FPA – Function Point Analysis) è un metodo standardizzato per misurare lo sviluppo del software dal punto di vista dell’utente. Essa quantifica le funzionalità che il software fornisce all’utente, basandosi principalmente sul disegno logico. Utenti e sviluppatori possono utilizzare la FPA per misurare le unità di prodotto software, oggetto di sviluppo o di manutenzione, a sostegno dell’analisi della qualità e della produttività.
Alla data, esistono quattro metodi standard per la misurazione funzionale del software: IFPUG, COSMIC, MkII e NESMA. Il metodo IFPUG è attualmente il più diffuso per utilizzo e per origine, oltre che attuale riferimento indicato dalle direttive CNIPA per la valutazione dei progetti software per la Pubblica Amministrazione centrale.