sistema de monitorie de empresa de transporte...

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

INFORME FINAL DEL PROYECTO PARA OPTAR AL TÍTULO PROFESIONAL DE

INGENIERO DE EJECUCIÓN EN INFORMÁTICA

Julio, 2009.

ii

Pontificia Universidad Católica de Valparaíso – Chile Facultad de Ingeniería

Escuela de Ingeniería Informática


Gustavo Rene Cisternas Silva

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

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

Julio, 2009.


i

Dedicatoria

Dedicado a mis Padres.. Quienes me apoyaron durante este largo camino

En los buenos y malos momentos, Que llevaron como fruto este logro.


ii

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.


iii

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.


iv

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


v

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


vi

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


vii

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


viii

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


ix

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


x

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


1

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.


2

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.


3

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.


4

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

Pro

yect

o I

Análisis de Requerimientos Julio - Agosto 2008

Establecer requerimientos del prototipo Septiembre - Octubre 2008

Diseño del prototipo Noviembre - Diciembre 2008

Pro

yect

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


5

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.


6

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


7

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

Administrador Principal

Persona que interactúa el sistema a nivel Administrativo, puede gestionar Usuarios, Gestionar funciones que no posee disponible otros usuarios. Gestiona o interactúa con la información de los Expediciones (Ingresar, Modificar y Consultar), Órdenes de Transporte y generar informes.

Cliente Principal

Persona interesada en obtener servicios directos con el negocio de transportes de encomiendas, revisar documentación relacionada a su perfil y consultar tarifas.


8

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.


9

5.3 Diagrama De Actividades Flujo Actual De Trabajo

act Diagrama de activ idad General

SistemaActor

Encargado Recibesolicitud de Servicio

Solicita Rut

Es clienteDesaea Registrar Datos

RegistrarCliente

FIN

Continuar Servicio

Verificar Estado

Se Autoriza

Consultar Serv icio

FIN

Generar DocumentoAsociar a

Expedición

Consultar TarifasVerificar

Tarifa

Expedicion Existe

Asignar a Expedicion

Generar Expedición

ConsultarDocumentos

Rev isar Documentos

Informar al Cliente

Existe Ruta

Crear Ruta

FIN

FIN

Enviar Expedición

FIN DE FLUJO

[NO]

[SI]

[NO]

[SI]

[SI]

[SI] [NO]

[SI]

[NO]

[SI]

[SI]

[NO]

[NO]

[SI]

[NO]

[SI]

[NO]

[SI]

[NO]

Figura 5.1 Diagrama de Actividades actual de Trabajo.

Los documentos generados pueden ser Ordenes de Transportes, internas, Empresas Dib, Facturas, etc.


10

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.


11

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.


12

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

Gestionar Expedición Gestiona toda la información relacionada a una expedición como son los tipos de órdenes de transporte.

Gestionar Orden de Transporte

Gestiona las ordenes de transporte de los servicios de la empresa y sus estados

Gestionar Call Center Gestiona las solicitudes recibidas vía telefónica o Internet para un servicio de la empresa.

Gestionar Usuarios Gestionar los usuarios asociados al sistema.

Gestionar Clientes Corresponde a la gestión de los clientes que incurren en los servicios de la empresa

Consultar Cotización Gestiona las consultas de los clientes para cotizar las tarifas de los servicios de encomienda que presta le empresa

Gestionar Servicios de Encomiendas

Gestiona los servicios de las expediciones activas o aquellas que son solicitados por parte del cliente

Consultar Cartola de Movimientos

Corresponde a las consulta dentro de un periodo determinado de los servicios y documentos asociado a un cliente.

Consultar Estado de Documentos

Corresponde a las consultas de los clientes para verificar los estados de documentos asociados a los servicios incurridos por su parte


13

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

Ref # Función Categorí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

Ref # Función Categorí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

R4.3 Registrar modificaciones sobre información en la ficha de los usuarios en

Evidente

R4.4 Consultar información relevante de los usuarios en el sistema. Evidente Módulo Mantener Clientes

Ref # Función Categoría R5.1 Registrar una nueva ficha de clientes en el sistema. Evidente R5.2 Almacenar permanentemente los clientes en el sistema. Oculta

R5.3 Registrar modificaciones sobre información en la ficha de los clientes en

Evidente

R5.4 Consultar información relevante de los socios en el sistema. Evidente Módulo Consultar Tarifas

Ref # Función Categoría R6.1 Consultar un tarifado o cotización en base a información

proporcionada por el cliente Evidente

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


14

Módulo Consultar Estado Documentos Ref # Función Categoría R7.1 Consultar información relevante a los servicios incurridos por el

cliente. Evidente

Módulo Cartola de Movimientos

Ref # Función Categoría R8.1 Consultar información relevante del estado de pagos de los

documentos adquiridos por los servicios del cliente Evidente

Módulo Gestionar Servicios de Encomienda

Ref # Función Categoría 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


15

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

Seguridad

Evitar errores en datos de entrada. El sistema debe dar seguridad a los datos almacenados en el 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.

Rendimiento

Tiempos de respuesta rápida para consultas y obtención de información relacionada al negocio y para transacciones

Soporte

Compatible con Sistema Operativo Microsoft Windows XP y versiones posteriores. Debe entregar ayuda sobre la forma de ser ocupado, en caso de cualquier eventualidad, además de contar con un manual de usuario.

Legales

Se consideran las licencias necesarias para el desarrollo, de no ser así se espera contar con herramientas gratuitas. Todas las reglas de impuestos se tienen que aplicar, por ley [3][4], durante las ventas.

Modularidad

Integración de las distintos módulos del Sistema, y es posible la integración de nuevos módulos a futuro como el sistema de GPS. Tabla 6.3 Requerimientos No Funcionales de Sistema


16

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.


17

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


18

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.


19

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.


20

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.

VAN = ∑

=

n

n 1 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


21

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.


22

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

realidad Crítico 20%

Experiencia de los integrantes del grupo de trabajo de título no está

acorde con las necesidades de la empresa

Despreciable 30%

Dimensiones de la base de datos exceden las

estimaciones iniciales Critico 30%


23

Generación de manuales de

usuarios certeros para su

uso.

Despreciable 75%

Se incorporan nuevas

funcionalidades al sistema. Marginal 40%

Diseño de interfaz de fácil

uso, intuitiva, con colores

institucionales.

Marginal 60%

Uso de herramientas

requeridas por el trabajo de

título.

Marginal 30%

Necesidad del sistema

como Herramienta de

apoyo.

Crítico 80 %

Necesidad de los clientes

de un nuevo mecanismo de

acceso a la información

Crítico 70 %

Aparecen nuevos

requerimientos que

necesitan rediseñar el

sistema

Crítico

80 %


24

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

Las dimensiones del sistema se escapan de la realidad

Dimensionar los módulos del sistema en base a sus requerimientos sin afectar su funcionalidad.

Agregar o quitar requerimientos.

Experiencia de los integrantes del grupo de trabajo de título no está acorde con las necesidades de la empresa

Comprobar a través de acercamientos de los módulos menos complicados la captación de los requerimientos.

Verificar otros antecedentes del grupo de trabajo.

Dimensiones de la base de datos exceden las estimaciones iniciales

Definir un modelo de base de datos acorde al actual usado.

Verificar el modelo actual en uso con el diseñado.

Generación de manuales de usuarios certeros para su uso.

Documentar los procesos durante el inicio del proceso de análisis.

Incorporar al cliente a través de informes de estado.

Se incorporan nuevas funcionalidades al sistema.

Verificar que las nuevas funcionalidades corresponden al sistema actual

Aplicar una estrategia para incorporar mejoras en nuevas versiones del sistema

Diseño de interfaz de fácil uso, intuitiva, con colores institucionales.

Aplicar estilo de interfaces similares al sistema en base al existente sin descartar mejoras

Incorporar funcionalidades que mejoren el uso del sistema

Uso de herramientas requeridas por el trabajo de título.

Coordinar el uso de herramienta adecuado para el desarrollo del sistema y acorde a la capacidad del grupo de trabajo

Uso de herramientas conocidas en el mercado

Necesidad del sistema como Herramienta de apoyo.

Encaminar las necesidades de los usuarios a través de los requerimientos del sistema

Definir que implementaciones se realizarán primero

Necesidad de los clientes de un nuevo mecanismo de acceso a la información

Establecer las necesidades principales de los clientes

Definir el orden de las implementaciones.

Aparecen nuevos requerimientos que necesitan rediseñar el sistema

Verificar y valorar el impacto sobre el sistema

Proponer agregar nuevos módulos al sistema en un nuevo proceso.


25

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


26

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


27

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.


28

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.


29

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.


30

• 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 Systems [11] 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.

Las herramientas de Sparx Systems [11] 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.


31

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.


32

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 (IIS). La tecnología ASP [10] 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 programar en ASP [10] 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".

ASP [10] ha pasado por cuatro iteraciones mayores, ASP [10] 1.0 (distribuido con IIS

3.0), ASP [10] 2.0 (distribuido con IIS 4.0), ASP [10] 3.0 (distribuido con IIS 5.0) y ASP.NET (parte de la plataforma .NET de Microsoft). Las versiones pre-.NET se denominan actualmente (desde 2002) como ASP [10] clásico.

En el último ASP [10] clásico, ASP [10] 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.


33

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.

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.

¿Qué es la plataforma .NET?

Herramientas

de desarrollo

Servicios Web XML

Servidores

Clientes

Experiencias

de usuario


34

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.


35

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.


36

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.


37

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


38

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


39

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.


40

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

Computador Estaciones

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 Memoria : Kingston DDR2 1GB 667Mhz KVR667D2N5 (KNG-391) Dispositivos : Mouse Optico M325BP S/Black PS2 Teclado Black Espanol K8050P PS2

Computador Servidor

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


41

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


42

9 Análisis Del Sistema 9.1 Diagrama De Casos De Uso De Contexto General

uc Caso de Uso General


Gestionar Orden de Transporte (OT)

Administrador

Cliente

Gestionar Cliente

Gestionar Expedicion

Consultar Estado Documentos

Gestionar Usuarios

Generar Cotización

Consultar Cartola Mov imientos

Gestionar Serv icios de Encomienda

Gestionar Call Center

Figura 9.1 Diagrama De Casos De Uso De Contexto General


43

9.2 Diagrama Caso De Uso Gestionar Expedición

uc Caso de Uso Gestionar Expedición

Administrador


Consultar Expedición

Modificar Expedición

Actualizar Estado OT

Actualizar Estado Factura

Actualizar Expedición

Ingresar Expedición

Verificar Expedición

Verificar Vehiculo

Anular Expedicion

«include»

«include»

«extend»

«extend»

«include»

«include»

Figura 9.2 Diagrama Caso De Uso Gestionar Expedición


44

9.3 Diagrama Caso De Uso Gestionar OT

uc Caso de Uso Gestionar OT


Verificar Folio Solicitud

Generar Folio Solicitud

Administrador

Ingresar OT

Modificar OT

Anular OT

Consultar OT

«include»

«include»

Figura 9.3 Diagrama Caso De Uso Gestionar OT


45

9.4 Diagrama Caso De Uso Consultar Cartola De Movimientos

uc Caso de Uso Consultar Mov imientos


Solicitar Periodo a Consultar

Cliente

Generar Informe

Consultar Mov imientos Cliente

Verificar Periodo

Exportar Cartola

«include»«include»

«include»

«extend»

Figura 9.4 Diagrama Caso De Uso Consultar Cartola de Movimientos


46

9.5 Diagrama Caso De Uso Consultar Cotización

uc Caso de Uso Generar Cotizacion


Cliente

Ingresar Datos

Veriricar Tarifado Cliente

Calcular Tarifa

Imprimir Tarifa

Env iar Cotizacion

«extend»

«extend»


Figura 9.5 Diagrama Caso De Uso Consultar Cotización


47

9.6 Diagrama Caso De Uso Consultar Estado De Documentos

uc Caso de Uso Consultar Estado Documentos



Cliente

Generar InformeVerificar PeriodoExportar Consulta

Solicitar Documento a Consultar

Recuperar Documentos del

Periodo

«extend»

«include»

«include»

«include»

«include»

Figura 9.6 Diagrama Caso De Uso Consultar Estado De Documentos


48

9.7 Diagrama Caso De Uso Gestionar Servicios De Encomienda

uc Caso de Uso Gestionar Serv icios de Encomienda


Cliente

Ingresar Solicitud Serv icio

Verificar Estado Cliente

Consultar Serv icio

Env iar Solicitud

Verificar Estado Serv icio

Verificar Puntos de Control

Generar Registro de Serv icios


«include»

«include»

«include»

Figura 9.7 Diagrama Caso De Uso Gestionar Servicios De Encomienda


49

9.8 Diagrama Caso De Uso Gestionar Clientes

uc Caso de Uso Gestionar Clientes


Ingresar Cliente

Modificar Cliente

Eliminar Cliente

Consultar Cliente

Asignar Tarifa

Administrador

«include»

«include»

Figura 9.8 Diagrama Caso De Uso Gestionar Clientes


50

9.9 Diagrama Caso De Uso Gestionar Call Center

uc Caso de Uso Gestionar Call Center


Ingresar Solicitud

Modificar Solicitud

Anular Solicitud

Consultar Solicitud



Env iar Solicitud

Administrador

«include»

«include»

«include»

«include»

«include»

Figura 9.9 Diagrama Caso De Uso Gestionar Call Center


51

9.10 Diagrama Caso De Uso Gestionar Usuario

uc Caso de Uso Gestionar Usuarios


Asignar Sucursal

Verificar Sucursal

Ingresar Usuario

Modificar Usuario

Eliminar Usuario

Consultar Usuario

Administrador

«include»

«include»

«include»

Figura 9.10 Diagrama Caso De Uso Gestionar Usuario


52

9.11 Diagrama Caso De Uso Login

uc Caso de Uso Login


Cliente

Administrador

LoginVerificar Usuario«include»

Figura 9.11 Diagrama Caso De Uso Login


53

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.


54

Caso de Uso Eliminar Cliente Actores Administrador (A) Precondiciones � El Administrador debe estar logeado en el sistema.

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

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


55

Caso de Uso Modificar Cliente Actores Administrador (A) Precondiciones � El Administrador debe estar logeado en el sistema.

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

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


56

Caso de Uso Consultar Cliente Actores Administrador (A) Precondiciones � El Administrador debe estar logeado en el sistema.

� 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 Escenario Alternativo

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.


57

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.

Escenario Alternativo 4a. Cliente no existe en el sistema,



58

Caso de Uso Modificar Orden de Transporte (OT) Actores Administrador(A) Precondiciones � El Administrador se encuentra logeado en el sistema.

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

Escenario Alternativo 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 Administrador para que corrija la consulta o la cancele.


59

Caso de Uso Anular Orden de Transporte (OT) Actores Administrador(A) Precondiciones � El Administrador se encuentra logeado en el sistema.

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




60

Caso de Uso Consultar Expedición Actores Administrador (A) 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.

Escenario Alternativo 4a. S: verifica que la expedición no existe y corresponde al período escogido, se envía mensaje al

Administrador para que corrija la consulta o la cancele.

Caso de Uso Modificación Expedición Actores Administrador (A) 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.

Escenario Alternativo 4a. S: verifica que la expedición existe y corresponde al período escogido, se envía mensaje al

Administrador para que corrija la consulta o la cancele.


61

Caso de Uso Ingresar Expedición Actores Administrador (A) 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.

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


62

Caso de Uso Anular Expedición Actores Administrador(A) Precondiciones � El Administrador se encuentra logeado en el sistema.

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





63

Caso de Uso Ingresar Solicitud Call Center Actores Administrador(A) Precondiciones � El Administrador se encuentra logeado en el sistema.


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

Escenario Alternativo 5a. Cliente no existe en el sistema,



64

Caso de Uso Modificar Solicitud de Call Center Actores Administrador(A) Precondiciones � El Administrador se encuentra logeado en el sistema.

� 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




65

Caso de Uso Anular Solicitud de Call Center Actores Administrador(A) Precondiciones � El Administrador se encuentra logeado en el sistema.

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





66

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.

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


67

Caso de Uso Ingresar Usuario Actores Administrador (A) Precondiciones � El Administrador debe estar logeado en el sistema.

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

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


68

Caso de Uso Modificar Usuario Actores Administrador (A) Precondiciones � El Administrador debe estar logeado en el sistema.

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

Escenario Alternativo 5a. Usuario no existe.

1. S: verifica que el usuario no se encuentra ingresado en el sistema, se envía un mensaje al

Administrador para que corrija el ingreso o lo cancele.

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.


69

Caso de Uso Consultar Usuario Actores Administrador (A) Precondiciones � El Administrador debe estar logeado en el sistema.

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

Escenario Alternativo 5a. Usuario no existe.

1. S: verifica que el usuario no se encuentra ingresado en el sistema, se envía mensaje al Administrador para que corrija el ingreso o lo cancele.


70

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.

Escenario Alternativo 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 � El Cliente debe estar registrado en el sistema.

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

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


71

Caso de Uso Consultar Cartola de Movimientos Actores Cliente (C) Precondiciones � El Cliente debe estar registrado en el sistema.

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

Escenario Alternativo 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

Escenario Alternativo 3a. S: no existe tarifado para los parámetros ingresados y se solicita un nuevo ingreso de información

al cliente.


72

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


73

10.2 Modificar Cliente

sd Modificar Cliente

Administrador

Sistema

Modificar_datos_Cliente()

Solici tar 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


74

10.3 Eliminar Cliente

sd Eliminar Cliente

Administrador

Sistema

Eliminar Socio()

Solicitar Rut Cliente

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


75

10.4 Consultar Cliente

sd Consultar Cliente

Administrador

Sistema

Consultar Cliente

Solicitar Rut 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


76

10.5 Ingresar OT

sd Ingresar OT

Administrador

Sistema

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


77

10.6 Modificar OT

sd Modificar OT

Administrador

Sistema

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


78

10.7 Anular OT

sd Eliminar OT

Administrador

Sistema

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


79

10.8 Login

sd login

Cliente y/o Administrador

Sistema

Ingresar Login

Solicitar datos Usuario

Ingresar Datos Usuarios(Usuario,Contraseña)

Verficar datos

Confirmar Ingreso

Figura 10.8 Diagrama de Secuencia Login


80

10.9 Consultar Estado de Documentos

sd Listar Informes

Administrador

Sistema

Listar Informes ()

Despliega plantil la

Selecciona Informe

Despliega Informe

Selecciona periodo

Genera Informe

Figura 10.9 Diagrama de Secuencia Consultar Estado de Documentos


81

10.10 Ingresar Expedición

sd Ingresar Expedición

Administrador

Sistema

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


82

10.11 Anular Expedición

sd Anular Expedicion

Administrador

Sistema

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


83

10.12 Modificar Expedición

sd Modificar Expedición

Administrador

Sistema

Modificar Expedicion

Solicita Periodo

ingresaPeriodo(Periodo)

Solicita Folio Expedicion

Ingresa FolioExpedicion(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


84

10.13 Consultar Cotización

sd Consultar Tarifas

Administrador

Sistema

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


85

11 Diagramas De Actividad Flujo Futuro De Trabajo 11.1 Flujo Futuro General

act fluj o general futuro

SistemaActor

Administrador ingresa al sistemalogin

Existe usuario

Fin Ingreso

DespliegaPagina

PrincipalSelecciona Modulo



Gestionar Orden de Transporte

Gestionar Orden deTransporte

Gestionar Usuario

Gestionar Usuario

Gestior Call CenterGestionar Call Center

Gestionar Cliente

Gestionar Cliente

Salir del Sistema

fin

Solicitar Periodo

Desplegar Formulario

Realizaroperacion sobre

expedicion VerificarDatos

RegistrarOperacion

fin

Solicitar periodo Desplegar Formulario

Realizar Operacionsobre OT Verificar Datos

registrarOperacion

fin

Desplegarformulario

Realizar operacionsobre usuario Verificar datos usuario Registrar operacion

fin

Despliega formulariorealizar operacion sobrecall center

v erifica datos desolicitud

registra operacion delcall center

fin

Desplegar Formulario

Realizar operacion sobrecliente

v erificar datos cliente

registra operacion decliente

fin

[no][si]

[si]

[no]

[si]

[no]

[si]

[no]

[si]

[no]

[si]

[no]

Figura 11.1 Diagrama de Actividades Flujo Futuro General


86

11.2 Flujo Futuro Ingresar Expedición

act Flujo Futuro ingresar expedicion

SistemaActor

Administrador requiere ingresar expedicionLogin

existe usuario

finSolicita periodo

Selecciona periodo Verifica periodoingresado

Solicita datos v ehiculo

Periodo Existe

Ingresa Vehiculo

Existe vehiculo

Verifica Vehiculo

Solicita Datos expedicionIngresa Datos expedicion

Verifica datos

Registra Expedicion

Emite comprobante

Verifica comprobante

ingresar otra expedicion

fin

genera folio

[no][si]

[si ]

[no]

[si ]

[no]

[no]

[si]

Figura 11.2 Diagrama de Actividades Flujo Futuro Ingresar Expedición


87

11.3 Flujo Futuro Ingresar Orden de Transporte

act flujo futuro ingresar ot

SistemaActor

Administrador requiere ingresar OTLogin

existe usuario

finSolicita periodo

Selecciona periodo Verifica periodoingresado

Solicita datos OT

Periodo Existe

Ingresa Datos OT Verifica datos

Solicita Folio expedicion

Ingresa folio expedicion

Verifica datos

Registra OT

Emite comprobante

Verifica comprobante

ingresar otra ot

fin

genera folio

existe expedicion

[no][si]

[no]

[si ]

[si]

[no]

[s]

[no]

Figura 11.2 Diagrama de Actividades Flujo Futuro Ingresar Orden de Transporte


88

11.4 Flujo Futuro Consultar Cotización

act flujo futuro cotizacion

SistemaActor

Cliente desea generar unacotizacion

Login

existe usuario

finSolicita datos cotizacion

Ingresa datos a cotizar Verifica tarifa delcliente

Calcula Tarifa

Despliega Cotizacion

rev isa cotizacion

escoge env iar cotizacion

registra la cotizacion

Env ia la cotizacion aCall center

emite comprobante

rev isa comprobante

fin

[no][si]

Figura 11.3 Diagrama de Actividades Flujo Futuro Consultar Cotización


89

12 Diseño 12.1 Modelo Del Dominio

class Modelo Dominio

Usuario

Expedición_Mes_Anno

OT_Mes_Anno

Detalle_OT_Mes_Anno

Factura_Mes_Anno

Detalle_Factura_Mess_Anno

Tarifa

Periodo

Vehiculo

Perfil

Cartola

Sucursal

CallCenter

Tipo_Vehiculo

AdministradorCliente

OTI

OT

OT DIB

Tarifa WEB Tarifa Mov il

Expedicion Web

Expedicion Mov il

1..*

Tiene

1

1..*

asignada

1

1

tiene

*

1..*Tiene

1

1..*

asignada1

1

tiene

1..*

1..*

tiene

1

1

tiene

1..*

1

tiene

*

1..*

posee

1

1..*

asignado

1

*

tiene 1

1..

registra

1..*

1..*

tiene

1

Figura 12.1 Diagrama de Diseño Modelo Del Dominio


90

12.2 Modelo Conceptual De Clases

object modelo Clases

Usuario

- Rut- Giro- Razon- Direccion- Comuna- Ciudad- Fono1- Fono2- Casi lla- Fax- Mail- Url- Saldo- Credito- Disponible- Estado- HoraCierre- Contraseña

+ Ingresar Usuario() : void+ Modificar Usuario() : void+ El iminar Usuario() : void+ Consultar Usuario() : void

Expedición_Mes_Anno

- OidExpedicion- Fecha- Neto- Kgs- Cancela- Estado- Periodo

+ Ingresar Expedicion() : void+ Modificar Expedicion() : void+ Consultar Expedicion() : void+ Anular Expedicion() : void

OT_Mes_Anno

- OidOt- Vencimiento- Telefono- Neto- Total- Saldo- Estado- Obs- Desde- Hasta- Periodo- TipoOt- Rut_Rec- Nombres_Rec- Ap_Pat_Rec- Ap_Mat_REC

+ Ingresar OT() : void+ Modificar OT() : void+ Anular OT() : void+ Consultar OT() : void

Detalle_OT_Mes_Anno

- Documento- Bulto- Kilos- Mts3- ValorUnitario

Factura_Mes_Anno

- OidFactura- Neto- Total- Iva- Estado- Razón- Fecha- Dirección- Ciudad- Desde- Hasta- Obs- Periodo- Rut_Rec- Nombres_Rec- Ap_Pat_Rec- Ap_Mat_Rec

+ Actualizar Estado Factura() : void+ Actualizar Estado OT() : void

Detalle_Factura_Mess_Anno

- Documento- Ki los- Bulto- Mts3- ValorUnitario

Tarifa

- OidTari fa- Descripcion- Valor

+ Asignar Tari fa() : void+ Calcular Tarifa() : void

Periodo

- OidPeriodo- Descripcion- Estado

+ Verificar Periodo() : void

Vehiculo

- OidVehiculo- Anno- Patente- Carga- Marca- FechaRevision- Modelo- NChasis- NMotor

+ Verificar Vehiculo() : void

Perfil

- OiPerfi l- Descripcion

Cartola

- OidCartola- Fecha- Periodo- Obs

+ Exportar Cartola() : void

Sucursal

- OidSucursal- Descripcion- Estado- Obs

+ Asignar Sucursal() : void+ Verificar Sucursal() : void

CallCenter

- OidFol io- Fecha- Estado- Des_Rut- Des_Direccion- Des_Telefono- Des_Contacto- Des_Hora_Cierre- Des_Hora_Llamada- Rec_Rut- Rec_Nombre- Rec_Direccion- Rec_Comuna- Rec_Sector- Rec_Telefono

+ Ingresar Solicitud() : void+ Modificar Sol ici tud() : void+ Anular Solicitud() : void+ Consultar Sol ici tud() : void

Tipo_Vehiculo

- OidTipo- Descripcion

1..*

posee

1

1

tiene

*

1..*

tiene

1

1

tiene

1..*

1..*

asignado

1

1..*

Tiene

1

1

tiene

1..*

1..*

asignada

1

1..*

Tiene

1

1..*

asignada

1

1

tiene

*

*

tiene

1

1..

registra

1..*

1..*

tiene

1

Figura 12.2 Diagrama de Diseño Modelo Conceptual De Clases


91

12.3 Modelo Entidad Relación

Figura 12.3 Diagrama de Diseño Modelo Entidad Relación


92

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.


93

12.4.1 Pagina Principal

Figura 12.4 Diseño Pagina Principal


94

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


95

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


96

12.4.4 Periodo

Figura 12.7 Diseño Periodo


97

12.4.5 Modulo de Call Center

Figura 12.8 Módulo Call Center

Figura 12.9 Módulo Edición Call Center


98

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


99

12.4.7 Modulo Vehiculo

Figura 12.12 Módulo Vehiculo

Figura 12.13 Módulo Edición Vehiculo


100

12.4.8 Módulo Expedición

Figura 12.14 Módulo Expedición

Figura 12.15 Módulo Edición Expedición


101

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


102

12.4.10 Módulo Estados de Documentos

Figura 12.18 Módulo Estados de Documentos


103

12.4.11 Acceso Restringido

Figura 12.19 Acceso Restringido


104

12.4.12 Vista Palm Menú de Utilidades

Figura 12.20 Menú Utilidades Palm


105

12.4.13 Búsqueda de Expedición Palm

Figura 12.21 Busqueda de Expedición Palm


106

12.4.14 Consulta de Expedición

Figura 12.22 Consulta de Expedición Palm


107

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.


108

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


109

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.


110

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


111

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.


112

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.


113

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.


114

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.


115

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.


116

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.


117

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


118

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 Prueba

A probar

Condición Entrada Salida

Validar Usuario

Sistema Estar ingresado en el sistema.

Nombre Usuario y Clave

de Acceso

1.- Datos correctos: pasar a operaciones del usuario. 2.- Caso contrario: solicitar reingreso de los datos o registrarse en el sistema. 3.- Faltan datos: solicitar ingreso del o los datos faltantes.

Ingresar Usuario

Sistema Administrador logeado.

Ingresar todos los

datos solicitad

os

1.- Datos correctos: mostrar funciones de acuerdo al tipo de usuario. 2.- Datos incorrectos: solicitar reingreso de los datos. 3.- Faltan datos: solicitar ingreso del o los datos faltantes. 4.- Nombre de usuario ya existe: mostrar mensaje de error y solicitar que ingrese un nuevo nombre.

Consultar Estado de

Documentos

Sistema Cliente logeado

Ingresar todos los datos y pasos

solicitados

1.- Datos correctos: mostrar mensaje de paso exitoso. 2.- Datos incorrectos: solicitar reingreso de los datos. 3.- Faltan datos: solicitar ingreso del o los datos faltantes. 4.- Paso de generación de informe fallido: solicitar 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 Información

Sistema Administrador logeado.

Ninguna 1.- Borra Información: mostrar mensaje de 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


119

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


120

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.


121

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.


122

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.


123

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

requerimientos estudio o canalización de los problemas y entregar al cliente de manera descriptiva de estos.

Tarifa Precio a pagar por un servicio contratado por el cliente, o precio cobrar por un

servicio prestado por la empresa.

visión Concepción de una realidad que se puede generar en algún momento.

Gestión Conjunto de acciones llevadas a cabo para solucionar un asunto, o administrar

una entidad.

Logear Identificar a un usuario válido en el sistema.

Logout Finalizar sesión de un usuario válido en sistema.

Orden de Transporte Documento generado por la empresa similar a una guía de despacho con el

detalle de los servicios a prestar en esa expedición.

Rol Función que una persona desempeña en un lugar o situación.

Merma Substracción o pérdida de algún artículo que afecta directamente a la empresa y

debe incurrir en su pago a terceros.

Folio Identificador autoincrementable asociado a documentos de la empresa.

Open Source Código fuente gratuito a disposición de usuarios que pueden trabajar y

modificar directamente su funcionamiento

PAY BACK Periodo de recuperación de una inversión.

Tabla 16.1 Glosario


124

16.4 Diagrama Caso De Uso General Detallado

uc Caso de Uso Detallado


Cliente

LoginVerificar Usuario

Administrador


Generar Informe

Consultar Mov imientos Cliente

Verificar Periodo

Solicitar Documento a Consultar

Consultar Estado Documentos

Generar Cotización

Consultar Cartola Mov imientos

Gestionar Serv icios de Encomienda

Exportar Consulta

Recuperar Documentos del

Periodo

Exportar Cartola

Veriricar Tarifado Cliente

Calcular Tarifa

Imprimir Tarifa

Env iar Cotizacion

Ingresar Solicitud Serv icio

Verificar Estado Cliente

Consultar Serv icio

Env iar Solicitud

Verificar Estado Serv icio

Verificar Puntos de Control

Generar Registro de Serv icios

Asignar Sucursal Verificar SucursalIngresar Usuario

Modificar Usuario

Eliminar Usuario

Consultar Usuario

Ingresar Solicitud

Modificar Solicitud

Anular Solicitud

Consultar Solicitud



Env iar Solicitud

Ingresar Datos

Ingresar Cliente

Modificar Cliente

Eliminar Cliente

Consultar Cliente

Asignar Tarifa

Consultar Expedición

Modificar Expedición

Actualizar Estado OT

Actualizar Estado FacturaActualizar Expedición

Ingresar Expedición

Verificar Expedición

Verificar Vehiculo

Anular Expedicion

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«extend»

«extend»

«include»

«include»

«include»

«include»

«include»

«include»

«extend»

«include»

«extend»

«include»

«extend»«include»

«include»

«include»

«include»

«include»

«include»

«include»

«extend»

Figura 16.1 Diagrama Caso De Uso General Detallado

sistema de monitorie de empresa de transporte...

Documents