PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 OralData- Sistema de gestión de pacientes para prácticas clínicas Juan Camilo Ossa Guzmán Juan David Nanclares Pulgarín Trabajo de grado presentado como requisito parcial para optar al título de: Especialista en Ingeniería de Software Asesor(es) Alicia Osorio Builes Edwin Andrés Cubillos Julián Alberto Uribe Gómez Instituto Tecnológico Metropolitano - ITM Facultad de Ingenierías Departamento de Antioquia Medellín, Colombia 2024 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 1. RESUMEN Este proyecto, titulado “OralData - Sistema de Gestión de Pacientes para Prácticas Clínicas”, se centra en el desarrollo de una aplicación móvil diseñada para mejorar la gestión de pacientes en las consultas clínicas odontológicas para las prácticas de los estudiantes de odontología. A través de una metodología ágil, concretamente Scrum, se ha realizado un estudio de mercado para identificar Aplicaciones existentes con funcionalidades similares, como My Dental Clinic, Smile y Dentalink. A partir de las fortalezas y debilidades de estas aplicaciones, se ha propuesto un sistema que ofrece autogestión bilateral de programación y autorregistro de usuarios en la plataforma. La aplicación se desarrollará utilizando tecnologías como Flutter y Firebase, que permitirán a los estudiantes registrar y autenticar usuarios, gestionar perfiles, programar y cancelar citas y comunicarse con pacientes a través de chat en tiempo real. Además, proporcionará notificaciones para eventos importantes y garantizará la seguridad de los datos personales de los usuarios. El principal objetivo del desarrollo de OralData es mejorar la eficiencia y experiencia en las prácticas clínicas de los estudiantes de odontología, facilitando la gestión de pacientes y optimizando las tareas operativas. Se proyecta que el sistema ayude a superar los desafíos actuales en la formación práctica, mejorando tanto la calidad de la educación como la atención al paciente. Palabras Clave: Gestión de pacientes en Oral Data, prácticas clínicas odontológicas, aplicación móvil Oral Data, metodología ágil Scrum, Flutter, Firebase. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 2. ACRÓNIMOS GIT: Grupo de investigación en integración de soluciones con tecnología de información y comunicación MIRP: Máquinas Inteligentes y Reconocimiento de Patrones NWK: Capa de la red de pila ZigBee MDS: Escalamiento multidimensional PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 TABLA DE CONTENIDO 1. RESUMEN ........................................................................................................................ 2 2. ACRÓNIMOS .................................................................................................................... 3 3. INTRODUCCIÓN ............................................................................................................... 9 2.ANTECEDNETES Y MARCO TEÓRICO .................................................................................. 10 2.1 Antecedentes............................................................................................................................................ 10 2.2 Marco Teórico .......................................................................................................................................... 11 3 PLANTEAMIENTO DEL PROBLEMA .................................................................................... 14 3.1 Diagrama causa efecto ............................................................................................................................. 15 3.2 OBJETIVOS ......................................................................................................................................... 15 General ....................................................................................................................................................... 15 Específicos ................................................................................................................................................... 15 4. METODOLOGÍA ................................................................................................................. 16 4.1 Planificación, Gestión y Administración del Proyecto .............................................................................. 16 4.1.1. Requisitos del Proyecto .................................................................................................................... 16 4.1.2 Plan de Metodología Ágil .................................................................................................................. 18 4.1.3 Gestión Ágil ........................................................................................................................................ 19 4.1.4 Administración Ágil ............................................................................................................................ 21 4.1.5 Plan de Gestión de Riesgos ................................................................................................................ 23 4.1.6 Resultados de Plan de gestión de riesgos para Oral Data ................................................................. 25 4.1.7 Stakeholders ...................................................................................................................................... 34 4.1.8 Roadmap del Proyecto ...................................................................................................................... 34 4.1.9 Diagrama de Gant .............................................................................................................................. 36 4.1.10 Modelo de Datos ............................................................................................................................. 36 4.2. Ingeniería de Requisitos .......................................................................................................................... 41 4.2.1 Elicitación de Requisitos .................................................................................................................... 41 4.2.2 Descripción de los roles del área problemática (Funciones, información personal requerida para el sistema) ...................................................................................................................................................... 41 4.4 Descripción gráfica del proyecto en base a una infraestructura simulada .............................................. 43 4.5 Arquitectura con Diagrama Preconceptual .............................................................................................. 46 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 4.6 Requerimientos ........................................................................................................................................ 10 4.6.1 Historias de usuario ........................................................................................................................... 10 5.RESULTADOS Y DISCUSIÓN ................................................................................................ 12 5.1 Esquematización de resultados esperados ............................................................................................... 12 5.2 Arquitectura del Proyecto ........................................................................................................................ 15 5.3 Diagrama de Arquitectura ........................................................................................................................ 16 5.4 Descripción de Componentes ................................................................................................................... 18 5.5 Patrones de diseño ................................................................................................................................... 18 5.5.1 Patrones Arquitectónicos Utilizados ................................................................................................. 18 5.6 Resultados obtenidos en el desarrollo del software de Oral Data ........................................................... 19 5.6.1 Historias de Usuario en la infraestructura de Oral Data ................................................................... 19 5.6.2 Casos de Uso ...................................................................................................................................... 21 5.6.3 Requisitos Funcionales y No Funcionales .......................................................................................... 22 5.6.4 Integración de Imágenes ................................................................................................................... 23 5.6.5 Roles funcionales en Oral Data .......................................................................................................... 33 5.6.6 Descripción de Archivos .................................................................................................................... 39 5.6.7 Carpeta Models ................................................................................................................................. 40 5.6.8 Carpeta Admin ................................................................................................................................... 43 5.6.9 Carpeta Patients ................................................................................................................................ 46 5.6.10 Carpeta Services .............................................................................................................................. 49 5.6.11 Carpeta Student ............................................................................................................................... 50 Carpeta Repository ..................................................................................................................................... 65 6. CONCLUSIONES, RECOMENDACIONES Y TRABAJO FUTURO ............................................ 72 6.1 Tendencias y Desviaciones ....................................................................................................................... 72 Inciso 1 Recopilación de Datos .................................................................................................................... 72 Inciso 2 Análisis de Tendencias .................................................................................................................... 72 Inciso 3: Identificación de Desviaciones ...................................................................................................... 72 Inciso 4: Evaluación y Acción ....................................................................................................................... 72 Inciso 5: Seguimiento y acciones correctivas ............................................................................................... 73 6.2 Lecciones Aprendidas y Recomendaciones .............................................................................................. 73 6.2.1 Lecciones ........................................................................................................................................... 73 6.2.2 Recomendaciones ............................................................................................................................. 73 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.3 Conclusiones y Próximos Pasos ................................................................................................................ 74 1. REFERENCIAS ................................................................................................................. 75 8.ANEXO ................................................................................................................................ 76 8.1 Anexo A Cronograma de actividades ................................................................................................ 76 8.2 Anexo B Compromiso para el desarrollo de trabajos de grado ................................................................. 79 Información general ................................................................................................................................... 79 Estudiante(s) ............................................................................................................................................... 79 Asesor(es) ................................................................................................................................................... 79 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Tabla de Ilustraciones Ilustración 1. Diagrama causa efecto ................................................................................................................. 15 Ilustración 2. Matriz de riesgos .......................................................................................................................... 27 Ilustración 3. Evaluación de riesgo ..................................................................................................................... 33 Ilustración 4. Diagrama de Gant ......................................................................................................................... 36 Ilustración 5. Arquitectura simulada del proyecto de Oral Data. ....................................................................... 43 Ilustración 6. Diagrama preconceptual .............................................................................................................. 46 Ilustración 7. Backlog de product – OralData ..................................................................................................... 10 Ilustración 8. HU_RF 001 – Registrar pacientes ................................................................................................. 10 Ilustración 9. HU_RF Clasificar paciente ............................................................................................................. 11 Ilustración 10. HU_RF Visualización de horarios disponibles ............................................................................. 11 Ilustración 11. HU_RF Agendar Citas .................................................................................................................. 11 Ilustración 12. Vista funcional relacionada con HU_RF 001- Registrar pacientes.............................................. 12 Ilustración 13. Vista funcional relacionada con HU_RF 003- Clasificar pacientes.............................................. 13 Ilustración 14 Vista funcional relacionada con HU_RF 004- Gestionar horarios de disponibilidad ................... 14 Ilustración 15. Arquitectura de la app Oral Data en dispositivos móviles ......................................................... 16 Ilustración 16. Interfaz de usuario anónimo ...................................................................................................... 23 Ilustración 17. Formulario de registro en calidad de paciente........................................................................... 24 Ilustración 18. Formulario registro estudiantes ................................................................................................. 25 Ilustración 19. Agendamiento de citas odontológicas ....................................................................................... 26 Ilustración 20. Detalles pacientes ....................................................................................................................... 27 Ilustración 21. Valoración de pacientes ............................................................................................................. 28 Ilustración 22. Notificación de agendamiento de cita........................................................................................ 29 Ilustración 23. Detalles de la cita agendada ....................................................................................................... 30 Ilustración 24. Chata de oraldata entre paciente y estudiante .......................................................................... 31 Ilustración 25. Editar perfil ................................................................................................................................. 32 Ilustración 26. Rol de administrador de Oral Data ............................................................................................. 33 Ilustración 27. Administración de fichas clínicas y usuarios............................................................................... 34 Ilustración 28. Rol paciente ................................................................................................................................ 35 Ilustración 29. Formulario de consulta odontológica ......................................................................................... 36 Ilustración 30. Detalle de citas pacientes ........................................................................................................... 37 Ilustración 31. Panel de acceso rápido perfil de paciente .................................................................................. 38 Ilustración 32. Menu de visualización de Oral Data en su código fuente .......................................................... 39 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Tablas Tabla 1. Interpretación de la gestión agil ........................................................................................................... 21 Tabla 2. Tareas por rol de responsable .............................................................................................................. 23 Tabla 3. Tabla de plan de gestión de riesgos ...................................................................................................... 26 Tabla 4. Lista de chequeo para riesgo El product backlog ................................................................................. 28 Tabla 5. Lista de chequeo para riesgo Estimaciones incorrectas ....................................................................... 29 Tabla 6. Lista de chequeo para riesgo El Product Owner no comunica de forma efectiva ................................ 30 Tabla 7. Lista de chequeo para riesgo El equipo de desarrollo .......................................................................... 30 Tabla 8. Lista de chequeo para riesgo sprint planning ....................................................................................... 31 Tabla 9. Lista de chequeo para riesgo daily........................................................................................................ 32 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 3. INTRODUCCIÓN El proyecto "OralData - Sistema de gestión de pacientes para prácticas clínicas" surge de la necesidad de optimizar la gestión de pacientes en las facultades de odontología. En la actualidad, los estudiantes están experimentando dificultades al buscar pacientes y administrar sus prácticas clínicas de manera efectiva, lo cual está teniendo un impacto negativo en la calidad de su formación. Durante la investigación de mercado se descubrieron varias aplicaciones como My Dental Clinic, Smile y Dentalink. Estas Másterciones ofrecen características similares, pero también presentan ciertas limitaciones en diferentes aspectos. OralData es una solución innovadora que se basa en estas observaciones. Permite a los usuarios autogestionar tanto el agendamiento como el autorregistro, mejorando la experiencia y eficiencia de estudiantes y pacientes por igual. El proyecto tiene como objetivo proponer un sistema de gestión que esté enfocado en aplicaciones móviles para automatizar las tareas operativas relacionadas con los pacientes, con el fin de mejorar la eficiencia y la experiencia durante el proceso de prácticas clínicas. Para alcanzar este objetivo general, se han establecido los siguientes objetivos específicos: Entender las necesidades técnicas requeridas para el desarrollo de una aplicación web de gestión de pacientes en odontología; determinar las funcionalidades esenciales del sistema de gestión; crear un diseño orientado a la web que organice eficientemente los procesos clínicos; y finalmente, elaborar un sistema de gestión acorde con dichas necesidades. Este trabajo se compone de varios conceptos fundamentales. En primer lugar, se ofrece una descripción general del proyecto que abarca su pertinencia y justificación, así como los objetivos a alcanzar con el mismo. En este escrito se detalla el tema problemático que está siendo tratado, así como también se expone la importancia de la solución planteada. Después se explica detalladamente la metodología ágil aplicada en el proceso de desarrollo del proyecto, centrándose principalmente en Scrum. Además, se realiza una descripción exhaustiva de las tecnologías utilizadas en el proyecto, como Flutter y Firebase; destacando su contribución fundamental durante todo el proceso de creación de la aplicación. En primer lugar, se examina el déficit existente en la atención de pacientes en las escuelas de odontología en Colombia. Se discuten los efectos negativos que estos problemas tienen sobre la educación de los estudiantes y se argumenta a favor de implementar una solución tecnológica para abordar esta situación. A continuación, se detalla el diseño y desarrollo del sistema OralData, abarcando el modelo de datos utilizado, la arquitectura del sistema y los patrones arquitecturales aplicados. Además, se presentan las funcionalidades implementadas y cómo han sido diseñadas para satisfacer las necesidades identificadas. Por último, se evalúan los resultados obtenidos durante el proceso de desarrollo del sistema, considerando las pruebas y validaciones realizadas. Se examinan las lecciones aprendidas y se presentan recomendaciones para mejorar la plataforma OralData. Además, se plantea una estrategia sobre los próximos pasos a seguir para continuar perfeccionando esta aplicación. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 4. ANTECEDNETES Y MARCO TEÓRICO 4.1 Antecedentes El presente proyecto propone la creación de una plataforma en la cual los estudiantes de la facultad de odontología tanto de pregrado como posgrado puedan administrar a través de su usuario y su contraseña, los espacios de práctica y gestionar a las personas para ser atendidas durante las clínicas, ya que esto debe cumplirse como requisito para aprobar las competencias que cada clínica practica requiere. Después de una investigación de mercado se encuentran algunas aplicaciones con funcionalidades similares al software que se propone desarrollar. En primer lugar, se encontró, la aplicación de origen escandinava llamada My Dental Clinic, el cual es una herramienta útil para estudiantes, en el cual pueden obtener y gestionar pacientes. Dicha aplicación, permite la gestión de la información de pacientes, teniendo acceso en todo momento a dichos datos, adicionalmente, permite rastrear los gastos de la clínica, crear, imprimir, enviar tratamientos a los pacientes, tener colaboración entre profesores, de manera que varios estudiantes y profesores puedan atender al paciente al mismo tiempo. Además, permite tener respaldo de los datos de pacientes. (Dental Clinic App, s.f.) Dentro de dicha revisión, se encontró además, un software mexicano llamado Smile que está especializado en clínicas universitarias, el cual presenta similitudes a las del proyecto propuesto, entre estás se encuentran el agendamiento y control de citas de los pacientes por cada estudiante, registro de expediente clínico con notas de evolución y plan de tratamiento, control de actividades de estudiantes por parte de profesores e incluye otras funcionalidades como lo son controles de órdenes de laboratorio, imágenes médicas al expediente clínico, control de inventarios e ingresos económicos de la clínica; mostrando altos beneficios tanto en el ámbito clínico-académico como a nivel administrativo. (Software Dentalink, s.f.) De esta misma manera, y compartiendo gran cantidad de funcionalidades que presentan las aplicaciones anteriores, se encontró un software chileno llamado Dentalink, que además tienen un módulo integrado de toda la parte de contabilidad, ingresos y trazabilidad de los pacientes, cuentan también con un dashboard que permite por medio de graficas tener informes precisos y en tiempo real de las citas asignadas, pacientes agendados, pacientes en consulta y pagos online. (Software Dentalink, s.f.) En resumen, se encontraron 3 aplicaciones con gran robustez, las cuales presentan beneficios similares a los esperados al desarrollo propuesto. Estos son: ordenamiento de la agenda para evitar dificultades con la programación de citas, diligenciamiento de la historia clínica (almacenando de manera integral, eficiente y segura toda la información del paciente), obtención de reportes de gestión para reconocer puntos de mejora y facilitar la toma de decisiones. Una vez finalizada esta investigación, en la cual de describen las soluciones actuales, se concluye que la propuesta a desarrollar posee como valor agregado, la autogestión bilateral de agendamiento (tanto pacientes como estudiantes podrán gestionar su atención) y todo, a partir del autorregistro de usuarios en la plataforma (tanto pacientes como estudiantes). PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 4.2 Marco Teórico La gestión de pacientes es un componente esencial de la educación odontológica. Los estudiantes necesitan tener la oportunidad de practicar sus habilidades en pacientes reales para desarrollar las competencias necesarias para ejercer su profesión. Aprendizaje práctico: Es un enfoque de aprendizaje centrado en la experiencia de aprendizaje activo y en la aplicación de conocimientos para situaciones reales. Dicho enfoque, se basa en la teoría de aprendizaje experiencial de John Dewey, quien afirma que el conocimiento se construye a través de la experiencia y son los estudiantes quienes son los protagonistas de su propio aprendizaje. (Ausubel, Novak y Hanesian, 1978) Este aprendizaje, puede incluir actividades como resolución de problemas, exploración y experimentación, por tanto, los estudiantes construyen su propio conocimiento a medida que avanzan (Ausubel, Novak y Hanesian, 1978), incluyendo estrategias como el aprendizaje cooperativo y basado en el servicio, permitiendo abordar problemas en situaciones reales con el objetivo de beneficiar a la comunidad. Este tipo de aprendizaje es importante para la formación de los odontólogos, ya que les permite desarrollar las competencias necesarias para ejercer su profesión. En las áreas de la salud, dicho aprendizaje, se da a través de prácticas clínicas. Practicas clínicas odontológicas: Las prácticas clínicas en el área odontológica son esenciales para la formación de estudiantes, en ellas los estudiantes pueden aplicar los conocimientos adquiridos durante las clases teóricas en un entorno real (Universidad de Santiago de Compostela, 2023). Durante dichas prácticas, se realiza evaluación y tratamiento a pacientes, las cuales son realizadas bajo la supervisión de profesores con experiencia tanto en docencia como en atención clínicas. Las prácticas clínicas, incluyen adquisición de competencias de comunicación asistencial, gestión clínica, razonamiento y juicio crítico, por tanto, no solo aprenden a realizar procedimientos dentales, sino que también a comunicarse efectivamente con pacientes, gestionar citas, recursos y a tomar decisiones basados en evidencia (Universidad de Santiago de Compostela, 2023). Para desarrollar dichas prácticas, es necesario, contar con un sistema que permita realizar tareas administrativas, las cuales permitan realizar la gestión de pacientes. Sistemas de gestión de pacientes: Es una parte fundamental de la atención médica, en la cual se realizan procesos administrativos, en los cuales se coordina de punta a punta la atención al paciente. Durante la gestión, se recopila información del paciente, se realizan actividades administrativas, se gestionan las horas de atención, los profesionales que prestarán la atención con los profesionales de la red asistencial y se coordina los cuidados (F. Aguayo & R. Mella, 2015) Dicho proceso, implica, planificación, organización, motivación en la atención y control de provisión de cuidados a prestarse de manera oportuna, segura e integral, sustentado en políticas de cada centro de atención. (F. Aguayo& R. Mella, 2015). PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Los sistemas de gestión de pacientes han evolucionado significativamente en los últimos años, por tanto, su evolución ha estado marcada por los siguientes hitos: - En 1960 comienzan a usarse en la década de 1960, estos sistemas eran simples, dicha información se diligenciaba de manera manual en papel y era almacenada en carpetas físicas - En 1970 se comienza a usar tecnología informática, con sistemas que permitían a médicos y profesionales en salud, acceder a información de los pacientes de manera rápida y fácil. - En 1980: se introducen los primeros sistemas de gestión de pacientes con sistemas integrados, los cuales combinaban información de los pacientes como historial médico, resultado de exámenes médicos y prescripciones, consultando dicha información desde diferentes fuentes. - En 1990: Se comienza a desarrollar sistemas para gestión de pacientes en la web, permitiendo a profesionales de la salud consultar información de los pacientes desde cualquier lugar - En la década del 2000, se comienzan a realizar sistemas para gestión de pacientes para aplicaciones móviles - En la década del 2010, se introducen los sistemas para gestión en la nube, los cuales almacenan información de pacientes desde cualquier lugar con acceso a internet - En la década del 2020, se introduce el aprendizaje automático y la inteligencia artificial a los sistemas de gestión de pacientes, permitiendo tomar decisiones sobre el tratamiento de los pacientes Al ser la odontología una rama de la salud, la evolución de los sistemas de gestión de pacientes se ha visto influenciada por los sistemas de gestión de pacientes, en los cuales se hacen ajustes de acuerdo con las necesidades específicas del sector, por tanto, ha sido un reflejo de la evolución de la tecnología en los sistemas de gestión en salud. La gestión de pacientes de manera efectiva puede ayudar a recopilar información la cual permita comprender mejor las necesidades de los usuarios de manera que se pueda prestar una atención de calidad. Gestión de la calidad: Es un proceso llevado a cabo con el fin de mejorar la eficiencia y efectividad de las operaciones y servicios de una organización. Se enfoca en la mejora continua de los procesos, productos y servicios para satisfacer o superar las expectativas y necesidades de los clientes. Este proceso implica la recopilación y análisis de la información de los clientes para entender sus necesidades y expectativas, y luego utilizar esta información para desarrollar productos y servicios que satisfagan o superen estas expectativas (Definición ABC, gestión de la calidad) Esta, además, implica la implementación de sistemas y procedimientos para controlar y mejorar la calidad de los productos y servicios. Esto puede incluir la inspección de los productos o servicios, la realización de pruebas y auditorías, y la implementación de acciones correctivas cuando se detectan problemas de calidad. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 El desarrollo de un sistema que permita desarrollar un sistema de gestión en salud requiere un lenguaje de programación potente y flexible y un marco de desarrollo que permita amplia gama de bibliotecas y herramientas, como las presentadas a continuación: Flutter: Flutter es un avanzado kit de desarrollo de software creado por Google que permite a los desarrolladores construir aplicaciones de alta calidad para dispositivos móviles, web y de escritorio a partir de una única base de código. Utilizando el lenguaje de programación Dart, Flutter ofrece un enfoque innovador y eficiente para el desarrollo de aplicaciones, caracterizado por su capacidad de compilar código nativo, lo que garantiza un rendimiento óptimo en plataformas Android e iOS. Una de las características más destacadas de Flutter es su uso de widgets, componentes reutilizables que permiten crear interfaces de usuario personalizables y atractivas. Estos widgets pueden combinarse y estilizarse de múltiples formas, proporcionando una gran flexibilidad en el diseño de interfaces de usuario complejas y adaptables a diversas plataformas. El desarrollo con Flutter se beneficia enormemente de la función "hot reload", que permite a los desarrolladores ver los cambios en el código en tiempo real sin necesidad de reiniciar la aplicación. Esto acelera considerablemente el proceso de desarrollo y facilita la depuración. Además, Flutter es reconocido por su capacidad multiplataforma, permitiendo que una sola base de código pueda generar aplicaciones para iOS, Android, la web y sistemas de escritorio como Windows, macOS y Linux. Esta versatilidad, junto con una comunidad activa y un vasto ecosistema de paquetes y plugins, ha convertido a Flutter en una herramienta muy popular entre los desarrolladores que buscan crear aplicaciones modernas, eficientes y con una excelente experiencia de usuario. FireBase: Es una plataforma en la nube para el desarrollo de aplicaciones web y móvil. Está disponible para distintas plataformas (iOS, Android y web), con lo que es más rápido trabajar en el desarrollo. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 5. PLANTEAMIENTO DEL PROBLEMA La formación de los odontólogos requiere de un equilibrio entre la teoría y la práctica. Sin embargo, en los últimos años, las clínicas prácticas en las facultades de odontología de Colombia han enfrentado un déficit importante. Esto se debe a que los estudiantes, en gran medida, tienen dificultades para encontrar pacientes que les permitan desarrollar sus competencias prácticas y habilidades manuales, adquiridas inicialmente en la teoría (Rojas & Galvis, 2023). Este déficit puede afectar la calidad de la formación de los odontólogos y la atención que brindan a los pacientes. Los estudiantes que no tienen la oportunidad de practicar sus habilidades en pacientes reales pueden tener dificultades para adquirir la confianza y la experiencia necesarias para ejercer su profesión. Además, esto les genera un estancamiento académico ya que al no demostrar sus competencias estos reprueban y por ultimo los pacientes que reciben atención odontológica de estudiantes con poca experiencia pueden estar expuestos a un mayor riesgo de complicaciones. Todo esto, ha hecho que el proceso de gestión de pacientes en las facultades de odontología sea un proceso complejo y desafiante, generando dificultades para los estudiantes y profesores. Los profesionales de la salud deben dedicar mucho tiempo a tareas operativas, como la búsqueda de pacientes, el diligenciamiento de la historia clínica y la asignación de citas (F. Arevalo, 2015). La gestión de pacientes de manera tradicional, sin un sistema que permita automatizar estas tareas, es ineficiente y puede generar otras dificultades, como el aumento de los errores, la disminución de la productividad y la mala experiencia del paciente (Journal of Dental Education,2021). Actualmente no se cuenta con un sistema que sirva de puente directo entre los estudiantes y pacientes que permita la gestión, atención, fluidez y trazabilidad sin que exista un rol intermedio en las instituciones que en su mayoría de veces no cumple con estos requerimientos ya que usa una hoja de cálculo y no contempla una valoración acertada o información detallada que permita direccionar bien a los estudiantes para asignar sus clínicas, dejando un panorama de incertidumbre en los estudiantes para cumplir con los requisitos académicos necesarios para aprobar y continuar con su proceso de aprendizaje, estos actualmente tienen truncados estos procesos y les está generando retrasos por no aprobar los niveles o semestres a tiempo. Por otro lado, los pacientes no tienen la posibilidad de identificar la existencia de jornadas o clínicas de atención en las cuales ellos pueden acceder a servicios de forma gratuita o a un bajo costo. Dichas dificultades permiten evidenciar la necesidad de un sistema el cual permita realizar gestión, trazabilidad y obtención de pacientes por parte de los estudiantes para que puedan ejercer sus clínicas de atención y que los pacientes con pocos recursos tengan la posibilidad de acceder a una atención respaldada por un docente con amplia experiencia de manera gratuita o más económica. Por lo anterior que, para abordar este problema, es necesario implementar un sistema de gestión de pacientes que permita automatizar las tareas operativas ayudándole a los estudiantes a elegir, contactar y agendar pacientes a través de un sistema que permita mejorar la eficiencia, la seguridad y la experiencia entre paciente y el estudiante. ¿Es posible diseñar un sistema de gestión de pacientes para estudiantes de odontología que mejore la eficiencia y la experiencia en el proceso de las practicas clínicas? PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 5.1 Diagrama causa efecto https://drive.google.com/file/d/1S1QX03DzBY_dLFb9iUUoNMzbuxiyCwJj/view?usp=drive_link Ilustración 1. Diagrama causa efecto 5.2 OBJETIVOS General Proponer un sistema de gestión de pacientes orientado a aplicativos móviles para que los estudiantes de odontología que puedan automatizar las tareas operativas, mejorando la eficiencia y la experiencia en el proceso de prácticas clínica. Específicos Perceptivo: Comprender las necesidades técnicas que se tendrían al momento de diseñar una aplicación para gestión de pacientes para las facultades de odontología Aprehensivo: Seleccionar de las necesidades técnicas anteriormente establecidas las funcionalidades que debe llevar el sistema de gestión de pacientes en su diseño Comprensivo: Diseñar un sistema de gestión orientado a la web capaz de estructurar el proceso de prácticas clínicas Integrativo: Desarrollar un sistema de gestión de pacientes que cumpla con las necesidades técnicas anteriormente identificadas. https://drive.google.com/file/d/1S1QX03DzBY_dLFb9iUUoNMzbuxiyCwJj/view?usp=drive_link PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6. METODOLOGÍA El presente proyecto busca crear un aplicativo móvil para estudiantes de facultades de odontología, el cual facilite el proceso de gestión de pacientes, siendo desarrollado en .dart el cual es un lenguaje de programación flexible, con el uso del flutter y firebase debido a que este facilita la interacción con bases de datos relacionales y no relacionales las cuales se usarán en el proceso para almacenamiento de información de usuarios e historias clínicas y proporciona características de seguridad muy importante para proteger los datos de los pacientes. Teniendo en cuenta esto, se hace uso de .dart como marco para crear el frontend de la aplicación debido a que facilita la creación de interfaces de usuario, la creación de código modular y su alta compatibilidad con diferentes dispositivos móviles. Las imágenes de perfil de los usuarios y las solicitadas para la clasificación de pacientes se almacenarán en firebase. El desarrollo tendrá en cuenta el patrón MVVM, el cual mejora la seguridad de la aplicación y permite la mantenibilidad y separa la aplicación a través de capas. Esto, junto con la arquitectura responsiva, permitirá que la aplicación se vea bien en diferentes dispositivos y tamaños de pantalla, sin que se tenga que generar código adicional para esto, adicionalmente cargará gradualmente la aplicación, mejorando la experiencia. 6.1 Planificación, Gestión y Administración del Proyecto 6.1.1. Requisitos del Proyecto Requisitos Funcionales: 1. Registro y Autenticación de Usuarios: • El sistema debe permitir el registro de estudiantes y pacientes. • El sistema debe permitir la autenticación de usuarios registrados. 2. Gestión de Perfiles: • Los usuarios deben poder actualizar su información personal. • Los estudiantes deben poder subir una imagen de perfil. • Los pacientes deben poder subir una imagen de valoración y una imagen de perfil. 3. Gestión de Citas: • Los estudiantes deben poder agendar citas con pacientes. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 • Los estudiantes deben poder cancelar citas. • Los pacientes deben recibir notificaciones locales cuando se agenden o cancelen citas. • Los pacientes deben poder ver sus citas programadas. 4. Chat en Tiempo Real: • Los estudiantes y pacientes deben poder comunicarse a través de un chat en tiempo real. • Los usuarios deben recibir notificaciones locales cuando se envíe un nuevo mensaje en el chat. 5. Notificaciones: • Implementar notificaciones locales para eventos importantes como nuevas citas y nuevos mensajes de chat. Requisitos No Funcionales 1. Seguridad: • La aplicación debe garantizar la seguridad de los datos personales de los usuarios. • Los datos deben ser encriptados durante la transmisión. 2. Usabilidad: • La interfaz de usuario debe ser intuitiva y fácil de usar. • La aplicación debe ser accesible en dispositivos móviles. 3. Rendimiento: • La aplicación debe ser capaz de manejar múltiples usuarios simultáneamente. • La aplicación debe ser optimizada para funcionar eficientemente en dispositivos de gama baja. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.1.2 Plan de Metodología Ágil Metodología Ágil: Scrum Roles • Product Owner: Responsable de definir y priorizar el backlog del producto. • Scrum Master: Facilita el proceso Scrum y se asegura de que se sigan las prácticas ágiles. • Development Team: Equipo de desarrollo que implementa las funcionalidades del producto. Ceremonias 1. Sprint Planning: Reunión para planificar las tareas del sprint. 2. Daily Stand-up: Reuniones diarias para revisar el progreso y resolver impedimentos. 3. Sprint Review: Reunión al final del sprint para revisar y demostrar el trabajo realizado. 4. Sprint Retrospective: Reunión para reflexionar sobre el sprint y planificar mejoras para el siguiente sprint. Artefactos 1. Product Backlog: Lista priorizada de todas las funcionalidades y requisitos del proyecto. 2. Sprint Backlog: Lista de tareas seleccionadas para el sprint actual. 3. Incremento: Conjunto de funcionalidades completadas durante el sprint. Sprints: • Cada sprint tiene una duración de 2 semanas. • Al final de cada sprint, se debe entregar un incremento funcional del producto. Duración Total del Proyecto: 8 meses Sprint Duration: 2 semanas Total Sprints: 16 sprints Roles en Scrum • Product Owner: Juan Camilo Ossa PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 • Scrum Master: Juan David Nanclares • Development Team: Compuesto por los estudiantes de odontología y desarrolladores del proyecto. Ceremonias de Scrum • Sprint Planning: Reunión al inicio de cada sprint para planificar las tareas. • Daily Stand-up: Reuniones diarias de 15 minutos para revisar el progreso. • Sprint Review: Reunión al final de cada sprint para revisar y demostrar el trabajo realizado. • Sprint Retrospective: Reunión al final de cada sprint para reflexionar sobre el sprint y planificar mejoras. Artefactos de Scrum • Product Backlog: Lista priorizada de todas las funcionalidades y requisitos del proyecto. • Sprint Backlog: Lista de tareas seleccionadas para el sprint actual. • Incremento: Conjunto de funcionalidades completadas durante el sprint. 6.1.3 Gestión Ágil La gestión ágil se centra en el seguimiento del progreso del proyecto, la identificación y resolución de problemas y la adaptación a los cambios. Se basa en los principios de: • Transparencia: Todo el equipo debe tener acceso a la información sobre el estado del proyecto. • Inspección: El trabajo del equipo debe inspeccionarse regularmente para identificar problemas. • Adaptación: El equipo debe adaptarse a los cambios en las necesidades del proyecto. • Enfoque en el valor: El equipo debe centrarse en entregar valor al negocio. • Mejora continua: El equipo debe buscar constantemente formas de mejorar su proceso de trabajo. ¿Quién la lidera? La gestión ágil para el proyecto es liderada por un miembro del equipo que asume el rol de Scrum Master, quien tiene la responsabilidad de asegurar que el equipo siga la metodología Scrum y de remover los impedimentos que puedan afectar el progreso del proyecto. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 ¿Cuáles son las responsabilidades? Las responsabilidades de la gestión ágil incluyen: • Monitorear el progreso del proyecto. • Identificar y resolver problemas. • Gestionar los riesgos. • Comunicarse con las partes interesadas. • Facilitar la mejora continua. Componentes de la gestión ágil aplicados en el proyecto: • Tablero Kanban: Una herramienta visual que se utiliza para mostrar el estado del trabajo en curso. En este se pueden visualizar las tareas por hacer, que hay en proceso, que está en pruebas y que se ha • Gráficos de burndown: Gráficos que muestran la cantidad de trabajo restante en un sprint. Con esta herramienta se podrá monitorear el progreso del trabajo restante de los sprints • Herramientas de comunicación: Herramientas que se utilizan para facilitar la comunicación entre los miembros del equipo. Para estas se usarán Herramientas como Teams, Google meet, whatsapp y Zoom. Actividades de la gestión ágil seguidas en el proyecto: • Reuniones diarias de scrum: Ajustada al proyecto, se realizan 2 reuniones a la semana estilo daily, en las cuales se manejan los puntos a tener en cuenta de una daily de seguimiento a las tareas para ver que si se estén cumpliendo los objetivos del sprint y en caso de haber impedimentos realizar acciones para eliminarlos en el menor tiempo posible. • Reunión de revisión de sprint: Se programaron reuniones al final de cada sprint en la que el equipo muestra el trabajo completado y recibe feedback del Product Owner. • Reunión de retrospectiva de sprint: Se programó para el final de cada sprint, una reunión donde se reflexiona sobre el sprint que acaba de pasar para tener en cuenta aspectos a mejorar para los siguientes sprints. • Monitoreo del progreso del proyecto: Seguimiento del avance del proyecto en relación con el plan original. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 • Gestión de riesgos: Identificación de riesgos potenciales que puedan afectar el proyecto y desarrollo de planes de contingencia. • Comunicación con las partes interesadas: Mantener a las partes interesadas informadas sobre el progreso del proyecto. • Facilitar la mejora continua: Identificar oportunidades para mejorar el proceso de trabajo e implementar cambios. Tarea Rol responsable Monitorear el progreso del proyecto Scrum Master Identificar y resolver problemas Equipo de desarrollo Gestionar los riesgos Scrum Master Comunicarse con las partes interesadas Product Owner Facilitar la mejora continua Scrum Master Tabla 1. Interpretación de la gestión agil De la herramienta AzureDevops para la parte de gestión ágil en el proyecto, se hace uso de las siguientes funcionalidades: • Uso de tableros Kanban para visualizar el flujo de trabajo (actividades en estado por hacer, en progreso, listo para revisión, completado) • Visualización de informes para el seguimiento en tiempo real, se crearon allí gráficos Burndown • Integración con repositorio del proyecto. 6.1.4 Administración Ágil ¿Cómo se realizará la administración ágil del proyecto? La administración ágil del proyecto OralData se basa en los principios y prácticas de la metodología Scrum, que promueve un enfoque iterativo e incremental para el desarrollo de software. ¿Quién liderará la administración ágil del proyecto? El Scrum Master será el responsable de liderar la administración ágil del proyecto. El Scrum Master es un facilitador que guía al equipo en la adopción de los principios y prácticas Scrum, y ayuda a eliminar los impedimentos que puedan surgir durante el desarrollo del proyecto. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 ¿Cuáles son las responsabilidades del Scrum Master para administración ágil? Las responsabilidades del Scrum Master incluyen: • Facilitar las reuniones Scrum: Planificación del sprint, revisión del sprint, retrospectiva del sprint y reunión diaria. • Proteger el tiempo del equipo: Asegurar que el equipo tenga el tiempo y el espacio necesarios para trabajar de manera eficiente. • Servir como coach del equipo: Ayudar al equipo a mejorar sus habilidades y prácticas ágiles. • Promover la transparencia: Asegurar que todos los miembros del equipo tengan acceso a la información necesaria. ¿Cuáles son los componentes de la administración ágil del proyecto? Los componentes de la administración ágil del proyecto incluyen: • Tablero Kanban: Una herramienta visual para gestionar el flujo de trabajo y visualizar el progreso del equipo. • Gráficos Burndown: Herramientas para monitorear el progreso del trabajo restante en un sprint. ¿Cuáles son las actividades de la administración ágil del proyecto? Las actividades de la administración ágil del proyecto incluyen: • Revisión del sprint: El equipo demuestra el trabajo completado en el sprint al Product Owner y recibe feedback. • Retrospectiva del sprint: El equipo reflexiona sobre el sprint pasado y busca oportunidades de mejora para el próximo sprint. ¿Cuáles son las tareas a administrar con sus roles responsables? Tarea Rol Responsable Gestión del backlog del producto Product Owner Planificación del sprint Scrum Master, Equipo de desarrollo Revisión del sprint Product Owner, Scrum Master, Equipo de desarrollo Retrospectiva del sprint Scrum Master, Equipo de desarrollo Reunión diaria Scrum Master, Equipo de desarrollo Monitoreo del progreso Scrum Master, Equipo de desarrollo PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Eliminación de impedimentos Scrum Master, Equipo de desarrollo Comunicación con las partes interesadas Product Owner, Scrum Master Tabla 2. Tareas por rol de responsable Para esta parte, se hace uso de encuestas donde se recopila el feedback de los usuarios teniendo en cuenta encuestas de satisfacción y herramientas donde se documentan las lecciones aprendidas. 6.1.5 Plan de Gestión de Riesgos La gestión de riesgos es un componente importante en la planificación y ejecución de proyectos, debido a que permite responder a posibles desafíos que pueden comprometer los objetivos del proyecto, por tanto, hace posible la prevención de problemas antes de que estos ocurran, de manera que el equipo esté preparado para enfrentar situaciones imprevistas. Un plan para gestionar los riesgos resulta ser muy útil para este proyecto donde se implementa la metodología ágil, debido a que actúa como una guía estratégica en el flujo del proyecto, facilitando la colaboración entre los miembros del equipo, promueva la transparencia y la creación de un producto de alta calidad. Por tanto, a continuación, se detalla el Plan de Gestión de riesgos para el proyecto OralData, donde en cada etapa del plan, se asignan responsabilidades para la planificación, gestión y administración de riesgos, buscando que el proyecto avance de forma segura. Proceso de gestión de riesgos 1. Identificación de riesgos: Para esta etapa en la gestión de riesgos, se realizaron reuniones de lluvia de ideas, donde se identificaron posibles riesgos del proyecto, se documentaron los hallazgos. Planificación: el responsable de coordinar las sesiones fue el Scrum Master Gestión: El scrum Master documenta los riesgos hablados durante la sesión 2. Evaluación de los riesgos: Una vez los riesgos fueron identificados, en esta etapa se analizó para cada riesgo su causa raíz, consecuencia, probabilidad de ocurrencia e impacto (como se muestra en el punto XX), permitiendo priorizar los riesgos. Planificación: El Scrum master documentó la priorización de los riesgos basándose en su relevancia y la capacidad del equipo para manejarlos. Gestión: El Product Owner evaluó los riesgos desde la perspectiva del negocio. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Administración: Los responsables de administrar la matriz de riesgos construida fueron los miembros del equipo de desarrollo. 3. Priorización de riesgos: De acuerdo con los riesgos, en esta etapa se validó cuales riesgos atacar primero, de acuerdo con su impacto y probabilidad. Planificación: el Product Owner priorizó los riesgos, basándose en los elementos presentes en el backlog relacionados con ellos, buscando mantener el foco en las áreas más importantes. Gestión: El Scrum Master, se encargó de realizar la priorización, tomando decisiones sobre los riesgos abordados. Administración: El equipo de desarrolló tomó liderazgo de la administración de los riesgos, teniendo en cuenta que estuvieran presentes en los sprints. 4. Tratamiento de riesgos: En esta etapa, se definieron acciones para mitigar los riesgos, incluyendo estrategias de verificación y validación. Planificación: El responsable fue el equipo de desarrollo, quienes fueron responsables de desarrollar estrategias y acciones para mitigar los riesgos Gestión: El miembro del equipo con conocimiento en entrega continua es el responsable de la gestión de esta etapa, realizando pruebas para mitigar los riesgos. Administración: La administración en esta etapa, está a cargo del Scrum Master, quien administra el seguimiento del tratamiento de los riesgos. 5. Monitoreo y revisión: En esta etapa, se realiza seguimiento de los riesgos y revisión de la efectividad de los planes implementado, validando si se presentan cambios en la probabilidad e impacto de cada riesgo. Planificación: El responsable del equipo de entrega continua, realiza seguimiento y revisión de los riesgos. Gestión: El Scrum Master facilita las reuniones donde se revisa el estado de los riesgos. Administración: El Product Owner se asegura de que se actualice la lista de riesgos y además se asegura de que se mantenga alineada con los objetivos del producto. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.1.6 Resultados de Plan de gestión de riesgos para Oral Data Para el primer análisis, se tuvieron 2 reuniones donde el objetivo fue evaluar los riesgos en el ciclo de vida del producto, como resultado de las etapas de identificación y evaluación del riesgo, se construyó la siguiente tabla en conjunto: Rol/Evento/ Producto Item específico Riesgo Consecuencias del riesgo Probabilidad de ocurrencia Impacto Producto Product backlog El product backlog carece de alineación estratégica -Desviación de la visión y objetivos del producto -No se tiene claridad en los elementos del product backlog -el equipo de desarrollo trabaja en funcionalidades que no aportan al negocio -el producto final no satisface las necesidades del cliente - la entrega del proyecto puede retrasarse - Dificultades en la toma de decisiones que afectan la calidad y entrega del producto Muy probable Grave Producto Sprint backlog Estimaciones incorrectas -El equipo no tendrá suficiente tiempo para completar las tareas del sprint -el equipo podría estar sobrecargado de trabajo Muy probable Mayor PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 -pérdida de motivación del equipo Evento Sprint planning Inviabilidad en las expectativas - no se cumple con los objetivos del sprint -un equipo desmotivado - desalineación entre el equipo y el Product Owner Moderada Mayor Evento Daily larga discusión sobre problemas no relacionados - Falta de concentración y eficacia - desviación de la atención del objetivo principal de la reunión - no se planifica adecuadamente el trabajo del día - no se resuelven obstáculos Muy probable Significativo Rol Product Owner El Product Owner no comunica de forma efectiva las necesidades del producto al equipo de desarrollo - El equipo de desarrollo puede malinterpretar los requisitos del producto - construir funcionalidades que no cumplen con las expectativas del Product Owner. - Se pueden producir errores y defectos en el producto Moderada Grave Rol Equipo de desarrollo El equipo de desarrollo no escribe código de alta calidad - El producto final puede ser susceptible a errores - Producto difícil de mantener - Se tendrá problemas de escalabilidad Moderado Grave Tabla 3. Tabla de plan de gestión de riesgos PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 A partir de allí, se construyó la siguiente matriz, con ayuda de la Product Owner: Ilustración 2. Matriz de riesgos Entre las medidas usadas, se crearon listas de chequeo, las cuales son poderosas para la gestión de riesgos, porque garantizan que se consideren los aspectos importantes, se reduce la probabilidad de errores y se ayuda a prevenir errores y contratiempos. Entre las acciones de mitigación, para cada riesgo, se construyeron listas de validación y verificación: - Lista de chequeo para riesgo El product backlog carece de alineación estratégica (VyV) Nombre del item Descripción Si/No Propósito del producto ¿Todos los miembros entienden la misión y objetivos del producto? Involucrar stakeholders ¿Se incluye a los stakeholders en la validación del producto backlog? PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Herramientas de visualización de la visión ¿Se hizo uso de herramientas para la visualización de la visión? Identificación del público ¿Se tienen en cuenta usuarios potenciales y sus necesidades? Documentación del producto ¿Se tiene documentación donde se detalle visón del producto, propósito y público objetivo? Conexión con un product roadmap ¿Se conecta el product backlog con un elemento accionable en un product roadmap? disponibilidad del Product Backlog ¿Es el product backlog accesible para todos los miembros del equipo? Uso de herramientas adecuadas para creación ¿Se hace uso de herramientas que facilitan la gestión del product backlog? Revisión y retrospectivas ¿Se realizó una revisión del producto backlog? ¿y en caso de identificar elementos de mejora fueron ajustados? Tabla 4. Lista de chequeo para riesgo El product backlog PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 - Lista de chequeo para riesgo Estimaciones incorrectas (VyV) Nombre del Item Descripción Si/No Entendimiento historias de usuario Los miembros del equipo entendieron el detalle de las historias de usuario Capacitación uso de técnicas ¿Se capacitó al equipo en el uso de técnicas de estimación de acuerdo a cada tipo de tarea? Conocimiento y experiencia ¿Para las estimaciones, se tuvo en cuenta la experiencia y conocimiento de cada miembro del equipo? Estimación conjunta Se realizó estimación en conjunto con el equipo Dudas aclaradas En caso de haber dudas, ¿fueron estas resueltas? Dependencias externas ¿Se evitó tener dependencias externas o en caso de haberlas fueron estas dirigidas para atenderse lo más pronto? Técnicas de estimación Se aplicaron técnicas de estimación como Planning Poker, Wideband Delphi o T-Shirt Sizing Margen de error ¿Se tuvo en cuenta un margen de error para historias dependientes de tareas o respuestas de otros? Medidas correctivas ¿Se aplicaron medidas correctivas en caso de ser necesario? Tabla 5. Lista de chequeo para riesgo Estimaciones incorrectas PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 - Lista de chequeo para riesgo El Product Owner no comunica de forma efectiva las necesidades del producto al equipo de desarrollo Nombre del Item Descripción Si/No Plan de comunicación efectivo Se han implementado prácticas de comunicación efectiva. Requisitos del producto documentados Los requisitos del producto están claramente documentados. Equipo de desarrollo involucrado en la definición del producto El equipo de desarrollo ha definido el producto. Feedback oportuno y constructivo Se brinda feedback oportuno y constructivo al equipo de desarrollo. Tabla 6. Lista de chequeo para riesgo El Product Owner no comunica de forma efectiva - Lista de chequeo para riesgo El equipo de desarrollo no escribe código de alta calidad Nombre del Item Descripción Si/No Implementar prácticas de desarrollo de software: TDD, refactorización. Se implementan prácticas como TDD (Desarrollo Dirigido por Pruebas) y refactorización para mejorar la calidad del código. Realizar revisiones de código regulares Se realizan revisiones de código de forma regular para detectar y corregir errores, mejorar la legibilidad y asegurar la calidad del código. Asegurar que el código esté bien documentado El código está documentado de forma clara y precisa para facilitar su comprensión, mantenimiento y escalabilidad. Brindar capacitación al equipo de desarrollo en las mejores prácticas de desarrollo de software Se brinda capacitación al equipo de desarrollo en las mejores prácticas de desarrollo de software para mejorar sus habilidades y conocimientos. Tabla 7. Lista de chequeo para riesgo El equipo de desarrollo PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 - Lista de chequeo para riesgo sprint planning Inviabilidad en las expectativas Nombre del item Descripción Si/No Estimación de Esfuerzo Los integrantes del equipo realmente estimaron la cantidad de horas de trabajo necesarias para completar los elementos del backlog y la duración total de las actividades del sprint Asignación de Recursos Se determino las necesidades de recursos, se esclareció quién hará qué y calcular el trabajo propio, asegurando de que las asignaciones coincidan con la capacidad del equipo Definición de Criterios de Aceptación Se definió los criterios de aceptación para cada elemento del backlog Gestión de Dependencias Se identifico y gestiono las dependencias entre las tareas para minimizar los efectos de la falta de tiempo y asegurar que el trabajo pueda completarse en el tiempo asignado Revisión de Criterios de Aceptación Es de alta importancia asegurar de que cada elemento del backlog tenga criterios de aceptación claros y objetivos, para acelerar los debates durante la planificación y evitar malentendidos Revisión de la Planificación ¿El equipo si reviso el plan de sprint?, de esta manera se asegura de que todos los miembros estén cómodos con el objetivo y que este esté alineado con la visión estratégica y la hoja de ruta del producto Tabla 8. Lista de chequeo para riesgo sprint planning PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 - Lista de chequeo para riesgo daily larga discusión sobre problemas no relacionados Nombre del item Descripción Si/No Establecer un Tiempo Fijo ¿Se definió un tiempo específico para las reuniones diarias? Agenda Clara El equipo debe preparar una agenda que incluya los temas a discutir Líder de la Reunión El equipo debe de designar a un líder de la reunión que se encargue de mantener el enfoque en los temas de la agenda Reglas de Discusión Se de planear sobre qué se puede discutir y qué no, para evitar que se aborden temas no relacionados con el trabajo del sprint Seguimiento de Decisiones El grupo debe de Asegurarse de que todas las decisiones tomadas durante la reunión se documenten y se asignen responsabilidades claras para su seguimiento. Seguimiento de Problemas El equipo debe de utilizar herramientas de seguimiento de problemas para documentar Tabla 9. Lista de chequeo para riesgo daily PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Para el segundo análisis, se tuvo una tercera sesión para evaluar los riesgos, pero esta vez tuvo lugar la evaluación de riesgos del producto de software, donde a continuación se presentan los resultados de las etapas de identificación del riesgo, evaluación del riesgo y priorización de los riesgos. Ilustración 3. Evaluación de riesgo PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.1.7 Stakeholders Stakeholders Internos • Estudiantes de Odontología: Usuarios principales que utilizarán el sistema para gestionar sus prácticas clínicas. • Pacientes: Usuarios que serán gestionados por los estudiantes a través del sistema. • Facultad de Odontología: Institución educativa que supervisa las prácticas clínicas y el uso del sistema. Stakeholders Externos • Proveedores de Tecnología: Empresas o individuos que proporcionan soporte técnico y servicios de infraestructura. • Reguladores: Entidades gubernamentales que establecen las normativas para la educación y prácticas odontológicas. 6.1.8 Roadmap del Proyecto Fase 1: Inicio del Proyecto • Duración: 1 mes • Actividades: • Definición de objetivos y alcance del proyecto. • Identificación de stakeholders y recolección de requisitos. • Planificación inicial y creación del backlog del producto. Fase 2: Diseño y Planificación • Duración: 2 meses • Actividades: • Diseño de la arquitectura del sistema. • Diseño del modelo de datos. • Creación de prototipos de interfaz de usuario. • Planificación detallada de sprints. Fase 3: Desarrollo • Duración: 6 meses PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 • Actividades: • Implementación de funcionalidades en sprints iterativos. • Desarrollo de registro y autenticación de usuarios. • Desarrollo de gestión de perfiles. • Implementación de gestión de citas. • Desarrollo de chat en tiempo real. • Implementación de notificaciones locales. • Pruebas unitarias y de integración. Fase 4: Pruebas y Validación • Duración: 2 meses • Actividades: • Pruebas de usuario. • Validación de funcionalidades. • Corrección de errores y optimización del sistema. Fase 5: Implementación y Despliegue • Duración: 1 mes • Actividades: • Preparación del entorno de producción. • Despliegue de la aplicación en dispositivos móviles. • Capacitación de usuarios finales. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.1.9 Diagrama de Gant Ilustración 4. Diagrama de Gant 6.1.10 Modelo de Datos El modelo de datos del sistema OralData se estructura principalmente en las siguientes colecciones: • users • appointments • messages • available_slots Users Campo Tipo Descripción uid String Identificador único del usuario tipoDocumento String Tipo de documento del usuario numeroDocumento String Número de documento del usuario PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Campo Tipo Descripción name String Nombre del usuario email String Correo electrónico del usuario numcelular String Número de celular del usuario genre String Género del usuario bornDate Date Fecha de nacimiento del usuario role String Rol del usuario (estudiante/paciente) profImage String URL de la imagen de perfil imageUrl String URL de la imagen de valoración token String Token de notificación La tabla anterior nos especifica el siguiente contenido uid (String): Identificador único del usuario. Este campo almacena una cadena de texto que representa un ID único para cada usuario, utilizado para identificar a los usuarios de manera exclusiva en el sistema. TipoDocumento (String): Tipo de documento del usuario. Este campo almacena una cadena de texto que indica el tipo de documento de identificación del usuario (por ejemplo, cédula, pasaporte, etc.). numeroDocumento (String): Número de documento del usuario. Este campo almacena una cadena de texto que contiene el número del documento de identificación del usuario. name (String): Nombre del usuario. Este campo almacena una cadena de texto que contiene el nombre completo del usuario. email (String): Correo electrónico del usuario. Este campo almacena una cadena de texto que contiene la dirección de correo electrónico del usuario. numcelular (String): Número de celular del usuario. Este campo almacena una cadena de texto que contiene el número de teléfono celular del usuario. genre (String): Género del usuario. Este campo almacena una cadena de texto que indica el género del usuario (por ejemplo, masculino, femenino, etc.). PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 bornDate (Date): Fecha de nacimiento del usuario. Este campo almacena una fecha que representa la fecha de nacimiento del usuario. role (String): Rol del usuario. Este campo almacena una cadena de texto que indica el rol del usuario en el sistema, ya sea estudiante o paciente. profImage (String): URL de la imagen de perfil. Este campo almacena una cadena de texto que contiene la URL de la imagen de perfil del usuario. imageUrl (String): URL de la imagen de valoración. Este campo almacena una cadena de texto que contiene la URL de la imagen de valoración asociada al usuario. token (String): Token de notificación. Este campo almacena una cadena de texto que contiene el token utilizado para enviar notificaciones push al usuario. Appointments Campo Tipo Descripción id String Identificador único de la cita studentId String Identificador del estudiante patientId String Identificador del paciente date Date Fecha de la cita timeSlot String Hora de la cita clinicType String Tipo de clínica (niños/adultos) id (String): Identificador único de la cita. Este campo almacena una cadena de texto que representa un ID único para cada cita, utilizado para identificar las citas de manera exclusiva en el sistema. studentId (String): Identificador del estudiante. Este campo almacena una cadena de texto que contiene el ID del estudiante asociado a la cita, permitiendo identificar al estudiante que atenderá la cita. patientId (String): Identificador del paciente. Este campo almacena una cadena de texto que contiene el ID del paciente asociado a la cita, permitiendo identificar al paciente que será atendido. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 date (Date): Fecha de la cita. Este campo almacena una fecha que representa el día en que se llevará a cabo la cita. timeSlot (String): Hora de la cita. Este campo almacena una cadena de texto que indica el intervalo de tiempo asignado para la cita (por ejemplo, "10:00 AM - 11:00 AM"). clinicType (String): Tipo de clínica. Este campo almacena una cadena de texto que indica el tipo de clínica en la que se llevará a cabo la cita, especificando si es una clínica para niños o adultos. messages Campo Tipo Descripción senderId String Identificador del remitente receiverId String Identificador del receptor message String Contenido del mensaje timestamp Date Fecha y hora del mensaje senderId (String): Identificador del remitente. Este campo almacena una cadena de texto que representa el ID único del usuario que envía el mensaje, permitiendo identificar al remitente en el sistema. receiverId (String): Identificador del receptor. Este campo almacena una cadena de texto que representa el ID único del usuario que recibe el mensaje, permitiendo identificar al receptor en el sistema. message (String): Contenido del mensaje. Este campo almacena una cadena de texto que contiene el contenido del mensaje enviado entre usuarios. timestamp (Date): Fecha y hora del mensaje. Este campo almacena la fecha y hora en que se envió el mensaje, permitiendo rastrear cuándo se realizó la comunicación. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Available_slots Campo Tipo Descripción date Date Fecha del slot disponible timeSlot String Hora del slot disponible clinicType String Tipo de clínica (niños/adultos) available Boolean Disponibilidad del slot date (Date): Fecha del slot disponible. Este campo almacena una fecha que representa el día en que hay un slot (intervalo de tiempo) disponible para una cita. timeSlot (String): Hora del slot disponible. Este campo almacena una cadena de texto que indica el intervalo de tiempo disponible para una cita (por ejemplo, "10:00 AM - 11:00 AM"). clinicType (String): Tipo de clínica. Este campo almacena una cadena de texto que indica el tipo de clínica en la que está disponible el slot, especificando si es una clínica para niños o adultos. available (Boolean): Disponibilidad del slot. Este campo almacena un valor booleano que indica si el slot está disponible (true) o no (false). Relaciones entre las colecciones • users - appointments: Los usuarios (estudiantes y pacientes) están relacionados con las citas. Un estudiante puede tener múltiples citas y un paciente puede estar agendado en múltiples citas. • users - messages: Los usuarios pueden enviar y recibir mensajes. Cada mensaje tiene un remitente y un receptor. • users - available_slots: Los estudiantes gestionan los slots disponibles para agendar citas. • appointments - messages: Los mensajes pueden estar relacionados con las citas, facilitando la comunicación entre estudiantes y pacientes respecto a las citas. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.2. Ingeniería de Requisitos 6.2.1 Elicitación de Requisitos Se realizaron entrevistas a 2 personas con el objetivo de conocer el estado del proceso (una de la Universidad Cooperativa de Colombia y otra de la universidad de Antioquia), las cuales se adjuntan como hipervínculo: entrevista elicitación.docx Entrevista elicitación UCC.mp4 Entrevista elicitacion UdeA.mp4 Luego de revisar el proceso, con los profesores, quienes serían dueños del producto a realizar, se acordó que estos tendrán un rol de visualización para temas de historias clínicas. 6.2.2 Descripción de los roles del área problemática (Funciones, información personal requerida para el sistema) Paciente: Es la persona que requiere atención médica. Puede realizar las siguientes actividades: • Registrarse en el sistema. • Diligenciar encuesta de clasificación • Cancelar una cita. https://correoitmedu.sharepoint.com/:w:/s/Grupo_especializacin_Software/EVjkK1IRN5BOjFoYqOwLUMsB9RRVfQOHoqDI8zWcSVs_dQ https://correoitmedu.sharepoint.com/:v:/s/Grupo_especializacin_Software/EaMLuZ6zDLxEjm7WNLArQvQB0z02ibKByAUJTRGXXbSmxw?e=pUnu7A https://correoitmedu.sharepoint.com/:v:/s/Grupo_especializacin_Software/EanOGLLYsINNmSRNUprIsJwB9LY_KcLgdBZXQc4v78H9yQ?e=hw1tsO PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Estudiante: Es el alumno que está cursando la asignatura. Puede realizar las siguientes actividades: • Visualizar los pacientes en la base de datos. • Agendar una cita. • Cancelar una cita. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.3 Descripción gráfica del proyecto en base a una infraestructura simulada Ilustración 5. Arquitectura simulada del proyecto de Oral Data.1 Componentes Principales Aplicación Móvil Función: La interfaz de usuario con la cual interactúan los usuarios finales. Conexiones: Se conecta con el backend móvil y con las API personalizadas. Backend Móvil Función: Gestión central de las aplicaciones móviles, incluyendo la lógica de negocio y la interacción con bases de datos y otros servicios. Plataformas de las API Gestión de Usuarios Móviles: Maneja las cuentas y autenticación de usuarios. Políticas de la Aplicación: Define y aplica reglas y configuraciones de uso. Almacenamiento: Gestión de datos almacenados, tanto en bases de datos como en otros repositorios. 1 Fuente: Elaboración propia PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Notificaciones: Envío de mensajes y alertas a los dispositivos móviles. Base de Datos: Almacena información estructurada y no estructurada. Ubicación: Servicios de geolocalización y manejo de datos de ubicación. Conectores Función: Permiten la integración con diferentes servicios y protocolos. SOAP: Protocolo estándar para intercambio de información estructurada en la implementación de servicios web. API REST: Arquitectura de transferencia de estado representacional para la interacción con servicios web. ICS (Integration Cloud Service) : Servicios de integración en la nube para conectar diferentes aplicaciones y servicios. Servicios en la Nube: VMware: Ofrece soluciones de virtualización. Microsoft Hyper-V: Proveedor de servicios de virtualización. AWS (Amazon Web Services): Proveedor de servicios en la nube que ofrece una variedad de soluciones para almacenamiento, bases de datos, cómputo, etc. Azure: Plataforma de servicios en la nube de Microsoft. IBM Cloud: Proveedor de servicios en la nube de IBM, incluyendo soluciones de inteligencia artificial, blockchain, IoT, etc. Flujo de Información La Aplicación Móvil interactúa directamente con el Backend Móvil y las API Personalizadas. El Backend Móvil maneja la lógica de negocio y la interacción con las plataformas de las API, incluyendo la gestión de usuarios, políticas de la aplicación, almacenamiento, notificaciones, bases de datos y servicios de ubicación. Las API Personalizadas permiten la integración específica y personalizada con otras aplicaciones y servicios, usando conectores como SOAP, API REST y ICS. Los Conectores permiten la conexión del sistema con diferentes Servicios en la Nube, facilitando la escalabilidad y flexibilidad del sistema. PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Los Servicios en la Nube ofrecen la infraestructura necesaria para alojar y operar las aplicaciones y servicios, proporcionando soluciones escalables y manejables. Esta arquitectura modular y escalable permite una gestión eficiente de aplicaciones móviles, integrando múltiples servicios y garantizando la interacción fluida entre diferentes componentes del sistema. 9 6.5 Arquitectura con Diagrama Preconceptual https://drive.google.com/file/d/1UWM0giwLd_H_d_J0pdLn0ZbYMPL1ckFe/view?usp=sharing Ilustración 6. Diagrama preconceptual https://drive.google.com/file/d/1UWM0giwLd_H_d_J0pdLn0ZbYMPL1ckFe/view?usp=sharing 10 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 6.6 Requerimientos 6.6.1 Historias de usuario En la Ilustración 4, se presenta el backlog de Oral Data, el cual está dividido en 3 épicas que contienen las 3 grandes funcionalidades principales de la aplicación, las cuales son registro en plataforma, agendamiento de citas y registro de la historia clínica Ilustración 7. Backlog de product – OralData Cada historia de usuario contiene un requerimiento y criterios de aceptación de dicha historia, a continuación, se presentan algunas de las historias de usuario con requerimientos funcionales de la aplicación. A continuación, en las Figuras 4, 5 6 y 7 se muestra el detalla de algunas de las historias de usuario del proyecto Ilustración 8. HU_RF 001 – Registrar pacientes 11 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Ilustración 9. HU_RF Clasificar paciente Ilustración 10. HU_RF Visualización de horarios disponibles Ilustración 11. HU_RF Agendar Citas 12 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 7.RESULTADOS Y DISCUSIÓN 7.1 Esquematización de resultados esperados Vistas funcionales: En las siguientes figuras, se presentan las vistas funcionales correspondientes a las historias de usuario presentadas: Ilustración 12. Vista funcional relacionada con HU_RF 001- Registrar pacientes 13 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Ilustración 13. Vista funcional relacionada con HU_RF 003- Clasificar paciente 14 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Ilustración 14 Vista funcional relacionada con HU_RF 004- Gestionar horarios de disponibilidad 15 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 7.2 Arquitectura del Proyecto El sistema de gestión de pacientes para prácticas clínicas (OralData) se basa en una arquitectura de tres capas, utilizando Flutter para el desarrollo de la aplicación móvil y Firebase como backend. Las tres capas principales son: 1. Capa de Presentación: Interfaz de usuario desarrollada en Flutter. 2. Capa de Lógica de Negocio: Implementación de la lógica de la aplicación, incluidas las funcionalidades de gestión de usuarios, citas y chat. 3. Capa de Datos: Almacenamiento y gestión de datos utilizando Firebase Firestore y Firebase Auth. 2. Componentes Principales • Aplicación Móvil (Flutter): Interfaz de usuario y lógica de negocio. • Firebase Auth: Autenticación y gestión de usuarios. • Firebase Firestore: Almacenamiento de datos. • Firebase Storage: Almacenamiento de imágenes de perfil y valoración. • Firebase Cloud Messaging (FCM): Envío de notificaciones locales. 16 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 7.3 Diagrama de Arquitectura https://drive.google.com/file/d/1vs0m_CxRWAYiSND7tEQ907rBDkk1Gn25/view?usp=sharing Ilustración 15. Arquitectura de la app Oral Data en dispositivos móviles La imagen anterior es el diagrama de arquitectura para la aplicación de OralData, desarrollada con Flutter y Dart, a continuación, se describe cada componente del diagrama: OralData App: Es la aplicación móvil desarrollada en Dart. Firebase SDK Integrado con Dart: La aplicación OralData utiliza el SDK de Firebase, que está integrado con el lenguaje Dart. Firebase Firestore (Database): Firebase Firestore se utiliza para la gestión de la base de datos, almacenando información relevante como las citas, los pacientes y los estudiantes. Las flechas indican que el SDK de Firebase en Dart interactúa con Firestore. Firebase Storage (Storage): https://drive.google.com/file/d/1vs0m_CxRWAYiSND7tEQ907rBDkk1Gn25/view?usp=sharing 17 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Firebase Storage se utiliza para el almacenamiento de archivos, como imágenes de panorámicas dentales, dentaduras, entre otros. El SDK de Firebase en Dart interactúa con el servicio de almacenamiento. Firebase Auth (Authentication): Firebase Authentication se utiliza para la autenticación de usuarios, garantizando que solo los usuarios autorizados puedan acceder a la aplicación OralData. El SDK de Firebase en Dart interactúa con el servicio de autenticación. Funciones en Nube: Las funciones en la nube de Firebase se utilizan para ejecutar lógica en el backend, como el procesamiento de datos de las citas o el envío de notificaciones. Estas funciones pueden interactuar con Firebase Firestore y Firebase Storage. Configuración Remota de Backend: Indica la configuración remota del backend, que se realiza a través de Internet para actualizar y gestionar la aplicación OralData de manera eficiente. Aplicación Móvil: Los dispositivos móviles con la aplicación OralData instalada se conectan a Internet para interactuar con el backend configurado remotamente, permitiendo a los usuarios agendar y gestionar citas odontológicas 18 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 7.4 Descripción de Componentes • Aplicación Móvil (Flutter): Proporciona la interfaz de usuario y maneja la lógica de presentación. Los usuarios pueden registrarse, iniciar sesión, gestionar citas y comunicarse a través del chat. • Firebase Auth: Maneja la autenticación de usuarios, incluyendo el registro y el inicio de sesión. • Firebase Firestore: Base de datos NoSQL que almacena información de usuarios, citas, mensajes de chat y tokens de notificación. • Firebase Storage: Almacena imágenes de perfil y de valoración. • Firebase Cloud Messaging (FCM): Servicio de mensajería que permite enviar notificaciones locales a los dispositivos móviles de los usuarios. 7.5 Patrones de diseño 7.5.1 Patrones Arquitectónicos Utilizados Modelo-Vista-Controlador (MVC) El patrón MVC separa la aplicación en tres componentes principales: el modelo, la vista y el controlador. En el proyecto: Modelo: Representado por las clases como ̀ Patient`, `PatientDiligency`, ̀ MyUser`, `AppointmentSlot`, que manejan la lógica de datos y la interacción con Firebase. Vista: Representada por las páginas y widgets de Flutter como `ProfilePage`, `HomePage`, `AppointmentDetailsPage`, etc., que manejan la interfaz de usuario. Controlador: Representado por los métodos y funciones en las páginas y los archivos de API (`firebase_api.dart`, `auth_api.dart`, etc.), que manejan la lógica de negocio y la interacción entre la vista y el modelo. 19 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Proveedor de Servicios (Service Provider) Este patrón se usa para encapsular la lógica de negocio y los servicios de la aplicación en clases de servicio. En el proyecto, los archivos `firebase_api.dart`, `auth_api.dart` y `notificationservices.dart, actúan como proveedores de servicios que abstraen las operaciones con Firebase y otras funcionalidades de la aplicación. Repositorio (Repository Pattern) El patrón Repositorio se usa para separar la lógica de acceso a datos de la lógica de negocio. Este patrón se puede observar en la forma en que se ha estructurado la interacción con Firebase a través de archivos de API como `firebase_api.dart`, `agenda_api.dart`, `Appointment_api.dart`, etc. Estos archivos sirven como repositorios que manejan la comunicación con Firebase Firestore y otros servicios de Firebase. Singleton El patrón Singleton asegura que una clase tenga solo una instancia y proporciona un punto de acceso global a esa instancia. En aplicaciones Flutter, esto se puede ver en la instancia de Firebase que se inicializa una sola vez y se usa en toda la aplicación. Factory Method El patrón Factory Method se usa para crear objetos sin especificar la clase exacta de objeto que se creará. Esto se puede ver en métodos como `fromJson` y `toJson` en tus modelos de datos (`Patient`, `MyUser`), que manejan la creación de instancias de estas clases a partir de datos JSON. Observer (Observador) Este patrón permite que un objeto notifique a otros objetos sobre cambios en su estado. En el contexto de Firebase, las actualizaciones en tiempo real de Firestore utilizan un mecanismo similar al patrón Observer, donde los cambios en los datos se notifican a los listeners registrados. 7.6 Resultados obtenidos en el desarrollo del software de Oral Data 7.6.1 Historias de Usuario en la infraestructura de Oral Data 1. Registro de Paciente 20 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Historia de Usuario: Como paciente, quiero registrarme en la aplicación para poder acceder a los servicios de gestión de citas. Criterios de Aceptación: • El paciente debe poder ingresar su información personal, incluyendo nombre, correo electrónico, teléfono y contraseña. • El sistema debe verificar que el correo electrónico no esté registrado previamente. • El paciente debe recibir una confirmación de registro exitoso. 2. Agendamiento de Citas Historia de Usuario: Como estudiante, quiero agendar citas con pacientes para gestionar mis prácticas clínicas. Criterios de Aceptación: • El estudiante debe poder seleccionar un paciente, una fecha y un horario disponible. • El sistema debe verificar la disponibilidad del horario seleccionado. • El estudiante y el paciente deben recibir una notificación de la cita agendada. 3. Gestión de Disponibilidad Historia de Usuario: Como estudiante, quiero gestionar mi disponibilidad para que pueda agendar pacientes en los horarios disponibles. Criterios de Aceptación: • El estudiante debe poder agregar, modificar y eliminar horarios de disponibilidad. • El sistema debe evitar la duplicación de horarios. • La disponibilidad debe actualizarse en tiempo real. 4. Comunicación a través del Chat Historia de Usuario: Como paciente, quiero comunicarme con el estudiante a través del chat para resolver dudas antes de la cita. Criterios de Aceptación: • El paciente debe poder iniciar una conversación con el estudiante. • Ambos usuarios deben recibir notificaciones de nuevos mensajes. 21 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 • El chat debe permitir el envío de texto e imágenes. • 7.6.2 Casos de Uso Caso de Uso: Registro de Paciente Actor Principal: Paciente Precondiciones: El usuario no debe estar registrado. Flujo Principal: 1. El paciente accede a la pantalla de registro. 2. El paciente ingresa su información personal. 3. El sistema valida los datos ingresados. 4. El sistema registra al paciente y envía una confirmación. Flujos Alternativos: • Si el correo electrónico ya está registrado, el sistema muestra un mensaje de error. Caso de Uso: Agendamiento de Citas Actor Principal: Estudiante Precondiciones: El estudiante debe estar autenticado. Flujo Principal: 1. El estudiante selecciona un paciente y una fecha. 2. El estudiante elige un horario disponible. 3. El sistema verifica la disponibilidad del horario. 4. El sistema registra la cita y notifica al estudiante y al paciente. Flujos Alternativos: • Si el horario no está disponible, el sistema muestra un mensaje de error. 22 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 7.6.3 Requisitos Funcionales y No Funcionales Requisitos Funcionales 1. Registro y Autenticación: • El sistema debe permitir el registro de pacientes y estudiantes. • El sistema debe autenticar a los usuarios antes de permitirles acceder a las funcionalidades. 2. Gestión de Citas: • Los estudiantes deben poder agendar, modificar y cancelar citas. • Los pacientes deben poder ver sus citas agendadas. 3. Gestión de Disponibilidad: • Los estudiantes deben poder gestionar sus horarios de disponibilidad. • El sistema debe evitar la duplicación de horarios. 4. Chat: • El sistema debe permitir la comunicación en tiempo real entre estudiantes y pacientes. Requisitos No Funcionales 1. Seguridad: • La información personal de los usuarios debe estar protegida mediante autenticación y cifrado. • El acceso a los datos debe estar restringido según el rol del usuario. 2. Performance: • El sistema debe ser capaz de manejar múltiples usuarios concurrentes sin degradar el rendimiento. • Las acciones de gestión de citas y disponibilidad deben reflejarse en tiempo real. 3. Usabilidad: 23 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 • La interfaz de usuario debe ser intuitiva y fácil de usar. • Las notificaciones deben ser claras y proporcionar feedback adecuado a los usuarios. 7.6.4 Integración de Imágenes Usuario anónimo Ilustración 16. Interfaz de usuario anónimo Pantalla inicial de la aplicación cuando un usuario no se ha registrado y cuando este le da en registrarse existe la posibilidad de identificarse con el rol con el que va a interactuar. 24 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Registro de Paciente: Captura de pantalla de la pantalla de registro para pacientes Ilustración 17. Formulario de registro en calidad de paciente. Estas interfaces son las que representan la metodología de registro en calidad de paciente, en estas se pide información referente a la necesidad que se tiene en la disciplina de atención de odontología. 25 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Registro de Estudiante: Captura de pantalla de la pantalla de registro para estudiantes. Ilustración 18. Formulario registro estudiantes Esta interfaz, es la que relaciona el registro a nivel de formulario para los usuarios que se encuentran en calidad de estudiante, este registro se mantiene principalmente cuando el dominio de correo es institucional. 26 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Proceso de agendamiento: Capturas de pantalla del proceso de agendamiento desde la gestión de disponibilidad horaria rol estudiante Ilustración 19. Agendamiento de citas odontológicas Aquí el estudiante tiene la posibilidad de parametrizar su horario y días disponibles para las practicas clínicas, el sistema solo permite crear agendas a partir del día actual y hasta máximo un mes. 27 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Detalles usuario registrado como paciente Ilustración 20. Detalles pacientes Una vez parametrizada la disponibiilidad el estudiante podra visualizar el listado de pacientes que se han registrado en la aplicación, donde al dar clic en el icono de informacion, podrá valorar si el paciente es idoneo para sus prácticas clínicas. 28 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PARA LA GENTE Código FDE 088 Versión 06 Fecha 24-02- 2020 Metodologia de valoracion de pacientes Ilustración 21. Valoración de pacientes En caso de ser un paciente idóneo para su atención con el icono de agregar podrá agregar el paciente a su listado de pacientes, donde posteriormente podrá agendar a este. 29 PROPUESTA DE PROYECTO DE GRADO O INGENIERÍA PA