Diagramas de flujo de datos (DFD): Niveles, símbolos y ejemplos prácticos
Aprenda a crear diagramas de flujo de datos con la notación correcta. Cubre los niveles DFD 0-2, los símbolos Yourdon-DeMarco vs Gane-Sarson y ejemplos del mundo real.
Cuando un sistema falla o un proceso produce resultados incorrectos, la primera pregunta generalmente es "¿dónde salió mal la información?". Los diagramas de flujo de datos (DFD) responden a esa pregunta haciendo explícito el movimiento de datos: mostrando exactamente de dónde provienen los datos, hacia dónde van, cómo se transforman y dónde se almacenan.
A diferencia de los diagramas de flujo que modelan el flujo de control (qué sucede a continuación), los DFD modelan el flujo de datos (qué datos se mueven y hacia dónde). Esa distinción los convierte en la herramienta adecuada para el análisis de sistemas, el diseño de software y la documentación de integraciones de datos complejas.
¿Qué es un diagrama de flujo de datos?
Un diagrama de flujo de datos es una representación visual de cómo se mueven los datos a través de un sistema. Muestra:
- Entidades externas — fuentes y destinos de datos fuera del sistema
- Procesos — transformaciones que convierten datos de entrada en datos de salida
- Almacenes de datos — lugares donde se guardan los datos en reposo
- Flujos de datos — el movimiento de datos entre los elementos anteriores
Los DFD no muestran temporización, lógica de decisión ni quién realiza las tareas. Muestran exclusivamente el movimiento de datos. Este alcance enfocado los hace útiles para comprender y diseñar sistemas sin perderse en los detalles de implementación.
Símbolos del DFD
Dos notaciones dominan: Yourdon-DeMarco y Gane-Sarson. Representan los mismos conceptos con formas diferentes.
Notación Yourdon-DeMarco
La notación original de análisis estructurado, ampliamente utilizada en ingeniería de software:
| Elemento | Símbolo | Descripción |
|---|---|---|
| Proceso | Círculo (burbuja) | Transforma datos; etiquetado con frase verbal |
| Almacén de datos | Rectángulo de extremo abierto | Almacena datos; etiquetado con un sustantivo |
| Entidad externa | Rectángulo | Fuente o destino fuera del sistema |
| Flujo de datos | Flecha con etiqueta | Datos nombrados moviéndose entre elementos |
┌──────────┐ ╭──────────╮ ┌═══════════════╗
│ Cliente │───────→ │ Validar │───────→ ║ D1: Pedidos ║
└──────────┘ Pedido │ pedido │ Pedido ╠═══════════════╣
╰──────────╯ válido ║ ║
Notación Gane-Sarson
Común en sistemas de información y análisis de negocio:
| Elemento | Símbolo | Descripción |
|---|---|---|
| Proceso | Rectángulo con esquinas redondeadas (encabezado dividido) | Etiquetado con ID y nombre del proceso |
| Almacén de datos | Rectángulo abierto en el lado izquierdo | Etiquetado con número D y nombre |
| Entidad externa | Rectángulo | Fuente o destino fuera del sistema |
| Flujo de datos | Flecha con etiqueta | Datos nombrados moviéndose entre elementos |
┌──────────┐ ┌────────────────┐ ┌═══╦════════════╗
│ Cliente │───────→ │ 1.0 │───────→ ║D1 ║ Pedidos ║
└──────────┘ Pedido │ Validar pedido │ Válido ╚═══╩════════════╝
└────────────────┘ Pedido
¿Cuál notación usar?
Ambas transmiten la misma información. Elija según su contexto:
- Yourdon-DeMarco: preferida en ingeniería de software, academia y cuando se usan métodos de análisis estructurado
- Gane-Sarson: común en sistemas de información empresarial y contextos corporativos
Elija una y manténgala consistente en todos los diagramas de un proyecto.
Niveles del DFD
Los DFD están organizados jerárquicamente. Los diagramas de nivel superior proporcionan una visión general; los de nivel inferior proporcionan detalle. Cada nivel descompone un único proceso del nivel superior en sus subprocesos internos.
Nivel 0: Diagrama de contexto
El diagrama de contexto muestra todo el sistema como un único proceso, rodeado de entidades externas. Define el límite del sistema y muestra qué datos cruzan ese límite.
Pedido del cliente
┌──────────┐ ─────────────────→ ╭──────────────────────╮
│ Cliente │ │ │
└──────────┘ ←───────────────── │ Sistema de gestión │
Confirmación del │ de pedidos │
pedido │ │
╰──────────────────────╯
┌──────────┐ ─────────────────→ │
│Proveedor │ Actualización ↓
└──────────┘ de inventario ┌──────────────┐
│ Proc. pagos │
└──────────────┘
Un diagrama de contexto debe caber en una página y mostrar solo los flujos de datos que cruzan el límite: sin detalles internos. Si se encuentra agregando procesos internos, está en el nivel incorrecto.
Nivel 1: Diagrama de resumen
El diagrama de nivel 1 descompone el único proceso de contexto en sus subprocesos principales. Estas son las áreas funcionales principales del sistema.
┌──────────┐ ╭──────────╮ ╭──────────╮
│ Cliente │───────→ │ 1.0 │───────→ │ 2.0 │───┐
└──────────┘ Pedido │ Recibir │Pedido │ Procesar │ │
│ pedido │Válido │ pago │ │
╰──────────╯ ╰──────────╯ │
│ ↓
↓ ╭──────────╮
┌════════════════╗ │ 3.0 │
║ D1: Pedidos ║────────────→ │ Cumplir │
╚════════════════╝ Datos del │ pedido │
pedido ╰──────────╯
│
↓
┌──────────┐
│ Empresa │
│ envíos │
└──────────┘
Los diagramas de nivel 1 típicamente tienen de 3 a 7 procesos. Si tiene más, considere agruparlos en menos procesos de alto nivel.
Nivel 2: Diagrama detallado
El nivel 2 descompone cada proceso del nivel 1 en sus subpasos. Cada burbuja del nivel 1 obtiene su propio diagrama de nivel 2.
Por ejemplo, expandiendo el proceso 1.0 "Recibir pedido" del ejemplo anterior:
┌──────────┐ ╭──────────╮ ╭──────────╮
│ Cliente │──────────→ │ 1.1 │──────────→ │ 1.2 │
└──────────┘ Pedido │ Validar │ Dato válido│ Verificar│
en bruto │ formato │ │ stock │
╰──────────╯ ╰──────────╯
│ │ │
Pedido │ En stock
inválido Sin│
↓ stock↓
┌──────────┐ ╭──────────╮
│ Cliente │ │ 1.3 │
└──────────┘ │ Reservar │
│ artículos│
╰──────────╯
│
↓
┌════════════╗
║ D1: Pedidos║
╚════════════╝
¿Qué tan profundo debe ir?
Deje de descomponer cuando un proceso:
- Sea lo suficientemente simple como para describirse en pocas frases
- Sea implementado por una sola persona o función de sistema atómica
- Ya esté en el nivel de detalle necesario para la implementación
La mayoría de los sistemas no necesitan más que el nivel 2. El nivel 3 es raro y a menudo indica que el sistema es demasiado complejo o que la descomposición no está bien estructurada.
DFD vs diagrama de flujo
Con frecuencia se confunden porque ambos usan cajas y flechas. Responden a preguntas diferentes.
| Aspecto | Diagrama de flujo de datos | Diagrama de flujo |
|---|---|---|
| Muestra | Cómo se mueven los datos en un sistema | Cómo fluye el control en un proceso |
| Pregunta principal | ¿Qué datos van a dónde? | ¿Qué sucede a continuación? |
| Tiempo/secuencia | No modelado (solo transformaciones) | Central — la secuencia es la estructura principal |
| Lógica de decisión | No representada | Explícita (nodos de decisión en diamante) |
| Quién realiza | No se muestra | Se puede mostrar con formato de carriles |
| Almacenamiento de datos | Símbolo explícito de almacén de datos | No representado |
| Mejor para | Análisis de sistemas, arquitectura de datos | Documentación de procesos, guías de procedimientos |
Un diagrama de flujo muestra los pasos de un proceso de aprobación de préstamos. Un DFD muestra qué datos recibe el sistema de solicitud de préstamos, dónde se almacenan y qué salidas produce.
Use un DFD cuando analice o diseñe un sistema. Use un diagrama de flujo cuando documente un procedimiento.
Paso a paso: crear un DFD
Paso 1: Definir el límite del sistema
Identifique qué está dentro de su sistema y qué está fuera:
- Dentro: procesos, almacenes de datos y flujos de datos que controla
- Fuera: entidades externas — clientes, socios, sistemas externos
Todo lo que esté fuera del límite es una entidad externa. Los datos que cruzan el límite aparecen como flujos en el diagrama de contexto.
Paso 2: Dibujar el diagrama de contexto (Nivel 0)
- Coloque todo el sistema como un único círculo etiquetado en el centro
- Identifique todas las entidades externas y colóquelas alrededor del exterior
- Dibuje flujos de datos que crucen el límite con etiquetas descriptivas
- Verifique la completitud: ¿hay algún dato que entre o salga del sistema sin etiquetar?
Paso 3: Identificar los procesos principales (Nivel 1)
Descomponga el sistema en 3-7 procesos principales:
- Nombre cada proceso con una frase verbal ("Validar pedido", "Procesar pago")
- Númerelos (1.0, 2.0, 3.0)
- Identifique qué flujos de datos los conectan
Paso 4: Agregar almacenes de datos
Identifique dónde se guardan los datos entre procesos:
- Bases de datos: registros de clientes, historial de pedidos, inventario
- Archivos: archivos de registro, configuración
- Datos externos: datos pasados hacia/desde sistemas externos (a menudo representados como flujos de límite, no como almacenes internos)
Nombre cada almacén de datos con un sustantivo y asígnele un número D (D1, D2).
Paso 5: Conectar con flujos de datos
Dibuje flechas etiquetadas entre elementos:
- Los flujos deben tener nombres descriptivos ("pedido del cliente", "registro validado", "factura")
- Los flujos conectan procesos con procesos, procesos con almacenes de datos, y entidades externas con procesos
- Los almacenes de datos no se conectan directamente a entidades externas (los datos deben pasar a través de un proceso)
Paso 6: Descomponer al Nivel 2
Para cada proceso principal del Nivel 1, dibuje un diagrama de Nivel 2 separado que muestre sus subprocesos internos. Los flujos de datos que entran y salen del proceso del Nivel 1 se convierten en los flujos de límite del diagrama de Nivel 2.
Paso 7: Verificar la consistencia
Compruebe que:
- Cada flujo de datos que entra en un proceso es utilizado por ese proceso
- Cada flujo de datos que sale de un proceso se origina en ese proceso
- Los almacenes de datos solo son accedidos a través de procesos (no directamente por entidades externas)
- Los flujos de límite del Nivel 1 coincidan con los flujos del diagrama de contexto
Ejemplo del mundo real: sistema de pedidos de comercio electrónico
Nivel 0: Diagrama de contexto
┌──────────┐ Solicitud de pedido ╭──────────────────────╮
│ Cliente │ ────────────────────→ │ │
└──────────┘ │ Sistema de pedidos │
↑ Estado del pedido │ E-Commerce │
└───────────────────────── ─ │ │
╰──────────────────────╯
┌──────────┐ Resultado del pago │ ↑
│ Pasarela │ ────────────────────→ │ │
│ de pago │ ←──────────────────── │ Datos de
└──────────┘ Solicitud de cargo ↓ envío
┌──────────────┐
│ Empresa de │
│ envíos │
└──────────────┘
Nivel 1: Procesos principales
Cliente ─── Solicitud de pedido ──→ ╭──────────╮
│ 1.0 │ ──→ D1: Pedidos
│ Validar │
│ pedido │
╰──────────╯
│
Pedido validado
↓
Pasarela pago ←── Cargo ── ╭──────────╮ ── Registro ──→ D2: Pagos
Solicitud │ 2.0 │ de pago
Pasarela pago ── Resultado ──→ │ Procesar │
│ pago │
╰──────────╯
│
Pedido confirmado
↓
╭──────────╮
D1: Pedidos ── Datos ──────→ │ 3.0 │ ── Solicitud envío ──→ Empresa
D3: Productos ─ Stock ─────→ │ Cumplir │ de envíos
│ pedido │
╰──────────╯
│
Datos de envío
↓
╭──────────╮
│ 4.0 │ ── Actualización ──→ Cliente
│ Rastrear │ de estado
│ y notif. │
╰──────────╯
Nivel 2: Descomposición del proceso 1.0 (Validar pedido)
Cliente ─── Pedido en bruto ──→ ╭──────────╮
│ 1.1 │ ── Inválido ──→ Cliente (Error)
│ Verificar│
│ formato │
╰──────────╯
│
Pedido formateado
↓
╭──────────╮
D3: Productos ─ Info stock ─────→│ 1.2 │ ── No disponible ──→ Cliente
│ Verificar│
│ stock │
╰──────────╯
│
Pedido disponible
↓
╭──────────╮
D4: Clientes ─ Datos auth ──────→│ 1.3 │ ── No verificado ──→ Cliente
│ Verificar│
│ cliente │
╰──────────╯
│
Pedido validado
↓
D1: Pedidos (almacenado)
Errores comunes en DFD
Conectar entidades externas directamente a almacenes de datos. Los almacenes de datos son internos; las entidades externas no pueden acceder a ellos directamente. Todos los datos que cruzan el límite del sistema deben pasar a través de un proceso.
Flujos de datos sin etiquetar. Cada flecha debe tener un nombre descriptivo. "Datos" o "Info" no son descriptivos. Un flujo debe nombrarse según lo que representan los datos: "pedido del cliente", "confirmación de pago", "nivel de stock".
Procesos sin entradas o salidas. Un proceso debe tener al menos un flujo de entrada y uno de salida. Un círculo sin datos entrantes "crea" datos de la nada — eso no es un proceso, es una entidad externa. Un círculo sin datos salientes descarta todo — modele eso como una escritura en almacén de datos o elimine el proceso.
Mezclar flujo de control con flujo de datos. Las decisiones, la secuencia y la lógica de control no pertenecen a los DFD. Si se encuentra dibujando diamantes de decisión, está creando un diagrama de flujo, no un DFD. Los DFD solo muestran el movimiento de datos.
Demasiado detalle en el nivel 1. El nivel 1 debe tener de 3 a 7 procesos principales. Si muestra 15 procesos en el nivel 1, ha omitido la descomposición jerárquica. Agrupe procesos relacionados en burbujas de nivel superior y use el nivel 2 para mostrar el detalle.
Niveles inconsistentes. Los flujos de datos que entran en el proceso 2.0 en el diagrama de nivel 1 deben coincidir con los flujos de límite en el diagrama de nivel 2 para el proceso 2.0. La inconsistencia significa que los diagramas no representan el mismo sistema.
Almacenes de datos compartidos entre subsistemas sin explicación. Si varios procesos acceden al mismo almacén de datos, asegúrese de que sea intencional y de que el acceso tenga sentido. El uso excesivo de un único almacén de datos "base de datos principal" oculta decisiones importantes de arquitectura de datos.
Crear diagramas de flujo de datos con Flowova
Mapear flujos de datos manualmente es tedioso: identificar todos los flujos de límite, numerar los procesos de forma consistente y mantener los niveles sincronizados requiere un esfuerzo significativo.
El creador de diagramas de flujo de datos de Flowova genera estructuras DFD a partir de descripciones de sistemas en lenguaje natural. Describa las entradas, salidas y procesos principales de su sistema, y obtenga un diagrama borrador que puede refinar. Esto es especialmente útil para crear diagramas de contexto y resúmenes de nivel 1 rápidamente, y luego profundizar en el detalle de nivel 2 para los procesos que lo necesiten.
Conclusión
Los DFD son la herramienta adecuada cuando necesita comprender o comunicar cómo se mueven los datos a través de un sistema: no qué sucede paso a paso, sino de dónde provienen los datos, qué los transforma, dónde se almacenan y hacia dónde van finalmente.
Comience con un diagrama de contexto para establecer el límite del sistema. Descomponga al nivel 1 para identificar los procesos principales. Vaya al nivel 2 solo para los procesos que necesiten mayor aclaración. Mantenga los flujos de datos con nombres específicos, evite mezclar lógica de control en el diagrama y verifique la consistencia entre niveles.
Recursos relacionados
- Símbolos de diagrama de flujo y significados — Referencia de notación estándar
- Guía de diagramas BPMN — Estándar de modelado de procesos de negocio
- Creador de diagramas de flujo de datos — Crear DFD con IA
- Plantillas de arquitectura de sistemas — Plantillas de diagramas de arquitectura listas para usar
