Una perizia di congruità di costo su un progetto software verifica se il prezzo richiesto o pagato è coerente con la complessità effettiva del lavoro e con i valori di mercato. Si basa su metodi accreditati — analisi dei Function Point, benchmark di settore, confronto con progetti analoghi — e produce un parere tecnico utilizzabile in contenziosi, gare d'appalto, operazioni di M&A e sinistri assicurativi.
Quando il costo del software diventa una questione legale
Il costo di sviluppo software entra nel ragionamento legale in situazioni molto diverse tra loro. Non si tratta solo di contenziosi: c'è un intero ecosistema di situazioni in cui qualcuno — un giudice, un commissario di gara, un consulente M&A, un liquidatore assicurativo — deve valutare se un importo relativo a un progetto software è corretto.
Il cliente ritiene di aver pagato troppo per un sistema che non vale quanto dichiarato, o la software house reclama il pagamento di lavori extra. La perizia stabilisce il valore tecnico effettivo del lavoro svolto.
In una gara pubblica per un sistema informatico, la stazione appaltante o il concorrente escluso vuole verificare se il prezzo dell'offerta aggiudicataria era anomalmente basso o ingiustificatamente alto rispetto al capitolato.
In un'acquisizione aziendale, il software proprietario ha un valore dichiarato nel bilancio. La perizia verifica se il costo di sviluppo storico giustifica quella valutazione o se l'asset è sovrastimato.
Un progetto software si interrompe per cause assicurate (incendio, dolo, insolvenza del fornitore). Il liquidatore deve stabilire il valore del lavoro già svolto e il costo per completare o ricostruire il sistema.
Il problema fondamentale: il software non ha un listino
Un'automobile ha un valore di mercato verificabile. Un immobile ha parametri catastali, valori OMI, prezzi comparabili per zona. Il software personalizzato non ha nulla di equivalente: ogni progetto è diverso dagli altri, i fattori che determinano il costo sono numerosi e interdipendenti, e la maggior parte delle informazioni rilevanti non è pubblica.
Questo crea uno spazio in cui prezzi molto diversi possono essere tutti "giusti" in senso assoluto, e altri possono essere gonfiati o sottostimati in modo non immediatamente rilevabile da chi non è del settore. La perizia di congruità serve a ridurre questa asimmetria informativa con un metodo rigoroso e documentabile.
«Il costo di un progetto software non è arbitrario — ma per capire perché un determinato prezzo è congruo o no, bisogna saper misurare la complessità funzionale prima ancora di guardare le ore lavorate.»
I metodi accreditati per la stima
La perizia di congruità non si basa su un'opinione soggettiva del perito. Usa metodi standardizzati e riconosciuti a livello internazionale, applicati con trasparenza e documentati nell'elaborato finale.
Il metodo più consolidato per misurare la dimensione funzionale di un sistema software, indipendentemente dalla tecnologia usata per costruirlo. I Function Point quantificano il software in termini di funzionalità offerte all'utente — input, output, query, file logici, interfacce esterne — assegnando a ciascuna un peso in base alla complessità.
Una volta misurata la dimensione in Function Point, si applica un fattore di produttività (ore per Function Point) derivato dai benchmark di settore (ISBSG, NESMA) per ricavare uno stimato di ore di lavoro. Moltiplicato per i costi di mercato per tipologia di risorsa, si ottiene il range di costo congruo.
Il vantaggio dell'FPA è che è misurabile dai requisiti — non richiede di aver visto il codice — e produce risultati comparabili tra organizzazioni diverse e tecnologie diverse.
Un'alternativa ai Function Point più adatta a sistemi descritti con Use Case — documenti che descrivono le interazioni tra utente e sistema per raggiungere un obiettivo. Ogni Use Case viene classificato per complessità (semplice, medio, complesso) e pesato in base agli attori che interagiscono con il sistema.
Il metodo UCP è meno universale dell'FPA ma produce stime più accurate per sistemi descritti con documentazione object-oriented o agile. In un contenzioso su un progetto agile con user story, può essere il metodo più appropriate.
I metodi parametrici producono una stima dal basso verso l'alto — dalla funzionalità al costo. Il confronto con benchmark di mercato produce una stima dall'alto verso il basso: quanto costano mediamente progetti con caratteristiche simili (settore, dimensione, tecnologia, complessità)?
I benchmark utilizzati in sede peritale provengono da fonti accreditate: ISBSG (International Software Benchmarking Standards Group), survey di settore pubblicate da Gartner e IDC, database di contratti pubblici aggiudicati. Il confronto con benchmark non è da solo sufficiente — le variabili contestuali sono troppe — ma rafforza o mette in discussione i risultati del metodo parametrico.
Le variabili che fanno muovere il costo
Prima di valutare la congruità di un prezzo, bisogna comprendere quali variabili lo determinano. Due progetti con lo stesso numero di schermate e funzionalità possono costare in modo molto diverso per ragioni perfettamente giustificabili.
Gli errori più comuni nelle perizie di congruità su software
Non tutte le perizie di congruità sono equivalenti. Alcune si basano su metodi corretti ma applicati male; altre usano metodi non appropriati al tipo di progetto. Gli errori più frequenti che un CTP di parte deve saper riconoscere e contestare:
- Usare le ore dichiarate dalla software house come base di calcolo. Le ore dichiarate non sono la realtà delle ore lavorate — sono una ricostruzione. La stima corretta parte dalla funzionalità e risale alle ore, non il contrario.
- Ignorare i requisiti non funzionali. Una perizia che stima la congruità contando solo le schermate e le funzionalità visibili sottostima sistematicamente i sistemi con requisiti elevati di sicurezza, scalabilità o integrazione.
- Usare benchmark generici senza aggiustamenti contestuali. I benchmark ISBSG si riferiscono a un universo molto ampio di progetti. Applicarli senza aggiustamenti per tecnologia, settore e complessità produce stime che possono essere fuorvianti in un senso o nell'altro.
- Non distinguere sviluppo e manutenzione. Molti contratti mischiano costo di sviluppo iniziale e costi continuativi di manutenzione e supporto. Una perizia che non separa questi componenti non può essere usata per valutare la congruità del solo sviluppo.
- Valutare il codice senza i requisiti. Il codice di per sé non dice quanto doveva costare — dice quanto è complesso ciò che è stato costruito. Per valutare la congruità, bisogna confrontare la complessità effettiva con quella attesa dai requisiti originali.
Come si legge una perizia di congruità
Una perizia di congruità ben strutturata risponde a tre domande in sequenza. Chi la legge — avvocato, giudice, commissario di gara — dovrebbe poter seguire il ragionamento anche senza competenze tecniche.
Prima domanda: qual è la dimensione funzionale del sistema? Quante funzionalità, di quale complessità, misurate con quale metodo. Questo è il punto di partenza oggettivo, indipendente dal costo dichiarato.
Seconda domanda: qual è il costo atteso per un sistema con quella dimensione funzionale? Applicando i fattori di produttività da benchmark di settore, e moltiplicando per le tariffe di mercato per il profilo di risorse appropriato, si ottiene un range di costo congruo. Non un numero puntuale — un range, perché le variabili contestuali producono varianza legittima.
Terza domanda: il costo oggetto di perizia è dentro, sopra o sotto quel range? La risposta a questa domanda è il cuore della perizia. Se il costo è dentro il range, è congruo. Se è significativamente sopra o sotto, la perizia deve spiegare quali fattori giustificano lo scostamento — o concludere che lo scostamento non è giustificabile.
La perizia non si sostituisce alla valutazione giuridica: non dice chi ha ragione. Dice se il costo è tecnicamente giustificato. Il resto spetta al giudice, all'arbitro o alla stazione appaltante.
Se hai bisogno di una perizia di congruità di costo su un progetto software — per un contenzioso, una gara d'appalto o una due diligence — contattaci. Redigiamo perizie asseverate e giurate, basate sui metodi accreditati, con esperienza diretta di sviluppo su cui fondare il ragionamento tecnico.