La fase di analisi di un progetto software dura in genere da due a tre settimane per un applicativo verticale con pochi utenti coinvolti, e sale a sei-otto settimane quando il progetto interessa più reparti e richiede integrazioni con sistemi esistenti come ERP o gestionali. Su progetti enterprise, in ambito Pubblica Amministrazione o in relazione a componenti IoT e intelligenza artificiale su scala articolata, i tempi possono superare le otto-dodici settimane. La durata esatta dipende dall'ampiezza del perimetro, dal numero di sistemi da integrare e dal livello di chiarezza con cui l'azienda arriva al primo incontro con il fornitore.
Cos'è la fase di analisi di un progetto software
La fase di analisi è il primo passaggio del ciclo di vita di un progetto software, quello in cui un'esigenza operativa viene trasformata in un insieme di requisiti chiari e verificabili. Non produce ancora codice né schermate: il suo output è un documento che descrive processi, dati, vincoli e obiettivi, e che diventa la base su cui si costruisce tutto il resto del progetto. Chi commissiona un software arriva quasi sempre con un problema concreto - un processo lento, dati sparsi su più fogli di calcolo, un gestionale che non dialoga con altri sistemi - e non con una specifica tecnica già pronta. Il compito dell'analisi è proprio trasformare quel problema in requisiti funzionali e non funzionali, casi d'uso e vincoli operativi.
All'interno di questa fase rientrano attività distinte: la raccolta dei requisiti tramite interviste e workshop con gli utenti reali, lo studio di fattibilità tecnica ed economica, la modellazione del dominio applicativo e, a seconda della complessità del progetto, la progettazione preliminare dell'architettura dati. Ogni sotto-attività richiede il coinvolgimento di persone diverse in azienda: chi usa il sistema ogni giorno, chi ne definisce il budget, chi dovrà garantirne la manutenzione nel tempo. È proprio la necessità di coordinare questi attori a incidere sulla durata complessiva più del volume di documentazione da produrre in sè.
Quanto dura la fase di analisi: le tempistiche reali
La durata della fase di analisi cambia in modo significativo in base al perimetro del progetto e al numero di sistemi coinvolti, ma esistono tre fasce ricorrenti che si osservano nella maggior parte dei progetti software commissionati da aziende italiane.
- Applicativo verticale con pochi utenti e un solo reparto coinvolto: da due a tre settimane. È il caso tipico di uno strumento che digitalizza un singolo processo, senza integrazioni complesse con altri sistemi.
- Progetto che coinvolge più reparti e richiede integrazioni con ERP, CRM o gestionali esistenti: da sei a otto settimane. La maggior parte del tempo in più non serve a scrivere il documento, ma a mappare correttamente API, formati di scambio e responsabilità tra i diversi sistemi.
- Progetto enterprise, in ambito della Pubblica Amministrazione o con componenti IoT e intelligenza artificiale: da otto a dodici settimane, talvolta oltre. Su questi progetti l'analisi include quasi sempre anche una fase di verifica tecnica dedicata, spesso sotto forma di Proof of Concept.
Queste fasce sono indicative e vanno sempre verificate nel primo incontro con il fornitore, perché la stima definitiva dipende da variabili specifiche del singolo progetto, non da regole generali applicabili a qualunque contesto.
I fattori che allungano o accorciano i tempi di analisi
Alcuni elementi incidono più di altri sulla durata effettiva dell'analisi, indipendentemente dalla dimensione nominale del progetto.
- Numero di stakeholder da coinvolgere: più reparti significano più interviste, più cicli di validazione e più probabilità che emergano richieste in conflitto tra loro.
- Presenza di sistemi legacy da integrare: verificare API non documentate o formati di scambio datati richiede tempo tecnico che si aggiunge alla raccolta dei requisiti.
- Chiarezza dei requisiti in ingresso: un'azienda che arriva con un problema ben descritto e una consapevolezza profonda dei propri processi interni accorcia sensibilmente la fase iniziale di elicitazione.
- Necessità di un Proof of Concept: quando la fattibilità tecnica di un aspetto specifico è incerta, va verificata prima di proseguire, e questo può allungare i tempi complessivi.
- Vincoli normativi o di settore: ambiti come la Pubblica Amministrazione, la sanità o la finanza aggiungono vincoli di conformità da mappare durante l'analisi.
- Disponibilità del team cliente: se le persone da intervistare hanno agende piene, i workshop si diluiscono nel tempo anche quando il perimetro tecnico è tutto sommato semplice.
Chi vuole contenere i tempi di analisi può agire soprattutto sull'ultimo punto: arrivare al primo incontro con le persone giuste già individuate riduce la parte più imprevedibile dell'intero processo.
Le fasi interne dell'analisi e quanto incide ciascuna sulla durata
Un'analisi ben strutturata si compone di attività distinte, ciascuna con un peso diverso sulla durata complessiva.
Raccolta dei requisiti e verifica di fattibilità
La prima attività consiste nel mappare i processi così come funzionano davvero, non come sono descritti sulla carta. Richiede interviste dirette con chi usa il sistema quotidianamente e con chi ne governa il budget, oltre all'individuazione dei vincoli normativi, infrastrutturali e di competenze interne. Da qui esce la verifica di fattibilità, cioè la risposta onesta alla domanda se il progetto sia realizzabile, con quali tecnologie e a quali condizioni. Su progetti semplici questa attività assorbe circa un terzo del tempo totale di analisi; su progetti con più reparti coinvolti può crescere, perché il numero di interviste e cicli di validazione cresce in proporzione al numero di persone coinvolte.
Studio dell'architettura dati e delle integrazioni
Il dato è la parte che sopravvive a ogni futura riscrittura del software, quindi va progettato con attenzione fin da questa fase. Si definiscono il modello dati, le entità e le relazioni, i livelli di accesso per ruolo e le politiche di storicizzazione delle informazioni. In parallelo si verifica cosa deve dialogare con cosa: ERP, CRM, gestionali, macchinari, sistemi legacy. È in questa attività che si nascondono la maggior parte delle sorprese che allungano i tempi, perché le API disponibili raramente corrispondono del tutto alla documentazione ufficiale, quando esiste.
Analisi funzionale e progettazione delle interfacce
I requisiti raccolti vengono tradotti in funzioni concrete: casi d'uso, ruoli, permessi, stati del sistema, gestione delle eccezioni. Su questa base si progettano le interfacce, partendo dai wireframe fino ad arrivare al design UX/UI vero e proprio. L'obiettivo non è l'effetto grafico, ma la riduzione dei passaggi: se una persona ripete la stessa operazione decine di volte al giorno, ogni click risparmiato in fase di progettazione si traduce in tempo di lavoro recuperato ogni giorno per gli anni successivi.
Realizzazione del prototipo dinamico
Non uno screenshot statico, ma un modello navigabile in cui si passa da una schermata all'altra seguendo i flussi reali che il software dovrà supportare. È il momento in cui il progetto smette di essere un documento e diventa qualcosa che gli utenti finali possono testare prima ancora che venga scritta la prima riga di codice. Le correzioni raccolte in questa fase, quando arrivano da chi userà l'applicativo ogni giorno, valgono più di qualunque revisione fatta a tavolino.
Cosa succede se si salta o si accorcia la fase di analisi
La fase di analisi nel suo core (escludendo quindi la progettazione ux/ui e la prototipazione dinamica) ha un difetto strutturale: non produce nulla di visibile. Non ci sono schermate da mostrare, non c'è codice che gira, e per questo è spesso la prima voce che si prova a tagliare quando il budget stringe o le scadenze si accorciano. È anche, nella pratica, il taglio che costa di più nel tempo. I progetti software raramente falliscono per limiti tecnici: s’interrompono se a metà percorso si scopre che il flusso reale differisce da quello immaginato, che un sistema di terze parti non espone i dati come previsto, o che due reparti si aspettavano risultati diversi dalla stessa funzione.
A quel punto la correzione non è più una riga di codice da modificare: è una riprogettazione, con costi e tempi che superano di gran lunga quanto si sarebbe speso per un'analisi completa fatta all'inizio. Una fase di analisi condotta con metodo serve esattamente a far emergere questi punti quando correggerli costa una riunione, non settimane di sviluppo e revisione delle integrazioni già scritte.
«Se stai valutando un nuovo progetto software e vuoi capire perimetro, tempi e costi prima di impegnarti, una call conoscitiva di trenta minuti con il team di analisi e progettazione di Antha è il modo più rapido per avere una stima reale.»
Come si svolge la fase di analisi con una software house
Il primo passaggio è sempre un incontro conoscitivo, in genere di circa trenta minuti, in cui emergono perimetro, punti critici e fattibilità di massima, prima di qualunque preventivo vincolante. Da lì parte la raccolta strutturata dei requisiti, condotta a quattro mani con il cliente attraverso interviste e workshop mirati, seguita dallo studio dell'architettura dei dati e dalla mappa delle integrazioni con i sistemi esistenti. Un approccio agile applicato già in questa fase permette di pianificare cicli di sviluppo iterativi fin dal principio, anziché rimandare la pianificazione a un momento successivo. Alcune software house si affidano inoltre a framework di sviluppo già pronti all’uso e con moduli nativi già consolidati - dalla gestione delle identità e degli accessi fino all'API Gateway - che permettono di stimare tempi e costi su basi concrete invece che teoriche, riducendo ulteriormente il margine di incertezza sulla durata complessiva.
Il percorso di analisi e progettazione software si chiude sempre con una restituzione formale al cliente: documento dei requisiti, schema dell'architettura dati, wireframe e prototipo navigabile, più un piano di lavoro con attività, priorità e scadenze condivise. Questo documento resta di proprietà del cliente anche se lo sviluppo viene affidato a un altro fornitore, ed è spesso utilizzato per confrontare preventivi o per costruire un business case interno. Quando il progetto prevede il collegamento con sistemi terzi già in uso in azienda, la mappa delle integrazioni realizzata in questa fase diventa il riferimento tecnico per tutto lo sviluppo successivo.
Un esempio concreto di come un'analisi ben condotta guidi l'intero progetto è il sistema di gestione dati clinici realizzato per Emergency, dove la mappatura dei processi in fase di analisi ha permesso di gestire vincoli operativi non banali fin dal primo giorno di lavoro.
Quanto costa la fase di analisi di un progetto software
Il costo dell'analisi viene quasi sempre quotato sul perimetro effettivo, definito nel primo incontro conoscitivo, e non su una tariffa standard applicabile a qualunque progetto. Come ordine di grandezza, incide generalmente fra il dieci e il venti per cento del valore complessivo del progetto: una quota che può sembrare significativa se isolata dal resto, ma che riduce in modo concreto il rischio sul restante ottanta per cento, cioè sulla fase in cui viene effettivamente scritto il software. Aziende che hanno già affrontato una riprogettazione a metà sviluppo, dopo aver saltato o compresso l'analisi iniziale, riconoscono facilmente perché questa proporzione abbia senso: il costo di correggere un requisito frainteso cresce in modo significativo a ogni fase successiva del progetto in cui viene individuato.
Domande frequenti sulla fase di analisi di un progetto software
Cosa comprende la fase di analisi di un progetto software?
Comprende la raccolta dei requisiti funzionali e non funzionali, lo studio di fattibilità tecnica ed economica, la modellazione dell'architettura dei dati, la mappa delle integrazioni con sistemi terzi e, a seconda dei casi, wireframe e un prototipo navigabile delle interfacce principali. Il risultato finale è un documento di analisi che descrive processi mappati, casi d'uso, vincoli e assunzioni, oltre a un piano di lavoro con attività, priorità e scadenze condivise con il cliente.
Qual è la differenza tra analisi dei requisiti e analisi funzionale?
L'analisi dei requisiti stabilisce cosa il software deve ottenere: obiettivi, vincoli, esigenze delle persone coinvolte. L'analisi funzionale definisce invece come lo ottiene, attraverso funzioni, ruoli, permessi, casi d'uso e comportamento del sistema nelle eccezioni. La prima risponde al perché di una scelta progettuale, la seconda al come viene effettivamente implementata.
Si può commissionare solo l'analisi, senza lo sviluppo del software?
Sì. L'analisi viene restituita al cliente in forma di documento completo e resta di sua proprietà, indipendentemente da chi realizzerà poi lo sviluppo. Diversi clienti la usano per confrontare preventivi di fornitori diversi, per costruire un business case interno o per presentare il progetto a un potenziale finanziatore. Se lo sviluppo viene affidato a un altro fornitore, il documento resta comunque utilizzabile come riferimento tecnico.
Proof of Concept, prototipo o MVP: quale serve al mio progetto?
I tre termini vengono spesso usati come sinonimi, ma rispondono a domande diverse. Il Proof of Concept risponde alla domanda se un'idea sia tecnicamente fattibile, e si concentra su un singolo aspetto critico senza essere destinato agli utenti finali. Il prototipo risponde alla domanda se l'esperienza d'uso funzioni, riproducendo flussi e interfacce senza logica applicativa reale. L'MVP risponde alla domanda se il prodotto regga sul campo, ed è software funzionante a tutti gli effetti, ridotto alle funzioni essenziali e rilasciato a utenti reali. Su un progetto con tecnologia consolidata il Proof of Concept è spesso superfluo; su un progetto con componenti IoT o di intelligenza artificiale è quasi sempre il passaggio che evita l'investimento sbagliato.
Serve avere già le idee chiare prima di iniziare l'analisi?
No, ed è la condizione più comune tra chi contatta una software house. Nella maggior parte dei casi il cliente arriva con un problema operativo - un processo lento, dati sparsi su più fogli di calcolo, un gestionale che non comunica con il resto - e non con una specifica funzionale già pronta. Trasformare quel problema in requisiti chiari e verificabili è esattamente il compito della fase di analisi.
