Tesis

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO – CHILE
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
Sistema Cotización de Seguros Automotrices on-line.
FELIPE ANDRÉS SILVA PADILLA
INFORME FINAL DEL PROYECTO

PARA OPTAR AL TÍTULO PROFESIONAL DE
INGENIERO DE EJECUCIÓN EN INFORMÁTICA
Enero, 2010
Pontificia Universidad Católica de Valparaíso – Chile
Facultad de Ingeniería
Escuela de Ingeniería Informática
Sistema Cotización de Seguros Automotrices on-line.
FELIPE ANDRÉS SILVA PADILLA
Profesor Guía: José Miguel Rubio León
Carrera: Ingeniería de Ejecución en Informática
Enero, 2010
DEDICATORIAS
A mis padres, hermana y mis abuelos, por depositar en mí su confianza, a mi futura
esposa por apoyarme en todo momento y en especial a mi abuelita que partió antes de
poder ver este logro.
FELIPE A(DRES SILVA PADILLA

AGRADECIMIE(TOS
Agradezco este logro en primer lugar a Dios, a mis padres y familia quienes a pesar del
tiempo no dudaron en que este logro seria alcanzado.
A la Pontificia Universidad Católica de Valparaíso, por entregarme los valores
profesionales que han permitido durante estos años de trabajo enfrentar cualquier
desafío.
A la familia que durante mis años de estudios en la ciudad de Valparaíso, fueron mi
soporte y cobijo.
FELIPE A(DRES SILVA PADILLA

Resumen
El proyecto a desarrollar es un sistema de cotizaciones de seguros automotrices on-line,
el cual está orientado al ser utilizado por parte de corredores asociados a la compañía de
seguros, en este caso en particular la compañía es RSA Chile S.A. El hecho de ser ésta
una aplicación Web permitirá a los corredores realizar cotizaciones vía remota y el
posterior envío del documento de la cotización vía e-mail, aumenta exponencialmente
los potenciales clientes y reduce los costos asociados a la captación de estos.
El aplicativo proveerá una plataforma capaz de interactuar con los sistemas de
productos y sistema de personas de la compañía aseguradora mencionada, donde se
implementará la aplicación. También consumirá los servicios de información comercial
de empresas externas (boletín comercial) y el servicio de información sobre la cantidad
de siniestros del posible asegurado (SISGEN). Esto para generar cotizaciones con
información fidedigna, incluyendo recargos o descuentos, permitiendo llevar a cabo la
posterior emisión de la póliza con valores cotizados.
Mientras tanto, la solución será desarrollada bajo una arquitectura web del tipo SOA
utilizando Ciclo de vida Clásico como paradigma de desarrollo y UML como lenguaje
de modelado, la herramienta de desarrollo será Microsoft Visual Studio .NET 2003, el
lenguaje de programación a utilizar será C#, el motor de base de datos es SQL 2000 e
Iseries.
Abstract
The project developed in this document is about an On-line Car insurance policy quote
system, oriented to be used by brokers that belong to an insurance company; in this
particular case of study the company is RSA Chile S.A.
As Web application, the system will allow brokers to quote by using a remote access
and let them to send quote document by e-mail wich results in exponencially increasing
potential customers and reducing costs associated with recruiting them.
Application will provide a platform capable to interact with both products and
costumers systems of the insurance company in which the web application will be
installed. In addition, the application will consume finantial information from Web
Services provided by external companies (financial newsletter) and the Web Service
which provide information about insured’s vehicle accident register (SISGEN). This
information is useful to generate quotes with true information, including recharge or
discounts, and it allows submiting policy width quoted values before.
Solution will be developed under a SOA web architecture by using Classic Life Cycle
as a development paradigm and UML as modeling language. The development tool will
be Microsoft Visual Studio .NET 2003 with C# as programming language and the
Database Engine will be SQL Server 2000 and ISeries
ÍNDICE DE CONTENIDOS
1 Introducción ................................................................................................................. 11
1.1 El Problema .......................................................................................................... 12
1.2 Objetivos del Proyecto ......................................................................................... 14
1.3 Objetivo General del proyecto. ............................................................................. 14
1.4 Objetivos Específicos. .......................................................................................... 14
2 Metodología y Paradigma de Desarrollo ..................................................................... 15
2.1 Modelo en Cascada............................................................................................... 15
2.2 UML ..................................................................................................................... 17
3 Planificacion del Proyecto ........................................................................................... 18
3.1 Planificación ......................................................................................................... 18
3.1.1 Especificación de Tareas ............................................................................... 18
3.1.2 Definición de Hitos ........................................................................................ 27
3.1.3 Diagrama OBS ............................................................................................... 27
3.1.4 Diagrama EDT............................................................................................... 28
3.1.5 Carta Gantt ..................................................................................................... 29
3.1.6 Matriz de Responsabilidades ......................................................................... 31
3.1.7 Reporte con precedencias y duración de actividades. ................................... 37
3.1.8 Diagrama uso de Recursos ............................................................................ 44
3.2 Gestión del Riesgo ................................................................................................ 45
3.2.1 Identificación de riesgos ................................................................................ 45
3.2.2 Análisis de riesgos ......................................................................................... 46
3.2.3 Severidad del riesgo....................................................................................... 46
3.2.4 Probabilidad de Ocurrencia ........................................................................... 46
3.2.5 Exposición del riesgo .................................................................................... 47
3.2.6 Planes de mitigación y planes de contingencia ............................................. 48
3.3 Estudio de Factibilidad ......................................................................................... 49
3.3.1 Factibilidad Técnica ...................................................................................... 49
3.3.2 Arquitectura aplicación.................................................................................. 50
3.3.3 Estudio Factibilidad Económica. ................................................................... 51
3.3.4 Estudio Factibilidad Operacional. ................................................................. 51
3.3.5 Estudio Factibilidad Legal. ............................................................................ 51
4 Análisis y Diseño del Proyecto ................................................................................... 52
4.1 Especificación de Requerimientos........................................................................ 52
4.1.1 Requerimientos Funcionales ......................................................................... 52
Pontificia Universidad Católica de Valparaíso Página 6

4.1.2 Requerimientos no funcionales ..................................................................... 53
4.1.3 Casos de Uso ................................................................................................. 54
4.1.4 Actores ........................................................................................................... 54
4.1.5 Diagrama de Casos de Uso ............................................................................ 55
4.1.6 Casos de Uso Narrativo ................................................................................. 57
5 Diseño .......................................................................................................................... 64
5.2 Diagrama de Clases .............................................................................................. 67
5.3 Diagrama de Secuencias ....................................................................................... 68
5.3.1 Diagrama Secuencia Seleccionar Cobertura Adicional ................................. 68
5.3.2 Diagrama Secuencia Obtener Planes Comerciales ........................................ 68
5.3.3 Diagrama Secuencia Seleccionar Coberturas Adicionales ............................ 69
5.3.4 Diagrama Secuencia Generar PDF ................................................................ 70
5.3.5 Modelo Entidad Relación .............................................................................. 71
5.4 Diseño de Interfaces ............................................................................................. 72
6 Planes de Pruebas ....................................................................................................... 77
6.1 Pruebas de Unidad ................................................................................................ 77
6.2 Pruebas de Integracion.......................................................................................... 77
6.3 Pruebas de Sistemas ............................................................................................. 78
6.4 Plan de Pruebas .................................................................................................... 79
7 Conclusiónes................................................................................................................ 82
7.1 Conclusiones......................................................................................................... 82
Referencias .................................................................................................................... 84

INDICE DE FIGURAS
Figura 1 Ciclo de vida clásico del software. ................................................................... 17

Figura 2 Diagrama OBS ................................................................................................. 27
Figura 3 Diagrama Estructura de Desglose de Trabajo ................................................. 28
Figura 4 Carta Gantt ....................................................................................................... 29
Figura 5 Carga Gantt (continuación) .............................................................................. 30
Figura 6 Matriz de Responsabilidades............................................................................ 31
Figura 7 Matriz de Responsabilidades (continuación) ................................................... 32
Figura 8 Matriz de Responsabilidades (continuación) .................................................. 33
Figura 9 Matriz de Responsabilidades (continuación) .................................................. 34
Figura 10 Matriz de Responsabilidades (continuación) ................................................ 35
Figura 11 Matriz de Responsabilidades (continuación) ................................................ 36
Figura 12 Diagrama Gantt Optimista ............................................................................. 37
Figura 13 Diagrama Gantt Optimista (continuación ) .................................................... 38
Figura 14 Diagrama Gantt Esperada. ............................................................................. 39
Figura 15 Diagrama Gantt Esperado (continuación) ...................................................... 40
Figura 16 Diagrama Gantt Pesimista .............................................................................. 41
Figura 17 Diagrama Gantt Pesimista (continuación) ..................................................... 42
Figura 18 Diagrama Calculo de Fechas .......................................................................... 43
Figura 19 Diagrama Camino Critico .............................................................................. 44
Figura 20 Diagrama Uso de Recurso .............................................................................. 44
Figura 21 Arquitectura de la aplicación ......................................................................... 50
Figura 22 Modelo de Casos de Generar Cotización ....................................................... 55
Figura 23 Modelo de Casos de Generar Cotización ....................................................... 56
Figura 24 Asociar Plan Comercial ................................................................................. 57
Figura 25 Diagrama de Actividades Ingresar Proponente .............................................. 64
Figura 26 Diagrama Actividades Validar Información Comercial ................................ 65
Figura 27 Diagrama Actividades Ingresar Asegurado ................................................... 65
Figura 28 Diagrama Actividades Validar Información Siniestralidad ........................... 66
Figura 29 Diagrama de Clases ........................................................................................ 67
Figura 30 Diagrama de Secuencia Seleccionar Cobertura Adicional............................. 68
Figura 31 Diagrama de Secuencia Obtener Planes Comerciales .................................... 68
Figura 32 Diagrama de Secuencia Seleccionar Coberturas Adicionales ........................ 69
Figura 33 Diagrama de Secuencia Seleccionar Coberturas Adicionales ........................ 70
Figura 34 Modelo Entidad Relación ............................................................................... 71
Figura 35 Prototipo ““Ver Cotizaciones Realizadas” , Interfaz Filtros .......................... 72
Figura 36 Prototipo ““Ver Cotizaciones Realizadas” Interfaz Resultado Búsqueda ..... 72
Figura 37 Prototipo “Ver Cotizaciones Realizadas” Interfaz Detalle Cotización .......... 73
Figura 38 Prototipo “Generar Cotización” Interfaz Paso 1 ............................................ 74
Figura 39 Prototipo “Generar Cotización” Interfaz Agregar Vehículo .......................... 74
Figura 40 Prototipo “Generar Cotización” Interfaz Paso 2 ............................................ 75
Figura 41Prototipo “Generar Cotización” Interfaz Paso 3 ............................................ 75
Figura 42 Prototipo “Generar Cotización” Interfaz Enviar PDF .................................... 76

INDICE DE TABLAS
Tabla 1 Especificación tarea EDT .................................................................................. 18

Tabla 2 EDT OBS .......................................................................................................... 18
Tabla 3 EDT Matriz de Responsabilidades .................................................................... 19
Tabla 4 EDT Definición de Entregables......................................................................... 19
Tabla 5 EDT Definición de Diagrama Gantt .................................................................. 19
Tabla 6 EDT Definición de Diagrama Gantt .................................................................. 19
Tabla 7 EDT Definición de riesgos ............................................................................... 20
Tabla 8 EDT Definición de planes de mitigación y planes de contingencia ................. 20
Tabla 9 EDT Identificación y Análisis de Riesgos ....................................................... 20
Tabla 10 EDT Requerimientos Funcionales .................................................................. 20
Tabla 11 EDT Requerimientos no Funcionales ............................................................. 21
Tabla 12 EDT Requerimientos no Funcionales .............................................................. 21
Tabla 13 EDT Definición de Componentes ................................................................... 21
Tabla 14 EDT Definición Diagrama de Clases .............................................................. 21
Tabla 15 EDT Definición Diagrama de Secuencia ........................................................ 22
Tabla 16 EDT Definición Diagrama de Actividades...................................................... 22
Tabla 17 EDT Definición modelo Conceptual ............................................................... 22
Tabla 18 EDT Definición modelo entidad relación........................................................ 22
Tabla 19 EDT Diseño Servicios. .................................................................................... 23
Tabla 20 EDT Implementación base de datos lógica ..................................................... 23
Tabla 21 EDT Implementación base de datos física. ..................................................... 23
Tabla 22 EDT Implementación de Servicios Web según modelos WSDL .................... 23
Tabla 23 EDT Generación estilos capa de presentación ................................................ 24
Tabla 24 EDT Generación interfaces web del aplicativo ............................................... 24
Tabla 25 EDT Ejecución pruebas sobre Base de datos .................................................. 24
Tabla 26 EDT Ejecución pruebas sobre Base de datos .................................................. 24
Tabla 27 EDT Ejecución de pruebas sobre Capa Presentación ...................................... 25
Tabla 28 EDT Pruebas Integración ................................................................................ 25
Tabla 29 EDT Pruebas Aceptación ................................................................................ 25
Tabla 30 EDT Correcciones Base de datos. ................................................................... 25
Tabla 31 EDT Correcciones servicios Web ................................................................... 26
Tabla 32 EDT Correcciones capa de presentación ......................................................... 26
Tabla 33 EDT Implementación de Servicios Web según modelos WSDL .................... 26
Tabla 34 Hitos Externos ................................................................................................. 27
Tabla 35 Hitos Internos ................................................................................................. 27
Tabla 36 Plantilla Identificación de riesgos ................................................................... 45
Tabla 37 Identificación de Riesgos ............................................................................... 46
Tabla 38 Exposición al Riesgo ....................................................................................... 48
Tabla 39 Planes de mitigación y contingencia .............................................................. 49
Tabla 40 Estudio factibilidad técnica ............................................................................. 50
Tabla 41 Descripción narrativa caso de uso Generar Cotización. .................................. 57
Tabla 42 Descripción Ver Cotizaciones Realizadas. ...................................................... 58
Tabla 43 Administrar Planes .......................................................................................... 58
Tabla 44 Descripción Administrar Usuarios. ................................................................. 58
Tabla 45 Descripción Ingresar Asegurado. .................................................................... 58
Tabla 46 Descripción Ingresar Vehículos. ..................................................................... 59
Tabla 47 Descripción Generar Archivo PDF Cotización. .............................................. 59
Tabla 48 Descripción Generar Archivo PDF Cotización. .............................................. 59

Tabla 49 Descripción Enviar PDF Cotización vía Email. .............................................. 59
Tabla 50 Descripción Obtener Marcas / Modelos. ......................................................... 60
Tabla 51 Descripción Validar Información Siniestralidad ............................................. 60
Tabla 52 Descripción Validar Información Comercial. ................................................. 60
Tabla 53 Descripción Obtener Información Persona. .................................................... 60
Tabla 54 Descripción Guardar Cotización ..................................................................... 61
Tabla 55 Descripción Agregar Coberturas Adicionales. ................................................ 61
Tabla 56 Descripción Agregar Recargo / Descuento ..................................................... 61
Tabla 57 Descripción Seleccionar Plan Comercial. ....................................................... 61
Tabla 58 Descripción Seleccionar Plan Comercial. ....................................................... 61
Tabla 59 Descripción Activar Plan Comercial. .............................................................. 62
Tabla 60 Descripción Seleccionar Corredor. .................................................................. 62
Tabla 61 Descripción Administrar Parámetros Plan Comercial. .................................... 62
Tabla 62 Descripción Obtener Planes Comerciales. ...................................................... 62
Tabla 63 Descripción Asociar Coberturas Adicionales. ................................................. 62
Tabla 64 Descripción Obtener Coberturas Adicionales. ................................................ 63
Tabla 65 Plan de pruebas para Modulos o Interfaces ..................................................... 81
Tabla 66 Plan de Pruebas para Servicios Web. .............................................................. 81

1 I(TRODUCCIÓ(
La venta de seguros en Chile puede ser realizada por compañías de seguros generales o
por compañías de seguros de vida. Las primeras cubren el riesgo de pérdida o deterioro
en las cosas o el patrimonio, mientras que las compañías de seguros de vida cubren los
riesgos de las personas o bien garantizan a ésta, dentro o al término de un plazo, un
capital, una póliza saldada o una renta para el asegurado o sus beneficiarios. En forma
excepcional, los riesgos de accidentes personales y los de salud pueden ser cubiertos por
ambos tipos de compañías.
La contratación de un seguro se formaliza mediante la emisión de una póliza de

seguro, la cual es el documento justificativo del contrato que establece los derechos y
obligaciones del asegurado y del asegurador. Mediante este contrato el asegurador se
obliga, en el caso que se produzca un siniestro cubierto por la póliza, a indemnizar al
asegurado o a sus beneficiarios de acuerdo a las condiciones del seguro. Por su parte, el
asegurado se obliga al pago de una prima estipulada en la póliza.
Las primas de seguros en Chile son fijadas libremente por los aseguradores.
Asimismo, las comisiones por intermediación también son libremente convenidas entre
asegurador y corredor de seguros, dejándose constancia de ella en la respectiva póliza
[1].
Dentro del grupo de seguros generales se encuentran los de tipos automotrices,

en este grupo destacan los del tipo SOA, seguro obligatorio automotriz, y los seguros
automotrices para siniestros los cuales pueden asegurar a los vehículos y/o cubrir la
responsabilidad civil y/o daños a terceros. Es para este tipo de seguros que la compañía
RSA Seguros Chile S.A. ha solicitado a Sigma S.A., una empresas con más 25 años de
experiencia en desarrollo e implementación de soluciones informáticas para el negocio
de seguros, el desarrollo de una plataforma Web que permita la realización de
cotizaciones en línea de seguros automotrices.
A través de los capítulos en que se ha dividido este documento, se planteara la

problemática a solucionar y como se piensa desarrollar la mejor solución que satisfaga
los requerimientos. En este documento se presentará en forma detallada el proceso
mediante el cual se desarrollará el proyecto Cotizador de Seguros Automotrices On-
line.
En el primer capítulo del documento se describe el problema que se debe
abordar se define quienes son los interlocutores y cuáles serán los usuarios de de la
aplicación desarrollar. Desde el problema se desprenden los objetivos, general y
especifico, de la aplicación.
Continúa el documento mostrando cual será la planificación, esta estará guiada

por las estructuras de desglose de trabajo, definición el paradigma de desarrollo a
utilizar y el lenguaje de modelamiento a utilizar. En base al paradigma seleccionado,
Ciclo de Vida Clásico, se realiza el desarrollo del proyecto en las fases de Ingeniería de
Software, Análisis y Diseño que serán las etapas que quedan plasmadas en el presente
documento.

1.1 EL PROBLEMA
El Seguro no es otra cosa más que el contrato que se establece con una empresa
aseguradora. En dicho contrato, denominado póliza, la empresa se compromete a que si
la persona que compró el seguro, o beneficiario de este, sufre algún daño en su persona
(enfermedades o accidentes e incluso la muerte), o en algunos de sus bienes
(automóvil, empresa, taller o casa) por cualquier motivo (robo, incendio, terremoto),
dicha persona (o quien ella haya designado como beneficiario) recibirá la cantidad de
dinero acordada en la póliza. A este dinero se le conoce como indemnización [2].
Las empresas aseguradoras no únicamente pagan con dinero el daño que el
Asegurado o alguna de sus pertenencias hayan sufrido, sino que, según el tipo de
aseguradora y de contrato, pueden llegar a reparar ese daño. Por ejemplo si tuvo un
accidente automovilístico, su vehículo será reparado en los talleres con los que la
compañía aseguradora sostenga convenios. De la misma forma, la póliza establece la
cantidad de dinero que el Asegurado deberá pagar a la empresa cada mes o en el tiempo
que ambos hayan acordado. A este dinero que se le paga a la Compañía de Seguros se le
llama "Prima". Para muchas personas resultará obvio, pero es importante resaltar que
no se podrá contratar un seguro cuando el interesado haya sufrido un accidente o
desarrollado alguna enfermedad, ni cuando el automóvil, por ejemplo, ya esté chocado o
haya sido robado[2].
La palabra Seguro proviene del latín Securus, que significa libre y exento de todo
peligro, daño o riesgo. Contrato por el cual una persona natural o jurídica, se obliga a
resarcir pérdidas o daños que ocurran en las cosas que corren un riesgo en mar o tierra.
El Contrato de Seguro es el documento (póliza) por virtud del cual el asegurador se
obliga frente al asegurado, mediante la percepción de una prima, a pagar una
indemnización, dentro de los límites pactados, si se produce el evento previsto
(siniestro).
La póliza deberá constar por escrito, especificando los derechos y obligaciones de las
partes, ya que en caso de controversia, será el único medio probatorio[3].
El modelo de ventas de seguros automotrices se está cimentado en una arquitectura

con 5 bases las cuales son:
• Entidad Aseguradora: Son las encargadas de cubrir el riesgo de los seguros

que han sido contratados por sus clientes. Tambien llamadas compañía de
seguros.
• El Corredor: Son personas naturales o jurídicas, independientes de las
compañías de seguro. Su función es ofrecer a las personas que deseen
asegurarse por su intermedio, el seguro más conveniente, según las
necesidades de estas.
• Fuerza de Venta: Son captadores de posibles contratantes de seguros.
• El Proponente persona natural o jurídica la cual realiza el contrato del seguro
y es el responsable del pago del mismo.
• El asegurado es el beneficiario del seguro.
En la actualidad la interacción entre estas 5 bases se realiza siguiendo el siguiente

flujo:

1. La entidad aseguradora entrega al corredor los tipos seguros ofrecidos por esta,
estos tipos son denominados planes comerciales. Esta información es
entregada en formato electrónico del tipo estático, es decir planillas
electrónicas o archivos planos para inyectar información en la bases de datos
de propiedad del corredor.
2. El corredor transmite esta información a la fuerza de venta, la cual debe
realizar el contacto con los posibles proponentes. Esta tarea generalmente se
realiza en terreno.
3. Una vez realizada la captación de un cliente, este debe dirigirse donde el
corredor para realizar la oficialización del contrato de el seguro.
4. El corredor informa a la compañía de seguro la concretación de la póliza de
seguro.
Este método de trabajo presenta las siguientes deficiencias.
• La comunicación entre la entidad aseguradora y el corredor no es on-line, por lo

tanto surge la imposibilidad de implementar estrategias de márquetin con
rapidez y eficacia.
• Existe una gran dependencia cantidad de personas que componen la fuerza de
venta, mas grande la fuerza de venta mayor cantidad posibles clientes se pueden
contactar.
• Costos elevados en la captación.
• Imposibilidad de competir en el portal “Compara On-line”, el cual ofrece a un
usuario una gama de seguros en distintas compañías de seguros.

1.2 OBJETIVOS DEL PROYECTO
1.3 OBJETIVO GE(ERAL DEL PROYECTO.
Implementar una aplicación informática bajo una arquitectura web, que permita la
generación de cotizaciones de seguros automotrices.
1.4 OBJETIVOS ESPECÍFICOS.
Para atender el objetivo general se proponen los siguientes objetivos específicos:
• Diseñar e implementar una aplicación que permita obtener información

actualizada de los seguros disponibles para cotizar.
• Desarrollar funcionalidades capaces de consumir WebServices que entregan

información referente a deudas comerciales de los proponentes e información de
siniestralidad del asegurado.
• Proveer de una aplicación que genere un canal de transferencia de información

entre los actores e entidades involucrados en el proceso de cotización del un
seguro automotriz.
• Generar una aplicación la cual sea una vía para aumentar la competitividad de la
compañía de seguros.
• Desarrollar un sistema adaptable a los cambios y expansiones.
• Proveer una aplicación que sea este disponible para los usuarios desde cualquier
punto del país durante las 24 horas del dia.

2 METODOLOGÍA Y PARADIGMA DE
DESARROLLO
El proceso de Ingeniería de Software es un conjunto de actividades necesarias

para transformar los requisitos de un usuario en un software [5]. Dichas actividades
deben seguir un orden con el fin de lograr un desarrollo estándar, el cual facilite el
control y el trabajo del equipo encargado de llevar a cabo estas actividades. Los
paradigmas o metodologías de desarrollo de software plantean formas de trabajo,
encasillan las actividades en etapas y describen los procesos a realizar en cada una de
estas etapas, con el propósito de ofrecer la visibilidad al proceso y lograr un desarrollo
disciplinado.
Existen varias metodologías de desarrollo. Cada una de estas presenta diferentes

formas de trabajo. Entre las más utilizadas se encuentran
• Ciclo de Vida Clásico o Modelo en Cascada

• Modelo de Desarrollo por Prototipos
• Modelo en Espiral
• Proceso Unificado de Desarrollo
Se utilizará el Modelo en Cascada pues es la metodología de trabajo que está definida

como oficial, para el desarrollo de proyectos informáticos para el desarrollo de
proyectos por parte de la empresa Sigma para la compañía RSA.
2.1 MODELO E( CASCADA
Las etapas del ciclo de vida clásico se muestran en la figura 1. Este abarca las siguientes
actividades [4]:
1. Ingeniería y análisis del sistema.
Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza

estableciendo los requisitos de todos los elementos del sistema y luego asignando algún
subconjunto de estos requisitos al software. Este planteamiento es esencial cuando el
software debe interrelacionarse con otros elementos, tales como hardware, personas y
bases de datos. Esta parte abarca los requisitos globales a nivel del sistema con una
pequeña parte de análisis y diseño a un nivel superior.

2. Análisis de los requisitos del software.
Este proceso se centra esencialmente en el software. Para comprender la naturaleza

de los programas que hay que construir, el ingeniero de software debe comprender
el ámbito de la información del software, así como la función, el rendimiento y las
interfaces requeridas. Los requisitos, tanto del sistema como del software, se
documentan y se revisan con el cliente.
3. Diseño.
El diseño del software es un proceso multipaso que se enfoca sobre cuatro atributos
distintos: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. Al igual que en el análisis de los
requisitos, el diseño se documenta y forma parte de la configuración del software.
4. Codificación.
Aquí el diseño debe traducirse en una forma legible para la máquina. Si el diseño se
realiza de una manera detallada, la codificación puede realizarse mecánicamente.
5. Prueba.
Una vez que se ha generado el código, comienza la prueba del programa. La prueba
se centra en la lógica interna del software, asegurando que todas las sentencias se
han probado, y en las funciones externas, realizando pruebas que aseguren que la
entrada definida producen los resultados que realmente se requieren.
6. Mantención.
El software indudablemente, sufrirá cambios después de que se entregue al

cliente. Los cambios ocurrirán debido a que se hayan encontrado errores, a que
el software deba adaptarse a cambios del ambiente externo, o debido a que el
cliente requiera ampliaciones funcionales o del rendimiento. El mantenimiento
del software aplica cada uno de los pasos precedentes del ciclo de vida de un
programa existente en vez de a uno nuevo.

Figura 1 Ciclo de vida clásico del software.
2.2 UML
El Lenguaje Unificado de Modelado (UML) es un lenguaje estándar para

modelar el software. UML puede utilizarse para visualizar, especificar, construir y
documentar los artefactos de un sistema que involucra gran cantidad de software [6].
Para entender y poder leer modelos UML se debe entender los bloques básicos
de construcción, estos bloques poseen tres elementos principales:
• Elementos: Son la representación de un artefacto del sistema.

• Relaciones: Son las encargadas de ligar los elementos entre sí.
• Diagramas: Es la representación grafica de un conjunto de elementos y sus
relaciones.
Se opto por el modelado de UML (Unified Modeling Language) debido a que es

el método de diseño más utilizado actualmente, que independientemente del lenguaje en
que se realizará la programación, es eficiente, eficaz y sobretodo comprensible para
cualquiera que tenga los conocimientos básicos de una interpretación adecuada de un
caso a otro[5].

3 PLA(IFICACIO( DEL PROYECTO
3.1 PLA(IFICACIÓ(
En este capítulo se presentará el proceso planificación del proyecto a ejecutar. Para

realizar la planificación se utilizaran las siguientes herramientas:
• EDT (Estructuras de Desglose de Trabajo), para la representación grafica de esta

se utilizará el formato de árbol.
• OBS (Estructuras de desglose de la Organización), herramienta que representa
las entidades que participarán en el desarrollo del proyecto.
• Matriz de Responsabilidades, es el resultado del cruce entre la EDT y la OBS.
• Diagrama Gantt.
• Diagrama Pert.
3.1.1 Especificación de Tareas

A continuación se realiza una especificación de tareas junto con sus responsables y
recursos, se muestra la tabla 1.
(umero 1.1.1
(ombre EDT
Descripción Creación de una EDT, Estructura de Desglose de Trabajo, el cual
permita la especificación del alcance del proyecto y sirva de base
para la planificación de éste.
Esfuerzo Estimado 2 Día/ Hombre
Personas Jefe de Proyecto
Recursos 1 PC Desarrollo
Duración 2 Día
Entregables EDT
Predecesoras
Tabla 1 Especificación tarea EDT
(umero 1.1.3
(ombre OBS
Descripción Crear la Estructura de Desglose de Organización la cual permita
generar la matriz de responsabilidades.
Personas Jefe de Proyecto
Duración 2 Día
Entregables OBS
Predecesoras 1.1.1 (D. Obligatoria)
Tabla 2 EDT OBS

(umero 1.1.4
(ombre Matriz de Responsabilidades
Descripción Obtener el cruce entre la OBS y la EDT para generar el listado de
responsables por tarea.
Personas Jefe Proyecto
Duración 1 Día
Entregables Tabla Matriz de Responsabilidades
Predecesoras 1.1.1(D. Obligatoria); 1.1.3 (D. Obligatoria);
Tabla 3 EDT Matriz de Responsabilidades
(umero 1.1.2
(ombre Definición de Entregables
Descripción Especificar los Hitos y sus entregables por tarea.
Duración 1 Día
Entregables Especificación de tareas completa
Tabla 4 EDT Definición de Entregables
(umero 1.2.1
(ombre Diagrama Gantt
Descripción Se especificará el programa del proyecto mediante una
herramienta gráfica como es el Diagrama Gantt.
Duración 1 Día
Entregables Carta Gantt
Tabla 5 EDT Definición de Diagrama Gantt
(umero 1.2.2
(ombre Diagrama Pert
Descripción Se utilizará la esta herramienta para generar caminos críticos de
del desarrollo
Personas Jefe de proyecto
Duración 1 Día
Entregables Diagramas Pert
Tabla 6 EDT Definición de Diagrama Gantt
(umero 1.3.1

(ombre Definición de riesgos
Descripción Identificación y Análisis de Riesgos
Duración 2 Día
Entregables Matriz de definición de riesgos
Tabla 7 EDT Definición de riesgos
(umero 1.3.2
(ombre Definición de planes de mitigación y planes de contingencia
Descripción Identificación y Análisis de Riesgos
Duración 1 Día
Entregables Matriz de definición de riesgos
Tabla 8 EDT Definición de planes de mitigación y planes de contingencia
(umero 1.3
(ombre Plan de Riesgos
Descripción Identificación y Análisis de Riesgos, junto con la creación de
plan de mitigación y contingencia
Duración 2 Día
Entregables Análisis de Riesgos
Tabla 9 EDT Identificación y Análisis de Riesgos
(umero 2.1.1
(ombre Requerimientos Funcionales.
Descripción Se realizará 2 reuniones con el cliente para identificar los
requerimientos funcionales del sistema.
Personas Analista-Funcional, Consultor Cliente
Recursos Sala de reuniones
Duración 2 Días
Entregables Informe de identificación de requerimientos funcionales
Predecesoras 1.3 (D. Obligatoria)
Tabla 10 EDT Requerimientos Funcionales
(umero 2.1.2

(ombre Requerimientos no funcionales.
Descripción Se realizara 2 reuniones de trabajo, con el equipo interno, a fin de
determinar los requerimientos no funcionales del proyecto.
Personas Jefe de Proyecto, Analista-Funcional
Recursos Sala de reuniones
Duración 2 Días
Entregables Informe de identificación de requerimientos no funcionales.
Tabla 11 EDT Requerimientos no Funcionales
(umero 2.1.3
(ombre Especificación Formal
Descripción Se debe construir una especificación formal de requerimientos
mediante la utilización de casos de usos.
Personas Analista-Funcional
Duración 4 Días
Entregables Especificación Formal Usando Casos de Uso
Tabla 12 EDT Requerimientos no Funcionales
(umero 2.2.1
(ombre Definición de Componentes
Descripción Construcción y especificación de la disposición de los elementos
estructurales que componen el sistema, en cuanto a su ubicación
lógica.
Personas Arquitecto
Duración 2 Días
Entregables Diagrama de Componentes del Sistema
Tabla 13 EDT Definición de Componentes
(umero 3.1.1
(ombre Definición Diagrama de Clases
Descripción Construcción guiado por los casos de uso del diagrama de clases
del aplicativo
Duración 3 Días
Entregables Diagrama de Clases
Tabla 14 EDT Definición Diagrama de Clases
(umero 3.2.1

(ombre Definición Diagrama de Secuencia
Descripción Se realizará un diagrama de Interacción, específicamente de
secuencia para representar la colaboración de clases y sus
respectivos métodos.
Duración 3 Días
Entregables Diagramas de Secuencia.
Tabla 15 EDT Definición Diagrama de Secuencia
(umero 3.2.2
(ombre Definición Diagrama de Actividades
Descripción Se realizará un diagrama actividades, a fin de definir el
comportamiento de los casos de uso del sistema.
Duración 2 Días
Entregables Diagrama de Actividades
Tabla 16 EDT Definición Diagrama de Actividades
(umero 3.3.1
(ombre Definición modelo Conceptual
Descripción Diseño del modelo Conceptual del sistema en base al diagrama
de clases
Duración 3 Días
Entregables Modelo Conceptual
Tabla 17 EDT Definición modelo Conceptual
(umero 3.3.2
(ombre Definición modelo entidad relación
Descripción Se genera el modelo entidad relación del aplicativo la posterior
generación de la base de datos
Duración 3 Días
Entregables Modelo Entidad Relación
Tabla 18 EDT Definición modelo entidad relación

(umero 3.4.1
(ombre Diseño Servicios.
Descripción Modelar los servicios que tendrá el sistema a desarrollar, para
realizar esto se utilizará una extensión de UML denominada
WSLD.
Personas Analista-Funcional.
Duración 5 Días
Entregables Diagramas WSLD.
Tabla 19 EDT Diseño Servicios.
(umero 4.1.1
(ombre Implementación base de datos lógica
Descripción Se construirá y codificará la base de datos lógica del sistema
Personas Analista-Programador1
Recursos Servidor Base de Datos , 1 PC Desarrollo
Duración 3 Días
Entregables Base de Datos lógica.
Tabla 20 EDT Implementación base de datos lógica
(umero 4.1.2
(ombre Implementación base de datos física.
Descripción Se construirá y codificará la base de datos fisica del sistema
Recursos Servidor Base de Datos , 1 PC Desarrollo
Duración 2 Días
Entregables Base de Datos fisica.
Tabla 21 EDT Implementación base de datos física.
(umero 4.2.1
(ombre Implementación de Servicios Web según modelos WSDL
Descripción Se construirá los Servicios Web del aplicativo
Personas Analista/Programador2
Recursos Servidor Base de Datos, Servidor Web, 1 PC Desarrollo
Duración 15 Días
Entregables Listado Servicios Web, código fuente de estos.
Tabla 22 EDT Implementación de Servicios Web según modelos WSDL

(umero 4.3.1
(ombre Generación estilos capa de presentación
Descripción Se las planillas de estilo de las páginas web del aplicativo.
Duración 3 Días
Entregables Plantillas de estilos en formato css.
Predecesoras 4.1.2 (D. Obligatoria); 4.2.1 (D. Obligatoria)
Tabla 23 EDT Generación estilos capa de presentación
(umero 4.3.2
(ombre Generación interfaces web del aplicativo
Descripción Se construyen las páginas web del aplicativo.
Duración 12 Días
Entregables Plantillas de estilos en formato CSS.
Tabla 24 EDT Generación interfaces web del aplicativo
(umero 5.1.1
(ombre Ejecución pruebas sobre Base de datos
Descripción Se llevará a pruebas sobre la base de datos generada.
Personas Equipo-QA
Duración 1 Días
Entregables Informe de resultados de las pruebas sobre la base de datos
Tabla 25 EDT Ejecución pruebas sobre Base de datos
(umero 5.1.2
(ombre Ejecución pruebas sobre Base de datos
Descripción Se llevará a pruebas sobre la base de datos generada.
Personas Equipo-QA
Duración 1 Días
Entregables Informe de resultados de las pruebas sobre la base de datos
Tabla 26 EDT Ejecución pruebas sobre Base de datos

(umero 5.1.3
(ombre Ejecución de pruebas sobre Capa Presentación
Descripción Se llevará a pruebas sobre la base las páginas web desarrolladas
servicios web desarrollados.
Personas Equipo-QA
Duración 2 Días
Entregables Informe de resultados de las pruebas sobre las páginas web.
Tabla 27 EDT Ejecución de pruebas sobre Capa Presentación
(umero 5.2.1
(ombre Pruebas Integración
Descripción Se realizaran las pruebas de integración del aplicativo con el
sistema de Emisión de Pólizas Web.
Personas Equipo-QA
Recursos Servidor Base de Datos, Servidor Web, 1 PC Desarrollo, módulos
Perfiles, Emisión Web de pólizas
Duración 4 Días
Entregables Informe de resultado de pruebas.
Tabla 28 EDT Pruebas Integración
(umero 5.2.2
(ombre Pruebas Aceptación
Descripción Se realizaran pruebas por parte del cliente para obtener los
comentarios del cliente.
Personas Consultor-Cliente
Recursos Servidor Base de Datos, Servidor Web, 1 PC Desarrollo, módulos
Perfiles, Emisión Web de pólizas
Duración 2 Días
Entregables Informe de resultado de pruebas.
Tabla 29 EDT Pruebas Aceptación
(umero 6.1.1
(ombre Correcciones Base de datos.
Descripción Se realizarán las correcciones correspondientes a la base de datos,
las cuales fueron detectadas en la fase de pruebas del sistema
Duración 2 Días
Entregables Informe de correcciones sobre base de datos
Tabla 30 EDT Correcciones Base de datos.

(umero 6.1.2
(ombre Correcciones servicios Web
Descripción Se realizarán las correcciones correspondientes los servicios web,
Duración 3 Días
Entregables Informe de correciones sobre los servicios Web
Tabla 31 EDT Correcciones servicios Web
(umero 6.1.3
(ombre Correcciones capa de presentación
Descripción Se realizarán las correcciones correspondientes a las base de datos,
Duración 3 Días
Entregables Informe de correcciones sobre las páginas web del aplicativo
Tabla 32 EDT Correcciones capa de presentación
(umero 6.1.4
(ombre Actualización Documentación
Descripción Se actualizarán los documentos de Diseño según las nuevas
modificaciones.
Duración 2 Días
Entregables Documentos Actualizados
Predecesoras 6.1.1 (D. Obligatoria); 6.1.2 (D. Obligatoria); 6.1.3 (D.
Obligatoria)
Tabla 33 EDT Implementación de Servicios Web según modelos WSDL

3.1.2 Definición de Hitos
Hitos Externos Fecha

Entrega de Carta Gantt 08/09/09
Entrega especificación de Casos de Uso. 29/09/09
Entrega Informe de diseño 27/10/09
Entrega Aplicativo 24/12/09
Tabla 34 Hitos Externos
Hitos Internos Fecha

Entrega diagrama Pert 11/09/09
Entrega Documento Plan de Pruebas 29/10/09
Implementación en ambiente de testing 27/11/09
Entrega resultado de pruebas 09/12/09
Tabla 35 Hitos Internos
3.1.3 Diagrama OBS
Figura 2 Diagrama OBS

3.1.4 Diagrama EDT
Figura 3 Diagrama Estructura de Desglose de Trabajo

3.1.5 Carta Gantt
Figura 4 Carta Gantt

Figura 5 Carga Gantt (continuación)

3.1.6 Matriz de Responsabilidades
A continuación se presenta la matriz de responsabilidades resultante del cruce entre las EDT y la OBS.
Figura 6 Matriz de Responsabilidades.

Figura 7 Matriz de Responsabilidades (continuación)
.





3.1.7 Reporte con precedencias y duración de actividades.
Planificación optimista.
Figura 12 Diagrama Gantt Optimista

Figura 13 Diagrama Gantt Optimista (continuación )

Panificación esperada
Figura 14 Diagrama Gantt Esperada.

Figura 15 Diagrama Gantt Esperado (continuación)

Planificación Pesimista
Figura 16 Diagrama Gantt Pesimista

Figura 17 Diagrama Gantt Pesimista (continuación)

Figura 18 Diagrama Calculo de Fechas

Figura 19 Diagrama Camino Critico
3.1.8 Diagrama uso de Recursos
Figura 20 Diagrama Uso de Recurso

3.2 GESTIÓ( DEL RIESGO
En el siguiente capítulo se presentara proceso de administración de riesgos asociados a

la implementación del aplicativo se define administración de riesgos como:
La Administración de Riesgos es el conjunto de acciones específicamente

ejecutadas para reducir las posibilidades de que algo vaya mal durante el
Proyecto, identificando y moderando los riesgos que aparecen durante todo el ciclo
de vida del Proyecto[2].
El plan de administración de riesgo busca identificar cuáles son las amenazas que
enfrenta el proyecto a fin de mitigarlos, para cumplir con este objetivo se dividirá en las
siguientes tareas:
• Identificar los riesgos.

• Analizar los riesgos.
• Priorizar los riesgos.
• Planificar los riesgos.
• Definir estrategia de resolución de los riesgos (planes de mitigación o planes de
contingencia).
• Monitorear los riesgos identificados.
El plan de administración de riesgos debe ser actualizado cuando los riesgos o

estrategias de mitigación cambien. El responsable de dicha tarea corresponde a la
unidad de gestión definida en la OBS en este caso especifico esta responsabilidad recae
en el Jefe de Proyecto, el cual debe estar permanentemente monitoreando el estado del
proyecto, y lo posibles riesgos que se presenten, para ejecutar el plan de mitigación o
contingencia según sea el caso.
3.2.1 Identificación de riesgos

Se utilizara la siguiente tabla para representar la identificación de los riesgos
Condición Consecuencia
La causa del riesgo Efecto del riesgo
Tabla 36 Plantilla Identificación de riesgos

Condición Consecuencia
Falta de dominio del negocio por parte del La aplicación a entregar no cumplirá con los
analista-funcional requerimientos del usuario
Control de fuentes se realiza de forma local en Perdida de codificación, dificultad de manejar
el Pc del analista-programador versiones de entrega.
El equipo de desarrollo es también el Sobrecarga de trabajo del equipo de
encargado de entregar soporte a las desarrollo.
aplicaciones que están en explotación
El Jefe de Proyectos se encuentra destinado Falta de rigurosidad en la gestión del proyecto
media jornada al proyecto.
El equipo de desarrollo no posee experiencia Problemas en la comunicación del equipo de
trabajando juntos. trabajo
Error en estimación de plazos del proyecto Sobrecarga del trabajo del equipo del
proyecto..
El conocimiento técnico del equipo de Producto a entregar con defectos.
desarrollo es pobre.
Equipo de QA sin disponibilidad de horas- Atraso en realización de pruebas y entrega de
hombre sus resultados.
No renovación del contrato de desarrollo con Se cancela el proyecto.
el cliente
Tabla 37 Identificación de Riesgos
3.2.2 Análisis de riesgos
Para la realización del impacto de riesgos estos se clasificaran según su severidad y

posteriormente según su probabilidad de ocurrencia.
3.2.3 Severidad del riesgo

La severidad del riesgo será divida en 3 categorías, estas serán de tipo cualitativo y se
les asignará un valor cuantitativo:
• Leve: Su influencia afecta a varias tareas que no son críticas para el desarrollo
del sistema o a una tarea crítica para el desarrollo exitoso del proyecto. El valor
cuantitativo a utilizar para esta categoría será 1.
• Media: Su influencia afecta el apego del desarrollo a la planificación
provocando demoras importantes en él. El valor cuantitativo a utilizar para esta
categoría es 2.
• Grave: aparición hace imposible la entrega del proyecto cumpliendo con todos
los requerimientos el usuario. El valor cuantitativo a utilizar para esta categoría
es 3.
3.2.4 Probabilidad de Ocurrencia

La probabilidad de ocurrencia del riesgo será divida en 3 categorías estas son:

Baja: Va desde un 0 a un 30% de probabilidad de ocurrencia. Se asignará un de 1 para
la determinar la exposición del riesgo.
Media: Intervalo entre un 31% y 70% de ocurrencia. Se asignara un valor 2 para
determinar la exposición del riesgo.
Alta: Intervalo entre un 71% y 100% de ocurrencia. Se asignara un valor 3 para
determinar la exposición del riesgo.
3.2.5 Exposición del riesgo

Para medir la exposición del riesgo se utilizara la siguiente fórmula:
• (Probabilidad) * (Impacto) = Exposición
En la siguiente tabla se mostrara el cruce de los puntos 4.1 al 4.5 para generar la
priorización de los riesgos
Id Descripción Probabilidad Severidad Exposición

de del al
Ocurrencia riesgo riesgo
Falta de rigurosidad en la gestión del
proyecto pues el jefe se proyecto se
1 encuentra destinado solo media jornada al 3 3 9
proyecto.
El equipo del proyecto tiene sobrecarga de

trabajo por errores en la estimación de los
2 3 2 6
plazos del proyecto
El aplicativo a entregar no cumple

cabalmente con los requerimiento del
3 usuario debido a la falta de dominio del 2 3 6
negocio por parte del analista-funcional
Sobrecarga del trabajo del equipo de

4 desarrollo ante la llegada de una solicitud 2 2 4
de soporte de productivo de prioridad 1.
La etapa de codificación se atrasa en
plazos estipulados, desplazando las
5 fechas de las tareas de pruebas, quedando 2 2 4
sin disponibilidad de H/H por parte del
grupo de QA.
Pérdida de código fuente del proyecto
debido a que el control de fuentes se
6 1 3 3
realiza de forma local en el Pc del
analista-programador
Producto entregable defectuoso debido a
7 que el conocimiento técnico del equipo de 1 3 3
desarrollo es pobre.
Se cancela el proyecto por la no 1 3 3
8 renovación del contrato de desarrollo con
el cliente.

Problemas de comunicación y
convivencia entre el equipo de desarrollo
9 1 2 2
pues no existe de trabajos anteriores
juntos.
Tabla 38 Exposición al Riesgo
3.2.6 Planes de mitigación y planes de contingencia
En base a los riegos identificados se elaboran planes de mitigación, para evitar la

concertación del riesgo. Los planes de contingencia tienen como objetivo enfrentar el
riesgo una vez que este se vuelve real. En la siguiente tabla se muestran los planes de
contingencia.
Id Probabilidad Severidad Exposición Plan de Mitigación Plan de Contingencia

Riesgo de del al
Ocurrencia Riesgo Riesgo
La carga de trabajo para
El jefe de proyectos será
con otros proyectos del
1 Alta Grave 9 destinado 100% al
Jefe de proyecto será
proyecto
disminuida en un 70%
Reestructuración del la
carta Gantt asumiendo
Se realizará una revisión
por parte de la empresa
2 Alta Media 6 de la carta Gantt al final de
de desarrollo los costos
cada etapa.
de la extensión del
proyecto.
Se realizarán 2 sesiones de Se solicitará apoyo de
3 Media Grave 6 capacitación al analista- un consultor del área de
funcional. subscripción.
Los soportes serán Se utilizara horas
planificados antes o extraordinarias para
4 Media Media 4
después de la etapa de cumplir con soportes
codificación urgentes
El proceso de codificación Las pruebas serán
deberá terminar en la realizadas por el equipo
fecha indicada para que de desarrollo
5 Media Media 4
equipo de prueba pueda (certificación por pares)
ejecutar su tarea en los cada recurso testeará el
plazos estipulado desarrollo del otro.
Se dispondrá de un Implementación de un
6 Alta Leve 3 procedimiento de control software de control de
de fuentes diario. fuentes.
Antes de que comience la
Se reasignaran recursos
etapa de codificación se
7 Baja Grave 3 con mayor expetis
realizarán capacitaciones
técnico
para el grupo de desarrollo
El fin del proyecto debe
ser planificado antes de la
8 Baja Grave 3 No existe.
fecha de renovación de
contrato
9 Baja Media 2 Antes del comienzo del Reorganización del

proyecto el equipo de grupo de trabajo.
desarrollo deberá
desarrollar pequeñas
aplicaciones
Tabla 39 Planes de mitigación y contingencia
3.3 ESTUDIO DE FACTIBILIDAD
En el estudio de falibilidad se busca analizar las variables que influyen en la

puesta en marcha del proyecto y si existe todos las condiciones para que este se lleve a
cabo sin inconvenientes. Este estudio se divide en cuatro áreas de interés:
• Estudio de factibilidad técnica: La factibilidad técnica, consiste en

determinar si el problema tiene una solución susceptible de llevar a cabo
con los recursos computacionales y conocimientos técnicos que posee la
organización.
• Estudio de factibilidad económica: El estudio de factibilidad económica

tiene como objetivo determinar si se justifica, en términos de una relación
costo/beneficio, implementar el sistema de desarrollo informático.
• Estudio de factibilidad operacional: Consiste en determinar la capacidad

potencial de la organización para llevar a cabo el proyecto en términos de
los planes, políticas y procedimientos vigentes, es decir, a que se expone la
organización al incorporar un nuevo sistema.
• Estudio de factibilidad legal: El estudio de la factibilidad legal tiene

como objetivo verificar si el sistema a desarrollar no vulnera las leyes ni
decretos vigentes.
3.3.1 Factibilidad Técnica

En esta etapa se definirán los requerimientos mínimos para el desarrollo del proyecto.
Estos son extraídos de las especificaciones del fabricante.
Software Hardware
Licencia para el desarrollo de software con la Procesador: Equipo con procesador a 600
herramienta Microsoft Visual Studio .NET, MHz o CPU compatible con Intel Pentium de
versión 2003 velocidad superior
Memoria: 160 megabytes (MB) de RAM
Disco duro: 3.3 gigabytes (GB) de espacio
disponible en disco duro

Sql Server 2000 Enterprise Edition Procesador: Equipo con procesador a 450
MHz o CPU compatible con Intel Pentium de
velocidad superior
Memoria: 512 megabytes (MB) de RAM
Disco duro: 6 gigabytes (GB) de espacio
disponible en disco duro
Windows 2003 Server Enterprice Edition Procesador : Pentium a 133 megahercios

(MHz) o mayor velocidad (se recomienda 550
MHz)
Memoria : 128 megabytes (MB) de RAM (se
recomienda 256 MB)
Disco duro : 4 gigabytes (GB) de espacio
disponible en el disco duro
Iseries Maquina: AS/400 Modelo 9402 720 VSR1
Procesador: 206C
Memoria: 1384 MB
Disco Duro: 180 GB
Unidad de resplado 6390 1/4 20 GB
Tabla 40 Estudio factibilidad técnica
3.3.2 Arquitectura aplicación
Figura 21 Arquitectura de la aplicación

3.3.3 Estudio Factibilidad Económica.
La factibilidad económica del proyecto presente está garantizada pues los costos
del desarrollo se enmarca en el contrato de firmado entre la empresa Sigma S.A.
(proveedora ) y RSA (cliente) este contrato tiene una duración de 3 años y en el cual se
especifica que RSA tiene una cantidad de horas de desarrollo mensualmente. Dichas
horas deben ser utilizada en su totalidad, en caso contrario el cliente debe asumir los
costos, pues el cobro por estas horas es un costo fijo mensual.
3.3.4 Estudio Factibilidad Operacional.

Por normativa del cliente RSA, una vez que esta aplicación este en marcha las
cotizaciones realizadas por esta herramienta serán validas, para ser posteriormente
transformadas en pólizas de vehículos. Bajo esta premisa el cliente implementara un
Call-Center para la captación de cliente utilizando esta aplicación. Además el atractivo
para los corredores de la compañía de seguro, es la baja de los costos en el contacto de
nuevos clientes y obtener información. Estos antecedentes aseguran la explotación del
aplicativo.
3.3.5 Estudio Factibilidad Legal.
El desarrollo exige la tenencia de licencias de software para el desarrollo y explotación,

dichas licencias ya son de propiedad de la empresa de desarrollo y del cliente. Cabe
mencionar que esta es otra aplicación la cual formará parte de la gama de aplicaciones
del cliente, desarrollados con las herramientas mencionadas en los requerimientos no
funcionales. Por lo tanto si nos remitimos a estos requerimientos en el aspecto legal el
proyecto es viable.

4 A(ÁLISIS Y DISEÑO DEL PROYECTO
4.1 ESPECIFICACIÓ( DE REQUERIMIE(TOS
Los requerimientos representan las necesidades que se deben satisfacer para

lograr que el producto del desarrollo sea la solución más adecuada para el problema. El
objetivo es captar de forma explícita y concisa, cuales son estas necesidades con el fin
de centrar los esfuerzos del equipo de trabajo en lograr satisfacerlas. Estos
requerimientos se obtienen, principalmente, mediante reuniones con el cliente. Además
en este caso particular existen los documentos de requerimientos que son generados por
el cliente. Los cuales son básicamente una explicación narrativa de lo que este necesita
el cliente.
Requerimientos funcionales: Describen los servicios que se espera que el sistema

proveerá. Declaran la manera en que el sistema reaccionará a entradas particulares y el
cómo se comportara en situaciones particulares. A veces especifican incluso lo que el
sistema no debe hacer.
Requerimientos no funcionales: Describen las restricciones bajo las cuales el sistema

debe operar. Se refieren a las propiedades emergentes del producto, como la fiabilidad,
la respuesta en el tiempo, la capacidad de almacenamiento, etc. Generalmente son más
críticos que los requerimientos funcionales particulares. El incumplimiento de un
requerimiento funcional degradará el sistema, mientras que una falla en un
requerimiento no funcional lo inutiliza.
4.1.1 Requerimientos Funcionales
• Permitir realizar una cotización de un seguro automotriz de uno hasta 3

vehículos para un plan y sus coberturas seleccionadas.
• Para permitir la cotización se deben validar la información comercial del

proponente.
• Validar la siniestralidad del asegurado.
• Generar una interfaz que permita a un usuario con rol Administrador obtener
información acerca de las cotizaciones realizadas por los diferentes corredores.
• Generación de un archivo PDF que represente la cotización realizada.
• Se debe permitir el envió vía correo de la cotización en formato PDF.
• Se debe proveer un control de acceso al aplicativo.
• La aplicación debe manejar perfiles de usuario para restringir el uso de los

módulos del aplicativo.

• Los valores monetarios de la cotización serán en UF.
• Permitir la asignación de glosas genéricas para cada uno de los planes

configurados en el aplicativo.
• Incorporar recargos o descuentos por antigüedad del vehículo cotizado.
• Tener información sobre las acciones que cada usuario ha realizado con la
herramienta.
• Se debe validar la morosidad del cliente en la base de datos de la aseguradora.
• La cotización debe incluir el recargo por concepto de siniestralidad del

asegurado.
• Los códigos que se manejen en el modelo Web para Modelos-Marcas y Planes

Técnicos deben ser idénticos a los existentes en el Sistema de Productos.
• La cotización debe incluir el recargo según la información comercial del

proponente.
• Se debe permitir al corredor realizar recargos o descuentos según lo asignado

por la aseguradora.
• La información sobre el asegurado y/o proponente debe ser obtenida desde el

maestro de persona de la compañía aseguradora, de lo contrario, para el éxito de
la cotización se debe permitir su ingreso.
• La información referente a Coberturas y valores por Planes Técnicos será

obtenida directamente desde el Sistema de Productos de la compañía
aseguradora.
4.1.2 Requerimientos no funcionales
• El proyecto deberá ser desarrollado bajo una arquitectura Web.
• Para el desarrollo se deberá utilizar como lenguaje de programación Microsoft

Visual Studio .NET, versión 2003
• Se utilizará 2 motores de base de datos: SQL Server 2000 y AS/400 utilizando

Iseries.
• El servidor Web que soportara la aplicación deberá ser IIS versión 6.
• Para la construcción del Software se utilizarán 3 ambientes Desarrollo, Testing y

Producción los cuales son proveídos por el cliente.

• El acceso a los Datos en el Módulo Cotizador deberá implementarse mediante
Web Services.
• Cada tabla involucrada en el funcionamiento del aplicativo tendrá 4 campos de

auditoría estos son fecha, hora, usuario y modulo del aplicativo.
• Cada WS contará con validación de usuario y contraseña. Los cuales estarán

encriptados con MD5 en la base de datos.
4.1.3 Casos de Uso
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple

para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de
Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo
los usuarios desean que funcione. No es realmente una aproximación a la orientación a
objetos; es realmente una forma de modelar los requerimientos. Es, sin embargo, una
manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los
casos de uso son generalmente el punto de partida del análisis orientado a objetos con
UML.
El modelo de casos de uso se compone de actores y casos de uso. Los actores

representan usuarios y otros sistemas que interaccionan con el sistema. Se dibujan como
"muñecos" de palo. Actualmente representan el tipo de usuario, no una instancia de
usuario.
4.1.4 Actores
El sistema, según lo descrito a través de los requerimientos planteados, está

orientado a 2 clases distintas de usuarios, quienes cumplen diferentes roles en el
sistema, ya sea consultándolo, explotándolo o administrándolo. En las siguientes líneas
se explica el perfil y participación de cada uno de estos actores frente a la aplicación:
• Usuario Sistema: Corresponde a individuos que poseen atributos dentro del

sistema para realizar cotizaciones, imprimirlas y enviar vía email un archivo
PDF de está.
• Usuario Administrador: Este perfil de usuario en el sistema posee privilegios

que le permiten realizar cotizaciones, crear usuarios del sistema, crear y
configurar planes y asignar planes a los distintos corredores que utilizaran la
aplicación, permitiéndosele realizar consultas al sistema y eventualmente
modificar su información personal.

4.1.5 Diagrama de Casos de Uso
4.1.5.1 Caso de uso General Sistema
Figura 22 Modelo de Casos de Generar Cotización

4.1.5.2 Caso de uso Generar Cotización
Figura 23 Modelo de Casos de Generar Cotización

4.1.5.3 Caso de uso Asociar Planes
Figura 24 Asociar Plan Comercial
4.1.6 Casos de Uso (arrativo

Se presenta una descripción narrativa de cada caso de uso en la tabla 41 se muestra la
descripción narrativa del caso de uso Generar Cotización.
Caso de Uso Generar Cotización

Actores Usuario Sistema(iniciador)
Tipo Principal
Descripción Un usuario ingresa a la aplicación, entrega información del proponente,
selecciona un plan comercial, ingresa información del asegurado,
ingresa información de uno o hasta tres vehículos, ingresa descuentos
u/o recargos, selecciona coberturas adicionales y guarda la cotización.
Una vez guardada se genera el archivo PDF de la cotización y puede
realizar el envío de este vía correo electrónico.
Referencias Casos de Uso: Ingresar Proponente, Seleccionar Plan, Ingresar
Cruzadas Asegurado, Ingresar Vehículos, Generar archivo PDF Cotización.
Tabla 41 Descripción narrativa caso de uso Generar Cotización.

Caso de Uso Ver Cotizaciones Realizadas
Tipo Principal
Descripción El usuario selecciona un rango de fechas y ejecuta la búsqueda, el
sistema entrega una tabla con todas las cotizaciones realizadas en el
rango de búsqueda realizada.
Referencias Casos de Uso: Generar archivo PDF Cotización.
Cruzadas
Tabla 42 Descripción Ver Cotizaciones Realizadas.
Caso de Uso Administrar Planes

Actores Usuario Administrador (iniciador)
Tipo Principal
Descripción El usuario puede modificar los planes comerciales, eliminar
asociaciones entre planes y corredores, agregar, eliminar y modificar
glosas adicionales a los planes.
Referencias El usuario debe haber realizado el caso de uso Asociar Planes.
Cruzadas
Tabla 43 Administrar Planes
Caso de Uso Administrar Usuarios.

Actores Usuario Administrador (iniciador)
Tipo Principal
Descripción El usuario crea, modifica y elimina los usuarios del sistema.
Referencias
Cruzadas
Caso de Uso Ingresar Proponente.
Tipo Principal
Descripción El usuario ingresa el Rut del proponente, en caso de no existir en el
maestro de personas, el usuario debe ingresar los nombres y apellidos
de los proponentes. Se valida la información comercial del proponente.
Referencias Casos de usos: Validar información Comercial, Obtener datos
Cruzadas Proponente.
Tabla 44 Descripción Administrar Usuarios.
Caso de Uso Ingresar Asegurado.

Tipo Principal
Descripción El usuario ingresa el Rut del asegurado, en caso de no existir en el
maestro de personas, el usuario debe ingresar los nombres y apellidos
de los proponentes. Se valida la información de siniestralidad del
asegurado ingresado.
Referencias Casos de usos: Validar Información Siniestralidad, Obtener datos
Cruzadas Proponente.
Tabla 45 Descripción Ingresar Asegurado.

Caso de Uso Ingresar Vehículos.
Tipo Principal
Descripción El usuario selecciona la marca y el modelo del vehículo e ingresa el
año del vehículo.
Referencias Casos de usos: Obtener Marcas / Modelos.
Cruzadas
Tabla 46 Descripción Ingresar Vehículos.
Caso de Uso Generar Archivo PDF Cotización.

Tipo Principal
Descripción El usuario solicita al sistema la generación del archivo PDF de la
cotización ingresada.
Referencias Casos de usos: Obtener Marcas / Modelos.
Cruzadas
Tabla 47 Descripción Generar Archivo PDF Cotización.
Caso de Uso Generar Archivo PDF Cotización.

Tipo Opcional
Descripción El usuario solicita al sistema la generación del archivo PDF de la
cotización ingresada.
Referencias Casos de usos: Se debe ejecutar primero el caso de uso Guardar
Cruzadas Cotización.
Caso de Uso Imprimir PDF Cotización.
Tipo Opcional
Descripción El usuario selecciona la opción de imprimir el archivo PFD de la
cotización.
Referencias Casos de usos: El caso de uso Generar Archivo PDF Cotización debe
Cruzadas ser ejecutado previamente.
Tabla 48 Descripción Generar Archivo PDF Cotización.
Caso de Uso Enviar PDF Cotización vía Email.

Tipo Opcional
Descripción El usuario selecciona la opción enviar vía correo electrónico el PFD de
la cotización, ingresa el correo del receptor y solicita al sistema el
envío del archivo.
Referencias Casos de usos: El caso de uso Generar Archivo PDF Cotización debe
Cruzadas ser ejecutado previamente.
Tabla 49 Descripción Enviar PDF Cotización vía Email.

Caso de Uso Obtener Marcas / Modelos.
Actores Usuario Sistema(iniciador), Sistema de Vehiculos
Tipo Secundario
Descripción Desde el caso de uso ingresar vehículos se dispara la solicitud para
obtener las marcas y modelos de los vehículos desde el sistema de
vehículos. Se obtiene la información de las marcas con sus respectivos
modelos y es devuelta al caso de uso que realizo la solicitud.
Referencias Casos de usos: Se debe ejecutar el caso de uso Ingresar Vehículo.
Cruzadas
Tabla 50 Descripción Obtener Marcas / Modelos.
Caso de Uso Validar Información Siniestralidad

Actores Usuario Sistema(iniciador), Sistema Información Siniestralidad
Tipo Secundario
Descripción Desde el caso de uso ingresar asegurado se dispara la solicitud para
validar la siniestralidad del asegurado, se consulta si el Rut ingresado
para el asegurado registra siniestros, esta información la entrega el
Sistema SISGEN, en caso de existir siniestros se devuelve la cantidad
de estos. En caso que la cantidad de siniestros sea mayor al ingresado
como tope para el plan se informa que no puede el asegurado tomar el
seguro.
Referencias Casos de usos: Se debe ejecutar el caso de uso Ingresar Asegurado.
Cruzadas
Tabla 51 Descripción Validar Información Siniestralidad
Caso de Uso Validar Información Comercial

Actores Usuario Sistema(iniciador), Sistema Información Comercial
Tipo Secundario
Descripción Desde el caso de uso Ingresar Proponente se dispara la solicitud para
validar la información comercial del proponente, se consulta si el Rut
ingresado para el proponente registra deuda en el sistema comercial,
esta información la entrega el Boletín Comercial, en caso de existir
deuda se devuelve la cantidad en UF de esta. En caso que la deuda sea
mayor al ingresado como tope para el plan se informa que no puede el
Proponente tomar el seguro.
Referencias Casos de usos: Se debe ejecutar el caso de uso Ingresar Proponente.
Cruzadas
Tabla 52 Descripción Validar Información Comercial.
Caso de Uso Obtener Información Persona

Actores Usuario Sistema(iniciador), Sistema Personas
Tipo Secundario
Descripción Desde el caso de uso ingresar Asegurado o ingresar Proponente se
dispara la solicitud para obtener la información desde el Sistema de
Producto del rut ingresado, el sistema de personas responde con el
nombre y apellido del rut ingresado en caso que exista en éste.
Referencias Casos de usos: Ingresar Asegurado, Ingresar Proponente.
Cruzadas
Tabla 53 Descripción Obtener Información Persona.

Caso de Uso Guardar Cotización
Tipo Principal
Descripción El usuario ha ingresado la información correspondiente a la cotización,
se toman los datos ingresados y son cargados en la base de datos del
sistema.
Referencias Casos de usos: Se deben ejecutar previamente los casos de uso Ingresar
Cruzadas Asegurado, Ingresar Proponente y Seleccionar Plan Comercial
Tabla 54 Descripción Guardar Cotización
Caso de Uso Agregar Coberturas Adicionales

Tipo Opcional
Descripción El usuario ha seleccionado el plan comercial a cotizar y selecciona
coberturas adicionales de su preferencia.
Referencias Casos de usos: Se deben ejecutar previamente le caso de uso
Cruzadas Seleccionar Plan Comercial
Tabla 55 Descripción Agregar Coberturas Adicionales.
Caso de Uso Agregar Recargo / Descuento

Tipo Opcional
Descripción El usuario ha seleccionado el plan comercial a cotizar y aplica un
descuento u o recargo, este es un valor cuantitativo expresado en
porcentaje, el sistema calcula el valor del plan con el valor ingresado
aumentando el valor de este o disminuyendo, dependiendo si es un
descuento o recargo el agregado.
Referencias Casos de usos: Se deben ejecutar previamente le caso de uso
Cruzadas Seleccionar Plan Comercial
Tabla 56 Descripción Agregar Recargo / Descuento
Caso de Uso Seleccionar Plan Comercial

Tipo Principal
Descripción El usuario selecciona el plan comercial para el cual se realizará
cotización.
Referencias Casos de usos: Agregar Coberturas Adicionales
Cruzadas
Tabla 57 Descripción Seleccionar Plan Comercial.
Caso de Uso Seleccionar Plan Comercial

Tipo Principal
Descripción El usuario selecciona el plan comercial para el cual se realizará
cotización.
Referencias Casos de usos: Agregar Coberturas Adicionales
Cruzadas
Tabla 58 Descripción Seleccionar Plan Comercial.

Caso de Uso Activar Plan Comercial
Actores Usuario Administrador(iniciador)
Tipo Principal
Descripción El usuario selecciona un plan comercial y lo activa para que sea usado
por el Sistema de Cotización.
Referencias Casos de usos: Seleccionar Coberturas Adicionales, Obtener Planes
Cruzadas Comerciales
Tabla 59 Descripción Activar Plan Comercial.
Caso de Uso Seleccionar Corredor

Tipo Principal
Descripción El usuario selecciona los corredores que serán habilitados para utilizar
el plan comercial activado.
Referencias Casos de usos: Se debe haber ejecutado el caso de uso Activar Plan
Cruzadas Comercial.
Tabla 60 Descripción Seleccionar Corredor.
Caso de Uso Administrar Parámetros Plan Comercial

Tipo Principal
Descripción El usuario ingresa, modifica los parámetros del plan comercial estos
son prima minima, máxima cantidad siniestros y máxima deuda
comercial.
Cruzadas Comercial.
Tabla 61 Descripción Administrar Parámetros Plan Comercial.
Caso de Uso Obtener Planes Comerciales

Actores Usuario Administrador(iniciador), Sistema de Productos
Tipo Secundario
Descripción Desde el caso de uso Activar Plan Comercial se genera la solictitud
hacia el Sistema de Producto para que este provea los planes
comerciales disponibles. El Sistema de Producto devuelve los planes
comerciales vigentes.
Cruzadas Comercial.
Tabla 62 Descripción Obtener Planes Comerciales.
Caso de Uso Asociar Coberturas Adicionales

Tipo Secundario
Descripción El usuario selecciona las coberturas adicionales que quedaran asociadas
al plan comercial activado.
Cruzadas Comercial.
Tabla 63 Descripción Asociar Coberturas Adicionales.

Caso de Uso Obtener Coberturas Adicionales
Actores Usuario Administrador(iniciador), Sistema de Productos
Tipo Secundario
Descripción Desde el caso de uso Asociar Coberturas Adicionales se genera la
solictitud hacia el Sistema de Producto para que este provea las
coberturas adicionales disponibles. El Sistema de Producto devuelve
las coberturas adicionales disponibles.
Cruzadas Comercial.
Tabla 64 Descripción Obtener Coberturas Adicionales.

5 DISEÑO
5.1.1.1 Diagrama de Actividades Ingresar Proponente
Figura 25 Diagrama de Actividades Ingresar Proponente

5.1.1.2 Diagrama de Actividades Validar Información Comercial
Figura 26 Diagrama Actividades Validar Información Comercial
5.1.1.3 Diagrama de Actividades Ingresar Asegurado
Figura 27 Diagrama Actividades Ingresar Asegurado

5.1.1.4 Diagrama de Actividades Validar Información Siniestralidad
Figura 28 Diagrama Actividades Validar Información Siniestralidad

5.2 DIAGRAMA DE CLASES
Figura 29 Diagrama de Clases

5.3 DIAGRAMA DE SECUE(CIAS
5.3.1 Diagrama Secuencia Seleccionar Cobertura Adicional
Figura 30 Diagrama de Secuencia Seleccionar Cobertura Adicional
5.3.2 Diagrama Secuencia Obtener Planes Comerciales
Figura 31 Diagrama de Secuencia Obtener Planes Comerciales

5.3.3 Diagrama Secuencia Seleccionar Coberturas Adicionales
Figura 32 Diagrama de Secuencia Seleccionar Coberturas Adicionales

5.3.4 Diagrama Secuencia Generar PDF
Figura 33 Diagrama de Secuencia Seleccionar Coberturas Adicionales

5.3.5 Modelo Entidad Relación
Figura 34 Modelo Entidad Relación

5.4 DISEÑO DE I(TERFACES
En la presente sección se mostrará los prototipos de las interfaces que deberán ser
desarrolladas.
Prototipo para caso de uso “Ver Cotizaciones Realizadas”.
Figura 35 Prototipo ““Ver Cotizaciones Realizadas” , Interfaz Filtros
Figura 36 Prototipo ““Ver Cotizaciones Realizadas” Interfaz Resultado Búsqueda

Figura 37 Prototipo “Ver Cotizaciones Realizadas” Interfaz Detalle Cotización

Prototipo para caso de uso “Generar Cotización”.
Figura 38 Prototipo “Generar Cotización” Interfaz Paso 1
Figura 39 Prototipo “Generar Cotización” Interfaz Agregar Vehículo

Figura 40 Prototipo “Generar Cotización” Interfaz Paso 2
Figura 41Prototipo “Generar Cotización” Interfaz Paso 3

Figura 42 Prototipo “Generar Cotización” Interfaz Enviar PDF

6 PLA(ES DE PRUEBAS
Para verificar si el desarrollo del sistema va en el camino correcto es necesario

realizar pruebas las cuales nos entreguen un control por sobre lo que se está realizando.
Para llevar a cabo esto en forma ordenada se implementara un plan de pruebas.
Se han identificados 3 tipos de pruebas a implementar.
• Pruebas de Unidad: Para probar las interfaces y validar que su lógica trabaja
correctamente de acuerdo a las especificaciones. Se inician una vez que la
interfaz comienza su desarrollo.
• Pruebas de Integración: Se integran las interfaces en módulos y estos son

probados . Se inicia una vez que cada interfaz ha aprobado exitosamente las
pruebas de unidad.
• Pruebas del Sistema: Buscar verificar que el comportamiento del sistema

software satisface los requisitos establecidos por los clientes y futuros usuarios
del mismo.
6.1 PRUEBAS DE U(IDAD
Estas pruebas son los procedimientos de pruebas locales a un módulo del

sistema. Por definición dichas pruebas cubren la funcionalidad propia del módulo tanto
con una perspectiva de caja blanca como de caja negra, pero prestando poca o ninguna
atención a la integración con otros módulos.
Las pruebas unitarias buscan lograr lo siguiente:
• Asegura calidad del código entregado.
• Ayuda a definir los requerimientos y responsabilidades de cada modulo probado.
• Permitir hacer refactoring tempranamente en el código.
• Poder realizar hacer pruebas de estress tempranamente en el código.
• Encontrar errores o bugs tempranamente en el desarrollo
Este tipo de pruebas son predecesoras de las pruebas de integración.
6.2 PRUEBAS DE I(TEGRACIO(
La prueba de integración es una técnica sistemática para construir la

estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para

detectar errores asociados con la interacción. El objetivo es tomar los módulos
probados en unidad y estructurar un programa que esté de acuerdo con el que
dicta el diseño. Existen 2 métodos para ejecutar estas pruebas estos son :
Integración descendente, es una estrategia de integración incremental a

la construcción de la estructura de programas, en el cual se integran los
módulos moviéndose en dirección hacia abajo por la jerarquía comenzando por
el control principal (Programa principal). Los módulos subordinados de control
principal se incorporan en la estructura.
Integración ascendente, es donde la construcción del diseño empieza

desde los módulos más bajos hacia arriba (módulo principal), el procesamiento
requerido de los módulos subordinados siempre está disponible.
La sección de una estrategia de integración depende de las características
depende de las características del software y, a veces, del plan del proyecto, en
algunos de los casos se puede combinar ambas estrategias.
6.3 PRUEBAS DE SISTEMAS
La fase de pruebas del sistema tiene como objetivo verificar el sistema software
para comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse
varios tipos distintos de pruebas en función de los objetivos de las mismas. Algunos
tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas
de seguridad, etc. Este trabajo se centra en pruebas funcionales de aplicaciones con
interfaces gráficas. Estas pruebas verifican que el sistema software ofrece a los actores
humanos la funcionalidad recogida en su especificación.

6.4 PLA( DE PRUEBAS
Para la ejecución de los tipos de pruebas nombradas anteriormente se ejecutará el plan

de pruebas descrito en la siguiente tabla.
Elemento a Validar Casos a Probar
Formato de Campo de Ingreso Formato Correcto en Ingreso de Campos Numéricos
Formato Correcto en Ingreso de Campos de Rut
Formato Correcto en Ingreso de Campos de Fecha
Campos de Fecha Desde y Hasta
DV de Campos Rut Obtencion Automatica de Campos Rut
Campos de DV inhabilitados
Validacion en Botones de Accion Obligatoriedad de Campos al presionar "Buscar" una Cotizacion
Obligatoriedad de Campos al presionar "Buscar" Cotizacion
Sección Encabezado de Página Estilo general del Encabezado correcto
Contenido del Encabezado correcto
Ortografia Encabezado correcto
Alineacion Vertical y Horizontal correcto
Sección Pie de Página Estilos general del texto del pie correcto
Contenido del texto del pie correcto
Alineación Vertical y horizontal Correcto
Sección de Filtros: Alineacion de contenido de campos Ingresados según su Tipo
Alineacion Vertical y Horizontal de Campos en la Pagina
Alto y Largo homogeno de Campos en la Pagina
Texto de ejemplos para Campos Fecha, Rut y Monedas
Estilos de Label y Valores Correctos
Ortografia de Labels Correctos
Sección de Filtros seleccionados Alineacion Vertical y Horizontal de Campos en la Pagina
Alto y Largo de Campos de la seccion homogenos
Estilos de Label y Valores Correctos
Ortografia de Labels Correcta

Botones de Acción: Diseño y Formato Correcto

Posicion Horizontal de Botones Correcta
Separación Vertical con info de arriba y debajo Homogenea
Textos de botones según EF
Grilla de Resultados: Titulo: Ancho de Columnas Correcto
Titulo: Alto de fila Correcto
Titulo: Estilo de letras y colores Correctos
Titulo: Iconos Gráficos Correctos
Titulo: Orden de aparicion de columnas según EF
Resultado: Orden de aparicion de los valores de cada campo según EF
Resultado: Alineacion de valores según tipo de dato
Resultado: Formato de despliegue de valores según tipo de dato
Resultado: Estilos de columnas con Links correctos
Resultado: Color de fondo de filas correcto
Resultado: Alto de filas homogeneos
Resultado: Despliegue de Barra de desplazamiento horizontal si

corresponde
Resultado: Barra de desplazamiento vertical si corresponde
Paginación : Estilos de paginación Correcto
Paginación : Alineacion Vertical respecto a grilla correcto
Paginación : Alineacion horizontal correcto (centrado)
Sección de Mensajes de Error Iconos graficos según tipo de mensajes correcto
Estilos de textos de mensajes correcto
Posicion del Mensaje en la página correcta
Desplazamiento del texto dentro de cuadro de Mensaje corrrecto
Error Conexión a Base Datos Texto del mensaje Correcto
Estilo y formato del mensaje Correcto
Registro de Error en Base de Datos
Expiracion de tiempo de Sesion Texto del mensaje Correcto

NO existencia de SPs Texto del mensaje Correcto
NO existencia de parametro en
Texto del mensaje Correcto
Web.config
Funcionamiento Erroneo de
Texto del mensaje Correcto
Funcionalidad
Tabla 65 Plan de pruebas para Modulos o Interfaces
Elemento a Validar Casos a Probar
Obligatoriedad de Parámetros de
Validación Correcta de Parámetros de Entrada Obligatorios
Entrada
Validación Correcta de Parámetros de Entrada No Obligatorio
Formato de Parámetros de Entrada Formato Correcto en Parámetro de Entrada de Tipo Numéricos

Formato Correcto en Parámetro de Entrada de Tipo Rut
Formato Correcto en Parámetro de Entrada de Tipo Fecha
Formato Correcto en Parámetro de Entrada de Tipo Patente
Consistencia de Fechas Desde/Hasta en

Inconsistencia en valores de Parámetros de Fecha Desde y Hasta
Parámetros de Entrada
Validacion de parámetro de Tipo Patente Validar Patente Correcta
Listado de Campos de la Respuesta del

Listado de Campos de respuesta del Método Correcto
Método
Formato de los Campos de la Respuesta
Listado de todos los Campos de la respuesta del Método Correcto
del Método
Orden de la Respuesta del Método Orden de todos los Campos de la respuesta del Método Correcto
Estructura de la Respuesta del Método La estrucura de la respuesta del Método Correcto
Mensajes de Error devueltos por el

Mensaje de error Correcto para Obligatoriedad de Parámetro de Entrada
método
Mensaje de Error Correcto para Formato de Parámetro de Entrada
Mensaje de Error Correcto para Incosistencia de Fechas en Parámetro de

Entrada
Mensaje de error Correcto para Patentes Invalidas en Parámetro de Entrada
Tabla 66 Plan de Pruebas para Servicios Web.

7 CO(CLUSIÓ(ES
7.1 CO(CLUSIO(ES
Como queda plasmado en este documento que la planificación no es una ciencia

empírica si no que se rige por métodos y se basa en herramientas claras y definidas. Si
esta es realizada en forma ordenada y metódicamente se obtiene un producto robusto.
El uso de las Estructuras de desglose de trabajo, bien definidas, permiten la

construcción de la planificación de forma natural, es muy distinto abrir un documento
Proyect en blanco y tratar de plasmar en el las tareas a realizar, a tener estas tareas ya
definas, su duración y los recursos a utilizar.
Durante la etapa de análisis de riesgos se propuso como planes de mitigación algunas

actividades que no se encuentran en la planificación del proyecto. Esto es porque dichas
actividades no deberían impactar en el calendario de éste, además los costos asociados a
dichas actividades no deben ser transmitidos al cliente.
La utilización UML para el modelamiento del aplicativo, permitió que la

documentación generada sea de fácil comprensión, pues esta herramienta es de amplia
difusión y se ha convertido prácticamente en un estándar de modelamiento.
En cuanto a diseñar e implementar una aplicación capaz de obtener información

actualizada de seguros disponibles para cotizar, se logra a través de la implementación
procedimientos que permiten la interacción ( WebServices ) entre el la aplicación
desarrollada y el sistema de productos de la compañía RSA. Mediante estos
procedimientos de interacción mencionados se pone a disposición del usuario del
sistema información actualizada de cualquier cambio que tengan los seguros disponibles
en el sistema de productos.
Con respecto al desarrollo de Servicios Web que obtengan información referentes a

deudas comerciales y siniestralidad, se logró implementarlos dando un valor agregado al
producto a entregar, pues en el proceso para generar una cotización ,que existían
anterior a la implantación de este proyecto, para incluir estos factores se debía realizar
una consulta manual ( llamada telefónica a los Call-Center, respetivos, que disponen las
instituciones para entregar esta información), se podía incurrir en vicios por parte de la
fuerza de venta en manipular maliciosamente esta información, o simple y llanamente
era obviada.
La aplicación desarrollada cumple en generar un canal de transferencia de información

entre los actores e entidades involucrados en el proceso de cotización del un seguro
automotriz, pues ésta fue imprentada en una arquitectura web. La información que
utiliza el sistema es extraída directamente de los sistemas de productos, personas y
sistemas propietarios de terceros, que entregan información de siniestralidad y deuda
comercial. Permitiendo tener información actualizada en tiempo real.

La implementación utiliza para la interacción entre la capa de presentación y la capa de
datos WebServices, esta característica permite la utilización de estos para generar
cotizaciones para el portal www.ComparaOnline.cl, el cual es un sitio dedicado a
realizar cotizaciones de seguros automotrices en distintas compañías y presentar al
usuario de este sitio web una abanico de seguros a contratar según las necesidades del
usuario. Esto permite al aplicativo proveer a la compañía de seguros aumentar su
competitividad en el mercado.
El aplicativo desarrollado es un sitio web esto le permite estar disponible para su uso las
24 horas del día los 365 días del año convirtiéndose cumpliendo con el objetivo
especifico de disponibilidad de uso.
El aplicativo al ser desarrollado con una herramienta que permite la orientación a

objetos, le da la cualidad de poder implementar cambios y expansiones con un costo
bajo de impacto.

REFERENCIAS
[1] Súper Intendencia de Seguros y Valores, Mercado de Seguros, Estructura de

Mercado, Oferta de Seguros [en línea] Disponible:
http://www.svs.cl/sitio/mercados/seguros_estrucOferta.php
[2] Súper Intendencia de Seguros y Valores, Mercado de Seguros, Estructura de

Mercado, Normativa legal del mercado Asegurador chileno [en línea] Disponible:
http://www.svs.cl/sitio/legislacion_normativa/normativa/seguros/resumen_dfl251.pdf
[3] Ley de Seguros. DFL Nº 251 , de 1931. (texto actualizado e incluye modificaciones
introducidas por la ley Nº 20.255, de 17 de marzo de 2008).
[4] - Pressman, Roger S.; Ingeniería del Software: Un enfoque práctico; Cuarta
edición. McGraw-Hill, México D. F.,1998. Capítulo 18.
[5]. G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje

Unificado de Modelado", Addison Wesley, 1999

Tesis

Cargado por

Copyright:

Formatos disponibles

Tesis

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO – CHILE

Sistema Cotización de Seguros Automotrices on-line.

FELIPE ANDRÉS SILVA PADILLA

INFORME FINAL DEL PROYECTO

Sistema Cotización de Seguros Automotrices on-line.

FELIPE ANDRÉS SILVA PADILLA

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

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

FELIPE A(DRES SILVA PADILLA

FELIPE A(DRES SILVA PADILLA

Pontificia Universidad Católica de Valparaíso Página 6

Pontificia Universidad Católica de Valparaíso Página 7

Figura 1 Ciclo de vida clásico del software. ................................................................... 17

Pontificia Universidad Católica de Valparaíso Página 8

Tabla 1 Especificación tarea EDT .................................................................................. 18

Pontificia Universidad Católica de Valparaíso Página 9

Pontificia Universidad Católica de Valparaíso Página 10

La contratación de un seguro se formaliza mediante la emisión de una póliza de

Dentro del grupo de seguros generales se encuentran los de tipos automotrices,

A través de los capítulos en que se ha dividido este documento, se planteara la

Continúa el documento mostrando cual será la planificación, esta estará guiada

Pontificia Universidad Católica de Valparaíso Página 11

El modelo de ventas de seguros automotrices se está cimentado en una arquitectura

• Entidad Aseguradora: Son las encargadas de cubrir el riesgo de los seguros

• El asegurado es el beneficiario del seguro.

En la actualidad la interacción entre estas 5 bases se realiza siguiendo el siguiente

Pontificia Universidad Católica de Valparaíso Página 12

Este método de trabajo presenta las siguientes deficiencias.

• La comunicación entre la entidad aseguradora y el corredor no es on-line, por lo

Pontificia Universidad Católica de Valparaíso Página 13

1.3 OBJETIVO GE(ERAL DEL PROYECTO.

1.4 OBJETIVOS ESPECÍFICOS.

Para atender el objetivo general se proponen los siguientes objetivos específicos:

• Diseñar e implementar una aplicación que permita obtener información

• Desarrollar funcionalidades capaces de consumir WebServices que entregan

• Proveer de una aplicación que genere un canal de transferencia de información

• Desarrollar un sistema adaptable a los cambios y expansiones.

Pontificia Universidad Católica de Valparaíso Página 14

El proceso de Ingeniería de Software es un conjunto de actividades necesarias

Existen varias metodologías de desarrollo. Cada una de estas presenta diferentes

• Ciclo de Vida Clásico o Modelo en Cascada

Se utilizará el Modelo en Cascada pues es la metodología de trabajo que está definida

2.1 MODELO E( CASCADA

1. Ingeniería y análisis del sistema.

Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza

Pontificia Universidad Católica de Valparaíso Página 15

Este proceso se centra esencialmente en el software. Para comprender la naturaleza

El software indudablemente, sufrirá cambios después de que se entregue al

Pontificia Universidad Católica de Valparaíso Página 16

El Lenguaje Unificado de Modelado (UML) es un lenguaje estándar para

• Elementos: Son la representación de un artefacto del sistema.

Se opto por el modelado de UML (Unified Modeling Language) debido a que es

Pontificia Universidad Católica de Valparaíso Página 17

En este capítulo se presentará el proceso planificación del proyecto a ejecutar. Para

• EDT (Estructuras de Desglose de Trabajo), para la representación grafica de esta

3.1.1 Especificación de Tareas

Pontificia Universidad Católica de Valparaíso Página 18

Pontificia Universidad Católica de Valparaíso Página 19