Proyecto Arquitectura de Software

Venta de planes de seguros Arquitectura de Software PRESENTACIÓN El presente trabajo describe el proyecto para el des

Views 203 Downloads 0 File size 328KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

Venta de planes de seguros Arquitectura de Software

PRESENTACIÓN

El presente trabajo describe el proyecto para el desarrollo de software que permita automatizar los procesos de que contiene el negocio de cotización y afiliación de la venta de Seguros de la Empresa NOVASALUD y su integración con otros procesos de la empresa.

u201400528 - Ángelo Padilla Fuertes u201401554 - Raúl Vásquez u201400645 – Noé Maguiña EMPRESA NOVASALUD

ÍNDICE

INTRODUCCIÓN............................................................................................ 3 Objetivos del proyecto............................................................................... 4 1. Capítulo 1: Modelo del negocio.........................................................4 1.1. Descripción de la organización objetivo........................................4 1.2. Descripción del negocio...................................................................4 2. Capítulo 2: Requerimientos...............................................................5 2.1. Visión del sistema............................................................................. 5 2.2. Especificación de los requerimientos de software.....................5 2.2.1. Lista de características.................................................................5 2.2.2. Lista de requerimientos suplementarios o de calidad.............5 2.2.3. Lista de reglas del negocio...........................................................6 2.3. Modelo de casos de uso...................................................................7 2.3.1. Lista y diagrama de actores.........................................................7 2.3.2. Diagrama de paquetes..................................................................8 2.3.3. Diagrama de casos de uso por paquete.....................................9 2.3.4. Especificación de casos de uso de alto nivel...........................10 2.3.5. Lista de casos de uso priorizados.............................................12 2.3.6. Lista de casos de uso que impactan en la arquitectura........12 3. Capítulo 3 : Análisis............................................................................. 0 3.1. Modelo del dominio de clases o modelo conceptual................0 3.2. Realización de los casos de uso para el análisis........................0 3.2.1. Especificación detallada de Historias de Usuario de los casos de uso que impactan en la arquitectura................................0 3.2.2. Diagrama de clases de análisis...............................................2 3.2.3. Diagrama de interacción de los casos de uso especificados......................................................................................... 3 DI_Registra Información Personal............................................................3 4. Conclusiones......................................................................................... 3 5. Glosario de términos............................................................................4 6. Siglario................................................................................................... 5

INTRODUCCIÓN En líneas generales el Grupo NovaSalud está orientado a prestar servicios de aseguramiento oncológico. NovaSalud está considerada como una prepaga, que es básicamente una empresa que ofrece planes privados de salud, en este caso planes oncológicos, que cada persona o grupo familiar puede pagar de acuerdo a sus propias expectativas. Debido a que cada familia determina cuanto quiere gastar y que nivel de cobertura requiere, este sistema es llamado Medicina Pre pagada o por Prepago. Los planes oncológicos que ofrece NovaSalud son considerados planes complementarios a los planes de salud básicos. En este contexto, el Grupo NovaSalud requiere contar con una solución informática que permita gestionar los procesos de Ventas de planes de seguros de acuerdo a las reglas del mercado asegurador, a las reglas propias de los productos que actualmente se manejan y finalmente de acuerdo a la normatividad vigente. El Grupo NovaSalud ha decidido implementar un Sistema informático de Gestión de Ventas que se irán definiendo con los procesos de Ventas, suscripción y los sub procesos que ayudarán a describirla.

Objetivos del proyecto El proyecto tiene como objetivo gestionar la venta de los productos NovaSalud a través de los Canales de Venta en cuanto al registro de los datos generales del canal, la clasificación de los mismos, y los contratos donde se detallan las condiciones según las cuales cada canal realizará las ventas de los productos. Los contratos permiten definir las condiciones generales relacionadas a los productos, comisiones pactadas, tipos de clientes, tipos de pago con las cuales los canales pueden realizar la venta. El proyecto tiene como objetivos específicos   

Captar más canales de venta para abarcar una población mayor de próximos afiliados Ofrecer variedad de planes por rango de grupo etario (edades) Ofrecer planes con excepciones para clientes que no pasen los exámenes de PSA o mamografías.

1. Capítulo 1: Modelo del negocio 1.1.

Descripción de la organización objetivo

NovaSalud: Es una empresa con presencia mundial, que está especializada en la prevención, detección diagnóstico y tratamiento del cáncer. 1.2.

Descripción del negocio

El proceso de ventas comienza desde que el cliente se acerca al canal de venta a solicitar una cotización. La cotización es la parte de interacción del proveedor con el cliente a través de los diferentes canales de venta, que le permitirá obtener información sobre el plan al cual desea afiliarse y brindar datos esenciales para solicitar una pre-afiliación. Posteriormente, la solicitud será sometida a evaluación para determinar si procede o no la afiliación. Finalmente, se notifica al cliente el resultado de la evaluación de la respectiva solicitud.

2. Capítulo 2: Requerimientos 2.1.

Visión del sistema

2.2.

Especificación de los requerimientos de software

2.2.1.Lista de características 2.2.2. Lista de requerimientos suplementarios o de calidad         











FUNCIONALIDAD Registrar información de los clientes. Realizar los cálculos de los planes de acuerdo a las características del cliente. Generar solicitud de cotización con número único. Generar informe de cotizaciones diariamente. Generar solicitud de pre – afiliación. Toda solicitud debe poder imprimirse. Realizar validaciones automáticas en el sistema. Generar documento de validación médica de suscripción Emitir modelos de cartas para resultados de suscripción médica. USABILIDAD El sistema debe ser lo más amigable posible, debido a que la mayor parte de la concentración de nuestros clientes está orientado a personas de la tercera edad. En caso de algún error en el sistema, estos deben estar correctamente tipificados para su más rápida solución por nuestro personal técnico. CONFIABILIDAD Nuestras redes de clínicas de seguros atienden las 24 horas del día por ello es importante que se tome en cuenta la performance del rendimiento de la misma. Requerimos semanalmente sacar estadísticos de clientes afiliados, clientes rechazados, clientes con observaciones, etc. Pero al momento de bajar esa información el sistema no debe verse impactado. RENDIMIENTO Actualmente se manejan un total de 500 asesores de ventas (canal) que van ofreciendo nuestros seguros oncológicos y mediante una portátil podrán ingresar al sistema. Por ello, se requiere tomar la precaución con respecto al rendimiento ante un ingreso masivo de nuestros agentes.

    





Ello también no debe afectar a los tiempos de respuesta de las cotizaciones o registros de información. Tener en cuenta un alto nivel de TPS. SOPORTE Nuestro sistema web debe correr normalmente en los navegadores Google Chrome, IE y Mozilla. El sistema web debe ser compatible con el SO Windows 8 en adelante. Toda corrección de error en el sistema debe atendido en un máximo de 20 minutos. CONSIDERACIONES DE DISEÑO Tomar todas las mejores condiciones de aspecto al momento de realizar el diseño. Utilizar las herramientas de CSS y JavaScript. DOCUMENTACIÓN DE USUARIO EN LÍNEA Y SISTEMA DE AYUDA Todas las ventanas deben presentar un icono de “?” el cual nos brinde la mejor ayuda posible en cuanto a manejo del sistema. COMPONENTES ADQUIRIDOS No aplica

  

INTERFACES Manejamos un estándar predefinido con colores establecidos. Color de pantalla: Combinar el azul marino con el plomo. Color de letra: Utilizar los colores blanco y un amarillo bajo. LICENCIAMIENTO No aplica



REQUERIMIENTOS LEGALES, COPYRIGHT Y OTROS Todos los derechos reservados serán nuestros.



ESTÁNDARES APLICABLES Los explicados anteriormente

2.2.3.Lista de reglas del negocio REGLAS DE CÁLCULO RN01. Solicitud de cotización.- Todos los planes de acuerdo a su rango etario tienen precios establecidos, los

cuales son aplicados en fórmulas para obtener el costo del plan que pagaría el afiliado titular. REGLAS DE RELACIÓN RN02. Afiliaciones.- Un afiliado tiene un número único de afiliado. Así mismo, un afiliado puede estar solo dentro de una póliza (contrato) de seguro. Reglas de estructura. RN04. Agrupamiento de familias de asegurados.Cuando se afilia un grupo familiar, existe un indicador que muestra la cantidad de asegurados que están dentro del grupo. El indicador es universal (T0, T1, T2). Ello indica Titular, Titular más uno, Titular más dos. REGLA DE OPERACIÓN RN05. Proceso de suscripción.- Cuando el cliente está en proceso de evaluación y se observa que tiene alguna pre existencia. Se le informa al cliente mediante una carta que se le puede afiliar pero con algunos cambios en las condiciones de su póliza. Si el afiliado no responde a la carta, se cancela el proceso de afiliación.

2.3.

Modelo de casos de uso

2.3.1.Lista y diagrama de actores CLIENTE El cliente se transforma en un actor de sistema cuando el mismo realiza su proceso de cotización y pre afiliación en el sistema web. PROMOTOR DE VENTAS, ASISTENTE DE VENTAS Estos actores del sistema representan a un canal de venta, como ellos existen los canales de venta en oficina y la parte web también representa a un canal. Son los encargados de obtener los clientes ofreciéndoles variedad de planes. MEDICO AUDITOR El médico auditor es el encargado de realizar el proceso de suscripción a todas las pre afiliaciones que se realizar, él decide si un cliente se afilia o no, o quizá puede ofrecer alternativas de afiliación. ASISTENTE TÉCNICO

Es la persona encargada de distribuir la documentación solicitada por las diferentes áreas del proceso de ventas. Además, es el encargado de generar una carta modelo ya sea de afiliación o de rechazo de afiliación. Diagrama de actores del sistema

Usuario

Cliente

Promotor de Ventas

2.3.2.Diagrama de paquetes

Asistente de Ventas

Asistente Técnico

Médico Auditor

2.3.3.Diagrama de casos de uso por paquete PAQUETE COTIZACIÓN

PAQUETE SUSCRIPCIÓN

PAQUETE AFILIACIÓN

2.3.4.Especificación de casos de uso de alto nivel Caso de uso: Actor(es): Propósito: Caso de uso asociado: Resumen:

Registrar información personal Cliente, Asistente Ventas Registrar toda cotización o pre – afiliación iniciada Validar información El caso de uso comienza cuando el cliente registrar sus datos por el sistema web o cuando el asistente de ventas realiza el registro también por el sistema pero cuando el cliente está en frente de él. Según su requerimiento el Cliente puede solo rellenar datos mas no borrar una vez que todo haya sido grabado, el asistente de

Clasificación: Caso de uso: Actor(es): Propósito: Caso de uso asociado: Resumen:

Clasificación: Caso de uso: Actor(es): Propósito:

Caso de uso asociado: Resumen:

Clasificación: Caso de uso: Actor(es): Propósito: Caso de uso asociado: Resumen:

ventas si tiene la potestad de registrar y/o modificar los datos ya grabados. El caso de uso termina con la grabación de los datos. Primario Generar cotización Cliente, Asistente de ventas Obtener una cotización de algún plan de seguro Selección de plan, Generar informe cotización. El caso de uso comienza cuando el cliente o el asistente de ventas han registrado correctamente los datos. Según su requerimiento este es un proceso automatizable que se realizará al dar clic en un botón. El caso de uso terminará con la impresión de la cotización. Primario Generar solicitud de pre afiliación Asistente de ventas, Cliente Obtener los datos correctamente de los clientes para el envío de información futura. Imprimir solicitud de pre afiliación, Entrega solicitud de pre afiliación, Adjunta DJS. El caso de uso comienza cuando el asistente de ventas o el cliente aceptaron la cotización y dieron clic en iniciar pre afiliación. Según su requerimiento todo proceso de pre afiliación se iniciará después de haberse cotizado. El caso de uso termina cuando se da clic en dicho botón de inicio de pre afiliación. Primaria Generar formulario de suscripción Medico auditor Evaluar la pre afiliación solicitada por el cliente. Adjunta examen médico El caso de uso comienza cuando el médico auditor recepciona la solicitud de pre

Clasificación: Caso de uso: Actor(es): Propósito: Caso de uso asociado: Resumen:

Clasificación:

afiliación. Según su requerimiento el médico auditor evaluará la DJS adjuntada y tomará la decisión de aceptar, rechazar u observar la pre afiliación. El caso de uso termina cuando el medico emite sus resultados y genera su formulario de suscripción. Primaria Generar cartas modelo Asistente técnico Informar al cliente sobre su proceso de afiliación

El caso de uso comienza cuando el asistente técnico recibe el informe médico. Según su requerimiento el asistente técnico procederá a emitir cartas modelo de envío al cliente para informar al cliente sobre su proceso de pre afiliación. El caso de uso termina cuando se realiza el envío de la carta modelo al cliente. Primaria

2.3.5.Lista de casos de uso priorizados

2.3.6.Lista de casos de uso que impactan en la arquitectura Caso de uso Registrar información personal Validar información Generar cotización Selección de plan Generar

Complejid ad Primario

Estado

Secundari o Primario

Defini do Defini do Defini do Defini

Secundari o Secundari

Defini do

Dificulta d Baja

Responsa ble Canal de venta

Priorida d Ciclo 0

Media

Canal venta Canal venta Canal venta Canal

de

Ciclo 0

de

Ciclo 0

de

Ciclo 0

de

Ciclo 0

Alta Baja Media

informe cotización Generar solicitud de pre afiliación Imprimir solicitud de pre afiliación Entrega solicitud de pre afiliación Adjunta DJS Generar formulario de suscripción Adjunta examen médico Generar cartas modelo

o

do

venta

Primario

Defini do

Alta

Canal de venta

Ciclo 1

Secundari o

Defini do

Media

Canal de venta

Ciclo 1

Secundari o

Defini do

Baja

Canal de venta

Ciclo 1

Secundari o Primario

Defini do Defini do

Media

Canal de venta Médico auditor

Ciclo 1

Secundari o

Defini do

Baja

Médico auditor

Ciclo 2

Primario

Defini do

Alta

Asistente técnico

Ciclo 3

Alta

Ciclo 2

3. Capítulo 3 : Análisis 3.5.1. Modelo del dominio de clases o modelo conceptual

3.2. Realización de los casos de uso para el análisis 3.2.1. Especificación detallada de Historias de Usuario de los casos de uso que impactan en la arquitectura Nombre

Registrar información personal

Autor

Analista Funcional

Actor

Cliente, Asistente Ventas

Iteración Casos de uso asociados

CU_Generar solicitud de cotización

Descripción

El caso de uso comienza cuando el cliente registrar sus datos por el sistema web o cuando el asistente de ventas realiza el registro también

Nombre

Registrar información personal por el sistema pero cuando el cliente está en frente de él. Según su requerimiento el Cliente puede solo rellenar datos mas no borrar una vez que todo haya sido grabado, el asistente de ventas si tiene la potestad de registrar y/o modificar los datos ya grabados. El caso de uso termina con la grabación de los datos.

Referencias

Reglas de negocio:

RF02_Ingresar datos RF02_Modificar datos RF02_Eliminar datos RN05_Proceso de suscripción

Precondiciones

Código y clave de ingreso al sistema

Post Condiciones

Se generó el registro de la información personal de la persona Se generó un nuevo código de cliente

Flujo normal de eventos 1. El caso de uso se inicia cuando el Asistente de Ventas (Cliente) seleccionan la opción “Registrar Información Personal” 2. El sistema muestra la interfaz “Registrar Información Personal” con la vista formulario con los siguientes campos: Nombre, Apellido Paterno, Apellido Materno, Género, Fecha de Nacimiento, Tipo de Documento, Nro. Documento, Correo, País, Departamento, Provincia, Distrito, Dirección, Teléfono Fijo, Teléfono Celular. Además, de las opciones Nuevo, Registrar y Modificar. 3. Si el Asistente de Venta elige: 3.1. “Nuevo” se limpian los campos y vuelve al punto 2. 3.2. “Grabar”, el sistema graba los datos en la base de datos Cliente. 3.3. “Editar”, el sistema permite modificar los campos previamente registrados. 3.4. “Borrar”, el sistema permite eliminar los datos del cliente 4. El caso de uso finaliza. Sub Flujo Registrar Cliente 1. 2. 3. 4.

El El El El

Asistente de Ventas ingresa los datos de un cliente. Sistema carga los datos del cliente en el formulario. Asistente de Ventas presiona el botón Registrar. sistema valida los datos ingresados.

Nombre

Registrar información personal

5. El sistema registra los datos del cliente y muestra el MSG “Cliente registrado con éxito”. 6. El sistema regresa a la interfaz Registrar Información Personal. Sub Flujo Actualizar Cliente 1. El Sistema carga los datos del cliente en el formulario. 2. El Asistente de Ventas modifica los datos del cliente. 3. El Asistente de Ventas presiona el botón Registrar. 4. El sistema valida los datos ingresados. 5. El sistema actualiza los datos del cliente y muestra el MSG “Cliente actualizado con éxito”. 6. El sistema regresa a la interfaz Registrar Información Personal. Sub Flujo Borrar Cliente 1. El Sistema carga los datos del cliente en el formulario. 2. El Asistente de Ventas presiona el botón Borrar. 3. El sistema muestra el MSG: “¿Confirmar borrar a este Cliente?”. 4. El Asistente de Ventas selecciona la opción Si para confirmar la eliminación. 5. El sistema muestra mensaje de confirmación en la interface de Registrar Información Personal. 6. El Sistema regresa a la interfaz Registrar Información Personal. Flujo alternativo 1 Datos del Cliente Inválidos En los pasos 4 del subflujo Registrar y 4 del subflujo Actualizar Cliente si los datos ingresados del cliente son nulos o inválidos el sistema muestra el MSG: “Se han encontrado datos inválidos del cliente, verifique” y el flujo no continua. Flujo alternativo 2 No Confirma Eliminación En el paso 2 del subflujo Borrar Cliente, si el Administrador selecciona No. Finaliza el Subflujo. Información adicional Pantalla 1:

Nombre

Registrar información personal

3.2.2. Diagrama de clases de análisis CA_Registrar Información Personal

3.2.3. Diagrama de interacción de los casos de uso especificados DI_Registra Información Personal

4. Conclusiones 







 

La especificación de requerimientos de software debe ser lo suficientemente clara y precisa con respecto a sus descripciones puesto que ello es un punto primordial para el viabilidad del proyecto. Para realizar una confiable especificación de casos de uso del sistema se debe tener la correspondencia con los requerimientos funcionales hallados, y detallar el que y el cómo se realizará dicho caso de uso. Cuando se empieza profundizar en estas especificaciones se van encontrando consideraciones que hacen necesarios modificaciones en los artefactos del proyecto. La trazabilidad es un elemento sumamente importante, tanto para el control de los avances del proyecto como para sustentar la incorporación y especificación de casos de uso del sistema. Es importante mantener un control de la administración del proyecto (cronograma y entregables) en paralelo a la ingeniería del mismo (artefactos de la metodología RUP) pues así se controla mejor el proyecto lo cual ayuda a detectar el origen de los riesgos y problemas. Así mismo, es imprescindible mitigar las ambigüedades pues son un riesgo para el proyecto.

Una conclusión importante es al haber aplicado los estándares de modelamiento necesarios para representar de forma más detallada el negocio se debe llegar de esa manera a realizar el desarrollo del proyecto en un corto tiempo, minimizando recursos y aun costo inferior al establecido.





Asimismo, según lo analizado se concluye que falta un proceso de verificación y validación de documentos, lo cual sirve para tener un control del documento de examen de asegurabilidad ingresado a la clínica y tomado en cuenta para generar las afiliaciones. Además, se debe redefinir la interfaz de usuario del canal de venta vía web, ya que la producción de ventas abarca mayormente a personas de la tercera edad y no se ha tomado en cuenta como un requerimiento funcional.

5. Glosario de términos A Asegurado: La persona u organización que está cubierta por el plan de seguro. C Canal de Venta: Medio por el cual se va a realizar el proceso de Venta del seguro por parte del cliente. Cobertura: Protección de seguro o de reaseguro, en base a acuerdos contractuales. Es lo establecido por escrito en el contrato de seguro o póliza de seguros, donde se establecen las condiciones generales, particulares, detalle del bien asegurado, costo, etc. que sirven para establecer y enunciar todos los derechos y obligaciones de las partes contratantes.

D Diagnóstico Es la identificación médica de los signos, síntomas y hallazgos presentados por el paciente. Como estándar, se utiliza la codificación internacional CIE 10 (Décima versión de la Clasificación Estadística Internacional de Enfermedades y otros Problemas de Salud). O Oncología: Es la especialidad médica que estudia y trata las neoplasias; tumores benignos y malignos. Los profesionales de esta especialidad son los oncólogos. Orden de Atención: Documento en donde se registra la información relativa a la atención que va a realizar el paciente en la clínica, la cual indica entre otros datos la especialidad en la cual se va a atender, médico, etc. G Grupo etario: Es un conjunto de personas, que tienen el mismo rango de edades.

P Prueba de asegurabilidad: Para clasificar a un plan, las clínica tiene derecho a pedirle información sobre su salud y su estilo de vida. La clínica usará esta información - su prueba de asegurabilidad - para decidir si lo puede aceptar, y a qué precio le puede vender el plan. Póliza: Documento que el asegurador entrega al asistente de Ventas mediante el cual se declara formalmente la existencia del contrato de seguro y las condiciones en que se ha pactado. 6. Siglario  

DJS: Declaración Jurada de Salud. PS: Plan de Salud