TL;DR — le sei fasi in sintesi
Ogni progetto software su misura di successo attraversa le stesse sei fasi, indipendentemente dal fatto che il team utilizzi un approccio agile o ibrido. Saltare o affrettare qualsiasi fase genera costi a valle che superano sistematicamente il tempo risparmiato. Ecco la versione breve:
- Discovery: Definire cosa costruire e perché — requisiti, perimetro, modello di dati, decisioni architetturali. 4–6 settimane.
- Design & architettura: Wireframe UX, design UI, blueprint di sistema. 3–5 settimane.
- Sprint di sviluppo: Build agile iterativo, software funzionante ogni 2 settimane. 12–24 settimane per i progetti di media complessità.
- Test & QA: Test automatizzati, QA manuale, revisione della sicurezza, profilazione delle performance. 3–5 settimane (in parallelo agli sprint).
- Deploy & lancio: Verifica in staging, rilascio in produzione, monitoraggio go-live. 1–2 settimane.
- Supporto & iterazione: Correzione bug, patch di sicurezza, nuove funzionalità. 15–20 % del costo di build all’anno.
Panoramica: l’intero ciclo SDLC in una tabella
La tabella seguente riepiloga cosa produce ogni fase, la durata tipica e il suo peso nel costo totale di una piattaforma di media complessità (build da 90.000 €–230.000 €).
| Fase | Output principali | Durata tipica | % del costo di build |
|---|---|---|---|
| 1. Discovery | Documento dei requisiti, modello di dati, Architecture Decision Record, project charter | 4–6 settimane | 10–15 % |
| 2. Design & architettura | Wireframe, sistema UI, contratti API, diagramma infrastrutturale | 3–5 settimane | 8–12 % |
| 3. Sprint di sviluppo | Incrementi software funzionanti, demo di sprint, build pronti per il rilascio | 12–24 settimane | 55–65 % |
| 4. Test & QA | Suite di test automatizzati, report QA, risultati sicurezza, baseline di performance | 3–5 settimane | 8–12 % |
| 5. Deploy & lancio | Ambiente di produzione, pipeline CI/CD, runbook, checklist go-live | 1–2 settimane | 3–5 % |
| 6. Supporto & iterazione | Rilasci di patch, incrementi funzionali, dashboard di monitoraggio | Continuativo | 15–20 % /anno |
Fase 1: Discovery
La discovery è la fase più determinante dell’intero ciclo di vita del software. Trasforma un problema di business in una specifica tecnica costruibile. Senza di essa, i team di sviluppo costruiscono la cosa sbagliata alla massima velocità.
Una fase di discovery ben condotta produce quattro artefatti fondamentali:
- Documento dei requisiti: user story, criteri di accettazione, decisioni fuori perimetro e gestione dei casi limite.
- Modello di dati: le entità, le relazioni e i vincoli che il sistema deve rappresentare. È il fondamento di ogni decisione architetturale successiva.
- Architecture Decision Record (ADR): stack tecnologico, punti di integrazione, strategia di hosting, requisiti di conformità e compromessi documentati con la loro motivazione.
- Project charter: perimetro, milestone, composizione del team, cadenza di comunicazione e percorsi di escalation.
La discovery dura tipicamente 4–6 settimane per un progetto di media complessità e costa 14.000 €–22.000 € con un team nearshore senior. È quasi sempre prezzata separatamente dal build principale — e giustamente. Il deliverable della discovery è ciò che permette a un preventivo a prezzo fisso o a un cap a tempo e materiali di avere significato. Senza di essa, qualsiasi prezzo fisso è una stima al buio.
I team che saltano la discovery riportano sistematicamente gli stessi sintomi: requisiti che cambiano dopo che l’architettura è definita, integrazioni scoperte a metà sprint, requisiti di conformité del Regolamento UE 2016/679 (GDPR/Garante) applicati retroattivamente dopo il lancio. Ognuno di questi è più costoso da correggere di quanto sarebbe costata un’intera fase di discovery. Leggete la nostra guida sullo sviluppo MVP per una prospettiva complementare sul perimetro dei progetti in fase iniziale.
Fase 2: Design & architettura
Il design e l’architettura traducono gli artefatti della discovery nel blueprint visivo e strutturale su cui il team di sviluppo lavorarà. Si sviluppa in due flussi di lavoro paralleli.
UX e UI design produce i flussi utente, i wireframe e i mockup ad alta fedeltà. Per il software orientato al prodotto, ottenere l’UX giusta prima dell’inizio dello sviluppo non è una questione estetica — previene il tipo di rilavorazione più costoso: ricostruire un’interfaccia che gli utenti reali rifiutano. Una libreria di componenti ben progettata accelera anche lo sviluppo, poiché gli ingegneri costruiscono su un sistema coerente piuttosto che inventare l’UI schermata per schermata.
Architettura di sistema produce il diagramma infrastrutturale, i contratti API, il piano di migrazione dei dati (se applicabile) e il runbook tecnico. Le decisioni chiave prese qui includono: monolite vs microservizi, comunicazione sincrona vs event-driven, strategia di autenticazione e autorizzazione, requisiti di residenza e cifratura dei dati, e progettazione della pipeline CI/CD.
Le decisioni architetturali prese in questa fase sono costose da invertire. Scegliere la strategia sbagliata di partizionamento dei dati, ad esempio, può richiedere una migrazione completa sei mesi dopo. Gli architetti senior giustificano il loro costo in questa fase effettuando compromessi informati piuttosto che seguire soluzioni familiari o di moda.
Fase 3: Sprint di sviluppo
Lo sviluppo è il punto in cui viene consumata la quota maggiore del budget — tipicamente il 55–65 % del costo totale. Per i progetti di media complessità dura 12–24 settimane su più sprint agili.
Ogni sprint segue lo stesso ritmo: planning (definire gli obiettivi dello sprint dal backlog), build (gli ingegneri implementano le story concordate), review (software funzionante dimostrato agli stakeholder), retrospettiva (azioni di miglioramento del team). La cadenza di sprint bisettimanale svolge una funzione critica: fa emergere i disallineamenti presto, quando sono poco costosi da correggere, piuttosto che alla consegna, quando non lo sono più.
Pratiche ingegneristiche chiave che distinguono una consegna professionale da una amatoriale:
- Code review: ogni pull request revisionata da almeno un ingegnere senior prima del merge. Previene l’accumulo di debito tecnico.
- Test automatizzati: test unitari, di integrazione e end-to-end scritti in parallelo con le funzionalità, non come recupero. Copertura minima del 70 % sui percorsi critici.
- Feature flag: nuove funzionalità deployate dietro flag, che consentono rollout incrementali e rollback sicuri senza overhead di deployment.
- Sicurezza by construction: validazione degli input, gestione dei segreti, mitigazioni OWASP Top 10 e scansione delle vulnerabilità delle dipendenze integrati nel workflow di sviluppo, non applicati retroattivamente in QA.
Per i team con requisiti di conformità (residenza dei dati GDPR/Garante, audit trail SOC 2, trattamento PHI HIPAA), i controlli di conformità devono essere integrati nelle story dello sprint fin dall’inizio, non aggiunti dopo la consegna. Vedere la nostra pagina del servizio di sviluppo software su misura per i dettagli su come strutturiamo la consegna agile conforme.
Fase 4: Test & QA
L’assurance della qualità viene eseguita in parallelo agli sprint di sviluppo piuttosto che come fase discreta post-build. Ma un ciclo QA dedicato alla fine dello sviluppo rimane essenziale prima di qualsiasi rilascio in produzione.
La piramide di test per il software di livello produzione copre quattro strati:
- Test unitari: test rapidi e isolati di singole funzioni e componenti. Eseguiti ad ogni commit. Devono coprire il 70 %+ della logica di business.
- Test di integrazione: verificano che componenti e servizi interagiscano correttamente. Coprono i contratti API critici e le operazioni sul database.
- Test end-to-end: simulano percorsi utente reali in un ambiente deployato. Coprono tutti i flussi utente principali e i casi limite documentati in discovery.
- Test non funzionali: profilazione delle performance sotto carico realistico, penetration test di sicurezza (per gli ambienti regolamentati), audit di accessibilità (WCAG 2.1 AA minimo per il software pubblico EU/US).
Un penetration test di sicurezza è non negoziabile per qualsiasi software che tratta dati personali (conformità GDPR/Regolamento UE 2016/679 e Garante per la protezione dei dati personali), transazioni finanziarie (PCI-DSS) o cartelle cliniche (HIPAA). Per il software destinato ai mercati europei, la Valutazione d’Impatto sulla Protezione dei Dati (DPIA) è un obbligo legale per le attività di trattamento ad alto rischio e deve essere completata prima del lancio, non dopo una richiesta del Garante.
Fase 5: Deploy & lancio
Il deploy è la fase più breve ma quella con la visibilità pubblica più elevata. Un lancio non riuscito crea un problema di fiducia che richiede settimane di comunicazione operativa per essere risolto, indipendentemente dalla qualità tecnica del software.
Il deploy di livello produzione per un progetto di media complessità comprende:
- Provisioning dell’infrastruttura: ambiente cloud configurato per il carico di produzione, security group, policy di backup e alerting in place.
- Pipeline CI/CD: pipeline automatizzata di build, test e deploy in modo che i rilasci futuri richiedano minuti, non giorni.
- Rollout graduale: il traffico di produzione viene migrato dal vecchio al nuovo sistema in incrementi (5 % → 25 % → 100 %) con trigger di rollback automatico se i tassi di errore aumentano.
- Monitoraggio go-live: dashboard in tempo reale per tasso di errore, latenza, throughput e metriche infrastrutturali nelle prime 72 ore post-lancio. È attesa la copertura on-call dell’ingegneria durante questa finestra.
- Runbook operativo: procedure documentate per le attività operative comuni, la risposta agli incidenti e i percorsi di escalation. Essenziale per i team cliente che prendono in carico dopo il trasferimento.
Fase 6: Supporto & iterazione
Il software che non viene mantenuto attivamente si degrada. Non in modo spettacolare o immediato — ma costantemente. Le dipendenze diventano obsolete. Le vulnerabilità di sicurezza si accumulano. Le performance peggiorano con la crescita dei volumi di dati. Funzionalità che funzionavano con 100 utenti si rompono con 10.000.
I benchmark di settore collocano sistematicamente il supporto e la manutenzione continuativi al 15–20 % del costo iniziale di build all’anno. Cosa copre quel budget per una piattaforma di media complessità:
- Patch di sicurezza e aggiornamenti delle dipendenze: CVE critiche e alte corrette entro SLA concordate (tipicamente 24–72 ore per le critiche). Non negoziabile.
- Correzione bug dai feedback degli utenti reali: i primi 90 giorni post-lancio fanno emergere la maggior parte dei bug di casi limite che i test non hanno intercettato.
- Scaling dell’infrastruttura: aggiustamenti di capacità con la crescita della base utenti, ottimizzazione dei costi man mano che i pattern di utilizzo si stabilizzano.
- Iterazioni funzionali: aggiunte di funzionalità guidate dai dati utente, miglioramenti UX e integrazioni guidate dalla roadmap di prodotto.
- Monitoraggio e on-call: alerting 24/7 con SLA di risposta definiti. Per il software revenue-critical, gli incidenti P1 devono essere presi in carico entro 15 minuti.
Per un build da 140.000 €, prevedete 21.000 €–28.000 € all’anno per il supporto. Per un build da 280.000 €, 42.000 €–56.000 € all’anno. I team che azzerano il budget di supporto si trovano tipicamente a dover affrontare una riscrittura completa forzata entro 3–5 anni al 150–200 % del costo originale. Leggete la nostra guida sul costo dello sviluppo software su misura nel 2026 per il modello completo dei costi di manutenzione.
L’iterazione in questa fase non è manutenzione — è sviluppo del prodotto. Le analisi di utilizzo, i ticket di supporto e i feedback commerciali alimentano un backlog prioritizzato. I nuovi rilasci in questa fase sono più rapidi e meno costosi del build iniziale, perché l’architettura è consolidata, il team conosce il codebase e la pipeline CI/CD è operativa. Scegliere il partner di sviluppo giusto è importante in questa fase: cercate un team capace sia di manutenzione a lungo termine che di consegna rapida di funzionalità. Leggete la nostra guida su come scegliere una società di sviluppo software per valutare i partner su entrambe le dimensioni.
FAQ
Quali sono le fasi dello sviluppo software?
Le sei fasi principali sono: discovery (requisiti e architettura), design e architettura (blueprint UX e di sistema), sprint di sviluppo (build agile iterativo), test e QA (verifica automatizzata e manuale), deploy e lancio (rilascio in produzione), e supporto e iterazione (manutenzione ed evoluzione funzionale). Ogni fase produce artefatti specifici e condiziona la fase successiva. Saltare le fasi genera costi a valle che superano sistematicamente il tempo risparmiato.
Perché la fase di discovery è importante?
La discovery converte un problema di business in una specifica tecnica concreta e costruibile prima che qualsiasi budget di sviluppo venga impegnato. Identifica la complessità delle integrazioni, i requisiti di conformità al Regolamento UE 2016/679 (GDPR/Garante) e i vincoli architetturali che altrimenti emergerebbero come sorprese costose a metà build. I progetti che investono in una discovery seria di 4–6 settimane risparmiano tipicamente il 30–50 % di rilavorazioni durante il build.
Quanto tempo richiede ogni fase?
Per un progetto di media complessità: discovery 4–6 settimane; design e architettura 3–5 settimane; sprint di sviluppo 12–24 settimane; test e QA 3–5 settimane (in parallelo agli sprint); deploy e lancio 1–2 settimane. La durata totale end-to-end è tipicamente 5–9 mesi dal kick-off al lancio in produzione. I progetti enterprise complessi durano 12–24 mesi.
Utilizzate la metodologia agile o a cascata?
Utilizziamo un modello ibrido: fasi strutturate di discovery e architettura (gate waterfall leggeri) seguite da sprint agili bisettimanali per la consegna. Questo modello combina rigore architetturale e flessibilità di consegna. Il waterfall puro non è adatto alla maggior parte dei software su misura perché i requisiti evolvono. L’agile puro senza architettura a monte genera debito tecnico che si accumula nel tempo. Il modello ibrido è lo standard attuale per il software su misura PMI ed enterprise.
Cosa succede dopo il lancio?
Il software entra nella fase di supporto e iterazione: patch di sicurezza, correzione bug, scaling dell’infrastruttura e nuove funzionalità. Prevedete il 15–20 % del costo di build all’anno per questa fase. L’iterazione post-lancio è più rapida e meno costosa del build iniziale perché l’architettura e la pipeline CI/CD sono già in place. Non tagliate questo budget — la manutenzione differita crea un debito tecnico compounding che impone una riscrittura completa entro 3–5 anni.
Pubblicato il 21 maggio 2026. Le tempistiche di processo e le percentuali di costo riflettono la consegna nearshore senior per progetti software su misura di media complessità. Le tempistiche individuali variano in base al perimetro, alla complessità delle integrazioni e ai requisiti di conformità.
