Embed Size (px)
Citation preview
1
IMPLEMENTACIÓN DE PLATAFORMA MARCA BLANCA INFLUTECH PARA LA
AUTOMATIZACIÓN DE INFLUENCER MARKETING DIGITAL EMPRESARIAL.
Presentado por:
JOSÉ LUIS DÍAZ BERNAL JAIME DAVID NIÑO VALDERRAMA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ, COLOMBIA
2017
2
IMPLEMENTACIÓN DE PLATAFORMA MARCA BLANCA INFLUTECH PARA LA
AUTOMATIZACIÓN DE INFLUENCER MARKETING DIGITAL EMPRESARIAL.
Presentado por:
JOSÉ LUIS DÍAZ BERNAL JAIME DAVID NIÑO VALDERRAMA
INFORME FINAL DE PASANTIA
Ms. Ing. ALEJANDRO DAZA Director
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ, COLOMBIA
2017
3
TABLA DE CONTENIDO 1. INTRODUCCIÓN.............................................................................................................. 8
2. PLANTEAMIENTO DEL PROBLEMA ........................................................................... 10
3. OBJETIVOS .................................................................................................................... 12
3.1. OBJETIVO GENERAL ............................................................................................. 12
3.2. OBJETIVOS ESPECÍFICOS ..................................................................................... 12
4. JUSTIFICACIÓN ............................................................................................................ 13
5. MARCO TEÓRICO ......................................................................................................... 15
5.1. REPOSITORIOS GIT ................................................................................................ 15
5.1.1 SISTEMAS DE CONTROL DE VERSIONES LOCALES ..................................... 16
5.1.2 SISTEMAS DE CONTROL DE VERSIONES CENTRALIZADOS ....................... 17
5.1.3 SISTEMAS DE CONTROL DE VERSIONES DISTRIBUIDOS ............................. 18
5.2. RUBY ........................................................................................................................ 19
5.3. RUBY ON RAILS ...................................................................................................... 20
5.3.1 ARQUITECTURA DE RAILS .............................................................................. 21
5.4. BASES DE DATOS RELACIONALES ....................................................................... 23
5.4.1 POSTGRESQL ..................................................................................................... 25
5.5. BASES DE DATOS NO RELACIONALES ................................................................ 27
5.5.1 MONGODB ......................................................................................................... 30
5.5.2 ELASTICSEARCH .............................................................................................. 31
5.5.3 REDIS .................................................................................................................. 33
5.6. AUTOMATIZACIÓN Y ENCOLAMIENTO DE TAREAS ......................................... 34
5.6.1 CRONS ................................................................................................................ 34
5.6.2 SIDEKIQ ............................................................................................................. 35
5.7. APIs .......................................................................................................................... 36
5.8.1 OAUTH2 .............................................................................................................. 37
5.8.2 FACEBOOK REST API ....................................................................................... 37
5.8.3 TWITTER REST API ........................................................................................... 38
5.8.4 GOOGLE REST API ............................................................................................ 39
5.9. AMAZON WEB SERVICES ...................................................................................... 40
5.9.2 RDS ..................................................................................................................... 41
5.9.3 S3 ......................................................................................................................... 42
5.10. SERVIDOR DE APLICACIÓN ................................................................................ 42
5.10.1 UNICORN .......................................................................................................... 43
5.11. NGINX .................................................................................................................... 44
4
6. METODOLOGÍA ............................................................................................................ 45
6.1 METODOLOGÍAS ÁGILES ....................................................................................... 45
6.2 SCRUM ...................................................................................................................... 46
6.2.1. GENERALIDADES ............................................................................................. 46
6.2.2. BASE TEÓRICA DE SCRUM ............................................................................. 47
6.2.3. EL EQUIPO DE SCRUM..................................................................................... 47
6.2.4. EVENTOS DE SCRUM ....................................................................................... 48
6.3 IMPLEMENTACIÓN DE LA METODOLOGÍA ........................................................ 51
7. PROCESO DE DESARROLLO........................................................................................ 54
7.1. FASE DE ANÁLISIS ................................................................................................. 54
7.1.1 REVISIÓN DE LA PLATAFORMA FLUVIP ................................................. 54
7.2. FASE DE EVALUACIÓN .......................................................................................... 61
7.2.1 EVALUACIÓN DE LOS SISTEMAS DE ALMACENAMIENTO .......................... 62
7.2.2. EVALUACIÓN DE LA INTERCOMUNICACIÓN ENTRE APLICACIONES ...... 75
7.2.3. EVALUACIÓN DE LOS MEDIOS DE COMUNICACIÓN CON LOS USUARIOS 81
7.2.4. EVALUACIÓN DEL ENTORNO DE PRUEBAS .................................................. 84
7.2.5. EVALUACIÓN DEL SITIO PRINCIPAL DE LA APLICACIÓN ......................... 85
7.2.6. EVALUACIÓN DE LA CARGA DE ARCHIVOS DE LOS USUARIOS ................ 86
8. RESULTADOS ................................................................................................................ 90
8.1. CREAR UN MODELO ARQUITÉCTONICO QUE GARANTICE UN SISTEMA AISLADO PARA CADA MARCA BLANCA. ................................................................... 90
8.1.1 ARQUITECTURA FÍSICA FINAL ....................................................................... 90
8.1.2 ARQUITECTURA LÓGICA FINAL .................................................................... 91
8.1.3 ESTRUCTURA SECUENCIAL FINAL ................................................................ 91
8.2. PROPONER UN MODELO DE BASE DE DATOS QUE GARANTICE CONCURRENCIA EN CADA MARCA BLANCA. ........................................................... 95
8.2.1 ESTRUCTURA FINAL DE BASE DE DATOS ...................................................... 95
8.3. RESULTADOS OBTENIDOS CON LA ARQUITECTURA Y MODELO DE DATOS PROPUESTO .................................................................................................................. 97
8.3.1. RENDIMIENTO Y TIEMPOS DE RESPUESTA.................................................. 98
8.3.2. DATOS ............................................................................................................. 101
8.4. MODULO ORIENTADO A PRUEBAS AUTOMATIZADAS. ................................... 101
8.5. ACOPLAMIENTO DE LOS SERVICIOS EXTERNOS (REDES SOCIALES) CON EL NUEVO MODELO DE AGENCIA ................................................................................. 103
8.6. IMPLEMENTAR UN MODULO DE PERSONALIZACIÓN VISUAL PARA CADA AGENCIA. .................................................................................................................... 106
5
8.7. RESULTADOS COMERCIALES DEL PRODUCTO: IMPACTO DE SERVICIOS INTERNOS Y PROTOTÍPOS INTERACTIVOS. ........................................................... 111
8.8 FUNCIONAMIENTO DE PROTOTIPOS, ADAPTACIÓN DE NUEVOS USUARIOS Y COSTO BENEFICIO PROYECTADO DEL PROYECTO .............................................. 112
8.9 TAMAÑO DEL PROYECTO .................................................................................... 117
8.10 INCONVENIENTES ............................................................................................... 117
9. CONCLUSIONES .......................................................................................................... 119
10. BIBLIOGRAFIA .......................................................................................................... 122
LISTA DE ILUSTRACIONES Ilustración 1 Chacon, S. (2014). Diagrama de control de versiones local. .............................. 16 Ilustración 2 Chacon, S. (2014). Diagrama de control de versiones centralizado. .................. 17 Ilustración 3 . Chacon, S. (2014). Diagrama de control de versiones distribuido. .................. 18 Ilustración 4 Matsumoto, Y. (2003). Bloques, una funcionalidad realmente expresiva. ......... 19 Ilustración 5 Komisar, P. (2009). Ruby on Rails Architecture. ............................................... 21 Ilustración 6 Jerarquía de almacenamiento de datos en PostgreSQL ...................................... 26 Ilustración 7 Base de datos Clave Valor. ................................................................................. 29 Ilustración 8 Base de datos Documental. ................................................................................. 30 Ilustración 9 Base de datos de grafos. ...................................................................................... 30 Ilustración 10 Sintaxis para definir una tarea en Cron. ............................................................ 35 Ilustración 11 Facebook API. .................................................................................................. 38 Ilustración 12 Twitter API. ...................................................................................................... 39 Ilustración 13 Google YouTube API. ...................................................................................... 40 Ilustración 14 Información básica de SCRUM. ....................................................................... 49 Ilustración 15 Cronograma del Proyecto ................................................................................. 53 Ilustración 16 Arquitectura de almacenamiento inicial. .......................................................... 56 Ilustración 17 Protocolos de comunicación con aplicaciones externas ................................... 57 Ilustración 18 Sistema inicial de envío de correo electrónico. ................................................ 58 Ilustración 19 Sistema automatizado de pruebas. .................................................................... 59 Ilustración 20 Modelo de Dominio Inicial FLUVIP ................................................................ 63 Ilustración 21 Nueva Arquitectura interna de la base de datos relacional. .............................. 67 Ilustración 22 Arquitectura Física de la plataforma utilizando un RDS. ................................. 67 Ilustración 23 Automatización de migraciones mediante tareas administrativas. ................... 68 Ilustración 24 Manejo de cache con el ORM........................................................................... 69 Ilustración 25 Generación de nodos por agencia. .................................................................... 71 Ilustración 26 MongoDB para agencias. .................................................................................. 73 Ilustración 27 Almacenamiento de credenciales en base de datos. ......................................... 78 Ilustración 28 Esquema de comunicación con redes sociales usando la fase de configuración. .......... 80
6
Ilustración 29 Almacenamiento de configuración de correo en base de datos. ....................... 82 Ilustración 30 Personalización de correo electrónico con identidad de una marca blanca. ..... 83 Ilustración 31 Separación de INFLUTECH del Sitio Público de FLUVIP. ............................ 86 Ilustración 32 Integración de INFLUTECH con archivos multimedia en instancia S3. ......... 89 Ilustración 33 Arquitectura física final de INFLUTECH. ....................................................... 92 Ilustración 34 Arquitectura lógica final de INFLUTECH ....................................................... 93 Ilustración 35 Estructura secuencial del sistema. .................................................................... 94 Ilustración 36 Modelo de Dominio Inicial FLUVIP ................................................................ 96 Ilustración 37 Estructura final de base de datos para el aislamiento de información. ............. 97 Ilustración 37 Operaciones de mayor consumo en PostgreSQL. ............................................. 98 Ilustración 38 Operaciones de mayor consumo en Redis. ....................................................... 99 Ilustración 39 Tiempo de respuesta de peticiones web. ........................................................... 99 Ilustración 40 Distribución del módulo automatizado de pruebas......................................... 103 Ilustración 41 Independización de servicios externos por agencia ........................................ 105 Ilustración 42 Landing Socialyse. .......................................................................................... 107 Ilustración 43 Landing Thinketers. ........................................................................................ 107 Ilustración 44 Formulario de registro Socialyse. ................................................................... 108 Ilustración 45 Formulario de registro Thinketers. ................................................................. 108 Ilustración 46 Formulario de ingreso Socialyse..................................................................... 109 Ilustración 47 Formulario de ingreso Thinketers. .................................................................. 109 Ilustración 48 Dashboard Operativo Socialyse. ..................................................................... 110 Ilustración 49 Dashboard Operativo Thinketers. .................................................................. 110 Ilustración 50 Dashboard Influencer Socialyse. .................................................................... 110 Ilustración 51 Dashboard Influencer Thinketers.................................................................... 111 Ilustración 52 Ingresos totales INFLUTECH. ....................................................................... 115 Ilustración 53 Ingresos totales, Costos de inversión y Ganancia Neta. ................................. 116 Ilustración 54 Relación de costo beneficio. ........................................................................... 116
7
LISTA DE TABLAS Tabla 1 Ejemplo de una tabla en el modelo relacional de bases de datos ............................... 23 Tabla 2 Ejemplo de una mala estructura de datos. ................................................................... 24 Tabla 3 Distribución inicial de los archivos del proyecto........................................................ 55 Tabla 4 Bases de datos utilizadas en FLUVIP. ........................................................................ 56 Tabla 5 Medios de comunicación implementados en FLUVIP. .............................................. 58 Tabla 6 Estado inicial del conjunto de pruebas del sistema..................................................... 60 Tabla 7 Ventajas y desventajas de utilizar un solo esquema de PostgreSQL .......................... 65 Tabla 8 Ventajas y desventajas de usar múltiples esquemas en PostgreSQL. ......................... 65 Tabla 9 Ventajas y desventajas de usar un único índice de Elasticsearch. .............................. 70 Tabla 10 Ventajas y desventajas de usar múltiples índices de Elasticsearch. ......................... 70 Tabla 11 Ventajas y desventajas de usar múltiples bases de datos de MongoDB. .................. 72 Tabla 12 Ventajas y desventajas de usar una única base de datos de MongoDB. ................... 73 Tabla 13 Ventajas y desventajas de una base de Redis por agencia. ....................................... 74 Tabla 14 Ventajas y desventajas de usar AWS ElasticCache. ................................................. 74 Tabla 15 Ventajas y desventajas de usar un conjunto único de clientes de aplicaciones de redes sociales. .... 76 Tabla 16 Ventajas y desventajas de usar varios conjuntos de clientes de aplicaciones de redes sociales. ...... 77 Tabla 17 Parámetros de configuración de clientes de aplicación de redes sociales ................ 79 Tabla 18 . Ventajas y desventajas de servir los archivos estáticos desde el servidor de aplicación. .............. 87 Tabla 19 . Ventajas y desventajas de servir los archivos estáticos desde un bucket en una instancia S3........ 88 Tabla 20 Comparación de métricas de rendimiento. ............................................................. 100 Tabla 21 Crecimiento en los motores de almacenamiento .................................................... 101 Tabla 22 Comparación del conjunto total de pruebas. ........................................................... 101 Tabla 23 Restricciones de uso de servicios externos. ............................................................ 104 Tabla 24 Especificación de logos. Tomado del manual de creación. .................................... 106 Tabla 25 Resultados comerciales por marca blanca. ............................................................. 112 Tabla 26 Resultados comerciales por marca blanca .............................................................. 113 Tabla 27 Ingresos totales INFLUTECH. ............................................................................... 114 Tabla 28 Proyección de costo beneficio. ............................................................................... 115 Tabla 29 . Comparación del tamaño del proyecto. ................................................................ 117
8
1. INTRODUCCIÓN El marketing de influenciadores es un sector del área de mercadeo que se enfoca en conectar a
las marcas anunciantes con influenciadores, para que, a través de sus redes sociales, dichos
influenciadores comuniquen o difundan información de estas marcas de forma orgánica.
En los últimos años, el Influencer Marketing ha contado con importantes transformaciones las
cuales han permitido una expansión en la manera de hacer publicidad en diversos medios
digitales. Gracias al auge del internet, varias empresas de mercadeo se han dedicado a
implementar nuevas técnicas y herramientas para incrementar las métricas publicitarias e
impulsar a sus clientes en el proceso de globalización, permitiendo que los contenidos creados,
sean expuestos a diferentes y mayores tipos de público directos o potenciales frente a las
empresas que deciden destinar parte de su presupuesto a campañas digitales.
De igual manera, la diversidad en materia de herramientas tecnológicas, también ha facilitado
el desarrollo de aplicaciones y sistemas de información que contribuyen al crecimiento de este
nuevo tipo de mercado. La automatización de tareas para involucrar a las marcas y al público
general ha creado la necesidad de nuevas maneras de comunicación y control en estas empresas.
Por otra parte, el crecimiento del número de compañías de todos los sectores relacionados con
la tecnología, que ofrecen soluciones de Software como servicio (Saas) y que implementan
proyectos tecnológicos bajo el modelo “Marca Blanca” (del inglés White Label o Multi-tenant
Applications).
Las aplicaciones “Multi-Tenant” resuelven la necesidad de ofrecer un conjunto de servicios de
manera aislada, a cientos o miles de compañías diferentes, para que automaticen los procesos
relacionados con algún sector particular. Al mismo tiempo, las compañías ahorran mucho
tiempo y dinero al no tener que implementar un sistema similar desde cero y pueden ofrecer el
sistema como un producto propio de la empresa.
Utilizando una aplicación bajo este modelo las empresas adquieren ventajas competitivas para
mantenerse a la vanguardia de los desarrollos tecnológicos, al mismo tiempo que pueden
9
garantizar que la información recopilada es de su propiedad y que los procesos de
mantenimiento, revisión y actualización corren por parte del proveedor de la aplicación.
10
2. PLANTEAMIENTO DEL PROBLEMA FLUVIP es una empresa dedicada a conectar marcas de productos con audiencias específicas
a través de personajes que pueden influir en las decisiones de compra de los productos de dichas
marcas, es decir, “se dedica a la publicidad programática de contenidos de marcas particulares,
a través de las redes sociales de personas con gran influencia sobre audiencias objetivo” [1], esto
es conocido como Influencer Marketing.
El principal objetivo de FLUVIP es permitirles a las grandes marcas ofrecer sus productos o
anunciar sus eventos a través de las redes sociales de celebridades, expertos en ciertas áreas o
personas del común por medio de su plataforma tecnológica. Este proceso de conectar las
marcas con las personas llamadas influenciadores, se realiza a través de la plataforma web,
proponiendo los contenidos que luego serán publicados programáticamente en las redes de
estos influenciadores. Una vez finalizadas estas publicaciones, FLUVIP, permite que las
marcas realicen seguimiento del impacto que tuvieron sus campañas en cada red social de
manera detallada.
Durante el desarrollo de esta labor, la empresa se encuentra con la oportunidad de contactar a
un número significativo de agencias de medios; estas agencias son empresas que realizan
labores publicitarias con marcas, de manera muy similar a la labor de FLUVIP pero de una
manera mucho menos automática; es decir, se encargan de la publicación de contenidos en
redes sociales y de llevar estadísticas y seguimiento a todas las campañas, de manera manual,
lo que representa una mayor inversión de costo y tiempo y mayor vulnerabilidad a errores.
Estos procesos manuales para estas agencias de medios, representan un gran desafío ya que, al
ser influenciadores personajes que proponen sus propios contenidos, se pone de manifiesto la
necesidad de mantener un seguimiento constante sobre estos posteos para asegurar su correcta
publicación y el cumplimiento de los parámetros que las marcas requieren sobre estos
contenidos.
La realización manual de todos estos procesos, hace que el análisis de los resultados sea escaso
y que las campañas tengan poca información que facilite y apoye la creación de estrategias a
11
tener en cuenta para futuras iniciativas publicitarias, además de no contar con datos generados
en tiempo real.
Según la revista FORBES en su edición de diciembre de 2016, el 47% de los consumidores en
línea usan algún tipo de tecnología que bloquea los avisos publicitarios, razón por la cual se
hace necesario para las marcas usar el poder de influencia de las personas en las redes sociales
de forma orgánica, controlada y medible con el fin de alcanzar más consumidores, y de esta
manera, alcanzar a este gran porcentaje de usuarios que se pierde gracias a los bloqueos de
publicidad.
Luego de analizar estos factores de oportunidad, se consideraron como variables a analizar: la
personalización de contenidos, la selección de influenciadores en un punto de entrada único, el
monitoreo oportuno de estos contenidos y el análisis de la información que estos contienen y
su impacto. Teniendo en cuenta estas variables, se plantean las siguientes preguntas: ¿De qué
manera se pueden unir estas agencias de medios a FLUVIP y mejorar sus procesos de
Influencer Marketing? ¿Cómo generar soluciones de automatización de procesos en las
agencias publicitarias y de marketing y monetizar desde FLUVIP?
Así, se plantea la necesidad de generar un producto estándar para dichas agencias que facilite
el registro de los influenciadores de forma sistemática, y la generación automática de los
reportes parciales y finales que se hacen sobre las estadísticas de las publicaciones que generan
los influenciadores para las marcas.
De esta manera, en el presente proyecto se propone la implementación de un sistema Marca
Blanca que les permita a las agencias de medios tener estas funcionalidades y trabajar sobre
una plataforma robusta, generando un nuevo modelo de negocio para FLUVIP y un valor
agregado para las empresas que implementan esta tecnología que lleva varios años en
funcionamiento, garantizando en el proceso un ambiente completamente aislado entre cada una
de las agencias.
12
3. OBJETIVOS
3.1. OBJETIVO GENERAL
Diseñar, desarrollar e implementar un Sistema de Información enfocado en el Influencer
Marketing, que permita ser usado como plataforma propia a las Agencias de Medios para
automatizar sus campañas publicitarias, teniendo como base las metodologías y herramientas
utilizadas en FLUVIP.
3.2. OBJETIVOS ESPECÍFICOS
3.2.1 Crear un modelo arquitectónico que garantice un sistema aislado bajo las
restricciones de negocio para cada agencia de mercado.
3.2.2 Proponer un modelo de base de datos que garantice concurrencia en cada marca
blanca, y su independencia frente a la estructura actual de FLUVIP.
3.2.3 Diseñar un módulo orientado a pruebas automatizadas que asegure la separación de
la información entre agencias.
3.2.4 Analizar el acoplamiento de los servicios externos (Redes sociales) con el nuevo
modelo de agencias.
3.2.5 Implementar un módulo de personalización de visual para cada cliente que permita
afianzar la identidad de agencia.
3.2.6 Implementar pruebas de funcionamiento de los prototipos operativos de cada una
de las plataformas de cada agencia.
3.2.7 Agilizar el proceso de adaptación de nuevos usuarios operativos con la plataforma
para la creación de propuestas y campañas de cada marca blanca.
13
4. JUSTIFICACIÓN FLUVIP nace como una Startup que ofrece al mercado una propuesta de automatización de
Influencer Marketing, y durante los últimos años se ha convertido en la plataforma líder en
Latinoamérica y Estados Unidos con un enfoque multicultural. En FLUVIP, se considera
influenciador a cualquier persona con presencia en redes sociales y se encuentran categorizados
como Celebridades (personas conocidas en el mundo on y off line, generalmente con cientos
de miles de seguidores y se encargan de aportar alcance), Profesionales (personas
especializadas en un tema, su audiencia los sigue porque confía en sus contenidos y se encargan
de aportar validación),y Ciudadanos (personas del común, con un círculo pequeño de
seguidores pero que generan una mayor fidelización).
De esta manera, la creación de plataformas web que permitan difundir los contenidos
publicitarios masivamente, plantea en FLUVIP la necesidad de ofrecer Marcas Blancas (White
Labels) de la plataforma innovadora de marketing de influenciadores.
Este proyecto surge como una oportunidad para FLUVIP de crear una solución de negocios
para las agencias de medios que trabajan o se encuentran incursionando en el proceso de gestión
de automatización de campañas de Influencer Marketing.
Muchas de las empresas que se enfocan en este mercado, realizan los procesos de reclutamiento
de influenciadores, creación de propuestas para clientes y contenidos de manera manual, y se
hace visible la necesidad de automatizar y optimizar estos procesos, principalmente la medición
y análisis de la información que se presenta a través de las redes sociales, lo cual implica estar
a la vanguardia de los desarrollos tecnológicos que generen valor agregado frente a los
competidores en el mercado.
Dado que la implementación y despliegue de un sistema de información que permita llevar a
cabo todos estos procesos de manera automatizada y programática, implica una gran inversión
de tiempo y de capital para estas agencias de medios, se presenta la iniciativa de modificar y
evolucionar la estructura actual del sistema de información de FLUVIP a una estructura del
modelo “Marca Blanca”, lo cual implica una reestructuración del sistema de información
actual, con el fin de abrir el mercado bajo una estructura SaaS (Software as a Service).
14
Este sistema ofrecerá a las agencias de medios y a cualquier otro interesado, la posibilidad de
automatizar sus procesos relacionados con Influencer Marketing y ofrecer el sistema como una
plataforma desarrollada in house, accediendo a todas las funcionalidades actuales con las que
cuenta el sistema de información de FLUVIP.
Marca Blanca se presentará como un sistema que le permita a estas agencias vincular sus
propios influenciadores y relacionarlos con sus propias marcas, desplegar campañas
publicitarias para varias redes sociales, utilizar el sistema de filtros y el sistema de clasificación
demográfica, proponer contenidos y programarlos para que sean publicados automáticamente,
realizar análisis de resultados basados en el sistema de generación de reportes estadísticos, entre
otras características.
Esta estructura se implementará teniendo en cuenta las funcionalidades actuales de FLUVIP,
con un sistema totalmente aislado y encapsulado para cada una de las agencias que se vinculen
y consuman el sistema de información como un servicio.
De esta manera, las agencias que hagan uso de dicho servicio podrán optimizar sus flujos de
trabajo operativo, y tener mayor control sobre sus procesos internos, lo que implica obtener una
mayor monetización y le permitirá a FLUVIP expandir su alcance a muchos otros países con
el objetivo de ser la empresa de Influencer Marketing más grande de Latinoamérica y Estados
Unidos.
15
5. MARCO TEÓRICO Implementar dentro del modelo de negocio del Influencer Marketing una plataforma
innovadora y robusta que brinde a las agencias nuevas oportunidades de expansión y
crecimiento, exige a FLUVIP desarrollo de tecnologías sólidas que permitan extender y adaptar
sus funcionalidades de forma rápida y segura.
La tecnología sobre la que la plataforma MARCA BLANCA INFLUTECH se encuentra
sustentada, busca dar respuesta a cada uno de los requerimientos y necesidades del mercado de
las agencias de medios. Una vez determinados los requisitos de cada una de las agencias, se
definirán las estrategias tecnológicas que permitan brindar a los clientes un producto
completamente funcional.
Parte de este análisis inicial, se presenta a continuación con un resumen de cada una de las
herramientas que serán utilizadas en el desarrollo de este proyecto, con el fin de reducir tiempos
de entrega, tener control, agilidad, y calidad en los procesos de desarrollo de software sobre la
plataforma INFLUTECH.
5.1. REPOSITORIOS GIT
GIT es una herramienta que permite el versionamiento del código fuente de la plataforma con
el fin de registrar, revisar, agregar y revertir cambios hechos sobre el mismo, y de esta manera,
tener control sobre el código de INFLUTECH.
Scott Chacon y Ben Straub (2014) [2] indican que para hablar de repositorios GIT, primero
debemos introducirnos en los sistemas de control de versiones (CVS) los cuales son sistemas
que registran los cambios realizados sobre un archivo o una colección de archivos a lo largo
del tiempo y de esta forma permiten la gestión sobre proyectos, facilitando la recuperación de
anteriores versiones de un archivo, lo que mejorando el seguimiento y recuperación del
proyecto en sus distintas versiones.
Existen diferentes sistemas de control de versiones:
16
5.1.1 SISTEMAS DE CONTROL DE VERSIONES LOCALES
Chacon & Straub (2014) afirman que es el enfoque más simple, el cual se basa en la labor de
copiar los archivos a un nuevo directorio. Podría decirse que es más un trabajo manual,
propenso a errores en las versiones y que por ende no permite un correcto control y seguimiento
del trabajo realizado a pesar de que este se pueda documentar y versionar por fecha o por algún
otro indicativo. Como medida preventiva y para contrarrestar este evento, se han desarrollado
herramientas simples que dan seguimiento mediante bases de datos llevando el registro de los
cambios realizados en las versiones y archivos del proyecto.
Ilustración 1 Chacon, S. (2014). Diagrama de control de versiones local. [Figura]. Recuperado de https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones
Esta herramienta de versión local, como se puede observar en la figura 1, consiste en la
existencia una base de datos de versiones en la cual se guardan conjuntos de parches, entiéndase
como diferencias entre los archivos modificados y el repositorio remoto, y persistiendo estos a
disco en un formato especial que luego permite recrear los archivos sumando estos diferentes
parches.
17
5.1.2 SISTEMAS DE CONTROL DE VERSIONES CENTRALIZADOS
Según Chacon & Straub (2014) en el desarrollo de software el trabajo en equipo para el
desarrollo e implementación de requerimientos es muy importante, por lo que surge la
necesidad de un sistema de control de versiones que permita que uno o más desarrolladores
puedan contribuir al proyecto de manera ordenada y controlada para no afectar el desarrollo
del mismo, procurando así que cada uno de los integrantes del proyecto tenga la posibilidad de
estar trabajando en su propia versión, garantizando que esa parte desarrollada sea capaz de
integrarse posteriormente a la versiones de lo demás desarrolladores. Aunque ofrece muchas
ventajas en cuanto al control de versiones, posee una debilidad que, dada su naturaleza remota
y centralizada, puede incurrir en problemas como caídas de servidor y aunque no suele suceder
frecuentemente, reversión en los parches ya mezclados en la copia central del proyecto y en
caso de pérdida de la información puede estar ligado a pérdidas totales del proyecto.
Ilustración 2 Chacon, S. (2014). Diagrama de control de versiones centralizado. [Figura]. Recuperado de
https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones
18
5.1.3 SISTEMAS DE CONTROL DE VERSIONES DISTRIBUIDOS
Los sistemas de control de versiones distribuidos como lo son en caso de Git facilitan y mejoran
el trabajo, donde de la misma forma existe un servidor central, pero con la mejora que cada uno
de los usuarios o en este caso clientes puede realizar una copia completa del repositorio central,
clonando la versión original y principal del proyecto, siendo así mucho más fácil que cada uno
de los desarrolladores incorpore sus cambios a la versión principal, mediante el trabajo con
ramas que en este caso se incorporan al nodo padre o también llamado rama master Chacon &
Straub (2014). Cada uno de estos nodos son una copia exacta el nodo master en el momento en
el cual se desprendieron de él, y tienen la facilidad de poder navegar entre nodos, revertir
cambios con referencia al master y rebasar los mismos para actualizar los nodos hijos con el
master.
Ilustración 3 . Chacon, S. (2014). Diagrama de control de versiones distribuido. [Figura]. Recuperado de https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones
19
5.2. RUBY
Ruby es un lenguaje de programación interpretado y orientado a objetos que apareció por
primera vez en 1995 con Yukihiro Matsumoto. Este lenguaje tiene como influencia algunos
lenguajes de programación orientada a objetos como Python, Perl, Smalltalk, Lisp, Lua, entre
otros, esto hace que Ruby se considere un lenguaje multiparadigma, pues permite realizar
programación orientada a procedimientos, con orientación a objetos o funcional. (Matsumoto,
Y. 2001) [3].
Las siguientes son las características principales de Ruby:
● En Ruby todo es un Objeto.
● Los usuarios de Ruby pueden redefinir la parte del lenguaje que quieran que funcione
de forma distinta.
● Dentro de su estructura se presentan los bloques, que son cláusulas aplicadas a métodos
que describen cómo deben actuar.
Ilustración 4 Matsumoto, Y. (2003). Bloques, una funcionalidad realmente expresiva. [Figura]. Recuperado de https://www.ruby-lang.org/es/about/
● Introduce el concepto de Modules que son colecciones de métodos. Las clases pueden
mezclar un módulo e incorporar todos sus métodos, lo cual permite realizar lo que puede
verse como herencia múltiple.
● Tiene un recolector de basura automático.
● Tiene manejo de hilos independiente del sistema operativo.
● Es fácilmente portable, se desarrolla mayoritariamente en GNU/Linux, pero corre en
sistemas UNIX, Windows, DOS, etc.
● Ruby es un código de open source.
20
Este lenguaje de programación es relativamente joven y se dio a conocer en masa hasta hace
unos pocos años, y su objetivo principal es el desarrollador. Se enfoca no en hacer las cosas
más sencillas para la máquina, sino en hacer las cosas más sencillas para el desarrollador de
manera que el programar una aplicación se pueda hacer de forma natural, divertida y ágil. La
sintaxis del lenguaje es muy descriptiva y legible de manera que después de un corto tiempo se
vuelve intuitiva y le permite al programador agilizar y optimizar sus labores.
5.3. RUBY ON RAILS
Ruby on Rails es un framework o entorno de desarrollo web de código abierto que se enfoca
en la satisfacción de los programadores y la productividad sostenible. Permite escribir buen
código y su principio se basa en “Don’t Repeat Yourself”, lo que quiere decir evitar la
repetición, además favorece la convención antes que la configuración (Heinemeier, D.H, 2004)
[4].
Rails es un conjunto de librerías y automatismos destinados a resolver los problemas más
comunes que se presentan al momento de crear una aplicación web, permitiéndole al
desarrollador concentrarse en la lógica de negocio y dejando casi de lado la configuración.
Este framework fue creado en 2003 por David Heinemeier Hansson y en este momento cuenta
con más de 2100 colaboradores y una comunidad activa. Aplicaciones modernas como Twitter,
Scribd, Hulu, Xing, Soundcloud, Basecamp, Github, entre otras fueron construidas con este
framework.
Ruby on Rails es un framework que se desenvuelve en la arquitectura MVC y genera una
estructura básica para cada proyecto, en la cual se basa para hacer manejo y control de la
configuración de la aplicación que se está desarrollando, dentro de la estructura mencionada
cabe destacar los siguientes elementos (Komisar, P, 2009)[5]:
● app: Contiene todos los modelos vistas y controladores, además incluye los ‘helpers’ y
los ‘mailers’ y los recursos estáticos propios de la aplicación.
● bin: Contiene los scripts básicos y necesarios para iniciar y desplegar la aplicación.
● config: Aquí es donde se realiza la configuración de la aplicación relacionada con la
21
base de datos, rutas de la aplicación, entornos de trabajo, entre otros.
● Gemfile: Es un archivo en el que se especifican todas las dependencias externas que
tiene la aplicación, normalmente conocidas como gemas. Son librerías usualmente
desarrolladas por terceros que pueden incluirse dentro de la aplicación.
● lib: Aquí se almacenan todas las librerías y la lógica pesada propia de la aplicación.
● public: Contiene todos los archivos estáticos que pueden ser accedidos por cualquier
usuario desde internet.
● Rakefile: Es un archivo que permite configurar algunas tareas que se ejecutan
periódicamente sobre la aplicación.
● test: Es donde se almacenan todas las pruebas unitarias, de comportamiento y de
aceptación que validan la funcionalidad de la aplicación.
● vendor: Aquí se almacenan archivos estáticos y librerías de terceros.
5.3.1 ARQUITECTURA DE RAILS
La ilustración 5 describe la estructura de una aplicación desarrollada en Ruby on Rails, la cual
está basada en la conocida arquitectura MVC (Model View Controller).
Ilustración 5 Komisar, P. (2009). Ruby on Rails Architecture. [Figura]. Recuperado de
http://www.sentex.net/~pkomisar/Ruby/9_RubyOnRails_1.html
22
En esta arquitectura, un usuario realiza una petición, en este caso a través de un navegador web,
dicha petición llega a un servidor web que evalúa el destino y le entrega la información a un
controlador. El controlador recibe los datos de la petición y se los entrega a una clase o módulo
responsable de procesarlos. Estas clases pueden ser directamente los modelos de la lógica del
negocio, quienes se encargan de interactuar con la base de datos, al final del procesamiento el
controlador se encarga de retornar una respuesta al cliente, ya sea positiva o negativa. Dentro
de la arquitectura descrita cabe destacar los siguientes elementos:
● Active Record: Representa la M en la arquitectura MVC, se encarga de facilitar la
creación de objetos relacionados con los datos del negocio y su lógica. Es una
implementación del patrón Active Record el cual es una descripción misma de un ORM
(Object Relational Mapping system) (Heinemeier, D.H, 2004)[6]. ORM es una técnica
que conecta objetos de aplicación con tablas en una base de datos relacional. Dentro de
las funciones de Active Record están:
○ Representar modelos y sus datos.
○ Representar relaciones entre los modelos.
○ Representar jerarquía y herencia entre modelos relacionados.
○ Validar modelos antes de que sean almacenados en la base de datos.
○ Realizar operaciones en la base de datos directamente a través de objetos.
Active Record permite además realizar tareas de cambios en la base de datos, ya sea
creación de tablas, columnas o actualizaciones, a través de migraciones. Las
migraciones son clases escritas en lenguaje Ruby que permiten realizar dichos cambios
sobre la base de datos. De la misma forma Rails mantiene dentro de su configuración
un archivo escrito en Ruby que representa el esquema completo de la base de datos, el
cual sirve entre otras cosas, para realizar los test que involucren operaciones sobre la
base de datos.
● Action View: Es el encargado de manejar y compilar la respuesta que se envía al
cliente, cuando la respuesta es un documento HTML. Permite escribir templates o vistas
usando Ruby embebido en el código HTML. Provee además un conjunto de funciones,
conocidas como helpers, que proveen comportamiento común relacionado con
23
formularios, fechas y cadenas de texto (Heinemeier, D.H, 2004)[7].
● Action Controller: Representa la C en MVC. Luego de que se ha enrutado una petición
a un controlador en particular, el controlador es el encargado de procesar esta petición
y retornar la respuesta adecuada. El controlador sirve como un mediador entre las vistas
y los modelos de manera que la vista pueda presentar los datos que contenga el modelo
y mostrárselos al cliente (Heinemeier, D.H, 2004)[8]. Los controladores y en general la
arquitectura de Rails siguen la arquitectura de servicios web RESTful, de manera que
se generan recursos para un modelo basándose en los métodos estándar definidos por
HTTP.
● Action Mailer: Es el encargado de permitir la comunicación de la aplicación vía e-
mail. Define un conjunto de vistas y clases que permiten el envío de mails desde la
aplicación y funciona de manera muy similar a los controladores que manejan
peticiones HTTP (Heinemeier, D.H, 2004)[9].
5.4. BASES DE DATOS RELACIONALES
Los datos son el insumo principal de las actividades económicas y sociales de este nuevo siglo
y a través de la historia el ser humano ha ideado diferentes técnicas para almacenarlos y
analizarlos. Una base de datos se entiende como una colección estructurada de datos, es decir,
una forma de almacenamiento de datos que permite ser consultada posteriormente. Dentro de
los sistemas de información, las bases de datos o sistemas gestores de base de datos son
programas que permiten almacenar y consultar la información bajo el modelo entidad relación.
En este modelo los objetos del entorno a describir son representados mediante tablas con filas
y columnas, donde cada columna representa un atributo o característica del objeto, mientras
cada fila es un ejemplo particular del objeto, también llamado entidad, como se ve en la tabla
1.
Concursante
Nombre Apellido Edad País
Juan Pérez 23 3
Camila López 30 2
Tabla 1 Ejemplo de una tabla en el modelo relacional de bases de datos
24
La tabla 1 describe un objeto o entidad llamada Concursante. Cada columna de la tabla
representa una característica o atributo de un concursante, como por ejemplo su edad, y cada
fila de la tabla representa un objeto de dicha entidad, en este caso cada fila representa a un
concursante.
De acuerdo a Mike Gahan (2000)[10] este modelo aparece como solución a algunos problemas
que se presentan a la hora de almacenar los datos, algunos de ellos se mencionan a continuación:
● Pérdida de tiempo al almacenar varias veces la misma información.
● Se incrementa la probabilidad de error.
● Desperdicio de almacenamiento en disco.
● Afecta el rendimiento del sistema o programa que acceda a los datos.
● Las actualizaciones o correcciones deben aplicarse varias veces.
Según Gahan, una estructura de datos pobre puede llevar a la inflexibilidad a la hora de usar la
base de datos y posiblemente a problemas y errores al momento de consultar la información
que se desea. Un ejemplo de ello puede verse en la tabla 2.
Concursante
Nombre Apellido Edad País Continente Idioma
Juan Pérez 23 Colombia América Español
Pedro Alcacer 45 Colombia América Español
Camila López 30 Argentina América Español
Tabla 2 Ejemplo de una mala estructura de datos.
En la tabla 2 se puede ver como los datos relacionados con el país se tienen que repetir cada
vez que se almacena un registro de la tabla Concursante, esto refleja varios de los problemas
mencionados anteriormente, en este caso la información del país debería ser almacenada en una
tabla (Entidad) aparte y ser relacionada con la tabla Concursante.
25
Para resolver estos inconvenientes, el modelo relacional tiene varios mecanismos y
características que permiten dar una estructura sólida y confiable a los datos que se almacenan,
entre ellos se encuentran:
● Relaciones uno a uno.
● Relaciones uno a muchos.
● Relaciones muchos a muchos.
● Llaves primarias y llaves foráneas.
● Definición de tipos de datos.
5.4.1 POSTGRESQL
En el mercado existen numerosos motores o sistemas gestores de bases de datos tanto pagos
como de código abierto. PostgreSQL es un sistema gestor de bases de datos relacional orientado
a objetos de código abierto de amplia reputación y popularidad en la actualidad por su robustez,
confiabilidad e integridad. Es compatible con todos los sistemas operativos más importantes
(Windows, Unix, Linux), cumple con los estándares de SQL y tiene una amplia integración
nativa con varios lenguajes de programación como Java, Python, Ruby, entre otros [11].
Ventajas
En el sitio oficial de PostgreSQL (2017)[11], se describen varias ventajas de utilizar esta
herramienta como sistema gestor de base de datos:
● Posibilidad de extensión y modificación sin costos adicionales por licencias, dado que
es un software de código abierto.
● Amplia comunidad de contribuidores en internet que aportan y brindan soporte
constantemente.
● Confiabilidad legendaria en el sistema, dado que las compañías constantemente
reportan que PostgreSQL nunca ha presentado una caída en sus sistemas en muchos
años de uso.
● Es multiplataforma, lo que indica que es compatible con todos los sistemas operativos
tradicionales.
26
● Diseñado para ambientes de amplios volúmenes de datos.
● Provee muchas herramientas visuales de administración.
Características
Desde la documentación oficial del sitio (2017)[12] se describen algunas características
modernas de este sistema de bases de datos, adicionales a las muchas que ofrece el estándar
SQL:
● Consultas complejas.
● Llaves foráneas.
● Disparadores.
● Vistas actualizables.
● Integridad transaccional.
● Control de concurrencia multi-versión.
● Funciones de agregación.
● Lenguajes procedimentales.
Jerarquía de almacenamiento
A manera de organizar estructuradamente la información, PostgreSQL define su propia
jerarquía de almacenamiento de datos como se ve en la figura 6:
Ilustración 6 Jerarquía de almacenamiento de datos en PostgreSQL
27
● Clúster: Un clúster es una colección de bases de datos, es el nivel más alto de jerarquía
de almacenamiento en PostgreSQL y se caracteriza porque no tiene nombre y no puede
ser referenciado desde adentro del sistema de base de datos.
● Base de Datos: Una base de datos es una colección de tablas, funciones, operadores,
vistas, índices, secuencias, entre otros. Debe tener un nombre único en el clúster en el
que se encuentra.
● Esquemas: Un esquema es una colección nombrada de tablas, así como funciones,
operadores, entre otros. Una base de datos puede tener muchos esquemas y los nombres
de las tablas y demás objetos son únicos dentro del esquema. A diferencia del nivel de
base de datos, los esquemas en la misma base de datos son accesibles entre sí, es decir
que un objeto perteneciente a un esquema puede estar relacionado con otro de un
esquema diferente. Los esquemas funcionan como espacios de nombres para agrupar
colecciones de objetos. De acuerdo con la documentación de PostgreSQL (2017)[13], los
esquemas son análogos a los directorios a nivel de sistema operativo, pero sin la
posibilidad de realizar anidación.
● Tablas: De acuerdo a la documentación oficial [14] una tabla en el sistema es como una
tabla en papel, consiste de un número fijo de columnas y un número indeterminado de
filas. que agrupan la información relativa a una entidad particular.
5.5. BASES DE DATOS NO RELACIONALES
El modelo relacional en las bases de datos ha sido el modelo más utilizado por las grandes
empresas a través de los años para el desarrollo de sus aplicaciones debido a su fiabilidad y
consistencia, lo que lo hace la solución tradicional para el almacenamiento de los datos para la
mayoría de aplicaciones. Sin embargo, además de sus ventajas, de acuerdo con acens
whitepapers (2015)[15], a raíz de la aparición de la web 2.0, empezaron a aparecer varios
problemas a la hora de utilizar este modelo, dado que, con el surgimiento de aplicaciones como
Facebook, Twitter, Youtube, entre otras, cualquier usuario puede subir contenido lo que hizo
que el tamaño de los datos creciera exponencialmente.
28
De acuerdo con esto, dado que las bases de datos relacionales se caracterizan por las
transacciones, la integridad de los datos y sus conjuntos de reglas, el principal problema cuando
el tamaño de los datos es muy grande es el rendimiento. La primera solución que adoptaron las
empresas fue escalar añadiendo más máquinas para mejorar el procesamiento, pero muy pronto
se dieron cuenta que esta no era una opción viable, por lo que empezaron a pensar en establecer
un nuevo modelo o estructura de almacenamiento de datos [15].
Es ahí donde aparecen las bases de datos no relacionales, normalmente conocidas bajo el
término de NoSQL(Not Only SQL), según Adam Lith y Jakob Mattsson (2010)[16], Carlo Strozzi
introdujo el término en 1998 para referirse a su base de datos relacional de código abierto que
no ofrecía una interfaz SQL, el término fue re introducido en 2009 para referirse a un conjunto
de base de datos de código abierto y con el tiempo se ha entendido como un nuevo modelo que
se aparta de los conceptos del modelo relacional tradicional.
Características
Algunas de las características generales de las bases de datos NoSQL son las siguientes [16]:
● No utilizan estructuras fijas para el almacenamiento de los datos como las tablas.
● Evitan las operaciones de combinación de relaciones, lo que se conoce normalmente
como Joins.
● Se escalan horizontalmente.
● No utilizan SQL como lenguaje de consultas.
Ventajas
● Escalabilidad horizontal. Este enfoque permite mejorar el rendimiento y el
procesamiento de datos, agregando más nodos al sistema.
● Permite procesar grandes cantidades de datos, dado que utiliza una estructura
distribuida, es una de las principales opciones en el mundo del Big Data.
● Facilidad de uso. Dado que no utilizan SQL como lenguaje de consultas, la
manipulación de los datos es bastante sencilla en la mayoría de los casos.
● No generan cuellos de botella.
29
Tipos de bases de datos NoSQL
Existen distintos tipos de bases de datos no relacionales, entre las principales se encuentran [16]:
● Clave-Valor: Es el modelo NoSQL más popular y más sencillo de este tipo. Se
caracteriza por identificar a cada elemento con una llave única, lo que hace muy rápida
la escritura y lectura de los datos.
Ilustración 7 Base de datos Clave Valor. Recuperado de Acens [15]
● Bases de datos documentales: En este tipo de base de datos se almacena la información
como un documento, normalmente bajo un formato JSON o XML y se identifica cada
documento con una llave única. Son las bases de datos más versátiles y normalmente
se usan como complemento o reemplazo de las bases de datos relacionales. Tienen la
ventaja de ser muy flexibles en la forma en cómo se almacenan los datos, evitan el
desperdicio de espacio dado que no es necesario almacenar todos los campos si estos
no contienen información y brindan facilidad de uso. Por otra parte, su desventaja es
que no garantizan al programador la integridad de los datos.
30
Ilustración 8 Base de datos Documental. Recuperado de Acens [15]
● Bases de datos de grafos: En este tipo de base de datos la información está almacenada
en forma de nodos y sus relaciones se representan mediante aristas, lo que hace que
pueda ser entendido y recorrido utilizando la teoría de grafos [15].
Ilustración 9 Base de datos de grafos. Recuperado de Acens [15]
5.5.1 MONGODB
MongoDB, usualmente conocida simplemente como Mongo, es un sistema de bases de datos
NoSQL de tipo documental de código abierto. De acuerdo a su sitio oficial (2017) [17], mongo
31
está orientada a ser de fácil uso y escalabilidad y puede ser integrada con un amplio número de
lenguajes de programación. Mongo se basa en el formato de documentos JSON ofreciendo una
especificación llamada BSON (Binary JSON).
Dentro de las principales características de Mongo, descritas en su documentación oficial
(2017) [18] se encuentran:
● El modelo del documento se mapea fácilmente a los objetos de la aplicación, lo que
hace fácil la manipulación de los datos.
● Mongo soporta consultas ad-hoc, consultas de búsqueda por campos, rangos y
expresiones regulares. Dichas consultas pueden retornar un campo o una función
JavaScript.
● Cualquier campo de un documento puede ser indexado.
● Se puede escalar horizontalmente utilizando sharding y replicación de manera que la
aplicación pueda seguir funcionando si uno de los nodos falla, mediante balanceo de
carga.
● Tiene amplio soporte para almacenamiento de archivos.
● Proporciona un framework de agregación que se asemeja a las funciones de agregación
que se conocen de SQL.
5.5.2 ELASTICSEARCH
Elasticsearch es un sistema de búsquedas NoSQL distribuido basado en documentos. Provee
un servidor y motor de búsqueda de texto completo mediante una interfaz RESTful a través de
HTTP. De acuerdo a su sitio oficial (2017)[19], permite almacenar, buscar y analizar grandes
volúmenes de datos muy rápidamente y casi en tiempo real. Normalmente es utilizado para
potenciar las aplicaciones que tienen requerimientos de búsquedas muy complejas. Este sistema
está desarrollado en el lenguaje de programación Java y es de código abierto.
Conceptos Básicos
Así como dentro del modelo relacional se encuentran conceptos básicos como tabla, esquema,
índice, entre otros, este sistema maneja una serie de conceptos básicos, descritos en su sitio
oficial (2017) [20], que se explican a continuación:
32
● Near Real Time (NRT): Elasticsearch funciona casi en tiempo real. Esto quiere decir
que aproximadamente un segundo después de que un documento es indexado, está
disponible para ser consultado.
● Clúster: Es un conjunto de uno o más nodos(Servidores) que almacenan y proveen
mecanismos para consultar la totalidad de la información, se identifican mediante un
nombre único que por defecto es “elasticsearch”.
● Nodo: Un nodo es un servidor que hace parte del clúster y que participa en la indexación
y consulta de los documentos. Se identifican con un nombre único en el clúster, lo cual
es importante para propósitos de administración. Un clúster puede tener tantos nodos
como sea necesario e incluso ejecutarse sobre un único nodo.
● Índice: Es una colección de documentos con características similares. Se identifica
mediante su nombre, a través del cual se realizan operaciones de consulta, actualización
y búsqueda. Por ejemplo, un índice puede almacenar la información de los clientes de
la empresa, o de los productos.
● Tipo: Es la forma de referirse a una categoría lógica del índice cuya semántica depende
totalmente del programador. Por ejemplo, si se define un índice de productos, se puede
definir un tipo diferente para los productos originales, y otro para los importados.
● Documento: Es una unidad básica de información que puede ser indexada.
Básicamente, representa cada uno de los ejemplos de los índices que se definen, por
ejemplo, se puede indexar un documento para un producto importado específico. Estos
documentos se expresan mediante notación JSON y se pueden añadir tantos como se
desee.
● Shards y Réplicas: Es el mecanismo que ofrece este sistema para escalar
horizontalmente y de forma distribuida la información. Los shards con subdivisiones o
piezas de un índice que funcionan como un índice independiente y pueden ser
localizados en cualquier nodo del clúster. Además de esto permiten paralelizar las
operaciones con el objetivo de aumentar el rendimiento.
33
5.5.3 REDIS
Redis es una estructura de almacenamiento en memoria de código abierto. Se utiliza
normalmente como base de datos NoSQL clave valor, como caché y como distribuidor de
mensajes, como lo indica su sitio oficial (2017)[21]. Se trata de un servidor de almacenamiento
muy potente dado que almacena la información en memoria principal, por lo cual el acceso a
los datos es muchísimo más rápido. Por esta misma razón no es muy común almacenar grandes
volúmenes de datos en Redis, al contrario, se almacenan datos muy concretos que se consultan
constantemente.
Características
Dentro de las principales características de este sistema se encuentran las siguientes [21]:
● Tipos de datos: Soporta estructuras de datos como strings, diccionarios(hashes), listas,
conjuntos, conjuntos ordenados, índices geoespaciales, mapas de bits, entre otros.
● Operaciones Atómicas: Permite ejecutar operaciones atómicas sobre los datos, como
agregar un elemento a una lista, incrementar el valor de un hash, realizar intersección,
unión y diferencia de conjuntos, entre otras.
● Persistencia de datos: El conjunto de datos que se encuentra en memoria puede ser
persistido a disco duro cada cierto tiempo si es requerido.
● Pub/Sub: Redis implementa el paradigma publish/subscribe, en el que existen
publicadores que envían mensajes a suscriptores específicos conocidos como
recibidores a través de uno o varios canales. Este paradigma es de gran utilidad al
utilizarse como cola de mensajería para comunicar varias aplicaciones entre sí.
● Llaves con tiempo de vida: Redis permite establecer un tiempo de vida para las llaves
que se almacenan en la memoria, de manera que después de una fecha determinada la
llave expire y sea eliminada de la base de datos.
34
5.6. AUTOMATIZACIÓN Y ENCOLAMIENTO DE TAREAS Usualmente en el entorno de las aplicaciones web existen muchas tareas, funcionalidades y
herramientas que se ejecutan mediante interacción directa con los usuarios finales, es decir,
todas las acciones realizadas directamente por el usuario para manipular sus datos y los del
entorno que tiene disponible. Aunque la mayoría del esfuerzo y del trabajo de los
desarrolladores se ve reflejado directamente en las herramientas y funcionalidades que ve el
usuario, existen muchas tareas y procesos que deben ser ejecutados y que al final los usuarios
finales no ven. Usualmente, se trata de tareas que deben llevarse a cabo cada cierto periodo de
tiempo para que el usuario cuente con la información más actualizada posible y que por
cuestiones de rendimiento o usabilidad no es posible ejecutarlas en el mismo instante en que el
usuario está interactuando con el sistema.
Para ello existen dos modelos principales:
1. Automatización: Consiste en programar el sistema cada cierto tiempo para ejecutar
una tarea. Por ejemplo, cada hora actualizar el saldo de una tarjeta de crédito.
2. Encolamiento: Consiste en encolar las tareas y ejecutarlas cuando el sistema esté
disponible para llevarlas a cabo. Por ejemplo, enviar correos de invitación a los
contactos de un usuario que acaba de registrarse.
En el entorno de las aplicaciones de Ruby on Rails y sistemas UNIX, existen varias alternativas
para llevar esto a cabo, a continuación, se abordan dos de ellas.
5.6.1 CRONS
Cron hace referencia a un administrador de procesos de segundo plano que viene integrado en
los sistemas operativos UNIX, conocido también como demonio. Este administrador se basa en
un archivo conocido como crontab, en el cual se especifican línea por línea, una serie de tareas
que deben ser ejecutadas cada cierto intervalo de tiempo.
35
Cron define una sintaxis específica para definir las tareas a ejecutar, y aunque existen diversas
formas de actualizar el crontab, ya sea mediante comandos o herramientas, con un editor de
texto sencillo se pueden actualizar o definir nuevas tareas, Burak Guzel (2010) [22].
La sintaxis para definir una tarea en Cron tiene la siguiente estructura:
Ilustración 10 Sintaxis para definir una tarea en Cron. Recuperado de Envato Tuts. [22]
En la ilustración 10 se puede ver la sintaxis para definir tareas, en la cual, los asteriscos
representan cualquier posible valor que sea válido en una posición determinada, por ejemplo,
la sentencia “0 * * * * clean temporal data” lanzaría una tarea para borrar los archivos
temporales en el minuto 0 de cada hora de cada día del mes, lo cual se entiende más fácilmente
como ‘Cada hora en punto eliminar los archivos temporales’.
Existen varios comodines o caracteres especiales mediante los cuales se pueden programar
tareas cada cierto tiempo, por ejemplo “*/15 * * * *” ejecuta una tarea cada 15 minutos, y otros
mediante los cuales se pueden describir rangos de tiempo.
5.6.2 SIDEKIQ
Sidekiq es un servidor de encolamiento y programación de tareas desarrollado en el lenguaje
de programación Ruby, que cuenta con una gran facilidad de integración con el framework de
desarrollo web Ruby on Rails. Aunque cuenta con algunos productos de pago, Sidekiq es un
proyecto de código abierto mediante el cual se pueden ejecutar procesos en segundo plano,
denominados también workers, como lo indica su sitio oficial (2017)[23], de las siguientes
formas:
36
● Tan pronto como se ejecuta una acción.
● Cierto tiempo después de que se ejecuta una acción.
● Cada cierto intervalo de tiempo.
El primer caso es de gran utilidad cuando, por ejemplo, se va a enviar un email luego de que
un usuario ejecute una acción, de esta manera, en lugar de hacer que el usuario espere la
respuesta del envío, se puede ejecutar esta tarea en segundo plano e informar al usuario cuando
esté terminada.
El segundo caso es útil cuando se quiere ejecutar una tarea que depende de la terminación de
otras tareas de las cuales se conoce su tiempo de ejecución.
Características
● Utiliza hitos para ejecutar varias tareas sobre el mismo proceso.
● Está íntimamente relacionado con Ruby on Rails, de manera que permite hacer uso de
todas sus características y funcionalidades.
● Ofrece una interfaz para implementar un sistema de programación de tareas que se
ejecuten cada cierto intervalo de tiempo. La más utilizada actualmente se llama Sidekiq-
Cron [24], y funciona con una filosofía similar al Cron de UNIX,
● Ofrece una interfaz web para monitorear y administrar las tareas programadas o en
ejecución.
● Utiliza Redis como base de datos para encolar y programar las tareas a ejecutar.
5.7. APIs
Una API se define como una interfaz de programación de aplicaciones [25]. Su principal
característica consiste en encapsular la implementación de un proceso y exponiendo acciones
o información del proceso de acuerdo a la necesidad que la interfaz pretenda suplir. Por lo
general, estas interfaces contienen conjuntos de subrutinas que permiten acceder a ciertas
funciones que generan información o procesos de comunicación entre componentes de la
interfaz para realizar una acción concreta.
37
5.8. REST APIs
Una REST API [26] se define como un API remoto al cual se puede acceder usando el protocolo
HTTP y sus respectivos verbos (GET, POST, PUT, PATCH, DELETE) para ejecutar acciones
sobre los recursos que el API expone. De esta forma y con estos verbos HTTP, la interfaz
provee operaciones CRUD sobre los recursos que se están exponiendo.
5.8.1 OAUTH2 OAuth 2 [27] es un framework de autorización que permite a las aplicaciones obtener acceso
limitado a cuentas de usuario en un servicio HTTP, como Facebook, GitHub, Twitter entre
otros. Funciona delegando la autenticación del usuario en el servicio que aloja la cuenta de
usuario y autoriza que las aplicaciones de terceros accedan a la cuenta de usuario. OAuth 2
proporciona flujos de autorización para aplicaciones web y de escritorio y dispositivos móviles.
5.8.2 FACEBOOK REST API
El API de Facebook, Graph API [28], es la principal forma de acceder o generar información en
la plataforma de Facebook. El nombre del API viene de la idea de un grafo social en el cual la
información es representada siguiendo los conceptos de la teoría de grafos:
● Nodos: Son los vértices del grafo y para el caso práctico, la representación del nodo es
cualquier objeto al cual se pueda acceder como usuarios, publicaciones, páginas,
comentarios, etc. Estos nodos pueden ser de dos tipos: nodos raíz y nodos hoja. Los
nodos raíz pueden accedidos ser accedidos sin una consulta previa mientras que los
nodos hoja dependen de nodos raíz o entre conexiones con nodos hoja.
● Aristas: Son las aristas del grafo razón por la cual representan las conexiones y
relaciones entre los objetos nodo.
● Campos: Los campos son aquellas características o atributos internos de los nodos.
De esta manera se determinaron los siguientes nodos con el fin de asegurar el cumplimiento de
los requerimientos establecidos: Photo, Video, User, Page, Insights.
38
Ilustración 11 Facebook API.
5.8.3 TWITTER REST API
El API de Twitter [29] es el punto de acceso usado para generar u obtener información sobre los
diferentes endpoints que ofrece Twitter.
Dentro de Twitter API, se pueden encontrar diferentes endpoints, ya sean estos públicos o por
demanda, para analizar viralización en tiempo real, histórica o detalles históricos de las
publicaciones orgánicas que se existen en la plataforma e incluso agregar contenidos (Fotos,
vídeos, texto) a la plataforma. Estos endpoints, al ser REST, proveen las acciones CRUD sobre
los diferentes objetos recurso que expone como Status, Users y Trends.
39
Ilustración 12 Twitter API.
5.8.4 GOOGLE REST API
Google API ofrece acceso a muchos de los productos de Google como Drive, Calendar,
AdSense entre otros. Cada uno de estos APIs expone recursos sobre los cuales se pueden
realizar acciones REST. Para el caso de implementación, se tomaron dos endpoints:
● Youtube Data API [30]: Youtube Data provee acceso a información general sobre la
plataforma expuesta a través de recursos. Un recurso representa un elemento de la
plataforma tales como videos, canales, comentarios, usuarios, entre otros.
● Youtube Analytics [31]: Youtube Analytics provee acceso a la generación de reportes
sobre recursos específicos como vídeos y canales. Cada uno de estos reportes se pueden
acotar por alcance, como países sobre los que el vídeo o canal tuvo audiencia, o filtrar
por algún dato en específico que se requiera consultar como la proporción de géneros
que vieron un vídeo en específico o que siguen un canal.
40
Ilustración 13 Google YouTube API.
5.9. AMAZON WEB SERVICES
Amazon Web Services (AWS) es una plataforma que ofrece una colección de servicios de
computación en la nube. Entre los más reconocidos están los servicios de instancias EC2, que
funcionan como servidores, los RDS, que permite distribuir una base de datos en varias
instancias además de protección de la información sensible de la misma y los S3 que permiten
almacenamiento y transferencia de archivos.
Amazon Elastic Compute Cloud (EC2) es una solución escalable en la nube de Amazon Web
Services (AWS). Esta solución permite la escalabilidad al remover la barrera del hardware si
las aplicaciones crecen de acuerdo a las necesidades que se les presenten. EC2 ofrece servidores
virtuales llamados instancias, configuración de la seguridad de las mismas y el almacenamiento
en general, ya sea de archivos o de almacenamiento lógico en bases de datos de cualquier tipo.
Algunas de las ventajas que una instancia de EC2 son:
● Puede crecer en capacidad CPU, memoria, almacenamiento o capacidad de red.
41
● Seguridad por medio del protocolo Secure Shell (SSH) controlando el acceso por medio
de llaves. Una privada, que es almacenada por AWS y una privada que se queda para
el cliente.
● Abierta a la extensión con otros servicios de AWS como Amazon Simple Storage
Service (S3), Amazon Relational Database Service (Amazon RDS) y Amazon Virtual
Private Cloud (Amazon VPC), entre otros.
● Las instancias pueden estar alojadas en diferentes lugares del mundo con el fin de
facilitar acceso, reducir latencia y así poder mejorar tiempos de respuesta.
● Permite la creación de nubes virtuales privadas (Amazon VPC) con el fin de aislar
algunas instancias del ecosistema de la EC2.
5.9.2 RDS Amazon Relational Database Service (Amazon RDS [32]) es un servicio de administración de
bases de datos relacionales dentro de la plataforma EC2. RDS en sí, ofrece compatibilidad con
varios motores actualmente usados, entre ellos Postgresql y Oracle, garantizando así que las
aplicaciones que ya usan alguno de los motores soportados, también funcionen al usar el RDS.
Además de esto el RDS, como ya se dijo, se encarga de todas las labores administrativas sobre
el motor tales como generación de backups, recuperación en caso de caída, detección de errores,
reparación, entre otros.
Algunas de las características del RDS de Amazon son:
● Una de las características más relevante es la mejora en desempeño. Al poder definir
una tasa de operaciones de entrada/salida por segundo para el RDS, se pueden optimizar
la carga que pueden generar acciones de consulta o salvado de datos.
● La facilidad en la escalabilidad ya que, gracias al monitoreo y la mejora de desempeño
explicada en el punto anterior, la escalabilidad del RDS está garantizada. Dependiendo
de las necesidades inmediatas, se puede configurar el RDS para que haga un incremento
en la tasa de entrada/salida o asignar hasta 6 Terabytes de almacenamiento en cuestión
de minutos.
42
● La generación de backups automatizados y que se almacenan por un periodo de tiempo.
A esto se le suma los logs sobre cada una de las transacciones realizadas en cada uno
de los backups.
5.9.3 S3
Amazon Simple Storage Service (S3[33]) es un servicio del EC2, que abre la posibilidad de
almacenar objetos dentro de contenedores o recursos llamados ‘buckets’ que a su vez poseen
características para leer, eliminar o consultar estos objetos en el contenedor.
S3 posee característica como:
● De igual manera que las instancias S2, este servicio también se encuentra distribuido en
diferentes lugares del mundo garantizando de esta manera la accesibilidad a la
información en el bucket.
● En la parte de seguridad, permite cifrar y transferir los datos usando certificados SSL
para luego, dentro del servicio S3, configurar los accesos, administrar los permisos que
ciertos usuarios tienen sobre los objetos almacenados e incluso, la generación de logs
de auditoría para cada una de estas acciones.
● Facilidad de transferencia de datos, desde y hacia, el contenedor S3 mediante el
consumo de sencillos API endpoints.
5.10. SERVIDOR DE APLICACIÓN
Un servidor de aplicaciones [34] es un tipo de servidor diseñado para instalar, operar y hospedar
aplicaciones y servicios asociados para usuarios finales, servicios de TI y organizaciones.
La finalidad de un servidor de aplicaciones es facilitar el alojamiento y la entrega, ejecutar
procesos necesarios para garantizar la fiabilidad de la aplicación y proporcionar acceso al
usuario u otra aplicación cuando utiliza la lógica empresarial / funcional de la aplicación
instalada.
Las características clave requeridas de un servidor de aplicaciones incluyen redundancia de
datos, alta disponibilidad, equilibrio de carga, administración de usuarios, seguridad de datos
de aplicaciones y una interfaz de administración centralizada.
43
Dependiendo de la aplicación instalada, un servidor de aplicaciones puede clasificarse de
diversas maneras, como servidor web, servidor de aplicaciones de base de datos, servidor de
aplicaciones de fines generales o servidor de aplicaciones empresariales (EA).
5.10.1 UNICORN
Unicorn [35] es un servidor HTTP para aplicaciones Rack. Rack es una gema de Ruby que
proporciona una interfaz HTTP mínima entre servidores web que soporta Ruby y Frameworks
de Ruby, en este caso, Rails. Unicorn fue diseñado para servir solo a clientes rápidos en
conexiones de baja latencia y gran ancho de banda y aprovechar las características de los
núcleos tipo Unix / Unix. Los clientes lentos solo se deben servir colocando un proxy inverso
capaz de almacenar en su totalidad tanto la solicitud como la respuesta entre unicornio y
clientes lentos.
Algunas características que Unicorn son:
● Diseñado para Rack, Unix, clientes rápidos y facilidad de depuración. Cortamos todo
lo que es mejor compatible con el sistema operativo, nginx o Rack.
● Compatible con Ruby 1.9.3 y posterior. Unicorn 4.x sigue siendo compatible con los
usuarios de Ruby 1.8.
● Gestión de procesos: Unicorn eliminará y reiniciará los workers que mueren a causa de
fallas en la aplicación evitando así al desarrollador la responsabilidad de administrar
múltiples procesos o puertos. Unicorn puede engendrar y administrar cualquier cantidad
de procesos de trabajo que elija escalar a su backend.
● El balanceo de carga se realiza completamente por el kernel del sistema operativo. Las
solicitudes nunca se acumulan detrás de un proceso de trabajo ocupado.
● Actualizaciones binarias tipo nginx sin perder conexiones, que implica que se puede
actualizar unicorn, la aplicación en sí o las dependencias de la misma e incluso su
intérprete de Ruby sin sufrir de caída.
● Configuración sencilla y rápida a través de un Ruby DSL.
44
5.11. NGINX NGINX [36] es un servidor HTTP gratuito, de código abierto y de alto rendimiento, así como un
servidor proxy IMAP / POP3 con funciones como almacenamiento en caché, equilibrio de
carga, transmisión multimedia y más. Comenzó como un servidor web diseñado para el
máximo rendimiento y estabilidad. Además de las capacidades del servidor HTTP, NGINX
también puede funcionar como un servidor proxy para correo electrónico (IMAP, POP3 y
SMTP) y un proxy inverso y un equilibrador de carga para servidores HTTP, TCP y UDP.
NGINX es conocido por su alto rendimiento, estabilidad, rico conjunto de características,
configuración simple y bajo consumo de recursos.
NGINX es uno de los pocos servidores escritos para resolver el problema C10K (Concurrencia
en múltiples conexiones). A diferencia de los servidores tradicionales, NGINX no depende de
hilos para manejar las solicitudes. En su lugar, utiliza una arquitectura impulsada por eventos
(asíncrona) mucho más escalable. Esta arquitectura utiliza cantidades pequeñas, pero más
importantes, predecibles de memoria bajo carga. Incluso si no espera manejar miles de
solicitudes simultáneas, aún puede beneficiarse de la gran cantidad de memoria de alto
rendimiento de NGINX. NGINX escala en todas las direcciones: desde el VPS más pequeño
hasta los grandes grupos de servidores.
45
6. METODOLOGÍA La Metodología que se utilizó para el desarrollo de proyecto es Scrum, ya que permitió la fácil
adaptación en las etapas de desarrollo del producto, brindando prioridad al cliente mediante las
entregas continuas, por medio de las cuales, se pudo observar un valor agregado en el producto
en cada entrega y en algunos casos sugerir cambios durante el periodo de la iteración, lo que se
reflejó en la satisfacción del cliente y el desarrollo a la medida del producto.
Dada la naturaleza de FLUVIP, empresa que ha crecido como emprendimiento, los cambios
continuos son parte del crecimiento continuo, por lo que, al desarrollar con la metodología ágil,
permite tanto a los clientes internos como externos la posibilidad de ajustar el producto de
manera flexible, permitiendo asegurar las funcionalidades de FLUVIP desde la planificación
de las historias de usuario, el desarrollo de las mismas y las entregas al cliente.
Reconociendo que Scrum es la guía de trabajo en el desarrollo de FLUVIP, realizamos
a continuación una descripción de cómo se implementó dicha metodología con en el proyecto,
no sin antes destacar la importancia de esta metodología ágil y su utilización.
6.1 METODOLOGÍAS ÁGILES
Las metodologías ágiles surgen de la necesidad de desarrollar software de forma rápida,
respondiendo a los cambios que puedan surgir en el desarrollo del mismo, según el manifiesto
ágil creado a mediados de 2001 tras la reunión de 17 expertos en la industria de desarrollo de
software en Utah, EEUU luego nombrada The Agile Alliance, resume la filosofía ágil en
valorar los siguientes aspectos:
“Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
La gente es el principal factor de éxito de un proyecto de software.” [37]
Desarrollar software que funcione más que conseguir una buena documentación. La
documentación es importante mas no debe ser fundamental, si en necesario producir
documentación debe ser corta y centrarse en lo importante.
46
La colaboración con el cliente más que la negociación de un contrato. se propone que exista
interacción entre el cliente y el equipo de desarrollo. esta colaboración entre ambos, será la que
marque la marcha del proyecto y asegure su éxito.
Responder a los cambios más que seguir estrictamente un plan. es de vital importancia la
habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambio de
requisitos, tecnología, equipo, etc.) determina el éxito o fracaso del mismo. Por lo tanto, la
planificación no debe ser estricta sino flexible y abierta al cambio.
6.2 SCRUM
En el marco de las políticas y procesos establecidos al interior de FLUVIP para el área de
tecnología, particularmente para el desarrollo de proyectos de ingeniería de software se tiene
establecido que se use la metodología de desarrollo conocida como Scrum. A continuación, se
describen sus principales directrices y fundamentos:
6.2.1. GENERALIDADES
Scrum en su más alto nivel, es un marco de trabajo de procesos mediante el cual las personas
pueden enfrentar problemas complejos adaptativos. Ya hablando desde el punto de vista de
ingeniería de software, Scrum es una metodología ágil y flexible para gestionar el desarrollo
de software que busca principalmente maximizar el retorno de la inversión para la empresa
(ROI). Se basa en construir prioritariamente la funcionalidad de mayor valor para el cliente y
en los principios de inspección continua, adaptación, innovación y autogestión.
Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control
de riesgo.
47
6.2.2. BASE TEÓRICA DE SCRUM
Scrum se basa en la teoría de control de procesos empírica, es decir, la corriente que asegura
que el conocimiento procede de la experiencia y la toma de decisiones se realiza basándose en
lo que se conoce. “Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto”[38] .
Scrum está soportado en tres pilares de la implementación del control del proceso empírico:
• Transparencia: Los aspectos significativos del proceso deben ser visibles para los
responsables del resultado y debe estar soportado en un entendimiento común, es decir,
que todos los involucrados deben manejar un mismo lenguaje con respecto al proceso.
• Inspección: Los usuarios de Scrum deben inspeccionar constantemente los “artefactos”
de Scrum y el progreso de los objetivos, sin embargo, no debe ser tan frecuente como
para interferir en el trabajo.
• Adaptación: Si un responsable determina que uno o más aspectos de un proceso llevaran
a un resultado de un producto no aceptable, el proceso debe ser ajustado.
Para la inspección y adaptación Scrum prescribe cuatro eventos formales, contenidos dentro
del “Sprint”:
• Reunión de planificación del Sprint
• Scrum Diario
• Revisión del Sprint
• Retrospectiva del Sprint
6.2.3. EL EQUIPO DE SCRUM
El equipo Scrum está conformado por el dueño del producto o Product Owner, el equipo de
desarrollo un Scrum Master. Un equipo Scrum entrega los productos de manera iterativa e
incremental, de esta manera se maximizan las oportunidades de obtener retroalimentación.
48
• Product Owner: Es el responsable de maximizar el valor del producto y del trabajo
realizado por el equipo de desarrollo. Es la única persona responsable de gestionar la
lista del producto y esto implica asegurarse de que esta sea visible, transparente y clara
para todos.
• Equipo de Desarrollo: Son los profesionales encargados de entregar un incremento de
producto “Terminado”, que potencialmente se pueda poner en producción, al final de
cada sprint. Los equipos de desarrollo se caracterizan por ser auto organizados,
multifuncionales, por manejar el mismo título para cada uno de sus integrantes, por no
manejar sub-equipos bajo ninguna circunstancia y entenderse siempre como un todo.
• Scrum Master: Es el responsable de asegurar que el marco de trabajo Scrum es
entendido y adoptado. Es un líder dedicado al servicio del equipo Scrum que ayuda a
las personas externas al equipo Scrum a entender que interacciones externas pueden ser
beneficiosas para el equipo Scrum y cuáles no. Dentro de las funciones de un Scrum
Master están: facilitar los eventos Scrum según se requiera o necesite, guiar al equipo
de desarrollo a ser auto organizado y multifuncional, eliminar impedimentos para el
progreso del equipo de desarrollo, motivar cambios que incrementen la productividad
del Equipo Scrum.
6.2.4. EVENTOS DE SCRUM
En Scrum existen una serie de eventos predefinidos que tienen el fin de incrementar la
regularidad y evitar las reuniones no definidas en el Scrum. Los eventos están contenidos dentro
del Sprint, que es un evento en sí mismo, y cada uno de ellos representa una oportunidad para
inspeccionar algún aspecto o adaptarse a algún cambio. Los siguientes, son los principales
eventos de Scrum[38].
49
Ilustración 14 Información básica de SCRUM. Fuente: Deemer, P., Benefield, G., Larman, C., &Vodde, B. (2009).
Recuperado de https://bitbucket.org/rafa/drupal2/src/90dcc40947a3/PDF/scrumprimer_es.pdf
• Sprint: Es el corazón de Scrum, es un periodo de tiempo de un mes o menos durante el
cual se lleva a cabo un incremento del producto, que es utilizable y potencialmente
desplegable. Es conveniente que la duración de cada Sprint sea regular a lo largo del
desarrollo y cada sprint comienza una vez termina el anterior. Dentro del Sprint se dan
varias reuniones: la reunión de planificación del sprint, los scrums diarios, el periodo
de desarrollo, la revisión del sprint y la retrospectiva del sprint. Durante el sprint no está
permitido realizar cambios que puedan afectar el objetivo principal, pero el alcance
puede ser clarificado a medida que se va aprendiendo más.
Cada sprint puede considerarse como un proyecto con una duración máxima de un mes,
durante el cual se va a lograr algo y se obtendrá un producto o resultado.
• Planificación del Sprint: Es una reunión que se realiza al comienzo de cada sprint,
durante la cual se definen dos aspectos principales: que es lo que se entregará en el
sprint que comienza y como se logrará conseguirlo. Para definir qué es lo que se
entregará en el sprint, el equipo de trabajo y únicamente el equipo de trabajo decide que
50
cosas de la lista de producto estarán terminadas al final del sprint de acuerdo con las
prioridades de la lista.
Luego para definir cómo se logrará llevar a cabo este incremento, el equipo de
desarrollo por lo general empieza realizando el diseño del sistema y definiendo el
trabajo necesario para que la lista de producto se convierta en un producto funcional.
Para el final de la reunión de planificación se ha definido el trabajo suficiente, de manera
que pueda ser descompuesto en unidades de un día o menos.
• Scrum Diario: Es una reunión de 15 minutos que se realiza diariamente con el objetivo
de que el equipo de desarrollo sincronice sus actividades y de a conocer su plan de
trabajo para las próximas 24 horas. Esta reunión se realiza a la misma hora y en el
mismo lugar todos los días y cada miembro del equipo de desarrollo responde las
siguientes 3 preguntas:
o ¿Qué hice ayer que ayudará a alcanzar el objetivo del sprint?
o ¿Qué haré hoy para ayudar a alcanzar el objetivo del sprint?
o ¿Veo algún impedimento o tengo algo que no permita que yo o el equipo de
trabajo logre el objetivo del sprint?
Los scrums diarios ayudan a mejorar la comunicación, eliminan la necesidad de otras
reuniones y permiten identificar si algún miembro del equipo de trabajo tiene algún
bloqueo relativo al desarrollo, además permiten mejorar el nivel de conocimiento de
cada miembro del equipo de desarrollo de las tareas que llevan a cabo los demás
miembros.
• Revisión del Sprint: Al final del sprint se realiza una reunión para realizar una revisión
al incremento y ajustar la lista de producto si es necesario. Dentro de esta reunión se
socializa lo que se hizo durante el sprint por parte del equipo scrum y los interesados.
Durante esta reunión se presentan los siguientes eventos, entre otros:
o El dueño del producto indica que items de la lista de producto han sido
terminados y cuáles no.
51
o El equipo de desarrollo destaca lo que se hizo bien, qué problemas se
presentaron y cómo se resolvieron.
o El equipo de trabajo demuestra el incremento y resuelve dudas al respecto.
o El grupo completo colabora en definir qué debe hacerse a continuación.
• Retrospectiva del Sprint: Es una reunión que representa una oportunidad para el
equipo scrum de hacer una reflexión o inspección a si mismos y proponer un plan de
mejoras. Su objetivo principal consiste en definir los siguientes aspectos:
o Revisar como fue el último sprint en cuanto a relaciones, procesos y
herramientas.
o Identificar cuáles fueron los elementos que salieron bien y las posibles mejoras.
o Determinar un plan de mejoras en cuanto a la forma en que el equipo Scrum
realiza su trabajo.
6.3 IMPLEMENTACIÓN DE LA METODOLOGÍA
Con la metodología SCRUM especificada, se definieron los siguientes lineamientos para llevar
a cabo la implementación:
Roles de Scrum:
• Product Owner: Sebastián Jasminoy.
• Scrum Master: Milena Siachoque.
• Scrum Developers: Jaime David Niño, Jose Luis Díaz.
Los SPRINTS tuvieron una duración de una semana teniendo en cuenta la priorización
realizada previamente en el BACKLOG y los entregables del mismo fueron evaluados el
viernes de la semana del SPRINT. Dentro de cada semana se tuvieron reuniones de SCRUM
DIARIO con una duración de quince minutos con el fin de informar el del avance y los
inconvenientes encontrados.
52
Las retrospectivas de equipo, en las cuales participaron Product Owner, Scrum Master y Scrum
Developers, tuvieron una duración de dos horas y se realizaron cada mes para un total de cuatro
reuniones.
En apoyo a este proceso se utilizó la herramienta web Trello enfocada en la gestión de proyectos
y trabajo colaborativo, facilitando llevar el control del BACKLOG, hitos y SPRINTS del
equipo de desarrollo.
El cronograma de actividades del proyecto se presenta a continuación. Este cronograma se
encuentra segmentado por, las ya definidas, iteraciones semanales, y alimentado por el
BACKLOG definido ya definido por el Product Owner, el Scrum Master y el Scrum Developer
Team.
53
ACTIVIDADES 1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4 1 2 3 4FASE 1: Análisis ArquitecturalAnálisis de Bases de datos relacionales.Análisis de Bases de datos no relacionales.Análisis de Servicios externos.FASE 2: Separación a nivel de BD relacional.Migración de BD en servidor a Amazon RDS.Creación de Modelo de Agencias y Credenciales de Agencia.Diseño e implementación de los casos de prueba asociados con las agencias.Creación del Esquema de FLUVIP y seperación de esquemas a nivel de BD.Aislamiento de aplicaciones externas por agencia. |Actualización del Manual de Usuario.Revisión de calidad (Aislamiento de datos y registro de usuarios por Agencia)FASE 3: Separación a nivel de BD no relacionales.Migración de ElasticSearch y MongoDB a un servidor independiente.Migración de Redis a ElasticCache.Diseño e implementación de casos de prueba de filtros (ElasticSearch).Diseño e implementación de casos de reportes de estadísticas (Mongodb).Creacíón de Indices en ElasticSearch por agencia.Creación de colecciones en MongoDB por agencia. Implementación de tarea de monitoreo de estado de los índices de ES. Actualización del Manual de Usuario.Revisión de calidad (Filtros y reportes de estadísticas).
FASE 4: S3Migración de almacenimiento en servidor a Amazon S3.Diseño de Implementación de casos de prueba ( Aislamiento de archivos por agencia).Creación de contenedores de archivos por agencia.Implementación de tarea de monitoreo del estado de los archivos (Fotos y vídeos).Actualización de trabajos en segundo plano por agencia.
FASE 5: Personalización VisualSeparación del Sitio Público de FLUVIP.Generación de Landing Page personalizado por agencia.Implementación de personalización visual interna de la plataforma. Creación del modelo Contacto Agencia. Personalización de plantillas de correo por agencia.
SEMANA
NoviembreSEMANA
OctubreAgostoSEMANASEMANASEMANA
Julio Septiembre
Ilustración 15 Cronograma del Proyecto
54
7. PROCESO DE DESARROLLO
7.1. FASE DE ANÁLISIS
Inicialmente fue necesario realizar un análisis del estado de la plataforma FLUVIP, destacando
el core de la misma, cómo estaba construida arquitecturalmente y haciendo énfasis en los
elementos importantes que deberían mantenerse en las marcas blancas y definiendo aquellos
que de los cuales se deberían prescindir. En este proceso, estuvieron involucrados, además del
equipo desarrollador, el CTO de FLUVIP y los líderes de proyecto que se definieron la
arquitectura de alto nivel de la aplicación base.
Una vez finalizado este proceso, se realizó una selección de las herramientas para realizar la
implementación de INFLUTECH como White Label, teniendo en cuenta la facilidad en la
creación de nuevos componentes. Por último, se determinó un prototipo funcional inicial el
cual contiene los tiempos y las funcionalidades necesarias para culminar el proyecto.
7.1.1 REVISIÓN DE LA PLATAFORMA FLUVIP
En primer lugar, se determinaron los aspectos principales de la aplicación detallados a
continuación:
7.1.1.1 Tamaño del proyecto
La aplicación Web inicial, se encontraba desarrollada en el lenguaje de programación Ruby,
bajo el Framework Rails. El proyecto contaba inicialmente con 5569 archivos distribuidos de
la siguiente manera:
55
Lenguaje Porcentaje
Ruby 89.6 %
HTML 6.4 %
CSS 2.3 %
JavaScript 1.7 %
Tabla 3 Distribución inicial de los archivos del proyecto.
7.1.1.2 Bases de datos y recursos de almacenamiento.
La aplicación denominada en su momento FLUVIP contaba con varios sistemas de
almacenamiento de información o bases de datos de las que se habló anteriormente. En la
siguiente tabla se hace una breve descripción de cada una de ellas:
Nombre Tipo Descripción
PostgreSQL 9.2 Base de datos relacional
Es el sistema principal de almacenamiento de la aplicación. Contiene información relevante sobre todos los usuarios, cuentas, presupuestos, campañas y estadísticas que se han generado en la plataforma desde su existencia. Inicialmente funcionaba sobre MySQL pero fue migrada a PostgreSQL por limitaciones encontradas.
Elasticsearch 2.3 Base de datos Documental
Es utilizado como motor de búsquedas para realizar filtrado de resultados al momento de buscar influencers y cuentas de redes sociales para la creación de campañas publicitarias. Consiste en un índice de documentos JSON que persisten información únicamente relacionada con las cuentas de redes sociales, se mantiene sincronizada con PostgreSQL.
MongoDB Base de datos Documental
Utilizada para almacenar datos estadísticos provenientes de las redes sociales, relacionados con el desempeño de las campañas lanzadas a través de la plataforma. Consiste en documentos que almacenan información de las interacciones de los usuarios en las publicaciones a través del tiempo, se sincroniza con PostgreSQL.
Redis Base de datos Utilizada para almacenar datos que se consultan
56
Clave Valor constantemente como tasas de cambio entre monedas, estado de vinculación de cuentas, entre otros. Es utilizada principalmente como caché.
Tabla 4 Bases de datos utilizadas en FLUVIP.
En la siguiente figura se puede apreciar la arquitectura física de los sistemas de almacenamiento
utilizados por la aplicación FLUVIP:
Ilustración 16 Arquitectura de almacenamiento inicial.
De acuerdo a lo descrito por la ilustración 16, la arquitectura inicial del sistema demuestra una
aplicación desplegada en una instancia única de EC2, es decir, que tanto el servidor web, como
el servidor de aplicación y los distintos servidores de almacenamiento de datos se encuentran
instalados en la misma máquina.
57
7.1.1.3 Intercomunicación entre aplicaciones.
Teniendo en cuenta el enfoque de la aplicación en el sector del Influencer Marketing a través
de las redes sociales, uno de los puntos importantes a evaluar es el análisis de los mecanismos
que emplea la plataforma para comunicarse con los APIs de las distintas redes sociales.
La aplicación se basaba en la implementación de protocolos para comunicarse con Facebook,
Twitter y Google, específicamente para Youtube. Previo a esto, se realizaba comunicación con
Instagram, pero el API público de la red social fue cerrado por un tiempo no definido desde la
compra de dicha aplicación por parte de Facebook. Además de esto, la aplicación mantenía
comunicación constante con un API interno de una plataforma de análisis social de datos
demográficos y perfilación de cuentas de redes sociales, conocida como Socianalyzr.
Ilustración 17 Protocolos de comunicación con aplicaciones externas
.
De acuerdo a la ilustración 17, la plataforma se conecta con las redes sociales mediante el
protocolo OAuth 2.0, utilizando tokens de acceso para realizar la autenticación de las
peticiones. Dichos tokens se encuentran encriptados y almacenados en la base de datos
principal en PostgreSQL. A excepción del API Graph de Facebook que solo requiere el token
58
de acceso de usuario, todas las conexiones necesitan el id de cliente y su contraseña para validar
las peticiones.
7.1.1.4 Medios de Comunicación con los Usuarios
Con el fin de notificar acciones o eventos en la plataforma a los usuarios, se encontraron los
siguientes canales de comunicación:
Medio de Notificación
Descripción
Mensajes SMS No cuenta con un sistema de este tipo.
Notificaciones Push
Este tipo de notificaciones se da en aplicaciones móviles, pero en el momento FLUVIP no cuenta con una.
Email Envío de emails a través del proveedor Mailchimp, utilizando las tecnologías que provee el módulo ActionMailer del framework Ruby on Rails. Todos los correos tienen diseños y asuntos muy vinculantes al nombre de la empresa.
Notificaciones Web
Cuenta con un sistema básico de notificaciones, mediante mensajes flash, pero no son en tiempo real.
Tabla 5 Medios de comunicación implementados en FLUVIP.
El envío de correos se realiza totalmente a través del proveedor Mailchimp utilizando un
usuario/contraseña en una única aplicación de correo. Es necesario evaluar la cantidad de
correos que se envían mensualmente y determinar si es suficiente la afiliación actual con el
proveedor al momento de agregar nuevas agencias de medios al sistema.
Ilustración 18 Sistema inicial de envío de correo electrónico.
59
La ilustración 18 describe el sistema inicial de envío de correo electrónico, que juega un papel
importante a nivel de personalización de la plataforma para cada una de las marcas blancas.
7.1.1.5 Entorno de pruebas
Inicialmente la aplicación contaba con un sistema automatizado de pruebas mediante el cual se
podía asegurar en cierta medida que las funcionalidades existentes continuarán teniendo el
comportamiento esperado. Este sistema se encontraba implementado sobre la plataforma
Semaphoreci, vinculado de manera directa con el sistema de versionamiento en Github, de
manera que cada nueva funcionalidad (rama) era probada inmediatamente después de ser
subida. Esto es muy importante dado que permite realizar integración continua (Continuous
Integration) y testeo automatizado (Continuous automated testing), lo que da garantías al
momento de realizar cambios en la estructura de la aplicación. Esto fue de gran valor para los
desarrolladores al momento de abordar el problema porque les dio confianza para idear
estrategias y arquitecturas que pudieran soportar el sistema que se iba a implementar.
Ilustración 19 Sistema automatizado de pruebas.
60
La ilustración 19 muestra el ciclo de desarrollo guiado por pruebas mediante el cual los
desarrolladores en FLUVIP integran nuevas funcionalidades al sistema.
De igual manera, se utilizó la herramienta Simplecov para validar el nivel de cobertura de las
pruebas existentes en el sistema. Los resultados iniciales de esta herramienta fueron los
siguientes:
Porcentaje de Cobertura
Número de Archivos Líneas Analizadas Pruebas Ejecutadas
65.21 % 657 32276 2751
Tabla 6 Estado inicial del conjunto de pruebas del sistema.
7.1.1.6 Sitio principal de la aplicación (Home)
El punto de entrada a la aplicación web (Home Page) de FLUVIP consiste de un conjunto de
secciones informativas con datos relacionados con la compañía, el Influencer Marketing, y los
medios mediante los cuales tanto los influencers como las empresas se pueden vincular a la
aplicación y los beneficios que esto trae. Dado que uno de los puntos de la implementación
consiste en brindar a las marcas blancas cierto toque de personalización visual, se identifica se
identifican los siguientes aspectos:
● Implementar un sistema con alto grado de personalización visual para la página de
bienvenida, implica un proceso ingenieril extenso del lado de front-end, que de acuerdo
al estado actual de la aplicación del lado del cliente tomaría mucho más tiempo
desarrollar, por lo cual la principal opción es ofrecer una plantilla estándar que tenga un
nivel básico de personalización.
● Al realizar cambios como el mencionado en el punto anterior, se pierden muchos
elementos de interacción con el usuario y de diseño y estilo del sitio principal de
FLUVIP, así como las secciones relacionadas con el equipo de trabajo, los blogs,
alianzas comerciales, entre otros.
61
La estrategia a ejecutar para este punto será discutida en la siguiente sección.
7.1.1.7 Carga de archivos de los usuarios
Los archivos multimedia cargados por los usuarios o extraídos de las diferentes redes sociales,
son almacenados en la misma instancia EC2 descrita anteriormente, en una carpeta con acceso
a todo público.
Actualmente se identifican los siguientes escenarios de carga de archivos:
● Avatar de usuario.
● Foto de un influencer en su red social.
● Logo de una marca.
● Fotos para agregar a las publicaciones de las campañas.
7.2. FASE DE EVALUACIÓN
Una vez realizado el proceso de análisis interno de la plataforma FLUVIP, de los elementos
que la conforman y de su relación entre sí, se continúa con una fase de evaluación de los
distintos escenarios descritos, en la cual se identificó para cada uno de ellos las posibles
amenazas, su impacto a nivel empresarial y los posibles caminos de solución, para luego llegar
a tomar una decisión o plan de acción a ejecutar.
Cabe destacar, como punto clave de este trabajo, que la forma de ofrecer a cada una de las
marcas blancas un sitio exclusivo para sus tareas, es brindándoles un subdominio único a cada
una de ellas sobre la aplicación web.
Se escogió utilizar un subdominio y no un dominio diferente por cada marca blanca, dado que
cada subdominio nuevo sobre una dirección web es completamente gratuito, a diferencia de los
dominios que sí tienen un costo variable dependiendo de la demanda que tengan.
Adicional a esto, se decidió comprar el dominio web influtech.co para ofrecer INFLUTECH
como un producto impulsado y desarrollado por FLUVIP, pero con un concepto comercial
distinto a la labor realizada por FLUVIP.
62
7.2.1 EVALUACIÓN DE LOS SISTEMAS DE ALMACENAMIENTO
Es uno de los puntos críticos de este trabajo dado que el objetivo principal de este sistema, está
relacionado con garantizar sistemas aislados a cada una de las nuevas marcas blancas. Por este
motivo, se realizó un análisis detallado para cada uno en el cual se tuvo en cuenta los siguientes
aspectos:
● Papel e importancia del sistema de almacenamiento en la aplicación.
● Arquitectura o estructura actual y sus limitaciones.
● Posibles soluciones con sus ventajas y desventajas.
● Plan de acción.
A continuación, se describe cada uno de ellos.
7.2.1.1 PostgreSQL
Representa la fuente de información más importante de la aplicación, ya que contiene la
totalidad de los datos que relacionan a los Influencers con las marcas, a través de los
presupuestos y campañas creadas a través del sistema, además almacena los datos estadísticos
de cada uno de ellos.
Adicional a lo descrito en la sección anterior cabe resaltar los siguientes aspectos sobre el estado
inicial de este sistema:
● Funciona sobre la misma instancia que el servidor de aplicación.
● Tiene un total de 70 tablas.
● Únicamente hace uso del esquema público, lo cual es el comportamiento
predeterminado.
● No existen índices apropiados para algunas tablas y relaciones.
● Se accede a través del ORM ActiveRecord.
● El ORM permite ejecutar comandos de modificación, como agregación o eliminación
de columnas con gran facilidad.
● Los Backups en el entorno de producción se realizan de manera manual.
● El tiempo de ejecución de una petición sencilla desde el cliente a la base de datos es de
aproximadamente 0.8 segundos.
63
Ilustración 20 Modelo de Dominio Inicial FLUVIP
64
La ilustración 20 muestra el modelo de dominio inicial de FLUVIP, en el cual se incluyeron
las entidades más destacadas y sus relaciones, de la cual se resalta la relación inicial de la
cadena entre los usuarios con su país de origen. Los usuarios pueden ser de tipo Influencer o
Advertiser (marca) y ambos se relacionan a través de SocialNetworkAccount (cuentas de redes
sociales) incluidas en Budget (presupuestos) y Campaign (campañas).
Problemas a resolver
● Garantizar que la información esté aislada y sólo sea accesible para la agencia que
utilice esta información.
● Automatiza el proceso de cambios a la base de datos. Cuando se agrega o elimina una
tabla o columna, el cambio debe ser visible para todas las marcas blancas.
● Facilitar el proceso de BackUp para cada agencia.
● Se debe garantizar un tiempo de respuesta aceptable.
Posibles Soluciones
A. Realizar el encapsulado de los datos con respecto a su marca blanca, a través de
sentencias SQL, creando una nueva entidad que se relacione con los usuarios.
Ventajas Desventajas
Permite hacer un mejor manejo del pool de conexiones.
Aumenta en gran volumen los tiempos de desarrollo, dado que implica realizar un filtro adicional, mediante sentencias SQL, a cada nueva funcionalidad de la aplicación.
Mejora la administración que realiza PostgreSQL dado que no aumenta el número de tablas.
Al aumentar la complejidad de las sentencias, y el número de tablas que se consultan a la vez, disminuye el desempeño.
Las migraciones son fáciles de ejecutar, ya que solo hay un esquema.
A medida que se añaden nuevas marcas blancas, las tablas tienden a tener varios millones de registros, lo que causa problemas de desempeño y de mantenimiento.
Dado un caso particular, no permite realizar migraciones a una marca blanca en particular.
65
Implica realizar desarrollos adicionales para poder realizar un Backup únicamente con los datos relacionados a una marca blanca.
Tabla 7 Ventajas y desventajas de utilizar un solo esquema de PostgreSQL
B. Utilizar el esquema público de PostgreSQL como una plantilla o esqueleto de la base
de datos, y crear nuevos esquemas a partir de él para cada marca blanca.
Ventajas Desventajas
Se ajusta al modelo de “Número controlado de marcas blancas con grandes cantidades de datos”
Es necesario aumentar la cantidad y eficiencia del pool de conexiones.
El número de tablas actual de la aplicación es lo suficientemente pequeño, lo cual hace viable la duplicación de tablas por esquema.
Hay que tener en cuenta el caché generado por algunos ORM cuando se realizan consultas, para evitar resultados inesperados.
Permite dado el caso, personalizar el esquema a una marca blanca en particular.
Aumenta la cantidad de recursos(espacio en disco) requeridos para administrar la base de datos.
Permite realizar Backups exclusivos por marca blanca/esquema sin necesidad de desarrollos adicionales.
Es necesario encontrar una estrategia, para automatizar las migraciones a la base de datos.
Permite administrar los recursos diferencialmente a cada marca blanca.
Tabla 8 Ventajas y desventajas de usar múltiples esquemas en PostgreSQL.
Plan de Acción
Luego de evaluar las opciones disponibles, se escoge la opción B de múltiples esquemas, ya
que es la que más se acerca a solucionar los problemas descritos anteriormente, y se perfila
como la opción mejor mantenible a largo plazo. Para garantizar que se cumplen todos los
requerimientos se deben cumplir los siguientes puntos.
66
● Crear una nueva entidad “Agency” sobre el esquema público de la base de datos, para
almacenar los datos relacionados con cada marca blanca. Dicha entidad no existirá en
ninguno de los esquemas particulares.
● Para garantizar la mantenibilidad de la aplicación, FLUVIP pasará a ser una marca
blanca de la plataforma INFLUTECH, por lo cual se creará un nuevo esquema y se hará
una migración de los datos, y el esquema público será una plantilla para crear las nuevas
marcas blancas.
● Para agilizar las tareas, se debe crear un mecanismo que automatice las migraciones a
la base de datos.
● Para garantizar la confiabilidad de los datos, se debe utilizar un mecanismo que ignore
el cache generado por ActiveRecord en caso de que sea necesario.
● Para garantizar un rendimiento aceptable y una buena administración de los recursos de
PostgreSQL, se moverá el motor de base de datos de la instancia EC2 en la que se
encuentra actualmente, a una instancia RDS de Amazon, que realiza de manera
automatizada los procesos de administración y copias de seguridad.
Ejecución
La ilustración 21 muestra la arquitectura interna del motor de base de datos relacional, luego
de realizar la separación por esquemas. El flujo definido consiste en cambiar el esquema al que
apunta la aplicación en cada petición, que por defecto es “public”, a un esquema propio de cada
una de las marcas blancas, utilizando como medio de acceso el subdominio que proviene de los
encabezados HTTP. La forma de realizar esto, es cambiando el “search_path” de PostgreSQL,
de manera que se pueda acceder simultáneamente a varios esquemas, el orden en el que se
nombran establece la prioridad de búsqueda sobre el esquema, es decir que, si una tabla no se
encuentra en el primer esquema, se realiza una búsqueda sobre el segundo y así sucesivamente.
67
Ilustración 21 Nueva Arquitectura interna de la base de datos relacional.
.
Además de realizar la separación de la base de datos por esquemas, se realizó la migración de
la base de datos un RDS de Amazon, como se muestra en la ilustración 22.
Ilustración 22 Arquitectura Física de la plataforma utilizando un RDS.
68
De esta manera, es posible automatizar y garantizar el proceso de creación de backups, y se
establece un balanceo de carga para el motor de base de datos, lo que implica por consiguiente
disminuir el nivel de carga de la instancia EC2 que contiene la aplicación web INFLUTECH.
Por otra parte, con el fin de automatizar el proceso de cambios o migraciones a la base de datos,
por ejemplo agregación o eliminación de tablas o columnas, se hizo una modificación sobre la
tarea administrativa que viene previamente establecida en el framework Ruby on Rails,
conocida como ‘db:migrate’, que se encarga de ejecutar las migraciones pendientes en base a
una carpeta de archivos ruby.
De esta manera se hizo un enhancement (mejora) sobre la tarea, con el fin de que cada
migración sea ejecutada inicialmente en el esquema público, como es el comportamiento
predeterminado, y además sea ejecutada en cada uno de los esquemas existentes, siempre y
cuando la migración sobre el esquema público haya sido exitosa. Así, se garantiza que todas
las marcas blancas tengan un modelo de datos actualizado, y que si una nueva marca blanca es
creada tendrá también un esquema actualizado, la ilustración 23 muestra este escenario.
Ilustración 23 Automatización de migraciones mediante tareas administrativas.
Finalmente, con el fin de evitar resultados inesperados debido al caché que utiliza el ORM del
framework de desarrollo, se estableció un paso previo en los procesos que involucran realizar
iteraciones a través de los esquemas de la base de datos, en el cual dichos procesos son
encapsulados en un ambiente que no utiliza caché para la base de datos, como se ilustra en la
ilustración 24.
69
Ilustración 24 Manejo de cache con el ORM.
7.2.1.2. Elasticsearch
Una de las características de INFLUTECH que debe estar abierta a la extensión, a la vez que
garantice su aislamiento, es la indexación de documentos usados en las búsquedas de
influencers por agencia. Estos documentos poseen la información necesaria para realizar
búsquedas por ciertos parámetros al momento de iniciar un proceso de creación de campaña.
La separación es de vital importancia ya que cada uno de los documentos debe estar disponible
para ser indexado y encontrado encapsulando dicha información para que sólo sea visible para
la agencia a la pertenece el documento, por lo cual se hace necesario que cada una de las
agencias posea un nodo donde almacenar sus documentos con el fin de garantizar el flujo de
negocio de cada agencia (Precios de los influenciadores, credenciales de sus cuentas, entre
otros). Por este motivo, es importante resolver la necesidad de tomar una decisión que permita
separar, monitorear y administrar los nodos correspondientes a cada marca blanca. Teniendo
en cuenta esto se define lo siguiente:
70
Problemas a resolver
● Garantizar el aislamiento de los documentos propios de cada marca blanca.
● Implementar un método de monitoreo de la base de datos documental de las agencias
clientes.
Posibles soluciones
A. Indexar un campo extra en cada documento haciendo referencia a la marca blanca.
Ventajas Desventajas
El desarrollo sólo requiere un campo más en el documento, la actualización del esquema y una tarea de indexación.
Se generará un supernodo que aunque puede ser escalable, eventualmente será muy difícil de mantener.
Envío de parámetros de agencia siempre que se desee buscar algún documento.
Tabla 9 Ventajas y desventajas de usar un único índice de Elasticsearch.
B. Generar nodos escalables para cada agencia que tendrá cada uno sólo los documentos
respectivos a la misma.
Ventajas Desventajas
Se garantiza el aislamiento de los documentos en cada agencia.
Se requiere una tarea que detecte los cambios y actualice el esquema y los documentos de todos los nodos.
Permite el mantenimiento y soporte de los documentos de cada agencia por separado, sin afectar a los demás clientes.
Tabla 10 Ventajas y desventajas de usar múltiples índices de Elasticsearch.
Plan de acción
● Definir un estándar para nombrar los nodos que se le darán a cada agencia.
● Indexar los documentos en cada uno de los nodos.
71
● Implementar una tarea que revise el estado de los nodos y notifique el estado de cada
uno para realizar mantenimientos y actualizaciones de los esquemas.
Ejecución
La solución adoptada fue la opción B para la cual, luego de definir el estándar de nombramiento
para los nodos, se crearon y se actualizaron los documentos en cada nodo y se realizó una nueva
indexación para garantizar la consistencia de los documentos antiguos con el nuevo esquema
de documento.
Ilustración 25 Generación de nodos por agencia.
Finalmente se implementó una tarea recurrente que verifica el estado de los nodos por cliente
y se encarga de actualizarlos cada vez que un cambio se realiza.
7.2.1.3. MongoDB
INFLUTECH, al ser una plataforma que recibe y maneja información de diferentes fuentes
(Twitter, Facebook, Google) requiere poder almacenar y analizar esta información que, en el
72
caso de algunos proveedores, se recibe en tiempo real. Esto presenta un problema ya que el
proceso de análisis y actualización de esa información puede llegar a ser muy costoso en
términos de rendimiento si esta debe ser analizada varias veces en un periodo corto de tiempo.
Teniendo en cuenta esto se define lo siguiente:
Problemas a resolver
.
● Implementar una solución de almacenamiento para almacenar la información recibida
de los servicios que permita su análisis posterior.
Posibles soluciones
A. Implementar una base de MongoDB por agencia para almacenar la información
concerniente a la misma.
Ventajas Desventajas
Se puede aislar la información de los proveedores que sólo corresponda a la agencia.
Se debe crear una base de datos en MongoDB y mantenerla cada vez que una agencia nueva entra en funcionamiento.
Se requiere un paso intermedio para generar la conexión a la base de datos en MongoDB de la agencia.
Tabla 11 Ventajas y desventajas de usar múltiples bases de datos de MongoDB.
B. Implementar una base de MongoDB donde se almacene indistintamente de la agencia.
Ventajas Desventajas
Se requiere sólo una base de Mongo para el almacenamiento.
No existe separación real entre los documentos de cada agencia.
Facilita la búsqueda ya que sólo existe una única base de datos.
73
Agiliza la búsqueda al almacenar el ID único
de la respuesta del proveedor
Tabla 12 Ventajas y desventajas de usar una única base de datos de MongoDB.
Plan de acción
● Generar una tarea de reestructuración y almacenamiento para la información que llega
de los proveedores.
Ejecución
La opción elegida es la opción B. Para esto se generó una tarea que se recibe la información en
tiempo real y la almacena en la base de datos siendo la llave, el ID de la publicación en la red
social.
Ilustración 26 MongoDB para agencias.
7.2.1.4. Redis
Algunos de los proveedores principales de información para INFLUTECH cuentan con
restricciones de uso para evitar sobrecargas sobre su plataforma y regular comportamiento
74
sospechoso o en contra de sus políticas de uso. Esto crea la oportunidad de generar un registro
de información que no es necesario persistir, a largo plazo, que se hagan a los diferentes
servicios (Como Twitter o los servicios de conversión de moneda) por un lapso donde esta
información sea válida.
Problemas a resolver
.
● Implementar una solución de almacenamiento temporal en Redis con el fin de
almacenar información que cambia constantemente, como tasas de cambio y estado de
los permisos que tienen las cuentas registradas.
Posibles soluciones
A. Implementar una base de Redis por agencia.
Ventajas Desventajas
Se puede aislar la información sensible por agencia como estado de los permisos que se tienen sobre las cuentas.
Redis sólo permite a creación de 10 bases de datos.
Tabla 13 Ventajas y desventajas de una base de Redis por agencia.
B. Utilizar AWS ElasticCache.
Ventajas Desventajas
Se puede aislar por la información en un nodo único para cada agencia.
Implicaciones básicas de costos al ser un servicio nuevo.
El servicio es auto escalable y se restaura en caso de fallos.
Tabla 14 Ventajas y desventajas de usar AWS ElasticCache.
75
Plan de acción
● Persistir en AWS ElasticCache Redis la información cada vez que se consulten estados de los permisos.
Ejecución
Al momento de realizarse una petición de estado de permisos o de tasas de cambio entre divisas,
se busca el registro y de no ser encontrado se crea. Se delega todo al servicio quien está
encargado de vencer registros cada cierto tiempo, dependiendo de si es un permiso o una tasa
de cambio.
7.2.2. EVALUACIÓN DE LA INTERCOMUNICACIÓN ENTRE APLICACIONES
Constituye otro de los puntos clave de este trabajo debido a que el core a nivel de negocio de FLUVIP como empresa, está dado por su interacción con las aplicaciones de las redes sociales. El hecho de que este proceso haya sido automatizado anteriormente, es lo que diferencia y da un punto a favor a FLUVIP con respecto de su competencia en el marco del marketing de influencia. A continuación, se resaltan algunos puntos importantes con respecto a este proceso:
● Existe un único cliente de aplicación por red social, creado para comunicarse con su correspondiente aplicación.
● La comunicación se realiza a través de gemas (componentes), creados por la comunidad
y son de código abierto.
● La configuración de los clientes se realiza una única vez justo después de iniciada la aplicación web.
● Las credenciales se cargan a partir variables de entorno del sistema, no son incluidas en
el control de cambios por motivos de seguridad.
● Cada cliente tiene configurado un único punto o endpoint de retorno, también conocido como callback.
● Las pantallas (vistas) de autorización que se muestran al usuario, están personalizadas
visualmente con el logo, sitio url y nombre de FLUVIP.
76
Problemas a resolver
● Las pantallas (vistas) de autorización que se muestran al usuario, no deben mostrar ningún tipo de relación directa con FLUVIP.
● Los usuarios deben poder ser re-direccionados a su correspondiente sitio, por ejemplo,
los usuarios registrados en una marca blanca “mywhitelabel” deben ser re-direccionados exitosamente a “mywhitelabel.influtech.co”.
● Se debe garantizar el aislamiento de los usuarios y credenciales otorgadas por las
aplicaciones de las redes sociales, de manera que, si un usuario está registrado en más de una marca blanca, sus acciones y el vencimiento o garantía de sus permisos sea independiente entre cada marca blanca.
● Se debe asegurar que, si una marca blanca infringe por algún motivo los términos de
uso de las aplicaciones de las redes sociales, el resto de las marcas blancas no va a verse afectada.
Posibles Soluciones
A. Utilizar las mismas aplicaciones ya existentes para todas las marcas blancas que se inscriban, incluyendo a FLUVIP, eliminando la personalización visual de FLUVIP y ofreciendo una personalización a nivel de aplicación INFLUTECH.
Ventajas Desventajas
Dado que los sistemas de comunicación entre FLUVIP y el resto de aplicaciones ya está establecido, no requiere realizar ningún desarrollo adicional.
A medida que crezca el número de marcas blancas inscritas, será más fácil alcanzar los límites de peticiones por minuto establecidos por las redes sociales para el consumo de sus APIs.
Se ahorra el tiempo de configuración que necesita cada uno de los clientes de los APIs de las redes sociales.
No se aseguran varios de los puntos anteriormente, relacionados con el aislamiento de las credenciales otorgadas por los usuarios.
No es posible brindar personalización a nivel visual.
Tabla 15 Ventajas y desventajas de usar un conjunto único de clientes de aplicaciones de redes sociales.
B. Utilizar las aplicaciones existentes únicamente para la marca blanca FLUVIP, y crear una nueva aplicación por cada marca blanca que se inscriba en INFLUTECH.
77
Ventajas Desventajas
Permite garantizar totalmente los puntos descritos anteriormente, relacionados con las credenciales otorgadas por usuarios, y los términos de uso de las aplicaciones.
Implica realizar un desarrollo de un componente adicional, que permita cambiar el cliente de aplicación en tiempo de ejecución para cada marca blanca.
Permite un mayor control y manejo de los límites de peticiones establecidos por las aplicaciones.
Implica tiempos adicionales de configuración de los clientes de los APIs.
Permite escalar horizontalmente con gran facilidad.
Tabla 16 Ventajas y desventajas de usar varios conjuntos de clientes de aplicaciones de redes sociales.
Plan de Acción Luego de evaluar las opciones disponibles, se escoge la opción B de crear una aplicación por
cada marca blanca, ya que es la que más se acerca a solucionar los problemas descritos
anteriormente, y se perfila como la opción mejor mantenible a largo plazo. Para garantizar que
se cumplen todos los requerimientos se deben cumplir los siguientes puntos:
● Implementar un mecanismo de almacenamiento de forma segura, que permita guardar
las credenciales correspondientes a cada marca blanca para cada cliente de API de red
social.
● Implementar un proceso que permita realizar cambios entre aplicaciones, en tiempo de
ejecución, sobre las librerías y/o componentes sobre los que actualmente funciona
INFLUTECH, relacionados con la comunicación con las redes sociales.
Ejecución
Con el fin de poder almacenar las credenciales de aplicación que brindan las redes sociales
luego de crear un cliente para consumir sus APIs, se crea una nueva entidad en la base de datos
llamada “ApplicationCredentials”, únicamente en el esquema público de la base de datos,
directamente relacionada con la entidad “Agencies”, la ilustración 27 ilustra este escenario.
78
Dado que cada red social, genera tipos y cantidades diferentes de credenciales para sus
aplicaciones, se opta por almacenar las credenciales en un campo de tipo “jsonb”, en el cual
cada credencial se almacena utilizando doble encriptado para garantizar la seguridad de los
datos.
Ilustración 27 Almacenamiento de credenciales en base de datos.
Además de esto, luego de revisar la documentación y código fuente del componente encargado
de realizar la autenticación y comunicación con los APIs de las redes sociales, conocido como
“Omniauth”, se identifica que en los tres casos (Facebook, Twitter y Youtube) es posible
establecer una fase de configuración (setup phase), utilizando objetos lambda (funciones
almacenadas en memoria), para modificar los parámetros de la comunicación durante cada
petición. Teniendo en cuenta esto, se realiza la configuración del componente teniendo en
cuenta los siguientes parámetros:
Parámetro Descripción Fase Frecuencia
scope Utilizado para indicarle al API, que permisos se van a solicitar al usuario.
Inicio de la aplicación web.
Solo una vez
79
image_size Utilizado para indicar el tamaño de la pantalla de autorización.
Inicio de la aplicación web.
Solo una vez
authorize_url Utilizado para establecer la url de autorización de la red social
Inicio de la aplicación web.
Solo una vez
callback url Utilizado para indicar al API, a que endpoint debe re direccionar al usuario, una vez otorgue los permisos.
Fase de configuración.
Una vez por cada petición.
credentials Utilizado para enviar las credenciales del cliente del API que se utiliza para crear la conexión, contiene varios parámetros como CLIENT_ID, CLIENT_SECRET, entre otros dependiendo de la red social.
Fase de configuración.
Una vez por cada petición.
Tabla 17 Parámetros de configuración de clientes de aplicación de redes sociales
La figura 28 muestra el esquema de comunicación de la aplicación INFLUTECH con el resto
de APIs de las redes sociales.
80
Ilustración 28 Esquema de comunicación con redes sociales usando la fase de configuración.
81
7.2.3. EVALUACIÓN DE LOS MEDIOS DE COMUNICACIÓN CON LOS USUARIOS
Como se describió anteriormente, la aplicación web no cuenta con tantos canales de
comunicación con los usuarios, particularmente el medio principal de comunicación es a través
de correo electrónico. Inicialmente se identificó un sistema estático con la identidad de la marca
FLUVIP, que es necesario modificar para garantizar lo siguiente:
Problemas a resolver
● Brindar un nivel básico de personalización visual con la identidad de la marca
correspondiente a cada marca blanca, es decir, permitir a las marcas blancas enviar
correos informativos con su logo, canales de atención y sitios particulares como redes
sociales y páginas web.
● Enviar los correos desde una dirección de correo electrónico asociativa con cada marca
blanca.
● Configurar las direcciones de correo electrónico correspondientes a cada una de las
áreas de cada marca blanca (operaciones, soporte, comercial).
Posibles Soluciones
A. Adaptar el componente ActionMailer para establecer una fase de configuración
dinámica (en tiempo de ejecución) que permita personalizar los correos con una
identidad de marca distinta por petición.
Plan de acción
● Implementar un mecanismo de almacenamiento que permita persistir las
configuraciones establecidas para el sistema de envío de correos de cada marca blanca.
● Implementar una fase de configuración (setup phase) que permita cambiar
dinámicamente dichos parámetros de envío de correo electrónico.
82
Ejecución
Con el fin de poder almacenar los parámetros de configuración de correo electrónico para cada
marca blanca, se crea una nueva entidad en la base de datos llamada” AgencyContacts”,
únicamente en el esquema público de la base de datos, directamente relacionada con la entidad
“Agencies”, la ilustración 29 muestra este escenario.
Ilustración 29 Almacenamiento de configuración de correo en base de datos.
Una vez almacenada la configuración de correo electrónico por cada marca blanca, se
implementa una fase de configuración dinámica, ubicada entre la inicialización del componente
de correos (ActionMailer) y el proceso de entrega (deliver) del correo como tal. Para ello se
establece como punto de entrada el subdominio, mediante el cual se carga la configuración
previamente almacenada en base de datos, este proceso se ilustra en la ilustración 30.
83
Ilustración 30 Personalización de correo electrónico con identidad de una marca blanca.
84
7.2.4. EVALUACIÓN DEL ENTORNO DE PRUEBAS
Uno de los puntos a destacar en el proceso de desarrollo de este nuevo sistema, es que dadas
las directrices del equipo de tecnología, toda la implementación se realizó bajo los lineamientos
de TDD (Test Driven Development o Desarrollo guiado por pruebas), es decir, que los casos
de prueba son diseñados y escritos antes de empezar la implementación de cada uno de los
componentes. Teniendo en cuenta esto y lo descrito anteriormente sobre el estado inicial del
entorno de pruebas, se diseñaron casos de prueba para todos los componentes anteriormente
descritos, y se agregaron casos de prueba para algunas partes de la plataforma que no contaban
con cobertura total, entre ellas se destacan:
● Actualización de publicaciones de redes sociales.
● Vinculación de cuentas de redes sociales.
● Modificación del estado de las campañas.
● Unificación de perfiles.
● Creación de campañas a partir de presupuestos.
Con respecto a las pruebas diseñadas para los componentes descritos, se tuvieron en cuenta dos
escenarios:
A. La funcionalidad a probar debe verificar en su totalidad el aislamiento de los datos entre
dos o más marcas blancas, en cuyo caso se realiza el flujo completo creando cada uno
de los esquemas correspondientes en la base de datos e índices en elasticsearch,
verificando el escenario completo. Un ejemplo de esto son los reportes estadísticos de
las campañas ejecutadas, que deben reflejar los datos correspondientes a cada marca
blanca.
B. La funcionalidad a probar no debe verificar aislamiento entre los datos, sino un
comportamiento particular de un componente que es independiente de la marca blanca,
en cuyo caso se realiza una simulación del escenario utilizando el esquema público por
defecto, para agilizar los tiempos de ejecución de las pruebas. Un ejemplo de esto son
los componentes de cálculo de fórmulas relacionadas con alcance, engagement y datos
demográficos de las redes sociales.
85
7.2.5. EVALUACIÓN DEL SITIO PRINCIPAL DE LA APLICACIÓN
Como se explicó anteriormente, la aplicación web de FLUVIP tiene un sitio principal (Home)
muy bien estructurado desde la perspectiva del diseño y de la información que ofrece, y
constituye el punto de entrada y la presentación principal hacia los clientes (y/o usuarios)
potenciales, resaltando los grandes beneficios de trabajar con FLUVIP, tanto siendo influencer
como siendo marca. Por otra parte, también se mencionó que dentro de los objetivos de este
trabajo se encuentra ofrecer a las marcas blancas cierto grado de personalización visual, lo cual
incluye un landing (Home) principal adaptado a la identidad de cada marca. Por esta razón,
para garantizar que estos dos puntos se cumplan a cabalidad se determinó lo siguiente:
Plan de acción
● Mover/migrar el sitio principal de FLUVIP a una aplicación web diferente sobre la
misma instancia EC2, que funcione de manera estática y que sea independiente del
desarrollo de cada marca blanca. Esto incluye todas las vistas/pantallas de la aplicación
que no requieren que el usuario esté autenticado.
● Conectar la nueva aplicación, conocida desde ahora como Sitio Público de FLUVIP,
con la aplicación INFLUTECH mediante un enlace que re direccione al módulo de
autenticación.
● Modificar y adaptar la configuración del servidor web (Nginx) para que re direccione
las peticiones a las aplicaciones Sitio Publico de FLUVIP e INFLUTECH, tomando
como base el dominio de la dirección web.
● Implementar un sitio principal (Home) compartido entre las marcas blancas, que esté
personalizado con la identidad de cada marca.
Ejecución
Como primer paso se creó una nueva aplicación con Ruby on Rails, en la cual se copiaron todos
los módulos relacionados con el sitio principal de FLUVIP y se eliminaron de la aplicación
INFLUTECH. Luego se implementó el nuevo Home para INFLUTECH, en el cual se permite
a las marcas blancas personalizar su logo, slogan, background y nombre, así como algunos
86
colores. Adicional a esto se adaptó toda la plataforma para tomar la identidad correspondiente
a cada marca blanca.
Ilustración 31 Separación de INFLUTECH del Sitio Público de FLUVIP.
La ilustración 31 muestra la estructura de comunicación entre el servidor web y los servidores
de aplicación que exponen a INFLUTECH y al Sitio Público de FLUVIP. Para llegar a esto se
establecieron reglas en el servidor web utilizando expresiones regulares, con el fin de re-
direccionar el tráfico generado por los usuarios a las aplicaciones correspondientes.
7.2.6. EVALUACIÓN DE LA CARGA DE ARCHIVOS DE LOS USUARIOS
Otro punto importante a evaluar es la carga de archivos multimedia por parte de los usuarios
de la aplicación. Esto es relevante en cuanto a la capacidad de almacenamiento de la instancia
EC2 en la que se encuentra la aplicación, dado que la estrategia inicial de almacenamiento es
el mecanismo por defecto que ofrece Ruby on Rails, que consiste en almacenarlos en un
directorio ubicado en la raíz del proyecto. Por este motivo, al incrementar el número de usuarios
por cada marca blanca, se reducirá la capacidad de almacenamiento del servidor, lo que hará
87
más lentas las operaciones de lectura/escritura y se verá reflejado en los tiempos de respuesta
al usuario. Teniendo en cuenta esto se define lo siguiente:
Problemas a resolver
● Garantizar el aislamiento de los archivos multimedia propios de cada marca blanca.
● Garantizar que el rendimiento del servidor no se vea afectado al incrementar el número
de usuarios y de archivos multimedia.
Posibles soluciones
A. Aumentar la capacidad de almacenamiento de la instancia EC2 a medida que aumente
el espacio ocupado por los archivos multimedia, y separarlos físicamente mediante
directorios para cada marca blanca.
Ventajas Desventajas
No requiere hacer ningún desarrollo adicional.
No permite escalar horizontalmente las instancias de servidores de aplicación en caso de ser necesario.
Se puede acceder a los archivos directamente.
Es un proceso que no se puede automatizar por lo que puede generar graves errores en la aplicación.
Requiere reiniciar el servidor, lo cual da un tiempo de aproximadamente 10 a 15 minutos de no disponibilidad.
Es inviable económicamente, dado que aumenta la cuota por procesamiento sin que necesariamente se use.
Tabla 18 . Ventajas y desventajas de servir los archivos estáticos desde el servidor de aplicación.
B. Mover los archivos multimedia a una instancia S3(bucket) de Amazon, y separar los
archivos físicamente mediante directorios para cada marca blanca.
88
Ventajas Desventajas
Este tipo de instancias (S3) están específicamente diseñadas para el objetivo de almacenar archivos estáticos.
Requiere realizar un desarrollo adicional para conectar las instancias EC2 y S3.
Permite escalar horizontalmente los servidores de aplicación si es necesario.
No se tiene acceso directo a los archivos más que por la interfaz gráfica o por un cliente de aplicación de Amazon.
Reduce los costos generados por la instancia EC2.
Permite replicar los archivos de manera que se maneja una alta disponibilidad.
Su capacidad de almacenamiento aumenta automáticamente según sea necesario.
Tabla 19 . Ventajas y desventajas de servir los archivos estáticos desde un bucket en una instancia S3.
.
Plan de acción
● Crear la instancia de S3 de Amazon.
● Mover los archivos existentes al bucket.
● Implementar un mecanismo de comunicación entre el servidor de aplicación y el bucket.
Ejecución
Luego de crear la instancia S3 y un bucket para los archivos multimedia de INFLUTECH, se
realizó la comunicación entre la aplicación y el bucket utilizando las credenciales que provee
Amazon mediante la librería Carrierwave, disponible como código abierto para integrarse con
el framework Ruby on Rails, la ilustración 32 demuestra este escenario.
Finalmente se realizó la migración de los archivos utilizando un cliente API de Amazon web
services, proceso que tomó aproximadamente 3 días con un peso total de 89 GB.
89
Ilustración 32 Integración de INFLUTECH con archivos multimedia en instancia S3.
90
8. RESULTADOS
Luego de diseñar, evaluar e implementar el sistema anteriormente descrito, es muy importante
hacer una revisión de los resultados obtenidos hasta el momento y hacer una comparación entre
el estado inicial y final de la plataforma para medir el impacto que ha tenido este proyecto a
nivel comercial e ingenieril.
8.1. CREAR UN MODELO ARQUITÉCTONICO QUE GARANTICE UN SISTEMA
AISLADO PARA CADA MARCA BLANCA.
8.1.1 ARQUITECTURA FÍSICA FINAL
A lo largo del proyecto se realizaron cambios en la estructura base del sistema a nivel físico,
que son bastante destacables ya que modificaron en gran medida la arquitectura global del
sistema. Dentro de estos cambios se destacan:
● Creación de un RDS de Amazon y migración de la base de datos a esta nueva instancia.
● Creación de un S3 de Amazon y migración de los archivos multimedia a esta nueva
instancia.
● Separación de las aplicaciones INFLUTECH y Sitio Público de FLUVIP.
● Creación de un Elasticache de Amazon y consumo de servidor de Redis desde la
instancia EC2.
● Creación de una nueva instancia EC2 y migración del servidor de Elasticsearch y el
servidor de MongoDB a dicha instancia.
Los cambios previamente detallados y la comunicación entre los componentes se ven
reflejados en la arquitectura ejecutada que se observa en la ilustración 33.
91
8.1.2 ARQUITECTURA LÓGICA FINAL Los cambios que se han realizado a través de este trabajo, además de tener un impacto en la
arquitectura física de la plataforma, también tienen un impacto en la estructura lógica de la
misma y en la forma en la que se abstrae el concepto de “White Label” dentro de la aplicación
y de la compañía misma.
La ilustración 34 muestra la arquitectura lógica de la plataforma desde el punto de vista de las
marcas blancas, en la cual se pueden ver 3 puntos:
A. La forma en la que se realiza la encapsulación de las peticiones a través del
subdominio de la petición al servidor.
B. FLUVIP funcionando como una marca blanca más dentro de la aplicación
INFLUTECH.
C. El paquete de servicios que se le brinda a cada una de las marcas blancas para
garantizarles un sistema totalmente aislado.
8.1.3 ESTRUCTURA SECUENCIAL FINAL
Estos cambios que se ejecutaron también tienen un impacto en la forma secuencial en la que se
lleva a cabo cada petición de los usuarios. Anteriormente se pudo ver, desde el punto de vista
de las marcas blancas, como se encapsula una petición a un grupo de servicios distinto para
cada una de ellas. La ilustración 35 muestra cómo ocurre este encapsulamiento internamente
en la aplicación, viéndolo desde un punto de vista secuencial. La base de este flujo se encuentra
en un componente creado llamado “Environment Loader” (Cargador de ambiente), que se
encarga de encapsular las peticiones estableciendo un entorno previo a su ejecución, de manera
que se lleve a cabo bajo ciertas condiciones, y luego, una vez terminada la petición, restablece
el entorno a su configuración original antes de dar una respuesta al usuario final.
92
Ilustración 33 Arquitectura física final de INFLUTECH.
93
Ilustración 34 Arquitectura lógica final de INFLUTECH
94
Ilustración 35 Estructura secuencial del sistema.
95
8.2. PROPONER UN MODELO DE BASE DE DATOS QUE GARANTICE
CONCURRENCIA EN CADA MARCA BLANCA.
8.2.1 ESTRUCTURA FINAL DE BASE DE DATOS INFLUTECH al ser una plataforma con gran énfasis en la separación de información de
negocio y con una fuerte presencia en el mercado de las redes sociales requirió de la
implementación de un modelo que permitiera la libre ejecución, separación y protección de los
datos de cada una de las agencias.
La ilustración 36 muestra el modelo de dominio inicial de FLUVIP, en el cual se incluyeron
las entidades más destacadas y sus relaciones, de la cual se resalta la relación inicial de la
cadena entre los usuarios con su país de origen. Estos usuarios pueden ser de tipo Influencer o
Marcas (Advertiser) y ambos se relacionan a través de cuentas de redes sociales
(SocialNetworkAccount) incluidas en presupuestos (Budget) y campañas (campaign).
96
Ilustración 36 Modelo de Dominio Inicial FLUVIP
97
Para lograr el objetivo, se hizo uso de los esquemas de POSTGRESQL con el fin de mantener
una estructura básica común entre todas las agencias, pero aislando la información real en un
esquema exclusivo para cada una de ellas. En ilustración 37 se puede apreciar la estructura del
esquema público del cual se basan los esquemas específicos de cada agencia y el modelo de
Agencia.
Ilustración 37 Estructura final de base de datos para el aislamiento de información.
8.3. RESULTADOS OBTENIDOS CON LA ARQUITECTURA Y MODELO DE
DATOS PROPUESTO
Es claro que durante el desarrollo de este proyecto se han realizado cambios muy importantes,
tanto a nivel físico como lógico, como los que se describen en las secciones 8.1 y 8.2, que han
impactado el rendimiento y el comportamiento del sistema, y que, por lo tanto, vale la pena
reconocer dicho impacto realizando una comparación entre las mediciones iniciales y finales
del sistema.
98
8.3.1. RENDIMIENTO Y TIEMPOS DE RESPUESTA En FLUVIP actualmente se utiliza una herramienta llamada New Relic, que permite monitorear
constantemente las aplicaciones con el fin de realizar mediciones sobre distintos aspectos como
rendimiento, errores, transacciones, servicios externos, despliegues, entre otros. Considerando
esas mediciones y de acuerdo con los objetivos específicos 3.2.1 y 3.2.2 se presentan una serie
de gráficos realizados con esta herramienta, utilizando una muestra entre octubre 24 de 2017 y
octubre 27 de 2017.
Ilustración 38 Operaciones de mayor consumo en PostgreSQL.
La ilustración 38 muestra las operaciones que llevan un mayor tiempo de ejecución sobre el
motor de base de datos. Con base en la muestra, el promedio se encuentra en 45 ms y la
operación más prolongada es sobre la tabla OrganicPosts, lo cual tiene sentido dado que es
donde se almacenan todas las interacciones (comentarios, retweets, compartidos) que se
realizan sobre las publicaciones que se programan en el sistema. El pico alcanzado en esta
operación es de 233 ms sobre un conjunto de aproximadamente 5100 peticiones en una hora,
de 4:27 pm a 5:27 pm, sobre lo cual vale la pena aclarar que son operaciones realizadas en
procesos de actualización internos del sistema, es decir que no corresponden a peticiones web
realizadas por usuarios finales.
99
Ilustración 39 Operaciones de mayor consumo en Redis.
La ilustración 39 muestra las operaciones que consumen un mayor tiempo de ejecución en
Redis. Con base en la muestra se obtuvo un promedio de 1.5 ms y un máximo de 286 ms. Este
pico coincide con la hora de muestra que se describió anteriormente sobre la actualización de
publicaciones orgánicas, lo que constituye uno de los procesos más costosos del sistema en
términos generales.
Ilustración 40 Tiempo de respuesta de peticiones web.
100
La ilustración 40 muestra los tiempos de respuesta de las peticiones web realizadas a la
aplicación durante el periodo de muestra. Se obtuvo un promedio de 415 ms de tiempo de
respuesta del servidor sobre un promedio de 27.9 peticiones por minuto. El tiempo más largo
de respuesta, incluyendo el procesamiento del lado del cliente, fue de 1.6 segundos, entre las 3
y 5 de la tarde, periodo en el cual aumenta normalmente la cantidad de peticiones. Es importante
aclarar, que esta muestra incluye los periodos de inactividad que normalmente se dan entre las
8 PM Y 4 AM, dado que la aplicación es utilizada en mayor medida en Latinoamérica. La tasa
de peticiones por minuto en los horarios laborales es en promedio 51.3 rpm.
Finalmente, la tabla 20 muestra un comparativo entre las métricas al inicio y al final del
proyecto garantizando así la concurrencia del sistema al mejorar en términos generales los
tiempos de respuesta, aumentar la cantidad de peticiones por minuto y mejorando la experiencia
den general de los usuarios finales.
Métrica Inicio del proyecto
Final del Proyecto
PostgreSQL
● Tiempo promedio de respuesta 0.3 seg 45 ms
● Tiempo máximo de respuesta 1.5 seg 233 ms
● Promedio de peticiones por minuto 410 RPM 916 RPM
Redis
● Tiempo promedio de respuesta 15 miliseg 1.5 miliseg
● Tiempo máximo de respuesta 529 miliseg 286 miliseg
● Promedio de peticiones por minuto 347 RPM 516 RPM
Peticiones Web (Usuario Final)
● Tiempo promedio de respuesta. 2.1 seg 415 ms
● Tiempo máximo de respuesta (Incluyendo procesamiento del cliente)
4.9 seg 1.6 seg
● Promedio de peticiones por minuto 29.5 RPM 51.3 RPM
Tabla 20 Comparación de métricas de rendimiento.
101
8.3.2. DATOS Una vez concluido el proyecto se realizó un análisis comparativo sobre los motores de bases
de datos de la aplicación con el fin de monitorear su crecimiento. Los resultados pueden verse
en la tabla 21.
Al inicio del proyecto (Registros)
Al final del proyecto (Registros)
Crecimiento Total
(Porcentaje)
PostgreSQL 2’934.006 1’859.461 36.624%
Mongo 13’503.298 15’801.767 14.546%
ElasticSearch 39.168 53.792 27.186%
Tabla 21 Crecimiento en los motores de almacenamiento
8.4. MODULO ORIENTADO A PRUEBAS AUTOMATIZADAS.
Uno de los objetivos del proyecto es asegurar la fiabilidad del sistema y obtener un alto nivel
de cobertura en cuanto a pruebas unitarias y de integración. Una vez concluido el proyecto y
de acuerdo con el objetivo 3.2.3, se incrementó el valor de cobertura del sistema mediante el
módulo de pruebas automatizadas generando así una comparación entre el estado inicial y el
estado final del conjunto de pruebas del sistema lo cual puede verse en la tabla 22.
Al inicio del proyecto Al final del proyecto
Porcentaje de Cobertura 65.21 % 88.41 %
Número de Archivos 657 1245
Líneas Analizadas 32276 57747
Pruebas Ejecutadas 2751 3645
Tabla 22 Comparación del conjunto total de pruebas.
Aunque en gran parte de la comunidad de desarrollo coincide en que el porcentaje de cobertura
de pruebas de un proyecto no garantiza la calidad de las pruebas, como Martin Fowler en Test
Coverage [42], también coinciden en que es una herramienta muy útil para determinar qué partes
102
del código y cuántas no están siendo testeadas, y esto permite a los desarrolladores realizar un
análisis para agregar casos de cobertura o eliminar el código dependiendo del caso.
Para lograr el fortalecimiento de un módulo de pruebas automatizado que sea fácilmente
extensible y altamente confiable, se tuvo en cuenta los lineamientos establecidos por el TDD
como se menciona en la sección 7.2.4, y se tuvo en cuenta las distinciones que señala la
pirámide de pruebas que se describe a continuación:
• Pruebas de aceptación: Representan el nivel más alto de la pirámide y describen los
casos de prueba de escenarios que involucran interacción directa por parte de los
usuarios finales. En el caso de INFLUTECH se diseñaron e implementaron los casos de
prueba más comunes de acuerdo al nivel de interacción del usuario para cada
funcionalidad.
• Pruebas de integración: Representan el nivel medio de la pirámide y describen el
comportamiento de uno o más componentes de negocio del sistema. En el caso de
INFLUTECH, es el nivel que cuenta con un mayor nivel de cobertura y para el cual se
diseñaron e implementaron casos de prueba que validaran la mayor cantidad de
escenarios posibles, dado que, dichos componentes controlan las decisiones de negocio
más importantes y permiten independizar el procesamiento y los resultados de la forma
en que se presentan.
• Pruebas unitarias: Representan el nivel más bajo de la pirámide y describen el
comportamiento de un componente o función en total aislamiento. En el caso de
INFLUTECH, representa un alto porcentaje del conjunto de pruebas, ya que, la
posibilidad de probar y utilizar un componente en total aislamiento permite garantizar
bajo acoplamiento entre los componentes del sistema.
La ilustración 41 muestra la evolución que ha tenido el módulo de pruebas en cada uno de los
niveles de la pirámide descritos anteriormente durante el proyecto.
103
Ilustración 41 Distribución del módulo automatizado de pruebas.
A la conclusión del módulo de pruebas automatizadas se tuvo un incremento en el porcentaje
de cobertura y en la cantidad de pruebas del set que corresponden a la siguiente relación:
• Pruebas aceptación: Incremento del 25% en el número de pruebas aportando de esta
manera un 7.33% al porcentaje de cobertura total.
• Pruebas de integración: Incremento del 29% en el número de pruebas aportando de
esta manera un 8% al porcentaje de cobertura total.
• Pruebas unitarias: Incremento del 41.96% en el número de pruebas aportando de esta
manera un 13% al porcentaje de cobertura total.
El porcentaje de total de aumento de cobertura corresponde al 28.33%.
8.5. ACOPLAMIENTO DE LOS SERVICIOS EXTERNOS (REDES SOCIALES) CON
EL NUEVO MODELO DE AGENCIA
Como se ha mencionado previamente, INFLUTECH, cuenta con las redes sociales como
proveedores de servicios de consulta y generación de información para cada agencia. Teniendo
104
en cuenta que estos proveedores ofrecen sus servicios de manera gratuita, sus aplicaciones
tienen algunas restricciones relacionadas con el límite de uso que se aplica a cada consumidor
de sus servicios. Dichas restricciones deben ser tenidas en cuenta y se debe administrar de la
mejor manera posible el consumo de estas aplicaciones para garantizar a cada agencia
disponibilidad total a la información. La tabla 23 ilustra estos límites para una sola aplicación.
Cantidad Endpoints Limite Total Promedio de peticiones
Youtube 6 Endpoints 10000 peticiones 6000 peticiones Twitter 8 Endpoints 11000 peticiones 10000 peticiones
Facebook 8 Endpoints 8000 peticiones 7000 peticiones
Tabla 23 Restricciones de uso de servicios externos.
Estos datos fueron tomados en retrospectiva, de acuerdo al comportamiento de la plataforma
FLUVIP antes de la implementación de INFLUTECH. Con el fin de garantizar la concurrencia
de cada una de las agencias, desacoplar la dependencia de una única aplicación para cada
proveedor y tomando como ventaja el uso de los esquemas previamente explicados, se
definieron aplicaciones para cada agencia lo cual se traduce en que, al momento de hacer uso
de alguno de estos proveedores, el solicitante, en este caso una agencia, tendrá sus propias tasas
de consumo y de límites de consumo.
Para la utilización de las credenciales de cada uno de los servicios externos por agencia se lanza
un proceso en el momento que se crea una petición nueva, encargado de buscar en el esquema
de la agencia que está creando la petición, las credenciales correspondientes para cada uno de
los proveedores, tal y como se ve reflejado en la ilustración 42.
105
Ilustración 42 Independización de servicios externos por agencia
106
8.6. IMPLEMENTAR UN MODULO DE PERSONALIZACIÓN VISUAL PARA CADA
AGENCIA.
INFLUTECH con miras en garantizar la identidad de cada una de las agencias para que estas
tengan un valor único frente a sus clientes, definió como requisito un módulo de
personalización en el cual cada una de las agencias pudiera modificar algunos sectores de la
plataforma. Sin embargo, y por aclaraciones legales de la empresa FLUVIP durante el
transcurso de la ejecución del proyecto, se definieron los siguientes sectores claves como
sectores de personalización:
• Landing: Punto de acceso a la plataforma.
• Página de ingreso y registro: Páginas encargadas de la autogestión de los usuarios.
• Dashboard perfil operacional: Página de inicio del empleado de la agencia.
• Dashboard perfil influenciador: Página de inicio del usuario que vincula redes
sociales.
Además, se definió que estos lugares sólo pueden ser modificados bajo demanda y deben
cumplir con los estándares definidos en la tabla 24.
Nombre Tamaño Tipo Descripción
background mayor a 1600 x 1200 px JPG Esta será la imagen de fondo del inicio de sesión.
dark_logo exactamente 270 x 81 px SVG Es el logo para superficies claras
light_logo exactamente 270 x 81 px SVG Es el logo para superficies oscuras
nav_logo exactamente 240 x 50 px SVG Es el logo para los perfiles de influencer y operaciones.
tab_logo exactamente 270 x 81 px SVG Es el logo corto para los perfiles de influenciador y operaciones.
Tabla 24 Especificación de logos. Tomado del manual de creación.
A continuación, se muestran dos agencias resaltando su identidad en cada una de estas
secciones de la plataforma:
107
A. Landing: Uso del background
Ilustración 43 Landing Socialyse.
Ilustración 44 Landing Thinketers.
108
B. Registro: Uso dark logo.
Ilustración 45 Formulario de registro Socialyse.
Ilustración 46 Formulario de registro Thinketers.
109
C. Ingreso: Uso dark logo.
Ilustración 47 Formulario de ingreso Socialyse.
Ilustración 48 Formulario de ingreso Thinketers.
110
D. Dashboard Operativo: Uso de light logo.
Ilustración 49 Dashboard Operativo Socialyse.
Ilustración 50 Dashboard Operativo Thinketers.
E. Dashboard Influencer: Uso de light logo.
Ilustración 51 Dashboard Influencer Socialyse.
111
Ilustración 52 Dashboard Influencer Thinketers.
8.7. RESULTADOS COMERCIALES DEL PRODUCTO: IMPACTO DE SERVICIOS
INTERNOS Y PROTOTÍPOS INTERACTIVOS.
A lo largo de la ejecución de este proyecto, más exactamente hacia la mitad de la fase de
implementación del mismo, el equipo comercial de FLUVIP empezó a organizar reuniones
comerciales con algunos clientes previamente identificados, y también inició la búsqueda de
clientes potenciales que pudieran estar interesados en adquirir INFLUTECH como servicio de
software de Influencer Marketing. Luego de varias conversaciones, reuniones y acuerdos,
FLUVIP ha incorporado hasta la fecha cuatro agencias de publicidad como clientes de marca
blanca. Con lo anteriormente estipulado y de acuerdo con los objetivos específicos 3.2.4, 3.2.6
y 3.2.7 enfocados en la extensión de los servicios externos de Redes Sociales y la creación de
prototipos se obtuvieron los siguientes resultados:
Nombre Descripción N° de Usuarios
N° de Campañas
Socialyse Es una solución de social media que provee la empresa Havas Media, una de las agencias de medios más grandes del mundo. Tiene operación en 144 países [39]. Inicia operaciones usando INFLUTECH inicialmente en Latinoamérica y Estados Unidos.
1655 Usuarios 1430 Influencers 85 Clientes 140 Usuarios
313 Propuestas creadas. 50 Campañas Ejecutadas
112
Internos
Influnet Es una compañía dedicada al Influencer Marketing con base en Panamá, que inicia su operación automatizada a través de INFLUTECH, para realizar campañas en Panamá y Centroamérica
[40].
757 Usuarios totales. 710 Influencers. 33 Clientes. 13 Usuarios Internos
205 Propuestas Creadas 18 Campañas Ejecutadas
Influmedia Es una empresa de publicidad de Puerto Rico que quiere incursionar en el mercado de Influencer Marketing. Ya hay un acuerdo pero no han empezado operaciones.
0 Usuarios 0 Propuestas/Campañas
ThinketersIN Thinketers es una empresa de marketing digital con sede en España, que inicia su operación de Influencer Marketing cómo ThinketersIN a través de INFLUTECH [41].
139 Usuarios 115 Influencers. 13 Clientes 11 Usuarios Internos
10 Propuestas Creadas 8 Campañas ejecutadas
Tabla 25 Resultados comerciales por marca blanca.
En total son 2551 nuevos usuarios desde el lanzamiento de INFLUTECH representando así
un incremento en usuarios en cada uno de los prototipos operativos.
8.8 FUNCIONAMIENTO DE PROTOTIPOS, ADAPTACIÓN DE NUEVOS
USUARIOS Y COSTO BENEFICIO PROYECTADO DEL PROYECTO
La introducción del sistema marca blanca INFLUTECH, como se vio en el punto anterior, ha
generado un impacto significativo en varios recursos de la plataforma, como los usuarios, no
sólo de tipo influenciador sino también de tipo de operativo, lo cual indica que una vez se
encuentre en funcionamiento el crecimiento operacional hará que las campañas creadas a través
de la herramienta aumenten.
113
En la tabla 26 se encuentran registradas las campañas creadas cada mes por la marca blanca
FLUVIP las cuales se usarán como base para proyectar operacionalmente el comportamiento
de las otras marcas blancas.
CAMPAÑAS POR AGENCIA
Mes FLUVIP
Enero (2018) 5
Febrero (2018) 4
Marzo (2018) 6
Abril (2018) 3
Mayo (2018) 6
Junio (2017) 5
Julio (2017) 4
Agosto (2017) 4
Septiembre (2017) 6
Octubre (2017) 6
Tabla 26 Resultados comerciales por marca blanca
Con la información registrada desde la operación de FLUVIP como Marca Blanca se tiene la
tabla 27 de costos y ganancia para el año 2017 para la cual se tuvieron en cuenta las siguientes
consideraciones de acuerdo a la operación de FLUVIP:
● Por agencia se realiza el montaje de 5 campañas en promedio al mes.
● El salario promedio de un operativo es de $2.500.000.
● El porcentaje de ganancia por campaña oscila entre el 42% y el 53%.
● Para los meses de octubre y noviembre, Socialyse y Thinketers realizaron las primeras
campañas piloto, por eso se cuentan dentro de las ganancias.
114
Ingresos Netos Costos Ganancia Thinketers +
Socialyse Porcentaje Ganancia
Junio $165,244,520 $96,656,105 $68,588,415 $0 41.51%
Julio $155,323,705 $83,595,845 $71,727,860 $0 46.18%
Agosto $159,822,045 $97,112,245 $62,709,800 $0 39.24%
Septiembre $162,960,255 $92,500,675 $70,459,580 $0 43.24%
Octubre $184,024,126 $96,287,885 $87,736,241 $16,729,466 47.68%
Noviembre $180,187,818 $87,731,955 $92,455,863 $30,031,303 51.31%
PROYECCIÓN 2018
Enero $205,714,426 $81,780,955 $123,933,471 $55,557,911 60.25%
Febrero $231,342,328 $94,720,095 $136,622,233 $76,200,668 59.06%
Marzo $214,095,491 $80,280,580 $133,814,911 $58,953,831 62.50%
Abril $210,604,554 $89,554,515 $121,050,039 $45,360,034 57.48%
Mayo $233,804,554 $95,773,590 $138,030,964 $68,560,034 59.04%
Tabla 27 Ingresos totales INFLUTECH.
En la ilustración 53 se aprecia el comportamiento de las marcas blancas. Como se puede
observar, el costo operacional generado por cada una de las campañas que se crean
internamente es asumido por FLUVIP, mientras que, para el caso de otras marcas blancas como
Socialyse y Thinketers, el costo es asumido por ellas y adicional se paga un porcentaje a
FLUVIP por cada campaña creada con INFLUTECH, de allí que se vea un alza en la ganancia
generada desde el mes de octubre, sin que los costos operacionales varíen respecto a los meses
anteriores.
115
Ilustración 53 Ingresos totales INFLUTECH.
Con las proyecciones previamente registradas en la tabla 27, se tienen los datos necesarios:
Valor Actual de los Ingresos netos (VAI) y Valor Actual de los costos de inversión (VAC) para
realizar un análisis costo / beneficio, el cual se detalla en la tabla 28.
Ingresos Totales
Costos de Inversión (VAC)
Ganacia Neta (VAI)
Costo / Beneficio
Junio (2017) $165,244,520 $96,656,105 $68,588,415 0.71% Julio (2017) $155,323,705 $83,595,845 $71,727,860 0.86%
Agosto (2017) $159,822,045 $97,112,245 $62,709,800 0.65% Septiembre
(2017) $162,960,255 $92,500,675 $70,459,580 0.76% Octubre (2017) $184,024,126 $96,287,885 $87,736,241 0.91%
Noviembre (2017) $180,187,818 $87,731,955 $92,455,863 1.05%
Enero (2018) $205,714,426 $81,780,955 $123,933,471 1.52% Febrero (2018 $231,342,328 $94,720,095 $136,622,233 1.44%
Marzo (2018) $214,095,491 $80,280,580 $133,814,911 1.67% Abril (2018) $210,604,554 $89,554,515 $121,050,039 1.35%
Mayo (2018) $233,804,554 $95,773,590 $138,030,964 1.44%
Tabla 28 Proyección de costo beneficio.
116
Tal y como se aprecia en la ilustración 54 de Ingresos totales en comparación con el VAC y el
VAI, el proyecto se vuelve viable desde el mes de noviembre de 2017, ya que la entrada en
operación de las marcas blancas activas (Thinketers y Socialyse) generaron ingresos sin que
FLUVIP directamente invirtiera el costo operacional. En la ilustración 55 se observa el
comportamiento del índice de viabilidad y retorno de la inversión de la proyección.
Ilustración 54 Ingresos totales, Costos de inversión y Ganancia Neta.
Ilustración 55 Relación de costo beneficio.
$0
$50.000.000
$100.000.000
$150.000.000
$200.000.000
$250.000.000
Ingresos Totales, Costos de Inversión (VAC) y Ganacia Neta (VAI)
Ingresos Totales
Costos de Inversión (VAC)
Ganacia Neta (VAI)
Lineal (Ingresos Totales)
Lineal (Costos de Inversión(VAC) )
Lineal (Ganacia Neta (VAI))
0,00%0,20%0,40%0,60%0,80%1,00%1,20%1,40%1,60%1,80%
Cost
o / B
enfic
io
Relacion Costo / Beneficio
Costo / Beneficio
117
Al momento de cerrar el proyecto se cuenta con un costo beneficio presente (Noviembre de
2017) del 1.05% como se aprecia en la tabla 28.
8.9 TAMAÑO DEL PROYECTO
El desarrollo del proyecto WHITE LABEL fue una oportunidad para que los desarrolladores
hicieran una evaluación general del sistema, y les permitió hacer una revisión de todo el código
existente y determinar cuáles fragmentos del mismo ya no se estaban utilizando. Con base en
esto, los desarrolladores aprovecharon esta oportunidad para realizar una labor de limpieza y
obtener un proyecto mucho más compacto y manteniendo el código legado en el mínimo nivel
posible. La tabla 29 muestra una comparación entre el estado inicial y final del proyecto.
Inicial Final
Número de archivos 5569 4206
Ruby 89.6 % 89.3 %
HTML 6.4 % 5.6 %
CSS 2.3 % 2.4 %
JavaScript 1.7 % 1.7 %
Jupyter Notebook 0 % 1 %
Tabla 29 . Comparación del tamaño del proyecto.
8.10 INCONVENIENTES
Durante la implementación del proyecto se presentaron varios inconvenientes que impactaron
los flujos normales de algunos procesos. A continuación, se destacan algunos de ellos:
I. Mientras se desarrollaba WHITE LABEL, el resto del equipo de tecnología continuaba
desarrollado nuevas funcionalidades para la plataforma, por lo cual, en algunos puntos,
la integración entre este proyecto y las nuevas funcionalidades género un constante
118
proceso de actualización de cambios en el código, y por consiguiente se dieron unos
pequeños retrasos en el despliegue de actualizaciones.
II. Inicialmente se tenía la idea de poder desplegar cada nueva marca blanca en cuestión
de minutos, solo con tener la personalización visual de cada una de ellas. Sin embargo,
tanto Twitter como Facebook realizan un proceso de verificación de las plataformas que
usan sus aplicaciones, y este proceso puede tomar entre 2 y 5 días laborales. Por este
motivo, se estableció un periodo máximo de una semana para la configuración de cada
nueva marca blanca.
III. El hecho de que Instagram no haya sido una red social abierta a través de su API durante
tanto tiempo (1 año y medio aproximadamente), hace un poco más complejo el proceso
de capacitación de las marcas blancas con respecto a otras redes sociales. Sin embargo,
recientemente se han abierto nuevas oportunidades para que entidades externas utilicen
su API, que, aunque se encuentra bajo un proceso de revisión muy estricto, permitirá a
INFLUTECH mediante su equipo de tecnología, conectarse a esta red social y obtener
información mucho más precisa.
119
9. CONCLUSIONES
A la culminación del proyecto, se concluye que el trabajo realizado conjuntamente entre el
equipo de desarrollo y el área comercial, permitió lanzar al mercado un producto que ha
cumplido con las expectativas de los clientes que esperaban su implementación y ha generado
mucho interés en otros clientes potenciales.
El lanzamiento de INFLUTECH logró el objetivo de automatizar, y por lo tanto acelerar todos
los procesos de creación de campañas, búsqueda de influenciadores y monitoreo de resultados,
para las agencias de medios que realizan campañas publicitarias a través de Influencer
Marketing. De esta manera, ahora las agencias pueden vender su versión de INFLUTECH
como un servicio propio y están obteniendo mejores resultados.
La plataforma FLUVIP se transformó a un modelo marca blanca, ahora conocida como
INFLUTECH, utilizando como arquitectura un enfoque de aislamiento (físico) total de datos y
servicios. Durante la fase de análisis y desarrollo se pudo concluir que con respecto a los
objetivos 3.2.1 y 3.2.1 que aunque el aislamiento a nivel de aplicación es más económico en
cuanto a recursos físicos (20% menos en espacio de almacenamiento aproximadamente), no es
escalable hacia ninguno de los servicios, no garantiza aislamiento de los datos e implica
tiempos más largos de desarrollo para cada nueva funcionalidad (tiempos entre 30% y 55%
más largos dependiendo de la funcionalidad). En contraste a esto, la separación física de datos
y servicios aparece como un modelo mucho más fácil de escalar, y permite garantizar la
independencia entre cada una de las agencias vinculadas al sistema.
Inicialmente se pensó en aumentar los recursos del servidor principal de la aplicación para
obtener un mejor rendimiento, sin embargo, la independización de servicios mediante AWS
(Amazon Web Services) fue una alternativa más viable, dado que permitió liberar la carga del
servidor principal, facilitó un eficiente aprovechamiento de los recursos, y ayudó a liberar a los
desarrolladores de la administración de recursos ya que son servicios auto gestionados. Este
cambio de arquitectura se vio reflejado en los tiempos de respuesta de la aplicación y de cada
uno de los servicios, obteniendo una reducción del 85% en el tiempo de respuesta de la base de
datos principal sobre una base del doble de RPM, adicional a esto se obtuvo una reducción del
90% en el tiempo de respuesta de Redis sobre una base de 48% adicional de RPM, lo que
120
condujo a una reducción del 80% en el tiempo de respuesta de las peticiones web sobre una
base de 70% adicional de RPM. Estos resultados permitieron cumplir el objetivo de garantizar
altos niveles de concurrencia a cada una de las agencias vinculadas al sistema.
Ahora bien, con respecto al objetivo 3.2.5, la personalización visual es uno de los grandes
beneficios que ven las agencias al vincularse al sistema y las que se encuentran vinculadas
actualmente están muy a gusto de tener esta posibilidad. A pesar de que el módulo desarrollado
es relativamente básico, permite cumplir el objetivo de brindar a cada marca blanca un toque
de identidad propia.
El desarrollo guiado por pruebas (TDD) fue uno de los pilares en la construcción de este
sistema, haciendo que el objetivo 3.2.3 se evidenciara como ventaja competitiva ya que
permitió que el proyecto avanzará según los tiempos esperados, ayudó a construir un sistema
pensado desde el comienzo hacia la calidad, y además facilitó los procesos de revisión de
compatibilidad hacia atrás, de integración continua y de despliegue continuo. Este enfoque
permitió cumplir el objetivo de generar un sistema automatizado de pruebas que garantice
constantemente los requerimientos establecidos.
Utilizar SCRUM como metodología permitió que el proyecto se desarrollara de manera
organizada y bajo los cronogramas establecidos, a pesar de los inconvenientes que se
presentaron en el camino. Esta metodología permitió que cada miembro del equipo tuviera
definidas tareas muy claras y específicas y que el producto final fuera creciendo
progresivamente.
Las pruebas funcionales llevadas a cabo con los equipos internos de FLUVIP (Operaciones,
Comercial y Soporte), fueron de gran ayuda ya que permitieron obtener una muy buena
retroalimentación sobre módulos de la plataforma que funcionaban muy bien y otros que
necesitaban cambios para hacer más claro su entendimiento. Esto ayudó a realizar mejoras en
dichos puntos para que, junto a los manuales de usuario que se elaboraron, se lograra el objetivo
de hacer que el proceso de adaptación de los usuarios de las nuevas agencias sea mucho más
rápido y eficiente, pasando de un promedio de 8 días a un promedio de 2 días de adaptación.
Finalmente, y con los objetivos 3.2.6 y 3.2.7 en mente, se concluye que la versión actual de la
plataforma cumple con todos los requerimientos establecidos inicialmente, satisface el diseño
121
arquitectural que se planteó en la fase de análisis y se encuentra lista para ser una versión marca
blanca de múltiples agencias de medios.
122
10. BIBLIOGRAFIA
1. FLUVIP (2016). FLUVIP Platform. Recuperado el 07/07/2016. Sito web:
http://www.fluvip.com
2. GIT Acerca del control de versiones. Recuperado el 07/07/2016. Disponible en: https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones
3. RubyLang (2016). About Ruby. Recuperado el 07/11/2016. Sitio web:
https://www.ruby-lang.org/es/about/
4. Rails Guides (2016). Getting Started with Rails. Recuperado el 07/11/ 2016. Sitio web: http://guides.rubyonrails.org/getting_started.html
5. Rails Guides (2016). Ruby On Rails I. Recuperado el 07/11/2016. Sitio web:
http://www.sentex.net/~pkomisar/Ruby/9_RubyOnRails_1.html
6. Rails Guides (2016). Active Record Basics. Recuperado el 07/11/2016. Sitio web: http://edgeguides.rubyonrails.org/active_record_basics.html
7. Rails Guides (2016). Action View Overview. Recuperado el 07/11/2016. Sitio web:
http://guides.rubyonrails.org/action_view_overview.html
8. Rails Guides (2016). Action Controller Overview. Recuperado el 07/11/2016. Sitio web: http://guides.rubyonrails.org/action_controller_overview.html
9. Rails Guides (2016). Action Mailer Basics. Recuperado el 07/11/2016. Sitio web:
http://edgeguides.rubyonrails.org/action_mailer_basics.html
10. Mike Gahan. (2010). An introduction to databases. Recuperado el 20/09/2017, de UCL. Sitio web: http://www.ucl.ac.uk/archaeology/cisp/database/manual/node1.html
11. PostgreSql Global Development Group (2017). About PostgreSql. Recuperado el
20/09/2017, de PostgreSql Global Development Group. Sitio web: https://www.postgresql.org/about/
12. PostgreSql Global Development Group (2017). Intro to PostgreSql. Recuperado el
20/09/2017, de PostgreSql Global Development Group. Sitio web: https://www.postgresql.org/docs/9.6/static/intro-whatis.html
13. PostgreSql Global Development Group (2017). Schemas. Recuperado el 26/09/2017,
de PostgreSql Global Development Group. Sitio web: https://www.postgresql.org/docs/9.4/static/ddl-schemas.html
123
14. PostgreSql Global Development Group (2017). Table Basics. Recuperado el 26/09/2017, de PostgreSql Global Development Group. Sitio web: https://www.postgresql.org/docs/9.4/static/ddl-basics.html
15. Acens Technologies (2017). Bases de datos NoSQL. Qué son y tipos que nos
podemos encontrar. Recuperado el 30/09/2017, de Acens. Sitio web: https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf
16. Lith, Adam, Mattsson, Jakob (2010). Investigating storage solutions for large data.
Recuperado el 01/10/2017 de Chalmers University of Technology. Sitio web: http://publications.lib.chalmers.se/records/fulltext/123839.pdf
17. MongoDB, Inc (2017). The MongoDB 3.4 Manual. Recuperado el 02/10/2017 de
MongoDB, Inc. Sitio web: https://docs.mongodb.com/manual/
18. MongoDB, Inc (2017). What is MongoDB?. Recuperado el 02/10/2017 de MongoDB, Inc. Sitio web https://www.mongodb.com/what-is-mongodb
19. Elasticsearch BV. (2017). Getting Started with ElasticSearch. Recuperado el
04/10/2017 de Elasticsearch BV. Sitio web: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started.html
20. Elasticsearch BV (2017). Basic concepts. Recuperado el 04/10/2017 de Elasticsearch
BV. Sitio web: https://www.elastic.co/guide/en/elasticsearch/reference/current/_basic_concepts.html
21. RedisLabs (2017). Introduction to Redis. Recuperado el 04/10/2017 de RedisLabs.
Sitio web: https://www.elastic.co/guide/en/elasticsearch/reference/current/_basic_concepts.html
22. Burak Guzel (2010). Scheduling Tasks with Cron Jobs. Recuperado el 04/10/2017 de
EnvatoTuts. Sitio web: https://code.tutsplus.com/tutorials/scheduling-tasks-with-cron-jobs--net-8800
23. Ryan Boland (2014). Writing your first background worker. Recuperado el
05/10/2017 de Ryan Boland. Sitio web: https://ryanboland.com/blog/writing-your-first-background-worker
24. ondrejbartas (2013). Sidekiq Cron. Recuperado el 07/10/2017 de ondrejbartas. Sitio
web: https://github.com/ondrejbartas/sidekiq-cron
25. 3Scale (2012). What is an API?. Recuperado el 09/10/2017 de 3Scale. Sitio web:
http://images.engage.redhat.com/Web/RedHat/%7Bc52c3b6d-88ef-4af3-977d-
124
4cfc997e7da8%7D_mi-3scale-what-is-an-api-ebook-f7865-201706-en.pdf
26. Sam Deering (2012). What a REST Api is?. Recuperado el 09/10/2017 de SitePoint.
Sitio web: https://www.sitepoint.com/developers-rest-api/
27. DigitalOcean (2014). An introduction to OAuth2. Recuperado el 10/10/2017 de
DigitalOcean. Sitio web: https://www.digitalocean.com/community/tutorials/an-
introduction-to-oauth-2
28. Facebook, Inc (2017). Graph API. Recuperado el 10/10/2017 de Facebook Developers.
Sitio web: https://developers.facebook.com/docs/graph-api/reference
29. Twitter, Inc (2017). Twitter REST API. Recuperado el 10/10/2017 de Twitter
Developers. Sitio web: https://developer.twitter.com/en/docs/api-reference-index
Google, Inc (2017). Youtube Data API. Recuperado el 11/10/2017 de Google Developers.
Sitio web: https://developers.google.com/youtube/v3/docs/
31. Google, Inc (2017). Youtube Analytics API. Recuperado el 11/10/2017 de Google
Developers. Sitio web:https://developers.google.com/youtube/reporting/
32. Amazon Web Services (2017). Relational Database Service. Recuperado el
12/10/2017 de Amazon Web Services. Sitio web: https://aws.amazon.com/es/rds
33. Amazon Web Services (2017). S3. Recuperado el 12/10/2017 de Amazon web
Services. Sitio web: https://aws.amazon.com/es/s3/
34. Andrew Townsend (2011) . What is an Application Server?. Recuperado el
13/10/2017 de The Server Side. Sitio web:
http://www.theserverside.com/feature/What-is-an-Application-Server
35. Bogomips (2017). Unicorn. Recuperado el 13/10/2017 de Bogomips. Sitio web:
https://bogomips.org/unicorn/
36. Nginx (2017). What is NGINX?. Recuperado el 13/10/2017 de NGINX. Sitio web:
125
https://www.nginx.com/resources/wiki/
37. LETELIER, PENADÉS (2016). Métodologías ágiles para el desarrollo de software. Recuperado el 14/11/2017. Sitio web: http://www.cyta.com.ar/ta0502/v5n2a1.htm
38. Proyectos Ágiles (2015). ¿Qué es SCRUM?. Recuperado el 17/10/2017 de Proyectos
Ágiles. Sitio web: https://proyectosagiles.org/que-es-scrum
39. Agencia Havas (2017). About Havas. Recuperado 01/11/2017 de Agencia Havas.
Sitio web: http://www.havasmedia.com/who-we-are/about-us
40. Agencia Influnet (2017). About Influnet. Recuperado 01/11/2017 de Agencia Influnet.
Sitio web: http://influnet.com.pa/
41. Agencia Thinketers (2017). About Thinketers. Recuperado 01/11/2017 de Agencia
Thinketers. Sitio web: http://www.thinketers.com/influencers
42. Martin Fowler (2012). Test Coverage. Recuperado 11/11/2017 de Martin Fowler.
Sitio web: https://martinfowler.com/bliki/TestCoverage.html
