Contratto di sviluppo software custom: guida per chi commissiona e chi sviluppa
Commissionare o sviluppare un software custom è un'operazione complessa che, senza un contratto ben strutturato, finisce spesso in conflitto. I problemi più comuni sono la proprietà del codice, le specifiche cambiate in corso d'opera, i test e l'accettazione del lavoro, e la manutenzione post-delivery. Ecco cosa deve contenere un contratto di sviluppo software per tutelarsi da entrambi i lati.
Specifiche tecniche e capitolato: la radice dei conflitti
La maggior parte delle controversie nello sviluppo software nasce da specifiche vaghe o modificate. Il contratto dovrebbe allegare un documento di specifica tecnica (o capitolato) che descriva in modo preciso le funzionalità richieste, i requisiti non funzionali (performance, sicurezza, scalabilità), le integrazioni con altri sistemi, e i criteri di accettazione per ogni deliverable. Senza questi elementi, "il software non funziona come volevo" diventa impossibile da valutare oggettivamente.
Proprietà del codice e licenze
Chi possiede il codice sorgente al termine del progetto? La risposta standard è il committente — ma non è sempre così. Alcune parti del codice potrebbero usare librerie open source con licenze restrittive (es. GPL che richiede che il codice derivato sia open source), framework di proprietà dello sviluppatore, o componenti riusati da altri progetti. Il contratto deve specificare: il committente riceve il codice sorgente completo, quali librerie di terze parti sono usate e con quali licenze, se lo sviluppatore mantiene diritti su componenti preesistenti, e se il committente può far sviluppare ulteriormente il software da terzi.
Gestione delle varianti e change request
Le specifiche cambiano. Un buon contratto prevede una procedura formale per le change request: la proposta di modifica deve essere documentata per iscritto, lo sviluppatore fornisce una stima di impatto su tempi e costi, il committente approva prima dell'implementazione. Senza questa procedura, lo scope creep (l'espansione progressiva delle funzionalità richieste senza adeguamento del compenso) è quasi inevitabile e porta allo stallo del progetto.
Testing, accettazione e collaudo
Come si stabilisce che il software è "finito"? Il contratto deve definire: la procedura di collaudo (chi testa, con quali casi d'uso), il periodo di accettazione (solitamente 15-30 giorni dopo la consegna), come vengono classificati e gestiti i bug trovati (bloccanti, importanti, minori), e il criterio di accettazione formale (es. nessun bug bloccante aperto). Senza un processo di accettazione definito, il committente può tenere aperto il collaudo indefinitamente — o lo sviluppatore può pretendere il pagamento finale su un software non funzionante.
Manutenzione e supporto post-delivery
La manutenzione è spesso trascurata nel contratto iniziale — e diventa una fonte di conflitti. Distingui tra manutenzione correttiva (bug fixing post-collaudo, di solito gratuita per un periodo definito), manutenzione adattativa (aggiornamenti per compatibilità con nuove versioni di OS, browser, API esterne), e manutenzione evolutiva (nuove funzionalità). Le ultime due dovrebbero essere oggetto di un contratto separato o di un'opzione di rinnovo. Definisci anche cosa succede se lo sviluppatore non è più disponibile: hai accesso al codice? Puoi affidarlo a terzi?
← Freelance e consulenza con FirmaTranquilla
Leggi anche: Contratto di licenza software: i click-wrap che nessuno legge | Contratto di manutenzione: SLA e penali