UNIDAD II

Herramientas para el Análisis Estructurado

Especificaciones de Procesos

Casos Prácticos

Junio 2009

República Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Superior Colegio Universitario “Francisco de Miranda”

Cátedra: Análisis y Diseño de Sistemas I

Fonten, Soveida Carnet: 3700920 Morales, Yetza Carnet: Almaro Salas, Luis Alberto Carnet: 6300028 Pacheco, Daniel Carnet: 6400478 Menoscal, Carlos Carnet: 6400408

Índice Introducción............................................................................................................................ 4 Desarrollo ............................................................................................................................... 5

Situación Actual ................................................................................................................. 5 Bases Teóricas .................................................................................................................... 5 Diagramas de Flujo de Datos (DFDs) ................................................................................ 5

Ventajas Del Enfoque Del Flujo De Datos..................................................................... 5 Convenciones Usadas En Los Diagramas De Flujo De Datos ....................................... 6 Desarrollo De Diagramas De Flujo De Datos ................................................................ 8

Creación Del Diagrama De Contexto......................................................................... 8 Dibujo Del Diagrama 0 (El Siguiente Nivel) ............................................................. 9 Creación De Diagramas Hijos (Niveles Más Detallados) ........................................ 10

Diagramas De Flujo De Datos Lógicos Y Físicos........................................................ 11 Desarrollo De Diagramas De Flujo De Datos Lógicos ............................................ 11 Desarrollo De Diagramas De Flujo De Datos Físicos.............................................. 12 Particionamiento De Los Diagramas De Flujo De Datos......................................... 13

Diccionario de Datos ........................................................................................................ 14 Necesidad De Entender El Diccionario De Datos ........................................................ 14 El Depósito De Datos ................................................................................................... 15 Definición De Los Flujos De Datos ............................................................................. 16 Descripción De Las Estructuras De Datos ................................................................... 16 Estructuras De Datos Lógicas Y Físicas ...................................................................... 17 Elementos De Datos ..................................................................................................... 17 Almacenes De Datos .................................................................................................... 20 Creación del diccionario de datos................................................................................. 20 Análisis De Las Entradas Y Salidas ............................................................................. 21 Desarrollo De Almacenes De Datos............................................................................. 22 Uso Del Diccionario De Datos ..................................................................................... 22

Casos Prácticos ................................................................................................................. 23 Diagramas de Flujo de Datos........................................................................................ 23

Narrativa del Sistema................................................................................................ 23 Síntesis de la narrativa del sistema........................................................................... 23 Diagrama de Contexto.............................................................................................. 25 Diagrama 0 ............................................................................................................... 26 Diagrama 1 ............................................................................................................... 27 Diagrama 1.1 ............................................................................................................ 28 Diagrama 1.2 ............................................................................................................ 29 Diagrama 2 ............................................................................................................... 30 Diagrama 2.1 ............................................................................................................ 31 Diagrama 2.2 ............................................................................................................ 31 Diagrama 2.3 ............................................................................................................ 32 Diagrama 2.4 ............................................................................................................ 32 Diagrama 2.5 ............................................................................................................ 33

Diccionario de Datos .................................................................................................... 34 Conclusiones......................................................................................................................... 37

Bibliografía........................................................................................................................... 38

Introducción El uso de las herramientas de análisis estructurado es fundamental en el desempeño de las funciones del analista de sistemas, obtener información adecuada para la realización de una propuesta y posterior desarrollo de un sistema exitoso necesariamente pasa por la aplicación de las técnicas que estas herramientas brindan. En el presente trabajo tomaremos una situación hipotética en la cual la “Universidad Politécnica Generalísimo Francisco de Miranda” requiere la implantación de un sistema que permita llevar el control de las notas de los alumnos. Daremos por sentado que el levantamiento de requerimientos ya fue realizado y pasaremos a la siguiente fase en la cual demostraremos el uso de los diagramas de flujo de datos (DFDs) y de los diccionarios de datos. Como parte del desarrollo del trabajo, como base teórica, haremos una extensa explicación de las herramientas antes mencionadas así como de los conceptos utilizados en ellas. La aplicación de de las técnicas descritas en cada herramienta se verá en el desarrollo de los casos prácticos.

Desarrollo

Situación Actual

Bases Teóricas

Diagramas de Flujo de Datos (DFDs) Cuando los analistas de sistemas intentan entender los requerimientos de información de los usuarios, deben tener la oportunidad de visualizar como se mueven los datos en la organización, los procesos o transformaciones que sufren dichos datos y cuáles son los resultados. Aunque las entrevistas y la investigación de datos reales y concretos proporcionan una descripción verbal del sistema, una representación visual puede consolidar esta información de manera mucho más útil. El analista de sistemas puede elaborar una representación grafica de los procesos que se realizan con los datos en toda la organización, mediante una técnica de análisis estructurada llamada diagramas de flujo de datos (DFDs). Con el uso de tan sólo cuatro símbolos, el analista de sistemas puede crear una descripción gráfica de los procesos que, con el tiempo, contribuirán a desarrollar una sólida documentación del sistema.

Ventajas Del Enfoque Del Flujo De Datos

El enfoque del flujo de datos posee cuatro ventajas principales sobre las explicaciones descriptivas en relación con la forma en que los datos se mueven a través del sistema:

1. Libertad para emprender la implementación técnica del sistema en las etapas tempranas.

2. Una comprensión más profunda de la interrelación entre sistemas y subsistemas.

3. Comunicar a los usuarios el conocimiento sobre el sistema actual mediante diagramas de flujo de datos.

4. Análisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios.

Quizás la ventaja más grande es la libertad conceptual para utilizar los cuatro símbolos, ninguno de los símbolos especifica los aspectos físicos de la implementación. Los DFDs hacen énfasis en el procesamiento o la transformación de datos conforme éstos pasan por una variedad de procesos. En los DFDs lógicos no hay distinción entre 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 procesos manuales se agrupan, y los procesos automatizados también se pueden agrupar. Este concepto, llamado particionamiento, se trata en una sección posterior.

Convenciones Usadas En Los Diagramas De Flujo De Datos En los diagramas de flujo de datos se usan 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 estos 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 datos, y se considera externa al sistema descrito. A cada entidad se le asigna un nombre

Dx

adecuado. Aunque interactúa con el sistema, se considera fuera de los límites de éste. Las entidades se deben designar con un nombre. 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 hacia el destino de los datos. Los flujos de datos que ocurren simultáneamente se pueden describir mediante flechas paralelas. 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. Los procesos representan trabajo que se realiza en el sistema y se deben nombrar usando uno de los formatos siguientes. Un nombre claro permite reconocer fácilmente lo que hace un proceso.

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 SUBSISTEMA DE INFORMACIÓN DE INVENTARIOS o SISTEMA DE CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET.

3. Para los procesos detallados use un formato de sustantivo-verbo-adjetivo. El sustantivo indica cuál es el resultado principal del proceso, tal como INFORME o REGISTRO.

4. El verbo describe el tipo de actividad, tal como CALCULAR, VERIFICAR, PREPARAR, IMPRIMIR o AGREGAR. El adjetivo describe el resultado específico que se produce, tal como NUEVO PEDIDO o INVENTARIO. Ejemplos de nombres completos de procesos son:

a. CALCULAR IMPUESTOS DE VENTAS b. VERIFICAR ESTADOS DE CUENTA DEL CLIENTE c. PREPARAR FACTURA DE ENVÍO d. IMPRIMIR INFORME DE NUEVOS PEDIDOS e. ENVIAR CONFIRMACIÓN AL CLIENTE POR CORREO

ELECTRÓNICO f. VERIFICAR SALDO DE TARJETA DE CRÉDITO g. 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. Podría 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 ú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 derecho. Estos símbolos se dibujan con el espacio suficiente para que quepan las letras de identificación entre las líneas paralelas. En los diagramas de flujo de datos lógicos no se especifica el tipo de almacenamiento físico. En este punto el símbolo del almacén de datos simplemente muestra un lugar de depósito para los datos que permite examinar, agregar y recuperar datos. 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 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 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 Los diagramas de flujo de datos se pueden y deben dibujar de manera sistemática. Primero, el analista de sistemas necesita visualizar los flujos de datos desde una perspectiva jerárquica de arriba hacia abajo. Para empezar un diagrama de flujo de datos, se sintetiza la narrativa o 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. Esta lista a su vez le ayudará a determinar los límites del sistema que describirá. Una vez que haya recopilado una lista básica de elementos de datos, empiece a dibujar un diagrama de contexto.

Creación Del Diagrama De Contexto Con un enfoque jerárquico de arriba hacia abajo para diagramar el movimiento de los datos, los diagramas van de lo general a lo específico. Aunque el primer diagrama ayuda al analista de sistemas a entender el movimiento básico de los datos, lo general de su naturaleza limita su utilidad. El diagrama de contexto inicial debe mostrar un panorama global que incluya las entradas básicas, el sistema general y las salidas. Este diagrama será el más general, con una visión muy superficial del movimiento de los datos en el sistema y una visualización lo más amplia posible del sistema. El diagrama de contexto es el nivel más 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 número cero. En el diagrama de contexto se muestran todas las entidades externas, así como también los flujos de datos principales que van desde y hacia dichas entidades. El diagrama no contiene ningún almacén de datos. Para el analista es bastante simple crearlo una vez que conoce las entidades externas y el flujo de datos desde y hacia ellas.

Dibujo Del Diagrama 0 (El Siguiente Nivel) Al "ampliar los diagramas" 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 siguientes. Sin embargo, el resto del diagrama original se amplía para incluir de tres a nueve procesos y mostrar almacenes de datos y nuevos flujos de datos de menor nivel. El efecto es similar al de tomar una lupa para ver el diagrama de flujo de datos original. Cada diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para representar subprocesos, el analista de sistemas empieza a completar los detalles del movimiento de los datos. El manejo de excepciones se ignora en los primeros dos o tres niveles de la diagramación del flujo de datos. El Diagrama 0 es la ampliación del diagrama de contexto y puede incluir hasta nueve procesos. Si se incluyen más procesos en este nivel se producirá un diagrama difícil de entender. Por lo general, cada proceso se numera 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 en lugar de lineal, se puede empezar en cualquier punto del diagrama e ir hacia adelante o hacia atrás. Si no se 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. Empiece con el flujo de datos de una entidad en el lado de la entrada. Haga preguntas tales como: "¿Qué sucede con los datos que entran en el sistema?" "¿Se almacenan?" "¿Esta entrada es para varios procesos?"

2. Trabaje hacia atrás a partir de un flujo de datos de salida. Examine los campos de salida de un documento o pantalla. (Este enfoque es más sencillo si se han creado prototipos.) Pregunte sobre cada campo de la salida: "¿De dónde viene?" o "¿Se calcula o almacena en un archivo?" Por ejemplo, cuando la salida es un RECIBO DE NÓMINA, el NOMBRE DEL EMPLEADO y la DIRECCIÓN se podrían localizar en un archivo EMPLEADO, las HORAS TRABAJADAS podrían encontrarse en un REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se tendrían que calcular. Cada archivo y registro estaría conectado al proceso que produce el recibo de nómina.

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?" Observe que un almacén de datos utilizado en el sistema en el que esté usted trabajando podría ser producido por un sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya ningún flujo de datos hacia el almacén de datos.

4. Analice un proceso bien definido. Vea qué entrada de datos necesita el proceso y qué 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 crear diagramas hijos, 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 también. 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 número que a su proceso padre en el Diagrama 0. Por ejemplo, el proceso 3 se podría ampliar para crear el Diagrama 3. Los procesos del diagrama hijo se numeran usando el número del proceso padre, un punto decimal y un solo número para cada proceso hijo. Los procesos del Diagrama 3 se podrían numerar como 3.1, 3.2, 3.3, etc. Esta convención permite al analista localizar una serie de procesos a través de muchos niveles de ampliación. Si el Diagrama 0 presenta los procesos 1, 2 y 3, los diagramas hijos 1, 2 y 3 estarán en el mismo nivel. Por lo regular las entidades no se muestran en los diagramas hijos debajo del Diagrama 0. 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. Si el proceso padre tiene un flujo de datos conectado a un almacén de datos, también el diagrama hijo podría incluir el almacén de datos. Además, este diagrama de nivel inferior podría contener almacenes de datos que no se muestran en el proceso padre. Por ejemplo, se podría incluir un archivo que contenga una tabla de información, como una tabla de impuestos, o un archivo que conecta dos procesos del diagrama hijo. En un diagrama hijo se podría incluir un flujo de datos de nivel inferior, como una línea de error, aunque no se podría hacer lo mismo en el proceso padre. Los procesos se podrían ampliar o no ampliar, dependiendo de su nivel de complejidad. Cuando no se amplía un proceso, se dice que es funcionalmente primitivo y se llama proceso primitivo.

Diagramas De Flujo De Datos Lógicos Y Físicos Los diagramas de flujo de datos se catalogan como lógicos o físicos. Un diagrama de flujo de datos lógico se enfoca en el negocio y en el funcionamiento de éste. No se ocupa de la manera en que se construirá el sistema. Más bien, describe los eventos que ocurren en el negocio y los datos requeridos y producidos por cada evento. Por el contrario, un diagrama de flujo de datos físico muestra cómo se implementará el sistema, incluyendo el hardware, el software, los archivos y las personas involucradas en el sistema. Observe que el modelo lógico refleja el negocio, mientras que el modelo físico describe el sistema. En teoría, los sistemas se desarrollan mediante el análisis del sistema actual (DFD lógico actual) y después se agregan características que el nuevo sistema debe incluir (DFD lógico propuesto). Por último, se deben desarrollar los mejores métodos para implementar el nuevo sistema (DFD físico). El desarrollo de un diagrama de flujo de datos lógico para el sistema actual ofrece un entendimiento claro de su funcionamiento, y por lo tanto un buen punto de partida para desarrollar el modelo lógico del mismo. Con frecuencia este paso, que requiere una considerable cantidad de tiempo, se omite para ir directamente al DFD lógico propuesto. Las gráficas de navegación para los sitios Web que se crean con Microsoft FrontPage constituyen un ejemplo de un tipo de modelo lógico. Una ventaja de construir el diagrama de flujo de datos lógico del sistema actual es que se puede usar para crear el diagrama de flujo de datos lógico del nuevo sistema. Los procesos innecesarios en el nuevo sistema se podrían eliminar y agregar nuevas características, actividades, salidas, entradas y datos almacenados. Mediante este enfoque se garantiza que el nuevo sistema conservará las características esenciales del sistema anterior. Además, el uso del modelo lógico del sistema actual como base para el sistema propuesto ofrece una transición gradual para el diseño del nuevo sistema. Una vez desarrollado el modelo lógico para el nuevo sistema, se podría usar para crear un diagrama de flujo de datos físico para tal sistema.

Desarrollo De Diagramas De Flujo De Datos Lógicos Para desarrollar un diagrama de este tipo, primero construya un diagrama de flujo de datos para el sistema actual. Hay varias ventajas al usar un modelo lógico, entre ellas:

1. Mejor comunicación con los usuarios. 2. Sistemas más estables. 3. Mejor entendimiento del negocio por parte de los analistas. 4. Flexibilidad y mantenimiento. 5. Eliminación de redundancias y creación más sencilla del modelo físico.

Es más fácil usar un modelo lógico al comunicarse con los usuarios del sistema porque se centra en las actividades del negocio. En consecuencia, los usuarios estarán familiarizados con las actividades principales y con muchos de los requerimientos de información de cada actividad.

Con frecuencia, los sistemas desarrollados con un diagrama de flujo de datos lógico son más estables porque se basan en los eventos del negocio y no en una tecnología o método particular de implementación. Los diagramas de flujo de datos lógicos representan características de un sistema que deberían existir sin importar cuáles sean los medios físicos para llevarlas a cabo. Por ejemplo, las actividades tales como solicitar una credencial de socio de un videocentro, rentar un DVD y devolverlo, podrían realizarse aunque el establecimiento tenga un sistema automatizado, manual o híbrido.

Desarrollo De Diagramas De Flujo De Datos Físicos Después de desarrollar el modelo lógico del nuevo sistema, usted lo podría usar para crear un diagrama de flujo de datos físico. El diagrama de flujo de datos físico muestra cómo se creará el sistema, y generalmente contiene la mayoría, si no es que todos, de los elementos. Así como los diagramas de flujo de datos lógicos tienen ciertas ventajas, los diagramas de flujo de datos físicos tienen otras, entre ellas:

1. Aclarar qué procesos son manuales y cuáles son automatizados. 2. Describir los procesos con mayor detalle los DFDs lógicos. 3. Distribuir en un orden particular los procesos que se deben realizar. 4. Identificar los almacenes de datos temporales. 5. Especificar los nombres reales de archivos y documentos impresos. 6. Agregar controles para asegurar que los procesos se realicen

adecuadamente. Los diagramas de flujo de datos físicos son a menudo más complejos que los diagramas de flujo de datos lógicos debido a la gran cantidad de almacenes de datos que incluye un sistema. Con frecuencia se utilizan las siglas CLAE (CRUD: Créate, Read, Update and Deleté) para denotar las actividades Crear, Leer, Actualizar y Eliminar, que un sistema debe ejecutar en cada archivo maestro. Una matriz CLAE es una herramienta que sirve para representar en qué parte del sistema ocurre cada uno de estos procesos. Observe que algunos de los procesos incluyen más de una actividad. Los procesos de entrada de datos como codificar y verificar también son parte de los diagramas de flujo de datos físicos. Los diagramas de flujo de datos físicos también tienen almacenes de datos intermedios, con frecuencia un archivo de transacción o una tabla de base de datos temporal. A menudo, los almacenes de datos intermedios consisten en archivos de transacción que se utilizan para almacenar datos entre procesos. Dado que es poco probable que la mayoría de los procesos que requieren acceso a un conjunto determinado de datos se ejecuten al mismo tiempo, los archivos de transacción deben guardar los datos de un proceso para luego enviarlo al siguiente. Un ejemplo fácil de entender de este concepto se encuentra en las experiencias cotidianas relacionadas con la compra de comestibles, la preparación de la comida y la comida misma. Estas actividades son:

1. Escoger los artículos de los estantes. 2. Realizar el pedido y pagar la factura. 3. Transportar los comestibles a casa. 4. Preparar la comida. 5. Ingerir la comida.

Particionamiento De Los Diagramas De Flujo De Datos El particionamiento es el proceso de examinar un diagrama de flujo de datos y determinar cómo se debe dividir en colecciones de procedimientos manuales y colecciones de programas de cómputo. Analice cada proceso para determinar si debe ser un proceso manual o automatizado. Agrupe los procedimientos automatizados en una serie de programas de cómputo. A menudo se traza una línea punteada alrededor de un proceso o grupo de procesos que deben colocarse en un solo programa de cómputo. Existen seis razones para particionar diagramas de flujo de datos:

1. Diferentes grupos de usuarios. ¿Los procesos son realizados por varios grupos de usuarios diferentes, con frecuencia en distintas ubicaciones físicas de la compañía? Si es así, se deben particionar en diferentes programas de cómputo. Un ejemplo es la necesidad de procesar devoluciones de los clientes y pagos de los clientes en un almacén de departamentos. Ambos procesos implican obtener información financiera que se utiliza para ajustar las cuentas de los clientes (restando de la cantidad las deudas de los clientes), pero son ejecutados por diferentes grupos de usuarios en distintas ubicaciones. Cada grupo requiere una pantalla diferente para registrar los detalles de la transacción, ya sea una pantalla de crédito o una de pago.

2. Sincronización. Examine la sincronización de los procesos. Si dos procesos se realizan en diferentes momentos, no se pueden agrupar en un programa. Los aspectos de la sincronización también podrían involucrar qué cantidad de datos se presenta en un periodo determinado en una página Web. Si un sitio de comercio electrónico contiene páginas Web demasiado pesadas para pedir artículos o reservar vuelos en línea, la página Web se podría particionar en programas separados que den formato a los datos y los presenten.

3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible agruparlos en un solo programa de cómputo.

4. Eficiencia. En un programa se podrían combinar varios procesos para realizar un procesamiento eficiente. Por ejemplo, si una serie de informes requieren utilizar los mismos archivos de entrada grandes, producirlos en conjunto podría ahorrar una cantidad considerable de tiempo de ejecución de la computadora.

5. Consistencia de los datos. Los procesos se podrían combinar en un solo programa para mantener la consistencia de los datos. Por ejemplo, una

compañía de tarjetas de crédito podría requerir un análisis de los datos en un punto en el tiempo, por lo que obtendría una imagen de los datos para producir una diversidad de informes al mismo tiempo con el fin de que las cifras sean consistentes.

6. Seguridad. Los procesos se podrían particionar en diferentes programas por razones de seguridad. Se podría colocar una línea punteada alrededor de las páginas Web que se encuentren en un servidor seguro para separarlas de las que estén en un servidor no seguro. Por lo general, una página Web que se utiliza con el propósito de recabar la identificación y la contraseña del usuario se particiona de las páginas de entrada de datos o de otras páginas de negocios.

Diccionario de Datos El diccionario de datos es una aplicación especializada de los tipos de diccionarios usados como referencia en la vida cotidiana. El diccionario de datos es una obra de consulta con información acerca de los datos (es decir, metadatos), compilada por los analistas de sistemas para guiarse en el análisis y diseño. Como un documento, el diccionario de datos recopila y coordina términos de datos específicos, y confirma lo que cada término significa para las diferentes personas en la organización. Los diagramas de flujo de datos son un excelente punto de partida para recopilar entradas para el diccionario de datos. Una razón importante para mantener un diccionario de datos es guardar datos ordenados. Esto significa que los datos deben, ser consistentes. Si usted guarda datos acerca del sexo de un hombre como "M" en un registro, "Masculino" en un segundo registro y como el número "1" en un tercer registro, los datos no son consistentes. Un diccionario de datos ayudará en este aspecto. Los diccionarios de datos automatizados son valiosos por su capacidad de hacer referencias cruzadas de los elementos de datos y el lugar donde se utilizan, permitiendo por tanto realizar cambios a todos los programas que comparten un elemento común, si esto fuera necesario. Esta característica suplanta el hacer cambios al azar, y evita el tener que esperar hasta que un programa deje de funcionar porque un cambio no se ha implementado en todos los programas que comparten el elemento que se ha actualizado. Evidentemente, los diccionarios de datos automatizados se vuelven importantes para los sistemas grandes que producen miles de elementos de datos que requieren catalogación y referencias cruzadas.

Necesidad De Entender El Diccionario De Datos Muchos sistemas de administración de base de datos están equipados con un diccionario de datos automatizado. Estos diccionarios pueden ser complejos o sencillos. Algunos diccionarios de datos computarizados catalogan

automáticamente los elementos de datos cuando se hace la programación; otros simplemente proporcionan una plantilla para motivar a la persona que llene el diccionario a que lo haga de una manera uniforme para cada entrada. A pesar de la existencia de los diccionarios de datos automatizados, entender qué datos conforman un diccionario de datos, las convenciones usadas en estos últimos y cómo se desarrolla un diccionario de datos, son problemas que el analista de sistemas debe tener siempre presentes durante el esfuerzo de sistemas. Entender el proceso de compilar un diccionario de datos puede ayudar al analista de sistemas a visualizar el sistema y su funcionamiento. Las próximas secciones permiten al analista de sistemas ver la lógica detrás de lo que existe tanto en los diccionarios automatizados como en los manuales. Además de proporcionar documentación y eliminar la redundancia, el diccionario de datos se podría usar para:

1. Validar la integridad y exactitud del diagrama de flujo de datos. 2. Proporcionar un punto de partida para desarrollar pantallas e informes. 3. Determinar el contenido de los datos almacenados en archivos. 4. Desarrollar la lógica para los procesos del diagrama de flujo de datos.

El Depósito De Datos Aunque el diccionario de datos contiene información de los datos y procedimientos, una colección más grande de información de proyectos se llama depósito. El concepto de depósito es uno de los muchos impactos de las herramientas CASE y podría contener lo siguiente:

1. Información sobre los datos mantenidos por el sistema, incluyendo flujos de datos, almacenes de datos, estructuras de registros y elementos.

2. Lógica de procedimientos. 3. Diseño de pantallas e informes. 4. Relaciones entre datos, por ejemplo cómo se vincula una estructura de

datos con otra. 5. Requerimientos del proyecto y productos del sistema final. 6. Información sobre la administración del proyecto, tal como itinerarios de

entrega, logros, problemas pendientes de solución y usuarios del proyecto. El diccionario de datos se crea examinando y describiendo los contenidos de los flujos de datos, almacenes de datos y procesos. Cada almacén de datos y flujo de datos se debe definir y expandir para incluir los detalles de los elementos que contienen. La lógica de cada proceso se debe describir usando los datos que fluyen hacia el proceso o los que salen de él. Se deben detectar y resolver omisiones y otros errores de diseño.

Se deben desarrollar las cuatro categorías del diccionario de datos (flujos de datos, estructuras de datos, elementos de datos y almacenes de datos) para fomentar el entendimiento de los datos del sistema.

Definición De Los Flujos De Datos Por lo general, los flujos de datos son los primeros elementos que se definen. Las entradas y salidas del sistema se determinan mediante las entrevistas y la observación de los usuarios, y el análisis de documentos y de otros sistemas existentes. La información capturada para cada flujo de datos se podría resumir usando un formulario que contenga la siguiente información:

1. ID, un número de identificación opcional. A veces éste se codifica usando un esquema para identificar el sistema y la aplicación del sistema.

2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el texto que debe aparecer en el diagrama y se debe referenciar en todas las descripciones que usen el flujo de datos.

3. Una descripción general del flujo de datos. 4. La fuente del flujo de datos. Ésta podría ser una entidad externa, un

proceso o un flujo de datos proveniente de un almacén de datos. 5. El destino del flujo de datos (los mismos elementos que se describieron en

la fuente). 6. Algo que indique si el flujo de datos es un registro que está entrando o

saliendo de un archivo o un registro que contiene un informe, formulario o pantalla. Si el flujo de datos contiene datos que se usan entre los procesos, se designa como interno.

7. El nombre de la estructura de datos que describe los elementos encontrados en este flujo de datos. Para un flujo de datos simple, podrían ser uno o varios elementos.

8. El volumen por unidad de tiempo. Los datos podrían ser registros por día o cualquier otra unidad de tiempo.

9. Un área para comentarios adicionales y anotaciones sobre el flujo de datos.

Descripción De Las Estructuras De Datos Normalmente las estructuras de datos se describen usando una notación algebraica. Este método permite al analista producir una vista de los elementos que constituyen la estructura de datos junto con información referente a dichos elementos. Por ejemplo, el analista indicará si hay muchos elementos iguales en la estructura de datos (un grupo de repetición), o si dos elementos podrían excluirse mutuamente. La notación algebraica usa los siguientes símbolos:

1. Un signo de igual (-) significa "está compuesto de". 2. Un signo de suma (+) significa "y".

3. Las llaves {} indican elementos repetitivos, también llamados grupos de repetición o tablas. En el grupo podría haber un elemento de repetición o varios de ellos. El grupo de repetición podría tener condiciones, tal como un número fijo de repeticiones o límites superiores e inferiores para el número de repeticiones.

4. Los corchetes [ ] representan una situación de uno u otro. Se podría representar un elemento u otro, pero no ambos. Los elementos listados entre los corchetes son mutuamente excluyentes.

Estructuras De Datos Lógicas Y Físicas Cuando las estructuras de datos se definen primero, sólo se incluyen los elementos de datos que el usuario vería, tal como un nombre, dirección y saldo a pagar. Esta fase es el diseño lógico, el cual muestra qué datos necesita el negocio para sus operaciones diarias. Con el diseño lógico como base, el analista diseña a continuación las estructuras de datos físicas, las cuales incluyen los elementos adicionales necesarios para implementar el sistema. Los siguientes son algunos ejemplos de elementos del diseño físico:

1. Los campos clave se usan para localizar registros en una tabla de base de datos. Un ejemplo es el número de un artículo, el cual no se requiere para que un negocio funcione pero es necesario para identificar y localizar los registros de la computadora.

2. Los códigos para identificar el estado de los registros maestros, por ejemplo, para identificar si un empleado está activo (actualmente empleado) o inactivo. Tales códigos se pueden mantener en archivos que generen información de impuestos.

3. Los códigos de transacción se usan para identificar los tipos de registros cuando un archivo contiene diferentes tipos de registros. Un ejemplo es un archivo de crédito que contiene los registros para los artículos devueltos así como también los registros de pagos.

4. Las entradas de grupos de repetición que llevan la cuenta de los elementos hay en el grupo.

5. Los límites sobre el número de elementos aceptables en un grupo repetido. 6. Una contraseña usada por un cliente que accede a un sitio Web seguro.

Elementos De Datos Cada elemento de datos se debe definir una vez en el diccionario de datos y también se podría introducir previamente en un formulario de descripción del elemento. Las siguientes son las características que comúnmente se incluyen en el formulario de descripción del elemento:

1. ID del elemento. Esta entrada opcional permite al analista construir entradas de diccionario de datos automatizadas.

2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en el propósito al cual está destinado el elemento en la mayoría de los programas o por el usuario principal del elemento.

3. Alias, los cuales son sinónimos u otros nombres para el elemento. Los alias son nombres usados por diferentes usuarios en diferentes sistemas. Por ejemplo, NUMERO DEL CLIENTE también se podría designar como NÚMERO DE CUENTA POR COBRAR o NUMERO DEL CONSUMIDOR.

4. Una descripción breve del elemento. 5. Si el elemento es base o derivado. Un elemento base es el que se teclea

inicialmente en el sistema, tal como un nombre del cliente, dirección o ciudad. Los elementos base se deben almacenar en archivos. Los elementos derivados son creados por procesos como resultado de un cálculo.

6. La longitud de un elemento. Algunos elementos tienen longitudes estándar. Por ejemplo, en Estados Unidos la longitud para las abreviaturas de nombre de estado, los códigos postales y números telefónicos son estándar. Las longitudes podrían variar para otros elementos, y el analista y la comunidad de usuarios deben decidir en conjunto la longitud final con base en las siguientes consideraciones:

a. Las longitudes de las cantidades numéricas se deben determinar calculando el número mayor que probablemente contendrán y después dejar un espacio razonable para la expansión. Las longitudes designadas para los totales deben ser lo bastante grandes para dar acomodo a la suma de los números que acumulen.

b. A los campos de nombre y dirección se les podría asignar longitudes con base en la tabla siguiente. Por ejemplo, un campo para el apellido de 11 caracteres dará acomodo a 98 por ciento de los apellidos en Estados Unidos.

c. Para otros campos, con frecuencia es útil examinar o muestrear los datos históricos encontrados en la organización para determinar el tamaño adecuado del campo. Si el elemento es demasiado pequeño, se truncarán los datos que se necesiten introducir. El analista debe decidir cómo afectará esta situación a las salidas del sistema. Por ejemplo, si se trunca el apellido de algún cliente, por lo regular el correo aún se entregaría; sin embargo, si se trunca la dirección de correo electrónico, se devolverá como no encontrada.

7. El tipo de datos: numérico, fecha, alfabético o carácter que a veces se llama datos alfanuméricos o de texto. Los campos de carácter podrían contener una mezcla de letras, números y caracteres especiales. Si el elemento es una fecha, se debe determinar su formato —por ejemplo, MMDDAAAA—. Si el elemento es numérico, se debe determinar su tipo de almacenamiento. Hay tres formatos estándar para los mainframes: el decimal dividido en zonas, el decimal empaquetado y el binario. El formato decimal dividido en zonas se usa para imprimir y desplegar datos. El formato decimal empaquetado normalmente se usa para ahorrar espacio en los diseños de archivo y para elementos que requieren que en ellos se realice un nivel alto de aritmética. El formato binario es conveniente para los mismos propósitos

que el formato decimal empaquetado pero su uso es menos común. Los formatos de las computadoras personales, tales como moneda, numérico o científico, dependen de cómo se utilizarán los datos. Los formatos numéricos se definen aún más como entero, entero largo, precisión sencilla, precisión doble, etc. Hay muchos otros tipos de formatos que se utilizan en los sistemas de PC. Unicode es un sistema de codificación estandarizado para definir símbolos gráficos, tal como caracteres chinos o japoneses.

8. Los formatos de entrada y salida se deben incluir, usando símbolos de codificación especiales para indicar cómo se deben presentar los datos. Cada símbolo representa un carácter o dígito. Si el mismo carácter se repite varias veces, el carácter seguido por un número entre paréntesis que indica cuántas veces se repite el carácter, se sustituye con el grupo. Por ejemplo, XXXXXXXX se representaría como X(8).

9. Los criterios de validación para asegurar que el sistema capture los datos correctos. Los elementos pueden ser discretos, lo cual significa que tienen ciertos valores fijos, o continuos, con un rango parejo de valores. Los siguientes son criterios comunes de edición:

a. Un rango de valores es conveniente para elementos que contienen datos continuos. Por ejemplo, en Estados Unidos el promedio de puntos de un estudiante podría ser de 0.00 a 4.00. Si hay un solo límite superior o inferior para los datos, se usa un límite en lugar de un rango.

b. Si los datos son discretos, lo apropiado es una lista de valores. Ejemplos son los códigos que representan los colores de artículos para la venta por catálogo.

c. Una tabla de códigos es conveniente si la lista de valores es extensa (por ejemplo, las abreviaturas de los nombres de los estados, los códigos telefónicos del país o los códigos telefónicos de área de Estados Unidos).

d. Con frecuencia se incluye un dígito de verificación para las claves o los elementos de índice.

10. Cualquier valor predeterminado que pudiera tener el elemento. El valor predeterminado se despliega en las pantallas de entrada y se usa para reducir la cantidad de datos que tuviera que teclear el operador. Por lo regular, varios campos de cada sistema tienen valores predeterminados. Cuando use listas GUI o listas desplegables, el valor predeterminado es el que se encuentra seleccionado y resaltado. Al usar botones de opción, la opción para el valor predeterminado aparece seleccionada y al usar casillas de verificación, el valor predeterminado (ya sea "sí" o "no"] determina si la casilla de verificación tendrá o no una marca de verificación inicial.

11. Un área adicional para observaciones o comentarios. Aquí se podría indicar el formato de la fecha, si se requiere alguna validación especial, el método de dígito de verificación usado, etcétera.

Almacenes De Datos Todos los elementos base se deben almacenar en el sistema. También los elementos derivados se podrían almacenar en el sistema, tal como, para un empleado, el sueldo bruto acumulado a la fecha. Los almacenes de datos se crean para cada entidad de datos diferente que se almacenará. Es decir, cuando los elementos base de un flujo de datos se agrupan para formar un registro estructural, se crea un almacén de datos para cada registro estructural único. Debido a que un flujo de datos dado podría mostrar sólo una parte de los datos colectivos que un registro estructural contiene, usted tendría que examinar muchas estructuras de flujo de datos diferentes para llegar a una descripción completa de un almacén de datos.

Creación del diccionario de datos Las entradas del diccionario de datos se podrían crear después de completar el diagrama de flujo de datos, o se podrían construir conforme se desarrolle el diagrama de flujo de datos. El uso de notación algebraica y registros estructurales permite al analista desarrollar el diccionario de datos y los diagramas de flujo de datos mediante un enfoque jerárquico de arriba hacia abajo. Por ejemplo, el analista podría crear un flujo de datos de un Diagrama 0 después de las primeras entrevistas y, al mismo tiempo, hacer las entradas preliminares del diccionario de datos. Típicamente, estas entradas consisten en los nombres de los flujos de datos encontrados en el diagrama de flujo de datos y sus estructuras de datos correspondientes. Después de realizar varias entrevistas adicionales para descubrir los detalles del sistema, el analista extenderá el diagrama de flujo de datos y creará los diagramas hijos. Posteriormente se modifica el diccionario de datos para incluir los nuevos registros estructurales y elementos recabados en las entrevistas, observación y análisis de documentos posteriores. Cada nivel de un diagrama de flujo de datos debe usar datos adecuados para el nivel. El Diagrama 0 debe incluir únicamente formularios, pantallas, informes y registros. Conforme se creen los diagramas hijos, el flujo de datos que entre y salga de los procesos será cada vez incluyendo los registros estructurales y los elementos. El proceso 5, del Diagrama 0, es un ejemplo general de la producción de un RECIBO DE NÓMINA DEL EMPLEADO. La entrada correspondiente del diccionario de datos para el REGISTRO DEL EMPLEADO muestra el NUMERO DEL EMPLEADO y cuatro registros

estructurales, la vista de los datos obtenidos anteriormente en el análisis. Del mismo modo, también se definen como una serie de estructuras el REGISTRO DEL ARCHIVO DE TIEMPO y el RECIBO DE NÓMINA DEL EMPLEADO. Es importante que los nombres de los flujos de datos en el diagrama de flujo de datos hijo estén contenidos como elementos o registros estructurales en el flujo de datos del proceso padre. Regresando al ejemplo, INFORMACIÓN DEL SUELDO [entrada del proceso 5.3, CALCULAR MONTO DEL SUELDO ACTUAL) es un registro estructural contenido en el REGISTRO DEL EMPLEADO [entrada del proceso 5]. Del mismo modo, el SUELDO BRUTO está contenido en el registro estructural MONTO DEL SUELDO ACTUAL [salida el proceso padre 5.3, CALCULAR MONTO DEL SUELDO ACTUAL).

Análisis De Las Entradas Y Salidas Un paso importante en la creación del diccionario de datos es identificar y categorizar el flujo de datos de entrada y salida del sistema. Los formularios de análisis de entrada y salida, se podrían usar para organizar la información obtenida de las entrevistas y análisis de documentos. Observe que este formulario contiene los siguientes campos comúnmente incluidos:

1. Un nombre descriptivo para la entrada o salida. Si el flujo de datos está en un diagrama lógico, el nombre debe identificar el propósito de los datos [por ejemplo, INFORMACIÓN DEL CLIENTE). Sin embargo, si el analista está trabajando en el diseño físico o si el usuario ha declarado explícitamente la naturaleza de la entrada o salida, el nombre debe incluir esa información con respecto al formato. Ejemplos son ESTADO DE FACTURACIÓN DEL CLIENTE y AVERIGUACIÓN DE DETALLES DEL CLIENTE.

2. El contacto del usuario responsable para la clarificación de detalles adicionales, retroalimentación del diseño y aprobación final.

3. Si los datos son de entrada o salida. 4. El formato del flujo de datos. En la fase del diseño lógico, el formato podría

ser indeterminado. 5. Elementos que indican la secuencia de los datos en un informe o pantalla

(quizás en columnas). 6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o

derivados y sus criterios de edición. Una vez que se haya completado el formulario, cada elemento se debe analizar para determinar si se repite, si es opcional o si se excluye mutuamente con otro elemento. Los elementos que hay en un grupo o que regularmente se combinan con algunos otros elementos en muchas estructuras se deben agrupar en un registro estructural.

Desarrollo De Almacenes De Datos Otra actividad relativa a la creación del diccionario de datos es el desarrollo de los almacenes de datos. Hasta ahora, hemos determinado qué datos necesitan fluir de un proceso a otro. Esta información se describe en estructuras de datos. Sin embargo, la información podría estar almacenada en diversos lugares, y el almacén de datos podría ser diferente en cada lugar. Mientras que los flujos de datos representan datos en movimiento, los almacenes de datos representan datos en reposo.

Uso Del Diccionario De Datos El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la organización, se agregan elementos de datos al diccionario de datos. Por otro lado, el diccionario de datos no es un fin en sí mismo y nunca debe serlo. Para evitar desviarse del propósito principal con la construcción de un diccionario de datos completo, el analista de sistemas debe verlo como una actividad paralela al análisis y diseño de sistemas. Para maximizar su potencial, el diccionario de datos se debe vincular a varios programas de sistemas para que cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo mismo en la base de datos. El diccionario de datos se vuelve simplemente una curiosidad histórica si no se mantiene actualizado. El diccionario de datos se podría usar para crear pantallas, informes y formularios. La estructura de datos y los elementos de un almacén de datos se usan normalmente para generar el código fuente correspondiente en lenguaje de computadora que posteriormente se integra en los programas de cómputo. El diccionario de datos se podría usar en conjunto con un diagrama de flujo de datos para analizar el diseño del sistema, detectar fallas y áreas que se necesitan aclarar. Algunas consideraciones son:

1. Todos los elementos base en un flujo de datos de salida deben estar presentes en un flujo de datos de entrada en el proceso que produce la salida. Los elementos base se teclean y nunca deben ser creados por un proceso.

2. Un elemento derivado debe ser creado por un proceso y debe ser la salida de por lo menos un proceso en el cual no es entrada.

3. Los elementos que están presentes en un flujo de datos que entran o salen de un almacén de datos se deben contener en el almacén de datos.

Si se empieza temprano, un diccionario de datos puede ahorrar bastante tiempo en las fases de análisis y diseño. El diccionario de datos es la fuente común en la organización para contestar preguntas y arreglar controversias acerca de cualquier

aspecto de la definición de los datos. Un diccionario de datos actualizado puede servir como una referencia excelente para los esfuerzos de mantenimiento en los sistemas desconocidos. Los diccionarios de datos automatizados pueden servir de referencia para las personas y los programas.

Casos Prácticos

Diagramas de Flujo de Datos Narrativa del Sistema La narrativa del sistema consiste en la elaboración de un texto en el cual se detalle de manera ordenada cada uno de los procesos que ocurren en el sistema, en la misma se debe hacer hincapié en la detección de los eventos y los actores que interactúan con el sistema, los documentos, formatos, formas o archivos utilizados o que se producen y el flujo que debe seguir la información. Para los efectos del presente trabajo tomaremos como ejemplo la gestión de una empresa de venta y alquiler de equipos e insumos médicos. Daremos por sentado que ya se realizó la narrativa de los procesos y pasaremos directamente a la síntesis de la misma. Síntesis de la narrativa del sistema:

Entidad Flujo Proceso Almacén CLIENTES EMPRESA PROVEEDORES

Agrega Alumno al Plantel Carga Notas de las Evaluaciones Compra Datos Clientes Datos Compra Datos de Alquileres Datos de Devoluciones Vencidas al Plazo Datos de Estados de Cuenta Datos de Factura Datos de Facturas Datos de la Materia Datos de Pagos Datos de Pedido Datos de Productos Datos de Productos Comprados Datos de Productos Solicitados Datos de Proveedores Datos del Pago Datos del Pensum Datos del Proveedor Datos Pedido Datos Productos Recibidos Datos Proveedores

Actualiza Datos de Proveedores Actualizar Datos Proveedores Calcular Multa Emitir Facturas Pendientes de Pago Entregas Pendientes Facturación Facturación Mensual Genera Alquileres Pendientes de Devolución Genera Demanda de Alquileres Genera Pagos Pendientes Genera Pedido Generar Pedidos a Proveedor Gestión de Alquiler y Compra Gestión de Clientes Gestion de Compras Gestión de Crédito y Cobranza Gestión de Devoluciones Gestión de Proveedores Gestiónar Entregas Inscripcion de Materias Plan de Evaluación Realizar Pagos Registrar Devoluciones

Alquiler Cliente Compras Devoluciones Entregas Facturas Pagos Pedidos Productos Proveedor

Devolución Disponibilidad Entrega Pedido Estados de Cuenta Factura Factura Pedido Facturacion Mensual Facturas Pendientes Fallas de Productos Hace Pedido Inscribe al Alumno Lista de Productos Solicitados Mantiene Stock de Productos Multa Paga Pedido Pagos Pendientes Productos Pendientes por Entregar Registra Compras Registra Devoluciones Registra Existencias - Disponibilidad Registra Existencias -Disponibilidad Registra Inscripcion de Materia Registro de Alquileres Registro de Devoluciones Registro de Transacciones del Cliente Solicitud de Alquiler

Registrar Entrega Registrar Factura Registrar Pedidos Registro de Alumno Registro de Materias Registro de Notas Registro de Pagos Sistema de Venta y Alquiler de Insumos y Equipos Médicos Validar Alquiler y Procesa Compras

Diagrama de Contexto

Sistema de V entay A lquiler deInsumo s y

Equipo s M édico s

0

CLIENTES

EMPRESA

PROVEEDORES

Solicitud de Alquiler

Devolución

Compra

Multa

Factura

Factura Pedido

Entrega Pedido

Hace Pedido

Paga Pedido

DatosProveedores

DatosClientes

DatosPedido

DatosCompra

Diagrama 0

Gestion deCompras

Solic itud deAlquiler

Devoluc ión

Compra Fac tura Pedido

Entrega Pedido

Multa

Fac tura

Hace Pedido

PagaPedido

DatosProv eedores

Datos Clientes

Datos Pedido

Datos Compra

1

Gestión deClientes

2

Gestión deProveedores

3

D4 Productos

D5 Compras

MantieneStock deProduc tos

Regis traEx is tenc ias -D is ponibilidad

Regis traCompras

Estados deCuenta

Diagrama 1

Solicitud deAlquiler Devolución

Compra

Datos Clientes

Registra Existencias -Disponibilidad

Estados de Cuenta

MultaFactura

RegistraExistencias -Disponibilidad

Estados deCuenta

1.1

Gestión deAlquiler yCompra

1.2

Gestión deDevoluciones

1.3

Gestión deCrédito yCobranza

D6 ClienteD5 Compras

D7 Alquiler

Registro deAlquileres Registro de

Devoluciones

RegistraCompras

Registro deTransaccionesdel Cliente

Datos deProductosComprados

Datos deEstados de Cuenta

D4 ProductosRegistraDevoluciones

Disponibilidad

Diagrama 1.1

Solicitud deAlquiler

DatosClientes

RegistraExistencias -Disponibilidad

Estados deCuenta

Registro deAlquileres

Datos deProductos

Registro deTransaccionesdel Cliente

Factura

Registro deAlquileres

RegistraCompras

1.1.1

V a lida rA lquiler yPro cesaC o mpra s

1.1.2

GeneraD ema nda de

A lquileres

1.1.3

GeneraA lquileres

Pendientesde D ev o lució n

D4 Pro ducto s

D8 A lquileres

D5 C o mpra s D6 C lienteDatosdeAlquileres

Diagrama 1.2

Devolución

RegistraExistencias -Disponibilidad

Registro deDevoluciones

Multa

Registro deDevoluciones Registra

Devoluciones

1.2.1

Registra rDevo lucio nes

1.2.2

Ca lcula rMulta

D9 Devo luciones

D8 AlquileresD4 Pro ducto s

Datos deDevolucionesVencidas al Plazo

Diagrama 2

Factura Pedido

EntregaPedido

Datos Proveedores

Datos dePagos

Hace Pedido

PagaPedido

Datos Pedido

Mantiene Stockde Productos

2.1

GenerarPedidos aProveedor

2.2

GestiónarEntregas

2.3

RealizarPagos

2.4

ActualizarDatosProveedores

2.5

Facturación

D10 Pedidos

D4 Productos

D11 Proveedor

D12 Facturas D13 Pagos

Fallas de Productos

Datos dePedido

Lista deProductos Solicitados

Datos deProveedores

Datos del Pago

Datos deFactura

Datos deProveedores

DatosdeFactura

Datos dePagos

FacturasPendientes

FacturacionMensual

Diagrama 2.1

Datos ProveedoresDatosP edido

Fallas de Productos

HaceP edido

Datos de Pedido

2.1.1

RegistrarPedidos

D4 Productos

D11 Proveedor

D10 Pedidos

2.1.2

GeneraPedido

Diagrama 2.2

EntregaPedido

Lista de ProductosSolicitados

MantieneStockdeProductos

2.2.1

RegistrarEntrega

2.2.2

Entrega sPendientes

D10 Pedido s

D14 Entreg as

D4 Productos

Datos ProductosRecibidos

Datos deProductosSolicitados

Datos ProductosRecibidos

ProductosPendientes por Entregar

Diagrama 2.3

Datos de P agos

Datos deP roveedores

Datos deFactura

P agaP edido

Datos del Pago

2.3.1

Registro dePagos

2.3.2

GeneraPagosPendientes

D12 Facturas

D11 Proveedor

D13 Pagos

Datos deFacturas

P agosP endientes

Diagrama 2.4

Datos deProveedores

2.4.1

A ctualizaDatos de

Provee dores

D11Pr oveedor

Datos delProveedor

Diagrama 2.5

FacturaPedido

Datos deFactura

Datos de PagosDatos deFactura

FacturasPendientes

FacturacionMensual

2.5.1

RegistrarFactura

2.5.2

EmitirFacturas

Pendientesde Pago

2.5.3

FacturaciónMensual

D12 Facturas

D13 Pagos

DatosdeFactura

Diccionario de Datos

Alquileres nombre tipo longitud descripcion

id_alquiler entero 8 Identificador único del movimiento de alquiler codigo_cliente carácter 8 Codigo del Cliente que Alquila Equipo codigo_producto carácter 10 Codigo de Producto Alquilado cantidad entero 5 Cantidad de Producto precio numerico 10,2 Precio Unitario del Alquiler total numerico 10,2 Total del Alquiler fecha_salida fecha 10 Fecha de salida del Producto fecha_retorno fecha 10 Fecha en que Debe Retornar el Producto fecha_entrada fecha 10 Fecha real de Retorno

Cliente nombre tipo longitud descripcion

codigo_cliente carácter 8 Codigo de Cliente apellido_cliente carácter 45 Apellidos del Cliente nombre_cliente carácter 45 Nombres del Cliente direccion carácter 80 Direccion del Cliente telefono carácter 20 Telefonos del Cliente (Habitacion y Oficina) fax carácter 20 Fax del Cliente (Habitacion y Oficina) email carácter 45 Correo Electronico del Cliente celular carácter 20 Telefonos Celular del Cliente fecha_ultima_trans fecha 10 Fecha de Ultima Transacción del Cliente

Compras nombre tipo longitud descripcion

codigo_cliente carácter 8 Codigo de Cliente codigo_producto carácter 10 Codigo del Producto Comprado cantidad entero 5 Cantidad de Producto Comprado precio numerico 10,2 Precio Unitario de Venta total numerico 10,2 Total de la Venta

Devoluciones nombre tipo longitud descripcion

id_devolucion entero 8 Identificador único del movimiento de devolución id_alquiler entero 8 Identificador único del movimiento de alquiler fecha_devolucion fecha 10 fecha de la devolucion

Entregas nombre tipo longitud descripcion

id_entrega entero 8 Identificador único del movimiento de entrega id_pedido entero 8 Identificador único del movimiento de pedido fecha_entrega fecha 10 fecha de entrega tipo_recepcion entero 1 Tipo de Recepcion: 1=Aceptada, 2=Rechazada

Facturas nombre tipo longitud descripcion

id_factura entero 8 Identificador Unico de Factura nro_control entero 8 Numero de Cotrol de la Factura fecha_factura fecha 10 Fecha de la Factura codigo_cliente carácter 8 Codigo de Cliente monto numerico 10,2 Monto Total de la Factura saldo numerico 10,2 Saldo Actual de la Factura

Pagos nombre tipo longitud descripcion

id_pago entero 8 Identificador Unico de Pago id_factura entero 8 Identificador Unico de Factura que se Paga codigo_cliente carácter 8 Codigo de Cliente fecha_pago fecha 10 Fecha del Pago monto_pago numerico 10,2 Monto Pagado / Abonado

Pedidos nombre tipo longitud descripcion

id_pedido entero 8 Identificador Unico de Pedido fecha_pedido fecha 10 Fecha del Pedido codigo_producto carácter 10 Codigo de Producto Pedido cantidad numerico 10,2 Cantidad de Producto Pedido costo numerico 10,2 Costo del Pedido condicion entero 1 Condicion del Pedido: 1=Normal, 2=Urgente

Productos nombre tipo longitud descripcion

codigo_producto carácter 10 Codigo de Producto descripcion_producto carácter 50 Nombre del Producto costo numerico 10,2 Costo Unitario del Producto precio_venta numerico 10,2 Precio para la Venta categoria entero 1 Categoria del Producto: 1:Solo Venta 2:Solo Alquiler 3:Alquiler o Venta tasa numerico 5,2 Tasa para Alquiler del Producto castigo numerico 5,2 Porcentaje de Castigo en demora de retorno del Producto existencia1 entero 5 Existencia para alquilar existencia2 entero 5 Existencia para la venta

Proveedor

nombre tipo longitud descripcion codigo_proveedor carácter 8 Codigo del Proveedor nombre_proveedor carácter 60 Nombre / Descripcion del Proveedor rif_proveedor carácter 15 RIF Proveedor nit_proveedor carácter 20 NIT Proveedor fecha_ingreso fecha 10 Fecha de Ingreso como Proveedor fecha_ultima_compra fecha 10 Fecha de Ultima Compra Realizada al Proveedor linea entero 2 Linea de Productos del Proveedor: 1=Equipos, 2=Insumos, 3= Ambos compras_mes numerico 12,2 Monto de las Compras realizadas en el mes compras_ejercicio numerico 12,2 Monto de las Compras realizadas en el Ejercicio Fiscal

Conclusiones

Se han aplicado las técnicas de diseño estructurado de sistemas siguiendo la

metodología del uso de Diagramas de Flujo de Datos (DFDs) partiendo desde el

gráfico contextual para luego pasar al diagrama 0 desde donde se han explotado

cada uno de los procesos mostrados, la metodología propone el uso de un

conjunto de símbolos para la representación de los elementos que conforman los

diagramas: entidades, procesos, flujos y archivadores, de estos se optó por el uso

de la simbología de Gane & Sarson. Para la realización de los dibujos se utilizado

una herramienta de ayuda al modelamiento llamada Visible Analyst Versión 7.5.

Para la creación del Diccionario de Datos se uso Excel.

Estimamos fundamental el uso de las herramientas de diseño estructurado de

sistema pues permitan obtener una visión global de la propuesta antes de escribir

la primera línea de código, podemos definir la funcionalidad del sistema de una

manera más precisa evitando el re-trabajo y al final un mayor grado de

satisfacción por parte de los usuarios.

Bibliografía

Kenneth E. Kendall y Julie E. Kendall Análisis y Diseño de Sistemas – 6ta Edición Pearson Educación, México, 2005 M.Sc. Lic. Aidee Vargas C. Análisis de Sistemas Octubre 2007 Ayuda Visual Analyst 7.5 Visible Systems Corp. 1992 - 2001