Upload
dangthu
View
218
Download
1
Embed Size (px)
Citation preview
1
UNIVERSIDAD TECNOLOGICA DEL PERU
FACULTAD DE INGENIERÍA DE SISTEMAS Y ELECTRÓNICA
ESCUELA DE INGENIERÍA DE SISTEMAS
DISEÑO DE UN APLICATIVO MOVIL
PARA LAS INSPECCIONES
VEHICULARES DE PACIFICO SEGUROS
ELABORADO POR:
MAGALY RUBÍ JAYO VEGA
ASESOR:
MBA. CARLOS ZORRILLA VARGAS
Tesis para optar el Título de Ingeniero de Sistemas
Lima – Perú
2014
2
DEDICATORIA
Dedico este proyecto a Dios que me guió para
seguir adelante y me dio las fuerzas para no
desfallecer en el intento.
3
AGRADECIMIENTO
Agradezco a Dios, por haber permitido
desarrollarme académicamente en esta
institución educativa y por darme fuerzas
para realizar este proyecto. Asimismo a mis
padres por haberme apoyado en el periodo
académico.
4
INTRODUCCION
En la actualidad el mercado automotor es uno de los sectores de mayor tendencia al
crecimiento, cada vez se adquieren más unidades por medio de créditos vehiculares,
préstamos, etc[1].
Así mismo, el robo de vehículos y autopartes va en aumento. Por ello, las entidades
bancarias exigen que los clientes cuenten con una póliza vehicular. Sin embargo, algunos
de ellos prefieren contratar, voluntariamente, una póliza y tener la seguridad que, en caso
ocurra un siniestro o robo, el seguro los va a indemnizar, previo pago de una prima según
especifica el contrato.
Por ejemplo, si un automóvil cuesta US$ 10,000, el monto de la prima del seguro, en
promedio, es US$ 700. Por ello, si roban el vehículo, para recuperarlo solo se deberá
asumir el monto de la prima más los deducibles que nos imponga la compañía de
seguros por el siniestro ocurrido.
Ante todos estos sucesos, las empresas aseguradoras, con la finalidad de verificar el
estado de la unidad, realizan la inspección previa a la contratación de seguros. En este
trabajo, contribuimos a que el proceso de adquisición de un seguro vehicular sea más
rápido y eficiente. Mediante el uso de tecnologías crearemos un aplicativo móvil que
permita al inspector obtener los datos exactos de la unidad con todas las características
técnicas en menor tiempo permitiendo la evaluación y/o suscripción más especializada y,
al mismo tiempo, minimizar costos para la empresa evitando tareas de digitación y
validación redundante.
Por consiguiente, la investigación abarca desde un análisis del problema hasta el diseño
de un aplicativo móvil para la inspección de vehículos de la empresa Pacífico Seguros.
Usando metodologías de desarrollo y viabilidad económica plasmaremos el problema y la
solución.
5
INDICE GENERAL
INTRODUCCION .............................................................................................................. 4
INDICE GENERAL ........................................................................................................... 5
INDICE DE TABLAS ......................................................................................................... 6
INDICE DE FIGURAS ....................................................................................................... 7
CAPÍTULO 1: ASPECTOS GENERALES ......................................................................... 9
1.1. DEFINICIÓN DEL PROBLEMA ......................................................................... 9
1.2. DEFINICIÓN DE LOS OBJETIVOS ...................................................................14
1.2.1. OBJETIVO GENERAL ................................................................................14
1.2.2. OBJETIVOS ESPECIFICOS .......................................................................14
1.3. JUSTIFICACIÓN DE LA INVESTIGACIÓN ........................................................15
CAPÍTULO 2: FUNDAMENTO TEORICO ........................................................................16
2.1. ANTECEDENTES..............................................................................................16
2.1.1. NIVEL NACIONAL ......................................................................................16
2.1.2. NIVEL INTERNACIONAL ..........................................................................19
2.2. MARCO TEÓRICO ...........................................................................................21
2.3. MARCO CONCEPTUAL ....................................................................................27
2.4. MARCO METODOLOGICO ...............................................................................29
2.5. MARCO LEGAL .................................................................................................33
CAPÍTULO 3: DESARROLLO DE LA APLICACIÓN ........................................................34
3.1. MODELAMIENTO..............................................................................................34
3.2. DESARROLLO ..................................................................................................52
3.3. APLICACIÓN .....................................................................................................69
3.4. MONITOREO ....................................................................................................71
3.5. MANTENIMIENTO .............................................................................................73
3.6. GESTIÓN DEL PROYECTO ..............................................................................78
CAPÍTULO 4: ANALISIS DE COSTO BENEFICIO ..........................................................84
4.1. ANALISIS DE COSTO .......................................................................................84
4.3. ANALISIS DE SENSIBILIDAD ...........................................................................87
CONCLUSIONES ............................................................................................................88
RECOMENDACIONES ....................................................................................................89
BIBLIOGRAFIA ................................................................................................................90
6
INDICE DE TABLAS
Tabla 1 Resumen por año de inspecciones .....................................................................10
Tabla 2 Resumen por un mes de inspecciones................................................................11
Tabla 3 Resumen por un día de inspecciones .................................................................12
Tabla 4 Metodologías de desarrollo de Software .............................................................29
Tabla 5 Herramientas para el diseño ...............................................................................31
Tabla 6 Especificación de caso de uso: Ingreso del inspector al sistema.........................40
Tabla 7 Especificación de caso de uso: Consulta de información del cliente/vehículo .....41
Tabla 8 Especificación de caso de uso: Registra inspección ...........................................42
Tabla 9 Herramientas para el modelado de datos ............................................................47
Tabla 10 Herramientas para la base de datos .................................................................50
Tabla 11 Sistemas operativos móviles .............................................................................63
Tabla 12 Cuadro comparativo de características técnicas de tablets ...............................65
Tabla 13 Proceso de pruebas del aplicativo .....................................................................67
Tabla 14 Plan del proyecto ..............................................................................................79
Tabla 15 Cuadro comparativo de costos ..........................................................................84
Tabla 16 Costos del proyecto ..........................................................................................85
Tabla 17 Flujo de caja del proyecto .................................................................................86
Tabla 18 Análisis de sensibilidad de costos .....................................................................87
7
INDICE DE FIGURAS
Figura 1 Indicadores de la evolución de tiempo de emisiones con inspección .................10
Figura 2 Evolución de inspecciones Vehiculares por Año – Lima ....................................11
Figura 3 Evolución de inspecciones Vehiculares por Mes/Día–Lima ................................12
Figura 4 Diagrama Causa – Efecto ..................................................................................13
Figura 5 Sistema de Inspecciones ...................................................................................17
Figura 6 Módulos Funcionales del Guidwide - Programa Creo ........................................18
Figura 7 Cronograma e Release 0 Programa CREO .......................................................18
Figura 8 Aplicativo móvil Fuente: movilrepot.es ..............................................................20
Figura 9 Distribución de primas del mercado asegurador Ramos riesgos generales .......21
Figura 10 Cantidad de trabajadores 2011 y 2012 ............................................................23
Figura 11 Composición Accionara de Pacífico Seguros S.A ............................................23
Figura 12 Diagrama de bloque de Emisión de automóviles .............................................24
Figura 13 Línea de Negocio de Pacífico Asiste ................................................................25
Figura 14 Flujo de inspección vehicular Actual ................................................................26
Figura 15 Flujo de inspección vehicular Propuesto ..........................................................27
Figura 16 Marco conceptual – Tesis ................................................................................28
Figura 17 Artículos de la ley N° 29946 .............................................................................33
Figura 18 Diagrama de Contexto Gestionar inspecciones ...............................................36
Figura 19 Diagrama de nivel superior ..............................................................................37
Figura 20 Diagrama de detalle – Consultar inspección ....................................................37
Figura 21 Diagrama de detalle - Realizar inspección .......................................................38
Figura 22 Diagrama de clases .........................................................................................39
Figura 23 Actores del Sistema: Inspector .........................................................................39
Figura 24 Diagrama de casos de uso: Ingreso del inspector al sistema ...........................40
Figura 25 Diagrama de casos de uso: Consulta de información del Cliente/Vehículo ......41
Figura 26 Diagrama de casos de uso: Registra inspección ..............................................42
Figura 27 Diagrama de secuencia: Ingreso del inspector al sistema ................................43
Figura 28 Diagrama de secuencia: Consulta información del cliente/ vehículo ................44
Figura 29 Diagrama de secuencia: Registra inspección ...................................................45
Figura 30 Diagrama de colaboración ...............................................................................46
Figura 31 Modelamiento de la base de datos ..................................................................49
Figura 32 Pantalla de acceso al aplicativo móvil ..............................................................52
Figura 33 Validación de datos ingresados .......................................................................53
8
Figura 34 Consultar inspecciones ....................................................................................54
Figura 35 Resultados de búsqueda de inspección ...........................................................54
Figura 36 Mensaje de consulta de inspecciones ..............................................................55
Figura 37 Bandeja de actividades ....................................................................................55
Figura 38 Datos de la inspección .....................................................................................57
Figura 39 Editar estado de la inspección .........................................................................58
Figura 40 Características del vehículo .............................................................................58
Figura 41 Observaciones de la inspección .......................................................................59
Figura 42 Accesorios del vehículo ...................................................................................60
Figura 43 Capturar u Obtener fotografías ........................................................................60
Figura 44 Capturar fotografías del vehículo .....................................................................61
Figura 45 Grabar estado de inspección ...........................................................................61
Figura 46 Envío de constancia de la inspección ..............................................................62
Figura 47 Arquitectura del aplicativo móvil .......................................................................69
Figura 48 Funcionamiento del aplicativo móvil .................................................................70
Figura 49 Procedimiento de monitoreo ............................................................................72
Figura 50 Encuesta de Satisfacción del Usuario ..............................................................73
Figura 51 Diagrama de bloques soporte a usuarios .........................................................78
Figura 52 Cronograma de actividades .............................................................................81
Figura 53 Informe semanal del proyecto ..........................................................................82
Figura 54 Relación de lecciones aprendidas ....................................................................83
9
CAPÍTULO 1: ASPECTOS GENERALES
1.1. DEFINICIÓN DEL PROBLEMA
La demanda de los seguros vehiculares presenta un incremento del 13% anual [2]. Esto
se debe a que las personas prefieran contar con un respaldo frente a eventos
inesperados de pérdida como robos, choques, volcaduras etc. Que pongan en riesgo su
patrimonio (inversión).
La situación actual del grupo de empresas aseguradoras en nuestro país, en el ramo de
seguros de autos, realizan inspecciones vehiculares con la finalidad de obtener
información exacta del estado y equipamiento como accesorios musicales, aros, etc.
Sin embargo, este proceso no es el más óptimo, debido a que el inspector registra
manualmente los datos en una ficha de inspección y captura las fotografías con una
cámara digital; culminada la inspección, retorna a las oficinas de Pacífico seguros para
registrar los formularios en el sistema y descargar las fotografías en una carpeta
compartida. Todos estos procedimientos manuales y traslados innecesarios generan que
la emisión de la unidad se realiza en mayor tiempo y el gasto es innecesario.
Observamos que en los 12 últimos meses no se cumple con los tiempos establecidos
para realizar una inspección (ver Figura 1). Muestra la evolución del tiempo y
cumplimiento de las emisiones con inspección y se mantiene tendencia de demora
excesiva en este proceso.
Las inspecciones vehiculares realizadas en el año 2014 se ha incrementado en un
12.42% con respecto al año anterior, asimismo el tiempo promedio de cada inspección a
aumentando considerablemente (ver Figura 2).
En la Tabla 1 se puede apreciar el resumen por año del proceso de inspección vehicular.
10
Figura 1 Indicadores de la evolución de tiempo de emisiones con inspección
Fuente: Indicadores de servicio de Pacífico Seguros Agosto 2014
En la Tabla 1 se observa que el número de inspecciones a estado en constante
incremento cada año, y que el promedio del tiempo de registro de inspecciones se
incrementado considerablemente. Podemos observar el crecimiento en forma visual en la
Figura 2.
Tabla 1 Resumen por año de inspecciones Fuente: Pacífico Seguros SA
AÑO
Cantidad
de
inspectores
Cantidad de
inspecciones
realizadas
Tiempo
promedio
de registro
In situ(hrs)
Tiempo
promedio de
registro en
Oficina (hrs)
Total de tiempo
promedio por
inspección(hrs)
2012 8 23,360 7,787 13,627 21,413
2013 9 23,908 7,969 13,946 21,915
2014 11 24,638 10,266 14,372 24,638
11
Figura 2 Evolución de inspecciones Vehiculares por Año – Lima
Fuente: Indicadores de servicio de Pacífico Seguros Agosto 2014
En la Tabla 2 y Tabla 3 se observa el número de inspecciones realizadas en promedio
en un mes y en un día respectivamente. Podemos observar el crecimiento de las
inspecciones en forma visual en la Figura 3.
Tabla 2 Resumen por un mes de inspecciones Fuente: Pacífico Seguros SA
MES
Cantidad
de
inspectores
Cantidad de
inspecciones
realizadas
Tiempo
promedio
de registro
In situ(hrs)
Tiempo
promedio
de registro
en Oficina
(hrs)
Total tiempo
promedio(hrs)
ene-14 11 2,500 872 1,221 2,093
19,000
20,000
21,000
22,000
23,000
24,000
25,000
2012 2013 2014
Nro
. de
Insp
ecc
ion
es
PERIODO
Cantidad de inspecciones realizadas
Total de tiempo promedio por inspección(hrs)
12
Tabla 3 Resumen por un día de inspecciones Fuente: Pacífico Seguros SA
DIACantidad de
inspectores
Cantidad de
inspecciones
realizadas
Tiempo
promedio de
registro In
situ(hrs)
Tiempo
promedio de
registro en
Oficina (hrs)
Total tiempo
promedio(hrs)
15/08/2014 1 7 3 4 7
Figura 3 Evolución de inspecciones Vehiculares por Mes/Día–Lima Fuente: Indicadores de servicio de Pacífico Seguros Agosto 2014
En la Figura 4, se muestra el diagrama de causa y efecto, donde se explica de forma
grafica el problema de inspección vehicular no optima o deficiente.
0
500
1,000
1,500
2,000
2,500
MES DIA
Nro
. de
Insp
ecc
ion
es
PERIODO
Cantidad de inspecciones realizadas Total tiempo promedio(hrs)
13
Figura 4 Diagrama Causa – Efecto
Fuente: Elaboración propia
Identificamos 6 principales causas que originan una inspección vehicular deficiente:
Demora excesiva en el registro de la inspección in situ y traslado a la oficina.
Errores de digitación al transcribir los datos.
Incremento de robos de vehículos, lo cual generó incremento de la demanda de
seguros.
El uso de herramientas defectuosas y obsoletas de la organización.
Re digitación innecesaria de las fichas de inspección.
La falta de un control a las inspecciones.
Nuestra investigación se enfocará sobre 3 causas principales:
Demora excesiva en el registro de la inspección in situ y traslado a la oficina.
Errores de digitación al transcribir los datos.
Reproceso innecesario de las fichas de inspección.
14
Debido al tiempo limitado que contamos para el desarrollo de la investigación, no nos
enfocaremos las 3 causas restantes, debido a que requieren un mayor análisis y más
tiempo para poder plantear una solución.
Incremento de robos de vehículos, lo cual generó incremento de la demanda de
seguros.
El uso de herramientas defectuosas y obsoletas de la organización.
La falta de un control a las inspecciones.
Con el uso del aplicativo móvil evitaremos el traslado a las oficinas para poder dejar las
fichas de inspección al asistente, no será necesario que vuelvan a digitar el formulario de
inspección y evitando gasto innecesario en movilidad.
1.2. DEFINICIÓN DE LOS OBJETIVOS
1.2.1. OBJETIVO GENERAL
Diseñar un aplicativo móvil utilizando tecnologías de información, que permita al inspector
realizar el registro en línea de las inspecciones vehiculares de Pacifico Seguros.
1.2.2. OBJETIVOS ESPECIFICOS
a) Identificar, detallar y diseñar los requerimientos para el diseño del aplicativo
móvil.
b) Seleccionar la plataforma tecnológica de la empresa para diseñar la aplicación
propuesta.
c) Diseñar la interfaz gráfica y amigable que facilite el registro de las inspecciones
en línea.
15
1.3. JUSTIFICACIÓN DE LA INVESTIGACIÓN
Porque actualmente el mercado de seguros vehiculares es el sector con alto crecimiento
[3]. Sin embargo, el proceso de inspección no es el más óptimo ante la demanda actual
debido a que el proceso es manual generando demora excesiva y gasto innecesario de
recursos.
El proceso de carga manual de la información trae consigo errores de digitación y pérdida
de la misma. Pacifico Seguros contrata personal adicional para que ingresen los datos al
sistema, lo cual incrementa los gastos administrativos.
Diseñar un aplicativo móvil para la inspección de vehículos evita procesos manuales e
ineficientes. El diseño está sustentado en base a 4 fundamentos:
Minimizar el tiempo de inspección, cumplir las metas de atención diaria y los
lineamientos del Programa CREO.
Optimizar el uso de tecnologías móviles evitando el uso de papel para las fichas o
documento que se generan en una inspección vehicular y estar alineado a los
objetivos estratégicos de la empresa.
Obtener una evaluación y/o suscripción más especializada de seguros vehiculares
y obtener las características técnicas en menor tiempo.
Para que Pacifico tenga mayor prestigio en niveles de servicio al cliente y sienta
que recibe un servicio más personalizado.
16
CAPÍTULO 2: FUNDAMENTO TEORICO
2.1. ANTECEDENTES
2.1.1. NIVEL NACIONAL
Implementación de un aplicativo para teléfonos móviles que indique las rutas de
transporte público de la ciudad de Lima a partir de la ubicación del usuario [4]
La tesis consistió en la implementación de un aplicativo para teléfonos móviles que pueda
listar las rutas de transporte público urbano de la ciudad de Lima Metropolitana tomando
como datos de entrada la información de la ubicación del usuario. Se enfocó en el estudio
de las tecnologías relacionadas al desarrollo de las aplicaciones móviles en general,
asimismo se detalló las características de las herramientas disponibles para el desarrollo
del proyecto. Posteriormente se buscó presentar el análisis de la solución realizado a
partir de los conceptos y herramientas presentadas en la tesis, además de ello se explicó
las características de la propuesta de solución. Luego se describió el diseño de la
solución el cual incluye la información de la arquitectura del sistema, el flujo de datos, la
descripción de la base de datos a utilizar y finalmente las interfaces de la aplicación,
explicó la implementación realizada para ello se detalló tanto la estructura de la aplicación
como las configuraciones realizadas en el sistema. Se presentaron las conclusiones y
recomendaciones del trabajo, además se propuso algunos trabajos futuros que permitan
la integración de este sistema con nuevas herramientas de telecomunicaciones que
complementen el trabajo presentado y le añadan nuevas características de acuerdo a los
nuevos requerimientos de los usuarios.
17
Aportes de la propia empresa para optimizar las inspecciones vehiculares
Pacífico Seguros en el año 1990 empezó a realizar inspecciones vehiculares en
plataforma previa coordinación con el cliente, el proceso consistía en realizar la
inspección vehicular llenando un formato en papel y luego se transcribía al sistema web
de inspecciones (ver Figura 4), este sistema de inspección fue evolucionando en el
tiempo, en el año 2006 implementaron las inspecciones a domicilio, en donde mejoró la
satisfacción del cliente, sin embargo el tiempo de inspección siguió aumentando,
posteriormente se contrataron más inspectores debido a la demanda.
Figura 5 Sistema de Inspecciones
Fuente: Pacífico Seguros SA
En el 2010 la base de datos colapsó, por lo que desde entonces las fotos se guardan en
una carpeta compartida de inspectores que se almacena en un disco Duro.
En actualidad Pacífico Seguros, viene mejorando sus procesos de negocio a través del
proyecto Creo.
Creo, es un programa que integra las áreas de negocio, basado en Java, está dividido en
3 módulos: ClaimCenter, PolicyCenter y BillingCenter.
Estos módulos tienen parámetros para conectarse con los otros módulos, está a cargo de
Accenture OSB.
18
En la Figura 5 detalla los módulos funcionales de la solución Guidewire a los que el
programa Creo busca integrar.
Figura 6 Módulos Funcionales del Guidwide - Programa Creo Fuente: Pacífico Seguros SA
Este programa se está implementando en todas las áreas, ya está implementado con
productos de automóviles para el canal tele venta según se detalla en la Figura 6.
Figura 7 Cronograma e Release 0 Programa CREO
Fuente: Intranet de Pacífico Seguros SA
19
2.1.2. NIVEL INTERNACIONAL
Optimización del proceso de producción de una póliza de seguro para la rama a
vehículos livianos y particulares en Aseguradora del Sur [5]
En la tesis se analizó la principal línea de negocios de Aseguradora del Sur y se
identificó las áreas de mayor utilización del tiempo para el desarrollo de la misma. La
aplicación de una metodología científica permitió examinar el desenvolvimiento de la
compañía y desarrolló una propuesta de optimización para el proceso productivo. El
análisis se fundamentó en el uso de herramientas estadísticas orientadas a determinar
tiempos estándares para las actividades más relevantes del proceso y recomendaciones
adicionales en cuanto a su estructuración. Se buscó incrementar las unidades de pólizas
de seguro producidas; consumiendo en el menor tiempo posible sin que la calidad de las
mismas se vea afectada.
20
CASO DE ÉXITO EN ESPAÑA – MOVIL REPORT [6]
En España la empresa “avanTIC” diseñó e implementó un aplicativo móvil denominado
MovilReport.es.
MovilReport.es, es una aplicación móvil que recoge datos fidedignos de dónde y cuándo
se capturan los datos. Además se envían al instante un reporte en formato PDF.
Esta solución soportó la documentación de trabajos e inspecciones policiales, fotografías
y datos.
Características de Móvil Report
Aplicaciones en Androide, iPhone y PhoneGap (compatible con múltiples
plataformas).
Figura 8 Aplicativo móvil Fuente: movilrepot.es
21
2.2. MARCO TEÓRICO
MERCADO DE SEGUROS VEHICULARES PERUANO
El parque automotor en el Perú tiene 1 millón 800 mil vehículos no descontinuados, de
los cuales el 1 millón 500 mil (82%) corresponden a personas naturales. Y de este grupo,
alrededor de 91,000 personas naturales tienen asegurados sus vehículos con Pacífico
Seguros.
Actualmente, las primas vehiculares representan el 23% de las primas del mercado
asegurador según la SBS al cierre de Diciembre 2012. De este porcentaje 28%
corresponden a Pacífico Seguros. (Ver Figura 8)
Figura 9 Distribución de primas del mercado asegurador Ramos riesgos generales
Fuente: Elaboración propia sobre la base del avance del boletín SBS de diciembre de 2012.
22
PACÍFICO SEGUROS
Pacífico es una compañía sólida y de gran trayectoria en el mercado asegurador peruano
perteneciente a dos grandes socios: Credicorp, conglomerado financiero de reconocida
trayectoria en el Perú y contamos con un socio estratégico de gran prestigio en el ámbito
internacional, AMERICAN INTERNATIONAL GROUP, AIG, el más importante consorcio
asegurador norteamericano con presencia en más de 130 países.
Cuenta con la calificación de grado de inversión internacional de Moody's y Fitch Ratings,
dos de las clasificadoras de riesgo más importantes del mundo. Es reconocida como la
mejor compañía de seguros generales del Perú por el sector empresarial, los líderes de
opinión y la opinión pública, según estudios realizados por Ipsos-Apoyo y la Encuesta
Anual de Ejecutivos de la Cámara de Comercio de Lima.
DATOS DE LA EMPRESA
Misión
Ayudar a los clientes a proteger su estabilidad económica, ofreciéndoles soluciones que
protejan aquello que valoran y aseguren el cumplimiento de sus objetivos.
Visión
Ser una de las cinco mejores aseguradoras de Latinoamérica: simple, transparente,
accesible, rentable y con colaboradores altamente competentes y motivados.
Cantidad de trabajadores
Pacífico Seguros en la actualidad cuenta con 1148 Colaboradores distribuidos a nivel
nacional (ver Figura 9).
En el área de Pacífico Asiste cuenta con un total de 46 colaboradores.
23
26 colaboradores en la parte administrativa, planeamiento y Operaciones
20 Inspectores vehiculares.
Figura 10 Cantidad de trabajadores 2011 y 2012
Fuente: Área de Gestión y Desarrollo Humano (al 30 de noviembre 2012)
ESTRUCTURA ORGANIZACIONAL [7]
Pacífico seguros es una empresa que tiene una organización Funcional, está
encabezada por una composición accionaria (ver Figura 10 seguido de una Gerencia
General, Gerencia de líneas de Negocio, seguido por las divisiones (ver Figura 11)
Figura 11 Composición Accionara de Pacífico Seguros S.A
Fuente: www.equilibrium.com.pe/pps.pdf
2.2.1. SEGURO DE AUTOMÓVILES [8]
Es aquel seguro que tiene por objeto la prestación de indemnizaciones de accidentes
producidos a consecuencia de la circulación de vehículos.
Las coberturas que otorga este Seguro son: daños personales que comprenden una
indemnización por muerte, invalidez e incapacidad de las víctimas del accidente, así
24
como también el pago de los gastos de atención médica, hospitalaria, quirúrgica,
farmacéutica y gastos de recuperación o de rehabilitación del accidentado y los daños
materiales que comprenden la indemnización a terceros por los perjuicios ocasionados
por el asegurado, como consecuencia del accidente.
2.2.2. EMISIÓN DE UNA PÓLIZA VEHICULAR
En Pacífico Seguros las emisiones de pólizas vehiculares siguen el siguiente diagrama,
desde la cotización en el área de ventas hasta la facturación de la póliza en el área de
emisión. (Ver Figura 6)
VENTA SUSCRIPCIÓN EMISIÓN
Actividades
Proveedores
Sistemas
Cliente – Prospecto de Cliente
Brokers
Analizar las propuestas/ Cotizaciones que se
encuentren fuera de políticas, aprobando o
rechazándolas
Inspeccionar el vehículo del futuro cliente, para
validar que se encuentre dentro de las políticas
Prospecto de Clientes
Venta Nueva: incluye, la cotización y gestión
de los responsables para realizar Venta
Alianzas, Estandarizados, No estandarizados
y Concurso Público de los productos de Autos
Emitir en sistema la póliza nueva/renovada/
endoso
Compaginar las pólizas y carnet impresos
Entrega de pólizas al cliente
Lotus Notes
BPM
WEB Corredores
BPM
Lotus Notes
SIV
Axel/X
Lotus Notes
BPM
Solicitud de Cotización/ RenovaciónEntradas
Clientes
Cotización
Solicitud de Inspección Solicitud de Emisión
Cuenta Asignada a un Ejecutivo
Cotización aprobada
Salidas Solicitud de Emisión/ Cotización rechaz
Vehiculo aprobado
Póliza entregada al cliente
Proceso de Suscripción
Proceso de Emisión
Cliente
Proceso de Venta
Emisión
Ejecutivos
Proceso de Suscripción
Proceso de Venta
Cliente
Venta Nueva
Renovaciones
ProspectoInspección de
Vehículos
Suscripción de
Riesgos
Emisión de
Endosos/
Renovaciones
Compaginación
Emisión Cuenta
Nueva
Despacho
Estandarizados:
MLTA/ SVP
BCP (BANA-BANJ)
No Estandarizados:
JURI
Productos/Servicios
Figura 12 Diagrama de bloque de Emisión de automóviles
Fuente: Pacifico Seguros SA
2.2.3. INSPECCIÓN VEHICULAR[9]
Es una actividad que forma parte del proceso de la evaluación de riesgos de las pólizas
vehiculares y parte de las cargas y obligaciones del asegurado expresadas en el
Condicionado General Común, que consiste en el levantamiento de información in situ. El
inspector evalúa el estado y el riesgo del vehículo.
Debe analizar:
25
- Datos de la unidad. (marca, modelo, año de fabricación, número de motor, número
de serie, rodaje)
- Estado de conservación. (carrocería e interiores)
- Detalle de los accesorios musicales y de comunicación.
- Detalle del equipamiento de la unidad como aire acondicionado, spoiler, tipo de
lunas (nacionales o importadas, normales o anti-impacto), seguro de aros, vasos, faros y
máscaras, bastón de seguridad y alarma.
- Relación de daños con los que contaba la unidad en el momento de la inspección.
Las inspecciones vehiculares son realizadas por Pacífico Asiste en la actualidad, como
una de las labores que tienen a cargo. (Ver Figura 7)
Figura 13 Línea de Negocio de Pacífico Asiste
Fuente: Pacífico Seguros SA
Actualmente Pacifico seguro cuenta con un proceso de inspección vehicular que
involucra varias actividades manuales y que no agregan valor al proceso( ver figura 14),
se resalta en rojo las actividades que modificaremos con nuestro aplicativo móvil (AM).
26
Inicio
Solicita emisión de
póliza vehiculara
con inspección vía
e-mail al buzón
SSC
Recibe solicitud De
emisión a través
buzón de SSC Lima
Cliente/Corredor SSC Lima
Ejecutivo comercial
Coordinador de Inspección / Asistentes
Asigna y deriva
caso al
inspector
Consigue dato faltante y
envía mail al coordinador
de inspección solicitando
continuar con la
inspección.
Recibe el caso por un
aviso vía mail y a través
de su bandeja de
pendientes
Coordina inspección con
el cliente por teléfono
Devuelve caso al
ejecutivo
Comercial
Fin
¿Logró
coordinación?NO SI
Se traslada a
Realiza
inspección in Situ
SIV
SIV
SIV
SIV
Inspector
Crea slip y genera
inspección a traves
del Lottus Note y
Deriva al
Coordinador de
Inspecciones
Recibe slip con
solicitud de
inspección y valida
los datos
Work Flow
Chek list
Llena la ficha de
inspección y toma
fotografias
Se traslada a la
oficina para dejar
la ficha y
fotografias
Receociona las
fichas de
inspeccion
Escanea y Registra
los datos de la ficha
y descarga las fotos
A
A
Figura 14 Flujo de inspección vehicular Actual
Fuente: Elaboración propia en base a información de Pacífico Asiste
Con la implementación del Aplicativo Móvil (AM), se propone modificar el flujo de trabajo,
eliminado actividades que no agregan valor y optimizando el tiempo de la inspección
vehicular (ver figura 15). En verde se resalta las actividades que agregan valor al
proceso y que serán realizadas utilizando el Aplicativo móvil (AM).
27
Inicio
Solicita emisión de
póliza vehiculara con
inspección vía e-mail al
buzón SSC
Recibe solicitud De
emisión a través
buzón de SSC Lima
Cliente/Corredor SSC Lima
Ejecutivo comercial
Coordinador de Inspección / Asistentes
Asigna y deriva
caso al
inspector
Consigue dato faltante
y envía mail al
coordinador de
inspección solicitando
continuar con la
inspección.
Recibe el caso a través
de su bandeja de
pendientes
Coordina inspección con
el cliente por teléfono
Elige opción no
contactado
Fin
¿Logró
coordinación?NO SI
Se traslada a
Realiza
inspección in Situ
SIV
SIV
AM
AM
Inspector
Crea slip y genera
inspección a traves
del Lottus Note y
Deriva al
Coordinador de
Inspecciones
Recibe slip con
solicitud de
inspección y valida
los datos
Work
Flow
Chek list
A
A
Registra los datos en el
aplicativo movil, toma
fotos, lo registra en el
sistema y envia mail de
confirmación al cliente.
AM
Figura 15 Flujo de inspección vehicular Propuesto
Fuente: Elaboración propia en base a información de Pacífico Asiste
2.3. MARCO CONCEPTUAL
En el marco conceptual (ver Figura 16) se representa, contextualmente, el problema de
inspección vehicular, especificando las principales causas y sus efectos. Además, ofrece
una sinopsis de las alternativas a elegir y los resultados que generan cada una de ellas.
Alternativa 1: Seguir con los procesos y herramientas actuales.
Resultado: Mantener los problemas actuales.
Alternativa 2: Implementar el aplicativo móvil.
Resultado: Optimizar el tiempo de inspección vehicular, mejorar el servicio al cliente,
ahorro en materiales (formatos en papel para registrar la inspección) y en mano de
obra (digitadores que transcriben los datos al sistema).
28
Alternativa 3: Optimizar procesos (enviar la inspección por un correo a un buzón
genérico).
Resultado: Evitar traslados innecesarios de los inspectores (enviarían los datos por
correo).
El proyecto de implementar un aplicativo móvil es la alternativa que genera más
beneficios para la empresa y el cliente. Representa en forma gráfica como el proyecto es
relevante para solucionar el problema.
Figura 16 Marco conceptual – Tesis
Fuente: Elaboración propia
29
2.4. MARCO METODOLOGICO
El mercado tecnológico presenta, en la actualidad, diversas metodologías para el diseño
de software (RUP, SCRUM y XP).
A continuación, se describen las características, ventajas y desventajas de las principales
metodologías (ver Tabla 4).
Tabla 4 Metodologías de desarrollo de Software Fuente: Elaboración Propia
METODOLOGIA RATIONAL UNIFIED PROCESS (RUP)
METODOLOGIA EXTREME PROGRAMMING (XP)
De
fin
ició
n
Es una metodología de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Utilizada para el análisis, implementación y documentación de sistemas.
Es un enfoque de la ingeniería de software formulado por Kent Beck y De Jean. Es la más destacada de los procesos ágiles de desarrollo de software. Pone más énfasis en la adaptabilidad que en la previsibilidad.
Ca
rac
teri
sti
cas
Forma disciplinada de asignar tareas y responsabilidades.
Pretende implementar las mejores prácticas en Ingeniería de Software.
Desarrollo iterativo.
Administración de requisitos.
Uso de arquitectura basada en componentes
Control de cambios.
Modelado visual del software.
Desarrollo iterativo e incremental.
Pruebas unitarias continuas.
Integración del equipo de programación con el cliente.
Corrección de todos los errores antes de añadir nueva funcionalidad.
Propiedad del código compartida.
Ve
nta
jas
Promueve la reusabilidad.
Disminuye la brecha semántica entre la visión interna y la visión externa del sistema.
Facilita la construcción de prototipos.
Confiabilidad, Integridad y Estabilidad.
Mantenimiento más sencillo.
Modificaciones locales.
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
Solución de errores de programas.
Versiones nuevas.
Implementa una forma de trabajo adaptable.
De
sv
en
taja
s Abarca mucha documentación dentro
del desarrollo de una aplicación.
En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.
Es recomendable solo en proyectos a corto plazo.
Altas comisiones en caso de fallar
Imposible prever todo antes de programar.
Demasiado costoso e innecesario
30
Luego de describir las características principales, ventajas y desventajas de las
metodologías RUP y XP.
Para la selección de la metodología, se considera los siguientes criterios.
C1: Eficacia de la metodología.
C2: Curva de aprendizaje.
C3: Relación entre la envergadura del proyecto y la metodología
Se utiliza la siguiente escala de puntajes.
NIVEL PUNTOS
EXCELENTE 3
BUENO 2
REGULAR 1
Alternativas de metodologías.
A1: RUP
A2: XP
C1 C2 C3 TOTAL
A1 3 3 2 8
A2 3 2 1 6
TOTAL 6 5 3 14
La metodología de desarrollo seleccionada fue la alternativa A1: RUP.
Argumentos de Selección de la metodología RUP:
Se ha seleccionado la metodología debido a que el proyecto está alineado a los
estándares y políticas del área de Tecnologías de Información de Pacifico
Seguros.
Es adaptable al contexto y necesidades del proceso de la organización.
31
El mercado tecnológico presenta, en la actualidad, diversas metodologías para el diseño
del Aplicativo: StarUML, Rational Rose, Visual Paradim y Visio Microsoft.
A continuación, se describe las características, ventajas y desventajas de las principales
herramientas (ver Tabla 5).
Tabla 5 Herramientas para el diseño
Fuente: Elaboración Propia
RATIONAL ROSE VISIO MICROSOFT
De
fin
ició
n
Herramienta de modelado visual para el desarrollo de aplicaciones, el modelado de datos, el diseño de servicios web, el modelado empresarial, la ampliación de aplicaciones heredadas y el modelado basado en componentes.[10]
Es un software de dibujo vectorial que permite realizar diagramas de oficina, de base de datos, flujo de programas y UML.
Ca
rac
teri
sti
cas
Proporciona prestaciones de modelado visual para desarrollar muchos tipos de aplicaciones de software.
Contiene herramientas web y XML para el modelado de aplicaciones web.
Unifica el equipo del proyecto proporcionando una ejecución y una notación de modelos UML comunes.
Los estándares de creación de diagramas actualizados son compatibles, incluidos el Unified Modeling Language (UML) 2.4 y el Business Process Model and Notation (BPMN) 2.0.
Permite hacer diagramas dinámicos en tiempo real.
Permite trabajar en equipo al mismo tiempo sobre un mismo diagrama.
Ve
nta
jas Es una herramienta muy completa y
estable como muy pocas herramientas que se han creado.
Facilidad de uso para el modificado y creación de nuevos diagramas.
Facilita compartir los diagramas con un equipo de trabajo.
Funcionalidades de autoconexión en diagramas.
De
sv
en
taja
s Entorno grafico no muy amigable para el
usuario.
No es un software libre.
No se puede crear el entorno del Sistema para los diagramas de casos de uso.
Falta de compatibilidad con más lenguajes de programación.
No es un software libre.
Presenta muchas opciones en la barra de formas.
Para seleccionar la herramienta para el desarrollo de la metodología RUP se ha
considerado los siguientes criterios.
C1: Funcionalidad del producto.
C2: Rendimiento del producto.
32
C3: Mantenimiento del producto
C4: Garantía del producto.
C5: Curva de aprendizaje
C6: Costo de licenciamiento
Se utiliza la siguiente escala de puntajes.
NIVEL PUNTOS
EXCELENTE 3
BUENO 2
REGULAR 1
Alternativas de herramientas de diseño.
A1: IBM Rational Rose
A2: Microsoft Visio
C1 C2 C3 C4 C5 C6 TOTAL
A1 3 3 1 3 3 2 15
A2 3 3 2 3 1 2 14
TOTAL 6 6 3 6 4 4 29
La herramienta de diseño seleccionada fue la alternativa A1: Rational Rose.
Argumentos de selección de la herramienta de IBM Rational Rose:
Se ha seleccionado la herramienta debido a que el proyecto está alineado a los
estándares y políticas del área de Tecnologías de Información de Pacifico
Seguros.
Facilita la creación y modificado de diagramas.
Es compatible con varios lenguajes de programación.
33
2.5. MARCO LEGAL
Pacifico Seguros se rige en base a la Ley de contratación de Seguros N° 29946, la cual
considera las características del seguro, en el articulo N°27, faculta a Pacifico Seguros a
incorporar condiciones y/o clausulas previamente aprobadas por la Superintendencia de
Banca y Seguros donde señala la inspección de los vehículos, así mismo en el Articulo
34 hace referencia que debe de brindar una copia del informe de inspección de riesgo
(ver figura 17).
Figura 17 Artículos de la ley N° 29946
Fuente: Diario oficial El Peruano
34
CAPÍTULO 3: DESARROLLO DE LA APLICACIÓN
3.1. MODELAMIENTO
3.1.1. Especificación de requerimientos
Se identificará lo que el Aplicativo móvil debe hacer (Especificar Requisitos).
3.1.1.1. Requisitos generales
a) Trabajar con fechas que codifiquen el año con cuatro cifras.
b) Las solicitudes de inspección son creadas desde el sistema de gestión de pólizas
(Policy Center).
c) Solo tiene un perfil de usuario, el cual puede ingresar al sistema, consultar y
realizar inspección.
3.1.1.2. Ingreso del inspector al sistema
El modulo permite el ingreso al aplicativo móvil, debe de cumplir los dos siguientes
requisitos:
a) Para el proceso de autentificación el aplicativo debe de utilizar el Sistema de
Seguridad de Aplicaciones, Modulo centralizado de administración (SSA). Es un
sistema que permite que el usuario pueda ingresar al sistema utilizando las
mismas credenciales de inicio de sesión de la maquita y el resto de aplicativos.
b) En caso las credenciales no coincidan debe de mostrar mensaje indicando el
error. Luego de tres intentos se cierra el aplicativo.
3.1.1.3. Consulta de inspecciones
Se encarga de consultar las inspecciones vehiculares relacionadas a los parámetros de
búsqueda.
a) Debe de permitir consultar por documento de identidad del cliente (DNI).
b) Debe de permitir consultar por placa del vehículo.
35
c) Mostrar inspecciones asociadas a los datos de búsqueda ingresados (DNI o
Placa).
d) Mostrar mensajes en caso de encontrar inspecciones relacionadas a los datos
ingresados.
3.1.1.4. Realizar inspección
Se encarga del registro de la información recolectada durante la inspección.
a) Debe de mostrar los datos básicos de la inspección, código de inspección,
descripción del canal, agente de venta y ciudad.
b) Se visualiza los datos del cliente: Nombres y apellidos, documento de identidad,
teléfono, email y dirección, los cuales deben de ser no editables.
c) Se muestra los datos básicos del vehículo: Placa, año, chasis, marca, modelo y
motor. Los datos son editables.
d) Permitir ingresar observaciones sobre el estado de inspección.
e) Permitir registrar accesorios del vehículo, permite editar.
f) Permite capturar fotografías, utilizando la cámara de la tablet o de la galería. No
permite eliminar las fotografías.
g) Actualizar el estado de inspección( Aprobado, observado o rechazado)
h) Enviar constancia de la inspección al email registrado del cliente. En el reporte no
debe de figurar el estado ingresado por el inspector.
3.1.2. Análisis y diseño
3.1.2.1. Diagrama de Contexto: Nivel 0
En el diagrama de contexto (ver Figura 18) se muestran las interacciones que realiza el
aplicativo móvil con el entorno (agentes externos), estas son: Emisor, Inspector y
Clientes.
36
Actualmente las tareas de inspecciones llegan a la bandeja de actividades del inspector
luego de ser generadas por el área de emisión, el inspector se comunica con el cliente y
pacta la fecha y hora para la inspección. El inspector realiza la inspección con un
formulario físico y tomas las fotografías con una cámara digital. Luego de esto un
digitador traslada la información al sistema y digitaliza el formulario.
Con este proyecto el inspector podrá realizar la inspección utilizando un aplicativo móvil
instalado en una tablet, el cual va permitir registrar en línea las inspecciones y capturar
fotografías, Ya no deberá digitar y escanear el formulario, dado que su envió al sistema
será automático.
Gestionar
Inspecciones
Cliente
Inspector
Emisor
Constancia_Inspección
Solicita_inpección
Consultar_Actualizar_Inspección
Figura 18 Diagrama de Contexto Gestionar inspecciones Fuente: Elaboración Propia
3.1.2.2. Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso
principal de gestionar inspecciones. En este nivel los procesos no suelen
interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o
entidad que los una.
Los principales procesos de la gestión de inspección son: Consultar inspecciones y
registrar inspección. Los datos de entrada para el proceso de Consultar inspecciones
37
son: vehículo por la placa de rodaje o documento de identidad del cliente. Nos va
mostrará si existe una inspección relacionada a la búsqueda y se podrá realizar el
siguiente proceso de registrar inspección el cual tiene como salida una constancia de
inspección (ver Figura 19).
Consultar
Inspecciones
Registra
Inspección
Inspecciones
Constancia
Consulta_vehículo_cliente
Figura 19 Diagrama de nivel superior
Fuente: Elaboración Propia
3.1.2.3. Diagrama de Detalle o Expansión: Nivel 2
En un diagrama de nivel 2 o mayor, comienzan a explotarse progresivamente el nivel de
detalle.
Se describe los procesos principales (consultar inspección y realizar inspección). El
proceso de Consultar inspección y la interrelación con el proceso realizar inspección, nos
muestra que luego de ingresar los datos de consulta (placa o documento de identidad) el
sistema realiza la validación para comprobar la existencia de inspecciones vehiculares
asociadas a los parámetros de búsqueda (ver figura 20).
Consultar
inspección
Realizar
Inspección
Inspecciones
Consulta_validada
Consulta inspección
Figura 20 Diagrama de detalle – Consultar inspección Fuente: Elaboración Propia
38
El proceso de Realizar inspección es el proceso principal donde se va registrar las
características del vehículo, accesorios adicionales y las fotografías que dejan constancia
del estado del vehículo. El proceso tiene como entrada el número de inspección y salidas
la inspección actualizada y una constancia que se enviara al cliente vía email (ver Figura
21).
Realizar
InspecciónNro_inspección Inspección
Enviar_constancia
Constancia
Figura 21 Diagrama de detalle - Realizar inspección
Fuente: Elaboración Propia
3.1.2.4. Diagrama de Clases
Para el diseño de nuestro aplicativo móvil para el registro de las inspecciones vehiculares
elaboramos un diagrama de clases que resume el contenido (ver Figura 22).
El diagrama de clases muestra las clases que intervienen en el diseño de nuestra
aplicación móvil para el registro de las inspecciones vehiculares.
Las clases que intervienen son Cliente, Inspector, Vehículo, Foto, Accesorio e Inspección.
Nos muestra la información respecto a los atributos y operaciones que se efectúan en el
aplicativo.
39
Figura 22 Diagrama de clases
Fuente: Elaboración Propia
3.1.2.5. Actores
En el diseño de nuestro aplicativo móvil para el registro de las inspecciones vehiculares
solo participa un actor.
Nombre de actor: Inspector
Definición: Es el encargado del registro de la inspección vehicular, llenar el formulario,
así como la carga de las imágenes del vehículo que se ha inspeccionado. Tendrá todos
los permisos y libertad de movimientos por el aplicativo.
Figura 23 Actores del Sistema: Inspector
Fuente: Elaboración Propia
Inspector
40
3.1.2.6. Diagramas de Casos de Uso
Caso de uso Ingreso del inspector al sistema
En este caso de uso se definen todos los actores y relaciones necesarias para que el
inspector pueda ingresar al aplicativo móvil para el registro de inspecciones.
Figura 24 Diagrama de casos de uso: Ingreso del inspector al sistema
Fuente: Elaboración Propia
En la Tabla 6 se especifican los actores, descripción del caso de uso, condiciones, flujo
básico y flujo alterno del caso de uso de ingreso del inspector al sistema.
Tabla 6 Especificación de caso de uso: Ingreso del inspector al sistema Fuente: Elaboración Propia
Ingreso del inspector al sistema
Actores Inspector.
Descripción Se encarga de la validación de información del inspector para
permitirle el ingreso al sistema.
Precondición Que el inspector se encuentre registrado en el sistema.
Flujo Básico 1. El inspector solicita ingreso al sistema.
2. El sistema solicitado datos de autenticación.
3. El inspector ingresa datos. Usuario, contraseña.
4. El sistema verifica la información, de ser conforme permite
acceso al sistema al inspector.
Flujo Alterno En caso la información sea incorrecta en 3 intentos el sistema se
cerrará automáticamente.
Inspector Solicitar ingreso al sistema
Verificar información del inspector
<<include>>
41
Caso de uso Consulta información cliente/vehículo
En este caso de uso se definen los actores y relaciones necesarias para que el inspector
pueda consultar la información de cliente y vehículo al que va a realizar la inspección.
Figura 25 Diagrama de casos de uso: Consulta de información del Cliente/Vehículo
Fuente: Elaboración Propia
En la Tabla 7 se especifican los actores, descripción del caso de uso, condiciones, flujo
básico y flujo alterno del caso de uso consulta de información del cliente/ vehículo.
Tabla 7 Especificación de caso de uso: Consulta de información del cliente/vehículo
Fuente: Elaboración Propia
Consulta de información del cliente/vehículo
Actores Inspector
Descripción Se encarga de consultar por placa o documento de identidad del
cliente, el sistema mostrará la inspección o las inspecciones
relacionadas.
Precondición Que la unidad sea asegurable para la compañía de seguros. Que
exista una solicitud inspección presencial con todos los datos del
cliente y vehículo.
Flujo Básico 1. El inspector encargado realiza la consulta sobre la información
del cliente y la unidad que va a inspeccionar. La consulta la
realiza por placa o documento de identidad del cliente.
2. El sistema devuelve la información de una o varias solicitudes
de inspección conforme sea la consulta.
Flujo Alterno Si la información solicitada no existe, el sistema mostrará el
siguiente mensaje: “No existe inspecciones relacionadas al cliente o
placa que ingreso”.
Verificar información del cliente o
vehiculo
InspectorConsulta información del cliente o
vehiculo
<<include>>
42
Caso de uso Registra inspección
Este caso de uso contiene los actores y relaciones necesarias para el registro de la
información sobre características, daños e imágenes de la unidad inspeccionada.
Figura 26 Diagrama de casos de uso: Registra inspección
Fuente: Elaboración Propia
En la Tabla 8 se especifican los actores, descripción del caso de uso, condiciones, flujo
básico y flujo alterno del caso de uso de Registra inspección.
Tabla 8 Especificación de caso de uso: Registra inspección Fuente: Elaboración Propia
Registra inspección
Actores Inspector
Descripción Se encarga del registro de la información recolectada durante la
inspección, tales como: Características, accesorios, daños,
observaciones, imágenes (del vehículo a asegurar) y actualiza el
estado de la inspección.
Precondición Que la solicitud se encuentre registrada en el sistema.
Flujo Básico 1. El inspector consulta la información del cliente y el vehículo a
inspeccionar y descarga el formulario al dispositivo móvil.
2. Registra la información básica de la unidad, características
como placa, marca, modelo, color, motor, chasis, etc.
3. Registras los accesorios de la unidad como Radio, aire
Consultar infromación del clienteDescargar información del cliente/
vehículo
<<include>>
Registrar caracteristicas del
vehículo
Registrar accesorios del vehículo
Registrar daños/ observaciones del
vehículo
Cargar fotos del vehículo
Inspector
Actualizar estado de la inspección
43
acondicionado, etc.
3. Registra los daños u observaciones que encuentre en el
vehículo inspeccionado.
4. Carga por medio del aplicativo móvil, fotos del vehículo
inspeccionad0 directamente a la base de datos del sistema.
5. Actualiza el estado de inspección (Aprobado, observado o
rechazado.
3.1.2.7. Diagrama de Secuencia
En este diagrama podemos visualizar, la secuencia de procesos que se realizan en el
aplicativo móvil para poder registrar la información de una inspección.
El primer paso para poder ingresar al sistema consiste en la autentificación del inspector
vehicular. En la figura 27 se puede visualizar el diagrama de secuencia del caso de uso
Ingreso del inspector al sistema.
Figura 27 Diagrama de secuencia: Ingreso del inspector al sistema
Fuente: Elaboración Propia
Base de DatosBase de Datos
: Inspector : Inspector
Aplicativo MovilAplicativo Movil
1: Ingresa al aplicativo()
2: Solicita usuario y clave()
3: Ingresa Usuario y clave()
4: Valida usuario y clave()
5: Verifica usuario y clave()
6: Información erronea, sale del aplicativo()
7: Información correcta: Ingresa al aplicativo()
44
Para continuar con el siguiente paso, se debe de estar autentificado, es decir haber
pasado el diagrama de secuencia Ingreso del inspector (ver Figura 27). Luego el
inspector puede realizar el proceso de consultar información del cliente/ vehículo, se
puede consultar por placa del vehículo o documento de identidad del cliente, el sistema
muestra las inspección o inspecciones asociadas, caso contrario mostrara un mensaje
indicando que no existen inspecciones relacionadas al cliente o placa que ingreso (ver
Figura 28).
Figura 28 Diagrama de secuencia: Consulta información del cliente/ vehículo
Fuente: Elaboración Propia
Para la realización del tercer paso, se tiene como pre-requisito estar autentificado, es
decir haber pasado por el diagrama de secuencia: Ingreso del inspector al sistema. Luego
de la autentificación el inspector puede realizar la inspección del vehículo, registrar
información básica del vehículo, accesorios como radio, aire acondicionado, fotografías
que dejan constancia del estado en que se encuentra el vehículo y enviar una constancia
de inspección al cliente vía email (ver Figura 29).
: Inspector : Inspector
Aplicativo MovilAplicativo Movil Base de DatosBase de Datos
1: Digita Documento del cliente o Placa()
2: Consulta el dato ingresado()
3: Verifica la consulta()
4: Devuelve la consulta()
5: No encuentra consulta, muestra mensaje ()
6: Muestra la datos de la inspección( Datos del cliente y estado)()
45
Figura 29 Diagrama de secuencia: Registra inspección
Fuente: Elaboración Propia
: Inspector : Inspector
Aplicativo MovilAplicativo Movil Base de DatosBase de Datos
1: Selecciona inspección()
2: Busca información solicitada()
3: Envia información solicitada()
4: Muestra información ()
5: Actualiza estado de inspección()
6: Muestra las opciones (No contactado, en proceso)()
8: Estado En proceso, Muestra formulario()
7: Estado No contactado, guarda la información
9: Registra datos del vehículo(Caracteristicas,fotos, daños)()
10: Envia información registrada()
11: Graba información
12: Envia conformidad de registrada()
13: Muestra conformidad de grabado()
14: Actualiza estado de inspección()
15: Verifica estado de inspección()
16: Muestra estados de inspección( Aprobado, observado o rechazado)()
17: Selecciona estado de inspección()
18: Envia información estado()
19: Graba información()
20: Indica conformidad en el registro()
21: Muestra conformidad, envia email()
22: Finaliza inspección, sale del sistema()
46
3.1.2.8. Diagrama de colaboración
Este diagrama muestra el comportamiento de la clase de entrada al sistema, se indica las posibles razones del cambio de su estado.
Figura 30 Diagrama de colaboración
Fuente: Elaboración Propia
Base de
Datos
: Inspector
Aplicación
1: Autenticación en el sistema
2: Valida información
3: Verifica información
4: No permite ingreso al sistema
5: Permite ingreso al sistema
6: Muestra opciones del sistema
7: Solicita información del cliente y vehículo8: Busca información en la base de datos
9: Muestra información solicitada
10: Carga información al sistema
11: Envía información cargada
12: Graba información
13: Envía conformidad de grabación14: Muestra conformidad
3.1.2.9. Modelamiento de la Base de Datos
El mercado tecnológico nos proporciona diversas herramientas para el modelado de
datos, que permiten describir los datos de la base de datos (Erwin 7.3, StartUML 5.0, IBM
Rational DATA ARCHITECT versión 7.5.1, Toad Data Modeler Versión 4.0 y
SybasePowerDesigner 12.0).
A continuación se describe las características, ventajas y desventajas de las principales
herramientas (ver Tabla 9).
Tabla 9 Herramientas para el modelado de datos Fuente: Elaboración Propia
Erwin Toad Data Modeler
De
fin
ició
n
Herramienta de modelado ofrece un entorno de modelado de datos de colaboración para administrar datos empresariales con una interfaz intuitiva y gráfica.
Herramienta de modelado de datos y diseño de base de datos, potente y económica.
Ca
rac
teri
sti
cas Visualización de estructuras de datos
complejas.
Herramientas de comparación de modelos y Bases de datos.
Informes y publicación para compartir información entre los diversos roles de la organización.
Crear modelos de datos lógicos y físicos de alta calidad.
Comparar y sincronizar modelos
Generar SQL/DDL complejos
Crear y modificar scripts.
Aplicar ingeniería inversa y directa a bases de datos y sistemas de almacenamiento de datos.
Ve
nta
jas
Permite aprender y practicar las habilidades de modelado de datos.
Contribuye a incrementar la calidad y a reducir los costos de mantenimiento y desarrollo.
Aumento de la productividad en la construcción.
Documentación. No es necesario utilizar otros modeladores para representar la entidad-relación, la propia definición ya forma parte de la documentación técnica.
Generación automática de scripts de cambio.
De
sv
en
taja
s Falta de niveles standard.
Conflicto en la integración con otras herramientas.
Función limitada.
Entorno poco amigable.
Luego de analizar las ventajas y desventajas de las principales herramienta.
48
Para el modelamiento seleccionamos la herramienta Erwin Data Modeler.
Argumento de selección:
Herramienta muy intuitiva y fácil de usar.
Existe bastante información en las redes, manuales, que facilitan su uso y contribuyen
al mejor desempeño.
El proyecto está alineado a los estándares del área de tecnología de información de
Pacifico Seguros.
El diseño de la base de datos nos muestra las tablas necesarias para el funcionamiento
del aplicativo móvil para las inspecciones vehiculares.
Las tablas que intervienen son:
Cliente, contiene la información de los clientes como Código, Nombre, Apellidos,
Documento, Dirección, Email y Teléfono.
Inspector, contiene la información del inspector encargado como Código, Nombre,
Apellidos, Documento y Zona.
Vehículo, contiene la información de la unidad como Placa, Marca, Modelo, Año, Color y
observación.
Accesorio, contiene la información de la unidad como Placa, código del accesorio y
descripción del accesorio.
Foto, contiene la información de la unidad como placa del vehículo, código de la
fotografía y ruta de la fotografía.
La tabla más importante para nuestro aplicativo móvil es Inspección que relaciona las
tablas anteriormente mencionadas y genera la integridad de la información. Contiene los
campos siguientes, Código del inspector, Código del cliente, Placa del vehículo, Código
de la inspección, Descripción, Estado, Fecha de solicitud y Fecha fin.
49
Figura 31 Modelamiento de la base de datos
Fuente: Elaboración Propia
3.1.2.10. Base de datos
Para poder seleccionar la base de datos el mercado tecnológico nos proporciona
diversidad de herramientas (SQL Server 2008R2, MySql, Oracle, My SQL, Informix,
InterBase, Microsoft Access y Paradox).
Cliente
CodCli
direc
docid
nombre
telef
Inspección
CodCli (FK)
codinr (FK)
placaveh (FK)
codins
codir
dscins
estado
fecfin
fecsol
Inspector
codinr
codir
contrasena
docidinr
nominr
usuario
Foto
codfoto
placaveh (FK)
dscacc
ruta
Accesorio
codacc
placaveh (FK)
dsacc
placavehic
Vehículo
placaveh
ano
chasis
marca
modelo
motor
obser
50
A continuación se describe las características, ventajas y desventajas de las principales
herramientas (ver Tabla 10).
Tabla 10 Herramientas para la base de datos Fuente: Elaboración Propia
Oracle 11g SQL Server
De
fin
ició
n Es un sistema de gestión de base de
datos objeto-relacional, desarrollado por Oracle Corporation.
Es un sistema para la gestión de bases de datos de Microsoft.
Ca
rac
teri
sti
cas Soporte de transacciones.
Estabilidad.
Escalabilidad. Soporte multiplataforma.
Soporte de transacciones.
Entorno gráfico de administración.
Permite trabajar en modo cliente-servidor.
Administrar información de otros servidores de datos.
Ve
nta
jas Automatiza las tareas de
administración y ofrece las mejores funciones de seguridad y de cumplimiento de las normativas.
Mayores niveles de disponibilidad
Ofrece un rendimiento fiable gracias a la integración de tecnologías en memoria.
De
sv
en
taja
s Precios altos en licencias.
Consume muchos recursos.
Esta limitación es exclusiva de sistemas operativos 32 bits
Requiere de un sistema operativo Microsoft Windows.
Para seleccionar la herramienta de base de datos se ha considerado los siguientes
criterios.
C1: Funcionalidad del producto.
C2: Rendimiento del producto.
C3: Mantenimiento del producto
C4: Garantía del producto.
C5: Curva de aprendizaje
C6: Costo de licenciamiento
51
Proveedores de Software de Base de Datos.
A1: Oracle 11g
A2: Microsft SQL Server 2008R2
Se utiliza la siguiente escala de puntajes.
NIVEL PUNTOS
EXCELENTE 3
BUENO 2
REGULAR 1
C1 C2 C3 C4 C5 C6 TOTAL
A1 2 3 3 3 3 3 17
A2 3 3 1 3 2 2 14
TOTAL 5 6 4 6 5 5 31
El proveedor de Base de Datos seleccionado fue la alternativa A1: Oracle 11g.
Argumentos de selección Oracle 11g
Se ha seleccionado la herramienta debido a que el proyecto está alineado a los
estándares y políticas del área de Tecnologías de Información de Pacifico Seguros.
Bondades que ofrece su arquitectura.
Nivel de garantía que ofrece Oracle a todos sus productos.
Existe personal calificado y con certificaciones en el manejo de la herramienta.
El costo de mantenimiento es menor comparado con los otros motores de base de
datos.
52
3.2. DESARROLLO
3.2.1. PROTOTIPO
3.2.1.1. Ingreso del inspector al sistema
Pantalla de acceso al sistema
En la Figura 32 se muestra la pantalla de acceso al sistema, la cual requiere de un ID de
usuario y su contraseña.
El Id de usuario es un área de texto alfanumérico, es decir acepta números o letras y es
el mismo que se usa para conectarse a los diferentes aplicativos de Pacifico Seguros.
La contraseña es de tipo password no es vista al momento de ingresar.
El botón de ingresar es el que ejecuta el evento de validación para el ingreso al sistema.
Figura 32 Pantalla de acceso al aplicativo móvil
Fuente: Elaboración Propia
Pantalla de validación de campos
En la Figura 33 se muestra la pantalla de validación de datos de ingreso, el inspector
debe de ingresar su código de usuario asignado y la contraseña y presionar el botón
ingresar.
53
Si el nombre o contraseña ingresada es incorrecta, el sistema muestra un mensaje que
los datos que han sido ingresados de manera errónea, tanto para el id de usuario como
para la contraseña ingresada. Permite ingresar hasta tres oportunidades luego se cierra
el aplicativo.
Figura 33 Validación de datos ingresados
Fuente: Elaboración Propia
3.2.1.2. Consultar Inspecciones
.Pantalla de Bandeja de Actividades
a) Consulta de información del cliente/ vehículo.
En la figura 34 muestra los campos para poder hacer consultas por placa o documento
de identidad del cliente.
En caso encuentre inspección o inspecciones asociadas a la placa o documento
ingresado, muestra el detalle de la inspección o inspecciones con el respectivo estado de
la inspección o inspecciones, el usuario podrá consultar los datos de la inspección o
ingresar a realizar la inspección en caso se encuentre pendiente (ver Figura 35).
54
Figura 34 Consultar inspecciones
Fuente: Elaboración Propia
Figura 35 Resultados de búsqueda de inspección
Fuente: Elaboración Propia
Si no existe inspección o inspecciones asociadas, el sistema mostrará el siguiente
mensaje: “No existen inspecciones relacionadas a los datos ingresados” (ver Figura 36).
55
Figura 36 Mensaje de consulta de inspecciones
Fuente: Elaboración Propia
a) Bandeja de actividades
En la Figura 37 se muestra las inspecciones que el inspector tiene asignado, figuran los
estados en que se clasifican las inspecciones (Pendientes, no contactados, aprobados,
observados y rechazados).
Figura 37 Bandeja de actividades
Fuente: Elaboración Propia
56
En la opción inspecciones Pendientes, se muestra todas las inspecciones que el
inspector no ha realizado ninguna acción.
En la opción inspecciones No contactados, muestra todas las inspecciones que el
inspector luego de intentar comunicarse con el cliente para realizar la inspección no logra
contactarlo.
En la opción Aprobados, muestra todas las inspecciones que el inspector luego de
realizar la inspección presencial al vehículo encuentra que el vehículo se encuentra en
perfectas condiciones y cumple con todo lo especificado en la cotización del seguro.
En la opción Observados, figuran todas las inspecciones que el inspector observo por
algunos daños que pueda presentar la inspección al momento de la inspección o en caso
alguno de los datos difiera de los datos consignados al momento de cotizar el seguro.
Ejemplo: Cotizaron al vehículo con año de fabricación 2013, pero en la inspección resulta
ser un vehículo de año de fabricación 2012.
En la opción Rechazados, figuran todas las inspecciones que el inspector rechazo por
algunos tener daños al momento de la inspección o en caso alguno de los datos difiera
de los datos consignados al momento de cotizar el seguro. Ejemplo: Cotizaron al vehículo
como timón original, pero en la inspección resulta ser un vehículo timón cambiado y no
asegurable.
En la opción Todos, muestra todas las inspecciones, incluye todos los estados
(Pendientes, no contactado, aprobado, observado y rechazado)
3.2.1.3. REGISTRAR INSPECCIÓN
Pantalla detalles de la inspección
Luego de seleccionar una inspección pendiente, el sistema muestra los detalles básicos
de la inspección como el código de la inspección, descripción (muestra detalles básicos
de la cotización, canal por el cual se está adquiriendo el seguro).
57
a) Datos del cliente
Muestra los datos básicos indispensables para poder contactarse con el cliente y realizar
la inspección presencial (ver Figura 38).
Nombres del cliente, documento de identidad, teléfonos, email y dirección.
Con esta información el inspector intenta comunicarse con el cliente y pacta la hora y
lugar para poder realizar la inspección.
Figura 38 Datos de la inspección
Fuente: Elaboración Propia
b) Estado de la inspección
Si el inspector no logra comunicarse con el cliente luego de 3 intentos el inspector puede
cambiar el estado de la inspección de pendiente a No contactado (ver Figura 39).
En caso logre comunicarse con el cliente y pacten una hora y lugar de inspección, el
inspector puede cambiar el estado de la inspección a en proceso y el sistema va permitir
editar el formulario de los datos del vehículo.
58
Figura 39 Editar estado de la inspección
Fuente: Elaboración Propia
Pantalla datos del vehículo
a) Características del vehículo
En la Figura 40 se observa los principales características que el cliente consigno al
momento de cotizar su póliza, muestra la placa, el número de motor, chasis, marca,
modelo y año de fabricación del vehículo. El inspector verifica la información consignada
y puede editarlo luego de la verificación presencial.
Figura 40 Características del vehículo
Fuente: Elaboración Propia
59
b) Observaciones/ Daños
En esta sección el inspector coloca información adicional sobre la inspección, pueden
colocar los daños que el vehículo pueda tener (ver Figura 41).
Figura 41 Observaciones de la inspección
Fuente: Elaboración Propia
c) Accesorios del vehículo
En esta sección el aplicativo muestra una lista donde el inspector puede incluir accesorios
que el cliente adquiere por separado al momento de adquirir el vehículo por ejemplo: aire
acondicionado, radio full equipo, etc. Permite ingresar la descripción del accesorio,
marca, modelo, valor y observaciones adicionales sobre el accesorio.
Estos datos deben de ser corroborados y/o editados por el inspector luego de revisar los
datos del vehículo (ver Figura 42).
60
Figura 42 Accesorios del vehículo
Fuente: Elaboración Propia
d) Fotos
Para dejar constancia sobre el estado del vehículo al momento de la inspección, el
inspector captura fotografías al vehículo por los cuatro lados, la placa, el motor, los
accesorios especiales y en algunos casos los daños que presente el vehículo (ver
Figura 43).
Figura 43 Capturar u Obtener fotografías
Fuente: Elaboración Propia
61
Luego de obtener la fotografía muestra las imágenes capturadas en la pantalla (ver
Figura 44).
Figura 44 Capturar fotografías del vehículo
Fuente: Elaboración Propia
e) Grabar estado de la inspección
Para finalizar la inspección el inspector selecciona el estado (Aprobado, observado y
rechazado) con este grabado la inspección desaparece de la bandeja de pendientes y se
traslada a la opción elegida (ver Figura 45).
Figura 45 Grabar estado de inspección
62
Fuente: Elaboración Propia A su vez el sistema envía un formulario como constancia de la inspección al email
proporcionado por el cliente (ver Figura 46).
Figura 46 Envío de constancia de la inspección
Fuente: Elaboración Propia
3.2.2. IMPLEMENTACIÓN
Para la implementación de nuestra solución, se usará el tipo de programación móvil,
porque permite realizar la inspección en cualquier lugar, se toma en cuenta que los
inspectores cuentan con internet móvil.
Sistema Operativo móvil
Para poder seleccionar el sistema el mercado tecnológico nos proporciona diversidad de
herramientas. Entre los principales sistema operativos los siguientes:
Android, iOS, Windows Phone, BlackBerry OS, Firefox OS, Ubuntu Touch y otros.
De acuerdo al sistema operativo que se elija, también se va elegir el lenguaje de
programación.
63
A continuación se describe las características, ventajas y desventajas de los principales
sistemas operativos móviles (ver Tabla 11).
Tabla 11 Sistemas operativos móviles Fuente: Elaboración Propia
Android iOS
De
fin
ició
n
Sistema operativo móvil más popular del mundo. Está basado en Linux, diseñado originalmente para cámaras fotográficas profesionales, luego fue vendido a Google y modificado para ser utilizado en dispositivos móviles como los teléfonos inteligentes, luego en tablets y otros dispositivos inteligentes.
El sistema operativo móvil más avanzado del mundo. Es el cerebro del iPhone, el iPad y el iPod touch. Está diseñado para aprovechar al máximo la avanzada tecnología del hardware de Apple.
Ca
rac
teri
sti
cas Sistema multitarea.
Sistema abierto.
Panel de ajustes rápidos.
Muy personalizable.
Sistema multitarea.
Sistema cerrado.
Panel de ajustes rápidos.
Poco personalizable.
Ve
nta
jas Control sobre la instalación y
desinstalación de aplicaciones y sus datos.
Ofrece libertad a los usuarios.
Teclados alternativos.
Ofrece control sobre las aplicaciones.
De
sv
en
taja
s Presenta problemas de
compatibilidad con versiones más recientes.
No permite la instalación de iOS en hardware de terceros.
No permite compartir archivos con otros dispositivos que no sean Ios.
Para seleccionar el sistema operativo se ha considerado los siguientes criterios.
C1: Funcionalidad.
C2: Rendimiento.
C3: Mantenimiento
C4: Garantía del producto.
C5: Curva de aprendizaje
C6: Costo de licenciamiento
64
Alternativas de sistema operativo.
A1: Android
A2: iOS
Se utiliza la siguiente escala de puntajes.
NIVEL PUNTOS
EXCELENTE 3
BUENO 2
REGULAR 1
C1 C2 C3 C4 C5 C6 TOTAL
A1 3 3 2 3 3 3 17
A2 3 3 3 2 3 1 15
TOTAL 6 6 5 5 6 4 32
El sistema operativo seleccionado fue la alternativa A1: Android.
Argumentos de selección
Nos permite tener control sobre la instalación y desinstalación de aplicaciones y sus
datos.
Ofrece libertad a los usuarios.
Tiene la cuota más alta del mercado, sobrepasa el 80%.
Al seleccionar el sistema operativo Android, el lenguaje de programación a utilizar es
Java, utilizando el propio Kit de desarrollo de software libre (SDK) que nos proporciona
Android.
La ventaja de Android desde el punto de vista del desarrollo es que se puede reutilizar el
código existente para crear aplicaciones funcionales rápidamente. Por ejemplo nuestra
aplicación necesita el uso de la cámara, no es necesario escribir el código para la
aplicación de cámara. Sólo hay que llamar al marco Cámara existente inherente a
Android para su uso en la aplicación. Incluso los desarrolladores sin mucha experiencia
65
pueden comenzar a crear aplicaciones útiles sin una amplia formación o experiencia.
Debido a que existen varios portales web y tutoriales que facilitan el aprendizaje.
El mercado de tablets está ofreciendo cada vez más alternativas. Todas las marcas
están haciendo apuestas interesantes lanzando dispositivos mejores y a un mejor precio.
En este sentido debemos de evaluar las principales para que nuestro aplicativo pueda
ejecutarse, tomando en cuenta que la tablet es para trabajar, se necesita editar textos,
fotos, compartir archivos y navegar por internet largo y tendido.
A continuación se describe las características técnicas de las principales Tablets (ver
Tabla 12).
Tabla 12 Cuadro comparativo de características técnicas de tablets Fuente: Elaboración Propia en base a información www.falabella.com.pe
Atributos Galaxy Tab3
Lite Samsung Tablet Quad Core Lenovo
Tablet Slave HP
Tamaño pantalla 7" 8" 7"
Duración batería Hasta 9 horas Hasta 8 horas Hasta 7 horas
Puertos USB USB 2.0 USB 2.0 USB 2.0
Bluetooth v4.0 v4.0 3.0 + HS
Cámara Web 2,0 MP 5MP 5MP
N° celdas batería 3,600 mAh 1 celda 4000 mAh
Memoria RAM 1 GB 1GB 1GB
WiFi b/g/n (2,4 GHz)
/WiFi Direct b/g/n (2,4 GHz)
/WiFi Direct compatible con
Miracas
Memoria caché 8 GB
Sistema operativo Android 4.2 Android 4.2 Android 4.2
Garantía proveedor 1 año 1 año 1 año
Disco duro 8 GB 16GB 16GB
Peso 310 gr 350 gr 325 gr
Marca procesador Dual Core de
1,2 GHz MTK 8121 Quad
Core Marvell SOC PXA986
Dual Core
Lector tarjetas memoria
Micro SD (hasta 32GB)
Micro SD (hasta 32GB)
Micro SD (hasta 32GB)
Velocidad procesador 1,2 GHz 1.3Ghz 1,2 GHz
Precio S/. 500.00 S/. 600.00 S/. 600.00
66
Para seleccionar la tablet se ha considerado los siguientes criterios.
C1: Costo del producto.
C2: Rendimiento del producto.
C3: Compatibilidad del producto.
C4: Garantía del producto.
C5: Soporte del Proveedor
Opciones de Tablets.
A1: Galaxy Tab3 Lite Samsung
A2: Tablet Quad Core Lenovo
A3: Tablet Slave HP
Se utiliza la siguiente escala de puntajes.
NIVEL PUNTOS
EXCELENTE 3
BUENO 2
REGULAR 1
C1 C2 C3 C4 C5 TOTAL
A1 3 3 2 3 3 14
A2 2 3 2 2 3 12
A3 2 3 2 2 3 12
TOTAL 7 9 6 7 9 38
La tablet seleccionada fue la alternativa A1: Galaxy Tab3 Lite Samsung.
Argumentos de selección
Ultra portabilidad a llevar con facilidad en todas partes.
Experiencia optima de visión: Pantalla de alta resolución de tablet muestra su
hospitalidad al máximo.
67
Tiene mayor duración de batería en comparación a las otras alternativas.
3.2.3. PRUEBAS
El objetivo de este punto consiste en elaborar un plan de Pruebas que permita encontrar
el origen de los posibles errores y abordarlos para realizar un aplicativo más estable. Los
procesos para el aseguramiento de la calidad y los responsables de realizar cada
proceso se describen en la Tabla 13.
Tabla 13 Proceso de pruebas del aplicativo Fuente: Elaboración Propia
ProcesoLider técnico
de calidad
Ingeniero de
pruebas
Proveedor
de
desarrollo
Lider Usuario
Realiza
Diseño de
pruebas
1. Genera
Grafo
Funcional(GF)
y/o Matriz de
Guiones de
Prueba (MGP)
Realiza
pruebas de
Certificación-
1
2. Ejecuta
Matriz de
Guiones de
Prueba. En
caso encuentre
errores, notifica
al proveedor
3. Corrige
defectos
Realiza
pruebas de
Certificación-
2
4. Consolida
resultados de
prueba de
certificación
Realiza
pruebas de
Ratificación
5. Ejecuta guiones
de Ratificación. En
caso la ratificación
es exitosa firma
acta de
conformidad de
pruebas de
ratificación. Caso
contrario informa
No conformidad del
las pruebas.
68
3.2.4. ARQUITECTURA
La arquitectura del aplicativo móvil es la organización o estructura de sus partes más
relevantes, lo que permite tener una visión común entre todos los involucrados (inspector
y cliente) y una perspectiva clara del sistema completo para realizar la inspección
vehicular.
La arquitectura se ve influenciada por la plataforma software, sistema operativo móvil,
gestor de bases de datos, consideraciones de desarrollo. Muchas de estas restricciones
constituyen requisitos no funcionales del sistema.
Requisitos no funcionales
La arquitectura del aplicativo debe estar alineada a una arquitectura de Aplicación con
información dinámica. La información está en almacenada en una base de datos y la
aplicación accede a un script (lenguaje de servidor) que se conecta a la base de datos y
genera archivo descargable que retorna a la aplicación.
Ventajas:
Permite editar los datos de la base de datos, o generar el contenido con
formularios, o con conector de base de datos.
La modificación de información es sencilla y rápida.
Desventajas:
Complejidad del desarrollo mayor.
Costes de hosting Web para alojar base de datos.
69
En la Figura 47 se muestra la arquitectura del aplicativo móvil con información dinámica.
Aplicativo
Movíl
InternetServidor
Base de
datos
Cliente
Inspector
Figura 47 Arquitectura del aplicativo móvil
Fuente: Elaboración Propia
3.3. APLICACIÓN
A continuación detallaremos el funcionamiento del aplicativo.
3.3.1. Integración con el Sistema de Pacífico Seguros SA
La integración del Aplicativo Móvil para las inspecciones vehiculares se hará con el nuevo
sistema el cual está en implementación en la compañía Pacífico Seguros SA.
Dicho sistema denominado PolicyCenter perteneciente a la empresa Guidewire[11] es un
sistema para el manejo del registro, modificación y mantenimiento de las pólizas de todos
los tipos (Vehiculares, riesgos de propiedad, para Viajes, etc.).
70
Al ser una tecnología de vanguardia permite la integración con el lenguaje Java, en el
cual se ha desarrollado nuestro aplicativo móvil asegurando también actualizaciones y
mantenimiento del mismo (ver Figura 48).
A continuación se describen los procesos enumerados.
1. Se genera la orden de inspección desde el sistema PolicyCenter.
2. El inspector realiza la inspección por medio del aplicativo móvil.
3. Inspector graba la inspección realiza y automáticamente se actualiza la base de
datos en PolicyCenter. Y envía un email de constancia de la inspección.
4. Con la información guardada y actualizada, el sistema PolicyCenter emite
automáticamente la póliza para el cliente.
5. La póliza emitida se envía por mail al cliente y de forma paralela se envía al área
de compaginación para su impresión y envió del físico.
Figura 48 Funcionamiento del aplicativo móvil
Fuente: Elaboración Propia
71
3.3.2. Seguridad de la Aplicación
La compañía Pacífico Seguros cuenta con un módulo de seguridad desde el cual se
administra las opciones de usuarios para todos sus programas tanto de intranet como los
que se encuentran en la red.
Este módulo lleva el nombre de SSA y tiene como función principal la asignación de
perfiles y roles así como la determinación de permisos ya sea para un perfil o para un
usuario en específico. Este módulo se encuentra actualmente en funcionamiento y será
adaptado para el funcionamiento con el nuevo software PolicyCenter.
Con respecto a nuestro aplicativo móvil, este extrae la información de las tareas
pendientes del usuario sin modificarla debido a que solo se tiene acceso desde la
aplicación a la modificación y carga de información respecto a la inspección.
En consecuencia, el aplicativo se rige bajo los parámetros que ha designado el módulo
SSA. Evitando de esta manera la manipulación de información que no corresponda.
3.4. MONITOREO
a) Concluida la Ratificación, se iniciará el procedimiento de Aseguramiento y Control de
la Calidad - Seguimiento. , el cual se realiza con frecuencia diaria y durante 15 días
(ver Figura 49).
Líder usuario: Es el responsable que generó el requerimiento.
HelpDesk: Responsables de derivar el ticket al área correspondiente.
Administrador de calidad: Equipo responsable del seguimiento y asegurar la
calidad del aplicativo luego del pase a producción.
Proveedores: Empresa responsable del desarrollo.
72
En caso de no identificar defectos o errores el líder usuario debe de llenar una encuesta
de satisfacción (ver Figura 50).
b) El líder del proyecto convoca la reunión de Cierre de Proyecto.
c) El líder del proyecto realiza transferencia al equipo de Continuidad y Mantenimiento.
Como evidencia de dicho acuerdo se genera Acta de Transferencia de Continuidad
Operativa.
Figura 49 Procedimiento de monitoreo
Fuente: Elaboración Propia
Administrador de la Calidad Nivel D
(Proveedores)
Equipo de TI
Ticket resuelto? No
Proveedores
SiLíder Usuario
• GW
• Documentum
• HP Exstream
• Otros
Help Desk
Realiza seguimiento en producción.
En caso Identifica defectos en
producción. Genera Ticket.
Proveedores que
pueden ser
contactados para
solución y validación
de defectos.
Aplicación Alerta
Aplicación de Monitoreo
IT Operator
Una vez que el
ticket ha sido
resuelto,
informará al líder
usuario y
actualizará la
documentación
asociada.
Help Desk se encarga
de abrir tickets.
Lider Usuario
Crear ticket
Nivel B
(Helpdesk)
Problema Peformance
IT Operator
Revisa los tickets y enviará
al proveedor de desarrollo.
Error?
Si
Fin
No Llena encuesta
de satisfacción.
73
Figura 50 Encuesta de Satisfacción del Usuario
Fuente: Formatos TI Pacifico Seguros
3.5. MANTENIMIENTO
Después de la trasferencia del aplicativo a continuidad operativa, tendremos que tener un
plan de mantenimiento, el cual incluye los principales tipos de mantenimiento [12]:
Mantenimiento adaptativo, perfectivo, correctivo y preventivo.
74
Mantenimiento Adaptativo
Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios
en el entorno (hardware o software) en el cual se ejecuta.
El mantenimiento adaptativo es cada vez más usual debido principalmente al cambio,
cada vez más rápido, en los diversos aspectos de la informática: nuevas generaciones de
hardware cada dos años, nuevos sistemas operativos -ó versiones de los antiguos- que
se anuncian regularmente, y mejoras en los periféricos o en otros elementos del sistema.
Mantenimiento Perfectivo
Es el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas
por el usuario.
Desde algo tan simple como cambiar el formato de impresión de un informe, hasta la
incorporación de un nuevo módulo aplicativo.
Mantenimiento Correctivo
El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles defectos de
los programas.
Entre otros, los fallos en el software pueden ser de:
Procesamiento, por ejemplo, salidas incorrectas de un programa.
Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda
de información.
Programación, por ejemplo, inconsistencias en el diseño de un programa.
Documentación, por ejemplo, inconsistencias entre la funcionalidad de un
programa y el manual de usuario.
75
Mantenimiento Preventivo
Este último tipo de mantenimiento consiste en la modificación del software para mejorar
sus propiedades (por ejemplo, aumentando su calidad y/o su mantenimiento) sin alterar
sus especificaciones funcionales. Por ejemplo, se pueden incluir sentencias que
comprueben la validez de los datos de entrada, re estructurar los programas para mejorar
su legibilidad, o incluir nuevos comentarios que faciliten la posterior comprensión del
programa. Este tipo de mantenimiento es el que más partido saca de las técnicas de
ingeniería inversa y reingeniería.
El mantenimiento Adaptativo, perfectivo y correctivo se realizan a través de solicitud de
requerimientos rápido (SOL rápido). A continuación detallamos el procedimiento que se
debe seguir para canalizarlo.
PROCEDIMIENTO SOL RAPIDO
Fuente: Procedimientos TI Pacifico Seguros
Líder Usuario
a) Presenta necesidad de atención de requerimiento al Especialista de Negocios.
Especialista de Negocios
b) Evalúa necesidad del Líder Usuario.
c) Determina si es un requerimiento simple que puede ser atendido como SOL Rápido.
d) En caso sea un requerimiento simple, elabora la sección inicial del SOL Rápido
incorporando la información necesaria (flujos, instructivos, diagramas, procedimientos,
etc.) así como los responsables de certificar y ratificar la solicitud.
Subgerente del Servicio de Procesos y Soluciones de Negocio
e) Asigna un Jefe de Proyecto TI para evaluación del SOL Rápido.
Especialista de Soluciones
f) Analiza requerimiento de atención rápida – SOL Rápido.
76
g) En caso determine que se trata de un SOL Rápido crea el número de requerimiento
del SOL Rápido en la BDRE.
h) Elabora sección técnica del SOL Rápido y la Guía de Adaptación.
i) Comunica y envía SOL Rápido a Responsable de Estabilización con copia al
Especialista de Negocios
Jefe de Estabilización
j) Registra SOL rápido en el portal de Gestión de soles rápidos.
Especialista de Estabilización
k) Evalúa SOL Rápido y cruce de objetos.
Jefe de Estabilización
l) En caso la atención sea viable gestiona con el proveedor la asignación de recursos
humanos para atender el requerimiento.
m) En caso la atención no sea viable, comunica al Especialista de Negocios con copia al
Especialista de Soluciones la postergación o cancelación del SOL.
Especialista de Estabilización
n) En caso se cuenten con los recursos humanos asignados por el proveedor, gestiona y
planifica el desarrollo con recurso asignado y determina la secuencia de ejecución del
mismo.
o) Registra fechas estimadas de inicio de desarrollo y pase a producción del SOL en el
portal de Gestión de Soles Rápidos.
p) Transfiere SOL al Administrador de la Calidad y coordina capacitaciones.
Administrador de la Calidad
q) Ejecuta la etapa de Diseño del procedimiento de Aseguramiento y Control de la
Calidad y aquellos definidos en la Guía de Adaptación.
77
Proveedor de Desarrollo
r) Realiza el desarrollo según lo especificado en la solicitud de requerimiento rápido.
s) Genera la documentación necesaria para el pase a producción.
Especialista de Estabilización
t) Verifica correcto funcionamiento del desarrollo realizado, aplicación modificada.
u) Realiza el proceso de pase al ambiente de pre-producción siguiendo el proceso
Gestión de Cambios - Pase a Pre Producción
Administrador de la Calidad
v) Ejecuta la etapa de Certificación del procedimiento de Aseguramiento y Control de
la Calidad y de aquellos definidos en la Guía de Adaptación.
Especialista de Estabilización
w) Realiza el pase a Producción siguiendo el procedimiento de Gestión de Cambios -
Pase a Producción.
Administrador de la Calidad
x) Ejecuta la etapa de Ratificación del procedimiento de Aseguramiento y Control de la
Calidad y aquellos definidos en la Guía de Adaptación.
Jefe de Estabilización
y) Comunica al Especialista de Negocios, con copia al Especialista de Soluciones, y
actualiza fechas y estado del requerimiento en el portal de gestión de soles rápidos
A continuación se muestra el diagrama de bloques del soporte al usuario, así como la
labor que desempeña el área de mantenimiento de Pacifico Seguros.
Inicia con la recepción de incidentes o recepción de solicitudes, actividades de Help desk
y derivando los casos al área de mantenimiento (ver Figura 51).
78
SOPORTE A USUARIOS
Actividades
Proveedores
Sistemas
Gestión de problemas
Gestión de cambios
Entradas
Clientes
Salidas Fuera de alcance
Fuera de alcance
Servicios Help Desk
MANTENIMIENTO OPERATIVO
Fuera de alcance
Fuera de alcance
Fuera de alcance
Mantenimiento Operativo
Gestión de incidentes
Gestión de problemas
Gestión de inventario
Gestión de requerimientos
Gestión de terceros/garantía
Gestión de compras
Cierre de ticket
Usuarios de diversas áreas
Usuarios Externos
SERVICIOS HELP DESK
Recepción de incidentes.
Recepción de solicitudes de servicios.
Usuarios de diversas áreas
Unicenter Service Desk CA
Figura 51 Diagrama de bloques soporte a usuarios
Fuente: Proceso TI Pacifico Seguros
GESTIÓN DEL PROYECTO
La Gestión del proyecto es lograr un balance al gestionar objetivos, restricciones para
desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios de
Pacifico Seguros.
3.5.1. Plan del proyecto
El objetivo de esta actividad es definir y preparar las condiciones de trabajo,
estableciendo recursos, fechas y costes, para lograr los objetivos que se persiguen con el
proyecto (ver Tabla 14) [13].
79
Tabla 14 Plan del proyecto Fuente: http://administracionelectronica.gob.es
Tarea GPI 2.1: Selección de la Estrategia de Desarrollo
El objetivo de esta tarea es elegir la estrategia de desarrollo más adecuada al proyecto.
Mientras que la metodología especifica procesos, actividades, tareas y productos a
obtener en cada una de ellas, la estrategia de desarrollo es el enfoque a utilizar para
establecer cómo debe organizarse el proyecto.
Tarea GPI 2.2: Selección de la Estructura de Actividades, Tareas y Productos
La estructura de procesos, actividades y tareas que se presenta abarca el desarrollo
completo de sistemas de información y será preciso adaptarla nuestro proyecto. En esta
tarea se selecciona la estructura del proyecto, estableciendo los procesos principales de
desarrollo del aplicativo móvil. Para cada proceso se determinan las actividades y tareas
a realizar, así como los productos a generar, en función de las características concretas
80
del proyecto.
Tarea GPI 2.3: Establecimiento del Calendario de Hitos y Entregas
Esta tarea tiene como objetivo, en función de las actividades y tareas seleccionadas en
GPI 2.2, establecer los plazos de realización de las actividades y tareas del proyecto, las
fechas en que se producirán las entregas y aquellas en que deben recibirse los productos
adquiridos y los trabajos encargados a terceros.
Asimismo, se establecen los hitos o puntos de control precisos para la gestión y
seguimiento del desarrollo del proyecto. Entre estos deben incluirse, como mínimo, los de
fin de proceso ya previstos.
Tarea GPI 2.4: Planificación Detallada de Actividades y Recursos Necesarios
El objetivo de esta tarea es la programación global del proyecto, planificando en el tiempo
las actividades y tareas, y realizando la asignación de recursos necesaria en función de
los distintos perfiles implicados. La planificación detallada de actividades y tareas,
recursos y plazos, permite concretar con exactitud el plan de costes del proyecto.
Para la programación de tiempos y esfuerzos se utilizan técnicas de planificación
basadas en datos de gestión de proyectos similares realizados en la empresa o de
referencias externas.
Tarea GPI 2.5: Presentación y Aceptación de la Planificación General del Proyecto
El objetivo de esta tarea es la presentación de la Planificación General del Proyecto al
Comité de Seguimiento para su aprobación.
81
3.5.2. Cronograma
Para el proyecto se debe de establecer el Calendario de Hitos y Entregas.
A continuación se muestra un cronograma tentativo, incluye: Estimación de tiempo, costo
y recursos (ver Figura 52).
Figura 52 Cronograma de actividades
Fuente: Elaboración propia
82
3.5.3. Actas de Reunión, Informes
Su finalidad es presentar la información sobre la marcha del proyecto y estudiar las
posibles desviaciones e incidencias, tomando decisiones o adquiriendo compromisos
para determinar y realizar las acciones apropiadas que resuelvan dichas desviaciones o
incidencias.
Las reuniones externas ya están previstas, en ellas el líder de proyecto informará al
Comité de Seguimiento de la marcha del proyecto exponiendo y aclarando todos los
puntos del Informe de seguimiento en el período, haciendo hincapié en la información
relativa a las incidencias encontradas, ya que muchas tendrán su origen en el seno del
Cliente o Usuario.
Se manejan reuniones planificadas, de definiciones, de presentación, así mismo se
enviaran informes semanales, utilizando la plantilla que usa Pacifico Seguros (ver Figura
53).
Figura 53 Informe semanal del proyecto
83
Fuente: Formatos TI Pacifico Seguros
3.5.4. Lecciones Aprendidas
Las lecciones aprendidas nos permiten organizar una información para ser aprovechada
en eventos que se enfrentarán en un mañana. Las experiencias vividas en el proyecto
pueden ser un aporte fundamental para otros proyectos, para lograr este propósito es
necesario disponer de la información inherente a esas situaciones para que se transmita
a todos aquellos que puedan tener algún interés en llevar a cabo acciones similares de la
manera más eficiente y óptima posible. Se utilizará el formato que usa Pacifico Seguros
(ver figura 54).
Figura 54 Relación de lecciones aprendidas
Fuente: Formatos TI Pacifico Seguros
84
CAPÍTULO 4: ANALISIS DE COSTO BENEFICIO
4.1. ANALISIS DE COSTO
El análisis de costo va permitir definir la factibilidad económica del proyecto.
Por tal motivo para la validación económica de nuestro proyecto, diseñamos un cuadro
comparativo entre el flujo de proceso actual contra el flujo propuesto como solución (ver
Tabla 15). Con estos datos elaboraremos un flujo de caja para poder calcular el VAN y el
TIR.
Tabla 15 Cuadro comparativo de costos Fuente: Elaboración propia
Descripción Costo
Actual
Costo
Propuesto
Hoja de inspección S/. 0.30 S/. 0.00
Honorario del inspector S/. 15.00 S/. 15.00
Pasaje (promedio) S/. 5.00 S/. 5.00
Digitación de la solicitud + Escaneado S/. 3.00 S/. 0.00
Ejecución del endoso S/. 4.00 S/. 0.00
Impresión del endoso S/. 1.20 S/. 0.00
Courier para el endoso S/. 1.50 S/. 0.00
Total S/. 30.00 S/. 20.00
Ahorro por inspección S/. 10.00
Ahorro mensual (promedio 2500 inspecciones) S/. 25,000.00
Ahorro Anual S/. 300,000.00
En la Tabla 16 se detalla los costos de hardware, software y recursos humanos para la
implementación del proyecto.
85
Tabla 16 Costos del proyecto Fuente: Elaboración propia
Tipo de
costoDescripción Costo Detalle
Servidor de BD S/. 0 Pacifico cuenta con el equipo
Computadoras Core i5 S/. 0 Pacifico cuenta con el equipo
Sala multimedia equipada S/. 0 Pacifico cuenta con el equipo
Tablets S/. 6,000 12 Tablets Samsung
Costos de Hardware S/. 6,000
Windows Server 2008 R2 S/. 0 Pacifico cuenta con licencia
Android SDK S/. 0 No necesita licencia
Oracle 10g S/. 0 Pacifico cuenta con licencia
Erwin S/. 0 Pacifico cuenta con licencia
Rational Rose Entrepise S/. 0 Pacifico cuenta con licencia
Microsoft visio S/. 0 Pacifico cuenta con licencia
Internet S/. 0 Pacifico cuenta plan de datos
Costos de Software S/. 0
Jefe de Proyecto S/. 32,640 272 horas
Analista Funcional S/. 9,408 112 horas
Ingeniero de Soluciones S/. 13,392 144 horas
Desarrollador 1 S/. 11,760 168 horas
Certificación S/. 19,344 208 horas
Costos de Recursos S/. 86,544
Total Inversión S/. 92,544
Hardware
Software
Recursos
En la Tabla 17 se detalla el flujo de caja del proyecto, considerando un periodo de 24
meses.
Teniendo como inversión inicial (flujo negativo) el monto de implementación del aplicativo
móvil y como flujo positivo el ahorro mensual de las inspecciones vehiculares detalladas
en la tabla 14. El VAN obtenido recomienda la implementación del aplicativo móvil. El TIR
obtenido es mayor a la tasa mínima de descuento que tiene Pacifico Seguros (20% de
tasa de descuento).
86
Tabla 17 Flujo de caja del proyecto Fuente: Elaboración propia
Proyecto: Aplicativo móvil
Flujo de caja - CASO DE COSTOS
Mes 1 Mes 2 Mes 23 Mes 24
Factores de Negocio
Ahorro en proceso propuesto 25,000 25,000 25,000 25,000
Total 25,000 25,000 25,000 25,000
Inversion
Desarrollo (S/. 86,544)
Hardware -6000
Total inversiones -92,544
Flujo de caja (S/. 92,544) 25,000 25,000 25,000 25,000
Año1 300,000
Año2 300,000
Tasa de dscto 20%
Van 2 años 458,333
Inversion 92,544
TIR 27%
Payback 4 meses
VAN mayor que la Inversión
4.2. ANALISIS DE BENEFICIO
a) Beneficios intangibles
Las mejoras en el servicio de inspección vehicular pueden repercutir de varias maneras.
Cliente:
Siente que recibe un servicio más personalizado.
Puede recomendar a otras personas tomar un seguro.
Deja de lado tomar seguros en otra compañía.
Empresa:
Mayor prestigio en niveles de servicio al cliente.
87
b) Beneficios tangibles
Estos beneficios serán apreciados en el ahorro, de material, de personal y otros.
Se reducirá el costo de economato en impresiones de fichas de inspección
vehicular.
Se reducirá el costo de digitación de información.
Los inspectores vehiculares ahorraran tiempo de traslado a la oficina.
4.3. ANALISIS DE SENSIBILIDAD
La finalidad del análisis de sensibilidad consiste en mejorar la calidad de la información
para que el inversor tenga una herramienta adicional para decidir si invierte o no en el
proyecto.
A continuación en la Tabla 18 se muestra el análisis de sensibilidad considerando
escenarios: Optimista, moderado y pesimista. Modificando las variables de inversión,
tasa de descuento, flujo mensual y periodo, se obtiene resultados diferentes del VAN,
TIR y el tiempo de recuperación (Payback).
Por lo tanto, la decisión de invertir o no en este proyecto no se basa solamente en el
cálculo del VAN realizado previamente, sino en la comprensión del origen de la
rentabilidad del proyecto y del posible cambio en las variables estimadas.
Tabla 18 Análisis de sensibilidad de costos Fuente: Elaboración propia
Variables Real Optimista Moderado Pesimista
Inversión 92,544S/. 80,000S/. 92,544S/. 110,000S/.
Tasa de descuento 20% 25% 20% 15%
Flujo Mensual 25,000S/. 30,000S/. 25,000S/. 20,000S/.
Periodo(meses) 24 24 24 24
VAN 458,333S/. 518,400S/. 458,333S/. 390,170S/.
TIR 27% 37% 27% 18%
Payback 4 meses 3 meses 4 meses 6 meses
88
CONCLUSIONES
El diseño de un aplicativo móvil, mejora el proceso de inspección vehicular,
debido a que actualmente el proceso tiene tareas manuales que no agregan
valor.
El diseño del aplicativo móvil, permite optimizar los recursos económicos de la
empresa, luego de la evaluación de las herramientas tecnológicas de vanguardia
existentes en el mercado se decidió utilizar las herramientas tecnológicas con las
que cuenta Pacifico Seguros.
El diseño del aplicativo móvil tiene una interfaz amigable, fácil de utilizar y permite
registrar las inspecciones de forma sencilla y en línea.
Con la implementación del aplicativo móvil se va mejorar el tiempo de inspección,
debido a que el inspector va poder registrar los datos del vehículo en menor
tiempo.
89
RECOMENDACIONES
Implementar el aplicativo móvil para las inspecciones vehiculares, para lograr un
proceso más eficiente y contribuir a mejorar la experiencia del cliente que opta por
comprar un seguro a Pacifico Seguros.
Utilizar las herramientas tecnológicas propuestas, porque contribuyen al mejor
rendimiento del aplicativo y bajo costo de implementación, considerando que
Pacifico Seguros cuenta con las licencias de software y hardware.
El proyecto del aplicativo móvil se puede replicar en otras áreas de Pacifico
Seguros como inspecciones de Siniestros, Inspecciones de Maquinarias e incluso
se puede aplicar en otras compañías de seguros realizando pequeñas
modificaciones (Ejemplo: El aplicativo pueda soportar videos cortos).
90
BIBLIOGRAFIA
[1] Aumento del parque automotor en el Perú -http://peru21.pe/economia/habra-
45-millones-vehiculos-2020-2124538 [2] Estadísticas de crecimiento de seguros vehiculares en el Perú -
http://gestion.pe/noticia/910849/primas-seguros-vehiculares-crecen-1285-junio [3] Estadísticas de crecimiento de seguros vehiculares en el Perú-
http://gestion.pe/noticia/910849/primas-seguros-vehiculares-crecen-1285-junio [4] AÑAZGO LA ROSA, Angie Monique, Implementación de un aplicativo para
teléfonos móviles que indique las rutas de transporte público de la ciudad de lima a partir de la ubicación del usuario. Tesis para obtener título de Ingeniero de Telecomunicaciones, Perú/Lima, Mayo 2011.
[5] RAMOS CEVALLOS, Daniel, Análisis y propuesta de optimización del proceso de
producción de una póliza de seguro para la rama a vehículos livianos y particulares tipo VI o "Autotal" en Aseguradora del Sur. Tesis para obtener título de Ingeniero Industrial,Ecuador/Quito/USFQ, Mayo 2011
[6] CARACTERÍSTICAS DE MÓVILREPORT -http://www.movilreport.es, España
2012. [7] Composición Accionaria de Pacífico Seguro -http://www.equilibrium.com.pe
/pps.pdf [8] PACÍFICO SEGUROSSA, Términos de seguros vehiculares -
http://www.Pacíficoseguros.com/site/Personas/Vehiculos-y-SOAT/Seguro-de-Autos-Todo-Riesgo.aspx
[9] PACÍFICO SEGUROS SA, Procedimiento de inspección vehicular. Documentos
de Negocio, Abril del 2012 [10] Rational Rose Entrepise - http://www-
03.ibm.com/software/products/es/ratirosefami# [11] GUIDEWIRE - http://www.guidewire.com [12] TIPOS DE MANTENIMIENTO,
http://ingenieria.uatx.mx/labastida/files/2011/08/MANTENIMIENTO-DE-SOFTWARE.pdf
[13] GESTIÓN DE PROYECTOS,
http://administracionelectronica.gob.es/pae_Home/dms/pae_Home/documentos/Documentacion/Metodologias-y-guias/Metricav3/METRICA_V3_Gestion_de_Proyectos.pdf