Red social. Consulta Médica
Roman Petrov Petrov
UOCTrabajo final de máster DADM
página 2
• Introducción
• Contexto y justificación
• Análisis del dominio y analogías
• Planificación de trabajo
• Análisis, diseño y arquitectura
• Implementación y pruebas
• Conclusiones finales
• Demo de aplicación
Contenido:
página 3
© Roman Petrov Petrov
Reservados todos los derechos. Está prohibido la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la impresión, la reprografía, el microfilme, el tratamiento informático o cualquier otro sistema, así como la distribución de ejemplares mediante alquiler y préstamo, sin la autorización escrita del autor o de los límites que autorice la Ley de Propiedad Intelectual.
AgradecimientosDedicado a mi familia, por el apoyo y
ayuda en disponer de tiempo necesario para mi formación en la UOC.
Avances tecnológicos
Introducción
página 4
• En el mundo actual, contemporáneo y digital, usamos a diario diferentes tipos de soluciones móviles. Este hecho tiene su origen en los años 90 cuando fue posible colocar un gran número de microcircuitos y placas integradas en un dispositivo de tamaño relativamente pequeño como para poder llevarlo en el bolsillo de una camisa o pantalón.
• Hoy en día, el volumen de consumo y el número de tipos de soluciones móviles usados a diario es colosal, incomparable e imprevisible en los años anteriores.
• Al mismo tiempo, surgió el concepto de redes sociales, donde y como su propio nombre indica, permiten interconectar grandes grupos de personas de diferentes intereses y donde su número puede variar según los objetivos seguidos por estos.
¿Usar redes sociales en medicina?
página 5
• Total movilidad
• En la palma de la mano
• Sin ser médico
• Canal seguro
Redes sociales NO especializadas
Análisis del dominio y búsqueda de analogías
página 6
Redes sociales especializadas
Redes sociales NO especializadas
página 7
A nivel nacional, los médicos suelen utilizan más las redes sociales generales que las soluciones profesionales.
• Facebook 45%. Acercamiento más directo al paciente y publicar información divulgativa.
• Twitter 40%. Difundir hitos, de destacar las noticias sobre los avances y dar a conocer la información sobre las conferencias y eventos.
• LinkedIn 39%. Ayuda a construir propia marca profesional como especialista en una determinada área
• YouTube 28%. Contenido visual y dinámico sobre las técnicas, tecnologías o los tratamientos médicos.
Redes sociales especializadas
página 8
• Intercambio de conocimiento.
• Consultas dirigidas a una especialidad concreta.
• Valoraciones online.
• Segundas opiniones.
• Pagos por participación.
• Posibilidad de anonimato.
• Revisión de analíticas
página 9
• Solo cursos online para médicos • Consultas a una especialidad concreta.
• Debates.
página 10
Resumen características de las redes sociales
• Difusión de información médica.
• Debates sobre enfermedades
Nombre Diálogo paciente/médico
Usuariosregistrados
Web App Disponible España
Acceso paciente
+ 800.000 + iOSAndroid
- -
- 6.000 + - + -
- 5.000 + - + -
+ 90.000 + - + +
- desconocido + - + +
página 11
Resultado análisis
La mayoría de las redes médicas no están disponibles en España y aquellas que sí lo estaban en su momento sus aplicaciones ya no se pueden descargar de los Market.
Un gran número se utiliza simplemente para difusión de noticias médicas.
No todas cuentan con una aplicación móvil lo que merma bastante su popularidad.
Casi todas están orientadas exclusivamente a profesional sanitario siendo obligatorio el registro del usuario y con confirmación de número colegiado.
Las que sí permiten el acceso a los pacientes son comunicaciones de tipo foro y no un dialogo de tu a tu entre el médico y el paciente.
Objetivos de proyecto
página 12
Crear una nueva red social especializada con acceso desde una aplicación móvil y que cumpla con siguientes características:
Permita establecer un diálogo seguro entre el paciente y los médicos, o entre los especialistas entre si.
Permita intercambiar ficheros de las pruebas del paciente como imágenes de radiología o analíticas del laboratorio.
Permita visualizar los ficheros subidos para su posterior análisis
La aplicación funcione y esté disponible en España.
Permita acceso al sistema tanto a los médicos como a los pacientes.
Todo ello llevado y gestionado cómodamente desde una aplicación móvil.
Scrum
Planificación de trabajo
página 13
Para tener una planificación más realista, se ajustó la duración máxima de los sprint a una semana, de lunes a domingo, y permitiendo al alumno trabajar cualquier día pero con el compromiso de dedicar un mínimo de dieciocho horas de carga en cada uno, para garantizar las entregas de los hitos a tiempo y acorde a las fases de TFM, así como de los entregables finales a las fechas marcadas por el plan de la asignatura.
página 14
Fases y sus detalles
Fase 0. Definir y presentar una propuesta justificada de una idea por el estudiante para su validación y aprobación por parte del consultor de la asignatura.
Fase 1. Definir los objetivos del proyecto, la metodología que se utilizará y de realizar la planificación realista de entregas de los hitos basada en la disponibilidad del alumno y las fechas de entregas del plan docente.
Fase 2. Definir el diseño completo de todo el proyecto, el lado funcional y el técnico. El modelo de datos y la arquitectura del sistema, el tipo y forma de comunicación entre el cliente y el servidor, realizar los prototipos de baja y alta fidelidad.
Fase 3. Preparar el entorno de desarrollo e implementar la aplicación final de forma iterativa e incremental agregando en cada Sprint las nuevas funcionalidades que se validan al final y pasan los test correspondientes.
Fase 4. Preparar el contenido de la entrega final que incluye una presentación en texto con los puntos y las decisiones tomadas más importantes, una presentación en vídeo y una memoria final con las conclusiones y resultados obtenidos a lo largo de desarrollo del proyecto.
Riesgos de proyecto
página 16
Riesgo Grado Probabilidad Afectación Como anticiparComo actuar si pasa
Horas extras en el trabajo Riesgo mayor Alta Alta Aprovechar las horas de la comida para adelantar
TFM, llegar antes para dedicar tiempo por la
mañana
Enfermedad común Riesgo medio Baja Baja Evitar contacto con los enfermos.
Enfermedad y estado alarma Covid-19 Riesgo Alto Alta Alta Evitar contacto con los enfermos. Uso de
mascarilla si sales, teletrabajo con la empresa.
Necesidades formativas Riesgo Alto Media Alta Revisión de toda la documentación necesaria
antes de ponerse a desarrollar
Planificación inexacta Riesgo Medio Baja Alta Revisar las tareas pendientes de Backlog más a
menudo y replanificar las prioridades
Análisis, diseño y arquitectura
página 17
DCU-Diseño centrado en usuario:
Usuarios y contextos de uso.
Diseño conceptual.
Prototipado
Evaluación
Diseño técnico:
Casos de uso
Modelo de datos
Diseño de la arquitectura
página 18
Usuarios y contextos de uso
Mediante benchmarking realizar un análisis de público objetivo y sus
necesidades actuales:
soluciones similares o de competencia directa para conocer usuarios y sus
expectativas, tendencias del mercado y funcionalidades más usadas en las
aplicaciones
Perfiles de usuario
Agrupar los objetivos, las necesidades y las expectativas de los usuarios en función de
sus características:
paciente y médico donde ambos pueden realizar las mismas acciones, pero se han
diferenciado en el sistema por su perfil para dar una visibilidad correcta a los
usuarios
Diseño conceptual
página 19
Definir los actores finales y declarar los escenarios de uso de estos en
base a la información obtenida en la etapa anterior:
Definición de personas
Escenarios de uso
Flujos de interacción
Prototipado
página 20
La técnica de prototipado consiste en realizar un diseño inicial de la aplicación y que se divide en dos partes:
creación de un prototipo de baja fidelidad y otro de alta fidelidad.
Prototipo de baja fidelidad con sketching
página 21
Prototipo de alta fidelidad
página 22
página 23
Evaluación
Evaluación heurística mediante modelo Nielsen de la aplicacación y que ha cumplido con todos sus principios:
P1. Visibilidad del estado del sistema
P2. Coincidencia entre el sistema y el mundo real
P3. Control y libertad del usuario
P4. Coherencia y estándares
P5. Prevención de errores
P6. Reconocimiento antes que memoria
P7. Flexibilidad y eficiencia de uso
P8. Estética y diseño minimalista
P9. Ayudar al usuario a reconocer los errores, diagnosticarlos y recuperarse de ellos
P10. Ayuda y documentación
Patrón MVVMSu finalidad es de tratar desacoplar al máximo la interfaz de usuario de la lógica de la aplicación. Sus componentes son:
• El modelo (Model). Representa la capa de datos y/o la lógica de negocio. Contiene la información, pero nunca las acciones o servicios que la manipulan.
• La vista (View). Representa la información a través de los elementos visuales que la componen. Las vistas son activas, contienen eventos, comportamientos y enlaces a datos que.
• Modelo de vista (ViewModel). Es un actor intermediario entre el modelo y la vista, contiene toda la lógica de presentación y se comporta como una abstracción de la interfaz. La comunicación entre la vista y el viewmodel se realiza por medio los enlaces de datos (binders).
Diseño de la arquitectura
página 24
La arquitectura final resultante de la red social médica
página 25
Vista física
página 26
El proyecto final es una solución cliente-servidor, con componentes distribuidos entre las capas de Frontend y Backend.
Software, tecnologías, librerías y herramientas utilizadas:
página 27
Implementación y pruebas
Se utilizaron las herramientas acordadas para llevar a cabo un correcto desarrollo de la aplicación y del proyecto.
• Android Studio, como IDE de desarrollo
• Android Architecture Components, como patrón de diseño.
• PostgreSQL, como base de datos de código abierto.
• WebSocket como tecnología de comunicación sobre TCP entre cliente y servidor.
• Ubuntu OS, como servidor de backend. Oracle Virtual Box, como máquina virtual para montarlo.
• SpringBoot, como framework y Spring Tools, como herramienta de Eclipse para integraciones Spring
• REST, como protocolo de intercambio y manipulación de datos en los servicios.
• Hibernate, para definir las entidades de bbdd y JPA, para generar operaciones sobre las tablas.
• Liquibase, como gestor de cambios en bbdd y DTO, para encapsular y pasar los datos entre las capas
• JUnit4 y Mockito, para las pruebas unitarias y la automatización.
Se revisó la planificación y se encontraron algunas desviaciones debido a la situación actual de la pandemia de COVID-19 y el recién llegado el nuevo concepto de teletrabajo en la empresa, que requirió adaptaciones y ajustes a nivel personal y laboral, pero pudieron ser corregidos a tiempo no afectando a la línea temporal del trabajo final.
Se organizaron las clases siguiendo el modelo MVVM como se especificó en la fase de Análisis y Diseño.
Estructura de proyecto cliente
página 28
Encriptación de comunicación con HTTPS.
Para garantizar la seguridad de información intercambiada se encriptó la comunicación con un certificado auto firmado de tipo ssl, distribuyendo la clave privada y pública entre los participantes.
Se organizaron las clases siguiendo el modelo Spring Boot como se especificó en la fase de Análisis y Diseño.
Estructura de proyecto backend
página 29
• Ayudan a identificar las debilidades de la aplicación, los valores y verificar los casos de uso. Por norma general, se divide en tres partes principales, expresados mediante el concepto llamado "Pirámide de Cohn" que indica que cuanto más bajo se encuentra la capa en la pirámide, más acciones independientes puede cubrir y más fácil será desarrollarla.
• La primera capa, Unit (pruebas unitarias) se utiliza para verificar que los métodos sean correctos a través de las comparaciones ordinarias.
• La segunda capa, de integración o de servicios, se utiliza para probar la interacción del proyecto con otros componentes
• En la parte superior de la pirámide, se encuentran las pruebas de la interfaz de usuario
Pruebas finales
página 30
Pirámide de Cohn
Test de backend
página 31
Siguiendo la recomendación de Cohn, se definieron para Backend
todos los test necesarios y fueron pasados con éxito validando por
completo el funcionamiento del servidor.
página 32
Test de frontendPrueba Resultado Observaciones
Registro en el sistema OK Correcto, se dan de alta en el
sistema ambos perfiles
Login en el sistema OK Correcto, se realiza el login en el
sistema
Ver perfil de usuario OK Correcto, se visualizan los datos
de usuario
Listar usuarios OK Correcto, se listan los usuarios
registrados
Ver usuarios favoritos OK Correcto, se listan los usuarios
favoritos
Marcar como favorito OK Correcto, se guarda usuario como
favorito
Ver diálogos OK Correcto, se visualizan los
diálogos de usuario
Empezar un diálogo OK Correcto, se abre un diálogo
nuevo o ya anterior
Enviar un mensaje OK Correcto, se envía un mensaje al
destinatario
Visualizar un fichero OK Correcto, se visualiza el fichero
adjunto
Responder un mensaje OK Correcto, usuario lee y responde
el mensaje
Ver ficheros propios OK Correcto, se visualizan los
ficheros del almacén
Subir fichero OK Correcto, se sube el fichero al
almacén
Las diferentes APIs aplicación cliente
Carga en Sesión Profiler
Resultado final
página 33
• Se realizó una comparativa de análogos concluyendo que era necesario crear una nueva red social especializada con cliente móvil Android y se identificaron los requisitos de esta.
• Se evaluó el porcentaje de dispositivos de diferentes sistemas operativos disponibles en el mercado y se eligió el más popular, Android.
• Mediante la utilización de Android Studio, se desarrolló la aplicación que ha cumplido con todos los objetivos y requisitos establecidos.
• Mediante la utilización de Spring BootStudio, se desarrolló un Backend que realiza todo el registro de la información en una base de datos relacional.
• Se comprobó la funcionalidad de la aplicación y se demostró que todos los elementos de la aplicación funcionan correctamente y no dan errores.
• Se creó la documentación de uso y mantenimiento de la aplicación.
página 34
Mejoras futuras
• Como cualquier otro proyecto informático, puede y debe ser mejorado mediante anexo de nuevas funcionalidades y mejora de las existentes. En la comparación final del conjunto desarrollado se identificó que sería muy interesante tener también una versión web.
• También añadir más formatos de ficheros adjuntos como podrían ser los modelos STL.
• Añadir compresión de imágenes adjuntas
• Para terminar, una etapa más en el desarrollo de la aplicación sería lanzar una versión para el sistema operativo iOS, que es el segundo sistema operativo más popular del mercado.
página 35Conclusiones
• Todas las tareas se realizaron en tiempo y siguiendo la planificación prevista, siendo resueltas correctamente logrando con éxito el objetivo principal: crear una red social especializada que permita poner en contacto a pacientes con los médicos y especialistas entre sí, todo cómodamente utilizando una aplicación móvil en sus smartphones.
• El uso de las soluciones como Room, Retrofit 2 y RxJava ha sido casi un reto personal costando bastante al principio, pero avanzando a paso firme y aprendiendo las novedades.
• Las poderosas técnicas de DCU permitieron ampliar la perspectiva de la aplicación más allá del ámbito de programador, hasta los usuarios que la van a utilizar para comprender sus opiniones e impresiones