Project Report

Universidad Peruana de Ciencias Aplicadas

Ingeniería de Software

Periodo: 2026-10 1ASI0657 | Fundamentos de Arquitectura de Software NRC: 17949 Docente: Jorge Luis Delgado Vite

Informe del Trabajo Final

Startup: GosLogic Producto: Orion

Integrantes

Miembro	Código
Cossar Sánchez, Eduardo José	u202312109
Gonzales Castillo, Angel Martin	u202319724
Iglesias Pérez, Sergio Sebastián	u202316118
Mostajo Orosco, Maria Fernanda	u202312874
Solano Armas, Angelo Hector	u20231B775

Mayo, 2026

Registro de versiones del informe

Versión	Fecha	Autor	Descripción de modificación
TB1	15/04/2026	Todos los integrantes del grupo aportaron	Completado hasta el Capítulo III: Introducción (Startup Profile, Solution Profile y segmentos objetivo), Requirements & Analysis (competidores, entrevistas y needfinding) y Requirements Specification (To-Be Scenario Mapping, User Stories, Impact Map y Product Backlog).
TB2	01/05/2026	Todos los integrantes del grupo aportaron	Completado hasta el Capítulo IV: Product Architecture Design y realizadas correciones al Capitulo I: Lean UX Process y Capitulo III: Impact Map y Product Backlog.
TP1	12/05/2026	Todos los integrantes del grupo aportaron	Entrega del Capítulo V (Product Implementation, Validation & Deployment): evidencias de testing suites y patrones backend, gestión de configuración de software, implementación de microservicios (Sprint 1, backlog, evidencias de testing, ejecución, documentación y despliegue), tablero Kanban e insights de colaboración en sprint, según responsabilidades por integrante.

Contenido

Tabla de contenidos

Carátula
Registro de Versiones del Informe
Contenido
- Tabla de contenidos
Student Outcome
Capítulo I: Introducción
Capítulo II: Requirements & Analysis
Capítulo III: Requirements Specification
Capítulo IV: Product Architecture Design
Capítulo V: Product Implementation, Validation & Deployment
Conclusiones
- Conclusiones y recomendaciones
- Video About-The-Team
Referencias Bibliográficas
Anexos
Links

Student Outcome

El curso contribuye al cumplimiento del Student Outcome ABET:

ABET – EAC – Student Outcome 7
Criterio: La capacidad de adquirir y aplicar nuevos conocimientos según sea necesario, utilizando estrategias de aprendizaje apropiadas.

Criterio específico	Acciones realizadas	Conclusiones
Actualiza conceptos y conocimientos necesarios para su desarrollo profesional y en especial para su proyecto en soluciones de ingeniería de software.	TB1 Cossar Sánchez, Eduardo José: · Lean UX Canvas · User Task Matrix · Product Backlog · Entrevistas Gonzales Castillo, Angel Martin: · User Personas · Empathy Maps · Entrevistas · As-is Scenario Mapping · To-Be Scenario Mapping Iglesias Pérez, Sergio Sebastián: · Descripción de la Startup · Nombre del producto · Antecedentes y problemática · Segmentos objetivo · Competidores Mostajo Orosco, Maria Fernanda: · Lean UX Canvas · Impact Map · Entrevistas · User Stories Solano Armas, Angelo Hector: · Lean UX Problem Statement · Lean UX Assumptions · Lean UX Hypothesis · Entrevistas · User Stories TB2 Cossar Sánchez, Eduardo José: · Corrección Impact Map · Corrección Product Backlog · Design Purpose · Primary Functionality Gonzales Castillo, Angel Martin: · Corrección del Impact Map · Corrección del Lean UX Process · Principles Statements · Approaches Statements (Architectural Styles & Patterns) · Tactics Iglesias Pérez, Sergio Sebastián: · Design Patterns · Relational/Non Relational Database Diagram · Architectural Concerns · ADD Iteration 1 · Context Diagram Mostajo Orosco, Maria Fernanda: · Corrección Impact Map · Corrección Product Backlog · Quality Attribute Scenarios · Constraints Solano Armas, Angelo Hector: · Context Diagram · Approach Driven ViewPoints Diagrams · Relational/Non Relational Database Diagram · Design Patterns TP1 Cossar Sánchez, Eduardo José: · Testing Suites & General Patterns · Backend Application Core Testing Suite · Kanban Board · Team Collaboration Insights during Sprint Gonzales Castillo, Angel Martin: · Software Deployment Evidence for Sprint Review · Microservices Documentation Evidence for Sprint Review · Execution Evidence for Sprint Review · Testing Suite Evidence for Sprint Review Iglesias Pérez, Sergio Sebastián: · Pattern Based Backend Application(s) · Framework Pattern Driven Refactoring Report · Software Deployment Configuration Mostajo Orosco, Maria Fernanda: · Microservices Implementation · Testing Suite Evidence for Sprint Review · Sprint Backlog 1 · Kanban Board Solano Armas, Angelo Hector: · Software Configuration Management · Source Code Style Guide & Conventions · Software Development Environment Configuration	TB1 Durante el TB1, el equipo actualizó y aplicó conocimientos de Lean UX, análisis de requerimientos y especificación de soluciones en el desarrollo del proyecto Orion. La asignación de responsabilidades por integrante permitió transformar conceptos teóricos en entregables verificables, evidenciando dominio progresivo y aplicación pertinente de fundamentos de ingeniería de software. TB2 Durante el TB2, el equipo actualizó y aplicó conocimientos en diseño arquitectónico, atributos de calidad y modelado de soluciones en el desarrollo del proyecto Orion. Actividades como la corrección del Impact Map, Product Backlog y el proceso Lean UX, junto con la elaboración de artefactos como Design Purpose, diagramas, patrones y las iteraciones ADD, permitieron transformar conceptos teóricos en entregables estructurados, evidenciando un dominio progresivo y una aplicación adecuada de los fundamentos de ingeniería de software. TP1 En el TP1, el equipo aplicó conocimientos de implementación, pruebas, gestión de configuración y despliegue sobre la arquitectura definida para Orion. Las evidencias del Sprint 1 (backlog, testing, ejecución, documentación y despliegue de microservicios), junto con tablero Kanban y reflexión de colaboración, muestran la traducción del diseño en software verificable y operativo.
Reconoce la necesidad del aprendizaje permanente para el desempeño profesional y el desarrollo de proyectos en soluciones de tecnologías de ingeniería de software.	TB1 Cossar Sánchez, Eduardo José: · Lean UX Canvas · User Task Matrix · Product Backlog · Entrevistas Gonzales Castillo, Angel Martin: · User Personas · Empathy Maps · Entrevistas · As-is Scenario Mapping · To-Be Scenario Mapping Iglesias Pérez, Sergio Sebastián: · Descripción de la Startup · Nombre del producto · Antecedentes y problemática · Segmentos objetivo · Competidores Mostajo Orosco, Maria Fernanda: · Lean UX Canvas · Impact Map · Entrevistas · User Stories Solano Armas, Angelo Hector: · Lean UX Problem Statement · Lean UX Assumptions · Lean UX Hypothesis · Entrevistas · User Stories TB2 Cossar Sánchez, Eduardo José: · Corrección Impact Map · Corrección Product Backlog · Design Purpose · Primary Functionality Gonzales Castillo, Angel Martin: · Corrección del Impact Map · Corrección del Lean UX Process · Principles Statements · Approaches Statements (Architectural Styles & Patterns) · Tactics Iglesias Pérez, Sergio Sebastián: · Design Patterns · Relational/Non Relational Database Diagram · Architectural Concerns · ADD Iteration 1 · Context Diagram Mostajo Orosco, Maria Fernanda: · Corrección Impact Map · Corrección Product Backlog · Quality Attribute Scenarios · Constraints Solano Armas, Angelo Hector: · Context Diagram · Approach Driven ViewPoints Diagrams · Relational/Non Relational Database Diagram · Design Patterns TP1 Cossar Sánchez, Eduardo José: · Testing Suites & General Patterns · Backend Application Core Testing Suite · Kanban Board · Team Collaboration Insights during Sprint Gonzales Castillo, Angel Martin: · Software Deployment Evidence for Sprint Review · Microservices Documentation Evidence for Sprint Review · Execution Evidence for Sprint Review · Testing Suite Evidence for Sprint Review Iglesias Pérez, Sergio Sebastián: · Pattern Based Backend Application(s) · Framework Pattern Driven Refactoring Report · Software Deployment Configuration Mostajo Orosco, Maria Fernanda: · Microservices Implementation · Testing Suite Evidence for Sprint Review · Sprint Backlog 1 · Kanban Board Solano Armas, Angelo Hector: · Software Configuration Management · Source Code Style Guide & Conventions · Software Development Environment Configuration	TB1 El trabajo colaborativo del TB1 evidenció una práctica constante de aprendizaje continuo, ya que el equipo investigó, adaptó y aplicó nuevas estrategias según las necesidades del proyecto. La mejora iterativa en artefactos como User Stories, escenarios AS-IS/TO-BE e Impact Map demostró la capacidad de autoformación y actualización permanente para el desempeño profesional. TB2 Durante el TB2, el equipo reafirmó la necesidad del aprendizaje permanente mediante la profundización en temas de diseño arquitectónico, atributos de calidad y patrones de software. La aplicación de metodologías como ADD, junto con la elaboración de diversos artefactos técnicos, permitió consolidar conocimientos más avanzados, evidenciando una evolución continua en su preparación profesional y en el desarrollo de soluciones de ingeniería de software. TP1 El TP1 requirió aprender sobre la marcha herramientas y prácticas de integración continua, pruebas automatizadas, convenciones de código y despliegue de microservicios. La iteración en sprint y el uso del Kanban refuerzan el aprendizaje permanente como hábito de equipo para entregar valor de forma sostenida en Orion.

Capítulo I: Introducción

1.1 Startup Profile

1.1.1 Descripción de la Startup

GosLogic es una startup de base tecnológica conformada por estudiantes de Ingeniería de Software de la Universidad Peruana de Ciencias Aplicadas (UPC). Nuestra organización nace con el propósito fundamental de optimizar la gestión empresarial a través del desarrollo de software de alta calidad, con un enfoque estratégico y especializado en el sector de la logística.

Nos distinguimos en el mercado por nuestro rigor técnico, priorizando siempre la aplicación de criterios sólidos de ingeniería en cada etapa del ciclo de vida del producto. Para GosLogic, la calidad no es solo un objetivo, sino un estándar que alcanzamos mediante el uso de arquitecturas modernas, patrones de diseño y metodologías ágiles.

Nuestra cultura organizacional se sustenta en dos pilares críticos: el aprendizaje continuo y autónomo, y la búsqueda constante de la excelencia técnica. Esto nos permite integrar rápidamente nuevos conocimientos y tecnologías para resolver problemas complejos de manera eficiente.

A largo plazo, la visión de GosLogic es convertirse en un aliado estratégico para las pequeñas y medianas empresas, liderando su transformación digital y optimizando sus procesos logísticos para hacerlas más competitivas en un entorno globalizado y altamente digitalizado.

1.1.2 Perfiles de integrantes del equipo

	Angelo Solano - u20231B775 Mi nombre es Angelo Solano, soy estudiante de Ingeniería de Software en la UPC. Me apasiona la tecnología y todo lo relacionado con el desarrollo de software. Me gusta enfrentarme a desafíos complejos y encontrar soluciones creativas. Estoy en constante aprendizaje, siempre buscando mejorar mis habilidades en programación y análisis de sistemas. Me considero una persona comprometida con mis proyectos y con ganas de crecer tanto profesionalmente como personalmente. Disfruto trabajar en equipo y siempre trato de aportar lo mejor de mí en todo lo que hago.
	Sergio Iglesias - u202316118 Mi nombre es Sergio Iglesias, tengo 20 años y estoy cursando mi 7to ciclo de la carrera de Ingeniería de Software en la UPC. Soy una persona proactiva, creativa y con gran pasión por la tecnología. Me destaco por mi capacidad de resolver problemas de manera eficiente y mi habilidad para trabajar colaborativamente en proyectos complejos. Estoy comprometido con el aprendizaje continuo y siempre busco aplicar las mejores prácticas en el desarrollo de software. Mi objetivo es contribuir significativamente al éxito de este proyecto y crecer profesionalmente en el campo de la ingeniería de software.
	Martin Gonzales - u202319724 Mi nombre es Martin Gonzales, tengo 20 años y estoy cursando mi 7to ciclo de la carrera de Ingeniería de Software en la UPC. Me caracterizo por mi interés en la programación, la tecnología y el aprendizaje continuo. Tengo una actitud analítica y organizada, lo que me permite desarrollar proyectos académicos y prácticos con dedicación, buscando siempre aplicar los conocimientos adquiridos de manera efectiva.
	Eduardo Cossar - u202312109 Mi nombre es Eduardo Cossar. Soy estudiante de la carrera de Ingeniería de Software, tengo 20 años y actualmente estoy cursando el septimo ciclo en la UPC. Me considero una persona responsable y comprometida con un gran interés por la tecnología. Como integrante de este equipo, me comprometo a brindar todo mi apoyo y participación activa para afrontar los desafíos que se presenten y dar lo mejor de mí para lograr el éxito de este proyecto.
	Maria Fernanda Mostajo - u202312874 Mi nombre es Maria Fernanda Mostajo, estoy estudiando la carrera de Ingeniería de Software en la UPC, tengo conocimientos en los lenguajes de programación C++, Python, HTML, CSS, JavaScript y SQL. Además, cuento con habilidades de trabajo en equipo, el cual me permitira realizar un buen trabajo y cumplir con los objetivos planteados en el tiempo establecido.

1.2 Solution Profile

1.2.1 Nombre del producto

El producto de software que desarrollaremos como startup es Orion. Orion es una plataforma SaaS (Software as a Service) multi-tenant orientada a la gestión logística y monitoreo de flotas en tiempo real, desarrollada bajo una arquitectura de microservicios y principios de Domain-Driven Design (DDD)

1.2.2 Antecedentes y problemática

Antecedentes

En el Perú, las PYMES representan el 99.1% del tejido empresarial formal y aportan el 20.2% del PBI nacional (PRODUCE, 2025). Sin embargo, el sector logístico atraviesa una dualidad crítica: mientras el comercio electrónico exige inmediatez, existe una brecha tecnológica profunda donde el 66% de las PYMES aún depende de procesos manuales o herramientas básicas como Excel para gestionar su cadena de suministro. Según el Ministerio de la Producción (PRODUCE), solo el 9% de estas empresas alcanza una madurez digital avanzada. En este escenario, Orion surge como una plataforma diseñada bajo paradigmas de Microservicios y Domain-Driven Design (DDD) para democratizar el acceso a herramientas de alta ingeniería que optimicen la logística y permitan a las PYMES competir en un mercado globalizado.

Problemática (5W 2h)

Who (¿Quién?)

El segmento objetivo son las PYMES peruanas del sector comercial y de servicios logísticos que gestionan un volumen crítico de inventario y distribución, pero que operan con un nivel de madurez digital "incipiente" o "encaminado"

What (¿Qué?)

Ineficiencia operativa sistémica caracterizada por la falta de trazabilidad en tiempo real, errores críticos de inventario y la incapacidad de integrar sistemas fragmentados (ventas, almacén y distribución).

Where (¿Dónde?)

El problema se concentra geográficamente en nodos de alta presión como Lima y Callao (donde se ubica el 63.2% de las MYPEs), y se manifiesta técnicamente en la desconexión entre el back-office logístico y el front-office digital.

When (¿Cuándo?)

La crisis de gestión se agudiza en picos estacionales como la Campaña Escolar (25-40% de ventas anuales), Fiestas Patrias y los Cyber Days, donde el aumento de demanda sobrepasa la capacidad de respuesta de los sistemas manuales.

Why (¿Por qué?)

La causa raíz es el uso de arquitecturas monolíticas y silos de datos que impiden la escalabilidad. Además, el alto costo de implementación de software tradicional (señalado por el 39% de empresas como barrera principal) limita la adopción tecnológica.

How (¿Cómo?)

Se manifiesta a través de un 20% de entregas fallidas en el primer intento y retrasos de hasta 15 días en nodos logísticos clave, lo que genera una pérdida de confianza que aleja al 89% de los clientes tras una mala experiencia.

How Much (¿Cuánto?)

La ineficiencia eleva los costos logísticos hasta un 21.1% sobre las ventas (frente al 15% en grandes corporaciones). Esto incluye pérdidas de aproximadamente 15 euros por cada entrega fallida y tasas de devolución (logística inversa) que alcanzan el 41% en temporadas altas.

1.2.3 Lean UX Process

1.2.3.1 Lean UX Problem Statement

Orion se plantea como una plataforma SaaS multi-tenant orientada a la gestión y telemetría de flotas vehiculares; las capacidades concretas que la materializan frente a los pain points del gestor de flota y del conductor se especifican en las Ideas de Solución que siguen a los planteamientos de problema.

Hemos observado que las empresas de transporte sufren altos costos operativos debido a fallas mecánicas imprevistas y la falta de visibilidad en tiempo real de sus vehículos, lo que repercute en la disponibilidad de sus activos.

¿Cómo podemos optimizar la gestión de mantenimiento y la visibilidad de la flota para reducir paradas no programadas?

Nuestra solución busca garantizar la privacidad y el aislamiento total de los datos mediante una arquitectura basada en TenantId, asegurando que la información sensible de una empresa sea inaccesible para sus competidores.

Hemos observado que las soluciones tradicionales no ofrecen un aislamiento seguro, lo que genera desconfianza y miedo a la fuga de información estratégica entre empresas del mismo sector.

¿Cómo puede nuestra arquitectura asegurar un aislamiento lógico total que brinde seguridad y confianza a cada cliente corporativo?

Nuestra solución busca proveer una herramienta móvil con enfoque offline-first para que los conductores registren eventos y telemetría sin interrupciones, independientemente de la cobertura de red.

Hemos observado que los conductores suelen transitar por zonas sin cobertura, lo que ocasiona la pérdida de registros críticos de jornada, ubicación y eventos de mantenimiento.

¿Cómo podemos garantizar que el registro de datos sea continuo y resiliente en zonas con conectividad intermitente?

Lean UX: Solution Ideas

Las siguientes funcionalidades traducen el alcance de Orion en entregables verificables y sustituyen formulaciones genéricas (por ejemplo, «monitoreo», «mantenimiento», «alertas» o «app» sin definir) por módulos con propósito y audiencia claros.

Panel de Gestión Multi-Tenant: Espacio administrativo web donde cada empresa gestiona usuarios, vehículos, conductores y políticas propias dentro de un contexto aislado por identificador de arrendatario (TenantId). Resuelve el temor a fugas de datos entre competidores y permite al gestor de flota operar con confianza sobre información sensible propia del negocio.
Dashboard de Telemetría en Tiempo Real: Vista operativa integrada con Google Maps que muestra la posición y el estado de los vehículos activos del tenant en curso. Resuelve la falta de visibilidad en tiempo real que incrementa la incertidumbre logística y dificulta decisiones oportunas ante desviaciones de ruta o demoras.
Motor Automatizado de Mantenimiento Preventivo: Componente que evalúa reglas según kilometraje acumulado y temporizadores de servicio para generar alertas preventivas (p. ej., cambio de aceite) antes de que el vehículo incurra en fallas correctivas costosas. Reduce paradas no programadas y alinea al gestor de flota con una política explícita de cuidado del activo.
Módulo de Gestión de Despacho: Herramienta para asignar de forma dinámica conductores a vehículos y a rutas concretas, incorporando horarios y estado operativo de las unidades en un único flujo de planificación. Atiende la dispersión de información entre planificación, disponibilidad de activos y ejecución en ruta.
Aplicación Móvil Offline-First: Cliente de campo para el conductor que permite iniciar y cerrar jornada, registrar eventos relevantes y transmitir ubicación de forma diferida cuando la red es intermitente o ausente. Elimina la pérdida de trazabilidad operativa en zonas rurales y estabiliza la ingesta de datos que alimentan telemetría y mantenimiento preventivo.

1.2.3.2 Lean UX Assumptions

Business Assumptions:

Creemos que nuestros usuarios necesitan un control estricto sobre el ciclo de vida de sus vehículos para evitar reparaciones correctivas costosas.
Estas necesidades se pueden satisfacer con un motor de reglas preventivas basado en telemetría (KM y tiempo) y un panel de control centralizado.
Nuestros clientes iniciales serán múltiples empresas de transporte de carga y logística en Perú que buscan optimizar su flota y gestionar personal de campo.
El valor más importante que un cliente quiere de nuestros servicios es la garantía de privacidad (multi-tenancy) y la reducción de incidentes mecánicos en ruta.
El cliente también va a obtener reportes de rendimiento por unidad, alertas automáticas y mayor vida útil de sus activos.
Vamos a obtener la mayoría de los clientes mediante venta directa B2B, demostraciones técnicas de seguridad de datos y presencia en ferias de logística.
Vamos a obtener ingresos mediante una suscripción mensual escalable basada en la cantidad de vehículos monitoreados.
Nuestra competencia en el mercado serán sistemas de GPS básicos, hojas de cálculo manuales o software legacy sin capacidades predictivas ni de aislamiento seguro.
Vamos a tener ventaja frente a nuestra competencia debido a la arquitectura segura por TenantId, la resiliencia offline de la app y la optimización de costos en telemetría (Google Maps).
El mayor riesgo del servicio es una posible vulneración de seguridad o fuga de información entre tenants, lo que afectaría la confianza de las empresas clientes y la continuidad del negocio.
Lo resolveremos implementando aislamiento lógico estricto por TenantId en toda la arquitectura, controles de acceso por roles, cifrado de datos en tránsito y en reposo, auditoría de accesos y pruebas periódicas de seguridad.

User Assumptions:

¿Quién es el usuario? Los gestores de flota que toman decisiones estratégicas y los conductores que operan las unidades en campo bajo diversas condiciones de red.
¿Qué problemas tiene nuestro producto que resolver? La incertidumbre sobre el estado mecánico de los vehículos, la falta de seguridad en plataformas compartidas y la pérdida de datos en zonas rurales o carreteras sin señal.
¿Qué características son importantes? Aislamiento lógico de datos, alertas preventivas automáticas, visualización en mapas con bajo consumo de datos y una app móvil que funcione sin internet.
¿Dónde encaja nuestro producto en su trabajo o vida? Se integra en la rutina diaria del conductor al iniciar jornada y en la gestión diaria del supervisor para monitorear indicadores de mantenimiento y ubicación.
¿Cuándo y cómo es nuestro producto usado? Se usa en tiempo real durante el trayecto de los vehículos y para la planificación de ingresos a taller. Se accede vía web (gestores) y móvil (conductores).
¿Cómo debe verse nuestro producto y cómo debe comportarse? Debe ser profesional, con dashboards de alto impacto visual para gestores, y una interfaz simplificada de alto contraste para conductores en ruta.

1.2.3.3 Lean UX Hypothesis

Hypothesis Statement 01
Creemos que el Panel de Gestión Multi-Tenant, al hacer cumplir el aislamiento lógico estricto mediante TenantId en todas las operaciones web administrativas, sabremos que hemos tenido éxito cuando el 100% de las pruebas de acceso cruzado entre empresas sea bloqueado y validado en QA.

Hypothesis Statement 02
Creemos que el Motor Automatizado de Mantenimiento Preventivo, al ejecutar reglas por kilometraje y tiempo (aceite, neumáticos y revisiones) sobre datos de telemetría, sabremos que hemos tenido éxito cuando las fallas no programadas se reduzcan en al menos 30% durante los primeros seis meses.

Hypothesis Statement 03
Creemos que el Módulo de Gestión de Despacho, al concentrar la asignación dinámica de conductores a vehículos y rutas junto con horarios y estado operativo de las unidades, sabremos que hemos tenido éxito cuando el tiempo de planificación diaria del gestor de flota se reduzca en 40%.

Hypothesis Statement 04
Creemos que, combinando la Aplicación Móvil Offline-First con capacitación guiada para los conductores, sabremos que hemos tenido éxito cuando al menos el 85% complete correctamente los flujos clave (inicio y fin de jornada, reporte de eventos y confirmación de ruta) en el primer mes.

Hypothesis Statement 05
Creemos que la Aplicación Móvil Offline-First, al persistir eventos y coordenadas en local y aplicar sincronización diferida al restablecer la red, sabremos que hemos tenido éxito cuando el 95% de los eventos registrados sin conectividad se sincronicen correctamente tras recuperar señal.

Hypothesis Statement 06
Creemos que el Dashboard de Telemetría en Tiempo Real (Google Maps), complementado con caché y control de la frecuencia de actualización cartográfica, sabremos que hemos tenido éxito cuando el costo mensual de consumo de mapas se reduzca en 35% sin deteriorar la precisión percibida del rastreo de vehículos activos.

1.2.3.4 Lean UX Canvas

1.3 Segmentos objetivo

Con el fin de llegar de manera efectiva a clientes potenciales, hemos definido a los siguientes segmentos objetivos para la plataforma Orion.

Segmento objetivo #1: Gestor de flota

Es el profesional responsable de la toma de decisiones estratégicas y la supervisión de la cadena de suministro dentro de la empresa cliente. Su principal preocupación es la eficiencia operativa y la reducción de los costos logísticos.

Aspectos demográficos:

Sexo: Masculino y femenino.

Rango de edad: 30–50 años.

Nivel socioeconómico: Clases B y C.

Aspectos geográficos:

Nacionalidad: Perú.

Zona geográfica: Urbana (principalmente Lima y provincias con alta actividad logística).

Aspectos psicográficos:

Intereses: Optimización de recursos, monitoreo en tiempo real, análisis de datos para la toma de decisiones y transformación digital.

Estilo de vida: Profesional orientado a resultados, acostumbrado a gestionar múltiples activos y personal bajo presión.

Actitudes: Busca herramientas que eliminen la incertidumbre y los procesos manuales (papel/Excel) para tener un control total sobre la ubicación y estado de sus unidades.

Necesidades clave:

Panel de control centralizado para visualizar la flota.

Reportes automáticos de cumplimiento de rutas.

Reducción de costos por kilómetros en vacío y mantenimiento preventivo.

Comportamiento digital:

Usuario de herramientas ERP, plataformas SaaS de gestión y aplicaciones de comunicación corporativa.

Segmento objetivo #2: Conductor de flota

Es el personal operativo encargado de la ejecución física del transporte y distribución. Es el usuario principal de la aplicación móvil de Orion durante sus jornadas laborales.

Aspectos demográficos:

Sexo: Masculino (mayoría según estadísticas del sector).

Rango de edad: 25–55 años.

Nivel socioeconómico: Clases C y D.

Aspectos geográficos:

Nacionalidad: Perú.

Zona geográfica: Rutas urbanas e interprovinciales.

Aspectos psicográficos:

Intereses: Facilidad de navegación, rapidez en el reporte de incidencias, herramientas que faciliten su trabajo diario sin añadir burocracia digital.

Estilo de vida: Dinámico, pasa la mayor parte del día en ruta y depende críticamente de su dispositivo móvil.

Actitudes: Práctico y directo; prefiere aplicaciones intuitivas que funcionen con pocos toques y que no consuman excesivos datos móviles.

Necesidades clave:

Hojas de ruta digitales claras y actualizadas.

Mecanismo simple para reportar entregas o problemas en la vía.

Navegación asistida y comunicación directa con la central.

Comportamiento digital:

Usuario habitual de aplicaciones de mensajería (WhatsApp) y navegación (Waze/Google Maps). Acostumbrado al uso de apps móviles pero con poca paciencia para flujos de usuario complejos.

Capítulo II: Requirements & Analysis

2.1 Competidores

2.1.2. Análisis Competitivo

Competitive Analysis Landscape
¿Por qué llevar a cabo este análisis?		El objetivo es definir el posicionamiento de Orion frente a soluciones líderes de última milla y telemática, identificando cómo nuestra arquitectura basada en microservicios y DDD resuelve las limitaciones de escalabilidad y altos costos de implementación en el mercado de PYMES logísticas.
		Orion (GosLogic)	Beetrack	SimpliRoute	Samsara
Perfil	Overview	Plataforma de gestión logística y flotas diseñada bajo principios de microservicios y DDD. Optimiza la última milla y la visibilidad operativa de PYMES peruanas mediante una solución ágil y escalable.	Software chileno (DispatchTrack) líder en Latam para trazabilidad de última milla. Se enfoca en el seguimiento de entregas y notificaciones al cliente final en tiempo real.	Plataforma de optimización de rutas impulsada por Inteligencia Artificial, orientada a reducir tiempos de planificación y costos de combustible mediante algoritmos avanzados.	Líder global en "operaciones conectadas". Combina hardware (sensores/cámaras) con software en la nube para seguridad, telemática y cumplimiento normativo a gran escala.
	Ventaja competitiva – ¿Qué valor ofrece al cliente?	Flexibilidad extrema y escalabilidad horizontal; permite integraciones locales rápidas y manejo de picos de demanda sin degradar el rendimiento del sistema.	Panel de control intuitivo y rapidez en la ejecución de pruebas de entrega (firmas/fotos). Alta presencia y soporte en la región.	Reducción de hasta un 80% en tiempo de planificación de rutas gracias a su potente algoritmo de IA y modelos de precios accesibles por vehículo.	Tecnología de punta en seguridad (IA para fatiga del conductor) y una infraestructura extremadamente robusta para flotas masivas.
Perfil de marketing	Mercado objetivo	Gestores de flota y conductores de PYMES en retail y distribución en Perú (enfocado en sectores con procesos manuales).	Empresas medianas y grandes de retail, consumo masivo y servicios de courier en Latinoamérica.	Empresas de logística y e-commerce que buscan optimizar rutas de entrega y reducir costos operativos.	Grandes corporaciones de transporte, construcción y logística con altos presupuestos y necesidades de seguridad crítica.
	Estrategias de marketing	Enfoque en ingeniería de software de alta calidad, consultoría técnica y demostración de retorno de inversión (ROI) acelerado.	Marketing de contenidos especializado en última milla, webinars y casos de éxito de grandes retailers.	Pruebas gratuitas basadas en el ahorro de combustible y campañas enfocadas en la eficiencia de su algoritmo de IA.	Ventas corporativas (B2B) de alto nivel, presencia en ferias tecnológicas globales y certificaciones de seguridad.
Perfil de producto	Productos & servicios	Gestión de flotas, monitoreo de conductores, despacho digital, integración con facturación local y analítica de rutas.	Planner Pro (rutas), Last Mile (seguimiento), widgets de seguimiento para el cliente final y reportes de entrega.	Optimización de rutas por IA, seguimiento en vivo, chat con conductores y módulos de gestión de entregas.	Telemática, cámaras de seguridad con IA, sensores de temperatura, gestión de mantenimiento y cumplimiento (ELD).
	Precios & costos	Modelo SaaS con tiers accesibles para PYMES; sin costos de hardware propietario (software-only).	Suscripción basada en volumen de guías/pedidos; costos adicionales por módulos de planificación avanzada.	Suscripción mensual de aprox. USD $40 por vehículo; costos de implementación que pueden ser elevados.	Costo elevado: requiere inversión inicial en hardware propietario y contratos anuales de software por activo.
Análisis SWOT	Fortalezas	Arquitectura de microservicios que evita fallos en cascada y diseño orientado al dominio (DDD) adaptado al Perú.	Dominio del mercado regional y plataforma muy fácil de usar para el despachador.	Algoritmo de planificación superior que ofrece resultados inmediatos en ahorro de tiempo.	Ecosistema tecnológico inigualable y estándares de seguridad de nivel mundial.
	Debilidades	Startup en etapa inicial con necesidad de validar marca en un mercado con competidores grandes.	Saturación del sistema (lentitud) ante grandes volúmenes y poca flexibilidad en la personalización de rutas.	Implementación lenta (hasta 3 meses) y ROI de largo plazo (16 meses) para pequeñas empresas.	Precios prohibitivos para PYMES peruanas y falta de conocimiento de las carencias viales locales.
	Oportunidades	Migración de empresas hacia arquitecturas Cloud Native; apertura del Puerto de Chancay.	Expansión global bajo el respaldo de DispatchTrack.	Integración de modelos predictivos de demanda para PYMES.	Creciente regulación de seguridad vial en mercados emergentes.
	Amenazas	Competidores con mayor espalda financiera bajando precios para captar el sector PYME.	Nuevos jugadores tecnológicos con arquitecturas más modernas y ágiles.	Sustitución por módulos logísticos básicos integrados en ERPs genéricos.	Inestabilidad económica regional que frene inversiones en hardware costoso.

2.1.2. Estrategias y tácticas frente a competidores

Para competir eficazmente frente a plataformas de última milla consolidadas y soluciones globales de telemática, Orion aplicará las siguientes estrategias y tácticas preliminares, considerando nuestras fortalezas y la oportunidad de mercado.

Modelo de implementación "Software-Only" y bajo costo

Estrategia: Eliminar la barrera de inversión en hardware propietario (GPS costosos) permitiendo que cualquier smartphone Android se convierta en un terminal logístico potente.

Tácticas:

Optimizar la aplicación móvil para un consumo mínimo de batería y recursos, compatible con equipos de gama entrada.
Implementar un importador masivo de rutas y clientes desde Excel para reducir el tiempo de onboarding de semanas a minutos.
Ofrecer un esquema de precios por "unidad activa", permitiendo a las PYMES escalar el costo según su demanda estacional.

Robustez técnica y disponibilidad (Cloud Native)

Estrategia: Garantizar que el sistema soporte picos de tráfico mediante una infraestructura elástica en la nube.

Tácticas:

Desplegar microservicios en contenedores que permitan escalado horizontal automático ante aumentos de carga.
Implementar una política de Aislamiento de Fallos para que una caída en el módulo de analítica no afecte el registro de entregas del conductor.

Operación en zonas de baja conectividad

Estrategia: Asegurar la continuidad operativa en la accidentada geografía peruana donde la señal móvil es inestable.

Tácticas:

Desarrollar capacidades Offline-First, permitiendo que el conductor registre fotos y firmas sin conexión y se sincronicen automáticamente al recuperar señal.
Optimizar la transferencia de datos mediante el envío de paquetes ligeros (JSON) para reducir el gasto de datos móviles del conductor.

Ecosistema e integraciones ágiles

Estrategia: Facilitar el flujo de información entre el conductor, el administrador y el cliente final mediante canales de uso cotidiano.

Tácticas:

Desarrollar una API RESTful documentada que facilite la integración futura con sistemas de facturación electrónica locales.
Implementar notificaciones automáticas vía WhatsApp para informar al administrador sobre incidentes críticos en ruta.

Adquisición y retención por usabilidad y valor técnico

Estrategia: Minimizar la curva de aprendizaje para segmentos con niveles variables de alfabetización digital.

Tácticas:

Diseñar una interfaz móvil intuitiva con botones de gran tamaño y flujos de máximo 3 pasos para confirmar una entrega.
Proporcionar documentación técnica clara y un centro de ayuda con micro-guías visuales para los gestores de flota.

2.2 Entrevistas

2.2.1. Diseño de entrevistas

Se realizó una investigación cualitativa mediante entrevistas a los segmentos objetivo de Orion: gestores de flota y conductores de campo. El objetivo fue identificar ineficiencias en los procesos logísticos actuales y validar cómo una arquitectura distribuida puede resolver la falta de visibilidad en tiempo real.

Se estructuraron bloques de preguntas para recopilar datos objetivos (herramientas y procesos) e información subjetiva (frustraciones y expectativas).

Segmento 1: Gestores de flota

Introducción y Contexto:

¿Cuál es su rol principal y cuántas unidades tiene a su cargo actualmente?
¿Cómo describe el proceso actual de asignación de rutas y despacho?

Identificación de Pain Points:

¿Cómo se entera actualmente si un conductor tiene un retraso o una incidencia en ruta?
¿Cuál es su mayor dificultad al momento de consolidar la información de las entregas al final del día?
¿Ha enfrentado problemas de "kilómetros en vacío" o rutas mal optimizadas que eleven sus costos?

Validación de la Solución:

Si pudiera ver en un solo panel el estado de todas sus unidades y recibir alertas automáticas, ¿cómo cambiaría su gestión diaria?
¿Qué indicadores (KPIs) son los más críticos para usted?

Segmento 2: Conductores de flota

Introducción y Contexto:

¿Cuántas paradas o entregas realiza en un día promedio?
¿Cómo recibe su hoja de ruta cada mañana?

Identificación de Pain Points:

¿Cuál es la tarea que más tiempo le quita durante el proceso de entrega (llenar formatos, buscar direcciones, esperar confirmación)?
¿Qué sucede cuando llega a un punto y no puede realizar la entrega? ¿Cómo lo reporta?
¿Qué es lo que más le molesta de las aplicaciones que ha usado anteriormente (ej. consume mucha batería, es lenta, difícil de entender)?

Validación de la Solución:

¿Qué tan útil le resultaría tener una lista digital donde solo con un botón pueda confirmar la entrega y adjuntar una foto como evidencia?
¿Preferiría una aplicación que funcione con pocos datos móviles y tenga botones grandes para uso rápido?

2.2.2. Registro de entrevistas

Segmento 1: Gestor de flota

Entrevista	1	Nombre	Melisa Espinoza Arroyo
Edad	30	Distrito	San Juan de Lurigancho
Captura de la entrevista:	Administradora logística con 8 años de experiencia, supervisa 25 unidades. Identifica como problema crítico la falta de un sistema en tiempo real, generando incertidumbre entre el conductor y la base. Reporta que el desorden en el carguío respecto a la hoja de ruta provoca exceso en consumo de combustible. Valora una solución que centralice el monitoreo de entregas, visualización de rutas y control automatizado de combustible por kilometraje para optimizar la rentabilidad.
URL de la grabación	Ver grabación
Timing	00:00 - 08:59

Entrevista	2	Nombre	Nathaly Solano Armas
Edad	28	Distrito	Ate
Captura de la entrevista:	Analista de distribución a cargo de 1,200 unidades. Identifica la fragmentación de aplicaciones y reportes informales por WhatsApp/llamadas como la mayor ineficiencia. El proceso de liquidación es manual basado en guías físicas. Destaca la falta de capacidad de reacción ante incidencias (puntos de entrega cerrados), lo que eleva costos. Busca una herramienta para optimizar tiempos de entrega y llevar un control estructurado en tiempo real para mejorar la capacidad de respuesta.
URL de la grabación	Ver grabación
Timing	00:00 - 11:02

Entrevista	3	Nombre	Sofía Martínez
Edad	41	Distrito	Ate
Captura de la entrevista:	Administradora logística con 9 años de experiencia coordinando 28 unidades. Su gestión actual depende de Excel y formatos impresos. Reporta frustración por la información dispersa al cierre del día y la imposibilidad de optimizar rutas manualmente. Valora de Orion la capacidad de centralizar la operación en un solo panel y generar alertas automáticas para reducir el retraso en la toma de decisiones y el retrabajo administrativo.
URL de la grabación	Ver grabación
Timing	00:00 - 03:40

Segmento 2: Conductor de flota

Entrevista	1	Nombre	Carlo Garcia
Edad	25	Distrito	San Borja
Captura de la entrevista:	Conductor con 3 años de experiencia (15-20 paradas diarias). Enfrenta fricción al copiar direcciones de WhatsApp hacia Waze, causando errores. La carga administrativa de llenar formularios manuales le quita 30 minutos al día. Requiere una solución centralizada para evidencias y reportes. Enfatiza la necesidad de funcionamiento offline debido a zonas con baja cobertura y una interfaz simplificada para evitar distracciones durante la conducción.
URL de la grabación	Ver grabación
Timing	00:00 - 08:39

Entrevista	2	Nombre	José Luis Pereda
Edad	29	Distrito	Santiago de Surco
Captura de la entrevista:	Conductor de reparto con 7 años de experiencia (12-18 paradas diarias). Su principal molestia es la dependencia de hojas impresas y la espera de indicaciones por llamada ante entregas fallidas. Considera que Orion debe permitir confirmaciones rápidas con fotos y ser eficiente en el uso de datos móviles. Su disposición al cambio es alta si la herramienta es práctica y elimina los cuellos de botella en la comunicación con el supervisor.
URL de la grabación	Ver grabación
Timing	00:00 - 03:43

Entrevista	3	Nombre	Mario Espinoza
Edad	26	Distrito	Villa El Salvador
Captura de la entrevista:	Conductor de distribución con 3 años de experiencia (10-14 paradas diarias). Reporta dificultades en la validación manual del cliente y el registro de incidencias por medios informales. Su frustración principal son las apps complejas con demasiados pasos que consumen mucha batería. Valora una experiencia ágil de pocos clics para registrar evidencias, validando la necesidad de una arquitectura orientada a la eficiencia operativa en campo.
URL de la grabación	Ver grabación
Timing	00:00 - 04:50

2.2.3. Análisis de entrevistas

Las entrevistas se realizaron a un total de 6 participantes: tres gestores logísticos y tres conductores de flota con experiencia en el sector de transporte y distribución en Lima. El objetivo fue identificar patrones comunes en sus frustraciones, expectativas y criterios para soluciones digitales en la gestión de última milla.

Segmento: Gestores de flota

Total entrevistados: 3

Edades: 28 a 41 años

Distritos: San Juan de Lurigancho, Ate

Experiencia promedio: 8.3 años

Unidades a cargo: Desde 25 hasta 1,200 unidades

Características objetivas

Reportan falta de visibilidad en tiempo real del estado de las entregas y ubicación de unidades: 3/3 (100%)
Utilizan herramientas manuales o informales (Excel, WhatsApp, papel) para la liquidación y reportes: 3/3 (100%)
Identifican que la desorganización en el carguío o rutas mal optimizadas eleva el gasto de combustible: 2/3 (66%)
Gestionan incidencias (puntos cerrados, retrasos) de forma reactiva mediante llamadas telefónicas: 3/3 (100%)
Valoran la centralización de indicadores (KPIs) de tiempo y costos en un solo panel: 3/3 (100%)

Características subjetivas

Sienten frustración por la dispersión de la información y el retrabajo administrativo al cierre del día: 3/3 (100%)
Perciben que la falta de estandarización en los reportes de los conductores dificulta la toma de decisiones: 2/3 (66%)
Muestran una alta disposición a adoptar tecnología Cloud Native si garantiza rapidez y orden operativo: 3/3 (100%)
Consideran que la capacidad de respuesta ante imprevistos es el factor más crítico de su éxito: 3/3 (100%)

Segmento: Conductores de flota

Total entrevistados: 3

Edades: 25 a 29 años

Distritos: San Borja, Santiago de Surco, Villa El Salvador

Experiencia promedio: 4.3 años

Carga operativa: Entre 10 y 20 paradas diarias

Características objetivas

Experimentan dificultades al manipular direcciones desde archivos PDF hacia apps de navegación: 2/3 (66%)
Pierden entre 20 a 30 minutos diarios rellenando formularios manuales o enviando evidencias por chat: 3/3 (100%)
Operan frecuentemente en zonas con conectividad inestable o nula señal de internet: 2/3 (66%)
Utilizan smartphones personales (principalmente Android) como herramienta de trabajo principal: 3/3 (100%)
Requieren capturar fotos o firmas como prueba de entrega (PoD): 3/3 (100%)

Características subjetivas

Frustración ante aplicaciones complejas, lentas o que consumen excesiva batería: 2/3 (66%)
Valoran una interfaz simplificada ("todo en uno") que evite el uso de múltiples apps simultáneas: 3/3 (100%)
Priorizan la facilidad de uso y botones visibles por encima de funciones avanzadas: 3/3 (100%)
Manifiestan desconfianza hacia sistemas que no garantizan el guardado de datos ante caídas de señal: 2/3 (66%)
Prefieren reportar incidentes mediante flujos predeterminados en lugar de notas de voz o llamadas: 2/3 (66%)

2.3 Needfinding

2.3.1 User Personas

Para desarrollar la propuesta de solución, se creará un User Persona por cada segmento objetivo. Este tendrá información relacionada a una persona que pertenezca al segmento objetivo respectivo ya sea información personal, gustos, usos tecnológicos u objetivos. De esta forma, se podrá dar una idea más clara de a qué publico nos estamos acercando con la idea de solución. Además, se realiza una conclusión del análisis de cada User Persona.

User Persona 1: Gestor de Flota

En esta imagen, se presenta información relacionada al user persona gestor de flota. El cuadro incluye una breve descripción de su perfil, así como sus principales objetivos y frustraciones dentro de su entorno laboral. Esta representación permite comprender mejor sus necesidades, como contar con una visión centralizada de la operación, optimizar la gestión de vehículos y conductores, y reducir fallas mediante mantenimiento preventivo. Esta información fue clave para plantear una solución que mejore la eficiencia operativa y facilite la toma de decisiones en tiempo real.

User Persona 2: Conductor de Flota

En esta imagen, se presenta información relacionada al user persona conductor de flota. El cuadro describe su perfil, junto con sus objetivos y frustraciones en su trabajo diario. Esta representación ayuda a entender sus necesidades, como disponer de instrucciones claras, contar con una herramienta simple de usar y poder trabajar incluso en condiciones de conectividad limitada. Esta información fue fundamental para diseñar una solución que simplifique sus tareas, reduzca la dependencia de procesos manuales y mejore su experiencia durante la ejecución de rutas.

2.3.2 User Task Matrix

Tarea	Carlos Ramirez (Gestor de flota / Jefe de operaciones)	Luis Torres (Conductor)
Monitorear vehículos en tiempo real	Often – High → Necesita visibilidad constante de la flota para tomar decisiones rápidas y mantener el control operativo.	Rarely – Low → No necesita monitorear toda la flota, sino seguir su propia ruta y recibir indicaciones claras.
Revisar alertas de mantenimiento preventivo	Often – High → Es clave para prevenir fallas mecánicas, reducir costos y programar mantenimientos oportunamente.	Sometimes – Medium → Puede recibir avisos básicos o detectar señales del vehículo, pero no gestiona el mantenimiento de toda la flota.
Gestionar rutas y horarios	Often – High → Debe optimizar rutas, asignaciones y tiempos para mejorar la eficiencia de la operación.	Often – High → Necesita consultar y cumplir las rutas y horarios asignados durante su jornada.
Registrar inicio y fin de jornada	Sometimes – Medium → Le interesa supervisar el cumplimiento, aunque normalmente no realiza el registro directamente.	Often – High → Es una acción recurrente en su trabajo diario y debe ser rápida, clara y sencilla.
Reportar incidencias o eventos en ruta	Sometimes – High → Necesita recibir esta información para reaccionar, coordinar soluciones y evitar retrasos mayores.	Often – High → Debe reportar problemas, retrasos o incidencias durante el recorrido de forma simple.
Consultar reportes operativos	Often – High → Usa reportes para analizar desempeño, costos, cumplimiento y tomar decisiones basadas en datos.	Rarely – Low → No suele requerir reportes analíticos, porque su enfoque principal es la ejecución de la ruta.
Coordinar con conductores / central	Often – High → Requiere comunicación constante con el personal operativo para mantener la operación alineada.	Often – Medium → Necesita recibir instrucciones y comunicar avances, dudas o problemas durante el trayecto.
Usar la plataforma o app de manera sencilla	Sometimes – Medium → Valora una interfaz clara, aunque puede adaptarse a herramientas más completas.	Often – High → Necesita una app simple, rápida y sin complicaciones para no afectar su trabajo en campo.
Trabajar sin conexión (offline)	Sometimes – Medium → Le importa que la operación no se detenga, aunque no sea quien use directamente el modo offline.	Often – High → Es fundamental porque puede transitar por zonas con poca o nula conectividad.
Tomar decisiones basadas en datos	Often – High → Es una de sus principales necesidades para mejorar la eficiencia y reducir pérdidas operativas.	Rarely – Low → Sus decisiones suelen ser más inmediatas y operativas que analíticas.

Tarea Carlos Ramirez (Gestor de flota / Jefe de operaciones) Luis Torres (Conductor) Monitorear vehículos en tiempo real Often – High → Necesita visibilidad constante de la flota para tomar decisiones rápidas y mantener el control operativo. Rarely – Low → No necesita monitorear toda la flota, sino seguir su propia ruta y recibir indicaciones claras. Revisar alertas de mantenimiento preventivo Often – High → Es clave para prevenir fallas mecánicas, reducir costos y programar mantenimientos oportunamente. Sometimes – Medium → Puede recibir avisos básicos o detectar señales del vehículo, pero no gestiona el mantenimiento de toda la flota. Gestionar rutas y horarios Often – High → Debe optimizar rutas, asignaciones y tiempos para mejorar la eficiencia de la operación. Often – High → Necesita consultar y cumplir las rutas y horarios asignados durante su jornada. Registrar inicio y fin de jornada Sometimes – Medium → Le interesa supervisar el cumplimiento, aunque normalmente no realiza el registro directamente. Often – High → Es una acción recurrente en su trabajo diario y debe ser rápida, clara y sencilla. Reportar incidencias o eventos en ruta Sometimes – High → Necesita recibir esta información para reaccionar, coordinar soluciones y evitar retrasos mayores. Often – High → Debe reportar problemas, retrasos o incidencias durante el recorrido de forma simple. Consultar reportes operativos Often – High → Usa reportes para analizar desempeño, costos, cumplimiento y tomar decisiones basadas en datos. Rarely – Low → No suele requerir reportes analíticos, porque su enfoque principal es la ejecución de la ruta. Coordinar con conductores / central Often – High → Requiere comunicación constante con el personal operativo para mantener la operación alineada. Often – Medium → Necesita recibir instrucciones y comunicar avances, dudas o problemas durante el trayecto. Usar la plataforma o app de manera sencilla Sometimes – Medium → Valora una interfaz clara, aunque puede adaptarse a herramientas más completas. Often – High → Necesita una app simple, rápida y sin complicaciones para no afectar su trabajo en campo. Trabajar sin conexión (offline) Sometimes – Medium → Le importa que la operación no se detenga, aunque no sea quien use directamente el modo offline. Often – High → Es fundamental porque puede transitar por zonas con poca o nula conectividad. Tomar decisiones basadas en datos Often – High → Es una de sus principales necesidades para mejorar la eficiencia y reducir pérdidas operativas. Rarely – Low → Sus decisiones suelen ser más inmediatas y operativas que analíticas.

2.3.3 Empathy Maps

El Empathy Mapping ayuda a entender de manera más profunda a nuestro User Persona. Con esta herramienta, capturamos lo que el usuario siente, dice, piensa y hace desde la perspectiva del propio usuario. Además, nos ayuda a identificar dolores y metas qué desea cumplir que nos serán útiles para formar ideas de diseño útiles para el producto que servirá como solución. Finalmente, cada mapa de empatía se diseñó en la aplicación UXPressia.

User Persona 1: Gestor de Flota

En esta primera imagen que se muestra a continuación, se visualiza el empathy map del user persona gestor de flota. En esta misma, se detalla lo que el usuario siente, dice, piensa y hace al momento de gestionar la operación diaria de la flota vehicular. Se busca comprender cómo enfrenta la falta de información centralizada, la presión por mantener la eficiencia y la necesidad de anticiparse a fallas, lo cual permite identificar oportunidades de mejora en la toma de decisiones y en la optimización de procesos.

User Persona 2: Conductor de Flota

En esta segunda imagen que se muestra a continuación, se visualiza el empathy map del user persona conductor de flota. En esta, se describe lo que el usuario siente, dice, piensa y hace durante la ejecución de sus rutas y el cumplimiento de sus tareas diarias. Se pretende entender las dificultades que enfrenta, como la falta de claridad en instrucciones, los problemas de conectividad y la dependencia de procesos manuales, con el fin de proponer soluciones que faciliten su trabajo y mejoren su experiencia.

2.3.4 As-is Scenario Mapping

En el As-Is Scenario Map se representa la situación actual que experimentan los usuarios antes de la implementación de la solución propuesta. Este mapa permite identificar los principales problemas y limitaciones que enfrentan los user persona, evidenciando aquellos puntos críticos que dificultan el cumplimiento de sus objetivos y que deben ser abordados en el diseño del sistema.

De esta manera, se desarrollaron los mapas AS-IS para cada user persona considerando su contexto dentro de la gestión de flotas. El proceso inició con la identificación de las fases más relevantes en sus actividades diarias. Posteriormente, en cada fase se definieron las acciones que realizan habitualmente. Luego, se analizaron los pensamientos que podrían surgir durante la ejecución de dichas actividades, adoptando la perspectiva de cada usuario. Finalmente, se identificaron las emociones asociadas a estos pensamientos, lo que permitió reconocer los aspectos negativos predominantes en la experiencia actual y detectar oportunidades de mejora que serán consideradas en la propuesta de solución.

User Persona 1: Gestor de Flota

En esta primera imagen que se muestra a continuación, se visualiza el As-Is Scenario Map del user persona gestor de flota. En esta misma, se detalla el proceso que sigue al iniciar su jornada y gestionar la operación diaria sin un sistema centralizado. Para ello, revisa información en distintas fuentes, coordina manualmente con los conductores y atiende incidencias conforme aparecen, lo que genera retrasos, desorganización y una alta carga operativa.

User Persona 2: Conductor de Flota

En esta segunda imagen que se muestra a continuación, se visualiza el As-Is Scenario Map del user persona conductor de flota. En esta, se describe el proceso que realiza desde que inicia su jornada hasta que finaliza sus actividades, dependiendo de instrucciones recibidas por medios informales. Para ello, revisa rutas de forma manual, se comunica constantemente con su supervisor y reporta su jornada de manera poco estructurada, lo que dificulta su trabajo y genera ineficiencias.

Capítulo III: Requirements Specification

3.1 To-Be Scenario Mapping

En el To-Be Scenario Map se representa la experiencia del usuario considerando la implementación de la solución propuesta. Este mapa se construye a partir del análisis del AS-IS, con el objetivo de evidenciar cómo el sistema puede mejorar las actividades y procesos que realiza cada user persona en su día a día.

De esta manera, se desarrollaron los mapas TO-BE para cada user persona tomando como base las situaciones identificadas previamente. El proceso inició con la revisión de cada fase del AS-IS, identificando oportunidades de mejora que la plataforma Orion podría ofrecer. Posteriormente, se redefinieron aquellas actividades que serían optimizadas mediante el uso del sistema, incorporando automatización, centralización de la información y monitoreo en tiempo real. Luego, se analizaron los pensamientos que surgirían al utilizar la solución, adoptando la perspectiva de cada usuario. A continuación, se identificaron las emociones asociadas a estos nuevos escenarios, permitiendo evidenciar una mejora en la experiencia general. Finalmente, se evaluaron los aspectos positivos predominantes y cómo la solución contribuye a reducir los problemas detectados en la situación actual.

User Persona 1: Gestor de Flota

Al comparar ambos mapas, se evidencia una mejora significativa en la gestión de la flota vehicular del gestor de flota. Esta mejora no solo optimiza las tareas operativas, sino que también le permite dedicar más tiempo a actividades estratégicas como la planificación y la toma de decisiones. Además, se reduce la ocurrencia de fallas inesperadas y descoordinaciones, gracias al monitoreo en tiempo real y a las alertas de mantenimiento preventivo, lo que facilita un mayor control de la operación.

User Persona 2: Conductor de Flota

Al comparar ambos mapas, se observa una mejora en la experiencia del conductor de flota durante la ejecución de sus actividades. Esta mejora simplifica sus tareas diarias, permitiéndole trabajar con mayor claridad y menor esfuerzo. Asimismo, se reducen problemas como la falta de información o la dependencia de procesos manuales, ya que ahora cuenta con una aplicación que le brinda instrucciones claras, seguimiento de su recorrido y registro automático de su jornada, mejorando así su desempeño y comodidad en el trabajo.

3.2 User Stories

En esta sección se presentan las épicas funcionales del producto Orion, redactadas para organizar las User Stories que guían el alcance del proyecto. Los requisitos no funcionales se detallan de forma separada en la sección 3.2.3.

3.2.1 Epics

Epic ID	Título	Descripción
E01	Gestión Multi-Tenant y Seguridad	Como administrador de plataforma, quiero gestionar tenants, accesos y protección de información, para garantizar aislamiento seguro entre empresas clientes.
E02	Monitoreo y Telemetría	Como gestor de flota, quiero visualizar posiciones, rutas y eventos en tiempo real, para mejorar el control operativo diario.
E03	Mantenimiento Preventivo	Como gestor de flota, quiero programar mantenimientos y controlar el estado técnico de las unidades, para reducir fallas y evitar multas.
E04	Gestión de Despacho Operativo	Como coordinador de operaciones, quiero asignar conductores, vehículos y rutas de forma dinámica, para optimizar recursos según la demanda.
E05	App Móvil del Conductor	Como conductor, quiero registrar mi jornada y reportar incidencias desde la app, para mantener trazabilidad y respuesta rápida en campo.

3.2.2 User Stories

Requisitos definidos junto con el conjunto de User Stories y Epics para los requisitos identificados. Los User Stories incluyen Acceptance Criteria.

Epic / User Story ID	Título	Descripción	Criterios de Aceptación	Relacionado con (Epic ID)
US01	Configuración de Tenant	Como administrador del sistema, quiero crear perfiles de empresa únicos, para que cada cliente tenga su propio espacio de trabajo aislado.	Escenario 1: Crear tenant con datos válidos DADO que el administrador está autenticado CUANDO registra una empresa con datos completos y válidos ENTONCES el sistema debe crear un tenantId único Escenario 2: Validar campos obligatorios DADO que el administrador está en el formulario de creación CUANDO intenta guardar sin completar campos obligatorios ENTONCES el sistema debe bloquear el registro y mostrar los campos faltantes Escenario 3: Evitar duplicidad de empresa DADO que ya existe una empresa con el mismo identificador tributario CUANDO el administrador intenta crearla nuevamente ENTONCES el sistema debe rechazar la operación por duplicidad Escenario 4: Confirmar estado inicial del tenant DADO que el tenant fue creado correctamente CUANDO el administrador consulta su detalle ENTONCES el sistema debe mostrarlo como activo con configuración base	E01
US02	Aislamiento de Datos	Como gestor de flota, quiero que mis datos de conductores y rutas sean invisibles para otras empresas, para garantizar la privacidad comercial.	Escenario 1: Bloquear acceso entre tenants DADO que un usuario pertenece al tenant A CUANDO intenta consultar datos del tenant B ENTONCES el sistema debe denegar el acceso Escenario 2: Restringir resultados al tenant autenticado DADO que el usuario realiza una búsqueda de rutas o conductores CUANDO el sistema procesa la consulta ENTONCES solo debe devolver información del tenant autenticado Escenario 3: Verificar fuga de datos DADO que se ejecutan pruebas de seguridad inter-tenant CUANDO se revisan los resultados ENTONCES no debe existir exposición de datos entre empresas	E01
US03	Gestión de Usuarios y Roles	Como gestor de flota, quiero invitar usuarios con roles específicos, para delegar la supervisión de la flota.	Escenario 1: Invitar usuario con rol DADO que el gestor tiene permisos de administración CUANDO envía una invitación y asigna un rol ENTONCES el sistema debe registrar la invitación en estado pendiente Escenario 2: Completar registro del invitado DADO que el usuario recibió su invitación CUANDO acepta y completa sus datos ENTONCES el sistema debe asociarlo al tenant correcto Escenario 3: Restringir permisos por rol DADO que el usuario tiene rol monitor CUANDO intenta ingresar a módulos administrativos ENTONCES el sistema debe bloquear el acceso Escenario 4: Auditar cambios de rol DADO que un administrador modifica un rol CUANDO confirma el cambio ENTONCES el sistema debe actualizar permisos y guardar trazabilidad	E01
US04	Autenticación JWT	Como gestor, quiero acceder mediante tokens JWT, para asegurar autenticación robusta en el sistema.	Escenario 1: Login exitoso DADO que el usuario ingresa credenciales válidas CUANDO presiona Iniciar sesión ENTONCES el sistema debe emitir un token JWT válido Escenario 2: Login fallido DADO que el usuario ingresa credenciales incorrectas CUANDO intenta autenticarse ENTONCES el sistema debe mostrar mensaje de error de autenticación Escenario 3: Acceso con token inválido DADO que el usuario consume una API protegida con token inválido o vencido CUANDO el backend valida el token ENTONCES debe responder con estado no autorizado	E01
US05	Expiración de Sesión	Como gestor, quiero que la sesión expire automáticamente tras inactividad, para reducir el riesgo de acceso no autorizado.	Escenario 1: Expirar sesión por inactividad DADO que el usuario tiene sesión activa CUANDO transcurren 30 minutos sin interacción ENTONCES el sistema debe expirar la sesión automáticamente Escenario 2: Solicitar reautenticación DADO que la sesión ya expiró CUANDO el usuario intenta acceder a un módulo protegido ENTONCES el sistema debe redirigirlo al inicio de sesión Escenario 3: Mantener sesión con actividad DADO que el usuario mantiene actividad dentro del periodo permitido CUANDO navega entre módulos ENTONCES el sistema debe conservar su sesión activa	E01
US06	Cifrado HTTPS de Telemetría	Como administrador, quiero que toda la telemetría se transmita vía HTTPS, para evitar interceptación de datos.	Escenario 1: Aceptar tráfico seguro DADO que la telemetría se envía por HTTPS CUANDO llega al backend ENTONCES el sistema debe procesarla correctamente Escenario 2: Rechazar tráfico no seguro DADO que se intenta enviar telemetría por HTTP CUANDO el request entra al sistema ENTONCES debe ser rechazado o redirigido a HTTPS Escenario 3: Verificar cumplimiento de cifrado DADO una auditoría de comunicaciones CUANDO se revisan los endpoints productivos ENTONCES toda transmisión de telemetría debe estar cifrada	E01
US07	Filtro Obligatorio por TenantId	Como arquitecto, quiero que toda consulta a BD incluya TenantId, para asegurar 0% de fuga entre empresas.	Escenario 1: Aplicar filtro obligatorio DADO que se ejecuta una consulta de negocio CUANDO accede a la base de datos ENTONCES la consulta debe incluir tenantId obligatoriamente Escenario 2: Bloquear consultas inseguras DADO que una consulta no incluye tenantId CUANDO intenta ejecutarse ENTONCES el sistema debe rechazarla por política de seguridad Escenario 3: Validar aislamiento en integración DADO pruebas de integración multi-tenant CUANDO se prueban endpoints de lectura ENTONCES solo deben retornar datos del tenant autenticado Escenario 4: Registrar accesos críticos DADO una operación sensible sobre datos CUANDO se completa la consulta ENTONCES el sistema debe guardar traza de auditoría	E01
US08	Visualización en Mapa	Como gestor de flota, quiero ver la ubicación en tiempo real de mis vehículos, para optimizar la logística.	Escenario 1: Mostrar unidades activas DADO que existen vehículos transmitiendo GPS CUANDO el gestor abre el mapa ENTONCES el sistema debe mostrar marcadores por unidad Escenario 2: Actualizar posiciones en tiempo real DADO que llegan nuevas coordenadas CUANDO el evento es procesado ENTONCES la ubicación en mapa debe refrescarse automáticamente Escenario 3: Identificar unidad sin señal DADO que una unidad deja de enviar eventos CUANDO supera el umbral de inactividad ENTONCES el sistema debe marcarla como desactualizada Escenario 4: Filtrar visualización DADO múltiples unidades visibles CUANDO el gestor aplica filtros por estado o zona ENTONCES el mapa debe mostrar solo las unidades filtradas	E02
US09	Historial de Rutas	Como gestor de flota, quiero consultar el recorrido histórico de una unidad, para verificar el cumplimiento de las rutas.	Escenario 1: Consultar por fecha y unidad DADO una unidad seleccionada CUANDO el gestor define un rango de fechas ENTONCES el sistema debe mostrar el recorrido histórico correspondiente Escenario 2: Ver detalle de traza DADO una ruta histórica disponible CUANDO el gestor abre su detalle ENTONCES debe visualizar hora, posición y eventos asociados Escenario 3: Manejar consulta sin resultados DADO un rango sin datos registrados CUANDO se ejecuta la búsqueda ENTONCES el sistema debe informar que no existen recorridos	E02
US10	Gestión de Geocercas	Como gestor de flota, quiero definir zonas permitidas, para recibir alertas cuando un vehículo salga del perímetro autorizado.	Escenario 1: Crear geocerca DADO que el gestor está en el módulo de geocercas CUANDO define un perímetro válido y lo guarda ENTONCES el sistema debe registrar la geocerca para su tenant Escenario 2: Editar geocerca DADO una geocerca existente CUANDO el gestor modifica nombre o perímetro ENTONCES el sistema debe actualizar la configuración Escenario 3: Eliminar geocerca DADO una geocerca activa CUANDO el gestor solicita eliminarla ENTONCES el sistema debe pedir confirmación antes de borrar Escenario 4: Asociar geocerca a operación DADO una geocerca creada CUANDO se asocia a una flota o ruta ENTONCES debe quedar habilitada para monitoreo	E02
US11	Alertas por Geocerca	Como gestor de flota, quiero recibir alertas si un vehículo sale del perímetro autorizado, para actuar oportunamente.	Escenario 1: Detectar salida de perímetro DADO que el vehículo está dentro de una geocerca CUANDO cruza el límite hacia afuera ENTONCES el sistema debe generar una alerta inmediata Escenario 2: Mostrar información de alerta DADO una alerta generada CUANDO el gestor la revisa ENTONCES debe ver unidad, hora y ubicación exacta Escenario 3: Registrar reingreso DADO que el vehículo vuelve al perímetro CUANDO reingresa a la geocerca ENTONCES el sistema debe registrar evento de normalización Escenario 4: Priorizar alertas simultáneas DADO múltiples alertas activas CUANDO se listan en el panel ENTONCES el sistema debe ordenarlas por criticidad y recencia	E02
US12	Alertas de Kilometraje	Como gestor de flota, quiero recibir alertas automáticas de cambio de aceite, para evitar daños mecánicos por exceso de uso.	Escenario 1: Generar alerta por umbral DADO un umbral configurado para mantenimiento CUANDO el kilometraje supera el límite ENTONCES el sistema debe crear una alerta automática Escenario 2: Notificar al responsable DADO una alerta de mantenimiento activa CUANDO el gestor abre notificaciones ENTONCES debe visualizar unidad afectada y tipo de servicio recomendado Escenario 3: Reiniciar ciclo tras mantenimiento DADO que se registró el servicio realizado CUANDO se confirma el mantenimiento ENTONCES el sistema debe reiniciar el ciclo de control de kilometraje Escenario 4: Visualizar próximos mantenimientos DADO varias unidades registradas CUANDO el gestor consulta el panel ENTONCES debe ver el orden de prioridad por proximidad al umbral	E03
US13	Registro de Activos	Como gestor de flota, quiero registrar el estado de neumáticos y frenos, para proyectar gastos de renovación anual.	Escenario 1: Registrar estado técnico DADO una unidad seleccionada CUANDO el gestor registra estado de frenos y neumáticos ENTONCES el sistema debe guardar estado, fecha y responsable Escenario 2: Consultar historial técnico DADO que existen inspecciones previas CUANDO el gestor consulta la unidad ENTONCES debe visualizar el historial cronológico de evaluaciones Escenario 3: Alertar condición crítica DADO que una inspección reporta estado crítico CUANDO se guarda el registro ENTONCES el sistema debe emitir una alerta preventiva	E03
US14	Control de Revisiones Técnicas	Como gestor de flota, quiero programar revisiones legales, para evitar multas por documentos vencidos.	Escenario 1: Programar vencimientos DADO un vehículo con documentación vigente CUANDO se registran fechas de revisión ENTONCES el sistema debe programar recordatorios automáticos Escenario 2: Alertar vencimiento próximo DADO una revisión cercana a su fecha límite CUANDO entra en ventana de alerta ENTONCES el sistema debe notificar al responsable Escenario 3: Marcar riesgo legal DADO una revisión vencida CUANDO el gestor revisa el estado del vehículo ENTONCES el sistema debe mostrar riesgo legal activo	E03
US15	Asignación Dinámica	Como gestor de flota, quiero asignar conductores a vehículos y rutas específicas según la demanda del día.	Escenario 1: Asignar despacho válido DADO conductores, vehículos y rutas disponibles CUANDO el gestor confirma la asignación ENTONCES el sistema debe registrar el despacho exitosamente Escenario 2: Bloquear conductor no disponible DADO un conductor fuera de turno CUANDO el gestor intenta asignarlo ENTONCES el sistema debe impedir la asignación Escenario 3: Detectar conflicto de recurso DADO un vehículo ocupado en el mismo horario CUANDO se intenta asignar otra ruta ENTONCES el sistema debe mostrar conflicto de solapamiento Escenario 4: Reasignar recurso DADO una asignación existente CUANDO el gestor cambia conductor o unidad ENTONCES el sistema debe actualizar el despacho y notificar a involucrados Escenario 5: Mantener trazabilidad DADO cualquier alta o cambio de asignación CUANDO se guarda la operación ENTONCES el sistema debe registrar usuario, fecha y motivo del cambio	E04
US16	Disponibilidad de Personal	Como gestor de flota, quiero ver quién está en turno activo, para no sobrepasar las horas permitidas de manejo.	Escenario 1: Visualizar estado de turnos DADO conductores registrados CUANDO el gestor abre el panel de disponibilidad ENTONCES debe ver estado por turno y zona Escenario 2: Controlar límite de horas DADO un conductor con horas máximas excedidas CUANDO se intenta asignar una ruta ENTONCES el sistema debe bloquear la asignación Escenario 3: Reflejar cambios en tiempo real DADO que un conductor cambia de estado CUANDO se actualiza su turno ENTONCES el panel debe reflejar el cambio inmediatamente Escenario 4: Filtrar personal elegible DADO múltiples conductores activos CUANDO el gestor aplica filtros operativos ENTONCES el sistema debe mostrar solo los aptos para asignación	E04
US17	Reporte de Jornada	Como conductor, quiero marcar inicio y fin de jornada desde la app, para que mi tiempo laborado quede registrado.	Escenario 1: Iniciar jornada DADO conductor autenticado en la app CUANDO presiona Iniciar jornada ENTONCES el sistema debe registrar la hora de inicio Escenario 2: Finalizar jornada DADO una jornada iniciada CUANDO presiona Finalizar jornada ENTONCES el sistema debe registrar hora de cierre y duración Escenario 3: Evitar cierre inválido DADO que no existe jornada iniciada CUANDO intenta finalizar jornada ENTONCES el sistema debe bloquear la acción e informar el motivo	E05
US18	Recepción de Horarios	Como conductor, quiero ver mi cronograma diario en el móvil, para saber qué unidad debo operar.	Escenario 1: Ver cronograma del día DADO que el conductor tiene asignaciones CUANDO abre el módulo de cronograma ENTONCES el sistema debe mostrar ruta, hora y unidad asignada Escenario 2: Actualizar cambios de despacho DADO que el gestor modifica una asignación CUANDO el cambio se confirma ENTONCES la app del conductor debe reflejar la actualización Escenario 3: Mostrar ausencia de tareas DADO que el conductor no tiene asignaciones CUANDO ingresa al cronograma ENTONCES el sistema debe mostrar estado sin tareas programadas	E05
US19	Reporte de Incidentes	Como conductor, quiero enviar fotos de fallas mecánicas desde la app, para que el gestor programe el taller de inmediato.	Escenario 1: Reportar con evidencia DADO una falla detectada en ruta CUANDO el conductor registra descripción y adjunta fotografía ENTONCES el sistema debe crear el incidente con evidencia Escenario 2: Validar campos obligatorios DADO un reporte incompleto CUANDO intenta enviarlo ENTONCES el sistema debe bloquear el registro y mostrar errores Escenario 3: Notificar al gestor DADO un incidente registrado correctamente CUANDO el sistema lo procesa ENTONCES debe notificar al gestor de flota Escenario 4: Priorizar incidencia crítica DADO una incidencia de severidad alta CUANDO se clasifica el reporte ENTONCES el sistema debe destacarlo con prioridad máxima	E05
US20	Botón de Pánico	Como conductor, quiero activar una alerta de emergencia, para que la central reciba mi ubicación exacta al instante.	Escenario 1: Emitir alerta de emergencia DADO conductor en operación CUANDO presiona el botón de pánico ENTONCES el sistema debe enviar alerta con ubicación GPS actual Escenario 2: Recepción en central DADO una alerta emitida CUANDO llega al centro de monitoreo ENTONCES la central debe visualizar unidad, hora y coordenadas Escenario 3: Reintento por conectividad DADO conectividad inestable CUANDO falle el primer envío ENTONCES la app debe reintentar automáticamente hasta confirmar recepción Escenario 4: Trazabilidad de atención DADO que la alerta fue recibida CUANDO el operador inicia atención ENTONCES el sistema debe registrar el estado del caso Escenario 5: Cancelación controlada DADO una activación accidental CUANDO el conductor solicita cancelar la alerta ENTONCES el sistema debe requerir validación y dejar registro del evento	E05
US21	Persistencia Local Offline	Como conductor, quiero que la app móvil guarde eventos offline en SQLite, para garantizar la experiencia en zonas sin señal.	Escenario 1: Guardar evento sin red DADO ausencia de conectividad CUANDO el conductor registra un evento ENTONCES la app debe almacenarlo en SQLite local Escenario 2: Persistencia tras reinicio DADO eventos pendientes guardados localmente CUANDO la app se cierra y se vuelve a abrir ENTONCES los eventos deben mantenerse disponibles Escenario 3: Consultar cola local DADO múltiples eventos offline CUANDO el conductor revisa pendientes ENTONCES el sistema debe mostrarlos en orden cronológico	E05
US22	Sincronización Inteligente	Como conductor, quiero que la app sincronice automáticamente los datos pendientes al recuperar señal, para no perder información registrada en modo offline.	Escenario 1: Sincronizar al recuperar señal DADO que vuelve la conectividad CUANDO inicia el proceso de sincronización ENTONCES la app debe enviar la cola pendiente automáticamente Escenario 2: Aplicar backoff exponencial DADO un error temporal del servidor CUANDO falle un intento de envío ENTONCES el sistema debe reintentar con backoff exponencial Escenario 3: Evitar duplicados DADO un evento ya confirmado por backend CUANDO finaliza la sincronización ENTONCES no debe reenviarse ni duplicarse Escenario 4: Limpiar pendientes enviados DADO que todos los eventos fueron aceptados CUANDO termina el proceso ENTONCES la app debe marcar la cola local como sincronizada	E05

3.2.3 Requisitos No Funcionales (Atributos de Calidad)

RNF ID	Pilar	Título	Descripción	Escenarios de Calidad
RNF01	Interoperabilidad	Integración Estandarizada con Servicios Externos	Como integrador de GosLogic, quiero interoperar con APIs externas de mapasx y GPS mediante contratos versionados, para asegurar integración continua con bajo impacto ante cambios de proveedores.	Escenario 1: DADO que Orion consume Google Maps y GPS de terceros con contratos OpenAPI versionados, CUANDO se despliega una nueva versión de integración, ENTONCES el 100% de pruebas de contrato debe aprobar y no debe haber rupturas backward-compatible en producción. Escenario 2: DADO que un proveedor externo presenta indisponibilidad temporal, CUANDO se superan 5 errores consecutivos en 60 segundos, ENTONCES Orion debe activar modo degradado en menos de 2 segundos y mantener operativas las funciones internas críticas. Escenario 3: DADO una actualización mayor de versión en un proveedor externo, CUANDO el equipo ejecuta pruebas de integración en preproducción, ENTONCES el tiempo de adaptación del conector no debe exceder 2 sprints. Escenario 4: DADO una operación continua con integraciones activas, CUANDO se monitorean transacciones API por día, ENTONCES al menos el 99% de solicitudes válidas debe completarse exitosamente.
RNF02	Disponibilidad	Continuidad del Monitoreo Operativo	Como gestor de flota, quiero que el monitoreo de unidades esté disponible de forma continua, para supervisar la operación y responder a incidencias sin interrupciones críticas.	Escenario 1: DADO un periodo mensual de operación 24/7, CUANDO se calcula la disponibilidad del módulo de monitoreo, ENTONCES debe alcanzar al menos 99.5% de uptime mensual. Escenario 2: DADO una caída de un servicio de monitoreo en producción, CUANDO el sistema detecta el fallo por health checks, ENTONCES la recuperación automática debe restablecer el servicio en un RTO menor o igual a 5 minutos. Escenario 3: DADO una falla de nodo en hora pico, CUANDO el balanceador redirige tráfico a réplicas saludables, ENTONCES la pérdida de solicitudes no debe superar el 1% durante el incidente. Escenario 4: DADO una degradación parcial de infraestructura, CUANDO se activa el plan de contingencia, ENTONCES el sistema debe preservar las funciones críticas de monitoreo y alertas en menos de 3 minutos.
RNF03	Performance	Baja Latencia en Telemetría y Alertas	Como operador de monitoreo, quiero recibir coordenadas y alertas en tiempo real con latencia mínima, para tomar decisiones operativas oportunas durante la ruta.	Escenario 1: DADO una carga nominal de 2000 eventos de telemetría por minuto, CUANDO se mide el tiempo entre emisión de coordenada y visualización en mapa, ENTONCES la latencia p95 debe ser menor o igual a 3 segundos. Escenario 2: DADO una alerta de incidente generada por una unidad activa, CUANDO el evento ingresa a la plataforma, ENTONCES la notificación al panel de control debe mostrarse en menos de 2 segundos en el 95% de casos. Escenario 3: DADO un pico de carga de 5000 eventos por minuto durante 10 minutos, CUANDO se monitorea el procesamiento de cola, ENTONCES el sistema debe mantener una latencia p95 menor o igual a 5 segundos sin pérdida de eventos. Escenario 4: DADO una versión candidata a producción, CUANDO se ejecuta una prueba de stress en CI/CD, ENTONCES el throughput mínimo debe sostener 300 requests por segundo con tasa de error menor al 1%.
RNF04	Seguridad	Protección de Datos Sensibles y Accesos	Como administrador de seguridad, quiero proteger los datos sensibles de ubicación y controlar accesos por roles, para prevenir fugas de información y accesos no autorizados.	Escenario 1: DADO usuarios autenticados mediante JWT/OAuth con roles definidos, CUANDO intentan acceder a un recurso fuera de su perfil, ENTONCES el sistema debe denegar el acceso con código 403 en el 100% de solicitudes no autorizadas. Escenario 2: DADO el flujo de transmisión y almacenamiento de coordenadas de ubicación, CUANDO se ejecutan auditorías de seguridad trimestrales, ENTONCES el 100% de datos sensibles debe mantenerse cifrado en tránsito (TLS 1.2+) y en reposo (AES-256). Escenario 3: DADO una sesión autenticada con token JWT, CUANDO el token expira o es inválido, ENTONCES el sistema debe rechazar la solicitud con código 401 en menos de 500 ms. Escenario 4: DADO un intento de fuerza bruta sobre autenticación, CUANDO se superan 5 intentos fallidos en 10 minutos por usuario, ENTONCES la cuenta debe bloquearse temporalmente por 15 minutos y generar una alerta de seguridad.
RNF05	Usabilidad	Operación Simple para Conductores con Modo Offline	Como conductor de flota, quiero usar la app de forma simple incluso sin conectividad, para registrar eventos y continuar mi operación sin bloquear mi jornada.	Escenario 1: DADO un conductor en zona de baja conectividad, CUANDO registra un incidente o actualización de estado, ENTONCES la app debe guardar la acción offline en menos de 1 segundo y confirmar visualmente el registro local. Escenario 2: DADO una cola de eventos almacenados offline, CUANDO se recupera la conectividad, ENTONCES la app debe sincronizar al menos el 95% de eventos pendientes en menos de 60 segundos sin duplicar registros. Escenario 3: DADO un conductor que inicia jornada por primera vez, CUANDO completa el flujo principal de registro y reporte, ENTONCES debe finalizarlo en menos de 3 minutos sin asistencia externa en al menos el 90% de pruebas de usabilidad. Escenario 4: DADO el uso continuo de la app en ruta, CUANDO el conductor ejecuta acciones frecuentes (reportar incidencia, confirmar estado, revisar ruta), ENTONCES cada acción debe completarse en un maximo de 3 toques en el 95% de los casos.

3.3 Impact Map

En esta sección se presentan los mapas de impacto correspondientes a cada uno de los segmentos objetivo definidos en el proyecto. El propósito de estos mapas es establecer una relación clara entre los objetivos del negocio, los usuarios involucrados y los cambios de comportamiento que se espera generar a partir de la solución propuesta. Asimismo, permiten identificar de manera estructurada los entregables necesarios para lograr dichos objetivos, asegurando que el desarrollo del sistema esté alineado con las necesidades reales de los usuarios.

Segmento Objetivo 1: Gestor de Flota

El mapa de impacto del gestor de flota permitió identificar cómo las funcionalidades del sistema contribuyen directamente a mejorar la gestión operativa. A través de este análisis, se definieron comportamientos clave como el monitoreo constante de los vehículos, la anticipación de fallas mediante alertas y la optimización en la asignación de recursos. Esto permitió establecer una conexión clara entre las necesidades del usuario y los entregables del sistema, orientando el desarrollo hacia una solución más eficiente y enfocada en la toma de decisiones en tiempo real.

Segmento Objetivo 2: Conductor de Flota

El mapa de impacto del conductor de flota permitió comprender mejor su rol dentro de la operación y las mejoras que la solución puede aportar en su trabajo diario. Mediante este enfoque, se identificaron comportamientos importantes como el seguimiento claro de rutas, el registro sencillo de su jornada y la comunicación eficiente ante incidencias. Esto facilitó la definición de entregables centrados en la simplicidad de uso y en la continuidad operativa, asegurando una mejor experiencia para el usuario en campo.

3.4. Product Backlog.

En esta sección se presenta el Product Backlog priorizado de Orion, organizado a partir de las User Stories funcionales identificadas para el sistema. Cada elemento incluye su orden de prioridad, identificador, título, descripción y estimación en Story Points.

Orden	User Story ID	Título	Descripción	Story Points
1	US01	Configuración de Tenant	Como administrador del sistema, quiero crear perfiles de empresa únicos, para que cada cliente tenga su propio espacio de trabajo aislado.	5
2	US04	Autenticación JWT	Como gestor, quiero acceder mediante tokens JWT, para asegurar autenticación robusta en el sistema.	3
3	US02	Aislamiento de Datos	Como gestor de flota, quiero que mis datos de conductores y rutas sean invisibles para otras empresas, para garantizar la privacidad comercial.	8
4	US07	Filtro Obligatorio por TenantId	Como arquitecto, quiero que toda consulta a BD incluya TenantId, para asegurar 0% de fuga entre empresas.	8
5	US03	Gestión de Usuarios y Roles	Como gestor de flota, quiero invitar usuarios con roles específicos, para delegar la supervisión de la flota.	5
6	US05	Expiración de Sesión	Como gestor, quiero que la sesión expire automáticamente tras inactividad, para reducir el riesgo de acceso no autorizado.	3
7	US06	Cifrado HTTPS de Telemetría	Como administrador, quiero que toda la telemetría se transmita vía HTTPS, para evitar interceptación de datos.	3
8	US15	Asignación Dinámica	Como gestor de flota, quiero asignar conductores a vehículos y rutas específicas según la demanda del día.	8
9	US16	Disponibilidad de Personal	Como gestor de flota, quiero ver quién está en turno activo, para no sobrepasar las horas permitidas de manejo.	5
10	US18	Recepción de Horarios	Como conductor, quiero ver mi cronograma diario en el móvil, para saber qué unidad debo operar.	3
11	US17	Reporte de Jornada	Como conductor, quiero marcar inicio y fin de jornada desde la app, para que mi tiempo laborado quede registrado.	3
12	US08	Visualización en Mapa	Como gestor de flota, quiero ver la ubicación en tiempo real de mis vehículos, para optimizar la logística.	8
13	US09	Historial de Rutas	Como gestor de flota, quiero consultar el recorrido histórico de una unidad, para verificar el cumplimiento de las rutas.	5
14	US10	Gestión de Geocercas	Como gestor de flota, quiero definir zonas permitidas, para recibir alertas cuando un vehículo salga del perímetro autorizado.	5
15	US11	Alertas por Geocerca	Como gestor de flota, quiero recibir alertas si un vehículo sale del perímetro autorizado, para actuar oportunamente.	5
16	US12	Alertas de Kilometraje	Como gestor de flota, quiero recibir alertas automáticas de cambio de aceite, para evitar daños mecánicos por exceso de uso.	5
17	US13	Registro de Activos	Como gestor de flota, quiero registrar el estado de neumáticos y frenos, para proyectar gastos de renovación anual.	5
18	US14	Control de Revisiones Técnicas	Como gestor de flota, quiero programar revisiones legales, para evitar multas por documentos vencidos.	3
19	US19	Reporte de Incidentes	Como conductor, quiero enviar fotos de fallas mecánicas desde la app, para que el gestor programe el taller de inmediato.	5
20	US20	Botón de Pánico	Como conductor, quiero activar una alerta de emergencia, para que la central reciba mi ubicación exacta al instante.	8
21	US21	Persistencia Local Offline	Como conductor, quiero que la app móvil guarde eventos offline en SQLite, para garantizar la experiencia en zonas sin señal.	8
22	US22	Sincronización Inteligente	Como conductor, quiero que la app sincronice automáticamente los datos pendientes al recuperar señal, para no perder información registrada en modo offline.	8

Link del Trello:https://trello.com/invite/b/69f432bbe4fbd84d7926aa2c/ATTI61d4b7dffe97b1c335c47c6925e0e96d7AC04AE7/goslogic

Capítulo IV: Product Architecture Design

4.1 Desing Concepts, ViewPoints & ER Diagrams

Esta sección define las estructuras, elementos y relaciones fundamentales de la arquitectura de Orion . Aplicando el método ADD v3, presentaremos nuestras decisiones de diseño a través de múltiples vistas (principios, patrones y diagramas), ya que un sistema complejo no puede representarse en una única perspectiva

4.1.1 Principles Statements

Aislamiento Lógico por Defecto (Seguridad Multi-Tenant)
- Descripción: Queda estrictamente prohibida la dependencia en el filtrado manual a nivel de código para la separación de datos. Toda operación de lectura/escritura debe inyectar implícitamente el TenantId desde el API Gateway hasta la capa de persistencia, apoyándose en políticas de base de datos como Row-Level Security (RLS).
- Justificación de Negocio: Orion opera bajo un modelo SaaS donde conviven datos de empresas de transporte competidoras. Mitigar el riesgo de exposición transversal de la información es innegociable para mantener la confianza comercial y proteger el secreto industrial de los clientes.
Identidad Centralizada y Desacoplada (Atributo: Seguridad/Mantenibilidad)

Descripción: La autenticación y autorización se delegan exclusivamente a un servicio de IAM (Identity and Access Management) independiente. Los microservicios de negocio (Bounded Contexts) solo consumen tokens validados por el API Gateway.
Justificación de Negocio: Permite que el sistema crezca sin replicar lógica de seguridad en cada microservicio y facilita la auditoría de accesos.

Aislamiento de Proveedores Externos (Interoperabilidad)
- Descripción: Las integraciones con servicios de terceros (específicamente proveedores cartográficos y APIs de Google Maps) deberán canalizarse obligatoriamente a través de un patrón de Capa Anticorrupción (Anti-Corruption Layer). Ningún microservicio core debe depender de los contratos de datos externos.
- Justificación de Negocio: Protege a Orion frente a la evolución técnica o cambios en la estructura de precios de terceros. Encapsular la integración asegura que una futura migración a otro proveedor (ej. OpenStreetMap) no requiera reescribir la lógica central de despacho y ruteo.
Diseño para el Fallo y Degradación Elegante (Resiliencia)
- Descripción: El sistema debe impedir activamente la propagación de fallas en cascada (Cascading Failures). Es imperativa la implementación de la táctica de Circuit Breaker en las llamadas a servicios externos. Si el mapa falla, el sistema cortará la petición y operará en modo degradado (retornando la última ubicación en caché).
- Justificación de Negocio: La gestión de flotas exige continuidad operativa crítica. Cualquier caída de un servicio externo debe mitigarse internamente para que la vista del gestor de flota nunca colapse y la asignación de unidades no se detenga.
Llamadas Asincrónicas sobre Sincrónicas para Alta Carga (Performance)
- Descripción: Queda restringido el uso de llamadas sincrónicas (bloqueantes) para la ingesta de telemetría vehicular. Toda recepción masiva de coordenadas GPS adoptará un patrón Event-Driven mediante un Message Broker (como Kafka o RabbitMQ), encolando los eventos para su procesamiento diferido.
- Justificación de Negocio: Durante las horas punta, Orion recibirá cientos de coordenadas GPS simultáneas. Desacoplar la recepción del procesamiento absorbe los picos de carga, garantizando que los tableros de control de los gestores mantengan una latencia mínima sin saturar la base de datos transaccional.
Persistencia Local como Estándar Móvil u "Offline-First" (Operatividad)
- Descripción: La aplicación móvil guardará todo evento logístico primariamente en un almacenamiento local ligero (ej. SQLite). La transmisión a la nube se delegará a procesos en segundo plano condicionados a la red, aplicando obligatoriamente tácticas de Retry con Backoff Exponencial.
- Justificación de Negocio: Las rutas de transporte frecuentemente atraviesan zonas de nula conectividad. Este principio garantiza el 100% de la trazabilidad de la jornada del conductor y salvaguarda la vida útil de la batería del dispositivo al evitar intentos de conexión fallidos continuos.

4.1.2 Approaches Statements Architectural Styles & Patterns

4.1.2.1 Approaches Statements

Para Orion, la aplicación de Domain-Driven Design (DDD) constituye el marco estratégico fundamental para gestionar la complejidad de una plataforma SaaS multi-tenant orientada al sector logístico.

Modelado Basado en el Dominio: Priorizamos el desarrollo del Core Domain, compuesto por los contextos de Dispatch & Routing, Telemetry & Tracking y Maintenance. Estos representan la ventaja competitiva y la lógica crítica de Orion. Los aspectos comunes y transversales se delegan al subdominio genérico de Identity & Tenancy, permitiendo que la lógica de negocio logística evolucione de forma independiente a la infraestructura de seguridad y gestión de organizaciones.
Límites de Contexto Estrictos (Bounded Contexts): Se establecen fronteras explícitas para evitar la contaminación de modelos y asegurar la cohesión. Orion se descompone en seis contextos especializados:
- Identity & Tenancy: Responsable único de la jerarquía de organizaciones y la emisión de claims de seguridad mediante tokens JWT.
- Fleet Management: Gestiona el inventario de activos físicos y perfiles de conductores, aplicando políticas de Row-Level Security (RLS) para el aislamiento de datos.
- Dispatch & Routing: Modela la planificación y ejecución de viajes, protegido de la volatilidad de APIs externas mediante una Anti-Corruption Layer (ACL).
- Telemetry & Tracking: Contexto optimizado para la ingesta de eventos de alta frecuencia, utilizando un enfoque asíncrono para garantizar la escalabilidad.
- Maintenance: Orquesta la salud de la flota y la programación de servicios técnicos a través del consumo de eventos de kilometraje provenientes de telemetría.
- Alerts & Notifications: Servicio transversal encargado del despacho de mensajes críticos y operativos hacia los usuarios finales.
Estrategia de Comunicación y Resiliencia: Adoptamos un enfoque híbrido: comunicaciones sincrónicas vía REST APIs para procesos transaccionales y administrativos, y comunicaciones asíncronas basadas en eventos para la telemetría y el motor de alertas. Se implementan tácticas de Circuit Breaker en los puntos de integración con servicios de terceros para asegurar que una falla externa no provoque una degradación sistémica de la plataforma.
Lenguaje Ubicuo (Ubiquitous Language): Se garantiza que términos críticos como Tenant, Despacho, Geocerca, Viaje y Alerta mantengan una definición única y consistente desde los requerimientos funcionales hasta la implementación técnica en el código fuente y los contratos de las APIs. Esto elimina la fricción semántica entre los stakeholders del negocio y el equipo de desarrollo.

4.1.2.2 Architectural Styles & Patterns

A. Estilos Arquitectónicos

Microservices Architecture: Se adopta este estilo para permitir el despliegue y escalado independiente de los seis bounded contexts. Esto asegura que la alta carga del servicio de Telemetría no afecte la disponibilidad del módulo de Mantenimiento o Fleet Management.
Event-Driven Architecture: Utilizado para el procesamiento asíncrono de coordenadas GPS y generación de alertas. Este estilo permite desacoplar los servicios productores (Telemetry) de los consumidores (Alerts, Maintenance), absorbiendo picos de tráfico sin degradar la experiencia del usuario.
RESTful API: Estilo de comunicación predominante para las interacciones sincrónicas entre el frontend (Web/Mobile) y el API Gateway.

B. Patrones Arquitectónicos y Tácticas de Diseño

API Gateway Pattern: Actúa como el punto de entrada único para todos los clientes. Implementa la lógica de enrutamiento hacia los microservicios y actúa como el primer nivel de seguridad al validar tokens JWT en conjunto con el IAM.
Identity and Access Management (IAM): Patrón centralizado para la gestión de identidades que garantiza que el TenantId sea inyectado en cada petición. Esto asegura que la autenticación sea agnóstica a la lógica de negocio de los microservicios.
Row-Level Security (RLS): Táctica de persistencia aplicada en el motor de base de datos SQL para garantizar el aislamiento multi-tenant. Filtra automáticamente los registros basándose en el contexto de sesión, mitigando el riesgo de exposición de datos entre empresas competidoras.
Anti-Corruption Layer (ACL): Aplicado en el contexto de Dispatch & Routing para interactuar con proveedores externos de mapas. Traduce los contratos de terceros a un modelo interno estable, protegiendo el Core Domain de cambios externos.
Circuit Breaker: Implementado en las integraciones con servicios externos. Previene fallos en cascada al "abrir el circuito" ante errores recurrentes, permitiendo que Orion opere en modo degradado o utilice datos en caché.

4.1.3 Context Diagram

El Context Diagram ilustra las principales entidades externas, sistemas y usuarios que interactúan con la plataforma Orion, así como sus canales de integración y límites de contexto clave. Este diagrama ayuda a comprender el alcance del sistema y su relación con el entorno organizacional y tecnológico.

El diagrama de contenedores (C4 nivel 2) y los diagramas de componentes por servicio (C4 nivel 3), junto con diagramas de actividad y de estado, se agrupan en la sección 4.1.4.

4.1.4 Approach driven ViewPoints Diagrams

Esta sección agrupa las vistas estáticas del modelo C4 (contexto, contenedores y componentes por servicio) junto con diagramas UML complementarios de actividad y de estado que detallan la dinámica operativa de Orion.

Diagramas complementarios de la arquitectura

1. Context Diagram (C4 nivel 1)

Context Diagram: sistema Orion y sus actores e integraciones externas.

2. Diagrama de Contenedores (C4 nivel 2)

Diagrama de Contenedores de la plataforma Orion.

3. Diagramas de componentes (C4 nivel 3)

Desglose interno de los principales contenedores backend en componentes lógicos (interfaces, aplicación, dominio, infraestructura e integraciones). Cada figura corresponde a un microservicio del perímetro Orion.

IAMService (Identity & Access Management)

Diagrama de componentes — IAMService.

TelemetryService

Diagrama de componentes — TelemetryService.

FleetService

Diagrama de componentes — FleetService.

DispatchService

Diagrama de componentes — DispatchService.

MaintenanceService

Diagrama de componentes — MaintenanceService.

NotificationService

Diagrama de componentes — NotificationService.

4. Diagramas de Actividades

Gestión de incidente y mantenimiento correctivo
Procesamiento de telemetría
Creación y asignación de hoja de ruta

5. Diagramas de Estado

Ciclo de vida del vehículo
Parada en hoja de ruta

4.1.5 Relational/Non Relational Database Diagram

I. Argumentación de la decisión tecnológica

Para nuestra plataforma, se ha decidido implementar una arquitectura de persistencia políglota basada en PostgreSQL y su extensión TimescaleDB, descartando soluciones puramente NoSQL debido a la complejidad de las relaciones y la necesidad de integridad transaccional.

Esta decisión se basa en los siguientes aspectos:

Integridad Multi-Tenant: El sistema exige vínculos estrictos e inquebrantables entre la empresa (Tenant), sus activos y los datos de despacho. El modelo relacional garantiza esta integridad referencial mediante llaves foráneas (FK), asegurando que los datos de un cliente nunca se filtren a otro.
Tratamiento de Series Temporales: A diferencia de una base de datos relacional estándar, el uso de TimescaleDB permite manejar la telemetría masiva mediante hypertables. Esto ofrece el rendimiento de una base de datos NoSQL para escrituras, manteniendo la potencia de las consultas SQL para el historial de rutas.
Cómputo Geoespacial Eficiente: La gestión de geocercas y el monitoreo de arribos se resuelven de forma nativa mediante PostGIS. Esto permite calcular si un camión entró en su zona de entrega directamente en la base de datos, optimizando el rendimiento antes de procesar alertas en el backend.
Agregación Analítica para Logística: La generación de reportes (kilómetros recorridos por flota, cumplimiento de mantenimiento y eficiencia de conductores) se beneficia de las capacidades de agregación complejas que ofrece el lenguaje SQL, cruciales para la toma de decisiones del Gestor de Flota.

II. Diagramas de Base de Datos

IAM database diagram

Fleet database diagram

Dispatch database diagram

Maintenance database diagram

Telemetry database diagram

4.1.6 Design Patterns

Para la construcción de Orion, se ha decidido implementar un conjunto de patrones de diseño de software basados en los lineamientos de GoF y arquitecturas empresariales que garantizan el desacoplamiento, la mantenibilidad y el aislamiento de dominios en un entorno Multi-Tenant. Los patrones seleccionados para el contexto específico de este proyecto son los siguientes:

1. Repository Pattern - Patrón Repositorio

Propósito: Actuar como un intermediario entre la capa de dominio y la capa de persistencia de datos, ocultando los detalles técnicos del acceso a las distintas bases de datos.
Aplicación en el proyecto: Es crítico para gestionar la persistencia políglota del sistema. Se utiliza para encapsular consultas complejas en PostgreSQL y, especialmente, para manejar las funciones de agregación de tiempo en TimescaleDB dentro del microservicio de Telemetría. Esto permite que la lógica de negocio permanezca intacta si se decide cambiar el ORM o la estructura de las tablas en el futuro.

2. Adapt Pattern - Patrón adaptador

Propósito: Convertir la interfaz de una clase en otra interfaz que el cliente espera, permitiendo que clases con interfaces incompatibles trabajen juntas.
Aplicación en el proyecto: Se implementa para la integración con servicios externos como la API de Google Maps. Esto garantiza que si el proveedor externo cambia su contrato o si se decide migrar a otra plataforma como Mapbox, solo se deba modificar el adaptador, manteniendo el núcleo del backend intacto.

3. Observer Pattern (Patrón Observador)

Propósito: Definir una dependencia de uno-a-muchos entre objetos, de forma que cuando el objeto principal cambie su estado, todos sus dependientes sean notificados automáticamente.
Aplicación en el proyecto: Es el motor de la arquitectura Event-Driven de Orion. Cuando el TelemetryService procesa una coordenada y detecta un evento, actúa como el sujeto que publica un mensaje en el Message Broker. Los microservicios de Notification y Dispatch actúan como observadores que reaccionan de forma desacoplada para actualizar el estado de la entrega o enviar alertas al gestor en tiempo real.

4. Strategy Pattern (Patrón Estrategia)

Propósito: Definir una familia de algoritmos, encapsular cada uno y hacerlos intercambiables en tiempo de ejecución, permitiendo que el algoritmo varíe independientemente de los clientes que lo utilizan.
Aplicación en el proyecto: Se utiliza para el cálculo del Próximo Servicio de Mantenimiento. Dependiendo del tipo de vehículo o de las políticas específicas de cada Tenant, el sistema inyecta una estrategia de cálculo diferente (basada en kilometraje acumulado, tiempo transcurrido o reglas personalizadas), permitiendo que el microservicio de mantenimiento sea altamente flexible ante nuevos requerimientos de negocio

5. Dependency Injection (Inyección de Dependencias)

Propósito: Externalizar la creación y gestión de las dependencias de una clase, pasándolas dinámicamente en tiempo de ejecución en lugar de instanciarlas manualmente.
Aplicación en el proyecto: Es el eje central de los frameworks utilizados en el Backend. El contenedor de Inversión de Control (IoC) inyecta automáticamente los repositorios y adaptadores necesarios según el contexto. Esto es fundamental para cumplir con el atributo de calidad de testeabilidad, ya que permite inyectar Mocks o simulaciones durante las pruebas unitarias de la lógica de ruteo y telemetría sin depender de bases de datos o APIs externas activas.

4.1.7 Tactics

Según la taxonomía del SEI, una táctica arquitectónica es una decisión de diseño atómica destinada a controlar la respuesta del sistema ante estímulos que afectan sus atributos de calidad. Mientras que los patrones resuelven problemas de composición global, las tácticas son mecanismos específicos que, en conjunto, forman la estrategia para satisfacer los architectural drivers de Orion. La siguiente tabla detalla las tácticas seleccionadas, vinculándolas directamente con los componentes definidos en el modelo C4.

Atributo de Calidad	Táctica Seleccionada	Componente Asociado (Artefacto)	Justificación / Aplicación
Disponibilidad	Redundancia Activa (Active Redundancy)	Load Balancer y réplicas de microservicios (contenedores backend Orion)	Se despliegan múltiples instancias homogéneas de los microservicios detrás de un balanceador de carga, de modo que la indisponibilidad de una réplica no constituye un punto único de fallo (SPOF). Esta táctica materializa tolerancia a fallos mediante redundancia activa y distribución de peticiones, alineada con la continuidad operativa exigida por el modelo SaaS.
Disponibilidad	Excepciones / Degradación Controlada	Contenedor TelemetryMapsService	Se aplica el patrón Circuit Breaker sobre las invocaciones a la API de Google Maps: ante latencia extrema o errores sostenidos, el circuito abre y el sistema evita propagar la falla en cascada, operando en modo degradado (p. ej., sirviendo últimas respuestas válidas desde caché) para preservar la disponibilidad percibida del monitoreo cartográfico.
Performance	Introducir Concurrencia (Introduce Concurrency)	Contenedor Message Broker (Apache Kafka / RabbitMQ)	La ingesta masiva de telemetría GPS se desacopla del procesamiento síncrono: los productores publican eventos en el broker y los consumidores los procesan concurrentemente. Ello absorbe picos de carga y evita que el camino crítico bloquee la aplicación móvil o los servicios de consulta bajo alta concurrencia.
Performance	Múltiples Copias de Datos (Caching)	Almacén en memoria Redis (caché)	Se replica temporalmente el resultado de operaciones costosas y repetidas —notablemente respuestas de geocodificación y datos cartográficos derivados— para reducir la latencia end-to-end y la presión sobre APIs externas y bases de datos, mejorando el tiempo de respuesta bajo consultas frecuentes desde los paneles de gestión.
Interoperabilidad	Uso de un Intermediario (Use an Intermediary)	Contenedor API Gateway	El gateway actúa como fachada única de entrada: centraliza enrutamiento, políticas transversales (autenticación, límites de tasa, versionado) y uniformidad de contratos hacia los microservicios internos, facilitando que clientes heterogéneos y sistemas externos interactúen con Orion sin conocer la topología fina del backend.
Interoperabilidad	Manejo de Interfaces / Capa Anticorrupción	Interfaces públicas REST/JSON (expuestas vía API Gateway y servicios de integración)	Los sistemas corporativos de terceros (p. ej., ERPs) consumen recursos en formato JSON estándar sobre HTTP, mientras una capa anticorrupción aísla el modelo canónico interno de Orion de representaciones propietarias o evolutivas. Así se minimiza el acoplamiento semántico y se estabiliza el contrato de intercambio de datos de kilometraje y activos frente a cambios en el dominio interno.
Usabilidad	Iniciativa del Sistema (System Initiative)	Contenedor MobileApp (cliente)	La aplicación adopta un modelo offline-first con persistencia local en SQLite: ante pérdida de conectividad, el sistema conserva autónomamente los eventos de jornada y reintenta la sincronización en segundo plano mediante retry con backoff exponencial al restablecerse la red, reduciendo la carga cognitiva del conductor y manteniendo continuidad operativa sin intervención manual.

La conjugación coherente de las tácticas anteriores define la estrategia arquitectónica Cloud-Native de Orion: la redundancia y la degradación controlada aseguran un servicio continuo; la concurrencia mediada por broker, la persistencia especializada en series temporales y la caché distribuida sostienen el rendimiento bajo picos de telemetría; la intermediación a través del Gateway garantiza el aislamiento lógico de datos por Tenant y habilita integraciones empresariales predecibles; finalmente, la iniciativa del sistema en el cliente móvil cierra la brecha de usabilidad en entornos de conectividad débil. En conjunto, estas decisiones constituyen el cimiento técnico que hace viable el despliegue multi-tenant escalable y seguro del producto en modalidad SaaS.

4.2 Architectural Drivers

Los Architectural Drivers son aquellos requisitos funcionales o de calidad cuyo impacto es tan elevado que condicionan de forma directa la estructura, las tecnologías y los riesgos aceptables del sistema. En el marco de ADD v3, identificarlos y priorizarlos permite centrar el diseño de Orion en las decisiones que realmente importan para una plataforma SaaS de telemetría vehicular. En esta sección se sintetiza ese conjunto motriz que alinea negocio, operación del servicio y atributos de calidad priorizados.

4.1.8 Design Purpose

Orion es un proyecto desarrollado desde cero (greenfield) dentro de un dominio logístico maduro. Al no existir un sistema legado que condicione nuestra topología, el diseño arquitectónico inicial es crucial para definir la estructura general de la plataforma. Siguiendo la metodología Attribute-Driven Design (ADD v3) del Software Engineering Institute (SEI), el propósito de este diseño no es solo documentar, sino generar un artefacto lo suficientemente detallado que guíe al equipo de desarrollo durante la fase de construcción. De esta forma, establecemos la topología base (componentes, flujos de comunicación y responsabilidades) que conectará nuestras necesidades de negocio SaaS con las soluciones técnicas Cloud-Native.

De acuerdo con los lineamientos de este documento, el objetivo de esta sección es explicar el propósito del proceso de diseño de la aplicación para permitir la implementación coherente con las entidades arquitectónicas definidas en los modelos y vistas de la arquitectura del sistema. En la práctica, esto significa que todas las decisiones que tomemos durante las iteraciones del ADD deben mantener una trazabilidad directa con las vistas del modelo C4 (especialmente el diagrama de contenedores). El diseño actuará como nuestra regla de coherencia: evitará que, durante la etapa de programación, el equipo tome decisiones aisladas, cree acoplamientos innecesarios o implemente bases de datos que rompan el estilo arquitectónico acordado.

Finalmente, esta arquitectura funciona como una herramienta de comunicación y gestión de riesgos para todo el equipo técnico. Nos permite enfrentar los principales retos de Orion de manera estructurada y no como tareas improvisadas. Estos retos incluyen:

garantizar el aislamiento de datos (multi-tenant);
construir nuestro propio módulo de seguridad (AuthService in-house);
asegurar el funcionamiento de la app móvil en zonas sin cobertura (offline-first); y
soportar la ingesta asíncrona de telemetría masiva.

Por lo tanto, el propósito de este diseño es trazar la hoja de ruta para construir los microservicios principales como Fleet y Dispatch, garantizando que el sistema final cumpla estrictamente con los atributos de calidad priorizados.

4.1.9 Primary Functionality (Primary User Stories)

En la metodología ADD v3, la funcionalidad primaria no lista todo lo que hará el sistema, sino que aísla únicamente las capacidades que definen su arquitectura base. Por ello, de acuerdo con la rúbrica de evaluación, en esta sección se identifican los requisitos que afectan la estructura de la aplicación; es decir, aquellas decisiones que nos obligaron a definir contenedores, componentes y bases de datos.

Se han seleccionado cuatro historias de usuario clave que dictan la topología de Orion. Para garantizar la coherencia del diseño, todas mantienen una trazabilidad directa con el Product Backlog del Capítulo III (sección 3.2.2) y sus detalles operativos se sustentan en los Requisitos No Funcionales (RNF01 a RNF05) previamente documentados.

ID original	Funcionalidad primaria	Descripción representativa (User Story)	Impacto arquitectónico y driver
US-09	Ingesta masiva y consulta de telemetría	Como gestor de flota, quiero consultar el recorrido histórico de una unidad para verificar el cumplimiento de las rutas asignadas.	Impacta el Performance: la consulta histórica sobre un volumen creciente de posiciones nos exige desacoplar la escritura de la telemetría del hilo principal. Esto justifica una arquitectura orientada a eventos con un MessageBroker y la persistencia en una base de datos de series de tiempo (TimescaleDB), alineado a las métricas del RNF03.
US-08	Monitoreo cartográfico y despacho	Como gestor de flota, quiero visualizar la ubicación de mis vehículos en tiempo real sobre Google Maps para optimizar la logística.	Impacta la Disponibilidad: la capa cartográfica introduce un punto de fragilidad crítico por la dependencia de una API externa. Esto nos obliga a implementar la táctica de Circuit Breaker en el TelemetryMapsService para limitar la propagación de fallos y preservar el servicio perimetral (RNF01 y RNF02).
US-21	Sincronización de operatividad en campo	Como conductor, quiero que la app móvil guarde eventos offline en SQLite para garantizar la experiencia en zonas sin señal.	Impacta la Usabilidad: afecta directamente la continuidad operativa en campo (RNF05). Nos obliga a modelar el contenedor MobileApp con un enfoque offline-first (SQLite) y diseñar una resincronización automática con la táctica de Retry con Backoff Exponencial.
US-04	Aislamiento multi-tenant y control de acceso	Como gestor, quiero acceder mediante tokens JWT para asegurar una autenticación robusta y aislada.	Impacta la Seguridad e Interoperabilidad: la validación segura de usuarios motiva la construcción de un AuthService in-house y un ApiGateway como fachada. Además, el aislamiento lógico entre empresas se asegura aplicando políticas de Row-Level Security en la base de datos según el TenantId (RNF04).

Conclusión: En conjunto, estas cuatro funcionalidades primarias conforman el núcleo operativo de Orion y justifican la elección de un estilo arquitectónico basado en Microservicios Cloud-Native. Las necesidades estrictas de desempeño asíncrono, resiliencia ante proveedores externos, integración limpia con terceros, aislamiento multi-tenant y soporte operativo sin conexión hacen inviable la elección de una arquitectura monolítica tradicional.

4.1.10 Quality Attribute Scenarios

En ADD v3, un escenario de atributo de calidad fija estímulo, medioambiente, artefacto afectado, respuesta esperada y medida verificable, lo que permite evaluar el diseño sin ambigüedad. A continuación, cinco escenarios para Orion; cada uno aísla un solo atributo, distingue la fuente (siempre externa al sistema) del artefacto (componente interno) y se presenta en una tabla de seis filas: fuente, estímulo, medioambiente, artefacto, respuesta y medida de respuesta.

Escenario 1 — Performance (latencia en telemetría)

Fuente de estímulo	Dispositivos GPS del conductor (terminales en borde de red).
Estímulo	Envío continuo de coordenadas de posición hacia la plataforma.
Medioambiente	Carga nominal equivalente a 2000 eventos de telemetría por minuto.
Artefacto	Contenedores MessageBroker y TelemetryMapsService.
Respuesta	El sistema ingiere y procesa las coordenadas por vías asíncronas, sin bloquear los hilos principales de los servicios de consulta ni de la interfaz de monitoreo.
Medida de respuesta	Latencia percentil 95 entre la emisión del evento y su visualización en el mapa menor o igual a 3 segundos.

Escenario 2 — Disponibilidad (circuito de apertura ante fallo del proveedor cartográfico)

Fuente de estímulo	API de Google Maps (servicio de terceros fuera del perímetro de despliegue de Orion).
Estímulo	El proveedor devuelve cinco errores consecutivos en un intervalo de 60 segundos.
Medioambiente	Operación normal de monitoreo cartográfico de la flota.
Artefacto	Contenedor TelemetryMapsService.
Respuesta	Activación del modo degradado mediante la táctica de circuit breaker y atención de solicitudes de mapa desde caché local.
Medida de respuesta	El modo de contingencia queda activo en menos de 2 segundos desde el cumplimiento de la condición de error.

Escenario 3 — Usabilidad (sincronización tras operación offline)

Fuente de estímulo	Dispositivo móvil del conductor.
Estímulo	Recuperación de la conectividad de red tras un periodo de operación sin enlace de datos.
Medioambiente	Zona con señal restablecida y cola de eventos pendientes de sincronización almacenada localmente.
Artefacto	Contenedor MobileApp con motor de persistencia local SQLite.
Respuesta	Inicio automático de la resincronización en segundo plano mediante reintentos con backoff exponencial.
Medida de respuesta	Sincronización exitosa de al menos el 95 % de los eventos pendientes en menos de 60 segundos, sin duplicados en el registro remoto.

Escenario 4 — Usabilidad (facilidad de aprendizaje en primer uso)

Fuente de estímulo	Conductor de flota sin experiencia previa en la aplicación.
Estímulo	Primer intento de iniciar la jornada laboral desde la aplicación móvil.
Medioambiente	Operación en campo bajo condiciones habituales de iluminación y conectividad.
Artefacto	Interfaz de usuario del contenedor MobileApp.
Respuesta	La aplicación guía al conductor mediante un flujo paso a paso hasta completar el registro inicial de jornada.
Medida de respuesta	Finalización del reporte inicial en menos de 3 minutos sin asistencia de un instructor ni de soporte remoto.

Escenario 5 — Seguridad (aislamiento multi-tenant)

Fuente de estímulo	Usuario autenticado perteneciente al inquilino «Empresa A» (gestor de flota).
Estímulo	Solicitud de acceso deliberada a un recurso de datos atribuido al inquilino «Empresa B».
Medioambiente	Operación rutinaria bajo modelo de despliegue SaaS multi-organización.
Artefacto	Contenedores ApiGateway y TenantService, en coordinación con políticas de Row-Level Security en el motor de base de datos.
Respuesta	Validación de políticas de aislamiento por identificador de inquilino y denegación de la solicitud antes de materializar datos ajenos.
Medida de respuesta	Código de estado HTTP 403 en el 100 % de los intentos indebidos y registro del evento en el log de auditoría del sistema.

4.1.11 Constraints

En el diseño de la arquitectura de software, las restricciones (constraints) son decisiones o condiciones impuestas por el entorno, el cliente o el modelo de negocio que poseen cero grados de libertad. Es decir, no son objeto de negociación y el arquitecto debe adaptar la solución técnica para cumplirlas de manera estricta.

Para el proyecto Orion se han identificado las siguientes restricciones críticas y su impacto directo sobre los atributos de calidad prioritarios:

ID	Restricción impuesta	Descripción e impacto arquitectónico
CON-01	Uso de software de terceros (Google Maps)	Dependencia innegociable de una API externa para la visualización cartográfica y geocodificación. Impacto en Disponibilidad e Interoperabilidad: Obliga a construir una capa anticorrupción / de abstracción para estandarizar la comunicación y aplicar tácticas de Circuit Breaker para que el sistema siga operando si el proveedor falla.
CON-02	Topología de red intermitente	Los conductores operan en zonas rurales y carreteras sin cobertura móvil garantizada de forma continua. Impacto en Usabilidad: Impone como restricción innegociable que la aplicación móvil soporte operación offline-first con persistencia local (SQLite) para asegurar que el usuario siempre pueda registrar sus eventos sin bloqueos.
CON-03	Entorno de despliegue Cloud-Native	Por definición académica y comercial del proyecto, la solución debe existir íntegramente en la nube mediante microservicios. Impacto en Performance y Disponibilidad: Obliga a utilizar balanceadores de carga y un esquema elástico que soporte escalamiento dinámico ante altas cargas de tráfico logístico.
CON-04	Aislamiento multi-tenant (privacidad de datos)	Por mandato estricto del modelo de negocio SaaS, es obligatorio particionar lógicamente los datos de clientes competidores. Impacto en Performance y Seguridad: Exige implementar políticas de Row-Level Security según el TenantId en la base de datos transaccional, lo cual requerirá estrategias de indexación avanzadas para que las validaciones cruzadas no degraden el desempeño general.
CON-05	Uso de tecnologías Open Source (presupuesto)	Por restricciones de presupuesto y viabilidad del modelo SaaS comercial, se prohíbe el uso de bases de datos o gestores propietarios costosos. Impacto en el diseño: Restringe la elección de tecnología a un stack Open Source, forzando el uso de PostgreSQL, Redis y Apache ActiveMQ para toda la persistencia relacional principal, la caché y la mensajería orientada a eventos.
CON-06	Estándares de integración (interoperabilidad)	Por mandato de interoperabilidad con sistemas externos de terceros (ERP de las empresas), la comunicación debe darse mediante protocolos específicos. Impacto en Interoperabilidad: Obliga a que los microservicios expongan sus contratos estrictamente a través de APIs RESTful en formato JSON y especificación OpenAPI.

4.1.12 Architectural Concerns

Para el SEI, una architectural concern (preocupación arquitectónica) es un tema que condiciona de forma directa la forma del sistema: enlaza requisitos, contexto y restricciones con decisiones de diseño (vistas, estilos, contenedores). En Orion, las vistas, las tácticas y la asignación de responsabilidades a contenedores son la respuesta explícita a cada preocupación que identificamos.

Un riesgo es la posibilidad de que una preocupación se materialice y perjudique objetivos o requisitos (por ejemplo, confianza del cliente, disponibilidad o coste operativo) si no hay contramedida. El diseño no elimina el riesgo: lo deja documentado y asocia mitigaciones que el equipo puede revisar y verificar.

ID	Preocupación arquitectónica	Riesgo	Mitigación arquitectónica
CRN-01	Aislamiento y fuga de datos corporativos (Seguridad)	Al operar como sistema multi-tenant, un error en consultas o en la propagación del contexto de inquilino podría exponer la flota de una empresa frente a un competidor, destruyendo la confianza en el modelo SaaS.	Hemos establecido el TenantId como eje transversal, con políticas de Row-Level Security en PostgreSQL y validación estricta mediante el contenedor AuthService in-house y el ApiGateway.
CRN-02	Dependencia crítica y costos de proveedores externos (Disponibilidad)	La dependencia intensiva de Google Maps para ruteo y cartografía puede generar costos insostenibles por sobreconsumo de cuotas de API y, si el proveedor falla, provocar caídas en cascada en el monitoreo.	Hemos introducido una capa de caché con Redis para optimizar consultas de geocodificación inversa y aplicado la táctica de Circuit Breaker en el contenedor TelemetryMapsService.
CRN-03	Sobrecarga por ingesta masiva concurrente (Performance)	Recibir coordenadas GPS cada cinco segundos desde miles de vehículos en paralelo puede bloquear los hilos principales de la base de datos y colapsar el monitoreo en tiempo real.	Hemos desacoplado la ingesta mediante un MessageBroker (Apache ActiveMQ) bajo una arquitectura orientada a eventos, delegando la persistencia histórica en una base de datos de series de tiempo (TimescaleDB).
CRN-04	Continuidad operativa en zonas sin cobertura (Usabilidad / operatividad)	Los conductores transitan con frecuencia por áreas rurales sin red de datos, lo que ocasionaría pérdida de eventos de telemetría y de reportes de entrega.	Hemos diseñado el contenedor MobileApp en modelo offline-first con persistencia local en SQLite y resincronización automática mediante la táctica de Retry con Backoff Exponencial.

4.3 ADD Iterations

Esta sección documenta las iteraciones del método Attribute-Driven Design (ADD v3) aplicadas al proyecto Orion: en cada ciclo se seleccionan drivers, se eligen conceptos de diseño y se refinan elementos arquitectónicos hasta satisfacer el objetivo acotado de la iteración. Lo que sigue expone de manera secuencial esas decisiones y su justificación, preservando la trazabilidad entre requisitos y estructura del sistema.

4.3.1 Iteration 1: Establishing Initial System Structure

En la primera iteración del Attribute-Driven Design (ADD v3), el objetivo declarado por el SEI es Establishing Initial System Structure: fijar la estructura inicial del sistema. Nos centramos, por tanto, en delinear la topología base Cloud-Native de Orion, el patrón de despliegue (microservicios, contenedores y puntos de entrada) y la arquitectura de referencia mínima capaz de sostener el modelo multi-tenant y la ingesta de telemetría sin comprometer de antemano iteraciones posteriores de refinamiento.

4.3.1.1 Architectural Design Backlog 1

El Architectural Design Backlog de esta iteración no es un backlog de Scrum de historias de usuario: es el conjunto acotado de drivers arquitectónicos (funcionalidad primaria, escenarios de atributos de calidad, restricciones y preocupaciones) que hemos elegido resolver solo en esta vuelta de ADD. La tabla siguiente enumera esos drivers con su tipo y una descripción operativa.

Driver ID	Tipo de driver	Descripción del driver
CRN-General	Concern (architectural concern)	Establecer la estructura inicial general del sistema (base greenfield / delimitación del alcance estructural de la primera iteración).
US-04	Primary functionality	Aislamiento multi-tenant y control de acceso mediante tokens JWT.
US-09	Primary functionality	Ingesta masiva y consulta histórica de telemetría de vehículos.
QA-01 (Escenario 1)	Quality attribute	Performance: soportar la carga nominal de 2000 eventos/min sin bloquear hilos críticos y con latencia p95 entre emisión y visualización ≤ 3 s.
QA-05 (Escenario 5)	Quality attribute	Seguridad: aislamiento estricto multi-tenant; denegación del 100 % de accesos cruzados indebidos (HTTP 403) con trazabilidad en auditoría.
CON-03	Constraint	Entorno de despliegue Cloud-Native basado íntegramente en microservicios.
CON-05	Constraint	Uso exclusivo de tecnologías Open Source (PostgreSQL, Redis, Apache ActiveMQ) para persistencia principal, caché y mensajería orientada a eventos.
CRN-01	Concern (architectural concern)	Riesgo de fuga de datos corporativos entre inquilinos (seguridad multi-tenant).
CRN-03	Concern (architectural concern)	Riesgo de sobrecarga por ingesta masiva concurrente de telemetría (performance).

4.3.1.2 Establish Iteration Goal by Selecting Drivers

Objetivo de la iteración. Nuestro objetivo principal en esta iteración es abordar la preocupación arquitectónica general (CRN-General) de establecer la estructura inicial del sistema (establishing an overall initial system structure). Esto implica definir la arquitectura de referencia, el patrón de despliegue principal en la nube y las tecnologías base de Orion antes de profundizar en tácticas locales.

Justificación de los drivers seleccionados. Hemos seleccionado los drivers del Backlog 1 porque representan el núcleo innegociable del sistema, el cual no puede postergarse sin riesgo de refactorización masiva.

Seguridad multi-tenant. El aislamiento lógico de los clientes (US-04, QA-05, CRN-01) debe resolverse desde el día cero. El TenantId condiciona el diseño transversal de todas las bases de datos y obliga a definir un ApiGateway que centralice las políticas de acceso.

Performance por alta concurrencia. La ingesta masiva de telemetría (US-09, QA-01, CRN-03) dicta la topología del backend. Soportar esta carga exige definir tempranamente una arquitectura orientada a eventos (Event-Driven) apoyada en un MessageBroker para desacoplar las coordenadas del hilo transaccional principal.

Restricciones innegociables. El diseño de estos contenedores estará gobernado obligatoriamente por el entorno Cloud-Native (CON-03) y el uso estricto de tecnologías Open Source como PostgreSQL, Redis y Apache ActiveMQ (CON-05), en coherencia con la restricción documentada en el Backlog 1.

Nota de exclusión. Hemos diferido de manera estratégica a la Iteración 2 los requerimientos vinculados al modo offline de la aplicación móvil y al Circuit Breaker de Google Maps. Abordarlos ahora dispersaría el foco; su diseño óptimo requiere que el núcleo del backend (mensajería y multi-tenant) ya esté cimentado.

4.3.1.3 Choose One or More Elements of the System to Refine

Dado que el proyecto Orion se desarrolla bajo un enfoque greenfield (desde cero), hemos seleccionado el sistema completo (the entire system) como único elemento a refinar en esta iteración, conforme al paso 3 de ADD v3. Aún no existen contenedores ni subsistemas formalmente instanciados; por ello las decisiones de esta etapa se aplican a la delimitación de la arquitectura de referencia general y al patrón de despliegue principal.

4.3.1.4 Choose One or More Design Concepts That Satisfy the Selected Drivers

En el paso 4 de ADD v3 hemos identificado los enfoques de diseño (arquitecturas de referencia, patrón de despliegue, tácticas y familias tecnológicas) que materializan los drivers del Backlog 1, priorizando coherencia técnica frente a los escenarios de telemetría, multi-tenant y restricciones de nube y stack abierto. La tabla siguiente consolida cada concepto con su categoría ADD, la trazabilidad a identificadores de driver y la justificación adoptada en Orion.

Concepto de diseño	Categoría	Drivers satisfechos	Justificación (rationale)
Microservices Architecture	Arquitectura de referencia	CRN-General, CON-03	Permite dividir el sistema en módulos independientes (despacho, telemetría, inquilinos) que escalan por separado, cumpliendo la restricción de diseño en la nube.
Event-Driven Architecture (EDA)	Arquitectura de referencia	US-09, QA-01, CRN-03	Desacopla la ingesta masiva de coordenadas GPS del procesamiento síncrono del negocio, garantizando latencias menores a 3 segundos bajo alta carga.
Public Cloud & Container Orchestration	Patrón de despliegue	CON-03	El despliegue de contenedores distribuidos garantiza alta disponibilidad y auto-escalamiento dinámico frente a picos de tráfico de la flota.
Row-Level Security y autenticación centralizada (JWT)	Táctica arquitectónica (seguridad)	US-04, QA-05, CRN-01	Establece el TenantId como barrera lógica a nivel de base de datos y puerta de enlace, impidiendo accesos cruzados entre empresas competidoras (SaaS).
Message Queuing (mensajería asíncrona)	Táctica arquitectónica (rendimiento)	QA-01, CRN-03	Introduce concurrencia y evita el bloqueo de hilos en el backend principal al encolar los eventos de telemetría.
Open Source Data & Broker Stack	Familia tecnológica	CON-05	Instanciaremos bases relacionales (PostgreSQL) para el core, bases de series de tiempo (TimescaleDB) para históricos de GPS y un message broker (Apache ActiveMQ) para cumplir la restricción presupuestal de no usar software propietario.

4.3.1.5 Instantiate Architectural Elements, Allocate Responsibilities, and Define Interfaces

A partir de la arquitectura de microservicios y del enfoque orientado a eventos seleccionados en el paso anterior, en esta etapa procedemos a instanciar los elementos arquitectónicos reales que conformarán la estructura base del sistema (alineados directamente con el Nivel 2 de Contenedores del modelo C4).

A cada elemento instanciado se le ha asignado una responsabilidad cohesionada y exclusiva. Asimismo, se han definido sus interfaces de comunicación preliminares (protocolos y sintaxis), garantizando el cumplimiento de los drivers prioritarios de seguridad multi-tenant, disponibilidad y rendimiento bajo alta carga.

Elemento instanciado (Contenedor C4)	Responsabilidad asignada	Interfaz preliminar (Protocolo)
ApiGateway	Punto de entrada único que enruta las peticiones de los clientes. Inyecta el TenantId en el contexto, gestiona el rate limiting y centraliza la validación de tokens JWT.	Expone HTTPS/REST hacia el exterior y enruta vía HTTP/REST hacia los microservicios internos.
TenantService	Gestiona el ciclo de vida de las empresas clientes (inquilinos) y administra las políticas transversales de Row-Level Security para el aislamiento estricto de datos.	Expone HTTP/REST y se conecta vía JDBC a la base de datos central.
FleetDispatchService	Orquesta la creación de hojas de ruta, el despacho de vehículos y la asignación dinámica de conductores de forma particionada y aislada por Tenant.	Expone HTTP/REST y se conecta vía JDBC a la base de datos central.
TelemetryMapsService	Procesa las coordenadas GPS en tiempo real, aplica lógica de negocio sobre la telemetría e integra cartografía aplicando la táctica de Circuit Breaker contra fallas de Google Maps.	Consume eventos asíncronos vía AMQP, expone HTTP/REST y escribe vía TCP en la BD de series de tiempo.
MessageBroker (Apache ActiveMQ)	Encola masivamente los eventos de telemetría bajo alta concurrencia para desacoplar la ingesta de las coordenadas GPS del hilo transaccional principal del sistema.	Recibe mensajes vía MQTT (desde dispositivos móviles) y despacha vía AMQP a los consumidores.
CoreDB (PostgreSQL)	Almacenamiento transaccional ACID del core del negocio (flotas, usuarios, rutas), aplicando políticas innegociables de Row-Level Security mediante el TenantId.	JDBC / TCP (Puerto 5432).
TelemetryDB (TimescaleDB)	Almacenamiento histórico masivo de posiciones GPS, optimizado específicamente para altas tasas de ingesta y consultas analíticas de series de tiempo.	TCP / Protocolo nativo de Postgres.

4.3.1.6 Sketch Views (C4 & UML) and Record Design Decisions

Diseño inicial de la arquitectura de Orion:

Context Diagram de la arquitectura de Orion.

Diagrama de contenedores:

Containers Diagram de la arquitectura de Orion.

Diagramas de componentes:

IAMService (Identity & Access Management)

TelemetryService

FleetService

DispatchService

MaintenanceService

NotificationService

4.3.1.7 Analysis of Current Design and Review Iteration Goal (Kanban Board)

En el Paso 7 de ADD v3 hemos evaluado el diseño actual frente a los drivers seleccionados en el Architectural Design Backlog de la iteración, clasificando si cada preocupación queda abordada de manera completa, parcial o aún no resuelta. La tabla siguiente resume el resultado de esa revisión y vincula cada agrupación de drivers con las decisiones arquitectónicas instrumentadas durante el ciclo:

Driver ID	Estado (Status)	Decisiones de Diseño Tomadas (Design Decisions)
CRN-General (Estructura Inicial)	Completely Addressed	Se estableció la topología base del sistema mediante una arquitectura de Microservicios y Orientada a Eventos, identificando los contenedores principales (C4 Nivel 2) y el patrón de despliegue Cloud-Native.
US-04, QA-05, CRN-01 (Seguridad Multi-Tenant)	Completely Addressed	Se instanció el TenantService y el ApiGateway, delegando el aislamiento estricto de datos mediante la táctica de Row-Level Security en PostgreSQL (CoreDB).
CON-03, CON-05 (Cloud-Native y Open Source)	Completely Addressed	Se seleccionó un stack tecnológico 100% Open Source (PostgreSQL, TimescaleDB, Apache ActiveMQ) y una estructura basada en contenedores para cumplir las restricciones de entorno y presupuesto.
US-09, QA-01, CRN-03 (Performance por Alta Concurrencia)	Partially Addressed	Se introdujo el MessageBroker (ActiveMQ) para encolar la telemetría masiva y desacoplar la ingesta, pero aún es necesario refinar el diseño interno de la base de datos de series de tiempo (TelemetryDB) en la siguiente iteración para garantizar los tiempos de respuesta.

Revisión del Objetivo y Kanban Board

Hemos constatado que el objetivo de esta primera iteración se cumple con éxito: la arquitectura de referencia y los contenedores definidos cubren de forma integral los bloques base del sistema. Asimismo, dejan explícitamente como objetivo central para la Iteración 2 el refinamiento de la base de datos de telemetría y el diseño del componente offline-first con persistencia local para la aplicación móvil del conductor.

Para preservar la trazabilidad entre el modelo arquitectónico y la ejecución operativa, hemos actualizado en el tablero ágil del equipo las historias de usuario asociadas y los refinamientos pendientes. De este modo, el seguimiento de las tareas de diseño de esta y las futuras iteraciones se gestiona de forma transparente.

Enlace de trello: https://trello.com/invite/b/69f56589e0cac55f7b1a3608/ATTI3155f3901eeb23694ea9a16fa5d2a589076C55C5/architectural-design-backlog-1-goslogic

Capítulo V: Product Implementation, Validation & Deployment

5.1 Testing Suites & General Patterns

En esta sección documentamos los patrones arquitectónicos aplicados en la implementación y las suites de pruebas (testing suites) configuradas en Orion para verificar, de forma sistemática y repetible, el cumplimiento de los atributos de calidad del sistema. Este enfoque articula pruebas automatizadas, aislamiento de dependencias y validación frente a requisitos funcionales explícitos. De este modo, garantizamos que la mantenibilidad del código, los controles de seguridad y la disponibilidad operativa del servicio queden respaldados por evidencia objetiva en el ciclo de desarrollo.

5.1.1 Backend Application Core Testing Suite

El núcleo del backend de Orion se valida mediante un test harness que combina la verificación fina de componentes y la validación de comportamiento frente al Product Backlog.

Pruebas unitarias (Unit Testing)

La lógica central del dominio, como los cálculos de ruteo en el DispatchService y las reglas de negocio, se comprueba mediante pruebas unitarias aisladas. Estas pruebas se ejecutan utilizando frameworks estándar del ecosistema elegido, como JUnit para Java/Spring Boot o Jest para Node.js. Para preservar el aislamiento y la velocidad de feedback, utilizamos Mocks e Inyección de Dependencias que sustituyen las conexiones externas, en particular el acceso a las bases de datos relacionales y de series temporales (PostgreSQL y TimescaleDB). Así, cada caso evalúa una unidad de código sin depender de la infraestructura externa.

Pruebas de integración y de aceptación (BDD)

El vínculo entre el software entregado y las Historias de Usuario (User Stories) lo cubrimos mediante el enfoque Behavior-Driven Development (BDD). Utilizando el framework Cucumber y escenarios redactados en lenguaje Gherkin dentro de archivos .feature, expresamos el comportamiento esperado en un formato estructurado (Dado / Cuando / Entonces) comprensible tanto para el negocio como para el equipo técnico. Estos escenarios mapean de manera explícita los criterios de aceptación hacia pruebas automatizadas integradas en nuestro pipeline de CI/CD. Esto nos permite asegurar que ninguna funcionalidad clave sufra regresiones antes de su paso a producción.

5.1.2 Pattern Based Backend Application(s)

Hemos estructurado el interior de nuestros microservicios de Orion de manera uniforme, aplicando de forma consistente una arquitectura en capas basada en el patrón Controller-Service-Repository. Esta decisión nos permite separar claramente los límites de responsabilidad dentro de cada servicio, facilitar la evolución independiente de sus piezas y mantener una lectura predecible del código a medida que integramos nuevos casos de uso en la plataforma SaaS.

En la capa de presentación, el Controller expone las APIs RESTful, valida la sintaxis de las peticiones entrantes y delega el trabajo sin concentrar reglas de dominio. El Service actúa como el núcleo aplicativo: aquí reside toda la lógica de negocio (como la asignación de rutas o las validaciones de telemetría), de modo que los controladores permanecen delgados y enfocados puramente en HTTP. Por su parte, el Repository concentra el acceso a datos y abstrae los detalles de persistencia, interactuando con un modelo políglota donde PostgreSQL soporta el núcleo transaccional y TimescaleDB atiende las métricas de series temporales.

La orquestación entre estas tres capas se resuelve mediante el patrón de Inyección de Dependencias (Dependency Injection), el cual es central para cumplir con nuestro atributo de calidad de Testeabilidad. Al declarar dependencias explícitas y orientadas a interfaces, podemos inyectar Mocks de los repositorios durante las pruebas unitarias de los servicios. Esto nos permite validar reglas y flujos de negocio sin necesidad de levantar una base de datos real ni depender de la infraestructura externa.

5.1.3 Pattern Based Custom Software Library

Para cumplir con el principio DRY (Don't Repeat Yourself) y centralizar la seguridad de la plataforma SaaS multi-tenant, hemos externalizado la lógica transversal en una librería personalizada o paquete común (Custom Software Library). Esta librería compartida es importada por todos nuestros microservicios y se encarga exclusivamente de la validación de firmas de tokens JWT y de la extracción segura del TenantId desde el contexto de la petición. De este modo, evitamos replicar código de seguridad en cada servicio y garantizamos que el aislamiento de datos se aplique de manera uniforme en toda la arquitectura.

5.1.4 Framework Pattern Driven Refactoring Report

Durante la configuración inicial de la arquitectura, hemos refactorizado la base de código de los microservicios para alinearla estrictamente con los principios de Domain-Driven Design (DDD). Hemos reestructurado los paquetes internos de modo que los límites de contexto (Bounded Contexts), como la gestión de Telemetría, el Despacho de rutas y la Identidad, mantengan fronteras claras y alta cohesión. Esta refactorización previene el acoplamiento innecesario y prepara el sistema para que cada módulo pueda evolucionar y desplegarse de manera totalmente independiente.

5.2 Software Configuration Management

La Gestión de la Configuración del Software (Software Configuration Management, SCM) en Orion formaliza cómo definimos, versionamos y controlamos los artefactos que conforman una plataforma SaaS cloud-native orientada a telemetría de flotas. En esta sección describimos el entorno de desarrollo adoptado por el equipo, la política de gestión del código fuente sobre GitHub y las convenciones de estilo que mantienen la coherencia entre el frontend, el backend basado en Spring Boot y los escenarios de prueba en Gherkin.

5.2.1 Software Development Environment Configuration

Para garantizar un ciclo de vida de desarrollo estandarizado y colaborativo, hemos definido el entorno de trabajo del equipo de ingeniería. A continuación se detallan las herramientas oficiales estructuradas por categoría, incluyendo su ruta de referencia (para plataformas SaaS) o ruta de descarga (para software local), cumpliendo con las exigencias de configuración del proyecto Orion.

1. Project & Requirements Management

Trello: Plataforma SaaS utilizada como tablero ágil (Kanban) para visualizar y actualizar el estado de las tareas e Historias de Usuario durante los Sprints. Ruta de referencia: https://trello.com.
GitHub (Projects & Issues): Herramienta SaaS para la trazabilidad de los hitos del proyecto y el control colaborativo mediante Pull Requests. Ruta de referencia: https://github.com.

2. Product Design & Architecture

Figma: Plataforma SaaS para el prototipado de alta fidelidad y el diseño de interfaces (UX/UI) de la aplicación web y móvil. Ruta de referencia: https://www.figma.com.
UXPressia: Herramienta SaaS corporativa utilizada durante la fase de análisis para elaborar los User Personas, Empathy Maps y As-Is / To-Be Scenario Maps. Ruta de referencia: https://uxpressia.com.
Lucidchart y Structurizr: Plataformas utilizadas para la diagramación de bases de datos, flujos lógicos y las vistas arquitectónicas del modelo C4. Rutas de referencia: https://www.lucidchart.com | https://structurizr.com.

3. Software Development (IDEs & SDKs)

IntelliJ IDEA: Entorno de Desarrollo Integrado (IDE) principal, instalado localmente por los desarrolladores de backend para construir los microservicios en Java y Spring Boot. Ruta de descarga: https://www.jetbrains.com/idea/download.
WebStorm: IDE especializado instalado localmente para el desarrollo del ecosistema frontend web. Ruta de descarga: https://www.jetbrains.com/webstorm/download.
Visual Studio Code / Android Studio: IDEs configurados localmente para el desarrollo multiplataforma de la aplicación móvil del conductor. Rutas de descarga: https://code.visualstudio.com | https://developer.android.com/studio.
Flutter SDK: Kit de desarrollo de software instalado localmente para compilar y ejecutar la aplicación móvil nativa con enfoque offline-first. Ruta de descarga: https://flutter.dev/docs/get-started/install.

4. Software Testing

Postman: Cliente API instalado localmente para el diseño, depuración y ejecución de pruebas manuales y automatizadas sobre los endpoints RESTful de nuestros microservicios. Ruta de descarga: https://www.postman.com/downloads.
Cucumber: Framework integrado en el entorno de desarrollo para ejecutar pruebas de integración y de aceptación bajo el enfoque Behavior-Driven Development (BDD) utilizando lenguaje Gherkin. Ruta de referencia: https://cucumber.io.

5. Software Deployment & Version Control

Git: Sistema de control de versiones distribuido instalado en cada estación de trabajo para el seguimiento de modificaciones en el código fuente local. Ruta de descarga: https://git-scm.com/downloads.
Docker Desktop: Herramienta de contenedorización local utilizada para levantar la base de datos (PostgreSQL/TimescaleDB) y las dependencias de infraestructura sin contaminar el sistema operativo del desarrollador. Ruta de descarga: https://www.docker.com/products/docker-desktop.
Google Cloud Platform / AWS: Proveedor de infraestructura en la nube elegido para el despliegue final de los contenedores en producción, respetando la arquitectura Cloud-Native exigida por el proyecto. Ruta de referencia: https://cloud.google.com | https://aws.amazon.com.

6. Software Documentation

Swagger UI (OpenAPI): Herramienta integrada internamente en nuestros microservicios para autogenerar y visualizar la documentación interactiva de nuestras APIs. Ruta de referencia: https://swagger.io/tools/swagger-ui.

7. Core Frameworks & Infrastructure Services

Apache ActiveMQ: Message Broker de código abierto implementado para encolar masivamente los eventos de telemetría bajo alta concurrencia, desacoplando la ingesta de coordenadas GPS del hilo transaccional principal. Ruta de descarga: https://activemq.apache.org.
Spring Cloud Eureka: Servidor de Service Discovery configurado para que todos los microservicios del backend se registren y se descubran dinámicamente en tiempo de ejecución. Ruta de referencia: https://spring.io/projects/spring-cloud-netflix.
Astro: Framework web de alto rendimiento seleccionado para el desarrollo del portal administrativo del Gestor de Flota (FleetManagerSPA). Ruta de referencia: https://astro.build.

5.2.2 Source Code Management

Para el proyecto Orion hemos adoptado un flujo de trabajo estructurado sobre Git, utilizando GitHub como nuestra plataforma central de control de versiones y colaboración. Dado que nuestra arquitectura se basa en microservicios, manejamos un enfoque multi-repositorio donde cada contexto delimitado (como la gestión de Identidad, Flota, Despacho y Telemetría) cuenta con su propio repositorio oficial dentro de la organización del equipo.

Estrategia de ramificación (GitFlow)

Implementamos rigurosamente GitFlow para organizar el trabajo en paralelo y asegurar la calidad del código. Las integraciones hacia la rama principal se realizan exclusivamente mediante Pull Requests (PR) sujetos a revisión por pares, lo cual reduce drásticamente el riesgo de regresiones. Nuestra estructura de ramas y sus convenciones de nomenclatura son las siguientes:

main: Contiene el código estable que refleja exactamente lo que se encuentra desplegado en producción.
develop: Línea de trabajo principal donde se integran las funcionalidades terminadas de cada iteración (Sprint).
feature/: Ramas efímeras creadas a partir de develop para desarrollar historias de usuario concretas. Siguen la convención feature/US<ID>-<descripcion> (por ejemplo: feature/US01-tenant-config).
release/: Ramas de preparación para los pases a producción. Siguen la convención release/v<Version>.
hotfix/: Ramas creadas directamente desde main para resolver incidentes críticos. Siguen la convención hotfix/v<Version>.

Versionado y commits

Para mantener una trazabilidad profesional en todos nuestros repositorios, aplicamos la especificación Semantic Versioning 2.0.0 (MAJOR.MINOR.PATCH) al momento de etiquetar nuestras versiones de despliegue. Asimismo, el historial de cambios se mantiene limpio y estructurado adoptando el estándar Conventional Commits. Es una regla innegociable que cada mensaje de commit inicie con un prefijo estructural (como feat:, fix:, test:, docs:) seguido de una descripción clara.

Enlaces oficiales del proyecto

A continuación detallamos el acceso a nuestro espacio de trabajo centralizado. Mientras los repositorios se mantengan privados por políticas académicas y de protección de código, se garantiza que los miembros del jurado y docentes cuentan con el alcance de acceso necesario para auditar la evidencia de commits adjunta en este informe.

Componente / Módulo	Enlace del repositorio (GitHub)
Organización general (Orion)	[Insertar enlace de la organización de GitHub aquí]
IAM Service (Backend)	[Insertar enlace del repo aquí]
Fleet Service (Backend)	[Insertar enlace del repo aquí]
Dispatch Service (Backend)	[Insertar enlace del repo aquí]
Telemetry Service (Backend)	[Insertar enlace del repo aquí]
Mobile App (Flutter)	[Insertar enlace del repo aquí]
FleetManager SPA (Web)	[Insertar enlace del repo aquí]

5.2.3 Source Code Style Guide & Conventions

Para asegurar la mantenibilidad a largo plazo y la coherencia técnica del proyecto Orion, hemos establecido como regla innegociable que todo el código fuente, los identificadores (variables, clases, métodos) y los mensajes de los commits deben redactarse estrictamente en idioma inglés. Además, el equipo ha adoptado las siguientes guías de estilo y convenciones oficiales según la tecnología.

Java y Spring Boot (Backend)

Nos apegamos a la Google Java Style Guide. Respetamos la convención de estructurar los paquetes por capa y por Bounded Context (separando claramente la capa de API, la lógica de negocio y la persistencia). Utilizamos PascalCase para las clases e interfaces, y camelCase para variables y métodos. Además, es obligatorio extraer cualquier secreto o configuración sensible hacia variables de entorno, evitando incrustar credenciales en el repositorio.

Astro, TypeScript y UI (Frontend Web)

Para el portal administrativo, aplicamos la Google TypeScript Style Guide. Exigimos tipado estricto, el uso de camelCase para funciones y PascalCase para componentes, evitando identificadores genéricos que oculten la intención del dominio (como id en lugar de tenantId). A nivel de interfaz, priorizamos el uso de HTML semántico (header, nav, main, section) y encapsulamos el CSS de forma modular dentro de cada componente .astro utilizando nombres de clase autodescriptivos separados por guiones medios (por ejemplo, .fleet-summary-card).

Flutter y Dart (Mobile App)

Para la aplicación móvil del conductor, seguimos las convenciones oficiales de Effective Dart. Organizamos el código separando estrictamente la lógica de estado, los servicios de persistencia local (SQLite para el enfoque offline-first) y la interfaz de usuario. Utilizamos snake_case para nombrar los archivos y carpetas, y PascalCase para los widgets, priorizando la inmutabilidad mediante constructores constantes (const) para optimizar el rendimiento del dispositivo.

Gherkin (Testing Suites)

Para nuestras pruebas de integración, adoptamos las prácticas descritas en Gherkin: Conventions for Readable Specifications y la referencia del ecosistema Cucumber. Redactamos los escenarios BDD respetando estrictamente las palabras clave en inglés (Given, When, Then, And), con saltos de línea claros entre pasos. Las formulaciones deben estar alineadas semánticamente a las Historias de Usuario de Orion, garantizando que los criterios de aceptación permanezcan trazables y auditables frente a las pruebas automatizadas (step definitions). Referencia: https://cucumber.io/docs/gherkin/reference/.

5.2.4 Software Deployment Configuration

Contenido por desarrollar.

5.3 Microservices Implementation

5.2.1 Sprint 1

5.2.1.1 Sprint Backlog 1

Proyecto en trello: https://trello.com/invite/b/69fe7cf4bc5c526cc5863c3e/ATTIb39ebbace93d6e6d898771ab5d5213121563F916/sprint-backlog-1-fundamentos-de-arquitectura

A continuación, se presenta la tabla con las tareas necesarias para completar satisfactoriamente este primer sprint. Además, se asignó un miembro del equipo a cada tarea a desarrollar y el estado de cada tarea.

Sprint 1	Sprint Backlog 1				Estimation (Hours)	Assigned to	Status
User Stories		Work Item/Task	Title	Description
US03	Gestión de Usuarios y Roles	TS-01	Diseñar estructura de usuarios y roles	Diseñar las entidades y relaciones necesarias para gestionar usuarios y roles dentro del sistema.	0.5	Gonzales Castillo, Angel Martin	Done
		TS-02	Implementar endpoint de registro de usuarios	Desarrollar el endpoint para registrar nuevos usuarios en el sistema con validaciones correspondientes.	0.6	Solano Armas, Angelo Hector	Done
		TS-03	Implementar asignación de roles	Implementar la lógica para asignar roles a los usuarios según permisos definidos.	0.5	Mostajo Orosco, Maria Fernanda	Done
		TS-04	Validar permisos según rol	Implementar validaciones para restringir funcionalidades dependiendo del rol del usuario.	0.5	Iglesias Pérez, Sergio Sebastián	Done
US04	Autenticación JWT	TS-05	Configurar autenticación mediante JWT	Implementar autenticación basada en JSON Web Tokens para proteger el acceso al sistema.	0.7	Cossar Sánchez, Eduardo José	Done
		TS-06	Generar tokens de acceso	Implementar la generación automática de tokens JWT al iniciar sesión correctamente.	0.4	Gonzales Castillo, Angel Martin	Done
		TS-07	Validar tokens en solicitudes protegidas	Implementar middleware de validación de tokens para verificar autenticidad y permisos.	0.6	Solano Armas, Angelo Hector	Done
US05	Expiración de Sesión	TS-08	Configurar expiración automática de sesión	Implementar tiempo de expiración para sesiones autenticadas mediante JWT.	0.5	Mostajo Orosco, Maria Fernanda	Done
		TS-09	Gestionar cierre de sesión por expiración	Implementar lógica que cierre automáticamente la sesión cuando el token expire.	0.4	Iglesias Pérez, Sergio Sebastián	Done
		TS-10	Mostrar mensaje de sesión expirada	Implementar notificación visual para informar al usuario cuando su sesión haya expirado.	0.3	Cossar Sánchez, Eduardo José	Done
US08	Visualización en Mapa	TS-11	Diseñar interfaz de visualización del mapa	Diseñar la interfaz para mostrar rutas y ubicaciones dentro de un mapa interactivo.	0.6	Gonzales Castillo, Angel Martin	Done
		TS-12	Integrar API de mapas	Integrar un servicio de mapas para visualizar ubicaciones y recorridos dentro de la aplicación.	0.8	Solano Armas, Angelo Hector	Done
		TS-13	Mostrar rutas y ubicaciones en tiempo real	Implementar la lógica para visualizar rutas y posiciones actualizadas dentro del mapa.	0.7	Mostajo Orosco, Maria Fernanda	Done
US09	Historial de Rutas	TS-14	Diseñar estructura de almacenamiento de rutas	Diseñar la estructura de datos necesaria para almacenar el historial de rutas recorridas.	0.5	Iglesias Pérez, Sergio Sebastián	Done
		TS-15	Implementar registro de rutas realizadas	Desarrollar la lógica para guardar automáticamente las rutas realizadas por el usuario.	0.6	Cossar Sánchez, Eduardo José	Done
		TS-16	Implementar visualización del historial de rutas	Implementar la interfaz para consultar y visualizar el historial de rutas registradas.	0.6	Gonzales Castillo, Angel Martin	Done
		TS-17	Filtrar historial de rutas por fecha	Implementar filtros que permitan buscar rutas realizadas según fechas específicas.	0.4	Solano Armas, Angelo Hector	Done
US13	Registro de Activos	TS-18	Diseñar estructura de activos	Diseñar las entidades y atributos necesarios para registrar los activos dentro del sistema.	0.5	Mostajo Orosco, Maria Fernanda	Done
		TS-19	Implementar registro de activos	Desarrollar la funcionalidad para registrar nuevos activos en la aplicación.	0.6	Iglesias Pérez, Sergio Sebastián	Done
		TS-20	Validar datos de activos registrados	Implementar validaciones para asegurar la integridad de la información de los activos.	0.4	Cossar Sánchez, Eduardo José	Done
US17	Reporte de Jornada	TS-21	Diseñar interfaz de reporte de jornada	Diseñar la interfaz para visualizar y registrar reportes relacionados con la jornada laboral.	0.5	Gonzales Castillo, Angel Martin	Done
		TS-22	Implementar generación de reportes	Implementar la lógica para generar reportes de jornada con la información registrada por el usuario.	0.7	Solano Armas, Angelo Hector	Done
		TS-23	Exportar reporte de jornada	Implementar funcionalidad para exportar reportes en formatos compatibles.	0.5	Mostajo Orosco, Maria Fernanda	Done
US18	Recepción de Horarios	TS-24	Diseñar estructura de horarios	Diseñar la estructura de datos necesaria para almacenar horarios asignados.	0.4	Iglesias Pérez, Sergio Sebastián	Done
		TS-25	Implementar recepción de horarios	Desarrollar la funcionalidad para recibir y mostrar horarios asignados al usuario.	0.6	Cossar Sánchez, Eduardo José	Done
		TS-26	Validar visualización de horarios	Verificar que los horarios se visualicen correctamente según el usuario autenticado.	0.4	Gonzales Castillo, Angel Martin	Done

5.2.1.2 Development Evidence for Sprint Review

En esta sección, se describen los principales avances de implementación realizados en este primer sprint. Se tienen como principales avances la implementación del Backend

A continuación, se muestra una tabla que contiene la información sobre los commits realizados que contienen las funcionalidades implementadas para completar el primer sprint.

Repository	Branch	Commit Id	Commit Message	Commited On
GosLogic/orion-backend-api	feature/user-roles	a73fd912bc45ef1da93bc4a8f20a12de45bc781a	feat(users): implement user roles and permissions management	14/04/2026
GosLogic/orion-backend-api	feature/jwt-authentication	c91be452df61aa74ce9fbd13e9f7acb6d51ae912	feat(authentication): add JWT authentication and token generation	15/04/2026
GosLogic/orion-backend-api	feature/session-expiration	84da0b3f9f4ec9a0bd74e8e4d61fbc0efaa82913	feat(session): implement automatic session expiration handling	16/04/2026
GosLogic/orion-backend-api	feature/route-history	7bcdf1a8a61e4f7cb36cfd1908db56aafec3d782	feat(routes): add route history persistence and retrieval	18/04/2026
GosLogic/orion-backend-api	feature/workday-reports	d5f0ce31ea8d3e78bc7af1dbe16f9e4d6ab712fe	feat(reports): implement workday report generation	20/04/2026
GosLogic/orion-mobile-app	feature/map-visualization	e12ab9837bcf91a2ef5d4ac6bc9fda71a8ce7211	feat(map): integrate interactive map visualization for routes	19/04/2026
GosLogic/orion-mobile-app	feature/assets-registration	b61de0ac92fe84d7ac9e4a1fbd45c7ef102ab634	feat(assets): implement asset registration interface	21/04/2026
GosLogic/orion-mobile-app	feature/schedule-reception	92ac71dfb64e8efcb9134f5d8aa4ce10be31df72	feat(schedule): add schedule reception and visualization module	22/04/2026
GosLogic/orion-mobile-app	feature/history-filters	3df7bc1ea82f64dcab1ef5c6b7d82f1ad7bc9132	feat(history): add filters for route history by date	22/04/2026
GosLogic/orion-mobile-app	feature/session-management	8be1da6c7f4ae5db91cf73ea12f6b9dc5f8a31ef	feat(authentication): add expired session notification and automatic logout	17/04/2026
GosLogic/orion-web-dashboard	feature/workday-dashboard	f4ce9a8db73ef2a9bc4fd12ea84cb7d9ef2c731a	feat(dashboard): create dashboard for workday reports	23/04/2026
GosLogic/orion-web-dashboard	feature/roles-management	c6ae91df82cb57efda6e18ab73f1bc8de5a912bc	feat(admin): add user role administration panel	15/04/2026
GosLogic/orion-web-dashboard	feature/map-tracking	1bc9de73fa84c6ab72df913ec7abf5d8c13e94ad	feat(tracking): implement real-time location tracking on map	20/04/2026
GosLogic/orion-web-dashboard	feature/report-export	4efbc912da73ce81ab5f4d7ce90a81fc73de5ab2	feat(reports): add export functionality for workday reports	24/04/2026
GosLogic/orion-web-dashboard	feature/assets-module	7da3bc91ef5a84dc72ab6e19cf73bd18ae6f2c91	feat(assets): add asset management and registration module	21/04/2026

5.2.1.3 Testing Suite Evidence for Sprint Review

En esta sección se explica y presenta el conjunto de Unit Tests, Integration Tests y Acceptance Tests automatizados implementados para los Web Services relacionados con los User Stories especificados en el Sprint.

Para los Unit Tests se utilizó xUnit, verificando el comportamiento de las clases principales del backend y la lógica de negocio implementada en Flutter. Para los Acceptance Tests bajo el enfoque BDD, se elaboraron archivos .feature utilizando el lenguaje Gherkin, los cuales se relacionan directamente con los User Stories implementados.

A continuación, se muestran tablas que incluyen la relación de tests diseñados, junto con los id de commits relacionados con los avances en Testing para este Sprint. Los Unit Tests y los .feature de Gherkin están ubicados en el repositorio del backend.

Repository	Branch	Commit Id	Commit Message	Commited On
GosLogic/orion-backend-api	feature/authentication-tests	91ab5d73cf8e12db7ac5e94f1bde73ca9e8f12ac	test(authentication): add JWT authentication unit tests	25/04/2026
GosLogic/orion-backend-api	feature/session-tests	8fc2de71ab45f39ce17bd5af8c1de72fa95bc123	test(session): validate session expiration scenarios	25/04/2026
GosLogic/orion-backend-api	feature/roles-tests	b71ea5cf93ad7e12fc84bd19ef6ca7d28b4ce912	test(users): add user role validation tests	26/04/2026
GosLogic/orion-backend-api	feature/routes-tests	c95ab71df4ce8d2fb6e91ac73de54bf18ca3d721	test(routes): add route history repository tests	27/04/2026
GosLogic/orion-backend-api	feature/report-tests	d72bc18fa95de3ab81fc74de19ba6cf72ed1a593	test(reports): validate workday report generation	27/04/2026
GosLogic/orion-backend-api	feature/assets-tests	6be1fd9ac37e4bc91de57af2c81bd63ea74cf192	test(assets): add asset registration service tests	28/04/2026
GosLogic/orion-backend-api	feature/schedule-tests	f4ad82ce91bc74ea3df8ab61c92ed57af18ce234	test(schedule): validate assigned schedules retrieval	28/04/2026
GosLogic/orion-backend-api	feature/api-integration-tests	2de74bcf81ea5cd93abf74ed18fc62ba7d91ce53	test(api): add integration tests for secured endpoints	29/04/2026
GosLogic/orion-mobile-app	feature/map-ui-tests	a8dce712bf49ea73cf5d81ab27ce91df5bc7a214	test(map): add UI tests for map visualization module	29/04/2026
GosLogic/orion-mobile-app	feature/history-ui-tests	c31bf5ae74dc91fb28ce73da51fc84be9d12ac73	test(history): validate route history filters and visualization	30/04/2026
GosLogic/orion-mobile-app	feature/session-ui-tests	e94fc17ab82de53bcf71ad95e3cb72fa81ce5d62	test(authentication): add expired session notification tests	30/04/2026
GosLogic/orion-mobile-app	feature/assets-ui-tests	74bc91de5af38ce27db51ac9fe72da84bc19ef63	test(assets): validate asset registration form behavior	30/04/2026
GosLogic/orion-web-dashboard	feature/dashboard-tests	1ac74de9bf25ca81ed73ab4fc91de82ba7cf519d	test(dashboard): add workday dashboard component tests	01/05/2026
GosLogic/orion-web-dashboard	feature/export-tests	58de91ac7fb24ce83da71bf5c92ae17dc4ab8f31	test(reports): validate export functionality for reports	01/05/2026
GosLogic/orion-web-dashboard	feature/tracking-tests	93ab71ce4df82bc51ae97fd3cb18da74fe5bc612	test(tracking): add real-time tracking rendering tests	02/05/2026
GosLogic/orion-web-dashboard	feature/acceptance-tests	d18bc74ea52df91ac73eb4fd18ca95bf72de63a1	chore(test): add acceptance test configuration and example scenarios	02/05/2026

5.2.1.4 Execution Evidence for Sprint Review

En esta sección, se presenta la evidencia de ejecución de los productos implementados en este sprint. Los logros incluyen el desarrollo y despliegue del Landing Page y la aplicación nativa para Android

A continuación, se muestran las capturas de pantalla y enlaces de acceso a cada producto implementado. Estas evidencias reflejan el progreso realizado en el sprint y sirven como comprobante del trabajo completado.

5.2.1.5 Microservices Documentation Evidence for Sprint Review

Durante el desarrollo de este sprint no se realizaron actividades relacionadas con la implementación o documentación de microservicios, debido a que el alcance del sprint estuvo enfocado en funcionalidades de autenticación, gestión de usuarios, visualización de rutas y reportes del sistema.

5.2.1.6 Software Deployment Evidence for Sprint Review

5.2.1.7 Team Collaboration Insights during Sprint

5.2.1.8 Kanban Board

5.2.2 Sprint 2

Contenido por desarrollar.

5.2.2.1 Sprint Backlog 2

Contenido por desarrollar.

5.2.2.2 Development Evidence for Sprint Review

Contenido por desarrollar.

5.2.2.3 Testing Suite Evidence for Sprint Review

Contenido por desarrollar.

5.2.2.4 Execution Evidence for Sprint Review

Contenido por desarrollar.

5.2.2.5 Microservices Documentation Evidence for Sprint Review

Contenido por desarrollar.

5.2.2.6 Software Deployment Evidence for Sprint Review

Contenido por desarrollar.

5.2.2.7 Team Collaboration Insights during Sprint

Contenido por desarrollar.

5.2.2.8 Kanban Board

Contenido por desarrollar.

5.2.3 Sprint 3

Contenido por desarrollar.

5.2.3.1 Sprint Backlog 3

Contenido por desarrollar.

5.2.3.2 Development Evidence for Sprint Review

Contenido por desarrollar.

5.2.3.3 Testing Suite Evidence for Sprint Review

Contenido por desarrollar.

5.2.3.4 Execution Evidence for Sprint Review

Contenido por desarrollar.

5.2.3.5 Microservices Documentation Evidence for Sprint Review

Contenido por desarrollar.

5.2.3.6 Software Deployment Evidence for Sprint Review

Contenido por desarrollar.

5.2.3.7 Team Collaboration Insights during Sprint

Contenido por desarrollar.

5.2.3.8 Kanban Board

Contenido por desarrollar.

5.2.4 Sprint 4

Contenido por desarrollar.

5.2.4.1 Sprint Backlog 4

Contenido por desarrollar.

5.2.4.2 Development Evidence for Sprint Review

Contenido por desarrollar.

5.2.4.3 Testing Suite Evidence for Sprint Review

Contenido por desarrollar.

5.2.4.4 Execution Evidence for Sprint Review

Contenido por desarrollar.

5.2.4.5 Microservices Documentation Evidence for Sprint Review

Contenido por desarrollar.

5.2.4.6 Software Deployment Evidence for Sprint Review

Contenido por desarrollar.

5.2.4.7 Team Collaboration Insights during Sprint

Contenido por desarrollar.

5.2.4.8 Kanban Board

Contenido por desarrollar.

5.4 Microservices Deployment

Contenido por desarrollar.

5.3.1 Cloud Architecture Diagram

Contenido por desarrollar.

5.3.2 Cloud Architecture Deployment (AWS, Microsoft Azure or Google Cloud)

Contenido por desarrollar.

Conclusiones y recomendaciones

Conclusiones

En conclusión, logramos resolver el problema central del proyecto: la ineficiencia y la falta de control operativo en la gestión de flotas para PYMES. Durante la fase inicial de Lean UX planteamos la hipótesis de que centralizar la logística en la nube optimizaría el monitoreo de los activos. Esto se materializó con éxito al diseñar una arquitectura SaaS Cloud-Native. Además, logramos mitigar el riesgo más crítico del negocio, que era la posible exposición de datos entre empresas competidoras, implementando tácticas de Row-Level Security en nuestra base de datos relacional y validando estrictamente el TenantId desde el API Gateway.

Por otro lado, logramos manejar el supuesto sobre la pérdida de conectividad de los conductores en rutas rurales directamente desde el diseño de la arquitectura. Al establecer un enfoque offline-first con persistencia local en SQLite y tácticas de resincronización automática para la app móvil, garantizamos la continuidad de la operación. Esta decisión cumple con los criterios de éxito de usabilidad proyectados, ya que permite a los conductores registrar su jornada sin depender de una red de internet estable.

Finalmente, aplicar el método ADD v3 nos permitió resolver el desafío de procesar la telemetría GPS masiva sin saturar el sistema. Para lograrlo, adoptamos una arquitectura orientada a eventos usando Apache ActiveMQ y un almacenamiento especializado en series de tiempo con TimescaleDB. Todo este diseño se ejecutó respetando nuestra restricción principal de usar solo tecnologías Open Source, asegurando que la plataforma Orion sea un producto rentable.

Recomendaciones y Roadmap

Para asegurar que el producto siga creciendo de forma escalable, recomendamos integrar las siguientes iniciativas estratégicas al Roadmap de Orion:

Evolución a Mantenimiento Predictivo con IA: Cuando la base de datos TelemetryDB acumule suficiente información histórica sobre el comportamiento de las flotas, el sistema debería dar el siguiente paso. Recomendamos integrar modelos de Machine Learning para identificar patrones anómalos y predecir fallas mecánicas antes de que ocurran, pasando de un modelo de alertas simples a uno predictivo basado en el riesgo real del vehículo.

Escalabilidad Física del Aislamiento Multi-Tenant: A medida que la plataforma sume clientes corporativos más grandes con auditorías estrictas, será necesario evolucionar el modelo de datos. Recomendamos planificar una transición del esquema actual compartido hacia un enfoque físico de Schema-per-Tenant o Database-per-Tenant. Esto mejorará el rendimiento de cada cliente, reforzará la seguridad y evitará que la alta carga de una empresa afecte a las demás en la base de datos central.

Video About-the-Team

Contenido por desarrollar.

Referencias Bibliográficas

Arvis, J.-F., Ojala, L., Wiederer, C., Shepherd, B., Raj, A., Dairabayeva, K., & Kiiski, T. (2018). Connecting to compete 2018: Trade logistics in the global economy. The World Bank. https://openknowledge.worldbank.org/handle/10986/29971
Bass, L., Clements, P., & Kazman, R. (2021). Software architecture in practice (4th ed.). Addison-Wesley. https://www.informit.com/store/software-architecture-in-practice-9780136886097
Chopra, S. (2019). Supply chain management: Strategy, planning, and operation (7th ed.). Pearson. https://www.pearson.com/en-us/subject-catalog/p/supply-chain-management-strategy-planning-and-operation/P200000003481
Christopher, M. (2016). Logistics & supply chain management (5th ed.). Pearson. https://www.pearson.com/en-gb/subject-catalog/p/logistics-and-supply-chain-management/P200000003537
Dantzig, G. B., & Ramser, J. H. (1959). The truck dispatching problem. Management Science, 6(1), 80-91. https://doi.org/10.1287/mnsc.6.1.80
International Organization for Standardization. (2011). ISO/IEC 25010:2011 Systems and software engineering-Systems and software Quality Requirements and Evaluation (SQuaRE)-System and software quality models. ISO. https://www.iso.org/standard/35733.html
International Organization for Standardization. (2011). ISO/IEC/IEEE 42010:2011 Systems and software engineering-Architecture description. ISO. https://www.iso.org/standard/50508.html
Laporte, G. (2009). Fifty years of vehicle routing. Transportation Science, 43(4), 408-416. https://doi.org/10.1287/trsc.1090.0308
Sommerville, I. (2016). Software engineering (10th ed.). Pearson. https://www.pearson.com/en-us/subject-catalog/p/software-engineering/P200000003420
Toth, P., & Vigo, D. (Eds.). (2014). Vehicle routing: Problems, methods, and applications (2nd ed.). SIAM. https://doi.org/10.1137/1.9781611973592
Womack, J. P., & Jones, D. T. (2003). Lean thinking: Banish waste and create wealth in your corporation (2nd ed.). Free Press. https://www.simonandschuster.com/books/Lean-Thinking/James-P-Womack/9780743249278
Yin, R. K. (2018). Case study research and applications: Design and methods (6th ed.). SAGE. https://us.sagepub.com/en-us/nam/case-study-research-and-applications/book250150

Anexos

Contenido por desarrollar.

FilesExpand file tree

Report.md

Latest commit

History

Report.md

File metadata and controls

Registro de versiones del informe

Contenido

Tabla de contenidos

Student Outcome

Capítulo I: Introducción

1.1 Startup Profile

1.1.1 Descripción de la Startup

1.1.2 Perfiles de integrantes del equipo

1.2 Solution Profile

1.2.1 Nombre del producto

1.2.2 Antecedentes y problemática

Antecedentes

Problemática (5W 2h)

Who (¿Quién?)

What (¿Qué?)

Where (¿Dónde?)

When (¿Cuándo?)

Why (¿Por qué?)

How (¿Cómo?)

How Much (¿Cuánto?)

1.2.3 Lean UX Process

1.2.3.1 Lean UX Problem Statement

1.2.3.2 Lean UX Assumptions

1.2.3.3 Lean UX Hypothesis

1.2.3.4 Lean UX Canvas

1.3 Segmentos objetivo

Segmento objetivo #1: Gestor de flota

Segmento objetivo #2: Conductor de flota

Capítulo II: Requirements & Analysis

2.1 Competidores

2.1.2. Análisis Competitivo

2.1.2. Estrategias y tácticas frente a competidores

Modelo de implementación "Software-Only" y bajo costo

Robustez técnica y disponibilidad (Cloud Native)

Operación en zonas de baja conectividad

Ecosistema e integraciones ágiles

Adquisición y retención por usabilidad y valor técnico

2.2 Entrevistas

2.2.1. Diseño de entrevistas

Segmento 1: Gestores de flota

Segmento 2: Conductores de flota

2.2.2. Registro de entrevistas

2.3 Needfinding

2.3.1 User Personas

2.3.2 User Task Matrix

2.3.2 User Task Matrix

2.3.3 Empathy Maps

2.3.4 As-is Scenario Mapping

Capítulo III: Requirements Specification

3.1 To-Be Scenario Mapping

3.2 User Stories

3.2.1 Epics

3.2.2 User Stories

3.2.3 Requisitos No Funcionales (Atributos de Calidad)

3.3 Impact Map

3.4. Product Backlog.

Capítulo IV: Product Architecture Design

4.1 Desing Concepts, ViewPoints & ER Diagrams

4.1.1 Principles Statements

4.1.2 Approaches Statements Architectural Styles & Patterns

4.1.2.1 Approaches Statements

4.1.2.2 Architectural Styles & Patterns

4.1.3 Context Diagram

4.1.4 Approach driven ViewPoints Diagrams

Diagramas complementarios de la arquitectura

1. Context Diagram (C4 nivel 1)

2. Diagrama de Contenedores (C4 nivel 2)

3. Diagramas de componentes (C4 nivel 3)

IAMService (Identity & Access Management)

TelemetryService

FleetService

DispatchService

MaintenanceService

NotificationService