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

## Veille

Análisis de SFEIR (voz de consultora, "la lectura de un ingeniero") que articula dos marcos demasiado a menudo confundidos: el **SDLC** (Software Development Life Cycle — *construir el software correcta y fiablemente*) y el **PDLC** (Product Development Life Cycle — *construir el producto correcto y triunfar en el mercado*). Tesis central: los dos ciclos no son competidores sino **anidados** — el SDLC es el subconjunto del PDLC **alojado bajo su fase de desarrollo**; cuando un equipo de producto llega a la etapa de "construcción", un ciclo SDLC completo (diseño → construcción → pruebas → revisión → despliegue) se ejecuta dentro de él. El SDLC está estandarizado (**ISO/IEC/IEEE 12207**, ediciones 2017 y 2026), con su linaje de modelos (Waterfall 1970, modelo en V, iterativo/espiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) y sus métricas **DORA** (throughput, estabilidad, MTTR, tasa de fallos de cambio). El PDLC, al ser el ciclo paraguas, se extiende desde la **ideación/discovery** hasta la **retirada del mercado** (no confundir con el **PLC** de marketing de Theodore Levitt, 1965, que describe una *curva comercial*, no un *trabajo organizado*: "el PLC observa una curva; el PDLC organiza el trabajo"). **Punto de inflexión**: el SDLC aborda nativamente **solo uno de cada cuatro riesgos** — vía el marco de **Marty Cagan «Four Big Risks»** (Valor → PM, Usabilidad → Diseñador, Viabilidad técnica → Lead Engineer, Viabilidad de negocio → PM) — una organización excelente en SDLC pero ciega al PDLC produce "software que nadie quiere" — la **"feature factory"** de John Cutler (el éxito medido por el output, no por el outcome). **Por qué la IA lo cambia todo**: la IA generativa **comprime el SDLC** (datos de Google/JetBrains, mayo de 2026: **~85% de los desarrolladores** usan regularmente agentes de codificación, **~41% del código nuevo** es generado por IA; la implementación pasa de semanas a horas), por lo que el **cuello de botella se desplaza aguas arriba** — decidir *qué* construir (Marty Cagan, abril de 2026: "cuando el coste de la entrega se desploma, el cuello de botella se traslada al discovery"). Consecuencias: DORA 2025 (~5.000 profesionales, 90% de adopción de IA) muestra una **correlación positiva con el throughput pero negativa con la estabilidad** (más funcionalidades no validadas implica inestabilidad y retrabajo); Andrew Ng (AI Startup School, julio de 2025) informa de equipos que **invierten la proporción "1 PM por 4 ingenieros" a "2 PM por 1 ingeniero"**; y con el **spec-driven development**, la frontera PDLC/SDLC se vuelve **porosa** (la especificación de producto se vuelve directamente ejecutable por agentes). **Lo que un CIO debe retener**: un SDLC aumentado se convierte en un **estándar de mercado, no en un diferenciador** — hay que instrumentar la unión con el producto, exigir **especificaciones ejecutables** como entrada, cruzar las métricas técnicas con las métricas de outcome, y **rechazar** el rol de "proveedor de funcionalidades". Para un CPO: el desplazamiento del cuello de botella hacia el discovery es a la vez una **promoción** (el juicio de producto vuelve a ser escaso) y un **aviso para actuar** (industrializar el discovery para alcanzar la paridad con el SDLC). El marco propio de SFEIR ("Diseñar y construir en la era agéntica" — **ciclo de 11 fases** + **Software Factory 10x**) se posiciona como la respuesta del lado de la ingeniería, con la **articulación de los dos ciclos** como la siguiente palanca. Conclusión: "a medida que el código se convierte en un commodity, el margen se desplaza hacia el juicio de producto y la gobernanza".

## 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 de vida del software, ciclo de vida del producto, PLC, ciclo de vida del producto, Theodore Levitt, ISO/IEC/IEEE 12207, 12207, Waterfall, modelo en V, iterativo, espiral, Agile, DevOps, DevSecOps, CI/CD, DORA, métricas DORA, throughput, estabilidad, MTTR, tasa de fallos de cambio, lead time, velocidad, discovery, ideación, product-market fit, adopción, retención, NPS, Marty Cagan, Four Big Risks, cuatro grandes riesgos, valor, usabilidad, viabilidad técnica, viabilidad de negocio, Product Manager, CPO, responsable de producto, Lead Engineer, diseñador, John Cutler, feature factory, output vs outcome, cuello de botella, desplazamiento del cuello de botella, aguas arriba, qué construir, coste de entrega, IA generativa, agentes de codificación, 85% de los desarrolladores, 41% del código generado por IA, Google JetBrains, vibe coding, The New SDLC With Vibe Coding, Andrew Ng, proporción PM-ingeniero, 2 PM por ingeniero, spec-driven development, especificación ejecutable, porosidad PDLC SDLC, frontera porosa, CIO, CIO, diferenciador, estándar de mercado, unión producto-ingeniería, gobernanza de extremo a extremo, marco agéntico de SFEIR, ciclo de 11 fases, Software Factory 10x, PM aumentado, discovery instrumentado, prototipado con agentes, anidamiento de ciclos, subconjunto, juicio de producto, commodity del código

## Authors

SFEIR (voix éditoriale du cabinet)

## Ton

**Perfil**: pieza de thought-leadership pedagógico-estratégica de una consultora (SFEIR), dirigida a CIO, CPO y liderazgo técnico. Estructura canónica "aclaración de vocabulario → articulación → impacto de la IA → recomendaciones por rol → FAQ", con una dimensión de **tabla comparativa** dimensión por dimensión (alcance, propósito, pregunta, actores, métricas, horizonte, riesgos) y una sección de FAQ que resuelve confusiones frecuentes ("¿el PDLC reemplaza al SDLC?", "¿PDLC vs PLC?").

**Estilo**: didáctico y estructurado — primero expone definiciones estandarizadas (referenciando ISO/IEC/IEEE 12207, modelos históricos), luego se apoya en autoridades reconocidas (Marty Cagan para los Four Big Risks y el desplazamiento del cuello de botella, John Cutler para la feature factory, Andrew Ng para la inversión de la proporción PM/ingeniero, DORA para los datos de estabilidad). **Frases martillo** recurrentes: "el PLC observa una curva; el PDLC organiza el trabajo"; "el SDLC aborda nativamente solo uno de cada cuatro riesgos"; "a medida que el código se convierte en un commodity, el margen se desplaza hacia el juicio de producto y la gobernanza". Distingue **correlación de causalidad** (datos de DORA 2025: "correlaciones, no causalidad"). Cierra con un **posicionamiento de producto** deliberado del marco propio de SFEIR (ciclo de 11 fases, Software Factory 10x), presentado como el componente ya entregado al que ahora hay que añadir la articulación de los dos ciclos.

## Pense-betes

- **La distinción en una frase.** **SDLC** = "construir el software **correcta y fiablemente**" (pregunta: *¿cómo entregarlo?*); **PDLC** = "construir el producto **correcto**, triunfar en el mercado" (pregunta: *¿qué construir, y por qué?*). El SDLC es un **subconjunto** del PDLC, no su competidor.
- **Anidamiento, no sustitución.** El SDLC está **alojado bajo la fase de desarrollo** del PDLC. Cuando el equipo de producto llega a la etapa de "construcción", un ciclo SDLC completo (diseño → construcción → pruebas → revisión → despliegue) se ejecuta dentro de él. Respuesta directa a la FAQ: "el PDLC no reemplaza al SDLC, los dos están anidados".
- **No confundir PDLC y PLC.** El **PLC** (ciclo de vida del producto, Theodore Levitt, HBR 1965 — introducción/crecimiento/madurez/declive) describe una **trayectoria comercial** que guía el marketing. El **PDLC** describe el **proceso de diseño y construcción**. Fórmula: "el PLC observa una **curva**; el PDLC organiza el **trabajo**".
- **El SDLC cubre solo uno de cada cuatro riesgos.** Vía el marco **"Four Big Risks" de Marty Cagan**: **Valor** (PM — "¿vendrán, lo elegirán?"), **Usabilidad** (Diseñador — "¿sabrán usarlo?"), **Viabilidad técnica** (Lead Engineer — "¿se puede construir?"), **Viabilidad de negocio** (PM — "¿funciona para el negocio?"). El SDLC aborda nativamente solo la **viabilidad técnica**. Excelencia en SDLC + ceguera al PDLC = "software que nadie quiere" = **feature factory** de **John Cutler** (el éxito medido por el **output**, no por el **outcome**).
- **Por qué la IA lo cambia todo: la compresión del SDLC.** **Datos de Google/JetBrains, mayo de 2026**: **~85% de los desarrolladores** usan regularmente agentes de codificación; **~41% del código nuevo** es generado por IA. La implementación pasa de **semanas a horas** — pero los requisitos, la arquitectura y la verificación siguen a **ritmo humano**.
- **El cuello de botella se desplaza aguas arriba.** **Marty Cagan (abril de 2026)**: "cuando el coste de la entrega se desploma, el cuello de botella se traslada al discovery — decidir **qué** construir". Lo que escasea ya no es el código, es el **juicio de producto**.
- **La señal de DORA 2025 (leerla con cuidado).** Encuesta de Google Cloud (~5.000 profesionales, 90% de adopción de IA): correlación **positiva con el throughput de entrega**, pero **negativa con la estabilidad** (correlaciones, **no causalidad**). Interpretación: entregar **funcionalidades no validadas** más rápido crea inestabilidad y retrabajo — exactamente lo que la disciplina del PDLC busca prevenir aguas arriba.
- **La inversión de la proporción.** **Andrew Ng (AI Startup School, julio de 2025)**: algunos equipos proponen invertir la proporción histórica **"1 PM por 4 ingenieros"** hasta llegar a **"2 PM por 1 ingeniero"** — según el contexto. Una señal de que el centro de gravedad del esfuerzo se desplaza de nuevo hacia la definición de producto.
- **La frontera se vuelve porosa.** Con el **spec-driven development**, el artefacto de diseño del PDLC **alimenta directamente** al SDLC: "la frontera entre los dos ciclos se vuelve porosa". La **especificación de producto se vuelve ejecutable** por agentes.
- **Lo que un CIO debe reconocer.** Optimizar solo el SDLC ya no basta: un SDLC aumentado se convierte en un **estándar de mercado, no en un diferenciador**. Acciones: (1) **instrumentar la unión** con el producto; (2) **exigir especificaciones ejecutables** como entrada; (3) **cruzar** las métricas técnicas con las métricas de **outcome**; (4) **rechazar** el rol de "proveedor de funcionalidades". Riesgo identificado: un **PDLC artesanal frente a un SDLC industrializado** crea un "desequilibrio insostenible".
- **Lo que un CPO debe reconocer.** El desplazamiento del cuello de botella es a la vez una **promoción** (el juicio de producto vuelve a ser escaso) **y** un aviso para actuar: **equipar el discovery** (prototipado con agentes, validación acelerada de los cuatro riesgos) para alcanzar la **paridad de industrialización** con el SDLC. "El CPO sostiene ahora el camino crítico de la empresa".
- **Posicionamiento propio de SFEIR.** El marco "Diseñar y construir en la era agéntica" — **ciclo de 11 fases** + **Software Factory 10x** — resuelve el lado de la ingeniería; la **siguiente palanca** es la **articulación de los dos ciclos** (PM aumentado, porosidad PDLC/SDLC, gobernanza de extremo a extremo). Conclusión: "a medida que el código se convierte en un **commodity**, el margen se desplaza hacia el **juicio de producto y la gobernanza**".
- **Relacionado**: clúster **SDLC / ADLC / ciclo agéntico** (BMAD-Method urbanismo de IA agéntica 2026-02-04; The New SDLC With Vibe Coding, Google mayo 2026; SFEIR "arquitecto en la era de la IA" 2026-07-15; ciclo de 11 fases de SFEIR); **DORA** (DORA 2026-04-21 ROI/curva 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; enfoque spec-driven de IA); **KDLC** (Ashish Singh, ciclo de vida del conocimiento, 28 de junio de 2026) y **compounding knowledge lifecycle** (Klaassen 2026-07-02) como marcos de ciclo de vida vecinos.

## RésuméDe400mots

SFEIR aclara dos marcos a menudo confundidos. El **SDLC** (Software Development Life Cycle), estandarizado por **ISO/IEC/IEEE 12207** (2017, 2026), estructura la **producción de software** — recolección de requisitos, diseño, desarrollo, pruebas/QA, despliegue, mantenimiento — con su linaje de modelos (Waterfall 1970, modelo en V, iterativo/espiral, **Agile** 2001, **DevOps/DevSecOps** 2009+) y sus métricas **DORA** (throughput, estabilidad, MTTR, tasa de fallos de cambio). Su propósito: "construir el software **correcta y fiablemente**". El **PDLC** (Product Development Life Cycle) es el **ciclo paraguas**: desde la ideación/discovery hasta la retirada del mercado, busca "construir el producto **correcto**". No confundir con el **PLC** de Theodore Levitt (1965), que describe una **curva comercial**; "el PLC observa una curva, el PDLC organiza el trabajo".

**Articulación**: los ciclos están **anidados** — el SDLC es el subconjunto del PDLC alojado bajo su **fase de desarrollo**. Punto crítico vía el marco **"Four Big Risks" de Marty Cagan** (Valor, Usabilidad, Viabilidad técnica, Viabilidad de negocio): el SDLC aborda nativamente solo la **viabilidad técnica** — "uno de cada cuatro riesgos". Una organización fuerte en SDLC pero ciega al PDLC se convierte en la **"feature factory"** de **John Cutler**, que mide el éxito por el **output** en lugar del **outcome**.

**Por qué la IA lo cambia todo**: la IA generativa **comprime el SDLC** (Google/JetBrains, mayo de 2026: **~85%** de los desarrolladores usan agentes de codificación, **~41%** del código nuevo es generado por IA; la implementación pasa de semanas a horas). El **cuello de botella se desplaza aguas arriba** — decidir *qué* construir (**Cagan**, abril de 2026). Tres consecuencias: **DORA 2025** (~5.000 profesionales, 90% de adopción) muestra una correlación **positiva con el throughput pero negativa con la estabilidad** (correlaciones, no causalidad) — más funcionalidades no validadas, más retrabajo; **Andrew Ng** (julio de 2025) informa de la inversión de la proporción **"1 PM / 4 ingenieros" a "2 PM / 1 ingeniero"**; y el **spec-driven development** vuelve **porosa** la frontera **PDLC/SDLC** (la especificación se vuelve ejecutable por agentes).

**Recomendaciones.** Para el **CIO**: un SDLC aumentado es ahora un **estándar de mercado, no un diferenciador** — instrumentar la unión con el producto, exigir **especificaciones ejecutables**, cruzar las métricas técnicas y de outcome, rechazar el rol de "proveedor de funcionalidades"; un PDLC artesanal frente a un SDLC industrializado es un "desequilibrio insostenible". Para el **CPO**: a la vez una promoción **y** un aviso para actuar — **equipar el discovery** para alcanzar la paridad de industrialización. SFEIR posiciona su marco propio (**ciclo de 11 fases** + **Software Factory 10x**) como la respuesta del lado de la ingeniería, con la **articulación de los dos ciclos** como la siguiente palanca. Conclusión: "a medida que el código se convierte en un commodity, el margen se desplaza hacia el juicio de producto y la gobernanza".

## 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/es/fiches/sfeir-sdlc-pdlc-articulation-2026-07-22/