Análisis y Diseño de Sistemas – Instituto ITEC

Diagramas de flujo de datos.

El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una
red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de
datos. Siendo éste, una de las herramientas más comúnmente usadas, sobre todo por sistemas
operacionales en los cuales las funciones del sistema son de gran importancia y son más complejos que
los datos que éste maneja.

Es importante tener en mente: los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de
proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como
una herramienta para la planeación estratégica y de negocios.

Los componentes de un diagrama típico de flujo de datos:

 Proceso.
 Flujo.
 Almacén.
 Terminador.

Proceso.

El primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja,
función, transformación. El proceso muestra una parte del sistema que transforma entradas en salidas.
El proceso se representa gráficamente como un círculo, como se muestra en figura 4.1.1(a). Algunos
analistas prefieren usar un óvalo o un rectángulo con esquinas redondeadas, como se muestra en la
figura 4.1.1(b). Y otros prefieren usar un rectángulo, como se muestra en la figura 4.1(c). Las
diferencias entre estas tres formas son puramente cosméticas, aunque obviamente es importante usar la
misma forma de manera consistente para representar todas las funciones de un sistema.

Figuras 4.1.1(a),(b)(c): Ejemplos de procesos.

Nótese que el proceso se nombra o describe con una sola palabra, frase u oración sencilla. Un buen
nombre para un proceso generalmente consiste en una frase verbo-objeto tal como validar entradas o
calcular impuesto. En algunos casos, el proceso contendrá el nombre de una persona o un grupo (por
ejemplo, un departamento o una división de una organización), o de una computadora o un aparato
mecánico.

Página 1
Análisis y Diseño de Sistemas – Instituto ITEC

Flujo.

Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo
se muestra en la figura 4.1.2. El flujo se usa para describir el movimiento de bloques o paquetes de
información de una parte del sistema a otra.

Figura 4.1.2: Ejemplo de un flujo.

En la mayoría de los sistemas que modele como analista, los flujos realmente representan datos, es
decir, bits, caracteres, mensajes, números de punto flotante y los diversos tipos de información con los
que las computadoras pueden tratar.

Nótese que el flujo de la figura 4.1.2 tiene nombre. El nombre representa el significado del paquete que
se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo
indica su nombre.

Los flujos muestran también la dirección: una cabeza de flecha en cualquier extremo (o posiblemente
ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o hacia fuera de un
proceso (o ambas cosas). El flujo que se muestra en la figura 4.1.4(a) por ejemplo, indica claramente
que el número se está mandando hacia el proceso denominado Validar números telefónicos. Y el flujo
denominado honorarios de entrega de choferes de la figura 4.1.4 (b) claramente indica que es una salida
generada por el proceso Generar honorarios de entrega de choferes. Los datos que se mueven a lo largo
de dicho flujo viajarán ya sea a otro proceso (como entrada) o a un almacén o a un terminador. El flujo
de dos cabezas que se muestra en la figura 4.1.4 (c) es un diálogo, es decir, un empacado conveniente
de dos paquetes de datos (una pregunta y una respuesta) el mismo flujo. En el caso de un diálogo, los
paquetes de cada extremo de la flecha deben nombrarse, como se ilustra en la figura 4.1.4 (c).

Figuras 4.1.3 (a):Flujo de entrada.

Página 2
Análisis y Diseño de Sistemas – Instituto ITEC

figura 4.1.3 (b):Flujo de salida.

Figura 4.1.3(c): Flujo de diálogo.

Almacén.

El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos
líneas paralelas, como lo muestra la figura 4.1.5. De modo característico el nombre que se utiliza para
identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén
por medio de flujos.

Figura 4.1.5: Representación gráfica de un almacén.

Para el analista con conocimiento de proceso de datos es tentador referirse a los almacenes como
archivos o base de datos; pero un almacén también pudiera consistir en datos almacenados en tarjetas
perforadas, microfilm, microfichas, discos ópticos, etc. y un almacén también puede ser un conjunto de
fichas de papel en una caja de cartón, nombres y domicilios en un directorio, diversos archivos en un
archivero, o varias formas no computarizadas.

Aparte de la forma física que toma el almacén, también existe la cuestión de su propósito: ¿Existe el
sistema por causa de un requerimiento fundamental del usuario o por algún aspecto conveniente de la
realización del sistema?. En el primer caso, la base de datos existe como un área de almacenamiento
diferida en el tiempo, necesaria entre dos procesos que ocurren en momentos diferentes.

Los almacenes se conectan por flujos a los procesos. Así, el contexto en el que se muestra en un DFD
es uno de los siguientes (o ambos):

 Un flujo desde un almacén.

Página 3
Análisis y Diseño de Sistemas – Instituto ITEC

 Un flujo hacía un almacén.

Terminador.

El terminador gráficamente se representa como un rectángulo, como se muestra en la figura 4.1.6. Los
terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente,
puede ser una persona, o un grupo, por ejemplo, una organización externa o una agencia
gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero
fuera del control del sistema que se está modelando. En algunos casos, un terminador puede ser otro
sistema, como algún otro sistema computacional con el cual se comunica éste.

Figura 4.1.6: Representación gráfica de un terminador .

Existen tres cosas importantes que debemos recordar acerca de los terminadores:

 Son externos al sistema que se está modelando.

 Es evidente que ni el analista ni el diseñador del sistema están en posibilidades de cambiar los
contenidos de un terminador o la manera en que trabaja.
 Las relaciones que existan entre los terminadores no se muestran en el modelo de DFD.

Página 4
Análisis y Diseño de Sistemas – Instituto ITEC

Guía para la construcción de DFD.

Además de la regla básica que existen para la elaboración de DFD tal como, los componentes básicos
de DFD son: proceso(burbuja) flujo, almacenes y terminadores. Existen otras reglas adicionales que
nos permitirán no elaborar DFD erróneos y gratos a la vista de los usuarios.

Las reglas incluyen las siguientes:

1. Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.
2. Numerar los procesos.
3. Evitar los DFD excesivamente complejos
4. Redibujar el DFD tantas veces como sea necesario estéticamente.
5. Asegurarse de que el DFD sea lógicamente consistente y que también sea con cualesquiera
DFD relacionados con él.
6. Extensiones del DFD para sistemas de tiempo real

1.- Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.

Un proceso en un DFD puede representar una función que se está llevando a cabo, o pudiera indicar
cómo se está llevando a cabo, identificando a la persona, grupo o mecanismo involucrado.

Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir,
escoja un verbo activo (un verbo transitivo que tenga objeto) y un objeto apropiado para formar una
frase descriptiva para el proceso. Los siguientes son ejemplos de nombres de procesos:

 Calcular trayectoria del proyectil.

 Producir informe de inventario.
 Validar número telefónico.
 Asignar estudiante a la clase.

Los nombres de los procesos (al igual que los nombres de flujos y de terminadores) deben provenir de
un vocabulario que tenga algún significado para el usuario.

2.- Numerar los procesos.

Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas numeran cada
burbuja. No importa mucho como sea haga esto, de izquierda a derecha, de arriba abajo o de cualquier
otra manera servirá, mientras haya constancia en la forma de aplicar los números.

La única cosa que se debe tener en mente es que el sistema de numeración implicará, para algunos
lectores casuales de su DFD, una cierta secuencia de ejecución. Esto es, cuando se muestre el DFD a un
usuario, él pudiera preguntar: ¿Acaso la burbuja número 1 sucede primero, luego la 2 y luego la 3?. Y

Página 5
Análisis y Diseño de Sistemas – Instituto ITEC

esto no es así en absoluto. El modelo de DFD es una red de procesos asincrónicos que se
intercomunican, lo cual es, de hecho, una representación precisa de la manera en la que en realidad
muchos sistemas operan.

Un ejemplo de la funcionalidad de enumerar las burbujas es el siguiente: Es más fácil en una discusión
sobre un DFD decir " burbuja 1" en lugar de "Editar transacción y reportar errores". Pero de mayor
importancia aún es el hecho de que los números se convierten en base para la numeración jerárquica.

3.- Evitar los DFD excesivamente complejos.

El propósito de un DFD es modelar de manera precisa las funciones que debe llevar a cabo un sistema
y las interacciones entre ellas. Pero otro propósito del DFD es ser leído y comprendido, no sólo por el
analista que construyó el modelo, sino por los usuarios que sean los expertos en la materia de
aplicación.

Existe una regla principal para la elaboración de un DFD, que se debe tener en mente: no cree un DFD
con demasiados procesos, flujos, almacenes y terminadores. En la mayoría de los casos, esto significa
que no debería haber más de media docena de procesos y almacenes, flujos y terminadores
relacionados en un solo diagrama.

Existe una excepción importante a esto, un diagrama especial 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.- Redibujar el DFD tantas veces como sea necesario estéticamente.

En un proyecto real de análisis de sistemas el DFD debe dibujarse y volver a dibujar a menudo hasta 10
veces o más, antes de 1) ser técnicamente correcto, 2) ser aceptable para el usuario y 3) estar lo
suficientemente bien dibujado como para que no sea embarazoso mostrarlo a las dirección de la
organización.

¿Qué hace estéticamente agradable a un DFD?. Esto es obviamente una cuestión de gustos y puede
determinarse por normas dispuestas por su organización o por las características particulares de
cualquier paquete que utilice de diseño de diagramas basado en una estación de trabajo automatizada.
Y la opinión de usuario pudiera ser un tanto diferente de la suya; lógicamente, cualesquiera cosas que
el usuario encuentre agradable debe determinar la manera de la que se dibuje el diagrama.

5.- Asegurese de que el DFD sea lógicamente consistente.

Las principales reglas de consistencia son:

Página 6
Análisis y Diseño de Sistemas – Instituto ITEC

 Evite sumideros infinitos, burbujas que tienen entradas pero no salidas.

 Evite las burbujas de generación espontánea, que tienen salidas sin tener entradas, porque son
sumamente sospechosas y generalmente incorrectas.
 Tenga cuidado con los flujos y procesos no etiquetados. Esto suele ser un indicio de falta de
esmero, pero puede esconder un error aún más grave: a veces el analista no etiqueta un flujo o
un proceso porque simplemente no se le ocurre algún nombre razonable.

6.- Extensiones del DFD para sistemas de tiempo real.

Para los sistemas de tiempo real necesitamos alguna manera de 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). Se muestran
gráficamente con líneas punteadas en el DFD.

Página 7
Análisis y Diseño de Sistemas – Instituto ITEC

Diseño de Sistemas

Como analista, puede no sentir interés por los detalles del diseño de sistemas o de programas; sin
embargo, la labor de analista y la del diseñador no siempre se pueden separar debido a que, el analista
debe asegurarse de entender los requerimientos del usuario, mientras que el diseñador debe asegurar
que dichos requerimientos se puedan implantar de manera realista con la tecnología computacional
actual.

Existe otra razón para tener interés en el diseño de sistemas: tal vez le toque hacerlo. Sobre todo en los
sistemas pequeños y medianos, a menudo se espera que el mismo individuo documente los
requerimientos del usuario y además desarrolle el diseño.

La actividad de diseño involucra el desarrollo de una serie de modelos. Los modelos más importantes
para el diseñador son el modelo de implementación de sistemas y el modelo de implementación de
programas. El modelo de implantación de sistemas se divide luego en un modelo de procesador, y uno
de tareas.

En el nivel del modelo del procesador, el diseñador del sistema trata principalmente de decidir como
asignar el modelo esencial a los distintos procesadores(CPU) y como deben comunicarse entre sí.
Existe típicamente una variedad de opciones:

 El modelo esencial completo se le puede asignar a un solo procesador (solución de computadora

principal).
 Cada burbuja de la figura 0 del DFD del modelo esencial se puede asignar a un procesador
distinto (solución distribuida).
 Se pude escoger una combinación de computadoras principales, minis y micros para minimizar
costos, maximizar confiabialidad o lograr algún otro objetivo.

Así como se deben asignar procesos a los componentes apropiados de hardware, los almacenes de datos
se deben igualmente asignar. El diseñador debe de decidir si un almacén se realizará  como base de
datos en el procesador 1 o el 2. Dado que la mayor parte de los almacenes se comparten entre muchos
procesos, también debe decidir si se deben asignar copias del almacén a diferentes procesadores.

En el nivel del modelo de tarea, el diseñador debe, procesador por procesador, asignar procesos y
almacenes a las tareas individuales de cada uno.

Obsérvese que los procesos dentro de un mismo procesador pueden tener necesidad de comunicarse
mediante alguna forma de protocolo de comunicación entre tareas. El mecanismo para hacerlo varía de
un proveedor a otro, pero casi siempre se realiza através del sistema operativo del proveedor.

En el modelo de implementación de programas se llega al nivel de una tarea individual. Dentro de una
tarea individual, la computadora opera de una manera no sincronizada: sólo se pueden llevar a cabo una

Página 8
Análisis y Diseño de Sistemas – Instituto ITEC

actividad a la vez. El modelo más común de organización de la actividad en una sola unidad
sincronizada es el diagrama de estructura, que muestra la organización jerárquica de módulos dentro de
una tarea.

Página 9
Análisis y Diseño de Sistemas – Instituto ITEC

Programación.

La programación comienza cuando termina la actividad de diseño. En esta fase se  involucra la
escritura de instrucciones en C++, Pascal, o algún otro lenguaje de programación para implantar lo que
el analista ha especificado y el diseñador ha organizado en módulos.

Como programadores se pueden enfrentar a los siguientes problemas:

 Productividad: esto es escribir más software, más rápidamente. La principal razón de esto es la
enorme cantidad de sistemas y aplicaciones que siguen en espera en las grandes organizaciones.
 Eficiencia: la eficiencia es de gran importancia en muchos sistemas de tiempo real, y en
sistemas que procesan grandes volúmenes de datos (ejemplo, sistemas en bancos, reservación
en aerolíneas, compañías de bolsas y compañías de seguro). La meta de eficiencia usualmente
entra en conflicto con otras metas discutidas: si se emplea mucho tiempo en la construcción de
un sistema eficiente, es probable que sea menos mantenible y menos transportable, y que tenga
más errores residuales sutiles, además de que tal vez reduzca la productividad de la persona que
escribió el programa.
 Corrección: se podría argumentar que esto es lo más importante. Después de todo, si el
programa no funciona correctamente, no importa que tan eficiente sea. Por ejemplo, se prefieren
lenguajes de programación como Ada y Pascal si la corrección es de importancia crítica, en
caso de que se estuviera construyendo sistemas de la Guerra de las Galaxias o el sistema de
control para un reactor nuclear, porque son de "tipos rígidos".
 Portabilidad: en algunos ambientes esto es importante; el usuario puede desear ejecutar el
mismo sistema en varios tipos distintos de computadoras. Los lenguajes de tercera generación
(C, Pascal, FORTRAN, COBOL, etc.) son más portátiles que los de cuarta generación; aunque
no existe un lenguaje universalmente portátil. Por ello, además del lenguaje de programación
debemos preocuparnos por el estilo de programación, sí la portabilidad es un factor importante.
 Mantenibilidad: como los sistemas viven durante mucho tiempo, por lo tanto el software debe
mantenerse.

Página 10
Análisis y Diseño de Sistemas – Instituto ITEC

Prueba.

En muchos casos, el analista trabaja de manera cercana con el usuario para desarrollar un conjunto
eficaz y de gran alcance de casos de prueba basados en el modelo esencial y el modelo de implantación
del usuario. Este proceso puede llevarse a cabo en paralelo con las actividades de implantación del
diseño y de la programación, para que, cuando los programadores terminen de escribir sus programas y
de realizar sus propias pruebas locales, el equipo del analista/usuario esté listo con sus propios casos de
prueba.

Existen distintas estrategias de prueba, las dos más comunes se conocen como prueba ascendente y
descendente. El enfoque ascendente empieza por probar módulos individuales separadamente (prueba
de módulos). Luego, los módulos individuales se combinan para forma unidades que se probaran en
masas (pruebas de subsistemas). Finalmente, todos los componentes del sistema se combinan para
probarse (prueba del sistema).

El enfoque de prueba descendente empieza con un esqueleto del sistema; es decir, la estrategia de
prueba supone que se han desarrollado los módulos ejecutivos de alto nivel del sistema, pero que los de
bajo nivel existen sólo como módulos vacíos; un ejemplo de módulo vacío es uno que no procesa nada,
sino que simplemente termina luego de ser llamado.

También existen diferentes tipos de pruebas, tales como:

Prueba funcional: Su propósito es asegurar que el sistema realiza sus funciones normales de
manera correcta. Así, los casos de prueba se desarrollan y se alimentan al sistema; las salidas se
examinan para ver si son correctos.

Prueba de recuperación: El propósito de este tipo de prueba es asegurar que el sistema

pueda recuperarse adecuadamente de diversos tipos de fallas, como: fallas de hardware, fallas
de corriente, fallas en el sistema operativo, etc.

Prueba de desempeño: El propósito de este tipo de prueba es asegurar que el sistema pueda
manejar el volúmen de datos y transacciones de entrada especificados en el módulo de
implantación del usuario, además de asegurar que tenga el tiempo de respuesta requerido.

Para poder realizar una excelente prueba se necesita de tres cosas: un plan de prueba, descripciones de
pruebas y procedimiento de prueba. Un plan de prueba es un documento organizado que describe las
actividades de prueba. Un documento de planeación de pruebas típico contendrá la siguiente
información:

 Propósito de la prueba: cuál es el objetivo de la prueba, y qué parte del sistema se está
probando.
 Localización y horario de la prueba: dónde y cuando se hará.

Página 11
Análisis y Diseño de Sistemas – Instituto ITEC

 Descripción de la prueba: descripción de las entradas que se proporcionarán al sistema, y las

salidas y resultados que se anticipan.
 Procedimiento de prueba: descripción de cómo se deben preparar y presentar los datos de
prueba al sistema; cómo capturar los resultados de salida, cómo analizar los resultados de las
pruebas, y cualesquiera otros procedimientos operacionales que se deben observar.

Página 12