Hoja de Trabajo - monicabajonerodcastro/SportApp GitHub Wiki
Hoja de Trabajo
Objetivos
- Posicionar a SportApp como un jugador principal en el segmento de las aplicaciones de salud y bienestar basadas en el deporte y la buena alimentación de sus usuarios en Latinoamerica.
- Incursionar en el segmento de las aplicaciones de apoyo y gestión a deportistas no profesionales
- Desarrollar una aplicación web y mobile que se diferencie de otras aplicaciones y plataformas ya existentes, ofreciendo servicios a usuarios latinoamericanos para apoyar la práctica de la actividad física
Restricciones de negocio
- SportApp tiene 8 semanas para diseñar la arquitectura de este sistema, incluidas pruebas de concepto y experimentos de arquitectura
- SportApp tiene 8 semanas para desarrollar una primera versión de la aplicación
- Se tiene presupuesto para un equipo de arquitectura de 4 personas y pagar un equipo de desarrollo de 4 personas
- El recaudo de dinero proveniente de inversión de riesgo depende de mostrar un prototipo al finalizar las 16 semanas, por lo que esta fecha no es modificable
Restricciones de tecnología
- Dado que el equipo de trabajo tiene experiencia en Python, esta tecnología debe ser utilizada como plataforma de ejecución de la nueva solución
- Es mandatorio que se tengan clientes móviles y web para la solución
- Uso de algún proveedor de nube para la solución
Requisitos de calidad
- Se debe poder agendar una sesión con un entrenador/médico en menos de 2 segundos
- El registro, clasificación y recomendación de planes de un usuarios debe realizarse en menos de 3 segundos
- El registro de usuarios debe funcionar 7x24x365
- El servicio de entrenador debe estar disponible durante todo el tiempo del entrenamiento
- Cuando ocurren eventos masivos, como competencias o salidas deportivas, el registro de usuarios puede darse en grandes volúmenes, se debe seguir respondiendo en el tiempo establecido, hasta con 1000 registros simultáneos
- En caso de eventos masivos, por ejemplo travesías de ciclo montañismo, medias maratones o maratones, es necesario que se puedan monitorear y notificar alertas y cambios a los participantes en el mismo tiempo y hasta con 1000 usuarios simultáneos
- La comunicación con aplicaciones complementarias (como strava) debe realizarse en menos de 2 segundos y se debe garantizar que ningún dato se pierda en caso de no contar con comunicación al momento de enviar la información a la aplicación tercera
- El cálculo y visualización de indicadores de salud como FTP y VO2 max debe ocurrir en menos de tres segundos después de terminado un evento deportivo
- Toda la información de un usuario debe estar protegida contra modificaciones no autorizadas (integridad) o consulta de datos personales y médicos (confidencialidad) por personas no autorizadas para ello
- Agregar un nuevo indicador debe ser posible de hacerse sin modificar la aplicación web o la app móvil (generar una nueva versión o redespliegue)
Backlog de arquitectura
El Backlog de Arquitectura se manejó en el tablero de jira.
Las funcionalidades se definieron en el tablero de jira.
Se definen los siguientes ítems relacionados a atributos de calidad:
Se definieron las siguientes historias necesarias para completar las tareas, cada una dentro de su épica correspondiente:
- AR-2: Definición de problema de negocio a resolver (Visión de arquitectura)
- AR-3: Definición de objetivos de los stakeholders (Visión de Arquitectura)
- AR-4: Riesgos (Visión de Arquitectura)
- AR-5: Restricciones de negocio y tecnología (Visión de Arquitectura)
- AR-6: Esfuerzo estimado para construir la aplicación (Visión de Arquitectura)
- AR-7: Modelo de contexto (Visión de Arquitectura)
- AR-8: Modelo de dominio (Visión de Arquitectura)
- AR-9: Modelo de componentes (Visión de Arquitectura)
- AR-10: Modelo de despliegue (Visión de Arquitectura)
- AR-12: Definición de componentes a probar (Documento de estrategia de pruebas)
- AR-13: Definición de alcance de las pruebas (Documento de estrategia de pruebas)
- AR-14: - Definición de tipos de pruebas (Documento de estrategia de pruebas)
- AR-15: Creación de objetivos de arquitectura
- AR-16: Creación de restricciones de negocio
- AR-17: Creación de restricciones de tecnología
- AR-18: Creación de requisitos de calidad
- AR-25: Creación EDT (Gerencia de Proyectos)