Il modello a spirale nello sviluppo software è la risposta che Barry Boehm diede negli anni Ottanta a un problema che fa ancora fallire progetti nel 2026: i team vincolano l’intero budget a un piano prima di sapere quali parti di quel piano sono sbagliate. Invece di procedere per fasi rigide, un progetto a spirale ripercorre più volte le stesse quattro attività e, in ogni ciclo, concentra lo sforzo su ciò che ha più probabilità di farlo fallire.
Per questo il modello a spirale si adatta naturalmente ai progetti in cui un’ipotesi iniziale sbagliata costa cara: sostituzione di core banking, sistemi clinici, piattaforme logistiche, software per aerospazio e difesa e altre forme di sviluppo di software enterprise su misura in cui un rischio di integrazione, prestazioni o conformità può vanificare un anno di lavoro. È anche il modello più spesso frainteso, perché il celebre diagramma sembra un processo da seguire e non un modo per decidere il passo successivo.
Questa guida spiega il modello a spirale in modo semplice: da dove viene, come leggere il diagramma, che cosa succede in ogni quadrante, le milestone che impediscono alla spirale di girare all’infinito, un esempio completo, i veri vantaggi e svantaggi e il confronto con il modello a cascata, il modello a V e l’agile. L’ultima sezione mostra come applichiamo la logica della spirale ai progetti moderni, senza il suo storico peso documentale.
Che cos’è il modello a spirale nello sviluppo software?
Il modello a spirale nello sviluppo software è un modello di ciclo di vita iterativo e guidato dal rischio in cui un progetto ripercorre quattro attività — fissare gli obiettivi, risolvere i rischi, costruire e testare, pianificare il ciclo successivo — e ogni ciclo produce una versione più completa del sistema. L’idea chiave: è il rischio, non una sequenza predefinita, a stabilire quanto di ogni attività fare e quando.
Ogni giro della spirale si chiama ciclo, loop o iterazione. I primi cicli sono piccoli ed economici: un concetto operativo, uno studio di fattibilità, un prototipo usa e getta. I cicli successivi sono più ampi e somigliano allo sviluppo e al rilascio tradizionali. La distanza dal centro della spirale rappresenta il costo cumulato: il modello rende quindi visibile che ogni ciclo in più costa denaro e deve guadagnarsi il proprio posto.
Da dove viene il modello a spirale
Barry Boehm, allora in TRW, descrisse per la prima volta il modello nel 1986 nell’articolo A Spiral Model of Software Development and Enhancement e ne pubblicò la versione più nota su IEEE Computer nel maggio 1988. Il suo esempio era il TRW Software Productivity System, un programma interno di strumenti i cui requisiti erano troppo incerti per un unico passaggio a cascata. Nel 2000 Boehm formalizzò il modello in un rapporto per il Software Engineering Institute della Carnegie Mellon e nel 2014 fu coautore dell’Incremental Commitment Spiral Model, l’evoluzione moderna dell’idea.
La spirale ha influenzato anche gli acquisti pubblici. Nel 2000 il Dipartimento della Difesa degli Stati Uniti adottò l’acquisizione evolutiva con sviluppo a spirale come approccio preferito per i grandi sistemi, e Boehm scrisse linee guida per questo utilizzo. Questa eredità spiega perché il modello sia ancora diffuso in aerospazio, difesa, pubblica amministrazione e altri programmi ad alta posta in gioco.
Perché il modello a spirale è un metamodello
Il modello a spirale è un metamodello perché può contenere gli altri modelli di processo invece di sostituirli. Se il rischio principale di un ciclo sono esigenze degli utenti poco chiare, quel ciclo si comporta come una prototipazione evolutiva. Se requisiti e tecnologia sono ben compresi, un ciclo può svolgersi come una breve cascata. Se il rischio è un’integrazione tardiva, il ciclo consegna un incremento. La spirale è il quadro decisionale; il modello usato in ogni ciclo si sceglie in base al rischio.
Come si legge il diagramma del modello a spirale?
Il diagramma del modello a spirale si legge dal centro verso l’esterno: la spirale parte dall’origine, attraversa quattro quadranti in ogni ciclo e ogni ciclo completato termina con una revisione e un impegno sul successivo. Il raggio indica il costo cumulato; l’angolo indica l’avanzamento nel ciclo corrente.
La maggior parte dei diagrammi online omette gli elementi che rendono utile la spirale, quindi conviene sapere che cosa significa ogni elemento visivo:
| Elemento del diagramma | Significato | Implicazione pratica |
|---|---|---|
| Distanza dal centro | Costo cumulato finora | I cicli esterni costano molto; l’apprendimento rischioso va fatto nei cicli interni |
| Posizione angolare | Avanzamento nel ciclo corrente | Ogni ciclo deve attraversare tutti e quattro i quadranti, anche brevemente |
| Attraversamento dell’asse orizzontale | Punto di revisione e impegno | Gli stakeholder decidono se proseguire, cambiare rotta o fermarsi |
| Prototipi nel quadrante 2 | Artefatti di riduzione del rischio | Costruiti per rispondere a una domanda, non per essere rilasciati |
| Ciclo più esterno | Progettazione di dettaglio, codifica, test, rilascio | Somiglia alla delivery tradizionale una volta eliminati i rischi |
Quali sono le quattro fasi del modello a spirale?
Le quattro fasi del modello a spirale sono: determinare obiettivi, alternative e vincoli; identificare e risolvere i rischi; sviluppare e testare il prodotto del livello successivo; pianificare l’iterazione successiva. Ogni ciclo le attraversa tutte e quattro, ma il tempo dedicato a ciascuna dipende dai rischi di quel ciclo.
1. Determinare obiettivi, alternative e vincoli
Il primo quadrante definisce che cosa deve ottenere il ciclo e quali strade sono percorribili. Il team registra gli obiettivi per la parte di prodotto considerata (prestazioni, funzionalità, adattabilità), i progetti alternativi o le opzioni make-or-buy e i vincoli come budget, tempi, normative e interfacce con i sistemi esistenti. Obiettivi chiari rendono concreta l’analisi del rischio del quadrante successivo.
2. Identificare e risolvere i rischi
Il secondo quadrante è il cuore della spirale: il team valuta le alternative rispetto agli obiettivi, individua le principali fonti di rischio e investe lo sforzo appena sufficiente a ridurle. Le tecniche tipiche sono prototipi usa e getta, benchmark, simulazioni, interviste agli utenti, verifiche delle referenze dei fornitori e modelli analitici. Il risultato è una decisione: quale alternativa perseguire e quali rischi restano aperti.
3. Sviluppare e testare il prodotto del livello successivo
Il terzo quadrante costruisce la versione successiva del prodotto con l’approccio di sviluppo adatto al rischio residuo. Nei primi cicli può trattarsi di una specifica o di un’architettura; in quelli successivi di codice funzionante, integrato e testato. Poiché le grandi incognite sono state affrontate nel quadrante 2, questo lavoro poggia su ipotesi verificate anziché su supposizioni.
4. Valutare e pianificare l’iterazione successiva
Il quarto quadrante chiude il ciclo con una revisione dei risultati da parte di chi detiene budget e requisiti, seguita da un piano per il ciclo successivo. La revisione è un vero punto di impegno: gli stakeholder possono proseguire come previsto, cambiare gli obiettivi o fermare il progetto finché il costo cumulato è ancora basso. Fermarsi presto è un esito legittimo e spesso prezioso.
| Quadrante | Domanda chiave | Input tipici | Output tipici |
|---|---|---|---|
| 1. Obiettivi | Che cosa deve ottenere questo ciclo? | Obiettivi di business, esigenze degli stakeholder, revisione del ciclo precedente | Obiettivi, alternative, vincoli |
| 2. Analisi del rischio | Che cosa potrebbe farci fallire? | Alternative, vincoli, registro dei rischi | Prototipi, benchmark, approccio scelto |
| 3. Ingegneria | Siamo in grado di costruirlo? | Approccio scelto, ipotesi verificate | Specifica, progetto, codice, risultati dei test |
| 4. Valutazione | Dobbiamo proseguire? | Risultati, stime aggiornate, feedback degli stakeholder | Decisione go/no-go, piano del ciclo successivo |
Perché l’analisi del rischio è al centro della spirale?
L’analisi del rischio è al centro della spirale perché il modello la usa per decidere quanto fare di ogni attività: se fare di più riduce la probabilità di fallimento, lo si fa; altrimenti ci si ferma. Boehm la presentava come la risposta alla domanda «quanto basta?» per prototipazione, documentazione, test e pianificazione.
In pratica significa mantenere un registro dei rischi vivo, rivisto all’inizio e alla fine di ogni ciclo. Il registro qui sotto mostra il tipo di rischi seguiti da un tipico progetto enterprise a spirale e la tecnica usata per eliminarli:
| Rischio | Probabilità | Impatto | Tecnica di risoluzione | Eliminato nel ciclo |
|---|---|---|---|---|
| Gli utenti rifiutano il nuovo flusso di lavoro | Media | Alto | Prototipo cliccabile testato con 8–10 utenti | 1 |
| L’API dell’ERP legacy non regge il carico di picco | Alta | Alto | Test di carico su una copia di staging | 2 |
| Un fornitore terzo manca le scadenze | Media | Medio | Verifica delle referenze, milestone contrattuali, opzione di riserva | 2 |
| Un audit normativo rileva lacune di tracciabilità | Bassa | Alto | Matrice di tracciabilità rivista dalla compliance | 3 |
| Un ingegnere chiave lascia il progetto | Media | Medio | Pair programming, documentazione, condivisione delle conoscenze | Continuo |
Due abitudini rendono efficace il lavoro guidato dal rischio. Primo, valutare ogni rischio per probabilità e impatto, così che il team investa dove la perdita attesa è maggiore. Secondo, far sì che ogni prototipo risponda a una domanda di rischio precisa con un criterio superato/non superato: un prototipo senza domanda è solo sviluppo anticipato. La nostra guida al proof of concept nello sviluppo software spiega come progettare questi esperimenti.
Quali sono le milestone di ancoraggio e gli invarianti del modello a spirale?
Le milestone di ancoraggio sono tre punti di controllo — Life Cycle Objectives (LCO), Life Cycle Architecture (LCA) e Initial Operational Capability (IOC) — che Boehm aggiunse perché i progetti a spirale avanzassero verso un sistema finito invece di girare all’infinito. Sono la parte del modello che la maggior parte dei riassunti omette, e quella che lo rende governabile.
- Life Cycle Objectives (LCO) — gli stakeholder concordano che cosa deve fare il sistema e che esiste almeno un’architettura realizzabile.
- Life Cycle Architecture (LCA) — l’architettura è scelta, i suoi rischi principali sono risolti e il piano per costruirla è credibile.
- Initial Operational Capability (IOC) — il primo rilascio operativo è pronto, gli utenti sono formati e il sito è predisposto.
Nel rapporto Spiral Development: Experience, Principles, and Refinements del 2000, pubblicato dal Software Engineering Institute della Carnegie Mellon, Boehm elencò anche sei «invarianti» presenti in ogni vero progetto a spirale. Un processo che li ignora non è una spirale, anche se ne disegna una:
- Gli artefatti chiave — concetto operativo, requisiti, piani, progetto e codice — sono definiti in parallelo, non uno dopo l’altro.
- Ogni ciclo copre obiettivi, vincoli, alternative, rischi, revisione e impegno a proseguire.
- Il livello di sforzo su ogni attività è determinato dal rischio.
- Il livello di dettaglio di ogni artefatto è determinato dal rischio.
- Il progetto usa le tre milestone di ancoraggio (LCO, LCA, IOC).
- Il progetto considera l’intero sistema e il suo ciclo di vita, non solo lo sviluppo iniziale del software.
Esempio di modello a spirale: come si presenta un progetto in quattro cicli?
Un esempio rende concreti i quadranti astratti. Consideriamo un gruppo ospedaliero regionale che sostituisce il software di distribuzione dei farmaci: deve integrarsi con la cartella clinica elettronica esistente, funzionare su armadi di distribuzione automatizzati e superare una verifica normativa. I rischi principali sono l’usabilità clinica, l’integrazione con la cartella clinica e l’auditabilità.
| Ciclo | Obiettivo | Rischio principale affrontato | Lavoro di riduzione del rischio | Esito |
|---|---|---|---|---|
| 1 (4 settimane) | Confermare il concetto con infermieri e farmacisti | Il personale clinico rifiuta il flusso di lavoro | Prototipi cartacei e cliccabili, osservazione in reparto | LCO raggiunto; ambito ridotto del 20% |
| 2 (6 settimane) | Dimostrare l’architettura di integrazione | L’interfaccia della cartella clinica non rispetta i tempi di risposta | Spike HL7/FHIR, test di carico su un’istanza di staging | LCA raggiunto; aggiunto un message broker |
| 3 (12 settimane) | Costruire i moduli di distribuzione e audit | Lacune di tracciabilità per l’autorità | Matrice di tracciabilità, revisione indipendente dei test | Build pronta per il pilota in un reparto |
| 4 (10 settimane) | Pilota e rollout nel primo ospedale | Disservizi operativi al go-live | Esercizio in parallelo, formazione, piano di rollback | IOC raggiunto; rollout nel gruppo pianificato |
Le durate dei cicli sono indicative, ma lo schema è tipico: i primi due cicli sono brevi ed economici e cambiano sensibilmente il piano prima che si spenda la maggior parte del budget. Se il team avesse scoperto il problema di prestazioni della cartella clinica al nono mese di un progetto a cascata, la correzione avrebbe richiesto una riprogettazione sotto pressione. Per le specificità dell’integrazione in sanità, consulti la nostra guida all’integrazione EHR.
Quali sono i vantaggi e gli svantaggi del modello a spirale?
Il principale vantaggio del modello a spirale è far emergere e ridurre i rischi maggiori prima che si spenda la maggior parte del budget; il principale svantaggio è la dipendenza da persone esperte che valutino quei rischi e il lavoro di gestione aggiuntivo. Se il compromesso convenga dipende da quanto costerebbe un fallimento.
Vantaggi del modello a spirale
- Riduzione precoce del rischio. I rischi tecnici, di usabilità e di integrazione si verificano nei cicli meno costosi.
- Requisiti flessibili. Requisiti nuovi o modificati possono entrare all’inizio di ogni ciclo.
- Punti di arresto integrati. Ogni ciclo termina con una decisione go/no-go, così i progetti destinati a fallire si fermano presto.
- Stime sempre migliori. Ogni ciclo sostituisce ipotesi con dati e migliora le previsioni di costi e tempi.
- Forte coinvolgimento degli stakeholder. Utenti e sponsor esaminano artefatti reali a ogni ciclo.
- Adatto a sistemi completi. Hardware, software, esercizio e formazione si pianificano negli stessi cicli.
Svantaggi del modello a spirale
- Richiede competenza sul rischio. Senza un’analisi del rischio solida, i cicli diventano prototipazione senza fine.
- Carico di gestione. Revisioni, registri dei rischi e piani per ogni ciclo richiedono tempo.
- Prezzo fisso difficile. Costo totale e durata non sono noti all’inizio, il che complica i contratti a corpo.
- Rischio di ciclo infinito. Senza milestone di ancoraggio, i team continuano a rifinire invece di rilasciare.
- Eccessivo per progetti piccoli. Per lavori a basso rischio e ben compresi, il formalismo costa più di quanto fa risparmiare.
| Fattore | Giudizio sul modello a spirale |
|---|---|
| Dimensione e costo del progetto | Ideale per programmi grandi e costosi |
| Chiarezza dei requisiti | Forte quando i requisiti sono poco chiari o in evoluzione |
| Livello di rischio | Forte quando un fallimento è costoso o pericoloso |
| Prevedibilità del budget | Debole all’inizio, migliora ciclo dopo ciclo |
| Maturità del team richiesta | Alta: architetti senior e manager attenti al rischio |
| Velocità per piccole app | Debole: l’agile o un semplice modello iterativo è più rapido |
Conta anche l’aspetto contrattuale. Poiché i progetti a spirale scoprono il proprio ambito reale strada facendo, si adattano meglio a contratti time and materials o per fasi che a un unico prezzo fisso; il nostro confronto time and materials vs prezzo fisso vs team dedicato illustra le opzioni.
Quando conviene usare il modello a spirale?
Usi il modello a spirale quando un progetto è grande, costoso da sbagliare e pieno di incognite che si possono indagare prima della costruzione su larga scala. Se risponde sì ad almeno tre delle domande seguenti, i cicli di rischio in stile spirale probabilmente si ripagheranno:
- Il budget è così ampio che un progetto fallito danneggerebbe seriamente l’azienda?
- I requisiti sono poco chiari, contesi o destinati a cambiare in modo significativo?
- Il progetto dipende da tecnologie nuove o non collaudate, o da un’integrazione fragile con sistemi legacy?
- Un comportamento errato del sistema avrebbe conseguenze di sicurezza, finanziarie o normative?
- Il sistema resterà in uso per molti anni, così che esercizio e manutenzione vanno pianificati dall’inizio?
- Gli sponsor hanno bisogno di punti decisionali espliciti prima di liberare ogni tranche di budget?
Casi tipici sono i programmi aerospaziali e della difesa, le piattaforme di core banking e di pagamento, il software clinico e per dispositivi medici, le grandi sostituzioni di sistemi logistici ed ERP e i nuovi prodotti basati su hardware o componenti di IA non collaudati.
Quando il modello a spirale non è la scelta giusta
Il modello a spirale non è la scelta giusta per progetti piccoli, a basso rischio o ben compresi, per team senza figure senior in grado di condurre l’analisi del rischio, né per lavori da rilasciare in poche settimane. Un sito di marketing, un’app mobile standard con requisiti noti o un MVP pensato per ottenere rapidamente riscontri dal mercato sono serviti meglio da Scrum, Kanban o da un semplice modello iterativo.
In che cosa il modello a spirale differisce da cascata, modello a V e agile?
Il modello a spirale si distingue da cascata e modello a V perché ripete le proprie fasi in cicli guidati dal rischio, e dall’agile perché organizza questi cicli attorno a un’analisi esplicita del rischio e a punti di impegno formali anziché a sprint di durata fissa. La tabella riassume le differenze pratiche.
| Aspetto | Spirale | Cascata | Modello a V | Agile (Scrum) |
|---|---|---|---|---|
| Motore | Rischio | Documenti e fasi | Verifica e validazione | Valore per il cliente e feedback |
| Iterazioni | Cicli di durata variabile | Nessuna (un solo passaggio) | Nessuna (un solo passaggio) | Sprint fissi di 1–4 settimane |
| Modifiche ai requisiti | All’inizio di ogni ciclo | Costose dopo l’approvazione | Costose dopo l’approvazione | A ogni sprint |
| Gestione del rischio | Esplicita, a ogni ciclo | Implicita, tardiva | Tramite la pianificazione dei test | Implicita, tramite feedback brevi |
| Documentazione | Quanta ne richiede il rischio | Pesante | Pesante | Leggera |
| Ideale per | Grandi sistemi ad alto rischio | Ambito stabile e ben definito | Sistemi critici e regolamentati | Prodotti con esigenze in evoluzione |
I modelli puri sono rari nella pratica. Il rapporto PMI Pulse of the Profession 2024 rileva che la quota di progetti gestiti con approcci ibridi è passata dal 20% nel 2020 al 31% nel 2023, e l’ibrido spirale-agile è uno degli schemi più frequenti che osserviamo nei programmi enterprise. Per una panoramica più ampia, legga le nostre guide alle metodologie di sviluppo software e allo sviluppo software agile.
L’Incremental Commitment Spiral Model (ICSM)
L’Incremental Commitment Spiral Model è l’evoluzione moderna della spirale firmata da Boehm, pubblicata nel 2014 con Jo Ann Lane, Supannika Koolmanojwong e Richard Turner. Mantiene i cicli guidati dal rischio ma organizza ciascuno attorno a quattro principi: guida basata sul valore per gli stakeholder, impegno e responsabilità incrementali, ingegneria multidisciplinare concorrente e decisioni basate su evidenze e rischio. Nell’ICSM un progetto avanza solo quando le prove della sua fattibilità sono abbastanza solide da indurre gli stakeholder a impegnare altre risorse.
Come applicare il modello a spirale nel 2026?
Il modo più efficace di applicare il modello a spirale nel 2026 è mantenerne la disciplina del rischio e i punti decisionali, svolgendo la realizzazione di ogni ciclo con le moderne pratiche agili e DevOps. Questi sette passi descrivono come lavoriamo sui progetti ad alto rischio:
- Partire da un ciclo di discovery orientato al rischio. Mappare obiettivi, vincoli e i dieci rischi principali prima di scrivere codice di produzione; la nostra guida alla fase di discovery mostra che cosa produrre.
- Trasformare i rischi in esperimenti. Per ogni rischio principale, definire uno spike, un prototipo o un benchmark con un criterio superato/non superato chiaro e un time box.
- Limitare nel tempo ogni ciclo. Tenere i primi cicli entro 2–6 settimane e quelli successivi entro un trimestre, perché la spirale non vada alla deriva.
- Usare le milestone di ancoraggio come cancelli di finanziamento. Liberare il budget per la realizzazione completa solo dopo l’LCA, quando i rischi architetturali sono risolti.
- Eseguire sprint all’interno dei cicli. Usare Scrum o Kanban per il quadrante di ingegneria, con CI/CD, test automatizzati e feature flag.
- Mantenere vivo il registro dei rischi. Rivederlo a ogni revisione di ciclo, chiudere i rischi con evidenze e aggiungere quelli nuovi appena emergono.
- Documentare in base al rischio, non al modello. Scrivere specifiche dettagliate dove gli errori costano cari — interfacce, sicurezza, funzioni regolamentate — e restare leggeri altrove.
La spirale si integra inoltre in modo naturale nel ciclo di vita dello sviluppo software: non sostituisce requisiti, progettazione, realizzazione, test e rilascio, ma decide quante volte e con quale livello di dettaglio li percorrete.
FAQ
Che cos’è il modello a spirale nello sviluppo software?
Il modello a spirale nello sviluppo software è un modello di ciclo di vita iterativo e guidato dal rischio, presentato da Barry Boehm nel 1986. Un progetto attraversa cicli ripetuti: ogni ciclo fissa gli obiettivi, analizza e riduce i rischi principali, costruisce e testa una versione del prodotto e pianifica il ciclo successivo. È il rischio, non una sequenza fissa di fasi, a decidere che cosa fa il team dopo.
Quali sono le quattro fasi del modello a spirale?
Ogni ciclo del modello a spirale ha quattro quadranti: determinare obiettivi, alternative e vincoli; identificare e risolvere i rischi, spesso con prototipi o simulazioni; sviluppare e testare il prodotto del livello successivo; valutare i risultati e pianificare l’iterazione successiva. Gli stakeholder si impegnano sul ciclo successivo solo dopo la revisione.
Perché il modello a spirale è chiamato metamodello?
Il modello a spirale è chiamato metamodello perché può contenere altri modelli di processo. In base ai rischi di un ciclo, il team può condurlo come una fase a cascata, un prototipo evolutivo o un rilascio incrementale. La spirale decide quale approccio si adatta, invece di imporne uno solo.
Qual è il principale svantaggio del modello a spirale?
Il principale svantaggio del modello a spirale è la dipendenza da un’analisi del rischio competente. Ogni ciclo richiede persone capaci di individuare e dimensionare i rischi tecnici, di pianificazione e di business; senza di loro il modello diventa una costosa serie di prototipi senza fine. Aggiunge inoltre lavoro di gestione e documentazione, che lo rende poco adatto a progetti piccoli o a basso rischio.
Il modello a spirale è agile?
Non esattamente. Il modello a spirale è iterativo e accetta requisiti che cambiano, come l’agile, ma è guidato da un’analisi esplicita del rischio, da revisioni formali e da punti di impegno degli stakeholder anziché da sprint brevi di durata fissa. Nel 2026 molti team combinano i due: cicli di rischio e milestone in stile spirale a livello di programma, sprint Scrum o Kanban all’interno di ogni ciclo.
Chi ha creato il modello a spirale dello sviluppo software?
Il modello a spirale dello sviluppo software è stato creato da Barry Boehm. Lo descrisse per la prima volta nel 1986 nell’articolo A Spiral Model of Software Development and Enhancement e pubblicò la versione più citata su IEEE Computer nel maggio 1988, usando come esempio il TRW Software Productivity System. In seguito lo evolse nell’Incremental Commitment Spiral Model.
Pubblicato il 24 ottobre 2026. Fonti: B. Boehm, «A Spiral Model of Software Development and Enhancement», IEEE Computer, maggio 1988; B. Boehm, Spiral Development: Experience, Principles, and Refinements, CMU/SEI-2000-SR-008; B. Boehm e W. Hansen, The Spiral Model as a Tool for Evolutionary Acquisition; B. Boehm, J. A. Lane, S. Koolmanojwong e R. Turner, The Incremental Commitment Spiral Model, Addison-Wesley, 2014; PMI, Pulse of the Profession 2024. L’esempio ospedaliero e le durate dei cicli sono indicativi.
