Preventivo sviluppo software: esempio e checklist

Preventivo, stima e contratto non sono la stessa cosa

Una stima iniziale serve a capire l’ordine di grandezza e la fattibilità quando alcune decisioni sono ancora aperte. Il preventivo lega invece un prezzo a un perimetro, a ipotesi e a una modalità di lavoro. Il contratto disciplina il rapporto, le responsabilità, i diritti, i pagamenti e la gestione delle variazioni. Usare un solo documento per tre funzioni può lasciare zone ambigue.

Se il progetto è ancora vago, la prima attività acquistabile può essere l’analisi: interviste, mappa del processo, prototipo, modello dei dati e backlog prioritizzato. Il suo output deve essere riutilizzabile anche per confrontare fornitori diversi. Una cifra chiusa prima di chiarire flussi critici non elimina l’incertezza: spesso la sposta nelle esclusioni o nelle richieste successive.

La guida su quanto costa un software gestionale su misura approfondisce componenti e costo totale. Qui il punto è diverso: costruire un documento che permetta di capire cosa si sta comprando.

Esempio di richiesta: dal desiderio al caso verificabile

«Vorrei un portale clienti» descrive una soluzione, non il problema. Un brief migliore parte da un episodio reale: oggi la richiesta arriva via email, un operatore ricopia i dati, il responsabile approva, il cliente non vede lo stato e telefona. La prima release deve raccogliere dati obbligatori, assegnare la pratica, registrare decisioni e mostrare aggiornamenti autorizzati.

Per ogni flusso scrivi:

1. evento iniziale: cosa avvia il processo e da quale canale;
2. attori: chi inserisce, controlla, approva e consulta;
3. dati: quali sono obbligatori, sensibili o provenienti da altri sistemi;
4. regole: stati, controlli, calcoli, scadenze ed eccezioni;
5. output: notifica, documento, pagamento, aggiornamento o esportazione;
6. successo: prova osservabile che dimostra il completamento.

Allega esempi anonimizzati di moduli, file ed email. Evita dati personali reali nella fase commerciale. Uno screenshot aiuta a capire l’attuale interfaccia, ma non sostituisce regole e responsabilità.

Requisiti funzionali e non funzionali

I requisiti funzionali descrivono azioni: creare una pratica, assegnarla, calcolare un importo, inviare un avviso, esportare un report. Devono includere comportamento normale ed errori. «L’utente carica un file» resta incompleto senza formati, dimensione, controlli, permessi e risposta in caso di errore.

I requisiti non funzionali descrivono qualità e vincoli: accessibilità, prestazioni, disponibilità, tracciabilità, compatibilità, conservazione, sicurezza e capacità di crescita. «Veloce» non è misurabile. Meglio indicare pagine prioritarie, quantità attese, dispositivi, condizioni di rete e soglie concordate.

Attribuisci una priorità reale. Uso una distinzione semplice: indispensabile per il flusso principale, importante ma rinviabile, ipotesi da validare. Se tutto è prioritario, il preventivo include rischio e ampiezza che una prima release dovrebbe evitare.

Deliverable: cosa viene consegnato

La parola «software» può nascondere output molto diversi. Elenca applicazione, codice sorgente, configurazione infrastrutturale, schema dati, documentazione tecnica, guida operativa, credenziali e materiali di design previsti. Specifica formati e luogo di consegna.

Per un progetto distribuito sugli store, chiarisci chi crea e possiede gli account, chi prepara schede, screenshot, privacy information e risponde alle revisioni. Per una web app, definisci dominio, hosting, certificati, email transazionali, monitoraggio e ambienti. I costi di terze parti devono essere separati dal lavoro di sviluppo e associati a un intestatario dell’account, a un responsabile del rinnovo e a un metodo di pagamento.

Un repository e l’automazione del deploy non garantiscono da soli la continuità, ma riducono la dipendenza. Chiedi almeno istruzioni per installare, configurare, distribuire e ripristinare il sistema. Se alcune componenti restano proprietarie del fornitore, devono essere identificate insieme a licenza e condizioni di uscita.

Dati, integrazioni e dipendenze esterne

Ogni API comporta autenticazione, limiti, versioni e possibili indisponibilità. Nel preventivo indica sistema, operazioni richieste, disponibilità di documentazione e ambiente di prova, responsabilità sulle credenziali e comportamento quando il servizio non risponde. «Integrazione con il gestionale» non basta se non è chiaro quale prodotto, piano e interfaccia siano disponibili.

La migrazione richiede inventario, mapping, pulizia, prova e riconciliazione. Definisci quali archivi entrano, fino a quale data, chi corregge record incoerenti e come si verifica il risultato. Conservare il vecchio sistema in sola lettura può essere più sicuro che importare anni di dati inutilizzati.

Prevedi anche esportazione e uscita. Quali dati si possono scaricare, in quale formato, con quali allegati e in quanto tempo? Questa domanda protegge il processo aziendale e rende più chiaro il valore della proprietà dei dati.

Criteri di accettazione e test

Un criterio di accettazione trasforma una promessa in una verifica. Esempio: «dato un cliente autorizzato e una pratica completa, quando invia la richiesta, il sistema assegna un identificativo, registra data e autore, mostra conferma e rende la pratica visibile al ruolo responsabile». Il test può essere ripetuto da entrambe le parti.

Definisci chi prepara casi e dati di prova, chi esegue l’accettazione, entro quale finestra e come vengono classificati i problemi. Un difetto rispetto a un requisito approvato è diverso da una nuova preferenza. Stabilire questa differenza prima del collaudo riduce i conflitti.

Test automatici, test manuali, controllo accessibilità, verifica permessi e prova di ripristino coprono rischi differenti. Non serve promettere «zero bug»: serve concordare livelli di gravità, condizioni che bloccano il rilascio e procedura di correzione.

Fasi, milestone e richieste di modifica

Una roadmap affidabile collega pagamenti e decisioni a deliverable: analisi approvata, prototipo validato, flusso principale su ambiente di test, migrazione pilota, accettazione e avvio. Le date dipendono anche dal cliente: accessi, feedback, contenuti e decisioni tardive spostano il percorso.

Inserisci un processo per le modifiche. Ogni richiesta dovrebbe descrivere motivo, impatto su scope, tempi, prezzo e priorità. Può sostituire una funzione prevista, entrare in una fase successiva o generare una variazione. Questa disciplina permette di adattare il prodotto senza fingere che il perimetro iniziale sia immutabile.

Per progetti ancora incerti, un prezzo per fase con uscita possibile dopo ogni milestone può essere più trasparente di un unico pacchetto. La scelta contrattuale va valutata con professionisti competenti; il preventivo tecnico non sostituisce consulenza legale o fiscale.

Privacy e sicurezza devono avere attività verificabili

«Conforme al GDPR» non è una specifica tecnica. Il Regolamento (UE) 2016/679 richiede protezione dei dati fin dalla progettazione e misure adeguate al rischio. Il titolare resta responsabile delle finalità e delle basi giuridiche; il progetto e i fornitori devono tradurle in minimizzazione, accessi, conservazione, cancellazione, log, backup e gestione degli incidenti.

Il preventivo dovrebbe indicare ambienti separati, gestione dei segreti, autenticazione, autorizzazioni, aggiornamenti, dipendenze, backup e prova di ripristino. Se esiste un trattamento per conto del cliente, ruoli e istruzioni vanno formalizzati. Una valutazione d’impatto, quando necessaria, richiede informazioni che il team tecnico deve saper fornire.

Le Linee guida AgID per la sicurezza nello sviluppo delle applicazioni organizzano il lavoro tra ciclo di sviluppo sicuro, sviluppo del codice, hardening e modellazione delle minacce. Per rendere i controlli verificabili nel preventivo, OWASP ASVS 5.0.0 offre requisiti tecnici utilizzabili anche durante il procurement e nei contratti. Va scelto il livello adatto al rischio e vanno indicate versione, verifiche ed evidenze richieste: non basta una dichiarazione generica di conformità.

Proprietà, licenze e account

Codice, dati, design, documentazione e marchi sono beni distinti. Il contratto deve dire cosa viene ceduto, cosa viene concesso in licenza e cosa appartiene a terzi. Librerie open source conservano le proprie licenze; servizi cloud e SDK seguono condizioni autonome.

Account strategici — dominio, cloud, store, repository, analytics, email — dovrebbero avere intestazione e accessi coerenti con il piano di continuità. Il fornitore può operare con permessi delegati. Usa credenziali individuali e una procedura di revoca, non password condivise in chat.

Chiarisci il riuso di componenti generici e la riservatezza del materiale specifico. Se vuoi poter cambiare manutentore, richiedi accesso al codice, storico, configurazione, dipendenze, dati ed istruzioni sufficienti per un passaggio tecnico ragionevole.

Manutenzione, assistenza ed esclusioni

Il rilascio apre una fase operativa. Distingui manutenzione correttiva, adeguativa ed evolutiva: risolvere un difetto, adattare una dipendenza cambiata e aggiungere una funzione non sono lo stesso lavoro. Specifica durata della garanzia, canale di segnalazione, livelli di gravità e orari coperti.

Elenca costi ricorrenti: hosting, database, storage, invio email o SMS, mappe, pagamenti, domini, certificati, monitoraggio e account store. Indica chi rinnova e chi riceve gli avvisi. Un servizio dimenticato può interrompere un’applicazione tecnicamente funzionante.

Le esclusioni rendono il documento più onesto: contenuti, traduzioni, data entry, hardware, consulenza legale, campagne marketing, licenze o supporto utenti possono non essere inclusi. Devono essere visibili prima della firma, non scoperti durante il progetto.

Checklist per confrontare offerte

1. porta ogni offerta allo stesso elenco di flussi e deliverable;
2. separa analisi, sviluppo, costi esterni e manutenzione;
3. evidenzia ipotesi, punti aperti ed esclusioni;
4. verifica dati, migrazione, export e piano di uscita;
5. confronta test e criteri di accettazione, non solo tecnologie;
6. controlla proprietà di codice, account e documentazione;
7. valuta sicurezza, backup, incidenti e aggiornamenti;
8. leggi come cambiano prezzo e tempi quando cambia lo scope.

Chiedi chiarimenti per iscritto e aggiorna il documento condiviso. Il preventivo migliore non è necessariamente quello più lungo o più economico: è quello che rende visibili decisioni, rischi e responsabilità nella misura adatta al progetto.

Cosa inviare per una prima valutazione

Prepara una pagina con problema, utenti, flusso principale, tre eccezioni frequenti, sistemi da collegare, dati da importare e risultato atteso. Aggiungi vincoli reali: scadenza motivata, dispositivi, lingue, requisiti di accessibilità o sicurezza. Indica chi può decidere sul processo.

Se stai valutando un prodotto mobile, consulta anche la guida su quanto costa sviluppare un’app: store, dispositivi, servizi e manutenzione introducono voci specifiche. Per un sistema aziendale, parto dal processo e restituisco domande, rischi e perimetro della prima release prima di quantificare il lavoro.

Domande frequenti