UNIVERSIDAD NACIONAL DEL

CENTRO DEL PERÚ

FACULTAD DE INGENIERÍA DE SISTEMAS

TESIS
DISEÑO DE UN SISTEMA BASADO EN TECNOLOGÍA
WEB PARA EL CONTROL Y GESTIÓN DE VENTA DE
UNIDADES MÓVILES

Presentada por:
VÁSQUEZ RUDAS, Jhubel Favio.

PARA OPTAR EL TÍTULO PROFESIONAL DE:

INGENIERO DE SISTEMAS

HUANCAYO –PERÚ

2014
 ASESOR:

Mg. Jesús Ulloa Ninahuaman

ii
 AGRADECIMIENTOS:

Ante todo doy gracias a Dios Todopoderoso por darme la oportunidad de llegar hasta este
punto de mi existencia en que cumplo una meta tan importante como lo es graduarme de
Ingeniero de Sistemas.

Agradezco a mis padres por supuesto, por todo el apoyo y la confianza que han tenido para
conmigo, y su deseo de verme graduado.

Igualmente me siento agradecido con mi asesor y tutor de Trabajo de Grado, al cual le debo
el que esta nueva experiencia de realizar mi tesis.

A todos los docentes que en diversas formas contribuyeron con el fomento de mis
conocimientos en la materia de computación y sistemas de información.

Por último, pero no menos importante, agradezco a mis amigos (los que no pertenecen a la
universidad) y a mis compañeros de estudios universitarios, quienes nos ayudamos entre sí,
y que al igual que yo, espero pronto saber que finalizaron.

iii
 DEDICATORIA
A mis padres por su apoyo incondicional para
lograr mis objetivos en mi carrera profesional.

iv
 RESUMEN
La presente Tesis intitulada “Diseño de un Sistema basado en tecnología Web para el
control y gestión de venta de unidades móviles”. Para diseñar y crear este sistema se está
utilizando Tecnologías de la Información, un gestor de base de datos, tecnologías web
como medio de comunicación y elementos de seguridad que brindan confidencialidad al
sistema y a los datos que se transmiten. Para cumplir con estos requisitos la aplicación se
está utilizando de lenguaje de etiquetas HTML, el lenguaje de programación Java y un
sistema gestor de datos MySQL para generar contenidos dinámicos. Además se utilizarán
diferentes herramientas que ayuden a cumplir con los requerimientos especificados en el
diseño.

El diseño del sistema web que se presenta en este trabajo de tesis es crear un sistema de
control y gestión que permita a la agencia de venta ofrecer una fuente de información a
través de la web, con el sistema, se pretende permitir al usuario acceder a la información de
la agencia que necesite para poder realizar los procesos que le corresponde, enlazándose
desde cualquier computador de la agencia.

El sistema permitirá hacer análisis de los datos que contiene la Base de Datos utilizando los
formularios de búsquedas para obtener resultados específicos como datos de cliente,
productos, ventas realizadas; los cuales son importantes para evaluar el desempeño de los
vendedores y el estado de ventas de la agencia. Los datos que se transmiten son
protegidos por los elementos de seguridad que brindan confiabilidad.

El diseño del sistema Web puede mejorar la imagen y los servicios de la empresa mediante
una aplicación que facilite las operaciones y el control de la información de los clientes y
productos además de mejorar el proceso de atención de venta a los clientes lo cual
ayudaría a captar nuevos clientes, por lo que, el sistema Web vendrá complementado con
una serie de funcionalidades para el manejo y control de información relacionada con la
empresa.

v
 ABSTRACT
This thesis entitled "Design of a Web-based technology for the control and management of
mobile Information System." To design and create this system is being used Information
Technology, a manager of database, and web technologies as a means of communication
and security features that provide confidentiality to the system and the data transmitted. To
meet these requirements the application is using HTML language tags, the Java
programming language and MySQL database manager system to generate dynamic
content. Also different tools to help meet the requirements specified in the design will be
used.

Web design system presented in this thesis is to create a control and management system
that allows the agency to provide a source of sales information via the web, the system is
intended to allow the user to access information the agency needs to perform processes
corresponding to it, from any computer liaise agency.

The system will do data analysis containing the database using forms searches for specific
outcomes such as customer data, product sales; which are important for evaluating the
performance of vendors and sales status of the agency. The data transmitted is protected by
security features that provide reliability.

The design of the Web system can improve the image and services of the company through
an application that facilitates the operations and control of customer information and
products as well as improving the care process of selling to customers which would help
capture new customers, so that the web system will come complete with a variety of features
to manage and control information related to the company.

vi
 INDICE

Pág.
ASESOR ii
AGRADECIMIENTOS iii
DEDICATORIA iv
RESUMEN v
ABSTRACT vi
ÍNDICE vii
1.
INTRODUCCIÓN 01
CAPÍTULO I
GENERALIDADES
1.1. PLANTEAMIENTO DEL PROBLEMA 02
1.2. FORMULACIÓN DEL PROBLEMA 03
1.3. OBJETIVOS DE LA INVESTIGACIÓN 03
1.4. JUSTIFICACIÓN 03
1.4.1.Justificación Practica 03
1.4.2.Justificación Teórica 04
1.4.3.Justificación Metodológica 05
1.5. HIPÓTESIS 05
1.6. DISEÑO METODOLÓGICO 05
1.6.1.Tipo de Investigación 05
1.6.2.Nivel de la Investigación 06
1.6.3.Fuentes de Información 06
1.6.4.Alcance 07
1.6.5.Operacionalizacion de Variable 07
1.6.6.Validación de Indicadores 07
2.
CAPÍTULO II
MARCO DE REFERENCIA
2.1. ANTECEDENTES 09
2.1.1.Consumo de teléfonos móviles entre adolescentes y jóvenes en el Perú 09
2.1.2.Diseño e implementación de una tienda virtual 10
2.1.3.Diseño e implementación de un portal web para una empresa de
sistemas de iluminación 11
2.1.4.Desarrollo de una aplicación Web para la gestión de Entornos Virtuales 12
2.1.5.Desarrollo de una aplicación web basada en tecnología helpdesk para
ofrecer servicios de soporte técnico e inventario en la gerencia de

vii
 informática de la Empresa C.A. Hidrológica del centro, en valencia
estado Carabobo 12
2.2. MARCO TEÓRICO 13
2.2.1.Programación Orientada a Objetos 13
2.2.2.Base de Datos 13
2.2.3.Base de Datos – MySQL 14
2.2.4.Ingeniería de Software 15
2.2.5.Programación Web 16
2.2.6.Sitio Web 16
2.2.7.El Lenguaje HTML 17
2.2.8.Plataforma J2EE 18
2.2.9.CSS 18
2.2.10. Ajax 19
2.2.11. Apache Web Server 19
2.2.12. Concepto de Control de Gestión 19
2.2.13. Metodología de desarrollo de software 21
2.2.14. Metodología Rational Unified Process (RUP) 22
2.3. Modelo Aplicativo 27
2.4. Marco Conceptual 30
3.
CAPÍTULO III
INTERVENCION METODOLOGICA
3.1. CAPTURA DE REQUISITOS 32
3.1.1.Modelado de Negocio 32
3.1.2.Requerimientos 33
3.1.2.1. Requerimientos Funcionales 33
3.1.2.2. Requerimientos No Funcionales 36
3.1.3.Actores del Sistema 36
3.1.4.Diagramas de Caso de Uso 37
3.2. ANALISIS 37
3.2.1.Modelos de Caso de Uso 37
3.2.1.1. Realización de Casos de Uso del Negocio 38
a. Caso Uso del Módulo de Personal 39
b. Caso Uso del Módulo de Almacén - Ingreso 40
c. Caso Uso del Módulo de Almacén - Funciones 41
d. Caso Uso del Módulo de Activación 42
e. Caso Uso del Módulo de Ventas - Postpago 42
f. Caso Uso del Módulo de Ventas - Prepago 44
3.2.2.Análisis de Riesgos 46
3.3. DISEÑO 46

viii
 3.3.1.Diagrama de Clase 47
3.3.2.Diagrama de Paquetes 47
3.3.3.Diagrama de Secuencia 49
a) Diagrama 1: Personal 49
b) Diagrama 2: Almacén – Ingreso 50
c) Diagrama 3: Almacén – Funciones 50
d) Diagrama 4: Activación 51
e) Diagrama 5: Ventas 52
3.3.4.Diagrama de Colaboración 53
a) Diagrama 1: Personal 53
b) Diagrama 2: Almacén - Ingreso 53
c) Diagrama 3: Almacén - Funciones 54
d) Diagrama 4: Activación 54
e) Diagrama 5: Ventas 55
3.3.5.Generación de Base de Datos 56
3.3.6.Modelo de Diseño 56
3.3.6.1. Interfaz del Sistema 56
3.4. IMPLEMENTACION 65
3.4.1.Arquitectura del Sistema 66
3.4.1.1. Diagrama de Capas 67
3.4.2.Publicación 68
3.5. PRUEBAS 72
3.5.1.Justificación de las Pruebas de Cristal y Unitarias 72
3.5.2.Pruebas de Integración 73
3.5.3.Pruebas de Estrés 73
3.5.4.Pruebas de Seguridad 75
3.5.4.1. Resultado de pruebas Owasp 75
4.
CAPÍTULO IV
ANALISIS Y DISCUSION DE RESULTADOS
4.1. MAECO ESTADISTICO 77
4.1.1.Procesos Completados 77
A. Administración del Personal 77
B. Generación de Ventas 78
C. Ingreso de Equipos y Tarjetas SIM 78
D. Inventario de Equipos y Tarjetas SIM 79
E. Consolidación de Ventas 79
4.1.2.Respecto a los Usuarios 79
4.2. PRUEBA DE HIPOTESIS 80
4.2.1.Análisis Estadístico de las Pruebas 84

ix
CONCLUSIONES
RECOMENDACIONES
REFERENCIAS

x
 INDICE DE FIGURAS
Pág.
Figura N° 2.1. Modelos que Comprende UWE 22
Figura N° 2.2. Estructura de RUP 23
Figura N° 2.3. Fases e Hitos en RUP 25
Figura N° 2.4. Diagrama de Representación del ejemplo 26
Figura N° 2.5. Iteración Rup 28
Figura N° 3.1. Diagrama General de Responsables 38
Figura N° 3.2. Diagrama de Caso de Uso Módulo Personal 39
Figura N° 3.3. Diagrama de Caso de Uso Módulo Almacén – Ingreso 40
Figura N° 3.4. Diagrama de Caso de Uso Módulo Almacén – Funciones 41
Figura N° 3.5. Diagrama de Caso de Uso Módulo Activación 42
Figura N° 3.6. Diagrama de Caso de Uso Módulo Ventas – postpago 43
Figura N° 3.7. Diagrama de Caso de Uso Módulo Ventas – Prepago 44
Figura N° 3.8. Diagrama de Clase del Sistema 48
Figura N° 3.9. Diagrama de Organización del Área 49
Figura N° 3.10. Diagrama de Secuencia Módulo Personal 49
Figura N° 3.11. Diagrama de Secuencia Módulo Almacén – Ingreso 50
Figura N° 3.12. Diagrama de Secuencia Módulo Almacén – Funciones 51
Figura N° 3.13. Diagrama de Secuencia Módulo Activación 51
Figura N° 3.14. Diagrama de Secuencia Módulo Ventas 52
Figura N° 3.15. Diagrama de Colaboración Módulo Personal 53
Figura N° 3.16. Diagrama de Colaboración Módulo Almacén – Ingreso 53
Figura N° 3.17. Diagrama de Colaboración Módulo Almacén – Funciones 54
Figura N° 3.18. Diagrama de Colaboración Módulo Activación 54
Figura N° 3.19. Diagrama de Colaboración Módulo Ventas 55
Figura N° 3.20. Base de Datos del Personal 56
Figura N° 3.21. Pantalla de Acceso 57
Figura N° 3.22. Pantalla de Menú Principal 58
Figura N° 3.23. Pantalla de Ventas Colectivos 59
Figura N° 3.24. Pantalla de Ventas Negocios 59
Figura N° 3.25. Pantalla de Ventas Residencial 60
Figura N° 3.26. Pantalla de Modificación del Personal 61
Figura N° 3.27. Pantalla de Modificación de Activación 61
Figura N° 3.28. Pantalla de Modificación del Cliente 62
Figura N° 3.29. Pantalla de Ingreso de Tarjeta SIM 62
Figura N° 3.30. Pantalla de Registro tipo Chip 63
Figura N° 3.31.Pantalla de Ingreso de Planes 63
Figura N° 3.32.Pantalla de Ingreso de Equipos 63

xi
Figura N° 3.33. Pantalla de Búsqueda de Tarjeta SIM 64
Figura N° 3.34. Pantalla de Búsqueda de Equipos 64
Figura N° 3.35. Pantalla de Búsqueda de Clientes 65
Figura N° 3.36. Diagrama de Componentes 66
Figura N° 3.37. Pantalla de Ingreso a cPanel 69
Figura N° 3.38. Pantalla de Opciones 69
Figura N° 3.39. Pantalla Administrador de Archivos 70
Figura N° 3.40. Pantalla de Selección de Directorios 70
Figura N° 3.41. Pantalla Web Root 71
Figura N° 3.42. Pantalla Carga de Archivos 71
Figura N° 3.43. Pantalla Carga y Solicitudes hechas al Servidor 75
Figura N° 4.1. Resultado de Cuestionario 82
Figura N° 4.2. Tiempo de Demora en el Proceso de Ventas 83
Figura N° 4.3. Tiempo de Demora en el Proceso de Ingreso de Series 84
Figura N° 4.4. Tabla de la T de Student 85
Figura N° 4.5. Calculo del Estadígrafo “t” 86

xii
 INDICE DE CUADROS
Pág.
Cuadro N° 1.1.: Preguntas Frecuentes 07
Cuadro N° 1.3.: Variables e Indicadores 08
Cuadros del Diagrama General de Responsables 39
Cuadros del Diagrama de Caso de Uso Módulo Personal 40
Cuadros del Diagrama de Caso de Uso Módulo Almacén – Ingreso 40
Cuadros del Diagrama de Caso de Uso Módulo Almacén – Funciones 41
Cuadros del Diagrama de Caso de Uso Módulo Activación 42
Cuadros del Diagrama de Caso de Uso Módulo Ventas - Postpago 43
Cuadros del Diagrama de Caso de Uso Módulo Ventas - Prepago 45
Cuadro N° 3.1 Riesgos 46
Cuadro N° 3.2 Validaciones y Verificaciones 73
Cuadro Nº 3.3 Web Server Stress Tool 7 74
Cuadro Nº 3.4 Resultados obtenidos de Web Server 74
Cuadro Nº 3.5 Pruebas del Sistema OWASP 76
Cuadro N° 4.1 Modelo de escala de likert 80
Cuadro N° 4.2 Resultados obtenidos del Cuestionario 81
Cuadro N° 4.3 Cuadro Comparativo 82
Cuadro N° 4.4 Tiempos del proceso de ventas 84

xiii
 INTRODUCCIÓN
En la actualidad las agencias de venta de unidades móviles no cuentan con un sistema por
el cual puedan llevar un control de las ventas que han realizado, además de no llevar un
control de ventas de cada vendedor, otro aspecto importante es que las agencias realizan
las ventas de forma manual digitando las series de las tarjetas SIM y equipos móviles lo
cual ocasiona que en ocasiones se digiten mal las series lo cual genera demora en la venta.

En el capítulo I se presentan la situación del problema que se presentan al momento de

realizar una venta, después de identificar el problema se muestran el planteamiento del
problema y la importancia que tiene esta investigación, dando a conocer las razones a
través de la justificación correspondiente, la hipótesis generada, se puntualizan los objetivos
generales y específicos; y finalmente, se dan a conocer los alcances y los aportes de este
trabajo de tesis.

En el capítulo II se presentan aspectos generales relacionados con el trabajo de

investigación a realizar en este trabajo de tesis. En primer lugar, se muestran los
antecedentes científicos y de investigación; en seguida, se da a conocer el Marco teórico
que es nuestro sustento sostenible para la elaboración de la tesis y como parte final
tenemos el Marco conceptual que es como un glosario donde se ingresan algunas palabras
o frases que no son muy conocidas y que se está utilizando en la presente tesis.

En el capítulo III mostraremos el desarrollo del diseño, empleando la metodología RUP y el

empleó del Lenguaje Unificado de Modelamientos (UML), basándose en las fases de Inicio,
Elaboración, Construcción y Transición.

En el capítulo IV se muestra los posibles resultados del desarrollo del proyecto donde se ha
evaluado el diseño del sistema, con el fin de asegurarnos que se cumplan los objetivos
impuestos en la presente tesis. Estas evaluaciones nos permitirán observar el correcto
funcionamiento de los módulos, así como aspectos de seguridad, compatibilidad de la
aplicación, y son descritas en el actual capítulo.

Nuestra aplicación tendrá clasificados los productos por modelos, además para poder
facilitar la localización de nuestro material informático, se dispondrá de una pequeña
aplicación que realizará la búsqueda por palabras clave. Lo cual permitirá al usuario tener
una búsqueda más rápida y efectiva.

Jhubel Favio Vásquez Rudas

1
 CAPÍTULO I
GENERALIDADES
En el Capítulo I se da a conocer la situación del problema que se presenta al momento de
realizar una venta de equipos móviles y la identificación de las variables que afectan al
problema principal. Después de identificar el problema general planteamos el objetivo y la
hipótesis. En las justificaciones daremos a conocer la metodología a utilizar así como el
sustento y el beneficio de la realización del estudio en las agencias de ventas.

1.

1.1. PLANTEAMIENTO DEL PROBLEMA

En la agencia de ventas “Corporación Telenegocios Perú SA·C”, existen diferentes
áreas donde existen varias funciones que realizan los trabajadores de forma manual y
otros en archivos Word y Excel.

Al momento de realizar una venta el personal del área de ventas muestra la lista de
los equipos disponibles al cliente para que elija, después que el cliente ha realizado la
elección del equipo el vendedor solicita las series de los equipos y Tarjeta SIM a
almacén genera una hoja venta con los datos del cliente, tipo de plan, series del
equipo y tarjeta SIM para entregar al activador para que realice la activación del
equipo y tarjeta SIM además de asignar un número telefónico, cuando el cliente
realiza el pago se le entregara un comprobante de pago y guía de remisión los cuales
entrega al vendedor para que pueda recoger de almacén los equipos y hacerle la
entrega al cliente después de hacerle firmar el contrato de servicio.

El área de almacén tiene las siguientes funciones: recepcionar y llevar un control de

los equipos y tarjetas SIM, realizar los picking de los pedidos, brindar las series de los
equipos tarjetas SIM a los vendedores, entregar los equipos y tarjetas SIM activados,

2
 realizar stock de equipos e inventarios periódicamente, reingresar equipos y tarjetas
SIM que fueron anulados y otros.

Cabe destacar que las áreas no realizan las asignaciones de activos con un orden
especifico, por tanto se puede causar el descontento e inconformidad de los clientes,
provocando demora, incomodidad en varias oportunidades por falta de un monitoreo
constante que permita conocer cuáles son las atenciones pendientes, además de esto
no se cuenta con un sistema de inventario que actualice periódicamente lo existente
en el área de almacén, lo que ocasiona falta de información precisa de lo que se tiene,
gastos excesivos de tiempo y dificultad para llevar el seguimiento y control de los
activos y sus asignaciones.

En vista de lo descrito, se analizarán las necesidades generales de las áreas a fin de

determinar los requerimientos reales del sistema que se desea crear, diseñar,
desarrollar e implantar, usando una metodología de apoyo. El desarrollo de este
proyecto se realizará siguiendo las normativas para la creación de aplicaciones, la
cual exige el uso de herramientas libres a fin de cumplir con lo establecido, entre
estas se puede mencionar: Sistema manejador de Base de Datos MySql y Java como
lenguaje de programación de código abierto.

1.2. FORMULACIÓN DEL PROBLEMA

1.2.1. Problema General

¿Cómo influye un Sistema basado en tecnología Web en el Control y Gestión

de venta de unidades móviles?

1.3. OBJETIVO DE LA INVESTIGACIÓN

1.3.1. Objetivo General

Mejorar el control y gestión de venta de unidades móviles, mediante el diseño

un Sistema basado en Tecnología Web.

1.4. JUSTIFICACIÓN
1.4.1. Justificación Practica

El desarrollo del sistema web para el control y gestión de ventas de unidades

móviles en línea que sea accesible desde cualquier punto de internet, permitirá
mayor dinamismo en cualquier operación de la agencia de ventas, ya que el

3
 proceso de ventas ya no sería centralizada sino que podría hacerse a través de
cualquier punto con acceso a Internet y en cualquier parte de la agencia de
ventas o donde se encuentre el vendedor, lo que permitirá las siguientes
mejorías: El tiempo que lleva hacer el proceso de relleno del registro de ventas
se disminuiría considerablemente, revisar el stock disponible de los productos
en la agencia de ventas, revisar las cantidades de ventas del vendedor. Por lo
tanto materializar dicho proyecto resultaría necesario e importante para los
trabajadores de la agencia de ventas, así mismo estar a la vanguardia de la
tecnología presente en todo el mundo.

Además el desarrollo de sistema aportará gran cantidad de beneficios, entre

los cuales se encuentran:

1. Agilizar los procesos de registro y control de los activos por parte del
Departamento de Almacén.
2. Garantizar el manejo de la información y la generación a tiempo de
reporte sobre dichos activos.
3. Consultar el estado de las ventas registradas para un mejor servicio a los
clientes.
4. Evitar la pérdida de información debido a que esta, estará almacenada
en una base de datos confiable que permitirá centralizar toda la
información.

1.4.2. Justificación Teórica

El conocimiento práctico y concreto de nuevos mercados para el producto, en

este caso venta de unidades móviles, abre las alternativas de mejores
mecanismos de comercialización, lo cual incentiva a los actores esenciales,
como es el caso de las agencias de ventas, que sabiendo que son capaces por
si mismos de lograr el objetivo de poder encontrar nuevas ventas, poder
irradiar y multiplicar al resto de agencias.

El propósito de desarrollar esta web es para poder facilitar los procesos de las
áreas de la agencia, mostrar información actual y necesaria para poder realizar
las ventas, el control de equipos, costos y algunos procesos demás.

4
 1.4.3. Justificación Metodológica

La visión de la Agencia de ventas actualmente debe centrarse a mejorar sus

niveles de competitividad y pensar seriamente en introducir una herramienta
que le proporcione medir los indicadores y que le indiquen el grado de
eficiencia en el que se va conduciendo la gestión.

El proyecto genera información válida y confiable, donde el usuario puede ver

un avance progresivo de lo que se va trabajando. Es por esto que se hace
necesario entregar al usuario interfaces y procedimientos basados en
prototipos para familiarizar al usuario y así tener un mayor grado de
retroalimentación con él. Como proceso de desarrollo en el presente proyecto
se utilizará la metodología RUP, llamada así por sus siglas en inglés Rational
Unified Process, es un proceso de ingeniería del software. Proporciona un
acercamiento disciplinado a la asignación de tareas y responsabilidades en
una organización de desarrollo. Su propósito es asegurar la producción de
software de alta calidad que se ajuste a las necesidades de sus usuarios
finales con unos costos y un calendario predecibles.

1.5. HIPOTESIS GENERAL

1.5.1. Hipótesis General

El diseño del sistema basado en tecnología web, mejora el control y gestión de

venta de unidades móviles.

1.6. DISEÑO METODOLOGICO

1.6.1. Tipo de Investigación

La investigación realizada es tecnológica aplicada, la cual se centra en la

planificación basada en los procesos de aplicación, más que en la tecnología
misma. Se centra en el análisis de la forma en que se han de usar los recursos
tecnológicos para el cumplimiento de objetivos específicos. Se habla de
tecnología aplicada cuando se piensa en un tipo específico de organización y
aplicación de los procesos tecnológicos, lo cual comprende aspectos de
carácter normativo y aspectos referidos a la responsabilidad social. En otros
contextos, además, se remite a las capacidades de la tecnología para proveer
bienes y servicios.

5
1.6.2. Nivel de la Investigación

El estudio corresponde al nivel descriptivo explicativo, por cuanto en el diseño

se describe las características de cada uno de los componentes, del sistema
basado en tecnología web para el control y gestión de venta de una tienda de
celulares.

1.6.3. Fuentes de Información

Datos proporcionados por la Agencia de ventas Corporación Telenegocios

Perú SAC (Hojas, de Ventas, Guías de remisión).

Se usará la entrevista para el análisis del sistema de control y gestión, y un

cuestionario para validar la funcionalidad del sistema. Plan de recolección de la
información.

Cuadro N° 1.1. Preguntas Frecuentes

PREGUNTAS EXPLICACION
Para profundizar los conocimientos
relacionados con el tema de investigación y
¿Para qué? así lograr descubrir, comprender e interpretar
los hechos, fenómenos y relaciones de un
determinado ámbito de la realidad.
La investigación se realizara al Gerente de la
¿A qué persona
empresa, a los trabajadores de cada área y
o sujetos?
clientes actuales de la empresa.
La información estará basada sobre los
¿Sobre qué objetivos de ventas de la empresa, ofertas,
aspecto? promociones, servicio, almacén, atención,
exigencias y expectativas de los clientes.
Quien se encargara de la recolección de toda
¿Quién? la información es el investigador Jhubel
Vásquez Rudas.
La recolección de la información se realizara
todo el tiempo que sea necesario,
¿Cuándo?
empezando desde la indagación del
problema de estudio.

6
 La técnica que se emplea para la recolección
¿Qué técnica de
de la información será la encuesta, entrevista
recolección?
y la observación.
Mediante la elaboración de un cuestionario
¿Con que? de preguntas, entrevistas y una ficha de
observación.
Fuente: El Investigador
Elaborado por: El Investigador

1.6.4. Alcance

El sistema propuesto de software a desarrollar, cumplirá con los siguientes

requerimientos:

 Desarrollar un sistema de control y gestión de indicadores de ventas para

evaluaciones del personal de ventas.
 La automatización de las funciones y procesos de las áreas de la
agencia.
 Con los resultados que se obtendrá del sistema, se procederá a realizar
un reporte de estado de ventas que nos permitirá saber cuáles son los
representantes ligados y como va avanzando el trabajo para llegar a las
cantidades impuestas por las Empresa Telefónica del Perú.

1.6.5. Operacionalización de Variable

A continuación se identifican las variables dependientes e independientes del

presente estudio.

Variable Independiente

Sistema basado en Tecnología Web.

Variable Dependiente

Control y Gestión de ventas de unidades móviles.

1.6.6. Validación de Indicadores:

Para sustentar los indicadores de la Variable Independiente “Sistema basado

en Tecnología Web”, es necesario recolectar información de los futuros

7
 usuarios, ya que las necesidades y requerimientos por el motivo que son ellos
quienes van a utilizar el sistema.

En cuanto al indicador de la Variable Dependiente “Control y Gestión de ventas

de unidades móviles”, los usuarios tendrán acceso a la información de todas
las áreas según sea la necesidad de cada usuario.

Cuadro N° 1.2.: Variables e Indicadores

Variables Micro Variable Indicadores

Diseño del sistema Definir el diseño y

V.I. Sistema basado web procesos del sistema web

en Tecnología Web Nivel de aceptación Disposición de los usuarios

del Sistema para utilizar el sistema

Disposición de información
Control de la
actualizada entre las
información
V.D. Control y gestión áreas.

de equipos móviles
Tiempo en realizar el
Gestión de Ventas
proceso de venta.

Fuente: El Investigador
Elaborado por: El Investigador

En el proceso de ventas es donde parte todo para lograr el mejoramiento de la agencia de

ventas, ya que son los vendedores quienes interactúan con los clientes; y son los
encargados de ingresan la información de los ellos a la empresa, en la actualidad la
información de los clientes solo se tiene de forma física (hojas de ventas), y de los equipos
en archivo Excel. Lo cual ocasiona demora en caso haya algún reclamo por parte de la
Empresa telefónica del Perú, se tiene que buscar físicamente los documentos para
sustentar el reclamo.

8
 CAPÍTULO II
MARCO DE REFERENCIA
En el Capítulo II se muestran los antecedentes, estudios realizados anteriormente
relacionados con el ámbito de la presente Tesis que han servido para la solución de
problemas utilizando las distintas metodologías. En el Marco Teórico se muestran las
teorías y libros, así como los pasos a seguir de la Metodología RUP en los procesos de
implantación, aceptación y mantenimiento del Sistema, finalmente se muestra el marco
conceptual para comprender cada uno de los términos asociados a la tesis.

2.

2.1. ANTECEDENTES

Luego de la búsqueda de fuentes bibliográficas referentes al objeto de estudio

presentamos los siguientes antecedentes investigativos:

2.1.1. Miranda Cerruti, Renzo André; Martínez Ruiz, Alejandro; Leiva Mier, Ana
Paz; Madrid Vega, Rodrigo Mauricio, Enrique Jiménez, Luis Ricardo
(2012). Consumo de teléfonos móviles entre adolescentes y jóvenes en el
Perú. Trabajo de Comunicación social

Debido a la popularidad que han adquirido los teléfonos móviles, es raro

encontrar a una persona que no cuente con uno de ellos. En nuestro país, la
situación no es diferente. Incluso, un estudio realizado por OSIPTEL hace dos
años demuestra que en seis departamentos del Perú la cantidad de celulares
supera el número de habitantes que residen en ellos: Lima, Tacna, Arequipa,
Moquegua, Ica y Madre de Dios. Dentro de este fenómeno comunicacional, los
jóvenes son parte importante, pues se encuentran detrás de las últimas
tecnologías para experimentarlas.

9
 En este trabajo presentaremos los datos más importantes acerca de los usos,
financiamiento y difusión de la telefonía celular en la juventud peruana y en
varios casos la contrastaremos con datos de Iberoamérica.

2.1.2. Aroca Martínez, Francisco (2010). Diseño e implementación de una tienda

virtual. Tesis de Grado. Universitat Politécnica de Valencia.

En resumen se trata de desarrollar una aplicación para facilitar la venta de

material informático así como ayudar a su gestión, de una forma sencilla y
clara para los usuarios y el administrador de la aplicación.

Los objetivos concretos consistirán en:

 Mostrar un catálogo de los productos a nuestros posibles clientes.

 Permitir la compra de los productos que aparezcan en nuestra aplicación.
 Facilitar el mantenimiento de dicho catálogo.

Los resultados y productos que se piensan obtener:

 Una aplicación web para dar a conocer nuestros productos.

 Facilitar la gestión tanto del material como de los usuarios.

El método para guiar el desarrollo del proyecto se basará en las siguientes

etapas:

 La especificación de requisitos basada en la definición de casos de uso.

 El proceso de análisis basado en modelos UML.
 La definición de la arquitectura basada en tres capas.

Diseño e implementación de una tienda virtual

 La codificación de un prototipo de la aplicación.

 La realización de pruebas técnicas del sitio Web.

Los recursos disponibles consistirán en:

 Un entorno de diseño Web basado en herramientas convencionales.

WAMP el cual incluye Java, MySQL y Apache.
 Un servidor Web.
 Un alumno con dedicación completa.

10
2.1.3. Alsina Morillo, Joan (2009). Diseño e implementación de un portal web
para una empresa de sistemas de iluminación. Tesis de Grado.
Universitat Autónoma de Barcelona.

Este proyecto consiste en el diseño e implementación de un portal WEB para

una empresa que se dedica al desarrollo de aplicaciones para el diseño y
control de sistemas de iluminación. Esta empresa desea ampliar los servicios
que oferta a sus clientes mediante una aplicación que facilite la descarga de
las actualizaciones del software que la empresa desarrolla entre otras
funcionalidades.

Además, la empresa diseña modelos de funcionamiento para dispositivos

físicos, basados en el protocolo DMX512 (Digital MultipleX). Estos modelos son
de vital importancia para la expansión de la empresa ya que complementan el
software de diseño de instalaciones de iluminación. Además, a día de hoy,
existen pocas empresas que se dediquen al diseño de estos modelos. Por
tanto, también se desea que estos modelos de funcionamiento se distribuyan a
través del portal WEB, para mejorar el servicio a sus clientes.

Por otro lado, la implantación del portal WEB puede mejorar la imagen de
empresa y ayudar a captar nuevos clientes, por lo que, el portal vendrá
complementado con una serie de funcionalidades para la difusión de
información relacionada con la empresa.

Por tanto, el objetivo principal del proyecto es facilitar a los clientes de la

empresa el acceso a las actualizaciones de software y a los modelos de
funcionamiento a través de un portal WEB. De esta manera se mejora el
servicio que oferta la empresa en el momento de la solicitud del proyecto.
Además, se desea mejorar la imagen de empresa que se ofrece a los clientes y
futuros clientes incluyendo información relacionada con la empresa y sus
productos.

Para cumplir con estos requisitos la aplicación hará uso del lenguaje de
etiquetas HTML junto con CSS, el lenguaje de programación PHP y él un
sistema gestor de datos MySQL para generar contenidos dinámicos. Además
se utilizarán diferentes herramientas que ayuden a cumplir con los
requerimientos especificados en el proyecto.

11
2.1.4. Almaraz Hernández, Jesús Matías; Campos Cantero, Pablo; Castelo
Delgado, Tamara (2011). Desarrollo de una aplicación Web para la gestión
de Entornos Virtuales. Tesis de Grado. Universidad Complutense de
Madrid.

El objetivo de este proyecto es proporcionar a un potencial usuario una

aplicación para la gestión de entornos virtuales sobre las que se realizarán las
prácticas de las asignaturas de una determinada titulación dada. A su vez,
distinguimos tres tipos o niveles diferentes de usuarios: alumnos, profesores y
administradores. Los cuales tendrán acceso a diferentes funcionalidades y
recursos en función de su nivel de autenticación en el sistema.

Esta interfaz de usuario con la que se proveerá a la aplicación es del tipo Web,
siendo así accesible e intuitiva de cara a los posibles usuarios, ya que destaca
por su claridad y fácil uso de la misma.

Como es lógico, la aplicación dispone de una base de datos en la que se

gestionen y manejen todos los datos correspondientes a los diferentes
alumnos, profesores y administradores. Así pues, amén de tener que
comunicarse la interfaz con la base de datos para la autenticación de usuarios,
en la aplicación es posible la realización de consultas y modificaciones en la
base de datos a través de la interfaz.

2.1.5. Suniaga Salazar, José Miguel (2009).Desarrollo de una aplicación web

basada en tecnología helpdesk para ofrecer servicios de soporte técnico
e inventario en la gerencia de informática de la empresa c.a. Hidrológica
del centro, en valencia estado Carabobo. Tesis de Grado. Universidad de
Oriente

La Gerencia de Informática de la empresa C.A. Hidrológica del Centro,

HIDROCENTRO tiene como objetivo ofrecer a los empleados de la empresa
servicios de calidad en el área de información; desarrollando sistemas óptimos
y dando soporte a los recursos informáticos con eficiencia, en el menor tiempo
posible.

En tal sentido, la Gerencia de Informática debe: mantener un control del

inventario de los recursos informáticos de la empresa así como de los servicios
que se prestan a estos, de manera que se pueda gestionar los equipos que

12
 estén activos y vigilar el desempeño de los servicio de soporte técnico a cargo
de los empleados de la gerencia.

Actualmente, la gerencia lleva este control de manera manual, es por esa

razón que se requiere de un proyecto que permita la automatización de dichos
procesos. En este informe de trabajo de grado se presenta el diseño de un
Sistema de Administración de Inventario y Mantenimiento de Equipos (SAIME)
que apoyará los procesos descritos anteriormente, el cual está modelado y
documentado bajo el Lenguaje Unificado de Modelado (UML), siguiendo la
metodología RUP, implantado bajo la plataforma Windows, programado con el
lenguaje de programación Java y cuyos datos son almacenados en una base
de datos Postgre SQL.

2.2. MARCO TEORICO

2.2.1. Programación Orientada a Objetos

Actualmente, el paradigma de programación más usado debido a múltiples

ventajas respecto de sus antecesores es el de Programación Orientada a
Objetos.

La Programación Orientada a Objetos permite concebir los programas de una

manera bastante intuitiva y cercana a la realidad. Si bien la programación
procedural y estructurada ha dado solución durante muchos años a los
sistemas computacionales, presenta una desventaja en su construcción, ya
que cuando una aplicación crece, la modificación del código se hace muy
trabajosa y difícil, debido a que el cambio de una línea de programación
acarrea -seguramente- la modificación de muchas líneas de código
pertenecientes a otras funciones y procedimientos que están relacionados.

La POO nos permite agrupar códigos con funcionalidades comunes,

encapsulándolos y haciéndolos independientes, conviniendo que la aplicación
crezca sin tener que realizar cambios en el código.

2.2.2. Base de Datos

Una base de datos computarizada me parece importante para el mejor control

y búsqueda de datos en masa de una manera sencilla y rápida.

13
 Esta base de datos es usada por empresas grandes ya que ellas manejan una
gran cantidad de datos y ya que este sistema se los hace mucho más fácil y
rápido.

¿Se imaginan llenar 50 mil formularios para dar de alta a alguien o a algo a
mano, y después buscarlo?, ¿o buscar un libro en una biblioteca con más de
500 mil ejemplares para su consulta?, es muy laborioso y tardado, con la base
de datos solo tecleamos el nombre de lo que buscamos y ya tendremos todos
sus datos para la utilización de estos.

Como ven otra ventaja de la base de datos es economizar gastos de

infraestructura, ya que solo nos basta tener una computadora, crear la base de
datos y ya.

Una ventaja muy importante de la base de datos es evitar la redundancia de

los datos, ya que el sistema no permite que pongas dos o más veces el mismo
dato, otra ventaja de la base de datos es la seguridad de los datos, ya que solo
el administrador principal puede modificar todos los datos, y los
administradores secundarios con ciertos permisos solo pueden modificar
ciertos datos.

2.2.3. Base de Datos – MySQL

El lenguaje SQL es un lenguaje estándar de manejo de bases de datos

masivamente usado en cualquier entorno. MySQL es un sistema de gestión de
bases de datos basado en el lenguaje SQL. Es muy ampliamente usado en
entornos web, en combinación con lenguajes de servidor como PHP.

MySQL es un gestor de base de datos sencillo de usar e increíblemente rápido.

También es uno de los motores de base de datos más usados en internet, la
principal razón de esto es que es gratis para aplicaciones no comerciales.

Posee la facilidad de uso de cualquier sistema basado en SQL y añade

versatilidad en el manejo de las bases de datos, y una tremenda escalabilidad,
que hace que el mismo sistema sea válido para cualquier tamaño de bases de
datos.

Es el servidor de base de datos relacionales de fuente abierta más popular en

el mundo. Su arquitectura lo hace extremadamente rápido y fácil de adaptar.

14
 Las características principales de MySQL son:

 En un gestor de base de datos. Una base de datos es un conjunto de

datos y un gestor de base de datos es una aplicación capaz de manejar
este conjunto de datos de manera eficiente y cómoda.
 Es una base de datos relacional. Una base de datos relacional es un
conjunto de datos que están almacenados en tablas entre las cuales se
establecen unas relaciones para manejar los datos de una forma eficiente
y segura. Para usar y gestionar una base de datos relacional se usa el
lenguaje estándar de programación SQL.
 Es Open Source. El código fuente de MySQL se puede descargar y esta
accesible a cualquiera, por otra parte, usa la licencia GPL para
aplicaciones no comerciales.
 Es una base de datos muy rápida, segura y fácil de usar. Gracias a la
colaboración de muchos usuarios, la base de datos se ha ido mejorando
optimizándose en velocidad. Por eso es una de las bases de datos más
usadas en internet.

2.2.4. Ingeniería de Software

La ingeniería se compone por varias fases y en el caso del diseño de software

no tenemos excepción ya que para su construcción debemos generar varios
pasos o niveles que tendrá a lo largo del desarrollo nuestro programa.

El diseño de Software juega un papel importante en el desarrollo de software lo

cual permite al ingeniero de software producir varios modelos del sistema o
producto de que se va a construir el mismo que forman una especie de plan de
la solución de la aplicación. Estos modelos pueden evaluarse en relación con
su calidad y mejorarse antes de generar código, de realizar pruebas y de que
los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en
el que se establece la calidad del software es por ello que en este resumen
vamos a ver los conceptos y los principios del diseño de un software así como
los pasos o procesos a tomar en cuenta, pasando además por conceptos que
se manejan a la hora de diseñar un software.

15
2.2.5. Programación Web

Aunque los inicios de Internet se remontan a los años sesenta, no ha sido

hasta los años noventa cuando, gracias a la Web, se ha extendido su uso por
todo el mundo. En pocos años la Web ha evolucionado enormemente: se ha
pasado de páginas sencillas, con pocas imágenes y contenidos estáticos a
páginas complejas con contenidos dinámicos que provienen de bases de
datos, lo que permite la creación de "aplicaciones web". De forma breve, una
aplicación web se puede definir como una aplicación en la cual un usuario por
medio de un navegador realiza peticiones a una aplicación remota accesible a
través de Internet (o a través de una intranet) y que recibe una respuesta que
se muestra en el propio navegador. El contenido de este libro se estructura en
dos partes. En la primera parte del libro se tratan temas introductorios a la
programación de aplicaciones web: un breve repaso de la historia de Internet y
de la Web, características de las arquitecturas cliente/servidor, el concepto de
aplicación web y la estructura de un sitio web tanto a nivel físico como lógico.
La segunda parte del libro se centra en la programación de la parte cliente de
las aplicaciones web. En el "mundo Internet" existen muchas tecnologías que
se pueden emplear para programar los clientes web, como ActiveX, applet,
Flash, VRML, etc., pero sólo dos son las tecnologías más extendidas y se
pueden considerar "el estándar": HTML y Java Script. Este libro se centra en
esas dos tecnologías y presta una especial atención a la creación de
formularios, la base para cualquier aplicación web.

2.2.6. Sitio Web

Es un conjunto de archivos electrónicos y páginas Web referentes a un tema

en particular, que incluye una página inicial de bienvenida, generalmente
denominada home page, con un nombre de dominio y dirección en Internet
específicos, empleados por las instituciones públicas y privadas,
organizaciones e individuos para comunicarse con el mundo entero. En el caso
particular de las empresas, este mensaje tiene que ver con la oferta de sus
bienes y servicios a través de Internet, y en general para ser eficiente sus
funciones de mercadotecnia.

Su Sitio Web no necesariamente debe localizarse en el sistema de cómputo de

su negocio. Los documentos que integran el Sitio Web pueden ubicarse en un
equipo en otra localidad, inclusive en otro país. El único requisito es que el

16
 equipo en el que residan los documentos esté conectado a la red mundial de
Internet. Este equipo de cómputo o Servidor Web, como se le denomina
técnicamente, puede contener más de un sitio Web y atender
concurrentemente a los visitantes de cada uno de los diferentes sitios.

Al igual que los edificios, oficinas y casas, los Sitios Web requieren de una
dirección particular para que los usuarios puedan acceder a la información
contenida en ellos. Estas direcciones, o URLs (por sus siglas en inglés Uniform
Resource Locator), aparecen cotidianamente en todos los medios de
comunicación como son prensa escrita, radio, televisión, revistas,
publicaciones técnicas y en el propio Internet a través de los motores de
búsqueda (por su denominación en inglés searchengines).

Los nombres de estos sitios Web obedecen a un sistema mundial de

nomenclatura y están regidos por el ICANN (Internet Corporation for Assigned
Names and Numbers).

Los Sitios Web pueden ser de diversos géneros, destacando los sitios de
negocios, servicio, comercio electrónico en línea, imagen corporativa,
entretenimiento y sitios informativos.

2.2.7. El Lenguaje HTML

Este lenguaje estructura documentos. La mayoría de los documentos tienen

estructuras comunes (títulos, párrafos, listas…) que van a ser definidas por
este lenguaje mediante tags. Cualquier cosa que no sea un tag es parte del
documento mismo.

Este lenguaje no describe la apariencia del diseño de un documento sino que

ofrece a cada plataforma que le dé formato según capacidad y la de su
navegador (tamaño de la pantalla, fuentes que tiene instaladas...). Por ello y
para no frustrarnos, no debemos diseñar los documentos basándonos en como
lucen en nuestro navegador sino que debemos centrarnos en proporcionar un
contenido claro y bien estructurado que resulte fácil de leer y entender,

2.2.8. Plataforma J2EE

J2EE es un conjunto de especificaciones de APIs Java para la construcción de

aplicaciones empresariales

17
 o La mayor parte de las abstracciones de las APIs corresponden a
interfaces y clases abstractas.
o Existen múltiples implementaciones de distintos fabricantes, incluso
algunas OpenSource.
o Una aplicación construida con J2EE no depende de una implementación
particular.

La plataforma J2EE cuenta con las siguientes características:

o Escalabilidad
o Portabilidad
o Seguridad

¿Cómo se debe diseñar una aplicación empresarial para que sea mantenible y
contenga partes reusables?

o Debería estar diseñada siguiendo la arquitectura que fijan los patrones

arquitectónicos Model-View-Controller (MVC).
o Un patrón arquitectónico es un patrón de alto nivel que fija la arquitectura
global de una aplicación.
o Posteriormente, el diseño hará uso de patrones de diseño para resolver
problemas específicos.

En el patrón arquitectónico MVC existe una separación clara entre el modelo

(lógica de negocio) y la vista (interfaz gráfica), gracias a un controlador que los
mantiene independientes unos de otros (desacoplados). Ventajas:

o • El modelo es reusable con distintas vistas (ej.: una vista web y una con
interfaz de ventanas)
o • División clara de trabajo entre los miembros de un equipo, que estará
formado por personas con distintos niveles de especialización

2.2.9. CSS

Según (Eguíluz Pérez, CSS Avanzado, 2009) indica que “CSS es un lenguaje
de hojas de estilos creado para controlar el aspecto o presentación de los
documentos electrónicos definidos con HTML y XHTML. CSS es la mejor forma
de separar los contenidos y su presentación y es imprescindible para crear
páginas web complejas”.

18
2.2.10. AJAX

Según (Eguíluz Pérez, Introducción a AJAX, 2008) indica que “AJAX es un

acrónimo de Asynchronous JavaScript + XML, que se puede traducir como
"JavaScript asíncrono + XML.

“Ajax no es una tecnología en sí mismo. En realidad, se trata de varias

tecnologías independientes que se unen de formas nuevas y sorprendentes.”

Las tecnologías que forman AJAX son:

o XHTML y CSS, para crear una presentación basada en estándares.

o DOM, para la interacción y manipulación dinámica de la presentación.
o XML, XSLT y JSON, para el intercambio y la manipulación de
información.
o XML Http Request, para el intercambio asíncrono de información.
o JavaScript, para unir todas las demás tecnologías.

2.2.11. Apache Web Server

Es un servidor web libre, es decir, el encargado de construir y devolver las

páginas web que solicitan los navegadores. Su nombre procede de “a patchy
server” por ser una versión “parcheada” en 1995 de uno de los primeros
servidores web, el NCSA HTTPD, y actualmente corre en muy diversas
plataformas (Unix, Windows, etc.). Debido a su licencia libre pero ni copyleft,
existe también versiones propietarias de Apache, aunque es desarrollado y
mantenido por la comunidad del software libre a través de la fundación Apache.

2.2.12. Concepto de Control de Gestión

Pese a que el control de gestión no es una herramienta nueva, recién en los

últimos años ha alcanzado un sitial especial en el mundo de los negocios. No
obstante lo anterior, todavía existe poco conocimiento en relación a qué es
realmente el control de gestión y la utilidad que éste tiene para la dirección de
empresas, por lo que son muchos los mitos, imprecisiones y errores que han
contribuido a desvirtuar su real significado.

19
 En primer lugar, se puede mencionar la idea generalizada de creer que el
control de gestión es sólo un sistema de control, sin embargo, su significado
esencial no se ajusta a este concepto, básicamente, porque controlar significa
evaluar resultados con posterioridad a su ocurrencia (ex post) con el propósito
de analizar si se cumplió o no el objetivo deseado. Aunque es indiscutible la
necesidad de evaluar la realidad versus un estándar definido, resulta
claramente ineficiente centrar la atención de los directivos en resultados que ya
se lograron y que no se pueden revertir. Todo lo contrario, el control de gestión
busca influir en resultados futuros de manera de aumentar la probabilidad de
que éstos ocurran. Dicho de otra manera, el control de gestión es un sistema
de dirección que busca impactar el futuro de la organización y no controlar su
pasado.

En segundo lugar, otro mito ampliamente difundido se relaciona con la idea de

pensar el control de gestión como la construcción y el seguimiento aislado de
un conjunto de indicadores de carácter financiero y no financiero. Si bien los
indicadores o métricas que permiten precisar los objetivos son elementos
fundamentales en un sistema de este tipo, el control de la gestión utiliza los
indicadores como expresiones cuantitativas que permiten analizar qué tan bien
se está ejecutando la estrategia. Hablar de control de gestión es hablar de un
sistema integrado y coherente de información que permite tener una visión
global del desempeño de la empresa que facilite y apoye la toma de decisiones
de dirección estratégica.

Por último, el control de gestión tampoco está orientado a los niveles directivos
máximos de una organización. Si bien, un buen sistema de control de gestión
parte en los niveles superiores necesariamente debe bajar a los niveles
inferiores a través de un proceso de desdoblamiento o despliegue. Sólo así es
posible alinear a la compañía en relación a sus objetivos fundamentales y
definir cursos de acción que potencien las fortalezas y neutralicen las
debilidades. En otras palabras, cada unidad de negocios, área y/o
departamento debe tener su propio control de gestión sobre los objetivos
estratégicos que les conciernen.

2.2.13. Metodología de desarrollo de software

Desde que el desarrollo de aplicaciones informáticas se considerara un

proceso de ingeniería, muchas metodologías de desarrollo han ido naciendo

20
 con el fin de dar soporte al ciclo de desarrollo del proyecto. Entre estas,
podemos destacar algunas como Cascada (1956), Métrica (1980), Merisse
(1972), Espiral (1986) y ya más recientes como el Proceso Racional Unificado
(1995).Al principio estas metodologías estaban orientadas al desarrollo de
aplicaciones que gestionaran información guardada en las bases de datos, por
tanto estas se preocupaban del almacenamiento y la recuperación adecuada
de datos.

El término de aplicación multimedia surgió con la evolución de la tecnología,

estas aplicaciones tienen como objetivo difundir información a través de
medios multimedia como, video, sonido, imágenes, etc. A partir de 1993
surgieron nuevas propuestas metodológicas, para afrontar a la problemática de
estas aplicaciones: HDM (Garzoto 1993), RMM (Isakowitz 1995), RUP (IBM
1995), etc.

UML basado en Ingeniería Web

UWE (UML-Based Web Engineering) es una propuesta basada en UML y en el

Proceso Unificado Racional para modelar aplicaciones web. Los sistemas
adaptativos y la sistematización son dos aspectos sobre los que se enfoca
UWE. Otras características relevantes del proceso y método de autoría de
UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la
definición de un meta modelo (modelo de referencia) que da soporte al método
y el grado de formalismo que alcanza debido al soporte que proporciona para
la definición de restricciones sobre los modelos.

UWE, no separa el análisis y el diseño e incluyen estos modelos en la fase de

análisis-diseño1.

UWE propone al menos un tipo de diagrama UML para la visualización de

dichos modelos buscando representar los aspectos estructurales de las
diversas vistas .Se puede decir que se realiza una separación considerando
etapas de desarrollo, vistas del sistema y aspectos como la estructura y el
comportamiento. Este tipo de separación provee ventajas a la hora de realizar
mantenimientos y reingenierías de sistemas web, y también en la generación
de sistemas Web para distintos contextos y plataformas.

1
Escalona Cuaresma MJ. Modelos y técnicas para la especificacióny el análisis de la navegación en sistemas
software.[Tesis Doctoral]. España: Universidad de Sevilla; 2004.

21
 El modelo que propone UML basado en Ingeniería Web está compuesto por
cinco modelos principales, cabe mencionar que el número de modelos variará
con la versión de UWE. Véase Gráfico N° 2.1.

Figura N° 2.1. Modelos que comprende UWE.

1. Modelado de • Fija los requisitos funcionales de

Requerimientos la aplicación para reflejarlos en
un modelo de casos de uso.

2. Modelo de • Incluye los objetos implicados en

Contenido las actividades de la aplicacion.

3. Modelo de • Especifica que objetos serán

Navegación visitados por el navegador a
través de la aplicación.

4.Modelo de • Se divide en dos partes:

Procesos •Modelo de Estructura de
Procesos
•Modelo de Flujo de Procesos.
5.Modelo de • Representa las vistas del interfaz.
Presentación

Fuente: Página oficial. [Disponible en: http://uwe.pst.ifi.lmu].

Elaborado por: El Investigador

UML-Based Web Engineering, es una extensión de UML muy poderosa para el

diseño de Aplicaciones Web, provee una serie de herramientas tanto para
diseño y modelado. Es una propuesta que en los últimos años ha conseguido
gran aceptación en los foros de investigación. Sus modelos basados
totalmente en UML están siendo muy bien valorados. Además, es una
propuesta viva.

2.2.14. Metodología Rational Unified Process® (RUP) o Proceso Racional

Unificado

El Proceso Racional Unificado es un producto de Rational (IBM). Es un

proceso de desarrollo de software que se caracteriza por ser iterativo e
incremental, y por estar centrado en la arquitectura y guiado por los casos de
uso. RUP es un proceso de desarrollo de software genérico, sin embargo se
concibió principalmente para el desarrollo de sistemas basados en
programación orientada a objetos.

22
RUP se basa en la asignación de tareas y responsabilidades dentro de una
organización de desarrollo, cubre todo el ciclo de vida de desarrollo y asegura
que el software que se produzca sea de alta calidad. RUP puede ser adaptado
y extendido para satisfacer las necesidades de una organización.

Muchas de las mejores prácticas de desarrollo están incluidas dentro de este

modelo de desarrollo de software; entre ellas destacan las siguientes:

 Desarrolla el software de manera iterativa.

 Maneja requerimientos.
 Utiliza arquitecturas basadas en componentes.
 Modela el software de manera visual.
 Verifica la calidad del software.
 Controla los cambios del software.

El proceso puede ser descrito en dos dimensiones o a lo largo de dos ejes,

como se muestra en la Figura N° 2.1.

Figura 2.2. Estructura de RUP

Fuente: [Wikipedia, 2006b]

 El Eje Horizontal representa el tiempo y muestra los aspectos dinámicos

del proceso a medida que éste se desarrolla. Es expresado en términos
de ciclos, fases, iteraciones e hitos.

23
  El Eje Vertical representa el aspecto estático del proceso: cómo es
descrito en términos de actividades, artefactos, trabajadores y flujos de
trabajo.

Estructura Estática del Proceso

El proceso que describe RUP es representado utilizando cuatro elementos de

modelaje primario: Trabajadores, Actividades, Artefactos y Flujos de Trabajo.

 Trabajador: Define el comportamiento y responsabilidades de un

individuo o de un grupo de personas que trabajan en un equipo.
 Actividad: Es una unidad de trabajo que un individuo debe realizar.
 Artefacto: Es una pieza de información que es producido, modificado o
utilizado por un proceso.
 Flujo de Trabajo: Es una secuencia de actividades.

Estructura Dinámica del Proceso: Desarrollo Iterativo

El ciclo de vida del software se divide en ciclos, Cada ciclo concluye con una
generación del producto para los clientes. RUP divide cada ciclo de desarrollo
en cuatro fases consecutivas: Inicio, Elaboración, Construcción y Transición.
Estas fases a su vez se dividen en iteraciones.

Cada fase concluye con un hito bien definido, un punto en el tiempo en el cual
se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de
pasar a la siguiente fase.

A continuación, se describen brevemente cada una de las fases:

 Inicio: Durante esta fase se define el modelo del negocio y el alcance del
proyecto. Se identifican todos los actores y Casos de Uso y se delimita el
alcance del proyecto.
 Elaboración: El propósitos de esta fase es analizar el dominio del
problema, así como establecer una base de arquitectura sólida, desarrollar
el plan del proyecto y eliminar los mayores elementos de riesgo. En esta
fase se construye un prototipo de la arquitectura, que debe evolucionar en
iteraciones sucesivas hasta convertirse en el sistema final.

24
 Construcción: Durante esta fase se debe alcanzar la capacidad
operacional del producto; se implementan e integran todas las
características y requisitos, además de realizar las pruebas
necesarias para verificar que la versión del producto sea aceptable.
 Transición: En esta fase se entrega el producto a los usuarios finales.
Incluye actividades como: envío, entrenamiento, soporte y mantenimiento
del producto. En la figura Nº 2.2, se muestra el desarrollo de estas fases a
través del tiempo.
Figura 2.3. Fases e Hitos en RUP

Fuente: [Wikipedia, 2006b]

El Proceso Unificado de Rational, es un proceso de ingeniería de software que

proporciona un acercamiento disciplinado a la asignación de tareas y
responsabilidades en la agencia de desarrollo.

Su propósito es asegurar la producción de software de alta calidad que se

ajuste a las necesidades de los usuarios finales.

En definitiva el RUP es una metodología de desarrollo de software que intenta

integrar todos los aspectos a tener en cuenta durante todo el ciclo de vida del
software, con el objetivo de hacer abarcables tanto pequeños como grandes
proyectos software. Los tres principios básicos de RUP son:

o Dirigido por casos de uso

La razón de ser de un sistema software es servir a usuarios ya sean

humanos u otros sistemas, un caso de uso es una facilidad que el software
debe proveer a sus usuarios. Los casos de uso reemplazan la antigua
especificación funcional y constituyen la guía fundamental establecida para
las actividades a realizar durante todo el proceso de desarrollo incluyendo
el diseño, la implementación y las pruebas del sistema. Los casos de uso
dirigen y controlan el proceso de desarrollo en su totalidad.

25
 Figura N° 2.4. Diagrama de Representación del ejemplo.

Fuente: El Investigador
Elaborado por: El Investigador

o Centrado en la arquitectura

Arquitectura de un sistema es la organización o estructura de sus partes

más relevantes y constituye la pieza clave que permite comprender el
sistema, organizar el desarrollo y hacer evolucionar el software.

La arquitectura involucra los elementos más significativos del sistema y

está influenciada entre otros por plataformas software, sistemas operativos,
manejadores de bases de datos, protocolos, consideraciones de desarrollo
como sistemas heredados y requerimientos no funcionales.

Es como una radiografía del sistema que estamos desarrollando, lo

suficientemente completa como para que todos los implicados en el
desarrollo tengan una idea clara de que es lo que están construyendo, pero
lo suficientemente simple como para que si quitamos algo, una parte
importante del sistema quede sin especificar.

Una arquitectura ejecutable es una implementación parcial del sistema,

construida para demostrar algunas funciones y propiedades.

RUP establece refinamientos sucesivos de una arquitectura ejecutable,

construida como un prototipo evolutivo.

26
 o Proceso iterativo e incremental

Para hacer más manejable un proyecto se recomienda dividirlo en ciclos,

para cada ciclo se establecen fases de referencia, cada una de las cuales
debe ser considerada como un mini proyecto cuyo núcleo fundamental está
constituido por una o más iteraciones de las actividades principales básicas
de cualquier proceso de desarrollo.

El desarrollo se plantea de manera progresiva, de tal modo que se atenúen

los riesgos y se planteen las cuestiones en el instante en que se está
capacitado para resolverlas.

Cada etapa de RUP itera sobre 5 flujos de trabajo que son:

 Requisitos

Averiguar lo que el sistema debe hacer.

 Análisis

Conseguir una comprensión más precisa de los requisitos.

 Diseño

Comprensión de los requisitos no funcionales y adaptación de los

requisitos funcionales para su implementación.

 Implementación

Implementación de clases y pruebas de componentes individuales.

 Pruebas

Planificar, diseñar y realizar las pruebas de integración y de sistemas.

2.3. MODELO APLICADO

Las aplicaciones web son un caso especial del desarrollo de software. El modelo de
aplicación que se propone para el presente proyecto está basado en la metodología
de Proceso Racional Unificado (RUP) con su Lenguaje de Unificado de Moldeamiento
orientado al desarrollo de aplicaciones en web, basada en la extensión de UML
(UWE). Actualmente las aplicaciones de internet presentan complejidad creciente.

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al
equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con

27
el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso
iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini
proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya
logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada
mini proyecto se puede ver como una iteración (un recorrido más o menos completo a
lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un
incremento que produce un crecimiento en el producto.

Una iteración puede realizarse por medio de una cascada de etapas como se muestra
en la Figura 6. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,
Implementación y Pruebas), también existe una planificación de la iteración, un
análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se
realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

Figura N° 2.5. Iteracion RUP.

Fuente: El Investigador
Elaborado por: El Investigador

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada

iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando
termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los
existentes, afectando a las iteraciones siguientes. Durante la planificación de los
detalles de la siguiente iteración, el equipo también examina cómo afectarán los
riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración
pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con

28
esta dinámica hasta que se haya finalizado por completo con la versión actual del
producto.

Requerimientos

Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer
(Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario,
realizar una estimación del costo y tiempo de desarrollo. Utiliza el Modelo de Casos de
Uso para modelar el Sistema que comprenden los Casos de Uso, Actores y
Relaciones, además utiliza los diagramas de Estados de cada Casos de Uso y las
especificaciones suplementarias.

Análisis y diseño

Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar
requisitos en especificaciones de implementación, al decir análisis se refiere a
transformar Casos de Uso en clases, y al decir diseño se refiere a refinar el análisis
para poder implementar los diagramas de clases de análisis de cada Casos de Uso,
los diagramas de colaboración de cada Casos de Uso, el de clases de diseño de cada
Casos de Uso, el de secuencia de diseño de Casos de Uso, el de estados de las
clases, el modelo de despliegue de la arquitectura.

Implementación

Esta disciplina tiene como objetivos implementar las clases de diseño como
componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los
componentes individualmente, integrar los componentes en un sistema ejecutable
(enfoque incremental). Utiliza el Modelo de Implementación, conjuntamente los
Diagramas de Componentes para comprender cómo se organizan los Componentes y
dependen unos de otros.

Pruebas

Esta disciplina tiene como objetivos verificar la integración de los componentes

(prueba de integración), verificar que todos los requisitos han sido implementados
(pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes
de la distribución

29
2.4. MARCO CONCEPTUAL

Tecnología Web: Es una tecnología que utiliza todas las tecnologías de inter
conectividad de ordenadores que permite a los usuarios el intercambio, en formato de
hipertexto, de todo tipo de datos e información (Texto, imágenes, sonidos) y de
aplicaciones de software.

Integración de datos: Es el proceso de combinar datos que residen en diferentes

fuentes y permitirle al usuario final tener una vista unificada de todos sus datos. La
habilidad de transformar datos inter-departamentales de fuentes heterogéneas en un
plan de acción que se convertido en un reto y en una ventaja competitiva para
compañías que requieran la integración de datos

Telefonía Móvil: Es actualmente el medio de comunicación interpersonal más

utilizado en el mundo junto al World Wide Web. Los medios de financiación del
servicio de telefonía móvil son principalmente dos: la tarjeta prepago y el contrato.

Prepago: La tarjeta prepago nos da derecho a adquirir un número de teléfono y hacer

uso del servicio. La financiación, como bien indica el nombre, se realiza antes del
disfrute del servicio. Se recarga el saldo de la tarjeta con una determinada cantidad
económica, y el usuario puede disfrutar del servicio hasta que se agote lo que
inicialmente ha invertido.

Postpago: En el contrato de telefonía móvil la financiación es postpago, es decir, el

usuario abona cada mes la cantidad económica equivalente al uso exacto que ha
tenido durante todo este periodo. En postpago tienes la opción de varias tarifas a
elegir según el uso que le des al celular (móvil) puedes optar por planes en segundo o
minutos.

Smartphone: Un teléfono inteligente es un teléfono móvil construido sobre una

plataforma informática móvil, con una mayor capacidad de almacenar datos y realizar
actividades semejantes a una minicomputadora y conectividad que un teléfono móvil
convencional.

Servidor Web: Programa que se ejecuta continuamente en una computadora

(también se emplea el término para referirse a la computadora que lo ejecuta),
manteniéndose a la espera de peticiones por parte de un cliente (un navegador Web)
y que responde a estas peticiones mediante una página Web que se exhibirá en el
navegador o mostrando el respectivo mensaje si se detecta algún error.

30
 Sistema de Información: Conjunto de elementos que interactúan entre sí con el fin
de apoyar las actividades de una empresa, negocio o institución. Un sistema de
información realiza cuatro actividades básicas: entrada, almacenamiento,
procesamiento y salida de información.

XHTML: Siglas del inglés eXtensible Hyper Text Markup Language, es básicamente
HTML expresado como XML válido.

XMI: XML de Intercambio de Metadatos. Su principal objetivo es permitir un

intercambio de metadatos entre herramientas de modelado basadas en UML,
repositorios de metadatos, basados en MOF en distintos entornos distribuidos.

XML: Metalenguaje de marcado que permite la definición de etiquetas y el intercambio

de datos a través de la red. Permite que un documento pueda usar separa una gran
variedad de propósitos, facilita el desarrollo de aplicaciones para navegar por internet,
buscadores, y el intercambio de datos entre bases de datos.

Estadígrafo: Es un valor numérico que se obtiene a partir de datos muéstrales.

Describe alguna característica de la muestra, y la toma de decisiones respecto a la
población contiene cierto grado de incertidumbre.

Teniendo las investigaciones y proyectos realizados anteriormente, conociendo la

metodología, las herramientas y los pasos a seguir se proceden a aplicar dichos
conocimientos para la obtención de resultados que servirán en el mejoramiento de los
procesos de la agencia de ventas.

31
 CAPÍTULO III
INTERVENCION METODOLOGICA
En el capítulo III mostraremos el desarrollo del diseño, el empleó del Lenguaje Unificado de
Modelamientos (UML), basándose en la metodología RUP, explicando los procesos. Por
otro lado vale la pena investigar y entender el enfoque UML por su gran aceptación,
considerando que brinda un conjunto estandarizado de herramientas de UML incluye
diagramas que permite a las personas visualizar la construcción de un sistema orientado a
objetos.

3.

3.1. CAPTURA DE REQUISITOS

A continuación se presentarán los productos elaborados durante la fase de

concepción siguiendo los lineamientos establecidos en la metodología de desarrollo
RUP.

3.1.1. Modelado del negocio

Esta disciplina tiene como objetivos comprender la estructura y la dinámica de

la organización, comprender problemas actuales e identificar posibles mejoras,
comprender los procesos de negocio. Utiliza el Modelo de Caso de Uso del
Negocio para describir los procesos del negocio y los clientes, el Modelo de
Objetos del Negocio para describir cada Caso de Uso del Negocio con los
Trabajadores, además utilizan los Diagramas de Actividad y de Clases.

32
3.1.2. Requerimientos

Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer
(Especificar Requisitos), definir los límites del sistema, y una interfaz de
usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el
Modelo de CU para modelar el Sistema que comprenden los Casos de Uso,
Actores y Relaciones, además utiliza los diagramas de Estados de cada Caso
de Uso y las especificaciones suplementarias.

Los principales objetivos de esta disciplina son:

 Definir el ámbito del sistema.

 Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
 Tener un mejor entendimiento de los requerimientos del sistema.
 Tener una base para estimar recursos y tiempo de desarrollo del sistema.

Los requerimientos serán divididos en dos grupos: Los funcionales, que

describirán las funciones que el software va a ejecutar; y los no funcionales,
que especificarán criterios que pueden usarse para juzgar la operación de un
sistema en lugar de sus funciones específicas.

3.1.2.1. Requerimientos Funcionales

Los requerimientos funcionales ofrecen una descripción detallada del

comportamiento de la aplicación y de las necesidades del sistema así
como soluciones a posibles situaciones adversas o anómalas tales
como datos inválidos, errores, fallos del sistema entre otras. Por lo
tanto, para poder realizar correctamente el proyecto en cuestión
debemos asegurarnos que tenemos claros todos los requerimientos a
cumplir. En el siguiente listado veremos qué requisitos mínimos debe
cumplir nuestra aplicación.

Módulo de Personal

Evidentes para todos los tipos de usuarios.

33
R-1. El sistema permitirá la creación, modificación e inactivación de
usuarios y roles para tener diferentes niveles de acceso al
sistema.
R-2. El sistema debe permitir administrar las autorizaciones para la
ejecución de las acciones del sistema dependiendo del rol de
cada usuario.
R-3. El sistema debe permitir el ingreso a través de un formulario
para la identificación de los usuarios.
R-4. El sistema debe permitir visualizar la lista del personal de la
empresa.
R-5. El sistema debe permitir las ventas personales de cada
empleado.

Módulo de Almacén

Evidentes para todos los tipos de usuarios.

R-6. El sistema debe permitir registrar e ingresar los productos

nuevos a la agencia como las tarjetas SIM y equipos.
R-7. El sistema permitirá la modificación de los datos de los
productos.
R-8. El sistema permitirá mostrar la información actualizada de los
productos existentes y disponibles de los productos.
R-9. El sistema debe permitir realizar búsquedas de artículos por
coincidencia, por series.
R-10. Sección para el ingreso de productos por artículos, series y
otros datos.
R-11. El sistema debe permitir generar un inventario por artículos y
series.
R-12. El sistema debe permitir la actualización continua de
contenidos.

Módulo de Ventas

Evidentes para todos los tipos de usuarios.

R-13. El sistema permitirá registrar los datos del cliente.

34
R-14. El sistema debe permitir hacer ventas según el tipo: Prepago,
Postpago, Fijo e internet y otros.
R-15. El sistema debe permitir la actualización continua de
contenidos, es decir, se debe poder introducir, modificar y
eliminar elementos de las bases de datos.
R-16. El sistema debe guardar las cantidades de artículos vendidas y
los precios a los que fueron vendidas.
R-17. El sistema debe permitir hacer consultas.
R-18. El sistema debe validar los campos de los formularios, para
campos numéricos como cantidad sólo debe permitir introducir
números, para campos con números decimales.
R-19. El sistema debe validar los campos de los formularios antes de
su envío.
R-20. El sistema debe permitir la actualización continua de
contenidos.
R-21. Sección de activación que visualiza información necesaria:
nombre, dirección, teléfono de referencia y otros del cliente,
además de tipo de plan y tipo de ventas.
R-22. Sección de activación en los diferentes tipos, planes y otros.
R-23. Sección de activación para modificar el campo de número
telefónico.

Módulo de Caja

Evidentes para todos los tipos de usuarios.

R-24. El sistema debe permitir realizar pagos de las ventas

realizadas.
R-25. Sección para generar guías de remisión de las ventas
realizadas.
R-26. Sección para generar reporte de los movimientos diarios.
R-27. Sección para generar reporte de ingresos y egresos mensual.
R-28. El sistema debe guardar las cantidades de artículos vendidas y
los precios a los que fueron vendidas.

35
 3.1.2.2. Requerimientos No Funcionales

Los requerimientos no funcionales tienen que ver con características

que de una u otra forma puedan limitar el sistema. Estos
requerimientos se basan en restricciones impuestas por los usuarios
o bien surgidas por sucesos previstos improvistos y que afectan al
diseño final. Normalmente son cuantificables. Algunos ejemplos son,
el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad,
mantenimiento, seguridad, portabilidad, estándares, etc.

El sistema de control y gestión debe satisfacer los siguientes

requerimientos suplementarios: usabilidad, fiabilidad, desempeño y
mantenibilidad. Cada uno de estos requerimientos impacta la toma de
cualquier decisión sobre la arquitectura del sistema.

Todo sistema debe ser capaz de aceptar modificaciones sin que esto
afecte la operabilidad del mismo, lo cual se garantiza diseñando un
sistema en componentes.

3.1.2.2.1. Requerimientos de Equipos

 Se deberá contar con un servidor de internet que permita la
conexión de múltiples usuarios.
 Para que un encuestador pueda acceder a una encuesta debe
tener una conexión a Internet a través de un punto con acceso a
internet.

3.1.2.2.2. Disponibilidad
 El Sistema debe estar disponible cuando el usuario desee
acceder al sistema.

3.1.3. Actores del sistema

Los actores del sistema son las personas que interactúan con el software. Se
ha identificado los siguientes usuarios:

Administrador o Administrativo.

36
 Almacenero.

Vendedores.

Activador.

Personal de Caja.

3.1.4. Diagramas de Caso de Uso

El diagrama de caso de uso es el conjunto de los modelos de interacción entre

los usuarios externos de un sistema (actores) y el sistema mismo. Se han
identificado los siguientes casos de uso generales:

Gestionar proceso de acceso al personal

Gestionar procesos de almacén.

Gestionar procesos de activación.

Gestionar proceso de ventas.

3.2. ANALISIS

Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar
requisitos en especificaciones de implementación, al decir análisis se refiere a
transformar Caso de Uso en clases, y al decir diseño se refiere a refinar el análisis
para poder implementar los diagramas de clases de análisis de cada Caso de Uso, los
diagramas de colaboración de cada Caso de Uso, el de clases de diseño de cada
Caso de Uso, el de secuencia de diseño de Caso de Uso, el de estados de las clases,
el modelo de despliegue de la arquitectura.

3.2.1. Modelo de Casos de Uso del Negocio

Este diagrama representa la funcionalidad completa de un sistema (o una

clase) mostrando su interacción con los agentes externos. Esta representación
se hace a través de las relaciones entre los actores (agentes externos) y los
casos de uso (acciones) dentro del sistema. Los diagramas de casos de uso

37
definen conjuntos de funcionalidades afines que el sistema debe cumplir para
satisfacer todos los requerimientos que tiene a su cargo. Esos conjuntos de
funcionalidades son representados por los casos de uso. Se pueden visualizar
como las funciones más importantes que la aplicación puede realizar o como
las opciones presentes en el menú de la aplicación.

3.2.1.1. Realización de Casos de Uso del Negocio

Un modelo de Objetos del Negocio es un modelo interno a un negocio

y describe como cada caso de uso es llevado a cabo por parte de un
conjunto de trabajadores que utilizan un conjunto de entidades del
negocio y de unidades de trabajo. Los modelos de objetos del negocio
están asociados a cada uno de los casos de uso del negocio descritos
anteriormente.

Figura N° 3.1. Diagrama General de Responsables

Administrador

Responsable de
Sistemas
Almacen

Encargado de
Almacen
Activacion

Responsable de
Activar
Ventas

Personal de Ventas
Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.
Caja

Responsable de
Caja
Control
Economico

Responsable de
Control Economico 38
 Describe la dependencia de las áreas de la empresa.

Actor 01 Responsable de Sistemas – Administrador

Descripción Encargado del sistema.
Se encargan de crear, modificar y eliminar los
Comentarios usuarios de los trabajadores.
Se encarga del Manejo y mantenimiento del sistema.

Actor 02 Responsable de Almacén

Descripción Representa al encargado de almacén.
Comentarios Se encargan del control del almacén.

Actor 03 Responsable de Activación

Descripción Representa al personal del área de activación.
Comentarios Se encargan de la activación de equipos y / tarjetas
SIM en el sistema del operador.

Actor 04 Responsable de Ventas

Descripción Representa al personal de ventas.
Comentarios Se encargan del ingreso de las ventas
Se encarga de los documentos del cliente.

a. Caso Uso del Módulo de Personal

Figura N° 3.2. Diagrama de Caso de Uso Módulo Personal

Crea usuario,
contraseña y correo Solicita datos personales

Administrador Envia datos

Usuario

Envia Usuario y contraseña

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

39
 Actor 01 Responsable de Sistemas – Administrador
Descripción Encargado del sistema.
Se encargan de crear, modificar y eliminar los
usuarios de los trabajadores.
Comentarios
Se encarga del Manejo y mantenimiento del
sistema.

Actor 02 Usuario- Trabajadores del negocio

Descripción Trabajadores del negocio.
Se encargan de las funciones que les
Comentarios
corresponda de acuerdo a su área.

b. Caso Uso del Módulo de Almacén – Ingreso

Figura N° 3.3. Diagrama de Caso de Uso Módulo Almacén
Ingreso de Equipos

Recepcion y revision de equipos

Envio de equipos disponibles

Ingreso de equipos al sistema

Envio de pedidos de Equipos
Telefonica Almacen

Ingresar al stock de equipos

Envio de Equipos segun pedido

Revisa el pedido

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

Actor 01 Almacén
Descripción Encargado de realizar los pedidos de abastecimiento.
Realiza los pedidos de equipos dependiendo del stock
Comentarios disponible e ingresa las series al sistema.
Ingresa las series de los equipos al sistema.

40
 Actor 02 Empresa de Telefonía
Descripción Encargado de realizar los pedidos de abastecimiento.
Comentarios Envía información de equipos nuevos y disponibles.

c. Caso Uso del Módulo de Almacén – Funciones

Figura N° 3.4. Diagrama de Caso de Uso Módulo Almacén
Funciones

Ingresa series de los

equipos al sistema

Verificar las series

de los equipos

Almacen
Realizar stock
de los equipos

Generar inventarios

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

Actor 01 Almacén
Descripción Encargado de realizar las funciones del área.
Ingresa las series de los equipos y tarjetas al sistema.
Verifica las series al momento de recepcionar equipos.
Comentarios
Realiza stock de equipos todos los días.
Realiza inventarios de los equipos cada mes.

41
 d. Caso Uso del Módulo de Activación
Figura N° 3.5. Diagrama de Caso de Uso Módulo Activación

Envia pedido

Realiza activacion
del pedido
Vendedor Activador

Ingresar series

Envia series
Solicita series del pedido
de equipos
Almacen

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

Actor 01 Activador
Descripción Responsable de activar el pedido.
Se encargan de activar los equipos y tarjetas SIM, e
Comentarios
ingresar el número que corresponde en el sistema.

Actor 01 Vendedor
Descripción Responsable de generar y enviar las ventas.
Se encargan de crear, modificar y enviar las ventas
Comentarios
y/o pedidos.

Actor 03 Almacén
Descripción Responsable de los equipos y tarjetas SIM.
Se encargan de enviar las series de los equipos y
Comentarios
tarjetas SIM.

e. Caso Uso del Módulo de Ventas – Postpago

En caso de Ventas de tipo Postpago en el Caso de uso se agrega

una área que es Control Económico quien se encarga de validar
los documentos que necesita el cliente para ser aprobado, de no

42
 estar conforme informa al vendedor que al cliente no califica para
optar otro tipo de plan.

Figura N° 3.7. Diagrama de Caso de Uso Módulo Ventas - Postpago

Solicita datos
de equipos Entrega documentos Revisa conformidad
Control Economico
de Documentos

Envia datos estado

de documentos

Cliente / Vendedor
Realiza su pedido
Pto de Venta
Envia pedido

Informa monto
de pago

Envia monto Realiza activacion

Activador
Realiza el pago Envia monto del pedido del pedido
del pedido

Entrega Comprobante Solicita series

de pago de equipos

Caja Envia series

del pedido

Recoge pedidos con Almacen

comprobante de pago
Entrega equipos
del pedido

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

Actor 01 Cliente
Descripción Son clientes que realizan compras al por mayor.
Comentarios Realizan pedidos al por mayor.

Actor 02 Vendedor
Descripción Trabajadores del área de ventas.
Comentarios Se encargan de realizar las ventas de los clientes.

Actor 03 Almacén
Se encarga del ingreso y control de equipos y
Descripción
tarjetas SIM.
Comentarios Se encargan de escanear e ingresa las series.

43
 Actor 04 Activador
Descripción Responsable de activar equipos y tarjetas SIM.
Comentarios Se encargan de activar las series.

Actor 05 Caja
Descripción Responsable de Caja
Se encargan de realizar los cobros de pago de los
Comentarios
pedidos.

Actor 06 Control Económico

Descripción Responsable de Control Económico.
Comentarios Se encargan de revisar los documentos del cliente.

f. Caso Uso del Módulo de Ventas – Prepago

En el caso de ventas de tipo Prepago no hace falta de presentar

documentos como los que son necesarios en el plan postpago,
por ese motivo no hay necesidad de entrar en contacto con el
área de Control Económico.

Figura N° 3.7. Diagrama de Caso de Uso Módulo Ventas - Prepago

Solicita datos
de equipos

Envia datos
Vendedor

Envia pedido
Cliente / Realiza su pedido
Pto de Venta
Realiza activacion
del pedido
Envia monto
Informa monto del pedido
de pago Envia monto
Realiza pago
del pedido
Activador

Solicita series
Emite Comprobante de equipos
de Pago Caja
Revisa el pedido
en sus opciones

Envia series
Recoge pedidos con del pedido
comprobante de pago
Almacen

Entrega equipos
del pedido

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

44
 Actor 01 Cliente
Descripción Son clientes que realizan compras al por mayor.
Comentarios Realizan pedidos al por mayor.

Actor 02 Vendedor
Descripción Trabajadores del área de ventas.
Comentarios Se encargan de realizar las ventas de los clientes.

Actor 03 Almacén
Se encarga del ingreso y control de equipos y
Descripción
tarjetas SIM.
Comentarios Se encargan de escanear e ingresar las series.

Actor 04 Activador
Descripción Responsable de activar equipos y tarjetas SIM.
Comentarios Se encargan de activar las series.

Actor 05 Caja
Descripción Responsable de Caja
Se encargan de realizar los cobros de pago de los
Comentarios
pedidos.

45
 3.2.2. Análisis de Riesgos
3.2.2.1. Análisis de la situación actual

Cuadro N° 3.1.: Riesgos

RIESGOS
Plan de

Impacto
Enunciado del Probabilidad Plan de Respon
Mitigació

*
Riesgo Ocurrencia Contingencia sable
n
Evento:

Los usuarios no
Informar a

El Desarrollador
tienen información de Incentivar el
los
las ventas. Alta 4 uso del portal
usuarios
web.
Consecuencia: las ventas.

Desinformación para
las áreas.
Evento:

El control de los Brindar Demostrar las

productos es informació ventajas que

El Desarrollador
importante para el n de los nos otorga el
proceso de venta. Menor 2 productos sistema web
a las como un gestor
Consecuencia:
demás de control de
El proceso de control áreas. información.
y presentación se
vuelve más largo.
Fuente: El Investigador
Elaborado por: El Investigador

*Impacto.

 4 Severo.
 3 Catastrófico
 2 Sostenible
 1 Menor
3.3. DISEÑO

El diseño es un refinamiento que toma en cuenta los requerimientos no funcionales,

por lo cual se centra en como el sistema cumple sus objetivos.

Los principales objetivos en esta disciplina son:

46
  Adaptar el diseño para que sea consistente con el entorno de implementación.
 Desarrollar una arquitectura para el sistema.
 Transformar los requerimientos al diseño del futuro sistema.

Al principio de la fase de elaboración hay que definir una arquitectura candidata: crear
un esquema inicial de la arquitectura del sistema, identificar clases de análisis y
actualizar las realizaciones de los Casos de Uso con las interacciones de las clases
de análisis.

3.3.1. Diagrama de Clase

Los diagramas de clases son una vista arquitectónica del sistema que permiten
describir las características estáticas de los objetos y las interrelaciones que se
dan entre estos.

Las clases que hacen parte del diagrama de clases son las clases entidad las
cuales representan, los aspectos más permanentes de un dominio de
aplicación. En la figura Nº 3.21. podemos observar.

3.3.2. Diagrama de Paquetes.

Los diagramas de paquetes muestran como un sistema está dividido en

agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.
Dado que normalmente un paquete está pensado como un directorio, los
diagramas de paquetes suministran una descomposición de la jerarquía lógica
de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia

interna dentro de cada paquete y minimizar el acoplamiento externo entre los
paquetes. El sistema de control y gestión está dividido en cinco componentes
Ventas, Activación, Caja, Almacén y Control Económico cada uno de estos
componentes cumple funciones específicas como se puede apreciar en la
Figura Nº 3.22.

47
 Figura N° 3.8. Diagrama de Clase del Sistema

tbpuesto tbpersonal tbdepartamento

1 1 n
1
1 1 1n n

tbtipo_contrato 1 tbprovincia
1 1
tbusuarios
1 1
tbdestaque 1 1 tbdistrito

tbdetalles_activacio
tbactivaciones
n_prepago tbactivaciones_postpago
n
tbdetalle_activacion_postpago

n
tblista_venta_prepago 1 tbcliente_prepago 1
n tbexperto_postpago
1 1
tbclientes_postpago 1
1 1 1

1
1 1
tbventas_prepago_realizadas tbpago_caja 1 1 n tbobservaciones
1 1
1

tbtipo_venta tbplan
n
n n
tbboletas
tbchips n tbproducto
n 1 1 n tbentrega_documentos tbestado_control_economico
1 1

1
tbingreso_chips1 tbtipo_chip tbubicacion tbingreso_producto
n 1 n 1
n tbpago_caja_postpago
1

1 n
tbsub_ubicacion tbmarca
lista_ventas_postpago
tbventas_postpago_realizadas

Elaborado por: El Investigador

Fuente: El Investigador

48
 Figura N° 3.9. Diagrama de Organización del Área

Ventas Activacion

Caja Control Almacen

Economico

Fuente: Agencia de Ventas Corporación Telenegocios Perú SAC.

3.3.3. Diagramas de Secuencia

El diagrama muestra las interacciones entre los objetos organizadas en una

secuencia temporal. En particular muestra los objetos participantes en la
interacción y la secuencia de mensajes intercambiados.

a) Diagrama 1: Personal

Muestra la secuencia de los mensajes entre los actores, el

administrador y los usuarios (trabajadores del negocio). Se creara
cada usuario dependiendo al área que pertenece el trabajador para
poder configurar sus respectivas funciones.

Figura N° 3.10. Diagrama de Secuencia Módulo Personal

Administrador Usuario /
Trabajadores

Solicita datos
personales

Envia datos
solicitados

Crea usuario,
contraseña y correo
Envia usuario
y contraseña

Elaborado por: El Investigador

49
b) Diagrama 2: Almacén - Ingreso

Muestra la secuencia de los mensajes representados en el proceso de

abastecimiento de equipos e ingreso de las series al sistema y
muestra cual es la intervención del área del almacén y qué función
cumple dentro del proceso.

Figura N° 3.11. Diagrama de Secuencia Almacén - Ingreso

Telefonica Almacen

Envio de lista de
equipos disponibles

Envio de pedido
de equipos

Revisar Pedido

Atencion del pedido

Recepcion y revision
de equipos

Ingreso de series de
equipos al sistema

Elaborado por: El Investigador

Fuente: El Investigador

c) Diagrama 2: Almacén - Funciones

Muestra la secuencia de los mensajes representados en los procesos

o funciones que se realiza en el almacén.

50
 Figura N° 3.12. Diagrama de Secuencia Módulo Almacén - Funciones

Almacén Sistema

Verificar las series

de los equipos

Ingresar series
de los equipos

Actualizar Informacion

Realizar stock
de los equipos

Generar reporte
de las series

Elaborado por: El Investigador

Fuente: El Investigador

d) Diagrama 3: Activación

Muestra la secuencia de los mensajes representados en el proceso de

venta y muestra cual es la intervención del área de activación y que
áreas son las encargadas de enviarle información.

Figura N° 3.13. Diagrama de Secuencia Módulo Activación

Vendedor Almacen Activador

Solicita series
del pedido
Envia series
de equipos

Envia informacion del pedido

Revisa informacion del

pedido y activa los equipos

Envia el monto del pedido

Elaborado por: El Investigador

Fuente: El Investigador

51
 e) Diagrama 5: Ventas

Muestra la secuencia de los mensajes completo en el proceso de

venta del tipo postpago, donde a diferencia de Punto de Venta se
agrega el área Control Económico el cual se encarga de la
documentación.

Figura N° 3.14. Diagrama de Secuencia Módulo Ventas

Cliente Vendedor Control Almacen Activador Caja
Economico

Solicita informacion de equipos

Entrega inform acion

Realiza su pedido

Entrega docum entos

del cliente
Revisa conformidad
de documentos

Envia estado
de documentos

Solicita series
del pedido

Envia series
de equipos

Envia informacion del pedido

Revisa informacion del

pedido y activa los equipos

Envia el m onto del pedido

Informa el monto
de pago del pedido Informa el monto
del pedido a cobrar Revisa el pedido
en sus opciones

Realiza pago del pedido

Em ite comprobante de pago

y guia de rem ision
Recoge equipos con comprobante
de pago y guia de rem is ion

Entrega equipos
de su pedido

Elaborado por: El Investigador

Fuente: El Investigador

52
3.3.4. Diagramas de Colaboración (DC):

Un Diagrama de Colaboración muestra una interacción organizada

basándose en los objetos que toman parte en la interacción y los enlaces
entre los mismos. Estos diagramas muestran las relaciones entre los roles de
los objetos. Cada diagrama de colaboración hará una referencia directa a
cada caso de uso mostrado en la etapa de requisitos, así como también a
cada interface mostrada en la etapa de diseño. La secuencia de los mensajes
y los flujos de ejecución concurrentes se determinarán explícitamente
mediante números de secuencia. A continuación se presentan los diagramas
de colaboración de los principales procesos:

a) Diagrama 1: Personal
Figura N° 3.15. Diagrama de Colaboración Módulo Personal

3: Crea usuario,
contraseña y correo
1: Solicita datos
personales
4: Envia usuario
y contraseña
Administrador Usuario /
Trabajadores
2: Envia datos
solicitados

Elaborado por: El Investigador

Fuente: El Investigador

b) Diagrama 2: Almacén - Ingreso

Figura N° 3.16. Diagrama de Colaboración Almacén – Ingreso

5: Recepcion y revision
de equipos
6: Ingreso de series de
3: Revisar Pedido
equipos al sistema

1: Envio de lista de
equipos disponibles
4: Atencion del pedido
Telefonica Almacen

2: Envio de pedido
de equipos

Elaborado por: El Investigador

Fuente: El Investigador

53
c) Diagrama 2: Almacén - Funciones
Figura N° 3.17. Diagrama de Colaboración Módulo Almacén

1: Verificar las series

2: Ingresar series 3: Actualizar Informacion
de los equipos
de los equipos
4: Realizar stock
de los equipos
5: Generar reporte
de las series
Almacén Sistema

Elaborado por: El Investigador

Fuente: El Investigador

a) Diagrama 3: Activación
Figura N° 3.18. Diagrama de Colaboración Módulo Activación

Vendedor

3: Envia informacion del pedido

5: Envia el monto del pedido

1: Solicita series 4: Revisa informacion del

del pedido pedido y activa los equipos

2: Envia series
de equipos
Almacen Activador

Elaborado por: El Investigador

Fuente: El Investigador

54
 5: Revisa conformidad
1: Solicita informacion de equipos Vendedor de documentos
3: Realiza su pedido 4: Entrega documentos
b)

del Cliente

Cliente 2: Entrega informacion 6: Envia estado

12: Informa el monto de documentos Control
de pago del pedido Economico
17: Recoge equipos con comprobante 7: Solicita series
de pago y guia de remision del pedido 9: Envia informacion del pedido
Diagrama 5: Ventas

13: Informa el monto

15: Realiza pago del pedido
del pedido a cobrar
11: Envia el monto del pedido
10: Revisa informacion del
16: Emite comprobante de pago pedido y activa los equipos
y guia de remision 18: Entrega equipos

Fuente: El Investigador
14: Revisa el pedido de su pedido

Elaborado por: El Investigador

en sus opciones
8: Envia series
de equipos
Activador
Almacen
Figura N° 3.19. Diagrama de Colaboración Módulo Ventas

Caja

55
3.3.5. Generación de Base de datos.

Para la selección del motor de base de datos, se tuvieron en cuenta varios

aspectos importantes. Como primera medida, el motor de base de datos debía
ser un motor que fuese compatible para la implementación de la aplicación
Web, como segundo punto debía ser un motor de base de datos de libre
distribución. Por ello y de acuerdo a estas dos razones fundamentales se
decidió trabajar con MySQL. Anexo 1.

Figura N° 3.20. Base de Datos Personal.

Elaborado por: El Investigador

Fuente: El Investigador

3.3.6. Modelo de Diseño

Es una abstracción del Modelo de Implementación y su código fuente, el cual

fundamentalmente se empleará para representar y documentar su diseño.
Será usado como entrada esencial en las actividades relacionadas a
implementación. Representará a los casos de uso en el dominio de la solución.
Para representar los diagramas del Modelo de Diseño se emplearán diferentes
diagramas de UML tales como:

3.3.6.1. Interfaz del Sistema

El generar ventas es un proceso extenso, que ha resultado engorroso

por llevarse a cabo manualmente en su totalidad, generando una gran
cantidad de documentos físicos y siendo un proceso lento tanto en su
ejecución como en la realización de auditorías. La finalidad del
sistema es simplificar este proceso a través de su automatización.

56
Se diseñó una interfaz amigable y fácil de manejar para el usuario, en
la que se capturan los datos necesarios y se muestran los formatos
asociados a la generación de cada documento. El sistema se ajustó a
las leyes vigentes y se realizan todas las validaciones requeridas para
evitar el mal uso del proceso.

Acceso al sistema

Se requiere que el sistema verifique la identidad del usuario para

acceder a los módulos de personal, almacén, ventas, caja y otros

La construcción de la página principal se definió como una página de

autenticación de usuarios, en donde el usuario deberá ingresar un
Nombre de Usuario (Login) y una Contraseña (Password) para tener
acceso al sistema.

Para el caso del sistema Web es lo siguiente:

Figura N° 3.21. Pantalla de Acceso.

Elaborado por: El Investigador

Fuente: El Investigador

Una vez autenticado, el usuario podrá acceder al Menú Principal de

acuerdo al privilegio correspondiente, en la figura Nº.3.23

57
 Figura N° 3.22. Pantalla de Menú Principal.

Elaborado por: El Investigador

Fuente: El Investigador

Construcción de Formularios de Ingreso de Datos

En esta etapa se crearan todos los formularios de ventas donde se

ingresara información. Cada formulario contara con botones que le
permitirán Agregar, Generar Venta, Listar los datos ingresados
(Cliente, Vendedor) y en algunos casos dejara la posibilidad de
exportar los datos del cliente.

Los Formularios de ventas son los siguientes:

58
Figura N° 3.23. Pantalla de Ventas Colectivos.

Elaborado por: El Investigador

Fuente: El Investigador

Figura N° 3.24. Pantalla de Ventas Negocios.

Elaborado por: El Investigador

Fuente: El Investigador

59
 Figura N° 3.25. Pantalla de Ventas Residencial.

Elaborado por: El Investigador

Fuente: El Investigador

Para la edición de un registro si se conoce el Código Principal de la

tabla en donde se está trabajando, al escribir el código
inmediatamente buscara el registro completo y lo mostrara en pantalla
para entregar la posibilidad de modificarlo, de lo contrario se guardara
la nueva información ingresada.

60
Figura N° 3.26. Pantalla de Modificación del Personal.

Elaborado por: El Investigador

Fuente: El Investigador

Figura N° 3.27. Pantalla de Modificación de Activación.

Elaborado por: El Investigador

Fuente: El Investigador

61
 Figura N° 3.28. Pantalla de Modificación del Cliente.

Elaborado por: El Investigador

Fuente: El Investigador

Se crearan los formularios de ingreso donde se ingresara información

de los productos que proporciona la agencia de ventas. Cada
formulario contara con botones que le permitirán Importar e Ingresar.

El formato de ingreso de datos de es el siguiente:

Figura N° 3.29. Pantalla de Ingreso de Tarjetas SIM.

Elaborado por: El Investigador

Fuente: El Investigador

62
Figura N° 3.30. Pantalla de Registro Tipo Chip.

Elaborado por: El Investigador

Fuente: El Investigador

Figura N° 3.31. Pantalla de Ingreso de Planes.

Elaborado por: El Investigador

Fuente: El Investigador

Figura N° 3.32. Pantalla de Ingreso de Equipos.

Elaborado por: El Investigador

Fuente: El Investigador

63
Formularios de Listado

Este tipo de formato entrega la posibilidad de filtrar de acuerdo a un

criterio de búsqueda que puede ser por código o por nombre, y si el
dato buscado aparece en el listado, entonces se debe seleccionar la
información, cuando se hace clic se llevara los datos a los casilleros
correspondientes de los formularios.

Figura N° 3.33. Pantalla de Búsqueda de Tarjetas SIM.

Elaborado por: El Investigador

Fuente: El Investigador

Figura N° 3.34. Pantalla de Búsqueda de Equipos.

Elaborado por: El Investigador

Fuente: El Investigador

64
 Figura N° 3.35. Pantalla de Búsqueda de Clientes.

Elaborado por: El Investigador

Fuente: El Investigador

Formularios de Generación de Informes

En esta etapa se construyen los formularios que permiten la salida de

información a través de informes.

En cada formulario se podrá apreciar que existe un par de campos o

más que permitan el filtrado de información. Campos como rangos de
fechas o selección de un tipo de haber, entre otros. Adicional a ello
también existe un botón que permite ver el Informe, es botón cuando
es presionado se encargara de enviar los datos que se ingresaron
como parámetros para realizar la selección de registros de acuerdo a
esos parámetros y mostrara el informe asociado a ello.

3.4. IMPLEMENTACIÓN

El objetivo principal que se busca en esta disciplina es convertirlos elementos del

diseño en elementos de implementación, dichos elementos son los archivos y códigos
fuentes. Otra parte de esta disciplina son las pruebas de unidad, las cuales se limitan
a los componentes de software implementados. De esta disciplina se obtendrá un
sistema estable.

Los objetivos específicos son:

 Determinar en qué orden se implementarán los elementos de cada subsistema.

 Integrar el sistema siguiendo el plan.
 Notificar los errores de diseño, si se encuentran, actualizando la documentación.

65
A continuación se detallan cada una de las herramientas y procedimientos utilizados
para desarrollar e implementar la aplicación Web.

Figura N° 3.36. Diagrama de Componentes.

Validacion.
usuario.jsp

Modulo
index.jsp Personal

Modulo
Ventas
Conexion

Modulo
Almacen

Modulo Caja

Modulo Control
Economico Base de Datos

Elaborado por: El Investigador

Fuente: El Investigador

3.4.1. Arquitectura del Sistema

Este capítulo describe el ambiente de construcción e implementación

(arquitectura), con ejemplos de diseño de clases y consideraciones para la
construcción de un Caso de Uso en particular.

La implementación de este proyecto se realiza sobre ambiente web, con una

arquitectura de capas construidas sobre tecnología J2EE. Previamente se
construye una plataforma de desarrollo que facilita y orienta la construcción de
las aplicaciones, definiendo la forma de comunicación de las clases entre
capas, de instanciación de las clases, de ejecución de procesos típicos, como
creación de impresiones y orquestación de procesos batch, más otras
facilidades. Esto constituye el Framework de Desarrollo y se realiza en base a
integración de algunas aplicaciones ya existentes en el mercado, más algunos
desarrollos propios. Algunas de las aplicaciones abiertas que se consideran en
este Framework son las siguientes:

66
Spring2: Framework de desarrollo de aplicaciones alternativo a la típica
implementación Enterprise Java Bean (EJB) del J2EE. Fue desarrollado por
Rod Jonhson, y permite construir aplicaciones más simples y livianas.

Oracle XML Publisher3: Aplicación para la creación de documentos (pdf, excel,

doc) en base a una plantilla predefinida donde se le asocian los atributos de
los objetos de la aplicación.

A continuación se describen las componentes principales de la arquitectura de

implementación, indicando los conceptos arquitectónicos, los Framework
puntuales de algunas capas y su implementación específica en alguno de los
casos de uso del sistema.

3.4.1.1. Diagrama de Capas

Las componentes por cada capa son las siguientes:

Capa Cliente

A esta capa pertenecen las páginas Web y las clases bound

(Manager Bean Boundary), encargadas de controlar la presentación,
configurar las componentes visuales de las páginas Web, manejar
mensajes de información o error, y de relacionarse con la capa de
negocio.

Para la implementación y control de la capa cliente se utilizó el

Framework JSF Trinidad. Esta herramienta permite manejar controles
de presentación similares a Swing, Visual Basic o Delphi, donde la
programación de la interfaz se hace a través de componentes y está
basada en eventos (se pulsa un botón, cambia el valor de un campo,
etc.) El “lenguaje fuente” de las páginas es XHTML y en ejecución se
generan las páginas HTML.

Se considera también parte de la capa de cliente las funciones

propias del browser, pero por ser externas a este desarrollo, no se
considerarán en este documento.

Capa de Negocio

67
 Son parte de esta capa las clases que ejecutan procesos de negocio.
Se han separado en dos tipos según su naturaleza: Clases ON
(Objetos de Negocio), que implementan procesos de negocio
disparados desde la capa de cliente y clases SRN (Servicios de
Reglas de Negocio) que implementan procesos comunes, como
validaciones, cálculos genéricos, acceso a parámetros del sistema,
etc., que no se relacionan directamente con la capa de cliente.

Capa de Datos o Persistencia

Son parte de esta capa tanto los datos como las clases que los
acceden. Las clases DAO (Data Access Object) son las responsables
de encapsular los mecanismos de acceso a los datos en la base de
datos u otra fuente, como por ejemplo un Webservice o un archivo.

La comunicación entre las clases no es directa entre las distintas

capas, sino que es implementada mediante la configuración del
contenedor J2EE. Tampoco es directa entre clases de una misma
capa, es decir, una clase del tipo ON, que necesite invocar un método
de otra clase ON o SRN, no debe incluir como atributo un objeto de la
otra clase para acceder al método, sino que se invoca indirectamente
mediante métodos provistos por la arquitectura.

3.4.2. Publicacion

En esta parte detallaremos con un ejemplo los pasos a seguir para levantar la
aplicación en internet.

Por diversos motivos necesitamos subir archivos a nuestro Hosting desde

nuestro cPanel. Para logarlo seguiremos estos sencillos pasos.

1. Ingresar a nuestra área de administración cPanel con nuestros accesos

actuales.

68
 Figura N° 3.37. Pantalla de ingreso a cPanel.

Fuente: http://telenegocios.net:2082/logout/?locale=en

Para ingresar a él debe ingresar a la dirección de su dominio añadiendo al

final “/cpanel”. Ejemplo: dominioejemplo.com/cpanel

Después de ingresar el usuario y contraseña correctos, podrá ver una

ventana como esta:

Figura N° 3.38. Pantalla de Opciones.

Fuente: http://telenegocios.net:2082/cpsess4156573253/frontend/x3/index.html

69
 Seleccionaremos la opción “Administrador de Archivos”

Figura N° 3.39. Pantalla Administrador de Archivos.

Fuente: http://telenegocios.net:2082/cpsess4156573253/frontend/x3/index.html

Nos mostrará la siguiente ventana:

Figura N° 4.40. Pantalla de Selección de Directorios.

Fuente: http://telenegocios.net:2082/cpsess4156573253/frontend/x3/index.html

En esta ventana seleccionaremos la carpeta a la que entraremos, por

ejemplo si seleccionamos la opción: “Directorio Home” nos enviará a la
carpeta raíz de nuestro Hosting.

Si seleccionamos la opción “Web Root (public_html/www)” nos enviará a la

carpeta dónde se encuentran los archivos de nuestro sitio web. En este
caso es la opción que seleccionaremos.

70
 Después de dar clic en el botón “Go” veremos lo siguiente:

Figura N° 3.41. Pantalla Web Root.

Fuente: http://telenegocios.net:2082/cpsess4156573253/frontend/x3/filemanager/index.html

Para subir un archivo debemos dar clic en el botón lo que nos

mostrará la siguiente pantalla:

Figura N° 3.42.Pantalla Carga de Archivos.

Fuente: http://telenegocios.net:2082/cpsess4156573253/frontend/x3/index.html

Al dar clic en el botón “Seleccionar Archivos” nos abrirá una ventana del
explorador de Windows donde podremos seleccionar nuestro archivo el
cual se subirá al servidor automáticamente.

Una vez cargado el archivo podemos cerrar esta ventana.

71
 PARA crear carpetas, lo podemos hacer desde la ventana principal de
nuestro Administrador de Archivos, únicamente debemos dar clic en el

botón , indicarle el nombre y quedará creada la carpeta.

3.5. PRUEBAS

Para el desarrollo de este proyecto, se tuvieron en cuenta una serie de factores

importantes al momento de realizar las pruebas correspondientes al sistema Web de
control y gestión, entre ellas se encuentra el diseño y puesta en marcha de un plan de
pruebas, el cual tiene como objetivo garantizar la calidad y cumplimiento de los
requerimientos funcionales y no funcionales detallados anteriormente, para ello se
definió un alcance de dicho plan determinado de la siguiente manera; se definieron
una serie de criterios los cuales serán la base fundamental para el buen
funcionamiento del sistema, entre los criterios a tratar se tiene los siguientes:

 Rendimiento.
 Confiabilidad.
 Funcionalidad
 Requerimientos de Implementación.
 Requerimientos físicos.
 Aspectos Generales del sistema.

Entre las pruebas a utilizar se encuentran:

3.5.1. Justificación de las Pruebas de Cristal y Unitarias.

El desarrollo de este tipo de pruebas no se tuvieron en cuenta dentro del plan

diseñado para el test de la aplicación, esto debido a que los casos de uso no
tienen un alto nivel de complejidad en su procesamiento, ya que, por el
contrario estos son de tipo transaccional, es decir, no se requiere de una
inspección estricta en sus métodos, sentencias y condiciones propias de los
casos de uso, de igual manera cada uno de los módulos, realiza un
procesamiento de datos bajo en sus procedimientos.

72
3.5.2. Pruebas de Integración.

Pruebas funcionales. A continuación se listan los Casos de prueba del caso

de uso, para tener una descripción de todos los casos de uso,

Cuadro Nº 3.2 Validaciones y Verificaciones

Entrada Validaciones y/o verificaciones

Ingresar producto Verifica que producto no sea un dato nulo
Ingresar tipo Plan Verifica que los planes exista en la base de
datos
Ingresar Cliente Verifica que los clientes exista en la base de
datos
Ingresar Tipo de Venta Verifica que los tipos de venta exista en la base
de datos
Ingresar Ventas Prepago Verifica que los datos no sean nulos
Ingresar Ventas Postpago Verifica que los datos no sean nulos
Elaborado por: El Investigador
Fuente: El Investigador

3.5.3. Pruebas de Estrés.

Para el desarrollo de las pruebas de estrés, se seleccionaron los diferentes

módulos que desempeñan un alto nivel de carga para la aplicación, por esta
razón se decidió realizar las pruebas a los módulos de almacén, ventas. De
esta manera se pretende conocer las capacidades de la aplicación antes de
llevarla a un entorno de trabajo real.

Para lograr este objetivo se utilizó una herramienta llamada “Web Server
Stress Tool 7”. Este software permite realizar una simulación de varios
usuarios que utilizan el sistema al mismo tiempo. La prueba se realizó con 10
usuarios conectados en línea simulados en un equipo (local) el cual realiza
peticiones a otro equipo (Servidor) donde se encuentra alojada la aplicación
web, realizando 100 click’s por usuario cada 20 segundos. Los resultados
obtenidos por medio de este test fueron los siguientes:

73
 Cuadro Nº 3.3 Web Server Stress Tool 7

Elaborado por: El Investigador

Fuente: El Investigador

Cuadro Nº 3.4 Resultados obtenidos de Web Server

Elaborado por: El Investigador

Fuente: El Investigador

De acuerdo a los resultados Obtenidos, se puede afirmar que para el

escenario mencionado anteriormente, la aplicación cumple satisfactoriamente
con el objetivo de la prueba de estrés, debido a esto responde positivamente
las expectativas de la misma, con respecto al ancho de banda y número de
solicitudes que se podrían a llegar a tener en la aplicación.

De esta manera se puede obtener un gráfico ilustrativo correspondiente a las

cargas y solicitudes hechas al servidor desde la aplicación y su
correspondiente base de datos.

74
 Figura N° 3.43.Pantalla Carga y Solicitudes hechas al Servidor.

Elaborado por: El Investigador

Fuente: El Investigador

3.5.4. Pruebas de seguridad

Para estas pruebas se tuvieron en cuenta una serie de parámetros

importantes para poder diseñar e implementar un mecanismo de seguridad,
el cual será de gran ayuda para determinar posibles vulnerabilidades del
sistema y tomar medidas correctivas al respecto.

Para este tipo de pruebas se hizo uso de un framework de referencia llamado

OWASP Testing Guide v3.0, este tiene por objetivo ayudar a construir un
proceso completo de pruebas estratégicas, el framework consta de una serie
Ítems que deben ser tenidos en cuenta antes de la realización de las
pruebas, entre estos ítems se tienen:

 Revisión de los Requisitos de Seguridad

 Gestión de usuarios
 Autenticación
 Autorización
 Confidencialidad de los datos
 Integridad
 Gestión de sesiones

3.5.4.1. Resultado de pruebas OWASP

Dentro del desarrollo de las pruebas del sistema, OWASP implementa

una serie de procedimientos que se describen como una metodología

75
 para la realización de pruebas de intrusión en aplicaciones Web, y
explica cómo realizar la comprobación de cada vulnerabilidad.

Para el desarrollo del test de intrusión en aplicaciones Web se

definieron los siguientes tipos de pruebas:

 Pruebas de autenticación
 Pruebas de autorización
 Pruebas de gestión de sesiones

Cuadro Nº 3.5 Pruebas del Sistema OWASP

Numero
Categoría Nombre de Prueba Vulnerabilidad
de Ref.
OWASP- Se encontraron
Prueba de fuerza bruta
AT-004 credenciales débiles
Pruebas de
Prueba de recordatorio
Autenticación OWASP-
de contraseña y N.A.
AT-006
restablecimiento
Privilegios listados
Pruebas de OWASP- Prueba de escalada
correctamente según
Autorización AZ-003 de privilegios
tipo de usuario.
Prueba de
OWASP- Pruebas de fijación de
gestión de N.A
SM-003 sesión.
sesiones
Elaborado por: El Investigador
Fuente: El Investigador

Una vez realizado este estudio se identificó los posibles focos de reingeniería los cuales se
visualizaron con el apoyo de la metodología RUP es su fase de modelamiento de negocios,
lo que permitió utilizar los diagramas de Casos de Uso y de Secuencia del Software
Racional Rose.

76
 CAPÍTULO IV
ANÁLISIS Y DISCUSIÓN DE RESULTADOS
En el capítulo IV se muestra los posibles resultados del desarrollo del proyecto donde se ha
evaluado el diseño del sistema, con el fin de asegurarnos que se cumplan los objetivos
impuestos en la presente tesis. Estas evaluaciones nos permitirán observar el correcto
funcionamiento de los módulos, así como aspectos de seguridad, compatibilidad de la
aplicación, y son descritas en el actual capítulo.

4.

4.1. MARCO ESTADÍSTICO

Se planea alquilar el servicio de un servidor web después de que se termine las

evaluaciones, para que el sistema de control y gestión sea accesible desde diferentes
lugares externos a la agencia de ventas y se tenga la información disponible en todo
momento para todo el personal de la agencia de ventas.

Se pudo realizar comparaciones del tiempo ahorrado en cada proceso, respecto al uso
del sistema de control y gestión, contrastándolo con el tiempo dedicado anteriormente,
para los mismos procesos, basándose en entrevistas que se realizaron a los
involucrados en estos procesos como el personal de la agencia de ventas.

4.1.1. Procesos Completados

A. Administración del Personal

Este proceso contempla la creación de usuarios para el personal que labora en

la agencia de ventas.

77
 o Con el sistema de control y gestión: el proceso demora entre 8 a 12
minutos, dependiendo de la habilidad del usuario para usar el sistema.
o Manualmente: el proceso no se realizaba por motivo que no era necesario.

B. Generación de Ventas

Este proceso contempla la inscripción de clientes, tipos de ventas, tipos de

planes, asignación de series de equipos y tarjetas Sim y asignar el número
correspondiente.

o Con el sistema de control y gestión: el proceso de ventas demora de 15 a

20 minutos para Clientes nuevos; dentro de ello podemos elegir el tipo de
venta, tipo de plan dependiendo al tipo de venta, además de asignar la o
las series de los equipos y tarjetas SIM de acuerdo a la venta que se esté
realizando, para el lado de asignar el numero este proceso lo realiza el
activador después de haber generado la activación de el o los equipos
solicitado en la venta.
o Anteriormente: los vendedores al final del horario de atención al público, se
encargaba de realizar el ordenamiento de los papeles de ventas e iba
registrando a las ventas de acuerdo a como se realizaban la venta en una
hoja de Excel, esto le tomaba alrededor de una hora diaria y luego ya al
final del mes se generaba un listado de ventas general el cual ayuda para
llevar un control de ventas realizadas en el mes y que vendedores
cumplieron con sus metas.

C. Ingreso de Equipos y Tarjetas SIM

Este proceso considera el registro de equipos y tarjetas SIM nuevos que recién
han llegado a la agencia de ventas.

o Con el sistema de control y gestión: para el registro de las series de los

equipos y tarjetas SIM, con la funcionalidad de importación de ingreso
desde una hoja de cálculo, se consigue en un promedio de 3 minuto por
ingreso si ya se cuenta con la los modelos de equipos y tarjetas SIM y de 5
minutos si recién se registra los nuevos modelos y se pasa las series a la
hoja de cálculo.
o Anteriormente: el proceso se hacía de la siguiente manera, el almacenero
tenía que ingresar cada serie de equipo y tarjeta SIM en una hoja de Excel,

78
 después se une a las series ya existentes en la agencia para tener un
control del stock disponible.

D. Inventario de Equipos y Tarjetas SIM

Este proceso comprende el registro de los equipos y tarjetas SIM existentes y

disponibles en la agencia de ventas.

o Con el sistema de control y gestión: este proceso se realiza casi de forma

automática, ya que se cuenta con las series de los equipos y tarjetas SIM
ya cargadas a la base de datos; solo basta con generar las órdenes de
control y este automáticamente genera los listados correspondientes; este
proceso no tarda más de un minuto por grado.
o Anteriormente: este proceso se realizaba, comenzando por pasar las series
de los registros a una hoja de cálculo donde se guardaba la información de
los equipos y tarjetas SIM, este proceso demoraba en un promedio de 7 a
10 días; luego se pasaba a realizar los cálculos respectivos de los listados
y orden de series el cual demoraba alrededor de 1 día.

E. Consolidados de Ventas

Este proceso comprende el registro de las ventas postpago y prepago de la

agencia de ventas.

o Con el sistema de control y gestión: este proceso se realiza de forma diaria

donde se registra las ventas, además se puede realizar los listados de
ventas de cada vendedor, como esta información se encuentra registrada
en la base de datos, este consolidado se genera de forma automática.
o Anteriormente: este proceso solamente era responsabilidad de la
secretaria, quien tenía en un registro la lista de las ventas de cada
vendedor para fines de pago y control de metas

4.1.2. Respecto a los Usuarios

Con respecto a los clientes, la atención a ellos ahora se realiza de forma más
rápida, sin tener que estar desplazándolo de área en área, ya que antes si el

79
 cliente quería saber sobre los planes de venta tenían que pasar al área de
ventas donde el personal encargado le brindaría la información respectiva; a
veces también no se contaba con la información requerida por el cliente o con
información errónea en el caso de los equipos disponibles; con el uso de
sistema de control y gestión la información se encuentra disponible por el
momento en la red local de la institución educativa, pero que se puede ser
accedida por todos en horario de trabajo desde a las áreas de la agencia de
ventas; posteriormente como ya se indicaba anteriormente el acceso de este
sistema de información estará disponible en todo momento para todos los
usuarios ya que se adquirirá los servicios de un servidor web para esta
aplicación.

Con respecto a los trabajadores, pueden realizar sus labores de realizar

ventas, ingresar equipos e inventarios de manera mucho más rápida que
antes, de manera mucho más segura y con menos errores que antes.

4.2. PRUEBA DE HIPÓTESIS

El instrumento utilizado para la recolección de información y medición de los tiempos

en coordinación del personal fue el cuestionario. Esta herramienta permitió la
recolección de los datos necesarios para realizar el diseño; el cuestionario fue tomado
a los vendedores, personal administrativo y clientes; como el tamaño de la población
es muy poca se ha decidido utilizar el total de población como la muestra; para las
respuestas del cuestionario se usó la escala auto aplicada de Likert como se muestra
en el cuadro Nº 4.1.

Cuadro N° 4.1. Modelo de escala de Likert

INDICADOR EQUIVALENCIA
1 Totalmente de acuerdo
2 De acuerdo
3 Indeciso
4 En desacuerdo
5 Totalmente en desacuerdo
Fuente: Antz. Full service research company.
Elaborado por: El Investigador

Existen dos maneras de aplicar las escalas de actitud tipo Likert: auto-administrada y
la entrevista; en la primera se le entrega al sujeto la escala y él la contesta; en la
segunda, un entrevistador lee las afirmaciones y las alternativas de respuesta al

80
sujeto y anota lo que éste le conteste. Para esta investigación se utilizó el modo de
escala auto-administrada.

De la encuesta realizada a los trabajadores, y clientes obtuvo el resultado mostrado

en el Cuadro Nº 4.2.

Cuadro N° 4.2. Resultados obtenidos del Cuestionario

1 2 3 4 5
El sistema de control y gestión agiliza los procesos de la
1 2 4 2 2 0
agencia.
El sistema de control y gestión muestra la información
2 3 5 1 1 0
adecuada.
El sistema de control y gestión muestra la información en
3 3 3 3 1 0
forma oportuna.
El sistema de control y gestión hace más fácil mi labor
4 2 5 2 1 0
dentro de la agencia.
El sistema de control y gestión ayuda en las
5 3 3 2 2 0
coordinaciones en la agencia.
El sistema de control y gestión ayuda en el control de
6 2 5 2 1 0
equipos y tarjetas SIM.
El sistema de control y gestión está alineado con los
7 3 3 2 2 0
objetivos de la agencia.
El sistema de control y gestión ayuda con la
8 3 4 1 2 0
administración de la agencia.
9 El sistema de control y gestión es confiable. 4 4 1 1 0
El sistema de control y gestión ayuda a la gestión de
10 3 3 1 3 0
ventas de la agencia.
Fuente: Corporación Telenegocios Perú SAC.
Elaborado por: El Investigador

En la tabla anterior se logra apreciar la cantidad de encuestados optaron por una

respuesta en cada pregunta, se puede apreciar que la mayoría de los encuestados
optaron por las opciones 4 y 5, queriendo decir que para la mayoría de los
encuestados que el diseño del sistema de control y gestión web, colabora y agiliza los
procesos respectos a la gestión de ventas de la agencia; para un mayor análisis se
realizó la Figura Nº 4.2.

81
 Figura N° 4.1. Resultado de Cuestionario.

Totalmente de acuerdo
4
De acuerdo
3
Indeciso
2 En desacuerdo
Totalmente en desacuerdo
1

0
1 2 3 4 5 6 7 8 9 10

Fuente: Corporación Telenegocios Perú SAC.

Elaborado por: El Investigador

Como se observa en la Figura Nº 4.1, gran parte de los encuestados indican que el
diseño del sistema de control y gestión, cumple con el apoyo en los procesos de la
gestión de ventas, el control de los equipos y tarjetas SIM de la agencia de ventas;
además indican que el sistema de control y gestión es confiable y muestra la
información requerida en el momento.

Datos sobre los tiempos medidos de los procesos

En la prueba analizamos que nuestra aplicación cumple con el objetivo de minimizar

el tiempo en los procesos que se realiza para una venta, como se muestra en el
Cuadro N° 4.3.

Cuadro N° 4.3. Cuadro Comparativo

OBSERVACIONES OBSERVACIONES
AREA PROCESO ANTES DE LA DESPUES DE LA
APLICACIÓN WEB APLICACIÓN WEB

Ventas Evaluar datos del cliente 3 min. 2 min.

Entregar a documentos a
Ventas 1 min. 1 min.
Control Económico
Control Validar estado de
3 min. 2 min.
Económico documentos del cliente
Almacén Solicitar series a Almacén 2 min. 1 min.
Activación Enviar Series a Activador 2 min. 1 min.
Activación Enviar Número telefónico 2 min. 1 min.
Ventas Registrar datos del Cliente 3 min. 2 min.
Caja Enviar monto a Caja 2 min. 1 min.

82
 Caja Emitir comprobante a Caja 2 a 3 min. 2 min.
Recoger equipo de
Almacén 2 min. 1 min.
Almacén
Entregar equipo de
Almacén 2 min. 1 min.
Almacén
Fuente: Corporación Telenegocios Perú SAC.
Elaborado por: El Investigador

En la Figura Nº 4.2 se muestra los tiempos que antes tomaba realizar el proceso de
ventas y el que actualmente demora.

Figura N° 4.2. Tiempo de Demora en el Proceso de Ventas.

Entregar equipo de Almacén

Recoger equipo de Almacén

Emitir comprobante a Caja

Enviar monto a Caja

Registrar datos del Cliente

Enviar Número telefónico

Enviar Series a Activador

Solicitar series a Almacén

Validar estado de documentos del cliente

Entregar a documentos a Control Económico

Evaluar datos del cliente

0 0.5 1 1.5 2 2.5 3 3.5

Con Aplicación Web Sin Aplicación Web

Fuente: Corporación Telenegocios Perú SAC.

Elaborado por: El Investigador

Con el sistema de control y gestión: este proceso se realiza de manera automática

con un mínimo margen de error y demora de 15 a 18 minutos por venta, generando la
boletas y/o factura de venta en tan solo un solo día.

Anteriormente: este proceso demoraba de 20 a 25 minutos además de confirmar si los

datos proporcionados por el cliente son verdaderos.

En la Figura 4.3, se muestra la medición de los tiempos que anteriores y actuales al

respecto al uso del sistema de información.

83
 Figura N° 4.3. Tiempo de Demora en el Proceso de Ingreso de Series.

Realizar Stock de series

Ingresar series en excel
Verificar series del producto
Revisar series de las guias

0 1 2 3 4 5 6

CON APLICACIÓN WEB SIN APLICACIÓN WEB

Fuente: Corporación Telenegocios Perú SAC.

Elaborado por: El Investigador

Como se observan en los gráficos anteriores se redujo en más del 50% la realización
de cada proceso; especialmente en los procesos relacionados con el registro de
clientes, ventas, ingreso de equipos e inventarios, antes estos requerían más de tres
días y con el uso de sistema de control y gestión este tiempo se redujo a tan solo un
día.

4.2.1. Análisis Estadístico de las Pruebas

Por otro lado también se utilizó un estadígrafo para el contrastes, para el cual
se utilizó la prueba de T de Student, que es utilizado para comprobar si la
hipótesis nula (h0) se puede rechazar o no. La Hipótesis nula: la H0 consiste
en que no hay influencia del sistema de control y gestión sobre los procesos
de la agencia de ventas.

Las fórmulas para la prueba de hipótesis son las siguientes:

Caso I Caso II Caso III

Ho: u1=u2 Ho: u1=u2 Ho: u1=u2
Ha: u1<u2 Ha: u1≠u2 Ha: u1>u2
Prueba estadística:

con n-1 grados de libertar

Para el cálculo del valor estadístico se tiene el Cuadro Nº 4.4 el cual indica
los tiempos que toman en realizar los procesos de venta.

Cuadro N° 4.4. Tiempos del proceso de ventas

AREA PROCESO TIEMPOS

Ventas Evaluar datos del cliente 3 min.

Ventas Entregar a documentos a Control Económico 1 min.

84
Control Económico Validar estado de documentos del cliente 3 min.
Almacén Solicitar series a Almacén 2 min.
Activación Enviar Series a Activador 2 min.
Activación Enviar Número telefónico 2 min.
Ventas Registrar datos del Cliente 3 min.
Caja Enviar monto a Caja 2 min.
Caja Emitir comprobante a Caja 2 a 3 min.
Almacén Recoger equipo de Almacén 2 min.
Almacén Entregar equipo de Almacén 2 min.
Fuente: Corporación Telenegocios Perú SAC.

A continuación se pasa a realizar el cálculo del estadígrafo “t”.

Figura N° 4.4. Tabla de la T de Student.

Fuente: www.statics.ch

Consolidado de Ventas

ẋ = 5.176923

s = 1.566925

∞ = 0.05

5.176923 – 1
t= =9.61124674
1.566925/√13

Gl=n-1=13-1=12

85
 Calculando el valor de t en la tabla:

t = 1.7823

Figura N° 4.5. Calculo del Estadígrafo “t”

Elaboración: El investigador

Como se muestra en el Gráfico 4.5. se rechaza la hipótesis nula y se acepta

la hipótesis alternativa.

Como se desarrolló, en todas las pruebas T de Student arrojaron que la

hipótesis nula se rechaza y se acepta la alternativa, como se observar en la
Figuras 4.5, que el estadígrafo “t” se sitúa en la región crítica, por tanto no se
sigue el criterio de aceptación de la hipótesis nula. De esta manera, se
rechaza la H0 y se deduce que a un nivel 0.05 de significancia el Sistema de
control y gestión basado en tecnología web produce efectos significativos en
el proceso de gestión de ventas de la agencia de ventas.

En el presente capitulo se realizó el análisis de resultados de los datos, con el fin de obtener
los indicadores de la calidad de servicio actual y después de la intervención; así mismo se
desarrolló la validación de las hipótesis general, finalmente se procedió a la validación de
los instrumentos utilizados en el trabajo de investigación.

86
 CONCLUSIONES

1. Se concluye que la arquitectura tres capas permite llevar a cabo el desarrollo en varios
niveles, lo cual hace más fácil reemplazar o modificar un capa sin afectar los módulos
restantes.
2. Con la Implantación del Sistema se lograra el objetivo principal de este trabajo, el
mismo que permite que los datos se generen de manera rápida, seguridad y
confiabilidad.
3. Que después de aplicar el sistema se puede brindar mejor servicio al cliente porque
agilita los procesos de ventas, cobros y otros.
4. Se concluye que al dar un seguimiento a los clientes ocasionales genera una mejor
rentabilidad a la Empresa.

87
 RECOMENDACIONES

1. Hacer un buen uso de la aplicación para optimizar recursos tanto humanos como
financieros.

2. Cambiar la visión de las empresas y generar en ellas una necesidad del uso del
comercio electrónico.

3. En la tesis desarrollada se manejan dos tipos de roles: usuario y administrador, sin

embargo, si la evolución del sitio amerita establecer otros niveles de acceso al éste, se
recomienda crear roles adicionales a los ya existentes.

4. Se recomienda a las empresas en usar estas plataformas móviles ya que ayuda a

transmitir la información a los empleados y realizar ventas electrónicas, logrando así
tener un mejor rendimiento de su empresa.

88
 REFERENCIAS

Referencias Electrónicas

1. Laboratorio de Computación - Universidad de Magallanes. Introducción a la OOP

Disponible en:
http://kataix.umag.cl/~ruribe/Utilidades/Introduccion%20a%20la%20Programacion%20Orientada
%20a%20Objetos.pdf
Accesado él: [01 de Febrero 2014]

2. Cinvestav - Departamento de Computación. Programación orientada a objetos

Disponible en:
http://computacion.cs.cinvestav.mx/~acaceres/courses/udo/poo/files/slides/POO-01.pdf
Accesado el: [01 de Febrero 2014]

3. Compunauta Micro Linux (uLinux) MicroLinux II - free . Aprendiendo Java y

Programación Orientada a Objetos
Disponible en:
http://www.compunauta.com/forums/linux/programacion/java/AprendiendoJava.pdf
Accesado el: [01 de Febrero 2014]

4. Aprendizaje Web. Programación Orientada a Objetos

Disponible
en:http://aprendizajeweb.com/CursoJava2012/LibrosVarios/Programacion%20Orientada%20A%
20Objetos%20-%20Luis%20Joyanes%20Aguilar.pdf
Accesado el: [01 de Febrero 2014]

5. Universidad de Alicante. Bases de Datos 1

Disponible en: http://rua.ua.es/dspace/bitstream/10045/2990/1/ApuntesBD1.pdf
Accesado el: [01 de Febrero 2014]

6. FREELIBROS.ORGSW. Video2Brain: MySQL, Gestion de Base de Datos 2011

Disponible en:http://www.freelibros.org/videotutoriales/video2brain-mysql-gestion-de-bases-de-
datos-2011.html
Accesado el: [01 de Febrero 2014]

7. SW Computación. Bases de datos

Disponible en: http://www.sw-computacion.f2s.com/Linux/007-Bases_de_datos.pdf
Accesado el: [01 de Febrero 2014]

89
8. UDI Universitaria de investigacion y desarrollo. Introducción a las Bases de Datos
Disponible en:
http://www.udi.edu.co/paginas/investigacion/descargas/04/UDI_Libro_Bases_de_Datos.pdf
Accesado el: [01 de Febrero 2014]

9. UdoSpace. Desarrollo de una aplicación web basada en tecnología helpdesk

para ofrecer servicios de soporte técnico e inventario en la Gerencia de
Informática de la Empresa C.A. Hidrológica del centro, en Valencia estado
Carabobo
Disponible en: http://ri.biblioteca.udo.edu.ve/handle/123456789/1643?mode=full
Accesado el: [01 de Febrero 2014]

10. Casa del libro.com. Ingeniera de Software

Disponible en: http://www.casadellibro.com/libro-ingenieria-del-
software/9788478290741/1048885
Accesado el: [01 de Febrero 2014]

11. Casa del libro.com. Programacion de Aplicaciones Web

Disponible en: http://www.casadellibro.com/libro-programacion-de-aplicaciones-
web/9788497321815/910394
Accesado el: [01 de Febrero 2014]

12. OSIPTEL
Disponible en:
http://www.osiptel.gob.pe/WebsiteAjax/WebFormgeneral/sector/wfrm_Consulta_Informa
cion_Estadisticas.aspx?CodInfo=13463&CodSubCat=864&TituloInformacion=Indicador
es%20Estad%C3%ADsticos&DescripcionInformacion=
Accesado el: [15 de Enero 2014]

13. MySQL AB. Tutorial básico de MySQL

Disponible en:http://www.mysql-hispano.org/page.php?id=6&pag=1
Accesado el: [08 de Febrero 2014]

14. Textos.Pucp.: Consumo de teléfonos móviles entre adolescentes y jóvenes en el Perú

Disponible en:http://textos.pucp.edu.pe/texto/Consumo-de-telefonos-moviles-entre-
adolescentes-y-jovenes-en-el-Peru-
Accesado el: [02Marzo 2014]

15. Universitat Politécnica de Valencia. Diseño e Implementación de una tienda virtual

Disponible en:
http://riunet.upv.es/bitstream/handle/10251/9110/dise%C3%B1oeimplementaciondeunatiendavir
ualFcoAroca.pdf?sequence=1&isAllowed=y
Accesado el: [08Marzo 2014]

90
16. Deposit digital de documentos de la UAP: Diseño e implementación de un portal web
para una empresa de sistemas de iluminación
Disponible en:http://ddd.uab.cat/pub/trerecpro/2010/hdl_2072_48072/AlsinaMorilloJoanR-
ETISa2008-09.pdf
Accesado el: [12Marzo 2014]

17. E-Prints Complutense. Desarrollo de una aplicación Web para la gestión de Entornos
Virtuales
Disponible en: http://eprints.ucm.es/13083/1/Memoria_SI_Final.pdf
Accesado el: [15 Marzo 2014]

91
ANEXOS

92
A1 ESTRUCTURA DE LA BASE DE DATOS.

CREATE TABLE `Lista_Ventas_Postpago` (

`IMEI` varchar(50) NOT NULL,

`ICC` varchar(50) NOT NULL,

`Modelo` text NOT NULL,

`Tipo_Chip` varchar(50) NOT NULL,

`Plan` text NOT NULL,

`Cargo_Fijo` decimal(15,2) DEFAULT NULL,

`Monto` decimal(10,2) NOT NULL,

`Fecha` date NOT NULL,

`DNI_RUC` varchar(50) NOT NULL,

`ID_Vendedor` varchar(50) NOT NULL,

`ID_Local` varchar(50) NOT NULL,

`Estado` text NOT NULL,

PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbActivaciones` (

`DNI_RUC` varchar(11) NOT NULL,

`Fecha_Venta` date NOT NULL,

`Plan` text NOT NULL,

`Fecha_Activacion` date NOT NULL,

`ID_Vendedor` varchar(50) NOT NULL,

`ID_Local` varchar(50) NOT NULL,

`Estado_Activacion` text DEFAULT NULL,

`Estado_Entrega` text DEFAULT NULL,

`Estado_Documentos` text DEFAULT NULL,

`Observaciones` text DEFAULT NULL,

93
PRIMARY KEY (`DNI_RUC`,`Fecha_Venta`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbActivaciones_postpago` (

`DNI_RUC` varchar(11) NOT NULL,

`Fecha_Venta` date NOT NULL,

`Plan` text NOT NULL,

`Fecha_Activacion` date NOT NULL,

`ID_Vendedor` varchar(100) NOT NULL,

`ID_Local` varchar(100) NOT NULL,

`Estado` varchar(50) DEFAULT NULL,

PRIMARY KEY (`DNI_RUC`,`Fecha_Venta`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbBoletas` (

`Boleta` varchar(50) NOT NULL,

`ID_Ubicacion` varchar(50) NOT NULL,

`Estado` text NOT NULL,

`Fecha` date NOT NULL,

`Detalle` text,

`Monto` decimal(11,2) DEFAULT '0.00',

PRIMARY KEY (`Boleta`,`ID_Ubicacion`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbCancela_Liquidado` (

`Fecha_Venta` date NOT NULL,

`DNI_RUC` varchar(50) NOT NULL,

`RECIBO` varchar(20) DEFAULT NULL,

94
 `Fecha_Pago` date DEFAULT NULL,

PRIMARY KEY (`Fecha_Venta`,`DNI_RUC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbChips` (

`ICC` varchar(19) NOT NULL,

`ID_Tipo` bigint(20) NOT NULL,

`ID_Ubicacion` bigint(20) NOT NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbDepartamento` (

`ID` int(11) NOT NULL,

`Departamento` text NOT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbDeposito_Garantia` (

`DNI_RUC` varchar(50) NOT NULL,

`Fecha` date NOT NULL,

`Monto` decimal(11,2) DEFAULT NULL,

`ID_Cobrador` varchar(50) DEFAULT NULL,

`Recibo` varchar(50) DEFAULT NULL,

`ID_Receptor` varchar(50) DEFAULT NULL,

`Fecha_Entrega` date DEFAULT NULL,

`Fecha_Activacion` date NOT NULL,

PRIMARY KEY (`DNI_RUC`,`Fecha`,`Fecha_Activacion`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

95
CREATE TABLE `TbDestaque` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

`Destaque` varchar(50) DEFAULT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=latin1;

INSERT INTO `TbDestaque` (`ID`, `Destaque`) VALUES

(1,'Plataforma'),(2,'Campo'),(3,'Administrativo');

CREATE TABLE `TbDetalles_Activacion_Postpago` (

`IMEI` varchar(50) NOT NULL,

`ICC` varchar(50) NOT NULL,

`Modelo` varchar(100) DEFAULT NULL,

`DNI_RUC` varchar(50) NOT NULL,

`Fecha_Venta` date NOT NULL,

`Fecha_Activacion` date DEFAULT NULL,

`ID_Activador` varchar(50) DEFAULT NULL,

`Numero` varchar(50) DEFAULT NULL,

PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AVG_ROW_LENGTH=61;

CREATE TABLE `TbDetalles_Activacion_Prepago` (

`IMEI` varchar(50) NOT NULL,

`ICC` varchar(50) NOT NULL,

`Modelo` varchar(100) DEFAULT NULL,

`DNI_RUC` varchar(50) NOT NULL,

`Fecha_Venta` date NOT NULL,

`Fecha_Activacion` date DEFAULT NULL,

`ID_Activador` varchar(50) DEFAULT NULL,

`Numero` varchar(50) DEFAULT NULL,

96
 PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbDetalles_Venta_Puntos` (

`IMEI` varchar(50) NOT NULL,

`ICC` varchar(50) NOT NULL,

`Modelo` varchar(100) DEFAULT NULL,

`DNI_RUC` varchar(50) DEFAULT NULL,

`Fecha_Venta` date DEFAULT NULL,

`Tipo` varchar(50) NOT NULL,

PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbDistrito` (

`ID` int(11) NOT NULL,

`ID_Departamento` int(11) NOT NULL,

`ID_Provincia` int(11) NOT NULL,

`Distrito` text NOT NULL,

PRIMARY KEY (`ID`,`ID_Departamento`,`ID_Provincia`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbEgresos_Caja` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

`ID_Local` varchar(50) NOT NULL,

`Tipo` varchar(50) NOT NULL,

`Fecha` date NOT NULL,

`Detalle` text NOT NULL,

`Monto` decimal(15,2) NOT NULL,

97
 PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;

CREATE TABLE `TbEntrega_Documentos` (

`DNI_RUC` varchar(11) NOT NULL,

`Fecha_Activacion` date NOT NULL,

`Fecha_Venta` date NOT NULL,

`Experto` tinyint(1) DEFAULT NULL,

`Contrato_Prestacion` tinyint(1) DEFAULT NULL,

`Anexo_1A` tinyint(1) DEFAULT NULL,

`Anexo_Adq_Equipo` tinyint(1) DEFAULT NULL,

`DNI` tinyint(1) DEFAULT NULL,

`Ficha_RUC` tinyint(1) DEFAULT NULL,

`Boleta` tinyint(1) DEFAULT NULL,

`Fotocheck` tinyint(1) DEFAULT NULL,

`Guia` tinyint(1) DEFAULT NULL,

`Recibo_Servicios` tinyint(1) DEFAULT NULL,

`Observaciones` text,

PRIMARY KEY (`DNI_RUC`,`Fecha_Activacion`,`Fecha_Venta`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbEstado_Control_Economico` (

`DNI` varchar(11) NOT NULL,

`Fecha_Venta` date NOT NULL,

`Fecha_Activacion` date NOT NULL,

`Fecha_Entrega_Documento` date DEFAULT NULL,

`Fecha_Entrega_CDR` date DEFAULT NULL,

`Fecha_Obs1` date DEFAULT NULL,

98
 `Fecha_Obs2` date DEFAULT NULL,

`Fecha_Obs3` date DEFAULT NULL,

`Observaciones` text,

`Estado` varchar(20) DEFAULT NULL,

PRIMARY KEY (`DNI`,`Fecha_Venta`,`Fecha_Activacion`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbExperto_Postpago` (

`DNI_RUC` varchar(50) NOT NULL,

`Fecha_Vta` date NOT NULL,

`Fecha` date NOT NULL,

`Experto` varchar(50) NOT NULL,

PRIMARY KEY (`DNI_RUC`,`Fecha_Vta`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbGuia_postpago` (

`DNI_RUC` varchar(50) NOT NULL,

`Fecha_Venta` date NOT NULL,

`Guia` varchar(1000) DEFAULT NULL,

`Estado` varchar(50) DEFAULT NULL,

PRIMARY KEY (`DNI_RUC`,`Fecha_Venta`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbIngreso_Chips` (

`ICC` varchar(19) NOT NULL,

`Fecha` date NOT NULL,

`Guia` varchar(50) NOT NULL,

`Factura` varchar(50) NOT NULL,

`Caja` varchar(100) NOT NULL,

99
 PRIMARY KEY (`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbIngreso_Producto` (

`IMEI` varchar(15) NOT NULL,

`Fecha` date NOT NULL,

`Guia` varchar(20) NOT NULL,

`Factura` varchar(20) NOT NULL,

PRIMARY KEY (`IMEI`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbLista_Ventas_Prepago` (

`IMEI` varchar(15) NOT NULL,

`ICC` varchar(19) NOT NULL,

`Modelo` text NOT NULL,

`Tipo_Chip` text NOT NULL,

`Plan` text NOT NULL,

`Monto` decimal(10,2) NOT NULL,

`Fecha` date NOT NULL,

`DNI_RUC` varchar(11) NOT NULL,

`ID_Vendedor` varchar(8) NOT NULL,

`ID_Local` varchar(100) NOT NULL,

`Estado` text,

PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AVG_ROW_LENGTH=148;

CREATE TABLE `TbMarca` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

100
 `Marca` text NOT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=507 DEFAULT CHARSET=latin1;

CREATE TABLE `TbObservaciones` (

`DNI` varchar(50) NOT NULL,

`Fecha` date NOT NULL,

`Observacion` text,

PRIMARY KEY (`DNI`,`Fecha`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AVG_ROW_LENGTH=51;

CREATE TABLE `TbPago_Caja` (

`DNI_RUC` varchar(11) NOT NULL,

`Fecha` date NOT NULL,

`Plan` text NOT NULL,

`Monto_Total` decimal(10,2) NOT NULL,

`ID_Punto_Venta` varchar(100) NOT NULL,

`ID_Vendedor` varchar(100) NOT NULL,

`Estado` varchar(50) NOT NULL DEFAULT ' ',

PRIMARY KEY (`DNI_RUC`,`Fecha`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbPago_Caja_Postpago` (

`DNI_RUC` varchar(50) NOT NULL,

`Fecha` date NOT NULL,

`Plan` text NOT NULL,

`Monto_Total` decimal(10,2) NOT NULL,

`ID_Punto_Venta` varchar(50) NOT NULL,

101
`ID_Vendedor` varchar(50) NOT NULL,

`Estado` text NOT NULL,

PRIMARY KEY (`DNI_RUC`,`Fecha`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbPersonal` (

`DNI` varchar(8) NOT NULL,

`Nombre_Apellido` text NOT NULL,

`Direccion` text NOT NULL,

`ID_Departamento` int(11) NOT NULL,

`ID_Provincia` int(11) NOT NULL,

`ID_Distrito` int(11) NOT NULL,

`Correo` text,

`Celular` varchar(20) DEFAULT NULL,

`RPM` varchar(20) DEFAULT NULL,

`ID_Ubicacion` int(11) NOT NULL,

`Puesto` varchar(50) DEFAULT NULL,

`Contrato` varchar(50) DEFAULT NULL,

`Destaque` varchar(50) DEFAULT NULL,

PRIMARY KEY (`DNI`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbPlan` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

`ID_Marca` bigint(20) NOT NULL,

`Plan` text NOT NULL,

`Tipo` varchar(50) DEFAULT NULL,

`Costo` decimal(10,2) NOT NULL,

102
 `Tipo_Plan` varchar(50) DEFAULT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=11716 DEFAULT CHARSET=latin1;

CREATE TABLE `TbProducto` (

`IMEI` varchar(15) NOT NULL,

`ID_Marca` bigint(20) NOT NULL,

`ID_Ubicacion` varchar(10) NOT NULL,

`IDSub_Ubicacion` bigint(20) NOT NULL,

PRIMARY KEY (`IMEI`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbProvincia` (

`ID` int(11) NOT NULL,

`ID_Departamento` int(11) NOT NULL,

`Provincia` text NOT NULL,

PRIMARY KEY (`ID`,`ID_Departamento`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbPuesto` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

`Puesto` varchar(50) DEFAULT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=17 DEFAULT CHARSET=latin1;

CREATE TABLE `TbTipo_Chip` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

`Tipo` text NOT NULL,

103
 PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=latin1;

CREATE TABLE `TbTipo_Contrato` (

`ID` bigint(20) NOT NULL AUTO_INCREMENT,

`Tipo` varchar(50) DEFAULT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=latin1;

INSERT INTO `TbTipo_Contrato` (`ID`, `Tipo`) VALUES (1,'Planilla'),(2,'Media

Planilla'),(3,'Libre'),(4,'Junior');

CREATE TABLE `TbTipo_Venta` (

`DNI` varchar(50) NOT NULL,

`Fecha` date NOT NULL,

`Tipo_Venta` text NOT NULL,

PRIMARY KEY (`DNI`,`Fecha`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbTrabajo_PostPago` (

`DNI_RUC` varchar(50) NOT NULL,

`Centro_Laboral` text NOT NULL,

`RUC` varchar(11) DEFAULT NULL,

`Telef_Laboral` int(11) NOT NULL,

`Puesto` text,

`Salario` decimal(10,2) DEFAULT NULL,

PRIMARY KEY (`DNI_RUC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

104
CREATE TABLE `TbUbicacion` (

`ID` int(11) NOT NULL AUTO_INCREMENT,

`Punto_Venta` text NOT NULL,

`Sigla` text NOT NULL,

PRIMARY KEY (`ID`)

) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=latin1;

CREATE TABLE `TbUsuarios` (

`DNI` varchar(8) NOT NULL,

`Usuario` text NOT NULL,

`Password` text NOT NULL,

`Cambio` int(1) NOT NULL,

PRIMARY KEY (`DNI`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbVentas_Postpago_Realizadas` (

`IMEI` varchar(50) NOT NULL,

`ICC` varchar(50) NOT NULL,

`Modelo` text NOT NULL,

`Tipo_Chip` varchar(50) NOT NULL,

`Plan` text NOT NULL,

`Monto` decimal(10,2) NOT NULL,

`Cargo_Fijo` decimal(15,2) DEFAULT NULL,

`Fecha_Venta` date NOT NULL,

`DNI_RUC` varchar(50) NOT NULL,

`ID_Vendedor` varchar(50) NOT NULL,

`ID_Local_Venta` varchar(50) NOT NULL,

`Fecha_Pago` date NOT NULL,

105
 `ID_Local_Pago` varchar(50) NOT NULL,

`ID_Cobrador` varchar(50) NOT NULL,

`Boleta_Factura` text NOT NULL,

PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AVG_ROW_LENGTH=164;

CREATE TABLE `TbVentas_Prepago_Realizadas` (

`IMEI` varchar(50) NOT NULL,

`ICC` varchar(50) NOT NULL,

`Modelo` text NOT NULL,

`Tipo_Chip` text NOT NULL,

`Plan` text NOT NULL,

`Monto` decimal(10,2) NOT NULL,

`Fecha_Venta` date NOT NULL,

`DNI_RUC` varchar(50) NOT NULL,

`ID_Vendedor` varchar(50) NOT NULL,

`ID_Local_Venta` varchar(50) NOT NULL,

`Fecha_Pago` date NOT NULL,

`Local_Pago` varchar(50) NOT NULL,

`ID_Cobrador` varchar(50) NOT NULL,

`Boleta_Factura` text NOT NULL,

PRIMARY KEY (`IMEI`,`ICC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbCliente_Postpago` (

`DNI_RUC` varchar(50) NOT NULL,

`Cliente` text NOT NULL,

`Fecha_Nac` date DEFAULT '1981-09-06',

106
 `Direccion` text NOT NULL,

`Estado_Civil` varchar(20) DEFAULT NULL,

`Sexo` varchar(20) DEFAULT NULL,

`ID_Departamento` varchar(50) NOT NULL,

`ID_Provincia` varchar(50) NOT NULL,

`ID_Distrito` varchar(50) NOT NULL,

`Ref_Domiciliaria` text NOT NULL,

`Ref_Telef` varchar(50) NOT NULL,

`Correo` text NOT NULL,

`DNI_Rep` varchar(50) DEFAULT NULL,

`Representante` text,

PRIMARY KEY (`DNI_RUC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `TbCliente_Prepago` (

`DNI_RUC` varchar(11) NOT NULL,

`Cliente` text NOT NULL,

`Direccion` text NOT NULL,

`ID_Departamento` int(11) NOT NULL,

`ID_Provincia` int(11) NOT NULL,

`ID_Distrito` int(11) NOT NULL,

PRIMARY KEY (`DNI_RUC`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

107