Historias de usuario - jolara04-svg/Buscador_Sombras GitHub Wiki
HU-01: Mapa con mi ubicación
Rol: peatón / ciclista / conductor
Quiero: ver mi ubicación en un mapa
Para: orientarme
Criterios de aceptación: El mapa carga, muestra un indicador con mi posición, permite zoom y desplazamiento.
Prioridad: Alta; ya que es una funcionalidad núcleo. Sin el visor de mapa interactivo y la geolocalización del usuario, las demás funcionalidades no pueden funcionar.
Tamaño: M; ya que cargar un mapa base e integrar la API de geolocalización es una tarea de complejidad media, no requiere un backend complejo para empezar, pero implica gestionar permisos de ubicación y posibles fallos de conexión.
Sprint: Sprint 1 ?
Issue: #1
HU-02: Visualización del campus
Rol: peatón / ciclista / conductor
Quiero: visualizar el campus con edificios y árboles
Para: orientarme
Criterios de aceptación: Se cargan los elementos representativos del campus (edificios principales y zonas de vegetación) en la pantalla. Y al seleccionar o tocar un edificio, se muestra una etiqueta con su nombre oficial.
Prioridad: Media; puesto que aporta gran valor visual para la orientación, pero depende de que la geolocalización y el visor base (HU-01) estén operativos primero.
Tamaño: L; puesto que cargar y gestionar capas personalizadas, activos visuales o modelos 3D en un mapa consume más recursos de cómputo y requiere optimizaciones.
Sprint: Sprint 2 ?
Issue: #2
HU-03: Navegación en el mapa 1
Rol: peatón / ciclista / conductor
Quiero: poder rotar y hacer zoom en el mapa 3D
Para: explorar el campus desde distintos ángulos
Criterios de aceptación: Controles de rotación y zoom. Y la vista cambia fluidamente en tiempo real sin recargar la página o pantalla.
Prioridad: Alta; dado que el mapa incluye representación 3D (HU-02), la rotación y el control de cámara son imprescindibles para evitar que los edificios tapen la visibilidad de ciertos caminos o puntos de interés.
Tamaño: M; dado que la mayoría de motores y librerías de mapas 3D incluyen gestos y controles de cámara nativos, entonces el esfuerzo principal está en configurar límites de cámara para que el usuario no "se pierda" fuera del campus y suavizar las animaciones.
Sprint: Sprint 2 ?
Issue: #3
HU-04: Navegación en el mapa 2
Rol: peatón / ciclista / conductor
Quiero: alternar el mapa entre 2D y 3D
Para: elegir la perspectiva más cómoda
Criterios de aceptación: Botón para alternar, y la vista cambia sin recargar la pantalla de nuevo.
Prioridad: Media; ya que esto mejora la usabilidad y la accesibilidad, pero no impide el funcionamiento básico del mapa si se retrasa.
Tamaño: S; ya que es una tarea pequeña de interfaz y lógica de cámara.
Sprint: Sprint 3 ?
Issue: #4
HU-05: Posición solar por fecha y hora
Rol: peatón / ciclista / conductor
Quiero: ver la posición del sol para una fecha y hora determinada
Para: ver la iluminación del campus
Criterios de aceptación: El usuario puede seleccionar una fecha y hora mediante un selector. El sistema calcula las coordenadas solares en la ubicación del campus. Y la luz direccional del escenario 3D cambia de ángulo e intensidad para simular el momento del día.
Prioridad: Alta; puesto que es el motor astronómico base, sin el cálculo matemático de la posición solar no es posible proyectar sombras dinámicas ni simular el paso del tiempo.
Tamaño: M; puesto que existen librerías estándar (como SunCalc) que calculan el azimut y elevación del sol según coordenadas GPS y hora, entonces el esfuerzo está en vincular esa matemática con la fuente de luz del motor 3D.
Sprint: Sprint 3 ?
Issue: #5
HU-06: Simulación horaria del sol
Rol: peatón / ciclista / conductor
Quiero: simular el paso del tiempo
Para: ver cómo cambia la posición del sol
Criterios de aceptación: La interfaz incluye un control con botón de reproducción (play/pause) y una barra deslizante (slider). Y al reproducir la animación, la iluminación del campus se cambia de forma continua y fluida.
Prioridad: Media; dado que esto mejora la experiencia de usuario de la HU-05, permitiendo ver la evolución temporal de la luz de forma animada en lugar de estática.
Tamaño: M; dado que se apoya en la HU-05, consiste en crear un bucle de tiempo que incremente la hora progresivamente y actualice la luz en pantalla.
Sprint: Sprint 3 ?
Issue: #6
HU-07: Proyección de sombras
Rol: peatón / ciclista / conductor
Quiero: ver las proyecciones del sol por los árboles y edificios
Para: ver zonas de sombra
Criterios de aceptación: Los edificios y árboles 3D proyectan sombras dinámicas sobre el terreno y otras estructuras según la posición del sol. Y la longitud y dirección de las sombras se ajustan automáticamente al cambiar de hora o fecha.
Prioridad: Alta; ya que es la funcionalidad visual clave para peatones y ciclistas que buscan rutas o descansos protegidos del sol.
Tamaño: L; ya que calcular las sombras de tantos edificios y árboles en tiempo real consume bastantes recursos, por tanto, hay que optimizarlo bien para que la app no vaya lenta ni se trabe.
Sprint: Sprint 4 ?
Issue: #7
HU-08: Consulta de sombra por hora
Rol: peatón / ciclista / conductor
Quiero: seleccionar una hora determinada
Para: ver dónde habrá sombra en ese momento
Criterios de aceptación: El usuario puede elegir o ingresar una hora exacta, y el mapa congela la iluminación y muestra las sombras exactas correspondientes a esa hora específica.
Prioridad: Media; puesto que solo permite planificar con precisión una visita o trayecto puntual a una hora específica.
Tamaño: S; puesto que es una tarea pequeña de interfaz que conecta la selección puntual del usuario con las funciones creadas en la HU-05 y HU-07.
Sprint: Sprint 4 ?
Issue: #8
HU-09: Consulta de sombra por punto
Rol: peatón / ciclista / conductor
Quiero: seleccionar un punto del mapa
Para: ver a qué horas estará a la sombra
Criterios de aceptación: El usuario puede hacer clic sobre cualquier lugar del mapa, y aparece un listado de franjas horarias indicando las horas del día en que ese punto estará expuesto al sol o a la sombra.
Prioridad: Baja; dado que es una funcionalidad avanzada.
Tamaño: XL; dado que a diferencia de solo "dibujar sombras", requiere realizar un análisis geométrico o trazado de rayos en tiempo real hacia la fuente de luz solar a través de las 24 horas del día para determinar intersecciones con edificios o vegetación.
Sprint: Sprint 5 ?
Issue: #9
HU-10: Evolución estacional de la sombra
Rol: peatón / ciclista / conductor
Quiero: comparar la sombra en distintas estaciones
Para: planificar rutas futuras
Criterios de aceptación: Existencia de un selector de estación (primavera, verano, otoño, invierno). Y al cambiar la estación, la inclinación y posición del sol cambian automáticamente actualizando las sombras en el mapa.
Prioridad: Baja; ya que es una función analítica y de planificación avanzada, aporta contexto, pero no interrumpe el uso básico de navegación.
Tamaño: M; ya que se apoya por completo en la lógica solar ya construida (HU-05).
Sprint: Sprint 5 ?
Issue: #10
HU-11: Selección de origen y destino
Rol: peatón / ciclista
Quiero: seleccionar una posición de origen y otra de destino
Para: calcular la ruta entre ambos
Criterios de aceptación: El usuario puede indicar los puntos A (origen) y B (destino) tocando directamente el mapa o pulsando el botón "Usar mi ubicación actual". Aparecen marcadores gráficos bien diferenciados para origen y destino. Y se incluye un botón para limpiar o intercambiar la selección de puntos.
Prioridad: Alta; puesto que es la base imprescindible para cualquier sistema de cálculo de rutas.
Tamaño: M; puesto que es una tarea enfocada en la interacción de la interfaz y la gestión de marcadores visuales sobre el mapa.
Sprint: Sprint 4 ?
Issue: #11
HU-12: Búsqueda de lugares
Rol: peatón / ciclista / conductor
Quiero: buscar lugares por nombre
Para: seleccionar destino, origen o zona de aparcamiento más fácilmente
Criterios de aceptación: Barra de búsqueda con autocompletado en tiempo real al escribir el nombre de un edificio o lugar del campus. Al seleccionar un resultado, el mapa hace zoom y centra la cámara sobre la ubicación seleccionada. Y permite asignar directamente ese punto como Origen o Destino.
Prioridad: Alta; dado que es muy útil en entornos universitarios o de campus donde la gente no conoce las coordenadas exactas y busca por nombre del pabellón, facultad o aparcamiento.
Tamaño: M; dado que requiere tener una base de datos con los nombres y coordenadas de cada punto del campus y conectarlo con un componente de búsqueda.
Sprint: Sprint 4 ?
Issue: #12
HU-13: Ruta más rápida
Rol: peatón / ciclista
Quiero: ver la ruta más rápida entre dos puntos
Para: llegar cuanto antes
Criterios de aceptación: El sistema calcula y dibuja en el mapa el camino con la menor distancia/tiempo de caminata o pedaleo. Y muestra un panel con el tiempo estimado de llegada y la distancia total en kilómetros.
Prioridad: Alta; ya que es el comportamiento estándar que todo usuario espera de una app de mapas al pedir una ruta.
Tamaño: L; ya que requiere crear o integrar la red de caminos del campus (grafo de navegación) y aplicar un algoritmo estándar de cálculo de ruta corta.
Sprint: Sprint 4 ?
Issue: #13
HU-14: Ruta más sombreada
Rol: peatón / ciclista
Quiero: ver la ruta más sombreada entre dos puntos
Para: reducir el calor y la exposición solar recibidos
Criterios de aceptación: El sistema debe calcular y dibujar el trayecto que maximice la distancia bajo sombra según la posición solar actual, diferenciando visualmente los tramos de sol y sombra y mostrando un panel con el porcentaje de cobertura, distancia y tiempo estimado; en caso de no existir sombra (como en horario nocturno), debe trazar la ruta más corta mostrando un aviso informativo, y todo el proceso de cálculo y renderizado debe completarse en menos de 3 segundos.
Prioridad: Media; puesto que es la propuesta de valor diferenciadora del proyecto, pero requiere que el motor de rutas tradicional (HU-13) y el motor de sombras (HU-07) ya funcionen previamente.
Tamaño: XL; puesto que es la tarea de mayor complejidad técnica: no se trata solo de encontrar la ruta más corta, sino de cruzar cada tramo de camino con la posición de las sombras en ese instante, penalizando en el código los caminos expuestos al sol para recalcular el trayecto óptimo.
Sprint: Sprint 6 ?
Issue: #14
HU-15: Ruta equilibrada
Rol: peatón / ciclista
Quiero: ver la ruta que equilibre sombra y tiempo
Para: reducir el calor y la exposición solar sin dar rodeos excesivos
Criterios de aceptación: El sistema debe calcular y proponer una ruta alternativa que pondere de forma equitativa (50/50) la cobertura de sombra y la distancia, mostrando una tarjeta comparativa clara frente a la ruta más rápida (por ejemplo: "2 min más larga, 40% más de sombra"), utilizando los mismos códigos visuales de tramos sombreados y cumpliendo con un tiempo de respuesta menor a 3 segundos.
Prioridad: Media; dado que es una mejora intermedia muy útil, pero no es indispensable para el lanzamiento inicial.
Tamaño: L; dado que se construye reutilizando la lógica de la HU-14, ajustando la fórmula matemática para que balancee en peso un 50% de distancia y un 50% de sombra.
Sprint: Sprint 6 ?
Issue: #15
HU-16: Preferencias de ruta
Rol: peatón / ciclista
Quiero: ajustar la importancia de la sombra frente a la distancia o el tiempo
Para: elegir la ruta según mis preferencias
Criterios de aceptación: La interfaz incluye un control deslizante que permite graduar la prioridad entre "Máxima Sombra" y "Menor Tiempo". Y al modificar el control, el sistema recalcula y actualiza la ruta proyectada en el mapa en tiempo real.
Prioridad: Media; ya que personaliza la experiencia del usuario, permitiendo afinar el comportamiento de las historias de ruta (HU-13, HU-14 y HU-15).
Tamaño: M; ya que es solo agregar un control deslizante en la pantalla para que el usuario elija qué le importa más (si la sombra o llegar rápido), y pasarle ese dato al buscador de rutas que ya teníamos programado.
Sprint: Sprint 6 ?
Issue: #16
HU-17: Aparcamiento con sombra
Rol: conductor
Quiero: saber qué zonas de aparcamiento tendrán sombra durante mi estancia
Para: evitar que el coche se caliente
Criterios de aceptación: El conductor puede seleccionar un aparcamiento y definir un rango horario de permanencia, y el mapa resalta las zonas o plazas de aparcamiento indicando el nivel o porcentaje de cobertura de sombra previsto durante esa ventana de tiempo.
Prioridad: Media; puesto que cubre el caso de uso clave para el perfil conductor, complementando la utilidad del mapa para vehículos.
Tamaño: XL; puesto que requiere evaluar el cálculo de proyección de sombras (HU-07) de forma iterativa sobre un intervalo completo de horas en los polígonos/áreas definidos como zonas de aparcamiento.
Sprint: Sprint 5 ?
Issue: #17
HU-18: Probabilidad de plaza libre
Rol: conductor
Quiero: conocer la probabilidad de que haya una plaza libre en una zona y franja horaria
Para: decidir dónde dirigirme
Criterios de aceptación: Al consultar una zona de aparcamiento y una hora determinada, el mapa muestra un indicador de disponibilidad estimada (por ejemplos: "Alta", "Media", "Baja").
Prioridad: Baja; dado que es una funcionalidad avanzada que no forma parte del núcleo de sombras y geolocalización.
Tamaño: XL; dado que supone una elevada complejidad técnica y de datos, por la razón de que requiere consumir APIs externas, integrar sensores o construir un modelo predictivo basado en historiales de ocupación.
Sprint: Sprint 7 ?
Issue: #18
HU-19: Reportar cambios en el mapa
Rol: peatón / ciclista / conductor
Quiero: reportar cambios en el mapa (árboles, edificios, sombras, zonas de aparcamiento)
Para: que las recomendaciones de sombra sigan siendo precisas
Criterios de aceptación: Formulario desplegable al pulsar sobre un punto del mapa que permite seleccionar el tipo de elemento a reportar (por ejemplos: "árbol podado", "obras", "edificio nuevo") y adjuntar un comentario. Y el reporte queda guardado en la base de datos para su posterior moderación o actualización por parte de los administradores.
Prioridad: Baja; ya que es un mecanismo de mantenimiento participativo que solo tiene sentido una vez que la aplicación ya está publicada y en uso continuo.
Tamaño: L; ya que implica diseñar el componente de reporte en el cliente y construir el servicio backend (API + base de datos) para recibir y almacenar las incidencias del mapa.