• No se han encontrado resultados

Plataforma de gestión y seguimiento de conversiones offline

N/A
N/A
Protected

Academic year: 2023

Share "Plataforma de gestión y seguimiento de conversiones offline"

Copied!
295
0
0

Texto completo

Conversión offline: “La realización fuera de la web, por parte de un usuario o cliente potencial, de una determinada acción que hemos definido” [5]. Retorno de la Inversión: “ROI (Return on Investment) es el valor económico generado como resultado de la realización de diferentes actividades de marketing.

Introducción

  • Descripción del cliente
  • Descripción del equipo
  • Objetivos
    • Objetivos académicos
    • Objetivos del producto
    • Objetivos del proyecto
  • Nombre, slogan y logo
  • Estructura del documento

Luego de elegir el nombre, el equipo se reunió con miembros del departamento de marketing de Conecta361 para validar el nombre y la búsqueda. Este capítulo describe el proceso que utiliza el equipo para investigar, analizar e investigar los requisitos funcionales y no funcionales del sistema.

Introducción al Marketing Digital

  • Marketing Tradicional vs Marketing Digital
  • Estrategias más utilizadas
  • Importancia del Marketing Digital
  • Administradores de anuncios
    • Facebook Ads
    • Google Ads
  • Resumen

Una de las más utilizadas en la actualidad es el llamado marketing en redes sociales [23]. El crecimiento de las inversiones en publicidad digital ha aumentado considerablemente en la última década, principalmente debido al surgimiento de las redes sociales.

Contexto, problema y solución

  • Contexto
  • El problema
    • Necesidades del cliente
  • Solución
    • Actores
  • Resumen

Muchos de los clientes de Conecta361 enfrentaron el mismo problema que la empresa de automóviles. Por un lado, muchos de sus clientes no sabían cómo extraer sus ventas y, si lo sabían, no almacenaban todos los datos de la misma forma.

Marco metodológico

  • Características del proyecto
  • Roles
  • Relación con el cliente
  • Metodología y ciclo de vida
  • Fases del proyecto
    • Fase de investigación
    • Fase de desarrollo
    • Fase de documentación
  • Herramientas utilizadas
  • Resumen

El equipo buscó mantener una relación cercana con el cliente para alinear las expectativas del producto. Debido a las características del proyecto ya mencionadas en el punto 4.1, el equipo decidió utilizar un ciclo de vida incremental e iterativo [33].

Ingeniería de requerimientos

  • Proceso
    • Investigación
    • Técnicas de relevamiento de requerimientos
  • Listado de requerimientos
  • Requerimientos Funcionales
    • Aplicación Web
    • API
    • SDK
  • Requerimientos No Funcionales
    • Principales atributos de calidad
    • Otros atributos de calidad
  • Restricciones

El sistema debe permitir a los administradores habilitar, deshabilitar y configurar fuentes de datos para iniciar el procesamiento de ventas. El sistema debería permitirle ver el detalle completo del perfil del comprador de un evento. El sistema debe permitir la visualización de estadísticas relacionadas con el desempeño de las campañas de los clientes de Conecta361.

Se debe exponer una API que permita a los clientes de Conecta361 integrarse directamente con el sistema de la aplicación. Se debe proporcionar un SDK que permita a los clientes de Conecta361 integrarse directamente con el sistema de la aplicación.

Arquitectura y desarrollo

Requerimientos de arquitectura

Los datos de los clientes deben recuperarse a través de varias API de terceros, como MercadoPago. Los archivos de datos de los clientes deben poder importarse desde diversas fuentes de datos y CRM. Si los eventos no se procesan debido a la indisponibilidad de uno de los procesadores, se deben reintentar hasta que se procesen sin afectar la salud del sistema.

Los datos almacenados de los clientes sólo deben ser modificados por usuarios autorizados (sistema basado en roles). Cabe señalar que también se tratan aspectos de la calidad del rendimiento y los atributos de usabilidad, pero estos no se destacan entre los más importantes ya que se consideran importantes en cualquier sistema.

Descripción de la arquitectura

  • Interoperabilidad
  • Modificabilidad
  • Disponibilidad
  • Seguridad
  • Testeabilidad
  • Otros atributos de calidad

De esta manera, se ofrece a los clientes la posibilidad de integrarse con el sistema de forma fácil y rápida, con un bajo riesgo de que un cambio en el SDK afecte sus sistemas. 99 A continuación, puede ver README.md como una guía para implementar el SDK en Java. En la siguiente ilustración puedes ver el proceso a través de la plataforma de backoffice.

No es necesario modificar la estructura de la base de datos, como sería necesario en una base de datos relacional. Una vez procesado, el consumidor del evento cambia el valor de la propiedad de retirada de cola a 1, pero sin eliminar el registro dentro de la base de datos no relacional.

Tecnologías

  • Backend
  • Frontend
  • Infraestructura

Para el frontend se buscó un framework que permita desarrollar un SPA, como se menciona en el apartado de desempeño en Otras características de calidad. Por estos motivos, se decidió utilizar uno de los superconjuntos de Javascript para desarrollar en React, más específicamente Typecript, como el equipo ya lo conocía. Todas las aplicaciones web que siguen la arquitectura SPA deben mantener el estado de navegación web del usuario.

Una de las decisiones más importantes que tomó el equipo fue qué infraestructura construir para alojar el sistema. Elegir IaaS tiene muchas ventajas, ya que el equipo es responsable de toda la infraestructura.

Gestión de proyecto

Fases e hitos del proyecto

Fase de investigación

  • Implementación de Kanban
  • Distribución de esfuerzo

En la reunión del miércoles con la docente se hizo un resumen de lo investigado durante la semana y se priorizaron las tareas. En el gráfico anterior se puede ver el porcentaje aproximado de distribución del esfuerzo por categoría, ya que aunque esto estaba controlado, no todas las tareas estaban categorizadas. En primer lugar, muestra cómo la técnica de recopilación de requisitos requirió más de la mitad del esfuerzo en la fase de investigación.

Esto se debe principalmente a las características del proyecto y al desconocimiento del equipo sobre el tema, lo que hizo que los integrantes buscaran todas las formas posibles de adquirir conocimientos incluso antes de la fase de desarrollo. Al mismo tiempo, también se puede comprobar que se ha investigado en la automatización de procesos, pero también en la evaluación de tecnologías e infraestructuras.

Fase de desarrollo

  • Implementación de Scrum
  • Release plan
  • Métricas de gestión

Lista de trabajo para implementar las historias de usuario que el equipo creó en Sprint Planning para completar los objetivos seleccionados para la siguiente iteración. Al final de cada iteración, el equipo realizó validaciones con el propietario del producto a través de demostraciones para verificar que el desarrollo cumpla con los criterios de aceptación definidos. En este caso, después de cada sprint, el equipo realizó una autoevaluación del sprint anterior.

La velocidad por sprint es una métrica que te permite visualizar la cantidad de puntos de la historia que el equipo ha completado después del final del sprint. A partir del Sprint 6, se puede ver que el equipo tiene un ritmo constante en términos de puntos de historia y logra alcanzar un promedio de 35 puntos de historia por sprint.

Gestión de la comunicación

  • Comunicación entre el equipo
  • Comunicación con el cliente
  • Comunicación con el tutor y docentes de ORT

144 Finalmente, al crear una arquitectura evolutiva debido a los requisitos cambiantes, fue posible mantener la coherencia en su desarrollo sin requerir esfuerzo adicional. 145 problema y a medida que avanzaba la búsqueda, se revelaron los requisitos del sistema. Al entrar en la fase de desarrollo, se entregaron los incrementos de producto resultantes de los distintos sprints.

Los miércoles se realizaron reuniones semanales, durante las cuales se hizo un breve resumen de los avances. También se utilizó WhatsApp para todas las dudas que surgían a diario.

Gestión de riesgos

  • Metodología utilizada
  • Identificación de riesgos
  • Análisis cuantitativo
  • Control y seguimiento

1 Bajo impacto en el proyecto 3 Impacto medio en el proyecto 5 Alto impacto en el proyecto. Conocimiento del producto sobre los problemas comerciales y de dominio que afectan el producto y su uso. A lo largo del proyecto se realizó una evaluación y actualización mensual de los riesgos identificados con el objetivo de un mejor control y seguimiento de los mismos.

Dado que se trataba de un proyecto complejo con gran incertidumbre en el dominio del problema, el tamaño de los requisitos cambió e incluso aparecieron algunos nuevos. En el anexo 13.18 siguiente se puede ver el seguimiento detallado de cada uno de ellos.

Resumen

En la ilustración anterior se puede ver cómo ha ido evolucionando mes a mes el tamaño de los principales riesgos. La fase de desarrollo consistió en codificar la solución con la automatización como punto de referencia, tanto para probar como para implementar la solución. Esto estaba en línea con las necesidades del cliente, que requería una entrega rápida y eficiente de software valioso.

Paralelamente al desarrollo, también se identificaron riesgos potenciales del proyecto con el fin de rastrear cada uno de ellos y prevenir su materialización.

Automatización del proceso de ingeniería de software: un acercamiento a

  • DevOps
  • Integración y despliegue continuo
    • Investigación y construcción
    • Ejecución
  • Buenas prácticas utilizadas
  • Resumen

A continuación, se detallará el proceso que realizó el equipo para aplicar la integración e implementación continua en los distintos sistemas del proyecto. El equipo tuvo que tomar varias decisiones a nivel de desarrollo, tecnologías y construcción de la arquitectura para respaldar y garantizar la automatización de las prácticas de integración continua y implementación continua de la manera deseada. Una de las primeras decisiones que tuvo que tomar el equipo fue elegir la herramienta de integración continua.

A continuación, se explicarán los pasos seguidos por el equipo para realizar la integración y despliegue continuo luego de una adecuada configuración del proyecto. El equipo utilizó tanto Kanban como Scrum como marcos de gestión ágil según la fase en la que se encontraba el proyecto.

Gestión de la configuración

  • Elementos de configuración
    • Software
    • Librerías
    • Infraestructura
    • Documentación
  • Elección de herramientas
  • Metodología de trabajo
  • Resumen

Como ya se mencionó a lo largo del proyecto, el equipo intentó automatizar el proceso de ingeniería de la manera más eficiente y rápida posible. Es una parte fundamental de la computación en la nube y es esencial para DevOps [114]. Rama de funciones: la rama de soporte que se genera a partir de la rama de desarrollo para lanzar nuevas funciones.

Al final del desarrollo de la funcionalidad, se crea una solicitud de extracción y una vez aprobada, se integra al desarrollo. Rama Hotfix: rama de soporte que se origina desde la rama master con el propósito de corregir inmediatamente un error en producción.

Gestión de la Calidad

  • Objetivos de Calidad del Producto
  • Plan de Calidad
  • Aseguramiento de la Calidad
    • Aplicación de estándares
    • Capacitación en tecnologías
    • Revisiones
    • Retrospectivas
    • Verificaciones
    • Validaciones
    • Pruebas de Software
    • Automatización de pruebas
  • Gestión de incidentes
  • Métricas de calidad
    • Calidad de código

Antes de comenzar el desarrollo de software, el equipo decidió seguir un artículo sobre estándares y buenas prácticas para la codificación [117]. Antes de entrar a la fase de desarrollo, el equipo tuvo que capacitarse en ciertas tecnologías utilizadas para el desarrollo y la infraestructura del sistema. Por el lado del desarrollo, se han realizado evaluaciones cruzadas entre los miembros del frontend y del backend con el objetivo de que ambos subequipos conozcan el código del otro.

Se realizaron pruebas de integración manual entre frontend y backend al final de cada sprint con el objetivo de verificar que las nuevas características funcionaran juntas correctamente. Para el backend, SonarQube se configuró para adherirse a los estilos de programación Java propuestos por Google [121], y para el frontend, es-lint se configuró para los estilos de programación React propuestos por Airbnb [122].

Conclusiones

  • Estado actual
  • Conclusiones del proyecto
    • Conclusiones de los objetivos académicos
    • Conclusiones de los objetivos del producto
    • Conclusiones de los objetivos del proyecto
  • Reflexiones y lecciones aprendidas
  • Próximos pasos

El equipo pudo aprovechar esta oportunidad para aplicar los conocimientos adquiridos durante el curso. Sin duda, el equipo logró el objetivo de crear un producto extremadamente exigente y complejo. Hacer que el producto fuera productivo antes de la entrega final fue sin duda uno de los objetivos más desafiantes y motivadores para el equipo.

199 El equipo se comprometió con el cliente a tener un producto en producción antes de la entrega final. Fue un desafío que el equipo abordó con total motivación y seriedad para lograr los objetivos del proyecto.

Anexos

Archivos de ventas de clientes de Conecta361

Formato y especificación de campos de Facebook Ads

Flujo de subida de archivo manual en Facebook Ads

Wireframes, mockups y prototipos iniciales

  • Wireframes
  • Mockups y Prototipos iniciales

Resumen de herramientas utilizadas

Justificación de herramientas utilizadas

Ingeniería Inversa

Evidencia de primeras investigaciones

Listado de principales temas de investigación

Evidencias de flujos de investigación de APIs y sistema

Product Backlog

API Endpoints

Análisis de hosting para el sistema

Evidencia de feedback recolectado en Sprint Reviews

Hitos principales del proyecto

Informes de revisiones formales de Universidad ORT Uruguay

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

Plan de riesgos

Seguimiento de principales riesgos del proyecto

Análisis y justificación de elección de herramienta de CI/CD

Elementos de configuración de template de desarrollo genérico

Evidencia de elementos de software

Evidencia de librerías

Evidencia de elementos de infraestructura

Evidencia de elementos de documentación

Gitflow

Evidencia de versionado

Sincronización de Github con Jira y CI

Plan de calidad

Estándares de codificación

Referencias

Documento similar

Por la cual se ordena publicar un proyecto de resolución de carácter general “Por la cual se establece la metodología para calcular el costo de oportunidad del