Nombre | Código |
---|---|
Vasquez Requejo Augusto Mathias Leonardo | u20221A955 |
Cervantes Erequita Valentino Sebastian | U202110140 |
Ccotarma Ttito, Sihuar Eduardo Eusebio | U20211c736 |
Carpio Cornejo, Miguel Ángel Jesús | u20221c360 |
Braithuaite Toledo, Gabriel Anthony | u20201e889 |
El objetivo de esta sección es resumir las modificaciones relevantes que se realizan al informe durante el ciclo de vida del proyecto. Esta sección inicia en una página nueva y se incluye un cuadro con la siguiente estructura:
Versión | Fecha | Autores | Descripción de Modificaciones |
---|---|---|---|
1era | 19/25/2025 | Carátula, CapítuloI, Capítulo II, Capítulo III, Capítulo IV, Capítulo V |
URL del repositorio para el reporte del proyecto: https://github.com/KamaqLabs/Report
TB1
Para el desarrollo del informe perteneciente a la entrega TB1, se dividió la implementación de secciones de la siguiente forma para cada integrante del equipo:
Integrante | Tareas Asignadas |
---|---|
Vasquez Requejo Augusto Mathias Leonardo | Chapters 01,02,03,04,05 |
Cervantes Erequita Valentino Sebastian | Chapters 01,02,03,04,05 |
Ccotarma Ttito, Sihuar Eduardo Eusebio | Chapters 01,02,03,04,05 |
Carpio Cornejo, Miguel Ángel Jesús | Chapters 01,02,03,04,05 |
Braithuaite Toledo, Gabriel Anthony | Chapters 01,02,03,04,05 |
Los integrantes son:
- Vasquez Requejo Augusto Mathias Leonardo | (Mathifa519)
- Braithuaite Toledo Gabriel Anthony | (Gaboo04)
- Cervantes Erequita Valentino Sebastian |(KiwiAmenazante)
- Ccotarma Ttito, Sihuar Eduardo Eusebio | (Anx0123)
- Carpio Cornejo, Miguel Ángel Jesús | (MiguelCarpioC)
-
Capítulo IV: Solution Software Design
- 4.1. Strategic-Level Domain-Driven Design
- 4.2. Tactical-Level Domain-Driven Design
ABET – EAC - Student Outcome 5
Criterio: La capacidad de funcionar efectivamente en un equipo cuyos miembros juntos proporcionan liderazgo, crean un entorno de colaboración e inclusivo, establecen objetivos, planifican tareas y cumplen objetivos.
Criterio Específico | Acciones Realizadas | Conclusiones |
---|---|---|
Trabaja en equipo para proporcionar liderazgo en forma conjunta | Vasquez Requejo Augusto Mathias Leonardo TB1: Contribuyó al desarrollo de los capítulos iniciales del informe, organizando los apartados de introducción y propuesta de solución, lo que permitió orientar al equipo sobre la estructura general del documento. Cervantes Erequita Valentino Sebastian TB1: Aportó en la redacción y consolidación de las secciones relacionadas con la problemática y entrevistas, coordinando con el equipo para definir las ideas clave. Ccotarma Ttito Sihuar Eduardo Eusebio TB1: Se enfocó en el análisis de competidores y necesidades de usuario, planteando lineamientos para guiar las decisiones del equipo. Carpio Cornejo Miguel Ángel Jesús TB1: Colaboró en la organización del índice y los entregables de especificación de requerimientos, brindando soporte en la redacción y alineación de criterios comunes. Gabriel Braithuaite TB1: Trabajó con el equipo de manera conjunta decidiendo los objetivos de la primera entrega. |
Se logró consolidar el liderazgo compartido entre los integrantes, distribuyendo funciones claves que guiaron la elaboración del documento TB1. |
Crea un entorno colaborativo e inclusivo, establece metas, planifica tareas y cumple objetivos | Vasquez Requejo Augusto Mathias Leonardo TB1: Facilitó la coordinación inicial del trabajo, definiendo los primeros objetivos y estableciendo un plan de redacción conjunta. Cervantes Erequita Valentino Sebastian TB1: Apoyó en la revisión cruzada de capítulos y promovió un ambiente inclusivo, asegurando que todas las ideas fueran consideradas. Ccotarma Ttito Sihuar Eduardo Eusebio TB1: Aseguró la integración de los aportes del equipo en las secciones de análisis de usuarios, cumpliendo plazos acordados. Carpio Cornejo Miguel Ángel Jesús TB1: Coordinó la elaboración de diagramas y apartados técnicos, fomentando la colaboración entre todos los integrantes. Gabriel Braithuaite TB1: En base a los objetivos de la primera entrega, planificó las tareas que debía cumplir para aportar al equipo trabajando de manera colaborativa. |
El equipo trabajó de manera organizada y colaborativa, estableciendo metas claras y cumpliendo las tareas asignadas dentro de los plazos establecidos, lo que fortaleció el trabajo conjunto. |
Kamaqlabs es una startup tecnológica enfocada en el desarrollo de soluciones IoT (Internet of Things) para la industria hotelera. Su producto principal, Dedalus IoT, es una plataforma integral que conecta dispositivos inteligentes con aplicaciones web y móviles, permitiendo a los hoteles transformar su operación en espacios inteligentes, seguros y eficientes.
El sistema integra:
-
Gestión Web para Gerentes: creación y administración de habitaciones, reservas, credenciales y monitoreo de dispositivos.
-
Aplicación Móvil para Huéspedes: acceso seguro a su habitación mediante NFC/Bluetooth/tarjetas físicas, control de luces, cortinas, temperatura y pedidos de servicios en tiempo real.
-
Infraestructura IoT: sensores de humo y gas con alertas instantáneas, luces inteligentes con detección de presencia, cerraduras electrónicas y termostatos conectados.
Con este ecosistema, la startup busca cerrar la brecha tecnológica en el sector hotelero peruano y latinoamericano, donde predominan procesos manuales, baja digitalización y poca integración de dispositivos inteligentes.
- Misión
Impulsar la transformación digital del sector hotelero mediante una plataforma IoT accesible y confiable que mejore la seguridad, optimice la eficiencia energética y eleve la experiencia de los huéspedes.
- Visión
Convertirse en la solución IoT hotelera líder en Latinoamérica, reconocida por su capacidad de integrar la gestión operativa con tecnologías inteligentes que generen hoteles sostenibles, rentables y centrados en el cliente.
Propuesta de Valor
-
Para Gerentes: control total de habitaciones y dispositivos en tiempo real, reducción de costos operativos y seguridad reforzada.
-
Para Huéspedes: acceso rápido, seguro y personalizado a su habitación, con ambientes adaptados a sus preferencias.
-
Para el Hotel: un sistema escalable, adaptable y con soporte local que combina la gestión digital con la automatización IoT.
- Dedalus es una plataforma que integra IoT con gestión hotelera digital.
- Permite a los hoteles gestionar reservas, accesos y dispositivos inteligentes desde una sola solución.
- Administradores (Web): creación de habitaciones, gestión de reservas, monitoreo de sensores de humo/gas, control de iluminación y energía.
- Huéspedes (App móvil): apertura de cerraduras con NFC/Bluetooth, personalización del ambiente (luces, cortinas, termostato) y pedidos de servicio.
¿Qué soluciones específicas aporta la aplicación?
- Elimina procesos manuales, centralizando toda la gestión.
- Eleva la seguridad hotelera mediante sensores y accesos digitales.
- Reduce costos energéticos con luces y climatización inteligentes.
- Mejora la experiencia del huésped con automatización personalizada.
- La plataforma puede implementarse en hoteles de todo el Perú y Latinoamérica.
- Especialmente en destinos turísticos con alto flujo (Cusco, Arequipa, Lima, Riviera Maya).
¿Dónde impacta más?
- En hoteles pequeños y medianos que no cuentan con sistemas digitales ni infraestructura tecnológica avanzada.
- Dedalus actúa como un puente entre la informalidad y la profesionalización tecnológica.
- La solución es relevante todo el año.
- Tiene mayor valor en temporadas altas de turismo, cuando la demanda de habitaciones se incrementa.
¿Cuándo surgió la necesidad?
- Tras la pandemia, cuando el turismo se reactivó rápidamente.
- Los hoteles evidenciaron limitaciones tecnológicas para atender la demanda con seguridad y eficiencia.
-
Beneficiarios directos:
- Administradores: control total de reservas y dispositivos desde la web.
- Personal operativo: mayor claridad de tareas y alertas en tiempo real.
- Huéspedes: estancia personalizada, segura y fluida.
-
Quienes enfrentan el problema actualmente:
- Hoteles sin digitalización, con procesos manuales y llaves físicas.
- Establecimientos medianos que no pueden costear soluciones IoT premium internacionales.
- Porque existe una brecha tecnológica: muchos hoteles operan con sistemas manuales o básicos.
- Esto genera errores en reservas, inseguridad en accesos y altos costos de energía.
¿Por qué es importante mejorar la gestión hotelera con IoT?
- Porque la eficiencia operativa y la seguridad son factores clave para la competitividad turística.
- Un hotel inteligente no solo reduce costos, sino que también aumenta la satisfacción y fidelización de los huéspedes.
- Para administradores: panel web con gestión de reservas, monitoreo de sensores, control de dispositivos y seguridad de accesos.
- Para huéspedes: app móvil con acceso seguro a su habitación y control total de su ambiente.
- Integración IoT: dispositivos conectados mediante protocolos seguros (MQTT/REST) que reportan y reciben órdenes en tiempo real.
¿Cómo apoyamos la implementación?
- Brindamos capacitación, soporte técnico y despliegue gradual.
- Incluso hoteles con poca experiencia tecnológica podrán usar el sistema de manera efectiva.
- Modelo de negocio: planes de suscripción mensual por número de habitaciones + costos de instalación inicial de dispositivos IoT.
- Ahorro estimado:
- Hasta 30% en consumo energético con luces y climatización inteligentes.
- Reducción del 80% en errores de reservas y accesos.
- Incremento proyectado de 15–20% en satisfacción y retención de huéspedes.
- El sector hotelero en Perú y Latinoamérica enfrenta problemas de informalidad, baja digitalización y deficiencias en seguridad y eficiencia operativa.
- Los hoteles pequeños y medianos suelen operar con procesos manuales, llaves físicas y sistemas dispersos, lo que genera errores en reservas, pérdidas económicas y experiencias negativas en huéspedes.
- Al mismo tiempo, los huéspedes demandan estancias más seguras, rápidas y personalizadas, en línea con la transformación digital global.
Pregunta clave:
¿Cómo podemos integrar tecnología IoT en la gestión hotelera para mejorar la eficiencia, garantizar la seguridad y ofrecer experiencias personalizadas a los huéspedes?
- El dominio de Dedalus es el sector turístico y hotelero, con enfoque en la automatización inteligente de hoteles.
- Se centra en la conexión de dispositivos IoT (cerraduras, sensores, luces, termostatos, cortinas inteligentes) con aplicaciones digitales (web y móvil).
- El objetivo es profesionalizar los procesos hoteleros, elevar la competitividad y transformar la experiencia de los huéspedes.
- Administradores de hoteles: buscan digitalizar procesos, reducir costos energéticos, controlar accesos y mejorar la seguridad.
- Personal operativo: necesita claridad en las tareas y notificaciones en tiempo real para responder a emergencias o solicitudes.
- Huéspedes: desean accesos rápidos y seguros (NFC/Bluetooth), personalización de la habitación y procesos de check-in/out más fluidos.
-
Administradores:
- Procesos manuales en reservas y accesos.
- Falta de control en consumo energético.
- Baja visibilidad en la seguridad de habitaciones y ambientes.
-
Personal operativo:
- Comunicación deficiente con recepción.
- Alertas poco claras ante incidentes (fugas, incendios, ocupación).
- Duplicidad de tareas y tiempos muertos.
-
Huéspedes:
- Check-in lento y dependiente de llaves físicas.
- Habitaciones poco adaptadas a sus preferencias.
- Baja percepción de seguridad y confianza.
- Actualmente, no existe en el mercado una solución IoT integral que combine:
- Gestión de reservas + automatización de habitaciones + control de accesos + sensores de seguridad.
- Las soluciones existentes (PMS tradicionales, domótica de lujo, integraciones parciales) son costosas, poco accesibles o no adaptadas al contexto hotelero latinoamericano.
- Dedalus llena esta brecha ofreciendo un ecosistema accesible, modular y escalable.
- Visión: construir un ecosistema de hoteles inteligentes que integren seguridad, eficiencia y confort.
- Estrategia:
- Centralizar en una sola plataforma la gestión de reservas, accesos y dispositivos IoT.
- Reducir costos operativos mediante sensores y automatización energética.
- Mejorar la experiencia del huésped con accesos seguros y ambientes personalizados.
- Implementar un modelo escalable y accesible para hoteles pequeños y medianos.
- Los primeros en adoptar serán hoteles independientes y medianos en zonas de alto turismo (Cusco, Arequipa, Lima, Cartagena).
- Estos hoteles carecen de digitalización, pero enfrentan alta demanda turística y están más motivados en modernizar sus servicios.
- Representan el grupo más propenso a adoptar soluciones IoT por su necesidad de:
- Reducir errores en reservas y accesos.
- Mejorar la seguridad.
- Diferenciarse de la competencia informal.
Business Assumptions
- Los hoteles necesitan mejorar eficiencia, seguridad y gestión energética.
- La aplicación IoT que centralice reservas, accesos y dispositivos cubrirá esta necesidad.
- El valor más importante para los clientes será la automatización segura y confiable de sus procesos.
- La adquisición de clientes será principalmente mediante alianzas estratégicas con agencias de turismo, publicidad digital y referencias entre hoteles.
- El modelo de ingresos combinará suscripciones mensuales y instalación inicial de dispositivos IoT.
- La competencia serán PMS internacionales y sistemas de domótica de lujo, a los cuales superaremos con una solución más accesible y contextualizada al mercado local.
- El principal riesgo será la resistencia al cambio tecnológico. Esto se mitigará con capacitaciones y soporte continuo.
- El éxito se medirá en:
- Reducción de errores en reservas y accesos.
- Ahorro energético comprobado.
- Incremento en satisfacción y retención de huéspedes.
User Assumptions
- Usuarios: administradores, personal operativo y huéspedes.
- Problemas resueltos: reservas desorganizadas, accesos inseguros, consumo energético excesivo y mala experiencia de huéspedes.
- Características clave:
- Accesos inteligentes (NFC, Bluetooth, tarjeta).
- Automatización de luces, cortinas y temperatura.
- Reservas y gestión centralizada desde la web.
- Alertas de humo/gas en tiempo real.
- Uso en la vida real:
- Administrador: cada vez que gestiona reservas, controla dispositivos o responde a alertas.
- Huésped: cada vez que abre su habitación, personaliza el ambiente o solicita un servicio.
- Expectativas:
- Interfaz intuitiva.
- Seguridad y confiabilidad.
- Experiencia rápida y sin fricciones.
-
Administradores:
- Control total sobre reservas y accesos.
- Monitoreo en tiempo real de sensores y dispositivos.
- Ahorro energético comprobado.
-
Huéspedes:
- Acceso rápido y seguro.
- Ambientes personalizados durante su estancia.
- Experiencia confiable y sin complicaciones.
-
Personal operativo:
- Tareas claras y en tiempo real.
- Alertas automáticas para responder a incidentes.
- Menos tiempos muertos y duplicidad de esfuerzos.
- Reducción de errores en reservas y accesos en un 80%.
- Ahorro de 30% en consumo energético promedio.
- Incremento de 15–20% en satisfacción y retención de huéspedes.
- Formalización y escalabilidad del hotel, permitiendo certificaciones y alianzas.
- Gestión de reservas y accesos: reservas en línea, credenciales digitales autodestructivas al hacer check-out.
- Automatización inteligente: luces con detección de movimiento, termostatos regulados automáticamente, cortinas inteligentes.
- Seguridad reforzada: sensores de humo y gas con alertas inmediatas al sistema.
- Experiencia huésped: aplicación móvil para pedidos, control de ambiente y acceso seguro.
-
Hipótesis 1 — Acceso sin llaves (NFC/Bluetooth)
- Creemos que, al implementar credenciales móviles (NFC/Bluetooth) con revocación automática en checkout, reduciremos el tiempo de check-in y acceso a habitaciones para los huéspedes.
- Sabremos que hemos tenido éxito cuando el tiempo medio de check-in disminuya ≥ 60% y los incidentes por llaves extraviadas bajen ≥ 90% durante los primeros 3 meses post-lanzamiento.
-
Hipótesis 2 — Seguridad IoT (sensores de humo/gas)
- Creemos que, al integrar sensores de humo y gas con alertas en tiempo real hacia la API y panel web, mejoraremos la detección temprana de incidentes y la respuesta operativa.
- Sabremos que hemos tenido éxito cuando el tiempo de detección-a-alerta sea < 5 s, y el tiempo de atención de alertas críticas (p95) se reduzca ≥ 40% en 90 días.
-
Hipótesis 3 — Ahorro energético (luces + termostato + ocupación)
- Creemos que, al automatizar iluminación y climatización mediante detección de presencia y escenas eco, disminuiremos el consumo energético por habitación-noche.
- Sabremos que hemos tenido éxito cuando el kWh/hab-noche baje ≥ 25–35% y el tiempo con luces encendidas en habitaciones desocupadas se reduzca ≥ 70% dentro de los primeros 4 meses.
-
Hipótesis 4 — Automatización de ambiente (luces, cortinas, termostato)
- Creemos que, al permitir al huésped personalizar su ambiente desde la app, incrementaremos la satisfacción de la estancia y la percepción de confort.
- Sabremos que hemos tenido éxito cuando el NPS suba ≥ +15 puntos y la puntuación de “confort de la habitación” en encuestas in-app aumente ≥ 20% en 3 meses.
-
Hipótesis 5 — Reservas web (administración)
- Creemos que, al centralizar reserva/cancelación/modificación en la web del gerente con validaciones y calendario, reduciremos errores operativos y sobreasignaciones.
- Sabremos que hemos tenido éxito cuando los errores de reserva disminuyan ≥ 80% y el tiempo de gestión por reserva baje ≥ 50% en los primeros 2 sprints.
-
Hipótesis 6 — IAM unificado (web y móvil)
- Creemos que, al implementar registro de hotel (post-pago), validación/edición/recuperación de credenciales y RBAC, disminuiremos fricciones de acceso al sistema y mejoraremos la seguridad.
- Sabremos que hemos tenido éxito cuando la tasa de incidencias por credenciales caiga ≥ 70% y el tiempo de recuperación de cuenta sea < 2 min en 3 meses.
-
Hipótesis 7 — Pedidos a habitación (in-app)
- Creemos que, al habilitar pedidos y servicios desde la app del huésped, aumentaremos el consumo de amenities y el ingreso por upselling.
- Sabremos que hemos tenido éxito cuando el ingreso por servicios complementarios/hab-noche crezca ≥ 10–15% y el tiempo de atención de pedidos (p50) se reduzca ≥ 30% en 90 días.
-
Hipótesis 8 — Operación y respuesta (housekeeping/mantenimiento)
- Creemos que, al orquestar alertas IoT hacia tareas operativas (luces encendidas, ventana abierta, fuga), aceleraremos los tiempos de resolución y reduciremos reprocesos.
- Sabremos que hemos tenido éxito cuando el MTTR (tiempo medio de resolución) baje ≥ 40% y los reingresos por la misma incidencia disminuyan ≥ 50% durante los primeros 3 meses.
- Mediante la realizacion Lean UX Canvas podemos mostrar toda informacion anterior pero de una manera resumida, didactica y mas accesible al lector. Tambien se resume la problematica que estamos abordando y la solucion que proponemos, junto con los supuestos de las hipotesis y los puntos mas importantes de las mismas.
- Perfil:
Propietarios y administradores de hoteles pequeños y medianos, así como gerentes de operaciones en cadenas hoteleras. - Necesidades principales:
- Control centralizado de reservas y habitaciones.
- Monitoreo de dispositivos IoT (sensores de humo/gas, iluminación, climatización).
- Reducción de costos energéticos y operativos.
- Seguridad reforzada en accesos a habitaciones y áreas comunes.
- Reportes en tiempo real para toma de decisiones.
- Expectativas:
- Disminuir errores de reserva y sobreasignación.
- Obtener visibilidad en tiempo real de lo que ocurre en el hotel.
- Profesionalizar la gestión, integrando tecnología sin depender de sistemas costosos o extranjeros.
- Beneficios esperados:
- Ahorro energético (≥ 30%) con automatización de luces y climatización.
- Reducción de errores en reservas (≥ 80%) mediante validaciones digitales.
- Mayor seguridad con registros de accesos y credenciales digitales.
- Perfil:
Viajeros nacionales e internacionales que buscan una experiencia hotelera personalizada, rápida y segura. - Necesidades principales:
- Check-in ágil y sin llaves físicas.
- Control de su habitación desde el móvil (luces, cortinas, temperatura).
- Acceso seguro con NFC/Bluetooth o tarjeta física.
- Posibilidad de hacer pedidos o solicitar servicios desde la app.
- Expectativas:
- Procesos de check-in/out en segundos.
- Habitaciones personalizadas según sus preferencias (ejemplo: temperatura a 22 °C, cortinas cerradas al dormir).
- Comunicación rápida con el hotel sin depender de llamadas a recepción.
- Beneficios esperados:
- Mayor satisfacción (NPS +15 puntos) gracias a experiencias personalizadas.
- Seguridad y confianza en el acceso a la habitación.
- Comodidad en la estancia mediante automatización IoT y servicios bajo demanda.
IoT Hotel Management se diferencia de competidores como Cloudbeds, Opera PMS y Control4 al integrar la gestión hotelera tradicional con un ecosistema IoT accesible y escalable. Mientras que Opera PMS es robusto y orientado a grandes cadenas con altos costos de implementación, y Cloudbeds facilita la gestión de reservas pero carece de integración con dispositivos inteligentes, Control4 ofrece soluciones de domótica premium enfocadas en el lujo residencial más que en el sector hotelero. En cambio, IoT Hotel Management combina la digitalización de reservas y accesos con la automatización de luces, cortinas, termostatos y sensores de seguridad, brindando a los hoteles pequeños y medianos una solución integral, económica y contextualizada, que mejora la eficiencia operativa y eleva la experiencia personalizada del huésped.
Para diferenciarse en un mercado competitivo donde destacan soluciones como Cloudbeds, Opera PMS, RoomRaccoon o plataformas de domótica premium (Control4, Lutron), IoT Hotel Management plantea una estrategia basada en accesibilidad, integración IoT y soporte local.
-
Accesibilidad económica:
Ofrecer planes de suscripción escalables adaptados al tamaño del hotel, junto con precios competitivos en la instalación de dispositivos IoT. -
Soporte y capacitación local:
Acompañar la implementación con soporte en español, entrenamientos virtuales y presenciales, y guías de buenas prácticas, minimizando la resistencia al cambio tecnológico. -
Experiencia integral IoT:
Diferenciarse integrando en una sola plataforma:- Reservas web.
- Accesos inteligentes (NFC/Bluetooth).
- Sensores de humo y gas con alertas.
- Automatización de luces, cortinas y termostatos.
-
Escalabilidad:
Permitir que hoteles pequeños empiecen con un número reducido de habitaciones conectadas e incrementen el alcance de forma gradual sin necesidad de migrar a otra plataforma. -
Estrategia de marca y marketing:
Posicionarse como la primera plataforma IoT accesible para hoteles en Latinoamérica, resaltando la reducción de costos energéticos, la seguridad reforzada y la mejora en la experiencia del huésped.
-
Partnerships estratégicos:
Colaboración con proveedores de hardware IoT (cerraduras, sensores, iluminación inteligente) para reducir costos de integración. -
Campañas digitales segmentadas:
Promoción en LinkedIn y Facebook Ads enfocada en administradores hoteleros y propietarios de hoteles independientes. -
Casos de éxito locales:
Mostrar pilotos y hoteles que ya han reducido costos y mejorado la satisfacción de huéspedes tras la implementación. -
Marketing de contenidos:
Publicación de artículos, webinars y talleres sobre beneficios de la hotelería inteligente (ahorro energético, seguridad, eficiencia operativa). -
Expansión progresiva:
Iniciar en mercados turísticos clave (Cusco, Arequipa, Lima, Cartagena) y luego escalar a otros países de la región, validando métricas de éxito en cada etapa.
Categoría | Preguntas |
---|---|
Edad y género |
- ¿Podrías indicarme tu edad y género? - ¿Crees que tu edad influye en la forma en que gestionas un hotel? |
Ubicación del hotel |
- ¿En qué ciudad o región se encuentra tu hotel? - ¿Cómo influye la ubicación del hotel en la estrategia de gestión y reservas? |
Experiencia en el sector hotelero |
- ¿Cuántos años de experiencia tienes en la gestión hotelera? - ¿Cómo ha cambiado tu enfoque de gestión con el tiempo? |
Categoría | Preguntas |
---|---|
Motivaciones y objetivos |
- ¿Qué te motiva en la gestión de un hotel y cuáles son tus principales objetivos (e.g., maximización de ocupación, satisfacción del cliente, etc.)? - ¿Cómo evalúas el éxito de tu gestión hotelera? |
Herramientas y plataformas |
- ¿Qué sistemas o plataformas utilizas para gestionar reservas y operaciones hoteleras? - ¿Has probado alguna solución integrada para la gestión hotelera? ¿Cuál ha sido tu experiencia? |
Retos y frustraciones |
- ¿Cuáles son los principales desafíos que enfrentas en la gestión hotelera? - ¿Cómo abordas estos desafíos? ¿Hay alguna área específica donde sientas que necesitas más apoyo o mejores herramientas? |
Expectativas tecnológicas |
- ¿Qué características tecnológicas consideras esenciales en un sistema de gestión hotelera? - ¿Qué te gustaría que una plataforma como IoT Hotel Management mejorara o incluyera para facilitar la gestión de tu hotel? |
Categoría | Preguntas |
---|---|
Edad y género |
- ¿Podrías indicarme tu edad y género? - ¿En qué rango de edad sueles realizar más reservas? |
Distrito de residencia |
- ¿En qué distrito o ciudad resides actualmente? - ¿Prefieres realizar reservas cerca de tu residencia o estás dispuesto a viajar? |
Ocupación |
- ¿Cuál es tu ocupación actual? - ¿Tu ocupación influye en la frecuencia con la que realizas reservas? |
Categoría | Preguntas |
---|---|
Tipos de reservas preferidos |
- ¿Qué tipo de servicios sueles reservar con mayor frecuencia (restaurantes, hoteles, eventos, etc.)? - ¿Qué aspectos consideras al realizar una reserva (ubicación, precio, reputación, etc.)? |
Experiencia en reservas |
- ¿Qué es lo que más valoras al realizar una reserva? - ¿Hay algún aspecto que te haya frustrado o decepcionado en reservas anteriores? |
Uso de plataformas para realizar reservas |
- ¿Qué plataformas o métodos usas para realizar reservas? - ¿Prefieres realizar tus reservas en línea o en persona? ¿Por qué? |
Interacción con la tecnología |
- ¿Qué tan cómodo te sientes usando aplicaciones móviles o plataformas web para buscar y realizar reservas? - ¿Qué características tecnológicas te gustaría ver en una plataforma que gestione reservas? |
Comunicación con proveedores de servicios |
- ¿Qué tan importante es para ti recibir actualizaciones o notificaciones del proveedor antes y durante el servicio reservado? - ¿Te gustaría tener la opción de comunicarte directamente con el proveedor a través de la plataforma? |
Categoría | Pregunta |
---|---|
Pregunta Final | - ¿Hay algo más que consideras importante compartir sobre tu experiencia como organizador o usuario de reservas? |
Datos del entrevistado |
---|
Nombre: Gael Dario Lopez Diaz |
Link del video: Entrevista1 |
Edad: 20 años |
Procedencia: Lima, Ate |
![]() |
Resumen: . Gael Dario Lopez es un joven estudiante de 20 años que suele ir a hoteles y nos menciona que en lo que se fija para escoger un hotel se fija en la atención y respuesta rapida a la hora de reservar lo que le hace valorar un hotel de acuerdo al trato que reciba , sugiere que podriamos implementar la atención de llamada a la hora de realizar reserva |
Datos del entrevistado |
---|
Nombre: Jose Shuan Saavedra |
Minuto del video: Entrevista2 |
Edad: 20 años |
Procedencia: Lima, Lima |
![]() |
Resumen: Jose Shuan Saavedra es un estudiante de 24 años nos menciona que valora en un hotel la atención y trato que le dan al cliente , como sugerencia que puedas ver notificaciones por alguna promoción o descuento que se llegue a dar en el hotel |
Datos del entrevistado |
---|
Nombre: Gino Tineo |
Edad: 21 años |
Link del video: Entrevista4 |
Procedencia: Lima |
![]() |
Resumen: Gino Tineo es un joven Gestor Hotelero de 21 años el considera que su edad si influye para gestionar un hotel porque aún no tiene tanta experiencia y nos menciona que tiene una herramienta tecnologica para su hotel pero esta no es tan especializada y su principal desafio es que su pagina web ayude a automatizar los procesos de pedido de reserva y que gestione las redes sociales de su empresa |
Datos del entrevistado |
---|
Nombre: Mauricio Muñoz |
Edad: 21 años |
Link del video: Entrevista5 |
Procedencia: Perú |
![]() |
Resumen: Nauricio Muñoz es un Gestor Hotelero de 21 años el considera que su edad si influye a la hora de gestionar un hotel ademas nos menciona que si utiliza herramientas tecnologicas para gestionar su hotel sin embargo le gusta usar metodos tradicionales como lapiz y papel porque se siente más familiarizado y su principal desafio que ha enfrentado es la comunicación con el staff . |
Después de llevar a cabo y describir los registros de los entrevistados, esta sección desarrollará una estrategia conjunta que permitirá al equipo identificar ciertos aspectos y puntos en común. Este análisis ayudará a obtener una visión más analítica y concreta sobre el desarrollo de la aplicación IoT Hotel Management.
-
Tipo de Reserva y Preferencias
- Tipo de Reserva: El 70% de los huéspedes prefieren realizar reservas en línea utilizando plataformas como Airbnb y Booking.
- Preferencias: Valoran principalmente el precio, la ubicación y las opiniones de otros usuarios. La comodidad del smartphone para hacer reservas es una ventaja clave.
-
Prioridades al Reservar
- Principales Prioridades: Según el 90%, los huéspedes buscan precios competitivos, ubicaciones convenientes y transparencia en las tarifas adicionales. También valoran la posibilidad de recibir notificaciones y tener opciones de personalización.
-
Herramientas Actuales
- Herramientas Utilizadas: El 60% usa plataformas en línea como Airbnb, mientras que el 40% utiliza aplicaciones como Booking para gestionar sus reservas.
-
Características Deseadas en la Aplicación
- Características Deseadas: El 60% de los usuarios desean opciones avanzadas de personalización, recordatorios automáticos y mayor transparencia en tarifas. También consideran importante la integración de chat en vivo y recomendaciones basadas en inteligencia artificial.
-
Desafíos y Prioridades en la Gestión
- Desafíos Actuales: El 65% de los administradores de hoteles enfrentan dificultades con la falta de integración entre plataformas de gestión y la coordinación del personal.
- Prioridades: Valoran la eficiencia operativa y la capacidad de manejar múltiples tareas simultáneamente, como la asignación de habitaciones y la gestión de reservas.
-
Uso de Herramientas Actuales
- Herramientas Utilizadas: El 70% utiliza varias plataformas de gestión hotelera pero encuentra que la falta de integración es un problema significativo.
-
Características Deseadas en la Plataforma
- Características Deseadas: El 60% de los administradores busca implementar inteligencia artificial para optimizar la asignación de habitaciones y gestionar solicitudes en tiempo real. También desean actualizaciones en tiempo real y opciones de comunicación directa con los huéspedes.
-
Objetivos al Usar la Aplicación
- Objetivos: El 100% espera que la aplicación les ayude a mejorar la eficiencia operativa y optimizar la gestión de reservas y eventos, además de proporcionar una mejor comunicación con los huéspedes y clientes.
![image]assets/User%20Persona%20Huesped.png)
![María Delia Martínez]assets/User%20persona%20Admin.png)
En esta sección se presenta el user task matrix, que es una herramienta que nos permite identificar las tareas más importantes y frecuentes que realizan los User Personas en su entorno laboral. A través de esta matriz, podemos comparar y contrastar las tareas realizadas por los gerentes y los trabajadores, identificando las diferencias y similitudes en términos de frecuencia e importancia. Esto nos ayuda a comprender mejor las necesidades y desafíos de nuestros usuarios y a priorizar las características y funcionalidades de nuestro producto en función de sus tareas críticas.
Tareas | Frecuencia (Admin) | Importancia (Admin) | Frecuencia (Huésped) | Importancia (Huésped) |
---|---|---|---|---|
Gestionar reservas de huéspedes | Alta | Alta | - | - |
Coordinar y asignar tareas al personal | Media | Alta | - | - |
Automatizar la facturación | Media | Media | - | - |
Monitorear rendimiento de operaciones | Alta | Alta | - | - |
Controlar accesos digitales (NFC/Bluetooth) | Alta | Alta | Media | Alta |
Buscar y comparar opciones de alojamiento | - | - | Alta | Alta |
Realizar reservas en línea | - | - | Alta | Alta |
Personalizar experiencia de estancia | - | - | Media | Alta |
Recibir notificaciones y actualizaciones | - | - | Alta | Media |
Comunicarse con el hotel | - | - | Media | Alta |
-
Tareas con mayor frecuencia e importancia:
- Para los gestores de hoteles, las tareas más frecuentes e importantes son "Gestionar reservas de huéspedes" y "Monitorear rendimiento de operaciones", ya que estas son críticas para la operación diaria y la satisfacción del cliente.
- Para los viajeros, las tareas más frecuentes e importantes son "Buscar y comparar opciones de alojamiento" y "Realizar reservas en línea", dado que son esenciales para planificar y asegurar sus viajes.
-
Principales diferencias:
- Los gestores de hotel se centran en la administración y eficiencia operativa.
- Los viajeros se enfocan en la personalización y conveniencia de la experiencia de alojamiento.
-
Coincidencias:
- Ambos segmentos valoran la comunicación eficiente y la automatización para mejorar la experiencia general.
![image]assets/User%20Journey%20Mapping%20Huesped.png)
![image]assets/User%20Journey%20Mapping%20Admin.png)
![Huesped empathy map]assets/Empathy%20map%20Huesped.png)
![Hotel empathy map]assets/Empathy%20map%20Admin.png)
![Event storming]assets/Big%20Picture%20Eventstorming.jpg)
Link Miro: https://miro.com/app/board/uXjVJF6ySiI=/?share_link_id=547814286151
Storytelling:
Imagina que eres un huésped que decide hospedarse en un hotel gestionado por Kamaqlabs.
Desde tu casa, haces una reserva en línea a través de la plataforma web del hotel. El administrador revisa la solicitud y confirma la reserva. El sistema genera automáticamente una credencial digital para acceso a tu habitación, y la envía junto con una invitación a tu correo o app.
Días después, llegas al hotel. Al acercarte a la recepción, inicias el check‑in express desde tu celular. El sistema valida tu identidad, verifica la reserva, y completa el check‑in.
Te diriges a tu habitación y, al acercar tu celular a la cerradura, la puerta se abre mediante NFC. Apenas entras, los sensores de movimiento activan la luz. La temperatura se ajusta sola, porque el sistema reconoce tus preferencias anteriores.
Durante tu estadía, haces un pedido de servicio de habitación desde la app. Pero de repente, un sensor detecta humo en un área cercana. Se envía una alerta crítica al panel del administrador y se notifica al personal operativo. El personal es asignado, se dirige al lugar y resuelve el incidente rápidamente.
Finalmente, decides partir. Desde tu móvil, inicias el check‑out, el cual se completa sin pasar por recepción. Las credenciales de acceso se revocan automáticamente.
Término (Inglés) | Término (Español) | Definición |
---|---|---|
Reservation | Reserva | Proceso mediante el cual un huésped asegura una habitación en el hotel para una fecha específica. |
Check-in | Registro de entrada | Proceso de recepción y registro de un huésped en el hotel al inicio de su estancia. |
Check-out | Registro de salida | Proceso de salida y finalización de la estancia de un huésped en el hotel. |
Guest | Huésped | Persona que se aloja en el hotel. |
Room Service | Servicio de habitaciones | Servicio proporcionado por el hotel para entregar alimentos y bebidas directamente a la habitación del huésped. |
Housekeeping | Limpieza | Departamento encargado de la limpieza y mantenimiento de las habitaciones y áreas comunes del hotel. |
Front Desk | Recepción | Área del hotel donde se realizan las funciones de check-in, check-out y atención al cliente. |
Occupancy Rate | Tasa de ocupación | Porcentaje de habitaciones ocupadas en el hotel en un período de tiempo específico. |
No-show | No presentación | Situación en la que un huésped no se presenta para su reserva sin haberla cancelado previamente. |
Overbooking | Sobreventa | Práctica de aceptar más reservas de las que hay disponibles, anticipando que algunas reservas no se presentarán. |
Revenue Management | Gestión de ingresos | Estrategia para optimizar los ingresos del hotel mediante el ajuste de precios y la gestión de la disponibilidad de habitaciones. |
Conference Room | Sala de conferencias | Espacio en el hotel destinado a reuniones y eventos corporativos. |
Las User Stories son una herramienta fundamental para definir los requisitos del proyecto. Cada User Story incluye criterios de aceptación que deben ser comprobables y redactados en tiempo presente, tercera persona, siguiendo la estructura de Gherkin (Given-When-Then). Además, se consideran User Stories para el sitio web estático (Landing Page) y Technical Stories para los features del RESTful API.
- EPIC001 – Gestión de Habitaciones y Reservas
- EPIC002 – Accesos Seguros e IoT (cerraduras, credenciales NFC/Bluetooth)
- EPIC003 – Automatización de Ambiente (luces, cortinas, termostato)
- EPIC004 – Seguridad y Sensores Inteligentes (humo, gas, notificaciones)
- EPIC005 – Creación de la Landing Page
Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) |
---|---|---|---|---|
US001 | Crear habitación | Como administrador, quiero crear habitaciones en el sistema, para gestionar disponibilidad. | Dado que el administrador accede al panel web, cuando selecciona "Crear Habitación", entonces el sistema debe registrar la nueva habitación con los datos ingresados. | EPIC001 |
US002 | Editar habitación | Como administrador, quiero editar habitaciones, para actualizar datos como tipo o estado. | Dado que el administrador selecciona una habitación existente, cuando actualiza los campos, entonces el sistema debe guardar los cambios correctamente. | EPIC001 |
US003 | Eliminar habitación | Como administrador, quiero eliminar habitaciones, para mantener actualizado el inventario. | Dado que el administrador selecciona una habitación, cuando confirma la eliminación, entonces esta debe desaparecer de la lista. | EPIC001 |
US004 | Crear/gestionar reservas | Como administrador, quiero crear, modificar y cancelar reservas, para evitar sobreasignaciones. | Dado que el administrador accede al módulo de reservas, cuando gestiona una reserva, entonces el sistema debe reflejar el cambio en la disponibilidad. | EPIC001 |
US005 | Reporte de ocupación | Como administrador, quiero ver un reporte de ocupación de habitaciones, para optimizar la gestión. | Dado que el administrador solicita el reporte, cuando se genera, entonces debe mostrar porcentaje de ocupación y reservas activas. | EPIC001 |
Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) |
---|---|---|---|---|
US006 | Acceso con NFC | Como huésped, quiero abrir mi habitación con NFC, para ingresar sin usar llave física. | Dado que el huésped tiene credenciales válidas, cuando acerca el móvil al lector, entonces la cerradura debe abrirse. | EPIC002 |
US007 | Acceso con Bluetooth | Como huésped, quiero abrir mi habitación con Bluetooth, para acceder sin tarjeta. | Dado que el huésped tiene acceso activo, cuando se conecta vía Bluetooth, entonces el sistema debe desbloquear la cerradura. | EPIC002 |
US008 | Uso de tarjeta física | Como huésped, quiero usar tarjeta física, para entrar en caso de no tener NFC/Bluetooth. | Dado que el huésped recibe tarjeta física, cuando la desliza en la cerradura, entonces debe abrirse la puerta. | EPIC002 |
US009 | Revocación de acceso en checkout | Como administrador, quiero que los accesos digitales se revocan en checkout, para garantizar seguridad. | Dado que el huésped hace checkout, cuando finaliza su estancia, entonces el sistema debe desactivar sus credenciales. | EPIC002 |
US010 | Registro de accesos | Como administrador, quiero ver un historial de accesos, para auditar la seguridad. | Dado que el administrador accede al panel, cuando consulta accesos, entonces el sistema debe mostrar fecha, hora y método de entrada. | EPIC002 |
Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) |
---|---|---|---|---|
US011 | Control de luces | Como huésped, quiero encender y apagar las luces desde la app, para ajustar el ambiente. | Dado que el huésped accede a la app, cuando activa o desactiva las luces, entonces el cambio debe reflejarse en la habitación. | EPIC003 |
US012 | Control de cortinas | Como huésped, quiero abrir o cerrar cortinas desde la app, para personalizar la iluminación. | Dado que el huésped está en la app, cuando selecciona "Abrir/Cerrar Cortinas", entonces estas deben responder en tiempo real. | EPIC003 |
US013 | Control de temperatura | Como huésped, quiero regular el termostato desde la app, para tener confort climático. | Dado que el huésped accede al control, cuando ajusta la temperatura, entonces el termostato debe actualizarse. | EPIC003 |
US014 | Escena de bienvenida | Como administrador, quiero que al check-in se activen luces y clima, para recibir al huésped. | Dado que se activa un check-in, cuando el huésped ingresa, entonces el sistema debe aplicar la escena configurada. | EPIC003 |
US015 | Escena de ahorro energético | Como administrador, quiero que luces y clima se apaguen al detectar desocupación, para reducir costos. | Dado que no se detecta ocupación, cuando la habitación queda vacía, entonces el sistema debe apagar luces y climatización. | EPIC003 |
Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) |
---|---|---|---|---|
US016 | Detección de humo | Como administrador, quiero recibir alertas de humo, para actuar rápidamente. | Dado que un sensor detecta humo, cuando se activa, entonces el sistema debe enviar alerta inmediata al panel y app. | EPIC004 |
US017 | Detección de gas | Como administrador, quiero recibir alertas de gas, para evitar emergencias. | Dado que un sensor detecta gas, cuando el nivel es alto, entonces debe generar alerta inmediata. | EPIC004 |
US018 | Notificación en tiempo real | Como huésped, quiero recibir notificaciones de seguridad, para sentirme protegido. | Dado que ocurre un incidente, cuando se emite una alerta, entonces el huésped debe recibir notificación push en su app. | EPIC004 |
US019 | Registro histórico de alertas | Como administrador, quiero consultar historial de alertas, para tener trazabilidad. | Dado que accedo al módulo de seguridad, cuando pido historial, entonces el sistema debe mostrar fecha, tipo y respuesta. | EPIC004 |
US020 | Integración con tareas de staff | Como administrador, quiero que alertas IoT generen tareas automáticas, para acelerar la respuesta. | Dado que se activa una alerta, cuando esta se recibe, entonces debe asignarse una tarea al personal correspondiente. | EPIC004 |
Story ID | Título | Descripción | Criterios de Aceptación | Relacionado con (Epic ID) |
---|---|---|---|---|
US021 | Página inicial | Como visitante, quiero ver la página inicial, para obtener una visión general del sistema. | Dado que accedo al sitio, cuando cargo la landing, entonces debe mostrar una introducción clara al producto. | EPIC005 |
US022 | Sección de características | Como visitante, quiero ver las características del sistema, para entender sus beneficios. | Dado que accedo a la sección, cuando navego en la landing, entonces debo visualizar lista de features clave. | EPIC005 |
US023 | Sección de contacto | Como visitante, quiero enviar un mensaje desde la landing, para solicitar más información. | Dado que completo el formulario, cuando lo envío, entonces el sistema debe registrar el mensaje y confirmarlo. | EPIC005 |
US024 | Sección de planes | Como visitante, quiero ver los planes de suscripción, para conocer opciones de precios. | Dado que accedo a "Planes", cuando se muestra la sección, entonces debe listar los precios y modalidades disponibles. | EPIC005 |
US025 | Llamada a la acción (CTA) | Como visitante, quiero tener un botón de "Solicitar Demo", para pedir una prueba del sistema. | Dado que accedo a la landing, cuando hago clic en CTA, entonces debe redirigirme al formulario de demo. | EPIC005 |
Orden | User Story | Título | Descripción | Story Points |
---|---|---|---|---|
1 | US001 | Crear habitación | Como administrador, quiero crear habitaciones en el sistema, para gestionar disponibilidad. | 3 |
2 | US002 | Editar habitación | Como administrador, quiero editar habitaciones, para actualizar datos como tipo o estado. | 2 |
3 | US003 | Eliminar habitación | Como administrador, quiero eliminar habitaciones, para mantener actualizado el inventario. | 2 |
4 | US004 | Gestionar reservas | Como administrador, quiero crear, modificar y cancelar reservas, para evitar sobreasignaciones. | 5 |
5 | US005 | Reporte de ocupación | Como administrador, quiero ver un reporte de ocupación de habitaciones, para optimizar la gestión. | 3 |
6 | US006 | Acceso con NFC | Como huésped, quiero abrir mi habitación con NFC, para ingresar sin usar llave física. | 5 |
7 | US007 | Acceso con Bluetooth | Como huésped, quiero abrir mi habitación con Bluetooth, para acceder sin tarjeta. | 5 |
8 | US008 | Uso de tarjeta física | Como huésped, quiero usar tarjeta física, para entrar en caso de no tener NFC/Bluetooth. | 2 |
9 | US009 | Revocación de acceso en checkout | Como administrador, quiero que los accesos digitales se revocan en checkout, para garantizar seguridad. | 3 |
10 | US010 | Registro de accesos | Como administrador, quiero ver un historial de accesos, para auditar la seguridad. | 3 |
11 | US011 | Control de luces | Como huésped, quiero encender y apagar las luces desde la app, para ajustar el ambiente. | 3 |
12 | US012 | Control de cortinas | Como huésped, quiero abrir o cerrar cortinas desde la app, para personalizar la iluminación. | 3 |
13 | US013 | Control de temperatura | Como huésped, quiero regular el termostato desde la app, para tener confort climático. | 5 |
14 | US014 | Escena de bienvenida | Como administrador, quiero que al check-in se activen luces y clima, para recibir al huésped. | 3 |
15 | US015 | Escena de ahorro energético | Como administrador, quiero que luces y clima se apaguen al detectar desocupación, para reducir costos. | 5 |
16 | US016 | Detección de humo | Como administrador, quiero recibir alertas de humo, para actuar rápidamente. | 5 |
17 | US017 | Detección de gas | Como administrador, quiero recibir alertas de gas, para evitar emergencias. | 5 |
18 | US018 | Notificación en tiempo real | Como huésped, quiero recibir notificaciones de seguridad, para sentirme protegido. | 3 |
19 | US019 | Registro histórico de alertas | Como administrador, quiero consultar historial de alertas, para tener trazabilidad. | 3 |
20 | US020 | Integración de alertas con tareas de staff | Como administrador, quiero que alertas IoT generen tareas automáticas, para acelerar la respuesta. | 5 |
21 | US021 | Página inicial de la landing page | Como visitante, quiero ver la página inicial, para obtener una visión general del sistema. | 2 |
22 | US022 | Sección de características de la landing | Como visitante, quiero ver las características del sistema, para entender sus beneficios. | 2 |
23 | US023 | Sección de contacto en la landing | Como visitante, quiero enviar un mensaje desde la landing, para solicitar más información. | 3 |
24 | US024 | Sección de planes de la landing | Como visitante, quiero ver los planes de suscripción, para conocer opciones de precios. | 2 |
25 | US025 | Llamada a la acción (CTA – Solicitar demo) | Como visitante, quiero tener un botón de "Solicitar Demo", para pedir una prueba del sistema. | 2 |
Para abordar la complejidad de un sistema orientado a la gestión integral de operaciones hoteleras, se aplicó el enfoque de Domain-Driven Design a nivel estratégico. Este enfoque nos permitió identificar los distintos subconjuntos funcionales del sistema o Bounded Contexts que reflejan las áreas clave de negocio de nuestros usuarios objetivos: cadenas hoteleras, hoteles boutique y resorts.
El proceso se desarrolló mediante herramientas colaborativas como Event Storming y el Bounded Context Canvas.
Con el objetivo de comprender en profundidad el dominio del problema, se llevó a cabo una sesión de EventStorming. Con esta dinámica se pudieron identificar eventos clave dentro del negocio hotelero, facilitando la visualización de procesos críticos desde la reserva hasta la atención post-estadía del huésped, entre otros puntos de contacto. Esta actividad no solo ayudó a identificar los eventos, sino que también permitió descubrir las interacciones entre ellos y cómo se relacionan con los distintos actores involucrados.
Objetivo de la sesión: El objetivo de la sesión fue identificar los eventos clave del dominio del problema, así como los actores involucrados y sus interacciones. A través de esta actividad, se buscó obtener una comprensión profunda del negocio hotelero y sus procesos críticos. Durante una sesión de aproximadamente 1 hora y 30 minutos, se desarrollaron las siguientes actividades:
- Identificación de eventos: Se identificaron los eventos clave del dominio del problema, como "Reserva de habitación", "Check-in", "Check-out", entre otros. Estos eventos fueron representados en post-its de color naranja, lo que facilitó su visualización y comprensión.
- Identificación de actores: Se identificaron los actores involucrados en el proceso, como "Huésped" y "Gerente de hotel".
- Interacciones entre eventos y actores: Se establecieron las interacciones entre los eventos y los actores, lo que permitió visualizar cómo se relacionan y cómo influyen en el proceso general del negocio hotelero.
- Identificación de comandos y agregados: Se identificaron los comandos y agregados asociados a cada evento, lo que permitió comprender cómo se gestionan los datos y las acciones dentro del sistema.
Herramienta utilizada: Para esta sesión se empleó Miro, una herramienta colaborativa que permite crear diagramas y visualizar procesos de manera efectiva. Esta herramienta facilitó la colaboración entre los participantes y permitió documentar de manera clara y concisa los resultados de la sesión.
Link del Miro: https://miro.com/app/board/uXjVJG7btVM=/
En esta figura se puede observar el resultado de la sesión de EventStorming, donde el equipo identificó los eventos clave del dominio del problema, los actores involucrados y sus interacciones.
En esta sección se muestra como se llevó a cabo una sesión de Candidate Context Discovery con el fin de identificar los posibles Bounded Contexts que estructurarán estratégicamente la solución
Objetivo de la sesión: La sesión tuvo como finalidad analizar los eventos, comandos y actores identificados previamente para determinar los límites dentro del sistema.
Técnica utilizada: Look-For-Pivotal-Events
Se destacaron eventos de negocio que marcan cambios de estado significativos:
“Reserva confirmada” (transición de cliente interesado a huésped)
“Check-in completado” (inicio del proceso operativo interno)
“Check-out completado” (cierre del ciclo de atención)
Herramienta utilizada: Para esta sesión también se utilizó Lucidchart, para que de manera colaborativa el equipo pueda crear diagramas y visualizar procesos de manera efectiva.
Figura 2:
En esta figura se puede observar el resultado de la sesión de Candidate Context Discovery, donde el equipo utilizó las técnicas start-with value, start-with-simple y look-for-pivotal-events.
Una vez definidos los Bounded Contexts principales, se procedió a modelar los flujos de colaboración entre ellos mediante la técnica de Domain Storytelling.
Figura 3:
Esta figura muestra el flujo de colaboración entre el huésped y el sistema de reservas al momento de realizar una reserva. El proceso inicia con la solicitud del huésped, seguida por la verificación de disponibilidad y la confirmación de la reserva por parte del sistema. Posteriormente, se genera un registro de reserva.
Figura 4:
Esta figura ilustra el flujo de Gestión de Usuarios, donde se observa la interacción entre el sistema y el usuario al ingresar a la plataforma. El proceso incluye la autenticación del usuario, la verificación de sus credenciales y la gestión de su perfil.
Figura 5:
Esta figura representa el flujo de Gestión de Pagos y Suscripciones, donde se observa la interacción entre el sistema y el usuario al momento de realizar un pago. El proceso incluye la selección del método de pago, la validación de la transacción y la confirmación del pago.
Los Bounded Contexts identificados en la sesión de Candidate Context Discovery fueron documentados utilizando el Bounded Context Canvas. Esta herramienta permite visualizar de manera clara y concisa los límites, interacciones y responsabilidades de cada contexto.
Figura 6:
Esta figura muestra el Bounded Context Canvas del contexto de "Guía de Reservas", donde se detallan los límites, interacciones y responsabilidades del sistema de reservas.
Figura 7:
Esta figura muestra el Bounded Context Canvas del contexto de "Gestión de Usuarios", donde se detallan los límites, interacciones y responsabilidades del sistema de gestión de usuarios.
Figura 8:
Esta figura muestra el Bounded Context Canvas del contexto de "Pagos y Suscripciones", donde se detallan los límites, interacciones y responsabilidades del sistema de gestión de pagos y suscripciones.
Con el fin de establecer las relaciones entre los distintos Bounded Contexts identificados, se realizó un mapeo de contextos. Este mapeo permite visualizar cómo interactúan los diferentes contextos y cómo se comunican entre sí.
Esta figura muestra el mapeo de contextos, donde se pueden observar las relaciones entre los distintos Bounded Contexts. Cada línea representa una relación de comunicación entre los contextos, lo que permite entender cómo fluyen los datos y las interacciones entre ellos.
¿Qué pasaría si movemos una capability? Se pierde cohesión. Las órdenes responden a eventos que no necesariamente involucran al usuario.
¿Y si partimos un bounded context? Se pierde la claridad de los límites. La gestión de reservas y la gestión de pagos son procesos interdependientes que deben mantenerse juntos para evitar confusiones y errores en el sistema.
¿Qué pasaría si duplicamos funcionalidad? Se genera redundancia y confusión. La duplicación de funcionalidades puede llevar a inconsistencias en el sistema y dificultar su mantenimiento.
¿Y si creamos un shared service? Se genera un acoplamiento innecesario. La creación de un servicio compartido puede llevar a una dependencia excesiva entre los contextos, lo que dificulta su evolución y mantenimiento. Aunque puede ser útil si se conectan más contexts o microservicios. Sería algo escalable en el futuro.
Los diseños C4 son una forma efectiva de representar la arquitectura de un sistema de software de manera clara y concisa. En el caso del proyecto Dedalus, los diseños C4 nos permiten visualizar la estructura y las interacciones entre los diferentes componentes del sistema.
En el nivel más alto, el diseño C4 nos muestra el contexto del sistema, identificando los actores externos y los sistemas con los que interactúa LogistcsMasters. A medida que descendemos en los niveles de detalle, podemos ver los contenedores que componen el sistema, como la aplicación web, la base de datos y los servicios externos. Además, los diagramas C4 nos permiten visualizar los componentes internos de cada contenedor, como los módulos y las clases.
Estos diseños proporcionan una visión clara de la arquitectura del sistema, lo que facilita la comunicación entre los miembros del equipo y ayuda a identificar posibles problemas o mejoras. Al utilizar los diseños C4 en el proyecto LogistcsMasters, podemos asegurarnos de que todos los involucrados tengan una comprensión común de la arquitectura y puedan colaborar de manera efectiva en su implementación y evolución.
Esta es la propuesta táctica para el diseño de software de Dedalus, aplicando Domain-Driven Design (DDD).
Clases | Propósito | Atributos | Métodos |
---|---|---|---|
Reservation | Gestiona los datos y estado de una reserva | reservationID(), reservationDate(), numberOfPeople(), table() | createReservation(), cancelReservation(), updateReservation() |
Customer | Representa al cliente que realiza reservas. | paymentMethod, reservationList | register(), placeReserve(), makeReservation(), cancelReservation() |
Worker | Empleado del hotel que gestiona reservas. | Position | manageReserve() (overloaded para Order y Reservation) |
Clase | Tipo | Propósito |
---|---|---|
Reserva | Entity | Representa una reserva realizada por un cliente en el sistema. |
Customer | Entity | Representa al cliente que realiza una o más reservas. |
Worker | Entity | Representa al trabajador asignado a gestionar reservas. |
ReservaService | Domain Service | Lógica del negocio como validación de fechas, disponibilidad, etc. |
ReservaFactory | Factory | Encargado de crear objetos Reserva consistentes. |
IReservaRepository | Repository Interface | Interfaz para acceder a almacenamiento de reservas. |
Clase | Tipo | Propósito |
---|---|---|
ReservaController | Controller | Expone los endpoints de gestión de reservas (crear, cancelar, actualizar). |
Clase | Tipo | Propósito |
---|---|---|
CrearReservaHandler | Command Handler | Ejecuta el proceso de creación de una reserva. |
CancelarReservaHandler | Command Handler | Ejecuta la cancelación de una reserva. |
ActualizarReservaHandler | Command Handler | Ejecuta la actualización de datos de una reserva. |
Clase | Tipo | Propósito |
---|---|---|
MySQLReservaRepository | Repository Implementation | Implementa IReservaRepository para persistencia en base de datos relacional. |
EmailNotificacionService | External Service | Servicio de envío de notificaciones por email (ej. al confirmar reserva). |
CalendarioAPI | External API | Servicio externo para validar disponibilidad de fechas. |
Figura 10:
Este diagrama muestra la arquitectura de componentes del Bounded Context "Guía de Reservas". En él se pueden observar los distintos componentes que interactúan entre sí, así como sus responsabilidades y relaciones.
Figura 11:
Este diagrama muestra la estructura a nivel de clases para el Bounded Context "Guía de Reservas", siguiendo el modelo de capas de software. Se representan las principales entidades, servicios de dominio, controladores de interfaz, handlers de aplicación y componentes de infraestructura.
Figura 12:
Clase | Propósito | Atributos | Métodos |
---|---|---|---|
User | Representa a un usuario del sistema (cliente o trabajador) | id: String, name: String, username: String, password: String, email: String, role: Enum, reserveList: List | login(), logout(), checkReserves() |
AuthenticationService | Lógica de autenticación y validación de credenciales | – | authenticate(username, password), logout(user) |
UserValidationService | Verifica datos válidos de usuario (correo, contraseña, etc.) | – | validarCorreo(email), validarContrasena(password) |
IUserRepository | Interfaz para acceder a usuarios en base de datos | – | save(user), findByUsername(username), delete(id) |
MySQLUserRepository | Implementación de acceso a usuarios en base MySQL | – | Implementa IUserRepository |
AuthController | Expone los endpoints de autenticación y gestión de sesión | – | POST /login, POST /logout, POST /register |
LoginUserHandler | Maneja la lógica de login en la capa de aplicación | – | handle(LoginCommand) |
LogoutUserHandler | Maneja el cierre de sesión | – | handle(LogoutCommand) |
Clase | Tipo | Propósito |
---|---|---|
User | Entity | Representa al usuario del sistema con sus atributos y rol. |
AuthenticationService | Domain Service | Realiza autenticación basada en credenciales. |
UserValidationService | Domain Service | Valida datos de entrada del usuario. |
IUserRepository | Repository Interface | Interfaz para la persistencia y recuperación de usuarios. |
Clase | Tipo | Propósito |
---|---|---|
AuthController | Controller | Expone endpoints de login, logout y registro. |
Clase | Tipo | Propósito |
---|---|---|
LoginUserHandler | Command Handler | Ejecuta lógica de inicio de sesión. |
LogoutUserHandler | Command Handler | Ejecuta cierre de sesión de un usuario. |
Clase | Tipo | Propósito |
---|---|---|
MySQLUserRepository | Repository Implementation | Implementa interfaz para acceder a datos del usuario. |
JWTTokenService | External Service | Genera y valida tokens para autenticación. |
EmailService | External Service | Notificación de bienvenida, recuperación de contraseña, etc. |
Figura 12:
Este diagrama muestra la arquitectura de componentes del Bounded Context "Gestión de Usuarios". En él se pueden observar los distintos componentes que interactúan entre sí, así como sus responsabilidades y relaciones.
Figura 13:
El siguiente diagrama muestra la estructura a nivel de clases para el Bounded Context Gestión de Usuarios, siguiendo el modelo de capas de software. Se representan las principales entidades, servicios de dominio, controladores de interfaz, handlers de aplicación y componentes de infraestructura.
Figura 14:
Clase | Propósito | Atributos | Métodos |
---|---|---|---|
PaymentMethod | Representa un pago realizado por un cliente | paymentID: String, amount: Float, paymentDate: Date, customerID: String, methodType: Enum | processPayment(), refund() |
Suscription | Maneja la suscripción de un usuario a un plan | id: String, type: Enum, price: Float, status: Enum, startDate: Date, endDate: Date, userID: String | activate(), cancel(), renew() |
PaymentService | Realiza operaciones de validación y procesamiento de pagos | – | validarPago(...), confirmarTransaccion(...) |
SuscriptionService | Controla lógica de negocio de activación y renovación | – | asignarPlan(...), validarSuscripcionActiva(...) |
IPaymentRepository | Interfaz para persistencia de pagos | – | save(payment), findByCustomerID(id) |
ISuscriptionRepository | Interfaz para persistencia de suscripciones | – | save(suscription), findActiveByUserID(id) |
MySQLPaymentRepository | Implementación concreta de IPaymentRepository | – | Implementa métodos de la interfaz |
MySQLSuscriptionRepository | Implementación concreta de ISuscriptionRepository | – | Implementa métodos de la interfaz |
PaymentController | Expone endpoints relacionados al pago | – | POST /pago, GET /pagos/:clienteId |
SubscriptionController | Gestiona suscripciones | – | POST /suscripcion, GET /suscripciones/:usuarioId |
ProcessPaymentHandler | Maneja la lógica de realizar un pago | – | handle(PaymentCommand) |
RegisterSubscriptionHandler | Registra una suscripción para un usuario | – | handle(SuscriptionCommand) |
Clase | Tipo | Propósito |
---|---|---|
PaymentMethod | Entity | Representa un pago con monto, tipo y fecha. |
Suscription | Entity | Representa un plan de suscripción que puede estar activo o cancelado. |
PaymentService | Domain Service | Lógica de validación de pagos. |
SuscriptionService | Domain Service | Control de activaciones y renovaciones. |
IPaymentRepository | Repository Interface | Abstracción para guardar y consultar pagos. |
ISuscriptionRepository | Repository Interface | Abstracción para acceder a suscripciones. |
Clase | Tipo | Propósito |
---|---|---|
PaymentController | Controller | Endpoint para procesar y consultar pagos. |
SubscriptionController | Controller | Endpoint para registrar o consultar planes del usuario. |
Clase | Tipo | Propósito |
---|---|---|
ProcessPaymentHandler | Command Handler | Maneja la lógica completa del flujo de pago. |
RegisterSubscriptionHandler | Command Handler | Maneja el registro de una suscripción para un usuario. |
Clase | Tipo | Propósito |
---|---|---|
MySQLPaymentRepository | Repository Implementation | Almacena y recupera datos de pagos desde base de datos. |
MySQLSuscriptionRepository | Repository Implementation | Maneja la persistencia de planes de suscripción. |
StripePaymentGateway | External Service | Conecta con Stripe (o similar) para procesar pagos reales. |
BillingEmailService | External Service | Notificaciones sobre cobros, renovación o cancelación de planes. |
Figura 14:
Este diagrama muestra la arquitectura de componentes del Bounded Context "Pagos y Suscripciones". En él se pueden observar los distintos componentes que interactúan entre sí, así como sus responsabilidades y relaciones.
Figura 15:
El siguiente diagrama muestra la estructura a nivel de clases para el Bounded Context "Pagos y Suscripciones", siguiendo el modelo de capas de software. Se representan las principales entidades, servicios de dominio, controladores de interfaz, handlers de aplicación y componentes de infraestructura.
Figura 16:
Clase | Propósito | Atributos | Métodos |
---|---|---|---|
Notification | Representa un mensaje enviado al usuario sobre su reserva, orden u otra acción | id: String, type: Enum, message: String, status: Enum, recipientEmail: String | createMessage(), send(), markAsRead() |
Controlador | Clase orquestadora que gestiona reservas, servicios y asignaciones a usuarios | orderList: List, users: List, services: List | manageReserve(), assignOrderToWorker(), deliverMessage() |
Order | Representa un pedido realizado por el cliente que puede incluir servicios adicionales | orderId: String, customerId: String, details: String, status: Enum | confirm(), cancel() |
NotificationService | Lógica para envío y gestión de notificaciones | – | sendEmail(), notifyUser(), notifyAdmin() |
OrderService | Lógica de negocio para asignar y controlar órdenes | – | assignToWorker(order, worker), trackStatus() |
INotificationRepository | Interfaz para persistencia de notificaciones | – | save(notification), findUnreadByUser(id) |
IOrderRepository | Interfaz para persistencia de órdenes | – | save(order), getByCustomer(id) |
MySQLNotificationRepository | Implementación concreta del repositorio de notificaciones | – | Implementa INotificationRepository |
MySQLOrderRepository | Implementación concreta para almacenar órdenes | – | Implementa IOrderRepository |
NotificationController | Expone endpoints relacionados a notificaciones | – | GET /notificaciones/:usuarioId, POST /notificaciones |
OrderController | Endpoint para gestionar pedidos de servicios | – | POST /orden, GET /orden/:clienteId |
SendNotificationHandler | Encapsula el flujo de enviar una notificación | – | handle(NotificationCommand) |
AssignOrderHandler | Encapsula el flujo de asignar una orden a un trabajador | – | handle(AssignOrderCommand) |
Clase | Tipo | Propósito |
---|---|---|
Notification | Entity | Almacena y gestiona información de mensajes hacia el usuario. |
Order | Entity | Representa una solicitud de servicio o producto por parte del cliente. |
NotificationService | Domain Service | Lógica de envío y validación de notificaciones. |
OrderService | Domain Service | Maneja reglas de negocio de órdenes y asignación a trabajadores. |
INotificationRepository | Repository Interface | Para persistencia de notificaciones. |
IOrderRepository | Repository Interface | Para persistencia de órdenes. |
Clase | Tipo | Propósito |
---|---|---|
NotificationController | Controller | Exposición de notificaciones para clientes y administradores. |
OrderController | Controller | Exposición de pedidos y solicitudes de servicio por los usuarios. |
Clase | Tipo | Propósito |
---|---|---|
SendNotificationHandler | Command Handler | Lógica para crear y enviar una notificación. |
AssignOrderHandler | Command Handler | Asigna un pedido a un trabajador para ejecución. |
Clase | Tipo | Propósito |
---|---|---|
MySQLNotificationRepository | Repository Implementation | Persistencia de notificaciones en base de datos relacional. |
MySQLOrderRepository | Repository Implementation | Manejo de órdenes persistidas por clientes. |
EmailNotificationAdapter | External Service | Encapsula lógica de envío real vía SMTP, SendGrid, etc. |
RealtimeNotificationAdapter | External Service | WebSocket o Pusher para actualizaciones en tiempo real. |
Figura 16:
Este diagrama muestra la arquitectura de componentes del Bounded Context "Notificaciones y Órdenes". En él se pueden observar los distintos componentes que interactúan entre sí, así como sus responsabilidades y relaciones.
Figura 17:
El siguiente diagrama muestra la estructura a nivel de clases para el Bounded Context "Notificaciones y Órdenes", siguiendo el modelo de capas de software. Se representan las principales entidades, servicios de dominio, controladores de interfaz, handlers de aplicación y componentes de infraestructura.
Figura 18: