Il ciclo di vita del software, in inglese SDLC (Software Development Life Cycle), è il percorso che un programma compie dall'idea al ritiro: si decide cosa serve, lo si progetta, lo si costruisce, lo si collauda, lo si mette in uso e poi lo si mantiene. Le fasi, in ordine, sono sette:

Pianificazione e analisi: perché serve il software, con quale budget e in quanto tempo.
Requisiti: cosa deve fare, scritto in modo verificabile.
Progettazione: schermate, dati e tecnologie, prima di scrivere codice.
Sviluppo: la scrittura del codice, un blocco alla volta.
Test: la verifica che tutto funzioni, anche nei casi scomodi.
Rilascio: la messa in uso, con dati e persone pronti.
Manutenzione: correzioni, aggiornamenti e nuove funzioni, per anni.

Sotto trovi, fase per fase, cosa controllare anche se non sei un tecnico.

Cos'è il ciclo di vita del software (SDLC)

Un software non nasce quando qualcuno inizia a programmare e non finisce quando va online: prima bisogna capire il problema, dopo bisogna tenerlo in piedi per anni. Il ciclo di vita è la mappa di questo percorso: se commissioni un software, ti dice in ogni momento a che punto sei, cosa dovresti avere in mano e cosa tocca decidere a te.

Cosa significa SDLC

SDLC è la sigla di Software Development Life Cycle, cioè «ciclo di vita dello sviluppo del software». Nell'uso comune è sinonimo di ciclo di vita del software: a rigore il primo termine mette l'accento sullo sviluppo, il secondo comprende tutta la vita del programma fino alla dismissione, ma le fasi sono le stesse.

Le descrive anche uno standard internazionale, la norma ISO/IEC/IEEE 12207, aggiornata nel 2026: va dall'acquisizione del software allo sviluppo, dall'esercizio alla manutenzione, fino alla dismissione.

Perché si chiama «ciclo»

Perché non finisce con il rilascio. Ogni correzione o nuova funzione riparte, in piccolo, dalle stesse fasi: si capisce cosa serve, si progetta, si sviluppa, si testa, si rilascia. Un software in uso gira in questo ciclo finché non viene sostituito. Per questo un fornitore che salta l'analisi o i test non ti fa risparmiare: sposta solo il costo più avanti, quando correggere costa di più.

Le 7 fasi del ciclo di vita del software, una per una

I nomi cambiano da un manuale all'altro: c'è chi unisce analisi e requisiti, chi aggiunge la dismissione come ottava fase. La sostanza è questa.

1. Pianificazione e analisi

Si parte dal problema, non dalla soluzione: cosa non funziona oggi, cosa deve migliorare, con quale budget ed entro quando. Si valuta anche se conviene costruire su misura, per esempio un software gestionale personalizzato, o usare un programma già pronto.

Cosa succede: colloqui con il titolare e con chi farà il lavoro ogni giorno, obiettivi, vincoli, prima stima dei costi.
Chi la fa: tu, o chi decide in azienda, con l'analista del fornitore.
Cosa produce: obiettivi, perimetro della prima versione e stima di massima. Spesso nasce qui l'MVP (Minimum Viable Product): la versione minima che risolve già il problema principale.
Cosa controlli tu: che l'obiettivo sia misurabile («preventivi pronti in 10 minuti invece che in un'ora», non «lavorare meglio») e che budget e scadenza siano quelli veri.

2. Requisiti

Si scrive nel dettaglio cosa deve fare il software. I requisiti funzionali descrivono le funzioni («il commerciale crea un preventivo dal listino»); quelli non funzionali il comportamento: velocità, sicurezza, chi vede cosa, su quali dispositivi.

Cosa succede: si raccolgono i casi reali, si danno le priorità (indispensabile, utile, rimandabile) e si fissano i criteri di accettazione, cioè le condizioni per dire «questa funzione è fatta».
Chi la fa: l'analista, con te e con chi userà il software.
Cosa produce: il documento dei requisiti, o capitolato tecnico, con funzioni, priorità ed esclusioni.
Cosa controlli tu: che ogni requisito sia verificabile («la ricerca di un cliente risponde in meno di due secondi», non «deve essere veloce») e che sia scritto anche cosa non è incluso. Un errore corretto qui costa molto meno che nelle fasi successive.

3. Progettazione

Si decide come sarà fatto il software prima di costruirlo: le schermate, il percorso di chi lo usa e l'architettura, cioè come sono organizzati i dati e con quali programmi deve parlare.

Cosa succede: si disegnano i wireframe (schizzi delle schermate), poi un prototipo cliccabile; si scelgono il database (dove e come si salvano i dati) e le tecnologie.
Chi la fa: un designer dell'interfaccia (UX/UI) e lo sviluppatore più esperto del progetto.
Cosa produce: prototipo, schema dei dati, elenco di integrazioni e tecnologie.
Cosa controlli tu: fai provare il prototipo a chi userà il software. Chiedi tecnologie diffuse e standard: un domani qualsiasi sviluppatore potrà riprendere il lavoro.

4. Sviluppo

È la scrittura del codice. Si procede a blocchi, una funzione alla volta, e ogni blocco si può già provare.

Cosa succede: si costruiscono la parte visibile (front-end) e la logica che lavora sui dati (back-end). Il codice sta in un repository, l'archivio che conserva tutte le versioni, e ogni modifica viene riletta da un altro sviluppatore (code review).
Chi la fa: il team di sviluppo.
Cosa produce: funzioni da provare in un ambiente di test, separato da quello reale.
Cosa controlli tu: che ogni una o due settimane ci sia qualcosa da provare, che tu abbia accesso al repository e che ogni modifica chiesta in corsa sia messa per iscritto, con il suo effetto su costi e tempi.

5. Test

Si verifica che il software faccia quello che dicono i requisiti, anche nei casi scomodi. I test partono durante lo sviluppo e si chiudono con il collaudo del cliente.

Cosa succede: test automatici sui singoli pezzi, prove dei flussi completi, test di regressione (una modifica non deve rompere ciò che prima funzionava), prove di velocità e sicurezza. Spesso c'è una versione alfa, provata internamente, e una beta, data a pochi utenti reali.
Chi la fa: sviluppatori e tester; alla fine tu e il tuo personale, con il collaudo (il test di accettazione).
Cosa produce: difetti trovati e corretti, collaudo firmato.
Cosa controlli tu: prova con dati e casi veri, come il cliente che annulla, l'ordine con due indirizzi, l'aliquota IVA diversa. Firma solo se i criteri di accettazione sono rispettati. Approfondisci nella guida ai tipi di test del software.

6. Rilascio

Il rilascio (in inglese deploy) è la messa in produzione: il software diventa quello vero, usato dal personale o dai clienti. Per un'app comprende la pubblicazione sugli store (App Store e Google Play).

Cosa succede: si configurano i server, si portano i dati dal vecchio sistema o dai fogli Excel, si forma chi lo userà. Spesso si parte con pochi utenti e con un piano per tornare alla versione precedente se qualcosa va storto (rollback).
Chi la fa: gli sviluppatori; tu curi formazione e comunicazione interna.
Cosa produce: software in uso, credenziali di amministrazione, note di rilascio (cosa è cambiato), un breve manuale.
Cosa controlli tu: credenziali principali intestate alla tua azienda, backup (copie di sicurezza) attivi e provati, dati migrati corretti almeno a campione, un nome da chiamare se qualcosa si blocca.

7. Manutenzione ed evoluzione

È la fase più lunga, perché un software resta in uso per anni: correzioni, adeguamenti a nuove versioni di iOS, Android e browser o a nuove regole, aggiornamenti di sicurezza, nuove funzioni. Alla fine anche la dismissione va gestita: dati esportati, accessi chiusi.

Cosa succede: monitoraggio degli errori, aggiornamento delle librerie (i componenti di terze parti su cui il software si appoggia), piccoli rilasci periodici. Ogni nuova funzione ripercorre il ciclo in piccolo.
Chi la fa: lo stesso team, o un altro se il codice è standard e documentato.
Cosa produce: un contratto di manutenzione con perimetro scritto, un registro delle modifiche, report periodici.
Cosa controlli tu: che la manutenzione sia nel budget fin dall'inizio: come regola pratica, il 15–20% del costo iniziale all'anno. Tipi e costi sono spiegati nella guida alla manutenzione del software.

Fasi di sviluppo di un software: la tabella riassuntiva

La stessa sequenza in una tabella, da tenere a portata di mano quando parli con il fornitore.

Fase	Domanda a cui risponde	Chi è coinvolto	Cosa ti consegnano	Cosa controlli tu
1. Pianificazione e analisi	Perché lo facciamo e con quale budget?	Titolare, analista	Obiettivi, perimetro, stima di massima	Obiettivo misurabile, budget reale
2. Requisiti	Cosa deve fare, esattamente?	Analista, utenti chiave	Capitolato con priorità e criteri di accettazione	Requisiti verificabili, esclusioni scritte
3. Progettazione	Come sarà fatto?	Designer UX/UI, sviluppatore senior	Prototipo, schema dei dati, tecnologie	Prototipo provato dagli utenti, tecnologie standard
4. Sviluppo	Come lo costruiamo?	Sviluppatori	Funzioni da provare in ambiente di test	Avanzamenti visibili, accesso al codice
5. Test	Funziona davvero?	Sviluppatori, tester, utenti	Difetti corretti, collaudo	Prove con dati e casi reali
6. Rilascio	Come lo mettiamo in uso?	Sviluppatori, personale	Software online, credenziali, manuale	Credenziali intestate a te, backup attivi
7. Manutenzione	Come lo teniamo in forma?	Team di sviluppo	Aggiornamenti, correzioni, report	Budget annuo e perimetro scritti

Modelli di sviluppo: Waterfall, a V, iterativo, Agile e DevOps

Le fasi sono sempre quelle. Cambia il modo di percorrerle: tutte in fila una volta sola, oppure tante volte in piccolo. È questo che si intende per modello o metodologia di sviluppo.

Waterfall (modello a cascata)

Le fasi si fanno una dopo l'altra, come l'acqua di una cascata, e tornare indietro costa. Funziona con requisiti chiari e stabili, progetti piccoli e ben delimitati o quando serve molta documentazione formale. Il rischio: vedi il software solo alla fine e scopri tardi se era quello che ti serviva.

Modello a V

È una variante della cascata: a ogni fase di progettazione corrisponde un test pianificato fin dall'inizio, dal collaudo dei requisiti fino ai test sui singoli componenti. Serve dove gli errori costano molto, come nei dispositivi medici o nei software soggetti a certificazioni; per il gestionale di una piccola azienda è quasi sempre troppo pesante.

Iterativo e incrementale

Si costruisce una prima versione con l'essenziale e la si arricchisce a giri successivi (iterazioni), ognuno con un pezzo in più (incremento) e tutte le fasi in piccolo. Funziona quando vuoi usare qualcosa presto e spendere a tappe. Il rischio: senza un perimetro scritto per ogni giro, il progetto si allarga senza fine.

Agile: Scrum e Kanban in breve

La metodologia Agile prende il nome dal Manifesto Agile, scritto nel 2001, che privilegia tra l'altro «il software funzionante più che la documentazione esaustiva» e il «rispondere al cambiamento più che seguire un piano». In pratica: consegne frequenti, cliente coinvolto a ogni passo, priorità riviste spesso.

Scrum, uno dei modi più usati per lavorare in Agile, divide il lavoro in sprint: cicli di durata fissa che secondo la Scrum Guide durano un mese o meno, spesso una o due settimane, e si chiudono con una revisione del lavoro fatto. Le priorità le fissa il Product Owner, che in un progetto commissionato può essere una persona della tua azienda o del fornitore.

Kanban non lavora a cicli: usa una lavagna con colonne (da fare, in corso, fatto) e limita le attività aperte insieme, così il lavoro scorre senza ingorghi. È adatto alla manutenzione e alle richieste continue.

Il rischio: usare «agile» come scusa per non scrivere niente. Agile non vuol dire senza piano, ma piano breve e aggiornato spesso.

DevOps

Non è un modello di fasi, ma un modo di lavorare che unisce chi sviluppa (Dev) e chi gestisce il software in produzione (Ops). Si basa sulle automazioni: ogni modifica viene testata e può andare online in automatico (si chiama CI/CD, integrazione e rilascio continui) e il software è monitorato di continuo. Serve soprattutto ai software che devono restare sempre online e cambiano spesso, come un e-commerce: rilasci più piccoli, quindi meno rischiosi.

Tabella di confronto: quale modello usare e quando

Modello	Come funziona	Quando sceglierlo	Rischio principale	Quanto sei coinvolto tu
Waterfall	Fasi in fila, una volta sola	Requisiti stabili, progetto piccolo, molta documentazione	Scoprire alla fine che serviva altro	All'inizio e al collaudo
A V	Cascata con un test pianificato per ogni fase	Settori regolamentati, errori molto costosi	Lento e costoso per progetti semplici	All'inizio e nelle verifiche formali
Iterativo e incrementale	Prima versione essenziale, poi giri successivi	Vuoi usarlo presto e spendere a tappe	Perimetro che si allarga senza fine	A ogni giro
Agile (Scrum, Kanban)	Cicli brevi o flusso continuo, priorità riviste spesso	Prodotto nuovo, bisogni da scoprire	Nessuno che decide le priorità	Di continuo, ogni 1–2 settimane
DevOps	Test e rilasci automatici, monitoraggio	Software sempre online e aggiornato spesso	Automazioni sprecate se il software cambia poco	Poco, sul lato tecnico

Agile vs Waterfall: cosa cambia per chi commissiona

Prezzo: con la cascata si definisce tutto prima e il prezzo è chiuso; con Agile si fissa un budget e si decide strada facendo cosa entra.
Modifiche: nella cascata ogni cambio è una variante da rinegoziare; in Agile entra nel backlog, la lista ordinata delle cose da fare, e si decide in quale ciclo farlo.
Visibilità: nella cascata vedi il software alla fine; in Agile ne vedi un pezzo funzionante a ogni ciclo.
Impegno: Agile chiede a te, o a un tuo referente, tempo costante per provare e decidere.

Per una piccola azienda la strada più sensata è spesso ibrida: analisi e progettazione fatte bene all'inizio, per avere un preventivo con perimetro e consegne scritte, poi sviluppo a cicli brevi, con un pezzo funzionante da provare ogni una o due settimane.

Esempio: il ciclo di vita di un sistema di prenotazioni per un ristorante

Immagina un ristorante che riceve le prenotazioni al telefono e su WhatsApp, le segna su un'agenda di carta e ogni tanto si ritrova un tavolo prenotato due volte.

Pianificazione: l'obiettivo è ricevere le prenotazioni dal sito, con conferma automatica e meno telefonate durante il servizio, prima che inizi la stagione. Prima versione: prenotazione e gestione della sala. Rimandati: caparra per i gruppi e promemoria su WhatsApp.
Requisiti: il cliente sceglie giorno, orario e numero di persone e vede solo gli orari con posti liberi; riceve la conferma via email e un promemoria il giorno prima; il titolare vede la sala per turno e può spostare una prenotazione. Criterio di accettazione: se alle 21 i coperti sono esauriti, quell'orario non compare.
Progettazione: prototipo di tre schermate (prenota, conferma, sala), provato dal titolare e dal personale di sala su un tablet. Si sceglie una web app, cioè un'applicazione che si usa dal browser senza passare dagli store.
Sviluppo: tre blocchi di due settimane (prenotazione, sala, notifiche); alla fine di ognuno il titolare prova quello che c'è.
Test: i casi scomodi, come il gruppo di nove persone, la disdetta all'ultimo minuto, due clienti che prenotano l'ultimo tavolo nello stesso istante. Poi una settimana di beta sul solo turno del pranzo.
Rilascio: il sistema va online sul sito, le prenotazioni già prese vengono copiate dall'agenda e il personale fa un'ora di formazione. Per la prima settimana il telefono resta il piano B.
Manutenzione: correzioni dopo i primi weekend pieni, poi le evoluzioni rimandate. Ognuna ripercorre il ciclo in piccolo.

Un progetto così rientra di solito tra le app e le web app semplici: prezzi indicativi e fattori di costo sono nella guida su quanto costa creare un'app.

Il caso Nutrimi: dalle specifiche scritte al software in uso

Nutrimi è un software gestionale per nutrizionisti che abbiamo realizzato per un cliente. Durante la visita l'AI ascolta e compila la bozza dell'anamnesi, divisa in 14 sezioni; il software calcola la composizione corporea con più metodi e il fabbisogno, ha un editor delle diete con un «semaforo» e produce i report in PDF. È un buon esempio di ciclo di vita in un progetto reale:

Requisiti: il cliente ci ha portato un documento di specifiche scritto da professionisti. È il punto di partenza ideale, perché chi conosce il mestiere ha già messo nero su bianco cosa deve fare il software.
Sviluppo: quel documento è stato trasformato in software voce per voce, così ogni funzione si può ricondurre a un punto delle specifiche.
Test: in un software che fa calcoli, «sembra funzionare» non basta. I numeri sono stati controllati a mano su pazienti di prova.
Manutenzione ed evoluzione: il software cresce a ogni giro di feedback del cliente. Le richieste vengono messe per iscritto, con cosa c'è già e cosa manca, e poi rilasciate.

Per questo, dopo la messa online, proponiamo la gestione continua a canone: diventiamo il reparto tecnico del cliente e il ciclo prosegue un rilascio alla volta.

Errori tipici da evitare (e come prevenirli)

Partire dalla soluzione. «Facciamo un'app» non è un obiettivo. Prima chiarisci il problema e come misurerai il risultato.
Requisiti vaghi. «Deve essere semplice» non si può collaudare. Scrivi criteri di accettazione: quando faccio questo, deve succedere quest'altro.
Tutto nella prima versione. Più funzioni metti all'inizio, più tardi inizi a usare il software. Parti dall'indispensabile.
Nessuno che decide. Senza un referente interno che risponde in fretta, qualsiasi modello di sviluppo si blocca.
Test tagliati quando si è in ritardo. È il risparmio più caro: gli errori li troveranno i tuoi clienti.
Codice e credenziali solo al fornitore. Se codice sorgente e accessi non sono tuoi, cambiare fornitore diventa difficile. Fallo scrivere nel contratto.
Pensare che il rilascio sia la fine. Senza manutenzione il software invecchia: librerie superate, falle di sicurezza, funzioni che smettono di andare.
«Usiamo Agile» come slogan. Chiedi ogni quanto vedrai qualcosa di funzionante, chi decide le priorità e come si gestiscono le modifiche: le risposte contano più dell'etichetta. Altri criteri sono nella guida su come scegliere una software house.

Domande frequenti sul ciclo di vita del software

Cosa significa SDLC?

SDLC è la sigla di Software Development Life Cycle, in italiano «ciclo di vita dello sviluppo del software»: le fasi con cui un software viene pianificato, costruito, collaudato, rilasciato e mantenuto.

Quali sono le fasi del ciclo di vita del software, in ordine?

Pianificazione e analisi, requisiti, progettazione, sviluppo, test, rilascio e manutenzione. Alcuni testi le raggruppano in cinque o sei fasi, altri ne contano otto aggiungendo la dismissione, ma l'ordine logico è sempre questo.

Qual è la fase più importante del ciclo di vita del software?

Quella dei requisiti, perché tutte le altre si basano su quello che c'è scritto lì: un errore nei requisiti si trascina in progettazione, sviluppo e test. La fase più lunga, invece, è la manutenzione, che accompagna il software per tutta la sua vita.

Quanto dura il ciclo di vita di un software?

Lo sviluppo di una prima versione va da qualche settimana, per un progetto piccolo, a diversi mesi per un gestionale con più moduli. La vita del software, cioè il periodo in cui viene usato e mantenuto, si misura invece in anni.

Che differenza c'è tra SDLC e metodologia di sviluppo?

L'SDLC descrive cosa deve succedere: le fasi. La metodologia (Waterfall, Agile, Scrum, Kanban) descrive come organizzarle: tutte in fila una volta sola, oppure in tanti cicli brevi. Lo stesso ciclo di vita si può seguire con metodologie diverse.

Agile e Scrum sono la stessa cosa?

No. Agile è un insieme di principi: consegne frequenti, collaborazione con il cliente, adattamento ai cambiamenti. Scrum è uno dei modi concreti per applicarli, con sprint di durata fissa, ruoli ed eventi precisi. Anche Kanban è un approccio agile, ma lavora a flusso continuo.

In sintesi

Il ciclo di vita del software (SDLC) è la sequenza di fasi che trasforma un'idea in un software in uso e lo tiene in forma negli anni; il modello di sviluppo decide solo come percorrerle. Per chi commissiona la regola è semplice: a ogni fase devi avere in mano qualcosa di concreto da controllare.

Se hai un progetto in mente e vuoi sapere quanto può costare, con la Stima in 2 minuti descrivi l'idea in due righe e ricevi subito un range di prezzo, senza lasciare l'email.

Ciclo di vita del software (SDLC): fasi, modelli ed esempi