Sistema de Monitoreo de Empresa de Transporte Terrestre

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO – CHILE
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
Sistema de Monitoreo para

Empresa de Transporte Terrestre
GUSTAVO RENE CISTERNAS SILVA
INFORME FINAL DEL PROYECTO

PARA OPTAR AL TÍTULO PROFESIONAL DE
INGENIERO DE EJECUCIÓN EN INFORMÁTICA
Julio, 2009.
i
Pontificia Universidad Católica de Valparaíso – Chile
Facultad de Ingeniería
Escuela de Ingeniería Informática
Sistema de Monitoreo para

Empresa de Transporte Terrestre
Gustavo Rene Cisternas Silva
Profesor Guía: José Miguel Rubio León
Carrera: Ingeniería de Ejecución en Informática
Julio, 2009.
ii
Sistema de Monitoreo para Empresa de Transporte Terrestre
Dedicatoria
Dedicado a mis Padres..

Quienes me apoyaron durante este largo camino
En los buenos y malos momentos,
Que llevaron como fruto este logro.
i
Agradecimientos
A mi familia, mis amigos, mis profesores, y a todos aquellos que me acompañaron en estos años repletos de
esfuerzo, alegría y crecimiento.
ii
Resumen
Un Sistema Web, amplia las fronteras de operar, automatizar y gestionar
información vinculada directamente en el lugar donde sea implementada.
La finalidad de esta tesis es implementar el análisis y diseño del seguimiento y

control del flujo del trabajo de Título asociado a las información de una empresa, los
inconvenientes que estas poseen y como se pretenden solucionar.
Estableciendo un plan de trabajo enfocado en una mejora de procesos, una

arquitectura adecuada y tecnologías que mas se acomoden al trabajo de título. También
detalla todo el desarrollo del trabajo de título, casos de uso y los distintos diagramas.
Culminado con interfaces explicativas para el mejor entendimiento del sistema.
Abstract
A Web System, extends the boundaries to operate, automate and manage information
related directly to the place where it is implemented.
The purpose of this thesis is to implement the analysis and design of monitoring and
control project workflow associated with business information, the disadvantages that
these magazines and as trying to solve.
Establishing a work plan focused on improved processes and technologies, an architecture

that best accommodate the project. It also details the entire development project, use cases
and other diagrams. Culminated with explanatory interfaces for better understanding of the
system.
iii
Resumen y Abstract…………………………………………………………….. iii

Listado de Figuras…………………………………………………………….… viii
Listado de Tablas……………………………………………………………….. x
1 Introducción………………………………………...…………………………… 1
2 Definición de Objetivos…………………………………………………………. 2
2.1 Objetivo General…………………………………………………………… 2
2.1 Objetivos Específicos………………………………………………….…… 2
2.3 Mejoras Esperadas…………………………………………………………. 2
3 Metodología………………………………………….………………………….. 3
4 Plan De Trabajo……………………………………..……………………….…. 4
5 Estado Del Arte…………………………………………………………………. 6
5.1 Situación Actual…………………………………………………………… 6
5.1.1 Descripción de la empresa……………….……………….…………… 6
5.2.1 Usuarios……………….……………….……………….…………. 6
5.1.2.1 Clientes………………………………………………………………………… 7
5.1.2.2 Administrador…………………………………………………….……………. 7
5.2 Flujo De Trabajo Actual…………………………………………………… 8
5.3 Diagrama De Actividades Flujo Actual De Trabajo………………………. 9
5.4 Problemas Identificados…………………………………………………… 10
6 Solución Propuesta….………………………………………………………….. 11
6.1 Análisis De Requerimientos………………………………………………. 11
6.2 Módulos Del Sistema……………………………………………………… 12
6.3 Requerimientos Funcionales……………………………………………… 13
6.4 Requerimientos No Funcionales 15
6.5 Solución Propuesta con Sistema Automatizado
Descentralizado……………………………………………………………. 16
7 Desarrollo…………………………………………….………………………….. 18
7.1 Estudio De Factibilidad…………………………………………………… 18
7.2 Factibilidad Operacional………………………………………………….. 18
7.2.1 Factibilidad Técnica……………….……………….……………….. 18
7.2.2 Factibilidad Legal……………….……………….……………….…. 19
7.2.3 Factibilidad Económica……………….……………….…………….. 19
7.2.4 Inversión Inicial……………….……………….…………………….. 19
7.2.5 Costos operacionales……………….……………….……………….. 20
7.2.6 Costos de capacitación……………….……………….……………... 20
7.2.7 Costos de Mantención……………….……………….………………. 20
7.2.8 Beneficios Anuales……………….……………….……………….…. 20
7.2.9 Total beneficios de operación……………….……………….……… 20
7.2.10 Conclusión Estudio De Factibilidad……………….………………… 21
7.3 Análisis De Riesgo………………………………………………..……….. 22
7.3.1 Identificación de riesgos y análisis de riesgos……………………... 22
7.3.2 Planeación de riesgos……………….……………….……………... 22
iv
7.3.3 Paradigma De Desarrollo……………….…………………………. 24

7.3.4 Fases de Ciclo de Vida en Cascada……………….……………….. 25
7.3.5 Ciclo de vida Clásico con 2 Fases complementarias………………. 26
8 Metodologías De Desarrollo……………………………………….…………… 28
8.1 Herramientas Y Tecnologías De Desarrollo……………………………… 29
8.1.1 Herramientas……………….……………….…………………… 29
8.1.2 Herramienta De Modelado……………….……………….……… 30
8.2 Tecnologías……………………………………………………………….. 31
8.2.1 Motor De Base De Datos……………….……………….……….. 31
8.2.2 SQL Como Lenguaje……………….……………….……………. 31
8.2.3 Lenguaje De Programación ASP……………….………………… 32
8.2.4 Jquery……………….……………….……………….…………… 32
8.2.5 Ajax……………….……………….……………….……………... 33
8.2.6 Lenguaje De Programación Visual Basic .Net…………………… 33
8.2.7 Visual Studio .Net……………….……………….……………….. 34
8.2.8 J2ME……………….……………….……………….…………… 34
8.2.9 Mobile Web Development……………….……………….………. 35
8.2.10 IIS y Active Sync……………….……………….………………… 35
8.3 Arquitectura………………………………………………………………. 36
8.3.1 Introducción a los Servicios Web…………………………………. 36
8.3.2 Definición De Servicio Web……………….……………….……... 36
8.3.3 Arquitectura Orientada A Servicios 1…………………………….. 37
8.3.4 Arquitectura orientada a Servicios 2……………………………... 37
8.3.5 Tecnologías Usadas……………….……………….……………... 38
8.3.6 Arquitectura Física de los Servicios Web………………………… 38
8.3.7 Introducción a los Servicios Cliente Servidor……………………. 39
8.3.8 Definición de servicio Cliente Servidor…………………………... 39
8.3.9 Arquitectura De La Aplicación Central……………….…………. 40
8.3.10 Arquitectura Física……………….……………….……………… 40
9 Análisis Del Sistema…………………………………………………………….. 42
9.1 Diagrama De Casos De Uso De Contexto General………………………. 42
9.2 Diagrama Caso De Uso Gestionar Expedición…………………………… 43
9.3 Diagrama Caso De Uso Gestionar OT……………………………………. 44
9.4 Diagrama Caso De Uso Consultar Cartola De Movimientos……………... 45
9.5 Diagrama Caso De Uso Consultar Cotización……………………………. 46
9.6 Diagrama Caso De Uso Consultar Estado De Documentos………………. 47
9.7 Diagrama Caso De Uso Gestionar Servicios De Encomienda……………. 48
9.8 Diagrama Caso De Uso Gestionar Clientes………………………………. 49
9.9 Diagrama Caso De Uso Gestionar Call Center…………………………. 50
9.10 Diagrama Caso De Uso Gestionar Usuario…………………………….. 51
9.11 Diagrama Caso De Uso Login…………………….……………………. 52
9.12 Casos De Uso Explicación Formal…………...………………………… 53
v
10 Diagrama De Secuencias……………………………………………….……… 72
10.1 Ingresar Cliente………………………………………………………… 72
10.2 Modificar Cliente………………………………………………………. 73
10.3 Eliminar Cliente………………………………………………………… 74
10.4 Consultar Cliente……………………………………………………….. 75
10.5 Ingresar OT……………………………………………………………... 76
10.6 Modificar OT…………………………………………………………… 77
10.7 Anular OT……………………………………………………………… 78
10.8 Login…………………………………………………………………… 79
10.9 Consultar Estado de Documentos……………………………………… 80
10.10 Ingresar Expedición…………………………………………………… 81
10.11 Anular Expedición……………………………………………………… 82
10.12 Modificar Expedición…………………………………………………… 83
10.13 Consultar Cotización……………………………………………………. 84
11 Diagramas De Actividad Flujo Futuro De Trabajo…………………………... 85
11.1 Flujo Futuro General…………………………………………………… 85
11.2 Flujo Futuro Ingresar Expedición………………………………………. 86
11.3 Flujo Futuro Ingresar Orden de Transporte…………………………….. 87
11.4 Flujo Futuro Consultar Cotización…………………………………….. 88
12 Diseño……………………………………………………………………………. 89
12.1 Modelo Del Dominio…………………………………………………… 89
12.2 Modelo Conceptual De Clases………………………………………….. 90
12.3 Modelo Entidad Relación…………………….…………………………. 91
12.4 Diseño De Interfaces……………….………….…….………………….. 92
12.4.1 Pagina Principal……………….…………….….……………….…… 93
12.4.2 Login……………….……………….……….……….……………….. 94
12.4.3 Menú principal……………………….……………….………………. 95
12.4.4 Periodo……………….……………….……………….……………… 96
12.4.5 Modulo de Call Center……………….……………….………………. 97
12.4.6 Modulo Usuario……………….……………….……………….…….. 98
12.4.7 Modulo Vehiculo……………….……………….……………….……. 99
12.4.8 Módulo Expedición……………….……………….……………….…. 100
12.4.9 Módulo de Orden de Transporte……………….……………….…….. 101
12.4.10 Módulo Estados de Documentos……………….……………….…… 102
12.4.11 Acceso Restringido……………….……………….………………….. 103
12.4.12 Vista Palm Menú de Utilidades……………….……………….……... 104
12.4.13 Búsqueda de Expedición Palm……………….……………….……… 105
12.4.13 Consulta de Expedición……………….……………….…………… 106
13 Plan De Pruebas……………….……………….……………….………………. 107
13.1 Prueba de unidades……………….……………….……………….……. 108
13.2 Prueba de integración……………….……………….………………….. 109
13.3 Prueba Basada En Hilos……………….……………….……………….. 110
vi
13.4 Prueba Basada En Usos……………….……………….……………….. 111

13.5 Prueba De Sistema……………….……………….……………….……. 112
13.6 Prueba De Recuperación……………….……………….………………. 113
13.7 Prueba De Seguridad……………….……………….…………………... 114
13.8 Prueba De Rendimiento……………….……………….……………….. 115
13.9 Prueba de aceptación. ……………….……………….…………………. 116
13.9.1 Caja blanca……………….……………….……………….…………. 116
13.9.2 Caja negra. ……………….……………….……………….…………. 116
13.10 Plan de Pruebas. ……………….……………….……………….……… 118
14 Conclusiones y Trabajo Futuro………….……………….………………….. 119
15 Referencias……………….……………….……………….……………….……. 120
16 Anexo….…………….……………….……………….……………….…………. 121
16.1 Entrevista……………….……………….……………….……………… 121
16.2 Detalle de la entrevista……………….……………….………………… 121
16.2.1 Desventajas……………….……………….……………….………… 121
16.2.2 Ventajas……………….……………….……………….……………. 122
16.2.3 Conclusión de la entrevista……………….……………….………… 122
16.3 Glosario……………….……………….……………….………………. 123
16.4 Diagrama Caso De Uso General Detallado……………….…………… 124
vii
Lista de Figuras
Figura 5.1 Diagrama de Actividades actual de Trabajo. 9

Figura 7.1 Ciclo de Vida en Cascada 25
Figura 7.2 Ciclo de Vida Clásico con 2 Fases complementarias 26
Figura 8.1 Plataforma informática de .NET 33
Figura 8.2 Arquitectura Orientada a Servicios 1 37
Figura 8.3 Arquitectura Orientada a Servicios 2 37
Figura 8.4 Arquitectura Física Orientada a Web Services 38
Figura 8.5 Arquitectura de la Aplicación Central. 40
Figura 8.6 Diagrama de implementación del Sistema Central 41
Figura 9.1 Diagrama De Casos De Uso De Contexto General 42
Figura 9.2 Diagrama Caso De Uso Gestionar Expedición 43
Figura 9.3 Diagrama Caso De Uso Gestionar OT 44
Figura 9.4 Diagrama Caso De Uso Consultar Cartola de Movimientos 45
Figura 9.5 Diagrama Caso De Uso Consultar Cotización 46
Figura 9.6 Diagrama Caso De Uso Consultar Estado De Documentos 47
Figura 9.7 Diagrama Caso De Uso Gestionar Servicios De Encomienda 48
Figura 9.8 Diagrama Caso De Uso Gestionar Clientes 49
Figura 9.9 Diagrama Caso De Uso Gestionar Call Center 50
Figura 9.10 Diagrama Caso De Uso Gestionar Usuario 51
Figura 9.11 Diagrama Caso De Uso Login 52
Figura 10.1 Diagrama de Secuencia Ingreso de Cliente 72
Figura 10.2 Diagrama de Secuencia Modificar de Cliente 73
Figura 10.3 Diagrama de Secuencia Eliminar de Cliente 74
Figura 10.4 Diagrama de Secuencia Consultar de Cliente 75
Figura 10.5 Diagrama de Secuencia Ingreso OT 76
Figura 10.6 Diagrama de Secuencia Modificar OT 77
Figura 10.7 Diagrama de Secuencia Anular OT 78
Figura 10.8 Diagrama de Secuencia Login 79
Figura 10.9 Diagrama de Secuencia Consultar Estado de Documentos 80
Figura 10.10 Diagrama de Secuencia Ingresar Expedición 81
Figura 10.11 Diagrama de Secuencia Anular Expedición 82
Figura 10.12 Diagrama de Secuencia Modificar Expedición 83
Figura 10.13 Diagrama de Secuencia Consultar Cotización 84
Figura 11.1 Diagrama de Actividades Flujo Futuro General 85
Figura 11.2 Diagrama de Actividades Flujo Futuro Ingresar Expedición 86
Figura 11.2 Diagrama de Actividades Flujo Futuro Ingresar Orden de Transporte 87
Figura 11.3 Diagrama de Actividades Flujo Futuro Consultar Cotización 88
Figura 12.1 Diagrama de Diseño Modelo Del Dominio 89
Figura 12.2 Diagrama de Diseño Modelo Conceptual De Clases 90
Figura 12.3 Diagrama de Diseño Modelo Entidad Relación 91
Figura 12.4 Diseño Pagina Principal 93
Figura 12.5 Diseño Login 94
Figura 12.6 Diseño Menú Principal 95
viii
Figura 12.7 Diseño Periodo 96

Figura 12.8 Módulo Call Center 97
Figura 12.9 Módulo Edición Call Center 97
Figura 12.10 Módulo Usuario 98
Figura 12.11 Módulo Edición Usuario 98
Figura 12.12 Módulo Vehiculo 99
Figura 12.13 Módulo Edición Vehiculo 99
Figura 12.14 Módulo Expedición 100
Figura 12.15 Módulo Edición Expedición 100
Figura 12.16 Módulo Orden de Transporte 101
Figura 12.17 Módulo Edición Orden de Transporte 101
Figura 12.18 Módulo Estados de Documentos 102
Figura 12.19 Acceso Restringido 103
Figura 12.20 Menú Utilidades Palm 104
Figura 12.21 Búsqueda de Expedición Palm 105
Figura 12.22 Consulta de Expedición Palm 106
Figura 16.1 Diagrama Caso De Uso General Detallado 124
ix
Lista de Tablas
Tabla 4.1 Actividades del Plan de Trabajo 4
Tabla 5.1 Cuadro de resumen de Actores y su Interacción con el Sistema 7
Tabla 6.1 Módulos del Sistema 12
Tabla 6.2 Requerimientos Funcionales del Sistema 13
Tabla 6.3 Requerimientos No Funcionales de Sistema 15
Tabla 7.1 Identificación de Riesgos 22
Tabla 7.2 Planeación de Riesgos 24
Tabla 8.1 Propuesta requerimientos para funcionamiento 40
Tabla 15.1 Plan de Pruebas 118
Tabla 18.1 Glosario 123
x
1 Introducción
El resultado de esta tesis es presentar la información del análisis, estudio de
requerimientos, diseño, codificación y pruebas que es llevado a cabo para desarrollar el
trabajo de título denominado “Sistema de Monitoreo para Empresa de Transporte
Terrestre”, destinado a la empresa de encomiendas Fletser Ltda, con cobertura en la
Región de Valparaíso y Metropolitana, el cual posee solamente un sistema instalado y
funcionando de manera local directamente en la empresa destinado al uso de los
funcionarios para la gestión de los servicios ofrecidos y las tareas administrativas.
En estos momentos, en entrevistas con la actual Empresa para conocer las reglas del
negocio y la lógica de funcionamiento, es necesario incluir un sistema de monitoreo para el
cliente que contrata un servicio de transporte para agilizar los tiempos de consulta y liberar
en un alto porcentaje de las operaciones diarias que se realizan en la Empresa y por otro
lado, mejorar las transacciones internas como la gestión de los servicios ofrecidos.
Se busca implementar sistemas de búsquedas de paquetes según sus características

(cajas, palets, tamaño, peso, volumen, etc.) mediante códigos asignados internamente por
la Empresa, en este caso llamados ordenes internas (OT), conocer la ubicación del envío,
saber el estado de entrega y su recepción final. Además, incluir la cotización de servicios
de transportes de acuerdo a las necesidades del cliente, conocer los atributos del servicio
como los puntos de contacto, información de la Empresa, condiciones de pago, precios
especiales, coberturas, etc. Con esto se logra desvincular, como ya antes mencionado, a la
Empresa de esta constante tarea que incurre un alto costo en tiempo de atención a clientes
y separar las operaciones generales de las de alta importancia como lo son en algunos
casos clientes exclusivos o aquellos casos que sean necesarios de una atención
personalizada.
En los próximos puntos de este documento, se presenta la definición del objetivo general y
específicos de este trabajo de título, para luego dar lugar a la descripción del
funcionamiento actual de la empresa, dar a entender el problema y cómo se soluciona más
detalladamente, para ello se muestran las vistas preliminares del sistema, tanto para el
dispositivo móvil como para el sistema central y las configuraciones realizadas en el
sistema.
1
2 Definición de Objetivos
2.1 Objetivo General

Desarrollar un sistema de monitoreo de encomiendas que permita el seguimiento de
paquetes de diferentes dimensiones y tonelajes, utilizando servicios Web.
2.2 Objetivos Específicos
• Agilizar la mantención de la información de los servicios que se realizan entorno a

los clientes vinculados al sistema, esto es relacionado al control de ingreso,
mantención o modificación de sus cuentas e información.
• Mejorar el control de las expediciones por parte de los usuarios sobre el o los
estados de estos que estos puedan tener durante el proceso de gestión.
• Incrementar los tiempos de ejecución de los procesos más críticos del sistema que
tienen vinculación con las funcionalidades directas con el usuario.
• Generar un Prototipo de Consulta de Información destinado al cliente para conocer

el estado de sus servicios contratados, a través de un dispositivo móvil con servicios
Web.
2.3 Mejoras Esperadas
• Agilizar los tiempos de respuesta en los servicios destinados a la atención directa al

cliente sin desligar el trato ni la responsabilidad sobre ellos.
• Generar un producto que ofrezca servicio que distinga la empresa sobre las demás.
• Establecer puntos de control sobre los envíos para generar estadísticas de las
operaciones internas.
• Establecer un control de calidad de los procesos generados por parte de la empresa.
• Dirigir los esfuerzos hacia otras áreas no abarcadas completamente.
2
3 Metodología
Para el desarrollo del trabajo de título es de vital importancia incorporar un
método de trabajo para la mejora del proceso. Las principales estrategias o
metodologías para enfrentar cada tarea del proceso de análisis de sistemas, se pueden
agrupar en tres grandes categorías:
• Análisis Clásico
• Análisis Estructurado
• Análisis Orientado a Objetos
Se ha evaluado estas tres alternativas llegando a la conclusión de que por

conveniencia es optimo utilizar la metodología de Orientación a Objetos ya que
presenta una serie de características tales como facilidad de comprensión por parte del
cliente y desarrollador y rapidez en el desarrollo, la posibilidad de reutilización y la
posibilidad de adaptar la metodología al paradigma escogido que será cascada clásica,
profundizaremos en el paradigma escogido en los siguientes puntos del presente
documento.
Se especifican a continuación los ítems a tratar a lo largo del trabajo de título:
• Estudio de los procesos internos y externos realizados por parte de la empresa

de transporte terrestre, y rescatar aquellos en los cuales se pueden implementar
mejoras, identificando especialmente aquellas con problemas.
• Generar un recopilación de los estudios anteriores, agrupándolos de acuerdo su

importancia a mejorar, y verificar el impacto que tendrá a corto y largo plazo
dentro de la empresa.
• Identificar las pretensiones del trabajo de título que espera lograr directamente
con la implementación de una herramienta Web como apoyo a los servicios de
su empresa.
• Dado la generalidad del área de trabajo, se complementa junto con el cliente las
distintas alternativas que se pueden generar durante un proceso productivo
dentro de la empresa y canalizarlo de manera similar como un servicio
destinado a los usuarios.
• Del punto anterior, se desprende la toma de requerimientos funcionales y no

funcionales detalladamente como la percepción del flujo de trabajo dentro de la
empresa.
Una vez completado estos puntos, se puede dar por sentado una base para definir el
comportamiento y características del sistema de transporte terrestre a analizar y
desarrollar.
3
4 Plan De Trabajo
La esencia del plan de trabajo es definir paso a paso apoyado gráficamente,
representando las actividades del trabajo de título a realizar. La efectividad de un plan de
trabajo se ve reflejado en la coordinación del equipo de trabajo y sus actividades de manera
tal, generar procesos de que terminen en un producto de calidad.
En base a lo anterior, se apoya la gestión de acuerdo a las fases mencionadas, que

son el ciclo de vida en Cascada, incurriendo en las etapas de análisis y diseño, para
recopilar todo requerimiento que se pueda desprender por parte del cliente. Estos
requerimientos son refinados respecto a las primeras etapas del ciclo de vida en cascada,
como son el análisis del proceso, introducción del cambio e identificación de los procesos
de mejoramiento.
Actividad Periodo
Proyecto I
Análisis de Requerimientos Julio - Agosto 2008
Establecer requerimientos del prototipo Septiembre - Octubre 2008
Diseño del prototipo Noviembre - Diciembre 2008

Proyecto II
Mejoras al Diseño Febrero 2009
Codificación y Pruebas Enero - Abril 2009

Integración Mayo - Junio 2009
Tabla 4.1 Actividades del Plan de Trabajo
Cada actividad del plan de trabajo es descrita de la siguiente manera:
1 Análisis de Requerimientos
El principal objetivo de esta etapa será conocer las ventajas y desventajas de cada una de
las necesidades del trabajo de título, además de otros aspectos que influyan en la
automatización, con el propósito de seleccionar en una etapa posterior, aquellas que
puedan servir de mejor forma al logro de los objetivos planteados. Además de recopilar
toda la información necesaria para enfocar la dirección que debe tomar el trabajo de título
para llegar a una herramienta de calidad.
2 Establecer los requerimientos del prototipo
Dentro de esta etapa se realizará el análisis de la herramienta, cuyos requerimientos serán

definidos en base a las necesidades requeridas por parte del sistema.
4
3 Diseño del prototipo
En esta etapa se analizan los alcances y el funcionamiento que va a poseer el prototipo,

como una especificación de los resultados obtenidos en la toma de requerimientos. El
primer acercamiento al diseño corresponde a la última etapa realizada en Proyecto I.
4 Mejoras al diseño
En esta etapa se realiza una revisión del trabajo correspondiente a Proyecto I y se da

comienzo a la segunda etapa (correspondiente al desarrollo del prototipo) perteneciente a
Proyecto II.
5 Codificación y Pruebas
Esta etapa comprende la codificación utilizando las herramientas definidas previamente en

la toma de requerimientos. Mientras se realiza esta actividad, se lleva a cabo el plan de
pruebas estipulada para el prototipo.
6 Actividad Práctica
En esta etapa se espera utilizar el prototipo sobre una actividad práctica, con el fin de
obtener resultados que permitan evaluar la utilidad de la herramienta.
5
5 Estado Del Arte

El trabajo de título esta destinado a resolver los problemas que la empresa presenta en
la actualidad como es el hecho de la excesiva documentación que se genera, tiempos de
respuesta para los clientes demasiado largos y la centralización de la información entre
otros. Para esto, se incluye la utilización de herramientas de desarrollo accesibles para el
trabajo de título, que se adapten a las necesidades del sistema como son la implementación
de las funcionalidades a través de la Web y dispositivos móviles por medio de
Webservices. Por otra parte, desde el puno de vista de análisis y diseño se utiliza UML
para identificar los casos de uso como funcionalidades principales del sistema y exponerlas
al cliente para un mejor entendimiento e integración en el trabajo de título.
5.1 Situación Actual
5.1.1 Descripción de la empresa

La empresa en su actualidad posee un sistema local en intranet cuyas funcionalidades
en la actualidad presentan limitaciones en el control y manejo de los servicios activados de
la empresa, relacionado netamente con las transacciones relacionadas al transporte, en este
punto, el cliente juega un rol importante en los tiempos de respuesta a la información
requerida, ya sean facturas, ordenes de transporte (OT), clasificación y cotización de envió
y retiro de productos, tarifado de acuerdo a peso, dimensiones, tipo, etc.
Hoy en día, el personal asignado a las tareas de gestión de trasporte, comparten las
tareas de generación de ordenes de transporte, asignación de expediciones, rutas de las
expediciones, ordenes de transportes internas, facturación, rendición de pagos por clientes,
etc.
Junto con esto, el servicio directo a clientes dificulta los procesos mencionados
anteriormente, generando desorden en los servicios y reclamos los cuales con el tiempo se
han ido incrementando paulatinamente llegando a ser casi inmanejables.
Por otro lado, la empresa al tener sucursales y para el manejo mismo de los productos
que tienen a su cargo, no existe control alguno con el personal, lo cual ocasiona muchas
veces la perdida de productos por el concepto de mermas y conlleva a generar
indemnizaciones a los clientes por el extravío de su mercadería, sumados a todo esto una
pésima imagen hacia el cliente por el servicio entregado.
5.1.2 Usuarios
Después de haber conversado con cada uno de los integrantes de la empresa, he
podido diferenciar tres roles:
• Clientes
• Administrador
6
5.1.2.1 Clientes
La manera por la cual los diferentes clientes se relacionan hoy en día con la empresa
es solo vía telefónica, no existe un medio más interactivo el cual puede él dar solución a
sus necesidades, lo que conlleva a un colapso generalizado de llamadas.
5.1.2.2 Administrador
Realiza la gestión misma del servicio de encomienda: Recibir la llamada del cliente
que gatilla la necesidad del servicio, asignar una orden de transporte o factura a dicha
solicitud, eliminar, modificar, consultar clientes, se encarga además del ingreso de los
documentos que identifican la entrega de un servicio con aquellos clientes que poseen un
contrato activo, para esto se utiliza documentos internos tales como las OTI.
Por otro lado, el administrador completa las expediciones y rutas de los camiones para
la entrega posterior del producto.
Por su parte se encarga de : gestionar principalmente de todas las áreas de la empresa,

generando atribuciones totales como por ejemplo tarifas, vehículos, aumentos y asignación
de línea de créditos a los clientes, generar la entrega de dineros para los movimientos de
los camiones para su posterior pago de peajes, romanas, estacionamientos, etc.
También tiene la misión de dar un patrón de soluciones a aquellos reclamos que se

generen de los clientes para su posterior aplicación.
Es el encargado de generar y absorber de acuerdo a la información existente los

diferentes informes de gestión e índices financieros que sirven mucho a la hora de toma de
decisiones.
Independiente que la persona con más conocimientos del negocio pueda realizar
todas las tareas, es necesaria dicha clasificación de roles, para así dividir el trabajo según
las capacidades y conocimientos sobre el negocio de los integrantes, como también, para
quitar carga de trabajo a quien realiza las tareas más críticas dentro de la organización.
A continuación se presenta un cuadro resumen de lo expuesto anteriormente:
Tabla 5.1 Cuadro de resumen de Actores y su Interacción con el Sistema

Actores Tipo Descripción
Persona que interactúa el sistema a nivel
Administrativo, puede gestionar Usuarios,
Gestionar funciones que no posee disponible
Administrador Principal otros usuarios. Gestiona o interactúa con la
información de los Expediciones (Ingresar,
Modificar y Consultar), Órdenes de Transporte y
generar informes.
Persona interesada en obtener servicios directos
con el negocio de transportes de encomiendas,
Cliente Principal
revisar documentación relacionada a su perfil y
consultar tarifas.
7
5.2 Flujo De Trabajo Actual

En la actualidad, la empresa posee un sistema local en intranet con un servidor que
centraliza toda la información. Cada vez que un Cliente se contacta con la Empresa para
contratar un servicio se debe genera la documentación respectiva, esto puede incluir
Ordenes de Transporte, facturas, etc.
Tras acumular una cantidad de servicios estos se agrupan en rutas especificas, y se

genera una expedición (servicio de encomienda) destinada a los diferentes sucursales que
posee la empresa. Cada expedición tiene asociada una serie de documentos que están
directamente vinculados a los clientes que son recepcionistas del servicio. Antes de llegar
una encomienda al cliente, la expedición debe pasar por las sucursales respectivas, donde
se disgregan las encomiendas de acuerdo a los sectores que en los cuales se debe realizar la
entrega. Luego se efectúan las rutas previamente asignadas en la Casa Matriz. Cada ves
que se realiza una expedición, se retornan con documentos con el fin de fiscalizar el
servicio y verificar que se realizó con éxito, es acá en el momento de fiscalizar, en que
aparecen dificultades puesto que la información no llega actualizada desde el momento que
se inicio el servicio hasta cuando termina.
Se debe mencionar además que cierto grupo de clientes tienen un trato especial, por
lo que se genera diferentes procesos comerciales, en estos momentos, existen 2 clientes
que requieren de esta caracterización que son aquellos que se les asigna una Orden de
Transporte Interna especial y las Empresas DIB.
En el caso de si un cliente quiere realizar consultas respecto a un servicio

contratado puede hacerlo telefónicamente o en persona, siendo esta última la menos
incurrida, por lo tanto entorpecen las tareas que se efectúan diariamente puesto que se
encuentran de manera continua digitando y constatando a los trabajadores que pertenecen a
la empresa y si cumplieron con sus labores.
En este aspecto, las funciones principales que se están considerando son desde el
tema comercial, existen otros procesos separados del los servicios actuales de la empresa,
que son tratados como externos, como son mantenciones de recursos, medios de transporte,
computacional, infraestructura, etc.
Hoy en día la empresa no posee ninguna tecnología Web, esto abarca una página en
línea, por lo tanto, un recurso como ese, no deja de ser menos importante como lo puede
ser otros que se prestan en la actualidad.
8
5.3 Diagrama De Actividades Flujo Actual De Trabajo
act Diagrama de activ idad General
Actor Sistema
Es cliente
Desaea Registrar Datos
Solicita Rut
Encargado Recibe
[NO] [NO]
solicitud de Servicio
FIN
[SI]
[SI]
Continuar Servicio Registrar
Cliente
[NO]
FIN [SI] Verificar
Estado
Consultar
Serv icio [SI] [NO]
Se Autoriza FIN
Generar Documento Expedicion Existe

Asociar a Generar
[SI] Expedición [NO] Expedición
[NO]
[SI]
Consultar T arifas
Verificar Existe Ruta
Asignar a
[SI] Tarifa
Expedicion
[NO]
Consultar [NO]
Documentos Enviar Expedición
[SI] Crear Ruta

Rev isar
Documentos
[SI]
Informar al Cliente
[NO]
FIN
[SI]
FIN DE FLUJO
Figura 5.1 Diagrama de Actividades actual de Trabajo.
Los documentos generados pueden ser Ordenes de Transportes, internas, Empresas Dib,
Facturas, etc.
9
5.4 Problemas Identificados

Se identificaron una serie de problemas en el momento de realizar el análisis de los
requerimientos traspasados por el cliente.
• Generación de documentación innecesaria hacia el cliente que en la actualidad no

son recibidos por su parte.
• Escaso control en las actividades o servicios de la empresa, especialmente aquellos

llamados expediciones, derivando en su deficiencia y desconfianza por parte del
cliente.
• Tiempos obsoletos en el momento de asistir las consultas de los clientes respectos

de servicios contratados.
• Centralización de la información alojada netamente en la Casa Matriz.
• Perdida de documentación que respalde los procesos efectuados por la empresa.
• Seguimiento de las expediciones y sus estados luego de finalizar el servicio al

momento de llegar la información a la Casa Matriz.
• Inexistencia de un sistema en línea externo que permita adquirir información

actualizada.
10
6 Solución Propuesta
6.1 Análisis De Requerimientos

Para el análisis de requerimientos se concertaron reuniones con el Gerente de
Administración para canalizar y recopilar toda la información necesaria para enfocar la
dirección que debe tomar el trabajo de título para llegar a una herramienta de calidad. Estás
reuniones se realizaron directamente en las instalaciones de la empresa para conocer su
infraestructura y servicios prestados.
De manera amplia se definen los requerimientos que el cliente y/o Empresa esperan
satisfacer:
• Control de Expediciones en terreno una vez comenzado el servicio y despachado a

las diferentes sucursales
• Mejorar el acceso a la información desde el punto de vista administrativo.
• Descentralizar la información que se encuentra localmente almacenada en la casa

matriz.
• Involucrar al cliente a través de nuevos servicios no existentes en la actualidad
• Mejorar los tiempos de espera por parte del cliente en la recopilación de la

información relacionada a él.
• Implementar un sistema de cotización en línea que no dependa directamente de la
gestión interna de la empresa y que entregue una herramienta automatizada al
cliente.
• Mejorar los procesos de control sobre las órdenes de transporte que hoy en día se
gestionan de manera local, telefónica y directamente con el personal.
Dado la implicancia de los diferentes requerimientos que presenta el cliente en estos

momentos, una modularidad del sistema es recomendable para abarcar la solución y
proyectar las actividades a futuro en el desarrollo de esta nueva herramienta.
11
6.2 Módulos Del Sistema

En este punto presentamos los módulos del sistema junto a la descripción de los mismos
bajo los puntos de distribución y logística:
Tabla 6.1 Módulos del Sistema

Módulo Descripción
Gestiona toda la información relacionada a una expedición como
Gestionar Expedición
son los tipos de órdenes de transporte.
Gestionar Orden de Gestiona las ordenes de transporte de los servicios de la empresa y
Transporte sus estados
Gestiona las solicitudes recibidas vía telefónica o Internet para un
Gestionar Call Center
servicio de la empresa.
Gestionar Usuarios Gestionar los usuarios asociados al sistema.
Corresponde a la gestión de los clientes que incurren en los servicios

Gestionar Clientes
de la empresa
Gestiona las consultas de los clientes para cotizar las tarifas de los
Consultar Cotización
servicios de encomienda que presta le empresa
Gestionar Servicios de Gestiona los servicios de las expediciones activas o aquellas que son
Encomiendas solicitados por parte del cliente
Consultar Cartola de Corresponde a las consulta dentro de un periodo determinado de los

Movimientos servicios y documentos asociado a un cliente.
Consultar Estado de Corresponde a las consultas de los clientes para verificar los estados
Documentos de documentos asociados a los servicios incurridos por su parte
12
6.3 Requerimientos Funcionales
Módulo Gestionar Expedición

Ref # Función Categorí
R1.1 Registrar una nueva Expedición en el sistema. Evidente
R1.2 Registrar el estado de una Expedición ya registrado. Evidente
R1.3 Almacenar permanentemente la expedición en el sistema. Oculta
R1.4 Controla las Órdenes de Transporte asociadas en el sistema. Evidente
Módulo Gestionar Orden de Transporte

R2.1 Registrar una nueva Orden de Transporte en el sistema. Evidente
R2.2 Registrar el estado de una Orden de Transponte ya registrado. Evidente
R2.3 Almacenar permanentemente una Orden de Transporte en el Oculta
R2.4 Controla las Órdenes de Transporte en el sistema. Evidente
Módulo Gestionar Call Center

R3.1 Registrar una nueva solicitud de servicio del cliente. Evidente
R3.2 Envía la solicitud registrada para efectuar el servicio Oculta
R3.3 Almacenar permanentemente la solicitud en el sistema. Oculta
R3.4 Controla las solicitudes de servicio en el sistema. Evidente
Módulo Gestionar Usuarios

Ref # Función Categoría
R4.1 Registrar una nueva ficha de usuarios en el sistema. Evidente
R4.2 Almacenar permanentemente los usuarios en el sistema. Oculta
Registrar modificaciones sobre información en la ficha de los usuarios Evidente
R4.3
en
R4.4 Consultar información relevante de los usuarios en el sistema. Evidente
Módulo Mantener Clientes

R5.1 Registrar una nueva ficha de clientes en el sistema. Evidente
R5.2 Almacenar permanentemente los clientes en el sistema. Oculta
Registrar modificaciones sobre información en la ficha de los clientes Evidente
R5.3
en
R5.4 Consultar información relevante de los socios en el sistema. Evidente
Módulo Consultar Tarifas

R6.1 Consultar un tarifado o cotización en base a información Evidente
proporcionada por el cliente
R6.2 Calcula una tarifado de acuerdo a parámetros fijados por la empresa. Oculta
R6.3 Entregar las tarifas mas adecuadas al cliente de acuerdo a la consulta. Evidente
13
Módulo Consultar Estado Documentos

R7.1 Consultar información relevante a los servicios incurridos por el Evidente
cliente.
Módulo Cartola de Movimientos
R8.1 Consultar información relevante del estado de pagos de los Evidente
documentos adquiridos por los servicios del cliente
Módulo Gestionar Servicios de Encomienda
R9.1 Registrar un servicio de encomienda por parte del cliente Evidente
R9.2 Almacenar permanentemente los registros en el sistema. Oculta
R9.3 Envía información sobre el servicio de encomienda el sistema. Oculta
R9.4 Consultar información relevante de los servicios solicitados por el Evidente
Tabla 6.2 Requerimientos Funcionales del Sistema
14
6.4 Requerimientos No Funcionales

En la siguiente tabla, se exponen los requisitos no funcionales del sistema, clasificados
como atributos con los cuales debe contar éste:
Tipo Descripción
Evitar errores en datos de entrada.
El sistema debe dar seguridad a los datos almacenados en el
Seguridad sentido de guardarlos y permitir su respaldo con el fin de
asegurar la integridad de estos.
Usabilidad El uso del Sistema ha de ser fácil de entender,

independientemente de la experiencia, conocimiento o nivel
de concentración del usuario.
Tiempos de respuesta rápida para consultas y obtención de

Rendimiento
información relacionada al negocio y para transacciones
Compatible con Sistema Operativo Microsoft Windows XP

y versiones posteriores.
Soporte Debe entregar ayuda sobre la forma de ser ocupado, en
caso de cualquier eventualidad, además de contar con un
manual de usuario.
Se consideran las licencias necesarias para el desarrollo, de
no ser así se espera contar con herramientas gratuitas.
Legales Todas las reglas de impuestos se tienen que aplicar,
por ley [3][4], durante las ventas.
Integración de las distintos módulos del Sistema, y es

Modularidad
posible la integración de nuevos módulos a futuro como el
sistema de GPS.
Tabla 6.3 Requerimientos No Funcionales de Sistema
15
6.5 Solución Propuesta con Sistema Automatizado

Descentralizado
Durante el análisis en los procesos internos de la empresa de transporte terrestre
(Fletser), se propuso la solución de controlar y gestionar procesos que dependen
íntegramente de la Casa Matriz, la solución propuesta permite agilizar y descentralizar
tareas internas mejorando el control de aquellas que son de suma importancia y base para
la empresa, puesto que el rubro en el que se desenvuelve este tipo de empresas es de una
amplio espectro, dejando diferentes propuestas para que cada una pueda destacarse sobre
las demás. No se debe descartar que existan empresas que llevan una trayectoria en el
transcurso del tiempo mucho mas larga que la empresa actual, pero la solución a implantar
ofrece un mejor servicio al que ya se esta efectuando y con miras a seguir mejorando. El
flujo futuro de los procesos que permitirán llevar a cabo la nueva ampliación de los
servicios se describe a continuación.
• Gestionar Expedición: una expedición corresponde al servicio prestado por la

empresa al cliente por el traslado de una encomienda. Empaqueta múltiples envíos
en un solo viaje, por lo tanto tiene asociado todas las órdenes de transporte
existentes, junto con la información asociada de la expedición.
• Gestionar Call Center: El call center permite registrar las solicitudes de algún
servicio de la empresa por parte del cliente, en este caso las encomiendas, para
luego ser integradas a una expedición.
• Gestionar Orden de Transporte: una orden de transporte es un documento que se

genera para gestionar un servicio de encomienda bajo el nombre de expedición, el
cual puede poseer diferentes rutas, esta orden de transporte se rige bajo un folio
único de numeración, asociado a una expedición, se debe mencionar que pueden
existir varias ordenes de transporte asociadas a una misma expedición, estas pueden
tener diferentes estados como Cancelado, Pendientes, en Transito y Entregado.
Además se especifica información adicional respecto del cliente y quien efectúa su
cancelación.
• Gestionar Usuarios: Los usuarios asociados al sistema deben ser asociados a sus
respectivas cuentas, con el tipo de cuenta correspondiente para trabajar con el
sistema. De acuerdo al tipo de cuenta establecida tendrán acceso a las diferentes
funcionalidades del sistema.
• Mantener Cliente: Dentro de la empresa, el cliente esta asociado al sistema en base

a datos bajo una categoría especial o clasificación que influye en el tipo de
descuentos que pueda recibir por algún tipo de servicio. Además de poseer la
facultad de disponer un crédito contable para contratar algún servicio de la empresa
antes de su cancelación, las estaciones de trabajo establecidas fuera de la casa
central solo tienen la facultad de ingresar o modificar los clientes, para la
eliminación de los clientes se necesita una solicitud de la casa matriz para realizar
este procedimiento.
16
• Generar Cotización: los clientes pueden acceder al sistema para realizar consultas
sobre tarifas y simular cotizaciones sobre el peso, cantidad, tamaño, etc., del tipo de
paquete o similar antes de incurrir en una solicitud de transporte.
• Consultar Estado Documentos: Los clientes pueden acceder a través de su cuenta

para consultar el estado de los documentos asociados y generados al servicio de
transporte, verificar el estatus de entrega, información de la expedición en que se
está o se efectúo la operación, en este caso la expedición.
• Consultar Cartola de Movimientos: La documentación generada por los servicios

de la empresa asociada a un cliente puede ser verificada por esté, permitiendo
mantener una estatus de control para ambas partes, y agilizar el acceso al cliente de
sus transacciones realizadas por la empresa.
Cada cliente esta asociado al sistema bajo su RUT, ya sea empresa o persona
natural, así como las ordenes de transporte, internas, de DIB, las expediciones están
agrupadas mediante un Folio. Esto las convierte en un documento único y no
duplicable, mejorando la consistencia de los datos.
17
7 Desarrollo
7.1 Estudio De Factibilidad

Desde el punto de vista técnico, para la realización del trabajo de título son
necesarios algunos recursos tecnológicos que no son pertinentes de desarrollar, pues el
mercado -tanto nacional como internacional- los ofrece a costos razonables y de buena
calidad, así también como herramientas de desarrollo para generar un producto acomodado
a los requerimientos del cliente.
Se debe analizar diversas alternativas en el flujo del estudio de opciones

económicas para un sistema vía Web. A continuación se detallan las siguientes alternativas
estudiadas y los hitos abarcados para generarlos.
7.2 Factibilidad Operacional

El uso del sistema en un 100% siempre dependerá de los usuarios en su concepto de
aceptación en base a los siguiente, que los requerimientos solicitados por su parte han sido
decepcionados de manera clara y se apega en un alto nivel a la realidad, que la nueva
herramienta se convierta en una solución a ciertos procesos complejos realizados
internamente y no lo contrario, que a un largo plazo solo dificulten aquellos procesos que
ya se llevan a cabo con un grado de complejidad. Es de vital importancia como se manejen
los errores que se produzcan en al etapa de desarrollo, y no pasar por alto esta etapa de
control, que puede ser considerada de un alto riesgo.
El efecto de rechazo por parte de los usuarios, a que se resistan al uso de la
herramienta o que se sientan perjudicados o desplazados en el ámbito laboral.
El impacto que pueda producir el nuevo sistema no debe afectar las operaciones
actuales de la empresa, sino de manera contraria, mejorarlas para ofrecer un mejor servicio
al cliente.
Considerar el avance tecnológico como una ventaja y no lo contrario, debido a que la

tecnología avance rápidamente, el sistema debe poseer la capacidad de adaptarse, sino la
solución se vuelve obsoleta.
La optimización de procesos es el camino a seguir dentro de cualquier área de la

ingeniería [5][6], por lo tanto este nuevo sistema debe considerarse como una ventaja para la
empresa y el área de desarrollo en las actividades de los usuarios externos e internos,
además de integrar al cliente a través de un grado de interactividad que se atractiva y de
fácil uso como herramienta de apoyo.
7.2.1 Factibilidad Técnica

La determinación si un trabajo de título es viable se debe a uso correcto de las
herramientas y de los recursos que se disponen en el momento de llevar a cabo un trabajo
de título, la experiencia en proyectos anteriores, no necesariamente en la misma área de
negocio que se plantea la solución, se debe generar un equipo de trabajo con la capacidad
de adaptarse y enfrentar ante cualquier situación.
18
Se considera que esta solución es personalizada, pero no se descarta la posibilidad

de que en algún momento se peda generalizar.
Puesto que están bien definidos los requerimientos del sistema y el cliente posee
pleno conocimiento de los procesos de la empresa, la menar de transferir con detalle las
solicitudes así como la experiencia en otros proyectos anteriores por parte del grupo de
trabajo se pude considerar la viabilidad del trabajo de título.
7.2.2 Factibilidad Legal

La información que será controlada por parte de la empresa no atenta contra ninguna
infracción o violación legal del estado, así como el uso de las herramientas para el
desarrollo del sistema propuesto. No se incurre en adquisición ilícita de información
externa de otras empresas asociadas al rubro como son bases de datos o sistemas de
propiedad exclusiva.
Se cumplen con las licencias correspondientes, así como herramientas de uso libre
para el desarrollo de tecnologías Web.
Bajo estos puntos se considera la factibilidad legal como viable para el desarrollo del
producto.
7.2.3 Factibilidad Económica

Bajo el análisis de costos y beneficios que se adopta como alternativa de testeo sobre
los diferentes propuestas que se plantean como solución para la empresa.
Se considera que los costos incurridos sobre el trabajo de título no superen los
beneficios que se obtendrán al desarrollar el trabajo de título, se considera el costo de
hardware y software, de herramientas de desarrollo, implementación y capacitación
Debido a que el trabajo de título del sistema de transporte terrestre se considera como
un trabajo de título o actividad académica, la empresa considera los costos de las
herramientas de desarrollo como propias, debido a que posee un sistema funcionando de
manera loca en el cual ya incurrió en gastos anteriores y considera reutilizar licencias
adquiridas que puedan ser aplicadas nuevamente. Sin descartar la adquisición de nuevas
tecnologías que pueden traer beneficios a la empresa al implementar este nuevo sistema si
afectar el uso del actual.
Los métodos de análisis utilizados para evalúa el aspecto económico del trabajo de
título son el VAN, PAY BACK y TIR, para comprar los flujos de salida en comparación a
los flujos de entrada del trabajo de título.
7.2.4 Inversión Inicial

Costo para un desarrollador durante el trabajo de título, que incurrirá en análisis del
sistema y producción es de $420.000 en un periodo estimado de 6 meses, en un total de
$2.520.000. Un computador para desarrollo implementado en la Casa Matriz con un costo
promedio de $450.000.
19
7.2.5 Costos operacionales

Costos operacionales estimados en $17.000 por conceptos de insumos por 6 meses,
agregando a la inversión inicial es de $102.000 anual por el tiempo que se utilice el
sistema. Se considera una estación de trabajo o sucursal.
7.2.6 Costos de capacitación

Costo de capacitación del nuevo sistema y de las funcionalidades más importantes
es de $76.000, las que se desglosan en 2 charlas explicativas con un costo de $25.000 c/u
y un manual de usuario con un costo de $16.000.
7.2.7 Costos de Mantención

Costos de mantención del sistema mensualmente $120.000 por un periodo de 6
meses por un total de $720.000, con asistencia técnica 10 x 6 durante el mes.
7.2.8 Beneficios Anuales

La empresa posee 7000 clientes a la fecha, por lo tanto los gastos incurridos en la
atención directa se ve reducida en un 70% de los gastos destinados a la atención y
generación de servicios directamente vinculados. Este se ve reflejado en un valor mensual
de $320.000 con ingresos adicionales de $30.000 por concepto de insumos.
7.2.9 Total beneficios de operación
Corresponde al ahorro menos los gastos operacionales, y tendríamos nuestro flujo

de caja, $2.970.000 - $898.000= $2.072.000, la tasa de interés aplicada por el banco
Central es de 6.30% a mayo del 2008, y el trabajo de título se evalúa a 3 años.
n
∑
n =1
VAN = Fn / (1+ r) (9.2.9.1)
VAN = - 2.970.000 + 2.072.000 + 2.072.000 + 2.072.000 (9.2.9.2)

(1 + 0.063) (1 + 0.063)² (1 + 0.063)3
VAN= -2.970.000 + 1.949.200 + 1.833.678 + 1.725.000 (9.2.9.3)

VAN = 2.537.878
Periodo de Recuperación (PB) = I(Inversión inicial) (9.2.9.4)
Beneficio Neto
PB = 2.970.000 = 1,43 ≈ 2 Se recupera la inversión aproximada en 2 años.
2.072.000
20
7.2.10 Conclusión Estudio De Factibilidad
Luego del análisis legas, operacional, técnico y económico se concluye que cada
tema tratado durante la factibilidad cumplen con las exigencias de cada punto dando el pie
para convertir el trabajo de título en viable, y con la base de que se puede generar un
sistema con fundamentos económicos sólidos y no inseguros.
No se consideró las herramientas de desarrollo como costos asociados al trabajo de

título puesto que se encuentran adquiridas las licencias de Visual Basic 6.0, así también no
se considero la herramienta de desarrollo para código Web por ser un código abierto y
gratuito.
21
7.3 Análisis De Riesgo
Una tarea importante, es anticipar los riesgos que podrían afectar la programación
del trabajo de título o la calidad del software a desarrollar y emprender acciones para evitar
esos riesgos.
Por lo tanto es necesario establecer estrategias de riesgo proactivas. Para lograr esto
se realizaron estudios constantes a riesgos potenciales, valorando su probabilidad y su
impacto para establecer una prioridad según su importancia.
El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los
riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita responder
de una manera eficaz y controlada.
En base a lo anterior se concluye que una buena gestión del riesgo se centra en
actividades proactivas, controlando los riesgos y manteniéndolos al margen, pero como no
todo es controlable, se crean planes de contingencia para minimizar el impacto o pérdidas
que un riesgo pudiera ocasionar.
Para llevar a cabo estas estrategias es necesario primero identificar los riesgos
estableciendo un listado de riesgos potenciales, analizando, priorizándolos por impacto y
probabilidad de ocurrencia, para posteriormente crear un plan de riesgos tanto para
controlar o anular los riesgos y en el caso extremo ocupar planes de contingencia, todo esto
será supervisado a lo largo del proceso.
7.3.1 Identificación de riesgos y análisis de riesgos.

A continuación se presenta una lista con los riesgos identificados, incluyendo un
análisis de su impacto considerando 4 niveles: catastrófico, crítico, marginal, despreciable,
y considerando la probabilidad de que ocurra.
Tabla 7.1 Identificación de Riesgos

Riesgo Impacto Probabilidad
Las dimensiones del
sistema se escapan de la Crítico 20%
realidad
Experiencia de los
integrantes del grupo de
trabajo de título no está Despreciable 30%
acorde con las necesidades
de la empresa
Dimensiones de la base de
datos exceden las Critico 30%
estimaciones iniciales
22
Generación de manuales de
usuarios certeros para su Despreciable 75%
uso.
Se incorporan nuevas
Marginal 40%
funcionalidades al sistema.
Diseño de interfaz de fácil
uso, intuitiva, con colores Marginal 60%
institucionales.
Uso de herramientas
requeridas por el trabajo de Marginal 30%
título.
Necesidad del sistema
como Herramienta de Crítico 80 %
apoyo.
Necesidad de los clientes
de un nuevo mecanismo de Crítico 70 %
acceso a la información
Aparecen nuevos
requerimientos que
necesitan rediseñar el
Crítico 80 %
sistema
23
7.3.2 Planeación de riesgos.

Dado que los riesgos están identificados y priorizados se establecerán planes de
mitigación y planes de contingencia para ellos.
Tabla 7.2 Planeación de Riesgos

Riesgo Plan de mitigación Plan de
contingencia
Dimensionar los módulos del
Las dimensiones del sistema se sistema en base a sus Agregar o quitar
escapan de la realidad requerimientos sin afectar su requerimientos.
funcionalidad.
Comprobar a través de
Experiencia de los integrantes del
acercamientos de los Verificar otros
grupo de trabajo de título no está
módulos menos complicados antecedentes del
acorde con las necesidades de la
la captación de los grupo de trabajo.
empresa
requerimientos.
Verificar el modelo
Dimensiones de la base de datos Definir un modelo de base de
actual en uso con el
exceden las estimaciones iniciales datos acorde al actual usado.
diseñado.
Documentar los procesos Incorporar al cliente
Generación de manuales de
durante el inicio del proceso a través de informes
usuarios certeros para su uso.
de análisis. de estado.
Aplicar una
Verificar que las nuevas
estrategia para
Se incorporan nuevas funcionalidades
incorporar mejoras
funcionalidades al sistema. corresponden al sistema
en nuevas versiones
actual
del sistema
Aplicar estilo de interfaces Incorporar
Diseño de interfaz de fácil uso,
similares al sistema en base funcionalidades que
intuitiva, con colores
al existente sin descartar mejoren el uso del
institucionales.
mejoras sistema
Coordinar el uso de
herramienta adecuado para el Uso de herramientas
Uso de herramientas requeridas
desarrollo del sistema y conocidas en el
por el trabajo de título.
acorde a la capacidad del mercado
grupo de trabajo
Definir que
Encaminar las necesidades
Necesidad del sistema como implementaciones
de los usuarios a través de los
Herramienta de apoyo. se realizarán
requerimientos del sistema
primero
Necesidad de los clientes de un Definir el orden de
Establecer las necesidades
nuevo mecanismo de acceso a la las
principales de los clientes
información implementaciones.
Proponer agregar
Aparecen nuevos requerimientos Verificar y valorar el impacto nuevos módulos al
que necesitan rediseñar el sistema sobre el sistema sistema en un nuevo
proceso.
24
7.3.3 Paradigma De Desarrollo
La elección de un paradigma o modelo de proceso es tal vez una de las decisiones más
importantes en un proyecto de software, ya que éstos establecen las actividades necesarias
para transformar los requisitos de un usuario en software. Es un paradigma, una
representación abstracta de un proceso de software y la utilización de un proceso
inadecuado, probablemente reducirá la calidad o la utilidad del producto de software que se
va a desarrollar.
Se concuerda en que no existe un paradigma de desarrollo ideal, por lo que se hace

necesario buscar aquel que sea más conveniente y que cumpla de mejor manera con las
necesidades del trabajo de título, o en defecto adaptar un paradigma a las necesidades
personales.
En particular para éste trabajo de título se ha elegido el ciclo de vida cascada clásico,
sus principales características son:
• Ciclo de vida clásico ideal fue propuesto por W. Royce a principios de los 70.
• Es una aplicación secuencial de una serie de pasos
• Cada paso genera entradas y documentación para el siguiente.
En base a lo expuesto anteriormente se pueden identificar algunas ventajas que

fueron decisivas a la hora de la elección:
• Ventajas que posee este ciclo de vida son:

• Fases bien definidas
• Funciona bien con métodos y técnicas bien conocidas
• Poco costo de planificación
• Desventajas que posee este ciclo de vida son:
• Poco flexible al cambio
• Proyectos raramente siguen un flujo secuencial
• Dificultad para establecer los requerimientos al principio del proceso
• Errores detectados tardíamente
• Mantenimiento por “parches” (corregir según se presentan los problemas).
7.3.4 Fases de Ciclo de Vida en Cascada

Aún cuando el ciclo de vida clásico está conformado por 4 fases bien definidas es
posible distinguir en este modelo sin modificar su estructura dos fases más las cuales se
detallan en el siguiente esquema.
Figura 7.1. Ciclo de Vida en Cascada
25
7.3.5 Ciclo de vida Clásico con 2 Fases complementarias
Figura 7.2. Ciclo de Vida Clásico con 2 Fases complementarias
• Análisis: En esta etapa se debe entender y comprender de forma detallada cual es la

problemática a resolver, verificando el entorno en el cual se encuentra dicho problema,
de tal manera que se obtenga la información necesaria y suficiente para afrontar su
respectiva solución. Esta etapa es conocida como la del QUÉ se va a solucionar.
• Diseño: Una vez que se tiene la suficiente información del problema a solucionar, es
importante determinar la estrategia que se va a utilizar para resolver el problema. Esta
etapa es conocida bajo el CÓMO se va a solucionar.
• Implementación: partiendo del análisis y diseño de la solución, en esta etapa se procede

a desarrollar el correspondiente programa que solucione el problema mediante el uso
de una herramienta computacional determinada.
• Pruebas: Los errores humanos dentro de la programación de los computadores son

muchos y aumentan considerablemente con la complejidad del problema. Cuando se
termina de escribir un programa de computador, es necesario realizar las debidas
pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor
número de situaciones posibles a las que se pueda enfrentar.
• Documentación: Es la guía o comunicación escrita en sus diferentes formas, ya sea en

enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un
programa. La importancia de la documentación radica en que a menudo un programa
escrito por una persona, es modificado por otra. Por ello la documentación sirve para
ayudar a comprender o usar un programa o para facilitar futuras modificaciones
(mantenimiento).
26
La documentación se compone de tres partes:
1) Documentación Interna: Son los comentarios o mensajes que se añaden al código

fuente para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo
las precondiciones y las poscondiciones de cada función.
2) Documentación Externa: Se define en un documento escrito con los siguientes

puntos:
• Descripción del Problema
• Datos del Autor
• Algoritmo (diagrama de flujo)
• Diccionario de Datos
• Código Fuente (programa)
3) Manual de Usuario: Describe paso a paso la manera como funciona el programa,

con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.
• Mantenimiento: Una vez instalado un programa y puesto en marcha para

realizar la solución del problema previamente planteado o satisfacer una
determinada necesidad, es importante mantener una estructura de actualización,
verificación y validación que permitan a dicho programa ser útil y mantenerse
actualizado según las necesidades o requerimientos planteados durante su vida
útil. Para realizar un adecuado mantenimiento, es necesario contar con una
buena documentación del mismo.
Para terminar de entender la problemática en la cual se desarrolla este libro es

importante tener unos conceptos claros y precisos de lo que es el Análisis y el Diseño de
Algoritmos.
27
8 Metodologías De Desarrollo
Para el desarrollo del trabajo de título se utiliza el paradigma de cascada, este
paradigma es un guía completo para el desarrollo de proyectos de software, nos indica a
cada momento que hacer. Es correcto afirmar que el paradigma establece las actividades
necesarias para la obtención de software, sin embargo el paradigma no es el encargado de
decidir como efectuar éstas actividades, esto es responsabilidad de la metodología.
Anteriormente mencionado, las principales estrategias o metodologías para enfrentar

cada tarea del proceso de análisis de sistemas, se pueden agrupar en tres grandes
categorías:
• Análisis Clásico
• Análisis Estructurado
• Análisis Orientado a Objetos
Se ha evaluado tres alternativas, y llegado a la conclusión de que por las características

que posee y que daremos a conocer a continuación, es óptimo utilizar la metodología de
Orientación a Objetos ya que permite:
• Rapidez en el desarrollo y calidad garantizada en el diseño.

• Abstrae el mundo real, por lo que es más fácil de entender por parte del
cliente y desarrollador.
• Está más orientada a la interacción con el usuario, que a procesos con
entrada y salida.
• Posibilidad de reutilización.
• Documentar sin importar su implementación
• facilidad de dividir el sistema en varios subsistemas
• fomenta la reutilización de componentes
En base a lo expuesto anteriormente y al poder de UML [9] con la orientación a objetos

confirmamos que utilizaremos orientación a objetos.
28
8.1 Herramientas Y Tecnologías De Desarrollo

En un proyecto de desarrollo de software [7] es muy importante elegir las herramientas
y tecnologías más adecuadas para trabajar en él, ya que estas son de gran apoyo en el
desarrollo de las distintas actividades que el trabajo de título posee. Actualmente existe una
gran variedad de herramientas y tecnologías de desarrollo de software [7], lo cual hace muy
difícil establecer la elección adecuada, es por esto que se debe evaluar cuales son las
herramientas y tecnologías que más se acomoden al trabajo de título. Existen algunas
herramientas que se adaptan de mejor manera al trabajo de título, las cuales son bastantes
conocidas y fáciles de utilizar, esto nos permite una mejor decisión a la hora de elegir
alguna herramienta en particular.
A continuación se detallan algunas herramientas utilizadas para el desarrollo de este

informe:
• Microsoft Word 2003.

• Microsoft Access 2003.
• Microsoft PowerPoint 2003.
• Microsoft Visio 2003.
• Acrobat Reader Professional 8.0.
• Enterprise Architect 6.5.
• Sqlyog 5.15
8.1.1 Herramientas
• Microsoft Word 2003:

Utilizado para la generación de documentos e informes, debido a que es un
procesador de texto conocido y fácil de utilizar. Las ventajas que poseen con otros
procesadores de texto son la revisión mejorada y funcionalidad de comentarios,
permitiéndole comunicarse y compartir la información con más eficacia.
• Microsoft Access 2003:

Access 2003 ayuda a sacar el mayor partido a los datos. Posee potentes
herramientas que le permiten capturar, analizar y compartir información de un
modo efectivo, mientras que su integración protege contra el mal uso de datos
confidenciales, lo cual implica que se puede compartir información de un modo
confidencial sin perder integridad en los datos.
• Microsoft PowerPoint 2003:

Utilizado para la presentación del trabajo de título, mejora la manera de crear,
presentar y colaborar en las presentaciones. Utiliza capacidades multimedia
mejoradas para proporcionar presentaciones con mejor impacto.
PowerPoint 2003 ayuda a la creación de emocionantes presentaciones que
provocan un impacto en su audiencia.
29
• Microsoft Visio 2003:

Utilizado para generar diagramas explicativos y organigramas explicativos de las
diferentes actividades de la empresa. Utilizado también para la creación de cartas
Gantt de planificación temporal.
• Acrobat Reader Professional 8.0:

Utilizado para el envió de documentación. El software Adobe Acrobat 8.0
Professional es la forma avanzada para crear, controlar y enviar documentos PDF
de Adobe de gran calidad de manera segura.
• Enterprise Architect.
Producto completo de la familia Enterprise. Todos los productos de Sparx
[11]
Systems dan soporte a UML [9], el cual sus ultimas versiones proveen de
soporte hasta la versión UML [9] 2.1, Mediante esta herramienta se realizan los
diferentes diagramas de UML [9], ya sea diagrama de casos de uso, diagrama de
secuencia, diagrama de clases, entre otros.
• Sqlyog 5.15.
Es uno de los productos que provee las herramientas para administrar y navegar
en bases de datos de Sql.
En conclusión las herramienta descritas anteriormente son las que mejor se adaptan al
trabajo de título, las más conocidas y fáciles de utilizar.
8.1.2 Herramienta De Modelado
Lenguaje Unificado de Modelado (UML [9], por sus siglas en inglés, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y
documentar un sistema de software. UML [9] ofrece un estándar para describir un modelo
del sistema, incluyendo aspectos conceptuales tales como procesos de negocios y
funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y componentes de software reutilizables.
El punto importante para notar aquí es que UML [9] es un lenguaje para especificar y
no un método o un proceso. UML [9] se usa para definir un sistema de software; para
detallar los artefactos en el sistema; para documentar y construir -es el lenguaje en el que
está descrito el modelo. UML [9] se puede usar en una gran variedad de formas para
soportar una metodología de desarrollo de software [7], pero no específica en sí mismo qué
metodología o proceso usar.UML [9] cuenta con varios tipos de diagramas, los cuales
muestran diferentes aspectos de las entidades representadas.
[11]
Las herramientas de Sparx Systems brindan la libertad que contribuye a una
mejor creatividad. Con ellas, se puede elegir el nivel de abstracción que se adapte mejor a
cada tarea, se puede utilizar el ambiente de desarrollo que más convenga al equipo y crear
el ambiente de trabajo de título que se ajuste a sus necesidades específicas. Sin importar
cuál sea la plataforma de desarrollo o la función dentro del equipo, siempre hay una
solución que puede ayudar.
30
8.2 Tecnologías
Las tecnologías que se utilizaran en el trabajo de título se definen a continuación de

manera básica para la producción de sistema como aproximación del funcionamiento que
debe incurrir, si se debiese incluir tecnologías adicionales se detallarán en la entrega de
informe final.
8.2.1 Motor De Base De Datos

MYSQL Server [1], el sistema de gestión de bases de datos SQL Open Source
más popular, lo desarrolla, distribuye y soporta MySQL AB. MySQL AB es una compañía
comercial, fundada por los desarrolladores de MySQL. Es una compañía Open Source de
segunda generación que une los valores y metodología Open Source con un exitoso
modelo de negocio.
Entre sus características figuran:

• Es un sistema de gestión de bases de datos
• Es un sistema de gestión de bases de datos relacionales
• Es Open Source.
• El servidor de base de datos MySQL [1] es muy rápido, fiable y fácil de usar.
• MySQL Server trabaja en entornos cliente/servidor o incrustados
• Una gran cantidad de software de contribuciones está disponible para
MySQL [1].
MySQL [1] Server fue diseñado originalmente para trabajar con bases de datos de
tamaño medio (de 10 a 100 millones de registros, o unas 100MB por tabla) en máquinas
pequeñas. Hoy MySQL Server soporta bases de datos de tamaño de terabytes, pero el
código todavía puede compilarse en una versión reducida adecuada para dispositivos hand-
held o incrustados. El diseño compacto de MySQL Server hace el desarrollo en ambas
direcciones posible sin ningún conflicto en el árbol fuente.
8.2.2 SQL Como Lenguaje

Primero que todo debe quedar claro que SQL no es un lenguaje de programación
como C o Pascal, ya que no posee sentencias de selección o iteración (IF … THEN, FOR,
WHILE, etc.). Por lo tanto, cuando se desean utilizar los datos de la BD para realizar
algún proceso, se debe programar en otro lenguaje (lenguaje anfitrión), desde el cual se
hacen llamados a sentencias SQL (SQL embebido) cuando se desea interactuar con la BD.
Además, como lenguaje es bastante natural y fácil de leer, y se aplica de forma

natural al problema de implementar BD Relacionales, pero como consecuencia de esto es
poco estructurado y utiliza muchas palabras superfluas (que podrían omitirse quitando
claridad a las sentencias).
SQL permite abstraer al usuario de la estructura lógica de la BD mediante las vistas,

aunque éstas imponen bastantes restricciones a los procesos de insertar y modificar datos
en ellas. Además, habiendo sido estandarizado ya hace mucho tiempo, las BD Relacionales
en SQL son muy portables, ya que existen muchos SGBD que lo soportan.
31
Al ser SQL un lenguaje declarativo, es muy fácil verificar los programas, ya que
simplemente se declara lo que se desea como resultado de la ejecución.
SQL es mucho más que un lenguaje de consulta de BD, ya que permite:
• Definir la estructura de los datos;

• Recuperar y manipular datos;
• Administrar y controlar el acceso a los datos;
• Compartir datos de forma concurrente;
• Asegurar su integridad.
Lo anterior se hace basándose siempre en el Modelo Relacional de datos. En

consecuencia, SQL permite hacer efectivos los objetivos de los SGBD, permitiendo a los
usuarios utilizar todo el potencial de los SGBD.
8.2.3 Lenguaje De Programación ASP
Es una tecnología del lado servidor de Microsoft para páginas web generadas
dinámicamente, que ha sido comercializada como un anexo a Internet Information Server
[10]
(IIS). La tecnología ASP está estrechamente relacionada con el modelo tecnológico de
su fabricante. Intenta ser solución para un modelo de programación rápida ya que
[10]
programar en ASP es como programar en VisualBasic, por supuesto con muchas
limitaciones ya que es una plataforma que no se ha desarrollado como lo esperaba
Microsoft.
Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya

desarrollados como algunos controles ActiveX. Otros problemas que han hecho
evolucionar esta tecnología es el no disponer de información "que oriente a quienes desean
aprenderla y resulta muy costosa en tiempo descubrir aquí y allá toda la información para
volverla altamente útil".
[10] [10]
ASP ha pasado por cuatro iteraciones mayores, ASP 1.0 (distribuido con IIS
[10] [10]
3.0), ASP 2.0 (distribuido con IIS 4.0), ASP 3.0 (distribuido con IIS 5.0) y
ASP.NET (parte de la plataforma .NET de Microsoft). Las versiones pre-.NET se
[10]
denominan actualmente (desde 2002) como ASP clásico.
[10] [10]
En el último ASP clásico, ASP 3.0, hay siete objetos integrados disponibles
para el programador, Application, ASPError, Request, Response, Server, Session y
ObjectContext. Cada objeto tiene un grupo de funcionalidades frecuentemente usadas y
útiles para crear páginas web dinámicas.
8.2.4 Jquery
JQuery es un nuevo tipo de librerías de Javascript que permite simplificar la manera

de interactuar con los documentos HTML, permitiendo manejar eventos, desarrollar
animaciones, y agregar interacción con la tecnología AJAX a nuestras páginas Web.
JQuery esta diseñado para cambiar la forma de escribir código JavaScript.
32
8.2.5 Ajax
Es una técnica de desarrollo Web para crear aplicaciones interactivas o RIA (Rich
Internet Applications). Éstas se ejecutan en el cliente, es decir, en el navegador de los
usuarios y mantiene comunicación asíncrona con el servidor en segundo plano. De esta
forma es posible realizar cambios sobre la misma página sin necesidad de recargarla. Esto
significa aumentar la interactividad, velocidad y usabilidad en la misma.
AJAX es una combinación de cuatro tecnologías ya existentes:
• XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseño que

acompaña a la información.
• Document Object Model (DOM) accedido con un lenguaje de scripting por parte
del usuario, especialmente implementaciones ECMAScript como JavaScript y
JScript, para mostrar e interactuar dinámicamente con la información presentada.
• El objeto XMLHttpRequest para intercambiar datos asincrónicamente con el
servidor Web. En algunos frameworks y en algunas situaciones concretas, se usa
un objeto iframe en lugar del XMLHttpRequest para realizar dichos
intercambios.
• XML es el formato usado comúnmente para la transferencia de vuelta al servidor,
aunque cualquier formato puede funcionar, incluyendo HTML pre-formateado,
texto plano, JSON y hasta EBML.
8.2.6 Lenguaje De Programación Visual Basic .Net

La plataforma .NET es un conjunto de tecnologías diseñadas para transformar
Internet en una plataforma informática distribuida a escala completa.
¿Qué es la plataforma .NET?
Herramientas
de desarrollo
Clientes
Servicios Web XML
Servidores Experiencias
de usuario
Figura 8.1 Plataforma informática de .NET
Visual Basic .NET (VB.NET) es un lenguaje de programación orientado a objetos

que se puede considerar una evolución de Visual Basic implementada sobre el framework
.NET. Su introducción resultó muy controvertida, ya que debido a cambios significativos
en el lenguaje VB.NET no es compatible hacia atrás con Visual Basic, cosa que causó gran
división en la comunidad de desarrolladores de Visual Basic.
33
La gran mayoría de programadores de VB.NET utilizan el entorno de programación

Microsoft Visual Studio .Net en alguna de sus versiones (Visual Studio .NET, Visual
Studio .NET 2003 o Visual Studio .NET 2005), aunque existen otras alternativas, como
Sharp Develop que además es libre.
Como pasa con todos los lenguajes de programación basados en .NET, los
programas escritos en VB.NET requieren el Framework .NET para ejecutarse.
8.2.7 Visual Studio .Net

Visual Studio .NET se publicó en 2002 y fue la primera versión de Visual Studio en
introducir el framework .NET. Esta versión de Visual Studio introdujo, junto con el
Framework .NET tres nuevos lenguajes de programación, C#, VB.NET y Visual J#.
En esta primera versión de Visual Studio .NET se podían programar aplicaciones

Windows Forms (aplicaciones de escritorio) y aplicaciones ASP.NET (Aplicaciones Web)
apoyado de herramientas de ayuda como MSDN [2].
8.2.8 J2ME
Sun Mycrosystems da un paso adelante dentro de su tecnología Java, y nos presenta

J2ME (Java 2 Micro Edition): un entorno de producción para pequeños dispositivos que
permite la ejecución de programas creados en Java
Esta tecnología está enfocada hacia aplicaciones inalámbricas, varias son las
características que diferencian J2ME de otras tecnologías inalámbricas:
La primera y más obvia, es la integración transparente con otras Tecnologías Java.
Otra capacidad reside en la posibilidad de ejecutar aplicaciones altamente

dinámicas en el dispositivo inalámbrico, en este sentido, es posible ejecutar/guardar
programas altamente gráficos/vídeos a través de una conexión en Internet, caso no posible
con WAP/WML.
Finalmente la Interfaz Gráfica en general se ve ampliamente superada a diferencia

de aplicaciones WAP/WML.
En conclusión, J2ME es la versión de Java orientada a los dispositivos móviles,

debido a que los dispositivos móviles tienen una potencia de cálculo baja e interfaces de
usuario pobres, es necesaria una versión específica de Java destinada a estos dispositivos,
ya que el resto de versiones de Java, J2SE o J2EE, no encajan dentro de este esquema.
J2ME es por tanto, una versión “reducida” de J2SE.
34
8.2.9 Mobile Web Development
El desarrollo de páginas ASP.NET para exploradores de dispositivos móviles no

difiere sustancialmente del desarrollo de páginas para los exploradores de escritorio. Con
objeto de ayudarle a crear aplicaciones para dispositivos móviles, ASP.NET proporciona
un espacio de nombres System.Web.Mobile dedicado específicamente al desarrollo Web
móvil.
El espacio de nombres System.Web.Mobile contiene las funciones fundamentales,

incluyendo la autenticación y el control de errores, necesarias para generar aplicaciones
Web ASP.NET Mobile.
La clase MobileCapabilities proporciona un solo origen para obtener acceso a la

información de funciones sobre dispositivos cliente y para realizar consultas en funciones
de dispositivo. La clase MobileFormsAuthentication admite dispositivos sin cookies
anexando la información de autenticación adecuada a las direcciones URL pertinentes.
Aunque ASP.NET integra tecnología para que el desarrollo de aplicaciones Web

ASP.NET Mobile siga el mismo modelo que el desarrollo de aplicaciones Web tradicional,
el objetivo principal de la arquitectura no es permitirle crear páginas únicas que se puedan
procesar en exploradores de dispositivos de escritorio o de dispositivos móviles. Las
limitaciones de los exploradores en los dispositivos móviles a menudo implican que las
páginas diseñadas en los exploradores de escritorio no se puedan traducir en los
exploradores de dispositivos móviles.
8.2.10 IIS y Active Sync

Ambas son herramientas de Microsoft, IIS es una herramienta que permite publicar
en un directorio predeterminado del sistema operativo Windows los servicios web o
cualquier pagina web que tenga como servidor el localhost. Esta herramienta no esta
instalada por defecto por lo cual se debe instalar desde el menú agregar o quitar
componentes de Windows una vez instalada puede generar conflictos con el framework 2.0
de .net el cual deberá reinstalarse si así fuera necesario. Al momento de publicar el
webservice este queda disponible para cualquier usuario que conozca la dirección de
referencia en la web.
Por otra parte active sync es una herramienta de Microsoft que permite la
sincronización entre los emuladores proporcionados por visual Studio con los servicios
web desarrollados en la misma plataforma .net. Es necesario tener ejecutada de manera
simultanea active sync antes de ejecutar cualquier aplicación desarrollada en el compact
framework de .net ya que de lo contrario no se podrá comunicar con el webservice y este a
su vez no logrará comunicarse con la base de datos seleccionada.
35
8.3 Arquitectura
8.3.1 Introducción a los Servicios Web
• Servicios Web: Medio para exponer y hacer disponible la funcionalidad de los

sistemas de información mediante las tecnologías estándar Web.
• El uso de tecnologías estándar reduce la heterogeneidad.
• Introducen nuevas arquitecturas y paradigmas de computación.
• Diferentes definiciones para los mismos conceptos y tecnología subyacente:
• Un servicio Web es una aplicación accesible por otras aplicaciones a través del
Web.
• Cualquier cosa que tenga una URL es un servicio Web.
• Definición del consorcio
UDDI: aplicaciones de negocio modulares y autocontenidas que tienen interfaces

abiertos, orientados a Internet y basados en interfaces estándares.
Se requiere que el interface sea abierto, en el sentido de que este tiene que ser
publicado y puede ser invocado a través de Internet.
• ¿Qué significa autocontenida y modular?
UDDI es una iniciativa dirigida por distintos fabricantes de software, dentro el

consorcio de estándares OASIS http://www.uddi.org/. UDDI propone una plataforma
estándar e interoperable que permite a las aplicaciones de forma sencilla y dinámica,
encontrar y utilizar servicios Web sobre Internet.
OASIS (http://www.oasis-open.org) dirige el desarrollo, la convergencia y la adopción

de estándares para el comercio electrónico.
8.3.2 Definición De Servicio Web
Un servicio Web es una aplicación Web identificada por un URI, cuyos interfaces y
enlaces pueden ser definidos, descritos y descubiertos mediante artefactos XML y que
soporta la interacción directa con otras aplicaciones Web que interfaz que define una
colección de operaciones que son accesibles de forma remota usando mensajes XML
mediante protocolos estándar de Internet.
36
8.3.3 Arquitectura Orientada A Servicios 1
Figura 8.2 Arquitectura Orientada a Servicios 1
8.3.4 Arquitectura orientada a Servicios 2
Figura 8.3 Arquitectura Orientada a Servicios 2
37
8.3.5 Tecnologías Usadas

XML:
• Describe la información a ser usada.
• Describe tanto datos como documentos.
• Tiene la capacidad de describir datos y meta datos
• Forma sencilla de describir estructuras de datos complejas y jerárquicas
• Flexibilidad, facilidad de procesado e independencia de plataformas – arquitecturas.
SOAP:
• Empaqueta la información y la transporta, SOAP es un protocolo basado en XML
para el intercambio de información de una forma descentralizada sobre entornos
distribuidos. Define un mecanismo para el paso de instrucciones (comandos) y
parámetros entre clientes y servidores. Es totalmente independiente de la plataforma,
el modelo de datos y el lenguaje de programación usado.
WSDL( Web Service Description Languaje):

• Describe un servicio, se utiliza información XML para la descripción de servicios de
red y de un conjunto de puntos finales donde se dan los detalles de la conexión.
WSDL define que operaciones se puede realizar, donde se ubica el servicio, y como
se debe invocar.
UDDI:
• Proporciona una lista de servicios disponibles
8.3.6 Arquitectura Física de los Servicios Web

En la siguiente vista se muestra como la arquitectura de la aplicación principal , la
cual es de 3 capas, es absorbida por la arquitectura Web service , ya que esta ultima
engloba cualquier otra arquitectura presente en un sistema ,esto es debido a que son los
servicios Web los encargados de comunicar a los diversos sistemas que conforman el
sistema completo.
Figura 8.4 Arquitectura Fisica Orientada a Web Services
38
8.3.7 Introducción a los Servicios Cliente Servidor
Esta arquitectura consiste básicamente en que un programa -el cliente- realiza

peticiones a otro programa -el servidor- que le da respuesta. Aunque esta idea se puede
aplicar a programas que se ejecutan sobre un solo computador, es más ventajosa en un
sistema operativo multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los
servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la
centralización de la gestión de la información y la separación de responsabilidades, lo que
facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el
servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo
programa. Los tipos específicos de servidores incluyen los servidores Web, los servidores
de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos
servicios a otros, la arquitectura básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el servidor se
descompone en diferentes programas que pueden ser ejecutados por diferentes
computadoras aumentando así el grado de distribución del sistema.
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no
hay distribución, tanto a nivel físico como a nivel lógico.
8.3.8 Definición de servicio Cliente Servidor

La modalidad o arquitectura Cliente/Servidor es aquella en la que confluyen una
serie de aplicaciones basadas en dos categorías que cumplen funciones diferentes (una
requiere servicios y la otra los brinda) pero que a la vez, pueden realizar tanto actividades
en forma conjunta como independientemente. Esas dos categorías son justamente cliente y
servidor.
En el caso del cliente, es aquel que requiere un servicio del servidor. En esta
categoría se realizan funciones de software basándose en el hardware pero en caso de no
tener la capacidad de procesar los datos necesarios, recurre al servidor y espera a que este
le brinde los servicios solicitados. El cliente es una estación de trabajo o computadora que
está conectada a una red a través de la cual puede acceder al servidor.
Por el contrario, el servidor es la máquina desde la que se suministran servicios y

que está a la espera del requerimiento del cliente. Una vez hecho, busca la información
solicitada y le envía la respuesta al cliente; incluso puede enviar varios servicios a la vez,
lo que es posible porque entre ellos están conectados mediante redes LAN o WAN.
Entre las características fundamentales de esta arquitectura encontramos que tanto

el cliente como el servidor pueden realizar tareas en forma conjunta como separada ya que
el cliente también tiene sus propias aplicaciones, archivos y bases de datos y que además,
pueden estar en la misma plataforma o en plataformas diferentes. Por otra parte, el servidor
puede brindar varios servicios a la vez, tanto al mismo cliente como a clientes múltiples.
39
8.3.9 Arquitectura De La Aplicación Central

Aun cuando la arquitectura del sistema es del tipo Web, es necesario aclarar que la
aplicación principal fue pensada como modelo de 3 capas, las cuales son:
La capa de presentación, la capa de negocio y la capa de datos. Es necesaria esta

aclaración ya que el modelo de 3 capas pensado para la aplicación es utilizada por el
servicio Web.
Figura 8.5 Arquitectura de la Aplicación Central.
8.3.10 Arquitectura Física
El sistema se implementara por medio de un servidor, el cual se encontrara en la

Casa Matriz y será manejado por un administrador, en el cual será implementado tanto la
base de datos como el acceso de los datos.
Se cuanta con 2 computadores para manejar el sistema de Web establecido en las

estaciones de trabajo o monitoreo. A continuación entregamos una propuesta de la
descripción del equipo utilizado para este sistema:
DISPOSITIVOS DESCRIPCION
Procesador : Intel CPU Celeron 1.6 GHz/420 Box (775)

Tarjeta Madre : Asrock M/B Base Intel Wolfdale1333-
D667 Pci-E A/V/L (775)
Disco Duro : W.Digital Disco Duro Sata2 80Gb 7200
Computador
Memoria : Kingston DDR2 1GB 667Mhz KVR667D2N5
Estaciones
(KNG-391)
Dispositivos : Mouse Optico M325BP S/Black PS2
Teclado Black Espanol K8050P PS2
Procesador : Intel® Pentium Dual Core: 925 de 3.0 GHz,

4MB (2 x 2MB) Level 2 cache
Chipset/ FSB : Intel 3000 / 800MHz FSB (Front Side Bus)
Memoria : 1 GB / PC2-5300 unbuffered DDR2
(667MHz)
Computador Servidor Disco Duro : SATA2 160GB
Dispositivos : Mouse Optico M325BP S/Black PS2
Teclado Black Espanol K8050P PS2
Unidad Óptica: 48x IDE (ATAPI) DVD-ROM/RW
Tabla 8.1 Propuesta requerimientos para funcionamiento
40
Esta descripción de la arquitectura esta propuesta como de requerimientos mínimos

para satisfacer el correcto funcionamiento de todo el sistema y pensado también para un
alto rendimiento en cuanto a procesamiento de los datos.
Figura 8.6 Diagrama de implementación del Sistema Central
41
9 Análisis Del Sistema
9.1 Diagrama De Casos De Uso De Contexto General

uc Caso de Uso General
Gestionar
Expedicion
Gestionar Orden de
Transporte (OT)
Administrador
Gestionar Cliente
Gestionar Usuarios
Consultar Estado
Documentos
Generar Cotización
Consultar Cartola
Cliente Mov imientos
Gestionar Serv icios

de Encomienda
Figura 9.1 Diagrama De Casos De Uso De Contexto General
42
9.2 Diagrama Caso De Uso Gestionar Expedición

uc Caso de Uso Gestionar Expedición
Verificar Vehiculo
«include»
Ingresar Expedición
«include»
Modificar Expedición
Verificar Expedición
«include»
«include»
Administrador
Consultar Expedición
Actualizar Estado
Anular Expedicion Factura
«extend»
Actualizar
Expedición
«extend»
Actualizar Estado OT
Figura 9.2 Diagrama Caso De Uso Gestionar Expedición
43
9.3 Diagrama Caso De Uso Gestionar OT
uc Caso de Uso Gestionar OT
Ingresar OT Verificar Folio

«include» Solicitud
«include»
Modificar OT
Generar Folio
Solicitud
Administrador
Anular OT
Consultar OT
Figura 9.3 Diagrama Caso De Uso Gestionar OT
44
9.4 Diagrama Caso De Uso Consultar Cartola De

Movimientos
uc Caso de Uso Consultar Mov imientos
Exportar Cartola
Verificar Periodo Generar Informe «extend»
«include» «include»
Solicitar Periodo a Consultar Mov imientos

Consultar «include» Cliente
Cliente
Figura 9.4 Diagrama Caso De Uso Consultar Cartola de Movimientos
45
9.5 Diagrama Caso De Uso Consultar Cotización

uc Caso de Uso Generar Cotizacion
Veriricar Tarifado
Cliente
Calcular Tarifa
«include»
«extend»
«include»
«extend»
Env iar Cotizacion

Ingresar Datos
Cliente Imprimir Tarifa
Figura 9.5 Diagrama Caso De Uso Consultar Cotización
46
9.6 Diagrama Caso De Uso Consultar Estado De

Documentos
uc Caso de Uso Consultar Estado Documentos
Verificar Periodo Generar Informe

«extend» Exportar Consulta
«include»
«include»
Solicitar Periodo a
Consultar
«include» Recuperar
Cliente Documentos del
Periodo
«include»
Solicitar Documento a
Consultar
Figura 9.6 Diagrama Caso De Uso Consultar Estado De Documentos
47
9.7 Diagrama Caso De Uso Gestionar Servicios De

Encomienda
uc Caso de Uso Gestionar Serv icios de Encomienda
Verificar Estado
Cliente
«include»
Ingresar Solicitud
Serv icio
Env iar Solicitud
«include»
Cliente Consultar Serv icio Verificar Estado

«include» Serv icio
«include»
«include»
Generar Registro de
Verificar Puntos de Serv icios
Control
Figura 9.7 Diagrama Caso De Uso Gestionar Servicios De Encomienda
48
9.8 Diagrama Caso De Uso Gestionar Clientes

uc Caso de Uso Gestionar Clientes
Ingresar Cliente
«include»
Modificar Cliente
Asignar Tarifa
«include»
Administrador Eliminar Cliente
Consultar Cliente
Figura 9.8 Diagrama Caso De Uso Gestionar Clientes
49
9.9 Diagrama Caso De Uso Gestionar Call Center

uc Caso de Uso Gestionar Call Center
Generar Folio
Solicitud
Ingresar Solicitud
«include»
«include»
Verificar Folio
«include» Solicitud
Modificar Solicitud
«include»
Env iar Solicitud
Administrador «include»
Anular Solicitud
Consultar Solicitud
Figura 9.9 Diagrama Caso De Uso Gestionar Call Center
50
9.10 Diagrama Caso De Uso Gestionar Usuario
uc Caso de Uso Gestionar Usuarios
Ingresar Usuario
«include» Asignar Sucursal
«include»
«include»
Modificar Usuario
Verificar Sucursal
Eliminar Usuario
Administrador
Consultar Usuario
Figura 9.10 Diagrama Caso De Uso Gestionar Usuario
51
9.11 Diagrama Caso De Uso Login
uc Caso de Uso Login
Administrador
Login
«include» Verificar Usuario
Cliente
Figura 9.11 Diagrama Caso De Uso Login
52
9.12 Casos De Uso Explicación Formal

Caso de Uso Ingresar Cliente
Actores Administrador (A)
Precondiciones
El Administrador debe estar logeado en el sistema.
El Cliente no debe existir en el sistema
Poscondiciones
El Cliente ha sido almacenado en el sistema
Pasos:
1. El caso de uso se inicia cuando un Administrador necesita registrar un nuevo Cliente al sistema.
2. A: selecciona la opción ingresar un nuevo Cliente.
3. S: solicita los datos del nuevo Cliente para registrarlo como tal.
4. A: ingresa los datos requeridos para el registro en una plantilla de datos.
5. S: comprueba la validez de los datos, además de verificar que el nuevo Cliente no se encuentre
registrado en el sistema.
6. S: Almacena los datos del nuevo Cliente, e informa mediante un mensaje el ingreso exitoso.
7. S: informa al Administrador de su ingreso exitoso y termina el caso de uso.
Escenario Alternativo
5a. Cliente ya existe en el sistema.
1. S: verifica que el Cliente ya se encuentra ingresado en el sistema, y envía un mensaje al
Administrador para que corrija el ingreso o lo cancele. Pasa al paso 4 del flujo principal.
5b. Datos incorrectos.
1. S: verifica que los datos no están correctos o no están completos, y envía un mensaje al
Administrador para que los corrija o cancele el ingreso. Pasa al paso 4 del flujo principal.
53
Caso de Uso Eliminar Cliente

Precondiciones
La persona a eliminar debe estar registrada como socio del video club.
Poscondiciones
Elimina al Cliente del sistema.
Pasos:
1. El caso de uso se inicia cuando un Administrador quiere eliminar la información de un Cliente en
el sistema.
2. A: selecciona la opción Eliminar Cliente.
3. S: solicita el ingreso del Rut del Cliente.
4. A: ingresa el Rut del Cliente.
5. S: verifica que el Rut corresponde a una persona registrada anteriormente como Cliente, y que
esta no posee servicios activos o contratados.
6. S: despliega la información del Cliente, y da la opción del eliminarlo.
7. A: selecciona eliminar el Cliente.
8. S: elimina de manera permanente al Cliente, despliega mensaje de eliminación exitosa.
5a. Cliente no existe
1. S: verifica que el Cliente no se encuentra ingresado en el sistema, se envía mensaje al
Administrador para que corrija la consulta o la cancele.
5b. Cliente con servicio activo.
1. S: verifica actividad del Cliente, con servicio contratado iniciado. Esto impide la eliminación
permanente del sistema.
2. E: cancela operación.
54
Caso de Uso Modificar Cliente

Precondiciones
El Cliente debe existir en el sistema.
Poscondiciones
El Cliente ha sido actualizado en el sistema
Pasos:
1. El caso de uso se inicia cuando un Administrador quiere modificar la información de un Cliente en
el Sistema.
2. A: selecciona la opción modificar datos de un Cliente.
3. S: solicita el Rut del Cliente del cual se desea modificar la información.
4. A: ingresa el Rut del Cliente al sistema.
5. S: se comprueba los datos y verifica que la persona sea Cliente activo del sistema.
6. S: despliega un formulario igual al de ingreso con la información del Cliente a modificar.
7. A: modifica los Cliente que desea de la plantilla del Cliente.
8. A: selecciona actualizar los datos.
9. S: comprueba los datos del Cliente y los actualiza.
10. S: informa que los datos han sido actualizados correctamente al Administrador.
5a. S: verifica que el Cliente no se encuentra ingresado en el sistema, se envía un mensaje al
Administrador para que corrija el ingreso o finalice la operación. Vuelve al paso 4 del flujo
principal.
9a. S: verifica que los datos no son correctos, se envía un mensaje al Administrador para que los corrija
o cancele la modificación. Vuelve al paso 6 del flujo principal.
55
Caso de Uso Consultar Cliente

Precondiciones
El cliente del cual se requiere información debe estar registrado.
Poscondiciones
El sistema despliega la información del cliente.
Pasos:
1. El caso de uso se inicia cuando un Administrador quiere consultar la información de un Cliente en el
sistema.
2. A: selecciona la opción Consultar Cliente.
3. S: solicita el ingreso del Rut del Cliente, verifica que el Rut corresponde a una persona registrada
anteriormente como Cliente.
4. A: ingresar Rut Cliente.
5. S: verifica los datos del Cliente
6. S: despliega la información del Cliente.
7. A: analiza los datos y termina el caso de uso
3a. S: verifica que el Cliente no se encuentra ingresado en el sistema, se envía mensaje al Administrador
para que corrija la consulta o la cancele.
56
Caso de Uso Ingresar Orden de Transporte (OT)

Actores Administrador(A)
Precondiciones
El Administrador se encuentra logeado en el sistema.
Poscondiciones
Se realiza el ingreso de la Orden(es) de Transporte(s).
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita ingresar una OT.
2. A: selecciona la opción ingresar OT en el menú principal.
3. A: selecciona el Período en cual creará la OT.
4. S: solicita el Rut del Cliente que requiere realizar un servicio.
5. S: verifica Rut Cliente.
6. S: solicita la expedición a ser asociada.
7. A: Ingresa expedición
8. S: Verifica Expedición.
9. A: ingresa los datos de la OT.
10. S: genera un Folio automático para la OT.
11. S: presenta la descripción a rellenar por el Administrador.
12. A: ingresa el detalle de la OT
Se repite paso 8 hasta que el Administrador indique el termino del ingreso del detalle.
13. A: confirma el ingreso de la OT.
14. S: registra la OT en el sistema, y envía un mensaje con el ingreso exitoso.
15. S: emite comprobante de la OT.
4a. Cliente no existe en el sistema,
57
Caso de Uso Modificar Orden de Transporte (OT)

Precondiciones
La OT debe existir en el sistema.
Poscondiciones
Se realiza la modificación de la Orden(es) de Transporte(s).
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita modificar una OT.
2. A: selecciona la opción modificar OT en el menú principal.
3. A: selecciona el Período en cual se buscará la OT.
4. S: solicita el Folio de OT.
5. S: verifica el folio y despliega la información.
6. A: ingresa los datos de la OT.
7. S: modifica los datos de la OT.
8. S: presenta la descripción actualizada al Administrador.
9. A: confirma la modificación de la OT.
10. S: registra la OT en el sistema, y envía un mensaje con la actualización exitosa.
11. S: emite comprobante de la OT.
4a. Folio no existe en el sistema,
1. S: verifica que el Folio no se encuentra ingresado en el sistema, se envía mensaje al
58
Caso de Uso Anular Orden de Transporte (OT)

Precondiciones
La OT debe existir en el sistema.
Poscondiciones
Se realiza la eliminación de la Orden(es) de Transporte(s).
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita anulación una OT.
2. A: selecciona la opción anulación OT en el menú principal.
3. A: selecciona el Período en cual se buscará la OT.
4. S: solicita el Folio de OT.
5. A: ingresa el Folio de la OT.
6. S: verifica los datos de la OT.
7. S: presenta los datos al Administrador.
8. A: confirma la anulación de la OT.
9. S: registra la anulación OT en el sistema, y envía un mensaje con la operación exitosa.
10. A: cierra el modulo y termina el caso de uso.
59
Caso de Uso Consultar Expedición

Precondiciones
La expedición debe estar ingresada en el sistema.
Las Ordenes de transporte deben estar asociadas a al expedición en el período correspondiente.
Poscondiciones
Se despliega la información de la expedición.
Pasos:
1. El caso de uso se inicia cuando el Administrador quiere verificar los datos de una expedición.
2. A: selecciona el período a consultar de la expedición.
3. A: ingresa el Folio de la expedición.
4. S: verifica que el Folio de la expedición existe.
5. S: despliega la información de la expedición.
6. A: verifica la información de la expedición.
7. A: termina el caso de uso al salir del módulo.
4a. S: verifica que la expedición no existe y corresponde al período escogido, se envía mensaje al
Caso de Uso Modificación Expedición

Precondiciones
La expedición debe estar ingresada en el sistema.
Las Ordenes de transporte deben estar asociadas a al expedición en el período correspondiente.
Poscondiciones
Se despliega la información de la expedición.
Pasos:
1. El caso de uso se inicia cuando el Administrador quiere modificar los datos de una expedición.
2. A: selecciona el período a consultar de la expedición.
4. S: verifica que el Folio de la expedición existe.
5. S: despliega la información de la expedición.
6. A: ingresa la información para actualizar.
7. S: registra la información actualizada de la expedición.
8. A: termina el caso de uso al salir del módulo.
4a. S: verifica que la expedición existe y corresponde al período escogido, se envía mensaje al
60
Caso de Uso Ingresar Expedición

Precondiciones
La expedición no debe estar ingresada en el sistema.
Deben existir vehículos para asignar a la expedición.
Poscondiciones
Se registra la información de la expedición.
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita ingresar una Expedición.
2. A: selecciona la opción ingresar Expedición en el menú principal.
3. A: selecciona el Período en cual creará la Expedición.
4. S: solicita el vehiculo que realizará un servicio.
5. A: ingresa el vehiculo para realizar la expedición.
6. S: verifica estado del vehiculo.
7. A: ingresa los datos de la expedición.
8. S: genera un Folio automático para la expedición.
9. A: confirma el ingreso de la Expedición.
10. S: registra la Expedición en el sistema, y envía un mensaje con el ingreso exitoso.
11. S: emite comprobante de la expedición.
6a S: verifica que el vehiculo no existe o no esta disponible, se envía mensaje al Administrador para
que corrija el ingreso o lo cancele.
61
Caso de Uso Anular Expedición

Precondiciones
La expedición debe existir en el sistema.
Poscondiciones
Se realiza la anulación de la expedición.
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita anulación una expedición.
2. A: selecciona la opción anulación expedición en el menú principal.
3. A: selecciona el Período en cual se buscará la expedición.
4. S: solicita el Folio de expedición.
6. S: verifica los datos de la expedición.
8. A: confirma la anulación de la expedición.
9. S: registra la anulación expedición en el sistema, y envía un mensaje con la operación exitosa.
62
Caso de Uso Ingresar Solicitud Call Center

Precondiciones
Poscondiciones
Se realiza el ingreso de la solicitud de call center
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita ingresar una solicitud.
2. A: selecciona la opción ingresar Call Center en el menú principal.
3. S: solicita el Rut del Cliente que requiere realizar un servicio.
4. A: ingresa el Rut del Cliente.
5. S: verifica Rut Cliente.
6. S: solicita la información adicional.
7. A: Ingresa la información adicional.
8. S: genera un Folio automático para la solicitud.
9. A: confirma el ingreso de la Solicitud.
10. S: registra la solicitud en el sistema, la envía y da un mensaje con el ingreso exitoso.
11. A: termina el caso de uso
5a. Cliente no existe en el sistema,
63
Caso de Uso Modificar Solicitud de Call Center

Precondiciones
La solicitud debe existir en el sistema.
Poscondiciones
Se realiza la modificación de la solicitud.
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita modificar una solicitud.
2. A: selecciona la opción modificar Call Center en el menú principal.
3. A: selecciona el Período en cual se buscará la solicitud.
4. S: solicita el Folio de solicitud.
5. S: verifica el folio y despliega la información.
6. A: ingresa los datos de la solicitud.
7. S: modifica los datos de la solicitud.
8. S: presenta la descripción actualizada al Administrador.
9. A: confirma la modificación de la solicitud.
10. S: registra la solicitud en el sistema se envía y da un mensaje con la actualización exitosa.
11. A: termina el caso de uso
64
Caso de Uso Anular Solicitud de Call Center

Precondiciones
La solicitud debe existir en el sistema.
Poscondiciones
Se realiza la eliminación de la solicitud.
Pasos:
1. El caso de uso se inicia cuando el Administrador necesita anulación una solicitud.
2. A: selecciona la opción anulación solicitud de Call Center en el menú principal.
3. A: selecciona el Período en cual se buscará la solicitud.
4. S: solicita el Folio de solicitud.
5. A: ingresa el Folio de la solicitud.
6. S: verifica los datos de la solicitud.
8. A: confirma la anulación de la solicitud.
9. S: registra la anulación solicitud en el sistema, y envía un mensaje con la operación exitosa.
65
Caso de Uso Consultar Estado de Documentos

Actores Cliente
Precondiciones
El Cliente debe estar registrado en el sistema.
Poscondiciones
Se despliega la información solicitada por el Cliente.
Pasos:
1. El caso de uso se inicia cuando el Cliente quiere generar una consulta de documentos.
2. S: solicita el documento a consultar.
3. C: ingresa el documento.
4. S: solicita el periodo a consultar.
5. C: ingresa el periodo.
6. S: despliega una plantilla con las opciones para generar informes.
7. C selecciona el informe a generar.
8. S: verifica la consulta y despliega el informe en pantalla.
3a. No hay datos
1. S: verifica que no existe información para la opción seleccionada y envía un mensaje al cliente para
que corrija el ingreso de la consulta o la cancele.
5a. Imprimir Informes
A: solicita impresión de informe desplegado por el sistema, presionando botón “Imprimir”. Finaliza
el caso de uso.
66
Caso de Uso Ingresar Usuario

Precondiciones
El Usuario no debe existir en el sistema
Poscondiciones
El usuario ha sido almacenado en el sistema
Pasos:
1. El caso de uso se inicia cuando un Administrador ingresa un nuevo usuario al sistema.
2. A: selecciona la opción ingresar un nuevo usuario.
3. S: solicita información del usuario para registrarlo en el Sistema.
4. A: ingresa datos del usuario al sistema.
5. S: verifica el correcto ingreso de los datos, verifica que el usuario no se encuentre registrado en el
sistema, registra un nuevo usuario.
6. S: envía un mensaje del ingreso correcto al Administrador.
7. A: informa al usuario de su ingreso exitoso y termina el caso de uso.
5a. Usuario ya existe.
1. S: verifica que el usuario ya se encuentra ingresado en el sistema, y envía un mensaje al
Administrador para que corrija el ingreso o lo cancele.
5b. Ingreso incorrecto.
1. S: verifica que los datos no están correctos o no están completos, y envía un mensaje al
Administrador para que los corrija o cancele el ingreso.
67
Caso de Uso Modificar Usuario

Precondiciones
El usuario debe existir en el sistema.
Poscondiciones
El usuario ha sido actualizado en el sistema
Pasos:
1. El caso de uso se inicia cuando un Administrador quiere modificar la información de un usuario en
el Sistema.
2. A: selecciona la opción modificar datos de un usuario.
3. S: solicita Rut de usuario.
4. A: ingresa Rut del usuario al sistema.
5. S: se comprueba los datos y se verifica la existencia del usuario.
6. S: despliega la información del usuario a modificar.
7. A: modifica los datos que desea de la plantilla del usuario, selecciona actualizar datos.
8. S: comprueba los datos del usuario y los actualiza, informa al Administrador la actualización
exitosa.
5a. Usuario no existe.
1. S: verifica que el usuario no se encuentra ingresado en el sistema, se envía un mensaje al
8a. Datos incorrectos.
1. S: verifica que los datos no son correctos, se envía un mensaje al Administrador para que los
corrija o cancele la modificación.
68
Caso de Uso Consultar Usuario

Precondiciones
El usuario debe existir en el sistema.
Poscondiciones
El sistema despliega la información del usuario.
Pasos:
1. El caso de uso se inicia cuando un Administrador quiere consultar la información de un usuario en el
sistema.
2. A: selecciona la opción Consultar Usuario.
3. S: solicita el Rut de usuario.
4. A: ingresa el Rut del usuario al sistema.
5. S: se verifica la existencia de usuario en el sistema, despliega información del usuario.
6. A: consulta los datos y termina el caso de uso.

5a. Usuario no existe.
1. S: verifica que el usuario no se encuentra ingresado en el sistema, se envía mensaje al
69
Caso de Uso Login

Actores Administrador (A), Administrador (E)
Precondiciones
El usuario debe estar registrado en el sistema.
Poscondiciones
Autentificar el ingreso al sistema por parte de un usuario.
Pasos:
1. E o A: El caso de uso se inicia cuando el usuario ingresa su nombre de de usuario o login y la
password al sistema.
2. S: verifica los datos del usuario, permitiendo su acceso según tipo de acceso definido por usuario.
3. S: despliega la interfaz respectiva al tipo de usuario ingresado.
3a. S: verifica que el usuario no se encuentra ingresado en el sistema, se envía mensaje para que corrija
el ingreso o lo cancele.
Caso de Uso Consultar Estados documentos

Actores Cliente (C)
Precondiciones
Poscondiciones
Información de los documentos generados para el Cliente.
Pasos:
1. C: El caso de uso se inicia cuando el Cliente se loguea en el sistema.
2. C: Selecciona el período a consultar los estados de pago
3. S: despliega los tipos de documentos a consultar.
4. C: selecciona el documento a consultar.
5. S: solicita la información del documento a consultar.
6. C: ingresa la información requerida.
7. S: despliega la información del documento a consultar.
8. C: verifica la información y termina el caso de uso
3a. S: verifica que el documento no se encuentra ingresado en el sistema, se envía mensaje para que
corrija el ingreso o lo cancele.
70
Caso de Uso Consultar Cartola de Movimientos

Actores Cliente (C)
Precondiciones
Poscondiciones
Información de los movimientos generados por el Cliente.
Pasos:
1. C: El caso de uso se inicia cuando el Cliente se loguea en el sistema.
2. C: Selecciona el período a consultar de la cartola.
3. S: verifica el periodo y recupera la información.
4. S: despliega los documentos asociados al Cliente de la periodo solicitado y da la posibilidad de
exportar la consulta.
5. C: verifica la información termina el caso de uso
3a. S: verifica que no existen documentos o movimientos generados o asociados en ese periodo
seleccionado por el Cliente y envía un mensaje que no existe información.
Caso de Uso Generar Cotización

Actores Cliente (C)
Precondiciones
Las tarifas deben estar activas para su uso.
Poscondiciones
Las tarifas para envío de acuerdo a los datos ingresados por el Cliente.
Pasos:
1. C: El caso de uso se inicia cuando el Cliente ingresa al modulo de Generar Cotización.
2. C: ingresa los parámetros a consultar, como tamaño, cantidad, peso, etc.
3. S: Verifica la información ingresada por el cliente y realiza el calculo de acuerdo a parámetros
establecidos por la empresa.
4. S: despliega la consulta calculada al cliente.
5. C: verifica la información y termina el caso de uso
3a. S: no existe tarifado para los parámetros ingresados y se solicita un nuevo ingreso de información
al cliente.
71
10 Diagrama De Secuencias
10.1 Ingresar Cliente
sd Ingresar Cliente
Sistema
Administrador
Ingresar Cliente
Solicitar_datos_Cliente
Ingresar datos Ciente(Rut, Giro,

Razón, Dirección, Fono, Saldo.)
Verificar datos Cliente()
Solicitar Confirmación
Confirma Ingreso
Datos Registrados
Figura 10.1 Diagrama de Secuencia Ingreso de Cliente
72
10.2 Modificar Cliente

sd Modificar Cliente
Sistema
Administrador
Modificar_datos_Cliente()
Solicitar Rut Cliente
Ingresar Rut Cliente(Rut)
Verificar datos Cliente()
Solicita Datos Cliente
Modifica datos Cliente(Giro, Razón,

Dirección, Fono, Saldo.) Actualiza Datos Cliente
Confirma Datos Actualizados
Figura 10.2 Diagrama de Secuencia Modificar de Cliente
73
10.3 Eliminar Cliente

sd Eliminar Cliente
Sistema
Administrador
Eliminar Socio()
Ingresa Rut Cliente(Rut)
Verficar Rut Cliente
Despliega información Cliente
Selecciona Eliminacón Cliente(Si, No)
Elimina Cliente
Confirma Eliminación
Figura 10.3 Diagrama de Secuencia Eliminar de Cliente
74
10.4 Consultar Cliente
sd Consultar Cliente
Sistema
Administrador
Consultar Cliente
Ingresar Rut Cliente(Rut)
Verficar Rut Cliente
Desplegar Información Cliente
Analizar datos
Terminar Consulta
Figura 10.4 Diagrama de Secuencia Consultar de Cliente
75
10.5 Ingresar OT
sd Ingresar OT
Sistema
Administrador
Ingresar OT
Solicita Período
Ingreso Período OT(Periodo)
Solicita Rut Cliente
Ingresa Rut Cliente(Rut)
Verfica Rut Cliente
Solicita Expedición
Ingresa Expedicón(OidExpedición)
Verifica Expedición
Solicita Datos OT
Ingresa Datos OT(Rut, Neto, Desde, Hasta,

TipoOt)
Registra OT y Genera Folio
Confirma Ingreso
Figura 10.5 Diagrama de Secuencia Ingresar OT
76
10.6 Modificar OT
sd Modificar OT
Sistema
Administrador
Modificar Ot
Solicita Periodo OT
Ingresa Periodo(Periodo)
Solicita Folio OT
Ingresa Folio OT(OidOt)
Verifica Ot
Despliega Informacion
Ingresa datos OT(Rut, Neto, Desde, Hasta,

TipoOt) Verifica Datos
Despliega Confirmación
Confirma Datos OT
Registra OT
Emite Comprobante
Figura 10.6 Diagrama de Secuencia modificar OT
77
10.7 Anular OT
sd Eliminar OT
Sistema
Administrador
Anular OT
Solicita perído OT
Ingresa período(Periodo)
Solicita Folio OT
Ingresa Folio OT(OidOt)
Verifica Folio OT
Despliega datos OT
Confirma Anular OT
Verifica datos OT y Anular
Figura 10.7 Diagrama de Secuencia Anular OT
78
10.8 Login
sd login
Sistema
Cliente y/o Administrador
Ingresar Login
Solicitar datos Usuario
Ingresar Datos Usuarios(Usuario,

Contraseña)
Verficar datos
Confirmar Ingreso
Figura 10.8 Diagrama de Secuencia Login
79
10.9 Consultar Estado de Documentos

sd Listar Informes
Sistema
Administrador
Listar Informes ()
Despliega plantilla
Selecciona Informe
Despliega Informe
Selecciona periodo
Genera Informe
Figura 10.9 Diagrama de Secuencia Consultar Estado de Documentos
80
10.10 Ingresar Expedición

sd Ingresar Expedición
Sistema
Administrador
Ingresar Expedicion
Solicitar periodo
Selecciona periodo(Periodo)
Solicita Vehiculo
Ingresa Vehiculo(OidVehiculo)
Verifica Vehiculo
Solicita Datos Expedicion
Ingresa Datos Expedicion(Fecha, neto,

Kgs, OidSucursal)
Verifica datos y genera folio
Confirma Ingreso Expedicion
Emite Comprobante
Figura 10.10 Diagrama de Secuencia Ingresar Expedición
81
10.11 Anular Expedición

sd Anular Expedicion
Sistema
Administrador
Anular Expedicion
Solicita periodo
Ingresa periodo(Periodo)
Solicita Folio Expedicion
Ingresa Folio(OidExpedición)
Despliega Datos
Verifica Folio
Confirma Anulacion(Si, No)
Verifica Datos de Expedicion y Anula
Informa anulacion
Figura 10.11 Diagrama de Secuencia Anular Expedición
82
10.12 Modificar Expedición
sd Modificar Expedición
Sistema
Administrador
Modificar Expedicion
Solicita Periodo
ingresa
Periodo(Periodo)
Solicita Folio Expedicion
Ingresa Folio
Expedicion(OidExpedicion)
Verifica Folio
Despliega datos Expedición
Ingresa datos nuevos(Fecha, neto, Kgs,

OidSucursal)
Verifica los datos y los registra
Informa Modificacion
Figura 10.12 Diagrama de Secuencia Modificar Expedición
83
10.13 Consultar Cotización

sd Consultar Tarifas
Sistema
Administrador
Consultar Cotizacion
Solicita Datos a calcular
Ingresa Datos cotizacion(Rut)
Calcula y Verifica Tarifa Cliente
Despliega Cotizacion(Valor,
descripción)
Selecciona Envar Cotizacion
Envia Cotizacion
Informa Envio
Figura 10.13 Diagrama de Secuencia Consultar Cotización
84
11 Diagramas De Actividad Flujo Futuro De Trabajo
11.1 Flujo Futuro General

act fluj o general futuro
Actor Sistema
login
Admi nistrador i ngresa al si stem a
Exi ste usuario
Despliega [si]
Pagina [no]
Selecciona Modulo Principal
Fin Ingreso
Gestionar Expedicion
[si]
Gestionar Expedicion
Solicitar Periodo
Desplegar Formulario
[no]
Realizar
operacion sobre
expedicion Verificar Registrar
Datos Operacion
fi n Gestionar Orden de T ransporte
[si ]
Gestionar Orden de
Transporte
Solicitar periodo Desplegar Formulario
[no]
Realizar Operacion registrar

sobre OT Verificar Datos Operacion
fin
Gestionar Usuari o
Gestionar Usuario [si ]
Desplegar
formulario
Realizar operacion
sobre usuario Verificar datos usuario Registrar operacion [no]
fin
Gestior Call Center
[si]
realizar operacion sobre Despliega formulario

call center
registra operacion del
v erifica datos de [no]
call center
solicitud
Gesti onar Cl iente

fin
Gestionar Cliente [si ]
Desplegar Formulario
[no]
Realizar operacion sobre

cliente Salir del Sistema
v erificar datos cliente
fin
registra operacion de
cliente
fin
Figura 11.1 Diagrama de Actividades Flujo Futuro General
85
11.2 Flujo Futuro Ingresar Expedición

act Fluj o Futuro ingresar expedicion
Actor Sistema
Login
Admi nistrador requi ere i ngresar expedici on
existe usuari o
[no]
[si]
Solicita periodo fi n
Selecciona periodo Verifica periodo

ingresado
[no]
Peri odo Exi ste
[si ]
Solicita datos v ehiculo
Verifica Vehiculo
Ingresa Vehiculo
[no]
Existe vehicul o
[si ]
[si]
Solicita Datos expedicion
Ingresa Datos expedicion
Verifica datos
Registra Expedicion
genera folio
Emite comprobante
Verifica comprobante
ingresar otra expedi cion
[no]
fi n
Figura 11.2 Diagrama de Actividades Flujo Futuro Ingresar Expedición
86
11.3 Flujo Futuro Ingresar Orden de Transporte
act fluj o futuro ingresar ot
Actor Sistema
Login
Admi nistrador requi ere i ngresar OT
existe usuari o
[no]
[si]
Solicita periodo fi n
Selecciona periodo Verifica periodo

ingresado
[no]
Peri odo Exi ste
[si ]
Solicita datos OT
Ingresa Datos OT Verifica datos
Solicita Folio expedicion

[si]
Ingresa folio expedicion
Verifica datos
[no]
exi ste expedici on
[s]
Registra OT genera folio
Emite comprobante
Verifica comprobante
ingresar otra ot
[no]
fi n
Figura 11.2 Diagrama de Actividades Flujo Futuro Ingresar Orden de Transporte
87
11.4 Flujo Futuro Consultar Cotización
act fluj o futuro cotizacion
Actor Sistema
Login
Cliente desea generar una
cotizacion
existe usuario
[no]
[si]
Solicita datos cotizacion fin
Ingresa datos a cotizar Verifica tarifa del

cliente
Calcula Tarifa
rev isa cotizacion
Despliega Cotizacion
escoge env iar cotizacion

registra la cotizacion
Env ia la cotizacion a
Call center
emite comprobante
rev isa comprobante
fin
Figura 11.3 Diagrama de Actividades Flujo Futuro Consultar Cotización
88
12 Diseño
12.1 Modelo Del Dominio

class Modelo Dominio
Vehiculo
Expedicion Web tiene Tipo_Vehiculo

1..* 1
tiene
Sucursal
Expedicion Mov il
1..* tiene 1
Expedición_Mes_Anno
*
Detalle_Factura_Mess_Anno
1 1asignada tiene
Factura_Mes_Anno 1 1..*
1..*
asignada
OTI
1..*
Tiene CallCenter
1..* 1
registra
OT_Mes_Anno Usuario
1.. 1..*
Tiene
OT
1..* 1
tiene
Tarifa
1..* 1
1 1 *
posee
OT DIB
tiene tiene
1..*
Cartola
Tarifa WEB Tarifa Mov il

*
1
Detalle_OT_Mes_Anno Perfil
asignado
Cliente
1..* Administrador
Periodo
Figura 12.1 Diagrama de Diseño Modelo Del Dominio
89
12.2 Modelo Conceptual De Clases

obj ect modelo Clases
Vehiculo
- OidVehiculo
- Anno Tipo_Vehiculo
- Patente
- Carga tiene - OidTipo
- Marca - Descripcion
1..* 1
- FechaRevision
- Modelo
- NChasis
- NMotor
+ Verificar Vehiculo() : void

Sucursal
- OidSucursal
- Descripcion
1 - Estado
- Obs
tiene CallCenter
+ Asignar Sucursal() : void
+ Verificar Sucursal() : void - OidFolio
1 - Fecha
- Estado
1..* - Des_Rut
tiene
Detalle_Factura_Mess_Anno
- Des_Direccion
Expedición_Mes_Anno - Des_Telefono
- Documento
- Kilos - Des_Contacto
- OidExpedicion
- Bulto - Des_Hora_Cierre
- Fecha
- Mts3 - Des_Hora_Llamada
- Neto *
Factura_Mes_Anno - ValorUnitario - Rec_Rut
- Kgs
- Rec_Nombre
- Cancela tiene
- OidFactura - Rec_Direccion
- Estado
- Neto 1 1..* - Rec_Comuna
- Periodo
- Total - Rec_Sector
- Iva - Rec_Telefono
+ Ingresar Expedicion() : void
asignada - Estado
+ Modificar Expedicion() : void
- Razón + Ingresar Solicitud() : void
+ Consultar Expedicion() : void 1 1..*
- Fecha + Modificar Solicitud() : void
+ Anular Expedicion() : void
- Dirección Usuario registra + Anular Solicitud() : void
- Ciudad
- Rut 1.. 1..* + Consultar Solicitud() : void
1 - Desde
- Giro
- Hasta
asignada - Razon
- Obs
- Direccion
- Periodo Tiene - Comuna
1..* - Rut_Rec
- Nombres_Rec 1..* 1 - Ciudad
- Fono1
OT_Mes_Anno - Ap_Pat_Rec
- Fono2
- Ap_Mat_Rec
- Casilla
- OidOt
- Fax
- Vencimiento + Actualizar Estado Factura() : void
- Mail
- Telefono + Actualizar Estado OT() : void
- Url
- Neto
- Saldo
- Total Tarifa
- Credito
- Saldo Tiene
- Disponible tiene
- Estado - OidTarifa
- Obs 1..* 1 - Estado 1..* 1 - Descripcion
- HoraCierre
- Desde - Valor
- Contraseña
- Hasta
- Periodo + Asignar Tarifa() : void
posee + Ingresar Usuario() : void
- TipoOt + Calcular Tarifa() : void
+ Modificar Usuario() : void
- Rut_Rec 1 + Eliminar Usuario() : void
- Nombres_Rec
+ Consultar Usuario() : void
- Ap_Pat_Rec
- Ap_Mat_REC *
+ Ingresar OT() : void

tiene
+ Modificar OT() : void
Perfil
+ Anular OT() : void
+ Consultar OT() : void - OiPerfil
- Descripcion
1
1
tiene
1..*
* Cartola
- OidCartola
Detalle_OT_Mes_Anno - Fecha
- Documento - Periodo
- Bulto - Obs Periodo
asignado
- Kilos
- Mts3 + Exportar Cartola() : void 1 1..* - OidPeriodo
- ValorUnitario - Descripcion
- Estado
+ Verificar Periodo() : void
Figura 12.2 Diagrama de Diseño Modelo Conceptual De Clases
90
12.3 Modelo Entidad Relación
Figura 12.3 Diagrama de Diseño Modelo Entidad Relación
91
12.4 Diseño De Interfaces
El diseño de la Interfaz de Usuario (UI), es un proceso iterativo en donde los usuarios

interactúan con los diseñadores y prototipos de interfaz para decidir así, las características,
organización, apariencia y funcionamiento de la interfaz de usuario del sistema.
• Existen 3 actividades esenciales en este proceso:
Análisis del usuario: en este proceso se desarrolla una comprensión de las tareas
que el usuario realiza, su entorno de trabajo, como interactúa con el resto de las personas
en su trabajo etc.
Prototipado del Sistema: el diseño y desarrollo de la interfaz, en un proceso
iterativo. Aunque los usuarios pueden hablar de las facilidades que necesitan en una
interfaz, es muy difícil para ellos ser muy específicos hasta que ven algo tangible, por lo
tanto se deben generar prototipos del sistema y exponerlos a los usuarios para que así estos
puedan guiar el desarrollo de la interfaz.
Evaluación de la interfaz: es importante poseer una tarea de evaluación mas formalizada
donde se recopile información sobre las experiencias reales de los usuarios con la interfaz.
En cuanto al prototipado de la UI, idealmente, cuando se esta construyendo el

prototipo de la interfaz de usuario, se debe adoptar un proceso de prototipado en dos
etapas:
Al principio se deben desarrollar prototipos en papel y mostrárselos a los usuarios
finales, esta técnica es un enfoque poco costoso y sorprendentemente efectivo para el
desarrollo de prototipos.
Luego de la tarea anterior, se perfecciona el diseño y se desarrollan prototipos cada
vez mas sofisticados, y se ponen a disposición de los usuarios para realizar pruebas.
Entre los puntos a considerar a la hora de diseñar interfaces de usuario podemos

mencionar: la familiaridad del usuario, la mínima sorpresa, la recuperabilidad, la guía del
usuario y la diversidad de usuarios ayudan a guiar el diseño de interfaces.
El color se debe utilizar con moderación y de forma uniforme en las interfaces de
usuario.
Los objetivos de la evaluación de las interfaces de usuario son obtener una

retroalimentación de cómo se puede mejorar el diseño de la UI y evaluar si una interfaz
cumple sus requerimientos de usabilidad.
92
12.4.1 Pagina Principal
Figura 12.4 Diseño Pagina Principal
93
12.4.2 Login
El Cliente ingresa sus datos para acceder a su perfil de usuario y así tener acceso
a las distintas y discriminantes funcionalidades que ofrece el sistema. Se despliega al
ingresar al sistema otorgando atribuciones diferentes según su perfil. El menú refleja los
módulos en los cuales se ha dividido el sistema.
Figura 12.5 Diseño Login
94
12.4.3 Menú principal

Se despliega al ingresar como usuario al sistema. El menú refleja los módulos en
los cuales se ha dividido el sistema.
Figura 12.6 Diseño Menú Principal
95
12.4.4 Periodo
Figura 12.7 Diseño Periodo
96
12.4.5 Modulo de Call Center
Figura 12.8 Módulo Call Center
Figura 12.9 Módulo Edición Call Center
97
12.4.6 Modulo Usuario

Parte del mantenedor de Usuario, mediante este formulario es posible registrar
nuevos clientes en el sistema.
Figura 12.10 Módulo Usuario
Figura 12.11 Módulo Edición Usuario
98
12.4.7 Modulo Vehiculo
Figura 12.12 Módulo Vehiculo
Figura 12.13 Módulo Edición Vehiculo
99
12.4.8 Módulo Expedición
Figura 12.14 Módulo Expedición
Figura 12.15 Módulo Edición Expedición
100
12.4.9 Módulo de Orden de Transporte
Figura 12.16 Módulo Orden de Transporte
Figura 12.17 Módulo Edición Orden de Transporte
101
12.4.10 Módulo Estados de Documentos
Figura 12.18 Módulo Estados de Documentos
102
12.4.11 Acceso Restringido
Figura 12.19 Acceso Restringido
103
12.4.12 Vista Palm Menú de Utilidades
Figura 12.20 Menú Utilidades Palm
104
12.4.13 Búsqueda de Expedición Palm
Figura 12.21 Busqueda de Expedición Palm
105
12.4.14 Consulta de Expedición
Figura 12.22 Consulta de Expedición Palm
106
13 Plan De Pruebas
A excepción de los programas pequeños, los sistemas no se prueban, como una
simple unidad monolítica.
Los sistemas grandes se construyen a partir de subsistemas que a su vez se

construyen a partir de módulos que están compuestos de procedimientos y funciones. Por
lo tanto, el proceso de prueba se lleva a cabo en etapas en las que las pruebas se aplican de
forma incremental en conjunto con la implementación del sistema.
Se han reconocido los siguientes módulos dentro del sistema:
• Módulo Gestionar Expedición.

• Módulo Gestionar Call Center.
• Módulo Gestionar Orden de Transporte
• Módulo Gestionar Usuarios.
• Módulo Consultar Cotización
• Módulo Gestionar de Servicios de Encomiendas
• Modulo Consultar Cartola de Movimientos
• Modulo Consultar Estado de Documentos
La etapa de prueba se va a llevar cabo en cuatro etapas:

• Prueba de unidades.
• Prueba de integración.
• Prueba de sistema.
• Prueba de aceptación.
107
13.1 Prueba de unidades

Se prueban los componentes individuales para asegurarse de que operan
correctamente. Cada uno se prueba de forma independiente, sin los otros componentes del
sistema. Consiste esencialmente en probar cada método de las clases implementadas por
separado.
Como este tipo de prueba es el primero de esta etapa, posee una gran importancia,
ya que si las unidades están mal evaluadas no tiene sentido evaluar los módulos, ya que si
las unidades poseen errores, los módulos los acarrearan.
Por lo antes dicho, es preciso probar el flujo de datos de la interfaz del módulo,
además de las estructuras de datos locales, durante la prueba de unidad se debe comprobar
el impacto de los datos globales sobre el módulo.
Los módulos que requieren de prueba unitaria son:
• Módulo Gestionar Usuarios.

• Módulo Gestionar Orden de Transporte.
• Modulo Gestionar Expedición.
• Modulo Gestionar CallCenter
108
13.2 Prueba de integración.

Una vez que se probaron los componentes individuales de programa, deben
integrarse para crear un sistema parcial, o completo. Este proceso de integración
comprende la construcción del sistema y probar el sistema resultante con respecto a los
problemas que surjan de las interacciones de los componentes.
Debido a que el software orientado a objeto no posee una estructura de control

jerárquica, las estrategias convencionales de integración ascendente y descendente poseen
un significado pequeño.
Por lo mismo, existen dos distintas estrategias para evaluar la integración de los
módulos que son:
• Prueba basada en hilos.

• Prueba basada en usos.
109
13.3 Prueba Basada En Hilos

Esta integra el conjunto de clases necesarias para responder una entrada o evento del
sistema. Cada hilo se integra y prueba individualmente.
Al haber varias secuencias diferentes en el diagrama de secuencias dependiendo,

por ejemplo, del estado inicial del sistema y de la entrada del actor.
El caso de pruebas que se deriva de un diagrama de secuencia debería describir cómo

probar una secuencia interesante en el diagrama, tomando el estado inicial del sistema
110
13.4 Prueba Basada En Usos

Consiste en dividir las clases en capas e ir probando por cada nivel, la primera capa
debe poseer todas las clases independientes, luego se prueba el siguiente nivel donde se
encuentran las llamadas capas dependientes, que son las que utilizan las dependientes, y así
sucesivamente hasta llegar hasta el sistema completo.
En este caso se utilizará la prueba basada en usos, ya que se puede apreciar con
mayor claridad las capas y las interacciones entre las clases, por lo mismo, se ocupará
menos tiempo en este tipo de integración.
111
13.5 Prueba De Sistema

Luego de llevar a cabo la prueba de unidad y la de integración, se debe probar el
sistema en si.
Este tipo de prueba consiste en encontrar los errores que son el resultado de
interacciones no previstas entre los módulos y la interfaz. También comprende en validar
que el sistema cumpla sus requerimientos funcionales y no funcionales y probar las
propiedades emergentes del sistema.
Este tipo de prueba esta constituida por otras pruebas, estas pruebas en si poseen
distintos propósitos, pero en su conjunto apuntan a verificar que se hayan integrado
adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
Estas pruebas son:
• Prueba de recuperación.
• Prueba de seguridad.
• Prueba de resistencia.
• Prueba de rendimiento.
112
13.6 Prueba De Recuperación

.
La prueba de recuperación es una prueba del sistema que fuerza el fallo del software
de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente.
La recuperabilidad, frecuentemente denominada "recuperación de desastres", tiene

dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.
La recuperación de las bases de datos consisten en información y estampas de

tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un
momento y fecha en particular. Es posible hacer respaldos de la base de datos que no
incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe
sacar de línea la base de datos en caso de llevar a cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los datos, después se

aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado
consistente en un tiempo y momento determinados. Alternativamente se puede restaurar
una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de
datos.
113
13.7 Prueba De Seguridad

Esta prueba intenta verificar que los mecanismos de protección incorporados en el
sistema lo protegerán, de hecho, de accesos impropios y la capacidad de los usuarios para
acceder y cambiar los datos de acuerdo a las políticas del negocio, así como, las decisiones
de los encargados.
Al igual que otros metadatos, un sistemas de gestión de bases de datos (DBMS)

relacional maneja la seguridad en forma de tablas.
114
13.8 Prueba De Rendimiento

Esta diseñada para probar el rendimiento del software en tiempo de ejecución dentro
del contexto de un sistema integrado. Este tipo de prueba es usado para sistemas de tiempo
real y empotrado. Por lo mismo esta prueba no se realizará.
El rendimiento significa que la base de datos no cause tiempos de respuesta poco

razonables. En sistemas muy complejos cliente/servidor y de tres capas, la base de datos es
sólo uno de los elementos que determinan la experiencia de los usuarios en línea y los
programas desatendidos.
115
13.9 Prueba de aceptación.

Ésta es la etapa final en el proceso de pruebas antes de que el sistema se ponga en
operación. Ésta prueba la debe realizar el cliente. Debido a la diferencia entre los datos
reales y de prueba, la prueba de aceptación revela errores y omisiones en la definición de
requerimientos del sistema. También revela donde los problemas de requerimientos en los
recursos del sistema no cumplen las necesidades del usuario o donde el desempeño del
sistema es inaceptable. Dentro de esta prueba cae lo que es el manual de usuario.
Para realizar las tres primeras etapas del plan de prueba, que son de unidad,
integración y sistema se utilizarán ciertos métodos los cuales serán:
• Caja blanca.
• Caja negra.
• Partición equivalente.
• Análisis de valores límites.
13.9.1 Caja Blanca
La prueba de caja blanca es un método de diseño de casos de prueba que usa la

estructura de control de diseño procedimental para obtener los casos de prueba. Mediante
los métodos de prueba de caja blanca, se pueden obtener los casos de prueba que
garanticen que:
• Se ejercite por lo menos una vez todos los caminos independientes de cada
módulo.
• Se ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
• Se ejecuten todos los bucles en sus límites y con sus límites operacionales.
• Se ejerciten las estructuras internas de datos para asegurar su validez.
Además, considera el hecho de los errores de escritura que se puedan producir al

momento de trasladar el código fuente a un lenguaje de programación determinado.
13.9.2 Caja Negra.
Este método de prueba se centra en los requisitos funcionales de software, es decir,

permite al ingeniero de software obtener conjuntos de condiciones de entrada que ejerciten
completamente todos los requisitos funcionales de un programa. Este método es un
complemento al de caja blanca, ya que intenta descubrir diferentes tipos de errores que el
método de caja blanca no ha encontrado.
La prueba de caja negra intenta encontrar errores que caen en las siguientes
categorías:
- Funciones incorrectas o ausentes.
- Errores de interfaz.
- Errores en estructuras de datos o en accesos a bases de datos externas.
116
- Errores de rendimiento.
- Errores de inicialización y de terminación.
La caja negra se identifica como una entidad reconocible a la cual llegan diferentes
entradas y de la cual salen una o varias salidas. El funcionamiento de ésta consiste en que
la entrada que llega sea procesada dentro de la caja, y la salida que proporcione sea la
transformación de dicha entrada, no importando el proceso que se lleve a cabo para
transformar los valores de entrada en salidas.
117
13.10 Plan de Pruebas.

Se tomo en cuenta para la prueba de este trabajo de título la técnica de Caja Negra que
permite probar el sistema a través de las diferentes interfaces de usuario. Y se definirán los
flujos de prueba a través de casos de prueba, que se definen de manera resumida a
continuación.
Caso de A
Condición Entrada Salida
Prueba probar
Validar Sistema Estar Nombre 1.- Datos correctos: pasar a operaciones del usuario.
Usuario ingresado en Usuario 2.- Caso contrario: solicitar reingreso de los datos o
el sistema. y Clave registrarse en el sistema.
de 3.- Faltan datos: solicitar ingreso del o los datos
Acceso faltantes.
Ingresar Sistema Administrador Ingresar 1.- Datos correctos: mostrar funciones de acuerdo al
Usuario logeado. todos los tipo de usuario.
datos 2.- Datos incorrectos: solicitar reingreso de los datos.
solicitad 3.- Faltan datos: solicitar ingreso del o los datos
os faltantes.
4.- Nombre de usuario ya existe: mostrar mensaje de
error y solicitar que ingrese un nuevo nombre.
Consultar Sistema Cliente Ingresar 1.- Datos correctos: mostrar mensaje de paso exitoso.
Estado de logeado todos los 2.- Datos incorrectos: solicitar reingreso de los datos.
Documentos datos y 3.- Faltan datos: solicitar ingreso del o los datos
pasos faltantes.
solicitad 4.- Paso de generación de informe fallido: solicitar
os ingreso del o los datos faltantes o ingrese los datos
correctamente.
5.- Informe no se genera: mostrar mensaje de error
que ingrese todos los pasos correctamente o ingrese
el informe nuevamente.
Eliminar Sistema Administrador Ninguna 1.- Borra Información: mostrar mensaje de
Información logeado. eliminación exitosa
2.- No Borra Información: muestra mensaje de que la
información no pudo ser eliminada y solicita que
vuelva a seleccionar la información que desea
eliminar.
Tabla 13.1 Plan de Pruebas
118
14 Conclusiones y Trabajo Futuro

En el presente trabajo de título final se han presentado varios modelos del sistema,
capturas de imagen de los módulos terminadas con el objeto de lograr una representación
abstracta de una especificación, requerimiento o punto de vista particular del sistema del
trabajo de título.
En gran medida estos modelos se han representado gráficamente mediante uno o

más diagramas, cuyo propósito es expresar la esencia de algunos aspectos del trabajo
realizado en el sistema, sin especificar detalles innecesarios, esto último ha permitido en
gran medida pensar y discutir sobre los problemas y soluciones sin desviarnos del objetivo;
el desarrollo de un sistema aplicado al trabajo de título.
Además el uso y estudio de tecnologías para dispositivos móviles a través de Web

Services agrega un valor adicional para las funcionalidades del sistema que se quieren
llevar al Prototipo y se adapta a las necesidades que en la actualidad están ofreciendo los
nuevos sistemas que se están desarrollando con orientación Web.
En este análisis ha sido preciso no dejar pasar detalles que a veces parecen
demasiado obvios o sencillos pero marcan la diferencia al momento de buscar calidad. Es
preciso recordar que un software de calidad es aquel que cumple con los requisitos del
usuario, pero también estos requisitos conllevan la responsabilidad por parte del o los
desarrolladores de asignar los limites del sistema propuesto, ya que el no hacerlo podría
generar más de algún problema grave como puede ser el abarcar tantos tópicos que el
sistema no se terminara nunca o que simplemente el cliente cambie los requerimientos de
un momento a otro ya que no tenia claro lo que quería como solución.
En el momento de diseño se identificaron otras características que se pudieron

integrar al sistema como son mejoras en al funcionalidad de los módulos Web.
La inclusión de dispositivos inalámbricos que ofrezcan una conectividad remota a

las funcionalidades del sistema están pensadas a mejorar las y potenciar cualquier tipo de
proceso que sea prestado por el sistema.
Para finalizar, hoy en día, existen muchos proyectos disponibles para que una
empresa de cualquier área pueda realizar innovaciones en sus procesos internos, e
implementar la tecnología y la informática como una sección base de la empresa, y servir
como motor para nuevas innovaciones para presentar una cara al mercado mucho más
actualizada. Es por eso que no se debe desestimar
119
15 Referencias
Respecto a Empresas de Referencia:
[1] www.mysql.com
MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario subsidiaria de
Sun Microsystems y ésta a su vez de Oracle Corporation, quien desarrolla MySQL como software
libre en un esquema de licenciamiento dual.
[2] www.msdn.com
MSDN es la biblioteca oficial de Microsoft con la documentación técnica dirigida a los
desarrolladores de la plataforma Microsoft Windows. MSDN representa la red de desarrolladores de
Microsoft.
Respecto a las leyes y códigos:

[3] http://www.tramitefacil.gov.cl/1481/article-46526.html
Confiere un medio de prueba importante sobre la autoría o creación de una obra. También, respecto
de los titulares de derechos conexos. [Consultada el 9 de Septiembre de 2010]
[4] http://www.ads.cl/lHTML/ley.html
Ley 20435 publicada en el diario oficial el 4 de Mayo recién pasado que modificó la Ley de
Propiedad Intelectual Chilena N° 17336. [Consultada el 9 de Septiembre de 2010]
Respecto a textos guía:

[5] Pressman, Roger. (2002). Ingeniería en Software. Madrid: McGraw Hill.
[6] Sommerville, Ian. (2002). Ingeniería en Software. Ciudad de México: Pearson .
[7] Jacobson, Ivar. (2000). Proceso unificado de desarrollo de software. Addisson Wesley.
[8] http://www.microsoft.com/latam/office/.
Suite de oficina que abarca e interrelaciona aplicaciones de escritorio, servidores y servicios para los
sistemas operativos Microsoft Windows y Mac OS X. [Consultada el 5 de Julio de 2010]
[9] http://www.uml.org/
Lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad.
[Consultada el 17 de septiembre de 2010]
[10] http://www.asptutorial.info/
Tecnología de Microsoft del tipo "lado del servidor" para páginas web generadas dinámicamente,
que ha sido comercializada como un anexo a Internet Information Services (IIS)
[11] http://www.sparxsystems.es/
Una herramienta que abarca el ciclo de vida completo, para integrar su equipo y dar vida a su visión
de trabajo compartido. [Consultada el 1 de Agosto de 2010]
[12] Serpell Bley, Alfredo. (2001). Planificación y Control de Proyectos. Santiago: Ediciones
Universidad Católica de Chile.
120
16 Anexo
16.1 Entrevista
• Fecha: 29/02/2008
• Ubicación: Casa matriz Placilla
• Entrevistado: Cristian Espinoza (Gerente de Administración).
La siguiente entrevista se llevo a cabo por solicitud del cliente para traspasar la
información permitenente de los procesos y servicios que se están llevando actualmente en
la empresa, informar de la las proyecciones a futuro de soluciones a problemas que se
aquejan hoy en día que son traspasados indirectamente al cliente la mayoría de las veces.
16.2 Detalle de la entrevista
En primera instancia, el Gerente de Administración se encuentra en posición de

entregar la información necesaria sin inconvenientes, puesto que ve en una oportunidad de
mejorar y cambiar en cierta medida la cara de la empresa con una nueva herramienta de
negocio.
Conoce perfectamente los procesos de la empresa, pero la cantidad de información

generada por su parte tuvo que ser canalizada a través de consultas claves en la entrevista
que permitiera distinguir la categoría y similitud de procesos que parecen similares, pero
tienen un efecto totalmente diferente.
Deja abierta la posibilidad de generar nuevas entrevistas y la participación directa

en el trabajo de título si fuese necesario, puesto que al conocer directamente los servicios y
participar y revisar de ellos constantemente, permite tener una visón mucho mas fidedigna
que la que pudiese entregar otro encargado, sin descartar la participación de otros
funcionarios para tener diferentes puntos de vista.
16.2.1 Desventajas
• La complejidad de los procesos es alta.

• Existe una reticencia en un grado menor de traspasar ciertas funciones que se
realizan de manera local a una herramienta Web.
• Existe una dependencia directa por parte del Cliente al enfrentar consultas o
seguimiento de algún servicio contratado activo o efectuado anteriormente.
• La centralización de la información, decrementa los tiempos de respuesta en
procesos que deberían ser ágiles y efectivos por parte de la empresa hacia el cliente.
• Al fallar el sistema local, el tiempo en los procesos puede verse perjudicado
produciendo falencias durante su desarrollo.
121
16.2.2 Ventajas
• Ve una herramienta de apoyo hacia la gestión de su empresa.
• Potenciar los servicios activos dentro de la empresa y mejorar lo controles desde el
punto de vista de la gestión.
• Pese a que se ve un poco de inseguridad frente a la información que se exponga
como sistema Web, ven una ventaja sobre otras empresas al disponer de un sistema
tal que permita acercar al cliente dentro a un nivel de confianza mejor.
• Existen procesos sumamente definidos que permiten tener una visión mucho más
clara de los alcances del trabajo de título.
16.2.3 Conclusión de la entrevista

Para definir que la entrevista finalizó con un grado de éxito, se toman puntos en que
el cliente estuvo siempre dispuesto a entregar la información necesaria para desarrollar el
trabajo de título, entrego documentación adicional, explico y definió conceptos hasta tener
una clara visión del problema.
Dejo la posibilidad de realizar las reuniones que fuesen necesarias, e integrar a

otros usuarios para captar mejor el entorno de la empresa.
122
16.3 Glosario
Expedición Servicio de encomienda realizado vía terrestre a través de vehículos a motor con
los pedidos de los clientes.
Análisis de
estudio o canalización de los problemas y entregar al cliente de manera
requerimientos descriptiva de estos.
Precio a pagar por un servicio contratado por el cliente, o precio cobrar por un
Tarifa
servicio prestado por la empresa.
visión Concepción de una realidad que se puede generar en algún momento.
Conjunto de acciones llevadas a cabo para solucionar un asunto, o administrar
Gestión
una entidad.
Logear Identificar a un usuario válido en el sistema.
Logout Finalizar sesión de un usuario válido en sistema.
Documento generado por la empresa similar a una guía de despacho con el
Orden de Transporte
detalle de los servicios a prestar en esa expedición.
Rol Función que una persona desempeña en un lugar o situación.
Substracción o pérdida de algún artículo que afecta directamente a la empresa y
Merma
debe incurrir en su pago a terceros.
Folio Identificador autoincrementable asociado a documentos de la empresa.
Código fuente gratuito a disposición de usuarios que pueden trabajar y
Open Source
modificar directamente su funcionamiento
PAY BACK Periodo de recuperación de una inversión.
Tabla 16.1 Glosario
123
16.4 Diagrama Caso De Uso General Detallado

uc Caso de Uso Detallado
Sistem a de Moni toreo para Empresa de T ransporte T errestre
Ingresar Usuario Asignar Sucursal Verificar Sucursal

«i ncl ude» «i ncl ude»
«i ncl ude»
M odificar Usuario
Consultar Usuario
Eliminar Usuario
Env iar Solicitud
«i nclude»
Modificar Solicitud
Verificar Folio
Solicitud
Anular Solicitud
Ingresar Solicitud «i ncl ude»
«i ncl ude»
Consultar Solicitud
Generar Folio Solicitud
Anular Expedicion
Administrador
Consultar Expedición
«i ncl ude» Verificar Expedición
«incl ude»
M odificar Expedición
«incl ude»
Verificar Vehiculo
«i nclude»
Ingresar Expedición
Actualizar Estado
Actualizar Expedición
«extend» Factura
«extend»
Actualizar Estado OT
Consultar Cliente
Modificar Cliente
«i ncl ude»
Asignar Tarifa
Eliminar Cliente Ingresar Cliente «i ncl ude»
Login
«i ncl ude» Verificar Usuario
Imprimir Tarifa
Ingresar Datos
Env iar Cotizacion
«extend»
«i ncl ude»
«extend»
Calcular Tarifa
Cliente
Veriricar Tarifado Verificar Periodo

Generar Cotización Cliente
«i ncl ude»
Recuperar
Documentos del
Consultar Cartola Solicitar Periodo a Periodo
«i ncl ude»
M ov imientos «incl ude» Consultar
«i ncl ude»
Exportar Consulta
«i ncl ude»
Consultar Mov imientos

Consultar Estado
Cliente «incl ude»
Documentos
«i ncl ude» Solicitar Documento a
Consultar
«extend»
«i ncl ude»
Verificar Puntos de
Control
Exportar Cartola
«i ncl ude» Generar Informe «extend»

Gestionar Serv icios de
Encomienda Consultar Serv icio
«i ncl ude»
«incl ude»
«i ncl ude» Verificar Estado
«i ncl ude»
Serv icio
Generar Registro de
Ingresar Solicitud Serv icios
Serv icio
«i ncl ude»
«incl ude» Env iar Solicitud
Verificar Estado
Cliente
Figura 16.1 Diagrama Caso De Uso General Detallado
124

Sistema de Monitoreo de Empresa de Transporte Terrestre

Cargado por

Copyright:

Formatos disponibles

Sistema de Monitoreo de Empresa de Transporte Terrestre

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Monitoreo de Empresa de Transporte Terrestre

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO – CHILE

Sistema de Monitoreo para

GUSTAVO RENE CISTERNAS SILVA

INFORME FINAL DEL PROYECTO

Sistema de Monitoreo para

Gustavo Rene Cisternas Silva

Profesor Guía: José Miguel Rubio León

Carrera: Ingeniería de Ejecución en Informática

Dedicado a mis Padres..

La finalidad de esta tesis es implementar el análisis y diseño del seguimiento y

Estableciendo un plan de trabajo enfocado en una mejora de procesos, una

Establishing a work plan focused on improved processes and technologies, an architecture

Resumen y Abstract…………………………………………………………….. iii

7.3.3 Paradigma De Desarrollo……………….…………………………. 24

13.4 Prueba Basada En Usos……………….……………….……………….. 111

Figura 5.1 Diagrama de Actividades actual de Trabajo. 9

Figura 12.7 Diseño Periodo 96

Se busca implementar sistemas de búsquedas de paquetes según sus características

2.1 Objetivo General

2.2 Objetivos Específicos

• Agilizar la mantención de la información de los servicios que se realizan entorno a

• Generar un Prototipo de Consulta de Información destinado al cliente para conocer

2.3 Mejoras Esperadas

• Agilizar los tiempos de respuesta en los servicios destinados a la atención directa al

• Establecer un control de calidad de los procesos generados por parte de la empresa.

• Dirigir los esfuerzos hacia otras áreas no abarcadas completamente.

• Análisis Orientado a Objetos

Se ha evaluado estas tres alternativas llegando a la conclusión de que por

Se especifican a continuación los ítems a tratar a lo largo del trabajo de título:

• Estudio de los procesos internos y externos realizados por parte de la empresa

• Generar un recopilación de los estudios anteriores, agrupándolos de acuerdo su

• Del punto anterior, se desprende la toma de requerimientos funcionales y no

En base a lo anterior, se apoya la gestión de acuerdo a las fases mencionadas, que

Análisis de Requerimientos Julio - Agosto 2008

Establecer requerimientos del prototipo Septiembre - Octubre 2008

Diseño del prototipo Noviembre - Diciembre 2008

Mejoras al Diseño Febrero 2009

Codificación y Pruebas Enero - Abril 2009

Tabla 4.1 Actividades del Plan de Trabajo

Cada actividad del plan de trabajo es descrita de la siguiente manera:

2 Establecer los requerimientos del prototipo

Dentro de esta etapa se realizará el análisis de la herramienta, cuyos requerimientos serán

3 Diseño del prototipo

En esta etapa se analizan los alcances y el funcionamiento que va a poseer el prototipo,

En esta etapa se realiza una revisión del trabajo correspondiente a Proyecto I y se da

Esta etapa comprende la codificación utilizando las herramientas definidas previamente en

5 Estado Del Arte

5.1 Situación Actual

5.1.1 Descripción de la empresa

Por su parte se encarga de : gestionar principalmente de todas las áreas de la empresa,

También tiene la misión de dar un patrón de soluciones a aquellos reclamos que se

Es el encargado de generar y absorber de acuerdo a la información existente los

A continuación se presenta un cuadro resumen de lo expuesto anteriormente:

Tabla 5.1 Cuadro de resumen de Actores y su Interacción con el Sistema

5.2 Flujo De Trabajo Actual

Tras acumular una cantidad de servicios estos se agrupan en rutas especificas, y se

En el caso de si un cliente quiere realizar consultas respecto a un servicio

5.3 Diagrama De Actividades Flujo Actual De Trabajo

act Diagrama de activ idad General