Diagramas de Flujo de Datos

4 Diagramas de Flujo de Datos

4.1 Concepto
Los diagramas de flujos de datos (DFD), es una técnica de modelización, que nos
muestra un sistema como una red de procesos conectados entre ellos por flujos y
almacenamientos de datos.

Es un modelo que proporciona el punto de vista funcional de un sistema.

4.2 ¿Por qué análisis de flujo de datos?

Los analistas deben trabajar con los usuarios para hacerles comprender el
funcionamiento del sistema actual y el sistema futuro, para ello se hace aconsejable utilizar
un lenguaje común, sencillo y fiable, estas son las características de los diagramas de flujo
de datos. Los usuarios pueden hacer sugerencias para modificar los diagramas con la
finalidad de describir las actividades con mayor exactitud, y permitirá evitar los errores
desde el inicio pudiendo prevenir una posible falla del sistema.

Página -1-
Diagramas de Flujo de Datos

4.3 Notación de los Diagrama Flujo de Datos

Los métodos para el análisis de flujo de datos fueron desarrollados y promovidos por
dos organizaciones al mismo tiempo, Yourdon Inc (compañía de consultoría) y Mc
Donnell-Douglas (Gane and Sarson). En nuestro libro la notación utilizada será la de
Yourdon . Los DFD’s se pueden dibujar con sólo cuatro elementos gráficos sencillos, que
son:
♦ Procesos: El primer componente del DFD. El proceso muestra una parte del
sistema que transforma entradas en salidas, suelen ser personas,
procedimientos o dispositivos que utilizan o transforman datos. El proceso se
representa gráficamente como un círculo. Los sinónimos comunes son
burbuja, función o transformación.

figura 1: Proceso

♦ Flujo de datos: Se representa gráficamente por medio de una flecha que entra
o sale de un proceso. El flujo se usa para describir el movimiento de bloques
de información de una parte del sistema a otra. Por ello, los flujos representan
datos en movimiento, mientras que los almacenes representan datos en reposo.
En algún módelo puede representar movimiento de material. Los flujos
muestran la dirección; según si los datos se está moviendo hacia adentro o
hacia afuera de un proceso (o ambas cosas).

figura 2: Flujo de datos

Página -2-
 Diagramas de Flujo de Datos

Podemos hablar de varios tipos de flujos de datos:

◊ Segun dirección/sentido de los datos, respecto al proceso:

◊ Entrada.

número telefónico Validar

Numero
Telefónico

figura 3: Flujo de Entrada

◊ Salida.

Generar
Itinerario Itinerario Conductor
Conductor

figura 4: Flujo de Salida

◊ Diálogo (Entrada y Salida).

Determ. Pregunta sobre

Estado de estado de pedido
un pedido
Respuesta estado de
un pedido

figura 5: Flujo de diálogo

◊ Divergente, Convergente.
Cuando una misma información se envía a procesos diferentes, o cuando una
información compleja se descompone en varios datos mas sencillos cada uno
de los cuales va a un proceso diferente (divergente). Varios paquetes de datos
se juntan para formar parte de paquetes de datos mas complejos
(convergente).

Página -3-
Diagramas de Flujo de Datos

Código Postal
Domicilio del
usuario

Número telefónico

Calle

figura 6: Flujo divergente

♦ Almacen de datos: El almacen se utiliza para modelar una colección de datos

en reposo. Se representa por dos líneas paralelas. Es tentador asociar a los
almacenes los archivos o bases de datos, es así como a menudo se implantan
en un sistema informático, pero un almacen también puede consistir en datos
almacenados en cualquier soporte que contenga datos (archivos de papel,
tarjetas etc).

figura 7: Almacenamiento

♦ Entidad (Terminador): El siguiente componente del DFD es un terminador ;

representado gráficamente como un rectángulo representan fuentes (origen) o
destinos externos de datos que pueden ser: personas, programas,
organizaciones u otras entidades que interactúan con el sistema pero se
encuentran fuera de su frontera. En algun casos, un terminador puede ser otro
sistema con el cual se comunica éste.

figura 8: Entidad Externa o Terminador

Página -4-
 Diagramas de Flujo de Datos

Existen tres cosas importantes que debemos recordar acerca de los

terminadores :

◊ Son externos al sistema que se está modelando ; los flujos que conectan
los terminadores a diversos procesos (o almacenes) en el sistema
representan la interfaz entre él y el mundo externo.
◊ El analista de sistemas no puede modificar los contenidos, la
organización ni los procedimientos internos asociados en posibilidades
de cambiar los contenidos de un terminador o la manera en que trabaja.
El terminador con lo que representa está fuera del dominio.
◊ Las relaciones existentes entre los terminadores no se muestran en el
modelo DFD. Si existen relaciones entre los terminadores y si es
esencial para el analista modelarlos para poder documentar los
requerimientos y si es esencial para el analista modelarlos para poder
documentar los requerimientos del sistema, entonces ,por definición ,los
terminadores son en realidad parte del sistema y debieran modelarse
como procesos.

Deberemos respondernos una serie de preguntas como ¿cómo se piden los datos?,
¿en qué secuencia se reciben los datos?, ¿en qué secuencia se generan?, no deben ser
respuesta de los DFD´s, estas respuestas forman parte del procedimiento.

Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre
descriptivo. Los nombres de los procesos también reciben un número para poder
identificarlo.

ENTIDAD PROCESO 1 ENTIDAD

DDD
FLUJO 1 FLUJO 4

FLUJO 2 FLUJO 5
FLUJO 3

PROCESO 2

ALMACEN DE DATOS

figura 9: Componentes de un Diagrama de Flujo de Datos

Los diagramas de flujo de datos se concentran en el movimiento de datos a través del

sistema, no en los dispositivos o el equipo. Se identifican y describen los datos que fluyen
por todo el sistema, explicando porque los datos entran o salen y cual es el procesamiento
que se realiza con ellos (guardan y recuperan de almacenamiento de datos).

Página -5-
Diagramas de Flujo de Datos

4.4 Directrices para la construcción de DFD´s

Hay una serie de reglas que son necesarias para poder construir los DFD's
correctamente. La finalidad de estas reglas es ayudar a confeccionar DFD`s correctos, y
permitir dibujar un DFD agradable a la vista y por tanto que tenga mas probabilidades de
que sea estudiado por el usuario con el objetivo de ayudarle a su comprensión.

Las reglas a seguir para la construcción de un DFD son:

1. Elegir los nombres representativos para los procesos, flujos de datos,
almacenamientos y entidades externas de forma que describa lo mas
precisamente posible al objeto que representa.
En el caso de los procesos debemos identificar las funciones que el sistema
está llevando a cabo, es decir el nombre del proceso describirá lo que se
hace:

◊ Función: Verbo + objeto.

◊ Verbo significativo (Validar, Registrar etc).
◊ Evitar palabras de uso exclusivo por parte de usuario.
◊ Evitar terminología informática (Rutina,Procedimiento etc).

2. Numerar los procesos para identificarlos de forma rápida y unívoca.

Los números no indican secuencia. El modelo de DFD es una red de procesos
asincrónicos que se intercomunican, lo cual es, una representación precisa de
la manera en la realidad muchos sistemas operan. El hecho que exista
procesos no pueda realizar su función por falta de algún dato de otro proceso
no implica correspondiente con la numeración. Son la base para crear la
jerarquía de diagramas cuando se introduzcan los diagramas de flujo por
niveles.
3. Evitar DFD excesivamente complejos y recargados, es decir, con muchos
elementos gráficos juntos.
El propósito de un DFD es modelar de forma precisa las funciones que debe
llevar a cabo un sistema y las interacciones entre ellas. Pero otro propósito del
DFD, de igual importancia, es que sea leído y comprendido, no sólo pr el
analista que construyo el modelo, sin por los usuarios que sean los expertos
en la materia de aplicación. Esto significa que el diagrama debe ser fácilmente
entendido, fácilmente asimilado y placentero a la vista.
Existe una excepción, un DFD conocido como diagrama de contexto, que
representa el sistema entero como un solo proceso y destaca las interfaces
entre el sistema y los terminadores externos.
4. Consolidar flujos para ganar en legibilidad.
5. Redibujar el DFD tantas veces como sea necesario, con el objetivo de:

◊ Conseguir un DFD técnicamente correcto.

◊ Aceptado por el usuario
◊ Estar lo suficientemente bien dibujado como para que no sea
embarazoso mostrarlo a la dirección de la organización.

Página -6-
 Diagramas de Flujo de Datos

6. Asegurarse que el DFD es consistente.

Existen reglas para asegurar la consistencia del DFD con otros modelos de
sistemas ; el diagrama de entidad-relación, diagrama transción de estados,
diccionario de datos, y la especificación de procesos. Las principales reglas de
consistencia son :
◊ Evite sumideros infinitos, procesos que tienen entradas pero no salidas.
◊ Evite burbujas de generación espontánea, procesos que tienen salidas
sin tener entradas. Situación normalmente incorrecta.
◊ Cuidado con flujos y procesos no etiquetados, ya que puede esconder
errores importantes.
◊ Tener cuidado con los almacenes de “sólo lectura” o “sólo escritura”.,
ya que todo almacenamiento debe tener un flujo entrante y uno saliente,
es decir, la información se almacena se consume.
◊ Las entidades externas no pueden acceder directamente a ningún
almacenamiento. Siempre debe mediar un proceso que haga de
intermediario y extraiga o inserte la información pertinente.

SUMIDERO INFORMACION FUENTE INFORMACION

PROCESO(1/2)
PROCESO(2/2)

figura 10 : Sumidero y Fuente de Información

4.5 Niveles de un DFD

Cuando nos enfrentemos ante un modelo real, nos enfrentaremos ante un DFD
grande y complejo. Deberemos evitar diagramas complejos y poco legibles, de acuerdo
pero ¿cómo ?. Si el sistema es intrínsecamente complejo y tiene decenas de funciones que
?.

La respuesta es organizar el DFD global en una serie de niveles de modo que cada
uno proporcione sucesivamente más detalles sobre una porción del nivel anterior. Esto es

Página -7-
Diagramas de Flujo de Datos

análogo a la organización de mapas en una atlas, de modo que un mapa global nos muestra
un país completo, pero los mapas subsecuentes mostrarían los detalles de los países
individuales, los estados individuales dentro de los países.

La división consiste en construir una jerarquía de diagramas, en donde cada nivel

inferior es una expansión de un proceso del nivel superior.

El DFD de primer nivel consta de una sola burbuja, y representa el sistema de

información completo, como un todo ; los flujos de datos muestran las interfaces entre el
sistema y las entidades externas. Este DFD especial se conoce como diagrama de contexto
o nivel 0 .

El nivel 1, que sería el siguiente nivel inferior en la jerarquía, descompondría ese

macro proceso, que representa a todo el sistema, en las actividades principales que lo
componen, así como los almacenamientos generales que existan. A continuación se sigue el

De modo que se construirá una jerarquía de diagramas, en donde cada nivel inferior
es una expansión de un proceso del nivel superior.

4.6 Construcción de los niveles del DFD

Como podemos ver lo que se pretende es descomponer un todo en piezas con el
objetivo de reducir la complejidad. Pero debemos responder una serie de cuestiones :

1. ¿ Cómo saber cúantos niveles debe haber en un DFD ? No hay ninguna regla
para decidir cuantos niveles ha de tener un DFD. Pero dado que un DFD es
aconsejable que no tenga mas de media docena de burbujas y almacenes
relacionados, si nos aparece un nivel que contenga un número muy superior
deberemos insertar un nuevo nivel a los que hubiere. Hay que procurar que
haya equilibrio en la distribución de todos los elementos gráficos entre todos
los niveles del DFD.
2. ¿Deberemos de dividir todas las partes del sistema con el mismo nivel de
detalle ? La respuesta será que no. Algunas partes del sistema pueden ser más
complejas que otras y pueden requerir uno o más niveles de partición. En el
caso que nos encontremos con desigualdades respecto a la división de un
procesos respecto a otros, deberemos nivelar el DFD para lograr un
equilibrio.
3. ¿Cómo nos aseguraremos que los niveles del DFD son consistentes entre sí ?
Esta cuestión es importante, ya que normalmente existe un desarrollo entre
distintas personas en un proyecto real, así como una división del trabajo. Para
asegurarse que cada figura es consistente con su figura de más alto nivel se
sigue una regla sencilla : los flujos entrantes y salientes de una burbuja en un
nivel dado deben corresponder con los que entran y salen de toda la figura en

Página -8-
 Diagramas de Flujo de Datos

el nivel inmediatamente inferior que la describe.

4. ¿ Cómo se muestran los almacenes en los distintos niveles
introducimos redunadancia deliberadamente en el modelo. La regla es la
siguiente: mostrar un almacén en el nivel más alto donde primeramente sirve
de interfaz entre dos omás burbujas; luego mostrarlo de nuevo en cada
diagrama de nivel inferior que describa más a fondo dichas burbujas de
interface. Por lo tanto los almacenes locales, que utilizan sólo las burbujas en
una figura de menor nivel, no se mostrará en niveles superiores, dado que se
incluyen de manera implícita en un proceso del nivel inmediato superior.
5. ¿Cómo se realiza de hecho la partición de los DFD en niveles? La situación
que nos imaginamos como ideal es la de comenzar con el diagrama de
contexto y luego desarrollar cada figura para trabajar de forma progresiva
hasta los niveles de bajo nivel. Sin embargo éste planteamiento nos dará
problemas, de modo que el enfoque mmás aconsejable es identificar los
acontecimientos externos a los cuales debe responder el sistema y crear un
primer DFD borrador. Veremos como esta primera aproximación del DFD
puede suponer un punto de partida hacia arriba o hacia abajo.
6. Para decidir cuál es el último nivel no debemos seguir profundizando mientras
halla procesos que puedan ser descompuestos en subprocesos, ni entrar en
descripciones de tal detalle sobre los procesos que estemos desarrollando su
algoritmo. Es decir, los últimos niveles del DFD no deben convertirse en un
organigrama del algoritmo de cada proceso.

4.7 Explosión de un proceso

A medida que vayamos conociendo mas las actividades de un proceso, podemos
representarlas con otro DFD. Para ello seguiremos las siguientes normas:
1. Se debe explosionar un solo proceso cada vez. Por ejemplo, consideremos el
proceso 3 de la figura 11 como un proceso n genérico.
A

1 2

X Y

3 4
Z
(n)

figura 11: Diagrama de nivel 1

Página -9-
Diagramas de Flujo de Datos

2. Se representa una caja de proceso grande para ver con mas detalle su
funcionamiento.
3. Todos los procesos a que da lugar la explosión del proceso n, se van
numerando como n.1, n.2, n.3, n.4, etc.
4. Todos los flujos de datos que llegaban al proceso n tienen que llegar al
conjunto n.1, n.2, n.3, etc. Aplicando estas normas a la explosión del proceso
3 obtendríamos el resultado de la figura 12.

3.1

3.2

3.3

3.4

Z
Y

figura 12: Explosión proceso 3

5. Todos los flujos de datos que salían del proceso n tienen que salir del conjunto
n.1, n.2, n.3, etc.
6. Al estudiar en más detalle el funcionamiento del proceso n, y tener en cuenta
el tratamiento de errores y excepciones es posible que surjan nuevos flujos de
datos del conjunto del procesos explosionados con el exterior.
Si estos flujos son fruto del tratamiento de errores figura 11 y excepciones se
marcan con una X para resaltar el hecho de que no tienen que aparecer en el
DFD original (donde se definió el proceso n).
Si hay otros flujos adicionales con el exterior se tendrían que reflejar en el
DFD original.
7. En la explosión pueden aparecer almacenamientos de datos privados, es decir
que son utilizados exclusivamente por los procesos n.1, n.2, n.3, etc. Estos
almacenamientos quedan reflejados dentro del marco del proceso n y se
identifican como Dn.1, Dn.2, Dn.n, etc.
8. Todas las entidades externas han de estar fuera del marco de la explosión.

Página -10-
 Diagramas de Flujo de Datos

4.8 Desarrollo de DFD’s

El primer paso es hacer un estudio del sistema actual (estudio del sistema físico). El
sistema físico se traslada en una descripción lógica que se centra en datos y procesos.
Durante el análisis de flujo de datos se evalúan todos los detalles en términos de los
componentes lógicos de flujos de datos, procesos y almacenes de datos, orígenes y
destinos. En la fase de implementación, las especificaciones lógicas son trasladas en

4.8.1 Tipos de diagramas de flujo de datos

Los diagramas de flujo de datos son de dos tipos:

1. Diagramas físicos de flujo de datos.
Proporcionan un panorama del sistema en uso, muestra las tareas que se
llevan a cabo y como se hacen. Las características físicas incluyen:
♦ Nombre de personas
♦ Nombre o formatos de documentos
♦ Nombres de departamentos
♦ Archivo de maestro y de transacciones
♦ Equipo y dispositivos utilizados
♦ Ubicaciones
El empleo de estos diagramas es aconsejable por tres razones:
♦ Para los analistas de sistema es mas fácil describir la interacción
entre los componentes físicos que comprender las políticas
empleadas. De modo que identifican las personas, lo que hacen,
los documentos que inician las actividades y el equipo para su
procesamiento.
♦ Los diagramas físicos de flujos de datos son de utilidad para
comunicarse con los usuarios. Estos relacionan con facilidad alas
personas, las ubicaciones y los documentos ya que trabajan todos
los días con estas entidades (Los diagramas lógicos van a resultar
abstractos para los usuarios).
♦ Los diagramas fisicos proporcionan un camino para validar o
verificar el punto de vista del usuario sobre la forma en que opera
el sistema en uso.
2. Diagramas lógicos de flujo de datos.
Proporcionan un panorama del sistema independiente de la implantación, que
se centra en el flujo de datos entre los procesos sin considerar los dispositivos
específicos y la localización de almacenes de datos o personas en el sistema.
Los diagramas físcos de flujos de datos, no son un fin en si mismos, sino son
un medio para describir la implantación del sistema existente. El diagrama
lógico es un visión retrosprectiva de la implantación actual y proporciona la

Página -11-
Diagramas de Flujo de Datos

base para examinar la combinación de procesos, flujo de datos, almacenes de

datos, entradas y salidas sin importarnos los dipositivos físicos, personas o
aspectos de control que caracterizan la implantación.
Así que el diagrama lógico se obtiene del diagrama físico al llevar a cabo lo
siguiente:
♦ Señalar los datos necesarios en este momento para un proceso, no
documentos que los contienen.
♦ Indicar los flujos entre los procedimientos y no entre
personas,oficinas o localidades.
♦ Eliminar herramientas y dispositivos.
♦ Eliminar información de control.
♦ Consolidar los almacenes de datos redundantes.
♦ Eliminar los procesos innecesarios (v.gr los que no cambian los
datos, independientes de los dispositivos donde ocurren, los que
representan un proceso único dentro del sistema).

Cuando se inicia el estudio de sistemas en una area de la Organización, el analista

necesita obtener una visión del sistema. Primero los elementos físicos: personas,
documentos, listados. No es dificil recordar lugares o personas importantes (' Este trabajo
lo realiza Perez ', ' La autorización del pago de facturas se realiza en el departamento de
contabilidad ', etc.). Los diagramas físicos representan estos elementos.

Una vez superada esta primera fase de conocimiento del sistema actual, es necesario
descifrar los aspectos más importantes de cada actividad. Los diagramas lógicos nos
permiten describir los datos, procesos y eventos de forma abstracta, ya que el analista debe
conocer el trabajo que debe realizarse mas que las personas que en la actualidad lo
realizan. Los analistas generalmente comienzan por la construcción de un modelo físico
por que los componentes físicos se pueden identificar realmente durante el análisis y
después lo convierten a un modelo lógico. Pero veamos como podemos hacer esto con un
ejemplo:

Partamos del siguiente DFD físico de la figura 13, donde podemos apreciar dos
componentes físicos:
♦ el encargado de recepción, que recibe un pedido y lo verifica para determinar
si es del tipo que fabrica la organización. Si la respuesta es no, el pedido no se
acepta; si es sí, pasa a la sección de producción.
♦ sección de producción, que comprueba si la máquina para hacer el pedido
está disponible. Si no, el pedido no se acepta; en otro caso, se encargan los
recursos para la producción del pedido.

Página -12-
 Diagramas de Flujo de Datos

Clasificar
por áreas
Pedido
2
Pedido no comprobado
aceptado
CLIENTES
Encargado
Pedidos
de
Pedido clasificados
Recepción
1

Imposible
servir pedido Enviar a
Pedidos sección de
despachados producción
3
Sección de
producción
4

figura 13: DFD físico sistema de pedidos

Durante la conversión, primero se pasan todos los procesos que hacen referencia a
actividades físicas, en el ejemplo y enviar a la sección de
producción.

El resto de los procesos físicos se expanden después dentro de sus funciones lógicas.
Para ello se toma cada proceso físico, se busca qué es lo que hace y se reemplaza por un
DFD de funciones lógicas expandido que represente las actividades de un objeto físico. En
la figura 19 podemos apreciar como el encargado de recepción se reemplaza por dos
funciones que son registrar pedido y comprobar tipo de pedido. De la misma forma
sección de producción es reemplazado por sus dos funciones comprobar recursos
disponibles y encargar recursos a producción.

Página -13-
Diagramas de Flujo de Datos

Pedido no aceptado

CLIENTES Pedido Comprobar

Registrar
Pedido recibido Pedido
Pedido
1.1 1.2

Pedido
comprobado
PEDIDOS

Comprobar
Pedido aceptado recursos
disponibles
4.1
Encargar
recursos a Imposible
producción servir
4.2 pedido
RECURSOS

CLIENTES

figura 14: Conversión al DFD lógico

Después se examina este último DFD, y cualquier función común o similar se

combina para formar un proceso de nivel más alto que se convierte el DFD superior, en la
figura 14 podemos apreciar como los procesos comprobar pedido y comprobar recursos
disponibles se combinan en uno sólo pues tiene un propósito similar dando como resultado
el proceso comprobar factibilidad producción.

Página -14-
 Diagramas de Flujo de Datos

También se añaden al nuevo DFD los procesos registrar pedido y encargar

recursos a producción.

Imposible producir

CLIENTES Pedido Comprobar

Registrar
Pedido recibido Factibilidad
Pedido
Producción
1
2

Pedido
aceptado
PEDIDOS RECURSOS

Encargar
Recursos a
Producción
3

figura 15: DFD lógico sistema de pedidos

4.8.2 Deducción del diagrama lógico

Los diagramas físicos de flujo de datos son un medio para alcanzar un fin, no un fin
en sí mismos. Se elaboran para describir la implantación del sistema existente, con el
objetivo de tener la comprensión correcta de la implantación real del sistema existente.

El panorama lógico es una visión retrospectiva de la implantación actual y

proporciona la base para examinar la combinación de procesos, flujo de datos, almacenes
de datos, entradas y salidas sin tomar en cuenta dispositivos físicos, personas o aspectos de
control que caracterizan la implantación.

4.8.3 Reglas generales para el dibujo de diagramas lógicos de flujo

de datos

Las reglas a tener en cuenta, para el dibujo de los diagramas lógicos de flujo de
datos:

Página -15-
Diagramas de Flujo de Datos

1. Cualquier flujo de datos que abandone un proceso debe estar basado en los
datos que entran al proceso.
2. Todos los flujos de datos reciben un nombre, el nombre refleja los datos que
fluyen entre procesos, almacenes de datos, fuentes o destinos.
3. Sólo deben entrar al proceso los datos necesarios para llevarlo a cabo.
4. Un proceso no debe saber nada de ningún otro en el sistema, es decir debe ser
independiente, la única dependencia que debe existir es aquella que esté
basada en sus propios datos de entrada y salida.
5. Los procesos siempre están en continua ejecución, no se inician, ni tampoco
se detienen.
6. La salida de los procesos puede tomar una de las siguientes formas:
♦ Flujo de datos con información añadida por el proceso (v.gr
anotación en la factura).
♦ Una respuesta o cambio en la forma de los datos (v.gr cambio en
la forma de expresar los datos).
♦ Un cambio de condición (v.gr de no autorizado a autorizado).
♦ Un cambio de contenido (v.gr integración o separación de la
información contenida en uno o mas flujos entrantes de datos).
♦ Cambios en la organización (v.gr separación física o reacomodo
de datos).

4.8.4 Expansión de los procesos para mayor detalle

Dado que la información contenida en el diagrama de contexto, es inadecuada para

explicar en su totalidad los requerimientos del sistema, es deseable describir el panorama
lógico del procesamiento de facturas por pagar con mayor detalle.

Para identificar los procesos utilizamos los números 1.0, 2.0 y 3.0. Podemos hacer
referencia por su número (1.0) o por su nombre (Autorización de facturas).

Los diagramas de flujo de datos no tienen utilidad si se dibujan en forma inapropiada

o ser manejan sin cuidado. Aunque no hay leyes que establezcan el número de niveles, el
número de procesos por niveles, la norma comun es definir cada nivel inferior en términos
de tres a siete de procesos por cada proceso de nivel superior. La utilización de mas de
siete procesos hace que el diagrama sea difícil de manejar y dibujar.

Lo importante es entender que los diagramas de flujo de datos lógicos son una
herramienta de ayuda para ayudar la comprensión del sistema de la Organización. De
modo que un diagrama deja de ser útil cuando no es comprensible. Por lo tanto, debe
primar el sentido común, y no determinar normas estrictas para su construcción.

Página -16-
 Diagramas de Flujo de Datos

4.8.5 Mantenimiento de la consistencia entre procesos

Si comprobamos el diagrama de contexto, y el diagrama de primer nivel (figura 17),

el primer proceso tiene el mismo flujo de entrada (factura del proveedor), así como el flujo
de salida (cheque), esto se debe a que la explosión es consistente; los flujos de entradas o
salidas del proceso de nivel superior están presentes en el diagrama de nivel inferior, y
apareciendo nuevos flujos, almacenes. Esto es precisamente uno de los puntos importantes
de la expansión hacia niveles inferiores: encontrar mas detalles relacionados con los
procesos internos.

4.8.6 Convenciones de nivelación significativas

Nivelación es un término que se refiere al manejo de archivos locales (los empleados

dentro de un proceso). Los detalles relacionados con un solo proceso en un determinado
nivel deben permanecer dentro del proceso. Los almacenes y flujos de datos que son
relevantes únicamente para el interior del proceso, son ocultados hasta que el proceso se
extiende con mayor detalle.

Si nos fijamos en el diagrama de contexto, aparece un almacenamiento de datos

(datos del vendedor). Este almacén se crea fuera del sistema de facturas por pagar. Por
otro lado los almacenes de datos de facturas por pagar, órdenes de compra y cuentas por
pagar están contenidos dentro del proceso, y aparecen en el próximo nivel cuando se
expansione el proceso. La convención de nivelación señala que estos almacenes son
internos al proceso, no entradas para él.

4.8.7 Añadir los controles sólo en los diagramas de bajo nivel

Hasta el momento los diagramas de flujos de datos desarrollados no incluyen

información sobre controles. No se hace referencia sobre como manejar errores o
excepciones, por ejemplo como procesar facturas incorrectas. Aunque esta información no
es importante para identificar todos los flujos de datos, deben aparecer en segundo o tercer
nivel deben aparecer el manejo de errores y excepciones del proceso.

En nuestro ejemplo, podemos comprobar la figura 18 para el proceso de

Autorización de factura. Se incluyen el control de excepciones de facturas sin firma, o
facturas de compra sin pedido.

Los errores mas comunes cometidos al incluir los controles físicos en los diagramas
lógicos de flujo de datos. Por ejemplo: El copiado de números para documentos (copia
1,copia 2, copia para contabilidad), de instrucciones (encontrar el registro, revisar el
registro), o días para el inicio de actividades (hacerlo el lunes) no tienen nada que ver con
los aspectos lógicos y de datos de determinación de requerimientos.

Página -17-
Diagramas de Flujo de Datos

4.8.8 Asignar etiquetas significativas

Todos los flujos de datos deben tener un nombre que refleje con exactitud su
contenido. Los nombres dados a los flujos de datos deben reflejar los datos de interés para
los analistas, no los documentos o el lugar donde residen. Por ejemplo, una factura
contiene varios elementos diferentes de información. Los analistas están interesados en
aquellos que son importantes para un proceso en particular. Estos pueden ser el número de
la factura y la fecha de expedición, o la firma de autorización de la factura. Lo importante
no es la hoja de papel. Los datos que fluyen hacia los procesos experimentan cambios. Por
consiguiente, el flujo de datos de salida tiene un nombre diferente al de entrada.

4.8.9 Asignar de nombre a los procesos

Se deben asignar nombre a todos los procesos que les digan a los usuarios algo
específico con respecto a la naturaleza de las actividades del proceso. Los nombres Control
de Inventarios, Compras y Ventas, es mejor utilizar Ajustar cantidad, preparar orden de
compra o corregir pedido de ventas.

Consideraciones para dar nombre de los procesos:

1. Seleccionar nombres que indiquen la acción que se lleva a cabo. Lo mas
apropiado es escoger un verbo y un objeto que reciba la acción del verbo.
2. Asegurar que el nombre describa completamente el proceso. (Si un proceso
edita y valida los datos de una factura, no se puede dar el nombre de Edición
de facturas).
3. Seleccionar nombres para los procesos que expliquen el enlace entre los flujos
de entrada y salida.
4. Evitar nombres vagos como proceso, revisión, reunir u organizar.
5. Utilizar los nombres de los procesos de bajo nivel ya que estos son mas
específicos y descriptivos que los asociados con los procesos de alto nivel.
6. Asignar nombres a los procesos que sean únicos para la actividad que ellos
describen.

También hemos hablado de numerar los procesos con los números 1, 2, 3, 4 y 5. Los
procesos generados con la expansión de cada uno de ellos sen los niveles inferiores se les
asigna un decimal para indicar que son descripciones detalladas de un proceso de nivel
superior.

4.8.10 Evaluación y verificación del diagrama de flujo de datos

Es fundamental verificar con cuidado todos los diagrmas de flujo para determinar si
son correctos. La presencia de lo que parece ser un error señale una deficiencia en el
sistema. Debemos hacernos una serie de preguntas, que nos sirvan de ayuda para evaluar
los diagramas de flujo de datos:
1. ¿Existen en el diagrama de flujo de datos componentes que no tienen nombre

Página -18-
 Diagramas de Flujo de Datos

(flujo de datos, procesos, almacenamientos, entradas o salidas)?

2. ¿Existen almacenes de datos que son entradas y a los que nunca se hace
referencia?
3. ¿Existen procesos que no reciben entradas?
4. ¿Existen procesos que no generan salida?
5. ¿Exsiten procesos que tienen varias finalidades?
6. ¿Existen almacenes de datos a los que no de referencien?
7. ¿Existen demasiados atributos en el almacen de datos (mas que los detalles
necesarios)?
8. ¿El flujo de datos que llega a un proceso es demasiado extenso para la salida

4.9 DFD PARA SISTEMAS EN TIEMPO REAL.

Los flujos vistos hasta ahora, son simplemente los conductos a lo largo de los cuales
viajan los paquetes de datos entre procesos y almacenes. Podemos considerar las burbujas
de los DFD como procesadores de datos. Hay una clase de sistemas, los de tiempo real, en
los que necesitamos modelar flujos de control (es decir señales o interrupciones). Y se
requiere una manera de mostrar procesos de control (esto es, burbujas cuya única labor es
coordinar y sincronizar las actividades de otras burbujas del DFD). Un flujo de control
puede imaginarse como un conducto que porta una señal binaria (esto es, está encendido o
está apagado). A diferencia de otros flujos que se discuten en este capítulo, el flujo de
control no porta datos con valores. El flujo de control se manda de un proceso a otro (o de
algún terminador externo a un proceso) como una forma de decir que se inicie el proceso.
Un proceso de control puede considerarse como una burbuja ejecutiva, cuya función es
coordinar las actividades de otras burbujas en el diagrama ; sus entradas y salidas
consisten sólo en flujos de control. Los flujos de control salientes del proceso de control se
utilizan para despertar a otras burbujas ; los flujos de control entrantes generalmente
indican que una de las burbujas ha terminado su labor o que se ha presentado alguna
situación extraordinaria, de la cual necesita informarse a la burbuja de control. Por lo
común sólo hay un proceso de control de estos en un DFD dado.

Página -19-
Página -21-