Sistema Web para Salud de Ancianos
Cargado por
Arnold Villa LopezSistema Web para Salud de Ancianos
Cargado por
Arnold Villa LopezUNIVERSIDAD PRIVADA FRANZ TAMAYO
INGENIERIA DE SISTEMAS
PROYECTO MEDICUIDA
"Sistema de información web para el seguimiento del estado de salud en
pacientes de la tercera edad, con el diseño y la construcción de un circuito
para la detección de pulsos cardíacos"
CASO: “Casa de reposo María Esther Quevedo”
AUTORES: Encinas Cano Carla Valeria
Emmanuel Isaac Escobar Ríos
Cruz Lavadenz Jesús Gabriel
Vera Pozo Jair Fabricio
DOCENTES: Ing. Sharon Lizbeth Castellon Tito (BASE DE DATOS II BDA-312)
Ing. Luis Adolfo Alvarez Guerra (ESTRUCTURA DE DATOS EDA-311)
Ing. Juan Mario Eguivar Guerra (INVESTIGACIÓN OPERATIVA IOP-711)
Ing. Angela Giovanna Choque Condori (ANALISIS Y DISEÑO I ADI-311)
GESTIÓN 2025
LA PAZ - BOLIVIA
ÍNDICE
INGENIERIA DE SISTEMAS ....................................................................................................................1
ÍNDICE DE FIGURAS .............................................................................................................................. iv
CAPÍTULO 1 ...............................................................................................................................................1
INTRODUCCIÓN .......................................................................................................................................1
1.1. Motivación ...................................................................................................................................2
1.2. Antecedentes de proyecto .............................................................................................................2
1.3. Argumentos de la importancia del tema ........................................................................................3
CAPÍTULO 2 ...............................................................................................................................................4
MARCO REFERENCIAL ...........................................................................................................................4
2.1. Planteamiento del problema ................................................................................................................4
2.2. Formulación del problema general ..................................................................................................4
2.3. Objetivo general ..............................................................................................................................4
2.4. Objetivos específicos ......................................................................................................................5
2.5. Justificaciones .................................................................................................................................5
2.5.1. Justificación técnica ......................................................................................................................5
2.5.2. Justificación social........................................................................................................................6
2.5.3. Justificación económica ................................................................................................................6
2.5.4. Justificación científica ..................................................................................................................6
2.6. Límites ............................................................................................................................................8
2.7. Alcances ..........................................................................................................................................8
CAPÍTULO 3 .............................................................................................................................................10
MARCO TEÓRICO ...................................................................................................................................10
3.2. PHP (Hypertext Preprocessor). ......................................................................................................11
3.2.1. Características de PHP................................................................................................................11
3.3. Javascript. ......................................................................................................................................11
3.3.1. Características de Javascript. ......................................................................................................12
3.4. HTML (HyperText Markup Language). ........................................................................................13
3.4.1. Características de HTML............................................................................................................13
3.5. CSS (Cascading Style Sheets). ......................................................................................................13
3.5.1. Características de CSS. ...............................................................................................................14
3.6. Base de datos. ................................................................................................................................14
3.7. MySQL..........................................................................................................................................15
3.7.1. Características de MySQL. .........................................................................................................15
i
3.8. Modelos de base de datos. .............................................................................................................16
3.8.1. Modelo Entidad – Relación. .......................................................................................................16
Figura 1: Ejemplo de modelo Entidad-Relación .................................................................................17
3.8.2. Modelo Relacional......................................................................................................................17
Figura 2: Ejemplo de modelo relacional .............................................................................................18
3.9. Canva ............................................................................................................................................19
3.10. La metodología de la ruta crítica CPM. .......................................................................................19
3.10.1. Pasos para aplicar el método CPM. ..........................................................................................20
3.10.2. Gráfica de CPM. .......................................................................................................................20
Figura 3: Ejemplo de gráfica CPM .....................................................................................................21
3.11. Método de Evaluación y Revisión de Programas PERT. ..............................................................21
3.11.1. Pasos para aplicar el método PERT. ..........................................................................................21
3.11.2. Diagrama de PERT. ...................................................................................................................22
Figura 4: Ejemplo de diagrama PERT ................................................................................................23
3.12. Descripción de los diagramas de circuito ....................................................................................23
3.12.1. Diagrama del circuito general ...................................................................................................23
3.12.2. Diagrama esquemático .............................................................................................................24
3.12.3. Diagrama de estado ..................................................................................................................24
3.12.4. Diagrama de bloques ................................................................................................................25
CAPÍTULO 4 .............................................................................................................................................26
MARCO APLICATIVO ............................................................................................................................26
4.1. Introducción a la metodología de Análisis SCRUM ......................................................................26
4.2. Fase 1 – Pre Game .........................................................................................................................27
4.2.1. Análisis de requerimientos .........................................................................................................27
4.2.2. Historias de usuario ....................................................................................................................28
4.2.3. Product Backlog .........................................................................................................................29
4.2.4. Sprint Backlog ............................................................................................................................30
4.3. Fase 2 – Game .................................................................................................................................32
4.3.1. Diseño del sistema ......................................................................................................................32
[Link]. Diagramas de casos de uso ......................................................................................................32
[Link]. Diagrama de actividades ..........................................................................................................34
[Link]. Diagramas de secuencia ...........................................................................................................37
a) Diagrama de Secuencia – Inicio de Sesión .........................................................................................37
[Link]. Modelo entidad-relación. .........................................................................................................40
ii
[Link]. Modelo relacional ....................................................................................................................47
Figura 11: Modelo relacional (MySQL) .............................................................................................47
[Link]. Diagrama de clases de alto nivel ..............................................................................................50
Figura 12: Diagrama de clases de alto nivel .......................................................................................52
[Link]. Diagrama de bajo nivel ............................................................................................................53
WEBGRAFÍA ............................................................................................................................................59
ANEXOS ...................................................................................................................................................61
ANEXO 1 - PRODUCT BACKLOG .....................................................................................................62
ANEXO 2 – HISTORIAS USUARIO ....................................................................................................63
ANEXO 3 - SCRUM..............................................................................................................................75
iii
ÍNDICE DE FIGURAS
Figura 1: Ejemplo de modelo Entidad-Relación ............................................................................ 17
Figura 2: Ejemplo de modelo relacional ........................................................................................ 18
Figura 3: Ejemplo de gráfica CPM ................................................................................................ 21
Figura 4: Ejemplo de diagrama PERT ........................................................................................... 23
Figura 5: Diagrama de casos de uso ............................................................................................... 33
Figura 6: Diagrama de actividades ................................................................................................. 36
Figura 7: Inicio de Sesión (aplicable a todos los roles) .................................................................. 37
Figura 8: Agendar Cita Médica (Doctor / Cuidador) ..................................................................... 38
Figura 9: Sistema de emergencias .................................................................................................. 39
Figura 10: Modelo entidad-relación ............................................................................................... 40
Figura 11: Modelo relacional (MySQL) ........................................................................................ 47
Figura 12: Diagrama de clases de alto nivel................................................................................... 52
Figura 13: Diagrama de clases de bajo nivel .................................................................................. 54
Figura 14: Diagrama del circuito general ....................................................................................... 55
Figura 15: Diagrama esquemático.................................................................................................. 56
Figura 16: Diagrama de estado (circuito) ....................................................................................... 57
Figura 17: Diagrama de bloques .................................................................................................... 58
iv
1
CAPÍTULO 1
INTRODUCCIÓN
En la sociedad actual, el creciente envejecimiento de la población requiere soluciones
innovadoras para el cuidado de las personas mayores. Este grupo enfrenta desafíos significativos
en la gestión de su salud, como la administración de medicamentos, la coordinación de citas
médicas y la comunicación con familiares y cuidadores. Para los encargados de su bienestar, estas
tareas pueden resultar complejas y estresantes, dada la gran responsabilidad que conllevan.
En este contexto, el proyecto Medicuida: Sistema de información Web para el seguimiento
del estado de salud de pacientes con la integración de un circuito de detección de nivel de pulso,
nace con el objetivo de ofrecer una solución eficaz, segura y accesible para mejorar el cuidado de
los residentes en casas de reposo. Esta plataforma está diseñada para simplificar los procesos
relacionados con la salud y seguridad de los adultos mayores. El sistema abordara tareas esenciales
como la administración de medicamentos, la programación de citas médicas, la comunicación entre
los usuarios y la respuesta inmediata ante emergencias.
Una de las características más importantes de esta aplicación será la implementación de un
circuito medidor de pulso con la unión de alerta de emergencia, que permitirá a los residentes enviar
alertas rápidamente en caso de situaciones críticas. Esta funcionalidad optimizará la respuesta ante
emergencias al alertar de forma inmediata a los cuidadores, incrementando así la seguridad en las
casas de reposo
Este proyecto tiene como objetivo no solo mejorar la calidad de vida de los adultos mayores,
sino también aliviar la carga de trabajo de los cuidadores, reduciendo el estrés y facilitando la
gestión de las tareas relacionadas con la salud. A través de esta solución, se promoverá la autonomía
de los residentes, permitiéndoles participar activamente en el cuidado de su bienestar.
2
1.1. Motivación
La principal motivación para la creación de Medicuida es la creciente demanda de
soluciones innovadoras y efectivas para el cuidado de las personas de la tercera edad en nuestra
sociedad. Con el incremento de la población de edad avanzada, tanto los cuidadores profesionales
como los familiares se encuentran con importantes desafíos al gestionar la salud diaria de las
personas mayores. Es fundamental garantizar la correcta administración de medicamentos y la
eficaz coordinación de citas médicas para preservar la salud y el bienestar de este grupo vulnerable.
No obstante, los sistemas actuales suelen ser complejos y carecen de una accesibilidad y usabilidad
adecuadas.
Esta situación puede propiciar errores y omisiones que afectan de manera negativa la salud
de las personas mayores, generando además estrés adicional y aumentando la carga de trabajo de los
cuidadores. Medicuida se establece como una solución a esta dificultad, con el propósito de
proporcionar una herramienta tecnológica intuitiva y de fácil acceso que asista a los cuidadores y
mejore la calidad de vida de los residentes dentro de la casa de reposo.
1.2. Antecedentes de proyecto
El cuidado de las personas mayores ha cobrado un interés y preocupación creciente a
medida que la población mundial envejece. En las últimas décadas, se han creado múltiples
tecnologías y sistemas para asistir a los cuidadores en su trabajo diario, por ejemplo: CarePredict
o asistentes como Alexa (Amazon Echo). No obstante, muchos de estos sistemas no han conseguido
integrarse de forma efectiva en la vida diaria de los usuarios debido a su complejidad y a la falta
de accesibilidad. Investigaciones han evidenciado que la gestión de medicamentos y la
organización de citas médicas son dos de los principales retos que enfrentan los cuidadores. A
menudo, estos procesos dependen de recordatorios manuales y sistemas de gestión dispares, lo que
3
eleva la probabilidad de errores. En atención a estas necesidades, han aparecido diversas
aplicaciones y dispositivos; sin embargo, muchos de ellos no satisfacen plenamente las necesidades
particulares de los cuidadores y las personas mayores. Medicuida se fundamenta en la experiencia
y las lecciones adquiridas de desarrollos anteriores, con el objetivo de proporcionar una solución
más integral y ajustada a las realidades del cuidado diario.
1.3. Argumentos de la importancia del tema
El cuidado de las personas mayores es un tema de gran relevancia por diversas razones.
Primero, el envejecimiento de la población es un fenómeno global que transforma la estructura
demográfica de numerosas sociedades. Esto significa que un número creciente de personas
mayores requerirá apoyo para gestionar su salud diaria, lo que incrementará la demanda de
cuidadores capacitados. La correcta gestión de medicamentos y la programación de citas médicas
son esenciales para preservar la salud y evitar complicaciones en las personas mayores. Los errores
en estos procesos pueden resultar en consecuencias graves, como hospitalizaciones innecesarias y
deterioro de la salud. En tercer lugar, la carga de trabajo y el estrés de los cuidadores pueden afectar
de manera negativa su bienestar y la calidad del cuidado que son capaces de ofrecer.
Proporcionarles herramientas efectivas y de fácil uso puede aumentar significativamente su
capacidad para atender a las personas mayores. Finalmente, una solución como Medicuida no solo
favorecerá a las personas mayores y a sus cuidadores, sino que también podría contribuir a reducir
los costos del sistema de salud y a optimizar su eficiencia operativa.
4
CAPÍTULO 2
MARCO REFERENCIAL
2.1. Planteamiento del problema
El envejecimiento de la población es un fenómeno global que ha incrementado la demanda
de servicios especializados para el cuidado de adultos mayores. En las casas de reposo, el
seguimiento del estado de salud de los residentes enfrenta desafíos significativos como la
administración de medicamentos, la programación de citas médicas, la comunicación entre
cuidadores, familiares y médicos, así como la capacidad de responder eficientemente ante
emergencias. Estos procesos, cuando se realizan manualmente, suelen generar ineficiencias,
errores y una carga adicional para el personal asistencial.
Además, la ausencia de un sistema tecnológico integrado dificulta la gestión ordenada de
la información médica, lo que afecta negativamente tanto a la calidad del cuidado como al bienestar
de los residentes. Esta falta de herramientas tecnológicas también incrementa la carga operativa
del personal, generando retrasos y posibles errores en la atención médica.
2.2. Formulación del problema general
¿Cómo mejorar la gestión de salud y seguridad de los pacientes de la tercera edad en la casa
de reposo María Esther Quevedo, que facilite el seguimiento médico y brinde un apoyo eficaz a
los cuidadores?
2.3. Objetivo general
Desarrollar un sistema de información Web para el seguimiento del estado de salud de los
pacientes de la tercera edad, con el diseño y la construcción de un circuito inteligente en la casa de
reposo María Esther Quevedo.
5
2.4. Objetivos específicos
• Construir una interfaz intuitiva y fácil de usar para optimizar el tiempo y esfuerzo de los
usuarios según sus necesidades.
• Desarrollar un módulo de control de accesos basado en roles, con perfiles que garantice un
manejo seguro y personalizado de la información según las responsabilidades de cada
usuario.
• Implementar un módulo de recordatorios para la administración de medicamentos y la
programación de citas médicas, asegurando el cumplimiento de los planes de tratamiento.
• Diseñar y construir un dispositivo de hardware (circuito medidor) para dar seguimiento a
los niveles de pulso de cada paciente y generar alertas de emergencia en tiempo real.
2.5. Justificaciones
2.5.1. Justificación técnica
Desde un enfoque técnico, el proyecto Medicuida representa una solución completa de
integración entre software y hardware para la mejora de procesos médicos. El sistema se desarrolla
utilizando tecnologías como PHP, Java, HTML, CSS y MySQL, las cuales permiten una
construcción robusta, modular y escalable. La implementación de un sistema de roles facilita el
acceso controlado y personalizado a la información según el perfil del usuario, mientras que la
incorporación del circuito medidor de pulso para emergencias demuestra el aprovechamiento de
tecnologías de hardware para extender la funcionalidad y mejorar la capacidad de respuesta ante
situaciones críticas. Asimismo, la arquitectura del sistema se orienta a la interoperabilidad y la
sostenibilidad, asegurando su viabilidad técnica a largo plazo.
6
2.5.2. Justificación social
Medicuida tiene un impacto directo en la mejora de la calidad de vida de los adultos
mayores. Al permitir un seguimiento preciso del estado de salud y facilitar la gestión médica diaria,
el sistema contribuye a un entorno más seguro, ordenado y digno para los residentes. También
fortalece la comunicación entre el personal médico, los cuidadores y los familiares, promoviendo
una atención integral. El uso de recordatorios, reportes y alertas en tiempo real favorece la
autonomía de los adultos mayores y disminuye significativamente la sobrecarga de trabajo del
personal asistencial.
2.5.3. Justificación económica
Desde la perspectiva económica, Medicuida permite optimizar el tiempo del personal
médico y cuidador al automatizar procesos repetitivos, lo que se traduce en una mayor eficiencia
operativa. La reducción de errores en la administración de medicamentos y la mejora en la
respuesta a emergencias pueden evitar costos médicos innecesarios. Además, el hecho de ser un
sistema Web evita gastos adicionales en infraestructura física, ya que solo requiere una conexión a
internet y dispositivos compatibles, lo que lo convierte en una solución económica, viable y
adaptable a futuras necesidades.
2.5.4. Justificación científica
El sistema Web Medicuida se diferencia de otros productos similares en el mercado por
su enfoque integral e innovador en el seguimiento del estado de salud de adultos mayores,
combinando tecnologías de información con un dispositivo de hardware personalizado: un
circuito medidor de pulso con señal de emergencia desarrollada específicamente para este
proyecto. A diferencia de soluciones convencionales que solo permiten la gestión digital de
medicamentos y citas, este sistema incorpora un monitoreo en tiempo real del ritmo cardíaco de
7
los pacientes, convirtiéndose en una herramienta preventiva y de respuesta rápida ante posibles
emergencias.
El circuito medidor, diseñado como parte integral del sistema, cumple una función
científica fundamental al registrar constantemente las pulsaciones del usuario al ser usado,
permitiendo detectar alteraciones en el ritmo cardíaco antes de que se conviertan en eventos
críticos. Esta tecnología ha sido programada para operar mediante un sistema de tres niveles de
alerta:
Nivel Verde: Indica un estado de pulsaciones normales y estables, reflejando que el paciente
se encuentra dentro de sus rangos fisiológicos habituales.
Nivel Amarillo: Se activa cuando el paciente aprieta el botón 1 vez el cual manda la señal
de ayuda. Esta alerta funciona como una advertencia preventiva para que el personal de cuidado
pueda hacer seguimiento inmediato al paciente.
Nivel Rojo: Se activa ante un cambio brusco o extremo en las pulsaciones, ya sea por
taquicardia o bradicardia severa. Esta alerta desencadena automáticamente una señal de emergencia
en el sistema Web, notificando al personal correspondiente para una atención inmediata.
Este tipo de monitoreo continuo y clasificado por niveles de alerta representa un avance
significativo frente a otros sistemas que dependen únicamente del reporte manual o de
intervenciones del cuidador. La inclusión de un dispositivo biométrico conectado al sistema de
información permite no solo mejorar el tiempo de respuesta ante situaciones de riesgo, sino también
recopilar datos útiles para el análisis médico posterior, abriendo la posibilidad de implementar
modelos de prevención más eficaces en el futuro.
En suma, la integración de este circuito medidor dentro del sistema Medicuida proporciona
una capa adicional de seguridad clínica basada en criterios fisiológicos medibles, marcando una
8
clara diferencia en el abordaje tecnológico del cuidado geriátrico frente a otras plataformas
tradicionales del sector.
2.6. Límites
El sistema Web no incluirá funcionalidades para la gestión de personal, horarios laborales
ni control de asistencia del equipo médico o de cuidadores.
El sistema estará enfocado en el funcionamiento y validación en un entorno controlado de prueba,
sin contemplar su distribución comercial o implementación masiva en esta etapa.
No se contemplará el uso de inteligencia artificial ni algoritmos predictivos avanzados en
la toma de decisiones médicas.
No se gestionarán temas financieros ni administrativos como pagos, cobros o facturación
dentro de la plataforma.
2.7. Alcances
El sistema Web permitirá cargar imágenes de perfil para los usuarios, facilitando la
identificación clara de los responsables de cada cuenta.
La aplicación contará con una función de recordatorios automáticos para la
administración de medicamentos y la programación de citas médicas, garantizando el
cumplimiento de los tratamientos.
El sistema será capaz de almacenar grandes cantidades de datos médicos e históricos
sin comprometer su estabilidad ni la integridad de la información.
Se integrará un módulo que registre el historial de administración de medicamentos
y eventos médicos, permitiendo el seguimiento detallado de cada residente.
El sistema permitirá la exportación de reportes clave en formatos PDF o Excel,
facilitando la documentación externa o el respaldo manual por parte del personal.
9
La plataforma permitirá registrar y almacenar los distintos eventos médicos y alertas generadas
por el paciente, lo que facilitará su análisis posterior y permitirá la toma de decisiones clínicas mejor
informadas.
El sistema contempla la posibilidad de escalar sus funcionalidades e integraciones en futuras
fases, permitiendo incorporar nuevos módulos, sensores u optimizaciones técnicas conforme evolucionen
las necesidades del geriátrico.
10
CAPÍTULO 3
MARCO TEÓRICO
Medicuida se basa en varias teorías y conceptos fundamentales vinculados a la
gerontología, la gestión de la salud y el desarrollo de software enfocado en la usabilidad y
accesibilidad.
Desde la perspectiva gerontológica, el envejecimiento es un proceso natural que implica
una serie de transformaciones físicas, cognitivas y sociales. Es esencial entender estos cambios
para desarrollar una herramienta que atienda adecuadamente las necesidades de las personas
mayores. La teoría de la actividad y la teoría de la continuidad son pertinentes en este contexto, ya
que indican que mantener a las personas mayores activas y con un sentido de continuidad en sus
vidas favorece su bienestar general. (Liberty D., 2019)
En relación con la gestión de la salud, la teoría de la adherencia a la medicación destaca la
importancia de cumplir adecuadamente con los regímenes de medicamentos para prevenir
complicaciones de salud. Factores como la sencillez del régimen, la claridad de las instrucciones y
los recordatorios efectivos son fundamentales para aumentar la adherencia. (Brown, M. T., &
Bussell, J. K., 2011)
11
3.2. PHP (Hypertext Preprocessor).
PHP es un lenguaje de programación de código abierto, orientado a objetos, ampliamente
utilizado para el desarrollo web. Se integra fácilmente con HTML, permitiendo generar páginas
dinámicas e interactivas. Su facilidad de uso lo convierte en una opción accesible para
principiantes, al tiempo que ofrece características avanzadas para desarrolladores experimentados
(Ortega, s.f.).
3.2.1. Características de PHP.
PHP es un lenguaje de programación orientado a objetos, gratuito y de código abierto, lo
que lo convierte en una herramienta altamente accesible tanto para desarrolladores principiantes
como para expertos. Su estructura permite separar el código dinámico del contenido estático,
optimizando el procesamiento de datos y facilitando la organización del desarrollo. La versatilidad
de PHP lo hace compatible con distintos servidores y sistemas operativos, siempre que el entorno
tenga capacidad de interpretación. Además, PHP posee una comunidad muy activa, lo que garantiza
soporte constante y recursos de aprendizaje. Se destaca por permitir un desarrollo limpio y
escalable, además de soportar múltiples tipos de datos como enteros, decimales, cadenas de texto,
valores booleanos, objetos, arreglos, valores nulos y recursos externos, consolidándose como una
solución robusta para el desarrollo de aplicaciones y sistemas web complejos. (Ortega, s. f.)
3.3. Javascript.
Javascript es un lenguaje de programación utilizado para crear páginas Web dinámicas e
interactivas. Es el lenguaje de scripting más utilizado en la Web y lo emplean los desarrolladores
para añadir funcionalidad a sitios Web y aplicaciones.
Puede utilizarse para crear interfaces de usuario interactivas, crear aplicaciones del lado del
servidor, conectar bases de datos y mucho más. Su código de programación se ha convertido en
12
una parte esencial del desarrollo Web moderno y puede encontrarse en prácticamente todas las
aplicaciones Web.
Asimismo, es compatible con todos los navegadores modernos, lo cual lo hace un lenguaje
esencial por su versatilidad con diferentes plataformas.
En general, con este lenguaje se incluye dinamismo al navegar un sitio Web, cuando antes
se caracterizaban por ser estáticos. Es decir, un mejoramiento de la experiencia del usuario y al
mismo tiempo, una optimización de procesos debido a su facilidad de uso tanto del lado del cliente,
como del servidor.
Entre sus tareas más comunes podemos encontrar el uso de bases de datos, optimización de
las funciones de una plataforma y el desarrollo tanto de Web apps como aplicaciones móviles.
(Stride, 2023)
3.3.1. Características de Javascript.
JavaScript es un lenguaje de programación de alto nivel, interpretado y orientado a objetos,
cuya principal fortaleza radica en su capacidad para ejecutar código directamente en el navegador,
sin necesidad de compilación previa. Su sintaxis, parecida al lenguaje natural, lo convierte en una
opción intuitiva para desarrolladores. Este lenguaje es altamente versátil y puede ejecutarse en
múltiples plataformas y dispositivos, permitiendo la creación de interfaces interactivas, funciones
dinámicas y conexiones a bases de datos como MySQL o MongoDB. Su arquitectura asíncrona
permite ejecutar tareas en segundo plano sin afectar el rendimiento general de la página, y gracias
a su compatibilidad con formatos como JSON y a su capacidad para conectarse con diversas API’s
externas, se pueden desarrollar aplicaciones web altamente funcionales e integradas. Además, su
ecosistema incluye una gran cantidad de librerías y frameworks como React, Angular o [Link], y
13
ofrece soporte para tecnologías modernas como Web Assembly, lo que extiende aún más sus
capacidades para el desarrollo web de alto rendimiento. (Stride, 2023)
3.4. HTML (HyperText Markup Language).
HTML, que significa HyperText Markup Language (Lenguaje de Marcado de Hipertexto),
es el lenguaje estándar utilizado para crear y estructurar el contenido de una página Web. Define
la estructura y el significado del contenido, incluyendo texto, imágenes, enlaces y otros elementos
multimedia. Es el esqueleto de una página Web, que los navegadores interpretan para mostrar el
contenido al usuario. (Islas, 2025)
3.4.1. Características de HTML.
HTML es un lenguaje de marcado que permite estructurar el contenido de una página web
de manera jerárquica mediante el uso de etiquetas, facilitando la organización de textos, imágenes,
enlaces y elementos multimedia. Aunque no es un lenguaje de programación, constituye la base
fundamental para el desarrollo web, ya que define la estructura sobre la que se construye el resto
de la experiencia digital. Su facilidad de uso y aprendizaje lo convierten en una herramienta
accesible para principiantes, mientras que su capacidad para crear hipertextos permite la
navegación eficiente entre páginas. HTML es compatible con todos los navegadores modernos y,
al ser un estándar definido por el W3C, garantiza interoperabilidad y soporte constante. Su
evolución ha llegado hasta HTML5, que introduce nuevas etiquetas y funcionalidades adaptadas a
las necesidades actuales del desarrollo web. (Eloygiles, 2024)
3.5. CSS (Cascading Style Sheets).
Como HTML, CSS (Cascading Style Sheets) u Hojas de estilo en cascada en español, no
es realmente un lenguaje de programación, tampoco es un lenguaje de marcado. Es un lenguaje de
14
hojas de estilo, es decir, te permite aplicar estilos de manera selectiva a elementos en documentos
HTML. (CSS Básico - Aprende Desarrollo Web | MDN, 2025)
3.5.1. Características de CSS.
CSS es un lenguaje de hojas de estilo utilizado para definir la presentación visual de
documentos HTML, permitiendo separar el contenido de su apariencia. Su sintaxis es sencilla, lo
que facilita su aprendizaje y mantiene una estructura organizada para su mantenimiento. CSS es
altamente flexible, adaptándose a distintos dispositivos y plataformas mediante técnicas de diseño
responsivo, lo que asegura una experiencia visual coherente sin importar el entorno. Al ser
independiente del contenido, optimiza el rendimiento de la red al reutilizar estilos y reducir el
tamaño del código necesario. Asimismo, CSS puede combinarse con otros lenguajes como
JavaScript para lograr efectos interactivos y personalizados, y cuenta con un amplio conjunto de
propiedades que permiten construir interfaces ricas, accesibles y visualmente atractivas. Su
compatibilidad multiplataforma lo hace una pieza clave en el desarrollo de páginas web modernas.
(Cano, 2025)
3.6. Base de datos.
Se llama base de datos, o también banco de datos, a un conjunto de información
perteneciente a un mismo contexto, ordenada de modo sistemático para su posterior recuperación,
análisis y/o transmisión. Existen actualmente muchas formas de bases de datos, que van desde una
biblioteca hasta los vastos conjuntos de datos de usuarios de una empresa de telecomunicaciones.
Las bases de datos son el producto de la necesidad humana de almacenar la información,
es decir, de preservarla contra el tiempo y el deterioro, para poder acudir a ella posteriormente. En
ese sentido, la aparición de la electrónica y la computación brindó el elemento digital indispensable
15
para almacenar enormes cantidades de datos en espacios físicos limitados, gracias a su conversión
en señales eléctricas o magnéticas.
El manejo de las bases de datos se lleva mediante sistemas de gestión (llamados DBMS por
sus siglas en inglés: Database Management Systems o Sistemas de Gestión de Bases de Datos),
actualmente digitales y automatizados, que permiten el almacenamiento ordenado y la rápida
recuperación de la información. En esta tecnología se halla el principio mismo de la informática.
En la conformación de una base de datos se pueden seguir diferentes modelos y paradigmas,
cada uno dotado de características, ventajas y dificultades, haciendo énfasis en su estructura
organizacional, su jerarquía, su capacidad de transmisión o de interrelación, etc. Esto se conoce
como modelos de base de datos y permite el diseño y la implementación de algoritmos y otros
mecanismos lógicos de gestión, según sea el caso específico. (Equipo editorial, Etecé, 2024)
3.7. MySQL.
MySQL es un sistema de gestión de bases de datos relacionales de código abierto,
ampliamente utilizado para almacenar y gestionar datos. Se utiliza el lenguaje SQL (Structured
Query Language) para interactuar con MySQL, permitiendo la definición, manipulación, control y
consulta de datos. (Erickson, 2024)
3.7.1. Características de MySQL.
MySQL es un sistema de gestión de bases de datos relacional que destaca por ser gratuito,
de código abierto y altamente escalable, lo que lo hace ideal tanto para aplicaciones pequeñas como
para sistemas empresariales complejos. Su compatibilidad con múltiples plataformas, como
Windows, Linux y macOS, así como su integración con diversos lenguajes de programación, lo
convierte en una herramienta versátil para desarrolladores. MySQL ofrece mecanismos de
autenticación, cifrado y control de accesos que fortalecen la seguridad de la información, y
16
proporciona un rendimiento elevado gracias a su capacidad de respuesta rápida en la ejecución de
consultas. Además, es personalizable, permitiendo adaptar su configuración a las necesidades
específicas del proyecto, y facilita la recuperación y manipulación eficiente de los datos mediante
el lenguaje SQL. Su confiabilidad lo posiciona como uno de los sistemas de bases de datos más
utilizados a nivel global. (Arsys, s. f.)
3.8. Modelos de base de datos.
3.8.1. Modelo Entidad – Relación.
El modelo entidad relación es una herramienta que permite representar de manera
simplificada los componentes que participan en un proceso de negocio y el modo en el que estos
se relacionan entre sí.
El modelo entidad relación tiene tres elementos principales:
Entidades: El modelo contará con una entidad por cada uno de los componentes del
proceso de negocio. Así, en un negocio de venta de suscripciones a revistas, podemos tener
entidades “Cliente”, “Dirección”, “Factura”, “Producto”, o “Incidencias”, entre otras.
Atributos: Los atributos, componente fundamental de cada modelo entidad-relación, nos
permiten describir las propiedades que tiene cada entidad. “Nombre”, “Primer Apellido”,
“Segundo Apellido”, ”Fecha de nacimiento”, “Género” o “Segmento de valor” serán atributos de
la entidad “Cliente”.
Relaciones: Con las relaciones se establecen vínculos entre parejas de entidades. Cada
“Cliente” tendrá una “Dirección” de envío en la que recibirá la suscripción, podrá estar suscrito a
uno o varios “Productos”, y recibirá una “Factura” con la periodicidad acordada.
El diagrama entidad relación es la expresión gráfica del modelo entidad relación. En él las
entidades se representan utilizando rectángulos, los atributos por medio de círculos o elipses y las
17
relaciones como líneas que conectan las entidades que tienen algún tipo de vínculo. También es
muy común el formato de diagrama en el que los atributos de una entidad aparecen listados en
filas dentro del rectángulo que representa a esa entidad.
Además, es común que, en el modelo entidad-relación, los conectores que indican que dos
entidades A y B están relacionadas entre sí tengan una apariencia gráfica diferente dependiendo
del tipo de relación que exista entre ellas. (_ESIC Business & Marketing School, s. f.)
Figura 1: Ejemplo de modelo Entidad-Relación
Fuente: (Ilerna & Ilerna, 2024)
3.8.2. Modelo Relacional.
El modelo de base de datos relacional fue creado en 1970 por Edgar Frank Codd desde los
laboratorios de IBM, para mejorar la forma en que se consultaban los datos. Para comprender mejor
18
cómo funciona y por qué es tan importante en la era digital, te explicaremos algunos conceptos
fundamentales.
Si bien era muy complejo para la época, este modelo se basa en el principio de guardar los
datos como relaciones (tablas). Las tablas están formadas por filas, que puedes ver en forma vertical
(registros), y también por columnas, que puedes ver en dirección horizontal. Cada fila contiene un
ID único, denominado clave, y las columnas de la tabla contienen los atributos de los datos.
(Oyarzún, 2023)
Figura 2: Ejemplo de modelo relacional
Fuente: (Oyarzún, 2023)
Los atributos son las características que queremos destacar de las entidades, se refieren a
las personas, organizaciones, objetos o conceptos sobre los que nos interesa almacenar
información.
Ese ID único de cada registro se conoce como clave primaria (primary key o PK). Mientras
que cada fila se puede vincular para crear una relación entre tablas diferentes, mediante una clave
19
externa (foreign key o FK). La clave externa se presenta como la clave primaria de otra tabla
existente.
De esta forma, se puede vincular cualquier tabla (o relación) con otra mediante un atributo
en común. (Oyarzún, 2023)
3.9. Canva
Canva es una Web de diseño gráfico y composición de imágenes para la comunicación
fundada en 2012, y que ofrece herramientas online para crear tus propios diseños, tanto si son para
ocio como si son profesionales. Su método es el de ofrecer un servicio freemium, que puedes
utilizar de forma gratuita, pero con la alternativa de pagar para obtener opciones avanzadas.
Sirve tanto para diseñadores aficionados como para los más experimentados, incluyendo su
propio banco de imágenes y una serie de herramientas variadas. Si eres un diseñador experimentado
podrás obtener muy buenos resultados de forma rápida y sencilla, y si eres un aficionado no
necesitarás conocimientos para obtener resultados decentes. (Fernández, 2023)
3.10. La metodología de la ruta crítica CPM.
Método de ruta crítica (CPM), acrónimo de Critical Path Method. Es un algoritmo
estadístico de gestión de proyectos en la que tiene lugar la organización y control de actividades
bien definidas. Aquí se supone que la duración de la actividad es fija y segura, por lo que el CPM
es utilizado para calcular la hora de inicio más temprano y más tardía posible para cada actividad.
Este método de la ruta crítica CPM es clave en múltiples sectores.
El proceso en CPM diferencia los caminos críticos y no críticos para reducir el tiempo y
evitar la generación de colas. El motivo de la identificación de los caminos críticos es que, si alguna
actividad se retrasa, hará que todo el proceso se vea afectado. Este aspecto se ve claramente en los
diagramas CPM. (Euroinnova International Online Education, 2025)
20
3.10.1. Pasos para aplicar el método CPM.
Preparar una lista que conste de todas las actividades necesarias para completar un proyecto.
Calcular el tiempo requerido para completar cada actividad.
Determinar la dependencia entre las actividades, pues con este vemos que la "ruta crítica"
se puede definir como una secuencia de actividades en una red. Existen numerosos ejercicios de
ruta crítica que permiten afianzar estos conceptos. (Euroinnova International Online Education,
2025)
3.10.2. Gráfica de CPM.
Las gráficas de CPM muestras una tarea, compuesta por nodos. Están acompañados por la
duración estimada, usualmente en medidas de tiempo como las horas o días. Ahora bien, estos
nodos se unen mediante flechas que indican dependencias lógicas entre tareas, desde el inicio hasta
el fin. Entonces, ¿cuándo se usa el CPM? Se utiliza en tres casos: caminos posibles, duraciones
acumuladas y la ruta crítica antes mencionada. (Euroinnova International Online Education, 2025)
21
Figura 3: Ejemplo de gráfica CPM
Fuente: (Euroinnova International Online Education, 2025)
3.11. Método de Evaluación y Revisión de Programas PERT.
Técnica de Evaluación y Revisión de Proyectos (PERT), acrónimo de Program (Project)
Evaluation and Review Technique. Es una técnica que se utiliza para gestionar las actividades
inciertas de un proyecto, estudiando y representando las tareas para completarlo e identificar el
tiempo mínimo requerido de su ejecución. El método PERT utiliza el tiempo como una variable
que representa la aplicación de recursos planificada junto con la especificación de rendimiento. Es
común ver su aplicación combinada en metodología PERT y CPM. (Euroinnova International
Online Education, 2025)
3.11.1. Pasos para aplicar el método PERT.
El proyecto se divide en actividades y eventos.
22
Después de que se determina la secuencia adecuada, se construye una red. Esta puede
visualizarse como un diagrama PERT CPM.
Por último, se calcula el tiempo necesario en cada actividad y se determina la ruta crítica.
En muchos casos, puede acompañarse de un ejemplo de PERT para facilitar su comprensión.
(Euroinnova International Online Education, 2025)
3.11.2. Diagrama de PERT.
Veamos el siguiente ejemplo de diagrama PERT. Se consideran los siguientes estimaciones
de tiempo: optimista (O), más probable (M) y pesimista (P). Con esto, se calcula la duración
estimada, donde:
O + 4M + P se divide entre 6, que es la cantidad de tareas total.
El proyecto está compuesto por las tareas A, B, C, D, E, F, G. Entre ellas, hay una relación
de continuidad y ramificación, hasta el cierre del proyecto. Por las características del diagrama
PERT, este tipo de representación permite representar tareas variables en duración, estimar el
tiempo total e identificar una ruta para analizar cuellos de botella o prever retrasos. (Euroinnova
International Online Education, 2025)
23
Figura 4: Ejemplo de diagrama PERT
Fuente: (Euroinnova International Online Education, 2025)
3.12. Descripción de los diagramas de circuito
3.12.1. Diagrama del circuito general
El diagrama del circuito general representa la conexión física de todos los componentes
principales del sistema medidor de presión cardíaca integrado en la pulsera inteligente del
proyecto MEDICUIDA. En este circuito, se utiliza un sensor MAX30102 como dispositivo de
entrada para la medición de las pulsaciones del paciente. El sensor está conectado al
microcontrolador Arduino Nano, que actúa como unidad maestra del sistema, interpretando las
señales provenientes del sensor y del botón físico (pulsador). Posteriormente, los datos son
enviados al microcontrolador ESP32, el cual cumple la función de esclavo y está encargado de
transmitir los datos al sistema web mediante conexión Wi-Fi utilizando Firebase como puente.
24
Como elementos de salida del sistema se incorporan un LED y un buzzer, los cuales permiten
emitir alertas visuales y sonoras al detectar anomalías en las pulsaciones, cumpliendo una función
crítica en la señalización de emergencias dentro del entorno de atención en la casa de reposo.
3.12.2. Diagrama esquemático
El diagrama esquemático muestra la conexión lógica entre todos los componentes
electrónicos del circuito medidor. Este esquema detalla las conexiones exactas entre los pines del
ESP32, el Arduino Nano, el sensor MAX30102, el buzzer, el LED y el pulsador. En él se puede
observar la disposición de cada componente en un entorno de simulación electrónica, facilitando
el análisis y verificación de la continuidad del circuito antes de su implementación física. El
Arduino Nano, al ser el procesador maestro, recibe los datos del sensor y los interpreta según los
rangos definidos. Si los valores están fuera del rango seguro, se activa el buzzer y/o LED como
alerta, y los datos son posteriormente enviados por el ESP32 al sistema. Este diagrama es
esencial para la validación de conexiones y para la creación del prototipo funcional del hardware,
siendo una referencia clave para cualquier corrección o mejora futura del diseño electrónico.
3.12.3. Diagrama de estado
El diagrama de estado describe el comportamiento lógico del sistema de medición de
pulsaciones. Se inicia desde un estado Inactivo, en el cual el sistema espera detectar el dedo del
paciente en el sensor. Al ser detectado, el sistema pasa al estado Activo donde comienza el
proceso de cálculo del promedio de BPM (latidos por minuto). Dependiendo del resultado del
análisis, el sistema puede permanecer en un estado Normal (nivel verde) o transitar hacia un
estado de Alerta Amarilla (cuando los pulsos se desvían ligeramente del rango aceptable) o hacia
una Alerta Roja (cuando los pulsos se encuentran en rangos peligrosos). En el caso de alerta, se
permite la interacción mediante el pulsador. Un clic en el botón genera una alerta amarilla, y dos
25
clics generan una alerta roja, activando los mecanismos de señalización. Finalmente, el sistema
registra y envía los datos al entorno digital para su monitoreo, retornando luego al estado inicial
de espera. Este diagrama refleja claramente la lógica del flujo de estados de la pulsera inteligente
y sus respuestas ante situaciones fisiológicas críticas.
3.12.4. Diagrama de bloques
El diagrama de bloques representa una visión abstracta y simplificada de la arquitectura
funcional del circuito integrado en la pulsera inteligente. Comienza con los elementos de entrada,
que son el sensor de pulsaciones MAX30102 y el botón de emergencia. Ambos están conectados
al Arduino Nano, el cual actúa como controlador maestro encargado de procesar la información y
determinar si es necesario activar alguna alerta. Las salidas del sistema consisten en un LED y un
buzzer, utilizados para señalización inmediata. Paralelamente, el Arduino envía los datos al
ESP32, el cual actúa como esclavo responsable de realizar la conexión inalámbrica con la nube.
Esta conexión se realiza mediante Firebase, que sirve como intermediario para que el sistema
pueda reportar la información a una plataforma web de monitoreo o dashboard visible por el
personal autorizado. Este diseño modular y jerarquizado asegura la eficiencia en la recopilación,
procesamiento, respuesta local y envío remoto de los datos críticos del paciente.
26
CAPÍTULO 4
MARCO APLICATIVO
4.1. Introducción a la metodología de Análisis SCRUM
SCRUM es una metodología ágil de gestión de proyectos que permite desarrollar productos
de forma iterativa e incremental, enfocándose en la colaboración continua entre los miembros del
equipo y los interesados. En el contexto del desarrollo del sistema Medicuida, SCRUM se eligió
por su capacidad de adaptarse a los cambios, dividir el trabajo en ciclos manejables llamados sprints
y fomentar la entrega constante de valor funcional.
Esta metodología se estructura en roles, eventos y artefactos específicos. El equipo de
desarrollo de Medicuida se organizó bajo la estructura SCRUM con los siguientes roles:
Product Owner: Encargado de definir las características del producto y priorizar el backlog.
Scrum Master: Responsable de garantizar la correcta aplicación de SCRUM y eliminar
obstáculos para el equipo.
Equipo de Desarrollo: Grupo multidisciplinario que trabaja en la implementación de las
funcionalidades del sistema.
A lo largo del proyecto, se llevaron a cabo sprints planificados con reuniones periódicas
(dailys, reviews, retrospectives) y una constante evaluación de avances, lo cual permitió adaptar
rápidamente las funcionalidades del sistema a las necesidades reales del entorno de casas de reposo.
27
4.2. Fase 1 – Pre Game
4.2.1. Análisis de requerimientos
Durante esta etapa inicial del proyecto Medicuida, se identificaron y documentaron los
requerimientos funcionales y no funcionales necesarios para desarrollar un sistema eficiente,
seguro y fácil de usar para casas de reposo. Para ello, se realizaron entrevistas con usuarios
potenciales (médicos, cuidadores, familiares) y se analizaron casos de uso comunes en entornos
similares.
Los requerimientos funcionales identificados incluyen, entre otros:
• Gestión de usuarios con roles diferenciados (Superadmin, Administrador, Médico,
Cuidador, Familiar, Residente).
• Registro, edición y consulta de citas médicas y eventos del paciente.
• Administración de tratamientos, medicamentos y horarios de suministro.
• Registro de visitas y gestión de emergencias mediante un botón inteligente.
• Visualización del historial médico del paciente.
• Generación de notificaciones automáticas a familiares y cuidadores.
• Paneles personalizados según el tipo de usuario.
• Control de inventario médico y gestión de stock.
Los requerimientos no funcionales establecidos fueron:
• Accesibilidad desde múltiples dispositivos (interfaz responsive).
• Seguridad en el acceso mediante login con roles.
• Integración futura con hardware.
• Uso de tecnologías estándar: PHP, MySQL, HTML, JavaScript y CSS.
• Uso local del sistema mediante servidor XAMPP.
28
• Capacidad de generar reportes automatizados en formatos digitales.
Este análisis permitió construir el Product Backlog, estructurado por módulos de desarrollo
y priorizado según la criticidad de cada funcionalidad, sirviendo como base para la planificación
de los sprints.
4.2.2. Historias de usuario
Las historias de usuario permiten describir de manera clara y concisa las funcionalidades
requeridas desde la perspectiva del usuario final. Estas historias ayudan al equipo de desarrollo a
entender las necesidades reales y priorizar el trabajo con base en el valor entregado. A
continuación, se presentan las historias de usuario de cada uno de los roles en el sistema Web:
• Como Superadministrador, quiero gestionar los diferentes roles del sistema, para mantener
el control de acceso a las funcionalidades.
• Como Administrador, quiero registrar, editar y eliminar usuarios del sistema, para asegurar
que solo usuarios autorizados puedan interactuar con él.
• Como Médico, quiero poder ver el historial médico de los residentes, para tener una base
adecuada al tomar decisiones clínicas.
• Como Cuidador, quiero recibir notificaciones sobre medicamentos y eventos del paciente,
para dar seguimiento en tiempo real.
• Como Familiar, quiero visualizar el estado de salud y citas del residente, para mantenerme
informado del bienestar de mi ser querido.
Cada historia de usuario incluye criterios de aceptación y está vinculada a tareas específicas
dentro del Product Backlog.
29
4.2.3. Product Backlog
El Product Backlog de Medicuida está compuesto por todas las funcionalidades requeridas
para el correcto desarrollo del sistema. Este fue organizado en categorías funcionales para facilitar
la gestión y asignación durante los diferentes sprints:
Diseño:
Elaboración de mockups de interfaces para cada rol.
Diseño de arquitectura de base de datos.
Maquetado:
Maquetación de página de inicio.
Maquetación de formularios de login.
Maquetación de paneles según roles.
Frontend:
Implementación de login.
Visualización de citas, tratamientos y reportes.
Interfaz para panel de control de cada rol.
Backend:
Gestión CRUD de usuarios, roles, medicamentos y citas.
Registro de emergencias y notificaciones.
Conexión con la base de datos.
Hardware:
Planificación y diseño del circuito medidor de pulso con alerta de emergencia.
Vinculación del sistema con alertas emitidas desde hardware externo.
Cada ítem del backlog tiene una prioridad asignada (alta, media, baja), así como su
30
correspondiente historia de usuario. El backlog es un documento vivo que puede adaptarse a
medida que cambian los requerimientos o se completan tareas.
4.2.4. Sprint Backlog
El Sprint Backlog de Medicuida se estructura en nueve sprints que abordan
progresivamente las distintas áreas funcionales del sistema, desde el diseño inicial hasta la
integración con hardware. Cada sprint contiene un conjunto específico de tareas seleccionadas del
Product Backlog, priorizadas según valor al usuario y dependencia técnica.
Sprint 1 – Planificación y Diseño:
Este primer sprint se centra en el análisis, la conceptualización y la planificación general
del proyecto. Se elaboraron los mockups de las interfaces, se definieron los requerimientos
funcionales y no funcionales, se diseñó la arquitectura del sistema y se estructuró el modelo
entidad-relación de la base de datos. También se estableció la organización del equipo SCRUM y
se asignaron responsabilidades.
Sprint 2 – Maquetado e Inicio del Sistema:
En esta fase se implementaron las estructuras base del sistema, incluyendo el login de
usuarios, el sistema de autenticación y las primeras ventanas principales. También se estableció la
conexión con la base de datos y se diseñaron las interfaces visuales de los paneles iniciales para
roles como Superadmin, Administrador y Médico.
Sprint 3 – Funcionalidades Médicas:
Este sprint abordó el desarrollo de funcionalidades clave relacionadas con la gestión
médica, como el registro y consulta de citas médicas, administración de tratamientos, y control de
medicamentos. Se diseñaron y vincularon formularios y vistas para médicos y cuidadores,
integrando validaciones y almacenamiento en la base de datos.
31
Sprint 4 – Comunicación y Asistencia:
Se desarrollaron las funcionalidades de comunicación interna entre los usuarios del sistema,
especialmente entre médicos, cuidadores y familiares. También se incluyó el sistema de asignación
de tareas y asistencias programadas, con un enfoque en facilitar la coordinación entre personal de
salud y residentes.
Sprint 5 – Notificaciones y Recordatorios:
Este sprint se enfocó en el desarrollo del sistema de notificaciones automáticas y
personalizadas, orientadas a eventos como citas próximas, alertas médicas y tareas asignadas. Las
notificaciones se adaptan al tipo de usuario y se visualizan en los respectivos paneles de control.
Sprint 6 – Emergencias y Visualización Crítica:
Se trabajó en la implementación del botón de emergencia, alertas críticas del sistema y su
visualización en tiempo real. Esta funcionalidad es clave para responder a situaciones de riesgo
para los residentes, incluyendo paneles de monitoreo para cuidadores y personal médico.
Sprint 7 – Gestión de Residentes e Historial:
Se desarrolló la administración detallada de los residentes, incluyendo su historial médico,
evolución de tratamientos y visitas. Esta información queda accesible desde los distintos roles, con
distintos niveles de privilegio según el usuario.
Sprint 8 – Finalización y Reportes:
En este sprint se completaron tareas pendientes de otros sprints y se desarrollaron
funcionalidades de generación de reportes médicos, administrativos y de actividad. También se
afinó el sistema de permisos y se aplicaron pruebas generales del sistema.
32
Sprint 9 – Hardware e Integración:
Finalmente, se desarrolló la planificación y conexión con hardware externo,
específicamente con el circuito medidor de pulso con señal de emergencia. Se integraron los datos
provenientes del dispositivo al sistema Medicuida y se realizaron pruebas de funcionalidad, además
de asegurar la interoperabilidad del software con los sensores.
4.3. Fase 2 – Game
4.3.1. Diseño del sistema
En esta sección se incluyen los diagramas utilizados durante el diseño del sistema
Medicuida, los cuales nos permitieron representar las funcionalidades del sistema y la interacción
entre los actores y los módulos principales.
[Link]. Diagramas de casos de uso
El siguiente diagrama de casos de uso representa las principales funcionalidades del sistema
Medicuida, así como los actores que interactúan con él: Superadmin, Administrador, Médico,
Cuidador y Familiar.
Cada uno de estos actores tiene asignadas responsabilidades específicas:
33
Figura 5: Diagrama de casos de uso
Fuente: Elaboración propia
34
[Link]. Diagrama de actividades
El diagrama de actividades del sistema Medicuida representa de forma gráfica y
estructurada el flujo dinámico de acciones que los distintos roles del sistema realizan a lo largo de
su interacción con la plataforma. Este tipo de diagrama permite visualizar no solo las actividades
individuales de cada actor, sino también la relación entre procesos, decisiones condicionales y
subprocesos comunes como la mensajería o la gestión de emergencias.
El modelo está organizado en bloques diferenciados según el tipo de usuario:
Superadministrador, Administrador, Médico, Cuidador y Familiar, lo que facilita la identificación
de responsabilidades, accesos y tareas correspondientes a cada rol dentro del sistema.
El flujo inicia con el acceso al sistema, donde el usuario se autentica mediante
credenciales y, según su perfil, se le redirige a su respectiva interfaz de funcionalidades. A partir
de allí, se desencadenan los procesos específicos:
El Superadmin puede gestionar usuarios, roles y monitorear el uso general del sistema.
El Administrador tiene la capacidad de registrar personal, controlar inventario médico y
supervisar registros de atención.
El Médico puede visualizar la historia clínica de los pacientes, crear o modificar
tratamientos, generar diagnósticos y programar citas, además de comunicarse con cuidadores y
familiares.
El Cuidador se encarga del seguimiento diario del paciente, incluyendo la administración
de medicamentos, registro de síntomas, y reporte de eventos relevantes.
El Familiar puede consultar el estado del paciente, visualizar recordatorios y comunicarse
con el personal de atención.
35
El diagrama también incluye subflujos esenciales como la gestión de emergencias, donde
el cuidador o el médico puede activar una alerta crítica que se propaga al sistema y a los
familiares vinculados.
36
Figura 6: Diagrama de actividades
Fuente: Elaboración propia
37
[Link]. Diagramas de secuencia
a) Diagrama de Secuencia – Inicio de Sesión
Este diagrama representa el proceso de autenticación que sigue un usuario para acceder al
sistema Medicuida. El flujo inicia cuando el usuario, sin importar su rol (Superadmin,
Administrador, Doctor, Cuidador o Familiar), introduce sus credenciales en la interfaz web. Esta
información es enviada al controlador de autenticación, que se encarga de validar los datos
ingresados consultando la base de datos. En función de los resultados, el sistema responde
indicando si el acceso fue concedido o si hubo un error en la autenticación. Este diagrama refleja
el mecanismo de seguridad base que permite controlar el acceso de manera diferenciada según el
tipo de usuario.
Figura 7: Inicio de Sesión (aplicable a todos los roles)
Fuente: Elaboración propia
38
b) Diagrama de Secuencia – Agendar Cita Médica
El diagrama de agendamiento de citas médicas muestra el flujo interno del sistema para
programar una consulta. Similar al proceso de registro, se inicia con el ingreso de los datos por
parte del usuario (Doctor o Cuidador), seguido por una verificación de la fecha y hora. El
controlador de citas consulta la disponibilidad en la base de datos y, si no existen conflictos, guarda
la información. Este proceso asegura la correcta coordinación entre los roles responsables del
cuidado del paciente, evitando solapamientos o inconsistencias.
Figura 8: Agendar Cita Médica (Doctor / Cuidador)
Fuente: Elaboración propia
39
c) Diagrama de Secuencia – Activación del Sistema de Emergencias
Este diagrama describe el comportamiento automatizado del sistema cuando detecta una
situación crítica en el paciente. A diferencia de procesos manuales, esta acción es activada
automáticamente por el circuito medidor del paciente cuando registra un nivel de presión peligrosa.
Una vez detectado el evento, la señal es enviada al controlador del sistema de emergencias, que
registra la alerta en la base de datos y procede a notificar a los contactos responsables, como
médicos y familiares. Esta funcionalidad busca brindar una respuesta rápida ante situaciones
potencialmente riesgosas para el paciente.
Figura 9: Sistema de emergencias
Fuente: Elaboración propia
40
[Link]. Modelo entidad-relación.
El modelo entidad-relación (ER) es una herramienta conceptual utilizada en el diseño de
bases de datos para representar la estructura y relaciones entre los datos. El proyecto Medicuida,
este modelo define las entidades principales (como usuarios, residentes, medicamentos, citas
médicas y emergencias) y sus relaciones (por ejemplo, un médico prescribe medicamentos a un
residente). Este modelo permite visualizar cómo se organizará la información en la base de datos,
garantizando su integridad y eficiencia.
//* SE HARÁ PLOTEAR EL MODELO ENTIDAD - RELACIÓN *//
Figura 10: Modelo entidad-relación
Fuente: Elaboración propia
41
42
43
44
45
46
47
[Link]. Modelo relacional
El modelo relacional es la implementación práctica del modelo ER, donde los datos se
organizan en tablas (relaciones) compuestas por filas y columnas. En el presente proyecto
Medicuida, este modelo se utiliza para estructurar la base de datos en MySQL, definiendo tablas
como "Usuarios", "Medicamentos", "Citas Médicas" y "Alertas de Emergencia". Cada tabla tiene
atributos específicos (columnas) y relaciones entre ellas mediante claves primarias y foráneas, lo
que permite consultas eficientes y un manejo estructurado de la información.
//* SE HARÁ PLOTEAR EL MODELO RELACIONAL *//
Figura 11: Modelo relacional (MySQL)
Fuente: Elaboración propia
48
49
50
[Link]. Diagrama de clases de alto nivel
El diagrama de clases de alto nivel del sistema web Medicuida representa la estructura
lógica del software, mostrando las entidades principales, sus atributos clave, y las relaciones entre
ellas, organizadas bajo el enfoque orientado a objetos. Este modelo permite visualizar cómo
se organiza la información dentro del sistema y cómo interactúan los diferentes componentes del
mismo.
En el centro del diseño se encuentra la clase abstracta Usuario, de la cual heredan los
distintos roles del sistema: Doctor, Cuidador, Familiar, Administrador y Superadmin, utilizando el
principio de generalización (←⊣). Esto permite compartir atributos comunes como nombre, correo
o contraseña, y extender funcionalidades específicas para cada tipo de usuario.
La entidad Paciente, que ya no actúa como usuario activo, se sitúa como un nodo central,
vinculado a múltiples clases asociadas a su atención médica, tales como:
Circuito (Hardware): vinculada por composición (←◆), ya que el circuito medidor es parte
inseparable del paciente y permite el monitoreo en tiempo real de su pulso.
CitasMédicas, HistorialEmergencias y Tratamientos: también con composición, ya que no
tienen sentido sin la existencia del paciente.
HistorialMédico y Mediciones: están relacionadas mediante agregación o asociación, dado
que pueden existir como registros independientes aunque ligados al paciente.
El módulo de Medicamentos se relaciona a través de los tratamientos médicos y no depende
directamente del paciente, sino del contexto terapéutico en que se aplica.
Para representar la gestión administrativa, se introdujo la clase Registro, la cual permite a
los roles de Administrador y Superadmin registrar o gestionar nuevas entidades en el sistema, como
51
usuarios, pacientes y familiares. Esta clase se vincula a ambos roles por medio de agregación (←◦),
reflejando que pueden utilizar sus funcionalidades sin estar acoplados permanentemente a ellas.
Finalmente, la clase Notificaciones también está conectada a Superadmin, ya que este
recibe alertas del sistema (como emergencias o inicios de sesión) como parte de su función de
supervisión global.
Este diagrama permite comprender la estructura modular, jerárquica y distribuida del
sistema Medicuida, donde cada rol cumple una función específica, y los datos clínicos,
administrativos y de seguridad se integran mediante relaciones precisas.
52
Figura 12: Diagrama de clases de alto nivel
Fuente: Elaboración propia
53
[Link]. Diagrama de bajo nivel
El diagrama de clases de bajo nivel del sistema Medicuida representa gráficamente la
estructura detallada de todas las tablas que conforman la base de datos del proyecto, así como las
relaciones entre ellas. Este diagrama, basado en el modelo relacional implementado en MySQL,
permite visualizar de forma clara la arquitectura lógica del sistema, sus entidades principales, sus
atributos y las claves primarias y foráneas que las conectan.
Cada tabla del sistema fue diseñada para responder a requerimientos funcionales
específicos derivados del análisis previo del sistema, tales como la gestión de usuarios, la
administración de citas médicas, el seguimiento de tratamientos y la detección de emergencias
médicas mediante el circuito medidor. En el diagrama se incluyen tablas como Usuario, Paciente,
Doctor, Familiar, Administrador, Superadmin, Roles, CitasMedicas, Tratamientos, Medicamento,
HistorialMedico, HistorialEmergencias, Mediciones, Circuito, Notificaciones, Registros, entre
muchas otras.
El diagrama muestra claramente las relaciones de herencia (por ejemplo, todas las
entidades de tipo usuario como doctor, cuidador, administrador, etc., derivan de la entidad
general Usuario), las relaciones de composición (como Paciente con Circuito o
HistorialEmergencias, indicando que estas no existen sin el paciente), las agregaciones (como el
uso de medicamentos en los tratamientos), y las asociaciones (como la relación directa entre
Paciente y Familiar).
Este diagrama de bajo nivel tiene como objetivo servir de guía técnica para el desarrollo
backend del sistema, facilitando el trabajo de programación con las consultas SQL, la
normalización de datos, la implementación de restricciones de integridad y la documentación del
diseño de base de datos. Su nivel de detalle permite al equipo de desarrollo comprender de
54
manera precisa cómo interactúan los distintos componentes del sistema desde una perspectiva
lógica y funcional, apoyando también en tareas de mantenimiento, ampliación y futuras
integraciones.
Figura 13: Diagrama de clases de bajo nivel
Fuente: Elaboración propia
55
4.3.2. Diseño del circuito medidor
[Link]. Diagrama del circuito general
Figura 14: Diagrama del circuito general
Fuente: Elaboración propia
56
[Link]. Diagrama esquemático
Figura 15: Diagrama esquemático
Fuente: Elaboración propia
57
[Link]. Diagrama de estado
Figura 16: Diagrama de estado (circuito)
Fuente: Elaboración propia
58
[Link]. Diagrama de bloques
Figura 17: Diagrama de bloques
Fuente: Elaboración propia
59
WEBGRAFÍA
o Arsys. (s. f.-b). ¿Qué es MySQL? Explicación y características.
[Link]
eque%C3%B1as,datos%20para%20garantizar%20la%20seguridad.
o Cano, I. R. (2025c, marzo 5). ¿Qué es el CSS? Conceptos básicos - [Link].
[Link]. [Link]
basicos/#:~:text=Caracter%C3%ADsticas%20de%20CSS,donde%20queremos%20aplicar
%20las%20propiedades.
o CSS básico - Aprende desarrollo web | MDN. (2025b, marzo 31). MDN Web Docs.
[Link]
_website/Styling_the_content
o Eloygiles. (2024b, julio 24). Qué es HTML: guía sobre este lenguaje de programación
básico. Open English. [Link]
o Equipo editorial, Etecé. (2024, 25 noviembre). Base de datos - Concepto, tipos y ejemplos.
Concepto. [Link]
o Erickson, J. (2024b, agosto 29). MySQL: Understanding What It Is and How It’s Used.
[Link]
mysql/#:~:text=MySQL%20es%20un%20sistema%20de,opci%C3%B3n%20popular%20
para%20los%20desarrolladores.
o ESIC Business & Marketing School. (s. f.). Modelo entidad relación: descripción y
aplicaciones. [Link]
descripcion-aplicaciones
60
o Euroinnova International Online Education. (2025b, abril 14). que es cpm y pert.
[Link]
pert#:~:text=PERT%20es%20una%20t%C3%A9cnica%20de,cambi%C3%B3%20como
%20uno%20de%20construcci%C3%B3n.
o Fernández, Y. (2023, 9 junio). Qué es Canva, cómo funciona y cómo usarlo para crear un
diseño. Xataka. [Link]
para-crear-diseno
o Ilerna, & Ilerna. (2024b, septiembre 24). Modelo Entidad-Relación: qué es, cómo se hace
y ejemplos. Blog ILERNA Online: FP A Distancia Con Titulación Oficial.
[Link]
o Islas, D. S. (2025b, abril 28). Qué es HTML: aprende todo sobre este lenguaje web. Blog
de Wix. [Link]
html#:~:text=1.,comunicarnos%20y%20compartir%20informaci%C3%B3n%20globalme
nte.
o Mallón, X. (2024, 25 octubre). ¿Qué es [Link]? [2024] | KeepCoding Bootcamps.
KeepCoding Bootcamps. [Link]
o Ortega, K. (s. f.-b). ¿Qué es el lenguaje de programación PHP? - Saint Leo University. Saint
Leo University. [Link]
el-lenguaje-de-programacion-php
o Oyarzún, G. (2023b, diciembre 19). Base de datos relacional: qué es y cómo funciona.
ComparaSoftware. [Link]
o Stride. (2023b, marzo 31). ¿Qué es Javascript y Para qué Sirve? Usos y Características.
Stride. [Link]
61
ANEXOS
62
ANEXO 1 - PRODUCT BACKLOG
63
ANEXO 2 – HISTORIAS USUARIO
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU00 Solicitante: Jesus Lavadenz
Nombre de historia: Diseño de mockups generales del sistema
Tipo: Diseño Programador Responsable: Carla Encinas
Descripción:
Como desarrollador, necesito diseñar los mockups generales del sistema para visualizar y planificar la
estructura de la aplicación antes de su implementación.
Criterios de aprobación:
1. Se crean mockups navegables de cada vista principal.
2. Se incluye la navegación entre roles.
3. Se valida la consistencia visual y usabilidad.
4. Se aprueba por el equipo antes de iniciar la implementación.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU01 Solicitante: Carla Encinas
Nombre de historia: Diseño de la base de datos
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como desarrollador, necesito diseñar la base de datos del sistema para asegurar un almacenamiento
estructurado y eficiente de la información médica, administrativa y de usuarios.
Criterios de aprobación:
1. Se define el modelo entidad-relación completo.
2. Las tablas tienen claves primarias y foráneas bien definidas.
3. Incluye relaciones entre roles, residentes, citas, medicamentos y alertas.
4. Se prueba la conexión entre frontend y la base de datos.
64
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU02 Solicitante: Isaac Escobar
Nombre de historia: Creación del modelo entidad-relación de la base de datos
Tipo: Backend Programador Responsable: Carla Encinas
Descripción:
Como desarrollador backend, necesito construir el modelo entidad-relación de la base de datos para
visualizar claramente las tablas, relaciones y dependencias antes de implementarla físicamente.
Criterios de aprobación:
1. El modelo representa todas las entidades necesarias.
2. Las relaciones entre tablas están correctamente identificadas.
3. El modelo se revisa y aprueba en conjunto por el equipo técnico.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU03 Solicitante: Jair Vera
Nombre de historia: Diseño del sistema de roles y jerarquías
Tipo: Backend Programador Responsable: Isaac Escobar
Descripción:
Como administrador, necesito que el sistema tenga diferentes roles jerárquicos con permisos
diferenciados para asegurar el correcto acceso a funcionalidades específicas.
Criterios de aprobación:
1. Se crean y asignan roles: Superadmin, Admin, Doctor, Cuidador, Familiar, Residente.
2. Cada rol tiene acceso a vistas y funciones específicas.
3. El sistema restringe accesos según el rol.
65
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU04 Solicitante: Isaac Escobar
Nombre de historia: Desarrollo de ventana de login
Tipo: Fullstack Programador Responsable: Jesus Lavadenz
Descripción:
Como usuario del sistema, quiero acceder mediante un inicio de sesión seguro, para proteger la información
personal y médica.
Criterios de aprobación:
1. La interfaz es clara y funcional.
2. Se valida usuario y contraseña.
3. Se maneja sesión por rol.
4. Se muestra mensaje de error si el acceso falla.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU05 Solicitante: Isaac Escobar
Nombre de historia: Conexión a la base de datos
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como programador, necesito conectar la aplicación a la base de datos para permitir el acceso y
manipulación de los datos del sistema.
Criterios de aprobación:
1. Se establece conexión exitosa con MySQL u otra base definida.
2. Se maneja adecuadamente la desconexión o error de conexión.
3. La conexión es reutilizable en las distintas funcionalidades del sistema.
66
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU06 Solicitante: Isaac Escobar
Nombre de historia: Creación de registros artificiales
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como programador, necesito crear registros de prueba en la base de datos para verificar el correcto funcionamiento
de las funcionalidades del sistema antes de usar datos reales.
Criterios de aprobación:
1. Se crean al menos 10 registros ficticios de residentes, doctores y familiares.
2. Los datos simulan casos reales, incluyendo relaciones entre entidades.
3. Los registros permiten validar el sistema de login, roles y consultas.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU08 Solicitante: Carla Encinas
Nombre de historia: Desarrollo del panel del Doctor con lista de residentes
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como doctor, quiero acceder a un panel con la lista de residentes bajo mi cuidado para gestionar su información
médica.
Criterios de aprobación:
1. El doctor puede ver información relevante de cada residente.
2. Puede generar reportes, ver historial y programar citas.
3. Acceso restringido por rol.
67
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU07 Solicitante: Carla Encinas
Nombre de historia: Desarrollo de panel de administración (Admin)
Tipo: Frontend Programador Responsable: Jair Vera
Descripción:
Como administrador, necesito un panel para gestionar usuarios y recursos del sistema, garantizando un uso eficiente
del entorno.
Criterios de aprobación:
1. El panel permite agregar, editar y eliminar usuarios.
2. Muestra listas de residentes, doctores y cuidadores.
3. Cuenta con filtros y búsqueda.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU09 Solicitante: Isaac Escobar
Nombre de historia: Creación del sistema de agregar y eliminar usuarios del grupo (Admin)
Tipo: Backend Programador Responsable: Carla Encinas
Descripción:
Como administrador del sistema, necesito poder agregar o eliminar usuarios de los distintos grupos de acceso para
mantener el control de usuarios activos y permisos.
Criterios de aprobación:
1. El admin puede agregar usuarios con diferentes roles.
2. El admin puede eliminar usuarios existentes.
3. Se generan notificaciones internas al realizar cambios.
4. Se validan datos antes de agregar o eliminar usuarios.
68
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU10 Solicitante: Jesus Lavadenz
Nombre de historia: Creación de citas y eventos médicos del paciente
Tipo: Backend Programador Responsable: Isaac Escobar
Descripción:
Como médico, necesito crear citas y eventos médicos para que el sistema registre el seguimiento de la atención a los
residentes.
Criterios de aprobación:
1. Se puede registrar fecha, hora, paciente, y motivo de la cita.
2. Se asocian eventos médicos a un paciente específico.
3. Se valida que las citas no se traslapen en horario.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU12 Solicitante: Jair Vera
Nombre de historia: Visualización de signos vitales del paciente
Tipo: Frontend Programador Responsable: Jesus Lavadenz
Descripción:
Como cuidador o doctor, necesito visualizar en el sistema los signos vitales del paciente para monitorear su estado de
salud en tiempo real.
Criterios de aprobación:
1. Se muestran los signos vitales principales: presión, temperatura, frecuencia cardíaca.
2. Los datos se actualizan de forma automática o periódica.
3. Se destacan visualmente valores fuera del rango normal.
69
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU13 Solicitante: Jair Vera
Nombre de historia: Generación de reportes médicos por el Doctor
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como doctor, necesito generar reportes médicos por cada residente para registrar y compartir su evolución clínica.
Criterios de aprobación:
4. Se puede seleccionar un residente y generar un reporte.
5. Los reportes se almacenan en la base de datos.
6. Se exportan en formato PDF.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU14 Solicitante: Isaac Escobar
Nombre de historia: Impresión de reportes e informes médicos
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como doctor, necesito poder imprimir reportes e informes médicos para entregarlos a familiares, autoridades o
guardarlos físicamente.
Criterios de aprobación:
1. Los reportes son exportables a PDF.
2. Incluyen los datos médicos relevantes y actualizados.
3. Se visualizan correctamente antes de impresión.
70
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU16 Solicitante: Jair Vera
Nombre de historia: Chat entre familiares y cuidadores
Tipo: Fullstack Programador Responsable: Carla Encinas
Descripción:
Como familiar, quiero comunicarme directamente con el cuidador del residente para recibir actualizaciones en tiempo
real.
Criterios de aprobación:
1. Mensajes en tiempo real.
2. Se identifica el usuario emisor y receptor.
3. Historial de conversación disponible.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU17 Solicitante: Carla Encinas
Nombre de historia: Desarrollo del sistema de notificaciones generales
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como usuario del sistema, quiero recibir notificaciones de eventos importantes para mantenerme informado sobre
actividades y alertas.
Criterios de aprobación:
1. Notificaciones en tiempo real para usuarios específicos.
2. Diferentes tipos de notificación: cita, emergencia, recordatorio.
3. Se registra historial de notificaciones.
71
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU18 Solicitante: Jesus Lavadenz
Nombre de historia: Recordatorios automáticos de medicamentos
Tipo: Backend Programador Responsable: Carla Encinas
Descripción:
Como residente, se requiere recibir recordatorios automáticos para la toma de medicamentos, para asegurar el
cumplimiento de mis tratamientos de forma oportuna.
Criterios de aprobación:
1. El sistema envía notificaciones en los horarios establecidos por el médico.
2. Se permite personalizar los horarios de cada medicamento.
3. Se registra si el residente confirma haber tomado el medicamento.
4. Se genera una alerta al cuidador si el residente no confirma la toma.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU19 Solicitante: Jesus Lavadenz
Nombre de historia: Panel de emergencias del sistema
Tipo: Backend Programador Responsable: Isaac Escobar
Descripción:
Como cuidador, necesito un panel de emergencias donde se notifiquen situaciones críticas de los residentes para
poder atenderlas de inmediato.
Criterios de aprobación:
1. Se detectan y notifican emergencias automáticamente.
2. Se visualiza en un panel separado para cuidadores.
3. Permite confirmar la atención de la emergencia.
4. Se guarda un registro de cada alerta.
72
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU20 Solicitante: Isaac Escobar
Nombre de historia: Visualización de alertas críticas en pantalla central
Tipo: Fullstack Programador Responsable: Carla Encinas
Descripción:
Como administrador del centro, quiero que las alertas críticas se muestren en una pantalla central para que el
personal pueda actuar de inmediato.
Criterios de aprobación:
1. El panel central muestra alertas en tiempo real.
2. Se distingue visualmente por tipo de alerta.
3. Las alertas se eliminan solo tras confirmación.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU21 Solicitante: Jair Vera
Nombre de historia: Registro de nuevos residentes con historial clínico
Tipo: Backend Programador Responsable: Isaac Escobar
Descripción:
Como administrador, quiero poder registrar a nuevos residentes incluyendo su historial clínico para mantener toda
la información médica en un solo lugar.
Criterios de aprobación:
1. Formulario de ingreso de datos personales y médicos.
2. El historial se vincula al perfil del residente.
3. Validación de campos requeridos.
73
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU22 Solicitante: Isaac Escobar
Nombre de historia: Visualización del historial clínico por parte del cuidador
Tipo: Frontend Programador Responsable: Jair Vera
Descripción:
Como cuidador, quiero poder ver el historial clínico de los residentes para tomar decisiones informadas sobre su
cuidado.
Criterios de aprobación:
1. Interfaz clara con información médica relevante.
2. Acceso limitado según permisos.
3. Filtrado por tipo de consulta o fecha.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU23 Solicitante: Carla Encinas
Nombre de historia: Generación de reportes generales del sistema
Tipo: Backend Programador Responsable: Jesus Lavadenz
Descripción:
Como Superadmin, quiero generar reportes generales del sistema para tener una visión global de la actividad,
usuarios y funcionamiento.
Criterios de aprobación:
1. Reportes personalizables por periodo y categoría.
2. Exportación en PDF y Excel.
3. Incluye métricas clave como cantidad de citas, emergencias, usuarios activos, etc.
74
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU24 Solicitante: Carla Encinas
Nombre de historia: Validación de todos los formularios del sistema
Tipo: Fullstack Programador Responsable: Isaac Escobar
Descripción:
Como desarrollador, necesito validar todos los formularios del sistema para asegurar que los datos ingresados sean
correctos y evitar errores.
Criterios de aprobación:
1. Validación de campos obligatorios y formatos.
2. Mensajes de error amigables.
3. Validación tanto del lado del cliente como del servidor.
Historia de Usuario
Sistema de Evaluación del Desempeño
Número: HU25 Solicitante: Isaac Escobar
Nombre de historia: Planificación y armado del circuito medidor
Tipo: Hardware Programador Responsable: Carla Encinas
Descripción:
Como ingeniero responsable, necesito planificar y ensamblar el circuito medidor que estará vinculada al sistema para
detectar emergencias y enviar alertas.
Criterios de aprobación:
1. El circuito detecta cambios en signos vitales.
2. Se vincula al sistema vía Bluetooth o Wi-Fi.
3. Envía alertas automáticas al sistema en caso de emergencia.
4. Se prueba su integración con el panel de emergencias.
75
ANEXO 3 - SCRUM
El equipo de desarrollo del sistema Medicuida está conformado por los siguientes
miembros, con sus respectivos roles y funciones en el marco Scrum:
Jair Fabricio Vera Pozo
Rol: Scrum Master, Redactor Técnico y Desarrollador Frontend
Funciones Principales:
• Facilita las ceremonias Scrum.
• Organiza el desarrollo y planificación del proyecto.
• Desarrolla pantallas del sistema (paneles de usuario, dashboards).
• Redacta la documentación funcional del sistema.
• Lidera las tareas del frontend visual funcional.
Encinas Cano Carla Valeria
Rol: Product Owner y Gestor de Base de Datos (MySQL) + Hardware
Funciones Principales:
• Define y prioriza el backlog del producto.
• Valida funcionalidades junto al cliente.
• Diseña y gestiona la base de datos en MySQL.
• Supervisa el desarrollo del hardware (circuito medidor con señal de emergencia).
• Coordina tareas entre backend y conectividad de hardware.
Jesus Gabriel Cruz Lavadenz
Rol: Desarrollador Backend y Especialista UX
Funciones Principales:
76
• Programa funcionalidades principales del sistema.
• Desarrolla los sistemas de login, recordatorios, notificaciones, reportes.
• Realiza diseño de mockups UX.
• Integra lógica del backend y conexión con base de datos.
Emmanuel Isaac Escobar Ríos
Rol: Desarrollador Backend y Hardware
Funciones Principales:
• Desarrolla funcionalidades del lado del servidor (roles, citas, validaciones).
• Implementa lógica de emergencia, paneles de alerta y formularios.
• Colabora en la implementación del hardware.
• Valida conexión entre sensores y sistema.
DUPLAS TÉCNICAS:
Frontend Visual:
Jair Fabricio Vera Pozo + Jesus Gabriel Cruz Lavadenz
Backend General:
Jesus Gabriel Cruz Lavadenz + Emmanuel Isaac Escobar Ríos
Hardware y Emergencias:
Encinas Cano Carla Valeria + Emmanuel Isaac Escobar Ríos
Base de Datos:
Encinas Cano Carla Valeria + Jesus Gabriel Cruz Lavadenz
77
ANEXO 4 – CALCULOS CPM Y PERT
Asignamos un código de actividad a las tareas más representativas de cada sprint para que
el diagrama no sea demasiado extenso, pero sí completo. Aquí consideramos el flujo desde la
planificación (Pre-Game) hasta la integración (último sprint).
Actividades claves (resumen de planificación):
Duración estimada
Código Actividad Predecesoras
(días)
HU00 - Diseño de mockups generales del
A 4 —
sistema
B HU01 - Diseño de la base de datos 3 A
C HU02 - Diseño del sistema de roles y jerarquías 3 B
D HU03 - Desarrollo de ventana de login 2 B, C
E HU04 - Desarrollo dashboard del Superadmin 4 D
F HU05 - Desarrollo panel de Admin 4 E
G HU06 - Panel del doctor (lista de residentes) 3 F
HU07 - Organización de citas y eventos
H 5 G
médicos
I HU08 - Generación de reportes médicos 4 H
J HU09 - Desarrollo del chatbot asistente 5 G
K HU10 - Chat entre familiares y cuidadores 5 J
L HU11 - Sistema de notificaciones generales 3 K, I
HU12 - Recordatorios automáticos de
M 3 L
medicamentos
N HU13 - Panel de emergencias 4 M
O HU14 - Visualización de alertas críticas 4 N
P HU15 - Registro de nuevos residentes 4 O
Q HU16 - Visualización del historial clínico 4 P
R HU17 - Reportes generales del sistema 3 Q
S HU18 - Validación de formularios 3 R
HU19 - Planificación y armado de la pulsera
T 5 S
inteligente
Tabla 1: Actividades claves
Fuente: Elaboración propia
78
Diagrama CPM/PERT
Este diagrama ilustra la secuencia de todas las actividades necesarias para llevar a cabo el
proyecto MEDICUIDA, desde la planificación hasta la integración del hardware (circuito
medidor). Refleja la interdependencia entre tareas, la duración estimada en días y ayuda a
identificar la ruta crítica, es decir, la secuencia de tareas que no puede retrasarse sin afectar la
entrega final del sistema.
Figura 18: Diagrama CPM/PERT
Fuente: Elaboración propia
Estructura del diagrama
• Cada nodo del diagrama representa una actividad con:
• Identificador de la actividad (Ej: A, B, C…)
• Descripción de la tarea
• Duración estimada (en días)
• Tiempos tempranos (Early Start y Early Finish)
79
• Tiempos tardíos (Late Start y Late Finish)
• Holgura (Slack)
• Ruta Crítica (sí/no)
Identificar la ruta crítica (CPM)
A→B→C→D→E→F→G→H→I→L→M→N→O→P→Q→R→S→T
Duración total = 4 + 3 + 3 + 2 + 4 + 4 + 3 + 5 + 4 + 3 + 3 + 4 + 4 + 4 + 4 + 3 + 3 + 5 = 64 días
Esta es la ruta crítica, ya que, si alguna de estas actividades se retrasa, afectará todo el proyecto.
Ejemplo de secuencia de la Ruta Crítica (sin holgura)
En Ruta
ID Descripción Duración ES EF LS LF Holgura
Crítica
Diseño de mockups generales del
A 4 0 4 0 4 0 Si
sistema
B Diseño de la base de datos 3 4 7 4 7 0 Si
C Diseño del sistema de roles y jerarquías 3 7 10 7 10 0 Si
D Desarrollo de ventana de login 2 10 12 10 12 0 Si
E Desarrollo dashboard del Superadmin 4 12 16 12 16 0 Si
F Desarrollo panel de Admin 4 16 20 16 20 0 Si
G Panel del doctor (lista de residentes) 3 20 23 20 23 0 Si
J Desarrollo del chatbot asistente 5 23 28 23 28 0 Si
K Chat entre familiares y cuidadores 5 28 33 28 33 0 Si
L Sistema de notificaciones generales 3 33 36 33 36 0 Si
Recordatorios automáticos de
M 3 36 39 36 39 0 Si
medicamentos
N Panel de emergencias 4 39 43 39 43 0 Si
O Visualización de alertas críticas 4 43 47 43 47 0 Si
P Registro de nuevos residentes 4 47 51 47 51 0 Si
Q Visualización del historial clínico 4 51 55 51 55 0 Si
R Reportes generales del sistema 3 55 58 55 58 0 Si
S Validación de formularios 3 58 61 58 61 0 Si
80
En Ruta
ID Descripción Duración ES EF LS LF Holgura
Crítica
Planificación y armado de la pulsera
T 5 61 66 61 66 0 Si
inteligente
Tabla 2: Ruta Crítica (sin holgura)
Fuente: Elaboración propia
También podría gustarte
- Sistema de Gestión de Proyectos de GradoAún no hay calificacionesSistema de Gestión de Proyectos de Grado104 páginas
- Sistema Web para Control de PacientesAún no hay calificacionesSistema Web para Control de Pacientes127 páginas
- Sistema de Gestión de Proyectos SocialesAún no hay calificacionesSistema de Gestión de Proyectos Sociales94 páginas
- Sistema Web para Gestión de LibrosAún no hay calificacionesSistema Web para Gestión de Libros13 páginas
- Sistema Web de Gestión de Libros ETITCAún no hay calificacionesSistema Web de Gestión de Libros ETITC8 páginas
- Sistema Web para Gestión de InventariosAún no hay calificacionesSistema Web para Gestión de Inventarios134 páginas
- Sistema Web para Control de LaboratorioAún no hay calificacionesSistema Web para Control de Laboratorio147 páginas
- Sistema Web para Bibliotecas UPEAAún no hay calificacionesSistema Web para Bibliotecas UPEA157 páginas
- Sistema de Control Médico y AdministrativoAún no hay calificacionesSistema de Control Médico y Administrativo166 páginas
- Sistema Web o Móvil para Organización en PiuraAún no hay calificacionesSistema Web o Móvil para Organización en Piura3 páginas
- Sistema de Información para CSSR BarinasAún no hay calificacionesSistema de Información para CSSR Barinas135 páginas
- Sistema Web de Admisión UniversitariaAún no hay calificacionesSistema Web de Admisión Universitaria113 páginas
- Sistema Web Académico y Chat OnlineAún no hay calificacionesSistema Web Académico y Chat Online165 páginas
- Sistema de Venta de Autopartes OnlineAún no hay calificacionesSistema de Venta de Autopartes Online187 páginas
- Aplicación Web para Control de InventariosAún no hay calificacionesAplicación Web para Control de Inventarios98 páginas
- Sistema Experto para Detección de CáncerAún no hay calificacionesSistema Experto para Detección de Cáncer45 páginas
- Sistema de Información para RE/MAX PerúAún no hay calificacionesSistema de Información para RE/MAX Perú86 páginas
- Sistema de Gestión para La Gran VictoriaAún no hay calificacionesSistema de Gestión para La Gran Victoria301 páginas
- Sistema Web para Seguimiento de EgresadosAún no hay calificacionesSistema Web para Seguimiento de Egresados188 páginas
- Sistema Web para Revistas CientíficasAún no hay calificacionesSistema Web para Revistas Científicas248 páginas
- Software de Gestión Hospitalaria en JavaAún no hay calificacionesSoftware de Gestión Hospitalaria en Java4 páginas
- Sistema Web para Historias ClínicasAún no hay calificacionesSistema Web para Historias Clínicas215 páginas
- Sistema Web para Gestión de CalzadoAún no hay calificacionesSistema Web para Gestión de Calzado100 páginas
- Software Web para Registros AcadémicosAún no hay calificacionesSoftware Web para Registros Académicos74 páginas
- Sistema de Control de Inventario Farmacéutico100% (1)Sistema de Control de Inventario Farmacéutico124 páginas
- Sistema Web de Contabilidad N.I.I.F.Aún no hay calificacionesSistema Web de Contabilidad N.I.I.F.284 páginas
- Sistema Web para Encuestas en CintalapaAún no hay calificacionesSistema Web para Encuestas en Cintalapa92 páginas
- Mejora Logística en Orange BusinessAún no hay calificacionesMejora Logística en Orange Business77 páginas
- Sistema Web para Fisioterapia en GuayaquilAún no hay calificacionesSistema Web para Fisioterapia en Guayaquil103 páginas
- Sistema de Control para Radio Taxi UBBERAún no hay calificacionesSistema de Control para Radio Taxi UBBER3 páginas
- App SOA para Gestión de Pacientes HipertensosAún no hay calificacionesApp SOA para Gestión de Pacientes Hipertensos83 páginas
- Proyecto de Grado en Ingeniería de Sistemas0% (1)Proyecto de Grado en Ingeniería de Sistemas3 páginas
- Aplicación Web-Móvil para La Gestión de Adopciones deAún no hay calificacionesAplicación Web-Móvil para La Gestión de Adopciones de137 páginas
- Sistema de Control de Sueldos AgrícolaAún no hay calificacionesSistema de Control de Sueldos Agrícola224 páginas
- Sistema de Seguros Autogestionado HidrobolívarAún no hay calificacionesSistema de Seguros Autogestionado Hidrobolívar116 páginas
- Sistema Web para Gestión AcadémicaAún no hay calificacionesSistema Web para Gestión Académica101 páginas
- Sistema Web para Control de MatrículasAún no hay calificacionesSistema Web para Control de Matrículas105 páginas
- Base de Datos para Ingeniería en TelecomunicacionesAún no hay calificacionesBase de Datos para Ingeniería en Telecomunicaciones105 páginas
- Arquitectura de Software para WebAún no hay calificacionesArquitectura de Software para Web150 páginas
- Sistema Web para Taller UTP en PerúAún no hay calificacionesSistema Web para Taller UTP en Perú96 páginas
- Sistema de Información para Proyectos EducativosAún no hay calificacionesSistema de Información para Proyectos Educativos6 páginas
- Solución Web para Emergencias ObstétricasAún no hay calificacionesSolución Web para Emergencias Obstétricas243 páginas
- Aplicación Híbrida para Gestión de - OptAún no hay calificacionesAplicación Híbrida para Gestión de - Opt110 páginas
- Sistema Web para Control de EquiposAún no hay calificacionesSistema Web para Control de Equipos113 páginas
- Sistema Web para Nivelación AcadémicaAún no hay calificacionesSistema Web para Nivelación Académica82 páginas
- Automatización y Control IndustrialAún no hay calificacionesAutomatización y Control Industrial3 páginas
- Evolución de la Interacción Hombre-MáquinaAún no hay calificacionesEvolución de la Interacción Hombre-Máquina6 páginas
- Malla Curricular Técnico en ProgramaciónAún no hay calificacionesMalla Curricular Técnico en Programación2 páginas
- Vulnerabilidad de Configuración de SeguridadAún no hay calificacionesVulnerabilidad de Configuración de Seguridad13 páginas
- Ventajas y Desventajas de Ensamblador vs CAún no hay calificacionesVentajas y Desventajas de Ensamblador vs C5 páginas
- Actividades de Windows y Hardware BásicoAún no hay calificacionesActividades de Windows y Hardware Básico3 páginas
- Examen de Certificación Analista SOC EC-CouncilAún no hay calificacionesExamen de Certificación Analista SOC EC-Council28 páginas
- Microsoft Word: Historia y FormatosAún no hay calificacionesMicrosoft Word: Historia y Formatos14 páginas
- Digitalización de libros de dominio públicoAún no hay calificacionesDigitalización de libros de dominio público603 páginas
- Instala una Máquina Virtual con VirtualBoxAún no hay calificacionesInstala una Máquina Virtual con VirtualBox14 páginas
- Guía Completa de Windows Server 2019Aún no hay calificacionesGuía Completa de Windows Server 201941 páginas
- Herramientas y Procesos ETL EsencialesAún no hay calificacionesHerramientas y Procesos ETL Esenciales6 páginas
- Lista de Cotejo para Evaluar Entornos VirtualesAún no hay calificacionesLista de Cotejo para Evaluar Entornos Virtuales3 páginas
- Práctica de Servidor FTP en TelemáticaAún no hay calificacionesPráctica de Servidor FTP en Telemática13 páginas
- Ejercicios de Comandos Linux y PermisosAún no hay calificacionesEjercicios de Comandos Linux y Permisos2 páginas
- Curso de Diseño Estructural Metálico CYPE 3DAún no hay calificacionesCurso de Diseño Estructural Metálico CYPE 3D5 páginas
- Instalación ICG FrontRetail paso a pasoAún no hay calificacionesInstalación ICG FrontRetail paso a paso17 páginas
- Auxiliar de Diseño Gráfico: Funciones y RequisitosAún no hay calificacionesAuxiliar de Diseño Gráfico: Funciones y Requisitos3 páginas
- Movilidad para Actividades del SAFAún no hay calificacionesMovilidad para Actividades del SAF16 páginas