UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA DEPARTAMENTO DE TECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN

Transcripción

1 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA DEPARTAMENTO DE TECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN TRABAJO FIN DE GRADO Aplicación Social GEOME Autor: Javier García Ceca Director: Manuel Ángel Serrano Martín Junio, 2015 i

2 TRIBUNAL: Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL Fdo.: Fdo.: SECRETARIO Fdo.: ii

3 RESUMEN GeoMe es una aplicación social basada en la geolocalización, en la que los usuarios pueden encontrarse a través de la localización que su dispositivo transmite a la aplicación mediante las coordenadas obtenidas por el GPS del propio dispositivo. Con el uso de tecnologías basadas en web, se ha construido un plataforma en la que se posibilitá el acceso desde Internet a la aplicación a través de un navegador web. Esto ofrece compatibilidad con cualquier dispositivo capaz de conectarse a Internet y que disponga de un explorador web. En el desarrollo de la aplicación se aplicaron metodologías de planificación y programación ágiles, Scrum y TDD respectivamente. A través de la aplicación de dichas tecnologías, el desarrollo de la aplicación fue satisfactorio. Este proyecto muestra que cada vez es mayor la cantidad de información que se puede mostrar gracias a los sensores encontrados en los dispositivos.. iii

4 ABSTRACT GeoMe is a social application based on geolocalization, where the users can find each other throw the localization based on the information received on their GPS module and share it on the app. Developed with web-based technologies, GeoMe is built on a platform which is accesible from a web browser installed on a device. This feature makes the application available for all devices that have Internet connection and a web browser. For the development of the app, management and development agile methologies were used, like Scrum and TDD. Throw the application of those methologies, the project was successfully developed. This project shows how much information can be showed on the Internet with the sensors availables on every device. iv

5 AGRADECIMIENTOS, DEDICATORIAS Querría mostrar mi reconocimiento y agradecimientos a todas aquellas personas que de alguna forma contribuyeron a que este Trabajo Fin de Grado: En primer lugar, a mi tutor Manuel Ángel Serrano Martín, por su consejo y ayuda durante el desarrollo del proyecto. Agradecimiento especial a mi familia, la cual me ayudó y animó durante el desarrollo del trabajo y durante todo el periodo docente. Sin ella no hubiera sido posible esto. Por último, me gustaría agradecer a la Escuela Superior de Informática por la gran experiencia que ha sido recibir su docencia y los grandes años que he pasado en ella. v

6 Índice Capítulo 1. INTRODUCCIÓN CONTEXTO ESTRUCTURA DEL DOCUMENTO...2 Capítulo 2. OBJETIVOS DEL TFG OBJETIVO PRINCIPAL OBJETIVOS SECUNDARIOS...5 Capítulo 3. ANTECEDENTES, ESTADO DE LA CUESTIÓN INTRODUCCIÓN LAS REDES SOCIALES Orígenes Evolución Las redes sociales en la actualidad GPS Geolocalización Geolocalización en las redes sociales APLICACIONES WEB Qué es una aplicación web Usos comunes de las aplicaciones web Tipos de aplicaciones web Las aplicaciones web frente a las aplicaciones de escritorio Aplicaciones web móviles...23 Capítulo 4. MÉTODO DE TRABAJO INTRODUCCIÓN SCRUM Roles en Scrum Eventos en Scrum Artefactos de Scrum Desarrollo dirigido por test (Test-Driven Development TDD) Inicio de TDD Ventajas del uso de TDD Desarrollo Dirigido por Tests de Aceptación (ATDD) Historias de usuario Desarrollo centrado en la finalidad Frameworks ATDD MVC (Modelo Vista-Controlador) Stack MEAN (MongoDB, ExpressJS, AngularJS, NodeJS) MongoDB MongoLab Moongose ExpressJS AngularJS NodeJS...57 vi

7 Capítulo 5. RESULTADOS Introducción Planificación Sprint 1 Entrar en GeoMe Introducción Estructura del proyecto Acceso a MongoDB Registro Login Entrar en GeoMe Sprint 2 - Perfiles de usuario Introducción Añadir perfil de usuario Localización Modificar perfil de usuario Eliminar cuenta Perfil de Usuario Sprint 3 Gestión de usuarios Introducción Ver lista de usuarios Comprobar si existe como amigo Añadir usuario como amigo Eliminar usuario de la lista de amigos Gestionar usuarios Sprint 4 - Geolocalización Introducción Almacenar Geocoordenadas Mostrar la posición de un usuario Mostrar la posición de los amigos Enviar mensajes Compartir información Capítulo 6. CONCLUSIONES Y PROPUESTAS Introducción Conclusiones Propuestas Capítulo 7. BIBLIOGRAFÍA ANEXO I. ACRÓNIMOS vii

8 Índice de figuras Fig. 1: Logo GeoMe...1 Fig. 2: Logo Classmates [2]...8 Fig. 3: Teoría de los 6 grados [3]...8 Fig. 4: Estructura de redes sociales mediante un grafo [4]...9 Fig. 5: Logo Friendster [7]...10 Fig. 6: Logo Facebook [12]...11 Fig. 7: ecommerce en redes sociales [15]...13 Fig. 8: Logo Lugares de Facebook [18]...15 Fig. 9: Logo Foursquare [19]...16 Fig. 10: Logo Swarm [19]...16 Fig. 11: Logo Waze [20]...17 Fig. 12: Aplicaciones de escritorio [22]...20 Fig. 13: Aplicaciones web [23]...21 Fig. 14: Logo Scrum [26]...25 Fig. 15: Roles en Scrum [28]...27 Fig. 16: Scrum Master [29]...29 Fig. 17: Scrum Team [30]...30 Fig. 18: Sprint...32 Fig. 19: Eventos relacionados con el sprint [32]...32 Fig. 20: Estructura Sprint Review...34 Fig. 21: Estructura del Sprint Retrospective...35 Fig. 22: Ejemplo Product Backlog...35 Fig. 23: Sprint Backlog...37 Fig. 24: Ciclo TDD...39 Fig. 25: Ciclo ATDD...41 Fig. 26: Trabajo del Scrum Team con el cliente [38]...44 Fig. 27: Logo Mocha [40]...44 Fig. 28: Logo UnitJS [44]...46 Fig. 29: Esquema del MVC...47 Fig. 30: Stack MEAN [50]...48 Fig. 31: Logo MongoDB [52]...48 Fig. 32: Ejemplo de estructura de un documento en MongoDB [53]...50 Fig. 33: Logo Mongoose [55]...51 Fig. 34: Logo Express [57]...52 Fig. 35: Logo AngularJS [59]...53 Fig. 36: Two - way Data Binding...54 Fig. 37: Controladores AngularJS [60]...55 Fig. 38: Servicios en AngularJS [61]...57 Fig. 39: Logo NodeJS [63]...58 Fig. 40: Eventos asíncronos en Node.js [64]...58 Fig. 41: Comunicación entre el servidor y el cliente con Node.js [65]...59 Fig. 42: Diagrama de Gantt...67 Fig. 43: Tareas Sprints...69 Fig. 44: Artefactos y Eventos Scrum del proyecto...70 Fig. 45: Fase de fallos en los test de ATDD...71 Fig. 46: Estructura Stack MEAN [67]...72 viii

9 Fig. 47: Estructura de directorios de GeoMe...72 Fig. 48: Contenido de package.json...73 Fig. 49: Contenido de config.js...74 Fig. 50: Conexión con MongoLab...74 Fig. 51: Atributos del objeto User...75 Fig. 52: Fragmento de código del controlador de creación de usuarios...76 Fig. 53: Fragmento de código de la función de registro...76 Fig. 54: Operación en la API para el registro de usuarios...77 Fig. 55: Registro de usuario en MongoLab...77 Fig. 56: Autenticación basada en tokens [69]...79 Fig. 57: Fragmento de código de la función de login...80 Fig. 58: Fragmento de código de la creación del token...80 Fig. 59: Fragmento de código de la función de logout...81 Fig. 60: Fragmento de código de la función de isloggedin...81 Fig. 61: Fragmento de código de la función de getuser...81 Fig. 62: Fragmento de código para comprobar la sesión y actualizar las coordenadas...82 Fig. 63: Página de autenticación de GeoMe...83 Fig. 64: Página de registro de GeoMe...83 Fig. 65: Test pasados satisfactoriamente...84 Fig. 66: Recuperar la información del usuario...85 Fig. 67: Operación getprofile en el controlador del perfil de usuario...86 Fig. 68: Código para mostrar la información del usuario...86 Fig. 69: Código de storegeo()...87 Fig. 70: Actualización de la información de la localización...87 Fig. 71: Código del uso del módulo ngmap...88 Fig. 72: Perfil de usuario con localización...88 Fig. 73: Perfil de usuario con información acerca de este...89 Fig. 74: Acceso al formulario de modificación...90 Fig. 75: Estructura del formulario de modificación...90 Fig. 76: Ejemplo de uso de la directiva ng-model que enlaza el contenido con la variable 91 Fig. 77: Función de actualización de la información del perfil de usuario...91 Fig. 78: Función de la API para realizar la modificación sobre la base de datos...92 Fig. 79: Función encargada de eliminar la cuenta del usuario...93 Fig. 80: Sentencia DELETE...93 Fig. 81: Situación final del Sprint Backlog Fig. 82: Fase de fallos en los test de ATDD...95 Fig. 83: Tabla correspondiente con los usuarios de la aplicación...96 Fig. 84: Aspecto de la lista de usuarios...96 Fig. 85: Enlace del resultado de la consulta con la vista...97 Fig. 86: Consulta de la API sobre la base de datos...97 Fig. 87: Esquema de las solicitudes de amigo...98 Fig. 88: Comprobaciones de las solicitudes de amigo...98 Fig. 89: Botón para añadir amigos...99 Fig. 90: Fragmento de código que crea la solicitud de amistad Fig. 91: Consulta y petición POST de la API para la creación de la solicitud Fig. 92: Botón para eliminar a un amigo de la lista Fig. 93: Método enlazado al botón de eliminar amigo Fig. 94: Operación de eliminación del registro en la base de datos ix

10 Fig. 95: Estado del sprint backlog Fig. 96: Test aprobados satisfactoriamente Fig. 97: Test programados fallados Fig. 98: Añadimos la localización a la petición de registro del usuario Fig. 99: Actualización de la posición del usuario durante la navegación Fig. 100: Atributos necesarios para ngmap Fig. 101: Directiva ngmap Fig. 102: Obtener los amigos de la base de datos Fig. 103: Enlazar la lista de amigos con la página principal Fig. 104: Mostrar los amigos en el mapa Fig. 105: Aspecto de la página principal de GeoMe Fig. 106: Campo de mensaje y botón de enviar Fig. 107: Método que crea la request para la API Fig. 108: Creación del registro en la colección de Mensajes Fig. 109: Estado final del sprint backlog Fig. 110: Tests aprobados x

11 Índice de tablas Tabla 1: Diferencias entre la web estática y la web dinámica [21]...19 Tabla 2: Ventajas de las aplicaciones de escritorio o nativas...21 Tabla 3: Desventajas de las aplicaciones de escritorio o nativas...22 Tabla 4: Ventajas de las aplicaciones web o webapps...22 Tabla 5: Desventajas de las aplicaciones web o webapps...22 Tabla 6: Elementos Scrum...27 Tabla 7: Tareas realizadas durante el Sprint Planning Meeting...34 Tabla 8: Ejemplo de historias de usuario...43 Tabla 9: Características de Expresso...46 Tabla 10: Product Backlog...62 Tabla 11: Sprint Backlog...65 xi

12 Capítulo 1. INTRODUCCIÓN 1.1 CONTEXTO Las aplicaciones web permiten la generación automática de contenido, la creación de páginas personalizadas según el perfil del usuario o el desarrollo del comercio electrónico. Además, permite interactuar con los sistemas informáticos de gestión de una empresa, como puede ser gestión de clientes, contabilidad o inventario, a través de una página web. En los últimos tiempos muchas son las plataformas que se han desarrollado para poner en contacto a los usuarios, los cuales en su mayoría se conocían de antes, como es la familia y los amigos. Pero también existe demanda en la población un sistema de búsqueda de gente con gustos similares, es decir, con características afines a las nuestras con las que realizar actividades juntas que incluso con la gente que ya conoces no podrías realizar porque, simplemente, no les agrada como podría ser saltar en paracaídas o ir a un concierto de tu grupo favorito o porque simplemente vemos que la mayoría de la gente que conoces está reunida en un lugar en el que probablemente se esté celebrando algo que te pueda ser de interés. En este proyecto, le damos la vuelta: buscamos gente con la que compartir nuevas experiencias basadas en las nuestras. Fig. 1: Logo GeoMe 1

13 Haciendo uso del sistema de geolocalización que se puede utilizar al usar un explorador web desde nuestros dispositivos, podemos compartir nuestros pensamientos o simplemente nuestras acciones indicando a la vez donde nos encontramos. 1.2 ESTRUCTURA DEL DOCUMENTO El documento está estructurado en capítulos que recogen cada uno de los aspectos que se han estudiado para el desarrollo de este Trabajo Fin de Grado. A continuación se muestra un resumen de los distintos capítulos que se recogen en este documento junto con una breve descripción sobre lo que se encontrará el lector en cada uno de ellos. 1. Capítulo 1. INTRODUCCIÓN: Introducción al paradigma de aplicación Web. Qué es GeoMe. Capítulo 2. OBJETIVOS DEL TFG: Que ofrece GeoMe a los usuarios. Capítulo 3. ANTECEDENTES, ESTADO DE LA CUESTIÓN: En este capítulo se explican los orígenes de las redes sociales y su evolución a lo largo de los años, el GPS y su impacto en las redes sociales y el uso de las aplicaciones web como plataforma para usuarios. Capítulo 4. MÉTODO DE TRABAJO: En este capítulo se especifican los métodos, herramientas, técnicas y programas que se han utilizado para el desarrollo de GeoMe. Capítulo 5. RESULTADOS: En este capítulo se muestra, paso a paso, el desarrollo de GeoMe y la aplicación del conjunto de elementos que se describían en el capítulo anterior. Capítulo 6. CONCLUSIONES Y PROPUESTAS: Síntesis de los más importante que se ha observado durante el desarrollo de GeoMe, así como las posibilidades que esta ofrece de mejora. 2

14 Capítulo 7. BIBLIOGRAFÍA: En este capítulo se listan las referencias utilizadas para la realización de GeoMe. Anexos: 1. ANEXO I. ACRÓNIMOS 3

15 4

16 Capítulo 2. OBJETIVOS DEL TFG 2.1 OBJETIVO PRINCIPAL El objetivo principal es la creación de una aplicación web móvil que permita la comunicación entre las personas de un mismo entorno que compartan gustos y compartir opiniones sobre estos localizándose entre ellos vía GPS. Debido a que esta aplicación está basada en la geolocalización, está deberá mostrar al usuario aquellos usuarios que también usen la aplicación. Por ejemplo, un usuario puede estar en un local escuchando música en directo y este quiere compartir esto, ya que conoce a gente interesada en la mismo género musical por lo que, al enviar el mensaje, este comparte su ubicación para que así, el resto de usuarios, sea capaz de saber desde donde se ha enviado el mensaje. Mediante el uso de la aplicación, los usuarios pueden compartir las actividades que esten realizando para que sean localizados por el resto de usuarios y que estos decidan si acercarse al lugar desde donde se mando el mensaje. A su vez, y debido a que siempre se muestra la ubicación de los usuarios, el inicio de la conversación puede ser por parte de un usuario que visualice la localización de otro y le proponga un plan en una localización cercana o establecer un punto de encuentro. 2.2 OBJETIVOS SECUNDARIOS Un objetivo secundario principal es la consecución de la independencia entre GeoMe y la plataforma en la que el usuario puede ejecutar esta aplicación. Esto se conseguirá mediante el uso de tecnologías web, cuya propia naturaleza permite que la aplicación sea ejecutada en un explorador web. El resto de objetivos secundarios serán aquellos que mejoran la experiencia de usuario en el uso de la aplicación web GeoMe como puede ser la adición de gente conocida a 5

17 nuestra lista de amigos, la de incluir el nombre de la calle en la que nos encontramos en los mensajes que enviemos a través de la aplicación o la optimización de dicha aplicación para dispositivos móviles. 6

18 Capítulo 3. ANTECEDENTES, ESTADO DE LA CUESTIÓN 3.1 INTRODUCCIÓN Durante este capítulo se revisarán los orígenes de las redes sociales y como estas han ido cambiando para satisfacer las necesidades de los usuarios, ya sea creando nuevas aplicaciones complementarias a la ya existente o realizando una total modificación aportando las nuevas prestaciones que demandan los movimientos del mercado y el surgimiento de nuevos modelos de negocio. También se explicará que es el GPS y como este ha influido en las redes sociales. 3.2 LAS REDES SOCIALES Orígenes Las redes sociales en Internet son comunidades virtuales donde los usuarios interactúan y comparten contenidos con personas de todo el mundo, sus intereses, ambiciones o sus intereses en común. Funcionan como un lugar de encuentro entre personas que se conocen en la vida real y para aquellos a los que les gusta conocer a gente de todas las partes del mundo pudiendo compartir archivos de todo tipo como imágenes, audios e incluso vídeos. La primera red social creada está fechada en 1995 y a diferencia a la creencia popular, no es Facebook, creada en 2004, sino Classmates.com, la cual está aún en funcionamiento. Classmates es una red social creada en 1995 por Randy Conrads. En un principio esta red social ayudaba a ponerse en contacto a antiguos colegas y compañeros de clase del parvulario, del colegio, instituto, universidad y del lugar de trabajo e incluso entre los militares de los Estados Unidos de América. Finalmente la página pasó a centrarse en la 7

19 recopilación de momentos nostálgicos entre los participantes de la red social, cambiando incluso su nombre a Memory Lane. [1] Fig. 2: Logo Classmates [2] Tanto Classmates.com como el resto de redes sociales se basan en la gran conocida teoría de los 6 grados de separación. Esta teoría afirma que cualquier persona del planeta está conectada a otra a través de una cadena de conocidos de no más de 5 o 6 puntos de unión. Esta teoría surge en el siglo XX a raíz de la idea propuesta en 1929 por el húngaro Frigyes Karinthy, en un relato llamo Chains. En la década de los 50, investigadores del MIT e IBM trataron de demostrar esta teoría de forma matemática (dado un grupo de N personas, cual es la probabilidad de que cada miembro de N esté conectado a otro miembro a través de 1,2, 3 n enlaces). Fig. 3: Teoría de los 6 grados [3] 8

20 No fue hasta 1967 el sociólogo (Stanley Milgram) desarrolló un experimento con el fin de probar la teoría: al azar, eligió ciudadanos americanos de la región del Centro-Oeste, con el fin de entregar un envío a un desconocido en Massachussets, a miles de kilómetros de distancia. La única información era simple: el nombre, la ubicación genérica ( no había direcciones concretas) y la ocupación del destinatario. Con esta información, el objetivo para los que iniciaron la cadena era sencillo: entregar a quien ellos creyeran que podría estar ligado al destinatario, siempre que se cumpliera la condición de tratarse de personas que conocían directamente, y con la idea general de que el primer eslabón sería basado en el hecho de que creyeran que el conocido pudiera estar relacionado, es decir, que tuviera más probabilidades de conectar al destinatario de un modo u otro. Los receptores debían hacer lo mismo, y la cadena seguiría hasta que el destinatario fuera alcanzado. Los participantes en este experimento pensaban que serían necesarios cientos de personas las necesarias para acometer dicho objetivo, los más optimistas en decenas y muchos creían que era absurdo e imposible. La respuesta? En promedio, se necesitaron entre 5 y 7 intermediarios. Fig. 4: Estructura de redes sociales mediante un grafo [4] 9

21 En el 2001, la Universidad de Columbia continuó el experimento de Milgram, usando Internet, y otras numerosas pruebas (casi personas enviando el paquete a destinatarios de 157 países) se encontró que el número de pasos promedio era seis. Desde entonces, esta teoría se ha aplicado a temas de distinta índole, computacionales, de comunicación, circuitos, etc. [5] Evolución En 2002 aparecen sitios web promocionando las redes de amigos en línea cuando el término se empleaba para describir las relaciones en las plataformas virtuales. Una de las más importantes que aparecen es Friendster [6]. Fundado en el año 2002 por Jonathan Abrams en Mountain View, California, con la idea de proporcionar un sitio donde las personas pudiesen continuar con sus relaciones sociales, iniciar otras nuevas, intercambiar todo tipo de documentos, y complementar en la red una parte importante de su vida social. Fue ya en 2003 cuando la red social inició sus actividades y generó una gran atención. Fig. 5: Logo Friendster [7] En 2003 surgen además sitios tales como Tribe.net [8], MySpace [9], Ecademy[10] y LinkedIn [11], entre otros pero fue Friendster el que mantuvo la mayor cuota de mercado durante cierto tiempo. 10

22 Sin embargo, cuando hablamos de red social el primer nombre que nos viene a la mente es el de Facebook. Mark Zuckerberg fundó Facebook mientras estudiaba psicología en la universidad de Harvard. Para entonces ya había desarrollado otras redes sociales como Coursematch que permitía ver la gente que había elegido el mismo curso que ellos y Facemash donde podías valorar el atractivo de los estudiantes. En Febrero del 2004 Zuckerberg lanzó The Facebook. En las siguientes 24 horas, The Facebook consiguió el registro de estudiantes de Harvard. La red se expandió a otras universidades de Boston y eventualmente a todas las universidades EE.UU. No fue hasta Agosto de 2005 cuando el nombre de Facebook no fue comprado por $. En Septiembre del 2006 la red se extendió más allá del ámbito educacional y todo aque que dispusiera de una dirección de correo electrónico podía registrarse en el sitio. El sitio permanece siendo gratuito de registro y el beneficio es producido por el espacio publicitario personalizado que ofrece el sitio. Fig. 6: Logo Facebook [12] La investigación en las redes sociales ha ido profundizando en diversos aspectos. Algunos trabajos se han centrado en los procesos de gestión de las impresiones de los públicos, el modo en que se presentan a sí mismos, y la calidad de las amistades que se generan en ese ámbito. Aunque existen excepciones, la investigación disponible sugiere que la mayoría de las redes sociales sirve para reforzar relaciones sociales ya existentes, de modo que se establecen puentes entre lo online y lo offline. En esta línea, se ha sugerido que 11

23 Facebook se usa para estrechar relaciones offline, más que para conocer a otras personas. Esas relaciones pueden ser débiles o superficiales. [13] Las redes sociales en la actualidad Actualmente estamos en una era en la que cada sitio web es social. Hay una integración conceptual y mental casi completa de las redes sociales existentes con la vida cotidiana de los individuos. Ya no solo nos afecta cuando estamos conectados a ellas con un ordenador o cualquier dispositivo capaz de conectarse a Internet si no en las influencias que tienen sobre los propios individuos cuando estás realizando tareas de otra índole. Es decir, la sociedad moderna se encuentra tan ligada a las redes sociales que estas están presentes en cada acción que hacemos o por la necesidad de volver a ellas y encontrar nuevos contenidos en ellas, como fotos, vídeos o mensajes. Según Jeremiah Owyang, analista de mercado y orador, se predice que actualmente nos encontramos en la madurez de la quinta etapa en la evolución de las redes sociales y nuestra interacción con estas. [14] 1. Era de las relaciones sociales. 2. Era de la funcionalidad social. 3. Era de la colonización social. 4. Era del contexto social. 5. Era del social commerce. Las 2 primeras etapas se caracterizan por el comienzo del uso de las redes sociales como medio para conectarse y compartir socialmente de manera directa, sin mayor objetivo que dar a conocer información sin que haya un objetivo más allá de las simple comunicación y el refinamiento de esta integrando dichas conexiones en nuestra vida diaria y entendiendo como afecta el contenido compartido a las masas. La cuarta etapa está 12

24 caracterizada por la entrega de información personal a los sitios web, las cuales la usarían para dar una experiencia totalmente personalizada para cada usuario. En este caso podemos encontrarnos con las cookies, las cuales almacenan información sobre las actividades que hacemos en los sitios web para ofrecernos una experiencia más personal acorde con el comportamiento detectado en la página. La quinta significaría la sustitución de las marcas en la web por las redes sociales en las que las empresas participan activamente en las redes apuntando a un comercio sin intermediarios, integrándose en las redes sociales y así en la vida cotidiana de los usuarios. Debido a esto cada vez es más común que las redes sociales incluyan un sistema de pago integrado en la propia aplicación. Con esto las empresas consiguen que usuario pueda comprar desde aquel lugar en el que los usuarios pasan más tiempo, si necesidad de que este tenga que abandonar con esto y siga con la tarea que estuviera haciendo en el momento que comenzó la acción de compra. Ya son muchos los casos de redes sociales que han integrado la función de compra directamente en su aplicación. Los más sonados son Facebook, Twitter, Pinterest e Instagram. Fig. 7: ecommerce en redes sociales [15] 13

25 3.2.4 GPS GPS es un sistema que permite la triangulación de un objeto sobre la Tierra. Este sistema está formado por 24 satélites puestos en órbita por el Departamento de Defensa de los estados unidos. En un principio, este sistema fue diseñado con fines militares, pero en los 80, el gobierno hizo este sistema accesible para civiles, 24 horas al día. Su funcionamiento es el siguiente: los satélites GPS giran alrededor de la Tierra 2 veces al día en una órbita muy precisa y transmite la información a la Tierra. De esta forma, los receptores GPS recogen la información de un numero de satélites y calculan la posición del usuario a partir del tiempo que ha tardado en recibir dicha información. [16] Geolocalización Los sitios web que permiten la geolocalización, obtienen la posición del usuario a través de las coordenadas GPS que reciben del dispositivo conectado. De esta forma, estos sitios ofrecen información más relevante dependiendo de donde se encuentre el usuario y ahorra, en la mayoría de ocasiones, tiempos de búsqueda. La mejor explicación es un ejemplo de uso de la geolocalización en un sitio web. Suponga que está buscando un sitio de comida rápida. Este sitio puede pedirle que se le envíe la información de su localización para mostrarle, en un mapa de la zona, el sitio más cercano que dispone de los servicios que el usuario ha solicitado Geolocalización en las redes sociales En los últimos años se han popularizado distintas aplicaciones que nos permiten compartir con nuestros conocidos fotos y videos, además de facilitarles la información 14

26 sobre el lugar geográfico en el que se han obtenido estos documentos. Esto ha sido debido al uso del sistema de geolocalización incorporado en aquellos dispositivos que o bien disponen de un módulo GPS integrado o tienen conexión a Internet, con la cual se puede localizar la localización del dispositivo desde el que nos conectamos. Gracias a esta técnica se ha puesto a servicio de los usuarios unos servicios que después de haber localizado el dispositivo y por consiguiente, al propio usuario, unas funcionalidades que combinan la información recibida de la localización con los servicios instalados ya en el dispositivo, ofreciendo experiencias más reales a los usuarios. Entre los distintos servicios desarrollados entorno a esta técnica, se encuentran las redes sociales que permiten a sus usuarios localizar en tiempo real a las personas de una misma red social en una zona del mapa y combinar esos datos con servicios comerciales. Existen algunas redes sociales que se especializan en este tipo de técnicas o bien aquellas que adaptan estas técnicas de geolocalización a sus necesidades. Lugares de Facebook es un ejemplo de las segundas. Lugares de Facebook, con un potencial de usuarios de 500 millones, permite a las personas que utilizan la plataforma compartir información sobre donde se encuentran si ellos lo desean. Los usuarios favorecen además a la riqueza de contenido añadiendo lugares a sus entradas. [17][18] Fig. 8: Logo Lugares de Facebook [18] Foursquare es un servicio basado en localización web aplicada a las redes sociales. En 2009 lanzó la función de compartir los check-ins y la ubicación en tiempo real con los 15

27 amigos. Cinco años más tarde, decidieron que los check-ins tuvieran su propia aplicación. Swarm es la manera más rápida y fácil de mantenerte en contacto y reunirte con tus amigos. [19] Fig. 9: Logo Foursquare [19] Fig. 10: Logo Swarm [19] Otra de las aplicaciones que es conocida por el uso de la geolocalización a la hora de explotar todo su potencial es Waze. Waze tiene por objetivo común el contribuir a la calidad de los viajes en automóvil de los conductores en sus viajes diarios. Esto significa ayudarles a evitar problemas como puede ser un control policial, un atasco o en ahorrarse tiempo en sus viajes mostrando al resto de conductores de la zona una ruta alternativa. Además de las comunidades de conductores locales usando la aplicación, Waze es también el hogar de una activa comunidad de editores de mapas en línea, que aseguran que la información de sus áreas esté lo más actualizada posible. 16

28 Fig. 11: Logo Waze [20] 3.3 APLICACIONES WEB Qué es una aplicación web Una aplicación web es un sitio web que contiene páginas con contenido sin determinar, parcialmente o en su totalidad. El contenido final de una página se determina sólo cuando el usuario solicita una página del servidor web. Dado que el contenido final de la página varía de un petición a otra en función de las acciones del visitante, este tipo de página se denomina página dinámica. Las aplicaciones Web se crean en respuesta a diversas necesidades o problemas. [21] Usos comunes de las aplicaciones web Existen numerosos usos para las aplicaciones web. Estos dependerán de factores como a que segmento de la población va dirigido, que necesidades demandan los usuarios o los recursos de los que dispongan los responsables de estas plataformas. Los usos más comunes que podemos encontrar a lo largo de la web son: Permitir a los usuarios localizar información de forma rápida y sencilla en un sitio Web en el que se almacena gran cantidad de contenido. Pueden ser bases del 17

29 conocimiento (intranets de empresas) o páginas en las se ofrecen gran cantidad de material (tiendas ecommerce). Recoger, guardar y analizar datos suministrados por los visitantes de los sitios. El mejor ejemplo de este tipo de aplicación es Google Analytics, el cual puede ser añadido a cualquier sitio web y obtener estadísticas sobre todo lo que ocurre en él (clicks, enlaces más visitados, imágenes más visionadas, etc.). Actualizar sitios Web cuyo contenido cambia constantemente. Una aplicación web evita que el desarrollador web tenga que actualizar continuamente el código HTML del sitio Tipos de aplicaciones web Existen 2 tipos de aplicaciones web, las estáticas y las dinámicas: Aplicaciones web estáticas: Es aquella que es básicamente informativa, el visitante y el administrador de la página no pueden interactuar con la página para modificar su contenido. No se utilizan bases de datos ni se requieren conocimientos de programación web avanzados, es suficiente con HTML y CSS. Son más conocidas como páginas web. Aplicaciones web dinámicas: Es aquella que permite la interacción entre el visitante y el administrador de la Web, pudiéndose modificar el contenido de la página. Es decir, el visitante puede dejar un comentario, subir una foto o añadir a sus amigos. En este caso estaríamos ante el uso de una base de datos que mantiene toda la información actualizada y almacenada. En la siguiente tabla se presentan las diferencias fundamentales entre los 2 tipos de aplicaciones web existentes. 18

30 Web Estática Web Dinámica Necesidad de conocimientos técnicos Necesidad de conocimientos técnicos para el diseño y edición del contenido solo para instalar y configurar pero no para añadir/editar contenido Necesidad de aplicaciones específicas Gestor de contenido prediseñado Programas de diseño / edición Manejo desde un navegador web Programas de FTP Importancia en el diseño de la web Responsabilidad Centralizada Importancia en el contenido de la web Webmaster Reparto de responsabilidades: administradores, editores, registrados, etc. Menor participación del personal de la compañía Mayor participación y trabajo cooperativo Consulta de información Consultar, modificar, procesar... Escasamente actualizada Actualización más frecuente Pocas visitas Más visitas, suscripciones, RSS. Tabla 1: Diferencias entre la web estática y la web dinámica [21] Las aplicaciones web frente a las aplicaciones de escritorio Además de las aplicaciones web, existen otra clase de aplicaciones, las nativas o de escritorio. Las aplicaciones de escritorio son aquellas cuya funcionalidad es ejecutada por un programa instalado en cada puesto de trabajo y que se conecta a través de Internet con la base de datos. Estas se desarrollan de forma especifica para cada sistema operativo mediante un kit de desarrollo o SDK (Software Development Kit). Cada plataforma tiene 19

31 un sistema diferente por lo que se deberán crear varias aplicaciones con el lenguaje del sistema operativo seleccionado. Fig. 12: Aplicaciones de escritorio [22] La ventaja en las aplicaciones de escritorio es la velocidad de uso de la que diponen, ya que incorporan todos los controles de escritorio y los eventos asociados a ellos. Puedes hacer que la interfaz tenga el aspecto deseado, sin atenerte a guías de estilo o normas y una personalización total de las acciones y procesos que se producen en ella. Sin embargo, las aplicaciones web están en pleno auge debido a las capacidades interactivas que ofrece la web frente a las clásicas aplicaciones de escritorio. Esto es debido también en parte a que las de escritorio han estado siempre limitadas por el hardware del dispositivo donde estas se ejecutan, mientras que en las aplicaciones web o webapps es un servidor ajeno a nosotros el que se encargará de realizar la funcionalidad del software implementado. 20

32 Fig. 13: Aplicaciones web [23] Entre estas dos, existen algunas diferencias que condicionaran la decisión de desarrollar una aplicación de una forma u otra. En la siguiente tabla se muestran las ventajas y desventajas del uso de los 2 paradigmas en el mundo de la informática. [24] Ventajas de las aplicaciones de escritorio o nativas Habitualmente su ejecución no requiere comunicación con el exterior, si no que se realiza de forma local. Esto repercute en la velocidad de procesamiento. Suelen ser más robustas y estables que las webapps. Tiempo de respuesta más rápido. Pueden ser muy seguras. Acceso completo al dispositivo. Mejor experiencia de usuario. Envío de notificaciones o avisos a los usuarios. Tabla 2: Ventajas de las aplicaciones de escritorio o nativas 21

33 Desventajas de las aplicaciones de escritorio o nativas Su acceso está limitado al puesto de trabajo. Dependientes del sistema operativo que utilice el dispositivo y sus capacidades. Requieren instalación y actualización personalizada. Requieren librerías o complementos de terceros. Diferentes habilidades/idiomas/herramientas para cada plataforma de destino Tienden a ser más caras de desarrollar El código del cliente no es reutilizable entre las diferentes plataformas. Tabla 3: Desventajas de las aplicaciones de escritorio o nativas Ventajas de las aplicaciones web o webapps Portabilidad: se ejecutan desde cualquier ordenador con conexión a Internet. Aplicaciones colaborativas: los usuarios comparten información. Son aplicaciones ligeras: solo requieren del navegador web para acceder a los servicios. Consumen pocos recursos. Fáciles de actualizar y mantener. No hay problemas de compatibilidad. Su funcionalidad es independiente del sistema operativo instalado en el ordenador del usuario. Tabla 4: Ventajas de las aplicaciones web o webapps Desventajas de las aplicaciones web o webapps Es necesaria una conexión estable a Internet. El servidor debe tener los recursos necesarios para ejecutar la aplicación de forma estable y dar respuesta a todos los usuarios. Se tiene que preparar la aplicación para hacerla compatible con distintos navegadores. Si no dispone de los recursos suficientes, es posible que el tiempo de respuesta sea más lento que las nativas. Tabla 5: Desventajas de las aplicaciones web o webapps 22

34 3.3.5 Aplicaciones web móviles Este tipo de aplicaciones web se caracterizan por estar optimizadas para ser usadas en dispositivos móviles, como tablets o smartphones. Este tipo de aplicaciones se están convirtiendo rápidamente en el modelo preferido por sus ventajas económicas y operativas. Bajo este modelo, los desarrolladores pueden hacer uso de las últimas tecnologías y optimizar sus procesos de negocio sin ningún tipo de gasto adicional en infraestructuras u operaciones. El mejor ejemplo de aplicación web móvil es Firefox OS. Firefox OS es una plataforma abierta que promueve una mayor participación en la cadena valor. La web es la plataforma. Este ofrece un ecosistema alternativo, independiente y libre de las normas y restricciones que caracterizan a las plataformas patentadas existentes. Firefox OS está formado por 3 capas: 1. Gaia, la interfaz de usuario. Firefox OS ofreece una experiencia de usuario intuitiva y fácil de personalizar. 2. Gecko, el motor de renderizado web. A través de APIs web creadas por Mozilla, Gecko expone las capacidades de hardware del teléfono a los contenidos web. 3. Gonk, el núcleo. Aquí están concentradas las librerías del sistema, el firmware y los controladores del hardware. [25] Existen una serie de antecedentes en el uso de las tecnologías web como plataforma para crear redes sociales, las cuales se han ido adaptando a lo largo del tiempo para cubrir las necesidades, siempre cambiantes, de los usuarios. Tanto para la creación como para el mantenimiento de estos sitios web, es necesario seguir algún plan de desarrollo, en el cual se tienen en cuenta los muchos aspectos que influirán en él, como por ejemplo, que dirección se va a tomar, que es lo que hay que hacer y que se va a usar para conseguirlo. 23

35 Todo esto y mucho más es lo que hay que planificar antes de lanzarse de cabeza a la producción del proyecto y en el siguiente capítulo se explicarán los pasos a seguir para la planificación y desarrollo del mismo proyecto. 24

36 Capítulo 4. MÉTODO DE TRABAJO 4.1 INTRODUCCIÓN En este capítulo se trataran los procesos y metodologías que se han seleccionado para la resolución del problema. Se abarcarán los conocimientos aplicados desde la planificación del proyecto hasta el desarrollo del mismo, aportando figuras, diagramas, tablas y toda la información usada durante el proceso de construcción de la aplicación. 4.2 SCRUM Scrum es un sistema de gestión de proyectos en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar de forma colaborativa, en equipo, y obtener el mejor resultado posible en el desarrollo de un proyecto. Está metodología es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos desde principios de los años 90. Este tipo de organización está basado en los equipos Scrum, roles, eventos, artefactos y reglas asociadas. Fig. 14: Logo Scrum [26] Scrum se basa en la teoría de control de procesos de forma empírica. Es decir, el conocimiento que las personas implicadas adquieren es mediante la experiencia y la toma 25

37 de decisiones basadas en el conocimiento de los componentes del equipo de trabajo en ese momento. El enfoque que tiene Scrum frente a proyectos de gran complejidad es la afrontarlo mediante una metodología iterativa e incremental para optimizar la predictibilidad y el control de riesgo. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, las entregas no llegan a los límites de entrega, los costes de las entregas superan el presupuesto previsto o la calidad de los resultados no es la esperada por el cliente, cuando no se han previsto algunos riesgos y la aparición de estos han obligado a realizar cambios. Para todo esto y más, Scrum permite identificar y solucionar ineficiencias sistemáticamente, modificando la planificación en la siguiente iteración sin que el proyecto global se vea severamente afectado. Las ventajas de usar Scrum son numerosas, entre las que destacan la flexibilidad a cambios. La alta capacidad de reacción ante los cambios de requerimientos generados por necesidad del cliente, las evoluciones del mercado o las incidencias ocurridas durante el desarrollo de cualquier iteración permite una rápida adaptación a las nuevas necesidades del proyecto. Esta metodología de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades. [27] ROLES EVENTOS ARTEFACTOS Product Owner Sprint Planning Product Backlog Scrum Master Sprint Review Sprint Backlog Scrum Team Sprint Retrospective Daily Scrum Meeting Tabla 6: Elementos Scrum 26

38 4.2.1 Roles en Scrum Fig. 15: Roles en Scrum [28] Product Owner El dueño del producto o product owner normalmente es una persona con visión, autoridad y disponibilidad. Este es responsable de la comunicación continua entre todas las partes implicadas en el proyecto proporcionando la visión y las prioridades al equipo de desarrollo. El dueño del producto es una sola persona y tiene una ardua tarea. Tiene que ser capaz de equilibrar la participación de los scrum team, ya que Scrum tiene la ventaja de permitir a los equipos de trabajar de forma autónoma, el dueño del producto tiene que mantenerlos controlados para que la gestión del proyecto no sea un caos. A la vez, este tiene que ser capaz de responder las dudas de los equipos trabajo y de darles flexibilidad en cuanto a las decisiones de desarrollo. Las responsabilidades del product owner son variadas y se pueden resumir en las siguientes capacidades: 27

39 Expresar claramente los elementos del product backlog. Ordenar los elementos en el product backlog según el criterio del cliente y posteriormente el personal para alcanzar los objetivos y misiones de la mejor manera posible. Optimizar el valor del trabajo realizado por el scrum team. Asegurar que el product backlog es visible para el resto de componente, de forma que sea comprensible para que el trabajo se pueda desempeñar satisfactoriamente. Asegurar que el equipo de desarrollo entiende el product backlog y resuelve las posibles dudas generadas. Además, el dueño del producto es el único que tiene la capacidad de poder cambiar la prioridad de un elemento del product backlog. De esta forma, se mantiene un sistema de control sobre los cambios producidos en los elementos necesarios para llevar a cabo el proyecto. Scrum Master El Scrum Master actúa como intermediario entre el scrum team y el resto de partes que participan en el proyecto. Este se asegura de que el equipo trabaja ajustándose al marco de trabajo Scrum y que las interacciones externas con el equipo sean de ayuda y no sean contraproducentes para aumentar el valor creado por el equipo. Este rol tiene diferentes responsabilidades según con quién tenga que establecer comunicación ya sea con el product owner, el equipo de desarrollo o con el resto de participantes siempre maximizando la calidad de los resultado obtenidos por el equipo de desarrollo. 28

40 Fig. 16: Scrum Master [29] La relación existente con el product owner es debido a que ayuda al scrum master a que este ordene mediante técnicas específicas los elementos en la lista otorgándole a los elementos la prioridad correspondiente, además ayuda al scrum master: Ayudar al scrum team a entender la necesidad de contar con elementos del product backlog claros y concisos. Entender la planificación del producto en un entorno empírico. Entender y practicar la agilidad de la filosofía Scrum. Facilitar los eventos Scrum según se requieran. El scrum master también da servicio al scrum team de forma variada: Guiar al equipo en ser autoorganizado y multifuncional. Ayudar al equipo de forma que el trabajo de este consiga el mayor valor posible. Facilitar los eventos Scrum necesarios. Guiar al equipo en entornos donde la filosofía Scrum no ha llegado. 29

41 Por último, el scrum master también tiene el rol de asesor para el resto de órganos dentro de la organización: Guiar a la organización en la adopción de Scrum. Planificar las implementaciones Scrum. Ayudar a los empleados e interesados en asimilar la filosofía Scrum. Scrum Team El scrum team o equipo de desarrollo está compuesto por un grupo de profesionales que trabajan para entregar el sprint o incremento terminado. Solo los miembros del equipo son los que desarrollan los sprint. De acuerdo con el fundador de Scrum, los scrum teams son organismos autoorganizados. Este es responsable de autoorganizarse para poder acometer sus tareas. Fig. 17: Scrum Team [30] 30

42 Las características del scrum team son: Formado entre 3 y 9 personas, lo más común son grupos de 7. El equipo está formado por profesionales de distintas áreas, para poder abordar los problemas desde varios puntos de vista gracias a las habilidades y conocimientos únicos que cada uno posee. Los títulos carecen de importancia. Todos son desarrolladores independientemente del trabajo que realizan. Aunque cada miembro tenga habilidades especializadas en el área en la que se han concentrado, pero la responsabilidad recae en el scrum team. La máxima del scrum team es la entrega del sprint el cual le han asignado. [31] Eventos en Scrum Sprint En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones desde 2 semanas hasta 1 mes natural de duración). Es la unidad básica de unidad de desarrollo. Cada iteración tiene que proporcionar un resultado completo, un incremento de un producto que sea susceptible de entrega cuando el cliente lo requiera. 31

43 Fig. 18: Sprint Estas iteraciones son las conocidos sprints, que contienen y consisten en una serie de controles para determinar que hacer en él, como lo llevan y que está previsto hacer, además de resolver las dudas que vayan surgiendo. Cada sprint conlleva una serie de momentos durante el desarrollo de este donde se monitoriza el estado del sprint y hacía donde va según la información recabada. Fig. 19: Eventos relacionados con el sprint [32] 32

44 Sprint Planning Meeting Al comienzo de cada sprint, el scrum team se reúne para acordar una serie de aspectos sobre el trabajo que se va a llevar a cabo en el sprint correspondiente. En esta reunión se realizan las siguientes tareas: TAREAS SPRINT PLANNING MEETING Seleccionar que parte del proyecto se va a realizar durante el sprint. Preparar el sprint backlog con los detalles del tiempo necesario para completarlo. Identificar y comunicar cuanto porcentaje del total se va a realizar durante el sprint. Tabla 7: Tareas realizadas durante el Sprint Planning Meeting Está reunión sirve para contestar a 2 preguntas: Qué puede entregarse en el sprint que comienza? Cómo se conseguirá hacer el trabajo necesario para entregar el sprint? Daily Scrum Durante el desarrollo del sprint, se lleva a cabo un reunión del scrum team de 15 minutos estrictos para que este sincronice sus actividades y acuerde el trabajo que se va a realizar durante el día con todos los componentes, incluso si alguno de estos está ausente. Este evento responde a tres preguntas: Que se hizo el día anterior que contribuyera a la consecución del sprint goal u objetivo del sprint. Que haré hoy que contribuya a la consecución del sprint goal. 33

45 La existencia de algún impedimento que el equipo vea de conseguir el sprint goal. Esta última duda debe ser captada por el scrum master e identificarlo para que alguien del equipo de desarrollo se encargue de solucionarlo. Sprint Review Durante este evento, se lleva acabo una revisión para revisar el estado del sprint para inspeccionar el progreso de las tareas y adaptar el product backlog en caso de que fuera necesario. También se aprovecha este momento para buscar y sugerir nuevas mejoras que optimicen el valor del trabajo resultante del sprint. Fig. 20: Estructura Sprint Review El equipo de desarrollo revisa que trabajo se ha completado y que no y además presenta el trabajo terminado a las partes interesadas en el proyecto. Las únicas restricciones que presenta este proceso es que el trabajo incompleto no se debe mostrar y que su duración no debe exceder la estimación prevista según la longitud del sprint. El tiempo en el que se basa esta estimación es dos horas para un sprint de 2 semanas de duración. Sprint Retrospective Este proceso se realiza al terminar la revisión del sprint y su propósito es el de inspeccionar los aspectos relacionados con él, personas implicadas, relaciones creadas, procesos utilizados y herramientas seleccionadas para su realización. 34

46 Además identifica y ordena los elementos más importantes que salieron bien y un estudio del estado actual para, en caso de ser necesario, proponer cambios en el product backlog. [33] Fig. 21: Estructura del Sprint Retrospective Artefactos de Scrum Product Backlog Todo el proceso que inicia Scrum se sostiene sobre la lista del producto o product backlog. El product backlog es una lista priorizada de objetivos o requisitos de todo lo que se cree que se va a necesitar para llevar a cabo satisfactoriamente el proyecto. En esta es el cliente el que ordena dicha lista balanceando el valor que le aportan los requisitos respecto a su coste. Define el qué se desarrollará. Fig. 22: Ejemplo Product Backlog 35

47 Un product backlog nunca está terminado. La fase más temprana de esta solo refleja los requisitos producto de la primera reunión con el cliente. A partir de ahí, la lista evoluciona según se vaya conociendo el producto y las sucesivas reuniones con el cliente. Según avanza el desarrollo, el product backlog cambia para que el producto sea competitivo en el mercado. Pero esta lista no desaparece en el fin del proyecto, sino que continua mientras que el producto existe, proporcionando un incremento de valor según este se vaya utilizando, mediante el feedback recibido de los usuarios. Cualquier cambio tecnológico, de tendencias de mercado o los requisitos del mismo, podrían acarrear cambios en la lista, modificando así la naturaleza del producto de muchas formas (añadir nuevas funciones, quitando otras obsoletas o cambiando el target del propio producto). Existen fases de mejora del product backlog en los que se añaden detalles, estimaciones y orden de los elementos (si el cliente considera que las prioridades han cambiado debido a opiniones personales o las condiciones de mercado). Estas fases corren a cargo de los responsables de la lista, en este caso del dueño de producto (Product owner) y del equipo de desarrollo, que colaboran acerca de estos cambios. Ellos deciden cuando y como se realizan los procesos de mejora, aunque es el dueño del producto el que tiene la última palabra acerca de la aceptación de los cambios. Sprint Backlog El sprint backlog es una lista que contiene los elementos del product backlog que han sido seleccionados para el siguiente sprint además de un plan para conseguir la entrega del siguiente incremento y conseguir el objetivo. Este artefacto es una predicción por parte del equipo de desarrollo de cual será el siguiente incremento a entregar y el trabajo necesario para cumplir con él. 36

48 Fig. 23: Sprint Backlog En el sprint backlog el equipo de trabajo prepara las tareas necesarias para implementar los elementos que se han seleccionado del product backlog. Según se va ejecutando el sprint backlog el equipo puede detectar que es necesario añadir nuevas tareas, modificar otras y eliminarlas para la consecución de su objetivo. Las tareas dentro del sprint backlog pueden pasar por 3 estados: TODO en la que la tarea se encuentra pendiente de hacer, in progress, la tarea se encuentra en pleno desarrollo y done, cuando la tarea se considera terminada. En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (desde 2 semanas hasta un mes natural si así se necesita). Cada iteración tiene que proporcionar un resultado completo, hitos, que sean susceptibles de entrega al cliente cuando este lo solicite. [34] 4.3 Desarrollo dirigido por test (Test-Driven Development TDD) TDD es una metodología de desarrollo de software que se basa en la idea de desarrollar pruebas, codificar y re-factorizar el código construido. Es un tipo de metodología XP (extreme programming) [35]. La diferencia entre las metodologías tradicionales y las XP es que los requisitos se expresan de forma distinta. En la metodología XP los requisitos se transforman al lenguaje natura; donde en la tradicional 37

49 podemos encontrar: El sistema debe permitir que los usuarios registrados compren créditos y proporcionar las herramientas para que los usuarios paguen. Con XP nos encontraríamos: Comprar créditos y, Pagar créditos. El procedimiento a seguir para aplicar TDD en un proyecto es muy sencillo: La implementación de las funciones justas que el cliente necesita y no más. La minimización del número de defectos que llegan al software en fase de producción. La producción de software modular, altamente re-utilizable y preparado para el cambio. TDD se basa en la idea de realizar pruebas unitarias para el código que debemos construir. A diferencia de los procesos que se usan tradicionalmente para el desarrollo de software y posteriormente introducir las pruebas unitarias, TDD lo hace a la inversa. La idea es la de implementar las pruebas primero y a continuación añadir el código que resuelve dichas pruebas. Posteriormente se re-estructura el código implementado para cumpla las exigencias solicitadas. [36] El proceso de TDD se puede resumir en la siguiente figura: 38

50 Fig. 24: Ciclo TDD Una de los errores más comunes que se cometen al pensar en la aplicación de TDD a un proyecto es que este tendrá una alta cobertura de tests muy alta, algo que se busca puesto que mejora la calidad del trabajo realizado, pero realmente es a través de estos tests desde los cuales se generará el resto del proyecto Inicio de TDD El método de uso de TDD es el siguiente. Se escoge uno de los requisitos a implementar y se crea una sencilla implementación de este. Posteriormente se crea una prueba unitaria, se ejecuta y falla. El siguiente paso es escribir la mínima cantidad de código que sea capaz de superar, ejecutar la prueba y que esta sea superada. A partir de aquí se repite el proceso para terminar de implementar la funcionalidad o funcionalidades previamente propuestas. En caso de necesitar re-factoring, se revisarán, corregirán y ejecutarán las pruebas unitarias de nuevo. El caso de crear primero la prueba y comprobar que efectivamente falla, debido a que 39

51 aún no hemos implementado ningún fragmento de código es necesario para comprobar que no funciona porque aún no se implementado este requisito y evitar la duplicación de código innecesaria. De esta forma mantenemos un código limpio y mantenemos un alto grado de eficacia, que es la finalidad de TDD. [37] Ventajas del uso de TDD Existen ventajas y desventajas en el uso de TDD, pero en gran medida las ventajas son muy beneficiosas, por lo que en general, vale la pena la implementación del proyecto mediante esta técnica. Por un lado, si realizamos primero los test unitarios en un proyecto, esto quiere decir que hemos debido realizar un análisis en profundidad de los requisitos y los diversos escenarios. Eliminando variabilidad y encontrando los puntos clave. Además, la superación de las pruebas asegura que el código creado sea el mínimo necesario, reduciendo redundancia. La única desventaja digna de mencionar es que hay que trabajar la faceta de realización de buenos test. 4.4 Desarrollo Dirigido por Tests de Aceptación (ATDD) ATDD es una variación de aplicación del TDD. En este caso los test que se pasan son llamados de aceptación o de cliente y son los criterios escritos de que el producto contiene todas las funcionalidades demandadas por el cliente. El trabajo que se tiene que realizar en este tipo de metodología es el de transformar los requisitos obtenidos de las especificación del proyecto en lenguaje natural. Este proceso se realizar con todos los roles que existen en el proyecto (product owner, scrum team y los asesores de QA (quality assurance)) para darle la forma deseada con la colaboración de todos, ya que no hay una única manera 40

52 correcta de definirlos. El ciclo ATDD es el mismo que el de TDD pero con la diferencia de que este es exclusivamente por desarrolladores. En ATDD la lista de tests de cada requisito o historia de usuario pasan primero por el test de aceptación y posteriormente por el clásico algoritmo de TDD como se observa en la siguiente figura: Fig. 25: Ciclo ATDD Historias de usuario La historia de usuario es la traducción del requisito del proyecto al lenguaje natural. Este posee similitudes con los casos de uso. Con el hecho de establecer una relación entre ambos podríamos decir que el título de la historia de usuario corresponde con el del caso de uso. Cada historia de usuario contiene una lista de requerimientos que el cliente quiere que la funcionalidad contenga con total claridad. El titulo de la historia de usuario es un frase corta que resume las tareas que esta contiene, por ejemplo: 41

53 HISTORIAS DE USUARIO Formulario de registro Aceptar solicitud de amistad Perfil de usuario Enviar un mensaje Mostrar mapa Tabla 8: Ejemplo de historias de usuario Este tipo de historias deben ser breves, concretas y estimables, resultado de escuchar al cliente y de orientarle hacia lo que en verdad quiere. Cada una de estas historias genera preguntas acerca de las múltiples posibilidades que esta tiene. Estas preguntas son formuladas por parte del equipo de desarrolladores a los analistas y al cliente. Algunas preguntas de ejemplo obtenidas de la tabla anterior (Tabla 8) podrían ser: Que pasaría si la información introducida por el usuario es errónea y no tiene el formato esperado por el sistema? O si ya existe? Que ocurre si el amigo que envía la solicitud ya existe como amigo? Que ocurre si modificamos la información del perfil de usuario? Se actualiza automáticamente? Que pasa si enviamos un mensaje a alguien que no es nuestro amigo? O si el usuario no existe? Como hay que actuar en caso de que el dispositivo no permita la localización a través del GPS? Las respuestas puede incluso dar lugar a nuevos elementos en el product backlog. 42

54 4.4.2 Desarrollo centrado en la finalidad Usando ATDD y los frameworks que lo acompañan, podemos abstraernos de como quiere el cliente que funcione su proyecto, si no que nos centramos en el que tiene que hacer. De esa forma el equipo de desarrollo se centra en el resultado que se tiene obtener. Cambiamos el: Al rellenar el campo de texto y pulsar el botón Enviar mensaje, el mensaje debe enviarse y actualizar la página para que el usuario vea su mensaje publicado en la lista que se encentra bajo el mapa; por: Al enviar un mensaje, el muro debe actualizarse. Centrarse en la finalidad exige que tanto el product owner como el cliente se queden al margen de la forma en la que el equipo de desarrollo tiene pensado resolver cada una de las funcionalidades demandadas por dicho cliente. El problema que surge aquí es que el cliente se empeña en explicar esto, es decir, está convencido de hacerlo de una forma determinada, creyendo que ese es su rol dentro del proyecto. Este comportamiento es debido a que se ha encontrado con profesionales poco experimentados que no han sabido dirigirle a lo largo del proceso de planificación y no han sabido darle los ejemplos correctos para aclararle las ideas. Con ATDD nos convertimos en una especie de psicólogos en vez de adivinos. 43

55 Fig. 26: Trabajo del Scrum Team con el cliente [38] Frameworks ATDD Mocha Mocha es un framework test de JavaScript ejecutado sobre Node.js y por consiguiente en el explorador web, haciendo que las pruebas de forma asíncrona sea posible. Mocha ejecuta las sentencias en serie, permitiendo generar informes de forma precisa y flexible mientras que se capturan las excepciones ocurridas sobre los tests case. [39] Fig. 27: Logo Mocha [40] 44

56 Mocha contiene una serie de prestaciones que hacen que su uso sea ligero y eficiente [41]. Expresso Expresso [42] es un framework TDD para nodejs. Sus características son: CARACTERÍSTICAS Ligero Soporte para operaciones asíncronas intuitivo Ejecución de test intuitivos Informe de la cobertura de test Uso del módulo assert Tabla 9: Características de Expresso Unit.js Framework de test unitarios para JavaScript y Node.js. La filosofía de Unit.js es ser moderno, flexible, simple e intuitivo. [43] 45

57 Fig. 28: Logo UnitJS [44] Unit.js es una librería de afirmaciones para JavaScript, ejecutada sobre Node.js y un explorador web. Funciona con cualquier ejecutable de test y otros frameworks de prueba como Mocha, Jasmine, Karma, Protactor y más. Este framework ofrece un API para escribir las pruebas de la forma preferida por el desarrollador: Unit.js Assert Must.js Should.js Sinon.js Resto de librerías preferidas 4.5 MVC (Modelo Vista-Controlador) Para cada problema siempre hay buenas soluciones para la programación web, pero la 46

58 solución más común es la de aplicar el patrón de diseño MVC para organizar el código. Este patrón organiza el código en base a su función y como su propio nombre indica, lo organiza en 3 capas, modelo, vista y controlador [45]: Modelo: Esta capa define la lógica de negocio. En esta base es la que se encarga de mantener la información de la página, la base de datos. Contiene el núcleo de la funcionalidad de la aplicación. Vista: Está capa es la que está cara al usuario, sería donde se encontraría la interfaz de usuario o UI. Es la presentación del modelo y a través de la cual se modifica. Estas 2 capas están conectadas y cuando ocurre un cambio en la capa de modelo, esta se lo notifica a la de vista. Controlador: En esta capa se encuentra el bloque de código que realiza las llamadas al modelo y lo manipula para obtener datos y pasárselos a la vista. Fig. 29: Esquema del MVC 4.6 Stack MEAN (MongoDB, ExpressJS, AngularJS, NodeJS) En los últimos años se han puesto muy do moda las tecnologías MongoDB, NodeJS y 47

59 AngularJS lo que haya hecho que surjan alternativas que combinen estas 3 tecnologías (sin mencionar todos los complementos que acompañan a estas) para la construcción de webapps rápidas, robustas y mantenibles usando MongoDB, ExpressJS (middleware de NodeJS), AngularJS y el propio NodeJS. [46][47][48][49] Fig. 30: Stack MEAN [50] MongoDB MongoDB [51] es una base de datos documental que provee de gran rendimiento, gran disponibilidad y fácilmente escalable. Fig. 31: Logo MongoDB [52] 48

60 Base de datos documental: Los documentos se adaptan perfectamente a los distintos tipos de lenguajes de programación La capacidad de incrustar documentos y arrays reduce la necesidad de joins. Polimorfismo simplificado gracias al dinamismo de los esquemas. Alto rendimiento: Incrustar documentos permite una mayor rapidez de escritura y escritura. La indexación permite incluir índices a los documentos incrustados. Flujos de escritura opcionales. Alta disponibilidad: La replicación de servidores permite una experta recuperación de fallos. Escalabilidad simplificada: Las lecturas por eventos permite la replicación de esta de forma distribuida por todos los servidores. La automatización de la réplica permite distribuir colecciones a través de todas las máquinas. Estructura Un despliegue de MongoDB hospeda un número de bases de datos. Una base de datos está compuesta por un conjunto de colecciones. Cada colección soporta un conjunto de 49

61 documentos u objetos. Un documento es un conjunto de pares clave-valor en el que se almacena la información. Este tipo de objeto tienen esquemas dinámicos. Esto significa que los documentos dentro de una misma colección no tienen porque se de un mismo tipo, mismos campos o estructuras. Dentro de un documento puedes encontrar un sinfín de tipos de información. Fig. 32: Ejemplo de estructura de un documento en MongoDB [53] MongoLab MongoLab [54] es un servicio que ofrece almacenamiento para MongoDB completamente gestionado por el usuario. Las características que hacen de MongoLab un servicio de gran calidad es: Soporte para API REST. Permite la integración de distintas soluciones: Amazon AWS, Azure y Google. Alta disponibilidad. Monitorización continua y en alerta. 50

62 Análisis optimizado de query. Backups. Esto hace que la aplicación no dependa de manera local a la información almacenada, únicamente se necesita de conexión a Internet para acceder a la base de datos almacenadas en la página Moongose Mongoose [54] provee de una solución directa para el modelador de los datos de la aplicación web e incluye moldes para la construcción de tipos, validaciones, construcción de consultas, lógica de negocio y más. Fig. 33: Logo Mongoose [55] ExpressJS ExpressJS [56] es un framework web minimalista y flexible para Node.js que proporciona un conjunto robusto de características para aplicaciones web y móviles. Contiene una gran variedad de m todos de utilidad HTTP y middleware a su disposición, la creación de una potente API es rápido y fácil. 51

63 Fig. 34: Logo Express [57] El rendimiento de Express que provee de una capa web fundamental sin la necesidad de deshacerse de las prestaciones de Node. Algunas de las principales características son: Operaciones GET, POST, PUT y DELETE. Motores de plantillas: EJS, Jade, Less, Middleware vía Connect. Buena cobertura de test AngularJS AngularJS [58] es un framework que extiende las capacidades de HTML para tu aplicación. El entorno resultante es extraordinariamente expresivo y rápido de desarrollar. 52

64 Fig. 35: Logo AngularJS [59] AngularJS es una caja de herramientas para construir poderosas aplicaciones web. Es plenamente extensible y además es compatible con otras librerías. Cada prestación que AngularJS ofrece puede ser modificada o sustituida para que cumpla nuestras necesidades. Este web framework puede ser usado como solución completa a un problema de cara al cliente. Gestiona todo el DOM y AJAX que tiene lugar en tu aplicación. Algunas de las características que tiene: Data binding con {{}}. Controles DOM para estructuras para repetir, mostrar y ocultar elementos DOM. Soporta formularios y la validación de estos. Añade nuevos comportamientos al DOM, como controladores de eventos. Agrupa elementos HTML re-utilizables. Existen algunos elementos que son clave para optimizar el uso de las posibilidades que AngularJS nos ofrece como controladores, directivas, servicios, vista parciales y filtros entre muchos otros. Two-way data binding 53

65 La manera que AngularJS tiene para sincronizar los datos entre la capa de modelo y la vista es la funcionalidad de two-way data binding. Esto significa que si ocurre un cambio en el modelo, este se verá reflejado automaticamente en la vista y viciversa. Esto es diferente por ejemplo a cuando usamos jquery para esto, donde tenemos que implementar la lógica en ambas capas para que esta sincronización tenga efecto. Fig. 36: Two - way Data Binding Inyección de dependencias (Dependency Injection) Dependency Injection es un patrón de diseño que trata la forma en la que los componentes acceden a sus dependencias. Esta parte de la funcionalidad está a cargo de crear componentes, resolver dependencias y de proveer dichos componentes necesarios. Esta característica se usa definiendo los componentes o proveyendo bloques de configuración con.config o.run dentro la aplicación de Angular. Controladores En AngularJS, los controladores son funciones constructoras de JavaScript que se usan para incrementar la visibilidad del contexto o $scope. 54

66 Cuando un controlador es asignado a un elemento DOM a través de la directiva ngcontroller, Angular instancia un objeto de dicho controlador usando la función constructora de esta. De esta forma se crea una $scope hija disponible al inyectar el parámetro del controlador. Fig. 37: Controladores AngularJS [60] Los controladores son usados para: Establecer el estado inicial del objeto $scope. Añade comportamientos y eventos al objeto $scope. Directivas Podemos decir que las directivas con marcadores de elementos DOM, como los atributos que añadimos, los nombres o comentarios que le dicen al compilador que comportamiento añadir. Angular ya viene con algunas directivas incluidas como ng-bind, ngmodel (para sincronizar la capa de modelo con la vista, two-way data binding) y ngclass. A medida que los desarrolladores van creando servicios y controladores, eventualmente crean sus directivas para dar un poco más de funcionalidad a su proyecto. 55

67 Servicios Los servicios en Angular son objetos sustituibles que están unidos usando dependency injection (DI). Los servicios se usan para organizar y compartir código a través de toda la aplicación. Los servicios de angular: Instanciación lazy Angular solo crea el servicio cuando algún componente de la aplicación lo necesita. Singletons Cada componente dependiente de un servicio obtiene una referencia de este. Existen diferentes clases de servicio según las necesidades del proyecto: Factorías: Este tipo de servicio sirve para que te devuelva algún objeto de cualquier tipo. Lo típico es devolver un objeto JavaScript donde encontramos campos y métodos. Proveedores: Este tipo de declaración se usa cuando queremos implementar una API de cara a usarla en la aplicación, la cual es configurada antes de que la aplicación arranque. 56

68 Fig. 38: Servicios en AngularJS [61] NodeJS Como framework dirigido por eventos asíncronos, NodeJS [62] es diseñado para crear aplicaciones web escalables. De esta forma, la aplicación puede manejar muchas conexiones concurrentemente. Por cada conexión un callback es llamado, mientras tanto, Node.js está en espera sin hacer nada, de ahí que esté dirigido por eventos. 57

69 Fig. 39: Logo NodeJS [63] Esto es lo que en programación se llama programación concurrente donde se emplean hilos o threads para responder a las llamadas del sistema. La comunicación de red basado en hilos no es todo lo eficaz que gustaría y es muy difícil de usar. Es más, los usuarios de aplicaciones basadas en NodeJS no tienen que preocuparse por el atasco o parada de los procesos por que no existen tales paradas en el código. Casi ninguna funcionalidad en este framework realiza operaciones I/O por lo que los procesos no se bloquean. Fig. 40: Eventos asíncronos en Node.js [64] En Node.js el principal actor es el protocolo HTTP, ya que está diseñado para enviar 58

70 flujos de datos a baja latencia. Esto hace que NodeJS sea la opción perfecta para usarlo como framework web a la hora de construir nuestras aplicaciones. Construido en JavaScript JavaScript es el lenguaje de programación más popular (para bien y para mal). Si alguna vez el lector ha realizado alguna tarea basada en web, ha tenido que escribir con este lenguaje. Node usa V8, la máquina virtual que ejecuta Google Chrome, para la programación del lado del servidor. Node tiene un gran rendimiento debido a que parte de la base de compilar directamente en la máquina nativa que ejecutar y compilar en cada lenguaje. Otros beneficios de que Node esté escrito en JavaScript son: Los desarrolladores pueden escribir las aplicaciones en un solo lenguaje, lo que ayuda a reducir el contexto de cambio entre el cliente y el servidor durante el desarrollo, y permitiendo la comunicación entre ambos, así como reutilizar código. JSON es muy popular como tipo de dato para compartir información a día de hoy, además es un tipo de dato nativo de JavaScript. Fig. 41: Comunicación entre el servidor y el cliente con Node.js [65] 59

71 JavaScript es el lenguaje usado en algunas bases de datos no relacionales o NoSQL (como CouchDB o MongoDB), por lo que usar JavaScript quitaría a los desarrolladores problemas de conversión en caso de querer usar este tipo de BD. JavaScript es compilado por un gran número de lenguajes. Node usa V8 como hemos dicho antes, que mantiene el estándar ECMAScript. EN otras palabras, no tiene que esperar que todos los compiladores se pongan al día para poder usarlo. 60

72 61

73 62

74 Capítulo 5. RESULTADOS 5.1 Introducción En esta sección se describe la aplicación de las herramientas y procedimientos explicados en el capítulo anterior. Se verá la planificación prevista para el desarrollo del proyecto y como se han aplicado las técnicas para construir una aplicación web basada en la geolocalización mostrando los pasos más significativos. Además, se asignarán los roles que cada uno de los interesados en el proyecto adoptan para obtener un resultado satisfactorio. 5.2 Planificación Los roles de product owner recae sobre la figura del tutor del proyecto y el rol de scrum team recae sobre el autor del proyecto, ya que este el que tiene que mantener y planificar el plan de trabajo y de desarrollarlo. El rol de scrum master también es desempeñado por el autor del proyecto, ya que este es el que marca las reuniones para realizar las revisiones de estado de los sprints y de la organización de los siguientes pasos en el proyecto. El product backlog queda definido a través de las historias de usuario que dará forma al proyecto. Cada historia de usuario corresponde casi en su totalidad con una funcionalidad de la aplicación web. Esta lista de historias de usuarios se ve afectada por el avance del proyecto, donde según se implementan algunas funcionalidades, se encuentra con la necesidad de añadir otras para que la experiencia de usuario sea la mejor posible. El product backlog definitivo quedaría definido en la siguiente tabla: 63

75 PRODUCT BACKLOG Como usuario quiero poder registrarme en la aplicación. Cómo usuario quiero poder acceder mi cuenta en la aplicación Como usuario quiero añadir información personal a mi perfil. Como usuario quiero poder modificar la información personal de mi perfil. Como usuario quier poder eliminar la información personal de mi perfil. Como usuario quiero poder añadir a mis contactos a la aplicación. Como usuario quiero poder eliminar a mis contactos de la aplicación. Cómo usuario quiero poder comunicarme con mis contactos a través de la aplicación. Como usuario quiero compartir mi ubicación con mis contactos dentro de la ubicación. Como usuario quiero poder localizar a mis amigos dentro de la aplicación. Tabla 10: Product Backlog La planificación se ha realizado a través de un estudio de los requisitos o historias de usuario que existen en el proyecto. Estas historias se han organizado en 4 sprints que describen distintas partes fundamentales de la aplicación: Sprint 1 Acceso a la aplicación: En este sprint se implementan las funcionalidades necesarias para acceder a la aplicación como son el registro y la autenticación. Sprint 2 Perfiles de usuario: Este sprint contiene las historias de usuario en lo que refiere a la información que los usuarios muestran de cara al resto de participantes en la aplicación web. Sprint 3 Amigos: Implementación de las funciones básicas para gestionar al resto 64

76 de usuarios de la aplicación y añadirlos a tu lista de amigos, para poder visualizar información adicional acerca de ellos. Sprint 4 Localización: Mediante la API de HTML5, disponer de la posición del usuario en el momento que entra en la aplicación, para compartirla con el resto de usuarios. La estimación de las horas necesarias para llevar a cabo cada uno de los sprints se realizó mediante un estudio de las tareas que cada sprint contiene y de la habilidad del desarrollador designado y se han contemplado los siguientes aspectos: 1. Quién sera el encargado de resolver las tareas. 2. Como de difícil ve el encargado de resolverlas. Es decir, la complejidad que en un primer momento se puede identificar a partir de las habilidades y experiencia del desarrollador. 3. La limpieza del código. El desarrollador puede introducir bloques de código que luego no existirán en la fase de producción, lo que aumentará el tiempo de depuración del código. La planificación final se muestra con un diagrama de Gantt creado con la herramienta Gantt Project [66], en la que se muestran las tareas que forman parte de cada sprint planificado. La duración total del proyecto es de aproximadamente 2 meses, comenzando a finales de Marzo y concluyendo la aplicación a finales de Mayo. Los sprints se suceden de forma secuencial, los cuales tienen una relación Inicio-Fin con su antecesor. 65

77 Fig. 42: Diagrama de Gantt 66

78 SPRINT HISTORIA DE USUARIO ESTIMACIÓN (EN HORAS) VALIDACIÓN Como usuario quiero poder registrarme en la aplicación Como usuario quiero poder acceder mi cuenta en la aplicación. Como usuario quiero añadir información personal a mi perfil. Como usuario quiero poder modificar la información personal de mi perfil. Poder registrarse en la aplicación. 30 horas Autenticarse en la aplicación. Añadir información a la página de perfil para mostrarla al público. 45 horas Modificar la información que se muestra. Como usuario quiero poder añadir a mis contactos a la aplicación. Añadir a personas a tu lista de amigos. Como usuario quiero poder eliminar a mis contactos de la aplicación. Eliminar a amigos de la lista de amigos. 40 horas Cómo usuario quiero poder comunicarme con mis contactos a través de la aplicación. Establecer un chat entra los amigos seleccionados. Como usuario quiero compartir mi ubicación con mis contactos dentro de la ubicación. Compartir la ubicación GPS y ser localizado por el resto de amigos. Como usuario quiero poder localizar a mis amigos dentro de la aplicación. 50 horas Visualizar a mis amigos representados en un mapa. Tabla 11: Sprint Backlog Una vez tenemos definidas las historias de usuarios, se han de establecer las tareas que cada una de ellas conllevan. Estas tareas son los pasos que se toma a lo largo de cada uno de los sprint para llegar al objetivo, que es la entrega del hito de cada uno de los sprints. En la siguiente figura se muestran que tareas son las que componen cada uno de los sprints y la duración (en días) de cada una de ellas. Al final de cada sprint se indica el hito o entrega que se realiza en la finalización de cada uno de ellos. 67

79 Fig. 43: Tareas Sprints Mediante el uso de la herramienta Trello, una herramienta de gestión de proyectos que es perfecta para la planificación mediante Scrum, podemos crearnos una lista con los productos obtenidos tras la aplicación de la metodología utilizada para planificar el proyecto, en este caso, Scrum. En esta aplicación, nos ofrece la posibilidad, mediante la creación de fichas, organizar nuestras tareas en distintas categorías. En nuestro tablero existen distintas listas que agrupan: El product backlog. Los sprint backlog correspondientes con cada sprint, en los que aparecen cada tarea en su estado. 68

80 Los sprints review de cada reunión que acompañan a cada sprint que muestra el estado de las tareas y si se propone el cambio en el product backlog. Sprint retrospective en los sprints que existan algunas buenas prácticas que se creen necesarias respetar para que el proyecto quede de la manera más uniforme y correcta posible. Fig. 44: Artefactos y Eventos Scrum del proyecto 5.3 Sprint 1 Entrar en GeoMe Introducción Este sprint se caracteriza porque al ser el inicio del proyecto, contiene la instalación y configuración del entorno en el que se desarrollará el proyecto (directorios, ficheros, recursos, etc.). Las tareas correspondientes a este sprint se encuentran en el tablero Sprint Backlog #1. En la siguiente figura se muestra el estado del Sprint Backlog #1 al finalizar este e implementar el acceso a la aplicación GeoMe: Las tareas planeadas en este sprint son las siguientes: Conexión MongoDB. 69

81 Registro. Login. Entrar en GeoMe. Las pruebas que debe pasar el código para cumplir con las expectativas del sprint son los siguientes casos: Fig. 45: Fase de fallos en los test de ATDD Estructura del proyecto Implementando las tecnologías contenidas en el Stack MEAN, se tiene que tener en cuenta las buenas prácticas que recomiendan los desarrolladores de cada una de estas tecnologías por separado. Teniendo en cuenta que la aplicación se ha construido teniendo en mente una arquitectura cliente servidor: 70

82 Fig. 46: Estructura Stack MEAN [67] Por lo que se tiene que encontrar el equilibrio entre las estructuras que se recomiendan para MongoDB, NodeJS y ExpressJS y AngulaJS. El directorio se ha dividido en dos partes: la parte del servidor, donde se encuentra MongoDB y el servidor creado con NodeJS + ExpressJS con las rutas necesarias para recuperar los datos necesario de la capa de persistencia y la parte del frontend, donde se encuentran los archivos que van a tratar los datos recuperados en la parte del servidor. Después de crear los directorios correspondientes, la estructura del proyecto queda de la siguiente forma: Fig. 47: Estructura de directorios de GeoMe 71

83 El primer paso para crear el proyecto es la de definir el archivo package.json, el cual contendrá los módulos adicionales de NodeJS que se necesitarán para implementar las funcionalidades que se necesiten. El contenido final del fichero es el siguiente: Fig. 48: Contenido de package.json Acceso a MongoDB Para que la aplicación pueda almacenar la información introducida por los usuarios de la aplicación, debe tener conectada un sistema de almacenamiento, como una base de datos o ficheros. En este caso lo que se hará es conectar GeoMe a una base de datos NoSQL, que guardará la información de los usuarios, como sus datos, las relaciones con el resto de los usuarios y los mensajes que se envían entre estos. Esta tarea se consigue con el enlace a un servicio externo de este tipo de almacenamiento. La parte de conexión con MongoLab consta de 2 partes: 72

84 1. La URL de conexión que permite al servidor NodeJS conectarse a MongoLab, para permitir a la aplicación realizar consultas contra la base de datos en la nube. 2. La creación de los modelos de objetos que se usarán en la aplicación web. El fichero config.js contiene todas las variables necesarias para la ejecución de la aplicación, en este caso contiene el puerto sobre el que se ejecutará el servidor, la URL de conexión con la base de datos en MongoLab, con el nombre de la base de datos que se está utilizando (en este caso esitfg), con la información de acceso (usuario y contraseña) y la palabra secreta que se utiliza para codificar los datos. Fig. 49: Contenido de config.js En este punto, solo queda crear la conexión en el servidor con MongoLab, lo cual se consigue de la siguiente forma: Fig. 50: Conexión con MongoLab Registro El registro y el resto de operaciones que tienen que ver con manipular la base de datos (crear usuarios, enviar mensajes, etc.), se realizan mediante peticiones a la API que mediante AngularJS y sus servicios pone a disposición de los usuarios al alcance de un botón. 73

85 Fig. 51: Atributos del objeto User El registro en la aplicación conlleva la creación de un tipo de objeto User para almacenarlo en MongoDB. Este objeto tiene la siguiente estructura: En este objeto se almacenará información imprescindible para el funcionamiento de la aplicación, más allá de la información personal, que son las coordenadas del usuario (latitude y longitude). Para tratar las requests que se realizan desde el cliente, se ha desarrollado una capa de servicios en la parte pública de la aplicación para que, a través de operaciones GET, PUT, DELETE y POST, se pueda manipular la base de datos en MongoLab. Este tipo de operaciones primero reciben un tratamiento a través de los controladores que AngularJS ofrece, pudiendo manipular la información ante de que sea guardada en la base de datos. 74

86 Fig. 52: Fragmento de código del controlador de creación de usuarios En este caso, el registro de usuarios, se realiza una petición POST, la cual es tratada de la siguiente manera en el frontend. Este controlador está conectado al servicio de usuarios, el cual gestiona las conexiones a la base de datos cuando la información incluye datos de los usuarios, como la modificación, la eliminación, una búsqueda, etc. Todo esto se encuentra en el fichero userservice.js y en concreto, la operación que solicita el controlador de este fichero es la de userfactory.create. En la siguiente figura podemos ver la estructura de esta llamada a la API de la aplicación: Fig. 53: Fragmento de código de la función de registro 75

87 Fig. 54: Operación en la API para el registro de usuarios Esta operación realiza una llamada POST a la API diseñada para el proyecto, en concreto, esta llamada afecta a la siguiente parte de la API: En caso de error, el sistema envía de vuelta un mensaje en el que le indica el error y si la operación se realiza satisfactoriamente, envía un mensaje afirmativo. Después de que el usuario completa satisfactoriamente el registro, podemos observar que los cambios se han realizado de forma correcta y se reflejan en la base de datos: Fig. 55: Registro de usuario en MongoLab 76

88 5.3.5 Login GeoMe implementa un acceso a la aplicación basado en tokens. Este modelo de autenticación es el más común cuando la la aplicación web dispone de una API para las peticiones al servidor. Las principales razones para elegir este tipo de sistema de autenticación es: Sin estado y perfectamente escalable. Preparado para el login a través de dispositivos móviles. Autenticación a través de terceros (Twitter, Facebook y Google+). Ofrece seguridad extra. El funcionamiento de este tipo de login es bastante simple y se puede describir en 5 simples pasos: 1. El usuario intenta entrar con una combinación de nombre de usuario y contraseña. 2. El sistema valida sus credenciales. 3. El sistema provee al usuario de un token firmado por él. 4. El usuario almacena dicho token y lo envía con cada request que le haga al sistema. 5. El sistema verifica dicho token y responde en consecuencia. 77

89 Fig. 56: Autenticación basada en tokens [69] El sistema de login sigue el mismo recorrido que las operaciones que acceden a la API de la aplicación. En este caso, el servicio que gestiona los datos de autenticación se encuentran en el fichero authservice.js, donde tenemos las siguientes funciones: login: Esta función se encarga de la funcionalidad principal, que es la de autenticar al usuario en la aplicación. Se realiza un llamada a la API donde se envían los datos introducidos por el usuario (nombre de usuario y contraseña) y como resultado recibimos un token con dicha información. Fig. 57: Fragmento de código de la función de login 78

90 Esta función envía la información a la API la cuál comprueba los datos almacenados en la BD. Después de haber realizado las comprobaciones de que la información es correcta, el sistema crea un token con la información seleccionada: Fig. 58: Fragmento de código de la creación del token Logout: Esta función es llamada cuando el usuario quiere cerrar su sesión en la aplicación. Cuando se ejecuta esta función, la aplicación limpia el token relacionado con ese usuario: Fig. 59: Fragmento de código de la función de logout isloggedin: La función en cuestión comprueba si el usuario está logueado o no en la aplicación. Esta funcionalidad nos permitirá elegir que mostrar al usuario en función de estar o no autenticado en el sitio: 79

91 Fig. 60: Fragmento de código de la función de isloggedin getuser: En esta parte del servicio, recuperamos la información almacenada en el token del usuario. Esta información es la que usaremos para actualizar algunos aspectos de la funcionalidad de la aplicación (por ejemplo, actualizar su posición en cada momento): Fig. 61: Fragmento de código de la función de getuser Estas funciones que encontramos en nuestro servicio authservice.js son llamadas desde el controlador creado para centralizar las operaciones relacionadas con la autenticación del usuario en la aplicación. Este controlador se llama mainctrl.js y además de las llamadas a las funciones previamente descritas, cabe destacar 2 aspectos importantes: El uso del servicio $routechangestart, la cual es activada en cada request que el usuario realiza a la aplicación (como ir a una página, enviar un mensaje, etc.). En este servicio se comprueba si el usuario sigue autenticado en la aplicación y se actualiza la localización del usuario: 80

92 Fig. 62: Fragmento de código para comprobar la sesión y actualizar las coordenadas Además, como se puede observar en la figura anterior, también se actualizan las coordenadas del usuario cada vez que este cambia de ruta Entrar en GeoMe En este punto, la aplicación es accesible a través del registro y posterior autenticación del usuario, por lo que se alcanza el hito programado para el primer sprint. Tras la creación en el frontend de un formulario, tanto de registro como de autenticación, la aplicación tiene el siguiente aspecto: 81

93 Fig. 64: Página de registro de GeoMe Fig. 63: Página de autenticación de GeoMe Fig. 65: Test pasados satisfactoriamente Una vez tenemos el código implementado en la aplicación, volveremos a pasar los test y comprobar que, efectivamente, el código usado es funcional: 82

94 5.4 Sprint 2 - Perfiles de usuario Introducción En el segundo sprint se implementan los mecanismos necesarios para crear y personalizar los perfiles de usuario de los clientes de la aplicación web. Esto implica, entre otras cosas, añadir más operaciones a la API y otros controladores para gestionar las operaciones que tengan lugar en el perfil de usuario. La lista de tareas que tenemos en este sprint son: Añadir el perfil de usuario. Localización. Modificar perfil de usuario. Eliminar cuenta. Perfil de usuario Añadir perfil de usuario Para que el usuario sea capaz de compartir se información personal con el resto de usuarios, es necesario crear un apartado donde se refleja toda esta información. Para este fin, es necesario dos cosas: Añadir a la API de la aplicación estas peticiones para que los datos sean accesibles a la aplicación. 83

95 Crear un página donde se recuperen los datos de la base de datos asociados al usuario en cuestión (los nuestros o los del usuario que estamos visualizando en ese momento). En la API se añadirá una operación GET para recuperar los datos almacenados en MongoLab. Esta sentencia es sencilla ya que no hay que tratar los datos, se envían directamente al controlador para que este la enlace con la capa de presentación, el único parámetro que la operación requiere es el del id del usuario en cuestión: Fig. 66: Recuperar la información del usuario El controlador recupera los atributos del objeto user que le llega de la API y le asigna estos a los respectivos campos que queremos mostrar y/o utilizar en la página del perfil de usuario: Fig. 67: Operación getprofile en el controlador del perfil de usuario De esta forma ya tenemos los datos disponibles para usarlos en la página web que 84

96 contendrá esta información. En lo referente a la presentación de la información, usaremos las directivas disponibles de AngularJS para tratar los datos y mediante controladores, mostrarla del modo seleccionado: Fig. 68: Código para mostrar la información del usuario Localización Una parte fundamental de la funcionalidad de la aplicación, es la de mostrar la posición en Google Maps [70]. Esto se consigue por el uso de un módulo específico para AngularJS el cuál nos permite utilizar todas las funciones disponibles por la API de Google Maps en este framework de Google. NgMap [71], el nombre que recibe el módulo de Google Maps, nos permite posicionar sobre un mapa los puntos que deseemos. En este caso, mediante el GPS del dispositivo, podemos recuperar las coordenadas y localizar a los usuarios en el momento que accedan a la aplicación y naveguen por ella. Uno de los lugares donde se hará uso de esta característica será en la página del perfil de usuario, donde se mostrará, además de la información, la posición en el mapa del dueño de esa página de perfil. Como se ha visto en el apartado anterior, entre los datos recuperados están la localización, la latitud y la longitud del usuario. Estos datos son actualizados cuando el usuario navega por la aplicación y lo hace mediante una llamada a la API de esta, más concretamente al método storegeo() que se puede encontrar en el controlador mainctrl: 85

97 Fig. 69: Código de storegeo() En la API guardamos la información en la entrada indicada dentro del objeto vm.user: Fig. 70: Actualización de la información de la localización Ya solo queda mostrar el mapa y colocar sobre este un marcador que indique la posición exacta de nuestro usuario: Fig. 71: Código del uso del módulo ngmap El aspecto final de la página de perfil de usuario es el siguiente: 86

98 Fig. 72: Perfil de usuario con localización En la figura anterior podemos visualizar el nombre del usuario y su posición en el mapa y en la siguiente el resto de datos que queremos mostrar, como la imagen de perfil, su ciudad de residencia, etc: 87

99 Fig. 73: Perfil de usuario con información acerca de este Modificar perfil de usuario Es imprescindible permitir al usuario modificar la información que introduce en su perfil de usuario, ya que esta puede volverse obsoleta o simplemente, la ha introducido incorrectamente. El primer paso es el crear un formulario para que el usuario pueda modificar la información que se desee. Este formulario lo encontraremos en la propia página del perfil de usuario, el cual tendrá el mismo formato que el formulario de registro. En las siguientes figuras se indica la localización del formulario y su estructura: 88

100 Fig. 74: Acceso al formulario de modificación Fig. 75: Estructura del formulario de modificación Para recoger los datos introducidos por el usuario, necesitamos que un actor intermedio los recoja, los trate y los envíe a la API, para que esta a su vez, actualice la base de datos. El controlador se encuentra en el fichero userctrl, y recoge los datos que son 89

101 enlazados mediante la directriz ng-model: Fig. 76: Ejemplo de uso de la directiva ng-model que enlaza el contenido con la variable En el controlador designado para tal tarea, tenemos que usar el id asociado con el usuario y los datos que queremos modificar: Fig. 77: Función de actualización de la información del perfil de usuario En la API se realiza la modificación mediante una sentencia PUT para modificar los datos de la entrada de la base de datos asociada al id: 90

102 Fig. 78: Función de la API para realizar la modificación sobre la base de datos Eliminar cuenta El usuario tiene completo control sobre su perfil de usuario y por ende, de su cuenta. Esta puede ser eliminada a decisión del dueño de la misma. Esta funcionalidad es una de las más sencillas de implementar, ya que solo interviene una llamada a la API con intención de borrar el id del usuario de la base de datos, lo que eliminará toda su información de la misma. El controlador designado para ello es el mismo que el utilizado previamente para las operaciones realizadas en la página de perfil de usuario. En este caso, existe un botón que tiene asignado el evento deleteuser() el cuál activa la llamada a la API: 91

103 Fig. 79: Función encargada de eliminar la cuenta del usuario La llamada en la API designada para esta tarea es una sentencia DELETE en la que incluimos el id del usuario para encontrar la referencia en la base de datos: Fig. 80: Sentencia DELETE Perfil de Usuario La aplicación web se encuentra ahora mismo con una funcionalidad mínima. A estas altura la aplicación es capaz de registrar a los usuarios y de asignarles una página de perfil de usuario para que este pueda mostrar la información deseada. La situación del sprint backlog de este sprint quedaría así: 92

104 Fig. 81: Situación final del Sprint Backlog Sprint 3 Gestión de usuarios Introducción Este sprint se centra en la gestión de los usuarios y las interacciones entre los usuarios, concretamente en la creación de amigos. Adicionalmente, se ofrece la posibilidad de que cada usuario gestione su propia lista de amigos, añadiéndolos o eliminándolos. El sprint backlog inicial correspondiente con este tramo del desarrollo de la aplicación web es el siguiente: Ver lista de usuarios. Comprobar si existe como amigo. Añadir usuario como amigo. Eliminar usuario de la lista de amigos. Gestionar usuarios. Siguiendo la metodología ATDD, lo primero es plantear los test que la aplicación debe pasar: 93

105 Fig. 82: Fase de fallos en los test de ATDD Ver lista de usuarios Los usuarios tienen que ser capaces de encontrar al resto dentro de la aplicación, por lo que esta tiene que mostrar una lista con la información de los usuarios para poder encontrarse. La aplicación la muestra en forma de tabla incluyendo una breve descripción de los usuarios, como la foto de perfil, el nombre completo y la edad. El primer paso para consultar los usuarios existentes en la aplicación es la de crear una página donde presentaremos dicha información. Con una simple tabla, podemos mostrar de forma ordenada y estructurada la información y las funciones asociadas a cada usuario, como es ver el perfil solicitado. La página correspondiente contiene una tabla que es enlazada, mediante los controladores de AngularJS, con la información recuperada de la base de datos, en la que seleccionamos la información a mostrar. A continuación, se muestra el código correspondiente con la tabla: 94

106 Fig. 83: Tabla correspondiente con los usuarios de la aplicación De esta forma, la tabla queda definida de la siguiente forma: Fig. 84: Aspecto de la lista de usuarios Desde el controlador asignado a esta vista, tenemos que enlazar la información proveniente de la API con la vista. Simplemente se crea un objeto que recoja el resultado de la consulta de la API, haciendo esta información visible para que la lista pueda manipularlo (en caso de necesitarlo) y así, mostrarlo: 95

107 Fig. 85: Enlace del resultado de la consulta con la vista Desde la API, se consulta a la base de datos, más concretamente a la colección que contiene a los usuarios, sobre la información de estos. De esta forma se crea un objeto que contiene el resultado de la consulta y se envía al controlador: Fig. 86: Consulta de la API sobre la base de datos Comprobar si existe como amigo En las redes sociales es común que los usuarios quieran tener un contacto más cercanos con los amigos o familiares. En este caso, de saber donde están y que están haciendo. Esto se consigue mediante la adición de los usuarios que se añadan a la lista de amigos. Para poder añadir a un usuario como amigos, el primer requisito es comprobar que este no lo es ya, para que, posteriormente, enviar una solicitud de amistad o no en caso de que ya lo sea. 96

108 Esta funcionalidad la encontraremos en la API, cada vez que se lleve a cabo un intento, por parte de los usuarios, de añadir a otro como amigo. Las solicitudes de amistad son creadas basadas con el esquema Friend que creamos con mongoose: Fig. 87: Esquema de las solicitudes de amigo Como se ha indicado previamente, el sistema comprueba 2 supuestos: Que no existe una solicitud ya enviada al mismo usuario. Que el usuario no esté ya añadido como amigo. En el siguiente fragmento de código, se puede observar como se comprueban ambos casos mediante la recogida de las solicitudes existentes y comparándolas con los id's tanto del solicitante como del solicitado: Fig. 88: Comprobaciones de las solicitudes de amigo 97

109 5.6.4 Añadir usuario como amigo La tarea se centra en colocar en el perfil de cada usuario la opción de que lo añadan como amigo. Esta acción desencadena un proceso que pasa por la comprobación descrita en el apartado anterior y finaliza, en caso de no cumplirse las premisas en esa comprobación, con el envío de una solicitud de amistad. En la página del perfil de usuario se puede encontrar un botón que comunica al sistema su intención de enviar una solicitud y será el controlador asignado a esta funcionalidad la que dispare todo el proceso de añadir a un amigo. El botón de solicitud de amigo se encuentra bajo la información de usuario: Fig. 89: Botón para añadir amigos Asociado a este botón se encuentra el evento que crea una nueva solicitud de amistad con el usuario al que pertenece la página de perfil. El controlador userprofilecontroller contiene dicho evento, cuyo código es el siguiente: 98

110 Fig. 90: Fragmento de código que crea la solicitud de amistad Los parámetros enviados a la API sirven para comprobar la posible existencia de solicitudes previamente realizadas o la existencia del usuario como amigo. La API, en caso de que no exista esta relación, crea la solicitud sin incidencias. El atributo status nos indica el estado de la solicitud, 0 en caso de que esta esté a la espera y será 1 en el caso de que el usuario al que se le solicita la intención de ser añadido como amigo, acepte. En este momento, las solicitudes de amistad ya se pueden enviar a los usuarios que estos soliciten, comprobando previamente el historial de solicitudes. 99

111 Fig. 91: Consulta y petición POST de la API para la creación de la solicitud Eliminar usuario de la lista de amigos Los usuarios tienen la opción, si así lo desean, de eliminar en cualquier momento a un usuario de su lista de amigos, lo que implica que la aplicación web no le dará información adicional sobre ese usuario. Al igual que el resto de funciones, está es mostrada al usuario mediante un botón, el cuál, mediante el controlador que gestiona a los amigos, nos permitirá eliminar la relación de estos 2 usuarios. El botón en cuestión lo encontramos en la lista de amigos de un usuario: 100

112 Fig. 92: Botón para eliminar a un amigo de la lista En caso de que el usuario decida su eliminación, el controlador envía la información del usuario a eliminar para que en la API se pueda encontrar la relación en la base de datos y posteriormente, eliminarla: Fig. 93: Método enlazado al botón de eliminar amigo En la API se busca en la base de datos y se elimina el registro correspondiente a la información proporcionada: Fig. 94: Operación de eliminación del registro en la base de datos 101

113 5.6.5 Gestionar usuarios Tras la finalización de este tercer sprint, el usuario es capaz de conectarse a la aplicación web, gestionar por completo su perfil de usuario, añadiendo y modificando su información e incluso su eliminación del sistema y por último la capacidad de crear una lista de usuarios a los que llama amigos para obtener más información acerca de ellos, como, posteriormente, se comprobará. El estado final del sprint backlog correspondiente, deja todas las tareas en la fase de DONE o completadas: Fig. 95: Estado del sprint backlog 3 Y los tests correspondientes con las tareas implementadas son aprobados: Fig. 96: Test aprobados satisfactoriamente 102

114 5.7 Sprint 4 - Geolocalización Introducción Este último sprint contiene las tareas que definen la aplicación web desarrollada para el TFG. En él, se creará la funcionalidad de la localización a través del GPS del dispositivo, poder encontrarlos en un mapa consultando sus perfiles o en la página principal y además permitir que los usuarios que conversen entre ellos a través de mensajes. La lista de tareas programada para este sprint son: Almacenar Geocoordenadas. Mostrar la posición de un usuario. Mostrar la posición de los amigos. Enviar mensajes a los amigos. Visualizar coordenadas. Al finalizar el sprint, tendremos implementadas todas las funcionalidades relacionadas con la gestión de las geocoordenadas y su visualización dentro de la aplicación. Los test preparados para este tramo del proyecto son: 103

115 Fig. 97: Test programados fallados Almacenar Geocoordenadas En esta tarea se prepara la aplicación para almacenar las geocoordenadas según las acciones que el usuario realice dentro de la aplicación. Para que la localización sea guardada en la base de datos, tienen que darse 2 casos: 1. El usuario se registra en la aplicación, con lo que se establece la posición inicial del usuario. 2. El usuario navega por la aplicación, lo que refresca la posición almacenada del usuario para así tener la posición más reciente dentro de la aplicación. En el primer supuesto, añadimos a la petición de registro, las coordenadas que nuestro dispositivo obtiene a través del módulo GPS: 104

116 Fig. 98: Añadimos la localización a la petición de registro del usuario De esta forma, el usuario puede ser localizado por el resto desde el primer momento que se realiza el registro. Tras el proceso de autenticación, el usuario tiene que ser capaz de actualizar su localización automáticamente, de forma que la posición que transmite a la aplicación sea lo más precisa posible en términos temporales. Mediante el uso de la directiva $routechangestart, el sistema es capaz de detectar el evento de cambio de ruta, o lo que es lo mismo, cuando el usuario navega por las secciones de la aplicación web. Esto dispara la acción de actualizar la información del usuario en la base de datos, más concretamente de la localización (calle, ronda, etc.), la latitud y la longitud. Todo esto se encuentra en el controlador llamado mainctrl, que envía una petición a la API de la aplicación con el fin de acceder a la base de datos. 105

117 Fig. 99: Actualización de la posición del usuario durante la navegación Mostrar la posición de un usuario Una información imprescindible a la hora de mostrar la información de un usuario en su página del perfil de usuario es su posición en el mapa. Mediante un marcador, se indica la posición desde la última actualización del usuario. En esta tarea, se hará uso de la directiva ngmaps que permite la manipulación de las coordenadas a mostrar. En este caso, se usarán aquellas almacenadas en el registro del usuario dentro de la base de datos. Mediante el uso del mismo controlador que gestionaba la información de usuario, obtendremos los atributos indicados para el funcionamiento de la funcionalidad: 106

118 Fig. 100: Atributos necesarios para ngmap En la página perfil de usuario, se asocian dichos atributos con las opciones disponibles en ngmap. En este caso, usaremos la clase center para centrar el mapa en la posición del usuario y un marker para mostrar la figura de un marcador que indique la posición exacta del usuario: Fig. 101: Directiva ngmap De esta forma, en el momento que un usuario visita su propio perfil o el de otro usuario existente en la aplicación, se muestra su posición en el mapa, pudiendo conocer su ubicación: Mostrar la posición de los amigos Una de las ventajas que ofrece GeoMe cuando un usuario añade a otro a su lista de amigos, es la de conocer su ubicación sin necesidad de tener que visitar su perfil para conocerla. Para esto, GeoMe ofrece una página principal en la que ofrece la información que más le interesa al usuario en un primer momento, que es saber la ubicación de sus amigos nada más entrar en la aplicación y los mensajes que estos hayan podido publicar. 107

119 Fig. 102: Obtener los amigos de la base de datos Mediante una consulta a la API para recuperar los usuarios de la base de datos, tenemos que escoger aquellos que pertenecen a nuestra lista de amigos. El sistema comprueba esto comparando los usuarios recogidos con las relaciones existentes en la colección de amigos donde nuestro id aparezca y el estado de la solicitud esté aceptada: A través del controlador designado para la página de inicio de la aplicación, enlazamos la lista de amigos con el mapa que se muestra en dicha página. Aquí será donde la aplicación, recorriendo la lista, cree un marcador para cada usuario y que sea visible su ubicación: 108

120 Fig. 103: Enlazar la lista de amigos con la página principal Fig. 104: Mostrar los amigos en el mapa Mediante la directriz ng-repeat, se recorre la lista y se obtiene de cada entrada de la lista la latitud y longitud, para mostrarlas en el mapa: Fig. 105: Aspecto de la página principal de GeoMe 109

121 El aspecto que recibe la página principal es el siguiente: Como se puede ver bajo el mapa correspondiente a la visualización de la ubicación de los amigos, la siguiente tarea es el envío de mensajes a través de la aplicación Enviar mensajes Esta última tarea finaliza la serie de funciones que permite la comunicación entre los distintos usuarios de la aplicación, tras la visualización de la ubicación de estos en la página principal. Esta función permite la escritura de mensajes en el muro del usuario, donde se pueden compartir las inquietudes o actividades que los usuarios están realizando, acompañado de la marca temporal indicando el momento donde se realizó el mensaje y de su localización. La aplicación ofrece a los usuarios un pequeño formulario que consta de: Un campo para introducir el mensaje. Este mensaje será el texto que el usuario decida compartir con el resto de amigos dentro de la aplicación. Un botón que envía el mensaje a la aplicación. Este mensaje dispara el evento asociado en el controlador que gestiona el envío de mensajes. 110

122 Fig. 106: Campo de mensaje y botón de enviar El controlador en cuestión envía el mensaje a la API para que esta lo registre y el mensaje se accesible por el resto de amigos. Una vez el mensaje se envía a la API, el controlador refresca la página para que el resultado sea visible por el usuario: Fig. 107: Método que crea la request para la API Ya en la API es necesario añadir el resto de información necesaria para que el mensaje contenga todo lo necesario para informar correctamente a los usuarios, como la fecha en la 111