Texto - Universidad Nacional Abierta

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