1 Diagramas de Flujo de Datos

1.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.
1.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.

1.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 modelo 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).

Podemos hablar de varios tipos de flujos de datos:

Según dirección/sentido de los datos, respecto al proceso:
 Entrada.

 Salida.
  Diálogo (Entrada y Salida).

 Divergente, Convergente.
Cuando una misma información se envía a procesos diferentes, o cuando una
Información compleja se descompone en varios datos más 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).

• Almacén de datos: El almacén 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 almacén
también puede consistir en datos almacenados en cualquier soporte
que contenga datos (archivos de papel, tarjetas etc).
 • 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 algunos
casos, un terminador puede ser otro sistema con el cual se comunica
éste.

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.

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).

1.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:
 o Función: Verbo + objeto.
o Verbo significativo (Validar, Registrar etc).
o Evitar palabras de uso exclusivo por parte de usuario.
o 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 deben 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 por 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:
o Conseguir un DFD técnicamente correcto.
o Aceptado por el usuario
o Estar lo suficientemente bien dibujado como para que no sea
embarazoso mostrarlo a la dirección de la organización.
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 :

o Evite sumideros infinitos, procesos que tienen entradas pero no salidas.

o Evite burbujas de generación espontánea, procesos que tienen salidas
sin tener entradas. Situación normalmente incorrecta.
o Cuidado con flujos y procesos no etiquetados, ya que puede esconder
errores importantes.
o 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.
o 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.

1.5 Niveles de un DFD

Cuando nos enfrentemos ante un modelo real, nos enfrentaremos ante un DF
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 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.

1.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 cuantos 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
el nivel inmediatamente inferior que la describe.
4. ¿Cómo se muestran los almacenes en los distintos niveles
Introducimos redundancia 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 o más burbujas; luego mostrarlo de nuevo en cada
diagrama de nivel inferior que describa más a fondo dichas burbujas de
interfase. 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.
1.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.

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.
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.

1.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.

1.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

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ísicos 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 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 importarnos los dispositivos 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
un área de la Organización, el analista necesita obtener una visión del sistema.
Primero los elementos físicos: personas, documentos, listados. No es difícil
recordar lugares o personas importantes (' Este trabajo lo realiza Pérez ', ' 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.
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.

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. También se añaden al nuevo DFD los procesos registrar pedido y
encargar recursos a producción.

1.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.

1.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:
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).
1.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 común 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.

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.

1.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.

1.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.
1.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.

1.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.
1.8.10 Evaluación y verificación del diagrama de flujo de datos
Es fundamental verificar con cuidado todos los diagramas 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
(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
1.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.

.com