Il ciclo di vita dello sviluppo software (Software Development Life Cycle, o SDLC) è il processo strutturato utilizzato per pianificare, creare, testare, distribuire e mantenere il software. Per i CTO e i leader dell'ingegneria, le fasi dell'SDLC non sono burocrazia: sono il sistema operativo per una delivery prevedibile, un'ingegneria sicura fin dalla progettazione (secure-by-design) e investimenti di prodotto responsabili.
In sintesi
- Le sette fasi principali dell'SDLC sono pianificazione, analisi, progettazione, implementazione (sviluppo), collaudo (testing), rilascio (deployment) e manutenzione.
- Agile, Waterfall, Modello a Spirale e V-Model non sono rivali per definizione; ciascuno risponde a uno specifico profilo di rischio, governance e incertezza.
- Sicurezza, conformità e manutenibilità vanno integrate in ciascuna fase dell'SDLC, non aggiunte all'ultimo momento prima del rilascio.
- I modelli SDLC ibridi sono spesso la scelta pragmatica per le scale-up e le medie imprese europee.
- Il modello SDLC giusto è quello che i vostri team possono eseguire in modo coerente, misurare oggettivamente e migliorare di continuo.
Che cos'è il ciclo di vita dello sviluppo software e perché le fasi dell'SDLC sono importanti?
Il ciclo di vita dello sviluppo software è un framework ripetibile per trasformare un'esigenza aziendale in software funzionante e supportato. Le fasi dell'SDLC sono fondamentali perché creano punti di controllo condivisi per scope, architettura, ingegneria, collaudo, rilascio e miglioramento. Senza di esse, i team si affidano a sforzi individuali improvvisati, decisioni non documentate e alla scoperta tardiva dei rischi.
Secondo lo standard ISO/IEC/IEEE 12207:2026, pubblicato nell'aprile 2026, la norma stabilisce un framework comune per i processi del ciclo di vita del software e si applica dal concepimento fino allo sviluppo, all'operatività, al supporto e alla dismissione. Dichiara inoltre che i processi del ciclo di vita possono essere applicati in modo concorrente, iterativo, ricorsivo e incrementale, il che è fondamentale: «SDLC» non significa «vecchio Waterfall». (iso.org)
Per un CTO europeo, l'SDLC è utile perché collega tre livelli di controllo:
- Controllo di business: perché stiamo finanziando questo prodotto e quale valore deve generare?
- Controllo ingegneristico: come lo progetteremo, svilupperemo, testeremo e gestiremo in sicurezza?
- Controllo di governance: quali evidenze dimostrano che qualità, sicurezza e conformità sono state gestite correttamente?
Un SDLC solido previene anche un tipico fallimento di scalabilità. I team nelle prime fasi si muovono spesso rapidamente grazie a una comunicazione informale. Quando l'azienda arriva a più squad, fornitori esterni, clienti regolamentati o operazioni transfrontaliere, la delivery informale smette di funzionare.
L'SDLC dà a questi team un linguaggio comune. I product owner possono descrivere i requisiti. Gli architetti possono registrare le decisioni di progettazione. Gli ingegneri possono tracciare il codice rispetto agli elementi del backlog. I team di QA e sicurezza possono testare rispetto a criteri concordati. Le operations vedono cosa è cambiato, quando e perché.
La sicurezza fa ormai parte dell'SDLC. Secondo il NIST SP 800-218, Secure Software Development Framework versione 1.1, finalizzato il 3 febbraio 2022 e pubblicato nel febbraio 2022, pochi modelli SDLC affrontano esplicitamente la sicurezza del software in dettaglio, perciò le pratiche di sicurezza vanno di norma integrate in ciascuna implementazione. (csrc.nist.gov)
Questo è il punto per chi dirige: le fasi dell'SDLC non devono rallentare la delivery. Se eseguite bene, riducono le rilavorazioni, rendono visibili le decisioni e aiutano i team a rilasciare con sicurezza.
Quali sono le fasi chiave dell'SDLC in un progetto software moderno?
Le fasi chiave dell'SDLC sono pianificazione, analisi, progettazione, implementazione, collaudo, rilascio e manutenzione. Ciascuna fase risponde a una domanda diversa di delivery: perché sviluppare, cosa sviluppare, come sviluppare, se funziona, come rilasciarlo e come migliorarlo in sicurezza dopo il lancio.
Queste fasi vengono di solito mostrate in sequenza, ma i team moderni le ripercorrono spesso in cicli brevi. Un team Scrum, per esempio, può pianificare, analizzare, progettare, sviluppare, testare e rilasciare un incremento di prodotto essenziale all'interno di un singolo sprint.
| Fase SDLC | Obiettivo chiave | Deliverable principali |
|---|---|---|
| 1. Pianificazione | Definire l'obiettivo commerciale, i risultati e i rischi | Business case, piano finanziario, confini dello scope |
| 2. Analisi | Tradurre le intenzioni in requisiti e obblighi normativi | Specifiche dei requisiti, criteri di tracciabilità |
| 3. Progettazione | Creare la soluzione tecnica, la topologia e il modello dati | Decisioni architetturali (ADR), modelli di sicurezza, mock-up UX |
| 4. Implementazione | Scrivere codice secondo gli standard di manutenibilità | Codice sorgente, unit test, documentazione API |
| 5. Collaudo | Validare funzionalità, sicurezza e prestazioni | Report di test, difetti corretti, evidenze di conformità |
| 6. Rilascio | Spostare le modifiche in produzione in sicurezza | Pacchetto di release, istruzioni di deployment |
| 7. Manutenzione | Monitorare, gestire gli incidenti e raccogliere feedback | Aggiornamenti, patch di sicurezza, backlog di miglioramento |
La pianificazione dovrebbe definire le ragioni commerciali del lavoro: risultati di business, stakeholder, modello di finanziamento, vincoli di delivery e ipotesi di rischio iniziali. Una fase di pianificazione debole genera «team occupati» anziché software di valore.
L'analisi trasforma le intenzioni in requisiti operativi. Un'analisi efficace distingue tra regole di business, esigenze degli utenti, requisiti non funzionali e obblighi di conformità. Nei settori regolamentati, è qui che inizia la tracciabilità.
La progettazione traduce i requisiti in una soluzione tecnica: architettura, flussi dati, pattern di integrazione, controlli di sicurezza, topologia di deployment ed esperienza utente. Secondo la norma ISO/IEC 25010:2023, il modello di qualità del prodotto contiene nove caratteristiche per i prodotti ICT e software, e offre ai team un modo strutturato per discutere della qualità oltre il semplice «funziona». (iso.org)
L'implementazione è la fase in cui gli ingegneri creano il prodotto, ma non va considerata l'unica fase «vera» dell'SDLC. Le decisioni di codifica incidono su manutenibilità, osservabilità, resilienza e costi futuri.
Il collaudo dovrebbe combinare test automatizzati, test esplorativi, test di prestazioni, verifiche di accessibilità e validazione della sicurezza. Il rilascio porta poi le modifiche in produzione attraverso pratiche di release controllate. La manutenzione chiude il ciclo usando incidenti, telemetria e feedback degli utenti per migliorare il ciclo successivo.
Quali tipologie di modelli SDLC dovrebbero conoscere i leader tecnologici?
I leader tecnologici dovrebbero conoscere innanzitutto Waterfall, Agile, Modello a Spirale e V-Model, perché rappresentano i principali compromessi di delivery: prevedibilità, adattabilità, gestione del rischio e disciplina di verifica. La maggior parte delle organizzazioni reali usa modelli ibridi, combinando l'esecuzione Agile con la governance architetturale, i gate di conformità e la gestione strutturata delle release.
| Modello SDLC | Focus principale | Integrazione ideale | Rischio principale |
|---|---|---|---|
| Waterfall | Esecuzione sequenziale | Requisiti stabili, procurement formale | Feedback utenti tardivo |
| Agile | Adattabilità iterativa | Mercati dinamici, apprendimento rapido | Rischio di perdita del controllo architetturale |
| Modello a Spirale | Gestione del rischio | Progetti ad elevata incertezza | Elevati costi di analisi |
| V-Model | Disciplina di verifica | Sistemi regolamentati e critici | Rigidità al cambio dei requisiti |
Waterfall esegue le fasi in sequenza. È adatto ai progetti con requisiti stabili, dove il procurement richiede milestone formali o dove l'accettazione contrattuale dipende dalla documentazione. Il suo punto debole è il feedback tardivo: gli utenti potrebbero non vedere software funzionante finché le ipotesi principali non sono già costose da cambiare.
Agile lavora in brevi iterazioni e valorizza il software funzionante, la collaborazione e la reattività. Il Manifesto Agile, pubblicato nel 2001, ha stabilito i valori alla base di questo movimento, inclusi la collaborazione con il cliente e la risposta al cambiamento. (agilemanifesto.org) La Guida a Scrum 2020 di Ken Schwaber e Jeff Sutherland definisce Scrum come un framework leggero per generare valore attraverso soluzioni adattive a problemi complessi. (scrumguides.org)
Il Modello a Spirale è guidato dal rischio. L'articolo di Barry Boehm del 1988 su IEEE Computer ha descritto il modello a spirale come un approccio evolutivo e guidato dal rischio per orientare il processo software. È utile quando incertezza tecnica, sicurezza, architettura o rischi dei fornitori vanno valutati ripetutamente prima di impegnare ulteriori investimenti. (doi.org)
Il V-Model affianca alle attività di sviluppo le corrispondenti attività di verifica e validazione. È diffuso negli ambienti in cui le evidenze contano: software medico, sistemi automotive, difesa, sistemi embedded e altri settori ad alta affidabilità. Lo standard IEEE 1012-2024, pubblicato nel 2024, disciplina i processi di verifica e validazione lungo i cicli di vita di sistemi, software e hardware. (ieeexplore.ieee.org)
Per molte aziende con 50–500 dipendenti, la risposta pratica non è un modello da manuale. È un ibrido: product discovery e delivery in modalità Agile, record delle decisioni architetturali (ADR), gate di qualità automatizzati, controlli di sicurezza documentati e governance dei rilasci proporzionata al rischio.
Come scegliere il modello SDLC giusto per il proprio progetto?
Il modello SDLC si sceglie valutando stabilità dei requisiti, esposizione normativa, incertezza tecnica, maturità del team, frequenza dei rilasci e disponibilità degli stakeholder. Se i requisiti sono fissi, servono più controlli predittivi. Se l'apprendimento è essenziale, serve Agile. Se un fallimento costerebbe caro, vanno aggiunte verifiche più rigide, review dei rischi ed evidenze di sicurezza.
Si parte da sei domande diagnostiche:
- Quanto sono stabili i requisiti? Uno scope stabile supporta Waterfall o V-Model. Uno scope volatile favorisce Agile o la delivery iterativa.
- Quanto sarebbe grave un fallimento? Maggiore è l'impatto su sicurezza, finanza, ambito legale o reputazione, maggiore è la verifica necessaria.
- Con quale frequenza deve cambiare il prodotto? Un feedback frequente dal mercato favorisce Agile, DevOps e continuous delivery.
- Chi deve approvare le decisioni? Auditor esterni, clienti enterprise e buyer del settore pubblico richiedono spesso evidenze documentali.
- Quanto è maturo il team? Agile senza un'ingegneria disciplinata si trasforma in cambiamento incontrollato.
- Quanto è integrato il sistema? Dipendenze complesse possono richiedere una governance architetturale prima dell'esecuzione a livello di sprint.
Secondo il report Pulse of the Profession 2024 del PMI, pubblicato nel febbraio 2024 e basato sull'indagine globale annuale sulla gestione dei progetti del 2023, i team di progetto hanno registrato prestazioni comparabili tra approcci predittivi, ibridi e agili. La Figura 14 dello stesso report indica una prestazione media dei progetti nel 2023 pari al 73,8%, con uno scope creep medio del 30% e una perdita media di budget per i progetti falliti del 25,7%; sono evidenze di un'indagine sul project management, non un benchmark esclusivamente software. (pmi.org)
Questa distinzione è fondamentale. I dirigenti dovrebbero evitare i dogmatismi metodologici. Agile non è automaticamente moderno. Waterfall non è automaticamente sbagliato. L'errore tipico è scegliere un modello per ideologia anziché per i vincoli reali.
Per un prodotto SaaS o per lo sviluppo di web app aziendali, usate discovery in modalità Agile, trunk-based development, test automatizzati e progressive delivery. Per la modernizzazione di un ERP, usate una governance ibrida: architettura iniziale, ondate di migrazione iterative e criteri di accettazione formali. Per il software embedded regolamentato, usate la disciplina del V-Model con tracciabilità dai requisiti ai test.
In tutti i casi, integrate la sicurezza nella scelta. Secondo la sintesi del Cyber Resilience Act della Commissione Europea, il Regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024; gli obblighi di segnalazione dell'Articolo 14 si applicano dall'11 settembre 2026, e il Regolamento diventa pienamente applicabile dall'11 dicembre 2027. Questo mette sviluppo sicuro, gestione delle vulnerabilità ed evidenze di prodotto direttamente nella roadmap dei fabbricanti di prodotti con elementi digitali. (digital-strategy.ec.europa.eu)
Quali benefici offre un SDLC strutturato e cosa dovrebbero fare i leader?
Un SDLC strutturato migliora prevedibilità, qualità, sicurezza, verificabilità e manutenibilità a lungo termine. Il passo successivo è renderlo operativo: definire i diritti decisionali, automatizzare la raccolta delle evidenze, misurare flusso e qualità, e rivedere il modello ogni trimestre perché evolva insieme al prodotto e all'organizzazione.
Il primo beneficio è un migliore controllo degli investimenti. Pianificazione e analisi costringono i leader a definire i risultati prima che la capacità venga consumata. Questo riduce il rischio che i team costruiscano funzionalità tecnicamente valide che però non cambiano il comportamento dei clienti, i ricavi, l'efficienza o la postura di conformità.
Il secondo beneficio è la qualità fin dalla progettazione (quality assurance by design). Il collaudo costa meno quando i requisiti sono testabili, l'architettura è revisionabile e il codice è osservabile. Secondo il comunicato stampa del CISQ del 6 dicembre 2022 sul report The Cost of Poor Software Quality in the US: A 2022 Report, lo studio ha stimato il costo della scarsa qualità del software negli Stati Uniti nel 2022 in 2.410 miliardi di dollari e il debito tecnico accumulato in circa 1.520 miliardi; è una stima economica per gli Stati Uniti, non un benchmark enterprise europeo, ma mostra la scala dei costi di qualità evitabili. (it-cisq.org)
Il terzo beneficio è la mitigazione dei rischi. Sicurezza, privacy, resilienza e rischi dei fornitori si possono affrontare fase per fase. Le linee guida tecniche dell'ENISA del giugno 2025 sul Regolamento di esecuzione NIS2 elencano aree come la sicurezza della catena di fornitura e la sicurezza nell'acquisizione, nello sviluppo e nella manutenzione per i soggetti rilevanti che gestiscono infrastrutture digitali e servizi ICT. (enisa.europa.eu)
Il quarto beneficio è un onboarding più rapido e un migliore allineamento con i fornitori. Un SDLC chiaro spiega ai team interni, ai partner nearshore e ai vendor come il lavoro passa dall'idea alla produzione. Riduce le ambiguità su proprietà del backlog, standard di codifica, Definition of Done, approvazione dei rilasci e feedback sugli incidenti.
Per rendere operative le fasi dell'SDLC, i leader dovrebbero:
- definire un'unica policy sul ciclo di vita per tutto il lavoro software, con varianti più leggere per le modifiche a basso rischio;
- mappare i controlli sulle fasi, inclusi OWASP SAMM, NIST SSDF e ISO/IEC 25010 dove pertinenti;
- automatizzare CI/CD, collaudo, scansione delle dipendenze ed evidenze di rilascio;
- tracciare lead time, tasso di fallimento delle modifiche, difetti sfuggiti e andamento del debito tecnico;
- rivedere l'SDLC dopo incidenti rilevanti, audit e cambi di direzione del prodotto.
L'SDLC più efficace non è il documento più dettagliato. È il sistema di delivery più semplice che dà alla vostra organizzazione velocità, evidenze e controllo.
Fonti
- ISO/IEC/IEEE 12207:2026, Systems and software engineering — Software life cycle processes: https://www.iso.org/standard/90219.html
- NIST SP 800-218, Secure Software Development Framework Version 1.1: https://csrc.nist.gov/pubs/sp/800/218/final
- Commissione Europea, Cyber Resilience Act — Summary of the legislative text: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- CISQ, Cost of Poor Software Quality in the US: A 2022 Report, comunicato stampa: https://www.it-cisq.org/press-releases/12-06-22/
- PMI, Pulse of the Profession 2024 — The Future of Project Work: https://www.pmi.org/learning/thought-leadership/future-of-project-work
- ISO/IEC 25010:2023, SQuaRE — Product quality model: https://www.iso.org/standard/78176.html
- Agile Manifesto, 2001: https://agilemanifesto.org/
- Scrum Guide, 2020: https://scrumguides.org/scrum-guide.html
- Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, 1988: https://doi.org/10.1109/2.59
- ENISA, Technical implementation guidance supporting NIS2 implementation, giugno 2025: https://www.enisa.europa.eu/news/supporting-nis2-implementation-through-actionable-guidance
FAQ
Domande frequenti sull'SDLC
Risposte rapide per i responsabili tecnici che valutano fasi, modelli e governance della delivery nell'SDLC.
