# sfeir-sdlc-pdlc-articulation-2026-07-22

## Veille

Analisi SFEIR (voce di una società di consulenza, "la lettura di un ingegnere") che articola due framework troppo spesso confusi: lo **SDLC** (Software Development Life Cycle — *costruire il software in modo corretto e affidabile*) e il **PDLC** (Product Development Life Cycle — *costruire il prodotto giusto e avere successo sul mercato*). Tesi centrale: i due cicli non sono concorrenti ma **annidati** — lo SDLC è il sottoinsieme del PDLC **ospitato nella sua fase di sviluppo**; quando un team di prodotto raggiunge la fase di "build", al suo interno gira un ciclo SDLC completo (progettazione → costruzione → test → revisione → deployment). Lo SDLC è standardizzato (**ISO/IEC/IEEE 12207**, edizioni 2017 e 2026), con la sua genealogia di modelli (Waterfall 1970, modello a V, iterativo/spirale, **Agile 2001**, **DevOps/DevSecOps 2009+**) e le sue metriche **DORA** (throughput, stabilità, MTTR, change failure rate). Il PDLC, essendo il ciclo ombrello, si estende dall'**ideazione/discovery** al **ritiro dal mercato** (da non confondere con il **PLC** di marketing di Theodore Levitt, 1965, che descrive una *curva commerciale*, non un *lavoro organizzato*: "il PLC osserva una curva; il PDLC organizza il lavoro"). **Punto di svolta**: lo SDLC affronta nativamente **un solo rischio su quattro** — tramite il framework dei **"Four Big Risks" di Marty Cagan** (Valore → PM, Usabilità → Designer, Fattibilità → Lead Engineer, Sostenibilità economica → PM) — un'organizzazione eccellente sullo SDLC ma cieca sul PDLC produce "software che nessuno vuole" — la **"feature factory"** di John Cutler (successo misurato sull'output, non sull'outcome). **Perché l'IA cambia tutto**: l'IA generativa **comprime lo SDLC** (dati Google/JetBrains, maggio 2026: **~85% degli sviluppatori** usa regolarmente agenti di coding, **~41% del nuovo codice** è generato dall'IA; l'implementazione passa da settimane a ore), quindi il **collo di bottiglia si sposta a monte** — decidere *cosa* costruire (Marty Cagan, aprile 2026: "quando il costo della delivery crolla, il collo di bottiglia si sposta sulla discovery"). Conseguenze: DORA 2025 (~5.000 professionisti, 90% di adozione dell'IA) mostra una **correlazione positiva con il throughput ma negativa con la stabilità** (più funzionalità non validate significa più instabilità e rework); Andrew Ng (AI Startup School, luglio 2025) segnala team che **invertono il rapporto "1 PM per 4 ingegneri" in "2 PM per 1 ingegnere"**; e con lo **spec-driven development**, il confine PDLC/SDLC diventa **poroso** (la specifica di prodotto diventa direttamente eseguibile dagli agenti). **Cosa dovrebbe trarne un CIO**: uno SDLC potenziato diventa uno **standard di mercato, non un elemento di differenziazione** — bisogna strumentare la giunzione con il prodotto, esigere **specifiche eseguibili** come input, incrociare le metriche tecniche con le metriche di outcome, e **rifiutare** il ruolo di "fornitore di feature". Per un CPO: lo spostamento del collo di bottiglia verso la discovery è al tempo stesso una **promozione** (il giudizio di prodotto torna a essere una risorsa scarsa) e un **avviso ad agire** (industrializzare la discovery per raggiungere la parità con lo SDLC). Il framework interno di SFEIR ("Progettare e costruire nell'era agentica" — **ciclo a 11 fasi** + **Software Factory 10x**) si posiziona come la risposta sul lato ingegneristico, con l'**articolazione dei due cicli** come prossima leva. Conclusione: "man mano che il codice diventa una commodity, il margine si sposta verso il giudizio di prodotto e la governance."

## Titre Article

SDLC vs PDLC : quelle différence, et pourquoi l'IA change tout

## Date

2026-07-22

## URL

https://www.sfeir.com/articles/sdlc-vs-pdlc-difference-articulation/

## Keywords

SDLC, Software Development Life Cycle, PDLC, Product Development Life Cycle, ciclo di vita del software, ciclo di vita del prodotto, PLC, ciclo di vita del prodotto, Theodore Levitt, ISO/IEC/IEEE 12207, 12207, Waterfall, modello a V, iterativo, spirale, Agile, DevOps, DevSecOps, CI/CD, DORA, metriche DORA, throughput, stabilità, MTTR, change failure rate, lead time, velocity, discovery, ideazione, product-market fit, adozione, retention, NPS, Marty Cagan, Four Big Risks, quattro grandi rischi, valore, usabilità, fattibilità, sostenibilità economica, Product Manager, CPO, product lead, Lead Engineer, designer, John Cutler, feature factory, output vs outcome, collo di bottiglia, spostamento del collo di bottiglia, a monte, cosa costruire, costo della delivery, IA generativa, agenti di coding, 85% degli sviluppatori, 41% del codice generato dall'IA, Google JetBrains, vibe coding, The New SDLC With Vibe Coding, Andrew Ng, rapporto PM-ingegneri, 2 PM per ingegnere, spec-driven development, specifica eseguibile, porosità PDLC SDLC, confine poroso, CIO, CIO, elemento di differenziazione, standard di mercato, giunzione prodotto-ingegneria, governance end-to-end, framework agentico SFEIR, ciclo a 11 fasi, Software Factory 10x, PM potenziato, discovery strumentata, prototipazione con agenti, annidamento dei cicli, sottoinsieme, giudizio di prodotto, commodity del codice

## Authors

SFEIR (voix éditoriale du cabinet)

## Ton

**Profilo**: pezzo di thought-leadership pedagogico-strategico di una società di consulenza (SFEIR), rivolto a CIO, CPO e leadership tecnica. Struttura canonica "chiarimento del vocabolario → articolazione → impatto dell'IA → raccomandazioni per ruolo → FAQ", con una **tabella comparativa** dimensione per dimensione (perimetro, finalità, domanda, attori, metriche, orizzonte, rischi) e una sezione FAQ che risolve confusioni frequenti ("il PDLC sostituisce lo SDLC?", "PDLC vs PLC?").

**Stile**: didattico e strutturato — espone prima definizioni standardizzate (con riferimento a ISO/IEC/IEEE 12207, modelli storici), poi si appoggia ad autorità riconosciute (Marty Cagan per i Four Big Risks e lo spostamento del collo di bottiglia, John Cutler per la feature factory, Andrew Ng per l'inversione del rapporto PM/ingegneri, DORA per i dati sulla stabilità). **Formule martellanti** ricorrenti: "il PLC osserva una curva; il PDLC organizza il lavoro"; "lo SDLC affronta nativamente un solo rischio su quattro"; "man mano che il codice diventa una commodity, il margine si sposta verso il giudizio di prodotto e la governance." Distingue **correlazione da causalità** (dati DORA 2025: "correlazioni, non causalità"). Si chiude su un **posizionamento di prodotto** deliberato del framework interno di SFEIR (ciclo a 11 fasi, Software Factory 10x), presentato come il mattone già consegnato a cui va ora aggiunta l'articolazione dei due cicli.

## Pense-betes

- **La distinzione in una frase.** **SDLC** = "costruire il software in modo **corretto e affidabile**" (domanda: *come spedirlo?*); **PDLC** = "costruire il prodotto **giusto**, avere successo sul mercato" (domanda: *cosa costruire, e perché?*). Lo SDLC è un **sottoinsieme** del PDLC, non il suo concorrente.
- **Annidamento, non sostituzione.** Lo SDLC è **ospitato nella fase di sviluppo** del PDLC. Quando il team di prodotto raggiunge la fase di "build", al suo interno gira un ciclo SDLC completo (progettazione → costruzione → test → revisione → deployment). Risposta diretta alla FAQ: "il PDLC non sostituisce lo SDLC, i due sono annidati."
- **Non confondere PDLC e PLC.** Il **PLC** (product life cycle, Theodore Levitt, HBR 1965 — introduzione/crescita/maturità/declino) descrive una **traiettoria commerciale** che orienta il marketing. Il **PDLC** descrive il **processo di progettazione e costruzione**. Formula: "il PLC osserva una **curva**; il PDLC organizza il **lavoro**."
- **Lo SDLC copre un solo rischio su quattro.** Tramite i **"Four Big Risks" di Marty Cagan**: **Valore** (PM — "verranno, lo sceglieranno?"), **Usabilità** (Designer — "sapranno usarlo?"), **Fattibilità** (Lead Engineer — "si può costruire?"), **Sostenibilità economica** (PM — "funziona per il business?"). Lo SDLC affronta nativamente solo la **fattibilità tecnica**. Eccellenza SDLC + cecità PDLC = "software che nessuno vuole" = **feature factory** di **John Cutler** (successo misurato sull'**output**, non sull'**outcome**).
- **Perché l'IA cambia tutto: la compressione dello SDLC.** **Dati Google/JetBrains, maggio 2026**: **~85% degli sviluppatori** usa regolarmente agenti di coding; **~41% del nuovo codice** è generato dall'IA. L'implementazione passa da **settimane a ore** — ma i requisiti, l'architettura e la verifica restano a **ritmo umano**.
- **Il collo di bottiglia si sposta a monte.** **Marty Cagan (aprile 2026)**: "quando il costo della delivery crolla, il collo di bottiglia si sposta sulla discovery — decidere **cosa** costruire." Ciò che diventa scarso non è più il codice, è il **giudizio di prodotto**.
- **Il segnale DORA 2025 (da leggere con attenzione).** Indagine Google Cloud (~5.000 professionisti, 90% di adozione dell'IA): correlazione **positiva con il throughput di delivery**, ma **negativa con la stabilità** (correlazioni, **non causalità**). Interpretazione: spedire **funzionalità non validate** più velocemente crea instabilità e rework — esattamente ciò che la disciplina del PDLC dovrebbe prevenire a monte.
- **L'inversione del rapporto.** **Andrew Ng (AI Startup School, luglio 2025)**: alcuni team propongono di invertire lo storico rapporto **"1 PM per 4 ingegneri"** fino a **"2 PM per 1 ingegnere"** — a seconda del contesto. Un segnale che il baricentro dello sforzo si sposta di nuovo verso la definizione del prodotto.
- **Il confine diventa poroso.** Con lo **spec-driven development**, l'artefatto di design del PDLC **alimenta direttamente** lo SDLC: "il confine tra i due cicli diventa poroso." La **specifica di prodotto diventa eseguibile** dagli agenti.
- **Cosa deve riconoscere un CIO.** Ottimizzare solo lo SDLC non basta più: uno SDLC potenziato diventa uno **standard di mercato, non un elemento di differenziazione**. Azioni: (1) **strumentare la giunzione** con il prodotto; (2) **esigere specifiche eseguibili** come input; (3) **incrociare** le metriche tecniche con le metriche di **outcome**; (4) **rifiutare** il ruolo di "fornitore di feature". Rischio nominato: un **PDLC artigianale di fronte a uno SDLC industrializzato** crea uno "squilibrio insostenibile".
- **Cosa deve riconoscere un CPO.** Lo spostamento del collo di bottiglia è al tempo stesso una **promozione** (il giudizio di prodotto torna a essere una risorsa scarsa) **e** un avviso ad agire: **equipaggiare la discovery** (prototipazione con agenti, validazione accelerata dei quattro rischi) per raggiungere la **parità di industrializzazione** con lo SDLC. "Il CPO detiene ormai il percorso critico dell'azienda."
- **Posizionamento interno di SFEIR.** Il framework "Progettare e costruire nell'era agentica" — **ciclo a 11 fasi** + **Software Factory 10x** — chiude il lato ingegneristico; la **prossima leva** è l'**articolazione dei due cicli** (PM potenziato, porosità PDLC/SDLC, governance end-to-end). Conclusione: "man mano che il codice diventa una **commodity**, il margine si sposta verso il **giudizio di prodotto e la governance**."
- **Correlati**: cluster **SDLC / ADLC / ciclo agentico** (BMAD-Method urbanistica AI agentica 2026-02-04; The New SDLC With Vibe Coding, Google maggio 2026; SFEIR "architetto nell'era dell'IA" 2026-07-15; ciclo a 11 fasi SFEIR); **DORA** (DORA 2026-04-21 ROI/curva a J, State of AI-assisted Software Development 2025); **feature factory / output vs outcome** (John Cutler); **spec-driven / Software Factory** (StrongDM software factory 2026-02-06; approccio spec-driven IA); **KDLC** (Ashish Singh, knowledge life cycle, 28 giugno 2026) e **compounding knowledge lifecycle** (Klaassen 2026-07-02) come framework di ciclo di vita affini.

## RésuméDe400mots

SFEIR chiarisce due framework spesso confusi. Lo **SDLC** (Software Development Life Cycle), standardizzato da **ISO/IEC/IEEE 12207** (2017, 2026), struttura la **produzione del software** — raccolta dei requisiti, progettazione, sviluppo, test/QA, deployment, manutenzione — con la sua genealogia di modelli (Waterfall 1970, modello a V, iterativo/spirale, **Agile** 2001, **DevOps/DevSecOps** 2009+) e le sue metriche **DORA** (throughput, stabilità, MTTR, change failure rate). Il suo scopo: "costruire il software in modo **corretto e affidabile**." Il **PDLC** (Product Development Life Cycle) è il **ciclo ombrello**: dall'ideazione/discovery al ritiro dal mercato, mira a "costruire il prodotto **giusto**." Da non confondere con il **PLC** di Theodore Levitt (1965), che descrive una **curva commerciale**; "il PLC osserva una curva, il PDLC organizza il lavoro."

**Articolazione**: i cicli sono **annidati** — lo SDLC è il sottoinsieme del PDLC ospitato nella sua **fase di sviluppo**. Punto critico tramite i **"Four Big Risks" di Marty Cagan** (Valore, Usabilità, Fattibilità, Sostenibilità economica): lo SDLC affronta nativamente solo la **fattibilità tecnica** — "un rischio su quattro". Un'organizzazione forte sullo SDLC ma cieca sul PDLC diventa la **"feature factory"** di **John Cutler**, che misura il successo sull'**output** piuttosto che sull'**outcome**.

**Perché l'IA cambia tutto**: l'IA generativa **comprime lo SDLC** (Google/JetBrains, maggio 2026: **~85%** degli sviluppatori usa agenti di coding, **~41%** del nuovo codice è generato dall'IA; l'implementazione passa da settimane a ore). Il **collo di bottiglia si sposta a monte** — decidere *cosa* costruire (**Cagan**, aprile 2026). Tre conseguenze: **DORA 2025** (~5.000 professionisti, 90% di adozione) mostra una correlazione **positiva con il throughput ma negativa con la stabilità** (correlazioni, non causalità) — più funzionalità non validate, più rework; **Andrew Ng** (luglio 2025) segnala l'inversione del rapporto **"1 PM / 4 ingegneri" in "2 PM / 1 ingegnere"**; e lo **spec-driven development** rende **poroso il confine PDLC/SDLC** (la specifica diventa eseguibile dagli agenti).

**Raccomandazioni.** Per il **CIO**: uno SDLC potenziato è ormai uno **standard di mercato, non un elemento di differenziazione** — strumentare la giunzione con il prodotto, esigere **specifiche eseguibili**, incrociare le metriche tecniche e di outcome, rifiutare il ruolo di "fornitore di feature"; un PDLC artigianale di fronte a uno SDLC industrializzato è uno "squilibrio insostenibile". Per il **CPO**: al tempo stesso una promozione **e** un avviso ad agire — **equipaggiare la discovery** per raggiungere la parità di industrializzazione. SFEIR posiziona il proprio framework interno (**ciclo a 11 fasi** + **Software Factory 10x**) come la risposta sul lato ingegneristico, con l'**articolazione dei due cicli** come prossima leva. Conclusione: "man mano che il codice diventa una commodity, il margine si sposta verso il giudizio di prodotto e la governance."

## GrapheDeConnaissance

- SDLC —fait_partie_de→ PDLC (METHODOLOGIE, 0.95)
- SDLC —est_instance_de→ ISO/IEC/IEEE 12207 (DOCUMENT, 0.9)
- PDLC —s_oppose_à→ PLC (product life cycle, Theodore Levitt 1965) : le PLC observe une courbe commerciale, le PDLC organise un travail de conception (AFFIRMATION, 0.85)
- SDLC —affirme_que→ le SDLC ne traite nativement qu'un risque sur quatre (la faisabilité technique) parmi les Four Big Risks de Cagan (AFFIRMATION, 0.9)
- Marty Cagan —a_créé→ Four Big Risks (CONCEPT, 0.92)
- Four Big Risks —s_applique_à→ répartition des responsabilités produit : Valeur/Viabilité (PM), Utilisabilité (Designer), Faisabilité (Lead Engineer) (AFFIRMATION, 0.9)
- John Cutler —a_créé→ feature factory (CONCEPT, 0.9)
- feature factory —observé_dans→ organisations fortes en SDLC mais aveugles au PDLC, qui mesurent le succès à l'output plutôt qu'à l'outcome (AFFIRMATION, 0.88)
- IA générative —réduit→ le coût et la durée du SDLC : implémentation de semaines à heures (AFFIRMATION, 0.9)
- Google JetBrains —mesure→ ~85 % des développeurs utilisent régulièrement des agents de code et ~41 % du nouveau code est généré par IA (mai 2026) (MESURE, 0.9)
- Marty Cagan —affirme_que→ quand le coût du delivery s'effondre, le goulot d'étranglement se déplace vers l'amont : décider quoi construire (avril 2026) (AFFIRMATION, 0.92)
- Rapport DORA 2025 —mesure→ adoption IA à 90 % corrélée positivement au débit de livraison mais négativement à la stabilité (corrélations, non causalités) (MESURE, 0.88)
- Andrew Ng —affirme_que→ certaines équipes proposent d'inverser le ratio historique de 1 PM pour 4 ingénieurs jusqu'à 2 PM par ingénieur (juil. 2025) (AFFIRMATION, 0.85)
- approche spec-driven —permet→ rendre poreuse la frontière PDLC/SDLC : la spécification produit devient directement exécutable par des agents (AFFIRMATION, 0.85)
- SFEIR —recommande→ une DSI doit instrumenter la jonction produit, exiger des spécifications exécutables et refuser le rôle de fournisseur de features (AFFIRMATION, 0.88)
- SFEIR —affirme_que→ à mesure que le code devient une commodité, la marge se déplace vers le jugement produit et la gouvernance (AFFIRMATION, 0.9)
- cycle SFEIR à 11 phases —résout→ le versant ingénierie (SDLC augmenté) ; le levier suivant est l'articulation SDLC/PDLC (AFFIRMATION, 0.82)

---
Canonical: https://www.thekb.eu/it/fiches/sfeir-sdlc-pdlc-articulation-2026-07-22/