Ahorranza

App Store: plataforma de descarga de aplicaciones móviles o apps desde dispositivos con sistemas operativos iOS y Mac OS de la empresa Apple [6]. Punto de la historia: son una medida relativa para expresar una estimación asignada en función de la complejidad de la tarea, el riesgo o la falta de certeza sobre una tarea [46].

Introducción

• Objetivos
• Objetivos del producto
• Objetivos del proyecto
• Objetivos académicos
• Objetivos del proceso
• Entorno conceptual de Software Factory
• Descripción del equipo
• Estructura del documento

OPROY3 - Obtener un porcentaje de satisfacción superior al 75% de los usuarios en la encuesta de satisfacción final. Este es el principal desafío del trabajo y es uno de los logros que el equipo intentará alcanzar.

Problema

Contexto del problema

En relación con ellos, y especialmente la disminución del gasto y los cambios en la forma de gestionar las finanzas; Los expertos del Bank of America coinciden en que la clave para ahorrar es, primero, saber cuánto dinero gasta y, lo más importante, en qué categorías o áreas lo gasta [55]. Esta intervención manual consume mucho tiempo y dificulta mantener la coherencia en el uso de estas aplicaciones, lo que a su vez lleva a la percepción de que el esfuerzo invertido no produce resultados satisfactorios.

Tipos de usuarios y necesidades

Con base en esto, se decidió profundizar en los factores endógenos que se pueden controlar hasta cierto punto. Varios estudios han investigado las razones detrás de esta situación y concluyeron que se debe principalmente a la necesidad de intervenir manualmente para registrar los gastos, así como para asignar categorías o partidas a las transacciones [56].

Situación actual

Solución

• Descripción funcional del producto
• Mobile app
• Web app
• Landing page

A medida que el usuario registre las transacciones, aparecerán en la pantalla de inicio. En primer lugar, el usuario selecciona un objetivo de ahorro (por ejemplo el 10% de sus ingresos) y proporciona datos personales, información sobre su hogar y unidad familiar.

Emprendimiento

• Inicios del proyecto
• Creación del emprendimiento
• Marca y marketing
• Modelo de negocio

Dado que esta idea requería un mayor nivel de desarrollo técnico y una mayor complejidad en la gestión de la información financiera, el equipo consideró que sería más interesante abordar este desafío. Por esta razón y luego del análisis, que se puede ver en el Apéndice 4 - Elección de un nombre, se estimó que “Ahorro” es el más adecuado para el emprendimiento.

Marco metodológico

• Características del proyecto
• Características del equipo
• Roles
• Metodología de trabajo
• Ciclo de vida
• Metodología aplicada

Los detalles de su uso se explican en el apartado 10.1 - Identificación de elementos de configuración. Participaría el equipo de desarrollo y Santiago, quien orquestaría la reunión en el rol de Scrum Master.

Ingeniería de requerimientos

Proceso

• Fases del proceso

Inicialmente, la satisfacción de los miembros con el uso de cada uno estaba relacionada en gran medida con su simplicidad, intuición y funcionalidad. Análisis de foros donde se discute el manejo de la contabilidad y las finanzas. Otra característica que buscó facilitar el trabajo de los usuarios en el registro de sus gastos fue a través de la conexión con los bancos.

Puede ver el resultado en el apéndice 13: Comentarios de la demostración de OCR.

Funcionalidades

Finalmente, al final de la pantalla de resultados, este experimento incluiría una redirección a un Formulario de Google donde los usuarios podrían dejar sus opiniones, comentarios, mejoras que podrían realizar o errores identificados. Al establecer límites de gasto y monitorear el progreso de sus presupuestos, los usuarios pueden tomar decisiones informadas y evitar gastos excesivos que podrían afectar su estabilidad financiera a largo plazo. Con esta conexión, los usuarios pueden agregar gastos fácilmente a través de esta conexión y vincularlos a las distintas billeteras existentes.

Permitiría a los usuarios compartir ciertos gastos, ingresar nuevos en este core y poder ver sus reportes en billeteras compartidas.

Requerimientos no funcionales

• Portabilidad
• Usabilidad
• Performance
• Adecuación Funcional
• Mantenibilidad
• Escalabilidad
• Testeabilidad
• Observabilidad
• Seguridad
• Disponibilidad

Si el sistema no es escalable, puede resultar difícil o incluso imposible manejar un aumento en la demanda del mercado sin experimentar una disminución en la capacidad de respuesta o incluso una falla total del sistema. El sistema debe poder escalarse automáticamente para manejar aumentos en la carga de trabajo sin experimentar una disminución en la velocidad o la capacidad de respuesta. El sistema debe ser capaz de identificar errores que ocurren mientras los usuarios lo utilizan.

El sistema deberá disponer de mecanismos de identificación de usuarios, autenticación y control de acceso que permitan proteger los datos y recursos del sistema.

Restricciones

Arquitectura y diseño

Elección de tecnologías

• Factores del contexto
• Mobile app
• Web app
• Backend principal
• Escaneo de tickets de compra
• Categorizador de gastos
• Base de datos

Como mencionamos en la comparación anterior, el desarrollo móvil multiplataforma brinda acceso a los recursos del dispositivo (incluidas la cámara y las notificaciones automáticas) que son esenciales para desarrollar una solución. Se consideraron diferentes métricas para analizar el apoyo de la comunidad a cada una de las herramientas. Al igual que ocurre con la elección de la tecnología para el desarrollo móvil, este aspecto también es de fundamental importancia, ya que afecta directamente a la usabilidad del sistema.

Para analizar el rendimiento de cada opción se tuvo en cuenta un informe de Stefan Krause [96], en el que se comparan diferentes frameworks en función del tiempo en milisegundos que cada uno tarda en realizar determinadas acciones.

Desafíos tecnológicos

• Utilización de OCR para el escaneo de tickets
• Utilización de un modelo de machine learning para clasificar productos
• Generación de recomendaciones de ahorro
• Categorización de transacciones a partir de estados de cuenta bancarios

A partir de la primera lectura exitosa, se realiza un seguimiento de los resultados de las lecturas posteriores y el reconocimiento continúa a medida que mejora la puntuación. Una vez entrenado el modelo, se guarda en un archivo dentro de la solución. A partir de esto, sería posible confirmar el buen desempeño del modelo, obteniendo una tasa de precisión igual al 91% y una tasa de precisión igual al 95%, lo que está de acuerdo con RNF9 - Precisión y exactitud de la categorización de productos.

El 90% de los usuarios que invierten más de la mitad de sus ingresos en su vivienda no alcanzan sus objetivos de ahorro.

Visión general de la arquitectura

Permite a los usuarios que utilizan cualquiera de los navegadores mencionados en RNF2 - Portabilidad: Aplicación Web realizar diversas acciones detalladas en el apartado 6.2 - Funciones. La aplicación móvil, disponible para iOS y Android, desarrollada en Flutter, permite a los usuarios que cuenten con un dispositivo con las versiones especificadas en RNF1 - Portabilidad: Aplicación Móvil realizar diversas acciones detalladas en la Sección 6.2 - Funcionalidades. Servicio que brinda una manera fácil de registrar y autenticar usuarios a través de diversos proveedores de identidad como correo electrónico, Google, Facebook, Twitter, entre otros.

Las aplicaciones se comunican con él para permitir a los usuarios autenticarse sin necesidad de dos servicios de autenticación diferentes.

Atributos de calidad

• Portabilidad
• Performance
• Mantenibilidad
• Escalabilidad
• Disponibilidad
• Observabilidad
• Seguridad

Uno de los beneficios de utilizar esta biblioteca es que permite definir estilos que se aplican específicamente a cada componente de la aplicación, lo que da como resultado una apariencia visual más consistente, coherente y atractiva para los usuarios. Para lograr esta externalización se utilizaron variables de entorno, las cuales contienen valores específicos para cada entorno en el que se ejecuta el sistema. Otro beneficio de Apiary es que permitió compartir la documentación API con otros miembros del equipo, facilitando la comunicación y la colaboración en el proceso de desarrollo de software.

Según la realidad del proyecto, se espera que la utilización varíe considerablemente durante el día.

Detalle de la arquitectura

• Monolito vs SOA vs Microservicios
• Estructura del backend
• Estructura de la base de datos

Como se puede observar en la ilustración anterior, cada uno de los módulos tiene cuatro capas, las cuales se describen a continuación. Para la estructura de la base de datos, el equipo administró las entidades que se muestran en la siguiente ilustración. Categoría Representa las categorías de gastos o ingresos que se pueden ingresar al sistema.

Cada uno de ellos está asociado a una categoría específica, que se utiliza para categorizar las transacciones obtenidas al cargar un archivo de extracto bancario.

Infraestructura

• Despliegue del backend
• Despliegue de la web app
• Despliegue de la mobile app
• Dominios adquiridos

Para cumplir con los requisitos de seguridad, el acceso a la base de datos está configurado para que sea posible solo desde una aplicación interna dentro de la organización, es decir, el backend. Con referencia al despliegue de la aplicación web, se analizaron varias alternativas para llevar a cabo su implementación. En cuanto al factor costo, se constató que AWS brindó cobertura suficiente para implementar la aplicación web, gracias a los créditos otorgados por el presidente.

Para implementar la aplicación móvil se utilizaron diferentes estrategias dependiendo de la plataforma a implementar.

Gestión del proyecto

Cronograma

El primero de ellos, para la codificación hasta el primer MVP inclusive, en el que trabajaríamos en las características marcadas para esta entrega inicial mencionada en la sección 8.3.1 - Plan de lanzamiento, y el segundo, en el que se deberían priorizar. tareas existentes, teniendo también en cuenta los errores encontrados y las nuevas ideas sugeridas por los usuarios. Además, se puede observar que se han agregado diferentes actividades que se consideran claves para el proyecto. En particular, presentar la primera demostración a los usuarios, escanear y categorizar los elementos de un ticket de compra o recopilar comentarios sobre el mismo.

Estas modificaciones se verán a continuación, pero fueron la causa del retraso en algunas fechas propuestas, por ejemplo, la salida a producción de la aplicación, que estaba prevista para octubre y finalizó a principios de enero.

Primera fase: Planificación del proyecto

• Métricas

Segunda fase: Desarrollo hasta el primer MVP

• Plan de releases
• Sprints realizados
• Métricas

Esta actividad nos permitió planificar una gran cantidad de sprints en el futuro con una idea clara de la velocidad del equipo y lo que había que hacer. Esto, como se vio en el apartado anterior, dio lugar al cambio en el calendario de lanzamientos. Además, en la citada prensa seis, el equipo se centró en la segunda revisión académica y el lanzamiento de la primera demostración a los usuarios, escaneando tickets de compra y categorizando gastos para dispositivos Android.

Finalmente, en el sprint diez, puedes ver que la cantidad de puntos de historia completados disminuye debido a problemas que llevaron a la necesidad de tener un undécimo sprint.

Tercera fase: Desarrollo luego del primer MVP y documentación

Si continúa con el proyecto una vez finalizado, este procesamiento se reanudará. Indica cuántas funciones y correcciones de defectos se realizaron antes del lanzamiento de cada versión. El mensaje de error al validar la contraseña en los formularios no coincide con lo que espera el backend.

Tras este resultado, el equipo decidió congelar la función hasta que se entregara la documentación.

Modificaciones al alcance

Sin embargo, la implementación realizada en su momento no fue incluida en la solución final, principalmente por dos razones que se explicarán a continuación. Además, implementar dicha versión, como se especifica en la sección 4.4 - Modelo de Negocio, requiere no sólo un buen incentivo que le agregue valor, sino también suficientes usuarios interesados ​​para justificar su desarrollo. Finalmente, a la vista de los aspectos anteriores, se decidió no incluirlo en la solución final.

Esto se confirmó después de la implementación, los nuevos usuarios que completaron el elonboarding y registraron una billetera en la misma sesión también accedieron a las funciones destacadas al menos una vez antes de cerrar la aplicación.

Gestión de riesgos

• Identificación de riesgos
• Análisis cualitativo
• Monitoreo de los riesgos

Riesgos personales: riesgos relacionados con los factores personales de los miembros del equipo que afectan el proyecto. Un análisis cualitativo de cada uno de los riesgos identificados se puede encontrar en el Anexo 19 – Análisis cualitativo de cada riesgo. Desde el principio, tanto el impacto como la probabilidad fueron altos, ya que se desarrollaron funcionalidades cuyo interés por parte de los usuarios no estaba garantizado.

Al recopilar comentarios de los usuarios después de este lanzamiento, el impacto y la probabilidad disminuyeron.

Gestión de la comunicación