Diagrama de Flujo de Datos (DFD)

 ¿Qué es un diagrama de flujo de datos?

Un diagrama de flujo de datos (DFD) traza el flujo de la información para cualquier proceso o
sistema. Emplea símbolos definidos, como rectángulos, círculos y flechas, además de etiquetas
de texto breves, para mostrar las entradas y salidas de datos, los puntos de almacenamiento y
las rutas entre cada destino. Los diagramas de flujo de datos pueden variar desde simples
panoramas de procesos incluso trazados a mano, hasta DFD muy detallados y con múltiples
niveles que profundizan progresivamente en cómo se manejan los datos. Se pueden usar para
analizar un sistema existente o para modelar uno nuevo. De forma similar a todos los mejores
diagramas y gráficos, un DFD puede con frecuencia "decir" visualmente cosas que serían
difíciles de explicar en palabras y funcionan para audiencias tanto técnicas como no técnicas,
desde desarrolladores hasta directores. Esa es la razón por la que los DFD siguen siendo tan
populares después de todos estos años. Aunque funcionan muy bien para software y sistemas
de flujo de datos, en la actualidad no se aplican tanto para visualizar software o sistemas
interactivos, en tiempo real u orientados a bases de datos.

 Historia del DFD

Los diagramas de flujo de datos se popularizaron a finales de la década de 1970, a partir del
libro Structured Design (Diseño estructurado), de los pioneros de la informática, Ed Yourdon y
Larry Constantine. Lo basaron en los modelos computacionales de "gráficos de flujo de datos"
de David Martin y Gerald Estrin. El concepto de diseño estructurado se popularizó en el campo
de la ingeniería de software, y con este también lo hizo el método de DFD. Se volvió más
popular en los círculos de negocios que en los círculos académicos, ya que se aplicó al análisis
de negocios.

Contribuyeron además dos conceptos relacionados:

 Análisis y diseño orientados a objetos (OOAD), propuesto por Yourdon y Peter Coad para
analizar y diseñar una aplicación o sistema.

 Análisis de sistemas estructurados y método de diseño (SSADM), un método de cascada

para analizar y diseñar sistemas de información. Este riguroso enfoque de documentación
contrasta con los ágiles enfoques modernos, tales como Scrum y el Método de desarrollo de
sistemas dinámicos (DSDM).

Otros tres expertos que contribuyeron a este ascenso en la metodología de los DFD fueron
Tom DeMarco, Chris Gane y Trish Sarson. Colaboraron en diferentes combinaciones y fueron
los principales definidores de los símbolos y notaciones usados para un diagrama de flujo de
datos.

 Símbolos y notaciones usadas en los DFD

Dos sistemas comunes de símbolos llevan el nombre de sus creadores:

 Yourdon-Coad

 Yourdon-DeMarco

 Gane-Sarson
 Una diferencia importante en sus símbolos es que Yourdon-Coad y Yourdon-DeMarco usan
círculos para procesos, mientras que Gane y Sarson usan rectángulos redondeados, en
ocasiones llamados "grageas" (rombos). Hay también otras variaciones de símbolos en uso,
por lo que lo importante es ser claro y constante en las figuras y notaciones que uses para
comunicarte y colaborar con otros.

Usando las reglas o lineamientos para DFD de cualquier convención, los símbolos representan
los cuatro componentes de los diagramas de flujo de datos.

1. Entidad externa: un sistema externo que envía o recibe datos, comunicándose con el
sistema que se está diagramando. Son las fuentes y destinos de la información que entra o
sale del sistema. Podría ser una organización o persona externas, un sistema de
computadoras o un sistema de negocios. También se los conoce como terminadores,
fuentes y receptores o actores. Generalmente se los dibuja en los bordes del diagrama.

2. Proceso: cualquier proceso que cambia los datos y produce un resultado. Podría realizar
cálculos u ordenar datos basados en una lógica o dirigir el flujo de datos en función de reglas
de negocios. Se usa una etiqueta pequeña para describir el proceso, por ejemplo "Enviar
pago".

3. Almacén de datos: archivos o repositorios que conservan información para uso posterior, p.
ej., una tabla de base de datos o un formulario de membresía. Cada almacén de
datos recibe una etiqueta simple, p. ej., "Pedidos".

4. Flujo de datos: la ruta que los datos toman entre las entidades externas, los procesos y los
almacenes de datos. Representa la interfaz entre los otros componentes y se muestra con
flechas, generalmente etiquetadas con un nombre de datos corto, como "Detalles de
facturación".

 Reglas y consejos para el DFD

 Cada proceso debe tener al menos una entrada y una salida.

 Cada almacén de datos debe tener al menos una entrada y una salida de flujo de
datos.

 Los datos almacenados en un sistema deben pasar por un proceso.

 Todos los procesos en un DFD pasan a otro proceso o almacén de datos.

 Los datos almacenados en un sistema deben pasar por un proceso.

 Niveles y capas del DFD: de los diagramas de contexto al

pseudocódigo

Un diagrama de flujo de datos puede profundizar progresivamente en más detalle por medio de
niveles y capas, concentrándose en una pieza en particular. Los niveles de un DFD se numeran
0, 1 o 2 y en ocasiones llegan incluso hasta el Nivel 3 o más. El nivel necesario de detalle
depende del alcance de lo que estás tratando de lograr.

 Al Nivel 0 de un DFD también se lo llama Diagrama de contexto. Es un panorama básico de

todo el sistema o proceso que se está analizando o modelando. Está diseñado para ser una
vista rápida que muestra el sistema como un único proceso de nivel alto, con su relación con
entidades externas. Debe ser entendido fácilmente por una amplia audiencia, incluidas
partes interesadas, analistas de negocios, analistas de datos y desarrolladores.
  El Nivel 1 de un DFD brinda un desglose de piezas más detallado del diagrama a nivel de
contexto. Destacarás las principales funciones que el sistema lleva a cabo, a medida que
desgloses el proceso de alto nivel del diagrama de contexto en sus subprocesos.

 Luego el Nivel 2 del DFD profundiza un paso más hacia partes del Nivel 1. Puede requerir
más texto para alcanzar el nivel necesario de detalle acerca del funcionamiento del sistema.

 Es posible el avance hacia los Niveles 3, 4 y más, pero ir más allá del Nivel 3 es poco usual.
Hacerlo puede crear una complejidad que dificulte comunicar, comparar o modelar de forma
efectiva.

Con el uso de capas en el DFD, los niveles en cascada se pueden anidar directamente en el
diagrama, lo que proporciona un aspecto más ordenado con fácil acceso a profundizar en más
detalle.

Al contar con un DFD con tanto detalle, los desarrolladores y diseñadores pueden usarlo para
escribir pseudocódigo, que es una combinación de inglés y de lenguaje de codificación. El
pseudocódigo facilita el desarrollo del código real.

 Ejemplos de cómo se pueden usar los DFD

 Los diagramas de flujo de datos son muy apropiados para el análisis y modelado de
diversos tipos de sistemas en diferentes campos.
 DFD en ingeniería de software: Es aquí donde los diagramas de flujo de datos tuvieron
su principal arranque en la década de 1970. Los DFD pueden brindar un planteamiento
enfocado hacia el desarrollo técnico, en el cual se realiza más investigación previa para
llegar a la codificación.
 DFD en análisis de negocios: Los analistas de negocios emplean los DFD para analizar
los sistemas existentes y encontrar ineficiencias. La diagramación del proceso puede
detectar los pasos que, de otro modo, podrían pasar inadvertidos o no comprenderse
por completo.
 DFD en la reingeniería de procesos de negocios: Los DFD se pueden usar para
modelar un flujo de datos mejor y más eficiente a través de un proceso de negocios. La
reingeniería de procesos de negocios fue impulsada en la década de 1990 para ayudar
a las organizaciones a reducir costos operativos, mejorar el servicio al cliente y
competir mejor en el mercado.
 DFD en el desarrollo ágil: Los DFD se pueden usar para visualizar y comprender los
requisitos de negocios y técnicos y planificar los siguientes pasos. Pueden ser una
herramienta simple pero poderosa para la comunicación y colaboración a fin de
enfocarse en un desarrollo rápido.
 DFD en estructuras de sistemas: Cualquier sistema o proceso se puede analizar en un
detalle progresivo para mejorarlo en aspectos tanto técnicos como no técnicos.

 DFD vs. Lenguaje Unificado de Modelado (UML)

 Mientras que un DFD ilustra cómo fluyen los datos a través de un sistema, UML es un lenguaje
de modelado usado en el Diseño de software orientado a objetos para brindar una vista más
detallada. Un DFD aún puede brindar un buen punto de partida, pero a la hora de desarrollar el
sistema, los desarrolladores pueden optar por diagramas UML, como los diagramas de clases y
los diagramas de estructura para lograr la especificidad requerida

 DFD lógico vs. DFD físico

Estas son las dos categorías de un diagrama de flujo de datos. Un DFD lógico visualiza el flujo
de datos que es esencial para que opere un negocio. Se enfoca en el negocio y la información
necesaria, no en cómo funciona el sistema o cómo se propone que funcione. No obstante, un
DFD físico muestra cómo el sistema está realmente implementado ahora o cómo lo estará. Por
ejemplo, en un DFD lógico, los procesos serían actividades de negocios, mientras que en un
DFD físico, los procesos serían programas y procedimientos manuales

¿Cuál es la diferencia entre un DFD lógico y un DFD físico?

Un DFD lógico se enfoca en el negocio y las actividades de negocios, mientras que un DFD
físico analiza la forma en que se implementa un sistema. Así, mientras todo diagrama de flujo
de datos traza el flujo de información de un proceso o sistema, el diagrama lógico proporciona
el "qué" y el físico el "cómo". Hay dos perspectivas diferentes sobre el mismo flujo de datos,
cada uno diseñado para visualizar y mejorar el sistema. El DFD lógico describe los eventos de
negocios que ocurren y los datos requeridos para cada evento. Proporciona una base sólida
para el DFD físico, el cual describe cómo funcionará el sistema de datos, es decir, el hardware,
el software, los archivos en papel y las personas involucradas. A la vez, el lógico y el físico
pueden visualizar el estado actual por completo y modelar el nuevo estado que se considerará
y luego se implementará.

Propósito y beneficios de cada uno

Empezando con un DFD lógico actual, trazas el flujo de acciones de negocios tal cual existen,
lo que puede resaltar cualquier imperfección o ineficiencia. O bien, quizás ya conoces el tipo de
funcionalidad que buscas agregar, y el DFD lógico actual ayudará a revelar los pasos del
proceso que podría ser necesario eliminar o modificar. Al igual que con cualquier diagrama, el
DFD lógico debe ser suficientemente detallado para ser procesable. Dependiendo de su
alcance, puede tomar tiempo producir el DFD lógico actual y puede parecer tedioso, pero podrá
ser tiempo bien empleado.

Otro beneficio de los DFD lógicos es que tienden a ser más fácilmente entendibles por
personas sin conocimientos técnicos. Es probable que tengan sentido para las personas que
trabajan en las actividades de negocios. Servirán como una buena herramienta para colaborar
y comunicar sobre una mejor información y funcionamiento, sin preocupación aún por el
"cómo". Servirán como un puente entre las necesidades de negocios y los requerimientos
técnicos. La disciplina de trazar el flujo lógico actual ayudará a todos los involucrados a adquirir
un mejor entendimiento y revelará suposiciones erróneas, malentendidos e imperfecciones.
Elaborar modelos lógicos reduce el riesgo de omitir requerimientos de negocios, que de otra
forma surgirían tardíamente en el proceso, causando demoras y teniendo que rehacer el
trabajo.

Luego, con un entendimiento sólido de las actividades de negocios actuales, puedes modelar
una mejor manera con un DFD lógico de nuevo estado, que muestre nuevas funcionalidades y
funcionamiento sobre la base de lo que el análisis de negocios haya revelado. Este nuevo DFD
lógico modela los flujos de datos que son necesarios para crear un mejor funcionamiento, sin
importar la solución técnica o cómo se implementará el sistema.
Después de haber dibujado el nuevo DFD lógico, puede a su vez ser usado para determinar el
mejor método para implementar las actividades de negocios en un sistema actualizado. Esto
será la base para el nuevo DFD físico, el cual representa esa implementación física de
dispositivos, software, archivos y personas para posibilitar los procesos de negocios. En este
sentido, el DFD físico se convierte en el método de proporcionar al negocio lo que necesita. Es
el "cómo" que abastece al "qué". El DFD físico brinda entonces la base de un plan de
implementación para proporcionar el nuevo software, hardware, personas u otras piezas físicas
necesarios para operar el proceso de negocios.

Un ejemplo de análisis de flujo de datos lógico vs. físico

Digamos que tu departamento de RR. HH. tiene un enfoque y un sistema obsoletos para dar
seguimiento a las solicitudes de empleo. En lugar de lanzarte directamente a revisar software
nuevo, empiezas por trazar el flujo de datos lógico actual. Detallas las actividades de negocios
que ocurren, tales como las acciones que se llevan a cabo para escribir una publicación de
empleo, hacerle publicidad, ingresar solicitudes en los archivos o base de datos de la
compañía, alertar a los gerentes de contratación, actualizar los archivos, dar seguimiento a las
etapas del proceso, alertar a los candidatos, y así sucesivamente. Todo esto es desde la
perspectiva de las actividades de negocios, no de la tecnología o de otras partes del "cómo".
Presenta el flujo actual de datos y proporciona la base para comunicar y colaborar en una
mejor funcionalidad a fin de lograr las acciones de negocios necesarias para elegir entre los
candidatos para el empleo. Luego trazas el nuevo flujo lógico posible. Por ejemplo, dicho flujo
podría proporcionar alertas oportunas a los gerentes de contratación, manteniéndolos mejor
informados. Podría permitirles un acceso más sencillo a los currículums y a comparaciones de
calificaciones de los candidatos preseleccionados. Este nuevo DFD lógico es la base para
discutir la mejor manera de implementar un mejor funcionamiento en términos de software,
hardware, sistemas de archivo y empleados, todo lo cual se puede visualizar en un DFD físico.
Este se puede usar para evaluar soluciones de software y otras piezas de implementación para
ver cuál cubre mejor las necesidades de negocios. Por ejemplo, podrías mostrar cómo
diferentes plataformas de software podrían variar en diferentes versiones del DFD físico,
ayudando a revelar la mejor solución.

Elementos opuestos de DFD lógico vs. físico

Los diagramas de flujo de datos se componen de cuatro elementos: entidades externas,

procesos, almacenes de datos y flujos de datos. Sin embargo, los elementos representan
diferentes perspectivas en DFD lógicos que en DFD físicos.

Por ejemplo, en los DFD lógicos, los procesos son actividades de negocios; en los DFD físicos,
los procesos son programas de software, procedimientos manuales u otras formas de procesar
la información. En los DFD lógicos, los almacenes de datos son colecciones de información, sin
importar cómo se almacenan; en los DFD físicos, los almacenes de datos son bases de datos,
archivos de computadora y archivos en papel.

Cómo se usan en diferentes campos

DFD lógicos y físicos en ingeniería de software: Los DFD se originaron en la ingeniería y

desarrollo de software. Un DFD lógico puede captar las actividades actuales y necesarias
requeridas para un proceso. Un nuevo DFD lógico modela un nuevo grupo de actividades y
funciones. Un DFD físico actual representa el software, hardware, bases de datos y personas
actuales que llevan a cabo las actividades, y un nuevo DFD físico modela una nueva
implementación del sistema. Este análisis puede brindar una mejor forma de llegar al código
real que cumpla con los requisitos.

En análisis de negocios: Un DFD lógico puede ayudar a revelar los requerimientos de negocios
que podrían de otra forma pasar inadvertidos hasta muy tarde en el proceso, provocando
retrasos y teniendo que rehacer el trabajo. También sirve como herramienta de comunicación
clara con personas sin conocimientos técnicos involucradas en las actividades de negocios,
tanto para el flujo actual de información como para la nueva forma propuesta. El DFD físico
brinda entonces al sistema el "cómo" impulsar los requerimientos.

En el análisis estructurado: En el análisis estructurado de arriba abajo clásico, se dibuja un

DFD lógico de un sistema actual para describir su estado actual, y luego se modela un sistema
mejorado en un nuevo DFD lógico. Se dibujan luego los DFD físicos de arriba abajo para
mostrar la solución física proyectada de software, dispositivos y otras piezas del sistema. En el
análisis estructurado de abajo hacia arriba orientado a eventos, un DFD contextual (Nivel 0)
establece el alcance del proyecto y los niveles subsiguientes se desglosan en subprocesos.
Luego especificamos los eventos del sistema que requieren una respuesta y se dibujan los
DFD de eventos para representar cómo se maneja cada evento. Estos DFD de eventos se
pueden fusionar luego en un diagrama de sistema.

En la oficina y la administración: Un DFD lógico se usa para representar las acciones de

negocios que ocurren para que una oficina funcione. El nuevo DFD lógico puede entonces
modelar una mejor funcionalidad con los datos de la oficina, tales como información de
personal o información de clientes y pedidos. Forma la base para determinar cómo lograrlo,
mostrado en un DFD físico que indica cómo implementar nuevo software, dispositivos, archivos
de datos o bases de datos y personas.

En la asistencia médica: Un DFD físico actual puede representar el sistema actual del flujo de
datos, por ejemplo, la información de pacientes. Se puede usar eso para dibujar un DFD lógico
actual que muestre las funciones de datos con el "cómo" eliminado. Esos DFD ayudan a crear
un entendimiento claro de las deficiencias y los requerimientos para un nuevo sistema. Eso a
su vez, forma la base de un nuevo DFD lógico y luego un nuevo DFD lógico que represente el
software, los dispositivos, las bases de datos y otros elementos físicos nuevos.