Universidad ORT Uruguay
Facultad de Ingeniería
Bumbea
Servicio social de información de productos de
tecnología
Entregado como requisito para la obtención del título de
Ingeniero en Sistemas
Bruno HARTMANN – 154012
Camilo GARCÍA – 155000
Dayana JABIF – 154293
Agustín HALLER – 155612
Diego ACOSTA – 156156
Tutor: Martín SOLARI
Declaración de Autoría
Nosotros, Agustín Haller, Bruno Hartmann, Camilo García, Dayana Jabif y Diego Acosta, declaramos que el trabajo que se presenta en esta obra es de nuestra propia mano. Podemos asegurar que:
• La obra fue producida en su totalidad mientras realizábamos el proyecto de fin de carrera;
• Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
• Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas citas, la obra es enteramente nuestra;
• En la obra, hemos acusado recibo de las ayudas recibidas;
• Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qué fue contribuido por otros, y qué fue contribuido por nosotros;
• Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Aclaraciones de firma en orden de aparición: Agustín Haller - 28/02/13
Agradecimientos
La realización de este proyecto no hubiese sido posible sin la colaboración de muchas entidades y personas, a quienes queremos agradecer en la presentación de este documento.
Agradecemos en primer lugar a nuestro tutor del proyecto, Ing. Martín Solari, quien colaboró activamente durante el transcurso de toda la tesis, aportando su visión experta y ayudando en la motivación y seguimiento del equipo.
En segundo lugar, queremos agradecer a todas entidades que ayudaron a realizar este proyecto. A los representantes de las empresas, que dispusieron de su tiempo para validar en conjunto nuestras ideas y brindarnos sugerencias, y a la Universidad ORT Uruguay, por el apoyo brindado a través del Centro de Innovación y Emprendimientos (CIE) y de la Software Factoy (ORTsf).
También queremos agradecer a todas las personas que colaboraron directamente con el proyecto, aportando su conocimiento sobre los distintos aspectos del mismo: Lic. Enrique Topolansky, Cr. Jorge Freyer, Lucía Krygier, Cr. Pablo Correa, Ing. Douglas Rodriguez, Ing. Javier Vázquez, Ing. Eduardo Mangarelli y Lic. José Gordin.
Finalmente, agradecer a nuestras familias, parejas y amigos por la paciencia y el apoyo brindado durante estos meses dedicados a la realización de la tesis.
Muchas gracias a todos.
Abstract
La experiencia de compra es un ciclo por el cual todos los consumidores transitan regularmente. El ciclo comienza cuando el consumidor se informa sobre lo que quiere comprar, luego lo compra, lo experimenta y por último comparte con su entorno el sentimiento que el producto le generó. Usualmente, cuando uno quiere comprar algo, existe mucha gente que ya ha pasado por dicha decisión de compra. Poder conocer las experiencias y opiniones de otras personas, ayuda a que uno tome mejores decisiones, basadas en información y casos reales.
Bumbea es un servicio social basado en comentarios de usuarios, que conecta a empresas y clientes con sus experiencias. El sector en el que se enfoca Bumbea es el de la compra de productos de tecnología. Existe una gran diversidad de marcas y productos, lo que hace muy difícil tomar una decisión de compra, sin sorpresas ni disgustos posteriores.
Para realizar el proyecto se aplicó la metodología Design Thinking, que permitió la ejecución de un proceso centrado en los usuarios e ideado para innovar. Mediante un conjunto de técnicas, herramientas y actividades se extrajeron necesidades de los usuarios que se validaron con entrevistas y observación del proceso de compra. Como marco de gestión se adaptó Scrum, que establece un proceso iterativo, lo que permitió gestionar el alcance, los tiempos y los riesgos del proyecto. La usabilidad de Bumbea es un elemento clave para el éxito del proyecto. La solución propuesta se validó con usuarios y empresas de diferentes nichos.
Palabras Clave
Índice
Declaración de Autoría ... 2
Agradecimientos ... 3
Abstract ... 4
Palabras Clave ... 5
1. Introducción ... 9
1.1. Objetivos principales... 9
1.1.1. Objetivos del proyecto ... 9
1.1.2. Objetivos académicos ... 10
1.2. Criterios de éxito ... 11
1.3. Motivación ... 11
1.4. Denominación y logo del producto ... 12
2. Descripción del proyecto... 14
2.1. Análisis del problema ... 14
2.2. Solución al problema ... 15
2.3. Validación del emprendimiento ... 17
2.4. Alcance del proyecto ... 18
2.5. Evolución del concepto ... 19
2.6. Conformación del equipo ... 20
3. Metodología de trabajo ... 23
3.1. Proceso creativo: Metodología Design Thinking ... 24
3.1.1. Introducción a la metodología ... 24
3.1.2. Aplicación de la metodología al proyecto ... 25
3.1.3. Técnicas para empatizar y definir ... 26
3.1.4. Técnicas para idear ... 29
3.1.5. Técnicas de validación ... 34
3.2. Metodología para gestión y desarrollo del software: Scrum ... 35
4. Ingeniería de requerimientos ... 36
4.1. Requerimientos no funcionales ... 40
5. Diseño arquitectónico ... 43
5.1. Características de calidad ... 43
5.2. Descripción de la arquitectura ... 45
5.2.1. Vista de user stories ... 45
5.2.2. Vista de diseño ... 49
5.2.3. Vista de componentes ... 53
5.3. Herramientas y tecnologías utilizadas ... 60
5.3.1. Presentation Layer ... 60
5.3.2. Business Layer ... 60
5.3.3. Data Access Layer ... 61
5.3.4. Business Common Layer ... 61
5.4. Pruebas de concepto ... 61
5.5. Conclusiones del área ... 62
6. Gestión de la configuración... 64
6.1. Introducción ... 64
6.2. Herramientas utilizadas ... 64
6.2.1. Repositorio de código ... 64
6.2.2. Repositorio de documentos ... 65
6.2.3. Herramientas de comunicación ... 65
6.2.4. Herramientas de gestión ... 66
6.2.5. Herramientas de desarrollo ... 67
6.3. Gestión de versiones ... 68
6.3.1. Identificación de los ECS ... 68
6.3.2. Organización del repositorio ... 69
6.3.3. Gestión de respaldos ... 71
6.4. Circuito de control de cambios ... 71
6.5. Conclusiones del área ... 72
7. Gestión de la calidad ... 73
7.1. Objetivos del área ... 73
7.2. Aseguramiento de la calidad ... 74
7.2.1. Apoyo a Design Thinking ... 74
7.2.2. Proceso de beta-testing ... 76
7.3. Métricas ... 80
7.3.1. Usabilidad ... 80
7.3.2. Eficiencia ... 83
7.4. Conclusiones ... 84
8. Plan de difusión ... 86
8.1. Objetivos ... 86
8.2. Estrategias ... 86
8.3. Tácticas ... 87
8.4. Metodología aplicada ... 88
8.5.1. Acciones en redes sociales ... 89
8.5.2. Acciones de mailing ... 93
8.5.3. Acciones en lugares públicos ... 94
8.6. Conclusiones del área ... 95
9. Gestión de proyecto ... 97
9.1. Introducción ... 97
9.2. Marco de gestión ... 97
9.2.1. Metodología Scrum ... 97
9.2.2. Adaptación de Scrum... 98
9.3. Planificación y seguimiento ... 99
9.3.1. Planificación y estimación de iteraciones ... 99
9.3.2. Registro de esfuerzo y seguimiento ... 101
9.3.3. Análisis de resultados obtenidos ... 103
9.4. Gestión de riesgos ... 107
9.5. Gestión de la comunicación ... 109
9.5.1. Reuniones con interesados ... 109
9.5.2. Comunicación interna... 109
9.6. Conclusiones del área ... 110
10. Conclusiones ... 111
10.1. Conclusiones generales ... 111
10.2. Lecciones aprendidas ... 113
10.3. Producto obtenido y proyección a futuro ... 114
11. Bibliografía y referencias ... 116
12. Anexos ... 119
12.1. Anexo I Prototipos ... 119
12.2. Anexo II. Ciclo de vida de la queja ... 126
12.3. Anexo III. Ejemplo de registro de un sprint ... 128
12.4. Anexo IV. Registro de horas trabajadas ... 131
12.5. Anexo V. Resultado de encuesta ... 132
12.6. Anexo VI. Plan de negocios ... 135
12.7. Anexo VII. User stories ... 152
1. Introducción
El presente documento tiene como objetivo describir todas las actividades que formaron parte del proyecto Bumbea, realizado por los estudiantes: Agustín Haller, Bruno Hartmann, Camilo García, Dayana Jabif y Diego Acosta. Bumbea se desarrolló en el periodo comprendido entre marzo de 2012 y marzo de 2013 con el fin de obtener el título de Ingeniero en Sistemas.
El proyecto se desarrolla en el contexto de la problemática que existe a la hora de tomar una decisión de compra sin sorpresas ni disgustos posteriores. La experiencia de compra se define como un ciclo compuesto por las siguientes actividades: informarse de lo que se quiere comprar, comprar y experimentar el producto y, finalmente, compartir el sentimiento generado hacia el producto y/o el lugar de venta. Conocer previamente estas experiencias, ayuda a brindar mayor seguridad para tomar la mejor decisión de compra. Por este motivo, Bumbea se crea como un servicio social que conecta a empresas y clientes a través de sus experiencias, buscando facilitar la decisión de compra y ayudar a las empresas a ganar más clientes.
Al ser un proyecto que busca innovar, se decidió utilizar Scrum como marco de gestión y el ciclo de vida que ofrece Design Thinking. La alta probabilidad de que sucedieran cambios tanto en los requerimientos como en la idea fue lo que justificó utilizar ambas metodologías. Estos conceptos se describen detalladamente en los capítulos 3. Metodología de trabajo y 9. Gestión de proyecto.
1.1.Objetivos principales
1.1.1. Objetivos del proyecto
el proyecto de grado como primer experiencia, independientemente del resultado final del proyecto.
• Solucionar un problema real. Este objetivo se desprende del anterior, ya que una de las claves para un emprendimiento exitoso es resolver un problema real. El equipo se planteó realizar un producto innovador que sea útil para sus potenciales usuarios. Luego de que surgiera la idea, el objetivo de Bumbea fue que se convirtiera en un servicio que permita a los usuarios decidirse en cuanto a sus compras de tecnología, basándose en las experiencias compartidas en el sitio. El cumplimiento de dicho objetivo se medirá según el crecimiento del contenido del sitio y en base al feedbackde los usuarios del mismo.
• Crear una comunidad autosustentable de usuarios. Este objetivo plantea que los usuarios de Bumbea sean los que mantengan la plataforma en vigencia. Si bien es un objetivo bastante ambicioso para un proyecto nuevo, el equipo trabajó en función de lograrlo. En primera instancia, el equipo se propuso conseguir una gran cantidad de usuarios que utilicen el sitio y que ellos fueran los que empezaran a formar parte de esta comunidad.
1.1.2. Objetivos académicos
• Aplicación práctica. Poder aplicar los conocimientos, técnicas y estrategias aprendidas en la universidad en un proyecto real. Aprovechar la oportunidad para ver cómo se desenvuelve el equipo en cuanto a las diferentes áreas de la ingeniería de software para lograr un proyecto exitoso.
A su vez, se decidió por aplicar paradigmas basados en metodologías innovadoras con el fin de aprender cómo utilizarlas en un proyecto de ingeniería de software.
1.2.Criterios de éxito
A partir de los objetivos planteados, el equipo definió los siguientes criterios de éxito para el proyecto:
• Lograr establecer contacto con al menos dos empresas para que sean parte de la plataforma. Esto demostrará que el producto es capaz de adaptarse a la realidad de las empresas y otorgarles valor.
• Mantener un compromiso de trabajo a lo largo de todo el proyecto superior a las 12 horas semanales.
• Lograr un alto grado de satisfacción de usuarios. Tras lanzar la última versión del producto (dentro del alcance del proyecto) se buscará que los usuarios puntúen a nuestro producto con una conformidad superior al 85%.
• Ingresar al Centro de Innovación y Emprendimientos de la Universidad ORT (CIE). Este departamento de la universidad promueve y desarrolla la generación de nuevos emprendedores. En este sentido, sus acciones están dirigidas a fomentar la innovación, la actitud emprendedora, promover oportunidades y fortalecer la vinculación entre los emprendedores y el sector académico y socio-productivo. Tener el apoyo del CIE significará que nuestra idea tiene el potencial suficiente como para poder convertirse en una empresa y que por lo tanto los procesos innovadores aplicados habrán sido exitosos.
• Plasmar todas las lecciones aprendidas registradas en cada sprint. • Aprobar el proyecto con una calificación superior al 95%.
1.3.Motivación
metodologías innovadoras, desconocidas para el equipo, y que presentaban un desafío poder aplicarlas.
El poder desarrollar nuestra propia idea innovadora desde cero, aunque implique un desafío mayor, nos permite experimentar y aprender sobre todas las etapas por las que pasa un emprendimiento de estas características en la vida real. Estas etapas incluyen el contacto con clientes, inversionistas, relevamiento de necesidades, análisis de productos similares y múltiples tormentas de ideas y construcción de prototipos.
Por otro lado, se trabajó en una idea que reúne características que las empresas más importantes del ámbito del software están explotando actualmente. Entre estos atributos se encuentran, por ejemplo, la propagación de información y la relación que forman los internautas a través de la red.
1.4.Denominación y logo del producto
El proyecto consiste en la construcción de un nuevo producto llamado Bumbea, identificado por la Figura 1.1.
El nombre de la plataforma surge a través de una tormenta de ideas del equipo, en el cual se buscó un nombre que sea pegadizo, sencillo de recordar y que se pudiese transformar en un verbo, si aplicase. Es decir, se trató de agregar una nueva expresión al vocabulario, tal como lo hicieron las grandes empresas. Si bien el nombre no tiene relación alguna con el contenido del sitio, no se consideró esto como una desventaja.
2.
Descripción del proyecto
2.1.Análisis del problema
El problema surge debido a la amplia variedad de marcas y productos que existen en el mercado tecnológico. Actualmente, tomar una decisión de compra de un producto de tecnología (por ejemplo computadoras o celulares) depende de varios factores como su marca e imagen, el precio, sus características o detalles técnicos y las opiniones de personas que ya experimentaron el producto. Estas experiencias son claves a la hora de decidirse sobre el producto en cuestión, ya que en la mayoría de los casos, las personas buscan referencias del producto a través de allegados o en internet (por ejemplo en foros o blogs). Por este motivo, la recomendación de otras personas se considera un factor determinante en la decisión de compra [1].
Figura 2.1. – Ciclo de la experiencia de compra de un producto
El ciclo está basado en el concepto de ZMOT (Zero Moment of Truth o Momento Zero de la Verdad). Este momento se define como el instante preciso en el que un consumidor se decide a comprar un producto [2], es el instante único en que se toma la decisión para luego comenzar el ciclo descrito anteriormente.
2.2.Solución al problema
A partir de los problemas identificados en la sección anterior, se crea Bumbea. Es un servicio social que, basado en comentarios compartidos por usuarios, conecta empresas y clientes a través de sus experiencias de compra, ayudando a las personas a tomar decisiones de compra.
A Bumbea pueden ingresar dos tipos de usuarios: los consumidores (clientes de las empresas) y empresas que ofrecen productos de tecnología. Dentro de la plataforma, los primeros tienen la capacidad de compartir una experiencia vivida sobre una compra de algún producto, mediante la forma de una review. Este concepto es clave para el objetivo de Bumbea.
Una review incluye la opinión del usuario respecto a su experiencia de compra y consumo de un producto, junto con otros detalles, como las características propias de un producto. También se podrá especificar la empresa donde fue comprado el producto con el fin de dar información más precisa a los usuarios del sitio. A su vez, Bumbea ofrece a todos los usuarios la posibilidad de ver las reviews de otros usuarios, compartirlas en las redes sociales más populares e indicar si les fue útil o no para tomar una decisión de compra.
Las empresas vendedoras también están contempladas, ya que pueden tener acceso a las experiencias de sus clientes y utilizarlas para mejorar en distintos aspectos. Otro beneficio que tienen las empresas es el hecho de estar visible ante una comunidad de personas con intención de comprar, y quizás frente a usuarios que podían no conocerla anteriormente.
Uno de los principales desafíos que esta solución incluye es la cantidad de personas que realmente utilicen el sitio. Para que Bumbea resuelva el problema planteado, es clave que muchos usuarios hagan un buen uso de la plataforma. Es decir, escribiendo y compartiendo experiencias de compra con los demás usuarios. Para lograr esto fue necesario plantear una estrategia para difundir Bumbea, la cual se explica detalladamente en el capítulo 8. Plan de difusión.
Esto se solucionó brindando al usuario la posibilidad de crear el producto del cual se quiere realizar la review, en caso de que este no se encontrara en la plataforma. Además, al ser una plataforma en crecimiento, se decidió que momentáneamente los detalles y fotos del nuevo producto fueran agregados por los integrantes del equipo, ya que no implicaba un esfuerzo considerable durante el transcurso del proyecto. Sin embargo, esta decisión podría afectar la sustentabilidad del servicio a mediano plazo debido a la creciente innovación de productos tecnológicos y la necesidad de mantener la plataforma actualizada para que siga cumpliendo sus objetivos.
2.3.Validación del emprendimiento
Una vez definido el producto a realizar, se analizó mediante una presentación al CIE, la viabilidad que tendría el producto principalmente desde una perspectiva de rentabilidad, así como un análisis de sus puntos críticos y los beneficios que este brinda.
Si bien se destacó el trabajo realizado por el equipo, se detectaron puntos débiles referidos principalmente a la diferenciación de la idea y a las posibilidades de monetizar. Esto hizo que Bumbea no quede entre los proyectos preseleccionados para ser incubados por el CIE. Se recomendó desarrollar la primera versión y realizar pruebas de sondeo de recepción, para realizar un nuevo modelo de negocio y presentarse nuevamente a futuro.
2.4.Alcance del proyecto
Algunos meses antes de finalizar el proyecto, el equipo decidió enfocar esta instancia en lanzar un prototipo funcional de la plataforma y estudiar su impacto en los usuarios. La causa principal de no continuar con el emprendimiento fue que los integrantes del grupo no se sintieron dispuestos a abandonar sus puestos de trabajo para dedicarse a tiempo completo al emprendimiento.
Teniendo en cuenta la realidad mencionada anteriormente es que se definió como alcance del proyecto los siguientes puntos:
Investigación y validación de ideas
• Presentar prototipos simples para validar con potenciales usuarios de distintos perfiles. A partir de estas validaciones, procesar el feedback para identificar requerimientos, necesidades y mejoras posibles.
• Realizar pruebas de concepto con las APIs (Application Programming Interface) de las redes sociales más populares, verificando el uso planeado de las mismas en la solución final.
• Idear una solución que cubra una necesidad real.
Desarrollo del producto
• Definir un sector del mercado al que el producto apunte inicialmente.
• Implementación de un sitio web funcional enfocado en el sector de compras de tecnología, en el que los usuarios puedan ver, realizar y compartir experiencias de compra (En el capítulo 4. Ingeniería de Requerimientos se puede ver el alcance de este punto en mayor detalle).
• Realizar acuerdos con empresas que vendan productos de tecnología con el fin de incluirlas en nuestro sitio.
• Establecer un plan de comunicación para dar a conocer el producto final.
Difusión
• Poner en práctica el plan de comunicación utilizando las redes sociales más populares con el fin de ganar una gran variedad de usuarios que utilicen el sitio. • Recolectar y procesar el feedbackque dichos usuarios provean.
• Realizar mejoras en base a las sugerencias de los usuarios.
2.5.Evolución del concepto
Teniendo siempre como objetivo el de ubicarse del lado de los usuarios y clientes para comprender sus necesidades, se trabajó con distintas ideas de proyecto, las cuales se fueron validando y evolucionando hasta lo que hoy es Bumbea.
A continuación se presenta las principales ideas en las que se trabajó y el porqué de su evolución, dejando para las secciones posteriores, la descripción de los distintos métodos y herramientas aplicadas durante todo el proceso.
• IComplain (Marzo – Mayo): En los meses iniciales del proyecto, se trabajó con la idea de realizar un sitio únicamente de quejas sobre productos y servicios, donde los usuarios se adherían masivamente a un reclamo para obtener más repercusión que de hacerlo individualmente. Si bien este concepto podría resultar valioso para los usuarios, se validó que las empresas no percibían ese mismo valor ya que no estaban preparadas todavía para un nuevo canal de recepción de feedback negativo.
de distribuir esas campañas en las redes sociales y recolectar toda su repercusión.
• Sitio de reviews con análisis de campañas (Julio - Septiembre): En este período se incorporó al sitio de reviews el módulo de gestión y monitoreo de campañas en las redes sociales, brindándole a las empresas informes de su repercusión de acuerdo a sus necesidades. Se validaron prototipos con las empresas y los expertos en marketing, y se llegó a la conclusión de que, por un lado la idea se estaba centrando demasiado en las empresas y había perdido el foco en los usuarios (fundamentales para hacer crecer el sitio). Por otro lado, ya existían sitios y agencias de publicidad que ofrecían servicios similares, por lo que la competencia se tornaba aún más grande.
• Bumbea (Septiembre – Actualidad): En la búsqueda de centrarse nuevamente en los usuarios, se detectó la necesidad de contar con información objetiva y centralizada sobre qué y dónde realizar una compra de un producto. Fue este motivo por el cual se decidió evolucionar hacia el concepto de mejorar la experiencia de compra que propone Bumbea, el cual fue validado exitosamente por los distintos interesados.
2.6.Conformación del equipo
Responsabilidad de roles:
• Scrum master: Asegura que se sigue el proceso y organiza los daily scrums, sprint reviews y sprint planning. Fue imprescindible para la correcta gestión del proyecto, por lo que su participación fue activa durante todo el proyecto [3]. • Product owner: Es el encargado de que se realicen los requerimientos según lo
• Arquitecto: Es el responsable por la arquitectura de la solución. Su rol pasó a ser activo cuando se acercaba el momento de comenzar la construcción del producto para definir una arquitectura base y aún más activo luego de que el producto se definiera con mayor precisión.
• SQA: Es el encargado de definir modelos de pruebas, de que se prueben las
user stories implementadas, y de determinar y controlar que se sigan estándares. Este rol fue necesario luego de que se comenzó a construir la solución, ya que se aseguraba de que todo lo que se realizaba había sido probado y que, por lo tanto, los bugs en cada publicación eran mínimos.
• Desarrollo: Todo el equipo participó en las tareas de codificación.
• SCM: define y explica herramientas a usar en el proyecto, es responsable del control de cambios, del manejo de los repositorios y versionado de los distintos elementos.
• User Interaction and User Experience (UI y UX): asesor y referente en temas de UI y UX. Fue necesario incluir este rol dado que sólo uno de los integrantes poseía experiencia en diseño de interfaces gráficas [4].
El equipo de proyecto estuvo conformado por:
Figura 2.2. – Integrantes del equipo de Bumbea
El interés por desarrollar una idea propia implicó que todos los integrantes quisieran participar en las decisiones y actividades de definición del producto, es por esto que en la primera mitad del proyecto no se respetó completamente la asignación de roles (a excepción del Scrum Master ya que era necesario que alguien planifique las reuniones). Todo el equipo asistía a reuniones con clientes, realizaba entrevistas, ideaba prototipos y participaba de las tormentas de ideas hasta que el producto quedó definido. Sin embargo, se dividieron algunas tareas de investigación o realización de prototipos según la disponibilidad de cada uno en el momento o su interés por investigar un tema específico.
Si bien las decisiones importantes fueron tomadas en conjunto, también fue necesario delegar actividades por áreas para avanzar más rápido con el proyecto. Por lo tanto, se decidió identificar roles y asignarles un responsable. El responsable del área fue el principal encargado de planificar tareas para su área (y eventualmente también hacerlas), de controlar que se realicen según lo estipulado, de que se genere la documentación adecuada y de responder a terceros sobre temas relacionados a su área (ya sea en revisiones, defensa final, reuniones con tutor). Para definir a estos responsables se realizó una matriz de interesados (Ver figura 2.3) para los roles identificados, en la que inicialmente había más de un interesado por área pero que se terminó acotando a un único responsable. La única excepción a esto es con el desarrollo, en el cual participaron todos los integrantes por igual, ya que el aprendizaje de nuevas tecnologías como lenguajes de programación, manejador de versiones, entre otras actividades, eran de interés común para todo el equipo.
Agustín Bruno Camilo Dayana Diego
Scrum master X
Product owner X
Arquitecto X
SQA X
Desarrollo X X X X X
UI y UX X
3.
Metodología de trabajo
Comenzando con la idea básica de crear un sitio para compartir comentarios y quejas sobre productos y servicios, se buscó implementar una metodología capaz de transformar esa idea en un producto innovador y validado bajo distintos puntos de vista.
Considerando que la innovación y la interacción con los interesados son los pilares en los que se basa nuestro proyecto, se decidió aplicar el ciclo de vida evolutivo que provee Design Thinking[5] para llegar a su solución. Fue con esta metodología con la que se llevó a cabo la ingeniería de requerimientos, pudiendo definir el problema y la solución que hoy en día propone Bumbea.
Dado que Design Thinking está enfocado en el diseño conceptual de productos, decidimos complementarla con una metodología de gestión de proyectos. La indicada para esto fue Scrum, ya que su filosofía basada en el trabajo evolutivo y con equipos cohesivos es compatible con Design Thinking. Otros de los puntos clave para integrar ambas metodologías fue la utilización de user stories. Son una representación de un requisito de software escrito en una o dos frases utilizando el lenguaje común del usuario [6]. Esta representación por lo tanto es compatible con la visión de Design Thinking, y a su vez, permite estimar y controlar las tareas asociadas a las user stories
en un entorno ágil de gestión.
Para que todos los integrantes del equipo puedan comprender el funcionamiento de ambas y apegarse a sus lineamentos, se generaron y distribuyeron documentos y guías de buenas prácticas dentro del equipo.
3.1.Proceso creativo: Metodología Design Thinking
3.1.1. Introducción a la metodología
Design Thinking es una metodología para resolver problemas centrada en la innovación y en la interacción continua con los distintos actores involucrados. Utiliza el mismo enfoque con el que un diseñador enfrenta y resuelve problemas de diseño. Con esto se busca hacer coincidir las necesidades de las personas con lo tecnológicamente factible y viable desde el punto de vista del negocio. Este enfoque consta de los siguientes principios:
• Centrado en los usuarios: Tener empatía por las personas para las cuales se diseña y retroalimentarse de las mismas para lograr un buen diseño.
• Colaborativo: Integrar al equipo personas de variadas disciplinas y puntos de vista.
• Estar consciente del proceso: Tener claro el proceso de diseño y saber qué métodos utilizar en cada fase.
• Cultura de prototipo: Realizar prototipos es una parte integral del proceso de innovación.
• “No lo digas, muéstralo” [5]: Comunicar la visión del equipo de una manera impactante, creando experiencias, usando ilustraciones y contando buenas historias.
La definición de las etapas en esta metodología, es pensada para que el proceso de innovación sea un proceso sistemático y no una acción puntual de algún integrante del equipo. Su enfoque evolutivo y con alta comunicación entre los miembros del equipo, lo hace de fácil integración con metodologías ágiles de gestión.
Figura 3.1. Etapas de Design Thinking
• Empatizar: En la etapa de empatizar se pone al usuario o cliente en el centro del proceso de innovación. Se utilizan técnicas como la observación de campo, entrevistas a profundidad, pasar un día en la vida del cliente, entre otras, para encontrar oportunidades de innovación.
• Definir: una vez que se tiene un conocimiento profundo del cliente, se define el problema en el que se va a innovar.
• Idear: se generan ideas creativas para solucionar el problema. La diferencia con otras metodologías es que se realizan brainstormings (tormenta de ideas) tras haber pasado por las etapas de empatizar y definir, lo que lleva a ideas más centradas en necesidades reales de los usuarios. Esta técnica tiene como objetivo generar grupalmente una lista de ideas para el producto que se va a crear [7].
• Prototipar y validar: se reduce el riesgo del proceso de innovación al generar prototipos rápidos y baratos que pueden probarse inmediatamente con el cliente.
3.1.2. Aplicación de la metodología al proyecto
Tomando como base los conceptos generales de la metodología Design Thinking, se buscó aplicar la gran mayoría de ellos a este proyecto, realizando los ajustes necesarios para adaptarlos a los tiempos y necesidades del equipo.
estrictamente como se propone en la bibliografía, por lo que hubo que adaptarla a la realidad del equipo.
Para poder llegar a prototipar y validar ideas lo más rápido posible (lo recomendado para esta metodología) fue necesario en algunas iteraciones cambiar el orden de las etapas o incluso suprimir alguna de ellas, principalmente etapas de empatizar y definir. Para estos casos se optó por realizar varias reuniones con empresas en períodos cortos de tiempo, de modo de relevar la suficiente información como para que sea utilizada en más de una iteración. Si bien esto es admitido normalmente en la dinámica de Design Thinking, fue parte del aprendizaje del proyecto analizar cuándo aplicar estos ajustes.
Todos los miembros del equipo participaron en mayor o menor medida de todas las actividades, priorizando la experiencia de ser parte de reuniones con empresas, brainstormings y construcción de diversos prototipos, antes que la dedicación exclusiva de un integrante para una tarea específica.
Como ningún integrante del equipo había trabajado alguna vez con esta metodología, se utilizó el registro de lecciones aprendidas al finalizar cada iteración, de forma tal de aplicarlas a futuro para obtener el máximo provecho de Design Thinking. Este proceso se encuentra detallado con más profundidad en el capítulo 9: Gestión del proyecto.
3.1.3. Técnicas para empatizar y definir
Las técnicas utilizadas durante las etapas de empatizar y definir (dentro de las cuales se desarrolló gran parte de la ingeniería de requerimientos del proyecto), fueron las siguientes:
Reuniones con interesados
mercado, se decidió enfocarse en el sector tecnológico, dejando las características específicas del mismo para ser relevadas mediante el estudio de un grupo foco de usuarios. Todos los integrantes del equipo participaron en las entrevistas, yendo a las mismas en grupos de a tres personas.
Las empresas con las cuales se mantuvieron entrevistas fueron las siguientes:
• Divino
• Manos del Uruguay • Sensia cosméticos • Transcargo
• La Isla Surf Shop • Punto Arte
Al ser nuestro sitio un nuevo canal para promocionar productos por internet y que a su vez convive con las redes sociales, se detectó que uno de los pilares para el éxito del mismo es el marketing digital. Como todos los integrantes del equipo sólo poseen formación en ingeniería, fue necesario contactar expertos teóricos en marketing digital y personas con experiencia en community management. Este último es quien actúa como auditor de la marca en los medios sociales, haciendo de intermediario entre la empresa y el público hacia el que está dirigido [8].
También, con el objetivo de comprender aspectos claves para transformar la idea en un negocio, se mantuvieron reuniones con Enrique Topolansky, coordinador del CIE en Universidad ORT Uruguay. Con su ayuda, se elaboró el primer plan de negocios del proyecto (ver Anexo VI. Plan de negocios), y se validaron también aspectos de marketing y comunicación.
Tanto las entrevistas con empresas, como con el experto en marketing y el CIE, fueron grabadas y almacenadas en el repositorio de documentos. Cada una de ellas fue analizada posteriormente, ingresando las conclusiones en una planilla. Un ejemplo de esto puede verse a continuación:
Fecha Reunión Conclusiones
1/8/2012 Jorge Freyer • Nos recomendó enfocarnos en el rol de influenciar a los consumidores para la toma de decisiones.
• El marketing en nuestra idea está en comprender el valor que tiene la influencia para elegir un producto o servicio, o una marca, y cómo lo manejas.
• Necesitamos un especialista en negocios para que nos guíe
• Nos recomendó profundizar en las ventajas que tiene con respecto a usar redes sociales.
9/9/2012 Lucía Krygier • A las empresas les interesa que le vayamos procesando la información en nuestro sitio.
• Mezclar las opiniones de la gente con la publicidad de las empresas puede generar desconfianza de la gente.
• Construir la página en función de cómo navega la gente. 17/10/2012 Enrique
Topolansky
• Ofrecer un servicio de gestión de campañas origina una mayor competencia, ya que hay sitios y agencias de publicidad que ofrecen servicios similares.
• Crear un video de corta duración para hacer conocer el sitio.
Análisis de sentimientos
Es una técnica de Design Thinking [5] que busca mediante entrevistas con usuarios, entender sus pensamientos, emociones y motivaciones para determinar cómo innovar para ellos.
Esta técnica fue aplicada realizando entrevistas a 20 personas, cuyas preguntas estuvieron destinadas a comprender fundamentalmente su motivación al momento de quejarse sobre un producto o servicio que no cumplió sus expectativas.
Como conclusión de estas entrevistas, se realizó un diagrama que representa el ciclo de la queja, en el cual identificamos aquellos momentos clave que originan la disconformidad de los usuarios con las empresas y en el que nuestro sitio puede intervenir. El mismo puede apreciarse en el Anexo II. Ciclo de vida de la queja.
3.1.4. Técnicas para idear
¿Matriz de Qué? ¿Cómo? ¿Por qué?
¿Qué? ¿Por qué? ¿Cómo?
Usuarios
Información al momento de decidir sobre qué comprar. Hacer reviews. Mejorar experiencia de la queja.
Beneficios por participar.
Menor riesgo en la compra.
Compartir/mejorar /validar.
Aumentar la posibilidad de lograr algo.
Consumismo.
Muchas Reviews (+/-), beneficios.
Distribuir por redes sociales y estrategias (por ejemplo, QR en local).
Distribuir por redes sociales, respuesta, ranking (lista negra de empresas)
Iniciativas por parte de las empresas.
Empresas
Ayudarlas en el momento en que sus clientes se informan. Recibir feedback Análisis de mercado y competencia.
Atraer Clientes. Mejorar nexo con clientes.
Toma de decisiones.
Clientes dan Reviews positivas sobre sus servicios y comparten en redes sociales. Ofrecer beneficios, derecho a réplica para reviews negativas. Estrategias para incrementar clientes (QR, publicidad en redes sociales y nuestro sitio)
Figura 3.3. - Matriz de Qué, Cómo, Por qué. Notar que cada idea de la columna “QUE” se corresponde con la del mismo número en las otras columnas
Brainstormings
Elevator pitch
El elevator pitch [9] es un discurso breve que se utiliza para definir rápidamente un producto y su propuesta de valor entre aproximadamente 30 segundos y dos minutos. El mismo fue realizado con el objetivo de captar rápidamente el interés y describirles la problemática que se quería resolver a los entrevistados. Para asegurar esto, se llevaron a cabo varias instancias de mejora y ensayo del pitch, siendo validado por el tutor en cada ocasión. Se utilizó tanto en las primeras entrevistas con las empresas, como en las reuniones con el CIE y el experto en marketing.
Prototipos desechables
“El (MVP) es la versión de un nuevo producto que permite a un equipo recoger la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo.” [10]
La principal herramienta utilizada tanto para la validación con las empresas, como interna al grupo, fue la construcción de distintos MVP mediante prototipos desechables en papel, html, y mockups (modelo a escala de un diseño o dispositivo [11]). Al emplear esta técnica recomendada para Design Thinking, se ahorró el esfuerzo de construir innecesariamente prototipos funcionales de software, y se obtuvo el feedback necesario para incorporarlo en las próximas iteraciones. Para muchas de las reuniones se construyeron prototipos personalizados para cada empresa, los cuales pueden verse en detalle en el Anexo I. Prototipos.
A continuación se puede ver un ejemplo de la evolución del prototipo de “Ver
Figura 3.4. - Prototipo en papel de "Ver Reviews"
Figura 3.5. – Mockup de la user story “Ver Reviews”.
Figura 3.6– Mockup final de la user story “Ver Reviews”.
3.1.5. Técnicas de validación
Reuniones con empresas
Feedback a través del sitio
Desde la primera versión publicada del sitio web, se contó con una sección para que los usuarios puedan ingresar sugerencias de mejora. Mediante la ejecución del plan de comunicaciones, esta cantidad se incrementó considerablemente. Todas las sugerencias recibidas fueron registradas, categorizadas y analizadas posteriormente.
3.2.Metodología para gestión y desarrollo del software: Scrum
La metodología que se aplicó para gestionar el proyecto fue Scrum [12]. Se decidió implementar esta metodología debido a la naturaleza del proyecto elegido. Como no se cuenta con una lista de requerimientos definidos sino que, por el contrario, los mismos son inestables, se descartaron metodologías tradicionales (por ejemplo, cascada) y se buscó un enfoque evolutivo. Esto permite que un cambio en los requerimientos se acople directamente a lo ya realizado en iteraciones anteriores o que no sea costoso descartar y re-implementarlo.
También Scrum se adapta a las características del equipo, ya que es pensado para ser utilizada por equipos pequeños pero con fuerte comunicación entre ellos. Sin embargo, se tienen algunas particularidades propias del proyecto que imposibilitaron aplicar esta metodología en su totalidad.
4.
Ingeniería de requerimientos
Como resultado de haber aplicado Design Thinking, se pudieron definir los actores que forman parte del sitio y sus necesidades al momento de decidir sobre la compra de un producto de tecnología. Fue a partir de esto que se elaboró una lista de requerimientos funcionales, la cual permitió la realización de las user stories que se debían desarrollar.
Los actores identificados y sus necesidades son:
• Usuario Consumidor: Es el usuario consumidor de productos de tecnología que busca informarse sobre qué producto comprar, o bien compartir su experiencia de compra con otros usuarios. Este usuario necesita:
o Conocer la opinión de la gente que ya experimentó el producto sobre el que
desea informarse, o ya realizó una compra en el negocio en donde él piensa comprarlo.
o Que estas opiniones estén centralizadas en un único lugar y sean fáciles de
acceder.
o Que estas opiniones sean objetivas (que no sean influenciadas por
beneficios ofrecidos por empresas a cambio de buenas reviews).
o Conocer los productos y opiniones más valorados por los usuarios. o Poder descubrir nuevos productos de tecnología y sus opiniones.
o Contar con información completa y actualizada sobre los productos y sus
aspectos técnicos. A su vez, que los productos sean rápidos de encontrar dentro del sitio.
o Para el producto que desea comprar, poder decidir la empresa en dónde
o Compartir su experiencia de compra de un producto de tecnología no sólo
dentro del sitio, sino también con sus contactos en las principales redes sociales.
• Usuario Empresa: Es el usuario que representa a una empresa que vende productos de tecnología, y busca estar presente en el momento en que los consumidores buscan concretar una compra. Este usuario necesita:
o Dar a conocer a los consumidores los productos de tecnología que vende. o Que los consumidores conozcan opiniones objetivas sobre la empresa
realizadas por otros usuarios.
o Que un consumidor decida comprar un producto en su empresa gracias a la
información que encontró en el sitio.
o Dar a conocer a los consumidores su información de contacto y localización.
• Administrador: Es el usuario encargado de mantener la información completa y actualizada sobre los productos del sitio, y a su vez, de controlar que las reviews se realicen correctamente. Sus funciones comprenden:
o Ingresar productos nuevos y realizar modificaciones a los ya presentes. o Incorporar imágenes y los detalles técnicos de los nuevos productos
ingresados.
o Analizar las reviews denunciadas por otros usuarios.
o Eliminar reviews que violen las políticas del sitio (creadas por usuarios falsos
o contienen vocabulario inapropiado).
• Cnet: ofrece información de productos tecnológicos, revisiones, novedades y precios.
• Gsmarena: ofrece información técnica de celulares, revisiones, novedades, opiniones, votaciones, permitiendo también ver la evolución del precio del dispositivo así como sugerencias de dónde comprarlo.
• Amazon: Además de ser un negocio online que ofrece entre otras cosas productos de tecnología, brinda a sus usuarios revisiones, opiniones, descripciones, historial de precios de todos sus productos (incluidos los de tecnología).
• Mercadolibre: Ofrece entre tantas cosas, productos de tecnología, y permite que se realicen comentarios sobre los vendedores.
• Uguana: Sitio que proporciona información de distintos productos y empresas en distintos rubros dentro de los cuales se incluye el de la tecnología.
• ComparoyGano: Sitio que proporciona información de productos así como de los distintos puntos de venta con el objetivo de fomentar la “compra inteligente”.
Esta investigación permitió reforzar el concepto de que los usuarios valoran experiencias de otros usuarios y que actualmente el componente visual es un factor importante, así como lo es la integración con las redes sociales. Además, a partir de este análisis, se decidió que los usuarios deban destacar brevemente en las reviews, los puntos a favor y en contra de su experiencia. De esta manera otros usuarios consiguen rápidamente una visión general de lo que fue la experiencia. Gracias a ésta investigación el equipo pudo terminar de definir y priorizar las funcionalidades que hoy brinda Bumbea.
• Módulo Productos: El objetivo de este módulo es brindarles a los usuarios toda la información disponible de los productos presentes en Bumbea. Los usuarios podrán:
o Buscar un producto por su nombre.
o Ver productos destacados, más vistos, por categoría.
o Ver información general del producto (reviews, calificación promedio,
imágenes y lista de empresas que lo venden).
o Ver detalles técnicos de un producto. o Crear nuevos productos.
o Compartir producto en las redes sociales. o Denunciar un producto.
• Módulo Reviews: Este módulo es el que permite a los usuarios compartir sus experiencias con los demás usuarios de Bumbea. Para ello, los usuarios podrán:
o Publicar una review de la experiencia de compra. Valorar la experiencia con puntaje de 1 a 5. Describir ventajas y desventajas de la experiencia. Informar el lugar de la compra.
Comentarios de la experiencia.
o Marcar una review como útil.
o Compartir review en las redes sociales. o Denunciar una review.
• Módulo redes sociales Facebook y Twitter:El objetivo de este módulo permitir a los usuarios autenticarse mediante las redes sociales Facebook y Twitter. El usuario podrá:
o Acceder a las cuentas del sitio en las redes sociales.
• Módulo Empresas: Este módulo se enfoca en la información sobre las empresas que ofrecen productos de tecnología. Dentro del sitio, el usuario podrá:
o Ver información de una empresa (Ubicación, horario de atención,
número de teléfono, sitio web, cantidad de productos y reviews en el sitio).
o Ver catálogo de productos de una empresa. o Crear una nueva empresa en el sitio.
• Otros:
o Autenticarse vía mail.
o Ver información acerca de qué es Bumbea. o Ver información acerca del equipo de Bumbea.
o Ver información acerca de las condiciones del servicio.
4.1.Requerimientos no funcionales
En esta sección se detallarán los requerimientos no funcionales que fueron considerados al momento del diseño e implementación del sitio.
Los requerimientos que se listan a continuación son características de calidad que sirven para medir el grado de satisfacción de los usuarios y/o desarrolladores con respecto al sitio. En el capítulo VII. Gestión de calidad, se presenta una sección de métricas en las cuales se detallan las acciones tomadas para validar los siguientes requerimientos no funcionales y los resultados obtenidos.
o Un usuario debe poder crear una review en menos de 2 minutos
(incluyendo el tiempo de redacción de la experiencia).
o Se espera que al menos el 50% de los usuarios que se registran en el
sitio creen una review.
• Eficiencia: refiere a los eventos que ocurren y a los cuales el sitio debe responder en un determinado tiempo consumiendo la menor cantidad de recursos [13].
o Las respuestas a acciones sobre el sitio deben realizarse en un tiempo
menor a 10 segundos.
• Disponibilidad: refiere a las fallas del sistema y sus consecuencias. Una falla del sistema ocurre cuando el mismo no es capaz de seguir proporcionando un servicio consistente con su especificación. Estas fallas son observables por usuarios del sistema (humanos u otros sistemas) [13].
o La disponibilidad de Bumbea debe ser de al menos un 99,9%. Es decir
que en un año, se aceptará que Bumbea no esté operativo 8,76 horas.
• Modificabilidad: refiere al costo de realizar cambios (anticipados o no) sobre el sitio. Es decir cuán fácil es de cambiar la implementación de un componente (o el componente entero) sin que este cambio se propague sobre el resto de la arquitectura [13]. Dado que el sitio se valida constantemente con usuarios y la poca experiencia del equipo en este tipo de proyectos, el sitio debe ser adaptable a posible modificaciones que surjan en las reglas de negocio o en el diseño de la solución.
• El lenguaje de programación elegido para desarrollar el sitio fue C# (C sharp) aunque también se utilizó el lenguaje Javascript del lado del cliente (en las páginas HTML). Si bien se consideraron otros lenguajes, la elección de estos se debió fundamentalmente a la experiencia que los integrantes del equipo tienen con ellos.
• El sitio se alojó en la plataforma de servicios en la nube que ofrece Windows Azure Platform. “Windows Azure es un sistema operativo nube que se usa para el desarrollo, hospedaje de servicios y entorno de administración de servicios de la plataforma Windows Azure. La plataforma Windows Azure está compuesta por una infraestructura de hardware, software, red y recursos de almacenamiento. [14]”. En la sección 5.2.4 Vista de despliegue se puede encontrar la justificación de esta decisión.
5.
Diseño arquitectónico
El propósito de este capítulo es proveer la especificación del diseño arquitectónico del sitio. Para lograr esto, se usarán diferentes vistas arquitectónicas que ilustren las características más importantes del sitio. Se pretende capturar y transmitir las decisiones más importantes realizadas durante el proceso de desarrollo y los principales atributos de calidad del sitio.
En este capítulo también se podrá encontrar información acerca de las distintas tecnologías utilizadas así como las pruebas de concepto realizadas para la implementación de las diferentes user stories.
5.1.Características de calidad
Para determinar las características de calidad que debería tener el sitio, el grupo se basó principalmente en dos factores.
Dado que el problema que pretende solucionar el sitio es mejorar la experiencia de compra, la experiencia de los usuarios al utilizar Bumbea debe ser positiva, realizando el menor esfuerzo posible. Por lo tanto la Usabilidad, Eficiencia y Disponibilidad son características de calidad fundamentales que deben tener el sitio.
• Usabilidad: se hizo especial hincapié en la interfaz gráfica y experiencia del usuario en el sitio. Para esto se utilizaron tecnologías y componentes ricos visualmente que permitieran crear pantallas atractivas, además de una buena disposición de los elementos de las mismas para hacer el sitio más intuitivo. • Eficiencia: durante el proceso de desarrollo se tuvo presente este atributo y se
realizaron distintas tareas para monitorear el tiempo y los recursos necesarios para responder a las acciones realizadas por el usuario en el sitio.
pudo ayudar a controlar el uso de recursos (por ejemplo conexiones abiertas con la base de datos e interacciones con servicios de terceros).
A su vez se realizaron las siguientes acciones con los recursos estáticos de forma que la carga de los mismos impacte lo menos posible en la performance
del sitio:
o Se optimizaron las imágenes.
o Se utilizaron mecanismos para cargar las imágenes en paralelo. o Se minimizaron los archivos Javascript y las hojas de estilos.
• Disponibilidad: la arquitectura de servidores en la nube que ofrece Windows Azure garantiza que el servicio web esté disponible un 99,95% del tiempo. También, en caso de que una instancia no se esté ejecutando correctamente, se realiza una corrección en un plazo de dos minutos [16]. La elección de Windows Azure como servicio de hosting se explica con más detalle en la sección 5.2.4. Vista de despliegue.
Cada falla que se produce en el sitio es registrada en una base de datos a parte que se utiliza para el registro de información (logueo). A su vez en caso de producirse una falla en el sistema, la misma se presenta al usuario con un comentario amigable y notificando que ya se ha informado al equipo para solucionarla lo antes posible. A pesar de la falla, el sistema continúa funcionando de forma correcta.
El segundo factor se debe a la naturaleza del proyecto. Dado que se buscó innovar utilizando la metodología Design Thinking, sumado a la inexperiencia del equipo, era un muy factible que el producto sufriera cambios durante el transcurso del proyecto. Es por esto que la Modificabilidad de la aplicación es otro atributo de calidad que se decidió tener en cuenta.
que cada uno cumpla únicamente su función y estén débilmente acoplados para ser fácilmente modificables y remplazables.
Se respetaron todos los estándares de codificación, utilizando herramientas de análisis de código para validar que los mismos se cumplan. Como se comentó anteriormente, cada componente y sus clases realizan solamente el trabajo para el cual fueron creados, delegando tareas que no les corresponden a otros componentes. Esto incrementa mucho la Modificabilidad al evitar código duplicado y clases con más de un motivo de cambio (varias responsabilidades).
5.2.Descripción de la arquitectura
En esta sección se describe el sistema desde diferentes puntos de vista de manera de comunicar y registrar la arquitectura del sistema. Se utiliza la notación UML 2.0 y el objetivo de esta sección es describir como se resuelven los atributos de calidad mediante la utilización de patrones arquitectónicos y tácticas.
La descripción de la misma estará estructurada según el modelo 4 + 1 [17] que incluye un conjunto de vistas las cuales describen determinados aspectos de la arquitectura del sistema. El diseño de la misma se basó en la arquitectura propuesta por Microsoft para el desarrollo de aplicaciones web en el libro Microsoft Application Architecture Guide, 2nd Edition [18].
5.2.1. Vista de user stories
Figura 5.2 - Diagrama de user stories del módulo Reviews
Figura 5.4. - Diagrama de user stories varios
En el diagrama de secuencia a continuación, se representa el flujo necesario para que un usuario cree una review en el sitio. En el mismo se puede observar que en caso de que el producto o empresa no existiera al momento de crear la review, el usuario puede crearlos fácilmente sin necesidad de abandonar el proceso de creación de la misma.
Figura 5.6. - Diagrama de Secuencia sobre Crear una Review
5.2.2. Vista de diseño
Como se mencionó anteriormente, el diseño arquitectónico del sitio se basa en la arquitectura propuesta por Microsoftpara el desarrollo de aplicaciones web. El mismo está basado en el estilo Capas lógicas o Layers que provee niveles acumulativos de abstracción. Es decir que cada capa agrupa componentes encargados de determinadas tareas dentro de la arquitectura.
hacia abajo). Con esto buscamos separar las responsabilidades en distintos módulos, minimizar el acoplamiento entre los mismos y reducir el impacto de cambio para favorecer la modificabilidad del sitio.
Cada capa oculta los detalles de implementación a las capas adyacentes a través de interfaces bien definidas que exponen los servicios de la misma, favoreciendo el reúso y la modificabilidad. Sin embargo, un cambio de comportamiento en una capa puede tener gran impacto debido a la propagación del cambio a través del resto de las capas.
Asimismo, al generar estas agrupaciones por nivel de abstracción, estamos permitiendo que en un futuro las capas puedan ser distribuidas físicamente, lo que mejora la escalabilidad.
Figura 5.7. - Diseño de la Arquitectura del Sitio [17]
De esta forma, el diseño cuenta con tres capas claramente definidas, las cuales son: • Presentation Layer: En esta capa se implementó el patrón MVC y únicamente
contiene la interfaz de usuario junto con la lógica de presentación. “Modelo Vista Controlador (MVC) es un patrón o modelo de abstracción de desarrollo de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos.“ [19].
qué datos son necesarios almacenar o consultar (lo cual no se realiza directamente, sino que se utiliza la capa de acceso a datos).
• Data Access Layer:Es la encargada de interactuar con el repositorio de datos de forma de almacenar, modificar y consultar los datos del sitio. Esta capa también contiene los componentes responsables de establecer la comunicación con servicios de terceros, como ser Twitter, Facebook y Bitly (servicio online de reducción de URL). El único punto de acceso a esta capa es a través de un componente que implementa el patrón “Unit Of Work”.
• Cross-Cutting Concerns
o Business Common: En esta capa se encuentran los objetos que
representarán las entidades del sitio. Si bien se evaluó ubicar las
Business Entities en la capa de negocio, finalmente se optó ubicar las mismas como una capa transversal y crear objetos de transferencia de información para utilizarlos en la capa de presentación.
El principal motivo de esta decisión fue porque se previó la implementación de una capa de servicios que maneje objetos de menor tamaño para favorecer la escalabilidad y performance del sitio.
o Common: Esta capa contiene componentes encargados del “logueo”,
5.2.3. Vista de componentes
Presentation Layer
A nivel de la capa de presentación se crearon cinco componentes, de los cuales tres de ellos corresponden a la implementación del patrón MVC.
Las Vistas, Controladores y Modelos se desplegaron en distintos componentes para facilitar la organización y coordinación del equipo de desarrollo. Dado que el repositorio de código no iba a permitir el “multiple check-out” (se explicará el por qué en el capítulo de 6. Gestión de la configuración), esta decisión permitió organizar mejor el trabajo de los miembros del equipo, ya que, solo habría un único motivo para hacer check-out de un archivo de proyecto y no tres.
• UInterface.Controllers: Este componente contiene los controladores de la implementación del patrón MVC. Tiene la lógica para manejar las interacciones del usuario con la interfaz gráfica, lógica para manejar el modelo y por último, decidir que vista mostrar al usuario. No tiene lógica de negocio ni consulta directamente a la capa de negocio.
• Interface.Managers: Estos objetos son fachadas que contienen la lógica de consulta a la capa de negocio, y son invocados por los controladores para cargar la información en el modelo. De esta manera se limita a que los controladores solamente tengan lógica para controlar la interfaz gráfica y el modelo dejándolos más simples y entendibles.
cualquier acción de los controladores y sirve para medir la performance del sitio.
• UInterface.Utilities: Este componente contiene clases que proporcionan distintos tipos de utilidades únicamente a la interfaz gráfica. En este componente, se pueden encontrar distintas extensiones de clases propias del framework ASP.NET MVC 3, para lograr objetivos como interceptar las llamadas a los controladores para logueo de información. También se pueden encontrar clases que proveen funciones varias, cuya lógica no corresponde a ninguno de los demás componentes de esta capa.
Business Layer
Esta capa solamente contiene el componente BusinessComponents que encapsula la lógica de negocio. Por “lógica de negocio” se está haciendo referencia a la lógica de la aplicación que se encarga de implementar las reglas de negocio y comportamiento de la aplicación.
Data Access Layer
• DataAccessFactory: Este componente, como lo sugiere el nombre, es una implementación del patrón Fábrica para obtener la implementación del patrón Unit Of Work.
El patrón Unit Of Work “mantiene una lista de objetos afectados por una transacción de negocio y coordina la escritura de los cambios y la resolución de problemas de concurrencia.” [20].
dependen para realizar su trabajo. En su lugar, obtienen los objetos a través de una fuente externa (por ejemplo un archivo de configuración) [21].
• DataAccess.UnitOfWork: Este componente maneja el ciclo de vida y el contexto de los repositorios. Esto nos permite mejorar la performance de la plataforma ya que se reduce la cantidad de conexiones que se abren y cierran.
• DataAccess.Interfaces: Este componente contiene las interfaces que definen las operaciones de los Service Agents y la interface del Unit Of Work.
• DataAccess.ServiceAgents: Este componente se encarga de resolver el acceso a las API (Application Programming Interface) de terceros y exponer los servicios necesarios para que se consuma dicha información desde la capa de negocio.
Business Common Layer
• CrossCutting.BusinessEntities: Este componente contiene los objetos que representan entidades de negocio. Esto quiere decir que los mismos, son objetos simples que únicamente contienen atributos que en la vida real representan un aspecto del negocio.
• CrossCutting.DTOs: Este componente contiene objetos de transferencia de información que sirven para la comunicación entre la capa de presentación y el resto de la arquitectura. Estos objetos no tienen por qué representar una entidad de negocio sino que contienen la información necesaria para ser mostrada en la interfaz gráfica en una determinada funcionalidad.
Common Layer
• CrossCutting.Exceptions: Este componente contiene todas las excepciones propias del sitio que se utilizan a lo largo de todas las capas.
por el usuario y a través de una clase estática retorna los textos del archivo de recursos.
• CrossCutting.Logging: Este componente como lo sugiere el nombre, es el responsable del logueo de información del sitio. Para lograr una solución de logueo que no estuviera acoplada a la implementación de los distintos componentes de la arquitectura, se creó un Interceptor que lo que hace es interceptar y encapsular cada llamada a los controladores. De esta manera, al codificar, el equipo no debía agregar lógica que no fuera específicamente para la funcionalidad que estaba desarrollando.
• CrossCutting.Utilities: Este componente contiene distintas clases cuya lógica no pertenece a ninguna de las capas anteriormente mencionadas.
5.2.4. Vista de despliegue
Un tema a analizar fue la elección del hosting para el sitio web. La principal traba que hubo fue el precio de los servidores, ya que para aplicaciones web .Net el precio superaba lo que se tenía pensado abonar. Sin embargo, Microsoft tiene un programa llamado Microsoft BizSpark que se compromete a ayudar a las empresas de software emergentes ofreciéndoles software como por ejemplo Windows Azure. Windows Azure es una plataforma en la nube que permite almacenar y publicar sitios web. Por lo tanto, decidimos optar por esta solución.
Una de las grandes ventajas que ofrece Windows Azurees que brinda la posibilidad de escalar rápidamente en respuesta a los cambios de demanda. Una vez creada la aplicación web, se pueden especificar la cantidad de procesadores que se quieren usar y modificarlo fácilmente a medida que el sitio lo requiera [14].
Como se puede apreciar en la figura 5.9 el diagrama de despliegue representa una arquitectura Cliente-Servidor con un solo nodo que contiene el sitio web, la lógica de la aplicación y las bases de datos de logueo y del negocio. Si bien se crearon distintos componentes mapeándolos con cada elemento descripto de las capas lógicas, no era necesario desplegarlos en distintas capas físicas debido a que por el momento no se cuenta con una gran demanda de usuarios. No obstante, el diseño contempla la implementación de una capa de servicios y la distribución de los componentes en distintas capas físicas.
5.3.Herramientas y tecnologías utilizadas
A continuación se describen las distintas tecnologías y herramientas utilizadas durante el proceso de desarrollo.
5.3.1. Presentation Layer
• ASP.NET MVC3: tecnología para desarrollar aplicaciones web utilizando el patrón MVC. Esta tecnología/patrón permite tener una clara separación de responsabilidades lo que repercute en la modificabilidad y escalabilidad, además de facilitar el desarrollo en paralelo. Otra de las tantas ventajas es que se tiene total control del HTML generado ya que no se utilizan controles que añaden su propio markup o HTML. Esto permite mejor integración con librerías como jQuery entre otras.
• HTML 5: como lenguaje de markup se utilizó HTML 5 que permite tener páginas mejor estructuradas y más comprensibles, entre otros beneficios.
• jQuery y jQuery UI: para simplificar la codificación del lado del cliente (browser
o navegador web) se utilizó la librería jQuery que hace más fácil la manera de interactuar con los documentos HTML, agregar interacción con la táctica AJAX, entre otras [22]. Además, para implementar algunas funcionalidades se utilizó jQuery UI [23] que es una biblioteca de componentes visuales y efectos para la librería jQuery [24].
5.3.2. Business Layer
5.3.3. Data Access Layer
• Entity Framework: ORM (Object-Relational Mapping) que permite al desarrollador trabajar con los datos relacionales utilizando objetos del dominio. Se utilizó el enfoque de code-first y aunque Entity Framework implementa el patrón Unit Of Work (mediante el uso de la clase DataContext) se decidió hacer una implementación propia de este patrón por encima del que provee Entity Framework. De no hacer esto, el sitio queda atado a utilizar esta tecnología, siendo muy costoso si en el futuro se quiere cambiar de ORM o utilizar otra forma de acceso a datos. Esta decisión aumenta mucho la Modificabilidad del sistema.
• Castle Windsor: a nivel de la capa de acceso a datos, se utilizó Castle Windsor para implementar la inversión de control del componente DataAccess.UnitOfWork. También se utilizó en la capa de presentación inyectar a los controladores el Interceptor que contiene la lógica de logueo. De esta manera cada llamada a las acciones de los controladores es interceptada pudiendo loguear la información que se considere necesaria.
5.3.4. Business Common Layer
Esta capa contiene las entidades de negocio que son objetos simples (POCO Entities) y objetos de transferencia de información, por lo cual no fue necesario el uso de tecnologías adicionales.
5.4.Pruebas de concepto
Si bien la innovación del proyecto está dada por el negocio y no por la tecnología, una pieza fundamental de la idea es conectar el sitio con las redes sociales u otros servicios. Cada plataforma cuenta con una API y documentación sobre cómo usarla en determinados lenguajes de programación. El principal riesgo claramente era poder conectar el sitio a los servicios de terceros desde el lenguaje de programación C#.
Se utilizaron cuentas de Facebook y Twitter para realizar pruebas de concepto que lograran las siguientes funcionalidades:
• Autenticación
• Obtención de información del usuario • Realizar una nueva publicación
Dado que Twittersolo permite publicaciones de no más de 140 caracteres, se decidió utilizar un servicio llamado Bitlyque permitiera acortar las URLs que se incluyan en la publicación.
Por último, también se realizaron pruebas de concepto con la API de Google Places para poder obtener información acerca de locales y comercios. Al registrar una experiencia en el sitio, esto permitiría sugerir al usuario lugares donde puede haber realizado la compra.
En ninguno de los casos anteriores se obtuvo problemas, por lo que se verificó que era posible consumir estos servicios desde el lenguaje de programación C#.
5.5.Conclusiones del área
