NOMBRE DEL PROYECTO]

[Logo del Software]

[NOMBRE DEL PROYECTO]

[NOMBRE DE LA APP (SW)]

Integrantes

Plan de Desarrollo Software

Orientado por:

[Fecha]

Politécnico Gran Colombiano

Medellín

[INFORMACIÓN DE CONTACTO Y SITIO WEB]

Cronograma del Proyecto............................................................................................4

Recursos asignados......................................................................................................4

Roles............................................................................................................................5

1. Planeación, estimación y seguimiento...................................................................6

1.1. Planeación..........................................................................................................6

1.2. Estimación.........................................................................................................6

1.3. Seguimiento.......................................................................................................6

1.4. Propósito............................................................................................................6

1.5. Planteamiento del problema..............................................................................8

1.6. Alcance del producto / Software.......................................................................9

1.5. Objetivos del Proyecto....................................................................................10

1.5.1. Objetivo General.................................................................................10

1.5.2. Objetivos Específicos..........................................................................10

2. Metodología de desarrollo ágil.............................................................................11

2. Análisis.................................................................................................................12

2.1. Requisitos del sistema.....................................................................................12

2.5.1. Requisitos Funcionales........................................................................12

2.5.2. Requisitos No funcionales...................................................................12

[INFORMACIÓN DE CONTACTO Y SITIO WEB]

2.2. Historias de Usuarios.......................................................................................12

3. Diseño..................................................................................................................13

3.1. Modelo de Datos (Entidad – Relación)...........................................................13

3.2. Diagrama de Casos de Uso..............................................................................14

3.3. Diagrama de Actividad....................................................................................14

4. Implementación....................................................................................................15

4.1. Lenguajes de programación utilizados............................................................15

5. Diseño y de arquitectura de software...................................................................16

6. Gestión de calidad, testing y documentación.......................................................17

6.1. Estrategia de pruebas.......................................................................................17

3.5.1. Casos de prueba...................................................................................17

3.5.2. Resultados de las pruebas....................................................................17

7. Mantenimiento y Actualizaciones........................................................................19

7.1. Planes para futuras actualizaciones.................................................................19

8. Manual de Usuario...............................................................................................20

9. Manual de Técnico...............................................................................................21

10. Código Fuente......................................................................................................22

11. Glosario................................................................................................................23

Página 3
Página 4
GESTIÓN DEL PROYECTO DE SOFTWARE

Página 5
Cronograma del Proyecto

El desarrollo de HabitaBot se planificó en varias etapas secuenciales para garantizar un

progreso ordenado. Primeramente, se realizó la fase de planeación, en la cual se

definieron los objetivos, el alcance y los recursos necesarios del proyecto. Luego se

llevó a cabo el levantamiento de requisitos, mediante entrevistas con administradores y

residentes de conjuntos residenciales para entender las funcionalidades deseadas. Con

esa información, se procedió al diseño de la solución, imaginando la interfaz del sistema

y la arquitectura interna. Posteriormente, se inició la implementación y desarrollo del

prototipo funcional, integrando las características principales. Alcanzado un producto

preliminar, se realizaron pruebas con usuarios reales para verificar el funcionamiento y

recoger retroalimentación, introduciendo ajustes según los hallazgos. Finalmente, se

completó la implantación del sistema, integrando todos los módulos desarrollados,

preparando la documentación final y desplegando el producto listo para uso en un

entorno real. Este cronograma permitió visualizar las actividades en el tiempo,

monitorear el progreso y anticipar desafíos, asegurando la entrega puntual de un

producto de alta calidad. Cada fase incluyó hitos y períodos de revisión para adaptarse a

cambios imprevistos en requisitos o tiempos. En resumen, el cronograma sirvió como

hoja de ruta temporal clara del proyecto, facilitando un seguimiento efectivo del avance

y el cumplimiento de los plazos establecidos.

Recursos asignados.

Página 6
El proyecto contó con recursos humanos y técnicos cuidadosamente distribuidos. En

cuanto al equipo de desarrollo, estuvo conformado por tres integrantes, quienes

asumieron roles complementarios: un analista de requerimientos, un

diseñador/desarrollador de software y un encargado de pruebas y documentación.

Adicionalmente, se contó con la guía de un docente orientador que actuó como líder de

proyecto, apoyando en decisiones estratégicas y asegurando el uso correcto de la

metodología. Esta estructura colaborativa garantizó que las tareas de planeación, diseño,

programación y pruebas fuesen cubiertas de manera eficiente por miembros con las

competencias adecuadas.

En cuanto a recursos materiales, se emplearon computadores personales con conexión a

internet y diversas herramientas de desarrollo. Se utilizó el entorno de programación

Visual Studio Code para codificar el frontend web, una base de datos MySQL para

gestionar la información, y sistemas de control de versiones como GitHub para la

colaboración en el código. Para el diseño de la interfaz gráfica y diagramas UML se

hicieron uso de aplicaciones especializadas. También se apoyó la gestión del proyecto

con herramientas en la nube: por ejemplo, Trello para la organización de tareas y

Google Drive para almacenar y compartir documentos del proyecto. Estos recursos

proporcionaron la infraestructura necesaria para llevar a cabo el desarrollo de

HabitaBot, asegurando que el equipo contara con la tecnología y los entornos adecuados

para cumplir los objetivos en el cronograma establecido.

Roles

En la ejecución de HabitaBot se definieron claramente los roles y responsabilidades de

cada participante, lo cual es fundamental para una colaboración organizada y eficaz. Los

roles establecidos fueron:

Página 7
 Líder de Proyecto: desempeñado por la docente orientadora, encargada de

coordinar al equipo, tomar decisiones estratégicas y dar seguimiento al

cumplimiento de objetivos y plazos. Este rol aseguró la visión global del

proyecto y el apego a la planeación.

 Analista de Requerimientos: responsable de levantar, documentar y validar las

necesidades de los usuarios (administradores y residentes). Este miembro tradujo

las peticiones de los stakeholders en requisitos claros y priorizados para el

sistema.

 Diseñador de Software: encargado de proponer la arquitectura del sistema y

elaborar los modelos de diseño (diagramas UML) que sirvieron de base al

desarrollo. También participó en el diseño de la interfaz de usuario para asegurar

una experiencia consistente.

 Desarrollador: rol compartido por varios integrantes, enfocado en implementar

las funcionalidades del sistema escribiendo el código HTML, CSS, JavaScript y

la lógica del chatbot. Siguieron los lineamientos de diseño y se aseguraron de

cumplir con los requisitos funcionales establecidos.

 Tester / Encargado de Pruebas: responsable de planificar y ejecutar las pruebas

de software, encontrando e informando errores, y verificando que el sistema

cumpliera con los criterios de calidad. Este rol garantizó la confiabilidad y

correcto funcionamiento de HabitaBot antes de su entrega.

 Usuario/Cliente (Administradores y Residentes): aunque externos al equipo de

desarrollo, estos actores cumplieron un rol esencial proporcionando información

inicial, participando en pruebas piloto y retroalimentando el producto. Sus

interacciones validaron que el sistema realmente solucionara sus necesidades.

Página 8
La definición explícita de estos roles permitió distribuir las tareas de forma equilibrada,

mejorar la comunicación interna y cubrir cada fase del proyecto con el experto

adecuado. Como señalan las buenas prácticas, contar con roles bien asignados mejora la

colaboración y asegura que las diversas disciplinas del proyecto (gestión, análisis,

desarrollo, pruebas) estén integradas hacia un objetivo común de éxito.

Página 9
 1. Planeación, estimación y seguimiento

En un proyecto de software, planeación, estimación y seguimiento son actividades

fundamentales que orientan y controlan todo el proceso de desarrollo. Durante la

planeación inicial de HabitaBot, el equipo definió los objetivos del proyecto, delimitó el

alcance funcional, organizó las tareas por fases y asignó responsables y tiempos a cada

actividad. Seguidamente, se realizó una estimación del esfuerzo, tiempo y costos

requeridos para cada etapa, utilizando métodos sencillos acordes al contexto académico.

Finalmente, se estableció un mecanismo de seguimiento periódico para monitorear el

avance y asegurar que el proyecto se mantuviera en ruta. A continuación se detallan estos

aspectos:

Página 10
1.1. Planeación

La planeación abarcó la definición de qué se va a construir y cómo se abordará su

desarrollo. Se inició identificando las necesidades específicas en la administración de

conjuntos residenciales (ver apartado 1.5), para luego derivar la solución propuesta. Se

establecieron objetivos claros alineados con esas necesidades (ver apartado 1.7), y se

determinó el alcance del software, delimitando las funciones que incluiría la versión

inicial de HabitaBot. Asimismo, se identificaron las tareas principales del proyecto:

análisis de requisitos, diseño del chatbot y la base de datos, codificación de la interfaz y

lógica, pruebas unitarias y con usuarios, preparación de manuales, etc. Cada tarea fue

calendarizada en el cronograma, asignando responsables y estimando una duración.

También en esta fase se asignaron los recursos humanos y tecnológicos (ver Recursos

asignados) y se definió la metodología de trabajo (ver sección 2). En síntesis, la

planeación sirvió para organizar el trabajo y guiar al equipo hacia un resultado concreto

y alcanzable dentro del tiempo y recursos disponibles.

1.2. Estimación

Página 11
En esta actividad se calcularon las magnitudes de tiempo y esfuerzo necesarias para

completar el proyecto. Se descompusieron las tareas identificadas y se estimó la

duración de cada una considerando la experiencia del equipo. Por ejemplo, se proyectó

dedicar aproximadamente un 15-20% del tiempo total (una semana) a la planeación y

configuración inicial, alrededor de 4 semanas al desarrollo e implementación del

prototipo, y cerca de 1 semana adicional a pruebas y ajustes finales. Dado que cada

integrante disponía de unas 8 horas semanales para el proyecto, la suma de esfuerzo

estimado fue de ~144 horas hombre en total para el equipo (3 integrantes por 48 horas

cada uno). En cuanto a costos, al tratarse de un proyecto académico no hubo costos

monetarios significativos: se aprovechó software libre y recursos existentes de la

institución, contemplando únicamente posibles gastos menores (por ejemplo, impresión

de documentos). La estimación también incluyó recursos de hardware y software

requeridos (uso de servicios en la nube, licencias educativas, etc.). Estas

aproximaciones, aunque básicas, permitieron al equipo tener una noción de la carga de

trabajo y anticipar la necesidad de priorizar funciones esenciales.

1.3. Seguimiento

Para garantizar que el proyecto avanzara conforme a lo planificado, se implementó un

seguimiento continuo. Semanalmente, el equipo realizaba reuniones de control para

revisar el progreso de cada tarea frente al cronograma. Se utilizó una tabla Kanban en

Trello donde se actualizaban el estado de las tareas (Pendiente, En proceso, Hecho),

identificando retrasos o bloqueos a tiempo. Cuando se detectaba alguna desviación

significativa (por ejemplo, una funcionalidad tomando más tiempo del previsto), se

analizaban las causas y se tomaban decisiones de ajuste: reasignar tareas, simplificar

Página 12
 algún requerimiento opcional, o dedicar horas adicionales. Este seguimiento activo

permitió mantener el proyecto encaminado y reaccionar ágilmente ante problemas,

alineándose con los principios de mejora continua de las metodologías ágiles.

Adicionalmente, el docente líder verificaba el cumplimiento de hitos académicos

(entrega de informes parciales, presentaciones), asegurando que el proyecto cumpliera

con los criterios establecidos. Gracias a este monitoreo, HabitaBot se completó dentro

del plazo y alcance previstos, con la flexibilidad necesaria para absorber cambios

menores sin comprometer la entrega final.

1.4. Propósito

El propósito fundamental de HabitaBot fue desarrollar un software que atendiera una

necesidad real en la administración de conjuntos residenciales, optimizando procesos de

comunicación y registro de incidencias. Actualmente, muchas administradoras manejan

reportes de daños, solicitudes de los residentes y anuncios a través de medios poco

eficientes (llamadas, papel, mensajería dispersa), lo que genera demoras y errores.

HabitaBot se concibió como una solución para facilitar la organización de la información y

agilizar estos procesos cotidianos. Con este desarrollo, se buscó brindar beneficios

tangibles a sus usuarios: que un residente pueda reportar rápidamente una falla de

mantenimiento y obtener seguimiento, o consultar información de apartamentos en venta; y

que los administradores reciban estas notificaciones de forma estructurada para atenderlas

prontamente. En términos generales, el propósito guía del proyecto fue mejorar la

eficiencia, reducir errores y brindar una experiencia más ágil en la gestión comunitaria

mediante un asistente virtual intuitivo. Este propósito sirvió como norte durante todas las

Página 13
etapas de trabajo, asegurando que cada decisión de diseño o funcionalidad contribuyera al

objetivo de solucionar los problemas identificados en el contexto.

Página 14
 1.5. Planteamiento del problema

Previo al desarrollo, se identificó el problema central: en la administración de un conjunto

residencial, la comunicación entre residentes y administradores y el registro de incidencias

no estaban siendo eficientes. Las quejas o reportes de daños (por ejemplo, una luz pública

dañada, una fuga de agua, etc.) usualmente se realizaban de forma informal –vía telefónica,

en persona o por chats genéricos– lo que deriva en demoras, falta de seguimiento y posible

pérdida de información. Esta situación afecta la calidad del servicio al residente y

sobrecarga al administrador con un manejo poco organizado de las solicitudes.

Adicionalmente, se observó poca accesibilidad a información relevante: los residentes no

tenían un medio fácil para consultar el estado de sus reportes, ni para enterarse de

oportunidades (como apartamentos disponibles en la comunidad). Esta problemática

genera duplicidad de esfuerzos, insatisfacción de los residentes y opacidad en la gestión.

Por ello, se planteó la necesidad de un software que centralizara estas interacciones de

forma amigable. La idea fue atacar las deficiencias actuales proporcionando un sistema

confiable y ordenado donde: (1) los residentes puedan reportar fallas y hacer preguntas a

cualquier hora, recibiendo confirmaciones; (2) los administradores tengan un registro

estructurado de todos los reportes y solicitudes; y (3) la comunicación en general se agilice

mediante un asistente virtual disponible para todos. Solventar este problema mejoraría la

productividad del personal administrativo y elevaría la satisfacción de la comunidad

residente.

Página 15
1.6. Alcance del producto / Software

El alcance definido para HabitaBot corresponde a las funcionalidades esenciales para

resolver el problema planteado, sin incurrir en características fuera del propósito del

proyecto. Dentro del alcance se incluyeron los siguientes módulos y características

principales:

 Chatbot Interactivo: Interfaz conversacional accesible vía web, donde el

residente puede escribir mensajes. El bot es capaz de saludar, guiar al usuario

por menús de opciones y entender comandos básicos relacionados con reportes o

información general. Incluye un botón para activar/desactivar respuesta por voz,

mejorando la accesibilidad.

 Registro de Reportes de Falla: Funcionalidad central que permite al residente

reportar una incidencia en la propiedad (daños en zonas comunes, problemas de

servicios, seguridad, etc.). El bot recopila la categoría de la falla, detalles

adicionales, la ubicación (apartamento y bloque) y finalmente confirma el

registro. El reporte queda almacenado en el sistema con estado "Pendiente".

 Consulta de Estado de Reportes: Opción para que el residente solicite al bot el

estado actual de los reportes previamente realizados. El bot muestra una lista de

las fallas registradas junto con un estado indicativo (por ejemplo: En revisión,

Resuelto, etc.). Estos estados son determinados por el administrador o

automáticamente simulados por el sistema para efectos de la interacción.

 Búsqueda de Apartamentos: El asistente ofrece información sobre apartamentos

en venta o arriendo dentro del conjunto residencial (como valor agregado para

los residentes). El usuario puede elegir entre ver opciones de venta o alquiler, y

Página 16
 el bot genera una lista simulada de unidades disponibles con sus características

(número de habitaciones, área, precio) y facilita un contacto si se desea más

información.

 Gestión de Usuarios y Unidades: En la plataforma se contempló registrar a cada

residente con sus datos (nombre, apartamento, etc.) y, en su caso, permitir un

perfil de Administrador con privilegios. El administrador puede acceder a un

panel (no implementado en el prototipo de chatbot pero previsto en la

arquitectura) para gestionar la información de residentes, unidades

habitacionales y revisar todos los reportes recibidos.

 Almacenamiento Local/Remoto de Datos: El prototipo almacena los reportes de

forma local en el navegador (usando LocalStorage), mientras que en una versión

completa se integraría una base de datos remota donde persistan usuarios

registrados, reportes, histórico de acciones y demás entidades (ver Modelo de

Datos en sección 3.1). Esto asegura que la información clave (reportes, usuarios)

esté disponible para consulta y seguimiento.

Quedan fuera del alcance características avanzadas o complementarias como:

autenticación robusta de usuarios (en el prototipo el chatbot asume un usuario

predefinido "Daniel"), envío de notificaciones automáticas por email/SMS, integración

con sistemas de ticketing externos, procesamiento de lenguaje natural avanzado (el

chatbot sigue flujos predefinidos, no comprende texto libre complejo), y aplicaciones

móviles nativas. Estas funcionalidades se consideran para futuras fases (ver sección 7.1)

pero no fueron incluidas en la versión actual debido a las limitaciones de tiempo y

recursos.

Página 17
Página 18
1.5. Objetivos del Proyecto

1.5.1. Objetivo General

Desarrollar e implementar un asistente virtual conversacional (Chatbot) denominado

HabitaBot para la gestión de servicios en conjuntos residenciales, que permita a los

residentes reportar incidencias de mantenimiento y obtener información de manera ágil,

y a los administradores atender y registrar dichas solicitudes eficientemente. El asistente

debe mejorar la comunicación residente-administración, centralizando los reportes y

consultas en una plataforma única, fácil de usar y accesible en todo momento.

1.5.2. Objetivos Específicos

 Automatizar el registro de fallas: Diseñar la funcionalidad para que los

residentes puedan reportar problemas (daños, quejas, solicitudes) mediante

diálogo con el chatbot, estructurando la información (categoría de falla,

ubicación, descripción) en un reporte digital almacenado en la base de datos del

sistema.

 Facilitar el seguimiento de solicitudes: Implementar una opción de consulta

donde el usuario reciba del bot el estado actualizado de sus reportes,

aumentando la transparencia y reduciendo la necesidad de seguimiento manual

por parte de la administración.

 Brindar información útil vía chatbot: Incorporar al asistente módulos

informativos, como un catálogo de apartamentos en venta o arriendo dentro del

conjunto, con detalles de contacto. Esto agrega valor al residente y aprovecha la

plataforma para múltiples propósitos de comunicación.

Página 19
 Soportar interacción por voz: Integrar una característica opcional de síntesis de

voz, de modo que el bot pueda leer sus respuestas en español. Este objetivo

mejora la accesibilidad para usuarios con discapacidad visual o que prefieren oír

la respuesta, siguiendo la tendencia de interfaces conversacionales más

humanas.

 Desarrollar una arquitectura escalable: Definir e implementar una arquitectura

de software compuesta por un frontend web (interfaz del chatbot) y un backend

(servidor y base de datos) que permita escalar la solución. Aunque el prototipo

utiliza almacenamiento local, la arquitectura debe prever la conexión a una base

de datos central para uso real en producción.

 Garantizar facilidad de uso y adopción: Asegurar que la interfaz conversacional

sea intuitiva, con flujos de conversación claros y mensajes en lenguaje natural

comprensible. El objetivo es que incluso usuarios sin conocimientos técnicos

puedan utilizar HabitaBot sin dificultades, incrementando la adopción de la

herramienta en la comunidad.

Cada objetivo específico anterior se trazó para apoyar el logro del objetivo general y

resolver aspectos particulares del problema. El cumplimiento de estos objetivos fue

verificado mediante pruebas y validaciones con usuarios, confirmando que

HabitaBot efectivamente agiliza la gestión residencial y mejora la experiencia de los

residentes en sus interacciones con la administración.

Página 20
 2. Metodología de desarrollo ágil.

Para llevar a cabo el proyecto se optó por una metodología de desarrollo ágil,

específicamente inspirada en el marco Scrum. Las metodologías ágiles se caracterizan

por su enfoque iterativo e incremental, con entregas frecuentes y retroalimentación

continua, lo cual calzaba perfectamente con las necesidades del proyecto

acadé[Link]. En efecto, en la

industria del software, Scrum es preferido por un gran porcentaje de equipos gracias a

su flexibilidad y orientación a la satisfacción del [Link]. Por

lo tanto, el equipo adoptó prácticas de Scrum adaptadas a la escala del proyecto:

 Se definió un Product Backlog con las funcionalidades deseadas (historias de

usuario del apartado 3.2) priorizadas según su importancia.

 El desarrollo se organizó en iteraciones cortas (sprints) de aproximadamente 1

semana cada una, al final de las cuales se obtenían incrementos o módulos

funcionales (por ejemplo, un sprint para la interfaz del chatbot, otro para el

almacenamiento de reportes, etc.).

 Cada comienzo de iteración se realizó una breve planificación determinando qué

ítems del backlog se abordarían en ese sprint, estimando el esfuerzo en horas

para cada tarea.

 Se llevaron a cabo reuniones de seguimiento semanales (daily stand-ups

adaptados a un ritmo académico) en las que cada miembro reportaba su progreso

y obstáculos. Esto facilitó la comunicación y detección temprana de

impedimentos.

 Al término de cada sprint, se realizaba una revisión del incremento desarrollado.

Por ejemplo, se demostró el chatbot registrando un reporte básico al concluir el

Página 21
 primer sprint. La retroalimentación de los docentes y compañeros sirvió para

ajustar requisitos o mejorar aspectos de la interfaz.

 Asimismo, el equipo conducía retrospectivas informales para identificar qué

estaba funcionando bien en el proceso y qué se podía mejorar en el siguiente

ciclo, fomentando la mejora continua.

 Se mantuvieron principios ágiles como la colaboración con el cliente/usuario

(incluyendo a un representante de los residentes para probar el sistema y dar

opiniones), la entrega temprana de valor (priorizando primero las

funcionalidades clave de reporte de fallas), y la adaptación al cambio (se

ajustaron algunas historias de usuario a mitad del proyecto sin perjuicio, gracias

al enfoque iterativo).

Cabe destacar que este enfoque ágil permitió mantener un fuerte enfoque en el usuario

durante todo el desarrollo. Los requerimientos se discutieron en lenguaje natural y se

refinaron continuamente con ayuda del docente, lo que evitó malentendidos y produjo

un software más alineado con las expectativas. Según Medina Velandia & Gutiérrez

(2024), el uso de metodologías ágiles combinando Scrum con tableros Kanban es una

práctica común y efectiva en organizaciones de [Link]. En

nuestro caso, efectivamente se utilizó un tablero Kanban para visualizar el estado de las

tareas en todo momento, complementando el esquema Scrum.

En resumen, la metodología ágil brindó flexibilidad al proyecto HabitaBot, permitiendo

entregar resultados funcionales tempranos y mejorarlos iterativamente. Gracias a ello, el

equipo pudo reaccionar rápidamente ante cambios (como refinar la interacción del

chatbot según pruebas iniciales) y lograr un producto de calidad en el tiempo

establecido, lo cual refleja los valores fundamentales del Manifiesto Ágil: individuos e

Página 22
interacción sobre procesos, software funcionando sobre documentación extensiva,

colaboración con el cliente y respuesta ante el cambio.

2. Análisis

2.1. Requisitos del sistema

Los requisitos del sistema HabitaBot se clasificaron en funcionales, no funcionales y

reglas de negocio, asegurando cubrir tanto las funcionalidades esperadas como las

restricciones de calidad y políticas operativas.

2.5.1. Requisitos Funcionales

Son las funcionalidades o servicios que el software debe proveer al usuario. A

continuación se listan los requisitos funcionales principales de HabitaBot:

 RF1. Registro de usuarios: El sistema deberá permitir registrar nuevos residentes

con sus datos personales y vincularlos a una unidad residencial específica

(apartamento). Esto para otorgar acceso a las funcionalidades personalizadas.

(En el prototipo, por simplicidad, este registro se asumió fijo para un usuario

predefinido.)

 RF2. Autenticación: El sistema debe validar las credenciales de los usuarios

(residente o administrador) para iniciar sesión y cargar su panel correspondiente.

Administradores tendrán privilegios especiales. (En la implementación final se

contemplaría un login; en el prototipo no se implementó interfaz de login,

asumiendo el chatbot directamente disponible para un usuario activo.)

 RF3. Reporte de falla: El chatbot permitirá que un residente registre un reporte

de incidencia. Debe guiar al usuario para ingresar la categoría del problema (p.

ej., seguridad, agua, electricidad, etc.), una descripción o detalle del fallo, y la

Página 23
 ubicación (apartamento y bloque). Al finalizar, el sistema almacenará el reporte

con un identificador único, fecha de registro y estado inicial "Pendiente".

 RF4. Confirmación de registro: Tras el ingreso de un reporte, el sistema enviará

una confirmación al usuario (mediante mensaje del bot) indicando que la falla ha

sido registrada exitosamente. Se debe proveer un resumen de la información

capturada para verificación (como lo implementado en la conversación del

chatbot).

 RF5. Consulta de estado de reportes: El residente podrá solicitar al bot ver el

estado de sus reportes previos. El sistema listará cada reporte con su descripción

breve y el estado actual (Pendiente, En revisión, Resuelto). Esto implica que el

sistema debe almacenar y poder filtrar los reportes por usuario y actualizar sus

estados (sea manualmente por un admin o automáticamente para la

demostración).

 RF6. Búsqueda de información de apartamentos: El usuario podrá consultar a

HabitaBot por apartamentos en venta o en arriendo dentro del conjunto. El

sistema generará una lista de al menos 3 opciones ficticias con detalles (nombre

del edificio o unidad, número de habitaciones/área, precio estimado) y brindará

la opción de "Pedir información de contacto" para un apartamento específico. Al

elegir esa opción, el bot proveerá un correo electrónico y teléfono de contacto

simulados del vendedor/administrador encargados.

 RF7. Activación/Desactivación de voz: El chatbot ofrecerá un botón para activar

o desactivar la voz (text-to-speech). Cuando esté activada, todas las respuestas

del bot se leerán en voz alta en español. Cuando esté desactivada (valor por

defecto), el bot solo mostrará texto. Este requisito busca mejorar la usabilidad

para distintos usuarios.

Página 24
 RF8. Guardado y descarga de reportes: El sistema permitirá que el usuario

descargue un archivo de texto con el historial de reportes realizados. En el

prototipo, se implementó un botón "📂 Descargar reportes" que genera un archivo

.txt con la información de todos sus reportes almacenados (fecha, categoría,

descripción, etc.). Asimismo, la acción de "💾 Guardar reporte" tras registrar una

falla debe almacenar persistentemente el reporte en la base de datos (o

localStorage en su defecto). Este requisito facilita respaldos y transiciones al

administrador.

 RF9. Gestión de usuarios y roles (administrador): El sistema deberá contar con

una interfaz de administración (accesible solo para usuarios con rol

Administrador) donde sea posible gestionar los datos de usuarios residentes:

crear nuevos usuarios, asignarles o cambiar su unidad residencial, editar

información de contacto, o desactivar cuentas. Igualmente, el administrador

podría registrar manualmente incidencias o responder a ciertas consultas

frecuentes a través del sistema. (Este requisito se consideró en diseño aunque su

interfaz no fue desarrollada en el prototipo de chatbot.)

 RF10. Gestión de reportes (administrador): Desde el rol administrador, el

sistema debe permitir visualizar todos los reportes ingresados por los residentes,

filtrarlos por estado o categoría, y actualizar su estado (por ejemplo, marcar un

reporte como "Resuelto" una vez atendido). También puede agregar notas o un

historial de acciones asociadas a cada reporte. Esto garantiza el ciclo completo

de atención de un incidente.

Página 25
2.5.2. Requisitos No funcionales

Son las características de calidad que el sistema debe cumplir, relacionadas con su

operación y entorno. Para HabitaBot se identificaron los siguientes requisitos no

funcionales más relevantes:

 RNF1. Usabilidad: El chatbot debe ser intuitivo y fácil de usar para personas de

diversas edades, con una interfaz limpia. Los mensajes del bot se redactaron en

lenguaje claro y amable, evitando jerga técnica. Se incluyeron botones de opción

para la mayoría de interacciones (en lugar de exigir al usuario recordar

comandos), mejorando la experiencia de uso. Asimismo, los colores y diseño de

la ventana de chat son agradables a la vista, y el botón de voz es visible e

interpretativo (🔊/🔇).

 RNF2. Disponibilidad: El sistema web debe estar disponible 24/7, dado que los

residentes pueden necesitar reportar problemas en cualquier momento. Esto

implica que el servidor (en una versión desplegada) tenga alta disponibilidad. En

entorno local de pruebas, el sistema estuvo disponible siempre que el usuario

accediera a la página web del chatbot.

 RNF3. Rendimiento: La aplicación debe responder a las interacciones del

usuario en tiempo real o casi inmediato. En las pruebas se verificó que el bot

muestra las opciones o respuestas en menos de 1 segundo tras la entrada del

usuario, brindando una sensación de conversación fluida. Las operaciones de

guardado y carga de reportes también se ejecutan eficientemente gracias a su

sencillez (estructura en JSON de tamaño pequeño).

 RNF4. Compatibilidad y Portabilidad: El frontend de HabitaBot (HTML, CSS,

JS) es compatible con los navegadores web modernos (Chrome, Firefox, Edge) y

adaptable a diferentes tamaños de pantalla (diseño responsive básico dentro de la

Página 26
 ventana del chat). Esto permite que los residentes puedan acceder al bot tanto

desde un computador de escritorio como desde dispositivos móviles vía

navegador, sin requerir instalación de apps adicionales.

 RNF5. Seguridad: Si bien es un prototipo, se consideró la seguridad de la

información. En una versión completa, las comunicaciones entre el cliente y

servidor estarían cifradas bajo HTTPS, protegiendo datos sensibles como

contraseñas. Además, las contraseñas de usuarios deben almacenarse cifradas en

la base de datos (por ejemplo, aplicando hash + salt). El sistema debe validar

entradas del usuario para evitar inyecciones (en el chatbot, las entradas se

sanitizan ya que se ignoran etiquetas HTML potenciales en los mensajes, ver

código en sección 10). También se limitaría el acceso a funciones de

administrador mediante autenticación robusta.

 RNF6. Mantenibilidad y Escalabilidad: La arquitectura modular de HabitaBot

(separando la lógica del chatbot, la lógica de negocio del servidor y la base de

datos) está pensada para facilitar futuras modificaciones. El código fuente sigue

estándares de organización y nombrado que mejoran su legibilidad y

mantenimiento. Además, el sistema debe ser escalable: poder agregar más

categorías de reporte o más usuarios sin degradar su desempeño. La decisión de

usar tecnologías web estándar contribuye a esta escalabilidad horizontal (se

puede desplegar en la nube y atender múltiples conjuntos residenciales

independientemente).

 RNF7. Documentación: El proyecto incluye documentación completa (manual

de usuario, técnico, y la presente documentación del proyecto) para asegurar que

terceros puedan entender y operar el sistema. Bajo normas APA se

documentaron las fuentes de consulta, y se generaron diagramas UML

Página 27
 actualizados. Este aspecto facilita la transferencia de conocimiento y la

continuidad del proyecto por nuevos desarrolladores.

2.5.3. Regla de Negocio

Las reglas de negocio son políticas o restricciones propias del dominio que el sistema

debe respetar. En el contexto de administración de conjuntos residenciales y el uso de

HabitaBot, se establecieron las siguientes reglas de negocio relevantes:

 RB1. Asociación usuario-unidad: Cada residente debe estar asociado a una única

unidad residencial (apartamento) como su lugar de vivienda principal. Un

usuario residente no puede reportar fallas si no tiene una unidad asignada en el

sistema. Si un residente se muda a otra unidad, un administrador deberá

actualizar esa asociación en el sistema (regla administrada en Gestión de

usuarios).

 RB2. Roles y permisos: Se definen dos roles principales de usuario – Residente

y Administrador. Un usuario solo puede tener un rol a la vez. Los residentes

pueden únicamente acceder a funciones de usuario final (ej. reportar fallas,

consultar información), mientras que los administradores poseen permisos para

ver y modificar datos globales (usuarios, unidades, todos los reportes). Por

diseño, las interfaces sensibles (como la de administración) estarán protegidas

para que solo usuarios con rol administrador ingresen.

 RB3. Estados de los reportes: Todo reporte de falla seguirá un ciclo de vida con

estados definidos: Pendiente, En revisión, Resuelto. Inicialmente, al registrarse

un reporte su estado es Pendiente. Un administrador podrá cambiarlo a En

revisión cuando esté siendo atendido por el personal de mantenimiento, y

finalmente a Resuelto cuando la incidencia haya sido solucionada. Solo los

Página 28
 administradores pueden cambiar el estado; los residentes solo pueden consultar.

(En el prototipo, el estado mostrado es aleatorio o está simulado, pero la regla

conceptual se mantiene para una implementación real.)

 RB4. Formato de los reportes: Cada reporte deberá contener ciertos datos

mínimos obligatorios: categoría válida (predefinida en el sistema), descripción o

detalle no vacío, número de apartamento y bloque válidos (que correspondan a

la estructura del conjunto). Si alguno de estos datos falta o es inconsistente, el

sistema no lo registrará. Esta regla asegura integridad y utilidad de cada reporte

ingresado.

 RB5. Unicidad de identificadores: Los identificadores clave, como id de usuario,

id de unidad residencial, id de reporte, etc., deben ser únicos en el sistema (no

puede haber dos reportes con el mismo ID, ni dos usuarios con el mismo email).

Esto se garantiza a nivel de base de datos mediante claves primarias y

restricciones de unicidad.

 RB6. Persistencia y respaldo: Todo reporte guardado deberá almacenarse de

forma persistente y segura. En caso de caída del sistema o reinicio, no se debe

perder la información de reportes previos. Se sugiere la creación de respaldos

periódicos de la base de datos de reportes, dado que constituyen registros

oficiales de incidencias. (En el prototipo, esto se refleja en que los reportes

quedan en localStorage hasta que el usuario decida descargarlos.)

 RB7. Políticas de privacidad: La información de contacto de residentes

(teléfonos, emails) solo podrá ser visualizada por personal autorizado

(administradores) y no se muestra abiertamente a otros residentes a través del

chatbot. De igual forma, HabitaBot no divulgará datos personales sensibles en

Página 29
las conversaciones, siguiendo las políticas de privacidad de la empresa

administradora.

Página 30
2.2. Historias de Usuarios

Como parte del enfoque ágil, se redactaron historias de usuario (HU) para capturar los

requerimientos desde la perspectiva del usuario final, en un formato conciso: “Como

<rol> quiero <funcionalidad> para <beneficio>”. A continuación, se enumeran

algunas de las principales historias de usuario identificadas para HabitaBot, cubriendo

tanto las necesidades de los residentes como las de los administradores:

 HU-01 – Registrar una falla de mantenimiento: Como residente, quiero reportar

una falla o daño en mi conjunto residencial a través del chatbot, para que la

administración quede enterada y gestione su solución. Criterios de aceptación:

el bot debe solicitar categoría de la falla, descripción, ubicación

(apartamento/bloque) y confirmar la recepción del reporte.

 HU-02 – Recibir confirmación del reporte: Como residente, quiero recibir un

comprobante o confirmación después de reportar una falla, para tener la

certeza de que mi solicitud fue registrada correctamente. Criterios: el chatbot

muestra un mensaje resumen con un identificador de reporte y la información

ingresada.

 HU-03 – Consultar estado de mis reportes: Como residente, quiero consultar el

estado de los reportes de falla que he realizado, para conocer si ya fueron

atendidos o están en proceso. Criterios: si existen reportes, el bot lista cada falla

con un estado (Pendiente/En revisión/Resuelto); si no hay reportes, informa que

no existen registros.

Página 31
 HU-04 – Buscar apartamentos disponibles: Como residente (o interesado),

quiero obtener información sobre apartamentos en venta o arriendo en mi

conjunto, para evaluar opciones sin tener que ir a la administración. Criterios:

el bot ofrece elegir entre “Venta” o “Arriendo” y luego muestra al menos 3

anuncios con detalles y un contacto para más información.

 HU-05 – Activar o desactivar voz del asistente: Como usuario, quiero poder

activar o desactivar la función de voz del chatbot, para elegir la forma de

interacción que me resulte más cómoda. Criterios: al presionar el botón de voz,

el estado cambia (ON/OFF) y el bot verbaliza o deja de verbalizar las respuestas

a partir de ese punto.

 HU-06 – Recibir ayuda sobre funciones del bot: Como usuario, quiero que el

chatbot me explique qué operaciones puedo realizar (ayuda), para entender

cómo usarlo correctamente. Criterios: al solicitar “Ayuda”, el bot responde con

una lista de posibles comandos/opciones y una breve descripción de cada una

(por ejemplo “Reportar fallas”, “Ver estado de reportes”, “Ver apartamentos”,

“Activar voz”, etc.).

 HU-07 – Guardar registro de reportes realizados: Como residente, quiero poder

descargar un registro de las fallas que he reportado, para tener un respaldo y,

si es necesario, compartirlo con la administración. Criterios: el bot proporciona

un botón “Descargar reportes” que genera un archivo de texto con el historial; si

no hay reportes, avisa que no hay nada para descargar.

Página 32
 HU-08 – Gestionar residentes y unidades (Admin): Como administrador, quiero

registrar y editar la información de residentes y sus apartamentos en el sistema,

para mantener actualizada la base de datos de usuarios del chatbot. Criterios:

Debe haber una interfaz donde pueda agregar un nuevo residente con su unidad

o modificar la unidad asociada a un residente existente, con validaciones (ej: no

asignar dos residentes principales al mismo apartamento sin permiso).

 HU-09 – Ver reportes de la comunidad (Admin): Como administrador, quiero

visualizar todos los reportes de fallas ingresados por los residentes, para llevar

control de las incidencias del conjunto y asignarlas al personal de

mantenimiento. Criterios: La interfaz administrativa muestra una tabla o lista de

todos los reportes con su estado actual, permite filtrarlos por estado o fecha.

 HU-10 – Actualizar estado de un reporte (Admin): Como administrador, quiero

cambiar el estado de un reporte a medida que progresa su atención (por

ejemplo, marcarlo como resuelto), para que el residente pueda ver que se ha

atendido. Criterios: Al cambiar estado, se registra la fecha y usuario admin que

hizo el cambio; el residente al consultar verá el nuevo estado.

 HU-11 – Consultar estadísticas (Admin, futuro): Como administrador, quiero

obtener un resumen de estadísticas de reportes (cuántos por categoría, tiempos

de resolución promedio), para evaluar áreas problemáticas y eficiencia del

equipo de mantenimiento. Criterios: (Historia para futura implementación)

Generar un reporte mensual con conteo de incidencias por tipo.

Página 33
 HU-12 – Interactuar con menú principal rápidamente: Como residente

impaciente, quiero escribir directamente palabras clave como "registrar falla"

o "descargar reportes" en el chat, para que el bot me lleve directamente a esa

función sin navegar por todos los menús. Criterios: El chatbot reconocerá ciertas

palabras clave en la entrada del usuario (por ejemplo "reportar" o "descargar") y

actuará como si el usuario hubiese pulsado las opciones correspondientes del

menú.

 HU-13 – Interactuar con chatbot de ayuda general: Como usuario, quiero

comunicarme con un chatbot para recibir orientación sobre cómo usar el

sistema, especialmente la primera vez que lo utilizo. Criterios: El bot provee una

respuesta de ayuda al comando "Ayuda", detallando los usos disponibles

(reportar fallas, consultar estado, buscar apartamentos, activar voz).

 HU-14 – Activar o desactivar modo voz del asistente: Como usuario, quiero

activar o desactivar el modo de asistencia por voz para elegir cómo interactuar

con el sistema (texto o voz). Criterios: El botón de voz cambia su etiqueta

(ON/OFF) y el asistente confirma mediante un breve mensaje hablado cuando se

activa.

 HU-15 – Recibir guía mediante comandos rápidos: Como usuario, quiero

escribir comandos como "registrar falla" o "descargar reportes" para que el

chatbot me guíe directamente, sin necesidad de navegar manualmente por

opciones. Criterios: El sistema analiza la entrada del usuario; si coincide con una

funcionalidad conocida, el bot salta a ese flujo (por ejemplo, si escribe

"descargar reportes", el bot procede a generar el archivo si hay reportes).

Página 34
Las historias de usuario del HU-13 al HU-15 complementan las funcionalidades

conversacionales esperadas de HabitaBot, enfatizando la asistencia al usuario en

diversos modos de interacción. Todas las historias sirvieron como base para crear los

casos de uso y las pruebas correspondientes. Durante la implementación, se verificó el

cumplimiento de cada historia mediante escenarios prácticos con el chatbot. Este

enfoque centrado en historias de usuario garantizó que el desarrollo se mantuviera

enfocado en el valor para el usuario final, una de las ventajas clave de las metodologías

ágiles.

Página 35
 3. Diseño

La fase de diseño implicó traducir los requisitos en una estructura técnica y visual para

el sistema. Se elaboraron diversos diagramas siguiendo el estándar UML para guiar la

construcción de HabitaBot: el modelo de datos entidad-relación para la base de datos, el

diagrama de casos de uso para visualizar las interacciones del usuario, diagramas de

actividad para detallar flujos lógicos, y se delineó la arquitectura general del software.

Adicionalmente, se diseñó la interfaz de usuario (en este caso, la ventana de chat)

buscando simplicidad y claridad. En esta sección se presentan los principales productos

del diseño.

Página 36
3.1. Modelo de Datos (Entidad – Relación)

El modelo entidad-relación (ER) define las estructuras de datos que soportan a

HabitaBot. Dado que el sistema manejará información de usuarios, unidades

residenciales y reportes, se identificaron las siguientes entidades principales:

 Usuario: Representa a cada usuario de la plataforma (ya sea residente u

administrador). Sus atributos incluyen: idUsuario (clave primaria, identificador

único numérico), nombre, correo electrónico, contraseña (almacenada cifrada),

teléfono de contacto, y tipoUsuario (por ejemplo, Residente o Administrador).

En caso de residentes, el campo idUnidad funciona como clave foránea para

vincular el usuario con una unidad residencial específica.

 UnidadResidencial: Representa cada apartamento o unidad dentro del conjunto.

Atributos: idUnidad (PK), bloque o torre en la que se ubica, numero de

apartamento, y estadoOcupacion (por ejemplo, Ocupado o Disponible si está en

venta/arriendo). Esta entidad permite registrar la estructura física del conjunto y

asociar residentes a apartamentos.

 Reporte: Registra cada incidencia reportada por un residente. Atributos:

idReporte (PK), descripcion de la falla, fechaRegistro, y estado (Pendiente/En

revisión/Resuelto). Además contiene claves foráneas idUsuario (quién generó el

reporte) e idUnidad (la unidad relacionada, deducible también a través del

usuario). Un reporte puede no tener unidad si es sobre zonas comunes, pero en

general se asocia con la unidad del residente que reporta.

Página 37
 HistorialReporte: Permite llevar un registro de acciones o cambios de estado

sobre cada reporte. Atributos: idHistorial (PK), accion (texto que describe la

acción realizada, por ejemplo "Cambio de estado a Resuelto" o "Comentario

agregado"), fechaAccion, y claves foráneas idReporte (referencia al reporte

afectado) e idAdministrador (referencia al usuario admin que realizó la acción).

Esta entidad no se explotó en el prototipo, pero está diseñada para auditoría

completa en producción.

 Administrador: Dado que decidimos manejar administradores como un tipo

especial de usuario, esta podría ser una entidad derivada o simplemente se

identifica por tipoUsuario. Si se hubiese manejado separado, contendría

idUsuario (PK y FK hacia Usuario) y quizá atributos como nivel de permisos.

En el modelo, se asumió que con tipoUsuario='Administrador' es suficiente, por

lo cual no se creó tabla aparte en la implementación.

 ChatbotInteraccion: Pensada para registrar logs de cada interacción con el

chatbot. Sus atributos serían: idInteraccion (PK), idUsuario (FK del usuario que

interactúa), mensajeUsuario (texto ingresado), mensajeBot (texto respondido),

fecha de la interacción y modoVoz (booleano indicando si estaba la voz

activada). Esta entidad permitiría analizar conversaciones históricas para mejora

continua (no implementada en la versión actual, pero considerada en diseño para

potencial análisis de uso).

Página 38
  DescargaReporte: Opcionalmente, se consideró llevar control de cada evento de

descarga de reportes. Atributos: idDescarga (PK), idUsuario (FK del usuario que

descargó), archivoGenerado (nombre o identificador del archivo .txt generado) y

fechaDescarga. Esto podría ser útil para auditoría o métricas de uso (tampoco

implementado en el prototipo).

Figura 1. Modelo Entidad-Relación (ER):

3.2. Diagrama de Casos de Uso

El diagrama de casos de uso ofrece una vista de alto nivel de las interacciones entre los

actores externos y el sistema HabitaBot, destacando las funcionalidades que el sistema

ofrece. En este proyecto se identificaron dos actores principales:

 Residente: usuario habitual del chatbot que interactúa para reportar problemas y

obtener información.

 Administrador: usuario con privilegios que gestiona el sistema y la información

de los reportes y residentes.

A continuación se presenta el diagrama de casos de uso, que muestra los casos de uso

(óvalos) y su relación con cada actor (figura con nombre):

Página 39
Figura 2. Diagrama de Casos de Uso: Interacciones del Residente

Página 40
3.3. Diagrama de Actividad

Para detallar la lógica interna de ciertos procesos clave se emplearon diagramas de

actividad. En particular, se elaboró un diagrama de actividad para describir el flujo de

pasos involucrado en el caso de uso principal: Reportar una falla a través del chatbot.

Este diagrama modela el comportamiento secuencial y las decisiones durante la

interacción.

A continuación se describe textual y se adjunta el diagrama correspondiente al flujo de

reporte de falla:

1. Inicio: El residente inicia la interacción con HabitaBot (por ejemplo, abre la

ventana del chat) y el sistema está listo para recibir entradas.

2. El residente selecciona la opción "📋 Reportar una falla" del menú principal que

el bot le ofrece.

3. Solicitud de categoría: HabitaBot pide al usuario que especifique la categoría de

la falla (p. ej., parque, bloques, zonas comunes, seguridad, alumbrado, agua u

otros).

4. El usuario elige una categoría (por ejemplo, "Bloques").

5. Detalle específico: El bot, según la categoría elegida, solicita un detalle

específico de la falla. Siguiendo el ejemplo, si la categoría es Bloques, podría

listar sub-opciones (humedad, puerta dañada, ascensor, etc.) o en caso de

"Otros" pedir al usuario que escriba una descripción libre.

6. El usuario proporciona el detalle de la falla (ej.: selecciona "Ascensor detenido"

como falla específica, o escribe "ascensor no responde").

7. HabitaBot entonces pregunta el número de apartamento del usuario.

8. El usuario ingresa su número de apartamento (ej.: "304").

9. El bot solicita a continuación el bloque o torre donde ocurrió la falla.

Página 41
 10. El usuario ingresa el bloque (ej.: "Torre B").

11. Resumen: El chatbot reúne toda la información y muestra un resumen del

reporte al usuario: por ejemplo, "✅ He registrado la falla 'Ascensor detenido' en

la categoría 'Bloques', bloque B, apartamento 304."

12. HabitaBot ofrece opciones para finalizar: "💾 Guardar reporte" o "📂 Descargar

reportes".

13. Si el usuario elige "Guardar reporte", el sistema invoca la función de

almacenamiento y confirma: "💾 Tu reporte ha sido guardado correctamente en el

sistema." (luego le pregunta si desea reportar otra falla).

14. Si el usuario elige "Descargar reportes" en ese punto, el sistema genera el

archivo de texto con el historial de reportes y finaliza el flujo.

15. Fin: El proceso termina ya sea volviendo al menú principal o cerrando la

conversación, según la elección del usuario.

El diagrama de actividad correspondiente a este flujo se ilustra a continuación:

Figura 3. Diagrama de Actividad: Flujo para reportar un fallo

Página 42
 4. Implementación

4.1. Lenguajes de programación utilizados.

Dada la naturaleza del proyecto (interfaz conversacional web), se optó por una stack

tecnológica centrada en el desarrollo web. Los lenguajes y estándares empleados fueron:

 HTML5: se utilizó para crear la estructura de la página web del chatbot. Se

definió un contenedor principal (<div id="chatbox">) que encierra los

subcomponentes de la interfaz: el encabezado con el logo y el botón de voz, el

área de mensajes y el área de entrada de texto y botón enviar. HTML

proporcionó la base semántica sobre la cual se aplicaron estilos y se manipuló el

DOM con JavaScript.

 CSS3: se utilizó para diseñar la apariencia visual del chat de HabitaBot, tanto

mediante estilos internos como externos. Se definieron estilos para clases

como .bot (mensajes provenientes del bot, con fondo celeste) y .user (mensajes

del usuario con fondo verde claro alineados a la derecha), entre otros. También

se aplicaron estilos al contenedor de mensajes para scroll, al botón de voz

(#voiceToggle), etc. Por ejemplo, se estableció:

.bot { background: #e7f3ff; }

.user { background: #d1ffd8; text-align: right; }

#messages { height: 380px; overflow-y: auto; ... }

 de modo que la ventana de conversación fuera de tamaño fijo y con scroll

interno. Se usaron propiedades de flexbox para centrar elementos y crear el

layout responsivo (por ejemplo, el contenedor del chat está centrado vertical y

horizontalmente en la pantalla mediante display: flex; align-items: center;

justify-content: center; height: 100vh; en el body).

Página 43
 JavaScript (ES6): fue el núcleo de la implementación lógica del chatbot. Se

escribió un script principal que controla el comportamiento interactivo: escucha

la entrada del usuario, actualiza la interfaz con nuevos mensajes, y contiene la

máquina de estados que gestiona el diálogo. Se usaron características modernas

de ES6 como let/const, funciones flecha, template literals, y la API de Web

Speech para síntesis de voz.

Página 44
 5. Diseño y de arquitectura de software.

La arquitectura de HabitaBot sigue un enfoque de cliente-servidor de tres capas, común

en aplicaciones web. Aunque el prototipo se ejecuta mayormente del lado cliente, se

diseñó la arquitectura pensando en la futura implementación con un servidor y base de

datos reales. Los componentes principales de la arquitectura son:

 Cliente Web (Front-end): Corresponde a la aplicación que corre en el navegador

del usuario. Incluye la interfaz de usuario (HTML/CSS) y la lógica del chatbot

implementada en JavaScript. Este componente se encarga de gestionar la

interacción con el residente: mostrar la ventana de chat, enviar los mensajes del

usuario al sistema, presentar las respuestas del bot y realizar operaciones locales

(como guardar en localStorage o generar la descarga de reportes). Es

básicamente una aplicación single-page ligera. En el prototipo, toda la

inteligencia de decisión del flujo conversacional reside en el cliente.

 Servidor de Aplicación (Back-end): En una versión completa, existiría un

servidor (por ejemplo, construido con [Link]/Express) que proveería una API

REST. Este servidor manejaría la lógica de negocio que requiere persistencia y

coordinación central: autenticación de usuarios, almacenamiento de reportes en

la base de datos, actualización de estados por administradores, etc. El cliente

web enviaría peticiones HTTP al servidor (por ejemplo, al endpoint /api/reportes

para guardar un nuevo reporte o obtener todos los reportes de un usuario). En el

prototipo, algunas de estas funciones del servidor fueron simuladas en el cliente

(usando localStorage para no depender de un servidor real). Sin embargo, la

arquitectura contempla claramente esta separación para escalabilidad.

Página 45
  Base de Datos: Constituye la capa de almacenamiento persistente. Se planeó

usar MySQL como sistema gestor de base de datos relacional para guardar la

información de usuarios, unidades residenciales, reportes y sus historiales. La

base de datos reside en el servidor y es accedida mediante consultas SQL

realizadas por la lógica de aplicación. La persistencia garantiza que los datos no

se pierdan y puedan ser consultados concurrentemente. En el prototipo, la base

de datos MySQL no estuvo activa; los datos se guardaron localmente. No

obstante, se diseñaron los esquemas (ver modelo ER) y se preparó el proyecto

para esa integración más adelante.

 Servicios externos (futuros): Si se piensa a futuro, HabitaBot podría integrarse

con servicios de mensajería externos (por ejemplo, integración con WhatsApp

mediante API para recibir reportes, o con sistemas de tickets). También podría

haber un módulo de notificaciones push por correo. Estos componentes no se

implementaron, pero la arquitectura es extensible para añadir capas de

integración.

La comunicación entre componentes se da de la siguiente manera: el Residente,

mediante su navegador, interactúa con la aplicación web (frontend). Si la información

que solicita o envía requiere persistencia, el front envia una petición al servidor (por

AJAX/Fetch API), el cual a su vez lee o escribe en la base de datos. Luego el servidor

responde al cliente con los datos necesarios. Por ejemplo, al iniciar sesión (RF2), el

front enviaría credenciales al servidor, este las valida en la BD de usuarios y devuelve

una respuesta de éxito y token de sesión.

Figura 5. Diagrama de Arquitectura del Sistema

Página 46
 6. Gestión de calidad, testing y documentación

6.1. Estrategia de pruebas.

La estrategia de pruebas combinó pruebas manuales y automáticas en distintos niveles:

 Pruebas unitarias: Se probaron funciones individuales del código JavaScript, por

ejemplo la función estadoAleatorio() que devuelve un estado de reporte

aleatorio, verificando que siempre retornara uno de los valores esperados ("En

revisión", "Resuelto" o "Pendiente"). Del mismo modo, se probaron unidades

lógicas como generarApartamentos(tipo) para confirmar que generara

exactamente 3 apartamentos con atributos válidos en el formato correcto.

 Pruebas de integración: Se ejecutaron escenarios completos dentro del chatbot

para validar la interacción entre múltiples funciones. Por ejemplo, se simuló el

flujo completo de reportar una falla de principio a fin y se observó si todos los

componentes integrados (UI, funciones de agregar mensajes, almacenamiento,

etc.) funcionaron en armonía. Esto reveló inicialmente algunos problemas de

sincronización (como que handleUserInput("") se llamaba al final para reiniciar,

generando a veces un mensaje extra no deseado, lo cual se ajustó).

Página 47
 Pruebas funcionales (de sistema): Se crearon casos de prueba basados en los

requisitos funcionales (ver apartado 6.2) para verificar que cada funcionalidad

implementada cumpliera con los criterios de aceptación. Cada caso de uso

identificado tuvo al menos un caso de prueba asociado. Estas pruebas se

realizaron de forma manual, adoptando el rol de usuario final y siguiendo pasos

predefinidos. Por ejemplo, se probó que al iniciar HabitaBot, el saludo y menú

inicial aparecieran; luego al pulsar "Reportar una falla", se sucedieran

correctamente las preguntas de categoría, detalle, etc., y que tras guardar se

pudiera descargar el archivo. Igualmente, se probó que al solicitar "Ayuda", el

bot enlistara las funcionalidades, etc. Se revisó también la experiencia de usuario

(UX) para asegurarse de la facilidad de uso.

 Pruebas de interfaz de usuario: Se inspeccionó la interfaz en distintos

navegadores (Chrome, Firefox) y tamaños de pantalla para garantizar

consistencia en estilos y legibilidad. Además se validó que los colores

cumplieran consideraciones de contraste suficiente. Estas pruebas aseguran la

usabilidad, componente clave de calidad para este proyecto.

 Pruebas de rendimiento: Dado que la aplicación es liviana, no se usaron

herramientas especializadas, pero sí se hicieron mediciones empíricas: se

verificó que el tiempo de respuesta del bot ante cada input fuera prácticamente

inmediato. Con ~50 reportes almacenados en localStorage, la función de

descarga aún operaba sin demoras notables (unos pocos cientos de

milisegundos). Esto indica que para el volumen esperado (un conjunto

residencial pequeño o mediano) el rendimiento es adecuado.

Página 48
  Pruebas de seguridad básicas: Se intentó ingresar secuencias maliciosas o

inesperadas en la entrada del chat (por ejemplo HTML tags, inyecciones de

<script> o SQL keywords) para asegurar que no rompieran la aplicación.

Gracias a la sanitización ([Link](/<[^>]*>/gm, '') al hablar el bot), se

confirmó que etiquetas HTML no deseadas no se renderizan como código

ejecutable, apareciendo inofensivamente como texto plano en la conversación.

Aunque la seguridad completa requeriría más, estas pruebas iniciales dieron

confianza en que no hay vulnerabilidades triviales.

La estrategia también incluyó una revisión de código (code review) por parte de todos

los miembros: se revisó la claridad, se removieron duplicaciones y se comentaron las

secciones críticas del código para futura mantenibilidad.

3.5.1. Casos de prueba.

A continuación se enumeran algunos casos de prueba representativos, indicando su

objetivo, pasos y resultado esperado:

 CP01 – Inicio y saludo del bot: Objetivo: Verificar que al cargar la página,

HabitaBot salude correctamente y muestre el menú principal.

Precondición: Navegador abierto en [Link].

Pasos: 1) Cargar/Refrescar la página.

Resultado esperado: El chat muestra el mensaje de saludo ("¡Hola! ... ¿Qué

deseas hacer hoy?") y cuatro botones: "Reportar una falla", "Ver estado de

reportes", "Ayuda", "En busca de apartamentos". El botón de voz debe decir

"Voz OFF" por defecto.

Resultado obtenido: Pasó. El saludo y opciones se presentaron como previsto.

Página 49
 CP02 – Reporte exitoso de una falla: Objetivo: Comprobar el flujo completo

de registro de un reporte.

Pasos: 1) Click en " Reportar una falla". 2) En la lista de categorías que aparece,

click en "Bloques". 3) En la lista de fallas de bloques, seleccionar "Ascensor

detenido". 4) Cuando el bot pide apartamento, ingresar "101" y presionar Enviar.

5) Cuando pide bloque, ingresar "A" y Enviar. 6) Al mostrar resumen, click en "

Guardar reporte".

Resultado esperado: Bot confirma con mensaje "Tu reporte ha sido guardado

correctamente". Luego pregunta si desea registrar otra falla. El nuevo reporte

debe existir en localStorage y ser recuperable.

Resultado obtenido: Pasó. El flujo se desarrolló sin problemas, la información

presentada fue correcta. Al inspeccionar [Link], se encontró el

objeto del reporte con los datos ingresados.

 CP03 – Cancelación de reporte a mitad del flujo: Objetivo: Asegurar que el

usuario pueda desistir y volver al menú sin completar reporte.

Pasos: 1) Click "Reportar una falla". 2) Cuando pregunte categoría, en vez de

elegir una categoría, escribir "No" manualmente y Enviar.

Resultado esperado: El bot debe interpretar "no" como negativa y ofrecer

regresar al menú principal (según flujo de confirmarReporte).

Resultado obtenido: Pasó. El bot respondió "Está bien . Aquí estaré cuando

necesites reportar algo." y no quedó en un estado inconsistente. Flujo finalizado.

 CP04 – Consulta de estado de reportes con datos: Objetivo: Verificar que se

listan estados de todos los reportes.

Precondición: Tener al menos 2 reportes guardados en localStorage.

Pasos: 1) Click en "Ver estado de reportes".

Página 50
 Resultado esperado: El bot muestra cada reporte con un ícono y texto "Falla:

[descripción] - Estado: [En revisión/Pendiente/Resuelto]". Luego ofrece botón

"Menú principal".

Resultado obtenido: Pasó. Para cada reporte almacenado se mostró una línea

con estado "Pendiente" o "Resuelto" (simulados por estadoAleatorio()),

coincidiendo el número de líneas con el de reportes guardados.

3.5.2. Resultados de las pruebas.

Las pruebas realizadas confirmaron que HabitaBot cumple con los requisitos y es

estable en su comportamiento. A continuación se resumen los resultados generales:

 Funcionalidad: Todas las funcionalidades implementadas operan conforme a lo

esperado. Se pudo reportar fallas, consultarlas, obtener ayuda, buscar

apartamentos, usar la voz, descargar datos, etc., sin fallas ni

comportamientos inesperados. Los criterios de aceptación de cada historia de

usuario fueron satisfechos. Por ejemplo, el caso de uso más complejo (reportar

una falla) se completó con éxito repetidas veces, incluso ingresando variaciones

(diferentes categorías, con o sin detalles extras). El sistema previene entradas

incompletas al no avanzar de etapa si el usuario no proporciona la información

solicitada (por diseño de flujo).

 Usabilidad: Las pruebas con usuarios de prueba (compañeros que no habían

usado el sistema) fueron positivas. En pocos minutos lograron entender cómo

interactuar con el bot, encontraron útiles las respuestas de ayuda y calificaron la

interfaz como amigable. Se evidenció que los botones facilitaban mucho la

experiencia. Un ajuste surgido de estas pruebas fue añadir el ícono de casa 🏠 al

texto "Menú principal" del botón de regreso, para hacerlo más evidente; también

Página 51
 se aumentó ligeramente el tamaño de fuente de los mensajes para mejorar la

lectura. Tras estos cambios, la satisfacción de los usuarios de prueba fue alta,

indicando que la experiencia de usuario es adecuada para el público objetivo.

 Rendimiento: El chatbot respondió instantáneamente en los navegadores

probados. No se observaron ralentizaciones al cargar listas de botones o al

manipular arreglos en localStorage. Incluso con decenas de mensajes en el

historial, el scroll y la interfaz se mantuvieron fluidos. Dado el alcance del

sistema, no hubo problemas de memoria. Se estimó que la aplicación podría

manejar cientos de usuarios concurrentes en entornos reales sin problemas,

siempre que el servidor esté dimensionado apropiadamente, pues la carga en el

cliente es mínima.

 Compatibilidad: Se probó en Google Chrome v100+, Mozilla Firefox v90+ y

Microsoft Edge, todos en Windows 10. En todos se comportó correctamente.

En dispositivos móviles (Chrome en Android), la ventana de chat se adaptó al

tamaño reducido, permitiendo scroll en el contenedor de mensajes. El único

detalle encontrado fue que en Safari (iOS) la síntesis de voz requería interacción

del usuario (limite de seguridad), pero una vez activada funcionó. Por tanto, el

sistema es ampliamente compatible con plataformas modernas.

 Seguridad: Si bien no se hicieron pruebas de penetración exhaustivas, las

validaciones implementadas respondieron bien. Por ejemplo, al intentar inyectar

HTML (<img src=x onerror=alert('hack')>), el bot envió literalmente la cadena

escapada sin ejecutar nada, mostrando que nuestro sanitizado es eficaz. Esto

protege contra ataques XSS básicos. Para SQL injection, dado que no hay

consultas directas del cliente, no aplica en esta capa. De cualquier forma, en un

despliegue real se agregaría sanitización en el servidor también. No se

Página 52
 encontraron fugas de información: el bot no revela datos de otros usuarios (ya

que opera por sesión en el navegador). Un posible punto a mejorar en seguridad

sería implementar un control de tasa de peticiones para evitar spam del bot,

aunque por su naturaleza lineal no fue crítico en este contexto.

 Mantenibilidad del código: Aunque no es un resultado de pruebas, cabe

mencionar que en la revisión final del código se constató que este está ordenado

en secciones lógicas, con comentarios explicativos en funciones más complejas.

Por ejemplo, se etiquetó claramente la sección de lógica de reportes existente vs.

nueva en handleUserInput. Esto cumple buenas prácticas que facilitarán futuras

actualizaciones o la incorporación de nuevos desarrolladores al proyecto.

Página 53
 7. Mantenimiento y Actualizaciones.

7.1. Planes para futuras actualizaciones.

 Integración con plataforma móvil: Un primer paso evolutivo será portar o

complementar HabitaBot con una aplicación móvil nativa (Android/iOS) o al

menos asegurar que la versión web sea tipo Progressive Web App (PWA)

instalable. Esto facilitaría que los residentes usen el asistente desde sus teléfonos

con notificaciones push. La arquitectura actual lo permite, ya que el frontend

podría reutilizar la API. Se explorará el desarrollo en tecnologías híbridas (por

ejemplo, React Native o Flutter) para mantener un único código base.

 Backend robusto y notificaciones: Implementar completamente el servidor

backend que quedó planificado. Esto incluye desplegar una base de datos

central (en la nube) y modificar el chatbot para que en lugar de usar localStorage

llame a servicios REST. Un backend permitiría características avanzadas: por

ejemplo, enviar notificaciones automáticas por email o WhatsApp al

administrador cada vez que se registre un nuevo reporte, o al residente cuando su

estado cambie a Resuelto. Estas notificaciones mejorarían la efectividad del

sistema.

 Procesamiento de Lenguaje Natural (NLP): Actualmente el chatbot sigue

flujos predefinidos, pero una mejora importante sería incorporar un motor de

NLP (como Dialogflow o IBM Watson Assistant) para hacer la interacción más

flexible. Por ejemplo, permitir que el residente escriba en lenguaje libre "Quiero

reportar que no hay luz en el pasillo del bloque 3" y que el bot entienda la

intención y extraiga datos (categoría alumbrado, detalle farola apagada, bloque

Página 54
 3, etc.). Esto haría a HabitaBot más inteligente y conversacional. Según

tendencias recientes, los asistentes con IA conversacional ofrecen experiencias

más naturales y [Link], por lo que sería un upgrade

valioso.

 Ampliación de conocimientos (FAQ): Se planea entrenar a HabitaBot para que

pueda responder preguntas frecuentes de los residentes, más allá de reportes. Por

ejemplo: "¿Cuándo vence la cuota de administración?" o "¿Cuál es el horario de

la piscina?" y que el bot responda según información cargada por los

administradores. Esto convertiría al chatbot en un verdadero asistente virtual

integral para la propiedad horizontal. Algunas empresas ya están

implementando asistentes así para comunidades residenciales, ofreciendo

respuestas inmediatas a consultas [Link].

 Multi-idioma: Dado que en algunas comunidades podría haber residentes

angloparlantes u de otra lengua, se considerará internacionalizar el chatbot con

soporte multi-idioma (español/inglés inicialmente). Técnicamente, sería agregar

un archivo de recursos con traducciones y detectar el idioma preferido del

usuario.

 Módulo de pagos y reservas: Como expansión futura, HabitaBot podría

incorporar funcionalidades transaccionales, por ejemplo: permitir a un residente

reservar áreas comunes (salón social, cancha) interactuando con el bot, o

realizar pagos en línea de sus cuotas mensuales. Esto requiere integraciones

con pasarelas de pago y calendarios, pero añadiría enorme valor a la gestión

residencial digital.

 Métricas y panel de administración: En la interfaz de administrador, se prevé

desarrollar un panel de control con métricas visuales (gráficos) sobre los

Página 55
 reportes: número de reportes por mes, categoría más reportada, tiempos

promedio de resolución, etc. Esto ayudaría a la administración a identificar

cuellos de botella (por ejemplo, si "Humedad en apartamentos" es muy

recurrente, planear mantenimientos preventivos). Adicionalmente, se podrían

listar los residentes más participativos o aquellos que nunca han usado la

plataforma, orientando campañas de adopción.

 Mejoras de seguridad: A medida que el sistema crezca, se implementarán

mecanismos avanzados de seguridad: autenticación de dos factores para

administradores, limitación de intentos de login, cifrado de datos sensibles en

reposo (p. ej., usando AES para ciertos campos en BD), monitoreo de actividad

sospechosa, entre otros. Esto es crucial para mantener la confianza en el sistema,

especialmente si manejará datos personales y financieros (en caso de pagos).

 Escalabilidad horizontal: Si la herramienta se despliega en múltiples conjuntos

residenciales administrados por la misma empresa, se trabajará en que una única

instancia de HabitaBot pueda servir a varias comunidades, separando sus datos

por instancia. Esto implicará agregar un identificador de comunidad en las

entidades (multi-tenancy) y quizás permitir cierta personalización (por ejemplo,

nombre del condominio en el saludo, distintas categorías de fallas según el

lugar). La arquitectura orientada a microservicios puede ser evaluada si la base

de usuarios crece significativamente.

Página 56
 8. Manual de Usuario

HabitaBot es una herramienta orientada a usuarios finales (residentes de un conjunto

residencial y personal administrativo). El Manual de Usuario proporciona instrucciones

claras para que cualquier persona pueda aprovechar las funciones del chatbot sin

conocimientos técnicos previos. A continuación se presentan las secciones principales

de este manual:

 Introducción: Explica brevemente qué es HabitaBot y cuáles son sus

capacidades, motivando al usuario a utilizarlo. Ejemplo: "HabitaBot es un

asistente virtual disponible las 24 horas para ayudarte a reportar problemas en tu

conjunto residencial, consultar información y más, de forma fácil y rápida."

 Acceso al sistema: Detalla cómo acceder al chatbot. En este caso, si está

integrado en la página web de la administración, se indica la URL o la sección

("Portal del Residente") donde aparece el ícono o ventana del chat. Si hubiese

login, se explica cómo iniciar sesión con usuario y contraseña. Para el

prototipo, el acceso es directo al cargar la página web.

 Interfaz del Chatbot: Se describe la ventana de chat y sus componentes:

encabezado con logo y botón de voz, área de conversación donde aparecen los

mensajes, campo de texto donde el usuario escribe, y botones de opciones. Se

incluye una imagen de la interfaz con etiquetas numeradas para identificar cada

elemento.

 Uso básico – pasos comunes: Se instruye al usuario sobre cómo enviar mensajes

(por ejemplo: "Escribe tu mensaje en el campo inferior y haz click en Enviar o

presiona Enter"), y cómo seleccionar opciones (click en los botones azules que

Página 57
 muestra el bot). Se aclara que el bot inicialmente presentará un menú principal

de opciones disponibles.

 Reportar una falla: Explica paso a paso este proceso con un ejemplo:

1. En el menú principal del chat, haz click en "📋 Reportar una falla".

2. El bot te preguntará la categoría de tu problema; selecciona la que

corresponda (Parque, Bloques, etc.).

3. Luego te pedirá un detalle específico: selecciona o escribe la descripción

según te indique.

4. A continuación, ingresa tu número de apartamento y el bloque cuando se

te solicite.

5. El bot te mostrará un resumen; confirma guardando el reporte.

6. Recibirás confirmación de que tu reporte fue registrado.

Sugerencia: Se incluyen capturas de pantalla de ejemplo para visualizar estos pasos, con

mensajes del bot y respuestas del usuario, para que el lector reconozca la situación real.

 Consultar estado de mis reportes: Indica que el usuario puede en cualquier

momento escribir "estado de reportes" o hacer click en "📊 Ver estado de

reportes" en el menú principal, tras lo cual el bot listará todos los reportes

realizados y sus estados. Se muestra una captura ejemplo de la lista de estados.

Se explica que si no tiene reportes, el bot lo indicará.

 Buscar apartamentos en venta/arriendo: Describe cómo usar la opción "🔍 En

busca de apartamentos". El usuario elige si desea ver en venta o en arriendo.

Luego el bot mostrará un listado, y para cada apartamento habrá un botón "📞

Pedir información de contacto: [Nombre]". Al pulsarlo, el bot proporcionará los

datos de contacto (correo/teléfono) de la persona encargada. Se aconseja que,

tras obtener la información, el usuario contacte directamente si está interesado.

Página 58
 Función de voz: Explica el botón de altavoz en la cabecera. Por defecto dice

"Voz OFF" (mute). Si el usuario hace click y lo ve cambiar a "Voz ON",

significa que a partir de ese momento, el bot leerá en voz alta todos sus

mensajes. Vuelve a pulsar para silenciar de nuevo. Se menciona que la primera

vez posiblemente el navegador pida permiso para usar el micrófono/sonido.

También se aclara que la voz es generada automáticamente en español.

 Cómo pedir ayuda: Informa que en cualquier momento el usuario puede escribir

"ayuda" o seleccionar la opción 🆘 para recibir un recordatorio de qué puede

hacer el bot. El bot listará las funcionalidades. Recomendar hacer esto si el

usuario no está seguro de cómo proceder.

 Consejos de uso: Esta sección brinda tips para mejorar la experiencia:

o Ser específico al describir un problema para ayudar a una pronta

solución.

o No ingresar información personal sensible en el chat (más allá de lo

solicitado, por seguridad).

o Mantener activadas las notificaciones (si en futuro las hay) para enterarse

cuando su reporte sea resuelto.

o Usar la opción de descargar reportes como comprobante antes de

asambleas o reclamos formales.

 Resolución de problemas comunes: FAQ breve:

o "El bot no responde": Verificar conexión a internet. Si persiste, contactar

a soporte.

o "El bot no entiende lo que escribo": Intentar usar las opciones sugeridas

en botones o escribir palabras clave simples.

Página 59
 o "No puedo activar la voz": Asegurarse de haber dado permiso de audio

en el navegador.

o "¿Cómo cambio mi apartamento o mis datos?": Indica que eso lo hace el

administrador, no el bot.

 Contacto de soporte: Se provee información de contacto (correo/telefono de la

mesa de ayuda de la administración) en caso de que el usuario encuentre un error

en HabitaBot o necesite asistencia adicional no cubierta por el bot.

El manual está escrito en un lenguaje claro y accesible, evitando términos técnicos.

Instrucciones paso a paso, con capturas de pantalla y ejemplos prácticos, permiten que

incluso usuarios no familiarizados con chatbots puedan seguirlo. Por ejemplo, se

incluyen imágenes con globos de diálogo resaltando "Usuario escribe: Hola" y "Bot

responde: ..." para simular la experiencia real.

Siguiendo este manual, un residente promedio podrá desde el primer uso reportar sus

incidencias y navegar por las funciones de HabitaBot sin dificultad. Asimismo, el

manual es útil para el personal de administración, ya que les permite conocer también lo

que ven los residentes y así poder brindar ayuda si algún vecino se acerca con dudas.

Página 60
 9. Manual de Técnico

El Manual Técnico está dirigido a desarrolladores y personal de TI encargado de dar

mantenimiento o continuar el desarrollo de HabitaBot. Contiene la información

necesaria para comprender la estructura interna del software, los entornos de desarrollo,

la configuración del sistema y cómo desplegarlo. Secciones clave del manual técnico

incluyen:

 Descripción General de la Arquitectura: Resumen de la arquitectura de software

(como en sección 5) con un diagrama de componentes. Se explicita que es una

aplicación web con front-end en HTML/CSS/JS y un backend propuesto en

[Link] + MySQL. Se mencionan los módulos en que se divide el código y

cómo interactúan. Incluye diagramas UML complementarios, como un diagrama

de clases simplificado si aplica, o diagramas de despliegue indicando servidores,

etc., para contexto global.

 Estructura de Archivos y Directorios: Detalle del árbol de archivos del proyecto.

Página 61
 10. Código Fuente

En esta sección se presenta parcialmente el código fuente de los componentes

principales de HabitaBot, junto con explicaciones de su funcionamiento. Se enfoca en

aquellos fragmentos clave que implementan los requisitos más importantes, sirviendo

como referencia para desarrolladores o revisores del código. (Para el listado completo

de código, referirse al repositorio del proyecto entregado).

Fragmento 1: Estructura HTML del chat y botón de voz (archivo [Link])

<div id="messages"></div>

<div id="inputArea">
<input type="text" id="userInput" placeholder="Escribe tu mensaje...">
<button onclick="sendMessage()">Enviar</button>
</div>
</div>
En este código se observa la estructura básica de la interfaz de usuario:

 El div#chatbox contiene todo el componente de chat.

 Dentro de #header se coloca la imagen de perfil del bot (logo redondo) y el título

"HabitaBot". A la derecha está el botón voiceToggle, el cual al hacer clic invoca

Página 62
 la función JavaScript toggleVoice(). Este botón muestra por defecto "🔇 Voz

OFF" indicando que la voz está desactivada al inicio.

 Luego, div#messages es un contenedor vacío donde mediante JavaScript se irán

agregando los mensajes de la conversación (cada mensaje será un div con clase

"bot" o "user" inyectado dinámicamente).

 Finalmente, en div#inputArea está el campo de texto #userInput donde el

usuario escribe su mensaje, y un botón Enviar que llama a sendMessage() al

pulsarse. Nótese que también se envía al presionar Enter en el campo de texto

(implementado en la función sendMessage).

Este fragmento muestra el uso de identificadores y estructura semántica para que el

script JS pueda manipular el DOM fácilmente (por ejemplo, obteniendo

[Link]('messages') para agregar contenido).

Fragmento 2: Lógica de guardado de reporte y descarga (archivo [Link] – script

JavaScript)

function guardarReporte() {
const reporte = { categoria, falla, extra, apartamento, bloque, fecha: new
Date().toLocaleString() };
[Link](reporte);
let reportes = [Link]([Link]('reportes')) || [];
[Link](reporte);
[Link]('reportes', [Link](reportes));
addMessage("bot", "💾 Tu reporte ha sido guardado correctamente en el sistema.");
}

function descargarReportes() {
const reportes = [Link]([Link]('reportes')) || [];
if([Link]===0){
addMessage("bot","📂 No hay reportes para descargar.");

Página 63
 return;
}
let text = [Link](r=>`Fecha: ${[Link]}\nCategoría: ${[Link]}\nFalla: $
{[Link]}\nExtra: ${[Link]}\nApartamento: ${[Link]}\nBloque: ${[Link]}\
n`).join("\n-----------------\n");
const blob = new Blob([text], {type:"text/plain"});
const a = [Link]("a");
[Link] = [Link](blob);
[Link] = "[Link]";
[Link]();
}
Fragmento 3: Manejo de voz (funciones speak y toggleVoice)

let voiceEnabled = false;

function speak(text) {
if (!voiceEnabled) return;
const utterance = new SpeechSynthesisUtterance(text);
[Link] = "es-ES";
[Link] = 1;
[Link] = 1;
[Link](utterance);
}

function toggleVoice() {
voiceEnabled = !voiceEnabled;
const btn = [Link]("voiceToggle");
[Link] = voiceEnabled ? "🔊 Voz ON" : "🔇 Voz OFF";
[Link] = voiceEnabled ? "#43a047" : "#1976d2";
if(voiceEnabled){
speak("Función de voz activada. Hola, ahora también puedo hablar contigo.");
}
}

Fragmento 4: Ejemplo de transición de estados en handleUserInput

Página 64
else if (step === "categoria") {
categoria = input;
addMessage("bot", `Entendido. Categoría seleccionada: <b>${categoria}</b>.`);
switch (true) {
case [Link]("parque"):
addButtons([" Juegos dañados", " Banca rota", " Basura acumulada", " Falta de
iluminación", "Otro problema"]);
break;
case [Link]("bloque"):
addButtons([" Humedad", " Puerta dañada", " Ascensor detenido", " Escaleras en
mal estado"]);
break;
// ... otros cases para zonas, seguridad, alumbrado, agua ...
default:
addMessage("bot", "Por favor, describe brevemente la falla.");
step = "fallaLibre";
return;
}
step = "falla";

11. Glosario

Administrador: Usuario con permisos avanzados en el sistema HabitaBot, típicamente

personal de la administración del conjunto residencial. Puede gestionar usuarios, ver

todos los reportes y actualizar estados. Equivale al rol administrador de propiedad

horizontal en la vida real.

API (Application Programming Interface): Conjunto de definiciones y protocolos

mediante los cuales se comunica el front-end con el back-end. En HabitaBot se planificó

una API REST para enviar/recibir datos como reportes y usuarios entre cliente y

servidor.

Página 65
Botón de Voz: Elemento de la interfaz del chatbot que permite activar o desactivar la

funcionalidad de síntesis de voz. Muestra el ícono de altavoz con estado ON/OFF. Al

activarse, el bot lee en voz alta sus respuestas.

Chatbot: Programa de computadora que simula una conversación con humanos

mediante texto (y en el caso de HabitaBot, también voz). HabitaBot es un chatbot

diseñado para asistentes virtuales en comunidades residenciales, capaz de comprender

comandos predefinidos y responder en lenguaje natural.

Conjunto Residencial: Comunidad de viviendas (por ejemplo, edificios de apartamentos

o casas) administrada de forma conjunta. En el contexto de este proyecto, es el entorno

donde se implementa HabitaBot para facilitar la comunicación entre residentes y

administración.

CSS (Cascading Style Sheets): Lenguaje de hojas de estilo utilizado para definir la

presentación visual de documentos HTML. En HabitaBot, CSS define la apariencia del

chat (colores, fuentes, layouts).

Estado (de reporte): Condición actual de un reporte de falla en su ciclo de vida. Se

manejan tres estados: Pendiente (recién registrado, sin atender), En revisión (en proceso

de ser atendido) y Resuelto (solucionado). Los estados ayudan a priorizar y comunicar

el progreso de cada incidencia.

HTML (HyperText Markup Language): Lenguaje estándar de marcado para la creación

de páginas web. En este proyecto, HTML estructura la interfaz del chatbot.

LocalStorage: Almacenamiento web provisto por el navegador para guardar datos

localmente en formato clave-valor. HabitaBot utiliza LocalStorage para guardar los

reportes generados por un usuario en su navegador, permitiendo persistencia entre

sesiones (hasta que se borren los datos de navegación).

Página 66
Habla Sintética / Síntesis de Voz: Tecnología que convierte texto en voz hablada.

Implementada mediante la Web Speech API en HabitaBot, permite al bot "hablar" las

respuestas en español.

Reporte de Falla: Registro de un problema o incidencia reportado por un residente a

través de HabitaBot. Contiene información sobre qué ocurrió (descripción), dónde

(apartamento/bloque), cuándo (fecha) y categoría del problema. Los reportes quedan

almacenados para seguimiento por la administración.

Residente: Usuario final de HabitaBot, habitante de una unidad residencial (apartamento

o casa) en el conjunto. Los residentes usan el chatbot para comunicar problemas,

solicitudes o consultas. Tienen permisos limitados a sus propios datos y reportes.

Speech Synthesis API: Interfaz de programación web proporcionada por navegadores

modernos para síntesis de voz. Permite generar audio a partir de texto. En este proyecto

se utiliza para dar voz a HabitaBot.

Sprint: Término de metodologías ágiles (Scrum) que define un ciclo de trabajo corto

con entregables. En el desarrollo de HabitaBot se usaron sprints semanales para

planificar e implementar subconjuntos de funcionalidades.

Usuario Vinculado (Secundario): Término mencionado en requisitos para referirse a un

residente secundario asociado a una unidad residencial (por ejemplo, un familiar o

roommate del residente principal). En el sistema, podría tener permisos restringidos

pero generalmente se trata similar a un residente estándar, asociado a la misma unidad.

Web Speech API: Conjunto de APIs web que incluyen SpeechSynthesis (síntesis de

voz) y SpeechRecognition (reconocimiento de voz). En nuestro caso se usa

SpeechSynthesis para salida de voz. Permiten a las aplicaciones web interactuar con la

voz del usuario (entrada o salida).

Página 67
Workflow (Flujo de Trabajo): Secuencia de pasos ordenados para completar un proceso.

Por ejemplo, el workflow de "reportar falla" comprende los pasos: seleccionar

categoría, detallar falla, ingresar ubicación, confirmar y guardar. Se modeló con un

diagrama de actividad.

Propiedad Horizontal: Régimen legal de algunos países (como Colombia) que se refiere

a edificios o conjuntos de casas donde coexisten áreas privadas y comunes

administradas colectivamente. Es el contexto de la solución HabitaBot, dado que aplica

a comunidades residenciales bajo este esquema.

Glosario: Sección de un documento (como este) destinada a definir términos técnicos o

específicos utilizados, facilitando su comprensión para los lectores.

Referencias

 Acaunti. (2025). Un paso hacia la administración inteligente (Blog). Propiedata.

Recuperado de [Link] (consulta 2025-10-29).

 ITW. (2025, 28 de enero). Pruebas de software: su importancia, retos y

oportunidades para 2025. Recuperado de [Link] (consulta 2025-10-29).

 Marketing Pragma. (2024, 2 de mayo). Asistentes virtuales para la

administración de fincas. Pragma Blog. Recuperado de [Link] (consulta

2025-10-29).

Página 68
 Medina Velandia, L. N., & Gutiérrez Medina, D. A. (2024). Pautas para optar

por una metodología ágil para proyectos de software. Educación en Ingeniería,

19(37), 55-68. DOI: 10.26507/rei.v19n37.1292

 Sánchez, E. (2020, 23 de marzo). La importancia de la Arquitectura de Software

y otras prácticas. Medium. Recuperado de [Link] (consulta 2025-10-29).

Página 69