El trabajo fue realizado en su totalidad mientras realizábamos el proyecto de diploma de la carrera de Ingeniería de Sistemas. Backend: se refiere a la parte de un sistema informático que es responsable de la lógica empresarial y el almacenamiento de datos.
Introducción
- Estructura del documento
- Presentación del equipo
- Descripción del cliente
- Elección del proyecto
- Objetivos
- Objetivos académicos
- Objetivos de proyecto
- Objetivos de producto
- Objetivos de proceso
Esto requiere que el equipo dedique horas y esfuerzo a implementarlo. Por lo tanto, el equipo pretende dedicar un mayor porcentaje de tiempo al desarrollo del sistema (incluidas las pruebas unitarias) que al resto de las tareas del proyecto.
Problema y solución
Descripción del problema 1. Contexto del problema
- Tipos de usuarios y necesidades 1. Especialistas
- Situación actual
- Objetivos generales del producto
Los pacientes deben poder elaborar su plan nutricional teniendo en cuenta los requisitos marcados por los expertos. Los pacientes pueden cambiar su plan de nutrición a través del sistema, que tiene la opción de modificar un plan existente.
Descripción de la solución
- Descripción final del producto
Esto garantiza que se mantenga un nivel adecuado de seguridad y privacidad de los datos en el sistema. Una vez que se introduce un nuevo alimento, pasa a formar parte de las opciones para crear el plan en el sistema del paciente.
Proceso y ciclo de vida
Enfoque y Metodología
Otro de los pilares más importantes es “las personas y las interacciones por encima de los procesos y herramientas” [10], esto permitió que el equipo no estuviera atado a una forma específica de trabajar, sino que, si el contexto lo requería, tener libertad para experimentar. . , innovar o cambiar las prácticas existentes.
Ciclo de vida
Fases
- Estructuración del proyecto
- Desarrollo
- Documentación
Para esta fase, el equipo determinó que el uso de roles, eventos y objetos de Scrum no aplicaba, ya que Scrum es más eficiente como metodología después de tener una versión inicial del product backlog [17]. Como en la fase de estructuración del proyecto, el equipo decidió utilizar Kanban.
Ingeniería de requerimientos
Ciclo de vida
- Design Thinking como herramienta
- Relevamiento
- Análisis
- Especificación
- Validación
Es decir, el equipo vinculó la fase de empatía con la investigación de requisitos y la fase de definición con su análisis. Una vez que se completó la investigación y el análisis, el equipo pasó a especificar los requisitos.
Actores
Lista de compras: Se ha definido que para cada plan el paciente pueda ver los diferentes ingredientes y sus respectivas cantidades necesarias para elaborarlos, de modo que pueda organizar sus compras en el supermercado. El paciente tendrá la opción de recibir la lista por correo electrónico o verla directamente en una pantalla. Intentamos validar la solución propuesta con pacientes y especialistas previamente entrevistados presentando los wireframes finales.
La respuesta obtenida en esta etapa fue positiva, los wireframes propuestos eran correctos y tanto los pacientes como los especialistas expresaron su deseo de utilizar las funciones a diario.
Requerimientos funcionales
- Nuevo requerimiento en fase de desarrollo
Durante la fase de desarrollo y después del lanzamiento de la primera versión (al comienzo del sprint 12), el equipo decidió agregar un nuevo requisito junto con el cliente. En conversaciones entre el equipo y el cliente surgió la idea de mirar la viabilidad de vincularse con Google Fit. Para usarlo necesitas una cuenta de Google y un dispositivo móvil o reloj inteligente [21].
Como se puede observar en las imágenes, la aplicación Google Fit ofrece la posibilidad de establecer objetivos en cuanto a puntos de cardio y pasos realizados por día. El equipo descubrió e investigó en profundidad la posibilidad de integración con su API para comprender el esfuerzo que requería y lo útil que podía resultar para el paciente. Es por eso que se decidió implementar la integración de esta herramienta, sumando a las mediciones del sistema el número de pasos y puntos cardio para el intervalo de tiempo.
Requerimientos no funcionales
Descripción El tiempo promedio de aprendizaje que los pacientes necesitan para crear un plan de 5 días no debe ser superior a 7 minutos. Descripción Tiempo promedio de aprendizaje del paciente al editar un plan de 4 partes. Descripción El tiempo promedio de aprendizaje del paciente al recuperar una lista de alimentos para un plan específico no debe ser superior a 2 minutos.
Descripción El tiempo medio de aprendizaje de los profesionales para registrar la medición de un paciente debe ser de 2 minutos. Descripción El tiempo medio de aprendizaje de los expertos para preparar un almuerzo de 3 ingredientes no debe ser superior a 3 minutos y el máximo de solicitud de ayuda en el camino. Descripción El tiempo de respuesta del servidor debe ser de 500 ms o menos para el 90 % de las operaciones bajo carga normal.
Restricciones
Arquitectura y Diseño
Arquitectura a alto nivel
- Catálogo de Elementos
El equipo entiende que un diagrama de "arquitectura de alto nivel" permite al lector presentarse en general a lo que se discutirá más adelante. Por un lado, el paciente puede acceder a sus principales funcionalidades relacionadas con la creación y seguimiento de planes alimentarios, registro de datos e historial en general. El proyecto asociado con la fachada se llamó Artemisa (diosa gemela griega de Apolo), este nombre se mencionará a lo largo de la arquitectura.
El proyecto asociado con el backend se llamó Apolo (dios gemelo griego Artemisa), se hará referencia a este nombre en toda la arquitectura. Base de datos: Base de datos relacional MySQL, utilizando el servicio AWS RDS en entornos de ensayo y producción. Cola de mensajes: La cola de mensajes logra la asincronía mencionada en el punto anterior a través de una tabla de trabajos en la base de datos.
Elección de tecnologías
- Frontend - Página web
- Backend
- Base de datos
- Proveedor en la nube
- Cola de mensajes
Es un marco web basado en Python que se centra en la creación de sitios web complejos basados en bases de datos. Es versátil y, si bien es adecuado para sitios web basados en bases de datos, también puede utilizarse para otros fines [38]. Lo primero que se analizó fue la elección del tipo de base de datos: relacional o no relacional.
Son un tipo de base de datos que se caracteriza por trabajar con el lenguaje declarativo SQL, lo que permite muchas opciones de consulta. Baja estandarización: el lenguaje varía según el tipo de base de datos utilizada [40]. El equipo ya tiene experiencia con este tipo de base de datos y es un modelo fácil de manejar.
Vistas de Módulos
- Vista de Capas
- Vista de descomposición 1. Representación primaria
- Vista de Uso
- Modelo de datos
Sin embargo, la computadora sólo ejecuta tareas de larga duración en segundo plano, por lo que la velocidad jugó un papel menor en esta decisión. El equipo decidió estructurar el sistema en capas que constan de módulos que proporcionan un conjunto coherente de funcionalidades. El equipo optó por utilizar modelos Eloquent directamente para interactuar con los datos porque su implementación se basa en el patrón Active Record [53].
En conclusión, el equipo optó por utilizar los modelos como capa de acceso a datos y aprovechó el uso de Eloquent ORM [54]. Dicho todo esto, el equipo no dio por sentado que el front-end deba instalarse de forma independiente o incluso tener su propio repositorio. Dicho esto, conociendo estos datos, el equipo decidió mantener la lógica lo más simple posible.
Vistas de Componentes y Conectores
- Componente Google Fit
Otro punto importante es que el backend utilizó un paquete de composición que facilitaba la interacción con Google a través de un cliente escrito en PHP. El único servicio utilizado y, por tanto, registrado en Composer.json es Fitness. Como puede ver en el diagrama, la primera vez que un usuario intenta acceder a sus datos de GoogleFit, se le pide que acepte que la aplicación web acceda a cierta información de su cuenta.
Esta conexión a la pantalla de Google OAuth se crea en el backend desde el punto final /api/googleFit/login cuando el frontend detecta que el usuario aún no ha otorgado permisos o que han expirado. Con esta información, el frontend solicita datos correspondientes al usuario que utiliza las credenciales. Algo destacable en cuanto a seguridad y modificabilidad es que todo lo relacionado con GoogleFit se realiza en segundo plano.
Vistas de asignación e infraestructura
- Diagrama de despliegue en AWS
- Elección de servicios y despliegues
- Proyecto en Google Cloud: Google Fit
- Despliegue
- Desarrollo local
El proveedor de nube elegido por el equipo es AWS; la justificación de su elección se puede encontrar en 5.2.4. Además, el equipo conoce los servicios de Firebase y AWS Amplify, de ahí esta opción. Al crear un entorno en ElasticBeanstalk, el equipo creó un equilibrador de carga de aplicaciones [82], que distribuye la carga bajo demanda entre servidores EC2 [83] administrados directamente por EB.
Sin embargo, el equipo utilizó CloudFront con un doble propósito (rendimiento y seguridad) para actuar como punto de entrada para la aplicación web [86]. Como puedes ver en la segunda imagen, el dispositivo redirige fácilmente el tráfico, gracias a los registros A, al servicio correspondiente ya sea en CloudFront o en el balanceador de carga. Básicamente, el equipo creó un proyecto en la consola de Google Cloud y habilitó la API "fitness" para poder utilizarlo.
Atributos de calidad
- Modificabilidad
- Usabilidad
- Seguridad
- Performance
- Disponibilidad
- Portabilidad
- Testeabilidad
- Observabilidad
Como puede ver, el equipo ha mantenido archivos de configuración para hacer referencia a variables de entorno. En la imagen inferior podéis ver esta interfaz gráfica del navegador Google Chrome. Como se puede observar en el gráfico de distribución de duración (izquierda), ninguna variable (cualquier transacción) supera los 500 ms.
Puede ver los detalles de esta lógica en la Ilustración 71: Limitación de velocidad por ID de usuario o IP. El motivo por el cual no se guardan los datos de Google Fit se puede ver en el punto 5.6.3. En la imagen puede ver algunas de las métricas seleccionadas que el equipo encontró más útiles en un panel personalizado.
Gestión del proyecto
- Roles
- Cronograma
- Análisis del esfuerzo
- Fase de estructuración del proyecto
- Métricas
- Fase de desarrollo
- Roles de Scrum
- Artefactos
- Eventos
Finalmente, se pudo alcanzar el objetivo: el equipo dedicó el 63,1% a la fase de desarrollo en su conjunto (el 52% del tiempo total del proyecto está solo en desarrollo). El equipo realizó un análisis del esfuerzo durante esta fase de estructuración del proyecto, que se presenta a continuación con sus conclusiones. Fue creado durante la fase de estructuración del proyecto, en una instancia a la que el equipo se refiere como sprint cero.
Estos son los criterios acordados por el equipo Scrum para determinar cuándo un elemento del backlog se considera completo [120]. A cambio, se realizaron reuniones semanales entre el equipo de desarrollo en formato virtual. Por lo general participa el equipo de desarrollo, con el scrum master y el product propietario, pero i.
