BIN (Número de Identificación Bancaria): Número de identificación bancaria, estos son los primeros 6 dígitos de la tarjeta de crédito. IIN: Número de identificación del emisor, estos son los primeros 6 dígitos de la tarjeta de crédito.
Índice
Introducción
- Presentación del equipo
- Selección del proyecto
- Objetivos
- Producto
- Equipo
- Académicos
- Emprendimiento a futuro
- Descripción de los interesados
- Usuarios finales
- Organizadores de eventos
- Medios de pagos
- Estructura del documento
- Descripción del problema y la solución
- Marco metodológico
- Ingeniería de requerimientos
- Arquitectura
- Medios de pago
- Desarrollo
- Gestión del proyecto
- Gestión de calidad
- Usabilidad
- Conclusiones y lecciones aprendidas
- Proyecciones a futuro
Cuenta con un experto en el mercado que también se convirtió en el primer cliente del proyecto y con quien colaboramos en la definición de los objetivos del producto y del proyecto. Se describen detalladamente las técnicas utilizadas y las actividades realizadas en las fases de investigación, especificación y validación de los requisitos.
Descripción del problema y la solución
- El problema y su contexto
- Necesidades del usuario
- Compradores
- Vendedores
- Objetivos de la solución
- Descripción general de la solución
Se define comprador como cualquier cliente usuario de un establecimiento de alimentación y bebidas que realiza un pedido, paga y recoge productos directamente en el establecimiento. El público objetivo inicial son los eventos de food trucks, donde contará con el apoyo de Joaquín Pastorino, referente en el mercado de este tipo de eventos y uno de los pioneros.
Marco metodológico
- Características del proyecto
- Selección y definición del ciclo de vida del proyecto
- Metodología de referencia
- Roles
- Elementos y ceremonias
- Proceso de desarrollo
- Conclusiones
Además, se planificaron las historias de usuario a implementar y las tareas del proyecto a realizar en dicha iteración y estas tareas se asignaron a cada miembro del equipo. Para ver cada una de las tarjetas de las historias de usuario, vaya al Apéndice 4.
Ingeniería de requerimientos
- Relevamiento
- Encuestas
- Entrevistas
- Brainstorming
- Observación
- Benchmarking
- Especificación de requerimientos
- Requerimientos funcionales
- Requerimientos no funcionales
- Validación
- Validación presencial con usuarios y cliente
- Redes sociales
- Producto
- Conclusiones
Se destaca la importancia de la seguridad de los medios de pago y el almacenamiento de los datos de las tarjetas de crédito introducidos por los clientes al realizar el pago de los pedidos. Consulte el Apéndice 10 para ver imágenes del prototipo de la aplicación móvil del proveedor.
Arquitectura
- Descripción de la arquitectura
- Arquitectura orientada a servicios
- Vista de Despliegue
- Vista de Módulos
- Diseño
- Principios de diseño
- Modelo conceptual
- Atributos de calidad
- Seguridad
- Performance
- Disponibilidad
- Escalabilidad
- Interoperabilidad
- Modificabilidad
- Tecnologías
- Web API REST
- Base de datos
- Aplicaciones Móviles
- Aplicación Web
- Integración con sistemas externos
- Reportes
- Conclusiones
La integración que se realiza con el método de pago para poder realizar pagos a través de la plataforma se describe en el capítulo 6 sobre métodos de pago. Persistencia Este módulo es responsable de conservar todas las entidades de la plataforma en una base de datos. Además, es responsable de la transformación de las entidades definidas en el módulo de dominio en DTO [80].
Luego se presenta otro mostrando diferentes módulos de la API Web REST y su interacción. Garantiza la integridad de la transferencia de datos entre aplicaciones y la API REST web. En el caso de la aplicación web, cuando fue desarrollada en React se utilizaron dos tipos de componentes.
Medios de pago
- Elección de una pasarela de pago
- Integración de la pasarela de pagos
- Flujo de pago
- Decisiones tomadas
- Distribución del dinero
- Conclusiones
- Mejoras a futuro
7 - Si el vendedor acepta el pedido, se envía una solicitud al servidor de DePaso para que pueda realizar un pago en Mercado Pago utilizando los datos que guardó previamente. Además, la clave privada se determina transfiriendo el dinero a la cuenta DePaso dentro de Mercado Pago. El identificador de la tarjeta dentro de Mercado Pago y el CVV se envían al servidor junto con la orden para obtener un nuevo token temporal para realizar el pago.
5 - El servidor envía a Mercado Pago el identificador de la tarjeta almacenada (que fue elegida por el usuario) y el CVV. 6 - Mercado Pago valida los datos, es decir, que el CVV corresponde y que existe la identificación de la tarjeta. Además, se especifica la clave privada para que el dinero sea depositado en la cuenta DePaso en Mercado Pago.
Desarrollo
- Capacitación
- Estrategia de desarrollo
- Conclusiones
El número total de horas dedicadas al desarrollo de diversas aplicaciones fue de aproximadamente 1126 horas. Por otro lado, la aplicación del vendedor, aunque también implementada con Xamarin, fue creada después de la creación de la aplicación del comprador, por lo que hubo experiencias durante la creación por parte de los desarrolladores encargados de dichas aplicaciones. El 46% de las horas dedicadas al back office corresponden a la implementación de la integración con un servicio externo de los medios de pago.
El resto de las horas se dedicaron al desarrollo de otras funciones ofrecidas para las aplicaciones web y móviles. Florencia lideró el desarrollo de las aplicaciones móviles, mientras que Martín lideró el desarrollo de la aplicación web y la API Web REST y realizó el despliegue de las aplicaciones en Azure y Heroku. Finalmente mencionar que se dedicaron 93 horas de desarrollo a retrabajo (mejoras y defectos), lo que representa el 8,3% del total de horas de desarrollo.
Gestión del proyecto
- Gestión del alcance
- Definición del alcance
- Plan de release
- Gestión del esfuerzo
- Herramienta utilizada
- Métricas de esfuerzo
- Gestión de riesgos
- Identificación
Al inicio del proyecto se barajaron dos opciones: utilizar la herramienta Toggl o registrar las horas en una hoja de cálculo de Google Sheets. Como se puede observar en este gráfico, los periodos de mayor esfuerzo para la mayoría de zonas fueron en los meses de junio a octubre y desde diciembre hasta el final del proyecto en el mes de febrero. El área donde mayor esfuerzo se está realizando durante gran parte del proyecto es el desarrollo.
Esto se refleja en el cambio en los valores de riesgo 'Incumplimiento de los puntos de la historia al final del proyecto' y 'Esfuerzo', que se describen en la sección de riesgos a continuación. 134 El gráfico sólo muestra la distribución de horas dedicadas a la documentación final del proyecto. Como se mencionó en el Capítulo 7 sobre desarrollo, debido a su rol, Agustina dedicó más horas a tareas relacionadas con la gestión de proyectos, incluyendo horas a documentación, lo cual se refleja en el gráfico anterior.
Valor inicial
- Actividades preventivas
- Integración con medios de pago
- Sale una nueva aplicación similar al mercado
- Que los referentes de mercado se desvinculen del proyecto
- Conocimiento de tecnologías
- Usabilidad
- Seguridad
- Mala estimación
- No cumplir con los story points al finalizar el proyecto
- Conectividad de usuarios
- Seguimiento y evolución
- Ejecución de iteraciones (hitos del proyecto)
- Gestión de la comunicación
Este riesgo fue difícil de prevenir ya que el equipo no pudo hacer mucho al respecto. Disminuyó a través de las iteraciones, ya que el equipo tomó varias acciones para mitigarlo. Por lo tanto, el equipo decidió utilizar una herramienta recomendada por colegas de la Universidad que ya habían completado el proyecto de grado y la encontraron útil.
En las iteraciones, el equipo tuvo la misma cantidad de horas disponibles que en otra iteración. Además, el esfuerzo realizado por el equipo no se mantuvo constante durante todo el proyecto como sugiere Scrum. Esto se debe a que la complejidad de las historias de los usuarios no solo afecta la productividad, sino que el esfuerzo también se refleja en la cantidad de puntos de la historia que el equipo logra completar.
Slack
Además, el equipo creó otro grupo de WhatsApp con el supervisor para mantener una comunicación fluida y así coordinar las distintas reuniones a lo largo del proyecto y resolver dudas rápidamente. La comunicación personal se mantuvo con Joaquín Pastorino vía WhatsApp, siendo Agustina la encargada de comunicarse con él a través de mensajes privados en lugar de utilizar un grupo ya que el equipo no lo consideró necesario. El equipo creó un correo electrónico en Gmail [149] ([email protected]) para comunicarse oficialmente con los interesados y usuarios finales, tanto compradores como vendedores.
Gmail es un servidor de correo electrónico que tiene un almacenamiento excelente y también puede conectarse fácil y automáticamente a Google Drive, donde el equipo almacena todos los documentos del proyecto, a diferencia de Hotmail, un servidor que el equipo no suele utilizar de forma rutinaria. . Fue muy útil ya que tener un correo electrónico que representa al equipo y al que todos los miembros tienen acceso da una imagen de unidad y profesionalismo a todas las partes interesadas del proyecto con las que el equipo contactó. Fue a través de este correo electrónico que el equipo se comunicó y compartió archivos con el tutor como se mencionó anteriormente.
Skype
Conclusiones
El equipo considera que la gestión del alcance fue correcta, ya que se pudieron implementar 430 puntos de los 514, es decir, el 83,7% de los requisitos. Las herramientas elegidas para la gestión del tiempo y la comunicación eran apropiadas y el equipo las utilizaría nuevamente en proyectos futuros. Un aspecto a mejorar podría ser estimar, además de los requisitos funcionales, otras actividades de gestión de proyectos con story points, como las actividades de generación de documentos a lo largo del proyecto.
El equipo consideró que al medir la velocidad de este proyecto, la forma de definir cuándo está completa una historia de usuario no era la mejor. Por lo tanto, los proyectos futuros podrían considerar cambiar los criterios de finalización de la historia del usuario, como dividir los puntos de la historia en desarrollo frontal y posterior y medir su progreso parcial simultáneamente. repetición, al menos para medir la velocidad. Finalmente, se considera que se debe organizar mejor la disponibilidad del equipo de trabajo para que el esfuerzo de todos los miembros sea constante durante todo el proyecto, mejorando así la productividad y logrando una velocidad más pareja.
Gestión de calidad
- Objetivos de calidad
- De Proceso
- De Producto
- Académicos
- Plan de calidad
- Aseguramiento de la calidad
- Aplicación de estándares
- Pruebas de software
- Gestión de incidentes
- Revisiones
- Validación
- Gestión de la configuración
- Identificación de los elementos de configuración
- Elección de las herramientas y organización
- Métricas
- De Proceso
- De Producto
- Conclusiones
Para probar la aplicación móvil del proveedor se utilizó el emulador de Android, que incluye Microsoft Visual Studio, que permite la creación de diversos dispositivos. Un ejemplo de esto fue el tamaño de las tiendas cuando aparecen en la pantalla principal de la aplicación de compras. En el caso de los vendedores, las pruebas se realizaron con el internet inalámbrico proporcionado por Joaquín Pastorino en el evento Garage Gourmet para los vendedores participantes del evento.
Durante la ejecución del proyecto se registraron un total de 83 incidencias, de las cuales 39 fueron defectos y 44 mejoras. La herramienta utilizada para la gestión documental durante todo el proyecto fue Google Drive. De esta forma se podría medir y verificar el cumplimiento de los objetivos de calidad establecidos.
Usabilidad
- Investigación
- Taller de usabilidad
- Curso relacionado a la usabilidad
- Benchmarking
- Análisis Heurístico
- Metodología
- Resultados
- Pruebas con usuarios
- Procedimiento
- Resultados
- Oportunidades de mejora
Visibilidad del estado del sistema: cuando un vendedor rechazaba un pedido, se le eliminaba de la lista de pedidos pendientes, pero no se le notificaba que la acción se había realizado correctamente. Tuvo que intentar ingresar la fecha de vencimiento nuevamente porque el formato lo confundía. Tanto el formato de la fecha de vencimiento de la tarjeta de crédito como el formato del DNI no son comprensibles para los usuarios, lo que genera dudas al ingresar.
En los pedidos encontrados sería útil incluir el tiempo de recepción además del tiempo de entrega ya mostrado. Tanto el formato de la fecha de caducidad de una tarjeta de crédito como el del documento de identidad no son comprensibles para los usuarios, generando dudas a la hora de introducirlos. Los pedidos que están listos para ser recogidos no destacan del resto de pedidos pendientes, por lo que lleva tiempo visualizarlos.
![Ilustración 17: Diagrama de secuencia [83] de los elementos de la plataforma](https://thumb-us.123doks.com/thumbv2/123dok_es/12399162.0/79.892.111.775.452.721/ilustración-17-diagrama-secuencia-83-elementos-plataforma.webp)
