MANUAL DE USUARIO DEL SISTEMA 000
Transcript of MANUAL DE USUARIO DEL SISTEMA 000
UNUVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
ANÁLISIS, DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA
EL CONTROL DE PROCESOS ADMINISTRATIVOS PARA LA MEJORA DE
LA PRODUCTIVIDAD DE TECNOGALAXY CIA. LTDA.
TRABAJO DE GRADUACIÓNN PREVIO A LA OBTENCIÓN DEL TÍTULO
DE INGENIERO INFORMÁTICO
AUTOR: WILLIAM MAURICIO PATIÑO VILLAVICENCIO
TUTOR: ING. MAURO LEONARDO ROSAS LARA
QUITO - ECUADOR
2015
ii
DEDICATORIA
Dedico mi trabajo de tesis a Dios por iluminarme en momentos difíciles y por darme la fuerza
para alcanzar mis objetivos y principalmente por ayudarme a lograr una de mis principales
metas que es la graduación de ingeniero informático.
A mis padres Saúl Ángel Patiño y María Arcelia Villavicencio por el apoyo incondicional que
he recibido de ellos en todos los aspectos de mi vida, en especial durante mi formación
profesional en la universidad, por sus buenos consejos, orientación y motivación permanente
para lograr alcanzar mis sueños.
A mi prometida por haber llegado a mi vida y ayudarme a enfrentar nuevos retos y apoyarme
con un buen consejo. A mis hermanos por su amistad, consejos y apoyo ya que con ellos hemos
cruzado grandes obstáculos en nuestras vidas que hemos sabido enfrentarlas.
A mi Universidad Central del Ecuador, en especial a la Facultad de Ingeniería Ciencias Físicas y
matemáticas porque fue mi templo de aprendizaje y éxitos.
iii
AGRADECIMIENTO
Agradezco a dios por haberme iluminado y darme la sabiduría para alcanzar grandes logros y
éste es uno de ellos, el poder graduarme de Ingeniero Informático que me ha dado grandes
alegrías y satisfacciones en el ámbito profesional.
A mis padres Saúl Ángel Patiño y María Arcelia Villavicencio que supieron darme la fuerza, la
motivación y el apoyo incondicional para alcanzar mis objetivos.
A mis hermanos por todo su apoyo en momentos difíciles, por su amistad y buenos deseos para
lograr mis metas tan anheladas.
A mis compañeros de la universidad por haber compartido un sin número de conocimientos,
experiencias y principalmente por su amistad que todavía la tenemos y la seguiremos
cultivando.
A mi tutor el Ingeniero Mauro Rosas por guiarme y orientarme en el desarrollo de mi tesis y
apoyarme para poder finalizarla. A mis revisores por apoyar el desarrollo de mi tema de tesis y
su orientación para lograr finalizarla con éxito.
iv
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, Patiño Villavicencio William Mauricio en calidad de autor del trabajo de investigación o
tesis realizada sobre el ANÁLISIS, DESARROLLO E IMPLEMENTACIÓN DE UN
SISTEMA PARA EL CONTROL DE PROCESOS ADMINISTRATIVOS PARA LA
MEJORA DE LA PRODUCTIVIDAD DE TECNOGALAXY CIA. LTDA., hacer uso de todos
los contenidos que me pertenecen o de parte de los que contiene esta obra, con fines
estrictamente académicos o de investigación.
Los derechos que como autor me corresponden, con excepción de la presente autorización,
seguirán vigentes a mi favor, de conformidad con lo establecido en los artículos 5, 6, 8, 19 y
demás pertinentes de la Ley de Propiedad Intelectual y su Reglamento.
Quito, 15 de Marzo del 2015
William Mauricio Patiño Villavicencio
1716277874
v
CERTIFICACIÓN
En calidad del Tutor del proyecto de Investigación: ANÁLISIS, DESARROLLO E
IMPLEMENTACIÓN DE UN SISTEMA PARA EL CONTROL DE PROCESOS
ADMINISTRATIVOS PARA LA MEJORA DE LA PRODUCTIVIDAD DE
TECNOGALAXY CIA. LTDA., presentado y desarrollado por el señor: Patiño Villavicencio
William Mauricio, previo a la obtención del Título de Ingeniero Informático, considero que el
proyecto reúne los requisitos necesarios.
Quito, 15 de Marzo del 2015.
vi
INFORME SOBRE CULMINACIÓN Y APROBACIÓN DE TESIS
Quito, DM 11 de Mayo del 2015
Señor Ingeniero
Boris Herrera
DIRECTOR DE LA CARRERA DE INGENIERÍA INFORMÁTICA
Presente.-
Señor Director:
Yo, Mauro Leonardo Rosas Lara, Docente de la Carrera de Ingeniería Informática, de la
Facultad de Ingeniería Ciencias Físicas y Matemáticas de la Universidad Central del
Ecuador y en calidad de tutor.
Certifico
Luego de las revisiones técnicas realizadas por mi persona al proyecto de investigación
“ANÁLISIS, DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA EL
CONTROL DE PROCESOS ADMINISTRATIVOS PARA LA MEJORA DE LA
PRODUCTIVIDAD DE TECNOGALAXY CIA. LTDA.” llevando a cabo por parte del
egresado de la Carrera de Ingeniería Informática, señor William Mauricio Patiño
Villavicencio, con CC. 1716277874 ha concluido de manera exitosa, consecuentemente el
indicado egresado podrá continuar con los trámites de graduación correspondientes de
acuerdo a lo que estipula las normativas y direcciones legales.
Por la atención que digne al presente, reitero mi agradecimiento.
Atentamente
vii
viii
ix
CONTENIDO
DEDICATORIA ............................................................................................................ II
AGRADECIMIENTO .................................................................................................. III
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ......................................... IV
CERTIFICACIÓN ......................................................................................................... V
CONTENIDO ............................................................................................................... IX
LISTA DE TABLAS....................................................................................................XII
LISTA DE GRÁFICOS ............................................................................................ XIII
RESUMEN ................................................................................................................... XV
ABSTRACT ............................................................................................................... XVI
CERTIFICACIÓN DE TRADUCCIÓN ................................................................ XVII
CAPÍTULO 1 .............................................................................................................. - 1 -
1. PRESENTACIÓN DEL PROBLEMA ................................................................................ - 1 - 1.1. Planteamiento del problema .............................................................................................. - 1 -
1.2. Formulación del problema ................................................................................................ - 1 - 1.2.1. Objetivo general .......................................................................................................................... - 2 - 1.2.2. Objetivos específicos ................................................................................................................... - 2 -
1.3. Justificación del problema................................................................................................. - 2 -
1.4. Alcance y limitaciones ....................................................................................................... - 3 - 1.4.1. Alcance ......................................................................................................................................... - 3 -
1.4.1.1. Módulo de seguridades ...................................................................................................... - 3 - 1.4.1.2. Módulo de configuración técnica ..................................................................................... - 4 - 1.4.1.3. Módulo de parámetros del sistema................................................................................... - 5 - 1.4.1.4. Módulo de almacén............................................................................................................ - 6 - 1.4.1.5. Módulo de personas ........................................................................................................... - 8 -
1.4.2. Limitaciones ................................................................................................................................. - 8 - 1.5. Esquema de solución ....................................................................................................... - 10 -
1.6. Arquitectura ..................................................................................................................... - 10 - 1.6.1. Plataforma ................................................................................................................................. - 12 - 1.6.2. Herramientas de desarrollo ...................................................................................................... - 19 -
CAPÍTULO 2 ............................................................................................................ - 21 -
2. METODOLOGÍA ............................................................................................................... - 21 - 2.1. Antecedentes .................................................................................................................... - 21 -
2.2. Metodología de investigación .......................................................................................... - 21 -
2.3. Metodología SCRUM ....................................................................................................... - 21 - 2.3.1. Objetivo de Scrum .................................................................................................................... - 24 - 2.3.2. Componentes del proceso Scrum ............................................................................................. - 24 - 2.3.3. Roles ........................................................................................................................................... - 25 -
2.4. Marco teórico ................................................................................................................... - 25 -
2.5. Metodología de desarrollo ............................................................................................... - 25 - 2.5.1. Programación extrema (XP) .................................................................................................... - 25 - 2.5.2. Diseño incremental .................................................................................................................... - 26 - 2.5.3. Integración continua ................................................................................................................. - 26 -
x
2.5.4. Estandarización de código ........................................................................................................ - 26 - 2.5.5. Ritmo sostenible / Trabajo enérgico ........................................................................................ - 26 - 2.5.6. Fase de pruebas ......................................................................................................................... - 26 -
CAPÍTULO 3 ............................................................................................................ - 28 -
3. DESARROLLO .................................................................................................................. - 28 - 3.1. Requerimientos o pila de productos (Product backlog) .................................................. - 28 -
3.1.1. Requerimientos funcionales ..................................................................................................... - 28 - 3.1.2. Requerimientos no funcionales ................................................................................................ - 29 - 3.1.3. Requerimientos o pila de productos ........................................................................................ - 29 - 3.1.4. Pila de productos en módulos ................................................................................................... - 31 - 3.1.5. Organización de trabajo ........................................................................................................... - 33 -
3.2. Planificación de iteraciones o Sprints ............................................................................. - 34 -
3.3. Planificación Sprint - 1 ................................................................................................... - 35 - 3.3.1. Tareas Sprint 1 .......................................................................................................................... - 35 - 3.3.2. Implementación ......................................................................................................................... - 37 -
3.3.2.1. Instalación y configuración de herramientas de desarrollo ......................................... - 37 - 3.3.2.2. Instalación y configuración de servidores...................................................................... - 38 - 3.3.2.3. Configuración del front-end y back-end. ....................................................................... - 38 - 3.3.2.4. Definición del esquema de seguridades y generales. ..................................................... - 39 - 3.3.2.5. Transacciones para la configuración de seguridades ................................................... - 45 - 3.3.2.6. Transacciones para el mantenimiento de usuarios ....................................................... - 45 - 3.3.2.7. Definición del esquema de personas ............................................................................... - 46 - 3.3.2.8. Definición del esquema de parámetros de personas ..................................................... - 50 -
3.3.3. Evaluación ................................................................................................................................. - 50 - 3.3.4. Análisis del trabajo realizado. .................................................................................................. - 51 -
3.4. Planificación Sprint - 2 ................................................................................................... - 52 - 3.4.1. Tareas Sprint 2 .......................................................................................................................... - 52 - 3.4.2. Implementación ......................................................................................................................... - 54 -
3.4.2.1. Transacción de personas naturales ................................................................................ - 54 - 3.4.2.2. Transacción de personas jurídicas ................................................................................. - 54 - 3.4.2.3. Transacciones de parámetros de personas .................................................................... - 55 - 3.4.2.4. Transacciones de configuraciones técnicas .................................................................... - 55 - 3.4.2.5. Transacciones de comandos de negocio ......................................................................... - 56 - 3.4.2.6. Transacción de comandos de consulta ........................................................................... - 57 - 3.4.2.7. Transacción de comandos de mantenimiento ............................................................... - 57 - 3.4.2.8. Transacciones de parámetros del sistema ...................................................................... - 58 -
3.4.3. Evaluación ................................................................................................................................. - 59 - 3.4.4. Análisis del trabajo realizado ................................................................................................... - 59 -
3.5. Planificación Sprint - 3 ................................................................................................... - 61 - 3.5.1. Tareas Sprint 3 .......................................................................................................................... - 61 - 3.5.2. Implementación ......................................................................................................................... - 62 -
3.5.2.1. Modelo de procesos de productos en almacén ............................................................... - 63 - 3.5.2.2. Modelo de los procesos de facturación ........................................................................... - 64 - 3.5.2.3. Definición del esquema para los productos de almacén ............................................... - 64 - 3.5.2.4. Definición del esquema para facturación ...................................................................... - 66 - 3.5.2.5. Transacciones para registro de productos ..................................................................... - 67 - 3.5.2.6. Transacciones para movimientos de productos ............................................................ - 68 - 3.5.2.7. Transacciones para ingresos y salidas de productos ..................................................... - 69 - 3.5.2.8. Transacciones para la venta de productos ..................................................................... - 70 - 3.5.2.9. Transacción para órdenes de trabajo ............................................................................ - 71 - 3.5.2.10. Transacción para consulta de órdenes de trabajo ........................................................ - 72 -
3.5.3. Evaluación ................................................................................................................................. - 72 - 3.5.4. Análisis del trabajo realizado ................................................................................................... - 73 -
xi
CAPÍTULO 4 ............................................................................................................ - 74 -
4. PRUEBAS DEL SISTEMA ................................................................................................ - 74 - 4.1. Características del sistema............................................................................................... - 74 -
4.3. Pruebas de rendimiento ................................................................................................... - 76 -
4.4. Pruebas de carga.............................................................................................................. - 78 -
4.5. Prueba de rampa .............................................................................................................. - 79 -
4.6. Conclusiones y recomendaciones .................................................................................... - 81 - 4.6.1. Conclusiones .............................................................................................................................. - 81 - 4.6.2. Recomendaciones ...................................................................................................................... - 81 -
BIBLIOGRAFÍA ...................................................................................................... - 83 -
ANEXO 1 ................................................................................................................... - 85 -
5. MANUAL DE USUARIO ................................................................................................... - 85 -
ANEXO 2 ................................................................................................................. - 104 -
6. MANUAL TÉCNICO ....................................................................................................... - 104 -
xii
LISTA DE TABLAS
Tabla 1: Tabla de navegadores permitidos. ............................................................................................. - 9 -
Tabla 2: Tabla comparativa de lenguajes de programación web........................................................... - 11 -
Tabla 3: Características de implementaciones web para la capa de Front-end. .................................... - 13 -
Tabla 4: Características de las implementaciones JSF más utilizadas en desarrollo web ....................... - 14 -
Tabla 5: Comparativa ente las plataformas a utilizar para la capa de back - en ................................... - 15 -
Tabla 6: Características entre bases de datos relacionales más usadas. ............................................... - 16 -
Tabla 7: Características entre repositorios WEB de reportes. ................................................................ - 17 -
Tabla 8: Características entre diseñadores de reportes. ........................................................................ - 18 -
Tabla 9: Requisitos de software para desarrollo. ................................................................................... - 19 -
Tabla 10: Requisitos de hardware para la aplicación. ............................................................................ - 20 -
Tabla 11: Tabla comparativa de metodologías ágiles y tradicionales. .................................................. - 22 -
Tabla 12: Pila de productos descritos en forma general por el cliente. .................................................. - 30 -
Tabla 13: Requerimientos y estimación por parte del equipo técnico y cliente. .................................... - 33 -
Tabla 14: Planificación Sprint 1. ............................................................................................................. - 36 -
Tabla 15: Transacciones de configuración de seguridades. ................................................................... - 45 -
Tabla 16: Transacciones de usuarios. ..................................................................................................... - 46 -
Tabla 17: Planificación Sprint 2. ............................................................................................................. - 53 -
Tabla 18: Transacción de personas naturales. ....................................................................................... - 54 -
Tabla 19: Transacción de personas jurídicas. ......................................................................................... - 55 -
Tabla 20: Transacciones de parámetros de personas. ........................................................................... - 55 -
Tabla 21: Transacciones de configuraciones técnicas generales. ........................................................... - 56 -
Tabla 22: Transacción de comandos de negocio. ................................................................................... - 57 -
Tabla 23: Transacción de comandos de consulta. .................................................................................. - 57 -
Tabla 24: Transacción de comandos de mantenimiento. ....................................................................... - 58 -
Tabla 25: Transacciones de parámetros del sistema. ............................................................................. - 59 -
Tabla 26: Planificación Sprint 3. ............................................................................................................. - 62 -
Tabla 27: Transacciones de productos. .................................................................................................. - 68 -
Tabla 28: Transacciones de movimiento de productos........................................................................... - 69 -
Tabla 29: Transacciones de Ingresos/ Salidas de productos................................................................... - 70 -
Tabla 30: Transacciones de ventas de productos. .................................................................................. - 70 -
Tabla 31: Transacción de órdenes de trabajo. ........................................................................................ - 72 -
Tabla 32: Transacción de consulta de órdenes. ...................................................................................... - 72 -
Tabla 33: Tabla de escenarios para las pruebas de la aplicación. .......................................................... - 74 -
xiii
LISTA DE GRÁFICOS
Figura 1: Esquema general de la aplicación. .......................................................................................... - 10 -
Figura 2: Arquitectura de la aplicación bajo la plataforma JEE .............................................................. - 12 -
Figura 3: Ciclo de vida iterativo e incremental en el proyecto ................................................................ - 23 -
Figura 4: Iteración dentro del ciclo de vida del proyecto. ....................................................................... - 23 -
Figura 5: Procesos Scrum. ....................................................................................................................... - 24 -
Figura 6: Fase de pruebas luego del desarrollo. ..................................................................................... - 27 -
Figura 7: Caso de uso interacción usuario - sistema. .............................................................................. - 28 -
Figura 8: Gráfico BURN-DOWN del avance de cada Sprint. ................................................................... - 34 -
Figura 9: Aplicativos para el desarrollo de la aplicación. ....................................................................... - 37 -
Figura 10: Servidores a utilizar por la aplicación. ................................................................................... - 38 -
Figura 11: Caso de uso del modelo de autenticación y autorización. ..................................................... - 39 -
Figura 12: Proceso para la autenticación y autorización del sistema. ................................................... - 39 -
Figura 13: Modelo E-R de configuraciones generales. ........................................................................... - 40 -
Figura 14: Modelo E-R para archivos...................................................................................................... - 40 -
Figura 15: Modelo E-R de la división política. ......................................................................................... - 41 -
Figura 16: Modelo E-R de transacciones. ............................................................................................... - 42 -
Figura 17: Modelo E-R de comandos de negocio.................................................................................... - 43 -
Figura 18: Modelo E-R de seguridades. .................................................................................................. - 44 -
Figura 19: Modelo E-R del maestro de personas. .................................................................................. - 46 -
Figura 20: Modelo E-R para la información general de personas. ......................................................... - 47 -
Figura 21: Modelo E-R de personas naturales. ...................................................................................... - 48 -
Figura 22: Modelo E-R de información adicional y trabajos de personas naturales. ............................. - 49 -
Figura 23: Modelo E-R de personas jurídicas. ......................................................................................... - 49 -
Figura 24: Modelo E-R de parámetros de personas. .............................................................................. - 50 -
Figura 25: Gráfico Burn-Down Sprint 1. .................................................................................................. - 51 -
Figura 26: Gráfico Burn-Down Sprint 2. .................................................................................................. - 60 -
Figura 27: Modelo de Procesos de Productos. ........................................................................................ - 63 -
Figura 28: Modelo de procesos de compras a proveedores. .................................................................. - 63 -
Figura 29: Modelo de proceso de facturación. ....................................................................................... - 64 -
Figura 30: Modelo E-R detalle de productos. ......................................................................................... - 65 -
Figura 31: Modelo E-R productos por agencia. ...................................................................................... - 66 -
Figura 32: Modelo E-R de facturación. ................................................................................................... - 67 -
Figura 33: Modelo de procesos servicio técnico. .................................................................................... - 71 -
Figura 34: Modelo E-R de servicio técnico. ............................................................................................. - 71 -
Figura 35: Gráfico Burn-Down Sprint 3. .................................................................................................. - 73 -
Figura 36: Ingreso de datos a ser simulados para pruebas de la aplicación. ......................................... - 75 -
Figura 37: Ingreso de la dirección web de la aplicación a ser simulada. ................................................ - 76 -
Figura 38: Análisis de rendimiento para 20 usuarios. ............................................................................ - 77 -
Figura 39: Análisis de rendimiento para 50 usuarios. ............................................................................ - 77 -
Figura 40: Análisis de rendimiento para 100 usuarios. .......................................................................... - 78 -
Figura 41: Resultado del análisis de carga para 20 usuarios.................................................................. - 78 -
Figura 42: Resultado del análisis de carga para 50 usuarios.................................................................. - 79 -
Figura 43: Resultado del análisis de carga para 100 usuarios................................................................ - 79 -
Figura 44: Resultado del análisis de la prueba de rampa. ...................................................................... - 80 -
Figura 45: Pantalla de ingreso al sistema. .............................................................................................. - 85 -
Figura 46: Pantalla para restaurar la contraseña. ................................................................................. - 86 -
Figura 47: Pantalla general de la aplicación. ......................................................................................... - 87 -
xiv
Figura 48: Acceso a transacciones. ......................................................................................................... - 87 -
Figura 49: Creación de registros. ............................................................................................................ - 88 -
Figura 50: Controles de transacciones. ................................................................................................... - 89 -
Figura 51: Transacciones de configuraciones técnicas. .......................................................................... - 90 -
Figura 52: Transacciones de parámetros del sistema. ........................................................................... - 90 -
Figura 53: Transacciones de seguridades. .............................................................................................. - 91 -
Figura 54: Lista de valores de personas (LOV). ....................................................................................... - 92 -
Figura 55: Transacción de ingreso de usuario. ....................................................................................... - 93 -
Figura 56: Transacción de activación de usuarios creados. .................................................................... - 93 -
Figura 57: Transacción para la administración de usuarios. .................................................................. - 94 -
Figura 58: Transacción para el cambio de contraseña del usuario. ....................................................... - 94 -
Figura 59: Transacción de ingreso de personas naturales...................................................................... - 95 -
Figura 60: Transacción de ingreso de personas jurídicas. ...................................................................... - 96 -
Figura 61: Transacciones del módulo almacén....................................................................................... - 96 -
Figura 62: Transacción de creación de productos. ................................................................................. - 97 -
Figura 63: Ingreso de datos para el nuevo producto. ............................................................................. - 97 -
Figura 64: Transacción de productos por agencia. ................................................................................. - 98 -
Figura 65: Reporte de productos por agencia. ....................................................................................... - 98 -
Figura 66: Transacción de movimiento de productos. ............................................................................ - 99 -
Figura 67: Transacción de recepción de productos. ............................................................................. - 100 -
Figura 68: Documento de transferencia de productos. ........................................................................ - 100 -
Figura 69: Transacción de ingresos y salidas de productos. ................................................................. - 101 -
Figura 70: Transacción de compras de productos a proveedores. ....................................................... - 102 -
Figura 71: Transacción de ventas de productos. .................................................................................. - 102 -
Figura 72: Transacción de registro de órdenes de trabajo. .................................................................. - 103 -
Figura 73: Creación de la base de datos en postgres. .......................................................................... - 105 -
Figura 74: Restaurar el respaldo de la base de datos. .......................................................................... - 105 -
Figura 75: Configuración para la conexión a la base de datos. ............................................................ - 106 -
Figura 76: Configuración de puerto y para conexiones remotas. ......................................................... - 107 -
Figura 77: Configuración para la publicación de reportes. ................................................................... - 107 -
Figura 78: Servidor de aplicaciones en el entorno de desarrollo. ......................................................... - 108 -
Figura 79: Selección del servidor de aplicaciones. ................................................................................ - 109 -
Figura 80: Configuración del nuevo servidor con su maquina virtual. ................................................. - 109 -
Figura 81: Configuración de conexiones remotas desde el IDE. ........................................................... - 110 -
Figura 82: Selección del tipo de proyecto a importar. .......................................................................... - 111 -
Figura 83: Importar el proyecto WEB. .................................................................................................. - 111 -
Figura 84: Proyecto WEB en el entorno de desarrollo. ......................................................................... - 112 -
Figura 85: Levantar los servicios del servidor de aplicaciones. ............................................................. - 113 -
xv
RESUMEN
ANÁLISIS, DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA EL
CONTROL DE PROCESOS ADMINISTRATIVOS PARA LA MEJORA DE LA
PRODUCTIVIDAD DE TECNOGALAXY CIA. LTDA.
El objetivo principal del presente proyecto es el de implementar una aplicación web
intuitiva, simple y robusta que permita administrar los productos, clientes, ventas y servicio
técnico de TECNOGALAXY CIA. LTDA., bajo perfiles de acceso.
En el primer capítulo presentamos los objetivos que debemos lograr y la definición del
alcance del proyecto. En el segundo capítulo se expone un análisis y utilización de la
metodología para el desarrollo del proyecto con estimaciones del trabajo a ser realizado en
cada iteración. En el tercer capítulo realizamos las pruebas de rendimiento del sistema con
la utilización de una herramienta libre y además presentamos las conclusiones y
recomendaciones luego de finalizado el proyecto.
DESCRIPTORES: SISTEMA WEB / CONTROL DE VENTAS DE PRODUCTOS
TECNOLÓGICOS / CONTROL DE PRODUCTOS TECNOLÓGICOS / CONTROL DE
SERVICIO TÉCNICO.
xvi
ABSTRACT
ANALISYS, DEVELOPMENT AND IMPLEMENTATION OF A SYSTEM FOR THE
CONTROL OF ADMINISTRATIVE PROCESS FOR IMPROVING THE
PRODUCTIVITY OF TECNOGALAXY CIA. LTDA.
The main objective of this project is to implement an intuitive, simple and robust web
application that can manage products, customers, sales and service of TECNOGALAXY
CIA. LTDA., Low access profiles.
In the first chapter we present the objectives achieved and the definition of the project
scope. In the second chapter analysis and use of the methodology for the development of
project estimates of work to be done in each iteration it is exposed. In the third chapter we
conducted performance tests of the system using a free tool and also present the conclusions
and recommendations after project completion.
DESCRIPTORS: WEB SYSTEM / SALES CONTROL OF TECHNOLOGIC PRODUCT
/ TECHNOLOGIC PRODUCT CONTROL / TECHNICAL SUPPORT CONTROL.
xvii
CERTIFICACIÓN DE TRADUCCIÓN
xviii
- 1 -
CAPÍTULO 1
1. PRESENTACIÓN DEL PROBLEMA
1.1. Planteamiento del problema
TECNOGALAXY CIA. LTDA. Es una empresa pequeña dedicada a la distribución de toda
una gama de equipo tecnológico y de accesorios de oficina. También ofrece el servicio de
soporte técnico. Su oficina matriz se encuentra en la ciudad de Quito las ventas las realiza
dentro y fuera de la ciudad al por mayor y menor.
La empresa actualmente tiene tres sucursales en la ciudad de Quito. No tiene un sistema
informático homogéneo que le permita gestionar sus procesos de negocio, la información de
clientes, empleados y proveedores los tiene registrados en fichas, la información de
productos los lleva en hojas de Excel, la facturación lo realiza con una aplicación de
escritorio no centralizada, ofrece sus productos por medio de catálogos impresos u hojas
volantes, las órdenes de trabajo del servicio técnico son registradas en fichas, no poseen una
aplicación donde los clientes puedan solicitar información de productos y servicio técnico.
Tiene un sistema para realizar la contabilidad el cual es alimentado con los datos obtenidos
de cada sucursal, no tiene un sistema que le provea la información de ventas de forma
consolidada.
Las órdenes de trabajo para el servicio técnico las llevan en forma manual y en cada local
independientemente sin saber en qué estado se encuentra dicha orden lo cual produce
retrasos en la entrega generando molestias en el cliente.
La ausencia de un sistema informático en la empresa la ha llevado a las siguientes
inconvenientes:
Pérdidas económicas por falta de control en sus productos, servicio técnico y ventas, son las
causas por la que se requiere de un control centralizado y automatizado.
No tiene un sistema que le provea reportes de ventas, productos y servicio técnico con
fechas de corte.
1.2. Formulación del problema
De acuerdo a lo expuesto anteriormente la empresa requiere de un sistema que le ayude a
gestionar sus procesos de negocio permitiéndole obtener respuestas oportunas a sus
necesidades. Para esto se requiere de la implementación de un sistema informático bajo una
plataforma tecnológica robusta y libre que controle todos sus procesos.
- 2 -
1.2.1. Objetivo general
Implementar una aplicación web intuitiva que permita administrar los productos, servicio
técnico, registro de ventas, registro de compras, información de clientes así como obtener
reportes de ventas y productos bajo perfiles de acceso.
1.2.2. Objetivos específicos
Analizar los procesos de clientes, ventas, productos y servicio técnico de la empresa y
determinar el mecanismo óptimo para el control automatizado de dichos procesos.
Manejo de perfiles de acceso al sistema para la administración de sus procesos.
Implementar un modelo de almacenamiento de información para la generación de reportes
de ventas y productos según los perfiles de acceso.
1.3. Justificación del problema
“TECNOGALAXY CIA. LTDA.” Con la finalidad de brindar un mejor servicio a la
comunidad y con el crecimiento que ha tenido la empresa también crece la necesidad de
mejorar el control de sus procesos haciendo uso de la tecnología que es nuestra mejor aliada
para este fin.
El problema que se pretende solucionar es básicamente el control de los productos y
servicios con una buena atención al cliente, ágil y rápida en las ventas. Actualmente en la
sucursal principal atiende a un gran número de personas en temas de soporte técnico. La
gran demanda de este servicio en la comunidad ha hecho crecer la necesidad de tener un
sistema para controlar las órdenes de trabajo de cada cliente.
Al conocer de la necesidad que tiene la empresa de implementar una aplicación para el
control de sus procesos de negocio, ha hecho posible desarrollar el presente trabajo de tesis
como requerimiento de la empresa. Se ha realizado un análisis de viabilidad para llevar a
cabo su desarrollo e implementación, en la cual los principales beneficiarios serían
“TECNOGALAXY CIA LTDA”, la comunidad y el autor del presente proyecto previo a la
obtención del título de graduación.
Con la implementación del sistema se contribuirá en el desarrollo de una pequeña empresa
como “TECNOGALAXY CIA LTDA” brindándole un orden en su esquema funcional así
como en el mejor desenvolvimiento de la misma con un mejor servicio a la comunidad que
es el principal beneficiado y el actor primordial en el desarrollo de la empresa.
- 3 -
1.4. Alcance y limitaciones
1.4.1. Alcance
De acuerdo a los objetivos, al análisis y a la investigación realizada, el alcance del proyecto
los definimos en los siguientes módulos:
1.4.1.1. Módulo de seguridades
El módulo de seguridades permite definir un esquema de permisos de acceso hacia la
aplicación. A continuación se exponen los elementos del módulo de seguridades:
Autenticación.- En el módulo de seguridades se incluirá el componente de autenticación.
Para acceder al sistema se lo realizará mediante el ingreso de un usuario y contraseña.
Usuario.- Campo numérico para el ingreso del código de usuario que es la
cedula de ciudadanía o documento de identificación (pasaporte).
Contraseña.- Campo alfanumérico y de caracteres especiales, una de las
características de este campo es que la contraseña será encriptado en la base de
datos.
Para la administración de los usuarios que ingresaran a la aplicación se dispondrá de las
siguientes transacciones en el submenú “Usuarios”:
Ingreso de usuarios.- Previamente registrada a la persona se creara su usuario
para el acceso a la aplicación, su código de usuario será su número de
identificación o cedula de ciudadanía.
Mantenimiento de usuarios.- Se podrá dar mantenimiento a la información de
usuarios creados.
Activación de usuarios.- Luego de crear el usuario se necesitara de su
activación para el ingreso a la aplicación.
Cambio de contraseña.- Permitirá cambiar la contraseña del usuario.
Autorización.- Se incluirá el componente de autorización para el acceso a las páginas o
transacciones. El control de acceso a las transacciones se lo define mediante el uso de
perfiles.
Cada usuario tendrá uno o varios perfiles con un menú y éste con un conjunto de
transacciones o páginas. Inicialmente se tiene el usuario con perfil “Administrador General”
con todos los permisos y accesos a todas las transacciones, mediante éste se administrarán
los perfiles para cada usuario involucrado en el sistema.
- 4 -
El esquema de autorización se la podrá gestionar mediante el siguiente grupo de
transacciones asociados al submenú “Configuración”:
Perfiles.- Permite asignar los roles que los usuarios tendrán en el sistema.
Terminales.- Permite registrar la dirección IP, MAC e impresora asociado a un
terminal de trabajo de una área determinada.
Políticas de seguridad.- Permite definir las características de las contraseñas
asociadas a los usuarios.
Menús.- Permite definir un menú de transacciones asociado a un perfil.
Permisos por transacción.- Permite la creación, edición, eliminación y consulta
de registros en cada transacción. Una transacción la definiremos como una
pantalla.
Los perfiles que se definirán en el sistema se describen a continuación:
Administrador general.- Tiene acceso total a todos los módulos del sistema, por
ejemplo, creación de los perfiles y los menús asociados a un usuario. Gestiona
toda la parametrización de la aplicación.
Ventas.- Tiene acceso para la facturación de los productos y servicio técnico,
consulta de la información de los productos así como también gestiona la
información de clientes.
Servicio técnico.- Tiene acceso para la creación, consulta y modificación de
órdenes de trabajo, consulta de productos, consulta, creación y modificación de
clientes.
1.4.1.2. Módulo de configuración técnica
En este módulo se encontraran las transacciones de configuraciones técnicas de la
aplicación. El perfil administrador tiene el acceso a estas transacciones. En el submenú
“Generales” se tiene las siguientes opciones:
Módulos.- Se definen los módulos de la aplicación.
Canales.- Se definen los canales a utilizar.
Idioma.- Se definen los idiomas a utilizar en la aplicación en los módulos.
- 5 -
Resultados.- Se ingresan los mensajes a ser utilizados por el CORE1 de la
aplicación.
Monedas.- Se definen la moneda a utilizar en la aplicación.
Parámetros.- Se definen los parámetros generales a utilizar en la aplicación.
Secuencias.- Se ingresan los secuenciales a utilizar para los códigos.
Transacciones.- Se definen las páginas o transacciones que formaran parte del
menú.
En el submenú “Comandos” se presentan las opciones de menú para la parametrización de
comandos de ejecución por transacciones. Permite definir una clase Java que proporciona la
lógica de negocio adicional en cada transacción y las mencionamos a continuación:
Comandos de negocio.- Se definen componentes de consulta o mantenimiento
que se utilizara en transacciones especiales. Los comandos con clases java que
ejecutan una lógica de negocio o procesamiento específico.
Códigos de consulta.- Se definirán componentes de consulta por código. Estos
componentes son clases java que son invocados para retornar una respuesta al
ejecutar una consulta y pueden ser reutilizados en varias transacciones.
Comando de consulta.- Se definen los componentes y códigos de consulta a ser
llamados por una transacción.
Comando de mantenimiento.- Se definen los componentes de mantenimiento a
ser invocados por una transacción.
1.4.1.3. Módulo de parámetros del sistema
En el módulo de parámetros se definen las transacciones que forman parte de la
parametrización general del sistema y los mencionamos a continuación.
En el submenú “Generales” tenemos las siguientes opciones de menú:
Catálogos.- Se registran los catálogos a utilizar en la aplicación.
Países.- Permite definir países.
Provincias.- Permite el ingreso de provincias asociadas a un país.
1 CORE, Parte central del sistema que procesa las peticiones de ingresos, consultas, modificaciones y
eliminaciones de registros en la base de datos.
- 6 -
Cantones.- Permite el ingreso de provincias.
Parroquias.- Permite el ingreso de parroquias.
Ciudades.- Permite el ingreso de ciudades.
Nacionalidades.- Permite registrar las diferentes nacionalidades.
En el submenú “Compañía” se definan las siguientes opciones.
Área.- Se definen las diferentes áreas o departamentos que hay en la empresa.
Sucursal.- Ingreso de las sucursales de la empresa.
Agencia.- Permite el ingreso de las agencias de la empresa.
Compañía.- Es la parametrización de la compañía en la aplicación.
1.4.1.4. Módulo de almacén
El módulo de almacén se define las transacciones que formaran parte de la operación propia
de la empresa.
En el submenú “Generales” tenemos las siguientes opciones:
Marcas.- Permite el ingreso de marcas de productos a utilizar en la aplicación.
Impuestos.- Permite el ingreso de un tipo de impuestos a ser utilizados en la
aplicación.
Secciones.- Se define la sección a la que pertenece un producto.
Perchas.- Se define la percha en la que se encuentra un producto determinado.
Niveles.- Se registra el número de niveles por perchas para ubicar a un
producto.
Impuesto por producto.- Permite definir los impuestos asociados a un
determinado producto. La opción queda abierta para una futura
implementación.
En el submenú “Productos” tenemos las siguientes opciones de menú:
Productos.- En esta transacción podemos ingresar la definición propia de los
productos.
- 7 -
Productos por agencia.- Permite asignar, consultar y modificar los productos de
una agencia determinada.
Productos agencia.- Permite asignar, consultar y modificar un producto a una
agencia.
Movimiento productos.- Permite registrar los movimientos de productos entre
agencias.
Recepción productos.- Permite registrar la aceptación de los movimientos de
productos.
Kardex.- Permite la consulta de ingreso y salida de productos.
Compras.- Permite registrar las compras realizadas de los productos.
Consulta compras.- Permite realizar las consulta de las compras realizadas por
factura del proveedor.
En el submenú “Ventas” tenemos las transacciones para el registro de las ventas de los
productos, impresión de facturas así como la consulta de ventas y las mencionamos a
continuación.
Facturas.- En facturas podemos registras las ventas de los productos e imprimir
la factura.
Consulta ventas.- Transacción para la consulta de las ventas realizadas con
filtros de búsqueda.
Pagos.- En ésta transacción registramos los pagos de las facturas a crédito.
Consulta pagos.- Permite consultar los pagos realizados por facturas.
Facturas administrador.- Permite al administrador realizar el registro de una
venta de determinadas agencias.
Pagos administrador.- Permite al administrador realizar el registro de los pagos
de facturas a crédito de determinadas agencias.
En el submenú “Servicio técnico” se definen las transacciones que formaran parte de la
atención al cliente en cuanto a la parte de soporte técnico de productos o servicios.
Ordenes de trabajo.- Permite registrar las ordenes de trabajo del servicio técnico
y dar seguimiento a cada una de ellas.
- 8 -
Consulta de ordenes.- Permite realizar una consulta rápida de las ordenes de
trabajo.
1.4.1.5. Módulo de personas
En el módulo de personas se registran los datos de las personas involucradas en el sistema
ya sean empleados, clientes y proveedores. El submenú “Mantenimiento” consta de las
siguientes transacciones:
Creación de personas naturales.- Permite la creación y mantenimiento de la
información de personas naturales.
Creación de personas jurídicas.- Permite el ingreso y mantenimiento de la
información de las personas jurídicas.
En el submenú “Generales” tenemos las siguientes transacciones para el registro de la
información adicional de personas.
Sectores económicos.- Permite el ingreso de los sectores económicos para
personas.
Actividades económicas.- Registra las diferentes actividades económicas y no
económicas.
Actividades económicas por sector.- Permite ingresar las actividades por su
sector económico.
1.4.2. Limitaciones
En la implementación de la aplicación se detectaron las siguientes limitaciones.
El sistema se instaló en una computadora de escritorio de alto rendimiento por lo tanto el
gestor de base de datos, servidor de aplicaciones y servidor de reportes están en la misma
computadora. Por lo tanto puede perder rendimiento o tiempo de respuesta al aumentar los
usuarios que accedan al sistema. La empresa no tiene acceso al código fuente del sistema,
simplemente se hizo la entrega de los archivos binarios los mismos que fueron desplegados
en el servidor de aplicaciones.
Se ingresa a la aplicación mediante una dirección IP pública y un puerto no enmascarados.
La seguridad en cuanto al acceso a la aplicación por IP y puerto queda para una futura
implementación por parte de TECNOGALAXY CIA. LTDA.
En servidor de aplicaciones y el servidor de reportes no tienen una configuración de algún
certificado por lo tanto las peticiones al servidor no irán encriptados.
- 9 -
La aplicación no posee transacciones para respaldos de información del esquema de base de
datos, por lo tanto queda bajo la administración de TECNOGALAXY CIA. LTDA.
El sistema no tiene transacciones para consultas de auditoría, los registros están en la base
de datos y puede acceder a ella bajo consultas a las tablas.
El sistema no tiene comunicación directa con el sistema contable de la empresa, pero
proporciona consultas y reportes de las ventas realizadas, productos, compras y pagos.
Para el envío de correos electrónicos a las personas que han olvidado su contraseña para el
ingreso a la aplicación, no se tiene configurado un servidor de correo, se hace uso de una
cuenta creada en GMAIL para enviar la nueva contraseña al usuario.
Los navegadores en los que se recomienda y garantiza el correcto funcionamientos de la
aplicación se describen a continuación.
No. Navegador Versión
1 Mozila Firefox 30 o Superior
2 Google Chrome 30 o Superior
3 Safari 5 o Superior
Tabla 1: Tabla de navegadores permitidos. Fuente: Tesista. Autor: Tesista.
- 10 -
1.5. Esquema de solución
El sistema implementado en TECNOGALAXY CIA. LTDA., como parte de una solución
en el control de los procesos administrativos para la mejora de la productividad está
orientada a la web. Desarrollado con herramientas libres tanto para el editor de código como
para el servidor de aplicaciones, base de datos y reportes.
Se plantea desarrollar una aplicación web administrable basado en capas con la cual se tiene
un control independiente entre el cliente, la lógica de presentación, la lógica de negocio y el
repositorio de datos. A continuación se presenta un esquema global de la solución
informática:
Esquema General de la Aplicación
Cliente
Navegador
Navegador
Navegador
Servidor
Servidor de Aplicaciones
Servidor de Reportes
Servidor Base de Datos
Usuario Administrador
Internet
Figura 1: Esquema general de la aplicación.
Fuente: Tesista. Autor: Tesista.
1.6. Arquitectura
Para la implementación del sistema se ha elegido desarrollar una aplicación empresarial
web n-capas basado en el lenguaje de programación Java2.
Java se ha elegido como lenguaje de programación ya que presenta una gran variedad de
implementaciones ya probadas que pueden ser utilizadas, posee amplia documentación, es
de libre acceso y que particularmente poseo un gran conocimiento de herramientas para
desarrollo web. A continuación destacamos algunos puntos importantes del lenguaje Java
con respecto de otros lenguajes de programación más utilizados, calificando al lenguaje con
un valor de entre 0 y 10 dependiendo de las características más satisfactorias que posee con
respecto al otro.
2 Java, (Oracle Java, 2014).
- 11 -
Características JAVA PHP ASP.NET
Flexibilidad de la programación orientación a objetos en el
diseño de aplicaciones. 10 5 7
Multiplataforma en el desarrollo e implementación de
aplicaciones web. 10 8 3
Conectividad con diferentes bases de datos (Oracle,
PostgreSQL, MySql, SqlServer) 10 10 10
Fácil accesibilidad a la documentación. 8 8 5
Fácil organización por capas en el desarrollo de las
aplicaciones web. 10 5 10
Fácil acceso a las herramientas de desarrollo. 9 9 5
Mejor rendimiento de las aplicaciones en entornos web. 9 8 8
Herramientas de desarrollo y servidores de aplicaciones con
licencia de código abierto. 10 10 5
Independencia del sistema operativo en el desarrollo de las
aplicaciones. 10 10 3
Fácil mantenimiento del código fuente. 8 8 9
Se posee gran conocimiento de herramientas de desarrollo
web. 8 6 6
Total 9 8 6
Tabla 2: Tabla comparativa de lenguajes de programación web. Fuente: (Manosalvas, 2014).
Autor: Tesista.
De acuerdo a la valoración dada por las características y el conocimiento del lenguaje de
programación podemos decir que Java es la mejor opción para el desarrollo de la aplicación.
- 12 -
1.6.1. Plataforma
Para el desarrollo de la aplicación nos basaremos en la plataforma JEE3 que contiene un
conjunto de librerías y especificaciones que facilitan la programación y el despliegue de
sistemas empresariales bajo una arquitectura de N-capas. A continuación presentamos una
gráfica de la arquitectura del sistema a ser utilizada basada en la especificación JEE.
Arquitectura JEE
Cliente
Navegador
Navegador
Navegador
Servidor de aplicaciones
Servidor BD
Base de
datos
Front End Back End
JD
BC
Contenedor EJB
Componentes de negocio
Manejo de entidades JPA
Contenedor WEB
Páginas XHTML, JQuery
Controladores, Servlets
RMI
Servidor Web
BI - Server
Reportes
HT
TP
PENTAHO
HTTP
Figura 2: Arquitectura de la aplicación bajo la plataforma JEE
Fuente: Tesista. Autor: Tesista.
Como podemos apreciar en la Figura 2 se describe la arquitectura a utilizar para la
aplicación basada en las especificaciones JEE. Definimos las distintas capas que se utilizan
y que interactúan entre ellas para el correcto funcionamiento.
El Front – end permite definir la capa de presentación, esta es la parte del sistema que
interactúa con los usuarios. Permite abstraer y separar la lógica de presentación de la lógica
de negocio. Para la implementación de la lógica de presentación se utilizará el Famework4
JSF5 2.1, que es la herramienta más utilizada para entornos web por parte de desarrolladores
Java. A continuación presentamos algunos puntos importantes entre implementaciones Java
JSF, Struts6 y Wicket
7 para la lógica de presentación calificando con un valor entre 0 y 10
dependiendo de la característica más satisfactoria.
3 JEE, (Oracle Jee, 2013)
4 Framework, (Framework, 2006).
5 JSF, (Oracle JSF).
6 Struts, (Apache Struts, 2014).
7 Wicket, (Apache Wicket, 2013).
- 13 -
Características JSF STRUTS WICKET
Provee un desarrollo fácil y rápido.
9 8 5
Basado en el estándar JEE 10 10 9
Provee de varias bibliotecas y componentes para
el desarrollo.
10 9 8
Facilidad en el aprendizaje de componentes. 10 8 6
Provee una mejor integración para el desarrollo
de componentes visuales. 9 9 7
Facilidad en la configuración en base a
descriptores de despliegue o archivos XML.
9 9 8
Fácil integración con implementaciones de
desarrollo como Velocity, Poi, Doc4j.
10 10 10
Arquitectura fácil, extensible, escalable y soporta
actualizaciones de versiones.
9 6 6
Provee amplia documentación y ejemplos para el
aprendizaje en la web.
9 8 6
Total 9 8 7
Tabla 3: Características de implementaciones web para la capa de Front-end. Fuente: Tesista. Autor: Tesista.
De acuerdo a la valoración dada por las características y el conocimiento de las
implementaciones para el desarrollo del Front-end podemos decir que JSF es la mejor
opción para el desarrollo de la lógica de presentación.
Primefaces en su versión 5.0.3, es la implementación JSF con mayor número de
componentes agiles y fáciles de usar para el desarrollador, utiliza páginas con extensión
XHTML, internamente usa una librería JavaScript denominada JQuery que nos ayuda con
efectos, estilos, eventos, temas y usa la tecnología AJAX para mejorar la interacción del
usuario con el sistema en cuanto a eventos específicos. Presentamos a continuación unas
características importantes de la implementación frente a otras JSF.
- 14 -
Características PrimeFaces
5.0.3
IceFaces
3.x
RichFace
s 4.3
Componentes disponibles entre básicos, paneles,
tablas, árboles y menús.
10 7 4
Facilidad de implementación agregando las
dependencias en las librerías del proyecto web, o
con el uso de MAVEN para su empaquetado.
10 10 10
Documentación extensa o guías de usuario en
línea con ejemplos de libre acceso.
8 7 8
Mayor número de componentes integrados con
AJAX para el manejo de eventos para la mejor
iteración del usuario y aplicación.
9 8 7
Implementación mejorada con JQUERY para la
presentación de las páginas web. 10 9 8
Implementación JSF más utilizada por
desarrolladores.
9 7 7
Requiere de una suscripción para tener las
últimas actualizaciones.
7 7 9
Total 9 8 8
Tabla 4: Características de las implementaciones JSF más utilizadas en desarrollo web Fuente: (Implementaciones JSF).
Autor: Tesista.
De acuerdo a la valoración dada por las características y el conocimiento de las
herramientas para el desarrollo el Front-end en base JSF podemos decir que Primefaces es
la mejor implementación para el desarrollo de la parte web.
El Back – end es la capa responsable de procesar los datos ingresados por el parte del
usuario y transmitidos desde el Front – end. Los datos recolectados desde la parte del cliente
son gestionados y procesados por ésta capa la cual retorna una respuesta simple y entendible
hacia el cliente.
En esta capa estará definido un contenedor EJB8 para la lógica de negocio que contendrá un
motor de consultas, eliminación, actualización e ingreso de registros y un motor ejecución
de comandos de negocio (Clases java para realizar tareas específicas de mantenimiento, y
consulta). Los EJB’s nos permiten definir una arquitectura sencilla, robusta, escalable y
fiable al momento de desarrollar aplicaciones empresariales en el lenguaje java.
Presentamos algunas comparativas entre las soluciones Java EJB, SPRING9 y AVALON
10
8 EJB, (ÁLVAREZ, 2013).
9 SPRING, (Spring-Framework, 2014).
10 AVALON, (Wikipedia AVALON, 2013).
- 15 -
para la lógica de negocio son opciones usadas al momento de desarrollar aplicaciones web
calificamos con valores entre 0 y 10 según las características más satisfactorias.
Características EJB 3 SPRING Apache
AVALON
Manejador de transacciones, soporta JTA
como alternativa para las aplicaciones de
negocio.
9 8 0
Manejo de persistencia, empleo de
anotaciones, sentencias jpql, criteria, sql
nativo e integración con hibernate. JPA
como manejador de la capa de persistencia.
10 3 5
Definición de anotaciones, metadata y
descriptores de despliegue. 9 7 6
Flexibilidad de servicios, provee servicios
que pueden ser ensamblados por medio de
archivos de configuración XML.
8 9 7
El servidor de aplicaciones contiene una
implementación de EJB y tiene la
oportunidad de optimizar el rendimiento
mediante una configuración en el servidor.
9 3 5
Diferente y extensa documentación libre a
través de la página de JBOSS. 9 8 6
Implementaciones libres y documentadas
para el desarrollo de aplicaciones
empresariales.
9 8 5
Total 9 7 5
Tabla 5: Comparativa ente las plataformas a utilizar para la capa de back - en Fuente: Tesista. Autor: Tesista.
Existen diferencias muy marcadas entre las plataformas de desarrollo para la capa del Back
– end pero nos inclinamos por el uso de EJB ya que es una herramienta que particularmente
ha sido utilizada en distintos desarrollos de aplicaciones web y presenta gran flexibilidad en
su uso.
Se utilizará el contenedor JPA11
para el manejo de entidades (Definición de tablas como
objetos administrados desde el contenedor JPA), se acopla con diferentes bases de datos.
Para el repositorio de datos haremos uso de Postgresql 9.3, que es considerado líder mundial
en sistemas de bases de datos relacionales orientado a objetos de código abierto, posee una
11
JPA, (JPA, 2014).
- 16 -
amplia documentación con ejemplos explicativo de configuración. Es rápido en la
integración y se acopla fácilmente con JPA. Facilidad en la configuración en cuanto a
seguridades, basta con editar un archivo de configuración. Presentamos una comparativa
entre las diferentes herramientas gestoras de bases de datos describiendo como “Si” a las
características satisfactorias y como “No” a las poco satisfactorias.
Características PostgreSql MySql Oracle
Sistema gestor de bases de datos orientado a objetos
de código abierto.
10 8 0
Sistema gestor de base de datos multiplataforma y de
libre implementación en ambientes de producción.
10 10 0
Gestor de base de datos altamente transaccional. 9 7 10
Manejo de tipos de datos básicos y propios, basado
en el estándar SQL, manejo de restricciones y
seguridades.
9 8 9
Tienes más de un lenguaje para procedimientos
almacenados.
10 0 9
Tiene soporte y documentación para la
administración.
9 7 10
Soporte a transacciones, portabilidad, estabilidad y
escalabilidad.
10 7 10
Estructura para optimización de consultas SQL. 10 7 10
Permite subconsultas correlacionadas y no
correlacionadas hasta 255 niveles.
10 8 10
Diseñado para ambientes de altos volúmenes de
datos.
9 7 10
Posee herramientas gráficas libres para la
administración de las bases de datos.
10 9 7
Soporta alta concurrencia multiversión y elimina la
necesidad de bloqueos explícitos.
9 7 10
Acceso a la documentación para la administración en
su página oficial con constantes actualizaciones y de
libre acceso a la herramienta para entornos de
producción.
9 7 0
Sistema gestor de base de datos más utilizado para el
desarrollo de aplicaciones con herramientas libres. 10 8 0
Total 9 7 6
Tabla 6: Características entre bases de datos relacionales más usadas. Fuente: (Comparativa Bases de Datos, 2014).
Autor: Tesista.
- 17 -
En conclusión buscamos una herramienta gestora de base de datos de acceso libre y Oracle
no nos proporciona esa facilidad no la tomaremos en cuenta su licencia es costosa
conjuntamente con el soporte, no posee la infraestructura de orientación a objetos cosa que
PostgreSQL si lo tiene, no es un gestor de código abierto, posee una alta configuración
según requerimientos y está sustentado bajo el soporte para ambientes de producción.
PostgreSQL sistema de bases de datos objeto relacional de código abierto libre y gratuito,
posee una comunidad que continuamente está mejorando el sistema, amplia documentación
en internet y es una alternativa gratuita para la utilización en sistemas transaccionales que
puede abaratar los costos de las implementaciones por ende elegimos a PostreSQL como el
sistema para nuestro repositorio de datos.
Para el servidor de reportes hemos elegido utilizar Pentaho 4.5 Community Edition.
Utilizaremos el Bi-server como el repositorio y despliegue de reportes y como herramienta
de diseño utilizaremos el PRD (Pentaho Report Designer) diseñador de reportes Pentaho en
la versión 3.9. Presentamos un cuadro comparativo entre servidores de reportes y
herramientas de diseño.
Características Pentaho
BI-Server
Jaspersoft
BI-Server
Cristal
Server
Repositorio WEB de reportes y de
soluciones BI (Business Intelligence).
10 10 8
No posee una base de datos para gestionar
los recursos (reportes, subreportes, estilos,
y conexiones a datos.) facilitando la
administración.
9 3 7
El repositorio WEB de reportes se aloja
bajo un servidor de aplicaciones.
9 9 8
Corre bajo la plataforma Windows, Linux
y Mac OS.
10 10 9
Fácil configuración en el montado del
servidor de reportes WEB.
10 8 5
El aplicativo es proveído bajo una
comunidad de software libre. 8 9 5
Fácil configuración para el acceso a los
datos en los reportes.
9 8 6
Documentación accesible en la web para la
instalación y configuración.
9 8 6
Total 9 8 7
Tabla 7: Características entre repositorios WEB de reportes. Fuente: Tesista. Autor: Tesista.
Como podemos apreciar en el cuadro comparativo no hay diferencias muy marcadas entre
uno y otro servidor de reportes en cuanto a sus características principales, pero debido a la
- 18 -
mejor calificación obtenida y por conocimiento asumimos el reto de utilizar Pentaho 4.5
(BI-Server) como nuestro repositorio de reportes. A continuación marcaremos las
especificaciones importantes entre diseñadores de reportes.
Características Pentaho Report
Designer
Jasper
Studio
Ciristal
Report
Diseñador de reportes proveído bajo una
licencia de software libre.
9 9 9
Herramienta de fácil configuración para su uso
basta con desempaquetar el aplicativo y
usarlo.
10 8 7
Fácil configuración para el acceso a datos
desde un entorno intuitivo.
10 8 7
Provee el esquema para la definición de
subreportes y paso de parámetros.
9 9 8
Utiliza secuencias de acción (.xaction) para
invocar a los reportes.
9 0 0
La definición del reporte es empaquetado en
un conjunto de recursos para ser interpretados
por el repositorio WEB.
9 3 5
Posee una definición del reporte en un archivo
XML para ser interpretado por el repositorio
WEB.
7 9 7
Posee un plug-in para el diseño de reportes
dentro de un IDE de desarrollo (Eclipse y
NetBeans).
0 8 8
Se ejecuta bajo las plataformas Windows,
Linux y Mac OS.
10 10 8
Paleta para acceso a los objetos y
componentes de diseño de reportes
10 10 10
Vista de las propiedades de los objetos de
diseño.
10 10 9
Vista previa de diseño y exporte de reportes en
diferentes formatos.
10 8 8
Posee objetos para el diseño de gráficos,
subreportes, acceso a datos y publicación.
10 7 5
Total 9 8 7
Tabla 8: Características entre diseñadores de reportes. Fuente: Tesista. Autor: Tesista.
- 19 -
Usaremos el diseñador de reportes de Pentaho ya que nos ha presentado unas características
favorables, es muy amigable en su entorno gráfico y es una herramienta que nos facilita el
trabajo en cuanto a la creación y personalización de informes que se ajusta a las necesidades
del negocio y destinado a desarrolladores por ende haremos uso de ella.
1.6.2. Herramientas de desarrollo
A continuación presentamos unos cuadros que resumen el software y hardware a ser
utilizadas en el desarrollo de la aplicación para “TECNOGALAXY CIA. LTDA.”. Entre las
herramientas de software describimos los sistemas operativos en el cual podrá ejecutarse la
aplicación, repositorio de datos a ser utilizado, las herramientas de diseño de reportes y
servidor, IDE de desarrollo Java y servidor de aplicaciones.
No. Descripción Herramienta
1 Sistema operativo. Linux OpenSuse 13.2, Centos 7, Windows 7 o
superior
2 Servidor de aplicaciones. JBoss Application Server 7
3 Servidor de reportes. Pentaho BI-Server 4.5
4 IDE de desarrollo. Eclipse Kepler / NetBeans 7.3
5 Empaquetado Maven 3.0.4
5 Diseñador de reportes. PRD (Pentaho Report Designer) 3.9
6 Herramienta de modelado E-
R para la base de datos.
PowerDesigner 16.5
7 Gestor de base de datos. PostgreSql 9.3
8 Máquina virtual de Java. JDK v 1.7
9 Cliente de base de datos
li
PgAdmin III
10 Navegadores. Mozila Firefox, Chrome o Safari en sus
últimas versiones.
11 Visualizador de documentos
PDF.
Adobe Reader en sus últimas versiones o
cualquier otro.
Tabla 9: Requisitos de software para desarrollo. Fuente: Tesista. Autor: Tesista.
En cuanto al hardware definimos los requisitos mínimos recomendados para que la
aplicación se ejecute sin inconvenientes ya que se utilizará una computadora de escritorio
de alto rendimiento como servidor y los especificamos a continuación.
- 20 -
No. Descripción Herramienta
1 Procesador. Intel core I5 de 2.3 GHz. o superior.
2 Memoria RAM. Memoria RAM de 8GB o superior.
3 Unidad de disco rígido. Disco rígido de 100 GB o superior
4 Monitor. Monitor de resolución 1024 x 768 como
mínimo. 5 Red - Internet Conexión banda ancha con salida a internet
con IP pública.
6 Impresora. Impresora a color y B/N.
7 Periféricos. Puertos USB y lector de DVD Rom.
Tabla 10: Requisitos de hardware para la aplicación. Fuente: Tesista. Autor: Tesista.
- 21 -
CAPÍTULO 2
2. METODOLOGÍA
2.1. Antecedentes
La administración de los procesos de una organización pequeña o mediana es muy difícil si
se lo lleva de forma manual. Se complica aún más cuando empieza a crecer y extenderse,
ahora, con el avance informático y tecnológico ha mejorado considerablemente ésta
situación, tomando el control completo de la organización con la utilización de sistemas
web informáticos que ayuda a gestionar la información.
Implementar un sistema web informático que nos ayude con el control de nuestra
organización no es una tarea sencilla puesto que implica tener un gran conocimiento de los
requisitos específicos o de los procesos que se deseen automatizar, así como formar o
contratar un equipo de desarrollo que nos colabore con este fin.
El equipo que empezará el desarrollo de la aplicación también debe tener un gran
conocimiento de los procesos a implementar así como de procesos y metodologías que
ayuden a gestionar el avance del sistema, requiere de la total colaboración de los miembros
de la organización para que el proyecto concluya satisfactoriamente.
2.2. Metodología de investigación
El presente proyecto se realizó utilizando las siguientes modalidades en la investigación:
Investigación Bibliográfica, que se basa en la recopilación de información y nosotros la
utilizamos adecuadamente consultando libros, internet y artículos de investigaciones, para
realizar el presente trabajo de tesis y basarnos en resultados, análisis y consultas.
Investigación de Campo, la investigación de campo consiste en el levantamiento de la
información en el mismo lugar donde se detecta el problema, el análisis y levantamiento de
requerimientos se lo realizó en TECNOGALAXY CIA. LTDA., Se obtuvo toda la
colaboración del personal para que los requerimientos sean levantados con exactitud y en
base a las necesidades del cliente y que se detallaron en el presente proyecto de
investigación.
2.3. Metodología SCRUM
SCRUM12
es una metodología ágil que nos ayudará a concluir el proyecto con éxito, en si es
un marco de trabajo simple e incremental que nos va orientando y organizando en los
procesos de desarrollo de la aplicación, no nos dice que tenemos que hacer sino como
debemos de hacerlo. Los equipos de trabajo son auto gestionados todos colaboran y tiene la
12
SCRUM, (SCRUM, 2014).
- 22 -
misma importancia. Los expertos mencionan que la correcta ejecución de la metodología
hará que completemos el proyecto con éxito y en los tiempos estimados.
SCRUM está muy orientado a la gestión y el seguimiento de los proyectos, ayuda al buen
entendimiento, acuerdo de los requisitos y a gestionar sus cambios. Define un ciclo de vida
iterativo e incremental, esto implica a que hay que desarrollar pequeños entregables
periódicamente, aumentando la funcionalidad de la aplicación en cada iteración.
A continuación presentamos un cuadro comparativo entre metodologías de desarrollo ágil
SCRUM, XP13
y tradicional RUP14
para proyectos de corta duración con una valoración de
entre 0 y 10, diez es la calificación a la característica altamente satisfactoria y cero a la
característica desfavorable.
Características RUP SCRUM XP
Metodología ágil en el desarrollo de software que reduce los
costos de proyectos.
6 9 8
Reduce el costo del cambio en cada etapa del desarrollo de
software.
7 9 9
Las iteraciones son mucho más cortas en comparación con
otros métodos. Permite beneficiarse de la retroalimentación
en cada tarea.
8 9 9
Es altamente recomendable para proyectos pequeños. 7 9 9
Provee retroalimentación rápida, simplicidad, cambio
incremental, se acopla al cambio, trabajo de alta calidad. 6 8 8
Procesos controlados por pocas normas y de períodos cortos
basados en los objetivos del proyecto. 6 8 8
Todo el equipo participa en el desarrollo del proyecto
(Cliente, Jefe de proyecto y equipo de desarrollo).
6 9 8
Permite controlar equipos pequeños de desarrollo. 7 9 9
Aceptación a los cambios e integración permanente con la
arquitectura del software.
6 9 8
Total 7 9 8
Tabla 11: Tabla comparativa de metodologías ágiles y tradicionales. Fuente: Tesista. Autor: Tesista.
13
XP, (XP, 2013).
14 RUP, (Metodología RUP, 2014).
- 23 -
Analizando el cuadro comparativo Scrum como marco de trabajo y XP como metodología
de desarrollo resultan ser la mejor opción a seguir para la ejecución de proyectos de
software, y según el libro “SCRUM Y XP DESDE LAS TRINCHERAS15
” son las opciones
que mejor se acoplan para proyectos de software.
Fin del
proyecto
Inicio del
proyectoIteración 1 Iteración 2 Iteración 3
Figura 3: Ciclo de vida iterativo e incremental en el proyecto Fuente: Tesista. Autor: Tesista.
Cada iteración conocida como Sprint debe tener un periodo determinado, la teoría
recomienda que tenga una duración de menos de seis semanas. En ésta se definen los
requerimientos, su análisis, desarrollo, evaluación y pruebas de calidad de tal manera que al
finalizar el periodo se pueda entregar algo de valor y que funcione correctamente.
Iteración
Control de calidad Evaluación
Análisis y DiseñoRequerimientos
Figura 4: Iteración dentro del ciclo de vida del proyecto. Fuente: Tesista. Autor: Tesista.
En la fase de Requerimientos se evalúan las historias de usuario presentadas por el cliente y
se seleccionan las de mayor importancia, se las organiza por tareas que serán ejecutadas en
el Sprint.
15
Scrum y Xp desde las trincheras, (KNIBERG, 2007).
- 24 -
En la fase de Análisis y Diseño se identificara el modo en que se realizara el proceso de
desarrollo del producto. En nuestro caso lo vamos a descomponer en procesos con tareas
pequeñas y se definirá el modelo para la base de datos.
En la fase de Evaluación se realiza un control a lo largo del ciclo de vida de la iteración que
consiste en comprobar y aceptar los resultados luego de cada desarrollo o armar una
estrategia para mejorarla o reforzar la implementación.
En la fase de Control de Calidad se ejecutan pruebas para que el resultado esperado del
desarrollo se cumpla.
2.3.1. Objetivo de Scrum
El objetivo es la satisfacción del cliente así como el de disminuir el tiempo de desarrollo de
una aplicación con calidad a través de un equipo de trabajo muy organizado y auto
gestionado. Los requerimientos pueden ser modificados en el avance del proyecto. A
continuación se presenta un gráfico general de los procesos SCRUM.
Procesos SCRUM
Sprint BacklogSprint
Product Backlog
Aná
lisis/D
iseñ
oRequisitos
Eva
luac
ión
QA
Software
Incremental
Requerimientos
de usuario
Planeamiento
de las
iteraciones
Ejecución del
Sprint
Versión del
sistema
Figura 5: Procesos Scrum. Fuente: Tesista. Autor: Tesista.
2.3.2. Componentes del proceso Scrum
Pila de producto (Product backlog). Representa a un lista ordenada, priorizada y estimada
de los requerimientos o historias de usuario de alto nivel del cliente, en si es el alcance del
proyecto. La definición de la pila de producto puede ser realizada entre el cliente y el equipo
de trabajo.
Pila de Sprint (Sprint backlog). Cada iteración se lo conoce como un Sprint y representa
un periodo de corta duración de entre 2 y 6 semanas, el equipo de trabajo decide que es lo
que tiene que desarrollar primero y se debe finalizar con un producto funcional y operativo.
Lo que se va a implementar en cada sprint viene de la pila de producto.
- 25 -
2.3.3. Roles
Cliente (Product owner). Es el dueño del producto e identifica las necesidades que deben
cumplirse, priorizando lo más importante y es continuamente asesorado por el equipo de
desarrollo en temas técnicos. Es el responsable de actualizar la pila de producto.
Facilitador (Scrum master). Es la persona que ayuda al equipo de trabajo y al Product
Owner a finalizar con éxito el proyecto, organizando cada etapa en el desarrollo del
producto.
Equipo de trabajo (Team members). Es un equipo técnico formado por profesionales
multifuncionales y auto organizados, que cubren varios roles y son los encargados de
seleccionar las tareas de la pila de sprint según su prioridad para ser implementada.
2.4. Marco teórico
Los proceso de productos, facturación, inventario y servicio técnico antes mencionados para
TECNOGALAXY CIA. LTDA. Están implementados en un único sistema web centralizado
con permisos por usuario. Adicionalmente los datos de la aplicación están debidamente
actualizados y disponibles para que la aplicación funcione correctamente y presente la
información precisa en el momento que sean requeridos por los usuarios con acceso a
repositorios de datos y repositorio de reportes.
2.5. Metodología de desarrollo
2.5.1. Programación extrema (XP)
Es una metodología ágil para el desarrollo de software que permite al programador
mantener una comunicación fluida entre el equipo de trabajo y el cliente ya sea en temas
técnicos como en requerimientos del sistema. Por ser una metodología ágil disminuye el
tiempo de implementación de las aplicaciones y de cambios que puedan surgir durante el
proceso. Permite liberar software funcional en corto tiempo, soporta la integración con
cambios realizados las estimaciones y planificaciones son proporcionadas por el equipo de
trabajo.
El marco de trabajo ágil SCRUM se enfoca en las prácticas de organización y de gestión del
proyecto mientras que la metodología XP se centra más en las prácticas de programación de
aplicaciones. Es por esta razón y por experiencia adquirida se puede afirmar que pueden
combinarse ambas y que funcionan tan bien juntas ya que tratan de áreas diferentes y se
complementan satisfactoriamente entre ellas.
Algunas prácticas de XP son fusionadas y tratadas directamente por SCRUM y se podrían
ver como interacciones entre ambas. Estas prácticas podrían ser las reuniones de equipo,
historias de usuario, evaluaciones y planificaciones.
- 26 -
2.5.2. Diseño incremental
Es una de las prácticas de la metodología XP y significa comenzar con un diseño simple al
momento de desarrollar la aplicación e irlo mejorando continuamente, aportando con
cambios en su arquitectura sin impactos fuertes de tal manera que siempre se obtenga un
modelo funcional para el usuario. Otras metodologías inician con un modelo en la
arquitectura muy cerrado.
Las mejoras que pueden realizarse en la aplicación se describen a continuación:
Refactorización del código en cada desarrollo o implementación.
Mejoras en el diseño de la aplicación, estilos.
Mejoras en la arquitectura de la aplicación.
Actualización de modelos y esquemas de datos.
2.5.3. Integración continua
Implica que la mayoría de productos desarrollados cuenten con un entorno de integración
continuo, En nuestro desarrollo lo lograremos con la utilización de MAVEN que nos ayuda
a desarrollar módulos integrables compilarlos y empaquetarlos en archivos binarios para
llevarlos al servidor de tal manera que cada entregable funcional este completo y listo para
ser probado. Esto nos ayudara por que se ahorra muchísimo tiempo al momento unir una
nueva funcionalidad a la aplicación.
2.5.4. Estandarización de código
Apoya la utilización de estándares de programación al crear clases, atributos, métodos y
constantes. Esto a lo largo del desarrollo permite tener una regla única de programación con
código entendible y liviano. Para este fin nos basaremos en los estándares de codificación
del lenguaje JAVA.
2.5.5. Ritmo sostenible / Trabajo enérgico
La metodología de desarrollo ágil XP afirman que mantener jornadas de desarrollo muy
extendidas es contraproducente para obtener un software de calidad. Para ello recomiendan
disminuir las jornadas de trabajo hasta un máximo de 8 horas diarias con intervalos de
descanso para centrarse en lo que se debe hacer y hacerlo bien.
2.5.6. Fase de pruebas
Es considerada la parte más dura en el desarrollo de software. En el mundo SCRUM ideal al
final de la iteración se produce una versión instalable de nuestro sistema pero la experiencia
nos dice que no. Puesto que al liberar un producto estable luego de la iteración éste es
susceptible a tener errores por tal motivo es necesario pasar por la fase de pruebas para
garantizar un producto de calidad.
- 27 -
Equipo PruebasUsuariosVersión 1.0
Versión 1.1
Versión 1.1
Figura 6: Fase de pruebas luego del desarrollo. Fuente: Tesista. Autor: Tesista.
Con la “fase de pruebas” nos referimos a todo el periodo de pruebas, correcciones y
relanzamiento del producto hasta que haya una versión suficientemente estable y buena
como para instalar en producción.
- 28 -
CAPÍTULO 3
3. DESARROLLO
El presente capitulo pretende describir las fases de desarrollo del sistema de control de
procesos para TECNOGALAXY, siguiendo los lineamientos del marco de trabajo
SCRUM. En cada iteración se realizaran las tareas planificadas, evaluaciones de riesgos,
retroalimentaciones y un análisis del trabajo realizado. Para la implementación de cada
módulo se hará el uso de diagramas de procesos.
Un diagrama de proceso, es una forma gráfica de representar las actividades de alguna
operación dentro de un sistema, organización. Y con esto se pretende tener una visión de lo
que se tiene que realizar y cómo interactúa cada actividad dentro del proceso asociado a sus
actores.
3.1. Requerimientos o pila de productos (Product backlog)
Para iniciar un proyecto de software partimos de un grupo de requisitos o requerimientos
que un cliente nos proporciona o son necesidades identificadas para cubrir alguna
funcionalidad dentro de un sistema ya implementado.
Un requerimiento es una característica que un sistema debe tener para la satisfacción de un
cliente, mostrando todo lo que debe hacer más las restricciones en su funcionalidad.
Se identifican los tipos de requerimientos funcionales y no funcionales dentro de un
sistema.
3.1.1. Requerimientos funcionales
Éstos describen la interacción o el comportamiento externo del sistema, es la acción que
debe ser capaz de realizar la aplicación ante una petición hecha por el usuario. En
conclusión son las funciones del sistema que debe cumplir de acuerdo a lo solicitado por el
cliente.
Usuario
Aplicación
Petición
Respuesta
Figura 7: Caso de uso interacción usuario - sistema. Fuente: Tesista. Autor: Tesista.
- 29 -
3.1.2. Requerimientos no funcionales
Éstos básicamente son aspectos del sistema que no interfieren directamente con la
funcionalidad del mismo o pueden incluir restricciones como los detallados a continuación.
Usabilidad.- Factores humanos.
Confiabilidad.- Frecuencia de fallas, tiempo de recuperación.
Performance.- Tiempo de respuesta, procesamiento, precisión, capacidad de
carga.
Soporte.- Mantenerlo y configurable.
Interfaces.- Comunicación con sistemas externos.
Restricciones.- Uso de sistemas o paquetes, plataformas, lenguajes y
herramientas.
3.1.3. Requerimientos o pila de productos
Los requerimientos de la aplicación para TECNOGALAXY CIA. LTDA. Es el resultado de
la investigación a las necesidades que tiene la organización para administrar sus procesos
adecuadamente. Se han mantenido reuniones con su gerente para poder tener un mejor
entendimiento de dichos procesos.
Basados en el marco de trabajo SCRUM como punto de partida del proyecto es definir la
pila de producto o Product Backlog. En base a la investigación realizada y reuniones con el
gerente de la empresa se han definido y estimado una lista de requisitos ordenados y
priorizados.
Estos requisitos o historias de usuario son básicamente cosas y funcionalidades que el
gerente de TECNOGALAXY quiere de la aplicación y han sido descritas utilizando la
terminología propia del cliente.
Nuestras historias de usuario incluyen los siguientes campos:
Id.- Identificador único y auto-incremental de cada historia de usuario o
requerimiento.
Descripción.- Descripción corta de la historia de usuario o requerimiento.
Importancia (I).- Es la importancia que ha dado el gerente a cada requisito y la
calificaremos en el rango de 1 a 10, siendo 10 la calificación de mayor
importancia.
Estimación (E).- Es la valoración dada a cada requisito acerca del trabajo
necesario a realizar para cumplir con dicha historia de usuario. La valoración
está realizada en semanas de trabajo, Scrum recomienda estimar períodos de
desarrollo de menos de 6 semanas.
Pruebas (Testing).- Breve descripción de como probar la funcionalidad.
Notas.- Se puede agregar una descripción adicional resumida.
- 30 -
Una vez realizado el análisis de los procesos y requerimientos nuestro cliente nos
proporcionó los datos funcionales que desea del sistema y son los siguientes:
Id. Descripción I E Testing Notas
1 Permisos para el ingreso al
sistema.
10 4 Ingreso al sistema con
usuario y clave.
Seguridades.
2 Registro y mantenimiento de
locales.
10 2 Registrar de los locales
de TECNOGALAXY.
Multiagencia.
3 Registro y mantenimiento de
personas.
10 2 Guardar información
de clientes/empleados.
Personas.
4 Registro y mantenimiento de
productos por local.
10 2 Ingresar productos a
cada local.
Productos.
5 Movimientos de productos
entre locales.
9 2 Pasar productos de un
local a otro.
Transferencias
.
6 Entradas y salidas de
productos. 8 2
Llevar un control de los
productos que entran y
salen.
Kardex.
7 Registro de compras de
productos.
7 2 Adquisiciones de
productos por
proveedor.
Compras.
8 Registro de ventas y
devoluciones.
10 3 Venta de productos. Facturación
9 Registro de pagos de clientes. 9 1 Pagos por ventas a
crédito.
Créditos.
10 Ingreso y mantenimiento de
órdenes de trabajo.
9 2 Servicio técnico. Servicio.
11 Consultas de ventas. 10 1 Extraer información de
ventas en PDF/XLS.
Reportes.
12 Consulta de pagos. 9 1 Comprobantes de
pagos.
Comprobante.
13 Consultas de productos. 7 1 Extracción de
información.
N/A
14 Consulta de compras. 8 1 Extracción de
información.
N/A
15 Consultas de órdenes de
trabajo
9 2 Extracción de
información.
N/A
Totales: Promedio importancia de requerimientos 8,5/10
Total 16 semanas de trabajo estimado.
Tabla 12: Pila de productos descritos en forma general por el cliente. Fuente: Tesista. Autor: Tesista.
- 31 -
En la Tabla 12 se presenta un resumen global de lo que la aplicación debe realizar, estos
datos fueron obtenidos directamente del cliente y del alcance de la investigación.
3.1.4. Pila de productos en módulos
Una vez obtenidos las historias de usuario en su alto nivel podemos pasar a la planificación
del Sprint o tareas a realizar por cada requerimiento, la experiencia nos dice que después de
obtener los requisitos tenemos que asegurarnos que la “Pila de Producto” este perfectamente
organizada y priorizada antes de la reunión de planificación del Sprint.
Esto quiere decir que todas las historias de usuario deben estar perfectamente bien definidas
y entendidas, revisar que las estimaciones estén correctas con el equipo técnico, que todas
las prioridades en las tareas hayan sido fijadas.
Una recomendación funcional nos dice que podemos agrupar las historias de usuario
comunes en módulos de tal manera poder separar grupos de tareas específicas y que pueden
ser complementos a otras funcionalidades.
Analizando detenidamente y agrupando todas las historias de usuario hemos definido la
siguiente tabla. Han sido separados en módulos y algunos requerimientos han sido
analizados hasta obtener una definición al más bajo nivel posible.
Id. Módulo Requerimiento
E
Testing
Estimación
(Semanas)
1
4.
Seguridades.
Componente de autenticación.
Ingreso al sistema por
usuario y contraseña.
Ingreso, mantenimiento
y activación de
usuarios.
Cambio de contraseña.
2
Componente de autorización.
Ingreso y
mantenimiento de
perfiles de usuario.
Registro de terminales.
Políticas de seguridad.
Menús y permisos por
transacción.
2
Total de trabajo de semanas. 4
2 Personas. Ingreso y mantenimiento de
personas naturales y jurídicas.
1
- 32 -
Parámetros de personas.
Ingreso y
mantenimiento de
sector, actividades y
actividades por sector
económico.
1
Total de trabajo de semanas. 2
3 Configuración técnica
Ingreso y mantenimiento de
módulos, canales, idiomas,
monedas, parámetros generales,
secuencias, transacciones y
resultados.
1
Ingreso y mantenimiento de
componentes de negocio.
Definición de
comandos y códigos de
consulta.
Definición y
parametrización de los
comandos de consulta.
Definición y
parametrización de
comandos de
mantenimiento.
2
Total de trabajo de semanas. 3
4 Parámetros del sistema
Ingreso y mantenimiento de
catálogos, países, provincias,
cantones, parroquias, ciudades
nacionalidades, compañías,
sucursales, agencias y áreas.
0,5
Total de trabajo de semanas. 0,5
5 Almacén Ingreso y mantenimiento de
parámetros, marcas, impuestos,
secciones, niveles y perchas.
0,5
- 33 -
Productos del almacén.
Registro y
mantenimiento de
productos por agencia.
Movimiento y
recepción de productos
entre agencias.
Ingresos y salidas de
productos (Kardex).
Registro, devoluciones
y consultas de
productos.
2
Ventas de productos.
Registro de ventas de
productos
(Facturación).
Registro de pagos.
Consultas de ventas y
pagos.
1,5
Servicio técnico, registro,
mantenimiento y seguimiento de
órdenes de trabajo.
1,5
Consulta de órdenes de trabajo. 1
Total de trabajo de semanas. 6,5
Total: 16 semanas de trabajo
Tabla 13: Requerimientos y estimación por parte del equipo técnico y cliente. Fuente: Tesista. Autor: Tesista.
En la Tabla 13 se presentan los requerimientos o historias de usuario organizadas por
módulos y priorizado ascendentemente. Estos módulos no necesariamente representaran
nuestras iteraciones (Sprints) en el ciclo de vida de nuestro proyecto sino que se pueden
tomar de varios módulos para organizar una iteración.
3.1.5. Organización de trabajo
El trabajo a ser realizado lo hemos organizado de la siguiente manera:
Cada semana consta de 5 días de trabajo.
Cada día de trabajo consta de 8 horas.
De esta forma podemos medir el avance del proyecto, retrasos o sobreestimaciones de algún
requerimiento mediante gráficos que nos indicaran el estado real del proyecto en su avance.
- 34 -
SCRUM utiliza el diagrama BURN-DOWN que represente al conjunto de horas por día
estimado de trabajo, cada tarea a cumplir esta en función de horas de trabajo, en teoría
deberían cumplirse y seguir la línea marcada en azul que es lo ideal en el avance, pero en lo
real no sucede. Si al tomar los datos en la primera semana de trabajo estos están debajo de la
línea azul significa que hay una sobreestimación de tareas y sería necesario incluir más al
sprint, caso contrario si sobrepasa es una alarma porque hay demasiadas tareas en el sprint o
que se han subestimado las mismas y que puede ser que sean quitadas de la planificación.
Figura 8: Gráfico BURN-DOWN del avance de cada Sprint. Fuente: Tesista. Autor: Tesista.
3.2. Planificación de iteraciones o Sprints
Una vez organizados los requerimientos pasamos a la planificación de los Sprints. No es
más que la elaboración de una táctica que nos permita conseguir el mejor resultado posible
minimizando esfuerzos. Esta actividad la realizaremos nosotros como equipo de trabajo
dado que adquirimos el compromiso y somos los responsables de organizar el trabajo y
realizarlo ya que somos los indicados de cómo hacerlo.
Cada iteración es un conjunto de tareas técnicas a ser realizadas, las podemos organizar
tomando de diferentes módulos, la idea es tener un máximo 4 semanas de trabajo por cada
iteración, al final de ésta podemos entregar algo funcional que se ajuste a lo solicitado en los
requerimientos, pueden haber tareas no planificadas y que se necesiten de implementación
también los estimaremos tiempos y responsables para cada una de ellas.
Vamos a definir cada Sprint en períodos de 5 semanas que serían 25 días, a un ritmo de
trabajo de 8 horas diarias y así poder medir el avance y esfuerzo realizado en cada iteración.
0
20
40
60
80
100
120
140
160
180
0 5 10 15 20 25
Ho
ras
rest
ante
s d
e t
rab
ajo
Fecha o días de planificación
Gráfico Burn-down
Avance
- 35 -
3.3. Planificación Sprint - 1
Ahora pasamos a la planificación de las tareas a ser realizadas, es el punto de partida en la
implementación del sistema. La organización de la primera iteración es muy importante ya
que de ésta recogeremos todas las observaciones, retroalimentaciones y evaluaciones del
avance de la implementación para mejorar el tiempo de desarrollo y procesos futuros.
Anteriormente habíamos definido con el gerente de TECNOGALAXY los requerimientos
en un alto nivel, posteriormente los reorganizamos para poder tener una mejor orden y
entendimiento un poco más precisa de cómo funcionará la aplicación.
Hubieron detalles técnicos en la planificación que no se tomaron en cuenta como estimación
en tiempos de configuraciones e instalaciones de las herramientas pero no nos preocupemos
que esos detalles los manejaremos internamente en el grupo de trabajo y los evaluaremos
para su implementación y serán tomados en cuenta en este Sprint y posteriormente serán
mejorados según el avance del proyecto y las necesidades que surjan.
3.3.1. Tareas Sprint 1
Luego de la reunión técnica se organizaron las tareas que no forman parte de la
planificación inicial pero que forman parte fundamental del equipo de trabajo y que tiene
una alta prioridad. En esta primera iteración se tomaron en cuenta tareas técnicas y
requerimientos que son necesarios para el ingreso a la aplicación.
Id. No
.
Requerimiento
E
Testing
Tareas Estimació
n (días)
NO
PL
AN
IFIC
AD
AS
1
Instalación y
configuración de
herramientas de
desarrollo.
IDE’s de desarrollo Eclipse
Kepler y Netbeans 7.3.
Herramienta de construcción de
proyectos Maven 3.0.4.
Diseñador de reportes Pentaho
PRD 3.9.
Cliente de base de datos
PostgreSQL 9.3 PgAdmin III.
1
2
Instalación y
configuración de
servidores.
Servidor de aplicaciones jboss-
as-7.2.0.
Servidor de reportes Pentaho Bi-
Server 4.5.
Gestor de base de datos
PostgreSQL 9.3.
2
- 36 -
3
Configuración del
esquema Fron-End,
Back-End y ambiente
de desarrollo.
Definición de la capa del Front-
End.
Definición de la capa del Back-
End.
Definición del proyecto para las
entidades de la base de datos.
Definición del proyecto para la
parte del CORE.
Definición del proyecto para la
parte de generales y seguridades.
8 1
. S
EG
UR
IDA
DE
S
5.
4
Definición del esquema
de base de datos para
seguridades y generales
e ingreso al sistema
mediante usuario y
contraseña.
Modelo E-R de la base de datos
de generales y seguridades.
Script para base de datos.
Mapeo de entidades de generales
y seguridades.
Desarrollo de la pantalla para el
ingreso a la aplicación.
3
5
Transacciones para el
ingreso y
mantenimiento de
perfiles, terminales,
políticas de seguridad,
menús y permisos por
transacción.
Desarrollo de las pantallas de
perfiles, terminales, políticas de
seguridad, menús y permisos por
transacción.
4
6
Transacciones para el
ingreso, mantenimiento
y activación y cambio
de contraseña de
usuarios.
Desarrollo de las pantallas para
el ingreso, mantenimiento,
activación y cambio de
contraseñas de usuarios.
4
2.
PE
RS
ON
AS
7
Ingreso y
mantenimiento de
personas naturales y
jurídicas.
Modelo E-R para el esquema de
ingreso y mantenimiento de
personas naturales y jurídicas.
Script de base de datos.
Mapeo de entidades de personas.
2
8 Parámetros de
personas.
Modelo E-R para el esquema de
parámetros de personas.
Script de base de datos.
Mapeo de entidades de
parámetros de personas.
1
Total de planificación para 5 semanas. 25 Días
Tabla 14: Planificación Sprint 1. Fuente: Tesista. Autor: Tesista.
- 37 -
3.3.2. Implementación
En la Tabla 14 tenemos la planificación de las tareas para el primer Sprint. Está conformada
por 8 tareas de dos requerimientos, uno de no planificado por el cliente ya que es parte del
desarrollo y organización del grupo de trabajo. Está organizado para 5 semanas de trabajo el
cual tiene la implementación del módulo de seguridades para el ingreso al sistema y la
definición del esquema para el módulo de personas.
3.3.2.1. Instalación y configuración de herramientas de desarrollo
Es una tarea que el equipo decidió ponerlo en la primera planificación, consiste en instalar y
preparar los aplicativos y configurarlos para iniciar el desarrollo. No es parte de los
requerimientos del usuario pero es fundamental dentro del equipo ya que se organizan y
configuran las herramientas para el inicio del sistema. En la Figura 9 se presenta un
resumen de los aplicativos a ser instalados.
Herramientas para el desarrollo de la aplicación
Navegadores Web
Cliente de Base de Datos pgAdmin III
Visualizador de Documentos PDF
IDE Eclipse Kepler
IDE NetBeans 7.3
Maven 3.0.4
Diseñador de Reportes Pentaho 3.9
Figura 9: Aplicativos para el desarrollo de la aplicación. Fuente: Tesista. Autor: Tesista.
- 38 -
3.3.2.2. Instalación y configuración de servidores
En esta tarea instalaremos y configuramos los servidores que utilizará la aplicación. El
servidor de aplicaciones, descargar de la página de JBOSS. Luego instalar el gestor de base
de datos descargarlo de la página de POSTGRESQL y finalmente el servidor de reportes
descargado de la página de PENTAHO.
Servidores a utilizar
Servidor de Aplicaciones
jboss-as-7.2.0.Final
Servidor de Base de Datos
PostgreSql 9.3
Servidor de Reportes
Pentaho Bi-Server 4.5
Figura 10: Servidores a utilizar por la aplicación. Fuente: Tesista. Autor: Tesista.
3.3.2.3. Configuración del front-end y back-end.
Una vez preparadas las herramientas de desarrollo definimos el esquema Fornt-End y Back-
End que son las capas de la aplicación. Haremos uso de MAVEN para organizar los
proyectos definiremos un proyecto para la parte web y otro con un conjunto de proyectos
para la parte de las operaciones con la base de datos, seguridades y otros módulos de la
aplicación.
Front-End, Proyecto Web Java que contiene paginas dinámicas JSF con
extensión XHTML, recursos para páginas y clases que gestionan tanto la lógica
de presentación como la de comunicación con el Back-End y de llamada a
reportes.
Beck-End, Conjunto de proyectos que gestionan la comunicación entre la base
de datos y Front-End, encargado de realizar las operaciones DML (lenguaje de
manipulación de datos) los cuales corresponden a las operaciones básicas de
inserción, modificación, borrado y consulta de datos. Se organizó el proyecto de
tal manera que se puedan definir módulos independientes dependiendo del
requerimiento del negocio. Definición de un proyecto base para el mapeo de las
entidades de la base de datos.
- 39 -
3.3.2.4. Definición del esquema de seguridades y generales.
Se va implementar un sistema con un modelo de ingreso por usuario y contraseña, el mismo
que tendrá el acceso a pantallas o transacciones según el perfil asignado ha dicho usuario.
Usuario
Ingreso al
sistemaAutenticación de
usuario
Autorización de
usuario
Figura 11: Caso de uso del modelo de autenticación y autorización. Fuente: Tesista. Autor: Tesista.
Se define el siguiente modelo de procesos para el ingreso al sistema, el cual receptará el
usuario y contraseña ingresada por el usuario, la aplicación validará internamente con los
usuarios registrados en la base de datos y que estén activos, éste control lo realizará un
comando de negocio el cual permitirá el ingreso a la aplicación o caso contrario entregara
una respuesta de que no ha podido ingresar al sistema.
Proceso de autenticación y autorización
Sis
tem
a
au
toriza
ció
n
Sis
tem
a
au
ten
tica
ció
nU
su
ario
InicioIngreso de
credenciales
Verifica
credenciales
Ingreso
satisfactorioFinVerifica usuarios
Si
ActivosVerifica caducidad
de credencialesSi
Fin
Caducado
Ingreso no
satisfactorioNo
SiRegistrado
No
Presenta perfiles y
menús de
transacciones
Figura 12: Proceso para la autenticación y autorización del sistema. Fuente: Tesista. Autor: Tesista.
Se organizará el esquema de la base de datos según el módulo al que pertenezca, se definirá
un modelo como se planificó en los requerimientos, por ejemplo para seguridades,
configuraciones, personas, almacén y servicio técnico.
Para el inicio del desarrollo vamos a diseñar el esquema de base de datos para
configuraciones, seguridades y personas ya que son necesarias para el inicio del desarrollo
de la aplicación.
Diseño del modelo de configuraciones estarán las tablas de usos generales en la aplicación,
los organizamos según se los requiera en el desarrollo, ahora están las tablas de
- 40 -
configuraciones generales. En el modelo tenemos las tablas para el ingreso de empresas,
catálogos, módulos, idiomas, resultados de errores, parámetros generales, secuencias de
registros, sucursales, agencias y áreas.
Figura 13: Modelo E-R de configuraciones generales. Fuente: Tesista. Autor: Tesista.
Modelo para la definición de archivos que se puedan implementar, pertenece a generales.
Figura 14: Modelo E-R para archivos. Fuente: Tesista. Autor: Tesista.
FKTGENCATAGDETTCATALOGO
FKTGENSUCTCOMPANIA
FKTGENAGENTSUCURSAL
FKTGENAREATCOMPANIA
FKTGENEPARAMETCOMPANIA
FKTGENRESULTADOTCATALOG
FKTGENAGENTGENCIUD
TGENCOMPANIA
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
TGENCATALOGO
CCATALOGO
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
TGENCATALOGODETALLE
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TGENSUCURSAL
CSUCURSAL
CCOMPANIA
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
<pk,fk>
TGENAGENCIA
CAGENCIA
CSUCURSAL
CCOMPANIA
OPTLOCK
NOMBRE
CPAIS
CPPROVINCIA
CCANTON
CCIUDAD
DIRECCION
TELEFONO
PRINCIPAL
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC
VARCHAR(60)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(300)
VARCHAR(20)
VARCHAR(1)
<pk>
<pk,fk1>
<pk,fk1>
<fk2>
<fk2>
<fk2>
<fk2>
TGENIDIOMA
CIDIOMA
OPTLOCK
NOMBRE
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
TGENCANALES
CCANAL
OPTLOCK
NOMBRE
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
TGENAREA
CAREA
CCOMPANIA
OPTLOCK
NOMBRE
NUMERIC(3)
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
<pk,fk>
TGENMODULO
CMODULO
OPTLOCK
NOMBRE
NUMERIC(2)
NUMERIC
VARCHAR(60)
<pk>
TGENPARAMETROS
CODIGO
CCOMPANIA
TEXTO
NUMERO
OPTLOCK
NOMBRE
VARCHAR(30)
NUMERIC(4)
VARCHAR(50)
NUMERIC(19,7)
NUMERIC
VARCHAR(120)
<pk>
<pk,fk>
TGENMONEDA
CMONEDA
OPTLOCK
NOMBRE
DECIMALES
VARCHAR(3)
NUMERIC
VARCHAR(60)
NUMERIC(1)
<pk>
TGENRESULTADOS
CRESULTADO
CCATALOGO
CDETALLE
MENSAJE
CACHE
OPTLOCK
VARCHAR(12)
NUMERIC(4)
VARCHAR(6)
VARCHAR(150)
VARCHAR(1)
NUMERIC
<pk>
<fk>
<fk>
TGENCIUDAD
(localidad)
CPAIS
CPPROVINCIA
CCANTON
CCIUDAD
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk,fk>
<pk,fk>
<pk>TGENSECUENCIA
CSECUENCIA
VALORINICIAL
VALORFINAL
VALORINCREMENTO
CICLICA
VALORACTUAL
DESCRIPCION
VARCHAR(12)
NUMERIC(15)
NUMERIC(15)
NUMERIC(15)
VARCHAR(1)
NUMERIC(15)
VARCHAR(80)
<pk>
FKTGENARCHIVODETTARCHIVO
TGENARCHIVO
CARCHIVO NUMERIC(10) <pk>
TGENARCHIVODETALLE
CARCHIVO
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
ARCHIVO
EXTENSION
TAMANIO
NOMBREARCHIVO
TIPODECONTENIDO
NUMERIC(10)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
CHAR
VARCHAR(6)
NUMERIC(10)
VARCHAR(80)
VARCHAR(60)
<pk,fk>
<pk>
- 41 -
Diseño del modelo para la “División Política” de cada país o localidad como lo hemos
denominado en el esquema. Consideramos el ingreso de Países, Provincias, Cantones,
Ciudades y Parroquias.
Figura 15: Modelo E-R de la división política. Fuente: Tesista. Autor: Tesista.
Diseño del modelo de Transacciones, aquí se define a cada transacción como una página
web que se presentará al usuario dentro de la aplicación. Se pretende con esto que se pueda
separar a cada transacción según al módulo que pertenezcan para así tener una mejor
organización.
FKTGENPROVTGENPAIS
FKTGENCANTONTPROVINCIA
FKTGENCIUDADTGENCANTONFKTGENPARROQUIATGENCANTON
TGENPAIS
CPAIS
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk>
TGENPROVINCIA
CPAIS
CPPROVINCIA
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk>
TGENCANTON
CPAIS
CPPROVINCIA
CCANTON
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk,fk>
<pk>
TGENCIUDAD
CPAIS
CPPROVINCIA
CCANTON
CCIUDAD
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk,fk>
<pk,fk>
<pk>
TGENPARROQUIA
CPAIS
CPPROVINCIA
CCANTON
CPARROQUIA
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk,fk>
<pk,fk>
<pk>
TGENNACIONALIDAD
CNACIONALIDAD
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk>
- 42 -
Figura 16: Modelo E-R de transacciones. Fuente: Tesista. Autor: Tesista.
Diseño del modelo de Comandos de Negocio, aquí definimos las tablas para los comandos
de negocio o clases java. La idea de este modelo es de separar la lógica de negocio de la
lógica de presentación. Este esquema se define con la idea de no tener lógica de negoción en
la parte del Front-End, sino que toda ésta lógica se ejecute en el Back-End con llamadas a
clases Java. Las clases Java serán invocadas por cada transacción, por eso cada comando se
lo parametriza con cada transacción para que realice una rutina específica ya sea de
consulta, mantenimiento o simplemente un proceso paralelo.
FKTGENETRANSTMODULO
FKTGENTRANLOGTGENETRANSAC
TGENMODULO
(general)
CMODULO
OPTLOCK
NOMBRE
NUMERIC(2)
NUMERIC
VARCHAR(60)
<pk>
TGENTRANSACCION
CTRANSACCION
CMODULO
OPTLOCK
NOMBRE
PAGINA
AUTOCONSULTA
CACHE
COMPCOMPANIA
COMPMONCOMPANIA
COMPRUBROCOMPANIA
INMOBILIZACION
COMPLETARUBROS
REGISTRALOG
MAPEARUBROS
NUMERIC(4)
NUMERIC(2)
NUMERIC
VARCHAR(80)
VARCHAR(80)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
<pk>
<pk,fk>
TGENTRANSACCIONLOG
MENSAJE
CTRANSACCION
CMODULO
FREAL
FCONTABLE
CAGENCIA
CSUCURSAL
CCOMPANIA
IPSERVIDOR
TIEMPO
CTERMINAL
CUSUARIO
TIPO
CRESPUESTA
MENSUSUARIO
VARCHAR(50)
NUMERIC(4)
NUMERIC(2)
DATE
NUMERIC(8)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
VARCHAR(19)
NUMERIC(7,3)
VARCHAR(19)
VARCHAR(20)
VARCHAR(1)
VARCHAR(12)
VARCHAR(250)
<pk>
<fk>
<fk>
TGENTRANSACCIONTAB
CTRANSACCION
CMODULO
SECUENCIA
ORDEN
TITULO
PAGINA
AUTOCONSULTA
CONSULTA
CREAFUNCIONES
ACTIVO
NUMERIC(4)
NUMERIC(2)
NUMERIC(2)
NUMERIC(2)
VARCHAR(30)
VARCHAR(80)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
<pk,fk>
<pk,fk>
<pk>
FKTGENTRANTABTGENTRAN
- 43 -
Figura 17: Modelo E-R de comandos de negocio. Fuente: Tesista. Autor: Tesista.
Diseño del modelo de Seguridades, aquí se presenta el diseño relacional para el esquema de
autenticación y autorización. Con esto se pretende validar el ingreso de usuarios a la
aplicación previamente registrados, que cuenten con políticas de seguridad definidas por la
empresa y que puedan ser modificables con controles de sesiones y de perfiles. Cada perfil
presentará el menú con un conjunto de transacciones, a un usuario se podrá definir varios
perfiles.
TGENCOMPONENTE : 1
CCOMPONENTE
OPTLOCK
CCATALOGO
CDETALLE
NOMBRE
DESCRIPCION
VARCHAR(150)
NUMERIC
NUMERIC(4)
VARCHAR(6)
VARCHAR(60)
VARCHAR(200)
<pk>
<fk>
<fk>
FKTGENCOMPONENTETCATADET
FKTGENCOMPCONSULTTRANS
FKTGENCOMPCONCOMPTTRANS
FKTGENCOMPCODCONTCOM
FKTGENCOMPMANTETTRANS
FKTGENCOMPMANTETCOMPATRANS
FKTGENCOMPMANTETCANAL
FKTGENCOMPMANTETCOMPATCANAL
FKTGENCOMPMANTETCOMP
TGENCOMPANIA
(general)
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
TGENCOMPCODIGO
CCONSULTA
CCANAL
OPTLOCK
NOMBRE
VARCHAR(30)
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
<pk,fk>
FKTGENCOMPMANTETCOMPATCOMP
FKTGENCOMPMANTETCOMPATCIA
FKTGENCOMPCONCOMPTCOMPA
FKTGENCOMPCODTCANALES
FKTGENCOMPCODCONTCOMCOD
FKTGENCOMPCONCOMPTCODCONS
FKTGENCOMPCONSULTCODCONS
TGENCATALOGODETALLE
(general)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TGENCOMPCONSULTA
CTRANSACCION
CMODULO
CCONSULTA
CCANAL
OPTLOCK
NUMERIC(4)
NUMERIC(2)
VARCHAR(30)
VARCHAR(3)
NUMERIC
<pk,fk1>
<pk,fk1>
<pk,fk2>
<pk,fk2>
TGENCOMPCONSULTACOMPANIA
CTRANSACCION
CMODULO
CCONSULTA
CCANAL
CCOMPANIA
OPTLOCK
NUMERIC(4)
NUMERIC(2)
VARCHAR(30)
VARCHAR(3)
NUMERIC(4)
NUMERIC
<pk,fk1>
<pk,fk1>
<pk,fk3>
<pk,fk3>
<pk,fk2>
TGENCOMPCODIGOCONSULTA
CCONSULTA
CCANAL
SECUENCIA
CCOMPONENTE
OPTLOCK
ORDEN
ACTIVO
VARCHAR(30)
VARCHAR(3)
NUMERIC(2)
VARCHAR(150)
NUMERIC
NUMERIC(2)
VARCHAR(1)
<pk,fk2>
<pk,fk2>
<pk>
<fk1>
TGENTRANSACCION
(trans)
CTRANSACCION
CMODULO
OPTLOCK
NOMBRE
PAGINA
AUTOCONSULTA
CACHE
COMPCOMPANIA
COMPMONCOMPANIA
COMPRUBROCOMPANIA
INMOBILIZACION
COMPLETARUBROS
REGISTRALOG
MAPEARUBROS
NUMERIC(4)
NUMERIC(2)
NUMERIC
VARCHAR(80)
VARCHAR(80)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
<pk>
<pk,fk>
TGENCANALES : 1
(general)
CCANAL
OPTLOCK
NOMBRE
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
TGENCOMPONENTE : 2
CCOMPONENTE
OPTLOCK
CCATALOGO
CDETALLE
NOMBRE
DESCRIPCION
VARCHAR(150)
NUMERIC
NUMERIC(4)
VARCHAR(6)
VARCHAR(60)
VARCHAR(200)
<pk>
<fk>
<fk>
TGENCOMPMANTENIMIENTO
CTRANSACCION
CMODULO
SECUENCIA
CCANAL
CCOMPONENTE
OPTLOCK
ORDEN
ACTIVO
REVERSO
CFLUJO
PAQUETE
NUMERIC(4)
NUMERIC(2)
NUMERIC(2)
VARCHAR(3)
VARCHAR(150)
NUMERIC
NUMERIC(2)
VARCHAR(1)
VARCHAR(1)
VARCHAR(30)
VARCHAR(80)
<pk,fk1>
<pk,fk1>
<pk>
<pk,fk2>
<fk3>
TGENCOMPMANTENIMIENTOCOMPANIA
CTRANSACCION
CMODULO
SECUENCIA
CCANAL
CCOMPANIA
CCOMPONENTE
OPTLOCK
ORDEN
ACTIVO
REVERSO
CFLUJO
PAQUETE
NUMERIC(4)
NUMERIC(2)
NUMERIC(2)
VARCHAR(3)
NUMERIC(4)
VARCHAR(150)
NUMERIC
NUMERIC(2)
VARCHAR(1)
VARCHAR(1)
VARCHAR(30)
VARCHAR(80)
<pk,fk1>
<pk,fk1>
<pk>
<pk,fk2>
<pk,fk4>
<fk3>
TGENCANALES : 2
(general)
CCANAL
OPTLOCK
NOMBRE
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
- 44 -
Figura 18: Modelo E-R de seguridades. Fuente: Tesista. Autor: Tesista.
FKTSEGUSURIOTCOMPANIA
FKTSEGUSUDETTUSUARIO
FKTSEGUSUDETTPERSONA
FKTSEGUSUDETTAGENCIA
FKTSEGUSUDETTCATALOGO
TSEGUSUARIO : 1
CUSUARIO
CCOMPANIA
CINTERNO
VARCHAR(20)
NUMERIC(4)
NUMERIC(6)
<pk>
<pk,fk>
TGENCOMPANIA : 1
(general)
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
TPERPERSONA
(persona)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TGENAGENCIA
(general)
CAGENCIA
CSUCURSAL
CCOMPANIA
OPTLOCK
NOMBRE
CPAIS
CPPROVINCIA
CCANTON
CCIUDAD
DIRECCION
TELEFONO
PRINCIPAL
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC
VARCHAR(60)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(300)
VARCHAR(20)
VARCHAR(1)
<pk>
<pk,fk1>
<pk,fk1>
<fk2>
<fk2>
<fk2>
<fk2>
FKTSEGUSUDETTIDIOMA
FKTSEGUSUDETTCANALES
FKTSEGUSUDETTAREA
FKTSAFETERMINALTAGENCIA
FKTSAFETERMINALTAREA
FKTSEGUSUSESSIONTUSUARIO
TSEGROLTCOMPANIA
FKTSEGUSUARIOROLTUSUARIO
FKTSEGUSUARIOROLTROL
FKTSEGPOLITICATCOMPANIA
TSEGROL : 2
CROL
CCOMPANIA
OPTLOCK
NOMBRE
ACTIVO
NUMERIC(3)
NUMERIC(4)
NUMERIC
VARCHAR(60)
VARCHAR(1)
<pk>
<pk,fk>
TSEGUSUARIOROL
CUSUARIO
CCOMPANIA
CROL
VERREG
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
VARCHAR(20)
NUMERIC(4)
NUMERIC(3)
NUMERIC(4)
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
<pk,fk1>
<pk,fk1,fk2>
<pk,fk2>
<pk>
TSEGAUDITORIA
FECHA
TABLA
CAMPO
PARTICION
FREAL
CUSUARIO
CTERMINAL
CAGENCIA
CSUCURSAL
CCOMPANIA
CTRANSACCION
CMODULO
VALORANTERIOR
VALORNUEVO
NUMERIC(8)
VARCHAR(30)
VARCHAR(30)
NUMERIC(6)
DATE
VARCHAR(20)
VARCHAR(15)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(2)
VARCHAR(4000)
VARCHAR(4000)
<pk>
<pk>
<pk>
<pk>
<pk>
<fk>
<fk>
TSEGPOLITICA
CCOMPANIA
CCANAL
LONGITUD
DIASVALIDEZ
DIASMENSAJEDEINVALIDEZ
INTENTOS
REPETICIONES
NUMEROS
ESPECIALES
MINUSCULAS
MAYUSCULAS
NUMERIC(4)
VARCHAR(3)
NUMERIC(2)
NUMERIC(4)
NUMERIC(2)
NUMERIC(1)
NUMERIC(3)
NUMERIC(2)
NUMERIC(2)
NUMERIC(2)
NUMERIC(2)
<pk,fk1>
<pk,fk2>
TSEGUSUARIO : 2
CUSUARIO
CCOMPANIA
CINTERNO
VARCHAR(20)
NUMERIC(4)
NUMERIC(6)
<pk>
<pk,fk>
TSEGROLOPCIONES
CROL
CCOMPANIA
COPCION
VERREG
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
OPTLOCK
COPCIONPADRE
CTRANSACCION
CMODULO
NOMBRE
ORDEN
ACTIVO
NUMERIC(3)
NUMERIC(4)
VARCHAR(9)
NUMERIC(4)
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
NUMERIC
VARCHAR(9)
NUMERIC(4)
NUMERIC(2)
VARCHAR(60)
NUMERIC(2)
VARCHAR(1)
<pk,fk1>
<pk,fk1>
<pk>
<pk>
<fk2>
<fk2>
TSEGUSUARIOSESSIONHISTORIA
CUSUARIO
FCREACION
CCOMPANIA
CTERMINAL
NUMEROINTENTOS
IDSESSION
IPWEBSERVER
FINICIO
FSALIDA
VARCHAR(20)
DATE
NUMERIC(4)
VARCHAR(19)
NUMERIC(2)
VARCHAR(50)
VARCHAR(19)
DATE
DATE
<pk>
<pk>
<pk>
TSEGROLOPCIONTRANSACCION
CROL
CTRANSACCION
CMODULO
VERREG
CCOMPANIA
CUSUARIOING
VERACTUAL
CUSUARIOMOD
FINGRESO
FMODIFICACION
OPTLOCK
CREAR
EDITAR
ELIMINAR
NUMERIC(3)
NUMERIC(4)
NUMERIC(2)
NUMERIC(4)
NUMERIC(4)
VARCHAR(20)
NUMERIC(4)
VARCHAR(20)
DATE
DATE
NUMERIC
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
<pk,fk1>
<pk,fk2>
<pk,fk2>
<pk>
<pk,fk1>
FKTSEGPOLITICATCANALES
FKTSEGAUDITORIATUSUARIO
FKTSEGROLOPCIONESTROL
FKTSEGROLOPCIONESTTRANSACCION
FKTSEGROLOPCIONTRANSTROL
FKTSEGROLOPCIONTRANSTTRANS
TGENCATALOGODETALLE
(general)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>TSEGUSUARIODETALLE
CUSUARIO
CCOMPANIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
CPERSONA
CAGENCIA
CSUCURSAL
ESTATUSCUSUARIOCATALOGO
ESTATUSCUSUARIOCDETALLE
CIDIOMA
CCANAL
CAREA
SOBRENOMBRE
PASSWORD
AGENCIADELTERMINAL
USUARIOBPM
CAMBIOPASSWORD
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
VARCHAR(6)
VARCHAR(3)
VARCHAR(3)
NUMERIC(3)
VARCHAR(30)
VARCHAR(50)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
<pk,fk1>
<pk,fk1,fk2,fk3,fk7>
<pk>
<fk2>
<fk3>
<fk3>
<fk4>
<fk4>
<fk5>
<fk6>
<fk7>
TGENIDIOMA
(general)
CIDIOMA
OPTLOCK
NOMBRE
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
TGENCANALES
(general)
CCANAL
OPTLOCK
NOMBRE
VARCHAR(3)
NUMERIC
VARCHAR(60)
<pk>
TGENAREA
(general)
CAREA
CCOMPANIA
OPTLOCK
NOMBRE
NUMERIC(3)
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
<pk,fk>
TSEGTERMINAL
CTERMINAL
CAGENCIA
CSUCURSAL
CCOMPANIA
VERREG
VERACTUAL
CUSUARIOING
FINGRESO
CUSUARIOMOD
FMODIFICACION
CAREA
MAC
IMPRESORASLIP
VARCHAR(15)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
VARCHAR(20)
DATE
VARCHAR(20)
DATE
NUMERIC(3)
VARCHAR(20)
VARCHAR(50)
<pk>
<pk,fk1>
<pk,fk1>
<pk,fk1,fk2>
<pk>
<fk2>
TSEGUSUARIOSESSION
CUSUARIO
CCOMPANIA
CTERMINAL
NUMEROINTENTOS
IDSESSION
IPWEBSERVER
FINICIO
FSALIDA
ACTIVO
VARCHAR(20)
NUMERIC(4)
VARCHAR(19)
NUMERIC(2)
VARCHAR(50)
VARCHAR(19)
DATE
DATE
VARCHAR(1)
<pk,fk>
<pk,fk>
TGENCOMPANIA : 2
(general)
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
TGENTRANSACCION
(transacciones)
CTRANSACCION
CMODULO
OPTLOCK
NOMBRE
PAGINA
AUTOCONSULTA
CACHE
COMPCOMPANIA
COMPMONCOMPANIA
COMPRUBROCOMPANIA
INMOBILIZACION
COMPLETARUBROS
REGISTRALOG
MAPEARUBROS
NUMERIC(4)
NUMERIC(2)
NUMERIC
VARCHAR(80)
VARCHAR(80)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
VARCHAR(1)
<pk>
<pk,fk>
TSEGROL : 1
CROL
CCOMPANIA
OPTLOCK
NOMBRE
ACTIVO
NUMERIC(3)
NUMERIC(4)
NUMERIC
VARCHAR(60)
VARCHAR(1)
<pk>
<pk,fk>
- 45 -
3.3.2.5. Transacciones para la configuración de seguridades
En la tarea cinco se desarrollarán las transacciones de configuraciones de seguridades, que
consisten en el ingreso y mantenimiento de perfiles o roles de usuario, terminales o
estaciones de trabajo, políticas de seguridad para la contraseña, definición de menús
asociados a cada perfil y permisos por transacción que habilitará o deshabilita las opciones
de ingreso, modificación y eliminación de una pantalla.
Módulo Transacción Nombre Descripción
SE
GU
RID
AD
ES
(CO
NF
IGU
RA
CIÓ
N)
2-3 Perfiles. Perfiles de usuario.
2-4 Terminales. Estación de trabajo.
2-5 Políticas de seguridad. Parámetros de contraseña.
2-6 Menús. Menús asociados a perfiles.
2-11 Permisos por transacción. Permisos de transacciones.
Tabla 15: Transacciones de configuración de seguridades. Fuente: Tesista. Autor: Tesista.
3.3.2.6. Transacciones para el mantenimiento de usuarios
En esta tarea se desarrollarán las transacciones para el ingreso y mantenimiento de los
usuarios que utilizarán la aplicación, además se define una transacción para activar a los
usuarios creados y otra para el cambio de contraseñas. Estas transacciones interactúan con
la definición de personas así que fue necesario crear el esquema que se detalla en la tarea
siete.
- 46 -
Módulo Transacción Nombre Descripción
SE
GU
RID
AD
ES (
US
UA
RIO
S) 2-7 Ingreso de usuarios.
Ingreso de un usuario dado una
persona.
2-8 Mantenimiento de
usuarios.
Mantenimiento de usuarios
activos o inactivos.
2-9 Activación de
usuarios.
Activación de usuarios
ingresados.
2-10 Cambio de
contraseñas.
Cambio de contraseña del
usuario.
Tabla 16: Transacciones de usuarios. Fuente: Tesista. Autor: Tesista.
3.3.2.7. Definición del esquema de personas
En esta tarea se va a crear el modelo entidad relación de Personas, primero creamos la tabla
maestro para el ingreso del código de las personas.
Figura 19: Modelo E-R del maestro de personas. Fuente: Tesista. Autor: Tesista.
El ingreso de clientes, empleados y proveedores se lo realizara en el módulo de personas,
tiene una tabla maestro para el código de la persona y un conjunto de tablas de detalle para
la información general y se los clasifica en personas naturales y jurídicas.
TPERPERSONA
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TGENCOMPANIA
(general)
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
FKTPERPERSONATCOMPANIA
- 47 -
Figura 20: Modelo E-R para la información general de personas. Fuente: Tesista. Autor: Tesista.
FKTPERPERSONADETTPERPERSONA
FKTPERACTIXSECTACTIECONO
FKTPERPERSDETTIPOIDETCATDETAT
FKTPERPERSDETOFICIALTUSUARIO
FKTPERPERSDETUSUMODTUSUARIO
FKTPERPERSDETUSUINGTUSUARIO
FKTPERDIRECCIONTPERSONA
FKTPERDIRECCIONUSUINGTUSU
FKTPERDIRECCIONUSUMODTUSU
FKTPERDIRECCIONTIPODIRTCATA
FKTPERDIRECCIONTCIUDAD
FKTPERPERDETTEJECUTIVOPERPER
FKTPERPERDETFOTOTARCHIVO
FKTPERPERDETFIRMATARCHIVO
FKTPERPERDETACTXSECTACTXSEC
FKTPERPERDETTSECECONO
FKTPERPERDETTACTECONOMICA
FKTPERDIRECCIONTPARROQUIA
TGENCIUDAD
(<PhysicalDataModelF4>)
CPAIS
CPPROVINCIA
CCANTON
CCIUDAD
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk,fk>
<pk,fk>
<pk>
TGENARCHIVO
(<PhysicalDataModelF4>)
CARCHIVO NUMERIC(10) <pk>TGENPARROQUIA
(<PhysicalDataModelF4>)
CPAIS
CPPROVINCIA
CCANTON
CPARROQUIA
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk,fk>
<pk,fk>
<pk,fk>
<pk>
TPERPERSONA
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TPERPERSONADETALLE
CPERSONA
CCOMPANIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
NOMBRE
TIPOIDENTIFICACCATALOGO
TIPOIDENTIFICACDETALLE
IDENTIFICACION
CUSUARIOOFICIALCLIENTE
EXONERADOIMPUESTOS
CPERSONAEJECUTIVO
ESPERSONANATURAL
CARCHIVOFOTO
CARCHIVOFIRMA
CACTIVIDADXSECTOR
CSECTORECONOMICO
CACTIVIDAD
TIPODEPERSONA
TIPOACTIVIDAD
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
VARCHAR(100)
NUMERIC(4)
VARCHAR(6)
VARCHAR(20)
VARCHAR(20)
VARCHAR(1)
VARCHAR(120)
NUMERIC(10)
VARCHAR(1)
NUMERIC(10)
NUMERIC(10)
VARCHAR(10)
VARCHAR(4)
VARCHAR(4)
VARCHAR(1)
VARCHAR(1)
<pk,fk1>
<pk,fk1,fk3,fk4,fk5,fk6>
<pk>
<fk5>
<fk4>
<fk2>
<fk2>
<fk3>
<fk6>
<fk7>
<fk8>
<fk9>
<fk10>
<fk11>
TPERACTIVIDADECONOMICA
CACTIVIDAD
OPTLOCK
NOMBRE
TIPOACTIVIDAD
VARCHAR(4)
NUMERIC
VARCHAR(100)
VARCHAR(1)
<pk>
TPERACTIVIDADPORSECTOR
CSECTOR
CACTIVIDAD
OPTLOCK
NOMBRE
CIIU
VARCHAR(10)
VARCHAR(4)
NUMERIC
VARCHAR(200)
VARCHAR(20)
<pk>
<fk>
TGENCATALOGODETALLE : 1
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TSEGUSUARIO : 1
(<PhysicalDataModelF4>)
CUSUARIO
CCOMPANIA
CINTERNO
VARCHAR(20)
NUMERIC(4)
NUMERIC(6)
<pk>
<pk,fk>
TPERSECTORECONOMICO
CSECTORECONOMICO
OPTLOCK
NOMBRE
VARCHAR(4)
NUMERIC
VARCHAR(100)
<pk>
TPERPERSONADIRECCION
CPERSONA
CCOMPANIA
SECUENCIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
TIPODIRECCIONCCATALOGO
TIPODIRECCIONCDETALLE
CPAIS
CPPROVINCIA
CCANTON
CCIUDAD
CPARROQUIA
DIRECCION
TELEFONOFIJO
EXTENCION
CELULAR
PRINCIPAL
NUMERIC(10)
NUMERIC(4)
NUMERIC(2)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
NUMERIC(4)
VARCHAR(6)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(3)
VARCHAR(2000)
VARCHAR(20)
NUMERIC(6)
VARCHAR(20)
VARCHAR(1)
<pk,fk1>
<pk,fk1,fk2,fk3>
<pk>
<pk>
<fk2>
<fk3>
<fk4>
<fk4>
<fk5,fk6>
<fk5,fk6>
<fk5,fk6>
<fk5>
<fk6>
TSEGUSUARIO : 2
(<PhysicalDataModelF4>)
CUSUARIO
CCOMPANIA
CINTERNO
VARCHAR(20)
NUMERIC(4)
NUMERIC(6)
<pk>
<pk,fk>
TGENCATALOGODETALLE : 2
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
- 48 -
Ahora se presenta el modelo para el ingreso de la información de personas naturales.
Figura 21: Modelo E-R de personas naturales. Fuente: Tesista. Autor: Tesista.
Adicional en el ingreso de personas naturales de define el modelo para información
adicional y de trabajo.
FKTPERNATURALTPERSONA
FKTPERNATURALESTCIVTCATALOGO
FKTPERNATURALNIVESTUTCATALOGO
FKTPERNATURALPROFTCATALOGO
FKTPERNATURALUSUMODTUSUARIO
FKTPERNATURALUSUINGTUSUARIO
FKTPERNATURALTNACIONALIDAD
TPERNATURAL
CPERSONA
CCOMPANIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
APELLIDOPATERNO
APELLIDOMATERNO
PRIMERNOMBRE
SEGUNDONOMBRE
GENERO
ESTADOCIVILCCATALOGO
ESTADOCIVILCDETALLE
NIVELESTUDIOSCCATALOGO
NIVELESTUDIOSCDETALLE
PROFESIONCCATALOGO
PROFESIONCDETALLE
CNACIONALIDAD
FNACIMIENTO
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
VARCHAR(20)
VARCHAR(20)
VARCHAR(20)
VARCHAR(20)
VARCHAR(1)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
VARCHAR(3)
DATE
<pk,fk1>
<pk,fk1,fk5,fk6>
<pk>
<fk6>
<fk5>
<fk2>
<fk2>
<fk3>
<fk3>
<fk4>
<fk4>
<fk7>
TPERPERSONA : 1
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TGENCATALOGODETALLE : 1
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TSEGUSUARIO
(<PhysicalDataModelF4>)
CUSUARIO
CCOMPANIA
CINTERNO
VARCHAR(20)
NUMERIC(4)
NUMERIC(6)
<pk>
<pk,fk>
TGENNACIONALIDAD
(<PhysicalDataModelF4>)
CNACIONALIDAD
NOMBRE
OPTLOCK
VARCHAR(3)
VARCHAR(60)
NUMERIC
<pk>
- 49 -
Figura 22: Modelo E-R de información adicional y trabajos de personas naturales. Fuente: Tesista. Autor: Tesista.
En personas jurídicas se define el siguiente modelo para el ingreso de información general.
Figura 23: Modelo E-R de personas jurídicas. Fuente: Tesista. Autor: Tesista.
FKTPERTRAJOTCATALOGO
FKTPERTRAJOTIPOCONTTCATALOGO
FKTPERTRAJOTPERSONA
FKTPERTRAJOEMPLEADORTPERSONA
FKTPERINFOADICIONALTPERSONA
FKTPERINFADITIPOVIVTCATALOGO
TPERTRABAJO
CPERSONA
CCOMPANIA
SECUENCIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
TRABAJOCCATALOGO
TRABAJOCDETALLE
TIPOCONTARTOCCATALOGO
TIPOCONTARTOCDETALLE
CPERSONAEMPLEADOR
NOMBREEMPLEADOR
FINGRESOTRABJO
FSALIDATRABAJO
DIRECCION
NUMERIC(10)
NUMERIC(4)
NUMERIC(2)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
NUMERIC(10)
VARCHAR(80)
DATE
DATE
NUMERIC(2)
<pk,fk3>
<pk,fk3,fk4>
<pk>
<pk>
<fk1>
<fk1>
<fk2>
<fk2>
<fk4>
TGENCATALOGODETALLE : 2
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TPERPERSONA : 2
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
FKTPERINFADIRELDEPTCATALOGO
FKTPERINFADIORIGINGRESOSTCATA
TPERINFORMACIONADICIONAL
CPERSONA
CCOMPANIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
TIPOVIVIENDACCATALOGO
TIPOVIVIENDACDETALLE
RELACIONDEPENDENCIACCATALOGO
RELACIONDEPENDENCIACDETALLE
ORIGENINGRESOSCCATALOGO
ORIGENINGRESOSCDETALLE
TIEMPOVIVIENDAACTUAL
CARGASFAMILIARES
VALORVIVIENDA
PATRIMONIO
FACTUALIZACIONPATRIMONIO
TOTALINGRESOS
TOTALEGRESOS
NUMEROEMPLEADOS
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
NUMERIC(2)
NUMERIC(2)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(8)
NUMERIC(15,2)
NUMERIC(15,2)
NUMERIC(5)
<pk,fk1>
<pk,fk1>
<pk>
<fk2>
<fk2>
<fk3>
<fk3>
<fk4>
<fk4>
FKTPERJURIDICATPERSONA
FKTPERJURIDICATSECTORECONOMICOFKTPERJURIDICAUSUINGTUSUARIO
FKTPERJURIDICAUSUMODTUSUARIO
FK_TPERJURI_REFERENCE_TPERPERS
TPERJURIDICA
CPERSONA
CCOMPANIA
VERREG
OPTLOCK
VERACTUAL
CUSUARIOING
CUSUARIOMOD
FINGRESO
FMODIFICACION
CSECTORECONOMICO
CPERSONAREPRESENTANTELEGAL
FCONSTITUCION
FCADUCIDAD
REGISTROMERCANTIL
REGISTROPATRONAL
NUEMROEMPLEADOS
NUMEROSOCIOS
CAPITALNOMINAL
CAPITALORIGINAL
CAPITALSUSCRITO
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
NUMERIC
NUMERIC(4)
VARCHAR(20)
VARCHAR(20)
DATE
DATE
VARCHAR(4)
NUMERIC(10)
DATE
DATE
VARCHAR(20)
VARCHAR(20)
NUMERIC(5)
NUMERIC(6)
NUMERIC(19,7)
NUMERIC(19,7)
NUMERIC(19,7)
<pk,fk1>
<pk,fk1,fk3,fk4,fk5>
<pk>
<fk3>
<fk4>
<fk2>
<fk5>
TPERPERSONA
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TPERSECTORECONOMICO
(personas)
CSECTORECONOMICO
OPTLOCK
NOMBRE
VARCHAR(4)
NUMERIC
VARCHAR(100)
<pk>
TSEGUSUARIO
(<PhysicalDataModelF4>)
CUSUARIO
CCOMPANIA
CINTERNO
VARCHAR(20)
NUMERIC(4)
NUMERIC(6)
<pk>
<pk,fk>
- 50 -
3.3.2.8. Definición del esquema de parámetros de personas
Se definirá el modelo entidad relación para los parámetros de personas que es información
adicional y que es estática. Representa a las actividades económicas en caso de ser una
persona jurídica es información adicional y que fue definida como requerimiento del
usuario.
Figura 24: Modelo E-R de parámetros de personas. Fuente: Tesista. Autor: Tesista.
3.3.3. Evaluación
El modelo entidad relación se definió previa reunión con el cliente y bajo sus necesidades,
ha sido aceptada y se inició con el modelamiento.
En el primer Sprint hemos definido los esquemas para la base de datos de la aplicación, y
desarrollado transacciones de configuraciones y de usuarios. Resumiendo hemos logrado
modelar la parte de seguridades, configuraciones generales, personas y adicional se
desarrolló el Back-End que consta de un CORE genérico para la creación, modificación y
eliminación de registros, y un motor de ejecución de componentes de negocio por
transacción.
Se realizó una Prueba de Calidad interna ya que en esta fase de la implementación todos
los procesos son técnicos y hubo correcciones que aplicar a los desarrollos ya realizados, se
corrigieron los errores y se mejoraron procesos, y se estandarizo la creación de las páginas.
TPERACTIVIDADECONOMICA
CACTIVIDAD
OPTLOCK
NOMBRE
TIPOACTIVIDAD
VARCHAR(4)
NUMERIC
VARCHAR(100)
VARCHAR(1)
<pk>
TPERACTIVIDADPORSECTOR
CSECTOR
CACTIVIDAD
OPTLOCK
NOMBRE
CIIU
VARCHAR(10)
VARCHAR(4)
NUMERIC
VARCHAR(200)
VARCHAR(20)
<pk>
<fk>
TPERSECTORECONOMICO
CSECTORECONOMICO
OPTLOCK
NOMBRE
VARCHAR(4)
NUMERIC
VARCHAR(100)
<pk>
FKTPERACTIXSECTACTIECONO
- 51 -
3.3.4. Análisis del trabajo realizado.
Para realizar un análisis del trabajo y de los tiempos definidos según la planificación
haremos uso del diagrama Burndown, que nos avisa si la planificación realizada se cumplió
según lo estimado, si hubo retrasos o sobreestimaciones en la implementación.
Figura 25: Gráfico Burn-Down Sprint 1. Fuente: Tesista. Autor: Tesista.
Según los datos tomados en el avance real de la implementación y con los datos estimados
se observa que en la primera semana de desarrollo hubo una subestimación de tareas las
cuales tomaron más tiempo del planificado. Para la segunda semana hubieron tareas sobre
estimadas ya que con el retraso que se tuvo en la primera semana se nivelo el trabajo. A
partir de la tercera semana el trabajo real tomó más del planificado y hubo retrasos en la
finalización de los desarrollos.
0
50
100
150
200
250
0 5 10 15 20 25 30
Ho
ras
rest
ante
s d
e t
rab
ajo
Fecha o días de planificación
Avance Sprint 1
Estimado
Real
- 52 -
3.4. Planificación Sprint - 2
Nos preparamos para la planificación del segundo Sprint. En el anterior Sprint se realizaron
tareas de configuraciones, ambientes de trabajo, modelamiento del esquema de base de
datos para la parte general de la aplicación como son configuraciones, seguridades y
personas. Ahora vamos realizar la organización y desarrollo de las páginas de parámetros,
configuraciones y personas.
3.4.1. Tareas Sprint 2
Organizamos las tareas para los módulos dos, tres y cuatro según el orden de los
requerimientos definidos en la pila de productos.
Los módulos a implementar son los de personas que en el sprint anterior sólo quedó el
modelo entidad relación, el de configuraciones técnicas y parámetros. Se realizarán las
pantallas de las transacciones generales utilizadas por toda la aplicación y de
parametrizaciones del sistema.
- 53 -
Id. No. Requerimiento
E
Testing
Tareas Estimación
(días) 2
. P
ER
SO
NA
S
1 Transacción de ingreso y
mantenimiento de
personas naturales.
Desarrollo de la pantalla para el
ingreso de la información de
personas naturales.
3
2
Transacción de ingreso y
mantenimiento de
personas jurídicas.
Desarrollo de la pantalla para el
ingreso y mantenimiento de la
información de personas jurídicas.
3
3
Transacciones de ingreso
y mantenimiento de
parámetros de personas.
Desarrollo de las pantallas para el
ingreso y mantenimiento de los
parámetros de personas (Sector,
Actividades Económicas y
Actividades por Sector).
2
3.
CO
NF
IGU
RA
CIÓ
N T
ÉC
NIC
A
6.
4
Transacciones de ingreso
y mantenimiento de
configuraciones técnicas
de la aplicación.
Desarrollo de las pantallas para
módulos, canales, idiomas,
monedas, parámetros, secuencias
transacciones y resultados.
4
5
Transacciones para la
definición de comandos
de negocio y códigos de
consulta.
Desarrollo de las pantallas
comandos de negocio y códigos de
consulta.
2
6
Transacción para la
definición de
componentes de consulta.
Pantalla para crear los comandos de
consulta y asignar a cada
transacción.
2,5
7
Transacción para la
definición de los
comandos de
mantenimiento.
Pantalla para asociar los comandos
de mantenimiento a cada
transacción.
2,5
4.
PA
RÁ
ME
TR
OS
DE
L S
IST
EM
A
8 Transacciones para
parámetros del sistema.
Desarrollo de las pantallas para
Catálogos, Países, Provincias,
Cantones, Ciudades, Parroquias,
Nacionalidades, Compañías,
Sucursales, Agencias y Áreas.
6
Total de planificación para 5 semanas. 25 Días
Tabla 17: Planificación Sprint 2. Fuente: Tesista. Autor: Tesista.
- 54 -
3.4.2. Implementación
Para el Sprint 2 se han planificado 25 días que representan 5 semanas de trabajo hombre. En
esta fase iniciamos los desarrollos de las transacciones de los módulos de configuraciones
técnicas, parámetros del sistema y personas. Adicionalmente se irán depurando los errores
de los desarrollos de la fase anterior de tal manera que el sistema se vuelva cada vez más
estable y escalable.
3.4.2.1. Transacción de personas naturales
En la tarea uno se va a desarrollar la transacción para el ingreso de personas. En esta
pantalla se puede registrar información general de clientes, empleados y proveedores con un
tipo de identificación como persona natural. Además so podrá registrar direcciones,
información del lugar de trabajo y datos adicionales.
Módulo Transacción Nombre Descripción
PE
RS
ON
AS
NA
TU
RA
LE
S
3-1 Creación personas
naturales.
Ingreso de personas naturales.
Ingreso de información
general.
Ingreso de direcciones.
Ingreso de datos del
trabajo.
Ingreso de información
adicional.
Tabla 18: Transacción de personas naturales. Fuente: Tesista. Autor: Tesista.
3.4.2.2. Transacción de personas jurídicas
En la tarea dos se van a desarrollar la transacción para el ingreso de empresas o personas
jurídicas y del ingreso de direcciones asociadas a dicha empresa.
- 55 -
Módulo Transacción Nombre Descripción
PE
RS
ON
AS
JU
RÍD
ICA
S
3-2 Creación personas
jurídicas.
Ingreso de un usuario dado una
persona.
Ingreso de información
general.
Ingreso de direcciones.
Tabla 19: Transacción de personas jurídicas. Fuente: Tesista. Autor: Tesista.
3.4.2.3. Transacciones de parámetros de personas
Desarrollo de las transacciones de parámetros para personas naturales y jurídicas. Se
registran datos que serán usados en el ingreso de la información general de personas.
Módulo Transacción Nombre Descripción
PE
RS
ON
AS
(GE
NE
RA
LE
S) 3-20 Sectores económicos.
Perfiles de usuario.
3-21 Actividades económicas. Estación de trabajo.
3-22 Actividades por sector. Parámetros de contraseña.
Tabla 20: Transacciones de parámetros de personas. Fuente: Tesista. Autor: Tesista.
3.4.2.4. Transacciones de configuraciones técnicas
Se desarrollarán las transacciones de configuraciones generales de la aplicación, incluyen la
definición de los módulos para asociar las transacciones, definición de canales para
parámetros de comandos, ingreso de idiomas, registro de monedas, registro de parámetros
generales, definición de secuencias para registros, definición de transacciones y registro de
resultados.
- 56 -
Módulo Transacción Nombre Descripción
CO
NF
IGU
RA
CIO
NE
S T
ÉC
NIC
AS
(G
EN
ER
AL
ES
) 0-1 Módulos.
Registro de módulos para
organizar la aplicación.
0-2 Canales.
Canales para definición de
comandos específicos.
0-3 Idiomas. Registro de idiomas.
0-4 Monedas. Registro de monedas.
0-5 Parámetros generales.
Registro de parámetros que
puede utilizar el sistema.
0-6 Secuencias.
Registro de secuencias a ser
utilizadas en otras procesos.
0-7 Transacciones.
Definición de transacciones,
nombre, página y módulo.
0-8 Resultados.
Registro de mensajes
aplicativos y de usuario.
Tabla 21: Transacciones de configuraciones técnicas generales. Fuente: Tesista. Autor: Tesista.
3.4.2.5. Transacciones de comandos de negocio
La tarea consiste en desarrollar las pantallas asociadas a las transacciones de definición de
comandos de negocio y códigos de consulta.
Se realiza una parametrización de clases java que van a ejecutar tareas específicas al ser
invocadas por una transacción.
- 57 -
Módulo Transacción Nombre Descripción
CO
NF
IGU
RA
CIO
NE
S T
ÉC
NIC
AS
(CO
MA
ND
OS
)
0-16 Comandos de negocio.
Permite registrar la
definición de clases Java a
ser ejecutadas por una
transacción. Realiza rutinas
de mantenimiento y
procesos paralelos.
0-17 Códigos de consulta.
Permite registrar
identificadores para
llamadas a clases java que
realizan tareas específicas al
momento de que una
transacción consulta datos.
Tabla 22: Transacción de comandos de negocio. Fuente: Tesista. Autor: Tesista.
3.4.2.6. Transacción de comandos de consulta
La tarea consiste en desarrollar la pantalla para asociar un código de consulta a un comando
de negocio de tal manera que ejecute una lógica de negocio específica al ser invocada.
Módulo Transacción Nombre Descripción
CO
NIG
UR
AC
ION
ES
TÉ
CN
ICA
S (
CO
MA
ND
OS
)
0-18 Comandos de consulta.
Permite asociar un código
de consulta a un comando
de negocio o clase Java para
ejecutar una tarea específica
al ser invocado en la
consulta de registros y
puede ser reutilizado por
otras transacciones.
Tabla 23: Transacción de comandos de consulta. Fuente: Tesista. Autor: Tesista.
3.4.2.7. Transacción de comandos de mantenimiento
La tarea consiste en desarrollar una pantalla para el ingreso de los comandos de
mantenimiento que son clases Java a ser invocadas para realizar tareas específicas al
momento de realizar un mantenimiento.
- 58 -
Módulo Transacción Nombre Descripción
CO
NIG
UR
AC
ION
ES
TÉ
CN
ICA
S (
CO
MA
ND
OS
)
0-19 Comandos de
mantenimiento.
Permite asociar un comando
de negocio o clase Java a
una transacción para
ejecutar una tarea específica
al realizar un mantenimiento
por dicha pantalla y puede
ser reutilizado por otras
transacciones.
Tabla 24: Transacción de comandos de mantenimiento. Fuente: Tesista. Autor: Tesista.
3.4.2.8. Transacciones de parámetros del sistema
La tarea consiste en desarrollar las pantallas para los parámetros del sistema que son ingreso
y mantenimiento de catálogos, distribución política, compañías, sucursales, agencias y
áreas.
Módulo Transacción Nombre Descripción
PA
RÁ
ME
TR
OS
DE
L S
IST
EM
A
GE
NE
RA
LE
S
1-1 Catálogos.
Registro de módulos para
organizar la aplicación.
1-10 Países.
Canales para definición de
comandos específicos.
1-11 Provincias. Registro de idiomas.
1-12 Cantones. Registro de monedas.
1-13 Parroquias.
Registro de parámetros que
puede utilizar el sistema.
1-14 Ciudades.
Registro de secuencias a ser
utilizadas en otras procesos.
1-15 Nacionalidade
s.
Definición de transacciones,
nombre, página y módulo.
- 59 -
CO
MP
AÑ
IA
1-3 Áreas.
Registro de las áreas de la
empresa.
1-4 Sucursales
Registro de las sucursales de
la empresa
1-5 Agencias.
Registro de las agencias de
la empresa.
1-8 Compañía Registro de empresas.
Tabla 25: Transacciones de parámetros del sistema. Fuente: Tesista. Autor: Tesista.
3.4.3. Evaluación
En el Sprint 2 realizamos tareas netamente de desarrollo de páginas. Se han logrado
completar las transacciones de personas naturales, configuraciones técnicas y parámetros
del sistema que no poseen alta complejidad en su implementación y no fue necesario
agregar lógica de negocio para su funcionamiento. A diferencia del módulo de personas las
demás transacciones son de uso general en la aplicación y que requiere de un conocimiento
técnico amplio para manipular su información o posteriores configuraciones.
El desarrollo de las pantallas casi fue repetitivo salvo que había que tener en cuenta a que
tablas hacían referencia. En si implica un proceso sencillo de mantenimiento de las pantallas
si se tiene un conocimiento de las herramientas utilizadas.
Se realizó una Prueba de Calidad interna y con el cliente ya que las transacciones
desarrolladas forman parte de la parte técnica y administrativa de la aplicación. Las pruebas
fueron solventadas se corrigieron errores y se mejoró la forma de hacer pantallas.
3.4.4. Análisis del trabajo realizado
En esta fase el avance en el cronograma estuvo por debajo de lo planificado ya que hubieron
pantallas que fueron utilizadas en más de una transacción, en la primera semana de trabajo
estuvimos por debajo de lo planificado con un día ya que una pantalla fue común para
personas naturales y jurídicas se redujo el tiempo de implementación. Para la segunda
semana hubo un día de retraso ya que el modelo para parámetros de personas naturales hubo
que modificarlo y no se consideró y que resultan en tareas no planificadas. A partir de la
tercera semana tenemos un adelanto en la planificación ya que se inició el desarrollo de las
pantallas de configuraciones y parámetros con lo que fue más rápido el desarrollo.
- 60 -
Figura 26: Gráfico Burn-Down Sprint 2. Fuente: Tesista. Autor: Tesista.
-50
0
50
100
150
200
250
0 5 10 15 20 25 30
Ho
ras
rest
ante
s d
e t
rab
ajo
Fecha o días de planificación
Avance Sprint 2
Estimado
Real
- 61 -
3.5. Planificación Sprint - 3
Nos preparamos para el inicio del Sprin 3 que es el más largo, inicialmente se lo planificó
para 6,5 semanas pero en ésta se planificó realizarlo en 6 semanas para poderlo medir y que
consiste en 30 días de trabajo hombre. Aquí se implementará el módulo de Almacén y que
tiene alta complejidad ya que se realizarán desarrollos que involucran implementar lógica
de negocio para varias transacciones.
3.5.1. Tareas Sprint 3
Presentamos la planificación para la última iteración en el desarrollo de la aplicación y
consta de varias tareas complejas así como de configuraciones a transacciones que
implementan una lógica de negocio para su funcionamiento.
Id. No. Requerimiento
E
Testing
Tareas Estimación
(días)
5.
AL
MA
CE
N
7.
1
Levantamiento de
procesos de la gestión
de productos en el
almacén.
Diseño del modelo de procesos
para el tratamiento de los
productos en el almacén.
2
2
Levantamientos de
procesos en las ventas
de los productos.
Diseño del modelo de procesos
para las ventas de productos.
2
3
Modelo entidad
relación para los
procesos en la gestión
de productos en el
almacén.
Diseño de base de datos y
mapeo de entidades para en
manejo de la información de
los productos, movimientos,
ingresos y devoluciones.
3
4
Modelo entidad
relación para los
procesos en la venta
de los productos.
Diseño de base de datos y
mapeo de entidades para el
registro de ventas, pagos y
consultas.
2
5
Registro
mantenimiento de
productos por agencia.
Desarrollo de las transacciones
para el registro y
mantenimiento de productos
por agencia.
4
6
Movimiento y
recepción de
productos por agencia.
Desarrollo de las transacciones
para el proceso de movimiento
y recepción de productos entre
sucursales.
4
7
Proceso de control en
el ingreso y salida de
productos.
Transacciones y procesos para
el ingreso y salida de
productos.
Consulta de inventarios.
4
- 62 -
8 Facturación y registro
de venta de productos.
Transacciones para el registro
de las ventas.
Registro de pagos.
Consulta y reporte de ventas de
productos.
Impresión de facturas.
4
9
Registro,
mantenimiento y
seguimiento de
órdenes de trabajo.
Transacción para el registro y
mantenimiento de órdenes de
trabajo.
Impresión de órdenes de
trabajo.
3
10 Consulta de órdenes
de trabajo.
Transacción para la consulta de
órdenes de trabajo.
2
Total de planificación para 6 semanas. 30 Días
Tabla 26: Planificación Sprint 3. Fuente: Tesista. Autor: Tesista.
3.5.2. Implementación
Para le implementación del módulo se mantuvieron reuniones continuas con el cliente para
poder obtener un entendimiento de los procesos y realizar una implementación de los
requerimientos de tal manera lograr la satisfacción del cliente.
- 63 -
3.5.2.1. Modelo de procesos de productos en almacén
Para el módulo de almacén se define el ingreso de productos de acuerdo al siguiente modelo
de procesos presentado por el cliente. Implica un registro y mantenimiento de productos, los
productos pueden ser dados de baja más no pueden ser eliminados, se puede registrar
productos en cada agencia así como registrar el producto en una agencia y moverlos entre
agencias según las necesidades.
Proceso de almacen
Ag
en
cia
Alm
ace
nA
dm
inis
tra
do
r
InicioRegistro de
productos
Gestión en
inventarioActualizar stock
Documento de
movimiento
Movimiento de
productos
Recepción de
productos
Reporte productosReporte productos
Actualiza stock
agencia
Documento
recepción de
productosFin
Reporte kardex
Figura 27: Modelo de Procesos de Productos. Fuente: TECNOGALAXY CIA. LTDA.
Autor: Tesista.
Adicionalmente se tiene que contemplar el proceso de ingresos de los productos al almacén
por concepto de compras a proveedores. En el caso de que se obtengan los productos es
necesario el registro del ingreso y de devoluciones de los productos. El registro se lo
realizara con la factura entregada por el proveedor se actualizará el stock y así mismo se
podrá restaurar el stock por devoluciones de productos a los proveedores.
Proceso de compras
Alm
ace
nC
om
pra
sP
rove
ed
or
No
Si
Actualizar stock
Existen
devoluciones
Factura de
compra
Registrar compra A
Ingresar a
inventario
Recibir documento
de compra
Revisar producto Fin
Factura de
compra anulada
Anular registro de
compra
Inicio A
Restaurar stockOrden de pedido
Figura 28: Modelo de procesos de compras a proveedores. Fuente: TECNOGALAXY CIA. LTDA.
Autor: Tesista.
- 64 -
3.5.2.2. Modelo de los procesos de facturación
En el módulo de almacén se define el siguiente modelo de procesos para la facturación de
los productos.
Proceso de ventas
Alm
ace
nV
en
tas
Clie
nte
No
Recibir orden de
compra
A
Revisar stock
AInicio
FinStock
disponible
Registrar venta
Si
ANo Actualizar stock
Imprimir factura
ARegistrar cobro
Pago realizado
Si
NoExisten
devoluciones
Anular cobro
Si
Restaurar stock
Anular factura
Figura 29: Modelo de proceso de facturación. Fuente: TECNOGALAXY CIA. LTDA.
Autor: Tesista.
En el proceso de facturación implica tener un control en la salida de los productos. Se tiene
que implementar un proceso de actualización del stock en cada agencia y la impresión de la
factura. Se tiene que contemplar las devoluciones de productos por defectos de fábrica la
cual implica la anulación de facturas y restaurar el stock.
3.5.2.3. Definición del esquema para los productos de almacén
Con los datos proporcionados por TECNOGALAXY procedemos a la definición del
esquema entidad relación para la base de datos de productos.
- 65 -
Figura 30: Modelo E-R detalle de productos. Fuente: Tesista. Autor: Tesista.
Ahora presentamos el modelo de productos por agencia, quiere decir que los productos
pueden estar registrados en una o varias agencias, además se realizará el modelo para el
registro de ingresos y salidas de productos.
FKTALMPRODTIPOPRODTGENCATA
FKTALMPRODUMEDTGENCATA
TALMPRODUCTODETALLE
CPRODUCTO
CCOMPANIA
VERREG
VERACTUAL
NOMBRE
PRECIOUNITARIO
MARGENVENTA
MARGEDISTRIBUIDOR
MARGENMAYORISTA
STOCKMINIMO
STOCKMAXIMO
STOCK
TOTAL
TIPOPRODCCATALOGO
TIPOPRODCDETALLE
UMEDIDACCATALOGO
UMEDIDACDETALLE
CPERSONA
PCCOMPANIA
CATECCATALOGO
CATECDETALLE
CMONEDA
CMARCA
CARCHIVO
FINGRESO
FMODIFICACION
CUSUARIOING
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
VARCHAR(150)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
VARCHAR(6)
VARCHAR(3)
NUMERIC(4)
NUMERIC(10)
DATE
DATE
VARCHAR(20)
<pk,fk4>
<pk,fk4>
<pk>
<fk1>
<fk1>
<fk2>
<fk2>
<fk3>
<fk3>
<fk5>
<fk5>
<fk6>
<fk7>
<fk8>
TALMPRODUCTO
CPRODUCTO
CCOMPANIA
VARCHAR(20)
NUMERIC(4)
<pk>
<pk,fk>
TALMIMPUESTOPRODUCTO
CIMPUESTO
CPRODUCTO
CCOMPANIA
OPTLOCK
NUMERIC(4)
VARCHAR(20)
NUMERIC(4)
NUMERIC
<pk,fk1>
<pk,fk2>
<pk,fk2>
TGENCATALOGODETALLE
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TALMMARCA
CMARCA
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
TGENCOMPANIA
(<PhysicalDataModelF4>)
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
TALMIMPUESTO
CIMPUESTO
OPTLOCK
NOMBRE
DESCRIPCION
VALORIMPUESTO
PORCENTAJE
TASA
NUMERIC(4)
NUMERIC
VARCHAR(60)
VARCHAR(100)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
<pk>
TPERPERSONA
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
FKTALMIMPUTALMIMPU
FKTALMPRODTGENCOMP
FKTALMPRODTPERPERS
FKTALMPRODTALMPROD
FKTALMIMPUTALMPROD
FKTALMPRODTGENCATAPROC
FKTALMPRODTGENMONE
FKTALMPRODTALMMARC
FKTALMPRODTGENARCH
TGENMONEDA
(<PhysicalDataModelF4>)
CMONEDA
OPTLOCK
NOMBRE
DECIMALES
VARCHAR(3)
NUMERIC
VARCHAR(60)
NUMERIC(1)
<pk>
TGENARCHIVO
(<PhysicalDataModelF4>)
CARCHIVO NUMERIC(10) <pk>
- 66 -
Figura 31: Modelo E-R productos por agencia. Fuente: Tesista. Autor: Tesista.
3.5.2.4. Definición del esquema para facturación
De acuerdo al modelo de procesos para la facturación procedemos a modelar el esquema
entidad relación para la base de datos.
TALMPRODUCTOAGENCIA
CPRODUCTO
CCOMPANIA
CSUCURSAL
CAGENCIA
VERREG
VERACTUAL
NOMBRE
CUSUARIOING
FINGRESO
CUSUARIOMOD
FMODIFICACION
FCONTABLE
FREAL
STOCK
STOCKMINIMO
STOCKMAXIMO
CSECCION
CPERCHA
CNIVEL
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
VARCHAR(150)
VARCHAR(20)
DATE
VARCHAR(20)
DATE
NUMERIC(8)
DATE
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
<pk,fk1>
<pk,fk1>
<pk>
<pk>
<pk>
<fk2>
<fk3>
<fk4>
TALMPRODUCTO : 1
(parametros)
CPRODUCTO
CCOMPANIA
VARCHAR(20)
NUMERIC(4)
<pk>
<pk,fk>
TALMDETALLEMOVIMIENTO
CMOVIMIENTO
CPRODUCTO
CCOMPANIA
CANTIDAD
VARCHAR(50)
VARCHAR(20)
NUMERIC(4)
NUMERIC(15,7)
<pk,fk2>
<pk,fk1>
<fk1>
TGENCATALOGODETALLE : 1
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TALMPRODUCTOMOVIMIENTO
CMOVIMIENTO
CCOMPANIA
DESCRIPCION
COMENTARIO
CUSUARIO
CUSUARIOREC
FCONTABLE
FREAL
FMOVIMIENTO
CCATALOGO
CDETALLE
OPTLOCK
FINGRESO
FMODIFICACION
CSUCURSALORIGEN
CAGENCIAORIGEN
CSUCURSALDESTINO
CAGENCIADESTINO
VARCHAR(50)
NUMERIC(4)
VARCHAR(60)
VARCHAR(80)
VARCHAR(20)
VARCHAR(20)
NUMERIC(8)
DATE
DATE
NUMERIC(4)
VARCHAR(6)
NUMERIC
DATE
DATE
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
NUMERIC(4)
<pk>
<fk2>
<fk1>
<fk1>
TGENCOMPANIA
(<PhysicalDataModelF4>)
CCOMPANIA
CPERSONA
OPTLOCK
NUMERIC(4)
NUMERIC(10)
NUMERIC
<pk>
TALMSECCION
CSECCION
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
TALMPERCHA
CPERCHA
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
TALMNIVEL
CNIVEL
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
FKTALMPRODAGETALMPROD FKTALPRODUTALMPRODMOV
TALMPRODUCTOKARDEX
SECUENCIA
CPRODUCTO
CCOMPANIA
CCATALOGOTIPO
CDETALLETIPO
FOPERACION
CANTIDAD
SALDO
PRECIOUNITARIO
PRECIO
PRECIOTOTAL
OPTLOCK
NUMERIC(22)
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
VARCHAR(6)
DATE
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(22)
<pk>
<pk,fk1>
<fk1>
<fk2>
<fk2>
TGENCATALOGODETALLE : 2
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TALMPRODUCTO : 2
(parametros)
CPRODUCTO
CCOMPANIA
VARCHAR(20)
NUMERIC(4)
<pk>
<pk,fk>
FKTALMPRODTGENCATAMOVCAB
FKTALMPRODTGENCOMPMOVI
FKTALMDETATALMPROD
FKTALMPRODTALMSECC
FKTALMPRODTALMPERC
FKTALMPRODTALMNIVE
FKTALMPRODTALMKDX
FKTALMKDXTGENCATA
- 67 -
Figura 32: Modelo E-R de facturación. Fuente: Tesista. Autor: Tesista.
3.5.2.5. Transacciones para registro de productos
Para el registro de los productos se crearon un conjunto de transacciones en la que constan
de parámetros y de administración y las describimos a continuación.
El módulo de almacén tendrá tres secciones, la primera denominado “Generales” que tienen
las transacciones de parámetros, la segunda “Productos” que tiene las transacciones de
administración de productos por almacén y la tercera “Ventas” que tiene las transacciones
de registro y consulta de venta de productos.
TALMFACTURA
CFACTURA
CPERSONA
CCOMPANIA
CORDEN
CCATALOGOFPAGO
CDETALLEFPAGO
CCATALOGOESTADO
CDETALLEESTADO
FFACTURA
FINGRESO
FMODIFICACION
CUSUARIOING
CUSUARIOMOD
FENTREGA
CSUCURSAL
CAGENCIA
SUBTOTAL
TOTAL
OPTLOCK
VARCHAR(20)
NUMERIC(10)
NUMERIC(4)
VARCHAR(20)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
DATE
DATE
DATE
VARCHAR(20)
VARCHAR(20)
DATE
NUMERIC(4)
NUMERIC(4)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(22)
<pk>
<fk3>
<fk3>
<fk1>
<fk1>
<fk2>
<fk2>
TGENCATALOGODETALLE : 1
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TALMFACTURADETALLE
CFACTURA
SECUENCIA
CPRODUCTO
CCOMPANIA
CIMPUESTO
DESCRIPCION
CANTIDAD
DESCUENTO
PRECIOINVENTARIO
PRECIO
PRECIOVENTA
PRECIOTOTAL
VALORIVA
CSUCURSAL
CAGENCIA
OPTLOCK
VARCHAR(20)
NUMERIC(4)
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
VARCHAR(80)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(4)
NUMERIC(4)
NUMERIC(22)
<pk,fk1>
<pk>
<fk2>
<fk2>
<fk3>
TPERPERSONA : 1
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TALMPAGOS
CFACTURA
SECUENCIA
CCATALOGOESTADO
CDETALLEESTADO
FPAGO
FRECEPCION
VALORPAGO
SALDO
OPTLOCK
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
VARCHAR(6)
DATE
DATE
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(22)
<pk,fk1>
<pk>
<fk2>
<fk2>
TALMPRODUCTO
(parametros)
CPRODUCTO
CCOMPANIA
VARCHAR(20)
NUMERIC(4)
<pk>
<pk,fk> TALMFACTURAPROVEEDOR
CFACTURA
FACTURAPROVEEDOR
CPERSONA
CCOMPANIA
CCATALOGOESTADO
CDETALLEESTADO
FFACTURA
SUBTOTAL
TOTAL
OPTLOCK
VARCHAR(20)
VARCHAR(30)
NUMERIC(10)
NUMERIC(4)
NUMERIC(4)
VARCHAR(6)
DATE
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(22)
<pk>
<fk1>
<fk1>
<fk2>
<fk2>
FKTALMFACTTGENCATAL
FKTALMFACTTALMFACT
FKTALMFACTTGENCATA
FKTALMFACTTPERPERS
FKTALMPAGOTALMFACT
FKALMPAGOTGENCATA
FKTALMFACTDETALMPROD
FKTALMFACTPRTPERPERS
FKTALMFACTDETPROV
FKTALMFACTPROVTGENCATA
FKTALMFACTTALMIMPU
TALMFACTIRADETALLEPROV
CFACTURA
SECUENCIA
CANTIDAD
OPTLOCK
PRECIOCOMPRA
DESCRIPCION
VARCHAR(20)
NUMERIC(4)
NUMERIC(15,7)
NUMERIC(22)
NUMERIC(15,7)
VARCHAR(80)
<pk,fk>
<pk>
TPERPERSONA : 2
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TGENCATALOGODETALLE : 2
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TALMIMPUESTO
(parametros)
CIMPUESTO
OPTLOCK
NOMBRE
DESCRIPCION
VALORIMPUESTO
PORCENTAJE
TASA
NUMERIC(4)
NUMERIC
VARCHAR(60)
VARCHAR(100)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC(15,7)
<pk>
- 68 -
Módulo Transacción Nombre Descripción
AL
MA
CÉ
N (
GE
NE
RA
LE
S)
30-1 Marcas. Registro de marcas de
productos.
30-2 Impuestos. Registro de impuestos que
puede manejar un producto.
30-3 Secciones.
Registro de secciones,
creado para organizar los
productos dentro de la
agencia.
30-4 Perchas.
Registro de perchas, creado
para organizar los productos
en la agencia.
30-5 Niveles.
Registro de niveles, Creado
para organizar por niveles
los productos.
30-6 Impuestos por producto. Asigna un impuesto a un
producto.
AL
MA
CE
N (
PR
OD
UC
TO
S) 30-20 Productos.
Se registra la definición del
producto.
30-21 Productos por agencia.
Permite asignar un producto
a la agencia, consultar los
productos por agencia.
Transacción para el
administrador de la
aplicación.
30-22 Productos agencia.
Permite crear un producto y
consulta de sus productos en
la agencia.
Tabla 27: Transacciones de productos. Fuente: Tesista. Autor: Tesista.
3.5.2.6. Transacciones para movimientos de productos
Se crearon las transacciones para el movimiento o traslado de productos por agencia. Esto
proceso puede realizarse cuando en alguna agencia no tiene stock y otras que si poseen
hacen un traslado del producto para su comercialización. Genera un documento del
movimiento con el detalle de los productos, con el origen, destino, fechas y campos para
firmas autorizadas.
- 69 -
Módulo Transacción Nombre Descripción
AL
MA
CÉ
N (
PR
OD
UC
TO
S)
30-23 Movimiento de
productos.
Permite crear un registro de
un movimiento a realizar
con datos de la agencia
origen y destino. Permite la
anulación de movimientos y
genera un documento para
imprimir.
30-24 Recepción de productos.
Permite receptar el
movimiento de los
productos.
Tabla 28: Transacciones de movimiento de productos. Fuente: Tesista. Autor: Tesista.
3.5.2.7. Transacciones para ingresos y salidas de productos
Se crea un proceso para la entrada y salida de productos el cual actualiza el stock de
productos en cada agencia ya sea por ventas o compra de productos. Se puede consultar la
entrada y salida de productos más conocido como KARDEX.
Método de valuación de inventarios.- Existen dos sistemas de inventarios, el periódico y
el permanente. Nosotros utilizamos el sistema permanente el cual consiste en varios
métodos pero el más importante y el que utilizamos es el “Método de del promedio
ponderado16
” que consiste en determinar un promedio, sumando los valores existentes en el
inventario con los valores de las nuevas compras, para luego dividirlo entre el número de
unidades existentes en el inventario incluyendo tanto los inicialmente existentes, como los
de la nueva compra.
16
Método Promedio Ponderado, (Promedio Ponderado, 2014).
- 70 -
Módulo Transacción Nombre Descripción
AL
MA
CÉ
N (
PR
OD
UC
TO
S) 30-28 Kardex.
Permite consultar los
ingresos y salidas de los
productos.
30-29 Compras.
Permite registrar las
compras de productos a
proveedores mediante el
registro de la factura de
compra. También se puede
anular una compra.
30-33 Consulta de compras.
Permite realizar consultas de
los productos comprados a
proveedores.
Tabla 29: Transacciones de Ingresos/ Salidas de productos. Fuente: Tesista. Autor: Tesista.
3.5.2.8. Transacciones para la venta de productos
Para el proceso de ventas se crearon las transacciones para facturación, consultas, pagos y
consulta de pagos. Genera un documento para la impresión de la factura y comprobante de
pago.
Módulo Transacción Nombre Descripción
AL
MA
CÉ
N (
VE
NT
AS
)
30-27 Facturas.
Permite registrar la venta de los
productos por agencia e
imprimir la factura.
30-30 Consulta ventas.
Permite consultar las ventas
realizadas y emitir un reporte
con criterios de búsqueda.
30-31 Pagos Permite realizar pagos de
facturas
30-32 Consulta pagos Permite consultar la
información de pagos realizados
30-34 Facturas
administrador
Permite al administrador
facturar.
30-35 Pago administrador. Permite al administrador
registrar los pagos.
Tabla 30: Transacciones de ventas de productos. Fuente: Tesista. Autor: Tesista.
- 71 -
3.5.2.9. Transacción para órdenes de trabajo
Para servicio técnico se creó la transacción para el registro de órdenes de trabajo la misma
que puede realizar el seguimiento del servicio. Con el cliente se pudo analizar y validar el
proceso de servicio técnico y lo resumimos en el siguiente gráfico de procesos.
Proceso de servicio técnico
Té
cn
ico
Clie
nte
Inicio
Ingreso solicitud
servicio técnicoEvaluar solicitud
Aprobar
evaluación
Reparación
Si
FinSi
Finalizar
reparación
Requiere
repuestos
Aprobar
repuestos
Si
ANo No A
Figura 33: Modelo de procesos servicio técnico. Fuente: TECNOGALAXY CIA. LTDA.
Autor: Tesista.
En base al modelo de procesos de servicio técnico se realizó el modelo entidad relación que
se presenta a continuación.
Figura 34: Modelo E-R de servicio técnico. Fuente: Tesista. Autor: Tesista.
FKTTECORDETALMMARC
FKTALMORDENTRTGENCATA
FKTALMORDENTALMORDENTEC
FKTALMORDETALMORDEACC
FKTALMORDETALMORDEREPU
FKTALMORDENENTREGA
TALMORDENREPUESTOS
CORDEN
CCOMPANIA
CPRODUCTO
CSUCURSAL
CAGENCIA
DESCRIPCION
CANTIDAD
PRECIOVENTA
OPTLOCK
VARCHAR(20)
NUMERIC(4)
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
VARCHAR(80)
NUMERIC(15,7)
NUMERIC(15,7)
NUMERIC
<pk,fk>
<pk,fk>
<pk>
<pk>
<pk>
TALMORDENTRABAJO
CORDEN
CCOMPANIA
CPERSONA
CCATALOGOEQUIPO
CDETALLEEQUIPO
CCATALOGOINGRESO
CDETALLEINGRESO
CMARCA
CCATALOGOESTADO
CDETALLEESTADO
CCATALOGOENTREGA
CDETALLEENTREGA
CPRODUCTO
NOMBRE
SERIE
DESCRIPCION
DIAGNOSTICO
FINGRESO
FMODIFICACION
CUSUARIOING
CUSUARIOMOD
FCIERRE
FENTREGA
CTECNICO
COSTO
CSUCURSAL
CAGENCIA
OPTLOCK
VARCHAR(20)
NUMERIC(4)
NUMERIC(10)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
NUMERIC(4)
VARCHAR(6)
NUMERIC(4)
VARCHAR(6)
VARCHAR(20)
VARCHAR(250)
VARCHAR(60)
VARCHAR(250)
VARCHAR(300)
DATE
DATE
VARCHAR(20)
VARCHAR(20)
DATE
DATE
NUMERIC(10)
NUMERIC(15,7)
NUMERIC(4)
NUMERIC(4)
NUMERIC
<pk>
<pk,fk1>
<fk1>
<fk2>
<fk2>
<fk3>
<fk3>
<fk4>
<fk5>
<fk5>
<fk6>
<fk6>
TPERPERSONA
(<PhysicalDataModelF4>)
CPERSONA
CCOMPANIA
NUMERIC(10)
NUMERIC(4)
<pk>
<pk,fk>
TGENCATALOGODETALLE
(<PhysicalDataModelF4>)
CCATALOGO
CDETALLE
OPTLOCK
NOMBRE
CLEGAL
NUMERIC(4)
VARCHAR(6)
NUMERIC
VARCHAR(60)
VARCHAR(20)
<pk,fk>
<pk>
TALMMARCA
(parametros)
CMARCA
OPTLOCK
NOMBRE
NUMERIC(4)
NUMERIC
VARCHAR(60)
<pk>
TALMORDENRESPONSABLES
CORDEN
CCOMPANIA
CPERSONA
FINGRESO
ESTADO
OPTLOCK
VARCHAR(20)
NUMERIC(4)
NUMERIC(10)
DATE
VARCHAR(1)
NUMERIC
<pk,fk>
<pk,fk>
<pk>
TALMORDENACCESORIOS
CORDEN
CCOMPANIA
SECUENCIA
NOMBRE
SERIE
OPTLOCK
VARCHAR(20)
NUMERIC(4)
NUMERIC(4)
VARCHAR(150)
VARCHAR(100)
NUMERIC
<pk,fk>
<pk,fk>
<pk>
- 72 -
En base al esquema de base de datos para servicio técnico se desarrolló la siguiente
transacción para el ingreso y seguimiento de órdenes de trabajo.
Módulo Transacción Nombre Descripción A
LM
AC
ÉN
(S
ER
VIC
IO
TÉ
CN
ICO
)
30-25 Órdenes de trabajo.
Permite crear y dar
seguimiento a las órdenes de
trabajo. También permite
registrar los accesorios y
repuestos que pueda tener el
equipo o servicio. Se puede
asignar el trabajo uno o un
conjunto de responsables
que son empleado de
TECNOGALAXY.
Tabla 31: Transacción de órdenes de trabajo. Fuente: Tesista. Autor: Tesista.
3.5.2.10. Transacción para consulta de órdenes de trabajo
Se creó una transacción para la consulta de órdenes de trabajo el cual presenta el estado de
la orden y su responsable.
Módulo Transacción Nombre Descripción
AL
MA
CÉ
N (
SE
RV
ICIO
TÉ
CN
ICO
)
30-26 Consulta de órdenes.
Permite consultar las
órdenes de trabajo bajo
ciertos criterios de
búsqueda. En la consulta se
puede visualizar los datos
generales de la orden como
fecha de creación y entrega,
estado en el que se
encuentra, el técnico
responsable y el cliente
dueño del producto o
servicio.
Tabla 32: Transacción de consulta de órdenes. Fuente: Tesista. Autor: Tesista.
3.5.3. Evaluación
Como retrospectiva del trabajo realizado en el Sprint 3 concluimos que se subestimaron
tareas que implicaban un complejo desarrollo por ejemplo se tuvo que modificar el modelo
de agencias para asignar una agencia principal a cual agregar los productos que ingresan al
almacén por compras a proveedores. Además se implementó un mecanismo automatizado
para sumar y disminuir el stock en cada agencia por concepto de venas y compras de
- 73 -
productos. Adicionalmente para el reporte de ingresos y salidas se validó y controló el
proceso del promedio ponderado para el ingreso y salida de productos. Se modificaron
algunos procesos en los comandos de mantenimiento ya que las pantallas no fueron muy
genéricas y fueron diseñadas de acuerdo al requerimiento.
Se realizó una prueba de calidad interno con el cliente. Las pruebas consistieron en seguir
según el modelo de procesos analizado y desarrollado con el cliente, hubo que modificar
algunos desarrollos de las transacciones involucradas pero se solventó y se pudo completar
el proceso con la satisfacción del cliente.
3.5.4. Análisis del trabajo realizado
Realizando un análisis del avance del proyecto según la planificación pudimos encontrarnos
con tareas que no estuvieron planificadas y poder implementar dichas tareas nos tomó más
tiempo en el desarrollo esto suele suceder cuando los procesos a implementar no estuvieron
bien definidos y entendidos por parte del equipo de desarrollo.
Lo que se hizo fue realizar reuniones con el cliente para aclarar ciertos puntos con respecto
a los procesos de facturación, ingresos, salidas de productos y reorganizar cada tarea y
asumir los tiempos de los desarrollos. Hubo retrasos en lo planificado y se plasma en el
siguiente gráfico del seguimiento del avance del proyecto.
Figura 35: Gráfico Burn-Down Sprint 3. Fuente: Tesista. Autor: Tesista.
Analizando el gráfico podemos observar que efectivamente tuvimos retrasos a partir de la
segunda semana de trabajo debido a tareas no planificadas y que fueron necesarias de
implementarlas para cumplir con los requisitos del cliente. Este retraso se propagó debido a
que iban apareciendo más tareas sin planificar. Hubo un retraso total de 6 días laborables.
0
50
100
150
200
250
300
0 10 20 30 40
Ho
ras
rest
ante
s d
e t
rab
ajo
Fecha o días de planificación
Avance Sprint 3
Estimado
Real
- 74 -
CAPÍTULO 4
4. PRUEBAS DEL SISTEMA
En el desarrollo de sistemas se suelen realizar pruebas de las aplicaciones y en nuestro caso
no es la excepción. Se trata de realizar un sin número de pruebas para determinar que un
sistema tiene la capacidad de procesar las peticiones del usuario en forma oportuna y de
estabilidad del sistema en cuanto a la carga de trabajo, con esto podemos tener indicadores
a cerca de los atributos del sistema en cuanto a su calidad en temas de escalabilidad,
fiabilidad y consumo de recursos.
4.1. Características del sistema
Vamos a detallar las características de la plataforma en la cual se encuentra instalada la
aplicación objeto de nuestras pruebas.
El sistema operativo en el cual está corriendo nuestra aplicación es un Linux Centos 7 con
procesador INTEL i5 de 2.4 GHz, con memoria de 8Gb y un disco duro de 1Tb. La pruebas
de la aplicación se realizaron desde una maquina Windows 7 con procesador AMD Dual
Core de 2.1 GHz., con memoria RAM de 4 Gb. Y disco duro de 500 Gb. La herramienta
utilizada para las pruebas es el “Webserver Stress Tool 817
”, es un aplicativo de libre
descarga que nos ayudó a simular diferentes escenarios para realizar las pruebas de nuestro
sistema.
4.2. Escenarios
Los escenarios utilizados para nuestras pruebas los definimos en la siguiente tabla, en la
cual seleccionamos tres grupos de usuarios que realizan peticiones a la aplicación
concurrentemente bajo un determinado período de tiempo y con ayuda del simulador
ejecutamos dichas pruebas y obtenemos datos los cuales se presentan en gráficos y son
analizados. Los usuarios analizados que accederán a la aplicación de forma continua son
alrededor de 10 en TECNOGALAXY CIA. LTDA.
Escenario Usuarios Peticiones Retraso URL
1 20 10 por
usuario
3 Segundos
entre petición
http://192.168.0.104:8081/flipper
2 50 10 por
usuario
3 Segundos
entre petición
http://192.168.0.104:8081/flipper
3 100 10 por
usuario
3 Segundos
entre petición
http://192.168.0.104:8081/flipper
Tabla 33: Tabla de escenarios para las pruebas de la aplicación. Fuente: Tesisa. Autor: Tesista.
17
Aplicativo para pruebas de sistemas web, (Webserver, 2015).
- 75 -
La herramienta nos ayuda a simular un gran número de usuarios que acceden a un sitio web
a través de HTTP/HTTPS18
. Simula varios usuarios independientes realizando peticiones
mediante una dirección web. Presentamos los datos a ser simulados, el dato que varía es el
número de usuarios que para nuestra prueba fueron de 20, 50 y 100 usuarios concurrentes.
Se eligió tal número de usuarios de acuerdo a las especificaciones del servidor y del número
de personas que pueden utilizar el sistema.
Figura 36: Ingreso de datos a ser simulados para pruebas de la aplicación. Fuente: Tesista. Autor: Tesista.
Se simularon 20, 50 y 100 usuarios concurrentes realizando 10 peticiones cada 3 segundos.
Agregamos la dirección web de acceso a la aplicación como se muestra en la siguiente
figura.
18
HTTP/HTTPS, (Http y Https, 2015).
- 76 -
Figura 37: Ingreso de la dirección web de la aplicación a ser simulada. Fuente: Tesista. Autor: Tesista.
4.3. Pruebas de rendimiento
Esta prueba consiste en determinar el comportamiento de la aplicación en cuanto a la
velocidad de respuesta en base a las características del servidor y que permita descubrir los
elementos responsables a su respuesta. Una vez ejecutadas las pruebas con los tres
escenarios se obtuvieron los siguientes datos.
- 77 -
Figura 38: Análisis de rendimiento para 20 usuarios. Fuente: Tesista. Autor: Tesista.
La Figura 38 presenta información en cuanto a la simulación con 20 usuarios concurrentes.
Se procesaron las peticiones, el tiempo utilizado en la simulación fue de alrededor de 31
segundos y con una carga al procesador constante, un consumo de memoria normal.
Figura 39: Análisis de rendimiento para 50 usuarios. Fuente: Tesista. Autor: Tesista.
- 78 -
La Figura 39 presenta información en cuanto a la simulación con 50 usuarios concurrentes.
Se procesaron las peticiones, el tiempo utilizado en la simulación fue de alrededor de 31
segundos y con una carga al procesador constante, un consumo de memoria normal.
Figura 40: Análisis de rendimiento para 100 usuarios. Fuente: Tesista. Autor: Tesista.
La Figura 40 presenta información en cuanto a la simulación con 100 usuarios concurrentes.
Se procesaron las peticiones, un tiempo utilizado en la simulación fue de alrededor de 110
segundos tres veces más que el utilizado para las simulaciones anteriores y con una carga al
procesador normal y constante, un consumo de memoria normal.
Los datos de esta prueba nos permiten conocer datos acerca de la respuesta obtenida por el
servidor de aplicaciones y nos da la oportunidad de optimizar la configuración del mismo.
4.4. Pruebas de carga
Esta es una prueba acerca de la carga normal esperada en el sitio web. Simplemente harems
uso de los datos introducidos inicialmente para las pruebas de rendimiento y el simulador
nos proporcionó los siguientes datos para 20, 50 y 100 usuarios concurrentes.
Figura 41: Resultado del análisis de carga para 20 usuarios. Fuente: Tesista. Autor: Tesista.
- 79 -
En la Figura 41 se ilustra los datos de la simulación de carga para 20 usuarios concurrentes
donde se procesaron exitosamente 191 peticiones, el tiempo utilizado para completar la
simulación fue de 31.730 milisegundos, con un tiempo de respuesta entre cada petición de
166 milisegundos, lo cual son datos exitosos en la prueba.
Figura 42: Resultado del análisis de carga para 50 usuarios. Fuente: Tesista. Autor: Tesista.
En la Figura 42 se ilustra los datos de la simulación de carga para 50 usuarios concurrentes
donde se procesaron exitosamente 468 peticiones, el tiempo utilizado para completar la
simulación fue de 70.376 milisegundos, con un tiempo de respuesta entre cada petición de
150 milisegundos, lo cual son datos exitosos en la prueba.
Figura 43: Resultado del análisis de carga para 100 usuarios. Fuente: Tesista. Autor: Tesista.
En la Figura 43 se ilustra los datos de la simulación de carga para 100 usuarios concurrentes
donde se procesaron exitosamente 854 peticiones, el tiempo utilizado para completar la
simulación fue de 1362693 milisegundos, con un tiempo de respuesta entre cada petición de
1596 milisegundos, lo cual son datos exitosos en la prueba.
La prueba se realizó con el número estimado de usuarios en condiciones normales y dado
que la empresa crezca considerablemente en el personal que use el sistema.
4.5. Prueba de rampa
Consiste en utilizar un número creciente de usuarios durante un período de tiempo corto y
medir el porcentaje de usuarios atendidos en cada petición realizada al sistema y obtenemos
el promedio en tiempo de respuesta del aplicativo.
- 80 -
Figura 44: Resultado del análisis de la prueba de rampa. Fuente: Tesista. Autor: Tesista.
Analizando la Figura 44 de la simulación de la prueba de rampa podemos concluir que en
un tiempo de 2 minutos ya que el acceso de usuarios a la aplicación fue creciente se
pudieron atender alrededor del cien por ciento de las peticiones realizadas por los usuarios
con un tiempo promedio de respuesta de entre los 500 milisegundos entre cada petición.
Concluimos que la aplicación es estable y según las especificaciones del servidor son los
adecuados para su correcto funcionamiento.
- 81 -
4.6. Conclusiones y recomendaciones
Una vez finalizado el desarrollo del proyecto y de haber hecho las pruebas correspondientes
de funcionalidad con el cliente se tiene las siguientes conclusiones y recomendaciones.
4.6.1. Conclusiones
Podemos concluir que se han cumplido los objetivos planteados al inicio del desarrollo del
presente proyecto que consistían en implementar una aplicación web intuitiva que permita
administrar los procesos de clientes, productos, ventas y servicio técnico de
TECNOGALAXY CIA. LTDA., Se presentó una demora en la desarrollo de la aplicación,
específicamente en el módulo de ingresos y salidas de productos dado que no se tenía un
conocimiento acerca del método de valuación de inventarios pero se pudo solventar este
inconveniente con investigación y se logró el objetivo planteado.
En el desarrollo del trabajo se pudo entender que no podemos cerrarnos a la utilización de
una única metodología como marco de trabajo, sino que podemos extraer las mejores
prácticas de cada metodología y que se puedan acoplar para llegar a nuestros objetivos
cumpliendo adecuadamente los roles y responsabilidades en un equipo de trabajo. En
nuestro caso rescatamos lo mejor de la Metodología SCRUM y XP para organizar y
desarrollar el trabajo.
Podemos concluir que en la estimación de los tiempos de desarrollo del sistema para cada
iteración y siguiendo las mejores prácticas hubo un desfase de una y dos semanas con lo
estimado inicialmente en cada planificación, con lo que podemos decir que para cada
actividad a desarrollar se tiene que desglosar en la unidad más mínima para tener una
estimación más exacta en el tiempo de planificación de un proyecto.
4.6.2. Recomendaciones
El sistema se ha implementado según la viabilidad y requerimientos de la empresa
TECNOGALAXY CIA. LTDA., por lo que se recomienda que es necesario realizar un
mantenimiento del sistema en cuanto a los servidores de aplicaciones, de bases de datos, y
de reportes. Realizar la investigación acerca de la gestión de la base de datos con
PostgreSQL 9.3 ya que si a futuro necesitan cambiar de servidos o respaldar información de
la base de datos se necesitan conocimientos de configuraciones y administración de bases de
datos. También puede necesitar contratar a un ingeniero con conocimientos en bases de
datos PostgreSql para realizar las actividades de mantenimiento.
En la implementación del sistema se creó la transacción “Secuencias” que permite agregar
códigos secuenciales a registros esto para futuras implementaciones puede ser usado para la
impresión de facturas, documentos y otros reportes que necesiten ser impresos según un
número de secuencia desde la aplicación.
El sistema fue desarrollado de tal manera que se puedan implementar otros módulos en el
futuro, es escalable, flexible y multiempresa con un lenguaje de programación de gran
- 82 -
conocimiento por el entorno de desarrolladores de sistemas. El sistema está abierto para
futuras implementaciones o mejoras.
- 83 -
BIBLIOGRAFÍA
1. Framework. (2006). Recuperado el 03 de 10 de 2014, de http://jordisan.net/blog/2006/que-es-
un-framework/
2. Apache Wicket. (12 de 11 de 2013). Recuperado el 13 de 01 de 2015, de
https://wicket.apache.org/
3. Oracle Jee. (01 de 2013). Recuperado el 10 de 11 de 2014, de
http://docs.oracle.com/javaee/6/tutorial/doc/
4. Wikipedia AVALON. (26 de 06 de 2013). Recuperado el 13 de 12 de 2014, de
http://es.wikipedia.org/wiki/Apache_Avalon
5. XP. (08 de 10 de 2013). Recuperado el 20 de 12 de 2014, de
http://www.extremeprogramming.org/
6. Apache Struts. (08 de 12 de 2014). Recuperado el 13 de 01 de 2015, de
https://struts.apache.org/index.html
7. Comparativa Bases de Datos. (11 de 06 de 2014). Recuperado el 15 de 12 de 2014, de
http://es.slideshare.net/jazpekcobain/cuadro-comparativ-35729496
8. Instalación JDK. (2014). Recuperado el 10 de 01 de 2015, de
https://josemmsimo.wordpress.com/2014/01/14/como-instalar-java-jdk-y-jre-en-linux-
y-windows-con-detalles/
9. Instalar MAVEN. (2014). Recuperado el 10 de 01 de 2015, de
http://howtodoinjava.com/2013/01/02/how-to-install-maven-on-windows-7/
10. Instalar PotgreSql. (2014). Recuperado el 10 de 01 de 2015, de
http://www.tuinformaticafacil.com/postgresql/como-instalar-postgresql-para-windows
11. JPA. (09 de 05 de 2014). Recuperado el 13 de 12 de 2014, de
http://docs.oracle.com/javaee/5/tutorial/doc/bnbpz.html
12. Metodología RUP. (04 de 03 de 2014). Recuperado el 22 de 12 de 2014, de
http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
13. Oracle Java. (11 de 10 de 2014). Recuperado el 13 de 12 de 2014, de
https://www.java.com/es/download/whatis_java.jsp
14. Pentaho. (06 de 12 de 2014). Recuperado el 05 de 01 de 2015, de http://www.pentaho.com/
15. Promedio Ponderado. (14 de 07 de 2014). Obtenido de http://www.gerencie.com/metodo-
del-promedio-ponderado.html
- 84 -
16. SCRUM. (26 de 05 de 2014). Recuperado el 18 de 12 de 2014, de
http://www.proyectosagiles.org/
17. Spring-Framework. (01 de 05 de 2014). Recuperado el 13 de 12 de 2014, de
http://projects.spring.io/spring-framework/
18. Http y Https. (2015). Recuperado el 10 de 01 de 2015, de http://www.informatica-
hoy.com.ar/aprender-informatica/Diferencias-HTTP-HTTPS.php
19. Pruebas de rendimiento. (2015). Recuperado el 02 de 03 de 2015, de
http://www.globetesting.com/pruebas-de-rendimiento/
20. Pruebas de software. (2015). Recuperado el 02 de 03 de 2015, de
http://docsetools.com/articulos-educativos/article_11479.html
21. Webserver. (2015). Recuperado el 05 de 02 de 2015, de
http://www.paessler.com/tools/webstress
22. ALAIMO, M. (2013). Proyectos ágiles con Scrum. Buenos Aires: KLEER.
23. ÁLVAREZ, C. (03 de 12 de 2013). EJB. Recuperado el 13 de 12 de 2014, de
http://www.arquitecturajava.com/introduccion-a-ejb-3-1-i/
24. Implementaciones JSF. (s.f.). Recuperado el 15 de 12 de 2014, de
http://www.mastertheboss.com/jboss-web/richfaces/primefaces-vs-richfaces-vs-icefaces
25. KNIBERG, H. (2007). SRUM Y XP DESDE LAS TRINCHERAS. Obtenido de
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-
trincheras.pdf
26. MANOSALVAS, S. (24 de 03 de 2014). Lenguajes de Programación. Recuperado el 12 de
10 de 2014, de http://blog.buhoos.com/lenguajes-de-programacion-cuadro-comparativo/
27. Oracle JSF. (s.f.). Recuperado el 13 de 01 de 2015, de
http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html.
- 85 -
ANEXO 1
5. MANUAL DE USUARIO
5.1. Introducción
El presente manual permitirá al usuario manipular el sistema de administración de procesos
de TECNOGALAXY CIA. LTDA., de manera más eficiente, proporcionando una guía, una
descripción de las transacciones disponibles y de la navegación entre ellas. Cuenta con una
interfaz amigable e intuitiva que facilitara la utilización del sistema, la conexión al sistema
se lo puede realizar siempre y cuando haya disponible acceso al internet.
5.2. Objetivo del manual de usuario
El objetivo del presente manual es proporcionar una guía a los usuarios del sistema de
administración de procesos de TECNOGALAXY CIA. LTDA., con la cual facilite acceder
a las transacciones y operaciones correspondientes de una manera más sencilla y entendible.
5.3. Ingreso al sistema
Para el ingreso al sistema debemos colocar la siguiente URL en la barra de direcciones del
navegador y cargar la página “http://nombreHost:8081/flipper”.
Donde el “nombreHost” es la IP pública donde podemos acceder a la aplicación. En nuestro
caso por encontrarnos en la red local accedemos mediante la dirección
“http://192.168.0.109:8081/flipper”.
Figura 45: Pantalla de ingreso al sistema. Fuente: Tesista. Autor: Tesista.
- 86 -
El ingreso de usuario se lo realiza mediante el número de cedula de la persona registrada en
el sistema y la contraseña. En el caso de que no recuerde su contraseña de acceso existe la
opción de restaurarla mediante el enlace “Olvidó su contraseña?”, el cual genera una
contraseña temporal y la envía por correo electrónico a su cuenta registrada. Si su usuario
no se encuentra registrado emitirá un mensaje que dicho usuario no está registrado.
Figura 46: Pantalla para restaurar la contraseña. Fuente: Tesista. Autor: Tesista.
5.4. Pantalla general del sistema
En la Figura 47, se presenta la pantalla general una vez que hemos ingresado al sistema. A
continuación describimos cada una de las secciones presentes en la pantalla.
Menú de transacciones.- Despliega las transacciones asociadas a cada módulo, el
administrador general tiene acceso a todos los módulos del sistema como podemos
observar (Técnicos, Parámetros, Seguridad, Personas y Almacén).
Área de trabajo.- Consiste en el espacio donde se cargan las transacciones.
Perfil de usuario.- Aquí se muestran los perfiles asociados a cada usuario. Puede
tener más de un perfil y al seleccionarlo se carga el menú asociado a dicho perfil.
Información del usuario.- Presenta los datos de usuario que ha iniciado sesión.
Controles de las transacciones.- Aquí tenemos las acciones que se pueden ejecutar
en cada transacción. De izquierda a derecha tenemos, el botón de consulta , aquí
podemos realizar la consulta de los datos de una determinada transacción. Los
siguientes dos botones corresponden a la paginación de las tablas, permite
navegar entre grupos de datos obtenidos directamente de la base de datos como
consulta de ellos. El siguiente botón permite enviar a guardar información de
una determinada transacción. El siguiente botón permite actualizar o encerar la
- 87 -
transacción. El botón nos ayuda a cerrar la sesión del usuario y salir de la
aplicación
Figura 47: Pantalla general de la aplicación. Fuente: Tesista. Autor: Tesista.
Al desplegar el menú podemos acceder a las transacciones. Cada transacción está
identificada por el módulo al que pertenece y el número de página, por ejemplo, para
acceder a la página de definición de módulos, ésta se encuentra en el módulo de
configuraciones técnicas (0) y el número de página (1), así sabemos que la transacción es
“MÓDULOS (0-1)”.
Figura 48: Acceso a transacciones. Fuente: Tesista.
- 88 -
Autor: Tesista.
El menú está organizado por “Módulos”, “Menú de transacciones” y “Transacciones”. Para
acceder a una página o transacción basta con dar un click sobre la transacción y se carga en
el área de trabajo. Se carga la transacción y tenemos la tabla de datos o el formulario
asociado a ésta.
Sobre la tabla de registro tenemos un conjunto de controles que nos
ayudan a la administración de los registros. Estos controles de izquierda a derecha son
“Crear registro”, “Modificar registro seleccionado”, “Ver registro seleccionado” y
“Eliminar registro seleccionado”.
Figura 49: Creación de registros. Fuente: Tesista. Autor: Tesista.
Al dar click en el icono de crear registro nos aparece una pantalla en la que podemos
ingresar los datos para ese registro y dando click en “Confirmar” cargamos los datos a la
tabla y en “Cancelar” no se aplican los cambios realizados como se ilustra en le Figura 49.
Esta pantalla es común para al seleccionar los controles de “Modificar registro
seleccionado” y “Ver registro seleccionado” con la particularidad que se
bloquearán algunos campos de ingreso al presionar ver registros, es más usado para la
consulta de datos.
Adicional tenemos “TAB de transacciones” que nos permiten abrir dos páginas
simultáneamente e independientes. Podemos abrir una transacción en cada TAB y gestionar
la información sin que haya interrupción de datos.
- 89 -
5.5. Controles de transacciones
La pantalla general de transacciones tiene controles en base a las teclas de función, que nos
permiten realizar consultas, paginar los datos de una tabla, recargar la página y función de
acceso rápido a las transacciones.
Figura 50: Controles de transacciones. Fuente: Tesista. Autor: Tesista.
En las transacciones definimos los filtros de consulta en la parte superior de las tablas de
datos o de formularios, adicional tenemos funciones para el control de acciones en cada
transacción, esto es común para todas las pantallas y los definimos a continuación.
F3.- Acceso rápido a transacciones y aparece en la parte inferior derecha de la
aplicación y permite el ingreso del Módulo y Página para el acceso a la transacción.
F4.- Recarga la transacción y encera los datos.
F7.- Realiza la consulta de datos en la transacción en base a los filtros ingresados.
F8.- Realiza una consulta y regresa una página anterior en la tabla de datos.
F9.- Realiza una consulta u avanza un página en los datos.
F10.- Graba la información presente en la transacción.
5.6. Transacciones de configuraciones técnicas
En “Configuraciones técnicas” tenemos un conjunto de transacciones que son parte
fundamental de la operación de la aplicación y se debe tener un conocimiento técnico de
como emplearlas para el correcto funcionamiento del sistema. La descripción de las
transacciones se encuentra en el “Capítulo 1” sección “Alcance”. Consta de dos grupos de
configuraciones, “Generales” y “Comandos”.
- 90 -
Figura 51: Transacciones de configuraciones técnicas. Fuente: Tesista. Autor: Tesista.
5.7. Transacciones de parámetros del sistema
En “Parámetros” tenemos las transacciones que forman parte de la parametrización general
del sistema y son gestionadas por el administrador general. Consta de dos secciones,
“Generales” tenemos las transacciones de catálogos y de distribución geográfica y
“Compañía” donde están las transacciones de Sucursales, Agencias, Áreas y Compañias.
Figura 52: Transacciones de parámetros del sistema. Fuente: Tesista. Autor: Tesista.
- 91 -
5.8. Transacciones de seguridades
En “Seguridades” se encuentran las transacciones para dar permisos a los usuarios para el
ingreso al sistema así como la definición de menús según el perfil seleccionado. La
descripción de las transacciones se encuentra en el “Capítulo 1” sección “Alcance”. En la
Figura 53, tenemos la transacción para la definición de perfiles de usuario.
Figura 53: Transacciones de seguridades. Fuente: Tesista. Autor: Tesista.
5.8.1. Creación de usuarios
En la transacción 2-7 podemos ingresar un usuario previamente registrada la información en
la transacción de personas (3-1). Accedemos a la transacción y la aplicación tiene un
concepto para recuperar datos de otras transacciones mediante el uso de LOV’s (Listas de
Valores de registros) que nos ayuda a obtener datos de tablas que tienen a crecer, asi
podemos acceder mediante filtros de búsqueda ala información y recuperarla.
- 92 -
Figura 54: Lista de valores de personas (LOV). Fuente: Tesista. Autor: Tesista.
Obtenemos los datos de la persona que vamos a registrar como usuario del sistema desde la
lista de valores (LOV) de personas y que tiene filtros de consulta, así podemos acceder a la
información sin perder el rendimiento de la aplicación. Elegimos la información de la
persona y cargamos la información correspondiente al usuario que se encuentra como
campos requeridos (*) y grabamos presionando la tecla de función F10 y en el icono de los
controles de la transacción y nos da un mensaje de confirmación que la transacción a
finalizado con éxito.
- 93 -
Figura 55: Transacción de ingreso de usuario. Fuente: Tesista. Autor: Tesista.
Una vez creado al usuario debemos activarlo. Ingresamos a la transacción “Activación (2-
9)” recuperamos al usuario mediante el LOV de personas y damos F10, seguido nos da un
mensaje de que el usuario está activo.
Figura 56: Transacción de activación de usuarios creados. Fuente: Tesista. Autor: Tesista.
De ésta manera ya podemos ingresar a la aplicación con el usuario creado y la contraseña
por defecto es el número de identificación la misma que será pedida que la cambien.
- 94 -
5.8.2. Administración de usuarios
Para la administración de los usuarios tenemos la transacción “Mantenimiento de usuarios
(2-8)” y “Cambio de contraseña (2-10)”. De igual maneta accedemos a la información del
usuario mediante el LOV de personas, mientras que para el cambio de contraseña la
información de usuario viene precargada.
Figura 57: Transacción para la administración de usuarios. Fuente: Tesista. Autor: Tesista.
Figura 58: Transacción para el cambio de contraseña del usuario. Fuente: Tesista. Autor: Tesista.
- 95 -
5.9. Transacción de personas
En el Módulo de “Personas” tenemos las transacciones para el ingreso de la información de
los clientes, empleados y proveedores. En el módulo de personas consta de “”Generales”
donde están los parámetros de personas y en “Mantenimiento” tenemos las transacciones de
ingreso de información de personas naturales y jurídicas.
Para recuperar los datos de una persona ya ingresada accedemos desde el “LOV de
personas”, caso contrario simplemente ingresamos la información en los campos requeridos
y presionamos F10 o damos click en el botón grabar y la información se registrará en la
base de datos.
Figura 59: Transacción de ingreso de personas naturales. Fuente: Tesista. Autor: Tesista.
- 96 -
Figura 60: Transacción de ingreso de personas jurídicas. Fuente: Tesista. Autor: Tesista.
5.10. Transacciones de almacén
En el módulo “Almacén” tenemos las transacciones para la operación propia de la empresa.
Y vamos a describir cómo funcionan las transacciones más importantes del presente
módulo. Tenemos una sección de “Generales” que corresponden a los parámetros utilizados
en el módulo de almacén.
Figura 61: Transacciones del módulo almacén. Fuente: Tesista. Autor: Tesista.
- 97 -
5.10.1. Productos
En la sección de “Productos” tenemos la transacción “Productos (30-20)” aquí podemos
ingresar la definición propia de un producto. El producto se crea en la agencia principal.
Figura 62: Transacción de creación de productos. Fuente: Tesista. Autor: Tesista.
Al agregar un nuevo producto tenemos la siguiente pantalla para el ingreso de su definición.
Figura 63: Ingreso de datos para el nuevo producto. Fuente: Tesista. Autor: Tesista.
- 98 -
5.10.2. Productos por agencia
En esta transacción podemos consultar los productos que tenemos en cada agencia en base a
criterios de consulta como se muestra en la siguiente ilustración.
Figura 64: Transacción de productos por agencia. Fuente: Tesista. Autor: Tesista.
La impresión del reporte de productos nos presenta por secciones, cada sección es la
agencia y su detalle son los productos que le corresponden. Los formatos en los que se
puede descargar la información son en PDF y en EXCEL.
Figura 65: Reporte de productos por agencia. Fuente: Tesista. Autor: Tesista.
- 99 -
5.10.3. Movimiento de productos
Esta transacción “Movimiento productos (30-23)” nos permite realizar transferencias de
productos entre agencias ya sea por falta de stock o por ventas de productos. Podemos
recuperar una transferencia realizada mediante el “LOV de productos” y realizar las
acciones de “Transferir”, “Anular” e “Imprimir documento de la transferencia”.
Figura 66: Transacción de movimiento de productos. Fuente: Tesista. Autor: Tesista.
5.10.4. Recepción de productos
En la transacción “Recepción de productos (30-24)” podemos aceptar las transferencias de
productos que han llegado a nuestra agencia más no las de otras. Podemos “Aceptar”,
“Modificar”, “Anular” y “Reimprimir” la transferencia.
- 100 -
Figura 67: Transacción de recepción de productos. Fuente: Tesista. Autor: Tesista.
Podemos imprimir el documento de la transferencia y nos presenta como en la siguiente
ilustración.
Figura 68: Documento de transferencia de productos. Fuente: Tesista. Autor: Tesista.
- 101 -
5.10.5. Ingresos y salidas de productos (Kardex)
La transacción “Kardex (30-28)” nos permite consultar los datos de los productos en cuanto
a salidas e ingresos en nuestro almacén. Permite la descarga de la consulta en formato PDF.
Figura 69: Transacción de ingresos y salidas de productos. Fuente: Tesista. Autor: Tesista.
5.10.6. Compras de productos
En la transacción “Compras (30-29)” permite registrar las compras de productos a
proveedores, Permite “Anular” facturas de compra ya sea por devoluciones o desperfectos.
- 102 -
Figura 70: Transacción de compras de productos a proveedores. Fuente: Tesista. Autor: Tesista.
5.10.7. Ventas
En la transacción “Facturas (30-27)” podemos registrar las ventas de los productos, las
ventas las puede realizar de los productos que existen en dicha agencia más no de otra.
Figura 71: Transacción de ventas de productos. Fuente: Tesista. Autor: Tesista.
- 103 -
5.10.8. Servicio técnico
En servicio técnico tenemos la transacción de “Órdenes de trabajo (30-25)” que nos permite
registrar un servicio en cuanto a reparación de productos o algún servicio de instalación en
particular. Podemos recuperar información de una orden de trabajo ingresada, anulada o que
se encuentre dentro del flujo. Presenta varios estados en los cuales el cliente puede dar
seguimiento a su servicio.
Figura 72: Transacción de registro de órdenes de trabajo. Fuente: Tesista. Autor: Tesista.
- 104 -
ANEXO 2
6. MANUAL TÉCNICO
6.1. Introducción
El presente manual técnico brindará ayuda para la configuración e instalación de las
herramientas de desarrollo de la aplicación y con las cuales facilitará el entendimiento de
cómo fue estructurado el proyecto para una futura implementación o mejora del mismo.
6.2. Objetivo del manual técnico
El objetivo del presente documento es de guiar adecuadamente en la instalación del as
herramientas de desarrollo y de brindar unos lineamientos en cuanto al desarrollo realizado
y de cómo podemos agregar funcionalidad para unas futuras mejoras o implementaciones.
6.3. Instalación del servidores
Para la instalación los servidores se requieren que el JDK 1.719
, MAVEN 3.0.420
y
PostgreSql 9.321
estén instalados en ambiente de desarrollo. La instalación lo realizaremos
en un entorno Windows 7 y los servidores que se instalarán son los siguientes:
Servidor de aplicaciones “jboss-as-7.2.0”.
Servidor de reportes “Pentaho biserver-ce-4.5.0”.
6.3.1. Restaura base de datos de la aplicación
Una vez instalado el PostgreSql 9.3 en la maquina Windows abrimos el aplicativo pgAdmin
para la administración de nuestra base de datos y según los datos proporcionados en la
instalación nos conectamos como usuario “postgres” y con la contraseña correspondiente.
Al conectarnos y desplegar las bases de datos realizamos los siguientes pasos:
Creamos la base de datos “tecnogalaxy” o de su preferencia como propietario
asignamos a “postgres” y tablespace “pg_default”.
Creamos los roles “core” y “jbpm” con las contraseñas “core01” y “jbpm01”
respectivamente.
19
Instalar JDK, (Instalación JDK, 2014).
20 Instalar MAVEN, (Instalar MAVEN, 2014).
21 Instalar PostgreSql, (Instalar PotgreSql, 2014).
- 105 -
Figura 73: Creación de la base de datos en postgres. Fuente: Tesista. Autor: Tesista.
En la base de datos creada damos click derecho y nos dirigimos a “Restaurar/Restore” y
seleccionamos el archivo de backup de la base de datos que se encuentra en los archivos de
instalación y luego “Restaurar/Restore” nos indicará que el proceso ha sido exitoso con
ello tenemos el repositorio de datos de la aplicación.
Figura 74: Restaurar el respaldo de la base de datos. Fuente: Tesista. Autor: Tesista.
- 106 -
6.3.2. Instalación del servidor de aplicaciones
Descomprimir en cualquier ubicación el servidor de aplicación “jboss-as-7.2.0.rar” que se
encuentra en las herramientas de instalación y nos dirigimos a cambiar la configuración del
DATASOURCE para que apunte a nuestra base de datos local. Accedemos la a ubicación
“PATH_HOME\jboss-as-7.2.0\standalone\configuration\” y buscamos el archivo
“standalone.xml” y cambiamos la configuración.
Figura 75: Configuración para la conexión a la base de datos. Fuente: Tesista. Autor: Tesista.
Ahora cambiamos la configuración para el puerto y para aceptar conexiones remostas. En el
mismo archivo “standalone.xml” buscamos la sección que se muestra en la Figura 76 y
cambiamos la configuración.
- 107 -
Figura 76: Configuración de puerto y para conexiones remotas. Fuente: Tesista. Autor: Tesista.
Con esto tenemos configurado nuestro servidor de aplicaciones.
6.3.3. Instalación servidor de reportes
Descomprimir en cualquier ubicación el servidor de reportes “biserver-ce-4.5.0.rar” que se
encuentra en las herramientas de instalación y nos dirigimos a cambiar la configuración
para la publicación de reportes. Accedemos la a ubicación “PATH_HOME\biserver-
ce\pentaho-solutions\system\” y buscamos el archivo “publisher_config.xml” y
cambiamos la contraseña de publicación de reportes.
Figura 77: Configuración para la publicación de reportes. Fuente: Tesista. Autor: Tesista.
- 108 -
Ahora agregamos el conector para la conexión a la base de datos PostgreSql, copiamos el
archivo “postgresql-9.3-1100.jdbc4.jar” que se encuentra en la carpeta de herramientas de
instalación y lo pegamos en la siguiente ubicación “PATH_HOME\biserver-
ce\tomcat\lib\”. Para cargar los archivos de reportes creamos un directorio “TECNO” en la
ubicación “PATH_HOME\biserver-ce\pentaho-solutions\” copiamos todos los reportes,
archivos de secuencia de acción (xaction) y pegamos en la carpeta “TECNO”.
6.3.4. Instalación del diseñador de reportes
Descomprimir en cualquier ubicación el diseñador de reportes “prd-ce-3.9.0.rar” que se
encuentra en las herramientas. Accedemos la a ubicación “PATH_HOME\report-
designer\lib\jdbc\” y pegamos el archivo “postgresql-9.3-1100.jdbc4.jar” que se
encuentra en las herramientas de instalación. Con esto ya podemos crear, editar reportes y
subirlos al servidor de reportes.
6.4. Configuración del servidor de aplicaciones al IDE de desarrollo
Iniciamos Eclipse Kepler, recomendamos instalar el Jboss-Tools para Kepler y el Maven
para Eclipse. Como paso inicial vamos a configurar el servidor de aplicaciones.
Figura 78: Servidor de aplicaciones en el entorno de desarrollo. Fuente: Tesista. Autor: Tesista.
Para instalar un servidor damos click derecho en el entorno “Servers” y seleccionamos
“New Server” y seleccionamos el tipo de servidor a instalar le damos en “Next”.
- 109 -
Figura 79: Selección del servidor de aplicaciones. Fuente: Tesista. Autor: Tesista.
Ahora apuntamos al servidor que desempaquetamos dirigiéndonos a la ubicación en la que
se encuentra.
Figura 80: Configuración del nuevo servidor con su maquina virtual. Fuente: Tesista. Autor: Tesista.
- 110 -
Configuramos para que acepte conexiones remotas y le damos en “Finish” y con esto
hemos finalizamos la instalación del servidor de aplicaciones.
Figura 81: Configuración de conexiones remotas desde el IDE. Fuente: Tesista. Autor: Tesista.
6.5. Importar proyectos MAVEN al entorno de desarrollo
Ahora vamos a importar los proyectos de la aplicación hacia nuestro IDE de desarrollo
Eclipse para lo cual nos dirigimos a “New/Import” y seleccionamos el tipo de proyecto
MAVEN como se muestra en la Figura 82.
- 111 -
Figura 82: Selección del tipo de proyecto a importar. Fuente: Tesista. Autor: Tesista.
No dirigimos a la ubicación donde se encuentran nuestro código fuente
“PATH_HOME\sources\web-jsf\” y elegimos el proyecto web le damos “Ok” y “Finish”
y con esto tenemos los fuentes de la parte web en nuestro entorno de desarrollo.
Figura 83: Importar el proyecto WEB. Fuente: Tesista. Autor: Tesista.
Y posteriormente tenemos los fuentes cargados en como se muestra en la Figura 84.
- 112 -
Figura 84: Proyecto WEB en el entorno de desarrollo. Fuente: Tesista. Autor: Tesista.
Una vez importado el proyecto WEB vamos a compilar los fuentes del “Back-End” de la
aplicación, para ello necesitamos abrir una consola de comandos y dirigirnos a la ruta de los
fuentes “PATH_HOME\sources\backend\” e ingresamos el comando “mvn clean
install” para compilar los fuentes. Una vez terminado la compilación nos dirigimos a la
ubicación “PATH_HOME\sources\clientes\flip\tesis\” y compilamos nuevamente para
empaqueta rodos los binarios y generar un archivo EAR. Completa la compilación nos
dirigimos a la ubicación “PATH_HOME\sources\clientes\flip\tesis\target\” y copiamos el
archivo “backend-4.1.ear” y lo pegamos en la ruta “PATH_HOME\jboss-as-
7.2.0\standalone\deployments\” del servidor de aplicaciones. Con esto ya podemos
levantar los servicios del servidor de aplicaciones.
- 113 -
Figura 85: Levantar los servicios del servidor de aplicaciones. Fuente: Tesista. Autor: Tesista.
Verificamos que los servicios se levanten correctamente y enseguida sobre el servidor de
aplicaciones le damos click derecho elegimos “Add and Remove” y seleccionamos la
aplicación web “flipper” con ello tenemos el ambiente de desarrollo funcionando.