PRINCIPIOS DEL ANÁLISIS

Todos los métodos de análisis se relacionan por un conjunto de principios

operativos:

1. Debe representarse y entenderse el dominio de información de un problema.

2. Debe definirse las funciones que debe realizar el software.

3. Debe representarse el comportamiento del software.

4. Debe dividirse los modelos que representan información, función y

comportamiento de manera que se descubran los detalles por capas.

5. El proceso de análisis deriva ir desde la información esencial hasta el detalle

de la implementación.

Davis sugiere un conjunto de principios directrices para la Ingeniería de

Requisitos:

· Entender el problema antes de empezar a crear el modelo del análisis.

· Desarrollar prototipos que permitan al usuario entender cómo será la
interacción hombre-máquina.

· Registrar el origen y la razón de cada requisito.

· Usar múltiples planteamientos de requisitos.

o Reduce probabilidad de que se olvide algo.

o Aumenta probabilidad de reconocer inconsistencias.

· Dar prioridad a los requisitos. Cronogramas.

· Trabajar para eliminar la ambigüedad.

Metodología estructurada

Es la primera aproximación al problema. Está orientada a procesos, es decir, se

centra en especificar y descomponer la funcionalidad del sistema.

Herramientas utilizadas:

Diagramas de flujo de datos (DFD): Representan la forma en la que los datos se

mueven y se transforman. Incluye:

–Procesos

–Flujos de datos

–Almacenes de datos
Los procesos individuales se pueden a su vez descomponer en otros DFD de nivel
superior.

Especificaciones de procesos: Es lo que se escribe para uno de los procesos

definidos en el DFD cuando no se puede descomponer más. Puede hacerse en
pseudocódigo, con tablas de decisión o en un lenguaje de programación.

Diccionario de datos: Son los nombres de todos los tipos de datos y almacenes de
datos junto con sus definiciones

Diagramas de transición de estados: Modelan procesos que dependen del tiempo

Diagramas entidad-relación: Los elementos del modelo E/R se corresponden con

almacenes de datos en el DFD. En este diagrama se muestran las relaciones entre
dichos elementos

Los lenguajes de programación también reflejan esta dicotomía que existe entre
la metodologías, así existen lenguajes para la programación estructurada. Los más
famosos son: Cobol, Fortran, C, Pascal y Modula 2.

Notación

La notación de base de datos de Chen es útil para modelar los conceptos básicos
de las entidades y relaciones, ya que presenta una vista abstracta de las
asociaciones.
Estos diagramas son un buen paso de entrada para comprender la estructura de
la base de datos, especialmente para bases de datos básicas o ejemplos. Esta
notación también es adecuada para lluvias de ideas y diagramas rápidos.

Las entidades se representan mediante rectángulos. Los atributos son llamadas

circulares a las entidades. Las relaciones conectan las entidades con una forma de
diamante y un texto descriptivo.

Un ejemplo de un diagrama que usa la notación de base de datos de Chen.

Reglas

Descripción de la normalización

La normalización es el proceso de organizar los datos de una base de datos. Se

incluye la creación de tablas y el establecimiento de relaciones entre ellas según
reglas diseñadas tanto para proteger los datos como para hacer que la base de
datos sea más flexible al eliminar la redundancia y las dependencias incoherentes.

Los datos redundantes desperdician el espacio de disco y crean problemas de

mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se
deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un
cambio en la dirección de un cliente es mucho más fácil de implementar si los
datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de
datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario
mirar en la tabla Clientes para buscar la dirección de un cliente en particular,
puede no tener sentido mirar allí el salario del empleado que llama a ese cliente.
El salario del empleado está relacionado con el empleado, o depende de él, y por
lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes
pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar
o estar interrumpida.

Hay algunas reglas en la normalización de una base de datos. Cada regla se

denomina "forma normal". Si se observa la primera regla, se dice que la base de
datos está en "primera forma normal". Si se observan las tres primeras reglas, se
considera que la base de datos está en "tercera forma normal". Aunque otros
niveles de normalización son posibles, la tercera forma normal se considera el
nivel más alto necesario para la mayoría de las aplicaciones.

Al igual que con otras muchas reglas y especificaciones formales, en los

escenarios reales no siempre se cumplen los estándares de forma perfecta. En
general, la normalización requiere tablas adicionales y algunos clientes consideran
éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de
la normalización, asegúrese de que su aplicación se anticipa a los problemas que
puedan aparecer, como la existencia de datos redundantes y de dependencias
incoherentes.

Skip to Content

Go to Lucidchart homepage
Producto

Lucidspark

Soluciones

Recursos

Alternativa a Visio

Precios

Comunícate con Ventas

Regístrate gratis

Qué es un diagrama de flujo de datos

¿Cuáles son tus necesidades de creación de DFD?

No tengo experiencia en DFD y quiero aprender más.

Quiero crear mi propio DFD en Lucidchart.

Quiero crear un DFD usando una plantilla de Lucidchart.

Índice

¿Qué es un diagrama de flujo de datos?

Historia del DFD

Símbolos y notaciones usadas en los DFD

Reglas y consejos para el DFD

Niveles y capas del DFD: de los diagramas de contexto al pseudocódigo

Ejemplos de cómo se pueden usar los DFD

DFD vs. Lenguaje Unificado de Modelado (UML)

DFD lógico vs. DFD físico

Cómo crear un diagrama de flujo de datos

Esta guía brinda todo lo que necesitas saber acerca de los diagramas de flujo de
datos, incluidas definiciones, historia, símbolos y notaciones. Conocerás los
diferentes niveles de un DFD, la diferencia entre un DFD lógico y un DFD físico, y
recomendaciones para crear un DFD.

8 minutos de lectura
¿Deseas crear tu propio diagrama de flujo de datos? Prueba Lucidchart. Es rápido,
sencillo y totalmente gratis.

Crea un diagrama de flujo de datos

¿Qué es un diagrama de flujo de datos?

Un diagrama de flujo de datos (DFD) traza el flujo de la información para cualquier

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

diagrama de flujo de datos

Historia del DFD

Los diagramas de flujo de datos se popularizaron a finales de la década de 1970, a

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

Contribuyeron además dos conceptos relacionados:

Análisis y diseño orientados a objetos (OOAD), propuesto por Yourdon y Peter

Coad para analizar y diseñar una aplicación o sistema.

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

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

Otros tres expertos que contribuyeron a este ascenso en la metodología de los

DFD fueron Tom DeMarco, Chris Gane y Trish Sarson. Colaboraron en diferentes
combinaciones y fueron los principales definidores de los símbolos y notaciones
usados para un diagrama de flujo de datos.

Símbolos y notaciones usadas en los DFD

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

Yourdon-Coad

Yourdon-DeMarco

Gane-Sarson

Una diferencia importante en sus símbolos es que Yourdon-Coad y Yourdon-

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

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

Entidad externa: un sistema externo que envía o recibe datos, comunicándose

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

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

Almacén de datos: archivos o repositorios que conservan información para uso

posterior, p. ej., una tabla de base de datos o un formulario de membresía. Cada
almacén de datos recibe una etiqueta simple, p. ej., "Pedidos".

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

Notación

Yourdon-Coad
Gane-Sarson

Entidad externa

Entidad externa de Yourdon-Coad

Entidad externa Gane-Sarson

Proceso

Proceso Yourdon-Coad

Proceso Gane-Sarson

Almacén de datos

Almacén de datos Yourdon-Coad

Almacén de datos Gane-Sarson

Flujo de datos

Flujo de datos Yourdon-Coad

Flujo de datos Gane-Sarson

¿Deseas más detalles? Aquí tienes un amplio panorama de símbolos y notaciones

de diagramas y cómo se usan.

Reglas y consejos para el DFD

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

Cada almacén de datos debe tener al menos una entrada y una salida de flujo de
datos.
Los datos almacenados en un sistema deben pasar por un proceso.

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

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

Crear diagramas es rápido y sencillo con Lucidchart. Inicia una prueba gratuita hoy
mismo para empezar a crear y colaborar.

Crea un diagrama de flujo de datos

Niveles y capas del DFD: de los diagramas de contexto al pseudocódigo

Un diagrama de flujo de datos puede profundizar progresivamente en más detalle

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

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

básico de todo el sistema o proceso que se está analizando o modelando. Está
diseñado para ser una vista rápida que muestra el sistema como un único proceso
de nivel alto, con su relación con entidades externas. Debe ser entendido
fácilmente por una amplia audiencia, incluidas partes interesadas, analistas de
negocios, analistas de datos y desarrolladores.

diagrama de contexto

El Nivel 1 de un DFD brinda un desglose de piezas más detallado del diagrama a

nivel de contexto. Destacarás las principales funciones que el sistema lleva a cabo,
a medida que desgloses el proceso de alto nivel del diagrama de contexto en sus
subprocesos.

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

Diagrama de Nivel 2

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

Con el uso de capas en el DFD, los niveles en cascada se pueden anidar

directamente en el diagrama, lo que proporciona un aspecto más ordenado con
fácil acceso a profundizar en más detalle.

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

Ejemplos de cómo se pueden usar los DFD

Los diagramas de flujo de datos son muy apropiados para el análisis y modelado
de diversos tipos de sistemas en diferentes campos.

DFD en ingeniería de software: Es aquí donde los diagramas de flujo de datos

tuvieron su principal arranque en la década de 1970. Los DFD pueden brindar un
planteamiento enfocado hacia el desarrollo técnico, en el cual se realiza más
investigación previa para llegar a la codificación.

DFD en análisis de negocios: Los analistas de negocios emplean los DFD para
analizar los sistemas existentes y encontrar ineficiencias. La diagramación del
proceso puede detectar los pasos que, de otro modo, podrían pasar inadvertidos
o no comprenderse por completo.

DFD en la reingeniería de procesos de negocios: Los DFD se pueden usar para

modelar un flujo de datos mejor y más eficiente a través de un proceso de
negocios. La reingeniería de procesos de negocios fue impulsada en la década de
1990 para ayudar a las organizaciones a reducir costos operativos, mejorar el
servicio al cliente y competir mejor en el mercado.

DFD en el desarrollo ágil: Los DFD se pueden usar para visualizar y comprender los
requisitos de negocios y técnicos y planificar los siguientes pasos. Pueden ser una
herramienta simple pero poderosa para la comunicación y colaboración a fin de
enfocarse en un desarrollo rápido.

DFD en estructuras de sistemas: Cualquier sistema o proceso se puede analizar en

un detalle progresivo para mejorarlo en aspectos tanto técnicos como no
técnicos.

DFD vs. Lenguaje Unificado de Modelado (UML)

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

DFD lógico vs. DFD físico

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

Cómo crear un diagrama de flujo de datos

Puedes crear tu propio DFD en línea con Lucidchart. Usa nuestros ejemplos y
notaciones especializadas de DFD para representar visualmente el flujo de datos a
través de tu sistema. Nuestro creador de diagramas de flujo de datos es simple,
pero poderoso. Empieza con una plantilla y luego usa nuestras figuras para
personalizar tus procesos, almacenes de datos, flujos de datos y entidades
externas.

Recursos útiles

Cómo crear un diagrama de flujo de datos

Símbolos de diagramas de flujo de datos

Diagrama de flujo de datos lógico vs. físico

Crear diagramas de flujo de datos es rápido y sencillo con Lucidchart. Inicia una
prueba gratuita hoy mismo para empezar a crear y colaborar.

Diagramas de contexto
Crea un diagrama de contexto como referencia gráfica para los ingenieros y otros
integrantes del equipo

Un diagrama de contexto, también conocido como diagrama de contexto de

sistema o diagrama de flujo de datos de nivel 0, comunica una visión general de
alto nivel del flujo de datos dentro de un sistema técnico. Prácticamente no se
necesitan conocimientos técnicos para comprender este tipo de diagrama del
sistema. Por ese motivo, los ingenieros, analistas, desarrolladores y grupos
interesados pueden emplearlo como referencia gráfica para el análisis y el diseño
de sistemas. Usa Lucidchart como tu software para diagramas de contexto para
enfocarte eficientemente en los factores y los eventos externos que interactúan
con tu sistema y determinan el alcance de tu proceso.

Niveles

Diagrama de flujo de datos

Idioma

Descargar en PDF

Vigilar

Editar

Este artículo o sección necesita referencias que aparezcan en una publicación

acreditada.

Un diagrama de flujo de datos o DFD (sus siglas en español e inglés) es una

representación gráfica del flujo de datos a través de un sistema de información.
Un diagrama de flujo de datos también se puede utilizar para la visualización de
procesamiento de datos (diseño estructurado). Es una práctica común para un
diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción
entre el sistema y las entidades externas.
Componentes de un Diagrama de Flujo de Datos (DFD) según la notación de
Yourdon y DeMarco.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el

desarrollador original del diseño estructurado, basado en el modelo de
computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo
de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas
Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los
usuarios finales tendrán que ser informados y consultados en todas las etapas de
una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a
poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr,
y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo
de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas
de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema
más eficiente. Los diagramas de flujo de datos pueden ser usados para
proporcionar al usuario final una idea física de cómo resultarán los datos a última
instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La
manera en que cualquier sistema es desarrollado, puede determinarse a través de
un diagrama de flujo de datos.

Los niveles de un DFD son:

Nivel 0: Diagrama de contexto

Nivel 1: Diagrama de nivel superior

Nivel 2: Diagrama de detalle o expansión