INFO-LIT-RAM-2021

Vista previa del material en texto

UNIVERSIDAD NACIONAL DE PIURA 
FACULTAD DE INGENIERÍA INDUSTRIAL 
Escuela Profesional de Ingeniería Informática 
 
TESIS 
“DESARROLLO DE UNA APLICACIÓN MÓVIL UTILIZANDO FLUTTER Y 
FIREBASE PARA REALIZAR EL SEGUIMIENTO DE LOS TRATAMIENTOS 
FARMACOLÓGICOS DE UN PACIENTE” 
 
PARA OPTAR EL TITULO PROFESIONAL DE 
INGENIERO INFORMÁTICO 
 
PRESENTADO POR: 
Br. LUIS FERNANDO LITANO RAMOS 
ASESOR 
 MSc. VICTOR HUGO VALLE RIOS 
Co ASESOR 
ING. DALIA PAMELA VILCHEZ HOLGUIN 
 
LÍNEA DE INVESTIGACIÓN: 
INFORMÁTICA, ELECTRÓNICA Y TELECOMUNICACIONES 
SUB LINEA DE INVESTIGACIÓN: 
COMPUTACIÓN 
 
PIURA-PERU 
2021 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DEDICATORIA 
A mi madre Verónica Ramos Juárez, a mi abuela y 
segunda mamá, Francisca Juárez Ramos y a la 
casualidad más bonita de mi vida Sheila M., quienes 
me brindaron su apoyo emocional e incondicional 
durante el tiempo que escribía esta tesis. 
 
 
 
 
 
AGRADECIMIENTO 
A mi asesor Mg. Víctor Hugo Valle Ríos y mi co-asesora Ing. Dalia Pamela Vílchez Holguín 
por sus conocimientos, paciencia y tiempo para el desarrollo y culminación de la presente 
investigación. 
A los docentes de la escuela profesional de Ingeniería Informática por su bagaje de 
conocimiento e inculcarme sapiencias y valores que han contribuido a mi formación 
profesional. 
A mis amigos quienes dentro de sus posibilidades aportaron su granito de arena y finalmente, 
a todas aquellas personas, que de una u otra manera fueron artífices de este proyecto. 
Autor 
 
 
ÍNDICE 
RESUMEN .................................................................................................................... 1 
ABSTRACT .................................................................................................................. 2 
INTRODUCCIÓN ........................................................................................................ 3 
I. ASPECTOS DE LA PROBLEMÁTICA ................................................................ 4 
1.1 DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA ............................. 4 
1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN ...................... 5 
1.2.1. Problema General ....................................................................................... 5 
1.2.2. Problemas Específicos ................................................................................. 5 
1.3 JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN .............. 5 
1.4 OBJETIVOS ........................................................................................................ 7 
1.4.1 Objetivo General .................................................................................... 7 
1.4.2 Objetivos Específicos .............................................................................. 7 
1.5 DELIMITACIÓN DE LA INVESTIGACIÓN ................................................ 7 
1.5.1 DELIMITACIÓN ESPACIAL .............................................................. 7 
1.5.2 DELIMITACIÓN TEMPORAL ........................................................... 7 
II. MARCO TEÓRICO ................................................................................................ 8 
2.1 ANTECEDENTES DE LA INVESTIGACIÓN ............................................... 8 
2.2 BASES TEÓRICAS .......................................................................................... 10 
2.2.1. Tratamientos Farmacológicos .................................................................. 10 
2.2.2. Adherencia al Tratamiento ...................................................................... 10 
2.2.3. eSalud.......................................................................................................... 10 
2.2.4. mSalud ........................................................................................................ 12 
2.2.5. Lenguajes de programación de alto nivel ............................................... 12 
2.2.6. Dart ............................................................................................................. 12 
2.2.7. Flutter ......................................................................................................... 13 
2.2.8. Android Studio .......................................................................................... 14 
2.2.9. Firebase ...................................................................................................... 15 
2.2.10. Bases de datos NoSql ............................................................................... 16 
2.2.11. Cloud Firestore ........................................................................................ 17 
2.2.12. Scrum........................................................................................................ 18 
2.3 GLOSARIOS DE TÉRMINOS BÁSICOS ..................................................... 24 
2.4 MARCO REFERENCIAL ............................................................................... 25 
 
 
2.4.1 La Salud en el Perú .................................................................................... 25 
2.4.2 Ley de Protección de Datos Personales – Ley N° 29733 ......................... 25 
2.5 HIPÓTESIS ....................................................................................................... 26 
2.5.1 Hipótesis General ....................................................................................... 26 
2.5.2 Hipótesis Específicas .................................................................................. 26 
2.6 DEFINICIÓN Y OPERACIONALIZACIÓN DE VARIABLES ................. 26 
2.6.1 Variable de Trabajo ................................................................................... 26 
2.6.2 Operacionalización de la Variable ............................................................ 27 
III. MARCO METODOLÓGICO ............................................................................ 28 
3.1. ENFOQUE Y DISEÑO ................................................................................... 28 
3.2. MÉTODOS Y PROCEDIMIENTOS ............................................................. 28 
3.2.1. El equipo Scrum ................................................................................... 28 
3.2.2. Definición de “Hecho” .......................................................................... 28 
3.2.3. Eventos Scrum ...................................................................................... 29 
3.2.4. Historia de Usuario ............................................................................... 29 
3.2.5. Product Backlog .................................................................................... 30 
3.2.6. Sprint N° 1 ............................................................................................. 33 
3.2.7. Sprint N° 2 ............................................................................................. 46 
3.2.8. Sprint N° 3 ............................................................................................. 51 
3.2.9. Sprint N° 4 ............................................................................................. 61 
3.2.10. Sprint N° 5 ............................................................................................. 68 
3.2.11. Sprint N° 6 ............................................................................................. 75 
3.2.12. Estructura NoSQL en Firestore .......................................................... 77 
3.3. TÉCNICAS E INSTRUMENTOS .................................................................. 78 
3.4. ASPECTOS ÉTICOS ...................................................................................... 78 
IV. RESULTADOS Y DISCUCIÓN .........................................................................79 
4.1. RESULTADOS ................................................................................................ 79 
4.1.1. Indicadores de agilidad ........................................................................ 79 
4.1.2. Indicadores de eficiencia ...................................................................... 80 
4.1.3. Indicadores de utilidad ......................................................................... 83 
4.1.4. Indicadores de usabilidad .................................................................... 85 
3.1. DISCUSIÓN ..................................................................................................... 86 
V. CONCLUSIONES ................................................................................................. 89 
 
 
VI. RECOMENDACIONES ...................................................................................... 90 
VII. REFERENCIAS BIBLIOGRÁFICAS ............................................................. 91 
VIII. ANEXOS ............................................................................................................ 94 
6.1. ANEXO N° 1 .................................................................................................... 94 
6.2. ANEXO N° 2 .................................................................................................... 95 
6.3. ANEXO N° 3 .................................................................................................... 96 
6.4. ANEXO N° 4 .................................................................................................... 97 
6.5. ANEXO N° 5 .................................................................................................... 98 
6.6. ANEXO N° 6 .................................................................................................. 100 
 
TABLAS 
Tabla 1: Operacionalización de la variable (Fuente: Elaboración propia) .......................... 27 
Tabla 2: Product Backlog (Fuente: Elaboración propia) ..................................................... 33 
Tabla 3: Sprint N° 1 (Fuente: Elaboración propia) ............................................................. 34 
Tabla 4: Sprint N° 2 (Fuente: Elaboración propia) ............................................................. 46 
Tabla 5: Sprint N° 3 (Fuente: Elaboración propia) ............................................................. 51 
Tabla 6: Sprint N° 4 (Fuente: Elaboración propia) ............................................................. 61 
Tabla 7: Sprint N° 5 (Fuente: Elaboración propia) ............................................................. 69 
Tabla 8: Sprint N° 6 (Fuente: Elaboración propia) ............................................................. 76 
Tabla 9: Técnicas e instrumentos (Fuente: Elaboración propia) ......................................... 78 
Tabla 10: Resumen de la información extraída de la aplicación (Fuente: Elaboración propia)
 ............................................................................................................................................. 83 
 
 ÍNDICE DE GRÁFICOS 
Gráfico 1: Distribución de los agentes de salud en el Perú (Organización Mundial de la Salud, 
2020). ................................................................................................................................... 25 
Gráfico 2: Velocidad de incremento - Scrum (Fuente: Elaboración propia) ....................... 79 
Gráfico 3: Promedio del incremento por Sprint (Fuente: Elaboración propia) ................... 80 
Gráfico 4: Porcentaje de uso de CPU en 20 ejecuciones (Fuente: Elaboración propia) ..... 81 
Gráfico 5: Megabystes de RAM utilizados en 20 ejecuciones (Fuente: Elaboración propia)
 ............................................................................................................................................. 82 
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059999
 
 
Gráfico 6: Megabits utilizados en 20 ejecuciones (Fuente: Elaboración propia) ................ 83 
Gráfico 7: Evolución del promedio del porcentaje de adherencia ....................................... 84 
Gráfico 8: Comparativa de los tratamientos con supervisión y sin supervisión (Fuente: 
Elaboración propia) ............................................................................................................. 85 
Gráfico 9: Comparativa entre el tiempo de demora al registrar y actualizar el 1° tratamiento 
(Fuente: Elaboración propia) ............................................................................................... 85 
 
 
 
 ÍNDICE DE FIGURAS 
Figura 1. Relación entre los componentes de la eSalud (European Space Agency, 2004) . 11 
Figura 2. Ejemplo de una petición asíncrona a un servidor utilizando Dart (Google, s. f.-a).
 ............................................................................................................................................. 13 
Figura 3. Logo de Flutter (Google, s. f.-d). ......................................................................... 13 
Figura 4. Creación de una aplicación móvil básica en Flutter (Google, s. f.-g). ................. 14 
Figura 5. Planes de Firebase (Google, s. f.-c). .................................................................... 16 
Figura 6. Tres diferentes bases de datos NoSql (Meier y Kaufmann, 2019). ...................... 17 
Figura 7. Relación entre las colecciones, los documentos y los datos (Google, s. f.-f). ..... 18 
Figura 8 Proceso Scrum (Cevallos, 2015) ........................................................................... 29 
Figura 9: Selección del tipo de proyecto Flutter en Android Studio (Fuente: Elaboración 
propia) .................................................................................................................................. 35 
Figura 10: Configuración del proyecto Flutter en Android Studio (Fuente: Elaboración 
propia) .................................................................................................................................. 35 
Figura 11: Nombre del paquete del proyecto Flutter (Fuente: Elaboración propia) ........... 36 
Figura 12: Estructura de archivos y Widget por defecto en Flutter (Fuente: Elaboración 
propia) .................................................................................................................................. 36 
Figura 13: Creación del emulador para ejecutar la aplicación (Fuente: Elaboración propia)
 ............................................................................................................................................. 37 
Figura 14: Ejecución de la aplicación por defecto en Flutter (Fuente: Elaboración propia)
 ............................................................................................................................................. 38 
Figura 15: Listado de paquetes a utilizar (Fuente: Elaboración propia).............................. 39 
Figura 16: Tarea 002 (Fuente: Elaboración propia) ............................................................ 40 
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78060002
 
 
Figura 17: Estructura para almacenar los términos y condiciones en Firebase (Fuente: 
Elaboración propia) ............................................................................................................. 41 
Figura 18: Tarea 003 (Fuente: Elaboración propia) ............................................................ 41 
Figura 19: Configuración de reglas en Firebase (Fuente: Elaboración propia) ................... 42 
Figura 20: Estructura para almacenar los perfiles de usuario en Firebase (Fuente: 
Elaboración propia) ............................................................................................................. 43 
Figura 21: Tarea 005 (Fuente: Elaboración propia) ............................................................43 
Figura 22: Diagrama de flujo de los procesos principales de la aplicación (Fuente: 
Elaboración propia) ............................................................................................................. 45 
Figura 23: Estructura para almacenar los centros de salud en Firebase (Fuente: Elaboración 
propia) .................................................................................................................................. 46 
Figura 24: Tarea 008 (Fuente: Elaboración propia) ............................................................ 47 
Figura 25: Estructura para almacenar enfermedades en Firebase (Fuente: Elaboración 
propia) .................................................................................................................................. 47 
Figura 26: Tarea 009 y Tarea 010 (Fuente: Elaboración propia) ........................................ 48 
Figura 27: Estructura para almacenar los tipos de aplicación de un medicamento (Fuente: 
Elaboración propia) ............................................................................................................. 48 
Figura 28: Estructura para almacenar los tipos de medicamentos (Fuente: Elaboración 
propia) .................................................................................................................................. 49 
Figura 29: Estructura para almacenar las medicinas (Fuente: Elaboración propia) ............ 49 
Figura 30: Tarea 011 y Tarea 012 (Fuente: Elaboración propia) ........................................ 50 
Figura 31: Estructura para almacenar los tratamientos (Fuente: Elaboración propia) ........ 52 
Figura 32: Tarea 013 (Fuente: Elaboración propia) ............................................................ 53 
Figura 33: Estructura para almacenar los medicamentos de un tratamiento (Fuente: 
Elaboración propia) ............................................................................................................. 54 
Figura 34: Tarea 014 (Fuente: Elaboración propia) ............................................................ 55 
Figura 35: Tarea 015 (Fuente: Elaboración propia) ............................................................ 56 
Figura 36: Estructura para almacenar el historial de consumo de medicamentos (Fuente: 
Elaboración propia) ............................................................................................................. 57 
Figura 37: Almacenamiento de archivos con Firebase Storage (Fuente: Elaboración propia)
 ............................................................................................................................................. 57 
Figura 38: Tarea 016 (Fuente: Elaboración propia) ............................................................ 58 
Figura 39: Tarea 017 (Fuente: Elaboración propia) ............................................................ 59 
Figura 40: Tarea 018 (Fuente: Elaboración propia) ............................................................ 60 
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059967
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059967
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059970
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059970
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059975
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059975
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059981
 
 
Figura 41: Interacción del servicio en segundo plano (Fuente: Elaboración propia) .......... 62 
Figura 42: Estructura para almacenar las notificaciones de usuario (Fuente: Elaboración 
propia) .................................................................................................................................. 64 
Figura 43: Tarea 021 (Fuente: Elaboración propia) ............................................................ 65 
Figura 44: Tarea 022 (Fuente: Elaboración propia) ............................................................ 66 
Figura 45: Tarea 023 (Fuente: Elaboración propia) ............................................................ 67 
Figura 46: Tarea 024 (Fuente: Elaboración propia) ............................................................ 68 
Figura 47: Tarea 025 (Fuente: Elaboración propia) ............................................................ 70 
Figura 48: Tarea 026 (Fuente: Elaboración propia) ............................................................ 71 
Figura 49: Tarea 027 (Fuente: Elaboración propia) ............................................................ 72 
Figura 50: Tarea 028 (Fuente: Elaboración propia) ............................................................ 73 
Figura 51: Tarea 029 (Fuente: Elaboración propia) ............................................................ 74 
Figura 52: Tarea 030 (Fuente: Elaboración propia) ............................................................ 75 
Figura 53: Tarea 031, 032 y 033 (Fuente: Elaboración propia) .......................................... 77 
Figura 54: Estructura de la base de datos NoSQL desarrollada para Firestore ................... 77 
 
file:///D:/UNP/Tesis2.0/ProyectoActual/TESIS-FINAL.docx%23_Toc78059986
1 
 
RESUMEN 
La presente investigación tuvo como objetivo desarrollar una aplicación móvil que permita 
realizar el seguimiento de los tratamientos farmacológicos de un paciente. El objetivo surgió 
al identificar la necesidad en las personas de contar con una mejor cultura del cuidado de la 
salud, específicamente en el cumplimiento de los tratamientos farmacológicos. 
Para desarrollar la aplicación móvil se utilizó Flutter, un Framework de nueva generación, 
junto con Firebase que proporciona servicios en la nube de manera gratuita, hasta cierto 
límite, como almacenamiento No SQL, autenticación, almacenamiento de archivos, etc. 
La aplicación se desarrolló utilizando la metodología Scrum con un incremento de 0.86 story 
points por hora. Flutter cuenta con una buena eficiencia en el uso de recursos; se obtuvo en 
promedio un 32.84% de uso de CPU, 185 Megabytes de uso de memoria RAM y 7.96 
Megabits de transferencia de datos. 
Al finalizar el desarrollo la aplicación fue publicada en Google Play Store para que sea 
descargada e instalada por cualquier usuario. 
El porcentaje de adherencia refleja el progreso de un tratamiento farmacológico, fue 
obtenido para cada tratamiento registrado en la aplicación lo que permitió realizar un 
posterior análisis donde se encontró que el promedio del porcentaje de adherencia de todos 
los usuarios fue de 54.21% lo cual es alarmante. 
Se observó una evolución de la adherencia al utilizar la aplicación móvil, ya que aumentó 
de 31.18% en el primer tratamiento a 72.47% en el último, en el caso de usuarios con más 
de dos tratamientos. Otra comparativa resaltante son los tratamientos supervisados por otros 
usuarios que obtuvieron un 85.95% de adherencia mientras que los sin supervisión un 
51.50%. En cuanto al uso de la interfaz gráfica en la primera creación de un tratamiento fue 
de 59.71 segundos y en la primera actualización fue de 28.05 segundos. 
 
Palabras clave: Flutter, Firebase, Scrum, Tratamientos, Farmacológicos. 
2 
 
ABSTRACT 
The objective of this research was to develop a mobile application that allows the monitoring 
of a patient's pharmacological treatments. The objective arose from identifying the need in 
people to have a better health care culture, specifically in compliance with pharmacological 
treatments. 
Flutter, a new generation Framework, was used to develop the mobile application, together 
with Firebase that provides cloud services for free, up to a certain limit, such as No SQL 
storage, authentication, file storage, etc. 
The application was developed using the Scrum methodology with an increase of 0.86 story 
points per hour. Flutter has a good efficiencyin the use of resources; an average of 32.84% 
of CPU use, 185 Megabytes of RAM memory use and 7.96 Megabits of data transfer were 
obtained. 
At the end of the development, the application was published in the Google Play Store to be 
downloaded and installed by any user. 
The percentage of adherence reflects the progress of a pharmacological treatment, it was 
obtained for each treatment registered in the application, which allowed a subsequent 
analysis to be carried out where it was found that the average percentage of adherence of all 
users was 54.21%, which is alarming. . 
An evolution of adherence was observed when using the mobile application, since it 
increased from 31.18% in the first treatment to 72.47% in the last, in the case of users with 
more than two treatments. Another outstanding comparison is the treatments supervised by 
other users who obtained an 85.95% adherence while those without supervision a 51.50%. 
Regarding the use of the graphical interface in the first creation of a treatment it was 59.71 
seconds and in the first update it was 28.05 seconds. 
 
Key words: Flutter, Firebase, Scrum, Treatments, Pharmacological. 
3 
 
INTRODUCCIÓN 
El día a día del mundo globalizado ha llevado a las personas a concentrarse en realizar 
diversas actividades las cuales casi nunca incluyen un aspecto esencial e infravalorado de 
nuestra vida como es la salud. Esto ha causado que se les dé poca importancia a los 
tratamientos farmacológicos pues la mayoría del tiempo se ven abandonados y con poca o 
nula supervisión pese a que estos son los más comunes para combatir las enfermedades. 
Estos problemas a corto y largo plazo pueden ser críticos ya que posibilitan recaídas o 
inclusive volver a la enfermedad más resistente lo cual ocasiona el uso de fármacos más 
potentes. 
En la presente investigación se desarrolló una aplicación móvil como una herramienta 
tecnológica para resolver los dos problemas principales mencionados anteriormente. Para 
ello se empleó Flutter, un SDK de nueva generación para desarrollar aplicaciones móviles y 
Firebase, una suite de servicios para desarrollar y desplegar aplicaciones de forma rápida y 
sencilla. 
Para lograr su objetivo la aplicación se encargó de realizar el seguimiento en cada momento 
del tratamiento farmacológico, además de permitir ser supervisado por terceros de confianza 
seleccionados por el usuario. 
Dado que el desarrollo del software requería cambios continuos y agiles se utilizó Scrum 
como marco de trabajo. El equipo Scrum estuvo integrado por el asesor, la co-asesora y el 
investigador, cada uno asumió un rol Scrum, además se realizó eventos Scrum como Sprints, 
Sprint Review, Retrospective, etc. 
La importancia de este proyecto de investigación radica en contribuir a educar a las personas 
sobre cuán importante es la salud, empezando desde algo pequeño pero significativo, como 
el incentivar la culminación exitosa los tratamientos farmacológicos, ya que al seguirlos de 
manera estricta utilizando la aplicación móvil permitió a las personas combatir 
adecuadamente la enfermedad diagnosticada. 
4 
 
I. ASPECTOS DE LA PROBLEMÁTICA 
1.1 DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA 
Actualmente vivimos en un mundo donde gran parte de la población se dedica a trabajar 
durante todo el día, donde cada individuo está lleno de responsabilidades y pendientes 
por realizar descuidando algo fundamental en la vida como es la salud. 
La mayoría de las personas acuden a consulta médica sólo cuando están enfermas, 
inclusive una vez diagnosticada la enfermedad no se siguen el tratamiento 
farmacológico prescrito por su médico. 
Según Díez, Eladi y Farré Albaladejo (2002, p. 15) un tratamiento farmacológico 
consiste en curar o aliviar las enfermedades o síntomas utilizando medios 
farmacológicos. Se puede añadir que la ingesta de los fármacos se produce cada cierto 
tiempo y en una dosis determinada por el personal de salud que prescribe el tratamiento 
farmacológico. 
En 2009, la Organización Mundial de la Salud (OMS) citada por PFZIER determinó 
que el grado en que el paciente cumple o no con el tratamiento se le llama adherencia. 
Las consecuencias de tener un bajo o nulo grado de adherencia resultan en un fracaso 
terapéutico, lo cual aumenta la probabilidad de recaídas y agravamiento de la 
enfermedad, es decir que esta se vuelva más resistente y tenga que ser tratada con 
fármacos más potentes. En base a esto se infiere que un tratamiento con nula o 0% de 
adherencia es un tratamiento completamente abandonado, por el contrario, un 
tratamiento con 100% adherencia es un tratamiento completado correctamente. 
Los problemas relacionados con el incumplimiento del tratamiento se observan en todas 
las situaciones en las que éste tiene que ser administrado por el propio paciente, 
independientemente del tipo de enfermedad (Organización Mundial de la Salud, 2013a). 
Un motivo por el cual se da el abandono de los tratamientos farmacológicos en pacientes 
es por la falsa sensación de estar curados. Por ejemplo, existen personas que cuando 
están en un tratamiento farmacológico y sienten que sus síntomas empiezan a 
desaparecer, deciden abandonarlo con la idea de que ya están completamente curados, 
desconociendo las consecuencias perjudiciales de dicha decisión. 
Los tratamientos farmacológicos también pueden ejecutarse incorrectamente, esto se da 
cuando el fármaco se tenía que ingerir a cierta hora, pero el paciente por estar realizando 
otras actividades lo ingiere fuera del horario establecido o inclusive no lo llega a ingerir. 
5 
 
Otro motivo es la casi nula supervisión del tratamiento por un tercero, si bien es cierto 
que a cierta edad cada persona es responsable por las decisiones que toma, muchas de 
ellas hoy en día no son en beneficio de la salud, por este motivo para un paciente es 
necesario que el progreso de su tratamiento sea supervisado por un alguien más, que se 
encargue de verificar continuamente que los fármacos, la dosis y el horario en el cual se 
ingieren, sean los correctos. 
Por último, tanto para el paciente como para la persona que lo supervisa es necesario 
contar con un indicador que refleje en tiempo real el estado del tratamiento 
farmacológico. 
Por los motivos expuestos es necesario realizar el seguimiento de los tratamientos 
farmacológicos de una manera fácil, segura y confiable. 
1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN 
1.2.1. Problema General 
¿De qué manera se podría realizar el seguimiento de los tratamientos farmacológicos 
de un paciente utilizando la tecnología móvil? 
1.2.2. Problemas Específicos 
• ¿Cómo se podría contribuir a evitar el abandono de los tratamientos 
farmacológicos de un paciente? 
• ¿De qué manera se podría proporcionar una herramienta para supervisar los 
tratamientos farmacológicos de un paciente? 
• ¿De qué manera se podrían evaluar los tratamientos farmacológicos de un 
paciente? 
1.3 JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN 
Los tratamientos farmacológicos son los más utilizados para combatir las 
enfermedades, pero muchas veces no son completados correctamente. 
En 2003, el Dr. Derek Yach, Director Ejecutivo de Enfermedades No Transmisibles y 
Salud Mental de la OMS declaró que el incumplimiento de un tratamiento es la 
principal causa de que no se obtengan todos los beneficios que los medicamentos 
pueden proporcionar a los pacientes, causando complicaciones médicas y 
psicosociales de la enfermedad, reducción de la calidad de vida de los pacientes, 
aumento de la resistencia farmacológica (poca efectividad de los medicamentos), así 
como el desperdicio de recursos asistenciales. 
6 
 
Por ejemplo, hay enfermedades que son tratadas utilizando pastillas proporcionadas 
por el seguro de salud público. Si una persona no consigue terminar el tratamiento 
correctamente, es decir lo abandona o no lo ejecuta como debería ser, esta enfermedad 
puededebilitar el cuerpo del paciente para que adquiera otra enfermedad. Esta nueva 
enfermedad muchas veces es más complicada que la anterior por lo cual se le aplicaría 
un nuevo tratamiento con fármacos más potentes ocasionando un mayor gasto en 
salud. En pocas palabras la poca o nula adherencia a los tratamientos farmacológicos 
por parte de los pacientes ocasiona un aumento de los gastos públicos en salud y a su 
vez aumenta la crisis en este sector debido a que como se menciona en ComexPeru 
(2020) los establecimientos de salud presentan una infraestructura precaria, 
equipamiento obsoleto, inoperativo o insuficiente, es decir sus recursos son muy 
limitados. 
La situación mencionada anteriormente se ve reflejada en que muchas veces la 
cantidad de pacientes supera la capacidad de los centros médicos, así como que la 
gran parte de los pacientes son personas mayores que debido a las circunstancias de la 
vida no tuvieron la oportunidad de cuidar su salud adecuadamente en su adolescencia 
o juventud y poco a poco su salud se desgastó hasta el punto que muchos de ellos 
quedan internados en centros médicos con enfermedades que son el resultado de no 
cumplir adecuadamente tratamientos farmacológicos en años anteriores. 
Con el seguimiento y correcta culminación de este tipo de tratamientos se pretende 
incentivar a las personas a cuidar su salud, pues ello permitirá reducir a largo plazo la 
cantidad de pacientes mayores cuyas enfermedades han sido consecuencia de no haber 
realizado estas acciones. 
Muchas veces los pacientes no conocen las consecuencias de tener una baja adherencia 
al tratamiento o de que pasará si lo abandonan, por lo que se hace necesario mostrarle 
las consecuencias perjudiciales que podría tener si no consigue completar 
correctamente el tratamiento farmacológico. 
Los padres, apoderados o el médico de confianza encargados de supervisar la salud del 
paciente contarán con una herramienta tecnológica que les facilitará realizar su labor 
de supervisión, específicamente de los tratamientos farmacológicos. Para ello la 
herramienta les permitirá visualizar de forma detallada el historial de ingesta de 
7 
 
medicamentos del paciente, además de mostrar en tiempo real el progreso y estado del 
tratamiento, de inicio a fin. 
Al ser una aplicación móvil desarrollada con tecnologías de nueva generación, la 
herramienta mencionada será de fácil acceso para todas las personas que deseen 
beneficiarse haciendo uso de sus funciones. 
1.4 OBJETIVOS 
1.4.1 Objetivo General 
Desarrollar una aplicación móvil utilizando Flutter y Firebase, que permita 
realizar el seguimiento de los tratamientos farmacológicos de un paciente. 
1.4.2 Objetivos Específicos 
1. Implementar el registro de los tratamientos farmacológicos de un paciente, 
además de los recordatorios de ingesta de medicamentos y las advertencias 
de no completar el tratamiento farmacológico. 
2. Permitir que el paciente seleccione usuarios supervisores dentro de uno de 
sus tratamientos. 
3. Calcular el porcentaje de adherencia al tratamiento farmacológico 
basándose en la cantidad real y proyectada de ingestas de medicamentos. 
1.5 DELIMITACIÓN DE LA INVESTIGACIÓN 
1.5.1 DELIMITACIÓN ESPACIAL 
La aplicación móvil será publicada en Google Play Store restringiendo la 
instalación para que solo esté disponible en Perú. 
1.5.2 DELIMITACIÓN TEMPORAL 
El trabajo de investigación se desarrollará en un lapso de tiempo de 6 meses a 
partir de su aprobación. 
 
8 
 
II. MARCO TEÓRICO 
2.1 ANTECEDENTES DE LA INVESTIGACIÓN 
Lucy Gabriela Pacheco Campoverde y Cristian Iván Idrovo Tapia, alumnos en la carrera 
de Ingeniería de Sistemas de la Universidad Politécnica Salesiana, sede Cuenca – 
Ecuador, realizaron la tesis “DESARROLLO DE UNA APLICACIÓN MÓVIL EN 
ANDROID DE SOPORTE PARA LA PREVENCIÓN DE RECAÍDAS EN 
PACIENTES EN PROCESO DE RECUPERACIÓN DEL HOSPITAL 
PSIQUIÁTRICO HUMBERTO UGALDE CAMACHO” para optar por el título de 
Ingeniero de Sistemas. Este estudio se enfoca en apoyar y evaluar el estado de los 
pacientes en rehabilitación por consumo de sustancias estupefacientes mediante el uso 
de preguntas para evaluar el estado de ánimo en el cual se encuentra el paciente y de 
acuerdo a este mostrarle frases motivacionales que intenten mejorar su estado de ánimo. 
Otro de los módulos más importantes consta de un botón de pánico para cuando el 
paciente ingrese en crisis, lo primero que se le muestra es un vídeo persuasivo que 
intenta calmarlo, aunque también hay una opción para llamar a su persona de confianza 
y que está pueda tomar medidas que no están al alcance del aplicativo. El aplicativo se 
desarrolló utilizando la metodología del diseño centrado en el humano. El diseño de un 
sistema basado en el usuario final busca que el usuario sea partícipe de la creación del 
modelo que se va a implementar en un futuro (Pacheco Campoverde y Idrovo Tapia, 
2014, p. 37). 
Para nuestro proyecto es fundamental centrarse en el paciente con tratamientos 
farmacológicos y un tercero que puede ser un familiar o personal de salud, por lo cual 
se tomó como base los criterios de Pacheco Campoverde y Idrovo Tapia (2014) para 
determinar las necesidades de ambos. 
 
Juan David Vázquez Gutiérrez, alumno de la Facultad de Ingeniería en Tecnologías de 
Información y Comunicación de la Universidad Pontifica Bolivariana, sede Medellín – 
Colombia, realizó la tesis “DESARROLLO DE UNA APLICACIÓN MÓVIL QUE 
PERMITA LA INTERACCIÓN PACIENTE – MÉDICO – ESPECIALISTA EN 
POBLACIONES DE ÁREAS RURALES DE COLOMBIA” para optar por el título 
Magister en Tecnologías de la Información y Comunicación (TIC). El estudio consiste 
en proporcionar una ayuda rápida a los pacientes de zonas rurales, ya que dichas zonas 
son de difícil acceso por lo cual el médico general o especialista puede dar indicaciones 
9 
 
mediante el aplicativo sin necesidad de realizar traslados, esto dependiendo del criterio 
del médico general o especialista. La construcción de la aplicación se realizó usando el 
proceso de Design Thinking para obtener el MVP (Minimum Viable Product) y el 
proceso Running Lean para realizar las iteraciones y llegar a la aplicación que agregue 
valor al usuario. Para el desarrollo de software de la aplicación se aplicó el modelo de 
desarrollo evolutivo y algunas actividades del marco de referencia Ágil SCRUM 
(Vásquez Gutiérrez, 2017, p. 1). 
Esta investigación permite apreciar el uso del marco de referencia SCRUM, sobre todo 
la forma en la cual se definen y administran los Sprints, como por ejemplo el formato a 
utilizar para llevar el control de los ítems del Product Backlog y la forma en cómo se 
mide el incremento del proceso SCRUM. 
 
Franklin Jhino Arias Moreno, alumno de la Facultad de Ingeniería y Arquitectura, 
Escuela Profesional de Ingeniería de Computación y Sistemas de la Universidad San 
Martín de Porres, sede Lima – Perú, realizó la tesis titulada “APLICACIÓN WEB Y 
MÓVIL DE MONITOREO Y CONTROL DEL TRATAMIENTO DE LOS 
PACIENTES DEL HOSPITAL NACIONAL ARZOBISPO LOAYZA” para optar por 
el título profesional de Ingeniero de Computación y Sistemas. El estudio se centra en 
proporcionar una herramienta para controlar, administrar y hacer seguimiento al 
tratamiento farmacológico (Arias Moreno, 2014). El sistema de control se encuentra 
desarrollado para dispositivos Android y los tratamientos pueden ser supervisados por 
familiares del paciente. Adicionalmente cuenta con información sobre los médicos que 
pertenecen al Hospital Nacional Arzobispo Loayza para que los usuarios puedan 
consultar quien los está atendiendo, así como la especialidad de este. También cuenta 
con una opción para contactar al médico mediante un correo electrónico. 
Según sus conclusiones con el uso del aplicativo se logró llevar un mejor control en el 
seguimiento de los tratamientos de farmacología, algo importante a destacar es que se 
evitó que lospacientes perdieran su receta ya que está se encuentra registrada en el 
aplicativo. 
La investigación nos muestra una aplicación en específico para el Hospital Nacional 
Arzobispo Loayza, las funcionalidades referentes a los tratamientos se han tomado 
como base para trabajar en nuevas funcionalidades más generalizadas y que no 
dependan de un centro de salud en particular. 
 
10 
 
2.2 BASES TEÓRICAS 
2.2.1. Tratamientos Farmacológicos 
Para entender qué es un tratamiento farmacológico primero se debe entender el 
concepto de farmacología. Según Díez et al. (2002) es “la ciencia biológica que estudia 
las propiedades y acciones de los fármacos en los organismos vivos o también es el 
estudio de los fármacos y sus interacciones con los organismos vivos”. 
El mismo autor define un fármaco como toda sustancia química capaz de interaccionar 
con un organismo vivo, recordando además que los fármacos que causan efectos 
terapéuticos sobre las enfermedades se les denomina sustancias medicinales. 
Tomando estos dos conceptos se podría decir que un tratamiento farmacológico 
consiste en curar o aliviar las enfermedades o síntomas utilizando medios 
farmacológicos. 
2.2.2. Adherencia al Tratamiento 
La OMS citada por PFIZER (2009) define a la adherencia al tratamiento como el 
cumplimiento del mismo, es decir, tomar la medicación de acuerdo a la dosificación 
del programa prescrito. 
La baja o nula adherencia al tratamiento conduce al fracaso terapéutico el cual 
ocasiona un empeoramiento de la calidad de vida del paciente, genera una mayor 
probabilidad de recaídas, aumenta la frecuencia de consultas e ingresos hospitalarios, 
aumenta la probabilidad de mayor resistencia a los medicamentos, uso de 
medicamentos más potentes y aumento en los costos sanitarios. 
Fernández Arias, Acuna Villaorduna, Miranda, Diez Canseco, y Málaga (2014) hablan 
sobre un estudio de adherencia en el Hospital Cayetano Heredia en Lima – Perú, 
realizado en 115 pacientes con tratamiento antihipertensivo durante 6 meses utilizando 
la escala de Morisky, en los resultados se encontró una baja adherencia en el 57.4% de 
los pacientes, sobre todo en jóvenes y en aquellos a quienes se les había prescrito más 
de dos medicamentos. 
2.2.3. eSalud 
Según la Organización Mundial de la Salud (2019) eSalud es el uso de las tecnologías 
de la información y la comunicación (TIC), que permiten de alguna manera beneficiar 
la salud. Por otro lado, la eSalud proporciona herramientas para que todos los actores 
11 
 
que intervienen en la salud sobre todo los actores relegados tradicionalmente puedan 
reclamar su protagonismo (Casado Pardo, Beijinho do Rosario, Ben Adbellah, Benito 
Justel, y Ávila de Tomás, 2015, p. 476). 
Para la consultora ESA Medicina citada por Casado Pardo et al. (2015) la eSalud 
cuenta con los siguientes componentes: 
• Salud Telemática: Combina la informática y las telecomunicaciones, 
utilizando, por ejemplo: base de datos compartidos y accesibles a través de 
redes informáticas, historia clínica electrónica compartida, etc. 
• Informática de la salud: Concepto más amplio que el anterior, se tendría 
cualquier aplicación o herramienta informática que pudiera ser aplicable a la 
salud. 
• Telesalud-Telemedicina: Prestación de servicios de salud utilizando las 
tecnologías, donde la distancia es una barrera para recibir el servicio de 
atención de salud. 
• mSalud: Se centra en la tecnología móvil como teléfonos inteligentes, 
dispositivos de monitoreo de pacientes y otros dispositivos inalámbricos que 
pueden ser utilizados en beneficio de la salud. 
 
 
Figura 1. Relación entre los componentes de la eSalud (European Space Agency, 2004) 
 
12 
 
2.2.4. mSalud 
Según la OMS (2016) la mSalud es el uso de las tecnologías móviles inalámbricas en 
la salud pública para potenciar el acceso a la información, servicios y competencias 
sanitarios, además de fomentar cambios positivos en los comportamientos en materia 
de salud para prevenir el inicio de enfermedades agudas y crónicas. 
La mSalud o mHealth surgió debido a la gran importancia que tomaron las tecnologías 
móviles en nuestra vida diaria. Según un informe de 2015 de la UIT, hay más de 7000 
millones de suscripciones de telefonía móvil en todo el mundo, más del 70% de ellas 
en países de ingresos bajos o medianos (Organización Mundial de la Salud, 2016). 
Actualmente en el mercado existen diferentes aplicaciones, las más populares son las 
aplicaciones orientadas a los ePacientes, entre las más populares encontradas en 
Google Play Store tenemos: 
1. Medicsen: Orientada a los pacientes diabéticos, posee un algoritmo que predice 
valores futuros de la glucosa con una hora de antelación y con un margen de 
error medio de 10 unidades de glucosa. 
2. Ada: Esta aplicación se centra en evaluar síntomas y condiciones médicas para 
obtener informes de salud personalizados. 
3. GoogleFit: Una aplicación de Google en colaboración con la Organización 
Mundial de la Salud y American Heart Association. Se centra en mejorar la 
salud a partir de dos actividades: los minutos de actividad y los puntos cardio. 
2.2.5. Lenguajes de programación de alto nivel 
Son lenguajes que permiten desarrollar programas haciendo uso de una sintaxis más 
entendible para el programador. Una característica importante es que, a diferencia de 
los lenguajes de bajo nivel, no dependen de la arquitectura del ordenador utilizado 
(Quero Catalinas, 2003). Existe una gran cantidad de lenguajes como por ejemplo C, 
C++, Java, Kotlin, Dart, etc., su uso depende del proyecto en el cual se va a trabajar. 
2.2.6. Dart 
Dart es un lenguaje de programación de alto nivel desarrollado por Google, diseñado 
para ser optimizado del lado cliente para las interfaces gráficas (UI) de manera que las 
aplicaciones sean rápidas en cualquier plataforma lo cual aumenta la productividad de 
los desarrolladores. 
13 
 
Su sintaxis es muy clara y sencilla, fue influenciado por anteriores lenguajes de 
programación como C#, JavaScript, Java y CoffeScript. 
 
Figura 2. Ejemplo de una petición asíncrona a un servidor utilizando Dart (Google, s. f.-a). 
2.2.7. Flutter 
Flutter es el kit de herramientas de UI de Google para realizar hermosas aplicaciones, 
compiladas nativamente, para móvil, web y escritorio desde una única base de código 
(Google, s. f.-d). Es totalmente libre y de código abierto, actualmente el SDK de Flutter 
se encuentra en su versión v1.12.13+hotfix.5. 
 
Figura 3. Logo de Flutter (Google, s. f.-d). 
Flutter utiliza el lenguaje de programación Dart y se basa en que todo componente 
gráfico es un Widget, por ejemplo, dentro de lo Widget básicos tenemos los Container 
(contenedores), Row (filas), Column (columnas), Buttons (Botones), toda la 
información sobre cómo utilizarlos se puede encontrar en la documentación oficial. 
Permite un desarrollo rápido ya que cuenta con Hot Reload, que es una característica 
que nos permite visualizar los cambios instantáneamente mientras realizamos la 
codificación de nuestra aplicación. 
Cuenta con componentes de UI expresivos y flexibles para mantener el foco en la 
experiencia de usuario nativa. Permite una arquitectura en capas para una completa 
personalización, que resulta en un renderizado increíblemente rápido. 
https://storage.googleapis.com/flutter_infra/releases/stable/windows/flutter_windows_v1.12.13+hotfix.5-stable.zip
14 
 
El rendimiento nativo se logra gracias a que los widgets de Flutter incorporan todas 
las diferencias críticas entre plataformas, como el scrolling, navegación, iconos y 
fuentes, para proporcionar un rendimiento totalmente nativo tanto para iOS como para 
Android. 
Actualmente existen grandes empresas que utilizan Flutter como Alibaba, Tencent, 
Abbey Road Studios, Google, etc., las cuales (Google, s. f.-d). 
 
Figura 4. Creación de una aplicación móvil básica en Flutter (Google, s. f.-g). 
2.2.8. AndroidStudio 
Es un entorno de desarrollo integrado o IDE oficial para el desarrollo de aplicaciones 
para Android. Utiliza un potente editor de código, además de herramientas y funciones 
que permiten aumentar la productividad a la hora de desarrollar aplicaciones para 
Android. 
De acuerdo con Google (s. f.-e) sus principales características son las siguientes: 
• Sistema de compilación flexible basado en Gradle 
• Emuladores 
• Desarrollo para múltiples dispositivos 
• Variedad de marcos de trabajo y herramientas de prueba 
• Compatibilidad con Google Cloud Platform 
15 
 
El sistema de compilación flexible es la característica más importante porque permite 
compilar aplicaciones utilizando 3 lenguajes de programación: Java, Kotlin y Dart. En 
el caso de los proyectos creados con lenguaje Java y Kotlin pueden operar juntos, es 
decir se puede crear una función en Java y llamarla desde un archivo Kotlin. 
Para el caso de Dart todo el código debe estar escrito únicamente en este. Actualmente 
se utiliza para escribir aplicaciones con el SDK de Flutter. 
2.2.9. Firebase 
Firebase es un conjunto de herramientas del tipo Software as a Service (SaaS) 
proporcionadas por Google las cuales se centran en aumentar la productividad al 
momento de desarrollar y desplegar aplicaciones. Cuenta con integración con 
lenguajes de programación como Swift, Objective-C, Java, JavaScript, C++, etc. 
Entre sus principales herramientas o servicios tenemos: 
• Authentication: Nos permite autenticar usuarios de forma simple y segura 
(Google, s. f.-b). Se puede hacer utilizando múltiples métodos de acceso como 
por ejemplo las cuentas de Google, email y contraseña, Facebook, Github, etc. 
• Realtime Database: Esta herramienta nos permite almacenar y sincronizar 
datos en milisegundos (Google, s. f.-b). Se puede crear una base de datos no 
relacional, en la cual cualquier cambio que realicemos automáticamente se 
reflejará en los usuarios conectados. 
• Cloud Firestore: Aprovecha mejor el Realtime Database con un modelo de 
datos nuevo y más intuitivo, se pueden realizar consultas más ricas y rápidas 
(Google, s. f.-b). 
• Cloud Storage: Nos permite almacenar y enviar archivos a la escala de Google 
(Google, s. f.-b). 
• Google Analytics: Esta herramienta nos permite obtener datos de analítica 
ilimitados sobre la aplicación desplegada (Google, s. f.-b). 
En Firebase para limitar el acceso a las herramientas los usuarios cuentan con un plan; 
por defecto todos los usuarios tienen el plan gratuito llamado Spark, el cual limita las 
herramientas o servicios que se desean utilizar. 
16 
 
 
Figura 5. Planes de Firebase (Google, s. f.-c). 
2.2.10. Bases de datos NoSql 
Según Meier y Kaufmann (2019) el término NoSql es usado para referirse a cualquier 
enfoque de datos no relacionales que cumplan con dos criterios: 
1. Los datos no son almacenados en tablas 
2. El lenguaje de base de datos no es SQL 
Las bases de datos NoSql surgieron para proporcionar flexibilidad a las aplicaciones 
modernas, fácil desarrollo, alto rendimiento y diferentes modelados de datos. Entre los 
tipos de modelados más importantes tenemos: 
1. Clave-valor: su principal característica es el acceso a los datos utilizando una 
clave, permite el escalado horizontal de la estructura de las aplicaciones. Entre 
sus principales usos tenemos los juegos, la tecnología publicitaria, etc. 
2. Documentos: los datos se presentan como un objeto o documento de tipo 
JSON, permite flexibilidad, semiestructura y una jerarquía de documentos. 
Para acceder a un valor en particular se utilizan rutas, cada ruta debe ser única. 
3. Grafos: se utilizan cuando los datos a almacenar se encuentran altamente 
conectados. Como ejemplos tenemos: las redes sociales, motores de 
recomendaciones, etc. 
17 
 
 
Figura 6. Tres diferentes bases de datos NoSql (Meier y Kaufmann, 2019). 
2.2.11. Cloud Firestore 
Cloud Firestore es la nueva y mejorada versión de Realtime Database, utiliza una base 
de datos NoSql con modelado en base a documentos. Las características a resaltar 
mencionadas por Ramuka (2019) son las siguientes: 
• Base de datos NoSql diseñada para aplicaciones internacionales: es el 
serverless más rápido, ya que simplifica el almacenamiento, la sincronización 
y las consultas realizadas desde aplicaciones móviles, webs, etc. Además, 
proporciona librerías fáciles de integrar, las cuales soportan el modo fuera de 
línea. 
• Acelera la tasa de desarrollo proporcionado un serverless: ya que Cloud 
Firestore es una base de datos nativa de la nube, cuenta con escalado 
automático, de acuerdo a las necesidades de la aplicación. Está diseñado para 
producir una experiencia excelente de desarrollo, se puede modificar la 
aplicación con una sincronización en vivo (live sync), con soporte fuera de 
línea y con transacciones a través de los documentos y colecciones. 
• Simple y fácil: cuenta con librerías robustas, con todas las características 
necesarias para operar sobre los documentos y colecciones. La curva de 
aprendizaje es muy baja. 
Para Cloud Firebase los documents o documentos son la unidad de almacenamiento. 
Un documento debe ser ligero y debe contener un mapa de valores, son básicamente 
un JSON con la diferencia que su tamaño se limita a 1MB y deben de contar con un 
18 
 
identificador. Por otro lado, las Collections o Colecciones son simplemente 
contenedores de documentos. 
 
Figura 7. Relación entre las colecciones, los documentos y los datos (Google, s. f.-f). 
2.2.12. Scrum 
Según Ken Schwaber and Jeff Sutherland (2020), Scrum es un framework o marco de 
trabajo para desarrollar o mantener productos complejos, entiéndase como productos 
complejos al software a desarrollar. Scrum consta de equipos Scrum, roles, eventos, 
artefactos y reglas que interactúan entre sí. 
Ken Schwaber and Jeff Sutherland, creadores de esta metodología, desarrollaron 
Scrum con la finalidad de ayudar a satisfacer las necesidades de los negocios de hoy 
teniendo como principales características: 
• Ligero 
• Simple de entender 
• Difícil de dominar 
Cabe resaltar que Scrum no es un proceso, técnica o método definitivo ya que dentro 
se pueden emplear diversos procesos y técnicas. 
Ken Schwaber and Jeff Sutherland nos proporcionan cinco criterios para saber cuándo 
se debería utilizar Scrum, se puede apreciar que está orientado a los productos que 
constantemente están cambio, ya sea agregando nuevas funcionalidades o mejorando 
las ya existentes. 
1. Cuando se requiera investigar e identificar mercados, tecnologías y 
capacidades de productos viables. 
2. Al desarrollar productos y mejoras. 
19 
 
3. Cuando sea necesario lanzar productos y mejoras, tantas veces como sea por 
día. 
4. Al Desarrollar y mantener la nube (en línea, segura, bajo demanda) y otros 
entornos operativos para el uso del producto 
5. Al Mantener y renovar productos 
 
Teoría Scrum 
Scrum se basa en la teoría empírica de control de procesos o empirismo. Se tiene un 
enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo. 
Existen tres pilares que sostienen cada implementación del control empírico del 
proceso: transparencia, inspección y adaptación (Ken Schwaber and Jeff Sutherland, 
2020). 
Transparencia 
Consiste en mantener visibles para los responsables del resultado los aspectos 
significativos del proceso. Los aspectos deben definirse utilizando un estándar común. 
Ken Schwaber and Jeff Sutherland (2020) nos proporciona dos ejemplos: 
1. Todos los participantes deben compartir un lenguaje común que se refiera al 
proceso. 
2. Los que realizan el trabajo y los que inspeccionan el resultado deben compartir 
una definición de “Hecho”. 
Inspección 
Se debe inspeccionar los artefactos Scrum y avanzar hacia el Objetivo Sprint (Sprint 
Goal) para detectar variables indeseadas. La frecuencia de las inspecciones no debe 
interponerse enel trabajo. 
 
Adaptación 
Si al realizar la inspección se detecta que el resultado se desvía de los límites aceptables 
y que el producto resultante será inaceptable, se debe ajustar el proceso o el material 
que se procesa. Mientras el ajuste ser realice lo antes posible se minimizarán más 
desviaciones. 
20 
 
Existen cuatro eventos formales definidos por Ken Schwaber and Jeff Sutherland 
(2020) 
1. Sprint Planing (Planificación del Sprint) 
2. Daily Scrum (Scrum diario) 
3. Sprint Review (Revisión de Sprint) 
4. Sprint Retrospective (Retrospectiva de Sprint) 
 
Artefactos Scrum 
Representan trabajo o valor para proporcionar transparencia y oportunidades de 
inspección y adaptación. Están diseñados para maximizar la transparencia de la 
información clave para que todos los integrantes del equipo Scrum tengan la misma 
comprensión del artefacto. Scrum Guid Ken Schwaber and Jeff Sutherland (2020) 
define los siguientes artefactos: 
Product Backlog (Pila de Producto) 
Es una lista que contiene todas las características, funciones, requerimientos, mejoras 
y correcciones que conforman los cambios a realizar para el siguiente lanzamiento del 
producto. Cada ítem contiene atributos que proporcionan una descripción, un orden, 
una estimación y un valor, también incluyen descripciones de los test para considerar 
al ítem como “Hecho”, cada ítem cuenta con un atributo especial llamado Story Points 
el cual es un entero que representa el valor que el ítem sumará o incrementará en el 
proyecto, dicho atributo es arbitrario y definido por el Product Manager teniendo como 
criterios los siguientes: La cantidad de trabajo que hay que hacer, La complejidad del 
trabajo y cualquier riesgo o incertidumbre existe en hacer el trabajo. 
La acción de agregar un ítem o modificar un ítem del Product Backlog se denomina 
refinamiento y es realizado por todo el equipo Scrum. Scrum Guid Ken Schwaber and 
Jeff Sutherland (2020) recomienda no consumir más del 10% de la capacidad del 
equipo de desarrollo para esta actividad. 
 
 
 
21 
 
Sprint Backlog 
Es una sub lista del Product Backlog seleccionada por el equipo de desarrollo, el cual 
se pronostica que será completada en la siguiente iteración, además de especificar el 
trabajo necesario para considerar las funcionalidades como “Hecho” en la iteración. 
Increment (Incremento) 
Es la suma de los Story Points de todos los ítems del Product Backlog que han sido 
completados durante las iteraciones. El incremento es un indicador del avance del 
proyecto. 
 
Artefactos de Transparencia 
Se considera a las decisiones orientadas a optimizar el valor y controlar los riesgos 
según el estado percibido de los artefactos. Ken Schwaber and Jeff Sutherland (2020) 
nos muestra un solo artefacto de transparencia: La definición de “Hecho”. 
Definición de “Hecho” 
La definición de “Hecho” depende de lo que el equipo Scrum entienda como un trabajo 
completado, y es fundamental ya que se utilizará para evaluar todos los ítems del 
Product Backlog. La definición de “Hecho” ayuda a seleccionar los ítems del Product 
Backlog que pasarán al Sprint Backlog para realizar la siguiente iteración. 
A medida que el equipo Scrum evoluciona la definición de “Hecho” se expandirá 
incluyendo criterios cada vez más estrictos para lograr una mayor calidad. 
 
Valores Scrum 
Para que el resultado del proceso Scrum sea exitoso depende principalmente de que 
los miembros aprendan a vivir con 5 valores. 
1. Debe existir un compromiso personal para lograr los objetivos del Equipo 
Scrum. 
2. Tener el coraje para hacer lo correcto y trabajar en problemas difíciles. 
3. Centrarse en el trabajo del Sprint y los objetivos del Equipo Scrum. 
4. Ser abiertos sobre todo el trabajo y los desafíos para realizar el trabajo. 
5. Respetarse mutuamente considerándose personas capaces e independientes. 
22 
 
El equipo Scrum 
Las principales características de los equipos Scrum tomadas de Ken Schwaber and 
Jeff Sutherland (2020) consisten en tener un equipo auto organizado y multifuncional, 
auto organizado, ya que ellos elegirán la mejor manera de lograr el trabajo y 
multifuncional, debido a que así tendrán las competencias necesarias para realizar el 
trabajo sin depender de otras personas que no conforman el equipo. 
El modelo del equipo Scrum está diseñado para optimizar la flexibilidad, la creatividad 
y la productividad (Ken Schwaber and Jeff Sutherland, 2017). Debido a que los 
equipos entregan productos de manera iterativa deben maximizar las oportunidades de 
retroalimentación. Las entregas incrementales aseguran que siempre esté disponible 
una versión potencialmente útil del producto en funcionamiento. 
Los integrantes del equipo Scrum según Ken Schwaber and Jeff Sutherland (2020) son 
los siguientes: 
El Product Owner o Dueño del Producto 
Es el encargado de maximizar el valor del producto resultante del trabajo del equipo 
de desarrollo (Ken Schwaber and Jeff Sutherland, 2020). 
También es el único responsable de administrar el Product Backlog, la administración 
incluye los siguientes puntos. 
• Expresar claramente los ítems del Product Backlog. 
• Ordenar los ítems del Product Backlog para lograr los mejores objetivos y 
misiones. 
• Optimizar el valor del trabajo que realiza el equipo de desarrollo. 
• Asegurarse de que el Product Backlog sea visible, transparente y claro para 
todos, además de mostrar cuáles serán los siguientes trabajos que realizará el 
equipo Scrum. 
• Asegurarse que el equipo de desarrollo comprenda los ítems del Product 
Backlog al nivel necesario. 
 
El equipo de desarrollo 
Profesionales capacitados para llevar a los ítems del Product Backlog a la Definición 
de “Hecho”. Otras capacidades que también deben tener son las de organizar y 
23 
 
administrar su propio trabajo, esto optimiza la eficiencia y efectividad general del 
equipo de desarrollo. 
Ken Schwaber and Jeff Sutherland (2020) especifica que debe contar con lass 
siguientes características: 
• Auto organizados, nadie le dice al equipo de desarrollo cómo realizar el 
incremento de un ítem del Product Backlog. 
• Multifuncionales, deben contar con todas las habilidades necesarias para 
realizar los incrementos. 
• No se reconocen títulos para los miembros. 
• No formar sub-equipos, independiente del dominio a abordar, como por 
ejemplo: pruebas, arquitectura, operaciones, o análisis de negocio. 
• Cada miembro tiene habilidades especializadas y áreas de enfoque, pero la 
responsabilidad es del equipo de desarrollo en su conjunto. 
El Scrum Master (Facilitador de proyectos) 
Es el encargado de promover y apoyar a que el equipo Scrum siga los lineamientos de 
la guía Scrum, es decir debe hacerles entender la teoría, prácticas, reglas y valores del 
marco de trabajo Scrum. 
 
Scrum Events (Eventos Scrum) 
Son eventos diseñados para crear regularidad y minimizar las necesidades de reuniones 
no definidas en Scrum. 
The Sprint (Iteración) 
El corazón de Scrum es el Sprint, consiste en tomar un tiempo que puede ser un mes o 
menos y durante ese tiempo realizar las tareas o ítems definidos en el Sprint Backlog. 
Solo el Product Owner es el único autorizado para cancelar un Sprint. 
Sprint Planing (Panificación de la iteración) 
Para realizar un Sprint es necesario realizar un plan en colaboración con todo el equipo 
Scrum. El plan debe ser claro para todos con un tiempo de duración de un mes o menos, 
además debe responder a dos preguntas: 
• ¿Qué se puede entregar en el siguiente incremento del Sprint? 
24 
 
• ¿Cómo se logrará el trabajo necesario para lograr el incremento? 
 
Daily Scrum (Scrum diario) 
Es un evento de 15 minutos donde el equipo de desarrollo explica lo que tiene por 
hacer en las siguientes 24 horas. 
Sprint Review (Revisión de la iteración) 
Consiste en hacer una revisión al finalizar el Sprint con la finalidad de inspeccionar el 
incremento y adaptarel Product Backlog de ser necesario. En este evento se da a 
conocer cuales ítems del Product Backlog cumplen con la Definición de “Hecho”. 
Sprint Retrospective (Retrospectiva de la iteración) 
Es el evento que da la oportunidad al equipo Scrum de inspeccionarse a sí mismo y 
crear un plan para realizar mejoras que serán aplicadas en el siguiente Sprint. 
2.3 GLOSARIOS DE TÉRMINOS BÁSICOS 
1. Base de datos no relacional: Todas aquellas bases de datos las cuales no 
contienen relaciones entre sí, como por ejemplo claves foráneas; además de no 
utilizar SQL. 
2. Framework: Marco de trabajo, con un conjunto estandarizado de conceptos, 
prácticas y criterios para enfocar un tipo de problemática particular. 
3. JSON: Notación de objetos JavaScript, es un formato ligero de intercambio de 
datos. Leerlo y escribirlo es simple para los humanos, mientras que para las 
máquinas es simple de interpretarlo y generarlo (Ecma International, s. f.). 
4. Serverless: O computación sin servidor, es un modelo de ejecución en el que 
el proveedor en la nube es responsable de ejecutar nuestras aplicaciones 
mediante la asignación dinámica de recursos. 
5. Software as a Service (SaaS): Modelo de distribución de software donde el 
soporte lógico y los datos que maneja se alojan en servidores de una compañía 
de tecnologías de la información. 
6. Tecnología móvil: Tecnología que permite la comunicación entre dos aparatos 
que no están conectados por cables y que se basa en la transmisión y recepción 
de mensajes o señales por medio de ondas electromagnéticas (Biblioteca 
Agrícola Nacional de los Estados Unidos, s. f.). 
25 
 
2.4 MARCO REFERENCIAL 
2.4.1 La Salud en el Perú 
Según la Organización Mundial de la Salud (2013b) en el Perú existe una distribución 
geográfica desigual de los agentes de salud, actualmente Lima y las zonas del litoral 
son las que cuentan con las densidades más altas, mientras Piura, Lambayeque y 
Loreto presentan las más bajas. 
En el siguiente gráfico se puede observar la cantidad de médicos y enfermeros y 
parteras por cada 10 mil habitantes en nuestro país. 
 
Gráfico 1: Distribución de los agentes de salud en el Perú (Organización Mundial de la Salud, 2020). 
El sistema de salud peruano se encuentra compuesto por cinco entidades: el Ministerio 
de Salud (MINSA), el cual ofrece el 60% de los servicios de salud; EsSalud, que cubre 
el 30% y las Fuerzas Armadas (FFAA), la Policía Nacional (PNP), y el sector privado 
los cuales proporcionan el 10% restante. 
Los tratamientos farmacológicos en el Perú necesitan ser prescritos por un agente de 
la salud el cual utiliza el manual de buenas prácticas de prescripción elaborado por el 
ministerio de salud, se debe resaltar que en enfermedades no críticas el seguimiento 
del tratamiento farmacológico se realiza por propia cuenta del paciente o sus 
apoderados. 
2.4.2 Ley de Protección de Datos Personales – Ley N° 29733 
El tratamiento de los datos personales de los usuarios del aplicativo a nivel informático 
se realizará respetando la Ley de protección de datos personales o Ley N° 29733 la 
26 
 
cual norma los procedimientos que deben seguir los sistemas informáticos para realizar 
el procesamiento de información personal de los usuarios. 
Objeto de la ley: Tiene como objeto garantizar el derecho fundamental a la protección 
de los datos personales, previsto en el artículo 2, numeral 6 de la Constitución Política 
del Perú, a través de su adecuado tratamiento, en un marco de respeto de los derechos 
fundamentales que en ella se reconocen. 
2.5 HIPÓTESIS 
2.5.1 Hipótesis General 
Con el desarrollo de una aplicación móvil utilizando Flutter y Firebase se 
podrá realizar el seguimiento de los tratamientos farmacológicos de un 
paciente. 
2.5.2 Hipótesis Específicas 
1. Las opciones de registro de tratamientos farmacológicos, recordatorios de 
ingesta de medicamentos y advertencias de las consecuencias de 
abandonar el tratamiento farmacológico contribuirán a evitar el abandono 
de los tratamientos farmacológicos de un paciente. 
2. La opción de añadir usuarios supervisores a un tratamiento farmacológico 
de un paciente permitirá a terceros realizar el seguimiento del mismo. 
3. El porcentaje de adherencia determinará si el paciente cumplió o no con 
el tratamiento farmacológico. 
2.6 DEFINICIÓN Y OPERACIONALIZACIÓN DE VARIABLES 
2.6.1 Variable de Trabajo 
VT: Aplicación móvil desarrollada utilizando Flutter y Firebase. 
 
27 
 
2.6.2 Operacionalización de la Variable 
Definición 
Conceptual 
Definición 
Operacional 
Dimensiones Indicadores Instrumento 
Aplicación de 
software desarrollada 
específicamente para 
su uso en 
dispositivos 
informáticos 
inalámbricos 
pequeños, como 
teléfonos inteligentes 
y tabletas 
(Healthcare 
Information & 
Management 
Systems Society 
(HIMSS), 2019, p. 
137). 
Técnicas de 
medición 
para 
desarrollo de 
software 
basadas en 
Pressman 
(2010) y la 
métodología 
Scrum. 
Agilidad 
Velocidad del incremento (Horas) 
𝑣𝑖 = 
∑
𝑠𝑝𝑖
𝑛ℎ𝑖
𝑛𝑠
𝑖=1
𝑛𝑠
 
ns: Número de Sprints completados. 
𝑠𝑝𝑖: Story Points del Sprint i. 
𝑛ℎ𝑖: Horas del Sprint i. 
Guía Obs. N° 1 
Anexo N° 3 
Promedio del incremento por Sprint 
𝑝𝑖𝑠 = 
∑ 𝑠𝑝𝑖
𝑛𝑠
𝑖=1
𝑛𝑠
 
ns: Número de Sprints completados. 
𝑠𝑝𝑖: Story Points del Sprint i. 
Guía Obs. N° 1 
Anexo N° 3 
Eficiencia 
Porcentaje promedio de uso del CPU 
Guía Obs. N° 2 
Anexo N° 4 
Megabytes promedio de uso de la memoria RAM 
Guía Obs. N° 2 
Anexo N° 4 
Megabits promedio de uso del tráfico de red. 
Guía Obs. N° 2 
Anexo N° 4 
Utilidad 
Promedio del porcentaje de adherencia al tratamiento 
farmacológico 
Guía Obs. N° 3 
Anexo N° 5 
N° de tratamientos farmacológicos completados correctamente 
Guía Obs. N° 3 
Anexo N° 5 
Usabilidad 
Tiempo promedio al registrar un tratamiento por primera vez 
Guía Obs. N° 4 
Anexo N° 6 
Tiempo promedio al modificar un tratamiento por primera vez 
Guía Obs. N° 4 
Anexo N° 6 
Tabla 1: Operacionalización de la variable (Fuente: Elaboración propia)
28 
 
III. MARCO METODOLÓGICO 
3.1. ENFOQUE Y DISEÑO 
La investigación fue cuantitativa basándose en lo mencionado por Hernández 
Sampieri, Fernández Collado, y Baptista Lucio (2013), quienes indican que un enfoque 
cuantitativo es aquel que recolecciona datos para probar la hipótesis con base en la 
medición númerica y el análisis estadístico. 
El diseño de la investigación fue no experimental según Hernández Sampieri et al. 
(2013), porque no se realiza una manipulación deliberada de variables y solo se limita 
a observar fenómenos en su ambiente natural para analizarlos. 
Según su alcance es transeccional debido a que la recopilación de los datos será en un 
momento único. 
3.2. MÉTODOS Y PROCEDIMIENTOS 
El desarrollo de la aplicación se realizó utilizando la metodología ágil Scrum, por lo 
cual se inició definiendo al equipo Scrum. 
3.2.1. El equipo Scrum 
El rol de Product Owner fue asumido por el autor de la investigación con apoyo del 
asesor de la investigación: Mg. Víctor Hugo Valle Ríos. 
La co-asesora de la investigación Ing. Dalia Pamela Vílchez Holguín, asumió el rol de 
Scrum Master ya que debe asegurarse que la metodología Scrum se entienda. 
El equipo de desarrollo y encargado de realizar las tareas o requerimientos hasta 
llevarlos a la definición de “Hecho” estuvo conformado únicamente por el autor de la 
investigación. 
3.2.2. Definición de “Hecho” 
El equipo Scrum optó por utilizar la siguiente definición de “Hecho”: tarea que esté 
integrada con el resto del proyecto, se encuentre revisada por al menos un miembro 
del equipo, cumpla con los objetivos y requisitos previamente validada por el Product 
Owner. 
 
 
29 
 
3.2.3. Eventos Scrum 
El equipo Scrum resolvió establecer el Sprint inicialmente en un periodo de 1 semana 
a medida del transcurso de la investigación se fue incrementando el periodode tiempo 
finalizando en un Sprint de 3 semanas. 
La Reunión de Planificación de Sprint o Sprint Planning Meeting se estableció 
inicialmente en 1 hora utilizando la plataforma de video llamada Google Meet, según 
el número del Sprint a lo largo del proyecto fue variando entre 1 y 3 horas. 
El Scrum Diario o Daily Scrum se realizó utilizando video llamadas de no más de 5 
minutos para verificar hechos avanzados, hechos en progreso y los inconvenientes que 
surgieron. 
La Revisión de Sprint o Sprint Review junto con la retrospectiva de Sprint o Sprint 
Retrospective se realizaron al final de cada Sprint con una duración que osciló entre 1 
y 2 horas utilizando la plataforma de video llamada Google Meet. 
 
 
Figura 8 Proceso Scrum (Cevallos, 2015) 
3.2.4. Historia de Usuario 
Luego de regresar de una cita con el médico, donde le recetaron tomar medicamentos 
en un cierto horario, el usuario necesita de una aplicación para realizar el seguimiento 
de sus tratamientos farmacológicos. 
30 
 
Para ingresar a la aplicación el usuario puede registrarse con su correo personal o 
utilizando su correo de Google. Lo principal que debe visualizar deben ser los 
medicamentos que tiene pendiente de ingerir durante el día y una opción que lo invite 
a registrar un nuevo tratamiento farmacológico. El registro de su tratamiento debe 
incluir al médico y lugar donde fue atendido, además de su diagnóstico, también se 
debe registrar cada medicamento que fue recetado y por cada medicamento se debe 
especificar el rango de días y el horario en el cual debe ser ingerido. Cuando la 
aplicación detecte que se debe ingerir un medicamento se le alertará al usuario con un 
sonido de alarma y una notificación, el usuario al ver la notificación recordará que 
debe tomar el medicamento y la aplicación le solicitará al usuario tomarse una foto 
como prueba de que ingirió el medicamento para poder aumentar el progreso. 
El usuario también puede añadir a otros usuarios que utilicen la aplicación como 
supervisores de su tratamiento, esto en el caso de que un familiar quisiera asegurarse 
que el usuario cumple con su tratamiento farmacológico. El progreso del tratamiento 
tiene que ser visualizado en tiempo real por el usuario o los usuarios supervisores. 
3.2.5. Product Backlog 
La elaboración del Product Backlog se realizó en el Sprint Planning Meeting. En esta 
reunión los objetivos de la investigación se disgregaron en tareas más específicas, 
asignando una puntuación (que representa el valor de la tarea respecto al producto 
final) para cada una de ellas, así como un tiempo aproximado para su culminación. 
Código Tarea Story 
Points 
Duración 
(Horas) 
001 Elección e instalación de las herramientas de 
desarrollo, como IDE's y emulador. 
2 5 
002 Widget de bienvenida con información acerca de la 
aplicación. 
5 4 
003 Widget donde se muestren las políticas de 
privacidad de la aplicación. 
6 5 
004 Elaboración de las políticas de privacidad 5 2 
005 Widget de registro e inicio de sesión utilizando 
Firebase Authentication, los métodos de ingreso 
8 5 
31 
 
son: correo electrónico y contraseña; y Google 
OAuth 2.0. 
006 Definición del proceso de seguimiento de un 
tratamiento farmacológico para un paciente. 
8 3 
007 Widget que permita crear y actualizar un centro de 
salud. 
4 5 
008 Widget que permita seleccionar un centro de salud. 4 3 
009 Widget que permita crear y actualizar 
enfermedades. 
5 5 
010 Widget que permita seleccionar una enfermedad. 4 3 
011 Widget que permita crear y actualizar un 
medicamento. 
5 5 
012 Widget que permita seleccionar un medicamento. 4 4 
013 Widget que permita crear y actualizar la principal 
información relacionada al tratamiento, como, por 
ejemplo, el centro de salud, el personal de salud, la 
fecha de consulta médica, la enfermedad, etc. 
9 12 
014 Widget que permita crear y actualizar un 
medicamento asociado a un tratamiento, la 
cantidad, el tipo de aplicación, la medida de la 
aplicación, la fecha de inicio y fin y los horarios 
donde se deberá consumir el medicamento. 
7 10 
015 Widget que permita visualizar la información más 
importante de todos los medicamentos asociados al 
tratamiento, principalmente el avance de cada 
medicamento. 
5 7 
016 Widget que permita registrar el consumo de un 
medicamento en un horario determinado, 
adjuntando una imagen como prueba de la acción. 
8 9 
017 Widget que muestre todos los medicamentos 
pendientes de ingerir en el día actual. 
8 10 
018 Widget para visualizar el historial de consumo de 
medicamentos por cada tratamiento. 
7 9 
32 
 
019 Subsistema de alarma, cuando algún horario de un 
medicamento pendiente de consumir en el día, 
coincida con la hora actual se deberá ejecutar un 
subproceso que active la aplicación y avise al 
usuario de los medicamentos que tiene que 
consumir. 
9 10 
020 Subsistema de notificaciones, envío y recepción de 
notificaciones de diferentes tipos y que al recibirlas 
poder reaccionar con ciertas acciones. 
7 11 
021 Widget que permita visualizar las notificaciones 
ordenas por fecha de creación y que distinga las que 
aún no han sido leídas. 
6 8 
022 Widget del perfil del usuario donde pueda ingresar 
sus datos personales como por ejemplo nombre 
completo, fecha de nacimiento, peso y estatura. 
4 4 
023 Widget que permita buscar y añadir contactos al 
usuario. 
5 7 
024 Widget que permita visualizar y administrar los 
contactos del usuario. 
5 6 
025 Widget que permita al usuario contribuir a la 
aplicación convirtiéndose en personal de salud, con 
lo cual podrá registrar y editar medicamentos y 
centros de salud. Para contribuir deberá registrar 
una solicitud enviando su grado académico, 
número de colegiatura y opcionalmente su 
especialidad. 
6 8 
026 Widget que permita solo a los administradores de 
la aplicación validar las solicitudes de los usuarios 
que desean contribuir y aprobarlas o rechazarlas. 
4 7 
027 Widget que permita añadir usuarios supervisores a 
un tratamiento a partir de los contactos que tiene 
añadido el usuario. 
8 10 
33 
 
028 Widget que permita visualizar y administrar los 
supervisores que se han añadido a un tratamiento 
farmacológico. 
7 9 
029 Widget que permita a los usuarios que contribuyen 
en la aplicación a registrar mini artículos con 
información relacionada a no culminar un 
tratamiento correctamente. 
6 9 
030 Widget que muestre información al usuario sobre 
las posibles consecuencias de no seguir un 
tratamiento correctamente. 
7 8 
031 Widget que permita calcular y visualizar el 
promedio del porcentaje de adherencia de un 
tratamiento farmacológico 
4 10 
032 Widget que permita visualizar el número de 
tratamientos farmacológicos completados 
correctamente 
4 11 
033 Widget que permita visualizar el tiempo promedio 
al registrar y actualizar un tratamiento por primera 
vez. 
4 9 
Tabla 2: Product Backlog (Fuente: Elaboración propia) 
El Product Backlog se fue modificando de acuerdo a los eventos Scrum como los Daily 
Scrum y Sprint Review. 
3.2.6. Sprint N° 1 
En el Sprint Planning Meeting se determinó para la primera iteración o primer Sprint 
realizar las siguientes tareas: 
Código Tarea Story 
Points 
Duración 
(Horas) 
001 Elección e instalación de las herramientas de 
desarrollo, como IDE's y emulador. 
2 5 
002 Widget de bienvenida con información acerca de la 
aplicación. 
5 4 
34 
 
003 Widget donde se muestren las políticas de 
privacidad de la aplicación. 
6 5 
004 Elaboración de las políticas de privacidad 5 2 
005 Widget de registro e inicio de sesión utilizando 
Firebase Authentication, los métodos de ingreso 
son: correo electrónico y contraseña; y Google 
OAuth 2.0. 
8 5 
006 Definición del proceso de seguimiento de un 
tratamiento farmacológico para un paciente. 
8 3 
Tabla 3: Sprint N° 1 (Fuente: Elaboración propia) 
3.2.6.1. Tarea