1 Sistema de apoyo para la toma de decisiones en el proceso de selección de aspirantes a pilotos de Fuerzas Armadas, utilizando técnicas de Smart data Crisanto Caiza, Stalin Oswaldo y Lasso Ayala, Dany Fernando Departamento de Ciencias de la Computación Carrera de Ingeniería de Sistemas e Informática Trabajo de titulación, previo a la obtención del título de Ingeniero en Sistemas e Informática PhD. Cárdenas Delgado, Sonia Elizabeth 03 de febrero de 2022 2 Copyleaks ………..……………………… Cárdenas Delgado Sonia Elizabeth C.C:1713261160 3 DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA Certificación Certifico que el trabajo de titulación, Sistema de apoyo para la toma de decisiones en el proceso de selección de aspirantes a pilotos de Fuerzas Armadas, utilizando técnicas de Smart data fue realizado por los señores Crisanto Caiza Stalin Oswaldo y Lasso Ayala Dany Fernando el cual ha sido revisado y analizado en su totalidad por la herramienta de verificación de similitud de contenido; por lo tanto cumple con los requisitos legales, teóricos, científicos, técnicos y metodológicos establecidos por la Universidad de las Fuerzas Armadas ESPE, razón por la cual me permito acreditar y autorizar para que lo sustente públicamente. Sangolquí, 03 de febrero de 2022 ………..……………………… Cárdenas Delgado Sonia Elizabeth C.C:1713261160 4 DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA Responsabilidad de Autoría 5 DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA Autorización de publicación 6 Dedicatorias A mis padres Oswaldo y Mónica, por brindarme todo el inmenso apoyo desde el primer día para culminar mis estudios, por ser una parte fundamental en mi vida, por darme un ejemplo de esfuerzo y trabajo para conseguir los objetivos y, sobre todo, por ser el más grande ejemplo que tengo en mi vida. A mi hermana, por estar presente en mi día a día y brindarme apoyo en momentos difíciles. A mi familia, por la confianza depositada en mí, por siempre acogerme con un cálido abrazo y brindarme palabras de aliente a lo largo de este trayecto universitario. Stalin Crisanto El presente trabajo investigativo lo dedico a todo aquel que formó parte del camino, a las personas que hicieron posible lo imposible, principalmente a mis padres, Fernando y Laury, quienes brindaron desde el primer día su amor, trabajo y sacrificio; porque son un ejemplo de esfuerzo y dedicación para conseguir los objetivos, finalmente, su apoyo incondicional durante todos estos años ha dado frutos. A mi hermana, familiares y allegados por estar presentes en el día a día y brindarme apoyo en momentos difíciles, por ser un soporte moral y anímico que me brindaron a lo largo de esta etapa de nuestras vidas, por la confianza depositada, por siempre acogerme con un cálido abrazo y brindarme palabras de aliento a lo largo de este trayecto universitario. Dany Lasso 7 Agradecimientos Agradezco a Dios, por brindarme salud a lo largo de estos años. A mi padre, mi madre y mi hermana, porque son las personas más valiosas que tengo en mi vida. A mi directora de tesis, por la paciencia y el esfuerzo diario que, sin duda, permitió cumplir con el presente trabajo. A mi compañero de tesis, por el compromiso, trabajo y esfuerzo dedicado a lo largo del desarrollo del trabajo final. A mis amigos, con quienes compartí muchas experiencias y sin nada a cambio, me abrieron un espacio en su vida y brindarme su amistad. Stalin Crisanto Quiero expresar mi gratitud por la confianza que me brindaron, por el conocimiento concedido, porque gracias a todo ello se consiguió finalizar este trabajo. Un agradecimiento especial a mis padres ya que sin ellos esto no hubiese sido posible, y ayuda fue fundamental en toda mi trayectoria universitaria. También, quiero agradecer a la Universidad de las Fuerzas Armadas - ESPE, directivos, docentes, en especial a la directora de tesis, la Ing. Sonia E. Cárdenas Delgado, Ph.D., principal colaborador durante todo este proceso quien, con su dirección, paciencia, enseñanzas y el esfuerzo diario permitió cumplir con el presente trabajo. Finalmente, quiero expresar mi agradecimiento sincero a nuestros familiares y allegados, la culminación de este trabajo fue gracias a todos los factores, recursos, experiencias y consejos que nos han brindado. Dany Lasso 8 Índice de contenidos Portada…………………………………………………………………………………………...1 Copyleaks ..................................................................................................................... 2 Certificación .................................................................................................................. 3 Responsabilidad de Autoría ........................................................................................ 4 Autorización de publicación ........................................................................................ 5 Agradecimientos .......................................................................................................... 7 Índice de contenidos .................................................................................................... 8 Índice de tablas ...........................................................................................................10 Índice de figuras ..........................................................................................................10 Resumen ......................................................................................................................12 Abstract ........................................................................................................................13 Capítulo I ......................................................................................................................14 Introducción .................................................................................................................14 Antecedentes ...........................................................................................................14 Planteamiento del problema ...................................................................................15 Justificación .............................................................................................................17 Objetivos ..................................................................................................................18 Objetivo general ...................................................................................................18 Objetivos específicos ...........................................................................................18 Alcance .....................................................................................................................19 Capítulo II .....................................................................................................................23 Marco Teórico ..............................................................................................................23 Ingeniería del conocimiento ....................................................................................23 Etapas ...................................................................................................................23 Aplicaciones .........................................................................................................23 Sistemas de apoyo a la toma de decisiones ..........................................................24 Objetivos y beneficios .........................................................................................25 Clasificación .........................................................................................................26 Arquitectura ..........................................................................................................27 Big data y Smart data ..............................................................................................28 Definición de Smart Data .....................................................................................28 Método para obtener datos inteligentes .............................................................29 Técnicas de análisis de datos .................................................................................29 9 Reglas de inferencia .............................................................................................30 Reglas de asociación ...........................................................................................30 Aprendizaje Automático.......................................................................................30 Algoritmos genéticos ...........................................................................................31 Bases de datos no relacionales ..............................................................................31 Características ......................................................................................................31 Categorías .............................................................................................................32 MongoDB ..................................................................................................................35 Pruebas visuales ......................................................................................................36 Test de ishihara ....................................................................................................36 Test de Lang .........................................................................................................38 Test de titmus .......................................................................................................39 Metodología de Desarrollo ......................................................................................39 Equipo Scrum .......................................................................................................40 Elementos de Scrum ............................................................................................40 Eventos de Scrum ................................................................................................41 Proceso scrum .....................................................................................................42 Herramientas ............................................................................................................43 Software ................................................................................................................43 Capítulo III ....................................................................................................................46 Desarrollo de la aplicación .........................................................................................46 Metodología de desarrollo ......................................................................................46 Requisitos del sistema ............................................................................................47 Recopilación de información ...............................................................................47 Especificación de requisitos ...............................................................................48 Diseño del sistema ..................................................................................................49 Diagramas y especificación de casos de uso ....................................................49 Diseño de interfaces para el aplicativo web .......................................................55 Diseño de la base de datos ..................................................................................61 Diseño de la arquitectura .....................................................................................64 Definición de reglas .................................................................................................64 Capítulo IV ...................................................................................................................68 Validación del prototipo ..............................................................................................68 Protocolo de pruebas ..............................................................................................68 Proceso previo .....................................................................................................69 10 Pruebas clásicas ..................................................................................................70 Tareas virtuales ....................................................................................................73 Validación de las recomendaciones .......................................................................73 Análisis de Resultados ............................................................................................79 Cuestionarios .......................................................................................................79 Evaluación de la usabilidad .................................................................................80 Capítulo V ....................................................................................................................83 Conclusiones y recomendaciones .............................................................................83 Conclusiones ...........................................................................................................83 Recomendaciones ...................................................................................................84 Bibliografía...................................................................................................................85 Índice de tablas Tabla 1 Valoración de láminas de Ishihara ........................................................................... 37 Tabla 2 Equipo Scrum .............................................................................................................. 46 Tabla 3 Rango de prioridad de las historias de usuario ...................................................... 47 Tabla 4 Historias de usuario .................................................................................................... 48 Tabla 5 Especificación de requisitos del sistema ................................................................. 48 Tabla 6 Descripción caso de uso Iniciar sesión .................................................................... 51 Tabla 7 Descripción del caso de uso Administrar Usuarios ............................................... 52 Tabla 8 Descripción del caso de uso realizar tarea virtual ................................................. 53 Tabla 9 Descripción del caso de uso realizar prueba clásica ............................................. 54 Tabla 10 Descripción del caso de uso generar reportes ..................................................... 55 Tabla 11 Porcentajes para la prueba clásica de Lang ......................................................... 65 Tabla 12 Porcentajes para prueba clásica de ishihara ........................................................ 65 Índice de figuras Figura 1 Arquitectura de un sistema de apoyo a la toma de decisiones ......................... 27 Figura 2 Categoría NoSQL Tipo clave - valor....................................................................... 33 Figura 3 Categoría NoSQL almacenamiento en columnas ................................................ 33 Figura 4 Categoría NoSQL basada en gráficos .................................................................. 34 Figura 5 Categoría NoSQL Orientado a documentos ......................................................... 35 Figura 6 Ejemplo de documento ............................................................................................. 35 Figura 7 Ejemplo de colección ................................................................................................ 36 Figura 8 Ejemplo de lámina del test de ishihara .................................................................. 37 11 Figura 9 Lámina 1 de test de Lang ......................................................................................... 38 Figura 10 Lámina II de test de Lang ...................................................................................... 38 Figura 11 Test de titmus .......................................................................................................... 39 Figura 12 Proceso de scrum ................................................................................................... 43 Figura 13 Actores que intervienen en el sistema ................................................................. 50 Figura 14 Caso de uso Iniciar sesión ..................................................................................... 50 Figura 15 Caso de uso Administrar usuarios ........................................................................ 51 Figura 16 Caso de uso realizar tarea virtual ......................................................................... 52 Figura 17 Caso de uso prueba clásica .................................................................................. 54 Figura 18 Caso de uso generar reportes .............................................................................. 55 Figura 19 Interfaz inicio de sesión .......................................................................................... 56 Figura 20 Interfaz de pacientes .............................................................................................. 57 Figura 21 Interfaz de pruebas ................................................................................................. 58 Figura 22 Interfaz de pruebas tradicionales .......................................................................... 58 Figura 23 Interfaz de ingreso de resultados ......................................................................... 59 Figura 24 Precuestionario en pruebas virtuales ................................................................... 60 Figura 25 Interfaz para subir resultados de tareas virtuales .............................................. 60 Figura 26 Interfaz cuestionario de usabilidad ....................................................................... 61 Figura 27 Diseño de la base de datos ................................................................................... 62 Figura 28 Arquitectura del sistema ......................................................................................... 64 Figura 29 Protocolo de pruebas ............................................................................................ 69 Figura 30 Lectura del consentimiento informado por parte del paciente ......................... 69 Figura 31 Firma del consentimiento informado .................................................................... 70 Figura 32 Aplicación de prueba Lang .................................................................................... 71 Figura 33 Aplicación de prueba Ishihara ............................................................................... 71 Figura 34 Aplicación del pre cuestionario ............................................................................. 72 Figura 35 Aplicación del cuestionario de usabilidad ............................................................ 72 Figura 36 Opción para registrar paciente .............................................................................. 73 Figura 37 Formulario de datos para un nuevo paciente ..................................................... 74 Figura 38 Registro de resultados de la prueba de Lang ..................................................... 74 Figura 39 Registro de resultados de la prueba de Ishihara ............................................... 75 Figura 40 Resultados almacenados en la base de datos ................................................... 75 Figura 41 Registro de resultados de las pruebas virtuales ................................................ 76 Figura 42 Opción del sistema para visualizar las recomendaciones ................................ 77 Figura 43 Pantalla de recomendaciones ............................................................................... 77 Figura 44. Reporte generado por el sistema ....................................................................... 78 Figura 45 Resultados de los cuestionarios aplicado antes de las tareas virtuales ........ 79 Figura 46 Resultados del cuestionario aplicado después de las tareas virtuales .......... 80 Figura 47 Promedio de respuestas de la usabilidad del sistema ...................................... 81 Figura 48 Gráfico de medias cuestionarios de usabilidad .................................................. 82 12 Resumen En la actualidad, los sistemas de apoyo a la toma decisiones se han convertido en una herramienta importante en diferentes ámbitos. Este tipo de herramientas tecnológicas requieren ser implementadas en las escuelas de aviación de las Fuerzas Armadas del Ecuador, específicamente en las pruebas visuales que se realizan como parte del proceso de selección de aspirantes a pilotos. En este sentido, el presente trabajo muestra el desarrollo de un aplicativo que facilita el registro de datos personales, los resultados de las diferentes pruebas visuales (tradicionales y tecnológicas), documentos y cuestionarios aplicados a los aspirantes durante el proceso de evaluación visual. Los datos se integran en una base de datos NoSQL. La información es analizada mediante técnicas de Smart data y reglas asociativas. El proceso de validación del aplicativo se llevó a cabo siguiendo el protocolo de pruebas establecido en el proyecto. Los resultados fueron validados por el especialista en oftalmología. También, se registraron datos de procesos anteriores para validar los reportes generados por el aplicativo, y los resultados fueron favorables en apoyo a la toma de decisiones que brinda la herramienta. Los especialistas participantes puntuaron la funcionalidad y usabilidad del aplicativo con una media de 4.82/5. La herramienta podría ser implementada para sustentar las decisiones, reducir la subjetividad y evitar posibles novedades de aspecto legal dentro del proceso de selección de aspirantes. Palabras claves:  TOMA DE DECISIONES  SMART DATA  REGLAS DE ASOCIACIÓN  PRUEBAS VISUALES 13 Abstract Currently, decision support systems have become an important tool in different environments. These types of technological tools need to be implemented in the aviation schools of the Ecuadorian Armed Forces, specifically in the visual tests that are carried out as part of the selection process for aspiring pilots. In this sense, the present work shows the development of an application that facilitates the registration of personal data, the results of the different visual tests (traditional and technological), documents and questionnaires applied to the applicants during the visual evaluation process. The data is integrated into a NoSQL database. The information is analyzed using Smart data techniques and associative rules. The validation process of the application was carried out following the test protocol established in the project. The results were validated by the specialist in ophthalmology. Also, data from previous processes were recorded to validate the reports generated by the application, and the results were favorable in support of decision-making provided by the tool. Military personnel and specialists scored the functionality and usability of the application with an average of 4.63/5. The tool could be implemented to support decisions, reduce subjectivity, and avoid possible novelties of a legal aspect within the applicant selection process. Keywords:  DECISION MAKING  SMART DATA  ASSOCIATION RULES  VISUAL TESTS 14 Capítulo I Introducción Antecedentes La toma de decisiones por parte de los especialistas es un proceso que se puede realizar mediante el apoyo de herramientas tecnológicas a partir de diferentes técnicas como el razonamiento deductivo, análisis de datos, aprendizaje de máquina, entre otros. Los sistemas de soporte a las decisiones, han tenido una gran evolución desde la década de los 70’s. En la actualidad, este tipo de sistemas, cuenta con una gran variedad de opciones que se han convertido en una herramienta importante en la que los especialistas pueden respaldarse para mejorar sus diagnósticos. (Silva & Falappa, 2015) Por otra parte, Smart Data se ha convertido en una herramienta fundamental para la toma de decisiones dentro de las organizaciones. Sin duda, disponer de un almacenamiento eficiente de los datos para obtener un tiempo de respuesta aceptable se ha vuelto un bien necesario en las instituciones (Gourav, Rinkle, & Himanshu Aggarwal, 2018). Los datos que son generados en el ámbito de la salud, están relacionados con los pacientes, medicamentos, enfermedades, diagnósticos, investigación, entre otros. Los macrodatos tienen que ver con los datos clínicos del paciente, de igual manera los sistemas de apoyo a las decisiones clínicas que pueden ser: informes, recetas, imágenes médicas, adquisiciones en farmacia, seguros, entre otros datos que son de carácter administrativo. También encontramos datos de registros electrónicos de pacientes o EHR por sus siglas en inglés; incluso, no está por demás mencionar que hoy en día, los datos son generados por sensores biométricos, por las redes sociales, 15 blogs, sitios web y otras plataformas (Instituto Europeo de Salud y Bienestar Social, 2021). Hasta donde se conoce, en el Ecuador todavía no se dispone de datos en diferentes ámbitos como la medicina, educación, situación social de la niñez y las familias, gestión del transporte e inclusive para seguridad social o el clima; situación que ha limitado el desarrollo de estudios, investigación, desarrollo de aplicaciones y la búsqueda de soluciones para el apoyo a la toma de decisiones. En este contexto, el presente trabajo pretende contribuir en el desarrollo de una herramienta tecnológica que integre los datos de las diferentes pruebas visuales y su respectivo análisis para apoyar en la toma decisiones del médico especialista en el momento de identificar deficiencias visuales en el personal de aspirantes a pilotos de las Fuerzas Armadas del Ecuador. Además, con este trabajo se pretende contribuir en el desarrollo de un proyecto de investigación liderado por el Departamento de Ciencias de la Computación en la Universidad de las Fuerzas Armadas ESPE, en coordinación con el Hospital de Especialidades de FF.AA. Nro. 1 y el Centro de Investigación de Aplicaciones Militares CICTE. Planteamiento del problema En Aeronáutica, la visión constituye uno de los sentidos más importantes que debe poseer un piloto profesional. Para pilotar aeronaves se requieren todas y cada una de las cualidades de la visión, por lo que es necesario evaluar la agudeza visual, la amplitud de campo visual, la visión de profundidad, la visión normal de colores y la capacidad de adaptación retiniana. Desde esta perspectiva, las escuelas de aviación de las Fuerzas Armadas del Ecuador, no disponen de una herramienta tecnológica que integre la data de las diferentes pruebas de evaluación visual que son aplicadas dentro del proceso de selección de aspirantes a pilotos. 16 Esta situación, ha generado una serie de inconvenientes en el proceso, debido a que no se disponen de reportes a partir del análisis de datos, en varias ocasiones la toma de decisión para dicho proceso de ingreso a las escuelas de aviación carece de datos y análisis de la información resultante de las diferentes evaluaciones que se realizan. Esto sin duda ocasiona problemas a los evaluadores, ya que no cuentan con un apoyo adecuado que les permita sustentar las decisiones, mediante evidencias para evitar novedades, especialmente en el aspecto legal. Por ello, se requiere la configuración de un repositorio digital que permita generar información de valor, útil para el análisis y la toma de decisiones por parte de los especialistas. Por otra parte, en la actualidad existe un sinnúmero de herramientas que permiten utilizar Smart data, sin embargo, no todas estas herramientas se acoplan a los requerimientos que se pueda tener al desarrollar un sistema, es por eso también que se busca adecuar las herramientas más óptimas para el desarrollo de un sistema de apoyo a las decisiones. El problema identificado consiste en que la información que se genera producto de las evaluaciones oftalmológicas a los aspirantes a pilotos durante el proceso de selección no es almacenada y organizada en un repositorio digital, no se dispone de reportes que emitan recomendaciones o sugerencias y que apoyen para el proceso de selección de aspirantes a pilotos de las Fuerzas Armadas. Además, hace falta analizar la información para identificar patrones, tendencias o predicciones acerca de los resultados y las decisiones tomadas cuando se emiten los resultados con la idoneidad o no de ingresar a la escuela de formación para pilotos. En base a la problemática descrita, se plantea desarrollar una herramienta tecnológica que permita apoyar en el proceso de toma de decisiones por parte de los especialistas para con los aspirantes a pilotos previo al ingreso a las escuelas de aviación de las Fuerzas Armadas. 17 Justificación Las herramientas tecnológicas permiten que la información pueda ser registrada en sistemas especializados y almacenada de varias formas. Con la ayuda de las técnicas de Smart Data se está logrando un mejor manejo de la información no solo respecto al almacenamiento, sino a la toma de decisiones. Es importante mencionar que los sistemas de apoyo a la toma de decisiones han ido evolucionando junto con la aparición de nuevas herramientas y enfoques tecnológicos, lo que ha permitido que varias instituciones y organizaciones se planteen o ya implementen este tipo de sistemas. En este sentido, y como parte de un proyecto de investigación que lidera el Departamento de Ciencias de la Computación de la Universidad de las Fuerzas Armadas ESPE, se propone contribuir con el desarrollo de una herramienta tecnológica aplicando Smart Data que permita apoyar las decisiones a los especialistas en el proceso de ingreso para el personal de aspirante a pilotos de las Fuerzas Armadas del Ecuador y así contribuir en la seguridad en las operaciones aéreas. Se pretende crear repositorios de datos que integre los resultados de todas las pruebas visuales que se realizan a los aspirantes a pilotos y aplicar técnicas de análisis de datos a partir de los conocimientos y experticia de los profesionales especialistas en el ámbito de la visión. Esto permitirá ofrecer diagnósticos oportunos y mitigar la subjetividad en el momento de determinar qué aspirante tiene o no las cualidades de su visión apta para pilotar aeronaves. Además, se podrán disminuir la cantidad de solicitudes de revisión o subsanación que presentan los aspirantes luego de recibir los resultados, lo que beneficiará en la mejora del proceso y la credibilidad de los resultados. 18 El presente trabajo ha sido propuesto con el fin de apoyar a los médicos especialistas en la toma de decisiones en el ámbito oftalmológico, para mejorar el proceso de selección de aspirantes a pilotos de las escuelas de aviación de las Fuerzas Armadas. Este proyecto beneficia a los médicos especialistas y los aspirantes a pilotos de Fuerzas Armadas que podrán hacer uso del sistema. Los médicos dispondrán de una herramienta de apoyo a la toma decisiones y los aspirantes a pilotos tendrán evaluaciones menos subjetivas. El presente estudio también se enfocará en las distintas herramientas que permite el almacenamiento, tratamiento y posterior valor agregado que se le pueda dar a los datos mediante la aplicación de técnicas de Smart Data en apoyo a la toma de decisiones. Objetivos Objetivo general Implementar una herramienta tecnológica de apoyo para la toma de decisiones en el proceso de selección de aspirantes a pilotos de Fuerzas Armadas, mediante la utilización de técnicas de Smart Data y el análisis de los datos obtenidos en las diferentes pruebas de evaluación visual que se realizará previo al ingreso a las escuelas de aviación. Objetivos específicos  Diseñar una solución orientada al Smart Data, tomando los resultados de las pruebas visuales y los requerimientos definidos con los especialistas y técnicos en aviación, con el fin de apoyar en el proceso de selección de aspirantes a pilotos.  Desarrollar la solución de Smart data por reglas de inferencia como técnica de análisis de datos, peticiones API REST y HTTP como protocolos de comunicación y recepción de información con el fin de recolectar los datos 19 generados en las pruebas visuales y registrarlos en una base de datos NoSQL, generando información con un valor agregado.  Validar los resultados obtenidos del estudio basados en los criterios y recomendaciones de los médicos especialistas del HE Nro.1 de las FF.AA. en forma conjunta con investigadores del proyecto y técnicos de aviación, con el fin de demostrar la validez de la solución propuesta, se realizan pruebas en personal militar aspirante a pilotos en una muestra seleccionada por los especialistas. Alcance Para cumplir con los objetivos planteados del presente trabajo, se plantea las siguientes fases: Investigación del problema. Mediante reuniones de trabajo con los especialistas se analizan los procesos que siguen los especialistas al momento de tomar una decisión, basada en las pruebas visuales que se aplican a los aspirantes. También, se realiza un estudio para conocer herramientas y técnicas que se pueden aplicar en el desarrollo de este tipo de aplicativo en el ámbito de los sistemas de apoyo en la toma de decisiones. El entregable de esta fase serán los requerimientos y las reglas de asociación que se deben aplicar para el análisis de la data. Concepción y diseño de la solución. Partiendo de la anterior fase, se continua con una concepción global de la solución. De tal forma que se pueda diseñar a detalle los procesos, componentes y algoritmos que se requieren para brindar una alternativa de solución al problema identificado. Se realiza un breve análisis referente a los distintos tipos de pruebas que son aplicadas a los aspirantes a pilotos en la Fuerza Aérea, con el fin de proponer una norma de comunicación tomando en cuenta que datos son estrictamente 20 necesarios(datos estructurados) y que otros datos son propios de cada prueba (datos no estructurados), es decir, el sistema no estará acoplado a ciertas pruebas específicas, por el contrario, las diferentes pruebas podrán enviar sus datos de manera no estructurada y el sistema normalice y analice los datos en conjunto; de igual manera se define el aporte de cada prueba en la toma de decisiones. A continuación, se conceptualizar el vocabulario o simbología que usan los médicos especialistas del HE Nro.1 de las FF.AA. en el proceso, puesto que los informes y/o resultados del sistema están dirigidos a ellos. Es importante generar una abstracción y representación del análisis que realizan los médicos especialistas al momento de la toma de decisiones. En el proyecto se diseñan los algoritmos que se ejecutan para el análisis de datos. Dichos algoritmos en esta fase se encuentran a un alto nivel, es decir, serán representados por diagramas de decisión. El entregable de esta fase será la arquitectura de la solución a nivel de componentes (aplicativos, comunicación, usuarios) y los diagramas que utilizan los especialistas al momento de la toma de decisiones. Construcción de la solución. En base a lo generado en la fase 2, se desarrollará la solución, basado en la filosofía del Business Intelligence (Pinos & Villavicencio, 2007) que implementa los siguientes pasos: Recopilación y recepción de datos. Se utilizará la arquitectura API REST de forma que permita la comunicación e intercambio de datos, los cuales tendrán el formato JSON o archivos planos de manera que permita una lectura adecuada y posterior almacenamiento de la información. Las APIs generadas recibirán los datos que se establezca en la norma de comunicación generada en la fase 2. 21 Carga de los datos Se diseñará y creará una base de datos NoSQL que permita la persistencia de los datos de todos los módulos de pruebas visuales (tradicionales y no tradicionales) que se integran en el sistema, para lo cual se utilizará MongoDB porque es una base de datos orientada a documentos. Permite ampliar los tipos de datos que son almacenados en la base, esto debido a que, en las bases de datos no relacionales, no es requisito el seguir un esquema definido. Exploración de datos Mediante lenguajes de programación como Python, se va a explorar los datos enviados de las pruebas visuales, aplicando los criterios mencionados por los médicos especialistas. Mediante el uso de técnicas como las reglas de asociación. Descubrimiento de patrones y tendencias Tomando los datos enviados del aspirante y los históricos almacenados se procederá buscar patrones y tendencias mediante las reglas de asociación para encontrar hechos en común. Reportería y visualización de la información Se creará la interfaz web de usuario para: las consultas, generación de reportes que desplieguen el análisis de datos, mediante la biblioteca de interfaces React, la cual permite construcción de interfaces, se basa en componentes y cuenta con un sinnúmero de módulos que hacen al desarrollo mucho más estable. Evaluación de la Solución. Con el fin de evaluar la validez de la solución. Se aplican pruebas visuales tradicionales y tecnológicas en una muestra seleccionada por los especialistas, grupo control que incluye personal militar aspirante a pilotos de diferentes ramas de las Fuerzas Armadas. Dichas pruebas se realizan en forma conjunta con investigadores del proyecto, médicos especialistas del HE Nro.1 de las FF.AA. aspirantes y desarrolladores. Finalmente, se analizan los resultados obtenidos 22 del estudio basados en los criterios y recomendaciones de los especialistas y del protocolo establecido, con el fin de demostrar la validez de la solución propuesta. 23 Capítulo II Marco Teórico En este capítulo se describen los fundamentos teóricos en los que se basa el desarrollo de este trabajo. Ingeniería del conocimiento La Ingeniería del conocimiento es un área de la Inteligencia Artificial, que incorpora procesos de razonamiento de un experto para ser emulados en un sistema software con el fin de generar respuestas a problemas reales. Los sistemas basados en conocimiento incluyen conocimientos, reglas y formas de razonamiento, su objetivo es comprender de mejor manera el proceso de toma de decisiones (Sadiku et al., 2017). Etapas De acuerdo a Sadiku et al. (2017), la ingeniería del conocimiento está compuesta por 4 fases que se describen a continuación:  Adquisición de conocimientos: proceso para extraer conocimientos de una persona experta en un dominio determinado e integrar en un sistema.  Conocimiento administrativo: proceso donde se organiza la información, de forma que pueda ser aprovechada de forma efectiva, aplicando estándares y una gestión eficaz de la información.  Descubrimiento del conocimiento: proceso de análisis de la información obtenida, con la finalidad de encontrar conocimientos relevantes.  Difusión del conocimiento: este proceso está relacionado con extraer el conocimiento relevante identificado. Aplicaciones Esta área es crucial dentro de cualquier organización que tiene por objetivo juntar la experiencia con conocimientos técnicos. Otra de las aplicaciones importantes 24 es el reconocimiento de patrones y el procesamiento de imágenes. Debido a la evolución de las tecnologías de la información, empiezan a surgir otros campos de aplicación para la Ingeniería del conocimiento como el big data, smart data, minería de datos, etc (Sadiku et al., 2017). Sistemas de apoyo a la toma de decisiones Un sistema de apoyo a la toma de decisiones (DSS – Decision Support System, por sus siglas en inglés) son sistemas de información que tienen como objetivo, apoyar las actividades referentes a la organización, institución o del ámbito empresarial, los cuales, de cierto modo, tienen que ver con el proceso de tomas de decisiones. Un DSS, es un software que necesita de uso constante de un usuario para ejecutarse y que por lo general se desarrolla sobre las bases de los sistemas. Por otra parte, los DSS son considerados como activos de conocimiento ya que proporción más de una manera de generar sugerencias o recomendaciones (Shahsavarani et al., 2015). Los sistemas de apoyo a la toma de decisiones, deben proveer una solución adecuada, siempre que esté basada en el conocimiento de los expertos, además, la información que se utilice para este fin, debe ser una información específica que esté relacionada con el problema que se intenta resolver. De acuerdo a (García, Tortajada, & Sáez, 2019), los DSS deben tener las siguientes características: Manejo adecuado de la incertidumbre. Un problema en torno a las decisiones, es que suelen tener información incompleta ya que, de forma inmediata, no se puede saber con certeza qué resultados se va a lograr, sino que simplemente se pueden distinguir los antecedentes en los que se basó la mencionada decisión. 25 Claro en el problema a resolver. La problemática debe estar clara y específica, esto permitirá una mayor utilidad y fiabilidad del sistema de apoyo a la toma de decisiones. Resultados fiables. La fiabilidad es una de las características más importantes de un sistema de apoyo a la toma de decisiones, más aún cuando es un sistema de uso continuo; es por ello que las evaluaciones deben ser de forma dinámica y siempre actualizando la base de conocimientos y el flujo de decisiones implementadas. Mantenerse actualizado. Los sistemas de apoyo a la toma de decisiones, tienen una amplia gama de posibilidades para un uso estable en el futuro, pero las características del sistema, pueden ser mejoradas mediante la adaptación continua al medio en el que se encuentre funcionando, tomando en cuenta todos los cambios que se van dando en el camino. Objetivos y beneficios Uno de los objetivos más importantes que tienen los sistemas de apoyo a la toma de decisiones, es el hecho de brindar un soporte a las personas o profesionales en cualquier ámbito, a tomar una decisión cuando se enfrenten a problemas semiestructurados, en lugar de que las decisiones se realicen solo por la experiencia de la persona. En cuanto a los beneficios, Shahsavarani et al. (2015), menciona los siguientes:  Ahorro de gastos y tiempo  Capacidad para realizar análisis sin precedentes  Mejor uso de los recursos  Capacidad para responder rápidamente a situaciones inesperadas.  Ampliación de las opciones examinadas 26  Ampliación de las opciones disponibles  Crear nuevos puntos de vista  Proporcionar un nuevo aprendizaje  Desarrollo y facilitación comunicación profesional  Proporcionar control  Mejorar las decisiones  Facilitar el trabajo en equipo en el personal Clasificación De acuerdo a Greenes (2014) los sistemas de apoyo se clasifican de la siguiente manera:  Sistema de apoyo basado en el conocimiento: este tipo de sistema consta de 3 partes que son: base de conocimientos, implica las reglas y unión de datos que por lo general se presentan en forma de reglas “si-entonces”; motor de inferencia, usa la base de conocimiento para aplicar reglas y sintetizar los datos existentes mediante la lógica, y posteriormente generar nueva información; finalmente, el mecanismo de comunicación que permite la entrada y salida de datos.  Sistemas de apoyo no basados en el conocimiento: estos sistemas utilizan el aprendizaje automático, es así que las computadoras pueden utilizar las experiencias pasadas para generar nuevo conocimiento o aprendizaje por si solas. Este tipo de sistemas son desarrollados a partir de redes neuronales o algoritmos genéticos. 27 Arquitectura Un sistema de apoyo a la toma de decisiones consta de cuatro componentes principales, que son: 1) base de datos o base de conocimientos, 2) modelo, 3) la interfaz de usuario y 4) los usuarios (Jain, 2016). Figura 1 Arquitectura de un sistema de apoyo a la toma de decisiones Nota: Arquitectura planteada para un sistema de apoyo a la toma de decisiones. Tomado de: https://www.ibm.com/docs/es/spss-modeler/SaaS?topic=dm-crisp-help- overview, por IBM. Base de datos. Es una representación organizada de datos, los cuales se encuentran almacenados en forma digital y organizados de manera que permitan una representación de la realidad, apoyando a los procesos que necesitan o requieren de dichos datos, los cuales deben tener un nivel de gestión y calidad haciendo uso de un sistema de administración de base de datos (DBMS). Modelo. Hace referencia a una representación de una necesidad en un contexto específico, el cual permite que sea una pauta para ser imitada o reproducida. 28 Interfaz. Es un sistema que permite la interacción de los usuarios con las máquinas, los cuales incluyes componentes tanto de hardware como de software, que en conjunto permiten un manejo adecuado de los sistemas. Usuarios. Personas que manejan o utilizan el software o hardware especializados en cierto contexto. Big data y Smart data Big data es una solución tecnológica aplicada en las organizaciones, con la finalidad de mejorar procesos importantes como la toma de decisiones; para que Big data pueda tener una amplia efectividad, se requiere una gran cantidad de datos. Bajo este contexto, los datos no son de un nivel adecuado en cuento a su calidad para poder procesarlos y generar información importante, dando resultados poco útiles. Smart data, implica la necesidad de gestionar el valor de los datos, de forma que puedan ser procesados, sin necesidad de un gran volumen o cantidad. Implica también, herramientas, procesos y metodologías que permitan procesar dichos datos hasta el usuario final y brindar una información adecuada (Baldassarre et al., 2018). Definición de Smart Data Smart data es el conjunto de técnicas y métodos que permite extraer el valor de los datos, con la finalidad de proveer datos de calidad a los sistemas de apoyo a la toma de decisiones. También, es la manera en que se puede analizar o correlacionar diferentes fuentes de datos (Iafrate, 2015). A diferencia del big data, que necesita de una gran cantidad de datos, Smart data tiene como premisa que un conjunto pequeño de datos limpios, puede brindar más ideas valiosas y aportar más que un volumen grande (Faraway & Augustin, 2018). Smart data se centra en la veracidad y valor de los datos, con la finalidad de destacar datos importantes, que puedan ser aprovechados en una organización. Se definen tres atributos importantes que son (García-Gil et al., 2017): 29  precisión: los datos se deben ajustar completamente a su definición para impulsar su valor.  procesamiento: con ayuda de los datos, se debe maximizar los objetivos de la organización.  ágil: hace referencia a la disponibilidad de datos en tiempo real y deben permitir ajustarse a ambientes que cambian. Método para obtener datos inteligentes Baldassarre et al. (2018) proponen una metodología basada en el ciclo PDCA (planear, hacer, verificar y actuar). Planificación del análisis de datos: En esta primera fase, se definen los objetivos que se va a alcanzar con el análisis, basándose en los objetivos de la organización; también se definen las fuentes de donde van a surgir los datos. Definir reglas de análisis: Para esta fase, se toman como recursos los datos y los objetivos definidos en la fase anterior. La principal tarea es que los objetivos presentados puedan ser transformados en reglas para brindar una calidad adecuada a los datos. Control de calidad de datos: El objetivo de esta fase es evaluar la calidad de los datos, junto con las reglas definidas en la fase 2. Los datos que no son procesados son medidos en términos de calidad, haciendo una comparación con las reglas de análisis, posteriormente los resultados, se evalúan de acuerdo a los objetivos definidos por la organización. Técnicas de análisis de datos Hoy en día, analizar datos para generar información útil y valiosa, se ha convertido en una de las principales tareas dentro de una organización. Las técnicas 30 que permiten realizar un análisis a los datos son muy diversas. A continuación, se presentan tres de ellas. Reglas de inferencia También son una técnica lógica que permite extraer una conclusión, a partir de una o varias premisas o hipótesis. Se menciona que, un argumento es válido, siempre y cuando la conclusión sea verdadera (CalcaWorkshop, 2021). Las reglas de inferencia pueden ser definidas de la siguiente manera: Tomando en cuenta que: P y Q son hipótesis. 𝑆𝑖 𝑃 → 𝑄, 𝑦 𝑃 𝑒𝑠 𝑣𝑒𝑟𝑑𝑎𝑑𝑒𝑟𝑎, 𝑒𝑛𝑡𝑜𝑛𝑐𝑒𝑠 𝑄 𝑒𝑠 𝑣𝑒𝑟𝑑𝑎𝑑𝑒𝑟𝑎 Esto demuestra que, si la hipótesis P resulta ser verdadera, en consecuencia, la conclusión Q también será verdadera. Reglas de asociación Esta técnica de análisis permite extraer las relaciones que están presentes en el conjunto de datos, dichas relaciones se especifican en forma de reglas. Estas reglas permiten establecer la dependencia de ciertos objetos. Para encontrar reglas de asociación se deben tener en cuenta dos puntos importantes: la extracción de elementos que se presentan de forma frecuente dentro del conjunto de datos y la generación de reglas (Sharma & Ganpati, 2021). Aprendizaje Automático Es una técnica que permite a los sistemas computacionales aprender de los datos, tratando de simular la forma de aprendizaje de los seres humanos, mediante la utilización de algoritmos complejos. Es así que, mientras más datos de entrenamiento se pueda proporcionar al algoritmo, más preciso serán los modelos que puedan dar como resultado. Este proceso de entrenamiento debe ser iterativo de forma que permita 31 mejorar el análisis de los datos. El aprendizaje automático puede ser implementado en varios ámbitos como la salud, educación, investigación, etc. Ya que debido a la complejidad y el tamaño de los datos que se utilizan, los modelos pueden ser pasado por alto por los humanos (IBM, 2022). Algoritmos genéticos Los algoritmos genéticos son métodos que son utilizados en problemas relacionados con búsquedas y optimización que se basa en los principios relacionados con la genética y la selección natural, por esta razón, los conceptos se basan en teorías referentes a la biología y genética (Santos & Aday, 2014). Bases de datos no relacionales Denominados también NoSQL (No solo SQL), son bases de datos que permiten almacenar la información en varios formatos y que tienen compatibilidad con la alta velocidad y diferente variedad (Bathla, Rani, & Aggarwal, 2018). El almacenamiento en NoSQL difiere de las bases de datos relacionales ya que la información no se guarda en tablas, este enfoque implica tres características principales: la simplicidad al momento de diseñar, la escalabilidad horizontal y un mayor control sobre la disponibilidad; hoy en día, las bases de datos NoSQL, mayoritariamente son utilizadas junto con tecnologías como big data, smart data o aplicaciones en tiempo real debido a la gran flexibilidad que ofrece (Kotecha & Joshiyara, 2017). Características Escalabilidad. Las bases de datos no relacionales permiten escalar de manera horizontal, esto implica que para aumentar la capacidad de almacenamiento se debe agregar más equipo, máquinas, hardware o recursos (Amazon, 2022). Menos costo. Debido a la elasticidad y escalabilidad que tienen las bases de datos NoSQL en la nube, genera menos costo para las organizaciones que utilizan este 32 servicio, ya que la computación en la nube tiene un costo basado en el uso (Kotecha & Joshiyara, 2017). Redundancia. Implica tener copias de los datos o la información principal, para que en caso de que se genera un imprevisto donde sea evidente la perdida de información, exista una copia lista y disponible para su uso (Kotecha & Joshiyara, 2017). Flexibilidad. Los esquemas NoSQL son flexibles y dinámicos porque por lo general implican un desarrollo más rápido, repetitivo, acepta todos los formatos de datos, siendo idóneos, en mayor medida, para datos semiestructurados y no estructurados (Amazon, 2022). Fácil gestión. Dependiendo del tipo de base NoSQL que se utilice, el proveedor permitirá manejar las operaciones sobre la base de datos, brindando las herramientas adecuadas. Generalmente, estas actividades se las realizan mediante un dashboard administrativo al que se puede acceder mediante un navegador web. Categorías Las categorías de las bases de datos NoSQL se definen en base a la forma en que van a ser aplicadas, en un dominio o contexto específico. Clave valor. En esta categoría los datos son almacenados en pares denominados clave-valor, de forma que a cada clave le corresponde un valor único, la clave debe ser única y no se puede repetir, tal como se muestra en la Figura 2. Este tipo de estructura es eficiente en el ámbito de almacenamiento distribuido. Ejemplos de bases de datos NoSQL clave valor son: Cassandra, Azure, LevelDB y Riak (Bathla, Rani, & Aggarwal, 2018). 33 Figura 2 Categoría NoSQL Tipo clave - valor Nota. Adaptado de “Comparative study of NoSQL databases for big data storage” (p. 85), por Bathla, G., et al., 2021, International Journal of Engineering & Technology. Almacenamiento de columnas. Esta categoría permite almacenar los valores o datos en forma de columnas, en lugar del almacenamiento por filas en bases de datos relacionales. Con estas estructuras se obtiene una alta escalabilidad y buen rendimiento. La aplicación de este tipo de base NoSQL se orienta a la minería de datos; por ejemplo: Hbase, Mesa grande, HyperTable (Kotecha & Joshiyara, 2017). Figura 3 Categoría NoSQL almacenamiento en columnas 34 Nota. Adaptado de “Comparative study of NoSQL databases for big data storage” (p. 84), por Bathla, G., et al., 2021, International Journal of Engineering & Technology. Basado en gráficos. Es un tipo de base NoSQL que utiliza gráficos como forma de almacenamiento de los datos; los gráficos son estructuras que esquematizan una relación entra dos o más objetos. Dichos objetos se denominan nodos, los cuales están conectados mediante relaciones que se conocen como bordes; existe un identificador único en cada borde (Moko & Asagba, 2020). Un ejemplo de aplicación son las redes sociales; un usuario puede tener varias conexiones con otros usuarios. Figura 4 Categoría NoSQL basada en gráficos Nota. Adaptado de “Comparative study of NoSQL databases for big data storage” (p. 85), por Bathla, G., et al., 2021, International Journal of Engineering & Technology. Orientado a documentos. Similar a la categoría de par clave – valor, con la diferencia de que los datos o información se almacenan en estructuras denominadas documentos, los cuales pueden estar en forma de texto, matrices, cadenas, JSON, XML o cualquier formato (Moko & Asagba, 2020). Esta estructura tiene una ventaja importante y es que se puede agregar atributos nuevos cuando sea necesario, a diferencia de las bases de datos relacionales, donde se agrega un nuevo atributo para todos los registros, generando valores nulos innecesarios. Ejemplos de bases de datos 35 orientados a documentos son: MongoDB, CouchDB, OrientDB y MarkLogic (Bathla, Rani, & Aggarwal, 2018). Figura 5 Categoría NoSQL Orientado a documentos MongoDB Es una base de datos NoSQL orientada a documentos. Un documento hace referencia a un registro ingresado, el conjunto de estos se denomina colección, que es similar a una tabla en una base de datos relacional. Dentro de cada documento se encuentran los datos, que están compuestos por pares de clave – valor. Tienen una estructura similar a los objetos JSON y sus valores pueden ser otros documentos, matrices, arreglos, texto, números, valores booleanos, etc. (Mongo DB, 2022). Figura 6 Ejemplo de documento Nota. Ejemplo de un documento en MongoDB. Adaptado de “Document Database”, de MongoDB, 2021, MongoDB docs (https://docs.mongodb.com/manual/introduction). 36 Figura 7 Ejemplo de colección Nota. Ejemplo de un documento en MongoDB. Adaptado de “Document Database”, de MongoDB, 2021, MongoDB docs (https://docs.mongodb.com/manual/introduction). Pruebas visuales A continuación, se describen algunas pruebas visuales que son ampliamente utilizadas en el ámbito oftalmológico y que se consideran tradicionales porque no intervienen herramientas tecnológicas en el momento de su aplicación. Test de ishihara Es un test que permite diagnosticar problemas visuales relacionados con la percepción del color. Esta prueba está formada por láminas pseudo isocromáticas que permite distinguir alteraciones de los colores rojo – verde. Existen dos tipos: de 38 láminas y el de 24 (Melcón, 2004) . La base de este test es el de reconocer número o figuras geométricas hechas por pequeños puntos coloreados, la Figura 8 muestra un ejemplo respecto a las láminas de Ishihara. 37 Figura 8 Ejemplo de lámina del test de ishihara Interpretación de resultados. El manual de test (GIMA Professional Medical Product, 2022) indica que la evaluación de las placas 1 a 21 miden visión normal o deficiente del color; se considera normal, si el paciente lee 17 o más placas sin problemas; se considera deficiente si se leen 13 o menos placas. La Tabla 1 muestra los valores de las placas para personas con percepción normal, defectuosa y daltonismo. Tabla 1 Valoración de láminas de Ishihara Lámina Normal Deficiencia Daltonismo 1 12 12 12 2 8 3 X 3 6 5 X 4 29 70 X 5 57 35 X 6 5 2 X 7 3 5 X 8 15 21 X 9 74 X X 10 2 X X 11 6 X X 12 97 X X 13 45 X X 14 5 X X 15 7 X X 16 16 X X 17 73 X X 18 X 5 X 19 X 2 X 20 X 45 X 21 X 73 X 38 Test de Lang El test de Lang permite detectar la estereopsis. Consta de dos láminas denominados Lang I, que es la que mide la estereopsis más gruesa y Lang II que mide la estereopsis fina. Para aplicar este test, es necesario simplemente colocar la tarjeta frente al paciente, quien deberá nombrar los objetos que mira, a unos 40 centímetros de distancia. El test I tiene una cuantificación de: Coche: 550’’. Estrella: 600’’. Gato: 1200’’; mientras que, en el test II la cuantificación es: Luna: 200’’. Coche: 400’’. Elefante: 600’’. La Figura 9 y Figura 10 muestran las láminas de Lang I y II respectivamente (Morán et al., 2010). Figura 9 Lámina 1 de test de Lang Figura 10 Lámina II de test de Lang 39 Test de titmus Este test permite evaluar la ambliopía, el estrabismo y otros problemas de agudeza binocular utilizando estereopsis; para esta prueba se debe utilizar gafas polarizadas. Consta de tres partes que son:  la mosca: donde el paciente señalará las alas de la mosca y si se encuentra bien, las notará flotando;  animales: donde el paciente tendrá que decir cuál es el único animal que sobresale.  círculos: el paciente deberá indicar cuál es el círculo que sobresale en cada grupo, los cuales son 9 de 4 círculos cada uno. Figura 11 Test de titmus Metodología de Desarrollo Para la elaboración del presente trabajo, se utilizó la metodología de desarrollo denominada Scrum. De acuerdo a la guía del año 2020, Scrum se define como: “un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables para problemas complejos” (Schwaber & Sutherland, 40 2020). Este marco de trabajo está enfocado en el desarrollo ágil de software ya que permite el trabajo colaborativo a fin de encontrar mejores resultados. Equipo Scrum El equipo Scrum es grupo pequeño de personas multifuncionales los cuales persiguen objetivos en común; de acuerdo a la guía de Scrum (Schwaber & Sutherland, 2020), se sugiere que el número máximo de personas sea de 10 y sin establecer jerarquías ni sub-equipos. El equipo de Scrum tiene la responsabilidad de llevar a cabo todas las actividades que estén planificadas para lograr el producto final. Dentro del equipo de Scrum se encuentran los roles de: desarrolladores, propietario del producto y scrum master. Desarrolladores. Son los encargados de elaborar, diseñar y desarrollar el producto software (Schwaber & Sutherland, 2020). Propietario del producto (Product Owner). Es la persona que se responsabiliza de mantener una gestión eficaz dentro del equipo Scrum. Scrum master. Es la persona que tiene el mayor conocimiento de la guía de Scrum, su funcionamiento y todo lo que implica el marco de trabajo; tiene la función de liderar al equipo. Elementos de Scrum Hace referencia a los trabajos que se deben realizar para generar valor al producto; la guía de Scrum (Schwaber & Sutherland, 2020), define los siguientes elementos: Pila del producto (Product backlog), Pila de sprint (Sprint backlog) e Incremento. Pila del producto (Product backlog). Es un listado de requisitos, comúnmente denominados como historias de usuario. Se encuentran descritos en un lenguaje natural, no técnico (Softeng, 2021). 41 Pila del Sprint (Sprint backlog). Es un listado de tareas que sirven para realizar las historias del sprint como tal; este listado se compone del objetivo, las tareas y un plan (Schwaber & Sutherland, 2020). Incremento. Hace referencia a todas las tareas del product backlog completados en el transcurso de un sprint. Eventos de Scrum Permiten que el proceso de Scrum pueda tener regularidad y un buen control, con ello reducir en gran medida las reuniones no planificadas. (Schwaber & Sutherland, 2020). Sprint. Es una actividad que se puede realizar de forma iterativa; cuenta con un tiempo de duración fijada previamente. En este tiempo, el equipo de scrum trabaja para que las historias de usuario que se encuentran en el product backlog, puedan ser desarrolladas y generar una versión del software con una operatividad completa (Softeng, 2021). Planificación de Sprint. Es un proceso para planificar el sprint que se realizará a futuro; se establece todo el trabajo que realizará el equipo scrum, quienes crearán y planificarán todas las actividades que se deban llevar a cabo (Schwaber & Sutherland, 2020). Scrum diario (Daily Scrum). Son reuniones cortas de máximo 15 minutos, enfocados para los desarrolladores principalmente; tiene como meta inspeccionar los avances que se va teniendo para cumplir con el sprint, y en caso de que fuese necesario, adaptar el sprint backlog (Schwaber & Sutherland, 2020). Revisión del sprint (Sprint review). Es la revisión del sprint inicial planificado, aquí se lleva a cabo la inspección del resultado que se obtuvo durante el periodo de 42 trabajo. En esta reunión, todo el equipo scrum presenta los resultados alcanzados con su trabajo a las partes interesadas y se pone en discusión los avances que se va teniendo para el producto final. (Schwaber & Sutherland, 2020). Proceso scrum El proceso de scrum se ejecuta de forma iterativa, generalmente con periodos de 2 semanas, aunque se puede extender hasta 4 como un límite máximo, donde cada iteración que se realice debe tener como objetivo un incremento del producto final. Este proceso inicia con la planificación del sprint en donde la lista de requisitos, historias de usuario o product backlog es presentado al equipo scrum por parte del propietario del producto; el equipo scrum planifica las tareas que sean necesarias para poder cumplir con dichos requisitos durante la duración del sprint, dando como resultado el sprint backlog. Para poder verificar los avances, problemas o retrasos que existan durante la duración del sprint, el equipo realiza reuniones diarias o daily scrum; estas reuniones son importantes ya que permite eliminar cualquier inconveniente que vaya surgiendo y así poder adaptar todo el trabajo del equipo scrum; además, se puede definir de mejor manera los requisitos planteados en un inicio, en caso de ser necesario. Finalmente, se realiza la reunión de revisión, donde se presentan los requisitos y tareas finalizadas, lo que se conoce como incremento del producto y que pueden ser entregados al cliente sin ningún problema; además, se realiza la retrospectiva, donde el equipo analiza las formas de mejorar las futuras iteraciones (Albaladejo, 2015). 43 Figura 12 Proceso de scrum Nota: Proceso que se lleva a cabo en Scrum, donde el principio básico es el sprint. Tomado de: https://netmind.net/es/scrum-el-pasado-y-el-futuro, por M. Rodríguez, 2020. Herramientas Para le elaboración del sistema de apoyo a la toma de decisiones, se utilizaron las siguientes herramientas: Software Figma. es una aplicación que se ejecuta en el navegador y con la ayuda de herramientas permite crear interfaces de usuario en el proceso de diseño de un proyecto (Figma, s.f.). React. es una biblioteca que permite construir interfaces de usuario haciendo uso de componentes que puedan ser reutilizables y se disminuyan los errores al momento de construir las interfaces. Facebook es la principal empresa que brinda soporte a React, por lo que es una biblioteca sumamente utilizada en la comunidad de desarrolladores. 44 Next js. Es un framework de código abierto que permite el desarrollo sobre aplicaciones que están basadas en React. Permite la elaboración de aplicaciones de página única (SPA) y aplicaciones web que tienen un rendimiento alto, debido al renderizado en el lado del servidor, que es de las características más importantes (NextJs, 2022). Python. Es un lenguaje de programación multiparadigma ya que soporte programación orientada a objetos, imperativa y funcional; tienen una licencia de código abierto y es uno de los lenguajes más populares en la actualidad, debido a su facilidad de aprender y su amplia gama de aplicaciones en otros ámbitos como el análisis de datos, la estadística, la inteligencia artificial, machine learning, entre otros (Python, 2021). Django. Es un framework de Python orientado al desarrollo web, que se usa el patrón Modelo – Vista – Controlador; tiene como finalidad brindar una mayor facilidad a la construcción de sitios web complejos. Utiliza los principios de reutilización, la conectividad y extensibilidad de componentes y DRY (no re lo repitas). Djongo. Es una extensión del ORM (Object Relational Mapping) que viene implementado en Django pero haciendo uso de la base de datos NoSQL MongoDB. Realiza el mapeo de Python a documentos de la base, lo cual se conoce como ODM (Objecto Document Mapping – Mapeo de documentos de objetos). Ayuda a que las consultas sean más sencillas en comparación con Pymongo. MongoDB. Es una base de datos no relacional, que se basa en documentos, donde cada documento contiene los datos almacenados; estos datos pueden ser de varios tipos y no tiene una estructura definida. 45 Robo 3T. Es la interfaz gráfica (UI) que permite manejar las bases de datos creadas en MongoDB. Con la ayuda de esta interfaz se pueden ejecutar las consultas, crear índices y visualizar documentos. 46 Capítulo III Desarrollo de la aplicación En el presente capítulo se detalla el diseño y desarrollo del sistema de apoyo a la toma de decisiones. Metodología de desarrollo Para el desarrollo del sistema de apoyo a la toma de decisiones se utilizó la metodología ágil Scrum, donde se realiza un sprint cada cierto tiempo y permite mostrar un incremento de la aplicación. Con esta metodología se definió el equipo Scrum o equipo de trabajo, que son todas las personas que se encuentran involucradas con la construcción de la solución. La tabla 2 especifica las responsabilidades que tiene cada persona. En cuanto a la duración de cada sprint, se estableció un tiempo de 2 semanas a fin de que el equipo de desarrollo puede presentar un incremento que permita verificar los avances, corregir errores y mejorar el sistema. Tabla 2 Equipo Scrum Rol Responsabilidades Persona(s) Product Owner Conocer profundidad las reglas de negocio. Transmitir de forma clara los objetivos del producto. Médico especialista: Dr. Adrián Ruiz del Hospital de Especialidades de FF.AA. Nro. 1 Scrum Máster Solventar o eliminar los inconvenientes e impedimentos con el fin de asegurar que el proyecto se desarrolle adecuadamente. Ing. Sonia Cárdenas Delgado (Tutora de la Tesis) Equipo de Desarrollo Implementar las historias de usuarios planteadas por el product Owner. Estimar tiempos y planificar los lanzamientos de las funcionalidades.  Stalin Oswaldo Crisanto Caiza (Tesista)  Dany Fernando Lasso Ayala (Tesista) 47 Requisitos del sistema Los requisitos son funcionalidades de un sistema que se encuentran debidamente documentados para una mejor comprensión del equipo de desarrollo. Recopilación de información Scrum define al Product Backlog como una lista de funcionalidades que requiere el producto software. Con el fin de recopilar información para el desarrollo del sistema de apoyo a la toma de decisiones se utilizó historias de usuario para definir quién necesita la funcionalidad, cómo debe funcionar, que objetivo tiene dentro de la solución y una prioridad definida; la Tabla 4 muestra el modelo utilizado para recopilar las historias de usuario. Adicionalmente, para mantener una mejor documentación respecto a los requisitos del sistema, el equipo de desarrollo definió los rangos de prioridad para cada historia de usuario y requisito establecido, de acuerdo a como se muestra en la Tabla 3. Tabla 3 Rango de prioridad de las historias de usuario Prioridad Descripción 5 La implementación es mandatorio, sin ella la solución no puede funcionar. 4 La implementación genera valor al cliente, pero la solución puede funcionar sin ella. 3 La implementación debe ser desarrollada por todos los medios posibles, en caso de que esté retrasando al equipo, se puede dejar de lado. 2 La implementación es opcional, pero debe estar en la planificación. 1 La implementación de la funcionalidad solo será efectuada si sobra tiempo. 48 Tabla 4 Historias de usuario Identificador Nombre de la historia de usuario Descripción Historia breve, contado por el usuario de manera informal, donde cuenta qué es lo que necesita el sistema, cuáles serán los parámetros tanto de entrada como de salida de datos, etc. Estimación de tiempo Tiempo estimado que durará la implementación de la presente historia. Prioridad Prioridad que asigna el equipo de desarrollo Especificación de requisitos Una vez recopilada la información con las historias de usuario, se establecen los requerimientos de software, de acuerdo a su orden de prioridad e importancia para el sistema; para el presente desarrollo se definen los requisitos que se muestran en la tabla 5. Tabla 5 Especificación de requisitos del sistema ID Nombre del requisito Características R01 Administración de usuarios, roles y permisos El sistema debe contar con un módulo que permita manejar la información de usuarios. Adicionalmente, el sistema permitirá manejar los roles y permisos que se asignan a cada usuario. También se deberá manejar la autenticación e inicio de sesión por medio de un módulo de seguridades. R02 Realizar pruebas clásicas El sistema permitirá la realización de pruebas clásicas (Lang, Ishihara y Titmus), además de administrar la información de cada prueba que se haya realizado. R03 Realizar pruebas virtuales El sistema permitirá administrar la información de los resultados de las pruebas virtuales realizadas en los otros módulos (visión estereoscópica, 49 percepción visual de profundidad, percepción visual de color). Además de administrar la información de las pruebas que ya se han completado. R04 Realizar cuestionario El sistema permitirá realizar un pre - cuestionario con la finalidad de determinar si un paciente es apto para ingresar a los entornos virtuales. También permitirá realizar, un post – cuestionario, a fin de establecer que el paciente se encuentra estable, luego de realizar las pruebas virtuales. R05 Subir información de resultados El sistema permitirá subir archivos en formato txt, que cuentan con los diferentes resultados de las tareas virtuales. R06 Evaluar la tarea El sistema cuenta con una evaluación de la tarea, que será realizada por el paciente. A fin de conocer su percepción respecto a la usabilidad de la aplicación y entornos virtuales. R07 Visualizar detalles de la prueba El sistema debe permitir la generación de reportes donde se emitirá las recomendaciones o sugerencias de acuerdo a las pruebas que se hayan realizado y registrado en el sistema. Diseño del sistema En esta sección se especifica lo realizado por el equipo de desarrollo en cuanto al diseño de los distintos componentes que conforman el sistema de apoyo a la toma de decisiones, partiendo de los casos de uso, las interfaces de usuario, diseño de la base de datos y la arquitectura del sistema. Diagramas y especificación de casos de uso Los diagramas de caso de uso permiten visualizar de forma gráfica las diferentes funcionalidades del sistema; para los casos de uso, es importante definir los actores (usuarios) que intervienen en el sistema, tal como se muestra en la Figura 13. Estos son: administrador, que puede manejar todas las funcionalidades del sistema y evaluador, que realiza el flujo de las pruebas en el sistema. 50 Figura 13 Actores que intervienen en el sistema A continuación, se detallan los casos de uso definidos para la realización del sistema Figura 14 Caso de uso Iniciar sesión 51 Tabla 6 Descripción caso de uso Iniciar sesión Descripción del caso de uso Iniciar sesión Nombre Descripción Iniciar sesión Permite a los actores evaluador, paciente y administrador, poder ingresar al sistema. El sistema solicitará el ingreso de las credenciales (nombre de usuario y contraseña). El actor ingresará las credenciales que serán validadas por el sistema. En caso de que las credenciales sean correctas, se permitirá el acceso; en caso de que las credenciales sean incorrectas, se emitirá un mensaje de error. Figura 15 Caso de uso Administrar usuarios 52 Tabla 7 Descripción del caso de uso Administrar Usuarios Descripción del caso de uso Administrar Usuarios Nombre Descripción Administrar usuarios Permite que el usuario administrador pueda manejar la información referente a los usuarios del sistema. Puede crear un nuevo usuario, ya sea paciente o evaluador, ingresando la información necesaria; permite agregar roles y permisos que tendrá cada usuario. También permite modificar la información en caso de que sea necesario; habilitar o inhabilitar a un usuario y finalmente eliminar la información y registro de un usuario del sistema. Figura 16 Caso de uso realizar tarea virtual 53 Tabla 8 Descripción del caso de uso realizar tarea virtual Descripción del caso de uso realizar tarea virtual Nombre Descripción Tarea virtual Permite al usuario evaluador, realizar la prueba clásica a un paciente. El evaluador busca un paciente; en caso de que esté registrado, continua con el proceso; si el paciente no se encuentra registrado, el usuario evaluador deberá registrar sus datos. Con la información del paciente, se le realiza el pre – cuestionario, el evaluador tiene la opción de verificar las respuestas ingresadas a fin de establecer que el paciente está apto para realizar las tareas. Posteriormente, el evaluador sube la información generada por los módulos de pruebas. Realiza el post – cuestionario al paciente y finalmente se pedirá al que realice la evaluación de la tarea. Finalmente, el evaluador puede emitir reportes con las recomendaciones o sugerencias dependiendo de los resultados. 54 Figura 17 Caso de uso prueba clásica Tabla 9 Descripción del caso de uso realizar prueba clásica Descripción del caso de uso realizar prueba clásica Nombre Descripción Administrar usuarios El usuario evaluador puede realizar la prueba clásica a los pacientes. El evaluador busca un paciente; en caso de que esté registrado, continua con el proceso; si el paciente no se encuentra registrado, el usuario evaluador deberá registrar sus datos. Selecciona la prueba a realizar y se registran las respuestas. Finalmente, el evaluador puede emitir reportes con las recomendaciones o sugerencias dependiendo de los resultados. 55 Figura 18 Caso de uso generar reportes Tabla 10 Descripción del caso de uso generar reportes Descripción del caso de uso generar reportes Nombre Descripción Generar reportes Los usuarios pueden generar reportes de sus pruebas realizadas. Los usuarios deben iniciar sesión en el sistema, seleccionar una fecha o tipo de prueba, donde se podrá visualizar información referente a las respuestas de las pruebas tanto clásicas como virtuales y las recomendaciones que emite el sistema. Diseño de interfaces para el aplicativo web Las interfaces de usuario permiten establecer una comunicación del usuario con la computadora; para el diseño de interfaces del sistema de apoyo a la toma de 56 decisiones, en primer lugar, se realizó un maquetado utilizando Figma, que es una herramienta para elaborar prototipos y posteriormente se desarrolló utilizando Nextjs. Interfaz de inicio de sesión. El inicio de sesión consta de dos campos para ingreso de usuario y contraseña, que permitirá autenticar la información e ingresar al sistema. Figura 19 Interfaz inicio de sesión Interfaz de búsqueda y datos de pacientes. La interfaz de búsqueda e información de pacientes consta de una tabla donde resume la información de los pacientes y formularios de búsqueda. 57 Figura 20 Interfaz de pacientes Interfaz de flujo de pruebas. La interfaz de flujo de pruebas consta de las pruebas tradicionales y tareas virtuales que realizará un paciente de forma secuencial. Iniciando por la prueba tradicional de Lang, seguido de la prueba de Ishihara y finalizando con la prueba de Titmus. Posteriormente el paciente realiza las tareas virtuales en el siguiente orden: visión estereoscópica, percepción visual de profundidad, percepción visual del color y campo visual. 58 Figura 21 Interfaz de pruebas Interfaz de pruebas tradicionales. En la interfaz principal de las pruebas tradicionales (Lang, Ishihara y Titmus) se muestran las láminas correspondientes para la realización de la prueba, como se muestra en la Figura 22 para la prueba de Lang. Figura 22 Interfaz de pruebas tradicionales 59 Al ejecutar la prueba aparecerá una interfaz que permita registrar los resultados, los cuales podrán ser dinámicos en caso de que el paciente mencione otras respuestas que son incorrectas, a fin de tener información completa. Figura 23 Interfaz de ingreso de resultados Interfaces de tareas virtuales. Las tareas virtuales constan de 4 apartados. En el primer apartado se indica el consentimiento informado, para que el usuario pueda descargar la respectiva acta y aceptar los términos y condiciones de la tarea. El siguiente apartado es del pre – cuestionario (Ver Figura 24) para verificar que el paciente se encuentra con una salud estable para realizar la tarea. Luego se encuentra el apartado de la tarea virtual, donde permite subir la información de resultados obtenidos (Ver Figura 25). Finalmente se encuentra el apartado del post – cuestionario, que permite verificar que el paciente se encuentra con estabilidad luego de hacer o realizar la prueba. Además, se encuentra un botón para realizar la evaluación por parte del paciente respecto a la utilización de los entornos virtuales (Ver figura 26). 60 Figura 24 Precuestionario en pruebas virtuales Figura 25 Interfaz para subir resultados de tareas virtuales 61 Figura 26 Interfaz cuestionario de usabilidad Diseño de la base de datos La base de datos utilizada en este sistema es no relacional. El modelamiento se desarrolló en base a las especificaciones técnicas de MongoDB. El modelo consta de los módulos de seguridad, pruebas clásicas y pruebas virtuales (Ver Figura 27). 62 MÓDULO SEGURIDADES Figura 27 Diseño de la base de datos 63 MÓDULO PRUEBAS CLÁSICAS 64 Diseño de la arquitectura El esquema de la arquitectura del sistema describe su funcionamiento y la relación entre sus componentes, tal como se muestra en la Figura 28. Figura 28 Arquitectura del sistema Definición de reglas El sistema utiliza reglas de inferencia para generar las recomendaciones. Las reglas fueron supervisadas por el equipo de especialistas e investigadores previo a su implementación en el sistema. Cada prueba clásica y tarea virtual completa tiene una valoración del 100%. Pero cada una de ellas difiere en cuanto a la cantidad de aciertos y errores cometidos por el paciente. En la prueba clásica de Lang, la lámina 1 contiene 3 objetos y la lámina 2 contiene 4 objetos, dando un total de 7, los cuales corresponden al 100%; dependiendo de la cantidad de aciertos del paciente, los porcentajes son los siguientes: 65 Tabla 11 Porcentajes para la prueba clásica de Lang Score/Aciertos Porcentaje 1 14% 2 29% 3 43% 4 57% 5 71% 6 86% 7 100% Para la prueba clásica de Ishihara, se tomará en cuenta 17 láminas que en total corresponden al 100%, los porcentajes para la cantidad de aciertos que tenga el participante son los siguientes: Tabla 12 Porcentajes para prueba clásica de ishihara Score/Aciertos Porcentaje 1 6% 2 12% 3 18% 4 24% 5 29% 6 35% 7 41% 8 47% 9 53% 10 59% 11 65% 12 71% 13 76% 14 82% 15 88% 16 94% 17 100% 66 De acuerdo a los porcentajes obtenidos por el participante, la regla toma en cuenta la siguiente definición:  (Lang < 57%) Y (Profundidad < 40%) → “Se ha encontrado una posible deficiencia visual de estereopsis”.  (Ishihara < 59%) Y (Color < 50%) → “Se ha encontrado una posible deficiencia visual del color” La segunda regla se define de acuerdo a los siguientes porcentajes: Deficiencia de estereopsis  Puntuación prueba visual clásica 1 (LANG) 30%  Puntuación prueba visual tecnológica 1 (Percepción de profundidad) 20% Deficiencia de color  Puntuación prueba visual clásica 2 (Ishihara) 30%  Puntuación prueba visual tecnológica 2 (Percepción de color) 20% Con el valor obtenido, se definen las siguientes reglas:  (Total >= 91%) O (Total <= 100%) → “No se han encontrado deficiencias visuales”.  (Total >= 81%) O (Total <= 90%) → “No se han encontrado deficiencias visuales importantes”.  (Total >= 61%) O (Total <= 80%) → “Tiene alguna deficiencia, es necesario acudir al especialista”.  (Total >= 31%) O (Total <= 60%) → “Tiene deficiencias visuales, debe acudir al especialista”. 67  (Total >= 10%) O (Total <= 20%) → “Tiene deficiencias visuales importantes, debe acudir al especialista”. Las definiciones de las reglas fueron establecidas en base a las puntuaciones alcanzadas por los participantes, las técnicas de los investigadores y especialistas. 68 Capítulo IV Validación del prototipo En este capítulo se detalla el protocolo de pruebas implementado para validar el prototipo, y los resultados obtenidos de las diferentes tareas y pruebas, cuestionarios realizados antes y después de las tareas, así como la evaluación de la funcionalidad y usabilidad de la aplicación. Protocolo de pruebas El protocolo de pruebas establecido se muestra en la Figura 29. Las pruebas del prototipo se realizaron a un total de 10 participantes. La muestra fue seleccionada por los especialistas. Los participantes fueron un grupo control que incluyó personal militar, aspirante a pilotos de diferentes ramas de las Fuerzas Armadas. Se aplicaron pruebas visuales tradicionales y tecnológicas. Las pruebas se realizaron en el Centro de Investigación de Aplicaciones Militares CICTE ubicado en el campus Matriz de la Universidad de las Fuerzas Armadas ESPE. Las validaciones se realizaron por parte de los especialistas e investigadores del proyecto de investigación. 69 Figura 29 Protocolo de pruebas Proceso previo El paciente lee la hoja informativa proporcionada por el o los evaluadores, donde se indica el carácter y objetivo que tiene el sistema en general. Figura 30 Lectura del consentimiento informado por parte del paciente 70 El paciente lee la hoja informativa y el consentimiento informado donde indica haber recibido información de los objetivos y tareas a realizar, aclaración de dudas por parte del o los evaluadores y su participación voluntaria. Figura 31 Firma del consentimiento informado Pruebas clásicas El paciente y el evaluador toman posiciones para iniciar con las pruebas clásicas en el orden siguiente: prueba de Lang, prueba de Ishihara y prueba de Titmus. Se registran los resultados en el sistema. 71 Figura 32 Aplicación de prueba Lang Figura 33 Aplicación de prueba Ishihara El evaluador realiza un precuestionario con la finalidad de ingresar a las tareas virtuales sin que el paciente tenga algún síntoma de mareo. Las respuestas del cuestionario son ingresadas en el sistema. 72 Figura 34 Aplicación del pre cuestionario Finalmente, el evaluador aplica un postcuestionario de mareo al paciente para conocer su estado luego de haber realizado las tareas virtuales, además, se aplicará una evaluación respecto a la usabilidad del prototipo por parte del paciente. Figura 35 Aplicación del cuestionario de usabilidad 73 Tareas virtuales El aspirante realiza las tareas virtuales de acuerdo al orden establecido. Los resultados son emitidos por los respectivos módulos en formato .txt y cargados en el sistema de apoyo a la toma de decisiones. Validación de las recomendaciones Para validar las recomendaciones generadas se realizó los especialistas compararon los diagnósticos previos pertenecientes a los participantes del grupo control, con las recomendaciones o sugerencias que emite el sistema. Para el siguiente ejemplo, se mostrará el proceso de pruebas realizado con un participante, desde el ingreso de sus datos, hasta la generación del reporte. El paciente es registrado en el sistema (Ver Figura 37). Figura 36 Opción para registrar paciente 74 Figura 37 Formulario de datos para un nuevo paciente Luego, los resultados de las pruebas clásicas de Lang e Ishihara son ingresados en el sistema (Ver Figura 38 y Figura 39). Figura 38 Registro de resultados de la prueba de Lang 75 Figura 39 Registro de resultados de la prueba de Ishihara Los resultados se almacenan en la base de datos; para este caso, la colección denominada: “classic_test_langishiharatest”, tiene los documentos (registros) de los resultados que se ingresaron previamente. Figura 40 Resultados almacenados en la base de datos 76 Se registran los resultados de las pruebas virtuales, los cuales son cargados mediante un archivo txt (Figura 39) que se encuentra almacenado en la computadora. Estos datos son almacenados en la colección respectiva de la base de datos. Figura 41 Registro de resultados de las pruebas virtuales Los resultados son procesados en el sistema; una vez que se haya completado todo el registro de las pruebas el evaluador puede visualizar las recomendaciones del sistema (Ver Figura 43) y posteriormente, generar un reporte (Ver Figura 44); ambas opciones le permiten al especialista o médico visualizar la recomendación generada por el sistema. . 77 Figura 42 Opción del sistema para visualizar las recomendaciones Figura 43 Pantalla de recomendaciones 78 Figura 44. Reporte generado por el sistema Finalmente, los resultados de las recomendaciones generadas por el aplicativo fueron validados por el equipo de evaluadores y especialistas. Quienes manifestaron estar de acuerdo con los resultados obtenidos en las pruebas del grupo control. 79 Análisis de Resultados En esta sección se describe el análisis de los resultados obtenidos en el proceso de pruebas realizado. Cuestionarios Antes de la tarea virtual. Respecto al análisis del pre cuestionario aplicado luego de realizar las pruebas clásicas y previo a la realización de las tareas virtuales, los pacientes no muestran malestar alguno. Sin embargo, 1 participante presenta incremento de la salivación, dificultad al concentrarse y visión borrosa. Por otra parte, el 20% que corresponde a 2 pacientes presentan sudoración y el 50% de los pacientes tuvo dificultades al centrarse para visualizar las distintas láminas, tal como se muestra en la Figura 45. Figura 45 Resultados de los cuestionarios aplicado antes de las tareas virtuales Después de la tarea virtual. En el post-cuestionario se obtuvo que la mayoría de los participantes no sintieron malestares después de realizar la tarea. Solo un 80 participante presentó incremento de la salivación y solo tres participantes tuvieron dificultad de centrarse en las pruebas. Figura 46 Resultados del cuestionario aplicado después de las tareas virtuales Evaluación de la usabilidad Para medir la usabilidad se utilizó la escala de Likert, los resultados fueron analizados por preguntas. Este cuestionario contiene 6 preguntas y fue aplicado al personal médico que serán los usuarios que utilizarán el sistema. Para el cálculo de la media total, se hizo uso de las medias de cada pregunta (Ver Figura 47), teniendo así los siguientes resultados: 𝑚𝑒𝑑𝑖𝑎 = 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎1 + 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎2 + 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎3 + 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎4 + 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎5 + 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎6 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎𝑠 𝑚𝑒𝑑𝑖𝑎 𝑑𝑒 𝑢𝑠𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 4,82 + 4,80 + 4,71 + 4,85 + 4,88 + 4,87 6 𝑚𝑒𝑑𝑖𝑎 𝑑𝑒 𝑢𝑠𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 4,82 81 Figura 47 Promedio de respuestas de la usabilidad del sistema Es decir que el personal médico y los especialistas participantes puntuaron la funcionalidad y usabilidad del aplicativo con una media de 4,82/5. A continuación se detalla las medias obtenidas de cada pregunta (Ver Figura 48). Pregunta 1. Para la pregunta: “Me gustaría utilizar este sistema frecuentemente”. Los usuarios puntuaron una media de 4,82/5; lo que quiere decir que todos utilizarían el sistema en de forma frecuente. Pregunta 2. Para la pregunta: “El sistema es bastante fácil de usar”, los usuarios puntuaron una media de 4,80/5; lo que quiere decir que a todos les pareció un sistema fácil de utilizar. Pregunta 3. Para la pregunta: “Las funciones del sistema se encuentran bien integradas” se obtuvo una media de 4,71/5, esto quiere decir que los usuarios encontraron una buena integración de las diferentes funcionalidades del sistema. 82 Pregunta 4. La pregunta: “La interfaz de usuario tiene una estructura y organización clara” obtuvo una media de 4,85/5, lo que quiere decir que la mayoría de los usuarios encontraron una interfaz con una estructura y organización clara. Pregunta 5. La pregunta: “Los nombres de las opciones me han parecido claros y representativos” obtuvo una media de 4,85/5, esto quiere decir que la mayoría a la mayoría de los usuarios les ha parecido que las opciones están claras y representativas. Pregunta 6. La pregunta: “De acuerdo a su criterio, la recomendación del sistema fue” obtuvo una media de 4,87/5, lo que demuestra que los especialistas estuvieron de acuerdo con las recomendaciones emitidas por el sistema. Figura 48 Gráfico de medias cuestionarios de usabilidad Nota. La notación P1, P2, P3, P4 y P5 corresponden a las preguntas 1, 2, 3,4, 5 y 6 respectivamente. 83 Capítulo V Conclusiones y recomendaciones Conclusiones Las reuniones en conjunto con el equipo de investigadores, el médico especialista y los desarrolladores permitieron identificar los requerimientos del sistema, diseñar las interfaces, la base de datos y definir las reglas que se implementaron en el sistema con lo que se pudo determinar una arquitectura adecuada que almacene, analice y genere información de valor. Se logró el desarrollo de una herramienta tecnológica de apoyo a la toma de decisiones, que permite al especialista tener una recomendación acerca de todas las pruebas visuales aplicadas en aspirantes a pilotos en el proceso de selección. Estas recomendaciones fueron generadas por el aplicativo, con base a los resultados de las pruebas clásicas y las tareas virtuales. Las técnicas de análisis de datos fueron las reglas de inferencia. El protocolo de comunicación entre los módulos fueron API REST y HTTP y la base de datos NoSQL utilizada fue MongoDB. Se definieron las reglas de inferencia en conjunto con el equipo evaluador, especialistas e investigadores, como una técnica de análisis de datos adecuado, de forma que permitieron inferir posibles deficiencias visuales. Se realizó la respectiva validación del prototipo, mediante un protocolo de pruebas. Se registraron resultados de las pruebas clásicas y tareas virtuales. Las pruebas se realizaron en 10 participantes, ellos eran personal militar de aspirantes a pilotos. El grupo fue seleccionado por los especialistas. El lugar de las pruebas fue el Centro de Investigación de Aplicaciones Militares CICTE. 84 Los resultados de las recomendaciones generadas por el aplicativo fueron validados por el equipo de especialistas. Quienes manifestaron estar de acuerdo, con los resultados obtenidos en las pruebas del grupo control, con el margen de certeza (95%). Además, evaluaron la usabilidad y funcionalidad del prototipo de software para apoyo a la toma de decisiones, puntuando una media de 4,82/5 de acuerdo a la escala de Likert. Recomendaciones Se recomienda continuar con el desarrollo del sistema, a fin de que se incluyan más reglas y datos que permitan mejorar y sustentar la toma de decisiones al equipo evaluador y a los médicos especialistas en el proceso de selección de aspirantes a pilotos, en la fase de pruebas visuales. Se recomienda investigar y aplicar otras técnicas de analítica de datos, de forma que puedan ser implementados en el sistema y puedan generar recomendaciones o sugerencias con mayor sustento técnico y legal, de acuerdo al protocolo de selección de aspirantes. Se recomienda tomar el presente prototipo como punto de partida para adaptar otros tipos de pruebas en el proceso de selección de aspirantes a piloto, dentro del proyecto liderado por el Departamento de Ciencias de la Computación de la Universidad de las Fuerzas Armadas ESPE. 85 Bibliografía Aussenac-Gilles, N., Charlet, J., & Reynaud, C. (2020). Knowledge Engineering A Guided Tour of Artificial Intelligence Research. Springer International Publishing, 733-768. Albaladejo, X. (2015, 09 24). Qué es Scrum. Retrieved from Proyectos ágiles: https://proyectosagiles.org/que-es-scrum/ Amazon. (2022). Amazon Web Services. Retrieved 01 11, 2022, from Amazon Web Services: https://aws.amazon.com/es/nosql/ Baldassarre, M., Caballero, I., Caivano, D., Rivas, B., & Piattini, M. (2018). From Big Data to Smart Data: A Data Quality Perspective. International Workshop on Ensemble-Based Software Engineering , 19-24. Bathla, G., Rani, R., & Aggarwal, H. (2018). Comparative study of NoSQL databases for big data storage. International Journal of Engineering & Technology , 83. Domashova, J., Emtseva, S., Fail, V., & Gridin, A. (2021). Selecting an optimal architecture of neural network using genetic algorithm. Annual International Conference on Brain-Inspired Cognitive Architectures for Artificial ernational Conference on Brain-Inspired Cognitive Architect, 263–273. Faraway, J., & Augustin, N. (2018). When small data beats big data. Statistics & Probability Letters, 142-145. Figma. (n.d.). Figma. Retrieved from Figma: https://www.figma.com/login Fraccaro, P., O'Sullivan, D., Plastiras, P., O׳Sullivan, H., Dentone, C., Di Biagio, A., & Weller, P. (2015). Behind the screens: Clinical decision support methodologies – A review. Health Policy and Technology, 29-38. García, J., Tortajada, S., & Sáez, C. (2019). Sistemas de ayuda a las decisiones médicas. Valencia: Universidad Politécnica de Valencia. García-Gil, D., Luengo, J., García, S., & Herrera, F. (2017). Enabling Smart Data: Noise filtering in Big Data. Department of Computer Science and Artificial Intelligence, University of Granada, 1-26. GIMA Professional Medical Products. (n.d.). Retrieved from https://www.gimaitaly.com/DocumentiGIMA/Manuali/ES/M31292ES.pdf Gourav, B., Rinkle, R., & Himanshu Aggarwal. (2018). Comparative study of NoSQL databases for big data storage. International Journal of Engineering & Technology 7, 2-6. Greenes, R. (2014). Clinical Decision Support: The Road to Broad Adoption: Second Edition. Waltham: Academic Press. Iafrate, F. (2015). From Big Data to Smart Data. John Wiley & Sons. 86 IBM. (2022, 12 01). ¿Qué es Machine Learning? Retrieved from https://www.ibm.com/co-es/analytics/machine-learning Instituto Europeo de Salud y Bienestar Social. (2021, Mayo 24). Instituto Europeo de Salud y Bienestar Social. Retrieved from https://institutoeuropeo.es/articulos/insights/el-desafio-del-big-data-en-los- sistemas-de-salud/ Jain, R. (2016). Decision Support Systems: An overview. Decision Support Systems in agriculture using quantitative analysis, 42-49. Kotecha, B., & Joshiyara, H. (2017). A Survey of Non -Relational Databases with Big Data. International Journal on Recent and Innovation Trends in Computing and Communication, 143-148. Melcón, D. (2004, 06). Estudio clínico de la percepción del color aplicando el test TC- COI. Retrieved from Fundación Visión Coi: http://archivos.fundacionvisioncoi.es/TRABAJOS%20INVESTIGACION%20COI/ 3/TEST%20TC-COI.pdf Mijwel, M., Esen, A., & Shamil, A. (2019). Overview of Neural Networks. 1-2. Moko, A., & Asagba, P. (2020). Big Data and NoSQL Databases Architecture: A Review. International Journal of Applied Science and Mathematical Theory, 1-8. Mongo DB. (2022, 01 11). Welcome to the MongoDB Documentation. Retrieved from Welcome to the MongoDB Documentation: https://docs.mongodb.com/ Morán, D., Valladares, L., Vallo, Ó., & García, M. (2010). Valoración de la visión estereoscópica con Test Lang I y Lang II. Centro de Optometría Internacional, 13-50. NextJs. (2022). NextJs. Retrieved from NextJs: https://nextjs.org/ Pinos, L., & Villavicencio, P. (2007). Business Intelligence: Competir con información. Academia. Python. (2021). Python. Retrieved from Python: https://www.python.org/ Sadiku, M., Musa, S., & Nelatury, S. (2017). Knowledge Engineering. International Journal of Engineering Research and Allied Sciences (IJERAS), 6-7. Santos, C., & Aday, A. (2014). Algoritmos Genéticos: una solución para la optimización del Reflector Parabólico. Revista de Ingeniería Electónica, Automática y Comunicaciones, 1-15. Schwaber, K., & Sutherland, J. (2020, Noviembre). Scrum Guides Versions. Retrieved from Scrum Guides: https://scrumguides.org/docs/scrumguide/v2020/2020- Scrum-Guide-Spanish-European.pdf 87 Shahsavarani, A., Marz, E., Hakimi, M., Jafari, S., & Saeideh, S. (2015). Clinical Decision Support Systems (CDSSs): State of the art Review of Literature. International Journal of Medical Reviews. Sharma, A., & Ganpati, A. (2021). Association Rule Mining Algorithms: A Comparative Review. International Research Journal of Engineering and Technology (IRJET), 848-853. Silva, M., & Falappa, M. (2015). Sistemas de soporte a las decisiones clínicas. 4to Congreso Argentino de Informatica y Salud, 291-298. Softeng. (2021, 11 16). Proceso y Roles de Scrum. Retrieved from Softeng, Your comptetitive advantage: https://www.softeng.es/es-es/empresa/metodologias-de- trabajo/metodologia-scrum/proceso-roles-de-scrum.html Souifi, A., Cherfi, Z., Zolghadri, M., Barkallah, M., & Haddar, M. (2021). From Big Data to Smart Data: Application to performance management. IFAC PapersOnLine, 857– 862.