sistema de almacén - 148.206.53.231

Universidad Autónoma Metropolitana lztapalapa

Sistema de

Almacén

PROYECTO FINAL

Universidad Autónoma Metropolitana

l‘tapalapa

ALUMNO: ARNULFO HERNANDEZ HUIZ MATRICULA: 86222833 LIC. EN COMPUTACION

Proyecto final

ASESOR: Maestro. LUIS F. CASTRO CAREAGA

Documentación

Universidad Authoma Metropolitana lztapalapa

Contenido

Introducción

Capítulo 1 Conceptos Básicos Acerca del Sistema 1 Características Generales 2 Requerimientos Necesarios para Utilizar el Sistema 3 Conocimientos Necesarios para Utilizar el Sistema 3 Comunicación con el Sistema 4 Mensajes 5

Capítulo 2

Capítulo 3

Capítulo 4

Metodología Introducción 1 Sistema 2 Ciclo de vida del proyecto clásico 3 Ciclo de vida del proyecto estructurado 4 Herramientas de Modelado 5 Diccionario de Datos 6 Especificaciones de Procesos 7 Diagramas de Flujo 8 Diagramas de Entidad-Relación (DER, DEA) 9

Caso de Estudio Modelo Ambiental 2 Modelo de Comportamiento 15

Conclusiones Conclusiones 1 Bibliografia 3

Proyecto Final

Documentaci6n

Universidad Autónoma Metropolitana lztapalapa Proyecto Final

A mi hija

Gabriela Sopa Por fin comienzo a escribir estas líneas y digo por fin porque este es un proyecto que me llevó mucho tiempo realizarlo y las condiciones algunas veces no se dieron como yo esperaba. Pero es un buen momento para recapacitar y reconocer el esherzo de personas a las cuales les debo mucho, ya que sin su ayuda no hubiera podido terminar. Reconozco que esta obra pudiera haber sido mejor de como salió a fin de cuentas.

Quiero agradecer a personas muy especiales:

A mi Padre que me impulso u me ayudó a venir a estudiar a la ciudad de México y a éI en cualquier parte del cielo le dedico esta obra.

A mi esposa Carmen que siempre me apoyó y me estuvo insistiendo para terminar le dedico esta obra con mucho cariño.

Y muy especialmente a mi señora madre Doña Elsa, que k é la que siempre creyó en mi y trabajó muy duro para que yo pudiera terminar la Licenciatura y por eso le dedico esta obra.

Gracias.

Documentación

Universidad Autónoma Metropolitana Iktapalapa Proyecto Final

Introducción

Este es el comienzo de un proyecto que para mi tiene la mayor importancia. El objetivo del mismo es realizar el análisis y desarrollo de un sistema de información para automatizar las actividades realizadas en un almacén, el cual me dará como resultado una documentación y un software con los cuales podré titularme. Alguno de los objetivos que se pretenden en este proyecto son: Poner en practica los conocimientos obtenidos en el aula de clases. Tratar de llevar a una situación real el análisis de sistemas. Obtener una documentación que se apegue más a la realidad y así conocer la documentación que se debe entregar cuando se realiza un proyecto de esta indole.

La documentación que se esta generando con este informe nos presenta en su contenido un breve detalle de la metodología propuesta para desarrollo de sistemas y como caso de estudio el desarrollo del Sistema de Almacén.

Acerca del Proyecto Este sistema constará de tres módulos. El modulo de almacén, el modulo de ventas y el modulo de compras. El modulo de compras se encargará de generar las ordenes de entrada para que el almacén de entrada a los artículos y con esto modifique su inventario. El modulo de ventas se encargará de generar las ordenes de salida a las cuales el almacén cambiará el estatus y con ello un artículo podrá salir del almacén y ocasionará una baja en el inventario del almacén.

Documentación Introducción I- 7


Aunque el objetivo principal del sistema es el almach, se consideró indispensable hacer la parte de compras y de ventas para poder generar las ordenes de entrada y salida con las cuales trabajará el almacén.

Algunas de las actividades que realizará el sistema son las siguientes:

Registro de ordenes de Entradalsalida Manejo del inventario Clasificación y existencia de artículos Consulta de ordenes de E/S Consulta de Existencias Avisos en puntos de reorden Calculo del inventario usando UEPS, PEPS, y PROM. Etc, Etc.

Documentación Introducción 1-2


Capítulo 1 Conceptos Básicos

Este capítulo intenta introducir al usuario en los conceptos básicos de funcionamiento y operación del Sistema de Almacén. Incluye los procedimientos básicos para entrar al Sistema, utilizar las diversas pantallas que permiten establecer una comunicación interactiva, teclas de knción, mensajes y ayudas. También se explican las bases sobre las cuales hnciona el Sistema y conceptos fhdamentales que el usuario debe conocer para utilizar el Sistema eficientemente.

Acerca de/ Sistema El objetivo general del Sistema es controlar las operaciones de la empresa relacionadas con el almacén por medio de la computadora. Los alcances del sistema se pueden describir en los puntos siguientes:

Automatizar la operación de entrada y salida de artículos en el almacén. Conocer en cualquier momento el estatus de algún pedido de algún área en especial. Registro de la información de manera simple y eficiente. Proporcionar información veraz y oportuna en el momento que se requiera. Actualización en línea del inventario de artículos. Controlar la existencia de artículos por medio de puntos de reorden. Hacer el calculo de los inventarios con diferentes métodos (UEPS PEPS PROMEDIO).

Documentación Conceptos Básicos I- 7


Características Generales El Sistema de Almacén conforma un grupo de aplicaciones básicas para la operación completa e integral de las empresas que lo utilizan. Ofrece las siguientes hnciones:

M M

M

M M M M M M M M

M

Registro de transacciones en forma interactiva y en cualquier mes del ejercicio. Información en base al mes de proceso por medio de reportes en el momento que se requiera puesto que la actualización de los archivos es inmediata. Manejo de los catálogos ocupados en el sistema tales como Tipos de Clientes, Clientes, Proveedores, Tipos de Proveedores, Centros de Responsabilidad, Conceptos etc, etc. Impresión de cada uno de los catálogos. Regeneración de información en forma automática. Control del último pedido y última orden de Entrada-Salida por mes y ejercicio. Relación de pedidos y proveedores. Relación de Facturas y clientes. Detalle de pagos hechos a pedidos mensualmente. Saldos por cliente. Impresión de la información más relevante sobre pedidos y pagos, facturas, entradas y salidas. Seguridad de acceso a las aplicaciones a nivel usuario.

Algunas especificaciones del Sistema son:

Manejo interactivo de todo el ejercicio.

Algunas características del Sistema son:

Sistema 100% interactivo. Diseñado para el equipo AS/400 de IBM como servidor de archivos y una PC para la aplicación. Desarrollado en el lenguaje SQL Windows (Gupta). Ambiente de operación orientado al usuario. Guías de operación por medio de menús y algunas teclas de Función. Textos de ayuda en todas las aplicaciones. Seguridad de acceso a nivel aplicación. Documentación técnica y operativa.

Documentación Conceptos BBsicos 1-2


Requerimientos Necesarios para Utilizar el Sistema Para utilizar el sistema de Almacén es necesario satisfacer una serie de requisitos que se describen a continuación:

Materiales El siguiente material de apoyo es necesario para utilizar el sistema: W Manual Técnico

Manual de Usuario

Hardware El siguiente hardware es necesario para utilizar el sistema:

IBM AY400 (cualquier modelo), una PC con almanes 8 megas de RAM Terminal IBM, compatibles o estaciones de trabajo emuladas para acceso al AS400. Impresora.

Software El siguiente software es necesario para utilizar el sistema: W Sistema Operativo OS/400 Versión 2 Release 1 Modificación 1 o posterior.

SQL Windows de Gupta para la aplicación.

Recursos de Sistema Los siguientes recursos de sistema son necesarios para instalar y utilizar el sistema:

50 megabytes se requieren para almacenar los objetos y hentes de todos los

W 8 megabytes de memoria RAM mínima en la PC. Suficiente espacio en el AS400 para almacenar la información generada.

módulos del sistema de Almacén.

Conocimientos Necesarios para Utilizar el Sistema Una de las características del sistema es proporcionar un ambiente de operación orientado a usuarios finales. Por lo tanto, para utilizar el sistema es requisito que el usuario presente conocimientos en los siguientes aspectos:

Conocimiento en el área de compras. Conocimiento en el área de inventarios. Conocimiento en el área de ventas. Fundamentos básicos de una computadora. Debe manejar los conceptos de hardware, software, programa, monitor, teclado, CPU, memoria, disco duro, diskette y otros.

W Operación básica de una computadora. Debe manejar operaciones como encendido y apagado de la PC, manejo del teclado de la computadora, manejo de unidades de diskette, identificación y cuidado de diskettes.

Documentacibn Conceptos BAsicos 1 3


Comunicación con e/ Sistema El Sistema provee diversas pantallas para establecer una comunicación interactiva con el usuario. Cada pantalla tiene una función específica que permite introducir o extraer información eficientemente. Los tipos de pantalla que forman la interface de comunicación con el usuario son:

M Menú SelecciÓdLista EntraddSalida

Mensajes Los mensajes son el medio de comunicación entre el sistema y los usuarios y permiten que éstos identifiquen estados o condiciones de error durante la operación de un programa de aplicación. Todo dato de entrada se valida contra las características de cada campo; si presenta inconsistencia, el sistema desplegará un mensaje de ayuda indicando el estado o la causa del error en el área destinada para este fin. El sistema provee mensajes de ayuda informativos y de error dependiendo de las condiciones que causan el envío de éste. Los mensajes informativos indican al usuario acciones efectuadas por la aplicación y se identifican por las constantes <IN- que preceden al mensaje. Los mensajes de error indican al usuario fallas presentes en la operación de la aplicación y la acción a realizar para corregir el error. Estos se identifican por las constantes <ERR> que preceden al mensaje.

Documentación Conceptos Bhsicos 1-4

Universidad Autónoma Metropolitana lztapalapa Proyecto final

Capítulo 2 Metodología

2. I Introducción

En muchas de las organizaciones que cuentan con un equipo propio de desarrollo de sistemas, no existe una metodología bien cimentada que garantice que los sistemas que se desarrollan son realmente un producto de calidad y sobre todo lo más importante, que cumpla cabal y totalmente con todas las necesidades del área final. Los sistemas de información deben de cumplir con ciertas características y requisitos para una mayor satisfacción del cliente. Algunos de los problemas a que se enfrentan algunas empresas son los siguientes:

1 .- Utilización de diversas metodologías empíricas. 2.- Falta de planeación de tiempos para desarrollo (un proyecto es una actividad bien planeada). 3.- Falta de recursos humanos o mala distribución de este. 4.- Falta de estándares.

Por esto y por mucho más en cualquier organización debe existir una metodología que unifique criterios y estandarice esfuerzos con el propósito de ser productivos en el desarrollo de sistemas. Es importante hacer notar que el uso de una metodología no le quitará el trabajo al administrador de proyectos, sino que le ayudará a organizar mejor las actividades para garantizar que los problemas se solucionen en el momento adecuado.

Documentacibn Metodología 2- I


Todo esto nos lleva a hacernos una pregunta.

iDe que nos sirve tener una metodologia ? Los objetivos de tener una metodología son:

0 Definir las actividades a llevarse a cabo en un proyecto de desarrollo de

Este punto es de suma importancia en una organización grande donde constantemente está ingresando personal nuevo a los puestos de administración de proyectos (o analistas). El administrador novato pudiera no tomar en cuenta o subestimar la importancia de fases clave del proyecto si se basa solo en su intuición. Cada analista hace su trabajo de acuerdo a la metodología que conoce además de realizar el proyecto solo con los recursos que cuenta. 0 Lograr congruencia entre la multitud de proyectos de desarrollo de sistemas

Para los niveles más altos de la administración pudiera ser bastante conhso seguir la pista de cientos de proyectos diferentes, cada uno de los cuales se lleva a cabo de distinta manera. Por ejemplo, si el proyecto A define la actividad de análisis de sistemas de diferente forma que el proyecto B y el B no incluye una fase de diseño, ¿Cómo puede darse cuenta el administrador de segundo o tercer nivel de cual proyecto se está rezagando y cuál continúa según lo previsto? Normalmente los proyectos no se terminan a tiempo y es debido en gran parte a la falta de una planeación adecuada.

Proporcionar puntos de control y revisión administrativos de las decisiones

En los proyectos triviales, el Único punto de revisión probablemente esté al final del proyecto: ¿Se concluyó a tiempo y dentro de los márgenes del presupuesto acordado? ( o, más simple aún, ¿Se concluyó siquiera?) ¿y cumplió con los requisitos del usuario?. Para proyectos grandes se hace necesario una revisión periódica para ver si se esta cumpliendo con las etapas del proyecto. Es importante que el usuario participe en la revisión de estas etapas. 0 Homogenizar los sistemas. Cualquier analista puede entender cualquier sistema. Se habla del mismo idioma entre los analistas. Además para las persona administrativas se les facilita la supervisión.

Documentación de los sistemas. La documentación de los sistemas es una parte muy importante en cualquier organización, dicha ducumentación nos facilita la capacitación de personal de nuevo ingreso.

sistemas.

en una misma organización.

sobre continuar o no con un proyecto.

Documentaci6n Metodología 2-2

Universidad Autónoma Metropolitana Iztapalapa Proyecto Final

2.2 Sistema Es un grupo de elementos interdependientes o que interactúan regularmente formando un todo (ej. sistema númerico). Nosotros somos un sistema que interactua diariamente con otros sistemas los cuales estamos inmersos en un sistema mayor. Es por esto que debemos estudiar todo tipo de sistemas y esto nos dará una explicación de muchas cosas. Para poder intentar hacer un sistema computacional debemos ser capases de comprender los sistemas naturales ya que nuestro sistema interactuará con estos. Es muy importante que estudiemos acerca del tema de nuestro próximo sistema, esto le dará al usuario una mayor seguridad de que está tratando con alguien que le entiende.

Existen divisiones o agrupaciones de sistemas hechos por el hombre.

+ SISTEMAS EN LINEA Según Yourdon 1972. Un sistema en línea es aquel que acepta material de entrada

directamente del área donde se creó. También es el sistema en el que el material de salida, o el resultado de la computación, se devuelve directamente a donde es requerido.

+ SISTEMAS DE TIEMPO REAL Según Martin 1967. Un sistema computacional de tiempo real puede definirse como

aquel que controla un ambiente recibiendo datos, procesándolos y devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese momento. (Sistemas bancarios, sistemas de reservaciones aéreas y sistemas de bolsa de valores).

+ SISTEMAS DE APOYO A DECISIONES O PLANEACION ESTRATEGICA Los sistemas de planeación estratégica son un punto poco tocado por las organizaciones mexicanas, sin embargo día a día van tomando mayor fuerza. Los sistemas de planeación estratégica están basados en los sistemas operacionales los cuales crean o suministran los datos de una manera continua. véase las figuras 2.1 y 2.2. Este tipo de sistemas (Planeación Estratégica) se caracterizan porque con ellos los altos mandos de las grandes organizaciones pueden encontrar respuestas a preguntas tales como: Porque un producto esta bajando en ventas; como quiero que este la empresa en un tiempo determinado. etc.

En la fig. 2.1 podemos darnos cuenta de como un sistema de planeación estratégica nos apoyará en la toma de decisiones y los puntos que se deben considerar en dichos sistemas. Este modelo trata de identificar la discrepancia entre la posición actual de la organización (en términos de ganancias, rentabilidad, etc.) y la posición deseada por la gerencia, los accionistas y otros. En la fig. 2.2 observamos el modelo de planeación estratégica basado en la fuerza del mercado con sus puntos más importantes.

Documentación Metodologia 2-3

Universidad Autbnoma Metropolitana lztapalapa Proyecto Final

SISTEMAS BASADOS EN EL CONOCIMIENTO (EXPERTOS) La meta de los científicos de la computación que trabajan en el campo de la inteligencia artificial es producir programas capaces de limitar el desempeño humano en una gran variedad de tareas “inteligentes”. Para algunos sistemas expertos la meta esta próxima a ser alcanzada; para otros, aunque aún no sabemos construir programas que funcionen bien por sí solos, podemos comenzar a crear programas capaces de auxiliar a las personas en la ejecución de algunas tareas.

PRINCIPIOS GENERALES DE UN SISTEMA

1.- Entre más especializado sea el sistema, menos capaz es de adaptarse a circunstancias diferentes.

2.- Cuanto mayor sea el sistema mayor es el número de sus recursos que deben dedicarse a su mantenimiento diario.

3.- Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en sistemas menores. 4.- Los sistemas crecen.

En la fig. 2.3 se observa la jerarquía de los sistemas de procesamiento de información .

Antes de pasar a revisar el ciclo de vida del proyecto estructurado (metodología estructurada) veremos el ciclo de vida del proyecto clásico (metodología clásica) en el cual muchas empresas aun basan sus proyectos de sistemas de información. Esta metodología no es mala ya que en algunas áreas de la industria cumple muy bien con lo requerido, sin embargo veremos algunas debilidades que presenta esta metodología para el desarrollo de sistemas de información.

2.3 Ciclo de vida del proyecto clásico

Esta es la metodología que hasta ahora muchas empresas grandes y pequeñas han adoptado para el desarrollo de sistemas de información.

¿Qué es lo que realmente caracteriza el ciclo de vida de un proyecto como clásico? Se distinguen dos aspectos: Una fberte tendencia a la implantación ascendente del sistema y la insistencia en la progresión lineal y secuencia1 de una fase a la siguiente.

Documentación Metodología 2-4


0 IMPLANTACION ASCENDENTE

Como se observa en la figura 2.4, se espera que los programadores lleven acabo primero sus pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque se conoce también como el ciclo de vida de cascada. La implantación ascendente es buena para el montaje de automóviles en línea.

Algunos puntos a resaltar de la implantación ascendente son:

** Nada esta hecho hasta que todo esta terminado. ** Las fallas más triviales se encuentran al comienzo del periodo de prueba y las más grandes al final. (Existen fallas que no se ven sino hasta que el sistema esta terminado). ** La eliminación de fallas suele ser extremadamente dificil durante las últimas etapas de prueba del sistema. ** La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba. La experiencia nos dice que al usuario le cuesta mucho trabajo probar todo un sistema completo ya que invierte mucho tiempo y esto ocasiona que los sistemas no se prueben bien.

PROGRESION SECUENCIAL

Las fases se suceden secuencialmente. Querer esto es una tendencia natural humana: deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que volver a preocuparnos por ella. El Único problema que trae consigo este deseo de progreso ordenado es que no es nada realista. Esto es, no permite equivocaciones para no regresar a una etapa anterior. Una fase concluye cuando alguien decide que se ha agotado el tiempo y no cuando se quisiera dar por terminado.

2.4 Ciclo de vida del proyecto estructurado

El ciclo de vida del proyecto estructurado es la metodología que en este proyecto se propone para desarrollar las diferentes etapas.

2.4.1 LA ENCUESTA Se conoce también como estudio de factibilidad. Esto comienza cuando se ve la posibilidad o necesidad de automatizar ciertos procesas de negocios. Los objetivos de esta etapa son los siguientes:

Documentación Metodologia 2-5

Universidad Autónoma Metropolfiana lztapalapa Proyecto Final

Conocer e identificar que personas serán las usuarias y así como también conocer e involucrarse en el sistema tal y como se maneja hasta ahora (si no se sabe que se va a hacer nunca sabremos como hacerlo) esta etapa la podremos llevar a cabo con algunas entrevistas y observando a los usuarios en el momento de trabajar en el sistema actual.

Identificar algunas deficiencias actuales en el medio ambiente de los usuarios para así poderlas mejorar en el nuevo sistema. (se debe tener cuidado en hacer comentarios sobre tales deficiencias a los usuarios).

0 Establecer hasta donde podemos llegar con un nuevo sistema.

Determinar si es factible el proyecto y de ser así sugerir el mejor esquema de desarrollo.

Recolectar toda la información que nos sirva como guía para el desarrollo del proyecto.

En esta primera etapa nos encontraremos con algunas herramientas o conceptos tales como:

REGLAS DE ESTIMACION.

¿Que tipos de cosas necesitan estimarse en un proyecto de desarrollo de sistemas?

1.- Recursos humanos: Se cuenta con las personas necesarias (programadores, analistas, diseñadores, usuarios, etc.)?

2.- Tiempos: ¿Cuanto tiempo tardará el proyecto? y cuanto cada fase.

3.- Programación de personal: Cuando se requerirá de la gente y por cuanto tiempo.

4.- Presupuesto: Cuanto costará el sistema.

CALCULOS DE COSTO BENEFICIO

El propósito, desde luego, es mostrar a los usuarios del nuevo sistema, al igual que a otros grupos de administradores de la organizaciOn, que los beneficios que se esperan obtener con el nuevo sistema superan a los costos esperados. Cabe mencionar que en muchas organizaciones no se hace el estudio formal del costoheneficio ya que se desarrollan sistemas para necesidades que aveces ni siquiera están planeadas y son sistemas que se autorizan porque la circunstancia así lo ameritan. Para hacer un estudio o calculo de costo beneficio deberá documentarse más a fondo debido a que hay diversas formas de obtener los costos y beneficios de un sistema.

Documentacibn Metodología 2-6


TECNICAS DE ENTREVISTA Y RECOLECCION DE DATOS

¿Porque se hacen encuestas durante el análisis de sistemas?. Las razones son las siguientes: ** Necesitamos reunir información sobre el comportamiento de un sistema actual o de los requerimientos del nuevo, apartir de las personas que lo atienden.

** Necesitamos verificar lo que como analístas entendimos del comportamiento del sistema actual o de los requerimientos del nuevo en entrevistas anteriores.

** Reunir información para hacer un calculo de costo/beneficio o hacer el diseño conceptual del sistema.

Las entrevistas con mayores beneficios son aquellas en las cuales se platica o conversa con el usuario que utiliza el sistema actual y que además conoce las políticas del departamento. Las entrevistas deben ser con la persona adecuada. Las entrevistas deben de estar autorizadas y supeditadas por personas de mayor nivel en la organización. Todo lo que se acuerde debe de quedar por escrito.

2.4.2. EL ANALISIS DE SISTEMAS

El propósito principal de la actividad de análisis es transformar sus dos entradas - o insumos o factores - principales, las políticas del usuario y el esquema del proyecto en una especificación estructurada. Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de entidad relación, diagramas de transición de estados y demás herramientas.

2.4.3. EL DISEÑO

Esta actividad se dedica a asignar porciones de la especificación a procesadores adecuados a labores apropiados dentro de cada procesador. Dentro de cada labor, la actividad de diseño se dedica a la creación de una jerarquía apropiada de programas y de interfaces entre ellos para implantar la especificación creada en la actividad 2. Además la actividad de diseño se ocupa de la transformación de modelos de datos de entidad-relación en un diseño de base de datos.

2.4.4.IMPLANTACION

Incluye la codificación y la integración de módulos en un esqueleto progresivamente más completo del sistema final. Incluye programación estructurada como implantación descendente.


Universidad Autbnoma Metropolitana lztapalapa Proyecto Final

2.4.5. GENERACION DE PRUEBAS DE ACEPTACION

La especificación estructurada debe contener toda la información necesaria para definir un sistema que sea aceptable desde el punto de vista del usuario. Por eso, una vez generada la especificación, puede comenzar la actividad de producir un conjunto de casos de prueba de aceptación desde la especificación estructurada.

2.4.6. GARANTIA DE CALIDAD

Se conoce también como la prueba final o la prueba de aceptación. Esta fase es muy importante para verificar que el sistema tenga un nivel apropiado de calidad. Esta garantía o prueba debe hacerse para cada una de las anteriores etapas.

2.4.7. DESCRIPCION DEL PROCEDIMIENTO

Una de las actividades importantes a realizar es la generación de una descripción formal de las partes del sistema que se harán en forma manual, lo mismo que la descripción de cómo interactuarán los usuarios con la parte automatizada del nuevo sistema. El resultado de todo esto es un manual para el usuario. Esta actividad es muy poco tomada en cuenta y sobre todo en organizaciones en donde los sistemas se desarrollan sin una planeación y con muy poco tiempo. La documentación básica que se debe entregar al terminar un proyecto de analisis es: DISEÑO CONCEPTUAL

Definición del proyecto Plan de Trabajo Diagrama de descomposición Funcional Diagrama de Contexto Requerimiento de Usuario Analisis de Riesgos y Beneficios

Diagrama de E/R detallado Diagrama de Flujo de Datos Detallado Diseño de Pantallas y Reportes Mapa de navegación Levantamiento de Información

Modelo de Datos Diccionario de Datos Esquema fisico de la Base de Datos Diagrama Estructurado Descripción de Módulos Revisión de Apego a Políticas

DISEÑO LOGIC0

DISEÑO FISICO


Universidad Autónoma Metropolitana Iztapaapa Proyecto Final

CONSTRUCCION Chek list de Programación Resultados de prueba Manual de Usuario Manual de Operación Informe de Construcción

Informe de Implantación Informe post-conversión

IMPLANTACION

Cabe mencionar que esta es la lista de la documentación ideal para entregar al finalizar un proyecto.

2.4.8. CONVERSION DE BASES DE DATOS

Muchos de los sistemas nuevos se hacen porque, el sistema existente computarizado ya no responde a las necesidades actuales y además de que se necesita cambiar de plataforma de desarrollo, esto nos obliga a convertir las bases de datos actuales en nuevas basadas en las especificaciones de diseño actual.

2.4.9.INSTALACION

Esta es la actividad final. Con la instalación se debe de entregar un manual de usuario, una base de datos convertida o creada y el sistema aceptado. En algunos casos la instalación significa un cambio de la noche a la mañana al nuevo sistema sin más contratiempos pero en otros casos es un proceso gradual en el que se le proporciona a los usuarios el manual y un entrenamiento y comienza a usar el nuevo sistema.

La importancia del ciclo de vida del proyecto estructurado es que no implica que toda la actividad N debe concluir antes de comenzar la actividad N+1. Las actividades se puede estar llevando a cabo en forma simultáneamente paralelas. El diagrama que muestra esta metodología no es un diagrama de flujo sino que es un diagrama de flujo de datos. fig. 2.6

2.5 Herramientas de modelado

2.5.1. iQUE ES UN MODELO?

Un modelo es un simulacro o asimilación de la realidad a bajo costo de un sistema real. Existen muchas herramientas de modelado de sistemas, pero usted debe elegir la que más le describa las hnciones más importantes de su sistema y con mayor sencillez. Este modelo es un modelo orientado a las funciones.

Documentacit5n Metodologia 2-9


2.5.2. DIAGRAMA DE FLUJO DE DATOS (DFD)

El diagrama de flujo de datos es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por “conductos” y “tanques de almacenamiento” de datos. Los componentes de un DFD son: el proceso, el flujo y el terminador.

Sus principales características son:

** Prácticamente no requiere explicación; se puede simplemente mirar el diagrama

** El diagrama cabe fácilmente en una página. Esto significa dos cosas: y entenderlo. La notación es sencilla y clara .

1 .- Alguien puede mirarlo sin ofuscarse. 2.- El sistema que se esta modelando no es muy complejo.

** Guarda cierto estándar. Existen paquetes para computadoras que hacen estos diagramas.

Un ejemplo de un Diagrama de Flujo de Datos se muestra en la figura 2.7

COMPONENTES

PROCESO El proceso o función muestra una parte del sistema que transforma entradas en salidas y su símbolo es:

Impuestos

El nombre del proceso describirá lo que hace. Es decir será un verbo. No pueden existir procesos que solo tengan entradas o salidas.

FLUJO Se representa gráficamente por medio de una flecha que entra o sale de un proceso. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Por ello, los flujos representan datos en movimiento.

Un ejemplo de flujos se encuentra en la figura 2.8

Documentación Metodología 2- 1 O

Universidad Autónoma Metropolitana lztapalapa Proyecto final

EL ALMACEN Se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas o un rectángulo redondeado. El nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos. El analista conoce a los almacenes como archivos o bases de datos. Un ejemplo de un almacén se encuentra en la figura 2.9

EL TERMINADOR

Se representa como un rectángulo. Representa entidades externas con las cuales el sistema se comunica. Comúnmente, un terminador es una persona o un grupo, por ejemplo, una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía, pero hera del control del sistema que se esta modelando. En algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste.

Departamento de contabilidad

2.5.3 GUM PARA LA CONSTRUCCION DE UN DFD

1.- Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.

2.- Numerar los procesos.

3 .- Redibujar el DFD tantas veces como sea necesario estéticamente.

4.- Evitar los DFD excesivamente complejos.

5.- Asegurarse de que el DFD sea internamente consistente y que también lo sea con cualesquiera DFD relacionados con él.

Documentación Metodología 2- I 1

Universidad Autónoma Metropol7tana lztapalapa

2.6 Diccionario de Datos

Proyecto Final

1 Document

Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculo intermedios. El diccionario de datos define los datos haciendo lo siguiente:

0 Describe el significado de los flujos y almacenes que se muestran en los DFD.

0 Describe la composición de agregados de paquetes de datos que se muevan a lo largo de los de los flujos, es decir, paquetes complejos (por ejemplo el domicilio del cliente), que pueden descomponerse en unidades más elementales (como ciudad, estado y código postal).

0 Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relación.

2.6.1. NOTACION DEL DICCIONARIO DE DATOS

= está compuesto de

+ Y

( ) optativo (puede estar presente o ausente)

{ } iteración

[ ] seleccionar una de varias alternativas.

* * comentario.

Arroba. identificador (campo llave) para un almacén

1 separa opciones alternativas en la construcción.

ejemplo.

nombre = título de cortesía f nombre + (segundo nombre) + apellido

título de cortesía = [Sr. I Srita. I Dr. I Profesor]

nombre = { carácter legal }

segundo nombre = {carácter legal }

n Metodología 2- 12

Proyecto final

apellido = { carácter legal

carácter legal = [A-Z I a-z I 0-9 I , I I 3

2.6.2.DEFINICIONES

A= B+C puede leerse de las siguientes maneras: ** Cuando digamos A, queremos decir una B y una C. ** A se compone de B y C. ** A se define como B y C.

Para definir por completo un dato, nuestra definición debe incluir lo siguiente: 1.- El significado del dato dentro del contexto de la aplicación de este usuario. Por lo común se ofrece como comentario utilizando la notación "**". 2.- La composición del dato, si se compone de partes elementales con significado. 3.- Los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse más.

Un diccionario de datos es una labor muy pesada pero muy importante. Puede tener tanta información como se quiera. El diccionario de datos también contiene la lista de tablas, campos, tipos de datos, etc.

d Autónoma Metropolitana lztapalapa

c L 7, Especificaciones de procesos

2.7.1 PROPOSITO:

Define lo que debe hacerse para transformar entradas en salidas. En otras palabras describe qué es lo que sucede en cada una de las burbujas de procesos de más bajo nivel. Existen varias herramientas que se utilizan para producir una especificación de proceso: tablas de decisiones, leguaje estructurado (español, ingles, etc.), prelpost condiciones, diagramas de flujo, diagramas de NassUShneiderman, etc.

El método que se elija debe satisfacer dos requisitos:

** La especificación del proceso debe expresarse de una manera que puedan verificar tanto el usuario como el analista.

** El proceso debe especificarse en una forma que pueda ser comunicada efectivamente al público amplio que esté involucrado.

A continuación revisaremos algunas herramientas.

Documentación Metodologia 2- 13

I Universidad Authoma Metropolitana lztapalapa

2.7.2. LENGUAJE ESTRUCTURADO

Proyecto Final

I I El lenguaje estructurado, como el nombre lo indica, es “lenguaje español (o ingles u

otro ) con estructura. Es decir, es un subconjunto de todo el idioma con importantes restricciones sobre el tipo de frases que pueden utilizarse y la manera en que pueden juntarse dichas frases. Ejemplo.

FIJAR IMPUESTOS A 13 SUMAR3AX MULTLPLICAR PRECIO UNITARIO POR CANTIDAD DIVIDIR GANANCIAS ACTUALES ENTRE PERDIDAS ACTUALES

total diario = O HACER MIENTRAS haya más pedidos en PEDIDOS con fecha-de-pedido = fecha de hoy

MOSTRAR a contabilidad número de pedidos, nombre del cliente y cantidad-total total diario = total diario + cantidad total

mostrar a contabilidad total-diario

LEER el siguiente PEDIDO con fecha-de-pedido = fecha de hoy ’

FIN-HACER

SI edad-del-cliente es mayor que 65 fijar cuota a cuota-ancianos

OTRO fijar cuota a cuota-normal

FIN-SI

2.8. Diagramas de flujo

Son una herramienta mucho más gráfica y que en muchas ocaciones los usuarios estén más familiarizados con ellos. Un diagrama de flujo muestra una lógica secuencia1 y detallada y de tipo procedimiento. Los símbolos utilizados en los diagramas de flujo se han hecho de uso común en cualquier organización. Un ejemplo lo podrá observa en la figura 2.10

I

Documentacit5n Metodología 2- 14

Universidad Autónoma MetropoKtana lztapalapa Proyecto Final

Una vez vistas estas herramientas nos damos cuenta que existen muchas formas de describir las actividades o políticas de los usuarios para que un programador pueda automatizar en un programa dichas reglas. Otras de las formas más comunes de hacer especificaciones de procesos es el pseudopascal o pseudoC, que consiste en utilizar el lenguaje cotidiano y algunas instrucciones de algún lenguaje de programación tal como Pascal, C, etc.

2.9. Diagramas de Entidad-Relación (DER, DEA)

Es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema. Con este modelo se contestan algunas de las preguntas que se tienen acerca de los datos de las personas administrativas. (por ejemplo el presidente o gerente de la empresa). como son: ¿Que datos requerimos para manejar nuestro negocio? ¿Quien tiene dichos datos? ¿Quien tiene acceso a los datos? etc, etc. Un ejemplo tipico de un Diagrama de Entidad-Relación es el visto en la figura 2- 1 l.

Aveces construir primeramente el modelo de datos hace más fácil descubrir cuales son las hnciones requeridas del sistema.

Los componentes de un DER son:

1.- Tipos de objetos (tablas, archivos, BD). 2.- Relaciones. 3.- Indicadores asociativos de tipo de objeto. 4.- Indicadores de supertipohbtipo.

TWOS DE OBJETOS. Se representa por medio de una caja rectangular y representa una colección o conjunto de objetos (cosas) del mundo real.

I CLIENTE I El objeto es el algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo un objeto también pudiera ser algo no material: por ejemplo, horarios, planes, estándares, estrategias y mapas.

Documentaci6n Metodología 2- 15

Universidad Aut&noma Metropolitana liapalapa Proyecto final

Dado que a menudo las personas son tipos de objetos en un sistema, debe tenerse otra cosa en mente: una persona o cualquier cosa material pudiera ser diversos tipos de objetos distintos. Por ejemplo, Juan Pérez puede ser EMPLEADO o CLIENTE.

RELACIONES Los objetos se conectan entre sí mediante relaciones. Una relación representa un conjunto de conexiones entre objetos, y se representa por medio de un rombo. Cada instancia de la relación representa una asociación entre cero o más ocurrencias de un objeto y cero o más ocurrencias del otro. Son multidireccionales (se leen en cualquier dirección ) Muestran cardinalidad (muestran el número de objetos que participan en la relación). Un ejemplo se muestra en la figura a 2.12

Documentacibn Metodología 2- 16

I

s m U m

M

U M

O

&

ib P

Y

5 O

O

e m

9

O

Universidad Autónoma Metropoikana lztapaiapa Proyecto Final

Capítulo 3 Análisis

3.7 Modelo Ambiental

0 DECLARACI~N DEL PROPOSITO u OBJETIVO

El propósito del sistema de información SAUAM (Sistema de Almacén de la Universidad Autónoma Metropolitana) es almacenar y controlar la información para poder automatizar las actividades realizadas en un almacén. Esto incluye el control de una solicitud de entrada, control de inventarios, validación de existencias, manejo de puntos de reorden y control de una solicitud de salida de un artículo del almacén. Además de proporcionar al usuario consultas en línea y elaboración de reportes.

o LISTA DE EVENTOS La siguiente lista de eventos corresponde a las principales actividades 0 procesos que el sistema debe cubrir para poder alcanzar el objetivo planteado.

1, Un C.R. (Centro de Responsabilidad) solicita mercancía o artículos al

2. Compras genera un pedido u orden de entrada al almacén. 3. El proveedor surte los pedidos y entrega una factura para revisión y posterior

4. El almacén da entrada al artículo 5. El cliente retira mercancías del almacén

departamento de compras.

cobro.

Manual de Usuario introducción 3- 1

Universidad Autónoma MetropolTtana lztapalapa Proyecto Final

6. El almacén da salida a los artículos del almacén 7. Los clientes compran mercancías atravez de solicitarla por un pedido 8. Los clientes devuelven mercancías 9. Consulta de cuantos pedidos tiene el cliente 10.A proveedor se le devuelve mercancía 1 1 .El almacén recibe mercancías como transferencias de otros almacenes 12.E1 almacén manda mercancías a otros almacenes como transferencias 13 .El almacén genera una póliza para contabilidad 14.E1 cliente pregunta sobre el estatus de un pedido 15.Mantenimiento a los diferentes catálogos. 16.Reporte de gastos por almacén 17.Reporte de existencias en el almacén 18.Reporte de entradas al almacén 19.Reporte de salidas del almacén 20.Generación de ordenes de Entrada y salida 2 1 .Calculo del lnventario

0 DIAGRAMA DE CONTEXTO La fig. 3.1 nos muestra el diagrama de contexto para que podamos darnos cuenta cuales son las fronteras de nuestra sistema y conquienes interactuará. Podemos observar que el sistema involucra la relación con proveedores, clientes, centros de responsabilidad, el sistema de tesoreria, etc, etc.

DICCIONARIO DE DATOS

Como lo mensionamos en el capitulo anterior el diccionario de datos debe hacerse con las definiciones de los datos. En este caso de estudio no llevaremos a fondo el diccionario de datos, solo contendrá: los nombres de las tablas, los campos por cada tabla y algunas especificaciones más usuales.

0 DIAGRAMA DE ENTIDAD-RELACION

En las figuras 3.2, 3.3, 3.4 se muestran los diagramas de Entidad-Relación referentes al área de compras, ventas y almacén los cuales nos muestran los elementos de datos que interactuan. Se puede observar la cardinalidad que existe entre los elementos.

Manual de Usuario Introducción 3-2


Esta parte del diccionario de datos muestra las definiciones de los objetos utilizados en los diagramas.

A continuación presentamos en forma de tablas las entidades o archivos que se ocuparan en el sistema.

FSAUAO1 TIPOS DE CLIENTES

I 1 I TiuCte I Tiuo de Cliente lDec 12 l o I o 2

Date Cuando Ultima modificación WHEN01 4 O O 2 Dec Categoria de Cliente CatCte 3 BLANKS 50 Char Descripción del Tipo DesTip

5 BLANKS O 20 Char Quien Ultima modificación WHO01 6 O O 6 Dec Hora Ultima modificación TIME011

17 I P R O G O I I Programa Ultima modificación I Char I 10 I I BLANKS

1

BLANKS 40 Char Calle v número CalleC 4 BLANKS 50 Char Razón Social RazSoc 3 O O 3 Dec Número de la Tienda NumTda 2 O O 6 Dec Número de Cliente NumCte

5 ColCte Colonia Char 40 BLANKS 6 DelCte Delegación Char 40 BLANKS 7 RFCCte Registro Federal de Contribuyentes Cahr 13 BLANKS 8 TelCte Telefono Dec 7 O O

6 DelCte Delegación Char 40 BLANKS 7 RFCCte Registro Federal de Contribuyentes Cahr 13 BLANKS 8 TelCte Telefono Dec 7 O O 9

BLANKS 50 Char Nombre del dueño NomDue 10 O O 2 Dec Tipo de cliente (giro) TipCte

11 BLANKS O 20 Char Ouien Ultima modificación WHO02 12

Da.te Cuando Ultima modificación WHEN02

13 I TIME021 I Hora Ultima modificación lDec 16 l o 10 I 14 I PROG02 I Programa Ultima modificación I Char I 10 [BLANKS I

Manual de Usuatio Introducción 3-3


FSAUU3 CENTROS DE RESl

NumDep I Número de Departamento lDec 12 O O

1 2 3 4 5 6 7 8 9 10 11 12 13 14 -

NumDiv Número de División NumCos Número de Centro de Costo NomDep Nombre del Departamento NomDiv Nombre de la División

Dec 2 Dec 2 O Char I 30 Char I 30

NomCos I Nobre del Centro de Costo I Char I30 NCta I Cuenta lDec 13 O

O O

NSCta Sub-Cuenta Dec 3 NSSCta Sub-Sub-Cuenta Dec 3 NSSSCta Sub-Sub-Sub-Cuenta Dec 3 O WHEN03 I Cuando Ultima modificación I Date I WHO03 I Ouien Ultima modificación I Char 120 O BLANKS TIME03 I Hora Ultima modificación Dec 6 PROG03 Programa Ultima modificación Char 10

O O BLANKS

FSAUU4 TIPOS DE PROVEEDORES

PROVEEDORES

1 INumPro I Número de Cliente Dec 16 l o I I 2 INomPro I Número de Tienda Dec 13 l o I I 3 IDenPro I Denominación del Proveedor Char I50 I I I

5 ColPro Colonia 6 DelPro Delegación 7 EdoPro Estado 8 RFCPro Registro Federal de Contribuventes 9 CodPos Codigo Postal 10 FaxPro Fax del Proveedor 11 TelPro Telefono del Proveedor 12 ContPr Nonbre del Contacto 11 WHEN05 Cuando Ultima modificación Date

Char I20 I O ]BLANKS I 12 WHO05 Quien Ultima modificación 13 TIME051 Hora Ultima modificación 14 PROGO5 Programa Ultima modificación

Dec 6 O O Char 10 BLANKS


Universidad Autónoma Metropolitana lktapalapa Proyecto Final

SCTAA O O 3 Dec Sub-Sub-Cuenta tlara el Abono SSCTAA O O 3 Dec Sub-Cuenta para el Abono

I ISSSCTA I Sub-Sub-Sub-Cuenta Dara el Abono lDec 16 l o I o 11 12

Date Cuando Ultima modificación WHEN06

BLANKS 10 Char Programa Ultima modificación PROGO6 14 O O 6 Dec Hora Ultima modificación TIME061 13 BLANKS O 20 Char Quien Ultima modificación WHO06

1

BLANKS 40 Char Calle del emtlleado CalleE 3 BLANKS 50 Cahr Nombre del Empleado NomEimp 2 O O 6 Dec Número de Empleado NumEmp

I 10 I PROW7 I Programa Ultima modificación I Char I 10

FSA U08 ,VERIES Y FOLIOS

12 1Folio I Contador de Folios lDec 16 l o l o 1 3

Date Cuando Ultima modificación WHEN08 4 Blanks 40 Char Descripción del Folio DesFol

5

Blanks 10 Char Programa Ultima modificación PROGO8 7 O O 6 Dec Hora Ultima modificación TIME081 6 Blanks O 20 Char Quien Ultima modificación WHO08

Manual de Usuario lntroduccih 3-5


FSAUO9 ARTICULOS

1 NumSec Número de Sección



FSA U1 O ORll

1 Serie0 Serie de la Orden de E/S 2 Folio0 Folio de la Orden de E/S 3 FecOrd Fecha de la Orden de E/S 3 TipMov Tipo de movimiento 4 NumCte Número de Cliente 5 NumTda Número de Tienda 6 NumPro Número de Proveedor 7 NumSec Número de Sección 8 NumFam Número de Familia 9 NumGpo Número de Grupo 10 NumArt Número de Artículo 11 CantAr Cantidad entregada 12 ImpArt Importe de lo relacionado 13 IvaArt IVA de lo relacionado 14 IepArt IEPS de lo relacionado 15 TotArt Total de lo relacionado 16 WHEN10 Cuando Ultima modificación 17 WHO10 Quien Ultima modificación 18 TIME10 Hora Ultima modificación

,19 PROG10 Programa Ultima modificación

IENES DE ENTRADMSALIDA

Char 13 I I Blanks Dec 16 10 l o Date 8 O Dec 2 O O

Dec 12 I o I o Char 13 I I Blanks

Dec

Dec 115 12 I o Dec I15 12 I o Date 18 l o

O I Blanks

k Blanks

FSAU11 .RTERA

1 I SerieT I Serie de la transacción I Char Blanks I 3 6 8 6 3 6 3 3 15 15 15 15 15 15 8 8 20 6 10

2 I FolioT I Folio de la transacción I Dec O 3 FecTra Fecha de la transacción Date 4 NumCte Número de cliente Dec 5 NumTda Número de tienda Dec 6 NumPro Número de Proveedor Dec 7 NumCon Número de concepto Dec

O O O O I O

8 ConRef Concepto de referencia Dec 9 ImpTra Importe de la transacción Dec 10 IvaTra IVA de la transacción Dec 11 IepTra IEPS de la transacción Dec 12 TotTra Total de la transacción Dec 13 I SdoTra I Saldo de la transacción I Dec 2

2 14 AcuTra Acumulado de movimientos Dec 15 FecUlt Fecha de ultimo movimiento Date 4 WHEN0 1 1 Cuando Ultima modificación Date

1

5 WHO11 Quien Ultima modificación Char 6 TIME111 Hora Ultima modificación Dec

O O

7 I P R O G I ~ I Programa Ultima modificación I Char Blanks I


Universidad Autónoma Metropolitana lztapaapa Proyecto Final

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

-

-

-

FSAU13 FACTURAS CAL

SerFac Serie de la factura Char 3 FolFac Folio de la factura Dec 6 O FecFac I Fecha de la factura I Date 18 I NumCte Núero de Cliente Dec 6 O NumTda Número de Tienda Dec 3 O NumPro Número de Proveedor Dec 6 O TotCar I Total de cartones lDec 110 10 ImDFac I Importe de la factura lDec 115 12 IvaFac I IVA de la factura lDec 115 12 IepFac I IEPS de la factura lDec 115 12 TotFac I Total de la factura lDec I15 12 WHEN0 13 Cuando Ultima modificación Date 8 WHO13 Quien Ultima modificación Char 20 O

~ TIME131 Hora Ultima modificación Dec 6 O 1 PROG13 I Programa Ultima modificación I Char I10 I

ECERO

Blanks I O I

O I O I O I

I Blanks Blanks I



FSAUl4 FACTURAS D

1 SerFac Serie de la factura Char 3 2 FolFac Folio de la factura Dec 6 O 3 FecFac Fecha de la factura Date 8 4 NumCte Núero de Cliente Dec 6 O 5 NumTda Número de Tienda Dec 3 O

15 IepFac IEPS de la factura Dec 15 2 16 TotFac Total de la factura Dec 15 2 17 WHEN0 14 Cuando Ultima modificación Date 8 18 WHO14 Quien Ultima modificación Char 20 O 19 TIME141 Hora Ultima modificación Dec 6 O 20 PROG14 Programa Ultima modificación Char 10

!?TALLE ;D$i@Qmy " , . . . . . . . . . . . . . . . . . . . . . Blanks O O O O O O Blanks O O O O O O O O O Blanks O Blanks



FSAUl6 COTIZACIONES

10 I IvaCot I IVA de la factura lDec 115 12 IO I 11

O 8 Date Cuando Ultima modificación WHEN0 16 14 O 2 15 Dec Total de la factura TotCot 13 O O 2 Dec Nímero de secuencia de cotización NumCot 12 O 2 15 Dec IEPS de la factura IepCot

15 O O 6 Dec Hora Ultima modificación TIME161 16 Blanks O 20 Char Quien Ultima modificación WHO16

I17 lPROG16 I Programa Ultima modificación I Char I 10 I Blanks I Manual de Usuario


Manual de Usuario Introducción 3- I I

Manual de Usuario lntroduccíbn 3- 72


Manual de Usuario Introducción 3- 13


Acontinuación presentaremos las tablas en forma de lista.

o1 .- 02.- 03 .- 04.- 05.- 06.- 07.- 08.- 09.- 10.- 11.- 12.- 13.- 14.- 15.- 16.- 17.- 18.- 19.- 20.-

FSAUO 1 FSAU02 FSAU03 FSAU04 FSAUOS FSAU06 FSAU07 FSAU08 FSAU09 FSAUlO FSAUl1 FSAU12 FSAU13 FSAU14 FSAUl5 FSAU16 FSAU17 FSAU18 FSAU19 FSAU20

TIPOS DE CLIENTES CLLENTES CENTROS DE RESPONSABILIDAD TIPOS DE PROVEEDORES PROVEEDORES CONCEPTOS EMPLEADOS SERLES Y FOLIOS ARTICULOS ORDENES DE ENTRADNSALIDA TRANSACCIONES DE CARTERA REFERENCIA DE APLICACIONES FACTURAS CABECERO FACTURAS DETALLE PEDIDOS COTIZACIONES REQUISICIONES SALDOS POR CLIENTE SALDOS POR PROVEEDOR REGlSTRO DE CQNTROL

Documentación Análisis 3- 14

I

n t 7

z O i O

z O Y

W E #


3.2 Modelo de Comportamiento

El modelo de comportamiento es el modelo de comportamiento final que el sistema debe tener para manejar con éxito el ambiente. Con este modelo se empieza a apreciar el flujo de los datos y la implementación de los acontecimientos de la lista. Se representan los eventos en forma de diagrama de flujo.

Una fase del modelo de comportamiento es la realización del diagrma de flujo de datos para ver como fluyen los datos en el sistema. Adicionalmente se contempla la realización de rutinas en pseudocodigo para darnos cuenta de que manera se presentarian los programas.

Documentación AnAisis 3- 1

Universidad Autónoma Metropolitana Irtapalapa Proyecto Final

Definicibn de Procesos

MANTENIMIENTO DE CATALOGOS

PRINCIPAL Presenta menu principal elije la opción correcta Si opción es valida

Si opción = Alta Ejecuta ALTA

Si opción = Baja Ejecuta BAJA

Si opción = Modificación Ejecuta MODIFICACION

Otro manda mensaje salir

Termina

ALTA Captura la clave Valida que la clave sea valida Si la clave no existe

Otro

Termina

se da de alta en el archivo

se manda mensaje informativo

MODIFICACION Captura la clave Valida que la clave sea valida Si la clave no existe

Otro se manda mensaje de informativo

se presenta el registro en pantalla se valida la información modificada Mientras este mal

Termina-Mientras Se actualiza el registro

se presenta la pantalla

Termina

Documentación Andisis 3-2

Universidad Autónoma Metropolitana lztapalapa

BAJA Captura la clave Se valida la clave Si la clave no existe

Otro

Termina

se manda un mensaje informativo

se borra el registro

Proyecto Final

Documentación Análisis 3-3

1 c3 O

1' 2 !2 3 Z O N

-14 O I 8 B O m

3 n

1 o CA

1

CA J


Capítulo 4 Conclusiones

4. I Conclusiones

El análisis de sistemas es la percepción y simulación ordenada del mundo. Apesar de que muchas empresas no han adoptado una metodología para el desarrollo de sistemas. Vemos con gusto que muchas empresas más están haciendo reingenieria en sus departamentos de sistemas y comienzan a preocuparse por tener una metodología de trabajo más ordenada. A medida de que las empresas adopten metodologias estructuradas para el desarrollo de sistemas, tendrán sistemas, más robustos y se tendrá un control en los sistemas además de tener documentado sus sistemas y hacer así los cambios más fácilmente.

Se presentó en este trabajo el punto de vista del análisis tradicional y los puntos por los cuales esta metodología no es la apropiada para el desarrollo de sistemas. Una vez presentada la metodología tradicional se paso a presentar la metodología estructurada que nos presenta cosas nuevas y soluciona puntos en los cuales se han venido cometiendo errores. El uso de esta metodología no representa la solución a todos los problemas relacionados a los sistemas existentes en una empresa, pero esto da punto de inicio para organizar y garantizar el seguimiento de los proyectos y una calidad más elevada.

Documentación Conclusiones 3- 1

Universidad Autdnoma Metropolitana lztapalapa Proyecto final

La metodología debe proponerse a las personas directivas del departamento e incluso a los dueños de la empresa. Otro punto muy importante es el uso de herramientas nuevas tanto para modelar como para hacer documentación de los sistemas.

El caso de estudio que se presentó lamentablemente se presentó a un nivel de análisis, pero describe claramente los principales pasos con los cuales debe una como analista cumplir para realizar un proyecto de análisis y diseño de sistemas. Espero que esta obra llegue a manos de muchas personas y que estas puedan a su vez divulgar la metodología estructurada. También me daría gusto que las personas que se inician en el análisis de sistemas y alumnos que toman la materia de análisis y diseño de sistemas en esta universidad leyeran esta obra.

Documentacibn Conclusiones 3-2

Universidad Autónoma Metropokana lztapalapa

4.2 Bibliografía

ANALISIS ESTRUCTURADO MODERNO Edward Yourdon Prentice-Hall Hispanoamericana, s a .

MANUAL DE METODOLOGIA Grupo Serfin

Proyecto Final

Documentacibn Conclusiones 3-3

sistema de almacén - 148.206.53.231

Documents