Tema 1. Análisis Estructurado de Sistemas (AES) .: Procesamiento de Datos Unidad 2

MINISTERIO DE LA DEFENSA
UNIVERSIDAD NACIONAL REPÚBLICA BOLIVARIANA DE VENEZUELA

EXPERIMENTAL POLITÉCNICA DE LA FUERZA ARMADA
UNEFA – NÚCLEO YARACUY
PROCESAMIENTO DE DATOS
Unidad 2
Ing. Lucia Morera
Tema 1. Análisis Estructurado de Sistemas (AES).

Es un método para el análisis de sistemas manuales o automatizados, que
conducen al desarrollo de especificaciones para sistemas nuevos o para efectuar
modificaciones a los ya existentes. Permite al analista conocer un sistema o proceso
(actividad) en una forma lógica y manejable al mismo tiempo que proporciona la
base para asegurar que no se omite ningún detalle pertinente. Su objetivo es
organizar las tareas asociadas con la determinación de requerimientos para obtener
la comprensión completa y exacta de una situación dada. A partir de aquí determina
los requerimientos que serán la base de un sistema nuevo o modificado.
En el análisis estructurado la palabra estructura significa que:
1. El método intenta estructurar el proceso de determinación de los

requerimientos comenzando con la documentación del sistema existente.
2. El proceso está organizado de tal forma que intenta incluir todos los detalles
relevantes que describen al sistema en uso.
3. Es fácil verificar cuando se han omitido detalles relevantes.
4. La identificación de los requerimientos será similar entre varios analistas e

incluirá las mejores soluciones y estrategias para las oportunidades de desarrollo de
sistemas.
5. Los documentos de trabajo generados para documentar los sistemas

existentes y propuestos son dispositivos de comunicación eficiente.
Parte del valor del análisis estructurado de sistema radica en proveer al

diseñador las entradas necesarias para definir los programas de modo de obtener la
máxima confiabilidad o facilidad para su cambio, empleando diseño estructurado.
Entre sus ventajas tenemos que permite concebir soluciones alternativas más
creativas. Se percibe fácilmente las necesidades de la empresa y los usuarios. Ayuda
a describir las actividades y procesos realizados en la organización de una forma
clara. Permite determinar si hay fallas en el procesamiento de los datos.
Herramientas del AES
Para estudiar las herramientas del Análisis Estructurado de Sistemas,

existen algunos puntos introductorios que necesitamos repasar. Un modelo es
Ing. Lucia Morera UNEFA 1

Procesamiento de Datos. Unidad 2.
Programación Estructurada: Análisis Estructurado de Sistemas (AES). Herramientas del AES.
un simulacro a bajo costo de un sistema complejo que se desea estudiar. Se

construyen modelos de sistemas por tres motivos:
1. Para enfocar características importantes del sistema, a la vez que para

minimizar las características menos importantes.
2. Para discutir cambios y correcciones a los requerimientos del usuario, a

bajo costo y con riesgo mínimo.
3. Para verificar que se entiende el ambiente del usuario, y que se ha

documentado de tal manera que los diseñadores y programadores puedan
construir el sistema.
Sin embargo, existen muchos tipos diferentes de modelos que se

pueden construir para el usuario: modelos narrativos, modelos de prototipos,
modelos gráficos diversos, etc. De hecho, el sistema final que se le construirá
al usuario pudiera resultar ser un modelo, en el sentido de que puede
representar, por primera vez, una manera de que el usuario visualice lo que
desea.
¿Cuál modelo debemos usar? La premisa básica es que debe usarse

cualquier modelo que funcione en la situación en la que se encuentra. Los
diferentes usuarios pudieran requerir distintas herramientas de modelado, sea
por su experiencia pasada o porque ciertos tipos de diagramas los confunden o
intimidan. Diferentes proyectos pudieran requerir de distintas herramientas
para cumplir con los estándares de documentación impuestos por
organizaciones externas. Y diferentes tipos de sistemas pudieran requerir de
modelos diversos para poder destacar adecuadamente características
importantes.
Para llevar más lejos esto, la mayoría de los sistemas requieren de

múltiples modelos: cada modelo se enfoca a un número limitado de aspectos
del sistema a la vez que minimiza (o ignora totalmente) otros de sus aspectos.
Esto se da sobre todo en muchos de los sistemas que se están construyendo
actualmente, pues tienen características funcionales complejas, estructuras
de datos complejos, y consideraciones complejas de tiempos.
Cualquier herramienta que use debiera tener las siguientes características:
• Debe ser gráfica, con detalles textuales de apoyo apropiados.
• Debe permitir que el sistema sea visto en segmentos, en forma

descendente.
• Debe tener redundancia mínima.

• Debe ayudar al lector a predecir el comportamiento del sistema.
• Debe ser transparente para el lector.
A continuación, discutiremos con más detalle cada uno de estos puntos.
Modelos gráficos.
La mayoría de los modelos populares de sistemas, se apoyan mucho en

gráficas. No es requisito usar gráficas en un modelo de sistemas, pero el viejo
adagio de que "una imagen vale más que mil palabras" es una buena
explicación de nuestra preferencia por las gráficas en lugar de texto
narrativo. Una imagen bien escogida puede transmitir de manera concisa y
compacta una gran cantidad de información.
Esto no significa necesariamente que una imagen pueda describir todo

lo referente a un sistema; hacerlo normalmente significaría tener un desorden
que nadie quisiera mirar. En general, se utilizan los gráficos para identificar
los componentes de un sistema y su interfaz. Todos los demás detalles (esto
es, las respuestas a preguntas tales como "¿Cuántos?" y "¿En qué orden?", etc.)
se presentan en documentos textuales de apoyo. Los textos de apoyo son la
especificación del proceso y el diccionario de datos. Esto no significa que
todos los analistas deban usar un conjunto particular de herramientas gráficas
y de textos; es recomendable que uno o más gráficos debieran ser el
documento primario al que se dirige el usuario para poder entender el
sistema; los documentos textuales debieran servir de material de referencia
para consulta en caso de necesidad
Modelos segmentables en forma descendente
Un segundo aspecto importante de una buena herramienta de modelado

es su capacidad de mostrar un sistema por partes en forma descendente. Esto
no es importante para sistemas pequeños, pues de ellos se puede decir todo lo
necesario en una o dos páginas, y cualquiera que necesite conocer algún
aspecto del sistema bien puede conocerlo en su totalidad.
Sin embargo, los proyectos reales en el mundo real generalmente no

son pequeños. De hecho, muchos de los proyectos en los que es probable que
se involucre serán desde medianos hasta enormes. En consecuencia, será
imposible que alguien, sea usuario, analista o programador, se enfoque a todo
el sistema al mismo tiempo. Tampoco será posible presentar un modelo
gráfico de un sistema grande y complejo en una sola hoja de papel, a menos,
claro, que se considere el extremo de tener una microficha de 2 x 3 metros.
Por eso, nuestras herramientas deben permitirnos mostrar partes individuales

del sistema de manera independiente, junto con una forma sencilla de

moverse de una parte a otra del modelo del sistema.
Sin embargo, se necesita más que esto: no sería apropiado, por

ejemplo, crear un modelo gráfico enorme de 30 x 30 metros y luego cortarlo
en 3000 pedazos individuales de medio metro cuadrado, con miles de
conectores de hoja a hoja. Esto equivaldría, a grandes rasgos, a dibujar un
mapa de las calles de todo un país en una sola hoja y luego partirla en miles
de pedacitos del tamaño de una página.
De hecho, la experiencia con mapas y atlas ilustra cómo debe

organizarse un modelo de un sistema complejo. Por ejemplo, un atlas de
Venezuela empieza generalmente por un solo diagrama de una página de todo
el país. Dicha página muestra las regiones individuales, y pudiera también
mostrar las principales interfaces entre las regiones (ríos, autopistas, rutas
aéreas, etc.). Las siguientes páginas se dedican normalmente a cada región
individual, en donde cada página muestra las ciudades y municipios de la
región, al igual que las autopistas locales que no aparecen en el mapa de nivel
nacional. Podríamos imaginar mapas de nivel menor que proporcionarían
detalles de cada estado, de cada ciudad dentro de un estado determinado, y
de cada barrio dentro de una ciudad dada.
Un buen modelo de un sistema complejo de información debería

preceder de la misma manera descendente. Una porción de la vista global de
alto nivel del modelo debe dar al lector buena idea de los principales
componentes de alto nivel y de las interfaces del sistema. Las siguientes
porciones del modelo deberían proporcionar información respecto a los
componentes detallados de bajo nivel. Y así como el atlas proporciona un
mecanismo conveniente para recorrer el conjunto completo de mapas
individuales (esto es, llegar sin mayor confusión del mapa de nivel nacional al
mapa apropiado al nivel municipal), un buen modelo de un sistema de
información proporciona un mecanismo conveniente para pasar
tranquilamente de un nivel alto a uno bajo.
Modelos mínimamente redundantes.
Los modelos son representación de algún sistema del mundo real y el

sistema mismo pudiera ser estático (no cambiante) o dinámico. Un mapa de
Venezuela, por ejemplo, es una representación gráfica del país. Mientras que
muchos de sus aspectos son obviamente muy dinámicos, podría decirse que los
aspectos que modela un mapa son relativamente estáticos: las regiones
individuales no aparecen o desaparecen muy a menudo y las fronteras entre
ellos han permanecido constantes durante un tiempo bastante largo. (En
cambio, no puede decirse esto de un mapa de todo el mundo).

¿Por qué importa esto a quien construye un modelo? Simplemente,

porque es deseable mantenerlo en forma actualizada y precisa. Si el sistema
cambia, entonces debe cambiar el modelo, si ha de tenerse actualizado.
Obviamente, si sólo cambia un aspecto local del sistema, preferiríamos
cambiar sólo un aspecto local correspondiente del modelo, sin tener por
fuerza que cambiar algún otro. De hecho, si se requieren múltiples cambios,
existe una buena probabilidad de que no se hagan o de que se harán
desordenadamente. Y esto significa que el modelo se volverá gradualmente
menos preciso.
Modelos transparentes.
Finalmente, un buen modelo debe ser tan fácil de leer que el lector no
tenga que detenerse a pensar siquiera que se trata de la representación de un
sistema y no del sistema mismo. Esto no siempre es fácil de lograr y a menudo
requiere de práctica y preparación por parte del lector. Piense por ejemplo
en un mapa: ¿qué tan a menudo se pone a pensar en que está mirando una
representación abstracta de la región Costera y no la realidad misma? Por otro
lado, observe a un niño pequeño que esté viendo un mapa mientras sus padres
o su maestro pretenden explicarle que Nirgua tiene frontera con Chivacoa y
San Felipe a 50 kilómetros de Chivacoa. "No, no es cierto", dirá el niño,
"Chivacoa está a dos centímetros de San Felipe”. Al crecer, nos familiarizamos
cada vez más con el concepto de las representaciones abstractas, siempre que
nos parezcan cómodas mentalmente. Los científicos han estudiado el
comportamiento y la organización del cerebro humano y han encontrado que
el hemisferio izquierdo realiza los procesos secuenciales. También se hace
cargo de los textos; por ejemplo, las palabras que está leyendo, una tras otra,
en esta página. El hemisferio derecho trata con las imágenes y el
procesamiento asincrónico, donde "todo sucede a la vez". Esto indica que, si
estamos tratando de modelar algo que es intrínsecamente lineal y secuencial,
como el flujo de control en un programa de computadora, debemos usar una
herramienta de modelado textual que quepa cómodamente en el hemisferio
izquierdo, que será el mejor equipado para tratarlo. Y si estamos tratando de
modelar algo que es intrínsecamente multidimensional, con muchas
actividades que se dan a la vez, debemos usar una herramienta gráfica.
Diagramas de Flujo de Datos (DFD).
Un diagrama de flujo de datos es una herramienta de visualización que

se utiliza para ilustrar el flujo de procesos en una empresa o en un proyecto
específico dentro de esta. Destaca el movimiento de la información, así como
la secuencia de pasos o eventos necesarios para completar una tarea de
trabajo.

Los diagramas de flujo de datos describen, de la forma más amplia el

panorama general de las entradas, procesos y salidas del sistema. Se puede
usar una serie de diagrama de flujos de datos en capas para representar y
analizar los procedimientos detallados en el sistema final. (Kendall & Kendall
2005).
Los DFD’s hacen énfasis en el procesamiento o la transformación de

datos conforme éstos pasan por una variedad de procesos. En los DFD’s lógicos
no hay distinción entre los procesos manuales o automatizados. Los procesos
tampoco se representan gráficamente en orden cronológico. En vez de ello, se
agrupan sólo si el análisis detallado dicta que tiene sentido hacerlo.
Los DFD pueden variar en diseño y complejidad, de acuerdo al proceso

que representen. Pueden ir desde un simple esquema de un sistema general o
un esbozo más granular de un procedimiento de varios niveles. Un diagrama
de flujo de datos suele organizarse de forma jerárquica, mostrando todo el
sistema en un nivel, seguido de los principales subsistemas en el siguiente.
Por último, se muestran los detalles de cada subsistema primario, y los
componentes se identifican en último lugar.
Proceso del diagrama de flujo de datos
El proceso del diagrama de flujo de datos consta de cuatro

componentes principales:
Entidades externas. Organismos o sistemas externos que alimentan o

reciben la información que se transmite dentro del proceso diagramado.
Procesos. Una serie de pasos que conforman un procedimiento que

transforma las entradas o la información (por ejemplo, mediante cálculos,
lógica o cambiando su dirección) a medida que fluye por el sistema.
Almacenamiento de datos. Un receptáculo de información que se

utilizará o procesará en un momento posterior (es decir, una base de datos).
Las entradas de datos o los datos entrantes fluyen a través de un proceso y
luego a través del almacenamiento de datos. Por otro lado, las salidas de
datos o los datos salientes fluyen desde el almacenamiento de datos a través
de un proceso.
Flujo de datos. El curso que siguen las entradas de datos o información

a través de un sistema hasta que se produce la salida.
Símbolos y funciones del diagrama de flujo de datos

Un diagrama de flujo de datos utiliza símbolos estandarizados para

representar los diferentes componentes y funciones que conforman un sistema
o proceso. Hay cuatro convenciones comunes de símbolos en la diagramación
del flujo de datos.
Yourdon y DeMarco:
 Los círculos representan procesos

 Los cuadrados o rectángulos denotan las entidades externas
 Las líneas horizontales paralelas simbolizan el almacenamiento
de datos
 Las flechas indican el flujo de datos
Gane y Sarson:
 Los rombos (rectángulos con esquinas redondeadas) representan

procesos
 Los cuadrados o rectángulos denotan las entidades externas
 Los rectángulos abiertos simbolizan el almacenamiento de datos
Método de análisis y diseño de sistemas estructurados (SSADM):
 Los cuadrados o rectángulos representan procesos

 Los óvalos denotan entidades externas
 Los rectángulos abiertos simbolizan el almacenamiento de datos
Unificado:
 Los cuadrados marcados con “Proceso” representan procesos

 Las figuritas de palo (humanos) denotan entidades externas
 Los rectángulos con la etiqueta “Entidad” simbolizan el
almacenamiento

Convenciones usadas en los diagramas de flujo de datos.
En los diagramas de flujo de datos, en este curso y siguiendo a Kendall

& Kendall, se usarán cuatro símbolos básicos para graficar el movimiento de
los datos: un cuadrado doble, una flecha, un rectángulo con esquinas
redondeadas y un rectángulo abierto (cerrado en el lado izquierdo y abierto
en el derecho). Con la combinación de éstos cuatro símbolos se puede
describir gráficamente un sistema completo y varios subsistemas.

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

departamento, un negocio, una persona o una máquina) que puede enviar
datos al sistema o recibirlos de él. La entidad externa, o sólo entidad,
también se llama origen o destino de los datos, y se considera externa al
sistema descrito. A cada entidad se le asigna un nombre adecuado. La misma
entidad se podría usar más de una vez en un diagrama de flujo de datos en
particular para evitar que las líneas 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 señalando al destino de los datos. Una flecha también se
debe describir con un nombre, debido a que representa los datos de una
persona, lugar o cosa.
Un rectángulo con esquinas redondeadas se usa para mostrar la

presencia de un proceso de transformación. Los procesos siempre denotan un
cambio en los datos o una transformación de éstos; por lo tanto, el flujo de
datos que sale de un proceso siempre se designa de forma diferente al que
entra en él. Un nombre claro permite reconocer fácilmente lo que hace un
proceso. A continuación, se detalla el formato a usar para nombrar los
procesos.
1. A los procesos de alto nivel asígneles el nombre del sistema. Por ejemplo,
Sistema de control de inventarios.
2. Para nombrar un subsistema principal, use un nombre como: Subsitema de

Información de Inventarios o Sistema de Cumplimiento de Pedidos del Cliente
en Internet
3. Para los procesos detallados use un formato de verbo-sustantivo-adjetivo. El

verbo describe el tipo de actividad, tal como Calcular, Verificar, Preparar o
Imprimir. El sustantivo indica cuál es el resultado principal del proceso, tal
como Informe o Registro. El adjetivo describe el resultado específico que se
produce, tal como Nuevo Pedido o Inventario. Ejemplos de nombres
completos de los procesos Calcular Impuestos de Ventas, Verificar Estados de
Cuenta del Cliente, Verificar saldo de tarjeta de crédito y Agregar Registro de
Inventario.
A un proceso también se le debe dar un número de identificación único y

exclusivo, que indique su nivel en el diagrama.
El último símbolo básico usado en los diagramas de flujo de datos es el

rectángulo abierto, el cual representa un almacén de datos. El rectángulo se dibuja
con dos líneas paralelas cerradas por una línea corta del lado izquierdo, y abiertas
del lado derecho. Estos símbolos se dibujan con el espacio suficiente para que
quepan las letras de identificación entre las líneas paralelas. El almacén de datos

podría representar un almacén manual, tal como un gabinete de archivo, o un

archivo o una base de datos de computadora.
A los almacenes de datos se les asigna un nombre. Los almacenes de datos

temporales, tales como papel borrador o un archivo temporal de computadora, no se
incluyen en el diagrama de flujos de datos. Para identificar el nivel del almacén de
datos, a cada uno asígnele un número de referencia único, tal como D1, D2, D3, etc.
Desarrollo de diagramas de flujo de datos.
Primero, se necesita visualizar los flujos de datos desde una perspectiva

jerárquica de arriba hacia abajo. Para empezar, sintetice la historia del sistema de la
organización a una lista con las cuatro categorías de entidad externa, flujo de datos,
proceso y almacén de datos. Ésta lista a su vez le ayudará a determinar los límites
del sistema que describirá; luego empiece a dibujar el diagrama de contexto.
 Creación del diagrama de contexto. Los diagramas van de lo general a lo

específico. El diagrama de contexto inicial debe mostrar un panorama global
que incluya, las entradas básicas, el sistema general y las salidas.
El diagrama de contexto es el nivel más alto en un diagrama de flujo de

datos y contiene un sólo proceso, que representa a todo el sistema. Al
proceso se le asigna el número cero. Debe mostrar todas las entidades
externas, así como también los flujos de datos principales que van desde
y hacia dichas entidades. No contiene ningún almacén de datos.
 Dibujo del diagrama 0 (El siguiente nivel). El diagrama 0 es la ampliación

del diagrama de contexto y puede incluir hasta 9 procesos. Si se incluyen más
procesos en éste nivel se producirá un diagrama difícil de entender. Por lo
general, cada proceso se enumera con un entero, empezando en la esquina
superior izquierda del diagrama y terminando en la esquina inferior derecha.
En el diagrama 0 se incluyen los principales almacenes de datos del sistema
(que representan a los archivos maestros) y todas las entidades externas.
Debido a que un diagrama de flujo de datos es bidimensional, usted puede

empezar en cualquier punto del diagrama e ir hacia delante o hacia atrás. Si
no está seguro de lo que podría incluir en cualquier punto, tome una entidad
externa, un proceso o un almacén de datos diferente y empiece a dibujar el
flujo a partir de él:
1. Escoja una entidad del lado de entradas al sistema, y sobre ese flujo
de datos haga preguntas tales como: “¿Qué sucede con los datos que entran al
sistema?” “¿Se Almacenan?” “¿Ésta entrada es para varios procesos?”
2. Un flujo de datos de salida, puede trabajarlo hacia atrás. Examine los

campos de salida de un documento o pantalla. Puede hacer preguntas sobre
esos datos: “¿De dónde viene?” o “¿Se calcula o almacena en un archivo?”

3. Examine el flujo de datos desde o hacia un almacén de datos.

Pregunte: ¿Qué procesos ponen los datos en el almacén? O ¿Qué procesos usan
los datos?.
4. Analice un proceso bien definido. Vea que entrada de datos necesita el

proceso y que salida produce. Después vincule 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 problemáticas podrá realizar una lista de preguntas para las entrevistas
de seguimiento con los usuarios clave.
 Creación de Diagramas Hijos (Niveles más detallados). Cada proceso del

Diagrama 0 se puede, a su vez, ampliar para crear un diagrama hijo más
detallado. El proceso del diagrama 0 a partir del cual se realiza la ampliación
se llama proceso padre, y el diagrama que se produce se llama diagrama hijo.
La regla principal para cear diagramas hijos, el equilibrio vertical, estipula
que un diagrama hijo no puede producir salida o no puede recibir entradas
que el proceso padre no produzca o reciba también. Es decir, que todos los
flujos de datos hacia adentro o hacia afuera del proceso padre se deben
mostrar fluyendo hacia adentro o hacia afuera del diagrama hijo.
Al diagrama hijo se le asigna el mismo número que a su proceso padre en el

diagrama 0. Los procesos del diagrama hijo se numeran usando el número del
proceso padre, un punto decimal y un sólo número para cada proceso hijo. Por
lo regular las entidades no se muestran en los diagramas hijos. 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 vacía del diagrama hijo. El
diagrama hijo podría contener almacenes de datos que no se muestran en el
proceso padre.
Ejemplo de un diagrama de Flujo de datos.
1. Diagrama del proceso de Solicitud de Empleo.

2. La corporación de nuestro ejemplo es FilmMagic, una cadena de alquiler de

videos fundada por tres personas con experiencia en el negocio del alquiler de
videos. En la figura se listan un resumen de las actividades de negocios obtenido de
entrevistas realizadas a los propietarios de Filmmagic. El plan es contar con una serie
de tiendas distribuidas estratégicamente alrededor de un área metropolitana. La
compañìa también ha adoptado la singular política de otorgar alquiler gratuito de
DVDs o juegos a los clientes que alquilen cantidades considerables de videos, en un
intento por conseguir una buena participación de mercado. Según uno de los
propietarios de la compañía: “si las aerolíneas tienen programas de viajeros
frecuentes, nuestra tienda de videos puede contar con un programa de alquileres
recurrentes”. En consecuencia, un programa de bonos mensuales para los clientes
será parte del sistema.

Diagrama de
Contexto

Diagrama 0
Diccionario de Datos (DD).
Un diccionario de datos, o repositorio de metadatos, como lo define el

IBM Dictionary of Computing, es un repositorio centralizado de información
sobre datos tales como significado, relación con otros datos, origen, uso y
formato.
En un diccionario de datos se encuentra la lista de todos los elementos

que forman parte del flujo de datos en todo el sistema. Los elementos más
importantes son flujos de datos, almacenes de datos y procesos. El diccionario
guarda los detalles y descripciones de todos estos elementos. Si los analistas
desean conocer cuántos caracteres abarca un determinado dato o qué otros
nombres reciben en distintas partes del sistema, o dónde se utiliza,
encontrarán las respuestas en un diccionario de datos desarrollado en forma
apropiada.

El diccionario se desarrolla durante el análisis de flujo de datos y

auxilia a los analistas que participan en la determinación de los
requerimientos de sistemas.
Tiene por objetivo proveer un lenguaje común entre el autor de dichos

datos y sus posibles usuarios.
¿Por qué son importantes los diccionarios de datos?
Los diccionarios de datos nos permiten entender e interpretar un

conjunto de datos o base de datos al proporcionar información básica sobre
los campos o variables que contiene. Brindan la siguiente información:
• Qué significa cada campo o variable.

• Qué tipo de datos contiene.
• Qué valores puede tomar, o si usa algún catálogo.
• Si contiene información pública, confidencial, o reservada.
• Entre otros.
Los conjuntos o bases de datos sin un diccionario de datos pueden

derivar en malas interpretaciones y mal uso de los datos. En algunos casos, los
datos son inutilizables ya que su interpretación se vuelve imposible.
¿Para qué se usan los diccionarios de datos?
Documentar: proveen detalles sobre la estructura de los datos a las

personas usuarias, desarrolladores, u otros actores interesados.
Comunicar: proveen a las personas usuarias de vocabulario y

definiciones comunes para el intercambio de datos y uso de los datos.
Integración de datos: definiciones claras de los elementos del conjunto

de datos, bases de datos y/o sistema, proveen comprensión sobre el contexto
necesario para decidir cómo integrar los datos en distintos subsistemas.
Principios de los diccionarios de datos.
• Los diccionarios de datos están diseñados para facilitar la comprensión y

proveer de sentido, por tanto deben documentar la existencia, el significado y
el uso de cada elemento del conjunto y/o base de datos.
• Los diccionarios de datos deben ser accesibles para todas las personas
usuarias que ingresan y extraen datos.
• Las personas responsables de los datos deben mantener actualizado el

contenido del diccionario de datos, incluidas sus definiciones y sus valores.

• Los diccionarios de datos deben revisarse periódicamente para garantizar su

vigencia.
Tipos de Diccionario de Datos.
Activos. Solo para bases de datos. Se generan y se actualizan

automáticamente por el sistema gestor de la base de datos (SGBD). En la
mayoría de los casos pueden configurarse para cumplir con las características
que el usuario determine.
Pasivos. Deben ser generados de forma manual, principalmente para

los conjuntos de datos que no utilizan un sistema gestor de base de datos,
como aquellos en xlsx o csv.
Elementos Básicos de un diccionario de datos.
NOMBRE DE LA BASE Y/O CONJUNTO DE Escribir el nombre de la base o conjunto

DATOS de datos
NOMBRE DE LA TABLA DE LA BASE DE Registrarlo si:

DATOS / NOMBRE DE LA HOJA DEL
 El conjunto de datos está en un
CONJUNTO DE DATOS
archivo excel y los datos están
registrados en más de una hoja
de cálculo.
Escribir el nombre de la hoja
donde está registrado el campo.
 Para bases de datos relacionales
se debe escribir el nombre de la
tabla donde está registrado el
campo.
Si existe solo una hoja o tabla escribir el
nombre de dicha hoja o tabla.
ETIQUETA DEL CAMPO, VARIABLE O Escribir el nombre con el cual se

ATRIBUTO identifica al campo o atributo.
En un conjunto de datos son los
encabezados de los campos o títulos de
columna.
DESCRIPCIÓN Explicación breve del campo, variable o

atributo.
Esta descripción debe contener:
 Información que proporciona el

campo.
 Unidad de medida
Para el caso de bases de datos: ¿Es una
clave primaria?
TIPO DE DATO Puede ser alguno de los siguientes tipos:

 alfanumérico
 número entero
 número con decimales
 fecha (aaaa-mm-dd)
 fecha y hora (aaaa-mm-dd
hh:mm:ss)
 fecha y hora, incluyendo la zona
horaria (aaaa-mm- dd hh:mm:ss
UTC-5)
 hora (hh:mm:ss)
 booleana (dumm) (VERDADERO,
FALSO; 0, 1)
 geometry (para datos
geoespaciales)
En caso de base de datos utilizar el tipo
de campo que determine el sistema
gestor (SGBD).
CLASIFICACIÓN DE LA  Reservada. Se encuentra

temporalmente reservada porque
INFORMACIÓN
su uso y difusión puede poner en
riesgo la vida, seguridad o salud
de una persona física, interferir
en la persecución de delitos,
afectar la seguridad nacional, etc.
 Confidencial. Contiene datos
personales concernientes a una
persona física identificada o
identificable.
 Pública. Información en posesión
de cualquier autoridad que no sea
reservada o confidencial.
RANGO O Especificación del rango de todos los

valores que puede tomar el campo.

VALORES QUE Si puede tomar cualquier valor dentro
de un rango establecido, indicar los
PERMITE EL
extremos de ese rango.
CAMPO
Ejemplos:
 Numérico: 0 – 99
 Fecha y hora: 2000-01-01 00:00:00
a 2020-12-31 23:59:59
 Texto: Caracteres libres
Si solo puede tomar un número limitado
de valores, y cada valor representa una
categoría, indicar todas las posibles
opciones (variable
categórica). Ejemplos:
 Si el campo es "Estado Civil", el
rango es: Soltero(a); Casado(a);
Viudo(a); Divorciado(a)
 Si el campo es sexo: Hombre (H),
Mujer (M), Prefiere no decir.
 Si la variable es parentesco: 1=
Padre; 2=Madre; 3= Sin familiar
ESPECIFICACIONES Registrarlo si:

Y/O REGLAS DE Existe alguna aclaración adicional,
metodológica, técnica y/o reglas de
CÁLCULO
cálculo del campo que deba ser precisada
para su entendimiento.
Si no existe ninguna especificación,
registrar "No aplica".
OBLIGATORIEDAD Determinar si al momento de su captura

este campo es:
DEL CAMPO
 Obligatorio
 Opcional
Esto le facilita a los usuarios de los datos
identificar errores en los datos, valores
faltantes o registros incompletos.
REGISTRO DE Si existen datos vacíos (conocidos como

missing values) se debe especificar el

valor con el que se registren.
CAMPOS VACÍOS
Ejemplo: null, NA, N/A, 99, 999, s/d, No
aplica, Sin información, sin valor.
Si el campo no permite registros vacíos
indicar "SIN DATOS VACÍOS".
Descripción de Procesos (DP).
Hemos visto que antes de la descripción de procesos, es conveniente

hacer un mapa general de los procesos en el área que someteremos a estudio
o levantamiento; para esto nos apoyaremos en modelos gráficos. Luego, para
cada proceso general que hemos identificado en el mapa, deberemos
proceder a asignarle una identificación, un nombre funcional, su delimitación,
destinatarios y las condiciones óptimas tanto para quienes lo ejecutan como
para sus destinatarios.
Luego viene el elemento central de la gestión de los procesos que es su

descripción, la cual consta de un área descriptiva y de un área gráfica, que
son complementarias y que deberán contener al menos la siguiente
información:
 Recursos o input: son los elementos materiales, de información u otros

que pueden incluso ser intangibles (como el conocimiento empírico de
los profesionales) que el proceso consume o necesita para poder
generar la salida u output.
 Actividades: es la descripción secuencial, en orden cronológico, de las

actividades y sus respectivas tareas, que tienen que realizar los
participantes (protagonistas).
 Protagonistas o actores: personas o grupos de personas que desarrollan

las actividades y tareas del proceso.
 Salida: resultado del proceso, el output, aquello para lo cual ha sido

diseñado el proceso.
 Destinatario: persona o conjunto de personas que reciben y valoran la

salida del proceso.
 Indicadores: estas mediciones permiten hacer un seguimiento y

valoración del cumplimiento de los objetivos del proceso. En estricto
rigor no son parte de la descripción del proceso, pero al momento de

hacer este trabajo es adecuado incluir este aspecto por la estrecha

relación que tiene con el trabajo de levantamiento.
 Diagrama de flujo del proceso (flujograma): es la expresión gráfica

del proceso, que resulta de mucha utilidad porque facilita su análisis y
rediseño.

Tema 1. Análisis Estructurado de Sistemas (AES) .: Procesamiento de Datos Unidad 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 1. Análisis Estructurado de Sistemas (AES) .: Procesamiento de Datos Unidad 2

Cargado por

Copyright:

Formatos disponibles

MINISTERIO DE LA DEFENSA

UNIVERSIDAD NACIONAL REPÚBLICA BOLIVARIANA DE VENEZUELA

Ing. Lucia Morera

Tema 1. Análisis Estructurado de Sistemas (AES).

En el análisis estructurado la palabra estructura significa que:

1. El método intenta estructurar el proceso de determinación de los

3. Es fácil verificar cuando se han omitido detalles relevantes.

4. La identificación de los requerimientos será similar entre varios analistas e

5. Los documentos de trabajo generados para documentar los sistemas

Parte del valor del análisis estructurado de sistema radica en proveer al

Herramientas del AES

Para estudiar las herramientas del Análisis Estructurado de Sistemas,

Ing. Lucia Morera UNEFA 1

un simulacro a bajo costo de un sistema complejo que se desea estudiar. Se

1. Para enfocar características importantes del sistema, a la vez que para

2. Para discutir cambios y correcciones a los requerimientos del usuario, a

3. Para verificar que se entiende el ambiente del usuario, y que se ha

Sin embargo, existen muchos tipos diferentes de modelos que se

¿Cuál modelo debemos usar? La premisa básica es que debe usarse

Para llevar más lejos esto, la mayoría de los sistemas requieren de

Cualquier herramienta que use debiera tener las siguientes características:

• Debe ser gráfica, con detalles textuales de apoyo apropiados.

• Debe permitir que el sistema sea visto en segmentos, en forma

• Debe tener redundancia mínima.

Ing. Lucia Morera UNEFA 2

• Debe ayudar al lector a predecir el comportamiento del sistema.

• Debe ser transparente para el lector.

A continuación, discutiremos con más detalle cada uno de estos puntos.

La mayoría de los modelos populares de sistemas, se apoyan mucho en

Esto no significa necesariamente que una imagen pueda describir todo

Modelos segmentables en forma descendente

Un segundo aspecto importante de una buena herramienta de modelado

Sin embargo, los proyectos reales en el mundo real generalmente no

Ing. Lucia Morera UNEFA 3

del sistema de manera independiente, junto con una forma sencilla de

Sin embargo, se necesita más que esto: no sería apropiado, por

De hecho, la experiencia con mapas y atlas ilustra cómo debe

Un buen modelo de un sistema complejo de información debería

Modelos mínimamente redundantes.

Los modelos son representación de algún sistema del mundo real y el

Ing. Lucia Morera UNEFA 4

¿Por qué importa esto a quien construye un modelo? Simplemente,

Diagramas de Flujo de Datos (DFD).

Un diagrama de flujo de datos es una herramienta de visualización que

Ing. Lucia Morera UNEFA 5

Los diagramas de flujo de datos describen, de la forma más amplia el

Los DFD’s hacen énfasis en el procesamiento o la transformación de

Los DFD pueden variar en diseño y complejidad, de acuerdo al proceso

Proceso del diagrama de flujo de datos

El proceso del diagrama de flujo de datos consta de cuatro

Entidades externas. Organismos o sistemas externos que alimentan o

Procesos. Una serie de pasos que conforman un procedimiento que

Almacenamiento de datos. Un receptáculo de información que se

Flujo de datos. El curso que siguen las entradas de datos o información

Símbolos y funciones del diagrama de flujo de datos

Ing. Lucia Morera UNEFA 6

Un diagrama de flujo de datos utiliza símbolos estandarizados para

 Los círculos representan procesos

 Los rombos (rectángulos con esquinas redondeadas) representan

Método de análisis y diseño de sistemas estructurados (SSADM):

 Los cuadrados o rectángulos representan procesos

 Los cuadrados marcados con “Proceso” representan procesos

Ing. Lucia Morera UNEFA 7