tesis

AUTOMATIZACIÓN DEL MÓDULO DE CAJA.

OPCIÓN X: MEMORIA DE RESIDENCIA

PROFESIONAL

QUE PARA OBTENER EL TÍTULO DE: INGENIERA EN SISTEMAS

COMPUTACIONALES

PRESENTA:

ELIZABETH MÁRQUEZ BRAVO

MARZO DE 2008

Automatización del módulo de Caja

0111- 1

AGRADECIMIENTOS

A mis padres y hermano : Porque a pesar de las adversidades han estado ahí para

apoyarme en todo.

A la empresa PATSA Servicios S.A. DE C.V. y a mis c ompañeros de trabajo por

permitir realizar mi proyecto de residencia, y ahora por darme la oportunidad de

unirme a sus filas de colaboradores.

Agradezco y dedico este trabajo muy en especial al hombre más carismático,

inteligente, bondadoso y amoroso que haya conocido jamás, por su total apoyo

para concluir satisfactoriamente mis estudios y que con su presencia hizo de

mi estancia en este mundo algo especial e inigualab le. Con todo mi amor y

respeto para el I.S.C. Leonardo Bustamante González (QEPD), gracias por todo

corazón de cielo.

Sinceramente: Elizabeth Márquez Bravo.


0111- 1

ÍNDICE

INTRODUCCIÓN ........................................................................................................ 1 JUSTIFICACIÓN ......................................................................................................... 3 OBJETIVO GENERAL ................................................................................................ 6 OBJETIVOS ESPECÍFICOS ....................................................................................... 6 CARACTERIZACIÓN DEL ÁREA EN QUE SE PARTICIPÓ..................................... 7 PROBLEMAS A RESOLVER ...................................................................................... 9 ALCANCES Y LIMITACIONES ..................................................................................11 1 MARCO TEÓRICO .............................................................................................12

1.1 Modelo Estructurado ....................................................................................12 1.2 Sistema operativo UNIX...............................................................................20

1.2.1 Administración de Archivos y Directorios..............................................22 1.3 Base de datos jerárquica .............................................................................23 1.4 Paradigmas de programación ......................................................................26 1.5 Programación procedural o de procedimientos............................................27 1.6 Organización de archivos.............................................................................27 1.7 Archivos maestros........................................................................................28 1.8 Características del lenguaje SISINF. ...........................................................29 1.9 Conceptos contables....................................................................................40

2 PROCEDIMIENTO Y DESCRIPCIÓN DE LAS ACTIVIDADES ..........................42

2.1 Análisis.........................................................................................................43 2.1.1 Requerimientos mínimos de hardware y software ................................43

2.2 Comprensión y diseño de la base de datos .................................................60 2.3 Implementación............................................................................................67 2.4 Implantación y capacitación del sistema de caja..........................................72 2.5 Elaboración de manuales.............................................................................73

3 RESULTADOS, GRÁFICAS PROGRAMAS Y PANTALLAS DEL SISTEMA......74

3.1 Explicación de la gráfica del proceso automatizado de caja ........................74 3.2 Código relevante que se generó en la programación del sistema ...............76 3.3 Pantallas del sistema ...................................................................................80

CONCLUSIONES Y RECOMENDACIONES .............................................................84 REFERENCIAS BIBLIOGRÁFICAS ...........................................................................86


1 0111-

INTRODUCCIÓN

PATSA es una empresa del ramo avícola que se ha caracterizado por su

rápido crecimiento en los últimos años y esto debido a que ha tratado de estar al día

en tecnología y procedimientos nuevos que permitan su avance y progreso.

Hasta el momento la gran mayoría de los procesos están siendo automatizados para

tener un mejor control de cualquier movimiento que ocurra y esto se ve reflejado en

la información que se puede obtener día a día de cada uno de estos movimientos a

través de los sistemas ya implantados.

El sistema del departamento de caja de la empresa PATSA no existía anteriormente,

todos los procedimientos se realizaban manualmente, y así era mas difícil identificar

procedimientos erróneos, además se necesitaba que cada uno de los movimientos

de este departamento estuvieran registrados de forma electrónica para tener un

seguimiento confiable del proceso, al mismo tiempo alimentar de forma inmediata

otros sistemas que comparten información con el departamento de caja.

El presente documento describirá a detalle el proyecto del sistema del departamento

de caja de la empresa PATSA y cada uno de los pasos que lo conforman, haciendo

detalles específicos de funciones y operaciones. También se encuentra registrada y

transmitida sin distorsión, la información que fue proporcionada para la creación del

sistema, se informa desde la justificación del proyecto hasta los alcances obtenidos.


2 0111-

El documento se desarrolla en 3 capítulos: I.- Marco teórico: Se explican algunos

conceptos y teorías relacionadas con el modelo y el software utilizados para el

desarrollo del proyecto, II.- Procedimiento y descripción de las actividades: Se

explican las diferentes actividades desempeñadas y la forma de proceder en cada

una de ellas durante el proceso de desarrollo, y III.- Resultados gráficas, programas y

pantallas del sistema: Se exponen algunos gráficos y una parte del código mas

relevante así como una breve explicación de este.


3 0111-

JUSTIFICACIÓN

El departamento de caja de la empresa PATSA tiene las siguientes características en

cuanto a su proceso:

El departamento de caja cuenta con un fondo fijo diario de $20,000 es decir durante

el día el personal de la empresa puede solicitar dinero a dicho departamento

mientras se tenga la cantidad disponible solicitada.

El proceso de caja consiste en llenar un recibo manualmente donde se debe colocar

la fecha, el importe y la descripción de los gastos que se pretenden realizar. En las

oficinas los jefes de área cuentan con estos recibos pero en las demás áreas de la

empresa el solicitante se tiene que trasladar hasta oficinas para llenar dicho recibo.

Al final del día la persona encargada de caja utiliza una sumadora para calcular el

dinero otorgado de todas las solicitudes, con el riesgo de que se pueda traspapelar

alguna de estas.

El departamento de Contabilidad recibe la documentación de los usuarios después

de haber realizado sus gastos, y este departamento tiene que clasificar todos esos

gastos en cada una de las cuentas contables que maneja el departamento, estas se

encuentran integradas por una cuenta de mayor, una sub-cuenta, una sub-sub-

cuenta y una sub-sub-sub-cuenta. Así que para esto la persona del departamento de

contabilidad encargada de capturar esta información deberá conocer el área y la

sección en la que labora el usuario que entregó dicha documentación o de lo


4 0111-

contrario buscar los datos necesarios para poder capturar finalmente los gastos

generados.

También es difícil obtener información estadística del proceso y aún más difícil

detectar anomalías y/o errores ocasionados por las personas involucradas en el

proceso. La única manera de lograrlo es hacer un sistema que capture la información

necesaria que se genera en el departamento de caja, logrando tener un mejor control

del dinero solicitado así como un control de los usuarios que piden el dinero, no

importando el área y la sección a la que pertenezcan y no habrá necesidad de salir a

oficinas a pedir el recibo para su llenado, ya que si el área de la empresa donde se

encuentra el usuario cuenta con una computadora y acceso a la red LAN, se podrá

capturar desde ahí la solicitud.

Se pretende que el usuario sea responsable de sus propias solicitudes y tenga a la

vez el control de las mismas.

Lo más importante y trascendental es que el sistema de caja forma parte de la

información que se almacenará para calcular los gastos totales de toda la empresa

con el único fin de que se pueda tener el costo del pollo en cualquier momento del

procesamiento.

Los departamentos beneficiados con este sistema son el de contabilidad, caja y

gerencia.


5 0111-

Contabilidad: Podrá realizar de una manera eficiente y confiable las pólizas de

egresos que realizaban anteriormente de forma manual, así como el envío de los

gastos a sus respectivos centros de costo.

Caja: Podrá hacer su solicitud de cheque de una manera confiable sin necesidad de

sumar cada una de las solicitudes concedidas. Se le facilitará un menú donde pueda

generar reportes para conocer la actividad del departamento y podrá modificar las

solicitudes de los usuarios en los casos en que estas presenten errores.

Gerencia: Se le han reservado una serie de reportes que le muestran datos

específicos de los movimientos ocurridos en Caja y que le serán de suma

importancia para conocer de forma oportuna el funcionamiento de este sistema.

Para este proyecto no se requerirá de la adquisición de software o hardware

adicional, ya que en todos los departamentos de la empresa cuentan por lo menos

con una computadora con acceso al servidor mediante la red LAN. En el caso de que

el usuario tenga algún problema en el manejo de la PC, la persona encargada del

departamento de caja podrá realizar el proceso del usuario.


6 0111-

OBJETIVO GENERAL

Desarrollar e implementar un sistema para la automatización del departamento de

caja de la empresa PATSA, Servicios S.A. de C.V., con el fin de obtener información

al día de lo que ocurre durante el proceso que se lleva a cabo en el departamento,

tener control de cada una de las solicitudes de dinero y almacenar la información

para consultas informativas y estadísticas.

OBJETIVOS ESPECÍFICOS

• Hacer un análisis del proceso de caja utilizando diagramas DFD.

• Diseñar una base de datos jerárquica que involucre todos los campos

necesarios para el proceso.

• Implementar cada uno de los módulos en el lenguaje SISINF en base al

análisis y el diseño de la base datos.

• Realizar las pruebas necesarias antes de la implantación del sistema.

• Capacitar al personal involucrado en el proceso de caja.

• Documentar todos los módulos del sistema para su mantenimiento a futuro.


7 0111-

CARACTERIZACIÓN DEL ÁREA EN QUE SE PARTICIPÓ

El área de trabajo donde se desarrolló el proyecto fue el departamento de Sistemas e

Informática de PATSA Servicios S.A. de C.V. que forma parte del área administrativa

de la empresa, cabe mencionar que para la obtención de la información también se

trabajó con el departamento de caja.

A continuación se presenta el organigrama, objetivo y descripción de funciones del

departamento de sistemas e informática.

Objetivo general del departamento de sistemas:

Crear sistemas computacionales acordes a las necesidades de la empresa.

Descripción de funciones:

• Programar sistemas computacionales utilizando las instrucciones mas

recientes con el lenguaje SISINF, dando así lugar a un sistema actualizado,

con las ventajas de la tecnología que en ese momento se puedan aportar.

Figura 1. Organigrama del Departamento de Sistemas e Informática de la empresa PATSA Servicios S.A. de C.V.

SOPORTE TECNICO

Gustavo Alfonso Hernández Hernández

JEFE DE SISTEMAS

I.S.C. Margarito Colmenares Olivera

JEFE DEL DEPTO. DE SISTEMAS E INFORMATICA I.S.C. J.F. Javier Estrada Zarate

PROGRAMADOR Jr. 2

PROGRAMADOR Jr. 1


8 0111-

• Capacitar al personal con el nuevo sistema antes de ponerlo a prueba e

implantarlo.

• Documentar los sistemas que se vayan terminando explicando paso a paso la

función de cada uno de los programas que componen dicho sistema.

• Auxiliará en la instalación e implantación de paquetería en computadoras

personales.

• Auxiliará en tareas administrativas del departamento.

Departamento de caja

Figura 2. Organigrama del área Administrativa de PATSA

Caja es el departamento que se encarga de administrar el dinero en efectivo de la

empresa, el cual esta representado por monedas y billetes. De los cuales $ 20,000

diariamente están a disposición de los trabajadores de la empresa que soliciten cierta

cantidad justificada previamente para realizar gastos que requieran el pago inmediato

y en efectivo.

ÁREA

ADMINISTRATIVA

GESTO-

RIA

CONTABI-

LIDAD

COM-PRAS

SISTEMAS

CAJA

CUENTAS POR

PAGAR

CREDITO Y

COBRAN-ZA

FINAN-

ZAS

ALMA-CEN E

INVENTA-RIOS


9 0111-

PROBLEMAS A RESOLVER

El proceso que se realiza en la actualidad no permite conocer la información

oportunamente, ya que el tiempo que se llevan en recopilar la información depende

de las personas involucradas en el proceso, además de que se presta a errores y

malos manejos.

El usuario tiene que trasladarse hasta las oficinas administrativas de la empresa para

llenar la solicitud, y para llevar el control de la comprobación de los gastos lo hacen a

través de una hoja de Excel, de la cual si no actualizan sus formulas, generan datos

incorrectos.

En cuestión de almacenamiento lo único que se guarda directo al servidor es el

monto de dinero solicitado durante el día, pero no la información generada de cada

uno de los solicitantes que es importante para el seguimiento del proceso.

Para el departamento de contabilidad es bastante laborioso, ubicar cada uno de los

diferentes gastos en las cuentas contables al final del mes cuando generan la póliza,

debido a que tienen que recurrir a cada una de las solicitudes y en cuando la solicitud

no muestra la información necesaria, entonces deben dirigirse personalmente con el

solicitante y preguntarle sobre los gastos que realizó.

En los casos en que el solicitante no presente sus comprobantes de gastos, muchas

veces por errores técnicos el dinero que les fue otorgado no se les descuenta de


10 0111-

nomina y por política de la empresa, todo solicitante que no realice la comprobación,

tendrá que devolver al 100% el dinero otorgado.

Por último, no existe ningún tipo de reporte que muestre información sobre el

departamento de caja, por lo que es cuestionable su buen funcionamiento.


11 0111-

ALCANCES Y LIMITACIONES

El sistema de caja proporcionará de manera rápida e inequívoca información

exacta de los gastos que se realizan en efectivo, además de ayudar en forma precisa

al departamento de Contabilidad creando pólizas de egresos de forma automática

que les servirá para hacer posteriormente, en términos contables la balanza y

estados financieros.

El sistema esta diseñado para funcionar como cliente-servidor, por lo que solo se

necesita contar con una dirección IP de la red y conectarse al servidor a través de un

emulador de Terminal de UNIX que trabaja sobre Windows, por lo que cualquier

usuario o personal nuevo a la empresa podrá utilizar el sistema sin ningún problema.

El gerente general de la empresa podrá tomar decisiones más confiables y

sustentables a través de la información que le proporcione el departamento de Caja.

Hasta el momento no se visualiza ninguna limitación que pudiera frenar el

desempeño del sistema.


12 0111-

1 MARCO TEÓRICO

En este capítulo se explicarán algunos conceptos y teorías relacionadas con el

modelo y el software utilizados para el desarrollo del proyecto. El modelo en que se

rige el proyecto es el modelo estructurado y el lenguaje que se utilizó es SISINF que

es un lenguaje procedural con una base de datos jerárquica que trabaja sobre la

plataforma de UNIX.

1.1 Modelo Estructurado

El modelo estructurado proporciona un enfoque sistemático para el diseño y

construcción de sistemas de cómputo de calidad. A lo largo del análisis y diseño, el

analista debe proceder paso a paso obteniendo retroalimentación de los usuarios y

analizando el diseño, buscando omisiones y errores. Los siguientes puntos describen

una a una las actividades de este modelo representado en la figura 3:


13 0111-

ACTIVIDAD 1. RECOPILACIÓN DE INFORMACIÓN . Comienza cuando el usuario

solicita que una o más partes de sus procesos se automaticen, o se modifiquen. Los

principales objetivos son:

Figura 3. Diagrama del modelo estructurado


14 0111-

• Identificar a los usuarios responsables y crear un “campo de actividad” inicial

del sistema. Esto puede comprender una serie de entrevistas para determinar

usuarios involucrados en el proyecto.

• Identificar deficiencias actuales en el ambiente del usuario. Como que el

hardware del sistema actual no es confiable; el software no se puede

mantener, o no es conveniente.

• Preparar el esquema que se usará para guiar el proyecto.

ACTIVIDAD 2. EL ANÁLISIS DE SISTEMAS. El propósito de esta actividad es

transformar sus entradas principales, políticas del usuario y esquema del proyecto en

una especificación estructurada. Esto implica modelar el ambiente del usuario con

diagramas de flujo de datos, diagrama de entidad - relación, diagramas de transición

de estados y otras herramientas.

Muchos especialistas en sistemas de información reconocen la dificultad de

comprender de manera completa sistemas grandes y complejos. El método de

desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por

medio de:

1). La división del sistema en componentes.

2). La construcción de un modelo del sistema.


15 0111-

El análisis estructurado se concentra en especificar lo que se requiere que haga el

sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo

que hará el sistema) separados de los componentes físicos (computadora,

terminales, sistemas de almacenamiento, etc.). Después de esto se puede

desarrollar un diseño físico eficiente para la situación donde será utilizado.

El análisis estructurado es un método para el análisis de sistemas manuales o

automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos

o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista

conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que

proporciona la base para asegurar que no se omite ningún detalle pertinente.

Componentes

Símbolos gráficos: Iconos y convenciones para identificar y describir los

componentes de un sistema junto con las relaciones entre estos componentes.

Diccionario de datos: Descripción de todos los datos usados en el sistema. Puede

ser manual o automatizado.

Descripciones de procesos y procedimientos: Declaraciones formales que usan

técnicas y lenguajes que permiten a los analistas describir actividades importantes

que forman parte del sistema.

Reglas: estándares para describir y documentar el sistema en forma correcta y

completa.


16 0111-

Diseño Estructurado.

El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis

Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de

especificaciones del software.

El objetivo del Diseño Estructurado es programas formados por módulos

independientes unos de otros desde el punto de vista funcional.

La herramienta fundamental del Diseño Estructurado es el diagrama estructurado

que es de naturaleza gráfica y evitan cualquier referencia relacionada con el

hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas

(que es la tarea de los diagramas de flujo).

Los Diagramas Estructurados describen la interacción entre módulos independientes

junto con los datos que un módulo pasa a otro cuando interacciona con él.

Análisis de flujo de datos.

Estudia el empleo de los datos para llevar a cabo procesos específicos de la

empresa dentro del ámbito de una investigación de sistemas usa los diagrama de

flujos de datos y los diccionarios de datos.

El enfoque del flujo de datos para la determinación de requerimientos.

Cuando los analistas de sistemas tratan de comprender los requerimientos de

información de los usuarios, deben ser capaces de conceptualizar la forma en que


17 0111-

los datos se mueven a través de la organización, los procesos o transformaciones

que sufren los datos y lo que son las salidas. Aunque las entrevistas y la

investigación de datos relevantes proporcionan una narración verbal del sistema, una

representación visual puede cristalizar esta información en una forma útil.

Mediante una técnica de análisis estructurado llamado diagramas de flujo de datos

(DFD), el analista de sistemas puede reunir una representación gráfica de los

procesos de datos a lo largo de la organización. El enfoque de flujo de datos enfatiza

la lógica subyacente del sistema.

Diagrama de flujo de datos

Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual

se desarrollan otros componentes.

El modelo original se detalla en diagramas de bajo nivel que muestran características

adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de

datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen

suficientes detalles para que el analista comprenda la parte del sistema que se

encuentra bajo investigación.

El diagrama físico de datos da un panorama del sistema en uso, dependiente de la

implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen

nombres de personas, nombres o números de formato y documento, nombres de

departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados,

ubicaciones, nombres de procedimientos.


18 0111-

El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico

es independiente de la implantación, que se centra en el flujo de datos entre los

procesos, sin considerar los dispositivos específicos y la localización de los

almacenes de datos o personas en el sistema. Sin indicarse las características

físicas.

ACTIVIDAD 3. EL DISEÑO. Esta actividad se dedica a la creación de una jerarquía

apropiada de módulos de programas y de interfaces entre ellos para implantar la

especificación creada en la actividad de análisis. Además transforma el modelo de

datos en un diseño de base de datos.

ACTIVIDAD 4. IMPLEMENTACIÓN. Incluye la codificación y la integración de

módulos en un esqueleto progresivamente más completo del sistema final. Incluye

tanto programación como implantación descendente.

ACTIVIDAD 5. GENERACIÓN DE PRUEBAS DE ACEPTACIÓN. Una vez generada

la especificación, puede comenzar la actividad de producir un conjunto de casos de

pruebas de aceptación desde la especificación estructurada.


19 0111-

ACTIVIDAD 6. GARANTÍA DE CALIDAD. También llamada prueba final o prueba de

aceptación. Requiere como entrada los datos de prueba de aceptación generada en

la actividad 5 y el sistema integrado producido en la actividad 4.

ACTIVIDAD 7. DESCRIPCIÓN DEL PROCEDIMIENTO. Una de las actividades

importantes 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 interactúan los

usuarios con la parte automatizada del nuevo sistema. El resultado de esta actividad

es un manual para el usuario.

ACTIVIDAD 8. CONVERSIÓN DE LA BASE DE DATOS. En algunos proyectos la

conversión de la base de datos involucra más trabajo y más planeación estratégica

que el desarrollo de programas del nuevo sistema. En otros casos puede no existir

una base de datos que convertir. En general esta actividad requiere como entrada la

base de datos actual del usuario, al igual que la actividad de diseño producida por la

actividad 3.

ACTIVIDAD 9. INSTALACIÓN. Esta es la actividad final, sus entradas son el manual

del usuario producido en la actividad 7, la base de datos convertida que se creó con

la actividad 8 y el sistema aceptado producido por la actividad 6. En algunos casos la

instalación podrá ser total; pero también puede ser un proceso gradual, en el que un


20 0111-

grupo tras otro de usuarios van recibiendo manuales y entrenamiento y comenzando

a usar el nuevo sistema.

1.2 Sistema operativo UNIX

UNIX es un sistema operativo de tiempo compartido, controla los recursos de una

computadora y los asigna entre los usuarios. Permite a los usuarios correr sus

programas. Controla los dispositivos de periféricos conectados a la máquina. En la

figura 4 se muestra la arquitectura del sistema UNIX.

Posee las siguientes características:

- Es un sistema operativo multiusuario, con capacidad de simular

multiprocesamiento y procesamiento no interactivo.

- Está escrito en un lenguaje de alto nivel: “C”.

- Dispone de un lenguaje de control programable llamado SHELL.

Figura 4. Arquitectura del Sistema Unix


21 0111-

- Ofrece facilidades para la creación de programas y sistemas y el ambiente

adecuado para las tareas de diseños de software.

- Emplea manejo dinámico de memoria por intercambio o paginación.

- Tiene capacidad de interconexión de procesos.

- Permite comunicación entre procesos.

- Emplea un sistema jerárquico de archivos, con facilidades de protección de

archivos, cuentas y procesos.

- Tiene facilidad para redireccionamiento de Entradas/Salidas.

- Garantiza un alto grado de portabilidad.

El sistema se basa en un Núcleo llamado Kernel, que reside

permanentemente en la memoria, y que atiende a todas las llamadas del sistema,

administra el acceso a los archivos y el inicio o la suspensión de las tareas de los

usuarios.

La comunicación con el sistema UNIX se da mediante un programa de control

llamado SHELL. Este es un lenguaje de control y un intérprete, cuyas características

lo hacen sumamente flexible.

El shell permite modificar en forma dinámica las características con que se

ejecutan los programas en UNIX:

Las entradas y salidas pueden ser redireccionadas o redirigidas hacia

archivos, procesos y dispositivos;

� Es posible interconectar procesos entre sí.


22 0111-

� Diferentes usuarios pueden "ver" versiones distintas del sistema operativo

debido a la capacidad del shell para configurar diversos ambientes de

ejecución. Por ejemplo, se puede hacer que un usuario entre directamente a

su sección, ejecute un programa en particular y salga automáticamente del

sistema al terminar de usarlo.

1.2.1 Administración de Archivos y Directorios

El sistema de archivos de Unix; está basado en un modelo arborescente y

recursivo, en el cual los nodos pueden ser tanto archivos como directorios, y estos

últimos pueden contener a su vez directorios o subdirectorios. Debido a esta filosofía,

se maneja al sistema con muy pocas órdenes, que permiten una gran gama de

posibilidades. Todo archivo de Unix está controlado por múltiples niveles de

protección, que especifican los permisos de acceso al mismo. La diferencia que

existe entre un archivo de datos, un programa, un manejador de entrada/salida o una

instrucción ejecutable se refleja en estos parámetros, de modo que el sistema

operativo adquiere características de coherencia y estética que lo distinguen.

La raíz del sistema de archivos (conocida como root) se denota con el símbolo

“/”, y de ahí se desprende un conjunto de directorios que contienen todos los archivos

del sistema de cómputo. Cada directorio, a su vez, funciona como la subraíz de un

nuevo árbol que depende de él y que también puede estar formado por directorios o

subdirectorios y archivos. Un archivo siempre ocupará el nivel más bajo dentro del

árbol, porque de un archivo no pueden depender otros; si así fuera, sería un

directorio. Es decir, los archivos son como las hojas del árbol.


23 0111-

Se define en forma unívoca el nombre de todo archivo (o directorio) mediante

lo que se conoce como su trayectoria (path name): es decir, el conjunto completo de

directorios, a partir de root (/), por los que hay que pasar para poder llegar al

directorio o archivo deseado. Cada nombre se separa de los otros con el símbolo /,

aunque tan sólo el primero de ellos se refiere a la raíz.

1.3 Base de datos jerárquica

Visión lógica y física de datos. Una base de datos a diferencia de un archivo. Esta

hecha para que sea compartida por muchos usuarios.

El modelo lógico de la base de datos debe ser transformado en un diseño de base de

datos físico correspondiente. El diseño físico esta involucrado con la manera en que

son guardados y relacionados los datos, así como la manera que son accesados.

Hay tres tipos principales de bases de datos estructuradas lógicamente: jerárquicas,

en red y relacionales. En la figura 5 encontramos en ejemplo de estructuras

jerárquicas.

Figura 5. Ejemplo de estructura jerárquica de base de datos.


24 0111-

Una Base de datos jerárquica es un tipo de Sistema Gestor de Bases de Datos que,

como su nombre indica, almacenan la información en una estructura jerárquica que

enlaza los registros en forma de estructura de árbol (similar a un árbol visto al revés),

en donde un nodo padre de información puede tener varios nodos hijo.

Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden

establecerse relaciones entre nodos hermanos. En este caso la estructura en forma

de árbol se convierte en una estructura en forma de grafo dirigido. Esta variante se

denomina Bases de datos de red.

A diferencia del modelo relacional, el modelo jerárquico no diferencia una vista lógica

de una vista física de la base de datos. De manera que las relaciones entre datos se

establecen siempre a nivel físico, es decir, mediante referencia a direcciones físicas

del medio de almacenamiento (sectores y pistas).

Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo

relacional. Cada registro consta de un conjunto de campos, el equivalente a las

columnas del modelo relacional. Un conjunto de registros con los mismos campos se

denomina fichero (record type, en inglés), el equivalente a las tablas del modelo

relacional.

El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a

varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son

unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por

ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de

su departamento (nodo padre), pero no al contrario. Esto implica que solamente se


25 0111-

puede consultar la base de datos desde los nodos hoja hacia el nodo raíz. La

consulta en el sentido contrario requiere una búsqueda secuencial por todos los

registros de la base de datos (por ejemplo, para consultar todos los empleados de un

departamento). En las bases de datos jerárquicas no existen índices que faciliten

esta tarea.

Obsérvese que, a priori, no existen relaciones N:M (de muchos a muchos) en el

modelo jerárquico. Salvo que se simulen mediante varias relaciones 1:N. No

obstante, esto puede provocar problemas de inconsistencia, ya que el gestor de base

de datos no controla estas relaciones.

Como ya se ha mencionado, las relaciones se establecen mediante punteros entre

registros. Es decir, un registro hijo contiene la dirección física en el medio de

almacenamiento de su registro padre. Esto tiene una ventaja fundamental sobre las

bases de datos relacionales: el rendimiento. El acceso de un registro a otro es

prácticamente inmediato sin necesidad de consultar tablas de correspondencia.

Las relaciones jerárquicas entre diferentes tipos de datos pueden hacer que sea muy

sencillo responder a determinadas preguntas, pero muy difícil el contestar a otras.


26 0111-

1.4 Paradigmas de programación

Un paradigma de programación representa un enfoque particular o filosofía para la

construcción del software. No es mejor uno que otro sino que cada uno tiene

ventajas y desventajas. También hay situaciones donde un paradigma resulta más

apropiado que otro.

Algunos ejemplos de paradigmas de programación:

• Programación imperativa

• Programación procedural

• Programación funcional

• Programación lógica

• Programación estructurada

• Programación dirigida por eventos

• Programación modular

• Programación Orientada a Aspectos

• Programación Orientada a Objetos

• Programación con restricciones

• Programación por capas

• Programación a nivel funcional (John Backus)

• Programación a nivel de valores (John Backus)


27 0111-

1.5 Programación procedural o de procedimientos

La programación por procedimientos es un paradigma de la programación. Muchas

veces es aplicable tanto en lenguajes de programación de bajo nivel como en

lenguajes de alto nivel, en el caso de que esta técnica se aplique en lenguajes de

alto nivel, recibirá el nombre de Programación funcional , esta técnica consiste en

basarse de un número muy bajo de expresiones repetidas, englobarlas todas en un

procedimiento o función y llamarlo cada vez que tenga que ejecutarse.

Esta técnica de programación ofrece muy buena respuesta en relación a el tamaño

de los programas, y en bruto casi no se nota en la velocidad de ejecución del mismo

(mientras que las variables, constantes o índices de vector estén en memoria, como

suele ser normal, estos se relacionarán entre si, sin una carga de memoria

considerablemente alta para los procesadores modernos); aunque es muy

complicado conseguir una Programación por procedimientos pura.

1.6 Organización de archivos

Un archivo contiene grupos de registros usados para proporcionar información para

operación, planeación, administración y toma de decisiones. Primero se describen

los tipos de archivos usados y a continuación se presenta una descripción de las

muchas formas en que pueden ser organizados los archivos convencionales.


28 0111-

Tipos de archivos . Los archivos pueden ser usados para guardar datos durante un

periodo de tiempo o pueden ser usados para guardar datos temporalmente para un

propósito específico. Los archivos maestros y los archivos de tablas son usados para

guardar datos durante un periodo largo. Los archivos temporales son llamados, por lo

general, archivos de transacciones, archivos de trabajo o archivos de reporte.

1.7 Archivos maestros

Los archivos maestros contienen registros de un grupo de entidades. Los atributos

pueden ser actualizados frecuentemente, pero los registros mismos son

relativamente permanentes. Estos archivos tienden a tener grandes registros que

contienen toda la información acerca de una entidad de datos. Cada registro

contiene, por lo general, una llave primaria y varias llaves secundarias.

Frecuentemente, los archivos maestros son guardados como archivos indexados o

secuenciales con índice. Aunque el analista tiene la libertad de poner los elementos

de datos dentro de un archivo maestro en cualquier orden, un acomodo estándar es,

por lo general, poner primero el campo de llave primaria, seguido de elementos

descriptivos y, por ultimo, los elementos que reflejan al negocio y que cambian

frecuentemente con las actividades del negocio.

Organización secuencial. Cuando los registros están físicamente en orden en un

archivo se dice que el archivo es un archivo secuencial. Cuando es actualizado un

archivo secuencial es necesario recorrer todo el archivo. Debido a que los registros


29 0111-

no pueden ser insertados en la parte media del archivo secuencial es, por lo general,

copiado durante el proceso de actualización.

Organización indexada. Un índice es diferente de un apuntador, debido a que es

guardado en un archivo aparte del archivo de datos. Cuando el número de archivos

de índice aumenta, es posible usar archivos de índice para guardar muchos de los

datos. La cantidad de información en los archivos de índice puede ser bastante larga.

En este caso, a la estructura se le menciona como una lista invertida.

Las listas invertidas son muy adecuadas cuando se usan para encontrar información

sobre una combinación específica de llaves.

Organización secuencial indexada. Un método de organización ampliamente usado

es llamado organización secuencial indexada o ISAM (por método de acceso

secuencial indexado). En un archivo ISAM los registros están colocados en bloques.

Los registros dentro de los bloques de registros pueden estar en cualquier orden. Por

lo tanto, se necesita un índice para localizar los bloques de registros.

1.8 Características del lenguaje SISINF.

SISINF (SIStemas de INFormación) se encuentra implantado en diversos

Sistemas Operativos que debido a su funcionalidad pueden presentarse en

cuatro grupos:


30 0111-

1. HP-3000. Que abarca los Sistemas Operativos que trabajan en esta

plataforma, tales como MPE-V, MPE-XL y MPE-IX.

2. MS-DOS. Que agrupa los Sistemas Operativos que trabajan en

computadoras personales o redes de ellas, tales como MS-DOS

propiamente, WINDOWS 3.1, WINDOWS 95, WINDOWS NT,

WINDOWS 98, WINDOWS ME, NOVELL, LANTASTIC.

3. VMS. Que agrupan los Sistemas Operativos de DIGITAL para equipos

VAX y equipos ALPHA.

4. UNIX. Agrupa los Sistemas Operativos SCO-XENIX, SCO-UNIX, HP-UX, AIX,

TRU64, OSFI y LINUX.

SISINF es un sistema computacional formado por un lenguaje computacional

procedural y una base de datos que juntos forman lo que se llama SISINF.

SISINF está orientado hacia el manejo eficiente de la información en las

aplicaciones administrativas y de producción de la empresa, las cuales se

programan a través del Lenguaje, que permite el desarrollo de las mismas en

forma rápida y eficiente.

El lenguaje SISINF propone una forma de trabajo diferente tanto en el análisis y

programación de las aplicaciones, como en la forma de operación.


31 0111-

El analista, a la hora que está diseñando la aplicación, se enfoca a la

solución del problema sin preocuparse por la programación, esto permite dar

mayor importancia al análisis, teniendo por consecuencia, aplicaciones mejor

diseñadas.

Posteriormente, cuando se lleva a cabo la etapa de implantación del

Sistema, los cambios usuales de último momento son hechos con facilidad,

ya que los programas en este Lenguaje son cortos y sencillos.

En la operación de las aplicaciones, se propone la captura de información

por terminales; esto permite hacer una validación en el momento. En algunas

aplicaciones se puede hacer dicha captura a tiempo real, es decir, al mismo

tiempo en que se recibe la información por parte del usuario de un sistema y

en el sitio donde se origina.

El Lenguaje Computacional SISINF está formado por un grupo de

definiciones y un grupo de instrucciones. Con las definiciones el usuario

define todas las características de los archivos y variables una sola vez al

inicio del sistema. Con las instrucciones el usuario programa sus

aplicaciones en una forma sencilla. Dichas instrucciones están enfocadas al

manejo de archivos del banco de datos, archivos secuenciales, lectura y

desplegado de información en terminal e impresión de reportes.

Para el manejo de archivos del banco de datos se tienen las siguientes

características:


32 0111-

Se tiene un banco de datos de tipo jerárquico y navegacional, de varios

niveles.

- Se tienen en cada nivel uno o más tipos diferentes de registros.

- Se pueden recorrer los registros de niveles inferiores en el orden de inserción

o en un orden específico

- Se pueden accesar a todos los registros de un archivo en forma

secuencial (ordenado por sus llaves).

- Se pueden accesar a todos aquellos registros cuyas llaves sean

iguales a valores específicos.

- El sistema controla en forma automática el acceso a un archivo por

varios usuarios.

- El sistema controla en forma automática la creación, apertura y cierre

de archivos.

Si se hacen cambios a las estructuras de los archivos de una aplicación, es

necesario reconstruir los archivos y solamente volver a compilar los

programas que los usen, sin necesidad de hacerles ningún cambio. Tal sería

el caso de agregar nuevas variables a los archivos para el uso de nuevos

programas a desarrollar.

Módulos para el desarrollo de sistemas . Son los módulos básicos de SISINF que

intervienen directamente en las fases de diseño y operación de un sistema

computacional.


33 0111-

Módulo DBD (Compilador del Banco de Datos de SISINF). A través del módulo DBD

se define la estructura que tendrán los archivos que forman la base de datos de un

sistema.

Cada archivo de la base de datos tiene una estructura jerárquica, integrada por

recurrentes, o sea tipos de registros; a su vez cada registro está compuesto por un

conjunto de campos de información.

Para la DBD se cuenta con el lenguaje de definición de datos, que posee las

instrucciones para definir cada archivo, su estructura, tipos de registros, y los campos

que lo integran.

Las instrucciones que definen a una base de datos se alimentan de la DBD a través

de un archivo texto creado con un editor común; DBD revisa que tales instrucciones

estén correctamente especificadas y que la definición de cada archivo sea completa;

a partir de esto, DBD genera los esquemas internos de los archivos de la base de

datos, que serán usados posteriormente al compilarse los programas que hagan

referencia a tales archivos.

El proceso de definición de una base de datos se ilustra en la figura 6:


34 0111-

Módulo CLS (Compilador del Lenguaje Sisinf). A través del módulo CLS se definen

los procesos que se llevarán a cabo en el sistema de información, y que actuarán

sobre la base de datos previamente definida, como se puede ver en la figura 7.

La unidad elemental de proceso en SISINF es el programa. Cada programa puede

atender uno o varios tipos de transacciones dentro de uno o varios archivos de la

base de datos, pretendiendo que cada programa sea una función de un proceso, es

decir, una unidad congruente de operaciones sobre una entidad de información. Así,

un proceso complejo puede integrarse por la ejecución de una secuencia de

programas.

Para usar CLS se cuenta con el lenguaje de manipulación de datos, que provee las

instrucciones generales para:

• Manejar la base de datos.

• Manejar archivos secuenciales.

• Manejar terminales.

• Manejar escritura de reportes.

• Manipular información alfanumérica, numérica, de tipo fechas, imágenes y

audio.

Figura 6. Proceso de definición de una base de datos.


35 0111-

• Efectuar operaciones aritméticas.

• Comunicarse con programas hechos en otros lenguajes.

Módulo ELS (Ejecutor del Lenguaje SISINF). La ejecución de los programas en

SISINF se hace a través del módulo ELS, el cual es un monitor interpretador del

seudo-código generado por el compilador CLS para cada programa. Se encarga,

entre otras cosas, de:

• Efectuar las operaciones de manipulación de datos y aritméticas, validaciones,

verificaciones y manejo de fechas.

• Controlar el acceso a los archivos de la base de datos, incluyendo la

coordinación de acceso por múltiples usuarios.

• Controlar las operaciones de lectura y escritura en terminales, impresoras y

archivos secuenciales.

• Establece la comunicación necesaria con el sistema operativo

La figura 8 ilustra el proceso de ejecución de un programa:

Figura 7. Proceso del compilador del lenguaje Sisinf


36 0111-

Acceso a la base de datos: El acceso a la base de datos de SISINF es a nivel de

archivo, es decir, se selecciona el archivo por su nombre. Un programa puede estar

usando uno o varios archivos al mismo tiempo.

Para el acceso a la información de un archivo, SISINF proporciona las siguientes dos

estrategias:

A través de la estructura jerárquica: Esta estrategia permite tener acceso a las

ocurrencias de un tipo de recurrente. Para ello es necesario primero accesar el

registro padre, es decir, aquel del cual depende el recurrente.

Estando en el registro en cuestión, ya sea maestro o recurrente, se puede navegar a

través de cualquiera de los recurrentes que dependen de él, aún en forma

simultánea. Repitiendo el proceso, se puede llegar a todos los registros de niveles

inferiores.

Las ocurrencias de un recurrente que pertenecen a un mismo padre, forman la lista

lineal en la que los registros aparecen en el orden en que fueron insertados.

Figura 8. Proceso del ejecutor del lenguaje Sisinf


37 0111-

La instrucción de BUSCAR RECURRENTE permite recorrer la lista, con las

siguientes opciones mostradas en la tabla 1:

INF. Se posiciona al inicio de la lista SUP. Se posiciona al final de la lista ANT. Recorre desde el último registro accesado hacia delante SIG. Recorre desde el último registro accesado hacia atrás ORD. Recorre la lista ordenada por ciertos campos

Si en la instrucción se especifican variables, se hace una búsqueda secuencial en el

sentido indicado, hasta encontrar aquel registro que tenga valores iguales a los de

las variables indicadas.

A través de directorios (llaves): SISINF brinda al usuario la facilidad de establecer

accesos directos a los archivos, a través de la declaración de directorios, conocidos

como grupos de llaves; cada archivo puede tener varios directorios, en cualquier

nivel, cada uno de los cuales establece un medio de acceso diferente para el archivo.

Para tener un directorio el usuario selecciona uno o varios campos de un tipo de

recurrente, para que juntos constituyan la LLAVE DE ACCESO. La declaración de

directorios se hace al declarar el archivo en la DBD.

Cada valor de la llave en un directorio está acompañado de apuntadores al registro

de datos, ya sea maestro o recurrente, que contiene la información referenciada,

permitiendo así el acceso directo a la información, sin necesidad de hacer el acceso

a través de toda la estructura jerárquica.

Tabla 1. Accesos a través de la estructura jerárquica.


38 0111-

Al usar directorios para accesar un recurrente dependiente, automáticamente se

accesan también el o los registros de niveles superiores de los que depende el

registro accesado.

El uso de directorios para accesar un archivo es a través de la instrucción BUSCAR

DISCO, en la que se especifica, entre otras cosas, el directorio a usar, la forma de

usar el directorio, y si es aplicable, el o los valores específicos de la llave que se

desea encontrar.

Las formas de usar un directorio, conocidas como OPCIONES DE BÚSQUEDA, se

ilustran en la tabla 2:

SEC. Recorre el directorio en forma secuencial ascendente PRIN. Dado un valor o conjunto de valores de la llave, localiza el primer registro que tenga un valor

igual en el directorio. NO-

PRIN. Dado un valor o conjunto de valores de la llave, localiza el siguiente registro que tenga un valor igual en el directorio.

APROX. Dado un valor o conjunto de valores de la llave, localiza al primer registro que tenga un valor igual o mayor en el directorio.

BUSC. Certifica exclusivamente la existencia de un valor dado en el directorio, no actualiza apuntadores.

ULT. Se posiciona al final de un directorio.

Relación entre archivos: SISINF permite igualar variables de un archivo en otro

archivo, brindando con esto la facilidad de poder relacionar los archivos entre sí. De

esta manera, tomando el ejemplo anterior del archivo de clientes y del archivo de

bancos, si establecemos que el R3 (facturas) del archivo de clientes tiene un campo

que corresponde al número de factura, y lo igualamos en el recurrente R2 (depósitos)

del archivo de bancos, esto dará como resultado que al consultar los depósitos de

Tabla 2. Opciones de búsqueda a través de directorios


39 0111-

una cuenta, podremos establecer el número de factura al que corresponde, si aplica,

para cada uno de ellos, y claro está, de qué cliente se trata e inclusive de qué

pedido.

El código correspondiente en SISINF para esta simple consulta sería algo como lo

siguiente:

--- Iniciar el valor de BAN-NUM-CUENTA ----

---

BUSCAR DISCO BANCO EJECUTA 20 PRIN-G2 BAN-NUM-CUENTA

LEER DISCO BANCO BAN-NOM-BANCO

OPCION DISCO BANCO INICIO-R2

10 BUSCAR RECURRENTE BANCO 2 EJECUTA 20 ANT.

LEER DISCO BANCO CLT-NUM-FACTURA BAN-DEP-FECHA

BUSCAR DISCO CLIENT EJECUTA 999 PRIN-G3 CLT-NUM-FACTURA

LEER DISCO CLIENT CLT-RAZ-SOCIAL

--- Manipular información que se acaba de leer ---

---

EJECUTA 10

20 --- Continuar con otras instrucciones ---

---

Donde los campos:

BAN-NUM-CUENTA Se declaró en R1 del archivo de bancos como campo llave número 2.

BAN-NOM-BANCO Se declaró en R0 del archivo de bancos como campo simple.

BAN-DEP-FECHA Se declaró en R2 del archivo de bancos como campo simple.

CLT-NUM-

FACTURA

Se declaró en R3 del archivo de clientes como campo llave número 3, y se igualó

en R2 del archivo bancos como campo simple.

CLT-RAZ-SOCIAL Se declaró en R0 del archivo de clientes como campo simple.


40 0111-

Valores máximos: A continuación se enumeran algunos de los valores máximo

permitidos en SISINF para así reflejar el alcance que puede tener:

Descripción Valor máximo

Archivos por DBD 200

Tablas por DBD 100

Áreas con nombre por DBD 50

Grupos de llaves por archivo 10

Variables en un grupo de llaves 20

Recurrentes por archivo 30

Niveles de seguridad en un archivo 20

Variables por recurrente 125 (número de dependientes)

Archivos por programa 20

Tablas por programa 20

Variables por programa 400

Temporales por programa 20

Niveles de seguridad por programa 20

Variables en SUBPROGRAMA 50

Vectores por programa 10

Rutinas por programa 20

Áreas por programa 64

Variables por área 70

Etiquetas por programa 1000

1.9 Conceptos contables Una póliza es un documento donde se asientan o se registran las operaciones de la

empresa, a las cuales se les anexa los documentos que comprueban dichas

operaciones.


41 0111-

Una póliza de egresos se elabora cuando se expide un cheque o hay salida de

dinero en efectivo. Debe contener la aplicación contable de acuerdo con las claves

del catalogo de cuentas que maneja la empresa.

Cuenta: es el registro donde se controlan ordenadamente las variaciones o

alteraciones que producen las operaciones en los diferentes elementos o conceptos

del activo, pasivo y capital contable de la entidad o empresa.

Los datos que debe contener la póliza son:

Nombre de la compañía

Nombre o tipo de póliza

Fecha de elaboración de la póliza

Número de la póliza

1 columna para el número de la cuenta y subcuentas

Nombre de las cuentas

1 columna para cargos

1 columna para abonos

Firmas de la persona que la hizó, de quien la revisó y quien la autorizó.


42 0111-

2 PROCEDIMIENTO Y DESCRIPCIÓN DE LAS ACTIVIDADES

� �

� �

� �

� �

� �

� �

ELA

BO

RA

CIÓ

N

DE

MA

NU

ALE

S

� �

� �

� �

� �

� �

� � �

� � �

IMP

LEM

EN

TA

CIÓ

N

Y C

AP

AC

ITA

CIÓ

N

� � �

� � � � � � � �

� � � � � � � �

� � � � � � � �

� � � � � � � �

� � � � � � � �

� � � � � � � �

PR

OG

RA

MA

CIÓ

N

� � � � � � � �

� � �

� � �

� � �

� � �

� � �

� � � �

DIS

EÑ

O

� � � �

� �

� �

� �

�

�

AN

ÁLI

SIS

� Semanas 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Meses Agosto

2006 Septiembre

2006 Octubre 2006 Noviembre

2006 Diciembre

2006

Figura. 9 Diagrama de Gantt de las actividades realizadas


43 0111-

En la figura 9 esta representado el diagrama de Gantt utilizado para programar las

actividades que se llevaron a cabo durante el proyecto del sistema del departamento

de caja.

En este capítulo se describirán cada una de estas actividades, las cuales son:

Análisis, diseño de la base de datos, implementación, implantación y capacitación y

por último elaboración de manuales.

2.1 Análisis

El análisis requiere como primer punto identificar los problemas, oportunidades y

objetivos, se necesita observar honestamente lo que sucede en el área donde se

realiza el proyecto. En este primer punto las personas involucradas son los usuarios,

analistas y administradores del proyecto.

2.1.1 Requerimientos mínimos de hardware y software

En este punto se describirán las características del equipo hardware y software con

el que cuenta la empresa y que es el que se utilizó para el desarrollo del proyecto.

Se cuenta aproximadamente con una computadora por usuario en casi todas las

áreas, con características en hardware generalmente de mas de 20 GB en disco

duro, 128 MB de memoria, procesadores celeron con velocidad de 1 GH.

Características en software: Windows xp service pack 1 y 2, paquetería office,


44 0111-

emulador Reflection para el accesso al servidor, controlador para impresora HP en

red.

Características del servidor de la empresa:

• Compatibilidad con la versión basada en Itanium provista de capacidad para

64 vías del sistema Superdome con gradación del rendimiento para 64 CPU

• HP-UX Partition Manager permite ejecutar HP-UX 11i, Windows y Linux en

particiones independientes

• Administración de varios sistemas operativos para la ejecución de HP-UX,

Windows y Linux en particiones de hardware independientes

• Soporte para 1 terabyte de memoria principal

• Compatibilidad con todos los servidores Itanium 2 comercializados

anteriormente: HP Integrity rx5670 y HP Integrity rx2600

• Memoria local en células para escalabilidad del rendimiento de

Superdome/Itanium

• PCI y PCI-X Doorbell para posibilitar la sustitución de tarjetas de E/S en línea

con una pulsación

• Otros seis parámetros del kernel optimizables dinámicamente: dbc_max_pct,

dbc_min_pct, nflocks, nfile, maxfiles y fs_symlinks

• nPars (particiones de hardware)

• VxFS/VxVM/CVM 3.5 (VERITAS File System, VERITAS Volume Manager,

VERITAS Cluster Manager) con hasta 1024 ACL (Access Control Lists - Listas


45 0111-

de control de acceso), un tamaño máximo de archivo de 2 terabytes y un

tamaño máximo del sistema de archivos de 4 terabytes. VxFS es el sistema de

archivos por defecto

• Mejoras del rendimiento del conversor de códigos dinámico Aries (ejecuta

binarios PA-RISC en sistemas Itanium) en comparación con HP-UX 11i v1.6

(B.11.22)

• iCOD (instant Capacity on Demand - Capacidad instantánea a solicitud)

• Pay Per Use (PPU)

• Módulos del kernel cargables dinámicamente para sistema de archivos

• Java Virtual Machine (JVM) v1.4.1 con zona activa de 32 y 64 bits

• HP Workload Manager

• HP-UX Bastille para una configuración de sistema seguro

• Inicio del sistema y volcado de memoria más rápidos por medio de un mayor

paralelismo

• Compatibilidad binaria de aplicaciones con revisiones anteriores de HP-UX 11i

para Itanium [HP-UX 11i v1.5 (B.11.20) y HP-UX 11i v1.6 (B.11.22)]

• Compatibilidad de código fuente de aplicaciones con HP-UX 11i v1 en

sistemas PA-RISC

• Cargador dinámico

• HP WBEM Services para HP-UX para supervisar y controlar un conjunto

variado de recursos


46 0111-

• Adición y sustitución en línea de adaptadores de E/S

• Compatibilidad con el protocolo IPv6

• Conjunto de aplicaciones Mozilla (Mozilla es el navegador por defecto)

• HP-UX Secure Shell

• Mecanismo de configuración del kernel nuevo y mejorado

A partir de la información anterior se efectuaron una serie de entrevistas y se recabó

la información precisa que dejó a la vista lo que se tenía y a donde se pretendía

llegar con el proyecto. Para esto se hizo uso de herramientas tales como diagramas

de flujo donde se pudo obtener de manera gráfica, la entrada, proceso y salida de las

funciones del departamento de caja.

Con el análisis se hizo una propuesta del sistema, donde se proporcionó el análisis

de costo/beneficio de las alternativas y recomendaciones para mejorar todo el

proceso que se sigue.

La figura 10 muestra el diagrama de proceso de solicitudes a caja, este diseño fue

implementado por la empresa y está basado en diagramas administrativos y de

diagrama de flujo, el cual muestra los pasos que se llevan a cabo en cada

departamento y que en conjunto forman el proceso de principio a fin. Los símbolos

que se ocupan son los símbolos básicos de un diagrama de flujo, en los que los

rectángulos representan actividades, los círculos son inicio o fin del procedimiento,

los rombos son condiciones y las líneas indican la dirección de cada actividad.


47 0111-

PROCESO DE SOLICITUDES A CAJA

CAJAUSUARIOADMON. CONTABILIDADBANCOS

Genera Póliza de Egresos

(Encabezado)

Recibe Cheque por $20,000

Genera mediante el sistema una solicitud a caja por (X)

Cantidad

Verifica el concepto e

importe de dinero en la solicitud

Solicita se le autorice dicha solicitud

Autoriza Solicitud Recibe solicitud ya autorizada

Solicita a caja el importe de la solicitud

Entrega cheque por $20,000A caja

Verifica físicamente que la solicitud este

autorizada

Busca solicitud en el sistema y

corrobora datos

marca como concedido status de

la solicitudY

Entrega dinero a usuario

Recibe dinero del cajero

Realiza actividades y genera sus gastos correspondientes

* En la tarde *

Genera reporte de solicitudes

concedidas para verificar corte de

caja

Mediante el sistema genera

automáticamente Solicitud de cheque como reposición de fondo fijo por (X)

Cantidad producto de la suma de todas

las solicitudes concedidas

Solicita a Bancos Cheque

Genera Póliza de Egresos

(Encabezado)

Entrega cheque por (x) Cantidad a caja

Dinero para proporcionar a los usuarios por cada

solicitud

Captura gastos a comprobar a la solicitud correspondiente

FALTO DINERO

Genera otra solicitud a caja por la diferencia y le asigna

los gastos a comprobar correspondientes

SI

SOBRO DINERO

Entrega dinero a caja y recibirá a cambio un recibo de

ingreso capturado en la solicitud correspondiente

Recibe dinero y captura recibo de ingreso haciendo referencia a # de folio de la solicitud correspondiente

SI

NO

NO

* Recibe documentación

* Verifica que su codificación sea correcta, de lo

contrario la modificará

* Verifica la autenticidad de los gastos a comprobar

* Verifica que el importe de los

gastos a comprobar coincida con monto

solicitado

Genera detalle de la poliza que fue generada por

finanzas con los gastos a comprobar capturados por cada

usuarioEn este momento

tenemos la afectación al sistema

de costos

Al cierre de mes aplica pólizas a

balanza

FIN

INICIO CADA DIAINICIO DEL

SISTEMA POR PRIMERA VEZ

Esta de acuerdo

SI

Realiza las modificaciones correspondientes a la solicitud

NO

Entrega documentación a Contabilidad

Imprime solicitud con folio

Figura 10. Diagrama del proceso de solicitudes a caja. Diseño implementado por la empresa.


48 0111-

El diagrama detallado de flujo muestra un panorama de los módulos que se van a

utilizar así como las bases de datos que intervendrán.

La figura 11 muestra como primer punto la entrada de datos del usuario y que son el

número de compañía, iniciales y password, el primer paso es verificar si los datos

que deben de existir en la base de datos PUUSUA son correctos, si es así, se

redirecciona al módulo de solicitudes a caja, donde los datos que sean capturados

serán almacenados en la base de datos CLSOCA, una vez hecho esto, se procede a

la impresión de la solicitud, para que sea autorizada por el gerente, cuando es

autorizada se tendrá que ir a recoger el dinero en el departamento de caja, este

Figura 11. Diagrama detallado de flujo del proceso de Caja


49 0111-

deberá otorgar el dinero, a partir de este punto, caja realiza dos tareas, la primera es

otorgar el dinero a los solicitantes durante la jornada laboral y la segunda es generar

el reporte de solicitudes al término de su jornada.

En la primera tarea una vez que es otorgado el dinero, el solicitante lleva a cabo sus

gastos. Cuando concluya capturara dichos gastos que serán almacenados en la base

de datos CLSOCA, entregará los comprobantes en el departamento de Contabilidad

y esta a la vez generará la póliza de egresos.

La segunda tarea de caja se realiza una vez terminado de otorgar el dinero a todos

los solicitantes que concurrieron durante el día, generará un reporte de todos estos

movimientos y a través de este reporte podrá hacer la solicitud de cheque al

departamento de Bancos anexando al importe todas las solicitudes que fueron

concedidas, esta información se almacenará en la base de datos BASOLI. Por último

recogerá el cheque en el departamento de Bancos.

DIAGRAMA DE PROCESOS Y MÓDULOS

Los diagramas de procesos y módulos nos ayudan a identificar cada módulo que

estará contenido en el sistema, su función, módulos de donde son llamados y a los

que llamará, esto nos facilita la identificación de cada uno a la hora llevar a cabo la

implementación. A continuación se presenta cada uno de estos.


50 0111-

Función del módulo : Menú Principal.

Módulos llamadores : validación de iniciales y contraseña.

Módulos a llamar : Menú de usuarios, menú de caja y menú de contabilidad.

Objetivo : Acceso a los diferentes menús correspondiente a cada proceso

Entrada : validación por iniciales y contraseña

Proceso : acceso a menús

Salida : muestra el menú correspondiente.

Figura 12. Diagrama del módulo del menú principal.


51 0111-

Función del módulo : Menú de Usuarios.

Módulos llamadores : Menú Principal.

Módulos a llamar : A,B,M,C a solicitudes a Caja, A,B,M,C a comprobación de Gastos

y Reportes.

Objetivo : Capturar solicitud de Caja

Entrada : Por Menú Principal

Proceso : Genera folio de la solicitud a Caja consecutivo

Salida : Solicitud de Caja.

Figura 13. Diagrama del módulo del menú de usuarios.


52 0111-

Función del módulo : Solicitud a Caja.

Módulos llamadores : Menú de Usuarios.

Módulos a llamar : Altas, Bajas Modificaciones, Consultas, Imprimir.

Solicitud a Caja

Bajas

2

Modificaciones

3

Consultas

4

Imprimir

5

Altas

1

Objetivo : Control y manipulación de solicitudes a Caja

Entrada : Por menú de usuarios

Proceso : Control de solicitudes a Caja

Salida : Solicitud impresa.

Figura 14. Diagrama del módulo de solicitud a caja.


53 0111-

Función del módulo : Comprobación de gastos.

Módulos llamadores : Menú de usuarios.

Módulos a llamar : Altas, Bajas, Modificaciones, Consultas, Imprimir.

Objetivo : Control y manipulación de gastos a comprobar.

Entrada : Menú de usuarios.

Proceso : Control de comprobación de gastos.

Salida : Impresión y comprobación de gastos.

Figura 15. Diagrama del módulo de comprobación de gastos.


54 0111-

Función del módulo : Reportes.

Módulos llamadores : Menú de Usuarios.

Módulos a llamar : Solicitudes Realizadas a Caja, Comprobación de Gastos a

solicitudes, Usuarios que solicitan mas Dinero, Usuarios que no comprueban gastos

a tiempo, Gastos mas solicitados a Caja.

Objetivo : Generar Reportes.

Entrada : Menú de Usuarios.

Proceso : Genera reportes de diferentes características.

Salida : Información especifica de Caja.

Figura 16. Diagrama del módulo de Reportes.


55 0111-

Función del módulo : Menú de Caja

Módulos llamadores : Menú de Principal

Módulos a llamar : Entrega de dinero a Usuarios, A,B,M,C a Recibos de Ingresos,

Reportes, Solicitud de cheque Reposición de fondo fijo

Objetivo : Opciones para Caja

Entrada : Por Menú Principal

Proceso : Operaciones que lleva a cabo Caja

Salida : Entrega de dinero automatizada, impresión de recibos de ingreso e impresión

de solicitud de cheque.

Figura 17. Diagrama del módulo del menú de caja.


56 0111-

Función del módulo : Entregar Dinero a Usuarios

Módulos llamadores : Menú de Caja

Módulos a llamar : Entregar Dinero, Deshacer cambios.

Objetivo : Entrega de dinero a los usuarios.

Entrada : Por Menú de Caja.

Proceso : Control de entrega de dinero automatizado.

Salida : Solicitud Concedida.

Figura 18. Diagrama del módulo de solicitud a caja


57 0111-

Función del módulo : Recibo de ingresos.

Módulos llamadores : Menú de Caja.

Módulos a llamar : Altas, Bajas, Modificaciones, Consultas, Imprimir.

Recibo de Ingresos

Bajas

2

Modificaciones

3

Consultas

4

Formato

5

Altas

1

Objetivo : control y manipulación de recibos de ingresos.


Proceso : Captura de Recibos de ingresos.

Salida : impresión de Recibo de Ingresos.

Figura 19. Diagrama del módulo de recibos de ingreso.


58 0111-

Función del módulo : Reportes.

Módulos llamadores : Menú de Caja.

Módulos a llamar : Solicitudes Realizadas a Caja, Comprobación de gastos a

solicitudes, Usuarios que solicitan mas dinero, Usuarios que no comprueban gastos a

tiempo, Usuarios que no han comprobado gastos, Gastos mas solicitados a Caja.

Objetivo : Generar reportes para gerencia.


Proceso : Generación de diferentes reportes de interés gerencial.

Salida : muestra información específica.

Figura 20. Diagrama del módulo de reportes.


59 0111-

DIAGRAMA UML Se utilizaron los diagramas UML ya que son una herramienta muy eficaz en el

análisis de sistemas. Se uso el diagrama de casos de uso en especial para

reconocer a cada uno de los usuarios que utilizaran el sistema y para determinar la

vista que ellos tendrán con respecto a cada uno de los módulos que conformaran el

sistema.

• casos de uso

Figura 21. Diagrama UML de casos de uso del proceso del departamento de caja.


60 0111-

El diagrama UML de casos de uso dio como resultado que los principales implicados

en el proceso de caja son los usuarios o las personas que van a solicitar el dinero, el

cajero, el gerente y el departamento de contabilidad, cada uno realizando una tarea

específica en el proceso.

2.2 Comprensión y diseño de la base de datos

El almacenamiento de datos es considerado la parte medular de los sistemas de

información. Los objetivos generales son: integridad de datos, disponibilidad de

datos, actualización y recuperación eficiente, almacenamiento de datos eficiente,

recuperación de información para un propósito.

SISINF maneja archivos maestros: estos contienen registros de un grupo de

entidades. Los atributos pueden ser actualizados frecuentemente, pero los registros

mismos son relativamente permanentes. Cada registro contiene, por lo general, una

llave primaria y varias llaves secundarias.

La estructura de los datos es jerárquica, estas estructuras implican que una entidad

no puede tener más de una entidad que la posea. También son llamadas árboles,

debido a que los subordinados conectados con las entidades que los poseen se

asemejan a las ramas de un árbol, pero usualmente son trazados gráficamente de

cabeza.


61 0111-

En esta actividad se determinó que el archivo de base de datos para el sistema de

caja tendría 2 recurrentes, en el recurrente 0 quedarán almacenados todos los datos

de la solicitud de caja y en el recurrente 1, los movimientos de la póliza. La estructura

de la base de datos que se generó fue la que se muestra en la figura 22.

Los parámetros que se siguen para elaborar la definición de la DBD son los

siguientes:

Para dar nombre a un archivo deberá tomarse en cuenta que deben ser 6 caracteres,

el primero es la palabra is, los 2 siguientes caracteres indican en el directorio donde

se encuentra que en este caso será en el de clientes por lo que los caracteres serán

“cl” y los dos últimos indican la función del archivo en este caso será “so” por ser

Figura 22. Diagrama de la estructura jerárquica de la base de datos CLSOCA.


62 0111-

solicitudes a caja. Cuando se comience a almacenar la información se creara un

archivo con extensión “per” que es el archivo donde estará físicamente contenida la

información. Y este tomara el nombre de CLSOCA.

Reglas para crear un archivo en SISINF

ARCHIVO Nombre del archivo.

Número que indica el número de tipos de recurrentes.

(Sin contar el maestro o R0)

Número de grupos de llaves.

Dispositivo (Directorio, Grupo y Cuenta…) del archivo.

Nombre extendido para documentación y CAS. (Opcional)

Número de grupos para CAS. (Opcional)

MARCAR-ABIERTO. (Opcional)


63 0111-

En donde la palabra ARCHIVO debe aparecer tal y como se señala en el

formato, y los campos posteriores se refieren a información del usuario

tomando en cuenta que:

• El nombre del archivo se debe especificar de acuerdo a las reglas

generales para definir archivos dentro del sistema operativo y no

deberá exceder de 6 caracteres.

• El nombre del archivo no puede comenzar con T y a continuación un

número.

• Si el número de tipos de recurrente que se especifica es n, significa

que los tipos de recurrentes son R1, R2,… Rn.

• Si el número de grupos de llaves que se especifica es n, significa que

los grupos de llaves son LL1, LL2, … LLn.

• El número de tipos de recurrentes y el número de grupos de llaves

puede ser cero.

• El dispositivo del archivo (directorio, grupo y cuenta, etc.), se deberá

de dar de acuerdo a las reglas del sistema operativo.


64 0111-

Resultado de la DBD: Archivo: CLSOCA 1 1 ‘CLIENTES’ ‘Solic. de Caja chica’ 2 Índice o llaves: ANO-SCA, NUM-SCA, FEC-SCA

N. Campo

Nombre Tipo Longi-tud

Deci-mal

Descripción

1 NUM-CIA Numero de compañía 2 ANO-SCA Numérico 4 0 Ano de la solicitud a caja 3 NUM-SCA Numérico 8 0 Numero de la solicitud a caja 4 FEC-SCA Fecha 8 - Fecha de la solicitud a caja 5 IMP-SCA Numérico 8 2 Importe de la solicitud a caja 6 DES-SCA Alfanumérico 60 - Descripción de la solicitud a caja 7 DES-SCA1 Alfanumérico 60 - Descripción de la solicitud a caja 1 8 DES-SCA2 Alfanumérico 60 - Descripción de la solicitud a caja 2 9 CGA-SCA Lógico Comprobación de gastos a sol. 10 SOL-SCA Alfanumérico 4 - Usuario que solcito dinero a caja 11 AUT-SCA Alfanumérico 4 - Usuario que autorizó sol. a caja 12 USU-CAJ Alfanumérico 4 Usuario de caja que dio dinero 13 UAL-SCA Alfanumérico 4 - Usuario que capturo altas 14 HAL-SCA Alfanumérico 8 - Hora de alta. 15 UBA-SCA Alfanumérico 4 - Usuario que capturo bajas 16 HBA-SCA Alfanumérico 8 - Hora de baja 17 UMO-SCA Alfanumérico 4 - Usuario que capturo modificaciones 18 HMO-SCA Alfanumérico 8 - Hora de modificación 19 FEC-SCH Fecha Fecha de solicitud de cheque 20 NUM-SCH Numérico Numero de solicitud de cheque 21 NUM-CHE Numérico Numero de cheque 22 CIA-POL Numérico 4 0 Numero de compañía de la póliza 23 NUM-ANO Numérico Numero de ano 24 NUM-MES Numérico Numero de mes 25 CVE-TPO Alfanumérico 2 - Clave de tipo de póliza 26 NUM-POL Numérico Numero de póliza 27 OBS1-SCA Alfanumérico 60 - Observaciones 1 28 OBS2-SCA Alfanumérico 60 - Observaciones 2 29 OBS3-SCA Alfanumérico 60 - Observaciones 3 30 STA-SCA Alfanumérico 2 - Status de la solicitud de caja 31 NUM-PGTO Numérico 4 0 Numero de la partida del gasto 32 NUM-CTA Numérico Numero de cuenta 33 NUM-SCT Numérico Numero de sub-cuenta 34 NUM-SSC Numérico Numero de sub-sub-cuenta 35 NUM-SSS Numérico Numero de sub-sub-sub-cuenta 36 DES-GTOC Alfanumérico 40 - Descripción del gasto a comprobar 37 CVE-GTOC Alfanumérico 2 - Clave del gasto a comprobar 38 IMP-GTOC Numérico 16 2 Importe del gasto a comprobar 39 EAL-GTOC Lógico - - Entrada al almacén 40 OB1-GTOC Alfanumérico 60 - Observaciones 1 41 OB2-GTOC Alfanumérico 60 - Observaciones 2 42 OB3-GTOC Alfanumérico 60 - Observaciones 3 43 UAL-GTOC Alfanumérico 4 - Usuario que capturo altas 44 HAL-GTOC Alfanumérico 8 - Hora de alta. 45 UBA-GTOC Alfanumérico 4 Usuario que capturo bajas 46 HBA-GTOC Alfanumérico 8 Hora de baja 47 UMO-GTOC Alfanumérico 4 Usuario que capturo modificaciones 48 HMO-GTOC Alfanumérico 8 Hora de modificación 49 STA-GTOC Alfanumérico 2 - Status de gastos a comprobar

Figura 23. Archivo de base de datos CLSOCA


65 0111-

Base de datos del sistema de caja. *

* ISSOCA *--------------------------------------------------------------------

* SOLICITUDES DE CAJA CHICA *-------------------------------------------------------------------- ARCHIVO CLSOCA 1 1 'CLIENTES' 'Solicitudes de Caja chica' 2

RECURRENTE 0 R 2000 M 1 1 'Datos generales' * RECURRENTE 1 C 5 P 0 'Movtos. de la poliza' *

*

GRUPO 1 'SOLICITUDES DE CAJA CHICA' GRUPO 2 'GASTOS A COMPROBAR'

*------------------ * Descripcion de la Informacion General

*------------------ IGUAL PUCIAS NUM-CIA R0 LL1 G 1 IGUAL CLCAJA NUM-CAJ R0 LL1 G 1

ANO-SCA 'Anio solicitud de caja' * R0 LL1 N1 0 M7 G 1 NUM-SCA 'Num. solicitud de caja' * R0 LL1 N2 0 M7 G 1

FEC-SCA 'Fecha solicitud a caja' * R0 LL1 F G 1

* COR-SCA 'Compania origen de sol.caja' * R0 S N1 0 M7 G 1

IMP-SCA 'Importe solicitado a caja' * R0 S N2 2 M12 G 1 DES-SCA 'Descripcion de la sol. a caja' * R0 S X 60 M G 1

DES-SCA1 'Descripcion de la sol. a caja 1' * R0 S X 60 M G 1

DES-SCA2 'Descripcion de la sol. a caja 2' * R0 S X 60 M G 1 CGA-SCA 'Con comprobacion de gstos SI/NO' * R0 S S G 1

* SOL-SCA 'Usuario solicito dinero a caja' * R0 S X 4 M G 1

AUT-SCA 'Usuario autorizo sol. a caja' * R0 S X 4 M G 1

* FCO-SCA 'Fecha que se concedio dinero' * R0 S F G 1

USU-CAJ 'Usuario de caja q dio $$$' * R0 S X 4 M G 1 RFF-SCA 'Con Reposicion d Fondo F. SI/NO' * R0 S S G 1

*

UAL-SCA 'Usuario que capturo altas' * R0 S X 4 M G 1 HAL-SCA 'Hra. de alta ' * R0 S X 8 M G 1

UBA-SCA 'Usuario que capturo Bajas' * R0 S X 4 M G 1

HBA-SCA 'Hra. de Baja ' * R0 S X 8 M G 1 UMO-SCA 'Usuario que capturo Modif' * R0 S X 4 M G 1

HMO-SCA 'Hra. de Modif' * R0 S X 8 M G 1 *

* Num. de solicitud de cheque

* IGUAL BASOLI FEC-SCH R0 S G 1

IGUAL BASOLI NUM-SCH R0 S G 1 IGUAL ROPROV NUM-PRO R0 S G 1 IGUAL BACHEQ POB-CHE R0 S G 1

IGUAL BABENE NOM-BEN R0 S G 1 IGUAL PUCECO NUM-CEN R0 S G 1

* * Num. de Cheque ( Reposicion de caja)

*

IGUAL BACHEQ NUM-CHE R0 S G 1 *

* Datos de la poliza en la que sera pagada CIA-POL 'Num. de la cia de la poliza' * R0 S N1 0 M7 G 1 IGUAL COMES NUM-ANO R0 S G 1


66 0111-

IGUAL PUMES NUM-MES R0 S G 1

IGUAL COPOLI FEC-POL R0 S G 1

IGUAL COTIPO CVE-TPO R0 S G 1 IGUAL COPOLI NUM-POL R0 S G 1 * OB1-SCA 'Observciones uno' * R0 S X 60 M G 1

OB2-SCA 'Observciones dos' * R0 S X 60 M G 1

OB3-SCA 'Observciones Tres' * R0 S X 60 M G 1 *

STA-SCA 'Status de la soli. de caja' * R0 S X 2 M G 1 *--------

* Gastos a comprobar

*-------- NUM-PGTO 'Num. de partida del gasto' * R1 S N1 0 M7 G 2 FEC-GTOC 'Fecha de el gasto a comprovar' * R1 S F G 2 *

* Afectacion contable

* IGUAL COCUEN NUM-CTA R1 S G 2

IGUAL COCUEN NUM-SCT R1 S G 2 IGUAL COCUEN NUM-SSC R1 S G 2

IGUAL COCUEN NUM-SSS R1 S G 2

* IGUAL CLGTOC NUM-CGTO R1 S G 2

* DES-GTOC 'Descripcion del Gasto' * R1 S X 40 9 9 M G 2

CVE-GTOC '(D) o (H)' * R1 S X 2 9 9 M G 2

IMP-GTOC 'Importe del gasto' * R1 S N4 2 9 9 M12 G 2 IVA-GTOC 'Iva del gasto' * R1 S N2 2 9 9 M12 G 2

IGUAL CLMVGT CVE-MGTO R1 S G 2 RIN-GTOC 'Recibo de ingreso $ a caja' * R1 S N2 0 M7 G 2

*

PRO-GTOC 'Provedor del gto. a comprb' * R1 S N1 0 M7 G 2 IGUAL CPCXP NUM-FAC R1 S G 2

IGUAL CPCXP FEX-FAC R1 S G 2 * EAL-GTOC 'Entrada Almacen SI/NO' * R1 S S G 2

* OB1-GTOC 'Observaciones Uno' * R1 S X 60 M G 2

OB2-GTOC 'Observaciones Dos' * R1 S X 60 M G 2 OB3-GTOC 'Observaciones Tres' * R1 S X 60 M G 2

*

UAL-GTOC 'Usuario que capturo altas' * R1 S X 4 M G 2 HAL-GTOC 'Hra. de alta ' * R1 S X 8 M G 2

UBA-GTOC 'Usuario que capturo Bajas' * R1 S X 4 M G 2 HBA-GTOC 'Hra. de Baja ' * R1 S X 8 M G 2 UMO-GTOC 'Usuario que capturo Modif' * R1 S X 4 M G 2

HMO-GTOC 'Hra. de Modif' * R1 S X 8 M G 2 *

STA-GTOC 'Status de gtos.a comprobar' * R1 S X 2 M G 2 *

*-------- final de la definicion de archivos de contabilidad --------


67 0111-

2.3 Implementación

Para este sistema se comenzó a codificar el módulo de solicitudes de caja, creando

para ello las áreas respectivas o lo que es lo mismo la interfaz. Creando para ello las

opciones de Altas, Bajas, Modificaciones, Consultas e Impresión de solicitudes.

Este módulo se asigno para el control de las solicitudes de los usuarios, donde se

capturan por primera vez y podrán ser eliminadas o modificadas antes de que el

departamento de caja otorgue el dinero solicitado, utilizando para ello una variable

llamada “status”, que cambiara en cada paso del procedimiento de caja, para que

cuando se halla capturado tomará el valor de “RE” que significa registrada, si por

algún motivo es cancelada tomará el valor de “CA”.

Cuando el departamento de caja otorgue el dinero la variable de control de las

solicitudes llamada “status” cambiara a “CO”, que significa concedido.

Para módulo de comprobaciones de gastos, cabe mencionar que se tuvo un grado

mayor de complejidad debido a que desde aquí se tienen que vincular los gastos a

sus respectivas cuentas contables. En este módulo también se cuenta con la variable

“status”, solo que aquí se tomará en cuenta el valor de la variable que trae la solicitud

por tal motivo se podrá proseguir con la comprobación de gastos si trae el valor de

“CO” por lo que es posible capturar cualquier cantidad de gastos que el usuario haya

generado y cada uno de estos gastos se tomaran como partidas y estas a la vez

también tendrán un variable “status”.


68 0111-

Los diagramas de decisión ayudaron a la codificación, para determinar las acciones

que deberán tomarse en un momento dado si se tiene o no cierta información.

La figura 24 muestra diagrama de decisiones del módulo de solicitudes a caja en el

primer caso si la solicitud existe entonces se verifica si la solicitud esta concedida, si

es así solo se podrán hacer consultas e impresiones. Si no esta concedida podrá

realizar las operaciones, de: bajas, modificaciones, consultas e impresiones. En el

segundo caso si no existe solicitud se puede dar de alta o salir de ese módulo.

STA-SCA DESCRIPCIÓN

RE Registrada (solicitud de caja capturada) CA Cancelada (solicitud dada de baja) CO Concedida (Dinero otorgado al usuario) SO Solicitud (solicitud integrada a una solicitud de cheque) PO Póliza ( información de solicitud pertenece a una póliza)

Figura 24. Diagrama de decisión de solicitudes a caja


69 0111-

Para el módulo de entregar dinero a usuarios existen dos opciones, si la solicitud es

correcta y esta autorizada se entregara el dinero y las segunda opción es si la

solicitud es incorrecta y ya se ha concedido el dinero se pueden deshacer los

cambios.

Para el módulo de comprobación a gastos si aun no se ha generado la póliza y la

solicitud esta concedida se pueden realizar todas las operaciones. Si la solicitud esta

en póliza, mandará un mensaje de error con esa descripción.

Figura 25. Diagrama de decisión de Entregar dinero a usuarios.


70 0111-

Macrodiagrama El macrodiagrama muestra gráficamente en grandes rasgos, el sistema con cada uno

de sus módulos y las bases de datos donde quedará almacenada la información.

Por lo que podemos ver en la figura 27 que una vez teniendo acceso al sistema,

existirá un menú principal el cual esta comunicado con tres menús más, uno de

usuarios, uno de cajero y uno de contabilidad.

El Menú de usuarios tendrá las siguientes opciones: Reportes y Movimientos de

usuario que a su vez se descomponen en solicitudes a Caja y comprobación de

gastos.

Figura 26. Diagrama de decisión de comprobación de gastos.


71 0111-

Al concluir la programación se hicieron 25 pruebas al sistema, en los que se metieron

datos erróneos tales como: teclear una fecha anterior o posterior, no teclear el

importe, colocar otras iniciales en el campo de la persona que autoriza, de los cuales

si se tenían algunos errores, que fueron modificados inmediatamente.

Hasta lograr que a través de la programación se pudieran reconocer esos errores y

lograr que fueran repelidos, logrando que la captura se realice correctamente.

Figura 27. Macrodiagrama del proceso del sistema de caja.


72 0111-

2.4 Implantación y capacitación del sistema de caja

Una vez concluidas las pruebas y modificado el programa, se procedió a la

implantación, para lo cual se realizó una junta informativa con los jefes de cada

departamento, en la cual se les comento los puntos que abarca el sistema y los

beneficios que se obtendrán al automatizar el proceso del departamento de caja y

con la autorización del gerente se empezó a capacitar al personal, generando para

ello una solicitud de caja ficticia y en los casos en que el usuario contaba con datos

reales se hizo el ejercicio correspondiente.

El primer departamento en donde se pudo implantar el sistema fue el de Contabilidad

el cual hizo pruebas sobre las pólizas que es el procedimiento que realizan y en

donde se automatizo mas el trabajo, de los cuales se obtuvieron buenos resultados

Caja fue el siguiente departamento en ser implantado el sistema al mismo tiempo

que se capacitó a la persona encargada de este departamento tomando en cuenta

los comentarios para la mejora del sistema.

Posteriormente se capacitó a cada una de las personas involucradas en el proceso

de caja, tomando como ejercicios casos reales de solicitudes de caja y

comprobaciones de gastos, permitiendo al usuario aclarar sus dudas y anotar cada

uno de los comentarios que hicieron con respecto a la mejora según sus

percepciones.


73 0111-

La implantación tuvo buenos resultados, solo hubo pequeñas dificultades al capacitar

a personal que no tiene ningún tipo de conocimientos de computación, ya que para

ellos fue mas difícil poder realizar cada uno de los pasos del proceso ya automático.

2.5 Elaboración de manuales

Tanto el manual de análisis como el técnico se llevaron a cabo conforme se iba

desarrollando cada una de las actividades del proyecto para tener una coincidencia

absoluta de lo que se plantea en estos manuales y lo que se iba realizando.

Al final se hizo el manual de usuarios que detalla paso a paso el procedimiento para

la captura de la información de Caja de cada usuario, tratando de que sea un manual

de fácil comprensión para cualquier persona ajena a cualquier sistema.

Así se dio por terminado el sistema de caja siguiendo estándares y procedimientos

bien estructurados y justo en el tiempo estimado.


74 0111-

3 RESULTADOS, GRÁFICAS PROGRAMAS Y PANTALLAS DEL SISTEMA

3.1 Explicación de la gráfica del proceso automatiz ado de caja

En la figura 28 se muestra el proceso automatizado de caja dividido en cada uno de

los departamentos, en forma breve explicaremos cada uno de los pasos que se sigue

en con cada uno de los involucrados:

Usuario:

1 Genera mediante el sistema una solicitud a caja por x cantidad.

2 Imprime solicitud con folio.

3 Solicita se le autorice dicha solicitud.

4 Recibe solicitud autorizada.

1Entrega dinero a

Caja

1Recibe dinero inicio

del dia

2Genera Poliza de

Egresos (Encabezado)

3Genera reporte y

solicita cheque x la tarde.

2Entrega dinero a

usuarios solicitantes durante el dia.

3Recibe dinero de

caja

2Autorizar solicitud

1Captura solicitud

4Realiza sus

actividades y genera gastos

correspondientes

6Entrega

documentacion a contabilidad.

5Captura

comprobacion de gastos.

1Recibe documentos

y aclaraciones

3Genera poliza

(Detalle)

2Verifica

documentos y recodifica

ContabilidadUsuarioCajaBan

cos

Admon.

Figura 28. Diagrama del proceso automatizado del proceso de caja.


75 0111-

5 Solicita a caja el importe de la Solicitud.

6 Recibe el dinero del cajero.

7 Realiza actividades y genera sus gastos correspondientes.

8 Captura gastos a comprobar a la solicitud correspondiente.

• Si falto dinero: genera otra solicitud a caja por la diferencia y le

asigna los gastos a comprobar correspondientes.

• Si sobro dinero entrega dinero a caja y recibirá un recibo de ingreso

capturado en la solicitud correspondiente.

9 Entrega documentación a Contabilidad.

Caja:

1 Recibe cheque por $20,000 al inicio del sistema, posteriormente cada día

iniciara con dicho fondo.

2 Verifica físicamente que la solicitud esta autorizada.

3 Busca solicitud en el sistema y corrobora los datos.

4 Marca como concedido status de la solicitud y entrega dinero a usuario.

5 Por la tarde genera reporte de solicitudes concedidas para verificar corte de

caja.

6 Mediante el sistema genera automáticamente solicitud de cheque como

reposición de fondo fijo por x cantidad, producto de la suma de todas las

solicitudes concedidas.

7 Solicita a Bancos; Cheque.

8 Recibe dinero y captura recibo de ingreso haciendo referencia a la solicitud

correspondiente.


76 0111-

Contabilidad

1 Recibe documentos de comprobación de gastos.

2 Verifica que su codificación sea correcta de lo contrario podrá modificarla.

3 Verifica la autenticidad de los gastos a comprobar.

4 Verifica que el importe de los gastos a comprobar coincida con monto

solicitado.

5 Genera detalle de la póliza que fue generada por finanzas con los gatos a

comprobar, capturados por cada usuario. En este momento se tiene la

afectación al sistema de costos.

6 Al cierre de mes aplica Pólizas a balanza.

Bancos:

1 Genera póliza de Egresos (Encabezado/inicio del sistema).

2 Entrega cheque por $20,000 a Caja (inicio del sistema).

3 Entrega cheque por x cantidad a caja.

4 Genera póliza de Egresos (encabezado).

3.2 Código relevante que se generó en la programaci ón del sistema

A continuación se mostrara el código mas relevante que se origino al programar el

sistema, del lado derecho de cada código aparece una explicación breve de lo que

hace cada parte de código.


77 0111-

*--------- * Pedir el numero de caja a q corresponde la solic itud *--------- 1050 LEER TERMINAL EJECUTA 10 NUM-CAJ NUM-CAJG = NUM-CAJ BUSCAR DISCO CLCAJA EJECUTA 1052 PRIN-G 1 NUM-CIA NUM-CAJ LEER DISCO CLCAJA NOM-CAJ STA-CAJ SI STA-CAJ <> 'CA' EJECUTA 1055 ERROR 'Caja se encuentra cancelada' STA-CA J EJECUTA 1050 * 1052 ERROR 'Caja no existe' NUM-CAJ EJECUTA 1050 * 1055 ESCRIBIR TERMINAL NOM-CAJ OPCION DISCO CLCAJA LIBERAR *--------- * Establecer num. de sol. a caja chica y pedir el anio *--------- 1070 ESCRIBIR TERMINAL NUM-SCA * 1080 LEER TERMINAL EJECUTA 10 /R 1050 ANO-SC A *--------- * Establecer la fecha de la solicitud *--------- 1100 LEER TERMINAL EJECUTA 10 /R 1080 FEC-SC A FEC-SCAG = FEC-SCA SI FEC-SCA >= FEC-SIS EJECUTA 1120 ERROR 'fecha del sistema es menor a la fech a de la sol.' EJECUTA 1100 * 1120 CONVERTIR FEC-SCA A ANO-FEC /POS. 1 1 /LONG. 4 /ERROR 1130 SI ANO-SCA = ANO-FEC EJECUTA 1140 ERROR 'NO coincide Anio con anio de la fec ha' EJECUTA 1100 * 1130 ERROR 'No se pudo convertir fec. a anio' EJECUTA 1100 *---------- * Pedir el numero de la compania *---------- 1140 LEER TERMINAL EJECUTA 10 /R 1100 NUM- CIA SI NUM-CIA = 2 O NUM-CIA = 4 O NUM- CIA = 9 $ O NUM-CIA = 14 O NUM-CIA = 1 EJECUT A 1142 ERROR 'Cia. no contabilizada' EJECUTA 1140 * 1142 COR-SCA = NUM-CIA BUSCAR DISCO PUCIAS EJECUTA 1150 PRIN-G 1 NUM-CIA LEER DISCO PUCIAS NOM-CIA STA-CIA SI STA-CIA = 'RE' EJECUTA 1160 ERROR 'ESTA INACTIVA' STA-CIA EJECUTA 1140 * 1150 ERROR 'Escriba el numero de la Compania dire ctamente' EJECUTA 1140 * 1160 ESCRIBIR TERMINAL NOM-CIA OPCION DISCO PUCIAS LIBERAR NUM-CIA = NUM-CIAG MOVER NOM-CIAG A NOM-CIA *--------- * Pedir el importe solicitado a caja * ---------

Cada uno de los datos que se necesitan para llenar la solicitud de

caja son pedidos en

esta parte del código y estos son validados

con las condiciones

necesarias, en caso de meter

un dato erróneo, se enviara un mensaje en

pantalla.

Figura 29. Código del programa del módulo de solicitudes de caja


78 0111-

*-------------------------------------------------- --------------------- * Area para gastos a comprobar *-------------------------------------------------- --------------------- OPCION TERMINAL AREA 40 /RENGLON /POS. 9 1 /LONG. 13 80 $ /MARCO /RELEER IND-LEC /TIEMPO 180 $ /BN NORMAL VI S $ /COLOR AZUL AZUL BLANCO CELESTE AZUL AZU L AMARILLO $ /TECLAS-DE-FUNCION 1 '? AYUDA' 8 'TERMINAR' $ /BLANCOS-CEROS-GLOBAL /ESC-1-GLOBAL / MOD-2-GLOBAL $ / CONFIRMAR-1 $ /CAMPOS $ * 2 3 'Num. de Partida' $ 2 22 NUM-PGTO /LONG. 4 /VAR. /ESC. / LEC-1 /LEC-2 $ /DESP. $ * 2 30 'Fecha Gsto.' $ 2 42 FEC-GTOC /LONG. 8 /VAR. /ESC. / ESC-1 /ESC-2 $ * 2 64 'Saldo' $ 2 70 SPP-GTOC /LONG. 8 /VAR. /ESC. / ESC-1 /ESC-2 $ * 3 3 'Ent. Alm. SI/NO' $ 3 22 EAL-GTOC /LONG. 2 /VAR. /LEC. / ESC-1 /INF. $ /DESP. $ * 4 3 'Num. de Area ?' $ 4 22 NUM-CEN /LONG. 4 /VAR. /LEC. /ESC-1 /INF. $ /EDITAR /DESP. /AYUDA CHECA-CENTRO-COSTO $ 4 28 NOM-CEN /LONG. 38 /VAR. /ESC. /ESC-1 /ESC-2 $ * 5 3 'Num. de Gasto ?' $ 5 22 NUM-CGTO /LONG. 4 /VAR. /LEC. /ESC-1 /INF. $ /DESP. /EDITAR /AYUDA CHECA-N UM-CGTO $ 5 28 DES-CGTO /LONG. 30 /VAR. /ESC. /ESC-1 /ESC-2 $ * 6 3 'Num. Seccion ?' $ 6 18 NUM-SSS /LONG. 8 /VAR. /LEC. / ESC-1 /INF. $ /AYUDA CHECA-SUB-SUB-SUB-CUENTA /EDITAR /DESP. $ 6 28 NOM-SSS /LONG. 38 /VAR. /ESC. / ESC-1 /ESC-2 $ * 7 3 'Concepto' $ 7 18 DES-GTOC /LONG. 60 /VAR. /ESC. / ESC-1 /ESC-2 $ * 8 3 'Num. Prove. ?' $ 8 18 NUM-PRO /LONG. 4 /VAR. /LEC. / ESC-1 $ /AYUDA CHECA-PROVEEDOR-R1 /EDITAR /DESP. $ 8 23 NOM-PRO /LONG. 20 /VAR. /ESC. / ESC-1 /ESC-2 $ * 8 45 'Factura' $ 8 53 NUM-FAC /LONG. 8 /VAR. /LEC. / ESC-1 $ * 8 62 'Fec.F.' $ 8 69 FEX-FAC /LONG. 9 /VAR. /LEC. / ESC-1 /DESP. $ * 9 3 'Importe Gasto' $ 9 18 IMP-GTOC /LONG. 8 /VAR. /LEC. / ESC-1 /INF. $ * 9 28 'I.V.A.' $ 9 35 IVA-GTOC /LONG. 8 /VAR. /LEC. / ESC-1 $ * 9 45 'Total' $ 9 51 TMP-GTOC /LONG. 8 /VAR. /ESC. / ESC-1 /ESC-2 $ *

Esta es el área para pedir los

datos de la comprobación, en cada una de las líneas

donde aparece la palabra

“AYUDA” son llamadas a

subrutinas que despliegan como su

nombre lo indica ayuda

para llenar los campos que se

solicitan.

Figura 30. Código del programa del módulo de comprobación de gastos.


79 0111-

*------- * Verificar saldos pendientes *------- 1000 TOT-GTOC = 0 PEN-SAL = 0 TOT-ING = 0 VAR-TEM = 0 NUM-PGTO = 1 *---------- * Calcular gastos ya capturados *---------- OPCION DISCO CLSOCA INICIO-R1 1010 BUSCAR RECURRENTE CLSOCA 1 EJECUTA 1020 ANT. LEER DISCO CLSOCA NUM-PGTO IMP-GTOC I VA-GTOC STA-GTOC * NUM-PGTO = NUM-PGTO + 1 SI STA-GTOC = 'CA' EJECUTA 1010 TOT-GTOC = TOT-GTOC + IMP-GTOC + IVA-GTO C EJECUTA 1010 * 1020 SI IMP-SCA > TOT-GTOC EJECUTA 1030 ERROR 'Solicitud Saldada' EJECUTA 100 * 1030 PEN-SAL = IMP-SCA - TOT-GTOC IMP-GTOC = PEN-SAL *------- * Pedir gastos a comprobar *------- 1100 OPCION TERMINAL AREA 40 /SALVAR-ANTERIO RES /EMPALMAR $ /DESPLEGAR *------- * Escribir partida *------- ESCRIBIR TERMINAL NUM-PGTO ESCRIBIR TERMINAL PEN-SAL *---------- * pedir el numero de cuenta *---------- 1200 NUM-CTA = 1002 NUM-SCT = 0 NUM-SSC = 0 NUM-SSS = 0 * LEER TERMINAL EJECUTA 1900 NUM-CTA BUSCAR DISCO COCUEN EJECUTA 1260 PRIN-G 1 NUM-CIA NUM-CTA $ NUM-SC T NUM-SSC NUM-SSS LEER DISCO COCUEN NOM-CTA STA-CTA MOVER NOM-CTA A NOM-CTA-R0 * SI STA-CTA = 'RE' EJECUTA 1280 ERROR 'CTA. STA INACTIVA' STA-CTA EJECUTA 1200 * 1260 ERROR 'NUM. CTA. no existe' EJECUTA 1200 * 1280 ESCRIBIR TERMINAL NUM-CTA NOM-CTA-R0 *------ * Pedir num. de subcuenta *------ 1300 NUM-CTA = 1002 NUM-SCT = 0 NUM-SSC = 0 NUM-SSS = 0

Este código forma parte del módulo de la póliza que es la

última operación

que se lleva a cabo en el proceso de caja y que vincula los

gastos a las cuentas

contables que maneja la compañía.

Figura 31. Código del programa del módulo de aplicación de la póliza.


80 0111-

3.3 Pantallas del sistema Las siguientes gráficas son las pantallas del sistema de los principales módulos del sistema de caja.

La figura anterior muestra el menú de usuarios, en los cuales hay dos submenús,

uno el de movimientos de usuario en el cual están los módulos de solicitudes a caja y

comprobación de gastos, y el segundo de reportes los cuales incluyen los reportes

siguientes: solicitudes realizadas a caja, comprobación de gastos a solicitudes a caja,

usuarios que solicitan mas dinero, usuarios que no comprueban gastos a tiempo y

gastos mas solicitados por caja. Podemos seleccionar cualquiera de esto tecleando

enter en la opción deseada. Si queremos terminar la sesión simplemente tecleamos

F8.

Figura 32. Menú principal del sistema de Caja


81 0111-

La figura 33 muestra el módulo de solicitudes a caja, el cual tiene 4 opciones las

cuales son: altas, bajas, modificaciones, consultas, imprimir y salir que es una opción

exclusivamente si se trabaja desde una Terminal.

Los campos que se deberán llenar, son el numero de compañía, numero de caja,

año, fecha, compañía origen, importe solicitado, descripción, elegir si es con gastos a

comprobar, si es con reposición de fondo fijo, iniciales de la persona que autoriza,

iniciales de la persona encargada de caja y observaciones, el campo de numero de

solicitud se llena automáticamente al guardar la información en la base de datos, al

igual que el campo del status.

Figura 33. Módulo de solicitudes


82 0111-

La figura 34 muestra el módulo de comprobación de gastos, con las opciones de:

altas, bajas, modificaciones, consultas, imprimir y salir. Del cual debemos

proporcionar los datos de la solicitud a la que se le tenga que realizar la

comprobación de gastos, estos datos son: numero de compañía, numero de caja

numero de solicitud y año de la solicitud, con esto se mostraran los datos

proporcionados en el módulo de solicitudes, al teclear enter se pedirán los siguientes

datos: si el gasto tiene entrada a almacén, numero de área, numero de gasto,

numero de sección, numero de proveedor, numero de factura, fecha de factura,

importe de gasto, iva y observaciones. Los campos de número de partida, fecha de

gasto, saldo, concepto y total de la factura se llenan automáticamente.

Figura 34. Módulo de comprobación de gastos


83 0111-

La figura 35 muestra el reporte de solicitudes a caja, en vista previa o por teminal, el

cual muestra la fecha de solicitud, iniciales de usuario, nombre de usuario, es de

reposición de fondo fijo, numero de folio, importe, status y total acumulado, esto es

una ayuda al usuario por si no recuerda el numero de solicitud, aquí, puede buscarlo

fácil y rápido, si se elige la opción por impresora se convierte en un reporte formal

para el departamento de caja y que es a la ves entregado con la solicitud de cheque

ya que es el comprobante del importe solicitado al final del día.

Figura 35. Reporte de solicitudes de caja


84 0111-

CONCLUSIONES Y RECOMENDACIONES

Al final del tiempo estimado se logró cumplir con el objetivo de automatizar los

procesos que lleva a cabo el departamento de Caja, logrando obtener información en

tiempo y forma, lo cual es indispensable para la empresa.

El proyecto otorga bases para el desarrollo de otros proyectos y marca un logro en el

desempeño que se tuvo para la realización del mismo.

Cabe mencionar la importancia y relevancia del proyecto en función de los beneficios

obtenidos:

• El proceso dejó de ser un proceso manual y se convirtió en automático, donde

la información que se obtiene es la mas fidedigna y concreta.

• El usuario puede llevar a cabo el seguimiento de sus solicitudes, hasta que

llegan al departamento de contabilidad.

• Se pueden obtener reportes de los movimientos del departamento en

cualquier y de cualquier fecha del año.

• Cada gasto es enviado a sus respectivas cuentas contables.

Se debe mencionar que al sistema se le hicieron varias pruebas antes y durante la

implantación que permitieron conocer mejor el desempeño, logrando así un sistema

muy eficiente y funcional.


85 0111-

Podemos asegurar su buen funcionamiento debido a que en estos momentos el

sistema trabaja de forma correcta y se ha logrado cumplir con los objetivos

propuestos al inicio.

Por último es recomendable que el departamento de caja y el departamento de

sistemas trabajen en conjunto para cualquier cambio o mejora que se le pudiera

hacer al proyecto de automatización realizado, esto con el único fin de lograr un

sistema que cumpla con las necesidades y expectativas de los usuarios involucrados

en el proceso del departamento de caja.


86 0111-

REFERENCIAS BIBLIOGRÁFICAS LIBROS:

1. Kratos S.A. de C.V., 2005, Manual de Referencia de SISINF.

Segunda edicion.

Kratos S.A. de C.V.

2. Kenneth E. Kendall y Julie E. Kendall, 2000, Análisis y diseño de sistemas.

Tercera Edición, 2000

Pearson Educación

3. David Medinets, 2001, Herramientas de programación para el shell de UNIX.

Primera Edición

Mc Graw-Hill

INTERNET:

� Análisis de sistemas

http://www.gestiopolis.com/recursos/documentos/fulldocs/fin/sispol.htm

Responsable: Carlos López

Periodo de consulta: Agosto 2006


87 0111-

� Términos contables

http://www.ordenjuridico.gob.mx/Estatal/COLIMA/Manuales

Responsable: gobierno de Colima Méx.

Periodo de consulta: septiembre de 2006

� KRATOS

http://www.kratosnet.com/

Responsable: Kratos S.A. de C.V.

Periodo de consulta: agosto-diciembre de 2006

� PATSA

http://www.patsa.com.mx

Responsable: PATSA Servicios S.A. de C.V.

Periodo de consulta: agosto-diciembre de 2006

� Enciclopedia en línea

http://es.wikipedia.org

Responsable: Wikimedia Foundation, Inc.

Periodo de consulta agosto-diciembre de 2006

� Herramientas de HP

http://www.wrq.com/

Responsable: WRQ Corporation

Periodo de consulta: agosto de 2006

Documents

tesis