Solarte, Cruz y Saint-Priest / J. Comput. Electron. Sci.: Theory Appl., vol. 2 no. 1 pp. 19-30. Enero - Junio, 2021

Aplicación Web para la Predicción del Comportamiento de la Población Vinculada a la Compañía de Seguros Funerarios Servivir

Web Application for Predicting the Behavior of the Population Linked to the Servivir Funeral Insurance Company

DOI: https://doi.org/10.17981/cesta.02.01.2021.02

Artículo de investigación científica. Fecha de recepción: 04/03/2021. Fecha de aceptación: 19/06/2021.

Omar Solarte M.

Universidad Santiago de Cali. Cali (Colombia)

omar.solarte00@usc.edu.co

Carlos Andres Cruz G.

Universidad Santiago de Cali. Cali (Colombia)

carlos.cruz05@usc.edu.co

Yana Elida Saint-Priest V.

Universidad Santiago de Cali. Cali (Colombia)

yana.saint-priest00@usc.edu.co

.

Para citar este artículo:

O. Solarte, C. Cruz y Y. Saint-Priest, “Aplicación Web para la Predicción del Comportamiento de la Población Vinculada a la Compañía de Seguros Funerarios Servivir”, J. Comput. Electron. Sci.: Theory Appl., vol. 2, no. 1, pp. 1–30, 2021. https://doi.org/10.17981/cesta.02.01.2021.02

.

Resumen— El núcleo de negocio de la empresa Servivir se basa en servicios a partir de la venta de planes exequiales o funerarios. En su proceso realiza análisis de datos para comprender el comportamiento de los clientes, sin embargo, no cuentan con las herramientas especializadas para el análisis de datos que haga el proceso más eficiente y confiable; es así como nace la idea de este proyecto cuyo objetivo es la construcción de una aplicación web que permite realizar análisis de datos y presentar los resultados de los mismos a través de reportes gráficos. El proyecto se diseñó bajo la estructura metodológica incremental de desarrollo de software, también se implementaron lineamientos y artefactos de la metodología Scrum. Los resultados mostraron información relevante del comportamiento de los asociados a Servivir, se encontró concentración poblacional en tres entidades asociadas, lo cual genera un riesgo financiero en caso de retiro por fallecimiento. Al final se concluye que la aplicación reduce los tiempos de análisis de información en un 99,98%, con lo cual se considera altamente funcional.

Palabras clave— Bodega de datos; reportes gráfico; regresión lineal; seguros funerarios; exequiales

Abstract— The business core of the company Servivir is based on services from the sale of exequial plans. In their process, they perform data analysis to: for example, a population concentration was found in three associated entities, which generates a financial risk in the event of understand customer behavior, however, they do not have the specialized tools for data analysis that make the process more efficient and reliable; it’s for this that the idea of building a web application was born that allows data analysis and presents the results through graphic reports. The project was designed under the incremental methodological structure of software development, guidelines and artifacts of the Scrum methodology were also implemented. The results showed relevant information on the behavior of those associated with Servivir retirement. In the end it is concluded that the application reduces the information analysis times by 99.98%, with what is considered highly functional.

Keywords— Data warehouse; graphical reports; linear regression; funeral insurance

I. Introducción

La empresa Servivir es una compañía que vende seguros exequiales con una permanencia por más de 26 años en el mercado suroccidente Colombiano, una gran parte del negocio es la prestación de dichos servicios. Un servicio exequial es un seguro que cubre los servicios funerarios en caso de fallecimiento de las personas inscritas en la póliza, la póliza debe estar en vigencia cuando se requiera la prestación de los servicios. En una entrevista con el director de Sistemas de Gestión y Calidad de Servivir manifiesta que se ha almacenado por más de 20 años datos de sus clientes en un ERP (Enterprise Resource Planning) llamado LINIX, soportado en una base de datos Oracle. El núcleo de negocio de la organización se basa en conocer el comportamiento de la población vinculada a los servicios que ofrecen. Algunos de los comportamientos más importantes son: los rangos de edad donde se concentran la mayor parte de fallecimientos, los planes exequiales con mayor impacto de deceso, los meses con mayor tasa de mortalidad y el tipo de muerte (natural o violenta) con más frecuencia.

El área de sistemas de gestión y calidad es la encargada en primera instancia de realizar el análisis de datos, convirtiendo los resultados en insumo para las demás áreas del negocio. Para Servivir es importante conocer la información almacenada en la base de datos y que cada área cuente con toda la información que permita realizar las estrategias comerciales y proyecciones financieras anuales. Sin embargo, este proceso no cuenta con herramientas dedicadas al análisis de datos de un modo más eficiente y confiable, siendo las hojas de cálculo la única opción utilizada actualmente. La información puede ser explotada de mejor manera, permitiendo así realizar un análisis más preciso y confiable que finalmente entregue resultados que ayuden a mejorar las estrategias comerciales.

En la actualidad existen diversos software que, basándose en datos, predicen el comportamiento de un negocio a través de probabilidades que como finalidad alerta sobre algunos riesgos en diferentes áreas, ayudando a la toma de decisiones a los equipos de alta gerencia. Uno de estos es el Software Danger, un software especializado en la identificación de riesgos SIAR (Sistema Integral de Administración de Riesgos), el cual identifica la concentración de los riesgos graficando en diferentes segmentos y factores [20].

Para las empresas es importante la medición de los riesgos operacionales ya que son uno de los factores críticos en el momento de medir los procesos de gestión financiera. En el año 2016 se realizó un estudio aplicando una modelación de riesgo operacional causado por factores demográficos, cuyo objetivo es medir el riesgo financiero en empresas no financieras expuestas ante variables como tasas de mortalidad o tasas de morbilidad [1]. La metodología desarrollada incorpora elementos de la literatura actuarial, la economía financiera y la teoría de cópulas. Se centra en la medición del riesgo subyacente a factores demográficos y permite minimizar los requerimientos de información para su estimación.

En la actualidad, las empresas almacenan datos que en su mayoría no son analizados mientras que otras recopilan información y la forma de almacenarla limita la posibilidad del uso de los datos. Años antes, para el 2009 [2], se plantea como solución el uso de Business Intelligence, el cual generalmente se entiende como un software dedicado de análisis e informes con una interfaz gráfica de usuario, que procesa y visualiza la información requerida para la toma de decisiones gerenciales.

A raíz de todo lo anterior, se propuso construir una aplicación web que visualice mediante reportes gráficos los resultados del análisis predictivo del comportamiento de la población vinculada a Servivir, analizando los datos almacenados por más de 20 años en la base de datos de la organización, utilizando técnicas de minería de datos y así agilizar la toma de decisiones. Además, para el diseño y desarrollo de la aplicación fueron utilizadas las herramientas descritas en la Tabla 1.

Tabla 1.
Herramientas utilizadas para el diseño y desarrollo de la aplicación web.

Herramienta

Función

Inkscape

Diseño de interfaces frontend

Oracle Data Modeler

Diseño de base de datos dimensional.

Pentaho Data-Integration

Diseño y generación del proceso ETL.

Visual Studio Code

Codificación del desarrollo.

Oracle

Creación de la base de datos dimensional y relacional.

DBeaber Community

Administración de base de datos.

Npm

Administración de librerías Javascript implementadas en angular.

Pip

Utilizado para administrar librerías Python

Postman

Realización de las pruebas de los servicios Rest que alimentan la aplicación web de datos.

Fuente: Elaboración propia.

El proyecto comprende la ejecución de cuatro fases. Éstas y la documentación del proyecto son producto de la combinación de las metodologías Scrum e incremental. En primera instancia, se lleva a cabo la fase de análisis, en la cual se crearon los requerimientos y se descubrieron procesos de negocio y métricas. Seguidamente, en la fase de diseño se elaboraron las interfaces, la arquitectura y los documentos de pruebas funcionales y de usabilidad. A continuación, en la fase de desarrollo se implementaron los requerimientos para la construcción de la aplicación. Por último, en la fase de pruebas se aplicó el test funcional y de usabilidad al usuario que aprueba el correcto funcionamiento y el cumplimiento de las necesidades de la empresa, solicitadas para la aplicación.

II. Materiales y Métodos

El proyecto se diseñó bajo una estructura metodológica incremental de desarrollo de software. Investigaciones de la Universidad Católica de Argentina afirman que está compuesta por la fase de análisis y diseño, desarrollo, pruebas y entrega [3]. Además, confirman que este modelo permite verificar los avances en periodos cortos de tiempos y las pruebas e integración son constantes. Las pruebas realizadas fueron sobre la funcionalidad de la página web y estuvieron enfocadas al grado de satisfacción de los usuarios basado en la usabilidad del sistema.

Además, se implementaron lineamientos de la metodología Scrum, debido a que ésta permite flexibilidad, adaptabilidad y agilidad en el proceso de análisis y desarrollo, donde las características principales se dan en los roles definidos para el proyecto. En este sentido se complementa con qué, Scrum contiene una serie de reglas que permiten definir roles, generar artefactos necesarios y realizar desarrollo de objetivos en tiempos preestablecidos y ceremonias que deben respetarse [4]. Frente a las ceremonias que se mencionan [4], se interpreta en el proyecto como las reuniones de equipo de trabajo y sesiones semanales realizadas con el dueño del producto para verificar que se realizó lo pactado en el cronograma de trabajo.

La Fig. 1 muestra la combinación de los procesos y artefactos implementados de las metodologías incremental y Scrum generando un proceso de desarrollo de software adaptado a cumplir el objetivo general del proyecto. Por una parte se implementan las fases de análisis, diseño, desarrollo y pruebas de la metodología incremental combinado con los roles y la documentación liviana que ofrece Scrum. Se establecieron cuatro etapas: la etapa de análisis, en la cual se recolecta la información, se definió y se especificó requerimientos, se establecieron prioridades de los requerimientos y reuniones semanales para observar avances del proyecto; la etapa de diseño, en la cual se define la estructura del proyecto y las pruebas de usuario; la etapa de desarrollo para la implementación de los requerimiento y el diseño de aplicación; y la etapa de pruebas para el análisis y determinación de la calidad y satisfacción del usuario.

Fig. 1. Metodología implementada en el proyecto.
Fuente: Elaboración propia.

Basado en la metodología, se definieron y asignaron los roles y funciones del proyecto, para el cumplimiento de las tareas que fueron asignadas a cada responsable, como se muestra en la Tabla 2 a continuación.

Tabla 2.
Descripción de roles.

Rol

Función

Responsable

Líder Scrum

Elaborar el plan de trabajo y validar el progreso de las actividades del proyecto.

Luis Fernando Franco D.

Analista de Requerimientos

Levantar y especificar los requerimientos por medio de entrevistas y lluvia de ideas.

Carlos Andrés Cruz G.

Desarrollador

Implementar los requerimientos para el front y el backend, construir la base de datos dimensional, el proceso ETL (Extract, Transform and Load) y la integración de todos los componentes que hacen parte de la aplicación.

Omar Solarte M.

Carlos Andrés Cruz G.

Analista de pruebas

Realizar las pruebas funcionales y la ejecución, validación y análisis de las pruebas de usabilidad.

Omar Solarte M.

Carlos Andrés Cruz G.

Luis Fernando Franco D.

Fuente: Elaboración propia.

A. Fase de Análisis

En esta fase se generó el Product Backlog, basado en el análisis de las necesidades de empresa, documento donde se registran los requerimientos de alto nivel, y así, se identifican las expectativas de los usuarios. Como señalan en la Guía de Scrum, es la lista de las actividades que deben realizarse para la consecución de un proyecto [5]. Además se generó un sprint backlog, el cual se encarga de la priorización de los requerimientos para la ejecución del proyecto. Se afirma que el sprint backlog es una lista de tareas pendientes por ejecutar del Product Backlog las cuales se realizan durante un sprint [6]. En la Tabla 3 se muestra el listado de los requerimientos, y la prioridad que se le asignó a cada historia de usuario.

Tabla 3.
Resumen listado de requerimientos.

ID HU

Enunciado

Prioridad

Cómo

Quiero

Para

RF-08

usuario

Consultar el % de empleados de la entidad asociados a Servivir

Ver el % de vinculados a Servivir de la población total de la entidad asociada seleccionada y el nicho pendiente de esa entidad por asociar

ALTA

RF-09

usuario

Consultar la segmentación por edad de vinculados por entidad asociada

Visualizar por cada entidad Asociada, el % de vinculados por rango de edad

ALTA

RF-10

usuario

Consultar la segmentación por género de vinculados por entidad asociada

Visualizar por cada entidad Asociada, el % de vinculados por género

ALTA

RF-11

usuario

Consultar el índice de siniestralidad de una entidad

Ver el % y cantidad de asociados a la entidad vinculados a Servivir han fallecido en un rango de fechas

ALTA

RF-12

usuario

Consultar el índice de siniestralidad frente a Servivir

Ver del total de fallecidos de todas las entidades asociadas, que % de fallecidos aporta los asociados a la entidad vinculados a Servivir

ALTA

RF-13

usuario

Consultar el costo del índice de siniestralidad de una entidad

Ver el costo de los fallecidos que estuvieron asociados por entidad a Servivir han fallecido en un rango de fechas

ALTA

RF-14

usuario

Consultar el índice de siniestralidad frente a Servivir

Ver del total de fallecidos de todas las entidades asociadas, el costo de los fallecidos que aporta una entidad asociada a Servivir

ALTA

RF-15

usuario

Ver los resultados de las consultas en gráficos estadísticos

Para poder visualizar de modo gerencial y consolidado la información

ALTA

Fuente: Elaboración propia.

El significado de proceso de negocio es un conjunto de tareas cuyo objetivo es conseguir un resultado relevante y útil para el negocio [7]. Además, afirma que estas tareas suceden en el tiempo y permite ver la consecución de los objetivos de negocio en un histórico de datos. Con base en lo anterior y en los requerimientos pactados en el Product Backlog, los procesos de negocio estudiados fueron: Afiliaciones y Fallecimientos. Estos procesos son importantes para Servivir debido a que el núcleo del negocio se basa en las afiliaciones de los asociados a una entidad y los costos que generan los fallecimientos de personas que fueron vinculadas. Continuo a la identificación de procesos se obtuvieron los criterios de análisis: afiliado, convenio, plan exequial, entidad, pagaduría, género, y tiempo. Estos criterios coincidieron en ambos procesos con la diferencia del tiempo, ya que para afiliaciones el tiempo es la fecha de afiliación y para fallecimientos el tiempo es la fecha de fallecimiento del afiliado. Con estas relaciones se puede definir las métricas que hacen parte del proyecto.

Por otra parte, para identificar métricas fue necesario estudiar los procesos de negocio que actualmente sigue Servivir para evaluar los rendimientos que han tenido a través del tiempo en cuanto a afiliaciones y fallecimientos. Las métricas le proveen a los directivos datos concretos que ayudan en la toma de decisiones más rápidas y precisas para el crecimiento de la compañía. Las métricas son medidas cuantificables que permiten evaluar y monitorear los procesos de negocio así como su progreso hacia los objetivos de la empresa a corto, mediano o largo plazo [8]. En la Tabla 4 se muestra un resumen de métricas identificadas e implementadas en el cuadro de mando de la aplicación.

Tabla 4.
Listado de métricas.

Métricas seleccionadas para presentar en cuadro de mando

Métrica

Descripción

% de afiliados por entidad.

Se evalúa la cantidad de afiliados de una entidad sobre la cantidad total de empleados de la entidad.

% de afiliados por género.

Se evalúa la cantidad de afiliados dado su género (femenino o masculino) de una entidad sobre la cantidad de asociados de la entidad a Servivir.

% de afiliados por edad.

Se determina la cantidad de asociados de una entidad a Servivir por un rango de edad. Los rangos de edad establecidos por Servivir son:

- 0 a 30 años.

- Mayor a 30 y menor o igual a 40 años.

- Mayor a 40 y menor o igual a 60 años.

- Mayor a 60 y menor a 80 años.

- Mayor de 80 años.

% de afiliados por plan exequial.

% de asociados por plan exequial sobre la cantidad total de asociados de la entidad.

% de afiliados por convenio.

% de asociados por convenio sobre la cantidad total de asociados de la entidad.

% de fallecidos por entidad.

Con esta métrica se busca conocer el % de fallecidos de la entidad por el total de asociados de la entidad.

% de fallecidos por total de asociados.

Con esta métrica se busca conocer el % de fallecidos de la entidad por el total de asociados a Servivir.

Proyección de los fallecidos por entidad.

Se realiza una regresión lineal de los fallecidos para establecer los fallecidos en el siguiente año de operación.

Representación de costos de siniestros por entidad.

Costos de los fallecimientos atendidos por Servivir.

Fuente: Elaboración propia.

B. Diseño

Para el proyecto se crearon tres interfaces web: el ingreso, que permite al usuario ingresar al cuadro de mando; el registro, que permite crear un usuario y; el cuadro de mando, que permite visualizar los reportes y gráficos obtenidos a partir de las métricas descubiertas en el análisis del negocio. En la Fig. 2 se muestra el diseño del cuadro de mando.

Fig. 2. Diseño de cuadro de mando.
Fuente: Elaboración propia.

La arquitectura de la aplicación, como se observa en la Fig. 3, consta de una base de datos dimensional, que almacena la información depurada de los asociados de la empresa Servivir; una capa de datos, encargada de ejecutar las consultas a base de datos; una capa de negocio, que contiene el proceso ETL; los servicios web que proveen los datos para la capa de presentación; por último, la capa de presentación, permite al usuario consultar un cuadro de mando donde se pueden visualizar los datos a través de diferentes gráficas estadísticas.

Fig. 3. Arquitectura de la aplicación
Fuente: Elaboración propia.

Se creó un formulario para obtener información del test funcional, el cual tiene afirmaciones de los criterios de aceptación que el usuario califica con los adjetivos de cumplido o no cumplido. Las pruebas funcionales son relevantes para la evaluación de calidad de software, verificando el comportamiento del sistema de un modo dinámico; se basa en la selección de ejecuciones controladas [9]. La importancia de las pruebas funcionales radica en comprobar que lo desarrollado cumpla con las funciones para los cuales ha sido creado [10].

Para el test de usabilidad, se creó un formulario en el que especifican puntos para evaluar el grado en el que la aplicación le permite automatizar la recolección y el análisis de datos. Los métodos de valoración de usabilidad pueden dividirse en tres grupos: métodos de análisis, métodos de inspección y métodos de indagación. En el test de usabilidad de este proyecto se utilizó el método de indagación, puesto que la prueba se concentra en obtener información acerca del agrado, gustos, disgustos y expectativas sobre la aplicación web por parte de los usuarios. Para algunas investigaciones las pruebas de usabilidad como objetivo primordial, se basan en probar el diseño mediante una recolección de datos, para identificar y corregir las deficiencias que existan de acuerdo a la usabilidad [11].

Para la aplicación del test funcional y del test de usabilidad, se seleccionó como usuario final al director de gestión de calidad de la empresa Servivir, quien realizó la validación de la aplicación, para dar la aceptación del mismo.

C. Desarrollo

La aplicación desarrollada está soportada en una bodega de datos, que permite almacenar toda la información relevante sobre los afiliados activos y fallecidos. Una bodega de datos o Data Warehouse es una colección de datos, orientados a hechos relevantes del negocio, integrados, que incluyen el tiempo como característica importante de referencia y no volátiles para el proceso de toma de decisiones [12]. La bodega de datos contiene dos datamart: una para los asociados activos y otro para los asociados fallecidos. Un Datamart es una pequeña base de datos dentro de la bodega de datos, de la cual los usuarios pueden acceder fácilmente. La estructura de un Datamart se construyen para que las consultas de datos sean lo más simples posibles [13]. La bodega de datos se puede apreciar en la siguiente Fig. 4.

Fig. 4. Estructura de la bodega de datos Estructura de la bodega de datos.
Fuente: Elaboración propia.

En lo que respecta al proceso ETL, el resultado fue la extracción de la información referente a afiliaciones y fallecimientos desde la base de datos de Servivir. En la transformación se destaca el formateo de fechas de inicio de asociación y fecha de fallecimiento, cálculo de edades, separación de planes y convenios; por último, se ejecutó la carga de la información en las dimensiones y tablas de hechos correspondientes a afiliaciones y fallecimientos. ETL es una herramienta importante para extraer información del negocio, realizar el tratamiento y preparación de los datos y, la carga en la bodega de datos. En la Fig. 5 se visualiza el ETL generado para cargar la información en las tablas de hechos.

Fig. 5. Proceso total de ETL en Pentaho Data-integration.
Fuente: Elaboración propia.

La construcción de los servicios web permitió tener la lógica de negocio separada para cada uno de los requerimientos. Si las necesidades del negocio presentan una variación, la lógica del servicio afectado no causa ningún impacto a cualquier otro. Además, la respuesta de cada uno se da a través de formato JSON. JSON está diseñado para ser un lenguaje de intercambio legible por humanos, fácil de analizar y usar por las computadoras. Además, los servicios web hacen más fácil la comunicación de datos entre cliente y servidor.

Con el desarrollo de los servicios web se permite tener un proceso independiente que realice el cálculo de la predicción de fallecidos de Servivir para cada año de funcionamiento de los servicios exequiales. Se implementó el modelo de regresión lineal a través del modelo LinearRegression de la librería scikit-learn. El objetivo de la regresión lineal es descubrir la relación entre un conjunto de observaciones declaradas como X y la predicción en Y [14].

D. Pruebas

Se creó un documento de diseño de casos de prueba basado en el método de pruebas de particiones de equivalencia. Para la partición de equivalencia, el diseño de casos de prueba se crea teniendo en cuenta la evaluación de las clases de equivalencia para una condición de entrada; una clase de equivalencia representa un conjunto de estados válidos o inválidos. En el documento se describe la funcionalidad a evaluar, los criterios de aceptación, las opciones cumplen o no cumplen los criterios evaluados y, la casilla de observaciones para describir no conformidades que, aunque no afecten el funcionamiento de la aplicación, deben ser evaluados y corregidos posteriormente. En la Tabla 5 se muestra la estructura del documento creado con la funcionalidad consultar % de empleados de la entidad asociados a Servivir.

Tabla 5.
Resumen de documento de pruebas creado para el usuario.

Prueba funcional para usuario

Observaciones

Funcionalidad

Criterio de aceptación

Cumple

No cumple

Consultar el % de empleados de la entidad asociados a Servivir.

La consulta debe mostrar en % y cantidad numérica los asociados de la entidad.

X

 

 

La consulta debe mostrar en % y cantidad numérica los asociados de la entidad.

X

 

La consulta debe mostrar en % y cantidad numérica la población afiliada a Servivir versus la población total de la entidad.

X

 

Consultar la segmentación por edad de vinculados por entidad asociada.

La consulta debe mostrar el % y cantidad numérica de vinculados por entidad asociada dividida por rangos de edad.

X

 

 

Los rangos de edad a visualizar son:

0 < = 25 > 25 y < = 50 > 50 y < = 75 > 75.

X

 

Consultar la segmentación por género de vinculados por entidad asociada.

La consulta debe mostrar el % y cantidad numérica de vinculados por entidad asociada dividida por género (Masculino | Femenino).

X

 

 

Consultar el índice de siniestralidad de una entidad.

La consulta debe mostrar el % y la cantidad de fallecidos de la entidad asociada.

X

 

Fuente: Elaboración propia.

Contribuciones y Resultados

Con la metodología desarrollada se identificaron requerimientos, procesos de negocio y métricas que permitieron la construcción de la aplicación, generando una bodega de datos con dos datamart que almacenan la información relevante de los procesos seleccionados en la fase de análisis. Como se puede observar en la Fig. 6, se crearon gráficas que permiten visualizar la información consultada aplicando filtros de búsqueda por parte del usuario en el cuadro de mando.

Fig. 6. Aplicación web construida.
Fuente: Elaboración propia.

Luego de hacer el análisis de la información se encontró que la mayoría de vinculados se concentran en el rango de edad > 30 < = 50 años, equivalente al 46.3% de la población asociada a Servivir; seguido del rango de edad > 50 < = 70 años con el 32.5%. En cuanto a fallecimientos el rango de edad donde mayormente se presentan siniestros son los rangos > 70 años; seguido del rango >50 < =70. En la Fig. 7 se aprecian los rangos de edad para afiliados y fallecidos.

Fig. 7. Resultados por rango de edad afiliados y fallecidos.
Fuente: Elaboración propia.

En cuanto a los planes ofrecidos por Servivir, el plan Súper-Grupo Familiar presenta el mayor número de siniestros por fallecimiento, con un 61.7%; teniendo en cuenta que en este plan, se encuentra la mayor concentración de población. Por otra parte, se encontró que la entidad con mayor población vinculada a los planes exequiales, representa el 13.09% del total de fallecidos.

Otro comportamiento descubierto se refiere a las tres entidades con más asociados, los cuales acumulan el 23.1% de los asociados, lo cual podría representar un riesgo financiero si decidirán finalizar sus afiliaciones.

La función score, aplicada a la regresión lineal, arrojó una correlación de los datos de 83.23%, esto quiere decir, que la predicción del comportamiento de fallecimientos de Servivir es bastante confiable.

Se ejecutaron las pruebas funcionales y se encontraron las siguientes situaciones: al recuperar la clave la notificación que confirma que la clave fue modificada no es enviada y; en el reporte consultar el índice de siniestralidad frente a Servivir, se presenta información adicional que no debería aparecer. En la Tabla 6 se puede observar la cantidad de hallazgos contra la cantidad de casos exitosos.

Tabla 6.
Ejecución de pruebas

Casos creados

24

Casos ejecutados.

24

Errores encontrados (No conformidades).

2

Casos exitosos.

22

Fuente: Elaboración propia.

Los resultados de las pruebas funcionales se realizaron con el uso de indicadores de incidencias [15]. El primer indicador es la densidad de NC (no conformidades), la cual se obtiene a partir de la división entre las no conformidades descubiertas en las pruebas y los requerimientos ejecutados. Densidad NC =A/B, siendo A: No conformidades y B: Requerimientos ejecutados. Con base en lo anterior la aplicación tuvo una densidad de (1):

Frente a esto, se define que la aplicación no cumple con el 16.6% de las funcionalidades, lo cual refleja un desarrollo positivo, ya que se encuentra por debajo del 50%.

El segundo indicador es el cálculo de confiabilidad de la aplicación con base en la densidad NC identificada en cada una de las iteraciones de pruebas ejecutadas. El cálculo fue (2):

El resultado de la confiabilidad de la aplicación fue (3):

Por ende, la aplicación tiene confiabilidad del 83.4%, resultado positivo, ya que el valor mínimo esperado, especificado en los requerimientos orientados a la calidad del software, fue de 80%.

Como se puede apreciar en la Tabla 7, en el test funcional del usuario se validaron 12 funcionalidades. Se encontró que 10 cumplen al 100% los criterios de aceptación, esto indica que, el 83% de las funcionalidades trabajan correctamente. Los errores detectados no afectan el funcionamiento del aplicativo. También se detectó con este test una mejora para versiones futuras. Estos resultados también superan el esperado en calidad que se definió del 80%. En consecuencia, la aplicación fue aprobada a nivel funcional.

Tabla 7.
Medición cumplimiento de requerimientos.

Funcionalidad

Cumplimiento

Cantidad de errores / Observaciones

Iniciar sesión.

100%

0

Recuperar clave.

75%

3

Buscar una entidad asociada.

100%

0

Seleccionar año de inicio.

100%

0

Seleccionar año fin.

100%

0

Consultar el % de empleados de la entidad asociados a Servivir.

100%

0

Consultar la segmentación por edad de vinculados por entidad asociada.

100%

0

Consultar la segmentación por género de vinculados por entidad asociada.

100%

0

Consultar el índice de siniestralidad de una entidad.

100%

0

Consultar el índice de siniestralidad frente a Servivir.

50%

1

Consultar el costo del índice de siniestralidad de una entidad.

100%

0

Ver los resultados de las consultas en gráficos estadísticos.

100%

1

Fuente: Elaboración propia.

En el resultado del test de usabilidad, diligenciado por el director de gestión de calidad de Servivir, se evidenció que este estuvo “muy de acuerdo” en la facilidad del uso de aplicación; consideró como “de acuerdo” el diseño y distribución de los gráficos y filtros de búsqueda; estuvo “de acuerdo” en que los gráficos son fáciles de entender y; por último, “estuvo de acuerdo” en que la aplicación mejora los tiempos de entrega de resultados del análisis de datos, comparado con el proceso que realizan actualmente. Según el usuario, el proceso actual demora aproximadamente 4 horas y media y la aplicación emplea, en ambiente productivo, en promedio 3 minutos para arrojar los resultados.

La aplicación para la predicción del comportamiento de clientes dejó satisfecho al director de sistemas de gestión, confirmando así el cumplimiento a los objetivos del proyecto. Se considera la aplicación altamente funcional, con un alto grado de aceptación y satisfacción para el uso cotidiano en la empresa, en la Fig. 8 se muestra el test realizado al ETL.

Fig. 8. Evidencia del test al ETL.
Fuente: Elaboración propia.

Como resultado y para validar el tiempo en el que se ejecuta todo el proceso de extracción, transformación y cargue de información, el test arroja aproximadamente un minuto. En la Fig. 8, se presenta el tiempo que tarda el ETL en realizar el cargue en la base de datos dimensional.

Es importante mencionar que este proyecto coincide con otras investigaciones sobre el tema [16], [17] en las cuales se hace uso de la técnica de regresión lineal para predecir datos futuros relevantes con el fin de hacer uso de ellos en la toma de decisiones de una empresa. En otros estudios [18], consideran importante el uso de las pruebas de usabilidad para medir el nivel de aceptación y satisfacción de los usuarios de una aplicación. Del mismo modo, para algunos investigadores [19], manifiestan la importancia de ejecutar pruebas funcionales para asegurar que los requerimientos cumplen con lo pactado en los criterios de aceptación.

Conclusiones

La implementación de tecnologías enfocadas al análisis de datos son un factor clave que permite a las empresas garantizar una toma de decisiones ágil y confiable. Las aplicaciones orientadas al análisis de datos optimizan la utilización de recursos, y monitorean los procesos de negocio para obtener mejores resultados.

Implementar técnicas de regresión brinda una predicción de datos confiable dependiendo de la calidad de los datos con los que se entrena el modelo. Con el ingreso de nueva información íntegra, los resultados del modelo seguirán siendo confiables.

Con la realización de este proyecto se logró adquirir habilidades importantes sobre la aplicación de tecnologías que faciliten la recolección, el tratamiento y análisis de datos, lo cual representa una ventaja competitiva en el mercado laboral.

Para futuras versiones se puede crear un módulo de alertas basadas en reglas de negocio, para que la gerencia tenga conocimiento de posibles riesgos basados en el comportamiento de los datos. Este módulo enviaría las alertas por medio de correo electrónico del usuario.

Aunque la aplicación permite visualizar de forma gerencial el comportamiento de la población vinculada a Servivir, puede crecer su alcance, dado su desarrollo modular y se pueda aplicar a un posible crecimiento del portafolio de servicios de la compañía, como por ejemplo servicio exequial para mascotas, o como el mercado de seguros de vida.

Referencias

[1] D. F. Manotas, I. M. Ulloa & J. M. Uribe, “Modelación de riesgo operacional causado por factores demográficos”, Rev Ing, vol. 15, no. 29, pp. 113128, 2016. https://doi.org/10.22395/rium.v15n29a7

[2] K. Rostek, Business Intelligence for Insurance Companies, Found Manag, vol. 1, no. 1, pp. 6582, 2009. https://doi.org/10.2478/v10238-012-0005-z

[3] E. G. Maida & J. Pacienzia, “Metodologías de desarrollo de software”, tesis Licenciatura, dpto Sist Comp, UCA, CON, AR, 2015. Disponible en https://repositorio.uca.edu.ar/handle/123456789/522

[4] E. Bahit, Scrum & Extreme Programming para Programadores. BA, AR: SAFE, 2011. Recuperado de http://umh2818.edu.umh.es/wp-content/uploads/sites/884/2016/02/Scrum-y-eXtrem-Programming-para-programadores.pdf

[5] K. Schwaber & J. Sutherland, “La Guía de Scrum TM”, 2017. [Online]. Recuperado de https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Spanish.pdf

[6] K. Schwaber, What Is Scrum?, 2014. [Online]. Available: http://www.volaroint.com/wp-content/uploads/dlm_uploads/2014/03/DC-VOLARO-Training-Scrum-What_Is_Scrum.pdf

[7] S. Ramos, “Toma de requisitos para la creación de sistemas de BI: Procesos de Negocio (05)”, SolidQ Blogs, 2017. [Online]. Available: https://blogs.solidq.com/es/business-analytics/requisitos-procesos-de-negocio-business-intelligence-05/

[8] A. Muguira, ¿Qué es una métrica de negocio?, 2019. [Online]. Available: https://tudashboard.com/que-es-una-metrica-de-negocio/

[9] L. González, “Método para generar casos de prueba funcional en el desarrollo de software”, Rev. Ing, vol. 8, no. 15, Sup. 1, pp. 2936, 2009. Disponible en https://revistas.udem.edu.co/index.php/ingenierias/article/view/175

[10] J. C. Franco, “Metodología para testing de software basado en componentes”, proyecto grado, EAFIT, MD, CO, 2010. Disponible en https://repository.eafit.edu.co/handle/10784/413

[11] D. Shaw, Handbook of usability testing: How to plan, design, and conduct effective tests, JASIST, vol. 47, no. 3, pp. 258259, 1996. Available: https://asistdl.onlinelibrary.wiley.com/doi/10.1002/%28SICI%291097-4571%28199603%2947%3A3%3C258%3A%3AAID-ASI18%3E3.0.CO%3B2-%23

[12] W. H. Inmon, Building the data warehouse (2 ed.). NY, USA: John Wiley & Sons, 1996.

[13] D. Moody & M. A. Kortink, From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and Data Mart Design, Proceedings of the International Workshop on Design and Management of Data Warehouses, DMDW’2000, STH, SE, 5-6 Jun. 2000, pp. 112. Available: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-28/

[14] G. A. F. Seber & A. J. Lee, Linear Regression Analysis. NY, USA: Wiley, 2003.

[15] B. Florián, O. Solarte & J. Reyes, “Propuesta para incorporar evaluación y pruebas de usabilidad dentro de un proceso de desarrollo de software”, Rev EIA, vol. 7, no. 13, pp. 123141, 2010. Disponible en https://revistas.eia.edu.co/index.php/reveia/article/view/237

[16] W. Mayorga, “Determinantes macroeconómicos de los seguros de vida y personas”, Rev Fasecolda, no. 155, pp. 1823, 2013. Disponible en https://revista.fasecolda.com/index.php/revfasecolda/article/view/85

[17] L. Palacios-Cruz, M. Pérez, R. Rivas-Ruiz & J. Talavera, “Investigación clínica XVIII. Del juicio clínico al modelo de regresión lineal”, Rev Med Inst Mex Seguro Soc, vol. 51, no. 6, pp. 656661, 2013. Disponible en https://www.medigraphic.com/cgi-bin/new/resumen.cgi?IDARTICULO=46635

[18] B. Turan & H. Keser, “Museum Guide Mobile App: The Case of the Near East University Classical Car Museum”, Procedia Soc Behav Sci, vol. 131, pp. 278285, 2014. https://doi.org/10.1016/j.sbspro.2014.04.117

[19] J. Landicho, A. Perpetua, J. James, G. Balhin & R. Paid, “Hortari: a Gamification Application for Engaged Teaching and Learning in Higher Education”, J E-LKS, vol. 13, no. 1, pp. 181187, 2017. https://doi.org/10.20368/1971-8829/161

[20] Danger. (2019), Coplix. Available: http://www.coplix.co/danger/