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: