Random House App: Plataforma integral para la gestión de bares

Backend: Es la parte del desarrollo web que se encarga de hacer funcionar toda la lógica de un sistema. Revisión de código: examen sistemático realizado del código fuente de un programa de computadora.

Introducción

Descripción del proyecto

Objetivos

• Objetivos académicos
• Objetivos del equipo
• Objetivos del producto

Los objetivos del equipo están alineados con los objetivos académicos ya que se propone trabajar en equipo y al mismo tiempo utilizar metodologías de trabajo. Ya que una buena experiencia invita a los usuarios a repetir su uso y quedar satisfechos con la barra.

Problema actual

Nuestro cliente

Contexto

En todos los casos, el cliente deberá abonar el importe solicitado en el momento de la compra. Una vez que hayas realizado tu pedido, deberás esperar en la mesa en la que te encuentres, y cuando esté hecho, el camarero lo tomará.

El problema

Dependiendo del día y la cantidad de empleados que tengan, generalmente tienen entre 5 y 7 empleados trabajando en el flujo de recepción y creación de pedidos. Además de los problemas anteriores, existe poca información sobre los clientes, lo que hace que muchas de las decisiones que se toman no se basen en datos.

Desafíos del proyecto

• Desafíos de gestión
• Desafíos del equipo
• Desafíos tecnológicos
• Desafíos del producto
• Desafíos del contexto actual

Entre los desafíos del producto, según el equipo, el más importante fue una comprensión completa del producto y sus usuarios. El resultado de la correcta implementación del proyecto es la adaptación y familiarización de los clientes al nuevo proceso.

Interesados

Solución

• Esquema general del sistema
• Terminal autoservicio
• Aplicación mobile para clientes
• Web de toma de comandas en caja
• Terminal de recepción de comandas para cocina
• Backoffice web
• Usuarios del sistema

De esta forma, cuando el usuario quiera pagar sus pedidos del día, el responsable de su recogida podrá confirmar los pedidos. Aquí se muestra una lista de todos los productos del menú y de forma sencilla el usuario puede ver, editar o eliminar un producto.

Enfoque de trabajo

• Características del proyecto
• Características del equipo
• Ciclo de vida
• Justificación de elección
• Fases del ciclo de vida
• Procesos de Gestión 1. Metodologías de trabajo
• Aplicación de Scrum

Teniendo en cuenta las características antes mencionadas, el equipo optó por utilizar un ciclo de vida iterativo e incremental. Aquí el equipo se reúne para analizar qué funciona y qué no.

Ingeniería de requerimientos

• Introducción
• Proceso
• Metodología de trabajo
• Extracción y análisis de requerimientos
• Especificación
• Validación
• Actores
• Requerimientos Funcionales
• Requerimientos No Funcionales

El equipo determinó la información necesaria a la que se debe prestar especial atención en el momento de la observación. Aquí puedes ver algunas de las sugerencias más importantes obtenidas tras cada encuentro con los usuarios. La siguiente sección presenta diversas actividades realizadas para validar los requisitos identificados en el proceso de ingeniería de requisitos.

Cajero: Empleado que está en la caja tomando nuevos pedidos de los clientes.

Arquitectura

Descripción General

Diagrama de Contexto

Descripción de la arquitectura

Por la misma razón, una arquitectura monolítica es más eficiente ya que la comunicación y recuperación de información es más rápida, favoreciendo así la usabilidad del sistema.

Diagrama de componentes y conectores

• Catálogo de Componentes

Esta aplicación fue desarrollada en Rails y desde ella tienes control sobre los diferentes elementos que aparecen tanto en la aplicación móvil como en el terminal de autoservicio. Para que el cajero pueda utilizar el mismo sistema que el terminal de autoservicio y la aplicación móvil, se desarrolló una aplicación web en Flutter con el mismo flujo que el terminal y la aplicación, para que pudieran tener todos los pedidos. combinados en un solo sistema. Es un servicio que se utiliza para enviar notificaciones push a la aplicación móvil y también como servicio de alojamiento de la aplicación para la versión respectiva.

Servicio utilizado para manejar todos los pagos que no sean en efectivo dentro de la plataforma.

Diagrama de deploy

Elección de tecnologías

• Criterios de selección de tecnologías
• Análisis de tecnología móvil a utilizar
• Análisis de tecnología backend a utilizar
• Aplicación Web
• Hosting

Las razones por las que se eligió la tecnología para el desarrollo de aplicaciones móviles se detallan a continuación. Inicialmente, el equipo consideró tres opciones posibles para desarrollar la aplicación móvil. La principal funcionalidad de la aplicación web es funcionar como un sistema administrativo para el manejo de los distintos modelos que se manejan en el sistema.

Además de la aplicación web antes mencionada, se desarrolló otra para la toma de pedidos del cajero, la misma fue desarrollada en Flutter ya que, al ser un terminal de autoservicio y aplicación móvil, se realiza el flujo de realización de un pedido.

Principales atributos de calidad

• Usabilidad
• Modificabilidad
• Seguridad
• Performance
• Interoperabilidad
• Portabilidad
• Disponibilidad

Por tanto, la usabilidad dentro de la aplicación es clave para que los usuarios puedan tener la mejor experiencia posible. Al mismo tiempo, para promover la accesibilidad de la aplicación, se utilizó la herramienta WAVE [54]. RNF9: Los usuarios deben tener roles para acceder a las diferentes partes de la aplicación.

Ya sea para la aplicación web de administración, el uso de aplicaciones móviles o.

Desarrollo

Características del equipo de desarrollo

Estrategias de desarrollo

Gestión de proyecto

Gestión de alcance

• Definición de alcance
• Plan de release

11 de enero - 4 de abril: se desarrolló el primer MVP para esta versión para que el cliente tuviera un sistema para probar y dar comentarios. 5 de abril - 13 de junio: Trabajamos en la primera versión y agregamos nuevas solicitudes que recibimos de nuestros clientes y usuarios que probaron el sistema. 14 de junio - 8 de agosto: Se trabajó nuevamente para aumentar la versión anterior, agregar nuevos requisitos identificados y completar los planificados originalmente.

Estrategia de gestión

Para gestionar el alcance, el equipo decidió dividir el proyecto en tres versiones, esta cantidad se determinó en función de los requisitos que cubriría cada versión. Puedes ver las funciones previstas para cada uno de ellos en detalle en el Apéndice 12.8. Como puedes ver, el proyecto comenzó con un sprint 0 cuyo objetivo era recopilar requisitos y aprender lo máximo posible sobre el producto a fabricar y las tecnologías a utilizar.

Después del sprint 0, se decidió que el proyecto constaría de tres lanzamientos, el primero de los cuales alcanzaría un MVP, que serviría para ser validado.

Gestión del desarrollo

Trabajo de cada sprint

En el front end se desarrolló la pantalla de registro, restablecimiento de contraseña y sus conexiones con el backend. En el backend, se utiliza el marco Active Admin y se adapta para que el registro y el inicio de sesión funcionen. Se continúa trabajando en el desarrollo del carrito, añadiendo la funcionalidad de poder cambiar las cantidades del producto añadido y la posibilidad de eliminarlo.

Todo el proyecto se pone en producción para su uso en el bar.

Gestión de riesgos 1. Identificación de riesgos

• Asignación de prioridad
• Comportamiento de los riesgos
• Materialización de riesgos

Como se puede observar en el gráfico, el riesgo de que los miembros del equipo tuvieran problemas a la hora de aprender la tecnología era alto inicialmente, y esto se debe a que la mayoría no conocía la tecnología y por tanto tenía más posibilidades de tener problemas de aprendizaje. Como se puede observar, el riesgo de que la disponibilidad de los equipos se vea afectada es bastante variable. Como se puede observar en el gráfico, el riesgo de no conocer el dominio del producto era inicialmente alto, ya que ninguno de los miembros del equipo había trabajado con nada relacionado con el ámbito gastronómico, por lo que no lo sabíamos.

Disponibilidad del equipo Incrementar las horas de trabajo del resto de miembros para alcanzar los objetivos marcados.

Métricas de gestión 1. Burndown chart

• Velocidad por sprint
• Desvío por sprint
• Distribución del esfuerzo por área de trabajo

Como se puede observar en la gráfica el equipo tuvo variaciones de velocidad a lo largo del proyecto, la mayor razón de las variaciones de velocidad del equipo fueron las evaluaciones (tanto parciales como exámenes) que tuvieron los integrantes a lo largo del semestre. Por tanto, se puede ver reflejado en los sprints 3, 4 y 5 que el equipo iba por detrás. En el sprint número 6 y el sprint final de la liberación, se puede observar cómo el equipo aceleró y compensó la desviación anterior.

En el último sprint del último lanzamiento se puede ver como el equipo vuelve a acelerar y se aumenta mucho la velocidad para llegar al lanzamiento con los requisitos inicialmente acordados.

Herramientas de apoyo para la gestión 1. Gestión y comunicación

• Gestión de versionado
• Desarrollo

Esta herramienta se utilizó para reuniones virtuales con el tutor y expertos. Esta herramienta se utilizó como un SCM donde se crearon dos repositorios, uno para el backend y otro para el frontend. Esta herramienta se ha utilizado para la creación de prototipos, de modo que pueda mostrar el flujo al cliente para discutirlo.

Esta herramienta se utilizó para acceder a la base de datos y visualizar las tablas y datos de una manera sencilla, lo cual es muy conveniente durante el desarrollo.

Gestión de calidad

• Objetivos de calidad
• Plan de Calidad
• Aseguramiento de calidad
• Satisfacción del cliente
• Gestión de incidentes
• Métricas
• Métricas del proceso
• Métricas del producto
• Piloto

A su vez, el equipo siguió varios de los estándares descritos en el libro Clean Code de Robert C. El equipo decidió que el backend y el frontend de la aplicación estarían cada uno en un repositorio separado. Por último, pero no menos importante, el equipo tuvo una revisión con Amalia Álvarez para revisar las actividades realizadas para asegurar la calidad del proyecto.

De esta manera, el equipo podría ajustar el proceso a lo largo del proyecto para lograr sus objetivos.

Gestión de la configuración

• Elementos de configuración
• Herramientas para el control de versiones 1. Software
• Documentación
• Repositorios
• Software
• Workflow
• Documentación
• Gestión de cambios
• Gestión de ambientes

Toda la documentación del proyecto se almacenó en carpetas de Google Drive compartidas entre los miembros del equipo. Si estos cambios no se gestionan adecuadamente, pueden surgir problemas en la forma de trabajar del equipo. El product propietario debe evaluar con el resto del equipo si se debe realizar el cambio o no.

Una vez que todo esté listo, un miembro del equipo puede pasar la aplicación de la fase de prueba a la producción.

Conclusiones y lecciones aprendidas

• Estado actual
• Lecciones aprendidas 1. Gestión de proyecto
• Puesta en producción
• Enfoque de trabajo
• Ingeniería de requerimientos
• Arquitectura y tecnologías
• Gestión de calidad
• Conclusiones
• Conclusiones sobre los objetivos académicos
• Conclusiones sobre los objetivos del equipo
• Conclusiones sobre los objetivos del producto
• Conclusiones personales
• Próximos pasos

Esto se debe a que el equipo encontró una herramienta más completa para las necesidades requeridas, por lo que se decidió utilizar Jira como reemplazo. Esta era un área en la que por primera vez el equipo sería 100% responsable. Este objetivo era muy importante para el equipo ya que se trataba de aplicar lo que aprendimos en la competencia a un equipo que creamos y administramos.

A partir de las pruebas realizadas con los usuarios y de los comentarios recibidos, el equipo pudo concluir que este objetivo se podía lograr con éxito, lo cual es influyente.

Anexos

Informes de revisiones 1. Informe de revisión 1

• Informe de revisión 2
• Informe de revisión 3

Cerrar el círculo entre los atributos de calidad y el plan de calidad junto con el plan de aseguramiento de la calidad. Presentamos una demostración representativa del sistema que ayudó a comprender el alcance y la dificultad de nuestra solución.

Informe de avance

ORTsf Informe de Avance del Proyecto

Objetivo

Alcance

• Descripción del proyecto
• Carrera e integrantes del equipo Carrera: Ingeniería en sistemas
• Situación actual del proyecto
• Trabajo restante hasta el final
• Proyección hasta el final del proyecto
• Encuestas

Por otro lado, se aportará valor a los clientes mediante el desarrollo de una aplicación móvil que tiene como objetivo fidelizar a los clientes, mejorando su experiencia en el bar. A través de la aplicación, el usuario tiene la opción de realizar múltiples pedidos durante su estancia en el bar y luego pagar el total al final. El cliente solicita su pedido a través de la app, ingresa el número de mesa donde se encuentra y decide si realiza varios pedidos para luego pagar, o paga directamente.

Tiene lógica en el backend y comunicación con la aplicación móvil, pero el desarrollo de la pantalla en la aplicación móvil se desarrolla con controles básicos.