Análisis de Sistemas

INDICE
Tema Página

Investigación Preliminar................................................................................ 03
Prueba de Factibilidad
Factibilidad Técnica
Factibilidad Operacional
Factibilidad Económica

Determinación de requerimientos.................................................................. 06
Determinación de procesos
Determinación de datos

Análisis del flujo de los datos......................................................................... 10

Anticipación de requerimientos
Investigación de requerimientos
Especificación de requerimientos

Diagramas de Flujo de datos........................................................................... 10

Primer nivel del DFD
Expansión de los procesos a diagramas de mayor nivel
Reglas adicionales para el dibujo de DFD

Diccionario de Datos...................................................................................... 14
Importancia del diccionario
Contenido de un registro del diccionario
Notación empleada en el Diccionario de datos

Comentario final............................................................................................ 16
Cualquiera que sea la necesidad de información de una organización, siempre se debe
fundamentar en una solicitud (por escrito y firmada) por parte de alguna parte
involucrada en el mismo, sea este un usuario, analista, gerente, encargado de proyectos,
etc. En ella se debe establecer muy claramente los siguientes puntos:
 ¿Cuál es el problema?
 Detalles del problema
 Importancia del problema
 ¿Cuál cree el solicitante que puede ser la solución al mismo?
 ¿En qué forma ayuda un sistema de información?
 Breve resumen de los reportes usados y funciones que se realizan
 ¿Qué otras personas tienen conocimiento del problema y que se pueden
contactar?

Esta propuesta debe ser analizada por un comité (o su equivalente), que determina lo
urgente de poner a andar los medios necesarios para tratar resolver la situación.

Investigación Preliminar
Por cualquiera que sea la estrategia mediante la cual se va a desarrollar el
sistema (SDLC, prototipos, análisis estructurado, o por una combinación de éstos)
primero es necesario revisar la solicitud del proyecto. La elección de una estrategia es
secundario, lo importante es determinar si la solicitud merece o no la inversión de
recursos en un proyecto de sistemas de información. El tiempo estimado es
aproximadamente entre 4 a 6 seis días.
Ambito del estudio
La finalidad de la investigación preliminar es evaluar las solicitudes de proyectos. No es
un estudio de diseño ni tampoco incluye la recolección de detalles para describir el
sistema de la empresa. Más bien, es la reunión de información que permita a los
miembros del comité evaluar los méritos de la solicitud de proyecto y emitir un juicio,
con conocimiento de causa, con respecto a la factibilidad del proyecto propuesto
Durante la investigación preliminar se deben satisfacer los siguientes objetivos:
1. Aclarar y comprender la solicitud del proyecto:
2. Determinar el tamaño del proyecto
3. Evaluar los costos y beneficios de las diversas opciones
4. Determinar la factibilidad técnica y operacional de las diferentes alternativas
5. Reportar los hallazgos a la administración y formular recomendaciones que
esbocen el criterio de aceptación o rechazo del proyecto.

Ahora bien, los datos recogidos durante la investigación se reúnen por medio de
principalmente la revisión de documentos la conducción de entrevistas. El resumen de
cada entrevistado debe indicar:
 Resumen de las funciones que realiza
 Clasificación de los problemas identificados
 Análisis de las mejoras potenciales
 Cambios propuestos y su impacto
 Análisis de la relación entre los cambios propuestos y los planes existentes para
la organización y el departamento
Prueba de factibilidad del proyecto
La investigación preliminar examina la factibilidad del proyecto, la posibilidad
de que el sistema sea de utilidad para la organización; a saber en tres áreas:
• Factibilidad operacional: se refiere al hecho de que si trabajará o no el sistema si
este se llega a desarrollar, preguntas claves aquí son:
 ¿Existe apoyo suficiente para el proyecto por parte de la administración?, ¿Y
por parte de los usuarios?
 Los métodos que actualmente se usan en la empresa, ¿son aceptados por los
usuarios?
 ¿Los usuarios han participado en la planeación y desarrollo del proyecto?,
¿Cómo lo han hecho?
 ¿El sistema propuesto causará perjuicios?
 ¿Producirá resultados pobres en alguna área?
 ¿Se perderá control en alguna área específica?
 ¿Se perderá la facilidad de acceso a la información?
 ¿La productividad de los empleados será menor después de instalado el sistema?
 ¿Los clientes se verán afectados por la implantación?
• Factibilidad Técnica:
 ¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?
 ¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos
requeridos para usar el nuevo sistema?
 ¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin
importar el número y ubicación de los usuarios?
 Si se desarrolla el sistema, ¿se puede crecer con facilidad?
 ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y
seguridad de los datos?
• Factibilidad financiera y económica: un sistema puede ser factible desde el punto
de vista técnico y operacional, pero sino es factible económicamente para la
organización no puede ser implantado. Las cuestiones económicas y financieras
formuladas por los analistas deben incluir
 El costo de llevar a cabo la investigación completa de sistemas
 El costo del hardware y software para la aplicación
 Beneficios en la forma de reducción de costos o de menos errores costosos
 El costo si nada sucede (si el proyecto no se lleva a cabo)

Aprobación de la solicitud
No todos los proyectos solicitados son factibles. Algunas organizaciones reciben tantas
solicitudes de sus empleados que solo es posible atender unas cuantas. Sin embargo,
aquellos casos que son deseables y factibles deben incorporarse en los planes de
desarrollo de la organización, para ser atendidos lo más rápido posible, según los
recursos de la organización.

Dentro de los beneficios que el sistema podría brindar tenemos:

 Obtención de información no disponible actualmente
 Elaboración más oportuna de la información
 Mejoras en las operaciones de la organización
 Posibilidades de efectuar cálculos o estimaciones que actualmente no es
posible
 Reducción de costo
  Obtención de una posición competitiva dentro del mercado
 Mejoras en la toma de decisiones.
 Mejoras en la imagen, atención, seguridad, etc.

La siguiente tabla detalla una lista de actividades que se desarrollan en esta

etapa, acompañada de los productos generados por cada actividad

Lista de Actividades Productos

1. Planeación de la etapa Lista de actividades de esta etapa

Programación de la lista de actividades
Programación de las entrevistas
2. Recopilación de datos Informes y diagnósticos de soluciones

3. Realización de las entrevistas Archivo de proyecto e índice

Programación actualizada en entrevistas con
base en modificaciones que sufra el producto de
la actividad
Resumen de las entrevistas

4. Análisis de los datos Beneficios esperados

Entradas y salidas claves
Flujos de datos
Organigramas
Costos previos
Evaluación económica
5. Evaluación de la necesidad de Plan de etapas restantes
realizar la próxima etapa Resumen administrativo
6. preparación de plan de trabajo Lista de actividades de la siguiente etapa
para la siguiente etapa Programación de la lista de actividades de la
próxima etapa (con estimación, fecha calendario
y personas)
7.Revisión de los resultados con
el comité de decisión
 “Solo después de que un analista comprende en su totalidad el sistema, está en
posición de analizarlo y generar recomendaciones para el diseño de sistemas 1.”

En el estudio de factibilidad se trata de determinar si realmente existe un

problema, cuáles son sus características y en términos generales las posibles soluciones
y la factibilidad técnica, operacional y económica de aplicar dichas soluciones. Pero
nada más.

Determinación de requerimientos
Un requerimiento es una característica necesaria que deberá poseer el nuevo
sistema.
Por otra parte, la determinación de requerimientos es el estudio de un sistema
para comprender cómo trabaja y dónde es necesario efectuar mejoras.
Ahora bien, existen tres formas (= actividades) de determinar de requerimientos, a saber
• Anticipación de requerimientos: prever las características del nuevo
sistema con base en experiencia previa.
• Investigación de requerimientos: actividad más importante del análisis de
sistemas. Es el estudio y documentación del sistema actual usando para ellos
técnicas de para hallar hechos, análisis de flujo de datos y análisis de
decisión. Es aquí donde aplicamos entrevistas, cuestionarios, observación y
revisión de documentación entre otros.
• Especificación de requerimientos: los datos obtenidos durante la
recopilación de hechos se analizan para determinar las especificaciones de
los requerimientos, es decir, la descripción de las características del nuevo
sistema. Esta actividad tiene tres partes relacionadas entre sí, a saber:
 Análisis de datos basados en hechos reales
 Identificación de requerimientos esenciales
 Selección de estrategias para satisfacer los requerimientos

Todo sistema de información posee un conjunto de requerimientos básicos y un

conjunto de requerimientos específicos dependiendo si el sistema será de soporte para
transacciones o para la toma de decisiones.

En lo que resta del presente documento se elaborará un grupo de preguntas que

al dárseles respuesta presentarán un conjunto de hechos de los que posteriormente se
obtendrá una especificación de requerimientos lo más apegada posible a las necesidades
de cualquier organización.

Requerimientos básicos: los analistas estructuran su investigación al buscar

•
respuestas a las siguientes cuatro preguntas:
 ¿Cuál es el proceso básico de la empresa?
 ¿Qué datos utiliza o produce este proceso?
 ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
 ¿Qué controles de desempeño utiliza?
Son esas las preguntas que tienen que tener una respuesta concreta al tener
terminada la fase de investigación de requerimientos.

1
James A. Senn, Análisis y Diseño de Sistemas, Segunda edición, cap. tres, pág. 122.
Siempre se debe comenzar con lo básico. Los analistas hacen preguntas que cuando
reciben respuesta, proporcionan antecedentes sobre detalles fundamentales relacionados
con el sistema y que sirven para describirlo. Las siguientes preguntas son de utilidad
para adquirir la comprensión necesaria:
• ¿Cuál es la finalidad de la actividad dentro de la empresa?
• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?
Respuestas concisas a estas preguntas proporcionan un conocimiento amplio de una
actividad en particular y muestra también su objetivo. Pero analista no se detiene ahí,
todavía no existe información para comprender en su totalidad la actividad; más bien lo
que se tiene son los antecedentes que permiten a los analistas formular preguntas más
detalladas.

Durante esta, debemos identificar muy claramente los siguientes elementos:

 procesos
 flujos de datos entre procesos
 datos de cada flujo de datos
 almacenes de datos
 datos de los almacenes de datos.

Para ello el cuestionario que se aplica debe requerir la siguiente información:

 nombre de la entidad
 nombre los campos
 descripción
 fuente y sensibilidad (= seguridad)
 valor o importancia de los datos
 relaciones de los campos y entidades
 Criterio de retención y almacenamiento.

Preguntas clásicas para una determinación de requerimientos:

 Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende
desarrollar el sistema; o sea, cuántos tienen relación directa con el proyecto que
se está investigando. ?
• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del
sistema?
• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño
documentados oficial o no oficialmente?. Si los hay, ¿Se cumplen en forma
cabal en el 100% de las ocasiones?, es decir, ¿se respetan dichos
procedimientos?
• ¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
 • ¿Qué áreas necesitan un control específico?
• ¿Qué criterios se emplean para medir y evaluar el desempeño?
Por otra parte:
• ¿Existen actividades que considere podrían mejorarse?, ¿De qué manera?
• ¿Tiene alguna idea de actividades que podrían implementarse para mejorar el
rendimiento del sistema en general?

 Determinación de procesos:
• ¿Cuáles son las principales actividades que se realizan en la organización y que
tienen relación con el proceso que se está modelando?

 Descripción de cada proceso identificado

• ¿Qué es lo que da inicio a la actividad?
• ¿Cuál es el objetivo de la misma?
• ¿Cuánto tiempo se tarda en realizarla?
• ¿Qué retrasos ocurren o pueden ocurrir?
• ¿Qué métodos se emplean para medir y evaluar el desempeño de esta
actividad?
• ¿Se toman precauciones específicas de seguridad para la protección
contra alguna actividad impropia que se pudiera presentar?
• ¿Qué tan frecuente es el ciclo con el que se desarrolla dicha actividad?
• De acuerdo al ciclo con el que se presenta la actividad, ¿Cuál es el
volumen de información que aquí se procesa?
• ¿Qué pasos, sub-procesos, o funciones constituyen la actividad?
(describir la actividad paso a paso)
• ¿Existe algún tipo de control desarrollado en el proceso en cuestión?

 Determinación de datos (flujos y contenido de los flujos) - hacer la pregunta por

cada proceso o actividad identificada -
• ¿De dónde proviene la información que se utiliza en esta actividad? (fuentes)
• ¿Cuáles son específicamente los datos que recibe esta actividad? (dts de flujos)
• ¿De qué manera ingresan a este proceso? (flujos)
• ¿Qué tablas de referencia y diagramas u otros datos intervienen en la actividad?
(documentación involucrada)
• ¿Qué información se genera en esta actividad? (producto de la actividad)
• El resultado identificado anteriormente producto de los datos que se procesan
¿Hacia qué o quién van dirigidos? –persona o entidad- (destinos)
• ¿Con qué finalidad la utilizan?
• ¿Cuáles datos se conservan o almacenan en este proceso? Y ¿en qué forma
quedan almacenados?
• ¿Existe información que se genera pero que no es utilizada nunca por nadie?
(partes extrañas)
 Para cada dato identificado:
• ¿Qué formato posee cada dato que interviene en esta actividad?
• ¿Para qué es usado?
• ¿Se interpone algún tipo de seguridad para la verificación de la veracidad del
dato en mención?
 • ¿Qué tan importante es dicho dato?
• ¿Por cuánto tiempo es importante mantener el dato en el sistema?

Por otra parte si el sistema que se está investigando es para el soporte de

decisiones se deben, además de las anteriores, formular otras preguntas para determinar
los requerimientos de las decisiones, un esbozo de las mismas bien podría ser:
• ¿Qué información se usa para tomar la decisión?
• ¿Cuál es la fuente de esa información? ¿Qué sistemas transnacionales
producen los datos utilizados en el proceso de decisión? ¿Qué otros datos
son necesarios y no es posible obtener del procesamiento de transacciones?
¿Qué datos se originan en fuentes externas a la organización?
• ¿Cómo se deben procesar los datos para producir la información necesaria?
• ¿Cómo debe presentarse la información.

Una vez que se tenga recopilado el conjunto de hechos que se generan con relación al
sistema que estamos modelando, es posible dar una especificación de requerimientos,
mediante como se dijo un análisis de los datos obtenidos durante la recopilación de
hechos. Es después de esto entonces, que se puede ya dar un conjunto de
requerimientos que nos servirán para modelar el sistema mediante un DFD y del que
surge el diagrama E-R
 Análisis del Flujo de Datos
La estrategia del flujo de datos muestra el empleo de éstos en forma gráfica. Las
herramientas usadas para seguir esta estrategia muestran todas las características
esenciales del sistema y la forma en que se ajustan entre sí. Puede ser difícil
comprender en su totalidad un proceso de la empresa si se emplea para ello solo una
descripción verbal; las herramientas para el flujo de datos ayudan a ilustrar los
componentes esenciales de un sistema junto con sus interacciones.
El análisis de flujo de datos usa las siguientes herramientas:
 Diagrama de flujo de datos (explicado más adelante)
 Diccionario de datos (explicado más adelante)
 Diagrama de estructura de datos (diagrama de E-R)
 Gráfica de estructura: herramienta de diseño que muestra con símbolos la
relación entre los módulos de procesamiento y el software de la
computadora. Describen la jerarquía de los módulos componentes y los
datos que serán transmitidos entre ellos. Incluye el análisis de las
transformaciones entrada- salida y el análisis de las transacciones.

Diagramas de flujo de datos

Son una de las cuatro herramientas del análisis estructurado. Es una
herramienta gráfica que se emplea para describir y analizar el movimiento de los datos a
través de un sistema, ya sea este manual o automatizado, incluyendo procesos, lugares
para almacenar datos y retrasos en el sistema. Los DFD, como se les conoce
popularmente son la herramienta más importante y la base sobre la cual se desarrollan
otros componentes. La transformación de datos de entrada en salida por medio de
procesos puede describirse en forma lógica e independiente de los componentes físicos
(computadoras, gabinetes de archivos, y procesadores de texto) asociados con el
sistema.
Notación: los DFD se pueden dibujar con solo cuatro notaciones sencillas, a saber:
 Flujo de datos: movimiento de datos en determinada dirección, desde un
origen hasta un destino en forma de documentos, cartas, llamadas telefónicas
o virtualmente cualquier otro medio. El flujo de datos es un “paquete de
datos”
• Representación:

 Procesos: personas procedimientos o dispositivos que usan o producen

(transforman) datos.
• Representación:

 Fuente o destino de datos: fuentes o destinos externos de datos, que pueden

ser personas, programas, organizaciones u otras entidades que interactúan
con el sistema pero que se encuentran fuera de sus fronteras. La diferencia
fundamental con los procesos es que las fuentes o destinos no transforman
información, al menos no dentro de las fronteras del sistema que se está
modelando
• Representación:
  Almacenamiento de datos: es el lugar donde se guardan los datos o al que
referencian los procesos en el sistema. El almacenamiento de datos puede
representar dispositivos tanto computarizados como no computarizados.
• Representación:

Los DFD se concentran en el movimiento de los datos a través del sistema, no en

los dispositivos o el equipo. Los analistas identifican y describen, desde el inicio hasta
del final proceso, para comprender un área de aplicación o los datos que fluyen por todo
el sistema y entonces explican por qué los datos entran o salen y cuál es el
procesamiento que se realiza con ellos. Es muy importante determinar cuándo entran
los datos al área de aplicación y cuándo salen de ésta.
A medida que los analistas reúnen hechos y detalles, comprenden mejor el
proceso; esto los conduce a formular preguntas relacionadas con aspectos específicos
del mismo y los lleva a una investigación adicional. La investigación se divide en
detalles que tienen cada vez un nivel menor hasta que se comprenden todos los
componentes esenciales junto con sus interrelaciones.
• Lo que se quiere dar a entender con esto, es que una investigación de
sistemas produce muchos conjuntos de DFD, algunos (los primeros) brindan
panoramas de procesos importantes, mientras que otros (los que se obtienen
de los primeros) nos muestran con bastante detalle elementos dato,
almacenes de datos y pasos de procesamiento para componentes específicos
de un sistema grande.
A los primeros diagramas obtenidos se les conoce como diagramas de alto nivel,
mientras que a los resultantes de estos se les conoce como diagramas de bajo nivel.
En este sentido el primer diagrama que se obtiene se le conoce con el nombre de
diagrama de contexto, es un diagrama de nivel muy general (alto nivel); es también
conocido como diagrama de nivel 0. Contiene un solo proceso pero juega un papel
muy importante en el estudio del sistema en uso; ya que define fronteras. Todo lo que
no se encuentre dentro de las fronteras identificadas en el diagrama no forman parte del
estudio de sistemas. La forma en que funcionen otras organizaciones o elementos
externos (las fuentes y destinos) está fuera de nuestro control y no será estudiado con
detalle.

Cada flujo de datos(cada flecha) emplea una etiqueta que describe que datos emplea.
Cuando los datos se mueven de un lugar a otro el flujo de datos apunta hacia el lugar
donde se dirige el flujo.
Ejemplo:
• Un sistema está formado por varias actividades o procesos, cada uno de los
cuales contiene varios sub-procesos con marcadas interrelaciones entre ellos.
Por ejemplo un proceso de cuentas por pagar puede estar integrado por tres
sub-procesos que podrían llamarse: autorización de la factura, revisión del
adeudo en la cuenta y elaboración del cheque.
• A su vez cada sub-proceso se divide en sub-procesos más específicos.
 • Los nombres dados a los procesos especifican acciones y procedimientos de
control que realizan
• Cada proceso se etiqueta además con un número que identifica de donde
proviene (excepto el diagrama de contexto que solo se identifica con un nivel
0 más el nombre que se le proporcione)
• En términos generales todo componente de los DFD se etiquetan con un
nombre que sea representativo.

Primer nivel del DFD

En el primer nivel, es muy importante identificar los principales procesos, y
flujos que dan en forma conjunta sentido operacional al sistema que se está modelando.
Algunos analistas consideran ventajoso trabajar primero con todos los flujos de datos y
asignar, como ya se dijo nombres que sean significativos y descriptivos. Se identifican
todos los procesos, como ya se mencionó pero no se les da nombre hasta que sean bien
entendidos todos los flujos de datos. Después cuando se les ha asignado nombre a los
procesos, si el analista tiene dificultas para ligar los flujos de datos con los nombres
apropiados entonces esta situación indica que es necesario dividir aun más el proceso.

Expansión de los procesos a diagramas de mayor nivel

Una vez que se ha desarrollado el sistema como está descrito en el diagrama de primer
nivel, es indudable que el analista formule preguntas en relación con la forma que se
lleven a cabo los procesos. (Ver documento de determinación de requerimientos) En
general se debe estar seguro de:
• Todos los flujos de datos que explican el proceso en el diagrama previo
deben incluirse en el diagrama del siguiente nivel inferior
• Los flujos y almacenes de datos nuevo se añaden si son usados internamente
por el proceso para eslabonar otros procesos introducidos por primera vez en
la expansión de este nivel. Se deben mostrar los flujos y almacenes de datos
originados en el proceso dentro en este nivel.
• Ninguna entrada debe contradecir las descripciones de los DFD de niveles
más altos (si lo hacen uno o ambos son incorrectos y deben introducirse
cambios)

En general la expansión de niveles depende de la naturaleza y complejidad del sistema

que se modele; no es posible especificar un número de niveles, en general se debe
continuar con el proceso de expansión todo lo que sea necesario para comprender los
detalles del sistema y la forma en que trabaja, teniendo cuidado de verificar todos los
aspectos con usuarios que conocen el sistema, en general, se debe expandir todo aquel
proceso que incluyen varias tareas para las que es necesario, el flujo de datos entre
diferentes personas o localidades. Por otra parte no requieren expansión aquellas tareas
que son realizadas por una persona o en un escritorio, donde no existe flujo de datos.

Reglas adicionales para el dibujo de DFD: ya se han identificado la mayor parte de

los lineamientos que se siguen para el dibujo de los DFD, he aquí algunas más:
• Cualquier flujo de datos que abandone un proceso debe estar basado en los datos
que entran al proceso
• Todos los flujos de datos tienen un nombre que refleja los datos que fluyen entre
procesos, almacenes de datos, fuentes o destinos
• Solo deben entrar al proceso, los datos necesarios para llevarlo a cabo
• 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 basada en sus
propios datos de entrada y salida
• Los procesos siempre están en continua ejecución, no se inician ni tampoco se
detienen. Los analistas siempre deben suponer que un proceso está listo para
ejecutar su trabajo
• La salida de los procesos puede tomar una de las siguientes formas
 Flujo de datos con información añadida por el proceso (i.e: una anotación a una
factura)
 Una respuesta o cambio en la forma de los datos (i.e: un cambio en la forma de
expresar las utilidades –de ¢ a $-)
 Un cambio de condición (i.e: de autorizado a no autorizado)
 Cambio de contenido (i.e: integración o separación de la información contenida
en uno o más flujos entrantes de datos)
 Cambios en la organización (i.e: separación física o redondeo de datos)
• La norma común es definir cada nivel inferior en términos de 3 a 7 procesos para
cada proceso de nivel superior, si son necesarios más detalles se puede hacer en el
siguiente nivel.
• Los almacenes y flujos de datos que son relevantes solo para el interior del proceso,
son ocultados hasta que el proceso se extiende con mayor detalle
• Los datos que fluyen hacia los procesos experimentan cambios. Por consiguiente, el
flujo de datos de salida tiene un nombre diferente al de la entrada; si no se efectúa
algún cambio en el flujo de datos, entonces ¿cuál es la finalidad del proceso?
• En cuanto a los nombres de los procesos lo más apropiado es escoger un verbo y un
sujeto que reciba la acción y no nombre generales que no digan nada. Si un nombre
de proceso es vago o complejo tal vez se deba subdividir el proceso aún más.

Por otra parte no se ha mencionado nada aún sobre controles en los DFD, no hemos
mencionado nada al respecto sobre como manejar errores o excepciones, por ejemplo el
procesamiento de facturas incorrectas. Aunque esta información es necesaria para el
análisis final, no es importante identificar todos los flujos de datos (los errores o
excepciones son también flujos de datos). Los diagramas secundarios (por debajo del
segundo o tercer nivel), deben mostrar el manejo de errores y excepciones del proceso.
Aun así ciertos detalles físicos como el día de la semana que se debe hacer un
pago u otros controles de este tipo son innecesarios en los DFD, puesto que no tienen
nada que ver con los aspectos lógicos y de datos de la determinación de requerimientos.
Los elementos importantes para comprender un proceso durante el análisis lógico de
flujo de datos, no son el número de copias que se requieren de un documento sino las
descripciones de los datos necesarios para llevar a cabo el proceso.
 Diccionario de datos
Un diccionario de datos es un catálogo, un depósito, de los elementos de un
sistema. Estos elementos se centran alrededor de los datos y la forma en que están
estructurados para satisfacer los requerimientos y las necesidades de la organización. En
él se encuentran la lista de todos los elementos que forman parte del flujo de datos en
todo el sistema.
Importancia del diccionario:
Los analistas usan los diccionarios de datos por cinco razones principales:
• Manejar los detalles en sistemas grandes
• Comunicar un significado común para todos los elementos del sistema
• Documentar las características del sistema
• Facilitar el análisis de los detalles con la finalidad de evaluar las
características y determinar donde efectuar cambios en el sistema
• Localizar errores y omisiones en el sistema

Contenido de un registro del diccionario:

• Campos: es el nivel más importante de datos; ninguna unidad más pequeña
tiene significado para los analistas. La descripción de los datos debe ir
acompañada por los siguientes elementos:

• Estructuras de datos: son un grupo de datos elementales que están

relacionados con otros y que en conjunto describen un componente del
sistema. Los flujos de datos, o los almacenes de datos son ejemplo de
estructuras de datos. Dicho de otra forma si las estructuras están en
movimiento reciben el nombre de flujos y si son estéticas son almacenes de
datos. Se construyen sobre cuatro relaciones de componentes; que bien
pueden ser datos o estructuras de datos también. Se pueden usar las
siguientes combinaciones ya sea en forma individual o en conjunción con
alguna otra:
 Relación secuencial
 Relación de selección
 Relación de iteración
 Relación opcional
Notación empleada en el Diccionario de datos 2:
Se usa símbolos especiales con la finalidad de limitar la cantidad de texto
necesario empleado para describir las relaciones entre los datos y al mismo tiempo
mostrar con claridad las relaciones estructurales.
La simbología empleada se describe a continuación:

Símbolo Significado Explicación Uso

= Es equivalente a Alias Denota sinónimos
+ Y Concatenación, Denota una relación
componentes que siempre de secuencia
están incluidos en una
estructura
[] Uno u otro Define opciones entre los Denota una relación
componentes de una de selección
estructura
{} Iteraciones de Define la repetición de un Denota una relación
componente de la estructura de iteración
() Opcional Define componentes de la Denota una relación
estructura que puede o no opcional.
estar presente una sola vez

Registro de las descripciones de datos en el diccionario:

 Flujos de datos
• Nombre del flujo de datos
• Descripción
• Proviene de los procesos
• Para los procesos
• Estructuras de datos:

 Almacenes de datos
• Nombre del almacén
• Descripción
• Flujos de datos recibidos
• Flujos de datos proporcionados
• Descripción de los datos (mención a los datos o estructuras que contiene)
• Volumen
• Acceso

 Estructuras de datos (es aquí donde es emplea la notación descrita en la tabla

anterior)
• Nombre de la estructura
• Descripción
• Contenido
• Volumen
2
Esta notación es la empleada para describir un sistema en uso
 Elementos datos
• Nombre del dato
• Descripción
• Tipo
• Longitud
• Alias
• Rango de valores
• Lista de valores específicos (en caso que existan)
• Otros detalles de edición

 Procesos
• Nombre del proceso
• Descripción
• Flujos que entran
• Flujos que salen
• Resumen de la lógica

Comentario:
Una forma para desarrollar la investigación y desarrollo de sistemas puede
verse como sigue:
1. Investigación preliminar
2. Determinación de requerimientos
3. DFD del sistema en uso
 Flujos
 Almacenes
 procesos
4. DD
 Datos
 Flujos
 Almacenes
 Estructuras
 Procesos
5. E-R
6. DFD del sistema propuesto
7. Diseño
 Entradas
 Salidas
 Etc.
8. Implementación