DFDy Design-First Delivery

DFDy es un modelo de referencia para el desarrollo de arquitectura de software: ordena qué se define, qué se decide y qué se aprueba antes de promover a producción. No es un estándar, es una propuesta que compone prácticas reconocidas. Recórrelo, cambia las decisiones y explora cada paso.

Cambia las dos decisiones del flujo y mira qué pasos se recorren. Toca cualquier nodo para ver qué es y por qué está ahí.

¿Hay varias opciones de diseño que comparar?

¿El servicio necesita una base de datos?

Etapa que el cliente revisa y aprueba (Brief, PRD, HdU y UAT)Aprobación o puerta

Recorrido con tus opciones

Brief → PRD → ¿Varias opciones? → KDD → ADR → SAD → TM → NFR → OAS → ¿Base de datos? → DCA → HdU → TC → UAT → ARB → SSP → Producción → SOP. (ARB, SSP y SOP corren en paralelo o como apoyo.)

Qué es este flujo y qué no

No es un estándar. Es un flujo de referencia propio que compone prácticas reconocidas en un solo orden. El orden, los puntos de decisión y las dependencias entre pasos son una propuesta de trabajo, no una norma.

Lo más cercano a un estándar de ciclo de vida es ISO/IEC/IEEE 12207, pero no define estos pasos.

Decisiones

ADR (Nygard, 2011)
Arquitectura

ISO/IEC/IEEE 42010 y Rozanski y Woods, Software Systems Architecture
Requisitos no funcionales

ISO/IEC 25010 (modelo de calidad)
Contrato de API

OpenAPI (web), RPC o interfaz de terminal, según la plataforma
Historias de usuario

Cohn, User Stories Applied
Pruebas

ISO/IEC/IEEE 29119
Modelo de amenazas

Microsoft SDL y Shostack, Threat Modeling
Seguridad

NIST SP 800-18 (plan de seguridad del sistema)
Revisión de arquitectura

TOGAF (Architecture Board)

DFDy vs. otros modelos Comparativa con BMAD Method, Spec-Driven Development, Microsoft SDL, TOGAF, las revisiones de diseño y OWASP SAMM.

DCA: datos personales y auditorías

Si el servicio guarda datos, la revisión de datos es el paso que más consecuencias tiene. Su trabajo es detectar si hay datos de personas, datos sensibles o datos de tarjetas de pago y, si los hay, identificar qué leyes y auditorías de seguridad se activan, qué evidencia exigen y cómo pasan al plan de seguridad.

Las preguntas, la tabla y los entregables son una propuesta de este modelo, no asesoría legal. Para un caso real, valida con un abogado y con el área de seguridad.

1. Detectar

¿Guarda o procesa datos que identifican a una persona: nombre, RUT, correo, teléfono, dirección, IP o ubicación?
¿Hay datos sensibles: salud, biométricos, origen étnico, afiliación política o sindical, situación socioeconómica, convicciones, vida sexual, orientación sexual o identidad de género?
¿Hay datos de menores de edad?
¿Pasan por el sistema datos de tarjetas de pago: PAN, fecha de vencimiento, CVV o PIN?
¿Hay datos financieros, bancarios o de obligaciones económicas?
¿Los datos se comparten con terceros o se guardan fuera de Chile?
¿Cuánto tiempo se guardan y cómo se borran?

Un «sí» a cualquier pregunta activa una fila de la tabla siguiente. Si todas son «no», DCA deja registrado que el servicio no trata datos personales y solo aplica la clasificación interna.

2. Identificar qué auditorías se activan

Qué ley o auditoría activa cada tipo de dato, qué evidencia exige y qué pasa al plan de seguridad
Si se detecta	Qué aplica	Evidencia que exige	Pasa al SSP como
Datos personales	Ley 21.719 en Chile; el GDPR si hay personas en la Unión Europea; la ley que corresponda en otras jurisdicciones.	Inventario de tratamientos con su base de licitud (consentimiento u otra que permita la ley) Aviso de privacidad Procedimiento para los derechos de acceso, rectificación, supresión, oposición, portabilidad y bloqueo Contratos con los proveedores que tratan datos por cuenta del servicio Medidas de seguridad proporcionales al riesgo, con evidencia de que funcionan	Control de acceso, cifrado, retención y borrado.
Datos sensibles o de menores	Ley 21.719 con exigencias reforzadas: consentimiento expreso para datos sensibles y de los padres o representantes para menores de 14 años. En salud pueden aplicar además normas del sector.	Registro de consentimientos Evaluación de impacto aprobada antes de tratar datos de alto riesgo Plan de respuesta a filtraciones, con aviso a la Agencia y a los afectados	Controles reforzados y registro de auditoría de cada acceso.
Datos de tarjetas de pago	PCI DSS v4.0.1, del PCI Security Standards Council. No es una ley: lo exigen las marcas de tarjetas y el banco adquirente.	Diagrama de flujo de los datos de tarjeta y definición del alcance (CDE) SAQ o ROC según el nivel del comercio, con su AOC Escaneos de un ASV y pruebas de penetración, cuando aplican Nunca guardar el CVV ni el PIN después de autorizar; el PAN ilegible si se guarda	Alcance PCI, segmentación de red y gestión de vulnerabilidades.
Credenciales y secretos	No hay una ley específica: es buena práctica de seguridad.	Contraseñas guardadas con un hash diseñado para eso Secretos en un gestor de secretos, nunca en el código	Gestión de identidades y de secretos.

La ley chilena: 19.628 y 21.719

Hoy rige la Ley 19.628, sobre protección de la vida privada, de 1999.
La Ley 21.719, publicada en el Diario Oficial el 13 de diciembre de 2024, la reemplaza casi por completo y crea la Agencia de Protección de Datos Personales, que fiscaliza y sanciona.
Entra en vigencia el 1 de diciembre de 2026. Un proyecto en el Senado (boletín 18.623-07) propone postergarla al 1 de diciembre de 2027; al momento de escribir esto no estaba aprobado.
Las multas llegan hasta 20.000 UTM por infracciones gravísimas, como ocultar una filtración u omitir una evaluación de impacto obligatoria.

Fuentes encontradas por IA: Ley 21.719 en la BCN, publicación en el Diario Oficial y el resumen de LexAlert. Revisa el estado de la postergación antes de fijar fechas.

Tarjetas: reducir el alcance

La forma más simple de cumplir con PCI DSS es que el servicio nunca toque el número de la tarjeta: el pago ocurre en la página de un proveedor de pagos (redirección o campo embebido) y el servicio solo guarda el identificador de la transacción. Así el alcance se reduce mucho, y un comercio de comercio electrónico puede calificar para el cuestionario más corto (SAQ A).

Fuente encontrada por IA: biblioteca de documentos del PCI SSC. Qué cuestionario corresponde lo define el banco adquirente.

3. Entregar y conectar

DCA entrega

Inventario por campo: categoría, nivel, base de licitud, retención, ubicación y terceros
Diagrama de flujo de los datos
Lista de leyes y auditorías que aplican, con un responsable por cada una
Controles exigidos

El SSP lo usa

El plan de seguridad (SSP) toma la lista de auditorías y controles como requisitos. El ARB revisa que la arquitectura los permita, por ejemplo la segmentación que pide PCI DSS.

Antes de producción

La promoción exige la evidencia de cada auditoría activada: la evaluación de impacto aprobada, el AOC de PCI DSS vigente o el procedimiento de derechos funcionando. Los controles bajan a las HdU como criterios de aceptación, y los SOP suman la respuesta a filtraciones y la atención de derechos.

Glosario

Qué significa cada sigla, qué papel cumple en el flujo, qué necesita, qué produce y cuándo se da por terminada. La definición general viene de las fuentes citadas en cada una, que fueron encontradas por IA; las entradas, salidas y criterios de término son la propuesta de este flujo. Donde no encontré una fuente que defina la sigla tal como se usa aquí, lo digo.

Brief Resumen de la idea Del inglés: Brief

Resumen corto, de una o dos páginas, de la idea: qué se quiere lograr, por qué importa y para quién.
Rol en el flujo

Es el punto de partida del flujo. Alinea a quienes participan y permite decidir si vale la pena seguir antes de invertir en un PRD completo.

Quién

Producto o quien trae la idea, con el negocio.
Entra
- Una idea, una oportunidad o una necesidad del negocio
Produce
- Qué se quiere lograr y por qué importa
- Para quién es
- Una decisión: seguir hacia el PRD, ajustar o descartar
Está listo cuando

Quien decide entiende la idea y acuerda si sigue adelante.

En este flujo

No reemplaza al PRD: el Brief alinea y decide si seguir; el PRD detalla problema, usuarios, alcance, métricas y restricciones.
«Brief» es un término general del trabajo de producto y diseño, no una sigla ni un estándar. No encontré una fuente que lo defina como paso de este flujo; las citas de abajo son de obra, de memoria, sin abrir los textos, y cubren la práctica de evaluar una idea antes de especificarla. Conviene verificarlas.
Fuentes encontradas por IA
- libro Cagan. Inspired: How to Create Tech Products Customers Love, 2.ª ed. Wiley, 2018. Evaluación de la oportunidad: preguntas cortas para decidir si vale la pena seguir con una idea.
- libro Wiegers y Beatty. Software Requirements, 3.ª ed. Microsoft Press, 2013. Documento de visión y alcance, que precede a la especificación detallada.
PRD Documento de requisitos del producto Del inglés: Product Requirements Document

Documento que describe el problema, los usuarios, los objetivos, el alcance y cómo se medirá el éxito del producto.
Rol en el flujo

Desarrolla el Brief. Fija el qué y el por qué con detalle, y deja el cómo para las decisiones y la arquitectura.

Quién

Producto, con el negocio. Ingeniería lo revisa.
Entra
- Brief aprobado
- Investigación o conversaciones con usuarios
Produce
- Problema y objetivos
- Alcance: qué entra y qué queda fuera
- Métricas de éxito y restricciones
Está listo cuando

Quien decide y el equipo técnico coinciden en el problema y en cómo sabrán que quedó resuelto.
Fuentes encontradas por IA
- libro Cagan. Inspired: How to Create Tech Products Customers Love, 2.ª ed. Wiley, 2018. Explica los límites del PRD tradicional y propone partir del problema y validar antes de especificar.
- libro Wiegers y Beatty. Software Requirements, 3.ª ed. Microsoft Press, 2013. Visión y alcance, y especificación de requisitos.
KDD Comparación de alternativas de diseño

Comparación de alternativas de diseño contra los mismos criterios, para elegir con fundamento.
Rol en el flujo

Evita decidir por costumbre o a ciegas cuando hay más de una opción razonable. Su conclusión se registra en un ADR.

Quién

Equipo técnico, con arquitectura.
Entra
- PRD
- Las opciones de diseño en juego
Produce
- Criterios de comparación (derivados del PRD y de las metas de calidad)
- Tabla de opciones frente a criterios
- Una recomendación con su porqué
Está listo cuando

Todas las opciones se evaluaron con los mismos criterios y hay una recomendada.

En este flujo

Se omite cuando hay una sola opción razonable: el flujo va directo a ADR. La sigla es propia de este flujo; ver la nota de fuentes.
No encontré una fuente canónica que defina la sigla «KDD» en este sentido (la búsqueda solo devuelve «Knowledge Discovery in Databases», que es otra cosa). Las fuentes de abajo cubren la práctica: comparar alternativas con criterios y registrar el porqué. Conviene confirmar con quien definió la sigla qué significa exactamente.
Fuentes encontradas por IA
- artículo Tyree y Akerman. «Architecture Decisions: Demystifying Architecture». IEEE Software 22(2), 2005. Plantilla de decisión con alternativas y justificación.
- web Plantilla «Key Design Decision» (Mozilla Taiwan): registro de decisiones clave de diseño con estado. El sitio no respondió al validar los enlaces (noviembre de 2026).
- libro Bass, Clements y Kazman. Software Architecture in Practice, 4.ª ed. Addison-Wesley, 2021.
ADR Registro de decisión de arquitectura Del inglés: Architecture Decision Record

Registro corto de una decisión de arquitectura: contexto, decisión, estado y consecuencias.
Rol en el flujo

Es la bisagra del flujo. Alimenta la arquitectura del servicio (SAD) y es la entrada de la revisión de arquitectura (ARB).

Quién

Líder técnico o arquitecto del equipo.
Entra
- PRD
- Conclusión del KDD, si hubo
Produce
- Un ADR por decisión, numerado y con estado (propuesta, aceptada, reemplazada)
- Las consecuencias asumidas, buenas y malas
Está listo cuando

La decisión está aceptada y sus consecuencias están escritas. Si cambia después, se escribe otro ADR que la reemplaza, no se edita el anterior.
Fuentes encontradas por IA
- artículo Nygard. «Documenting Architecture Decisions», 2011. Origen del formato: contexto, decisión, estado y consecuencias.
- libro Clements et al. Documenting Software Architectures: Views and Beyond, 2.ª ed. Addison-Wesley, 2010. Sección 6.5 «Documenting Architectural Decisions».
SAD Documento de arquitectura de software Del inglés: Software Architecture Document

Descripción de la arquitectura del servicio: contexto, componentes, interfaces, datos, despliegue y decisiones aplicadas.
Rol en el flujo

Reúne las decisiones en un diseño coherente. De él salen las metas no funcionales (NFR), el contrato de API (OAS) y la pregunta por la base de datos.

Quién

Equipo técnico, liderado por arquitectura.
Entra
- ADR
- PRD
Produce
- Vistas de la arquitectura (contexto, componentes, despliegue)
- Modelo de datos a alto nivel
- Insumos para NFR, OAS y la decisión sobre base de datos
Está listo cuando

Alcanza para derivar el contrato de API y las metas de calidad sin suposiciones abiertas.
Fuentes encontradas por IA
- libro Clements et al. Documenting Software Architectures: Views and Beyond, 2.ª ed. Addison-Wesley, 2010.
- libro Rozanski y Woods. Software Systems Architecture, 2.ª ed. Addison-Wesley, 2011. Puntos de vista y perspectivas.
TM Modelo de amenazas Del inglés: Threat Model

Modelo de amenazas: un análisis de la arquitectura que responde qué se está construyendo, qué puede salir mal, qué se hará al respecto y si el análisis fue suficiente.
Rol en el flujo

Es la práctica de diseño de SDL dentro del flujo. Lleva la seguridad a la arquitectura y alimenta las historias (HdU) y la aprobación de seguridad (SSP).

Quién

Equipo técnico con seguridad.
Entra
- SAD (diagrama de flujo de datos y límites de confianza)
- DCA, si aplica
Produce
- Amenazas identificadas, por ejemplo con STRIDE, y su prioridad
- Controles de mitigación que bajan a las HdU como criterios de aceptación
- Riesgos que se aceptan, para revisarlos en SSP
Está listo cuando

Cada amenaza priorizada tiene un control asignado o un riesgo aceptado de forma explícita.

En este flujo

Se revisa cuando cambia la arquitectura, entra un dato nuevo o se suma un proveedor.
La sigla «TM» es propia de este flujo; la práctica es la de modelado de amenazas del Security Development Lifecycle (SDL) de Microsoft.
Fuentes encontradas por IA
NFR Requisitos no funcionales Del inglés: Non-Functional Requirements

Metas medibles de calidad del servicio: rendimiento, disponibilidad, seguridad, escalabilidad, costo, observabilidad.
Rol en el flujo

Convierte la calidad esperada en números que luego se pueden probar. Pasan a las historias como criterios de aceptación.

Quién

Arquitectura y producto.
Entra
- SAD
- PRD
Produce
- Metas cuantificadas, por ejemplo «p95 menor a 300 ms con 200 solicitudes por segundo»
- Cómo y dónde se medirá cada una
Está listo cuando

Cada meta tiene un número y un método de medición. «Rápido» o «seguro» sin número no cuenta.
Fuentes encontradas por IA
- estándar ISO/IEC 25010:2023. Modelo de calidad de producto (detallado en esta web: /factory/iso-iec-25010).
- libro Chung, Nixon, Yu y Mylopoulos. Non-Functional Requirements in Software Engineering. Kluwer, 2000.
- libro Bass, Clements y Kazman. Software Architecture in Practice, 4.ª ed. Addison-Wesley, 2021.
OAS Contrato de API Del inglés: OpenAPI Specification (OAS), usada aquí para cualquier API

Contrato de la API: la definición de la interfaz por la que otros se conectan al servicio, con sus operaciones, datos de entrada y salida, errores y autenticación. «API» aquí es cualquier tipo de conector, no solo una API web.
Rol en el flujo

Permite que quienes consumen la API y quienes la implementan trabajen en paralelo sobre el mismo acuerdo, antes de escribir código.

Quién

Backend, con quienes consumen la API.
Entra
- SAD
Produce
- Contrato versionado, en el formato que corresponda a la plataforma
- Base para mocks, validación automática y generación de clientes o de ayuda de uso
Está listo cuando

Los consumidores lo revisaron y lo aprobaron. Los cambios posteriores se versionan.

En este flujo

El formato depende de la plataforma: en web suele ser OpenAPI; en otras, una definición RPC (por ejemplo gRPC con Protocol Buffers); en una herramienta de terminal, los comandos, opciones y formato de salida. La sigla OAS viene del diagrama original y aquí no significa solo OpenAPI.
«OAS» viene del diagrama original, donde su leyenda es «API contract». Aquí significa el contrato de cualquier tipo de conector, no solo OpenAPI: en web suele ser OpenAPI, en otras plataformas una definición RPC y en una herramienta de terminal sus comandos y salida.
Fuentes encontradas por IA
- estándar OpenAPI Initiative. OpenAPI Specification. El contrato de una API web.
- web gRPC. Documentación: el contrato de un servicio RPC se define con Protocol Buffers.
- web Command Line Interface Guidelines: comandos, opciones y salida como contrato de una herramienta de terminal.
- libro Lauret. The Design of Web APIs. Manning, 2019. Diseñar el contrato antes de implementar.
DCA Aprobación de la clasificación de datos Del inglés: Data Classification Approval

Aprobación de la clasificación de la información que guardará el servicio: qué datos son, qué nivel de sensibilidad tienen, qué leyes o auditorías se activan (por ejemplo Ley 21.719 o PCI DSS) y qué controles exigen.
Rol en el flujo

Define cómo deben protegerse los datos antes de que existan, para que las historias ya incluyan esos controles.

Quién

Dueño de los datos y seguridad, o gobierno de datos.
Entra
- SAD (modelo de datos)
Produce
- Inventario de datos con su nivel (por ejemplo pública, interna, confidencial, restringida)
- Detección de datos personales, sensibles o de tarjetas de pago
- Lista de leyes y auditorías que aplican, con la evidencia que exige cada una
- Controles exigidos: cifrado, acceso, retención
Está listo cuando

La clasificación está aprobada antes de escribir las historias.

En este flujo

Solo aplica si el servicio necesita una base de datos. La sigla es propia de este flujo. El detalle de la detección y las auditorías está en la sección «DCA: datos personales y auditorías».
«DCA» es una sigla propia de este flujo (no es un estándar): aprobación de la clasificación de la información. El concepto establecido es «clasificación de la información» (ISO/IEC 27001, control A.5.12) o «categorización de seguridad» (NIST).
Fuentes encontradas por IA
HdU Historia de Usuario

Historia de usuario: una necesidad expresada desde el usuario («como… quiero… para…») con criterios de aceptación verificables.
Rol en el flujo

Reúne las entradas (NFR, OAS, TM y, si aplica, DCA) y las traduce en trabajo concreto y comprobable.

Quién

Producto, con ingeniería y calidad.
Entra
- NFR
- OAS
- TM (controles de seguridad)
- DCA, si aplica
- PRD
Produce
- Backlog de historias pequeñas
- Criterios de aceptación que incluyen metas de calidad, contrato y controles de datos
Está listo cuando

Cada historia es lo bastante pequeña para entregarse y tiene criterios que se pueden verificar con una prueba.
Fuentes encontradas por IA
- libro Cohn. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004. Escribir historias y probarlas con criterios de aceptación.
TC Casos de prueba Del inglés: Test Cases

Caso de prueba: condiciones de partida, pasos y resultado esperado, derivado de un criterio de aceptación.
Rol en el flujo

Cierra el ciclo entre lo que se pidió (HdU) y lo que se comprueba. Cada criterio queda cubierto por al menos un caso.

Quién

Calidad e ingeniería.
Entra
- HdU y sus criterios de aceptación
Produce
- Casos por historia: camino feliz, errores y bordes
- Casos para las metas de calidad y el contrato de API
Está listo cuando

Ningún criterio de aceptación queda sin un caso que lo compruebe.
Fuentes encontradas por IA
- libro Myers, Sandler y Badgett. The Art of Software Testing, 3.ª ed. Wiley, 2011.
- web ISTQB. Glosario estándar de términos de prueba.
UAT Pruebas de aceptación de usuario Del inglés: User Acceptance Testing

Pruebas de aceptación de usuario: quien pidió el producto, o su representante, ejecuta escenarios reales en un entorno cercano a producción y acepta o rechaza.
Rol en el flujo

Es la puerta del carril de desarrollo hacia producción. Junto con la aprobación de seguridad (SSP) habilita la promoción.

Quién

Usuarios o negocio, con apoyo de calidad.
Entra
- TC
- Versión desplegada en un entorno de pruebas
Produce
- Acta de aceptación o lista de defectos a corregir
Está listo cuando

Aceptación formal del negocio, sin defectos bloqueantes abiertos.
Fuentes encontradas por IA
- web ISTQB. Glosario estándar de términos de prueba («user acceptance testing»).
- libro Crispin y Gregory. Agile Testing. Addison-Wesley, 2009. Pruebas de aceptación y rol del cliente.
ARB Comité de revisión de arquitectura Del inglés: Architecture Review Board

Comité de revisión de arquitectura: evalúa las decisiones frente a los principios, riesgos y estándares de la organización.
Rol en el flujo

Corre en paralelo al desarrollo y debe estar aprobado antes de promover a producción. Su aprobación abre la revisión de seguridad.

Quién

Arquitectos senior y representantes de las áreas afectadas.
Entra
- ADR
- SAD (puede estar en borrador)
Produce
- Aprobación, aprobación con condiciones o rechazo con observaciones
Está listo cuando

Aprobado, con las condiciones asumidas por el equipo.

En este flujo

Conviene iniciarlo en las primeras semanas: tiene agenda y puede demorar.
Fuentes encontradas por IA
- libro Bass, Clements y Kazman. Software Architecture in Practice, 4.ª ed., cap. 21 «Evaluating an Architecture» (ATAM y evaluación ligera).
- estándar The Open Group. TOGAF Standard: Architecture Board y Architecture Compliance Reviews.
SSP Plan de seguridad del sistema Del inglés: System Security Plan

Aprobación de seguridad del servicio: plan de seguridad con controles, riesgos, amenazas y responsabilidades.
Rol en el flujo

Corre en paralelo al desarrollo y debe estar aprobado antes de promover a producción.

Quién

Seguridad de la información.
Entra
- ARB aprobado
- SAD
- Modelo de amenazas (TM)
- Clasificación de datos (DCA), si aplica
Produce
- Plan de seguridad aprobado
- Riesgos identificados y los que se aceptan de forma explícita
Está listo cuando

Aprobado por seguridad, con los riesgos residuales aceptados por quien corresponde.

En este flujo

Conviene iniciarlo temprano porque puede demorar. Se asume la lectura «plan de seguridad del sistema» (System Security Plan).
Asumo la lectura habitual «plan de seguridad del sistema» (System Security Plan), coherente con «aprobación de seguridad». Confírmala si en tu organización significa otra cosa.
Fuentes encontradas por IA
- estándar NIST SP 800-18 Rev. 1. Guide for Developing Security Plans for Federal Information Systems, 2006.
SOP Procedimientos operativos estándar Del inglés: Standard Operating Procedures

Procedimiento operativo: pasos escritos para una tarea repetible, como aprovisionar, certificar un release, restaurar un respaldo o responder a un incidente.
Rol en el flujo

Apoya la promoción a producción y la operación. No ocupa un paso fijo del flujo: se usa cuando hace falta.

Quién

Operaciones, con el equipo que construyó el servicio.
Entra
- SAD
- NFR
Produce
- Procedimientos versionados y probados
Está listo cuando

Alguien que no lo escribió puede ejecutarlo siguiendo solo el documento.

En este flujo

Por eso su flecha es punteada en el diagrama.
No hay un libro que defina «SOP» en ingeniería de software; es un término general de operaciones. Las fuentes cubren la práctica de documentar procedimientos operativos.
Fuentes encontradas por IA
- libro Beyer, Jones, Petoff y Murphy (eds.). Site Reliability Engineering. O'Reilly, 2016. Playbooks y procedimientos de respuesta.
- libro Limoncelli, Hogan y Chalup. The Practice of System and Network Administration, 3.ª ed., vol. 1. Addison-Wesley, 2016. Documentar y estandarizar procedimientos.

Ver el diagrama como código Mermaid

flowchart TD
    BRIEF["Brief<br/>Idea and why it matters"] --> PRD["PRD<br/>Product requirements"]
    PRD --> Q{"Several design<br/>options to compare?"}
    Q -- Yes --> KDD["KDD<br/>Compare alternatives"]
    Q -- No --> ADR["ADR<br/>Record the decision"]
    KDD --> ADR
    ADR --> SAD["SAD<br/>Service architecture"]
    SAD --> TM["TM<br/>Threat model (SDL)"]
    TM --> HDU
    SAD --> NFR["NFR<br/>Non-functional targets"]
    SAD --> OAS["OAS<br/>API contract"]
    SAD --> DB{"Needs a<br/>database?"}
    DB -- Yes --> DCA["DCA<br/>Data classification approval"]
    DB -- No --> HDU
    DCA --> HDU
    NFR --> HDU["HdU<br/>User stories with acceptance criteria"]
    OAS --> HDU
    HDU --> TC["TC<br/>Test cases"]
    TC --> UAT["UAT<br/>Acceptance testing"]
    ADR --> ARB["ARB<br/>Architecture review"]
    ARB --> SSP["SSP<br/>Security approval"]
    UAT --> PROD["Production promotion"]
    SSP --> PROD
    SOP["SOP<br/>Operating procedures"] -.-> PROD

DFDy Design-First Delivery

Recorrido con tus opciones

Qué es este flujo y qué no

Decisiones

Arquitectura

Requisitos no funcionales

Contrato de API

Historias de usuario

Pruebas

Modelo de amenazas

Seguridad

Revisión de arquitectura

DCA: datos personales y auditorías

1. Detectar

2. Identificar qué auditorías se activan

La ley chilena: 19.628 y 21.719

Tarjetas: reducir el alcance

3. Entregar y conectar

DCA entrega

El SSP lo usa

Antes de producción

Glosario

Brief Resumen de la idea Del inglés: Brief

Fuentes encontradas por IA

PRD Documento de requisitos del producto Del inglés: Product Requirements Document

Fuentes encontradas por IA

KDD Comparación de alternativas de diseño

Fuentes encontradas por IA

ADR Registro de decisión de arquitectura Del inglés: Architecture Decision Record

Fuentes encontradas por IA

SAD Documento de arquitectura de software Del inglés: Software Architecture Document

Fuentes encontradas por IA

TM Modelo de amenazas Del inglés: Threat Model

Fuentes encontradas por IA

NFR Requisitos no funcionales Del inglés: Non-Functional Requirements

Fuentes encontradas por IA

OAS Contrato de API Del inglés: OpenAPI Specification (OAS), usada aquí para cualquier API

Fuentes encontradas por IA

DCA Aprobación de la clasificación de datos Del inglés: Data Classification Approval

Fuentes encontradas por IA

HdU Historia de Usuario

Fuentes encontradas por IA

TC Casos de prueba Del inglés: Test Cases

Fuentes encontradas por IA

UAT Pruebas de aceptación de usuario Del inglés: User Acceptance Testing

Fuentes encontradas por IA

ARB Comité de revisión de arquitectura Del inglés: Architecture Review Board

Fuentes encontradas por IA

SSP Plan de seguridad del sistema Del inglés: System Security Plan

Fuentes encontradas por IA

SOP Procedimientos operativos estándar Del inglés: Standard Operating Procedures

Fuentes encontradas por IA