UNIVERSIDAD NACIONAL ABIERTA VICERRECTORADO ACADÉMICO ÁREA DE INGENIERÍA COORDINACIÓN DE INGENIERÍA DE SISTEMAS DOCUMENTACIÓN DEL SISTEMA DE CONCILIACIÓN GENERAL DE LA EMPRESA CONSORCIO OLEAGINOSO PORTUGUESA S.A. (COPOSA) Jean Sánchez Araure, Junio 2007 UNIVERSIDAD NACIONAL ABIERTA VICERRECTORADO ACADÉMICO ÁREA DE INGENIERÍA COORDINACIÓN DE INGENIERÍA DE SISTEMAS DOCUMENTACIÓN DEL SISTEMA DE CONCILIACIÓN GENERAL DE LA EMPRESA CONSORCIO OLEAGINOSO PORTUGUESA S.A. (COPOSA) Autor: Jean Sánchez Tutor Académico: Prof. Saibel Ramos, C.I: 9.837.306 Tutor Empresarial: Ing. Roberto Olmos, C.I: 12.264.598 Araure, Centro Local Portuguesa Junio, 2007 Índice Lista de Cuadros………………………………………………………………….…. iv Introducción………………………………………………………………................. vi Capitulo I: Definiciones y Conceptos Básicos………………………………….…. 1 Capitulo II: Antecedentes Del Problema…………………………………….……. 19 Descripción de la Empresa………………………………………….... 22 Capitulo III: El Problema………………………………………………………….... 26 Propuesta de Solución……………………………………………...… 27 Capitulo IV: Descripción de la Solución ………………………………………..…. 46 Pruebas de la Solución …………………………………………….... 146 Conclusiones y Recomendaciones……………..………………………………….. 147 Referencias………………………………………………………………………… 149 Apéndice ………………………………………………………………………..… 150 Manual de Usuario Introducción ………………………………………. 151 Anexo ……………………………………………………………………………... 157 CDROM: Contenido de los archivos fuentes y ejecutables de los manuales de usuario y manuales de programador creados en Help & Manual. Contenido de archivos fuentes de artefactos de UML creados en ArgoUml. Lista de Cuadros Organigrama Resumido de la Empresa ……………………………………………. 25 Proceso Unificado …………………………………………………………..……… 30 Modelo de Casos de Uso …………………………………………………………... 31 Modelo de Análisis ……………………………………………………………….... 32 Modelo de Diseño ………………………………………………………………..… 33 Modelo de Implementación ………………………………………………………... 33 Modelo de Prueba ………………………………………………………………….. 34 Iteraciones Usadas para la Documentación del Sistema de Conciliación …………. 35 Caso de Uso Identificar ………………………………………………………….… 48 Caso de Uso Conciliar ……………………………………………………………... 55 Caso de Uso Automático por Referencia ………………………………………….. 58 Caso de Uso Automático por Monto …………………………………………….… 60 Caso de Uso Movimiento Compartido en Banco ………………………………..… 63 Caso de Uso Movimiento Compartido en Libro ………………………………….... 65 Caso de Uso Cheques Anulados ………………………………………………...…. 68 Caso de Uso Interna en Banco ……………………………………………………... 71 Caso de Uso Interna en Libro …………………………………………………...…. 74 Caso de Uso Manual ……………………………………………………………….. 76 Caso de Uso Consultar Movimiento …………………………………………….…. 78 Caso de Uso Congelar Movimiento ………………………………………...……… 80 Caso de Uso Movimiento por Reclasificar ……………………………………….... 82 Caso de Uso Eliminar Movimiento ……………………………………………..…. 84 Caso de Uso Resultado …………………………………………………….………. 87 Caso de Uso Desaplicar ………………………………………………………….… 91 Caso de Uso Conciliar Cuenta ……………………………………………...……… 93 Caso de Uso Conciliación Movimiento ……………………………………………. 94 Caso de Uso Importar …………………………………………………………...…. 97 Caso de Uso Datos Banco ……………………………………………………..….. 102 Caso de Uso Libro AP …………………………………………………...……….. 108 Caso de Uso Libro AR ……………………………………..………………..……. 110 Caso de Uso Libro GL ………………………………..……………………..……. 112 Caso de Uso Movimiento No Aplicado ……………………………………...…… 114 Caso de Uso Desde Archivo ……………………………………….……………... 116 Caso de Uso Consultar ……………………………………………………………. 118 Caso de Uso Referencia en Libro …………………………………………...……. 120 Caso de Uso Estado de Cuenta …………………………………………………… 121 Caso de Uso Libro AP ……………………………………………………………. 123 Caso de Uso Libro AR ……………………………………………………….…… 124 Caso de Uso Libro GL ……………………………………………………………. 126 Caso de Uso Registrar …………………………………………………………….. 128 Caso de Uso Cuenta Bancaria …………………………………………………….. 130 Caso de Uso Movimiento en Banco …………………………………….……...… 131 Caso de Uso Movimiento en Libro …………………………………………..….... 133 Caso de Uso Configurar Tasa de Cambio ………………………………………… 135 Caso de Uso Reportes …………………………………………………………….. 137 Diagrama de Caso de Uso ………………………………………………...………. 138 Diagrama de Secuencia Identificar …………………………………………..…… 139 Diagrama de Secuencia Conciliar ……………………………………………….... 140 Diagrama de Secuencia Desaplicar …………………………………………..…… 141 Diagrama de Secuencia Importar ………………………………………….……… 142 Diagrama de Secuencia Consultar ……………………………………………..…. 143 Diagrama de Secuencia Registrar ……………………………………………..….. 144 Diagrama de Clases ……………………………………………………………..... 145 Introducción Los sistemas de información desde su advenimiento han necesitado maneras de representarse para realizar el análisis, diseño, codificación, implementación y prueba, además de alguna metodología para llegar a su feliz término. Los nacientes sistemas de información se enfrentaron con los problemas de complejidad que se aplican a los sistemas actuales, tal vez, la mayor diferencia de los sistemas de información actuales con sus antecesores es la ubicuidad, se encuentran en todas las organizaciones y en cada uno de los niveles, y la inmediatez que a través de la tecnología de la comunicación e información se ha desarrollado de una manera vertiginosa. Debido a la complejidad y al nacimiento de la Ingeniería del Software, comenzó un estudio sistemático de los sistemas de información, se realizaron diversos ensayos con diferentes metodologías y formas de representarlos; es en la década de los noventa cuando comienza el auge de la llamada Programación Orientada a Objetos, y es al final del año 1999, que diversos autores de diferentes metodologías logran reunirse y ponerse de acuerdo del estándar que debe usarse para el desarrollo de los sistemas de información; son tres personas las que reúnen para ese entonces las metodologías más avanzadas para la época, y los tres decidieron unirse para unificar sus metodologías, de allí nació el Proceso Unificado de Desarrollo de Software, y al mismo tiempo, una notación que fuese capaz de soportar la nueva metodología, gracias a esto el mundo conoció el UML; ya existían entonces una metodología conveniente para describir los nuevos sistemas de información y, además el modelado visual que soportaba la nueva notación. La empresa COPOSA y muy especialmente, la Gerencia de Informática debe adecuarse a los nuevos paradigmas de programación, la metodología y notación utilizada como estándares universales, y que aprovechan todas las ventajas de la tecnología orientada a objetos; como el Proceso Unificado de Desarrollo de Software predica en sus fases, es necesario una adecuada documentación de todos los artefactos usados en los diferentes flujos de trabajo. La necesidad de estandarizar la documentación de los sistemas de información desarrollados por la Gerencia de Informática de COPOSA, se hace cada vez mayor, por la urgencia de migrar hacia la nueva tecnología de programación predominante en la actualidad. Capítulo I Definiciones y Conceptos Básicos En este capitulo se introducen los términos técnicos y conceptos básicos utilizados para una mejor comprensión de la solución de la Documentación del Sistema de Conciliación General. Abstracción: es la operación de concentrar las cualidades esenciales o generales de cosas semejantes, donde las características esenciales pueden resultar ser cualquier cosa, por tanto la abstracción delimita el contorno relativo al analista o programador. Actividad: es la unidad tangible de trabajo efectuado por un trabajador en el flujo de trabajo, por tanto implica: Una responsabilidad bien limitada del trabajador; produce un resultado a partir de un conjunto de artefactos, y se refiere a la asignación de tareas a los individuos en plan de proyecto. Activo: todo aquello que una persona o empresa posee o le deben; los activos, por lo tanto, forman parte del patrimonio. Los activos incluyen activos reales y tangibles, como terrenos, edificaciones, plantas, máquinas, mobiliario y otros bienes, y activos financieros: dinero, valores, créditos y cuentas por cobrar, etc. Actor: es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Agregación: es una propiedad de la asociación que representa una relación todo-parte y que abarca a las clases u objetos. Análisis: se centra en la investigación del problema, no en la manera de definir la solución, es decir, describir el problema y las necesidades o requerimientos: En que consiste el conflicto y que debe hacerse. 1 Análisis Orientado a Objetos: se procura identificar y describir los objetos o conceptos dentro del dominio del problema. Arquitectura del Sistema: especifica la organización de las aplicaciones o sistema de software para la selección optima de los elementos estructurales y las interfaces entre ellos, además del comportamiento y la colaboración entre sus elementos, es decir, los elementos e interfaces, colaboración y composición; también considera las restricciones y compromisos de uso, funcionalidad, funcionamiento, flexibilidad al cambio, reutilización, comprensión, economía y tecnología, así como aspectos estéticos. Por tanto, la arquitectura es el conjunto organizado de elementos. Se utiliza para especificar las decisiones estratégicas acerca de la estructura y funcionalidad del sistema, las colaboraciones entre sus distintos elementos y su despliegue físico para cumplir unas responsabilidades bien definidas. Artefacto: es cualquier tipo de información creada, producida, cambiada o utilizada por trabajadores en los cinco workflow o flujos de trabajo, entendiéndose estos como: Requisitos, análisis, diseño, implementación y prueba. Además puede representar un área de responsabilidad, por tanto un artefacto puede ser un modelo, un elemento del modelo, o un documento. Asiento Contable: son cada una de las anotaciones que se realizan en la contabilidad de las instituciones con la finalidad de registrar los movimientos en las cuentas respectivas. Asociación: es la descripción del conjunto formado por las relaciones de los enlaces o vínculos de las clases u objetos. Atributo: son las características o propiedades que poseen las clases u objetos. Balance: elemento contable fundamental que consiste en una cuenta donde se reflejan las transacciones hechas por una empresa a lo largo de un período dado y la posición económica de la misma. Banco: establecimiento que se ocupa de la intermediación financiera. Los bancos son entidades mercantiles que se ocupan de comerciar con el dinero, considerado como 2 mercancía, y por ello reciben y custodian depósitos y otorgan préstamos. La organización y las funciones de la banca moderna dependen del crédito y éste, a su vez, es factible en gran parte gracias al desarrollo del sistema bancario. Casos de Prueba: es el artefacto que indica la forma en que se deberá probarse el sistema, incluyendo la entrada o resultado con las que han de probar y las condiciones bajo las cuales han de probarse. Casos de Uso: es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. Por tanto, es un documento narrativo que describe la secuencia de eventos de un actor (un agente externo) que usa un sistema para completar un proceso. Es una historia o una forma particular de usar un sistema. Los casos de uso no son exactamente requisitos ni especificaciones funcionales, pero ilustran e implican requisitos en las historias que cuentan. Casos de Uso del Negocio: se describe mediante diagramas de Casos de Uso que es llevado por un conjunto de trabajadores que utilizan un grupo de entidades del negocio y de unidades de trabajo. Casos Reales de Uso: es el caso de uso que describe el proceso a partir del diseño actual del sistema de información, explica las entradas y salidas, así como su implementación global, y la interfaz para el usuario. Ciclo de Vida Clásico del Sistema: también llamado Modelo en Cascada, es un enfoque en el que se ordena rigurosamente las fases o etapas para la construcción de las aplicaciones o software, de forma tal, que el inicio de cada etapa debe esperar la finalización de la inmediatamente anterior. Las etapas que normalmente se efectúan de inicio a fin son: Análisis de requisitos, Diseño del Sistema, Diseño del Programa, 3 Codificación, Pruebas, Implantación y Mantenimiento. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Clase: es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y significado, es decir, el mecanismo de software con que se definen e implementan los atributos y métodos de un tipo particular de objeto. Clase de Control: es una clase que representa coordinación, secuencia, transacciones y control, de los objetos y se usan para encapsular el control de un caso de uso. Clase de Diseño: es una clase que representa la abstracción o construcción similar de clase que deberá usarse en un componente durante la fase de implementación. Clase de Entidad: es una clase que se utiliza para modelar información que posee una vida larga y que muchas veces es persistente, a menudo modelan la información y el comportamiento asociado de algún fenómeno o concepto. Clase de Interfaz: es una clase que se utiliza para modelar la interacción entre el sistema y los actores, esta interacción implica recibir información y peticiones a los usuarios y sistemas externos. Cliente: es la persona, organización o grupo de personas que encomienda la construcción del sistema de información. Componentes: que pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema. Una característica básica de un componente es que debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles. Componente de Prueba: es el componente que automatiza uno o varios procedimientos de prueba o parte de ellos. 4 Conciliación Bancaria: es la tarea de cotejar las anotaciones que figuran en el extracto bancario con el libro banco a los efectos de determinar el origen de las diferencias. La conciliación consiste en verificar la igualdad entre las anotaciones contables y las constancias que surgen de los resúmenes bancarios, efectuando el cotejo mediante un básico ejercicio de control, basado en la oposición de intereses entre la empresa y el banco. Conciliación de Cheques Anulados: se eliminan de la conciliación aquellos cheques que hayan sido anulados en el mes al que se está conciliando. Conciliación de Diferencia en Monto: el monto del movimiento de dinero registrado en Banco no es igual al monto de dinero registrado en Libro, en este caso la diferencia resultante será registrada al mes siguiente en el Auxiliar GL, para realizar el ajuste de la misma. Conciliación de Movimientos Compartidos en Banco: ocurre cuando se necesita cruzar un movimiento de dinero registrado en Libro contra varios movimientos de dinero registrados en Banco. Conciliación de Movimientos Compartidos en Libro: ocurre cuando se necesita cruzar un movimiento de dinero registrado en Banco contra varios movimientos de dinero registrados en Libro. Conciliación Exacta: el monto del movimiento de dinero registrado es igual en Banco y en Libro. Conciliación Interna en Banco: se cruza un movimiento de dinero registrado en Banco contra otro movimiento de dinero en Banco, siempre y cuando uno sea la contra partida del otro. Este criterio se utiliza en el caso de un movimiento en Banco que no tiene su correspondiente en Libro. 5 Conciliación Interna en Libro: ocurre cuando se necesita cruzar un movimiento de dinero registrado en Libro contra otro movimiento de dinero registrado en Libro, siempre y cuando uno sea la contra partida del otro. Este criterio se utiliza en el caso de un movimiento en Libro que no tiene su correspondiente en Banco. Conciliación por Monto: es cuando se concilian los movimientos de dinero registrados que tienen el mismo monto tanto en Banco como en Libro, a pesar de no tener la misma referencia. Conciliación por Referencia: se cruza un movimiento en Libro contra uno de Banco, cuyas referencias son iguales, se toma en cuenta el tipo de movimiento. Concurrencia: es la propiedad que distingue un objeto que está activo de uno que no lo está. Contrato: es un artefacto que define las responsabilidades, precondiciones y poscondiciones que se aplican al uso de un método. Cheque: es un documento legal que contiene: a) Orden incondicional de pago, b) Dada por una persona (Librador), c) A una Institución de crédito (Librado), d) De pagar a la vista, e) A un tercero o al portador (Beneficiario) y f) Una cantidad de dinero. Composición: es la identificación de una clase en que cada instancia está constituida por otras clases u objetos. Copyleft: permite describir un grupo de derechos aplicados a una diversidad de trabajos tales como programas informáticos o software, arte, cultura y ciencia, es decir prácticamente casi cualquier tipo de producción creativa. Sus partidarios la proponen como alternativa a las restricciones de derechos para hacer y redistribuir copias de una obra determinada de las normas planteadas en los derechos de autor o propiedad intelectual. Se pretende garantizar así una mayor libertad, cada persona receptora de una copia o una versión derivada de un trabajo pueda, a su vez usar, 6 modificar y redistribuir tanto el propio trabajo como las versiones derivadas del mismo. Derecho de Autor: es un conjunto de normas y principios que regulan los derechos morales y patrimoniales que la ley concede a los autores, por el solo hecho de la creación de una obra literaria, artística o científica, tanto publicada o que todavía no se haya publicado. Derivación: es el proceso que consiste en definir una nueva clase por referencia a otra existente y agregar luego atributos y métodos, la clase existente es la superclase; la nueva clase se denomina subclase o clase derivada. Diagrama de Casos de Uso: muestran la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Diagrama de Clases: es el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones. Diagrama de Colaboración: muestran una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia. Diagrama de Estados: muestran la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un 7 estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino. Diagrama de Secuencia: muestran una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren. Diseño: pone de relieve la solución, como el sistema cumple con los requerimientos, es decir, contar con las descripciones detalladas y de alto nivel de la solución lógica y saber como satisface los requerimientos y las restricciones. Diseño Orientado a Objetos: se procura definir los objetos lógicos del software que finalmente serán implementados en un lenguaje de programación orientado a objetos. Dominio: es el límite formal que define determinada área o tema interés. Encapsulamiento: es el mecanismo de la Programación Orientada a Objetos con la que se ocultan los datos, la estructura interna y los detalles de la implementación de los objetos, la interacción con el objeto se realiza a través de una interfaz pública de operaciones. Entidad del Negocio: representa algo que los trabajadores toman, inspeccionan, manipulan, producen o utilizan en un caso de uso de negocios. Especialización: es la actividad que consiste en identificar los aspectos propios de cada artefacto y definir las relaciones generales que pudiesen existir con otra clase. Estado: representación de una acción que es atómica, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida. 8 Fallo: es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Fase: es el periodo de tiempo necesario entre dos hitos principales de un proceso de desarrollo. Fiabilidad: es la capacidad de un sistema de información de comportarse correctamente sobre su entorno de ejecución real. Usualmente se mide en función de la disponibilidad, exactitud, tiempo medios de fallos, defectos por cada mil (1000) líneas de código fuente o defectos de las clases del sistema de información, Generalización: es la actividad consistente en identificar aspectos comunes entre conceptos y en definir las relaciones entre el supertipo (concepto general) y el subtipo (concepto especializado). GPL: cuyas siglas significan General Public License o Licencia Pública General es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios. Hechos Contables: son aquellos sucesos puntuales que hacen variar las cuentas de la empresa. Un hecho contable puede ser, por ejemplo, una venta, un pago, una compra, una devolución, etc. Los hechos contables se reflejan en la empresa en forma de asientos. Herencia: es la característica de la Programación Orientada a Objetos con la cual se especializan los objetos a partir de superclases más generales, la subclase adquiere automáticamente las definiciones de los atributos y clases hechas a partir de las superclases. Hito Principal: es el punto en el tiempo en que se deben tomar importantes decisiones acerca del sistema de información; cada fase acaba con un hito principal en el cual los trabajadores deben tomar la decisión crucial si continuar o no con el 9 proyecto, y decidir sobre la planificación, presupuesto y requisitos del sistema de información. Los hitos principales son puntos de sincronización en los cuales convergen los objetivos ya definidos, se completan los artefactos, y donde se toma la decisión de abandonar o proseguir a la siguiente fase. Incrementar: se comienza la construcción de los artefactos que resuelve sólo una pequeña parte de lo que trata de lograr, luego se consideran los aspectos posteriores del problema y se añaden las nuevas piezas resultantes al artefacto existente, por tanto, incrementar significa aumentar. Ingeniería de Software: es la rama de la ingeniería que se encarga de crear y mantener las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, como las disciplinas tradicionales de ingeniería, tiene que ver con el costo y la confiabilidad. Algunas aplicaciones de software contienen millones de líneas de código que se espera que se desempeñen bien en condiciones siempre cambiantes. Ingeniería Directa: es la transformación del modelo de casos de uso en el modelo de análisis, posteriormente del modelo de análisis en el modelo de diseño, por último la transformación del modelo de diseño en el modelo de implementación, además de aplicarles el modelo de pruebas, es decir, la construcción y prueba de un sistema de información en forma natural. Ingeniería Inversa: consiste en el análisis del código fuente del sistema de información y desde este punto, intentar recrear los artefactos de diseño, análisis e incluso los requisitos del sistema. Interfaz: es una especificación para las operaciones externas visibles de una clase, componente, o otra entidad (incluyendo unidades globales como los paquetes), pero siempre sin especificar la estructura interna. Cada interfaz especifica a menudo sólo una parte limitada del comportamiento de una clase real. Una interfaz no tiene implementación. Una Interfaz es formalmente equivalente a una clase abstracta sin atributos y sin métodos, con sólo operaciones abstractas. 10 Interfaz de Usuario: es la interfaz a través de la cual el usuario puede interactuar con el sistema de información. Iterar: son versiones sucesivas de un artefacto, esto quiere decir que se produce una versión del artefacto, luego se revisa y se produce la segunda versión y así sucesivamente, hasta que se construya una versión del artefacto satisfactoria; por tanto, iterar significa repetir. Letra de Cambio: es un documento literal que contiene una orden incondicional de pago dada por una persona llamada girado, para que pague a la orden de un tercero llamado beneficiario, cierta cantidad de dinero en la fecha y lugar señalados en el documento. Ley de Miller: explica que los seres humanos son capaces de concentrarse en tan sólo siete unidades de información al mismo tiempo. Libro: es el documento legal donde se registran todos los hechos y operaciones contables. Este registro se realiza mediante los asientos contables. Libro AP: es el libro donde se asientan las cuentas por pagar. Libro AR: es el libro donde se asientan las cuentas por cobrar. Libro GL: es el libro donde se efectúa el asiento por el sistema de la partida doble. Licencia BSD: es la licencia de software otorgada principalmente para los sistemas BSD (Berkeley Software Distribution). Pertenece al grupo de licencias de software Libre. Esta licencia tiene menos restricciones en comparación con otras como la GPL estando muy cercana al dominio público. La licencia BSD al contrario que la GPL permite el uso del código fuente en software no libre. Es muy similar en efectos a la licencia MIT. Licencia MIT: es una de las licencias de software que ha empleado el MIT (Massachusetts Institute of Technology). El texto de la licencia no posee derechos de autor, lo que permite su modificación. No obstante esto puede no ser recomendable a no ser que se indique que es una modificación, y no la versión original. 11 Licencia de Software: es la autorización o permiso concedido por el titular del derecho de autor, en cualquier forma contractual, al usuario de un programa informático, para utilizar éste en una forma determinada y de conformidad con unas condiciones convenidas. La licencia, que puede ser gratuita u onerosa, precisa los derechos (de uso, modificación o redistribución) concedidos a la persona autorizada y sus límites. Además, puede señalar el plazo de duración, el territorio de aplicación y todas las demás cláusulas que el titular del derecho de autor establezca. Mantenimiento: es el proceso mediante el cual un artefacto del sistema de información se modifica a causa de un problema o debido a la necesidad de mejoramiento o adaptación. Mantenimiento Adaptativo: es cuando hay un cambio el entorno en el cual opera el sistema de información, y por tanto debe modificarse algún artefacto. Mantenimiento Correctivo: es la reparación de las fallas del sistema de información, existiendo la necesidad de modificar algún artefacto. Mantenimiento Perfectivo: es cuando el cliente desea ampliar las funciones del sistema de información, y por tanto corresponde modificar algún artefacto. Mensaje: es el mecanismo en virtud del cual los objetos se comunican entre si; generalmente una respuesta para ejecutar un método. Método: es un proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema de software en desarrollo, utilizando alguna notación bien definida. En el UML es la implementación o algoritmo especifico de las operaciones que puede realizar una clase, es decir, el procedimiento de software que puede ejecutarse en respuesta a un mensaje. Metodología: es una colección de métodos aplicados a lo largo del ciclo de vida del desarrollo de software y unificados por alguna aproximación general o filosófica. La mayor parte de las metodologías puede catalogarse en uno de los grupos siguientes: a) Diseño estructurado descendente, b) Diseño dirigido por datos y c) Diseño orientado a objetos. 12 Modelado Visual: es la visualización de artefactos en esquemas o diagramas estandarizados. Modelo: es la abstracción de un sistema, es decir, la descripción de las características estática, dinámica o ambas de un sistema. Modelo de Análisis: es la jerarquía más abstracta del análisis que contiene los paquetes, clases de interfaz, clase de entidad y clase de control del análisis, además de los casos de uso requeridos para representar el análisis. Modelo de Casos de Uso: es un modelo del sistema que contiene actores, casos de uso y sus relaciones, esto permite que se llegue a un acuerdo sin ambigüedades posibles sobre las condiciones o posibilidades, que debe cumplir el sistema entre cliente y desarrolladores. Modelo de Diseño: es la jerarquía más abstracta del diseño que contiene las clases del diseño e interfaz, además de los casos de uso requeridos para representar el diseño. Modelo de Dominio: es la que captura los tipos más importantes de objetos o clases en el contexto del sistema. En otras palabras, debe contribuir a una comprensión del problema que se supone que el sistema resuelve en relación a su contexto. Modelo de Implementación: es la jerarquía más abstracta de la implementación que contiene los componentes e interfaces. Modelo de Negocio: permite comprender los procesos de negocios de la organización, es el resultado de la comprensión del funcionamiento del modelo de dominio. Modelo de Prueba: es la jerarquía más abstracta de las pruebas que contiene los casos de pruebas, los procedimientos de pruebas y los componentes de pruebas. Modelos Prescriptivos de Proceso: es el conjunto de actividades, acciones, tareas, fundamentos y productos requeridos para desarrollar programas o software, es decir, asignar cada actividad del marco de trabajo con un conjunto de acciones de la 13 ingeniería del software, estas acciones en forma genérica son: comunicación, planeación, modelado, construcción y desarrollo. Multiplicidad: es el número de objetos que se permiten participar en una asociación. Nodo: es un elemento físico que existe en tiempo de ejecución y que representa un recurso computacional, que al menos debe poseer memoria y capacidad de almacenamiento. Notación: es un conjunto de diagramas normalizados que posibilita al analista o desarrollador el describir el comportamiento del sistema (análisis) y los detalles de una arquitectura (diseño) de forma no ambigua. La acción de dibujar un diagrama no constituye ni análisis ni diseño. Una notación no es un fin por si misma. El hecho de que una notación sea detallada no significa que todos sus aspectos deban ser utilizados en todas las ocasiones. Una notación no es más que un vehículo para capturar los razonamientos acerca del comportamiento y la arquitectura de un sistema. Las notaciones deben ser lo más independientes posibles de los lenguajes de programación, sin embargo facilita el proceso de desarrollo que exista una equivalencia entre la notación y los lenguajes de programación. Objeto: es la manifestación concreta de una abstracción, una entidad sobre la cual se pueden aplicar un conjunto de operaciones y que tienen un estado que almacena los efectos de las operaciones. Todo lo que un objeto “conoce” está representado en sus atributos (variables y estado actual), y todo lo que puede “realizar” está definido en sus métodos (comportamiento), y en sus “interacciones” con otros objetos a través del intercambio de mensajes (dinámica del ciclo de vida). Open Source: es el término con el que se conoce al software distribuido y desarrollado libremente. Fue utilizado por primera vez en 1998 por algunos usuarios de la comunidad del software libre, tratando de usarlo como reemplazo al ambiguo nombre original en inglés del software libre (free software). Pagaré: es un documento literal o título de valor o instrumento financiero, documento escrito mediante el cual una persona (Emisor) Se compromete a pagar a 14 otra persona (El Beneficiario) una determinada cantidad de dinero en una fecha acordada. Los pagares pueden ser al portador o endosables, es decir, que se pueden transmitir de un tercero. Los pagares pueden emitirlos los individuos particulares de empresas o estados. Paquete de Análisis: es un medio de organizar los artefactos del modelo de análisis en piezas manejables, por tanto, puede constar de clases de análisis, casos de usos y otros paquetes de análisis (recursivamente). 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. Los paradigmas más conocidos son: Paradigma de Programación Imperativa, Paradigma de Programación Funcional, Paradigma de Programación Lógica, Paradigma de Programación Estructurada, Paradigma de Programación dirigida por Eventos, Paradigma de Programación por Capas, Paradigma de Programación por Restricciones, Paradigma de Programación Orientado a Aspectos y Paradigma de Programación Orientado a Objetos. Pasivo: todo lo que una persona o empresa debe y está obligada a pagar. Los pasivos son la contraparte de los activos en los balances contables. Los pasivos pueden ser contingentes, cuando sólo son reclamables ante una cierta eventualidad previamente especificada, como en el caso de un aval dado para garantizar la deuda de un tercero, o no contingentes, como en una deuda cualquiera. Persistencia: es el almacenamiento duradero de estados o atributos de un objeto. Polimorfismo: es la característica de la Programación Orientada a Objetos mediante la cual dos o más tipos de objetos pueden responder a un mismo mensaje en forma diferente. Portabilidad: es la característica mediante la cual los sistemas de información pueden ser usados en diferentes entornos de ejecución. 15 Poscondición: son las restricciones que deben cumplirse una vez terminada una operación. Precondición: son las restricciones que deben cumplirse antes que se solicite una operación. Procedimiento de Prueba: es el procedimiento que especifica como realizar uno o varios caso de prueba o parte de estos Proceso Unificado de Desarrollo de Software: es el conjunto de actividades necesarias para transformar las necesidades de un usuario en un sistema de información, para esto se fundamenta en tres ideas básicas: los casos de uso, la arquitectura del sistema y el desarrollo iterativo e incremental. Programación Orientada a Objetos: es un paradigma de programación que define los programas en términos de clases de objetos. La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. Pruebas: es una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto. Relaciones entre Casos de Uso: entre dos casos de uso puede establecerse las siguientes relaciones: a) Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad. b) Include: Cuando un caso de uso utiliza a otro. Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta <<extiende>> o <<include>> según sea el tipo de relación. Responsabilidad: es el servicio o grupo de servicios ofrecidos por un tipo, la responsabilidad abarca uno o más propósitos u obligaciones de un tipo. Restricción: son las limitaciones o condiciones que se impone a un artefacto. 16 Riesgo: son las condiciones o situaciones que ponen en peligro o impiden el feliz término del sistema de información. Sistema: es una serie de artefactos (componentes) que en conjunto logran un resultado. Sistema de Información: es el que permite recopilar, manipular, almacenar y crear reportes de información respecto a las actividades de negocios de una empresa, con el fin de ayudar a la administración de la misma el manejo de las operaciones de negocios. Sistema de Partida Doble: cada asiento tiene dos vertientes: el debe y el haber. Estas dos posiciones hacen movimientos inversos, y afectan al activo o al pasivo, y se fundamentan por el hecho de que todo movimiento tiene una contrapartida. Software: no solo consiste en las instrucciones o código fuente a la computadora, sino también incluye los documentos de especificaciones, de diseño y legales, y de contabilidad de todo tipo, del plan de administración de proyectos y otros documentos de administración, así como todo tipo de manuales. Software Libre: es el software que, una vez obtenido, puede ser usado, copiado, estudiado, modificado y redistribuido libremente. El software libre suele estar disponible gratuitamente en Internet, o a precio del coste de la distribución a través de otros medios; sin embargo no es obligatorio que sea así y, aunque conserve su carácter de libre, puede ser vendido comercialmente. Subclase: es la especialización de otra clase (la superclase). Una subclase hereda los atributos y métodos de la superclase. Subtipo: es la especialización de otro tipo (el supertipo). Un subtipo hereda los atributos del supertipo. Superclase: son las clases cuyos atributos y métodos hereda otra clase. Supertipo: son los tipos cuyos atributos hereda otra tipo. Tipo: es la descripción de un conjunto de objetos similares con atributos pero que no incluye métodos. 17 Trabajador: es el cargo que puede ocupar una persona o equipo de trabajo, este demanda de responsabilidad y conocimientos o habilidades para realizar determinadas actividades o desarrollar artefactos específicos. UML: es un lenguaje gráfico para especificar, construir y documentar los artefactos que modelan un sistema. UML fue diseñado para ser un lenguaje de modelado de propósito general, por lo que puede utilizarse para especificar la mayoría de los sistemas basados en objetos o en componentes, y para modelar aplicaciones de muy diversos dominios de aplicación (telecomunicaciones, comercio, sanidad, etc.) y plataformas de objetos distribuidos (como por ejemplo J2EE, .NET o CORBA). Unidad de Trabajo: es el conjunto de entidades de negocio que conforman un todo reconocible para un usuario final. Usuario: es la persona o humano que interactúa con el sistema de información. Validación: es la evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos de las especificaciones. ¿Se esta construyendo el artefacto correcto? Verificación: es la evaluación de un sistema o de uno de sus componentes para determinar si los artefactos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. ¿Se esta construyendo correctamente el artefacto? Versión: es el conjunto de artefactos congruentemente completo y consistente entregado a un usuario para la prueba del sistema de información. Visibilidad: es la capacidad que tienen los objetos o clases de ver o hacer referencia a otros objetos. 18 Capítulo II Antecedentes del Problema El sistema de registro contable, ya sea manual o automatizado, permite el registro de la información financiera, la cual debe ser veraz y confiable. Al menos, son dos los documentos informativos que se deben generar, el Balance General y el Estado de Resultados, los mismos deben ser formulados por medio de la información particular de cada cuenta contable que los forman. Cada una de ellas debe estar respaldada por su saldo respectivo y un desglose o descripción de su contenido en un documento auxiliar llamado Relación Analítica, debidamente comprobada. Así cada saldo de cada cuenta debe ser “conciliado” con la información de cada relación analítica. Si en la comparación surgen diferencias, se debe buscar las causas que las originaron y emitir los documentos correctivos, para registrar los cambios en donde corresponda y obtener la igualdad de los saldos. A esto se le llama conciliación de cuentas. La Conciliación Bancaria es un caso especial de conciliación de cuentas, y consiste en un procedimiento de control interno y de rutina que consiste en verificar los registros realizados por la empresa que se encuentran también registrados en el banco, con el objeto de verificar los fondos depositados en el y detectar los errores u omisiones. Este proceso concluye cuando el saldo contable, al sumar o restar las diferencias sea igual al bancario. La conciliación bancaria lejos de ser un registro contable, es una herramienta de control. Las diferencias generalmente se generan al haber demoras en registrar algunas operaciones por falta de información. Uno de los casos más comunes es cuando la empresa entrega un cheque a un tercero. Inmediatamente lo contabiliza en sus registros y en el libro banco, pero el banco recién lo hará cuando el beneficiario se presente a cobrarlo o lo deposite. Esta diferencia se conoce con el nombre de cheque 19 pendiente o cheque no debitado. Otro caso de diferencias se da cuando la empresa deposita cheques. Ésta los registra en seguida en el libro banco, pero la acreditación por parte del banco no es inmediata, ya que estos cheques entran en el canje interno (depósitos de cheques contra el mismo banco, pero sobre otras plazas), clearing bancario o pase por cámaras compensadoras (cheques de otros bancos). Esta diferencia se denomina depósitos en tránsito o depósitos no acreditados. COPOSA empresa en la cual se desarrolló la pasantía, suscribe un convenio formal, con una institución financiera (banco), para que ésta le custodie, salvaguarde y le devuelva las entregas de dinero que aquélla le haga. Esta relación se da mediante depósitos y retiros, a través de medios adecuados. Las entradas y salidas de efectivo entre la empresa y el banco, las registran en sus respectivas contabilidades. Situación que genera dos cuentas corresponsales, que se llevan mutuamente y sus movimientos deben coincidir a determinada fecha. Esto se logra verificando dichos movimientos, partida por partida, eliminado las que sean iguales y atendiendo las partidas no correspondidas. A esto se le llama conciliación bancaria. Por lo tanto, la conciliación general es comparar dos movimientos financieros, de cuentas recíprocas y de saldos contrarios, haciendo que en un momento dado, dichos saldos sean iguales aplicando las diferencias que se hayan encontrado. A fin de automatizar el proceso de conciliación bancaria COPOSA utiliza como interfaz amigable para el usuario el Sistema de Conciliación General diseñado en el lenguaje de programación Microsoft® Visual Basic 6.0, la conexión a la base de datos se realiza a través del sistema ORACLE® para los siguientes libros: Libro GL (Contabilidad General), Libro AR (Cuentas por Cobrar) y Libro AP (Cuentas por Pagar) y la base de datos es implementada en Microsoft® SQL Server. Con este sistema la empresa y muy especialmente la Gerencia de Administración y Finanzas 20 han logrado optimizar el tiempo de respuesta de información tan vital para la organización. La documentación de los sistemas de información tiene gran importancia dentro de COPOSA y cualquier empresa, ya que esta ayuda a eliminar la posible dependencia que se pueda formar entre la aplicación o programa realizado, y el ejecutor de éste. Para que toda aplicación tecnológica y todo servicio informático quede adecuadamente documentado, es necesario exigirle a quien lo diseñe y/o desarrolle que entregue la documentación obtenida a través del diseño y desarrollo del sistema, de esta manera otras personas relacionadas o autorizadas por la empresa accedan a los conocimientos necesarios para corregir errores, hacer ajustes, nuevas versiones y actualizaciones, etc. Sin embargo, la Gerencia de Informática de COPOSA argumenta que realizar el proceso de documentación ocasiona un aumento de los costos y en un mayor plazo de entrega de los sistemas de información. Pero estas justificaciones no son posibles de sustentar en la realidad, ya que el costo de documentar se recupera con creces en el futuro, especialmente cuando la Gerencia de Informática se ve enfrentada a un error del sistema o sea necesario efectuarle mantenimiento al mismo. Además, puede decirse que cualquier sistema de información pobremente documentado carece de valor agregado aunque funcione bien, la mayoría de los programas cuya única documentación es el código fuente, se quedan obsoletos rápidamente y es imposible mantenerlos. La dedicación del esfuerzo de realizar la documentación del sistema se ve recompensada, ya que no se pondrá en duda las decisiones tomadas durante el desarrollo del mismo. Si no se documenta las decisiones, se cometerán los mismos 21 errores tratando de comprender, lo que pudo describirse fácilmente con una oportuna documentación. La falta de documentación no sólo genera trabajo adicional, sino además, tiende a dañar la calidad del código fuente. Si no se posee una nítida caracterización del problema, es imposible analizar, diseñar, desarrollar e implementar una solución clara. Finalmente la necesidad de realizar la documentación del sistema, entendiéndose esta como la información descriptiva (por ejemplo, modelos, especificaciones, manuales tanto de programador como de usuario, archivos de ayuda en línea, sitios Web, etc.) que detalla el uso y operación del sistema, es de suma importancia para el diseño y desarrollo del Sistema de Conciliación General, además de los otros sistemas desarrollados por la Gerencia de Informática de COPOSA. La documentación es la piedra angular que permite asegurar el mantenimiento y permanencia operativa de las aplicaciones, de ahí la importancia de contar con la documentación completa, correcta y actualizada, ya que la misma permite una búsqueda de información más accesible a los usuarios, además, de facilitar a los desarrolladores el mantenimiento del sistema. Descripción de la Empresa El 28 de Enero de 1974, un grupo de 153 hombres, agricultores en su mayoría, soñaron con hacer del Estado Portuguesa una de las regiones más generosas y un poderoso centro agroindustrial para Venezuela, fundando el Consorcio Oleaginoso Portuguesa, S.A. (Coposa). Es una empresa dedicada a producir, distribuir y comercializar productos de origen vegetal oleaginoso en los mercados nacionales e internacionales, a través del énfasis en el uso de altos estándares de tecnología y mercadeo, suministrando 22 productos de la mejor calidad. Para lograr los objetivos establecidos se emplean en forma directa a unas 1.000 personas en todo el país. El más valioso capital de la empresa es sin duda su recurso humano, y como tal, es cuidadosamente protegido por amplias medidas de seguridad industrial y estimulada a crecer a través de adiestramiento continuo. Además, se proporciona un extraordinario servicio a la comunidad a través de la Fundación Coposa, donde el proyecto de bienestar social se hace realidad todos los días. Y por encima de todo, se protege el medio ambiente a través del tratamiento de aguas residuales que permite conservar la belleza de nuestro hermoso país para las futuras generaciones. Misión Es fabricar, distribuir y comercializar bienes de origen vegetal oleaginoso en los mercados nacionales e internacionales, a través del énfasis en el uso de los más altos estándares de tecnología y mercado, suministrando productos de calidad superior que satisfagan las necesidades de sus clientes. Mejorando continuamente sus resultados financieros, sus índices de productividad y nivel profesional de sus trabajadores en un ambiente de responsabilidad, ética y de respeto al medio ambiente. Objetivos Con miras al cumplimiento de su misión, COPOSA tiene los siguientes objetivos: Objetivo Corporativo: La producción, comercialización y distribución de sus productos de alta calidad, especialmente dentro del mercado de aceites y grasas vegetales comestibles y harinas oleaginosas, con el fin de atender las demandas nacionales e internacionales y obtener un beneficio rentable económicamente para la empresa. 23 Objetivo Operativo: Para el logro del objetivo operativo se debe ejecutar lo siguiente: 1. Diversificar los productos e incrementar los servicios de COPOSA, con el fin de satisfacer los requerimientos en los mercados nacionales e internacionales. 2. Establecer un sistema de información y control. Políticas 1. Velar por el cumplimiento de las políticas y planes de abastecimiento, planificación y control de producción, aseguramiento de la calidad, desarrollo y mantenimiento de las instalaciones y maquinarias industriales a fin de ofrecer productos de gran calidad y a costos razonables. 2. COPOSA, promueve el desarrollo integral de su recurso humano, a través de la planificación e implementación de programas de entrenamiento, utilizando para ello recursos internos y externos. 3. COPOSA, se promueve velar por el cumplimiento estricto del conjunto de normas, leyes, principios y procedimientos establecidos, con el objeto de asegurar la prevención y bienestar social de sus trabajadores. 4. Se promueve velar por el cumplimiento de estrategias financieras y administrativas establecidas a fin de garantizar el correcto y máximo aprovechamiento de los recursos materiales y financieros de COPOSA. 5. La política de selección y empleo, se basa en que todas las personas tienen igual derecho al trabajo, independientemente de sus características de sexo, edad, religión, etc; quedando contratados los candidatos en comparación con otros. 6. Desarrollar estrategias y planes de mercado y venta en forma integrada para garantizar así la afectiva colocación de los productos y sub-productos en los diferentes mercados. 24 7. Es política de la empresa, velar por la implantación y cumplimiento de planes y programas socio-económicos que garanticen y mejoren el estado y calidad de vida de los trabajadores y su grupo familiar. 8. Se propone mantener y coordinar las actividades de atención médica establecida en COPOSA, para garantizar la salud y bienestar físico del trabajador. 9. Coordinar el establecimiento y administración del salario de los trabajadores acorde al nivel donde se desempeña. 10. Es también política de la empresa prevenir, evaluar y controlar el índice de accidentes en cada uno de nuestros departamentos, a través de un adecuado funcionamiento del área de higiene y seguridad industrial, a objeto de lograr una mayor protección a nuestro recurso humano y obtener una mayor producción. A escala nacional cuenta con seis (06) sucursales distribuidas en todo el territorio nacional, lo que le permite una amplia cobertura del mercado venezolano. PRESIDENCIA CONTRALORIA GERENCIA RELACIONES INSTITUCION CONSULTORIA JURIDICA GERENCIA GENERAL COMERCIAL GERENCIA LOGISTICA Y ABASTECIM GERENCIA ADMON. GERENCIA FINANZAS GERENCIA COMERCIALIZ ACIÓN GERENCIA MANUFACTURA GERENCIA ASEG. CALIDAD GERENCIA DIVISION R.R. H.H Figura Nº 2.1 Organigrama Resumido de la Empresa. Fuente: Gerencia Informática 25 Capítulo III: El Problema Una de las tecnologías más usadas en la actualidad para analizar, diseñar, codificar, mantener y probar los sistemas de información es la Programación Orientada a Objetos, además, el entorno de desarrollo actual de software está caracterizado por constante cambio. Todo proyecto que sobrepase los tres meses (3) está amenazado por la aparición de nuevas plataformas más exigentes, la extinción de herramientas u programas sin previo aviso. También está sometido a los cambios de requerimientos del cliente que a su vez están plenamente justificados por la readaptación de sus procesos de negocio guiado por las tendencias del mercado. La necesidad de la documentación de los sistemas de información desarrollados por la Gerencia de Informática de COPOSA, se hace mayor cuando es necesario migrar a la Programación Orientada a Objetos, para aprovechar sus características y las ventajas que brinda; la documentación permite a los analistas y programadores una mayor comprensión del sistema para realizar la transición de la forma menos traumática posible. Por tanto, la empresa necesita de la documentación de sus sistemas de información para asegurar un mayor y mejor mantenimiento preventivo, correctivo y adaptativo; además de las pruebas, rediseño y codificación de las aplicaciones. Los sistemas de información en la empresa COPOSA y muy específicamente el Sistema de Conciliación General no escapan de esta realidad, por esta razón la poca documentación existente del mencionado sistema de información constituye un problema a resolver. 26 Propuesta de Solución En consideración con lo anteriormente expuesto, durante el trabajo de Pasantía se propuso realizar la Documentación del Sistema de Conciliación General de la empresa Consorcio Oleaginoso Portuguesa, S.A. (COPOSA), siguiendo los enfoques y metodologías actuales para el desarrollo de los sistemas de información. La documentación del Sistema de Conciliación General se realizó a través del Proceso Unificado de Desarrollo de Software, que consta del análisis y diseño de los casos de usos, los diagramas y otros artefactos, la arquitectura del sistema y la aplicación del desarrollo iterativo e incremental sobre el ciclo de vida del sistema. El Proceso Unificado de Desarrollo de Software permite el descubrimiento de objetos y de sus múltiples conexiones a medida que se avanza en las respuestas a las interrogantes planteadas cuando se modela el dominio. La tecnología orientada a objetos preserva el antiguo principio del divide y vencerás. Se necesita descomponer la complejidad en partes más manejables y comprensibles, al parecer esto no es algo novedoso con respecto al tradicional Ciclo de Vida Clásico del Software, que persigue la descomposición funcional de los métodos estructurados. Sin embargo, la gran diferencia reside en aplicar la dualidad estructura-función en pequeñas unidades capaces de comunicarse y reaccionar en base a la aparición de una serie de eventos. Esta dualidad es aprovechada por el Proceso Unificado de Desarrollo de Software que se estructura en cuatro (4) fases y funciona bajo cinco (5) workflow o flujos de trabajos. Las cuatro (4) fases del Proceso Unificado de Desarrollo de Software según Booch, Jacobson y Rumbaugh (2004) son: 1) Fase de Iniciación: En esta fase se determina la conveniencia de desarrollar el Sistema de Conciliación General o cualquier otro sistema de información deseado por la Gerencia de Informática de la empresa COPOSA, es decir, precisar la viabilidad del sistema de información. 27 Los elementos derivados de la fase de iniciación son: a) La versión inicial del modelo de dominio, donde los objetos o clases se determinan en tres formas típicas: 1) Objetos que representan cosas que se manipulan en la empresa. 2) Conceptos de los que el Sistema de Conciliación General u otros sistemas que deben hacer un seguimiento. 3) Sucesos que ocurrirán o han ocurrido con respecto al Sistema de Conciliación. b) La versión inicial del modelo de negocios, se desarrolla en dos (2) pasos: 1) Los modeladores del negocio deben confeccionar un modelo que identifique a los actores y los casos de uso del negocio del Sistema de Conciliación. 2) Los modeladores deben desarrollar un modelo compuesto por trabajadores, entidades de negocio, y unidades de trabajo para los casos de uso del negocio del sistema. c) La versión inicial de los modelos de los artefactos de los requisitos, con atención en los Casos de Uso, glosario y prototipo de la interfaz de usuario que forman el Sistema de Conciliación. d) La versión inicial de los artefactos de análisis, constituidos por el modelo de análisis del Sistema de Conciliación. e) La versión preliminar de la arquitectura del Sistema de Conciliación. f) La lista inicial de los riesgos. g) El plan para la fase de elaboración. 28 2) Fase de Elaboración: El objetivo de esta fase es refinar o explicar los requisitos iniciales del Sistema de Conciliación, la arquitectura del sistema y cualquier otra condición considerada en la fase de iniciación. Los elementos derivados de la fase de elaboración son los siguientes: 3) a) El modelo de dominio terminado. b) El modelo de negocios terminado. c) Los artefactos de los requisitos terminados. d) Los artefactos de análisis terminados. e) La versión actualizada de la arquitectura del sistema. f) La lista actualizada de los riesgos. g) El plan de administración del proyecto. Fase de Construcción: El propósito de esta fase es producir las versiones operativas del Sistema de Conciliación que se efectúan en cada incremento. Los elementos derivados de la fase de construcción están: 4) a) El manual del usuario inicial y otros manuales de ser necesarios. b) Todos los artefactos (versión preliminar o beta). c) La arquitectura del sistema terminada. d) La lista actualizada de los riesgos. e) El plan de administración del proyecto. Fase de Transición: La finalidad de esta fase es asegurar que los requerimientos de COPOSA sean cumplidos, por tanto existe una retroalimentación entre los usuarios y el Sistema de Conciliación, la versión beta es mejorada y se corrigen las fallas encontradas para hacer el sistema lo más fiable posible. 29 Los elementos derivados de la fase de transición están: a) El manual del usuario inicial y otros manuales de ser necesarios. b) Todos los artefactos (versión beta). c) La arquitectura del sistema terminada. Figura Nº 3.1 Proceso Unificado. Fuente: Booch, Jacobson y Rumbaugh (2004) Como el Sistema de Conciliación General fue desarrollado siguiendo el Ciclo de Vida Clásico del Sistema, es operativo, pero no aprovecha las posibilidades de la Programación Orientada a Objetos. Surgió la necesidad de aplicar Ingeniería Inversa, a través de los Casos Reales de Uso, para determinar la documentación apropiada para el Sistema de Conciliación. Al mismo tiempo, al emplear las fases del Proceso Unificado de Desarrollo del Software se consigue, además de los Diagramas de Casos de Uso, otros artefactos muy importantes que guiaran durante el análisis, diseño, 30 desarrollo y prueba del Sistema de Conciliación, cuando sea necesario migrar a la tecnología orientada a objetos, también permitirá estandarizar la documentación de los restantes sistemas de información que posee la empresa COPOSA. Los cinco (5) workflows o flujos de trabajo del Proceso Unificado de Desarrollo de Software según Booch, Jacobson y Rumbaugh (2004) son los siguientes: 1) Flujo de Trabajo de Requisitos: El objetivo de este workflow es de asegurar que los desarrolladores elaboren un sistema de información correcto, para esto es necesaria una comunicación clara y precisa entre el cliente y los desarrolladores de la Gerencia de Informática de COPOSA. Para lograr esto, los requisitos tienen que ser totalmente comprendidos por el cliente, a través del modelado visual. Principalmente con el Modelo de Casos de Uso, se efectúa este flujo de trabajo, y al igual que las fases del Proceso Unificado utilizan los mismos modelos. Figura Nº 3.2 Modelo de Casos de Uso. Fuente: Booch, Jacobson y Rumbaugh (2004) 31 2) Flujo de Trabajo del Análisis: La finalidad de este workflow es de examinar y refinar los requisitos, hasta que sean comprensibles por el cliente sin ambigüedad posible, además, sea lo más preciso y con la mayor cantidad de detalles esenciales posibles para los desarrolladores de la Gerencia de Informática del Sistema de Conciliación. Su soporte es el Modelo de Análisis. Figura Nº 3.3 Modelo de Análisis. Fuente: Booch, Jacobson y Rumbaugh (2004) 3) Flujo de Trabajo del Diseño: En este workflow se refina todos los detalles provenientes del flujo de trabajo del análisis, permitiendo a los programadores implementar el Sistema de Conciliación. Para ello deben elegir el lenguaje de programación a utilizar, en este caso Microsoft© Visual Basic, la reutilización y la portabilidad del sistema. Es a través del Modelo de Diseño que se consiguen los objetivos del diseño del Sistema de Conciliación por parte de la Gerencia de Informática de COPOSA. 32 Figura Nº 3.4 Modelo de Diseño. Fuente: Booch, Jacobson y Rumbaugh (2004) 4) Flujo de Trabajo de Implementación: El propósito de este workflow es instaurar el Sistema de Conciliación en el lenguaje de programación seleccionado, es decir, consiste en codificar en Microsoft© Visual Basic los artefactos los cuales deberán ser probados por el programador. Figura Nº 3.5 Modelo de Implementación. Fuente: Booch, Jacobson y Rumbaugh (2004) 33 5) Flujo de Trabajo de Pruebas: La intención de este workflow es probar los artefactos. La prueba efectuada a cada componente tan pronto sea implementado se llama “prueba de unidad”; las pruebas efectuadas al final de cada iteración se denominan “pruebas de integración”; cuando el Sistema de Conciliación parece estar completo, se prueba en su totalidad a esto se le designa “prueba de producto”; cuando los trabajadores suponen que el sistema esta libre de fallos, se lo entregan al cliente para que este efectúe pruebas sobre el sistema de información, y compruebe si cumple con sus especificaciones, si el cliente queda satisfecho con el sistema de información entonces se dice se ha logrado aprobar la “prueba de aceptación”. A través del modelo de pruebas que se muestra a continuación: Figura Nº 3.6 Modelo de Prueba. Fuente: Booch, Jacobson y Rumbaugh (2004) La aplicación del desarrollo iterativo e incremental (las iteraciones construyen los modelos provenientes incremento por incremento, cada iteración añade algo 34 nuevo al modelo), con los incrementos se dividen las tareas (fases), y dentro de cada incremento es necesario iterar hasta que se hayan cumplido los flujos de trabajo, se tiene que el primer incremento se realizan los flujos de trabajo de requisitos, análisis, diseño, implementación y prueba; luego se continua con el segundo incremento el cual vuelve a tomar todos los flujos de trabajo, y así sucesivamente hasta que el sistema de información este completo. Las limitaciones que según la Ley de Miller poseemos los seres humanos, es la explicación más sencilla de porque es necesario el desarrollo iterativo e incremental, y la documentación del Sistema de Conciliación se realizó en tres (3) iteraciones. Figura Nº 3.7 Iteraciones Usadas para la Documentación del Sistema de Conciliación. Fuente: El Autor El mayor desafió del Sistema de Conciliación es su adaptación para el cambio. Es por esto que el Proceso Unificado de Desarrollo de Software permite crear modelos que faciliten la comunicación entre todos los agentes involucrados en el sistema en construcción; que hagan visible la trazabilidad entre la concepción de los componentes, su especificación, implementación e instalación; significa el diseño de arquitecturas que faciliten la gestión de las dependencias entre estos componentes, que sean en fin, fácilmente reemplazables por otros más optimizados o bien por componentes que aporten una mayor funcionalidad y/o facilidad de uso. En otras 35 palabras, reconsiderar lo obvio, desenmascarar presunciones, desambiguar conceptos conocidos, todo en busca de la simplicidad y la usabilidad de los artefactos, y muy especialmente de los objetos. El objeto es un artefacto que representa una entidad del mundo real o inventado. Es un concepto, una abstracción o algo que dispone de unos límites bien definidos y tiene una significación para el sistema que se pretende modelar. Los objetos poseen la siguiente estructura: a) Identidad. ¿Quién es el objeto? = Atributos. b) Propósito. ¿Cuál es la misión del objeto? = Justificación. c) Responsabilidades. ¿Qué debe hacer el objeto? = Métodos. d) Procedencia. ¿De qué Clase proviene el objeto? = Origen. e) Relaciones. ¿Qué mensajes entiende el objeto? = Comportamiento. Los objetos también poseen propiedades excepcionales que permiten un uso óptimo de los recursos, el Encapsulamiento, la Herencia y el Polimorfismo, son los tres (3) pilares en los cuales se descansa la Programación Orientada a Objetos. Encapsulamiento se entiende como el empaquetado de métodos y atributos dentro de un objeto mediante una interfase de mensajes. La clave está precisamente en este envoltorio del objeto. La interfase que rodea por completo al objeto actúa como punto de contacto para todos los mensajes que llegan desde cualquier objeto emisor. La interfase de mensajes tiene la misma función que la membrana celular, disponer de una barrera esencial entre la estructura interna de un objeto y el exterior. El propósito del encapsulamiento es garantizar que todas las interacciones del objeto tengan lugar a través de un sistema de mensajería predefinido con el que es capaz de entenderse y reaccionar adecuadamente. No existe ninguna otra manera con la que un objeto externo pueda acceder a los atributos y métodos escondidos dentro de la interfase de mensajes de otro objeto. 36 Herencia es el mecanismo por el cual una clase de objetos puede ser definida como un caso especial de otra clase más genérica. Los casos especiales de una clase se denominan Subclases. La clase más genérica, se conoce como la Superclase de todos sus casos especiales. Además de los métodos y atributos que heredan, las Subclases definen sus propios métodos y atributos. También, pueden redefinir algunos de los heredados (overriding). La interfase de mensajes definida para una Superclase también es heredada por las subclases. Esto implica que todas las Subclases de una Superclase están preparadas para responder correctamente a los mismos mensajes que la Clase padre. Esta propiedad es extremadamente útil porque permite tratar de la misma manera a todas las especializaciones de una Clase. Polimorfismo permite a los objetos interactuar entre ellos sin necesidad de conocer previamente a que tipo pertenecen. Un objeto puede ser de diferentes tipos. Por ejemplo una banda transportadora puede especializarse para cargar azúcar, maíz u otro tipo de ítems. Los demás objetos del sistema no tienen porque saber de cuantos tipos de banda transportadora se disponen. El mismo mensaje cargarItem, acompañado del parámetro que identifica dicho ítem, será interpretado de distinta manera por cada objeto receptor, el cual ya conoce previamente como tiene que tratar la naturaleza de su carga: azúcar, maíz, etc. Existe una reducción de esfuerzo muy significativa por el hecho que cualquier objeto del sistema puede enviar mensajes a las bandas transportadoras sin necesidad de saber de antemano qué tipo de banda transportadora está en uso. No hay necesidad de un código específico para cada tipo de banda transportadora, con lo cual, existe un ahorro de extensas sentencias IF o CASE que son complejas de mantener y de actualizar cuando se incorporan nuevos tipos de objetos. El UML o Unified Modeling Language “Lenguaje Unificado de Modelado”, se define como un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Captura decisiones y conocimientos sobre los sistemas que debe construir. Se usa para entender, diseñar, 37 hojear, configurar, mantener y controlar la información sobre tales sistemas. El UML no define un proceso estándar pero está pensado para ser usado por el Proceso Unificado de Desarrollo de Software, esto se debe a que la mayoría de los procesos empleados están orientados a objetos. El UML nació en 1994 por iniciativa de Grady Booch y Jim Rumbaugh para combinar sus dos famosos métodos: El de Booch y el OMT (Object Modeling Technique, Técnica de Modelado de Objeto), más tarde se unió Ivar Jacobson creador del método OOSE (Object Oriented Software Engineering, Ingeniería de Software a Objetos). El UML 1.0 fue adaptado unánimemente por los miembros del Object Management Group (OMG) como estándar en noviembre de 1997, OMG asumió la responsabilidad del desarrollo del estándar UML que en la actualidad se encuentra en UML 2.1. La palabra unificado tiene los siguientes significados relevantes para el UML: a) A través de los métodos históricos y notaciones: El UML combina conceptos comúnmente aceptados por muchos métodos orientados a objetos, seleccionando una definición clara para cada concepto, así como una notación y una terminología. b) A través del ciclo de vida de desarrollo: El UML no tiene saltos ni discontinuidades desde los requisitos a la implantación, esta continuidad es crítica para un desarrollo iterativo e incremental. c) A través de los dominios de aplicación: El UML está pensado para modelar la mayoría de los dominios de aplicación, incluyendo aquellos que implican sistemas grandes, complejos, de tiempo real, distribuidos, con tratamiento intensivo de datos o con cálculo intensivo, entre otras propiedades. d) A través de los lenguajes de implementación y plataformas: El UML está pensado para ser usado en sistemas desarrollados en varios lenguajes de 38 implementación y plataformas, lenguajes de programación, base de datos, documentos de organización, firmware y otros, el trabajo de la capa superior debería ser idéntico o similar, mientras que el trabajo de la capa inferior diferirá en algo para cada medio. e) A través de procesos de desarrollo: El UML usado como lenguaje de modelado lo subyacente a la mayoría de los procesos de desarrollo existentes o de nueva creación, de la misma forma que un lenguaje de programación de propósito general puede ser usada en varios estilos de programación. f) A través de los conceptos internos: En la construcción del metamodelo del UML el proceso permitió comprender mejor los conceptos y hacerlos más aplicables, este no fue el propósito original de la unificación, pero sí uno de los resultados más importantes. El UML captura información sobre la estructura estática y el comportamiento dinámico de un sistema. La estructura estática define los tipos de objetos importantes para un sistema y para su implementación, así como las relaciones entre los objetos. El comportamiento dinámico define la historia de los objetos en el tiempo y la comunicación entre objetos para cumplir sus objetivos. El UML permite agrupar las construcciones organizativas en paquetes, lo que permite dividir grandes sistemas en piezas, para entender y controlar las dependencias entre paquetes, y para gestionar las unidades del modelo en un entorno de desarrollo complejo. El UML no es un lenguaje de programación, pero permite construir modelos por ingeniería inversa a partir de programas existentes o por desarrollo iterativo. El UML no es un lenguaje altamente formal pensado para probar teoremas, el UML es un lenguaje de modelado de propósito general, es además, un lenguaje de modelado discreto. El objetivo del UML es ser tan simple como fuese posible pero manteniendo la capacidad de modelar toda gama de sistemas que se necesitan construir, además, de ser lo suficientemente expresivo para manejar todos los conceptos que se originan en 39 un sistema moderno, entre los más importantes la concurrencia y distribución, y los mecanismos de ingeniería del software, tales como encapsulamiento y componentes. Es un lenguaje universal como cualquier lenguaje de programación de propósito general. El UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML versión 1.4 del año 2000 y la versión 1.5 del año 2003 ofrecen nueve (9) diagramas en los cuales modelar sistemas. a) El Diagrama de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione, por tanto, es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML. El modelo de casos de uso consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que interaccionan con el sistema. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde un actor. Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otras propiedades, como las condiciones pre- y posdel escenario, condiciones que existen antes de que el escenario comience, y condiciones que existen después de que el escenario se completa. Típicamente, se modelan cada Caso de Uso con una secuencia normal de acciones. El usuario entonces considera condiciones “que si” para cada paso, y desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las secuencias alternas se 40 modelan en Casos de Uso separados, los cuales están relacionados con el caso de uso original mediante una relación “Extiende” (extends). Las relaciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el Caso de Uso extendido, hereda y modifica el comportamiento del Caso de Uso original. Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios Casos de Uso, la parte del comportamiento puede ser modelada en un caso de uso separado que está relacionado con los otros Casos de Uso mediante la relación “Include” (include). La relación Incluye (include) se puede pensar como un caso de uso equivalente “of aggregation”. b) El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada Caso de Uso, mientras que el Diagrama de Caso de Uso permite el modelado de una vista “business” del escenario, el Diagrama de Secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Típicamente se examina la descripción de un Caso de Uso para determinar que objetos son necesarios para la implementación del escenario. Un Diagrama de Secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. c) El Diagrama de Colaboración presenta una alternativa al Diagrama de Secuencia para modelar interacciones entre objetos en el sistema, mientras que el Diagrama de Secuencia se centra en la secuencia cronológica del escenario que se está modelando, el Diagrama de Colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por 41 medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas, el enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y “time-out”), y la visibilidad de un objeto con respecto a los otros. d) El Diagrama de Estado que permite modelar el comportamiento de los objetos en el sistema. e) El Diagrama de Actividad es un diagrama de flujo del proceso multipropósito que se usa para modelar el comportamiento del sistema. Los Diagramas de Actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado, un Diagrama de Actividad es parecido a un diagrama de flujo; la diferencia clave es que los Diagramas de Actividad pueden mostrar procesado paralelo (parallel processing), esto es importante cuando se usan diagramas de actividad para modelar procesos “bussiness” algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes. f) El Diagrama de Clase es el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones. g) El Diagrama de Objetos que sirve para modelar la estructura estática de los objetos en el sistema. h) El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de software, los componentes de código binario, y los componentes ejecutables. En el Diagrama de Componentes se modelan los componentes del sistema, a veces 42 agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes). i) Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama “deployment”, empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, se puede indicar que instancias de componentes viven o corren (se ejecutan) en el nodo. También se pueden modelar los objetos que contiene el componente. Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes en tiempo de compilación o de tiempo de enlazado. Y desde UML versión 2.0 del año 2005 hasta la actual versión 2.1.1 de superestructuras e infraestructuras se han añadido a los nueve (9) diagramas anteriores cuatro (4) diagramas los cuales son: j) Diagrama de Comunicación k) Diagrama de Estructura Compuesta, l) Diagrama de Tiempos, m) Diagrama de Vista de Interacción. Por lo que resulta que con UML versión 2.1.1 existen trece (13) diagramas. La primera herramienta utilizada para el diseño de los diagramas del UML fue el Umbrello que es una aplicación nativa para software libre (Debian, Ubuntu, Kubuntu, Knoppix, Fedora Core, etc) y no permite cambiar a otra plataforma (en la empresa COPOSA posee la licencia del sistema operativo Windows© XP); fue necesario utilizar otra herramienta, la escogida es el ArgoUML versión 0.24 que es una aplicación de diagramado de UML escrita en Java y publicada bajo la Licencia 43 BSD Open Source. Dado que es una aplicación Java, está disponible en cualquier plataforma soportada por Java (Linux, Windows, Mac, etc), por lo que se puede ejecutar en cualquier plataforma que tenga una máquina virtual Java. Pero esto también implica que es una aplicación que requiere máquinas con procesadores superiores a 2.0 Gh, y al menos 512 Mb de memoria RAM, esto debido a que el lenguaje Java es interpretado. El ArgoUml versión 0.24 presenta como inconveniente la recuperación de los archivos .uml ya escritos, si mientras se está guardando el archivo, o editando algún diagrama y falla la energía eléctrica, el archivo se corrompe y no es posible abrirlo, editarlo o manipularlo, ni que muestre información alguna. Esta falla, durante el desarrollo de la Pasantía represento un retraso considerable, ya que ocurrió cuatro veces (4) durante el diseño de los diagramas. Para implementar la documentación del Sistema de Conciliación General las primeras herramientas utilizadas para el diseño del manual de ayuda para el usuario fue el Help Creator 1.0.0.56 y el Help Producer 2.2 los cuales están publicados bajo la Licencia BSD Open Source, al igual que el ArgoUml versión 0.24, la recuperación de los archivos creados es una de la falla más critica, además, no poseen la capacidad de producir ayuda en diferentes formatos, ni permiten crear una ayuda lo suficientemente amigable para el usuario; estas razones condujeron a utilizar el programa Help & Manual© versión 4.3, que permite crear aplicaciones con una interfaz atractiva y gran cantidad de opciones, lo requerido en la actualidad por cualquier manual de ayuda. En este aspecto, Help & Manual© versión 4.3 facilita crear todo el sistema de ayuda y documentación necesaria de las aplicaciones y exportarlo a varios formatos (PDF, ayuda en HTML, winhelp, mmhelp...). Su interfaz es muy sencilla, por lo que se puede usar intuitivamente como si fuera un procesador de texto, además, se puede usar como un visualizador de imágenes, captura de pantalla y herramientas para impresión. 44 La documentación propuesta, permitirá a la Gerencia de Informática de COPOSA, desarrollar la documentación del Sistema de Conciliación General, además proporcionará una guía para estandarizar la documentación del resto de los sistemas de información existentes, asimismo, permitiendo el uso óptimo de los recursos, el empleo de las nuevas tecnologías del enfoque del Proceso Unificado de Desarrollo de Software y el Paradigma de la Programación Orientada a Objetos. 45 CAPITULO IV Descripción de la Solución La documentación del Sistema de Conciliación General se baso en el Proceso Unificado de Desarrollo de Software, para ello se utilizo UML; el UML indica que la primera actividad a desarrollar es la descripción de los Casos de Usos, para luego ensamblarlos en el Diagrama de Casos de Usos. El formato de los Casos de Usos propuestos para la solución del sistema fue tomado de Larman (1999), este autor también indica los patrones, que deben ser utilizados para el análisis, diseño, desarrollo, codificación, prueba, documentación y mantenimiento de los diferentes artefactos provenientes del UML. Caso de Uso: Identificar Actores: Analista Propósito: Identificación y / o Registro de analista para uso del sistema. Resumen: Un Analista se identifica ante el sistema de conciliación o se registra en el mismo, para esto deberá suministrar la información solicitada por el sistema. Al terminar la operación, el Analista recibe la identificación y clave de usuario. Tipo: Primario y esencial Referencias Cruzadas 46 Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se carga la hora y fecha del sistema cuando operativo. ingresar un Analista al de Se presenta una pantalla donde introducir los General, donde datos solicitados en caso de no poseer introducir su Conciliación deberá intenta Sistema identificación y clave de usuario. identificación y clave de usuario. 3. El Analista registra el 4. El identificador y la clave de usuario es identificador y clave de usuario validada para descartar que se encuentren de su elección. asignados a otro Analista. En esta el Analista suministra su Se indica el identificador y la clave de nombre, usuario a usar por parte del Analista. apellido, fecha de ingreso a la empresa, sitio en que labora: Planta o Sucursal, departamento donde labora y cargo desempeñado. 5. El Analista recibe la identificación y clave de usuario. 6. Se actualiza la base de datos del Sistema de Conciliación sobre la identificación y clave de usuario, además de asignar los permisos y restricciones que tendrá esta identificación en el sistema. Cursos alternos de los eventos Sección 1: se introduce un identificador o clave de usuario inválido. 47 Figura Nº 4.1 Caso de Uso Identificar Caso de Uso: Conciliar Actores: Analista, Usuario Propósito: Conciliación de las cuentas bancarias contra los libros contables de COPOSA. Resumen: Un Analista contable requiere realizar la conciliación del registro contable de dinero que se encuentra en Banco contra los registros contables de los Libros de la empresa, puede ocurrir que los registros tanto del Banco como de la Empresa sean exactos, por lo que la Conciliación es exacta; en caso que los registros contables de dinero del Banco y la Empresa difieran, existe una diferencia en monto, el Analista deberá determinar qué origina la irregularidad y por qué ocurre con la finalidad de solventar la situación, para esto el Analista puede realizar una revisión exhaustiva de los registros del Banco así como de los registros 48 contables de COPOSA. Al terminar la operación, el Analista recibe información de la conciliación efectuada. Caso de uso: el Analista debe haber Referencias Cruzadas terminado el caso de uso: Identificar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se carga la hora y fecha del sistema cuando operativo. un Analista necesita realizar la conciliación del dinero Se verifica los permisos y restricciones de que se encuentra registrado en esta identificación de usuario en el sistema. las Cuentas Bancarias contra los registros contables de los Libros de la empresa. Se presenta una pantalla que ofrece diferentes opciones, entre ellas la de Conciliación. 3. El Analista determina si los 4. Si el movimiento de registro del Banco y movimientos de registros del un movimiento de registro contable de Libro Banco contra los movimientos de pertenecen a la misma entidad financiera, los registros contables de los cuenta y tienen la misma referencia, el Libros, comparando para ello en sistema los cruza y muestra si tienen el el sistema de conciliación el monto igual o si existe una diferencia en el Banco, la Cuenta, la Referencia y mismo; en caso no poseer el mismo Monto, el Monto. el Analista puede decidir si cruzarlo o no. 5. El Analista decide entre las opciones que le ofrece el sistema 49 de conciliación, escoge la que permita efectuar un cruce más efectivo entre los registros bancarios y los registros de los Libros de la empresa, para esto dispone de las siguientes opciones de conciliación: a) Si realiza la conciliación de un movimiento registrado en Libro contra un movimiento registrado en Banco comparando el número de cuenta, tipo de movimiento y la referencia, iniciar Automática por Referencia. b) Si realiza la conciliación de un movimiento registrado en Libro contra un movimiento registrado en Banco tomando en cuenta el número bancaria, de cuenta tipo de movimiento y el monto, iniciar Automática por Monto. 50 c) Si realiza la conciliación de aquellos movimientos registrados en Libro que corresponden a un solo movimiento registrado en Banco, iniciar Movimiento Compartido en Banco. d) Si realiza la conciliación de aquellos movimientos registrados en Banco que corresponden a un solo movimiento registrado en Libro, iniciar Movimiento Compartido en Libro. e) Si realiza la conciliación de los cheques que sean anulados durante el mes que se está conciliando, el sistema muestra una lista con todos los cheques registrados en Libro pendientes por conciliado y un estatus si está o no anulado, iniciar Cheques Anulados. f) Si realiza la conciliación de aquellos movimientos 51 registrados en Banco que no tienen su correspondiente movimiento registrado en Libro, iniciar Interna en Banco. g) Si realiza la conciliación en Libro de aquellos movimientos cargados por la compañía que no tienen su correspondiente movimiento registrado en Banco, iniciar Interna en Libro. h) Si realiza la conciliación el analista es el que decide que movimiento en Libro cruza con uno de Banco, ya que no tienen similitud con respecto a la referencia y tipo de movimiento, iniciar Manual. i) Si se quiere consultar movimientos en Libro (AR / GL / AP) y movimientos registrados iniciar en Banco, Consultar 52 Movimiento. j) Si se quieren congelar los movimientos de los registros en un momento dado para realizar algún cruce y luego descongelarlo, iniciar Congelar Movimiento. k) Si se quiere consultar los movimientos de registros por Reclasificar, es decir, movimiento registrado en Libro en un Banco que correspondían a Otro Banco, iniciar Movimiento por Reclasificar. l) Si se quiere eliminar un movimiento cargado en el Estado de Cuenta de forma errónea., iniciar Eliminar Movimiento. m) Si se quiere mostrar los Resultados Conciliación, de una iniciar Resultado. 6. Actualiza el estatus de la conciliación 53 generada. Cursos alternos de los eventos Sección 3: se busca un registro contable no existente, o se busca un Banco inexistente. Sección 5: el Analista no pudo realizar la Conciliación por los tipos que permite el sistema de Conciliación General. Casos de usos relacionados usa Automática por Referencia. usa Automática por Monto. usa Movimiento Compartido en Banco. usa Movimiento Compartido en Libro. usa Cheques Anulados. usa Interna en Banco. usa Interna en Libro. usa Manual. usa Consultar Movimiento. usa Congelar Movimiento. usa Movimiento por Reclasificar. usa Eliminar Movimiento. usa Resultado. 54 Figura Nº 4.2 Caso de Uso Conciliar 55 Caso de Uso: Automática por Referencia Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación Automática por Referencia es diferente de acuerdo al tipo de movimiento registrado en Banco y el movimiento registrado en el Libro de la empresa que se está conciliando: a) Conciliación Libro AR: en este se concilian Depósitos en Libro contra DP (Depósitos) y NC (Notas de Crédito) en Banco, también se concilian NDC (Notas de Debitos por Cheques Devueltos) en Libro contra NDC en Banco. b) Conciliación Libro AP: aquí se concilian CH (Cheques) y ND (Notas de Debito) en Banco contra CH y ND en Libro y DP y NC en Banco contra DP y NC en Libro. c) Conciliación Libro GL: aquí se concilian Recepciones (DP, NC, NCT) en Libro contra DP, NC, NCT en Banco, también se concilian Pagos (CH, ND, NDT) en Libro contra CH, ND, NDT en Banco. También se concilian las diferencias de 56 meses anteriores contra pagos y / o recepciones en los registros del Libro según sea el caso. Bajo este criterio la Conciliación puede ser exacta o como diferencia en monto. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si las referencias del movimiento de cuando necesita registro del Banco y las referencias de realizar la conciliación bancaria movimiento de registro contable de Libros de son iguales, el sistema los cruza y muestra un las Analista referencias que se encuentran registradas en las los montos. Cuentas Bancarias contra las referencias de los registros contables de los Libros de la empresa. 3. El Analista determina si las 4. Se genera la conciliación automática por referencias de los movimientos referencia. de registros del Banco contra las Se actualiza la base de datos sobre las referencias de los movimientos Conciliaciones efectuadas por el sistema. de los registros contables de los Libros, son consistentes. 5. El Analista conciliación observa automática la por 57 referencia generada, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: las referencias del registro contable de los Libros de la empresa no coinciden con las referencias registradas en Banco. Puede cancelarse la conciliación automática por referencia o iniciar otro tipo de Conciliación. Figura Nº 4.3 Caso de Uso Automática por Referencia 58 Caso de Uso: Automática por Monto Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación Automática por Monto de acuerdo a la referencia en Banco que puede ser diferente a la que está en Libro. Un dato importante para este tipo de Conciliación es la fecha del movimiento en Libro que debe ser igual o mayor a la fecha en Banco. Se presentan las coincidencias del monto en los registros del Libro / Banco. Bajo este criterio la Conciliación puede ser exacta o como diferencia en monto. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si los montos del movimiento de registro cuando necesita del Banco y los montos de movimiento de realizar la conciliación bancaria registro contable de Libro son iguales, el de los montos que se encuentran sistema los cruza y muestra los montos registradas respectivos. un Analista en las Cuentas Bancarias contra los montos de los registros contables de los Libros de la empresa. 59 3. El Analista determina si los 4. Se genera la conciliación automática por montos de los movimientos de monto. registros del Banco contra los Se actualiza la base de datos sobre las montos de los movimientos de Conciliaciones efectuadas por el sistema. los registros contables de los Libros, son consistentes. 5. El Analista conciliación monto imprimir observa automática generada, la y la por puede conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con los montos y las referencias registradas en Banco. Puede cancelarse la conciliación automática por monto o iniciar otro tipo de Conciliación. Figura Nº 4.4 Caso de Uso Automática por Monto 60 Caso de Uso: Movimientos Compartidos en Banco Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación de Movimientos Compartidos en Banco esto de acuerdo a las razones por las cuales un movimiento de Libro está compartido entre varios movimientos en Banco: a) Un deposito se registra en Libro pero a nivel del Estado de Cuenta se presenta como dos depósitos diferentes, esto porque, el depósito estaba conformado por efectivo y cheque (caso Banco Provincial), en Libro AR. b) Se registra un cheque en Libro como un único Movimiento (monto cheque + comisión), pero a nivel del Estado de Cuenta existen dos movimientos: el cheque y la comisión, en Libro AP. Bajo este criterio la Conciliación puede ser exacta o como diferencia en monto. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor 1. Este caso de uso comienza Respuesta del sistema 2. Si un depósito está formado por 61 cuando un Analista necesita cantidades de dinero en efectivo y cheque, realizar la conciliación bancaria en el Libro de la empresa se registra un solo de la referencia y / o monto que movimiento, en los registros de Banco a se encuentra registrada en las nivel de Estado de Cuenta se presenta como Cuentas Bancarias contra las dos movimientos, uno refleja el monto de referencias y / o montos de los dinero en cheque y el otro el monto en registros contables de los Libros efectivo. Este caso sólo ocurre en el Banco de la empresa. Provincial y eventualmente en CorpBanc. El sistema los cruza y muestra los montos respectivos. 3. El Analista determina si los 4. Se genera la conciliación de movimientos montos de los movimientos de compartidos en banco. registros Se actualiza la base de datos sobre las contables en Libro contra el monto del movimiento del registro de Banco, Conciliaciones efectuadas por el sistema. son consistentes. 5. El Analista conciliación de observa la movimientos compartidos en banco generada, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación de movimientos compartidos en banco o iniciar otro tipo de Conciliación. 62 Figura Nº 4.5 Caso de Uso Automática en Banco Caso de Uso: Movimientos Compartidos en Libro Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación de Movimientos Compartidos en Libro esto de acuerdo a las razones por las cuales un movimiento en Banco se asocia contra varios movimientos registrados en Libro, considerando el número de cuenta bancaria y el tipo de Movimiento. a) Un depósito cancela varias facturas de diferentes 63 relaciones de cobro (ejemplo: facturas de clientes de cadenas nacionales), en Libro AR.. b) Un cheque en Banco cancela varias facturas de diferentes proveedores, en Libro AP. c) Un cheque en Banco se registra como dos (2) movimientos en Libro ya que separa monto cheque de la comisión, en Libro AP. Bajo este criterio la Conciliación puede ser exacta o como diferencia en monto. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si un depósito permite cancelar diferentes cuando necesita facturas en los Libros de la empresa se realizar la conciliación bancaria registran como varios movimientos, en los de la referencia y / o monto que registros de Banco a nivel de Estado de se encuentra registrada en las Cuenta Cuentas Bancarias contra las movimiento. referencias y / o montos de los El sistema los cruza y muestra los montos un Analista registros contables de los Libros se presenta como un único respectivos. de la empresa. 3. El Analista determina si la 4. Se genera la conciliación de movimientos sumatoria de los montos de los compartidos en libro. 64 movimientos registrados en Libro es coincidente con el Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. monto del movimiento registrado en Banco. 5. El Analista conciliación de observa la movimientos compartidos en libro generada, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: la suma de los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación de movimientos compartidos en libro o iniciar otro tipo de Conciliación. Figura Nº 4.6 Caso de Uso Movimiento Compartido en Libro 65 Caso de Uso: Cheques Anulados Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación de Cheques Anulados esto para verificar que todos los cheques registrados en Libro pendientes por conciliar, y para verificar como se encuentra el estatus de los mismos: anulado o no anulado. En caso de estar anulado muestra la fecha de anulación, si esta corresponde a un mes anterior o igual al mes que se está conciliando el cheque debe salir de la conciliación, en caso contrario debe seguir como cheque en tránsito. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si ocurre que la fecha de emisión de los cuando necesita cheques es anterior en meses a la fecha del realizar la conciliación bancaria sistema operativo, se les considera como de la referencia y monto de los cheques en transito, y luego en Libro AP se cheques anulan por Caducidad. un registrados Analista que en se las encuentran Cuentas El sistema muestra las referencias y los Bancarias contra las referencias y 66 montos de los cheques montos respectivos. registrados en los Libros de la empresa. 3. El Analista determina si las 4. Se genera la conciliación de cheques referencias y los montos de los anulados. cheques registrados en Libro Se actualiza la base de datos sobre las contra la referencia y el monto Conciliaciones efectuadas por el sistema. del cheque registrado en Banco, son consistentes. 5. El Analista conciliación anulados imprimir observa de generada, la la cheques y puede conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias de los cheques registrados en los Libros de la empresa no coinciden con el monto y la referencia de los cheques registrados en Banco. La fecha de emisión del cheque debe ser al menos menor en un mes a la fecha del sistema operativo. Puede cancelarse la conciliación de cheques anulados o iniciar otro tipo de Conciliación. 67 Figura Nº 4.7 Caso de Uso Cheques Anulados Caso de Uso: Interna en Banco Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación Interna en Banco esto para verificar que se concilian aquellos movimientos en Banco que no tienen su correspondiente movimiento registrado en Libro, el analista realiza el cruce entre un movimiento por acreditar contra uno por debitar. Las razones por las que un movimiento en Banco no tiene su movimiento en Libro son: 68 correspondiente a) Reintegro de IDB. b) Reversos internos de Banco. c) Compensación de cheques interna de Banco. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si se carga por error movimiento bancario cuando necesita a los Libros de la empresa, se deberá realizar la conciliación bancaria reversar el mismo con el movimiento de la referencia y / o monto que bancario que anule el asiento en los Libros se encuentra registrada en las de la empresa; por ejemplo: un cheque en Cuentas Bancarias contra las Libro AP, hay que registrar un movimiento referencias y / o montos de los en Libro GL que lo reverse en este cado registros contables de los Libros sería una nota de crédito. un Analista de la empresa. El sistema presenta dos listas: una con los movimientos por acreditar (Depósitos y Notas de Crédito) y la otra con los movimientos por debitar (Cheques, Notas de Débito, Comisiones, IDB). De esta manera el analista realiza el cruce entre un movimiento por acreditar contra uno por debitar. 3. El Analista determina si los montos que no 4. Se genera la conciliación interna en aparecen 69 registrados en los movimientos banco. del Libro correspondiente se Se actualiza la base de datos sobre las encuentra Conciliaciones efectuadas por el sistema. registrado en otro Libro de la empresa, para esto se considera la referencia y el monto del movimiento del registro de Banco. El Analista debe verificar la consistencia de los datos visualizados por el sistema y determinar si son consistentes. 5. El Analista observa la conciliación interna en banco generada, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación interna en banco o iniciar otro tipo de Conciliación. 70 Figura Nº 4.8 Caso de Uso Interna en Banco Caso de Uso: Interna en Libro Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación Interna en Libro esto para verificar que se concilian aquellos movimientos registrados en Libro que no tienen su correspondiente movimiento en Banco, el analista realiza el cruce entre un 71 movimiento por debitar contra uno por acreditar. Las razones por las que un movimiento en Libro no movimiento tiene en su correspondiente Banco, son aquellos movimientos cargados por concepto de: a) Reverso de IDB. b) Reverso de movimientos duplicados. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si se carga por error un registro en los cuando necesita Libros de la empresa que no poseen su realizar la conciliación bancaria correspondiente movimiento en el Banco, se de la referencia y / o monto que deberá reversar el mismo con el movimiento se encuentra registrada en las bancario que anule el asiento en los Libros Cuentas Bancarias contra las de la empresa; por ejemplo: un cheque en referencias y / o montos de los Libro AP, hay que registrar un movimiento registros contables de los Libros en Libro GL que lo reverse en este cado de la empresa. sería una nota de crédito. un Analista El sistema presenta dos listas: una con los movimientos por debitar (Depósitos y Notas de Crédito) y la otra con movimientos por acreditar (Cheques, Notas de Débito, Comisiones, IDB). De esta manera el 72 analista realiza el cruce entre un movimiento por debitar contra un movimiento por acreditar. 3. El Analista determina si los 4. Se genera la conciliación interna en montos banco. que no aparecen registrados en los movimientos del Libro correspondiente se Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. encuentran registrados en otro Libro de la empresa, para esto se considera la referencia y el monto del movimiento del registro de Banco. El Analista debe verificar la consistencia de los datos visualizados por el sistema y determinar si son consistentes. 5. El Analista observa la conciliación interna en banco generada, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación interna en banco o iniciar otro tipo de Conciliación. 73 Figura Nº 4.9 Caso de Uso Interna en Libro Caso de Uso: Manual Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Conciliación Manual esto para el decidir que movimiento registrado en Libro se cruza con uno de Banco, ya que no tienen similitud con respecto a la referencia y tipo de movimiento, este tipo de conciliación toma en cuenta solo el número de cuenta bancaria. Además bajo este criterio el analista puede 74 conciliar un movimiento en Libro sin asociarlo a un movimiento de Banco, solo le asigna un tipo de estatus: por reversar, por reclasificar, estimación IDB, reverso IDB. De esta manera el Movimiento en Libro queda conciliado. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si se carga por error un registro contable cuando necesita en los Libros de la empresa que poseen su realizar la conciliación pendiente correspondiente movimiento registrado en el de la referencia y / o monto que Banco, o si se carga por error un registro en no se encuentra registrada en las el Banco que poseen su correspondiente Cuentas Bancarias contra las movimiento contable en el Libro de la referencias y / o montos que no empresa. se encuentran en los registros El sistema muestra las referencias y los contables de los Libros de la montos respectivos. un Analista empresa. 3. El Analista determina si los 4. Se genera la conciliación manual. montos que aparecen registrados Se actualiza la base de datos sobre las en los movimientos del Libro Conciliaciones efectuadas por el sistema. correspondiente se encuentra registrado en otro Libro de la empresa, para esto se considera 75 la referencia y el monto del movimiento del registro de Banco. El Analista debe verificar la consistencia de los datos visualizados por el sistema y determinar si son consistentes. 5. El Analista observa la conciliación manual generada, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación manual o iniciar otro tipo de Conciliación. Figura Nº 4.10 Caso de Uso Manual 76 Caso de Uso: Consultar Movimiento Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Consulta de Movimiento para esto se toman los movimientos en Libro (AR / GL / AP) y Banco. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. El sistema presenta tres listas: la primera cuando necesita con la información de los movimientos consultar la conciliación bancaria registrados en los Libros de la empresa, la de acuerdo a la referencia. segunda un Analista con la información de los movimientos registrados en Banco y tercera la diferencia existente entre la información de los Libros de la empresa y Banco. 3. El Analista puede determina si 4. Se genera la conciliación de consultar los montos de los movimientos movimiento. de registros contables en Libro Se actualiza la base de datos sobre las son iguales a los montos del Conciliaciones efectuadas por el sistema. movimiento del registro de Analista observa la Banco. 5. El conciliación de consultar 77 movimiento generado, y puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación de consultar movimiento o iniciar otro tipo de Conciliación. Figura Nº 4.11 Caso de Uso Consultar Movimiento 78 Caso de Uso: Congelar Movimiento Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar la Congelar de Movimiento esto permite congelar los movimientos en un momento dado para realizar algún cruce y luego descongelarlo. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si es necesario efectuar algún tipo de cuando necesita operación sobre un movimiento pero que realizar la conciliación bancaria esto no repercuta en ninguna otra parte del de la referencia que se encuentra sistema, se puede congelar; en este sentido registradas en los Libros de la se asigna un estado o indicador a los empresa para que no realice movimientos, el cual puede ser congelado o operación no congelado. un Analista alguna sobre las referencias de los registros del Banco. 3. El Analista determina si los 4. Se genera la conciliación de congelar movimientos movimiento, con lo cual sólo cambio el de registros contables en Libro contra el estado del movimiento a congelado. movimiento Se presenta la pantalla que indica los del registro Banco, son consistentes. de movimientos congelados. 79 Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. 5. El Analista observa si luego de 6. Se genera la conciliación de congelar realizar movimiento, con lo cual sólo cambio el congelar efectuar la conciliación movimiento el cruce de pudo de los movimientos en la conciliación. estado del movimiento ha no congelado. Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. Puede cambiar el estado del movimiento y descongelarlo. 7. El Analista puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación de congelar movimientos o iniciar otro tipo de Conciliación. Figura Nº 4.12 Caso de Uso Congelar Movimiento 80 Caso de Uso: Movimiento por Reclasificar Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar el Movimiento por Reclasificar esto es movimiento registrado en Libro en un Banco que correspondían a otro Banco. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si es necesario consultar los movimientos cuando de en Libros de los diferentes Bancos. un Analista necesita consultar la conciliación bancaria El sistema presenta tres listas: una con los de la referencia que se encuentra movimientos registrados en Libro AR, otra registradas en el Libro que no con los movimientos registrados en Libro corresponden a las referencias de AP y la última con los movimientos los registros del Banco. registrados el Libro GL. 3. El Analista determina si los 4. Se genera la conciliación de movimiento movimientos por reclasificar, con lo cual sólo se de registros contables en Libro contra el movimiento del registro de Banco, son consistentes. visualizan los movimientos en los Libros. Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. 5. El Analista puede imprimir la conciliación generada. 81 Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación de movimientos por reclasificar o iniciar otro tipo de Conciliación. Figura Nº 4.13 Caso de Uso Movimiento por Reclasificar Caso de Uso: Eliminar Movimiento Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar Eliminar Movimiento esto para eliminar un 82 movimiento cargado en el Estado de Cuenta de forma errónea. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Si es necesario eliminar los movimientos cuando de Banco. un Analista necesita eliminar de la referencia que se El sistema realiza la búsqueda de acuerdo a encuentran registrada en Libro la referencia y presenta toda la información contra correspondiente del Banco, y además, permite borrar referencia del registro del Banco. solamente el movimiento registrado en el la Banco que se seleccione. 3. El Analista determina si los 4. Se genera la conciliación de eliminar movimientos movimiento, con lo cual sólo se elimina el de registros contables en Libro contra el movimiento seleccionado. movimiento Se actualiza la base de datos sobre las del registro de Banco, son consistentes. Conciliaciones efectuadas por el sistema. 5. El Analista puede imprimir la conciliación generada. Cursos alternos de los eventos Sección 2: los montos y las referencias del registro contable de los Libros de la empresa no coinciden con el monto y la referencia registrada en Banco. Puede cancelarse la conciliación de eliminar movimiento o iniciar otro tipo de 83 Conciliación. Figura Nº 4.14 Caso de Uso Eliminar Movimiento Caso de Uso: Resultado Actores: Analista, Usuario Resumen: Un Analista contable requiere realizar el Resultado esto para obtener el resumen de los movimientos registrados en Libro, movimientos de Banco, el cierre en Libro y el cierre en Banco. Referencias Cruzadas Caso de uso: el Analista debe haber 84 comenzado el caso de uso: Conciliar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. El sistema presenta tres listas: la primera cuando necesita con los movimientos registrados en Libro no visualizar la conciliación de los encontrados en Banco, la segunda los Libros de la empresa y los movimientos registros del Banco. encontrados en Libro y la tercera el cierre en un Analista cargados en Banco no Libro y el cierre en Banco. Esto se calculan de acuerdo a los siguientes criterios: Cierre en Libro: Saldo según Libro + Depósitos / Notas de Crédito en Banco no registradas en Libro + Cheques / Notas de Débito en Libro por Reclasificar + Cheques / Notas de Débito en Libro por Reversar + Diferencias en Depósitos / Notas de Crédito no registradas en Libro + Diferencias en Cheques / Notas de Débito en Libro por Reclasificar o Reversar - Cheques / Notas de Débito en Banco no 85 registradas en Libro - Depósitos / Notas de Crédito en Libro por Reclasificar - Depósitos / Notas de Crédito en Libro por Reversar - Diferencias en Cheques / Notas de Débito no registradas en Libro - Diferencias en Depósitos / Notas de Crédito en Libro por Reclasificar o Reversar Cierre en Banco: Saldo según Estado de Cuenta + Depósitos / Notas de Crédito en Libro por acreditarnos en Banco - Notas de Débito en Libro por debitarnos en Banco - Cheques en Tránsito. 3. El Analista observa el resultado generado, y puede imprimir la 4. Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. conciliación generada. 86 Figura Nº 4.15 Caso de Uso Resultado 87 Caso de Uso: Desaplicar Actores: Analista, Usuario Propósito: Conciliación de las cuentas bancarias contra los libros contables de la empresa COPOSA. Resumen: Un Analista contable requiere realizar la conciliación del registro contable de dinero que se encuentra en Banco contra los registros contables de los Libros de la empresa, puede ocurrir que los registros tanto del Banco como de la Empresa sean exactos, por lo que la Conciliación es exacta; en caso que los registros contables de dinero del Banco y los registros contables la Empresa difieran existe una diferencia en monto el Analista deberá determinar qué origina la irregularidad y por qué ocurre con la finalidad de solventar la situación, para esto el Analista puede realizar una revisión exhaustiva de los registros del Banco así como de los registros contables de COPOSA. Al terminar la operación, el Analista recibe información de la conciliación efectuada. Referencias Cruzadas Caso de uso: el Analista debe haber terminado el caso de uso: Identificar 88 Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se carga la hora y fecha del sistema cuando operativo. un Analista necesita realizar la conciliación del dinero Se verifica los permisos y restricciones de que se encuentra registrado en esta identificación de usuario en el sistema. las Cuentas Bancarias contra los registros contables de los Libros Se presenta una pantalla que ofrece diferentes opciones, entre ellas la de de la empresa. Desaplicar. 3. El Analista determina si los 4. Si el movimiento de registro del Banco y movimientos de registros del un movimiento de registro contable de Libro Banco contra los movimientos de pertenecen a la misma entidad financiera, los registros contables de los cuenta y tienen la misma referencia, el Libros, comparando para ello en sistema los cruza y muestra si tienen el el sistema de conciliación el monto igual o si existe una diferencia en el Banco, la Cuenta, la Referencia y mismo; en caso no poseer el mismo Monto, el Monto. el Analista puede decidir si cruzarlo o no. 5. El Analista decide entre las opciones que le ofrece el sistema de conciliación, escoge la que permita efectuar un cruce más efectivo entre los registros bancarios y los registros de los Libros de la empresa, para esto 89 dispone: a) Si realiza la conciliación de un movimiento registrado en Libro contra un movimiento registrado en Banco comparando el número de cuenta, tipo de movimiento y referencia, la iniciar Conciliación Cuenta. b) Si realiza la conciliación de un movimiento registrado en Libro contra un movimiento registrado en Banco tomando en cuenta el número bancaria, de tipo cuenta de movimiento y el monto, iniciar Conciliación Movimiento. 6. Actualiza el estatus de la conciliación generada. Cursos alternos de los eventos Sección 3: se busca un registro contable no existente, o se busca un Banco inexistente. Sección 5: el Analista no pudo realizar la Conciliación por los tipos que 90 permite el sistema de Conciliación General. Casos de usos relacionados usa Conciliación Cuenta. usa Conciliación Movimiento. Figura Nº 4.16 Caso de Uso Desaplicar Caso de Uso: Conciliación Cuenta Actores: Analista, Usuario Resumen: El Analista contable necesita desaplicar la conciliación efectuadas a las Cuentas Bancarias, en periodo determinado y a una 91 cuenta en específico. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Desaplicar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. El sistema muestra el periodo, Banco y cuando un Analista considera cuenta a la que se va a desaplicar. necesario conciliación modificar efectuada la a las Cuentas Bancarias. 3. El Analista selecciona las 4. Se genera desaplicar la conciliación Cuentas Bancarias a desaplicar. cuenta. Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. Cursos alternos de los eventos Sección 2: el periodo, el Banco o la cuenta no existen o son erróneos. Puede cancelarse desaplicar la conciliación cuenta o iniciar otro tipo de Desaplicar. 92 Figura Nº 4.17 Caso de Uso Conciliación Cuenta Caso de Uso: Conciliación Movimiento Actores: Analista, Usuario Resumen: El Analista contable necesita desaplicar la conciliación a una referencia en una Cuenta Bancaria, para esto solo cruza dos movimientos de la conciliación. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Desaplicar Curso normal de los eventos Acción del actor 1. Este caso de uso comienza Respuesta del sistema 2. El sistema muestra el Banco, periodo, 93 cuando un Analista considera cuenta, referencia, información en Libro e necesario información en Banco. modificar la conciliación efectuada a una Cuenta Bancaria. 3. El Analista selecciona la 4. Se genera desaplicar la conciliación referencia movimiento. de las Cuentas Bancarias a desaplicar. Se actualiza la base de datos sobre las Conciliaciones efectuadas por el sistema. Cursos alternos de los eventos Sección 2: el Banco, el periodo, la cuenta o la referencia no existen o son erróneos. Puede cancelarse desaplicar la conciliación movimiento o iniciar otro tipo de Desaplicar. Figura Nº 4.18 Caso de Uso Conciliación Movimiento 94 Caso de Uso: Importar Actores: Analista, Usuario Propósito: Introducir los datos que permitirán realizar la Conciliación de las Cuentas Bancarias contra los libros contables de COPOSA. El Analista contable necesita alimentar al Resumen: sistema con los movimientos cargados en Libro y los movimientos presentados por cada Banco en sus estados de cuenta. Caso de uso: el Analista debe haber Referencias Cruzadas terminado el caso de uso: Identificar Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se carga la hora y fecha del sistema cuando operativo. un Analista necesita cargar los datos para efectuar la conciliación de las Cuentas Se verifica los permisos y restricciones de esta identificación de usuario en el sistema. Bancarias contra los registros contables de los Libros de la empresa. Se presenta una pantalla que ofrece diferentes opciones, entre ellas la de Importar. 3. El Analista decide entre las opciones que le ofrece el sistema de conciliación, escoge la que permita cargar la información, 95 para esto dispone: a) Si introduce los datos y se toman en cuenta todas las Cuentas Bancarias asociadas al Banco entonces, iniciar Datos Banco. b) Si introduce los datos a los Libros entonces, de la iniciar empresa Datos Libro. 6. Actualiza la base de datos. Cursos alternos de los eventos Sección 3: el Analista no pudo importar los datos al sistema de Conciliación General, por errores en el formato de los datos a introducir. Casos de usos relacionados usa Datos Banco. usa Datos Libro. 96 Figura Nº 4.19 Caso de Uso Importar 97 Caso de Uso: Datos Banco Actores: Analista, Usuario Propósito: Introducir los datos de las Cuentas Bancarias. El Analista contable carga la base de datos Resumen: de los Estados de Cuenta de cada Banco, los que se son previamente construidos en archivos de Excel, a partir de los Estados de Cuentas descargados de Internet por el área de Tesorería. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Importar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando el Analista debe convertir visualiza el Banco, el total de movimientos y todos los Estados de Cuenta de la cada Bancarios. uno de los Bancos (suministrado por el área de Tesorería) a un formato de archivo de Excel con un orden estricto en las columnas, el cual es el siguiente: ¾ Banco: número asignado por informática al Banco. ¾ Cuenta: número de cuenta, 98 descripción de los movimientos su estructura es de 20 dígitos. ¾ Fecha: fecha del Movimiento, la que se presenta en el estado de cuenta. No estructura hay una definida para este campo, ya que cada Banco le da un formato particular a la fecha. ¾ Referencia: número que identifica al movimiento en el estado de cuenta, en casi todos los tipos de Movimientos es la que se presenta en el estado de cuenta, sólo en el caso de ciertos Movimientos el analista es el que asigna la Referencia al Movimiento al momento de construir el archivo en Excel, ejemplos de estos son: 1. La Comisión de Banco se utiliza el estándar de COM + los tres últimos dígitos del número de la cuenta a la que 99 pertenece la comisión. 2. IDB se utiliza el estándar de IDB + los tres últimos dígitos del número de la cuenta a la que pertenece el IDB. 3. Notas de Debitos Transcritas en Libro AP que no tienen referencia, a nivel de Libro se deja la que genera el sistema automáticamente. El área de cuentas por pagar emite un listado con todas estas Notas de Debito con la referencia asignada, y lo entrega al analista de contabilidad, para que este asigne las mismas referencias al estado de cuenta en el archivo de Excel. 4. Transferencias sin referencias en el estado de cuenta (caso Banco 100 Banesco), el analista asigna un correlativo de cinco dígitos comenzando con 1 y completando con ceros a la izquierda como sea necesario. ¾ Monto: monto en bolívares del movimiento según el estado de cuenta. ¾ TT: tipo de movimiento, este campo lo asigna el analista tomando en cuenta la para clasificación cada definida tipo de movimiento en Banco. ¾ Periodo: mes y año al que pertenece el movimiento, sigue el mismo estándar que en Libro. 3. El Analista verifica que los 4. En el caso que se estén importando los movimientos sean correctos. datos de Banco de un determinado periodo y se encuentren dos movimientos con la misma referencia y de la misma fuente el sistema pregunta si desea importarlos, es decir, cargar a la base de datos los dos Movimientos, esto para evitar que haya 101 duplicación de un mismo movimiento; además los dos movimientos deben ser del mismo tipo, pero pueden tener montos iguales o diferentes. En este caso el analista decide si cargar o no, luego de verificar si hay dos movimientos del mismo tipo, de la misma cuenta de Banco, con la misma referencia o porque se haya duplicado un movimiento en el archivo de Excel, es importante tener presente que pueden ser más de dos movimientos con la misma referencia Cursos alternos de los eventos Sección 3: el Analista observa errores en los datos introducidos al sistema. Figura Nº 4.20 Caso de Uso Datos Banco 102 Caso de Uso: Datos Libro Actores: Analista, Usuario Propósito: Introducir los datos en los movimientos en los Libros de la empresa. El Analista contable carga la base de datos Resumen: los movimientos de cada Libro, los que se son previamente construidos en archivos de Excel. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Importar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta un menú de opciones donde se cuando necesita visualiza Datos Libro AP, Datos Libro AR, cargar los datos de los Libros de Datos Libro GL, Datos No Aplicados y la empresa. Datos a Libro desde Archivo. un Analista Los datos de cada movimiento en Libro que se importan son los siguientes: ¾ Periodo: representa el mes y el año al que pertenece el movimiento. Su estructura es la siguiente Año (4 dígitos) + Mes (2 dígitos). ¾ Fecha: fecha contable en 103 que se registro el movimiento en Libro, su estructura es de Día (2 dígitos) / Mes (2 dígitos) / Año (2 dígitos). ¾ Cuenta: número de cuenta de Banco a la que pertenece el movimiento en Libro, su estructura es de 20 dígitos. ¾ Referencia: número que identifica al documento en Libro, número de deposito, número de cheque o del tipo de de Movimiento al que corresponda, en caso de aquellos movimientos que no tienen Referencia se carga en Libro la fecha como Referencia del número de mismo. ¾ Voucher: voucher del cheque, sólo se aplica a los cheques en Libro AP. ¾ Monto: movimiento monto cargado del en Libro. 104 ¾ Divisa: unidad monetaria en que se encuentra el monto del Libro, puede ser VEB o USD. ¾ Tipo: tipo de movimiento, si es deposito, cheque, etc. ¾ Cliente: proveedor al que se emite el cheque, sólo se aplica a cheques en Libro AP. ¾ Sucursal: aplica sólo a movimientos en Libro AR, representa la sucursal que cargo el movimiento. En el caso de AP y GL la sucursal siempre es “Planta Principal”. 3. El Analista decide entre las 4. El proceso de Importar Datos es por opciones que le ofrece el sistema periodo, el analista debe seleccionar el de conciliación, escoge la que periodo a importar, sólo se puede Importar permita cargar la información en datos de un periodo si ya se ha realizado el el Libro correcto, para esto cierre en cada uno de los auxiliares: AR, AP, dispone: GL; además si un periodo ya fue conciliado a) por el sistema, este no permite volver a Si introduce los datos en el Libro AP entonces, iniciar Datos Libro AP. b) Importar Datos del Libro pertenecientes a este periodo. Si introduce los datos en el 105 Libro AR entonces, iniciar Datos Libro AR. c) Si introduce los datos en el Libro GL entonces, iniciar Datos Libro GL. d) Si introduce los datos que fueron aplicados en un Libro al que correspondían iniciar no entonces, Datos No Aplicados. e) Si introduce los datos en el Libro AP entonces, iniciar Datos a Libro desde Archivo. 5. El analista puede realizar el proceso de importación de Datos de Libro cada vez que quiera y no existe duplicación de Movimientos. Casos de usos relacionados usa Datos Libro AP. usa Datos Libro AR. usa Datos Libro GL. usa Datos No Aplicado. 106 usa Datos a Libro desde Archivo. Caso de Uso: Libro AP Actores: Analista, Usuario Propósito: Introducir los datos en los movimientos en el Libro AP de la empresa. El Analista contable carga la base de datos Resumen: los movimientos del Libro AP, los que se son previamente construidos en archivos de Excel. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Datos Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando mostrara el periodo, cheques y depósitos, un Analista necesita cargar los datos para el Libro presentes en el Libro AP. AP. Los movimientos en Libro AP que se importan los cheques (CH), Notas de Debito (ND) y Depósitos (DP) que corresponden a pagos de un 107 proveedor y reintegro de reporte de gastos. 3. El Analista verifica que los movimientos en Libro AP sean correctos. Cursos alternos de los eventos Sección 3: el Analista no pudo importar los datos al sistema de Conciliación General, por errores en el formato de los datos a introducir. Figura Nº 4.21 Caso de Uso Libro AP 108 Caso de Uso: Libro AR Actores: Analista, Usuario Propósito: Introducir los datos en los movimientos en el Libro AR de la empresa. El Analista contable carga la base de datos Resumen: los movimientos del Libro AR, los que se son previamente construidos en archivos de Excel. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Datos Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando necesita mostrara el periodo, depósitos y notas de cargar los datos para el Libro debito por cheques devueltos, presentes en el AR. Libro AR. un Analista Los movimientos en Libro AR que se importan son los depósitos (DP) y Notas de Debito por Cheques devueltos (NDC). 3. El Analista verifica que los movimientos en Libro AR sean correctos. 109 Cursos alternos de los eventos Sección 3: el Analista no pudo importar los datos al sistema de Conciliación General, por errores en el formato de los datos a introducir. Figura Nº 4.22 Caso de Uso Libro AR 110 Caso de Uso: Libro GL Actores: Analista, Usuario Propósito: Introducir los datos en los movimientos en el Libro GL de la empresa. El Analista contable carga la base de datos Resumen: los movimientos del Libro GL, los que se son previamente construidos en archivos de Excel. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Datos Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando mostrara la información de acuerdo al un Analista necesita cargar los datos para el Libro periodo presente en el Libro GL. GL. Los movimientos en Libro GL que se importan son Depósitos (DP), Notas de Crédito (NC) y Notas de Transferencia Crédito por (NCT) correspondientes a la recepción Cheques (CH), Nota de Debito (ND), Notas de Debito por Transferencia (NDT), 111 Comisiones (COM), Impuesto al Debito Bancario (IDB) correspondientes a los pagos. 3. El Analista verifica que los movimientos en Libro GL sean correctos. Cursos alternos de los eventos Sección 3: el Analista no pudo importar los datos al sistema de Conciliación General, por errores en el formato de los datos a introducir. Figura Nº 4.23 Caso de Uso Libro GL 112 Caso de Uso: Movimiento No Aplicado Actores: Analista, Usuario Propósito: Introducir los datos de los movimientos que no fueron cargados en los Libros de la empresa. El Analista contable registra movimientos en Resumen: Libro que afectan la conciliación. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Datos Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando mostrara el periodo y depósitos presentes. el Analista contable registra movimientos en Libro que por alguna razón no bajaron en los procesos de “Importar Libro”, pero que afectan la conciliación, por lo que es necesario tomarlos en cuenta en la misma. También puede ocurrir que se presenten movimientos mal aplicados en Libro, es decir, que al momento de ser registrados en Libro AR viajan al auxiliar pero 113 no quedan asociados a ninguna factura. 3. El Analista verifica que los movimientos en los Libros sean correctos. Cursos alternos de los eventos Sección 3: el Analista no pudo importar los datos al sistema de Conciliación General, por errores en el formato de los datos a introducir. Figura Nº 4.24 Caso de Uso Movimiento No Aplicado 114 Caso de Uso: Datos a Libro desde Archivo Actores: Analista, Usuario Propósito: Introducir los datos de los movimientos de los Libros de la empresa desde un archivo en Excel. El Analista contable necesita alimentar con Resumen: información los Libros de la empresa desde un archivo en Excel. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Datos Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando mostrara el Analista contable los movimientos de Libro necesita la información de los correspondientes a las referencias y montos movimientos en Libro que se de cada Libro presente. encuentran ubicados en el archivo en Excel que se desea importar. 3. El Analista verifica que los movimientos en los Libros sean correctos. Cursos alternos de los eventos Sección 3: el Analista no pudo importar los datos al sistema de Conciliación 115 General, por errores en archivo a cargar. Figura Nº 4.25 Caso de Uso Desde Archivo 116 Caso de Uso: Consultar Actores: Analista, Usuario. Propósito: Luego de importar los movimientos de un Banco, se debe verificar que el saldo Final del Banco en el Sistema sea igual al que muestra el Banco en su Estado de Cuenta Oficial. Para determinar que se han cargado correctamente los movimientos de un Banco se consulta los datos del mismo. El Analista contable consulta la base de Resumen: datos los movimientos de cada Libro y del Estado de Cuenta Bancario. Caso de uso: el Analista debe haber Referencias Cruzadas terminado el caso de uso: Identificar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta un menú de opciones donde se cuando visualiza Referencia en Libro y Estado de un Analista necesita consultar los datos de los Libros Cuenta. de la empresa y el Estado de Cuenta. 3. El Analista decide entre las opciones que le ofrece el sistema de conciliación, escoge la que permita consultar la información en el Libro y el Estado de 117 Cuenta, para esto dispone: a) Si consulta los datos en el Libro entonces, iniciar Referencia en Libro. b) Si consulta los datos del Estado de Cuenta entonces, iniciar Estado de Cuenta. 4. El analista puede consultar los datos de Libro y del Estado de Cuenta cada vez que quiera. Casos de usos relacionados usa Referencia en Libro. usa Estado de Cuenta. Figura Nº 4.26 Caso de Uso Consultar 118 Caso de Uso: Referencia en Libro Actores: Analista, Usuario. Propósito: Consultar los movimientos en los Libros que posee la empresa. El Analista contable consulta la base de Resumen: datos los movimientos de cada Libro. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Consultar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta un menú de opciones donde se cuando visualiza Referencia en AP, Referencia en un Analista necesita consultar los datos de los Libros AR y Referencia en GL. de la empresa. 3. El Analista decide entre las opciones que le ofrece el sistema de conciliación, escoge la que permita consultar la información en el Libro, para esto dispone: a) Si consulta los datos en el Libro AP entonces, iniciar Libro AP. b) Si consulta los datos en el Libro AR entonces, iniciar Libro AR. 119 c) Si consulta los datos en el Libro GL entonces, iniciar Libro GL. Casos de usos relacionados usa Libro AP. usa Libro AR. usa Libro GL. Figura Nº 4.27 Caso de Uso Referencia en Libro Caso de Uso: Estado de Cuenta Actores: Analista, Usuario. Propósito: Consultar los movimientos del Estado de 120 Cuenta Bancario de la empresa. El Analista contable consulta la base de Resumen: datos de los movimientos bancarios. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Consultar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde se cuando necesita visualiza periodo, Banco, cuenta, saldo consultar el Estado de Cuenta inicial, debe, haber, saldo final, además del Bancario de la empresa. total de: movimientos, depósitos, notas de un Analista crédito, cheques, notas de comisiones, IDB. Cursos alternos de los eventos Sección 2: el periodo, el Banco o la cuenta no existen o son erróneos. Figura Nº 4.28 Caso de Uso Estado de Cuenta 121 debito, Caso de Uso: Libro AP Actores: Analista, Usuario. Propósito: Consultar los movimientos del Libro AP de la empresa. El Resumen: Analista contable consulta los movimientos del Libro AP. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Referencia en Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde permite cuando efectuar la consulta a través de la referencia un Analista necesita consultar los movimientos del indicando el tipo de movimiento. Libro AP. Se visualizara en pantalla información en de los movimientos del Libro AP y del Banco. Cursos alternos de los eventos Sección 2: la referencia no existe o es errónea. 122 Figura Nº 4.29 Caso de Uso Libro AP Caso de Uso: Libro AR Actores: Analista, Usuario. Propósito: Consultar los movimientos del Libro AR de la empresa. Resumen: El Analista contable consulta los movimientos del Libro AR. Referencias Cruzadas Caso de uso: el Analista debe haber comenzado el caso de uso: Referencia en Libro. 123 Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde permite cuando efectuar la consulta a través de la referencia un Analista necesita consultar los movimientos del indicando el tipo de movimiento. Libro AR. Se visualizara en pantalla información en de los movimientos del Libro AR y del Banco. Cursos alternos de los eventos Sección 2: la referencia no existe o es errónea. Figura Nº 4.30 Caso de Uso Libro AR 124 Caso de Uso: Libro GL Actores: Analista, Usuario. Propósito: Consultar los movimientos del Libro GL de la empresa. El Resumen: Analista contable consulta los movimientos del Libro GL. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Referencia en Libro. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde permite cuando efectuar la consulta a través de la referencia. un Analista necesita consultar los movimientos del Libro GL. Se visualizara en pantalla información en de los movimientos del Libro GL y del Banco. Cursos alternos de los eventos Sección 2: la referencia no existe o es errónea. 125 Figura Nº 4.31 Caso de Uso Libro GL 126 Caso de Uso: Registrar Actores: Analista, Usuario. Propósito: El Analista necesita incluir una Cuenta Bancaria, registrar un movimiento en Libro y registrar un movimiento en Banco. El Analista contable a través de la consulta Resumen: efectuada a los movimientos de Libro y de Banco y del Estado de Cuenta Bancaria considera introducir nuevos movimientos. Caso de uso: el Analista debe haber Referencias Cruzadas terminado el caso de uso: Identificar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta un menú de opciones donde se cuando visualiza Cuenta Bancaria, Movimiento en registrar un Analista una necesita nueva Cuenta Banco y Movimiento en Libro. Bancaria, un movimiento en Libro o uno en Banco. 3. El Analista decide entre las 4. Se actualiza la base de datos del sistema. opciones que le ofrece el sistema de conciliación, para esto dispone: a) Si registra una nueva Cuenta Bancaria entonces, iniciar Cuenta Bancaria. 127 b) Si registra un nuevo movimiento en Banco entonces, iniciar Movimiento en Banco. c) Si registra un nuevo movimiento en Libro entonces, iniciar Movimiento en Libro. Casos de usos relacionados usa Cuenta Bancaria. usa Movimiento en Banco. usa Movimiento en Libro. Figura Nº 4.32 Caso de Uso Registrar 128 Caso de Uso: Cuenta Bancaria Actores: Analista, Usuario. Propósito: El Analista necesita incluir una Cuenta Bancaria. El Analista contable a través de la consulta Resumen: efectuada Estado de Cuenta Bancaria considera introducir una nueva Cuenta Bancaria. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Registrar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde el Usuario cuando puede introducir el código de Banco, el registrar un Analista una nueva necesita Cuenta nombre del Banco y la Cuenta. Bancaria. 3. El Analista suministrada la información solicitada por el sistema. Cursos alternos de los eventos Sección 3: la Cuenta Bancaria introducida ya existe. 129 Figura Nº 4.33 Caso de Uso Cuenta Bancaria Caso de Uso: Movimiento en Banco Actores: Analista, Usuario. Propósito: El Analista necesita incluir un nuevo movimiento en Banco. Resumen: El Analista contable a través de la consulta efectuada al Estado de la Cuenta Bancaria considera necesario introducir un nuevo movimiento en Banco. Referencias Cruzadas Caso de uso: el Analista debe haber comenzado el caso de uso: Registrar. 130 Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde el Usuario cuando necesita puede introducir la fecha, referencia y registrar un nuevo movimiento monto; esto luego de seleccionar el Banco, en Banco. Cuenta y periodo. un Analista 3. El Analista suministrada la información solicitada por el sistema. Figura Nº 4.34 Caso de Uso Movimiento en Banco 131 Caso de Uso: Movimiento en Libro Actores: Analista, Usuario. Propósito: El Analista necesita incluir un nuevo movimiento en Libro. El Analista contable a través de la consulta Resumen: efectuada Estado considera en de Cuenta introducir Bancaria un nuevo movimiento en Libro. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Registrar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde el Usuario cuando necesita puede introducir la fecha, referencia, monto registrar un nuevo movimiento y observaciones; esto luego de seleccionar el en Libro. Banco, Cuenta, periodo y Libro. un Analista 3. El Analista suministrada la información solicitada por el sistema. 132 Figura Nº 4.35 Caso de Uso Movimiento en Libro 133 Caso de Uso: Configurar Tasa de Cambio Actores: Analista, Usuario. Propósito: El Analista necesita modificar el precio de las divisas que maneja el sistema. El Analista contable se ve obligado a Resumen: cambiar el precio de la tasa de cambio. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Identificar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. La tasa de cambio es un valor que trae cuando automáticamente el sistema, pero es editable un Analista necesita variar la tasa de cambio. para que el analista tenga la posibilidad de cambiarla cuando sea necesario, por esta razón se presenta una pantalla donde el Usuario puede introducir la tasa de cambio y la variación o diferencia que esta representa. Además permite editar el nombre de la divisa legal de Venezuela, y también la usada en el plano internacional. 3. El Analista suministrada la 4. Las divisas registradas en los información solicitada por el movimientos de Banco están expresadas en sistema. la moneda legal de Venezuela que es el bolívar (VEB). Las divisas de los montos en Libros están en 134 bolívares (VEB) y dólares (USD). Para realizar la conciliación de los movimientos en Libro cuya divisa sea USD, se debe multiplicar el monto del movimiento por la tasa de cambio vigente. Figura Nº 4.36 Caso de Uso Configurar Tasa de Cambio 135 Caso de Uso: Reportes Actores: Analista, Usuario. Propósito: El Analista necesita imprimir los resultados de la Conciliación. El Analista contable imprime la conciliación Resumen: generada para verificar que todo se encuentre correcto. Caso de uso: el Analista debe haber Referencias Cruzadas comenzado el caso de uso: Identificar. Curso normal de los eventos Acción del actor Respuesta del sistema 1. Este caso de uso comienza 2. Se presenta una pantalla donde el Usuario cuando puede seleccionar el periodo, Banco y el Analista necesita imprimir el resultado de la cuenta. conciliación Se visualiza el reporte según los parámetros generada, para buscar posibles fallas o errores. escogidos y puede ser impreso en papel. 3. El Analista suministrada la 4. Es impreso en papel el reporte según los información solicitada por el parámetros escogidos. sistema y puede indicar que se imprima el reporte en pantalla. Cursos alternos de los eventos Sección 4: la impresora no esta encendida, tiene papel atascado o no existe suficiente papel en la bandeja de alimentación de la impresora. 136 Figura Nº 4.37 Caso de Uso Reportes El diagrama de Casos de Usos resulta entonces de ser la combinación de: 1) Identificar. 2) Conciliar. 3) Desaplicar. 4) Importar. 5) Consultar. 6) Registrar. 7) Configurar Tasa de Cambio. 8) Reportes. 137 Figura Nº 4.38 Diagrama de Casos de Uso 138 Los Diagramas de Secuencia son los siguientes: Figura Nº 4.39 Diagrama de Secuencia Identificar 139 Figura Nº 4.40 Diagrama de Secuencia Conciliar 140 Figura Nº 4.41 Diagrama de Secuencia Desaplicar 141 Figura Nº 4.42 Diagrama de Secuencia Importar 142 Figura Nº 4.43 Diagrama de Secuencia Consultar 143 Figura Nº 4.44 Diagrama de Secuencia Registrar 144 Figura Nº 4.44 Diagrama de Clases 145 Pruebas de la Solución Se efectuaron las pruebas de la documentación por parte de los desarrolladores del Sistema de Conciliación establecido por la Gerencia de Informática de COPOSA, el resultado es satisfactorio, además, de las ventajas que posee el modelado visual y los Casos de Usos, cuya propiedad y mayor ventaja es evitar la ambigüedad en el desarrollo de los sistemas de información. El Proceso Unificado de Desarrollo de Software como metodología es de muchísima utilidad por ser iterativa e incremental, el acercamiento de dicha metodología en la Documentación del Sistema de Conciliación permitirá estandarizar el desarrollo de la documentación de los sistemas de información restantes de la empresa. 146 Conclusiones y Recomendaciones La documentación de sistemas, es el conjunto de información donde se describe qué hacen los sistemas, cómo lo hacen y para quién lo hacen. En otras palabras, la documentación consiste en material que explica las características técnicas y operativas del sistema de información. Es esencial para proporcionar entendimiento del sistema a quien lo vaya a usar, para mantenerlo, permitir la auditoria del mismo, y enseñar a los usuarios como hacerlo funcionar e interactuar con el. La documentación de los sistemas de información tiene una gran importancia dentro de la Gerencia de Informática de COPOSA, y de cualquier empresa en general, porque esta ayuda a eliminar la posible dependencia que se pueda formar entre la aplicación o software realizado, y el diseñador de ésta. Luego de realizar el diagnostico de la situación actual de la documentación, así como los estándares referentes a los requerimientos, análisis, diseño, codificación, prueba y mantenimiento del Sistema de Conciliación General, se identifico la necesidad de documentar dicho sistema, a través del Proceso Unificado del Desarrollo del Software, por el cual se determinaron los artefactos. Gracias al desarrollo iterativo e incremental se logro desarrollar los anteriores artefactos compuestos por los Casos de Uso, Diagramas de Casos de Uso, Diagrama de Secuencia y Diagramas de Clases. Esto permitió el desarrollo de la documentación del Sistema de Conciliación General y la posterior implementación de dicha documentación. Esto se evidencia con la entrega a la Gerencia de Informática de COPOSA de los archivos fuentes escritos en el Help & Manual: Conciliación y ManualProgramador, así como los archivos ejecutables compilados por el mismo programa; también se proporcionó el archivo fuente escrito en ArgoUml: sistema.uml donde se encuentran los artefactos utilizados para la documentación del Sistema de Conciliación General. 147 Considerando la importancia del modelado visual, a través del UML, y de la metodología aplicada que no es otra sino el Proceso Unificado de Desarrollo del Software en el desarrollo de la Documentación del Sistema de Conciliación, y en general de los sistemas de información de la empresa COPOSA, se recomienda los siguientes aspectos: 9 Nombrar un responsable dentro de la Gerencia de Informática de COPOSA que se encargue de instalar la aplicación. 9 Estandarizar y constituir como norma la documentación de los sistemas de información, además de los responsables del desarrollo, así como los cambios que han de efectuarse sobre dichos sistemas. 9 Instar a la Gerencia de Informática de COPOSA en la búsqueda de herramientas que permitan diseñar los diagramas del UML, que presenten amplio soporte técnico, cuyos errores o fallas sean leves y no sean tan gravísimas como la que concierne a la apertura o recuperación del archivo. 148 Referencias Bibliográficas ARGOUML. URL: http://www.argouml.tigris.org [Consulta: Marzo 7, 2007]. Booch, Jacobson y Rumbaugh (2004). El Proceso Unificado de Desarrollo de Software. Prentice Hall, Madrid, España. HELP & MANUAL. URL: http://www.ec-software.com/ [Consulta: Marzo 15, 2007]. Larman, C (1999). UML y Patrones. Introducción al análisis y diseño orientado a objetos. Prentice Hall, México DF, México. OBJECT MANAGEMENT GROUP. URL: http://www.omg.org [Consulta: Enero 15, 2007]. Pressman, R (2005). Ingeniería del Software. Un enfoque practico. Sexta Edición. McGraw-Hill, México DF, México. RATIONAL. URL: http://www.rational.com [Consulta: Diciembre 10, 2006]. Schach, S (2005). Análisis y Diseño Orientado a Objetos con UML y el Proceso Unificado. McGraw-Hill, México DF, México. Tamayo, M (2001). El Proceso de la Investigación Científica. Editorial Limusa, México DF, México. UML RESOURCE PAGE. URL: http://www.omg.org/uml/ [Consulta: Febrero 5, 2007]. Universidad Nacional Abierta (2000). Análisis y Diseño de Sistemas. Caracas, Venezuela. Universidad Nacional Abierta (2000). Manual de Proyecto de Grado. Caracas, Venezuela. 149 150