INSTITUTO TECNLOLGICO DE ZACATECAS

INGENIERA INFORMTICA.

Fundamentos de sistemas de informacin

.
Integrantes:

Alan De La Rosa Cabrera.

Grupo: A
Fecha: 20/09/2016

4.1 Enfoque estructurado:

En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos) como

principal herramienta para entender al sistema antes de plasmarlo a cdigo fuente
El DFD (Data Flow Diagram) surgi de la necesidad de un nuevo mtodo de
especificacin sencillo de implantar, fcil comprensin y comunicacin.
El DFD fue desarrollado por De Marco en los aos 70s y fue popularizado por
Yourdan. Es un mtodo de especificacin utilizado hasta la fecha. Para empezar
se puede preguntar Que son los diagramas de flujos de Datos?
Un diagrama de flujo de datos (DFD) es una representacin grfica de los
procesos que se realizan con los datos en su organizacin, con el uso de tan solo
cuatro smbolos, se puede crear una descripcin grafica de los procesos que, con
el tiempo, contribuirn a desarrollar una slida documentacin del sistema.
En seguida mencionan las ventajas sobre las explicaciones descriptivas en
relacin con la forma en que los datos se mueven a travs del sistema:
1. Libertad para emprender la implementacin tcnica del sistema en las
primeras etapas.
2. Comprensin ms profunda de la interrelacin entre sistemas y
subsistemas.
3. Comunicacin con los usuarios sobre el conocimiento del sistema actual
mediante diagramas de flujos de datos.
4. Anlisis de un sistema propuesto para determinar si se han definido los
datos y procesos necesarios.
La ventaja ms grande es la libertad conceptual para utilizar los cuatro smbolos,
los DFDs hacen nfasis en el procesamiento o la transformacin conforme estos
pasan por una variedad de procesos. En los DFDs lgicos no hay distincin entre
procesos manuales o automatizados. Los procesos tampoco se representan
grficamente en orden cronolgico. En vez de ello, se agrupan solo si el anlisis
detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y
los procesos automatizados tambin se pueden agrupar.

4.1.1. Simbologa:

En los diagramas de flujos de datos se usan cuatro smbolos bsicos para graficar
el movimiento de los datos: Un cuadrado doble, una flecha, un rectngulo con
esquinas redondeadas(o una burbuja) y un rectngulo abierto (cerrado en el lado
izquierdo y abierto en el derecho), como se muestra en la Figura 1 a continuacin.
Con la combinacin de estos cuatro smbolos se puede describir grficamente un
sistema completo y varios subsistemas.

Entidad

Flujo de datos

Proceso

Almacn de datos
Figura 1 Simbologa

El cuadrado doble se usa para describir una entidad externa (otro

departamento, un negocio, una persona o una maquina) que puede enviar datos al
sistema o recibirlos de l. La entidad externa, o solo entidad, tambin se llama
origen o destino de datos, y se considera externa al sistema descrito. A cada
entidad se le asigna un nombre adecuado. Aunque interacta con el sistema, se
considera fuera de los lmites de este. La misma entidad se podra usar ms de
una vez en un diagrama de flujo de datos en particular para evitar que las lneas
se crucen en el flujo de datos.

La flecha muestra el movimiento de los datos de un punto a otro, con la punta

de la flecha sealando hacia el destino de los datos. Los flujos de datos que
ocurren simultneamente se pueden describir mediante flechas paralelas. Una

flecha tambin puede se debe describir con un nombre, debido a que representan
los datos de un apersona, lugar o cosa.
Rectngulo con esquinas redondeadas se usa para mostrar la presencia de un
proceso de transformacin. Los procesos siempre denotan un cambio en los
datos o una transformacin de estos; por lo tanto el flujo de datos que sale de un
proceso siempre se designa de forma diferente al que entra en l. Los procesos
representan trabajo que se realiza en el tema y se deben nombrar usando uno de
los formatos siguientes:

Se le debe asignar un nombre claro ya que este permite reconocer

fcilmente lo que hace un proceso.

1. A los procesos de alto nivel asigna el nombre del sistema. Por ejemplo:
SISTEMA DE CONTROL DE VENTAS.
2. Para nombrar un subsistema principal, se usa un nombre como
SUBSISTEMA DE INFORMACION DE VENTAS O SISTEMAS DE
CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET.
3. Para los procesos detallados se usa un formato de sustantivo-verboadjetivo. El sustantivo indica cual es el resultado principal del proceso, tal
como informe o registro. El verbo describe el tipo de actividad, tal como
calcular, verificar, preparar, imprimir o agregar. El adjetivo describe el
resultado especfico que se produce tal como nuevo pedido o inventario.
Ejemplos de nombres de procesos son calcular impuestos de ventas,
verificar estados de cuenta del cliente, preparar factura de envo, imprimir
informe de nuevos pedidos, enviar confirmacin al cliente por correo
electrnico, verificar saldo de tarjeta de crdito y agregar registro de
inventario.

A un proceso se le debe de asignar un nmero de identificacin nico y

exclusivo, que indique su nivel en el diagrama. Podra haber varios flujos
de datos que entren y salgan de cada proceso. Los procesos con solo un
flujo de entrada y salida se deben examinar en busca de flujos de datos
perdidos.

El rectngulo abierto representa un almacn de datos. Estos smbolos se

dibujan con el espacio suficiente para que quepan las letras de
identificacin. En los diagramas de flujo de datos lgicos no se especifica el
tipo de almacenamiento a un lugar. En este punto el smbolo del almacn

de datos simplemente muestra un lugar de depsito para los datos que

permite examinar, agregar y recuperar datos.
El almacn de datos podra representar un almacn manual, tal como un gabinete
de archivo, un archivo o una base de datos de computadora. A los almacenes de
datos se les asigna un nombre debido a que representan a una persona, lugar o
cosa. Los almacenes de datos temporales, tales como papel borrador o un archivo
temporal de computadora, no se incluyen en el diagrama de flujo de datos. Para
identificar el nivel del almacn de datos, a cada uno asgnele un nmero de
referencia nica, tal como D1, D2, D3 etc.
4.1.2 Desarrollo de Diagramas de Flujos de Datos:
Los diagramas de flujos de datos se pueden y deben dibujar de manera
sistemtica. Primero se deben visualizar los flujos de datos desde una perspectiva
jerrquica de arriba a abajo. En seguida se describen los pasos a seguir.
Lista de actividades:
Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativa(o
historia) del sistema de la organizacin en una lista con las cuatro categoras de
entidad externa, flujo de datos, procesos, y almacn de datos. Esta lista a su vez
ayudara a determinar los lmites del sistema que describir. Una vez que se haya
recopilado una lista bsica de elementos de datos se empieza a dibujar el
diagrama de contexto.
Creacin de diagrama de contexto:
Con un enfoque jerrquico de arriba hacia abajo para diagramar el movimiento de
los datos, los diagramas van de lo general a lo especfico. Aunque el primer
diagrama ayuda a entender el movimiento bsico de los datos, lo general de su
naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrar un
panorama global que incluya las entradas bsicas, el sistema general y las
salidas. Este diagrama ser el ms general, con una visin muy superficial del
movimiento de los datos en el sistema y una visualizacin lo ms amplia posible
del sistema. El diagrama de contexto es el nivel ms alto en un diagrama de flujo
de datos y contiene un solo proceso, que representa a todo el sistema. Al proceso
se le asigna el nmero cero. En este diagrama se muestran todas las entidades
externas, as como los flujos de datos principales que van desde y hacia dichas
entidades. El diagrama no contiene ningn almacn de datos. Es bastante simple

la creacin ya que se conocen las entidades externas y el flujo de datos desde y

hacia ellas.
Dibujo del diagrama 0 (el siguiente nivel):
Al ampliar los programas se puede lograr un mayor detalle que con los diagramas
de contexto. Las entradas y salidas especificadas en el primer diagrama
permanecen constantes en todos los diagramas que le siguen. Sin embargo, el
resto del diagrama original se amplia para incluir de tres a nueve procesos y
mostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cada
diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para
representar subprocesos, en este paso se empiezan a completar los detalles del
movimiento de los datos. El manejo de excepciones se ignora en los primero dos o
tres niveles del diagrama de flujo de datos.
Entrada A

Entidad 1

Nombre del SistemaSalida C

Entidad 3

Entrada B
Entidad 2

Flujo de datos B

Proceso general AAAProceso general BBB

Entrada A

Salida C

Entidad 1

Entidad 3

Registro A
Almacn de Datos 2

D1

Registro E
Almacn de Datos 2

D2
Registro A

Flujo de datos D

Registro E

Proceso
general CCCProceso general DDD
Entrada
B
Entidad 2

Figura 2 Representacin del diagrama de contexto y del diagrama cero

El diagrama cero es la ampliacin del diagrama de contexto y puede incluir hasta

nueve procesos, esto se hace porque si se agregan ms procesos producir un
diagrama difcil de entender. Por lo general, cada proceso se numero con un
entero, empezando en la esquina superior izquierda del diagrama y terminando en
la esquina inferior derecha. En el diagrama cero se incluyen los principales
almacenes de datos del sistema (que representan a los archivos maestros) y todas
las entidades externas. La figura 3.2 representa grficamente el diagrama de
contexto y el diagrama cero.
Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal),
se puede empezar en cualquier punto del diagrama e ir hacia delante o hacia
atrs. Si no est seguro de lo que podra incluir en cualquier punto, tome una
entidad externa, un proceso o un almacn de datos diferente y empiece a dibujar
el flujo a partir de l:
1. Empezamos con el flujo de datos de una entidad en el lado de la entrada.
Se hacen preguntas como: Qu sucede con los datos que entran en el
sistema? Se almacenan? Esta entrada es para varios procesos?
2. Trabajamos hacia atrs a partir de un flujo de datos de salida. Examinamos
los campos de salida de un documento o pantalla. (Este enfoque es ms
sencillo si se han creado prototipos.) Se pregunta sobre cada campo de la
salida: "De dnde viene?" o "Se calcula o almacena en un archivo?" Por
ejemplo, cuando la salida es un RECIBO DE NOMINA, el NOMBRE DEL
EMPLEADO y la DIRECCION se podran localizar en un archivo EMPLEADO, las HORAS TRABAJADAS podran encontrarse en un
REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se
tendran que calcular. Cada archivo y registro estara conectado al proceso
que produce el recibo de nmina.
3. Examinamos el flujo de datos desde o hacia un almacn de datos. Se
pregunta: "Qu procesos ponen los datos en el almacn?" o "Qu
procesos usan los datos?" Observamos que un almacn de datos utilizado
en el sistema en el que se est trabajando podra ser producido por un
sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya
ningn flujo de datos hacia el almacn de datos.
4. Analizamos un proceso bien definido. Vea qu entrada de datos necesita el
proceso y qu salida produce. Se hace un vnculo la entrada y la salida con
los almacenes de datos y las entidades adecuadas.

5. Tome nota de cualquier rea confusa en donde no est seguro de lo que se

debe incluir o de la entrada o la salida que se requiera. Al conocer las reas
problemticas podr realizar una lista de preguntas para las entrevistas de
seguimiento con los usuarios clave.

Creacin de diagramas hijos (niveles ms detallados):

Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear un
diagrama hijo ms detallado. El proceso del Diagrama cero a partir del cual se
realiza la ampliacin se llama proceso padre, y el diagrama que se produce se
llama diagrama hijo. La regla principal para crear diagramas hijos, es el equilibrio
vertical, estipula que un diagrama hijo no puede producir salida o no puede recibir
entrada que el proceso padre no produzca o reciba tambin.
Todos los flujos de datos hacia dentro o hacia fuera del proceso padre se deben
mostrar fluyendo hacia dentro o hacia fuera del diagrama hijo.
Al diagrama hijo se le asigna el mismo nmero que a su proceso padre en el
Diagrama cero. Los procesos del diagrama hijo se numeran usando el nmero del
proceso padre, un punto decimal y un solo nmero para cado proceso hijo. Con
esto se puede localizar una serie de procesos a travs de muchos niveles de
ampliacin. Si el diagrama cero presenta los procesos 1, 2 y 3 los diagramas hijos
1, 2 y 3 estarn en el mismo nivel.
Por lo regular las entidades no se muestran en los diagramas hijos debajo del
diagrama cero. El flujo de datos que coincide con el flujo padre se llama flujo de
datos de interfaz y se representa con una flecha que parte de un rea vaca del
diagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacn
de datos, tambin el diagrama hijo podra incluir el almacn de datos. Adems,
este diagrama de nivel inferior podra contener almacenes de datos que no se
muestran en el proceso padre. Por ejemplo se podran incluir un archivo que
contenga una tabla de informacin, como una tabla de impuestos, o un archivo
que conecta dos procesos del diagrama hijo. En un diagrama hijo se podran
incluir un flujo de datos de nivel inferior, como una lnea de error, aunque no se
podra hacer lo mismo en el proceso padre.

Los procesos se podran ampliar o no ampliar, dependiendo de su nivel de

complejidad. Cuando no se ampla un proceso, se dice que es funcionalmente
primitivo y se llama proceso primitivo. En la figura 3.3 se ilustran niveles detallados
de un diagrama de flujos de datos hijo.
Revisin de Errores en los diagramas:
Cuando se dibujan diagramas de flujos de datos se pueden cometer varios errores
comunes como los siguientes:
1. Olvidar incluir un flujo de datos o apuntar con una flecha en la direccin
incorrecta. Un ejemplo es un proceso dibujado que muestra todos sus flujos
de datos como entrada o salida. Cada proceso transforma datos y debe
recibir una entrada y producir una salida. Este tipo de error ocurre
generalmente cuando el analista olvida incluir un flujo de datos o coloca una
flecha que apunta en la direccin incorrecta.
2. Conectar directamente entre s almacenes de datos y entidades externas.
Los almacenes de datos y las entidades externas no se deben conectar
entre s; slo se deben conectar con un proceso. Un archivo no interacta
con otro archivo sin la ayuda de un programa o una persona que mueva los
datos. Las entidades externas no trabajan directamente con los archivos.
Dos entidades externas conectadas directamente indican que desean
comunicarse entre s. Esta conexin no se incluye en el diagrama de flujo
de datos a menos que el sistema facilite la comunicacin. La elaboracin de
un informe es un ejemplo de esta clase de comunicacin. Sin embargo, es
necesario interponer un proceso entre las entidades para producir el
informe.

El flujo de datos del proceso padre debe coincidir con el diagrama hijo

Figura 4 Revisin de errores

3. Asignar nombres incorrectos a los procesos o al flujo de datos. Es

necesario revisar el diagrama flujo de datos para asegurar que cada objeto
o flujo de datos tenga un nombre adecuado. Un proceso debe indicar el
nombre del sistema o usar el formato sustantivo-verbo-adjetivo. Cada flujo
de datos se debe describir con un sustantivo.
4. Incluir ms de nueve procesos en un diagrama de flujo de datos. La
inclusin de demasiados procesos origina un diagrama confuso difcil de
entender y obstaculiza la comunicacin en lugar de facilitada. Si en un
sistema existen ms de nueve procesos, agrupe en un subsistema algunos
de los procesos que trabajan en conjunto y pngalos en un diagrama hijo.
5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es
decir, flujo de datos en el cual cada proceso tiene slo una entrada y una
salida. El flujo de datos lineal no es muy comn, excepto en los diagramas
de flujo de datos hijos muy detallados, su presencia normalmente indica
que al diagrama le falta algn flujo de datos.
6. Crear una separacin (o ampliacin) desequilibrada en los diagramas hijos.
Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida
que el proceso padre, Una excepcin a esta regla son las salida menores,
como las lneas de error, que se incluyen solamente en el diagrama hijo.

En seguida se sintetizan los pasos para desarrollar eficazmente diagramas de flujo

de datos, usando un enfoque jerrquico de arriba a abajo:
1. Haga una lista de las actividades del negocio y sela para determinar lo
siguiente:

Entidades externas

Flujos de datos

Procesos

Almacn de datos

2. Crear un diagrama de contexto que muestre las entidades externas y los

flujos de datos desde y hacia el sistema. No muestre ejemplos ni
almacenes de datos detallados.
3. Dibujar el diagrama 0(el siguiente nivel). Muestre procesos, pero que sean
generales. En este nivel muestre almacenes de datos.
4. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0
5. Revise que no haya errores y asegrese de que sean significativos los
nombres que haya asignado a cada proceso y flujo de datos.
6. Desarrolle un diagrama de flujo de datos fsico a partir del diagrama de
flujo de datos lgico. Distinga entre los procesos manuales y
automatizados, describa los archivos reales y los informes por nombre y
agregue controles para indicar cuando se completan los procesos o cuando
ocurren errores.
7. Ahora se hace una particin el diagrama de flujo de datos fsico separando
o agrupando sus partes con el propsito de facilitar la programacin y la
implementacin.

Referencias:
https://www.google.com.mx/url?
sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwjfo
o2-vJ_PAhUFET4KHXucCkwQFgg7MAQ&url=http%3A%2F
%2Fdsc.itmorelia.edu.mx%2F~jcolivares%2Fcourses%2Fsdf11b
%2Fsdf_p3.doc&usg=AFQjCNH1f4y4qYwBXoT4V5LrI95MGEYbeQ&sig2=kQh
G5GEGvJwH52jadrhjYQ&bvm=bv.133387755,d.cWw