Il ciclo di vita del software enterprise nel 2026
La realizzazione di un software enterprise può essere descritta attraverso una serie di fasi che comprendono analisi, progettazione, sviluppo, verifica, rilascio ed evoluzione del sistema. Nella pratica, soprattutto nei progetti complessi, queste attività raramente procedono secondo una sequenza completamente lineare: requisiti, architettura, sviluppo, sicurezza e operations tendono infatti a influenzarsi reciprocamente e a essere rivisti più volte durante il ciclo di vita dell’applicazione.
Un requisito può essere ridefinito dopo un prototipo, una scelta architetturale può essere aggiornata quando emergono nuovi vincoli infrastrutturali, mentre test e osservazione del comportamento dell’applicazione possono generare indicazioni utili per le successive iterazioni. Per questo, nei moderni contesti enterprise è spesso più appropriato parlare di software delivery lifecycle, intendendo un processo nel quale attività tecniche e di business rimangono collegate attraverso cicli progressivi di implementazione e feedback.
Nel 2026 questa impostazione assume particolare rilevanza in presenza di architetture cloud-native, pipeline CI/CD, API, sistemi distribuiti e software supply chain composte da librerie e servizi esterni. A questi elementi si aggiunge l’utilizzo crescente di strumenti di intelligenza artificiale generativa nelle attività di analisi, sviluppo, testing e documentazione, che può accelerare alcune fasi del processo ma richiede comunque meccanismi adeguati di verifica e governance.
Anche la sicurezza viene sempre più frequentemente integrata nelle diverse fasi del ciclo di sviluppo. Il National Institute of Standards and Technology, attraverso il Secure Software Development Framework e i successivi approfondimenti dedicati ai modelli DevSecOps, propone un approccio nel quale le pratiche di sicurezza accompagnano sviluppo, delivery e operations anziché essere concentrate esclusivamente nei controlli precedenti al rilascio.
Comprendere il ciclo di vita di un software enterprise significa quindi osservare non soltanto le singole fasi, ma anche il modo in cui requisiti, architettura, qualità, sicurezza e gestione operativa interagiscono lungo l’intero percorso che conduce dall’esigenza iniziale a un sistema utilizzabile in produzione.
Discovery e problem framing: definire il problema prima della soluzione
La fase iniziale di un progetto software è generalmente dedicata alla comprensione dell’esigenza che ha determinato l’avvio dell’iniziativa e dei risultati che l’organizzazione intende raggiungere.
In questa fase può essere utile distinguere il problema dalla soluzione inizialmente immaginata. Una richiesta espressa attraverso un insieme di funzionalità, infatti, può essere il risultato di processi esistenti, vincoli organizzativi o sistemi che richiedono prima di tutto di essere analizzati.
La discovery comprende normalmente obiettivi di business, utenti coinvolti, processi attuali, sistemi già presenti, vincoli tecnici e normativi e principali risultati attesi. Workshop, interviste, process mapping, analisi della documentazione e prototipazione possono contribuire a costruire una rappresentazione condivisa del contesto.
Un’organizzazione che intende automatizzare un processo amministrativo, per esempio, potrebbe inizialmente immaginare una nuova applicazione composta da schermate, workflow e approvazioni. L’analisi potrebbe successivamente evidenziare che alcune criticità derivano da dati duplicati, integrazioni mancanti o passaggi organizzativi ridondanti. In questo caso il progetto software può comprendere anche una revisione parziale del processo, oltre alla sua digitalizzazione.
L’output della discovery non deve necessariamente assumere la forma di una specifica definitiva. Nei modelli iterativi può essere rappresentato da obiettivi, requisiti iniziali, assunzioni e vincoli che vengono progressivamente affinati durante il progetto.
Requisiti funzionali e non funzionali: descrivere comportamento e condizioni operative
Una volta definito il contesto, i requisiti consentono di specificare il comportamento atteso del sistema e le condizioni nelle quali dovrà operare.
I requisiti funzionali descrivono le operazioni che il software deve supportare, mentre quelli non funzionali riguardano caratteristiche quali performance, disponibilità, scalabilità, sicurezza, accessibilità, privacy, osservabilità e continuità operativa.
Questi ultimi possono influenzare in modo significativo le decisioni architetturali. Un’applicazione utilizzata da un numero limitato di utenti interni presenta, per esempio, esigenze differenti rispetto a un servizio pubblico con elevati volumi di traffico; allo stesso modo, un sistema che gestisce dati personali o informazioni finanziarie richiede controlli differenti rispetto a un’applicazione che tratta informazioni non sensibili.
Identificare questi requisiti nelle prime fasi consente di valutarne l'impatto sulle scelte successive, limitando la necessità di interventi strutturali quando il sistema è già in una fase avanzata di realizzazione.
Progettazione architetturale: tradurre requisiti e vincoli in una struttura tecnica
La progettazione architetturale definisce il modo in cui responsabilità, dati e interazioni vengono distribuiti tra le diverse componenti del sistema.
La scelta non riguarda esclusivamente linguaggi, framework e database, ma comprende il modello complessivo dell’applicazione, le modalità di integrazione, il deployment, la gestione dei dati e il rapporto con l’infrastruttura.
Monolite modulare, microservizi, architetture event-driven, API, servizi managed e differenti modelli cloud rappresentano opzioni che possono risultare adeguate in funzione del contesto.
La scelta tra questi approcci dipende generalmente da fattori quali dimensione e competenze del team, requisiti di scalabilità, necessità di deployment indipendenti, complessità del dominio e capacità operative dell’organizzazione.
Un’architettura basata su numerosi microservizi, per esempio, può essere appropriata quando esistono confini di dominio chiari e team autonomi, ma introduce anche esigenze ulteriori in termini di observability, deployment, gestione delle dipendenze e resilienza.
La progettazione architetturale consiste quindi soprattutto nella valutazione dei trade-off, considerando non soltanto le caratteristiche tecniche della soluzione, ma anche il costo necessario per mantenerla ed evolverla nel tempo.
Architecture Decision Record: conservare il contesto delle decisioni tecniche
Nei sistemi con un ciclo di vita pluriennale può essere utile documentare non soltanto l’architettura finale, ma anche le ragioni che hanno portato alle principali decisioni.
Gli Architecture Decision Record, comunemente indicati come ADR, permettono di registrare il contesto di una scelta, le alternative considerate e le conseguenze previste.
Questo tipo di documentazione può facilitare la manutenzione futura perché consente ai team di ricostruire il reasoning associato a una decisione anche quando le persone che l’hanno presa non lavorano più sul progetto.
Una soluzione che alcuni anni dopo appare poco efficiente può infatti essere stata selezionata in presenza di vincoli che successivamente sono cambiati. Conservare queste informazioni consente di valutare con maggiore precisione se una scelta debba essere mantenuta o rivista.
Security by design e DevSecOps: integrare i controlli nel lifecycle
La sicurezza applicativa viene sempre più spesso affrontata lungo l’intero ciclo di sviluppo.
Il Secure Software Development Framework del NIST raccoglie pratiche che possono essere integrate nei diversi modelli di Software Development Life Cycle, includendo attività relative alla protezione del software, alla produzione di componenti sicuri, alla gestione delle vulnerabilità e alla preparazione dell’organizzazione.
In questa prospettiva, attività come threat modeling, gestione dei secret, analisi delle dipendenze, definizione degli accessi e valutazione della superficie di attacco possono essere avviate già durante progettazione e sviluppo.
La logica DevSecOps estende lo stesso principio alle pipeline di delivery, introducendo controlli automatizzati che possono accompagnare il codice durante build, test e deployment.
Nel 2026 il NIST ha continuato a sviluppare linee guida e materiali dedicati all’applicazione del Secure Software Development Framework nelle moderne pipeline DevSecOps, confermando la crescente integrazione tra software engineering e application security.
Delivery planning e backlog: trasformare requisiti e architettura in attività implementabili
Dopo la definizione iniziale dei requisiti e dell’architettura, il lavoro viene generalmente suddiviso in unità progressivamente implementabili.
Nei contesti Agile questo avviene attraverso backlog, epic, feature e user story, ma terminologia e livello di dettaglio possono variare sensibilmente tra le organizzazioni.
L'obiettivo è costruire unità di lavoro abbastanza contenute da consentire sviluppo, verifica e feedback senza perdere il collegamento con il risultato che la funzionalità dovrebbe produrre.
Nel backlog possono trovare spazio anche attività che non generano direttamente nuove funzionalità visibili agli utenti, come refactoring, automazione delle pipeline, security hardening, aggiornamento delle dipendenze o miglioramento dell’observability.
La gestione di queste attività insieme alle esigenze funzionali aiuta a mantenere un equilibrio tra velocità di delivery e sostenibilità tecnica del prodotto.
Development: dalla scrittura del codice al software engineering workflow
Durante la fase di implementazione il codice viene sviluppato e progressivamente integrato nel sistema, ma il lavoro dello sviluppatore comprende ormai numerose attività che si estendono oltre la semplice programmazione.
Version control, dependency management, automated testing, static analysis, code review, containerizzazione e pipeline CI/CD fanno parte del normale workflow di molti team software.
Nel 2026 si aggiunge inoltre l’utilizzo crescente di coding assistant e strumenti generativi capaci di produrre codice, test, documentazione e suggerimenti di refactoring.
Questi strumenti possono ridurre il tempo necessario per alcune attività di implementazione, mentre rimane necessario verificare l’output rispetto a requisiti funzionali, sicurezza, performance, qualità e coerenza con l’architettura del progetto.
L’utilizzo dell’AI tende quindi a modificare la distribuzione del lavoro tra produzione e verifica del codice, senza eliminare la responsabilità tecnica del team sul risultato finale.
Version control e code review: tracciabilità e condivisione della conoscenza
I sistemi di version control costituiscono una delle infrastrutture centrali del software development contemporaneo.
Un repository può contenere non soltanto codice sorgente, ma anche configurazioni, test, pipeline, documentazione e definizioni infrastrutturali, permettendo di mantenere una cronologia delle modifiche apportate al sistema.
La code review introduce un ulteriore livello di verifica collaborativa. Oltre all’individuazione di errori, può riguardare leggibilità, manutenibilità, sicurezza, aderenza alle convenzioni del progetto e coerenza con le decisioni architetturali.
La revisione del codice svolge inoltre una funzione di knowledge sharing, soprattutto nei team nei quali più persone devono essere in grado di intervenire sulle stesse componenti.
CI/CD: automatizzare integrazione e preparazione del rilascio
Continuous Integration e Continuous Delivery hanno progressivamente ridotto la separazione tra sviluppo e rilascio.
La Continuous Integration prevede l’integrazione frequente delle modifiche all’interno della codebase condivisa, accompagnata da processi automatizzati di build e verifica. La Continuous Delivery estende il modello preparando continuamente versioni del software potenzialmente distribuibili.
Una pipeline enterprise può includere compilazione, unit test, integration test, static analysis, vulnerability scanning, costruzione degli artefatti, generazione della SBOM e deployment verso diversi ambienti.
Il principale vantaggio dell’automazione è la ripetibilità del processo.
Procedure di rilascio codificate riducono la dipendenza da attività manuali e rendono più semplice ricostruire quali controlli siano stati eseguiti su una determinata versione.
Software supply chain: gestire anche i componenti esterni
La maggior parte delle applicazioni moderne utilizza una quantità significativa di componenti che non vengono sviluppati direttamente dal team.
Framework, librerie open source, package, container image e servizi esterni fanno parte della software supply chain e contribuiscono alle caratteristiche funzionali e di sicurezza dell’applicazione.
La gestione delle dipendenze comprende quindi aspetti relativi a versioning, manutenzione, licenze e vulnerabilità conosciute.
Strumenti come Software Bill of Materials, dependency scanning e artifact signing permettono di aumentare la visibilità sui componenti utilizzati e supportare le attività di gestione del rischio.
Si tratta di un processo continuo, perché una dipendenza considerata sicura al momento del rilascio può essere successivamente interessata dalla pubblicazione di nuove vulnerabilità.
Testing strategy: distribuire la verifica lungo il processo
Nei modelli contemporanei il testing non è necessariamente concentrato in una fase successiva al completamento dello sviluppo.
Unit test, component test, integration test, API test, end-to-end test, performance test e security test verificano aspetti differenti del sistema e possono essere eseguiti in momenti diversi della pipeline.
La progettazione della test strategy dipende dal tipo di applicazione e dal rischio associato alle diverse componenti.
Test molto rapidi possono essere eseguiti a ogni modifica, mentre verifiche più costose in termini di tempo o infrastruttura possono essere collocate nelle fasi successive del processo.
L’obiettivo è generalmente costruire un livello di copertura adeguato mantenendo tempi di feedback compatibili con il ritmo di sviluppo.
Quality engineering: estendere il concetto di qualità oltre la correttezza funzionale
La qualità di un software non dipende esclusivamente dall’assenza di bug.
Performance, manutenibilità, sicurezza, accessibilità, affidabilità e costo operativo contribuiscono alla qualità complessiva del prodotto.
Per questo in molti contesti il concetto tradizionale di Quality Assurance viene affiancato da quello di quality engineering, che distribuisce l’attenzione alla qualità lungo tutte le fasi del ciclo.
Developer, QA specialist, architect, security specialist, product owner e operations possono contribuire da prospettive differenti alla definizione e alla verifica dei criteri di accettazione del sistema.
La qualità diventa quindi una proprietà costruita progressivamente durante il processo di sviluppo anziché una verifica effettuata soltanto sul prodotto completato.
Ambienti di sviluppo, test e staging: aumentare progressivamente la fedeltà alla produzione
Gli ambienti intermedi consentono di verificare il software prima del rilascio agli utenti finali.
Development, test, staging e production possono essere configurati con livelli progressivamente maggiori di somiglianza rispetto alle condizioni operative reali.
Lo staging è particolarmente utile quando replica configurazioni, integrazioni e dipendenze della produzione con sufficiente fedeltà da rendere significativi i test finali.
Containerizzazione e Infrastructure as Code hanno contribuito a ridurre alcune differenze tra ambienti, rendendo una parte della configurazione riproducibile attraverso definizioni versionate.
Rimane comunque importante verificare quali differenze esistano tra staging e produzione, soprattutto quando incidono su performance, sicurezza o integrazioni esterne.
Release engineering: gestire il rischio associato al deployment
Il rilascio del software comprende attività tecniche e organizzative attraverso cui una nuova versione viene resa disponibile in produzione.
Strategie come rolling update, blue-green deployment, canary release e feature flag permettono di modulare il livello di esposizione di una nuova versione e, in alcuni contesti, di ridurre l’impatto di eventuali problemi.
Con un canary release, per esempio, la nuova versione può essere inizialmente distribuita a una parte limitata del traffico; attraverso le feature flag, invece, deploy tecnico e disponibilità della funzionalità possono essere gestiti separatamente.
La scelta della strategia dipende dalla criticità del sistema, dall’infrastruttura disponibile e dalla capacità di monitoring.
Il deployment viene così trattato non soltanto come un passaggio tecnico, ma come una parte della gestione del rischio operativo.
Observability: utilizzare la produzione come fonte di feedback
Il rilascio rappresenta l’inizio della fase in cui il sistema viene osservato in condizioni reali.
Logs, metriche, traces ed error tracking permettono di analizzare il comportamento tecnico dell’applicazione, mentre indicatori di business e di utilizzo aiutano a comprendere se le funzionalità vengano utilizzate come previsto.
L’observability supporta naturalmente la gestione degli incident, ma può anche produrre informazioni utili per le successive iterazioni di prodotto.
Un aumento degli errori su un determinato flusso può richiedere un intervento tecnico, mentre un utilizzo inferiore alle attese può suggerire approfondimenti sul design, sull’esperienza utente o sulla validità del requisito iniziale.
In questo senso, produzione e discovery non sono necessariamente due estremi separati del processo: le informazioni raccolte in esercizio possono contribuire alla definizione del lavoro futuro.
Reliability engineering: rendere misurabili disponibilità e prestazioni
Per le applicazioni più critiche può essere utile tradurre requisiti generici di affidabilità in indicatori quantitativi.
Service Level Indicator e Service Level Objective permettono di definire metriche e target relativi, per esempio, a disponibilità, latenza o tasso di errore.
La scelta del livello di servizio ha conseguenze dirette sulle decisioni architetturali e sui costi.
Un sistema progettato per disponibilità molto elevate può richiedere ridondanza, failover, disaster recovery e processi operativi più complessi rispetto a un’applicazione che può tollerare finestre di indisponibilità.
Definire questi obiettivi consente quindi di allineare il livello di affidabilità alle effettive necessità del business.
Maintenance ed evoluzione: gestire il software lungo il suo ciclo di vita
Dopo il primo rilascio un software enterprise continua generalmente a evolvere.
Nuove esigenze di business, aggiornamenti delle piattaforme, cambiamenti normativi, vulnerabilità e obsolescenza delle dipendenze possono richiedere interventi anche molti anni dopo il go-live.
La manutenzione comprende quindi bug fixing, aggiornamenti, miglioramenti e sviluppo di nuove funzionalità.
Per questo, nella valutazione delle decisioni progettuali, può essere utile considerare il total cost of ownership oltre al solo costo della prima implementazione.
Una soluzione più semplice da realizzare inizialmente può richiedere maggiore manutenzione nel tempo, mentre un investimento iniziale più elevato può risultare sostenibile se riduce i costi evolutivi. La relazione dipende dal tipo di sistema e dalla durata prevista del suo ciclo di vita.
Technical debt: gestire consapevolmente i compromessi tecnici
Il debito tecnico rappresenta una componente comune dell’evoluzione del software.
Decisioni temporanee, parti di codice che richiedono refactoring, dipendenze obsolete o soluzioni introdotte per rispettare una determinata scadenza possono accumularsi nel tempo.
Non tutto il debito tecnico ha necessariamente lo stesso impatto e non ogni elemento richiede una correzione immediata.
Può essere utile valutarlo in relazione a rischio, frequenza delle modifiche, costo di manutenzione e importanza della componente interessata.
In questo modo il refactoring può essere pianificato sulla base delle priorità tecniche e di business, evitando sia di ignorare completamente il problema sia di perseguire una perfezione tecnica che non produrrebbe un beneficio proporzionato.
Platform engineering: standardizzare le attività ricorrenti di delivery
Nelle organizzazioni che gestiscono molti team software, il platform engineering sta assumendo un ruolo crescente nella standardizzazione delle attività comuni.
Internal Developer Platform, template applicativi, pipeline condivise e golden path possono ridurre la necessità che ogni team configuri autonomamente build, deployment, monitoring e controlli di sicurezza.
L’obiettivo è generalmente fornire percorsi predefiniti per i casi più comuni, mantenendo al tempo stesso la possibilità di adottare soluzioni differenti quando i requisiti lo richiedono.
Questo approccio può ridurre la duplicazione del lavoro infrastrutturale e rendere più uniforme l’applicazione di policy organizzative.
AI-assisted SDLC: integrare nuovi strumenti nei processi esistenti
Gli strumenti di intelligenza artificiale generativa vengono utilizzati sempre più frequentemente durante diverse attività del Software Development Life Cycle.
Possono supportare la formalizzazione iniziale dei requisiti, la prototipazione, la produzione di codice e test, la documentazione o l’analisi di log e incident.
Il loro impatto dipende tuttavia dal contesto, dal tipo di attività e dal livello di supervisione adottato.
Quando la produzione di una prima soluzione viene accelerata, una quota maggiore del lavoro può spostarsi sulla verifica dell’output rispetto a sicurezza, correttezza e coerenza architetturale.
Per questo gli strumenti AI possono essere integrati nelle stesse pratiche di review, testing e governance applicate agli altri componenti del processo di sviluppo.
Ruoli e responsabilità: collaborazione lungo tutto il ciclo di delivery
Un progetto software enterprise coinvolge normalmente professionalità differenti.
Business Analyst e Product Owner partecipano alla definizione e prioritizzazione delle esigenze; Software Architect e Tech Lead lavorano sulle decisioni tecniche; Developer implementano le funzionalità; QA e Quality Engineer supportano le attività di verifica; Security Specialist intervengono sugli aspetti di sicurezza; DevOps, Platform Engineer e SRE contribuiscono alla pipeline, all’infrastruttura e all’affidabilità operativa.
A seconda del progetto possono inoltre essere coinvolti UI/UX Designer, Data Engineer, Data Analyst e specialisti del dominio applicativo.
Nei modelli di delivery contemporanei questi ruoli tendono a collaborare lungo più fasi del ciclo anziché intervenire esclusivamente in momenti separati.
Il livello di sovrapposizione varia in funzione della dimensione del progetto, della struttura organizzativa e delle competenze presenti all’interno del team.
Dal progetto al ciclo di evoluzione del prodotto
Per molte applicazioni enterprise il go-live rappresenta meno una conclusione e più il passaggio a una fase diversa del ciclo di vita.
Una volta utilizzato in condizioni reali, il software produce informazioni su performance, comportamento degli utenti e capacità di rispondere agli obiettivi iniziali, rendendo possibili ulteriori decisioni evolutive.
In questo contesto, il rispetto di tempi e budget rimane una dimensione importante della gestione progettuale, ma può essere affiancato da indicatori relativi all’adozione, all’affidabilità, alla qualità del servizio e al valore prodotto dal sistema.
La distinzione tra progetto e prodotto diventa quindi meno netta quando l’applicazione è destinata a evolvere attraverso release successive.
Dall’idea alla produzione: un lifecycle basato su iterazione e feedback
La realizzazione di software enterprise nel 2026 comprende quindi attività che vanno dall’analisi iniziale alla gestione del sistema in produzione e alla sua successiva evoluzione.
Discovery e requirements engineering permettono di definire obiettivi e vincoli; l’architettura organizza componenti e responsabilità; sviluppo, testing e security contribuiscono alla costruzione del prodotto; CI/CD e release engineering supportano la distribuzione; observability e reliability engineering consentono di valutarne il comportamento operativo.
Queste attività possono essere rappresentate come fasi distinte, ma nella pratica tendono a essere collegate attraverso feedback continui.
Un problema osservato in produzione può portare a una revisione architetturale, l’utilizzo reale di una funzionalità può modificare il backlog e una nuova vulnerabilità può richiedere aggiornamenti nella pipeline o nelle dipendenze.
Il ciclo di sviluppo software enterprise può quindi essere letto come un processo iterativo nel quale tecnologia, requisiti e condizioni operative evolvono insieme.
In questa prospettiva, il rilascio non rappresenta necessariamente il punto finale del progetto, ma uno dei momenti attraverso cui verificare se il sistema continui a rispondere alle esigenze per cui è stato realizzato e se possa essere mantenuto ed evoluto con livelli di qualità, affidabilità e costo coerenti con gli obiettivi dell’organizzazione.
Fonti citate:
- National Institute of Standards and Technology. (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218.
- National Institute of Standards and Technology. (2025). Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities. Initial Public Draft, NIST Special Publication 800-218 Rev. 1.
- National Institute of Standards and Technology. (2026). Secure Software Development, Security, and Operations (DevSecOps) Practices. National Cybersecurity Center of Excellence.
- National Institute of Standards and Technology. (2026). Secure Software Development Framework Update and DevSecOps Project. National Institute of Standards and Technology.
- National Institute of Standards and Technology. (2024). Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile. NIST Special Publication 800-218A.
Autore: Martina Pegoraro
