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

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.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.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 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 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 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 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

- 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.


personas.

10 2 Guardar información

de clientes/empleados.

Personas.


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


3 Configuración técnica

Ingreso y mantenimiento de

módulos, canales, idiomas,

monedas, parámetros generales,

secuencias, transacciones y

resultados.

1


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


4 Parámetros del sistema


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


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


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 -


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


CARCHIVO NUMERIC(10) <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>

TPERPERSONA


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

EMAIL

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


CCATALOGO

CDETALLE

OPTLOCK

NOMBRE

CLEGAL

NUMERIC(4)

VARCHAR(6)

NUMERIC

VARCHAR(60)

VARCHAR(20)

<pk,fk>

<pk>

TSEGUSUARIO : 1


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


CUSUARIO

CCOMPANIA

CINTERNO

VARCHAR(20)

NUMERIC(4)

NUMERIC(6)

<pk>

<pk,fk>



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


CPERSONA

CCOMPANIA

NUMERIC(10)

NUMERIC(4)

<pk>

<pk,fk>



CCATALOGO

CDETALLE

OPTLOCK

NOMBRE

CLEGAL

NUMERIC(4)

VARCHAR(6)

NUMERIC

VARCHAR(60)

VARCHAR(20)

<pk,fk>

<pk>

TSEGUSUARIO


CUSUARIO

CCOMPANIA

CINTERNO

VARCHAR(20)

NUMERIC(4)

NUMERIC(6)

<pk>

<pk,fk>

TGENNACIONALIDAD


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>



CCATALOGO

CDETALLE

OPTLOCK

NOMBRE

CLEGAL

NUMERIC(4)

VARCHAR(6)

NUMERIC

VARCHAR(60)

VARCHAR(20)

<pk,fk>

<pk>

TPERPERSONA : 2


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


CPERSONA

CCOMPANIA

NUMERIC(10)

NUMERIC(4)

<pk>

<pk,fk>

TPERSECTORECONOMICO

(personas)

CSECTORECONOMICO

OPTLOCK

NOMBRE

VARCHAR(4)

NUMERIC

VARCHAR(100)

<pk>

TSEGUSUARIO


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


Avance Sprint 1

Estimado

Real

- 52 -


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.


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.


ingreso de la información de

personas naturales.

3

2

Transacción de ingreso y

mantenimiento de

personas jurídicas.


ingreso y mantenimiento de la

información de personas jurídicas.

3

3

Transacciones de ingreso

y mantenimiento de


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.


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.


Catálogos, Países, Provincias,

Cantones, Ciudades, Parroquias,

Nacionalidades, Compañías,

Sucursales, Agencias y Áreas.

6



- 54 -


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.


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.


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 -


PE

RS

ON

AS

JU

RÍD

ICA

S

3-2 Creación personas

jurídicas.

Ingreso de un usuario dado una

persona.


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.


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 -


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 -


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.


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 -


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.


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 -


-50

0

50

100

150

200

250

0 5 10 15 20 25 30

Ho

ras

rest

ante

s d

e t

rab

ajo


Avance Sprint 2

Estimado

Real

- 61 -


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.


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


Desarrollo de las transacciones

para el registro y

mantenimiento de productos

por agencia.

4

6

Movimiento y

recepción de


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


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


2




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


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


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


CPERSONA

CCOMPANIA

NUMERIC(10)

NUMERIC(4)

<pk>

<pk,fk>

FKTALMIMPUTALMIMPU

FKTALMPRODTGENCOMP

FKTALMPRODTPERPERS

FKTALMPRODTALMPROD

FKTALMIMPUTALMPROD

FKTALMPRODTGENCATAPROC

FKTALMPRODTGENMONE

FKTALMPRODTALMMARC

FKTALMPRODTGENARCH

TGENMONEDA


CMONEDA

OPTLOCK

NOMBRE

DECIMALES

VARCHAR(3)

NUMERIC

VARCHAR(60)

NUMERIC(1)

<pk>

TGENARCHIVO


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>



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


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>



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>



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


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


CPERSONA

CCOMPANIA

NUMERIC(10)

NUMERIC(4)

<pk>

<pk,fk>



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 -


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


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 -


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 -


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.


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


CPERSONA

CCOMPANIA

NUMERIC(10)

NUMERIC(4)

<pk>

<pk,fk>

TGENCATALOGODETALLE


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.


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.


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


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.


- 78 -


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.



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.




simulación fue de 70.376 milisegundos, con un tiempo de respuesta entre cada petición de





simulación fue de 1362693 milisegundos, con un tiempo de respuesta entre cada petición de


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.

http://nombrehost:8081/flipper

http://192.168.0.109:8081/flipper

- 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.

MANUAL DE USUARIO DEL SISTEMA 000

Documents

Transcript of MANUAL DE USUARIO DEL SISTEMA 000